Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Типы связей между классами



 

Ассоциация (association) определяет некоторую связь между классами. Когда в системе создаются представители ассоциированных классов, они связываются так, как определяет данная ассоциация.

В UML одна ассоциация может специфицировать связь между двумя и несколькими (более чем двумя) классами. Ассоциации первого типа называются бинарными, а второго типа - N-арными.

Бинарная ассоциация (binary association) - это ассоциация между ровно двумя классами. Возможна ассоциация класса с самим собой, которая называется рефлексивной ассоциацией.

Изображается ассоциация в виде сплошной линии, соединяющей два символа класса. Каждая ассоциация обладает двумя ролями (association role), каждая роль представляет собой направление ассоциации. Большая часть информации, касающейся ассоциации, присоединена к ее ролям.

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

1) имя ассоциации - определяет необязательное имя ассоциации,

2) класс ассоциации - класс, позволяющий определять для ассоциаций атрибуты, операции и другие свойства (соединяется с линией ассоциации пунктирной линией). Это метка используется в случае, если необходимо присоединить к ассоциации некую дополнительную информацию.

Роль (association role) - это неотделимая часть ассоциации, описывающая некоторые свойства её соединения с классом (роль класса в данной ассоциации).

У роли могут быть следующие свойства:

1) Имя роли - строка, стоящая рядом с концом ассоциации. Поле не обязательное, но если имя задано, оно должно отображаться на диаграмме.

2) Навигация - если в направлении, соответствующем роли, поддерживается навигация, на конце линии может быть изображена стрелка. Возможность навигации в направлении роли означает, что партнеры ассоциации могут просматривать объекты, соответствующие этой роли.

3) Множественность - показывает количество конкретных объектов, которые могут быть связаны с данным партнером ассоциации. В общем случае, множественность показывает нижнюю и верхнюю границы количества объектов, которые могут участвовать в ассоциации.

4) Квалификатор - представляет собой список атрибутов класса с противоположного конца ассоциации, по значениям которых можно однозначно разбить множество его объектов на подмножества. Используется для связи объекта класса-партнера ассоциации с группой объектов другого класса-партнера ассоциации.

5) Агрегирование - показывает, что ассоциация является отношением типа целое/часть.

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

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

<нижняя граница>..<верхняя граница>

Верхняя граница и нижняя граница указывают минимальное и максимальное количество объектов, участвующих в ассоциации. Если для верхней границы стоит символ '*', то это символизирует, что она (верхняя граница) бесконечна.

Пример:

0..1

0..*

3..5,10..20,100,200..*

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

 

 

Рисунок 6 - Пример ассоциации с указанием множественности

 

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

Квалификатор изображается в виде маленького прямоугольника, присоединенного к началу ассоциации (рис.7). В нем указываются атрибуты другого класса-партнера ассоциации.

 

Рисунок 7 Квалификатор

 

Если у роли ассоциации установлен атрибут "aggregation", то вся ассоциация является отношением агрегирования. Такой атрибут может быть установлен только у одной из ролей.

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

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

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

Агрегирование изображается на диаграмме полым ромбом на конце линии ассоциации со стороны агрегирующего класса (агрегата) (рис.8). Композиция показывается также как и агрегирование, но ромбик рисуется не пустым, а заполненным.

 

Рисунок 8 - Пример композиции

 

1.3.9Типы связей между объектами

 

Аналогично ключевому понятию модели классов - понятию ассоциации, - для объектов существует понятие связи (link).

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

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

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

1) "association" - экземпляр ассоциации. Этот вид означает, что данная связь является экземпляром ассоциации, соединяющей соответствующие классы. Поскольку все связи есть экземпляры ассоциации, то указывать этот вид не имеет особого смысла, он выставляется по умолчанию.

2) "parameter" - этот вид связи означает, что объект является параметром операции другого объекта-партнера связи.

3) "local" - показывает, что объект есть локальный параметр операции или метода другого объекта-партнера связи.

4) "global" - аналогично предыдущему, только здесь - глобальный параметр.

5) "self" - применяется для обозначения связи объекта с самим собой. Используется, например, для обозначения возможности посылки объектом сообщений самому себе.

N-арная связь представляется на диаграмме как ромб от которого выходят соединения к объектам (рис.9). Остальные атрибуты N-арной связи такие же как и у бинарной связи.

 

