Конспект лекций, страница 14

Решение: Следует назначитьобязанность информационному эксперту – классу, у которого имеется информация,требуемая для выполнения обязанности. Пример:: RegistrationController3: // get schedule(forSemester)10: // update with new selections( ): Student: ScheduleПри выполнении подчиненного потока событий "Обновить график" вариантаиспользования "Зарегистрироваться на курсы" студент-пользователь должен получитьдоступ к своему графику прежде, чем изменить его. Согласно образцу "InformationExpert", нужно определить, объект какого класса содержит информацию, необходимуюдля доступа к графику.

На эту роль информационного эксперта, очевидно, претендуетобъект класса-сущности Student, поскольку график принадлежит именно ему. Поэтомусообщение 3 "get schedule(forSemester)" должно быть направлено от контроллера объектукласса Student. После того, как студент получит график и внесет в него необходимыеизменения, они должны быть зафиксированы в объекте Schedule. В данном случае уже сам9объекте Schedule будет играть роль информационного эксперта, поскольку оннепосредственно доступен контроллеру, и сообщение 10 "update with new selections" будетнаправлено именно ему.Следствия:При распределении обязанностей образец Information Expert используется гораздочаще любого другого образца.

Большинство сообщений на диаграммах взаимодействиясоответствуют данному образцу. Образец Information Expert не содержит неясных илизапутанных идей и отражает обычный интуитивно понятный подход. Он заключается втом, что объекты осуществляют действия, связанные с имеющейся у них информацией.Если информация распределена между различными объектами, то при выполнении общейзадачи они должны взаимодействовать с помощью сообщений.В некоторых ситуациях применение образца Information Expert нежелательно.Образец "Creator". Проблема: Нужно определить, кто должен отвечать за созданиенового экземпляра некоторого класса. Создание новых объектов в объектноориентированной системе является одним из стандартных видов деятельности.Следовательно, при назначении обязанностей, связанных с созданием объектов, полезноруководствоваться некоторым основным принципом.

Решение: Следует назначить классуВ обязанность создавать экземпляры класса А, если выполняется одно из следующихусловий:• класс В агрегирует, содержит или активно использует объекты класса А;• класс В обладает данными инициализации, которые будут передаваться объектамкласса А при их создании (т.е. класс В является информационным экспертом).Класс В при этом определяется как создатель (creator) объектов класса А.Если несколько классов удовлетворяют этим условиям, то предпочтительнееиспользовать в качестве создателя класс, агрегирующий или содержащий класс А.Пример: При выполнении подчиненного потока событий "Создать график" вариантаиспользования "Зарегистрироваться на курсы" необходимо решить, кто должен отвечатьза создание нового графика в системе.

На рис. показаны два возможных варианта решенияэтой задачи.: RegistrationController: RegistrationController9: // create with offerings()10: // add schedule(Schedule)9: // create with offerings( ): Student: Schedule: Student10: // create and add shedule(): ScheduleСогласно образцу "Creator", наилучшим решением является вариант справа (новыйобъект класса Schedule создается классом Student, а не RegistrationController, посколькуименно Student удовлетворяет первому из перечисленных выше условий).Следствия: Образец "Creator" определяет способ распределения обязанностей,связанный с процессом создания объектов. В объектно-ориентированных системах этазадача является наиболее распространенной. Основным назначением образца Creator10является выявление объекта-создателя, который при возникновении любого событиядолжен быть связан со всеми созданными им объектами.

При таком подходеобеспечивается низкая степень связанности объектов.В некоторых случаях в качестве создателя выбирается класс, который содержитданные инициализации, передаваемые объекту во время его создания. На самом деле этопример использования образца Information Expert.Образец "Low Coupling" (слабое зацепление или низкая связанность). Проблема:Нужно распределить обязанности между классами таким образом, чтобы снизитьвзаимное влияние изменений в них и повысить возможность повторного использования.Решение: Следует распределить обязанности таким образом, чтобы обеспечить слабоезацепление.

Зацепление (coupling) – это мера, определяющая насколько жестко одинэлемент связан с другими элементами, или каким количеством данных о других элементахон обладает. Элемент со низким зацеплением зависит от небольшого числа другихэлементов. Класс с высоким зацеплением зависит множества других классов. Наличиетаких классов нежелательно, поскольку оно приводит к возникновению следующихпроблем: Изменения в связанных классах приводят к локальным изменениям в данном классе. Затрудняется понимание каждого класса в отдельности. Усложняется повторное использование, поскольку для этого требуетсядополнительный анализ классов, с которыми связан данный класс.Пример: Рассмотрим подчиненный поток событий "Создать график" вариантаиспользования "Зарегистрироваться на курсы" (предыдущий рисунок). Согласно образцу"Low Coupling", наилучшим решением является вариант справа, поскольку при этом укласса RegistrationController будет на одну связь меньше (т.е., будет обеспечено болеенизкое зацепление).Следствия: Образец Low Coupling поддерживает независимость классов, что, в своюочередь, повышает возможности повторного использования и обеспечивает болеевысокую эффективность приложения.

