Арлоу Д., Нейштадт А. UML2 и Унифицированный процесс. Практический объектно-ориентированный анализ и проектирование
Подождите немного. Документ загружается.
184 Глава 8. Выявление классов анализа
информация о том, предпочитает ли он сидеть в самолете у окна или
в проходе. Необходимо сосредоточиться на важных с точки зрения
строящейся системы аспектах реальных сущностей.
Нередко составить первое впечатление о том, «хорош» класс или нет,
можно уже по его имени. В системе электронной коммерции вполне
понятно, какую реальную сущность может обозначать имя Customer;
оно является хорошей кандидатурой для имени класса. ShoppingBasket
также могло бы быть хорошей абстракцией, мы практически интуи
тивно понимаем его семантику. Однако семантика такого имени, как
WebSiteVisitor (посетитель вебсайта), кажется неопределенной и по сути
напоминает роль, выполняемую Customer по отношению к системе элек
тронной коммерции. Необходимо всегда искать «четкую абстракцию» –
чтото, что имеет ясную и очевидную семантику.
Обязанности описывают связный набор операций.
Обязанность – это контракт или обязательство класса по отношению
к его клиентам. По существу, обязанность – это сервис, который класс
предлагает другим классам. Очень важно, чтобы классы анализа име
ли связный набор обязанностей, абсолютно соответствующих назначе
нию класса (которое выражено в его имени) и реальной «сущности»,
моделируемой классом. Возвращаясь к примеру ShoppingBasket, можно
ожидать, что этот класс будет иметь следующие обязанности:
• добавить позицию в корзину;
• удалить позицию из корзины;
• показать позиции, находящиеся в корзине.
Это связный набор обязанностей, обслуживающий коллекцию товар
ных позиций, выбранных покупателем. Он является связным, потому
что все обязанности направлены на реализацию одной цели – обслу
живание корзины для покупок клиента. На очень высоком уровне аб
стракции эти три обязанности можно представить как обязанность
«обслужить корзину».
Теперь в класс ShoppingBasket можно было бы добавить следующие обя
занности:
• проверить действительность кредитной карты;
• принять платеж;
• распечатать квитанцию.
Но эти обязанности, похоже, не соответствуют назначению или интуи
тивно понятной семантике корзин для покупок. Они не являются
связными и, без сомнения, должны быть заданы гденибудь в другом
месте – может быть, в классах CreditCardCompany (компания, продающая
товары по кредитным карточкам), Checkout (касса) и ReceiptPrinter (уст
ройство для распечатки квитанций). Важно правильно распределить
8.3. Что такое классы анализа? 185
обязанности между классами анализа, чтобы обеспечить максималь
ную внутреннюю связность каждого класса.
И наконец, хорошие классы обладают минимальной связанностью
(coupling) с другими классами. Связанность измеряется количеством
классов, с которыми данный класс имеет отношения. Равномерное рас
пределение обязанностей между классами обеспечит в результате низ
кую связанность. Размещение управления или множества обязанно
стей в одном классе приводит к повышению связанности этого класса.
Способы максимального повышения внутренней связности и уменьше
ния связанности рассматриваются в главе 15.
8.3.3. Практические правила создания классов анализа
Здесь приведены некоторые практические правила создания правиль
но сформированных классов анализа.
• В каждом классе должно быть трипять обязанностей – необходимо
стремиться сохранить максимальную простоту классов. Обычно
число обязанностей, которые они могут поддерживать, ограничива
ют тремяпятью. Приводимый ранее класс ShoppingBasket является
хорошим примером класса с небольшим и управляемым количест
вом обязанностей.
• Ни один класс не является изолированным – суть хорошего ОО ана
лиза и проектирования во взаимодействии классов друг с другом
с целью предоставить пользователям значимый результат. По суще
ству, каждый класс должен быть ассоциирован с небольшим коли
чеством других классов, взаимодействуя с которыми он обеспечива
ет требуемый результат. Классы могут делегировать некоторые из
своих обязанностей другим «вспомогательным» классам, предна
значенным для выполнения именно этой конкретной функции.
• Остерегайтесь создания множества очень мелких классов – иногда
это может нарушить баланс распределения обязанностей. Если в мо
дели масса мелких классов, каждый из которых имеет однудве обя
занности, необходимо тщательно проанализировать ситуацию с це
лью объединения нескольких мелких классов в большие.
• Следует опасаться и противоположной ситуации, когда в модели
несколько очень больших классов, многие из которых обладают
большим числом (> 5) обязанностей. Стратегия в этом случае тако
ва: по очереди рассмотреть эти классы и проанализировать возмож
ность их разбиения на несколько меньших классов с допустимым
количеством обязанностей.
• Остерегайтесь «функтоидов»; функтоид – это на самом деле обыч
ная процедурная функция, выдаваемая за класс. Гради Буч любит
рассказывать забавный анекдот о модели очень простой системы,
состоящей из тысяч классов. При тщательном рассмотрении оказа
лось, что в каждом классе была всего одна операция doIt() (сделай
186 Глава 8. Выявление классов анализа
«это»). Опасность функтоидов всегда существует, когда аналитики,
привыкшие к прямой функциональной декомпозиции, впервые бе
рутся за ОО анализ и проектирование.
• Опасайтесь всемогущих классов – классов, которые, кажется, дела
ют все. Ищите классы, в именах которых есть слова «system» (сис
тема) или «controller» (контроллер)! Для решения этой проблемы
необходимо посмотреть, можно ли разбить обязанности всемогуще
го класса на связные подмножества. Если да, то, вероятно, каждый
из этих связных наборов обязанностей можно выделить в отдель
ный класс. Тогда поведение, предлагаемое исходным всемогущим
классом, можно было бы получить за счет взаимодействия этих
меньших классов.
• Необходимо избегать «глубоких» деревьев наследования – суть про
ектирования хорошей иерархии наследования в том, что каждый
уровень абстракции должен иметь четко определенное назначение.
Очень легко создать много по сути бесполезных уровней. Широко
распространенной ошибкой является использование иерархии для
реализации некоторого рода функциональной декомпозиции, где
каждый уровень абстракции имеет только одну обязанность. Это
нецелесообразно во всех отношениях, поскольку ведет к запутан
ной, сложной для понимания модели. В анализе наследование ис
пользуется только там, где есть явная и четкая иерархия наследо
вания, проистекающая непосредственно из предметной области.
Что касается последнего правила, то следует пояснить, что имеется
в виду под понятием «глубокое» дерево наследования. В анализе, где
классы представляют бизнессущности, «глубокое» – это три и более
уровней наследования. Это объясняется тем, что бизнессущности
имеют тенденцию формировать «широкие», а не «глубокие» иерархии
наследования.
При проектировании, когда дерево составляют классы области реше
ния, определение «глубины» зависит от предполагаемого языка реа
лизации. В Java, C++, C#, Python и Visual Basic под «глубоким» пони
мают дерево наследования, содержащее три или более уровней. Одна
ко в Smalltalk деревья наследования могут быть намного более глубо
кими изза структуры системы Smalltalk.
8.4. Выявление классов
Далее в этой главе обсуждается основной вопрос ОО анализа и проек
тирования – выявление классов анализа.
Как указывает Мейер (Meyer) в книге «Object Oriented Software Con
struction» [Meyer 1], нет простого алгоритма правильного выявления
классов анализа. Наличие подобного алгоритма было бы равнозначно
существованию универсального способа разработки ОО программного
8.4. Выявление классов 187
обеспечения, что так же невероятно, как появление универсального
способа доказательства математических теорем.
Тем не менее есть проверенные и протестированные методы, обеспечи
вающие хороший результат. Они представлены ниже и включают ана
лиз текста и интервьюирование пользователей и специалистов предмет
ной области. Но, разумеется, несмотря на все эти методы, правильное
выявление классов зависит от подхода, мастерства и опыта конкретно
го аналитика.
8.4.1. Выявление классов с помощью анализа
существительное/глагол
Анализ существительное/глагол – очень простой способ анализа тек
ста с целью выявления классов, атрибутов и обязанностей. По сути,
существительные и именные группы, встречающиеся в тексте, указы
вают на обязанности или атрибуты класса, а глаголы и глагольные
группы указывают на ответственности и операции класса. Анализ су
ществительное/глагол успешно применяется в течение многих лет,
поскольку основывается на прямом анализе языка предметной облас
ти. Однако необходимо помнить о синонимах и омонимах, поскольку
они могут стать причиной появления ложных классов.
В анализе существительное/глагол анализируется текст. Существитель
ные и именные группы указывают на классы или атрибуты. Глаголы
и глагольные группы служат признаком обязанностей или операций.
Также надо быть очень осторожными, когда предметная область недо
статочно понятна и определена. В этом случае необходимо попытаться
собрать максимум информации об этой области у максимально воз
можного числа людей, изучить аналогичные предметные области за
пределами вашей организации.
Наверное, самый сложный аспект анализа существительное/глагол –
выявление «скрытых» классов. Это классы, которые свойственны
предметной области, но могут никогда не упоминаться явно. Напри
мер, в системе резервирования для компании, занимающейся органи
зацией отдыха, заинтересованные стороны будут говорить о резервиро
вании, бронировании и т. д., но более важная абстракция, Order (Заказ),
может вообще не упоминаться открыто, если ее нет в существующих
бизнессистемах. Обычно признаком выявления скрытого класса яв
ляется «загустевание» системы после введения единственной новой
абстракции. Это происходит на удивление часто; на практике, если
у нас возникают хоть какиенибудь трудности с аналитической моде
лью, мы продолжаем поиск скрытых файлов. Даже если ничего не бу
дет выявлено, это заостряет внимание на некоторых серьезных вопро
сах и улучшает понимание предметной области.
188 Глава 8. Выявление классов анализа
8.4.1.1. Процедура анализа существительное/глагол
Первый шаг в анализе существительное/глагол – собрать максималь
но возможный объем относящейся к делу информации. Хорошими ис
точниками информации являются:
• модель требований;
• модель прецедентов;
• глоссарий проекта;
• чтолибо еще (архитектура, документыконцепции и т. д.).
После сбора документации проводится ее анализ. Делается это очень
просто: выделяется (или регистрируется какимлибо иным способом)
следующее:
• существительные, например рейс;
• именные группы, например номер рейса;
• глаголы, например размещать;
• глагольные группы, например проверить действительность кредит
ной карточки.
Существительные и именные группы могут служить признаком клас
сов или атрибутов классов. Глаголы и глагольные группы – обязанно
стей классов.
Если встретился термин, значение которого осталось непонятным, не
обходимо незамедлительно проконсультироваться у эксперта в пред
метной области и добавить этот термин в глоссарий проекта. Составьте
список существительных, именных групп, глаголов и глагольных
групп, используйте глоссарий проекта, чтобы разрешить противоре
чия с синонимами и омонимами. Результатом этого должен стать спи
сок потенциальных классов, атрибутов и обязанностей.
После создания такого списка производится предварительное распре
деление атрибутов и обязанностей по классам. Сделать это можно, вво
дя классы в средство моделирования и добавляя в них обязанности
в качестве операций. Если были выявлены какиелибо предполагаемые
атрибуты, их также можно предварительно распределить по классам.
В ходе этого процесса может возникнуть некоторое представление об
отношениях между определенными классами (прецеденты – хорошие
источники этого), поэтому можно добавить и коекакие потенциальные
ассоциации. В результате получается модель классов в первом прибли
жении, которая будет уточняться в ходе дальнейшего анализа.
8.4.2. Выявление классов с помощью CRCанализа
Очень хорошим (и забавным) способом привлечения пользователей
к процессу выявления классов является применение CRCанализа
(CRC – classresponsibilitiescollaborators, классобязанностиучастни
ки). Этот технический прием использует самый мощный в мире инст
8.4. Выявление классов 189
румент анализа – клеящуюся записку (стикер)! CRCметод настолько
популярен, что говорят (может быть, это выдумки), что в какойто мо
мент компания, торгующая стикерами, стала выпускать их уже с раз
меткой для имени класса, обязанностей и участников.
CRC – это техника мозгового штурма, при которой важные моменты
предметной области записываются на стикерах.
Начинаем с разметки стикеров, как показано на рис. 8.4. Записка де
лится на три ячейки. В верхней записывается имя предполагаемого
класса, в левой – обязанности, в правой – участники. Участники – это
другие классы, которые могут взаимодействовать с этим классом для
реализации функциональности системы. Ячейка с участниками обес
печивает возможность записи отношений между классами. Другой
способ показать отношения (который мы считаем предпочтительным) –
приклеить записки на доску и провести линии между взаимодейству
ющими классами.
8.4.2.1. Процедура CRCанализа
Если это не совсем простая система, CRCанализ должен всегда ис
пользоваться в сочетании с анализом существительное/глагол преце
дентов, требований, глоссария и другой относящейся к делу докумен
тации. Процедура CRCанализа проста. Ее основная идея – рассорти
ровать данные, поступающие в результате анализа информации. По
этой причине CRCанализ лучше проводить в два этапа.
8.4.2.2. Этап 1: мозговой штурм – сбор информации
Привлечение заинтересованных сторон – важнейшая составляющая
успеха CRC.
Участники – ОО аналитики, заинтересованные стороны и эксперты.
Кроме того, необходим руководитель. Процедура первого этапа сводит
ся к следующему:
1. Объясните участникам, что это настоящий мозговой штурм.
Имя класса: BankAccount
Обязанности:
поддерживать остаток
Участники:
Bank
Рис. 8.4. Разметка стикера
190 Глава 8. Выявление классов анализа
1.1. Все идеи принимаются как хорошие.
1.2. Идеи записываются, но не обсуждаются – никаких споров,
просто записывайте идеи и двигайтесь дальше. Все будет ана
лизироваться позже.
2. Попросите членов команды назвать «сущности» их области дея
тельности, например покупатель, продукт.
2.1. Каждую сущность запишите на клеящуюся записку в качестве
предполагаемого класса или атрибута класса.
2.2. Приклейте записку на стену или доску.
3. Попросите команду сформулировать обязанности этих сущностей,
запишите их в ячейке обязанностей записки.
4. Работая с командой, попытайтесь установить классы, которые мо
гут работать совместно. Перегруппируйте записки на доске соответ
ственно такой организации классов и нарисуйте линии между ни
ми. В качестве альтернативы впишите имена участников в соответ
ствующую ячейку записки.
8.4.2.3. Этап 2: анализ информации
Важные бизнеспонятия обычно становятся классами.
Участники – ОО аналитики и эксперты. Как определить, какие из
клеящихся записок должны стать классами, а какие – атрибутами?
Вернемся к разделу 8.3.2: классы анализа должны представлять чет
кую абстракцию предметной области. Определенные клеящиеся за
писки будут представлять ключевые бизнеспонятия и, непременно,
должны стать классами. Другие записки могут стать классами или ат
рибутами. Если по логике кажется, что записка является частью дру
гой записки, то это верный признак того, что она представляет атри
бут. Кроме того, если записка не кажется особенно важной или не от
личается интересным поведением, стоит рассмотреть возможность
сделать ее атрибутом другого класса.
Если по поводу записки есть какието сомнения, просто сделайте ее
классом. Важно сделать лучшее приближение, а затем довести этот
процесс до логического конца. Всегда можно уточнить модель позже.
8.4.3. Выявление классов путем применения
стереотипов RUP
Из RUP был заимствован метод стереотипов. Идея этого метода состо
ит в том, что в ходе анализа рассматриваются три разных типа класса
анализа. Этот метод позволяет сосредоточить анализ на конкретных
аспектах системы. Мы считаем необязательным использование этого
метода. Его можно применять как дополнение к основным методам
анализа: существительное/глагол и CRCкарточки.
8.4. Выявление классов 191
Согласно RUP считается полезным поискать классы, которые можно обо
значить стереотипами «boundary» (граница), «control» (управление)
и «entity» (сущность).
Стереотипами, приведенными в табл. 8.1, могут быть обозначены три
типа классов анализа.
В следующих трех разделах рассматриваются способы выявления ка
ждого из этих типов классов анализа.
Таблица 8.1
8.4.3.1. Выявление классов типа «boundary»
Классы типа «boundary» существуют на границе системы и общаются
с внешними актерами.
Такие классы можно обнаружить, рассмотрев контекст системы (гра
ницы системы) и выяснив, какие классы являются посредниками ме
жду контекстом системы и его окружением. Согласно RUP существует
три типа «boundary» (граничных) классов:
1. Классы пользовательского интерфейса – классы, связывающие сис
тему и людей.
2. Классы системного интерфейса – классы, связывающие систему
с другими системами.
3. Классы аппаратного интерфейса – классы, связывающие систему
с внешними устройствами, например датчиками.
Каждая связь между актером и прецедентом в модели должна быть
представлена некоторым объектом системы. Эти объекты – экземпля
ры граничных классов. Выяснив, кого или что представляет актер
(табл. 8.2), можно определить тип граничного класса.
Если граничный класс обслуживает более одного актера, эти актеры
должны быть одного типа (представлять человека, систему или уст
ройство). Если граничный класс обслуживает актеров разных типов,
это свидетельствует о плохом проектировании!
Стереотип Пиктограмма Семантика
«boundary» Класс, который является посредником во взаи
модействии между системой и ее окружением.
«control» Класс, инкапсулирующий характерное для пре
цедента поведение.
«entity» Класс, используемый для моделирования посто
янной информации о чемто.
192 Глава 8. Выявление классов анализа
Таблица 8.2
Поскольку речь идет о фазе анализа, важно удерживать эти классы на
соответствующем уровне абстракции. Например, при моделировании
граничного класса, представляющего GUI, необходимо смоделировать
только главное окно. Детализация всех графических элементов, со
ставляющих окно, должна быть перенесена в фазу проектирования.
Или можно ввести пустой класс, представляющий весь пользователь
ский интерфейс.
Аналогично и с классами системного и аппаратного интерфейсов.
Главное – зафиксировать факт существования классапосредника ме
жду системой и чемто еще, но не конкретные детали этого класса. Де
тали будут рассматриваться позже, при проектировании.
Например, если создается система электронной коммерции, нуждаю
щаяся во взаимодействии с системой Inventory (инвентаризация), то
интерфейс для связи с этой системой можно представить классом
InventoryInterface, помеченным стереотипом «boundary». Такой детализа
ции достаточно для аналитической модели.
8.4.3.2. Выявление классов типа «control»
Эти классы являются управляющими – их экземпляры координируют
поведение системы, соответствующее одному или более прецедентам.
Управляющие классы выявляются при рассмотрении поведения сис
темы, описанного прецедентами, и выработке решения о том, как это
поведение должно быть разделено между классами анализа. Простое
поведение часто можно распределить между граничными классами
или классамисущностями. Но более сложное поведение, такое как об
работка заказов, лучше обозначить, добавив соответствующий управ
ляющий класс, например OrderManager (менеджер заказов). Некоторые
разработчики моделей (включая и нас!) часто обозначают управляю
щий класс, дополняя его имя словами Manager или Controller.
Главное при работе с управляющими классами – они должны естест
венным образом проистекать из самой предметной области. Некоторые
разработчики моделей искусственно вводят управляющие классы для
каждого прецедента, чтобы управлять или выполнять этот прецедент.
Это опасный подход, в результате которого получается модель, больше
похожая на прямую функциональную декомпозицию, чем на настоя
щую ОО аналитическую модель. По сути, это одна из причин, по кото
Актер Указывает на
Представляет человека Класс пользовательского интерфейса (GUI)
Представляет систему Класс системного интерфейса
Представляет устройство Класс аппаратного интерфейса
8.4. Выявление классов 193
рой мы считаем использование стереотипов RUP необязательным. Они
могут сбить с толку начинающих разработчиков моделей!
В реальности контроллеры, вытекающие непосредственно из предмет
ной области (а не появляющиеся как побочный продукт определенной
техники анализа), обычно охватывают несколько прецедентов. Удач
ным примером контроллера является класс Registrar (регистратор). Он
задействован во многих прецедентах, описывающих систему регистра
ции курса. Аналогично одному прецеденту может требоваться участие
нескольких управляющих классов.
Если управляющий класс обладает очень сложным поведением, это го
ворит о том, что, вероятно, его можно разбить на два или более про
стых контроллера, реализующих связную часть этого поведения. Ка
ждый из получившихся простых классов должен попрежнему пред
ставлять чтото, что реально имеет место в предметной области. На
пример, при проектировании системы регистрации курса сначала
может быть введен управляющий класс CourseRegistrationController (кон
троллер регистрации курса), координирующий весь процесс. Но по
ведение такого класса очень сложное, поэтому его можно разбить на
ряд взаимодействующих классов, каждый из которых будет отвечать
за одиндва аспекта этого поведения. Класс можно было бы разложить
на классы Registrar, CourseManager (менеджер курсов) и PersonnelManager
(менеджер персонала). Обратите внимание, что каждый из этих клас
сов представляет реальную сущность предметной области.
Хороший способ проанализировать управляющие классы – предста
вить себя в роли такого класса. Что вам пришлось бы сделать в такой
ситуации?
8.4.3.3. Выявление классов типа «entity»
Эти классы моделируют информацию о чемто и обычно имеют очень
простое поведение, состоящее практически только в получении и зада
нии значений. Классы, представляющие постоянную информацию,
например адреса (класс Address) и людей (класс Person), являются клас
самисущностями.
Классысущности:
• пересекают несколько прецедентов;
• с ними оперируют управляющие классы;
• предоставляют и принимают информацию от граничных классов;
• представляют ключевые сущности, которыми управляет система
(например, Customer);
• часто являются постоянными (persistent).
Классысущности выражают логическую структуру данных системы.
Если есть модель данных, классысущности тесно связаны с сущностя
ми или таблицами этой модели.