Рисунок 9 - Связи

 

1.3.10 Расширения понятия класса в UML

 

В UML существует несколько разновидностей класса:

1) Интерфейс (interface) - класс, задающий набор операций, но не содержащий в себе поля и реализации этих операций. Класс, реализующий интерфейс, сам определяет содержимое этих операций.

2) Шаблон (template) или параметризованный класс (parameterized class) - шаблоны UML очень похожи на шаблоны C++. Они определяют семейство классов, отличающихся значением некоторых формальных параметров.

3) Утилита (utility) - класс, объединяющий группу общедоступных (глобальных) переменных и процедур.

4) Для указания вида класса в UML введено понятие стереотипа (stereotype). Стереотип как бы определяет подтип некого глобального типа Класс. Соответственно, классы-интерфейсы имеют стереотип "interface", а классы-утилиты - "utility". Существует стандартный набор стереотипов, который, при необходимости, можно расширять.

Интерфейс (interface) в UML фактически является описанием (без реализации) группы функций, которые он предоставляет для использования другому классу. Логика работы этих функций не определяется. Имеется лишь возможность задать неформальное (например, на естественном языке) описание того, что от них требуется.

Класс поддерживает (или реализует) интерфейс, если он содержит методы, реализующие все операции интерфейса. Между двумя интерфейсами можно задать отношение наследования. Оно будет означать обычное теоретико-множественное объединение списков операций предка и потомка.

На диаграмме классов UML интерфейс можно изобразить двумя способами: развернутым и сокращенным. В случае развернутого способа интерфейс изображается на диаграмме как класс со стереотипом "interface" и без секции атрибутов (рис.10). Допустимо также сокращенное изображение интерфейса - небольшой кружок с именем интерфейса возле него.

 

Рисунок 10 - Класс, реализующий интерфейс

 

На рис. 10 изображен класс RunningLine, который реализует интерфейс DataConsumer. Связь между ними называется детализация и представляется на диаграмме в виде пунктирной линии с полым треугольником на конце. Таким образом, класс RunningLine должен предоставить метод, реализующий операцию SetData, унаследованную от интерфейса DataConsumer.

 

Рисунок 11 - Использование интерфейса классом

 

На рис. 11 изображен класс RunningLine, использующий интерфейс DataConsumer. Связь между ними называется зависимость и представляется на диаграмме в виде пунктирной линии со стрелкой на конце. Такая связь говорит о том, что если интерфейс DataConsumer изменить, то класс RunningLine тоже может претерпеть некоторые изменения. Поэтому при конструировании диаграмм необходимо сводить число зависимостей к минимуму, во избежание влияния вносимых изменений. (Более подробно о зависимостях будет сказано ниже).

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

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

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

Шаблон не может участвовать в большинстве обычных отношений между классами. Существует всего два вида отношений, в которых он может участвовать - связи между шаблоном и классом, порожденным от него подстановкой параметров (помечается ключевым словом "bind"), и направленные ассоциации (рис.12). Направленная ассоциация должна идти в направлении от шаблона (то есть навигация в направлении от шаблона).

 

Рисунок 12 - Шаблон

На рис. 12 изображен шаблон TList (список, состоящий из k элементов типа C) и экземпляр этого шаблона RecordList, который получается подстановкой класса Record вместо формального параметра C, и присваиванием параметру k значения 30. На том же рисунке показано и сокращенное обозначение привязки конкретных значений формальным параметрам: TList<Rectangle, 6>. Здесь в угловых скобках по порядку перечислены фактические параметры: класс Rectangle и целое число 6.

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

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

На диаграмме утилита изображается как класс со стереотипом "utility", и может иметь как атрибуты, так и операции.

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

Зависимость изображается пунктирной линией, проведенной между двумя элементами диаграммы, и считается, что элемент, привязанный к концу стрелки, зависит от элемента, привязанного к началу этой стрелки. Зависимость может быть снабжена именем и спецификатором (рис.13).

Существуют следующие виды зависимостей:

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

2) Refine - историческая связь между элементами, как правило, показывает, что один элемент как бы произошел от другого,

3) Uses - ситуация когда один элемент модели использует другой,

4) Bind - устанавливается между шаблоном и экземпляром шаблона,

5) Friend - аналог C++ friend.

Рисунок 13 - Зависимость элементов модели

 

