SVM Strukturnye Diagrammy 14

Казанский государственный университет
И.Н. Исмагилов, Л.Н. Исмагилов, Н.А. Исмагилов
СРЕДСТВА ВИЗУАЛЬНОГО МОДЕЛИРОВАНИЯ

ПРОГРАММНЫХ СИСТЕМ.
ЯЗЫК UML (UNIFIED MODELING LANGUAGE)
СПЕЦИФИКАЦИИ 2.0
СТРУКТУРНЫЕ ДИАГРАММЫ
Казань
2007
УДК 004.43
ББК 32.973 - 018.1
И 87
Печатается по постановлению
Редакционно-издательского совета
факультета ВМК
Казанского государственного университета
Рецензенты:
Доктор физико-математических наук, профессор кафедры
Теоретической кибернетики КГУ, чл.-корр. АН РТ Ф.М. Аблаев
Кандидат технических наук, доцент кафедры Компьютерных систем
КГТУ им. А.Н. Туполева (КАИ) С.В. Шалагин
Исмагилов И.Н., Исмагилов Л.Н., Исмагилов Н.А.

И 87 Средства визуального моделирования программных систем. Язык UML
(Unified Modeling Language) спецификации 2.0. Структурные
диаграммы. Учебное пособие. – Казань: Казанский государственный
университет. – 2007. 138 с.
В настоящем пособии описывается унифицированный язык

моделирования UML спецификации 2.0, рассматриваются основные элементы
структурных диаграмм языка UML, приведены примеры использования
элементов данных диаграмм.
Данное пособие может быть полезным студентам, интересующимся
средствами визуального моделирования, принципами построения моделей
программных систем с применением языка UML.
УДК 004.43
ББК 32.973 - 018.1
© Казанский государственный университет

© Исмагилов И.Н., Исмагилов Л.Н., Исмагилов Н.А.
ОГЛАВЛЕНИЕ
Введение . . . . . . . . . . . 5
Часть 1. Методические основы технологий создания
программных систем . . . . . . . 9
1. Модель программной системы . . . . . 9
2. Объектно-ориентированная разработка. . . . 10
3. Объектно-ориентированная методология . . . 11
4. Три модели . . . . . . . . . 14
5. Концептуальная модель унифицированного языка
моделирования UML . . . . . . . 17
6. Диаграммы языка UML . . . . . . 28
7. Правила языка UML . . . . . . . 31
Часть 2. Структурные диаграммы унифицированного языка

моделирования UML . . . . . . 43
8. Диаграммы классов и объектов . . . . . 43
8.1. Моделирование классов. . . . . . 43
8.2. Отношения между классами и их графическое
изображение на диаграмме классов. . . . . 75
8.3. Диаграммы классов и объектов . . . . 101
9. Диаграмма композитной структуры . . . . 109
10. Пакеты . . . . . . . . 113
11. Представление проектирования. Компоненты . . 119
12. Представление развертывания . . . . . 129
Заключение . . . . . . . . . . 135
Литература . . . . . . . . . . 137
«Иногда мы обнаруживаем неприятные
истины. И когда это происходит,
попадаем в затруднительное положение,
поскольку утаить их – научная
нечестность, сказать же правду – значит
вызвать огонь на себя. Если эти истины
достаточно неприемлемы, то ваши
слушатели психологически неспособны
принять их, и вы будете ославлены как
абсолютно лишенный здравого смысла,
опасно революционный, глупый,
коварный или какой-то еще там человек.
(Не говоря уже о том, что, настаивая на
таких истинах, вы обеспечите себе
непопулярность во многих кругах и
вообще не обойдетесь без персонального
риска. Вспомните Галилео Галилея...)»
«Программирование – одна из наиболее

трудных отраслей прикладной
математики: слабым (poor) математикам
лучше оставаться чистыми (pure)
математиками»
Эдстер Вайб Дейкстра (Edsger Wibe

Dijkstra, 30.V.1930 - 06.VIII.2002) –
профессор технологического
университета, Эйндховен, Нидерланды –
один из тех людей, с именем которых
связано превращение программирования
из шаманства в науку.
Введение
Информатика как учебная дисциплина прочно завоевала место

в базовом образовании. При этом обучение непосредственно
программированию является неотъемлемой частью предмета.
Целью обучения программированию на начальных этапах является
не только и не столько преподавание ремесла написания
программных кодов, сколько привитие методологических и
технологических подходов и навыков, воспитание
соответствующего способа думать, ставить и решать задачу. Такой
подход к обучению позволяет сформировать думающего
исследователя, способного как к прикладному программированию,
так и к занятиям Computer Science.
Однако многие курсы сегодня направлены на решение частных
программистских задач в рамках конкретной среды реализации.
При этом используемые концепции разработки зачастую теряются
за особенностями применения данной среды программирования.
Альтернативный подход заключается в использовании
специализированных языков спецификаций, предназначенных для
разработки и описания программных систем на уровне концепций, а
не в терминах кодов. Такие языки обычно более наглядны, лучше
усваиваются, т.к. позволяют из готового набора диаграмм строить,
как из кубиков, программную систему.
В качестве языка описания концепций объектно-
ориентированного проектирования предлагается UML – Unified
Modelling Language, предложенный Grady Booch, Jim Rumbaugh и
Ivar Jacobson.
UML – это готовый мощный язык моделирования, в который
прямо включены современные концепции объектно-
ориентированного подхода. Он имеет механизмы расширения
выразительных возможностей как для нестандартных ситуаций, так
и для специализации средств моделирования для конкретных
6 Введение
предметных областей, обеспечивает интероперабельность для

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

бизнес-требований к системе.
В пособии рассмотрены общие принципы, лежащие в основе
унифицированного языка моделирования (UML), включая суть и
цели моделирования. Даны определения понятий модель, объектно-
ориентированная разработка, описаны этапы объектно-
ориентированной разработки, рассмотрена концептуальная модель
и правила языка UML.
Также в пособии представлено описание нотации структурных
диаграмм языка UML. Данный тип диаграмм описывает элементы
модели без учета временных аспектов. Он содержит диаграммы
классов, композитные структурные диаграммы, объектные
диаграммы, диаграммы пакетов, диаграммы компонентов и
диаграммы развертывания.
Любая модель должна определять полное множество объектов,
то есть ключевые концепции приложения, их внутренние свойства и
отношения между собой. Эта структура описывается в статическом
представлении системы. Концепции системы моделируются как
классы, каждый из которых описывает тип объектов, содержащих
определенную информацию и взаимодействующих между собой
для реализации некоторого поведения. Статическое представление
системы изображается с помощью диаграмм классов.
Диаграммы объектов показывают часть объектов системы и
связи между ними в некотором конкретном состоянии или
суммарно, в некоторый момент времени.
Модели UML создаются и для проектирования,
обеспечивающего реализацию системы. Диаграммы компонентной
структуры раскрывает реализацию класса в виде набора частей,
скрепленных между собой соединителями. Класс может
инкапсулировать свою внутреннюю структуру за внешне видимыми
портами. Компонент – это замещающая часть системы, которая
соответствует некоторому набору интерфейсов и обеспечивает их
реализацию.
8 Введение
Диаграммы компонентов представляют компоненты.

Компоненты сборки и конфигурационного управления обычно
представляют собой файлы с исходным кодом, динамически
подгружаемые библиотеки, HTML-странички и пр., компоненты
развертывания – это компоненты JavaBeans, CORBA, COM и т.д.
Представление развертывания описывает физическое
размещение узлов. Узел – это вычислительный ресурс, который
имеет, по меньшей мере, память и процессор и определяет
местонахождение исполняемых компонентов и объектов.
Диаграммы развертывания показывают декомпозицию системы на
физические устройства различных видов – серверы, рабочие
станции, терминалы, принтеры и т. д. – и связи между ними,
представленные различного рода соединениями.
При работе с большими системами вся информация о модели
должна быть поделена на связанные понятные части, чтобы
команды разработчиков могли параллельно работать над
различными разделами системы. Пакетами в языке UML
называются иерархически организованные блоки моделей.
В заключении представлены список сайтов и литература,
которые являются источниками информации по языку UML.
Часть 1
Методические основы
технологий создания программных систем
1. Модель программной системы
Под моделью программной системы (ПС) в общем случае

понимается формализованное описание программной системы на
определенном уровне абстракции. Формализация ПС происходит с
использованием текстового и графического описания ее аспектов.
Полная модель ПС определяется как некоторое множество моделей,
отражающие различные представления о программной системе,
включающие статические, структурные и динамические
представления.
Каждая модель определяет конкретный аспект системы,
использует набор диаграмм и документов заданного формата, а
также отражает точку зрения и является объектом деятельности
различных людей с конкретными интересами, ролями или задачами.
Графические (визуальные) модели представляют собой
средства для визуализации, описания, проектирования и
документирования архитектуры системы. Разработка модели ПС
промышленного характера в такой же мере необходима, как и
наличие проекта при строительстве большого здания. Это
утверждение справедливо как в случае разработки новой системы,
так и при адаптации типовых продуктов класса систем управления
ресурсами предприятий типа SAP R/3 или BAAN, в составе которых
так же имеются собственные средства моделирования. Хорошие
модели являются основой взаимодействия участников проекта и
гарантируют корректность архитектуры. Поскольку сложность
10
систем повышается, важно располагать хорошими методами

моделирования. Хотя имеется много других факторов, от которых
зависит успех проекта, но наличие строгого стандарта языка
моделирования является весьма существенным.
Состав моделей, используемых в каждом конкретном проекте,
и степень их детальности в общем случае зависят от следующих
факторов:
1) сложности проектируемой системы;
2) необходимой полноты ее описания;
3) знаний и навыков участников проекта;
4) времени, отведенного на проектирование.
Визуальное моделирование оказало большое влияние на
развитие технологий создания программных систем вообще и CASE
(Computer Aided Software Engineering – системы
автоматизированной разработки программных систем) средств, в
частности.
CASE методология представляет собой систему принципов и
совокупность методов проектирования ПС, а так же набор
инструментальных средств, позволяющих в наглядной форме
моделировать предметную область, анализировать эту модель на
всех стадиях разработки и сопровождения ПС и разрабатывать
приложения в соответствии с информационными потребностями
пользователей. Большинство существующих CASE средств
основано на методах структурного или объектно-ориентированного
анализа и проектирования, использующих спецификации в виде
диаграмм или текстов для описания внешних требований, связей
между моделями системы, динамики поведения системы и
архитектуры программных средств.
2. Объектно-ориентированная разработка
1. Модель программной системы 11
Объектно-ориентированная разработка программного

обеспечения представляет собой способ мышления, основанный на
абстракциях, существующих как в реальном мире, так и в
программах. В этом контексте разработка (development) обозначает
жизненный цикл программного обеспечения: анализ, проектирование
и реализацию. Целью объектно-ориентированной разработки
является идентификация и упорядочение концепций приложения, а
не окончательная реализация на языке программирования. Наиболее
сложной частью разработки программного обеспечения является
работа с его сущностью (essence), а не акциденцией (accidents)
отображения этой сущности в конкретный язык программирования.
Объектно-ориентированная разработка – это
концептуальный процесс, независимый от языка программирования,
по крайней мере, до последних этапов. Фактически это образ
мышления, а не методика программирования. Главное преимущество
объектной ориентированности состоит в том, что она помогает тем, кто
пишет спецификации, разработчикам и заказчикам ясно выражать
абстрактные концепции и обсуждать их друг с другом. Таким
образом, облегчается составление спецификаций, анализ,
документирование и определение интерфейсов и, конечно же,
программирование.
3. Объектно-ориентированная методология
Процесс объектно-ориентированной разработки и системы

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

обеспечения начинается с бизнес-аналитиков или пользователей,
которые придумывают приложение и формулируют первичные
требования к нему.
2 этап. Анализ. Аналитик исследует и переформулирует
требования, конструируя модели, исходя из концепций системы.
Аналитик должен работать с заказчиком, чтобы добиться понимания
задачи, потому что формулировки редко оказываются полными или
корректными. Аналитическая модель – это сжатая и точная
абстракция того, что именно должна делать система (а не то, каким
образом это будет сделано). Аналитическая модель не должна
содержать никаких решений относительно реализации. Например,
класс Window в аналитической модели системы управления окнами
для рабочей станции должен быть описан в терминах видимых
атрибутов и операций.
Аналитическая модель состоит из двух частей: модели
предметной области (domain model) – описания объектов
реального мира, отражаемых системой, и модели приложения
(application model) – описания видимых пользователю частей самого
приложения. Например, для приложения по системе начисления
зарплаты объектами предметной области могут быть структура
организации, информация о сотрудниках, подразделениях, система
оплаты, ведомости по зарплате, налогообложение, иждивенцы,
сроки и периодичность начисления и т.п. Объекты модели
приложения могут управлять начислением заработанной платы за
определенный период и отображать результаты. Хорошая модель
должна быть доступной для понимания и критики со стороны
экспертов, не являющихся программистами.
3 этап. Проектирование системы. Команда разработчиков
продумывает стратегию решения задачи на высшем уровне,
определяя архитектуру системы (system architecture). На этом этапе
определяются политики, которые послужат основой для принятия
решений на следующих этапах проектирования. Проектировщик
системы должен выбрать параметры системы, по которым будет

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

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

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

(аналитическая модель, проектная модель, модель реализации).
Модель классов (class model) описывает статическую структуру
объектов системы: их индивидуальность, отношения с другими
объектами, атрибуты и операции. Эта модель определяет контекст
разработки программы, то есть предметную область, создает
контекст для моделей состояний и взаимодействия. Изменения и
взаимодействия не имеют смысла, если отсутствует изменяющийся
объект или взаимодействующие объекты. Объекты (objects) – это
блоки, на которые «разбивается» наш мир, молекулы нашей модели.
Цель конструирования модели классов состоит в том, чтобы
охватить те реальные концепции, которые важны для нашего
приложения. При моделировании инженерной задачи модель классов
должна содержать термины, знакомые инженерам.
При моделировании бизнес-задачи должны использоваться
термины из бизнеса. Модель пользовательского интерфейса должна
быть выражена в терминах приложения. Аналитическая модель не
должна содержать компьютерных конструкций, если только
моделируемое приложение не является чисто компьютерным, как,
например, компилятор или операционная система. Проектная модель
описывает возможности решения задачи, а потому может содержать
компьютерные конструкции.
Модель классов изображается на диаграммах классов.
Диаграмма классов – это граф, вершинами которого являются
классы, а ребрами – их отношения.
Обобщение позволяет классам использовать общую структуру
и поведение, а связи между классами осуществляются при помощи
ассоциаций. Классы определяют значения атрибутов для каждого
объекта и операции, которые выполняются самими объектами или с
их участием.
Модель состояний (state model) описывает аспекты объектов,
связанные с течением времени и с последовательностью операций,
то есть события, связанные с изменениями, состояния,
16
определяющие контекст событий, и упорядочение событий и

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

как это происходит.
Каждая модель описывает свои аспекты системы, но при этом
она ссылается на другие модели. Модель классов описывает
структуры данных, которыми оперируют модели состояний и
взаимодействия. Операции в модели классов связаны с событиями и
действиями. Модель состояний описывает структуру управления
объектов. Она показывает решения, зависящие от значений объектов,
и действия, изменяющие значения объектов и состояния. Модель
взаимодействия подчеркивает обмен между объектами и дает единый
обзор операций в рамках системы. Иногда возникают
неоднозначности, касающиеся того, к какой модели должна быть
отнесена некоторая информация. Это естественно, поскольку любая
абстракция является лишь грубым срезом реальности. Что-нибудь
неизбежно окажется на границе этого среза. Некоторые свойства
системы могут быть плохо отражены в трех моделях. Это тоже
нормально, потому что никакая абстракция не может быть
совершенной. Цель состоит в том, чтобы упростить описание
системы и избежать перегрузки модели большим количеством
конструкций, из-за чего она стала бы бесполезной. Если какие-то
детали плохо отражаются в моделях, для них можно использовать
естественные языки или систему обозначений, предназначенную
специально для данного приложения.
5. Концептуальная модель унифицированного языка

