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

Каковы признаки хорошего класса анализа?Признаки хорошего класса анализа можно кратко охарактеризоватьследующим образом:•••его имя отражает его назначение;он является четкой абстракцией, моделирующей один конкретныйэлемент предметной области;он проецируется на четко определяемую возможность предметнойобласти;••у него небольшой четко определенный набор обязанностей;у него высокая внутренняя связность (cohesion);•у него низкая связанность с другими классами (coupling).Имя класса анализа должно отражать его назначение.При анализе делается попытка точно и лаконично смоделировать одинаспект предметной области с точки зрения создаваемой системы.

Например, при моделировании клиента банковской системы необходимозаписать его имя, адрес и т. д. При этом вряд ли представляет интерес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 Construction» [Meyer 1], нет простого алгоритма правильного выявленияклассов анализа.

Наличие подобного алгоритма было бы равнозначносуществованию универсального способа разработки ОО программного8.4. Выявление классов187обеспечения, что так же невероятно, как появление универсальногоспособа доказательства математических теорем.Тем не менее есть проверенные и протестированные методы, обеспечивающие хороший результат. Они представлены ниже и включают анализ текста и интервьюирование пользователей и специалистов предметной области. Но, разумеется, несмотря на все эти методы, правильноевыявление классов зависит от подхода, мастерства и опыта конкретного аналитика.8.4.1. Выявление классов с помощью анализасуществительное/глаголАнализ существительное/глагол – очень простой способ анализа текста с целью выявления классов, атрибутов и обязанностей.

По сути,существительные и именные группы, встречающиеся в тексте, указывают на обязанности или атрибуты класса, а глаголы и глагольныегруппы указывают на ответственности и операции класса. Анализ существительное/глагол успешно применяется в течение многих лет,поскольку основывается на прямом анализе языка предметной области. Однако необходимо помнить о синонимах и омонимах, посколькуони могут стать причиной появления ложных классов.В анализе существительное/глагол анализируется текст. Существительные и именные группы указывают на классы или атрибуты. Глаголыи глагольные группы служат признаком обязанностей или операций.Также надо быть очень осторожными, когда предметная область недостаточно понятна и определена. В этом случае необходимо попытатьсясобрать максимум информации об этой области у максимально возможного числа людей, изучить аналогичные предметные области запределами вашей организации.Наверное, самый сложный аспект анализа существительное/глагол –выявление «скрытых» классов.

Это классы, которые свойственныпредметной области, но могут никогда не упоминаться явно. Например, в системе резервирования для компании, занимающейся организацией отдыха, заинтересованные стороны будут говорить о резервировании, бронировании и т. д., но более важная абстракция, Order (Заказ),может вообще не упоминаться открыто, если ее нет в существующихбизнессистемах. Обычно признаком выявления скрытого класса является «загустевание» системы после введения единственной новойабстракции. Это происходит на удивление часто; на практике, еслиу нас возникают хоть какиенибудь трудности с аналитической моделью, мы продолжаем поиск скрытых файлов.