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

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

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

♦ Модифицируемость определяется тем, каким образом происходит разделение функциональности (архитектурный аспект) и методик кодирования в рамках отдельного модуля (неархитектурный аспект). Так, назвать систему модифицируемой можно лишь в том случае, если для внесения изменений требуется наименьшее количество отдельных элементов. Именно на этом строится структура декомпозиции модулей системы А-7Е, описанной в главе 3. Чем менее структурирован код, тем хуже система поддается модифицированию.

♦ Производительность также зависит от архитектурных и неархитектурных факторов. Отчасти она зависит от объема информации, передающейся между компонентами (это архитектурный аспект), от распределения функциональности между компонентами (архитектурный аспект), распределения совместно используемых ресурсов (архитектурный аспект), выбранных для реализации функциональности алгоритмов (неархитектурный аспект) и кодирования этих алгоритмов (также неархитектурный аспект).

В этом разделе мы хотим сделать упор на двух моментах:

1. Архитектура определяет возможность реализации предполагаемых атрибутов качества системы; проектирование и оценку этих атрибутов следует проводить на архитектурном уровне.

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

Реализовать ряд атрибутов качества по отдельности в сложной системе невозможно. Реализация одного такого атрибута всегда каким-то образом ~ иногда положительно, а иногда и отрицательно — влияет на реализацию других. К примеру, такие атрибуты качества, как безопасность и надежность, обычно конфликтуют между собой. У самой защищенной системы наименьшее количество точек отказа — как правило, они концентрируются в ядре безопасности. У самой надежной системы их, напротив, наибольшее количество — как правило, :ло ряд резервируемых процессов или процессоров, причем отказ одного из них не приводит к отказу системы в целом. Другой пример конфликта между атрибутами качества очевиден — практически любой атрибут качества негативно отражается на производительности. Взять хотя бы переносимость. Лучший способ обеспечить переносимость программного продукта — это изолировать системные зависимости. Такое решение увеличивает непроизводительные издержки в ходе исполнения системы (обычно на границах процессов или процедур), а следовательно, снижает производительность.

Теперь приступим к обзору атрибутов качества. Они делятся на три класса:

1. Атрибуты качества системы. Из них мы рассмотрим готовность, модифицируемость, производительность, безопасность, контролепригодность и практичность.

2. Коммерческие атрибуты качества (например, срок вывода продукта на рынок), реализация которых обусловливается архитектурой.

3. Атрибуты качества самой архитектуры (например, концептуальная целостность), которые косвенно влияют на другие качества — например, модифицируемость.