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

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

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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примеры

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

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

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

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

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

Шаблоны

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

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

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

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

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

См. также

Ссылки

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

[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] Перри, Делавэр; Вольф, Алабама (1992). «Основы изучения архитектуры программного обеспечения» (PDF) . Заметки по разработке программного обеспечения ACM SIGSOFT. 17 (4): 40. дои:10.1145/141874.141884

[8] Янсен, А.; Бош, Дж. (2005). «Архитектура программного обеспечения как совокупность архитектурно-проектных решений». 5-я рабочая конференция IEEE/IFIP по архитектуре программного обеспечения (WICSA'05)

[9] Крухтен, Филипп, Патрисия Лаго и Ханс Ван Влит . « Построение и рассуждение об архитектурных знаниях ». Качество архитектуры программного обеспечения. Springer Berlin Heidelberg, 2006. 43–58.

[10] Бабар, Массачусетс; Дингсойр, Т.; Лаго, П.; Влит, Х. ван (2009). Управление знаниями об архитектуре программного обеспечения: теория и практика (ред.), первое издание. Спрингер.

[11] Ли, З., Лян, П., Авгериу, П., Применение подходов, основанных на знаниях, в архитектуре программного обеспечения: исследование систематического картирования, Информационные и программные технологии, Том 55, Выпуск 5, май 2013 г., страницы 777-794, Эльзевир.

[12] Циммерманн О., Вегманн Л., Козиолек Х., Гольдшмидт Т., Руководство по принятию архитектурных решений в рамках проектов , Proc. из. IEEE/ИФИП ВИКСА 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. ООПЛА 2010 г.

[23] Бабар, Массачусетс; Дингсойр, Т.; Лаго, П.; Влит, Х. ван (2009). Управление знаниями об архитектуре программного обеспечения: теория и практика (ред.), первое издание. Спрингер.

[24] О. Циммерманн (2020). Определение готовности архитектурных решений, https://medium.com/olzzio/a-definition-of-done-for-architectural-decisions-426cf5a952b9

[25] Бушманн, Франк; Менье, Регина; Ронерт, Ганс; Соммерлад, Питер (1996). Архитектура программного обеспечения, ориентированная на шаблоны, Том 1: Система шаблонов. Джон Уайли и сыновья. ISBN 0-471-95869-7 .

[26] Х. Сервантес, Р. Казман, Проектирование архитектуры программного обеспечения: практический подход, Аддисон-Уэсли, 2016.

[27] Страница 21 в Циммерманне, О., Руководящие модели и инструменты принятия решений для SOA, облака и проектирования решений для аутсорсинга, http://resources.sei.cmu.edu/asset_files/Presentation/2011_017_001_24654.pdf

[28] Уве Здун и др., Решения устойчивого архитектурного проектирования, Программное обеспечение IEEE, Том 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. дои : 10.1109/WICSA.2014.15 . ISBN 978-1-4799-3412-6 . S2CID 17362075 .

[33] V, Смрити Рекха; Муччини, Генри (1 сентября 2018 г.). «Групповое принятие решений в архитектуре программного обеспечения: исследование производственной практики» . Информационные и программные технологии . 101 : 51–63. дои : 10.1016/j.infsof.2018.04.009 . ISSN 0950-5849 . S2CID 49384683 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]