Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование

Подождите немного. Документ загружается.

454 Глава 20. Реализация прецедента на этапе проектирования

зического оборудования. В рассматриваемом случае сигнализация со

стоит из четырех компонентов: блока управления, сирены, набора по

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

в лок управления, там можно найти плату контроллера для каждого

из типов датчиков.

Исходя из прецедентов и информации о физическом оборудовании

можно получить диаграмму классов для этой системы, представлен

ную на рис. 20.8.

Прецедент: ActivateAll (АктивироватьВсе)

Главные актеры:

SecurityGuard

Предусловия:

1. У SecurityGuard есть ключ активации.

Постусловия:

1. Система безопасности активирована.

2. Система безопасности отслеживает

датчики.

Основной поток:

1. SecurityGuard применяет ключ

активации для включения системы.

2. Система начинает отслеживать

датчики безопасности и пожарные

датчики.

3. Система воспроизводит звук

сирены, демонстрируя готовность.

Альтернативные потоки:

Нет.

ID: 2

Краткое описание:

Активирует систему.

Второстепенные актеры:

Нет.

Прецедент: DeactivateSystem

Главные актеры:

SecurityGuard

Предусловия:

1. У SecurityGuard есть ключ активации.

Постусловия:

1. Система безопасности

деактивирована.

2. Система безопасности не

отслеживает датчики.

Основной поток:

1. SecurityGuard применяет ключ

активации для выключения системы.

2. Система прекращает отслеживание

датчиков безопасности и пожарных

датчиков.

Альтернативные потоки:

Нет.

ID: 1

Второстепенные актеры:

Нет.

Краткое описание:

Деактивирует систему.

Прецедент: TriggerSensor

Главные актеры:

Fire

Intruder

Предусловия:

1. Система безопасности активирована.

Постусловия:

1. Звучит сигнал Сирены.

Основной поток:

1. Если актер Fire инициирует

пожарный датчик (FireSensor).

1.1. Сирена в

оспроизводит сигнал

пожарной тре

воги.

2. Если актер Intruder инициирует

датчик безопасности (SecuritySensor).

2.1. Сир

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

тревоги

Альтернативные потоки:

Нет.

ID: 3

Краткое описание:

Срабатывает датчик.

Второстепенные актеры:

Нет.

Рис. 20.7. Описание прецедентов системы безопасности

ControlBox

SecuritySensorMonitor FireSensorMonitor

SecuritySensor FireSensor

Siren

0..* 0..*

активный класс

Рис. 20.8. Диаграмма классов системы безопасности

20.5. Моделирование параллелизма 455

Экземплярами активных классов являются активные объекты.

Система безопасности должна непрерывно отслеживать пожарные дат

чики и датчики безопасности, поэтому необходимо использовать мно

гопоточность (multithreading). Классы ControlBox (блок управления),

SecuritySensorMonitor (монитор датчиков безопасности) и FireSensorMonitor

(монитор пожарных датчиков) показаны с двойными рамками справа

и слева. Это означает, что они являются активными классами.

20.5.2. Параллелизм на диаграммах

последовательностей

Теперь мы имеем достаточное количество информации для создания

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

прецедента ActivateAll показана на рис. 20.9. Она демонстрирует исполь

зование операторов par, loop и critical.

:Security

Guard

:ControlBox

:FireSensor

Monitor

:SecuritySensor

Monitor

activate()

monitor()

:FireSensor

:Security

Sensor

:Siren

par

monitor()

fire = isTriggered()loop 1, * [!fire]

fire()

intruder()

sd ActivateAll

soundActivatedAlarm()

soundFireAlarm()

intruder = isTriggered()

soundIntruderAlarm()

loop 1, * [(!intruder) & (!fire)]

critical

opt [!fire]

Рис. 20.9. Диаграмма последовательностей для прецедента ActivateAll

456 Глава 20. Реализация прецедента на этапе проектирования

Ниже приведен поэтапный анализ диаграммы, представленной на

