Активные субъекты в системе учета университетских курсов

В контексте системы учета университетских курсов могут быть получены следующие ответы на поставленные выше вопросы.

• Каждому студенту полагается выбрать курсы для изучения.

• Профессорам следует распределить между собой курсы, которые должны быть
прочитаны в течение семестра.

• Служащие деканата обязаны создать каталог курсов и составить индивидуальные расписания работы студентов.

• Ответственность за администрирование базы данных со сведениями о профессорах, курсах и студентах возлагается на деканат.

• Система учета курсов должна передавать информацию во внешнюю систему
учета студентов.

На основании перечисленных ответов легко выделить следующие категории активных субъектов, взаимодействующих с системой учета университетских курсов: "студент", "профессор", "сотрудник деканата" и "система учета студентов".

1. Расположить курсор мыши над элементом Use Case View окна броузера (Browser) и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.

2. Выбрать элемент меню New→Actor; дерево,
отображаемое в окне Browser, пополнится элементом New Class, соответствующим новому активному субъекту.

3. Выбрать элемент New Class и изменить его
название, введя требуемое имя активного
субъекта.

В модель следует включить краткое описание каждого активного субъекта, которое должно определять его роль в процессе использования системы. Описания активных субъектов системы учета университетских курсов могут выглядеть следующим образом:

• Студент — лицо, зарегистрированное в качестве слушателя университетских курсов;

• Профессор — лицо, наделенное полномочиями вести занятия в университете;

• Сотрудник деканата—служащий, ответственный за функционирование системы учета университетских курсов;

• Система учета студентов — внешняя система, обеспечивающая хранение информации о студентах.

Если окно документирования (Documentation) не отображается, открыть его, активизировав элемент меню View →Documentation.

В окне Browser выбрать элемент дерева, соответствующий требуемому активному субъекту.

Разместить курсор в окне Documentation и ввести текстовое описание активного субъекта.

Варианты использования (use cases) позволяют моделировать диалог между активным субъектом и системой и отображают функции последней, предоставляемые в распоряжение субъекта. Набор вариантов использования системы охватывает множество заслуживающих внимания способов ее применения. Говоря формально, вариант использования — это последовательность выполняемых системой транзакций, которая приводит к получению некоего ощутимого результата, в котором заинтересован определенный активный субъект.

Помощь в выборе вариантов использования системы окажут ответы на следующие вопросы.

• Какие задачи решает каждый активный субъект?

• Способен ли тот или иной субъект создавать, сохранять, изменять, удалять или
считывать фрагменты данных в контексте системы?

• Какие варианты использования гарантируют выполнение указанных выше функций обработки данных?

• Должны ли активные субъекты сообщать системе о каких либо - непредвиденных внешних обстоятельствах?

• Имеет ли субъект право получать информацию об определенных событиях, происходящих в системе?

• Какие варианты использования связаны с поддержкой и администрированием системы?

• Удовлетворяются ли вариантами использования все функциональные требования, предъявляемые к системе?

В языке UML вариант использования представляется символом, показанным на рис. 3.4.

Рис.3.4 Обозначение варианта использования в UML

В течение длительного времени продолжается дискуссия о том, какие именно варианты использования следует считать "хорошими". Одна из проблем связана с приемлемостью уровня детализации вариантов использования, т.е. с тем, насколько обширными (или узкими) они должны быть. Однозначного ответа, однако, не существует. Мне по нраву следующее правило:

"Вариант использования обычно охватывает изрядную долю функций, выполняемых системой от начала и до конца, и должен представлять для того или иного активного субъекта определенную ценность".

Например, в системе учета университетских курсов субъект Студент обязан выбрать подходящие курсы, а информация о нем должна быть включена в расписания занятий и в систему учета студентов. Речь в данном случае идет о трех вариантах использования или только об одном? Я предпочла бы последнее, поскольку названные функции взаимозависимы: разве нормально, если студент, выбравший курсы, не будет упомянут в расписаниях или в системе учета студентов (или хотя бы не получит уведомления о том, что сведения о нем не сохранены)? Если никто не зарегистрируется ни на один курс, профессоров впору увольнять с работы!

