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

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

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

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 (редактор прецедентов) показана на рис. 20.17.

Она была разработана с помощью инструUseCaseEditorCreateUseCaseSpecificationFromSchemaEditUseCaseSpecificationSyntaxHilightUseCaseSpecificationGenerateXMLUseCaseSpecificationAutoNumberUseCaseSpecificationUseCaseEngineerCreateActorSpecificationFromSchemaEditActorSpecificationSyntaxHilightActorSpecificationGenerateXMLActorSpecificationРис. 20.17. Модель прецедентов для системы UseCaseEditor20.8. Пример реализации прецедента на этапе проектирования465Прецедент: CreateUseCaseSpecificationFromSchemaID: 1Краткое описание:Система создает спецификацию нового прецедента из схемы прецедента.Главные актеры:UseCaseEngineerВторостепенные актеры:Нет.Предусловия:1. Существует схема прецедента.Основной поток:1. Прецедент начинается, когда UseCaseEngineer выбирает «create new use case».2.

Система запрашивает имя прецедента.3. UseCaseEngineer вводит имя прецедента.4. Система создает новый прецедент из схемы прецедента.5. Система представляет новый прецедент для редактирования.Постусловия:1. Система создала новый прецедент.Альтернативные потоки:UseCaseAlreadyExistsUseCaseEngineerCancelsРис. 20.18.

Описание прецедента CreateUseCaseSpecificationFromSchemaментального средства моделирования UML MagicDraw (www.magic+draw.com), поэтому иллюстрации немного отличаются от всех остальных иллюстраций этой книги.Основным прецедентом этой системы, вероятно, является CreateUseCaseSpecificationFromSchema (создать спецификацию прецедента по схеме).Он отражает назначение системы – предоставление возможности создания (и редактирования) описаний прецедентов на основании заранеесуществующей схемы.

Прецедент CreateUseCaseSpecificationFromSchemaпредставлен на рис. 20.18.Поскольку система очень проста, аналитическая модель не уточняласьдо очень глубокого уровня, и мы смогли быстро перейти к проектированию. Аналитическая диаграмма классов показана на рис. 20.19. Онаотражает наши исходные идеи о том, какие классы будут нужны.Как часть реализации прецедента на этапе анализа была создана аналитическая диаграмма последовательностей (рис.

20.20). Она иллюстрирует наше предположение о том, как система создает файл новогопрецедента из существующего файла схемы.Проектная модель классов представлена на рис. 20.21. Как видите,аналитическая диаграмма классов сильно отличается от проектной.Как упоминалось, это настолько простая система, что мы очень быстроперешли к проектированию, и основная работа по исследованию былапроведена в этом рабочем потоке.

Если бы система была более сложной,на определение требований и анализ понадобилось бы больше времени.466Глава 20. Реализация прецедента на этапе проектированияUseCaseEditor1useCases1..*useCaseModelDirectory : StringcreateUseCaseFromSchema()editUseCase()createActorFromSchema()editActor()syntaxHilight()autoNumber()1actors1..*ActorFileSUMRFileschema0..1fileName : StringschemaFileName : String0..*loadUseCaseFile()loadSchemaFile()saveUseCaseFile()UseCaseFileSchemaFileXMLRendererrenderUseCaseToXML()renderActorToXML()Рис.

20.19. Аналитическая диаграмма классовРедактор прецедентов был исследовательским проектом, и мы не понимали понастоящему, чем он мог быть полезен, пока не провели несколько итераций и не получили некоторые предварительные исполняемые базовые версии архитектуры, с которыми можно было экспериментировать. Также мы не пытались предугадывать самые эффективные центральные механизмы для файлов SUMR – мы установилиих, когда создали первую итерацию системы.Приложение редактора прецедентов разрабатывалось на языке программирования Python, и все классы, имена которых начинаются с буквwx, являются классами библиотеки GUI wxPython (www.wxpython.org).sd CreateUseCaseFromSchema:UseCaseEditor:SchemaFile:UseCaseEngineernewUseCase( name )load()«create»save()edit()Рис.

20.20. Аналитическая диаграмма последовательностейname:UseCaseFile46720.8. Пример реализации прецедента на этапе проектированияwxFrameУровеньGUIUseCaseEditor!hilights : Dictionary!actorList : wxListCtrl!useCaseList : wxListCtrl!textControl : wxTextCtrl+__init__(parent : wxPySimpleApp, id : String, title : String, size : Point, style : int)#makeToolBar()#makeMenu()#connectEvents()#enableButtonsAndMenus( enabled : Boolean )#updateView()#update( event : wxEvent)#newActor( event : wxEvent)#newUseCase( event : wxEvent)#newUseCaseFromSchema( schemaName : String )#newAlternativeFlow( event : wxEvent)#newExtensionUseCase( event : wxEvent)#generateXML( event : wxEvent)#itemSelected( event : wxEvent)#openUseCaseModel( event : wxEvent)#save( event : wxEvent)#setFont( event : wxEvent)#getNewName( message : String, caption : String ) : String#autoNumber()#autoNumberSelected( event : wxEvent)#syntaxHilight()#hilightSelected( event : wxEvent)#findAIIAndHilight( regularExpression : String, hilight : wxTextAttr)#saveFile()#loadFile()1!useCaseModelУровеньприложе!ния1UseCaseModel!useCasePath : String!useCaseFileNames : Dictionary!actorFileNames : Dictionary!actorExtension : String = ".ac"!useCaseExtension : String = ".uc"+__init__()+setUseCasePath( useCasePath : String )+load()+getModelElement( name : String ) : SUMRUseCaseParser+getUseCaseNames() : String[]+getUseCaseFileName( name : String ) : String+getNewUseCaseFileName( name : String ) : String+getUseCase( name : String ) : SUMRUseCaseParser+newUseCaseFromSchema( schemaName : String,useCaseName : String ) : SUMRUseCaseParser+useCaseNameExists( name : String ) : Boolean+getActorNames() : String[]+getActorFileName( name : String ) : String+getNewActorFileName( name : String ) : String+getActor( name : String ) : SUMRUseCaseParser+newActorFromSchema( schemaName : String,actorName : String ) : SUMRUseCaseParser+namelsValid( name : String ) : Boolean+nameExists( name : String ) : Boolean+actorNameExists( name : String ) : BooleanSUMRToXMLRenderer!fileName : String!buffer : String[]!root : String+render( fileName : String )+saveAs( fileName : String )+save()+printOut()!clean( line : String )Рис.

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

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