Его нельзя рассматривать изолированно от другихобразцов, таких как Information Expert и High Cohesion. Он также обеспечиваетвыполнение одного из основных принципов проектирования, применяемых прираспределении обязанностей.Образец "High Cohesion" (высокая прочность или сильная связность). Проблема:Нужно распределить обязанности между классами таким образом, чтобы каждый класс невыполнял много разнородных функций или несвязанных между собой обязанностей.Такие классы создавать нежелательно, поскольку они приводят к возникновению таких жепроблем, как у классов с сильной связанностью.

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

Согласнообразцу "High Cohesion", наилучшим решением также является вариант справа, посколькупри этом класс RegistrationController делегирует обязанность создания нового объектакласса Shedule классу Student, и у самого класса RegistrationController будет на однуобязанность меньше (т.е., его прочность будет выше).Следствия: Как правило, класс с высокой прочностью содержит сравнительнонебольшое число методов, которые функционально тесно связаны между собой, и невыполняет слишком много функций. Он взаимодействует с другими классами для11выполнения более сложных задач. Высокая степень однотипной функциональности всочетании с небольшим числом операций упрощают поддержку и модификацию класса, атакже возможность его повторного использования.Следует обратить внимание, что обязанностью экземпляров классов является нетолько прием сообщений, но и их отправка другим объектам. То есть объект обязан знатьо других объектах, которым он должен будет посылать сообщения.

Распределитьобязанности такого рода позволяют образцы Сценарий транзакции и Модель предметнойобласти.Образец «Сценарий транзакции».Аннотация: В управляющем классе заводится по одной операции на каждый запрос.Экземпляр управляющего класса обеспечивает правильную последовательность шаговсценария обработки каждого запроса, рассылая сообщения объектам сущностям, которыесами по себе не реализуют сложного поведения. Типовая последовательность шаговтакова: 1) прием входного запроса; 2) получение данных из базы; 3) обработка данных; 4)выдача результата. Все сложное поведение реализовано в контроллерах.Эскиз:Controllerservice1()service2()DataНазначение:Главное достоинство: простота, естественность, производительность.Подходит для небольших приложений.

Недостаток: при усложнении бизнес-логикидублируется большое количество кода – снижается гибкость и сопровождаемость. В такихслучаях нужно применять образец «Модель предметной области».Пример:: RegForCoursesForm: RegController: Student.: Student:: DBManager2: saveSchedule( )3: addSchedule(Schedule)4: save(Schedule, Student)Образец «Модель предметной области»Аннотация: Обязанности по обработке запросов распределены по сети объектовсущностей. В приложении создается слой объектов, описывающих структурные иповеденческие аспекты предметной области. Поведение сочетается с данными иреализуется в сущностях. Управляющие объекты довольствуются ролью посредниковмежду граничными объектами и сущностями.12Эскиз:Entity1op11()op12()DataEntity2Entity3op21()op22()op31()op32()Назначение: Подходит для приложений с запутанной бизнес-логикой.

Недостаток:создание модели предметной области более трудоемко, чем реализация сценариятранзакции. В простых случаях нужно применять сценарий транзакции.Пример: в системе регистрации на курсы бизнес-логика распределена между классамисущностями: RegistrationController9: deleteSchedule(Semester): Student.10: delete( ): Schedule11: removeStudent(Schedule):CourseOfferingЕсли бы применялся сценарий транзакции, взаимодействие выглядело бы так:: RegistrationController9: deleteSchedule(Semester)11: removeStudent(Schedule): Student:CourseOffering10: delete( ): ScheduleНабор обязанностей классов, полученный в результате их распределения, долженбыть проанализирован на предмет выявления и устранения следующих проблем:• дублирования одинаковых обязанностей в различных классах;13• противоречивых обязанностей в рамках класса;• классов с одной обязанностью или вообще без обязанностей;• классов, взаимодействующих с большим количеством других классов.Атрибуты классов анализа определяются, исходя из знаний о предметной области,требований к системе, глоссария и бизнес-модели.

В процессе анализа атрибутыопределяются только для классов-сущностей. Атрибуты должны быть простыми.Сложные атрибуты должны моделироваться как ассоциации между классами.Связи между классами определяются в два этапа. Начальный набор связейопределяется на основе анализа кооперативных диаграмм. Если два объектаобмениваются сообщениями, между ними должна быть ассоциация.: RegisterForCoursesForm<<boundary>>RegisterForCoursesForm2: // get course offerings( )8: // create schedule with offerings( )<<control>>RegistrationController: RegistrationControllerНа втором этапе, исходя из знаний о предметной области, создаются связи междуклассами-сущностями (ассоциации, агрегации, обобщения). Композиции выделяются наэтапе проектирования, во время анализа используются только агрегации.Квалификация механизмов анализа состоит в том, что: Составляется список всех механизмов анализа. Классы анализа ставятся в соответствие механизмам анализа. Определяются характеристики механизмов анализа.Механизмы анализа играют следующие роли: Отражают нефункциональные требования к системе (надежность, безопасность и т.д.)и их реализацию в архитектуре системы. Представляют собой набор типовых решений, или образцов (patterns), принятых вкачестве стандарта данного проекта. Позволяют сосредоточиться на преобразовании функциональных требований впрограммные абстракции, отвлекаясь от особенностей реализации.Так, имея дело с устойчивыми классами, достаточно указать для них механизм«persistencу», не задумываясь как именно будет реализовано сохранение их экземпляров вбазе данных.