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

1. Архитектура Программных
Систем
ДЗЮБА ДМИТРИЙ ВЛАДИМИРОВИЧ, СТАРШИЙ
ПРЕПОДАВАТЕЛЬ КАФ. 806
DDZUBA@YANDEX.RU

2. Зачем проектировать программную
систему?
1. Проектирование – дешевле чем полная реализация системы.
2. Проектирование дает возможность ответить на вопросы к системе:
◦ Из каких элементов система будет состоять.
◦ Как эти элементы будут взаимодействовать друг с другом.
◦ Что будет входить в состав элементов программы.
3. Проектирование заключается в создании модели программной системы.
Проектирование позволяет сэкономит время и деньги.

3. Ключевые модели
Вопросы неразрешимые на более низких
уровнях, решаются с помощью более
верхних уровней.
Например, что бы понять как реализовать
класс в программе, мы смотрим на
архитектуру. А для определения того какой
должна быть архитектура – смотрим в
требования и т.д.
Бизнес-модель предприятия
Методология разработки
Модель требований
Модель архитектуры
Спецификация системы
Модельдокументирования
Модельтестирования

4. Бизнес-модель предприятия
1. Культура производства
◦ Фабрика
◦ Проектная организация
◦ Предоставление услуг
2. Уровень зрелости
◦ Startup
◦ Зрелая компания
3. Домен
◦ Работа на корпоративных
заказчиков;
◦ Работа на конкретных
пользователей;
4. Способ производства
◦ In-house
◦ Outsource
◦ Интегратор
◦ Тиражируемый продукт

5. Архитектура
5
"Художник воплощает не зримые вещи -- данный камень или дерево, а их свойства, вещей. "
Е.В. Завадской “Эстетические проблемы живописи Старого Китая”
инварианты
Определение ANSI / IEEE Std 1471-2000
Основные принципы организации системы, воплощенной в его компонентах, их
взаимоотношениях друг с другом и окружающей средой и принципах, регулирующих дизайн и
эволюцию системы
Архитектура - описание структуры системы, состоящей из элементов ПО, описания видимых
свойств ПО и связей между ними. Архитектура строится на основе небольшого числа
приоритетных требований.

6. Основные свойства модели
1. Полнота
Модель документирует все элементы, необходимые для нахождения ответов на
вопросы к системе.
2. Непротиворечивость
Элементы модели не противоречат друг другу.
3. Проверяемость
Модель можно проверить, например проведя ее верификацию экспертами.

7. 7
Бизнес индикаторы архитектуры
Time to market
◦ Чем быстрее выпускается система, тем раньше вернуться инвестиции вложенные в её создание.
Соотношение стоимости и выгоды.
◦ Сложные решения дорого делать (большие затраты на содержание большой команды разработчиков).
Проектируемое время жизни продукта.
◦ Чем дольше время жизни продукта, тем больше мы сможем получать выгоды, модифицируя и развивая его.
Целевой рынок.
◦ ПО для массового рынка отличается от «заказного ПО». Это обусловлено наличием конкуренции.
План развития продукта
◦ Продукт выпускается только с базовой функциональностью, и часть функций может добавляться в следующих
релизах.
Интеграция с существующими системами
◦ Это позволит увеличить рынок сбыта ПО или добавит конкурентное преимущество.

8. Архитектура как компромисс
В общем случае лучшее техническое решение более дорогое по
сравнению с альтернативами.
Например, что бы написать и отладить алгоритм быстрой
сортировки Хоара потребуется больше времени, чем на написание
пузырьковой сортировки. Однако и работать быстра сортировка
будет быстрее.
Таким образом, принимая решения мы всегда должны четко
понимать:
 Что мы получаем
 Чем мы за это платим
Обоснование выбранного решения так же важно, как и его описание!

9. Процесс разработки архитектуры
Все практики разработки ПО – это шрупповые способы борьбы с
неопределенностью.
Неопределенность может быть связанна с чем угодно:
• Не известно как работает та или иная библиотека;
• Не известно можно ли реализовать требование;
• Не известно правильно ли созданы классы системы;
• …

