UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• Модель сложна и непонятна заинтересованным сторонам: в ней не сколько абстрактных прецедентов ( 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 Рабочий поток анализа 6.1. План главы Эта глава начинает наше исследование процесса ОО анализа. Здесь пред ставлен краткий обзор рабочего потока анализа в UP и некоторые практические правила создания аналитических моделей, что создает базу для дальнейшего более подробного обсуждения в следующих гла вах этой части книги. 6.3. Артефакты анализа – метамодель изучаем рабочий поток анализа изучаем лучшие приемы создания аналитических моделей 6.2. Рабочий поток анализа 6.5. Аналитическая модель – практические правила 6.6. Что мы узнали 6.4. Детализация рабочего потока анализа Рис. 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 Wesley 6.3. Артефакты анализа – метамодель 143 6.3. Артефакты анализа – метамодель В рабочем потоке анализа создаются два ключевых артефакта: • классы анализа – ключевые понятия в бизнес сфере; • реализации прецедентов – иллюстрируют, как экземпляры классов анализа могут взаимодействовать для реализации поведения систе мы, описанного прецедентами. С помощью UML можно самостоятельно создавать аналитическую мо дель. Метамодель аналитической модели приведена на рис. 6.3. Синтаксис пакета был представлен ранее (сущности, имеющие вид па пок). Синтаксис класса (прямоугольники) и синтаксис реализации прецедента (овалы, нарисованные пунктирной линией) показаны здесь впервые. Классы рассматриваются в главе 7, пакеты – в главе 11, реа лизации прецедентов – в главе 12. Аналитическую модель можно представить в виде пакета с треуголь ником в верхнем правом углу. Этот пакет содержит один или более па кетов анализа. Мы называем их «пакетами анализа», потому что они являются частью аналитической модели. На рис. 6.3 показаны лишь четыре пакета анализа, но настоящие аналитические модели могут включать множество пакетов. В каждом пакете, в свою очередь, могут находиться вложенные пакеты анализа. 6.4. Детализация рабочего потока анализа На рис. 6.4 показан рабочий поток анализа в UP. Соответствующие деятельности будут рассмотрены в следующих главах. Но чтобы по Аналитическая модель P1 P3 P2 P4 класс анализа реализация прецедента Рис. 6.3. Метамодель аналитической модели 144 Глава 6. Рабочий поток анализа нять их, необходимо рассмотреть классы и объекты. Они будут обсуж даться в главе 7. 6.5. Аналитическая модель – практические правила Все системы разные, поэтому сложно найти универсальный подход к созданию аналитических моделей. Тем не менее аналитическая мо дель системы среднего размера и сложности включает от 50 до 100 клас сов анализа. Необходимо запомнить, что при создании аналитической модели крайне важно ограничиться лишь теми классами, которые яв ляются частью словаря предметной области. Всегда есть искушение по местить в аналитическую модель и проектные классы (такие как клас сы, используемые для установления соединений или доступа к базе дан ных), но этого необходимо избегать (если только предметная область не касается связи или баз данных)! Такое ограничение накладывается в попытке сделать аналитическую модель кратким, простым описани ем структуры и поведения системы. Все решения по реализации долж ны приниматься в рабочих потоках проектирования и реализации. Вот некоторые практические приемы создания хорошей аналитиче ской модели: • Аналитическая модель всегда создается на языке соответствующей сферы деятельности. Абстракции аналитической модели должны формировать часть словаря бизнес сферы. • Создаваемые модели должны «рассказывать историю». Каждая диаграмма должна раскрывать некоторые важные части поведения системы. Иначе зачем они нужны? Как создавать такие диаграм мы, будет показано при рассмотрении реализации прецедентов. Архитектурный анализ Анализ прецедента Анализ класса Разработчик компонентов Архитектор Разработчик прецедентов Анализ пакета Рис. 6.4. Рабочий поток анализа в UP. Воспроизведено с рис. 8.18 [Jacobson 1] с разрешения издательства Addison Wesley 6.6. Что мы узнали 145 • Необходимо сосредоточиться на отображении основной картины. Не надо углубляться в детали того, как будет работать система. Для этого отводится достаточно времени при проектировании. • Необходимо четко различать предметную область (бизнес требова ния) и область решения (детальные конструктивные соображения). Основное внимание всегда должно быть направлено на абстракции предметной области. Например, при моделировании системы элек тронной торговли в аналитической модели должны присутствовать классы Customer (клиент), Order (заказ) и ShoppingBasket (корзина по купок). Здесь не должно быть классов доступа к базе данных или классов для установления соединений, поскольку они – артефакты области решения. • Всегда необходимо стремиться минимизировать связанность (coup ling). Каждая ассоциация между классами увеличивает их связан ность. В главе 9 будет показано, как можно максимально сократить связанность с помощью кратностей и навигации по ассоциациям. • Если присутствует естественная и очевидная иерархия абстракций, должна быть рассмотрена возможность применения наследования. При анализе иерархия никогда не должна применяться просто для повторного использования кода. Как мы увидим в разделе 17.6, на следование – самая сильная форма связанности классов. • Всегда должен задаваться вопрос: «Модель полезна для всех заин тересованных сторон?» Нет ничего хуже, чем создавать аналити ческую модель, которая игнорируется пользователями или проек тировщиками и разработчиками. Пока что это происходит очень часто, особенно с неопытными аналитиками. Основная превентив ная стратегия при этом – сделать аналитическую модель и процесс моделирования максимально открытыми, по возможности при влечь в него заинтересованные стороны, проводить частые и пуб личные обзоры. И наконец, модель должна быть простой! Конечно, легче сказать, чем сделать, но нам из собственного опыта известно, что внутри любой сложной аналитической модели можно найти простую. Один из спосо бов упрощения – рассматривать вопрос в общем, не погружаясь в част ности. 6.6. Что мы узнали Мы рассмотрели следующее: • Анализ заключается в создании моделей, отображающих основные требования и характеристики целевой системы – аналитическое моделирование имеет стратегическое значение. • Основной объем работ рабочего потока анализа выполняется в кон це фазы Начало и в фазе Уточнение. 146 Глава 6. Рабочий поток анализа • Рабочие потоки анализа и определения требований пересекаются, особенно в фазе Уточнение – обычно для выявления неучтенных или искаженных требований полезно анализировать требования по мере их обнаружения. • Аналитическая модель: • всегда создается на языке соответствующей сферы деятельности; • отображает картину в целом; • содержит артефакты, моделирующие предметную область; • рассказывает историю о целевой системе; • полезна максимально возможному числу заинтересованных сто рон. • Аналитические артефакты – это: • классы анализа – ключевые понятия бизнес сферы; • реализации прецедентов – иллюстрируют, как экземпляры клас сов анализа могут взаимодействовать для реализации поведения системы, описанного прецедентами. • Рабочий поток анализа в UP включает следующие деятельности: • Архитектурный анализ • Анализ прецедента • Анализ класса • Анализ пакета • Аналитическая модель – практические правила: • аналитическая модель среднестатистической системы состоит из 50–100 классов анализа; • включаются только классы, моделирующие словарь предметной области; • не формируются решения по реализации; • основное внимание на классах и ассоциациях – минимизация связанности между классами; • наследование применяется там, где присутствует естественная иерархия абстракций; • необходимо стремиться к простоте модели! 7 Объекты и классы 7.1. План главы Эта глава полностью посвящена объектам и классам. Они – основные строительные блоки ОО систем. Если читатель уже хорошо знаком с по нятием объектов и классов, можно пропустить разделы 7.2 и 7.4. Од нако, вероятно, вам будет интересна информация о UML нотации объ ектов (раздел 7.3) и классов (раздел 7.5). Глава завершается обсуждением смежных вопросов области действия операций и атрибутов (раздел 7.5), а также вопросов создания и унич тожения объектов (раздел 7.7). При анализе используется только часть UML синтаксиса класса. НО чтобы не разбрасывать справочную информацию по всей книге и не возвращаться к этому позже, в этой главе рассматривается полный синтаксис класса. 7.2. Что такое объекты? Книга «UML Reference Manual» [Rumbaugh 1] определяет объект как «отдельную сущность с явно выраженными границами, которая ин капсулирует состояние и поведение; экземпляр класса». Объекты объединяют данные и функциональность в единый блок. Объект можно представить как единый пакет данных и функциональ ности. Как правило, единственный путь добраться до данных объекта – вызвать одну из предоставляемых им функций. Эти функции называ ются операциями (operations). Сокрытие данных объекта за уровнем операций известно как инкапсуляция (encapsulation), или сокрытие данных (data hiding). Инкапсуляция в UML не является обязатель ной, поскольку некоторые ОО языки не нуждаются в ней. Однако со |