Литература

UML Notation Guide version 1.1. (1 September 1997)

UML Semantics version 1.1. (1 September 1997)

Object Constraint Language Specification version 1.1. (1 September 1997)

Введение

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

С середины 70-х по конец 80-х объектно-ориентированные языки моделирования возникают в виде методологий экспериментирующих с различными подходами к объектно-ориентированному анализу и проектированию. За период с 1989 по 1994 годы число языков ОО моделирования возросло с менее чем 10 до более чем 50. Однако эти методы были узко ориентированы на конкретные задачи и большинство пользователей не могли подобрать полностью отвечающего их потребностям языка. Это привело к тому, что с середины 90-х годов начинается объединение различных методов в единые, "полные" языки моделирования.

Разработка UML началась в октябре 1994 года, когда Гради Буч (Grady Booch) и Джим Рамбег (Jim Rumbaugh) из Rational Software Corporation начали работу по унифицированию метода Буча и OMT (Object Modeling Technique - техника объектного моделирования). В октябре 1995 года была представлена предварительная версия 0.8 унифицированного метода, так он был тогда назван. Во время экономического спада 1995 года Иве Иакобсон (Ivar Jacobson) и его компания Objectory объединились с Rational. Результатом объединения стало слияние унифицированного метода с методом OOSE (Object-Oriented Software Engineering).

При создании универсального языка моделирования Гради Буч, Джим Рамбег и Иве Иакобсон поставили перед собой следующие цели:

-   обеспечить моделирование систем (а не только ПО) используя ОО подход;

-   создать ясную концепцию языка;

-   решить проблему объема, возникающую в сложных системах;

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

Попытка Буча, Рамбега и Иакобсона завершилась созданием в июне и октябре 1996 года документов на версии 0.9 и 0.91 UML. В течение 1996 года Rational создает консорциум UML партнеров. Консорциум включает: DEC, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI и Unisys. Результатом их сотрудничества стало создание в январе 1997 года спецификации на UML версии 1.0.

В январе 97 к UML партнерам присоединились Object Time, Platinum Technology, Ptech, Taskon&Reich Technologies, Softeam и 1 сентября 1997 года была опубликована спецификация UML версии 1.1.

Управление моделью

Основой управления и организации модели в UML являются пакеты.

 

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

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

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

Над названием может быть помещена ключевая строка. Ключевые слова subsystem и model показывают, что этот пакет является метамоделью подсистемы или модели. Предопределенные стереотипы: system, facade, framework и topLevelPackage записываются вместе с ключевыми словами. Определенные пользователем стереотипы одного из предопределенных видов пакетов так же записываются рядом с ключевыми словами, но они не должны конфликтовать с ними.

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

Facade (фасад) является стереотипом пустого пакета, который ссылается на элементы модели, содержащиеся в другом пакете. Он обеспечивает общедоступное представление содержимого пакета.

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

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

Список свойств может быть помещен в фигурные скобки после или ниже названия пакета. Например: {abstract}.

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

Видимость элемента вне пакета может быть указана предшествующим названию элемента символом видимости ('+' для общедоступных (public), '-' для частных (private), '#' для защищенных (protected)). Если элемент это внутренний пакет, видимость его элементов как экспортируемых наружу пакета определяется комбинацией видимости элементов внутри пакета с видимостью самого пакета: результат должен в наибольшей степени ограничивать видимость.

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

Рисунок 1. Пакеты и связи между ними

 Сноски (Note)

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

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

Сноска может иметь стереотип.

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

Рисунок 2. Сноска

 

Общие механизмы расширения

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

Ограничение (constraint)

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

Ограничение изображается как текстовая строка в фигурных скобках ( { } ).

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

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

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

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

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

Комментарии (comment)

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

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

Рисунок 3. Ограничения

Свойства элементов

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

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

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

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

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

Описание свойства имеет форму:

keyword = value
(ключевое слово = значение)

где ключевое слово - это название свойства (атрибута метамодели или произвольного ярлыка), а значение - произвольная строка, которая показывает его значение. Если тип свойства - логический, то в случае, когда значение не указано по умолчанию принимается "true" (истина). (Это значит, что для описания истинного значение достаточно включить только ключевое слово; а для описания ложного значения допустимо совсем его не включать.) Для других типов свойств требуется явное указание значения.

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

{author = "Joe Smith", deadline = 31-March-1997, status = analysis}

{abstract}

Стереотипы

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

Общая идея представления стереотипа заключается в использовании символа базового элемента, но при этом над названием элемента (если оно есть) помещается ключевая строка. Ключевая строка - это название стереотипа заключенное в русские кавычки, например <foo>. Ключевая строка обычно помещается над или перед названием описываемого элемента модели. Она может также быть использована как элемент в списке. В этом случае она применяется к подмножеству элементов списка, пока другая строка стереотипа не заменит ее, или пока пустая строка стереотипа (<>) не отменит ее действие. Заметим, что название стереотипа не должно совпадать с предопределенными для данного вида элементов ключевыми словами.

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

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

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

 

Рисунок 4. Разновидности нотаций стереотипов

Диаграммы статических структур

Статическую структуру модели показывает диаграмма классов и диаграмма объектов.

Диаграммы классов показывают существующие предметы (такие как классы и типы), их внутреннюю структуру и отношения с другими предметами. Диаграммы классов не показывают временну´ю информацию, хотя они могут содержать "материализованные" события существующих предметов или предметы, которые описывают временно´е поведение. Диаграмма объектов показывает экземпляры (instance) совместимые с требованиями диаграммы классов.

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

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

Диаграмма классов представляет собой граф из элементов классификатора (classifier) соединенных различными постоянными отношениями. (Заметим, что диаграмма классов может также содержать интерфейсы, пакеты, отношения и даже экземпляры (instance), такие как объекты и связи. Возможно, более правильным было бы название "структурная статическая диаграмма", но "диаграмма классов" короче и уже присвоено.)

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

Диаграмма объектов - это граф экземпляров, включая объекты и значения данных. Статическая диаграмма объектов - это экземпляр диаграммы классов; она показывает моментальный снимок детального состояния системы в определенный момент времени. Использование диаграммы объектов довольно ограничено. В основном она показывает примеры структуры данных.

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