Еще одна проблема состоит в том, что делать с функциями, которые являются различными, но выглядят как родственные. Например, в обязанность сотрудника деканата входит добавление, модификация и удаление данных о курсах. Что это, три варианта использования системы или все-таки один? И вновь я остановила бы выбор на одном варианте, ведение каталога курсов", поскольку все функции выполняются одним активным субъектом "сотрудник деканата" и затрагивают одни и те же системные сущности (курсы).

Варианты использования системы учета университетских курсов

Система обязана удовлетворять следующим требованиям.

• Активный субъект "студент" регистрирует курсы, которые он намеревается прослушать.

• По завершении регистрации информация о студенте передается во внешнюю систему учета студентов.

• Субъект "профессор" использует систему для выбора курсов, которые он хотел бы преподавать в течение семестра, и для получения реестров студентов по каждому курсу.

• Субъект "сотрудник деканата" несет ответственность за ведение и опубликование каталога курсов на семестр и сохранение всей информации о расписаниях, студентах и профессорах.

Варианты использования системы, идентифицированные на основе названных требований, перечислены ниже:

Поток событий для варианта использования

С каждым вариантом использования связан определенный поток событий, происходящих по мере выполнения соответствующих функций системы. При описании потока событий определяется, что необходимо осуществить, и игнорируются аспекты того, как это делается. Другими словами, события воспроизводятся средствами языка предметной области, а не в терминах практической реализации функций. Схема потока событий должна содержать ответы на следующие вопросы.

• Как и когда вариант использования инициируется и завершается?

• Каким образом активные субъекты взаимодействуют с системой?

• Какие данные затрагиваются вариантом использования?

• Что представляет собой нормальная последовательность событий, предусматриваемых вариантом использования?

• Существуют ли альтернативные потоки событий для нештатных ситуаций?

Потоки событий обычно документируются на фале планирования по мере потребности. Вначале дается краткое описание действий, необходимых для обеспечения штатного функционирования системы. Далее информация изменяется и уточняется, а в завершение пополняется сведениями об исключительных ситуациях вида "что произойдет, если...".

Описание потока событий для варианта использования системы содержится в документе вида Use Case Specification ("спецификация варианта использования"). Для создания подобного документа в каждом проекте должен применяться некий стандартный шаблон. Мы прибегнем к помощи шаблона, заимствованного из регламента Rational Unified Process.

2.2.Альтернативные потоки
2.2.x. Альтернативный поток х>
3.0. Специальные требования
З.х. <Специальное требование х>
4.0. Предусловия

Ниже приведен полный текст спецификации одного из вариантов использования системы учета университетских курсов.

Спецификация варианта использования "выбор курсов профессором"

1.0 Наименование варианта использования: "выбор курсов профессором".

1.1. Краткое описание: вариант использования инициируется активным субъектом
"профессор" и предлагает возможности выбора до четырех курсов, которые должны вестись
в определенном семестре.

Функции варианта использования начинают выполняться с регистрацией субъекта "профессор" в системе и заданием его индивидуального пароля. Система проверяет пароль на достоверность (если пароль неверен, активизируется альтернативный поток 2.2.1), позволяет профессору выбрать текущий либо будущий семестр (при неправильном задании семестра выполняется поток 2.2.2) и предлагает указать одну из следующих опций: "добавление", "уда.1ение", "просмотр", "печать "и "выход".

Если выбрана опция "добавление", система отображает окно с палями ввода наименования и номера курса. Профессор вводит наименование и номер курса (при задании неверной информации выполняется поток 2.2.3). Система воспроизводит текст с предложением на ведение курса (или наименование курса не может быть отображено, выполняется поток 2.2.4), и профессор подтверждает свой выбор. Система связывает текущий субъект "профессор" с указанным курсом (если связь не может быть создана, выполняется поток 2.2.5). Вариант использования активизируется сначала.

Если выбрана опция "удаление", система отображает окно с полями ввода наименования и номера ранее предложенного профессором курса. Профессор вводит наименование и номер курса (при задании неверной информации выполняется поток 2.2.3). Система удаляет связь между курсом и текущим субъектом "профессор" (если связь удалить нельзя, выполняется поток 2.2.6). Вариант использования активизируется сначала.

