Диаграммы последовательностей: изображение обмена сообщениями в UML

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

Элементы и отношения представлены в UML в виде диаграмм. UML2 различает 14 различных типов диаграмм. Они относятся к одной из трех различных категорий: диаграммы структуры, диаграммы поведения и диаграммы взаимодействия.

Диаграммы структуры представляют систему и ее компоненты в статическом состоянии. Они иллюстрируют отношения между отдельными элементами или между элементами и вышестоящими концепциями. Примером может служить диаграмма классов.

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

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

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

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

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

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

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

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

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

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

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

Линии жизни показывают, как долго объект активно участвует в процессе. Это видно по тому, насколько длинна одна линия жизни по сравнению с другими. Некоторые объекты уничтожаются до завершения процесса. Объекты, которые больше не нужны, отмечаются на линии жизни знаком «X» в точке, где они должны быть уничтожены.

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

• Сущность
• Граница
• Управление

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

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

Границы обозначают интерфейсы, которые взаимодействуют с внешними субъектами. Такими объектами могут быть, например, пользовательские интерфейсы — в этом случае действующим лицом будет человек. Сущности, с другой стороны, представляют собой контейнеры данных или объекты, содержащие системные данные. Чтобы границы и сущности могли взаимодействовать, необходим элемент управления. Элемент управления не обязательно должен быть объектом. Метод, приписанный к одному из двух других элементов, также подходит. Управляющий элемент соединяет сущность и границу в качестве посредника. Он отслеживает сигналы обоих элементов и проверяет их на логичность.

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

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

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

[имя сообщения] : [атрибут «=»] имя сигнала или операции[аргументы] [«:» возвращаемое значение].

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

• • Константы
  • Значения Wildcard (символические значения, представляющие законное значение X на диаграмме)
  • Атрибуты отправителя
  • Параметры окружающего взаимодействия
  • Атрибуты вышестоящего класса

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

Это стандартизированные типы сообщений в диаграмме последовательности UML:

• Асинхронные сообщения типа (MessageSort) asynchCall, подключаются к операции и запускают ее выполнение. При использовании асинхронных сообщений система не ждет ответа от получателя, а продолжает свои процессы без перерыва. Параметры операции и атрибуты сообщения должны совпадать.
  • Условные обозначения: Асинхронные сообщения можно представить в виде стрелки с непрерывной линией и открытым наконечником.
  • Отправка и получение асинхронных сообщений: Этот вид сообщения возникает в результате действия асинхронной передачи сигнала. В этом случае атрибуты сигнала определяют аргументы сообщения.
• Синхронные сообщения запрашивают только операции, а не сигналы. Тип сообщения — synchCall. Синхронные сообщения ждут ответа от операции, прежде чем возобновить свое поведение. Синхронные сообщения отображаются в виде стрелки с заполненным наконечником.
• Ответ — получатель сообщения отправляет ответ обратно отправителю после того, как операция пришла к результату. Символ для этого имеет открытый или заполненный наконечник стрелки. Соответствующая линия является пунктирной.
• createMessage — это тип сообщения, который сигнализирует о создании нового экземпляра линии жизни. Система создает новый объект на диаграмме последовательности. Этот тип сообщения является единственным, который ссылается непосредственно на головку линии жизни. Другие сообщения должны указывать на пунктирную линию жизни. createMessage имеет стрелку с открытым наконечником и пунктирную линию, как у ответа, но направленную в противоположном направлении.
• Сообщение deleteMessage сигнализирует о том, в какой момент времени выполнения экземпляр линии жизни уничтожается. Сообщение об удалении рисуется в виде стрелки с заголовком <>> (это необязательно). Оно всегда должно указывать на спецификацию события уничтожения. Также называемая событием уничтожения, эта спецификация событий отмечает уничтожение объекта на линии времени выполнения символом «X».

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

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

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

Особой функцией является параметр подстановочного знака. Если в сообщении отсутствуют все параметры, синтаксис требует пустой строки. Этот символ указывает на то, что значение параметра не является фиксированным. Тем не менее, оно является допустимым с точки зрения параметров или атрибутов получателя — действует как подстановочный знак. Символы подстановочного знака являются заменителями отдельных букв или целых строк символов. Многие знают звездочку (*) как подстановочный знак. В UML дефис («-«) обозначает параметр подстановочного знака.

