Вы находитесь на странице: 1из 75

ОГЛАВЛЕНИЕ

1. Основные этапы развития UML..................................................................................................................3


2. Основные компоненты языка UML............................................................................................................5
2.1. Общая структура языка UML...............................................................................................................7
2.2. Специфика языка UML.........................................................................................................................8
2.2.1. UML - это язык визуализации.......................................................................................................9
2.2.2. UML - это язык специфицирования..............................................................................................9
2.2.3. UML - это язык конструирования................................................................................................9
2.2.4. UML - это язык документирования............................................................................................10
2.3. Сущности UML....................................................................................................................................11
2.4. Отношения UML.................................................................................................................................14
2.5. Диаграммы UML.................................................................................................................................16
3. Диаграмма вариантов использования (use case di agram).......................................................................17
3.1. Вариант использования.......................................................................................................................18
3.2. Актеры..................................................................................................................................................18
3.3. Интерфейсы..........................................................................................................................................19
3.4. Отношения на диаграмме вариантов использования.......................................................................20
3.4.1. Отношение ас социации..............................................................................................................21
3.4.2. Отношение расширения..............................................................................................................22
3.4.3. Отношение обобщения................................................................................................................23
3.4.4. Отношение включения.................................................................................................................24
3.5. Пример построения диаграммы вариантов использования.............................................................25
4. Диаграмма последовательности (sequence diagram)...............................................................................27
4.1. Объекты................................................................................................................................................27
4.1.1. Линия жизни объекта..................................................................................................................28
4.1.2. Фокус управления..........................................................................................................................29
4.2. Сообщения...........................................................................................................................................29
4.2.1. Стереотипы сообщений..............................................................................................................29
4.2.2. Временные ограничения на диаграммах последовательности................................................30
4.3. Пример построения диаграммы последовательности.....................................................................31
5. Диаграмма кооперации (collaboration diagram)........................................................................................31
5.1. Объекты................................................................................................................................................32
5.2. Связи.....................................................................................................................................................35
5.3. Кооперация...........................................................................................................................................36
5.4. Диаграмма кооперации уровня спецификации.................................................................................37
5.5. Пример построения диаграммы кооперации....................................................................................38
6. Диаграмма классов (class diagram)............................................................................................................39
6.1. Класс.....................................................................................................................................................40
6.1.1. Имя класса.....................................................................................................................................40
6.1.2. Атрибуты класса.........................................................................................................................41
6.1.3. Операция........................................................................................................................................43
6.2. Отношения между классами...............................................................................................................44
6.2.1. Отношение зависимости.............................................................................................................44
6.2.2. Отношение ассоциации...............................................................................................................45
6.2.3. Отношение агрегации..................................................................................................................46
6.2.4. Отношение композиции...............................................................................................................46
6.2.5. Отношение обобщения................................................................................................................47
6.3. Интерфейсы..........................................................................................................................................48
6.4. Объекты................................................................................................................................................48
7. Диаграмма состояний (statechart diagram)................................................................................................49
7.1. Автоматы..............................................................................................................................................49
7.2. Состояние.............................................................................................................................................50
7.2.1. Имя состояния..............................................................................................................................51
7.2.2. Начальное состояние...................................................................................................................51
7.2.3. Конечное состояние.....................................................................................................................51
7.3. Переход.................................................................................................................................................52
7.3.1. Событие........................................................................................................................................52
7.3.2. Сторожевое условие....................................................................................................................53
7.3.3. Выражение действия...................................................................................................................54
7.4. Составное состояние и подсостояние................................................................................................54
7.4.1. Последовательные подсостояния..............................................................................................55
7.4.2. Параллельные подсостояния.......................................................................................................56
8. Диаграмма деятельности (activity diagram)..............................................................................................58
8.1. Состояние действия.............................................................................................................................58
8.2. Переходы..............................................................................................................................................59
8.3. Дорожки................................................................................................................................................61
8.4. Объекты................................................................................................................................................63
9. Диаграмма компонентов (component diagram).........................................................................................64
9.1. Компоненты..........................................................................................................................................64
9.1.1. Имя компонента...........................................................................................................................65
9.1.2. Виды компонентов.......................................................................................................................65
9.2. Интерфейсы..........................................................................................................................................66
9.3. Зависимости.........................................................................................................................................67
10. Диаграмма развертывания (deployment diagram)...................................................................................70
10.1. Узел.....................................................................................................................................................71
10.2. Соединения........................................................................................................................................72

2
1. Основные этапы развития UML
Отдельные языки объектно-ориентированного моделирования стали появляться в период между
серединой 1970-х и концом 1980-х годов, когда различные исследователи и программисты предлагали
свои подходы к объектно-ориентированнному анализу и проектирования (ООАП). В период между
1989-1994 гг. общее число наиболее известных языков моделирования возросло с 10 до более чем 50.
Многие пользователи испытывали серьезные затруднения при выборе языка ООАП, поскольку ни
один из них не удовлетворял всем требованиям, предъявляемым к построению моделей сложных
систем. Принятие отдельных методик и графических нотаций в качестве стандартов (IDEF0, IDEF1X)
не смогло изменить сложившуюся ситуацию непримиримой конкуренции между ними в начале 90-х
годов.

К середине 1990-х некоторые из методов были существенно улучшены и приобрели


самостоятельное значение при решении различных задач ООАП. Наиболее известными в этот период
становятся:

 Метод Гради Буча (Grady Booch), получивший условное название Booch или Booch'91, Booch
Lite (позже - Booch'93).
 Метод Джеймса Румбаха (James Rumbaugh), получивший название Object Modeling Technique -
ОМТ (позже - ОМТ-2).
 Метод Айвара Джекобсона (Ivar Jacobson), получивший название Object-Oriented Software
Engineering - OOSE.

Каждый из этих методов был ориентирован на поддержку отдельных этапов ООАП. Например,
метод OOSE содержал средства представления вариантов использования, которые имеют
существенное значение на этапе анализа требований в процессе проектирования бизнес-приложений.
Метод ОМТ-2 наиболее подходил для анализа процессов обработки данных в информационных
системах. Метод Booch'93 нашел наибольшее применение на этапах проектирования и разработки
различных программных систем.

История развития языка UML берет начало с октября 1994 года, когда Гради Буч и Джеймс
Румбах из Rational Software Corporation начали работу по унификации методов Booch и ОМТ. Хотя
сами по себе эти методы были достаточно популярны, совместная работа была направлена на
изучение всех известных объектно-ориентированных методов с целью объединения их достоинств.
Проект так называемого унифицированного метода (Unified Method) версии 0.8 был подготовлен и
опубликован в октябре 1995 года. Осенью того же года к ним присоединился А. Джекобсон, главный
технолог из компании Objectory AB (Швеция), с целью интеграции своего метода OOSE с двумя
предыдущими.

Начиная работу по унификации своих методов, Г. Буч, Дж. Румбах и А. Джекобсон


сформулировали следующие требования к языку моделирования. Он должен:

 Позволять моделировать не только программное обеспечение, но и более широкие классы


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

3
Разработка системы обозначений или нотации для ООАП оказалась непохожей на разработку
нового языка программирования. Во-первых, необходимо было решить две проблемы:

1. Должна ли данная нотация включать в себя спецификацию требований?


2. Следует ли расширять данную нотацию до уровня языка визуального программирования?

Во-вторых, было необходимо найти удачный баланс между выразительностью и простотой языка.
С одной стороны, слишком простая нотация ограничивает круг потенциальных проблем, которые
могут быть решены с помощью соответствующей системы обозначений. С другой стороны, слишком
сложная нотация создает дополнительные трудности для ее изучения и применения аналитиками и
программистами. В случае унификации существующих методов необходимо учитывать интересы
специалистов, которые уже имеют опыт работы с ними, поскольку внесение серьезных изменений в
новую нотацию может повлечь за собой непонимание и неприятие ее пользователями прежних
методик. Чтобы исключить неявное сопротивление со стороны отдельных специалистов, необходимо
учитывать интересы самого широкого круга пользователей. Последующая работа над
унифицированным языком моделирования (Unified Modeling Language, UML) должна была учесть все
эти обстоятельства.

В этот период поддержка разработки языка UML становится одной из целей консорциума OMG
(Object Management Group). Хотя консорциум OMG был образован еще в 1989 году с целью
разработки предложений по стандартизации объектных и компонентных технологий CORBA, язык
UML приобрел статус второго стратегического направления в работе OMG. Именно в рамках OMG
создается команда разработчиков под руководством Ричарда Соли, которая будет обеспечивать
дальнейшую работу по унификации и стандартизации языка UML.

Усилия Г. Буча, Дж. Румбаха и А. Джекобсона привели к появлению первых документов,


содержащих описание собственно языка UML версии 0.9 (июнь 1996) и версии 0.91 (октябрь 1996).
Имевшие статус запроса предложений RTP (Request For Proposals), эти документы послужили
своеобразным катализатором для широкого обсуждения языка UML различными категориями
специалистов. Первые отзывы и реакция на язык UML указывали на необходимость его дополнения
отдельными понятиями и конструкциями.

Компания Rational Software вместе с несколькими организациями, изъявившими желание


выделить ресурсы для разработки строгого определения версии 1.0 языка UML, учредила консорциум
партнеров UML, в который первоначально вошли такие компании, как Digital Equipment Corp., HP, i-
Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и
Unisys. Эти компании обеспечили поддержку последующей работы по более точному и строгому
определению нотации, что привело к появлению версии 1.0 языка UML.

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


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

В настоящее время все вопросы дальнейшей разработки языка UML сконцентрированы в рамках
консорциума OMG. Соответствующая группа специалистов обеспечивает публикацию материалов,
содержащих описание последующих версий языка UML и запросов предложений RFP по его
стандартизации. Очередной этап развития данного языка закончился в марте 2004 года, когда
консорциумом OMG было опубликовано описание языка UML 2.0. История разработки и
последующего развития языка UML графически представлена на рис. 1.1.

4
Рис. 1.1. История развития языка UML

На основе технологии UML Microsoft, Rational Software и другие поставщики средств разработки
программных систем разработали единую информационную модель, которая получила название UML
Information Model. Предполагается, что эта модель даст возможность различным программам,
поддерживающим идеологию UML, обмениваться между собой компонентами и описаниями. Все это
позволит создать стандартный интерфейс между средствами разработки приложений и средствами
визуального моделирования.

Уже в настоящее время разработаны средства визуального программирования на основе UML,


обеспечивающие интеграцию, включая прямую и обратную генерацию кода программ, с наиболее
распространенными языками и средами программирования, такими как MS Visual C++, Java, C#,
Object Pascal/Delphi, Power Builder, MS Visual Basic, Forte, Ada, Smalltalk. Поскольку при разработке
языка UML были приняты во внимание многие передовые идеи и методы, можно ожидать, что на
очередные версии языка UML также окажут влияние и другие перспективные технологии и
концепции. Кроме того, на основе языка UML могут быть определены многие новые перспективные
методы. Язык UML может быть расширен без переопределения его ядра.

2. Основные компоненты языка UML


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

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

Конструктивное использование языка UML основывается на понимании общих принципов


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

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


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

Еще одним принципом прикладного системного анализа является принцип иерархического


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

Рис. 2.1. Общая схема взаимосвязей моделей и представлений сложной системы в процессе
ООАП

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

2.1. Общая структура языка UML


UML состоит из двух взаимодействующих частей, таких как:

 Семантика языка UML. Представляет собой некоторую метамодель, которая определяет


абстрактный синтаксис и семантику понятий объектного моделирования на языке UML.
 Нотация языка UML. Представляет собой графическую нотацию для визуального
представления семантики языка UML.

Абстрактный синтаксис и семантика языка UML описываются с использованием некоторого


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

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

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

Формальное описание самого языка UML основывается на некоторой общей иерархической


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

 Мета-метамодель
 Метамодель
 Модель
 Объекты пользователя

Уровень мета-метамодели образует исходную основу для всех метамодельных представлений.


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

7
Метамодель является экземпляром или конкретизацией мета-метамодели. Главная задача этого
уровня - определить язык для спецификации моделей. Данный уровень является более
конструктивным, чем предыдущий, поскольку обладает более развитой семантикой базовых понятий.
Все основные понятия языка UML - это понятия уровня метамодели. Примеры таких понятий - класс,
атрибут, операция, компонент, ассоциация и многие другие.

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

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

2.2. Специфика языка UML


UML является стандартным инструментом для создания документированных каркасов
("чертежей") программного обеспечения. UML - это язык для визуализации, специфицирования,
конструирования и документирования артефактов программных систем. Напомним что, артефакт
(artifact) - диаграмма, документ, модель, закон и т. д. - нечто, описывающее определенное понятие
предметной области. UML разработан таким образом, чтобы удовлетворять потребности при
моделировании любых систем: от информационных систем масштаба предприятия до
распределенных Web-приложений и даже встроенных систем реального времени. Это выразительный
язык, позволяющий рассмотреть систему со всех точек зрения, имеющих отношение к ее разработке
и последующему развертыванию. Несмотря на обилие выразительных возможностей, этот язык прост
для понимания и использования.

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

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

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

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

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

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

2.2.1. UML - это язык визуализации

Характерной особенностью мышления большинства программистов является то, что


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

А ведь даже в этих случаях программист занимается моделированием, хотя и неформально. И


такой подход чреват рядом неприятностей. Во-первых, обмениваться мнениями по поводу
построенной модели можно только тогда, когда все участники говорят на одном языке. А это
означает, что ваша компания не сможет принять великолепного программиста на C, если она
использует Delphi! Или вашему новичку будет совсем непросто догадаться, о чем идет речь. Во-
вторых, нельзя получить представление об некоторых аспектах программных систем без модели,
границы которой выходят за рамки текстового языка программирования. Например, назначение
иерархии классов можно, конечно, понять, если внимательно изучить код каждого класса, а вот
воспринять всю структуру сразу целиком ни за что не получится. Аналогично изучение кода системы
не позволит составить полное представление о физическом распределении и возможных миграциях
объектов в Web-приложении. В третьих, если ваш системный аналитик никогда не воплощал в явной
форме разработанные модели, эта информация будет навсегда утрачена, если его вдруг переманят в
конкурирующую фирму. В лучшем случае результаты его анализа можно будет только частично
воссоздать исходя из реализации.

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

2.2.2. UML - это язык специфицирования

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

2.2.3. UML - это язык конструирования

Хотя он и не является языком визуального программирования. Но модели, которые создаются с


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

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

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

2.2.4. UML - это язык документирования

Организация, серьезно работающая на рынке программных средств, кроме непосредственного


написания программного кода производит и некоторые другие артефакты, в том числе следующие:
 требования к системе;
 архитектуру;
 проект;
 исходный код;
 проектные планы и сметы;
 тесты;
 прототипы;
 версии и другие.

В зависимости от принятой методики разработки выполнение одних работ производится более


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

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


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

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

 информационные системы масштаба предприятия;


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

Сфера применения UML не ограничивается моделированием программного обеспечения. Его


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

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

Словарь UML включает три вида основных конструкций:

 сущности - абстракции, являющиеся основными элементами модели;


 отношения - связи между сущностями;
 диаграммы, группирующие представляющие интерес множества сущностей и отношений.

2.3. Сущности UML


В UML имеется четыре типа сущностей:

 структурные;
 поведенческие;
 группирующие;
 аннотационные.

Сущности являются основными объектно-ориентированными элементами языка. С их помощью


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

Класс (class) - это описание совокупности объектов с общими атрибутами, операциями


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

ClassName
-PrivateAttribute : char
#ProtectedAttribute
+PublicAttribute
+Operation1(S : String)
+Operation2()

Рис. 2.2. Пиктограмма класса

Интерфейс (interface) - это совокупность операций, которые определяют определенную службу


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

11
Рис. 2.3. Пиктограмма интерфейса

Кооперация (collaboration) определяет взаимодействие, она представляет собой совокупность


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

Рис. 2.4. Пиктограмма кооперации

Прецедент (use case) - это описание последовательности выполняемых системой действий,


которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor).
Графически прецедент тоже изображается в виде эллипса, только ограниченного непрерывной
линией, обычно содержащего только его имя, как показано на рис. 2.5.