Наследование (inheritance) - это отношение типа общее-частное между элементами модели.

Наследование показывается сплошной линией, идущей от конкретного элемента к более общему (в терминологии ООП - от потомка к предку, от сына к отцу, или от подкласса к суперклассу). Со стороны более общего элемента рисуется большой полый треугольник.

Один из атрибутов отношения наследования - дискриминатор (discriminator) -строка, задающая имя группы потомков. Его использование полезно, если у данного класса много потомков, и необходимо разбить их на несколько групп. Отсутствие дискриминатора означает, что дискриминатор - пустая строка (дискриминатор по умолчанию). Изображается дискриминатор текстовой строкой, стоящей возле линии наследования.

 

Рисунок 14 - Наследование

 

На рис. 14 Geometry - это дискриминатор, а {disjoint} - его дополнительное свойство.

Во многих современных языках программирования множественное наследование запрещено. Связано это со следующей проблемой. Допустим, класс A наследуется от классов B и C, а классы B и C, в свою очередь, имеют общего предка D. Такая ситуация называется перекрывающимся наследованием. Неясно, какой из экземпляров D будет храниться в экземпляре A. Для решения этой проблемы была разработана концепция виртуального наследования, обеспечивающая единственность экземпляра класса D в памяти. Но ее использование небезопасно и нетривиально.

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

1) disjoint - запрещение множественного наследовании;

2) overlapping - разрешение множественного наследования.

В контексте рисунка 14 первое свойство означает, что нельзя в множественном наследовании использовать двух потомков класса figure, если они произведены от него через ветку наследования, помеченную дискриминатором geometry. Если бы этот дискриминатор имел свойство {overlapping}, то это было бы возможно. По умолчанию дискриминатор имеет свойство {overlapping}.

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

1) complete - все потомки рассматриваемого класса определены (возможно, не показаны на данной диаграмме), и список потомков не может быть расширен (рис.15);

2) incomplete -возможно появление новых классов-потомков.

Рисунок 15 - Запрет создания новых подклассов

В контексте диаграмм классов, пакет (package) - это вместилище для некоторого набора классов и других пакетов. Пакет является самостоятельным пространством имен.

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

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

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

Рисунок 16 - Импортирование пакета

 

На рис. 16 показано, что пакет с именем Current импортирует пакет с именем Java::awt.

1.4 Диаграммы вариантов использования (use case diagrams)

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

1.4.1 Основные элементы диаграммы

 

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

Действующее лицо представляется на диаграмме прямоугольником (аналогично классу) с стереотипом "actor". Но, чаще всего, действующее лицо представляется пиктограммой в виде фигурки человечка, а имя действующего лица располагается под фигуркой.

Вариант использования представляется на диаграмме эллипсом, внутри которого располагается его имя. Имя варианта использования может быть расположено и под эллипсом (рис.17).

Рисунок 17 - Диаграмма вариантов использования

 

1.4.2 Связи в диаграмме вариантов использования

 

В диаграмме вариантов использования значимыми являются следующие связи (рис.18):

1) сommunicates - показывает участие действующего лица в варианте использования, соединяя символ действующего лица с символом варианта использования сплошной линией. Действующее лицо "общается" с вариантом использования по этой связи,

2) extends - линия со стереотипом "extends", с незаполненной стрелкой на конце, соединяет базовый вариант использования с вариантом использования, его расширяющим, и называется расширение. Конец с незаполненной стрелкой указывает на вариант использования, являющийся расширением базового варианта использования. Такой тип связи используется, если один варианта использования подобен другому, но несет большую нагрузку. Особенно удобно использовать такой тип связи при описании обработки аварийных ситуаций, возникающих в системе (чтобы не перегружать основной варианта использования, описывающий нормальное поведение системы, излишней логикой).

3) uses - линия с надписью "uses", с незаполненной стрелкой на конце, соединяет один вариант использования с другим вариантом использования, которого он использует. Такой тип связи называется использование, и применяется в тех случаях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования, и не хочется копировать его в каждом из этих вариантов. В этом случае данный фрагмент оформляется как отдельный вариант использования, и к нему проводятся соответствующие связи от других вариантов использования.

Рисунок 18 - Связи на диаграмме вариантов использования

1.5 Диаграммы взаимодействия (interaction diagrams)

 

