Новиков Ф.А. Учебно-методическое пособие по дисциплине Анализ и проектирование на UML

Подождите немного. Документ загружается.

Кооперация

Collaboration

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

Use case

Компонент

Component

Узел

Node

Состояние

State

Деятельность

Activity

Развилка / слияние

Ветвление / соединение

Пакет

Package

Примечание

Note

Ортогональные системы обозначений

Очень хорошо, если система обозначений такова, что все ее элементы

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

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

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

ортогональной системой векторов в векторном пространстве.

Действительно, ортогональная система образует базис, т.е. любой

вектор можно выразить в виде

линейной комбинации векторов базиса,

причем это выражение единственно. Это удобно.

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

ортогональными системами обозначений: как вы, несомненно, знаете,

один и тот же алгоритм можно запрограммировать очень и очень по

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

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

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

десятилетие очевиден, но идеал пока не достигнут.

UML также далек от идеала. Некоторые элементы абсолютно

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

но есть и такие, которые автору, вслед за

Э. Дейкстрой, хочется отнести

к "свистулькам и погремушкам".

1.4.2. Отношения

В UML используются четыре основных типа отношений:

• зависимость;

• ассоциация;

• обобщение;

• реализация.

Зависимость — это наиболее общий тип отношения между двумя сущностями,

Отношение зависимости указывает на то, что изменение независимой сущности

каким-то образом влияет на зависимую сущность. Графически отношение

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

независимой сущности к зависимой. Как правило, семантика конкретной

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

Например, зависимость со стереотипом «use» означает, что зависимая сущность

использует (скажем, вызывает операцию) независимую сущность.

Ассоциация — это наиболее часто используемый тип отношения между

сущностями. Отношение ассоциации имеет место, если одна сущность