Рис. 2.5. Пиктограмма прецедента

Активным классом (active class) называется класс, объекты которого вовлечены в один или
несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие.
Графически активный класс изображается также как и простой класс, но ограничивается
прямоугольником, который рисуется жирной линией, и включает имя, атрибуты и операции, пример
на рис. 2.6.

ClassName
-PrivateAttribute:char
#ProtectedAttribute
+PublicAttribute
+Operation1(int S:String)
+Operation2()

Рис. 2.6. Пиктограмма активного класса

Компонент (component) - это физическая заменяемая часть системы, которая соответствует


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

Рис. 2.7. Пиктограмма компонента

Узел (node) - это элемент реальной (физической) системы, который существует во время
функционирования программного продукта и представляет собой некоторый вычислительный ресурс,
обычно обладающий как минимум некоторым объемом памяти, а часто еще и возможностью

12
обработки. Графически для изображения узла используется куб, обычно содержащий только имя
узла, пример на рис. 2.8.

Рис. 2.8. Пиктограмма узла

Перечисленные семь базовых элементов: классы, интерфейсы, кооперации, прецеденты, активные


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

Поведенческие сущности (behavioral things) являются динамическими составляющими модели


UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве.
Существует всего два основных типа поведенческих сущностей.

Взаимодействие (interaction) - это поведение, суть которого заключается в обмене сообщениями


(messages) между объектами в рамках конкретного контекста для достижения определенной цели. С
помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности
объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения,
последовательности действий (поведение, инициированное сообщениями) и связи (между
объектами). Графически сообщение изображается в виде стрелки. Над которой почти всегда пишется
имя соответствующей операции, как показано на рис. 2.9.

Рис. 2.9. Пиктограмма сообщения

Автомат (state machine) - алгоритм поведения, определяющий последовательность состояний,


через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ
на различные события, а также реакции на эти события. С помощью автоматов описываются
поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов:
состояния, переходы из одного состояния в другое, события - сущности инициирующие переходы и
виды действий - реакция на переходы. Графически состояние изображается в виде прямоугольника с
закругленными углами, содержащего имя и, возможно, промежуточные состояния, пример на рис.
2.10.

Рис. 2.10. Пиктограмма состояния

Взаимодействия и автоматы являются основными поведенческими сущностями, входящими в


модель UML. Семантически они часто бывают связаны с различными структурными элементами, в
первую очередь с классами, кооперациями и объектами.

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые
можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

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

Рис. 2.11. Пиктограмма пакета

Аннотационные сущности - пояснительные части модели UML. Это комментарии для


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

Примечание (note) - это просто символ для изображения комментариев или ограничений,
присоединенный к элементу или группе элементов. Графически примечание изображается в виде
прямоугольника с загнутым краем, содержащим текстовый или графический комментарий, как
показано на рис. 2.12.

Рис. 2.12. Пиктограмма примечания

Этот элемент является основной аннотационной сущностью, которую мы можем использовать в


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

2.4. Отношения UML


В языке UML определены четыре типа отношений:

 Отношение зависимости (dependency relationship)


 Отношение ассоциации (association relationship)
 Отношение обобщения (generalization relationship)
 Отношение реализации (realization relationship)

Эти отношения являются основными связующими конструкциями в UML и применяются для


построения корректных моделей.

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при


котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.
Графически для изображения зависимости используют пунктирную линию, обычно со стрелкой,
которая может содержать метку (см. рис. 2.13).

14
Рис. 2.13. Пиктограмма зависимости

Ассоциация (association) - структурное отношение, описывающее совокупность связей, где под


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

Рис. 2.14. Пиктограмма ассоциации

Специальной формой или частным случаем отношения ассоциации является отношение


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

Агрегирование (aggregation) - так называется структурное отношение между целым и его частями.
Данное отношение имеет фундаментальное значение для описания структуры сложных систем,
поскольку применяется для представления системных взаимосвязей типа "часть-целое". Раскрывая
внутреннюю структуру системы, отношение агрегации показывает, из каких компонентов состоит
система и как они связаны между собой. С точки зрения модели отдельные части системы могут
выступать как в виде элементов, так и в виде подсистем, которые, в свою очередь, тоже могут
образовывать составные компоненты или подсистемы. Графически отношение агрегации
изображается сплошной линией, один из концов которой представляет собой незакрашенный внутри
ромб. Этот ромб указывает на "целое" остальные являются его "частями" (рис. 2.15).

Рис. 2.15. Пиктограмма агрегации

Отношение композиции является частным случаем отношения агрегации. Это отношение служит
для выделения специальной формы отношения "часть-целое", при которой составляющие части в
некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том,
что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его
составные части.

Графически отношение композиции изображается сплошной линией, один из концов которой


представляет собой закрашенный внутри ромб. Этот ромб указывает на класс-композицию или
"целое" остальные являются его "частями" (рис. 2.16).

Рис. 2.16. Пиктограмма композиции

Обобщение (generalization) - это отношение "специализация/обобщение", при котором объект


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

Рис. 2.17. Пиктограмма обобщения

Реализация (realization) - это семантическое отношение между классификаторами, при котором


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

Рис. 2.18. Пиктограмма реализации

2.5. Диаграммы UML


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

 Диаграмма вариантов использования (use case diagram)


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

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

Каждая из этих диаграмм детализирует и конкретизирует различные представления о модели


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

Диаграммы поведения также являются разновидностями логической модели, которые отражают


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

Рис. 2.19. Интегрированная модель сложной системы в нотации UML

3. Диаграмма вариантов использования (use case diagram)


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

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

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


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

Суть данной диаграммы состоит в следующем: проектируемая система представляется в виде


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

17
диалоге с актером. При этом ничего не говорится о том, каким образом будет реализовано
взаимодействие актеров с системой.

В самом общем случае, диаграмма вариантов использования представляет собой граф


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

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


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

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


содержится его краткое название или имя в форме глагола с пояснительными словами (рис. 6).

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

Каждый вариант использования соответствует отдельному сервису, который предоставляет


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

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


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

С системно-аналитической точки зрения варианты использования могут применяться как для


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

Примерами вариантов использования могут являться следующие действия: проверка состояния


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

18
3.2. Актеры
Актер представляет собой любую внешнюю по отношению к моделируемой системе сущность,
которая взаимодействует с системой и использует ее функциональные возможности для достижения
определенных целей или решения частных задач. При этом актеры служат для обозначения
согласованного множества ролей, которые могут играть пользователи в процессе взаимодействия с
проектируемой системой. Каждый актер может рассматриваться как некая отдельная роль
относительно конкретного варианта использования. Стандартным графическим обозначением актера
на диаграммах является фигурка "человечка", под которой записывается конкретное имя актера (рис.
3.1).

