Архитектура в IT:

философия и практика

Михаил Заборов

Архитектор, руководитель стратегических проектов

31 октября 2013 года

больших (40–100 человеко-лет)

корпоративных

информационных систем

на заказ

занимается разработкой

2/110

Обо мне

>10 лет в компании

Участвовал

в существенной части

проектов компании

в качестве руководителя

и архитектора

Работаю в одной из групп

развития бизнеса

3/110

Философский блок

4/110

Понятно ли вам,

что такое архитектура?

?

5/110

Архитектура как Buzzword

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

постоянно и повсеместно

Каждый понимает под этим словом что-то свое

Известно несколько сотен формальных

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

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

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

Многие определения существенно неполны

(описывают только один из аспектов)

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

архитектура, слишком абстрактно и интуитивно

6/110

Когда у нас слишком абстрактное

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

об объекте, мы не можем с ним

реально ничего сделать.

А если этот объект критически

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

становимся заложниками случая

и стечения обстоятельств.

Мы не можем существенно влиять

на результат.

!

7/110

Конфуций:

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

названий...

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

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

совершенства.

Если вещи не достигнут совершенства, то церемонии и музыка

не будут процветать.

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

справедливыми.

Если наказания не будут справедливыми, люди не будут знать,

что нужно делать.

Поэтому начальник должен давать только такие названия,

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

только то, что может быть выполнено на практике.

Термин заимствован из строительства

Термин «архитектура»

применительно к IT впервые

появился в 1960-х, однако

начал широко использоваться

только в начале 1990-х

9/110

Замечено, что системы с хорошей

архитектурой значительно чаще

достигают поставленных целей,

меньше стоят и дольше «живут»

10/110

Попытка сформулировать

понятие «архитектура» более строго

В какой системе находится

С чем взаимодействует

Как устроена внутри

Какие функции выполняет

Каковы последствия от ее отсутствия

11/110

Система,

в которой находится архитектура

Большая часть терминов

заимствована из стандарта

ISO/IEC/IEEE 42010

i

12/110

Архитектура приложения

и архитектура предприятия

(Enterprise Architecture)

TOGAF

Захман

FEAF

Over 9000

ISO/IEC/IEEE 42010

IEEE 1471:2000

13/110

Stakeholder, который хочет что-то

сделать с изделием

14/110

Stakeholder’ов много

и у них много разных интересов

15/110

Перейдем к ИТ

16/110

Выпуск

релизов

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

17/110

Риски

18/110

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

Выпуск

релизов

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

о внутреннем устройстве приложения

Состоит из решений1

о внутреннем устройстве (конструкции)

приложения

Решения находятся в отношении

зависимости

1Мы используем термин утверждение

20/110

Решение B зависит от решения A

Изменение A неизбежно влечет за собой

пересмотр B

Бывают ситуации, когда не очевидно,

какое решение базовое

A

B

Базовое

Зависимое (детализирующее)

21/110

Зависимости между решениями

Решения выстраиваются

в цепочки

Решение может зависеть

от нескольких решений

A

B

C A B C

D

22/110

Граф решений

Более

базовые

Более

детальные

Сложнее (дороже) пересматривать

Проще (дешевле) пересматривать

23/110

Слои графа решений

Граф решений

24/110

Grady Booch, Martin Fowler:

Архитектура – это все решения, которые,

сделав однажды, затем трудно изменить.

25/110

ВыводУ приложения нет архитектуры;

она есть у людей, которые его

модифицируют

26/110

Соответствие

архитектуры и продукта

27/110

Вывод

Что входит в архитектуру, а что нет, –

не всегда следствие решения

архитектора. Архитектор скорее

выявляет архитектурные решения,

чем принимает их.

Одна из главных задач архитектора –

чувствовать последствия решений

(что будет действительно важным,

а что – нет).

!

28/110

Решения удобно формировать

группой (в виде моделей)

29/110

При этом модель может фиксировать

решения разных уровней значимости

30/110

Одна из самых важных моделей –

схема функциональных блоков

31/110

Software Engineering Institute:

Архитектура – это структура вычислительной

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

компоненты, внешние свойства этих

компонентов, а также отношения между ними.

32/110

Архитектура – сложный объект

View

Аспекты

Слои