Если выбрана опция "просмотр", система извлекает и отображает следующую информацию обо всех предложениях на ведение курсов, поданных текущим субъектом "профессор" (если данные получить нельзя, выполняется поток 2.2.7): наименование и номер курса, номер предложения, а также время и место проведения занятий. По завершении просмотра вариант использования активизируется сначала.

Если выбрана опция "печать", система посылает на принтер расписание занятий, проводимых текущим субъектом "профессор" (если расписание не может быть распечатано, выполняется поток 2.2.8). Вариант использования активизируется сначала.

Если выбрана опция "выход", выполнение функций, предусмотренных вариантом использования системы, завершается.

2.2.1.Неверный пароль: введен неверный пароль; субъекту предоставляется возможность
повторить ввод или завершить вариант использования.

2.2.2.Неверный семестр: система сообщает субъекту о неверном вводе информации о семестре и предлагает повторить операцию или завершить вариант использования.

2.2.3.Неверная комбинация наименования и номера курса: система сообщает субъекту
о неверном вводе информации о наименовании и номере курса и предлагает повторить операцию или завершить вариант использования.

2.2.4. Ошибка воспроизведения текста с предложением на ведение курса: система сообщает субъекту о том, что в данный момент запрошенный курс не доступен; вариант использования активизируется сначала.

2.2.5. Ошибка создания связи между субъектом и выбранным им курсом: информация сохранена, система создаст связь позже; вариант использования активизируется сначала.

2.2.6. Ошибка удаления связи между субъектом и выбранным им курсом: информация сохранена, система удалить связь позже; вариант использования активизируется сначала.

2.2.7. Ошибка извлечения данных о предложениях на ведение курсов: система сообщает субъекту о том, что в данный момент информация не доступна; вариант использования активизируется сначала.

2.2.8. Ошибка печати расписания занятий: система сообщает субъекту о том, что в данный момент функция не доступна; вариант использования активизируется сначала.

3.0 Специальные требования: специальные требования не определены.

4.1. Перед активизацией варианта использования должен быть выполнен поток варианта использования «сохранение информации о курсах».

5.0. Постусловия: постусловия не определены.

6.0. Дополнительные значения: дополнительных замечаний нет.

Текст спецификации сохраняется в документе, внешнем по отношению к инструментальной системе Rational Rose, и ассоциируется с вариантом использования посредством связи.

Как связать документ спецификации потока событий с вариантом использования.

1. расположить курсор мыши над элементом окна Browser, соответствующим требуемому варианту использования, и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.

3. Перейти на вкладку Files диалогового окна Use Case Specification.

4. Расположить курсор мыши в пределах области окна и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.

6. С помощью средств навигации диалогового окна Открытие файла проследовать к нужной папке и выбрать требуемый файл.

Результат связывания документа спецификации с вариантом использования отображается в окне Browser.

Документ вида Use Case Specification может быть создан также в рамках проекта форма Rational Requisite Pro, а затем связан с вариантом использования в модели Rational Rose. Чтобы присоединить документ Requisite Pro к варианту использования, первым делом надлежит ассоциировать модель Rational Rose с проектом Requisite Pro.

Между активным субъектом и вариантом использования системы допускается устанавливать связь ассоциации (association relationship), которая выполняет коммуникативную функцию, сообщая о взаимодействии субъекта с системой в рамках определенного варианта использования. Направление связи указывает, кто (субъект или система) является инициатором взаимодействия. Двунаправленная ассоциация представляется в модели в виде линии, соединяющей связываемые элементы. Возможность взаимодействия элементов только в одном направлении отображается с помощью стрелки.

Варианты использования могут соединяться связями зависимости (dependency relationships) двух типов –включающими (inclusive) и расширяющими (extensive). Многими вариантами использования нередко охватывается одно и то же подмножество функций системы, которое уместно вынести в отдельный вариант, а не включать в каждый базовый вариант. Включающей связью соединяются определенный вариант использования и любой другой вариант, который предполагает выполнение тех же функций. Например, каждый из вариантов использования системы учета университетских курсов предусматривает процедуру регистрации пользователя. Подобные функции целесообразно представить в виде отдельного одноименного варианта использования, к которому следует обращаться в модели с помощью стрелки, направленной от базового варианта к «включаемому».