моделирования UML (Unified Modeling Language)
Концептуальной основой объектно-ориентированного анализа

и проектирования ПС (ООАП) является объектная модель. Ее
основными принципами являются абстрагирование, инкапсуляция,
модульность и иерархия, а также и понятия: объект, класс, атрибут,
операция, интерфейс и др.
18
Большинство современных методов ООАП основаны на

использовании языка UML. Унифицированный язык моделирования
UML (Unified Modeling Language) представляет собой язык для
определения, представления, проектирования и документирования
программных систем, организационно-экономических систем,
технических систем и других систем различной природы. UML
содержит стандартный набор диаграмм и нотаций самых
разнообразных видов.
UML – это преемник методов ООАП, которые появились в
конце 1980-х и начале 1990-х годов. Создание UML фактически
началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали
работу по объединению разработанных методов Booch и OMT
(Object Modeling Technique) под эгидой компании Rational Software.
К концу 1995 г. они создали первую спецификацию объединенного
метода, названного ими Unified Method, версия 0.8. Тогда же в 1995
г. к ним присоединился создатель метода OOSE (Object Oriented
Software Engineering) Ивар Якобсон. Таким образом, UML является
прямым объединением и унификацией методов Буча, Рамбо и
Якобсона, однако дополняет их новыми возможностями.
В настоящее время используется версия языка UML
спецификации 2.0 (UML 2.0), которая была принята OMG (Object
Management Group – организация по стандартизации в области
объектно-ориентированных методов и технологий) в 2004 году в
качестве стандартного языка моделирования. Язык UML получил
широкую поддержку в индустрии производства программных
систем.
Главными целями при разработке UML были следующие:
 предоставить пользователям готовый к использованию
выразительный язык визуального моделирования, позволяющий им
разрабатывать осмысленные модели и обмениваться ими;
 предусмотреть механизмы расширяемости и специализации
для расширения базовых концепций;
 обеспечить независимость от конкретных языков

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

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

атрибутами, операциями, отношениями и семантикой. Класс
реализует один или несколько интерфейсов. Графически класс
изображается в виде прямоугольника, в котором обычно записаны
его имя, атрибуты и операции, как показано на рис. 5.1.
Рис. 5.1 Класс
Интерфейс (Interface) – это совокупность операций, которые

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

ограниченного пунктирной линией, в который обычно заключено
только имя, как показано на рис. 5.3.
Рис. 5.3 Кооперация
Прецедент, вариант использования (Use case) – это описание

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

22
Три другие сущности – активные классы, компоненты и узлы –

подобны классам: они описывают совокупности объектов с общими
атрибутами, операциями, отношениями и семантикой.
Активным классом (Active class) называется класс, объекты
которого вовлечены в один или несколько процессов, или нитей
(Threads), и поэтому могут инициировать управляющее
воздействие. Активный класс во всем подобен обычному классу, за
исключением того, что его объекты представляют собой элементы,
деятельность которых осуществляется одновременно с
деятельностью других элементов. Графически активный класс
изображается так же, как простой класс, но ограничивающий
прямоугольник рисуется жирной линией и обычно включает имя,
атрибуты и операции, как показано на рис. 5.5.
Рис. 5.5 Активный класс
Два оставшихся элемента – компоненты и узлы – также имеют

свои особенности. Они соответствуют физическим сущностям
системы, в то время как пять предыдущих – концептуальным и
логическим сущностям.
Компонент (Component) – это физическая заменяемая часть
системы, которая соответствует некоторому набору интерфейсов и
обеспечивает его реализацию.
В системе можно встретить различные виды устанавливаемых
компонентов, такие как СОМ+ или Java Beans, а также компоненты,
являющиеся артефактами процесса разработки, например файлы
исходного кода. Компонент, как правило, представляет собой
физическую упаковку логических элементов, таких как классы,

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

мигрировать с одного узла на другой. Графически узел
изображается в виде куба, обычно содержащего только имя, как
показано на рис. 5.7.
Рис. 5.7 Узлы
Эти семь базовых элементов – классы, интерфейсы,

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

файлы, библиотеки, страницы и таблицы (виды компонентов).
Поведенческие сущности (Behavioral things) являются
динамическими составляющими модели UML. Это глаголы языка:
они описывают поведение модели во времени и пространстве.
Существует всего два основных типа поведенческих сущностей.
Взаимодействие (Interaction) – это поведение, суть которого
заключается в обмене сообщениями (Messages) между объектами в
рамках конкретного контекста для достижения определенной цели.
С помощью взаимодействия можно описать как отдельную
операцию, так и поведение совокупности объектов. Взаимодействие
предполагает ряд других элементов, таких как сообщения,
последовательности действий (поведение, инициированное
сообщением) и связи (между объектами). Графически сообщения
изображаются в виде стрелки, над которой почти всегда пишется
имя соответствующей операции, как показано на рис. 5.8.
Рис. 5.8 Сообщения
Автомат (State machine) – это алгоритм поведения,

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

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

которых можно организовать модель UML. Существуют также
26
вариации пакетов, например каркасы (Frameworks), модели и

подсистемы.
Аннотационные сущности – пояснительные части модели
UML. Это комментарии для дополнительного описания,
разъяснения или замечания к любому элементу модели. Имеется
только один базовый тип аннотационных элементов – примечание
(Note). Примечание – это просто символ для изображения
комментариев или ограничений, присоединенных к элементу или
группе элементов. Графически примечание изображается в виде
прямоугольника с загнутым краем, содержащим текстовый или
графический комментарий, как показано на рис. 5.11.
Рис. 5.11 Примечание
Этот элемент является основной аннотационной сущностью,

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

строительными блоками в UML и применяются для создания
корректных моделей.
Зависимость (Dependency) – это семантическое отношение
между двумя сущностями, при котором изменение одной из них,
независимой, может повлиять на семантику другой, зависимой.
Графически зависимость изображается в виде прямой пунктирной
линии, часто со стрелкой, которая может содержать метку
(рис. 5.12).
Рис. 5.12 Зависимости
Ассоциация (association) – структурное отношение,

описывающее совокупность связей; связь – это соединение между
объектами. Разновидностью ассоциации является агрегирование
(aggregation) – так называют структурное отношение между целым
и его частями. Графически ассоциация изображается в виде прямой
линии (иногда завершающейся стрелкой или содержащей метку),
рядом с которой могут присутствовать дополнительные
обозначения, например кратность и имена ролей. На рис. 5.13
показан пример отношений этого типа.
Рис. 5.13 Ассоциации
Обобщение (Generalization) – это отношение «специализация /

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

стрелкой, указывающей на родителя, как показано на рис. 5.14.
Наконец, реализация (Realization) – это семантическое
отношение между классификаторами, при котором один
классификатор определяет «контракт», а другой гарантирует его
выполнение.
Рис. 5.14 Обобщения
Отношения реализации встречаются в двух случаях: во-

первых, между интерфейсами и реализующими их классами или
компонентами, а во-вторых, между прецедентами и реализующими
их кооперациями. Отношение реализации изображается в виде
пунктирной линии с не закрашенной стрелкой, как нечто среднее
между отношениями обобщения и зависимости (рис. 5.15).
Четыре описанных элемента являются основными типами
отношений, которые можно включать в модели UML. Существуют
также их вариации, например уточнение (Refinement), трассировка
(Trace), включение и расширение (для зависимостей).
Рис. 5.15 Реализации
Классификатор (classifier) – элемент модели, описывающий

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

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

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

Структурные диаграммы (structural diagrams). Данный тип
диаграмм описывает элементы модели без учета временных
аспектов. Он содержит диаграммы классов, композитные
структурные диаграммы, диаграммы компонентов, диаграммы
развертывания, объектные диаграммы и диаграммы пакетов.
30
Поведенческие диаграммы (behavioral diagrams). Данный

тип диаграмм описывает поведенческие особенности системы или
бизнес-процессов. Он включает в себя диаграммы деятельности,
состояний и вариантов использования. Также данный тип диаграмм
включает в себя четыре диаграммы взаимодействия.
Диаграммы взаимодействия (interaction diagrams). Данный
тип диаграмм является подмножеством поведенческих диаграмм,
который придает значение взаимодействию объектов. Он включает
в себя диаграммы коммуникации, обзорные диаграммы
взаимодействия, диаграммы последовательности и временные
диаграммы.
Таблица 1 содержит информацию обо всех 13 диаграммах.
Таблица 1
Название диаграммы Описание
Структурные диаграммы (structural diagrams)
Классов Показывает совокупность статических элементов
(class diagram) модели, таких как классы с атрибутами и
операциями, а также связывающие их отношения
Объектов Описывает объекты и их отношения в
(object diagram) определенный момент времени.
Пакетов Диаграмма показывает, каким образом, возможно,
(package diagram) организовать элементы модели в группы. Также
демонстрируются зависимости между группами.
Компонентов Описывает компоненты, из которых состоит
(component diagram) приложение, система или предприятие.
Описываются компоненты, их взаимоотношения,
взаимосвязи.
Композитной структуры Описывает внутреннюю структуру
(composite structure классификатора (таких как класс, компонент и
diagram) вариантов использования).
Развертывания Диаграмма, на которой представлены узлы
(топологии) выполнения программных компонентов реального
(deployment diagram) времени, а также процессов и объектов.
Показывает наличие физических соединений –
маршрутов передачи информации между
аппаратными устройствами, задействованными в
реализации системы.
Поведенческие диаграммы (behavioral diagrams)

Деятельности Диаграмма описывает бизнес-процессы высокого
(activity diagram) уровня, включающие в себя поток данных, или
моделирует логику сложных процессов внутри
системы.
Вариантов использования Диаграмма, на которой изображаются отношения
(прецедентов) между действующими лицами (actors) и
(use case diagram) вариантами использования (use cases).
Конечных автоматов Используется для моделирования всех возможных
(состояний) изменений состояний конкретных объектов.
(state machine diagram)
Диаграммы взаимодействия (interaction diagrams)
Последовательности Диаграмма, на которой показаны взаимодействия
(sequence diagram) объектов, упорядоченные по времени их
проявления.
Коммуникации Диаграмма предназначена для описания поведения
(communication diagram) системы на уровне отдельных объектов, которые
обмениваются между собой сообщениями.
Диаграммы коммуникации обычно фокусируют
внимание на представление структурных связей
отдельных объектов между собой при обмене
между собой сообщениями. Раньше (в UML 1.5)
она называлась диаграммой сотрудничества
(collaboration diagram).
Обзора взаимодействия Разновидность диаграммы деятельности. Каждый
(interaction overview узел/деятельность внутри диаграммы может быть
diagram) представлен диаграммой взаимодействия.
Временная Описывает изменение состояния объекта во
(timing diagram) времени при его реакции на внешние события.
7. Правила языка UML
Строительные блоки UML нельзя произвольно объединять

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

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

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

или французском стиле. Тот же принцип применим и в отношении
UML. Работу с этим языком существенно облегчает
последовательное использование общих механизмов,
перечисленных ниже:
– спецификации (Specifications);
– дополнения (Adornments);
– принятые деления (Common divisions);
– механизмы расширения (Extensibility mechanisms).
UML – это не просто графический язык. За каждой частью его
системы графической нотации стоит спецификация, содержащая
текстовое представление синтаксиса и семантики соответствующего
строительного блока. Например, пиктограмме класса соответствует
спецификация, полностью описывающая его атрибуты, операции
(включая полные сигнатуры) и поведение, хотя визуально
пиктограмма порой отражает только малую часть этой
совокупности. Может существовать другое представление этого
класса, отражающее совершенно иные его аспекты, но, тем не
менее, соответствующее все той же спецификации. С помощью
графической нотации UML происходит визуализация системы, с
помощью спецификаций UML – описание ее деталей. Таким
образом, допустимо строить модель инкрементно, то есть
пошаговым образом – сначала нарисовать диаграмму, а потом
добавить семантику в спецификацию модели, или наоборот – начать
со спецификации (возможно, применив обратное проектирование к
существующей системе), а потом на ее основе создавать
диаграммы.
Спецификации UML создают семантический план, который
полностью включает в себя составные части всех моделей системы,
согласованные между собой. Таким образом, диаграммы UML
можно считать визуальными проекциями этого плана, при этом
каждая из них раскрывает один из значимых аспектов системы.
34
Почти каждый из элементов UML имеет соответствующее ему

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

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

Класс – это абстракция, объект – конкретная материализация этой
абстракции. В языке UML можно моделировать и классы, и
объекты, как показано на рис. 7.2.
Рис. 7.2. Классы и объекты

На этом рисунке показан один класс Customer (Клиент) и три
объекта: Jan:Customer (явно определенный как объект данного
класса), :Customer (анонимный объект класса Customer) и Elyse
(спецификация которого относит его к классу Customer, хотя это и
не выражено явно).
Практически все строительные блоки UML характеризуются
дихотомией «класс/объект». Так, имеются прецеденты и
экземпляры прецедентов, компоненты и экземпляры компонентов,
узлы и экземпляры узлов и т.д. В графическом представлении для
объекта принято использовать тот же символ, что и для его класса, а
название объекта подчеркивать.
Еще одним вариантом членения является деление на
интерфейс и его реализацию. Интерфейс декларирует контракт, а
реализация представляет конкретное воплощение этого контракта и
обязуется точно следовать объявленной семантике интерфейса.
UML позволяет моделировать обе эти категории, интерфейсы и их
реализации, как показано на рис. 7.3.: в данном случае один
компонент library.dll реализует два интерфейса interface1 и
interface2. Почти все строительные блоки UML характеризуются
36
дихотомией «интерфейс/реализация». Например, прецеденты

реализуются кооперациями, а операции – методами.
Рис. 7.3. Интерфейсы и реализации
Механизмы расширения. UML – это стандартный язык для

разработки «чертежей» программного обеспечения, но ни один
замкнутый язык не в состоянии охватить нюансы всех возможных
моделей в различных предметных областях. Поэтому UML является
открытым языком, то есть допускает контролируемые расширения.
Механизмы расширения UML включают:
– стереотипы;
– помеченные значения;
– ограничения.
Стереотип (Stereotype) расширяет словарь UML, позволяя на
основе существующих блоков языка создавать новые, специфичные
для решения конкретной проблемы. Например, работая с такими
языками программирования, как Java, С# или C++, часто
приходится моделировать исключения (Exceptions) - они являются
обыкновенными классами, хотя и рассматриваются особым
образом. Обычно требуется, чтобы исключения можно было
возбуждать и перехватывать, и ничего больше. Если пометить
исключения соответствующим стереотипом, то с ними можно будет
обращаться как с обычными строительными блоками языка; на рис.
7.4 это продемонстрировано на примере класса Overflow.
Рис. 7.4. Механизмы расширения
Помеченное значение (Tagged value) расширяет свойства

строительных блоков UML, позволяя включать новую информацию
в спецификацию элемента.
Скажем, если работаете над «коробочным» продуктом и
выпускаете много его версий, то зачастую необходимо отслеживать
версию и автора какой-нибудь важной абстракции. Ни версия, ни
автор не являются первичными концепциями UML, но их можно
добавить к любому блоку, такому, например, как класс, задавая для
него новые помеченные значения. На рис. 7.4 показано, как это
можно сделать, на примере класса EventQueue.
Ограничения (constraints) расширяют семантику строительных
блоков UML, позволяя определять новые или изменять
существующие правила. Вы можете, например, ограничить класс
EventQueue так, чтобы все события добавлялись в очередь по
порядку. На рис. 7.4 показано, как можно определить ограничение,
которое явно постулирует это правило для операции add.
Совместно эти три механизма расширения языка позволяют
модифицировать UML в соответствии с потребностями вашего
проекта. Кроме того, они дают возможность адаптировать UML к
новым технологиям разработки программного обеспечения,
например к вероятному появлению более мощных языков
распределенного программирования. С помощью механизмов
38
расширения можно создавать новые строительные блоки,

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

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

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

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

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

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

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