Viewpoint

33/110

Связь технологии и архитектуры

Деятельность архитектора направлена

на изготовление конкретного (одного)

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

Деятельность технолога направлена

на повышение эффективности и качества

процесса изготовления изделия (обычно

для массовых операций)

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

кирпичи (материал), из которого архитектор

может делать все более сложную

архитектуру

34/110

Возможность

не принимать решение повторно

Решения,

определяемые

технологией

35/110

Функции архитектуры

в процессе производства

Изменение системы

производства

Запрос

на изменение

Δ изменения

продукта

36/110

Функции архитектуры

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

2. Нормирует и технологизирует работы

по проектированию

3. Минимизирует риски

4. Используется как контракт в части SCOPE

37/110

1. Архитектура как модель приложения

Модель объекта – это что-то,

что позволяет отвечать

на вопросы об объекте

38/110

Декомпозиция работ по изменению

Разделение работы на независимые части

Запуск параллельных потоков работ

Интеграция результатов работ

Подзадача 1

Подзадача 2

Подзадача 3

Результат

Исходная

задача

39/110

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

Incredible Machine

Оценка масштаба (класса)

предлагаемых изменений

Просто или сложно?

http://domvsegda.ru/

41/110

2. Нормирование и технологизация

работ по проектированию

42/110

Локализация места модификации

приложения

43/110

Минимизация пересмотра принятых

ранее решений

A’ Приложения с хорошей

архитектурой меньше

подвержены постоянным

переделкам

44/110

Определение с сайта 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

Возможность посмотреть вперед и представить,

как будет выглядеть изделие в целом

Минимизация пересмотра принятых

ранее решений

Continuous Refactoring

46/110

Согласование действий проектировщиков

Архитектурные решения выполняют функцию

соглашения между всеми участниками процесса

Минимизация объема

проектирования для типовых задач

47/110

Питер Хрущка:

Архитектура – способ координировать умы.

48/110

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

49/110

Описание работоспособной

конструкции в целом

Нарисованная архитектура –

гарантия того, что это

вообще будет построено

50/110

Андрей Вербицкий:

Хорошая архитектура – это удачный

компромисс между желаниями

и ограничениями.

51/110

Определение ключевых элементов

конструкции, обеспечивающих

качество продукта

Несущие стены

52/110

Анатолий Левенчук:

Архитектура – это то, каким образом

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

функцию/назначение системы.

53/110

4. Архитектура как контракт

в части SCOPE

54/110

Фиксация назначения и границ продукта

А также задач, которые

в принципе могут этим

продуктом решаться

55/110

Определение реальных

потребительских свойств приложения

56/110

В результате мы получили

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

вести более содержательные

разговоры об архитектуре

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

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

более точно

«С архитектурой все плохо»

57/110

Качество архитектуры определяется

ее способностью выполнять

перечисленные функции.

!

58/110

Оценка качества архитектуры

Не отражает актуальное внутреннее устройство

приложения

Не работает как модель приложения

Структура модулей – «поперек» возникающих задач

Не помогает декомпозировать большие задачи

Внесение изменений приводит к непредсказуемым

последствиям

Не помогает локализовать изменения

Необходимые изменения в системе требуют

постоянного пересмотра базовых решений

Не обеспечивает минимизацию пересмотра решений

«Разношерстные» решения типовых задач

Не выполняет функцию координации59/110

Качество процесса управления

архитектурой

Случайные решения становятся базовыми

Решение приняли походя, а от него теперь многое зависит.

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

Проектировщики нижнего уровня

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

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

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

Базовые решения не пересматриваются вовремя

Воспринимаются как жесткие ограничения. Несмотря

на очевидные проблемы при принятии решений на более

детальном уровне

60/110

Методологический блок

61/110

Стандарты по архитектуре

(предприятия)

Таксономия и образцы моделей

Zachman Framework

FEAF

TEAF

Методы разработки архитектуры

TOGAF (ADM)

FEAF

EAP

62/110

Питер Хрущка

arc42.org

63/110

Качество ПО

Заказчик обычно не готов

платить за качество;

он просто ожидает его

64/110

Критерии качества (Quality Goals) –

часть замысла

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

Расширяемость

Простота использования

Надежность (Robustness)

Настраиваемость

