А.3.2.3.3. Объектно-ориентированная спецификация проекта

Одним из аспектов парадигмы объектно-ориентированного проектирования является наличие тесных взаимосвязей между фазами жизненного цикла. Проектируемые элементы на уровне определения требований следует в идеале реализовать с мощностью 1:1. Для этого существует ряд методов, один из которых — экспресс-создание прототипов. Тем не менее фазовые концепции характерны даже для объектно-ориентированного проектирования. Однако границы между определением требований, спецификацией проекта и описанием реализации не являются жесткими. Поскольку эти методы моделирования вышли из недр объектно-ориентированного программирования, они в значительной мере аналогичны описанию реализации. В свете этого в некоторых работах (например: Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 66) предлагается использование диаграмм взаимодействия только на уровне определения требований (фаза анализа), тогда как за спецификацией проекта (фаза проектирования) уже закреплены диаграммы классов, последовательностей и состояний. Другие авторы применяют одни и те же методы и диаграммы на обоих уровнях с той лишь разницей, что на стадии спецификации проекта их описание подвергается дальнейшей детализации.

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

А.3.2.3.3.1. Общая детализация

Мы можем разграничить внутренние методы и методы, доступные извне.

Определяются типы атрибутов классов с техническими свойствами, такими как гарантии, начальные значения и параметры (см. рис. 125). Гарантиями называются условия, которым должны удовлетворять объекты. Параметры в операциях указывают, для каких критериев возможен перенос значений после запуска операций. В примере на рис. 125 очевидно представлено, что атрибут «радиус» не должен быть отрицательным (гарантия), центральная точка по умолчанию имеет начальное значение х = 10, у = 10, а окружностью можно манипулировать (если она не отцентрирована на экране) путем изменения координат (положения) центральной точки или ввода новых параметров для создания других радиуса.

Рис. 125. Технические свойства атрибутов (Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 36)

Динамическое поведение объектов в течение их жизненного цикла можно дифференцировать при помощи диаграмм состояний, последовательностей и действий.

Термины «программы» и «модули» также используются в объектно-ориентированном системном проектировании; здесь модули содержат код классов, которые им присваиваются, или же связываются с файлами исходного кода и файлами трансляции.

Модули и их взаимосвязи отображаются компонентными диаграммами. Чаще всего их метаструктуры совпадают с метаструктурой отображения модулей. Управление версиями в значительной степени зависит от описания компонентов или модулей.

Термин «пакет» выполняет аналогичную функцию применительно к группировке элементов объектно-ориентированного описания. Пакеты не содержат физических кодов, а лишь объединяют элементы моделирования. Иногда термины «пакет» и «модуль» используются как синонимы.

Модули и пакеты являются компонентами UML и описываются с помощью компонентных диаграмм (см. рис. 126).

Рис. 126. Компонентная диаграмма UML