соответствующей системы.
Количество типов диаграмм для конкретной модели
приложения строго не фиксировано. Для простых приложений нет
необходимости строить все без исключения типы диаграмм.
Некоторые из них могут просто отсутствовать в проекте системы, и
это не будет считаться ошибкой разработчика. Например, модель
системы может не содержать диаграмму развертывания для
приложения, выполняемого локально на компьютере пользователя.
Важно понимать, что перечень диаграмм зависит от специфики
конкретного проекта системы.
Любая модель системы должна содержать только те элементы,
которые определены в нотации языка UML. Имеется в виду
требование начинать разработку проекта, используя только те
конструкции, которые уже определены в метамодели UML. Как
показывает практика, этих конструкций вполне достаточно для
представления большинства типовых проектов программных
систем. И только при отсутствии необходимых базовых элементов
языка UML следует использовать механизмы их расширения для
адекватного представления конкретной модели системы. Не
допускается переопределение семантики тех элементов, которые
отнесены к базовой нотации метамодели языка UML.
Часть 2
Структурные диаграммы
унифицированного языка моделирования UML
8. Диаграммы классов и объектов
8.1. Моделирование классов
Модель классов описывает статическую структуру системы:

объекты и отношения между ними, атрибуты и операции для
каждого класса объектов. В основе системы должны быть объекты, а
не требуемая функциональность. Объектно-ориентированная
система лучше соответствует реальному миру и оказывается более
жизнеспособной при возможных изменениях. Модели классов
являются интуитивным графическим представлением системы и
потому особенно полезны для общения с заказчиками.
Цель моделирования классов состоит в описании объектов. В
качестве примеров объектов можно привести следующие: Джо
Смит, компания Симплекс, процесс № 7648 и активное окно.
Объект (object) – это концепция, абстракция или сущность,
обладающая индивидуальностью и имеющая смысл в рамках
приложения. Объекты часто бывают именами собственными или
конкретными ссылками, которые используются в описании задач или
при общении с пользователями. Некоторые объекты существуют или
существовали в реальном мире (например, Альберт Эйнштейн или
компания General Electric), тогда как другие являются сугубо
концептуальными сущностями (например, тестовый прогон №
1234 или формула корней квадратного уравнения). Объекты
третьего типа (бинарное дерево 634 и массив, связанный с
переменной а) добавляются в модель в процессе реализации и не
44
имеют никакого отношения к физической реальности. Выбор

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

кормить лошадь, то эти две сущности будут отнесены к разным
классам. Интерпретация семантики зависит от назначения
конкретного приложения и является делом субъективным.
Каждый объект «знает» свой собственный класс. Большинство
объектно-ориентированных языков программирования позволяют
определять класс объекта во время выполнения программы. Класс
объекта – это его неявное свойство.
Если предметом моделирования являются объекты, то почему
вообще заходит речь о классах? Все дело в необходимости
абстрагирования. Группируя объекты в классы, производим
абстрагирование в рамках задачи. Именно благодаря абстракциям
моделирование оказывается столь мощным инструментом,
позволяющим проводить обобщения от нескольких конкретных
случаев к множеству подобных альтернатив. Общие определения
(такие как название класса и названия атрибутов) хранятся отдельно
для каждого класса, а не для каждого экземпляра.
Операции могут быть написаны один раз для целого класса,
благодаря чему все объекты класса получают возможность повторно
использовать написанный код. Например, все эллипсы имеют общие
процедуры прорисовки, вычисления площади и проверки на наличие
пересечения с некоторой прямой. У многоугольников будет свой
набор процедур. Даже в особых случаях (например, для окружностей и
квадратов) могут использоваться универсальные процедуры, хотя
специальные алгоритмы могут быть и эффективнее.
Классы
Класс (class) – абстрактное описание множества однородных
объектов, имеющих одинаковые характеристики, такие как,
атрибуты, операции и отношения с объектами других классов.
Класс является одной из основных конструкций языка UML.
Причинами этого являются следующие:
45
46
 Классы определяют основной словарь предметной области

моделируемой системы. Использование набора классов
существенно облегчает понимание о значениях терминов
предметной области.
 Классы могут служить основой для моделирования данных.
 Классы являются основой визуальных инструментов
моделирования – Rational Rose XDE, Embarcadero Describe, Sparx
Systems Enterprise Architect и других, которые производят
генерацию программного кода.
Графически класс в нотации языка UML изображается в виде
прямоугольника, который дополнительно может быть разделен
горизонтальными линиями на разделы или секции (рис. 8.1.1). В
этих секциях могут указываться имя класса, атрибуты и операции
класса.
Рис. 8.1.1. Варианты графического изображения класса на диаграмме классов
На начальных этапах разработки диаграммы отдельные классы

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

разработчике или языке реализации. Предполагается, что
окончательный вариант диаграммы содержит наиболее полное
описание классов, которые состоят из трех или четырех секций.
Даже если секции атрибутов и операций пусты, в обозначении
класса они должны быть выделены горизонтальной линией, с тем
чтобы отличить класс от других элементов языка UML. Примеры
графического изображения конкретных классов приведены на
рисунках 8.1.2, 8.1.3, 8.1.4.
Рис. 8.1.2. Примеры графического изображения конкретных классов
47
48
Рис.8.1.3. Примеры классов
Рис.8.1.4. Пример класса
Имя класса должно быть уникальным в пределах пакета,

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

имен классов использовать существительные, записанные по
практическим соображениям без пробелов. Необходимо помнить,
что имена классов образуют словарь предметной области в
методологии ООАП.
В секции имени класса могут также находиться стереотипы
или ссылки на стандартные шаблоны, от которых образован данный
класс и, соответственно, от которых он наследует атрибуты и
операции. В этой секции может также приводиться информация о
разработчике данного класса и статус состояния разработки. Здесь
также могут записываться и другие общие свойства этого класса,
имеющие отношение к другим классам диаграммы или
стандартным элементам языка UML.
Класс может иметь или не иметь экземпляров или объектов. В
зависимости от этого в языке UML различают конкретные и
абстрактные классы.
Конкретный класс (concrete class) – класс, на основе которого
могут быть непосредственно созданы экземпляры или объекты.
Рассмотренные выше обозначения относятся к конкретным
классам. От них следует отличать абстрактные классы.
Абстрактный класс (abstract class) – класс, который нельзя
реализовать непосредственно и не имеет экземпляров или объектов.
Операции не имеют реализации в абстрактном классе, это чистое
объявление.
Абстрактные классы (рис. 8.1.5) разрабатываются для того,
чтобы объединить некоторые действия, операции в один интерфейс,
и предоставлять этот интерфейс производным из него классам. Идея
создания абстрактных классов в том, что операции, определенные в
них являются относительно общими, и каждый класс, который
наследует эти операции, определяет и расширяет их для себя.
Для обозначения имени абстрактного класса используется
наклонный шрифт (курсив). В языке UML принято общее
соглашение о том, что любой текст, относящийся к абстрактному
49
50
элементу, записывается курсивом. Это имеет принципиальное

значение, поскольку является семантическим аспектом описания
абстрактных элементов языка UML.
Рис. 8.1.5. Графическое обозначение абстрактного класса
Активный класс (рис. 8.1.6) имеет экземпляры, каждый из

которых выполняет и управляет своим собственным потоком
управления.
В некоторых случаях необходимо явно указать, к какому
пакету относится тот или иной класс. Для этой цели используется
специальный символ разделитель – двойное двоеточие (::).
Синтаксис строки имени класса в этом случае будет следующий:
<Имя пакета>::<Имя класса>
Рис. 8.1.6. Активный класс
50
51
Другими словами, перед именем класса должно быть явно

указано имя пакета, к которому его следует отнести. Например,
если определен пакет с именем Банк, то класс Счет в этом банке
может быть записан в виде:
Банк::Счет.
Значения и атрибуты класса

Атрибут (attribute) – это именованное свойство класса, его
содержательная характеристика, описывающая множество
значений, которые могут принимать отдельные объекты этого
класса. Значение (value) – это элемент данных.
Атрибуты получаются абстрагированием типичных значений.
Можно провести следующую аналогию: объект относится к классу
так, как значение относится к атрибуту. Например, атрибутами
объектов класса Person (Человек) являются пате (имя), birthrate
(дата рождения) и weight (вес). Атрибутами объектов класса Car
(Машина) являются color (цвет), modelYear (год выпуска) и weight
(вес). У каждого конкретного объекта атрибут принимает свое
конкретное значение. Например, у объекта JoeSmith атрибут
birthdate может иметь значение «21 октября 1983». Другими
словами, Joe Smith родился 23 октября 1983 года. У разных
объектов один и тот же атрибут может иметь как разные, так и
одинаковые значения. Имя атрибута уникально в рамках класса (но
не обязательно уникально во множестве всех классов). Поэтому у
классов Person и Car может быть атрибут с одним и тем же
названием – weight.
На рис. 8.1.7 показана система обозначений атрибутов. Класс
Person (Человек) имеет атрибуты пате (имя) и birthdate (дата
рождения). Name – это строка, a birthdate – дата. У одного из
объектов класса Person атрибут пате имеет значение «Joe Smith», a
birthdate имеет значение «21 октября 1983». У другого объекта того
же класса атрибут пате имеет значение «Mary Sharp», а атрибут
birthdate имеет значение «16 марта 1950».
51
52
Рис. 8.1.7. Атрибуты обеспечивают детализацию классов
Атрибут класса служит для представления отдельного

свойства или признака, который является общим для всех объектов
данного класса. Атрибуты класса записываются во второй сверху
секции прямоугольника класса. Эту секцию часто называют
секцией атрибутов.
В языке UML принята определенная стандартизация записи
атрибутов класса, которая подчиняется некоторым синтаксическим
правилам. Каждому атрибуту класса соответствует отдельная
строка текста, которая состоит из:
 квантора видимости атрибута,
 имени атрибута,
 его кратности,
 типа значений атрибута
 и, возможно, его исходного значения.
Общий формат записи отдельного атрибута класса
следующий:
<квантор видимости> <имя атрибута> [кратность] : <тип
атрибута> = <исходное значение> {строка-свойство}
Видимость (visibility) – качественная характеристика
описания элементов класса, характеризующая потенциальную
возможность других объектов модели оказывать влияние, ссылаться
на отдельные аспекты поведения данного класса.
52
53
Видимость в языке UML специфицируется с помощью

квантора видимости (visibility), который может принимать одно из
4-х возможных значений и отображаться при помощи специальных
символов (рис. 8.1.8).
Символ «+» – обозначает атрибут с областью видимости типа
public (общедоступный, открытый). Атрибут с этой областью
видимости доступен или виден из любого другого класса пакета, в
котором определена диаграмма.
Символ «#» – обозначает атрибут с областью видимости типа
protected (защищенный). Атрибут с этой областью видимости
недоступен или невиден для всех классов, за исключением
подклассов данного класса.
Символ «-» – обозначает атрибут с областью видимости типа
private (закрытый). Атрибут с этой областью видимости недоступен
или невиден для всех классов без исключения.
И, наконец, символ «~» – обозначает атрибут с областью
видимости типа package (пакетный). Атрибут с этой областью
видимости недоступен или невиден для всех классов за пределами
пакета, в котором определен класс-владелец данного атрибута.
Рис. 8.1.8 Примеры обозначения видимости атрибутов
Квантор видимости может отсутствовать. Его отсутствие

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

используется в качестве идентификатора соответствующего
атрибута и поэтому должна быть уникальной в пределах данного
класса. Имя атрибута – единственный обязательный элемент
синтаксического обозначения атрибута, должно начинаться со
строчной буквы и не должно содержать пробелов.
Кратность (multiplicity) – спецификация области значений
допустимой мощности, которой могут обладать соответствующие
множества.
Кратность атрибута характеризует общее количество
конкретных атрибутов данного типа, входящих в состав отдельного
класса. В общем случае кратность записывается в форме строки
текста из цифр в квадратных скобках после имени
соответствующего атрибута, при этом цифры разделяются двумя
точками:
[нижняя граница .. верхняя граница],
где нижняя и верхняя границы положительные целые числа. Каждая
такая пара служит для обозначения отдельного замкнутого
интервала целых чисел, у которого нижняя (верхняя) граница равна
значению нижняя граница (верхняя). В качестве верхней границы
может использоваться специальный символ «*» (звездочка),
который означает произвольное положительное целое число, т.е.
неограниченное сверху значение кратности соответствующего
атрибута.
Интервалов кратности для отдельного атрибута может быть
несколько. В этом случае их совместное использование
соответствует теоретико-множественному объединению
соответствующих интервалов. Значения кратности из интервала
следуют в монотонно возрастающем порядке без пропуска
отдельных чисел, лежащих между нижней и верхней границами.
При этом придерживаются следующего правила: соответствующие
54
55
нижние и верхние границы интервалов включаются в значение

кратности.
Если в качестве кратности указывается единственное число, то
кратность атрибута принимается равной данному числу. В языке
UML кратность широко используется также для задания ролей
ассоциаций, составных объектов и значений атрибутов. Наиболее
типичные значения кратности: [1] – обязательное единственное
значение, [0..1] – необязательное единственное значение, [*] –
произвольное количество значений. Кратность определяет, является
ли атрибут обязательным (в терминах баз данных – может ли
атрибут иметь пустое значение). Если кратность атрибута не
указана, то по умолчанию в языке UML принимается ее значение
равное [1].
Тип атрибута представляет собой выражение, семантика
которого определяется некоторым типом данных, определенным в
спецификации типов данных атрибутов классов языка UML или
самим разработчиком. В нотации UML тип атрибута иногда
определяется в зависимости от языка программирования, который
предполагается использовать для реализации данной модели,
например, Integer, Boolean, String, Object, Date и др. В простейшем
случае тип атрибута указывается строкой текста, имеющей
осмысленное значение в пределах пакета или модели, к которым
относится рассматриваемый класс.
Исходное значение служит для задания начального значения
соответствующего атрибута в момент создания отдельного
экземпляра класса. Здесь необходимо придерживаться правила
принадлежности значения типу конкретного атрибута. Если
исходное значение не указано, то значение соответствующего
атрибута не определено на момент создания нового экземпляра
класса. С другой стороны, конструктор объекта может
переопределять исходное значение в процессе выполнения
программы, если в этом возникает необходимость.
55
56
Рис. 8.1.9. Описание деталей атрибутов класса
При задании атрибутов (рис. 8.1.9) могут быть использованы

дополнительные синтаксические конструкции – это подчеркивание
строки атрибута, пояснительный текст в фигурных скобках и косая
черта перед именем атрибута. Подчеркивание строки атрибута
означает, что соответствующий атрибут общий для всех объектов
данного класса, т.е. его значение у всех создаваемых объектов
одинаковое (аналог ключевого слова static в некоторых языках
программирования).
Пояснительный текст в фигурных скобках может означать две
различные конструкции. Если в этой строке имеется знак равенства,
то вся запись Строка-свойство служит для указания
дополнительных свойств атрибута, которые могут характеризовать
особенности изменения значений атрибута в ходе выполнения
программы. Фигурные скобки как раз и обозначают фиксированное
значение соответствующего атрибута для класса в целом, которое
должны принимать все вновь создаваемые экземпляры класса без
исключения. Это значение принимается за исходное значение
атрибута, которое не может быть переопределено в последующем.
Отсутствие строки-свойства по умолчанию трактуется так, что
значение соответствующего атрибута может быть изменено в
программе.
Знак «/» перед именем атрибута указывает на то, что данный
атрибут является производным от некоторого другого атрибута
этого же класса.
56
57
Производный атрибут (derived element) – атрибут класса,

