Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 83

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

Текст из файла (страница 83)

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

20.9. Она демонстрирует использование операторов par, loop и critical.sd ActivateAll:SecurityGuard:ControlBox:SecuritySensorMonitor:FireSensorMonitor:FireSensor:SecuritySensoractivate()soundActivatedAlarm()parmonitor()loop 1, * [!fire]fire = isT riggered()criticalfire()soundFireAlarm()monitor()loop 1, * [(!intruder) & (!fire)]intruder = isT riggered()opt [!fire]intruder()soundIntruderAlarm()Рис. 20.9. Диаграмма последовательностей для прецедента ActivateAll:Siren456Глава 20.

Реализация прецедента на этапе проектированияНиже приведен поэтапный анализ диаграммы, представленной нарис. 20.9 .1. Объект :SecurityGuard отправляет сообщение activate() объекту :ControlBox.2. :ControlBox отправляет сообщение soundActivatedAlarm() объекту :Siren.3. :ControlBox порождает два потока управления, представленные операндами оператора par. Перемещаясь вниз по диаграмме, сначалавызывается операнд 1 оператора par, а затем операнд 2 оператора par.4. Операнд 1 оператора par:4.1.

:ControlBox отправляет сообщение monitor() объекту :FireSensorMonitor.4.2. :FireSensorMonitor входит в цикл для опроса :FireSensor. При первом выполнении цикла задается начальное значение переменной fire, затем цикл продолжается до тех пор, пока fire имеетзначение false.4.3. Когда fire принимает значение true:4.3.1. :FireSensorMonitor входит в раздел critical, где:4.3.1.1. Он посылает сообщение fire() в :ControlBox.4.3.1.2.

:ControlBox посылает сообщение soundFireAlarm()объекту :Siren.5. Операнд 1 оператора par завершается.6. Операнд 2 оператора par:6.1. :ControlBox посылает сообщение monitor() объекту :SecuritySensorMonitor.6.2. :SecuritySensorMonitor входит в цикл для опроса :SecuritySensor.При первом выполнении цикла задается начальное значениепеременной intruder, затем цикл продолжается до тех пор, покаintruder И (AND) fire имеют значение false.6.3. Когда intruder принимает значение true:6.3.1. Если fire имеет значение false:6.3.1.1. :SecuritySensorMonitor посылает сообщение intruder() объекту :ControlBox;6.3.1.2.

:ControlBox посылает сообщение soundIntruderAlarm() объекту :Siren.7. Операнд 2 оператора par завершается.8. Взаимодействие завершается.В этом взаимодействии следует отметить несколько интересных моментов:•Оба операнда par выполняются параллельно.20.5. Моделирование параллелизма•••457Раздел critical представляет атомарное поведение, которое не можетбыть прервано. Это важное уточнение, поскольку вызов пожарногодатчика является критически важным для безопасности и не можетбыть прерван.Оба цикла (loop) имеют семантику Repeat...Until (повторять ... пока) –они выполняются один раз, чтобы задать значение переменной, используемой в их условиях, и затем повторяются до тех пор, пока ихусловия остаются истинными.Пожарная тревога всегда должна иметь больший приоритет по отношению к тревоге вторжения. Поэтому loop в операнде 2 оператораpar прерывается событием fire() или intruder(). Зачем продолжать отслеживание вторжений во время пожара! Более того, сигнал тревоги вторжения воспроизводится только в случае отсутствия пожарной тревоги.Еще хочется отметить, что на этой диаграмме показан только один FireSensor (пожарный датчик) и один SecuritySensor (датчик безопасности).Конечно, этого достаточно для иллюстрации поведения, но, возможно,вам захочется показать итерацию системы по нескольким датчикамSecuritySensor и нескольким FireSensor.