Расширяющие связи применяются для описания

Þ поведения системы при возникновении нештатных ситуаций;

Þ различных потоков событий, инициируемых в зависимости от того, какие опции выбираются пользователем.

Примером может служить вариант использования системы управления конвейером, адресующий специальный «аварийный» вариант при возникновении технических неполадок. В системе учета университетских курсов дополнительные «расширяющие» варианты использования в данный момент не предусмотрены. Расширяющая связь отображается в модели с помощью стрелки, направленной от «расширяющего» варианта к базовому.

В UML поддерживается понятие стереотипа (stereotype), которое обеспечивает возможность создания новых элементов модели на основе базовых и позволяет определять минимальное множество символов, пополняемые с целью описания набора сущностей, имеющих смысл в контексте разрабатываемой системы. Стереотипы применяются для конструирования требуемых связей вариантов использования. Имена стереотипов заключаются в угловые кавычки («») и размещаются рядом со стрелками, описывающими связи. Ассоциация может быть снабжена меткой с именем стереотипа «communicate», подчеркивающей, что связь обладает коммуникативной функцией, хотя делать это вовсе не обязательно, поскольку ассоциация –единственный тип связей, которыми могут соединяться активные субъекты и варианты использования. Включающие и расширяющие связи, относятся к одной и той же категории связей зависимости и поэтому должны снабжаться соответствующими метками.

Диаграмма вариантов использования (use case diagram) –это графическое представление подмножеств активных субъектов, взаимодействующих с системой посредством тех или иных вариантов ее использования. При проектировании любой системы обычно конструируется основная диаграмма (Main Use Case Diagram), представляющая множество пользователей (активных субъектов) и ключевые функции (варианты использования) системы. При необходимости создаются и дополнительные диаграммы. Вот некоторые типичные примеры:

Þ диаграмма, представляющая все варианты использования, инициируемые определенным активным субъектом;

Þ диаграмма, изображающая варианты использования, подлежащие последовательной реализации;

Þ диаграмма, описывающая некоторый вариант использования и все его связи.

На рассматриваемой стадии процесса разработки системы нередко создаются и диаграммы действий(activities diagrams), отображающие динамические характеристики системы. Диаграммы действий воспроизводят поток функций управления, показывают, какие ветви процесса могут выполняться параллельно, и определяют альтернативные пути достижения целей. Диаграммы действий, конструируемые на начальных фазах жизненного цикла системы, представляют потоки, которые охватывают несколько вариантов использования или протекают на уровне определенного варианта. Позже, по мере детализации проекта, создаются и диаграммы действий, иллюстрирующие особенности реализации отдельных операций.

Элементами диаграммы действий служат собственно действия (activities), переходи (transitions) от одного действия к другому, точки принятия решений (decision points) и полосы синхронизации (synchronization bars). В UML для описания действия, перехода, точки принятия решения и полосы синхронизации применяются соответственно прямоугольник с округленными углами, направленная стрелка, ромб и отрезок утолщенной прямой (горизонтальный или вертикальный).

Действие (activity) описывает некоторый фрагмент поведения системы в контексте потока функций управления.

Элемент перехода (transition) применяется в диаграмме действий с целью обозначения направления передачи управления от одного действия к другому. Функция перехода обычно активизируется по завершении действия-источника.

В процессе моделирования поведения системы зачастую необходимо определить, в какие моменты и в каких точках поток управления претерпевает ветвление в зависимости от принимаемых системой или пользователем решений. Переход, который берет начало в точке принятия решения (decision point), содержит контролируемое условие(guard condition), определяющее направление ветвления. Точки принятия решений совместно с соответствующими контролируемыми условиями позволяют наглядно продемонстрировать возможные альтернативные пути протекания процесса функционированиясистемы.

Процесс функционирования системы зачастую содержит стадии, которые могут содержаться параллельно. Полосы синхронизации (synchronization bars), позволяют указать, какие действия допускают единовременное выполнение или подлежат логическому объединению. Возможны ситуации, когда полоса синхронизации снабжается несколькими входящими связями и единственной исходящей и наоборот.