Рис. 3.1. Обозначение актера

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

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

Актеры используются для моделирования внешних по отношению к проектируемой системе


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

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

На диаграмме вариантов использования интерфейс изображается в виде маленького круга, рядом


с которым записывается его имя (рис. 3.2, а). В качестве имени может быть существительное, которое
характеризует соответствующую информацию или сервис (например, "датчик", "сирена",
19
"видеокамера"), но чаще строка текста (например, "запрос к базе данных", "форма ввода",
"устройство подачи звукового сигнала"). Если имя записывается на английском, то оно должно
начинаться с заглавной буквы I, например, ISecurelnformation, ISensor (рис. 3.2, б).

Рис. 3.2. Графическое изображение интерфейсов на диаграммах вариантов использования

Графический символ отдельного интерфейса может соединяться на диаграмме сплошной линией


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

Рис. 3.3. Графическое изображение взаимосвязей интерфейсов с вариантами использования

С системно-аналитической точки зрения интерфейс не только отделяет спецификацию операций


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

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


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

3.4. Отношения на диаграмме вариантов использования


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

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

 Отношение ассоциации (association relationship)


 Отношение расширения (extend relationship)
 Отношение обобщения (generalization relationship)
 Отношение включения (include relationship)

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

3.4.1. Отношение ас социации

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

Применительно к диаграммам вариантов использования оно служит для обозначения


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

Рис. 3.4. Пример графического представления отношения ассоциации между актером


и вариантом использования

Кратность (multiplicity) ассоциации указывается рядом с обозначением компонента диаграммы,


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

Для диаграмм вариантов использования наиболее распространенными являются четыре основные


формы записи кратности отношения ассоциации:

 Целое неотрицательное число (включая цифру 0). Предназначено для указания кратности,
которая является строго фиксированной для элемента соответствующей ассоциации. В этом случае
количество экземпляров актеров или вариантов использования, которые могут выступать в качестве
элементов отношения ассоциации, в точности равно указанному числу.

21
Примером этой формы записи кратности ассоциации является указание кратности "1" для актера
"Клиент банка" (рис. 3.4). Эта запись означает, что каждый экземпляр варианта использования
"Оформить кредит для клиента банка" может иметь в качестве своего элемента единственный
экземпляр актера "Клиент банка". Другими словами, при оформлении кредита в банке необходимо
иметь в виду, что каждый конкретный кредит оформляется на единственного клиента этого банка.

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

{первое_число, первое_число+1, первое_число+2, ..., второе_число]. Очевидно, что первое число


должно быть строго меньше второго числа в арифметическом смысле, при этом первое число может
быть равно 0.

Пример такой формы записи кратности ассоциации - "1..5". Эта запись означает, что количество
отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной
ассоциации, равно некоторому заранее неизвестному числу из множества целых чисел {1, 2, 3, 4, 5}.
Эта ситуация может иметь место, например, в случае рассмотрения в качестве актера - клиента банка,
а в качестве варианта использования - процедуру открытия счета в банке. При этом количество
отдельных счетов каждого клиента в данном банке, исходя из некоторых дополнительных
соображений, может быть не больше 5. Эти дополнительные соображения как раз и являются
внешними требованиями по отношению к проектируемой системе и определяются ее заказчиком на
начальных этапах ООАП.

 Два символа, разделенные двумя точками. При этом первый из них является целым
неотрицательным числом или 0, а второй - специальным символом "*". Здесь символ "*"обозначает
произвольное конечное целое неотрицательное число, значение которого неизвестно на момент
задания соответствующего отношения ассоциации.

Пример такой формы записи кратности ассоциации - "2..*". Запись означает, что количество
отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной
ассоциации, равно некоторому заранее неизвестному числу из подмножества натуральных чисел: {2,
3, 4}.

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

В качестве примера этой записи можно привести кратность отношения ассоциации для варианта
использования "Оформить кредит для клиента банка" (рис. 3.4). Здесь кратность "*" означает, что
каждый отдельный клиент банка может оформить для себя несколько кредитов, при этом их общее
число заранее неизвестно и ничем не ограничивается. При этом некоторые клиенты могут совсем не
иметь оформленных на свое имя кредитов (вариант значения 0).

Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение,


равное 1.

3.4.2. Отношение расширения

Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования


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

Отношение расширения между вариантами использования обозначается пунктирной линией со


стрелкой (вариант отношения зависимости), направленной от того варианта использования, который
является расширением для исходного варианта использования. Данная линия со стрелкой помечается
ключевым словом "extend" ("расширяет"), как показано на рис. 3.5.

Рис. 3.5. Пример графического изображения отношения расширения между


вариантами использования

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

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

Семантика отношения расширения определяется следующим образом. Если экземпляр варианта


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

3.4.3. Отношение обобщения

Отношение обобщения служит для указания того факта, что некоторый вариант использования А
может быть обобщен до варианта использования В. В этом случае вариант А будет являться
специализацией варианта В. При этом В называется предком или родителем по отношению А, а
вариант А - потомком по отношению к варианту использования В. Следует подчеркнуть, что потомок
наследует все свойства и поведение своего родителя, а также может быть дополнен новыми
свойствами и особенностями поведения. Графически данное отношение обозначается сплошной
линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский
вариант использования (рис. 3.6). Эта линия со стрелкой имеет специальное название - стрелка
"обобщение".

23
Рис. 3.6. Пример графического изображения отношения обобщения между вариантами
использования

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


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

Применительно к данному отношению, один вариант использования может иметь несколько


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

Между отдельными актерами также может существовать отношение обобщения. Данное


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

Рис. 3.7. Пример графического изображения отношения обобщения между актерами

3.4.4. Отношение включения

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


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

Семантика этого отношения определяется следующим образом. Когда экземпляр первого


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

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

Отношение включения, направленное от варианта использования А к варианту использования В,


указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные
для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной
диаграмме. Графически данное отношение обозначается пунктирной линией со стрелкой (вариант
отношения зависимости), направленной от базового варианта использования к включаемому. При
этом данная линия со стрелкой помечается ключевым словом "include" ("включает"), как показано на
рис. 3.8.

Рис. 3.8. Пример графического изображения отношения включения между вариантами


использования

3.5. Пример построения диаграммы вариантов использования


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

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

Рис. 3.9. Исходная диаграмма вариантов использования для примера разработки системы
продажи товаров по каталогу

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

На следующем этапе разработки данной диаграммы вариант использования "Оформить заказ на


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

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

Полученная в результате последующей детализации уточненная диаграмма вариантов


использования будет содержать 5 вариантов использования и 2 актеров (рис. 3.10), между которыми
установлены отношения включения и расширения.

Рис. 3.10. Уточненный вариант диаграммы вариантов использования для примера системы
продажи товаров по каталогу

Приведенная выше диаграмма вариантов использования, в свою очередь, может быть


детализирована далее с целью более глубокого уточнения предъявляемых к системе требований и
конкретизации деталей ее последующей реализации. Детализация может быть выполнена на основе
установления дополнительных отношений типа отношения "обобщение-специализация" для уже
имеющихся компонентов диаграммы вариантов использования. Так, в рамках рассматриваемой
системы продажи товаров может иметь самостоятельное значение и специфические особенности
отдельная категория товаров - компьютеры. В этом случае диаграмма может быть дополнена
вариантом использования "Оформить заказ на покупку компьютера" и актерами "Покупатель
компьютера" и "Продавец компьютеров", которые связаны с соответствующими компонентами
диаграммы отношением обобщения (рис. 3.11).
26
Рис. 3.11. Один из вариантов последующего уточнения диаграммы вариантов использования для
примера рассматриваемой системы продажи

Построение диаграммы вариантов использования является самым первым этапом процесса


объектно-ориентированного анализа и проектирования, цель которого - представить совокупность
требований к поведению проектируемой системы. Спецификация требований к проектируемой
системе в форме диаграммы вариантов использования представляет собой самостоятельную модель,
которая в языке UML получила название модели вариантов использования и имеет свое специальное
стандартное имя или стереотип "useCaseModel".

4. Диаграмма последовательности (sequence diagram)


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

Во-первых, взаимодействия объектов можно рассматривать во времени, и тогда для


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

Во-вторых, можно рассматривать структурные особенности взаимодействия объектов. Для


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

4.1. Объекты
На диаграмме последовательности изображаются исключительно те объекты, которые
непосредственно участвуют во взаимодействии и не показываются возможные статические
ассоциации с другими объектами. Для диаграммы последовательности ключевым моментом является
именно динамика взаимодействия объектов во времени. Графически каждый объект изображается
прямоугольником и располагается в верхней части своей линии жизни (рис. 4.1). Внутри
прямоугольника записываются имя объекта и имя класса, разделенные двоеточием. При этом вся
запись подчеркивается, что является признаком объекта, который, как известно, представляет собой
27
экземпляр класса. В случае, когда имя объекта отсутствует указывается только имя класса, а сам
объект считается анонимным.

Рис. 4.1. Различные графические примитивы диаграммы последовательности

Крайним слева на диаграмме изображается объект, который является инициатором


взаимодействия (объект 1 на рис. 4.1). Правее изображается другой объект, который непосредственно
взаимодействует с первым. Таким образом, все объекты на диаграмме последовательности образуют
некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с
другом.

Второе измерение диаграммы последовательности - вертикальная временная ось, направленная


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

4.1.1. Линия жизни объекта

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией,


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

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

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

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

4.1.2. Фокус управления

В процессе функционирования объектно-ориентированных систем одни объекты могут


находиться в активном состоянии, непосредственно выполняя определенные действия или в
состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную
активность объектов, в языке UML применяется специальное понятие, получившее название фокуса
управления (focus of control). Фокус управления изображается в форме вытянутого узкого
прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта
(начало активности), а ее нижняя сторона - окончание фокуса управления (окончание активности).

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

4.2. Сообщения
Цель взаимодействия в контексте языка UML заключается в том, чтобы специфицировать
коммуникацию между множеством взаимодействующих объектов. Каждое взаимодействие
описывается совокупностью сообщений, которыми участвующие в нем объекты обмениваются между
собой. В этом смысле сообщение (message) представляет собой законченный фрагмент информации,
который отправляется одним объектом другому. При этом прием сообщения инициирует выполнение
определенных действий, направленных на решение отдельной задачи тем объектом, которому это
сообщение отправлено.

Таким образом, сообщения не только передают некоторую информацию, но и требуют или


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

В таком контексте каждое сообщение имеет направление от объекта, который инициирует и


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

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

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

4.2.1. Стереотипы сообщений

В языке UML предусмотрены некоторые стандартные действия, выполняемые в ответ на


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

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

 "call" (вызвать) - сообщение, требующее вызова операции или процедуры принимающего


объекта;
 "return" (возвратить) - сообщение, возвращающее значение выполненной операции или
процедуры вызвавшему ее объекту;
 "create" (создать) - сообщение, требующее создания другого объекта для выполнения
определенных действий;
 "destroy" (уничтожить) - сообщение с явным требованием уничтожить соответствующий
объект. Посылается в том случае, когда необходимо прекратить нежелательные действия со стороны
существующего в системе объекта, либо когда объект больше не нужен и должен освободить
задействованные им системные ресурсы;
 "send" (послать) - обозначает посылку другому объекту некоторого сигнала, который
