2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 59
Текст из файла (страница 59)
Если это синхронный вызов, то объект Traderбудет ждать, пока операция закончится.cобытие времени(абсолютное)На заметку. В некоторых случаях возникает необходимостьв изображении объекта, который посылает сигнал сразунескольким объектам (мультивещание, multicasting) или всеможидающим объектам в системе (широковещание, broadcasting). Для моделирования мультивещания следует изобразить объект, посылающий сигнал набору, в который входятвсе получатели. Для моделирования широковещания нужнопоказать, что один объект посылает сигнал другому, представляющему систему в целом.cобытие времени(относительное)when (altitude < 1000)Рис.
21.4. События времени и измененияСобытие изменения происходит один раз при изменении значения условия с ложного на истинное (но не наоборот). Пока условиеостается истинным, событие не повторяется.На заметку. Хотя событие изменения моделирует условие,проверяемое непрерывно, обычно, проанализировав ситуацию, можно выявить дискретные моменты времени, когдаэто условие нужно проверять.Передача и получение событийПроцессыи потоки обсуждаютсяв главе 23.В событиях сигнала и вызова участвуют по меньшей мере дваобъекта: тот, который посылает сигнал или инициирует операцию,и тот, которому событие адресовано. Поскольку сигналы по своейприроде асинхронны, а асинхронные вызовы сами по себе являются307Конечныеавтоматыобсуждаются в главе 22,активныеобъекты –в главе 23.Любой экземпляр любого класса может быть получателем события вызова или сигнала.
Если это синхронное событие вызова, то отправитель и получатель находятся в состоянии «рандеву» на всем протяжении выполнения операции. Это означает, что поток управленияотправителя блокируется, пока операция не завершится. Если этосигнал, то отправитель и получатель не входят в состояние «рандеву»:отправитель посылает сигнал, но не дожидается ответа от получателя.В любом случае событие может быть потеряно (если явно не указано, что нужен ответ), вызвать переход состояния в автомате получателя, если он существует, или инициировать обычный вызов метода.На заметку.
Вызов может быть асинхронным. В этом случае отправитель продолжает выполнение своих действийсразу после отправления сигнала. Передача сообщения и егообработка получателем происходят параллельно с действиями отправителя. Когда выполнение метода завершается,он просто заканчивается. Если метод пытается вернуть значения, то они игнорируются.Диаграммы деятельности308Операциии классыобсуждаютсяв главе 4.Интерфейсыобсуждаются в главе 11,асинхронныеоперации –в главе 23.В UML события вызова, которые получает объект, моделируются как операции класса этого объекта. Именованные сигналы,получаемые объектом, моделируются путем перечисления в дополнительном разделе класса, как показано на рис.
21.5.«сигналы»Рис. 21.5. Сигналы и активные классыНа заметку. Точно так же можно присоединить именованныесигналы к интерфейсу. В любом случае имена сигналов, перечисленные в дополнительном разделе, являются не объявлениями, а лишь указаниями на то, что сигнал используется.Типичные приемы моделированияТипичные приемы моделированияв котором переход срабатывает при получении сигнала HardwareFault.В этом случае переход полиморфен: его вызывает как сам сигналHardwareFault, так и любая его специализация (разновидность), включая BatteryFault, MovementFault и MotorStall.Для моделирования семейства сигналов следует: Рассмотреть все разновидности сигналов, на которые можетотвечать данное множество активных объектов.
Выявить схожие виды сигналов и поместить их в иерархиютипа «обобщение/специализация», используя наследование.На верхних уровнях иерархии будут располагаться общиесигналы, а на нижних – специализированные. Определить возможности полиморфизма в автоматах этихактивных объектов. При обнаружении полиморфизма скорректировать иерархию, добавив в случае необходимости промежуточные абстрактные сигналы.На рис.
21.6 приведена модель семейства сигналов, которыеАбстрактмогли бы обрабатываться автономным роботом. Обратите вниные классыобсуждают- мание, что корневой сигнал RobotSignal (СигналРоботу) являетсяабстрактным, то есть непосредственное создание его экземпляровся в главе 5невозможно.
У этого сигнала есть две конкретные специализациии 9.(Collision и HardwareFault), одна из которых (HardwareFault) специализируется и дальше. Заметьте, что у сигнала Collision есть одинпараметр.Моделирование семейства сигналовВ большинстве систем, управляемых событиями, события сигналов образуют иерархию. Например, автономный робот можетразличать внешние сигналы, такие как Collision (Столкновение),и внутренние, например HardwareFault (АппаратныйОтказ). Однакомножества внешних и внутренних сигналов могут пересекаться.И даже внутри этих двух широких областей классификации можнообнаружить частные разновидности.
К примеру, HardwareFault можноподразделить на BatteryFault (ОтказБатареи) и MovementFault (ОтказДвигательногоМеханизма). Допускается и дальнейшая специализация. Так, разновидностью сигнала MovementFault является MotorStall(ОстановЭлектромотора).КонечныеМоделируя подобным образом иерархии сигналов, можно специавтоматыфицировать полиморфные события. Рассмотрим, к примеру, автомат,обсуждают- в котором некоторый переход срабатывает только при получениися в главе 22 сигнала MotorStall. Поскольку этот сигнал является в иерархии листовым, то переход инициируется только им, так что полиморфизмотсутствует.
Но предположим теперь, что вы построили автомат,Обобщенияобсуждаются в главе 5и 10.309«сигнал»«сигнал»«сигнал»«сигнал»«сигнал»«сигнал»«сигнал»«сигнал»Рис. 21.6. Моделирование семейства сигналов310Диаграммы деятельностиМоделирование аварийных ситуацийВажная часть визуализации, специфицирования и документирования поведения класса или интерфейса – выявление аварийныхситуаций, которые могут порождать его операции. Если вы имеетедело с некоторым классом или интерфейсом, то его операции ясныиз описания, но понять, какие аварийные ситуации они могут вызвать, нелегко, если это явно не указано в модели.В UML аварийные ситуации представляют собой разновидность событий и моделируются как сигналы. СобытияFошибкиможно присоединить к спецификации операций.
Моделированиеисключений в некотором смысле противоположно моделированиюсемейств сигналов. Основная цель последнего – специфицировать,какие сигналы могут получать активные объекты; цель же моделирования аварийных ситуаций состоит в том, чтобы показать, какиеаварийные ситуации может порождать объект.Чтобы выполнить эту задачу, требуется: Для каждого класса и интерфейса и для каждой определенной в них операции рассмотреть нормальные и аварийныеситуации и смоделировать их в виде сигналов, передаваемыхмежду объектами. Организовать иерархию сигналов: на верхних уровнях разместить общие сигналы, на нижних – специализированные,и при необходимости ввести промежуточные исключения.
Указать для каждой операции, какие аварийные ситуации(сигналы) она может порождать. Это можно сделать явнона диаграмме (проведя зависимости со стереотипом sendот операции к ее сигналам) или же использовать диаграммыпоследовательности, изображающие различные сценарии.КлассыNшабНа рис. 21.7 представлена модель иерархии аварийных ситуалоны обсуж- ций, которые могут порождаться контейнерными классами из стандаютсядартной библиотеки, например классомFшаблоном Set (Установв главе 9.ка).
В корне этой иерархии находится абстрактный сигнал SetError(УстановитьОшибку), а ниже расположены специализированныевиды ошибок: Duplicate (Дублирование), Overflow (Переполнение)и Underflow (Потеря значимости). Как видно, операция add (добавить) может породить сигналы Duplicate и Overflow, а операция remove(удалить) – только сигнал Underflow. Вместо этого можно было быубрать зависимости с переднего плана, перечислив их в спецификации каждой операции. Как бы то ни было, зная, какие сигналы может породить операция, вы сможете успешно создавать программы,использующие класс Set.Классы обсуждаютсяв главе 4 и 9,интерфейсы –в главе 11,стереотипы – в главе 6.Типичные приемы моделирования311На заметку.
Сигналы, в том числе аварийных ситуаций, – этоасинхронные события, происходящие между объектами. UMLтакже предусматривает исключения, которые можно обнаружить в таких языках программирования, как Ada или С++.Исключение является условием, при котором основной потоквыполнения задачи прерывается и выполняется другой поток.Исключения – это не сигналы; они просто представляют собойудобный механизм для спецификации альтернативного потокауправления внутри единственного синхронного потока выполнения задачи.SetErroritem«send»«send»«send»Рис. 21.7.
Моделирование условий ошибкиСоветы и подсказкиПри моделировании событий исходите из следующих соображений: стройте иерархию сигналов так, чтобы можно было воспользоваться общими для них свойствами; не забывайте ассоциировать подходящий автомат с каждымэлементом, который может получать события; обязательно моделируйте не только те элементы, которыемогут получать события, но и те, которые могут их посылать.Изображая событие в UML, в общем случае моделируйте иерархии событий явно, а их использование специфицируйте на заднемплане тех классов или операций, которые посылают или получаютсобытие.Введение313ВведениеГлава 22. Конечные автоматыВ этой главе:Взаимодействияобсуждаются в главе 16,объекты –в главе 13.Классы обсуждаютсяв главах 4и 8, варианты использования –в главе 17,системыв главе 32,диаграммыдеятельности – в главе20, диаграммысостояний –в главе 25.Состояния, переходы и деятельностиМоделирование жизненного цикла объектаСоздание хорошо структурированных алгоритмовИспользуя взаимодействие, можно моделировать поведение сообщества совместно работающих объектов.
При помощи конечногоавтомата можно смоделировать поведение отдельного объекта. Автомат – это поведение, которое специфицирует последовательностьсостояний объекта, через которые он проходит в течение своегожизненного цикла в ответ на события, а также реакции на эти события.Автоматы используются для моделирования динамическихаспектов поведения системы. Большей частью этот процесс подразумевает спецификацию жизненного цикла экземпляров класса,варианта использования или системы в целом. Эти экземплярымогут реагировать на такие события, как сигналы, операции либоистечение некоего периода времени.