Проектирование программных систем. Занятие 4

МАИ, каф 806, ППС1

Архитектура ПО. Общие понятия

"Художник воплощает не зримые вещи -- данный камень или дерево, а их свойства, инварианты вещей. " Е.В. Завадской “Эстетические проблемы живописи Старого Китая”

Определение ANSI / IEEE Std 1471-2000

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

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

Архитектура - основной артефакт для разработки.

Архитектура - строится на основе небольшого числа приоритетных бизнес требований.


Архитектура ПО. Бизнес-показатели влияющие на архитектуру.

Time to market Чем быстрее выпускается система, тем раньше вернуться инвестиции вложенные в её

создание.

Соотношение стоимости и выгоды. Сложные решения дорого делать (большие затраты на содержание большой команды

разработчиков).

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

модифицируя и развивая его.

Целевой рынок. ПО для массового рынка отличается от «заказного ПО». Это обусловлено наличием

конкуренции.

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

добавляться в следующих релизах.

Интеграция с существующими системами Это позволит увеличить рынок сбыта ПО или добавит конкурентное преимущество.


Архитектура ПО. Проектная команда.

Квалификация и количество людей, участвующих в проекте очень сильно влияют на архитектуру. Например, тех. Поддержка заказчика может уметь администрировать только Oracle и быть незнакомой с SQL server. Или программисты, работающие в компании могут знать только Java и не знать C#.

Роли с точки зрения влияния на архитектуру

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

Руководитель проекта. Главная роль с точки зрения принятия ключевых для проекта решений. Может влиять на изменение объема проекта и ресурсов проектной команды.

Архитектор. Должен быть один главный архитектор проекта, ответственный за ключевые решения. В проекте может быть несколько "продуктовых" архитекторов, ответственных за реализацию различных частей проекта.

Программист. Реализует код проекта. Основная опора архитектора в принятии сложных решений.

Дизайнер (user experience). Помогает спроектировать сценарии взаимодействия с пользователем. Помогает создать прототипы системы на ранних стадиях проекта, определить основные функции реализуемые в системе.

Тест-аналитик. Помогает верифицировать архитектуру, проверить её на полноту и непротиворечивость.

Тех.поддержка/внедрение. Помогает сформулировать требования к быстродействию, надежности, конфигурируемости и тестируемости.


Архитектура ПО. Совместимость ролей.

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


Архитектура ПО. Основные принципы процесса создания.

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

Архитектор должен иметь функциональные требования к архитектуре и список приоритезированных атрибутов качества архитектуры. Если его (списка) нет, то его нужно создать перед началом работ.

Атрибуты качества архитектуры должны иметь измеримые характеристики (максимальная пропускная способность и т.д.) - это основной элемент архитектуры. Если цифр нет – их нужно высчитать.

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

В процесс разработки архитектуры должны быть включены основные заинтересованные лица проекта (представитель заказчика, руководитель , аналитик, программист, тест-аналитик)

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


Checklist

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

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

Атрибуты качества должны достигаться с помощью четко определенной тактики.

Модули которые производят данные должны быть разделены от модулей, которые потребляют данные. (позволяет инкрементально наращивать модули)

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

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

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

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


Архитектура ПО. Основные этапы создания.

Определение заинтересованных лиц проекта (иногда сформировывается рабочая группа, которая периодически собирается для принятия основных решений по проекту);

Определение бизнес цели:

Уменьшение стоимости владения;

Улучшение качества;

Улучшение позиций на рынке;

Определяются ключевые функциональные требования

к ПО и их приоритеты.

Определяются ключевые атрибуты качества ПО и их приоритеты.

Разрабатывается высокоуровневая архитектура

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

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

Детальная архитектура валидируется архитекторами, разработчиками и тест-аналитиками.

МАИ, каф 806, ППС

Итерационный подход к разработке архитектуры