значение которого для отдельных объектов может быть вычислено
посредством значений других атрибутов этого же объекта.
Операции класса
Операция (operation) – это функция или процедура, которая
может быть применена к объектам класса, т.е. сервис,
предоставляемый каждым экземпляром или объектом класса по
требованию своих клиентов, в качестве которых могут выступать
другие объекты, в том числе и экземпляры данного класса.
Операциями класса Company (Компания) могут быть hire (нанять),
fire (уволить) и payDividend (выплатитьДивиденды). Операциями
класса Window (Окно) могут быть open (открыть), close (закрыть),
hide (скрыть) и redisplay (перерисовать). Все объекты одного класса
имеют общий список операций.
Каждая операция в качестве неявного аргумента принимает свой
целевой объект. Поведение операции зависит от класса целевого
объекта. Объект всегда знает свой собственный класс, а потому он
всегда знает и правильную реализацию операции.
Одна и та же операция может быть применена к разным классам.
Такая операция называется полиморфной: в разных классах она
может принимать разные формы. Методом (method) называется
реализация операции в конкретном классе. Например, класс File
(Файл) может иметь операцию print (печать). Печать ASCII-файлов,
двоичных файлов и цифровых изображений может осуществляться
разными методами. Все эти методы с логической точки зрения
выполняют одно и то же действие: печать файла. Поэтому они и
являются реализациями одной и той же операции print. При этом
каждый метод может быть реализован своим собственным кодом.
У операции могут быть и другие аргументы, кроме целевого
объекта. Эти аргументы могут быть как значениями, так и другими
объектами. Выбор метода зависит только от класса целевого объекта,
но не от классов аргументов, которые являются объектами, сколько
57
58
бы их ни было. В некоторых объектно-ориентированных языках

выбор метода может определяться произвольным числом
аргументов, но такая универсальность значительно усложняет
семантику модели.
Если операция реализована несколькими методами в разных
классах, очень важно, чтобы у всех методов была одна и та же
сигнатура (signature) – количество и типы аргументов, а также тип
возвращаемого значения. Например, у операции print не может быть
аргумента fileName (имяФайла) в одном методе и filePointer
(указательФайла) в другом методе. Поведение всех методов
операции должно быть согласованно. Лучше всего избегать
использования одинаковых названий для операций, отличающихся
друг от друга с семантической точки зрения, даже если они
применяются к разным множествам классов. Например, неправильно
было бы использовать название «инверсия» для операций
инвертирования матрицы и переворота геометрической фигуры. В
большом проекте может потребоваться использование пространств
имен для предотвращения конфликтов, но лучше всего заранее
принимать меры для предотвращения возможных проблем.
На рис. 8.1.10 изображен класс Person (Человек) с атрибутами
пате (имя) и birthdate (дата рождения) и операциями changejob
(сменить работу) и changeAddress (сменить адрес). Атрибуты и
операции называются составляющими класса. У класса File (Файл)
есть операция print (печать). У класса GeometricObject
(геометрический Объект) есть операции move (перемещение), select
(выделение) и rotate (поворот). Операция move имеет один аргумент
delta (смещение) типа Vector (вектор), операция select имеет
аргумент р типа Point (Точка) и возвращает значение типа Boolean
(логическое значение). Операция rotate имеет аргумент angle (угол),
который относится к типу чисел с плавающей точкой и имеет
значение по умолчанию 0.0.
58
59
Рис. 8.1.10. Операции
Операции класса записываются в третьей сверху секции

прямоугольника класса, которую часто называют секцией операций.
Название операции указывается обычным шрифтом и выравнивается
по левому краю. Первая буква названия операции должна быть
прописной. После названия операции могут быть указаны
необязательные дополнительные сведения, такие как список
аргументов и тип возвращаемого результата. Список аргументов
указывается в круглых скобках. Аргументы отделяются друг от друга
запятыми. Перед типом возвращаемого результата ставится
двоеточие. Пустой список аргументов в круглых скобках явно
показывает, что данная функция не принимает никаких аргументов.
Если же списка просто нет, никаких выводов делать нельзя.
Операции не указываются для отдельных объектов, поскольку у
всех объектов одного класса операции одинаковые.
Совокупность операций характеризует функциональный
аспект поведения всех объектов данного класса. Запись операций
класса в языке UML также стандартизована и подчиняется
определенным синтаксическим правилам. При этом каждой
операции класса соответствует отдельная строка, которая состоит
из:
 квантора видимости операции,
 имени операции,
 выражения типа возвращаемого операцией значения
59
60
 и, возможно, строка-свойство данной операции.

Общий формат записи отдельной операции класса следующий:
<квантор видимости> <имя операции> (список параметров):
<выражение типа возвращаемого значения> {строка-свойство}.
Квантор видимости, как и в случае атрибутов класса, может
принимать одно из четырех возможных значений и, соответственно,
отображается при помощи специального символа либо ключевого
слова. Символ «+» обозначает операцию с областью видимости
типа public (общедоступный). Символ «#» обозначает операцию с
областью видимости типа protected (защищенный). Символ «-»
используется для обозначения операции с областью видимости типа
private (закрытый). И, наконец, символ «~» используется для
обозначения операции с областью видимости типа package
(пакетный).
Квантор видимости для операции может отсутствовать. В этом
случае его отсутствие просто означает, что видимость операции не
указывается. Вместо условных графических обозначений также
можно записывать соответствующее ключевое слово: public,
protected, private, package.
Имя операции представляет собой строку текста, которая
используется в качестве идентификатора соответствующей
операции и поэтому должна быть уникальной в пределах данного
класса. Имя операции – единственный обязательный элемент
синтаксического обозначения операции, должно начинаться со
строчной буквы, и, как правило, записываться без пробелов.
Список параметров является перечнем разделенных запятой
формальных параметров, каждый из которых, в свою очередь,
может быть представлен в следующем виде:
<направление параметра> <имя параметра>:
<выражение типа> = <значение параметра по умолчанию>.
60
61
Параметр (parameter) – спецификация переменной операции,

которая может быть изменена, передана или возвращена.
Параметр может включать имя, тип, направление и значение
по умолчанию. Направление параметра – есть одно из ключевых
слов in, out или inout со значением in по умолчанию, в случае если
вид параметра не указывается.
Расшифровка значений ключевых слов:
in – операция не может изменить значение параметра;
out – операция устанавливает или изменяет значение
параметра, который возвращается объектом после выполнения
операции;
inout – операция использует значение параметра и может
изменить его, при этом значение параметра возвращается объектом
после выполнения операции.
Имя параметра есть идентификатор соответствующего
формального параметра, при записи которого следуют правилам
задания имен атрибутов. Выражение типа является спецификацией
типа данных для допустимых значений соответствующего
формального параметра. Наконец, значение по умолчанию в общем
случае представляет собой некоторое конкретное значение для
этого формального параметра.
Выражение типа возвращаемого значения также указывает на
тип данных значения, которое возвращается объектом после
выполнения соответствующей операции. Две точки и выражение
типа возвращаемого значения могут быть опущены, если операция
не возвращает никакого значения. Для указания нескольких
возвращаемых значений данный элемент спецификации операции
может быть записан в виде списка отдельных выражений.
Операция с областью действия на весь класс показывается
подчеркиванием имени и строки выражения типа. В этом случае
под областью действия операции понимаются все объекты этого
класса. В этом случае вся строка записи операции подчеркивается.
61
62
Строка-свойство служит для указания значений свойств,

которые могут быть применены к данной операции. Строка-
свойство может отсутствовать, если свойства не специфицированы.
Рис. 8.1.11. Пример описания операций класса
В UML также можно выделить свойство, которое указывает,

что операция не изменяет значения всех атрибутов. Такую
операцию помечают строкой свойств {IsQuery} рис. 8.1.11. В
зависимости от значения false или true свойства {IsQuery} возможно
изменение состояния системы. Помеченная операция объекта как
{IsQuery = false} изменяет состояние системы.
Расширение языка UML для построения моделей

программных и бизнес систем
Одним из несомненных достоинств языка UML является
наличие механизмов расширения, которые позволяют ввести в
рассмотрение дополнительные графические обозначения,
ориентированные для решения задач из определенной предметной
области. Язык UML содержит два специальных расширения:
профиль для процесса разработки программного обеспечения (The
UML Profile for Software Development Processes) и профиль для
бизнес-моделирования (The UML Profile for Business Modeling).
В рамках первого из них предложено три специальных
графических примитива, которые могут быть использованы для
уточнения семантики отдельных классов при построении различных
диаграмм:
62
63
 Управляющий класс (control class) – класс, отвечающий за

координацию действий других классов. На каждой диаграмме
классов должен быть хотя бы один управляющий класс, причем
количество посылаемых объектам управляющего класса сообщений
мало, по сравнению с числом рассылаемых ими. Управляющий
класс отвечает за координацию действий других классов. У каждой
диаграммы классов должен быть хотя бы один управляющий класс,
контролирующий последовательность выполнения действий этого
варианта использования. Как правило, данный класс является
активным и инициирует рассылку множества сообщений другим
классам модели. Кроме специального обозначения управляющий
класс может быть изображен в форме прямоугольника класса со
стереотипом «control» (рис. 8.1.12, а).
 Класс-сущность (entity class) – пассивный класс,
информация о котором должна храниться постоянно и не
уничтожаться с выключением системы. Класс-сущность содержит
информацию, которая должна храниться постоянно и не
уничтожается с уничтожением объектов данного класса или
прекращением работы моделируемой системы, связанные с
выключением системы или завершением программы. Как правило,
этот класс соответствует отдельной таблице базы данных. В этом
случае его атрибуты являются полями таблицы, а операции –
присоединенными или хранимыми процедурами. Этот класс
пассивный и лишь принимает сообщения от других классов модели.
Класс-сущность может быть изображен также стандартным образом
в форме прямоугольника класса со стереотипом «entity» (рис. 8.1.12,
б).
 Граничный класс (boundary class) – класс, который
располагается на границе системы с внешней средой и

непосредственно взаимодействует с актерами, но является
составной частью системы. Граничный класс может быть
изображен также стандартным образом в форме прямоугольника
класса со стереотипом «boundary» (рис. 8.1.12).
63
64
Рис. 8.1.12. Графическое изображение классов для моделирования

программных систем
В рамках второго профиля также предложено три специальных

графических примитива, которые могут быть использованы для
уточнения семантики отдельных классов при построении моделей
бизнес-систем:
 Сотрудник (business worker) – класс, служащий на
диаграмме классов для представления любого сотрудника, который
является элементом бизнес-системы и взаимодействует с другими
сотрудниками при реализации бизнес-процесса. Этот класс также
может быть изображен в форме прямоугольника класса со
стереотипом «worker» или «internalWorker» (рис. 8.1.13, а).
 Сотрудник для связи с окружением (caseworker) – класс,
служащий для представления в бизнес-системе такого сотрудника,
который, являясь элементом бизнес-системы, непосредственно
взаимодействует с актерами (бизнес-актерами) при реализации
бизнес-процесса. Этот класс также может быть изображен в форме
прямоугольника класса со стереотипом «caseWorker» (рис. 8.1.13,б).
 Бизнес-сущность (business entity) — специальный случай
класса-сущности, который также не инициирует никаких
сообщений. Этот класс служит для сохранения информации о
результатах выполнения бизнес-процесса в моделируемой бизнес-
системе или организации. Этот класс также может быть изображен
64
65
в форме прямоугольника класса со стереотипом «business entity»

(рис. 8.1.13, в).
Рис. 8.1.13. Графическое изображение классов для моделирования

бизнес-систем
Интерфейсы, порты и коннекторы

Интерфейс (interface) – именованное множество операций,
которые характеризуют поведение отдельного класса и
представляют его для других классов.
Одним из основных принципов объектного подхода является
разделение интерфейсной части от того, каким образом операции
реализованы как методы. Интерфейс понимается как некоторое
наставление, которое класс должен придерживаться. При этом класс
может реализовать один или более интерфейсов.
Интерфейс в контексте языка UML является специальным
случаем класса, у которого имеются операции, но отсутствуют
атрибуты. По определению все операции обладают признаком
видимости public. Для обозначения интерфейса используется
специальный графический символ окружность или стандартный
способ – прямоугольник класса со стереотипом «interface»
(рис. 8.1.14).
На диаграмме вариантов использования интерфейс
изображается в виде маленького круга, рядом с которым
65
66
записывается его имя (рис. 8.1.14, а). В качестве имени может

использоваться существительное, которое характеризует
соответствующую информацию или сервис, например, «Датчик
температуры», «Форма ввода», «Сирена», «Видеокамера»
(рис. 8.1.14, б). С учетом языка реализации модели имя интерфейса,
как и имена других классов, рекомендуется записывать на
английском языке и начинать с заглавной буквы I, например,
ITemperatureSensor, IsecureInformation (рис. 8.1.14, в).
Рис. 8.1.14. Примеры графического изображения интерфейсов на диаграммах

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

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

диаграмм, например, диаграммах компонентов и развертывания.
UML определяет два вида интерфейсов: обеспеченные
интерфейсы и требуемые интерфейсы.
Обеспеченные (предоставляемые) интерфейсы (provided
interfaces) – это интерфейсы, которые предоставляют своим
клиентам операции (сервисы, услуги), которые реализованы в
некотором классе. Это скорее отношение между интерфейсом и
классом, которое выражает возможность вызова класса для
предоставления описываемых интерфейсом сервисов. Есть два
способа показать обеспеченные интерфейсы. Один способ называют
применение «леденца на палочке»: интерфейс изображается в виде
круга, соединенного с изображением класса, которому
обеспечивается (предоставляется) интерфейс, прямой линией.
Другой способ определения интерфейса – это использование
изображение класса в виде прямоугольника с встроенным
стереотипом интерфейса, который соединяется с классом
пунктирной линией с не закрашенным треугольником в конце,
который примыкает к интерфейсу и указывает на него. Данные вид
отношений между классами и интерфейсами называют отношением
реализации.
Рис. 8.1.15. Объявление и отношение интерфейсов
На рис. 8.1.15 изображено объявление интерфейса IPassword

Handler (Управляющий паролями) классом Account (Счет), что
обозначает, например, реализацию услуг использования различных
алгоритмов шифрования при сохранении пароля клиента,
67
68
принадлежащих интерфейсу IPassword Handler, в классе Account.

Во втором примере представлено данное отношения между
интерфейсом IInventory Handler (Управление складом) и классом
Inventory (Склад, инвентарь, опись), которое позволяет элементам
системы взаимодействовать с объектами класса Inventory, в которых
реализованы сервисы по управлению инвентарем. При этом
элементам системы не обязательно знать, какие методы управления
инвентарем используются при реализации данных сервисов (услуг):
метод FIFO (first in, first out), LIFO (last in, first out) или какой-либо
другой метод.
Требуемый интерфейс (required interfaces) – это интерфейс,
сервисы (операции) которого запрашивает класс для полной
реализации своего внутреннего поведения. При этом класс должен
реализовать сервисы, предоставляемые интерфейсом, полностью.
Символ для требуемого интерфейса – полукруг, соединенный
сплошной линией с прямоугольником класса, как показано на
рис. 8.1.16.
Рис. 8.1.16. Требуемый интерфейс
Объекты класса Заказ реализуют сервисы интерфейса IRetrieve

Books (Поиск книг) при заполнении заказа и интерфейса IRetrieve
Tracking Info (Поиск информации об отправке), для того, чтобы
клиент, разместивший заказ, мог воспользоваться услугами
просмотра состояния заказа.
68
69
Если один класс объявляет обеспеченный интерфейс, а другой

класс требует тот же интерфейс, эти классы могут
взаимодействовать друг с другом по данному интерфейсу без
всяких дополнительных услуг.
Рис. 8.1.17. Обеспеченный интерфейс
На рис. 8.1.17 класс Inventory реализует обеспеченный

