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

25 сентября 2014 г.
Архитектура ПО
Управляя самым важным
Игорь Беспальчук
Руководитель проектов
дирекции по развитию технологий

Про компанию CUSTIS
2/144

Наша компания занимается:
 проектированием,
3/144

 …разработкой,
4/144

 …внедрением,
5/144

 …сопровождением,
6/144

 …развитием
7/144

 проектированием, разработкой, внедрением,
сопровождением, развитием…
 …заказных информационных систем
на полном жизненном цикле
t
8/144

Для
БанковТорговых сетей
Госкорпораций Предприятий ЖКХ
9/144

Структура компании
>200
10/144

Профессиональная инфраструктура
26%
11/144

Отличники 
20%
12/144

Мальчики и девочки 
30%
13/144

 (2001) Окончил
МГТУ им. Н. Э. Баумана (ИУ-8)
 Программист (Oracle, C#)
 (2006) Пришёл в CUSTIS
 (2008) Руководитель проекта
для ГК «Спортмастер»
 (2010) Руководитель отдела
технологического развития
 (2013) Руководитель проектов
дирекции по развитию технологий
15/144

Моя работа в компании сегодня
Становление и
совершенствование
Управление
проектированием
Архитектурное
проектирование
Архитектор
Управленец
16/144

Преамбула про управление
17/144

Суета вокруг архитектуры
 Проблематика – в области управления
архитектурным проектированием
 Управление архитектурным проектированием
может показаться
далекой и чуждой работой
 Но управлять можно и снизу 
 Важно
понимание происходящего
18/144

План
1. Прошлое и настоящее, теория и практика
2. Проблематика управления
3. Понятие архитектуры
4. Принципы управления
5. Паттерны и анти-паттерны
19/144

Краткая история дисциплины
“Software Architecture”
20/144

История дисциплины (1)
 1950-е: появление множества языков
программирования
 1960-е: первые соображения
(Эдсгер Дейкстра)
о необходимости структуризации программ
 1969 – вторая конференция Software
Engineering, первые упоминания
о “software architecture”
21/144

Ian P. Sharp, 1969
«Есть некое дополнение
к программированию,
и его надо вытащить на свет.
Это программная архитектура.
Архитектура и проектирование –
не одно и то же»
22/144

 1970-е: концепции модульности и сокрытия
информации (Парнас)
 до 1980-x: термин «архитектура» в основном
применяется к аппаратной части компьютеров
 1984: основан Software Engineering Institute
 1990-е: возрождение интереса к теме
 поздние 1990-е – бум на архитектурные тематики
 1996-2000: создание стандарта IEEE 1471
на описание программной архитектуры
23/144

 Слияние с движением
системной инженерии
 ISO/IEC/IEEE 42010:2011,
Systems and software engineering –
Architecture description
 (2010) Состояние дисциплины
архитектурного проектирования:
«готово к внедрению»
24/144

От теории к практике
«Кто переходит к практике
без теории, подобен моряку,
плывущему
на корабле без руля
и компаса, и не ведающему,
где он может оказаться»
25/144

The Standish Group Inc., «CHAOS manifesto-2013»
Печальная статистика
26/144

Совет Standish Group
 Для больших проектов – нет шансов быть
успешным,поэтому…
 не делайте больших проектов
«Мы верим, что нет нужды в больших
проектах и любой IT-проект можно
разбить на набор маленьких»
 Совет в целом правильный, но…
 …иногда при уменьшении проекта
полностью теряется его смысл
27/144

 B. Boehm, 2008
The ROI of System Engineering
Не отказываться, а научиться?
Размер
проекта
(KSLOC)
Оптимальные
затраты
на АП, %
Снижение
затрат
за счет АП,
%
10 5 18
100 20 38
1000 26 63
10000 33 92
29/144

Внутри больших проектов
 У управленцев запаздывает:
 понимание важности АП
 представление о зрелости дисциплины
 и внедрение
 …методов программной инженерии в целом
 …методов работы с программной архитектурой
 Болезни незрелости управления АП
 Хорошие программисты → плохие системы
30/144

«Архитектурная алхимия»
31/144

В чем затруднения практиков?
 Обычное отставание
 Сложность предмета архитектуры
 Мистификация на почве
непонимания
 Неосведомленность
о продвижениях
дисциплины
 Неготовность
учиться
32/144

Ключевое затруднение
 Без понимания предмета
управление невозможно
 Об архитектуре
говорят повсеместно,
но объяснить не могут
 Картинки зданий –
«вот, это архитектура»
33/144

«Архитектура…
 … – это все, что важно»
 … – содержит самые ранние решения»
 … – это способ координировать умы»
 … уравновешивает интересы сторон»
 … играет роль договора с заказчиком»
 … оказывает влияние на структуру коллектива»
34/144

Эволюция представлений
о программной архитектуре
35/144

Понятие и определение
 Для сложных понятий хороших
определений не бывает 
 150 определений
архитектуры
 Системный подход:
 В какое целое
вещь включена как часть
 Какую функцию она выполняет
 Как она устроена
(из чего состоит и за счет чего
выполняется функция)
Архитектура
36/144

Ian P. Sharp, 1968
«Мы говорим только о таких
спецификациях, которые определяют,
что программа должна делать….
Но нужно также определять дизайн,
форму; и в рамках этого каркаса
разработчик должен создавать что-
то… понимая, что архитектор имел в
виду»
37/144

Lane, 1990
«Архитектура включает разделение
функций между модулями, средства связи
между модулями, и представление
разделяемых данных»
38/144

Дизайн
Связи
Модули
Представления
данных
39/144

Royce, 1991
«Архитектура – связующее звено
между технологиями и процессами»
40/144

Dewayne Perry, Alexander Wolf, 1992
«Архитектура определяет выбор
элементов, их взаимодействий,
и ограничения на эти элементы,
и взаимодействия, необходимые, чтобы
обеспечить каркас, в котором будут
удовлетворяться требования и который
будет служить базой для дизайна.
Архитектура =
{Элементы, Формы, Объяснения} »
41/144

Технологии
ДизайнСвязи
МодулиПредставления
данных
Процессы
Взаимодействия каркас
Объяснения
Элементы
Ограничения
42/144

David Garlan, Mary Shaw, 1993
«Архитектура – уровень дизайна,
определяющий вопросы за алгоритмами
и структурами данных вычислений: общую
структуру системы, включая организацию
и глобальную систему управления, протоколы
коммуникации, синхронизации, доступа
к данным; назначение функциональности
элементам дизайна; физическое размещение;
композицию элементов; масштабирование
и производительность; выбор из альтернатив»
43/144

Barry Boehm, 1995
«Архитектура включает: набор
компонентов, связей и ограничений;
набор утверждений о потребностях
интересантов; объяснения,
показывающие что компоненты, связи
и ограничения определяют систему,
которая (если будет реализована)
ответит потребностям
интересантов»
44/144

Low Level (LL)
дизайн
Связи
каркас
Элементы
Взаимодействия
Процессы Технологии
уровень
Дизайн
Потребности
интересантов
Целевая
система
Разные общие
структуры
Размещение Альтернативы
45/144

Soni, Nord, and Hofmeister, 1995
«Архитектура включает четыре
представления:
1. концептуальная а. – элементы и связи
2. модульная а. – функциональная и слоевая
декомпозиция
3. а. выполнения – динамическая структура
4. а. кода – организация исходников,
бинарников и библиотек в окружении
разработки»
46/144

LL-
дизайн
Связи
каркас
Элементы
уровень
Дизайн
Целевая
система
структуры
Размещение
Альтернативы
Декомпозиция
Окружение
разработки
47/144

David Garlan, 2000
«Архитектура описывает структуру
системы в крупном. Эта структура
освещает высокоуровневые
проектировочные решения, включая
то, как система составлена
из взаимодействующих частей, каковы
основные способы взаимодействия,
и каковы ключевые свойства частей»
48/144

Philippe Kruchten, 2003
«Архитектура – это набор значимых
решений по поводу организации системы,
набор структурных элементов и их
интерфейсов, при помощи которых
компонуется система,
вместе с их поведением, определяемым во
взаимодействии между этими элементами,
компоновка элементов в постепенно
укрупняющиеся подсистемы, а также стиль
архитектуры который направляет эту
организацию»
49/144

James McGovern, 2004
«Архитектура состоит из всех важных
проектных решений по поводу структур
программы и взаимодействий между этими
структурами, которые составляют системы.
Проектные решения обеспечивают желаемый
набор свойств, которые должна поддерживать
система, чтобы быть успешной. Проектные
решения предоставляют концептуальную
основу для разработки системы, ее поддержки
и обслуживания»
50/144

LL-
дизайн
Связи
каркас
Элементы
уровень
Дизайн
Целевая
система
структуры
Альтернативы
Окружение
Проектные решения
51/144

ISO 42010
«Архитектура –
фундаментальные концепции или свойства
системы в ее окружении, выраженные
в ее элементах, отношениях, и принципах
их проектирования и развития»
«Архитектура и описание архитектуры –
разные сущности»
52/144

Окружение
LL-
дизайн
Связи
каркас
Элементы
уровень
Дизайн
Целевая
система
структуры
Окружение
Описание
АльтернативыОбъяснения
Фундаментальные
проектные решения Концепции
Свойства
Принципы проектирования
фиксация
трансляция
53/144

Стандарт ISO 42010
 Дает приемлемое определение
 И вводит ряд связанных понятий
(stakeholder, concern, view, viewpoint, …)
 Разводит архитектуру и описание
 Содержит развернутые рекомендации
на описание архитектуры
54/144

Стандарт ISO 42010
 Очень ценен для задач документирования
 Для задач управления – недостаточно
 Нужно разобраться с тем, что такое
«фундаментальные решения»
и как они должны приниматься
57/144

Наводим резкость
58/144

Содержание архитектуры
 Элементы, модули, связи, структуры, виды,
формы, каркасы, разделения, ограничения,
интересанты, потребности окружение,
размещение, управление, интерфейсы, слои,
артефакты, технологии, статика и динамика,
поведение, свойства, отношения, принципы,
стили…
 То есть самые разнообразные
проектные решения
 Конечно, не все и не любые,
а только фундаментальные – об этом далее
59/144

Зависимость проектных решений
 Решение А зависит от решения B,
если A имеет смысл или целесообразно
только в том случае,
когда принято и актуально решение B
B
A
60/144

Система транспортной логистики
Пример
Склады в 100 городах Гарантируется интернет-доступ
Распределенный «клиент-сервер»
Кросс-платформенный «клиент» Нужна работа с оборудованием
«Клиент» пишем на Java
Для UI используем JavaFX
61/144

Главное про зависимость решений
 Зависимости не бывают цикличны,
решения образуют направленный граф
(для простоты – «дерево решений»)
 Если изменяется некоторое решение,
то придется пересмотреть все решения,
которые прямо или косвенно зависят от него
 Решения ближе к корню дерева менять сложно,
решения ближе к листьям менять проще
 Именно положение в структуре зависимостей
определяет пресловутый уровень решения
 Именно околокорневые (фундаментальные)
проектные решения
и составляют содержание архитектуры системы 62/144

Пример Система транспортной логистики
Склады в 100 городах Гарантируется интернет-доступ
Распределенный «клиент-сервер»
Кросс-платформенный «клиент» Нужна работа с оборудованием
«Клиент» пишем на Java
Нужна работа с оборудованием
«Клиент» делаем под Web
Гарантируется интернет-доступ
Файловый и почтовый обмен
Кросс-платформенный «клиент»
«Клиент» делаем под Web
63/144

Фундаментальные проектные решения
Детальные проектные решения
Дизайн
LL-дизайн
Связи
Элементы
…
64/144

О чем недоговаривают эксперты
 Мартин Фаулер, 2003:
 Ральф Джонсон, 2003:
«Архитектура – это все важные решения...
Важные решения – это те, по которым
эксперт сказал, что они важные»
«Нет теоретических причин к тому, чтобы
какие-то решения в софте было тяжело
менять, как в строительстве»
65/144

Некоторые следствия
66/144

Области проектных решений
 Свойства целевой системы (черный ящик)
 Устройство системы (прозрачный ящик)
 Окружение целевой системы (надсистема)
 Производство (обеспечивающая система)
Производство Окружение
Устройство Свойства
67/144

А. Левенчук, 2014
«Архитектура – это те 20% решений
(относительно как требований,
так и устройства), которые
определяют остальные 80%
устройства»
68/144

Области проектных решений
 В архитектуру могут входить решения
не только об устройстве
 Если они существенно влияют на устройство
69/144

Граница архитектуры
 Граница «архитектура–дизайн» определяется
«мерой существенности»
(«фундаментальности»), проектных решений
 То есть граница относительна
70/144

LL-дизайн
71/144

Гибкая архитектура
 Не бывает
 Гибкой (легко изменяемой)
может быть структура
 Ральф Джонсон:
«Мы очень легко можем сделать любой
аспект ПО гибким. И это не сложно.
Но мы не можем сделать ПО гибкими во всех
аспектах. Это породит сложность,
а сложность трудноизменяема»
72/144

Модели в архитектуре
 Основная форма представления
и описания проектных решений (ISO)
 Вся современная инженерия
моделеориентирована
 Но не все модели одинаково полезны
 Детализация
 Вид модели
 Уровень абстракции
 Некоторые решения плохо выражаются
классическими box-and-line моделями
(ограничения, принципы)
73/144

АС
Генерация данных журналов
Сохранение данных журналов
Файлы на
локальных
дисках
Журналы в
БД
Интерфейсы доступа к
журналам
первичная запись
Хранилище
журналов архивирование
чтение
Запрос данных
Запись данных
77/144

Даты
событий
Журналы в исходной БД
(фиксированный объем)
Журналы в хранилище
Перенос
данных
Удаление
данных
Создание
новых
данных
Оперативный
и отчетный контурАналитический и архивный контур
78/144

Результат прояснения
 Про архитектуру можно разговаривать предметно!
 Выделять конкретные решения
 Показывать, что они фундаментальны для устройства
 И этим обосновывать,
что решение входит
в архитектуру
(и что из этого следует)
 Находить подходящие
модели и тексты
для наилучшего
выражения решений
 Конец архитектурной
алхимии
79/144

Что остается неясным?
Дизайн
Технологии
Процессы
Описание
? ?
?
80/144

Примеры архитектурных решений
82/144

Арочный свод
86/144

Интернет
 Из чего состоит архитектура интернета?
 Элементы, соединения и топология практически
произвольны
 Ключевые решения собраны
в стеке протоколов TCP/IP
 Структура гибка
(произвольна),
архитектура – нет!
88/144

Процессор
 Фредерик Брукс:
«Архитектура процессора –
это его система команд»
89/144

Hadoop
 В основе – модель вычислений
MapReduce
90/144

Стратегия
 Например, военная
 Стратегия – архитектура действия
 Архитектура – стратегия проектирования
92/144

Личные примеры каждого
 Ремонт квартиры
 Мебель ставят в последнюю очередь
 Но протяжка проводов и установка розеток
зависит от положения мебели
 Базовая абстракция – функциональные зоны
 Строительство загородного дома
 no comments…
93/144

Резюме по примерам
 Архитектурные решения не всегда
реализуются раньше
 Они могут не относиться к структуре,
структура может быть гибкой
 Они могут плохо выражаться с помощью
структурных (box-and-line) моделей
 Они могут относиться не к устройству,
а к употреблению или производству
 Они не выражаются самой системой
(«кодом») явно
 Ищите примеры архитектур вокруг себя
94/144

Принципы управления
архитектурным проектированием
95/144

Что остается неясным?
Дизайн
Описание
? ?
?
96/144

Надсистема архитектуры
 Архитектура не «внутри» целевой системы
 Архитектура –
внутри производственной системы
97/144

Дизайн
Описание
? ?
?
Производственная (обеспечивающая) система
Целевая
система
создает,
развивает
организует,
управляет
98/144

Функция архитектуры
 Естественные свойства
 негибкость
 подчинение детальных решений
 Отсюда – функция:
направлять детальное
проектирование
 Стратегия
проектирования
99/144

Цели архитектуры
 Назначение системы
 Атрибуты качества
 Ограничения (включая $ и t)
 Свойства окружения
 Не требования!
100/144

Принцип отражения
 (Успешная) система
отражает свойства среды
101/144

Анализ надсистемы
 Назначение и качество
тоже меняются
на жизненном цикле,
но медленно и закономерно
 Нужно понимать
динамику развития,
надсистемы
(окружение и производство)
102/144

Ответственность за архитектуру
 Архитектор или команда?
 НЕ ИМЕЕТ ЗНАЧЕНИЯ!
 До тех пор, пока
ответственность
не лежит ни на ком
и архитектуры нет
как механизма
управления
в производстве
103/144

Окружение
Целевая
системаПланирование
($, t, HR, …)
bin
Проектирование
LL-дизайн
Анализ
Назначение
Качество
Развитие
Сборка
104/144

Анализ, архитектура и дизайн
 Связаны, логически
(как зависимые решения)
 Но не хронологически!
 Хронологически –
все сложнее,
много итераций
105/144

Принципы организации АП
 Современное проектирование
должно быть архитектурным!
 Проявить предмет!
 Ответственность – не важно, на ком,
но должна быть!
 Ориентация на назначение и качество
на ПЖЦ, (а значит – требуется аналитика
качества и стратегии развития надсистем)!
 Вплетена в интерактивный цикл детального
проектирования
 Своевременный пересмотр
106/144

Паттерны управления
Позитивные
Негативные
107/144

108/144
Сборка
Окружение
Целевая
система
Планирование
($, t, HR, …)
Проектирование
LL-дизайн
Анализ
Назначение
Качество
Развитие
?
bin

Группы паттернов
 Целое
 Объективность
 Динамика
 Цели
 Ответственность
 Компетенции
 Развитие
109/144

Лима
 Архитектуры нет (нет целого)
 Про целое ничего нельзя сказать,
кроме объема
111/144

Скрыта за кодом
 Архитектура есть,
но «скрыта за кодом» –
не выражена явно
 Кто-то придумал, остальные
постоянно «реверсируют»
(с переменным успехом),
ответственность потеряна
 Обсуждение невозможно,
т. к. предмет отсутствует
(даже когда есть объект – А.)
113/144

Memento
 Решения не фиксируются, забываются
 Принимаются заново
 Или искажаются
из-за потери
оснований
115/144

 Попытка спроектировать все до мелочей
и сразу
 Все проектирование
произвести до кодирования
 Весь дизайн
запихивается в архитектуру
Big Design Upfront
117/144

Архитектурное голодание
(tech debt)
 Осознание долга есть
 Но с ним ничего не делается
119/144

Тайное качество
 Не направленность на требуемое качество
или работа на «внутреннее» качество
 Не бывает «внутреннего качества»!
т. е. такого, которое не обеспечивает внешнее,
может быть на долгом периоде
 Само требуемое качество
(как краткосрочное, так и долгосрочное)
тоже нуждается
в анализе, и фиксации
 Здесь же: мода, авангардизм
121/144

Башня из слоновой кости
 Архитектор творит нечто, что ему кажется
прекрасным
 Всем остальным это непонятно и неудобно
 Сам архитектор при этом «код не пишет» –
он выше этого
123/144

Анархический Agile
 Отрицается любое главенство
 Страшилки Ivory Tower и BDUF как оружие
 «Мы все равны»
 И поэтому никто не отвечает
 Принцип «равенства»
важнее результата
125/144

Лебедь, рак и щука
 Каждый строит свою
архитектуру
 Каждый хочет как лучше
(в своих представлениях)
 Безответственно
к общему результату
126/144

Главенство авторитета
 Главенство авторитета над целями
 Переход на личности –
сравниваются не решения,
а регалии архитекторов
 Статус важнее результата
128/144

Лучший программист
 Архитектор = самый сильный программист?
 Специфический предмет. Специфический
материал и свойства
 Специфические компетенции
129/144

Архитектура на год
 Архитектура рассчитана только
на минимальный старт
130/144

После нас – хоть потоп
 Успех оценивается по короткому
результату (сдача системы)
132/144

Отлито в бронзе
 А) «Архитектура от старой системы проверена,
