ПИАПС / федоров / 11mod

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

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

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

предполагает разделение

Система видов включала:

данных приложения,

Концептуальный вид как описание архитектуры системы в

пользовательского

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

интерфейса и управляющей

ними

логики на три отдельных

Модульный вид, раскрывающий функциональную

компонента: модель,

декомпозицию ПО и распределение по уровням детализации

предоставление и

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

контроллер, таким образом,

ПО

что модификация каждого

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

компонента может

библиотечную организацию в среде разработки

осуществляться независимо.

Модель предоставляет

данные предметной области представлению и реагирует на

команды контроллера, изменяя свое состояние. Представление

отвечает за отображение данных модели пользователю, реагируя

на изменения модели. Контроллер интерпретирует действия

пользователя, оповещая модель о необходимости изменений.

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

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

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

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

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

К одной модели можно присоединить несколько видов, не

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

затрагивая её реализацию.

единообразно трактовать индивидуальные и составные объекты.

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

реакции(контроллер)

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

Component -- компонент: объявляет интерфейс для компонуемых

объектов; предоставляет подходящую реализацию операций по

умолчанию, общую для всех классов; объявляет интерфейс для

доступа к потомкам и управления ими; определяет интерфейс для

доступа к родителю компонента в рекурсивной структуре и при

необходимости реализует его.

Primitive — примитив: представляет листовые узлы композиции и

не имеет потомков; определяет поведение примитивных

объектов в композиции.

17.4 Наблюдатель (паттерн поведения)

10.1 Архитектура ПО Структура программы или вычислительной

Composite — составной объект: определяет поведение

системы, которая включает

компонентов, у которых есть потомки; хранит компоненты

программные компоненты(элементы), видимые снаружи свойства

потомки; реализует относящиеся к управлению потомками

этих компонентов, а также отношения(взаимодействия) между

операции в интерфейсе класса Component.

ними. Архитектура затрагивает не только структуру и поведение,

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

но также использование, функциональность, и другие аспекты.

интерфейс Component

Этот термин также относится к документированию архитектуры

Достоинства паттерна Composite: В систему легко добавлять

программного обеспечения. Документирование архитектуры ПО

новые примитивные или составные объекты, так как паттерн

упрощает процесс коммуникации между стейкхолдерами

Composite использует общий базовый класс Component;

(stakeholders—лица заинтересованные в проекте), позволяет

Код клиента имеет простую структуру — примитивные и

зафиксировать принятые на ранних этапах проектирования

составные объекты обрабатываются одинаковым образом;

решения о высокоуровневом дизайне системы и позволяет

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

использовать компоненты этого дизайна и шаблоны повторно в

структуры.

других проектах.

Недостатки паттерна Composite: Неудобно осуществить запрет на

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

добавление в составной объект Composite объектов

требований к системе, в то время как проектирование ПО является

определенных типов. Так, например, в состав римской армии не

реализацией

могут входить боевые слоны.

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

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

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

1. Имя. Сославшись на него, мы можем сразу описать проблему

Таким образом, под паттернами проектирования понимается

проектирования; ее решения и их последствия. Присваивание

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

паттернам имен позволяет проектировать на более высоком

для решения общей задачи проектирования в конкретном

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

контексте. Паттерн проектирования именует, абстрагирует и

обсуждение с коллегами, упоминать паттерны в документации, в

идентифицирует ключевые аспекты структуры общего решения,

тонкостях представлять дизайн системы. Название паттерна

которые и позволяют применить его для повторно используемого

должно четко отражать его на" значение.

дизайна. Он вычленяет участвующие классы и экземпляры, их

2. Задача. Описание того, когда следует применять паттерн.

роль и отношения, а также функции. При описании каждого

Необходимо сформулировать задачу и ее контекст. Может

паттерна внимание акцентируется на конкретной задаче

описываться конкретная проблема проектирования или перечень

проектирования. Анализируется, когда следует применять

условий, при выполнении которых имеет смысл применять

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

данный паттерн.

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

