Разработка сложных программных изделий


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


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

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

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

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

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

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

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



Содержание раздела