Джим Арлоу, Айла Нейштадт - UML 2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование (1037782), страница 85
Текст из файла (страница 85)
20.21. Проектная модель классов1{dictionary}!actors0..*1SUMRUseCaseParser!includedUseCases : String[]!extensionPoints : String[]{dictionary}!useCases0..*+__init__( fileName : String )+getName(): String+getlD(): String+autoNumber()+deNumber()SUMRValidRleParser!schemaName : String!legalTags : Dictionary!illegalTags : Dictionary+__init__( fileName : String )+getMissingTags() : String[]+getExtraTags() : String[]AutoNumber+autoNumber( lines : String[] )+autoDeNumber( lines : String[] )!removeNumbers( line : String )!getlndent( line : String )+__init__()0..1!schema1SUMRFileParser!fileName : String!filePath : String!lines : String[]!tags : String[]!elements : Dictionary+__init__(fileName : String )+refresh()+saveAs( fileName : String )+save()+search( pattern : String )+getTagMultiplicity( tagName : String )+isTag() : Boolean468Глава 20.
Реализация прецедента на этапе проектированияЭто мощная межплатформенная библиотека GUI, основанная на wxWidgets (www.wxwidgets.org). Эти классы придерживаются другогостандарта присваивания имен: начинаются с маленькой буквы, а некак обычно с большой. Разные стандарты наименования в разработкепрограммного обеспечения сложились исторически.И наконец, давайте посмотрим на диаграмму последовательностей дляCreateUseCaseSpecificationFromSchema уровня проектирования (рис. 20.22).Эта диаграмма используется для иллюстрации центральных механизмов создания файла нового прецедента из существующего файла схемы. Эта диаграмма имеет важное значение, потому что данный механизм должен использоваться неизменно во всей системе.
Можно убедиться в работоспособности нашего проекта – имеются все необходимые классы и операции для выполнения поставленных задач.Хотя в этом примере мы представили артефакты определения требований, анализа и проектирования последовательно, необходимо помнить,что UP является итеративным процессом и что наборы этих артефактовна самом деле создаются параллельно.
В частности, работа над модельюпрецедентов, аналитической диаграммой классов и аналитическимидиаграммами взаимодействий будет проводиться одновременно. То жесамое относится к проектной диаграмме классов и проектным диаграммам взаимодействий. Обновление артефактов, созданных в предыдущих итерациях, является обычным делом. Помните, что в каждой итерации есть элемент каждого рабочего потока – Определения требований, Анализа, Проектирования, Реализации и Тестирования.20.9.
Что мы узналиРеализация прецедента на этапе проектирования – это на самом делерасширение реализации прецедента, созданной при анализе. Мы узнали следующее:• Деятельность UP Проектирование прецедента заключается в выявлении проектных классов, интерфейсов и компонентов, взаимодействие которых обеспечивает поведение, описанное прецедентом.• Проектные реализации прецедентов – это взаимодействия проектных объектов и классов, направленные на реализацию прецедента.Они включают:• проектные диаграммы взаимодействий – уточненные аналитические диаграммы взаимодействий;• проектные диаграммы классов – уточненные аналитическиедиаграммы классов.• Диаграммы взаимодействий могут использоваться в проектировании для моделирования центральных механизмов, таких как сохранение объектов; эти механизмы могут охватывать многие прецеденты.load()Рис. 20.22.
Диаграмма последовательностей уровня проектированияобновить модель из фай!лов прецедентов на дискесохранить файлпрецедента на дискесоздать новыйпрецедентполучить имя файладля нового прецедентаsaveAs( newUseCaseFileName)setUseCaseName( newUseCaseName)SUMRFileParser(schemaFileName ):SUMRFileParsernewUseCaseFileName = getNewUseCaseFileName( newUseCaseName )newUseCaseFromSchema( schemaName, newUseCaseName )создать новыйпрецедент в моделиnewUseCaseFromSchema( "UseCase.sss" ):UseCaseModelnewllseCaseName = getNewName( "Enter use case name", "New use case name")newUseCase( event ):UseCaseEditorполучить имяпрецедентанажать кнопку“New use case”:UseCaseEngineer20.9.
Что мы узнали469470Глава 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]. С их помощью обычно моделируетсяпредыстория жизненного цикла одного реактивного объекта. Онапредставляется в виде конечного автомата – автомата, который можетсуществовать в конечном числе состояний.
В ответ на события конечный автомат четко осуществляет переходы между этими состояниями.Рис. 21.1. План главы21.8. Что мы узнали21.6.2. Ветвление переходов – псевдосостояние выбора21.6.1. Соединение переходов – переходное псевдосостояние21.6. Переходы21.5. Состояния21.5.1.
Синтаксис состоянияизучаем переходыизучаем состояния21.4. Диаграммы состояний21.3. Конечные автоматы и UP21.7.4. События времени21.7.3. События изменения21.7. Событияизучаем события21.7.2. Сигналы21.7.1. События вызова21.2.2. Конечные автоматы и классы21.2.1. Поведенческие и протокольные автоматы21.2. Конечные автоматы472Глава 21. Конечные автоматы21.2. Конечные автоматы473Три основных элемента автоматов – состояния, события и переходы:• состояние (state) – «условие или ситуация в жизни объекта, при которых он удовлетворяет некоторому условию, осуществляет некоторую деятельность или ожидает некоторого события» [Rumbaugh 1];• событие (event) – «описание заслуживающего внимания происшествия, занимающего определенное положение во времени и пространстве» [Rumbaugh 1];• переход (transition) – переход из одного состояния в другое в ответна событие.Намного подробнее состояния, события и переходы будут рассмотреныв этой главе несколько позже.Реактивный объект – это объект, в широком смысле этого слова, который предоставляет автомату контекст.
Реактивные объекты:• отвечают на внешние события (т. е. события, происходящие внеконтекста объекта);• могут генерировать и отвечать на внутренние события;• их жизненный цикл смоделирован как последовательность состояний, переходов и событий;• их текущее поведение может зависеть от предыдущего поведения.Реальный мир полон реактивных объектов, которые можно смоделировать с помощью автоматов. В UMLмоделировании конечные автоматы обычно описываются в контексте конкретного классификатора.Затем конечный автомат моделирует поведение, общее для всех экземпляров этого классификатора. Конечные автоматы могут использоваться для моделирования динамического поведения таких классификаторов, как:• классы;• прецеденты;• подсистемы;• целые системы.21.2.1.
Поведенческие и протокольные автоматыСпецификация UML 2 определяет два типа конечных автоматов, имеющих общий синтаксис:• поведенческие автоматы;• протокольные автоматы.Поведенческие автоматы определяют поведение.Поведенческие автоматы с помощью состояний, переходов и событийопределяют поведение контекстного классификатора. Они могут использоваться, только если у контекстного классификатора есть некоторое поведение, которое можно смоделировать. У некоторых класси474Глава 21. Конечные автоматыфикаторов, например интерфейсов и портов, такого поведения нет;они просто описывают протокол использования. Состояния поведенческих автоматов могут определять одно или более действий, выполняемых при входе в состояние, нахождении в нем или выходе из него (см.раздел 21.5.1).Протокольные автоматы определяют протокол.Протокольные автоматы используют состояния, переходы и событиядля определения протокола контекстного классификатора.