Классификатор (Classifier)

Классификатор - это суперкласс метамодели для класса (class), типа данных (Data Type) и интерфейса (Interface). Все они имеют похожий синтаксис и поэтому все описываются с помощью символа прямоугольника с использованием необходимого ключевого слова. Поскольку классы наиболее часто встречаются в диаграммах, прямоугольник без ключевого слова представляет класс; другие подклассы классификатора отображаются при помощи ключевых слов. В следующем разделе обсуждение сконцентрировано на классах, однако, большая часть описания применима и к другим видам элементов, как будет видно позже в их собственных разделах.

Класс

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

Семантика

Классы отражают концепцию моделируемой системы. Классы имеют структуру данных, поведение и отношения с другими элементами.

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

Нотация

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

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

Package-name::Class-name
(Название_пакета::Название_класса)

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

Варианты представления

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

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

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

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

Рекомендации по оформлению

Название класса - отцентрировать, писать с прописной буквы жирным шрифтом.

Название стереотипа - отцентрировать, использовать обычный шрифт, заключить в < > и поместить над названием класса.

Атрибуты и операции выровнять по левому краю.

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

Для названий абстрактных классов и сигнатур абстрактных операторов использовать наклонный шрифт (италик).

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

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

Пример

Рисунок 5. Описание класса: детали скрыты, детали уровня анализа, детали уровня реализации

Секция названия

Нотация

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

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

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

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

Стереотип и список свойств необязательны.

Рисунок 6. Секция названия

Секция список

Нотация

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

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

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

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

Название секции. Чтобы показать к какому виду относится секция, она может содержать название. Название отображается выделяющимся шрифтом и центрируется вверху секции. Эта возможность полезна  в случае, когда некоторые секции пропускаются или добавлены дополнительные определенные пользователем секции. Для класса предопределенные секции это attributes и operations. Примером определенной пользователем секции может быть requirements (требования). Секция названия всегда представлена для класса, следовательно, не требуется и соответственно не допускается указывать ее название.

Варианты представления

ПО может представлять список элементов в отсортированном виде. В этом случае присущий элементам порядок не видим. Сортировка базируется на некотором внутреннем свойстве и не отражает дополнительную информацию для модели. Примерами правил сортировки являются сортировка по алфавиту, сортировка по стереотипам (такая как конструкторы, деструкторы, затем обычные методы), сортировка по видимости (public, затем protected, затем private) и т.п.

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

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

Пример

Рисунок 7. Ключевые слова стереотипов, присоединенные к группам элемента списка

Рисунок 8. Секции с названиями

Атрибут

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

Семантика

Заметим, что атрибут семантически эквивалентен построению ассоциаций. Однако цель и применение обычно отличаются.

Тип атрибута - определяется выражением типа. Он может быть именем класса или быть составным, как array[String] of Point. В любом случае детали выражений, описывающих тип атрибута, не определяются в UML; они зависят от синтаксиса выражений, поддерживаемых используемым языком подробной спецификации или программирования.

Нотация

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

visibility name : type-expression = initial-value {property-string}
видимость имя : выражение-типа = начальное-значение {строка-свойств}

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

+    общедоступный (public)

#    защищенный (protected)

-    частный (private)

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

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

Для некоторых языков программирования могут потребоваться дополнительные виды видимости, как implementation видимость в C++ (фактически для всех форм не общей видимости, зависящей от языка). Такая видимость должна определяться строкой свойства или зависящим от ПО способом.

где имя - строка идентификатор, которая представляет название атрибута;

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

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

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

Глобальные для класса атрибуты (class-scope attribute) отображаются с помощью подчеркивания имени и выражения типа; иначе атрибут является локальным для экземпляра. Локальные для экземпляра атрибуты (instance-scope attribute) не подчеркиваются; по умолчанию атрибуты локальные.

class-scope-attribute

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

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

colors [3]: Color
points [2..*]: Point

Заметим, что множественность 0..1 применяется для указания возможности пустых значений: отсутствия значения, как противопоставление точному значению из интервала. Например, следующее объявление допускает различие между пустым значением и пустой строкой:

name [0..1]: String

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

Варианты представления

Выражение типа может быть скрыто (но оно все равно имеет значение в модели).

Начальное значение может быть скрыто и может отсутствовать в модели. Решение о том надо ли и как показывать это различие зависит от ПО.

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

ПО может показывать различные поля атрибута как столбцы, а не как цельную строку.

Синтаксис строки атрибута может зависеть от синтаксиса конкретного языка программирования, такого как C++ или Smalltalk. Специфические связанные свойства могут включаться в строку.

Специфические атрибуты внутри списка могут быть опущены.

Рекомендации по оформлению

Названия атрибутов обычно начинаются со строчной буквы.

Для атрибутов используется обычный шрифт.

Пример

+size: Area = (100,100)
#visibility: Boolean = invisible
+default-size: Rectangle
#maximum-size: Rectangle
-xptr: XWindowPtr

Операция

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

Семантика

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

Нотация

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

visibility name (parameter-list): return-type-expression {property-string}
видимость имя (список-параметров): выражение-возвращаемого-типа {строка-свойств}

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

+    общедоступный (public)

#    защищенный (protected)

-    частный (private)

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

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

Для некоторых языков программирования могут потребоваться дополнительные виды видимости, как implementation видимость в C++  (фактически для всех форм не общей видимости, зависящей от языка). Такая видимость должна определяться строкой свойства или зависящем от ПО способом.

где имя - строка идентификатора;

где выражение-возвращаемого-типа зависящее от языка описание реализации типа или типов значений возвращаемых операцией. Если выражение не возвращает значения, то возвращаемый тип опускается (C++ void). Для указания множественности возвращаемых значений применяется список выражений.

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

kind name : type-expression = default-value
вид имя : выражение-типа = значение-по-умолчанию

где вид - это in, out или inout, по умолчанию in;

где имя - название формального параметра;

где выражение-типа - зависящее от языка описание реализации типа;