асинхронно инициируется одним объектом и принимается (перехватывается) другим. Отличие
сигнала от сообщения заключается в том, что сигнал должен быть явно описан в том классе, объект
которого инициирует его передачу.

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

Рис. 4.2. Диаграмма последовательности со стереотипными значениями сообщений

4.2.2. Временные ограничения на диаграммах последовательности

В отдельных случаях выполнение тех или иных действий на диаграмме последовательности


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

 {время_ожидания_ответа < 5 сек.}


 {время_передачи_пакета < 10 сек.}
30
4.3. Пример построения диаграммы последовательности
В качестве примера рассмотрим построение диаграммы последовательности для моделирования
процесса телефонного разговора с использованием обычной телефонной сети. Объектами в этом
примере являются: два абонента а и b, два телефонных аппарата, коммутатор и сам разговор как
объект моделирования. При этом как коммутатор, так и разговор являются анонимными объектами.

Процесс взаимодействия в этой системе начинается с поднятия трубки телефонного аппарата


первым абонентом. Тем самым он посылает сообщение телефонному аппарату с, которое переводит
этот аппарат в активное состояние и вызывает действие - подачу тонового сигнала в телефонную
трубку для первого абонента. Следующее действие также инициируется первым абонентом - набор
цифр телефонного номера. Это представлено в форме итеративного сообщения со знаком "*" слева от
его имени. Поднятие телефонной трубки и набор цифр номера являются физическими действиями и
поэтому изображаются в форме простых асинхронных сообщений. После набора цифр номера
телефона аппарат с рекурсивно вызывает процедуру посылки коммутационных импульсов на
коммутатор. Последний инициирует создание нового объекта в моделируемой системе - телефонного
разговора. После создания анонимный объект "разговор" сразу получает фокус активности и
посылает сообщение телефонному аппарату d на выполнение действия - звонка вызова. При этом
второй абонент снимает трубку (асинхронное сообщение), тем самым устанавливается прямое
соединение между абонентами а и b. После того как абоненты опустят трубки, разговор
заканчивается. Тем самым объект "разговор" уничтожается. Окончательный вариант диаграммы
последовательности может содержать некоторые временные ограничения и комментарии(рис. 4.3).

Рис. 4.3. Окончательный вариант диаграммы последовательности для моделирования


телефонного разговора

5. Диаграмма кооперации (collaboration diagram)


Главная особенность диаграммы кооперации заключается в возможности графически представить
не только последовательность взаимодействия, но и все структурные отношения между объектами,
участвующими в этом взаимодействии. Прежде всего, на диаграмме кооперации в виде
прямоугольников изображаются участвующие во взаимодействии объекты, содержащие имя объекта,
его класс и, возможно, значения атрибутов. Далее указываются ассоциации между объектами в виде
31
различных соединительных линий. При этом можно явно указать имена ассоциации и ролей, которые
играют объекты в данной ассоциации. Дополнительно могут быть изображены динамические связи -
потоки сообщений. Они представляются также в виде соединительных линий между объектами, над
которыми располагается стрелка с указанием направления, имени сообщения и порядкового номера в
общей последовательности инициализации сообщений.

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


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

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


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

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

Объект (object) является отдельным экземпляром класса, который создается на этапе выполнения
программы. Он может иметь свое собственное имя и конкретные значения атрибутов. Применительно
к объектам формат строки классификатора дополняется именем объекта и приобретает следующий
вид (при этом вся запись подчеркивается):

<Имя объекта>'/' <Имя роли классификатора> ':' <Имя классификатора>

[':' <Имя классификатора >]*

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

Ниже приводятся возможные варианты записи строки текста в прямоугольнике объекта.

 : С - анонимный объект, образуемый на основе класса С.


 / R - анонимный объект, играющий роль R.
 / R : С - анонимный объект, образуемый на основе класса С и играющий роль R.
 О / R - объект с именем О, играющий роль R.
 О : С - объект с именем О, образуемый на основе класса С.
 О / R : С - объект с именем О, образуемый на основе класса С и играющий роль R.
 О или - объект с именем О.
 О : - "объект-сирота" с именем О.
 / R - роль с именем R

32
:С - анонимная роль на базе класса С.
/R : С - роль с именем R на основе класса С.

Отдельные примеры изображения объектов и классов на диаграмме кооперации приводятся на


следующем рисунке (рис. 5.1).

Рис. 5.1. Примеры различных вариантов записи имен объектов, ролей и классов на диаграммах
кооперации

Так, в первом случае (рис. 5.1, а) обозначен объект с именем "клиент", играющий роль
"инициатор запроса". Далее (рис. 5.1, б) следует обозначение анонимного объекта, который играет
роль инициатора запроса. В обоих случаях не указан класс, на основе которого будут созданы эти
объекты. Обозначение класса присутствует в следующем варианте записи (рис. 5.1, в), причем объект
также анонимный. Применительно к уровню спецификации на диаграммах кооперации могут
присутствовать именованные классы с указанием роли класса в кооперации (рис. 5.1, г) или
анонимные классы, когда указывается только его роль (рис. 5.1, д). Последний случай характерен для
ситуации, когда в модели могут присутствовать несколько классов с именем "Клиент", поэтому
требуется явно указать имя соответствующего пакета База данных (рис. 5.1, е).

5.1.1. Мультиобъект

Мультиобъект (multiobject) представляет собой целое множество объектов на одном из концов


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

Рис. 5.2. Графическое изображение мультиобъектов на диаграмме кооперации

33
5.1.2. Активный объект

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

Активный объект (active object) имеет свою собственную нить (thread) управления и может
инициировать деятельность по управлению другими объектами. При этом под нитью понимается
некоторый облегченный поток управления, который может выполняться параллельно с другими
вычислительными нитями или нитями управления в пределах одного вычислительного процесса или
процесса управления.

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


широкими границами (рис. 5.3). Иногда может быть явно указано ключевое слово (помеченное
значение) {active}, чтобы выделить активный объект на диаграмме. Каждый активный объект может
инициировать единственную нить или процесс управления и представлять исходную точку потока
управления. В приведенном фрагменте диаграммы кооперации активный объект "а: Вызывающий
абонент" является инициатором процесса установления соединения для обмена информацией с
другим абонентом (на диаграмме не показан).

Рис. 5.3. Графическое изображение активного объекта (слева) на диаграмме кооперации

В следующем примере рассматривается ситуация с вызовом функции печати из текстового


редактора (рис. 5.4). Анонимный активный объект "Текстовый редактор" вначале посылает
сообщение анонимному мультиобъекту "Принтер", которое инициирует выбор единственного объекта
"Принтер", возможно, удовлетворяющего некоторым дополнительным условиям. После этого
выбранному объекту посылается сообщение о необходимости напечатать документ, загруженный в
текстовый редактор.

Рис. 5.4. Фрагмент диаграммы кооперации для вызова функции печати из текстового редактора

5.1.3. Составной объект

Составной объект (composite object) или объект-контейнер предназначен для представления


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

34
На диаграммах кооперации такой составной объект изображается как обычный объект, состоящий
из двух секций: верхней и нижней. В верхней секции записывается имя составного объекта, а в
нижней - его составные части вместо списка его атрибутов (рис. 5.5). При этом допускается иметь в
качестве частей другие составные объекты.

Рис. 5.5. Графическое изображение составного объекта на диаграмме кооперации

5.2. Связи
Связь (link) является экземпляром или примером произвольной ассоциации. Связь как элемент
языка UML может иметь место между двумя и более объектами. Бинарная связь на диаграмме
кооперации изображается отрезком прямой линии, соединяющей два прямоугольника объектов (см.
рис. 5.4). На каждом из концов этой линии могут быть явно указаны имена ролей данной ассоциации.
Рядом с линией в ее средней части может записываться имя соответствующей ассоциации. Связи не
имеют собственных имен, поскольку полностью идентичны как экземпляры ассоциации. Другими
словами, все связи на диаграмме кооперации могут быть только анонимными и записываются без
двоеточия перед именем ассоциации. Для связей не указывается также и кратность. Однако другие
обозначения специальных случаев ассоциации (агрегация, композиция) могут присутствовать на
отдельных концах связей. Например, символ связи типа "композиция" между мультиобъектом
"Принтер" и отдельным объектом "Принтер" (см. рис. 5.4).

5.2.1. Стереотипы связей

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

 "association" - ассоциация (предполагается по умолчанию, поэтому этот стереотип можно не


указывать).
 "parameter" - параметр метода. Соответствующий объект может быть ч только параметром
некоторого метода.
 "local" - локальная переменная метода. Ее область видимости ограничена только соседним
объектом.
 "global" - глобальная переменная. Ее область видимости распространяется на всю диаграмму
кооперации.

35
 "self - рефлексивная связь объекта с самим собой, которая допускает передачу объектом
сообщения самому себе. На диаграмме кооперации рефлексивная связь изображается петлей в
верхней части прямоугольника объекта.

Некоторые примеры связей с различными стереотипами изображены на рис. 5.6. Здесь


представлена обобщенная схема некоторой конкретной компании с именем "С", которая состоит из
отделов (анонимный мультиобъект "Отдел"). Последние, в свою очередь, состоят из сотрудников
(анонимный мультиобъект "Сотрудник"). Рефлексивная связь указывает на тот факт, что менеджер
отдела является в то же время и его сотрудником.

Рис. 5.6. Графическое изображение связей с различными стереотипами

5.3. Кооперация
Понятие кооперации (collaboration) является одним из фундаментальных понятий в языке UML.
Оно служит для обозначения множества взаимодействующих с определенной целью объектов в
общем контексте моделируемой системы. Цель самой кооперации состоит в том, чтобы
специфицировать особенности реализации отдельных наиболее значимых операций в системе.
Кооперация определяет структуру поведения системы в терминах взаимодействия участников этой
кооперации.
Кооперация может быть представлена на двух уровнях:
 На уровне спецификации - показывает роли классификаторов и роли ассоциаций в
рассматриваемом взаимодействии.
 На уровне примеров - указывает экземпляры и связи, образующие отдельные роли в
кооперации.

Диаграмма кооперации уровня спецификации показывает роли, которые играют участвующие во


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

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


классов) и связей (экземпляры ассоциаций). При этом связи дополняются стрелками сообщений. На
данном уровне показываются только релевантные объекты, т. е. имеющие непосредственное
отношение к реализации операции или классификатора.

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

Отсюда вытекает важное следствие. Одна и та же совокупность объектов может участвовать в


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

5.4. Диаграмма кооперации уровня спецификации


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

Рис. 5.7. Общее представление кооперации на диаграммах уровня спецификации

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


записывается строка текста. Эта строка текста называется ролью классификатора (classifier role). Роль
классификатора показывает особенность использования объектов данного класса. Обычно в
прямоугольнике показывается только секция имени класса, хотя не исключается возможность
указания секций атрибутов и операций.

Строка текста в прямоугольнике должна иметь следующий формат:

'/' <Имя роли классификатора> ':' <Имя классификатора>

[':' <Имя классификатора >]*

Здесь Имя классификатора, если это необходимо, может включать полный путь всех вложенных
пакетов. При этом один пакет от другого отделяется двойным двоеточием "::". Если не возникает
путаницы, можно ограничиться указанием только ближайшего из пакетов, которому принадлежит
данная кооперация. Символ "*" применяется для указания возможности итеративного повторения
имени классификатора.

