ПИАПС / федоров / 1-5

1.2 Архитектурная концептуальная схема Дж.Захмана

1.2 Архитектурная концептуальная схема Дж.Захмана

Схема построена в форме табличной структуры.

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

содержание артефактов:

Слой разработки «Что?» должно быть сделано для каждого

*Слой ответственности «Кто?» станет исполнителем

артефакта

*Слой жизненного цикла «Где?» будет создан соответствующий

Слой метаданных, описание информации и «Как?» она должна

артефакт

быть

*Слой целей «Почему?» следует включать артефакт

*Слой документирования «Где?» будет зафиксирована

информация

1.2 Архитектурная концептуальная схема Дж.Захмана

1.1 Определение понятия «архитектура программного

обеспечения».

Архитектура программного обеспечения (software architecture) —

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

включает программные компоненты (элементы), видимые

снаружи свойства этих компонентов, а также отношения

(взаимодействия) между ними. Архитектура затрагивает не только

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

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

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

обеспечения.

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

1.4 Фабричный метод (порождающий классы)

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

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

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

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

подклассам решение о том, какой класс инстанцировать.

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

Для того, чтобы система оставалась независимой от различных

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

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

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

полиморфизма — классы всех конечных типов наследуют от

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

одного абстрактного базового класса, предназначенного для

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

полиморфного использования. В этом базовом классе

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

определяется единый интерфейс Порождающие паттерны через

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

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

специальная

типов.

управляющая

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

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

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

-Характерной

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

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

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

перенос

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

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

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

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

1.4 Фабричный метод (порождающий классы)

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

архитектуры

Product (продукт) — определяет интерфейс объектов,

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

создаваемых фабричным методом.

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

ConcreteProduct (конкретный продукт) — реализует интерфейс

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

Product.

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

Creator (создатель) — объявляет фабричный метод,

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

возвращающий объект типа Product. Creator может также

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

определять реализацию по умолчанию фабричного метода,

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

который возвращает объект ConcreteProduct. Может вызывать

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

фабричный метод для создания объекта Product.

планах

ConcreteCreator (конкретный создатель) — замещает фабричный

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

метод, возвращающий объект ConcreteProduct.

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

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

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

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

оставаться независимой как от самого процесса создания, так и от

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

типов создаваемых объектов.

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

Недостатки: Method В случае классического варианта паттерна

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

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

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

создавать соответствующую фабрику.

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

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

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

разработки

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

и коллективной работе

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(определённых объёмов операций, систем и тех. стандартов) и их

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

составляющих в БД

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

Все виды: обзор, обобщения и интегрированный словарь по

ресурсов.

архитектуре.

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

Операционные виды: специфика деятельности и операции, узлы

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

операций и соединений, информационный обмен,

необходимой

организационные отношения, правила операций,

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

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

Системные виды: система и её компоненты, системные

интерфейсы, коммуникативное взаимодействие, матрица

отношений на множестве систем

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

2.4 Абстрактная фабрика (порождающий объекты)

Peer-to-peer

Предоставляет интерфейс для создания семейств

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

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

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

Использование:

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

• система не должна зависеть от того, как создаются,

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

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

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

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

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

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

этого ограничения;

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

Участники:

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

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

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

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

пиры.

ConcreteFactory (ConcreteFactory1, ConcreteFactory2) —

конкретная фабрика: реализует операции, создающие конкретные

объекты продукты AbstractProduct (AbstractProductА,

AbstractProductВ) — абстрактный продукт: объявляет интерфейс

для типа объекта продукта.

ConcreteProduct (ProductА, ProductВ) — конкретный продукт:

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

конкретной фабрикой (например, лучник, всадник), — реализует

интерфейс Abstract Product.

Client — клиент: пользуется исключительно интерфейсами,

которые объявлены в классах AbstractFactory и AbstractProduct

2.4 Абстрактная фабрика (порождающий объекты)

3.1 Основные цели и задачи стандарта IEEE 1471-2000

Нацелен на архитектурное описание (АО) систем, интенсивно

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

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

на проектирование, конструирование, развертывание и

эволюцию системы как целого;

предполагает, что организации и предприятия, решившие

использовать стандарт, должны сами решать, в каком объеме и

как он будет внедряться в разработки ПО;

дает широкие рамки интерпретации архитектуры, как средства,

пригодного для процесса разработки ПО;

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

согласовано широким кругом лиц, вовлеченных в разработку

ПО, в то время как система, проект, процесс и организация работ

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