Взаимодействие между объектами в системе представляются диаграммами взаимодействия (interaction diagrams). Диаграммы взаимодействия подразделяются на два основных типа диаграмм: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams).

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

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

 

1.5.1 Диаграммы последовательности (sequence diagrams)

Диаграммы последовательности имеют две размерности: вертикальная представляет время, горизонтальная - различные объекты. Оси могут меняться местами, так что ось времени может располагаться горизонтально, слева направо, а список объектов располагаться вертикально.

Объект на диаграмме изображается в виде прямоугольника на вершине вертикальной пунктирной линии, называемой линией жизни объекта (lifeline) (рис.19). Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия. Если объект создается или уничтожается на отрезке времени, представленном на диаграмме, то его линия жизни начинается и заканчивается в соответствующих точках, в противном случае линия жизни объекта проводится от начала до конца диаграммы. Символ объекта рисуется в начале его линии жизни; если объект создается не в начале диаграммы, то сообщение о создании объекта рисуется со стрелкой, проведенной к символу объекта. Если объект уничтожается не в конце диаграммы, то момент его уничтожения помечается большим крестиком "Х". При сообщении, вызывающем уничтожение объекта (или самоуничтожение), в конце возвращается сообщение об уничтожении объекта. Линия жизни может разветвляться в две (и более) параллельные линии, показываемые условно. Каждая ответвляющаяся линия соответствует переходу в потоке сообщений. Линии жизни могут объединяться в некоторой последующей отметке.

Рисунок 19 - Диаграмма последовательности №1

Сообщения (message) связывают объекты между собой и передают информацию о выполняемом действии.

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

Сообщения могут быть следующих типов:

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

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

Обычно стрелка с сообщением рисуется горизонтально. Это символизирует, что сообщение передается мгновенно и ничего не может произойти в момент передачи. Если на передачу сообщения необходимо какое-то время, в течение которого может что-нибудь произойти (например, посылка сообщения в противоположном направлении), то линия со стрелкой может быть ломаной (конец стрелки располагается ниже ее начала).

Объединенный набор сообщений может быть маркирован как итерация (iteration). Маркером итерации служи символ *. Для сценария итерация указывает, что множество сообщений может передаваться многократно. Для процедуры условие продолжения итерации может указываться в конце итерации. Возможны случаи, когда часть сообщений является частью итерации, а остальные сообщения могут быть выполнены только однократно.

Переходы (transition) рисуются как многократные стрелки, проведенные в одну точку, помеченные условием перехода. Переход может быть именован. Имя представляет собой время посылки сообщения (например: А). В случае, когда передача сообщения происходит не мгновенно, время получения отмечается именем со штрихом (например: А’). Имя может быть проставлено слева от стрелки. Имя может быть использовано для выражения, ограничивающего время посылки сообщений. Ограничения помещаются в фигурных.

Диаграммы последовательности полезны для представления параллельных процессов. Для этого в диаграммах последовательности вводятся активации (activation). Активация показывает период времени, в течение которого объект выполняет действия непосредственно или через зависимую процедуру.

Активация представляется на диаграмме длинным тонким прямоугольником, верхняя часть которого выравнивается с моментом когда метод данного объекта становиться активным, а нижняя часть - с моментом завершения работы данного метода (рис.20). Выполняемое действие может быть помечено текстом справа от символа активации (или слева, в зависимости от стиля), поочередно входящие сообщения показывают действия, которые выполняются в данном методе. В потоке управления процедуры верхняя часть символа активации предупреждает о входящем сообщении (которое инициирует действие), а нижняя часть является началом посылки возвращаемого сообщения.

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

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

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

1) Линия с заполненной стрелкой. Обозначает вызов процедуры. Может использоваться также между параллельно работающими активными объектами для посылки сигналов и ожиданий.

2) Линия с половинкой стрелки. Асинхронный поток управления. Используется для явного указания на асинхронный обмен сообщениями между двумя объектами.

3) Другие разновидности. Могут представлять другие разновидности управления, например, "balking" или "timeout", но они обычно воспринимаются как дополнительные возможности UML.

Рисунок 20 - Диаграмма последовательности №2

 

1.5.2 Кооперативные диаграммы (collaboration diagrams)

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

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

Пиктограмма объекта на кооперативной диаграмме помечается строкой имени, имеющей вид:

