11. Архитектурное проектирование программного продукта

Фаза архитектурного проектирования может быть названа фазой «принятия решения». Цель этой фазы – определить совокупность компонент программного продукта и их интерфейсы, чтобы дать каркас для последующей разработки программного продукта. Архитектурный проект должен охватывать все требования, сформулированные на предыдущей фазе.

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

• конструирование физической модели программного продукта;

• описание требований к архитектурному проекту;

• выбор среды программирования;

• обзор проекта.

2. Конструирование физической модели

Разработчик должен сконструировать физическую модель, описывающую проект программного продукта, используя терминологию разработчика. Физическая модель должна быть выведена из логической модели, описанной в «Требованиях к программному продукту». При трансформации логической модели в физическую принимаются проектные решения, связанные с распределением функций по компонентам и определением входов и выходов каждой компоненты. Проектные решения также должны удовлетворять и нефункциональным требованиям, критериям качества проекта и соображениям технологической реализуемости. Все проектные решения должны фиксироваться документально.

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

3. Детальное проектирование и изготовление программного продукта

Фаза детального проектирования и изготовления может быть названа «фазой реализации» в ЖЦ ИС. Цель этой фазы – детализация проекта, описанного в преды­дущем документе, она включает кодирование, тестирование и документирование. Верификация программного продукта может проводиться независимо специалистами, не принимавшими участия в разработке.

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

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

• нисходящая декомпозиция;

• структурное программирование;

• одновременное изготовление и документирование.

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

Нисходящая декомпозиция жизненно важна для управления сложностью и для реализации принципа «сокрытия информации».

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

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