Всё для программиста

Модели реализации объектно-ориентированных программных систем
Индекс материала
Модели реализации объектно-ориентированных программных систем
Интерфейсы
Компоновка системы
Разновидности компонентов
Моделирование программного текста системы
Основы компонентной объектной модели
Организация интерфейса СОМ
Реализация интерфейса
Серверы СОМ-объектов
Работа с СОМ-объектами
Повторное использование СОМ-объектов
IDL-описаниеи библиотека типа
Диаграммы размещения
Использование диаграмм размещения
Метрики объектно-ориентированных программных систем
Информационная закрытость
Связность объектов
Метрики связности по данным
Метрики связности по методам
Сцепление объектов
Локальность данных
Метрики, ориентированные на классы
Операционно-ориентированные метрики
Метрики для ОО-проектов
Метрики инкапсуляции
Метрики полиморфизма
Все страницы

ГЛАВА 13. Модели реализации объектно-ориентированных программных систем

 

Статические и динамические модели описывают логическую организацию системы, отражают логический мир программного приложения. Модели реализации обеспечивают представление системы в физическом мире, рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах [8], [23], [53], [67].

Компонентные диаграммы

 

Компонентная диаграмма — первая из двух разновидностей диаграмм реализации, моделирующих физические аспекты объектно-ориентированных систем. Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами.

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

Компоненты

 

По своей сути компонент является физическим фрагментом реализации системы, который заключает в себе программный код (исходный, двоичный, исполняемый), сценарные описания или наборы команд операционной системз (имеются в виду командные файлы). Язык UML дает следующее определение.

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

Интерфейс — очень важная часть понятия «компонент», его мы обсудим в следующем подразделе. Графически компонент изображается как прямоугольник с вкладками, обычно включающий имя (рис. 13.1).

 

Рис. 13.1. Обозначение компонента

 

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

Сходные характеристики компонента и класса:

q       наличие имени;

q       реализация набора интерфейсов;

q       участие в отношениях зависимости;

q       возможность быть вложенным;

q       наличие экземпляров (экземпляры компонентов можно использовать только в диаграммах размещения).

Вы скажете — много общего. И тем не менее между компонентами и классами есть существенная разница, ее характеризует табл. 13.1.

Таблица 13.1. Различия компонентов и классов

Описание

1

 

 

2

 

3

Классы — логические абстракции, компоненты — физические предметы, которые живут в мире битов. В частности, компоненты могут «жить» в физических узлах, а классы лишены такой возможности

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

Классы имеют свойства и операции. Компоненты имеют только операции, которые доступны через их интерфейсы

 

Рис. 13.2. Классы в компоненте

 

О чем говорят эти различия? Во-первых, класс не может «дышать» воздухом физического мира реализации. Ему нужен скафандр. Таким скафандром является компонент.

Во-вторых, им не жить друг без друга — пустые скафандры никому не нужны. Причем в скафандре-компоненте может находиться несколько классов и коопераций. Итак, в скафандре — физической реализации — располагается набор логики. Как показано на рис. 13.2, с помощью отношения зависимости можно явно отобразить отношение между компонентом и классами, которые он реализует. Правда, чаще всего такие отношения не отображаются. Их удобно представлять в компонентной спецификации.

В-третьих, класс — душа нараспашку (он может даже показать свои свойства). Компонент всегда застегнут на все пуговицы (правда, из него торчат интерфейсные разъемы операций).

Теперь уместно перейти к обсуждению интерфейсов.