Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 18

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

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

Классификация: структурный образец.

Назначение: отделить абстракцию от реализации.

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

С
итуации применимости:

• обеспечение независимости абстракции и реализации;

• необходимо расширять подклассами как интерфейсы, так и их реализации;

• изменения в реализации не должны влиять на клиента;

• необходимо разделить большую иерархию наследования на части.

Участники:

• Abstraction – абстракция, в которой определен интерфейс требуемый клиенту;

• RefinedAbstraction – уточненная абстракция с расширенным интерфейсом;

• Implementor – интерфейс для классов-реализаций;

• ConcreteImplementor – конкретный реализатор.

Отношения:

Абстракция перенаправляет запросы клиента одной из реализаций Implementora.

Результаты:

• реализация отделяется от интерфейса;

• чтобы заменить реализацию нет необходимости перекомпилировать абстакцию и ее клиента;

• система становится более легко модифицируемой.

Фасад (Facade)

Структурный паттерн, идея которого в том, чтобы предоставить унифицированный интерфейс к подсистеме (или пакету) в виде прокси-класса SubsystemProxy (в случае пакета – в виде фасада пакета).

П
ример:

Используется для предоставления простого интерфейса к сложной подсистеме, явного определения точки входа в подсистему, сокращения связей клиентов подсистемы с ее внутренними классами.

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

В системе регистрации ВУЗа для подсистемы BillingSystem создается фасад BillingSystem, реализующий единственную операцию submitBill интерфейса подсистемы IBillingSystem.

Реализация операции заключается в формировании параметра для вызова метода BillingSystemInterface::submit(theTransaction) и собственно вызова этой операции. По сути, фасад здесь является также Адаптером (вызов submitBill преобразуется в вызов submit граничного класса). Ситуация, когда совместно используются несколько образцов, часто встречается на практике.

Диаграмма взаимодействия объектов при использовании образца Фасад.

Proxy (Заместитель)

Классификация: структурный образец.

Назначение: для объекта создается суррогат, контролирующий доступ.

Мотивация: есть «тяжелый» класс, объекты которого разумно создавать по требованию – эта обязанность возлагается на легкие суррогаты.

Ситуации применимости:

• удаленный заместитель (тяжелый объект невыгодно перемещать с узла на узел, поэтому на другом узле его представляет заместитель);

• виртуальный заместитель;

• з
  ащищающий заместитель (проверяет права доступа).

Участники:

• Proxy – заместитель, хранящий ссылку на реальный объект;

• Class_Client – клиентский класс;

• Subject –общий интерфейс для класса и его заместителя;

• RealClass – класс, для которого создается заместитель.

Отношения:

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

Результаты (зависят от вида заместителя):

• удаленный заместитель скрывает тот факт, что реальный объект находится на другом узле (можно экономить сетевой трафик, если создать локальный заместитель удаленного объекта с копиями часто используемых атрибутов);

• виртуальный заместитель оптимизирует приложение («тяжелые» объекты создаются по требованию, пока в их создании нет необходимости, их представляют «легкие» объекты-заместители);

• защищающий заместитель обеспечивает нужный режим доступа к объекту.

Цепочка обязанностей (Chain of Responsibility)

Классификация: образец поведения.

Назначение: избежать привязки отправителя запроса к получателю, давая возможность передать запрос через многих (заранее неизвестно скольких) посредников.

Ситуации применимости:

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

• а
  дресат запроса не указан, но один из группы;

Участники:

• Handler – обобщенный обработчик, все специальные обработчики в цепочке являются его подклассами;

• ConcreteHandler – конкретный обработчик:

  • обрабатывает запрос;

  • знает следующего по цепочке;

  • если может обработать – обрабатывает, иначе передает дальше.

• C
  lient – отправляет запрос началу цепочки.

Например, при вызове справки о кнопке Print кнопка не знает, кто должен показывать справку, поэтому она передает запрос по цепочке окну Print, оно, в свою очередь, главному окну, которое может обработать запрос.

Результаты:

• ослабляется связность (клиент связан лишь с началом цепочки);

• гибкость в распределении обязанностей;

• нет гарантий, что запрос будет обработан, может дойти до конца цепочки и пропасть.

Iterator (Итератор)

Классификация: образец поведения.

Назначение: дать последовательный доступ к набору однородных объектов, не раскрывая его внутреннего представления.

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

Участники:

• Iterator – общий интерфейс для доступа и обхода структуры данных;

• ConcreteIterator –

  • конкретный способ обхода;

  • помнит позицию курсора (текущий элемент);

• Aggregate – интерфейс для создания итератора;

