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

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

Про себя

14/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

http://en.wikipedia.org/wiki/ISO/IEC_42010

http://en.wikipedia.org/wiki/ISO/IEC_42010

От теории к практике

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

25/144

The Standish Group Inc., «CHAOS manifesto-2013»

Печальная статистика

26/144

Совет Standish Group

Для больших проектов – нет шансов быть успешным,поэтому…

не делайте больших проектов

«Мы верим, что нет нужды в больших проектах и любой IT-проект можно разбить на набор маленьких»

Совет в целом правильный, но…

…иногда при уменьшении проектаполностью теряется его смысл

27/144

28/144

B. Boehm, 2008The 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

55/144

56/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

Области проектных решений

В архитектуру могут входить решения не только об устройстве

Если они существенно влияют на устройство


Устройство

Свойства

А

LLD

69/144

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

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

То есть граница относительна

70/144


LL-дизайн

71/144

Гибкая архитектура

Не бывает

Гибкой (легко изменяемой) может быть структура

Ральф Джонсон:

«Мы очень легко можем сделать любой аспект ПО гибким. И это не сложно. Но мы не можем сделать ПО гибкими во всех аспектах. Это породит сложность, а сложность трудноизменяема»

72/144

Модели в архитектуре

Основная форма представления и описания проектных решений (ISO)

Вся современная инженерия моделеориентирована

Но не все модели одинаково полезны Детализация

Вид модели

Уровень абстракции

Некоторые решения плохо выражаются классическими box-and-line моделями(ограничения, принципы)

73/144

74/144

75/144

76/144

АС

Генерация данных журналов

Сохранение данных журналов

Файлы на локальных

дисках

Журналы в БД

Интерфейсы доступа к журналам

первичная запись

Хранилищежурналов архивирование

чтение

Запрос данных

Запись данных

77/144

Даты событий

Журналы в исходной БД(фиксированный объем)

Журналы в хранилище

Перенос данных

Удаление данных

Создание новых

данных

Оперативный и отчетный контурАналитический и архивный контур

78/144

Результат прояснения

Про архитектуру можно разговаривать предметно! Выделять конкретные решения

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

И этим обосновывать, что решение входит в архитектуру (и что из этого следует)

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

Конец архитектурной алхимии

79/144

Что остается неясным?


Дизайн


Процессы

Описание

? ?

?

80/144

Перерыв

81/144

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

82/144

83/144

84/144

85/144

Арочный свод

86/144

87/144

Интернет

Из чего состоит архитектура интернета?

Элементы, соединения и топология практически произвольны

Ключевые решения собраны в стеке протоколов TCP/IP

Структура гибка (произвольна),архитектура – нет!

88/144

Процессор

Фредерик Брукс:

«Архитектура процессора – это его система команд»

89/144

Hadoop

В основе – модель вычисленийMapReduce

90/144

91/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

110/144

Лима

Архитектуры нет (нет целого)

Про целое ничего нельзя сказать, кроме объема

111/144

112/144

Скрыта за кодом

Архитектура есть, но «скрыта за кодом» – не выражена явно

Кто-то придумал, остальные постоянно «реверсируют» (с переменным успехом), ответственность потеряна

Обсуждение невозможно, т. к. предмет отсутствует (даже когда есть объект – А.)

113/144

Memento

114/144

Memento

Решения не фиксируются, забываются

Принимаются заново

Или искажаютсяиз-за потериоснований

115/144

116/144

Попытка спроектировать все до мелочейи сразу

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

Весь дизайн запихивается в архитектуру

Big Design Upfront

117/144

118/144

Архитектурное голодание (tech debt)

Осознание долга есть

Но с ним ничего не делается

119/144

120/144

Тайное качество

Не направленность на требуемое качество или работа на «внутреннее» качество

Не бывает «внутреннего качества»!т. е. такого, которое не обеспечивает внешнее, может быть на долгом периоде

Само требуемое качество (как краткосрочное, так и долгосрочное) тоже нуждается в анализе, и фиксации

Здесь же: мода, авангардизм

121/144

122/144

Башня из слоновой кости

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

Всем остальным это непонятно и неудобно

Сам архитектор при этом «код не пишет» – он выше этого

123/144

Мы

