Состав диаграммы Use Case

Диаграмма вариантов использования состоит из актеров, для которых система производит действие и собственно действия Use Case, которое описывает то, что актер хочет получить от системы. Актер обозначается значком человечка, а Use Case - овалом. Дополнительно в диаграммы могут быть добавлены комментарии.

Типы действующих лиц

Ответы на следующие вопросы позволят определить актеров, взаимодействующих с системой:

• кто взаимодействует с системой или использует систему;

• кто передает или принимает информацию в/из системы;

• кто является внешним по отношению к системе.

Каждый вариант использования показывает, как конкретный актер использует систему и в дальнейшем расширяется диаграммами состояний и последовательности действий.

Типы связей

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

• Простая ассоциация - отражается линией между актером и вариантом использования (без стрелки). Отражает связь актера и варианта использования. На рисунке между актером администратор и вариантом использования просматривать заказ.

• Направленная ассоциация - то же что и простая ассоциация, но показывает, что вариант использования инициализируется актером. Обозначается стрелкой.

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

• Расширение (extend) - показывает, что вариант использования расширяет базовую последовательность действий и вставляет собственную последовательность. При этом в отличие от типа отношений "включение" расширенная последовательность может осуществляться в зависимости от определенных условий. 

• Включение - показывает, что вариант использования включается в базовую последовательность и выполняется всегда (на рисунке не показан). 

9. Диаграммы классов. Аспекты использования. Компоненты. Стереотипы классов. Типы отношений.

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

Построение диаграмм классов можно рассматривать в следующих аспектах:

• концептуальная точка зрения — диаграмма классов описывает модель предметной области, в ней присутствуют только классы прикладных объектов;

• точка зрения спецификации — диаграмма классов применяется при проектировании информационных систем;

• точка зрения реализации — диаграмма классов содержит классы, используемые непосредственно в программном коде (при использовании объектно-ориентированных языков программирования).

Компоненты и типы отношений

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

• ассоциации (например, менеджер может вести несколько проектов),

• подтипы (работник является разновидностью личности).

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

Стереотип поведения – это механизм позволяющий разделить классы на категории.

Стереотипы классов

• граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Как правило, для каждой пары «действующее лицо - вариант использования» определяется один граничный класс. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации);

• классы сущностей (Entity) - представляют собой ключевые абстракции (понятия) разрабатываемой системы. Источники выявления классов-сущностей: ключевые абстракции, созданные в процессе архитектурного анализа, глоссарий, описание потоков событий вариантов использования;

• управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Могут отсутствовать в некоторых вариантах использования, ограничивающихся простыми манипуляциями с хранимыми данными. Как правило, для каждого варианта использования определяется один управляющий класс. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.