15. Языка uml. Назначение и элементы диаграммы развертывания.

Представление развертывания отражает расположение работающих компонентов на узлах. Узел — это ресурс, используемый во время выполнения программы (например, компьютер, аппаратное устрой­ство или память). Это представление служит для изображения рас­пределения ресурсов и их размещения.Каждый узел должен иметь имя, отличающее его от прочих узлов. Имя - это текстовая строка. Взятое само по себе, оно называется простым именем. Составное имя - это имя узла, к которому спереди добавлено имя пакета, в котором он находится. Имя узла должно быть уникальным внутри объемлющего пакета. Во многих отношениях узлы подобны компонентам. Те и другие наделены именами, могут быть участниками отношений зависимости, обобщения и ассоциации, бывают вложенными, могут иметь экземпляры и принимать участие во взаимодействиях. Однако между ними есть и существенные различия:

• компоненты принимают участие в исполнении системы; узлы - это сущности, которые исполняют компоненты;

• компоненты представляют физическую упаковку логических элементов; узлы представляют средства физического развертывания компонентов.

Первое из этих отличий самое важное. Здесь все просто - узлы исполняют компоненты, компоненты исполняются в узлах.Второе различие предполагает наличие некоего отношения между классами, компонентами и узлами. В самом деле, компонент - это материализация множества других логических элементов, таких как классы и кооперации, а узел - место, на котором развернут компонент. Класс может быть реализован одним или несколькими компонентами, а компонент, в свою очередь, развернут в одном или нескольких узлах. Как показано на рисунке, отношение между узлом и компонентом, который на нем развернут, может быть явно изображено с помощью отношения зависимости. Как правило, вам не придется визуализировать такие отношения. Лучше хранить их как часть спецификации узла.

Соединения. Самый распространенный вид отношения между узлами - это ассоциация. В данном контексте ассоциация представляет физическое соединение узлов, например линию Ethernet, последовательный канал или разделяемую шину. Ассоциации можно использовать даже для моделирования непрямых соединений типа спутниковой линии связи между двумя удаленными процессорами.

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

1. Припишите каждый значимый компонент системы к определенному узлу.

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

3. Изобразите распределение компонентов по узлам одним из трех способов:

• не делайте размещение видимым, но оставьте его на заднем плане модели, то есть в спецификации узла;

• соедините каждый узел с компонентами, которые на нем развернуты, от ношением зависимости;

• перечислите компоненты, развернутые на узле, в дополнительном разделе.

Для иллюстрации третьего способа на рисунке, основанном на предыдущих диаграммах, специфицированы исполняемые компоненты, размещенные в каждом узле. Эта диаграмма несколько отличается от предыдущих - она является диаграммой объектов, на которой визуализированы конкретные экземпляры каждого узла. В данном случае экземпляры RAID-массив и Киоск анонимны, а у остальных двух экземпляров есть имена (с для Консоли и s для Сервера). Для каждого процессора на рисунке отведен дополнительный раздел, показывающий, какие компоненты на нем развернуты. Объект Сервер также изображен со своими атрибутами (processorSpeed - скоростьПроцессора и memory -память), причем их значения видимы.Компоненты не обязательно должны быть статически распределены по узлам системы. В UML можно моделировать динамическую миграцию компонентов из одного узла в другой, как бывает в системах, включающих агенты, или в системах повышенной надежности, в состав которых входят кластерные серверы и реплицируемые базы данных.

16. Назначение и элементы диаграммы «сущность-связь».

17. Назначение и область применения паттернов проектирования.

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

Под паттерна­ми проектирования понимается описание взаимодействия объектов и классов, адап­тированных для решения общей задачи проектирования в конкретном контексте.

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

Одна из классификации паттернов по двум критериям. Пер­вый - цель — отражает назначение паттерна. В связи с этим выделяются:

• порожда­ющие паттерны (создание объектов)

• структурные паттерны (композиции объек­тов и классов)

• паттерны поведения (как классы или объекты взаимодействуют между собой)

Второй критерий - уровень — говорит о том, к чему обычно применяется пат­терн: к объектам или классам.

• Паттерны уровня классов описывают отношения между классами и их подклассами. Такие отношения выражаются с помощью на­следования, поэтому они статичны, то есть зафиксированы на этапе компиляции.

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

Цель /Уровень	Порождающие паттерны	Структурные паттерны	Паттерны поведения
Класс	Фабричный метод	Адаптер (класса)	Интерпретатор Шаблонный метод
Объект	Абстрактная фабрика, Одиночка, Прототип, Строитель	Адаптер (объекта), Декоратор, Заместитель, Компоновщик, Мост, Приспособленец, Фасад	Итератор, Команда, Наблюдатель, Посетитель Посредник, Состояние, Стратегия, Хранитель, Цепочка обязанностей