Диаграмма действий может быть разделена на зоны (swimlanes), каждая из которых обычно связана с определенным активным субъектом, ответственным за выполнение соответствующего подмножества действий.

Для обозначения исходного (start) и завершающего (end) действий в диаграмме применяются специальные символы в виде круга и стилизованного кольца. Обычно поток управления содержит одно исходное и несколько завершающих действий, по одному на каждый из возможных альтернативных путей протекания процесса функционирования системы.

Характеристики поведения разрабатываемой системы фиксируется и документируются средствами модели, которая отображает функции (варианты использования) продукта, представляет окружение системы (множество активных субъектов) и определяет связи между вариантами использования и активными субъектами (диаграммы вариантов использования). Наиболее важной является коммуникативная составляющая модели, позволяющая группам разработчиков, заказчиков и конечных пользователей, обсуждающим свойства системы, говорить на одном языке.

Основные модели закладываются на начальной фазе процесса разработки, когда идентифицируется основные субъекты и варианты использования системы, а позже, на этапе планирования, модель развивается и пополняется.

Каждый из внешних активных субъектов отождествляется с чем –то или с кем –то, взаимодействующим с системой. Варианты использования позволяют моделировать диалог между активным субъектом и системой и отображают функции последней, предоставляемые в распоряжение субъекта.

С каждым вариантом использования связан определенный поток событий, происходящих по мере выполнения соответствующих функций системы. При описании потока событий определяется, что необходимо осуществить, и игнорируются аспекты того, как это делается: события воспроизводятся средствами языка предметной области, а не в терминах практической реализации функции. Диаграмма вариантов использования –это графическое представление подмножеств активных субъектов, взаимодействующих с системой посредством тех или иных вариантов ее использования.

Варианты использования могут соединяться связями зависимости двух типов включающими и расширяющими. Включающие связи применяются для отображения групп функций, охватываемых несколькими вариантами использования, а расширяющие связи служат для описания множеств необязательных функций, поведения системы при возникновении нештатных ситуаций и различных потоков событий, инициируемых в зависимости от того, какие опции выбираются пользователем.

Диаграммы действий отображают динамические характеристики системы: воспроизводят поток функций управления, показывают, какие ветви процесса могут выполняться параллельно, и определяют альтернативные пути достижения целей. Диаграммы действий, конструируемые на начальных фазах жизненного цикла системы, представляют потоки, которые охватывают несколько вариантов использования или протекают на уровне определенного варианта. Позже, по мере детализации проекта, создаются и диаграммы действий, иллюстрирующие особенности реализации отдельных операций.

Объект (object) служит представлением реальной или абстрактной сущности— соседского грузовика, персонального компьютера, химического процесса, банковской транзакции, кредитной истории вашего друга Васи Сидорчика или траектории полета баллистической ракеты.

Объект — это понятие, абстракция или нечто с явно оговоренными границами, смыслом и назначением контексте программного приложения. Каждый объект системы обладает тремя характеристиками — состоянием, поведением и идентификационным признаком.

Состояние (state) объекта— это одно из возможных сочетаний условий его существования. Состояние объекта определяется набором свойств -атрибутов (attributes) и связей c другими объектами и со временем обычно способно изменяться. Например, объект, представляющий предложение на ведение курса, поданное определенным активным субъектом "профессор" системы учета университетских курсов, может пребывать в одном из двух состояний — "открыт" и "закрыт". Пока количество студентов, выбравших курс, меньше 10, объект остается в состоянии "открыт". Как только на курс регистрируется десятый студент, объект "закрывается".

Характеристика поведения (behavior) охватывает функциональную сторону жизни объекта, определяет его реакцию на запросы со стороны других объектов и реализуется в виде набора операций. В системе учета университетских курсов поведение объекта предложения на ведение курса определяется двумя основными функциями — "зарегистрировать студента" и "отменить регистрацию студента".

Идентификационный признак (identity) задает свойство уникальности объекта— даже в том случае, если состояние последнего идентично состоянию других объектов. В системе учета курсов, например, могут существовать два объекта -"алгебра 101, раздел!" и "алгебра 101, раздел 2". Хотя оба