<ИмяОбъекта : Имя Класса>,

где имя объекта, либо имя класса могут отсутствовать. Обратите внимание, что если имя объекта отсутствует, то перед именем класса для ясности сохраняется двоеточие.

Вызов взаимодействия на диаграмме может быть представлен символом действующего лица (рис.21).

 

Рисунок 21 - Кооперативная диаграмма

 

 

1.6 Диаграммы состояний (state diagrams)

Диаграмма состояний (state diagram) определяют все возможные состояния, в которых может находиться конкретный объект, а также процесс смены состояний объекта в результате влияния некоторых событий. Диаграммы состояний строятся для единственного класса и описывают поведение единственного объекта.

Диаграмма состояний представляет собой граф состояний в которых может находиться объект и связей между ними (рис.22). Определения состояния, его семантика базируются на определении statecharts Девида Харела (за исключением небольших отличий).

 

Рисунок 22 - Диаграмма состояний №1

 

1.6.1 Состояния

Состояние (state) представляет собой отрезок времени в жизни объекта, в течение которого является истиной некоторое условие, выполняются некие действия или ожидается некоторое событие.

Состояние может иметь иерархическую структуру. Каждое подсостояние (substate) может иметь свое начальное и конечное псевдосостояния. Переход в такое состояние означает переход в начальное псевдосостояние внутри него. Переход в конечное псевдосостояние подсостояния означает завершение работы данного подсостояния; завершение работы всех подсостояний означает завершение активности данного состояния и выход из него.

Состояние представляется на диаграмме как прямоугольник с закругленными углами (рис.23). Он может иметь одну или несколько секций. В них содержатся:

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

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

Внутреннее поведение. Указывается список внутренних действий, выполняемых когда объект находится в данном состоянии. Каждое действие описывается следующим образом:

<имя события><список параметров>‘/’<действие>

Имя события может быть использовано в одном состоянии неоднократно. Существует три зарезервированных действия, имеющих тот же формат описания, что и обычное действие, но чьи имена можно использовать только однократно:

1) ‘entry’ ‘/’ <действие> - действие, выполняемое при входе в состояние;

2) ‘exit’ ‘/’ <действие> - действие, выполняемое при выходе из состояния;

3) ‘do’ ‘/’ <действие> - действие, выполняемое при нахождении в состоянии.

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

Рисунок 23 - Состояние

1.6.2 Подсостояния

 

Состояние может быть усовершенствовано введением последовательных подсостояний со связями типа “И” или взаимоисключающих подсостояний со связями типа “ИЛИ”. Любое состояние может быть усовершенствовано одним из этих способов. Его подсостояния так же могут быть усовершенствованы первым или вторым способом.

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

Объект, перешедший в конечное псевдосостояние, прекращает свое существование.

Расширение состояния представляется на диаграмме аналогичным символом. В нем кроме секций для имени состояния, переменных состояния, внутреннего поведения, имеется секция для представления вложенной диаграммы состояний (рис.24).

Расширение состояния в виде параллельных подсостояний представляется как несколько окон, расположенных в данном состоянии одно под другим и разделенных пунктирной линией (рис.24). Каждое подсостояние может иметь свое имя и может содержать вложенную диаграмму непересекающихся состояний. Секции с текстовой информацией при данном представлении отделяются сплошной линией.

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

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

Рисунок 24 - Диаграмма состояний с последовательными подсостояниями

Рисунок 25 - Диаграмма состояний с параллельными подсостояниями

1.6.3 События

Событием (event) называется заслуживающее внимания происшествие. В диаграмме состояний оно может вызывать переход из состояния в состояние.

События могут быть различных видов:

1) Обозначенное условие, обычно описанное булевским выражением, становится истинным. Описывается условием перехода без определения имени события.

2) Получение одним объектом сигнала от другого объекта. Описывается именем события, вызывающим переход.

3) Истечение определенного промежутка времени после обозначенного события. Описывается временным интервалом, по истечении которого вызывается переход.

Сигнал или вызов события может быть определен следующим образом:

<имя события>‘(’<параметр>‘,’ . . .‘)’

Параметры имеют следующий формат:

<имя параметра>‘:’<тип>

Сигнал может быть представлен как класс со стереотипом "signal" на диаграмме классов (рис.26). Параметры будут в этом случае атрибутами класса. Сигнал также может быть определен как подкласс другого сигнала.