интерфейс IRetrieve Books, сервисы которого требуются другому
классу Order.
Порт (port) – это точка соединения класса с окружающей
средой. Соединения осуществляются через порты с обеспеченными
и требуемыми интерфейсами, объявленными для данного порта.
Существуют два способа представления портов. Порты служат
точками связи, через которые могут быть сделаны запросы к
выполнению операций, которые реализуют поведение класса.
Порты также служат воротами для осуществления запросов классом
к операциям (сервисам), которые предлагаются другими классами.
Порт изображается в виде небольшого квадрата,
пересекающего границу прямоугольника класса. Около квадрата
ставится имя порта. Интерфейсы связываются с портами через
коннекторы (connectors), которые изображаются простыми
прямыми линиями. На рис. 8.1.18 изображены примеры двух
портов, один из которых является именованным.
69
70
Рис. 8.1.18. Порты и коннекторы
Экземпляры класса Order получают запрос на выполнение

фактических заказов, которые осуществляются через сервисы,
предоставляемые интерфейсом Perform Fulfillment (представить к
исполнению). Для выполнения этого запроса экземпляры класса
Order используют сервисы интерфейса Retrieve Books. После того,
как данный заказ отправлен, клиент, осуществивший его, может
запросить информацию о состоянии заказа через интерфейс Provide
Tracking Info (предоставление информации об отправке).
Экземпляры класса Order, в свою очередь, используют интерфейс
Retrieve Tracking Info, чтобы получить необходимую информацию о
состоянии заказа и передать ее клиенту.
Поведение класса может быть частично или полностью
описано множеством объектов, которые принадлежат этому классу
или на которые ссылается класс. Каждый из таких объектов
является собственность класса.
Кооперация (сотрудничество), Collaboration

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

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

структура кооперации, которая представляется как набор ролей,
связанных соединителями. Роль – это описание участника
кооперации. Пиктограмма роли изображается виде прямоугольника,
в котором указывается имя и тип роли:
имя: Тип [множественность].
Один и тот же класс может играть различные роли в одной и
той же или в разных кооперациях. В этом случае каждая из ролей
класса будет представлена отдельным объектом.
71
72
Рис. 8.1.20. Кооперация с внутренней структурой
Кооперация Proxy является примером проектирования

паттерна (образца). Паттерн представляет собой
параметризованную кооперацию, которую можно использовать
несколько раз в одной, так и в нескольких системах. Паттерном
можно назвать только ту кооперацию, которую можно использовать
во многих ситуациях. В языке UML параметризованная кооперация
– это структурное и поведенческое представление определенных
видов паттернов.
Информация, запрашиваемая клиентом о своем заказе,
представляется с помощью интерфейса OrderInterface в форме
HTML-страницы. Этот интерфейс обеспечивает доступ клиента к
полномочиям OrderProxy, которые предназначены для конкретных
объектов класса Order. Это необходимо, поскольку объекты класса
Order ответственны за направление процессов в системе, и поэтому
они не должны быть непосредственно доступны клиентам.
OrderProxy обеспечивает доступ к заказам Order по мере
необходимости информации о них, не прерывая работу системы.
Термин вхождение кооперации использовался вместо термина
применение кооперации, но при этом происходило размывание
72
73
смысла термина вхождение. Поэтому предпочтительнее

употреблять термин применение.
Кооперацию можно использовать путем привязки ролей к
классам в конкретном контексте – например, в контексте
внутренней структуры класса или определения более крупной
кооперации. Результат такой привязки называется применением
кооперации. Кооперация может многократно использоваться в
различных применениях.
Применение кооперации изображается в виде пунктирного
эллипса, содержащего строку имени в следующем формате:
имя применения: Кооперация,
где имя применения является идентификатором конкретного
применения, а кооперация – имя определения кооперации.
Если применение кооперации связывает кооперацию с
классом, аспект поведения которого она описывает, то в данном
случае используется пунктирная стрелка, направленная от
применения кооперации к символу класса. Если кооперации
представляет общее поведение класса (а не отдельный его аспект),
то над пунктирной стрелкой ставится ключевое слово «represents»
рис. 8.1.21.
Рис. 8.1.21. Поведение класса, представленное кооперацией
Другие стереотипы классов

Существуют встроенные стереотипы, которые могут оказаться
полезными при определении классов. Эти стереотипы приведены
ниже:
73
74
1) Два стереотипа различают между собой первичную и

вторичную логику или управление потоком. Стереотип «focus»
определяет, что класс обеспечивает ядро логики (первичную
логику) с одним или несколькими вспомогательными классами,
которые предоставляют вспомогательные механизмы. Эти
вспомогательные классы имеют стереотип «auxiliary», т.е. классы,
которые поддерживают другие, более общие, центральные классы.
На рис. 8.1.22 представлен пример применения этих двух
стереотипов. Класс GLReport содержит средства форматирования и
печати отчетов, информация для которых предоставляется общим
классом General Ledger.
Рис. 8.1.22. Классы со стереотипами «focus» и «auxiliary»
2) Три следующих стереотипа определяют множества

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

74
75
Стереотип «enumeration» – это тип - перечисления, который

представляет собой конечное множество именованных элементов,
определяемых пользователем. Они обладают упорядоченностью,
именем и списком констант. На рис. 8.1.24 представлен пример
типа-перечисления.
Рис. 8.1.24. Тип-перечисление
Этот тип-перечисление может быть использован как

альтернатива классу BookAndAuthor, который может определяться
ранее. Если этого класса не существует, то в классе Author должен
присутствовать атрибут AuthorRole (Тип автора).
Стереотип «primitive» обозначает типы данных, встроенные в
UML. К примитивным типам относятся числа, строки и логические
величины.
3) Стереотип «utility» определяет класс, не имеющий
экземпляров, который содержит совокупность статических
атрибутов и операций, областью действия которых является сам
этот класс.
4) Следующие два стереотипа предлагают способ
дифференцировать классы при моделировании.
Стереотип «specification» определяет класс, описывающий
область определения объектов, не обеспечивая их физической
реализации.
75
76
Стереотип «implementationClass» определяет класс, который

обеспечивает физическую реализацию (включая атрибуты,
ассоциации с другими классами и методами). Класс реализации
предназначен для традиционных объектно-ориентированных
языков с однозначной фиксированной спецификацией.
5) Также можно использовать стереотип «stereotype». Данный
стереотип определяет новый вид элемента модели, созданный на
основе существующего элемента.
6) Стереотип «metaclass» определяет класс, экземпляры
которого также являются классами. Метаклассы используются, как
правило, при создании метамоделей.
8.2. Отношения между классами и их графическое изображение

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

разработке проектируемой системы имеют различные отношения
между классами, которые также могут быть изображены на
диаграмме классов. Совокупность допустимых типов таких
отношений строго фиксирована в языке UML и определяется самой
семантикой этих отношений. Базовые отношения, изображаемые на
диаграммах классов:
 Отношение ассоциации (association relationship);
 Отношение обобщения (generalization relationship);
 Отношение агрегации (aggregation relationship);
 Отношение композиции (composition relationship).
Каждое из этих отношений имеет собственное графическое
представление, которое отражает семантический характер
взаимосвязи между объектами соответствующих классов.
Отношение ассоциации
76
77
Ассоциация (association) – семантическое отношение между

двумя и более классами, которое специфицирует характер связи
между соответствующими экземплярами этих классов.
Отношение ассоциации соответствует наличию произвольного
отношения или взаимосвязи между классами. Данное отношение,
обозначается сплошной линией со стрелкой или без нее и с
дополнительными символами, которые характеризуют специальные
свойства ассоциации. Ассоциации рассматривались при изучении
элементов диаграммы вариантов использования, применительно к
диаграммам классов, тем не менее, семантика этого типа отношений
значительно шире.
Наиболее простой случай данного отношения – бинарная
ассоциация (binary association), которая служит для представления
произвольного отношения между двумя классами. Она связывает в
точности два различных класса и может быть ненаправленным
(симметричным) или направленным отношением. Частный случай
бинарной ассоциации – рефлексивная ассоциация, которая
связывает класс с самим собой. Ненаправленная бинарная
ассоциация изображается линией без стрелки. Для нее на диаграмме
может быть указан порядок чтения классов с использованием
значка в форме треугольника рядом с именем данной ассоциации.
На рис. 8.2.1 изображены примеры ненаправленных
ассоциаций, которые указывают на отношения между: классами
Book (Книга) и Publisher (Издатель), Book и Review (Обзор), Shipper
(Посылка) и ShippingInfo (Информация о посылке).
77
78
Рис. 8.2.1. Обозначения ассоциаций в UML

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

роль в соответствующем отношении, на что явно указывает имя
концевых точек ассоциации на диаграмме.
78
79
Рис. 8.2.3. Указание ролей классов в ассоциации
Приведенную на рис. 8.2.3 ассоциацию можно читать в обоих

направлениях:
«Обозреватель пишет обзор» или «Обзор, написан
обозревателем»
Отметим, что классы могут играть несколько ролей в рамках
различных ассоциаций.
 Кратность (множественность) классов-ролей ассоциации
указывает на то, какое количество объектов данного класса
участвуют в ассоциации с объектами другого класса.
На рис. 8.2.4 указываются ассоциации между классами
Customer (Клиент) и Account (Счет), Account и BillingInfo
(Информация о счете). Для этих ассоциаций указаны кратности
классов ассоциации. Они обозначают следующее: одному
покупателю электронного магазина принадлежит только один счет
и счет может принадлежать только одному покупателю, для одного
счета можно потребовать бесконечное множество запросов
информации об этом счете и каждая информация может быть
только об одном счете.
79
80
Рис. 8.2.4 Указание кратности классов в ассоциациях
Чаще всего встречаются следующие множественности: «ровно

один» – 1, «нуль и более» – 0 . . n, «нуль и более, с ограничением» –
0 . . *, «нуль и более, без ограничений» – 1 . . *.
В качестве простого примера ненаправленной бинарной
ассоциации можно рассмотреть отношение между двумя классами –
классом Company (Компания) и классом Person (Человек) рис. 8.2.5.
80
81
Рис. 8.2.5. Графическое изображение ненаправленной бинарной ассоциации

между классами
Два класса связаны между собой бинарной ассоциацией

«works for» (Работает на), имя которой указано на рисунке рядом с
линией ассоциации. Для данного отношения определен следующий
порядок чтения следования классов – человек работает на
компанию. Рядом с именами классов указывается их роль, а именно
класс Person выступает в качестве сотрудника компании, класс
Company – в качестве нанимателя, работодателя.
Направленная бинарная ассоциация изображается сплошной
линией с простой стрелкой на одной из ее концевых точек
(рис. 8.2.6.). Направление этой стрелки указывает на то, какой класс
является первым, а какой – вторым.
Рис. 8.2.6. Графическое изображение направленной бинарной ассоциации
81
82
В качестве еще одного примера направленной бинарной

ассоциации можно рассмотреть отношение между двумя классами –
классом Customer (Покупатель, клиент) и классом Purchase
(Покупка) рис. 8.2.7. Они связаны между собой бинарной
ассоциацией с именем Makes (Совершает), для которой определен
порядок следования классов. Это означает, что конкретный объект
класса Customer всегда должен указываться первым при
рассмотрении взаимосвязи с объектом класса Purchase. Другими
словами, эти объекты классов образуют кортеж элементов,
например, <Customer, purchase_1, purchase _2,…, purchase_n>.
Рис. 8.2.7. Графическое изображение направленной бинарной ассоциации

между классами с указанием кратности
Частный случай отношения ассоциации – так называемая

исключающая ассоциация (Xor-association) (рис. 8.2.8).
Рис. 8.2.8. Графическое изображение исключающей ассоциации между тремя

классами
82
83
На диаграмме классов исключающая ассоциация изображается

пунктирной линией, соединяющей две и более ассоциации
(рис. 8.2.8), рядом с которой записывается ограничение в форме
строки текста в фигурных скобках: {xor}.
Семантика данной ассоциации указывает на то, что из
нескольких потенциально возможных вариантов данной ассоциации
в каждый момент времени может использоваться только один.
Тернарная ассоциация связывает отношением три класса.
Ассоциация более высокой арности называется n-арной
ассоциацией.
n-арная ассоциация (n-ary association) – ассоциация между
тремя и большим числом классов.
Каждый экземпляр такой ассоциации представляет собой
упорядоченный набор (кортеж), содержащий n экземпляров из
соответствующих классов. Такая ассоциация связывает отношением
более чем три класса, при этом класс может участвовать в
ассоциации более чем один раз. Каждый экземпляр n-арной
ассоциации представляет собой n-арный кортеж, состоящий из
объектов соответствующих классов. В этом контексте бинарная
ассоциация является частным случаем n-арной ассоциации, когда
значение n=2, но имеет собственное обозначение. Бинарная
ассоциация – это специальный случай n-арной ассоциации.
Графически n-арная ассоциация обозначается ромбом, от
которого ведут линии к символам классов данной ассоциации
(рис. 8.2.9). Сам же ромб соединяется с символами классов
сплошными линиями. Обычно линии проводятся от вершин ромба
или от середины его сторон. Имя n-арной ассоциации записывается
рядом с ромбом соответствующей ассоциации. Однако порядок
классов в n-арной ассоциации, в отличие от порядка множеств в
отношении, на диаграмме не фиксируется.
83
84
Рис.8.2.9. Пример тернарной ассоциации
В качестве примера тернарной ассоциации можно рассмотреть

отношение между тремя классами: Employee (Сотрудник), Company
(Компания) и Project (Проект). Данная ассоциация указывает на
наличие отношения между этими тремя классами, которое может
представлять информацию о проектах, реализуемых в компании, и о
сотрудниках, участвующих в выполнении отдельных проектов
(рис. 8.2.10).
Рис. 8.2.10. Графическое изображение тернарной ассоциации
Класс может быть присоединен к линии ассоциации

пунктирной линией. Это означает, что данный класс обеспечивает
поддержку свойств соответствующей n-арной ассоциации, а сама n-
арная ассоциация имеет атрибуты, операции и/или ассоциации.
Другими словами, такая ассоциация является классом с
84
85
соответствующим обозначением в виде прямоугольника и

самостоятельным элементом языка UML – ассоциацией классом
(association class).
Класс-ассоциация (association class) – модельный элемент,
который одновременно является ассоциацией и классом. Класс-
ассоциация может рассматриваться как ассоциация, которая
обладает свойствами класса, или как класс, имеющий также
свойства ассоциации.
Как уже упоминалось, отдельный класс в ассоциации может
играть определенную роль в данной ассоциации. Эта роль может
быть явно специфицирована на диаграмме классов. С этой целью в
языке UML вводится в рассмотрение специальный элемент –
концевая точка ассоциации или полюс ассоциации (association end),
который графически соответствует точке соединения линии
ассоциации с отдельным классом.
Полюс ассоциации (association end) – концевая точка
ассоциации, которая связывает ассоциацию с классификатором.
Полюс ассоциации – часть ассоциации, но не класса. Каждая
ассоциация может иметь два или более полюсов ассоциации.
Наиболее важные свойства ассоциации указываются на диаграмме
рядом с этими элементами ассоциации и должны перемещаться
вместе с ними. Одним из таких дополнительных обозначений
является имя роли отдельного класса, входящего в ассоциацию.
Роль (role) – имеющее имя специфическое поведение
некоторой сущности, рассматриваемой в определенном контексте.
Роль может быть статической или динамической.
Имя роли представляет собой строку текста рядом с полюсом
ассоциации для соответствующего класса. Она указывает на
специфическую роль, которую играет класс, являющийся полюсом
рассматриваемой ассоциации. Имя роли не обязательный элемент
обозначений и может отсутствовать на диаграмме.
Следующий элемент обозначений – кратность ассоциации.
Кратность относится к концам ассоциации и обозначается в виде
85
86
интервала целых чисел, аналогично кратности атрибутов и