Производительность

Гибкость

65/110

Приоритизация критериев качества

Нужно выбрать небольшое (3–5) число

ключевых критериев

Приоритизировать их (определить, что в случае

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

1 Простота использования

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

3 Расширяемость

66/110

Критерии качества

системы «Розничный магазин»

Приоритет Цель Описание

1Устойчивость

к сбоям

Магазин должен функционировать во что бы то

ни стало

2Настраиваемость

и сопровождаемость

Магазины находятся в отдаленных точках;

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

каждый. Нужно уметь удаленно и просто

настраивать систему под особенности магазина

3Простота

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

4 Скорость реакцииИнтерфейсы должны реагировать достаточно

быстро, чтобы не раздражать покупателей

5 РасширяемостьМы должны успевать вносить изменения,

которые просит Заказчик

67/110

Критерии качества

68/110

Внешнее качество

Функциональность

Пригодность

Точность

Способность

к взаимодействию

Защищенность

Расширяемость

Соответствие

стандартам и правилам

Надежность

Стабильность

Отказоустойчивость

Восстанавливаемость

Соответствие

стандартам и правилам

Потребительские

свойства

Понятность

Простота

использования

Обучаемость

Пригодность

Привлекательность

Соответствие

стандартам и правилам

Эффективность

Времяемкость

Производительность

Ресурсоемкость

Соответствие

стандартам и

правилам

Внутреннее качество

Сопровождаемость

Изменяемость

Устойчивость

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

Открытость

Соответствие

стандартам и

правилам

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

Адаптируемость

Встраиваемость

Cосуществование

Заменяемость

Соответствие

стандартам и

правилам

Эксплуатационные качества

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

Эффективность

Продуктивность (результативность)

Производительность

Эксплуатационная безопасность

Удовлетворенность заказчика

DIN/ISO 9126 (++)

Требования к качеству

Нефункциональные

требования

Функциональные

требования

Требования

к качеству

Ограничения

69/110

Дерево качества

70/110

Качество

системы

«Розничный

магазин»

Устойчивость к сбоям

Настраиваемость

и сопровождаемость

Простота использования

Скорость реакции

Расширяемость

При любом сбое системы нужно иметь

возможность продать товар

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

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

Цены все равно должны обновляться из офиса

Настройка новой кассы должна происходить

автоматически

Большая часть настроек должна производится

централизовано из офиса

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

через 2-3 дня работы в паре с опытным сотрудником

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

из-за взаимодействия с системой

Получение заказов из интернет-магазинов

Интеграция с системой безопасности

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

A B

A C

Состав архитектуры

71/110

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

концепции

Структура

Аспект

исполнения(Runtime View)

Аспект

функциональных

блоков(Building Block View)

Аспект

внедрения

и инсталляции

(Deployment View)

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

интерфейсы, эргономика,

управление транзакциями,

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

сетевое взаимодействие,

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

обработка исключений и ошибок,

администрирование и

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

отчетность, конфигурирование,

параллелизация и многопоточность ,

интернационализация, миграция,

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

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

катастрофоустойчивость.

Структура

Структура является «абстракцией кода»

Должна отражать его реальное устройство

и состояние72/110

ИсполнениеВзаимодействие блоков

_ _ _

Функциональные блокиСтатическая структура функциональных

блоков и их зависимости

Внедрение и инсталляция

Инфраструктура ПО

Динамика

Статика

Аспект функциональных блоков

(Building Block View)

Этот аспект –

основной,

остальные –

вспомогательные

(позволяют посмотреть

на систему под другим

углом).

73/110

function, procedure, subroutine, method, array, record

class, unit, table

module, package, library, component, schema

layer, framework, schema

application, subsystem, database

Функциональный блок

Building Blocks (функциональные блоки) –

это блоки, из которых строится программный код.

В разных языках и средах программирования

это могут быть:

Могут быть и другие

специфические блоки

74/110

Иерархия блоков

75/110

Блок B как белый ящикБлок A как белый ящик

Контекстная диаграмма

Система как белый ящик

Система

Внешние

приложения

A B

A1

A2

A3

B1

B2

Детализация

Детализация Детализация

Количество уровней

10 LOC Метод

100 LOC Класс

1’000 LOC Модуль

10’000 LOC Компонент

100’000 LOC Подсистема

1’000’000 LOC Система

Нужны

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

модели

Достаточно

описания

в коде

76/110

Контекстная диаграмма

77/110

ПокупательАдминистратор

Продавец

Кладовщик

Розничный магазин

Система

товародвижения

Каталог товаров

Система

лояльности

Распределительный

центр

Бухгалтерия

Система

безопасности

Варианты организации блоков

DDD

Layers

Pipes & Filters

Model & View Controler

…

Over 9000

78/110

DDD

Основная идея – отделить

блоки с предметной областью

от блоков с технологией

Это имеет смысл,

поскольку различаются:

stakeholder’ы

логика развития

жизненные циклы

.

79/110

Блоки

Человеко-машинного

интерфейса

Интерфейсы

ввода Интерфейсы

вывода

Инфраструктура / Хранение

Другие

Сущности

Сервисы

Структура

Предметной области

DDD: как оно начиналось

Концептуальная книга Эрика Эванса

на английском – в 2003 году

на русском – только в 2010 году

Практическая книга Джимми Нильссона

на английском – в 2006 году

на русском – в 2007 году (почти сразу)

80/110

Основная идея DDD

Бизнес-

модель

Бизнес-

аналитик

Модель

приложенияКод

Системный

аналитик,

архитекторРазработчик

Заказчик

Без DDD

81/110

Основная идея DDD

Бизнес-

модель

Бизнес-

аналитик

Модель

приложенияКод

Системный

аналитик,

архитекторРазработчик

Заказчик

Без DDD

82/110

Модель на едином языке Код

Аналитики и архитектор Разработчик

DDD

Заказчик

Бизнес-

модель

Бизнес-

аналитик

Модель

приложенияКод

Системный

аналитик,

архитекторРазработчик

Заказчик

Без DDD

83/110

Плюсы модели на едином языке

Единое поле коммуникаций для всех

участников проекта

Верификация модели заказчиком

и выявление наиболее критичных ошибок

на этапе постановки

Простота внесения изменений в требования:

их не надо «протаскивать» через несколько

моделей

Гибкость реагирования на ограничения,

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

до заказчика посредством модели и найти

решения 84/110

Проблемы

при использовании единой модели

Плохо применима для задач, где основная

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

Необходимость понимания модели

заказчиком ограничивает моделирование

Модель не может служить окончательным

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

опускает технические детали; нужно

дополнительное проектирование

85/110

DDD: типы блоков

86/110

Блоки

Интерфейсов

ввода

Фукнциональные

блоки

Блоки

Интерфейсов

вывода

Компоненты/

подсистемы/

Пакеты

Инфраструктурные

блокиБлоки

храненияБлоки ЧМИ

(Презентация)

Представления

СущностиСервисы

(Контролеры)

Схема сущностей

Смотрите наш семинар

по UML

87/110

Слои

Позволяют отделять области кода

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

В идеале можно заменять слой,

не трогая остальные

Действия с системой обычно

пронизывают все слои насквозь

Плюсы:

Структуризация кода

Гибкость

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

Минусы:

Ухудшение

производительности

Сложность анализа

и изменений действий

над системой в целом

88/110

Другие варианты организации блоков

Pipes & Filters

MVC

89/110

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

90/110

Диаграммы для описания блоков

UML: диаграмма классов

UML: диаграмма пакетов

Схема сущностей

Другие структурные диаграммы

Диаграмма плана счетов

91/110

Аспект исполнения (Runtime View)

Runtime View – взгляд на систему

с точки зрения функционирования

в реальном времени

Ключевые функции:

Проверка BBW на адекватность.

Выявление новых блоков

Коммуникации с заказчиком

и пользователями

92/110

Ограничения использования Runtime View

Runtime View избыточен

(дублирует Building Block View):

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

в актуальном состоянии

Достаточно поддерживать 6–7 характерных

сценариев использования

Не нужно рисовать все альтернативы,

только характерные примеры

Runtime-диаграмм нужно рисовать много,

но большая часть из них – одноразового

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

93/110

Различные стили организации

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

BOSS Delegating

94/110

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

95/110

Диаграммы для описания

функционирования в реальном времени

UML

Диаграмма деятельности

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

Диаграмма коммуникации

Диаграмма состояний

Диаграмма взаимодействия

Не-UML

Блок схемы

Текстовые сценарии в виде пронумерованного

списка шагов

Что угодно еще96/110

Пример описания процесса

97/110

Аспект внедрения (Deployment View)

Deploy (от военного

Deploy groups) –

отправлять войска

на чужую территорию

В этом аспекте

мы рисуем,

на каких физических

устройствах будет

разворачиваться

система

98/110

Узлы

Существует два типа узлов

Узел устройства

Узел среды выполнения

:Host

Базовый элемент аспекта –

Node (Узел), что означает

«процессор» (физический

объект, способный выполнять

действия)

99/110

Разделение ответственности между

Buliding Block View и Deployment View

Программное

обеспечение Функциональный блок

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

приложения

Функциональный блок

или узел среды выполнения

Аппаратный процессор Узел устройства

100/110

Диаграммы

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

UML

Диаграмма развертывания

Не UML

Диаграммы развертывания

с использованием иконок (stereotypes)

101/110

Примеры

диаграмм развертывания

102/110

103/110

ТерминалСбора

данных

Колонки

Сканер ШК

Сканер ШК

СерверРозничного

магазина

ШинаОбмена с офисом

Псевдо -Оффлайн

касса

Арм Кладовщика

Армы КассираАрм Кассира

Автономнаякасса

Арм Продавца

Арм Администратора

СерверСистемы

безопасности

счетчикпосетителей

МобильныйАрм Продавца

Принтерэтикеток

Принтер

Принтерэтикеток

Принтер

Сканер ШК

Дисплей покупателя

Принтер

Информацинныйкиоск

Считывателькарт

Фискальный регистратор

Сканер ШК

Дисплей покупателя

Принтер

Считывателькарт

Фискальныйрегистратор

Псевдо-офлайн касса

Сервер Розничного

магазина

Шина обмена с офисом

Счетчик Посетителей

МобильныйАРМ продавца

ИнформационныйКиоскСервер

системы безопасности

АРМ Администратора

АРМКладовщика

АРМПродавца

АРМКассира

Автономная касса

104/110

Считыватель карт

Принтер

Сканер ШК

Фискальный регистратор

Дисплей покупателя

АРМКассира

АРМПродавца

ПринтерЭтикеток

Сканер ШК

ПринтерЭтикеток

Принтер

Терминал сбора

данных

Сканер ШК

АРМКладовщика

Колонки105/110

Архитектурные концепции

Ориентированы на технологию

и определяются ей (Technology-Driven)

Затрагивают больше одного функционального

блока

Могут быть повторно использованы в других

проектах

Должны порождаться в реальных проектах

(нельзя придумать заранее)

Чаще всего рождаются снизу вверх

106/110

Архитектурные концепции

Способы сохранения/работы с БД (Persistency)

Пользовательские интерфейсы Эргономика

Управление процессами (Process Control)

Управление транзакциямиУправление сессиями

Безопасность (Security)

Интеграция и взаимодействие (Communication)

Восстановление после аварий

Обеспечение доступности сервисов (High Availability)

Сопровождение, настройка и обслуживание (Administration and Operations)

Параллелизм (Parallelisation and Threading)

Сохранность (Safety)

Обработка ошибок и исключений

Масштабируемость (Scaling, Clustering)

Проверки корректности (Validation)

Интернационализация

Тестируемость (Testability)Журналирование (Logging, Tracing)

Загрузка данных (Migration)

Способы настройки (Configuration)

Способы распространение (Distribution)

Способы построения отчетов (Reporting)

Первый набросок системы

108/110

Задачи системы

Ключевая функциональность

Важные концепции предметной области

Критерии качества

Структура системы

Контекстная диаграмма

2-3 уровня Building Block View

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

фиксированные или переменные процессы

будут ли использоваться правила,

оркестровка или хореография

Внедрение и развертывание системы

Как система будет развертываться

Где и когда

В какой инфраструктуре

Концепции

Способы хранения

Технологии разработки

Способы доступа (GUI,API, Batch) 109/110

Практический блок. Вариант 1

Управление рейсами в аэропорту

110/110

Михаил Заборов

mzaborov@custis.ru

Спасибо!

Вопросы?

114/110