За определение архитектурного проекта несут ответственность инженеры -разработчики программного обеспечения. Во время выполнения работ они могут консультироваться с другими специалистами и представителями заказчика, а опера-
18
ционный персонал должен провести обзор архитектурного проекта. Выходным результатом этой фазы является документ «Архитектурный проект», который должен документировать каждую компоненту программного изделия и ее связи с другими компонентами. Документ считается завершенным, когда уровень описания компонент и их интерфейсов достаточен для того, чтобы над каждой из них могли независимо работать отдельные исполнители или их небольшие группы во время следующей фазы детального проектирования.
Рассматриваемая фаза ЖЦПИ заканчивается формальным утверждением документа «Архитектурный проект» после всестороннего его рассмотрения и критического обзора.
Деятельность на этой фазе выполняется в соответствии с планами, разработанными на предыдущей фазе. Основным видом деятельности во время этой фазы является разработка и документирование архитектурного проекта. Эта деятельность включает:
- конструирование физической модели программного изделия;
- описание требований к архитектурному проекту;
- выбор языка программирования;
- обзор проекта.
1.5.2. Конструирование физической модели
Разработчик должен сконструировать физическую модель, описывающую проект программного изделия, используя терминологию разработчика. Физическая модель должна быть выведена из логической модели, описанной в «Требованиях к программному изделию». При трансформации логической модели в физическую принимаются проектные решения, связанные с распределением функций по компонентам и определением входов и выходов каждой компоненты. Проектные решения также должны удовлетворять и нефункциональным требованиям, критериям качества проекта и соображениям технологической реализуемости. Все проектные решения должны фиксироваться документально.
Моделирование - это итеративный процесс. Необходимо после описания каждой части проекта повторно возвращаться к описанию предыдущих частей, пока не будет достигнуто ясного и точного описания каждой компоненты. Для построения модели в последние годы стали использоваться средства автоматизации, позволяющие получить непротиворечивую модель более простую для конструирования и модификации.
1.5.3. Декомпозиция программного изделия на компоненты
Программное изделие должно быть представлено в виде иерархии компонент в соответствии с методами функциональной декомпозиции. Все компоненты должны располагаться по уровням иерархии и каждая компонента при этом должна занимать точно определенное место. Функциональная декомпозиция осуществляется с помощью метода нисходящего проектирования. Как уже отмечалось, нисходящая декомпозиция является важным средством для управления сложностью. Кроме этого, она реализует принцип "сокрытия информации", требуя, чтобы компоненты нижнего уровня рассматривались как "черные ящики" для компонент более высокого уровня. Это означает, что для верхнего уровня известны только функции и интерфейсы компонент более низкого уровня, а особенности их внутреннего функционирования остаются неизвестными. Нисходящее проектирование также требует, чтобы каждый уровень проекта был описан с использованием терминов, отражающих степень абстракции, соответствующую данному уровню.
Компоненты нижнего уровня проекта должны быть достаточно независимы, чтобы дать возможность проводить независимое и параллельное их дальнейшее
19
детальное проектирование и кодирование с минимальными взаимосвязями между программистами.
Документ «Требования к программному изделию» содержит множество групп нефункциональных требований, поэтому проектирование каждой компоненты должно включать ее анализ с точки зрения требований каждой из этих групп. Однако при этом следует учитывать, что к разным компонентам могут иметь отношение лишь некоторые из этих групп.
1.5.4. Критерии качества архитектурного проекта
Архитектурный проект должен быть понятным, простым для модификации и обеспечивать высокую эффективность программного изделия. Эффективность определяется минимальным использованием имеющихся ресурсов, а простота модификации - снижением затрат на сопровождение. Для достижения этих целей обычно стремятся упрощать форму и функции каждой части архитектурного проекта. Для измерения сложности имеется ряд метрик, которые целесообразно использовать при проектировании. Функциональная простота характеризуется "связностью" отдельных компонент, т,е, внутренней структурой компоненты. При проектировании стремятся максимизировать связность каждой компоненты.
Простота формы достигается в результате:
- минимизация "сцепления" между компонентами;
- обеспечения соответствия функции, выполняемой компонентой, уровню ие
рархии;
- согласования программного обеспечения со структурами данных;
- максимизации числа компонент, использующих данную компоненту;
- ограничения числа подчиненных компонент;
- удаления дублирования между компонентами путем создания новых компо
нент.
Архитектурный проект должен быть модульным с минимальным сцеплением между компонентами и с максимальной связностью внутри каждой компоненты. Компоненты модульной схемы должны описываться как "черные ящики", скрывая информацию о их внутренней структуре от других компонент. Важно знать, что они делают, а не как они работают.
Для упрощения понимания при описании проектов всегда должны использоваться стандарты и соответствующая терминология, для решения одинаковых проблем всегда должны использоваться одинаковые решения. Для достижения единообразия и сопоставимости описаний разных частей проекта необходимо использовать стандарты на проектирование, СА8Е-средства и систематические обзоры проектных решений.
Выбор альтернативных решений может явиться хорошим и эффективным средством повышения качества проекта. Для выбора лучшего варианта необходимы соответствующие критерии, которые зависят от типа системы. Например, для системы реального времени важным является время ответа или время реакции системы, а для административной системы - стабильность базы данных. Для оценки альтернативных вариантов или для проверки сделанных допущений может использоваться прототип изделия. Например, для достижения высокой оперативности системы могут быть запрограммированы разные методы доступа к файлам базы данных, а разные методы могут привести к разным подходам в проектировании. Поэтому создание прототипов может оказаться частью процесса проектирования.
Документ «Архитектурный проект» программного изделия является ключевым документом, суммирующим все принятые решения. Он является основой для детального проектирования. Кроме описания всех компонент изделия, он должен содержать ссылки на все внешние интерфейсы. Одним из основных требований к до-
, 20
кументу является требование полноты охвата всех требований к программному изделию, представленных в предыдущем документе. Для демонстрации полноты в документ должна быть включена таблица перекрестных ссылок между требованиями к программному изделию и компонентами архитектурного проекта. Документ должен быть непротиворечивым, в достижении этого требования могут помочь методы и средства программотехники. Документ «Архитектурный проект» должен быть достаточно детальным, чтобы позволить управленцу составить план следующей фазы проектирования. Степень детализации на уровне архитектурного проекта должна также обеспечивать возможность более точной оценки стоимости работ последующих фаз разработки программного изделия.
1.6. Детальное проектирование и изготовление программного изделия
1.6.1. Основные виды деятельности
Фаза детального проектирования и изготовления может быть названа "фазой реализации" в ЖЦПИ. Цель этой фазы - детализация проекта, описанного в предыдущем документе, она включает кодирование, тестирование и документирование. Ответственными за выполнение работ в этой фазе являются программисты, специалисты другого профиля подключаются для консультаций. Верификация программного изделия может проводиться независимо специалистами, не принимавшими участия в разработке.
До начала кодирования (написания программ) важно рассмотреть адекватность и достаточность для разработки компьютерных ресурсов. Нельзя также говорить о начале кодирования, если отсутствует операционная система и системные программы для ЭВМ. Производительность труда программистов может существенно упасть, если ресурсов окажется недостаточно.
Деятельность во время этой фазы должна выполняться в соответствии с планом, принятым на предыдущей фазе. Выполнение пунктов плана должно тщательно отслеживаться и документироваться.
Детальное проектирование и изготовление программного изделия должно основываться на следующих трех принципах:
- нисходящая декомпозиция;
- структурное программирование;
-одновременное изготовление и документирование.
Эти принципы должны находить отражение как в проекте программного изделия, так и в организации работ. Их использование помогает своевременному выполнению работ и соблюдению бюджетных расходов. Они оказывают положительное влияние и на качество программного изделия, на его надежность и пригодность к сопровождению.
Нисходящая декомпозиция жизненно важна для управления сложностью и для реализации принципа "сокрытия информации".