UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
• проверить действительность кредитной карты; • принять платеж; • распечатать квитанцию. Но эти обязанности, похоже, не соответствуют назначению или интуи тивно понятной семантике корзин для покупок. Они не являются связными и, без сомнения, должны быть заданы где нибудь в другом месте – может быть, в классах 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 – class responsibilities collaborators, класс обязанности участни ки). Этот технический прием использует самый мощный в мире инст 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. Главное при работе с управляющими классами – они должны естест венным образом проистекать из самой предметной области. Некоторые разработчики моделей искусственно вводят управляющие классы для каждого прецедента, чтобы управлять или выполнять этот прецедент. Это опасный подход, в результате которого получается модель, больше похожая на прямую функциональную декомпозицию, чем на настоя щую ОО аналитическую модель. По сути, это одна из причин, по кото |