рис. 20.9 .

1. Объект :SecurityGuard отправляет сообщение activate() объекту :Control

Box.

2. :ControlBox отправляет сообщение soundActivatedAlarm() объекту :Siren.

3. :ControlBox порождает два потока управления, представленные опе

рандами оператора par. Перемещаясь вниз по диаграмме, сначала

вызывается операнд 1 оператора par, а затем операнд 2 оператора par.

4. Операнд 1 оператора par:

4.1. :ControlBox отправляет сообщение monitor() объекту :FireSensor

Monitor.

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() объекту :SecuritySensor

Monitor.

6.2. :SecuritySensorMonitor входит в цикл для опроса :SecuritySensor.

При первом выполнении цикла задается начальное значение

переменной intruder, затем цикл продолжается до тех пор, пока

intruder И (AND) fire имеют значение false

6.3. Когда intruder принимает значение true:

6.3.1. Если fire имеет значение false:

6.3.1.1. :SecuritySensorMonitor посылает сообщение intru

der() объекту :ControlBox;

6.3.1.2. :ControlBox посылает сообщение soundIntruder

Alarm() объекту :Siren.

7. Операнд 2 оператора par завершается.

8. Взаимодействие завершается.

В этом взаимодействии следует отметить несколько интересных мо

ментов:

• Оба операнда par выполняются параллельно.

20.5. Моделирование параллелизма 457

• Раздел critical представляет атомарное поведение, которое не может

быть прервано. Это важное уточнение, поскольку вызов пожарного

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

быть прерван.

• Оба цикла (loop) имеют семантику Repeat...Until (повторять ... пока) –

они выполняются один раз, чтобы задать значение переменной, ис

пользуемой в их условиях, и затем повторяются до тех пор, пока их

условия остаются истинными.

• Пожарная тревога всегда должна иметь больший приоритет по от

ношению к тревоге вторжения. Поэтому loop в операнде 2 оператора

par прерывается событием fire() или intruder(). Зачем продолжать от

слеживание вторжений во время пожара! Более того, сигнал трево

ги вторжения воспроизводится только в случае отсутствия пожар

ной тревоги.

Еще хочется отметить, что на этой диаграмме показан только один Fire

Sensor (пожарный датчик) и один 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. Реализация прецедента на этапе проектирования

20.5.3. Параллелизм на коммуникационных диаграммах

Для обозначения разных потоков управления после порядкового номе

ра указывается метка потока.

Параллелизм на коммуникационных диаграммах изображают с помо

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

вого номера операции, как показано на рис. 20.11. Данная коммуни

кационная диаграмма представляет то же взаимодействие, что и на

рис. 20.9. Здесь есть два параллельных потока управления, A и B.

:Security

Guard

:ControlBox

:FireSensor

Monitor

:SecuritySensor

Monitor

activate()

monitor()

[f]: FireSensor

[s]:Security

Sensor

:Siren

par

monitor()

intruder = isTriggered()

fire = isTriggered()

fire()

sd ActivateAll

loop 1,* [!fire]

break [fire]

critical

loop 1, * [(!intruder) & (!fire)]

loop [for each s in SecuritySensor]

break [intruder & (!fire)]

intruder()

soundIntruderAlarm()

soundFireAlarm()

soundActivatedAlarm()

loop [for each f inFireSensor]

Рис. 20.10. Диаграмма последовательностей для коллекции датчиков

20.6. Взаимодействия подсистем 459

В этом примере предполагается, что есть всего один экземпляр FireSen

sor и один экземпляр SecuritySensor и что итерация является операцией

последовательного опроса, постоянно вызывающей операцию isTrig

gered() до тех пор, пока датчик возвращает значение true.

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

последовательностей на рис. 20.10? Тогда пришлось бы постоянно про

ходить набор экземпляров датчиков, опрашивая их по очереди. Для

этого необходим вложенный цикл. На коммуникационных диаграм

мах можно показать вложенные циклы, но нет способа сделать это про

