Главная » Все файлы » Просмотр файлов из архивов » PDF-файлы » Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование

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

Описание файла

PDF-файл из архива "Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование", который расположен в категории "книги и методические указания". Всё это находится в предмете "объектно-ориентированный анализ и проектирование" из седьмого семестра, которые можно найти в файловом архиве МГУ им. Ломоносова. Не смотря на прямую связь этого архива с МГУ им. Ломоносова, его также можно найти и в других разделах. .

Просмотр PDF-файла онлайн

Текст 28 страницы из PDF

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

Рабочий поток анализа в UP. Воспроизведено с рис. 8.18 [Jacobson 1]с разрешения издательства Addison+Wesleyнять их, необходимо рассмотреть классы и объекты. Они будут обсуждаться в главе 7.6.5. Аналитическая модель – практическиеправилаВсе системы разные, поэтому сложно найти универсальный подходк созданию аналитических моделей. Тем не менее аналитическая модель системы среднего размера и сложности включает от 50 до 100 классов анализа. Необходимо запомнить, что при создании аналитическоймодели крайне важно ограничиться лишь теми классами, которые являются частью словаря предметной области.

Всегда есть искушение поместить в аналитическую модель и проектные классы (такие как классы, используемые для установления соединений или доступа к базе данных), но этого необходимо избегать (если только предметная область некасается связи или баз данных)! Такое ограничение накладываетсяв попытке сделать аналитическую модель кратким, простым описанием структуры и поведения системы. Все решения по реализации должны приниматься в рабочих потоках проектирования и реализации.Вот некоторые практические приемы создания хорошей аналитической модели:• Аналитическая модель всегда создается на языке соответствующейсферы деятельности.

Абстракции аналитической модели должныформировать часть словаря бизнессферы.•Создаваемые модели должны «рассказывать историю». Каждаядиаграмма должна раскрывать некоторые важные части поведениясистемы. Иначе зачем они нужны? Как создавать такие диаграммы, будет показано при рассмотрении реализации прецедентов.6.6. Что мы узнали145•Необходимо сосредоточиться на отображении основной картины.Не надо углубляться в детали того, как будет работать система. Дляэтого отводится достаточно времени при проектировании.•Необходимо четко различать предметную область (бизнестребования) и область решения (детальные конструктивные соображения).Основное внимание всегда должно быть направлено на абстракциипредметной области.

Например, при моделировании системы электронной торговли в аналитической модели должны присутствоватьклассы Customer (клиент), Order (заказ) и ShoppingBasket (корзина покупок). Здесь не должно быть классов доступа к базе данных иликлассов для установления соединений, поскольку они – артефактыобласти решения.•Всегда необходимо стремиться минимизировать связанность (coupling). Каждая ассоциация между классами увеличивает их связанность. В главе 9 будет показано, как можно максимально сократитьсвязанность с помощью кратностей и навигации по ассоциациям.•Если присутствует естественная и очевидная иерархия абстракций,должна быть рассмотрена возможность применения наследования.При анализе иерархия никогда не должна применяться просто дляповторного использования кода.

Как мы увидим в разделе 17.6, наследование – самая сильная форма связанности классов.•Всегда должен задаваться вопрос: «Модель полезна для всех заинтересованных сторон?» Нет ничего хуже, чем создавать аналитическую модель, которая игнорируется пользователями или проектировщиками и разработчиками. Пока что это происходит оченьчасто, особенно с неопытными аналитиками.

Основная превентивная стратегия при этом – сделать аналитическую модель и процессмоделирования максимально открытыми, по возможности привлечь в него заинтересованные стороны, проводить частые и публичные обзоры.И наконец, модель должна быть простой! Конечно, легче сказать, чемсделать, но нам из собственного опыта известно, что внутри любойсложной аналитической модели можно найти простую. Один из способов упрощения – рассматривать вопрос в общем, не погружаясь в частности.6.6.

Свежие статьи
Популярно сейчас