Сообщения ответа могут иметь только одно выражение с максимум одним операндом на параметр. Если отправитель ответа не выводит никаких значений, сообщение также не имеет конкретных значений, которые он отправляет. Обычно сообщение моделирует выходные параметры отправителя (значения, получаемые в результате операции) как операнды. Без выходных параметров операнд должен оставаться пустым. В этом случае вы просто моделируете заполнитель подстановочного знака, а не значение перемотки. Если операнд есть, система снова оценивает его в спецификации внешнего вида. Результат оценки определяет значения для параметров «out», «inout» и «return».

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

• Неизвестно
• Параметр взаимодействия
• Атрибут

Unknown — пустой параметр и обозначает подстановочный знак. Параметр взаимодействия является собственным параметром взаимодействия, которому он присущ. Это означает, что взаимодействие имеет параметр. У параметра есть имя. Параметры операции и взаимодействия имеют один и тот же тип. Атрибуты могут быть названы без ограничений. Они представляют собой имя поведения контекста. Это поведение определяет либо линию жизни, на которую возвращается сообщение, либо окружающее взаимодействие. Если взаимодействие не определяет никакого поведения, оно само выступает в качестве контекста.

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

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

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

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

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

Нотация UML для диаграмм коммуникаций предписывает простую рамку диаграммы последовательности. Прямоугольник с пятиугольной меткой в головной части. В метке обозначение «sd» отмечает этот тип диаграммы. Рядом с ним обратите внимание на название взаимодействия. Сообщения здесь принимают другую форму — они соединяют прямоугольные линии жизни (UML: узлы объектов) в виде простых прямых линий (UML: ребра).

Над ним запишите выражение последовательности вместе со стрелкой, указывающей в направлении приемника. Имя последовательности имеет следующий вид: [Целочисленное имя][Повторение]. Целое число задает иерархию для вложенных элементов. Если одно из целых чисел (например, 1.2.2 и 1.2.3) отличается в двух сообщениях, система отправляет их одно за другим. Название, с другой стороны, означает одновременную передачу. Система посылает два сообщения с именами последовательности 1.2.3a и 1.2.3b одновременно из-за одинакового целого числа. Повторение содержит либо ограничение, определяющее время отправки сообщения, либо значение, определяющее частоту повторения сообщения.

В UML охрана определяет поведение элемента. Элемент должен либо:

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

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

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

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

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

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

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

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

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

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

• Имя атрибута (атрибут линии жизни в утилите взаимодействия, которая получает возвращаемое значение)
• Имя взаимодействия (идентифицированные полезности взаимодействия, которые связывают взаимодействия и взаимодействия)
• Имя взаимодействия вызываемого элемента
• io-аргумент: входящие/исходящие аргументы взаимодействия
• Возвращаемое значение (ответ вызванного взаимодействия)

Вы моделируете преимущество взаимодействия в виде прямоугольника с пятиугольной меткой в верхнем левом углу. Введите в это поле аббревиатуру «ref».

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

Частичная декомпозиция — это частичная, последовательная декомпозиция линии жизни в рамках взаимодействия через другое взаимодействие. Используя такую декомпозицию, вы можете отделить детали друг от друга и более внимательно рассмотреть отдельные подфункции. Когда сообщения входят или выходят из разобранной линии жизни, они считаются фактическими воротами. Они связаны с формальными воротами действия декомпозиции. Ворота и параметры обоих элементов должны совпадать. В качестве преимущества взаимодействия частичная декомпозиция также получает метку «ref» и определяется связанным с ней взаимодействием.

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

Семантика трассировки спецификации выполнения представлена простой структурой <start,end>. Нотация для спецификации выполнения допускает две формы. Модель длинного, узкого квадрата с серой заливкой на линии жизни. Обычно активация в такой форме не включает метку в тело. В качестве альтернативы нарисуйте на линии жизни немного более широкий прямоугольник с белой заливкой. Там у вас будет место, чтобы дать полосе активности метку. Если объект выполняет действие во время выполнения, введите имя действия там.

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

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

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

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

Инвариант состояния — это ограничение во время выполнения. Линия жизни представляет объект. Во время выполнения этот объект меняет свое состояние из-за спецификации выполнения. Вариант состояния проверяет объект на изменение его состояния в спецификации выполнения — непосредственно перед выполнением следующей спецификации появления. После этого все предыдущие неявные действия в рамках спецификации исполнения считаются выполненными.

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

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

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

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

UML определяет 12 операторов взаимодействия

Альтернативный:

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

Страж:

