07 (1158686), страница 2

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 2)

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

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

• класс В агрегирует, содержит или активно использует объекты класса А;

• класс В обладает данными инициализации, которые будут передаваться объектам класса А при их создании (т.е. класс В является информационным экспертом).

Класс В при этом определяется как создатель (creator) объектов класса А.

Если несколько классов удовлетворяют этим условиям, то предпочтительнее использовать в качестве создателя класс, агрегирующий или содержащий класс А.

Согласно образцу "Creator", оба решения подходят, так как с одной стороны объект-контроллер обладает данными, необходимыми для инициализации, с другой стороны объект Student агрегирует объекты Schedule.

Следствия: Образец "Creator" определяет способ распределения обязанностей, связанный с процессом создания объектов. В объектно-ориентированных системах эта задача является наиболее распространенной. Основным назначением образца Creator является выявление объекта-создателя, который при возникновении любого события должен быть связан со всеми созданными им объектами. При таком подходе обеспечивается низкая степень связанности объектов.

В некоторых случаях в качестве создателя выбирается класс, который содержит данные инициализации, передаваемые объекту во время его создания. На самом деле это пример использования образца Information Expert.

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

• Изменения в связанных классах приводят к локальным изменениям в данном классе.

• Затрудняется понимание каждого класса в отдельности.

• Усложняется повторное использование, поскольку для этого требуется дополнительный анализ классов, с которыми связан данный класс.

Следствия: Образец Low Coupling поддерживает независимость классов, что, в свою очередь, повышает возможности повторного использования. Его нельзя рассматривать изолированно от других образцов, таких как Information Expert и High Cohesion. Он также обеспечивает выполнение одного из основных принципов проектирования, применяемых при распределении обязанностей.

Образец "High Cohesion" (высокая функциональная прочность или сильное зацепление обязанностей). Проблема: Нужно распределить обязанности между классами таким образом, чтобы каждый класс не выполнял много разнородных функций или несвязанных между собой обязанностей. Такие классы создавать нежелательно, поскольку они приводят к возникновению таких же проблем, как у классов с сильной связанностью. Решение: Следует распределить обязанности таким образом, чтобы обеспечить высокую функциональную прочность. В терминах объектно-ориентированного проектирования функциональная прочность (cohesion) – это мера взаимодействия и непротиворечивости обязанностей класса. Считается, что элемент обладает высокой прочностью, если его обязанности тесно связаны между собой, и он не выполняет излишнего объема работы. В роли таких элементов могут выступать классы, подсистемы, модули и т.д.

Классы с низкой прочностью, как правило, выполняют обязанности, которые можно легко распределить между несколькими классами. Грубо говоря, можно поделить класс два или более, отмерив каждой части подмножества атрибутов и операций, так чтобы получившиеся части были функционально прочны.

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

Следует обратить внимание, что обязанностью экземпляров классов является не только прием сообщений, но и их отправка другим объектам. То есть объект обязан знать о других объектах, которым он должен будет посылать сообщения.

Образец «Сценарий транзакции»

Аннотация: В управляющем классе заводится по одной операции на каждый запрос. Экземпляр управляющего класса обеспечивает правильную последовательность шагов сценария обработки каждого запроса, рассылая сообщения объектам сущностям, которые сами по себе не реализуют сложного поведения. Типовая последовательность шагов такова: 1) прием входного запроса; 2) получение данных из базы; 3) обработка данных; 4) выдача результата. Все сложное поведение реализовано в контроллерах.

Э
скиз:

Назначение: Главное достоинство: простота, естественность, производительность. Подходит для небольших приложений. Недостаток: при усложнении бизнес-логики дублируется большое количество кода – снижается гибкость и сопровождаемость. В таких случаях нужно применять образец «Модель предметной области».

Образец «Модель предметной области»

Аннотация: Обязанности по обработке запросов распределены по сети объектов-сущностей. В приложении создается слой объектов, описывающих структурные и поведенческие аспекты предметной области. Поведение сочетается с данными и реализуется в сущностях. Управляющие объекты довольствуются ролью посредников между граничными объектами и сущностями.

Э
скиз:

Назначение: Подходит для приложений с запутанной бизнес-логикой. Недостаток: создание модели предметной области более трудоемко, чем реализация сценария транзакции. В простых случаях нужно применять сценарий транзакции.

Отдельные этапы удаления расписания реализуются отдельными объектами. Объект студент обнуляет в себе ссылку на расписание и передает работу дальше объекту-расписанию. Объект-расписание отсылает запрос на удаление ссылки на себя из объекта-курса и освобождает занимаемую собой память.

Набор обязанностей классов, полученный в результате их распределения, должен быть проанализирован на предмет выявления и устранения следующих проблем:

• дублирования одинаковых обязанностей в различных классах;

• противоречивых обязанностей в рамках класса;

• классов с одной обязанностью или вообще без обязанностей;

• классов, взаимодействующих с большим количеством других классов.

Атрибуты классов анализа определяются, исходя из знаний о предметной области, требований к системе, глоссария и бизнес-модели. В процессе анализа атрибуты определяются только для классов-сущностей. Атрибуты должны быть простыми. Сложные атрибуты должны моделироваться как ассоциации между классами.

Связи между классами определяются в два этапа. Начальный набор связей определяется на основе анализа кооперативных диаграмм. Если два объекта обмениваются сообщениями, между ними должна быть ассоциация.

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

Квалификация механизмов анализа состоит в том, что:

• Составляется список всех механизмов анализа.

• Классы анализа ставятся в соответствие механизмам анализа.

• Определяются характеристики механизмов анализа.

Механизмы анализа играют следующие роли:

• Отражают нефункциональные требования к системе (надежность, безопасность и т.д.) и их реализацию в архитектуре системы.

• Представляют собой набор типовых решений, или образцов (patterns), принятых в качестве стандарта данного проекта.

• Позволяют сосредоточиться на преобразовании функциональных требований в программные абстракции, отвлекаясь от особенностей реализации.

Так, имея дело с устойчивыми классами, достаточно указать для них механизм «persistencу», не задумываясь как именно будет реализовано сохранение их экземпляров в базе данных. Пример:

Унификация классов анализа заключается в изменении модели анализа таким образом, чтобы соблюдалось выполнение следующих условий:

• имя и описание каждого класса анализа должно отражать сущность его роли в системе;

• классы с одинаковым поведением, или представляющие одно и то же явление, должны объединяться;

• классы-сущности с одинаковыми атрибутами должны объединяться (даже если их поведение отличается).

По результатам унификации классов должны быть модифицированы описания вариантов использования.

По окончании модель анализа должна быть подвергнута проверке:

1. Все ли классы обоснованы надлежащим образом?

2. Отражает ли имя каждого класса его роль?

3. Представляет ли класс единственную, четко определенную абстракцию?

4. Являются ли все атрибуты и обязанности класса функционально связанными?

5. Отражают ли классы всю функциональность вариантов использованию, заключенную в основных, подчиненных и альтернативных потоках событий?

6. Однозначно ли распределено поведение по классам?

8

Характеристики

Список файлов лекций