Событие, связанное с истечением промежутка времени, описывается выражением, в котором указывается данный отрезок модельного времени, например, "5 seconds". По умолчанию, по истечении данного отрезка времени, текущее состояние покидается. В противном случае, подобные события могут быть описаны условным выражением, например:

[date = Jan. 1, 2000] или [10 seconds since exit from state A].

События могут быть объявлены на диаграмме классов как класс со стереотипом "event".

Рисунок 26 - Объявление сигнала

1.6.4 Простой переход

Простой переход (simple transition) представляет собой связь между двумя объектами, показывающую когда объект может перейти из первого состояния во второе и выполняющую определенное действие, если произошло определенное событие. Событие может иметь параметры, которые доступны для действий, определенных на переходе или для действий, инициирующих последующее событие. События обрабатываются мгновенно. Если событие не вызывает никакого перехода, то оно просто игнорируется. Если вызывается сразу несколько переходов, то инициируется только один из них; выбор может быть недетерминированным, если переходы не имеют приоритетов.

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

Данная строка имеет следующий формат:

<описание события>‘[’<условное выражение>]‘/’<действие>‘^’<посылка сообщения>

Описание события описывает событие и его аргументы:

<имя события>‘(‘<параметр>‘,’ . . . ‘)’

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

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

Посылка сообщения определяет сообщение (или сигнал), посылаемое при возникновении данного события, и имеет следующий формат:

<адресат>‘.’<имя сообщения>‘(‘<параметр>‘.’ . . . ‘)’

Переход может содержать несколько таких предложений. Порядок их расположения определяет порядок их выполнения.

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

Имя сообщения содержит в себе имя события, о котором посылается сообщение (сигнал).

Параметры передаются вместе с данным сообщением (сигналом) объекту-адресату.

Пример:

right-mouse-down (location) [location in window] / object := pick-object (location) ^ object.highlight ()

 

1.6.5 Сложный переход

 

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

Если данный объект одновременно находится во всех исходных состояниях данного перехода, то переход осуществляется. Если условие перехода становится истинным, то переход инициируется и выполняются действия, стоящие на данном переходе.

Обычно все исходные состояния должны быть активны к тому моменту, как инициируется сложный переход (complex transition). В более сложных ситуациях, условие перехода может быть расширено и может разрешать инициировать переход, когда некоторое подмножество исходных состояний активно.

Сложный переход представляется на диаграмме состояний коротким вертикальным закрашенным прямоугольником (рис.27). От прямоугольника может исходить одна или несколько линий со стрелками на конце, проведенных к конечным состояниям. К символу сложного перехода могут быть проведены одна или несколько линий со стрелками на конце, проведенных от исходных состояний. Строка перехода располагается около данного символа. Конкретные линии, проведенные к определенным состояниям не могут иметь своих строк перехода.

Рисунок 27 - Сложный переход

1.6.6 Переход в состояние со сложной структурой

 

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

Переход на диаграмме состояний, введенный за границу сложного состояния, символизирует собой переход в сложное состояние (рис.28). Это означает, что переход происходит в начальное псевдосостояние/ псевдосостояния (в случае параллельной структуры) внутри сложного состояния. Начальное псевдосостояние также может быть представлено на диаграмме. Переход может быть проведен непосредственно к любому из подсостояний системы.

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

В случае перехода в сложное состояние для каждого из начальных подсостояний выполняются необходимые входные ("entry") действия. При выходе из сложного состояния для каждого из конечных подсостояний выполняются необходимые выходные ("exit") действия.

Состояние может содержать в себе индикатор предшествующего состояния (history state indicator), представляемый на диаграмме состояний как маленький кружок с буквой "Н" внутри (рис.29). Индикатор предшествующего состояния может иметь любое количество входящих переходов, но не может иметь выходящих переходов. Если в него выполняется переход, то это означает, что объект возвращается в то состояние, в котором он пребывал, перед тем как покинуть данное сложное состояние. Необходимые входные ("entry") действия при этом также выполняются.

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

Рисунок 28 - Пример переходов в сложном состоянии

Рисунок 29 – Индикатор предшествующего состояния

1.6.7 Посылка сообщений

 

Сообщения посылаются выполняемым в объекте действием множеству объектов-адресатов. Множество объектов-адресатов может содержать в себе от одного объекта до всей системы.

