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

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

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

5.16. Пример функциональной декомпозицииПри анализе прецедентов широко встречается следующая ошибка:создается ряд «высокоуровневых» прецедентов, которые затем разбиваются на ряд прецедентов более низкого уровня и т. д. до «элементарных» прецедентов, достаточно детализированных для реализации. Такой подход к разработке программного обеспечения называется функциональной декомпозицией. Он абсолютно ошибочен в применениик моделированию прецедентов.Рассмотрим пример. На рис. 5.16 аналитик описал работу библиотечной системы с помощью одного высокоуровневого прецедента RunLibrary (управление библиотекой). Затем путем функциональной декомпозиции разложил его на все более и более детализированные уровни.Многим неОО аналитикам рис.

5.16 кажется вполне приемлемым.Однако с точки зрения моделирования прецедентов в предложенномпримере содержится много ошибок:•Модель сосредоточена не на фиксировании требований, а на искусственном структурировании этих требований – существует множество возможных вариантов декомпозиции.•Модель описывает систему как набор вложенных функций. ОднакоОО системы в действительности являются наборами взаимодействующих объектов, обменивающихся сообщениями. Здесь очевидное концептуальное несоответствие.136Глава 5. Дополнительные аспекты моделирования прецедентов••Интерес представляют только описания прецедентов самого низкого уровня: AddBook (добавить книгу), DeleteBook (удалить книгу), AddTicket (добавить формуляр), DeleteTicket (удалить формуляр), LendBook(выдать книгу) и ReturnBook (вернуть книгу). Более высокие уровнипросто вызывают нижние и ничего не привносят в модель с точкизрения отражения требований.Модель сложна и непонятна заинтересованным сторонам: в ней несколько абстрактных прецедентов (RunLibrary, MaintainBooks (обслуживание книг), MaintainTickets (обслуживание формуляров) и MaintainLoans (обслуживание выдачи книг)) и много отношений «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Рабочий поток анализа6.1.

План главыЭта глава начинает наше исследование процесса ОО анализа. Здесь представлен краткий обзор рабочего потока анализа в UP и некоторыепрактические правила создания аналитических моделей, что создаетбазу для дальнейшего более подробного обсуждения в следующих главах этой части книги.изучаем рабочий поток анализаизучаем лучшие приемы создания аналитических моделей6.2. Рабочий поток анализа6.5.

Аналитическая модель – практические правила6.3. Артефакты анализа – метамодель6.4. Детализация рабочего потока анализа6.6. Что мы узналиРис. 6.1. План главы142Глава 6. Рабочий поток анализа6.2. Рабочий поток анализаАналитическое моделирование имеет стратегически важное значение,поскольку на этом этапе делается попытка смоделировать основное поведение системы.Основная аналитическая работа начинается в конце фазы Начало. Наряду с определением требований анализ является главной задачей фазы Уточнение.В фазе Уточнение основные силы направлены на создание моделей, отражающих требуемое поведение системы. Как видно из рис.

6.2, анализ в большой степени пересекается с определением требований. Этидве деятельности часто идут рука об руку. Обычно необходимо провести некоторый анализ требований, чтобы сделать их более понятнымии выявить все упущения или искажения.Цель рабочего потока анализа (с точки зрения ОО анализа) – созданиеаналитической модели. Данная модель фокусируется на том, чтодолжна делать система.

Детали того, как система будет это делать,предоставляются потоку проектирования.Граница между анализом и проектированием довольно неопределенная, и до известной степени все зависит от аналитика. В разделе 6.5представлены некоторые практические правила, которые могут помочь в создании хороших аналитических моделей.НачалоУточнениеПостроениеВнедрениеОпределениетребованийАнализПроектированиеРеализацияТестированиеПредварительныеитерацииШаг1Шаг2ШагnШагn+1Шагn+2ШагmШагm+1Рис. 6.2. Определение требований выполняется в фазах Начало и Уточнение.Адаптировано с рис. 1.5 [Jacobson 1] с разрешения издательства Addison+Wesley1436.3. Артефакты анализа – метамодель6.3.

Артефакты анализа – метамодельВ рабочем потоке анализа создаются два ключевых артефакта:• классы анализа – ключевые понятия в бизнессфере;• реализации прецедентов – иллюстрируют, как экземпляры классованализа могут взаимодействовать для реализации поведения системы, описанного прецедентами.С помощью UML можно самостоятельно создавать аналитическую модель. Метамодель аналитической модели приведена на рис. 6.3.Синтаксис пакета был представлен ранее (сущности, имеющие вид папок). Синтаксис класса (прямоугольники) и синтаксис реализациипрецедента (овалы, нарисованные пунктирной линией) показаны здесьвпервые. Классы рассматриваются в главе 7, пакеты – в главе 11, реализации прецедентов – в главе 12.Аналитическую модель можно представить в виде пакета с треугольником в верхнем правом углу.

Этот пакет содержит один или более пакетов анализа. Мы называем их «пакетами анализа», потому что ониявляются частью аналитической модели. На рис. 6.3 показаны лишьчетыре пакета анализа, но настоящие аналитические модели могутвключать множество пакетов. В каждом пакете, в свою очередь, могутнаходиться вложенные пакеты анализа.P3P1P4АналитическаямодельP2класс анализареализация прецедентаРис.

6.3. Метамодель аналитической модели6.4. Детализация рабочего потока анализаНа рис. 6.4 показан рабочий поток анализа в UP. Соответствующиедеятельности будут рассмотрены в следующих главах. Но чтобы по144Глава 6. Рабочий поток анализаАрхитектурный анализАрхитекторРазработчик прецедентовРазработчик компонентовАнализ прецедентаАнализ классаАнализ пакетаРис. 6.4.

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

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