Про архитектурные характеристики из книги “Fundamentals of Software Architecture”

Сегодня я участвовал во встрече книжного клуба { между скобок }, на которой мы разбирали четвертую главу книги “Fundamentals of Software Architecture”, в которой Mark Richards и Neal Ford рассказывали о характеристиках, выяснение которых обычно ложится на плечи людей, исполняющих роли архитекторов, так как бизнес сам про этот вид требований вспоминает нечасто.

Рис.1 “Заставка выпуска”

Fundamentals of Software Architecture

Авторы книги стартуют с места в карьер и рассказывают о том, что обычно такие требования называют нефункциональными требованиями (nonfunctional requirements), но этот термин им не нравится так как он — самоуничижительный. Дальше они вспоминают про атрибуты качества (quality attributes), но их и этот вариант не устраивает из-за перекоса в сторону проверки пост-фактум. И они останавливаются на термине архитектурные характеристики (architecture characteristics), который достаточно хорош для описания критических моментов, которые влияют на архитектуру.

Рис.2 “Architecture characteristics vs another terms”

Дальше авторы показывают, что эти характеристики удовлетворяют трем критериям, которые

— Specifies a nondomain design consideration
— Influences some structural aspect of the design
— Is critical or important to application success

Эти критерии детализированы на рисунке ниже

Рис.3 “The differentiating features of architecture characteristics”

Дальше авторы приводят списки характеристик для примера, которые сгруппированы по трем темам: операционные, структурные, сквозные

Рис.4 “Architecture characteristics”

Дальше авторы рассказали, что эти характеристики не общеприняты по индустрии и привели в качестве примера стандарт ISO/IEC 25010, в котором заданы восемь quality characteristics

Рис.5 “Quality characteristics из стандарта ISO/IEC 25010”

Причем параметры про functional часть авторы считают не относящимися к списку architecture characteristics

— Functional completeness
— Functional correctness
— Functional appropriateness

Ну и заканчивают авторы свою главу обсуждением trade-off для баланса архитектурных характеристик, но делают они это достаточно просто. Гораздо интереснее про это рассказано в книге “Software Architecture for Busy Developers”.

Software Architecture for Busy Developers

Здесь автор дает введение в Architecture Tradeoff Analysis Method (ATAM) и как его можно использовать для анализа архитектурных компромиссов. В этом методе у нас есть два вида пригодности системы:

• Fit for purpose — система соответствует функциональным требованиям и соответствует назначению
• Fit for use — работает надежно и пригодна для использования

В попытке удовлетворить эти запросы обычно и требуется идти на архитектурные компромиссы, но … делать это стоит проведя тщательный анализ, который включает изучения влияния наших решений на quality attributes (атрибуты качества) системы.

Рис.6 “ATAM — Architecture Tradeoff Analysis Method”

ATAM (Architecture Tradeoff Analysis Method) содержит следующие основные моменты

Рис.7 “The most important concerns of ATAM”

Если говорить на пальцах, то

• Sensitivity points —это решения которые влияют только на один атрибут
• Trade-off points — это архитектурные решения, которые влияют на несколько атрибутов и обычно при выборе мы жертвуем одним из них в пользу другого
• Risks и Non-risks — это риски и возможности от архитектурных решений

В этом методе много говорится про влияние на атрибуты качества системы, но как понять а какие атрибуты качества важны для нас. Один из вариантов — это стартануть с того, чтобы понять какие SLA у нашей системы, например, очень важно понять какие RTO и RPO. Другие важные параметры — это желаемая скорость поставки фич на рынок (TTM) и ожидания по совокупной стоимости владения решением (TCO).

Рис.8 “Exploring quality attributes”

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

Get Alexander Polomodov’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

На самом деле ATAM (Architecture Tradeoff Analysis Method) позволяет работать в рамках трех сценариев, из которых вариант с use cases является основным. В нем описываются основные сценарии, а дальше ожидания от желаемой архитектуры.

Рис.9 “Scenarios of ATAM”

Зачастую это описание ожиданий в рамках сценариев можно сделать в виде Utility Tree, как показано на примере ниже, где проектировалась система для загрузки и дальнейшей обработки данных (подробности рекомендую изучить в оригинальной книге).

Рис.10 “Utility trees”

На этом краткое введение в ATAM в этой книге заканчивается.

Интересно еще глянуть как про это пишут ребята из Google в книге “Building Secure and Reliable Systems”

Building Secure and Reliable Systems

Четвертая глава называется “Design Tradeoffs” и в ней авторы рассказывают про компромиссы. Интересно, что авторы подсвечивают, что нефункциональные требования можно рассматривать шире, чем обычно, например, включать туда эффективность и скорость разработки.

Рис.11 “Requirements”

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

Дальше авторы рассказывают, что

Google uses a design document template to guide new feature design and to collect feedback from stakeholders before starting an engineering project.

И потом приводят в пример ту часть Google’s Design Document Template, которая относится к вопросам надежности и безопасности.

Рис.12 “Google’s Design Document Template (reliability- and security-related sections)”

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

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

Рис.13 “Design Principles from “Building Secure and Reliable Systems””

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

P.S.

Запись выпуска доступна здесь