представляют предложения на ведение курсов, каждый отличается уникальным идентификационным признаком.

UML объект представляется в виде прямоугольника с подчеркнутой строкой текста, задающей имя объекта.

Класс (class) определяет группу объектов с общими свойствами (атрибутами), поведением (функциями), семантикой и связями с другими объектами. Класс можно трактовать как шаблон для создания объектов. Каждый объект является экземпляром некоторого класса, причем только одного. В качестве примера приведем определение класса "предложение курса", обладающего следующими характеристиками:

• атрибуты — "место проведения занятий", "время проведения занятий",
"наименование курса", "номер курса", "номер предложения";

• функции — "назначить место проведения занятий", "назначить время проведет
занятий", "зарегистрировать студента", "отменить регистрацию студента".

На роль экземпляров класса "предложение курса" могли бы претендовать такие объекты, как, скажем, "алгебра 101, раздел 1" и "алгебра 101, раздел 2", — каждому из них соответствуют определенный набор атрибутов и общие функциональные характеристики. Правильно сконструированный класс должен представлять одну и только одну абстракцию. Например, класс, предлагающий возможности сохранения информации о студенте наряду с функциями регистрации курсов, пройденных студентом на протяжении всего времени обучения, нельзя считать удачным, поскольку он охватывает две различные группы операций. Поэтому уместно было бы "расщепить" такой класс на два — "студент" и "курсы, пройденные студентом".

Для именования классов следует пользоваться терминами, принятыми в соответствующей предметной области. В качестве имени класса принято употреблять существительное единственного числа, наилучшим образом описывающее моделируемое понятие. Иногда уместно применить и сокращение, не забывая расшифровать его при документировании класса. Если аббревиатура допускает неоднозначную интерпретацию, надлежит применять соответствующую полную форму выражения.

Зачастую бывает сложно провести черту между объектами и классами. Почему "алгебра 101, раздел!"— это объект, а не класс? Что отличает его от сущности "алгебра 101, раздел 2"? Ответы на подобные вопросы, как правило, довольно субъективны. Впрочем, достаточно небольшого интеллектуального усилия, чтобы понять — структура и поведение указанных сущностей одинаковы. Речь идет о различных предложениях на ведение курсов. Помимо того, нетрудно предугадать, что в системе учета университетских курсов могут существовать и другие схожие объекты вида "музыка 101, раздел 1", "история 101, раздел 1", "история 101, раздел 2" и т.п. Все это естественным образом подводит нас к решению о создании класса Предложение Курса.

В UML класс изображается посредством прямоугольника, поделенного на зоны. В верхней зоне приводится имя класса, в средней задается его структура (список атрибутов), а ниже перечисляются функции, определяющие характеристики поведения.

1. Расположить курсор мыши над элементом Logical View окна Browser
и щелкнуть правой кнопкой, чтобы активизировать контекстное меню.

2. Выбрать элемент меню New=>Class; дерево, отображаемое в окне Browser,
пополнится элементом NewClass, соответствующим новому классу.

3. Выбрать элемент NewClass и изменить его название, введя требуемое
имя класса.

Прежде мы уже говорили о применении стереотипов при создании связей в диаграммах вариантов использования. Классам также отвечают определенные стереотипы, позволяющие создавать новые разновидности элементов моделируемой системы. К числу наиболее употребительных "стандартных" стереотипов классов относятся entity ("сущность"), boundary ("граница"), control ("управление"), utility("прикладной класс") и exception ("исключение").

На диаграммах названия стереотипов заключаются в угловые кавычки («») и располагаются над именами классов. Система Rational Rose позволяет ассоциировать со стереотипом определенную пиктограмму или выделять его тем или иным цветом. Примеры пиктограмм, предусмотренных в регламенте Rational Unified Process для обозначения стереотипов entity, boundary и control, показаны на рис. 4.4. Здесь же содержится образец символа класса, соответствующего стереотипу exception.