3. Решение. Описание элементов, отношений между ними,

Под паттернами проектирования понимается описание

функций каждого элемента. Конкретный дизайн или реализация

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

не имеются в виду, поскольку паттерн применим в самых разных

решения общей задачи проектирования в конкретном контексте.

ситуациях. Дается абстрактное описание задачи проектирования и

того, как она может быть решена с помощью некоего весьма

обобщенного сочетания классов и объектов.

4. Результаты — это следствия применения паттерна и разного

рода компромиссы. Хотя при описании проектных решений о

последствиях часто не упоминают, знать о них необходимо, чтобы

можно было выбрать между различными вариантами и оценить

преимущества и недостатки данного паттерна.

10.3 Архитектурные стили. Клиент – сервер.

10.4 Паттерн стратегия

Решает недостатки архитектуры файл-сервер.

Стратегия -- паттерн поведения объектов.

Назначение:Определяет семейство алгоритмов, инкапсулирует

Программы расположенные на сервере ожидают от клиентских

каждый из них и делает их взаимозаменяемыми.

программ запросы и предоставляют им свои ресурсы в виде

Стратегия позволяет изменять алгоритмы независимо от клиентов,

данных (загрузка файлов посредством HTP, FTP, потоковое

которые ими пользуются.

мультимедиа) или сервисных функций (работа с электронной

почтой, просмотр - страниц).

БД в этом случае помещается на сетевом сервере, как и в

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

приложения не происходит. Функции прямого обращения к БД

осуществляет

специальная

управляющая

программа – сервер

Участники

БД, поставляемая

Strategy — стратегия: объявляет общий для всех поддерживаемых

разработчиком СУБД.

алгоритмов интерфейс. Класс Context пользуется этим

Характерной

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

особенностью

в классе ConcreteStrategy.

архитектуры клиент –

ConcreteStrategy — конкретная стратегия: реализует алгоритм,

сервер является

использующий интерфейс, объявленный в классе Strategy.

перенос

Context (Comporessor) — контекст:

вычислительной нагрузки на сервер БД и максимальная разгрузка

• конфигурируется объектом класса ConcreteStrategy;

приложения клиента от вычислительной работы, а также

• хранит ссылку на объект класса Strategy;

существенное укрепление безопасности данных – как от

• может определять интерфейс, который позволяет объекту

злонамеренных, так и просто ошибочных изменений.

Strategy получить доступ к данным контекста.

10.4 Паттерн стратегия

11.1 Выгоды, получаемые от построения и использования

Достоинства и недостатки

архитектуры

1 Семейства родственных алгоритмов. Иерархия классов Strategy

определяет семейство алгоритмов или поведений, которые

Вносит вклад в формирование системы требований к ПО

можно повторно использовать в разных контекстах. Наследование

Показывает совокупность ранних проектных решений

позволяет вычленить общую для всех алгоритмов

Описывает организационную структуру ПО

функциональность.

Является общим базисом для линеек программных продуктов

2 Альтернатива порождению подклассов. Можно напрямую

Позволяет учитывать согласовывать предсказывать

породить от Context подклассы с различными поведениями. Но

характеристики качества, в том числе и по результатам ее

при этом поведение жестко «зашивается» в класс Context, что

исследования

затрудняет понимание, сопровождение и расширение контекста.

Дает информацию о распределении работ и их календарных

Кроме того, заменить алгоритм динамически уже не удастся. В

планах

результате вы получите

Дает возможность для более точной оценки стоимости и

множество родственных классов, отличающихся только

расписания работ

алгоритмом или поведением. Инкапсуляции алгоритма в

Снижает риски

отдельный класс Strategy позволяют изменять его независимо от

Является первой формой существования ПО, которая может

контекста.

быть проверена как целое

3 С помощью стратегий можно избавиться от условных

Предоставляет возможность для переноса или повторного

операторов.

использования стилей и архитектурных каркасов

Благодаря паттерну стратегия удается отказаться от условных

Приносит выгоду в ограничении словаря альтернатив проекта

