Модель представления архитектуры "4+1"

Модель 4+1 была разработана Филипом Крухтеном для описания архитектуры преимущественно-программных систем, основанном на использовании нескольких взаимодополняющих представлений. Представления используются для описания системы с точки зрения разных заинтересованных лиц, таких как конечные пользователи, разработчики или руководители проекта. Четыре представления – это логическая структура, разработка, процессы и физическая структура системы. Дополнительно вводятся варианты использования, или сценарии, которые иллюстрируют описываемую архитектуру. Поэтому говорят, что модель состоит из 4+1 представления. 

У каждого заинтересованного лица, кроме собственных интересов, есть ещё свои навыки, а также технологии и инструменты, которыми он применяет по отношению к системе, её данным, её коду или её документации.

Интересы, навыки, технологии и инструменты пользователей, как правило, находятся в рамках предметной области. Именно предметная область становится объектом изучения для аналитиков в проектах разработки и сопровождения системы, но интересы, навыки, инструментарий и технологических подходы у аналитиков совсем другие, и зависят они от целей проекта и опыта специалиста, а не от предметной области.

Подход руководства заказчика или эксплуатирующей организации по отношению к системе и её документации отличается от подхода пользователей. Руководителей предприятия заботит чаще деловая и экономическая сторона: как система позволит увеличить доходы или снизить расходы предприятия, какие бизнес-процессы удастся автоматизировать и т.п.

Свои интересы и подходы есть у разработчиков (программистов, дизайнеров, проектировщиков), у персонала сопровождения, у технических писателей, у специалистов по ИБ…

Интересы и подходы каждого заинтересованного лица (или группы лиц) отражаются на его точке зрения. То есть точка зрения на архитектуру – это то, с какой стороны и с какими ожиданиями смотрит человек на архитектурное описание системы.

То, что он при этом видит (или должен увидеть), мы назвали представлением архитектуры. В идеале, та картина, которую заинтересованное лицо реально видит, должна совпадать с той картиной, которую архитектор хочет ему показать. Это – залог взаимопонимания между заинтересованным лицом и архитектором. Но это же позволяет архитектору корректно сочетать интересы всех заинтересованных лиц, добиваться допустимых компромиссов и, в конечном итоге, создавать качественный продукт своей работы.

В модели 4+1 рассматриваются не все представления. Среди всех представлений выделены четыре самых важных:

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

В центре модели 4+1 помещены сценарии. В первом приближении, можно считать, что здесь размещаются сценарии использования системы. Но если смотреть на то, что ожидают заинтересованные лица, становится очевидным, что только сценариев использования тут недостаточно.

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

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

Во-вторых, помимо модели сценариев использования создаются сценарии испытаний (включая сценарии тестирования), развёртывания (с конфигурированием), взаимодействия с внешними системами, мониторинга работоспособности и т.п.

Для качественной проработки документации тоже могут создаваться свои наборы сценариев работы с этой документацией различных заинтересованных лиц. Эти сценарии определяют, по сути, состав и содержание каждого документа из состава технической и эксплуатационной документации на систему (и не надо поминать ГОСТы сейчас: при их разработке учитывался этот же подход, по сути).

Таким образом, для каждого представления в модели 4+1 есть свой набор сценариев, причём это не только сценарии использования.

Представления также взаимосвязаны между собой. Так, из набора прецедентов, определённых на основе пользовательских историй, можно создать модель предметной области, выделив из прецедентов сущности (субъекты и объекты) и их связи. Прецеденты можно детализировать в виде диаграмм взаимодействия и/или последовательностей. Всё вместе составит представление пользователя (логическое представление системы).

Далее, используя согласованную с заказчиком модель предметной области и модель прецедентов, моделируются бизнес-процессы. Из предметной области берутся субъекты (акторы, которые управляют процессом) и объекты (например, передаваемые данные). Прецеденты, в первом приближении, являются шагами бизнес-процесса, со своими пред- и постусловиями, инвариантами и т.п.

После согласования с заказчиком можно использовать бизнес-процессы и модель предметной области для формирования представления разработчика. Но тут надо понять несколько важных аспектов. 

Разработчики - не только программисты. Это и дизайнеры интерфейса пользователя, и проектировщики API, и разработчики баз данных... У каждого из них свои интересы, и поэтому представление разработчика должно дать каждому разработчику достаточную информацию для выполнения им своей части работы над системой. 

И потому модели предметной области и сценариев использования тут мало. Модель данных, используемых в системе, значительно отличается от модели предметной области. Модель данных, хранимых в хранилище, отличается от модели обрабатываемых данных. Набор сценариев, созданный на основе пользовательских историй, достаточен только для проектирования пользовательского интерфейса, да и то если сильно повезёт.

Правильное представление разработчика фактически является постановкой на разработку конкретного модуля системы, с определением всех его внешних связей и внутренней структуры, с определением его функций и алгоритмов их выполнения.

И конечно, представление разработчика содержит информацию о компонентах системы. Именно на основе структуры компонентов часто формируется представление развёртывания этих компонентов на физическом уровне.

Такова логика модели 4+1 Филиппа Крухтена. Далее я буду рассказывать о тонкостях этого подхода к описанию архитектуры системы по отдельным шагам.