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

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

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

Четвертый путь дает две таблицы (студентов и служащих) и два View (один для персон, второй для студентов-служащих).

Д
ля изображения схем БД в виде диаграмм классов применяется специализированный набор стереотипов – профиль. Рассмотрим пример:

Таблица изображается как класс со стереотипом <<table>>. SQL-запросы также изображаются классами со стереотипом <<view>> (на диаграмме отсутствуют). Столбцы таблиц представлены атрибутами классов-таблиц. Используются стереотипы <<column>> (обычный столбец) <<PK>> (столбец, входящий в первичный ключ), <<FK>> (столбец, входящий во внешний ключ), <<PK/FK>> (столбец, входящий в первичный и во внешний ключ). "Операции" таблиц моделируют ограничения или хранимые процедуры. Классификация студента хранится в отдельной таблице T_Classification. Так как этот класс абстрактный, то в таблице единственный служебный столбец, являющийся и первичным и внешним ключом (<<PK/FK>>). В таблицу T_Classification добавлены два ограничения: первичного и внешнего ключа, ограничение индекса и ограничение уникальности, определяющее, что с каждой записью классификации связана ровно одна запись из одной из двух оставшихся таблиц. Эти две таблицы для подклассов FullTimeClassification и PartTimeClassification. Помимо собственных столбцов в них есть служебный, являющийся и первичным и внешним ключом (<<PK/FK>>). Для <<PK/FK>> в каждой таблице добавлены 3 "операции"-ограничения: индекс, первичный и внешний ключ. Все связи идентифицирующие, так как всюду первичный ключ входит во внешний. Бывают неидентифицирующие связи, если первичный ключ не содержится целиком во внешнем ключе. Мощности на полюсах связей показывают соотношения количеств записей связанных значением внешнего ключа. Композиции указывают на зависимость по существованию между связанными записями.

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

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

1. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 19.

2. Мацяшек Л. А. Анализ и проектирование информационных систем с помощью UML 2.0 – СПб.: Вильямс, 2008 – § 10.9.

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

4. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.

Лекция 10. Образцы проектирования

Образец (паттерн) – это типовое проектное решение конкретной задачи проектирования, описанное специальным образом, чтобы облегчить его повторное применение.

Фактически, каждый паттерн является формализованным опытом лучших разработчиков в индустрии создания ПО. Исторически понятие образца возникло в архитектуре, введено архитектором Кристофером Александром – проектировщиком зданий и городов в конце 1970-х.

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

Основные составляющие части образца:

Имя. Идентифицирует образец, Хорошее имя характеризует решаемую проблему и способ ее решения.

Задача. Описание ситуации, в которой следует применять образец. Это описание включает в себя: постановку проблемы, контекст проблемы, перечень условий, при выполнении которых имеет смысл применять образец.

Решение. Описание элементов архитектуры, связей между ними, функций каждого элемента. Включает в себя UML-диаграммы.

Результаты. Следствия применения паттерна и компромиссы. Преимущества и недостатки образца. Влияние использования образца на гибкость, расширяемость и переносимость системы.

Полное описание образца в сборнике Гаммы и др. («банды четырех») включает:

• Название.

• Назначение (краткое описание функций образца и решаемой задачи).

• Другие известные названия.

• Мотивация (иллюстрация решаемой задачи проектирования).

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

• Структура (диаграмма классов).

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

• Отношения (диаграмма взаимодействия экземпляров классов-участников).

• Результаты.

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

• Пример кода.

• Известные применения (2 или более применений в различных областях).

• Родственные паттерны (связь с другими образцами, различия, использование образца в сочетании с другими).

Каталог образцов³ содержит 23 образца. Существуют другие каталоги – например, каталог Фаулера⁴.

Классификация образцов:

• Порождающие образцы (способы создания экземпляров классов).

• Структурные образцы (способы задания статических связей между проектными классами).

• Образцы поведения (способы организации взаимодействий).

Рассмотрим несколько образцов.

Абстрактная фабрика (Abstract Factory)

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

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

Мотивация: часто встает задача проектирования программной системы независимой от конкретной реализации GUI.

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

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

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

• Система должна конфигурироваться одним из семейств составляющих ее объектов;

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

У
частники:

• AbstractFactory – интерфейс с операциями для порождения экземпляров абстрактных классов-продуктов.

• ConcreteFactory – реализация порождения экземпляров конкретных классов.

• AbstractProduct – интерфейс с операциями класса-продукта.

• ConcreteProduct – реализация абстрактного продукта, объекты которой порождаются одной из конкретных фабрик.

• Client – класс пользующийся интерфейсами AbstractFactory и AbstractProduct.

Отношения:

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

Результаты:

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

• упрощение замены семейств продуктов;

• набор продуктов фиксирован, добавлять новые трудно.

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

П
ример: взаимодействие при создании новых объектов по образцу Абстрактная фабрика.

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

Фабричный метод (Factory method)

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

Назначение: определяет интерфейс для создания объектов, но оставляет реализациям решение о том, какой объект какого именно класса создавать.

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

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

• Класс заранее не знает, объекты каких классов нужно создавать;

• Известно лишь, что это будет экземпляр одного из подклассов (реализации) какого-то абстрактного класса (интерфейса);

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

Участники:

• Product – интерфейс порождаемых объектов;

• ConcreteProduct – конкретные реализации продукта;

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

• ConcreteCreator – реализация создателя для порождения конкретного продукта.

П
ример (редактор разноформатных документов):

Отношения:

Creator полагается на свои подклассы в определении factoryMethod’а, возвращающего экземпляр конкретного продукта.

Результаты:

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

• код связан лишь с интерфейсом класса Product, поэтому может работать с любым конкретным продуктом;

• накладные расходы: при создании даже одного экземпляра конкретного продукта понадобится создать экземпляр ConcreteCreator.

Адаптер (Adapter)

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

Назначение: преобразует один интерфейс в другой, обеспечивая совместимость.

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

С
итуация применимости: обеспечение совместимости существующего класса при его повторном использовании.

Участники:

• Target – требуемый клиентом интерфейс;

• Client – клиент;

• Adaptee – адаптируемый класс или интерфейс;

• Adapter – класс-адаптер, в методе request вызывается specificRequest из Adaaptee.

Отношения:

Адаптер получает запросы клиентов и преобразует их в вызовы операций адаптируемого класса или интерфейса.

Результаты:

• паттерн не работает, если надо адаптировать не только класс, но и его подклассы;

• вводится только один дополнительный объект.

Composite (Компоновщик)

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

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

Мотивация: есть совокупность объектов-контейнеров, состоящих из элементарных объектов и других контейнеров.

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

• нужно представить иерархию объектов «часть-целое»;

• нужно дать одинаковый интерфейс к составным и простым объектам.

У
частники:

• Component – компонент, определяющий единый интерфейс, содержащий реализации общих операций по умолчанию;

• Leaf – простые (элементарные) объекты;

• Composite – составной объект;

• Client – работает с объектами через интерфейс, объявленный в компоненте.

Отношения:

Клиенты вызывают операции Component. Если получатель запроса – лист, то он и обрабатывает запрос. Если – составной объект, то он дополнительно рассылает запросы своим частям.

Результаты:

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

• облегчается добавление новых классов – они являются подклассами Leaf или Composite;

• трудно ограничить состав видов объектов в составе композиции того или иного вида.

Р
ассмотрим пример (диаграмму объектов):

Если требуется запретить появление кнопок определенного вида в окнах определенного вида, то эта задача целиком ложится на программиста, образец Компоновщик нисколько не помогает её решить.

Мост (Bridge)

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

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