операций классов, но без прямых скобок. Этот интервал
записывается рядом с концом соответствующей ассоциации и
означает потенциальное число отдельных экземпляров класса,
которые могут иметь место, когда остальные экземпляры или
объекты классов фиксированы.
Так, для примера на предыдущем рисунке кратность «1» для
класса Company означает, что каждый сотрудник может работать
только в одной компании. Кратность «1..*» для класса Employee
означает, что в каждой компании могут работать несколько
сотрудников, общее число которых заранее неизвестно и ничем не
ограничено. Вместо кратности «1..*» нельзя записать только символ
«*», поскольку последний означает кратность «0..*». Для данного
примера это означало бы, что отдельные компании могут совсем не
иметь сотрудников в своем штате. Такая кратность приемлема в
ситуациях, когда в компании вообще не выполняется никаких
проектов.
Имя ассоциации рассматривается в качестве отдельного
атрибута у соответствующих классов ассоциаций и может быть
указано на диаграмме явным способом в определенной секции
прямоугольника класса.
Ассоциация является наиболее общей формой отношения в
языке UML. Все другие типы рассматриваемых отношений можно
считать частным случаем данного отношения. Однако важность
выделения специфических семантических свойств и
дополнительных характеристик для других типов отношений
обусловливают необходимость их самостоятельного изучения при
построении диаграмм классов. Поскольку эти отношения имеют
специальные обозначения и относятся к базовым понятиям языка
UML, следует перейти к их последовательному рассмотрению.
Отношение обобщения
86
87
Отношение обобщения является отношением классификации

между более общим элементом (родителем или предком) и более
частным или специальным элементом (дочерним или потомком).
Обобщение (generalization) – отношение между более общим
понятием и менее общим понятием.
Менее общий элемент модели должен быть согласован с более
общим элементом и может содержать дополнительную
информацию. Данное отношение используется для представления
иерархических взаимосвязей между различными элементами языка
UML, такими как пакеты, классы, варианты использования.
Применительно к диаграмме классов данное отношение
описывает иерархическое строение классов и наследование их
свойств и поведения.
Наследование (inheritance) – специальный концептуальный
механизм, посредством которого более специальные элементы
включают в себя структуру и поведение более общих элементов.
Согласно одному из главных принципов методологии ООАП –
наследованию, класс-потомок обладает всеми свойствами и
поведением класса-предка, а также имеет собственные свойства и
поведение, которые могут отсутствовать у класса-предка.
Родитель, предок (parent) – в отношении обобщения более
общий элемент. Потомок (child) – специализация одного из
элементов отношения обобщения, называемого в этом случае
родителем.
87
88
Рис. 8.2.11. Графическое изображение отношения обобщения в языке UML

На диаграммах отношение обобщения обозначается сплошной
линией с треугольной стрелкой на одном из концов (рис. 8.2.11).
Стрелка указывает на более общий класс (Parent Class, класс-
предок или суперкласс), а ее начало – на более специальный класс
(Child Class, класс-потомок или подкласс).
От одного класса-предка одновременно могут наследовать
несколько классов-потомков, что отражает таксономический
характер данного отношения (рис. 8.2.12). В этом случае на
диаграмме классов для подобного отношения обобщения
указывается несколько линий со стрелками.
88
89
Рис. 8.2.12. Изображение отношения обобщения
Например, класс Vehicle (Транспортное средство) (курсивное

написание на рисунке обозначает абстрактный класс) может
выступать в качестве суперкласса для подклассов,
соответствующих конкретным транспортным средствам, таким как:
Automobile (Автомобиль), Bus (Автобус), Tractor (Трактор) и
другим. Это может быть представлено графически в форме
диаграммы классов следующего вида (рис. 8.2.13).
Рис. 8.2.13. Пример графического изображения отношения обобщения для

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

уменьшения числа стрелок-треугольников и совокупности линий,
обозначающих одно и то же отношение обобщения, может быть
просто изображена стрелка. В этом случае отдельные линии
сходятся к стрелке, которая имеет с этими линиями единственную
точку пересечения (рис. 8.2.14).
89
90
Рис. 8.2.14. Альтернативный вариант графического изображения отношения

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

соответствует графу специального вида, а именно – иерархическому
дереву. Как нетрудно заметить, в этом случае класс-предок является
корнем дерева, а классы-потомки – его ветви. Отличие заключается
в возможности указания на диаграмме классов дополнительной
семантической информации, которая может отражать различные
теоретико-множественные характеристики данного отношения. При
этом класс-предок на диаграмме может занимать произвольное
положение относительно своих классов-потомков, определяемое
лишь соображениями удобства.
В дополнение к простой стрелке обобщения может быть
присоединена строка текста, указывающая на специальные свойства
этого отношения в форме ограничения. Этот текст будет относиться
ко всем линиям обобщения, которые идут к классам-потомкам.
Поскольку отмеченное свойство касается всех подклассов данного
отношения, именно поэтому спецификация этого свойства
осуществляется в форме ограничения, которое должно быть
записано в фигурных скобках.
В качестве ограничений могут быть использованы следующие
ключевые слова языка UML:
90
91
{complete} – означает, что в данном отношении обобщения

специфицированы все классы-потомки, и других классов-потомков
у данного класса-предка быть не может.
{incomplete} – означает случай, противоположный первому. А
именно, предполагается, что на диаграмме указаны не все классы-
потомки. В последующем возможно разработчик восполнит их
перечень, не изменяя уже построенную диаграмму.
{disjoint} – означает, что классы-потомки не могут содержать
объектов, одновременно являющихся экземплярами двух или более
классов.
{overlapping} – случай, противоположный предыдущему. А
именно, предполагается, что отдельные экземпляры классов-
потомков могут принадлежать одновременно нескольким классам.
С учетом дополнительного использования стандартного
ограничения диаграмма классов может быть уточнена (рис.8.2.15).
Рис. 8.2.15. Вариант уточненного графического изображения отношения

обобщения классов с использованием строки-ограничения
Отношение агрегации
Агрегация (aggregation) – специальная форма ассоциации,
которая служит для представления отношения типа «часть-целое»
между агрегатом (целое) и его составной частью.
91
92
Отношение агрегации имеет место между несколькими

классами в том случае, если один из классов представляет собой
сущность, которая включает в себя в качестве составных частей
другие сущности. Данное отношение имеет фундаментальное
значение для описания структуры сложных систем, поскольку
применяется для представления системных взаимосвязей типа
«часть-целое». Раскрывая внутреннюю структуру системы,
отношение агрегации показывает, из каких элементов состоит
система, и как они связаны между собой.
С точки зрения модели отдельные части системы могут
выступать в виде, как элементов, так и подсистем, которые, в свою
очередь, тоже могут состоять из подсистем или элементов. Таким
образом, данное отношение по своей сути описывает декомпозицию
или разбиение сложной системы на более простые составные части,
которые также могут быть подвергнуты декомпозиции, если в этом
возникнет необходимость.
Очевидно, что рассматриваемое в таком аспекте деление
системы на составные части представляет собой иерархию, но
принципиально отличную от той, которая порождается отношением
обобщения. Отличие заключается в том, что части системы никак не
обязаны наследовать ее свойства и поведение, поскольку являются
самостоятельными сущностями. Более того, части целого обладают
собственными атрибутами и операциями, которые существенно
отличаются от атрибутов и операций целого.
Графически отношение агрегации изображается сплошной
линией, один из концов которой представляет собой не
закрашенный внутри ромб. Этот ромб указывает на тот класс,
который представляет собой «целое» или класс-контейнер.
Остальные классы являются его «частями» (рис. 8.2.16).
92
93
Рис. 8.2.16. Графическое изображение отношения агрегации в языке UML
В качестве примера отношения агрегации можно рассмотреть

взаимосвязь типа «часть-целое», которая имеет место между
классом System (Системный блок) персонального компьютера и его
составными частями: Processor (Процессор), Mother Board
(Материнская плата), Operative memory (Оперативная память),
HDD (Жесткий диск) и Floppy Disk (Дисковод гибких дисков).
Используя обозначения языка UML, компонентный состав
системного блока можно представить в виде соответствующей
диаграммы классов (рис. 8.2.17), которая в данном случае
иллюстрирует отношение агрегации.
Рис. 8.2.17. Диаграмма классов для иллюстрации отношения агрегации на

примере системного блока ПК
Класс может находиться в отношении агрегации с самим собой

(рис. 8.2.18).
93
94
Рис. 8.2.18. Агрегация класса с самим собой
Заметим, что признак кратности устанавливается на все

отношения. Если кратность не указывается в отношении агрегации,
то по умолчанию кратность устанавливается следующая – много
объектов класса «части» и один объект класса «целого».
На рис. 8.2.19 представлена диаграмма, на которой
изображено, что объект класса Order (Заказ) из одного объекта
класса ShippingInfo (Информация о посылке), одного объекта класса
BillingInfo (Информация о счете) и из одного или более объектов
класса Book (Книги).
Рис. 8.2.19. Пример отношения агрегации
94
95
Основным свойством отношения агрегации является то, что

классы-части системы являются самостоятельными сущностями и
не зависят от класса-целого. Другими словами, классы-части в
отношении агрегации могут выступать в отрыве от класса-целого.
Например, когда некоторый заказ осуществился, то информацию о
нем можно заархивировать, однако информация о счете и о
посылке, которые находится в объектах соответствующих классов,
которые находятся в отношении агрегации с объектом класса Order
(Заказ), остаются в системе.
Отношение композиции
Композиция (composition) – разновидность отношения
агрегации, при которой составные части целого имеют такое же
время жизни, что и само целое. Эти части уничтожаются вместе с
уничтожением целого.
Отношение композиции – частный случай отношения
агрегации. Это отношение служит для спецификации более сильной
формы отношения «часть-целое», при которой составляющие части
тесно взаимосвязаны с целым. Особенности этой взаимосвязи
заключаются в том, что части не могут выступать в отрыве от
целого, т.е. с уничтожением целого уничтожаются и все его
составные части, и, что часть может принадлежать только одному
целому.
Композит (composite) – класс, который связан отношением
композиции с одним или большим числом классов.
Графически отношение композиции изображается сплошной
линией (рис. 8.2.20), один из концов которой представляет собой
закрашенный внутри ромб. Этот ромб указывает на тот класс,
который представляет собой класс-композит. Остальные классы
являются его «частями».
95
96
Рис. 8.2.20. Графическое изображение отношения композиции
Возможно, самым наглядным примером этого отношения

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

примере класса-композита Окно программы
96
97
Зависимости
Зависимость – это отношение между двумя элементами, при
котором изменение одного элемента «supplier» (поставщика) может
затронуть другой элемент «client», «source» (клиент, источник) или
предоставить необходимую ему информацию.
Зависимость изображается в виде пунктирной стрелки, которая
связывает два класса. Тот класс, который находится у хвоста
стрелки (клиент), зависит от элемента, который находится у ее
наконечника (поставщик).
Рис. 8.2.22. Графическое изображение зависимости
Если определение класса Book изменится, то вероятнее всего,

это изменение повлияет на ход работы функции
checkAvailability(b:Book) (функция проверки годности книги для
включения в заказ) класса Order (рис. 8.2.22).
У стрелки может находиться ключевое слово, указывающее на
вид данной зависимости, а также имя этой зависимости
UML определяет некоторое множество стереотипов, которые
относятся к зависимостям.
Зависимости использования (usage dependencies)

Зависимости использования – это зависимость, при которой
для правильного функционирования или программной реализации
одного элемента (клиента) требуется присутствие другого элемента
(поставщика).
97
98
Рис. 8.2.23. Зависимость использования
Пример на рис. 8.2.23 показывает, что объекты класса Order

(Заказ) требуют присутствия объектов класса OrderItem (позиция
заказа) для нормального функционирования системы.
В UML определены следующие пять типов зависимости
использования:
 call dependency (зависимость использования вызова). С
помощью зависимости использования вызова моделируется
ситуация, в которой операция класса-клиента вызывает операцию
класса-поставщика. Эта ситуация представляется стереотипом
«call».
 create dependency (зависимость использования создания).
Эта зависимость, говорит о том, что клиентский класс создает
экземпляры класса-поставщика. Эта ситуация представляется
стереотипом «create».
На рис. 8.2.24 показано, что объекты класса Order (Заказ)
создают экземпляры класса Journal Entry (Ведение записей в
журнале).
Рис. 8.2.24. Зависимость использования создания (create dependency)
 instantiation dependency (зависимость использования

создания экземпляров). Это зависимость между классами,
указывающая на то, что операции в классе-клиенте создают
экземпляры класса-поставщика. Эта ситуация представляется
стереотипом «instantiate».
98
99
Рис. 8.2.25. Зависимость использования создания экземпляров

(instantiation dependency)
Метод, принадлежащий объекту класса HTMLPage Handler

(рис. 8.2.25) создает объект класса LoginPage.
 responsibility dependency (зависимость использования
обязанности «responsibility»). Это зависимость, выражающая
ответственность класса-клиента перед классом-поставщиком.
 send dependency (зависимость использования отправки
«send»). Это зависимость, источником которой является операция
или класс, а целью – сигнал. Зависимость показывает, что объекты
класса-клиента отправляет сигнал объектам класса-поставщика.
Зависимости абстрагирования (abstraction dependencies)

Зависимости абстрагирования – это зависимость, при которой
элемент-клиент принадлежит одному уровню абстракций, а
элемент-поставщик принадлежит другому уровню абстракции.
На рис. 8.2.26 показано, что класс SShoppingCart более
конкретизирован, нежели класс ShoppingCart.
Рис. 8.2.26. Зависимость абстракций
В UML определены следующие пять типов зависимости

абстрагирования:
 derivation dependency (зависимость вывода, «derive»).
Зависимость вывода указывает, что элемент-источник (клиент)
99
100
может быть вычислен или выведен на основе элемента-цели

(поставщик).
На рис. 8.2.27 изображен вывод ассоциации между классами
Order (Заказ) и Account (Счет).
Рис. 8.2.27. Зависимость вывода
 realization dependency (зависимость реализации, «realize»).

Эта зависимость указывает, что класс-цель обеспечивает
физическую реализацию класса-клиента.
На рис. 8.2.28 изображено, что класс Physical Order реализует
класс Order. В данном случае класс Physical Order представляет
собой некоторый программный компонент.
Рис. 8.2.28. Зависимость реализации
100
101
 refinement dependency ( зависимость уточнения, «refine»).

Зависимость уточнения указывает, что элемент-поставщик
специфицирован на более высоком уровне детализации, чем
элемент-клиент (рис. 8.2.29).
Рис. 8.2.29. Зависимость уточнения
 trace dependency (зависимость трассировки, «trace»). Эта

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

(Управление логинами), который принадлежит модели уровня
анализа, к классу SessionManager (Управление сессией), который
принадлежит модели уровня проектирования.
 manifestation dependency (зависимость манифестации,
«manifest»). Модели, используемые при разработке программного
обеспечения, в конце концом реализуются в виде артефактов
(например, файлов различного рода). Артефакты – это сущности,
размещаемые на физических узлах, таких как компьютеры и
101
102
устройства хранения. Очень важно отслеживать отображение

элементов модели на их реализацию в виде артефактов.
Манифестация – это отношение зависимости между элементом
модели и реализующим его артефактом. Один элемент модели
может быть реализован несколькими артефактами, а один артефакт
может реализовывать несколько элементов модели.
Зависимости разрешения и подстановки (Permission and

Substitution Dependencies)
Зависимость разрешения («permit») – это зависимость,

которая предоставляет клиенту разрешение на использование
содержимого поставщика (не зависимо от объявленной видимости
содержимых элементов).
Рис. 8.2.31. Зависимость разрешения
Класс Customer (Клиент) предоставляет классу