18. Порождающие паттерны. “Abstract Factory”. “Builder”. “Singleton”.

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

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

Мотивация: Чтобы приложение можно было перенести на другой стандарт, в нем не должен быть жестко закодирован внешний облик. Внешний облик определяет визуальное представле­ние и поведение элементов пользовательского интерфейса - полос прокрутки, окон и кнопок. Если инстанцирование классов для конкретного внешнего облика разбросано по всему приложению, то изменить облик впоследствии будет нелегко. Можно решить эту проблему, определив абстрактный класс WidgetFactory, в котором объявлен интерфейс для создания всех основных элементов пользовательского интерфейса.

Применимость:

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

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

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

• необходимо предоставить библиотеку объектов, раскрывая только их интер­фейсы, но не реализацию.

Структура:

Участники:

• AbstractFactory - абстрактная фабрика: объявляет интерфейс для операций, создающих абстрактные объекты-продукты;

• ConcreteFactory - конкрет­ная фабрика: реализует операции, создающие конкретные объекты-продукты;

• AbstractProduct - абстрактный продукт: объявляет интерфейс для типа объекта-продукта;

• ConcreteProduct - конкретный продукт:

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

-реализует интерфейс AbstractProduct;

• Client - клиент:

-пользуется исключительно интерфейсами, которые объявлены в классах AbstractFactory и AbstractProduct.

Отношения:

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

• AbstractFactory передоверяет создание объектов-продуктов своему под-классу ConcreteFactory.

Результаты:

+ изолирует конкретные классы

Изолирует, клиента от деталей реализации классов. Клиенты манипулируют экземплярами через их абстрактные интерфейсы;

+ упрощает замену семейств продуктов

Приложение может изменить конфигурацию продуктов, просто подставив новую конкретную фабрику; + гарантирует сочетаемость продуктов

- фиксирует набор продуктов

Для поддержки новых продуктов необходимо расширить интерфейс фаб­рики, то есть изменить класс AbstractFactory и все его подклассы.

Builder (строитель)

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

Singleton (одиночка)

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

Аспект: единичный экземпляр класса.

Применимость: должен быть 1 экземпляр некого класса, легко доступный всем клиентам; единственный экземпляр должен расширяться путем порождения подклассов и клиентам нужно иметь возможность работать с расширяемыми классами без изменения своего кода.

19. Порождающие паттерны. “Factory method”. “Prototype”.

Prototype (прототип)

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

Применимость:

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

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

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

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

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

Определяет интерфейс для создания объектов, при этом выбранный класс инстанцируется подклассами

Можно определить инстанциируемый (instantiable) или неинстанциируемый (not instantiable) структурный тип. Для неистанциируемого типа не определяется конструктор, и поэтому невозможно создать значение этого типа. Поэтому такие типы применимы только для определения инстанциируемых подтипов. Назначение неинстанциируемых типов состоит в моделировании абстрактных концепций, на которых основываются более конкретные концепции.

20. Структурные паттерны. “Adapter”. “Bridge”. “Proxy”.

Adapter (адаптер)

Назначение:преобразует (адаптирует) интерфейс одного класса в интерфейс другого, который ожидают клиенты; обеспечивает совместную работу классов с несовместимыми интерфейсами.

Аспект: интерфейс к объекту.

Применимость:

• при несоответствии интерфейса существующего класса потребностям;

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

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

Bridge (мост)

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

Аспект: реализация объекта.

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

Стру-

ктура:

Результаты

• отделение реализации от интерфейса. Объект может динамически изменять свою реализацию. Разделение классов Abstraction и Implementor устраняет также зави­симости от реализации, устанавливаемые на этапе компиляции. Чтобы из­менить класс реализации, вовсе не обязательно перекомпилировать класс Abstraction и его клиентов.

• повышение степени расширяемости. Можно расширять независимо иерар­хии классов Abstraction и Implementor;

• сокрытие деталей реализации от клиентов.

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

Подменяет другой объект для контроля доступа к нему.

21. Структурные паттерны. “Composite”. “Decorator”.

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

Назначение: динамически добавляет объекту новые обязанности.

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

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

Результаты:

+ большая (чем в случае статического наследования) гибкость обеспечивается возможностью динамического добавления объекту новых обязанностей.

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

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

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

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

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

Аспект: структура и состав объекта.

Применимость: нужно представить иерархию объектов вида часть-целое; хотите, чтобы клиенты единообразно трактовали составные и индивидуальные объекты.