Р. А. Галимов, Ф. Г. Ахмадиев
МОДЕЛИРОВАНИЕ
ИНФОРМАЦИОННЫХ СИСТЕМ
В STARUML:
ТЕОРИЯ И ПРАКТИКА UML

Казанский государственный архитектурно-строительный университет
Кафедра информационных систем и технологий в строительстве
Р. А. Галимов
Ф. Г. Ахмадиев
МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ
СИСТЕМ В STARUML:
ТЕОРИЯ И ПРАКТИКА UML
Учебное пособие
ISBN 978-5-00254-206-2

УДК 004(075.8)
ББК 16.33я73
Г15
Авторы:
Галимов Руслан Атласович, кандидат технических наук, доцент
(Казанский государственный архитектурно-строительный университет)
Ахмадиев Фаил Габдулбарович, доктор технических наук, профессор
(Казанский государственный архитектурно-строительный университет)
Рецензент:
Зиганшин Арслан Маликович, доктор технических наук, профессор, зав. кафедрой
(Казанский государственный архитектурно-строительный университет)
Галимов, Руслан Атласович.
Г15 Моделирование информационных систем в StarUML: теория и практика UML :
учебное пособие / Р. А. Галимов, Ф. Г. Ахмадиев ; Казанский гос. архитектурно¬
строительный ун-т, Каф. информационных систем и технологий в строитель¬
стве. — Казань : Бук, 2025. — 159 с. — Текст : электронный.
ISBN 978-5-00254-206-2.
Учебное пособие содержит описание унифицированного языка моделирования
UML и набор рекомендаций по применению языка для анализа и проектирова¬
ния программных систем в платформе StarUML.
Пособие может быть рекомендовано студентам направления подготовки 09.03.02
«Информационные системы и технологии», изучающим дисциплины «Модели¬
рование систем», «Архитектура информационных систем», «Методы и средства
проектирования информационных систем», «Корпоративные информацион¬
ные системы», «Объектно-ориентированный анализ и моделирование», может
служить справочным материалом при выполнении расчетно-графических, кур¬
совых и дипломных работ и быть полезным для специалистов, проектирующих
информационные системы.
УДК 004(075.8)
ББК 16.33я73
© Галимов Р. А., Ахмадиев Ф. Г., 2025

СОДЕРЖАНИЕ
Введение	5
1.	Основные понятия моделирования систем	6
1.1	Основные понятия методологии ООАП	6
2.	Unified Modeling Language (UML)	9
2.1	Водопадная модель процесса разработки	12
2.2	Спецификация	14
2.3	Проектирование	15
2.4	Способы использования UML	17
2.5	Модель и ее элементы	18
2.5	Диаграммы	20
3.	Диаграмма вариантов использования (use-case diagram)	22
3.1	Теоретическая часть	22
3.2	Практическая часть	33
3.3	Практические задания	39
3.4	Контрольные вопросы	41
4.	Диаграмма классов (class diagram)	42
4.1	Теоретическая часть	42
4.2	Практическая часть	56
4.3	Практические задания	63
4.4	Контрольные вопросы	64
5.	Диаграмма деятельности (activity diagram)	66
5.1	Теоретическая часть	66
5.2	Практическая часть	77
5.3	Практические задания	79
5.4	Контрольные вопросы	81
6.	Диаграмма состояний (statechart diagram)	82
6.1	Теоретическая часть	82
6.2	Практическая часть	98
6.3	Практические задания	101
6.4	Контрольные вопросы	103
7.	Диаграмма последовательности (sequence diagram)	104
7.1	Теоретическая часть	104
7.2	Практическая часть	111
3

7.3	Практические задания	114
7.4	Контрольные вопросы	116
8.	Диаграмма кооперации (collaboration diagram)	117
8.1	Теоретическая часть	117
8.2	Практическая часть	122
8.3	Практические задания	123
8.4	Контрольные вопросы	125
9.	Диаграмма объектов (object diagram)	126
9.1	Теоретическая часть	126
9.2	Практическая часть	127
9.3	Практические задания	129
9.4	Контрольные вопросы	130
10.	Диаграмма компонентов (component diagram)	132
10.1	Теоретическая часть	132
10.2	Практическая часть	137
10.3	Практические задания	138
10.4	Контрольные вопросы	140
11.	Диаграмма развертывания (deployment diagram)	141
11.1	Теоретическая часть	141
11.2	Практическая часть	143
11.3	Практические задания	145
11.4	Контрольные вопросы	147
12.	Процесс разработки (development process)	148
12.1	Представления	148
12.2	Пять представлений	148
12.3	Восемь представлений	149
12.4	Три представления	150
12.5	Советы по применению UML	152
Список используемых источников	155
Приложение 1	156
4

ВВЕДЕНИЕ
Компьютерные технологии — самая динамично развивающаяся область,
аккумулирующая новейшие научно-технические достижения. Развитие
информационных технологий (ИТ) характеризуется постоянным усложнением
программного обеспечения, что вызвано рядом факторов:
•	высокой сложностью предметных областей и их описаний;
•	необходимостью интеграции новых и существующих приложений;
•	функционированием в неоднородной среде на разных платформах;
•	потребностью в поддержании единого стиля для постоянно
развивающихся версий;
•	разнородностью команд разработчиков.
Сложность — неотъемлемое свойство современного программного
обеспечения (ПО), и многие проблемы проистекают из ее роста. Поэтому
проектирование модели информационной системы (ИС) перед ее реализацией так
же необходимо, как и проект для строительства большого здания.
Настоящее учебное пособие посвящено теоретическим основам и
практическому применению унифицированного языка моделирования UML в
среде визуального проектирования StarUML. UML является промышленным
стандартом для визуализации, специфицирования, конструирования и
документирования артефактов программных систем.
Цель пособия — дать систематизированное представление о ключевых
понятиях объектно-ориентированного анализа и проектирования (ООАП) и
научить эффективно использовать различные типы UML-диаграмм для решения
задач анализа, проектирования и документирования на всех этапах разработки
программного обеспечения.
Материал структурирован по принципу «от теории к практике»: каждый
раздел содержит теоретическое описание элементов диаграммы и пошаговое
руководство по ее созданию в StarUML, подкрепленное практическими заданиями
и контрольными вопросами.
Пособие предназначено	для студентов, изучающих дисциплин
«Моделирование систем», «Архитектура информационных систем», «Методы и
средства проектирования информационных систем», «Корпоративные
информационные системы»,	«Объектно-ориентированный	анализ и
моделирование», и может быть использовано как справочный материал при
выполнении курсовых и дипломных работ, а также будет полезно специалистам,
занимающимся проектированием информационных систем.
5

1.	ОСНОВНЫЕ ПОНЯТИЯ МОДЕЛИРОВАНИЯ СИСТЕМ
Создание современных программных приложений — это коллективная
работа, в которой участвуют специалисты разного профиля. Чтобы обеспечить их
слаженное взаимодействие, необходимо единое понимание архитектуры и
функциональности будущей системы. Эту задачу решает построение понятной
для всех участников проекта (включая заказчика) модели до начала написания
кода.
Данная потребность стала катализатором перехода от «кустарных» методов к
индустриальным, что привело к появлению программной инженерии. Её
ключевая идея заключается в том, что разработка ПО — это формальный,
управляемый процесс, изучение и совершенствование которого напрямую влияет
на качество и долговечность продукта.
В развитии программной инженерии выделяют два ключевых этапа:
1.	1970-1980-е гг.: Эра структурного подхода, основанного на
декомпозиции системы на простые, независимо разрабатываемые части.
2.	1990-е гг.: Переход к объектно-ориентированному подходу, вызванный
ростом сложности систем и появлением соответствующих языков
программирования.
Объектно-ориентированный подход предполагает проектирование системы
как совокупности взаимодействующих объектов — экземпляров определенных
классов. Это позволило повысить производительность труда, создавать более
компактные и легко расширяемые программы.
На основе этого подхода сформировалась целостная методология —
объектно-ориентированный анализ и проектирование (ООАП). Её суть
заключается в моделировании предметной области через взаимодействующие
классы, которые объединяют в себе данные и поведение.
1.1	Основные понятия методологии ООАП
Фундаментальными понятиями ООАП являются понятия класса и объекта, а
также ее основные принципы: абстракция, инкапсуляция, полиморфизм,
наследование [1].
Класс (class) представляет собой абстракцию совокупности реальных
объектов, которые имеют общий набор свойств и обладают одинаковым
поведением.
Объект (object) в контексте ООАП рассматривается как экземпляр
соответствующего класса.
Определение классов и объектов - одна из самых сложных задач объектно¬
ориентированного анализа и проектирования. Понятия класса и объекта настолько
тесно связаны, что невозможно говорить об объекте безотносительно к его классу.
Однако существует важное различие этих двух понятий. В то время как объект
обозначает конкретную сущность, определенную во времени и пространстве,
класс определяет лишь абстракцию существенного в объекте.
6

Итак, объект обладает состоянием, поведением и идентичностью. Структура
и поведение схожих объектов определяет общий для них класс. Термины
«экземпляр класса» и «объект» взаимозаменяемы [1].
Абстракция (abstraction) - характеристика сущности, которая отличает ее от
других сущностей. Другими словами, она означает сосредоточение на важнейших
аспектах приложения и игнорирование всех остальных. Сначала принимается
решение о том, что представляет собой объект и что он делает, а уже затем
подбирается способ его реализации.
Инкапсуляция (encapsulation) - сокрытие отдельных деталей внутреннего
устройства классов от внешних по отношению к ним объектов или пользователей.
Иначе говоря, сокрытие информации состоит в отделении внешних аспектов
объекта, доступных другим объектам, от деталей внутренней реализации, которые
от них скрываются. Таким образом, инкапсуляция исключает возникновение
взаимосвязей участков программы, из-за которых не большие изменения
приводят к значительным непредвиденным последствиям. Инкапсуляция
позволяет модифицировать реализацию объекта безо всяких последствий для
использующих его приложений.
Полиморфизм (polymorphism) - свойство одноименных методов или
операций выполнять разные действия или обладать различным поведением в
зависимости от того, к какому классу они относятся. Это значит, что одна и та же
операция подразумевает разное поведение в разных классах. При вызове
операции не нужно беспокоиться о том, сколько ее реализаций существует в
системе.
Полиморфизм перекладывает ответственность за выбор подходящей
реализации с вызывающего кода на иерархию классов. Каждый объект выбирает
подходящую процедуру согласно своему классу. Это облегчает поддержку
программ, потому что добавление нового класса не требует изменения
вызывающего кода.
Наследование (inheritance) - принцип, в соответствии с которым знание о
более общей категории разрешается применять для частной. Если родительский
класс обладает фиксированным набором свойств и поведения, то любой
наследуемый от него класс (потомок) должен содержать тот же набор свойств и
поведения, а также иметь дополнительные, которые будут характеризовать его
уникальность. Наследование структур данных вместе с поведением дает
возможность подклассам совместно использовать общий код.
На использовании вышеперечисленных принципов основывается
методология построения объектно-ориентированных моделей [1].
Модель (model) - абстракция произвольной системы или объекта,
рассматриваемая с определенной точки зрения и представленная на некотором
языке или в графической форме. Попросту говоря, она является упрощенным
представлением реальности. Хорошая модель должна описывать важнейшие
аспекты проблемы и опускать все прочие.
Общим свойством всех моделей является их подобие оригинальной системе,
или системе-оригиналу. Необходимость построения моделей заключается в
возможности их использования для получения информации о свойствах или
7

поведении системы оригинала. Модель состоит из множества элементов, которые
совместно описывают моделируемую систему. Основное требование к модели -
она должна быть понятна всем специалистам проектной группы и удобна для
документирования.
Моделирование — это процесс создания и использования моделей. Сложную
систему можно представить тремя взаимосвязанными типами моделей, каждый из
которых отражает свой аспект системы:
•	Модель классов (диаграммы классов) — описывает структуру системы:
объекты, их классы и отношения между ними.
•	Модель состояний (диаграммы состояний) — показывает жизненный цикл
объектов одного класса, последовательность их состояний и реакцию на
события.
•	Модель взаимодействий (диаграммы последовательности, деятельности,
варианты использования) — описывает, как объекты обмениваются
сообщениями для выполнения задач.
Эти модели образуют единое целое: модель классов задаёт структуру
данных, модель состояний — логику поведения объектов, а модель
взаимодействий — их совместную работу.
Возникновение объектно-ориентированного подхода создало потребность в
универсальном языке для визуализации и проектирования. Результатом
многолетней работы специалистов стал UML (Unified Modeling Language),
который объединил лучшие методы моделирования и стал современным
стандартом.
8

2. UNIFIED MODELING LANGUAGE (UML)
UML, который является аббревиатурой полного названия Unified Modeling
Language. Правильный перевод этого названия на русский язык —
унифицированный язык моделирования. Таким образом, обсуждаемый предмет
характеризуется тремя словами, каждое из которых является точным термином
[2].
Язык — это знаковая система для хранения и передачи информации. Языки
делятся на типы по разным признакам. Так, формальные языки имеют строго
определённые правила, в то время как правила неформальных складываются
стихийно на основе практики. Другой критерий — происхождение: естественные
языки возникают исторически, а искусственные создаются целенаправленно
конкретными людьми.
UML можно классифицировать как формальный искусственный язык, хотя
его строгость уступает большинству языков программирования. Одним из
доказательств его искусственного происхождения является наличие трёх
конкретных авторов [2]. (Рис. 1):
. ; шл
Grady Booch
James Rumbaugh Ivar Jacobson
Грэди Буч
Айвар Якобсон
Джеймс Рамбо
Рис. 1 Авторы UML
В то же время в формирование языка внесли вклад многие теоретики и
разработчики, имя которым легион. Языкотворческая практика применительно к
UML непрерывно продолжается, что дает основание считать UML до некоторой
степени естественным языком. Описание UML по большей части формальное, но
содержит и явно неформальные составляющие.
Такие особенности UML как точки вариации семантики и стандартные
механизмы расширения, заметно отличают UML от языков, которые, по общему
мнению, являются образцами формализма.
Для описания формальных искусственных языков (в частности, для описания
языков программирования) придумано и используется множество различных
способов. Однако на практике сложилась общепринятая структура таких
описаний.
9

Считается, что формальный искусственный язык описан должным образом,
если это описание содержит по меньшей мере следующие части:
1.	Синтаксис, то есть определение правил конструирования выражений
языка.
2.	Семантика, то есть определение правил приписывания смысла
выражениям языка.
3.	Прагматика, то есть определение правил использования выражений языка
для достижения определенных целей.
Как формальный искусственный язык UML имеет синтаксис, семантику и
прагматику, хотя эти части названы в некоторых случаях иначе и описаны по
другому, нежели это принято в языках программирования.
Слово "моделирование", входящее в название UML, имеет множество
смысловых оттенков и сложившихся способов употребления. Понятно, что когда
мы моделируем, мы что-то такое делаем с моделями, но не совсем понятно, с
какими моделями и что именно делаем. Нам представляется необходимым
остановиться чуть подробнее на смысле слов "модель" и "моделирование" в
контексте UML, в противном случае есть риск упустить главное, погрузившись в
технические детали.
Начать придется издалека и, на первый взгляд, несколько сбоку: с
обсуждения понятий жизненный цикл и процесс разработки программной
системы.
UML имеет отношение прежде всего и главным образом к созданию и
применению компьютерных программ. Давно замечено, что приложение за время
жизни претерпевает многочисленные изменения своей формы, зависящие от
состояния процесса разработки и эксплуатации приложения. Обычно
совокупность и последовательность этих изменений называется жизненный цикл.
В разных парадигмах и технологиях программирования понятие жизненного
цикла определяется и трактуется немного по разному, но в общем близко к схеме,
представленной на Рис. 2. Важно подчеркнуть, что за время своей жизни
программа проходит метаморфозы, как правило, несколько раз, т.е. это именно
цикл, причем не один, а несколько [2].
10

Рис. 2 Жизненный цикл приложения
С понятием жизненного цикла приложения тесно связано понятие процесса
разработки приложения, т.е. определенной последовательности сменяющих друг
друга видов деятельности. В обыденном языке слово "разработка" подразумевает
создание чего-то, а когда это что-то (в данном случае, приложение) создано, то
разработка закончена. Вы прекрасно понимаете, что в случае приложений, после
того, как разработка закончена, начинается самое интересное — эксплуатация,
которая оказывается теснейшим образом связанной с разработкой. Для
приложений отделять друг от друга разработку и эксплуатацию, а тем более
противопоставлять эти понятия, было бы в корне неверно.
В результате понятия жизненного цикла и процесса разработки можно
считать равнообъемными, даже можно сказать, что это две стороны одного
понятия. Когда мы говорим "жизненный цикл", мы смотрим на предмет как бы с
точки зрения программы, которая пассивно переживает одно состояние за другим,
а когда мы говорим "процесс разработки", мы смотрим на тот же самый предмет с
точки зрения программиста, который активно выполняет одно действие за
другим.
Жизненный цикл и процесс разработки каждого конкретного приложения
индивидуальны, и потому они не представляют большого интереса. Для широкого
11

круга потребителей более интересно рассмотреть модели жизненного цикла и
процесса разработки.
Модель жизненного цикла и модель процесса разработки взаимно
определяют друг друга и являются согласованными. В каждой организации,
которая специализируется на разработке программного обеспечения, и даже у
особо продвинутых программистов-одиночек (далее такая организация или
человек называются обобщенно — разработчик), существуют свои собственные
модели жизненного цикла и процесса разработки. Конечно, в большинстве
случаев они оказываются очень близки, но все-таки имеют некоторые
индивидуальные особенности. Мы рассматриваем те модели жизненного цикла и
процесса разработки, которые используем сами, стараясь, по возможности,
опускать влияние на них наших собственных индивидуальных особенностей. От
этого наше рассмотрение становится более абстрактным, но, одновременно, более
широко применимым. Вы можете приспосабливать наши модели к своим нуждам,
меняя их в соответствии с конкретными обстоятельствами.
2.1	Водопадная модель процесса разработки
Одной из самых первых моделей процесса разработки была так называемая
модель "водопада", или модель "конвейера". В этой модели процесс разработки
носит линейный характер. Он также делится на фазы, но фазы сменяют друг друга
строго последовательно (так, как выполняются производственные операции над
изделием на конвейере). Таким образом, в процессе разработки программа как бы
опускается с более высоких, абстрактных уровней (ТЗ, эскизный проект и т. п.),
на все более низкие детальные уровни (код, данные в базе и т.п.). Образно говоря,
поток разработки направлен в одну сторону, вниз. Отсюда и происходит название
этой модели [2].
Большинство используемых в настоящее время моделей разработки носят
циклический характер (так называемая итеративная или инкрементальная
разработка). Например, в этой книге мы используем простую модель,
представленную на Рис. 3.
12

В процессе проектирования что-то делается и в результате нечто получается.
Если эта деятельность и форма результата регламентированы определенным
образом, то им уместно дать название. Так сложилось, что результат
проектирования (и анализа), оформленный средствами определенного языка
принято называть моделью. Деятельность по составлению моделей естественно
назвать моделированием. Именно в этом смысле UML является языком
моделирования.
Таким образом, модель UML — это, прежде всего, основной артефакт фазы
проектирования, а также и кое-что другое, а именно все, что авторам UML
удалось включить в язык, не нарушая принципа, к изложению которого мы
переходим в следующем разделе.
В литературе по технологии программирования часто используется одна
аналогия, которую считается довольно убедительной. Рассмотрим такую область
человеческой деятельности, как архитектура и строительство. В проектировании и
строительстве домов (по индивидуальному проекту) есть много общего с
разработкой приложений. В обоих случаях требуется как творческий подход, так
и большой объем рутинной работы; применяются как формальные, так и
неформальные методы; очень многое зависит от опыта и квалификации
разработчика; конечный результат оценивается степенью удовлетворенности
заказчика. Таким образом, аналогия имеет место [2]. Но есть одно различие,
которое сразу бросается в глаза. В архитектуре и строительстве очень широко
используются чертежи. Чертежи разные — рисунки архитектора с общим видом
будущего здания, детальные строительные чертежи, по которым ведется
строительство, различные вспомогательные схемы инженерных коммуникаций и
др. Конечно, садовый домик можно построить без всяких чертежей, "на глазок",
13

но с чертежами обычно получается все-таки лучше. Наверное, можно
попробовать построить и трехэтажный дом, не пользуясь чертежами, хотя
результат вряд ли будет надежным и красивым. Но высотный дом нельзя
построить без тщательного предварительного проектирования, учета
строительных норм и правил (СНИП) и составления огромного количества
разнообразных чертежей.
Между тем, при разработке приложений слишком часто приходиться
наблюдать, как неопытные разработчики проскакивают фазу проектирования и
получив техническое задание, сразу приступают к реализации, т.е. начинают
"класть кирпичи" [2]. Если при этом спросить их: "А где же чертеж будущего
приложения?", то они даже не понимают вопроса. Если речь идет о приложении
типа "садовый домик", то такой подход может сработать — помогут опыт и чутье.
Но если нужно построить высотный дом? Без чертежей не обойтись! В солидном
приложении деталей (функций, процедур, модулей, форм, элементов управления,
операторов) не меньше, а больше, чем в высотном доме отдельных строительных
деталей. Отсюда и наблюдаемое соотношение результативности: случай
обрушения дома из-за ошибок проектирования — это ЧП, которое случается
очень редко. Что же касается разработки приложений, то по данным некоторых
авторов, свыше половины проектов по разработке оканчиваются неудачей: не
доводятся до конца, прекращаются из-за перерасхода времени и средств, имеют
неудовлетворительный результат и т.д. Анализ показывает, что в подавляющем
большинстве случаев причина неудач кроется в плохом проектировании [2].
Одним из объективных факторов, объясняющих такое положение дел,
является сравнительная молодость программирования, как инженерной
дисциплины. Архитекторы и строители накапливали опыт тысячелетиями, а
чертежами пользуются уже столетия. У них было время придумать понятную,
удобную и надежную систему обозначений.
История разработки приложений насчитывает всего полвека. Сейчас только-
только появляются системы обозначений, сравнимые по выразительности и
удобству со строительными чертежами (и наиболее перспективным нам
представляется UML).
Другими словами, ощущается дефицит инженерно проработанных средств
проектирования приложений. Это обстоятельство создает дополнительные
трудности для разработчиков, но не может служить оправданием для
безответственного "проскакивания" фазы проектирования.
2.2	Спецификация
В типичных случаях разработки приложений участвуют по меньше мере два
действующих лица: заказчик (конкретный человек, или группа лиц, или
организация) и разработчик (это может быть программист-одиночка, временная
команда проекта или целая организация, специализирующаяся на разработке
приложений). Из-за того, что действующих лиц двое, очень многое зависит от
степени их взаимопонимания [2].
14

Одним из ключевых этапов разработки приложения является определение
того, что, собственно, должно делать разрабатываемое приложение. В результате
этого этапа появляется формальный или неформальный документ (артефакт),
который называют по-разному, имея в виду примерно одно и то же: постановка
задачи, пользовательские требования, техническое задание, внешние
спецификации и др.
Аналогичные по назначению, но, может быть, отличные по форме и
содержанию артефакты появляются и на других этапах разработки, особенно если
в разработку включено много действующих лиц. Для них также используются
различные названия: функциональные спецификации, архитектура приложения и
др. Мы будем все такие артефакты называть спецификациями.
Спецификация — это декларативное описание того, как нечто устроено или
работает. Необходимо принимать во внимание три толкования спецификаций.
1.	То, которое имеет в виду действующее лицо, являющееся источником
спецификации (например, заказчик).
2.	То, которое имеет в виду действующее лицо, являющееся потребителем
спецификации (например, разработчик).
3.	То, которое объективно обусловлено природой специфицируемого
объекта.
Эти три трактовки спецификаций могут не совпадать, и, к сожалению, как
показывает практика, сплошь и рядом не совпадают, причем значительно.
Заказчик может не осознавать своих объективных потребностей, или неверно их
интерпретировать, или заблуждаться относительно природы своих затруднений,
пытаясь с помощью заказного офисного приложения лечить симптомы, а не
причину болезни своего бизнеса. Разработчик может не разбираться в предметной
области заказчика и интерпретировать формулировки спецификаций совершенно
превратным образом. Если же в формулировке спецификаций участвует
разработчик, то злоупотребление технической терминологией может совершенно
дезориентировать заказчика.
Основное назначение UML — предоставить, с одной стороны, достаточно
формальное, с другой стороны, достаточно удобное, и, с третьей стороны,
достаточно универсальное средство, позволяющее до некоторой степени снизить
риск расхождений в толковании спецификаций.
2.3	Проектирование
В оригинале данное назначение UML определено с помощью слова construct,
которое мы передаем осторожным термином "проектирование". Речь идет о том,
что UML предназначен не только для описания абстрактных моделей
приложений, но и для непосредственного манипулирования артефактами,
входящими в состав этих приложений, в том числе такими, как программный код.
Другими словами, одним из назначений UML является, например, создание таких
моделей, для которых возможна автоматическая генерация программного кода
(точнее, фрагментов кода) соответствующих приложений. Более того, природа
15

моделей UML такова, что возможен и обратный процесс: автоматическое
построение модели по коду готового приложения [2].
Сказанное в предыдущем абзаце требует оговорок "до некоторой степени", "в
известной мере" буквально после каждого утверждения. Самое досадное, что в
данный момент точно указать "степень" и "меру" не представляется возможным.
Причина не в том, что никто не удосужился этим заняться, а в том, что это
очень трудная задача.
Модели UML являются артефактами, которые можно хранить и использовать
как в форме электронных документов, и в виде твердой копии. В последних
версиях UML с целью достижения более полного соответствия этому назначению
сделано довольно много. В частности, специфицировано представление моделей
UML в форме документов в формате XMI10, что обеспечивает практическую
интероперабельность при работе с моделями. Другими словами, модели UML не
являются вещью в себе, которой можно только любоваться — это документы,
которые можно использовать самыми разными способами, начиная с печати
картинок и заканчивая автоматической генерацией человекочитаемых текстовых
описаний [2].
Не следует думать, что UML — это панацея от всех болезней
программирования. Для ясного понимания назначения и области применения
UML полезно сопоставить UML с другими родственными явлениями.
Во-первых, UML не является языком программирования (хотя генерация
кода не возбраняется, см. предыдущий раздел). Дело не в том, что UML язык
графический, а подавляющее большинство практических языков
программирования являются линейными текстовыми языками. Гораздо важнее то,
что для моделей UML не определена операционная семантика, то есть не
определен способ выполнения моделей на компьютере. Это сделано вполне
сознательно, в противном случае UML оказался бы зависимым от некоторой
модели вычислимости, уровень абстрактности его концепций пришлось бы
существенно снизить и он не отвечал бы своему основному назначению: служить
средством спецификации приложений и других систем на любом уровне
абстракции и в различных предметных областях.
Во-вторых, UML не является спецификацией инструмента (хотя
инструменты подразумеваются и имеются, например, Together, Rational Rose,
Visual Paradigm, Microsoft Visio и др.). В последние годы в компьютерной
индустрии широкое распространение получили комплексные системы разработки
приложений, которые обычно называют CASE средствами. В таких системах
разработки предпринимаются попытки согласованным образом поддержать и
обеспечить все фазы процесса разработки приложений, а не только фазы
кодирования и отладки, традиционно поддерживаемые обычными системами
программирования [2].
Поскольку управление спецификациями и проектирование, по общему
мнению, являются важнейшими составляющими процесса разработки
приложений, понятно, что в CASE средствах должно быть предусмотрено нечто,
эквивалентное основному назначению UML. Однако сам язык никоим образом не
навязывает то, как его нужно поддерживать инструментальными средствами.
16

