Открытый семинар для студентов в компании CUSTIS (31 октября 2013 года). Лектор: Михаил Заборов, архитектор, руководитель стратегических проектов. Аннотация: Что такое архитектура применительно к IT? Спросите у десяти экспертов — и получите десять разных ответов. При работе над реальными проектами очень важно, чтобы у команды было единое понимание, что такое архитектура, как она устроена, с чем взаимодействует, чем отличается от требований, технологии и других артефактов, какие функции она должна выполнять и, наконец, что такое качественная архитектура. На семинаре мы поделимся своим практически-философским взглядом на проблему. Видеозапись семинара: ▪ https://vimeo.com/78616983 — философская часть; ▪ https://vimeo.com/78628966 — практическая часть.

1. Архитектура в IT:
философия и практика
Михаил Заборов
Архитектор, руководитель стратегических проектов
31 октября 2013 года

2. занимается разработкой
больших (40–100 человеко-лет)
корпоративных
информационных систем
на заказ
2/110

3. Обо мне


>10 лет в компании

Работаю в одной из групп
развития бизнеса
Участвовал
в существенной части
проектов компании
в качестве руководителя
и архитектора
3/110

4. Философский блок
4/110

5. ?
Понятно ли вам,
что такое архитектура?
5/110

6. Архитектура как Buzzword

Разговоры с упоминанием архитектуры ведутся
постоянно и повсеместно


Каждый понимает под этим словом что-то свое
Известно несколько сотен формальных
определений архитектуры
 Многие формулировки носят характер скорее
эмоциональных высказываний, чем определений
 Многие определения существенно неполны
(описывают только один из аспектов)

Существующие стандарты описывают, что такое
архитектура, слишком абстрактно и интуитивно
6/110

7. !
Когда у нас слишком абстрактное
и интуитивное представление
об объекте, мы не можем с ним
реально ничего сделать.
А если этот объект критически
влияет на успех проекта, то мы
становимся заложниками случая
и стечения обстоятельств.
Мы не можем существенно влиять
на результат.
7/110

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

9. Термин заимствован из строительства
Термин «архитектура»
применительно к IT впервые
появился в 1960-х, однако
начал широко использоваться
только в начале 1990-х
9/110

10. Замечено, что системы с хорошей
архитектурой значительно чаще
достигают поставленных целей,
меньше стоят и дольше «живут»
10/110

11. Попытка сформулировать
понятие «архитектура» более строго





В какой системе находится
С чем взаимодействует
Как устроена внутри
Какие функции выполняет
Каковы последствия от ее отсутствия
11/110

12. Система,
в которой находится архитектура
i
Большая часть терминов
заимствована из стандарта
ISO/IEC/IEEE 42010
12/110

13. Архитектура приложения
и архитектура предприятия
(Enterprise Architecture)




TOGAF
Захман
FEAF
Over 9000
 ISO/IEC/IEEE 42010
 IEEE 1471:2000
13/110

14. Stakeholder, который хочет что-то
сделать с изделием
14/110

15. Stakeholder’ов много
и у них много разных интересов
15/110

16. Перейдем к ИТ
16/110

17. Система производства приложения
(простой вариант)
Выпуск
релизов
17/110

18. Риски
18/110

19. Система производства приложения
(более сложный вариант)
Выпуск
релизов

20. Система представлений
о внутреннем устройстве приложения

Состоит из решений1
о внутреннем устройстве (конструкции)
приложения

Решения находятся в отношении
зависимости
1Мы
используем термин утверждение
20/110

21. Решение B зависит от решения A
A
Базовое
B
Зависимое (детализирующее)

Изменение A неизбежно влечет за собой
пересмотр B

Бывают ситуации, когда не очевидно,
какое решение базовое
21/110

22. Зависимости между решениями
A
B
C
Решения выстраиваются
в цепочки
A
Решение может зависеть
от нескольких решений
B
C
D
22/110

23. Граф решений
Сложнее (дороже) пересматривать
Более
базовые
Более
детальные
Проще (дешевле) пересматривать
23/110

24. Слои графа решений
Граф решений
24/110

25. Grady Booch, Martin Fowler:
Архитектура – это все решения, которые,
сделав однажды, затем трудно изменить.
25/110

26. Вывод
У приложения нет архитектуры;
она есть у людей, которые его
модифицируют
26/110

27. Соответствие
архитектуры и продукта
27/110

28. !
Вывод
Что входит в архитектуру, а что нет, –
не всегда следствие решения
архитектора. Архитектор скорее
выявляет архитектурные решения,
чем принимает их.
Одна из главных задач архитектора –
чувствовать последствия решений
(что будет действительно важным,
а что – нет).
28/110

29. Решения удобно формировать
группой (в виде моделей)
29/110

30. При этом модель может фиксировать
решения разных уровней значимости
30/110

31. Одна из самых важных моделей –
схема функциональных блоков
31/110

32. Software Engineering Institute:
Архитектура – это структура вычислительной
системы, которая включает программные
компоненты, внешние свойства этих
компонентов, а также отношения между ними.
32/110

33. Архитектура – сложный объект
View
Аспекты
Viewpoint
Слои
33/110

34. Связь технологии и архитектуры

Деятельность архитектора направлена
на изготовление конкретного (одного)
изделия. Архитектура описывает именно его

Деятельность технолога направлена
на повышение эффективности и качества
процесса изготовления изделия (обычно
для массовых операций)

Технология предоставляет архитектору
кирпичи (материал), из которого архитектор
может делать все более сложную
архитектуру
34/110

35. Возможность
не принимать решение повторно
Решения,
определяемые
технологией
35/110

36. Функции архитектуры
в процессе производства
Изменение системы
производства
Запрос
на изменение
Δ изменения
продукта
36/110

37. Функции архитектуры
1. Используется как модель приложения
2. Нормирует и технологизирует работы
по проектированию
3. Минимизирует риски
4. Используется как контракт в части SCOPE
37/110

38. 1. Архитектура как модель приложения
Модель объекта – это что-то,
что позволяет отвечать
на вопросы об объекте
38/110

39. Декомпозиция работ по изменению



Разделение работы на независимые части
Запуск параллельных потоков работ
Интеграция результатов работ
Подзадача 1
Исходная
задача
Подзадача 2
Подзадача 3
Результат
39/110

40. Анализ зависимостей (что будет, если)
Incredible Machine

41. Оценка масштаба (класса)
предлагаемых изменений

Просто или сложно?
http://domvsegda.ru/
41/110

42. 2. Нормирование и технологизация
работ по проектированию
42/110

43. Локализация места модификации
приложения
43/110

44. Минимизация пересмотра принятых
ранее решений
A’
Приложения с хорошей
архитектурой меньше
подвержены постоянным
переделкам
44/110

45. Определение с сайта SEI (какой-то индус ):
A good architecture is that which is totally secured,
which can accommodate future changes without
affecting the software as a whole, and which has
no redundant functionalities.
45/110

46. Минимизация пересмотра принятых
ранее решений

Возможность посмотреть вперед и представить,
как будет выглядеть изделие в целом
Continuous Refactoring
46/110

47. Согласование действий проектировщиков

Архитектурные решения выполняют функцию
соглашения между всеми участниками процесса

Минимизация объема
проектирования для типовых задач
47/110

48. Питер Хрущка:
Архитектура – способ координировать умы.
48/110

49. 3. Минимизация рисков
49/110

50. Описание работоспособной
конструкции в целом
Нарисованная архитектура –
гарантия того, что это
вообще будет построено
50/110

51. Андрей Вербицкий:
Хорошая архитектура – это удачный
компромисс между желаниями
и ограничениями.
51/110

52. Определение ключевых элементов
конструкции, обеспечивающих
качество продукта
Несущие стены
52/110

53. Анатолий Левенчук:
Архитектура – это то, каким образом
конструкция поддерживает требуемую
функцию/назначение системы.
53/110

54. 4. Архитектура как контракт
в части SCOPE
54/110