сто и ясно! В сложных случаях рекомендуется использовать диаграм

мы последовательностей. Их синтаксис более четкий и гибкий.

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

На диаграммах взаимодействий подсистем можно показать взаимодей

ствия между частями системы.

После создания физической архитектуры подсистем и интерфейсов мо

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

системами. Это обеспечивает очень удобное высокоуровневое представ

ление того, как архитектура реализует прецеденты, без перехода к бо

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

Каждая подсистема рассматривается как черный ящик, который про

сто предоставляет и требует сервисы, описанные как предоставляемые

и требуемые интерфейсы. О взаимодействиях объектов внутри подсис

темы вообще не надо беспокоиться.

1.1.1 A * [!fire] :

fire = isTriggered()

:FireSensorMonitor :SecuritySensorMonitor

:ControlBox

1: activate ()

:SecurityGuard

1.1 A : monitor() 1.1 B : monitor()

:FireSensor

:Siren

1.1.1 B *[(!intruder) & (!fire)]

intruder = isTriggered()

sd ActivateAll

1.2 B :

intruder()

1.2 A :

fire()

1.3 A : soundFireAlarm()

1.3 B : soundIntruderAlarm()

:SecuritySensor

Рис. 20.11. Коммуникационная диаграмма с двумя параллельными потоками

управления

460 Глава 20. Реализация прецедента на этапе проектирования

На рис. 20.12 показана подсистема Customer с единственным интерфей

сом CustomerManager.

Рисунок 20.13 является частью диаграммы последовательностей, пред

ставляющей взаимодействие актера с данной подсистемой. Обратите

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

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

частью подключаемой подсистемы, он может иметь собственную ли

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

линии жизни.

20.7. Временные диаграммы

Одним из слабых мест UML 1 было моделирование систем реального

времени. Это такие системы, в которых временные соотношения кри

тически важны и события должны следовать друг за другом в рамках

определенного временного окна. Мы говорим «временное окно», а не

«время», потому что абсолютное время для нас как разработчиков

неприемлемо. Когда в модели задается время, на самом деле задается

время плюсминус некоторая погрешность, определяемая внешними

факторами, такими как точность системных часов. Обычно это не яв

ляется проблемой, за исключением систем с очень точными временны

ми ограничениями.

Временные диаграммы моделируют временные ограничения.

В UML 1 временные ограничения можно было обозначать на разных

диаграммах, но не было отдельной диаграммы, предназначенной имен

«subsystem»

Customer

CustomerManager

Рис. 20.12. Подсистема Customer

:Sales Agent

«subsystem»

:Customer

getCustomerDetails( cid )

customerDetails

:CustomerManager

Рис. 20.13. Диаграмма взаимодействия актера с подсистемой Customer

20.7. Временные диаграммы 461

но для моделирования временных соотношений. UML 2 предоставляет

разработчикам моделей систем реального времени временные диаграм

мы. Это разновидность диаграммы взаимодействий, основное внима

ние в которой направлено на моделирование временных ограничений.

Таким образом, она идеально подходит для моделирования этого ас

пекта систем реального времени. Временные диаграммы, аналогичные

временным диаграммам UML, в течение многих лет успешно использу

ются в электронной промышленности для моделирования временных

ограничений электронных схем.

Временные диаграммы очень просты. Время откладывается на гори

зонтальной оси слева направо. Линии жизни и их состояния (или оп

ределенные условия, накладываемые на линии жизни) располагаются

вертикально. Переходы между состояниями линий жизни и условия

ми представляются в виде графика. На рис. 20.14 приведена простая

временная диаграмма для класса Siren. Эта диаграмма иллюстрирует,

что происходит, когда формируется событие «вторжение», а затем со

бытие «пожар». Конечно, это самый пессимистичный сценарий, но

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

наружения взломщика и пожара.

Вот последовательный анализ данной временной диаграммы.

t = 0: :Siren находится в состоянии Off (выключен).