Если кооперация допускает обобщенное представление, то на диаграммах могут быть указаны


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

37
Рис. 5.8. Графическое изображение отношения обобщения между отдельными кооперациями
уровня спецификации

В отдельных случаях возникает необходимость явно указать тот факт, что кооперация является
реализацией некоторой операции или классификатора. Это можно представить одним из двух
способов.

Во-первых, можно соединить символ кооперации пунктирной линией со стрелкой обобщения с


символом класса, реализацию операции которого специфицирует данная кооперация (рис. 5.9, а). Так,
если в качестве класса рассмотреть "Заказ на покупку товара", у которого имеется операция
"оформить_заказ (), то ее реализация может быть специфицирована в форме кооперации.

Рис. 5.9. Способы представления кооперации, которая реализует операцию класса

Во-вторых, можно просто изобразить символ кооперации, внутри которого указать всю
необходимую информацию, записанную по определенным правилам (рис. 5.9, б). Эти правила
определяют формат записи имени кооперации, после которого записывают двоеточие и имя класса. За
именем класса следует двойное двоеточие и имя операции.

Подобное общее представление кооперации на уровне спецификации используется на начальных


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

5.5. Пример построения диаграммы кооперации


В качестве примера рассмотрим построение диаграммы кооперации для моделирования процесса
телефонного разговора с использованием обычной телефонной сети (рис. 5.10), расмотренным в
параграфе 4.3.

Для объекта "Разговор" указано помеченное значение {transient}, которое означает, что этот
объект создается в процессе выполнения объемлющего процесса и уничтожается до его завершения.

38
Рис. 5.10. Диаграмма кооперации для моделирования телефонного разговора

Как нетрудно заметить, диаграмма кооперации для примера с телефонным разговором не


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

Если же взаимодействующие объекты образуют между собой различные типы отношений-


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

6. Диаграмма классов (class diagram)


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

Нотация UML предоставляет широкие возможности для отображения дополнительной


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

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

Диаграмма классов представляет собой некоторый граф, вершинами которого являются элементы
типа "классификатор", которые связаны различными типами структурных отношений. Следует
заметить, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже
отдельные экземпляры, такие как объекты и связи. Когда говорят о данной диаграмме, имеют в виду
39
статическую структурную модель проектируемой системы. Поэтому диаграмму классов принято
считать графическим представленном таких структурных взаимосвязей логической модели системы,
которые не зависят или инвариантны от времени.

6.1. Класс
Класс (class) в языке UML служит для обозначения множества объектов, которые обладают
одинаковой структурой, поведением и отношениями с объектами из других классов. Графически
класс изображается в виде прямоугольника, который дополнительно может быть разделен
горизонтальными линиями на разделы или секции (рис. 2.2).

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

Предполагается, что окончательный вариант диаграммы содержит наиболее полное описание


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

Даже если секция атрибутов и операций является пустой, в обозначении класса она выделяется
горизонтальной линией, чтобы сразу отличить класс от других элементов языка UML. Примеры
графического изображения классов на диаграмме классов приведены на рис.6.1. В первом случае для
класса "Прямоугольник" (рис. 6.1, а) указаны только его атрибуты - точки на координатной плоскости,
которые определяют его расположение. Для класса "Окно" (рис. 6.1, б) указаны только его операции,
секция атрибутов оставлена пустой. Для класса "Счет" (рис. 6.1, в) дополнительно изображена
четвертая секция, в которой указано исключение - отказ от обработки просроченной кредитной
карточки.

Рис. 6.1. Примеры графического изображения классов на диаграмме

6.1.1. Имя класса

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

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

Примерами имен классов могут быть такие существительные, как "Сотрудник", "Компания",
"Руководитель", "Клиент", "Продавец", "Менеджер", "Офис" и многие другие, имеющие
непосредственное отношение к моделируемой предметной области и функциональному назначению
проектируемой системы.

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

В некоторых случаях необходимо явно указать, к какому пакету относится тот или иной класс.
Для этой цели используется специальный символ разделитель - двойное двоеточие "::". Синтаксис
строки имени класса в этом случае будет следующий <Имя_пакета>::<Имя_класса>. Другими
словами, перед именем класса должно быть явно указано имя пакета, к которому его следует отнести.
Например, если определен пакет с именем "Банк", то класс "Счет" в этом банке может быть записан в
виде: "Банк::Счет".

6.1.2. Атрибуты класса

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

<квантор видимости><имя атрибута>[кратность]:

<тип атрибута> = <исходное значение>{строка-свойство}

Квантор видимости может принимать одно из трех возможных значений и, соответственно,


отображается при помощи специальных символов:

 Символ "+" обозначает атрибут с областью видимости типа общедоступный (public). Атрибут
с этой областью видимости доступен или виден из любого другого класса пакета, в котором
определена диаграмма.
 Символ "#" обозначает атрибут с областью видимости типа защищенный (protected). Атрибут с
этой областью видимости недоступен или невиден для всех классов, за исключением подклассов
данного класса.
 И, наконец, знак "-" обозначает атрибут с областью видимости типа закрытый (private).
Атрибут с этой областью видимости недоступен или невиден для всех классов без исключения.

Квантор видимости может быть опущен. В этом случае его отсутствие просто означает, что
видимость атрибута не указывается. Эта ситуация отличается от принятых по умолчанию соглашений
в традиционных языках программирования, когда отсутствие квантора видимости трактуется как
public или private. Однако вместо условных графических обозначений можно записывать
соответствующее ключевое слово: public, protected, private.

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

В качестве примера кратности атрибутов рассмотрим следующие варианты:

 [0..1] означает, что кратность атрибута может принимать значение О или 1. При этом 0
означает отсутствие значения для данного атрибута.
 [0..*] означает, что кратность атрибута может принимать любое положительное целое значение
большее или равное 0. Эта кратность может быть записана короче в виде простого символа - [*].
 [1.:*] означает, что кратность атрибута может принимать любое положительное целое значение
большее или равное 1.
 [1..5] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3, 4, 5.
 [1..3,5,7] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3,
5, 7.
 [1..3,7.. 10] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2,
3, 7, 8, 9, 10.
 [1..3,7..*] означает, что кратность атрибута может принимать любое значение из чисел: 1, 2, 3,
а также любое положительное целое значение большее или равное 7.

Если кратность атрибута не указана, то по умолчанию принимается ее значение равное 1..1, т. е. в


точности 1.

Тип атрибута представляет собой выражение, семантика которого определяется языком


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

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


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

Например, если некоторый атрибут задан в виде форма: Прямоугольник. то это будет означать,
что все объекты данного класса могут иметь несколько различных форм, каждая из которых является
прямоугольником. Другим примером может служить задание атрибута в виде номер_счета:Integer. что
может означать для объекта Сотрудник наличие некоторого подмножества счетов, общее количество
которых заранее не фиксируется.

Строка-свойство служит для указания значений атрибута, которые не могут быть изменены в
программе при работе с данным типом объектов. Фигурные скобки как раз и обозначают
фиксированное значение соответствующего атрибута для класса в целом, которое должны принимать
все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное
значение атрибута, которое не может быть переопределено в последующем. Отсутствие строки-
свойства по умолчанию трактуется так, что значение соответствующего атрибута может быть
изменено в программе. Например, строка-свойство в записи атрибута заработная_плата:Currency = =
{$500} может служить для обозначения фиксированной заработной платы для каждого объекта
класса "Сотрудник" определенной должности в некоторой организации. С другой стороны, запись
данного атрибута в виде зара-ботная_плата: Currency = $500 означает уже нечто иное, а именно - при
создании нового экземпляра Сотрудник (аналогия - прием на работу нового сотрудника) для него
устанавливается по умолчанию заработная плата в $500. Однако для отдельных сотрудников могут
быть сделаны исключения как в большую, так и в меньшую сторону, о чем необходимо позаботиться
дополнительно в программе.
42
6.1.3. Операция

В третьей сверху секции прямоугольника записываются операции или методы класса. Операция
(operation) представляет собой некоторый сервис, предоставляющий каждый экземпляр класса по
определенному требованию. Совокупность операций характеризует функциональный аспект
поведения класса. Запись операций класса в языке UML также стандартизована и подчиняется
определенным синтаксическим правилам. При этом каждой операции класса соответствует отдельная
строка, которая состоит из квантора видимости операции, имени операции, выражения типа
возвращаемого операцией значения и, возможно, строка-свойство данной операции:

<квантор видимости><имя операции>(список параметров):

<выражение типа возвращаемого значения>{строка-свойство}

Квантор видимости, как и в случае атрибутов класса, может принимать одно из трех возможных
значений и, соответственно, отображается при помощи специального символа. Символ "+"
обозначает операцию с областью видимости типа общедоступный (public). Символ "#" обозначает
операцию с областью видимости типа защищенный (protected). И, наконец, символ "-" используется
для обозначения операции с областью видимости типа закрытый (private).

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

Имя операции представляет собой строку текста, которая используется в качестве


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

Операция, которая не может изменять состояние системы и, соответственно, не имеет никакого


побочного эффекта, обозначается строкой-свойством "{запрос}" ("{query}"). В противном случае
операция может изменять состояние системы, хотя нет никаких гарантий, что она будет это делать.

Список формальных параметров и тип возвращаемого значения могут не указываться. Квантор


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

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


операций:

 +создать()- может обозначать абстрактную операцию по созданию отдельного объекта класса,


которая является общедоступной и не содержит формальных параметров. Эта операция не
возвращает никакого значения после своего выполнения.
 +нарисовать(форма: Многоугольник = прямоугольник, цвет_заливки: Color = (О, О, 255)) -
может обозначать операцию по изображению на экране монитора прямоугольной области синего
цвета, если не указываются другие значения в качестве аргументов данной операции.
 запросить_счет_клиента(номер_счета:1п1е§ег):Сиггепсу - обозначает операцию по
установлению наличия средств на текущем счете клиента банка. При этом аргументом данной
операции является номер счета клиента, который записывается в виде целого числа (например,
"123456"). Результатом выполнения этой операции является некоторое число, записанное в
принятом денежном формате (например, $1,500.00).
43
 выдать_сообщение():{"Ошибка деления на ноль"} - смысл данной операции не требует
пояснения, поскольку содержится в строке-свойстве операции. Данное сообщение может появиться
на экране монитора в случае попытки деления некоторого числа на ноль, что недопустимо.

6.2. Отношения между классами


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

 Отношение зависимости (dependency relationship)


 Отношение ассоциации (association relationship)
 Отношение обобщения (generalization relationship)
 Отношение реализации (realization relationship)

Каждое из этих отношений имеет собственное графическое представление на диаграмме, которое


отражает взаимосвязи между объектами соответствующих классов.

6.2.1. Отношение зависимости

Отношение зависимости в общем случае указывает некоторое семантическое отношение между


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

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


соответствующими элементами со стрелкой на одном из ее концов ("->" или "<-"). На диаграмме
классов данное отношение связывает отдельные классы между собой, при этом стрелка направлена от
класса-клиента зависимости к независимому классу или классу-источнику (рис. 6.2). На данном
рисунке изображены два класса: Класс_А и Кяасс_Б, при этом Класс_Б является источником
некоторой зависимости, а Класс_А - клиентом этой зависимости.

Рис. 6.2. Графическое изображение отношения зависимости на диаграмме классов

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


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

 "access" - служит для обозначения доступности открытых атрибутов и операций класса-


