ЛекUML
.pdfзависимость; ассоциация; обобщение; реализация.
Зависимость — это наиболее общий тип отношения между двумя сущностями, Отношение зависимости указывает на то, что изменение независимой сущности каким-то образом влияет на зависимую сущность. Графически отношение зависимости изображается в виде пунктирной стрелки, направленной от независимой сущности к зависимой. Как правило, семантика конкретной зависимости уточняется в модели с помощью дополнительной информации. Например, зависимость со стереотипом «use» означает, что зависимая сущность использует (скажем, вызывает операцию) независимую сущность.
Ассоциация — это наиболее часто используемый тип отношения между сущностями. Отношение ассоциации имеет место, если одна сущность непосредственно связана с другой (или с другими — ассоциация может быть не только бинарной). Графически ассоциация изображается в виде сплошной линии с различными дополнениями, соединяющей связанные сущности. На программном уровне непосредственная связь может быть реализована различным образом, главное, что ассоциированные сущности знают друг о друге. Например, отношение часть–целое является частным случаем ассоциации и называется отношением агрегации.
Обобщение — это отношение между двумя сущностями, одна их которых является частным (специализированным) случаем другой. В UML отношение обобщения подразумевает выполнение принципа подстановочности: если сущность А (общее) суть обобщение сущности Б (частное), то Б может быть подставлено вместо А в любом контексте. Графически обобщение изображается в виде сплошной стрелки с треугольником на конце, направленной от частного к общему. Отношение наследования между классами в объектно-ориентированных языках программирования является типичным примером обобщения.
Отношение реализации используется несколько реже, чем предыдущие три типа отношений, поскольку часто подразумеваются по умолчанию. Отношение реализации указывает, что одна сущность является реализацией другой. Например, класс является реализацией интерфейса. Графически реализация изображается в виде пунктирной стрелки с треугольником на конце, направленной от реализующей сущности к реализуемой.
2.2. Диаграммы
Помимо сущностей и отношений, в модели должна быть какая-то структура, которая бы помогала ее составлению и пониманию.
Диаграммы UML и есть та основная накладываемая на модель структура, которая облегчает создание и использование модели.
Диаграмма — это графическое представление некоторой части графа модели. Вообще говоря, в диаграмму можно было бы включить любые (допустимые) комбинации сущностей и отношений, но произвол в этом вопросе затруднил бы понимание моделей. Поэтому авторы UML определили набор рекомендуемых к использованию типов диаграмм, которые получили название канонических типов диаграмм.
2.2.1. Классификация диаграмм
Всего определено 9 канонических типов диаграмм.
Диаграмма использования
Диаграмма классов Диаграмма объектов Диаграмма состояний Диаграмма деятельности Диаграмма последовательности Диаграмма кооперации Диаграмма компонентов Диаграмма размещения
Канонические диаграммы отнюдь не образуют полного «ортогонального» набора: они пересекаются как по включенным в них средствам, так и по области применения. Более того, некоторые из них являются частными случаями других, есть просто семантические эквивалентные пары, можно привести примеры допустимых диаграмм, для которых затруднительно указать однозначно, к какому именно из канонических типов диаграмма относится.
Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной на рисунке
|
Классов |
Объектов |
|
|
Структурная |
Компонентов |
|
|
|
||
|
Реализации |
|
|
Диаграмма |
Использования |
Размещения |
|
{root} |
|||
|
|
Состояний
Поведенческая
Деятельности
Последовательности
Взаимодействия
Кооперации
Классификация диаграмм
2.2.2. Диаграмма использования
Диаграмма использования — это наиболее общее представление функционального назначения системы. Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире?
На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений:
ассоциация между действующим лицом и вариантом использования; обобщение между действующими лицами; обобщение между вариантами использования;
зависимости (различных типов) между вариантами использования.
Кроме того, на диаграмме использования можно применить специальный графический комментарий — обозначить границу системы (действующие лица находятся снаружи, а варианты использования — внутри), если это почему-либо не очевидно.
Основные элементы нотации, применяемые на диаграмме использования, показаны на рисунке
Действующее |
System name |
|
Имя системы |
||
лицо |
||
|
||
|
Use case name |
|
Actor name |
Зависимость |
|
Обобщение |
||
|
||
|
Ассоциация |
|
|
Use case name |
Вариант использования
Actor name
Граница системы
Нотация диаграммы использования
2.2.3. Диаграмма классов
Диаграмма классов — основной способ описания структуры системы. На диаграмме классов применяются один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:
ассоциация между классами (с множеством дополнительных подробностей); обобщение между классами; зависимости (различных типов) между классами и интерфейсами.
Основные элементы нотации, применяемые на диаграмме классов, показаны на рисунке
|
Класс |
|
Реализация |
|||
|
|
|
|
|||
|
ClassA |
|
интерфейса |
|||
|
|
|
|
InterfaceA |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
Обобщение |
|
|
|
|
|
|
|
|
|
Ассоциация |
|
|
|
|
ClassB |
|
ClassC |
|||
|
|
|
|
|
|
|
|
|
|
1 |
* |
|
|
|
|
|
|
|
||
Нотация диаграммы классов
2.2.4. Диаграмма объектов
Диаграмма объектов — это частный случай диаграммы классов. Диаграммы объектов имеют вспомогательный характер — по сути это примеры (можно сказать дампы памяти), показывающие, какие имеются объекты и связи между ними в некоторый конкретный момент функционирования системы.
На диаграмме объектов применяют один основной тип сущностей: объекты (экземпляры классов), между которыми указываются конкретные связи (экземпляры ассоциаций).
Основные элементы нотации, применяемые на диаграмме объектов, показаны на рисунке
Объект |
Object2 : ClassC |
|
|
||
|
||
|
|
|
: ClassB
Связь
Object3
Нотация диаграммы объектов
2.2.5. Диаграмма состояний
Диаграмма состояний — это основной способ детального описания поведения в UML. В сущности, диаграммы состояний представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.
На диаграмме состояний применяют один основной тип сущностей — состояния, и один тип отношений — переходы. На рисунке показаны основные элементы нотации, применяемые на диаграмме состояний.
Переход
|
State1 |
State2 |
|
Начальное |
Состояние |
Конечное |
|
состояние |
|||
|
состояние |
||
|
|
Нотация диаграммы состояний
2.2.6. Диаграмма деятельности
Диаграмма деятельности — это, фактически, блок-схема алгоритма, в которой модернизированы обозначения.
На диаграмме деятельности применяются применяют один основной тип сущностей — деятельность, и один тип отношений — переходы (передачи управления), а также графические обозначения (развилки, слияния и ветвления). Помимо потока управления на диаграмме деятельности можно показать и поток данных, используя такую сущность, как объект (в определенном состоянии) и соответствующую зависимость.
Кроме того, на диаграмме деятельности можно применить специальный графический комментарий — так называемые дорожки — подчеркивающие, что некоторые деятельности отличаются друг от друга, например, выполняются в разных местах.
Основные элементы нотации, применяемые на диаграмме деятельности, показаны на рисунке
|
Дорожка |
|
|
|
|
Swim Lane 1 |
|
Swim Lane 2 |
|
|
|
|
|
Имя дорожки |
|
Развилка |
|
|
|
Ветвление |
|
|
|
|
Activity 1 |
Деятельность |
Activity 2 |
Activity 3 |
Объект в |
|
|
|
|
|
|
Поток |
|
|
состоянии |
|
|
|
|
|
|
управления |
|
Object |
|
|
|
|
|
|
|
|
|
|
[in state] |
|
|
|
|
Слияние |
Нотация диаграммы деятельности
2.2.7. Диаграмма последовательности
Диаграмма последовательности — это способ описать поведение системы "на примерах". Фактически, диаграмма последовательности — это запись протокола конкретного сеанса
работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является посылка сообщений взаимодействующими объектами. Именно последовательность посылки сообщений отображается на данной диаграмме.
На диаграмме последовательности применяют один основной тип сущностей — объекты (экземпляры взаимодействующих классов и действующих лиц), и один тип отношений — сообщения, которыми обмениваются взаимодействующие объекты. Предусмотрено несколько типов сообщений, которые в графической нотации различаются видом стрелки, соответствующей отношению.
Важным аспектом диаграммы последовательности является явное отображение течения времени. В отличии от всех других типов диаграмм, на диаграмме последовательности имеет значение не только наличие графических связей между элементами, но и взаимное положение элементов на диаграмме. А именно, считается, что имеется (невидимая) ось времени, по умолчанию направленная сверху вниз, и то сообщение, которое отправлено позже, нарисовано ниже.
Ниже на рисунке показаны основные элементы нотации, применяемые на диаграмме последовательности. Для обозначения самих взаимодействующих объектов применяется стандартная нотация — прямоугольник с подчеркнутым именем объекта. Пунктирная линия, выходящая из объекта, называется линией жизни. Это не обозначение отношение в модели, а графический комментарий, призванный направить взгляд читателя диаграммы в правильном направлении. Фигуры в виде узких полосок, наложенных на линию жизни, также не являются изображениями моделируемых сущностей. Это графический комментарий, показывающий отрезки времени, в течении которых объект имеет управление. Создание объекта в процессе взаимодействия отмечается тем, что значок объекта расположен ниже (т. е. объект появляется позже). Уничтожение объекта отмечает большим косым крестом и прекращением линии жизни.
Объект (экземпляр класса)
Object1
Время
Actor Message1()
Object2
Сообщение Message2() Создание объекта
Активация
Message3()
Возврат
Линия Уничтожение 
жизни
объекта
Нотация диаграммы последовательности
2.2.8. Диаграмма кооперации
Диаграмма кооперации семантически эквивалентна диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих объектов, только выраженное другими графическими средствами. Более того, большинство инструментов умеет автоматически преобразовывать диаграммы последовательности в диаграммы кооперации и обратно. Такое преобразование является взаимно-однозначным.
Таким образом, на диаграмме кооперации также применяют один основной тип сущностей — объекты (экземпляры взаимодействующих классов и действующих лиц), и один тип отношений — сообщения, которыми обмениваются взаимодействующие объекты. Однако здесь акцент делается не на времени, а на связях между конкретными объектами.
На рисунке показаны основные элементы нотации, применяемые на диаграмме кооперации. Для обозначения самих взаимодействующих объектов применяется стандартная нотация — прямоугольник с подчеркнутым именем объекта. Взаимное положение объектов на диаграмме кооперации не имеет значения — важны только связи (экземпляры ассоциаций), вдоль которых передаются сообщения. Для отображения упорядоченности сообщений во времени применяется иерархическая десятичная нумерация.
|
Сообщения |
|
1.1 Message2() |
1 Message0() |
1.1.1 Message3() |
Object1 |
Object2 |
Связь Объект
(экземпляр класса)
Actor
Нотация диаграммы кооперации
2.2.9. Диаграмма компонентов
Диаграмма компонентов — это, фактически, список артефактов, из которых состоит моделируемая система, с указанием некоторых отношений между артефактами. Наиболее существенным типом артефактов программных систем являются программы. Таким образом, на диаграмме компонентов основной тип сущностей — это компоненты (как исполнимые модули, так и другие артефакты), а также интерфейсы (чтобы указывать взаимосвязь между компонентами) и объекты (входящие в состав компонентов). На диаграмме компонентов применяются следующие отношения:
реализации между компонентами и интерфейсами (компонент реализует интерфейс); зависимости между компонентами и интерфейсами (компонент использует интерфейс); зависимости между объектами и компонентами (объект входит в компонент).
На рисунке показаны основные элементы нотации, применяемые на диаграмме компонентов. Отношение зависимости, соответствующее включению часто изображают, помещая фигуру одной сущности внутрь фигуры другой сущности.
Компонент,
Component1 реализующий 
интерфейс
Компонент, использующий интерфейс
Component2 
Interface
Интерфейс
Нотация диаграммы компонентов
2.2.10. Диаграмма размещения
Диаграмма размещения немногим отличается от диаграммы компонентов. Фактически, наряду с отображением состава и связей компонентов здесь показывается, как физически размещены компоненты на вычислительных ресурсах во время выполнения. Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется один тип сущностей — узел, а также отношение ассоциации между узлами, показывающее, что узлы физически связаны во время выполнения.
На рисунке показаны основные элементы нотации, применяемые на диаграмме размещения.
|
|
|
|
Соединение |
|
|
|
|
|
узлов |
|
|
|
|
|
Компонент, |
|
|
|
Component |
|||
|
|
||||
|
|
размещенный |
|||
|
|
Workstation |
на узле |
||
|
|
|
Server |
||
|
|
|
|
|
Узел |
|
|
|
|
|
|
Нотация диаграммы размещения
2.3. Представления
Как показывает практический опыт, не удается описать с единой точки зрения все без исключения аспекты моделируемой системы. Отсюда следует вывод: моделировать сложную систему следует с нескольких различных точек зрения, каждый раз принимая во внимание один аспект моделируемой системы и абстрагируясь от остальных. Идея состоит в том, что абстрактный граф модели, состоящий из множества разнотипных сущностей и отношений, не подлежит конструированию или изучению в целом. Каждый раз для визуализации, изменения или иных манипуляций из этого общего графа вычленяются только сущности и отношения, важные для определенного аспекта моделируемой системы, а все остальные игнорируются. Такой вид с определенной точки зрения, можно сказать проекцию модели, называют представлением.
2.3.1. Пять представлений
Набор используемых представлений модели является еще менее формальным и догматическим, чем набор канонических типов диаграмм. Например, одним из самых
популярных является набор представлений, описанных авторами UML и показанных на рисунке
Логическое |
|
Представление |
представление |
|
компонентов |
|
|
|
Представление
использования
Представление |
Представление |
процессов |
размещения |
Пять представлений модели
Представление использования — это описание поведения системы с точки зрения внешних по отношению к ней агентов. Структурные аспекты передаются диаграммами использования, а поведенческие аспекты — диаграммами взаимодействия, состояний и деятельности.
Логическое представление предназначено для описания словаря предметной области, то есть, в парадигме объектно-ориентированного программирования, классов. Структурные аспекты передаются диаграммами классов и объектов, а поведенческие аспекты — диаграммами взаимодействия, состояний и деятельности.
Представление процессов — это описание взаимодействия процессов в во время работы системы. Оно отражает такие аспекты, как параллелизм, синхронизация, производительность, масштабируемость, пропускная способность. Структурные аспекты передаются с помощью концепции активных классов: процессы и потоки, а поведенческие аспекты — диаграммами взаимодействия, состояний и деятельности.
Представление компонентов — это описание конфигурации системы на уровне артефактов. Структурные аспекты передаются диаграммами компонентов, а поведенческие аспекты — диаграммами взаимодействия, состояний и деятельности.
Представление размещения отражает топологию связей аппаратных средств и размещения на них компонентов. Структурные аспекты передаются диаграммами размещения, а поведенческие аспекты — диаграммами взаимодействия, состояний и деятельности.
2.4.Общие механизмы
ВUML имеются общие правила и механизмы, которые относятся не к конкретным элементам модели, а ко всему языку в целом. Обычно выделяют следующие общие механизмы:
внутреннее представление модели; дополнения; подразделения; механизмы расширения.
2.4.1. Внутреннее представление модели
Модель имеет внутреннее представление — представление для «хранения» модели. Для графов известно множество разнообразных способов их представления в компьютере.
Разработчики инструментов для моделирования на UML вправе использовать любое представление или придумать свое. Важным общим правилом UML является спецификация того, какую именно семантическую информацию, связанную с тем или иным графическим элементом нотации, инструмент обязан хранить. Другими словами, у каждой картинки есть оборотная сторона, где все записано, даже то, что в данном контексте ненужно или нельзя показывать на картинке. Например, инструмент может поддерживать режим, в котором часть информации о классе (скажем, список операций) не отображается на картинке или отображается не полностью. Но при этом полный список со всеми деталями во внутреннем представлении сохраняется. Более того, внутреннее представление может быть переведено в текст в формате XMI (конкретное приложение XML) без потери информации. Таким образом, в UML определен результат сериализации модели. Это важное правило, на котором базируется интероперабельность инструментов.
2.4.2.Дополнения
Укаждого элемента модели есть базовая графическая нотация. Эта нотация может быть расширена путем использования дополнительных текстовых и/или графических объектов, присоединяемых к базовой нотации. Такие дополнительные объекты так и называются — дополнения. Дополнения позволяют показать на диаграмме те части внутреннего представления модели, которые не отображаются с помощью базовой графической нотации.
Например, базовой нотацией отношения ассоциации является сплошная линия. Эта базовая нотация может быть расширена целым рядом дополнений: именем ассоциации, указанием кратности полюсов ассоциации, ролей, направления навигации, агрегации и т. д.. Еще пример: базовой нотацией класса является прямоугольник с именем класса. Эта нотация может быть расширена разделами со списками атрибутов и операций, дополнительными разделами, указанием кратности, стереотипа и т. д.
Как правило, инструменты позволяют детально управлять отображением дополнений, скрывая ненужные подробности или, наоборот, выявляя все детали.
2.4.3. Подразделения
UML является объектно-ориентированным языком, поэтому базовые понятия объектноориентированного подхода имеют в языке большое влияние. Всюду, где возможно, единообразно применяются и изображаются две дихотомии: класс–объект и интерфейс– реализация. Дихотомия класс–объект означает, что всегда четко различается о чем идет речь: об общем описании некоторого множества однотипных объектов (т. е. о классе) или о конкретном объекте из некоторого множества однотипных объектов (т. е. об экземпляре класса). Это важное различие передается единообразно: если это конкретный объект (экземпляр класса), то его имя подчеркивается; если это класс (описание множества), то оно не подчеркивается. Одна и та же сущность в разных контекстах может рассматриваться и как класс (множество) и как экземпляр класса (элемент). Это совершенно естественно и неизбежно, хотя бы потому, что элементами множеств могут быть множества. Важно четко указать, что именно подразумевается в данном контексте. Например, класс в обычной модели является описанием множества объектов и его имя не подчеркивается. Но в то же время каждый класс является объектом — экземпляром метакласса classifier, определенного в метамодели UML.
Дихотомия интерфейс–реализация позволяет указать в модели, чем именно является та или иная сущность: абстрактным описанием того, чем она должна быть по отношению к