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

Открытый семинар для студентов в компании CUSTIS (25 сентября 2014 года).
Лектор: Игорь Беспальчук, руководитель проектов дирекции технологического развития.

Transcript

1. 25 сентября 2014 г. Архитектура ПО Управляя самым важным Игорь Беспальчук Руководитель проектов дирекции по развитию технологий
2. Про компанию CUSTIS 2/144
3. Наша компания занимается:  проектированием, 3/144
4. Наша компания занимается:  …разработкой, 4/144
5. Наша компания занимается:  …внедрением, 5/144
6. Наша компания занимается:  …сопровождением, 6/144
7. Наша компания занимается:  …развитием 7/144
8. Наша компания занимается:  проектированием, разработкой, внедрением, сопровождением, развитием…  …заказных информационных систем на полном жизненном цикле t 8/144
9. Для Банков Торговых сетей Госкорпораций Предприятий ЖКХ 9/144
10. Структура компании >200 10/144
11. Профессиональная инфраструктура 26% 11/144
12. Отличники  20% 12/144
13. Мальчики и девочки  30% 13/144
14. Про себя 14/144
15. Игорь Беспальчук  (2001) Окончил МГТУ им. Н. Э. Баумана (ИУ-8)  Программист (Oracle, C#)  (2006) Пришёл в CUSTIS  (2008) Руководитель проекта для ГК «Спортмастер»  (2010) Руководитель отдела технологического развития  (2013) Руководитель проектов дирекции по развитию технологий 15/144
16. Моя работа в компании сегодня Становление и совершенствование Управление проектированием Архитектурное проектирование Архитектор Управленец 16/144
17. Преамбула про управление 17/144
18. Суета вокруг архитектуры  Проблематика – в области управления архитектурным проектированием  Управление архитектурным проектированием может показаться далекой и чуждой работой  Но управлять можно и снизу   Важно понимание происходящего 18/144
19. План 1. Прошлое и настоящее, теория и практика 2. Проблематика управления 3. Понятие архитектуры 4. Принципы управления 5. Паттерны и анти-паттерны 19/144
20. Краткая история дисциплины “Software Architecture” 20/144
21. История дисциплины (1)  1950-е: появление множества языков программирования  1960-е: первые соображения (Эдсгер Дейкстра) о необходимости структуризации программ  1969 – вторая конференция Software Engineering, первые упоминания о “software architecture” 21/144
22. Ian P. Sharp, 1969 «Есть некое дополнение к программированию, и его надо вытащить на свет. Это программная архитектура. Архитектура и проектирование – не одно и то же» 22/144
23. История дисциплины (2)  1970-е: концепции модульности и сокрытия информации (Парнас)  до 1980-x: термин «архитектура» в основном применяется к аппаратной части компьютеров  1984: основан Software Engineering Institute  1990-е: возрождение интереса к теме  поздние 1990-е – бум на архитектурные тематики  1996-2000: создание стандарта IEEE 1471 на описание программной архитектуры 23/144
24. История дисциплины (3)  Слияние с движением системной инженерии  ISO/IEC/IEEE 42010:2011, Systems and software engineering – Architecture description  (2010) Состояние дисциплины архитектурного проектирования: «готово к внедрению» 24/144
25. От теории к практике «Кто переходит к практике без теории, подобен моряку, плывущему на корабле без руля и компаса, и не ведающему, где он может оказаться» 25/144
26. The Standish Group Inc., «CHAOS manifesto-2013» Печальная статистика 26/144
27. Совет Standish Group  Для больших проектов – нет шансов быть успешным,поэтому…  не делайте больших проектов «Мы верим, что нет нужды в больших проектах и любой IT-проект можно разбить на набор маленьких»  Совет в целом правильный, но…  …иногда при уменьшении проекта полностью теряется его смысл 27/144
28. 28/144
29.  B. Boehm, 2008 The ROI of System Engineering Не отказываться, а научиться? Размер проекта (KSLOC) Оптимальные затраты на АП, % Снижение затрат за счет АП, % 10 5 18 100 20 38 1000 26 63 10000 33 92 29/144
30. Внутри больших проектов  У управленцев запаздывает:  понимание важности АП  представление о зрелости дисциплины  и внедрение  …методов программной инженерии в целом  …методов работы с программной архитектурой  Болезни незрелости управления АП  Хорошие программисты → плохие системы 30/144
31. «Архитектурная алхимия» 31/144
32. В чем затруднения практиков?  Обычное отставание  Сложность предмета архитектуры  Мистификация на почве непонимания  Неосведомленность о продвижениях дисциплины  Неготовность учиться 32/144
33. Ключевое затруднение  Без понимания предмета управление невозможно  Об архитектуре говорят повсеместно, но объяснить не могут  Картинки зданий – «вот, это архитектура» 33/144
34. «Архитектура…  … – это все, что важно»  … – содержит самые ранние решения»  … – это способ координировать умы»  … уравновешивает интересы сторон»  … играет роль договора с заказчиком»  … оказывает влияние на структуру коллектива» 34/144
35. Эволюция представлений о программной архитектуре 35/144
36. Понятие и определение  Для сложных понятий хороших определений не бывает   150 определений архитектуры  Системный подход:  В какое целое вещь включена как часть  Какую функцию она выполняет  Как она устроена (из чего состоит и за счет чего выполняется функция) Архитектура 36/144
37. Ian P. Sharp, 1968 «Мы говорим только о таких спецификациях, которые определяют, что программа должна делать…. Но нужно также определять дизайн, форму; и в рамках этого каркаса разработчик должен создавать что- то… понимая, что архитектор имел в виду» 37/144
38. Lane, 1990 «Архитектура включает разделение функций между модулями, средства связи между модулями, и представление разделяемых данных» 38/144
39. Дизайн Архитектура Связи Модули Представления данных 39/144
40. Royce, 1991 «Архитектура – связующее звено между технологиями и процессами» 40/144
41. Dewayne Perry, Alexander Wolf, 1992 «Архитектура определяет выбор элементов, их взаимодействий, и ограничения на эти элементы, и взаимодействия, необходимые, чтобы обеспечить каркас, в котором будут удовлетворяться требования и который будет служить базой для дизайна. Архитектура = {Элементы, Формы, Объяснения} » 41/144
42. Технологии Дизайн Связи Модули Представления данных Процессы Взаимодействия каркас Объяснения Элементы Ограничения 42/144
43. David Garlan, Mary Shaw, 1993 «Архитектура – уровень дизайна, определяющий вопросы за алгоритмами и структурами данных вычислений: общую структуру системы, включая организацию и глобальную систему управления, протоколы коммуникации, синхронизации, доступа к данным; назначение функциональности элементам дизайна; физическое размещение; композицию элементов; масштабирование и производительность; выбор из альтернатив» 43/144
44. Barry Boehm, 1995 «Архитектура включает: набор компонентов, связей и ограничений; набор утверждений о потребностях интересантов; объяснения, показывающие что компоненты, связи и ограничения определяют систему, которая (если будет реализована) ответит потребностям интересантов» 44/144
45. Low Level (LL) дизайн Связи каркас Объяснения Элементы Ограничения Взаимодействия Процессы Технологии уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Альтернативы 45/144
46. Soni, Nord, and Hofmeister, 1995 «Архитектура включает четыре представления: 1. концептуальная а. – элементы и связи 2. модульная а. – функциональная и слоевая декомпозиция 3. а. выполнения – динамическая структура 4. а. кода – организация исходников, бинарников и библиотек в окружении разработки» 46/144
47. LL- дизайн Связи каркас Объяснения Элементы Ограничения Взаимодействия Процессы Технологии уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Альтернативы Декомпозиция Окружение разработки Представления 47/144
48. David Garlan, 2000 «Архитектура описывает структуру системы в крупном. Эта структура освещает высокоуровневые проектировочные решения, включая то, как система составлена из взаимодействующих частей, каковы основные способы взаимодействия, и каковы ключевые свойства частей» 48/144
49. Philippe Kruchten, 2003 «Архитектура – это набор значимых решений по поводу организации системы, набор структурных элементов и их интерфейсов, при помощи которых компонуется система, вместе с их поведением, определяемым во взаимодействии между этими элементами, компоновка элементов в постепенно укрупняющиеся подсистемы, а также стиль архитектуры который направляет эту организацию» 49/144
50. James McGovern, 2004 «Архитектура состоит из всех важных проектных решений по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания» 50/144
51. LL- дизайн Связи каркас Объяснения Элементы Ограничения Взаимодействия Процессы Технологии уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Альтернативы Декомпозиция Окружение разработки Представления Проектные решения 51/144
52. ISO 42010 «Архитектура – фундаментальные концепции или свойства системы в ее окружении, выраженные в ее элементах, отношениях, и принципах их проектирования и развития» «Архитектура и описание архитектуры – разные сущности» 52/144
53. Окружение LL- дизайн Связи каркас Элементы Ограничения Взаимодействия Процессы Технологии уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Декомпозиция Окружение разработки Описание Представления Альтернативы Объяснения Фундаментальные проектные решения Концепции Свойства Принципы проектирования фиксация трансляция 53/144
54. Стандарт ISO 42010  Дает приемлемое определение  И вводит ряд связанных понятий (stakeholder, concern, view, viewpoint, …)  Разводит архитектуру и описание  Содержит развернутые рекомендации на описание архитектуры 54/144
55. 55/144
56. 56/144
57. Стандарт ISO 42010  Очень ценен для задач документирования  Для задач управления – недостаточно  Нужно разобраться с тем, что такое «фундаментальные решения» и как они должны приниматься 57/144
58. Наводим резкость 58/144
59. Содержание архитектуры  Элементы, модули, связи, структуры, виды, формы, каркасы, разделения, ограничения, интересанты, потребности окружение, размещение, управление, интерфейсы, слои, артефакты, технологии, статика и динамика, поведение, свойства, отношения, принципы, стили…  То есть самые разнообразные проектные решения  Конечно, не все и не любые, а только фундаментальные – об этом далее 59/144
60. Зависимость проектных решений  Решение А зависит от решения B, если A имеет смысл или целесообразно только в том случае, когда принято и актуально решение B B A 60/144
61. Система транспортной логистики Пример Склады в 100 городах Гарантируется интернет-доступ Распределенный «клиент-сервер» Кросс-платформенный «клиент» Нужна работа с оборудованием «Клиент» пишем на Java Для UI используем JavaFX 61/144
62. Главное про зависимость решений  Зависимости не бывают цикличны, решения образуют направленный граф (для простоты – «дерево решений»)  Если изменяется некоторое решение, то придется пересмотреть все решения, которые прямо или косвенно зависят от него  Решения ближе к корню дерева менять сложно, решения ближе к листьям менять проще  Именно положение в структуре зависимостей определяет пресловутый уровень решения  Именно околокорневые (фундаментальные) проектные решения и составляют содержание архитектуры системы 62/144
63. Пример Система транспортной логистики Склады в 100 городах Гарантируется интернет-доступ Распределенный «клиент-сервер» Кросс-платформенный «клиент» Нужна работа с оборудованием «Клиент» пишем на Java Для UI используем JavaFX Нужна работа с оборудованием «Клиент» делаем под Web Для UI используем JavaFX Гарантируется интернет-доступ Файловый и почтовый обмен Кросс-платформенный «клиент» «Клиент» делаем под Web Для UI используем JavaFX 63/144
64. Фундаментальные проектные решения Детальные проектные решения Дизайн Архитектура LL-дизайн Связи Элементы Ограничения Взаимодействия Размещение … 64/144
65. О чем недоговаривают эксперты  Мартин Фаулер, 2003:  Ральф Джонсон, 2003: «Архитектура – это все важные решения... Важные решения – это те, по которым эксперт сказал, что они важные» «Нет теоретических причин к тому, чтобы какие-то решения в софте было тяжело менять, как в строительстве» 65/144
66. Некоторые следствия 66/144
67. Области проектных решений  Свойства целевой системы (черный ящик)  Устройство системы (прозрачный ящик)  Окружение целевой системы (надсистема)  Производство (обеспечивающая система) Производство Окружение Устройство Свойства 67/144
68. А. Левенчук, 2014 «Архитектура – это те 20% решений (относительно как требований, так и устройства), которые определяют остальные 80% устройства» 68/144
69. Области проектных решений  В архитектуру могут входить решения не только об устройстве  Если они существенно влияют на устройство Производство Окружение Устройство Свойства 69/144
70. Граница архитектуры  Граница «архитектура–дизайн» определяется «мерой существенности» («фундаментальности»), проектных решений  То есть граница относительна 70/144
71. Архитектура LL-дизайн 71/144
72. Гибкая архитектура  Не бывает  Гибкой (легко изменяемой) может быть структура  Ральф Джонсон: «Мы очень легко можем сделать любой аспект ПО гибким. И это не сложно. Но мы не можем сделать ПО гибкими во всех аспектах. Это породит сложность, а сложность трудноизменяема» 72/144
73. Модели в архитектуре  Основная форма представления и описания проектных решений (ISO)  Вся современная инженерия моделеориентирована  Но не все модели одинаково полезны  Детализация  Вид модели  Уровень абстракции  Некоторые решения плохо выражаются классическими box-and-line моделями (ограничения, принципы) 73/144
74. 74/144
75. 75/144
76. 76/144
77. АС Генерация данных журналов Сохранение данных журналов Файлы на локальных дисках Журналы в БД Интерфейсы доступа к журналам первичная запись Хранилище журналов архивирование чтение Запрос данных Запись данных 77/144
78. Даты событий Журналы в исходной БД (фиксированный объем) Журналы в хранилище Перенос данных Удаление данных Создание новых данных Оперативный и отчетный контур Аналитический и архивный контур 78/144
79. Результат прояснения  Про архитектуру можно разговаривать предметно!  Выделять конкретные решения  Показывать, что они фундаментальны для устройства  И этим обосновывать, что решение входит в архитектуру (и что из этого следует)  Находить подходящие модели и тексты для наилучшего выражения решений  Конец архитектурной алхимии 79/144
80. Что остается неясным? Архитектура Дизайн Технологии Процессы Описание ? ? ? 80/144
81. Перерыв 81/144
82. Примеры архитектурных решений 82/144
83. 83/144
84. 84/144
85. 85/144
86. Арочный свод 86/144
87. 87/144
88. Интернет  Из чего состоит архитектура интернета?  Элементы, соединения и топология практически произвольны  Ключевые решения собраны в стеке протоколов TCP/IP  Структура гибка (произвольна), архитектура – нет! 88/144
89. Процессор  Фредерик Брукс: «Архитектура процессора – это его система команд» 89/144
90. Hadoop  В основе – модель вычислений MapReduce 90/144
91. 91/144
92. Стратегия  Например, военная  Стратегия – архитектура действия  Архитектура – стратегия проектирования 92/144
93. Личные примеры каждого  Ремонт квартиры  Мебель ставят в последнюю очередь  Но протяжка проводов и установка розеток зависит от положения мебели  Базовая абстракция – функциональные зоны  Строительство загородного дома  no comments… 93/144
94. Резюме по примерам  Архитектурные решения не всегда реализуются раньше  Они могут не относиться к структуре, структура может быть гибкой  Они могут плохо выражаться с помощью структурных (box-and-line) моделей  Они могут относиться не к устройству, а к употреблению или производству  Они не выражаются самой системой («кодом») явно  Ищите примеры архитектур вокруг себя 94/144
95. Принципы управления архитектурным проектированием 95/144
96. Что остается неясным? Архитектура Дизайн Описание ? ? ? 96/144
97. Надсистема архитектуры  Архитектура не «внутри» целевой системы  Архитектура – внутри производственной системы Производство Окружение Устройство Свойства 97/144
98. Архитектура Дизайн Описание ? ? ? Производственная (обеспечивающая) система Целевая система создает, развивает организует, управляет 98/144
99. Функция архитектуры  Естественные свойства  негибкость  подчинение детальных решений  Отсюда – функция: направлять детальное проектирование  Стратегия проектирования 99/144
100. Цели архитектуры  Назначение системы  Атрибуты качества  Ограничения (включая $ и t)  Свойства окружения  Не требования! 100/144
101. Принцип отражения  (Успешная) система отражает свойства среды 101/144
102. Анализ надсистемы  Назначение и качество тоже меняются на жизненном цикле, но медленно и закономерно  Нужно понимать динамику развития, надсистемы (окружение и производство) 102/144
103. Ответственность за архитектуру  Архитектор или команда?  НЕ ИМЕЕТ ЗНАЧЕНИЯ!  До тех пор, пока ответственность не лежит ни на ком и архитектуры нет как механизма управления в производстве 103/144
104. Окружение Целевая система Планирование Ограничения ($, t, HR, …) bin Проектирование LL-дизайн Архитектура Анализ Потребности Назначение Качество Развитие Сборка 104/144
105. Анализ, архитектура и дизайн  Связаны, логически (как зависимые решения)  Но не хронологически!  Хронологически – все сложнее, много итераций 105/144
106. Принципы организации АП  Современное проектирование должно быть архитектурным!  Проявить предмет!  Ответственность – не важно, на ком, но должна быть!  Ориентация на назначение и качество на ПЖЦ, (а значит – требуется аналитика качества и стратегии развития надсистем)!  Вплетена в интерактивный цикл детального проектирования  Своевременный пересмотр 106/144
107. Паттерны управления Позитивные Негативные Негативные Негативные Негативные 107/144
108. 108/144 Сборка Окружение Целевая система Планирование Ограничения ($, t, HR, …) Проектирование LL-дизайн Архитектура Анализ Потребности Назначение Качество Развитие ? bin
109. Группы паттернов  Целое  Объективность  Динамика  Цели  Ответственность  Компетенции  Развитие 109/144
110. 110/144
111. Лима  Архитектуры нет (нет целого)  Про целое ничего нельзя сказать, кроме объема 111/144
112. 112/144
113. Скрыта за кодом  Архитектура есть, но «скрыта за кодом» – не выражена явно  Кто-то придумал, остальные постоянно «реверсируют» (с переменным успехом), ответственность потеряна  Обсуждение невозможно, т. к. предмет отсутствует (даже когда есть объект – А.) 113/144
114. Memento 114/144
115. Memento  Решения не фиксируются, забываются  Принимаются заново  Или искажаются из-за потери оснований 115/144
116. 116/144
117.  Попытка спроектировать все до мелочей и сразу  Все проектирование произвести до кодирования  Весь дизайн запихивается в архитектуру Big Design Upfront 117/144
118. 118/144
119. Архитектурное голодание (tech debt)  Осознание долга есть  Но с ним ничего не делается 119/144
120. 120/144
121. Тайное качество  Не направленность на требуемое качество или работа на «внутреннее» качество  Не бывает «внутреннего качества»! т. е. такого, которое не обеспечивает внешнее, может быть на долгом периоде  Само требуемое качество (как краткосрочное, так и долгосрочное) тоже нуждается в анализе, и фиксации  Здесь же: мода, авангардизм 121/144
122. 122/144
123. Башня из слоновой кости  Архитектор творит нечто, что ему кажется прекрасным  Всем остальным это непонятно и неудобно  Сам архитектор при этом «код не пишет» – он выше этого 123/144
124. Мы gile! 124/144
125. Анархический Agile  Отрицается любое главенство  Страшилки Ivory Tower и BDUF как оружие  «Мы все равны»  И поэтому никто не отвечает  Принцип «равенства» важнее результата 125/144
126. Лебедь, рак и щука  Каждый строит свою архитектуру  Каждый хочет как лучше (в своих представлениях)  Безответственно к общему результату 126/144
127. 127/144
128. Главенство авторитета  Главенство авторитета над целями  Переход на личности – сравниваются не решения, а регалии архитекторов  Статус важнее результата 128/144
129. Лучший программист  Архитектор = самый сильный программист?  Специфический предмет. Специфический материал и свойства  Специфические компетенции 129/144
130. Архитектура на год  Архитектура рассчитана только на минимальный старт 130/144
131. 131/144
132. После нас – хоть потоп  Успех оценивается по короткому результату (сдача системы) 132/144
133. 133/144
134. Отлито в бронзе  А) «Архитектура от старой системы проверена, возьмем для новой системы её»  Б) «Архитектуру системы мы сделали три года назад, и теперь менять в ней ничего нельзя»  Фрэнк Ллойд Райт: «Забудьте обо всех архитектурах мира, если не понимаете того, что они были хороши в своём роде и в своё время» 134/144
135. 135/144
136. Швейцарский нож  Универсальная архитектура – одна на сильно непохожие (но кажущиеся похожими) проекты  «Там же везде БД, документы, трехзвенка и гриды»  Неверно выбран масштаб повторного использования  Software Product Lines 136/144
137. Пара позитивных паттернов 137/144
138. Review  Экспертная оценка архитектуры 138/144
139. Архитектура для клиента  Обсуждение архитектуры с представителями заказчика и другими интересантами  В адекватных для них представлениях, отражающих их (различные!) интересы 139/144
140. Резюме (в форме советов-директив)  Управляйте или «оно» будет управлять вашим проектом. Архитектура в любом случае будет влиять. И никогда не будет гибкой. Сделайте ее инструментом управления  Для этого – объективируйте предмет, возложите ответственность, обеспечьте полномочиями и ресурсами. Направляйте на цель (анализ)  Утвердите и держите в голове понятие: 20% фундаментальных решений, которые потом не пересмотришь, но на которых стоит все остальное. Из понятия все остальное следует 140/144
141. Литература  Филипп Кратчен «Ретроспектива программных архитектур»  Сайт стандарта 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. Расширенный список  Развитие успешных систем не в области инженерии  Р. Докинз «Эгоистичный ген»  Т. Кун «Структура научных революций» 142/144
143. Спасибо! Вопросы? Игорь Беспальчук ibespalchuk@custis.ru http://iamhere.moikrug.ru 143/144