Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

CUSTIS
September 25, 2014

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

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

CUSTIS

September 25, 2014
Tweet

More Decks by CUSTIS

Other Decks in Research

Transcript

  1. 25 сентября 2014 г. Архитектура ПО Управляя самым важным Игорь

    Беспальчук Руководитель проектов дирекции по развитию технологий
  2. Игорь Беспальчук  (2001) Окончил МГТУ им. Н. Э. Баумана

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

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

    управления 3. Понятие архитектуры 4. Принципы управления 5. Паттерны и анти-паттерны 19/144
  5. История дисциплины (1)  1950-е: появление множества языков программирования 

    1960-е: первые соображения (Эдсгер Дейкстра) о необходимости структуризации программ  1969 – вторая конференция Software Engineering, первые упоминания о “software architecture” 21/144
  6. Ian P. Sharp, 1969 «Есть некое дополнение к программированию, и

    его надо вытащить на свет. Это программная архитектура. Архитектура и проектирование – не одно и то же» 22/144
  7. История дисциплины (2)  1970-е: концепции модульности и сокрытия информации

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

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

    подобен моряку, плывущему на корабле без руля и компаса, и не ведающему, где он может оказаться» 25/144
  10. Совет Standish Group  Для больших проектов – нет шансов

    быть успешным,поэтому…  не делайте больших проектов «Мы верим, что нет нужды в больших проектах и любой IT-проект можно разбить на набор маленьких»  Совет в целом правильный, но…  …иногда при уменьшении проекта полностью теряется его смысл 27/144
  11.  B. Boehm, 2008 The ROI of System Engineering Не

    отказываться, а научиться? Размер проекта (KSLOC) Оптимальные затраты на АП, % Снижение затрат за счет АП, % 10 5 18 100 20 38 1000 26 63 10000 33 92 29/144
  12. Внутри больших проектов  У управленцев запаздывает:  понимание важности

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

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

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

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

    бывает   150 определений архитектуры  Системный подход:  В какое целое вещь включена как часть  Какую функцию она выполняет  Как она устроена (из чего состоит и за счет чего выполняется функция) Архитектура 36/144
  17. Ian P. Sharp, 1968 «Мы говорим только о таких спецификациях,

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

    между модулями, и представление разделяемых данных» 38/144
  19. Dewayne Perry, Alexander Wolf, 1992 «Архитектура определяет выбор элементов, их

    взаимодействий, и ограничения на эти элементы, и взаимодействия, необходимые, чтобы обеспечить каркас, в котором будут удовлетворяться требования и который будет служить базой для дизайна. Архитектура = {Элементы, Формы, Объяснения} » 41/144
  20. David Garlan, Mary Shaw, 1993 «Архитектура – уровень дизайна, определяющий

    вопросы за алгоритмами и структурами данных вычислений: общую структуру системы, включая организацию и глобальную систему управления, протоколы коммуникации, синхронизации, доступа к данным; назначение функциональности элементам дизайна; физическое размещение; композицию элементов; масштабирование и производительность; выбор из альтернатив» 43/144
  21. Barry Boehm, 1995 «Архитектура включает: набор компонентов, связей и ограничений;

    набор утверждений о потребностях интересантов; объяснения, показывающие что компоненты, связи и ограничения определяют систему, которая (если будет реализована) ответит потребностям интересантов» 44/144
  22. Low Level (LL) дизайн Связи каркас Объяснения Элементы Ограничения Взаимодействия

    Процессы Технологии уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Альтернативы 45/144
  23. Soni, Nord, and Hofmeister, 1995 «Архитектура включает четыре представления: 1.

    концептуальная а. – элементы и связи 2. модульная а. – функциональная и слоевая декомпозиция 3. а. выполнения – динамическая структура 4. а. кода – организация исходников, бинарников и библиотек в окружении разработки» 46/144
  24. LL- дизайн Связи каркас Объяснения Элементы Ограничения Взаимодействия Процессы Технологии

    уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Альтернативы Декомпозиция Окружение разработки Представления 47/144
  25. David Garlan, 2000 «Архитектура описывает структуру системы в крупном. Эта

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

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

    по поводу структур программы и взаимодействий между этими структурами, которые составляют системы. Проектные решения обеспечивают желаемый набор свойств, которые должна поддерживать система, чтобы быть успешной. Проектные решения предоставляют концептуальную основу для разработки системы, ее поддержки и обслуживания» 50/144
  28. LL- дизайн Связи каркас Объяснения Элементы Ограничения Взаимодействия Процессы Технологии

    уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Альтернативы Декомпозиция Окружение разработки Представления Проектные решения 51/144
  29. ISO 42010 «Архитектура – фундаментальные концепции или свойства системы в

    ее окружении, выраженные в ее элементах, отношениях, и принципах их проектирования и развития» «Архитектура и описание архитектуры – разные сущности» 52/144
  30. Окружение LL- дизайн Связи каркас Элементы Ограничения Взаимодействия Процессы Технологии

    уровень Дизайн Потребности интересантов Потребности интересантов Целевая система Разные общие структуры Размещение Декомпозиция Окружение разработки Описание Представления Альтернативы Объяснения Фундаментальные проектные решения Концепции Свойства Принципы проектирования фиксация трансляция 53/144
  31. Стандарт ISO 42010  Дает приемлемое определение  И вводит

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

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

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

    если A имеет смысл или целесообразно только в том случае, когда принято и актуально решение B B A 60/144
  35. Система транспортной логистики Пример Склады в 100 городах Гарантируется интернет-доступ

    Распределенный «клиент-сервер» Кросс-платформенный «клиент» Нужна работа с оборудованием «Клиент» пишем на Java Для UI используем JavaFX 61/144
  36. Главное про зависимость решений  Зависимости не бывают цикличны, решения

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

    Распределенный «клиент-сервер» Кросс-платформенный «клиент» Нужна работа с оборудованием «Клиент» пишем на Java Для UI используем JavaFX Нужна работа с оборудованием «Клиент» делаем под Web Для UI используем JavaFX Гарантируется интернет-доступ Файловый и почтовый обмен Кросс-платформенный «клиент» «Клиент» делаем под Web Для UI используем JavaFX 63/144
  38. О чем недоговаривают эксперты  Мартин Фаулер, 2003:  Ральф

    Джонсон, 2003: «Архитектура – это все важные решения... Важные решения – это те, по которым эксперт сказал, что они важные» «Нет теоретических причин к тому, чтобы какие-то решения в софте было тяжело менять, как в строительстве» 65/144
  39. Области проектных решений  Свойства целевой системы (черный ящик) 

    Устройство системы (прозрачный ящик)  Окружение целевой системы (надсистема)  Производство (обеспечивающая система) Производство Окружение Устройство Свойства 67/144
  40. А. Левенчук, 2014 «Архитектура – это те 20% решений (относительно

    как требований, так и устройства), которые определяют остальные 80% устройства» 68/144
  41. Области проектных решений  В архитектуру могут входить решения не

    только об устройстве  Если они существенно влияют на устройство Производство Окружение Устройство Свойства 69/144
  42. Гибкая архитектура  Не бывает  Гибкой (легко изменяемой) может

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

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

    дисках Журналы в БД Интерфейсы доступа к журналам первичная запись Хранилище журналов архивирование чтение Запрос данных Запись данных 77/144
  45. Даты событий Журналы в исходной БД (фиксированный объем) Журналы в

    хранилище Перенос данных Удаление данных Создание новых данных Оперативный и отчетный контур Аналитический и архивный контур 78/144
  46. Результат прояснения  Про архитектуру можно разговаривать предметно!  Выделять

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

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

    Архитектура – стратегия проектирования 92/144
  49. Личные примеры каждого  Ремонт квартиры  Мебель ставят в

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

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

    – внутри производственной системы Производство Окружение Устройство Свойства 97/144
  52. Функция архитектуры  Естественные свойства  негибкость  подчинение детальных

    решений  Отсюда – функция: направлять детальное проектирование  Стратегия проектирования 99/144
  53. Цели архитектуры  Назначение системы  Атрибуты качества  Ограничения

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

    цикле, но медленно и закономерно  Нужно понимать динамику развития, надсистемы (окружение и производство) 102/144
  55. Ответственность за архитектуру  Архитектор или команда?  НЕ ИМЕЕТ

    ЗНАЧЕНИЯ!  До тех пор, пока ответственность не лежит ни на ком и архитектуры нет как механизма управления в производстве 103/144
  56. Окружение Целевая система Планирование Ограничения ($, t, HR, …) bin

    Проектирование LL-дизайн Архитектура Анализ Потребности Назначение Качество Развитие Сборка 104/144
  57. Анализ, архитектура и дизайн  Связаны, логически (как зависимые решения)

     Но не хронологически!  Хронологически – все сложнее, много итераций 105/144
  58. Принципы организации АП  Современное проектирование должно быть архитектурным! 

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

    …) Проектирование LL-дизайн Архитектура Анализ Потребности Назначение Качество Развитие ? bin
  60. Группы паттернов  Целое  Объективность  Динамика  Цели

     Ответственность  Компетенции  Развитие 109/144
  61. Скрыта за кодом  Архитектура есть, но «скрыта за кодом»

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

    Или искажаются из-за потери оснований 115/144
  63.  Попытка спроектировать все до мелочей и сразу  Все

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

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

    кажется прекрасным  Всем остальным это непонятно и неудобно  Сам архитектор при этом «код не пишет» – он выше этого 123/144
  66. Анархический Agile  Отрицается любое главенство  Страшилки Ivory Tower

    и BDUF как оружие  «Мы все равны»  И поэтому никто не отвечает  Принцип «равенства» важнее результата 125/144
  67. Лебедь, рак и щука  Каждый строит свою архитектуру 

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

    личности – сравниваются не решения, а регалии архитекторов  Статус важнее результата 128/144
  69. Лучший программист  Архитектор = самый сильный программист?  Специфический

    предмет. Специфический материал и свойства  Специфические компетенции 129/144
  70. Отлито в бронзе  А) «Архитектура от старой системы проверена,

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

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

    другими интересантами  В адекватных для них представлениях, отражающих их (различные!) интересы 139/144
  73. Резюме (в форме советов-директив)  Управляйте или «оно» будет управлять

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

    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
  75. Расширенный список  Развитие успешных систем не в области инженерии

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