7.3.Критерии качества архитектурного проекта

Архитектурный проект должен быть понятным, простым для модификации и обеспечивать высокую эффективность программно­го изделия. Эффективность определяется минимальным использова­нием имеющихся ресурсов, а простота модификации — незначи­тельными затратами на сопровождение. Для достижения этих целей обычно стремятся упростить форму и функции каждой части архи­тектурного проекта. Для измерения сложности имеется ряд метрик, которые целесообразно использовать при проектировании. Функ­циональная простота характеризуется "связностью" отдельных ком­понент, т.е. внутренней структурой компоненты. При проектирова­нии стремятся максимизировать связность каждой компоненты.

Простота формы достигается в результате:

• минимизации "сцепления" между компонентами;

• обеспечения соответствия функции, выполняемой компонен­той, уровню иерархии;

• согласования программного обеспечения со структурами дан­ных;

• максимизации числа компонент, использующих данную ком­поненту;

• ограничения числа подчиненных компонент;

• удаления дублирования между компонентами путем создания новых компонент.

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

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

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

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

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