ПИАПС / федоров / 6-8

8.1Поясните на примере отличия характеристик качества с точки

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

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

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

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

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

Основые характеристики качества:

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

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

ними

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

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

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

ПО

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

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

8.3Архитектурные стили.REST(передача репрезентативного

8.3Архитектурные стили.REST(передача репрезентативного

состояния)

состояни)

Метод взаимодействия компонентов распределённого

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

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

возможности кэширования ответа и получения ответа из

процедуры представляет собой обычный HTTP запрос(обычно GET

существующего кэша;

или POST; такой запрос называют REST - запрос), а необходимые

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

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

произвольным количеством промежуточных узлов. При этом

SOAP, CORBA, RPC).

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

В широком смысле REST означает концепцию построения

за исключением случаев передачи конфиденциальной

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

информации.

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

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

серверов во Всемирной паутине.

Приложения, не соответствующие приведенным условиям, не

Хотя данная концепция лежит в самой основе Всемирной

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

паутины, термин REST был введен Роем Филдинго одним из

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

создателей протокола HTTP, лишь в 2000г.Филдинго писал

надежность(за счет отсутствия необходимости сохранять

Концепцию построения распределенного приложения, при

информацию о состоянии клиента, которая может быть

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

утеряна);

исчерпывающую информацию о желаемом ответе сервера

производительность(за счет использования кэша);

(желаемом

масштабируемость;

Репрезентативном состоянии),и сервер не обязан сохранять

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

информацию о состоянии клиента

для приложений обслуживания сети;

Необходимые условия для построения распределенных REST

простота интерфейсов;

приложений:

портативность компонентов;

клиент-серверная архитектура;

легкость внесения изменений, способность эволюционировать,

сервер не обязан сохранять информацию о состоянии клиента;

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

8.4Паттерн Заместитель,Proxy (структурирующий объекты)

8.4Паттерн Заместитель,Proxy (структурирующий объекты)

Назначение:

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

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

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

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

Участники:

1. Proxy (imageProxy) — Заместитель:

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

реальному субъекту. Объект класса Proxy может обращаться

кобъекту класса Subject, если интерфейсы классов RealSubject и

Subject одинаковы;

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

что Заместитель всегда может быть подставлен вместо реального

Преимущества:

субъекта;

удалённый заместитель;

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

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

его создание и удаление.

оптимизацию;

2. Subject — субъект: определяет общий для RealSubject и

защищающийзаместитель;

Proxy интерфейс, так что класс Proxy можно использовать

«умная» ссылка;

везде, где ожидается RealSubject.

Недостатки:

3. RealSubject (Image) — реальный субъект: определяет

резкоеувеличениевремениотклика.

реальныйобъект, представленный Заместителем.

7.1Перечислите и поясните смысл видов в архитектуре «4+1».

7.1Перечислите и поясните смысл видов в архитектуре «4+1».

Архитектура конкретной ПО описывается множеством ее

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

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

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

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

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

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

выполнения.

получения полезной конфигурации.

4. Вид с позиций процесса, содержащий описание задач

Эти решения должны вытекать из требований функциональности

(процессов и нитей), их взаимодействия и конфигурации и

и других факторов. С другой стороны, эти решения устанавливают

распределения объектов и классов по задачам. Потребность этого

дальнейшие ограничения на требования и на будущие проектные

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

решения нижнего уровня.

существенную степень параллелизма. В RationalUnifiedProcess 5.1

При использовании подхода «4+1» разработчики ПО начинают

представление процесса — это подмножество модели проекта.

формирование архитектуры с типичного набора видов,

5. Физический вид, который содержит описание различных

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

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

платформы, и расположение задач (из представления процесса)

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

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

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

Набор видов включает следующее.

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

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

1. Usecase вид, который содержит прецеденты и сценарии,

связывание с базой «4+1» ложится на разработчиков ПО.

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

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

или технические риски. Вид является подмножеством модели

системы в целом. Но архитектура интересуется только

прецедентов.

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

2. Логический вид, который содержит наиболее важные классы

Структура модели — организационные элементы, например,

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

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

уровней. Здесь содержится уже некоторая реализация

Существенные элементы — критические прецеденты, главные

прецедента. Это представление является подмножеством модели

классы, общие механизмы и так далее, а не все элементы,

проекта

представленные в модели. Несколько ключевых сценариев,

3. Вид с позиции разработки, который содержит краткий обзор

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

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

Сервис, чтобы зафиксировать модульность, необязательные

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

7.2Архитектурные решения SEI..

7.2Архитектурные решения SEI..

В Институте Программной Инженерии (SEI) *1+ разработан под$

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

конкретного ПО, кроме базовых «точек зрения», может

потребоватьсядополнительный набор видов. А значит,

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

необходимых ему типовых видов, в частности «boxandline»

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

для такойработы. Но главный акцент предлагается направить на

работу с видами с позиций качества (рис. 27). Значения

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

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

происходить «возврат» к предшествующим шагам архитектурного

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

для принятия новых архитектурных решений.Архитектурные

решения SEI согласованы со стандартом ИСО/

МЭК 9126. Особое внимание рекомендуется уделять

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

решений.

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

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

(EDA)

(EDA)

Это концепция управления корпоративной информационной

Этот архитектурный стиль может применяться при разработке и

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

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

Доступ к БД в EDA базируется на использовании

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

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

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

данных. Все запросы клиентов поступают на вход SQL шлюза,

(или агентов)

который транслирует SQL запросы в унифицированный формат и

и потребителей событий (или стоков). Стоки ответственны за

перенаправляет их к серверам БД. Взаимодействие с ними

ответную реакцию, как только событие возникло. Реакция может

возможно как через набор общих API, так и через ODBC интерфейс

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

(рис. 8). Использование SQL шлюза обеспечивает доступ к данным

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

в разнородных многозвенных системах, где множество

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

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

собственную реакцию на это событие. Создание приложений и

различного формата.

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

им быть сконструированными

способом, способствующим лучшей интерактивности, поскольку

системы, управляемые событиями, по структуре более

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

7.4Паттерн декоратор.

7.4Паттерн декоратор.

Назначение:

Участники:

Паттерн Decorator динамически добавляет новые обязанности

Interface (VisualComponent): определяет интерфейс для объектов,

объекту. Декораторы являются гибкой альтернативой

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

порождениюподклассов для расширения

обязанности.

функциональности.Рекурсивно декорирует основной

CoreFunctionality (TextView): определяет объект, на который

объект.Паттерн Decorator использует схему «обертываем подарок,

возлагаются дополнительные обязанности.

кладем его в коробку, обертываем коробку»

Decorator — Декоратор: хранит ссылку на объект Component и

определяет интерфейс, соответствующий интерфейсу Component.

OptionalOne, OptionalTwo... (BorderDecorator, ScrollDecorator) —

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

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

Преимущества:

большая гибкость, нежели у статического наследования.

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

выполнения программы.

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

на верхних уровнях иерархии.

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

необходимости.

Недостатки:

Декоратор и его компонент не идентичны.

Декоратор действует как прозрачное обрамление. Но

декорированный компонентвсе же не идентичен исходному.

множество мелких объектов

6.1Приведите определение понятия «вид».

6.1Приведите определение понятия «вид».

Понятие «Вид. View» является родственным для «Видов»,

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

черчении. Понятие «вид» в архитектурных описаниях ПО

соответствует «проекции ПО» на определенный интерес или

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

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

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

содержание, выраженное в моделях. Архитектурные виды АС

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

Виды в конкретной технологии разработки ПО могут быть

оформлены на определенном языке (например, на языке UML

и/или других языках описания архитектуры, Architecture

Description Language) и визуализированы в соответствии с

определенным набором правил: каждый вид соответствует

вполне определенной точке зрения (рис. 13); точка зрения

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

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

для их использования.

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

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

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

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

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

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

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

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

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

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

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

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

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

системы.

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

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

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

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

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

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

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

Пр:

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

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

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

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

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

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

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

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

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

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

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

(SOA)

(SOA)

Архитектура не привязана к какой-то определенной технологии.

Она может быть реализована с использованием широкого спектра

технологий, включая такие технологии как REST, RPC, DCOM,

CORBA или вебсервисы. SOA может быть реализована, используя

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

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

данными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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