операторов при выборе нужного поведения. Инкапсуляция же

или его частей

каждого поведения в отдельный класс Strategy решает эту

Помогает в эволюционном прототипировании

проблему.

Оформляет концептуальную целостность ПО и процесса его

разработки

11.1 Выгоды, получаемые от построения и использования

11.2 Архитектурная концептуальная схема DoDAF

архитектуры

11.2 Архитектурная концептуальная схема DoDAF

11.3 Архитектурные стили. Одноранговые сети.

Технические виды (группа из 12 подвидов) описывают текущий

Peer-to-peer

стандартный профиль и предсказания по его изменениям.

Одноранговая, децентрализованная или пиринговая (равный к

Архитектурная концептуальная схема DoDAF разработана для

равному) сеть—это оверлейная компьютерная сеть, основанная на

военных нужд и в этом плане она является предметно зависимой.

равноправии участников. Часто в такой сети отсутствуют

Отличия схемы MoDAF от схемы DoDAF

выделенные серверы, а каждый узел (peer) является как

1

Потребность решать и моделировать задачи при обретения

клиентом, так и выполняет функции сервера. В отличие от

разного рода комплектующих аппаратного и программного типов.

архитектуры клиент-сервера, такая организация позволяет

2

Потребность моделировать трансформационные программы и

сохранять работоспособность сети при любом количестве и

3

Их взаимозависимости.

любом сочетании доступных узлов. Участниками сети являются

4

Потребность моделировать компетентность и другие виды

пиры.

способностей лиц, вовлеченных в разработку и использование АС.

5

Потребность моделировать необходимые для разработки АС

6

Кадровые ресурсы, подобно моделированию технических

ресурсов.

7

Потребность объединять информационные представления в

8

Традиционные модели архитектуры, чтобы обеспечить

необходимой

9

Информацией работу архитекторов предприятия.

11.4 Паттерн состояния.

11.4 Паттерн состояния.

Состояние — паттерн поведения объектов.

Подклассы StateOne, StateTwo, StateThree — конкретное

Паттерн State позволяет объекту изменять свое поведение в

состояние: каждый подкласс реализует поведение,

зависимости от внутреннего состояния. Создается впечатление,

ассоциированное с некоторым состоянием контекста Context.

что объект изменил свой класс.

Достоинства:

Паттерн State является объектно-ориентированной реализацией

Локализует зависящее от состояния поведение и делит его на

конечного автомата.

части, соответствующие состояниям, переходы между

состояниями становятся явными.

12.1 Антипаттерны

12.2 Архитектурная концептуальная схема TOGAF

TOGAF (The Open Group Architecture Framework)

Антипаттерны в противовес практики хорошего

Основным полем для применения TOGAF является, прежде всего,

программная инфраструктура информационной системы (в

программирования — это классы наиболее часто внедряемых

противоположность таким типам архитектур, как бизнес

плохих решений проблем. Они изучаются, как категория чтобы

архитектура, архитектура данных и приложений). Таким образом,

избежать проблем в будущем, либо распознать отдельные случаи

она в наилучшей

их применения при изучении неработающих систем.

мере подходит для описания интеграционных компонент,

Антипаттерны в программировании:

использующихся для поддержки широкого спектра

• Ненужная сложность (Accidental complexity): внесение ненужной

корпоративных приложений, прежде всего, критичных для

сложности в решение.

бизнеса (mission$critical). Поскольку эта интеграционная

• Действие на расстоянии (Action at a distance): неожиданное

архитектура сильно зависит от принимаемых решений в

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

остальных областях, то в рамках TOGAF в необходимой степени

• Накопить и запустить (Accumulate and fire): установка

рассматриваются и эти смежные области. В состав модели TOGAF

параметров подпрограмм в наборе глобальных переменных.

входят две основные компоненты — методика ADM (Architecture

• Слепая вера (Blind faith): недостаточная проверка корректности

Development Method), определяющая процесс разработки

исправления ошибки или результата работы подпрограммы