55. Фиксация назначения и границ продукта
А также задач, которые
в принципе могут этим
продуктом решаться
55/110

56. Определение реальных
потребительских свойств приложения
56/110

57. В результате мы получили
модель, которая позволяет
вести более содержательные
разговоры об архитектуре
Например, задавать вопросы по конкретным
функциям и диагностировать проблемы
более точно
«С архитектурой все плохо»
57/110

58. !
Качество архитектуры определяется
ее способностью выполнять
перечисленные функции.
58/110

59. Оценка качества архитектуры

Не отражает актуальное внутреннее устройство
приложения
Не работает как модель приложения

Структура модулей – «поперек» возникающих задач
Не помогает декомпозировать большие задачи

Внесение изменений приводит к непредсказуемым
последствиям
Не помогает локализовать изменения

Необходимые изменения в системе требуют
постоянного пересмотра базовых решений
Не обеспечивает минимизацию пересмотра решений

«Разношерстные» решения типовых задач
Не выполняет функцию координации
59/110

60. Качество процесса управления
архитектурой

Случайные решения становятся базовыми
Решение приняли походя, а от него теперь многое зависит.
Нет осознанного управления архитектурой

Проектировщики нижнего уровня
не руководствуются базовыми решениями
Не выполняется функция нормирования. Теряется
целостное представление об устройстве приложения

Базовые решения не пересматриваются вовремя
Воспринимаются как жесткие ограничения. Несмотря
на очевидные проблемы при принятии решений на более
детальном уровне
60/110

61. Методологический блок
61/110

62. Стандарты по архитектуре
(предприятия)

Таксономия и образцы моделей
 Zachman Framework
 FEAF
 TEAF

Методы разработки архитектуры
 TOGAF (ADM)
 FEAF
 EAP
62/110

63. Питер Хрущка
arc42.org
63/110

64. Качество ПО
Заказчик обычно не готов
платить за качество;
он просто ожидает его
64/110

65. Критерии качества (Quality Goals) –
часть замысла







Безопасность
Расширяемость
Простота использования
Надежность (Robustness)
Настраиваемость
Производительность
Гибкость
65/110

66. Приоритизация критериев качества

Нужно выбрать небольшое (3–5) число
ключевых критериев

Приоритизировать их (определить, что в случае
конфликта целей мы приносим в жертву)
1
Простота использования
2
Безопасность
3
Расширяемость
66/110

67. Критерии качества
системы «Розничный магазин»
Приоритет
Цель
Описание
Магазин должен функционировать во что бы то
ни стало
1
Устойчивость
к сбоям
2
Магазины находятся в отдаленных точках;
нет возможности индивидуально настраивать
Настраиваемость
и сопровождаемость каждый. Нужно уметь удаленно и просто
настраивать систему под особенности магазина
3
Простота
использования
Для рядовых сотрудников магазина
4
Скорость реакции
Интерфейсы должны реагировать достаточно
быстро, чтобы не раздражать покупателей
5
Расширяемость
Мы должны успевать вносить изменения,
которые просит Заказчик
67/110

68. Критерии качества
Функциональность
 Пригодность
 Точность
 Способность
к взаимодействию
 Защищенность
 Расширяемость
 Соответствие
стандартам и правилам
Надежность
 Стабильность
 Отказоустойчивость
 Восстанавливаемость
 Соответствие
стандартам и правилам
DIN/ISO 9126 (++)
Потребительские
свойства
 Понятность
 Простота
использования
 Обучаемость
 Пригодность
 Привлекательность
 Соответствие
стандартам и правилам
Эффективность
 Времяемкость
 Производительность
 Ресурсоемкость
 Соответствие
стандартам и
правилам
Внешнее качество
Сопровождаемость
 Изменяемость
 Устойчивость
 Тестируемость
 Открытость
 Соответствие
стандартам и
правилам
Переносимость
 Адаптируемость
 Встраиваемость
 Cосуществование
 Заменяемость
 Соответствие
стандартам и
правилам
Внутреннее качество
Переносимость
 Эффективность
 Продуктивность (результативность)
 Производительность
 Эксплуатационная безопасность
 Удовлетворенность заказчика
