Основные компоненты языка UML. Унифицированный процесс проектирования. Состав моделей

UML — это язык для визуализации, специфицирования, конструирования и документирования артефактов программных систем.

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

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

Язык UML предназначен прежде всего для разработки программных систем. Его использование особенно эффективно в следующих областях:

• информационные системы масштаба предприятия;
• банковские и финансовые услуги;
• телекоммуникации;
• транспорт;
• оборонная промышленность, авиация и космонавтика;
• розничная торговля;
• медицинская электроника;
• наука;
• распределенные Web-системы.

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

Унифицированный процесс проектирования осуществляется поэтапно. Проект должен расти инкрементно.

Модели:

1. Вариантов использования

2. Анализа

3. Проектирования

4. Реализации

5. Тестирования

Шаги повторяются до достижения конечного результата.

Общая структура (4 основные компонента) – <рисунок>

Сложная модель должна включать 2 аспекта: статический и динамический.

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

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

• Диаграмма вариантов использования (use case diagram)
• Диаграмма классов (class diagram)
• Диаграммы поведения (behavior diagrams)
• Диаграмма состояний (statechart diagram)
• Диаграмма деятельности (activity diagram)
• Диаграммы взаимодействия (interaction diagrams)
• Диаграмма последовательности (sequence diagram)
• Диаграмма кооперации (collaboration diagram)
• Диаграммы реализации (implementation diagrams)
• Диаграмма компонентов (component diagram)
• Диаграмма развертывания (deployment diagram)

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

1. Диаграмма вариантов использования
2. Диаграмма классов
3. Диаграмма состояний
4. Диаграмма деятельности
5. Диаграмма последовательности
6. Диаграмма кооперации
7. Диаграмма компонентов
8. Диаграмма развертывания

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

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

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

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

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

Основная цель: в визуальной и наглядной форме отобразить функциональность системы для обсуждения с заказчиком и для дальнейшей работы системы.

Обычно она является первым этапом построения диаграмм.

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

Разработка диаграммы вариантов использования преследует цели:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

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

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

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

Модель вариантов использования реализует иерархический подход

(концептуальный->логический->физический->)

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде множества сущностей или актеров, взаимодействующих с системой с помощью так называемых вариантов использования. При этом актером (actor) или действующим лицом называется любая сущность, взаимодействующая с системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая может служить источником воздействия на моделируемую систему так, как определит сам разработчик. В свою очередь, вариант использования (use case) служит для описания сервисов, которые система предоставляет актеру. Другими словами, каждый вариант использования определяет некоторый набор действий, совершаемый системой при диалоге с актером.

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

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

Множество вариантов использования в целом должно определять все возможные стороны ожидаемого поведения системы.

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

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

Связь – ассоциация – частный вид зависимости, который предполагает связь экземпляр-экземпляр.

Ассоциации могут быть направленными navigable (навигационный)

Как правило, большинство ассоциаций двунаправлены (бинарны). (если стрелка не нарисована, то двунаправленны)

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: