007 Архитектура: Атрибуты качества и представления архитектуры (C4 model)

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

В процессе создания архитектуры высок риск перегрузить ее лишними компонентами или не предусмотреть важные атрибуты качества. Для меня было важно разобрать основные этапы строения, чтобы в работе не упустить основные детали. Один из первых вопросов “С чего начать?” - как идею превратить в техническое решение, начав с абстракции и постепенно переходя к деталям. Модель C4 (Context, Containers, Components, Code), созданная Саймоном Брауном, решает эту проблему через иерархию. C4model.com - официальный сайт, там есть отличные примеры схем на всех 4 уровнях и в целом достаточно подробное описание подхода в представлении архитектуры, поэтому некоторые подробности в данной статье я пропущу.

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

Атрибуты качества

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

За основу возьму Стандарт ISO/IEC 25010, он является одним из актуальных источников для классификации атрибутов качества в системной и программной инженерии, и выделяет 8 основных категорий, которые делятся на 30+ подхарактеристик. По ссылке находится ГОСТ Р ИСО/МЭК 25010-2015 - это официальная, идентичная русскоязычная версия международного стандарта ISO/IEC 25010:2011.

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

Стандарт расширил фокус исключительно с программного обеспечения на целые вычислительные системы (софт + железо + данные). Такие характеристики как «Безопасность» и «Совместимость» стали настолько критичными, что были выделены в самостоятельные, независимые атрибуты верхнего уровня (ранее они были лишь подхарактеристиками).

Если будет желание погрузиться дополнительно в теорию без воды, то порекомендую следующие работы:

Существуют еще «бизнес-атрибуты качества» (например, Time-to-market или Cost). Архитектура может быть идеальной технически, но если её внедрение занимает 2 года при бюджете в месяц - это плохая архитектура.

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

- Стандарт содержит огромный массив теоретических данных, моделей и определений. Промпт превращает этот сложный 30-страничный документ в пошаговый, интерактивный фреймворк. Он заставляет оценивать продукт не хаотично, а через две взаимодополняющие призмы: как продукт написан технически (Модель качества продукта) и какую реальную пользу/влияние он оказывает на людей (Модель качества при использовании).

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

- Учел скрытые ожидания. Стандарт подчеркивает, что некоторые потребности пользователей являются фактическими, но часто остаются невысказанными (поскольку кажутся "очевидными"), и они всплывают только тогда, когда продукт начинает использоваться. Промпт поможет выявить их на ранней стадии.

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

- Добавленное правило (Trade-offs) делает работу ИИ-ассистента аналитической. Стандарт обращает внимание на взаимосвязь характеристик и то, как они влияют друг на друга (например, общие требования к надежности и отказоустойчивости могут повлиять на общую производительность или удобство). Промпт заставит ИИ предупреждать пользователя: «Если мы максимально закручиваем гайки в безопасности (Security), нам придется пожертвовать скоростью работы (Performance Efficiency)».

- Четкое разделение верификации и валидации. В ИТ эти понятия часто путают, но промпт (Step 4) расставляет все по местам согласно ГОСТ. Верификация подтвердит, что технические требования выполнены (продукт сделан правильно). Валидация подтвердит, что система действительно решает задачи заинтересованных сторон в реальном контексте (сделан правильный продукт).

# Role and Context
You are a Senior Systems and Software Quality Engineer and a leading expert on the ISO/IEC 25010 (SQuaRE) standard. Your objective is to guide the user through a rigorous, step-by-step evaluation of an IT product's quality, following the GOST R ISO/IEC 25010-2015 / ISO/IEC 25010:2011 framework.

# Operational Rules & Strategy
1. **Interactive Step-by-Step:** Conduct the process ONE step at a time. Do not rush. Wait for the user's response before proceeding to the next step.
2. **Reasoning Protocol (Think First):** Before providing your main response, use a "Internal Thought" process to:
    - Analyze how the current lifecycle stage affects the choice of measures.
    - Identify potential trade-offs (e.g., if the user prioritizes Reliability, note how it might affect Performance Efficiency).
    - Detect any implied needs that the user might have missed.
3. **Standard Rigor:** Use exact terminology from the standard (e.g., "Functional Suitability" instead of "Features").
4. **Adaptive Depth:** If the user's input is vague, ask clarifying questions instead of proceeding. We need a clear "Human-Machine System" context to be effective.
5. **Model Tailoring:** Prioritize only the most relevant characteristics based on high-level goals and resources, as measuring everything is practically impossible.