Эксплуатационные качества
68/110

69. Требования к качеству
Функциональные
требования
Требования
к качеству
Нефункциональные
требования
Ограничения
69/110

70. Дерево качества
A
B
При любом сбое системы нужно иметь
возможность продать товар
Товар можно продать, даже если его нет в остатках
Устойчивость к сбоям
Качество
системы
«Розничный
магазин»
Настраиваемость
и сопровождаемость
Простота использования
Скорость реакции
Возможна временная недоступность каналов связи
Цены все равно должны обновляться из офиса
A
C
Настройка новой кассы должна происходить
автоматически
Большая часть настроек должна производится
централизовано из офиса
Новый сотрудник должен выполнять большую часть функций
через 2-3 дня работы в паре с опытным сотрудником
Время обслуживания покупателя не должно увеличиваться
из-за взаимодействия с системой
Получение заказов из интернет-магазинов
Расширяемость
Подключение новых типов оборудования
Интеграция с системой безопасности
70/110

71. Состав архитектуры
Структура
Аспект
функциональных
блоков
Аспект
внедрения
и инсталляции
(Building Block View)
(Deployment View)
Аспект
исполнения
(Runtime View)
Архитектурные
концепции
Сохраняемость, пользовательские
интерфейсы, эргономика,
управление транзакциями,
управление сессиями, безопасность,
сетевое взаимодействие,
распространение, проверка,
обработка исключений и ошибок,
администрирование и
сопровождение, логирование,
отчетность, конфигурирование,
параллелизация и многопоточность ,
интернационализация, миграция,
тестируемость, масштабируемость,
кластеризация, высокая доступность,
катастрофоустойчивость.
71/110

72. Структура
Функциональные блоки
Внедрение и инсталляция
Статическая структура функциональных
блоков и их зависимости
Инфраструктура ПО
Статика
Исполнение
Динамика


Взаимодействие блоков
_
_
_
Структура является «абстракцией кода»
Должна отражать его реальное устройство
и состояние
72/110

73. Аспект функциональных блоков
(Building Block View)
Этот аспект –
основной,
остальные –
вспомогательные
(позволяют посмотреть
на систему под другим
углом).
73/110

74. Функциональный блок

Building Blocks (функциональные блоки) –
это блоки, из которых строится программный код.
В разных языках и средах программирования
это могут быть:
 function, procedure, subroutine, method, array, record
 class, unit, table
 module, package, library, component, schema
 layer, framework, schema
 application, subsystem, database Могут быть и другие
специфические блоки
74/110

75. Иерархия блоков
Контекстная диаграмма
Система
Внешние
приложения
Детализация
Система как белый ящик
B
A
Детализация
Блок A как белый ящик
Детализация
Блок B как белый ящик
A2
B2
A1
B1
A3
75/110

76. Количество уровней
10 LOC
Метод
100 LOC
Класс
1’000 LOC
Модуль
10’000 LOC
Компонент
100’000 LOC
Подсистема
1’000’000 LOC
Система
Достаточно
описания
в коде
Нужны
архитектурные
модели
76/110

77. Контекстная диаграмма
Распределительный
центр
Система
товародвижения
Система
лояльности
Каталог товаров
Розничный
магазин
Система
безопасности
Бухгалтерия
Покупатель
Администратор
Продавец
Кладовщик
77/110

78. Варианты организации блоков






DDD
Layers
Pipes & Filters
Model & View Controler
…
Over 9000
78/110

79. DDD
.

Основная идея – отделить
Блоки
Человеко-машинного
интерфейса
 блоки с предметной областью
 от блоков с технологией

Структура
Предметной области
Это имеет смысл,
поскольку различаются:
 stakeholder’ы
 логика развития
 жизненные циклы
Сервисы
Интерфейсы
ввода
Другие
Сущности
Интерфейсы
вывода
Инфраструктура / Хранение
79/110

80. DDD: как оно начиналось
Концептуальная книга Эрика Эванса


на английском – в 2003 году
на русском – только в 2010 году
Практическая книга Джимми Нильссона
 на английском – в 2006 году