10. Процесс создания архитектуры
1. Определение заинтересованных лиц проекта (иногда
сформировывается рабочая группа, которая периодически собирается
для принятия основных решений по проекту);
2. Определение бизнес цели:
◦ Уменьшение стоимости владения;
◦ Улучшение качества;
◦ Улучшение позиций на рынке;
3. Определяются ключевые функциональные требования к ПО и их
приоритеты.
4. Определяются ключевые атрибуты качества ПО и их приоритеты.
5. Разрабатывается высокоуровневая архитектура.
6. Высокоуровневая архитектура валидируется рабочей группой.
7. Разрабатывается детальная архитектура модулей.
8. Детальная архитектура валидируется архитекторами, разработчиками и
тест-аналитиками.
10

11. Проектная команда
1. Аналитик. Помогает понять требования к проекту. Помогает определить список основных вариантов
использования.
2. Руководитель проекта. Главная роль с точки зрения принятия ключевых для проекта решений. Может
влиять на изменение объема проекта и ресурсов проектной команды.
3. Архитектор. Должен быть один главный архитектор проекта, ответственный за ключевые решения. В
проекте может быть несколько "продуктовых" архитекторов, ответственных за реализацию различных
частей проекта.
4. Программист. Реализует код проекта. Основная опора архитектора в принятии сложных решений.
5. Дизайнер (user experience). Помогает спроектировать сценарии взаимодействия с пользователем.
Помогает создать прототипы системы на ранних стадиях проекта, определить основные функции
реализуемые в системе.
6. Тест-аналитик. Помогает верифицировать архитектуру, проверить её на полноту и
непротиворечивость.
7. Тех.поддержка/внедрение. Помогает сформулировать требования к быстродействию, надежности,
конфигурируемости и тестируемости.
11

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

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

14. Этапы создания архитектуры
1. Определение архитектурных целей
Четкие цели помогают сконцентрироваться на решении правильных проблем в дизайне
программного обеспечения.
2. Определение основных вариантов использования
Для проектирования архитектуры нужно выбрать небольшой набор основных сценариев, который
поможет сконцентрироваться на архитектуре.
3. Создания описания приложения
Определяем тип приложения, выбор стратегии развертывания, выбор архитектурного стиля и
технологий.
4. Определение основных вопросов
Определяем основные вопросы к архитектуре, базируясь на атрибутах качества.
5. Выбор решения – кандидата
Создается описание архитектуры или прототип, который тестируется на соответствие основным
вариантам использования, вопросам, определенным на предыдущем этапе и ограничениям.
14
Важно понимать, что процесс итеративный и раннее погружение в детали приносит столько же вреда,
сколько и пользы.

15. Определение архитектурных целей
Определяем цели данной итерации
Создание прототипа, тестирование потенциальных решений, проектирование какой-то фазы в
разработке приложения.
Определяем, кто будет читателем архитектуры
Архитектура может использоваться другими архитекторами, разработчиками, тестировщиками,
руководителями.
Определяем ограничения
Могут существовать технологические ограничения (например, выбор платформы или языка
программирования), организационные ограничение и т.д.
Содержания и время проведения фазы зависит от решаемых целей. Например:
◦ Создание полного дизайна приложения
◦ Создание прототипа
◦ Идентификация ключевых технических рисков
◦ Тестирование потенциальных решений
◦ Создание модели для понимания системы
151 2 3 4 5

16. Определение основных
вариантов использования
Вариант использования должен:
◦ Описывать важную не исследованную область или область с большими рисками
◦ Описывает архитектурно-важный сценарий
◦ Описывает использование атрибутов качества системы
◦ Описывает пересечение атрибутов качества системы
Архитектурно-важный сценарий
◦ Критический для бизнеса
Т.е. имеет важность как в достижении основных целей пользователей или спонсоров проекта.
◦ Имеет большое влияние на архитектуру
Сценарии которые задействованы как в реализации важной бизнес-функциональности, так и в
реализации атрибутов качества.
161 2 3 4 5