где значение-по-умолчанию - необязательное выражение значения для параметра, выраженное и подчиненное ограничениям окончательного целевого языка;

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

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

Операция, которая не модифицирует состояние системы (не имеет побочных эффектов) описывается свойством {query}; иначе, операция может изменять состояние системы, однако нет гарантий, что это действительно происходит.

Семантика параллелизма операций определяется строкой свойств с одним из следующих имен: sequential, guarded, concurrent. В отсутствии описания семантика параллелизма неопределенна и в худшем случае должна быть назначена последовательная.

Самое верхнее появление сигнатуры операции объявляет операцию на классе (и, следовательно, наследуется всеми его наследниками). Если класс не реализует операцию (т.е. отсутствует метод), то операция либо маркируется как {abstract} либо сигнатура операции пишется курсивом, чтобы показать ее абстрактность. Любое последующее появление сигнатуры операции показывает, что подчиненный класс реализует метод операции. (Описание {abstract} или курсив в подчиненном классе не указали бы на метод, но такое использование нотации было бы плохим стилем.)

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

Запись операции со стереотипом {signal} показывает, что класс принимает определенный сигнал.

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

Ключевое слово стереотипа предшествует строке операции, включая индикаторы видимости. Список свойств в скобках следует за строкой операции.

Варианты представления

Список аргументов и возвращаемое значение могут быть опущены (одновременно).

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

Синтаксис строки операции может зависеть от синтаксиса конкретного языка программирования, такого как C++ или Smalltalk. Специфические связанные свойства могут включаться в строку.

Рекомендации по оформлению

Названия операции обычно начинаются со строчной буквы.

Для операций используется обычный шрифт.

Абстрактные операции могут показываться курсивом.

Пример

Рисунок 9. Список с различными видами операций

+display (): Location
+hide ()
+create ()
-attachXWindow(xwin:XWindow*)

Приём сигнала

Прием и ответ объекта класса на определенный сигнал отображается использованием такого же синтаксиса, как для операции с ключевым словом {signal}. Ответ объекта на принимаемый сигнал изображается конечным автоматом. Одним из использований этой нотации является ответ объекта класса на состояния неисправности и исключения, которые моделируются как сигналы.

 

 

 

Класс типа против класса реализации

Семантика

С помощью стереотипов классы могут разделяться на классы типов и реализаций (хотя они могут оставаться и не разделенными). Тип характеризует изменчивую роль, которую объект может временно принимать. Класс реализации определяет материальные структуру данных и процедуры объекта, как это реализовано в традиционных языках (C++, Smalltalk и т.д.). Объект может иметь множество классов типа (которые могут изменяться динамически), но только один класс реализации (который фиксирован). Хотя использование классов типов и реализаций отличается, их внутренняя структура одинакова, поэтому они моделируются как стереотипы класса. Все виды классов требуют, чтобы подкласс полностью поддерживал все особенности суперкласса, включая поддержку всех унаследованных атрибутов, ассоциаций и операций.

Нотация

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

Реализация типа классом реализации моделируется как отношение реализации, показываемое пунктирной линией с непрерывным треугольником указателя стрелки (пунктирная "стрелка обобщения"). Этот символ подразумевает наследование операций, но не структуры (атрибутов или ассоциаций).

Пример

Рисунок 10. Нотация для классов типов и реализаций

 

Интерфейсы

Семантика

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

Нотация

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

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

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

Пример

Рисунок 11. Нотация интерфейса на диаграмме класса

Параметризованный класс (шаблон)

Семантика

Шаблон - это описатель для класса с одним или более несвязанными параметрами. Что, следовательно, определяет семейство классов, каждый класс определяется связыванием параметров с реальными значениями. Обычно параметры представляют собой типы атрибутов, но могут также представлять целые числа, другие типы или даже операции. Атрибуты и операции в шаблоне определяются в терминах формальных параметров, поэтому они становятся связанными, как только шаблон непосредственно связывается с действительными значениями.

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

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

Нотация

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

Варианты представления

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

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

name : type
название : тип

где название - идентификатор параметра с областью действия внутри шаблона;

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

Если тип опущен, то ему назначается выражение типа, такое как название класса или тип данных, для которых суперклассом является классификатор. Другие типы параметров (такие как Integer) должны явно показываться; они должны являться допустимым выражением типа.

Пример

Рисунок 12. Нотация шаблона с использованием параметров как ссылок

Связанный элемент

Семантика

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

Нотация

Связанный элемент обозначается текстовым синтаксисом в строке имени элемента, следующим образом:

Template-name  '<' value-list '>'
Название-шаблона  '<' список-значений '>'

где список-значений - разделенный запятыми не пустой список выражений значений;

где название-шаблона идентично названию шаблона.

Например, VArray<Point,3> обозначает класс, описанный шаблоном VArray.

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

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

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

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

Рекомендации по оформлению

В связанном классе секции атрибутов и операций обычно опускаются, так как они не изменяются по сравнению с шаблоном.

Утилита

Утилита - группировка глобальных переменных и процедур в форме объявления класса. Это не фундаментальная конструкция, а средство повышения удобства программирования. Атрибуты и операции из утилиты становятся глобальными переменными и процедурами. Утилита моделируется как стереотип класса.

Семантика

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

Нотация

Отображается с помощью стереотипа класса . Имеет и атрибуты и операции, которые все являются глобальными.

Пример

Рисунок 13. Нотация для утилиты

 

 

Метакласс

Семантика

Метакласс - это класс, чьи экземпляры являются классами.

Нотация

Отображается с помощью стереотипа класса .

Путь класса

Нотация

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

Package-name::Class-name
(Название_пакета::Название_класса)

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

Пример

Рисунок 14. Путь до классов из других ракетов

Импортирование пакета

Семантика