Recommendation Engine (Продвижение рекомендации) доступ к
своим частным (private) атрибутам emailAddress и name (рис.
8.2.31).
Зависимость подстановки («substitute») подразумевает
возможность подстановки класса-клиента вместо класса-
поставщика во время выполнения программы. В некоторых случаях
класс-поставщик задает контракт на взаимодействие (определяет
интерфейсы и порты), не указывая конкретные черты. Любой класс,
реализующий указанные интерфейсы и порты, может быть
102
103
подставлен вместо исходного класса, даже если у него совершенно

иные внутренняя структура и реализация.
Рис. 8.2.32. Зависимость подстановки
На рис. 8.2.32 более детализированная страница Login Page

использует основную структуру HTML-страницы.
Классы-ассоциации
Класс-ассоциация (association classes) – это ассоциация,
которая в то же время является и классом. У класса-ассоциации
присутствуют как свойства класса, так и свойства ассоциации. Он
связывает два или несколько классов и вместе с тем имеет атрибуты
и операции. Класс-ассоциация используется в том случае, когда у
каждой связи должны быть свои собственные значения атрибутов,
операции или ссылки на объекты.
Класс-ассоциация изображается с помощью символа класса
(прямоугольника), который соединяется пунктирной линией с
ассоциацией (рис. 8.2.33).
103
104
Рис. 8.2.33. Класс-ассоциация
Обычно между классами Author (Автор) и Book (Книга)

устанавливаются отношения многие ко многим, потому что, один
автор может написать более чем одну книгу, а одна книга может
иметь более одного автора. Присутствие класса-ассоциации
BookAndAuthor (Книга и автор) позволяет соединить одного автора
с одной книгой. Атрибут класса-ассоциации BookAndAuthor role
обеспечивает возможность определения – был ли автор главным,
соавтором или редактором.
8.3. Диаграммы классов и объектов
Центральное место в методологии объектно-ориентированного

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

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

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

происходит моделирование системы.
На рис. 8.3.1 изображен пример диаграммы классов уровня
определения требований, предметной области.
Рис. 8.3.1. Пример диаграммы классов внешнего уровня детализации
Расположение классов на приведенной диаграмме предлагает

их разделение на пять концептуальных групп. Начиная с верхнего
левого угла и перемещаясь по часовой стрелке, перечислим эти
группы следующие:
 PurchaseOrder (Заказ покупки), Shipment (Посылка) и Stock
(Склад);
106
107
 Category (Категория), Catalog (Каталог), Book (Книга),

BookAndAuthor (Книга и Автор) и Author (Автор);
 Customer (Клиент), Account (Счет), BillingInfo
(Информация об оплате) и ShippingInfo (Информация об отгрузке);
 Item (Элемент заказа), ShoppingCart (Покупательская
корзина), Order (Заказ) и OrderHistory (История заказа);

 GLAccount (Учетная запись в книге бухгалтерского учета).
Диаграмма классов уровня анализа требований

На диаграмме классов уровня анализа требований обычно
указываются атрибуты сущностей предметной области, которые
были определены на предыдущем этапе. На диаграмме можно также
показать другие дополнительные специальные символы, например,
кратность и названия ролей и т. д. Диаграмма классов уровня
анализа требований не должна содержать операций классов,
поскольку принятие решения о том, для каких классов и какие
операторы будут определены, лежит в основе построения диаграмм
классов уровня реализации требований.
На рис. 8.3.2 приведен пример диаграммы классов уровня
анализа требований.
Из примера (рис. 8.3.2) видно, что диаграмма классов
находится на начальном этапе построения, поскольку не для всех
классов определены атрибуты, а для тех классов, у которых
существует некоторый набор атрибутов, этот набор не полный.
Разработка диаграмм – это процесс, который является постепенным,
т.е. диаграммы развиваются по ходу разработки, поскольку
возрастают знания о предметной области.
Специальное обозначение {encrypted} (зашифрован), которое
присоединено к атрибуту password (пароль) класса Account (Счет)
означает определенное пользователем ограничение на данные,
которое указывает на то, что пароль подвергается шифрованию
прежде, чем он сохраняется в системе. Это некоторое решение
проектирования, реализации требований, но так как это решение
107
108
существует на уровне атрибута, то имеет смысл включать такие

ограничения на диаграмму классов на данном уровне детализации.
Рис. 8.3.2. Пример диаграммы классов уровня анализа требований
Диаграмма классов уровня реализации требований

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

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

требований – это просто более расширенная версия диаграммы
классов уровня анализа требований. Следующий пример,
109
110
представленный на рис. 8.3.3, расширяет версию диаграммы

классов уровня анализа с помощью добавления в нее операторов
классов.
На рис.8.3.4 детализируются некоторые классы уровня анализа
требований, которые связаны с классом ShoppingCart.
Новый класс ShoppingCart (Покупательская корзина) – это
HTML-страница, которая состоит из статической формы,
отображающая содержимое корзины, и Java-аплета, который
позволяет клиенту изменять содержимое этой корзины.
Класс CandidateOrder – JavaServer страница (JSP), который
получает необходимую информацию от HTML-страницы
ShoppingCart, и сохраняет информацию на сервере в формате,
подходящем для дальнейшей обработки системой.
Рис. 8.3.4. Диаграмма классов более высокого уровня детализации
Класс SShoppingCart – модуль Enterprise JavaBean, который

существует пока клиент помещает товары в покупательскую
корзину. В этот момент система создает «постоянный» EJB модуль
с именем EOrder, представляющий собой оконную форму; с
помощью которой осуществляется заказ.
На рис. 8.3.5 показана детализация класса ShoppingCart,
представленного на рис. 8.3.4.
110
111
Рис. 8.3.5. Диаграмма классов низкого уровня
Классы, представленные на рис. 8.3.5:

 Remote – суперкласс всех интерфейсов, через которые
клиенты имеют удаленный доступ к EJBs.
 EnterpriseBean – суперкласс EntityBean и SessionBean.
 EJBHome определяет операции типа создать и удалить для

EJB.
EJBObject определяет операции чтобы обратиться к


данным EJB.
ShoppingCartIF содержит определяемые пользователем


операции для EJB.
SessionBean – форма EJB, который существует только во

время сеанса системы с клиентом.
 ShoppingCartHome – интерфейс на «фабрику», которая

создает образцы EJB.
111
112
ShoppingCart – интерфейс к EJB. ShoppingCart предлагает

операции, определенные в EJBObject и ShoppingCartIF, через
множественное наследование
ShoppingCartBean осуществляет операции, предложенные

ShoppingCartIF.
Диаграмма объектов
Диаграмма объектов показывает набор объектов и отношений
между ними в конкретный момент времени функционирования
системы. Рис. 8.3.7. представляет пример диаграммы объектов.
Рис. 8.3.7. Диаграмма объектов
На диаграмме объектов изображено множество объектов и

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

внутренняя структура (части и соединители) структурированного
классификатора или кооперации. Композитная структура описывает
взаимосвязи объектов в определенном контексте, благодаря
которым из этих объектов образуется цельная сущность, имеющая
некоторое предназначение.
Таблица 2
Графическая нотация элементов диаграммы композитной структуры
Тип узла Нотация Описание
Элемент структурного классификатора,
partName: представляющий объект или множество
Part (часть) ClassName объектов в контекстуальном
взаимоотношении
Структурная характеристика
классификатора, скрывающая
portName:
взаимодействие между содержимым
Port (порт) ClassifierName
классификатора и внешней средой.
Точка соединения классификатора и
внешней средой
Описание структуры. По форме
кооперация представляет собой
структурированный классификатор.
Collaboration
Collaboration
Name Поведение кооперации может
(кооперация)
задаваться взаимодействиями,
изображающими потоки сообщений в
рамках кооперации.
Collaboration
Use
usageName: Использование кооперации в связи с
Collaboration
(кооперация
Name конкретными частями контекста
применения)
Connector ________________ Соединение двух структурированных
(коннектор) частей структурированного
классификатора или кооперации;
спецификация ассоциации, которая
применима только в определенном
113
114
контексте
Связывающий составной элемент
структурного классификатора,
описывающий появление экземпляра
Role binding (или множества экземпляров) в
(связывающая ___________ контексте, определяемом структурой
роль) классификатора. Представление
индивидуума в контексте,
определяемом структурным
классификатором.
Примеры диаграммы композитной структуры

На рис. 9.1 показан класс TV Viewer (Телевизор) вместе с
интерфейсами, которые он предоставляет и которые требует. В
данном случае класс показан двумя способами: с помощью шарово-
гнездовой нотации и с помощью перечисления внутри объекта.
Рис. 9.1. Два способа представления объекта TV Viewer и его интерфейсов
На рис. 9.2 показан тот же класс, разбитый внутри на две

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

части. На рис. 9.2 показано, что каждый объект TV Viewer содержит
один генератор (Generator) и один блок управления (controls).
Чтобы обозначить часть, реализующую интерфейс, надо
нарисовать разъем, предоставляемый этим интерфейсом.
Аналогично, чтобы показать часть, нуждающуюся в интерфейсе,
надо нарисовать разъем, предоставляемый этому интерфейсу. Кроме
того, разъемы между частями можно показать или с помощью
простой линии, как сделано в данном случае, или с помощью
шарово-гнездовой нотации.
Рис. 9.2. Внутренний вид компонента
115
116
Рис. 9.3. Компонент с несколькими портами

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

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

пакета. Если пакет удаляется, то уничтожается и принадлежащий
ему элемент. Элемент может принадлежать только одному пакету.
Хорошо спроектированный пакет группирует семантически
близкие элементы, которые имеют тенденцию изменяться
совместно. Таким образом, хорошо структурированные пакеты
слабо связаны и обладают четко выраженной семантикой.
Каждый элемент модели, который не является при этом
частью другого элемента модели, должен быть объявлен
исключительно в одном пространстве имен. Говорят, что элемент
принадлежит пространству имен, в котором хранится его
объявление. Пакет – это пространство имен общего назначения,
которому может принадлежать элемент модели любого вида, если
только для этого элемента не ограничен вид владельца. Пакет
может содержать вложенные пакет и обычные элементы. Обычно
имеется один корневой пакет, которому принадлежит модель
системы в целом.
Модель является разновидностью пакета.
Пакет представляет собой общий механизм организации
элементов модели и диаграмм в группы. Его изображают в виде
папки с закладкой. Существует три способа представления пакета:
 Имя пакета изображается в теле папки, а содержание папки
скрыто из вида (рис.10.1).
Рис. 10.1. Изображение пакета
117
118
 Имя пакета изображается в рамках закладки, и содержимое

пакета показывается в теле папки (рис. 10.2).
 Имя пакета появляется в теле папки, а содержимое

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

пакетов. Имя – это текстовая строка. Имя пакета должно быть
118
119
коротким и простым, оно должно передать сущность содержимого

пакета. К составному имени спереди добавлено имя объемлющего
его пакета, если таковой существует. Имя пакета должно быть
уникальным в объемлющем пакете.
Мы также можем указать видимость элементов в пределах
пакета. Доступны следующие обозначения: «public» (+), что
означает, что любой другой элемент модели может «видеть»
данный элемент, и «private» (-), что означает, что только элементы в
пределах того же самого пакета могут видеть данный элемент.
Импорт и доступ (import and access)

Пакеты являются основной для управления конфигурацией,
хранения и управления доступом. Каждый элемент может
непосредственно принадлежать другому элементу модели или
одному пакету, поэтому иерархия принадлежности представляет
собой дерево. Элементы модели (в том числе, и пакеты) могут
ссылаться на другие элементы в других пакетах, таким образом,
схема их использования представляет собой граф.
Между пакетами могут существовать отношения зависимости.
В большинстве случаев они обобщают зависимости, которые
существуют между содержимым этих пакетов. Если между двумя
пакетами есть зависимость использования, это означает, что
существует, по меньшей мере, одна такая зависимость между парой
элементов этих пакетов (однако не между каждой парой элементов).
В пакет можно добавить элементы модели из других пакетов,
используя ссылку на них. Если видимость элемента из другого
пространства имен определена как «public», то пакету
предоставляется возможность импортировать данный элемент. Если
видимость элемента определена как «private», то пакету
предоставляется возможность доступа к нему. Оба типа отношений
– импорта «import» и доступа «access» – представляются как
стереотипы отношения зависимости с пакетом, получающим
импортированный элемент или доступ к элементу (рис. 10.4).
119
120
Рис. 10.4. Пример изображения зависимостей импорта и доступа
Элемент импортирующего пакета может использовать имена

импортированных элементов так, как если бы они были определены
внутри его самого. Однако заметим, что если пакет импортирует
элемент с именем, которое существует у элемента, вложенного в
этот пакет, то импорт должен осуществляться с ассоциированным
псевдонимом (associated alias). На рис. 10.5 представлен пример
импорта с таким псевдонимом.
Рис. 10.5. Импорт с ассоциированным псевдонимом

120
121
Пакет WebServer обращается к классу Book (Книга), который

принадлежит пакету Catalog (Каталог), и импортирует этот класс
по псевдониму CatalogBook.
Зависимости импорта и доступа работают аналогичным
образом и на уровне пакетов.
Рис. 10.6. Импорт пакетов
В результате приведенного на рис. 10.6 импорта, пакет

WebServer может рассматривать классы Book и Author как
вложенные в него элементы.
Импорт дает элементам одного пакета односторонний доступ к
элементам другого.
Специальный случай импорта пакета представляет стереотип
«modelLibrary». Этот стереотип показывает, что пакет клиента
использует исходный пакет как библиотеку доступных элементов
модели. Например, имеется пакет datatypes (типов данных),
который следует сделать доступным для других пакетов.
Объединение (слияние) пакетов (package merge)

Объединение пакетов – это особенность UML, которая
позволяет объединять содержания целевых пакетов в один
исходный пакет. Это полезно в том случае, когда элементы под
одинаковыми именами, в разных пакетах, предназначены для
представления идентичных сущностей.
121
122
Рис. 10.7. Объединение пакетов
Результатом объединения пакетов является комбинирование

их содержимого, используя механизмы обобщения и
переопределения. При этом применяются следующие основные
правила:
 все существующие отношения сохраняются;
 каждый элемент пакетов, участвующих в объединении, в
предполагаемом новом пакете приобретают новые базовые
элементы, которые является родительскими для них и которые
обладают аналогичным именем и представляют идентичные
сущности. При этом для первых используются квалифицированные
имена, а именно package name: element name. Это необходимо,
потому что элементы суперкласса, возможно, обладают
дополнительными свойствами, которые должны быть распределены
по элементам-подклассам.
Диаграммы пакетов (package diagram)

Диаграмма пакетов – это структурная диаграмма, основным
содержанием которой являются пакеты и отношения между ними.
На рис. 10.8. продемонстрирована диаграмма пакетов, в
которой объединены пять пакетов.
122
123
Диаграммы пакетов удобны в больших по размерам

программных системах для представления зависимостей между
основными компонентами системы. Такие диаграммы хорошо
соответствуют общепринятым программным структурам.
Разработка диаграмм пакетов и зависимостей помогает держать под
контролем зависимости приложения. Пакеты представляют
группирующий механизм при структуризации программной
системы.
11. Представление проектирования. Компоненты
Компонент (Components) представляет собой модульный

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

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

как business компоненты и компоненты процесса, и физические
компоненты, такие как компоненты Enterprise Java Beans (EJBs),
Common Object Request Broker Architecture (CORBA), и COM+ и
.NET компоненты.
Отношения между компонентами могут задаваться в форме
зависимостей между интерфейсами. Интерфейсы компонента
описывают функциональные возможности, которые он
поддерживает. Интерфейсы могут быть двух типов: обеспеченные и
требуемые. Обеспеченный интерфейс описывает операции, доступ к
которым компонент гарантирует (другим компонентам). Каждой
операции такого интерфейса должен соответствовать элемент
реализации, поддерживаемый компонентом. Требуемый интерфейс
описывает функциональность, которая поставляется другими
компонентами.
На рис. 11.1 демонстрируется пример компонента с двумя
типами интерфейсов. Компонент изображается в виде
прямоугольника с ключевым словом «component».
Рис. 11.1. Компонент
На рис. 11.2. показано иное графическое изображение

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