17. Создания описания приложения
Определяем архитектурный стиль (см. дальше)
Мобильное приложение, веб-приложение, толстый клиент и т.д.
Определяем ограничения уровня развертывания приложения
Типы аппаратных платформ, использование протоколов взаимодействия, поддержка QoS,
организационные процедуры связанные с установкой и сопровождением
Определяем архитектурные стили
Например SOA, клиент/сервер, архитектурные слои, domain-driven design и т.д.
Определение подходящих технологий
◦ Mobile Application
.NET Compact Framework, ASP.NET for Mobile,Silver Light for Mobile
◦ Rich Client Application
Windows Presentation Foundation, Windows Forms, XAML Browser Application
◦ Rich Internet Application
Silverlight, Silverlight + AJAX
◦ Web Application
ASP.NET Web Forms, AJAX, Silverlight controls, MVC2
◦ Service Application
WCF, ASP.NET Web Services
171 2 3 4 5

18. Определение основных вопросов
Атрибуты качества
◦ Производительность
◦ Надежность
◦ Безопасность
◦ Тестируемость
◦ Модифицируемость
◦ Usability
Инфраструктурные
варианты использования
◦ Аутентификация и авторизация
◦ Кэширование
◦ Коммуникации
◦ Управление конфигурациями
◦ Обработка исключительных ситуаций
◦ Логирование и диагностика
◦ Валидация данных
181 2 3 4 5
Определяем основные области в которых сконцентрированы
риски для разрабатываемой архитектуры. В основном они
связаны с новыми технологиями и критическими бизнес-
требованиями.

19. Пример проблемных областей для безопасности
191 2 3 4 5

20. Выбор решения – кандидата
В конце итерации мы будем иметь архитектуру разработанную
на предыдущей итерации и кандидат, разработанный на этой.
Для тестирования кандидата, нужно найти ответы на
следующие вопросы:
◦ Вносит ли новая архитектура новые риски?
◦ Новая архитектура уничтожает больше рисков чем прошлая?
◦ Новая архитектура покрывает больше требований чем
предыдущая?
◦ Новая архитектура поддерживает архитектурно-важные варианты
использования?
◦ Новая архитектура решает поставленные задачи по достижению
атрибутов качества системы?
◦ Новая архитектура реализовывает дополнительные
инфраструктурные варианты использования?
201 2 3 4 5

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

22. Основные вопросы
◦ Данные
◦ Схема данных
◦ Таблицы или массивы?
◦ Специальные структуры данных?
◦ Данные связанны или независимы?
◦ Доступ к данным
◦ Прямой доступ по имени или адресу?
◦ Косвенный доступ через посредника?
◦ Способы управления
◦ Что запускает задачу на выполнение?
◦ Что останавливает выполнение задачи?
◦ Как определяется последовательность действий в
задаче?
◦ Как будут определяться приоритеты между
задачами?
◦ Как управлять доступом к общим для разных задач
данным?
◦ Структуры
◦ Как организовывать программный код?
◦ Функции?
◦ Классы?
◦ Компоненты?
◦ Как осуществить размещение кода на
компьютере?
◦ Время
◦ Будет использоваться абсолютное время?
◦ Будет использоваться относительное время?
22

23. 23
Иерархические программы
◦ Характерно
◦ Однопоточное (single thread) управление
◦ Данные могут быть локальными, глобальными или на где-то вовне
◦ Статически прописывается вызов процедур
◦ Работает как набор независимых программ
◦ Данные синхронизуются по запуску программы
◦ Когда применять?
◦ Хорошо для небольших высокопроизводительных программ.

24. Пример документирования
Блок-схема сортировки
«Пузырьком»

25. 25
Объектно-ориентированные
программы
◦ Характерно
◦ Однопоточное или многопоточное управление;
◦ Данные инкапсулированы или внешние;
◦ Иерархические вызовы динамически связываемых процедур;
◦ Наследование;
◦ Когда применять
◦ Сложные программы, которые нужно часто модифицировать;

