stringtranslate.com

Архитектурное решение

В программной инженерии и проектировании архитектуры программного обеспечения архитектурные решения — это проектные решения, которые учитывают архитектурно значимые требования ; они воспринимаются как сложные для принятия [1] и/или дорогостоящие для изменения. [2]

Характеристики

Архитектурные решения влияют и воздействуют на нефункциональные характеристики системы. Каждое архитектурное решение описывает конкретную, архитектурно значимую проблему дизайна (также известную как проблема дизайна, требуемое решение), для которой существует несколько потенциальных решений (также известных как варианты, альтернативы). Архитектурное решение фиксирует результат сознательного, часто совместного процесса выбора варианта и предоставляет обоснование дизайна для результата принятия решения, например, ссылаясь на один или несколько качественных атрибутов, рассматриваемых архитектурным решением, и отвечая на вопросы «почему» о дизайне и выборе варианта. Архитектурные решения касаются программной системы в целом или одного или нескольких основных компонентов такой системы. Типы архитектурных решений — это выбор архитектурных тактик и шаблонов, технологий интеграции и промежуточного программного обеспечения, а также связанных стратегий и активов реализации (как коммерческих продуктов, так и проектов с открытым исходным кодом). [3]

Проектирование архитектуры программного обеспечения — это сложная проблема , [4] поэтому архитектурные решения трудно принять правильно. Часто не существует единого оптимального решения для любого заданного набора проблем проектирования архитектуры. Принятие архитектурных решений — это основная обязанность архитекторов программного обеспечения; [5] дополнительную мотивацию важности архитектурных решений как первоклассной концепции в архитектуре программного обеспечения можно найти в Интернете. [6]

История

Обоснование упоминалось в раннем определении архитектуры программного обеспечения Перри/Вульфа [7], но не исследовалось до 2004 года, когда в Гронингене, Нидерланды, был проведен семинар по архитектурным решениям и управлению архитектурными знаниями . Ранние публикации можно проследить до этого семинара. [8] [9] С 2006 года сообщества по управлению архитектурными знаниями и исследованию архитектурных решений набирали обороты, и ряд статей был опубликован на крупных конференциях по архитектуре программного обеспечения, таких как Европейская конференция по архитектуре программного обеспечения (ECSA), Качество архитектуры программного обеспечения (QoSA) и (Рабочая) Международная конференция по архитектуре программного обеспечения (ICSA). В книге Springer обобщено состояние дел по состоянию на 2009 год [10] , а систематическое картографическое исследование 2013 года [11] собирает и анализирует все больше и больше последних результатов исследований.

На практике важность принятия правильных решений всегда признавалась, например, в процессах разработки программного обеспечения, таких как OpenUP; существует множество шаблонов и практик для документирования решений. Семь из этих шаблонов сравниваются в. [12] Самый последний стандарт для описаний архитектуры, ISO/IEC/IEEE 42010:2011 , имеет выделенную сущность обоснования и дает подробные рекомендации, какие архитектурные решения следует фиксировать и какие свойства архитектурного решения следует записывать в журнал решений. [13]

Этапы управления принятием решений

Идентификация решения

Прежде чем принять решение, необходимо сформулировать необходимость принятия решения: насколько срочным и важным является AD? Нужно ли его принимать сейчас или можно подождать, пока не станет больше известно о требованиях и разрабатываемой системе? Как личный, так и коллективный опыт, а также признанные методы и практики проектирования могут помочь в определении решения; было предложено, чтобы команда разработчиков Agile-программного обеспечения вела бэклог решений, дополняющий бэклог продукта проекта. [14]

Принятие решений

Определенные решения могут быть приняты только при соблюдении определенных критериев, которые формируют определение готовности к принятию решения о разрешении споров: (1) Заинтересованные стороны определены, (2) Настало время, (3) Перечислены альтернативы (т.е. варианты), (4) Определены требования и другие критерии, (5) Выбран шаблон решения о разрешении споров. [15]

Существует ряд методов принятия решений, как общих, так и специфических для программного обеспечения и архитектуры программного обеспечения, например, диалоговое картирование . [16] Групповое принятие решений является активной темой исследований.

Документация по решению