Класс может вызываться из другого пакета. На уровне пакетов зависимость "импорта" показывает, что содержимое целевых пакетов может вызываться из клиентских пакетов или пакетов рекурсивно внедренных в них. Цели ссылок должны иметь видимость достаточную для ссылок. Видимость может быть определена как для элементов модели, так и для пакетов. Если элемент модели вложен в один или более пакет, то видимость элемента и всех его контейнеров объединяется согласно правилу, выбирающему наиболее ограниченную видимость из набора. Невозможно избирательно экспортировать некоторые элементы из вложенного пакета; видимость внешнего пакета применяется к каждому экспортируемому элементу внутреннего пакета. Импорт является рекурсивным для вложенных уровней пакетов. Зависимый класс должен иметь, по крайней мере, видимость "protected", любые другие классы требуют видимость "public". (Более подробно это описано в документе по семантике.)

Заметим, что зависимость импорта не изменяет пространства имен клиента и не создает автоматически ссылки; она просто дает возможность установить ссылки. Заметим также, что ПО может при создании ссылки автоматически создавать импортную зависимость.

Нотация

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

Пример

Рисунок 15. Зависимость импорта между пакетами

 

Объект

Семантика

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

Нотация

Нотация объекта получается из нотации класс подчеркиванием элементов уровня экземпляра.

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

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

objectname : classname

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

display_window: WindowingSystem::GraphicWindows::Window

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

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

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

objectname : classname '[' statename-list ']'

 

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

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

attributename : type = value
названиеатрибута : тип = значение

Тип уже присвоен при объявлении атрибута класса и поэтому может быть опущен.

Значение определяется как символьное значение. UML не определяет синтаксис символьных выражений, но ожидает, что ПО определит такой синтаксис, использую некоторый язык программирования.

Варианты представления

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

Класс объекта может быть опущен (вместе с двоеточием).

Секция значений атрибутов может быть полностью скрыта.

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

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

Рекомендации по оформлению

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

Варианты

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

Пример

Рисунок 16. Объекты

Составные объекты

Семантика

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

Нотация

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

Пример

Рисунок 17. Составной объект

Ассоциация

Бинарные ассоциации показываются как линии, соединяющие два символа классов.

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

Бинарная ассоциация

Семантика

Бинарная ассоциация является ассоциацией точно между двумя классами (включая возможность рефлексивной ассоциации от класса к самому себе).

Нотация

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

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

Конец ассоциации, которым она присоединяется к классу, называется ролью ассоциации. Наиболее интересная информация об ассоциации заключена в ее ролях. Подробности смотрите разделе роль ассоциации.

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

название ассоциации

Обозначает (необязательное) название ассоциации.

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

символ класса ассоциации

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

Показывается как символ класса, присоединенный пунктирной линией к пути ассоциации.

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

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

Варианты представления

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

Рекомендации по оформлению

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

Варианты

Ассоциация-ИЛИ. Ограничение ИЛИ показывает ситуацию, в которой для любого одиночного объекта может быть одновременно реализована только одна из нескольких потенциальных ассоциация. Это показывается как пунктирная линия, соединяющая две или более ассоциации, которые все должны иметь общий класс, со строкой ограничения "{or}" помечающей пунктирную линию. Любой экземпляр класса может иметь в конкретный момент времени только одну из ассоциаций. Все названия ролей должны различаться. (Это простое предопределенное использование описания ограничения.)

Пример

Рисунок 18. Нотация ассоциации

Цель ассоциации

Семантика

Цель ассоциации является просто концом ассоциации, которым она присоединяется к классу. Это часть ассоциации, а не часть класса. Каждая ассоциация имеет две или более цели. Наиболее интересные подробности относительно ассоциации заключены в ее целях. Цель ассоциации не является отдельным элементом; она только механическая часть ассоциации.

Нотация

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

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

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

неупорядочены - элементы формируют неупорядоченный набор. Это является умолчанием и не требует явного указания.

упорядочены - элементы набора упорядочены в список. Это по-прежнему набор и дубликаты запрещены. Эта общая спецификация включает все виды упорядочения. Она может быть определена с помощью ключевого слова {ordered}.

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

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

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

 

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

навигация

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

указатель конгломерата

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

Если ромб заполнен, то это выражает сильную форму конгломерата, известную как композиция (composition).

название роли

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

описатель интерфейса

Название классификатора со следующим синтаксисом:

':' classifiername
':' название классификатора

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

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

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

изменчивость

Если связи изменяются (могут быть добавлены, удалены или перемещены), то никаких указаний на это не требуется. Свойство {frozen} показывает, что связи объекта (находящегося на конце с данным "украшением") не могут быть добавлены, удалены или перемещены после того, как объект создан и инициализирован. Свойство {addOnly} показывает, что связи могут быть добавлены (возможно, множественность является переменной), но не могут быть модифицированы или удалены.

видимость

Определяется индикатором видимости ('+', '#', '-' или явно заданным ключевым словом,  например, {public}) перед названием роли. Определяет видимость ассоциации со стороны заданного наименования роли.

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

Варианты представления

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

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

Вариант представления 1: Показаны все стрелки. Отсутствие стрелки показывает, что навигации нет.

Вариант представления 2: Подавлены все стрелки. О навигации нельзя сделать никаких выводов. Это типичная ситуация когда информации опущена при показе.

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

Рекомендации по оформлению

Если у одной роли есть несколько украшений, то они выводятся в следующем порядке, начиная от конца пути, присоединенного к классу, в направлении основной части пути:

спецификатор;

символ конгломерата;

навигационные стрелки.

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

Пример

Рисунок 19. Различные украшения на ролях ассоциаций

Множественность

Семантика

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

Нотация

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

lower-bound .. upper-bound
нижняя-граница .. верхняя-граница

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

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

Если определено единственное целочисленное значение, то диапазон содержит это единственное значение.

Если описание множественности состоит из одной звездочки (*), то это означает неограниченный неотрицательный целочисленный интервал, то есть является эквивалентом *..* = 0..* (ноль или больше).

Множественность 0..0 бессмысленна, так как это означало бы, что множество всегда пустое.

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

Рекомендации по оформлению

Предпочтительно чтобы интервалы монотонно возрастали. Например, "1..3,7,10" предпочтительнее чем "7,10,1..3".

Два смежных интервала должны объединяться в один интервал. Например, "0..1" предпочтительнее чем "0,1".