Строгой инструкции, которая предписывала бы способы отыскания абстракций, подходящих на роль классов, просто нет. Гради Буч (Grady Booch) по этому поводу однажды воскликнул: "Гм–м, трудное дельце!" В Rational Unified Process для разработки классов моделируемой системы предлагается обращать внимание на стереотипы классов сущностей, границ и управления. Указанное множество стереотипов позволяет аналитику и дизайнеру размежевать уровни предметной области, представления и управления системой.

Поскольку процесс проектирования отличается итеративным характером, множество классов системы на протяжении ее жизненного цикла изменяется и пополняется. Исходный набор классов-кандидатов редко совпадает с тем, члены которого в конечном итоге реализуются на практике.

Класс сущностей (entity class) моделирует структуру данных и поведение, отличающиеся стабильным характером. Класс подобного типа отражает качества сущности реального мира или применяется для выполнения внутренних функций системы. Классы сущностей обычно не зависят от окружения, т.е. не чувствительны к тому, каким образом внешние обстоятельства влияют на работу системы. Во многих случаях такие классы удается с успехом применять в нескольких различных приложениях.

Первый шаг состоит в разграничении сфер ответственности системы на основе результатов анализа потока событий, охватывающего определенные варианты использования. Классы сущностей обычно необходимы системе для поддержки функций, относящихся к той или иной сфере ответственности. Для описания определенной функции подойдет краткое выражение с именем существительным. Полученный список описаний подлежит фильтрации с целью удаления фрагментов, которые не относятся к предметной области, являются избыточными либо посвящены конкретным особенностям реализации.

Классы сущностей создаются, как правило, на фазе планирования. Их часто называют "предметными", поскольку они представляют абстракции понятий и вещей реального мира.

Классы границ (boundary classes) обслуживают процессы взаимодействия между системой и ее окружением, обеспечивая интерфейсы для пользователей и сторонних систем (т.е. активных субъектов). Такие классы образуют часть системы, которая непосредственно "общается" с внешним миром.

Для отыскания классов границ анализируется каждая пара вида "активный субъект/вариант использования". Классы границ, выбранные на этапе планирования, обычно отличаются низким уровнем детализации. В этот момент, например, целесообразно моделировать и документировать функции окна графического интерфейса, рассматриваемого в целом, не оговаривая особенности реализации его отдельных частей (кнопок, переключателей, опций и т.п.).

Требования, предъявляемые к элементам графического интерфейса пользователя, зачастую весьма неоднозначны. Хотя термины "дружественный интерфейс" или "гибкий интерфейс" употребляются повсеместно, о единодушии при их толковании говорить не приходится. Это как раз тот случай, когда весьма уместны подходы, связанные с коллективным обсуждением решений и созданием прототипов: потребитель получает возможность заранее "пощупать" будущую систему и прийти к осмысленному выводу о том, насколько в действительности "дружественны" предлагаемые интерфейсы. Затем найденные критерии "дружественности" закрепляются в виде структур и характеристик поведения классов границ. В процессе проектирования классы уточняются и "шлифуются" с учетом особенностей выбранных механизмов их реализации. Как упоминалось выше, классы границ используются и для моделирования способов взаимодействия разрабатываемой системы с другими системами.

Классы управления (control classes) находят применение при реализации характеристик поведения системы, присущих одному или нескольким вариантам использования, и координируют события, возникающие по мере функционирования системы в рамках этих вариантов. Класс управления можно воспринимать как абстракцию, отображающую динамику варианта использования системы. Классы управления обычно тесно "привязаны" к особенностям конкретного приложения.

На ранних стадиях жизненного цикла системы для каждой пары вида "активный субъект/вариант использования" создается по одному классу управления, на который возлагаются обязанности по контролю за потоком событий, происходящих по мере выполнения этого варианта.

Мнения по поводу целесообразности применения классов управления весьма разноречивы. Многие полагают, что подобные классы способствую<

Что будет с Землей, если ось ее сместится на 6666 км? Что будет с Землей? - задался я вопросом...

Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот...

ЧТО ПРОИСХОДИТ ВО ВЗРОСЛОЙ ЖИЗНИ? Если вы все еще «неправильно» связаны с матерью, вы избегаете отделения и независимого взрослого существования...

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: