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

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

5.6. Когда применять дополнительные возможности 133

overdueBook, и в точке payFine (выплатить штраф). Это свидетельствует

о том, что IssueWarning (рис. 5.15) содержит только один сегмент встав

ки, тогда как IssueFine (как мы уже видели) – два.

5.6. Когда применять дополнительные

возможности

Применяйте дополнительные возможности, только если они упрощают

модель и делают ее более понятной.

Применяйте дополнительные возможности, только если они упроща

ют модель прецедентов. Мы вновь убеждаемся в том, что лучшие моде

ли прецедентов – это простые модели. Запомните, что модель преце

дентов – это изложение требований, то есть она должна быть понятной

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

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

применяются редко или вообще отсутствуют, предпочтительнее моде

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

следняя кажется разработчику более изысканной.

Учитывая опыт моделирования прецедентов в различных компаниях,

можно сделать следующие выводы:

• обычно заинтересованные стороны после небольшой тренировки

и обучения могут без труда разбираться в актерах и прецедентах;

• заинтересованным сторонам сложнее воспринимать обобщение ак

теров;

• широкое использование отношения «include» затрудняет понимание

моделей прецедентов – заинтересованным сторонам и разработчи

кам моделей приходится рассматривать несколько прецедентов для

получения полной картины;

• у заинтересованных сторон возникают большие сложности с пони

манием отношения «extend» даже после подробных объяснений;

• как это ни удивительно, многие разработчики объектных моделей

неверно понимают семантику отношения «extend»;

• обобщение прецедентов следует применять, только если в системе

используются абстрактные (а не конкретные) родительские преце

денты, в противном случае это сильно усложняет дочерние преце

денты.

5.7. Советы и рекомендации по написанию

прецедентов

В данном разделе предлагается несколько советов и рекомендаций

по написанию прецедентов.

134 Глава 5. Дополнительные аспекты моделирования прецедентов

5.7.1. Делайте прецеденты короткими и простыми

Основной девиз: «Делайте прецеденты короткими, делайте их просты

ми». Они должны включать именно такой объем информации, которо

го достаточно для записи требований. К сожалению, в некоторых про

ектах разработчики избегают простого и сжатого изложения и стре

мятся к непомерному увеличению объема документации. Гради Буч

называет эту тенденцию «бумажной жадностью».

Есть хорошее правило: основной поток прецедента должен помещать

ся на одной странице. Немного больше, и прецедент практически на

верняка окажется слишком длинным. В реальности большинство пре

цедентов короче половины страницы.

Начать надо с упрощения фраз (использовать только короткие повест

вовательные предложения, как описано в разделе 3.6.2). Затем уда

лить все детали проектирования (см. следующий раздел). Если преце

дент попрежнему слишком велик, необходимо повторно проанализи

ровать проблему. Вероятно, прецедент можно разбить на несколько

прецедентов либо выделить альтернативные потоки.

5.7.2. Фокусируйтесь на том «что», а не «как»

Помните, прецеденты создаются для того, чтобы понять, чего актеры

ждут от системы, а не как она должна это осуществлять. «Как» стано

вится ясно позже, при проектировании. Смешение «что» с «как» явля

ется повсеместной проблемой. Разработчик, работая над прецедентом,

придумывает какоето решение. Рассмотрим, к примеру, следующий

фрагмент прецедента:

...

4. Система просит Покупателя подтвердить заказ.

5. Покупатель нажимает кнопку OK.

...

В данном примере разработчик прецедента представил себе некий

пользовательский интерфейс: форму с кнопкой «ОК». Изза этого пре

цедент перестал быть простым изложением требований, это первич

ный проект. Лучше записать шаг 5 следующим образом:

...

5. Покупатель соглашается с заказом.

...

Детали проектирования (которые пока неизвестны!) должны оставать

ся вне прецедента.

5.7.3. Избегайте функциональной декомпозиции

Функциональная декомпозиция не подходит для моделей прецедентов.

5.7. Советы и рекомендации по написанию прецедентов 135

При анализе прецедентов широко встречается следующая ошибка:

создается ряд «высокоуровневых» прецедентов, которые затем разби

ваются на ряд прецедентов более низкого уровня и т. д. до «элементар

ных» прецедентов, достаточно детализированных для реализации. Та

кой подход к разработке программного обеспечения называется функ

циональной декомпозицией. Он абсолютно ошибочен в применении

к моделированию прецедентов.

Рассмотрим пример. На рис. 5.16 аналитик описал работу библиотеч

ной системы с помощью одного высокоуровневого прецедента RunLibra

ry (управление библиотекой). Затем путем функциональной декомпо

зиции разложил его на все более и более детализированные уровни.

Многим неОО аналитикам рис. 5.16 кажется вполне приемлемым.

Однако с точки зрения моделирования прецедентов в предложенном

примере содержится много ошибок:

• Модель сосредоточена не на фиксировании требований, а на искус

ственном структурировании этих требований – существует множе

ство возможных вариантов декомпозиции.

• Модель описывает систему как набор вложенных функций. Однако

ОО системы в действительности являются наборами взаимодейст

