Вступление
Попросите кого-нибудь из строительной отрасли визуально описать архитектуру здания, и вам будут представлены планы участка, планы этажей, виды высот, виды поперечного сечения и подробные чертежи. Напротив, попросите разработчика программного обеспечения рассказать об архитектуре программного обеспечения программной системы с помощью диаграмм, и вы, скорее всего, получите путаницу из коробок и линий... непоследовательные обозначения (цветовая кодировка, формы, стили линий и т.д.), неоднозначные названия, немаркированные отношения, общая терминология, отсутствующие технологические решения, смешанные абстракции и т.д.
Как стандарты отрасли, у нас есть Унифицированный язык моделирования (UML), ArchiMate и SysML, но вопрос о том, обеспечивают ли они эффективный способ передачи архитектуры программного обеспечения, часто неуместен, потому что многие команды уже отказались от них в пользу гораздо более простых диаграмм "прямоугольников и линий". Отказ от этих языков моделирования - это одно, но, возможно, в гонке за гибкостью многие команды разработчиков программного обеспечения потеряли способность к визуальному общению.
Схемы вашего кода
Модель C4 была создана как способ помочь командам разработчиков программного обеспечения описать и передать архитектуру программного обеспечения, как во время предварительных сессий проектирования, так и при ретроспективном документировании существующей кодовой базы. Это способ создания схем вашего кода с различными уровнями детализации, точно так же, как вы использовали бы что-то вроде Google Maps для увеличения и уменьшения масштаба интересующей вас области.
Хотя модель C4 в первую очередь предназначена для архитекторов и разработчиков программного обеспечения, она предоставляет командам разработчиков программного обеспечения возможность эффективно и действенно описывать свою архитектуру программного обеспечения на разных уровнях детализации, показывая различного уровня модели при диалоге с разными типам аудитории при выполнении предварительного проектирования или ретроспективном документировании существующей кодовой базы.
Модель C4 - это подход "сначала абстракция" к построению диаграмм архитектуры программного обеспечения, основанный на абстракциях, которые отражают то, как архитекторы и разработчики программного обеспечения представляют и строят программное обеспечение. Небольшой набор абстракций и типов диаграмм делает модель C4 простой в освоении и использовании. Пожалуйста, обратите внимание, что вам не нужно использовать все 4 уровня диаграммы; только те, которые повышают ценность - системный контекст и диаграммы контейнеров достаточны для многих групп разработчиков программного обеспечения.
Абстракции
Чтобы создать эти карты вашего кода, нам сначала нужен общий набор абстракций для создания повсеместного языка, который мы можем использовать для описания статической структуры программной системы. Модель C4 рассматривает статические структуры программной системы (software system) с точки зрения контейнеров (containers), компонентов (components) и кода (code) и людей (people) использующих программные системы, которые мы создаем.
Программная система состоит из одного или нескольких контейнеров (веб-приложений, мобильных приложений, настольных приложений, баз данных, файловых систем и т.д.), Каждый из которых содержит один или несколько компонентов, которые, в свою очередь, реализуются одним или несколькими элементами кода (например, классы, интерфейсы, объекты, функции и т.д.):
Человек (Person)
Человек представляет одного из пользователей вашей программной системы (например, акторов, ролей, персонажей и т.д.).
Программная система (Software System)
Программная система - это высший уровень абстракции и описывает то, что приносит пользу ее пользователям, независимо от того, являются они людьми или нет. Это включает в себя программную систему, которую вы моделируете, и другие программные системы, от которых зависит ваша программная система (или наоборот). Во многих случаях программная система "принадлежит" одной команде разработчиков программного обеспечения.
Контейнер (Container)
(приложения и хранилища данных)
Не Docker! В модели C4 контейнер представляет приложение или хранилище данных. Контейнер - это то, что должно быть запущено для работы всей программной системы. В реальном выражении контейнер - это что-то вроде:
- Серверное веб-приложение: Веб-приложение Java EE, работающее на Apache Tomcat, ASP.NET Приложение MVC, работающее на Microsoft IIS, приложение Ruby on Rails, работающее на WEBrick, Node.js применение и т.д.
- Веб-приложение на стороне клиента: Приложение JavaScript, работающее в веб-браузере с использованием Angular, Backbone.JS, jQuery и т.д.
- Клиентское настольное приложение: Настольное приложение Windows, написанное с использованием WPF, настольное приложение OS X, написанное с использованием Objective-C, кроссплатформенное настольное приложение, написанное с использованием JavaFX, и т.д.
- Мобильное приложение: Приложение Apple iOS, приложение для Android, приложение Microsoft Windows Phone и т.д.
- Консольное приложение на стороне сервера: Автономное (например, "public static void main") приложение, пакетный процесс и т.д.
- Бессерверная функция: Одна бессерверная функция (например, Amazon Lambda, функция Azure и т.д.).
- База данных: Схема или база данных в системе управления реляционными базами данных, хранилище документов, графическая база данных и т.д., Такие как MySQL, Microsoft SQL Server, база данных Oracle, MongoDB, Riak, Cassandra, Neo4j и т.д.
- Хранилище больших двоичных объектов или контента: Хранилище больших двоичных объектов (например, Amazon S3, хранилище больших двоичных объектов Microsoft Azure и т.д.) Или сеть доставки контента (например, Akamai, Amazon CloudFront и т.д.).
- Файловая система: Полная локальная файловая система или часть более крупной сетевой файловой системы (например, SAN, NAS и т. Д.).
- Сценарий оболочки: Один сценарий оболочки, написанный на Bash и т.д.
- и т.д.
Контейнер - это, по сути, контекст или граница, внутри которой выполняется некоторый код или хранятся некоторые данные. И каждый контейнер - это отдельно развертываемая/запускаемая вещь или среда выполнения, обычно (но не всегда) работающая в своем собственном пространстве процессов. Из-за этого связь между контейнерами обычно принимает форму связи между процессами.
Компонент (Component)
Слово "компонент" является чрезвычайно перегруженным термином в индустрии разработки программного обеспечения, но в данном контексте компонент представляет собой группу связанных функций, инкапсулированных за четко определенным интерфейсом. Если вы используете такой язык, как Java или C#, самый простой способ представить компонент как набор классов реализации за интерфейсом. Такие аспекты, как упаковка этих компонентов (например, один компонент против множества компонентов в файле JAR, DLL, общей библиотеке и т.д.), Являются отдельной и ортогональной проблемой.
Здесь важно отметить, что все компоненты внутри контейнера обычно выполняются в одном и том же пространстве процессов. В модели C4 компоненты не являются отдельными развертываемыми единицами.
Основные диаграммы
Визуализация этой иерархии абстракций выполняется путем создания коллекции диаграмм контекста (Context), контейнеров (Container), компонент (Component) и (необязательно) кода (Code) (например, класса UML). Именно отсюда модель C4 получила свое название.
Уровень 1: Схема системного контекста
Схема системного контекста является хорошей отправной точкой для построения диаграмм и документирования программной системы, позволяя вам посмотреть со стороны и увидеть общую картину. Нарисуйте схему, показывающую вашу систему в виде прямоугольника в центре, окруженного её пользователями и другими системами, с которыми она взаимодействует.
Детали здесь не важны, так как это вид, показывающий общую картину системного ландшафта. Основное внимание следует уделять людям (актерам, ролям, персонажам и т.д.) и программным системам, а не технологиям, протоколам и другим деталям низкого уровня. Это своего рода схема, которую вы могли бы показать нетехническим людям.
Область применения: Единая программная система.
Основные элементы: Программная система в объеме.
Вспомогательные элементы: Люди (например, пользователи, действующие лица, роли или персонажи) и программные системы (внешние зависимости), которые непосредственно связаны с программной системой в области действия. Как правило, эти другие программные системы выходят за рамки или границы вашей собственной программной системы, и вы не несете за них ответственности или не являетесь их владельцем.
Целевая аудитория: Все, как технические, так и нетехнические люди, внутри и за пределами команды разработчиков программного обеспечения.
Рекомендуется для большинства команд: Да.
Уровень 2: Схема контейнеров
Как только вы поймете, как ваша система вписывается в общую ИТ-среду, действительно полезным следующим шагом будет уточнение границ системы с помощью диаграммы контейнеров. "Контейнер" - это что-то вроде серверного веб-приложения, одностраничного приложения, настольного приложения, мобильного приложения, схемы базы данных, файловой системы и т.д. По сути, контейнер - это отдельно запускаемый/развертываемый модуль (например, отдельное пространство процесса), который выполняет код или хранит данные.
Схема контейнера показывает высокоуровневую форму архитектуры программного обеспечения и то, как распределяются обязанности между её узлами. Она также показывает основные технологические решения и то, как контейнеры взаимодействуют друг с другом. Это простая, ориентированная на технологии диаграмма высокого уровня, которая полезна как разработчикам программного обеспечения, так и персоналу службы поддержки/эксплуатации.
Область применения: Единая программная система.
Основные элементы: Контейнеры в пределах области действия программной системы.
Вспомогательные элементы: Люди и программные системы, непосредственно подключенные к контейнерам.
Целевая аудитория: Технические специалисты внутри и за пределами команды разработчиков программного обеспечения; в том числе архитекторы программного обеспечения, разработчики и операционный/вспомогательный персонал.
Рекомендуется для большинства команд: Да.
Примечания: На этой диаграмме ничего не говорится о сценариях развертывания, кластеризации, репликации, отработке отказа и т.д.
Уровень 3: Схема компонентов
Затем вы можете увеличить и декомпозировать каждый контейнер дальше, чтобы определить основные структурные строительные блоки и их взаимодействие.
Диаграмма компонентов показывает, как контейнер состоит из нескольких "компонентов", каковы каждый из этих компонентов, их обязанности и детали технологии/реализации.
Область применения: Один контейнер.
Основные элементы: Компоненты внутри контейнера в области действия.
Вспомогательные элементы: Контейнеры (в пределах области применения программной системы) плюс люди и программные системы, непосредственно подключенные к компонентам.
Целевая аудитория: Архитекторы и разработчики программного обеспечения.
Рекомендуется для большинства команд: Нет, создавайте диаграммы компонентов только в том случае, если вы чувствуете, что они повышают ценность, и рассмотрите возможность автоматизации их создания для долговременной документации.
Уровень 4: Код
Наконец, вы можете увеличить масштаб каждого компонента, чтобы показать, как он реализован в виде кода; используя диаграммы классов UML, диаграммы отношений сущностей или аналогичные.
Это необязательный уровень детализации, который часто доступен по требованию с помощью таких инструментов, как IDE. В идеале эта диаграмма должна быть автоматически сгенерирована с помощью инструментов (например, IDE или инструмента моделирования UML), и вам следует рассмотреть возможность отображения только тех атрибутов и методов, которые позволяют вам рассказать историю, которую вы хотите рассказать. Этот уровень детализации не рекомендуется ни для чего, кроме наиболее важных или сложных компонентов.
Область применения: Один компонент.
Основные элементы: Элементы кода (например, классы, интерфейсы, объекты, функции, таблицы базы данных и т.д.) в пределах области действия компонента.
Целевая аудитория: Архитекторы и разработчики программного обеспечения.
Рекомендуется для большинства команд: Нет, для долговременной документации большинство IDE могут генерировать такой уровень детализации по требованию.
Дополнительные диаграммы
Как только вы хорошо разберетесь в статической структуре, вы можете дополнить диаграммы C4, чтобы показать другие аспекты.
Схема ландшафта системы
Модель C4 обеспечивает статическое представление одной программной системы, но в реальном мире программные системы никогда не живут изолированно. По этой причине, и особенно если вы отвечаете за набор программных систем, часто бывает полезно понять, как все эти программные системы сочетаются друг с другом в рамках предприятия. Для этого просто добавьте еще одну диаграмму, расположенную "сверху" диаграмм C4, чтобы показать системный ландшафт с точки зрения ИТ. Как и диаграмма системного контекста, эта диаграмма может отображать организационные границы, внутренних/внешних пользователей и внутренние/внешние системы.
По сути, это карта высокого уровня программных систем на уровне предприятия с детализацией C4 для каждой интересующей программной системы. С практической точки зрения схема системного ландшафта на самом деле является просто диаграммой системного контекста без особого внимания к конкретной программной системе.
Сфера применения: Предприятие.
Основные элементы: Люди и программные системы, относящиеся к предприятию по сфере деятельности.
Целевая аудитория: Технические и нетехнические специалисты, как внутри, так и за пределами команды разработчиков программного обеспечения.
Динамическая диаграмма
Динамическая диаграмма может быть полезна, если вы хотите показать, как элементы статической модели взаимодействуют во время выполнения для реализации истории пользователя, варианта использования, функции и т.д. Эта динамическая диаграмма основана на диаграмме связей UML (communication diagram), ранее известной как "диаграмма совместной работы UML (collaboration diagram). Это похоже на диаграмму последовательности UML (sequence diagram), хотя она позволяет расположить элементы диаграммы в свободной форме с пронумерованными взаимодействиями для указания порядка.
Область применения: Предприятие, программная система или контейнер.
Основные и вспомогательные элементы: Зависит от области применения схемы; предприятие (см. Схему системного ландшафта), программная система (см. Системный контекст или Схемы контейнеров), контейнер (см. Схему компонентов).
Целевая аудитория: Технические и нетехнические специалисты, как внутри, так и за пределами команды разработчиков программного обеспечения.
Схема развертывания
Схема развертывания позволяет проиллюстрировать, как программные системы и/или контейнеры в статической модели сопоставляются с инфраструктурой. Эта схема развертывания основана на схеме развертывания UML, хотя и немного упрощена, чтобы показать сопоставление между контейнерами и узлами развертывания. Узел развертывания - это что-то вроде физической инфраструктуры (например, физический сервер или устройство), виртуализированной инфраструктуры (например, IaaS, PaaS, виртуальная машина), контейнерной инфраструктуры (например, контейнер Docker), среды выполнения (например, сервер базы данных, веб-сервер/сервер приложений Java EE, Microsoft IIS) и т.д. Узлы развертывания могут быть вложенными.
Вы также можете включить узлы инфраструктуры, такие как службы DNS, балансировщики нагрузки, брандмауэры и т.д.
Область применения: Одна или несколько программных систем.
Основные элементы: узлы развертывания, экземпляры программных систем и экземпляры контейнеров.
Вспомогательные элементы: Узлы инфраструктуры, используемые при развертывании программной системы.
Целевая аудитория: Технические специалисты внутри и за пределами команды разработчиков программного обеспечения; в том числе архитекторы программного обеспечения, разработчики, архитекторы инфраструктуры и операционный/вспомогательный персонал.
Обозначения
Модель C4 не предписывает никаких особых обозначений. Простая запись, которая хорошо работает на досках, бумаге, стикерах, карточках и различных инструментах для построения диаграмм, выглядит следующим образом.
Так же вы можете использовать цвет и формы для дополнения диаграммы, либо для добавления дополнительной информации, либо просто для того, чтобы сделать диаграмму более эстетичной.
C4 и UML
Хотя приведенные выше примеры диаграмм созданы с использованием обозначения "прямоугольники и линии", основные диаграммы могут быть проиллюстрированы с использованием UML с соответствующим использованием пакетов, компонентов и стереотипов. Однако результирующим диаграммам UML, как правило, не хватает одинаковой степени описательного текста, поскольку добавление такого текста невозможно (или сложно) с помощью некоторых инструментов UML.
Вот три примера системного контекста, контейнера и диаграммы компонентов для сравнения.
C4 и ArchiMate
См. C4 model, Точка зрения архитектуры и Archi 4.7 для получения подробной информации о том, как создавать диаграммы моделей C4 с помощью ArchiMate.
Ключи/легенда диаграммы
Любая используемая нотация должна быть как можно более самоописывающейся, но все диаграммы должны иметь ключи/легенду, чтобы сделать нотацию явной. Это относится и к диаграммам, созданным с использованием таких обозначений, как UML, ArchiMate и SysML, так как не все будут знать используемые обозначения.
Обозначения, обозначения, обозначения
Хотя модель C4 является подходом, основанным на абстракции, и не зависит от нотации, вам все равно необходимо убедиться, что ваша нотация диаграммы имеет смысл и что диаграммы понятны. Хороший способ подумать об этом - спросить себя, может ли каждая диаграмма стоять отдельно и быть (в основном) понята без повествования. Вы можете использовать этот краткий контрольный список для просмотра диаграмм архитектуры программного обеспечения, чтобы помочь себе ссылка.
И вот некоторые рекомендации, связанные с обозначениями.
| Диаграммы | Элементы | Отношения |
|
|
|
Техническое дополнение (от переводчика)
Нотацию C4 можно использовать в PlantUML диаграммах (пишем текст, который преобразуется в диаграмму), https://github.com/plantuml-stdlib/C4-PlantUML
Можно перевести чек лист проверки диаграммы и оформить в PDF, если нужно пишите в комментарии - дополню статью.
Благодарю за внимание.
