Глава 4

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

(в соавторстве с Феликсом Бахманом и Марком Кляйном)

— Котик! Чешик! . Скажите, пожалуйста, куда мне отсюда идти?

— А куда ты хочешь попасть? — ответил Кот.

— Мне все равно... — сказала Алиса

— Тогда все равно, куда и идти, заметил Кот.

— ...только бы попасть куда-нибудь., пояснила Алиса.

— Куда-нибудь ты обязательно попадешь, — сказал Кот. — Нужно только достаточно долю идти

Льюс Кэррол «Алиса в стране чудес»

Архитектурно-экономический цикл убеждает нас в том, что требования по качеству к системной архитектуре определяются коммерческими мотивами. Подобного рода атрибуты качества сопровождают основные требования по функциональности — формулировки возможностей и поведения системы, а также предоставляемых ею услуг. Несмотря на явное сходство функциональности с другими атрибутами качества, она занимает в схеме разработки центральное, а иногда и единоличное, положение, и в этом у вас еще будет возможность убедиться. Мы считаем, что такой подход недальновиден. Причины переработки систем часто кроются не в недостатке функциональности — по этому показателю новые элементы как раз ничем не отличаются от старых, а в трудностях сопровождения, переноса, масштабирования, низкой производительности иди противостояния сетевым атакам. В главе 2 мы говорили о том, что формирование архитектуры — это первый этап процесса создания программного продукта, на котором основное внимание следует уделять требованиям по качеству. Функциональность системы здесь отображается на программные структуры, от которых и зависит, сможет ли архитектура обеспечить наличие в системе необходимых атрибутов качества. В главе 5 мы обсудим влияние на реализацию качества архитектурно-проектных решений, а в главе 7 — стратегию компромиссных решений, с необходимостью принятия которых постоянно сталкиваются архитекторы.

Пока что мы намерены рассмотреть вопрос выражения атрибутов качества, наличие которых в предполагаемой системе или системах должна обеспечить разрабатываемая архитектура. Анализ отношений между программной архитектурой и атрибутами качества начнем с подробного описания последних. Что имеется в виду, когда систему называют, скажем, модифицируемой, надежной или защищенной? Характеристики подобных свойств и методика формулирования требований по качеству к системе — вот о чем мы будем говорить ниже.

4.1. Функциональность и архитектура

функциональность и атрибуты качества ортогональны. Это утверждение, которое поначалу может показаться излишне смелым, на самом деле совершенно справедливо — по-другому просто не может быть. Если бы функциональность и атрибуты качества не были ортогональны, уровень защиты, производительности, готовности или практичности определялся бы выбранной функцией. Очевидно, что устанавливать нужный уровень этих характеристик можно произвольно. Мы не имеем в виду, что любая функция дает возможность реализовать любой атрибут качества на любом уровне. Операции обработки сложных графических данных или сортировки огромной базы данных сложны по определению и, следовательно, не позволяют достичь молниеносной производительности. Сомнению не подлежит лишь то, что в отношении любой из этих функций относительный уровень качества определяется решениями, которые принимает архитектор. Некоторые архитектурные решения способствуют повышению производительности, иные же приводят к обратному эффекту. В этом контексте целью настоящей главы, как и любой хорошей архитектуры, является разделение задач. Мы разберем все важные атрибуты качества по порядку и покажем, как их структурировать.

Что такое функциональность? Это способность системы выполнять те задачи, которые на нее возложены. Для выполнения любой задачи элементы системы — все или некоторые — должны работать согласованно; аналогичным образом в ходе строительства дома взаимодействуют монтажники, электрики, кровельщики, штукатуры, маляры и отделочники. Таким образом, если обязанности между элементами распределены неправильно или если у них нет средств координации с другими элементами (они требуются для того, чтобы элементы могли своевременно приступать к исполнению своих обязанностей), система не сможет обеспечить надлежащую функциональность.

Для обеспечения функциональности существует множество разных структур. Если бы функциональность была единственным требованием, систему можно было бы организовать в виде единичного монолитного модуля безо всякой внутренней структуры. В действительности системы разлагаются на модули, которые делают ее более понятной и поддерживают решение ряда других задач. Функциональность, таким образом, не сильно зависит от структуры. Когда существенную роль начинают играть другие атрибуты качества, программная архитектура ограничивает распространение функциональности по структурам. К примеру, но многих случаях декомпозиция структур проводится таким образом, чтобы их конструированием могли заниматься сразу несколько специалистов (помимо прочего, такое решение оптимизирует срок выхода продукта на рынок, хотя в этом ключе оно рассматривается весьма редко). Очень важно, как функциональное! ь пересекается с другими атрибутами качества и одновременно ограничивает их.