Guard проверяет, выполняется ли условие операнда. Если да, то система посылает сообщение в область условия. Если нет, то посылается сообщение в альтернативной области. Для выполнения операнда в этом комбинированном фрагменте всегда требуется защита, которая оценивается как истинная. Если операнд условия не имеет явной защиты, то предполагается неявная защита. Таким образом, этот фрагмент всегда является решением «или-или».

Вариант:

Этот комбинированный фрагмент моделируется на диаграмме последовательности как альтернатива. Он также обозначает решение. Однако здесь имеется только один операнд. Поэтому решение принимается на основании того, должен ли операнд быть выполнен или нет. Операнд с условием не должен быть пустым. Его альтернатива, напротив, пуста. Пометьте фрагмент с оператором взаимодействия «Option» меткой «opt.».

Break:

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

Петля:

Комбинированный фрагмент с оператором взаимодействия «loop» повторяет свой операнд. Точное количество проходов определяется монитором. Этот монитор может включать барьеры повторения и булевы переменные. Обратите внимание на барьеры повторения в метке кадра: loop (X,Y). Переменные X и Y представляют собой натуральное число. X — это минимальное количество повторений («min-int»). Y — максимальное число повторений («max-int»). X должно быть неотрицательным числом, Y — неотрицательным числом, равным или большим минимального числа (т.е. > 0).

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

Например, в банкомате вы можете ввести правильный PIN-код три раза. Если PIN-код неверный, вас попросят повторить ввод. На диаграмме последовательности UML обратите внимание на сообщение «Ввод PIN-кода» и его ответ «Неправильный PIN-код. Повторите попытку с помощью соответствующих стрелок». Метка имеет вид Loop (0,2). Булевская переменная — [неправильный PIN-код]. Пока PIN-код неправильный, цикл повторяется дважды. Если PIN-код правильный, система разрешает цикл. Если максимальное число повторений превышено, цикл также ослабевает, но процесс завершается как недействительный.

Параллель:

Обычно положение стрелки на линии жизни в диаграмме последовательности всегда предписывает хронологический порядок. В комбинированном фрагменте с оператором взаимодействия parallel его операнды могут выполнять свои процессы одновременно. Потенциально операнды переплетают порядок выполнения своих процессов. Однако заданный порядок внутри операндов всегда сохраняется. На диаграмме последовательности UML смоделируйте этот комбинированный фрагмент с помощью непрерывной рамки. Разделите различные операнды оптически пунктирными линиями, аналогично альтернативному варианту. Введите в метку сокращение «par» (см. иллюстрацию в разделе «Критическая область»). Если операнды должны работать параллельно на одной линии жизни, UML допускает сокращение: область co-region выполняет именно эту задачу. Для этого просто заключите в квадратные скобки записи событий, на которые они влияют.

Критическая секция:

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

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

Утверждение:

Оператор взаимодействия «Assertion» (также Assurance или Backup) определяет состояние продолжения. Последовательности внутри операнда с меткой assert считаются действительными продолжениями. Утверждение утверждает, что все последовательности за пределами фрагмента заканчиваются недопустимыми продолжениями.

Игнорировать/рассмотреть:

Диаграмма последовательностей UML подробно представляет часть системы. Некоторые сообщения вам не нужны для представления. Другие вы хотите принять во внимание. Вы используете оператор взаимодействия «игнорировать», чтобы исключить определенные сообщения. Эта информация появляется на дорожке в системе, но не во фрагменте игнорирования. Нотация предписывает метку в таком виде: ignore {message1,message2}.

Комбинированные фрагменты с оператором взаимодействия «consider», с другой стороны, рассматривают определенные сообщения во фрагменте. Все остальные сообщения, проходящие через фрагмент, игнорируются системой. Вы также можете заключить сообщения в скобки для рассмотрения: consider {Message3,Message4}.

Эти два оператора имеют противоположные задачи. Однако оба они часто встречаются во вложенных фрагментах. Например, моделисты часто комбинируют assert с ignore (в таком виде: assert ignore {Msg1, Msg2}) или assert и consider (в таком виде: assert consider {Msg3, Msg4}).

Отрицательный:

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

Строгий порядок:

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

Слабая последовательность:

Комбинированные фрагменты с оператором взаимодействия «sequence» представляют собой слабый порядок. Поведение между операндами во фрагменте влияет на свойства трассировки вместо операторов взаимодействия. Поэтому слабая секвенция может действовать как параллельный фрагмент. Это происходит, когда операнды участвуют на разных линиях жизни. В свою очередь, слабая секвенция превращается в строгий порядок, когда ее операнды появляются на одной линии жизни. Обозначение — «seq».

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

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

Продолжение:

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

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