Входными данными для архитектуры обычно являются варианты использования, функциональные требования, нефункциональные требования (производительность, безопасность, надежность и т.д.), целевое ИТ окружение системы и другие ограничения.

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

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

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

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

8


Этапы создания архитектуры [1/2]

Определение архитектурных целей

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

Создания описания приложения

Определение основных вопросов

Выбор решения - кандидата

9


Этапы создания архитектуры [2/2]

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

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

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

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

Выбор решения – кандидатаСоздается описание архитектуры или прототип, который тестируется на соответствие основным вариантам использования, вопросам, определенным на предыдущем этапе и ограничениям.

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

10


Определение архитектурных целейитерационный процесс построения архитектуры [1/5]

Определяем цели данной итерацииСоздание прототипа, тестирование потенциальных решений, проектирование какой-то фазы в разработке приложения.

Определяем, кто будет читателем архитектурыАрхитектура может использоваться другими архитекторами, разработчиками, тестировщиками, руководителями.

Определяем ограниченияМогут существовать технологические ограничения (например, выбор платформы или языка программирования), организационные ограничение и т.д.

Содержания и время проведения фазы зависит от решаемых целей. Например:

Создание полного дизайна приложения

Создание прототипа

Идентификация ключевых технических рисков

Тестирование потенциальных решений

Создание модели для понимания системы

11


Определение основных вариантов использованияитерационный процесс построения архитектуры [2/5]

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

Описывать важную не исследованную область или область с большими рисками

Описывает архитектурно-важный сценарий

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

Описывает пересечение атрибутов качества системы

Архитектурно-важный сценарий

Критический для бизнесаТ.е. имеет важность как в достижении основных целей пользователей или спонсоров проекта.

Имеет большое влияние на архитектуруСценарии которые задействованы как в реализации важной бизнес-функциональности, так и в реализации атрибутов качества.

12


Создания описания приложенияитерационный процесс построения архитектуры [3/5]

Определяем тип приложенияМобильное приложение, веб-приложение, толстый клиент и т.д.

Определяем ограничения уровня развертывания приложенияТипы аппаратных платформ, использование протоколов взаимодействия, поддержка QoS, организационные процедуры связанные с установкой и сопровождением

Определяем архитектурные стилиНапример SOA, клиент/сервер, архитектурные слои, domain-driven design и т.д.

Определение подходящих технологий Mobile Application

.NET Compact Framework, ASP.NET for Mobile,Silver Light for Mobile

Rich Client ApplicationWindows Presentation Foundation, Windows Forms, XAML Browser Application

Rich Internet ApplicationSilverlight, Silverlight + AJAX

Web ApplicationASP.NET Web Forms, AJAX, Silverlight controls, MVC2

Service ApplicationWCF, ASP.NET Web Services

13


Определение основных вопросовитерационный процесс построения архитектуры [4/5]

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

Атрибуты качества Производительность

Надежность

Безопасность

Тестируемость

Модифицируемость

Usability

Инфраструктурные варианты использования Аутентификация и авторизация

Кэширование

Коммуникации

Управление конфигурациями

Обработка исключительных ситуаций

Логирование и диагностика

Валидация данных

14


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

15


Выбор решения – кандидатаитерационный процесс построения архитектуры [5/5]

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

Вносит ли новая архитектура новые риски?

Новая архитектура уничтожает больше рисков чем прошлая?

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

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

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

Новая архитектура реализовывает дополнительные инфраструктурные варианты использования?

16


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

17


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

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

• Схема данных– Таблицы или массивы?– Специальные структуры данных?– Данные связанны или независимы?

• Доступ к данным– Прямой доступ по имени или адресу?– Косвенный доступ через посредника?

Управления• Что запускает задачу на выполнение?• Что останавливает выполнение задачи?• Как определяется последовательность действий в

задаче?• Как будут определяться приоритеты между

задачами?• Как управлять доступом к общим для разных задач

данным?

Структур• Как организовывать программный код?

