Б4 Универсальный язык моделирования UML

Результатом проектирования системы является ее модель. Процесс создания модели называется моделированием (modeling).

Универсальный язык моделирования UML (Unified Modelling Language) представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. Этот язык вобрал в себя наилучшие качества методов программной инженерии, которые с успехом использовались на протяжении последних лет при моделировании больших и сложных систем.

Язык UML основан на некотором числе базовых понятий, которые могут быть изучены и применены большинством программистов и разработчиков, знакомых с методами объектно-ориентированного анализа и проектирования.

Основными элементами UML являются сущности (Thing), отношения (Relationship), диаграммы (Diagram). Сущности являются ключевыми абстракциями языка, отношения связывают сущности вместе, диаграммы группируют коллекции сущностей, которые представляют интерес.

Структурные сущности являются существительными языка UML. К ним относятся:

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

- интерфейсы (Interface) – это набор операций, которые определяют сервис класса или компоненты. Интерфейс графически изображается в виде круга и, как правило, присоединяется к классу или к компоненту, который реализует данный интерфейс;

- кооперации/коммуникации (Collaboration) – определяют взаимодействие и служат для объединения ролей и других элементов, которые взаимодействуют вместе так, что получающееся в результате поведение объекта оказывается большим, чем просто сумма всех элементов. Изображается в виде эллипса с пунктирной границей;

- прецеденты, варианты использования (Use case) – описание набора последовательностей действий, которые выполняются системой и имеют значение для конкретного действующего лица (Actor). Прецеденты изображаются в виде эллипса и используются для структурирования поведенческих сущностей в модели;

- активные классы (Active class) – это классы, чьими экземплярами являются активные объекты, которые владеют процессом или потоком управления и могут инициировать управляющее воздействие. Стереотипами конкретного класса являются процесс (Process) и поток (Thread). Графически такой класс изображается как класс с жирной границей;

- компоненты (Component) – это физически заменяемые части системы, обеспечивающие реализацию ряда интерфейсов. Компонент – это физическое представление таких логических элементов, как классы, интерфейсы и кооперации. Предметная область компонентов относится к реализации. Изображаются компоненты в виде прямоугольника с ярлыками слева и, как правило, имеют только имя и примечание;

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

Данные перечисленных семи типов объектов являются базовыми структурными объектами UML. Существуют также вариации данных объектов, такие как действующие лица, субъекты (Actor), сигналы (Signal), утилиты (Utility – вид класса), процессы и нити (Process и Thread – виды активного класса), приложения (Application), документы (document), файлы (File), библиотеки (Library), страницы (Page), таблицы (Table).

Поведенческие сущности– это динамические части моделей UML. К ним относятся:

- взаимодействия (Interaction) – включают набор сообщений, которыми обмениваются указанные объекты с целью достижения указанной цели. Взаимодействие описывается в контексте кооперации и изображается направленной линией, маркируется именем операции сверху;

- автоматы (State machine) – спецификации поведения, представляющие собой последовательности состояний, через которые проходит в течение своей жизни объект, или взаимодействие в ответ на происходящие события (а также ответные действия объекта на эти события). Автомат прикреплен к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров. Изображается автомат как прямоугольник с закругленными углами.

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

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

К базовым отношениям между объектами, которые позволяют строить блоки UML, можно отнести следующие (рисунок Б4.1):

Рисунок Б4.1 – Отношения UML

- зависимость (Dependency) – это семантическое отношение между двумя сущностями, при котором изменение одной из них (независимой сущности) может отразиться на семантике другой (зависимой). Виды зависимостей, которые соответствуют нескольким видам отношений между объектами, перечислены ниже:

- абстракция (Abstraction) – представляет собой изменение уровня абстрактности для некоторого понятия. Как правило, один из элементов, более абстрактный, а второй – более конкретный, хотя возможны ситуации, когда оба элемента являются двумя возможными вариантами понятия, существующими на одном уровне абстракции. К зависимости абстракции относятся следующие стереотипы (в порядке возрастания специфичности отношений): трассировать (Trace), уточнять (Refine), реализовать (есть собственная нотация) и выводить (Derive),

- связывание (Binding) – связывает элемент с шаблоном. Аргументы, необходимые для параметров шаблона, прикреплены к зависимости связывания в виде списка,

- комбинирование (Combination) – соотносит две части описания классификатора (любой элемент модели, описывающий определенные черты структуры и поведения системы), чтобы получить полное описание элемента,

- разрешение (Permission) – зависимость (всегда изображается в виде особого стереотипа), связывающая тот или иной пакет (или класс) с другим пакетом (или классом), которому он предоставляет разрешение использовать свое содержимое. Стереотипами зависимости разрешения являются: быть доступным (Access), быть дружественным (Friend) и импортировать (Import),

- использование (Usage) – описывает ситуацию, когда одному элементу для правильной реализации или функционирования требуется присутствие другого элемента. К стереотипам этого вида зависимости относятся: вызывать (Call), создать экземпляр (Instantiate), параметр (Parameter) и отправить (Send);