архитектуры, и Базовая Архитектура (FoundationArchitecture). Она

• Лодочный якорь (Boat anchor): сохранение более не

дополняется соответствующей базой данных ресурсов,

используемой части системы.

включающей описания архитектурных принципов, примеров

реализации, а также cпециализированный язык ADML. Заметим,

что в описании TOGAF добавлен специальный документ,

поясняющий соответствие между понятиями TOGAF и моделью

Захмана.

12.2 Архитектурная концептуальная схема TOGAF

12.3 Архиектурные стили. Сервис-ориентированная архитектура

Модульный подход к

разработке программного обеспечения, основанный на

использовании распределенных, слабосвязанных заменяемых

компонентов, оснащенных стандартизированными интерфейсами

для взаимодействия по стандартизированным протоколам.

Главное, что отличает SOA — это использование независимых

сервисов с четко определенными интерфейсами, которые для

выполнения своих задач могут быть вызваны неким стандартным

способом, при условии, что сервисы заранее ничего не знают о

приложении, которое их вызовет, а приложение не знает, каким

образом сервисы выполняют свою задачу.

12.3 Архиектурные стили. Сервис-ориентированная архитектура

12.4 Паттерн фасад

SOA также может рассматриваться как стиль архитектуры

Фасад — паттерн, структурирующий объекты.

Паттерн Facade предоставляет унифицированный интерфейс

информационных систем, который позволяет создавать

вместо набора интерфейсов некоторой подсистемы. Facade

приложения, построенные путем комбинации слабо-связанных и

определяет интерфейс более высокого уровня, упрощающий

взаимодействующих сервисов.

использование подсистемы.

SOA может поддерживать интеграцию и консолидацию операций

Паттерн Facade «обертывает» сложную подсистему более

В составе сложных систем, однако SOA не определяет и не

простым интерфейсом.

предоставляет методологий или фреймворков для

документирования сервисов.

стр 21

Участники

Классы SubsystemA, SubsystemB, SubsystemC и т.д. явл

компонентами сложной подсистемы, с которыми должен

взаимодействовать клиент

Client взаимодействует с компонентами подсистемы

Facade - непосредственно фасад, который предоставляет

интерфейс клиенту для работы с компонентами

12.4 Паттерн фасад

13.1 Концептуальный каркас стандарта IEEE 1471-2000

Достоинства:

В рамках концептуального каркаса указаны понятия (и их связи),

Изолирует клиентов от компонентов подсистемы

относящиеся к понятию «архитектурное описание»

Уменьшая тем самым число объектов, с которыми клиентам

(«заинтересованные лица», «интерес заинтересованных лиц»,

приходится иметь дело, упрощая работу с подсистемой

«вид», «точка зрения» и другие детали) и контексту его

Позволяет ослабить связанность между подсистемой и ее

употребления (система, среда, миссия, архитектура). За каждым

клиентами.

понятием стоит его (потенциальное или реальное) материальное

Фасад не исключает возможности приложениям

воплощение определенной составляющей (или ряда

напрямую обращаться к классам подсистемы, если это

составляющих) процесса и/или результата разработки ПО.

необходимо. Таким образом, у вас есть выбор между простотой и

Лица, заинтересованные в разработке – для определения

общностью. Совет конечно очевидный: как можно только в

типовых ролей(приобретающие, эксперты-консультанты,

крайних случаях прибегайте к прямому взаимодействию с классом

пропагандисты, разработчики, сопровождающие, снабженцы,

за фасадом, лучше если возможно все же как-нибудь

пользователи, администраторы, тестировщики).

обобщить/абстрагировать эту операцию и добавить ее в сам

Интерес – интерес лица, находящегося в определённой роли к

фасад.

процессу разработки ПО

Точка зрения – позиция с которой определённая группа лиц

заинтересованных в разработке ПО, желает, привыкла, готова или

в состоянии представить ПО как целое

Вид – проекция ПО на определённый интерес или интересы.

Концептуальный каркас в стандарте оформлен в виде

семантической сети, связывающей определенными отношениями