непосредственно связана с другой (или с другими — ассоциация может быть не

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

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

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

главное, что ассоциированные сущности знают друг о друге. Например, отношение

часть–целое является частным случаем ассоциации и называется отношением

агрегации.

Обобщение — это отношение между двумя сущностями, одна их которых является

частным (специализированным) случаем другой. В UML отношение обобщения

подразумевает выполнение

принципа подстановочности: если сущность А (общее)

суть обобщение сущности Б (частное), то Б может быть подставлено вместо А в

любом контексте. Принцип подстановочности правомерен, поскольку обобщение

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

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

стрелки с

треугольником на конце, направленной от частного к общему.

Отношение наследования между классами в объектно-ориентированных языках

программирования является типичным примером обобщения.

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

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

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

класс является реализацией интерфейса. Графически реализация изображается в

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

сущности к реализуемой.

Перечисленные типы отношений являются основными, различные их вариации и

дополнительные отношения детально рассматриваются в последующих главах.

О важности правильных обозначений

Нельзя не отметить тщательность выбора графической нотации в UML.

Если основные принципы поняты, то обозначения оказываются вполне

естественными. Рассмотрим, например, нотацию отношений. Два типа

линий подчеркивают степень определенности семантики, привносимой

отношением в модель. Ассоциация и обобщение имеют четко

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

поэтому и линии сплошные. Зависимость и

реализация более

расплывчаты — линии используются пунктирные. Далее, направления

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

образом. Независимая сущность может и не знать, что ее использует

другая сущность, а вот зависимая сущность не может не знать, от чего

она зависит. Эта аналогия уместна и для обобщения и реализации.

Например, описывая

наследование (которое часто реализуется

указателем в наследующем классе на наследуемый класс) в

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

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

становится явно видным. То же относится и к дополнительным

элементам стрелок: обобщение и реализация имеют много общего,

поэтому и наконечники стрелок у них одинаковые.

При рассмотрении

последующих (более детальных и содержательных)

примеров нотации читателю было бы полезно задавать себе вопрос:

"почему выбрано такое обозначение?" до тех пор, пока сам собой не

появится ответ: "а как же иначе!".

1.5. Диаграммы

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

лексики в обычном языке программирования. А именно, мы обрисовали (еще не

полностью, но уже достаточно) множество слов UML (лексем, графических

примитивов — называйте как хотите — фиксированного термина нет). Пора

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

предложения.

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

отношения между ними. В результате получается модель, то есть граф (с

разнородными вершинами и ребрами), нагруженный дополнительной

информацией. Но при более внимательном рассмотрении обнаруживаются

проблемы. Мы хотим затратить некоторые усилия на обсуждение этих проблем,

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

самом деле, эти особенности и есть продуманное решение замалчиваемых обычно

проблем.

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

сущность — отношение — сущность в модели вполне может рассматриваться как

простое утверждение: 2<5, ртуть тяжелее железа, Ф.А. Новиков является

сотрудником Политехнического университета (все это примеры отношений). Пока

все хорошо, но вспомним, что в графе (в модели) никакой упорядочивающей

структуры нет: нельзя сказать, что это вершина первая, а это — вторая. Продолжая

нашу аналогию, получается, что модель — это множество несвязанных между

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

современной литературе будь сказано. Если взять какой-нибудь "нормальный"

текст,

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

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

предложения объединены в абзацы, абзацы собраны в параграфы и главы, у

которых есть заголовки, помимо обычных абзацев и заголовков есть врезки и

сноски. И все эти дополнительные структуры по сути ничего не добавляют к

содержанию книги, но серьезно влияют на ее читабельность. Текст, в котором нет

этих структур, понять очень трудно.

Отсюда вывод: помимо сущностей и

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

составлению и пониманию.

Диаграммы UML и есть та основная накладываемая на модель структура, которая

облегчает создание и использование модели.

Диаграмма — это графическое представление некоторой части графа модели.

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

комбинации сущностей и отношений, но произвол в этом вопросе затруднил бы

понимание моделей. Поэтому авторы UML определили набор рекомендуемых к

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

диаграмм.

ЗАМЕЧАНИЕ

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

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

отойти от канона ни на шаг, даже если эту нужно по сути задачи. С другой стороны,

некоторые инструменты (например, Together) наряду с каноническими

поддерживают и апокрифические типы диаграмм. Было бы удобно, если бы набор

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

настроить, изменить и переопределить этот набор в случае необходимости, примерно

так, как это делается с шаблонами Word.

1.5.1. Классификация диаграмм

В UML 1.x всего определено 9 канонических типов диаграмм. Ниже перечислены

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

• Диаграмма использования

• Диаграмма классов

• Диаграмма объектов

• Диаграмма состояний

•

Диаграмма деятельности

• Диаграмма последовательности

Скажем эту книгу — не в качестве образца, а в качестве примера.

Смеем вас уверить, что писать структурированный текст также намного легче.

• Диаграмма кооперации

• Диаграмма компонентов

• Диаграмма размещения

Этот список является итогом многочисленных дискуссий и компромиссов, поэтому

не следует воспринимать его как догму. В частности, расхожее утверждение "в

UML определены 9 типов диаграмм" является не совсем верным: в метамодели

UML определены элементы модели (сущности и отношения) и способы их

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

отражающая сложившуюся практику его использования.

Канонические диаграммы отнюдь не образуют полного ортогонального набора:

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

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

есть просто семантические эквивалентные пары, можно привести примеры

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

именно из канонических типов диаграмма относится.

Сказанное можно проиллюстрировать условной классификацией диаграмм,

приведенной на рис. 1.6.

Диаграмма

{root}

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

Поведенческая

Структурная

Классов Объектов

Реализации

Компонентов

Размещения

Состояний

Деятельности

Взаимодействия

Последовательности

Кооперации

Рис. 1.6. Иерархия типов диаграмм.

ЗАМЕЧАНИЕ

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

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

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

представляется некоторой натяжкой.

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

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

изложения. Детали изложены в остальных главах книги.

1.5.2. Диаграмма использования

Диаграмма использования — это наиболее общее представление функционального

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

вопрос моделирования: что делает система во внешнем мире?

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

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

следующие основные типы отношений:

•

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

•

обобщение между действующими лицами;

• обобщение между вариантами использования;

• зависимости (различных типов) между вариантами использования.

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

графический комментарий — обозначить границу системы (действующие лица

находятся снаружи, а варианты использования — внутри), если это почему-либо не

очевидно.

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

на рис. 1.7.

Рис.1.7. Нотация диаграммы использования (UML 2.0)

1.5.3. Диаграмма классов

Диаграмма классов — основной способ описания структуры системы. Это не

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

являются основным (если не единственным) "строительным материалом" системы.

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

(включая многочисленные частные случаи классов: интерфейсы, типы, классы-

ассоциации и многие другие), между которыми устанавливаются следующие

основные типы отношений:

•

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

• обобщение между классами;

• зависимости (различных типов) между классами и интерфейсами.

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

рис. 1.8.

Рис. 1.8. Нотация диаграммы классов

1.5.4. Диаграмма объектов

Диаграмма объектов — это частный случай диаграммы классов. Диаграммы

объектов имеют вспомогательный характер — по сути это примеры (можно сказать

дампы памяти), показывающие, какие имеются объекты и связи между ними в

некоторый конкретный момент функционирования системы.

На диаграмме объектов применяют один основной тип сущностей: объекты

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

(экземпляры ассоциаций).

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

рис. 1.9.

Рис. 1.9. Нотация диаграммы объектов

1.5.5. Диаграмма состояний

Диаграмма состояний — это основной способ детального описания поведения в

UML. В сущности, диаграммы состояний представляют собой граф состояний и

переходов конечного автомата (см. главу 4), нагруженный множеством

дополнительных деталей и подробностей.

На диаграмме состояний применяют один основной тип сущностей — состояния, и

один тип отношений — переходы, но и для тех и для других определено множество

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

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

Детальное описание всех вариаций диаграмм состояний приведено в главе 4, а на

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

состояний.

Рис. 1.10. Нотация диаграммы состояний (UML 1.х)

1.5.6. Диаграмма деятельности

Диаграмма деятельности — это, фактически, старая добрая блок-схема алгоритма,

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

объектно-ориентированным подходом, что позволило органично включить

диаграммы деятельности в UML.

На диаграмме деятельности применяют один основной тип сущностей —

деятельность, и один тип отношений — переходы (передачи управления), а также

графические обозначения (развилки, слияния и ветвления), которые похожи на

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

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

гиперграфе (см. врезку "Множества, отношения и графы"). Семантика элементов

диаграмм деятельности подробно разобрана в главе 4.

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

данных, используя

такую сущность, как объект (в определенном состоянии) и

соответствующую зависимость. Кроме того, на диаграмме деятельности можно

применить специальный графический комментарий — так называемые дорожки —

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

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

применяемые на диаграмме деятельности, показаны на рис. 1.11.

Рис. 1.11. Нотация диаграммы деятельности (UML 2.0)

1.5.7. Диаграмма последовательности

Диаграмма последовательности — это способ описать поведение системы "на

примерах". Фактически, диаграмма последовательности — это запись протокола

конкретного сеанса работы системы (или фрагмента такого протокола). В

объектно-ориентированном программировании самым существенным во время

выполнения является посылка сообщений взаимодействующими объектами.

Именно последовательность посылки сообщений отображается на данной

диаграмме, отсюда и название.

На диаграмме последовательности применяют один основной тип сущностей —

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

тип отношений — сообщения, которыми обмениваются взаимодействующие

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

нотации различаются видом стрелки, соответствующей отношению.

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

течения времени. В отличии от всех других типов диаграмм, на диаграмме

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

элементами, но и взаимное положение элементов на диаграмме. А именно,

считается, что имеется (невидимая) ось времени, по умолчанию направленная

сверху вниз, и то сообщение, которое отправлено позже, нарисовано ниже.

ЗАМЕЧАНИЕ

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

время течет слева направо.

На рис. 1.12 показаны основные элементы нотации, применяемые на диаграмме

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

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

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

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

направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде

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

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

времени, в течении которых объект имеет управление (как говорят, имеет место

активация объекта). Создание объекта в процессе взаимодействия отмечается тем,

что значок объекта расположен ниже (т. е. объект появляется позже). Уничтожение

объекта отмечает большим косым крестом и прекращением линии жизни. Прочие

детали нотации диаграммы последовательностей см. в главе 4.

Рис. 1.12. Нотация диаграммы последовательности (UML 2.0)

1.5.8. Диаграмма кооперации

Диаграмма кооперации, которая в UML 2 переименована в диаграмму

коммуникации, семантически эквивалентна диаграмме последовательности.

Фактически, это такое же описание последовательности обмена сообщениями

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

средствами. Более того, большинство инструментов умеет автоматически

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

обратно. Такое преобразование является взаимно-однозначным.

Таким образом, на диаграмме кооперации

также применяют один основной тип

сущностей — объекты (экземпляры взаимодействующих классов и действующих

лиц), и один тип отношений — сообщения, которыми обмениваются

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

связях между конкретными объектами.

На рис. 1.13 показаны основные элементы нотации, применяемые на диаграмме

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

применяется

стандартная нотация — прямоугольник с подчеркнутым именем объекта. Взаимное

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