t = 10: Происходит событие intruder, и :Siren переходит в состояние

SoundingIntruderAlarm (воспроизведение сигнала тревоги втор

жения).

t = 25: Сигнал тревоги вторжения может звучать не более 15 минут

согласно местным правилам подачи сигналов тревоги. :Siren

sd IntruderThenFire

SoundingFireAlarm

SoundingIntruderAlarm

Off

:Siren

{t <= 15}

состояние или условие

линия жизни

intruder intruder

fire

cобытие

ограничение продолжительности

Resting

{t = 30}

01020304050

время в минутах

временная линейка

60 70 80 90 100

intruder

Рис. 20.14. Временная диаграмма для класса Siren

462 Глава 20. Реализация прецедента на этапе проектирования

переходит в состояние Resting (покой). Он должен находиться

в этом состоянии 30 минут (опять же по местным законам).

t = 35: Происходит событие intruder, но :Siren в состоянии Resting, по

этому не может воспроизводить сигнал тревоги.

t = 55: :Siren возвращается в состояние Off.

t = 65: Возникает еще одно событие intruder. :Siren переходит из со

стояния Off в состояние SoundingIntruderAlarm.

t = 75: Происходит событие fire. :Siren переходит из состояния Sound

ingIntruderAlarm в состояние SoundingFireAlarm (воспроизведение

сигнала пожарной тревоги).

t = 100: Взаимодействие завершается, :Siren остается в состоянии

SoundingFireAlarm.

Временные диаграммы также можно представить в более компактной

форме, когда состояния располагаются горизонтально. На рис. 20.15

в такой форме показана временная диаграмма с рис. 20.14.

В такой компактной форме акцент обычно смещается больше на со

стояния и относительное время, а не на представление абсолютного

времени, как это моделирует временная линейка.

Временные диаграммы могут использоваться для представления изме

нений состояния объекта во времени.

Временные диаграммы также могут использоваться для иллюстрации

временных ограничений во взаимодействиях между двумя или более

линиями жизни. На рис. 20.16 показано взаимодействие между лини

ями жизни :FireSensorMonitor, :IntruderSensorMonitor и :Siren.

На этой временной диаграмме следует отметить несколько интересных

моментов:

• Временнаяй диаграмма имеет три отделения, по одному для каж

дой линии жизни.

sd IntruderThenFire

Sounding

Intruder

Alarm

:Siren

{t <= 15}

Off Resting

Sounding

Intruder

Alarm

Sounding

fire

Alarm

{t = 10}

состояние или условие

{t > 30}

все промежутки времени в минутах

Off

Рис. 20.15. Компактная форма временной диаграммы с рис. 20.14

20.7. Временные диаграммы 463

• На временных диаграммах можно показать сообщения, которыми

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

• При вызове датчики обоих типов переходят в состояние Triggered

(инициирован), а затем в течение 1 секунды возвращаются в состоя

ние NotTriggered (не инициирован). Это значит, что у обоих датчиков

короткое время повторной готовности – важнейшая характеристика.

• :Siren отвечает на события вторжения только в состоянии Off. В со

стоянии Resting он игнорирует эти события. Это обусловлено мест

ными правилами, согласно которым сигнал тревоги вторжения

должен подаваться только в течение 15 минут, а затем выключать

ся, по крайней мере, на полчаса.

sd SirenBehavior

SoundingIntruderAlarm

Off

:Siren

{t <= 15}

Triggered

NotTriggered

:IntruderSensorMonitor

{t <= 15}{t = 30}

{t <= 0.016}

все промежутки времени в минутах

Resting

Triggered

NotTriggered

:FireSensorMonitor

{t <= 0.016}

SoundingFireAlarm

cообщения

soundFireAlarm()

soundIntruderAlarm()

soundIntruderAlarm()soundIntruderAlarm()

Рис. 20.16. Временная диаграмма иллюстрирует временные ограничения,

накладываемые на взаимодействия между линиями жизни