Существует множество шаблонов и инструментов для фиксации решений как в гибких сообществах (например, записи архитектурных решений М. Найгарда [17] ), так и в методах разработки программного обеспечения и проектирования архитектуры (например, см. макеты таблиц, предложенные IBM UMF [18] и Тайри и Акерманом из CapitalOne. [19] Г. Фэрбенкс включил обоснование решения в свой одностраничный Architecture Haikus; [20] его нотация позже была преобразована в Y-утверждения. См. [21] для мотивации, примеров и сравнений.

Принятие решения (исполнение)

Архитектурные решения используются в разработке программного обеспечения ; следовательно, они должны быть сообщены и приняты заинтересованными сторонами системы, которые финансируют, разрабатывают и эксплуатируют ее. Архитектурно очевидные стили кодирования [22] и обзоры кода , которые фокусируются на архитектурных проблемах и решениях, являются двумя связанными практиками.

Архитектурные решения также необходимо учитывать при модернизации программной системы в процессе эволюции программного обеспечения .

Обмен решениями (необязательный шаг)

Многие архитектурные решения повторяются в разных проектах; следовательно, опыт прошлых решений, как хороших, так и плохих, может стать ценным ресурсом многократного использования при использовании четкой стратегии управления знаниями. [23]

Важно знать, когда можно считать, что одно архитектурное решение выполнено. Было предложено пять элементов определения выполнено: доказательства, критерии, соглашение, документация, реализация/обзор. [24]

Примеры

В крупномасштабных проектах количество принимаемых архитектурных решений может превышать 100, в том числе:

Дополнительные примеры см. в каталогах концепций дизайна в Attribute-Driven Design 3.0 [26] и моделях руководства по принятию решений, специфичных для предметной области [27] .

Это пример принятого решения, отформатированного в соответствии с шаблоном Y-утверждения, предложенным в: [28]

«В контексте сервиса интернет-магазина, столкнувшись с необходимостью поддержания согласованности и актуальности данных сеанса пользователя во всех экземплярах магазина, мы решили использовать шаблон состояния сеанса базы данных (а не состояние сеанса клиента или состояние сеанса сервера) [29] для достижения эластичности облака, приняв тот факт, что базу данных сеансов необходимо проектировать, внедрять и реплицировать».

Шаблоны

Многие шаблоны были предложены практикующими архитекторами и исследователями архитектуры программного обеспечения. Репозитории GitHub, такие как «Архитектурные решения (ADR)» [30] и «Архитектурные решения Markdown» [31], собирают многие из них, а также ссылки на инструменты и подсказки по написанию.

Принятие решений группой по архитектуре программного обеспечения

И практики, и исследователи признают, что принятие решений по архитектуре программного обеспечения — это групповой процесс, в котором участвуют несколько заинтересованных сторон, обсуждающих, оценивающих и выбирающих архитектурные решения. Исследования [32] [33] практиков показали, что, хотя группы имеют идеальный размер, структурированный подход к принятию решений в значительной степени отсутствует. В частности:

Эти задачи открывают широкие возможности для экспериментов и исследований для сообщества разработчиков архитектуры программного обеспечения.

Смотрите также

Ссылки

  1. ^ Фаулер, М. (2003). «Проектирование – кому нужен архитектор?». IEEE Software. 20 (5): 11–44. doi:10.1109/MS.2003.1231144
  2. ^ Буч, Г., абстрагирование неизвестного, основной доклад на конференции SATURN 2016
  3. ↑ Страница 64 в O. Zimmermann, Architectural Decisions as Reusable Design Assets. IEEE Software, том 28, выпуск 1, страницы 64-69, январь/февраль 2011 г.
  4. ^ Конклин, Джеффри (2006). Диалоговое картирование: построение общего понимания злободневных проблем. Чичестер, Англия: Wiley Publishing. ISBN  0470017686 .
  5. ^ Крухтен, П., Чем на самом деле занимаются архитекторы программного обеспечения?, Журнал систем и программного обеспечения 81 (2008) 2413–2416
  6. ^ Хохпе, Г., Это архитектура? Ищите решения!
  7. ^ Перри, Д. Э.; Вольф, А. Л. (1992). "Основы изучения архитектуры программного обеспечения" (PDF). ACM SIGSOFT Software Engineering Notes. 17 (4): 40. doi:10.1145/141874.141884
  8. ^ Янсен, А.; Бош, Дж. (2005). «Архитектура программного обеспечения как набор архитектурных проектных решений». 5-я рабочая конференция IEEE/IFIP по архитектуре программного обеспечения (WICSA'05)
  9. ^ Крухтен, Филипп, Патрисия Лаго и Ханс Ван Влит . «Создание и рассуждение об архитектурных знаниях». Качество программных архитектур. Springer Berlin Heidelberg, 2006. 43-58.
  10. ^ Бабар, МА; Дингсойр, Т.; Лаго, П.; Влиет, Х. ван (2009). Архитектура программного обеспечения. Управление знаниями: теория и практика (ред.), первое издание. Springer.
  11. ^ Ли, З., Лян, П., Авгериу, П., Применение подходов, основанных на знаниях, в архитектуре программного обеспечения: систематическое картографическое исследование, Информационные и программные технологии, том 55, выпуск 5, май 2013 г., страницы 777–794, Elsevier.
  12. ^ Циммерманн, О., Вегманн, Л., Козиолек, Х., Гольдшмидт, Т., Архитектурное руководство по принятию решений в проектах, Труды IEEE/IFIP WICSA 2015
  13. ^ ISO/IEC/IEEE 42010: Шаблоны для использования стандарта.
  14. ^ Хофмейстер, К., Крухтен, П., Норд, Р., Оббинк, Х.; Ран, А., Америка, П. (2007), Общая модель проектирования архитектуры программного обеспечения, полученная на основе пяти промышленных подходов.
  15. ^ О. Циммерман (2023). Определение готовности к архитектурным решениям, https://medium.com/olzzio/a-definition-of-ready-for-architectural-decisions-ads-2814e399b09b
  16. ^ Конклин, Джеффри (2006). Диалоговое картирование: построение общего понимания злободневных проблем. Чичестер, Англия: Wiley Publishing. ISBN 0470017686 . 
  17. ^ М. Найгард, Документирование архитектурных решений
  18. ^ Циммерманн, О., Архитектурная структура моделирования решений для SOA и облачного проектирования, презентация SEI SATURN 2010.
  19. ^ Тайри, Дж., Акерман, А., Архитектурные решения: демистификация архитектуры
  20. ^ Г. Фэрбенкс, Архитектурное хайку, http://www.slideshare.net/matthewmccullough/architecture-haiku
  21. ^ Т. ван Лессен, Краткое введение в ADR, https://speakerdeck.com/vanto/a-brief-introduction-to-architectural-decision-records
  22. ^ Фэрбенкс, Г., Архитектурно-очевидный стиль кодирования: как сделать ваш дизайн видимым в вашем коде, Proc. OOPSLA 2010
  23. ^ Бабар, МА; Дингсойр, Т.; Лаго, П.; Влиет, Х. ван (2009). Архитектура программного обеспечения. Управление знаниями: теория и практика (ред.), первое издание. Springer.
  24. ^ О. Циммерманн (2020). Определение готовности для архитектурных решений, https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9
  25. ^ Бушманн, Франк; Менье, Регина; Ронерт, Ганс; Соммерлад, Питер (1996). Архитектура программного обеспечения, ориентированная на шаблоны, Том 1: Система шаблонов. Джон Уайли и сыновья. ISBN 0-471-95869-7 . 
  26. ^ Х. Сервантес, Р. Казман, Проектирование программных архитектур: практический подход, Addison-Wesley, 2016.
  27. ^ Страница 21 в Циммерманн, О., Модели руководства и инструменты принятия решений для проектирования SOA, облачных вычислений и аутсорсинговых решений, http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf
  28. ^ Уве Здун и др., Решения по устойчивому архитектурному проектированию, IEEE Software, том 30, номер 6 (2013), доступно по адресу http://www.infoq.com/articles/sustainable-architectural-design-decisions
  29. ^ М. Фаулер, Шаблоны архитектуры корпоративных приложений
  30. ^ Дж. Паркер-Херндерсон, Запись архитектурного решения (ADR), https://github.com/joelparkerhenderson/architecture_decision_record
  31. ^ Организация ADR, записи архитектурных решений Markdown
  32. ^ Рехав, В. Смрити; Муччини, Генри (апрель 2014 г.). «Исследование группового принятия решений в архитектуре программного обеспечения». Конференция IEEE/IFIP по архитектуре программного обеспечения 2014 г. стр. 185–194. doi :10.1109/WICSA.2014.15. ISBN 978-1-4799-3412-6. S2CID  17362075.
  33. ^ V, Smrithi Rekha; Muccini, Henry (1 сентября 2018 г.). «Групповое принятие решений в архитектуре программного обеспечения: исследование промышленных практик». Информационные и программные технологии . 101 : 51–63. doi : 10.1016/j.infsof.2018.04.009. ISSN  0950-5849. S2CID  49384683.