Для этого придется изменить диаграмму так, как показано на рис. 20.10, и ввести еще два внутреннихцикла для прохода по коллекции датчиков.Оба операнда на рис. 20.10 с точки зрения цикла ведут себя одинаково, поэтому в качестве примера был выбран верхний из них, которыйотслеживает FireSensor.Как видите, внешний цикл остался неизменным. А новый внутреннийцикл по очереди перебирает все датчики FireSensor. Это можно показатьс помощью выражения цикла:[for each f in FireSensor]Тогда селектор [f] может использоваться для обозначения на диаграммепоследовательностей FireSensor, выбранного циклом в качестве линиижизни, и ему может быть отправлено сообщение isTriggered(). В этом цикле есть комбинированный фрагмент break, который прерывает внутренний цикл и выполняет свой операнд, когда fire принимает значениеtrue.

При этом, как и ранее, мы попадаем в критическую секцию.Важно сохранять максимальную простоту диаграмм последовательностей. Основное внимание в реализации прецедента должно быть направлено на иллюстрацию возможных взаимодействий классов приреализации описанного прецедентом поведения. Для данного примерапрецедента ActivateAll диаграммы, показанной на рис. 20.9, вероятно,достаточно для представления основного поведения системы, особенноесли снабдить ее несколькими комментариями. А рис. 20.10 всетакислишком подробный.458Глава 20. Реализация прецедента на этапе проектированияsd ActivateAll:SecurityGuard:ControlBox:SecuritySensorMonitor:FireSensorMonitor[f]: FireSensor[s]:SecuritySensor:Sirenactivate()soundActivatedAlarm()parmonitor()loop 1,* [!fire]loop [for each f inFireSensor]fire = isTriggered()break [fire]criticalfire()soundFireAlarm()monitor()loop 1, * [(!intruder) & (!fire)]loop [for each s in SecuritySensor]intruder = isTriggered()break [intruder & (!fire)]intruder()soundIntruderAlarm()Рис.

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

Данная коммуникационная диаграмма представляет то же взаимодействие, что и нарис. 20.9. Здесь есть два параллельных потока управления, A и B.45920.6. Взаимодействия подсистемsd ActivateAll1.3 A : soundFireAlarm()1.3 B : soundIntruderAlarm()1: activate ():SecurityGuard:Siren:ControlBox1.1 A : monitor():FireSensorMonitor1.2 A :fire()1.2 B :intruder()1.1 B : monitor():SecuritySensorMonitor1.1.1 B *[(!intruder) & (!fire)]:intruder = isTriggered()1.1.1 A * [!fire] :fire = isTriggered():FireSensor:SecuritySensorРис.

20.11. Коммуникационная диаграмма с двумя параллельными потокамиуправленияВ этом примере предполагается, что есть всего один экземпляр FireSensor и один экземпляр SecuritySensor и что итерация является операциейпоследовательного опроса, постоянно вызывающей операцию isTriggered() до тех пор, пока датчик возвращает значение true.А если бы датчиков было много, как предполагалось для диаграммыпоследовательностей на рис. 20.10? Тогда пришлось бы постоянно проходить набор экземпляров датчиков, опрашивая их по очереди. Дляэтого необходим вложенный цикл. На коммуникационных диаграммах можно показать вложенные циклы, но нет способа сделать это просто и ясно! В сложных случаях рекомендуется использовать диаграммы последовательностей.

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

О взаимодействиях объектов внутри подсистемы вообще не надо беспокоиться.460Глава 20. Реализация прецедента на этапе проектированияCustomerManager«subsystem»CustomerРис. 20.12. Подсистема CustomerНа рис. 20.12 показана подсистема Customer с единственным интерфейсом CustomerManager.Рисунок 20.13 является частью диаграммы последовательностей, представляющей взаимодействие актера с данной подсистемой. Обратитевнимание, как изображен интерфейс: в прямоугольнике, примыкающем снизу к пиктограмме подсистемы. Поскольку интерфейс являетсячастью подключаемой подсистемы, он может иметь собственную линию жизни, и сообщения могут направляться непосредственно к этойлинии жизни.«subsystem»:Customer:Sales Agent:CustomerManagergetCustomerDetails( cid )customerDetailsРис.

Характеристики

Список файлов книги