А.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
Дата добавления: 2019-02-26; просмотров: 142; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!