26. Пример документирования
Различные UML диаграммы:
- диаграммы классов
- sequence
- activity
…
class Logical Design
Entity Meeting
- Color: int
- Date_from: DATE
- Date_to: DATE
- Description: String
- Title: String
Value Object Location
- Latitude: double
- Longitude: double
Entity User
- Login: String
- Password: String
Value Object
Configuration
- URL
Entity Vehicle
- Power Reserve: int
- Speed: int
+ isLocationReachableInTime(): boolean
Entity Own Legs Entity Taxi
Calendar
+ FindByDate(): Entity Meeting
+ FindByPlace(): Entity Meeting
1
take place
1
is in
1
have
0..*
uses
0..*
1
1 0..*

27. 27
DSL Engine
◦ Характерно
◦ Программа которая обрабатывает управляющие данные в терминах
предметной области;
◦ Управляющая программа производит разбор входных данных и
выполняет функцию в соответствии с описанием входных данных;
◦ Когда применять
◦ Удобно для решения отраслевых задач связанных с вычислением и
планированием.
◦ Пример
◦ Программа для создания расписаний;

28. Пример
Enterprise Service Bus с поддержкой BPEL
<process name="mathProcess" targetNamespace="http://example.com/ws-bp/math" xmlns="http://docs.oasis-
open.org/wsbpel/2.0/process/executable" xmlns:math="http://manufacturing.org/wsdl/math">
<partnerLinks>
<partnerLink name="Math" partnerLinkType="math:exampleMath" myRole="mathService" />
</partnerLinks>
<variables>
<variable name="numIn" messageType="math:unsignedInt"/>
<variable name="numOut" messageType="math:unsignedInt"/>
<variable name="num" type="xsd:unsignedInt"/>
</variables>
<sequence>
<receive partnerLink="Math" portType="math:mathPort" operation="secondDegree" variable="numIn" createInstance="yes"/>
<assign name="LoopCounterIncrement">
<copy> <from>$numIn.request</from> <to variable="num"/> </copy>
<copy> <from>$num * $num</from> <to variable="numOut" part="response"/> </copy>
</assign>
<reply operation="secondDegree" partnerLink="Math" portType="math:mathPort" variable="numOut"/>
</sequence>
</process>

29. 29
Сервисы, с разделением на слои абстракции
◦ Характерно
◦ Каждый уровень предоставляет свой сервис;
◦ Каждый уровень скрывает нижележащие сервисы;
◦ Каждый уровень имеет хорошо определенные интерфейсы;
◦ Данные синхронизуются с помощью вызовов, идущих между
слоями;
◦ Когда применять
◦ В сложных разнородных системах

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

31. Событийно-ориентированная архитектура
◦ Характерно
◦ Очереди событий от внешних источников;
◦ Определение следующего выполняемого действия по состоянию программы;
◦ Переходы состояний в программе;
◦ Вычисления производятся при обработке запросов;
◦ Результат вычислений посылается через очередь сообщений;
◦ Когда применять
◦ В системах, которые зависят от не детерминированных внешних событий.
◦ В сложных многопоточных приложениях
31

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

33. 33
Транзакции
◦ Характерно
◦ Постоянная поддержка целостной структуры данных;
◦ Работа с запросами на получение данных и изменение состояния данных;
◦ Когда применять
◦ При работе с данными сложной структуры;
◦ При параллельной работе с данными в разных потоках;
◦ Пример
◦ Различные системы online платежей

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

35. 35
Транспорт
◦ Характерно
◦ Передача данных от одной программы другой;
◦ Трансформирование данных;
◦ Передача данных по запрограммированным путям;
◦ Данные определяют алгоритмы работы с ними;
◦ Когда применять
◦ В системах сбора данных;
◦ В системах передачи данных;

36. Пример
При описании таких систем
делают упор на описании
формата сообщений, путей
передачи сообщений, правил
обработки сообщений.

37. Классификация типов взаимодействия
модулей
37

38. Классификация по структуре
взаимодействия
1. Точка – точка
2. Звезда

