Конспект лекций (1158677), страница 20
Текст из файла (страница 20)
Основной ключ – комбинация этихстолбцов.Автомобильмодельпроизводитель 0..1IDАвто1Модель600АвтомобильID1IDПрицепа12Прицепмодель0..1 грузоподъемностьПроизводительМерседесПрицепID2МодельИЖКАМАЗГрузоподъемность10001500В этом случае можно было добавить внешний ключ к какой-либо из таблиц, но не всегдадопускаются пустые значения во внешнем ключе.• «* к *» – для ассоциации заводится отдельная таблица. Ее столбцы – внешние ключидля таблиц классов, связанных ассоциацией.
Основной ключ – комбинация этихстолбцов.3Coursecredits0..nnamecurriculumdescription 0..nnumber+preRequisitesIDCou rse123Cre dits1001501 50IDCou rse133Nam eМАТ АН1МАТ АН2ФУНКАН…………I DCourse212В примере показано, как можно представить в таблицах связи между курсами (чтобызаписаться на курс функционального анализа, необходимо предварительно прослушатьдва курса математического анализа).• «1 к 1..*» – к таблице класса у полюса «1..*» добавляется столбец – внешний ключ длятаблицы класса у полюса «один».• «1 к 0..*» – как «1 к 1..*».Пример:Course Offering tableNumberCourseOffering678- number : StringCourse_ID456789Foreign Key0..*1Primary KeyCourse tableCourse- name- description- number•NameDescription NumberMath 101Algebra456789«0..1 к *» – применяются те же решения, что и в «0..1 к 0..1».Всякий раз, когда при реализации ассоциаций возникают связанные таблицы,возникают и ограничения целостности (в разных случаях разные), т.
е. фактическидобавляется не только внешний ключ и/или таблица, но и триггеры.Отображение классов связанных N-арной ассоциацией:Требуется таблица для хранения связи. Например, в случае тернарной (N=3) связиформируются четыре таблицы, по одной для каждого класса и одна для связи. Таблицасвязи будет иметь среди своих атрибутов ключи каждой из 3х других таблиц.Пример:4Отображение классов-ассоциаций:Атрибуты класса-ассоциации добавляются либо в создаваемую для связи таблицу,либо (если дополнительная таблица не требуется) в ту таблицу, куда добавляется внешнийключ.Пример:СеместрЧитаемыйКурсЛекторКурсIDЛектор IDСеместр IDКурс АтрибутЧитКурс••••Отображение квалифицированных ассоциацийРешение:Определить, какие мощности были бы у полюсов ассоциации без квалификатора.Применить решение для ассоциаций с полученными мощностями.Добавить квалификатор как столбец (или столбцы) в ту же таблицу, куда добавляютсявнешние ключи.Как правило, квалификатор становится частью возможного ключа таблицы, в которуюон добавлен.Пример:Отображение обобщения (наследования):Стратегии:• для каждого класса своя таблица;• для всей иерархии наследования одна таблица;• таблицы только для конкретных (не абстрактных) классов;5Person•StudentEmployeeтаблицы только для различных конкретных классов.Какой именно способ выбрать диктуют соображенияэффективности (скорость в обмен на объем памяти).StudentEmployeeРассмотрим на примере.
Пусть класс Person – абстрактный.При использовании 1-го подхода будут созданы 4таблицы. У таблиц Person, Student, Employee будет дополнительный столбец – тип, вкотором будет храниться реальный тип объекта. Для каждого экземпляра класса Studentбудут две записи, одна в таблице студентов, вторая – в таблице персон. Для экземпляраStudentEmployee – четыре записи, по одной в каждой таблице. При чем у всех их будетодинаковое значение первичного ключа.
Дублирование записей позволит быстро находитьвсех персон, всех студентов и т. п.При втором подходе используется общая разреженная таблица. В ней также длякаждой записи хранится ее тип. Неудобство состоит в том, что для любой записи оперсоне есть риск «залезть» в поля, принадлежащие подклассу.Третий подход позволяет сэкономить одну таблицу – Person – для поиска всехперсон в БД будет создан View, объединяющий записи 3-х созданных таблиц.Четвертый путь дает две таблицы (студентов и служащих) и два View (один дляперсон, второй для студентов-служащих).Литература к лекции 91.
Вендров А. М. Проектирование программного обеспечения экономическихинформационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 4.2. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделированиеи разработка. 2-е изд.: Пер. с англ. – СПб.: Питер, 2007. – Глава 19.3. Мацяшек Л. А. Анализ и проектирование информационных систем с помощью UML2.0 – СПб.: Вильямс, 2008 – § 10.9.6Лекция 10.
Образцы проектированияОбразец (паттерн) – это типовое проектное решение конкретной задачипроектирования, описанное специальным образом, чтобы облегчить его повторноеприменение.Фактически, каждый паттерн является формализованным опытом лучшихразработчиков в индустрии создания ПО. Исторически понятие образца возникло вархитектуре, введено архитектором Кристофером Александром – проектировщикомзданий и городов в конце 1970-х.«Любой паттерн описывает задачу, которая снова и снова возникает в нашейработе, а также принцип ее решения, причем таким образом, что это решение можнопотом использовать миллион раз, ничего не изобретая заново.» Кристофер Александр.Основные составляющие части образца:Имя. Идентифицирует образец, Хорошее имя характеризует решаемую проблему испособ ее решения.Задача.
Описание ситуации, в которой следует применять образец. Это описаниевключает в себя: постановку проблемы, контекст проблемы, перечень условий, привыполнении которых имеет смысл применять образец.Решение. Описание элементов архитектуры, связей между ними, функций каждогоэлемента. Включает в себя UML-диаграммы.Результаты. Следствия применения паттерна и компромиссы.
Преимущества инедостатки образца. Влияние использования образца на гибкость, расширяемость ипереносимость системы.Полное описание образца включает:• Название.• Назначение (краткое описание функций образца и решаемой задачи).• Другие известные названия.• Мотивация (иллюстрация решаемой задачи проектирования).• Применимость (описание ситуаций, в которых применим паттерн. Примерыпроектирования, которые можно улучшить с помощью образца).• Структура (диаграмма классов).• Участники (слоты или роли, задействованные в образце, на место которых следуетподставлять конкретные проектные классы).• Отношения (диаграмма взаимодействия экземпляров классов-участников).• Результаты.• Реализация (сложности, подводные камни при реализации образца, рекомендации,зависимость от языка программирования).• Пример кода.• Известные применения (2 или более применений в различных областях).• Родственные паттерны (связь с другими образцами, различия, использование образца всочетании с другими).Каталог образцов1 содержит 23 образца.
Существуют другие каталоги – например,каталог Фаулера2.Классификация образцов:• Порождающие образцы (способы создания экземпляров классов).• Структурные образцы (способы задания статических связей между проектнымиклассами).• Образцы поведения (способы организации взаимодействий).1Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования.Паттерны проектирования. – СПб.: Питер, 2007.2Фаулер М. Архитектура корпоративных приложений. – М.: Вильямс, 2007.1Рассмотрим несколько образцов.Абстрактная фабрика (Abstract Factory)Классификация: образец порождения объектов.Назначение: предоставляет интерфейс для создания взаимосвязанных ивзаимозависимых объектов, не определяя их конкретных классов.Мотивация: часто встает задача проектирования программной системы независимойот конкретной реализации GUI.Ситуации применимости:• Система не должна зависеть от того как создаются, компонуются и представляютсявходящие в нее объекты;• Входящие в семейство объекты должны использоваться вместе и необходимообеспечить выполнение этого ограничения;• Система должна конфигурироваться одним из семейств составляющих ее объектов;• Предоставляется библиотека классов, реализация которых скрыта за интерфейсом.Участники:• AbstractFactory – интерфейс с операциями для порождения экземпляров абстрактныхклассов-продуктов.• ConcreteFactory – реализация порождения экземпляров конкретных классов.• AbstractProduct – интерфейс с операциями класса-продукта.• ConcreteProduct – реализация абстрактного продукта, объекты которой порождаютсяодной из конкретных фабрик.• Client – класс пользующийся интерфейсами AbstractFactory и AbstractProduct.Отношения:Обычно, во время выполнения создается один экземпляр ConcreteFactory, которыйсоздает экземпляры конкретных продуктов одного из семейств.
Для использованияобъектов другого семейства нужно породить другую конкретную фабрику.Результаты:• изоляция клиента от деталей реализации классов-продуктов (их имена известнытолько конкретной фабрике);• упрощение замены семейств продуктов;• набор продуктов фиксирован, добавлять новые трудно.Представим, что нужно добавить третий класс продуктов. Потребуется добавить2иерархию из 3-х классов и дополнительный метод в каждую фабрику.C lie ntF:C o n cre te Fa cto ry1cre a teP ro du ctAnewA:P ro d uctA1cre a teP ro du ctBne wB:P r o du ctB1Пример: взаимодействие при создании новых объектов по образцу Абстрактная фабрика.Фабричный метод (Factory method)Классификация: образец порождения объектов.Назначение: определяет интерфейс для создания объектов, но оставляет реализациямрешение о том, какой объект какого именно класса создавать.Мотивация: нужно создать экземпляр одной из реализаций интерфейса, но заранеенеизвестно какой.
Например, в текстовом редакторе работающем с разными форматамипри создании нового документа не известен его тип.Ситуации применимости:• Класс заранее не знает, объекты каких классов нужно создавать;• Известно лишь, что это будет экземпляр одного из подклассов (реализации) какого-тоабстрактного класса (интерфейса);• Класс делегирует свои обязанности одному из вспомогательных подклассов ипланируется локализовать знание о том, какой именно из подклассов берет этиобязанности на себя.•••Участники:Product – интерфейс порождаемых объектов;ConcreteProduct – конкретные реализации продукта;Creator – интерфейс порождения экземпляров продукта, в котором определенфабричный метод (factoryMethod), может определять реализацию фабричного метода3•по умолчанию;ConcreteCreator – реализация создателя для порождения конкретного продукта.Пример (редактор разноформатных документов):+docsDocumentopen()Document* docs=CreateDoc();docs.Add(doc);docs->open();...ApplicationcreateDoc()*MyDocumentMyApplicationopen()createDoc()return new MyDocument<<creates>>Отношения:Creator полагается на свои подклассы в определении factoryMethod’а,возвращающего экземпляр конкретного продукта.Результаты:• нет необходимости встраивать в код зависящие от приложения классы;• код связан лишь с интерфейсом класса Product, поэтому может работать с любымконкретным продуктом;• накладные расходы: при создании даже одного экземпляра конкретного продуктапонадобится создать экземпляр ConcreteCreator.Адаптер (Adapter)Классификация: структурный образец.Назначение: преобразует один интерфейс в другой, обеспечивая совместимость.Мотивация: есть библиотечный класс, который можно было бы использовать, но онне поддерживает требуемый интерфейс.Ситуация применимости: обеспечение совместимости существующего класса приего повторном использовании.1ClientAdapterrequest()-theTargetTargetrequest()-AdapteeRef1AdapteespecificRequest()•••Участники:Target – требуемый клиентом интерфейс;Client – клиент;Adaptee – адаптируемый класс или интерфейс;4•Adapter – класс-адаптер, в методе request вызывается specificRequest из Adaaptee.Отношения:Адаптер получает запросы клиентов и преобразует их в вызовы операцийадаптируемого класса или интерфейса.ClientAdr:AdapterAdpt:Adapteereques ts pecReques tРезультаты:паттерн не работает, если надо адаптировать не только класс, но и его подклассы;вводится только один дополнительный объект.Composite (Компоновщик)Классификация: структурный образец.Назначение: организует объекты в древовидные структуры, позволяет клиентамединообразно работать с составными и элементарными объектами.Мотивация: есть совокупность объектов-контейнеров, состоящих из элементарныхобъектов и других контейнеров.Ситуации применимости:• нужно представить иерархию объектов «часть-целое»;• нужно дать одинаковый интерфейс к составным и простым объектам.••ComponentClient••••-theComponent+ operation()+ getChild()1+ addComponent()+ removeComponent()-componentsnLeafComposite+ operation()+ operation()+ getChild()+ addComponent()+ removeComponent()for all children G:G.operation();Участники:Component – компонент, определяющий единый интерфейс, содержащий реализацииобщих операций по умолчанию;Leaf – простые (элементарные) объекты;Composite – составной объект;Client – работает с объектами через интерфейс, объявленный в компоненте.Отношения:5Клиенты вызывают операции Component.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
