2. Реализация визуальной модели программной системы

2.1. Диаграмма вариантов использования

Диаграмма вариантов использования (use case diagram) определяет поведение системы с точки зрений пользователя. Диаграмма Use Case рассматривается как главное средство для первичного моде­лирования динамики системы, используется для выяснения требований к разра­батываемой системе, фиксирования этих требований в форме, которая позволит про­водить дальнейшую разработку [10], [11], [12]. Диаграммы вариантов использования часто называют диаграммами прецедентов.

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

Вершинами в диаграмме вариантов использования являются актеры и элементы Use Case. Актеры представляют внешний мир, нуждающийся в работе системы. Элементы Use Case представляют действия, выполняемые системой в интересах актеров.

Значение множественности (multiplicity) действующего лица показывает, сколько экземпляров конкретного действующего лица будет использоваться в системе. Абстрактным называется действующее лицо, не имеющее экземпляров. Иными словами, его множественность равна нулю.

Между актером и элементом Use Case возможен только один вид отношения ― отношение ассоциации (association relationship), отображающее их взаимодействие (см. рис. 2.1). Как и любая другая ассоциация, она может быть помечена именем, ролями, мощностью.

Рис. 2.1. Отношение ассоциации

Между актерами допустимо отношение обобщения (generalization relationship). Данное отношение является направленным (от потомка к предку) и указывает на факт специализации одних актеров относительно других (см. рис. 2.2). Экземпляр потомка может взаимодействовать с такими же разновидностями элементов Use Case, что и экземпляр предка.

Рис. 2.2. Отношение обобщения между актерами

Между элементами Use Case определены отношение обобщения и две разновид­ности отношения зависимости — включения и расширения.

Отношение обобщения (generalization relationship) фиксирует, что потомок наследует поведение предка (см. рис. 2.3). Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case, являющийся потомком, может замещать элемент Use Case, являющийся предком, в любом месте диаграммы.

Рис. 2.3. Отношение обобщения между вариантами использования

Отношение включения (include relationship) между двумя элементами Use Case означает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования (см. рис. 2.4). Включаемый элемент Use Case никогда не использует­ся самостоятельно — его конкретизация может быть только частью другого, базового элемента Use Case.

Рис. 2.4. Отношение включения между вариантами использования

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

Отношение расширения (extend relationship) между элементами Use Case означает, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования (см. рис. 2.5). Данное отношение включает в себя некоторое условие, которое должно быть выполнено для реализации расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязательного поведения.

Рис. 2.5. Отношение расширения между вариантами использования

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

Элемент Use Case описывает, что должна делать система, но не определяет, как она должна это делать. При моделировании это позволяет отделять внешнее пред­ставление системы от ее внутреннего представления.

Поведение элемента Use Case определяется потоком событий (flow of events). Начальное описа­ние выполняется в текстовой форме, прозрачной для пользователя системы. В по­токе событий выделяют:

• основной поток и альтернативные потоки поведения;

• как и когда начинает функционировать и заканчивается элемент Use Case;

• когда элемент Use Case взаимодействует с актерами;

• какими данными обмениваются актер и система.

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

В общем случае один элемент Use Case описывает набор последовательностей, в котором каждая последовательность представляет возможный поток событий. Каждая последовательность называется сценарием. Сценарий — конкретная последовательность действий, которая иллюстрирует поведение. Сценарии являются для элемента Use Case почти тем же, чем являются экземпляры для класса. Гово­рят, что сценарий — это экземпляр элемента Use Case.

Спецификация (описание) элемента Use Case — основной источник информации для выпол­нения анализа и проектирования системы. Очень важно, чтобы содержание спе­цификации было представлено в полной и конструктивной форме. В общем слу­чае спецификация включает главный поток, подпотоки и альтернативные потоки поведения.

Правила разработки диаграмм вариантов использования:

• Не моделируйте связи между действующими лицами. По определению актеры находятся вне сферы действия системы. Это означает, что связи между ними также не относятся к её компетенции.

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

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

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

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

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

В терминологии фирмы Rational Software Corp. кооперации называют реализациями элементов Use Case, и обозначения их весь­ма схожи (см. рис. 2.6).

Рис. 2.6. Вариант использования и его реализация

Обратите внимание на то, что связаны эти элементы отношением реализации: кооперация реализует конкретный элемент Use Case.

Кооперации содержат две составляющие — статическую (структурную) и дина­мическую (поведенческую).

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

Таким образом, кооперации представляют собой набор раз­нообразных диаграмм. Например, требования к информационной системе задаются множеством элементов Use Case, каждый из которых реализуется отдельной кооперацией. Все эти кооперации применяют одни и те же классы, но все же имеют разную функциональную организацию.

Параметризованные, то есть настраиваемые кооперации называют паттернами (об­разцами). Паттерн является решением типичной проблемы в определенном кон­тексте. Обозначение паттерна имеет вид, представленный на рис. 2.7.

Рис. 2.7. Обозначение паттерна

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

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

Упражнение

В новой модели системы Rational Rose создайте диаграмму вариантов использования для системы АТМ (Automated Teller Machine ― автоматический банкомат) (см. рис. 2.8).