Группирующие сущности

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

Пакет (Package) – механизм организации элементов (структурных, поведенческих и группирующих сущностей) модели в группы (рис. 4.5). В отличие от компонентов носят чисто концептуальный характер.

Рис. 4.5. - Графическое изображение пакета.

Аннотационные сущности

Аннотационные сущности (Summary things) представляют собой пояснительные символы объектной модели.

Примечание (Note) – символ для изображения комментариев или ограничений, присоединенных к элементу или группе элементов (рис. 4.6).

Рис. 4.6. - Графическое изображение примечания.

4.1.2. Отношения

Отношения – это символы, связывающие различные сущности. В языке определено четыре вида отношений: обобщение, ассоциация, зависимость и реализация.

Обобщение (Generalization) – отношение (потомок-родитель), при котором специализированный элемент (потомок) может быть подставлен вместо обобщенного элемента (родителя) (рис. 4.7). Потомок наследует структуру и поведение своего родителя.

Ассоциация (Association) – отношение связи (соединения) между объектами (рис. 4.7). На графическом изображении ассоциации могут присутствовать дополнительные обозначения кратности, ролей или меток.

Агрегирование – разновидность ассоциации, т.е. ассоциация между целым и его частями (рис. 4.7).

Композиция - такое отношение агрегирования, при котором часть является неотъемлемой составляющей целого (рис. 4.7).

Рис. 4.7. - Графическое изображение обобщения, ассоциации, агрегирования и композиции.

Зависимость (Dependency) – отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой (см. рис. 4.8).

Реализация (Realization) – отношение между элементами, при котором один элемент определяет «контракт», а другой гарантирует его выполнение (см. рис. 4.8). Используется между интерфейсами и реализующими их классами или компонентами, а также между прецедентами и реализующими их кооперациями.

Рис. 4.8. - Графическое изображение зависимости и реализации.

4.1.3. Диаграммы

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

Диаграмма вариантов использования/прецедентов (Use case diagram) – диаграмма поведения, показывающая функции моделируемой системы и ее связи с другими системами, т.е., в случае разработки программного обеспечения, требования пользователей. Диаграмма состоит из множества прецедентов, классов (акторов: пользователей или любых других внешних систем) и отношений между ними (рис. 4.9).

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

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

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

Связь типа «расширение» применяется в тех случаях, когда один вариант использования подобен другому, но несет несколько другую нагрузку и, в связи с этим, необходимо описать изменение в обычном поведении системы.

Связь типа «использование» применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования и нет смысла копировать его описание.

Диаграмма классов (Class diagram) – структурная диаграмма, показывающая структуру классов предметной области. Диаграмма состоит из классов, интерфейсов, коопераций и отношений между ними (рис. 4.10). Абстрактные классы, от которых не производятся экземпляры, помечаются курсивом.

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

Диаграмма объектов (Object diagram) – структурная диаграмма, показывающая объектную модель системы, состоящую из множества экземпляров классов (объектов) и отношений между ними.

Рис. 4.10. - Диаграмма классов.

Диаграмма взаимодействия – диаграмма поведения, показывающая взаимодействие нескольких объектов, например, в рамках одного варианта использования. Взаимодействия изображаются с помощью диаграммы последовательностей (Sequence diagram), подчеркивающей временную последовательность событий (рис. 4.11), или диаграммы кооперации (Collaboration diagram), подчеркивающей структурную организацию объектов, посылающих и принимающих сообщения (рис. 4.12).

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

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

Рис. 4.11. - Диаграмма последовательности.

Рис. 4.12. - Диаграмма кооперации.

Сообщения: 1 – открыть сейф; 2 – деньги в первый мешок; 3 – деньги во второй мешок; 4 – деньги в третий мешок.

Рис. 4.13. - Диаграмма деятельности (активности).

Диаграмма компонентов (Component diagram) – диаграмма, показывающая организацию совокупности компонент (файлов) и их зависимости.

Диаграмма развертывания (Deployment diagram) – диаграмма, показывающая узлы и отношения между ними (физическое размещение компонент в аппаратных средствах).

Применение языка UML существенно облегчается за счет следующих механизмов:

• спецификаций (specifications) – текстовых описаний синтаксиса и семантики соответствующих элементов модели (диаграммы);

• принятых делений (common divisions) – в соответствии с дихотомией «класс/объект» и дихотомией «интерфейс/реализация»;

• механизмов расширения (extensibility mechanisms) – обеспечивающих расширение синтаксиса и семантики языка.

Предусмотрены следующие механизмы расширения языка:

• стереотипы (stereotypes), позволяющие расширять словарь языка и представлять на основе существующих элементов новые специфичные для конкретных проблем элементы модели;

• помеченные значения (tagged values), позволяющие расширять свойства элементов языка и представлять новые атрибуты и новую информацию в спецификацию элемента;

• ограничения (constraint), позволяющие расширять семантику элементов языка и определить новые или изменить старые правила.

UML не зависит от процесса его использования или метода моделирования. Однако, лучше всего он поддерживает Рациональный Унифицированный Процесс (Rational Unified Process – RUP) изготовления программных продуктов.

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

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

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

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

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

Консорциум OMG начал разрабатывать UML 2.0, чтобы преодолеть существенные недостатки ранних версий. В число проблем, которые пытаются решить архитекторы стандарта UML 2.0, входит проблема разбухания ранних версий и недостатки в определении семантики. В процессе работы над новым стандартом возникла необходимость включить в него поддержку разработки на базе моделей (Model-Driven Development – MDD) и, в частности, подхода к такой разработке с позиций архитектуры на базе моделей (Model-Driven Architecture – MDA). В результате стандартизации языка моделирования общественными усилиями был разработан очень громоздкий и сложный вариант стандарта. По мнению известных экспертов [106, с. 34] «Кажется, конечный результат полностью противоречит благим намерениям, породившим радикальный пересмотр стандарта. Многочисленные концепции моделирования, плохо определенная семантика и облегченные механизмы расширения UML 2.0 затрудняют его изучение и применение в MDD» ... «Язык UML 2.0 в некоторых отношениях превосходит предыдущие версии, но его громоздкость и сложность могут создать проблемы для пользователей, разработчиков инструментальных средств и рабочих групп OMG, развивающих этот стандарт».