основные понятия архитектуры ПО. За отбор подходящих средств

и их использование несет ответственность архитектор.

13.1 Концептуальный каркас стандарта IEEE 1471-2000

13.2 Архитектурная концептуальная схема FEAF

Ее специфика связана с разработкой ПО в рамках системы задач

государственного масштаба для США.

Федеральная архитектура — это концептуальная модель описания

деятельности федерального правительства и государственных

организаций с функциональной точки зрения, вне зависимости от

организационных структур, реализующих соответствующие

функции, с целью улучшения их деятельности за счет

использования информационных технологий. Подобные задачи в

нашей стране намечено решать в рамках «Электронной России».

Федеральная архитектура — определяет функции

государственных организаций, информацию и технологии,

необходимые для их реализации, а также процессы

преобразований, необходимые для внедрения новых

информационных технологий. Отдельные государственные

организации должны использовать эту общую модель для

описания своих собственных архитектур.

13.2 Архитектурная концептуальная схема FEAF

13.3 Архитектурные стили. Архитектура, управляемая

моделью(MDA)

13.3 Архитектурные стили. Архитектура, управляемая

13.4 Паттерн интерпретатор

моделью(MDA)

Интерпретатор — паттерн поведения классов.

Консорциум OMG как разработчик MDA не предоставляет никаких

Назначение паттерна Interpreter

программных средств для обеспечения перехода от модели к

Для заданного языка определяет представление его грамматики,

модели. Предполагается, что они будут реализованными силами

а также интерпретатор предложений этого языка.

сторонних разработчиков.

Отображает проблемную область в язык, язык — в грамматику, а

Фактически, MDA — это концепция разработки, поддержанная

грамматику — в иерархии объектно-ориентированного

группой стандартов (UML, MOF, CWM и XMI), разработанных

проектирования.

OMG. Эти стандарты накладывают требования, которым должны

Удовлетворять модели, и предоставляют рекомендации для

разработчиков сред создания ПО по MDA.

Участники

AbstractExpression — абстрактное выражение: объявляет

абстрактную операцию Interpret, общую для всех узлов в

абстрактном синтаксическом дереве.

TerminalExpression — терминальное выражение:

• реализует операцию Interpret для терминальных символов

грамматики;

13.4 Паттерн интерпретатор

14.1 Архитектурные парадигмы

• необходим отдельный экземпляр для каждого терминального

В публикациях по архитектуре ПО поднимаются вопросы о

символа в предложении.

парадигмах (совокупности фундаментальных установок,

CompoundExpression — нетерминальное выражение:

представлений и терминов) ПО как «модели постановки

• по одному такому классу требуется для каждого

проблемы и ее решения», определяющей основные подходы к

грамматического правила R :: = R1, R2, ..., Rn;

проблемам архитектуры [28, 29, 30].

• хранит переменные экземпляра типа AbstractExpression для

Особую известность в этом получили следующие парадигмы [2].

каждого символа от Rl до Rп;

1. Объектно-ориентированная парадигма, в рамках которой

• реализует операцию Interpret для нетерминальных символов

используется объектно-ориентированный подход (ООП) к

грамматики. Эта операция рекурсивно вызывает себя же для

структуризации ПО на всех этапах ее жизненного цикла.

переменных, представляющихR1, R2, ..., Rn.

В основе этой парадигмы лежат идеи, методы и средства

Context — контекст: содержит информацию, глобальную по

Объектно-Ориентированного Анализа и Проектирования (ООАП).

отношению к Интерпретатору.

В основу ООП положены следующие принципы: абстрагирование,

Client — клиент:

ограничение доступа, модульность, иерархичность,

• строит (или получает в готовом виде) абстрактное

типизация,параллелизм, устойчивость.

синтаксическое дерево, представляющее отдельное предложение

2. Компонентно-ориентированная парадигма, исходящая из

на языке с данной грамматикой. Дерево составлено из

принципов сборочного проектирования, конструирования и

экземпляров классов CompoundExpression и TerminalExpression;

