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

Некоторыеразработчики моделей (включая и нас!) часто обозначают управляющий класс, дополняя его имя словами Manager или Controller.Главное при работе с управляющими классами – они должны естественным образом проистекать из самой предметной области. Некоторыеразработчики моделей искусственно вводят управляющие классы длякаждого прецедента, чтобы управлять или выполнять этот прецедент.Это опасный подход, в результате которого получается модель, большепохожая на прямую функциональную декомпозицию, чем на настоящую ОО аналитическую модель. По сути, это одна из причин, по кото8.4.

Выявление классов193рой мы считаем использование стереотипов RUP необязательным. Онимогут сбить с толку начинающих разработчиков моделей!В реальности контроллеры, вытекающие непосредственно из предметной области (а не появляющиеся как побочный продукт определеннойтехники анализа), обычно охватывают несколько прецедентов. Удачным примером контроллера является класс Registrar (регистратор). Онзадействован во многих прецедентах, описывающих систему регистрации курса. Аналогично одному прецеденту может требоваться участиенескольких управляющих классов.Если управляющий класс обладает очень сложным поведением, это говорит о том, что, вероятно, его можно разбить на два или более простых контроллера, реализующих связную часть этого поведения.

Каждый из получившихся простых классов должен попрежнему представлять чтото, что реально имеет место в предметной области. Например, при проектировании системы регистрации курса сначаламожет быть введен управляющий класс CourseRegistrationController (контроллер регистрации курса), координирующий весь процесс.

Но поведение такого класса очень сложное, поэтому его можно разбить наряд взаимодействующих классов, каждый из которых будет отвечатьза одиндва аспекта этого поведения. Класс можно было бы разложитьна классы Registrar, CourseManager (менеджер курсов) и PersonnelManager(менеджер персонала). Обратите внимание, что каждый из этих классов представляет реальную сущность предметной области.Хороший способ проанализировать управляющие классы – представить себя в роли такого класса.

Что вам пришлось бы сделать в такойситуации?8.4.3.3. Выявление классов типа «entity»Эти классы моделируют информацию о чемто и обычно имеют оченьпростое поведение, состоящее практически только в получении и задании значений. Классы, представляющие постоянную информацию,например адреса (класс Address) и людей (класс Person), являются классамисущностями.Классысущности:•пересекают несколько прецедентов;•с ними оперируют управляющие классы;•предоставляют и принимают информацию от граничных классов;•представляют ключевые сущности, которыми управляет система(например, Customer);•часто являются постоянными (persistent).Классысущности выражают логическую структуру данных системы.Если есть модель данных, классысущности тесно связаны с сущностями или таблицами этой модели.194Глава 8.

Выявление классов анализа8.4.4. Выявление классов из других источниковПомимо анализа существительное/глагол, CRCанализа и стереотиповRUP существует множество других потенциальных источников классов, которые необходимо учитывать. Мы ищем четкие абстракции, которые проецируются на реальные сущности предметной области. Подобным же образом можно найти классы и в реальном мире.•Все физические объекты, такие как самолет, люди и гостиницы,могут обозначать класс.•Документооборот – еще один богатый источник классов. Такие вещи, как счета, заказы и сберегательные книжки, могут указыватьна возможные классы.

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

Примером такой сущности может быть LoyaltyProgram (программа лояльности), например призовая карта. Конечно, сама программа не является конкретной сущностью (ее нельзя пощупать!),но это связная абстракция, поэтому ее можно смоделировать каккласс.8.4.4.1. Базовые шаблоныБазовые шаблоны могут предоставить готовые компоненты аналитической модели.В нашей книге «Enterprise Patterns and MDA» [Arlow 1] описывалось понятие, названное нами базовые шаблоны (archetype patterns).

Это шаблоны бизнеспонятий, настолько распространенных в бизнессистемах,что мы решили считать их понастоящему базовыми. То есть их можносмоделировать один раз и затем использовать повторно, а не моделировать вновь и вновь в каждой новой бизнессистеме. Основная мыслькниги состоит в том, что шаблоны можно использовать в исходном илиизмененном виде, создавая аналитическую модель из компонентов мо+дели (model components). Эта техника называется компонентно+ориен+тированным моделированием (component+based modeling).8.5. Создание аналитической модели в первом приближении195Мы предоставляем следующие базовые шаблоны:•Customer Relationship Management;•Inventory;•Money;•Order;•Party;•Party relationship;•Product;•Quantity;•Rule.Каждый шаблон разработан очень подробно и отличается содержательностью. Их использование позволит сохранить массу человекодней или даже человекомесяцев работы.

Если шаблон не вполне подходит для моделируемой системы, он может служить источником полезных идей для написания собственных классов анализа. Это лучше,чем начинать с чистого листа.Использование шаблонов – это, наверное, самый эффективный способвыявления классов моделей: просто взять их с полки!8.5. Создание аналитической моделив первом приближенииЧтобы создать аналитическую модель в первом приближении, необходимо в инструментальном средстве моделирования объединить в однуUMLмодель результаты анализа существительное/глагол, CRCанализа, стереотипов RUP и изучения других источников классов (особенно базовых шаблонов).

Объединение осуществляется следующимобразом:1. Сравниваются все источники классов.2. Классы анализа, атрибуты и обязанности, полученные из разныхисточников, объединяются и вводятся в инструментальное средство моделирования.2.1. С помощью глоссария проекта выявляются синонимы и омонимы.2.2. Находятся различия в результатах трех методов. Отличия указывают на неопределенности или моменты, требующие болеетщательной проработки.

Обработайте эти различия сейчас илиоставьте это на будущее.3. Участники (или линии между клеящимися записками на доске)представляют отношения между классами. Моделирование отношений будет обсуждаться в главе 9.196Глава 8. Выявление классов анализа4. Корректируются имена классов, атрибутов и обязанностей согласнокакомулибо стандартному соглашению о присваивании имен, принятому в компании, или в соответствии с простыми соглашениями,изложенными в главе 7.Результатом этой деятельности является набор классов анализа, в котором у каждого класса может быть несколько ключевых атрибутови должно быть от трех до пяти обязанностей.

Это аналитическая модель в первом приближении.8.6. Что мы узналиВ этой главе мы описали, что такое классы анализа, и рассмотрели методы поиска таких классов с помощью анализа существительное/глагол, мозгового штурма CRC, применения стереотипов RUP и проверкидругих источников классов.Вы узнали следующее:•В результате UPдеятельности Анализ прецедентов получаем классыанализа и реализации прецедентов.•Классы анализа представляют четкую, точно определенную абстракцию предметной области.•Предметная область – это область, в которой возникла необходимость в программной системе.•Классы анализа должны точно и четко проецироваться в реальное бизнеспонятие.•Бизнеспонятия часто нуждаются в уточнении во время анализа.•Аналитическая модель содержит только классы анализа – любыеклассы, вытекающие из соображений проектирования (области решения), должны быть исключены.•Классы анализа включают:••высокоуровневый набор предполагаемых атрибутов;•высокоуровневый набор операций.Каковы признаки хорошего класса анализа?•Имя класса отражает его назначение.•Класс является четкой абстракцией, которая моделирует одинконкретный элемент предметной области.•Класс проецируется в четко идентифицируемую возможностьпредметной области.•У класса анализа небольшой, определенный набор обязанностей:•обязанность – это контракт или обязательство, которое классимеет перед своими клиентами;8.6.