39. 39
Взаимодействие точка-точка (стихийная интеграция
систем)
Каждый элемент соединяется с
нужным ему элементом напрямую.
Плюсы
◦ Быстро создавать;
Минусы
◦ Тяжело поддерживать (вносить
изменения, повторно
использовать интерфейсы);

40. 40
Взаимодействие "звезда"
(интегрирующая среда)
◦ Данный способ взаимодействия характеризуется
наличием центрального компонента (интегрирующей
среды), управляющего взаимодействием подсистем в
рамках информационной системы в целом.
◦ Интегрирующая среда имеет универсальный интерфейс
для доступа активных систем.
Плюсы
◦ Легко поддерживать (есть возможность многократного
использования интерфейсов);
Минусы
◦ Тяжело создавать (дополнительный элемент);
◦ Может работать медленнее;

41. Классификация по типу обмена данными
1. Файловый обмен (точка-точка). Системы
экспортируют общие данные в формате
пригодном для импорта в другие системы.
2. Общая база данных (звезда)
3. Удаленный вызов процедур (точка-точка).
4. Обмен сообщениями (звезда/точка-точка)
41

42. 42
Классификация по методу интеграции
1. Интеграция систем по данным (data-centric). Концепция интеграции в этом подходе состоит в
том, что приложения объединяются в систему вокруг интегрированных данных под
управлением СУБД. Интегрирующей средой является промышленная СУБД (как правило,
реляционная) со стандартным интерфейсом доступа к данным (обычно это доступ на SQL). Все
функции прикладной обработки размещаются в клиентских программах.
2. Функционально-центрический (function-centric) подход. При функционально-центрическом
подходе основным системообразующим фактором являются сервисы - общеупотребительные
прикладные и системные функции коллективного доступа, реализованные в виде серверных
программ со стандартным API.
3. Объектно-центрический (object-centric). Объектно-центрический подход, основанный на
стандартах объектного взаимодействия CORBA, COM/DCOM, .NET и пр. и является композицией
типов объединения систем по данным и обьектно - центрического.
4. Интеграция на основе единой понятийной модели предметной области (concept-centric).
Разрабатывается общесистемный язык взаимодействия, основанный на бизнес объектах и
бизнес функциях. Взаимодействие основано на передаче событий.

43. 43
Checklist
 Архитектура должна быть продуктом группы архитекторов с явно выраженным лидером. Т.е. за
разработку архитектуры должен отвечать один архитектор.
 Архитектор должен иметь функциональные требования к архитектуре и список приоритезированных
атрибутов качества архитектуры. Если его (списка) нет, то его нужно создать перед началом работ.
 Атрибуты качества архитектуры должны иметь измеримые характеристики (максимальная пропускная
способность и т.д.) - это основной элемент архитектуры. Если цифр нет – их нужно высчитать.
 Архитектура должна быть хорошо документирована в нотации понятной участникам проекта. Т.е.
термины и детализация выбираются исходя из квалификации проектной команды.
 В процесс разработки архитектуры должны быть включены основные заинтересованные лица проекта
(представитель заказчика, руководитель , аналитик, программист, тест-аналитик)
 Архитектура должна разрабатываться инкрементально, начиная с базовых модулей и путей
взаимодействия между ними с минимальной функциональностью.

44. Checklist
 Архитектура должна состоять из хорошо определенных модулей, с определенными принципами
реализуемой в модули функциональности.
 Каждый модуль должен иметь четко определенный интерфейс, пряча детали реализации от других
модулей.
 Атрибуты качества должны достигаться с помощью четко определенной тактики.
 Модули которые производят данные должны быть разделены от модулей, которые потребляют данные.
(позволяет инкрементально наращивать модули)
 Для параллельных систем должно быть четкое описание процессов и их взаимодействия.
 Процессы должны быть спроектированы так, что инсталяция процесса на конкретную машину должен
легко меняться.
 Архитектура должны состоять из небольшого набора понятных паттернов.
 Архитектура должна иметь четкие стратегии по достижению бизнес целей, которые должны быть
прописаны для всех команд разработки.
44

45. Спасибо!