производства ПО, в основе которых лежат программные

• вызывает операцию Interpret.

«компоненты» как единицы сборки.

Достоинства и недостатки

К числу основных характеристик KОА (CBA) относятся:

1 Грамматику легко изменять и расширять.

• опора на компонентные модели

2 Простая реализация грамматики

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

3 Сложные грамматики трудно сопровождать.

проектирования и реализации;

• интерфейсы и взаимодействие находятся в центре интересов

разработки архитектуры ПО;

14.1 Архитектурные парадигмы

14.2 Лица заинтересованные в разработке

• интерфейсы могут обслуживать различные компоненты

Стейкхолдерами могут быть:

• компонентные модели требуют от компонентов поддержки

*Те, кто активно вовлечен в проект и работает в нем (проектная

«действий по самоанализу» так, чтобы их функциональности или

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

свойства могли быть открыты и использованы «во время

сторонние компании и другие исполнители и т.д.)

сборки» или в реальном времени;

*Те, на чьи интересы может повлиять проект и кто будет

• особое внимание уделяется образцам проектирования и

пользоваться его результатами (заказчики, руководители

принципам разделения интересов для определения роли

функциональных подразделений и их сотрудники, бизнес-

компонента и его ответственности.

партнеры, клиенты, покупатели и т.д.)

3. Сервисно-ориентированная парадигма, применение которой

*Те, кто в проект не вовлечен, но кто, в силу своего положения

базируется на идее массового сервисного обслуживания

или профессиональной деятельности, может на него влиять (топ-

пользователей ПО по их запросам.

менеджеры компании, владельцы и инвесторы, акционеры,

К числу основных характеристик СОА (SBA) относятся [2]:

кредиторы, внешние и внутренние партнеры, регулирующие

• свобод соед, заключ в том, что любой сервис может быть

государственные органы и т.д.)

получен как ответ на запрос из любого (разрешенного) источника;

Пр:

• для сервиса не треб ничего запом от одного вызова до другого

1 пользователи (Users) обеспечивающие использование системы

• сервисы являются основными единицами моделирования,

по назначению;

проектирования и реализации;

2 администраторы (Administrators) обеспечивающие

• определение, описание, открытие сервиса, протоколы доступа и

функционирование системы;

аспекты качества являются центральными интересами в

3 тестировщики (Testers) проверяющие корректность работы

архитектурном проектировании ПО;

системы.

• сервис «выставляет напоказ» свои возможности

4 лица (Acquirers) приобретающие систему;

• сервис может быть независимо и динамич обнаруж и использ;

5 эксперты-консультанты (Assesors) проверяющие

• так как сервис не имеет состояний, то обмен данными между

целесообразность приобретения;

распределенными пользователями и провайдерами могут

привести к существенным накладным расходам.

14.2 Лица заинтересованные в разработке

14.3 Архитектурные стили. Пайпы и фильтры.

6 пропагандисты (Communicators) распространяющие сведения об

этом через документы и обучение;

7 разработчики (Developers) создающие систему;

8 сопровождающие (Mainteners) внедряющие, сопровождающие

и развивающие систему;

9 снабженцы (Suppliers) поставляющие «комплектующие части»;

Pump — источник данных в системе; фильтр (filter) — получает

информацию от источника (вначале от внешнего — pump), затем

через PIPE от предыдущего фильтра. После обработки поток

данных отправляется дальше; Pipe — осуществляет передачу

данных от источника информации к фильтру или между

фильтрами в системе; Sink — приемник обработанного фильтрами

потока данных

Недостатки: для большинства применений, фильтр должен

полностью получить весь пакет данных до начала их обработки.

Поэтому возможны существенные временные задержки,

связанные с накоплением данных в буфере или потеря данных в

случае переполнения буфера.

И еще важный фактор — пайпы обычно проектируют для

передачи одного вида данных. Таким образом при

необходимости передавать данные разных типов может

возникнуть необходимость в создании нескольких видов пайпов

для связи между фильтрами.