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

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

• Logical view: Логическое представление сфокусировано на функциональности, предоставляемой системой для конечных пользователей. В этом представлении используются UML-диаграммы классов, связей и последовательностей.

• Development view: Представление разработки показывает систему с точки зрения разработчика и касается управления программой. Это представление также известно как представление реализации. Здесь используются UML-диаграммы компонентов и пакетов для описания компонентов системы и их объединения в логические пакеты (например, слои).

• Process view: Представление процесса отражает динамические аспекты системы, показывает происходящие в системе процессы и связи между ними. Представление процесса фокусируется на поведении системы во время выполнения программы. Представление процесса отражает параллелизм выполнения, распределение, интеграцию, производительность, масштабирование и т.п. Представление процесса использует UML-диаграммы активности.

• Physical view: Представление физической структуры показывает систему с точки зрения системного инженера. Она показывает распределение программных компонентов по физическим уровням и физические каналы связи между уровнями. Это представление известно также как представление развёртывания системы. Представление физической структуры системы использует UML-диаграмму развёртывания.

• Scenarios: Описание архитектуры системы должно быть проиллюстрировано небольшим набором вариантов использования, или сценариев. Этот набор сценариев составляет пятое представление модели Крачтена. Сценарии должны описывать взаимодействие между объектами и между процессами. Сценарии используются для идентификации архитектурных элементов и для иллюстрирования и проверки качества архитектуры системы. Они также служат отправной точкой для тестирования архитектурного прототипа системы. Сценарии описываются UML-диаграммами вариантов использования.

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

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

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

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

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

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

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

1. представление пользователя позволяет увидеть, как система отражает предметную область и вписывается в повседневную работу непосредственных пользователей системы;

2. представление бизнес-процессов позволяет увидеть, как система вписывается в процессы деятельности организации и автоматизирует их;

3. представление разработки (или сопровождения) системы показывает, как система должна быть реализована (или уже была реализована);

4. представление развёртывания даёт информацию о конфигурации системы в её окружении в процессе эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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