Пример

0..1

1

0..*

*

1..*

1..6

1..3,7..10,15,19..*

Спецификатор

Семантика

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

Нотация

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

Множественность, присоединенная к целевой роли, обозначает возможную мощность множества целевых объектов выбранных объединением объекта источника и значения спецификатора. Обычно применяются следующие значения: "0..1" (уникальное значение может быть выбрано, но каждое возможное значение спецификатора не обязательно выбирает значение), "1" (каждое возможное значение спецификатора выбирает уникальный целевой объект, следовательно, область значений спецификатора должна быть конечной) и "*" (значение спецификатора индекс, который разделяет целевые объекты на подмножества).

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

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

Варианты представления

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

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

Рекомендации по оформлению

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

Пример

Рисунок 20. Спецификаторы ассоциаций

Класс ассоциации

Семантика

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

Нотация

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

Варианты представления

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

Рекомендации по оформлению

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

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

Пример

Рисунок 21. Класс ассоциации

 

N-арные ассоциации

Семантика

N-арные ассоциации - это ассоциации между 3 и более классами (один класс может появляться больше одного раза). Каждый экземпляр ассоциации является кортежем n значений из соответствующих классов. Бинарная ассоциация является частным случаем со своей собственной нотацией.

Множественность может определяться и для n-арных ассоциаций, но является менее очевидной, чем двоичная множественность. Множественность на роли представляет потенциальное количество экземпляров кортежей в ассоциации, когда другие N-1 значения фиксированы.

N-арные ассоциации не могут содержать символ конгломерата на любой из ролей.

Нотация

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

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

Рекомендации по оформлению

Обычно линии рисуются из вершин ромба или середин его сторон.

Пример

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

Рисунок 22. Тернарная ассоциация, которая также является классом ассоциации

Композиция

Семантика

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

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

Нотация

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

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

rolename ':' classname

Это определяет название роли класса в ассоциации композиции по отношению к составному элементу.

Альтернативно, композиция показывается украшением на конце пути ассоциации в виде сплошного заполненного ромба присоединенного к элементу целого. Множественность показывается обычным способом.

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

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

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

Рекомендации по проектированию

Эта нотация применима к подобным классу элементам модели: классам, типам, узлам, процессам и т.д.

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

Пример

Рисунок 23. Различные способы показа композиций

Связи

Семантика

Связь - кортеж (список) ссылок на объекты. Наиболее часто, это пара ссылок на объекты. Она является экземпляром ассоциации.

Нотация

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

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

Спецификатор может показываться для связи. Значения спецификатора могут показываться в его прямоугольнике.

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

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

         параметр процедуры

                  локальная переменная процедуры

                глобальная переменная

                    связь с самим собой (способность объекта послать себе сообщение)

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

Пример

Рисунок 24. Связи

Обобщение

Семантика

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

Нотация

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

Путь обобщения может иметь текстовую метку следующего формата:

discriminator
дискриминатор

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

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

Варианты представления

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

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

Подробности

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

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

Предопределены следующие ограничения:

Overlapping перекрывающийся	Потомок может происходить более чем из одного подкласса.
disjoint непересекающийся	Потомок не может происходить более чем из одного подкласса.
complete завершенный	Все подклассы определены (во всяком случае, показаны). Дополнительных подклассов не ожидается.
incomplete незавершенный	Некоторые подклассы определены, но известно, что их список незавершен. Имеются дополнительные подклассы, которые пока отсутствуют в модели. Это утверждение непосредственно о модели. Заметим, что это не эквивалентно многоточию, которое констатирует, что дополнительные подклассы существуют в модели, но не показаны на текущей диаграмме.

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

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

Пример

Рисунок 25. Стили отображения обобщения

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

Рисунок 27. Обобщение с совместным представлением цели

Зависимость (Dependency)

Семантика

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

Нотация

Зависимость показывается пунктирной стрелкой между двумя элементами модели. Элемент модели на хвосте стрелки зависит от элемента модели на острие стрелки. Стрелка может быть помечена необязательным стереотипом и необязательным названием.

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

trace - Trace следит - След	Историческое соединение между двумя элементами, которые представляют одинаковое понятие на разных уровнях значимости.
Refine - Refinement уточняет - Уточнение	Историческое или возникшее соединение между двумя элементами с отображением (не обязательно полным) между ними. Описание отображения может быть присоединено к зависимости в примечании. Были предложены различные виды уточнений, которые могут быть указаны дальнейшим стереотипированием.
Uses - Usage использует -  Использование	Ситуация в которой элемент требует присутствия другого элемента для корректной реализации и функционирования. Может стереотипироваться дальше для указания точного характера зависимости, например, вызов операций другого класса, предоставление прав доступа, иллюстрирующий объект другого класса, и т.д.
Bind - Binding связывает - Связывание	Связывание параметров шаблона с действительными значениями для создания не параметризованного элемента.

Варианты представления

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

Пример

Рисунок 28. Варианты использования зависимостей между классами

Рисунок 29. Зависимости между пакетами

Производный элемент (derived element)

Семантика

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

Нотация

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

Рекомендации по оформлению

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

Пример

Рисунок 30. Производный атрибут и производная ассоциация

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

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

Диаграмма случаев использования

Семантика

Диаграммы случаев использования показывают элементы модели случаев использования. Модель случаев использования представляет функциональные возможности системы или класса как они проявляются при внешнем взаимодействии с системой.

Нотация

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

Пример

Рисунок 31. Диаграмма случаев использования

Случай использования

Семантика

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

Нотация

Случай использования изображается как эллипс, содержащий название случая использования.

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

Варианты представления

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

Рекомендации по оформлению

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

Действующее лицо

Семантика

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

Нотация

Действующее лицо может показываться как прямоугольник класса со стереотипом "actor". Стандартная картинка стереотипа для действующего лица рисунок человечка с названием действующего лица под рисунком.

Рекомендации по оформлению

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

Отношения случаев использования

Семантика

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

Communicates (Общается) - Участие действующего лица в случае использования. Это отношение только между действующими лицами и случаями использования.