на русском – в 2007 году (почти сразу)
80/110

81. Основная идея DDD
Без DDD
Бизнесаналитик
Заказчик
Системный
аналитик,
архитектор
Разработчик
Бизнесмодель
Модель
приложения
Код
81/110

82. Основная идея DDD
Без DDD
Бизнесаналитик
Заказчик
Системный
аналитик,
архитектор
Разработчик
Бизнесмодель
Модель
приложения
Код
82/110

83. Без DDD
Бизнесаналитик
Заказчик
Системный
аналитик,
архитектор
Разработчик
Бизнесмодель
Модель
приложения
Код
DDD
Аналитики и архитектор
Заказчик
Модель на едином языке
Разработчик
Код
83/110

84. Плюсы модели на едином языке

Единое поле коммуникаций для всех
участников проекта

Верификация модели заказчиком
и выявление наиболее критичных ошибок
на этапе постановки

Простота внесения изменений в требования:
их не надо «протаскивать» через несколько
моделей

Гибкость реагирования на ограничения,
выявляемые при разработке: их можно донести
до заказчика посредством модели и найти
решения
84/110

85. Проблемы
при использовании единой модели

Плохо применима для задач, где основная
сложность не в предметной области

Необходимость понимания модели
заказчиком ограничивает моделирование

Модель не может служить окончательным
проектом для реализации, поскольку
опускает технические детали; нужно
дополнительное проектирование
85/110

86. DDD: типы блоков
Фукнциональные
блоки
Сущности
Сервисы
(Контролеры)
Представления
Блоки
Интерфейсов
ввода
Инфраструктурные
блоки
Блоки
Интерфейсов
вывода
Блоки
хранения
Компоненты/
подсистемы/
Пакеты
Блоки ЧМИ
(Презентация)
86/110

87. Схема сущностей
Смотрите наш семинар
по UML 
87/110

88. Слои



Позволяют отделять области кода
с независимой логикой развития
В идеале можно заменять слой,
не трогая остальные
Действия с системой обычно
пронизывают все слои насквозь
Плюсы:
Минусы:




Ухудшение
производительности

Сложность анализа
и изменений действий
над системой в целом
Структуризация кода
Гибкость
Переносимость
88/110

89. Другие варианты организации блоков
Pipes & Filters
MVC
89/110

90. Типы связей между BB на одном уровне
90/110

91. Диаграммы для описания блоков




UML: диаграмма классов
UML: диаграмма пакетов
Схема сущностей
Другие структурные диаграммы
 Диаграмма плана счетов
91/110

92. Аспект исполнения (Runtime View)

Runtime View – взгляд на систему
с точки зрения функционирования
в реальном времени

Ключевые функции:
 Проверка BBW на адекватность.
Выявление новых блоков
 Коммуникации с заказчиком
и пользователями
92/110

93. Ограничения использования Runtime View

Runtime View избыточен
(дублирует Building Block View):
 Не нужно очень сильно увлекаться поддержанием
в актуальном состоянии
 Достаточно поддерживать 6–7 характерных
сценариев использования
 Не нужно рисовать все альтернативы,
только характерные примеры
 Runtime-диаграмм нужно рисовать много,
но большая часть из них – одноразового
использования (не нужно постоянно поддерживать)
93/110

94. Различные стили организации
потока управления
BOSS
Delegating
94/110

95. Пример диаграммы последовательности
95/110

96. Диаграммы для описания
функционирования в реальном времени

UML

Не-UML
 Диаграмма деятельности
 Диаграмма последовательности
 Диаграмма коммуникации
 Диаграмма состояний
 Диаграмма взаимодействия
 Блок схемы
 Текстовые сценарии в виде пронумерованного

списка шагов
Что угодно еще
96/110

97. Пример описания процесса
97/110

98. Аспект внедрения (Deployment View)

Deploy (от военного
Deploy groups) –
отправлять войска
на чужую территорию

В этом аспекте
мы рисуем,
на каких физических
устройствах будет
разворачиваться
система
98/110

