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

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

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()

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}

!actors1

!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

!useCaseModel 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). Эти классы придерживаются другого

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

как обычно с большой. Разные стандарты наименования в разработке

программного обеспечения сложились исторически.

И наконец, давайте посмотрим на диаграмму последовательностей для

CreateUseCaseSpecificationFromSchema уровня проектирования (рис. 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.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. Синтаксис состояния

Рис. 21.1. План главы

21.2. Конечные автоматы 473

Три основных элемента автоматов – состояния, события и переходы:

• состояние (state) – «условие или ситуация в жизни объекта, при ко

торых он удовлетворяет некоторому условию, осуществляет некото

рую деятельность или ожидает некоторого события» [Rumbaugh 1];

• событие (event) – «описание заслуживающего внимания происше

ствия, занимающего определенное положение во времени и про

странстве» [Rumbaugh 1];

• переход (transition) – переход из одного состояния в другое в ответ

на событие.

Намного подробнее состояния, события и переходы будут рассмотрены

в этой главе несколько позже.

Реактивный объект – это объект, в широком смысле этого слова, кото

рый предоставляет автомату контекст. Реактивные объекты:

• отвечают на внешние события (т. е. события, происходящие вне

контекста объекта);

• могут генерировать и отвечать на внутренние события;

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

ний, переходов и событий;

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

Реальный мир полон реактивных объектов, которые можно смодели

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

маты обычно описываются в контексте конкретного классификатора.

Затем конечный автомат моделирует поведение, общее для всех экзем

пляров этого классификатора. Конечные автоматы могут использо

ваться для моделирования динамического поведения таких классифи

каторов, как:

• классы;

• прецеденты;

• подсистемы;

• целые системы.

21.2.1. Поведенческие и протокольные автоматы

Спецификация UML 2 определяет два типа конечных автоматов, име

ющих общий синтаксис:

• поведенческие автоматы;

• протокольные автоматы.

Поведенческие автоматы определяют поведение.

Поведенческие автоматы с помощью состояний, переходов и событий

определяют поведение контекстного классификатора. Они могут ис

пользоваться, только если у контекстного классификатора есть неко

торое поведение, которое можно смоделировать. У некоторых класси