Extends (Расширяет) - Отношения расширяет от случая использования А к случаю использования Б показывает, что экземпляр случая использования Б может включать (подчиненное специфическим условиям определенным в расширении) поведение определяемое А. Поведение, определяемое несколькими расширителями одного целевого случая использования, может реализовываться одним экземпляром случая использования.

Uses (Использует) - Отношение использует от случая использования А к случаю использования Б показывает, что экземпляр случая использования А будет также включать поведение определяемое Б.

Нотация

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

Отношение "extends" между случаями использования показывается стрелкой обобщения от случая использования, обеспечивающего расширение к основному случаю использования. Стрелка помечается стереотипом .

Отношение "uses" между случаями использования показывается стрелкой обобщения от использующего случая использования к используемому случаю использования. Стрелка помечается стереотипом .

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

Пример

Рисунок 32. Отношения случая использования

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

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

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

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

Диаграммы последовательности имеют несколько немного различных форматов предназначенных для различных целей.

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

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

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

Семантика

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

Нотация

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

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

(Заметим, что большинство из этих описаний напрямую взято из нотаций Object Message Sequence Chart Buschmann-а, Meunier-а, Rohnert-а, Sommerlad-а и Stal-а, которая сама получена из нотации Message Sequence Chart.)

Варианты представления

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

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

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

Пример

Рисунок 33. Простая диаграмма последовательности с параллельными объектами

Рисунок 34. Диаграмма последовательности с фокусом управления, условием, рекурсией, созданием и уничтожением

Линия жизни объекта

Семантика

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

Нотация

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

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

Пример

Смотри Рисунок 34.

Активация

Семантика

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

Нотация

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

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

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

Пример

Смотри Рисунок 34.

Сообщение

Семантика

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

Нотация

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

Варианты представления

Разновидность: Асинхронное. Асинхронное сообщение рисуется с половинкой острия (с одним крылом вместо двух).

Разновидность: Вызов. Вызов процедуры рисуется с полным острием. Возврат показывается пунктирной стрелкой.

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

Разновидность: В параллельной системе полное острие показывает создание нити управления (семантика ожидания), а половина острия показывает посылку сообщения без создания управления (семантика без ожидания).

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

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

Разновидность: Итерация. Связанное множество сообщений может быть выделено и отмечено как итерация. Для сценария итерация показывает, что множество сообщений может повторяться много раз. Для процедуры, условие продолжения итерации может быть определено в ее конце. В случае параллелизма некоторые сообщения на диаграмме могут быть частью итерации, а другие могут выполняться один раз. Желательно упорядочивать диаграмму так, чтобы сообщения итерации легко выделялись вместе.

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

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

Время переходов

Семантика

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

Нотация

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

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

Пример

Смотри Рисунок 33.

Диаграммы сотрудничества

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

Сотрудничество

Семантика

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

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

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

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

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

Нотация

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

Диаграмма сотрудничества

Семантика

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

Нотация

Диаграмма сотрудничества является графом ссылок на объекты и связи с потоками сообщений присоединенных к этим связям. Диаграмма показывает объекты важные для выполнения операции, включая объекты задействованные или доступные во время операции косвенно. Сотрудничество, использованное для описания операции, включает ее аргументы и локальные переменные, создаваемые в процессе выполнения, а так же обычные ассоциации. Объекты, создаваемые в процессе выполнения, могут быть обозначены как {new}; объекты, уничтожаемые в процессе выполнения, могут быть обозначены как {destroyed}; объекты, созданные в процессе выполнения и затем уничтоженные, могут быть обозначены как {transient}. Эти изменения в состоянии существования выводятся из подробностей сообщений, пересылаемых между объектами; и предусмотрены для удобства представления.

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

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

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

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

Пример

Рисунок 35. Диаграмма сотрудничества

Структура шаблона

Семантика

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

Заметим, что шаблоны, определенные в Design Patterns Гэме (Gamma), Хелмом (Helm), Джонсоном (Johnson) и Влисайдсом (Vlissides), включают много больше чем структурные описания. UML описывает структурные и некоторые поведенческие аспекты проектных шаблонов, однако нотация UML не включает другие важные аспекты шаблонов, такие как использование компромиссов и примеров. Они должны быть выражены в тексте или таблицах.

Нотация

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

Пример

Рисунок 36. Использование сотрудничества

Содержимое сотрудничеств

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

Семантика

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

Нотация

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

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

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

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

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

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

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

Семантика

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

Нотация

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

Пример

Сотрудничества подчеркивающие взаимодействие смотри разделе Диаграммы Сотрудничества.

Роли сотрудничества

Семантика

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

Нотация

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

Роль класса показывается в виде прямоугольного символа класса. Обычно показывается только название сотрудничества. Название сотрудничества содержит строку:

classRoleName : Classifiername

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

display_window: WindowingSystem::GraphicWindows::Window

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

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

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

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

Варианты представления

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

Класс объекта может быть опущен (вместе с двоеточием).

Пример

Смотри Рисунок 35.

Мультиобъект

Семантика

Мультиобъект представляет собой множество объектов на "множественной" цели ассоциации. Он используется для показа операций, которые адресуют скорее все множество, чем отдельный элемент из него. Базовая статическая модель не затрагивается такой группировкой. Это соответствует ассоциации с множественностью "много" используемой для доступа к множеству ассоциированных объектов.

Нотация

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

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

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

Обычно сообщение выбора к мультиобъекту возвращает ссылку на конкретный объект, которому первоначальный отправитель посылает сообщение.

Пример

Рисунок 37. Мультиобъект

Активный объект

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

Семантика

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

Нотация

Роль активного объекта показывается как символ объекта с толстой рамкой. Часто роли активных объектов показываются виде комплекса с вложенными частями.

Для указания активного объекта может использоваться ключевое слово {active}.

Рисунок 38. Составной активный объект

Потоки сообщений

Семантика

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

Нотация

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

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

заполненное сплошное острие

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

остовное острие       

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

половинка остовного острия

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

другие разновидности

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