99. Узлы

Существует два типа узлов
 Узел устройства
 Узел среды выполнения
Базовый элемент аспекта –
Node (Узел), что означает
«процессор» (физический
объект, способный выполнять
действия)
:Host
99/110

100. Разделение ответственности между
Buliding Block View и Deployment View
Программное
обеспечение
Функциональный блок
Среда исполнения
приложения
Функциональный блок
или узел среды выполнения
Аппаратный процессор
Узел устройства
100/110

101. Диаграммы
для описания аспекта внедрения

UML

Не UML
 Диаграмма развертывания
 Диаграммы развертывания
с использованием иконок (stereotypes)
101/110

102. Примеры
диаграмм развертывания
102/110

103. Принтер
Информацинный
киоск
Фискальный
регистратор
Принтер
Сервер
Системы
безопасности
счетчик
посетителей
Арм
Администратора
Армы Кассира
Арм Кассира
Дисплей
покупателя
Сканер ШК
Считыватель
карт
Шина
Обмена с
офисом
Сервер
Розничного
магазина
Мобильный
Арм Продавца
Автономная
касса
Принтер
Принтер
этикеток
Сканер ШК
Терминал
Сбора
данных
Колонки
Арм Продавца
Арм
Кладовщика
Псевдо Оффлайн
касса
Фискальный
регистратор
Принтер
Принтер
этикеток
Сканер ШК
Дисплей
покупателя
Сканер ШК
Считыватель
карт
103/110

104. Сервер
системы
безопасности
Информационный
Киоск
АРМ
Счетчик
Посетителей Администратора
АРМ
Кассира
Шина обмена
с офисом
Сервер
Розничного
магазина
Автономная касса
Мобильный
АРМ продавца
АРМ
Кладовщика
АРМ
Продавца
Псевдо-офлайн касса
104/110

105. Принтер
Этикеток
АРМ
Продавца
Считыватель
карт
Сканер
ШК
Принтер
Принтер
АРМ
Кладовщика
АРМ
Кассира
Дисплей
покупателя
Принтер
Этикеток
Фискальный
регистратор
Сканер
ШК
Терминал
сбора
данных
Сканер
ШК
Колонки
105/110

106. Архитектурные концепции

Ориентированы на технологию
и определяются ей (Technology-Driven)

Затрагивают больше одного функционального
блока

Могут быть повторно использованы в других
проектах

Должны порождаться в реальных проектах
(нельзя придумать заранее)

Чаще всего рождаются снизу вверх
106/110

107. Архитектурные концепции
Масштабируемость (Scaling, Clustering)
Обеспечение доступности сервисов (High Availability)
Восстановление после аварий
Безопасность (Security) Способы сохранения/работы с БД (Persistency)
Интернационализация Пользовательские интерфейсы Эргономика
Способы настройки (Configuration) Способы построения отчетов (Reporting)
Способы распространение (Distribution)
Загрузка данных (Migration)
Журналирование (Logging, Tracing) Тестируемость (Testability)
Обработка ошибок и исключений
Интеграция и взаимодействие (Communication)
Управление процессами (Process Control) Параллелизм (Parallelisation and Threading)
Сохранность (Safety)
Управление транзакциями
Управление сессиями
Проверки корректности (Validation)
Сопровождение, настройка и обслуживание (Administration and Operations)

108. Первый набросок системы
108/110

109. 





Задачи системы


Ключевая функциональность
Важные концепции предметной области
Критерии качества
Структура системы


Контекстная диаграмма
2-3 уровня Building Block View
Как будут устроены потоки управления в системе



фиксированные или переменные процессы
будут ли использоваться правила,
оркестровка или хореография
Внедрение и развертывание системы



Как система будет развертываться
Где и когда
В какой инфраструктуре
Концепции



Способы хранения
Технологии разработки
Способы доступа (GUI,API, Batch)
109/110

110. Практический блок. Вариант 1
Управление рейсами в аэропорту
110/110

111. Спасибо!
Вопросы?
Михаил Заборов
mzaborov@custis.ru
114/110