Глава 7. Архитектурное проектирование программного изделия

7.1. Общее содержание работ фазы

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

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

Рассматриваемая фаза ЖЦПИ заканчивается формальным ут­верждением документа Архитектурный проект после всестороннего его рассмотрения и критического обзора.

Работы на этой фазе выполняются в соответствии с планами, разработанными на предыдущей фазе, и направлены на создание и документирование архитектурного проекта- Сюда входят:

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

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

• выбор языка программирования;

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

Виды деятельности

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

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

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

 

7.2.2. Декомпозиция программного изделия на компоненты

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

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

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