9.1 Паттерны GRASP Паттерны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам (9шт.) В отличии от паттернов GoF, данные паттерны не имеют выраженной структуры, чёткой области применения и конкретной решаемой проблемы, а представляют собой обобщенные подходы, используемые при проектировании дизайна истемы.

(далее с – структурный, п – поведения)

• Информационный эксперт(с) Описывает основополагающие принципы назначения обязанностей классам и объектам. Повышает связность модулей и не противоречит свойству инкапсуляции.

• Низкая связанность(с) и Высокое зацепление(п) Реализует основополагающий принцип ООП. Позволяет легко модифицировать и сопровождать программный код а также повышает степень его повторного использования.

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

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

• Полиморфизм(п) Позволяет обрабатывать альтернативные варианты поведения на основе типа.

• Чистая выдумка(п) Позволяет устранить высокую связность модулей системы, путем введения дополнительного класса.

Перенаправление(п) Реализует низкую связность между классами, путём назначения обязанностей дополнит. объекту-посреднику.

9.2 Система видов в архитектурных решениях Simens

(Использование концептуального вида было предложено до UML) Система видов включала:

• Концептуальный вид как описание архитектуры системы в понятиях, раскрывающих основные элементы ПО и связи между ними

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

• Вид исполнения, специфицирующий динамическую структуру ПО

• Вид с позиций кодов, включающий кодовые компоненты и их библиотечную организацию в среде разработки

9.3 Архитектурные стили. MVC

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

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

Выполняются задачи:

• К одной модели можно присоединить несколько видов, не затрагивая её реализацию.

• Не затрагивая реализацию видов, можно изменить реакции(контроллер)

• Работа узкоспециализированных разработчиков

9.4 Паттерн компановщик

Компоновщик -- паттерн, структурирующий объекты.

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

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

Primitive — примитив: представляет листовые узлы композиции и не имеет потомков; определяет поведение примитивных объектов в композиции.

Composite — составной объект: определяет поведение компонентов, у которых есть потомки; хранит компоненты потомки; реализует относящиеся к управлению потомками операции в интерфейсе класса Component.

Client — клиент: манипулирует объектами композиции через интерфейс Component

Достоинства паттерна Composite: В систему легко добавлять новые примитивные или составные объекты, так как паттерн Composite использует общий базовый класс Component;

Код клиента имеет простую структуру — примитивные и составные объекты обрабатываются одинаковым образом;

Паттерн Composite позволяет легко обойти все узлы древовидной структуры.

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

10.1 Архитектура по

Структура программы или вычислительной системы, которая включает

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

Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией

Функциональных требований.

10.2 Определение паттерна проектирования

1. Имя. Сославшись на него, мы можем сразу описать проблему проектирования; ее решения и их последствия. Присваивание паттернам имен позволяет проектировать на более высоком уровне абстракции. С помощью словаря паттернов можно вести обсуждение с коллегами, упоминать паттерны в документации, в тонкостях представлять дизайн системы. Название паттерна должно четко отражать его на" значение.

2. Задача. Описание того, когда следует применять паттерн. Необходимо сформулировать задачу и ее контекст. Может описываться конкретная проблема проектирования или перечень условий, при выполнении которых имеет смысл применять данный паттерн.

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

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

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

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