Cтруктурирование проблемы на отдельные компоненты и обеспечение способов их взаимодействия определяют понятность и "прозрачность" описания требований, полученных в результате процесса анализа.
Типы составляющих компонентов и правила их композиции определяются в программной инженерии как архитектура системы. Процесс декомпозиции проблемы, определяющей архитектуру системы, называют парадигмой программирования,
базирующейся на двух широко распространенных моделях: функции-данные и объектная модель.
Модель функции-данные исторически появилась первой. Согласно этой модели проблема декомпозируется на последовательность функций и обрабатываемых с их помощью данных. Элементами композиции служат данные и функции над ними, их представления должны быть согласованы между собой. Если изменяются некоторые данные, то пересматриваются функции, которые их обрабатывают, и определяются пути их изменений. Т.е. внесение локальных изменений в постановку проблемы требует ревизии всех данных и функций для подтверждения того, что на них не повлияли внесенные изменения.
Объектно-ориентированный подход к разработке программных систем такого недостатка не имеет. В нем общее видение решения проблемы формирования требований осуществляется исходя из следующих постулатов:
– мир составляют объекты, которые взаимодействуют между собой;
– каждому объекту присущ определенный состав свойств или атрибутов, который определяется своим именем и значениями;
– объекты могут вступать в отношения друг с другом;
– значения атрибутов и отношения могут с течением времени изменяться;
– совокупность значений атрибутов конкретного объекта в определенный момент времени определяет его состояние;
– совокупность состояний объектов определяет состояние мира объектов;
– мир и его объекты могут находиться в разных состояниях и порождать некоторые события;
– события могут быть причиною других событий или изменений состояний.