источника для классов-клиентов;
 "bind" - класс-клиент может использовать некоторый шаблон для своей последующей
параметризации;
44
 "derive" - атрибуты класса-клиента могут быть вычислены по атрибутам класса-источника;
 "import" - открытые атрибуты и операции класса-источника становятся частью класса-клиента,
как если бы они были объявлены непосредственно в нем;
 "refine" - указывает, что класс-клиент служит уточнением класса-источника в силу причин
исторического характера, когда появляется дополнительная информация в ходе работы над
проектом.

6.2.2. Отношение ассоциации

Отношение ассоциации соответствует наличию некоторого отношения между классами. Данное


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

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

В качестве простого примера отношения бинарной ассоциации рассмотрим отношение между


двумя классами - классом "Компания" и классом "Сотрудник" (рис. 6.3). Они связаны между собой
бинарной ассоциацией Работа, имя которой указано на рисунке рядом с линией ассоциации. Для
данного отношения определен порядок следования классов, первым из которых является класс
"Сотрудник", а вторым - класс "Компания".

Рис. 6.3. Графическое изображение отношения бинарной ассоциации между классами

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


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

Следующий элемент обозначений - кратность отдельных классов, являющихся концами


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

Специальной формой или частным случаем отношения ассоциации является отношение


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

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

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

В качестве примера отношения агрегации рассмотрим взаимосвязь типа "часть-целое", которая


имеет место между сущностью "Грузовой автомобиль" и такими компонентами, как "Двигатель",
"Шасси", "Кабина", "Кузов". Графически отношение агрегации изображается сплошной линией, один
из концов которой представляет собой незакрашенный внутри ромб. Этот ромб указывает на тот из
классов, который представляет собой "целое". Остальные классы являются его "частями" (рис. 6.4).

Рис. 6.4. Диаграмма классов для иллюстрации отношения агрегации на примере ПК

6.2.4. Отношение композиции

Отношение композиции является частным случаем отношения агрегации. Это отношение служит
для выделения специальной формы отношения "часть-целое", при которой составляющие части в
некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том,
что части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его
составные части.

Графически отношение композиции изображается сплошной линией, один из концов которой


представляет собой закрашенный внутри ромб. Этот ромб указывает на тот из классов, который
представляет собой класс-композицию или "целое". Остальные классы являются его "частями" В
качестве дополнительных обозначений для отношений композиции и агрегации могут использоваться
дополнительные обозначения, применяемые для отношения ассоциации. А именно, указание
кратности класса ассоциации и имени данной ассоциации, которые не являются обязательными.
Применительно к описанному выше примеру класса "Окно_программы" его диаграмма классов
может иметь следующий вид (рис. 6.5).

46
Рис. 6.5. Диаграмма классов для иллюстрации отношения композиции на примере
класса окна программы

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


программы, которые не указывались в явном виде при описании этого примера Так, в частности,
указание кратности 1 рядом с классом "Рабочая_область" характерно для однодокументных
приложений.

6.2.5. Отношение обобщения

Отношение обобщения является обычным таксономическим отношением между более общим


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

Применительно к диаграмме классов данное отношение описывает иерархическое строение


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

С целью упрощения обозначений на диаграмме классов совокупность линий, обозначающих одно


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

Рис. 6.6 Вариант графического изображения отношения обобщения классов для случая
объединения отдельных линий

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


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

В качестве ограничений могут быть использованы следующие ключевые слова языка UML:
47
 {complete} - означает, что в данном отношении обобщения специфицированы все классы-
потомки, и других классов-потомков у данного класса-предка быть не может. Пример - класс
Клиент_банка является предком для двух классов: Физическое_лицо и Компания, и других классов-
потомков он не имеет. На соответствующей диаграмме классов это можно указать явно, записав
рядом с линией обобщения данную строку-ограничение;
 {disjoint} - означает, что классы-потомки не могут содержать объектов, одновременно
являющихся экземплярами двух или более классов. В приведенном выше примере это условие
также выполняется, поскольку предполагается, что никакое конкретное физическое лицо не может
являться одновременно и конкретной компанией. В этом случае рядом с линией обобщения можно
записать данную строку-ограничение;
 {incomplete} - означает случай, противоположный первому. А именно, предполагается, что на
диаграмме указаны не все классы-потомки. В последующем возможно восполнить их перечень не
изменяя уже построенную диаграмму. Пример - диаграмма класса "Автомобиль", для которой
указание всех без исключения моделей автомобилей соизмеримо с созданием соответствующего
каталога. С другой стороны, для отдельной задачи, такой как разработка системы продажи
автомобилей конкретных моделей, в этом нет необходимости. Но указать неполноту структуры
классов-потомков все же следует;
 {overlapping} - означает, что отдельные экземпляры классов-потомков могут принадлежать
одновременно нескольким классам. Пример - класс "Многоугольник" является классом-предком для
класса "Прямоугольник" и класса "Ромб". Однако существует отдельный класс "Квадрат",
экземпляры которого одновременно являются объектами первых двух классов. Вполне естественно
такую ситуацию указать явно с помощью данной строки-ограничения.

6.3. Интерфейсы
Интерфейсы являются элементами диаграммы вариантов использования. Однако при построении
диаграммы классов отдельные интерфейсы могут уточняться и в этом случае для их изображения
используется специальный графический символ - прямоугольник класса с ключевым словом или
стереотипом "interface" (рис. 6.7). При этом секция атрибутов у прямоугольника отсутствует, а
указывается только секция операций.

Рис. 6.7. Пример графического изображения интерфейса на диаграмме классов

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

Для графического изображения объектов используется такой же символ прямоугольника, что и


для классов. Отличия проявляются при указании имен объектов, которые в случае объектов
обязательно подчеркиваются (рис. 6.8). При этом запись имени объекта представляет собой строку
текста "имя объекта:имя класса", разделенную двоеточием (рис. 6.8 а, б). Имя объекта может
отсутствовать, в этом случае предполагается, что объект является анонимным, и двоеточие указывает
48
на данное обстоятельство (рис. 6.8, г). Отсутствовать может и имя класса. Тогда указывается просто
имя объекта (рис. 6.8, в). Атрибуты объектов принимают конкретные значения.

Рис. 6.8. Пример графического изображения объектов на диаграммах языка UML

7. Диаграмма состояний (statechart diagram)


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

Главное предназначение этой диаграммы - описать возможные последовательности состояний и


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

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

Диаграмма состояний по существу является графом специального вида, который представляет


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

7.1. Автоматы
Автомат (state machine) в языке UML представляет собой некоторый формализм для
моделирования поведения элементов модели и системы в целом. В метамодели UML автомат
является пакетом, в котором определено множество понятий, необходимых для представления

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

Простейшим примером визуального представления состояний и переходов на основе формализма


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

Рис. 7.1. Простейший пример диаграммы состояний для технического устройства типа
компьютер

Основными понятиями, входящими в формализм автомата, являются состояние и переход.


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

В общем случае автомат представляет динамические аспекты моделируемой системы в виде


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

7.2. Состояние
В языке UML под состоянием понимается абстрактный метакласс, используемый для
моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия.

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

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

Например, инвариант может представлять статическую ситуацию, когда объект находится в


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

50
Рис. 7.2. Графическое изображение состояний на диаграмме состояний

Состояние на диаграмме изображается прямоугольником со скругленными вершинами (рис. 7.2).


Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией.
Если указана лишь одна секция, то в ней записывается только имя состояния (рис. 7.2, а). В
противном случае в первой из них записывается имя состояния, а во второй - список некоторых
внутренних действий или переходов в данном состоянии (рис. 7.2, б). При этом под действием в
языке UML понимают некоторую атомарную операцию, выполнение которой приводит к изменению
состояния или возврату некоторого значения (например, "истина" или "ложь").

7.2.1. Имя состояния

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

7.2.2. Начальное состояние

Начальное состояние представляет собой частный случай состояния, которое не содержит


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

Рис. 7.3. Графическое изображение начального и конечного состояний на диаграмме состояний

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

7.2.3. Конечное состояние

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

7.3. Переход
Простой переход (simple transition) представляет собой отношение между двумя
последовательными состояниями, которое указывает на факт смены одного состояния другим.
Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением
некоторых действий, а переход во второе состояние будет возможен после завершения этих действий,
а также после удовлетворения некоторых дополнительных условий. Переход осуществляется при
наступлении некоторого события: окончания выполнения деятельности (do activity), получении
объектом сообщения или приемом сигнала. На переходе указывается имя события. Кроме того, на
переходе могут указываться действия, производимые объектом в ответ на внешние события при
переходе из одного состояния в другое. Срабатывание перехода может зависеть не только от
наступления некоторого события, но и от выполнения определенного условия, называемого
сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло
указанное событие и сторожевое условие приняло значение "истина".

На диаграмме состояний переход изображается сплошной линией со стрелкой, которая


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

<сигнатура события>'['<сторожевое условие>']' <выражение действия>.

При этом сигнатура события описывает некоторое событие с необходимыми аргументами:

<имя события>'('<список параметров, разделенных запятыми>')'.

7.3.1. Событие

Термин событие (event) требует отдельного пояснения, поскольку является самостоятельным


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

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

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

Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после
события-триггера и представляет собой некоторое булевское выражение. Введение для перехода
сторожевого условия позволяет явно специфицировать семантику его срабатывания. Если сторожевое
условие принимает значение "истина", то соответствующий переход может сработать, в результате
чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение "ложь",
то переход не может сработать, и при отсутствии других переходов объект не может перейти в
целевое состояние по этому переходу.

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

Графически фрагмент логики моделирования почтовой программы может быть представлен в


виде следующей диаграммы состояний (рис. 7.4). При необходимости получить новую почту,
пользователь должен установить телефонное соединение с провайдером, что и показано явно на
диаграмме верхним переходом. Другими словами, пользователь инициирует событие-триггер
"установить телефонное соединение". В качестве параметра этого события выступает конкретный
телефонный номер провайдера. Далее следует проверка сторожевого условия "телефонное
соединение установлено", которое следует понимать как вопрос. Только в случае положительного
ответа "да", т. е. "истина", происходит переход почтовой программы-клиента из состояния
"активизация почтовой программы" в состояние "загрузка почты с сервера провайдера". В противном
случае (линия занята, неверный ввод пароля, отключенный логин) никакой загрузки почты не
произойдет, и программа останется в прежнем своем состоянии.

Рис. 7.4. Диаграмма состояний для моделирования почтовой программы-клиента

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


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

7.3.3. Выражение действия

Выражение действия (action expression) выполняется в том и только в том случае, когда переход
срабатывает. Представляет собой атомарную операцию (достаточно простое вычисление),
выполняемую сразу после срабатывания соответствующего перехода до начала каких бы то ни было
действий в целевом состоянии. Атомарность действия означает, что оно не может быть прервано
53
никаким другим действием до тех пор, пока не закончится его выполнение. Данное действие может
оказывать влияние как на сам объект, так и на его окружение, если это с очевидностью следует из
контекста модели. Выражение записывается после знака "/" в строке текста, присоединенной к
соответствующему переходу.

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

В качестве примера выражения действия (см. рис. 7.4) может служить "разорвать телефонное
соединение (телефонный номер), которое должно быть выполнено сразу после установления
истинности ("истина") сторожевого условия "почтовый ящик на сервере пуст".

Другим примером может служить очевидная ситуация с выделением графических объектов на


