Архитектура в формате C4. Sketches and NoUML

4cЯ не перестаю удивляться энтузиазму, мастерству и целеустремленности архитекторов, с которым они предлагают свои подходы к моделированию информационных систем. Совсем недавно на InfoQ появилась статья Саймона Брауна (Simon Brown) Agile Software Architecture Sketches and NoUML. Саймон автор книги Software Architecture for Developers и сайта coding{the}architecture. В принципе, слайды и материалы с сайта достаточно полно описывают идеи автора. Но для тех, кому будет лениво их просматривать, я изложу краткую версию, немного дополнив её своими комментариями

Итак, простые архитектурные эскизы могут быть не менее полезны, чем строгие модели, выполненные в той или иной нотации, например в нотации UML. Автор предлагает использовать четырехуровневый набор абстракций и соответствующие им четыре вида диаграмм: классы, компоненты, контейнеры и контекст (classes, components, containers, context).

  1. Контекстная диаграмма описывает систему на самом высоком уровне. Её цель заключается в том, чтоб показать окружение системы: пользователей (действующие лица, роли) и другие информационные системы, с которыми осуществляется взаимодействие. Эта модель в первую очередь предназначена для людей, не обладающих специальной подготовкой в ИТ. Она чем-то похожа на UML use case diagram, т.к. содержит акторов и обсуждаемую систему (System Under discussion). Однако контекстная диаграмма не содержит этих смешных овальчиков, которыми обычно отрисовывают сами use case-ы. Вместо них варианты использования пишутся непосредственно на стрелках между действующим лицом и системой.
  2. Диаграмма контейнеров напоминает мне UML deployment diagram, разработанную программистом. На ней присутствуют узлы и некоторые компоненты, но набор этих элементов ограничен. Вы не увидите на ней сетевых элементов, балансировщиков нагрузки и прочих инфраструктурных деталей. Рисуются только те узлы, которые задействованы для развертывания компонент (веб-сервера, сервера приложений, файловые ресурсы, СУБД). Эта схема скорее показывает набор необходимых приложению технологий, чем конкретную модель развертывания.
  3. Компонентная диаграмма детализирует содержание контейнеров. Но отображаются на ней не компоненты в понимании UML, т.е. физически выделяемые элементы системы, а функциональные модули, сервисы в понимании SOA.
  4. Ну и наконец, диаграмма классов представляет собой UML диаграмму классов. Для всех, кроме, быть может, самих разработчиков эта диаграмма является опциональной.

Более подробное изложение подхода можно найти в презентациях на сайте. Пожалуй, эпиграфом ко всему изложенному подходу можно считать фразу Саймона: «You don’t need a UML tool to do architecture but agree on notation».

Теперь мои соображения об изложенном выше подходе. Упрощение еще никому не мешало. В отличии от большинства архитекторов, которым приходится рисовать модели в различных инструментах, я имею возможность рисовать архитектуру на салфетке, чем с удовольствием и пользуюсь. Работая в том или ином инструменте, больше думаешь о том, как нарисовать, а не о том что надо нарисовать. С другой стороны, главным, на мой взгляд, в архитектурных тулах является не картинка, а справочник узлов, компонент, действующих лиц, вариантов использования и т.д. Его все равно надо где-то вести, пусть хоть в экселе, но надо. И наконец, все четыре С больше концентрируются на структуре системы, а не на её поведении. Поэтому, я бы дополнил подход еще одним С – collaboration. Тем более, что 4+1 С это вполне в архитектурных традициях. В принципе, это можно сделать и на любой из перечисленных выше диаграмм просто расставив номера шагов над стрелками, но при наличии сложных сценариев это их перегрузит.

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

Enjoy

Архитектура в формате C4. Sketches and NoUML: 5 комментариев

  1. Очень правильно: “Работая в том или ином инструменте, больше думаешь о том, как нарисовать, а не о том что надо нарисовать”. В ряде проектов тактически просто отказывал в приобретении лицензий на инструмент, так как последствия были бы для проекта скорее отрицательны. Хотя тут надо не забывать и о стратегии. И надо считать, с какого момента разовые и постоянные затраты на инструмент будут меньше, чем ущербы от отсутствия постоянно актуального архитектурного репозитория. Тут очень многое зависит от уровня профессиональной культуры организации в целом и от соотвествующих затрат на “культуру труда”.
    А вот следующая фраза интересна (на мой взгляд) иным:
    “С другой стороны, главным, на мой взгляд, в архитектурных тулах является не картинка, а справочник узлов, компонент, действующих лиц, вариантов использования и т.д.”. – справочники просто необходимы, но и картинка очень важна. И чем дальше, тем важнее. Причем не картинка в стиле UML, а в менее формализованных нотациях и даже просто образная. Тут есть примеры, есть перспективы, но, в первую очередь, есть над чем думать – и архитекторам и разработчикам “тулзов”!

Добавить комментарий для Евгений Зиндер Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *