00 (1158679), страница 10

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

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

Прикладной уровень (Application subsystems) – реализация функциональности вариантов использования.

Бизнес-уровень (Business-specific) – набор компонентов, специфичных для конкретной предметной области.

Уровень промежуточного ПО (Middleware) – платформо-независимые сервисы (GUI, ORB, …)

Уровень базового ПО (System software) – обеспечение вычислительной и сетевой инфраструктуры (ОС, сетевые протоколы и др.).

Благодаря использованию этого образца система получается модифицируемой (т. е. внесение в нее изменений сравнительно не трудоемко) и мобильной (т. е. может переноситься на другие платформы)

Образец «Каналы и фильтры» разбивает большую сложную задачу по обработке данных на упорядоченную совокупность небольших независимых этапов обработки (каждый такой этап – «фильтр»), соединенных «каналами» – потоками данных. При этом для некоторых задач удается добиться эффективного решения за счет конвейера.

Образец «Model-view-controller». Проблема: Изменения во внешнем представлении достаточно вероятны, одна и та же информация представляется по-разному в нескольких местах, система должна быстро реагировать на изменения данных. Решение: выделить набор компонентов 3-х типов: компонентов хранения данных, компонентов представления для пользователей, и компонентов обработки (воспринимающих команды, преобразующих данные и обновляющих представления).

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

Анализ вариантов использования выполняется разработчиками и включает в себя:

• идентификацию классов, участвующих в реализации потоков событий, (так называемых, классов анализа);

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

• унификацию классов анализа;

• квалификацию механизмов анализа.

Анализ вариантов использования является итерационным процессом – делится на несколько итераций, в ходе которых работа ведется над одним или несколькими (но не всеми сразу) вариантами использования. Как правило, распределение вариантов использования по итерациям осуществляется на основе их приоритета (высокоприоритетные раньше, низкоприоритетные позже).

Шаги анализа вариантов использования:

1. Уточнение и дополнение описаний вариантов использования.

2. Для каждой реализации варианта использования:

   1. Выявление классов, участвующих в реализации потоков событий варианта использования.

   2. Распределение поведения, реализуемого вариантом использования, между классами (обязанности классов).

3. Для каждого выявленного класса анализа:

   1. Определение обязанностей класса.

   2. Определение атрибутов и ассоциаций.

   3. Квалификация механизмов анализа.

4. Унификация классов анализа.

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

• граничные классы, являющиеся посредниками при взаимодействии с внешними объектами;

• классы-сущности, представляющие собой основные абстракции (понятия) разрабатываемой системы;

• управляющие классы, обеспечивающие координацию поведения объектов в системе.

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

• пользовательский интерфейс (обмен информацией с пользователем, без деталей UI – кнопок, списков, окон);

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

Способы выделения классов-сущностей:

• Перевод бизнес-сущностей из бизнес-модели в классы-сущности.

• Анализ глоссария (некоторые термины являются именами искомых классов-сущностей).

• Анализ описаний вариантов использования.

Правило выделения управляющих классов: для каждого варианта использования создается ответственный за его реализацию класс управления.

Все созданные при анализе данного варианта использования классы анализа помещаются на диаграмму VOPC (View Of Participating Classes).

Распределение поведения, реализуемого вариантом использования, между классами реализуется с помощью диаграмм взаимодействия (диаграмм последовательности и кооперативных диаграмм). Диаграммы последовательности и кооперативные диаграммы являются как бы двумя ортогональными проекциями, описывающими взаимодействие (проекция на вертикальную плоскость – диаграмма последовательности, на горизонтальную – диаграмма кооперации):

Виды обязанностей классов:

• Знание:

  • наличие информации о данных или вычисляемых величинах;

  • наличие информации о связанных объектах.

• Действие:

  • выполнение некоторых действий самим объектом (прием и обработка входящих сообщений);

  • инициация действий других объектов (отправка исходящих сообщений);

  • координация действий других объектов (посредничество).

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

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

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

Образец “Information Expert”. Проблема: Нужно определить наиболее общий принцип распределения обязанностей между классами. Решение: Следует назначить обязанность информационному эксперту – классу, у которого имеется информация, требуемая для выполнения обязанности.

Следствия: При распределении обязанностей образец 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) выдача результата. Все сложное поведение реализовано в контроллерах.

Э
скиз:

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

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

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