экране монитора при однократном нажатии левой кнопки мыши. В этом случае соответствующий
переход может иметь следующую строку текста: "нажата и отпущена левая кнопка мыши
(координаты) [координаты в области графического объекта] / выделить объект (цвет). Результатом
этого триггерного перехода может быть, например, активизация некоторых свойств объекта (размер
файла в строке состояния) или последующее его удаление в корзину.

7.4. Составное состояние и подсостояние


Составное состояние (composite state) - такое сложное состояние, которое состоит из других
вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния
(substate). Хотя между ними имеет место отношение композиции, графически все вершины
диаграммы, которые соответствуют вложенным состояниям, изображаются внутри символа
составного состояния (рис. 7.5). В этом случае размеры графического символа составного состояния
увеличиваются, так чтобы вместить в себя все подсостояния.

Рис. 7.5. Графическое представление составного состояния

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

7.4.1. Последовательные подсостояния

Последовательные подсостояния (sequential substates) используются для моделирования такого


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

Для примера рассмотрим в качестве моделируемого объекта обычный телефонный аппарат. Он


может находиться в различных состояниях, одним из которых является состояние дозвона до
абонента. Очевидно, для того чтобы позвонить, необходимо снять телефонную трубку, услышать
тоновый сигнал, после чего набрать нужный телефонный номер. Таким образом, состояние дозвона
до абонента является составным и состоит из двух последовательных подсостояний: "поднять
телефонную трубку" и "набрать телефонный номер". Фрагмент диаграммы состояний для этого
примера содержит одно составное состояние и два последовательных подсостояний (рис. 7.6).

Рис. 7.6. Пример составного состояния с двумя вложенными последовательными подсостояниями

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


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

Составное состояние может содержать в качестве вложенных подсостояний начальное и конечное


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

7.4.2. Параллельные подсостояния

Параллельные подсостояния (concurrent substates) позволяют специфицировать два и более


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

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