• C
  oncreteAggregate – реализация интерфейса Aggregate.

Результаты:

• поддерживаются разные способы обхода;

• упрощается интерфейс Aggregate;

• есть возможность иметь одновременно несколько активных обходов (столько, сколько объектов-итераторов).

Strategy (Стратегия)

Классификация: образец поведения.

Назначение: Определяет семейство алгоритмов, инкапсулирует каждый из них и делает их взаимозаменяемыми.

Мотивация: есть несколько алгоритмов решения одной задачи, которые нежелательно «зашивать» в клиентский класс.

Ситуации применимости:

• Имеется много родственных классов, отличающихся только поведением.

• Необходимо иметь несколько разных реализаций одной операции.

• Нужно скрыть от клиента сложные, специфичные для алгоритма структуры данных.

• Упрощение кода метода, представляющего собой длинное ветвление или switch.

Участники:

• Strategy – интерфейс общий для семейства алгоритмов;

• ConcreteStrategy – конкретная стратегия, реализующая интерфейс;

• Context – контекст, направляющий запросы клиента стратегиям;

• C
  lient – клиентский класс.

Результаты:

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

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

• Избавляемся от if и switch (улучшаем читаемость кода).

• Интерфейс класса Strategy общий для всех подклассов ConcreteStrategy – неважно, сложна или тривиальна их реализация. Поэтому вполне вероятно, что некоторые стратегии не будут пользоваться всей передаваемой им информацией, особенно простые.

П
риведем пример использования образца для реализации разных стратегий расчета налогов:

Decorator (Декоратор)

Классификация: структурный образец.

Назначение: добавление объекту новых обязанностей в динамике. Альтернатива подклассам.

Мотивация: Например, хотим, чтобы библиотека GUI могла добавлять свойства (рамку) или новое поведение (прокрутку) к любому элементу GUI. Для этого «оборачиваем» элемент GUI в объект-декоратор. Декоратор имеет тот же интерфейс. Он переадресует запросы элементу, который в него «завернут».

Ситуации применимости:

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

• для реализации обязанностей, которые могут быть сняты с объекта;

• когда расширение путем порождения подклассов по каким-то причинам неудобно или невозможно.

Участники:

• Component – интерфейс для декорируемых объектов;

• ConcreteComponent – класс декорируемых объектов;

• Decorator – декоратор, ссылающийся на декорируемый объект и определяющий интерфейс для декораторов, соответствующий интерфейсу Component;

• ConcreteDecorator – реализует какое-либо дополнительное поведение;

• Client – клиентский класс.

Р
езультаты:

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

• Хотя декорированный объект и обычный имеют общий интерфейс, они различны.

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

Р
ассмотрим пример, в котором для класса Ticket применены две обертки для печати с верхним и нижним колонтитулом. Диаграмма классов:

Д
иаграмма кооперации, демонстрирующая цепочку объектов, задействованных при печати:

Литература к лекции 10

1. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. – СПб.: Питер, 2007.

2. Фаулер М. Архитектура корпоративных приложений. – М.: Вильямс, 2007.

3. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007

Лекция 11. Технология создания программного обеспечения. Rational Unified Process (RUP)

Основные определения:

Технология создания ПО (ТС ПО) – это упорядоченная совокупность взаимосвязанных технологических процессов в рамках ЖЦ ПО.

Технологический процесс – это совокупность взаимосвязанных технологических операций.

Технологическая операция – это основная единица работы, выполняемая определенной ролью, которая:

• подразумевает четко определенную ответственность роли;

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

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

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

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

Руководство – практическое руководство по выполнению одной или совокупности технологических операций. Руководства включают методические материалы, инструкции, нормативы, стандарты и критерии оценки качества рабочих продуктов.

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

Основным требованием, предъявляемым к современным ТС ПО, является их соответствие стандартам жизненного цикла (ЖЦ) ПО и оценкой технологической зрелости организаций-разработчиков (ISO 12207, ISO 9000, CMM и др.). Согласно этим нормативам, ТС ПО должна поддерживать полный набор процессов ЖЦ, к которым относятся:

• управление требованиями;

• анализ и проектирование ПО;

• разработка ПО;

• эксплуатация;

• сопровождение;

• документирование;

• управление конфигурацией и изменениями;

• тестирование;

• управление проектом.

Полнота поддержки процессов ЖЦ ПО должна поддерживаться комплексом инструментальных средств (CASE-средств). Также есть ряд других требований:

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

• поддержка поставщика;

• простота использования;

• удовлетворительные стоимостные характеристики.

В качестве примера ТС ПО рассмотрим Rational Unified Process (RUP).

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

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