Решение всех вопросов, связанных с реализацией UML на компьютере полностью
отдано на откуп разработчикам инструментов.
В третьих, UML не является моделью процесса разработки приложений (хотя
модель процесса необходима и имеется множество различных. Конечно, у авторов
UML есть собственная модель процесса — Rational Unified Process (RUP),
которую они не могли не иметь в голове, разрабатывая язык, но, тем не менее,
ими сделано все для того, чтобы устранить прямое влияние RUP на UML и
сделать UML пригодным для использования в любой модели процесса или даже
без оной.
2.4	Способы использования UML
Из сказанного выше видно, что UML предназначен для решения различных
задач, соответственно он может быть использован и практически используется по
разному.
Способы использования UML в порядке убывания важности [2]:
•	Рисование картинок. Графические средства UML можно и нужно
использовать безотносительно ко всему остальному. Даже рисование
диаграмм карандашом на бумаге позволяет упорядочить мысли и
зафиксировать для себя существенную информацию о моделируемом
приложении или иной системе. Мы ставим такое использование UML на
первое место по важности.
•	Обмен информацией. Сообщество людей, применяющих и понимающих
UML стремительно растет. Если вы будете использовать UML, то вас будут
понимать другие и вы будете понимать других с полувзгляда.
•	Спецификация систем. Это важнейший способ использования UML. В
нашей оценочной шкале использование UML для спецификации не стоит на
первом месте только потому, что, к сожалению, еще не во всех случаях
UML оказывается абсолютно адекватным средством спецификации
(примеры приведены в других местах книги). Но по мере развития языка все
меньше будет оставаться случаев, в которых UML оставляет желать
лучшего.
•	Повторное использование архитектурных решений. Повторное
использование ранее разработанных решений — ключ к повышению
эффективности. Однако, пока что модели UML повторно используются еще
в ограниченных масштабах. Оценка 0 (золотая середина) означает: хорошо,
но мало.
•	Генерация кода. Генерировать код нужно и можно, но возможности
имеющихся инструментов не стоит переоценивать.
•	Имитационное моделирование. Возможности построения моделей UML, из
которых путем вычислительных экспериментов можно было бы извлекать
информацию о моделируемом объекте, пока что уступают возможностям
специализированных систем, сконструированных для этой цели.
•	Верификация моделей. Было бы замечательно, если бы по модели можно
было бы делать формальные заключения об ее свойствах: модель
17

непротиворечива, согласована, эффективна и т. п. Кое-что UML позволяет
проверить, но, конечно, очень мало. Здесь уместно привести аналогию с
традиционными системами программирования: они позволяют быстро и
надежно избавиться от синтаксических ошибок, но с логическими
ошибками дело обстоит гораздо хуже. Может быть, в будущем...
2.5	Модель и ее элементы
Модель UML — это конечное множество сущностей и отношений между
ними. Сущности и отношения модели — это экземпляры метаклассов
метамодели. Обсуждение этого определения требует использования
общеизвестных математических понятий, которые мы предполагаем известными
[2].
Таким образом, рассматривая модель UML с наиболее общих позиций,
можно сказать, что это граф (точнее, нагруженный мульти-псевдо-гипер-орграф),
в котором вершины и ребра нагружены дополнительной информацией и могут
иметь сложную внутреннюю структуру. Вершины этого графа называются
сущностями, а ребра — отношениями. Остальная часть параграфа содержит
беглый (предварительный), но полный обзор имеющихся типов сущностей и
отношений.
Для удобства обзора сущности в UML можно подразделить на четыре
группы [2]:
•	структурные;
•	поведенческие;
•	группирующие;
•	аннотационные.
Структурные сущности, как нетрудно догадаться, предназначены для
описания структуры. Обычно к структурным сущностям относят следующие.
•	Класс — описание множества объектов с общими атрибутами и
операциями.
•	Интерфейс — множество операций, которое определяет набор услуг
(службу), предоставляемых классом или компонентом.
•	Действующее лицо — сущность, находящаяся вне моделируемой системы и
непосредственно взаимодействующая с ней.
Вариант использования — описание последовательности производимых
системой действий, доставляющей значимый для некоторого действующего лица
результат.
•	Компонент — физически заменяемый артефакт, реализующий некоторый
набор интерфейсов.
•	Узел — физический вычислительный ресурс.
Поведенческие сущности предназначены для описания поведения. Основных
поведенческих сущностей всего две: состояние и действие (точнее, две с
половиной, потому что иногда употребляется еще и деятельность, которая
является частным случаем состояния)
18

Состояние — период в жизненном цикле объекта, в котором объект
удовлетворяет некоторому условию, выполняет деятельность или ожидает
события.
Деятельность — состояние, в котором выполняется работа, а не просто
пассивно ожидается наступление события.
Действие — атомарный неделимый элемент работы.
Это только надводная часть айсберга поведенческих сущностей: состояния
бывают самые разные. Кроме того, при моделировании поведения используется
еще ряд вспомогательных сущностей, которые здесь не перечислены, потому что
сосуществуют только вместе с указанными основными.
Группирующая сущность в UML одна — пакет — зато универсальная.
Пакет — группа элементов модели (в том числе пакетов).
Аннотационная сущность тоже одна — примечание — зато в нее можно
поместить все что угодно, так как содержание примечания UML не ограничивает.
В UML используются четыре основных типа отношений [2]:
•	зависимость;
•	ассоциация;
•	обобщение;
•	реализация.
Зависимость — это наиболее общий тип отношения между двумя
сущностями. Отношение зависимости указывает на то, что изменение
независимой сущности каким-то образом влияет на зависимую сущность.
Графически отношение зависимости изображается в виде пунктирной стрелки,
направленной от независимой сущности к зависимой. Как правило, семантика
конкретной зависимости уточняется в модели с помощью дополнительной
информации.
Например, зависимость со стереотипом «use» означает, что зависимая
сущность использует (скажем, вызывает операцию) независимую сущность.
Ассоциация — это наиболее часто используемый тип отношения между
сущностями. Отношение ассоциации имеет место, если одна сущность
непосредственно связана с другой (или с другими — ассоциация может быть не
только бинарной). Графически ассоциация изображается в виде сплошной линии
с различными дополнениями, соединяющей связанные сущности. На
программном уровне непосредственная связь может быть реализована различным
образом, главное, что ассоциированные сущности знают друг о друге. Например,
отношение часть-целое является частным случаем ассоциации и называется
отношением агрегации.
Обобщение — это отношение между двумя сущностями, одна их которых
является частным (специализированным) случаем другой. В UML отношение
обобщения подразумевает выполнение принципа подстановочности: если
сущность А (общее) суть обобщение сущности Б (частное), то Б может быть
подставлено вместо А в любом контексте. Принцип подстановочности
правомерен, поскольку обобщение подразумевает, что сущность Б обладает всеми
свойствами и поведением сущности А и, возможно, еще чем-то. Графически
19

обобщение изображается в виде сплошной стрелки с треугольником на конце,
направленной от частного к общему.
Отношение наследования между классами в объектно-ориентированных
языках программирования является типичным примером обобщения.
Отношение реализации используется несколько реже, чем предыдущие три
типа отношений, поскольку часто подразумеваются по умолчанию. Отношение
реализации указывает, что одна сущность является реализацией другой.
Например, класс является реализацией интерфейса. Графически реализация
изображается в виде пунктирной стрелки с треугольником на конце,
направленной от реализующей сущности к реализуемой.
Перечисленные типы отношений являются основными, различные их
вариации и дополнительные отношения детально рассматриваются в
последующих главах.
2.5	Диаграммы
Диаграмма — это графическое представление некоторой части графа модели.
Вообще говоря, в диаграмму можно было бы включить любые (допустимые)
комбинации сущностей и отношений, но произвол в этом вопросе затруднил бы
понимание моделей. Поэтому авторы UML определили набор рекомендуемых к
использованию типов диаграмм, которые получили название канонических типов
диаграмм [2].
В UML 1.x всего определено 9 канонических типов диаграмм. Ниже
перечислены их названия, принятые в этой книги (в других источниках есть
отличия).
1.	Диаграмма вариантов использования
2.	Диаграмма классов
3.	Диаграмма деятельности
4.	Диаграмма состояний
5.	Диаграмма последовательности
6.	Диаграмма кооперации
7.	Диаграмма объектов
8.	Диаграмма компонентов
9.	Диаграмма размещения
Этот список является итогом многочисленных дискуссий и компромиссов,
поэтому не следует воспринимать его как догму. В частности, расхожее
утверждение "в UML определены 9 типов диаграмм" является не совсем верным:
в метамодели UML определены элементы модели (сущности и отношения) и
способы их комбинирования, а 9 типов диаграмм — это уже надстройка над
языком, отражающая сложившуюся практику его использования.
Канонические диаграммы отнюдь не образуют полного ортогонального
набора: они пересекаются как по включенным в них средствам, так и по области
применения. Более того, некоторые из них являются частными случаями других,
есть просто семантические эквивалентные пары, можно привести примеры
20

допустимых диаграмм, для которых затруднительно указать однозначно, к какому
именно из канонических типов диаграмма относится.
Сказанное можно проиллюстрировать условной классификацией диаграмм,
приведенной на Рис. 4 [2].
Рис. 4. Иерархия типов диаграмм
21

3.	ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ (USE-CASE DIAGRAM)
3.1	Теоретическая часть
Диаграмма вариантов использования (Use Case Diagram) — это один из
основных инструментов в UML (Unified Modeling Language), который позволяет
визуализировать функциональные требования к системе. Другое название -
Диаграмма прецедентов. Она показывает, какие действия могут выполнять
пользователи (актеры) и какие функции предоставляет система в ответ на эти
действия.
Основные компоненты диаграммы вариантов использования:
1.	Актеры. Это внешние сущности, которые взаимодействуют с системой.
Актеры могут быть пользователями, другими системами или
устройствами.
2.	Варианты использования (прецеденты). Это функциональные возможности
системы, которые описывают, как актеры взаимодействуют с системой для
достижения определенной цели.
Связи:
1.	Ассоциация - соединение между актерами и вариантами использования,
показывающее взаимодействие.
2. Обобщение -	когда один вариант использования является
специализированной версией другого.
3.	Включение обозначает, что один вариант использования включает в себя
другой.
4.	Расширение показывает, как один вариант использования может быть
расширен другим вариантом использования при определенных условиях.
Прецеденты - это технология определения функциональных требований к
системе. Работа прецедентов заключается в описании типичных взаимодействий
между пользователями системы и самой системой и предоставлении описания
процесса ее функционирования. Создание диаграммы прецедентов лучше начать с
описания сценариев.
Сценарий (scenario) - это последовательность шагов, описывающих
взаимодействие пользователя и системы. Поэтому при наличии онлайнового
магазина, основанного на вебсайте, мы можем использовать сценарий «Покупка
товара», в котором происходит следующее:
Покупатель просматривает каталог и помещает выбранные то вары в
корзину. При желании оплатить покупку он вводит информацию о кредитной
карте и производит платеж. Система проверяет авторизацию кредитной карты и
подтверждает оплату товара тотчас же и по электронной почте.
Подобный сценарий описывает только одну ситуацию, которая может иметь
место. Однако если авторизация кредитной карты окажется не удачной, то
подобная ситуация может послужить предметом уже другого сценария. В другом
случае у вас может быть постоянный клиент, для которого проверка информации
о покупке и кредитной карте не обязательна, и это будет третий сценарий. Так
или иначе, но все эти сценарии похожи. Суть в том, что во всех трех сценариях у
22

пользователя одна и та же цель: купить товар. Пользователь не всегда может это
сделать, но цель остается. Именно цель пользователя является ключом к
прецедентам:
Прецедент представляет собой множество сценариев, объединенных
некоторой общей целью пользователя.
В терминах прецедента пользователи называются актерами. Актер (actor)
представляет собой некую роль, которую пользователь играет по отношению к
системе. Актерами могут быть пользователь, торговый представитель
пользователя, менеджер по продажам и товаровед.
Актеры действуют в рамках прецедентов. Один актер может выполнять
несколько прецедентов; и наоборот, в соответствии с одним пре цедентом могут
действовать несколько актеров. Обычно клиентов много, поэтому роль клиента
могут играть многие люди. К тому же один человек может играть несколько
ролей, например, менеджер по продажам, выполняющий роль торгового
представителя клиента. Актер не обязательно должен быть человеком. Если
система предоставляет не который сервис другой компьютерной системе, то
другая система является актером.
Не существует стандартного способа описания содержимого прецедента; в
разных случаях применяются различные форматы. Обычно начинают с выбора
одного из сценариев в качестве главного успешного сценария. Сначала вы
описываете тело прецедента, в котором главный успешный сценарий представлен
последовательностью нумерованных шагов. Затем берете другой сценарий и
вставляете его в виде расширения или включения и т.д.
В каждом прецеденте есть ведущий актер, который посылает системе запрос
на обслуживание. Ведущий актер - это актер, желание которого пытается
удовлетворить прецедент и который обычно, но не всегда, является инициатором
прецедента. Одновременно могут быть и другие актеры, с которыми система
также взаимодействует во время выполнения прецедента. Они называются
второстепенными актерами.
Каждый шаг в прецеденте - это элемент взаимодействия актера с системой.
Каждый шаг должен быть простым утверждением и должен четко указывать, кто
выполняет этот шаг. Шаг должен показывать намерение актера, а не механику его
действий. Следовательно, в прецеденте интерфейс актера не описывается.
Действительно, составление прецедента обычно предшествует разработке
интерфейса пользователя.
В книге Кокборна [Alistair Cockburn, Writing Effective Use Cases,
AddisonWesley, 2001.] предлагается схема уровней прецедентов. Базовый
прецедент находится на «уровне моря». Прецеденты уровня моря (sea level)
обычно представляют отдельное взаимодействие ведущего актера и системы.
Такие прецеденты предоставляют ведущему актеру какой-либо полезный
результат и обычно занимают от пары минут до получаса. Прецеденты, которые
существуют в системе, только если они включены в прецеденты уровня моря,
называются прецедентами уровня рыб (fish level). Прецеденты высшего уровня,
уровня воздушного змея (kitelevel), показывают, как прецеденты уровня моря на
страиваются на более широкое взаимодействие с бизнес-процессами. Обычно
23

прецеденты уровня воздушного змея являются прецедентами бизнес-процессов, а
на уровне моря и на уровне рыб находятся прецеденты системы. Большинство
ваших прецедентов должно принадлежать уровню моря [3].
Прецеденты представляют собой ценный инструмент для понимания
функциональных требований к системе. Первый вариант прецедентов должен
составляться на ранней стадии выполнения проекта. Более подробные версии
прецедентов должны появляться непосредственно перед реализацией данного
прецедента. Важно помнить, что прецеденты представляют взгляд на систему со
стороны.
Большая опасность прецедентов заключается в том, что разработчики делают
их очень сложными и застревают на них. Обычно чем меньше вы делаете, тем
меньший вред можете нанести. Если у вас немного информации, то получится
короткий, легко читаемый документ, который явится отправной точкой для
вопросов. Если информации слишком много, то вряд ли кто-то вообще будет ее
изучать и пытаться понять.
Элементы диаграммы прецедентов и особенности ее построения рассмотрим
на примере информационной системы для школы (можно рассматривать ее как
сайт или как отдельное приложение).
В этой системе можно выделить следующие группы пользователей [4]:
1.	Обучающиеся
2.	Преподаватели
3.	Классные руководители
4.	Заместители директора
Каждая из групп пользователей может пользоваться нашей системой по-
своему.
Обучающиеся могут:
1.	Смотреть расписание
2.	Просматривать свои оценки
3.	Преподаватели могут:
4.	Размещать материалы для уроков
5.	Выставлять оценки в электронный журнал
Классные руководители могут делать все то же самое, что и преподаватели
плюс:
1.	Составлять расписание родительских собраний
2.	Заместители директора могут:
3.	Составлять расписание
4.	Публиковать посты с важной информацией
5.	Все пользователи могут:
6.	Отправлять сообщения
Получилось много пунктов, которые может быть сложно уложить в голове.
Для того чтобы быстро ориентироваться в этих пунктах, мы и хотим научиться
строить диаграммы прецедентов.
Каждая группа пользователей на диаграмме вариантов использования
обозначается человечком, под которым записывается имя группы людей, которую
24

он обозначает. Например, изобразим группу пользователей "Преподаватели"(Рис.
5):
О
Преподаватель
Рис. 5. Актер "Преподаватель "
Этот актер обозначает всех преподавателей, которые будут пользоваться
системой.
Обратите внимание, что имя группы записывается в единственном числе.
Символ человечка уже обозначает группу пользователей, поэтому не нужно
дополнительно отражать это в имени.
В общем случае, актёр обозначает любые сущности, использующие систему.
Этими сущностями могут быть люди, технические устройства или даже другие
системы.
Так же изобразим актёров для оставшихся групп пользователей (Рис. 6):
О
О
О
О
л
л
А
А
Зам. директора
Кл. руководитель
Преподаватель
Обучающийся
Рис. 6. Актеры
Здесь изображены все группы пользователей, которые могут пользоваться
нашей системой.
Каждая группа пользователей использует определённые функции системы.
На диаграмме вариантов использования функция системы изображается
эллипсом, внутри которого записывается имя функции в форме глагола с
пояснительными словами.
Рис. 7. Прецедент "Выставить оценки в электронный журнал"
25

Данный эллипс называется вариантом использования или прецедентом (англ.
"use-case"). В общем случае, вариант использования - набор действий, который
может быть использован актёром для взаимодействия с системой.
Мы хотим отображать на диаграмме информацию о том, какие варианты
использования могут быть использованы каждым актёром. Сейчас, например, мы
хотим показать, что выставлять оценки могут только преподаватели.
Рис. 8. Связь между актерами и прецедентом
Мы соединили актеров с вариантом использования с помощью сплошной
линии без стрелки. Такая линия называется отношением ассоциации.
Отношение ассоциации
Association relationship
Рис. 9. Отношение ассоциации
Отношение ассоциации предназначено только для соединения актёров и
вариантов использования. Нет никакого смысла соединять отношением
ассоциации двух актёров или два варианта использования.
Если на диаграмме вариантов использования актёр соединен с вариантом
использования с помощью отношения ассоциации, это означает, что данный актёр
может выполнять действия, описанные вариантом использования.
Добавим еще вариантов использования и соединим их с соответствующими
актёрами:
26

Составить
эасписание.
Отправить
сообщение
/'РазместитьN
материалы для
урока
Узнать расписание
Выставить оценки в
электронный журнал
Преподаватель
Опубликовать
пост с важной
нформацие
Зам. директора
(узн
знать свои оценк
бучающийся
оставить
Отправить
расписание
сообщение
родительских
обрани
Кл руководитель
Рис. 10. Первая версия диаграммы
Заметим, что в нашей системе группы пользователей «Преподаватель» и
«Классный руководитель» обладают схожими возможностями. Чтобы изобразить
это на диаграмме, мы можем пойти одним из трёх путей:
Дублировать варианты использования, чтобы связать их с каждым схожим
актёром (очевидно, неудачный вариант).
Соединить каждого актёра со всеми нужными вариантами использования.
Это может породить множество пересечений линий, что не самым лучшим
образом скажется на читаемости диаграммы.
Показать с помощью одного из видов отношений, что актёры связаны между
собой. Это будет означать, что один из них может пользоваться всеми вариантами
использования, с которыми соединён другой актёр.
Последний вариант похож на принцип повторного использования кода при
написании программ или на наследование классов в ООП (Объектно¬
ориентированное программирование). Преимущество этого варианта в том, чтобы
уменьшить количество связей на диаграмме.
Воспользуемся третьим путём. В этом нам поможет, так называемое,
отношение обобщения. Отношение обобщения обозначается сплошной линией с
полой треугольной стрелкой.
	>
Отношение обобщения
Generalization relationship
Рис. 11. Отношение обобщения
27

Отношение обобщения означает, что некоторый актёр (вариант
использования) может быть обобщён до другого актёра (варианта использования).
Стрелка направлена от частного случая (специализации) к общему случаю.
Ниже представлены несколько
обобщения.
Покупка горного и скоростного
велосипеда - ЧАСТНЫЙ случай
покупки
примеров использования отношения
Физическое лицо и юридическое
лицо можно ОБОБЩИТЬ до
обычного покупателя
Как можно заметить, отношение обобщения используется, чтобы показать,
что одно действие является частным случаем другого действия или что одну
группу людей можно обобщить до другой группы.
Вернёмся к нашему основному примеру. Изобразим отношение обобщения
от актёра "Кл. руководитель" к актёру "Преподаватель".
Рис. 12. Сравнение диаграмм
На рисунке сразу видно, насколько понятнее становится диаграмма при
использовании отношения обобщения: исчезли все повторы вариантов
использования и пересечения линий. Разумеется, это огромный плюс для тех, кто
будет читать эту диаграмму в дальнейшем.
28

Давайте обратим внимание на действие «Узнать свои оценки». Логично
предположить, что обучающиеся захотят не только знать список своих оценок, но
и знать свою среднюю оценку за некоторый период времени или среднюю оценку
по определённому предмету.
Изобразим это на диаграмме. Для этого создадим два варианта
использования "Узнать среднюю оценку за некоторый период времени" и "Узнать
среднюю оценку по предмету" и соединим их с вариантом использования "Узнать
свои оценки" отношением обобщения.
Составить
эасписаниа
Отправить
сообщение
Узнать расписание
/Разместить N
материалы для
'V урока У
Обучающийся
знать свои оценк!
Выставить оценки в
электронный журнал
€ть среднюю у
за некоторый
од времени/
Узнать среднюю
ценку по предмету,
Опубликовать
пост с важной
нформацие
Зам директора
Преподаватель
оставить
расписание
родительских
обрани
Кл руководитель
Рис. 13. Вторая версия диаграммы
Для заместителя директора мы отмечали, что ему нужно составлять
расписания. Условно расписание можно поделить на три категории:
Расписание занятий
Расписание мероприятий
Расписание каникул
Всё это составляется заместителем директора, поэтому покажем это на
диаграмме. Для этого будем использовать отношение включения. Отношение
включения обозначается пунктирной линией с V-образной стрелкой на конце, над
стрелкой добавляется надпись “include”.
"include"
	>
Отношение включения
Include relationship
Рис. 14. Отношение включения
29

В общем случае, отношение включения используется, чтобы показать, что
некоторый вариант использования включает в себя другой вариант использования
в качестве составной части.
Когда мы используем отношение включения, мы подразумеваем, что
составные варианты использования ОБЯЗАТЕЛЬНО входят в состав общего
варианта использования.
Когда пользователь сохраняет результаты своей работы в файл, он указывает
место сохранения и расширение файла (например, если он редактировал
фотографию в photoshop, он может сохранить ее в различных форматах). Этот
процесс можно изобразить на диаграмме вариантов использования следующим
образом:
Рис. 15. Отношение включения используется для изображения составного действия
Составление расписания ВКЛЮЧАЕТ в себя составление расписания
занятий, мероприятий, каникул(обязательно)
Как итог, наша диаграмма принимает следующий вид:
^Составить'
расписание
У занятий у
Составить
^мероприятии,
Составить Л
эасписание/'include
Опубликовать пост с
важной информацией
/Составить'
(расписание
V каникул у
Отправить
сообщение.
Разместить
материалы
Узнать расписание
1Я урока.
'знать свои
Выставить оценки в
электронный журнал
/■'Составить^
расписание
родительских
Аообраниу^
include
' "include" расписание
Зам директора
гнки)
--ОбУ'
бучающиися
Преподаватель
Кл руководитель
Рис. 16. Третья версия диаграммы
30

Нужно сказать, что в диаграммах вариантов использования применяется ещё
один вид связи - отношение расширения. Применение отношение расширения
несколько специфично, поскольку неправильное его использование может
запутать читателя диаграммы. Тем не менее, для полноты картины мы всё равно
рассмотрим применение этого отношения на практике.
Во время дистанционного обучения школьникам необходимо выполнять
домашние задания и присылать их в виде архива или фотографий учителям.
Получается, нужно добавить возможность прикреплять файл к сообщению в
нашей системе. Чтобы отобразить это на диаграмме мы будем использовать
отношение расширения. Отношение расширения обозначается пунктирной
линией с V-образной стрелкой на конце (похоже на отношение включения), над
стрелкой добавляется надпись “extend ”.
"extend"
	>
Отношение расширения
Extend relationship
Рис. 17. Отношение расширения
Допустим, вы делаете заказ в сети быстрого питания. Вы хотите заказать
бургер. Вам, скорее всего, вам предложат расширить ваш заказ картошкой фри
или соусом. Давайте изобразим процесс заказа на диаграмме вариантов
использования.
Рис. 18. К заказу может быть добавлена картошка фри или соус (необязательно)
Два нижних варианта использования описывают возможные «расширения»
для базового варианта использования. Исходя из этого примера, мы можем
сделать важное замечание.
Можно сказать, что отношение расширения - это выборочное отношение
включения. Если отношение включения обозначает, что элемент обязательно
включается в состав другого элемента, то в случае отношения расширения, это
включение необязательно.
31

Понимание этого критически важно для грамотного использования этого
вида отношений.
Вернёмся к нашему основному примеру. Мы хотим, чтобы действие
«прикрепить файл к сообщению» расширяло действие «отправить сообщение».
На диаграмме это изображается следующим образом:
Составить у *
за списание/'include'
Опубликовать пост с
важной информацией
ообщени!
Разместить
материалы
«для урока.
Узнать расписание
'знать свои оценю
>учающиися
Выставить оценки в
электронный журнал
Составить
расписание
занятии
include"
Составить
_ Include
расписание
мероприятии
Составить
расписание
каникул
Отправить4^ 4xterd" /прикрепить файл
Зам директора
Преподаватель
оставите
расписание
родительских
обраний
Кл руководитель
Рис. 19. Четвёртая (финальная) версия диаграммы
Мы рассмотрели основные инструменты для построения диаграммы
вариантов использования.
Общие рекомендации
1.	Диаграммы очень просто изменять. Не нужно пугаться того, что требования к
программе могут измениться или что вы что-то забыли отобразить на
диаграмме. Вы можете добавить элементы к диаграмме, когда вам угодно.
2.	Не нужно засорять диаграмму слишком мелкими действиями. Объедините все
общие действия в одну группу под общим названием, чтобы было просто
читать диаграмму.
3.	Старайтесь не допускать пересечений соединительных линий. Это может
затруднить чтение диаграммы для вас и для ваших коллег.
4.	Не дублируйте варианты использования на диаграмме. Если приходится
дублировать варианты использования, то элементы диаграммы надо
постараться расставить по-другому.
32

5.	Пользуйтесь специальными компьютерными программами для построения
диаграмм. Это существенно упростит весь процесс моделирования.
3.2	Практическая часть
Постановка задачи
Магазин занимается продажей детской и взрослой одежды и обуви
различных брендов. Покупатель просматривает каталог и делает заказ.
Предполагаем, что потенциальный клиент заходит на сайт магазина, он может
нажать кнопку просмотра (или загрузки) каталога, далее может положить
понравившийся товар в корзину, изменить корзину и, приняв решение о покупке
товаров, перейти из корзины к оформлению заказа [5].
Для того чтобы корректно создать систему, отвечающую всем требованиям
заказчика, мы должны абсолютно четко представить себе ее основные бизнес¬
функции и выяснить предъявляемые к системе требования. Для этого необходимо
провести обследование компании и построить ее полную бизнес-модель.
Поскольку наш пример является придуманным, мы не можем провести такое
обследование и не имеем возможности общаться с заказчиком, то мы будем
опираться на придуманное нами словесное описание системы.
Описание работы системы
Каждый товар в каталоге описывается артикулом, размерным рядом, ценой и
фото с кратким описанием. Покупатель может загрузить каталог товаров. Каталог
не содержит разделы, имеет блочную структуру, состоит из набора товаров с
фото, ценой и размерами. Покупатель складывает понравившиеся товары в
корзину, при этом выбирая размер и количество необходимого товара данного
артикула. Корзину можно изменить: просмотреть, удалить товар, изменить
количество позиций одного артикула, вернуться в каталог. Когда покупатель
делает заказ, он вводит свои личные данные, телефон и оплачивает его по
банковской карте (если заказ не оплачен, то он и не сделан) [5].
После того как сделан заказ, его можно забрать со склада через 1 рабочий
день. Данные о заказе поступают сотруднику магазина, назовем его сотрудником
отдела продаж, он проверяет наличие товаров и передает его кладовщику на
комплектацию. Кладовщик, собрав заказ, делает отметку о готовности. Заказ
выдается со склада кладовщиком. Кладовщик выдает заказ и отмечает в системе,
что заказ выдан.
Магазин не занимается доставкой заказов, не делает скидок. Для того чтобы
ограничить масштаб задачи, мы не рассматриваем систему снабжения магазина
новыми товарами. Этим занимается другая система, назовем ее Склад.
Информация о проданных товарах (т.е. сделанных заказах) поступает также в
систему Склад.
Поскольку на протяжении от создания до выдачи заказа, он проходит разные
стадии, то будет разумно ввести понятие статуса заказа. Сотрудники магазина
33

могут статус заказа изменять, а покупатель может проследить за сборкой заказа. В
таком случае наша система предоставляет еще одну функцию: узнать статус
заказа.
Создадим новый проект в StarUML, выбрав Rational Approach из списка
предложенных подходов. Для создания диаграммы вариантов использования в
программной среде StarUML следуйте следующим шагам:
1.	Откройте StarUML на вашем компьютере.
2.	Нажмите на «File» ^ «New From Template» ^ «Rational» для
создания нового проекта.
Иерархическая структура проекта отображается справа на навигаторе модели
(Model Exploer). В зависимости от выбранного подхода на навигаторе модели
будут отображены различные пакеты представлений модели. Каждый пакет
представления будет содержать элементы моделей и диаграмм, которые мы
создадим.
При создании нового проекта моделирования мы выбрали подход Rational
Approach. При таком подходе в навигаторе будут присутствовать четыре пакета
представлений модели системы (Рис. 20):
1.	Use Case View - представление требований к системе, описывает, что
система должна делать;
2.	Logical View - логическое представление системы, описывает, как система
должна быть построена;
3.	Component View - представление реализации, описывает зависимость
между программными компонентами;
4.	Deployment View - представление развертывания, описывает аппаратные
элементы, устройства и программные компоненты.
MODEL EXPLORER Q.
Л
Untitled
Л
Use Case View
Use Case View
>
■' Logical View
►
Component View
►
■ Deployment View
Рис. 20. Навигатор модели
Сейчас каждое представление содержит одну диаграмму. Если щелкнуть по
ней два раза, то откроется рабочее поле этой диаграммы и соответствующая
панель инструментов.
Для добавления диаграммы прецедентов можно воспользоваться одним из
методов:
34

1.	Раскройте представление Use Case View, активируйте двойным нажатием
левой кнопкой мыши созданную по умолчанию диаграмму Use Case
View.
2.	Вызовите контекстное меню на рабочем поле программы (щелчок правой
кнопкой мыши) и выберите «Add Diagram» ^ «Use Case Diagram».
Добавление актеров:
В панели инструментов выберите инструмент «Actor» и щелкните на рабочей
области диаграммы, чтобы добавить актера. Введите имя актера (например,
"Менеджер проекта").
Добавление прецедентов:
Выберите инструмент «Use Case» и добавьте варианты использования на
диаграмму (например, "Создать проект", "Назначить задачи").
Создание связей:
Используйте инструмент «Association» (Ассоциация) в панели инструментов
для соединения актеров с вариантами использования. Нажмите на актера и
проведите линию к соответствующему варианту использования, чтобы показать,
что актер взаимодействует с этой функцией.
Если необходимо, добавьте другие типы связей, такие как «Include»
(Включение) или «Extend» (Расширение), чтобы отразить более сложные
отношения между вариантами использования.
Настройка свойств:
Вы можете настроить свойства каждого элемента (актеров и вариантов
использования) через панель свойств, которая находится в правой части
интерфейса StarUML. Здесь можно изменить название, добавить описание и
задать другие параметры.
Сохранение диаграммы:
После завершения работы над диаграммой сохраните проект, нажав на «File»
^ «Save As». Выберите подходящее имя и место для сохранения файла.
Моделирование системы
Определим актеров и прецеденты системы заказов магазина «Style» [5].
Напомним, что покупатель делает заказ, складывая товары в корзину. Возможна
только одна форма оплаты: банковской картой по интернету, невозможно
оформление заказа без оплаты.
Заказ имеет статус: оплачен, передан на комплектацию, собран, получен.
Статус заказа изменяется автоматически либо сотрудником магазина. Покупатель
может узнать статус своего заказа по уникальному номеру заказа.
Система не занимается поставками товаров в магазин. Этим занимается
другая система, назовем ее Склад. Таким образом, с нашей системой
взаимодействуют покупатель, сотрудники магазина и внешняя система Склад.
С нашей системой взаимодействуют сотрудник отдела продаж, который
проверяет оплату заказа и отправляет его на комплектацию, и кладовщик,
который собирает заказ и выдает его покупателю. С точки зрения бизнеса - это
две разных должности, выполняющих разные функции, но с точки зрения
35

системы они играют одну роль сотрудника, изменяющего статус заказа
покупателя с использованием программного обеспечения моделируемой системы.
В этом смысле для системы нет разницы между сотрудником отдела продаж и
кладовщиком. Выбирая действующих лиц, нужно помнить о том, что мы должны
отразить их роль, а не должность.
Введем обобщающее сотрудников действующее лицо - Сотрудник. Другой
пример: сотрудник магазина «Style» (положим, кладовщик) может выступать в
роли сотрудника и общаться с системой как сотрудник магазина, а может
выступать и в роли покупателя, сделав заказ в магазине. Не смотря на то, что
физически это один человек, он выступает в роли двух актеров: покупателя и
сотрудника.
Итак, актеры системы заказов магазина «Style» будут следующие:
Покупатель, Сотрудник, Система Склад. Покупатель использует нашу систему
для того, чтобы заказать вещи, он просматривает каталог, добавляет
понравившиеся ему товары в корзину, открывает корзину, удаляет из нее товары
или изменяет их количество и, наконец, может оформить свой заказ, при этом его
оплатив. В конечном итоге результат использования системы покупателем будет
получен, если он выполнил все эти действия от начала до конца. Поэтому не
будем разделять заказ товаров на несколько прецедентов, а выделим только один:
Заказ товаров.
Покупатель, сделав заказ в магазине «Style», может в дальнейшем узнавать
статус своего заказа, это тоже случай использования системы, назовем его
Получение информации о заказе. Сотрудник должен изменять статус сделанного
заказа, для него определим прецедент Управление статусом заказа. Система
Склад должна получать информацию о сделанных заказах для возможности
управления наличием товаров на складе, для нее также должен быть доступен
прецедент Получение информации о заказе. Итак, прецеденты системы заказов
магазина «Style»: Заказ товаров, Управление статусом заказа, Получение
информации о заказе.
Для системы заказов магазина «Style» мы определили актеров Покупатель,
Сотрудник, Система Склад и прецеденты Заказ товаров, Управление статусом
заказа, Получение информации о заказе. Построим основную диаграмму
прецедентов [5] (рис. 18).
36

Управление статусом заказа
Получение информации о заказе
Сотрудник
I
Покупатель
% *
Склад
Рис. 21. Основная диаграмма прецедентов заказов магазина «Style»
Для актера Покупатель и прецедента Заказ товаров установили отношение
направленной ассоциации: Заказ товаров инициализируется Покупателем.
Сотрудник имеет возможность управлять статусом заказа, при этом он
непременно участвует в прецеденте Получение информации о заказе.
Направленную ассоциацию от Получение информации о заказе к актеру Система
Склад можно понимать как автоматическую передачу данных из моделируемой
системы в систему снабжения товарами Склад.
В StarUML добавление описания к элементам модели делается следующим
образом. Выделите элемент модели, щелкнув по нему мышкой, и откройте
редактор Documentation. Введите описание элемента в окно документирования
(Рис. 22).
isAbstract ( ]
isFinalSpecialization [ ]
isLeaf Q
w Documentation
©	100%
Рис. 22. Документирование элемента модели в StarUML
Все элементы модели должны быть задокументированы.
37

Для актеров и прецедентов системы заказов магазина «Style» сделаем
краткое описание. Покупатель - это человек, который может сделать заказ в
магазине «Style», с помощью проектируемой системы. Сотрудник - это все
сотрудники магазина «Style», которые могут получать информацию о сделанных
заказах и изменять статус заказа в системе в зависимости от того шага, на
котором находится обработка данного заказа. Система Склад - это внешняя
система, которая получает информацию о сделанных в магазине «Style» заказах
для того, чтобы обеспечить учет наличия товаров на складе и снабжение
товарами. Заказ товаров - этот прецедент запускается покупателем для того,
чтобы оформить заказ в магазине «Style». Состоит из просмотра каталога,
добавления товаров в корзину, просмотра корзины, изменения содержания
корзины и оформления заказа, включая оплату. Управление статусом заказа -
этот прецедент используется сотрудниками магазина для изменения статуса
заказа в процессе его обработки.
Получение информации о заказе - прецедент используется всеми актерами
для просмотра информации о заказе. Для того чтобы создать еще одну диаграмму
(любого типа), например, детализирующую прецедент, щелкните правой кнопкой
мыши по папке Use Case View и в появившемся контекстном меню выберите Add
Diagram, затем выберите из списка диаграмму, которую вы хотите добавить.
Например, можно создать дополнительную диаграмму прецедентов, выбрав пункт
Use Case Diagram (Рис. 23).
% MODEL EXPLORER Q. J
□п л Untitled
Class Diagram
Add Diagram
Package Diagram
Add
Object Diagram
Composite Structure Diagram
Component Diagram
Deployment Diagram
Cut
Copy
Paste
Delete From Model
Use Case Diagram
Sequence Diagram
Communication Diagram
Move Up Ctrl Shift +
Move Down Ctrl Shift *
Timing Diagram
Select In Diagram
Рис. 23. Создание дополнительной диаграммы прецедентов
Наиболее значимым для данной системы и ее актеров прецедентом является
прецедент Заказ товаров. Для него мы построим дополнительную диаграмму
прецедентов, поясняющую этот вариант использования [5] (рис. 21)
38

Посмотр каталога
Просмотр корзины
Покупатель
Удаление товара из корзины
Изменение корзины
<<extend>>
Добавление товара в корзину
□формление заказа
□плата заказа
Рис. 24. Диаграмма вариантов использования, поясняющая основной прецедент Заказ товаров
3.3	Практические задания
Задание 1. В приложении StarUML построить диаграммы прецедентов
продемонстрированных на Рис. 21 и Рис. 24.
Задание 2. (Проектное) Разработать модель требований в виде диаграмм
прецедентов для информационной системы на заданную тему. Тема
индивидуального задания из Приложения 1.
Требуемый результат:
1.	Комплект из трех диаграмм прецедентов различной степени детализации:
•	диаграмма уровня "Воздушный змея" (контекстная диаграмма,
показывающая систему в целом и всех внешних актеров,
взаимодействующих с ней);
•	диаграмма уровня "Моря" (детализирует основные функциональные
пакеты системы);
•	диаграмма уровня "Рыб" (детализирует один или несколько
конкретных прецедентов до уровня элементарных операций);
2.	Текстовая документация:
a.	Описание для каждого актера.
b.	Подробное описание для каждого прецедента.
3. Готовый проект: Сохраненный проект в выбранном инструменте
моделирования (StarUML).
План выполнения:
1.	Выбор и анализ темы
1.1.	Выбрать тему информационной системы из Приложения 1.
Пример: Информационная система 'Прокат велосипедов'.
1.2.	Провести краткий анализ предметной области: определить основных
пользователей системы и ключевые процессы, которые она должна
автоматизировать.
39

2.	Определение актеров и прецедентов верхнего уровня
2.1.	Выявить всех внешних актеров (Actor), которые будут взаимодействовать с
системой (например, Клиент, Администратор, Курьер).
2.2.	Определить основные цели каждого актера по отношению к системе. Эти
цели станут прецедентами верхнего уровня (например, "Арендовать
велосипед", "Управлять парком велосипедов").
2.3.	Нарисовать диаграмму уровня "Воздушный змея", отобразив на ней
систему, всех актеров и связи между ними (кто какими прецедентами
пользуется).
3.	Детализация и создание диаграммы уровня "Моря"
3.1.	Выбрать 2-3 ключевых прецедента с диаграммы верхнего уровня для
детализации.
3.2.	Разбить каждый выбранный прецедент на более мелкие, атомарные
сценарии.
Пример: Прецедент "Арендовать велосипед" можно разбить на "Найти
свободный велосипед", "Забронировать велосипед", "Оплатить аренду".
3.3.	Нарисовать диаграмму уровня "Моря", сгруппировав прецеденты по
функциональным блокам (например, "Бронирование", "Оплата",
"Администрирование") и показав связи (включение «include»,
расширение «extend»).
4.	Глубокая детализация и создание диаграммы уровня "Рыб"
4.1.	Выбрать один самый сложный или важный прецедент с диаграммы "Моря".
4.2.	Декомпозировать его до уровня отдельных шагов, которые выполняет
система и актер.
Пример: Прецедент "Оплатить аренду" детализируется до "Выбрать
способ оплаты", "Ввести данные карты", "Подтвердить платеж",
"Получить электронный чек".
4.3.	Нарисовать диаграмму уровня "Рыб", которая является "внутренностью"
одного прецедента.
5.	Написание документации
5.1.	Для каждого актера составить краткое описание:
5.1.1.	Имя актера.
5.1.2.	Его роль и ответственность в системе.
5.1.3.	Цели его взаимодействия с ИС.
5.2.	Для каждого прецедента на всех диаграммах составить описание по
шаблону:
5.2.1.	Имя прецедента:
5.2.2.	Актеры: (Основные и второстепенные).
5.2.3.	Предусловия: (Что должно быть истинно до начала выполнения
сценария).
5.2.4.	Постусловия: (Что будет гарантированно истинно после успешного
выполнения).
5.2.5.	Основной поток событий: (Пошаговое описание успешного сценария).
5.2.6.	Альтернативные потоки: (Описание ветвлений, исключений).
6.	Оформление и сохранение проекта
40

6.1.	Проверить все диаграммы на соответствие нотации UML.
6.2.	Сохранить проект и экспортировать диаграммы в универсальные форматы
(.pdf, .png) для отчета.
3.4	Контрольные вопросы
1.	Что такое диаграмма вариантов использования и какова ее основная цель?
2.	Каковы основные компоненты диаграммы вариантов использования?
3.	Как различаются актеры и варианты использования на диаграмме?
4.	Какие существуют типы связей между актерами и вариантами
использования? Приведите примеры.
5.	В чем разница между связями «Include» и «Extend»?
6.	Как диаграммы вариантов использования помогают в процессе разработки
информационных систем?
7.	Почему важно учитывать мнения пользователей при создании диаграммы
вариантов использования?
8.	Каковы основные шаги по созданию диаграммы вариантов использования в
StarUML?
9.	Приведите примеры вариантов использования для системы управления
строительным проектом.
10.	Как вы можете использовать диаграмму вариантов использования для
улучшения коммуникации между разработчиками и заинтересованными
сторонами?
41

4.	ДИАГРАММА КЛАССОВ (CLASS DIAGRAM)
4.1	Теоретическая часть
Парадигма объектно-ориентированного программирования (ООП)
повсеместно используется при создании современного программного
обеспечения. Модель объектов, заложенная в данную парадигму, способна
достаточно точно описывать свойства и возможности сущностей реального мира.
Разумеется, эти объекты не существуют обособленно друг от друга, они
взаимодействуют друг с другом для достижения какой-то глобальной цели
разрабатываемой системы [6].
Стандартная библиотека некоторого языка программирования -
замечательный сборник полезных утилит. Однако разнообразие решаемых
программистами задач так велико, что одной только стандартной библиотекой
ограничиться не получится. Программисту часто приходится самому создавать
необходимый ему набор функциональности. Это можно сделать, создав пакет
функций или набор классов.
Создание собственных классов при разработке программы добавляет в
проект новый уровень абстракции, который позволяет определить некоторый
функционал системы и работать в дальнейшем только с ним (Рис. 25).
Рис. 25. Разбиение программы на модули
Чем выше уровень абстракции, которым пользуется программист, тем выше
уровень его продуктивности при разработке приложения.
42

«Хорошая абстракция превращает практически неподъемную задачу в две,
решить которые вполне по силам. Первая из этих задач состоит в определении и
реализации абстракции, а вторая - в использовании этих абстракций для
решения текущей проблемы.»
Э.С. Таненбаум
Использование ООП может существенно упросить жизнь программисту. Это
достигается за счёт сокрытия особенностей внутренней реализации классов.
Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП -
панацея от всех проблем. Однако на практике, если не иметь чёткого
представления о том, какие классы нужно реализовать и как ими потом
пользоваться, в результате может получиться очень запутанная система, которая
начнёт порождать спагетти-код (от англ. “spaghetti code”), который будет лишь
мешаться, когда вы захотите добавить что-то новое в систему.
Назначение диаграммы классов
Диаграмма классов (от англ. "class diagram") предназначена для
представления внутренней структуры программы в виде классов и связей между
ними.
Все сущности реального мира, с которыми собирается работать программист,
должны быть представлены объектами классов в программе. При этом у каждого
класса должно быть только одно назначение и уникально осмысленное имя,
которое будет связано с этой целью.
Класс - элемент диаграммы, обозначающий множество объектов,
обладающих одинаковой внутренней структурой, поведением и отношениями с
объектами других классов. Изображается класс на диаграмме в виде
прямоугольника, разделённого на три секции [6] (Рис. 26):
1.	Имя класса
2.	Список полей класса
3.	Список методов класса
а Имя класса
Список полей
Список методов
Рис. 26. Изображение класса на диаграмме
Обязательным элементом класса является только его название (Рис. 27).
Оранжевым цветом мы будем выделять обязательные части элементов.
43

Customer
-	balance: Integer
-	wishList[0..*]: Product
+ topUpBalance(cashValue: Integer)
+ makePurchaseQ
+ appendToWishList(product: Product)
- isEmailVerified(): Boolean
Название класса
Поля класса
Методы класса
Рис. 27. Изображение содержимого класса на диаграмме
Пример класса "Покупатель". У покупателя есть баланс (balance) денег и
список желаемого (wishList). Пользователь может пополнять баланс на некоторую
сумму денег (topUpBalance()), может совершать покупки (makePurchaseQ) и
может добавлять товары в список желаемого (appendToWishList()). Также мы
можем проверить, подтверждена ли электронная почта пользователя.
Обычно в качестве имени класса выбирается существительное в
единственном числе. Разумеется, это имя должно быть уникальным в пределах
диаграммы. Если имя класса состоит из нескольких слов, мы, по практическим
соображениям, будем записывать их слитно в верблюжьем стиле (от англ.
"CamelCase").
Статический класс
Класс, в котором есть только статические поля и методы и на основе
которого не создаются объекты (экземпляры), называется статическим классом.
Чтобы показать на диаграмме, что наш класс статический, нужно добавить к
имени модификатор «utility».
Формально, такие модификаторы называется стереотипами. Стереотип -
именованный набор свойств. В данном случае, стереотип «utility» означает, что
объекты указанного класса не создаются.
По сути, название модификатора «utility» связано с тем, статический класс
предоставляет набор утилит, которые могут быть использованы любыми
классами, которые в них нуждаются.
Абстрактный класс
Класс, который является базовым для других классов и объекты которого мы
не собираемся создавать, называют абстрактным. Абстрактный класс на
диаграмме изображается так же, как и обычной класс, однако имя такого класса
должно быть записано курсивом (Рис. 28).
44

Human
Аострактный класс.
Его ооъекты не создаются
Отношение
наследования
~ Manager
Programmer
- SeniorProgrammer
Классы, объекты которых.
можно создавать
Рис. 28. Отображение абстрактного класса на диаграмме
В UML принято соглашение, согласно которому все элементы, относящиеся
к абстрактному классу, должны быть помечены курсивом (жирный шрифт при
этом сохраняется).
Поля класса
Вернёмся к нашему примеру с классом Customer. Обратите внимание на
центральную секцию.
Customer
-	balance: Integer
-	wishList[0..*]: Product
+ topUpBalance(cashValue: Integer)
+ makePurchase()
+ appendToWishList(product: Product)
-	isEmailVerified(): Boolean
Поля класса
Давайте рассмотрим первую строчку.
Уровень
видимости
- balance: Integer
I '
Тип поля
Идентификатор
45

В общем случае, каждое поле класса должно описываться следующим
образом:
<уровень видимости><идентификатор>[кратность]:<тип поля>=<начальное значение>{свойство}
<visibility>< lentificator>[multiplicity]:<type>=<initial value>{property}
Общий вид поля класса
Уровень видимости (от англ. "visibility") - свойство поля, которое показывает,
из какой части программы можно обратиться к данному полю.
- balance: Integer
В нашем случае, поле balance - закрытое.
Обычно может принимать следующие значения:
"+" - открытое поле. Аналог public в языках программирования. Означает,
что к полю можно обратиться из любой части программы.
"-" - закрытое поле. Аналог private в языках программирования. Означает, что
получить доступ к полю можно только внутри класса.
"#" - защищённое поле. Аналог protected в языках программирования.
Означает, что получить доступ к полю можно внутри класса и внутри
производных классов.
Идентификатор (от англ. "identificator") - название поля. Является
обязательным элементом для описания переменной на диаграмме классов,
поскольку однозначно её определяет (все идентификаторы на диаграммах
уникальны).
Тип поля (англ. "type of field") показывает, какой тип имеет данное поле в
нашей программе. На ранней стадии проектирования можно и не уточнять, какой
тип имеет то или иное поле.
Уровень видимости
- balance: Integer
Идентификатор
- balance: Integer
Тип ПОЛЯ
46

Типы полей обычно привязаны к какому-то конкретному языку
программирования, например. Кроме того, в качестве типа поля может быть
использован пользовательский тип данных.
Кратность (от англ. "multiplicity") - интервал, определяющий диапазон
количества элементов в массиве. Если для поля указана кратность, то его следует
считать массивом. Количество элементов в таком массиве и будет определяться
указанным интервалом.
- wishList[0..*]: Product
\
Кратность
Список желаемого - это массив, который может либо быть пустым, либо
может хранить неограниченное число товаров. Пояснение к использованию
кратности
Для кратности указывают одно или два значения:
•	[m..n] - интервал от m до n включительно (m <= n). Такая запись будет
означать, что в коллекции может храниться от m до n значений
включительно.
•	[n] - интервал, который можно рассматривать, как сокращённую
запись [0..п].
Может случиться так, что мы захотим показать, что в массиве может
храниться неограниченное количество элементов. В таком случае верхняя граница
n заменяется символом *.
Примеры интервалов:
•	[1] - ровно один объект. То же самое, что и интервал [1..1]
•	[0..1] - ноль или один объект.
•	[0..*] - ноль или неограниченное количество объектов. Часто такой
интервал обозначают просто как [*].
•	[1..*] - один или неограниченное количество объектов.
Наиболее часто используют кратность [0..*] или [1..*]. Можно заметить, что
динамические структуры данных вообще очень удобны в использовании.
Чтобы отличать статические элементы класса от обычных, статические поля
и методы будут подчёркиваться.
Методы класса
Снова разберём наш пример с классом Customer. На этот раз обратим
внимание на третью секцию - секцию методов.
47

Customer
-	balance: Integer
-	wishList[0..*]: Product
+ topUpBalance(cashValue: Integer)
+ makePurchaseQ
+ appendToWishList(product: Product)
-	isEmailVerifiedQ: Boolean
Ч-
Методы класса
Описание методов очень похоже на описание полей класса. На рисунке ниже
представлен общий вид описания метода класса.
<уровень видимости><идентификатор>(‘список аргументов):<тип возвращаемого значения>
<visibility><identificator>(	):<return type>
Список параметров
пуст
I
/
- isEmailVerified(): Boolean
Уровень
видимости
Идентификатор
Тип возвращаемого
значения
Аргументы методов в общем случае описываются следующим образом:
<имя аргумента>:<тип аргумента>
<name of argument>:<type>
Список аргументов содержит
два параметра
/
- getSum(IValue: Integer, rValue: Integer): Integer
В случае, если у метода есть несколько аргументов, они указываются в
скобках через запятую в указанном формате.
48

Виды отношений
Отношения между классами на диаграмме представляются следующими
соединительными линиями:
	>
Отношение ассоциации (от англ, "association relationship")
	^
Отношение зависимости (от англ, "dependency relationship")
Отношение обобщения (от англ, "generalization relationship")
Отношение наследования (от англ, "inheritance relationship")
Отношение агрегации (от англ, "aggregation relationship")
	*
Отношение композиции (англ, "composition relationship")
Отношение ассоциации используют, чтобы показать, что между классами
(например, между двумя классами) существует некоторая связь. Обычно с
помощью него на диаграмме классов показывают, что один класс пользуется
функционалом другого класса.
Методы класса LogSystem используют метод Console:WriteLme() и,
возможно, некоторые другие для вывода результатов.
В общем случае, использование отношения ассоциации выглядит следующим
образом:
49

Как вы можете заметить, стрелка ассоциации направлена от класса
пользователя к классу владельцу используемой функциональности. Для
пояснения того, каким образом один класс использует другой класс, вы можете
описать данный процесс в вспомогательном тексте.
Обратите внимание на кратность ассоциации, которая расположена под
стрелкой. С кратностью мы уже встречались ранее. Здесь у нее несколько иное
значение. Кратность ассоциации обозначает количество объектов, которые
участвуют во взаимодействии. Как показано на рисунке выше, во взаимодействии
могут участвовать от m до n пользователей и от q до г владельцев.
Клиенты могут подключаться к серверу. С помощью кратности ассоциации
указывается допустимое количество объектов в таком взаимодействии.
Если кратность ассоциации не указана, будет подразумеваться кратность
[0..*]. В случае со статическими классами кратность не указывается (можно
считать, что там указана кратность.
Избегайте использования отношения ассоциации в обе стороны, как это
показано на рисунке ниже. Такое взаимодействие классов можно считать ярким
примером спагетти-кода. В случае ошибки очень сложно будет обнаружить, что
послужило ей причиной.
Обозначение отношения ассоциации
50

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

В переводе с английского, слово aggregation означает соединение частей. Это
значение очень точно отражает суть данного отношения - показать, из каких
частей состоит класс. Отношение означает, что объект одного класса включает в
себя в качестве составной части объект другого класса.
Объект класса PersonalComputer (упрощённо) состоит из объекта класса
Monitor, объекта класса ComputerMouse и объекта класса Keyboard.
С отношением агрегации также можно использовать кратность, чтобы
показать, сколько объектов одного класса входят в состав объекта другого класса.
Отношение композиции является частным случаем отношения агрегации.
Однако у него есть одно отличие - классы-части, которые он соединяет с классом-
целым, не могут существовать обособленно.
Одним из переводов слова composition является слово смесь. Если допустить,
что из смеси не получится получить исходные компоненты, то это хорошо
помогает понять, что части, соединённые отношением композиции не могут
существовать сами по себе.
Давайте в качестве примера рассмотрим окно интерпретатора Python.
52

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

диаграмма последовательности, описывающая оформление заказа объектами
Ивановым и Петровым. Обратите внимание на эти объекты: они имеют
одинаковые свойства: имя, счет в банке и т.п. Значит, в системе должен появиться
класс с именем Покупатель, который будет шаблоном объектов Иванов и Петров.
Некоторые возможные классы будут выявлены при рассмотрении трех
стереотипов: сущность (entity), граница (boundary) и управление (control).
Стереотип - это механизм, позволяющий категоризировать классы. Он
используется для создания нового типа элемента, в данном случае нового типа
класса.
Например, Вы хотите выделить все экранные формы в модели. Для этого
нужно создать стереотип Form (Форма).
Стереотипы помогают лучше понять ответственности каждого класса в
модели, категоризировать выполняемые ими функции. В UML для этого
применяют три основных стандартных вида стереотипов классов: классы-
сущности, граничные классы и управляющие классы.
Класс-сущность содержит информацию, хранимую постоянно. Используется
для моделирования данных и поведения с длинным жизненным циклом. Они
могут представлять информацию о предметной области, а могут представлять
элементы самой системы. Часто являясь абстракциями предметной области, они
имеют наибольшее значение для пользователя, поэтому в их названиях
применяются термины предметной области. Если существует проект базы
данных, то можно обратиться к изучению названий таблиц, многие из них станут
классами-сущностями. Обозначаются классы-сущности стереотипом <<entity>>
либо специальной пиктограммой [5] (Рис. 29).
Рис. 29. Обозначение классов-сущностей
Граничными классами называются классы, расположенные на границе
системы со всем остальным миром, и т.о. они обеспечивают взаимодействие
между окружающей средой и внутренними элементами системы.
Для вычисления пограничных классов необходимо исследовать диаграммы
вариантов использования. Для каждого взаимодействия между актером и
прецедентом нужно создать хотя бы один граничный класс. Обратите внимание,
что если два действующих лица инициируют один прецедент, то они могут
применять один общий пограничный класс для взаимодействия с системой.
Обозначаются граничные классы именем стереотипа <<boundary>> либо
специальной пиктограммой [5] (Рис. 30).
54

Рис. 30. Обозначение граничных классов
Управляющий класс отвечает за координацию действий других классов. Они
служат для моделирования последовательного поведения одного или нескольких
прецедентов и координации событий, реализующих заложенное в них поведение.
Обозначаются управляющие классы именем стереотипа «control» либо
специальной пиктограммой (Рис. 31).
Рис. 31. Обозначение управляющих классов
Управляющие классы можно представить, как «исполняющие» прецедент,
поэтому у каждого варианта использования обычно имеется один управляющий
класс, контролирующий последовательность событий этого прецедента. Они
обычно зависят от приложения.
Управляющий класс делегирует ответственности другим классам. Сам он
может получать мало сообщений, но отсылать множество. Его называют классом-
менеджером. Он запускает альтернативные потоки и знает, как поступить в
случае ошибки. На начальном этапе проектирования управляющие классы
создаются для каждой пары актер/прецедент, в дальнейшем они могут
объединяться, разделяться или исключаться.
Документирование классов
После того, как класс создан, информацию о нем необходимо
документировать. Заметим, что документация предназначена для описания
предназначения класса, а не его структуры.
Пример. Если в нашей модели присутствует класс Сотрудник, то хорошим
описанием для него будет:
Сотрудник - это человек, работающий на фирме. Класс содержит
информацию, необходимую для исполнения организацией своих обязанностей по
55

отношению к сотруднику (начисление зарплаты, перевод на другую должность,
увольнение и т.п.)
Плохим описанием будет описание структуры класса, которая может быть и
так описана с помощью атрибутов. Например, плохое описание класса
Сотрудник: Имя, телефон, адрес, должность, зарплата.
В StarUML документирование классов выполняется также как и описанное
выше документирование прецедентов. Нужно выделить класс, который вы хотите
описать, открыть окно документирования Documentation на инспекторе модели и
ввести описание класса.
Когда применяются диаграммы классов
Диаграммы классов составляют фундамент UML, и поэтому их постоянное
применение является условием достижения успеха. Трудность, связанная с
диаграммами классов, заключается в том, что они настолько обширны, что их
применение может оказаться непомерно сложным. Приведем несколько полезных
советов.
1.	Не пытайтесь задействовать сразу все доступные понятия. Начните с самых
простых, описанных в этой главе: классов, ассоциаций, атрибутов,
обобщений и ограничений. Обращайтесь к дополнительным понятиям,
только если они действительно необходимы.
2.	Концептуальные диаграммы классов очень полезны при изучении делового
языка. Чтобы при этом все получалось, необходимо всячески избегать
обсуждения программного обеспечения и применять очень простые
обозначения.
3.	Не надо строить модели для всего на свете, вместо этого следует
сконцентрироваться на ключевых аспектах. Лучше создать мало диаграмм,
которые постоянно применяются в работе и отражают все внесенные
изменения, чем иметь дело с большим количеством забытых и устаревших
моделей.
Самая большая опасность, связанная с диаграммами классов, заключается в
том, что вы можете сосредоточиться исключительно на структуре и забыть о
поведении. Поэтому, рисуя диаграммы классов для того, чтобы разобраться в
программном обеспечении, используйте какие-либо формы анализа поведения.
Если вы применяете эти методы поочередно, значит, вы двигаетесь в верном
направлении.
4.2	Практическая часть
Диаграммы классов относятся к логическому представлению системы Logical
View [5]. На диаграмме Logical View представления Logical View обычно
размещают главную диаграмму пакетов, а диаграммы классов помещают на
другие листы этого представления. Для создания новой диаграммы классов
выполним следующие шаги: щелкнуть правой кнопкой мыши по папке
56

представления Logical View в навигаторе модели, в контекстном меню выбрать
пункт Add Diagram, в списке выбрать диаграмму классов Class Diagram (Рис. 32).
MODEL EXPLORER Q,
□о л ■ Untitled
л Й Use Case View
Use Case View
Class Diagram
Package Diagram
Object Diagram
Composite Structure Diagram
Component Diagram
Deployment Diagram
Use Case Diagram
Sequence Diagram
Communication Diagram
Timing Diagram
Interaction Overview Diagram
Information Flow Diagram
Statechart Diagram
Activity Diagram
Profile Diagram
AWS Architecture Diagram
BPMN Diagram
GCP Architecture Diagram
Requirement Diagram
Block Definition Diagram
ER Diagram
Wireframe Diagram
Mindmap Diagram
Flowchart Diagram
Data Flow Diagram
Add Diagram
►
Add
Cut
Ctii + X
Copy
Ctrl ♦ C
Paste
Ctrl ♦ V
Delete From Mode!
Ctrl * Del
Move Up
Ctrl ♦ Shift + Стрелка вверх
Move Down
Ctrl + Shift + Стрелка вниз
Select In Diagram
Ctrl - D
name Logical View
stereotype
Рис. 32. Добавление диаграммы классов
Будет создана новая диаграмма классов со стандартным именем
ClassDiagraml, которое можно изменить в редакторе свойств диаграммы.
Рассмотрим сценарий Оформление заказа, который является внутренним
потоком для прецедента Заказ товара. Опишем его классы [5].
Данный сценарий позволяет покупателю оформить заказ из корзины и
оплатить его с использованием банковской карты. Давайте представим, как
выполняется этот сценарий. Покупатель, находясь в своей покупательской
корзине, приняв решение о том, что он готов сделать заказ в магазине «Style»,
выбирает опцию «Оформить заказ». Как реагирует система на действия
покупателя? Запускается сценарий Оформление заказа. Пользователь должен на
специальной форме внести свои личные данные, подтвердить заказ или нет, и в
зависимости от этого произвести оплату, затем получить подтверждение заказа. В
системе появляется новый объект - заказ покупателя.
По всей видимости, нам нужен будет хотя бы один граничный класс,
который осуществляет связь между действующим лицом Покупатель и
57

дополнительным прецедентом Оформить заказ. Назовем его ОформлениеЗаказа
(PlaceOrder). Этот класс знает, какие товары и в каком количестве были в корзине
покупателя, их нужно перенести в заказ. Также этот класс может знать, пуста
корзина покупателя или нет, и, если пуста, то вывести об этом соответствующее
сообщение.
Для того, чтобы сделать заказ, покупатель должен ввести свои личные
данные, электронный адрес, телефон и данные кредитной карты. Для этих целей
мы введем еще один класс ВводЛичныхДанных (EnterPersonalInformation).
После того, как выбраны товары и введена личная информация покупателя,
остается только проверить детали заказа и согласиться с ними или нет - для этого
действия введем класс ПроверкаДеталейЗаказа (ConfirmOrder).
Наконец, когда покупатель завершит оформление заказа, то на экране он
видит номер заказа и подтверждение заказа отправляется покупателю на
электронный адрес, для выполнения этих обязанностей создадим еще один
граничный класс ПодтверждениеЗаказа (OrderConfirmation).
Создадим один управляющий класс, который будет распределять
обязанности других классов и вызывать их операции при выполнении данного
сценария. Назовем этот управляющий класс МенеджерОформленияЗаказа
(PlaceOrderManager).
В сценарии Оформление заказа речь идет о покупателе, заказе и товарах.
Создадим классы-сущности Покупатель (Customer), Заказ (Order), Товар (Item).
Возможно, что в ходе дальнейшего проектирования какие-то новые классы
будут добавлены для этого сценария, а какие-то, напротив, из этой диаграммы
удалены. Построим диаграмму классов сценария Оформление заказа в StarUML.
Создайте в пакете Logical View диаграмму классов описанным выше
способом. Переименуйте ClassDiagram1 в Place Order (Оформление Заказа).
Создадим новый класс Покупатель (Customer). Щелкните правой кнопкой мыши
по Logical View в навигаторе модели, в контекстном меню выберите пункт Add
(Добавить), затем выберите пункт Class (Класс). Новый класс будет создан и
отобразится в навигаторе модели. На вкладке Properties (Свойства) измените имя
класса на Покупатель (Customer). Заметим, что при таком способе создания
класса, StarUML создает новое пространство имен.
Если вы хотите создать класс, который носит такое же имя, как, например,
действующее лицо на диаграмме прецедентов, то для того, чтобы StarUML
«разрешил» использовать это имя еще раз, нужно создать класс способом,
описанным выше. Теперь перетащите этот класс из навигатора модели на лист
диаграммы Place Order (Рис. 33)
58

Рис. 33. Класс Покупатель (Customer)
Для того чтобы создать класс ОформлениеЗаказа (PlaceOrder), используем
другой метод. Слева на панели инструментов (Toolbox) щелкните изображение
класса (Class), затем щелкните на листе диаграммы Place Order в том месте, куда
необходимо поместить класс, при этом стандартное имя класса станет активным,
давая возможность его изменить. Измените имя класса на ОформлениеЗаказа
(PlaceOrder)
Создадим все остальные классы, наша диаграмма классов представлена на
Рис. 34.
Item
Order
Cusomer
Рис. 34. Диаграмма классов сценария Оформление заказа
Для того чтобы создать атрибут класса в StarUML, выделите класс, атрибуты
которого вы хотите задать, щелкнув по нему дважды, затем в появившихся
инструментах нажмите на кнопку Add Attribute. (Рис. 35).
59

Рис. 35. Добавление атрибута в класс
Будет создан новый атрибут и откроется редактор его свойств, в котором
можно изменить имя созданного атрибута (раздел Name) и задать другие
спецификации.
Чтобы создать операцию класса в StarUML, выделите класс, операцию
которого вы хотите задать, щелкнув по нему дважды, затем в появившихся
инструментах нажмите на кнопку Add Operation. Будет создана новая операция и
откроется редактор ее свойств, в котором можно изменить имя созданной
операции (раздел Name) и задать другие спецификации.
Когда мы создаем атрибут класса, StarUML автоматически делает его
открытым. Квантор видимости изображается рядом с именем атрибута, слева.
Чтобы изменить видимость, выделите атрибут, щелкнув по нему два раза,
щелкните по появившемуся значку слева от имени атрибута и в списке выберете
желаемую видимость атрибута [5](Рис. 36).
Рис. 36. Определение видимости атрибута
Изменить видимость атрибута можно, также используя редактор свойств
данного атрибута, раздел Visibility (Видимость).
Квантор видимости может быть опущен. Его отсутствие означает, что
видимость атрибута не указывается. Вместо условных графических обозначений
можно записывать соответствующее ключевое слово: public, protected, private,
package или использовать значок StarUML для обозначения видимости.
Для задания кратности атрибута в StarUML нужно выделить атрибут,
откроется его редактор свойств и в разделе Multiplisity выбрать кратность (Рис.
37).
60

Рис. 37. Задание кратности атрибута
Для задания типа атрибута в StarUML нужно выделить атрибут, откроется
его редактор свойств, и в разделе Type указать нужный тип (если он стандартный,
либо выбрать из введенных ранее классов).
Атрибут item класса Заказ (Order) должен быть экземпляром класса Товар
(Item). Для остальных атрибутов зададим стандартные типы [5] (Рис. 38).
<< entity >>
Order
code: String
firstName: String
lastName: String
phoneNumber: String
e-mail: Strng
item: Item[l..*]
total: Float
createOrderQ
findltemsQ
Рис. 38. Типы атрибутов класса Order
Исходное значение служит для задания начального значения
соответствующего атрибута в момент создания отдельного экземпляра класса.
Для задания параметра операции в StarUML нужно выделить операцию и
ввести параметры вручную (с указанием их типов).
Чтобы создать отношение между классами в StarUML щелкните один раз по
обозначению элемента связи на панели элементов слева, выбрав тот тип
отношения, который вам нужен, а затем проведите линию от одного класса к
другому, удерживая левую кнопку мыши.
Кратность указывает, сколько экземпляров одного класса взаимодействуют с
помощью отношения с одним экземпляром данного класса в данный момент.
61

Примеры индикаторов мощности:
0..1	ноль или один;
1	ровно один;
1..	*	один или много;
2..	5	2,3,4 или 5
6..	8.10	6,7,8 или 10
Покупатель может оформить много заказов или не оформить ни одного.
Заказ должен быть сделан только 1 покупателем.
Как видно из примера, читать кратность класса нужно на противоположном
конце связи. Указывать имя, роль или кратность связи необязательно. Это нужно
делать, когда это может помочь более точному представлению модели системы и
лучшему ее пониманию.
Определим отношения между классами сценария Оформление заказа. Класс
PlaceOrder связан с EnterPersonallnformation, а объект ConfirmOrder посылает
сообщения объекту класса PlaceOrderManager. PlaceOrderManager связан с
объектами классов Order и OrderConfirmation.
Для всех перечисленных связей определим отношения ассоциации. Класс
OrderConfirmation использует класс Order как параметр своей операции: между
ними определим отношение зависимости. Экземпляры класса Order состоят из
экземпляров класса Item. Между ними создадим отношение агрегации. Для того
чтобы класс ConfirmOrder мог выполнять операцию подтверждения заказа, он
должен быть связан с классом EnterPersonalInformation, поэтому создадим между
ними отношение ассоциации [5] (Рис. 39).
62

Рис. 39. Диаграмма классов с отношениями
4.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму классов
продемонстрированную на Рис. 39.
ЗАДАНИЕ 2. (Проектное) Разработать структурную модель данных в виде
диаграммы классов для информационной системы на заданную тему. Тему
индивидуального задания выбрать из Приложения 1, диаграмму классов построит
в соответствии с ранее разработанными диаграммами прецедентов.
Требуемый результат:
1.	Одна детализированная диаграмма классов, отражающая ключевые
сущности (классы) предметной области, их атрибуты, операции и
взаимосвязи между ними (ассоциации, наследование, агрегация,
композиция и т.д.).
2.	Текстовая документация:
2.1.	Описание для каждого класса, его назначения в системе.
2.2.	Пояснения для ключевых атрибутов и методов.
3.	Готовый проект: Сохраненный проект в выбранном инструменте
моделирования.
План выполнения:
1.	Анализ предметной области и выделение сущностей
1.1.	На основе темы из Приложения 1 и диаграмм прецедентов провести анализ
предметной области.
1.2.	Выявить ключевые сущности (классы), которые являются основными
объектами системы.
63

Пример для системы "Прокат велосипедов": Велосипед, Клиент, Аренда,
ТочкаПроката, Платеж.
2.	Определение атрибутов и методов классов
2.1.	Для каждого выявленного класса определить его атрибуты —
характеристики, которые описывают состояние объекта. Указать их типы
данных.
Пример для класса Клиент: -id: int, -фио: String, -номерТелефона: String, -
email: String.
2.2.	Определить операции (методы), которые могут быть выполнены над
объектами класса. Это глаголы, связанные с сущностью.
Пример для класса Аренда: +рассчитатъСтоимостъ(): double,
+завершитъАренду().
3.	Установление связей между классами
3.1.	Проанализировать взаимодействие между классами и определить типы
связей между ними:
•	Ассоциация
•	Агрегация
•	Композиция
•	Наследование/Обобщение
3.2.	Для ассоциаций, агрегаций и композиций указать мультипликатор
(например, 1, 0..*, 1..*).
Пример: Клиент — 1	0..* Аренда (один Клиент может иметь
ноль или много Аренд).
4.	Написание документации
4.1.	Для каждого класса составить краткое описание:
•	Имя класса
•	Назначение (Какую роль играет этот класс в системе?)
•	Ключевые атрибуты (С пояснением, для чего они нужны).
•	Ключевые методы (С кратким описанием логики их работы).
•	Для сложных или неочевидных связей между классами дать
пояснение
Пример: "Связь композиции между Заказ и ПозицияЗаказа означает, что
при удалении заказа все его позиции также должны быть удалены из
системы."
5.	Оформление и сохранение проекта
5.1.	Проверить диаграмму на соответствие нотации UML 2.x.
5.2.	Сохранить проект и экспортировать итоговую диаграмму в универсальный
формат (.pdf, .png) для отчета.
4.4	Контрольные вопросы
1.	Почему создание собственных классов важно при разработке программ и как
оно повышает уровень абстракции?
64

2.	Чем отличается уровень абстракции, используемый программистом, и как он
влияет на продуктивность?
3.	Какие задачи стоят перед разработчиком при определении и использовании
абстракций?
4.	Каково предназначение и структура диаграммы классов?
5.	Какие элементы включает изображение класса на диаграмме и что является
обязательным для его обозначения?
6.	Какие особенности существуют при именовании и обозначении классов на
диаграмме?
7.	Чем отличается статический класс от обычного, и как он обозначается на
диаграмме?
8.	Что такое абстрактный класс и как он отображается на диаграмме?
9.	Какие основные свойства имеют поля класса, такие как уровень видимости,
тип и кратность?
10.	Какие отношения между классами используют в UML и что показывает
каждое из них?
11.	В чем заключается отличие между отношениями ассоциации, наследования,
агрегации и композиции?
12.	Как выявлять классы при проектировании системы и какие стереотипы
помогают в их категоризации?
13.	Почему важно документировать классы, и как это делается в UML?
65

5.	ДИАГРАММА ДЕЯТЕЛЬНОСТИ (ACTIVITY DIAGRAM)
5.1	Теоретическая часть
Диаграммы деятельности - это технология, позволяющая описывать логику
процедур, бизнес-процессы и потоки работ. Во многих случаях они напоминают
блок-схемы, но принципиальная разница между диаграммами деятельности и
нотацией блок-схем заключается в том, что первые поддерживают параллельное
процессы.
Диаграммы деятельности подвергались самым большим изменениям при
смене версий языка UML, поэтому неудивительно, что они были снова изменены
и существенно расширены в UML 2. В UML 1 диаграммы деятельности
рассматривались как особый случай диаграмм состояний. Это вызвало немало
трудностей у специалистов, моделирующих потоки работ, для которых хорошо
подходят диаграммы деятельности. В UML 2 это ограничение было
ликвидировано.
На Рис. 40 показан пример простой диаграммы деятельности [3]. Мы
стартуем с начального узла (initial node), а затем выполняем операцию Receive
Order (Принять заказ). Затем идет ветвление (fork), которое имеет один входной
поток и несколько выходных параллельных потоков.
Из Рис. 40 видно, что операции Fill Order (Заполнить заявку), Send Invoice
(Послать счет) и следующие за ними выполняются параллельно. По существу, в
данном случае это означает, что последовательность операций не имеет значения.
Можно заполнить заявку, послать счет, доставить товар (Delivery), а затем
получить оплату (Receive Payment); или можно послать счет, получить оплату,
заполнить заявку, а затем доставить товар.
Можно также выполнять операции поочередно. Возьмем со склада первую
позицию заказа, печатаем счет, берем вторую позицию заказа, кладем счет в
конверт и т. д. Или можно что-то делать одновременно: печатать счет одной
рукой, а другой рукой брать что-нибудь со склада. Согласно диаграмме, любая из
этих последовательностей действий допустима.
Диаграмма деятельности позволяет любому, кто выполняет данный процесс,
выбирать порядок действий. Другими словами, диаграмма только устанавливает
правила обязательной последовательности действий, которым мы должны
следовать. Это важно для моделирования бизнес-процессов, поскольку эти
процессы часто выполняются параллельно. Такие диаграммы также полезны при
разработке параллельных алгоритмов, в которых независимые потоки могут
выполнять работу параллельно.
66

[priority order]
начальный дзел
Receive
Order
выявление
операция
Mil Order
Send Invoice
/teiueHue
Zftefy
поток/ песню
Overnight
Regular
Delivery
Receive
Delivery
Payment
слияние
одьеаинение
Close
Order
конец деятельности
Рис. 40. Простая диаграмма деятельности
При наличии параллелизма необходима синхронизация. Мы не закрываем
заказ, пока он не оплачен и не доставлен. Это показывается с помощью
объединения (join) перед операцией Close Order (Закрыть заказ). Исходящий из
объединения поток выполняется только в том случае, когда все входящие потоки
достигли объединения. Поэтому вы можете закрыть заказ, только когда принята
оплата и заказ доставлен [3].
В UML 1 действовали определенные правила для балансировки ветвлений и
объединений, так как диаграммы деятельности представляли особый случай
диаграмм состояний. В UML 2 в такой балансировке уже нет необходимости.
Заметьте, что узлы на диаграмме деятельности называются операциями
(actions), а не активностями (activities). Строго говоря, деятельность относится к
67

последовательности действий, поэтому диаграмма представляет деятельность,
состоящую из операций.
Условное поведение схематически обозначается с помощью решений
(decisions) и слияний (merges). Решение, которое в UML 1 называлось ветвью,
имеет один входящий поток и несколько защищенных выходных потоков.
Каждый выходной поток имеет защиту - условное выражение, помещенное в
квадратные скобки. Каждый раз при достижении решения выбирается только
один из выходных потоков, поэтому защиты должны быть взаимно
исключающими. Применение [else] в качестве защиты означает, что поток [else]
используется в том случае, когда другие защиты данного решения принимают
ложное значение.
На Рис. 40 решение располагается после операции заполнения заявки. Если у
вас срочный заказ, то он выполняется в течение суток (Overnight Delivery); в
противном случае производится обычная доставка (Regular Delivery).
Слияние (merge) имеет несколько входных потоков и один выходной.
Слияние обозначает завершение условного поведения, которое было начато
решением [3].
На диаграмме каждая операция имеет один входящий в нее поток и один
выходящий. В UML 1 подразумевалось, что несколько входящих потоков имеют
слияние. Другими словами, операция выполнялась, если запускался любой поток.
В UML 2 это было изменено, так что вместо слияния предполагается
объединение; таким образом, операция выполняется, только если все потоки
пройдены. Поэтому рекомендется применять операции с единственным входным
потоком и единственным выходным, а также явно показывать все объединения и
слияния; это избавит вас от путаницы.
Декомпозиция операции
Операции могут быть разбиты на вложенные деятельности (subactivities). Я
могу взять алгоритм доставки, показанный на Рис. 40, и определить его как
самостоятельную деятельность (Рис. 41), а затем вызвать его как операцию (Рис.
42) [3].
Операции могут быть реализованы или как вложенные деятельности или как
методы классов. Вложенную деятельность можно обозначить с помощью символа
«граблей». Вызов метода отображается с помощью синтаксиса имя_класса:
имя_метода. Можно также вставить в символ операции фрагмент кода, если
поведение представлено не единственным вызовом метода.
68

Рис. 41. Дополнительная диаграмма деятельности
Рис. 42. Деятельность из рис. 36 модифицирована для вызова деятельности из рис. 37
69

Диаграммы деятельности рассказывают о том, что происходит, но ничего не
говорят о том, кто какие действия выполняет. В программировании это означает,
что диаграмма не отражает, какой класс является ответственным за ту или иную
операцию. В моделировании бизнес-процессов это означает, что не отражено
распределение обязанностей между подразделениями фирмы. Это не всегда
представляет собой трудность; часто имеет смысл сконцентрироваться на том, что
происходит, а не на том, кто какую роль играет в данном сценарии.
Можно разбить диаграмму деятельности на разделы (partitions), чтобы
показать, кто что делает, то есть какие операции выполняет тот или иной класс
или подразделение предприятия. На Рис. 43 приведен простой пример,
показывающий, как операции по обработке заказа могут быть распределены
между различными подразделениями.
Fufi merit
Customer Service
Rnance
(исполнение)
(обслуживание клиента)
(финансовые операции)
Receive
Order
Send
Invoice
Receive
Payment
\
f
Close
Order
J
t
Deliver
Order
Рис. 43. Разбиение диаграммы деятельности на разделы
На Рис. 43 представлено простое одномерное разбиение [3]. Этот способ по
понятным причинам часто называют плавательными дорожками (swim lanes), и
такая форма была единственной в UML 1. В UML 2 сетка может быть двумерной,
поэтому «плавательная» метафора больше не содержит воды. Кроме того, можно
взять каждое измерение и разделить строчки на столбцы, создавая тем самым
иерархическую структуру.
70

Сигналы. В простом примере на Рис. 40 диаграммы деятельности имеют
четко определенную стартовую точку, соответствующую вызову программы или
процедуры. Кроме того, операции могут отвечать на сигналы.
Временной сигнал (time signal) приходит по прошествии времени. Такие
сигналы могут означать конец месяца в отчетном периоде или приходить каждую
секунду в контроллере реального времени.
На Рис. 44 показана деятельность, в которой ожидаются два сигнала. Сигнал
показывает, что данная деятельность принимает сообщение о событии от
внешнего процесса. Это означает, что деятельность постоянно прослушивает эти
сигналы, а диаграмма определяет, как деятельность на них реагирует.
Рис. 44. Сигналы в диаграмме деятельности
В случае, показанном на Рис. 44, до моего отлета остается два часа (Two
hours before flight), и мне пора собирать багаж. Если я упакую его раньше
времени, то все равно не смогу уехать, пока не прибудет такси [3].
Если такси приходит (Taxi Arrives) до того, как я успею собрать багаж (Pack
Bags), то оно должно ждать меня, пока я не закончу.
Мы можем как принимать сигналы, так и посылать их. Это полезно, когда
мы посылаем сообщение, а затем должны ожидать ответа, перед тем как
продолжить. На Рис. 45 показан хороший пример этого процесса, основанный на
общей идиоме таймаутов. Заметим, что в этой гонке участвует два потока:
первый, достигший финального состояния, выигрывает и прерывает выполнение
другого потока.
Хотя блоки приема сигналов только ожидают внешнего события, мы можем
также показать входящий в него поток. Это означает, что мы не начинаем
прослушивание до тех пор, пока поток не инициирует прием.
71

Рис. 45. Отправка и прием сигналов
Маркеры. Смельчаки, рискнувшие погрузиться в дьявольскую глубину
спецификаций UML, обнаружат, что в разделе, посвященном активности, много
говорится о маркерах (tokens), их создании и использовании.
Начальный узел создает маркер, который затем передается следующей
процедуре, которая выполняется и передает маркер следующей процедуре. В
точку ветвления приходит один маркер, а ветвление порождает маркер для
каждого исходящего потока. Наоборот, в точке объединения при появлении
отдельного маркера ничего не происходит до тех пор, пока не соберутся все
маркеры, затем порождается маркер для исходящего потока.
Можно визуализировать маркеры с помощью монеток или счетчиков,
перемещающихся по диаграмме. В случае более сложных диаграмм деятельности
маркеры часто облегчают визуализацию.
Потоки и ребра. В UML 2 параллельно употребляются термины поток (flow)
и ребро (edge) для обозначения связи между двумя операциями. Самый простой
вид ребра - это обычная стрелка между двумя операциями. Если хотите, можете
присвоить ей имя, но в большинстве случаев простой стрелки будет достаточно
[3].
При возникновении трудностей с разводкой линий можно воспользоваться
разъемами (connectors), которые позволят вам не рисовать линии на всем их
протяжении. Разъемы изображаются парами: один для входного и один для
выходного потоков, при этом они должны иметь одну и ту же метку. Я
предпочитаю без необходимости не применять разъемы, поскольку они нарушают
визуализацию потока управления.
Простейшие ребра передают маркер, имеющий значение только для
управления потоком. Однако по ребрам можно передавать объекты; тогда
объекты будут играть роль маркеров как передатчиков данных.
Передачу объекта вдоль ребра можно показать, помещая на ребро
прямоугольник класса. Можно также изображать контакты (pins) на операциях,
хотя использование контактов имеет некоторые хитрости, о которых я кратко
расскажу.
72

Все способы, показанные на Рис. 46, эквивалентны. Вы вправе выбрать тот
способ, который лучше всего отражает то, что вы хотите сообщить. В
большинстве случаев вполне достаточно простой стрелки.
Рис. 46. Четыре способа представления ребер
Контакты и преобразования. Процедуры, как и методы, могут иметь
параметры. Показывать на диаграмме деятельности информацию о параметрах не
обязательно, но при желании можно отобразить параметры с помощью контактов
(pins).
Если процедура разбивается на части, то контакты должны соответствовать
прямоугольникам параметров на разделенной диаграмме.
Если требуется нарисовать точную диаграмму деятельности, то необходимо
обеспечить соответствие выходных параметров одной процедуры входным
параметрам другой. Если они не совпадают, то можно указать преобразование
(transformation) (Рис. 47) для перехода от одной процедуры к другой.
Преобразование должно представлять собой выражение, свободное от сторонних
эффектов: главное, чтобы запрос с выходного контакта предоставлял тип объекта,
соответствующий входному контакту.
Показывать контакты на диаграмме деятельности не обязательно.
Контакты удобны, когда требуется увидеть данные, принимаемые и
передаваемые различными процедурами. При моделировании бизнес-процессов
посредством контактов можно отображать ресурсы, которые потребляются и
производятся различными процедурами.
73

Отмена приема
Время приема L_bt£..
яонниисш аял nafiauietttha
«transformation»
«transformation»
appointment.cancellation Notice
appointment.patient
Сообщение
1 Пациент
выражение
Уведомить пациента
п{геоа(1азоваяил
Рис. 47. Преобразование потока
С помощью контактов можно без опаски показать несколько потоков,
входящих в одну и ту же операцию. Нотация контактов усиливает предположение
о наличии последующего объединения, а в UML 1 вообще нет контактов, поэтому
не возникает путаницы с более ранними допущениями.
Области расширения. При работе с диаграммами деятельности часто
сталкиваешься с ситуациями, когда выход одной операции инициирует
многочисленные вызовы другой операции. Есть несколько способов показать это,
но лучше всего подходит область расширения. Область расширения (expansion
region) отмечает область диаграммы деятельности, где операции выполняются
один раз для каждого элемента коллекции.
На рис. 9 процедура Choose Topics (Выбрать темы) генерирует список тем.
Затем каждый элемент этого списка становится маркером для входа процедуры
Write Article (Написать статью). Подобным образом каждая операция Review
Article (Рецензировать статью) генерирует единственную статью, которая
добавляется к выходному списку области расширения. Когда все маркеры в
области расширения достигают выходной коллекции, область расширения
генерирует единственный маркер для списка, который передается процедуре
Publish Newsletter (Опубликовать информационный бюллетень).
В данном случае в выходной и входной коллекциях одинаковое количество
элементов. Однако в выходной коллекции может оказаться меньше элементов,
чем во входной; в таком случае область расширения действует как фильтр.
На Рис. 48 все статьи пишутся и рецензируются параллельно, что отмечено
ключевым словом «concurrent» [3]. Область расширения также может быть
итеративной. Итеративные области должны полностью обрабатывать каждый
входной элемент за один раз.
74

Рис. 48. Область расширения
Если есть только одна операция, которую надо вызывать несколько раз, то
применяется нотация, показанная на Рис. 49. Такой способ записи предполагает
параллельное расширение, поскольку оно наиболее общее. Эта нотация
соответствует концепции динамического параллелизма, принятой в UML 1.
f	\
Choose
Topics
L	j
Publish
Newsletter
Рис. 49. Нотация для единственной процедуры в области расширения
Окончание потока. При получении нескольких маркеров, как в случае с
областью расширения, поток часто останавливается, даже если вся активность в
целом не завершена. Окончание потока (flow final) означает завершение
конкретного потока без завершения всей активности.
На Рис. 50 показана модифицированная версия Рис. 48, в которой статьи
могут быть отвергнуты. Если статья отклонена, то маркер ликвидируется
окончанием потока. В отличие от окончания активности, в данном случае
остальная активность может продолжаться. Этот подход позволяет областям
расширения действовать в качестве фильтров, в результате чего выходная
коллекция будет меньше входной.
75

[отклонить]
Choose Topics
у список тем
«concurrent»
Write Artie е
Review Artie e
принять h
Pub hsh
Newsletter
окончание потока
Рис. 50. Окончание потока в активности
Описания объединений. По умолчанию объединение разрешает выполнение
выходного потока, когда все входные потоки достигли объединения. (Или, говоря
более формальным языком, оно порождает маркер выходного потока, когда
приходят маркеры всех входных потоков.) В некоторых случаях, в частности,
когда есть поток с несколькими маркерами, полезно иметь более сложное
правило.
Описание объединения (join specification) - это логическое выражение,
присоединенное к объединению. Каждый раз, когда в объединение прибывает
маркер, вычисляется описание объединения, и если его значение истинное, то
порождается маркер. Поэтому на Рис. 51. Описание объединения, независимо от
того, выбираю ли я напиток (Select Drink) или кидаю монетку (Insert Coin),
автомат оценивает определение объединения. Автомат утоляет мою жажду,
только если я кинул достаточное количество денег. Если, как в данном случае, вы
хотите показать, что вы приняли маркер в каждом входном потоке, то необходимо
именовать потоки и включить их в описание объединения.
Рис. 51. Описание объединения
76

Я должен подчеркнуть, что эта глава лишь слегка затронула диаграммы
деятельности. Учитывая объем языка UML, можно написать целую книгу только
об одной этой технологии. На самом деле я думаю, что диаграммы деятельности
могли бы стать отличной темой для книги, посвященной пристальному
рассмотрению нотаций и их применению.
Жизненно важный вопрос заключается в том, как широко они применяются.
В настоящий момент диаграммы деятельности не относятся к наиболее
распространенным технологиям языка UML, и все их предшественники в области
моделирования потоков также не пользовались успехом. Технология диаграмм
еще не достигла необходимого уровня для описания поведения таким способом. С
другой стороны, в многочисленных сообществах есть проявления скрытой
потребности, которую могли бы удовлетворить стандартные приемы.
Когда применяются диаграммы деятельности
Самое большое достоинство диаграмм деятельности заключается в том, что
они поддерживают и стимулируют применение параллельных процессов. Именно
благодаря этому они представляют собой мощное средство моделирования
потоков работ. Множество импульсов к развитию UML 2 пришло от людей,
вовлеченных в эти потоки работ [3].
Можно также применять диаграмму деятельности в качестве совместимой с
языком UML блок-схемы. Хотя это позволяет разрабатывать блок-схемы, близкие
к UML, но вряд ли это очень захватывающий процесс. В принципе, можно
воспользоваться преимуществами, предоставляемыми ветвлением и
объединением, для описания параллельных алгоритмов одновременно
выполняющихся программ. Хотя сам я не очень активно применял параллельные
циклы, но у меня также нет достаточного количества подтверждений этого от
людей, имеющих большой опыт их применения. Я думаю, причина в том, что
сложность параллельного программирования состоит в противостоянии данных
параллельных процессов, а диаграммы деятельности не могут оказать большой
помощи в этом вопросе.
В наибольшей степени их мощь может проявиться в случае применения UML
как языка программирования. Здесь диаграммы деятельности являются ценным
инструментом для представления логики поведения систем.
Мне часто приходилось видеть, как диаграммы деятельности применялись
для описания прецедентов. Опасность такого подхода в том, что часто эксперты в
предметной области с трудом могут им следовать. Если дело обстоит так, то
лучше обойтись обычной текстовой формой.
5.2	Практическая часть
Чтобы построить диаграмму деятельности для некоторого прецедента в
StarUML, нужно щелкнуть правой кнопкой мыши по этому прецеденту, в
выпавшем контекстном меню выбрать пункт Add Diagram, затем в появившемся
списке выбрать Activity Diagram (Рис. 52).
77

Покупатель
► I
Format
►
Cut
Ctrl + X
Copy
Ctrl * C
Paste
Ctrl + V
Select Ail
Ctrl * A
Delete
Del
Delete From Model
Ctrl * Del
Select In Explorer
Ctrl + E
Select In Diagram
Ctrl * D
Open Sub-Diagram
Ctrl ♦ Shift + D
Tag Editor...
Ctrl + T
Sequence Diagram
Communication Diagram
Timing Diagram
Interaction Overview Diagram
Information Flow Diagram
Statechart Diagram
Activity Diagram
AWS Architecture Diagram
BPMK Diagram
GCP Architecture Diagram
Wireframe Diagram
Mindmap Diagram
Flowchart Diagram
Рис. 52. Добавление диаграммы деятельности
Поле для создания диаграммы деятельности появится в окне программы,
изменится панель инструментов слева, и новая диаграмма отобразится на
навигаторе модели.
Построим диаграмму деятельности для дополнительного прецедента
Оформить заказ актера Покупатель (Рис. 53) [5]. Оформление заказа включает
указание своих личных контактных данных, электронной почты и оплату заказа.
Оформление начинается из корзины покупателя, когда он выбирает опцию
«Оформить заказ».
78

Ввести личные данные
' Загрузить форму s
подтверждения заказа
с составом и реквизитами : аказа]
ель соглас*
Провести оплату
Открыть корзину
[Оплата прошла успешно]
Вывести сообщение
Покупатель
Система
кредитная система
Св
V"0
Выбрать опцию i
Оформить заказу
Загрузить форму \
ввода данных /
<5
Позакать
Отправить
заказ на
данные о заказе
тотт
\ покупателю
Рис. 53. Диаграмма деятельности прецедента Оформить заказ
5.3 Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму деятельности
продемонстрированную на Рис. 53.
ЗАДАНИЕ 2. (Проектное) Разработать модель бизнес-процесса или
алгоритма в виде диаграммы деятельности для ключевого сценария
информационной системы на заданную тему индивидуального задания (см.
Приложение 1). Диаграмма деятельности должна соответствовать ранее
разработанным диаграммам прецедентов (для понимания контекста) и диаграммы
классов (для понимания сущностей).
Требуемый результат:
1.	Одна детализированная диаграмма деятельности, наглядно
отображающая поток выполнения одного сложного или значимого
бизнес-процесса системы, включая последовательность действий,
ветвления, параллельные выполнения и потоки данных.
2.	Текстовая документация
• Общее описание моделируемого процесса.
79

•	Пояснения для ключевых действий, узлов ветвления/слияния и
разделения/соединения.
•	Описание потоков данных (если они присутствуют на диаграмме).
3.	Готовый проект.
План выполнения:
1.	Выбор и анализ бизнес-процесса
1.1.	На основе темы из Приложения 1 и диаграмм прецедентов выбрать один
ключевой, достаточно сложный процесс для моделирования.
Пример для системы "Прокат велосипедов": "Процесс аренды велосипеда",
"Процесс возврата велосипеда и расчета оплаты".
1.2.	Определить границы процесса: его начальную точку (триггер) и конечную
точку (результат).
1.3.	Определить основных участников (роли или системы), которые выполняют
действия в процессе.
2.	Определение последовательности действий и потока управления
2.1.	Определить начальный узел (Initial Node), который символизирует начало
процесса.
2.2.	Разбить процесс на элементарные действия (Activity) и определить их
строгую последовательность.
Пример: "Проверить доступность велосипеда", "Заблокировать велосипед
в системе", "Сформировать договор аренды".
2.3.	Выявить точки принятия решений и добавить узлы ветвления/слияния
(Decision/Merge Nodes). Для каждого ветвления определить сторожевые
условия (Guard Conditions), например, [велосипед доступен] / [велосипед
недоступен].
2.4.	Определить, какие действия могут выполняться параллельно, и добавить
узлы разделения/соединения (Fork/Join Nodes).
Пример: После подтверждения аренды параллельно могут выполняться
"Списать средства с карты" и "Отправить SMS с кодом получения".
3.	Добавление потоков данных и окончания процесса
3.1.	Определить, какие объекты (данные или материальные предметы)
создаются, используются и передаются в процессе. Отобразить их на
диаграмме.
Пример: Объекты "Заявка на аренду", "Договор", "Платеж".
3.2.	Показать поток данных с помощью стрелок зависимости.
3.3.	Определить все возможные конечные узлы (Activity Final Node или Flow
Final Node), которыми завершается процесс (успешно или с ошибкой).
4.	Организация диаграммы с использованием дорожек
4.1.	Для наглядности разделить диаграмму на дорожки (Swimlanes), которые
отвечают за распределение ответственности.
4.2.	Распределить действия и объекты по дорожкам в соответствии с тем, какой
участник (роль или система) их выполняет или владеет.
Пример: Дорожки "Клиент", "Мобильное приложение", "Сервер системы",
"Платежный шлюз".
80

5.	Написание документации
5.1.	Составить общее описание процесса:
5.1.1.	Название процесса.
5.1.2.	Участники (Роли или системы, задействованные в процессе).
5.1.3.	Предусловия (Что должно быть истинно для начала процесса).
5.1.4.	Постусловия (Результат успешного выполнения процесса).
5.2.	Для ключевых и сложных действий дать краткое пояснение:
Пример: "Действие 'Рассчитать итоговую стоимость': учитывает
базовую ставку, время аренды и примененные акции."
5.3.	Для важных узлов ветвления пояснить логику условий.
6.	Оформление и сохранение проекта
6.1.	Проверить диаграмму на соответствие нотации UML 2.x, убедиться, что все
потоки имеют начало и конец.
6.2.	Убедиться, что диаграмма читаема, а дорожки четко разделены.
6.3.	Сохранить проект и экспортировать итоговую диаграмму в формат .pdf или
.png для отчета.
5.4	Контрольные вопросы
1.	В чем заключается принципиальное различие между диаграммой деятельности
и обычной блок-схемой?
2.	Что такое начальный узел (initial node) и какую роль он играет на диаграмме
деятельности?
3.	Какой элемент диаграммы используется для обозначения начала
параллельных процессов и сколько у него входных и выходных потоков?
4.	С помощью какого элемента осуществляется синхронизация параллельных
потоков перед выполнением следующей операции?
5.	Какой элемент используется для описания условного поведения (ветвления) и
как обозначаются условия на исходящих от него потоках?
6.	Как называется элемент, который обозначает завершение условного
поведения, начатого решением (decision)?
7.	С какой целью диаграмму деятельности разбивают на разделы (partitions)?
8.	Что показывает символ «временного сигнала» (time signal) на диаграмме
деятельности?
9.	Что такое «маркер» (token) в контексте выполнения диаграммы деятельности и
как он передается?
10.	Как называется область на диаграмме, где операции выполняются один раз
для каждого элемента входной коллекции?
11.Чем «окончание потока» (flow final) отличается от «окончания активности»
(activity final)?
12.Что такое «описание объединения» (join specification) и в каких случаях оно
используется?
13.	Каков главный недостаток диаграмм деятельности при моделировании бизнес¬
процессов или прецедентов?
81

6.	ДИАГРАММА СОСТОЯНИЙ (STATECHART DIAGRAM)
6.1	Теоретическая часть
Для большинства физических систем, кроме самых простых и тривиальных,
статических представлений совершенно недостаточно для моделирования
процессов функционирования подобных систем как в целом, так и их отдельных
подсистем и элементов.
Рассмотрим простой пример. Любое техническое устройство, такое как
телевизор, компьютер, автомобиль, телефонный аппарат в самом общем случае
может характеризоваться такими своими состояниями, как «исправен» и
«неисправен». Интуитивно ясно, какой смысл вкладывается в каждое из этих
понятий. Более того, использование по назначению данного устройства возможно
только тогда, когда оно находится в исправном состоянии. В противном случае
необходимо предпринять совершенно конкретные действия по его ремонту и
восстановлению работоспособности [3].
Однако понимание семантики понятия состояния представляет определенные
трудности. Дело в том, что характеристика состояний системы не зависит (или
слабо зависит) от логической структуры, зафиксированной в диаграмме классов.
Поэтому при рассмотрении состояний системы приходится на время отвлечься от
особенностей ее объектной структуры и мыслить совершенно другими
категориями, образующими динамический контекст поведения моделируемой
системы. Поэтому при построении диаграмм состояний необходимо использовать
специальные понятия.
Для моделирования поведения на логическом уровне в языке UML могут
использоваться сразу несколько канонических	диаграмм:	состояний,
деятельности, последовательности и кооперации, каждая из которых фиксирует
внимание на отдельном аспекте функционирования системы. В отличие от других
диаграмм диаграмма состояний описывает процесс изменения состояний только
одного класса, а точнее - одного экземпляра определенного класса, т. е.
моделирует все возможные изменения в состоянии конкретного объекта. При
этом изменение состояния объекта может быть вызвано внешними воздействиями
со стороны других объектов или извне. Именно для описания реакции объекта на
подобные внешние воздействия и используются диаграммы состояний.
Главное предназначение этой диаграммы - описать	возможные
последовательности состояний и переходов, которые в совокупности
характеризуют поведение элемента модели в течение его жизненного цикла.
Диаграмма состояний представляет динамическое поведение сущностей, на
основе спецификации их реакции на восприятие некоторых конкретных событий.
Системы, которые реагируют на внешние действия от других систем или от
пользователей, иногда называют реактивными. Если такие действия
инициируются в произвольные случайные моменты времени, то говорят об
асинхронном поведении модели.
Хотя диаграммы состояний чаще всего используются для описания
поведения отдельных экземпляров классов (объектов), но они также могут быть
82

применены для спецификации функциональности других компонентов моделей,
таких как варианты использования, актеры, подсистемы, операции и методы.
Диаграмма состояний по существу является графом специального вида,
который представляет некоторый автомат. Понятие автомата в контексте UML
обладает довольно специфической семантикой, основанной на теории автоматов.
Вершинами этого графа являются состояния и некоторые другие типы элементов
автомата (псевдосостояния), которые изображаются соответствующими
графическими символами. Дуги графа служат для обозначения переходов из
состояния в состояние. Диаграммы состояний могут быть вложены друг в друга,
образуя вложенные диаграммы более детального представления отдельных
элементов модели. Для понимания семантики конкретной диаграммы состояний
необходимо представлять не только особенности поведения моделируемой
сущности, но и знать общие сведения по теории автоматов.
Простейшим примером визуального представления состояний и переходов на
основе формализма автоматов может служить ситуация с исправностью
технического устройства, такого как компьютер. В этом случае вводятся в
рассмотрение два самых общих состояния: «исправен» и «неисправен» и два
перехода: «выход из строя» и «ремонт». Графически эта информация может быть
представлена в виде изображенной ниже диаграммы состояний компьютера (Рис.
54) [3].
Рис. 54 Простейший пример диаграммы состояний для технического устройства типа
компьютер
Основными понятиями, входящими в формализм автомата, являются
состояние и переход. Главное различие между ними заключается в том, что
длительность нахождения системы в отдельном состоянии существенно
превышает время, которое затрачивается на переход из одного состояния в
другое. Предполагается, что в пределе время перехода из одного состояния в
другое равно нулю (если дополнительно ничего не сказано). Другими словами,
переход объекта из состояния в состояние происходит мгновенно.
Формализм автоматов допускает вложение одних автоматов в другие для
уточнения внутренней структуры отдельных более общих состояний
(макросостояний). В этом случае вложенные автоматы получили название
подавтоматов. Подавтоматы могут использоваться для внутренней спецификации
процедур и функций, образующих поведение исходного объекта. Например,
состояние неисправности технического устройства (Рис. 54) может быть
детализировано на отдельные подсостояния, каждое из которых может
характеризовать неисправность отдельных подсистем, входящих в состав данного
устройства.
83

В языке UML понятие автомата дополнено специальной семантикой
входящих в соответствующий пакет элементов. Далее будут рассмотрены
основные элементы поведения, которые образуют концептуальный базис,
необходимый для правильного построения диаграмм состояний.
Формализм обычного автомата основан на выполнении следующих
обязательных условий [3]:
1.	Автомат не запоминает историю перемещения из состояния в состояние. С
точки зрения моделируемого поведения определяющим является сам факт
нахождения объекта в том или ином состоянии, но никак не
последовательность состояний, в результате которой объект перешел в
текущее состояние. Другими словами, автомат «забывает» все состояния,
которые предшествовали текущему в данный момент времени.
2.	В каждый момент времени автомат может находиться в одном и только в
одном из своих состояний. Это означает, что формализм автомата
предназначен для моделирования последовательного поведения, когда
объект в течение своего жизненного цикла последовательно проходит через
все свои состояния. При этом автомат может находиться в отдельном
состоянии как угодно долго, если не происходит никаких событий.
3.	Количество состояний автомата должно быть обязательно конечным (в
языке UML рассматриваются только конечные автоматы), и все они должны
быть специфицированы явным образом. При этом отдельные
псевдосостояния могут не иметь спецификаций (начальное и конечное
состояния). В этом случае их назначение и семантика полностью
определяются из контекста модели и рассматриваемой диаграммы
состояний.
4.	Граф автомата не должен содержать изолированных состояний и переходов.
Это условие означает, что для каждого из состояний, кроме начального,
должно быть определено предшествующее состояние. Каждый переход
должен обязательно соединять два состояния автомата. Допускается
переход из состояния в себя, такой переход еще называют «петлей».
5.	Автомат не должен содержать конфликтующих переходов, т. е. таких
переходов из одного и того же состояния, когда объект одновременно
может перейти в два и более последующих состояния (кроме случая
параллельных подавтоматов).
Состояние может быть задано в виде набора конкретных значений атрибутов
класса или объекта, при этом изменение их отдельных значений будет отражать
изменение состояния моделируемого класса или объекта.
Состояние на диаграмме изображается прямоугольником со скругленными
вершинами (Рис. 55). Этот прямоугольник, в свою очередь, может быть разделен
на две секции горизонтальной линией. Если указана лишь одна секция, то в ней
записывается только имя состояния (Рис. 55, а). В противном случае в первой из
них записывается имя состояния, а во второй - список некоторых внутренних
действий или переходов в данном состоянии (Рис. 55, б). При этом под действием
в языке UML понимают некоторую атомарную операцию, выполнение которой
84

приводит к изменению состояния или возврату некоторого значения (например,
«истина» или «ложь») [3].
Рис. 55 Графическое изображение состояний на диаграмме состояний
Имя состояния представляет собой строку текста, которая раскрывает
содержательный смысл данного состояния. Имя всегда записывается с заглавной
буквы. Поскольку состояние системы является составной частью процесса ее
функционирования, рекомендуется в качестве имени использовать глаголы в
настоящем времени (звенит, печатает, ожидает) или соответствующие причастия
(занят, свободен, передано, получено). Имя у состояния может отсутствовать, т. е.
оно является необязательным для некоторых состояний. В этом случае состояние
является анонимным, и если на диаграмме состояний их несколько, то все они
должны различаться между собой.
Список внутренних действий содержит перечень внутренних действий или
деятельностей, которые выполняются в процессе нахождения моделируемого
элемента в данном состоянии. Каждое из действий записывается в виде отдельной
строки и имеет следующий формат:
<метка-действия '/' выражение-действия>
Метка действия указывает на обстоятельства или условия, при которых будет
выполняться деятельность, определенная выражением действия. При этом
выражение действия может использовать любые атрибуты и связи, которые
принадлежат области имен или контексту моделируемого объекта. Если список
выражений действия пустой, то разделитель в виде наклонной черты '/' может не
указываться.
Перечень меток действия имеет фиксированные значения в языке UML,
которые не могут быть использованы в качестве имен событий. Эти значения
следующие [3]:
•	entry - эта метка указывает на действие, специфицированное следующим
за ней выражением действия, которое выполняется в момент входа в
данное состояние (входное действие);
•	exit - эта метка указывает на действие, специфицированное следующим за
ней выражением действия, которое выполняется в момент выхода из
данного состояния (выходное действие);
•	do - эта метка специфицирует выполняющуюся деятельность («do
activity»), которая выполняется в течение всего времени, пока объект
85

находится в данном состоянии, или до тех пор, пока не закончится
вычисление, специфицированное следующим за ней выражением
действия. В последнем случае при завершении события генерируется
соответствующий результат;
• include - эта метка используется для обращения к подавтомату, при этом
следующее за ней выражение действия содержит имя этого подавтомата.
Во всех остальных случаях метка действия идентифицирует событие,
которое запускает соответствующее выражение действия. Эти события
называются внутренними переходами и семантически эквивалентны переходам в
само это состояние, за исключением той особенности, что выход из этого
состояния или повторный вход в него не происходит. Это означает, что действия
входа и выхода не выполняются.
В качестве примера состояния рассмотрим ситуацию ввода пароля
пользователя при аутентификации входа в некоторую программную систему (Рис.
56). В этом случае список внутренних действий в данном состоянии не пуст и
включает 4 отдельных действия, первые два из которых стандартные и описаны
выше, а два последних определяются своей спецификацией.
Ввод пароля
entry / установить символы невидимыми
exit I установить символы видимыми
символ / получить символ
помощь / показать помощь
У	J
Рис. 56. Пример состояния с непустой секцией внутренних действий Начальное состояние
Начальное состояние представляет собой частный случай состояния, которое
не содержит никаких внутренних действий (псевдосостояния). В этом состоянии
находится объект по умолчанию в начальный момент времени. Оно служит для
указания на диаграмме состояний графической области, от которой начинается
процесс изменения состояний. Графически начальное состояние в языке UML
обозначается в виде закрашенного кружка (Рис. 57, а), из которого может только
выходить стрелка, соответствующая переходу.
•—-	—
Я (б)
начальное состояние конечное состояние
Рис. 57. Графическое изображение начального и конечного состояний на диаграмме состояний
На самом верхнем уровне представления объекта переход из начального
состояния может быть помечен событием создания (инициализации) данного
объекта. В противном случае переход никак не помечается. Если этот переход не
помечен, то он является первым переходом в следующее за ним состояние.
Конечное (финальное) состояние представляет собой частный случай
состояния, которое также не содержит никаких внутренних действий
86

(псевдосостояния). В этом состоянии будет находиться объект по умолчанию
после завершения работы автомата в конечный момент времени. Оно служит для
указания на диаграмме состояний графической области, в которой завершается
процесс изменения состояний или жизненный цикл данного объекта. Г рафически
конечное состояние в языке UML обозначается в виде закрашенного кружка,
помещенного в окружность (Рис. 57, б), в которую может только входить стрелка,
соответствующая переходу.
Простой переход
Простой переход (simple transition) представляет собой отношение между
двумя последовательными состояниями, которое указывает на факт смены одного
состояния другим. Пребывание моделируемого объекта в первом состоянии
может сопровождаться выполнением некоторых действий, а переход во второе
состояние будет возможен после завершения этих действий, а также после
удовлетворения некоторых дополнительных условий. В этом случае говорят, что
переход срабатывает, или происходит срабатывание перехода. До срабатывания
перехода объект находится в предыдущем от него состоянии, называемым
исходным состоянием, или в источнике (не путать с начальным состоянием - это
разные понятия), а после его срабатывания объект находится в последующем от
него состоянии (целевом состоянии) [3].
Переход осуществляется при наступлении некоторого события: окончания
выполнения деятельности (do activity), получении объектом сообщения или
приемом сигнала. На переходе указывается имя события. Кроме того, на переходе
могут указываться действия, производимые объектом в ответ на внешние события
при переходе из одного состояния в другое. Срабатывание перехода может
зависеть не только от наступления некоторого события, но и от выполнения
определенного условия, называемого сторожевым условием. Объект перейдет из
одного состояния в другое в том случае, если произошло указанное событие и
сторожевое условие приняло значение «истина».
На диаграмме состояний переход изображается сплошной линией со
стрелкой, которая направлена в целевое состояние (например, «выход из строя»
на Рис. 54). Каждый переход может помечен строкой текста, которая имеет
следующий общий формат:
<сигнатура события>'['<сторожевое условие>']' <выражение действиям
При этом сигнатура события описывает некоторое событие с необходимыми
аргументами:
<имя события>'('<список параметров, разделенных запятыми>)'
87

Событие
Термин событие (event) требует отдельного пояснения, поскольку является
самостоятельным элементом языка UML. Формально, событие представляет
собой спецификацию некоторого факта, имеющего место в пространстве и во
времени. Про события говорят, что они «происходят», при этом отдельные
события должны быть упорядочены во времени. После наступления некоторого
события нельзя уже вернуться к предыдущим событиям, если такая возможность
не предусмотрена явно в модели.
Семантика понятия события фиксирует внимание на внешних проявлениях
качественных изменений, происходящих при переходе моделируемого объекта из
состояния в состояние. Например, при включении электрического переключателя
происходит некоторое событие, в результате которого комната становится
освещенной. После успешного ремонта компьютера также происходит
немаловажное событие - восстановление его работоспособности. Если поднять
трубку обычного телефона, то, в случае его исправности, мы ожидаем услышать
тоновый сигнал. И этот факт тоже является событием [3].
В языке UML события играют роль стимулов, которые инициируют
переходы из одних состояний в другие. В качестве событий можно рассматривать
сигналы, вызовы, окончание фиксированных промежутков времени или моменты
окончания выполнения определенных действий. Имя события идентифицирует
каждый отдельный переход на диаграмме состояний и может содержать строку
текста, начинающуюся со строчной буквы. В этом случае принято считать
переход триггерным, т.е. таким, который специфицирует событие-триггер.
Например, переходы на Рис. 54 являются триггерными, поскольку с каждым из
них связано некоторое событие-триггер, происходящее асинхронно в момент
выхода из строя технического устройства или в момент окончания его ремонта.
Если рядом со стрелкой перехода не указана никакая строка текста, то
соответствующий переход является нетриггерным, и в этом случае из контекста
диаграммы состояний должно быть ясно, после окончания какой деятельности он
срабатывает. После имени события могут следовать круглые скобки для явного
задания параметров соответствующего события-триггера. Если таких параметров
нет, то список параметров со скобками может отсутствовать.
Сторожевое условие
Сторожевое условие (guard condition), если оно есть, всегда записывается в
прямых скобках после события-триггера и представляет собой некоторое
булевское выражение. Напомним, что булевское выражение должно принимать
одно их двух взаимно исключающих значений: «истина» или «ложь». Из
контекста диаграммы состояний должна явно следовать семантика этого
выражения, а для записи выражения может использоваться синтаксис языка
объектных ограничений, основы которого изложены в приложении.
Введение для перехода	сторожевого условия позволяет	явно
специфицировать семантику его срабатывания. Если сторожевое условие
принимает значение «истина», то соответствующий переход может сработать, в
88

результате чего объект перейдет в целевое состояние. Если же сторожевое
условие принимает значение «ложь», то переход не может сработать, и при
отсутствии других переходов объект не может перейти в целевое состояние по
этому переходу. Однако вычисление истинности сторожевого условия
происходит только после возникновения ассоциированного с ним события-
триггера, инициирующего соответствующий переход.
В общем случае из одного состояния может быть несколько переходов с
одним и тем же событием-триггером. При этом никакие два сторожевых условия
не должны одновременно принимать значение «истина». Каждое из сторожевых
условий необходимо вычислять всякий раз при наступлении соответствующего
события-триггера.
Примером события-триггера может служить разрыв телефонного соединения
с провайдером Интернет-услуг после окончания загрузки электронной почты
клиентской почтовой программой (при удаленном доступе к Интернету). В этом
случае сторожевое условие есть не что иное, как ответ на вопрос: «Пуст ли
почтовый ящик клиента на сервере провайдера?». В случае положительного
ответа «истина», следует отключить соединение с провайдером, что и делает
автоматически почтовая программа-клиент. В случае отрицательного ответа
«ложь», следует оставаться в состоянии загрузки почты и не разрывать
телефонное соединение.
Графически фрагмент логики моделирования почтовой программы может
быть представлен в виде следующей диаграммы состояний (Рис. 58). Как можно
заключить из контекста, в начальном состоянии программа не выполняется, хотя
и имеется на компьютере пользователя. В момент ее включения происходит ее
активизация. В этом состоянии программа может находиться неопределенно
долго, пока пользователь ее не закроет, т. е. не выгрузит из оперативной памяти
компьютера. После окончания активизации программа переходит в конечное
состояние. В активном состоянии программы пользователь может читать
сообщения электронной почты, создавать собственные послания и выполнять
другие действия, не указанные явно на диаграмме.
Однако при необходимости получить новую почту, пользователь должен
установить телефонное соединение с провайдером, что и показано явно на
диаграмме верхним переходом. Другими словами, пользователь инициирует
событие-триггер «установить телефонное соединение». В качестве параметра
этого события выступает конкретный телефонный номер модемного пула
провайдера. Далее следует проверка сторожевого условия «телефонное
соединение установлено», которое следует понимать как вопрос. Только в случае
положительного ответа «да», т. е. «истина», происходит переход почтовой
программы-клиента из состояния «активизация почтовой программы» в состояние
«загрузка почты с сервера провайдера». В противном случае (линия занята,
неверный ввод пароля, отключенный логин) никакой загрузки почты не
произойдет, и программа останется в прежнем своем состоянии.
89

установить телефонное соединение (тел. номер)
(тел. соед-ние установлено)
т
закончить загрузку почты
(почтовый ящик на сервере пуст)
разорвать тел. соединение (тел. номер)
Рис. 58. Диаграмма состояний для моделирования почтовой программы-клиента
Второй триггерный переход на диаграмме инициирует автоматический
разрыв телефонного соединения с провайдером после окончания загрузки почты
на компьютер пользователя. В этом случае событие-триггер «закончить загрузку
почты» происходит после проверки сторожевого условия «почтовый ящик на
сервере пуст», которое также следует понимать в форме вопроса. При
положительном ответе на этот вопрос (вся почта загружена или ее просто нет в
ящике) почтовая программа прекращает загрузку почты и переходит в состояние
активизации. В случае же отрицательного ответа загрузка почты будет
продолжена.
Выражение действия
Выражение действия (action expression) выполняется в том и только в том
случае, когда переход срабатывает. Представляет собой атомарную операцию
(достаточно простое вычисление), выполняемую сразу после срабатывания
соответствующего перехода до начала каких бы то ни было действий в целевом
состоянии. Атомарность действия означает, что оно не может быть прервано
никаким другим действием до тех пор, пока не закончится его выполнение.
Данное действие может оказывать влияние как на сам объект, так и на его
окружение, если это с очевидностью следует из контекста модели. Выражение
записывается после знака "/" в строке текста, присоединенной к
соответствующему переходу [3].
В общем случае, выражение действия может содержать целый список
отдельных действий, разделенных символом ";". Обязательное требование - все
действия из списка должны четко различаться между собой и следовать в порядке
их записи. На синтаксис записи выражений действия не накладывается никаких
ограничений. Главное - их запись должна быть понятна разработчикам модели и
программистам. Поэтому чаще всего выражения записывают на одном из языков
программирования, который предполагается использовать для реализации
модели.
В качестве примера выражения действия (Рис. 58) может служить «разорвать
телефонное соединение» (телефонный номер), которое должно быть выполнено
сразу после установления истинности («истина») сторожевого условия «почтовый
ящик на сервере пуст».
Другим примером может служить очевидная ситуация с выделением
графических объектов на экране монитора при однократном нажатии левой
90

кнопки мыши. Имеется в виду обработка сигналов от пользователя при
выделении тех или иных графических примитивов (пиктограмм). В этом случае
соответствующий переход может иметь следующую строку текста:
"нажата и отпущена левая кнопка мыши (координаты) [координаты в области
графического объекта] / выделить объект (цвет)
Результатом этого триггерного перехода может быть, например, активизация
некоторых свойств объекта (размер файла в строке состояния) или последующее
его удаление в корзину.
Составное состояние
Составное состояние (composite state) - такое сложное состояние, которое
состоит из других вложенных в него состояний. Последние будут выступать по
отношению к первому как подсостояния (substate). Хотя между ними имеет место
отношение композиции, графически все вершины диаграммы, которые
соответствуют вложенным состояниям, изображаются внутри символа составного
состояния (Рис. 59). В этом случае размеры графического символа составного
состояния увеличиваются, так чтобы вместить в себя все подсостояния [3].
Рис. 59. Графическое представление составного состояния с двумя вложенными в него
последовательными подсостояниями
Составное состояние может содержать два или более параллельных
подавтомата или несколько последовательных подсостояний. Каждое сложное
состояние может уточняться только одним из указанных способов. При этом
любое из подсостояний, в свою очередь, может являться составным состоянием и
содержать внутри себя другие вложенные подсостояния. Количество уровней
вложенности составных состояний не фиксировано в языке UML.
Последовательные подсостояния
Последовательные подсостояния (sequential substates) используются для
моделирования такого поведения объекта, во время которого в каждый момент
времени объект может находиться в одном и только одном подсостояний.
Поведение объекта в этом случае представляет собой последовательную смену
подсостояний, начиная от начального и заканчивая конечным подсостояниями.
Хотя объект продолжает находиться в составном состоянии, введение в
91

рассмотрение последовательных подсостояний позволяет учесть более тонкие
логические аспекты его внутреннего поведения.
Для примера рассмотрим в качестве моделируемого объекта обычный
телефонный аппарат. Он может находиться в различных состояниях, одним из
которых является состояние дозвона до абонента. Очевидно, для того чтобы
позвонить, необходимо снять телефонную трубку, услышать тоновый сигнал,
после чего набрать нужный телефонный номер. Таким образом, состояние
дозвона до абонента является составным и состоит из двух последовательных
подсостояний: «поднять телефонную трубку» и «набрать телефонный номер».
Фрагмент диаграммы состояний для этого примера содержит одно составное
состояние и два последовательных подсостояний (Рис. 60).
Рис. 60. Пример составного состояния с двумя вложенными последовательными
подсостояниями
Некоторых пояснений могут потребовать переходы. Два из них
специфицируют событие-триггер набор цифры, которое имеет имя «цифра» с
параметром "n". В качестве параметра, как нетрудно предположить, выступает
отдельная цифра на диске телефонного аппарата. Переход из начального под¬
состояния нетриггерный, поскольку он не содержит никакой строки текста.
Последний переход в конечное подсостояние не имеет события- триггера, но
имеет сторожевое условие, проверяющее правильность набранного номера
абонента. Только в случае истинности этого условия телефонный аппарат может
перейти в конечное подсостояние, которое характеризует суперсостояние «дозвон
до абонента» в целом.
Составное состояние может содержать в качестве вложенных подсостояний
начальное и конечное состояния. При этом начальное подсостояние является
исходным, когда происходит переход объекта в данное составное состояние. Если
составное состояние содержит внутри себя конечное подсостояние, то переход в
это вложенное конечное состояние означает завершение нахождения объекта в
данном вложенном состоянии. Важно помнить, что для последовательных
подсостояний начальное и конечное состояния должны быть единственными в
каждом составном состоянии.
Параллельные подсостояния
Параллельные подсостояния (concurrent substates) позволяют
специфицировать два и более подавтомата, которые могут выполняться
параллельно внутри составного события. Каждый из подавтоматов занимает
92

некоторую область (регион) внутри составного состояния, которая отделяется от
остальных горизонтальной пунктирной линией. Если на диаграмме состояний
имеется составное состояние с вложенными параллельными подсостояниями, то
объект может одновременно находиться в каждом из этих подсостояний.
Однако отдельные параллельные подсостояния могут, в свою очередь,
состоять из нескольких последовательных подсостояний (подавтоматы 1 и 2 на
Рис. 61). В этом случае по определению объект может находиться только в одном
из последовательных подсостояний подавтомата. Таким образом, для
абстрактного примера (Рис. 61) допустимо одновременное нахождение объекта в
подсостояниях (1, 3, 4), (2, 3, 4), (1, 3, 5), (2, 3, 5). Недопустимо нахождение
объекта одновременно в подсостояниях (1, 2,3) или (3, 4, 5) [3].
Рис. 61. Графическое изображение составного состояния с вложенными параллельными
подсостояниями
Поскольку каждый регион вложенного состояния специфицирует некоторый
подавтомат, то для каждого из вложенных подавтоматов могут быть определены
собственные начальное и конечные подсостояния (Рис. 61). При переходе в
данное составное состояние каждый из подавтоматов оказывается в своем
начальном подсостояний. Далее происходит параллельное выполнение каждого из
этих подавтоматов, причем выход из составного состояния будет возможен лишь
в том случае, когда все подавтоматы будут находиться в своих конечных
подсостояниях.
Если какой-либо из подавтоматов пришел в свое конечное состояние раньше
других, то он должен ожидать, пока и другие подавтоматы не придут в свои
конечные состояния.
Рассмотренное выше понятие перехода является вполне достаточным для
большинства типичных расчетно-вычислительных задач. Однако современные
программные системы могут реализовывать очень сложную логику поведения
отдельных своих компонентов. Может оказаться, что для адекватного
представления процесса изменения состояний семантика обычного перехода для
них недостаточна. С этой целью в языке UML специфицированы дополнительные
обозначения и свойства, которыми могут обладать отдельные переходы на
диаграмме состояний.
93

В отдельных случаях переход может иметь несколько состояний-источников
и несколько целевых состояний. Такой переход получил специальное название -
параллельный переход. Введение в рассмотрение параллельного перехода
обусловлено необходимостью синхронизировать и/или разделить отдельные
подпроцессы на параллельные нити без спецификации дополнительной
синхронизации в параллельных подавтоматах.
Графически такой переход изображается вертикальной черточкой,
аналогично обозначению перехода в известном формализме сетей Петри. Если
параллельный переход имеет две или более входящих дуг (Рис. 62, а), то его
называют соединением (join). Если же он имеет две или более исходящих из него
дуг (Рис. 62, б), то его называют ветвлением (fork). Текстовая строка
спецификации параллельного перехода записывается рядом с черточкой и
относится ко всем входящим (исходящим) дугам [3].
■■■ ■
Процесс_1
- -■
Процесс_2
1. 1
( Состояние_1
<( Состояние_3 )
1 3\
{ Состояние_2 \
-Л	О
\ Состояние_4 ]
Рис. 62. Графическое изображение параллельного перехода из параллельных состояний (а) и
параллельного перехода в параллельные состояния (б)
Срабатывание параллельного перехода происходит следующим образом. В
первом случае (переход-соединение) переход срабатывает, если имеет место
событие-триггер для всех исходных состояний этого перехода, и выполнено (при
его наличии) сторожевое условие. При срабатывании перехода-соединения
одновременно покидаются все исходные состояния перехода (состояния 1 и 2) и
происходит переход в целевое состояние. При этом каждое из исходных
состояний перехода должно принадлежать отдельному подавтомату, входящему в
состав автомата (процессу 1).
Во втором случае (ветвление) происходит расщепление автомата на два
подавтомата, образующих параллельные ветви вложенных подсостояний. При
этом после срабатывания перехода моделируемый объект одновременно будет
находиться во всех целевых состояниях этого перехода (состояния 3 и 4). Далее
процесс изменения состояний будет протекать согласно ранее рассмотренным
правилам для составных состояний.
Поведение параллельных подавтоматов независимо друг от друга, что
позволяет реализовать многозадачность в программных системах. Однако в
отдельных случаях может возникнуть необходимость учесть в модели
синхронизацию наступления отдельных событий. Для этой цели в языке UML
имеется специальное псевдосостояние, которое называется синхронизирующим
состоянием.
94

Синхронизирующее состояние
Синхронизирующее состояние (synch state) обозначается небольшой
окружностью, внутри которой помещен символ звездочки Оно используется
совместно с переходом- соединением или переходом-ветвлением для того, чтобы
явно указать события в других подавтоматах, оказывающие непосредственное
влияние на поведение данного подавтомата.
Для иллюстрации использования синхронизирующих состояний рассмотрим
упрощенную ситуацию с моделированием процесса постройки дома.
Предположим, что постройка дома включает в себя строительные работы
(возведение фундамента и стен, возведение крыши и отделочные работы) и
работы по электрификации дома (подведение электрической линии, прокладка
скрытой электропроводки и установка осветительных ламп). Очевидно, два этих
комплекса работ могут выполняться параллельно, однако между ними есть
некоторая взаимосвязь.
В частности, прокладка скрытой электропроводки может начаться лишь
после того, как будет завершено возведение фундамента и стен. А отделочные
работы следует начать лишь после того, как будет закончена прокладка скрытой
электропроводки. В противном случае отделочные работы придется проводить
повторно. Рассмотренные особенности синхронизации этих параллельных
процессов учтены на соответствующей диаграмме состояний с помощью двух
синхронизирующих состояний (Рис. 63).
Рис. 63. Диаграмма состояний для примера со строительством дома
Рассмотрим диаграмму состояний, которая представляет собой пример
моделирования поведения конкретного объекта - процесса функционирования
телефонного аппарата (Рис. 64). Этот пример иллюстрирует все основные
особенности графической нотации, используемой при построении диаграммы
состояний.
Кратко прокомментируем основные особенности этого примера. Данная
диаграмма состояний представляет единственный автомат с одним составным
состоянием. Вне этого составного состояния имеется только одно состояние
«ожидание», которое характеризует исправный и подключенный к телефонной
сети телефонный аппарат. Переход в следующее состояние происходит при
95

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

проверка сторожевого условия «разговор доступен». Если оно истинно, что
соответствует снятию трубки абонентом, начинается телефонный разговор. В
противном случае (это условие не выполняется, т. е. оно ложно) телефон абонента
будет продолжать звонить, извещая нас об отсутствии последнего либо о
невозможности по какой-либо причине вести разговор по телефону. При этом нам
ничего не остается, как опустить трубку на рычаг.
Если же разговор состоялся, то после слов прощания и выполнения
сторожевого условия «подтверждение» на окончание разговора мы снова
опускаем трубку. При этом телефонный аппарат переходит в состояние
«ожидание», в котором может находиться неопределенно долго.
Заключение
По своему назначению диаграмма состояний не является обязательным
представлением в модели и как бы «присоединяется» к тому элементу, который,
по замыслу разработчиков, имеет нетривиальное поведение в течение своего
жизненного цикла. Наличие у системы нескольких состояний, отличающихся от
простой дихотомии «исправен - неисправен», «активен - неактивен», «ожидание
- реакция на внешние действия», уже служит признаком необходимости
построения диаграммы состояний. В качестве начального варианта диаграммы
состояний, если нет очевидных соображений по поводу состояний объекта, можно
воспользоваться этими суперсостояниями, рассматривая их как составные и
уточняя их (детализируя их внутреннюю структуру) по мере рассмотрения логики
поведения объекта [3].
При выделении состояний и переходов следует помнить, что длительность
срабатывания отдельных переходов должна быть существенно меньшей, чем
нахождение моделируемого объекта в соответствующих состояниях. Каждое из
состояний должно характеризоваться определенной устойчивостью во времени.
Другими словами, из каждого состояния на диаграмме не может быть
самопроизвольного перехода в какое бы то ни было другое состояние. Все
переходы должны быть явно специфицированы, в противном случае построенная
диаграмма состояний является либо неполной, либо ошибочной.
При разработке диаграммы состояний нужно постоянно следить, чтобы
объект в каждый момент мог находиться только в единственном состоянии. Если
это не так, то данное обстоятельство может быть как следствием ошибки, так и
неявным признаком наличия параллельности у поведения моделируемого
объекта. В последнем случае следует явно специфицировать необходимое число
подавтоматов, вложив их в то составное состояние, которое характеризуется
нарушением условия одновременности.
Следует обязательно проверять, что никакие два перехода из одного
состояния не могут сработать одновременно (требование отсутствия конфликтов
у переходов). Наличие такого конфликта может служить признаком ошибки либо
неявной параллельности типа ветвления рассматриваемого процесса на два и
более подавтомата. Если параллельность по замыслу разработчика отсутствует, то
необходимо ввести дополнительные сторожевые условия либо изменить
97

существующие, чтобы исключить конфликт переходов. При наличии
параллельности следует заменить конфликтующие переходы одним
параллельным переходом типа ветвления.
6.2	Практическая часть
Для добавления диаграммы состояний в модель нужно выполнить
следующие шаги: щелкнуть правой кнопкой мыши по папке представления
Logical View в навигаторе модели, в контекстном меню выбрать пункт Add
Diagram, в списке выбрать диаграмму состояний Statechart Diagram (Рис. 65). Мы
также можем связать диаграмму состояний с тем классом, состояния объекта
которого она описывает. Для этого нужно щелкнуть правой мышкой по
соответствующему классу, а не по папке Logical View.
С|аяя1
f
Add
Add Diagram
► [
►
Format
►
Cut
Ctrl *X
Copy
Ctrl ♦ C
Paste
Ctrl * V
Select All
Ctrl* A
Delete
Del
Delete From Model
Ctrl * Del
Select In Explorer
Ctrl + E
Select In Diagram
Ctrl* D
Open Sub-Diagram
Ctrl * Shift + D
Tag Editor...
Ctrl * T
Sequence Diagram
Communication Diagram
Timing Diagram
Interaction Overview Diagram
Information Flow Diagram
Statechart Diagram
Activity Diagram
AWS Architecture Diagram
BPMK Diagram
GCP Architecture Diagram
Wireframe Diagram
Mindmap Diagram
Flowchart Diagram
Рис. 65. Добавление диаграммы состояний
Вернемся к нашему примеру магазина «Style» [5]. Покупатель оформляет
заказ. Класс Заказ, кроме прочих атрибутов имеет атрибут «статус». Проследим
динамику движения заказов в системе с помощью диаграммы состояний,
составленной для класса Заказ.
По условию нашей задачи данные о сделанном заказе поступают сотруднику
отдела продаж, который проверяет оплату, реквизиты заказа и передает его
кладовщику на комплектацию. Кладовщик, проверив наличие заказанных товаров
и собрав заказ, если это возможно, делает отметку о готовности. Заказ выдается со
склада кладовщиком. Кладовщик выдает заказ и отмечает в системе, что заказ
выдан. Далее данные о заказе мы можем передать в архив. Отразим на диаграмме
переход заказа между состояниями (Рис. 66) [5].
98

?
Оформлен
	j
I
Выдан
¥
Рис. 66. Диаграмма состояний объекта класса Заказ
Находясь в каком-либо состоянии, объект может выполнять определенные
действия, с состоянием можно связать такие действия как входное и выходное
действия и внутренняя или просто деятельность.
При оформлении заказа он должен быть оплачен (входное действие
Оплатить заказ), обработка заказа подразумевает проверку оплаты и наличия
товаров, переход в одно из состояний На комплектации, Укомплектован, Выдан
означает смену статуса заказа (соответствует действию выхода Изменить
статус) (Рис. 67)
99

Рис. 67. Изменение состояния объекта осуществляется с помощью переходов
Переход может быть направлен в то же состояние, из которого он выходит. В
этом случае его называют переходом в себя. Исходное и целевое состояния
перехода в себя совпадают. Этот переход изображается петлей со стрелкой и
отличается от внутреннего перехода. При переходе в себя объект покидает
исходное состояние, а затем снова входит в него.
Если покупатель получил заказ, то это событие вызывает переход из
состояния Укомплектован в состояние Выдан. Если же покупатель не получил
свой заказ в течение двух недель, то заказ расформировывается, а деньги
возвращаются покупателю на банковскую карту. Условие [Покупатель не забрал
заказ в течение 2 недель] вызывает переход в состояние Расформирован при этом
выполняется действие Вернуть деньги на карту. Окончательную диаграмму
состояний можно видеть на Рис. 68 [5].
100

Оформлен
entrY/Оплатить заказ
На обработке
do/Проверить оплату и наличие
exit/Изменить статус
На комплектации
exit/Изменить статус
Укомплектован
exit/Изменить статус
Покупатель получил зак
[Покупатель не заорал зак
ечение 2 недель]Дернуть деньги на карту
Выдан
Расформирован
Рис. 68. Окончательная диаграмма состояний объекта Заказ
6.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму состояний
продемонстрированную на Рис. 68
ЗАДАНИЕ 2. (Проектное) Разработать модель поведения отдельного объекта
в виде диаграммы состояний, отображающей его жизненный цикл в рамках
информационной системы на заданную тему (Приложение 1). Диаграмма
состояний спроектировать в соответствии с ранее разработанными диаграммами
классов (для выбора ключевого класса) и диаграммами прецедентов (для
понимания контекста использования).
Требуемый результат:
1.	Одна детализированная диаграмма состояний, описывающая полный
жизненный цикл одного значимого объекта системы, включая все возможные
состояния, переходы между ними, события, охранные условия и действия.
2.	Текстовая документация
•	Общее описание моделируемого жизненного цикла объекта.
•	Пояснения для ключевых состояний и сложных переходов.
•	Описание событий, условий и действий.
3.	Готовый проект.
План выполнения:
1.	Выбор объекта для моделирования и определение начального состояния
101

1.1.	На основе темы из Приложения 1 и диаграммы классов выбрать один
ключевой класс, объекты которого имеют нетривиальный жизненный цикл.
Пример для системы "Прокат велосипедов": класс Велосипед (а не Клиент,
чье состояние может быть простым) или класс ЗаказНаАренду.
1.2.	Определить начальное состояние (Initial Pseudostate) объекта — состояние,
в котором он создается.
Пример для Велосипед: Доступен.
2.	Определение основных состояний и конечного состояния
2.1.	Выявить все устойчивые состояния (States), в которых может находиться
объект в течение своего жизненного цикла. Состояние — это период
времени, когда объект удовлетворяет некоторому условию.
Пример для ЗаказНаАренду: Новый, Подтвержденный, Активный,
Завершенный, Отмененный.
2.2.	Определить, может ли жизненный цикл объекта завершаться, и если да, то
указать конечное состояние (Final State).
Пример: Состояние Архивный для ЗаказНаАренду после истечения срока
хранения данных.
3.	Определение событий и переходов
3.1.	Для каждой пары состояний определить события (Events), которые
инициируют переход (Transition) из одного состояния в другое. События —
это то, что происходит в системе.
Пример: Переход из Доступен в Забронирован по событию
поступилЗапросНаБронирование().
3.2.	Добавить условия для переходов, которые могут произойти только при
выполнении определенного логического условия.
Пример: [бронь подтверждена администратором].
4.	Детализация состояний и добавление действий
4.1.	Для сложных состояний использовать вложенные состояния (Submachines)
или составные состояния (Composite States) для моделирования внутренней
активности.
4.2.	Добавить действия (Actions) в состояния, используя нотацию
4.2.1.	entry / для действия при входе в состояние.
4.2.2.	exit / для действия при выходе из состояния.
4.2.3.	do / для продолжительной активности, выполняемой пока объект
находится в состоянии.
Пример: В состоянии ВРемонте действие do / выполнитьРемонт().
5.	Моделирование сложного поведения
5.1.	Использовать псевдосостояние истории для моделирования возврата к
прерванному составному состоянию, если это применимо.
5.2.	Добавить псевдосостояние выбора для моделирования динамического
ветвления в зависимости от условий во время выполнения.
5.3.	Проверить диаграмму на наличие "висячих" состояний и недопустимых
переходов.
6.	Написание документации
6.1.	Составить общее описание жизненного цикла
102

6.1.1.	Моделируемый класс: (Какой класс представлен на диаграмме)
6.1.2.	Назначение диаграммы: (Какую поведенческую логику она
описывает)
6.1.3.	Ключевые состояния: (Краткий обзор основных фаз жизни объекта)
6.2.	Для ключевых и сложных состояний дать пояснение:
Пример: "Состояние 'Ожидаетоплаты': в этом состоянии система
ожидает подтверждения платежа от платежного шлюза. Заказ
заблокирован для изменений."
6.3.	Для важных переходов пояснить бизнес-логику:
Пример: "Переход 'отменаПоТаймауту' происходит автоматически по
истечении 30 минут, если заказ не был оплачен, что реализовано с
помощью внутреннего таймера."
7.	Оформление и сохранение проекта
7.1.	Проверить диаграмму на соответствие нотации UML 2.x.
7.2.	Убедиться, что диаграмма наглядно отображает все значимые аспекты
жизненного цикла объекта.
7.3.	Сохранить проект и экспортировать итоговую диаграмму в формат .pdf или
.png для отчета.
6.4	Контрольные вопросы
1.	Что является главным предназначением диаграммы состояний?
2.	Каковы пять обязательных условий формализма обычного автомата,
перечисленных в тексте?
3.	Как графически изображается состояние на диаграмме состояний?
4.	Какие три фиксированные метки действия используются в секции
внутренних действий состояния и что они означают?
5.	Чем отличается «входное действие» (entry) от деятельности (do activity) с
точки зрения момента выполнения?
6.	Как графически обозначаются начальное и конечное состояния
(псевдосостояния) на диаграмме?
7.	Из чего состоит полная текстовая строка, которой может быть помечен
переход?
8.	Что такое «сторожевое условие» (guard condition) и в какой момент оно
вычисляется?
9.	Что такое «составное состояние» и для чего оно используется?
10.	В чем ключевое различие между последовательными и параллельными
подсостояниями с точки зрения нахождения в них объекта?
11.	Как называется переход, который имеет несколько состояний-источников
или несколько целевых состояний, и как графически изображается его
«ветвление»?
12.	Для какой цели используется «синхронизирующее состояние» и как оно
обозначается на диаграмме?
13.	Какое главное требование к длительности нахождения объекта в состоянии
по сравнению со временем перехода между состояниями?
103

7.	ДИАГРАММА ПОСЛЕДОВАТЕЛЬНОСТИ (SEQUENCE DIAGRAM)
7.1	Теоретическая часть
Диаграммы взаимодействия (interaction diagrams) описывают взаимодействие
групп объектов в различных условиях их поведения. UML определяет диаграммы
взаимодействия нескольких типов, из которых наиболее употребительными
являются диаграммы последовательности.
Диаграмма последовательности используется для визуализации
взаимодействия между объектами в системе. Она показывает порядок сообщений,
которыми объекты обмениваются друг с другом во времени и их жизненный
цикл. Это самый простой и удобный инструмент для демонстрации всех
интеграций и взаимодействий в рамках проектируемого бизнес-процесса.
Основные элементы, из которых состоит sequence-диаграмма: объекты
(зеленое), линии жизни (красное), сообщения (синее).
Обычно диаграмма последовательности описывает один сценарий. На
диаграмме показаны экземпляры объектов и сообщения, которыми обмениваются
объекты в рамках одного прецедента (use case) [2].
Рис. 69. Пример диаграммы последовательности
Объекты — это сущности, которые взаимодействуют друг с другом.
Например, пользователь, топик или очередь, микросервис. Помимо названия,
объекты могут еще отличаться своим типом:
Рис. 70. Типы объектов
104

Диаграммы последовательностей используются для уточнения диаграмм
прецедентов, более детального описания логики сценариев использования. Это
отличное средство документирования проекта с точки зрения сценариев
использования!
На диаграмме последовательностей могут изображаться экземпляры
действующих лиц. Для того чтобы поместить действующее лицо на диаграмму,
нужно найти его в навигаторе модели справа и перетащить на поле диаграммы
последовательностей [5].
Рис. 71. Экземпляр действующего лица на диаграмме последовательности
Действующие лица, присутствующие на диаграммах взаимодействия,
выделяются из потока событий как сущности, запускающие процессы. На одной
диаграмме их может быть несколько.
Каждый объект или действующее лицо на диаграмме последовательностей
имеет свою линию жизни, которая обозначается пунктиром.
Линия жизни объекта (object lifeline) - вертикальная пунктирная линия на
диаграмме последовательности, которая представляет существование объекта в
течение определенного периода времени.
Фокус управления (активность, focus of control) - специальный символ на
диаграмме последовательности, указывающий период времени, в течение
которого объект выполняет некоторое действие, находясь в активном состоянии.
Фокус управления изображается тонким прямоугольником, расположенным
на линии жизни [5] (Рис. 72).
105

Рис. 72. Фокус управления
Иногда отображение фокуса активности и нумерации сообщений на
диаграмме могут сделать ее трудной для чтения. Чтобы фокус управления и
нумерация сообщений не отображались на диаграмме последовательности в
StarUML нужно открыть редактор свойств этой диаграммы в инспекторе модели и
в разделах ShowSequenceNumber и ShowActivation убрать «галочки» (Рис. 73).
Рис. 73. Управление отображением фокуса управления и нумерации сообщений
Объекты и действующие лица на диаграммах последовательности
обмениваются сообщениями. Сообщения обозначаются стрелками, идущими от
отправителя к получателю.
Сообщение (message) — спецификация передачи информации от одного
элемента модели к другому с ожиданием выполнения определенных действий со
стороны принимающего элемента [5] (Рис. 74).
106

1 : добавить товар в корзину()
Рис. 74. Сообщение
Для сообщений на диаграммах последовательностей, как и для других
элементов модели, доступен ряд спецификаций.
Во-первых, у каждого сообщения должно быть имя, соответствующее его
цели.
Во-вторых, сообщения на диаграммах последовательностей можно соотнести
с операциями, определенными для классов. Если от одного объекта к другому
направлено сообщение, то это означает, что объект-источник вызывает операцию
объекта-приемника. Объект не может вызвать произвольную операцию: она
должна быть доступна этому объекту.
В особых случаях сообщение не становится операцией: например, ввод
логина и пароля подразумевает их печать в соответствующих полях, и сообщение
будет реализовано в виде поля ввода в окне программы.
В-третьих, мы можем для каждого сообщения установить тип
синхронизации. Каждому типу соответствует его обозначение.
Вызов операции (процедуры) (call) вызывает операцию того объекта, к
которому направлено. Объект может вызвать свою операцию. Тогда стрелка
начинается и заканчивается на линии жизни одного и того же объекта, такое
сообщение называется рефлексивным.
Синхронное сообщение обозначается стрелкой с закрашенным наконечником
[5].
* 1
V
►:
Асинхронное сообщение (send) посылает объекту сигнал. При этом источник
не ждет отклика приемника или подтверждения получения, а продолжает свою
работу. Обозначается нежирной стрелкой.
Ответное сообщение (return) возвращает значение из процедуры тому
объекту, к которому направлено. Обозначается пунктирной стрелкой.
107

Создать объект (create) - создает новый объект. Обозначается стрелкой со
стереотипом «create».
Уничтожить объект (destroy)- удаляет объект. Объект может уничтожить сам
себя. Обозначается стрелкой со стереотипом «destroy». При уничтожении
объекта на его линии жизни появляется символ разрушения, который
обозначается крестом.
«destroy >> I
:::::::::—►
Синхронные и асинхронные вызовы
Если вызывающий объект посылает синхронное сообщение (synchronous
message), то он должен ждать, пока обработка сообщения не будет закончена,
например при вызове подпрограммы. Если вызывающий объект посылает
асинхронное сообщение (asynchronous message), то он может продолжать работу
и не должен ждать ответа. Асинхронные вызовы можно встретить в
многопоточных приложениях и в промежуточном программном обеспечении,
ориентированном на сообщения.
Асинхронность улучшает способность к реагированию и уменьшает
количество временных соединений, но сложнее в отладке.
Циклы, условия
Общая проблема диаграмм последовательности заключается в том, как
отображать циклы и условные конструкции. Прежде всего надо усвоить, что
диаграммы последовательности для этого не предназначены. Подобные
управляющие структуры лучше показывать с помощью диаграммы деятельности
или собственно кода. Диаграммы последовательности применяются для
визуализации процесса взаимодействия объектов, а не как средство
моделирования алгоритма управления [3].
И для циклов, и для условий используются фреймы взаимодействий
(interaction frames), представляющие собой средство разметки диаграммы
взаимодействия.
108

Рис. 75. Использование фреймов взаимодействий
В основном фреймы состоят из некоторой области диаграммы
последовательности, разделенной на несколько фрагментов. Каждый фрейм имеет
оператор, а каждый фрагмент может иметь защиту [3] (на Рис. 76 перечислены
общепринятые операторы для фреймов взаимодействия).
Для отображения цикла применяется оператор loop с единственным
фрагментом, а тело итерации помещается в защиту. Для условной логики можно
использовать оператор alt и помещать условие в каждый фрагмент. Будет
выполнен только тот фрагмент, защита которого имеет истинное значение. Для
единственной области существует оператор opt.
109

Оператор
Значение
alt
opt
par
loop
region
neg
ref
sd
Несколько альтернативных фрагментов (alternative); выполняет¬
ся только тот фрагмент, условие которого истинно (рис. 4.4)
Необязательный (optional) фрагмент; выполняется, только если
условие истинно. Эквивалентно alt с одной веткой (рис. 4.4)
Параллельный (parallel); все фрагменты выполняются парал¬
лельно
Цикл (loop); фрагмент может выполняться несколько раз, а за¬
щита обозначает тело итерации (рис. 4.4)
Критическая область (critical region); фрагмент может иметь
только один поток, выполняющийся за один прием
Отрицательный (negative) фрагмент; обозначает неверное вза¬
имодействие
Ссылка (reference); ссылается на взаимодействие, определенное
на другой диаграмме. Фрейм рисуется, чтобы охватить линии
жизни, вовлеченные во взаимодействие. Можно определять па¬
раметры и возвращать значение
Диаграмма последовательности (sequence diagram); используется
для очерчивания всей диаграммы последовательности, если это
необходимо
Рис. 76. Общепринятые операторы для фреймов взаимодействия
Когда применяются диаграммы последовательности
Диаграммы последовательности следует применять тогда, когда требуется
посмотреть на поведение нескольких объектов в рамках одного прецедента.
Диаграммы последовательности хороши для представления взаимодействия
объектов, но не очень подходят для точного определения поведения [3].
Если вы хотите посмотреть на поведение одного объекта в нескольких
прецедентах, то примените диаграмму состояния. Если же надо изучить
поведение нескольких объектов в нескольких прецедентах или потоках, не
забудьте о диаграмме деятельности.
Если требуется быстро исследовать несколько вариантов взаимодействия,
лучше использовать CRC_карточки, поскольку это позволяет избежать
непрерывного рисования и стирания. Часто бывает удобно поработать с
CRC_карточками для просмотра вариантов взаимодействия, а затем с помощью
диаграмм взаимодействий фиксировать те взаимодействия, которые будут
применяться позже.
Взаимосвязь диаграмм классов и последовательности
Процесс построения модели системы является итеративным. Особенно
хорошо это можно видеть при создании диаграмм классов и последовательности.
Какую диаграмму создавать первой: классов или последовательности? Одни
разработчики начинают с диаграмм классов, другие - наоборот, с
110

последовательности. И в том и в другом случае, скорее всего, обе эти диаграммы,
построенные для одного сценария, будут в дальнейшем подвергаться изменению.
После построения диаграмм последовательности на диаграммах классов могут
появиться новые классы, а на диаграммах последовательности - новые объекты,
которых раньше там не было, но они придут туда из диаграмм классов. Возможно,
что некоторые объекты и классы будут, напротив, удалены [3].
7.2	Практическая часть
Для создания новой диаграммы последовательности нужно выполнить
следующие шаги: щелкнуть правой кнопкой мыши по папке представления
Logical View в навигаторе модели, в контекстном меню выбрать пункт Add
Diagram, в списке выбрать диаграмму последовательности Sequence Diagram
(Рис. 77).
Model Explorer
D?S
Ш SIX 4 t -5-
в ^ Untitled
fi Use Case View
В " ЁЁ
	151 M.
Add
и|м
Ш
Cbss Degram
Use Case Diagram
Sequence Diagram
„Л Sequence Diagram (Role)
El Collaboration Diagram
El Collaboration Diagram (Role)
Ё1 State chart Diagram
EJ Activity Diagram
Component Dagram
tU Deployment Diagram
oj Composite Structure Degram
Robustness Diagram
Add Diagram
►
Cut
Ctrl+X
Чш
Copy
Ctrl+C
ft
Paste
Ctrt+V
Delete From Model
Ctrl+Del
Un$
►
щ
Collection Editor...
Ctrl+F5
Щ
Constraints...
ari+F6
lagged Values...
Ctrl+F7
C++
►
C#
►
Java
►
Apply Pattern...
? x
Рис. 77. Добавление диаграммы последовательности
Также можно использовать диаграмму последовательности для детализации
прецедента. Для этого нужно связать диаграмму с прецедентом: для создания
диаграммы щелкните правой кнопкой мыши по прецеденту, а не по папке Logical
View. Однако, если мы строим диаграмму последовательности для анализа
системы, то лучше все-таки помещать ее в Logical View.
Составим диаграмму последовательности для случая, когда покупатель
успешно оформляет заказ [5] (Рис. 78). Покупатель выбирает опцию «Оформить
заказ» (Place order), при этом вызывается некоторый объект PlaceOrder (забегая
111

вперед скажем, что это будет граничный объект, принадлежащий
соответствующему граничному классу).
Далее открывается форма ввода личных данных покупателя и его кредитной
карты (EnterPersonalInformation), на ней покупатель вводит свое имя, адрес,
телефон, адрес электронной почты (enter personal information) и кредитные
данные. Информация принимается и открывается форма подтверждения заказа
(ConfirmOrder), покупатель подтверждает, что согласен с реквизитами заказа
(Confirm order), детали заказа сохраняются для дальнейшего использования (save
the details). Фокус управления передается некоторому управляющему объекту
(PlaceOrderManager), который обращается к внешней кредитной системе (Credit
System) для проведения платежа.
Если платеж прошел успешно (а именно такой сценарий мы сейчас и
рассматриваем), то PlaceOrderManager посылает сообщение (Create order)
создать объект Заказ (Order), затем вызывает форму подтверждения заказа
(OrderConfirmation). Объект Заказ (Order) обращается к объектам Товар (Item) для
того, чтобы получить информацию о товарах и создает заказ. Процесс
завершается [5].
Рис. 78. Диаграмма последовательности сценария Оформление заказа
Обратите внимание, что символ объекта Товар (Item) на диаграмме
последовательности отличается от символов других объектов. Дело в том, что мы
задали множественный экземпляр класса. Действительно, заказ может состоять из
нескольких товаров, значит объекту Заказ (Order) требуется получить
информацию о нескольких объектах Товар (Item). Вместо того, чтобы
представлять каждый товар отдельно мы используем нотацию UML для
множественного экземпляра класса, представляя одним значком несколько
объектов.
Чтобы сделать объект множественным в StarUML выделите объект, щелкнув
по нему мышью один раз, в открывшемся редакторе свойств поставьте флажок в
разделе IsMultiInstance [5] (Рис. 79).
112

Рис. 79. Создание множественного объекта
Обычно для основного потока событий большинства прецедентов строится
одна диаграмма последовательности, для альтернативных потоков -
дополнительные диаграммы, описывающие все остальные сценарии. Так
поступают потому, что на диаграмме последовательности действий сложно
отобразить логику ЕСЛИ-ТО-ИНАЧЕ. Однако если это необходимо и не
загромождает диаграмму, то это можно сделать с помощью условий.
Например, в процессе оформления покупателем заказа возможны несколько
альтернатив. Например, на втором шаге оформления заказа покупатель может
подтвердить свой заказ, а может и не согласиться с его реквизитами. На
диаграмме последовательности это можно изобразить так, как это показано на
Рис. 80.
Рис. 80. Ветвление потока управления
113

Если покупатель подтверждает свой заказ на втором шаге (customer confirmed
the order), то процесс переходит оплате заказа. Если покупатель не подтверждает
заказ (customer did not confirm the order), то открывается корзина покупателя.
Условие, как это принято в нотации UML, записывается в квадратных скобках [].
Обратите внимание, что мы упростили предыдущую диаграмму описания
оформления заказа, иначе добавление ветвей процесса сделало бы ее громоздкой
и трудно понимаемой. На практике лучше изображать диаграмму
последовательности отдельно для каждого сценария потока событий [5].
7.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму
последовательности, продемонстрированную на Рис. 78.
ЗАДАНИЕ 2. (Проектное) Разработать модель взаимодействия объектов в
виде диаграммы последовательности, детализирующей сценарий выполнения
одного прецедента в информационной системе на заданную тему (Приложение 1).
Диаграмма последовательности должна соответствовать ранее разработанным
диаграммам прецедентов (для выбора сценария) и диаграммам классов (для
определения объектов и методов).
Требуемый результат:
1.	Одна детализированная диаграмма последовательности, наглядно
отображающая временную последовательность взаимодействий между
объектами в рамках выбранного сценария, включая сообщения, временные
ограничения и логические ветвления.
2.	Текстовая документация
•	Общее описание моделируемого сценария взаимодействия.
•	Пояснения для ключевых сообщений и сценариев взаимодействия.
•	Описание актеров, объектов и их ролей в процессе.
3.	Готовый проект.
План выполнения:
1.	Выбор сценария и определение участников
1.1.	На основе темы индивидуального задания и диаграмм прецедентов выбрать
один ключевой сценарий для детализации.
Пример для системы "Прокат велосипедов": "Сценарий успешного
оформления аренды", "Сценарий обработки возврата велосипеда".
1.2.	Определить всех участников взаимодействия: внешних актеров и
внутренних объектов системы, которые задействованы в сценарии.
Пример: Клиент, ИС Проката (контроллер), СервисБронирования,
БазаДанных, ПлатежныйШлюз.
2.	Построение базовой последовательности сообщений
2.1.	Расположить участников на диаграмме в виде линий жизни (Lifelines) слева
направо в порядке инициирования взаимодействия.
114

2.2.	Определить начальное сообщение (initial message), которое запускает
сценарий.
2.3.	Построить последовательность синхронных сообщений (synchronous
messages) с активационными блоками (activation boxes), показывающими
период выполнения операции.
Пример:	запросНаБронирование() ^ проверитъДоступностъ() ^
получитьСтатус() ^ вернутъРезулътат().
3.	Добавление сложного поведения и ответов
3.1.	Использовать возвратные сообщения (reply messages) для явного показа
возврата значений.
3.2. Добавить асинхронные	сообщения (asynchronous messages)	для
взаимодействий, не требующих немедленного ответа.
3.3. Применить операторы	взаимодействия (interaction operators) для
моделирования ветвлений и циклов:
3.3.1.	opt - для опциональных последовательностей;
3.3.2.	alt - для альтернативных сценариев;
3.3.3.	loop - для циклических выполнений;
Пример: alt [бронирование подтверждено] / [бронирование отклонено].
4.	Моделирование создания/уничтожения объектов и временных ограничений
4.1.	Использовать сообщение со стереотипом «create» для явного указания
создания объектов в процессе выполнения сценария.
4.2.	Применить блок уничтожения (stop shape) для указания момента
уничтожения объекта.
4.3.	Добавить временные ограничения (timing constraints) для критичных по
времени операций.
Пример: {времяОтвета < 2 сек}.
5.	Добавление примечаний и комментариев
5.1.	Использовать примечания (notes) для пояснения сложных моментов
взаимодействия.
5.2.	Добавить комментарии к неочевидным сообщениям и условиям ветвлений.
5.3.	Проверить целостность диаграммы - все сообщения должны иметь
отправителя и получателя.
6.	Написание документации
6.1.	Составить общее описание сценария:
6.1.1.	Название сценария: (Какой процесс моделируется)
6.1.2.	Участники взаимодействия: (Акторы и объекты с краткими
пояснениями их ролей)
6.1.3.	Предусловия: (Условия начала сценария)
6.1.4.	Результат: (Ожидаемый итог выполнения)
6.2.	Для ключевых сообщений дать пояснение
Пример: "Сообщение 'проверитъЛоялъностъQ': проверяет историю аренд
клиента и рассчитывает персональную скидку."
6.3.	Для блоков ветвления описать бизнес-логику условий.
7.	Оформление и сохранение проекта
7.1.Проверить диаграмму на соответствие нотации UML 2.x.
115

7.2.	Убедиться, что последовательность сообщений логична и соответствует
бизнес-логике.
7.3.	Сохранить проект и экспортировать итоговую диаграмму в формат .pdf или
.png для отчета.
7.4	Контрольные вопросы
1.	Какова основная цель диаграммы последовательности?
2.	Что представляет собой линия жизни объекта на диаграмме
последовательности?
3.	Что такое фокус управления и как он обозначается на диаграмме?
4.	Каким образом в StarUML можно отключить отображение фокуса
управления и нумерации сообщений?
5.	Какие два основных типа сообщений по способу взаимодействия различают
и в чем их ключевое различие?
6.	Как обозначается на диаграмме сообщение, которое создает новый объект?
7.	Как обозначается сообщение, которое уничтожает объект, и что при этом
появляется на его линии жизни?
8.	Какое средство разметки используется на диаграммах последовательности
для отображения циклов и условий?
9.	Какой оператор фрейма используется для отображения цикла
(повторяющихся действий)?
10.	Какой оператор фрейма используется для условной логики с несколькими
вариантами выполнения?
11.	Какой метод, помимо диаграмм, предлагается для быстрого исследования
вариантов взаимодействия объектов?
12.	Какова взаимосвязь между диаграммами классов и последовательности в
итеративном процессе построения модели?
116

8.	ДИАГРАММА КООПЕРАЦИИ (COLLABORATION DIAGRAM)
8.1	Теоретическая часть
Собственно, слово "кооперация" значит "совместная деятельность",
"сотрудничество". Такие диаграммы показывают, как объекты работают вместе
для достижения общей цели, акцентируясь на их ролях.
Диаграмма кооперации - диаграмма взаимодействий, в которой основной
акцент сделан на структурной организации объектов, посылающих и получающих
сообщения.
Следует отметить, что здесь имеет место некоторая терминологическая
путаница. В оригинале такие диаграммы называются Collaboration Diagram. Слово
"collaboration", конечно же, синоним слова "cooperation", но в "русском" варианте
звучит хуже. Поэтому в русскоязычных учебниках говорят "диаграмма
кооперации", а не "коллаборации". Кроме этого, само это название немного
устарело - в UML 2.x подобные диаграммы называются Communication Diagram.
Впрочем, все три слова - "cooperation", "collaboration" и "communication" -
являются синонимами, так что довольно часто используется "старое" название.
Диаграммы кооперации применяются для того, чтобы:
1.	показать набор взаимодействующих объектов в реальном окружении "с
высоты птичьего полета";
2.	распределить функциональность между классами, основываясь на
результатах изучения динамических аспектов системы;
3.	описать логику выполнения сложных операций, особенно в тех случаях,
когда один объект взаимодействует еще с несколькими объектами;
4.	изучить роли, выполняемые объектами внутри системы, а также
отношения между объектами, в которые они вовлекаются, выполняя эти
роли.
Говоря о диаграммах кооперации, часто упоминают два "уровня" таких
диаграмм - уровень экземпляров (примеров, Instance-Level) и уровень
спецификации (Specification-Level). Уровень экземпляров отображает
взаимодействия между объектами (экземплярами классов); такая диаграмма
обычно создается, чтобы исследовать внутреннее устройство объектно¬
ориентированной системы. Уровень же спецификации используется для изучения
ролей, исполняемых в системе основными классами. В любом случае, диаграмма
взаимодействия не отображает процесс. Она показывает взаимодействие между
объектами, которое, как мы уже знаем, осуществляется путем посылки и приема
сообщений. При этом точная последовательность сообщений не так хорошо
видна, как на диаграмме последовательностей, так что если для вас важно
отобразить именно порядок отправки и приемов сообщений, используйте
диаграмму последовательностей.
Кооперация (collaboration) - статическая конструкция для моделирования
набора сущностей, взаимодействующих друг с другом. Кооперация определяет
набор взаимодействующих ролей, используемых вместе, чтобы показать некую
117

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

имя роли : имя класса
Имя роли или имя класса можно опустить, однако двоеточие должно
остаться.
Связи между объектами изображаются на диаграмме в виде ролей в
ассоциации, включая временные связи: аргументы процедур, локальные
переменные и самосвязи. Несколько ролей в ассоциации могут иметь одно и то же
имя ассоциации, если, разумеется, они соединяют различные роли
классификатора. Стрелки на линиях указывают направление навигации, которое
соответствует направлению, указанному стрелкой. (Наконечник стрелки,
расположенный на линии между объектами-прямоугольниками, обозначает
одностороннюю навигацию. Стрелка рядом с линией указывает на направление
потока сообщений по этой связи. Поток сообщений не может двигаться по
односторонней связи в обратную сторону, поэтому направление потоков
сообщений должно совпадать с направлением навигационных стрелок.)
Поскольку диаграмма кооперации - всего лишь альтернативная форма
представления той же информации, которая содержится в диаграмме
последовательностей, то и обозначения объектов (классов) в ней, по сути, такие
же, как и на диаграмме последовательностей (и на других диаграммах) [3].
Рис. 81. Пример диаграммы кооперации
Диаграмма иллюстрирует покупку некоторого товара (вероятно, в онлайне) и
оплату с помощью кредитной карты (Рис. 81). Еще одна интересная вещь,
которую можно увидеть на этой диаграмме - это сообщения, вернее, то, как они
изображаются. Сообщения показаны в виде текста (названия метода) со стрелкой.
Но есть один нюанс: на диаграмме последовательностей было легко показать
последовательность отправки сообщений, так как линии жизни служили
одновременно "осями времени", направленными вниз, и, естественно, было видно,
что нижние сообщения отправлены позже верхних.
В диаграммах взаимодействия проблему отображения очередности
сообщений решили просто - перед названием каждого сообщения просто пишут
его номер. Выглядит эта конструкция так:
119

номер : названиесообщения
Причем часто используют и составные номера. Например, объект отправил
другому объекту сообщение с номером 1. Когда объект-получатель в свою
очередь отправляет сообщения другим объектам, они получают номера 1.1, 1.2 и
т. д. Иногда нужно показать одновременную отправку сообщений. Чтобы
отметить параллельные потоки сообщений, их номера предваряют буквами A, B,
C, D и т. д.
Мультиобъект показывает, что на "дальнем" конце ассоциации находится не
один, а целый набор объектов. Такая конструкция используется, чтобы показать
операцию, которая нацелена на целый набор объектов. Мультиобъект
изображается как два прямоугольника, смещенных по отношению друг к другу,
что создает впечатление "колоды карт". Сообщение, отправленное
мультиобъекту, означает сообщение к набору объектов, например, операция
выбора - поиска определенного объекта. Пример подобной диаграммы показан на
Рис. 82:
Рис. 82. Диаграмма кооперации с мультиобъектом
Для печати документа из некоторого приложения необходимо выбрать из
всех доступных некий конкретный принтер. Символ композиции применен для
того, чтобы показать, что принтер входит в состав набора объектов. Предположим
теперь, что у нас доступны несколько сетевых принтеров и один локальный. Как
показать, что выбран именно он? Легко. Для этого используют связи со
стереотипами. Чтобы показать, что выбран локальный принтер, чуть изменим
предыдущую диаграмму:
120

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

не присущее самим ролям, а являющееся всего лишь побочным эффектом
использованию этих ролей в более широком контексте. Зачастую, один и тот же
объект играет роли в нескольких кооперациях, являясь частью общей кооперации.
Благодаря такому наложению кооперации между ними возникает неявный поток
управления и информации.
Кооперация, которая описывает операцию, также включает в себя символы
ролей, представляющие собой аргументы операции, а также локальные
переменные, создаваемые во время выполнения операции. Объекты, создаваемые
во время выполнения операции, могут быть помечены как {new} (новый);
объекты, которые во время выполнения операции уничтожаются, - как {destroyed}
(уничтожаемый). Те же объекты, которые создаются и уничтожаются во время
выполнения операции, можно пометить как {transient} (временные). Объекты, не
помеченные никаким ключевым словом, существуют на момент начала
выполнения операции и продолжают свое существование после его окончания.
В отличие от диаграммы последовательности, на диаграмме кооперации
изображаются только отношения между объектами, играющими определенные
роли во взаимодействии. С другой стороны, на этой диаграмме не указывается
время в виде отдельного измерения. Поэтому последовательность взаимодействий
и параллельных потоков может быть определена с помощью порядковых номеров.
Следовательно, если необходимо явно специфицировать взаимосвязи между
объектами в реальном времени, лучше это делать на диаграмме
последовательности.
Поведение системы может описываться на уровне отдельных объектов,
которые обмениваются между собой сообщениями, чтобы достичь нужной цели
или реализовать некоторый сервис. С точки зрения аналитика или конструктора
важно представить в проекте системы структурные связи отдельных объектов
между собой. Такое статическое представление структуры системы как
совокупности взаимодействующих объектов и обеспечивает диаграмма
кооперации.
Таким образом, с помощью диаграммы кооперации можно описать полный
контекст взаимодействий как своеобразный временной «среза» совокупности
объектов, взаимодействующих между собой для выполнения определенной
задачи или бизнес-цели программной системы.
8.2	Практическая часть
Для того чтобы добавить диаграмму кооперации в представление Logical
View, щелкните правой кнопкой мыши по Logical View (либо по каталогу, в
котором содержится ранее созданная диаграмма последовательности), в
контекстном меню выберите пункт Add Diagram, в списке выберите диаграмму
кооперации Communication Diagram.
Для сценария Оформление заказа, для которого мы уже составили диаграмму
последовательности. На диаграмму кооперации поместим все те же объекты,
перетащив их с навигатора модели (Рис. 83) [5].
122

: enter personal info()
2 :
PlaceOrder :
PlaceOrder
EnterPersonallnformatJon :
1 : place orderQ
EnterPersonallnformation
4 : save deta ils()
3 : confirmorderQ
Customer
ConfirmOrder
ConfirmOrder
5 : place orderQ
PlaceOrderManaaer :
PlaceOrderManaaer
6 : validate :redit()
: Credit System
: display orderQ
Item :
Item
: getT?m{J‘-'--|
Order :
Order
OrderConfirmation :
8 : create orderQ
OrderConfirmation
Рис. 83. Кооперативная диаграмма сценария Оформление заказ
8.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму кооперации,
продемонстрированную на Рис. 83.
ЗАДАНИЕ 2. (Проектное) Разработать структурную модель взаимодействия
объектов в виде диаграммы кооперации, акцентирующей внимание на
структурных связях между объектами при выполнении конкретного сценария в
информационной системе на заданную тему (Приложение 1). Диаграмма
коопераций должна соответствовать ранее разработанным диаграмме
последовательности (для понимания временной последовательности) и диаграмме
классов (для определения статических связей).
Требуемый результат:
1.	Одна детализированная диаграмма кооперации, отображающая
взаимодействие объектов в рамках выбранного сценария с акцентом на
структурные отношения между ними, включая ссылки и
последовательность сообщений.
2.	Текстовая документация:
•	Общее описание моделируемого взаимодействия и его особенностей.
•	Пояснения для ключевых ролей, ссылок и последовательности
сообщений.
•	Описание преимуществ использования диаграммы кооперации для
данного сценария.
3.	Готовый проект.
123

План выполнения:
1.	Выбор сценария и определение ролей объектов
1.1.	На основе темы индивидуального задания выбрать сценарий, где важны
структурные связи между объектами.
Пример для системы "Прокат велосипедов": "Сценарий обработки
возврата велосипеда с проверкой состояния", "Сценарий сложного
расчета стоимости аренды".
1.2.	Определить роли (roles) - объекты, участвующие во взаимодействии, и их
специфические обязанности в данном сценарии.
Пример:	клиент: Клиент, аренда: Аренда, велосипед:Велосипед,
тлъкулятор:КалъкуляторСтоимости.
2.	Построение структурного контекста и связей
2.1.	Расположить роли объектов на диаграмме в виде прямоугольников.
2.2.	Определить ссылки (links) между объектами, которые позволяют им
взаимодействовать. Показать эти связи линиями между объектами.
Пример: связь между клиент:Клиент и аренда:Аренда, а также между
аренда:Аренда и велосипед:Велосипед.
2.3.	Проверить, что все необходимые для взаимодействия структурные связи
присутствуют на диаграмме.
3.	Определение последовательности сообщений
3.1.	Для каждой связи определить сообщения (messages), которые передаются
между объектами.
3.2.	Пронумеровать сообщения в порядке их выполнения, используя
десятичную нотацию для вложенных вызовов.
Пример: 1: запроситъВозврат(), 1.1: проверитъСостояние(), 1.2:
рассчитатъИтоговуюСтоимостъ().
3.3.	Указать направление сообщений с помощью стрелок.
4.	Детализация сложных взаимодействий
4.1.	Использовать условные сообщения с указанием условий в квадратных
скобках.
Пример: 2: [повреждение обнаружено] уведомитъОРемонте().
4.2.	Применить итерации для показа циклических взаимодействий.
Пример: 1.1.*: проверитъВсеКомпоненты().
4.3.	Моделировать вложенные вызовы через детальную нумерацию сообщений.
5.	Сравнение с диаграммой последовательности и выявление преимуществ
5.1.	Проанализировать, какие структурные аспекты взаимодействия лучше
видны на диаграмме кооперации по сравнению с диаграммой
последовательности.
5.2.	Убедиться, что диаграмма демонстрирует явные преимущества в
отображении структурных отношений.
6.	Написание документации
6.1.	Составить общее описание взаимодействия:
6.1.1.	Название сценария: (Какой процесс моделируется).
124

6.1.2.	Особенности представления: (Почему для этого сценария выбрана
диаграмма кооперации).
6.1.3.	Ключевые структурные отношения: (Важные связи между объектами).
6.2.	Для ключевых ролей дать пояснение.
Пример:	"Роль	'калькуляторКалькуляторСтоимости':	объект,
ответственный за расчет итоговой стоимости с учетом всех
параметров аренды и примененных акций."
6.3.	Для важных сообщений описать их назначение.
Пример: "Сообщение 1.2.1: получитьТариф() - запрос к объекту тарифа
для получения базовой стоимости проката."
7.	Оформление и сохранение проекта
7.1.	Проверить диаграмму на соответствие нотации UML 2.x.
7.2.	Убедиться, что нумерация сообщений последовательна и логична.
7.3.	Организовать расположение объектов для максимальной наглядности
структурных связей.
7.4.	Сохранить проект и экспортировать итоговую диаграмму в формат .pdf или
.png для отчета.
8.4	Контрольные вопросы
1.	Для каких четырех основных целей применяются диаграммы кооперации?
2.	Какие два "уровня" диаграмм кооперации часто упоминаются и в чем их
различие?
3.	Как графически изображается кооперация (collaboration) на диаграмме?
4.	Что такое "роль классификатора" и как задается ее синтаксис на диаграмме?
5.	Как на диаграмме кооперации решается проблема отображения очередности
отправки сообщений?
6.	Что обозначает символ "мультиобъекта" и как он графически изображается?
7.	Как на диаграмме можно уточнить характер связи между объектами,
например, указать, что принтер является локальным?
8.	Какими ключевыми словами помечаются объекты, создаваемые и
уничтожаемые в процессе выполнения операции?
9.	В чем заключается основное отличие между диаграммой кооперации и
диаграммой последовательности с точки зрения представления времени и
последовательности?
10.	Что показывает диаграмма кооперации с точки зрения структурной
организации системы?
11.	Может ли один и тот же объект быть связан с несколькими ролями в разных
кооперациях, и что представляет собой такое взаимодействие?
12.	Для описания реализации какой сущности может использоваться кооперация,
и что она в себя включает для класса?
125

9.	ДИАГРАММА ОБЪЕКТОВ (OBJECT DIAGRAM)
9.1	Теоретическая часть
Диаграмма объектов представляет собой визуальное отображение
экземпляров классов и их взаимосвязей в системе в определенный момент
времени. Она служит "снимком" состояния системы, показывающим, как объекты
одного или нескольких классов взаимодействуют друг с другом. Диаграмма
объектов позволяет разработчикам более детально понять структуру системы и
связи между её компонентами.
Диаграммы объектов применяются в различных ситуациях, включая:
•	Демонстрацию примеров структур данных.
•	Проверку точности и полноты диаграммы классов на этапе анализа
проекта.
•	Иллюстрацию конкретных примеров необходимых классификаторов
перед созданием диаграммы классов.
•	Объяснение небольших частей сложной диаграммы классов или
моделирование рекурсивных отношений.
Таким образом, диаграммы объектов представляют статический вид системы
с точки зрения проектирования и процессов, являясь основой для сценариев,
описываемых диаграммами взаимодействия. Говоря другими словами, диаграмма
объектов используется для пояснения и детализации диаграмм взаимодействия,
например, диаграмм последовательностей. Приведем простейший пример такой
диаграммы (Рис. 84).
Рис. 84. Пример диаграммы объектов
Основные элементы диаграммы объектов включают:
126

Объекты: представляют собой экземпляры классов и отображаются в виде
прямоугольников с именем объекта и именем его класса, разделенными
двоеточием и подчеркнутыми.
Атрибуты объектов: перечисляются в отдельном блоке внутри
прямоугольника объекта, показывая их конкретные значения.
Связи (Links): линии, соединяющие два объекта, показывающие отношения
между ними. Связи могут быть одно- или двунаправленными.
Диаграмма объектов соотносится с диаграммой классов: последняя содержит
описание общей ситуации, а первая - описание конкретных экземпляров,
выводимых из диаграммы классов.
При построении диаграммы объектов следует следовать нескольким
принципам:
1.	Определите механизм, который необходимо смоделировать, включая
функции или поведение части системы.
2.	Идентифицируйте классы и интерфейсы, участвующие в механизме, а
также их отношения.
3.	Рассмотрите сценарий, проходящий через механизм. Зафиксируйте его в
определенный момент времени и отобразите все участвующие объекты.
4.	Отобразите состояние и значения атрибутов каждого объекта, чтобы
лучше понять сценарий.
5.	Отобразите связи между объектами, представляющие собой экземпляры
ассоциаций.
9.2	Практическая часть
Диаграммы объектов относятся к логическому представлению системы
Logical View. Для создания новой диаграммы объектов выполним следующие
шаги: щелкнуть правой кнопкой мыши по папке представления Logical View в
навигаторе модели, в контекстном меню выбрать пункт Add Diagram, в списке
выбрать диаграмму классов Object Diagram.
В качестве примера на Рис. 85 показана совокупность объектов, взятая из
реализации автономного робота. Внимание здесь акцентировано на нескольких
объектах, составляющих часть механизма робота, предназначенного для расчета
модели окружающей среды, в которой тот перемещается. Разумеется, в работе
системы принимает участие гораздо больше объектов, но на данной диаграмме
рассматриваются только абстракции, непосредственно вовлеченные в процесс
формирования представления окружающей среды.
127

w1 : Wall
w2: Wall
d8 : Door
w3: Wall
width = 36
width = 96
width = 36
width = 96
r: Robot hnovinal
N
t
w: World
а1 : Area I a2 : Area
Рис. 85. Моделирование структур объектов
Как видно из рисунка, один из объектов соответствует самому роботу (г,
экземпляр класса Robot) и в настоящий момент находится в состоянии moving
(движется). Этот объект связан с экземпляром w класса World (Мир),
являющегося абстракцией модели мира робота. В свою очередь объект w связан с
мультиобъектом, который состоит из экземпляров класса Element (Элемент),
описывающего сущности, опознанные роботом, но еще не включенные в его
модель мира. Такие элементы помечены как части глобального состояния робота.
В текущий момент времени экземпляр w связан с двумя экземплярами класса
Area. У одного из них (а2) показаны его собственные ссылки на объекты класса
Wall (Стена) и объект класса Door (Дверь).
Указана ширина каждой из трех стен и отмечено, что каждая связана с
соседними. Как видно из диаграммы, робот распознал, что замкнутое помещение,
в котором он находится, имеет с трех сторон стены, а с четвертой - дверь.
Создавая диаграммы объектов на языке UML, помните, что каждая такая
диаграмма - это всего лишь графическое изображение статического
представления системы с точки зрения проектирования или процессов. Ни одна
отдельно взятая диаграмма объектов не в состоянии передать всю заключенную в
этих представлениях информацию. На самом деле во всех системах, кроме самых
тривиальных, существуют сотни, а то и тысячи объектов, большая часть которых
анонимна. Полностью специфицировать все объекты системы и все способы,
которыми они могут быть ассоциированы, невозможно. Следовательно,
диаграммы объектов должны отражать только некоторые конкретные объекты
или прототипы, входящие в состав работающей системы.
Таким образом, диаграмма объектов позволяет визуализировать, как
конкретные экземпляры классов взаимодействуют друг с другом в системе,
обеспечивая ясное и понятное представление о структуре и поведении системы в
определенный момент времени.
128

9.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму объектов,
продемонстрированную на Рис. 84.
ЗАДАНИЕ 2. (Проектное) Разработать статическую модель конкретного
экземпляра системы в виде диаграммы объектов, отображающей снимок системы
в определенный момент времени для заданной темы информационной системы
(Приложение 1). Диаграмма объектов должна соответствовать ранее
разработанной диаграмма классов (для понимания структуры классов и связей
между ними).
Требуемый результат:
1.	Одна детализированная диаграмма объектов, представляющая
конкретные экземпляры классов с установленными значениями атрибутов
и связей между объектами в определенный момент времени выполнения
системы.
2.	Текстовая документация:
•	Общее описание моделируемой ситуации или сценария.
•	Пояснения для ключевых объектов и их значений атрибутов.
•	Обоснование установленных связей между объектами.
3.	Готовый проект.
План выполнения:
1.	Выбор контекста и определение момента времени
1.1.	На основе темы индивидуального задания выбрать конкретный сценарий
или ситуацию для моделирования.
Пример для системы "Прокат велосипедов": "Состояние системы после
оформления аренды клиентом Ивановым", "Объектная структура
активной аренды №123".
1.2.	Определить момент времени, который представляет диаграмма -
конкретное состояние системы после выполнения определенных действий.
1.3.	Выбрать масштаб моделирования - какие объекты включать в диаграмму
для репрезентативности.
2.	Создание объектов и установка значений атрибутов
2.1.	Для выбранного сценария создать объекты (экземпляры классов),
используя нотацию: имяОбъекта:ИмяКласса.
Пример:	клиентИванов:Клиент,	аренда123:Аренда,
велосипед005:Велосипед.
2.2.	Для каждого объекта установить конкретные значения атрибутов в формате
атрибут = значение.
Пример: клиентИванов:Клиент {id = 15, фио = "Иванов А.С.", телефон =
"+ 79161234567"}.
3.	Установление связей между объектами
3.1.	Определить ссылки (links) между объектами на основе ассоциаций из
диаграммы классов.
3.2.	Указать ролевые имена и мультипликаторы для связей, где это необходимо.
129

4.	Моделирование композитных структур и множественных связей
4.1.	Для объектов, являющихся частью композитных структур, явно показать
отношения композиции или агрегации.
4.2.	Отобразить объекты с множественными связями, показав все релевантные
связи в выбранном контексте.
5.	Проверка согласованности и целостности
5.1.	Проверить, что все связи между объектами допустимы согласно диаграмме
классов.
5.2.	Убедиться, что значения атрибутов соответствуют типам данных и
ограничениям, определенным в диаграмме классов.
5.3.	Проверить целостность диаграммы - все показанные связи должны иметь
соответствующие объекты на диаграмме.
6.	Написание документации
6.1.	Составить общее описание контекста:
6.1.1.	Моделируемая ситуация: (Какой сценарий или состояние системы
представлено).
6.1.2.	Момент времени: (Когда существует данное состояние системы).
6.1.3.	Назначение диаграммы: (Для чего создается этот снимок системы).
6.2.	Для ключевых объектов дать пояснение
Пример:	"Объект	'аренда123:Аренда': представляет конкретную
активную аренду велосипеда, начатую 15.05.2024 в 10:30."
6.3.	Для важных значений атрибутов объяснить их значение:
Пример: "Атрибут 'статус = "активна"' указывает, что аренда в
настоящее время продолжается."
7.	Оформление и сохранение проекта
7.1.	Проверить диаграмму на соответствие нотации UML 2.x.
7.2.	Убедиться, что диаграмма читаема и логически организована.
7.3.	Сгруппировать связанные объекты для лучшего восприятия структуры.
7.4.	Сохранить проект и экспортировать итоговую диаграмму в формат .pdf или
.png для отчета.
9.4	Контрольные вопросы
1.	Что представляет собой диаграмма объектов и какую метафору часто
используют для её описания?
2.	Для каких четырёх основных целей применяются диаграммы объектов?
3.	Как диаграмма объектов соотносится с диаграммой классов?
4.	Каковы три основных элемента диаграммы объектов?
5.	Как графически отображается объект (экземпляр класса) на диаграмме
объектов?
6.	Что такое "связь" (link) на диаграмме объектов и как она отображается?
7.	Каков первый шаг в процессе построения диаграммы объектов?
8.	Какую информацию показывают в блоке атрибутов объекта на диаграмме?
9.	Почему ни одна отдельная диаграмма объектов не может передать полную
информацию о системе?
130

10.	Какие объекты обычно выбирают для отображения на диаграмме объектов в
сложных системах?
11.	Что представляют собой связи между объектами с точки зрения диаграммы
классов?
12.	Для пояснения и детализации каких диаграмм часто используется диаграмма
объектов?
131

10.	ДИАГРАММА КОМПОНЕНТОВ (COMPONENT DIAGRAM)
10.1	Теоретическая часть
Диаграмма компонентов UML представляет собой структурную диаграмму,
которая показывает взаимосвязь между различными компонентами системы.
Компонент в UML — это модуль классов, представляющий независимую
подсистему, способную взаимодействовать с другими частями системы.
Диаграмма компонентов позволяет визуализировать физическую структуру
системы, акцентировать внимание на компонентах и их взаимосвязях, а также
подчеркнуть поведение сервисов в отношении интерфейсов.
Диаграммы компонентов используются в следующих случаях [3]:
1.	Для определения и организации компонентов системы в рамках
разработки на основе компонентов (component-based development, CBD).
2.	Для группировки классов по общему назначению, чтобы упростить
понимание структуры проекта.
3.	Для визуализации физической структуры системы и анализа взаимосвязей
между её компонентами.
4.	Для акцентирования внимания на сервисном поведении интерфейсов, что
помогает в проектировании и реализации системы.
Основные элементы диаграммы компонентов включают:
Компоненты:	модульные части системы, которые инкапсулируют
функциональность (отдельный модуль кода). Они обозначаются
прямоугольниками с пометкой «component» или значком компонента. Компонент
может иметь свои собственные свойства, такие как атрибуты и операции (Рис. 86).
Интерфейсы: Определяют операции, которые предоставляет или требует
компонент. Представляются кругами (леденцами) для предоставляемых
интерфейсов и полукругами (сокетами) для требуемых интерфейсов (Рис. 86).
«components а
Заказ
ЗаголовокЗаказа
заказ О -|
элемент *
СтрокаТовара
Клиент
—С
Местонахождение
Товара
	О
Рис. 86. Элементы диаграммы компонентов
Порты: Точки взаимодействия на границе компонента, обозначенные
маленькими квадратами.
132

Узлы: Представляют физические или виртуальные среды выполнения, в
которых развернуты компоненты, обозначаются трехмерными блоками.
Артефакты: Физические файлы, развернутые на узлах, обозначаются
прямоугольниками со стереотипом «artifact».
Отношения: Показывают зависимости и связи между компонентами
(например, зависимости, ассоциации, соединители сборки).
Компонент, как элемент модели, может иметь различную физическую
реализацию. Для более точной спецификации формы реализации компонента
можно использовать текстовый стереотип, который указывается выше строки с
именем компонента (Рис. 87).
133

Ключевое
слово
Перевод
Назначение
file
Файл
Определяет наиболее общую разновидность ком¬
понента, который представляется в виде произ¬
вольного физического файла
executable
Исполнимый
Определяет разновидность компонента-файла,
который является исполнимым файлом и может
выполняться на некоторой компьютерной плат¬
форме
document
Документ
Определяет разновидность компонента-файла,
который представляется в форме документа про¬
извольного содержания, не являющегося исполни¬
мым файлом или файлом с исходным текстом про¬
граммы
library
Библиотека
Определяет разновидность компонента-файла,
который представляется в форме динамической
или статической библиотеки
source
Источник
Определяет разновидность компонента-файла,
представляющего собой файл с исходным текстом
программы, который после компиляции может быть
преобразован в исполнимый файл
table
Таблица
Определяет разновидность компонента, который
представляется в форме таблицы базы данных
Рис. 87. Текстовые стереотипы компонентов
Из графических стереотипов наибольшее распространение получили три
группы символов. Для первой группы компонентов используются следующие
стереотипы [7]:
•	динамически подключаемые библиотеки, как правило имеющие
расширение DLL (Рис. 88, а);
•	Web-страницы на языке разметки гипертекста, как правило, имеющие
расширение HTML или HTML (Рис. 88, б);
•	файлы справки, как правило, имеющие расширение HLP (Рис. 88, в);
•	файлы с исходными текстами программ, имеющие, например, расширения
H и CPP для языка С++ (Рис. 88, г).
134

Рис. 88. Изображение графических стереотипов компонентов
При создании диаграммы компонентов следует учитывать следующие
принципы:
1.	Определите область системы и её требования.
2.	Идентифицируйте компоненты и их функциональность, обеспечивая
инкапсуляцию.
3.	Определите предоставляемые и требуемые интерфейсы для каждого
компонента.
4.	Определите взаимосвязи и зависимости между компонентами.
5.	Укажите артефакты и узлы, на которых будут развернуты компоненты.
6.	Нарисуйте диаграмму, используя UML-инструмент, и проверьте её на
точность.
Компонентное программирование
Идея компонентного или сборочного программирования также стара как
само программирование. Действительно затраты на тиражирование программ
любой величины и сложности неизмеримо малы по сравнению с затратами на их
разработку. Затратами на тиражирование можно просто пренебречь. Отсюда
возникает естественное желание не создавать каждую новую программу "с нуля",
а использовать ранее созданные программы в качестве готовых компонентов,
благо затраты на копирование столь невелики. Оставляя в стороне экономические
вопросы, связанные с правами собственности, сосредоточимся на техническом
аспекте: насколько реально компонентное программирование? Допустим, нужные
по функциональности программные компоненты доступны для копирования: как
можно их использовать при разработке новой программы? Ответ на этот вопрос
имеет огромное значение, прежде всего экономическое. Для решения данного
вопроса были предприняты беспрецедентные усилия, особенно в последние годы.
Оценка текущего состояния данного вопроса состоит из трех утверждений.
1.	Компонентное программирование является непреложным требованием
практики, без него прогресс в индустрии программного обеспечения
невозможен.
135

2.	В последние годы в этой области наблюдается значительный прогресс,
причем налицо тенденция к ускорению.
3.	Современные технологии компонентного программирования все еще
далеки от идеала и не в полной мере отвечают требованиям практики.
Поясним видение следующей аналогией. Автомобиль можно рассматривать
состоящим из компонентов: двигатель, трансмиссия, ходовая часть, кузов...
Можно ли собрать автомобиль из готовых компонентов? Ответ: да, если
компоненты были изготовлены в расчете на то, что из них будет собрана
конкретная модель автомобиля с применением конкретной технологии сборки. В
противном случае сборка проблематична. Однако в каждом достаточно большом
гаражном кооперативе можно найти умельца, который с помощью хорошего
набора ручных инструментов, природной смекалки и технического чутья может
собрать нечто, способное двигаться, из самых неожиданных компонентов. Пока
что, по нашему мнению, работа программистов, использующих готовые
компоненты, больше напоминает шаманство гаражного умельца, нежели
современное автоматизированное производство.
Что же является компонентом в смысле UML? Прежде всего, это компонент
в смысле сборочного программирования: особым образом оформленная часть
программного кода, которая может работать в составе более сложной программы.
К сожалению, такое определение слишком расплывчато: отдельная строка
исходного кода также может рассматриваться как компонент, но это, видимо, не
совсем то, чего мы хотим. На самом деле абсолютно формальное определение
компонента в UML дать невозможно.
При выделении компонентов применяются следующие неформальные
критерии:
•	Компонент нетривиален. Это нечто более сложное и объемное, чем
фрагмент кода или одиночный класс.
•	Компонент независим, но не самодостаточен. Он содержит все, что нужно
для функционирования, но предназначен для работы во взаимодействии с
другими компонентами.
•	Компонент однороден. Он выполняет несколько взаимосвязанных функций,
которые могут быть естественным образом охарактеризованы как единое целое в
контексте более сложной системы.
•	Компонент заменяем. Он поддерживает строго определенный набор
интерфейсов и может быть без ущерба для функционирования системы заменен
другим компонентом, поддерживающим те же интерфейсы.
Компоненты понимаются в UML в наиболее общем смысле: это не только
исполнимые файлы с кодами программы, но и исходные тексты программ,
вебстраницы, справочные файлы, сопроводительные документы, файлы с
данными и вообще любые артефакты, которые тем или иным способом
используются при работе приложения и входят в его состав.
В терминологии UML компонент — это классификатор, т. е. дескриптор,
описывающий множество однотипных объектов, и как всякий классификатор,
компонент может иметь экземпляры. Такой взгляд на компоненты может
показаться несколько надуманным, но он имеет свое обоснование в
136

необыкновенной легкости копирования электронных артефактов. Действительно,
если на компакт-диске с поставляемой системой записан, например, файл
документации, то можно считать, что это описание множества файлов с
документацией, потому что при развертывании системы этот файл может быть
легко скопирован на все рабочие станции в необходимом числе экземпляров [7].
10.2	Практическая часть
В приложении StarUML диаграмма развертывания уже находится в
представлении развертывания (Component View), иерархической структуры
проекта (подход Rational Approach).
% MODEL EXPLORER Q
CD
<
Untitled
►	Ц] Use Case View
►	S Logical View
*	Й Component View
Component View
*	Deployment View
Deployment View
Начать работу с диаграммой можно после ее активации двойным нажатием
ЛКМ.
Рассмотрим пример из информационной системы отдела кадров. Основное
назначение системы — хранить данные о кадрах и выполнять по указанию
пользователя некоторые операции с этими данными. Анализирую состав
операций, мы видим, что они сводятся к созданию, модификации и удалению
хранимых элементов данных. Стандартным решением в таких ситуациях является
применение готовой СУБД для управления данными. С точки зрения
проектирования информационной системы отдела кадров целесообразно считать
используемую СУБД готовым компонентом. Мы можем не заострять внимания на
структуре этого компонента — она стандартна и, наверное, достаточно хорошо
описана вне нашей модели. Нам достаточно определить интерфейс, с помощью
которого осуществляется взаимодействия. Подавляющее большинство СУБД
поддерживают интерфейс ODBC, и мы можем предположить, что такова же и
используемая нами система управления базам данных.
СУБД возьмет на себя все функции по непосредственному манипулированию
данными: создание, удаление и поиск записей в таблицах и т. д. Реализация
операций нашей информационной системы отдела кадров сводится к некоторой
последовательности элементарных операций с данными. Например, операция
перевода сотрудника с одной должности на другую, видимо, потребует изменения
в трех элементах данных: в данных о сотруднике и в данных о старой и новой
должностях. Однако, целесообразно ли считать, что определение и выполнение
самой последовательности элементарных операций с данными также является
137

прерогативой выделенного нами компонента — СУБД. Общепринятая практика
отвечает на этот вопрос отрицательно. По многим причинам лучше выделить это
в отдельный компонент, обычно называемый бизнес-логикой.
Наконец мы должны предположить, что в нашей системе должен быть
компонент, ответственный за пользовательский интерфейс. В первом
приближении мы приходим к структуре компонентов, приведенной на Рис. 89,
которая называется «трехуровневая архитектура».
Рис. 89. Диаграмма компонентов
10.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму компонентов,
продемонстрированную на Рис. 89.
ЗАДАНИЕ 2. (Проектное) Разработать архитектурную модель физической
структуры системы в виде диаграммы компонентов, отображающей компоненты
программного обеспечения, их интерфейсы и зависимости между ними для
информационной системы на заданную тему (Приложение 1). Диаграмма
компонентов должна соответствовать ранее разработанным диаграммам классов и
прецедентов (для понимания функциональных требований и логической
структуры).
Требуемый результат:
1.	Одна детализированная диаграмма компонентов, представляющая
основные структурные элементы системы, их интерфейсы и отношения
зависимости, показывающая организацию компонентов на уровне
исходного кода или выполнения.
2.	Текстовая документация:
•	Общее описание архитектурного решения системы.
•	Пояснения для ключевых компонентов и их назначения.
•	Описание интерфейсов и зависимостей между компонентами.
138

3.	Готовый проект.
План выполнения:
1.	Анализ функциональности и выделение компонентов
1.1.	На основе темы индивидуального задания и диаграмм прецедентов
провести анализ функциональных требований к системе.
1.2.	Выделить основные компоненты - модули, которые могут быть независимо
развернуты и заменены, представляющие собой функциональные блоки
системы.
Пример для системы "Прокат велосипедов": WebUI, MobileApp,
RentalService, PaymentGateway, UserManagement, BikeTracking.
2.	Определение интерфейсов компонентов
2.1.	Для каждого компонента определить предоставляемые интерфейсы
(provided interfaces), которые компонент реализует для использования
другими компонентами.
Пример: RentalService предоставляет интерфейс IRentalService с
операциями createRental(), completeRental().
2.2.	Определить требуемые интерфейсы (required interfaces), которые
компонент использует от других компонентов.
Пример: RentalService требует интерфейс IPaymentProcessing от
компонента PaymentGateway.
3.	Установление отношений между компонентами
3.1.	Определить зависимости (dependencies) между компонентами, показав,
какие компоненты требуют функциональности других компонентов.
3.2.	Использовать порты (ports) для явного указания точек взаимодействия
компонентов с внешней средой.
3.3.	Сгруппировать логически связанные компоненты в пакеты (packages), если
система достаточно крупная.
4.	Детализация внутренней структуры компонентов
4.1.	Для ключевых компонентов показать их внутреннюю структуру, указав
какие классы или интерфейсы реализуют функциональность компонента.
4.2.	Использовать делегирование (delegation) для показа связи между портами
компонента и его внутренними элементами.
4.3.	Указать стереотипы (stereotypes) для компонентов, если они относятся к
определенным технологическим слоям.
Пример: «service», «repository», «controller».
5.	Моделирование аспектов развертывания и повторного использования
5.1.	Показать компоненты, которые могут быть библиотеками или
исполняемыми модулями.
5.2.	Указать артефакты (artifacts), если диаграмма относится к уровню
реализации.
5.3.	Определить компоненты, предназначенные для повторного использования
в других системах.
6.	Написание документации
6.1.	Составить общее описание архитектуры:
139

6.1.1.	Архитектурный стиль (Многоуровневая архитектура, микросервисы и
т.д.).
6.1.2.	Назначение диаграммы (Уровень представления - уровень
выполнения или исходного кода).
6.1.3.	Ключевые компоненты (Обзор основных функциональных блоков).
6.2.	Для каждого компонента дать пояснение:
Пример:	"Компонент 'PaymentGateway': отвечает за обработку
платежных операций, интегрируется с внешними платежными
системами, предоставляет унифицированный интерфейс для обработки
транзакций."
6.3.	Для интерфейсов описать их назначение:
Пример: "Интерфейс 'IUserAuthentication': определяет контракт для
операций аутентификации и авторизации пользователей."
7.	Оформление и сохранение проекта
7.1.	Проверить диаграмму на соответствие нотации UML 2.x.
7.2.	Убедиться, что все зависимости между компонентами логически
обоснованы.
7.3.	Организовать компоненты по уровням или функциональным группам для
лучшей читаемости.
7.4.	Сохранить проект и экспортировать итоговую диаграмму в формат .pdf или
.png для отчета.
10.4	Контрольные вопросы
1.	Что такое диаграмма компонентов в UML и какую структуру системы она
представляет?
2.	Каковы основные цели использования диаграмм компонентов?
3.	Что такое компонент в контексте UML и как он обозначается на диаграмме?
4.	Какие два основных вида интерфейсов существуют на диаграмме
компонентов и как они графически изображаются?
5.	Что такое порт на диаграмме компонентов и как он обозначается?
6.	Для чего на диаграмме компонентов используются узлы и как они
обозначаются?
7.	Что представляют собой артефакты на диаграмме компонентов?
8.	Каковы основные этапы или принципы создания диаграммы компонентов?
9.	Каковы неформальные критерии выделения компонента в UML?
10.	Является ли компонент в UML только исполняемым файлом? Если нет, то
что еще он может представлять?
11.	Для чего используются текстовые стереотипы при спецификации
компонента?
140

11.	ДИАГРАММА РАЗВЕРТЫВАНИЯ (DEPLOYMENT DIAGRAM)
11.1	Теоретическая часть
Диаграмма развертывания — это тип структурной диаграммы UML, который
иллюстрирует физическое развертывание программных компонентов на
аппаратных узлах. Она показывает, как программные артефакты распределяются
между различными узлами системы, такими как серверы, процессоры и
устройства хранения данных, а также их взаимосвязи. Диаграммы развертывания
помогают понять архитектуру системы и ее компоненты, что критически важно
для успешного развертывания и поддержки программных решений [8].
Диаграммы развертывания применяются в различных ситуациях, включая:
1.	Планирование установки программных систем на различных устройствах.
2.	Проектирование необходимого аппаратного обеспечения для поддержки
программного обеспечения.
3.	Определение необходимых устройств и сетей, чтобы обеспечить
эффективную работу всех компонентов системы.
4.	Идентификация зависимостей между программным обеспечением и
аппаратным обеспечением, что позволяет находить узкие места и
улучшать производительность.
К основным элементам диаграммы развертывания относятся:
Узел (Node): представляет физический или вычислительный ресурс, на
котором развертываются программные компоненты (Рис. 90). Изображается в
виде трехмерного куба с закругленными углами. Узлы могут содержать
вложенные узлы, что позволяет отображать иерархии.
Сервер
:Сеовер Базы
Приложений
Данных № 1
а	6
Рис. 90. Графическое изображение: а - узла в качестве типа; б - узла в качестве экземпляра
Среда выполнения (execution environment) представляет собой узел, который
обладает функциональностью, необходимой для практического выполнения
развернутых на нем исполнимых артефактов (Рис. 91).
141

Рис. 91. Примеры изображения: а - среды выполнения; б - среды выполнения в узле
Компонент (Component): модульная часть системы, обычно реализуемая в
виде программного модуля или класса. Обозначается прямоугольником с двумя
выступами по бокам, указывающими на порты.
Устройство - это узел, который используется для представления физического
вычислительного ресурса в системе. Примером устройства является сервер
приложений.
С	71
Device
+ Attribute 1 : Туре
+ Attribute 2 : Type
-	Attribute 3 : Type
-	Attribute 4 : Type
т Operation 1 { arg Hat)
: return
+ Operation 2 { arg list'
: return
4 Operation 3 { arg Hat)
: return
+ Operation 4 ( arg list}
: return
Артефакт (Artifact): физический фрагмент информации, например,
исполняемый файл или библиотека. Представляется прямоугольником с
закругленным углом и пометкой "artifact".
«artifact» [j
«artifact» 0
Заказ.jar
Transaction.exe
Рис. 92. Примеры изображения: а - артефакта в качестве типа; б - экземпляра артефакта
Интерфейс (Interface): обозначает контракт, который должен реализовать
компонент. Изображается в виде круга.
142

Зависимость (Dependency): пунктирная линия с стрелкой, указывающая на
зависимость одного элемента от другого.
Ассоциация (Association): прямая линия, показывающая связь между узлами.
Диаграмма развертывания содержит графические изображения процессоров,
устройств, процессов и связей между ними. В отличие от диаграмм логического
представления, диаграмма развертывания является единой для системы в целом,
поскольку должна всецело отражать особенности ее реализации. Эта диаграмма,
по сути, завершает процесс ООАП для конкретной программной системы и ее
разработка, как правило, является последним этапом спецификации модели.
При разработке диаграмм развертывания преследуются следующие цели:
•	специфицировать физические узлы, необходимые для размещения на них
исполнимых компонентов программной системы;
•	показать физические связи между узлами реализации системы на этапе ее
исполнения;
•	выявить узкие места системы и реконфигурировать ее топологию для
достижения требуемой производительности.
При создании диаграммы развертывания следует учитывать следующие
принципы [9]:
1.	Идентификация компонентов: перечислите все программные и аппаратные
элементы, которые будут включены в диаграмму.
2.	Понимание взаимосвязей: выясните, как эти элементы взаимодействуют
друг с другом.
3.	Сбор требований: соберите информацию о необходимом аппаратном
обеспечении, сетевых настройках и других аспектах развертывания.
4.	Нарисуйте узлы и компоненты: используйте стандартные символы для
обозначения узлов и компонентов.
5.	Соедините узлы и компоненты: используйте линии и стрелки для
отображения взаимосвязей между элементами.
6.	Добавьте детали: укажите все важные характеристики и спецификации,
такие как параметры оборудования и протоколы связи.
11.2	Практическая часть
В приложении StarUML диаграмма развертывания уже находится в
представлении развертывания (Deployment View), иерархической структуры
проекта (подход Rational Approach).
143

m
<
Untitled
►	fS~j Use Case View
►	Ei Logical View
л E Component View
Component View
л E Deployment View
Deployment View
Начать работу с диаграммой можно после ее активации двойным нажатием
ЛКМ.
Рассмотрим пример из информационной системы отдела кадров. Сколько
компьютеров будет использоваться при работе данного приложения? На этот
вопрос нужно отвечать также вопросом: а сколько пользователей будет у системы
и сколько из них будут работать с приложением одновременно?
Если имеется только один пользователь (или, хуже того, нашу систему
установят "для галочки", а использовать не будут), то проблем нет — настольное
приложение — один компьютер и диаграмма размещения не нужна [10].
Допустим, что у нашей системы должно быть много пользователей и они
могут работать одновременно. Тогда ответ очевиден: узлов должно быть не
меньше, чем число одновременно работающих пользователей, потому что вдвоем
за одним компьютером обычным пользователям работать неудобно.
Скорее всего, узлов должно быть на единицу больше чем пользователей, т. к.
в большинстве организаций есть специально выделенный компьютер (сервер) для
хранения корпоративных данных, за которым никто не работает. Там мы и
разместим нашу базу данных, в расчете на то, что нужная СУБД, скорее всего, на
сервере уже установлена.
Остается вопрос о размещении компонентов, реализующих бизнес-логику.
Здесь возможны разные варианты: на компьютере пользователя, на
промежуточной машине (сервере приложений), на корпоративном сервере баз
данных. Если мы остановимся на последнем варианте (который на жаргоне
называется "архитектура клиент/сервер с тонким клиентом"), то получим
диаграмму, приведенную на Рис. 93 [2].
144

Рис. 93. Диаграмма развёртывания информационной системы отдела кадров
11.3	Практические задания
ЗАДАНИЕ 1. В приложении StarUML построить диаграмму развертывания,
продемонстрированную на Рис. 93.
ЗАДАНИЕ 2. (Проектное) Разработать модель физического развертывания
системы в виде диаграммы развертывания, отображающей аппаратные узлы,
программные компоненты и связи между ними для информационной системы на
заданную тему (Приложение 1). Диаграмма развертывания должна
соответствовать ранее разработанной диаграмме компонентов (для понимания
программной структуры системы).
Требуемый результат:
1.	Одна детализированная диаграмма развертывания, представляющая
физическую архитектуру системы, включая узлы выполнения,
устройства связи, размещенные компоненты и протоколы
взаимодействия.
2.	Текстовая документация:
•	Общее описание инфраструктуры развертывания системы.
•	Пояснения для ключевых узлов и их характеристик.
•	Описание связей и протоколов взаимодействия.
3.	Готовый проект.
План выполнения:
1.	Анализ требований к инфраструктуре
1.1.	На основе темы индивидуального задания проанализировать требования к
аппаратному обеспечению и сетевой инфраструктуре.
1.2.	Определить тип системы развертывания (веб-приложение, мобильное
приложение, desktop-приложение, гибридная система).
1.3.	Выявить необходимость интеграции с внешними системами и
устройствами.
2.	Определение узлов выполнения
145

2.1.	Выделить узлы выполнения (execution nodes) - аппаратные устройства и
серверы, на которых выполняется код.
Пример: Webserver, DatabaseServer, ApplicationServer, MobileDevice,
PaymentTerminal.
2.2.	Для каждого узла указать стереотипы и характеристики.
Пример: <<cloud_server>>, <<database_server>>, OS=Linux, RAM=16GB.
3.	Определение артефактов и их размещения
3.1.Определить артефакты (artifacts) - физические единицы информации,
размещаемые на узлах.
Пример: webapp.war, database.sql, mobile-app.apk, configuration.properties.
3.2.	Указать отношения размещения (deployment) между артефактами и узлами.
3.3.	Показать зависимости между артефактами.
4.	Спецификация связей и протоколов
4.1.	Определить связи (communication paths) между узлами.
4.2.	Для каждой связи указать протоколы взаимодействия.
Пример: HTTP/HTTPS, JDBC, REST API, WebSocket.
4.3.	Указать характеристики соединений (пропускная способность, задержки).
5.	Моделирование внешних зависимостей
5.1.	Выделить внешние системы и сервисы.
Пример: ExternalPaymentGateway, SMTPServer, CloudStorage.
5.2.	Показать интерфейсы взаимодействия с внешними системами.
5.3.	Указать протоколы интеграции.
6.	Детализация конфигурации
6.1.	Для критичных узлов показать внутреннюю структуру (процессоры,
память, диски).
6.2.	Указать требования к производительности.
6.3.	Показать резервирование и балансировку нагрузки.
7.	Написание документации
7.1.	Общее описание инфраструктуры:
7.1.1.	Архитектура развертывания:	(Монолитная, микросервисы,
гибридная).
7.1.2.	Масштабируемость:	(Вертикальное/горизонтальное
масштабирование).
7.1.3.	Требования к доступности: (SLA, время бесперебойной работы).
7.2.	Описание узлов.
Пример: "Узел 'DatabaseServer': сервер базы данных на PostgreSQL,
развернутый в основном дата-центре, с репликацией в резервный ЦОД."
7.3.	Описание связей.
Пример: "Связь 'LAN/WAN': гигабитная сеть между серверами, VPN-
туннели для удаленных узлов."
8.	Верификация и оформление
8.1.	Проверить соответствие нотации UML 2.x.
8.2.	Убедиться в логичности и реализуемости архитектуры.
8.3.	Проверить учет требований безопасности и производительности.
146

8.4.	Организовать узлы по зонам ответственности или физическому
расположению.
9.	Сохранение результатов
9.1.	Сохранить проект и экспортировать диаграмму в форматы .pdf и .png.
11.4	Контрольные вопросы
1.	Что такое диаграмма развертывания UML и какую часть системы она
иллюстрирует?
2.	Каковы основные цели создания и использования диаграмм развертывания?
3.	Что такое узел и как он графически изображается на диаграмме?
4.	Чем отличается графическое изображение узла-типа от узла-экземпляра?
5.	Что представляет собой среда выполнения на диаграмме развертывания?
6.	Что такое артефакт и как он обозначается на диаграмме?
7.	Как на диаграмме развертывания изображается зависимость между
элементами?
8.	Каковы ключевые этапы или принципы создания диаграммы развертывания?
9.	Почему диаграмма развертывания является единой для системы в целом?
10.	Какую роль в контексте диаграммы развертывания играет устройство?
11.	Какой элемент диаграммы используется для представления физического
фрагмента информации, такого как исполняемый файл?
12.	Какую информацию необходимо собрать на этапе подготовки к созданию
диаграммы развертывания?
147

12.	ПРОЦЕСС РАЗРАБОТКИ (DEVELOPMENT PROCESS)
12.1	Представления
Было бы очень соблазнительно иметь возможность строить модели любых
систем единообразно, придерживаясь, так сказать, одной универсальной точки
зрения. Во многих ранних методологиях моделирования и проектирования
программных систем такие попытки (более или менее удачные)
предпринимались. Как показывает практический опыт, не удается описать с
единой точки зрения все без исключения аспекты моделируемой системы.
Действительно, в модели нужно отразить множество вещей: интерфейсы для
взаимодействия с внешним миром, внутреннюю логическую структуру
программы, структуру хранимых данных, алгоритмы функционирования, состав
артефактов, включаемых в поставку и многое другое. Было бы самонадеянно
утверждать, что единое средство описания всех аспектов сразу в принципе
невозможно — просто пока мы не знаем такого средства. Отсюда следует вывод
[2]:
Моделировать сложную систему следует с нескольких различных точек
зрения, каждый раз принимая во внимание один аспект моделируемой системы и
абстрагируясь от остальных.
Этот тезис является одним из основополагающих принципов UML, по
нашему мнению, может быть самым важным принципом, предопределившим
практический успех UML. Идея состоит в том, что абстрактный граф модели,
состоящий из множества разнотипных сущностей и отношений, не подлежит
конструированию или изучению в целом. Каждый раз для визуализации,
изменения или иных манипуляций из этого общего графа вычленяются только
сущности и отношения, релевантные для определенного аспекта моделируемой
системы, а все остальные игнорируются. Такой вид с определенной точки зрения,
можно сказать проекцию модели, мы называем представлением.
12.2	Пять представлений
Набор используемых представлений модели является еще менее формальным
и догматическим, чем набор канонических типов диаграмм. Например, одним из
самых популярных является набор представлений, описанных авторами UML
показанных на Рис. 94 [2].
148

Design Vi
Process \
Рис. 94. Пять представлений модели
Представление использования — это описание поведения системы с точки
зрения внешних по отношению к ней агентов. Структурные аспекты передаются
диаграммами использования, а поведенческие аспекты — диаграммами
взаимодействия, состояний и деятельности. Логическое представление
предназначено для описания словаря предметной области, то есть, в парадигме
объектно-ориентированного программирования, классов. Структурные аспекты
передаются диаграммами классов и объектов, а поведенческие аспекты —
диаграммами взаимодействия, состояний и деятельности. Представление
процессов — это описание взаимодействия процессов во время работы системы.
Оно отражает такие аспекты, как параллелизм, синхронизация,
производительность, масштабируемость, пропускная способность. Структурные
аспекты передаются с помощью концепции активных классов: процессы и потоки,
а поведенческие аспекты — диаграммами взаимодействия, состояний и
деятельности. Представление компонентов — это описание конфигурации
системы на уровне артефактов. Структурные аспекты передаются диаграммами
компонентов, а поведенческие аспекты — диаграммами взаимодействия,
состояний и деятельности. Представление размещения отражает топологию
связей аппаратных средств и размещения на них компонентов. Структурные
аспекты передаются диаграммами размещения, а поведенческие аспекты —
диаграммами взаимодействия, состояний и деятельности.
С другой стороны были случаи использования восеми представлений, как
показано на Рис. 95 [2].
12.3	Восемь представлений
149

Представления
Диаграммы
Основные концепции
Статическое
представление
Диаграмма классов
Класс, ассоциация, обобщение,
зависимость, реализация, интерфейс
Представление
использования
Диаграмма
использования
Вариант использования, действующее
лицо, ассоциация, расширение,
включение, обобщение вариантов
использования
Представление
реализации
Диаграмма
компонентов
Компонент, интерфейс, зависимость,
реализация
Представление
размещения
Диаграмма
размещения
Узел, компонент, зависимость,
расположение
Представление
конечных
автоматов
Диаграмма
состояний
Состояние, событие, переход, действие
Представление
деятельности
Диаграмма
деятельности
Состояние, деятельность, переход по
завершении, развилка, слияние
Представление
взаимодействия
Диаграмма
последовательности
Взаимодействие, объект, сообщение,
активация
Диаграмма
кооперации
Кооперация, взаимодействие, роль в
кооперации, сообщение
Представление
управления
моделью
Диаграмма классов
Пакет, подсистема, модель
Рис. 95. Представления модели и диаграммы в языке UML
Нельзя не заметить, что здесь набор представлений не многим отличается от
набора канонических диаграмм, если не считать управления моделями.
Включение этого аспекта в число представлений нам представляется спорным.
12.4	Три представления
Учитывая неформальный характер понятия представления и опираясь на
собственный опыт использования UML, мы рискнем предложить свой вариант
набора представлений. Их всего три [2].
Представление использования. По сути это то же самое представление, что
было указано выше. Представление использования призвано отвечать на вопрос,
что делает система полезного. Определяющим признаком для отнесения
элементов модели к представлению использования является, по нашему мнению,
явное сосредоточение внимание на факте наличия у системы внешних границ, то
есть выделение внешних действующих лиц, взаимодействующих с системой, и
внутренних вариантов использования, описывающих различные сценарии такого
150

взаимодействия. Таким образом, единственным выразительным средством
представления использования оказываются диаграммы использования.
Представление структуры. Представление структуры призвано отвечать (с
разной степенью подробности) на вопрос: из чего состоит система.
Определяющим признаком для отнесения элементов модели к представлению
структуры является явное выделение структурных элементов — составных частей
системы — и описания взаимосвязей между ними. Принципиальным является
чисто статический характер описания, то есть отсутствие понятия времени в
любой форме, в частности, в форме последовательности событий и/или действий.
Представление структуры описывается прежде всего и главным образом
диаграммами классов, а также, если нужно, диаграммами компонентов и
размещения и, в редких случаях, диаграммами объектов.
Представление поведения. Представление поведения призвано отвечать на
вопрос: как работает система. Определяющим признаком для отнесения
элементов модели к представлению поведения является явное использования
понятия времени, в частности, в форме описания последовательности
событий/действий, то есть в форме алгоритма. Представление поведения
описывается диаграммами состояний и деятельности, а также диаграммами
взаимодействия в форме диаграмм кооперации и/или последовательности. Такой
набор представлений является (почти) ортогональным и согласованным с
классификацией диаграмм. Более того, он во многом инспирирован личным
опытом моделирования.
Автору никогда не удавалось построить разумную модель для мало-мальски
сложной системы так, как это рекомендуется в некоторых учебниках: сначала
построить представление использования, затем последовательно логическое
представление, представления процессов и компонентов и, наконец,
представление развертывания. Если процесс моделирования заканчивался
удовлетворительным результатом, то он (процесс) оказывается итеративным и
параллельным, примерно таким как показано на Рис. 96.
151

Рис. 96. Процесс моделирования
Другими словами, процесс итеративный, на каждом шаге может
присутствовать уточнение представления использования, за которым следует
параллельное моделирование структуры и поведения.
12.5	Советы по применению UML
Унифицированный язык моделирования (UML) является мощным
инструментом для визуализации, проектирования и документирования
программных систем. Однако его эффективность напрямую зависит от того,
насколько грамотно и целесообразно он применяется. Следующие советы помогут
использовать UML с максимальной пользой, избегая распространенных ошибок.
1.	Помните: UML — это средство, а не цель.
Главная ошибка начинающих аналитиков — создание избыточно
детализированных и сложных моделей, которые не несут практической ценности.
Модель должна решать конкретную задачу: прояснить архитектурное решение,
документировать взаимодействие с пользователем или объяснить сложную
бизнес-логику команде разработчиков. Не рисуйте диаграммы ради самих
диаграмм. Если модель перестала быть полезной, ее следует переработать или
отказаться от нее.
2.	Адаптируйте уровень детализации под аудиторию.
Одну и ту же систему можно моделировать с разной степенью подробности.
152

Для обсуждения с заказчиком или бизнес-аналитиком идеально подходят
диаграммы вариантов использования (Use-Case Diagram) и высокоуровневые
диаграммы деятельности (Activity Diagram). Они понятны не-техническим
специалистам и фокусируются на что система делает, а не как.
Для разработчиков и архитекторов необходимы более детальные диаграммы
классов (Class Diagram), диаграммы последовательности (Sequence Diagram) и
диаграммы состояний (Statechart Diagram). Они описывают структуру,
взаимодействие объектов и сложное поведение системы.
3.	Используйте правильную диаграмму для правильной задачи.
UML предлагает 14 типов диаграмм, но на практике активно используется
около 5-7. Выбор зависит от аспекта системы, который вы хотите прояснить:
Структура системы: Используйте диаграммы классов (логическая структура)
и диаграммы компонентов (физическая структура).
Поведение системы: Используйте диаграммы вариантов использования
(функциональность с точки зрения пользователя) и диаграммы деятельности
(бизнес-процессы и алгоритмы).
Взаимодействие объектов: Используйте диаграммы последовательности
(временной порядок вызовов методов, акцент на времени) и диаграммы
коммуникации (структура взаимодействия между объектами, акцент на связях).
Изменение состояния объекта: Используйте диаграммы состояний для
моделирования жизненного цикла объектов с сложным поведением (например,
заказ в интернет-магазине: Создан -> Оплачен -> Доставляется -> Выполнен).
4.	Соблюдайте принцип итеративности и инкрементальности.
Не пытайтесь создать полную и идеальную модель системы перед началом
программирования. Это подход "водопада", который плохо работает в
современных условиях. Вместо этого:
a.	Начните с эскизов (UML как черновик). Набросайте ключевые классы
или сценарии взаимодействия на доске или в инструменте.
b.	Уточняйте и детализируйте модели по мере развития проекта.
c.	Будьте готовы изменять диаграммы, когда код эволюционирует.
Модель должна быть живым документом, а не реликвией начального
этапа.
5.	Синхронизируйте модель и код.
Одна из самых больших проблем — расхождение между UML-моделями и
реальным кодом. Чтобы этого избежать:
a.	Используйте инструменты с возможностью обратного проектирования
(Reverse Engineering), которые могут автоматически генерировать
диаграммы классов из исходного кода.
b.	Рассматривайте диаграммы как абстрактное представление кода,
которое не обязано быть точным до каждого поля, но должно отражать
ключевые архитектурные решения.
c.	Включайте в модель только наиболее важные, структурные или
сложные элементы, опуская очевидные детали.
6.	Сосредоточьтесь на ясности, а не на строгости нотации.
153

Строгое следование стандарту UML менее важно, чем понятность диаграммы
для вашей команды.
Используйте стереотипы («interface», «controller», «entity») для
добавления семантики, понятной вашей команде.
При необходимости добавляйте краткие комментарии (Note) для объяснения
неочевидных решений.
Избегайте "спагетти-диаграмм" с большим количеством перекрещивающихся
связей. Если диаграмма становится слишком сложной, разбейте ее на несколько
более простых.
UML — это язык общения, а не формальный стандарт для проверки. Его сила
— в способности донести сложные идеи до разных участников проекта.
Эффективное применение UML требует прагматичного подхода: выбора нужного
инструмента (диаграммы) для конкретной задачи, адаптации уровня детализации
под аудиторию и поддержания моделей в актуальном состоянии. Помните, что
лучшая диаграмма — это та, которая устранила недопонимание и помогла
двигаться дальше.
154

СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ
1.	Ларина Ю.А. Основы объектно-ориентированного моделирования с
использованием языка UML / Ярославль: ЯрГУ. 2010. - 151 с.
2.	Новиков Ф.А. Учебно-методическое пособие по дисциплине «Анализ и
проектирование на UML» / СПб: ИТМО. 2007. - 286 с.
3.	Фаулер М. UML. Основы. 3-е издание. - Пер. с англ. / СПб: Символ-Плюс,
2004. - 192 с.
4.	Использование диаграммы вариантов использования UML при
проектировании программного обеспечения [Электронный ресурс]. - Режим
доступа:	URL:https://habr.com/m/artides/566218/,	свободный (дата
обращения: 10.11.2025).
5.	Каюмова А.В. Визуальное моделирование в StarUML / Казань: КФУ. 2013. -
104 с.
6.	Использование диаграммы классов UML при проектировании и
документировании программного обеспечения [Электронный ресурс]. -
Режим доступа: URL:https://habr.com/ru/articles/572234/, свободный (дата
обращения: 10.11.2025).
7.	Буч. Г., Рамбо Дж. Язык UML: руководство пользователя / М.: ДМК. 2000. -
494 с.
8.	Ларман К. Применение UML и шаблонов проетирования.2-е издание / М.
Изд.дом «Вильямс». 2004. -624 с.
9.	Арлоу Д., Нейштадт И. UML 2 и унифицированный процесс. Практический
объектно-ориентированный анализ и проектирование, 2-е издание /
СПб:Символ Плюс. 2007. - 624 с.
10.	Рамбо Дж., Блаха М. UML 2.0: объектно-ориентированное моделирование и
разработка / СПб: Питер. 2007. - 544 с.
155

ПРИЛОЖЕНИЕ 1
ПРОЕКТНОЕ ЗАДАНИЕ
Освоить практические навыки проектирования информационных систем с
использованием нотации UML на платформе StarUML через создание комплекта
диаграмм для предметной области в сфере строительства.
Задачи:
1.	Изучить принципы моделирования в нотации UML.
2.	Освоить работу с инструментом StarUML.
3.	Разработать комплект UML-диаграмм для выбранной темы.
4.	Сформировать навыки анализа предметной области и
проектирования архитектуры ИС.
Общие требования к выполнению работ
1.	Состав:
1.1.	Комплект из 11-12 UML-диаграмм различных типов.
1.2.	Текстовая документация ко всем элементам моделей.
1.3.	Проект в формате StarUML (.mdj).
1.4.	Экспортированные диаграммы в формате PDF/PNG.
1.5.	Пояснительная записка
2.	Обязательные типы диаграмм:
2.1.	Диаграмма прецедентов - 2-3 уровня детализации.
2.2.	Диаграмма классов.
2.3.	Диаграмма последовательности.
2.4.	Диаграмма деятельности.
2.5.	Диаграмма состояний.
2.6.	Диаграмма коопераций.
2.7.	Диаграмма объектов.
2.8.	Диаграмма компонентов.
2.9.	Диаграмма развертывания.
3.	Требования к оформлению:
3.1.	Соответствие нотации UML 2.x
3.2.	Наличие поясняющих комментариев и документации
3.3.	Логичная структура проекта в StarUML
3.4.	Читаемость и эстетика диаграмм
3.5.	Единый стиль оформления
Каждая тема сформулирована как предметная область, в рамках которой
студент должен самостоятельно спроектировать конкретную информационную
систему по своему выбору. Это позволяет развить навыки анализа и
проектирования в условиях неоднозначности требований.
156

Темы для самостоятельной разработки UML-диаграмм
1.	Система управления проектами в строительстве (на примере PlanRadar).
2.	Система учета сотрудников строительной организации (на примере Битрикс24).
3.	Система управления арендой торговых площадей.
4.	Система информационного моделирования зданий (BIM) для проектирования
жилого дома.
5.	Система контроля качества строительных работ.
6.	Система управления строительными материалами и складским учетом.
7.	Система планирования и бюджетирования строительных проектов.
8.	Система мониторинга безопасности на строительной площадке.
9.	Система учета и контроля затрат на строительные работы.
10.	Система управления договорами подряда в строительстве.
11.	Система управления запасами строительных материалов.
12.	Система управления техническим надзором на строительных объектах.
13.	Система мониторинга энергопотребления зданий.
14.	Система анализа рисков на строительных объектах.
15.	Система автоматизированного проектирования (CAD).
16.	Система экологического контроля на строительной площадке.
17.	Система учета и контроля материалов на строительной площадке.
18.	Система управления транспортом и логистикой на строительной площадке.
19.	Система мониторинга состояния бетонных конструкций (на примере
PropTech.SMC).
20.	Система управления документацией в строительстве.
21.	Система учета рабочего времени строителей.
22.	Система управления взаимодействием с заказчиками (CRM для строительства).
23.	Система контроля соблюдения строительных норм и правил (СНиП, СП).
24.	Система управления техническим состоянием зданий на этапе эксплуатации.
25.	Система учета и технического обслуживания строительной техники.
26.	Система управления взаимодействием подразделений строительной компании.
27.	Система анализа больших данных в строительстве.
28.	Система прогнозирования цен на строительные материалы.
29.	Система управления проектно-сметной документацией.
30.	Система мониторинга геодезических данных на строительной площадке.
31.	Система управления производственным процессом на строительной площадке.
32.	Система мониторинга состояния строительных объектов в реальном времени.
33.	Система управления проектами с использованием Agile-методологий.
34.	Система учета и контроля строительных материалов (на примере
1С:Управление строительством).
35.	Система управления качеством на строительных объектах.
36.	Система мониторинга строительных работ с использованием БПЛА (дронов).
37.	Система автоматизированного проектирования (на примере AutoCAD).
38.	Система учета рабочего времени сотрудников на стройке.
39.	Система управления арендой строительного оборудования.
40.	Система управления взаимодействием с субподрядчиками.
157

41.	Система планирования и контроля бюджета строительного проекта.
42.	Система управления рисками на строительных площадках.
43.	Система учета затрат на строительные материалы (ТСМ).
44.	Система контроля соблюдения норм охраны труда и техники безопасности.
45.	Система управления техническим обслуживанием оборудования.
46.	Система мониторинга потребления ресурсов (вода, электроэнергия) на стройке.
47.	Система управления проектной документацией (на примере DocuWare).
48.	Система анализа данных по строительным проектам.
49.	Система управления закупками строительных материалов.
50.	Система мониторинга состояния бетонных конструкций.
51.	Система управления персоналом на строительной площадке (на примере SAP
SuccessFactors).
52.	Система учета и контроля финансовых потоков строительной компании.
53.	Система управления экологическими рисками на стройке.
54.	Система автоматизации документооборота в строительстве.
55.	Система управления проектами по методологии Scrum.
56.	Система мониторинга состояния строительной техники.
57.	Система управления качеством выполнения строительно-монтажных работ.
58.	Система учета и контроля проектных затрат.
59.	Система управления электронной строительной документацией.
60.	Система учета и анализа производительности труда на стройке.
61.	Система контроля выполнения обязательств по контрактам.
62.	Система управления взаимодействием с клиентами (CRM).
63.	Система управления жизненным циклом строительного объекта (PLM).
64.	Система автоматизации процессов управления проектами.
65.	Система мониторинга соблюдения строительных норм.
66.	Система управления арендой офисных помещений.
67.	Система контроля качества строительных материалов.
68.	Система анализа рыночных тенденций в строительстве.
69.	Система учета и контроля эксплуатационных расходов зданий.
70.	Система управления проектами в условиях неопределенности.
71.	Система автоматизации процессов планирования строительных работ.
72.	Система учета и анализа финансовых рисков в строительстве.
73.	Система управления охраной труда и техникой безопасности.
74.	Система контроля соблюдения экологических норм на стройке.
75.	Система управления проектами по принципам Бережливого строительства
(Lean Construction).
76.	Система мониторинга качества работ подрядчиков.
77.	Система управления цепочками поставок (SCM) в строительстве.
78.	Система учета и контроля строительных машин и механизмов.
79.	Система управления проектами на основе анализа данных.
80.	Система управления конфликтами и претензиями в строительстве.
158

Электронное учебное издание
Галимов Руслан Атласович
Ахмадиев Файл Габдулбарович
МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ
В STARUML:
ТЕОРИЯ И ПРАКТИКА UML
Выпускающий редактор Г. А. Письменная
Выполнено с готового оригинал-макета
Подписано к использованию 09.12.2024.
Усл. печ. л. 18,2. Заказ 2380.
Издательство «Бук». 420029, г. Казань, ул. Академика Кирпичникова, д. 25.

БУК
ИЗДАТЕЛЬСТВО
www.bukbook.ru
ISBN 978-5-00254-206-2
9
785002
542062