последовательных подсостояний (подавтоматы 1 и 2 на рис. 7.7). В этом случае по определению
55
объект может находиться только в одном из последовательных подсостояний подавтомата. Таким
образом, для абстрактного примера (рис. 7.7 допустимо одновременное нахождение объекта в
подсостояниях (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Недопустимо нахождение объекта одновременно в
подсостояниях (1, 2,3) или (3, 4, 5).

Рис. 7.7. Графическое изображение составного состояния с вложенными параллельными


подсостояниями

Поскольку каждый регион вложенного состояния специфицирует некоторый подавтомат, то для


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

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

Пример диаграммы состояний, которая представляет собой моделирования поведения


конкретного объекта - процесса функционирования телефонного аппарата (рис. 7.8). Данная
диаграмма состояний представляет единственный автомат с одним составным состоянием. Вне этого
составного состояния имеется только одно состояние "ожидание", которое характеризует исправный
и подключенный к телефонной сети телефонный аппарат. Переход в следующее состояние
происходит при поднятии телефонной трубки. Переход с атомарным действием "подать тоновый
сигнал" переводит аппарат в составное состояние, а точнее - в начальное его подсостояние.

56
Рис. 7.8. Диаграмма состояний процесса функционирования телефонного аппарата

Далее телефонный аппарат будет находиться в состоянии "тоновый сигнал". При этом будет
непрерывно издавать этот сигнал до тех пор, пока не произойдет событие-триггер "набор цифры (п)",
либо не истечет 15 секунд с момента поднятия трубки. В первом случае аппарат перейдет в состояние
"набор номера", а во втором - в состояние "истечение времени ожидания". Последняя ситуация может
быть результатом сомнений по поводу "звонить - не звонить?", следствием чего могут стать гудки в
трубке. При этом нам ничего не остается делать, как опустить ее на рычаг.

При наборе номера выполняется событие-триггер "набор цифры (п) со сторожевым условием
"номер неполный". Это означает, что если набранный телефонный номер не содержит необходимого
количества цифр, то нам следует продолжать набор очередной цифры, оставаясь в состоянии "набор
номера".

Если же набранный номер полный, то можно перейти в состояние "неверный номер" или
"соединение". В случае неверного номера (сторожевое условие "неверный" истинно) ничего не
остается, как покинуть составное состояние, опустив трубку на рычаг. Если же номер верный, то
происходит соединение по этому номеру.

Однако в результате соединения может оказаться, что аппарат абонента занят (переход в
состояние "занято") либо свободен (переход в состояние "звонок у абонента"). В первом случае
можно повторить дозвон, предварительно опустив трубку на рычаг (выход из составного состояния).
Во втором случае происходит проверка сторожевого условия "разговор доступен". Если оно истинно,
что соответствует снятию трубки абонентом, начинается телефонный разговор. В противном случае
(это условие не выполняется, т. е. оно ложно) телефон абонента будет продолжать звонить, извещая
нас об отсутствии последнего либо о невозможности по какой-либо причине вести разговор по
телефону. При этом нам ничего не остается, как опустить трубку на рычаг.

Если же разговор состоялся, то после слов прощания и выполнения сторожевого условия


"подтверждение" на окончание разговора мы снова опускаем трубку. При этом телефонный аппарат
переходит в состояние "ожидание", в котором может находиться неопределенно долго.
57
8. Диаграмма деятельности (activity diagram)
Для моделирования процесса выполнения операций в языке UML используются так называемые
диаграммы деятельности. Применяемая в них графическая нотация во многом похожа на нотацию
диаграммы состояний, поскольку на диаграммах деятельности также присутствуют обозначения
состояний и переходов. Отличие заключается в семантике состояний, которые используются для
представления не деятельностей, а действий, и в отсутствии на переходах сигнатуры событий.
Каждое состояние на диаграмме деятельности соответствует выполнению некоторой элементарной
операции, а переход в следующее состояние срабатывает только при завершении этой, операции в
предыдущем состоянии. Графически диаграмма деятельности представляется в форме графа
деятельности, вершинами которого являются состояния действия, а дугами - переходы от одного
состояния действия к другому.

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

В контексте языка UML деятельность (activity) представляет собой некоторую совокупность


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

8.1. Состояние действия


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

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


стороны которого заменены выпуклыми дугами (рис. 8.1). Внутри этой фигуры записывается
выражение действия (action-expression), которое должно быть уникальным в пределах одной
диаграммы деятельности.

Рис. 8.1. Графическое изображение состояния действия

Действие может быть записано на естественном языке, некотором псевдокоде или языке
программирования. Никаких дополнительных или неявных ограничений при записи действий не
накладывается. Рекомендуется в качестве имени простого действия использовать глагол с
пояснительными словами (рис. 8.1 а). Если же действие может быть представлено в некотором
формальном виде, то целесообразно записать его на том языке программирования, на котором
предполагается реализовывать конкретный проект (рис. 8.1, б).

58
Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное
действие, которое, в свою очередь, состоит из нескольких более простых действий. В этом случае
можно использовать специальное обозначение так называемого состояния под-деятельности
(subactivity state). Такое состояние является графом деятельности и обозначается специальной
пиктограммой в правом нижнем углу символа состояния действия (рис. 8.2). Эта конструкция может
применяться к любому элементу языка UML, который поддерживает "вложенность" своей структуры.
При этом пиктограмма может быть дополнительно помечена типом вложенной структуры.

Рис. 8.2. Графическое изображение состояния под-деятельности

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное


состояния.

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

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

В качестве примера рассмотрим как (рис. 8.3) рассчитывается общая стоимость товаров,
покупаемых по кредитной карточке в супермаркете. Если эта стоимость превышает $50, то
выполняется аутентификация личности владельца карточки. В случае положительной проверки
(карточка действительная) или если стоимость товаров не превышает $50, происходит снятие суммы
со счета и оплата стоимости товаров. При отрицательном результате (карточка недействительная)
оплаты не происходит, и товар остается у продавца.

59
Рис. 8.3. Различные варианты ветвлений на диаграмме деятельности

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

Как правило, такая черточка изображается отрезком горизонтальной линии, толщина которой
несколько шире основных сплошных линий диаграммы деятельности. При этом разделение
(concurrent fork) имеет один входящий переход и несколько выходящих (рис. 8.4, а). Слияние
(concurrent join), наоборот, имеет несколько входящих переходов и один выходящий (рис. 8.4, б).

Рис. 8.4. Графическое изображение разделения и слияния параллельных потоков управления

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


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

60
Рис. 8.5. Диаграмма деятельности для примера с приготовлением напитка

8.3. Дорожки
Диаграммы деятельности могут быть использованы не только для спецификации алгоритмов
вычислений или потоков управления в программных системах. Не менее важная область их
применения связана с моделированием бизнес-процессов. Действительно, деятельность любой
компании (фирмы) также представляет собой не что иное, как совокупность отдельных действий,
направленных на достижение требуемого результата. Однако применительно к бизнес-процессам
61
желательно выполнение каждого действия ассоциировать с конкретным подразделением компании. В
этом случае подразделение несет ответственность за реализацию отдельных действий, а сам бизнес-
процесс представляется в виде переходов действий из одного подразделения к другому.

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


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

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

В качестве примера рассмотрим фрагмент диаграммы деятельности торговой компании,


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

Рис. 8.6. Фрагмент диаграммы деятельности для торговой компании

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

62
8.4. Объекты
В общем случае действия на диаграмме деятельности выполняются над теми или иными
объектами. Эти объекты либо инициируют выполнение действий, либо определяют некоторый
результат этих действий. При этом действия специфицируют вызовы, которые передаются от одного
объекта графа деятельности к другому. Поскольку в таком ракурсе объекты играют определенную
роль в понимании процесса деятельности, иногда возникает необходимость явно указать их на
диаграмме деятельности. Для графического представления объектов используются прямоугольник
класса, с тем отличием, что имя объекта подчеркивается. Далее после имени может указываться
характеристика состояния объекта в прямых скобках. Такие прямоугольники объектов
присоединяются к состояниям действия отношением зависимости пунктирной линией со стрелкой.
Соответствующая зависимость определяет состояние конкретного объекта после выполнения
предшествующего действия. На диаграмме деятельности с дорожками расположение объекта может
иметь некоторый дополнительный смысл. А именно, если объект расположен на границе двух
дорожек, то это может означать, что переход к следующему состоянию действия в соседней дорожке
ассоциирован с готовностью некоторого документа (объект в некотором состоянии). Если же объект
целиком расположен внутри дорожки, то и состояние этого объекта целиком определяется
действиями данной дорожки.

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


объектом процесса продажи является заказ или вернее состояние его выполнения. Вначале до звонка
от клиента заказ как объект отсутствует и возникает лишь после такого звонка. Однако этот заказ еще
не заполнен до конца, поскольку требуется еще подобрать конкретный товар в отделе продаж. После
его подготовки он передается на склад, где вместе с отпуском товара заказ окончательно
дооформляется. Наконец, после получения подтверждения об оплате товара эта информация
заносится в заказ, и он считается выполненным и закрытым (рис. 8.7).

Рис. 8.7. Фрагмент диаграммы деятельности торговой компании с объектом-заказом

63
9. Диаграмма компонентов (component diagram)
Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели
системы и относились к логическому уровню представления. Особенность логического
представления заключается в том, что оно оперирует понятиями, которые не имеют самостоятельного
материального воплощения. Другими словами, различные элементы логического представления,
такие как классы, ассоциации, состояния, сообщения, не существуют материально или физически.
Они лишь отражают наше понимание структуры физической системы или аспекты ее поведения.

Основное назначение логического представления состоит в анализе структурных и


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

Полный проект программной системы представляет собой совокупность моделей логического и


физического представлений, которые должны быть согласованы между собой. В языке UML для
физического представления моделей систем используются так называемые диаграммы реализации
(implementation diagrams), которые включают в себя две отдельные канонические диаграммы:
диаграмму компонентов и диаграмму развертывания.

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности


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

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

 Визуализации общей структуры исходного кода программной системы.


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

В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и


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

9.1. Компоненты
Для представления физических сущностей в языке UML применяется специальный термин -
компонент (component). Компонент реализует некоторый набор интерфейсов и служит для общего
обозначения элементов физического представления модели. Для графического представления
компонента может использоваться специальный символ - прямоугольник со вставленными слева
двумя более мелкими прямоугольниками (рис. 1). Внутри объемлющего прямоугольника
записывается имя компонента и, возможно, некоторая дополнительная информация. Изображение

64
этого символа может незначительно варьироваться в зависимости от характера ассоциируемой с
компонентом информации.

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


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

Рис. 9.1. Графическое изображение компонента в языке UML

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

9.1.1. Имя компонента

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

Если же компонент представляется на уровне экземпляра, то в качестве его имени записывается


<имя компонента ':' имя типаХ При этом вся строка имени подчеркивается.

В качестве простых имен принято использовать имена исполняемых файлов (с указанием


расширения ехе после точки-разделителя), имена динамических библиотек (расширение dll), имена
Web-страниц (расширение html), имена текстовых файлов (расширения txt или doc) или файлов
справки (hip), имена файлов баз данных (DB) или имена файлов с исходными текстами программ
(расширения h, cpp для языка C++, расширение Java для языка Java), скрипты (pi, asp) и др.

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


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

9.1.2. Виды компонентов

Поскольку компонент как элемент физической реализации модели представляет отдельный


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

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

В языке UML выделяют три вида компонентов.

 Во-первых, компоненты развертывания, которые обеспечивают непосредственное выполнение


системой своих функций. Такими компонентами могут быть динамически подключаемые
библиотеки с расширением dll (рис. 9.2, а), Web-страницы на языке разметки гипертекста с
расширением html (рис. 9.2, б) и файлы справки с расширением htр (рис. 9.2, в).
 Во-вторых, компоненты-рабочие продукты. Как правило - это файлы с исходными текстами
программ, например, с расширениями h или срр для языка C++ (рис. 9.2, г).
 В-третьих, компоненты исполнения, представляющие исполнимые модули - файлы с
расширением ехе. Они обозначаются обычным образом.

Рис. 9.2. Варианты графического изображения компонентов на диаграмме компонентов

Эти элементы иногда называют артефактами, подчеркивая при этом их законченное


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

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


компонента перед его именем. В языке UML для компонентов определены следующие стереотипы:

 Библиотека (library) - определяет первую разновидность компонента, который представляется


в форме динамической или статической библиотеки.
 Таблица (table) - также определяет первую разновидность компонента, который
представляется в форме таблицы базы данных.
 Файл (file) - определяет вторую разновидность компонента, который представляется в виде
файлов с исходными текстами программ.
 Документ (document) - определяет вторую разновидность компонента, который представляется
в форме документа.
 Исполнимый (executable) - определяет третий вид компонента, который может исполняться в
узле.

9.2. Интерфейсы
Следующим элементом диаграммы компонентов являются интерфейсы. Напомним, что в общем
случае интерфейс графически изображается окружностью, которая соединяется с компонентом
отрезком линии без стрелок (рис. 9.3, а). При этом имя интерфейса, которое обязательно должно
начинаться с заглавной буквы "I", записывается рядом с окружностью. Семантически линия означает
реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент
реализует соответствующий набор интерфейсов.

66
Рис. 9.3. Графическое изображение интерфейсов на диаграмме компонентов

Другим способом представления интерфейса на диаграмме компонентов является его


изображение в виде прямоугольника класса со стереотипом "интерфейс" и возможными секциями
атрибутов и операций (рис. 9.3, б). Как правило, этот вариант обозначения используется для
представления внутренней структуры интерфейса, которая может быть важна для реализации.

При разработке программных систем интерфейсы обеспечивают не только совместимость


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

9.3. Зависимости
Напомним, что зависимость не является ассоциацией, а служит для представления только факта
наличия такой связи, когда изменение одного элемента модели оказывает влияние или приводит к
изменению другого элемента модели. Отношение зависимости на диаграмме компонентов
изображается пунктирной линией со стрелкой, направленной от клиента (зависимого элемента) к
источнику (независимому элементу).

Зависимости могут отражать связи модулей программы на этапе компиляции и генерации


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

В первом случае рисуют стрелку от компонента-клиента к импортируемому интерфейсу (рис. 9.4).


Наличие такой стрелки означает, что компонент не реализует соответствующий интерфейс, а
использует его в процессе своего выполнения. Причем на этой же диаграмме может присутствовать и
другой компонент, который реализует этот интерфейс. Так, например, изображенный ниже фрагмент
диаграммы компонентов представляет информацию о том, что компонент с именем "main.exe"
зависит от импортируемого интерфейса I Dialog, который, в свою очередь, реализуется компонентом
с именем "image.java". Для второго компонента этот же интерфейс является экспортируемым.

67
Рис. 9.4. Фрагмент диаграммы компонентов с отношением зависимости

Заметим, что изобразить второй компонент с именем "image.java" в форме варианта примечания
нельзя именно в силу того факта, что этот компонент реализует интерфейс.

Другим случаем отношения зависимости на диаграмме компонентов является отношение между


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

Рис. 9.5. Графическое изображение отношения зависимости между компонентами

Наконец, на диаграмме компонентов могут быть представлены отношения зависимости между


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

Рис. 9.6. Графическое изображение зависимости между компонентом и классами


68
Следует заметить, что в данном случае из диаграммы компонентов не следует, что классы
реализованы этим компонентом. Если требуется подчеркнуть, что некоторый компонент реализует
отдельные классы, то для обозначения компонента используется расширенный символ
прямоугольника. При этом прямоугольник компонента делится на две секции горизонтальной линией.
Верхняя секция служит для записи имени компонента, а нижняя секция - для указания
дополнительной информации (рис. 9.7).

Рис. 9.7. Графическое изображение компонента с дополнительной информацией о реализуемых


им классах

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

Рис. 9.8. Графическое изображение компонента уровня экземпляра, реализующего отдельные


объекты

Объекты, которые находятся в отдельном компоненте-экземпляре, изображаются вложенными в


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

69
10. Диаграмма развертывания (deployment diagram)
Физическое представление программной системы не может быть полным, если отсутствует
информация о том, на какой платформе и на каких вычислительных средствах она реализована.
Конечно, если разрабатывается простая программа, которая может выполняться локально на
компьютере пользователя, не задействуя никаких периферийных устройств и ресурсов, то в этом
случае нет необходимости в разработке дополнительных диаграмм. Однако при разработке
корпоративных приложений ситуация представляется совсем по-другому.

Во-первых, сложные программные системы могут реализовываться в сетевом варианте на


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

Во-вторых, интеграция программной системы с Интернетом определяет необходимость решения


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

Наконец, технологии доступа и манипулирования данными в рамках общей схемы "клиент-


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

Первой из диаграмм физического представления является диаграмма компонентов. Второй


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

Диаграмма развертывания предназначена для визуализации элементов и компонентов программы,


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

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


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

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

 Определить распределение компонентов системы по ее физическим узлам.

70
 Показать физические связи между всеми узлами реализации системы на этапе ее исполнения.
 Выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой
производительности.

Для обеспечения этих требований диаграмма развертывания разрабатывается совместно


системными аналитиками, сетевыми инженерами и системотехниками.

10.1. Узел
Узел (node) представляет собой некоторый физически существующий элемент системы,
обладающий некоторым вычислительным ресурсом. В качестве вычислительного ресурса узла может
рассматриваться наличие по меньшей мере некоторого объема электронной или магнитооптической
памяти и/или процессора. В последней версии языка UML понятие узла расширено и может включать
в себя не только вычислительные устройства (процессоры), но и другие механические или
электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и
манипуляторы.

Графически на диаграмме развертывания узел изображается в форме трехмерного куба (строго


говоря, псевдотрехмерного прямоугольного параллелепипеда). Узел имеет собственное имя, которое
указывается внутри этого графического символа. Сами узлы могут представляться как в качестве
типов (рис. 10.1, а), так и в качестве экземпляров (рис. 10.1, б).

Рис. 10.1. Графическое изображение узла на диаграмме развертывания

В первом случае имя узла записывается без подчеркивания и начинается с заглавной буквы. Во
втором имя узла-экземпляра записывается в виде <имя узла ':' имя типа узла>. Имя типа узла
указывает на некоторую разновидность узлов, присутствующих в модели системы.

Например, аппаратная часть системы может состоять из нескольких персональных компьютеров,


каждый из которых соответствует отдельному узлу-экземпляру в модели. Однако все эти узлы-
экземпляры относятся к одному типу узлов, а именно узлу с именем типа "Персональный
компьютер". Так, на представленном выше рисунке (рис. 10.1, а) узел с именем "Сервер" относится к
общему типу и никак не конкретизируется. Второй же узел (рис. 10.1, б) является анонимным узлом-
экземпляром конкретной модели принтера.

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

71
Рис. 10.2. Графическое изображение узла-экземпляра с дополнительной информацией в форме
помеченного значения

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

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


изображениями компонентов (рис. 10.3, б). Важно помнить, что в качестве таких вложенных
компонентов могут выступать только исполняемые компоненты.

Рис. 10.3. Варианты графического изображения узлов-экземпляров с размещаемыми на них


компонентами

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

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

Соединения являются разновидностью ассоциации и изображаются отрезками линий без стрелок.


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

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

Рис. 10.4. Фрагмент диаграммы развертывания с соединениями меходу узлами

Кроме соединений на диаграмме развертывания могут присутствовать отношения зависимости


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

Диаграммы развертывания могут иметь более сложную структуру, включающую вложенные


компоненты, интерфейсы и другие аппаратные устройства. На изображенной ниже диаграмме
развертывания (рис. 10.6) представлен фрагмент физического представления системы удаленного
обслуживания клиентов банка. Узлами этой системы являются удаленный терминал (узел-тип) и
сервер банка (узел-экземпляр).

Рис. 10.5. Диаграмма развертывания с отношением зависимости между узлом и развернутыми на нем
компонентами

73
Рис. 10.6. Диаграмма развертывания для системы удаленного обслуживания клиентов банка

На этой диаграмме развертывания указана зависимость компонента реализации диалога


"dialog.exe" на удаленном терминале от интерфейса lAuthorise, реализованного компонентом
"main.exe", который, в свою очередь, развернут на анонимном узле-экземпляре "Сервер банка".
Последний зависит от компонента базы данных "Клиенты банка", который развернут на этом же узле.

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


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

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


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

Транспортная платформа оснащается собственным микропроцессором, цифровой видеокамерой,


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

На микропроцессоре платформы развернуты программные компоненты для реализации


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

Вариант физического представления этой транспортной системы показан на следующей


диаграмме развертывания (рис. 10.7).

74
Рис. 10.7. Диаграмма развертывания для модели системы управления транспортной платформой

Данная диаграмма содержит самую общую информацию о развертывании рассматриваемой


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

75