UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• Временнаяй диаграмма имеет три отделения, по одному для каж дой линии жизни. sd IntruderThenFire Sounding Intruder Alarm :S iren {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 :S iren {t <= 15} T riggered NotT riggered :Int ru de rS enso rMo nit or {t <= 15} {t = 30} {t <= 0.016} все промежутки времени в минутах Resting T riggered NotT riggered :F ireS enso rMo nit or {t <= 0.016} SoundingFireAlarm cообщения soundFireAlarm() soundIntruderAlarm() soundIntruderAlarm() soundIntruderAlarm() soundIntruderAlarm() Рис. 20.16. Временная диаграмма иллюстрирует временные ограничения, накладываемые на взаимодействия между линиями жизни 464 Глава 20. Реализация прецедента на этапе проектирования • :Siren всегда отвечает на события пожара, даже если находится в со стоянии Resting, потому что пожарная сигнализация должна вклю чаться как можно скорее после возникновения события пожара. Как видите, временные диаграммы являются удобным способом мо делирования временных ограничений, накладываемых на взаимодей ствия. 20.8. Пример реализации прецедента на этапе проектирования В данном разделе рассматривается реальный пример проектирования реализации прецедента. Обсуждаемый пример – это простой редактор прецедентов, ориентированный на схемы. Это часть системы SUMR, которая описывается в приложении B. Ознакомьтесь с этим приложе нием, прежде чем читать дальше. Как сказано в приложении B, приложение, которое мы собираемся рас смотреть, является простым редактором прецедентов с синтаксической подсветкой имен актеров, имен прецедентов, включений и расшире ний. Модель прецедентов для системы UseCaseEditor (редактор прецеден тов) показана на рис. 20.17. Она была разработана с помощью инстру UseCaseEngineer UseCaseEditor CreateUseCaseSpecificationFromSchema EditUseCaseSpecification SyntaxHilightUseCaseSpecification GenerateXMLUseCaseSpecification AutoNumberUseCaseSpecification CreateActorSpecificationFromSchema EditActorSpecification SyntaxHilightActorSpecification GenerateXMLActorSpecification Рис. 20.17. Модель прецедентов для системы UseCaseEditor 20.8. Пример реализации прецедента на этапе проектирования 465 ментального средства моделирования UML MagicDraw (www.magic draw.com ), поэтому иллюстрации немного отличаются от всех осталь ных иллюстраций этой книги. Основным прецедентом этой системы, вероятно, является CreateUseCase SpecificationFromSchema (создать спецификацию прецедента по схеме). Он отражает назначение системы – предоставление возможности соз дания (и редактирования) описаний прецедентов на основании заранее существующей схемы. Прецедент CreateUseCaseSpecificationFromSchema представлен на рис. 20.18. Поскольку система очень проста, аналитическая модель не уточнялась до очень глубокого уровня, и мы смогли быстро перейти к проектиро ванию. Аналитическая диаграмма классов показана на рис. 20.19. Она отражает наши исходные идеи о том, какие классы будут нужны. Как часть реализации прецедента на этапе анализа была создана ана литическая диаграмма последовательностей (рис. 20.20). Она иллюст рирует наше предположение о том, как система создает файл нового прецедента из существующего файла схемы. Проектная модель классов представлена на рис. 20.21. Как видите, аналитическая диаграмма классов сильно отличается от проектной. Как упоминалось, это настолько простая система, что мы очень быстро перешли к проектированию, и основная работа по исследованию была проведена в этом рабочем потоке. Если бы система была более сложной, на определение требований и анализ понадобилось бы больше времени. ID: 1 Главные актеры: UseCaseEngineer Предусловия: 1. Существует схема прецедента. Основной поток: 1. Прецедент начинается, когда UseCaseEngineer выбирает «create new use case». 2. Система запрашивает имя прецедента. 3. UseCaseEngineer вводит имя прецедента. 4. Система создает новый прецедент из схемы прецедента. 5. Система представляет новый прецедент для редактирования. Постусловия: 1. Система создала новый прецедент. Прецедент: CreateUseCaseSpecificationFromSchema Краткое описание: Система создает спецификацию нового прецедента из схемы прецедента. Альтернативные потоки: UseCaseAlreadyExists UseCaseEngineerCancels Второстепенные актеры: Нет. Рис. 20.18. Описание прецедента CreateUseCaseSpecificationFromSchema 466 Глава 20. Реализация прецедента на этапе проектирования Редактор прецедентов был исследовательским проектом, и мы не по нимали по настоящему, чем он мог быть полезен, пока не провели не сколько итераций и не получили некоторые предварительные испол няемые базовые версии архитектуры, с которыми можно было экспе риментировать. Также мы не пытались предугадывать самые эффек тивные центральные механизмы для файлов SUMR – мы установили их, когда создали первую итерацию системы. Приложение редактора прецедентов разрабатывалось на языке про граммирования Python, и все классы, имена которых начинаются с букв wx, являются классами библиотеки GUI wxPython (www.wxpython.org). createUseCaseFromSchema() editUseCase() createActorFromSchema() editActor() syntaxHilight() autoNumber() 1..* 0..* 0..1 schema 1..* actors UseCaseEditor SUMRFile useCases useCaseModelDirectory : String ActorFile UseCaseFile SchemaFile fileName : String schemaFileName : String loadUseCaseFile() loadSchemaFile() saveUseCaseFile() 1 1 renderUseCaseToXML() renderActorToXML() XMLRenderer Рис. 20.19. Аналитическая диаграмма классов :UseCaseEngineer :UseCaseEditor :SchemaFile newUseCase( name ) sd CreateUseCaseFromSchema load() edit() name:UseCaseFile «create» save() Рис. 20.20. Аналитическая диаграмма последовательностей 20.8. Пример реализации прецедента на этапе проектирования 467 Рис. 20.21. Проектная модель классов +__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() UseCaseEditor hilights : Dictionary actorList : wxListCtrl useCaseList : wxListCtrl textControl : wxTextCtrl wxFrame {dictionary} actors 1 fileName : String buffer : String[] root : String SUMRToXMLRenderer +render( fileName : String ) +saveAs( fileName : String ) +save() +printOut() clean( line : String ) +autoNumber( lines : String[] ) +autoDeNumber( lines : String[] ) removeNumbers( line : String ) getlndent( line : String ) +__init__() AutoNumber includedUseCases : String[] extensionPoints : String[] SUMRUseCaseParser +__init__( fileName : String ) +getName(): String +getlD(): String +autoNumber() +deNumber() useCasePath : String useCaseFileNames : Dictionary actorFileNames : Dictionary actorExtension : String = ".ac" useCaseExtension : String = ".uc" UseCaseModel +__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 ) : Boolean 1 useCaseModel 1 1 +__init__(fileName : String ) +refresh() +saveAs( fileName : String ) +save() +search( pattern : String ) +getTagMultiplicity( tagName : String ) +isTag() : Boolean SUMRFileParser fileName : String filePath : String lines : String[] tags : String[] elements : Dictionary schemaName : String legalTags : Dictionary illegalTags : Dictionary +__init__( fileName : String ) +getMissingTags() : String[] +getExtraTags() : String[] SUMRValidRleParser 0..* {dictionary} useCases 0..* 0..1 schema 1 Уровень GUI Уровень приложе ния 468 Глава 20. Реализация прецедента на этапе проектирования Это мощная межплатформенная библиотека GUI, основанная на wx Widgets (www.wxwidgets.org). Эти классы придерживаются другого стандарта присваивания имен: начинаются с маленькой буквы, а не как обычно с большой. Разные стандарты наименования в разработке программного обеспечения сложились исторически. И наконец, давайте посмотрим на диаграмму последовательностей для C reateUseCaseSpecificationFromSchema уровня проектирования (рис. 20.22). Эта диаграмма используется для иллюстрации центральных механиз мов создания файла нового прецедента из существующего файла схе мы. Эта диаграмма имеет важное значение, потому что данный меха низм должен использоваться неизменно во всей системе. Можно убе диться в работоспособности нашего проекта – имеются все необходи мые классы и операции для выполнения поставленных задач. Хотя в этом примере мы представили артефакты определения требова ний, анализа и проектирования последовательно, необходимо помнить, что UP является итеративным процессом и что наборы этих артефактов на самом деле создаются параллельно. В частности, работа над моделью прецедентов, аналитической диаграммой классов и аналитическими диаграммами взаимодействий будет проводиться одновременно. То же самое относится к проектной диаграмме классов и проектным диаграм мам взаимодействий. Обновление артефактов, созданных в предыду щих итерациях, является обычным делом. Помните, что в каждой ите рации есть элемент каждого рабочего потока – Определения требова ний, Анализа, Проектирования, Реализации и Тестирования. 20.9. Что мы узнали Реализация прецедента на этапе проектирования – это на самом деле расширение реализации прецедента, созданной при анализе. Мы узна ли следующее: • Деятельность UP Проектирование прецедента заключается в выявле нии проектных классов, интерфейсов и компонентов, взаимодейст вие которых обеспечивает поведение, описанное прецедентом. • Проектные реализации прецедентов – это взаимодействия проект ных объектов и классов, направленные на реализацию прецедента. Они включают: • проектные диаграммы взаимодействий – уточненные аналити ческие диаграммы взаимодействий; • проектные диаграммы классов – уточненные аналитические диаграммы классов. • Диаграммы взаимодействий могут использоваться в проектирова нии для моделирования центральных механизмов, таких как со хранение объектов; эти механизмы могут охватывать многие пре цеденты. 20.9. Что мы узнали 469 newllseCaseName = getNewName( "Enter use case name", "New use case name") saveAs( newUseCaseFileName) SUMRFileParser(schemaFileName ) setUseCaseName( newUseCaseName) :SUMRFileParser обновить модель из фай лов прецедентов на диске нажать кнопку “New use case” получить имя прецедента создать новый прецедент в модели получить имя файла для нового прецедента создать новый прецедент сохранить файл прецедента на диске newUseCaseFileName = getNewUseCaseFileName( newUseCaseName ) newUseCaseFromSchema( schemaName, newUseCaseName ) newUseCase( event ) newUseCaseFromSchema( "UseCase.sss" ) :UseCaseEditor :UseCaseEngineer :UseCaseModel load() Рис. 20.22 . Д и аг р а м м а по с л едо в а т е л ь но ст ей уро в ня про е ктиро в ания 470 Глава 20. Реализация прецедента на этапе проектирования • Моделирование параллелизма. • Используются активные классы и объекты. • Диаграммы последовательностей: • par – все операнды выполняются параллельно; • critical – операнд выполняется автоматически без прерыва ний. • Коммуникационные диаграммы: • порядковый номер дополняется меткой для обозначения по тока управления. • Диаграммы деятельности: • ветвления; • объединения. • Диаграммы взаимодействий подсистем показывают взаимодейст вия между разными частями системы на высоком уровне абстрак ции: • в них могут входить актеры, подсистемы, компоненты и классы; • части подсистем (например, предоставляемые интерфейсы) могут отображаться в прямоугольниках, примыкающих снизу к пикто грамме подсистемы. • Временные диаграммы – моделируют временные ограничения: • очень полезны для моделирования аппаратных систем реально го времени и встроенных систем; • время увеличивается вдоль горизонтальной оси слева направо; • линии жизни, состояния и условия располагаются по вертикали; • переходы между состояниями или условиями изображаются в ви де графика; • можно показать временные ограничения и события; • компактная форма временной диаграммы делает акцент на отно сительном времени. 21 Конечные автоматы 21.1. План главы В этой главе обсуждаются конечные автоматы – важное средство моде лирования динамического поведения классификаторов. Глава начинается с введения в конечные автоматы (раздел 21.2), затем обсуждаются два типа конечных автоматов (раздел 21.2.1), автоматы и классы (раздел 21.2.2) и синтаксис конечных автоматов (раздел 21.4). Далее основное внимание уделяется базовым компонентам автоматов: состояниям (раздел 21.5), переходам (раздел 21.6) и событиям (раздел 21.7). 21.2. Конечные автоматы Конечный автомат моделирует динамическое поведение реактивного объекта. И диаграммы деятельности, и диаграммы состояний моделируют ас пекты динамического поведения системы, но их семантика и назначе ние в моделировании сильно различаются. Диаграммы деятельности базируются на технологии сетей Петри (глава 14) и обычно использу ются для моделирования бизнес процессов, в которых принимают уча стие несколько объектов. В основе конечных автоматов UML лежит работа Харела (Harel) [Harel 1]. С их помощью обычно моделируется предыстория жизненного цикла одного реактивного объекта. Она представляется в виде конечного автомата – автомата, который может существовать в конечном числе состояний. В ответ на события конеч ный автомат четко осуществляет переходы между этими состояниями. 472 Глава 21. Конечные автоматы 21.2. Конечные автоматы 21.2.1. Поведенческие и протокольные автоматы 21.2.2. Конечные автоматы и классы 21.3. Конечные автоматы и UP 21.4. Диаграммы состояний 21.5. Состояния 21.6. Переходы 21.6.1. Соединение переходов – переходное псевдосостояние 21.6.2. Ветвление переходов – псевдосостояние выбора 21.7. События 21.7.1. События вызова 21.7.2. Сигналы 21.7.3. События изменения 21.7.4. События времени 21.8. Что мы узнали изучаем состояния изучаем переходы изучаем события 21.5.1. Синтаксис состояния Ри с . 2 1 .1 . Пл ан гл ав ы 21.2. Конечные автоматы 473 Три основных элемента автоматов – состояния, события и переходы: • состояние (state) – «условие или ситуация в жизни объекта, при ко торых он удовлетворяет некоторому условию, осуществляет некото рую деятельность или ожидает некоторого события» [Rumbaugh 1]; |