Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Uml Book (Rus).doc
Скачиваний:
15
Добавлен:
11.08.2019
Размер:
58.74 Mб
Скачать

Последовательности

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

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

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

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

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

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

D5 : ejectHatch(3)

показывает, что операция ejectHatch (с фактическим параметром 3) выполня­ется в результате получения пятого сообщения в последовательности, начатой процессом или потоком D. Асинхронный поток управления изображается с помо­щью «полустрелки» (см. главу 22).

Можно показывать не только фактические аргументы, посланные вместе с опе­рацией или сигналом в контексте взаимодействия, но и возвращаемые значения функции. Например, из выражения ниже явствует, что операция find с факти­ческим параметром "Rachelle" возвращает значение р. Это вложенная после­довательность: операция выполняется в результате второго сообщения, вложенного в третье, которое, в свою очередь, вложено в первое сообщение последовательности. На той же самой диаграмме р можно использовать в качестве фактического пара­метра других сообщений.

1.3.2 : р := find("Rachelle")

Примечание UML позволяет моделировать и более сложные виды, последователь­ностей: итерации, ветвления и охраняемые сообщения (см. главу 18). Кроме того, для моделирования временных ограничений, встречаю­щихся в системах реального времени, с последовательностью можно связать отметки времени (см. главу 23). Более экзотические виды передачи сообщений (например, тайм-ауты) допустимо моделиро­вать, определяя подходящий стереотип (см. главу 6).

Создание, модификация и уничтожение

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

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

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

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]