gile!124/144

Анархический Agile

Отрицается любое главенство

Страшилки Ivory Tower и BDUF как оружие

«Мы все равны»

И поэтому никто не отвечает

Принцип «равенства»важнее результата

125/144

Лебедь, рак и щука

Каждый строит свою архитектуру

Каждый хочет как лучше(в своих представлениях)

Безответственно к общему результату

126/144

127/144

Главенство авторитета

Главенство авторитета над целями

Переход на личности – сравниваются не решения,а регалии архитекторов

Статус важнее результата

128/144

Лучший программист

Архитектор = самый сильный программист?

Специфический предмет. Специфический материал и свойства

Специфические компетенции

129/144

Архитектура на год

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

130/144

131/144

После нас – хоть потоп

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

132/144

133/144

Отлито в бронзе

А) «Архитектура от старой системы проверена, возьмем для новой системы её»

Б) «Архитектуру системы мы сделали три года назад, и теперь менять в ней ничего нельзя»

Фрэнк Ллойд Райт:

«Забудьте обо всех архитектурах мира, если не понимаете того, что они были хороши в своём роде и в своё время»

134/144

135/144

Швейцарский нож

Универсальная архитектура – одна на сильно непохожие (но кажущиеся похожими) проекты

«Там же везде БД, документы, трехзвенка и гриды»

Неверно выбран масштаб повторного использования

Software Product Lines

136/144

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

137/144

Review

Экспертная оценка архитектуры

138/144

Архитектура для клиента

Обсуждение архитектуры с представителями заказчика и другимиинтересантами

В адекватных для них представлениях,отражающих их (различные!) интересы

139/144

Резюме (в форме советов-директив)

Управляйте или «оно» будет управлять вашим проектом. Архитектура в любом случае будет влиять. И никогда не будет гибкой. Сделайте ее инструментом управления

Для этого – объективируйте предмет, возложите ответственность, обеспечьте полномочиями и ресурсами. Направляйте на цель (анализ)

Утвердите и держите в голове понятие: 20% фундаментальных решений, которые потом не пересмотришь, но на которых стоит все остальное. Из понятия все остальное следует

Manage!

OR

be managed…

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

http://www.osp.ru/os/2006/03/1156577/

http://www.osp.ru/os/2006/03/1156577/

http://www.osp.ru/os/2006/03/1156577/

http://www.iso-architecture.org/ieee-1471/index.html



http://www.amazon.com/Software-Architecture-Practice-Edition-Engineering/dp/0321815734/ref=pd_sim_sbs_b_2?ie=UTF8&refRID=09DNYC7S85WZ9SWY8D8M






http://www.amazon.com/Documenting-Software-Architectures-Beyond-Edition/dp/0321552687/ref=pd_bxgy_b_img_y







http://ailev.ru/

http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf





http://www.ics.uci.edu/~andre/ics223w2006/kruchten1.pdf








http://www.versionone.com/assets/img/files/ChaosManifesto2013.pdf

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1690&context=compsci








http://www.amazon.com/Software-Architecture-Organizational-Principles-Patterns/dp/0130290327









http://www.ibm.com/developerworks/ru/library/eeles/








http://www.sei.cmu.edu/architecture/definitions.html

http://www.sei.cmu.edu/architecture/definitions.html

https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CBwQFjAA&url=http://www.researchgate.net/publication/227658974_The_ROI_of_systems_engineering_Some_quantitative_results_for_softwareintensive_systems/links/0deec529e0379c88bb000000&ei=giAcVPnyD4rMyAOHp4HgBw&usg=AFQjCNHAXzj8etZRbkgF6DrIygpsifeO3A&sig2=FHMITcEdvZJutJanjqtp9Q&bvm=bv.75774317,d.bGQ&cad=rjt





http://www.ozon.ru/context/detail/id/19375256/

http://geek-and-poke.com/

Расширенный список

Развитие успешных системне в области инженерии

Р. Докинз «Эгоистичный ген»

Т. Кун «Структура научных революций»

142/144

Спасибо!

Вопросы?

Игорь Беспальчук

[email protected]

http://iamhere.moikrug.ru

143/144

mailto:[email protected]

http://iamhere.moikrug.ru/

Science

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