- ассоциация (Association) – структурное отношение, описывающее множество связей между объектами классификаторов, где связь (Link) – это соединение между объектами, которое описывает связи между их экземплярами. Ассоциации являются как бы клеем, который связывает систему воедино. Без ассоциаций мы имели бы просто некоторое количество классов, не способных взаимодействовать друг с другом. У ассоциации может быть имя, однако основную информацию об ассоциации следует искать у ее полюсов, где описывается, каким образом каждый объект участвует в ассоциации: у ассоциации есть список, состоящий из двух или более полюсов ассоциации: каждый из них определяет роль, которую играет данный классификатор в этой ассоциации. Один и тот же классификатор может играть несколько ролей, которые не являются взаимозаменяемыми. Каждый полюс ассоциации описывает свойства, применимые к конкретному объекту этой ассоциации, например, сколько раз один объект может появляться в связях (множественность). Некоторые свойства (такие как допустимость навигации) применимы только к бинарным ассоциациям, хотя большинство свойств относится и к бинарным, и к n-арным ассоциациям;

- обобщение(Generalization) – это отношение специализации/обобщения, при котором объекты специализированного элемента (потомка – Child) можно подставить вместо объектов обобщенного элемента (родителя, предка – Parent). В случае обобщения классов прямой предок может именоваться суперклассом, а прямой потомок – подклассом;

- реализация (Realization) – отношение между спецификацией и ее программной реализацией; указание на то, что поведение наследуется без структуры.

Мы перечислили четыре основных отношения. В UML также существуют их варианты: уточнение (Refinement), трассировка (Trace), включение (Include), расширение (Extend).

Визуализация представления проектируемой системы с различных точек зрения в UML реализована посредством диаграмм – проекций системы.

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

Рисунок Б4.2 – Диаграммы UML

Чаще всего UML рассматривает разрабатываемую систему с пяти взаимосвязанных точек зрения (рисунок Б4.3).

Рисунок Б4.3 – Моделирование архитектуры системы

Представление с точки зрения вариантов использования (Use case view) включает пользовательские истории, описывающие систему с точки зрения конечного пользователя, аналитика, тестера. Это представление не определяет структуру программного обеспечения, а существует для передачи общего представления о системе. В UML это отображается посредством диаграмм вариантов использования (Use case diagram), динамический аспект представлен в диаграммах взаимодействий (Interaction diagram), состояний (Statechart diagram), активности (Activity diagram).

Представление с точки зрения дизайна (Design view) включает классы, интерфейсы и кооперации, которые формируют словарь задачи и ее решение. Данное представление в первую очередь осуществляет поддержку функциональных требований к системе, значение сервисов, которые система должна предоставить конечному пользователю. В UML это отображается посредством диаграмм классов (Class diagram) и объектов (Object diagram), динамический аспект отображается в диаграммах взаимодействий, состояний, активности.

Представление с точки зрения процессов (Process view) включает нити и процессы, которые формируют параллельную обработку и синхронизацию в системе. Данное представление в первую очередь относится к производительности, масштабируемости и пропускной способности системы. В UML статический и динамический аспекты отображаются теми же диаграммами, что и в Design view, но внимание акцентируется на активных классах, представляющих процессы и нити.

Представление с точки зрения реализации (Implementation view) включает компоненты и файлы, используемые при сборке системы. Подобное представление в первую очередь относится к управлению конфигурациями (Configuration management) релизов продукта. Статический аспект в UML отображен диаграммой компонентов (Component diagram), а динамический – диаграммами взаимодействий, состояний, активности.

Представление с точки зрения внедрения (Deployment view) включает узлы и их взаимодействие – они определяют аппаратную топологию, на которой выполняется программное обеспечение. Это представление в первую очередь относится к распространению, доставке, установке компонентов, из которых строится физическая система. Статический аспект в UML отображается диаграммой внедрения (Deployment diagram), а динамический – диаграммами взаимодействий, состояний, активности.

Ниже приведены определения и примеры диаграмм:

- диаграмма классов (Class diagram) – структурная диаграмма, на которой показано множество классов, интерфейсов, коопераций и отношений между ними (рисунок Б4.4);

- диаграмма объектов (Object diagram) – структурная диаграмма, на которой показано множество объектов и отношений между ними. Ее можно считать особым случаем диаграммы классов. Инструментам моделирования не нужно поддерживать отдельный формат для диаграмм объектов. На них изображены объекты, поэтому диаграмма классов, на которой нет классов, но есть принадлежащие им объекты, может считаться диаграммой объектов;

- диаграмма вариантов использования, прецедентов, (Use case diagram) – диаграмма поведения, на которой показано множество вариантов использования и действующих лиц, а также отношений между ними (рисунок Б4.5);

- диаграммы взаимодействий (Interaction diagram):

- диаграмма последовательностей (Sequence diagram) – диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий (рисунок Б4.6);

- диаграмма кооперации/коммуникации (Collaboration diagram) – диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения;

Рисунок Б4.4 – Диаграмма классов

Рисунок Б4.5 – Диаграмма вариантов использования

Рисунок Б4.6 – Диаграмма последовательностей

- диаграмма состояний (Statechart diagram) – диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий;

- диаграмма активности (Activity diagram) – диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой (рисунок Б4.7);

- диаграмма компонентов (Component diagram) – диаграмма, на которой изображена организация некоторого множества компонентов и зависимости между ними, – относится к статистическому виду системы (рисунки Б4.8, Б4.9);

- диаграмма топологии системы (Deployment diagram) – структурная диаграмма, на которой показаны узлы и отношения между ними.

Рисунок Б4.7 – Диаграмма активности

Рисунок Б4.8 – Пиктограммы компонентов

Рисунок Б4.9 – Примеры диаграммы компонентов