Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Metodicheskie_ukazania_k_vypolneniyu_KP_OOP.doc
Скачиваний:
1
Добавлен:
01.07.2025
Размер:
3 Мб
Скачать
☆

5.3 Объектно-ориентированное программирование

Результатами объектно-ориентированного программирования являются диаграммы модулей и процессов в нотации Booch [2] и диаграммы пакетов, компонентов и развертывания в нотации UML [3], а также протоколы классов.

5.3.1 Диаграммы модулей

Диаграмма модулей показывает распределение классов и объектов по модулям в физическом проектировании системы. Каждая отдельная диаграмма модулей представляет некоторый ракурс структуры модулей системы. При разработке диаграмма модулей используется, чтобы показать физическое деление архитектуры по слоям и разделам [2].

Основными элементами диаграммы модулей являются модули и их зависимости. На рис. 5.22 приведены обозначения различных типов модулей. Первые три значка – это файлы, различающиеся своими функциями. Значок главной программы обозначает файл, содержащий корневую программу. В C++ это соответствовало бы некоторому файлу с расширением .cpp содержащему привилегированную функцию-неэлемент, называемую main. Обычно существует ровно один такой модуль на программу. Значок описания и значок тела обозначают файлы, которые содержат, соответственно, описания и реализации. В C++, например, модуль описаний соответствует заголовочному файлу с расширением .h, а модуль тела – файлу с текстом программы с расширением .cpp.

Рисунок 5.22 – Значки модулей и подсистем

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

Единственная связь, которая может существовать между двумя модулями, – компиляционная зависимость – представляется стрелкой, выходящей из зависимого модуля. В C++ такая зависимость указывается директивой #include. В множестве компиляционных зависимостей не могут встречаться циклы. Для того чтобы избежать цикличности при компиляции взаимозависящих модулей, используется директива #pragma once, либо конструкция:

#ifndef <Literal>

#define <Literal>

#include <ModuleName>

<ModuleFirstString>

…

<ModuleLastString>

#endif

Чтобы определить частичную упорядоченность компиляций, достаточно выполнить частичное упорядочение структуры модулей системы.

Большие системы могут быть разложены на несколько сотен, если не тысяч, модулей. Пытаться разобраться в физической архитектуре такой системы без ее дополнительного структурирования почти безнадежно. На практике разработчики стремятся следовать неформальному соглашению собирать связанные между собой модули в структуры типа каталогов. По этим соображениям вводится понятие подсистемы на диаграмме модулей. Подсистемы представляют собой совокупности логически связанных модулей. В языке C++ объединение нескольких модулей в подсистему осуществляется их логическим заключением в единое пространство имен (namespace).

Подсистемы служат частями физической модели системы. Подсистема – это агрегат, содержащий другие модули и другие подсистемы. Каждый модуль в системе должен жить в одной подсистеме или находиться на самом верхнем уровне.

На рис. 5.22 показано обозначение подсистемы. Как и модуль, подсистема должна быть именованной. Имена подсистем подчиняются тем же правилам, что и имена модулей, хотя полное имя подсистемы обычно не содержит суффиксов.

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

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

Пример. Диаграмма модулей.

На рисунке 5.23 приведен пример построения диаграммы модулей ПрО «Микроволновая печь». Имеется главный модуль Imitation.cpp, содержащий функцию main. На каждый класс ПрО заведено по два модуля: один (*.h) для протокола класса, второй (*.cpp) для его реализации.

Рисунок 5.23 – Диаграмма модулей