возьмем для новой системы её»
 Б) «Архитектуру системы мы сделали три года
назад, и теперь менять в ней ничего нельзя»
 Фрэнк Ллойд Райт:
«Забудьте обо всех архитектурах
мира, если не понимаете того,
что они были хороши
в своём роде и в своё время»
134/144

Швейцарский нож
 Универсальная архитектура –
одна на сильно непохожие (но кажущиеся
похожими) проекты
 «Там же везде БД, документы, трехзвенка
и гриды»
 Неверно выбран масштаб повторного
использования
 Software Product Lines
136/144

Пара позитивных паттернов
137/144

Review
 Экспертная оценка архитектуры
138/144

Архитектура для клиента
 Обсуждение архитектуры
с представителями
заказчика и другими
интересантами
 В адекватных для них
представлениях,
отражающих их
(различные!)
интересы
139/144

Резюме (в форме советов-директив)
 Управляйте или «оно» будет управлять вашим
проектом. Архитектура в любом случае будет
влиять. И никогда не будет гибкой. Сделайте ее
инструментом управления
 Для этого – объективируйте предмет, возложите
ответственность, обеспечьте полномочиями
и ресурсами. Направляйте на цель (анализ)
 Утвердите и держите в голове понятие:
20% фундаментальных решений, которые потом
не пересмотришь, но на которых стоит все
остальное. Из понятия все остальное следует
140/144