– Функции?– Классы?– Компоненты?

• Как осуществить размещение кода на компьютере?

Время• Будет использоваться абсолютное время?• Будет использоваться относительное время?


Детальная архитектура. Стили архитектуры.

Иерархические программы

Характерно

• Однопоточное (single thread) управление

• Данные могут быть локальными, глобальными или на где-то вовне

• Статически прописывается вызов процедур

• Работает как набор независимых программ

• Данные синхронизуются по запуску программы

Когда применять?

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



Объектно-ориентированные программы


• Однопоточное (single thread) управление;

• Данные инкапсулированны или внешнии;

• Иерархические вызовы динамически связываемых процедур;

• Наследование;

Когда применять

• Сложные программы, которые нужно часто модифицировать;



DSL Engine


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

• Управляющая программа производит разбор входных данных и выполняет функцию в соответствии с описанием входных данных;


• Удобно для решения отраслевых задач связанных с вычислением и планированием.

Пример

• Программа для создания расписаний;



Сервисы, с разделением на слои абстракции


• Каждый уровень предоставляет свой сервис

• Каждый уровень скрывает нижележащие сервисы

• Каждый уровень имеет хорошо определенные интерфейсы

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


• В сложных гетерогенных системах

Пример

• Модель OSI/ISO

• Стандартная трехуровневая архитектура



Событийно-ориентированная архитектура


• Очереди событий от внешних источников

• Определение следующего выполняемого действия по состоянию программы

• Переходы состояний в программе

• Вычисления производятся при обработке запросов

• Результат вычислений посылается через очередь сообщений


• В системах, которые зависят от не детерминированных внешних событий.

• В сложных многопоточных приложениях

Пример

• Пользовательский интерфейс

• Распределенные вычисления



Транзакции


• Постоянная поддержка целостной структуры данных;

• Работа с запросами на получение данных и изменение состояния данных;


• При работе с данными сложной структуры;

• При параллельной работе с данными в разных потоках;

Пример

• Различные системы online платежей



Транспорт


• Передача данных от одной программы другой

• Трансформирование данных

• Передача данных по запрограммированным путям

• Данные определяют алгоритмы работы с ними


• В системах сбора данных

• В системах offline-обработки данных


Организация взаимодействия модулей

26


Архитектура ПО. Организация взаимодействия модулей. Структурные паттерны.

Взаимодействие точка-точка (стихийная интеграция систем)

Быстро создавать

Тяжело поддерживать


Архитектура ПО. Организация взаимодействия модулей. Структурные паттерны.

Взаимодействие "звезда" (интегрирующая среда)

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

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

Интегрирующая среда может использовать интерфейсы пассивных систем.


Архитектура ПО. Организация взаимодействия модулей.

Паттерны по типу обмена данными

Файловый обмен (точка-точка)

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

Общая база данных (звезда)

Удаленный вызов процедур (точка-точка).

Обмен сообщениями (звезда/точка-точка)


Архитектура ПО. Организация взаимодействия модулей.

Паттерны по методу интеграции

Интеграция систем по данным (data-centric). Концепция интеграции в этом подходе состоит в том, что приложения объединяются в систему вокруг интегрированных данных под управлением СУБД. Интегрирующей средой является промышленная СУБД (как правило, реляционная) со стандартным интерфейсом доступа к данным (обычно это доступ на SQL). Все функции прикладной обработки размещаются в клиентских программах.

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

Объектно-центрический (object-centric). Объектно-центрический подход, основанный на стандартах объектного взаимодействия CORBA, COM/DCOM, .NET и пр. и является композицией типов объединения систем по данным и обьектно - центрического.

Интеграция на основе единой понятийной модели предметной области (concept-centric). Разрабатывается общесистемный язык взаимодействия, основанный на бизнес объектах и бизнес функциях. Взаимодействие основано на передаче событий.

Education

Проектирование программных систем. Занятие 4