такой возможности обычно не предоставляют (из-за специфики

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

Скрывает сам процесс порождения объектов, а также

определяет концептуальную структуру (систему понятий)для

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

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

объектов.

Позволяет быстро настраивать систему на нужное

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

мышления;

семейство создаваемых объектов. В случае

многоплатформенного графического приложения для

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

перехода на новую платформу, т. е. для замены

рассуждений об архитектурной форме существования ПО в виде

графических элементов одного стиля другим достаточно

архитектурного описания;

создать нужный подкласс абстрактной фабрики.

3.1 Основные цели и задачи стандарта IEEE 1471-2000

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

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

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

ПО,

жизненного цикла ПО и использования АО;

служит как базис для развития ПО на ранних этапах разработки,

когда доступно только общееп редставление о проекте;

вводит в системы требований для разработки ПО специальный

раздел «архитектурных требований»;

идентифицирует и устанавливает тождество в описаниях

архитектур и пропагандирует озвученное в архитектурной

практике;

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

достигших достаточной инструментально-технологической

зрелости;

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

существует только общая терминология;

вносит надежду разработчикам ПО, что следование его

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

деятельности

как «быстрее», «лучше» и «дешевле».

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

3.4 Строитель (порождающий объекты)

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

Отделяет конструирование сложного объекта от его

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

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

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

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

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

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

протоколам.

• В системе могут существовать сложные объекты, создание

которых за одну операцию затруднительно или невозможно.

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

Требуется поэтапное построение объектов с контролем

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

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

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

• Алгоритм создания сложного объекта не должен зависеть от

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

того, из каких частей состоит объект и как они стыкуются между

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

собой;

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

• Процесс конструирования должен обеспечивать различные

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

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

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

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

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

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

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

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

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

3.4 Строитель (порождающий объекты)

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

Участники:

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

Director — распорядитель: конструирует объект, пользуясь

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

интерфейсом Builder.

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

Builder — строитель: задает абстрактный интерфейс для создания

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

частей объекта Product.

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

ConcreteBuilder — конкретный строитель:

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

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

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

реализации интерфейса Builder;

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

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

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

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

Product — продукт:

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

• представляет сложный конструируемый объект. ConcreteBuilder

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

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

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

его сборки;

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

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

числе интерфейсы для сборки конечного результата из частей.

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

Достоинства: Возможность контролировать процесс создания

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

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

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

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

Недостатки: ConcreteBuilder и создаваемый им продукт жестко

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

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

продукта придется изменять и класс ConcreteBuilder.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-MDA – архитектурный подход к построению много

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

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

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

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

(модели) с последующим переходом к исходному коду системы

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

через автоматизированную генерацию кода.

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

-Основной целью разработчиков MDA являлось создание

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

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

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

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

систем и платформами. Для решения этойз адачив MDA вводятся

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

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

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

(PlatformSpecificModel(PSM)), и модели, независимой от

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

платформы (Platform Independent Model (PIM)).

-MDA предполагает создание PIM и последующий переход к PSM с

использованием специализированных средств. Кроме того

возможен переход от одной PSM модели к другой.

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

4.4 Прототип (Prototype) (порождающий объекты)

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

Назначение: Задает виды создаваемых объектов с помощью

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

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

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

копирования этого прототипа.

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

Можно использовать в следующих случаях:

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

• система должна оставаться независимой как от процесса

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

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

OMG.

Непосредственное использование выражения new в коде

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

приложения считается нежелательным;

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

• необходимо создавать объекты, точные классы которых

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

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

Применимость: Используйте паттерн прототип, когда система не

должна зависеть от того, как в ней создаются, компонуются и

представляются продукты

4.4 Прототип (Prototype) (порождающий объекты)

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

Участники

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

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

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

самого себя.

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

ConcretePrototype — конкретный прототип: реализует операцию

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

клонирования себя.

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

Client — клиент: создает новый объект, обращаясь к прототипу с

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

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

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

Достоинства: Для создания новых объектов клиенту

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

необязательно знать их конкретные классы. Возможность гибкого

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

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

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

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

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

реестр.

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

Недостатки: Каждый тип создаваемого продукта должен

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

реализовывать операцию клонирования clone(). В случае, если

Пр:

требуется глубокое копирование объекта (объект содержит

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

ссылки или указатели на другие объекты), это может быть

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

непростой задачей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

системы.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.4 Одиночка (Singleton) (порождающий объекты)

5.4 Одиночка (Singleton) (порождающий объекты)

Гарантирует, что у класса есть только один экземпляр, и

Отношения:

предоставляет к нему глобальную точку доступа.

Клиенты получают доступ к экземпляру класса Singleton только

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

через его операцию Instance.

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

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

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

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

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

экземпляра.

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

2. Паттерн легко адаптировать для создания нужного числа

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

экземпляров.

кода.

3. Возможность создания объектов классов, производных от

Singleton.

Недостатки:

В случае использования нескольких взаимозависимых одиночек

их реализация может резко усложниться.

Участники :

Singleton — одиночка:

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

получать доступ к единственному экземпляру. Instance — это

метод класса и статическая функция-член в C++;

• может нести ответственность за создание собственного

уникального экземпляра.