# The Evaluation Workflow

### Step 1: Context and Stakeholder Mapping
Analyze the "Human-Machine System" context. Ask the user for:
- **The Target Product:** What is it and what does it do?
- **Lifecycle Stage:** Is it in design, testing, or operational use?
- **Context of Use:** Tasks, equipment, physical and social environment.
- **Stakeholders:** Help categorize Primary, Secondary (maintenance/support), and Indirect users.

### Step 2: Formulating Quality Requirements
Facilitate the definition of requirements using the two main models:
- **Quality in Use Model:** Effectiveness, Efficiency, Satisfaction, Freedom from Risk, Context Coverage.
- **Product Quality Model:** Functional Suitability, Performance Efficiency, Compatibility, Usability, Reliability, Security, Maintainability, Portability.

### Step 3: Defining Quantifiable Quality Measures
Select specific metrics:
- **Internal:** Static properties (architecture/code) during development.
- **External:** Dynamic properties (response time/error rates) during testing.
- **Quality in Use:** Real-world impact (success rate/actual risk incidents).

### Step 4: Verification and Validation Framework
- **Verification:** Objective evidence that technical requirements (Product Quality) are met.
- **Validation:** Confirmation that the system satisfies stakeholder needs in the actual context of use.

Let's begin. Introduce yourself as the SQuaRE Quality Architect and start with Step 1 questions.

Модель C4.

В этой статье не буду рассматривать и переписывать документацию по модели C4. Кратко рассмотрю основы и оставлю мысли про ценности, которая дает эта модель и оставлю ресурсы, где все подробно и доступно объясняется.

Модель C4 намеренно не навязывает строгих правил отрисовки (как это делает UML), но предоставляет отличные рекомендации. За практическими примерами каждого типа диаграмм, нотацией, советами по выбору инструментов и чек-листами я крайне рекомендую обратиться к официальному сайту c4model.com, который является исчерпывающим ресурсом для внедрения этого подхода в вашей команде.

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

Рассматривая атрибуты качества, мы рассматривали стандарт ISO 25010 - отвечающий на вопрос “Насколько качественной должна быть система”, при изучении модели C4, стоит рассмотреть стандарт ISO/IEC/IEEE 42010, чтобы ответить на вопрос “По каким правилам мы описываем систему?”. C4 - это конкретная реализация концепций, заложенных в этом стандарте.

Изучая про C4 мне попала статья Documenting Architecture Decisions - автор  Майкл Найгард предлагает использовать записи об архитектурных решениях (ADR) для эффективного управления изменениями в гибких проектах. Вместо громоздкой документации, которую никто не читает, рекомендуется создавать короткие текстовые файлы, фиксирующие контекст, мотивы и последствия выбора технологий или методов разработки. Каждая запись включает в себя описание действующих факторов, само решение и оценку его влияния на будущую структуру системы. Хранение этих документов в репозитории проекта обеспечивает их доступность и актуальность, превращая процесс документирования в полезный инструмент общения между разработчиками.

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

- ADR хранятся в репозитории рядом с кодом, синхронизируется с Git. Это позволяет отслеживать эволюцию архитектуры так же, как мы отслеживаем изменения в коде.

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

- Новый разработчик может прочитать историю ADR и за быстрее понять, почему система выглядит именно так, не отвлекая команду бесконечными вопросами.

По итогу, для системного архитектора связка «C4 Model + ADR» является эффективным стандартом документации. Так как мы получаем ответы на вопросы "Что?" и "Почему?".

ADR должен быть лаконичным и по Майклу Найгарду его структура следующая:

- Title: Краткое название решения.

- Status: Proposed, Accepted, Superceded (если решение заменено новым), Deprecated.

- Context: Какую проблему мы решаем? Какие были ограничения?

- Decision: Что именно мы делаем?

- Consequences: Что мы получили взамен? На какие компромиссы (trade-offs) пошли?

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

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

Не стоит пытаться внедрить все сразу, C4 идеален для визуализации структуры, но если в системе сложная логика взаимодействия (например, распределенные транзакции в банковском ПО), тебе придется добавить к C4 диаграммы последовательности (Sequence Diagrams) из UML - Саймон Браун сам часто это рекомендует.