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

Помимо атрибутов качества системы и атрибутов качества, связанных с экономической ситуацией, существуют атрибуты качества, имеющие непосредственное отношение к характеру самой архитектуры; их реализация не менее важна. Мы поговорим о трех таких атрибутах качества и, как и раньше, оставим составление конкретных сценариев на вашей совести — соответствующее задание сформулировано в разделе «Дискуссионные вопросы».

Концептуальная целостность — это фундаментальная идея, или представление, которое объединяет проектное решение системы на всех его уровнях. Одни и те же задачи архитектура должна выполнять одними и теми же способами. Особое внимание на концептуальную целостность системы обращает, в частности, Фред Брукс (Fred Brooks) — по его мнению, без этого система обречена на провал:

Я продолжаю утверждать, что концептуальная целостность есть наиболее важный из всех факторов проектирования системы. Пусть лучше в системе не будет каких- то необычных функций и исправлений, но она должна выражать единый набор конструкторских решений — это значительно полезнее, чем нагромождать большое количество самостоятельных и не связанных друг с другом идеи. [ Brooks 75]

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

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

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

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

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

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

Заключение

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

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

Дополнительная литература

Обзор общих сценариев и отображения сценариев, выявленных в ходе оценки архитектуры, на общие сценарии содержится в издании [Bass 01Ь]. Детальные исследования готовности опубликованы в работах [Laprie 89] и [Cristian 93). Вопросы безопасности рассматриваются в публикации [Ramachandran 02]. Взаимоотношениям между практичностью и программной архитектурой посвящены исследования [Gram 96] и [Bass 01а].

В издании [McGregor 01] приводится анализ контролепригодности. [Paulish 02] рассматривает процент стоимости разработки, связанной с тестированием.

Общепризнанные определения атрибутов качества содержатся в стандартах IEEE [ISO 91]. [Witt 94] обсуждает желательные атрибуты качества архитектуры (и архитекторов).

Дискуссионные вопросы

1. Каковы важнейшие атрибуты качества системы, над которой вы в данный момент работаете? Как выглядят системно-ориентированные сценарии, в которых эти атрибуты качества зафиксированы, и общие сценарии, из которых они произведены?

2. Брукс утверждает, что концептуальная целостность есть ключ к созданию успешных систем. Вы с ним согласны? Можете ли вы привести успешные системы, которые обходились без этого атрибута качества? Если таковые имеются, то за счет каких факторов они стали успешными? Как можно оценить систему на предмет ее соответствия заветам Брукса?

3. Составьте сценарии коммерческих и архитектурных атрибутов качества, приведенных в разделах 4.4 и 4.5. Учли ли вы в своих сценариях все эти атрибуты качества? Какие из них труднее всего зафиксировать при помощи сценариев?