Архитектурное решение - Википедия - Architectural decision

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

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

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

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

История

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

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

Шаги управления решениями

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

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

Принимать решение

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

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

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

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

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

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

Распространение решения (необязательный шаг)

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

Примеры

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

  • Выбор схемы архитектурных слоев и ответственности отдельных слоев (при использовании шаблона Layers из [23])
  • Выбор технологии реализации для каждого уровня, компонента и соединителя (например, язык программирования, формат контракта интерфейса, XML или JSON при проектировании интерфейсов интеграции и обмена сообщениями)
  • Выбор фреймворков уровня представления на стороне клиента (например, фреймворки JavaScript) и на стороне сервера (например, фреймворки Java и PHP)

См. Каталоги концепций дизайна в Attribute-Driven Design 3.0. [24] и модели принятия решений для конкретных областей [25] для получения дополнительных примеров.

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

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

Шаблоны

Многие шаблоны были предложены практикующими архитекторами и исследователями архитектуры программного обеспечения. Репозитории GitHub, такие как «Запись архитектурного решения (ADR)»[28] и «Записи архитектурных решений уценки»[29] собрать множество из них, а также ссылки на инструменты и написание подсказок.

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

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

  • Преобладает неструктурированный подход к принятию решений. Это ограничивает участие членов группы.
  • Отсутствует поддержка инструментов для совместной работы, чтобы помочь архитекторам в процессе принятия решений.
  • Архитекторы часто сталкиваются с задержками и упущениями в процессе принятия решений из-за отсутствия структурированного подхода.
  • Команды архитекторов сталкиваются с проблемами, в том числе: Групповое мышление и Групповая поляризация

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

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

Рекомендации

  1. ^ Фаулер, М. (2003). «Дизайн - Кому нужен архитектор?». Программное обеспечение IEEE. 20 (5): 11–44. DOI: 10.1109 / MS.2003.1231144
  2. ^ Буч, Г., абстрагирование неизвестного, Доклад SATURN 2016
  3. ^ Страница 64 в О. Циммерманн, Архитектурные решения как повторно используемые активы дизайна. Программное обеспечение IEEE, том 28, выпуск 1, страницы 64-69, январь / февраль. 2011 г.
  4. ^ Конклин, Джеффри (2006). Картирование диалогов: формирование общего понимания злых проблем. Чичестер, Англия: издательство Wiley Publishing. ISBN  0470017686.
  5. ^ Крухтен П., Чем на самом деле занимаются архитекторы программного обеспечения?, Журнал систем и программного обеспечения 81 (2008) 2413–2416
  6. ^ Хохпе, Г., Это архитектура? Ищите решения!
  7. ^ Perry, D.E .; Вольф, А. Л. (1992). «Основы изучения архитектуры программного обеспечения» (PDF). Примечания по разработке программного обеспечения ACM SIGSOFT. 17 (4): 40. DOI: 10.1145 / 141874.141884
  8. ^ Jansen, A .; Босх, Дж. (2005). «Архитектура программного обеспечения как набор архитектурных дизайнерских решений». 5-я рабочая конференция IEEE / IFIP по архитектуре программного обеспечения (WICSA'05)
  9. ^ Крухтен, Филипп, Патрисия Лаго и Ханс Ван Влит. "Создание и рассуждение об архитектурных знаниях." Качество программных архитектур. Springer Berlin Heidelberg, 2006. 43–58.
  10. ^ Babar, M.A .; Dingsøyr, T .; Lago, P .; Влит, Х. ван (2009). Управление знаниями архитектуры программного обеспечения: теория и практика (ред.), Первое издание. Springer.
  11. ^ Ли, З., Лян, П., Авгериу, П., Применение основанных на знаниях подходов в архитектуре программного обеспечения: систематическое сопоставление, информационные и программные технологии, том 55, выпуск 5, май 2013 г., страницы 777-794, Elsevier .
  12. ^ Циммерманн, О., Вегманн, Л., Козиолек, Х., Гольдшмидт, Т., Руководство по архитектурным решениям по проектам, Proc. из. IEEE / IFIP WICSA 2015
  13. ^ ISO / IEC / IEEE 42010: шаблоны для использования стандарта.
  14. ^ Hofmeister, C., Kruchten, P., Nord, R., Obbink, H .; Ран, А., Америка, П. (2007), Общая модель проектирования архитектуры программного обеспечения, основанная на пяти промышленных подходах.
  15. ^ Конклин, Джеффри (2006). Картирование диалогов: формирование общего понимания злых проблем. Чичестер, Англия: издательство Wiley Publishing. ISBN  0470017686.
  16. ^ М. Нигард, Документирование архитектурных решений
  17. ^ Циммерманн, О., Платформа моделирования архитектурных решений для SOA и облачного проектирования, Презентация SEI SATURN 2010.
  18. ^ Тайри Дж., Акерман А., Архитектурные решения: демистификация архитектуры
  19. ^ Г. Фэрбенкс, Архитектурное хайку, http://www.slideshare.net/matthewmccullough/architecture-haiku
  20. ^ Т. ван Лессен, Краткое введение в ADR, https://speakerdeck.com/vanto/a-brief-introduction-to-architectural-decision-records
  21. ^ Фэрбенкс, Г., Архитектурно очевидный стиль кодирования: сделать ваш дизайн видимым в вашем коде, Proc. OOPSLA 2010
  22. ^ Babar, M.A .; Dingsøyr, T .; Lago, P .; Влит, Х. ван (2009). Управление знаниями архитектуры программного обеспечения: теория и практика (ред.), Первое издание. Springer.
  23. ^ Бушманн, Франк; Менье, Регина; Ронерт, Ганс; Соммерлад, Питер (1996). Шаблонно-ориентированная архитектура программного обеспечения, Том 1: Система шаблонов. Джон Вили и сыновья. ISBN  0-471-95869-7.
  24. ^ Х. Сервантес, Р. Казман, Проектирование архитектур программного обеспечения: практический подход, Аддисон-Уэсли, 2016.
  25. ^ Страница 21 в Циммерманн, О., Руководящие модели и инструменты для принятия решений для проектирования SOA, облака и аутсорсинга, http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf
  26. ^ Уве Здун и др., Решения в области устойчивого архитектурного проектирования, Программное обеспечение IEEE, том 30, номер 6 (2013 г.), доступно по адресу http://www.infoq.com/articles/sustainable-architectural-design-decisions
  27. ^ М. Фаулер,Паттерны архитектуры корпоративных приложений
  28. ^ Дж. Паркер-Херндерсон, Отчет об архитектурных решениях (ADR), https://github.com/joelparkerhenderson/architecture_decision_record
  29. ^ Организация ADR,Записи архитектурных решений Markdown
  30. ^ Рекхав, В. Смрити; Муччини, Генри (апрель 2014 г.). «Исследование группового принятия решений в архитектуре программного обеспечения». Конференция IEEE / IFIP по архитектуре программного обеспечения, 2014 г.. С. 185–194. Дои:10.1109 / WICSA.2014.15.
  31. ^ V, Смрити Рекха; Муччини, Генри (1 сентября 2018 г.). «Групповое принятие решений в архитектуре программного обеспечения: исследование производственных практик». Информационные и программные технологии. 101: 51–63. Дои:10.1016 / j.infsof.2018.04.009. ISSN  0950-5849.