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

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

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

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Рис. 20.13. Диаграмма взаимодействия актера с подсистемой Customer20.7.

Временные диаграммыОдним из слабых мест UML 1 было моделирование систем реальноговремени. Это такие системы, в которых временные соотношения критически важны и события должны следовать друг за другом в рамкахопределенного временного окна. Мы говорим «временное окно», а не«время», потому что абсолютное время для нас как разработчиковнеприемлемо. Когда в модели задается время, на самом деле задаетсявремя плюсминус некоторая погрешность, определяемая внешнимифакторами, такими как точность системных часов.

Обычно это не является проблемой, за исключением систем с очень точными временными ограничениями.Временные диаграммы моделируют временные ограничения.В UML 1 временные ограничения можно было обозначать на разныхдиаграммах, но не было отдельной диаграммы, предназначенной имен46120.7. Временные диаграммыно для моделирования временных соотношений. UML 2 предоставляетразработчикам моделей систем реального времени временные диаграммы. Это разновидность диаграммы взаимодействий, основное внимание в которой направлено на моделирование временных ограничений.Таким образом, она идеально подходит для моделирования этого аспекта систем реального времени.

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

Переходы между состояниями линий жизни и условиями представляются в виде графика. На рис. 20.14 приведена простаявременная диаграмма для класса Siren. Эта диаграмма иллюстрирует,что происходит, когда формируется событие «вторжение», а затем событие «пожар». Конечно, это самый пессимистичный сценарий, носмоделировать его важно, чтобы понять взаимодействие функций обнаружения взломщика и пожара.Вот последовательный анализ данной временной диаграммы.t = 0::Siren находится в состоянии Off (выключен).t = 10:Происходит событие intruder, и :Siren переходит в состояниеSoundingIntruderAlarm (воспроизведение сигнала тревоги вторжения).t = 25:Сигнал тревоги вторжения может звучать не более 15 минутсогласно местным правилам подачи сигналов тревоги.

:Sirensd IntruderThenFireограничение продолжительностиSoundingFireAlarm:Siren{t <= 15}{t = 30}SoundingIntruderAlarmfireлиния жизниcобытиеOffintruderintruderсостояние или условиеRestingintruderвременная линейка010203040время в минутахРис. 20.14. Временная диаграмма для класса Siren5060708090100462Глава 20.

Реализация прецедента на этапе проектированияt = 35:t = 55:t = 65:t = 75:t = 100:переходит в состояние Resting (покой). Он должен находитьсяв этом состоянии 30 минут (опять же по местным законам).Происходит событие intruder, но :Siren в состоянии Resting, поэтому не может воспроизводить сигнал тревоги.:Siren возвращается в состояние Off.Возникает еще одно событие intruder. :Siren переходит из состояния Off в состояние SoundingIntruderAlarm.Происходит событие fire. :Siren переходит из состояния SoundingIntruderAlarm в состояние SoundingFireAlarm (воспроизведениесигнала пожарной тревоги).Взаимодействие завершается, :Siren остается в состоянииSoundingFireAlarm.Временные диаграммы также можно представить в более компактнойформе, когда состояния располагаются горизонтально.

На рис. 20.15в такой форме показана временная диаграмма с рис. 20.14.В такой компактной форме акцент обычно смещается больше на состояния и относительное время, а не на представление абсолютноговремени, как это моделирует временная линейка.Временные диаграммы могут использоваться для представления изменений состояния объекта во времени.Временные диаграммы также могут использоваться для иллюстрациивременных ограничений во взаимодействиях между двумя или болеелиниями жизни. На рис. 20.16 показано взаимодействие между линиями жизни :FireSensorMonitor, :IntruderSensorMonitor и :Siren.На этой временной диаграмме следует отметить несколько интересныхмоментов:• Временнаяй диаграмма имеет три отделения, по одному для каждой линии жизни.sd IntruderThenFire:Sirenвсе промежутки времени в минутахOff{t <= 15}{t > 30}SoundingIntruderAlarmResting{t = 10}OffSoundingIntruderAlarmSoundingfireAlarmсостояние или условиеРис.

20.15. Компактная форма временной диаграммы с рис. 20.1446320.7. Временные диаграммыsd SirenBehavior{t <= 0.016}все промежутки времени в минутах:FireSensorMonitorT riggeredNotT riggered{t <= 0.016}:IntruderSensorMonitorcообщенияT riggeredNotT riggeredsoundFireAlarm()SoundingFireAlarmsoundIntruderAlarm()soundIntruderAlarm()soundIntruderAlarm():SirenSoundingIntruderAlarmsoundIntruderAlarm()OffResting{t <= 15}{t = 30}{t <= 15}Рис.

20.16. Временная диаграмма иллюстрирует временные ограничения,накладываемые на взаимодействия между линиями жизни•••На временных диаграммах можно показать сообщения, которымиобмениваются линии жизни, как представлено на рисунке.При вызове датчики обоих типов переходят в состояние Triggered(инициирован), а затем в течение 1 секунды возвращаются в состояние NotTriggered (не инициирован). Это значит, что у обоих датчиковкороткое время повторной готовности – важнейшая характеристика.:Siren отвечает на события вторжения только в состоянии Off.

В состоянии Resting он игнорирует эти события. Это обусловлено местными правилами, согласно которым сигнал тревоги вторжениядолжен подаваться только в течение 15 минут, а затем выключаться, по крайней мере, на полчаса.464Глава 20. Реализация прецедента на этапе проектирования•:Siren всегда отвечает на события пожара, даже если находится в состоянии Resting, потому что пожарная сигнализация должна включаться как можно скорее после возникновения события пожара.Как видите, временные диаграммы являются удобным способом моделирования временных ограничений, накладываемых на взаимодействия.20.8. Пример реализации прецедентана этапе проектированияВ данном разделе рассматривается реальный пример проектированияреализации прецедента.

Обсуждаемый пример – это простой редакторпрецедентов, ориентированный на схемы. Это часть системы SUMR,которая описывается в приложении B. Ознакомьтесь с этим приложением, прежде чем читать дальше.Как сказано в приложении B, приложение, которое мы собираемся рассмотреть, является простым редактором прецедентов с синтаксическойподсветкой имен актеров, имен прецедентов, включений и расширений. Модель прецедентов для системы UseCaseEditor (редактор прецедентов) показана на рис.

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

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