Литература
 Филипп Кратчен «Ретроспектива программных архитектур»
 Сайт стандарта ISO 42010 http://www.iso-architecture.org/ieee-1471/index.html
 L. Bass, et al. «Software Architecture in Practice»
 P. Clements, et al. «Documenting Software Architectures: Views and Beyond»
 Блог А. Левенчука http://ailev.ru
 Мартин Фаулер «Who Needs an Architect?»
 Филипп Кратчен «Common Misconceptions about Software Architecture»
 CHAOS manifesto 2013
 Девид Гарлан «Software Architecture: a Roadmap»
 D. Dikel «Software Architecture: Organizational Principles and Patterns»
 P. Eeles «Что такое архитектура программного обеспечения?»
 Определения архитектуры на сайте SEI
 B. Boehm «The ROI of System Engineering»
 Ф. Брукс «Проектирование процесса проектирования»
 Geek & Poke 
141/144

Расширенный список
 Развитие успешных систем
не в области инженерии
 Р. Докинз «Эгоистичный ген»
 Т. Кун «Структура научных революций»
142/144

Спасибо!
Вопросы?
ibespalchuk@custis.ru
http://iamhere.moikrug.ru
143/144

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Архитектура ПО: управляя самым важным

Similar to Архитектура ПО: управляя самым важным (20)

More from CUSTIS

More from CUSTIS (20)

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

Editor's Notes