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

Методы анализа - Сцепление модулей
Индекс материала
Методы анализа
Описание потоков данных и процессов
Описание потоков данных и процессов
Методы анализа, ориентированные на структуры данных
Методика Джексона
Шаг объект-структура
Шаг начального моделирования
Контрольные вопросы
Основы проектирования программных систем
Особенности этапа проектирования
Структурирование системы
Моделирование управления
Декомпозиция подсистем на модули
Связность модуля
Функциональная связность
Коммуникативная связность
Временная связность
Связность по совпадению
Сцепление модулей
Контрольные вопросы
Классические методы проектирования
Проектирование для потока данных типа «преобразование»
Проектирование для потока данных типа «запрос»
Доопределение функций
Учет системного времени
Структурное тестирование программного обеспечения
Тестирование «черного ящика»
Потоковый граф
Цикломатическая сложность
Шаги способа тестирования базового пути
Тестирование ветвей и операторов отношений
Тестирование циклов
Неструктурированные циклы
Функциональное тестирование программного обеспечения
Способ разбиения по эквивалентности
Способ анализа граничных значений
Способ диаграмм причин-следствий
Организация процесса тестирования программного обеспечения
Тестирование интеграции
Восходящее тестирование интеграции
Системное тестирование
Стрессовое тестирование
Все страницы
Сцепление модулей

 

Сцепление (Coupling) — мера взаимозависимости модулей поданным [58], [70], [77]. Сцепление — внешняя характеристика модуля, которую желательно уменьшать.

Количественно сцепление измеряется степенью сцепления (СЦ). Выделяют 6 типов сцепления.

1. Сцепление по данным (СЦ=1). Модуль А вызывает модуль В.

Все входные и выходные параметры вызываемого модуля — простые элементы данных (рис. 4.13).

 

Рис. 4.13. Сцепление поданным

 

2. Сцепление по образцу (СЦ=3). В качестве параметров используются структуры данных (рис. 4.14).

 

Рис. 4.14. Сцепление по образцу

3. Сцепление по управлению (СЦ=4). Модуль А явно управляет функционированием модуля В (с помощью флагов или переключателей), посылая ему управляющие данные (рис. 4.15).

 

Рис. 4.15. Сцепление по управлению

4. Сцепление по внешним ссылкам (СЦ=5). Модули А и В ссылаются на один и тот же глобальный элемент данных.

5. Сцепление по общей области (СЦ=7). Модули разделяют одну и ту же глобальную структуру данных (рис. 4.16).

6. Сцепление по содержанию (СЦ=9). Один модуль прямо ссылается на содержание другого модуля (не через его точку входа). Например, коды их команд перемежаются друг с другом (рис. 4.16).

 

Рис. 4.16. Сцепление по общей области и содержанию

 

На рис. 4.16 видим, что модули В и D сцеплены по содержанию, а модули С, Е и N сцеплены по общей области.

Сложность программной системы

 

В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться различными способами.

Например, М. Холстед (1977) предложил меру длины N модуля [33]:

N » n1log2 (n1) + n2log2(n2),

где n1 — число различных операторов, п2 число различных операндов.

В качестве второй метрики М. Холстед рассматривал объем V модуля (количество символов для записи всех операторов и операндов текста программы):

V = N x log2 (n1 + n2).

Вместе с тем известно, что любая сложная система состоит из элементов и системы связей между элементами и что игнорировать внутрисистемные связи неразумно.

Том МакКейб (1976) при оценке сложности ПС предложил исходить из топологии внутренних связей [49]. Для этой цели он разработал метрику цикломатической сложности:

V(G) = E-N + 2,

где Е — количество дуг, a.N количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представляться как локальная структура, состоящая из элементов и связей между ними.

Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей, меру сложности внешних связей (между модулями) и меру сложности внутренних связей (внутри модулей) [28], [56]. Традиционно со внешними связями сопоставляют характеристику «сцепление», а с внутренними связями — характеристику «связность».

Вопросы комплексной оценки сложности обсудим в следующем разделе.

Характеристики иерархической структуры программной системы

 

Иерархическая структура программной системы — основной результат предварительного проектирования. Она определяет состав модулей ПС и управляющие отношения между модулями. В этой структуре модуль более высокого уровня (начальник) управляет модулем нижнего уровня (подчиненным).

Иерархическая структура не отражает процедурные особенности программной системы, то есть последовательность операций, их повторение, ветвления и т. д. Рассмотрим основные характеристики иерархической структуры, представленной на рис. 4.17.

 

Рис. 4.17. Иерархическая структура программной системы

 

Первичными характеристиками являются количество вершин (модулей) и количество ребер (связей между модулями). К ним добавляются две глобальные характеристики — высота и ширина:

q высота — количество уровней управления;

q ширина — максимальное из количеств модулей, размещенных на уровнях управления.

В нашем примере высота = 4, ширина = 6.

Локальными характеристиками модулей структуры являются коэффициент объединения по входу и коэффициент разветвления по выходу.

Коэффициент объединения по входу Fan_in(i) — это количество модулей, которые прямо управляют i-м модулем.

В примере для модуля n: Fan_in(n)=4.

Коэффициент разветвления по выходу Fan_out(i) — это количество модулей, которыми прямо управляет i-й модуль.

В примере для модуля m: Fan_out(m)=3.

Возникает вопрос: как оценить качество структуры? Из практики проектирования известно, что лучшее решение обеспечивается иерархической структурой в виде дерева.

Степень отличия реальной проектной структуры от дерева характеризуется невязкой структуры. Как определить невязку?

Вспомним, что полный граф (complete graph) с п вершинами имеет количество ребер

ес=n(n-1)/2,

а дерево (tree) с таким же количеством вершин — существенно меньшее количество ребер

et=n-l.

Тогда формулу невязки можно построить, сравнивая количество ребер полного графа, реального графа и дерева.

Для проектной структуры с п вершинами и е ребрами невязка определяется по выражению

.

Значение невязки лежит в диапазоне от 0 до 1. Если Nev = 0, то проектная структура является деревом, если Nev = 1, то проектная структура — полный граф.

Ясно, что невязка дает грубую оценку структуры. Для увеличения точности оценки следует применить характеристики связности и сцепления.

Хорошая структура должна иметь низкое сцепление и высокую связность.

Л. Констентайн и Э. Йордан (1979) предложили оценивать структуру с помощью коэффициентов Fan_in(i) и Fan_out(i) модулей [77].

Большое значение Fan_in(i) — свидетельство высокого сцепления, так как является мерой зависимости модуля. Большое значение Fan_out(i) говорит о высокой сложности вызывающего модуля. Причиной является то, что для координации подчиненных модулей требуется сложная логика управления.

Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игнорировании веса связи. Здесь рассматриваются только управляющие потоки (вызовы модулей). В то же время информационные потоки, нагружающие ребра структуры, могут существенно изменяться, поэтому нужна мера, которая учитывает не только количество ребер, но и количество информации, проходящей через них.

С. Генри и Д. Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j) [35]. Они учитывают количество элементов и структур данных, из которых i-й модуль берет информацию и которые обновляются j-м модулем соответственно.

Информационные коэффициенты суммируются со структурными коэффициентами sfan_in(i) и sfan_out( j), которые учитывают только вызовы модулей.

В результате формируются полные значения коэффициентов:

Fan_in (i) = sfan_in (i) + ifan_in (i),

Fan_out (j) = sfan_out (j) + ifan_out (j).

На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры:

S = length(i) x (Fan_in(i) + Fan_out(i))2,

где length(i) — оценка размера i-го модуля (в виде LOC- или FP-оценки).