Основы программирования

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

 

В классическом методе Л. Констентайна и Э. Йордана определены шесть типов сцепления, которые ориентированы на процедурное проектирование [77].

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

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

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

Рассмотрим объектно-ориентированные метрики сцепления, предложенные М. Хитцем и Б. Монтазери [38].

Зависимость изменения между классами

 

Зависимость изменения между классами CDBC (Change Dependency Between Classes) определяет потенциальный объем изменений, необходимых после модификации класса-сервера SC (server class) на этапе сопровождения. До тех пор, пока реальное количество необходимых изменений класса-клиента СС (client class) неизвестно, CDBC указывает количество методов, на которые влияет изменение SC.

CDBC зависит от:

q       области видимости изменяемого класса-сервера внутри класса-клиента (определяется типом отношения между CS и СС);

q       вида доступа СС к CS (интерфейсный доступ или доступ реализации).

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

Таблица 14.3. Вклад отношений между клиентом и сервером в зависимость изменения

Тип отношения

SC не используется классом СС

SC — класс экземплярной переменной в классе СС

Локальные переменные типа SC используются внутри /-методов класса СС

SC является суперклассом СС

SC является типом параметра для/-методов класса СС

СС имеет доступ к глобальной переменной класса SC

0

n

j

n

j

n

 

Конечно, здесь предполагается, что те элементы класса-сервера SC, которые доступны классу-клиенту СС, являются предметом изменений. Авторы исходят из следующей точки зрения: если класс SC является «зрелой» абстракцией, то предполагается, что его интерфейс более стабилен, чем его реализация. Таким образом, многие изменения в реализации SC могут выполняться без влияния на его интерфейс. Поэтому вводится фактор стабильности интерфейса для класса-сервера, он обозначается как к (0 < k < 1). Вклад доступа к интерфейсу в зависимость изменения можно учесть умножением на (1 - k).

Метрика для вычисления степени CDBC имеет вид:

;

CDBC(CC, SC) = min(n, A).

Пути минимизации CDBC:

1) ограничение доступа к интерфейсу класса-сервера;

2) ограничение видимости классов-серверов (спецификаторами доступа public, protected, private).



 
продажа срубов из оцилиндрованного бревна