Метка сообщения. Метка имеет следующий синтаксис:

 predecessor-guard-condition sequence-expression return-value := message-name argument-list
 условие-защиты-по-предшественнику выражение-порядка возвращаемое-значение := название-сообщения список-аргументов

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

Предшественник. Предшественник - разделенный запятыми список порядковых номеров с последующей косой чертой ('/'):

sequence-number ',' ... '/'

Если список пуст, то выражение опускается.

Каждый порядковый номер - это выражение порядка без повторения элементов. Он должен соответствовать порядковому номеру другого сообщения.

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

Заметим, что сообщение, численно соответствующее предшествующему порядковому номеру, является неявным предшественником и не требует явного перечисления. Для порядковых номеров с одинаковым префиксом, числовым предшественником является номер, в котором последний элемент на единицу меньше. То есть номер 3.1.4.5 предшественник для 3.1.4.6.

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

[ integer | name ][ recurrence ]
[ целое число | название ][ рекуррентность ]

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

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

Рекуррентность определяет условное или итерационное выполнение. Это означает, что сообщение выполняется ноль или более раз в зависимости от присутствующих условий. Варианты:

'*' '[' iteration-clause ']'
'*' '[' оператор-итерации ']'   Итерация

'[' condition-clause ']'
'[' условный-оператор ']'   Ветвление

Итерация представляет последовательность сообщений на заданном уровне вложенности. Оператор итерации может быть опущен (когда условие итерации не определено). Оператор-итерации задается в псевдокоде или с помощью реального языка программирования; UML не определяет его формат. Примером может быть *[i := 1..n].

Условие определяет сообщение, выполнение которого возможно в случае истинности условного оператора. Оператор-итерации задается в псевдокоде или с помощью реального языка программирования; UML не определяет его формат. Примером может быть [x > y].

Заметим, что ветвление описывается также как и итерация, только без звезды; его можно считать итерацией ограниченной однократным возникновением.

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

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

Сигнатура. Сигнатура - строка, которая показывает название, аргументы и возвращаемое значение операции, сообщения или сигнала. Она имеет следующие свойства:

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

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

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

 

Варианты представления

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

Синтаксис сообщений может быть заменен синтаксисом языка программирования, например C++ или Smalltalk. Однако все выражения на одной диаграмме должны использовать одинаковый синтаксис.

Пример

Примеры на диаграмме смотри на Рисунок 35.

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

2: display (x, y)                            простое сообщение
1.3.1: p:= find(specs)                  вложенный вызов с возвращаемым значением
[x < 0] 4: invert (x, color)            условное сообщение
A3,B4/C3.1*: update ()              синхронизация с другими нитями, итерация

Маркеры создания/уничтожения

Семантика

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

Нотация

Объекты или связи, которые создаются в период взаимодействия, имеют как ограничение ключевое слово new. Объекты или связи, которые уничтожаются в период взаимодействия, имеют как ограничение ключевое слово destroyed. Ключевое слово может использоваться даже, если элемент не имеет названия. Оба ключевых слова могут использоваться совместно, но лучше использовать ключевое слово transients.

Варианты представления

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

Пример

Смотри Рисунок 35.

 

Диаграммы схем состояния

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

Семантика и нотация, описанные в этой главе, по существу представляют собой схемы состояния Дэвида Харела (Devid Harel), модифицированные так, чтобы они стали объектно-ориентированными. Его работа стала существенным развитием традиционных простых конечных автоматов. Нотация схем состояния также реализует подходы традиционных моделей конечных автоматов Мура (Moore) и Мейли (Mealy).

Диаграмма схем состояния

Семантика

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

Нотация

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

Пример

Рисунок 39. Диаграмма состояния

Состояния

Семантика

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

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

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

Нотация

Состояние изображается прямоугольником с закругленными углами. Оно может содержать одну или больше секций. Все они необязательные. Определены следующие секции:

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

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

event-name argument-list '[' quard-condition ']''/' action-expression
 название-события список-аргументов '[' условие-защиты ']''/' выражение-действия

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

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

'entry' '/' action-expression
'entry' '/' выражение-действия           Атомарное действие, выполняемое при входе в состояние.

'exit' '/' action-expression
'exit' '/' выражение-действия              Атомарное действие, выполняемое при выходе из состояния.

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

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

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

'do' '/' machine-name (argument-list)
'do' '/' название-автомата (список-аргументов)

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

Пример

Рисунок 40. Состояние

Составные состояния

Семантика

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

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

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

Нотация

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

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

Детализация состояния на разобщенные подсостояния изображается показом вложенной диаграммы состояний в графической области.

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

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

Пример

Рисунок 41. Последовательные подсостояния

Рисунок 42. Параллельные подсостояния

События

Семантика

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

выделенное условие становится истинным (обычно описывается как логическое выражение). Это - Событие Изменения. Оно описывается ключевым словом when с последующим логическим выражением в круглых скобках. Событие происходит, когда значение выражения изменяется с ложного на истинное. Заметим, что оно отличается от условия защиты: Условие защиты вычисляется одновременно с возникновением его сообщения; если оно ложно, то переход не происходит и сообщение теряется. Например: when(баланс < 0).

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

получение объектом запроса операции. Это - Событие Вызов. Оно описывается сигнатурой операции, как условием инициирования, на переходе. Визуальных отличий от события сигнала нет; предполагается, что они различаются по названиям.

завершение назначенного периода времени после выделенного события (часто наступления текущего состоянием) или наступление заданных даты/времени. Это - Событие Времени. Оно описывается временным выражением, как условием инициирования, на переходе. Одним из распространенных временных выражений является отсчет времени от момента наступления текущего состояния; что описывается ключевым словом after с последующим количеством времени в круглых скобках. Например: after (10 seconds).

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

Нотация

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

event-name '(' comma-separated-parameter-list ')'
название-события '(' разделенный-запятыми-список-параметров ')'

Параметр имеет формат:

parameter-name ':' type-expression
название-параметра ':' выражение-типа

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

Событие времени работы может задаваться ключевым словом after с последующим выражением, которое вычисляет (в моделируемом времени) величину времени, например "after (5 секунд)" или "after (10 секунд после выхода из состояния А)". Если стартовая точка не указана, то берется момент наступления текущего состояния. Другие события времени могут задаваться как условия, например when (дата = 1 янв 2000).

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

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

