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

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

Отображение классов связанных N-арной ассоциацией:

Требуется таблица для хранения связи. Например, в случае тернарной (N=3) связи формируются четыре таблицы, по одной для каждого класса и одна для связи. Таблица связи будет иметь среди своих атрибутов ключи каждой из 3х других таблиц.

Отображение классов-ассоциаций:

Атрибуты класса-ассоциации добавляются либо в создаваемую для связи таблицу, либо (если дополнительная таблица не требуется) в ту таблицу, куда добавляется внешний ключ.

Отображение квалифицированных ассоциаций

Решение:

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

• Применить решение для ассоциаций с полученными мощностями.

• Добавить квалификатор как столбец (или столбцы) в ту же таблицу, куда добавляются внешние ключи.

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

Отображение обобщения (наследования):

Стратегии:

• для каждого класса своя таблица;

• для всей иерархии наследования одна таблица;

• таблицы только для конкретных (не абстрактных) классов;

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

Какой именно способ выбрать диктуют соображения эффективности (скорость в обмен на объем памяти). Рассмотрим на примере. Пусть класс Person – абстрактный.

При использовании 1-го подхода будут созданы 4 таблицы. У таблиц Person, Student, Employee будет дополнительный столбец – тип, в котором будет храниться реальный тип объекта. Для каждого экземпляра класса Student будут две записи, одна в таблице студентов, вторая – в таблице персон. Для экземпляра StudentEmployee – четыре записи, по одной в каждой таблице. При чем у всех их будет одинаковое значение первичного ключа. Дублирование записей позволит быстро находить всех персон, всех студентов и т. п.

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

Третий подход позволяет сэкономить одну таблицу – Person – для поиска всех персон в БД будет создан View, объединяющий записи 3-х созданных таблиц.

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

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

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

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

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

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

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

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

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

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

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

• Название.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Абстрактная фабрика (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 – работает с объектами через интерфейс, объявленный в компоненте.

Отношения:

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

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