Холизм в программной архитектуре

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

Holistic?

Принадлежность архитектуры системе как целому, а не ее отдельным частям, — один из основных посылов стандарта ISO/IEC/IEEE 42010:2011, отраженный в тексте стандарта через определение holistic. Авторитетный словарь английского языка Merriam-Wester Dictionary дает нам толкование этого непривычного термина:

Ho·lis·tic (adj.): relating to or concerned with complete systems rather than with individual parts.

Накопленный индустрией 30-летний опыт разработки сложных программных систем уже нашел свое отражение в целом ряде архитектурных подходов, которые предписывают начинающим архитекторам смотреть на систему как целое, а вместе с этим — рассматривать ее саму с различных сторон. Для этого в ISO/IEC/IEEE 42010:2011 введены понятия методов и групп описаний архитектуры (англ. architecture viewpoint, architecture view), которые можно проиллюстрировать несложным для новичка и популярным подходом «4 + 1», предложенным Ф. Крачтеном (англ. Ph. Kruchten) в статье [1].

Подход «4 + 1» Ф. Крачтена…

Основными чертами архитектурного подхода «4 + 1» являются —параллелизм пяти групп описаний архитектуры (представлений, англ. view), каждая из которых удовлетворяет одной группе интересов заинтересованных сторон (руководителя проекта, разработчика, конечного пользователя и пр.), а также раздельный анализ «функциональных» и «нефункциональных» требований.

Впрочем, основным показателем холистичности крачтеновского описания архитектуры ПО является круговой охват будущего продукта, в описании которого находится место для таких вопросов, как:

  • состав системы в терминах классов и объектов, представляющие сущности, явления и процессы реального мира (логическое представление);
  • вопросы параллелизма, синхронизации и т.д. (процессное представление);
  • отображение ПО на (распределенную) аппаратную инфраструктуру (физическое представление);
  • статическая организация ПО в среде его разработки (представление разработки);
  • избранные варианты использования системы (сценарии — абстрактное представление критически важных (повышающих производственные риски) требований к системе).

… и не только

По таким же законам, хотя и в своей собственной парадигме, строятся и другие популярные архитектурные подходы: от IEEE 1471 до The Open Group Architecture Framework (TOGAF).

Ссылки

[1] Kruchten, Ph. “Architectural Blueprints—The ‘4+1’ View Model of Software Architecture,” IEEE Software, vol. 12 (6), pp. 42-50, Nov. 1995.

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.