Пример

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

Простые переходы

Семантика

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

Нотация

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

event-signature '[' guard-condition ']' '/' action-expression '^' send-clause
сигнатура-события '[' условие-защиты ']' '/' выражение-действия '^' операция-отправки

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

event-name '(' parameter ',' ... ')'
название-события '(' параметр ',' ... ')'

Условие-защиты является логическим выражением, описанным в терминах параметров условия инициирования события, а так же атрибутов и связей объекта, которому принадлежит конечный автомат. Условие защиты также может включать проверки параллельных состояний текущего автомата (или явно назначенные состояния некоего достижимого объекта): например, "in State1" или "not in State2". Названия состояний могут быть полностью представлены, содержащими их, вложенными состояниями, создающими путь названий в форме "State1::State2::State3"; это может применяться в случае, когда в различных областях составных состояний полного автомата встречаются одинаковые названия состояний.

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

Операция-отправки является специальным случаем действия, с форматом

destination-expression '.' destination-message-name '(' argument '.' ... ')'
выражение-назначения '.' название-сообщения-назначения '(' параметр '.' ... ')'

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

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

Название-сообщения-назначения является названием сообщения (операции или сигнала) осмысленным для объекта(ов) назначения.

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

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

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

Пример

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

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

Составные переходы

Составные переходы могут иметь многочисленные исходные и целевые состояния. Он представляет синхронизацию и/или разбиение управления на параллельные нити без параллельных подсостояний.

Семантика

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

Нотация

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

Пример

Рисунок 44. Составной переход

Переходы во вложенные состояния

Семантика

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

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

Нотация

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

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

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

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

Область состояний может содержать индикатор истории состояний, изображаемый окружностью с буквой 'H'. Индикатор истории относится к непосредственно содержащей его области состояния. Индикатор истории может иметь любое количество входящих переходов из внешних состояний и максимум один непомеченный переход, который идентифицирует "предыдущее состояние" по умолчанию, если в область никогда не входили. Возбуждение перехода в индикатор истории показывает, что объект возвращается в состояние, которое было последним в составной области; при этом выполняются любые необходимые входные действия. Для глубокой истории может применяться индикатор 'H*'. Он показывает, что объект скорее возвращается в состояние, которое было последним на какой-нибудь глубине составной области, чем в состояние заключенное в том же уровне, что и индикатор истории. Область может иметь одновременно поверхностные и глубокие индикаторы истории.

Варианты представления

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

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

Пример

Примеры составных переходов смотри на рисунках Рисунок 42 и Рисунок 44. Ниже показаны примеры оборванных переходов и индикатора истории.

Рисунок 45. Оборванные переходы

Рисунок 46. Индикатор истории

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

Семантика

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

Нотация

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

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

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

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

Символом отправителя может быть:

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

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

Приемником может быть:

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

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

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

Пример

Рисунок 47. Посылка сообщений

Рисунок 48. Создание и уничтожение объектов

Внутренние переходы

Семантика

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

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

Нотация

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

Пример

Рисунок 49. Состояние с внутренними переходами

Диаграмма активности

Диаграмма активности

Семантика

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

Нотация

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

Пример

Рисунок 50. Диаграмма активности

Состояние действия

Семантика

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

Нотация

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

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

Варианты представления

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

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

Пример

Рисунок 51. Деятельность

Решения

Семантика

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

Нотация

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

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

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

Пример

Рисунок 52. Решение

Дорожки процессов

Семантика

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

Нотация

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

Пример

Рисунок 53. Дорожки процессов на диаграмме активности

Отношения потока объект-действие

Семантика

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

Нотация

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

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

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

Объект в состоянии. Часто один и тот же объект управляется несколькими последовательными действиями. Можно показать стрелки к и от всех соответствующих действий. Однако для большей ясности, объект может быть показан на диаграмме много раз, каждое появление обозначает различные моменты в процессе его жизни. Чтобы отличить разные появления одного объекта, на каждой точке появления может помещаться заключенное в скобки и присоединенное к названию объекта его состояние, например, PurposeOrder[approved]. Такое описание может также использоваться на диаграммах сотрудничества.

Пример

Рисунок 54. Действия и поток объектов

Пиктограммы управления

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

Стереотипы

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

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

Рисунок 55. Символы приема и посылки сигналов

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

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

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

Рисунок 56. Отложенное событие

Диаграммы реализации

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

Компонентная диаграмма

Семантика

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

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

Нотация

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

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

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

Пример

Рисунок 57. Компонентная диаграмма

Диаграммы развертывания

Семантика

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

Нотация

Диаграмма развертывания представляет граф узлов соединенных ассоциациями связи. Узлы могут содержать экземпляры компонентов; они показывают, что компоненты "живут" или работают в узле. Компоненты могут содержать объекты; это означает, что является частью компонента. Компоненты соединяются с другими компонентами пунктирными стрелками зависимостей (возможно через интерфейс). Это значит, что один компонент использует сервисы другого компонента; при необходимости для показа точного вида зависимости может использоваться стереотип.

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

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

Заметим, что процесс представляет собой всего лишь специальный вид объектов (смотри Объект Действие).

Пример

Рисунок 58. Узлы

Узлы

Семантика

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

Нотация

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

Тип узла имеет название типа:

node-type
тип-узла

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

name ':' node-type
название ':' тип-узла

Название является названием конкретного узла (ели оно есть). Тип узла показывает вид узла. Любой из элементов или оба вместе являются необязательными.

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

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

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

Пример

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

Рисунок 59. Использование узлов для хранения объектов

Компоненты

Семантика

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

Нотация

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

Тип компонента имеет название типа:

тип-компонента

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

название-компонента ':' тип-компонента

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

Пример

Пример показывает компонент с интерфейсами и компонент содержащий объекты времени выполнения.

Рисунок 60. Компоненты

Расположение экземпляров и объектов внутри объекта

Семантика

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

Нотация

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

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

Пример

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