Диаграммы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- стереотипы (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, развивающих этот стандарт».