порты (ports).
Рис. 11.2. Компонент
Компонент находится в отношениях реализации (realization

dependency) с одним или более классами, реализующие свои
интерфейсы, которые обеспечиваются этим компонентом.
Эти отношения имеют такой же вид, как и отношения между
классом и его интерфейсами. На рис. 11.3 показан пример
зависимости реализации.
Рис. 11.3. Зависимость реализации (Realization dependency)
При применении компонентов используется два типа

соединителей (connectors):
126
127
Делегирующий соединитель (delegation connector) связывает

внешний порт компонента с портом одного из его внутренних
субкомпонентов. Сообщение от внешнего источника, принятое во
внешнем порту, передается в порт внутреннего компонента;
сообщение от внутреннего источника, принятое во внутреннем
порту, передается во внешний порт и тем самым в соединенный с
ним компонент. Делегирующие соединители должны связывать
требуемые элементы с требуемыми, а обеспеченные – с
обеспеченными.
Соединитель сборки (assembly connector) подключает
требуемый интерфейс или порт на одном компоненте к
обеспеченному интерфейсу или порту на другом компоненте.
Соединитель сборки – это первичный механизм для того, чтобы
связать компоненты вместе на диаграммах компонентов (component
diagrams).
Диаграмма компонентов (Component Diagrams) – это

диаграмма, на которой показаны определения, внутренняя
структура и зависимости типов компонентов. На этой диаграмме
изображаются также интерфейсы.
На рис. 11.4. изображены набор Java-сервлетов (Java Servlets),
которые определены на Web-сервере, используя стереотип «servlet».
Элементами на данной диаграмме являются:
Book Details (детали книги) позволяет найти и вывести
информацию о книге, например, описание обложки книги, краткое
содержание, цену, и различные мнения о книги, когда Клиент хочет
видеть подробности об определенной книге.
Book Base (книжная база) содержит список всех доступных
книг; другие сервлеты вызывают эту базу для получения
информации о книгах.
Catalog (каталог) предоставляет результаты запросов
клиентов поиска и просмотра книг.
127
128
Рис. 11.4. Диаграмма компонентов
Login (вход в систему) обрабатывает вход в систему Клиента.

Main Page (главная страница) – первая страница, которую
клиент обозревает, когда он заходит на сайт книжного магазина.
Purchasing (покупка) осуществляет преобразование корзины
покупок в заказ, а также взаимодействует с внешними
финансовыми объектами, которые разрешают или блокируют
выполнение операций по кредитным карточкам клиентов.
Shopping Cart View (просмотр корзины покупок) позволяет
управлять содержимым корзины покупок клиента.
Рис. 11.5 содержит набор компонентов, которые определены
для отдельного серверного приложения.
Элементами данной диаграммы являются:
Book (книга) – это объектный модуль (entity bean), который
содержит информацию о книгах, в частности, ISBN книги, название
книги и ее авторов, содержание, краткое описание книги, цена по
прейскуранту и т.д.
Cart Line Item (товар, помещенный в корзину) – модуль
(stateful session), который содержит указатель на определенные
128
129
книги в корзине покупок, заказываемое количество книг, и скидки

на покупку книг.
Рис. 11.5. Диаграмма компонентов для серверного приложения
Customer (клиент) – модуль (stateful session), который

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

модуль, содержащий аналогичную информацию с модулем Cart
Line Item.
Pricer (кассир) – это модуль (stateless session), который
вычисляет стоимость каждой книги, помещенной в корзину
покупок клиента, на основе цен по прейскуранту, скидок на книги и
их количества.
Shopping Cart (корзина покупок) – это модуль (stateful session),
который содержит указатели на книги, которые клиент хочет
приобрести.
Диаграммы компонентов обычно помещаются в собственные
пакеты, например, как показано на рис. 11.6.
Рис. 11.6. Применение пакетов.
130
131
Стереотипы компонентов
Следующие встроенные стереотипы (Component Stereotypes)
могут оказаться полезными при определении компонентов:
Стереотип «entity» определяет постоянно хранимый
информационный компонент, представляющий некоторое понятие в
бизнес сфере.
Стереотип «process» определяет компонент, основанный на

транзакциях.
Стереотип «service» определяет компонент без состояния,
который возвращает значение.
Стереотип «implement» определяет компонент,
обеспечивающий реализацию конкретной спецификации, от
которой он зависит.
Стереотип «buildComponent» определяет компонент,
назначающий набор компонентов для разработки на
организационном или системном уровне.
Артефакты и манифестации (Artifacts and Manifestations)

Артефакт – это спецификация физического элемента
информации, используемого или порождаемого в процессе
разработки программного обеспечения (например, им может быть
внешний документ или рабочий продукт). Артефактом может быть
модель, описание и др. Артефакт соответствует конкретному
элементу реального мира.
Артефакт изображается в виде прямоугольника с ключевым
слово «artifact» над его именем (рис. 11.7).
131
132
Рис. 11.7. Артефакты
Артефакт может содержать в себе другие артефакты. С

вложенными артефактами композитный артефакт находится в
отношении композиции (composition relationship).
Манифестация – это физическая реализация элемента модели
в идее артефакта.
Артефакты – это сущности, размещаемые на физических
узлах, таких как компьютеры и устройства хранения. Очень важно
отслеживать отображение элементов модели на их реализацию в
виде артефактов. Манифестация – это отношение между элементом
модели и реализующим его артефактом. Отношение манифестации
обозначается стрелкой зависимости (пунктирной стрелкой),
направленной от артефакта к элементу модели, с ключевым словом
«manifest».
Рис. 11.8. Манифестация
На рис. 11.8. изображено, что класс Order (Заказа),

изображенный на рис. 11.7., реализован в Java-файле Order.jar.
Следующие встроенные стереотипы могут оказаться
полезными при определении артефактов:
Стереотип «document» определяет компонент,
представляющий документ. Данный компонент – артефакт
содержит полезную информацию о моделируемой системе.
Стереотип «executable» определяет программный файл,
который может выполняться в компьютерной системе.
Стереотип «file» определяет физический файл в контексте
системы.
132
133
Стереотип «library» определяет артефакт, который

представляет статическую и динамическую библиотеку.
Стереотип «script» определяет артефакт, который представляет
собой файл, содержащий текст, допускающий интерпретацию
компьютерной системой.
Стереотип «source» определяет артефакт, который
представляет собой файл, содержащий текст программы и который
может быть скомпилирован в исполняемый код.
12. Представление развертывания
Узлы (Nodes) – это физический объект, существующий во

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

которые обозначают коммуникационные маршруты. На рис. 12.1.
изображены два экземпляра узлов, связанные коммуникационным
маршрутом.
В UML определены два вида узлов.
Устройство (device) – это физический вычислительный
ресурс с возможностями обработки, на котором могут
развертываться артефакты для выполнения (рис. 12.2).
Рис. 12.2. Устройства
Устройство может содержать в себе другие устройства. С

вложенными устройствами композитное устройство находится в
отношении композиции (composition relationship).
Среда выполнения (execution environment) – это узел,
представляющий конкретную платформу, на которой происходит
выполнение, – операционную систему, систему управления
технологическим потоком, СУБД и т.д.
Рис. 12.3.Среда выполнения

134
135
Среда выполнения моделирует программно-аппаратное

окружение, предоставляющее набор стандартных услуг, которые
могут использоваться компонентами приложений (рис. 12.3).
Развертывание (Deployment)
Узлы представляют собой размещение, топологию
программных артефактов – другими словами, это
месторасположение артефактов в период выполнения. Артефакт,
который существует в определенном узле, называют размешенным
артефактом.
Детали развертывания могут быть заданы в спецификациях
развертывания, которые определяют набор свойств, например,
указано место развертывания на узле и параметры выполнения. На
рис. 12.4 приведен пример спецификации развертывания.
Рис. 12.4. Спецификация развертывания
Диаграммы развертывания
Диаграмма развертывания (топологии) (Deployment
Diagrams) – это диаграмма, на которой изображается конфигурация
работающих узлов и артефактов, развернутых на них. На рис. 12.5.
приведен пример использования пользовательских стереотипов.
135
136
Обычно диаграмму развертывания помещают в пакет,

содержащий все диаграммы развертывания, как показано на
рис. 12.6.
Рис. 12.5. Диаграмма развертывания
136
137
Рис. 12.6. Пакет развертывания

Каркасы, подсистемы и системы (Frameworks, Subsystems,
and Systems)
Использование стереотипа «frameworks» показывает, что
содержимое данного пакета представляет архитектурный образец,
который обеспечивает расширяемый шаблон для приложений
внутри предметной области. Каркас является отправной точкой для
конструирования архитектуры. На рис. 12.7. приведен пример
каркаса.
137
138
Рис. 12.7. Каркас
На рис. 12.7 кооперация интерфейс клиента (Customer

Interfaces collaboration) представляет шаблоны визуальной части,
кооперация процесс заказа (Order Processing) представляет
управленческую часть шаблона, база учета и база товаров
представляет модельную часть.
Стереотип «subsystem» определяет часть проекта системы –
подсистему. Она может иметь свою собственную спецификацию и
реализацию.
Стереотип «systemModel» определяет, что пакет содержит
множество моделей, которые, взятые вместе, составляют модель
всей системы. На рис. 12.8 представлен пример с тремя
подсистемами, объединенными в одну целую систему.
138
139
Рис. 12.8. Подсистемы
139
Заключение
В настоящее время полностью специфицирована и
документирована версия 2.0 языка UML и продолжается
дальнейшая работа по его развитию. Имеются ссылки на версию
языка UML 2.1.
В настоящее время разработкой программных
инструментальных систем с реализацией языка UML 2.0
занимаются более 300 фирм производителей программного
обеспечения. Среди них можно назвать IBM Rational Software Corp.,
Gentleware AG, Pacestar Software, Visual Paradigm, Sparx Systems,
Metamill Software и другие. Перспективность и выгодность
использования языка UML при разработке программных систем уже
доказана. Изучение визуальных средств моделирования
необходимо. В общем случае средства моделирования позволяют
понимать методы, подходы, методологии решения задач,
необязательно связанных с разработкой программных систем.
В этом пособии описаны основные аспекты элементов языка
UML версии 2.0.
Для подробного изучения описания языка UML лучше всего
использовать спецификацию Unified Modeling Language:
Superstructure version 2.1 и Unified Modeling Language: Infrastructure
version 2.1. В них содержится более детальное описание элементов
языка UML.
Источниками информации по языку UML в Интернете
являются сайты компании IBM партнер Rational www.rational.com,
www-306.ibm.com/software/rational, www.ibm.com, www.uml.org со
стороны которой осуществляется общая координация работы над
очередными версиями языка UML. Эта компания продолжает
разработку CASE-средства Rational Rose, в котором реализуются
текущие дополнения языка UML для различных платформ.
Уже сейчас язык UML становится тем связующим языком, на
котором могут общаться между собой руководители
информационных служб, менеджеры проектов, системные
Заключение 136
аналитики, бизнес-аналитики, программисты, тестировщики,

математики, экономисты, физики и специалисты других профессий,
представляя свои профессиональные знания в унифицированном
виде. Ведь, по существу, каждый из специалистов оперирует
модельными представлениями в своей области знаний. И именно
этот модельный аспект может быть специфицирован и
документирован средствами языка UML.
В связи с этим значение языка UML неуклонно возрастает,
поскольку он все более приобретает черты языка представления
знаний. При этом наличие в языке UML средств для изображения
структуры и поведения модели позволяет достичь адекватного
представления декларативных и процедурных знаний и, что не
менее важно – установить между этими формами знаний
семантическое соответствие.
Все эти особенности языка UML позволяют сделать вывод о
том, что он занимает лидирующее положение среди графических
нотаций моделирования и документирования программных систем
и бизнес-процессов.
Литература
[1] James Rumbaugh, Ivar Jacobson, Grady Booch. Unified Modeling
Language Reference Manual, The, 2nd Edition. Addison Wesley
Professional, 2004.
[2] Martin Fowler. UML Distilled, 3rd ed. Addison-Wesley, Boston,
2004.
[3] Kendall Scott. Fast Track UML 2.0. Apress, Berkeley, CA. 2004.
[4] Michael Blaha, James Rumbaugh. Object-Oriented Modeling and
Design with UML, 2nd edition. Prentice Hall, Upper Saddle River,
N.J., 2005.
[5] Unified Modeling Languages Specification, Version 2.0. Object
Management Group, Framingham, Mass. 2004. Internet: www.omg.org.
[6] Unified Modeling Language: Superstructure, Version 2.0. Object
Management Group, ptc/03-07-06, Internet: www.omg.org.

SVM Strukturnye Diagrammy 14

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SVM Strukturnye Diagrammy 14

Загружено:

Авторское право:

Доступные форматы

Казанский государственный университет

И.Н. Исмагилов, Л.Н. Исмагилов, Н.А. Исмагилов

СРЕДСТВА ВИЗУАЛЬНОГО МОДЕЛИРОВАНИЯ

Исмагилов И.Н., Исмагилов Л.Н., Исмагилов Н.А.

В настоящем пособии описывается унифицированный язык

© Казанский государственный университет

Часть 2. Структурные диаграммы унифицированного языка

«Программирование – одна из наиболее

Эдстер Вайб Дейкстра (Edsger Wibe

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

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

решении задачи, сфокусировать свое внимание на реализации

Диаграммы компонентов представляют компоненты.

1. Модель программной системы

Под моделью программной системы (ПС) в общем случае

систем повышается, важно располагать хорошими методами

Объектно-ориентированная разработка программного

Процесс объектно-ориентированной разработки и системы

1 этап. Концептуализация системы. Разработка программного

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

будут переходить от одного этапа к другому без всяких изменений в

Для описания системы с различных точек зрения используются

состояний, взаимодействия), но и этапом разработки

определяющие контекст событий, и упорядочение событий и

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

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

Концептуальной основой объектно-ориентированного анализа

Большинство современных методов ООАП основаны на

 обеспечить независимость от конкретных языков

Строительные блоки UML

Класс (Class) – это описание совокупности объектов с общими

Рис. 5.1 Класс

Интерфейс (Interface) – это совокупность операций, которые

Рис. 5.2. Интерфейс

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

Рис. 5.3 Кооперация

Прецедент, вариант использования (Use case) – это описание

Рис. 5.4 Прецедент, вариант использования

Три другие сущности – активные классы, компоненты и узлы –

Рис. 5.5 Активный класс

Два оставшихся элемента – компоненты и узлы – также имеют

физическую упаковку логических элементов, таких как классы,

Рис. 5.6 Компоненты

Совокупность компонентов может размещаться в узле, а также

Рис. 5.7 Узлы

Эти семь базовых элементов – классы, интерфейсы,

процессы и нити (виды активных классов), приложения, документы,

Рис. 5.8 Сообщения

Автомат (State machine) – это алгоритм поведения,

Рис. 5.9. Состояние

Рис. 5.10 Пакеты

Пакеты – это основные группирующие сущности, с помощью

вариации пакетов, например каркасы (Frameworks), модели и

Рис. 5.11 Примечание

Этот элемент является основной аннотационной сущностью,

Эти отношения являются основными связующими

Рис. 5.12 Зависимости

Ассоциация (association) – структурное отношение,

Рис. 5.13 Ассоциации

Обобщение (Generalization) – это отношение «специализация /

отношение обобщения изображается в виде линии с не закрашенной

Рис. 5.14 Обобщения

Отношения реализации встречаются в двух случаях: во-