вующих объектов, обменивающихся сообщениями. Здесь очевид

ное концептуальное несоответствие.

LibrarySystem

Librarian

AddBook

DeleteBook

AddTicket

DeleteTicket

LendBook

ReturnBook

Избегайте функциональной

декомпозиции

«include»

MaintainBooks

MaintainTickets

MaintainLoans

«include»

RunLibrary

«include»

Рис. 5.16. Пример функциональной декомпозиции

136 Глава 5. Дополнительные аспекты моделирования прецедентов

• Интерес представляют только описания прецедентов самого низко

го уровня: AddBook (добавить книгу), DeleteBook (удалить книгу), Add

Ticket (добавить формуляр), DeleteTicket (удалить формуляр), LendBook

(выдать книгу) и ReturnBook (вернуть книгу). Более высокие уровни

просто вызывают нижние и ничего не привносят в модель с точки

зрения отражения требований.

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

сколько абстрактных прецедентов (RunLibrary, MaintainBooks (обслу

живание книг), MaintainTickets (обслуживание формуляров) и Main

tainLoans (обслуживание выдачи книг)) и много отношений «include»

с более низкими уровнями абстракции.

Применение функциональной декомпозиции говорит о том, что анали

тик неправильно продумал систему. Обычно это свидетельствует о том,

что он обучен более традиционным методам процедурного программи

рования и пока что не уловил принципа ОО программирования. В этом

случае лучше привлечь опытного разработчика моделей прецедентов

в качестве руководителя и консультанта.

Не все примеры функциональной декомпозиции так очевидны, как

приведенный на рис. 5.16. Обычно декомпозицию можно обнаружить

в отдельных частях модели, поэтому желательно проверять все части

модели прецедентов, имеющие глубокую иерархию.

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

тов иерархии возникают естественным образом. Однако в этих естест

венных иерархиях, как правило, не более одного (или максимум двух)

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

дента.

5.8. Что мы узнали

Мы изучили приемы углубленного моделирования прецедентов. Ос

новная задача моделирования – создать простую понятную модель

прецедентов, в которой вся необходимая информация представлена

максимально четко и лаконично. Модель прецедентов, не использую

щая расширенные возможности, всегда предпочтительнее той, где так

много обобщений, отношений «include» и «extend», что невозможно по

нять, о чем идет речь. Здесь лучшее правило: «Если сомневаешься, не

включай».

Мы узнали следующее:

• Обобщение актеров обеспечивает возможность вынести поведение,

общее для двух или более актеров, в актерародителя.

• Актерродитель является более обобщенным, чем его потомки,

а потомки – более специализированными, чем их родитель.

• Дочерний актер везде может заменять актерародителя – это

принцип замещаемости.

5.8. Что мы узнали 137

• Актерродитель обычно абстрактный – он определяет абстракт

ную роль.

• Дочерние актеры конкретны – они определяют конкретные роли.

• Обобщение актеров может упрощать диаграммы прецедентов.

• Обобщение прецедентов позволяет вынести возможности, общие

для двух или более прецедентов, в родительский прецедент.

• Дочерние прецеденты наследуют все возможности родительских

прецедентов.

• Дочерние прецеденты могут вводить новые возможности.

• Дочерние прецеденты могут переопределять родительские воз

можности за исключением отношений и точек расширения.

• В дочерних прецедентах мы применяем простые обозначения:

• унаследованный без изменений – 3. (3.);

• унаследованный и перенумерованный – 6.2. (6.1.);

• унаследованный и переопределенный – 1. (o1.);

• унаследованный, переопределенный и перенумерованный –

5.2. (o5.1.);

• добавленный – 6.3.

• Хорошим стилем является абстрактность родительского преце

дента.

• Отношение «include» позволяет вынести шаги, повторяющиеся в не

скольких потоках прецедентов, в отдельный прецедент, который

включается по необходимости.

• Синтаксис include(ИмяПрецедента) используется для включения

поведения другого прецедента.

• Включающий прецедент называют базовым прецедентом.

• Прецедент, который включается, называют включаемым преце

дентом.

• Базовый прецедент без всех включаемых прецедентов является

неполным.

• Включаемые прецеденты могут быть:

• полными – это обычные прецеденты, их экземпляры могут

быть созданы;

• неполными – они содержат только фрагмент поведения и их

экземпляры не могут быть созданы.

• Отношение «extend» вводит новое поведение в существующий (базо

вый) прецедент.

• Точки расширения накладываются поверх потока событий базо

вого прецедента.

• Точки расширения размещаются между шагами потока собы

тий.

138 Глава 5. Дополнительные аспекты моделирования прецедентов

• Расширяющие прецеденты предоставляют сегменты вставки –

фрагменты поведения, которые могут быть «подключены» к точ

кам расширения.

• Отношение «extend» между расширяющим и базовым прецеден

тами определяет точки расширения. В этих точках вводятся сег

менты вставки расширяющих прецедентов.

• Базовый прецедент является полным и без сегментов вставки –

он ничего не знает о возможных сегментах вставки, он только

предоставляет точки входа для них.

