Виды деятельности
7.2.1. Конструирование физической модели
Разработчик должен сконструировать физическую модель, описывающую проект программного изделия в терминах программной обстановки. Физическая модель должна быть выведена из логической модели, описанной в Требованиях к программному изделию. При трансформации логической модели в физическую принимаются проектные решения, связанные с распределением функций по компонентам и определением входов и выходов каждой компоненты. Проектные решения также должны удовлетворять и нефункциональные требования, соответствовать критериям качества проекта и соображениям технологической реализуемости. Все проектные решения должны фиксироваться документально.
Моделирование — итеративный процесс. После описания каждой части проекта необходимо возвращаться к описанию предыдущих частей, пока не будет достигнуто ясное и точное описание каждой компоненты. Для построения модели в последние годы стали использоваться средства автоматизации, позволяющие получить непротиворечивую, более простую модель для конструирования и модификации.
7.2.2. Декомпозиция программного изделия на компоненты
Программное изделие должно быть представлено в виде иерархии компонент в соответствии с методами функциональной декомпозиции, а все компоненты — располагаться по уровням иерархии, и каждая компонента при этом — занимать точно определенное место. Функциональная декомпозиция осуществляется с помощью метода нисходящего проектирования. Как уже отмечалось, нисходящая декомпозиция является важным средством для управления сложностью. Кроме этого, она реализует принцип "сокрытия информации", требуя, чтобы компоненты нижнего уровня рассматривались как "черные ящики" для компонент более высокого уровня. Следовательно, для верхнего уровня известны только функции и интерфейсы компонент более низкого уровня, а особенности их внутреннего функционирования остаются неизвестными. Нисходящее проектирование также требует, чтобы каждый уровень проекта был описан с использованием терминов, отражающих степень абстракции, соответствующую данному уровню.
Компоненты нижнего уровня проекта должны быть достаточно независимы, чтобы обеспечивать проведение независимого и параллельного дальнейшего их детального проектирования и кодирования с минимальными взаимосвязями между программистами.
Документ Требования к программному изделию содержит множество групп нефункциональных требований, поэтому проектирование каждой компоненты должно включать ее анализ с точки зрения выполнения требований всех групп. Однако здесь следует помнить, что к разным компонентам могут иметь отношение лишь некоторые из групп требований.