Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
1.7. Структура UML 31
Объекты (и классы) будут подробно рассмотрены в главе 7. До тех пор
будем считать, что объект единым целым блока данных и поведения.
Иначе говоря, объекты содержат информацию и могут выполнять
функции.
1.7. Структура UML
Понимание работы UML как визуального языка начинается с рассмот
рения его структуры. Она показана на рис. 1.4 (как выяснится позже,
это действительная UMLдиаграмма). Эта структура включает:
• строительные блоки – основные элементы, отношения и диаграм
мы UMLмодели;
• общие механизмы – общие UMLпути достижения определенных
целей;
• архитектура – UMLпредставление архитектуры системы.
Понимание структуры UML дает нам представление о структуре всего
изложенного в книге материала. Наличие структуры также указывает
на то, что сам UML – это спроектированная система с собственной ар
хитектурой. Кстати, UML был смоделирован и спроектирован с помо
щью UML! Этим проектом является метамодель UML.
1.8. Строительные блоки UML
Согласно «The Unified Modeling Language User Guide» [Booch 2], UML
состоит всего из трех строительных блоков (рис. 1.5):
• Сущности – это сами элементы модели.
• Отношения связывают сущности. Отношения определяют, как се
мантически связаны две или более сущностей.
• Диаграммы – это представления моделей UML. Они показывают
наборы сущностей, которые «рассказывают» о программной систе
ме и являются нашим способом визуализации того, что будет де
лать система (аналитические диаграммы) или как она будет делать
это (проектные диаграммы).
UML
Общие механизмы АрхитектураСтроительные блоки
Рис. 1.4. Структура UML
32 Глава 1. Что такое UML?
В следующих трех разделах типы строительных блоков рассматрива
ются немного подробнее.
1.8.1. Сущности
«Сущности» – это существительные UMLмодели.
Все UMLсущности можно разделить на:
• структурные сущности – существительные UMLмодели, такие как
класс, интерфейс, кооперация, прецедент, активный класс, компо
нент, узел;
• поведенческие сущности – глаголы UMLмодели, такие как взаимо
действия, деятельности, автоматы;
• группирующая сущность – пакет, используемый для группировки
семантически связанных элементов модели в образующие единое
целое модули;
• аннотационная сущность – примечание, которое может быть добав
лено к модели для записи специальной информации, очень похо
жее на стикер.
Все эти сущности и то, насколько успешно они используются в UML
моделировании, рассматривается в части 2.
1.8.2. Отношения
Отношения позволяют показать взаимодействие в пределах модели
двух или более сущностей. Для понимания роли, которую отношения
играют в моделях UML, достаточно представить отношения между чле
нами отдельной семьи. Отношения в модели UML позволяют зафикси
ровать значимые (семантические) связи между сущностями. Напри
мер, в табл. 1.1 представлены UMLотношения, применяемые к струк
турным и группирующим сущностям модели.
Правильное понимание семантики различных типов отношений явля
ется очень важной частью моделирования UML. Однако мы отложим
подробное описание этих семантик до следующих разделов книги.
Отношения
Строительные блоки
Диаграммы
Сущности
Рис. 1.5. Строительные блоки UML
1.8. Строительные блоки UML 33
Таблица 1.1
1.8.3. Диаграммы
Диаграммы – это только представления модели.
Во всех инструментальных средствах UMLмоделирования новые сущ
ности или новые отношения при создании добавляются в модель. Мо
дель – это хранилище всех сущностей и отношений, созданных для
описания требуемого поведения проектируемой программной системы.
Диаграммы – это своего рода картины, или представления модели.
Диаграмма это не модель! На самом деле, различие между диаграммой
и моделью является очень важным для понимания, поскольку сущ
ность или отношение могут быть удалены с диаграммы, или даже со
всех диаграмм, но попрежнему они продолжают существовать в моде
ли. Они будут оставаться в модели до тех пор, пока не будут явно уда
лены из нее. Общая ошибка новичков в UMLмоделировании состоит
в том, что они удаляют сущности с диаграмм, не удаляя их из модели.
Существует тринадцать различных типов UMLдиаграмм, все они при
ведены на рис. 1.6. На рисунке каждый прямоугольник представляет
определенный тип диаграммы, при этом курсивом выделяются абст
рактные категории типов диаграмм. Например, существует шесть раз
ных типов Диаграмм структуры. Обычный текст указывает на конкрет
ную диаграмму, которую можно реально создать. Заштрихованные
блоки обозначают типы диаграмм, впервые появившиеся в UML 2.
Тип
отношения
UMLсинтаксис Краткая
семантика
Раз
дел
источник цель
Зависимость Исходный элемент зависит от целевого
элемента и изменение последнего может
повлиять на первый.
9.5
Ассоциация Описание набора связей между объектами. 9.4
Агрегация Целевой элемент является частью исход
ного элемента.
18.4
Композиция Строгая (более ограниченная) форма
агрегирования.
18.5
Включение Исходный элемент содержит целевой эле
мент.
11.4
Обобщение Исходный элемент является специализа
цией более обобщенного целевого элемен
та и может замещать его.
10.2
Реализация Исходный элемент гарантированно вы
полняет контракт, определенный целе
вым элементом.
12.3
34 Глава 1. Что такое UML?
Эти диаграммы можно разделить на те, которые моделируют статиче
скую структуру системы (статическую модель), и те, которые моделиру
ют динамическую структуру системы (динамическую модель). Статиче
ская модель фиксирует сущности и структурные отношения между ни
ми; динамическая модель отображает, как сущности взаимодействуют
для генерирования требуемого поведения программной системы. Стати
ческая и динамическая модели рассматриваются начиная с части 2.
Определенного порядка создания UMLдиаграмм не существует, хотя
обычно начинают с диаграммы прецедентов для определения предмет
ной области системы. Как правило, работа идет одновременно над не
сколькими диаграммами, каждая из которых уточняется по мере выяв
ления более подробной информации о разрабатываемой программной
системе. Таким образом, диаграммы являются как представлением мо
дели, так и основным механизмом введения информации в модель.
В UML 2 представлен новый синтаксис диаграмм, изображенный на
рис. 1.7. У каждой диаграммы может быть рамка, область заголовка
и область содержимого. Область заголовка – это неправильный пяти
угольник, содержащий тип (не обязательно), имя и параметры (не обя
зательно) диаграммы.
Диаграмма
Диаграмма
структуры
Диаграмма
поведения
Диаграмма
классов
Диаграмма
составных
структур
Диаграмма
компонентов
Диаграмма
развертывания
Диаграмма
объектов
Диаграмма
пакетов
Диаграмма
деятель!
ности
Диаграмма
взаимо!
действия
Диаграмма
преце!
дентов
Диаграмма
состояний
(конечных
автоматов)
Диаграмма
последовательности
Коммуникационная
диаграмма
Диаграмма
обзора взаимодействий
Временная
диаграмма
Рис. 1.6. Типы UML+диаграмм
заголовок
область содержимого
синтаксис заголовка: <тип> <имя> <параметры>
особое внимание: <тип> и <параметры> необязательны
рамка
Рис. 1.7. Синтаксис UML+диаграмм
1.9. Общие механизмы UML 35
<Тип> указывает тип данной диаграммы и должен быть одним из ти
пов, перечисленных на рис. 1.6. Спецификация UML определяет, что
<тип> может быть сокращен, но не предоставляет списка стандартных
сокращений. Явное задание <типа> требуется редко, потому что его
обычно легко определить из визуального синтаксиса.
<Имя> должно описывать семантику диаграммы (например, CourseRegi
stration (регистрация курса)). <Параметры> предоставляют информацию,
необходимую элементам модели, представленным на диаграмме. При
меры использования <параметров> будут приведены позже.
У диаграммы может быть (не обязательно) условная рамка, ограничи
вающая область в инструменте моделирования, внутри которой нахо
дится диаграмма. Пример условной рамки приведен на рис. 1.8.
1.9. Общие механизмы UML
В UML существует четыре общих механизма, последовательно приме
няемых ко всему языку моделирования. Они описывают четыре стра
тегии подхода к моделированию объектов, которые в разных контек
стах многократно применяются в UML. Это еще раз убеждает нас в про
стоте и элегантности структуры UML (рис. 1.9).
условная рамка
Рис. 1.8. Пример диаграммы
36 Глава 1. Что такое UML?
1.9.1. Спецификации
Спецификации – это суть UMLмодели. Они обеспечивают семантиче
ский задний план модели.
Модели UML имеют, по крайней мере, два измерения: графическое,
позволяющее визуализировать модель с помощью диаграмм и пикто
грамм, и текстовое, состоящее из спецификаций различных элементов
модели. Спецификации – это текстовые описания семантики элемента.
Класс, например BankAccount (банковский счет), можно изобразить в ви
де прямоугольника с ячейками (рис. 1.10), но это представление ниче
го не сообщает о бизнессемантике этого класса. Семантика элементов
модели фиксируется в спецификациях; без них можно только догады
ваться, что на самом деле представляет собой элемент.
Набор спецификаций – это суть модели. Спецификации формируют се+
мантический задний план (semantic backplane), который объединяет
модель и наполняет ее смыслом. Различные диаграммы – это просто
представления или визуальные проекции этого плана.
Механизмы
расширения
Принятые
деления
Дополнения
Спецификации
Общие механизмы
Рис. 1.9. Общие механизмы UML
withdraw()
calculateInterest()
deposit()
BankAccount
accountNumber
owner
balance
пиктограмма
или элемент
модели
Deposit
Семантический задний план
Спецификация класса
Спецификация прецедентов
Спецификация зависимостей
Рис. 1.10. Семантический задний план
1.9. Общие механизмы UML 37
Семантический задний план обычно сопровождается инструментом
моделирования UML, предоставляющим доступ, просмотр и измене
ние спецификаций каждого элемента модели.
Диаграммы обеспечивают представления семантического заднего плана.
UML обеспечивает большую гибкость при создании моделей. В частно
сти, модели могут быть:
• сокращенными – некоторые элементы присутствуют в заднем плане,
но скрыты в той или иной диаграмме для упрощения представления;
• неполными – некоторые элементы модели могут быть полностью
пропущены;
• несогласованными – модель может содержать противоречия.
Здесь важен сам факт ослабления требований к полноте и согласован
ности, поскольку, как вы заметите, со временем модель эволюциони
рует и неоднократно подвергается изменениям. Однако развитие все
гда происходит по направлению к согласованным моделям, достаточ+
но полным для создания программной системы.
Разработку моделей с помощью UML, как правило, начинают с графи
ческой модели, которая позволяет визуализировать систему, а затем
по мере ее развития добавляют в задний план все больше и больше се
мантики. Однако модель можно считать полезной или полной, только
если семантика модели присутствует в семантическом заднем плане.
В противном случае модели не существует, есть просто бессмыслен
ный набор блоков и пятен, соединенных линиями! Кстати, общую
ошибку, совершаемую новичками в разработке моделей, можно на
звать «смерть от диаграмм»: модель переполнена диаграммами, но не
доопределена.
1.9.2. Дополнения
В UML каждый элемент модели обозначается простым символом, к ко
торому можно добавлять ряд дополнений, визуализирующих аспекты
спецификации элемента. С помощью этого механизма видимая на диа
грамме информация может быть представлена в соответствии
с конкретными требованиями.
Мы дополняем элементы модели на UMLдиаграммах, чтобы подчерк
нуть важные детали.
Начинать можно с создания высокоуровневой диаграммы, использую
щей только основные символы с одним или двумя дополнениями.
Со временем диаграмма уточняется путем добавления все большего
и большего количества дополнений до тех пор, пока не станет доста
точно подробной.
38 Глава 1. Что такое UML?
Важно помнить, что любая UMLдиаграмма – это только представление
модели, и поэтому необходимо показывать лишь те дополнения, кото
рые подчеркивают важные характеристики модели и делают диаграм
му более понятной и удобочитаемой. Обычно нет необходимости пока
зывать на диаграмме все до мельчайших подробностей. Важнее то,
чтобы диаграмма была понятной, иллюстрировала именно те аспекты,
которые требуется, и была легкой для восприятия.
На рис. 1.11 показано, что минимальным представлением класса яв
ляется прямоугольник с именем класса. Однако различные детали ба
зовой модели могут быть раскрыты в виде дополнений, расширяющих
это минимальное представление. Возможные необязательные допол
нения выделены на рисунке серым цветом.
1.9.3. Принятые деления
Принятые деления описывают конкретные способы представления
мира. В UML существует два принятых деления: классификатор/эк
земпляр и интерфейс/реализация.
1.9.3.1. Классификатор и экземпляр
В UML предполагается, что может существовать абстрактное понятие
типа сущности (например, банковский счет) и отдельные конкретные
экземпляры этой абстракции (такие как «мой банковский счет» или
«ваш банковский счет»). Абстрактное понятие типа сущности – это
классификатор, а отдельные конкретные сущности – экземпляры. Это
очень важная концепция, которая на самом деле крайне проста для по
нимания. Примеры классификаторов и экземпляров можно найти по
всюду. Возьмем эту книгу по UML. Можно сказать, что «UML 2 и Уни
фицированный процесс» – это абстрактная идея этой книги, и множе
ство ее экземпляров – это книги, одну из которых вы сейчас читаете.
Вы увидите, что понятие «классификатор/экземпляр» является клю
чевой концепцией, пронизывающей UML.
Window
+size : Area=(100,100)
# visibility : Boolean = false
+ defaultSize : Rectangle
#maximumSize : Rectangle
!xptr : XWindow*
+create()
+hide()
+display( location : Point )
!attachXWindow(xwin : XWindow*)
{author = Jim, status = tested}
Window
элемент без дополнений
элемент с дополнениями
Рис. 1.11. Элемент с дополнениями
1.9. Общие механизмы UML 39
В UML экземпляр обычно обозначается той же пиктограммой, что и со
ответствующий классификатор, но для экземпляров имя на пикто
грамме подчеркнуто. Поначалу это различие может показаться несу
щественным.
Классификатор – это абстрактное понятие, например тип банковского
счета. Экземпляр – конкретная сущность, например ваш банковский
счет или мой банковский счет.
UML 2 предоставляет богатую систематику из 33 классификаторов.
Некоторые из наиболее распространенных классификаторов приведе
ны в табл. 1.2.
Таблица 1.2
Все эти классификаторы (и другие) будут рассмотрены более подробно
в следующих разделах.
1.9.3.2. Интерфейс и реализация
Интерфейс – это, например, кнопки на панели видеомагнитофона. Реа
лизация – устройство видеомагнитофона.
Основная идея этих понятий в том, чтобы отделить то, что выполняет
действие (интерфейс), от того, как это делается (реализации). Напри
мер, при управлении машиной водитель взаимодействует с очень про
стым и четко определенным интерфейсом. На разных машинах этот
интерфейс реализован поразному.
Классифи
катор
Семантика Раздел
Актер Роль, выполняемая внешним пользователем системы,
которому система предоставляет некоторые услуги.
4.3.2
Класс Описание набора объектов, обладающих одинаковыми
свойствами.
7.4
Компонент Модульная и замещаемая часть системы, инкапсулирую
щая свое содержимое.
19.8
Интерфейс Набор операций, используемых для определения серви
сов, предлагаемых классом или компонентом.
19.3
Узел Физический элемент, существующий во время выполне
ния и представляющий собой вычислительный ресурс,
например ПК.
24.4
Сигнал Асинхронное сообщение, передаваемое между объектами. 15.6
Прецедент Описание последовательности действий, осуществляемых
системой для предоставления пользователю результата.
4.3.3
40 Глава 1. Что такое UML?
Интерфейс определяет контракт (имеющий много общего с юридиче
ским контрактом), придерживаться которого обязуются конкретные
реализации. Это функциональное разделение между тем, что обещано
выполнить, и реализацией этого обещания является важной концеп
цией UML. Подробно этот вопрос обсуждается в главе 17.
Конкретные примеры интерфейсов и реализаций можно найти повсю
ду. Например, кнопки на панели видеомагнитофона обеспечивают
простой интерфейс его сложного механизма. Интерфейс избавляет нас
от необходимости вникать в детали внутреннего устройства.
1.9.4. Механизмы расширения
UML – расширяемый язык моделирования.
Разработчики UML понимали, что просто невозможно создать полно
стью универсальный язык моделирования, который удовлетворял бы
всем современным требованиям и тем, что могут появиться в ближай
шем будущем. Поэтому UML включает три простых механизма расши
рения, приведенные в табл. 1.3.
Таблица 1.3
Более подробно эти механизмы расширения рассматриваются в сле
дующих трех разделах.
1.9.4.1. Ограничения
Ограничения позволяют добавлять новые правила в элементы модели.
Ограничение – это строка текста, заключенная в фигурные скобки ({ }),
определяющая некоторое условие или правило для элемента модели,
которое должно оставаться истинным. Иначе говоря, оно некоторым
образом ограничивает какиелибо свойства элемента. В книге приво
дятся примеры ограничений.
Механизмы расширения UML
Ограничения Расширяют семантику элемента, обеспечивая возможность
добавлять новые правила.
Стереотипы Обеспечивают возможность определять новые элементы мо
дели UML на основании существующих: мы определяем се
мантику стереотипа самостоятельно.
Стереотипы добавляют новый элемент в метамодель UML.
Помеченные
значения
Предоставляют способ расширения спецификации элемен
та, обеспечивая возможность добавлять в него новую специ
альную информацию.