• Расширяющий прецедент, как правило, неполный – обычно он

просто объединяет в себе один или более сегментов вставки; он

может быть и полным прецедентом, но это редкий случай.

• Если расширяющий прецедент имеет предусловия, они должны

быть реализованы; в противном случае расширяющий преце

дент не выполняется.

• Постусловия расширяющего прецедента, если они есть, накла

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

расширяющего прецедента.

• Расширяющий прецедент может содержать несколько сегментов

вставки.

• Два или более расширяющих прецедента могут расширять один

и тот же базовый прецедент в одной и той же точке расширения –

порядок выполнения каждого расширяющего прецедента не оп

ределен.

• Условные расширения – логические условия, налагаемые на от

ношение «extend». Разрешают вставку в случае истинности усло

вия и запрещают, если условие ложно.

• Дополнительные возможности применяются следующим образом:

• Обобщение актеров применяется, только если упрощает модель.

• Обобщение прецедентов рекомендуется не использовать или ис

пользовать только с абстрактными родителями.

• «include» применяется, только если упрощает модель; необходи

мо остерегаться злоупотреблений, поскольку тогда модель пре

цедентов превращается в функциональную декомпозицию.

• «extend» рекомендуется не использовать; если все же применяет

ся, все разработчики модели и заинтересованные стороны долж

ны гарантированно понимать и соглашаться с его семантикой.

• Советы и рекомендации по написанию прецедентов:

• прецеденты должны быть короткими и простыми;

• основное внимание необходимо уделять тому, что, а не как;

• избегать функциональной декомпозиции.

III

Анализ

Рабочий поток анализа

6.1. План главы

Эта глава начинает наше исследование процесса ОО анализа. Здесь пред

ставлен краткий обзор рабочего потока анализа в UP и некоторые

практические правила создания аналитических моделей, что создает

базу для дальнейшего более подробного обсуждения в следующих гла

вах этой части книги.

6.3. Артефакты анализа – метамодель

изучаем рабочий поток анализа изучаем лучшие приемы создания аналитических моделей

6.2. Рабочий поток анализа 6.5. Аналитическая модель – практические правила

6.6. Что мы узнали

6.4. Детализация рабочего потока анализа

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

142 Глава 6. Рабочий поток анализа

6.2. Рабочий поток анализа

Аналитическое моделирование имеет стратегически важное значение,

поскольку на этом этапе делается попытка смоделировать основное по

ведение системы.

Основная аналитическая работа начинается в конце фазы Начало. На

ряду с определением требований анализ является главной задачей фа

зы Уточнение.

В фазе Уточнение основные силы направлены на создание моделей, от

ражающих требуемое поведение системы. Как видно из рис. 6.2, ана

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

две деятельности часто идут рука об руку. Обычно необходимо провес

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

и выявить все упущения или искажения.

Цель рабочего потока анализа (с точки зрения ОО анализа) – создание

аналитической модели. Данная модель фокусируется на том, что

должна делать система. Детали того, как система будет это делать,

предоставляются потоку проектирования.

Граница между анализом и проектированием довольно неопределен

ная, и до известной степени все зависит от аналитика. В разделе 6.5

представлены некоторые практические правила, которые могут по

мочь в создании хороших аналитических моделей.

Начало Уточнение Построение Внедрение

Определение

требований

Анализ

Проектирование

Реализация

Тестирование

Предварительные

итерации

Шаг

n+1

Шаг

n+2

Шаг

m+1

Рис. 6.2. Определение требований выполняется в фазах Начало и Уточнение.

Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства Addison+

Wesley

6.3. Артефакты анализа – метамодель 143

6.3. Артефакты анализа – метамодель

В рабочем потоке анализа создаются два ключевых артефакта:

• классы анализа – ключевые понятия в бизнессфере;

• реализации прецедентов – иллюстрируют, как экземпляры классов

анализа могут взаимодействовать для реализации поведения систе

мы, описанного прецедентами.

С помощью UML можно самостоятельно создавать аналитическую мо

дель. Метамодель аналитической модели приведена на рис. 6.3.

Синтаксис пакета был представлен ранее (сущности, имеющие вид па

пок). Синтаксис класса (прямоугольники) и синтаксис реализации

прецедента (овалы, нарисованные пунктирной линией) показаны здесь

впервые. Классы рассматриваются в главе 7, пакеты – в главе 11, реа

лизации прецедентов – в главе 12.

Аналитическую модель можно представить в виде пакета с треуголь

ником в верхнем правом углу. Этот пакет содержит один или более па

кетов анализа. Мы называем их «пакетами анализа», потому что они

являются частью аналитической модели. На рис. 6.3 показаны лишь

четыре пакета анализа, но настоящие аналитические модели могут

включать множество пакетов. В каждом пакете, в свою очередь, могут

находиться вложенные пакеты анализа.

6.4. Детализация рабочего потока анализа

На рис. 6.4 показан рабочий поток анализа в UP. Соответствующие

деятельности будут рассмотрены в следующих главах. Но чтобы по

Аналитическая

модель

класс анализа реализация прецедента

Рис. 6.3. Метамодель аналитической модели