Посылка сообщения на диаграмме представляется сплошной линией со стрелкой на конце, проведенной от данного объекта к объекту-адресату. Стрелка помечается именем события, списком его аргументов.

Посылка сообщений между диаграммами состояний представляется пунктирной линией со стрелкой на конце, проведенной от отправителя к адресату (рис.30).

Рисунок 30 - Посылка сообщений

 

1.7 Диаграммы деятельностей (activity diagrams)

Диаграммы деятельностей (activity diagrams) предназначены для того, чтобы отразить переходы в рамках выполнения определенной задачи, вызванные внутренними процессами (в противоположность внешним событиям). Диаграммы деятельности используются для моделирования потоков работ в различных вариантах использования, для анализа вариантов использования.

1.7.1 Основные элементы диаграммы

 

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

В диаграмме деятельностей может использоваться состояние, связанное с принятием решения - решение(decision). Решение используется в тех случаях, когда в зависимости от условий перехода, может быть выбран тот или иной переход на диаграмме.

Может показаться, что диаграмма действий является аналогом блок-схемы. Это не так. Рассмотрим диаграмму, представленную на рис.31. Обнаружить разницу можно, посмотрев на состояние действия Find Beverage. Оно активизирует два действия, связанные с поиском кофе и колы. Предположим, что кофе найден и мы стали двигаться вниз по "кофейному маршруту". Этот путь ведет к линейке синхронизации, с которой связана активация трех деятельностей - Put Coffee in Filter, Add Water to Reservoir и Get Cups. Диаграмма указывает на то, что все три деятельности могут выполняться параллельно и порядок их выполнения не играет роли. В этом и заключается главное различие между блок-схемой и диаграммой деятельностей. Блок схемы ограничиваются последовательными процессами, а диаграммы деятельностей могут поддерживать параллельные процессы.

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

Решение представляется на диаграмме как ромб, с одним или более входящим в него переходом и с одним или более выходящим переходом.

 

Рисунок 31 - Диаграмма деятельностей

1.7.2 "Плавательные дорожки"

 

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

В этом случае диаграмма деятельностей разделяется пунктирными линиями на вертикальные зоны. Каждая зона представляет собой зону ответственности конкретного класса, как это представлено на рис.32.

Рисунок 32 - Плавательные дорожки

 

1.7.3 Декомпозиция на диаграмме деятельностей

 

Любое состояние действия на диаграмме деятельностей может быть подвергнуто дальнейшей декомпозиции. Его описание может быть представлено в виде текста, кода или другой диаграммы деятельностей.

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

1.8 Диаграммы размещения (deployment diagrams)

Диаграммы размещения (deployment diagrams) отражают физические взаимосвязи между программными и аппаратными компонентами системы, а также используются для изображения маршрутов перемещения объектов в распределенной системе.

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

 

1.8.1 Компоненты

 

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

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

<тип компоненты>

Экземпляр компоненты описывается строкой с подчеркиванием, содержащей собственное имя и тип:

<имя компоненты>‘:’<тип компоненты>

Рисунок 33 - Компоненты

1.8.2 Узлы

Узел (node) - это физический объект, имеющий вычислительный ресурс, память и возможность обработки информации.

Узел представляется на диаграмме параллелепипедом (рис. 34). Тип узла описывается следующим выражением:

<тип узла>

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

<имя>‘:’<тип узла>

Тип узла описывает разновидность данного узла. Пунктирная линия, проведенная от узла к компоненте, показывает возможность данного типа узла поддерживать данный тип компонент. Узлы могут содержать экземпляры компонент - это означает, что компонента "живет" или запускается в данном узле. Компоненты могут содержать в себе объекты; это говорит о том, что объект является частью компонента. Компоненты соединяются между собой пунктирными линиями, возможно использование интерфейсов. Это говорит о том, что один компонент использует другой компонент. Использование стереотипа уточняет вид данной зависимости.

Диаграммы размещения могут быть использованы для представления того, какие компоненты запускаются в каких узлах. Для этого используется связь со стереотипом "supports". Перемещение компонента из узла в узел или объекта из компонента в компонент может быть представлено с помощью связи со стереотипом “becomes".

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

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

Рисунок 34 - Использование узлов, содержащих объекты

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.