ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 06.11.2023
Просмотров: 823
Скачиваний: 6
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
6.3. Сложность программной системы
6.3.1. Методы оценки сложности
Оценка сложности программной системы имеет большое значение в реализации проекта этой системы. От сложности системы зависит про- изводительность труда разработчиков, а следовательно трудоемкость, сроки разработки и стоимость проекта. Между сложностью и надежно- стью программной системы также существует тесная связь. Очевидно, что чем выше сложность программной системы, тем труднее обеспечить ее надежность.
При оценке сложности программ, как правило, выделяют три основ- ные группы метрик: метрики размера программ, метрики сложности потока управления программ и метрики сложности потока данных про- грамм [28, 29]. Оценки первой группы наиболее просты и поэтому по- лучили широкое распространение. Традиционной характеристикой раз- мера программ является количество строк исходного текста. Под стро- кой понимается любой оператор программы. К группе оценок размера программ можно отнести метрику Холстеда. За базу принят подсчет количества операторов и операндов используемых в программе, т.е. оп- ределение размера программы.
Непосредственное измерение размера программы, несмотря на свою простоту, дает хорошие результаты. Оценка размера программы недос- таточна для принятия решения о ее сложности, но вполне применима для классификации программ, существенно различающихся объемами.
При уменьшении различий в объеме программ на первый план выдви- гаются оценки других факторов, оказывающих влияние на сложность.
Таким образом, оценка размера программы есть оценка по номинальной шкале, на основе которой определяются только категории программ без уточнения оценки для каждой категории.
Одно из основных правил программирования – соблюдение просто- ты. Более простой считается та программа, которая легче для понима- ния отладки, сопровождения и модификации. Однако не существует общепринятого мнения, что делает программу простой. Проще та про- грамма, которая использует привычную систему обозначений. Про- грамма с небольшим числом уровней вложенности проще, чем про- грамма, в которой таких уровней много. Существует еще ряд правил достижения простоты программ, вероятно, проще вся программная сис- тема, которая тщательно спроектирована. Однако в любом случае же- лательно уметь определять меру сложности программной системы.
В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться раз- личными способами.
Например, М. Холстед предложил меру длины N модуля [39]:
N n1 * log2 (n1) + n2 * log2 (n2), где n1 – число различных операторов, п2 – число различных операн- дов.
265
В качестве второй метрики М. Холстед рассматривал объем V моду- ля (количество символов для записи всех операторов и операндов текста программы):
V = N * log 2 (n1 + n2).
Вместе с тем известно, что любая сложная система состоит из эле- ментов и системы связей между элементами и что игнорировать внут- рисистемные связи неразумно. Вторая наиболее представительная груп- па оценок сложности программ – метрики сложности потока управле- ния программ. Как правило, с помощью этих оценок оперируют либо плотностью управляющих переходов внутри программ, либо взаимосвя- зями этих переходов.
Одной из наиболее простых, но достаточно эффективных оценок сложности программ является метрика Т. Джилба [30], в которой логи- ческая сложность программы определяется как насыщенность програм- мы выражениями IF_THEN_ELSE. При этом вводятся две характери- стики:
1. СL – абсолютная сложность программы, характеризующаяся коли- чеством операторов условия;
2. cl – относительная сложность программы, характеризующаяся на- сыщенностью программы операторами условия, т.е. cl определяется как отношение CL к общему числу операторов.
Используя метрику Джилба, ее дополнили еще одной составляющей, а именно характеристикой максимального уровня вложенности опера- тора CLI, что позволило применить метрику Джилба к анализу цикли- ческих конструкций.
Т. МакКейб при оценке сложности ПС предложил исходить из то- пологии внутренних связей [2]. Для этой цели он разработал метрику цикломатической сложности:
V(G) = E - N + 2, где Е – количество дуг, a N – количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представ- ляться как локальная структура, состоящая из элементов и связей между ними.
Большой интерес представляет оценка сложности программ по ме- тоду граничных значений [28]. В этом методе вводится несколько до- полнительных понятий, связанных с графом программы.
Пусть имеется G = (V,E) – ориентированный граф программы с единственной начальной и единственной конечной вершинами (рис.
6.2). В этом графе число входящих в вершину дуг называется отрица- тельной степенью вершины, а число исходящих из вершины дуг – по- ложительной степенью вершины. Тогда набор вершин графа можно разбить на две группы: вершины, у которых положительная степень <=1; вершины, у которых положительная степень >=2.
Вершины первой группы назовем принимающими вершинами, а вершины второй группы – вершинами отбора. Для получения оценки по
266 методу граничных значений необходимо разбить граф G на максималь- ное число подграфов G’, удовлетворяющих следующим условиям: вход в подграф осуществляется только через вершину отбора; каждый подграф включает вершину (называемую нижней границей подграфа), в которую можно попасть из любой другой вершины под- графа. Например, вершина отбора, соединенная сама с собой дугой петлей, образует подграф.
Число вершин, образующих такой подграф, равно скорректирован- ной сложности вершины отбора. Для примера графа по рис. 6.2 можно составить таблицу характеристик подграфов (табл. 6.2).
Рис. 6.2. Пример графа
Табл. 6.2
Характеристики подграфов
Характеристики подгра-
фов программ
Вершины отбора
a b c d
Вершины перехода b,c b,d e,f g,h
Скорректированная слож- ность вершины графа
10 2
3 3
Вершины подграфа b,c,d,e,f,g,h,i,j b e,f g,h
Нижняя граница подграфа k d i j
Каждая принимающая вершина имеет скорректированную слож- ность, равную 1, кроме конечной вершины, скорректированная слож- ность которой равна 0. Скорректированные сложности всех вершин графа G суммируются, образуя абсолютную граничную сложность про- граммы. После этого определяется относительная граничная сложность программы:
S
0
=1– (v–1)/S
a
,
267 где S
0
– относительная граничная сложность программы; S
a
– абсо- лютная граничная сложность программы, v – общее число вершин графа программы.
Таким образом, относительная сложность программы равна
S
0
=1-(11/25)=0,56.
Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей, меру сложности внешних свя- зей (между модулями) и меру сложности внутренних связей (внутри модулей). Традиционно с внешними связями сопоставляют характери- стику «сцепление», а с внутренними связями — характеристику «связ- ность».
Иерархическая структура программной системы – основной резуль- тат предварительного проектирования. Она определяет состав модулей
ПС и управляющие отношения между модулями. В этой структуре мо- дуль более высокого уровня (начальник) управляет модулем нижнего уровня (подчиненным). Иерархическая структура не отражает проце- дурные особенности программной системы, то есть последовательность операций, их повторение, ветвления и т. д. Рассмотрим основные харак- теристики иерархической структуры, представленной на рис. 6.3 [30].
Рис. 6.3. Иерархическая структура программной системы
Первичными характеристиками являются количество вершин (моду- лей) и количество ребер (связей между модулями). К ним добавляются две глобальные характеристики: высота – количество уровней управле- ния; и ширина – максимальное из количеств модулей, размещенных на уровнях управления. В примере по рис. 6. высота = 4, ширина = 6.
Локальными характеристиками модулей структуры являются коэф- фициент объединения по входу и коэффициент разветвления по выходу.
Коэффициент объединения по входу Fan_in(i) – это количество моду- лей, которые прямо управляют i-м модулем. В примере для модуля n:
Fan_in(n) = 4. Коэффициент разветвления по выходу Fan_out(i) – это количество модулей, которыми прямо управляет i-й модуль. В примере для модуля m: Fan_out(m) = 3.
268
Возникает вопрос: как оценить качество структуры? Из практики проектирования известно, что лучшее решение обеспечивается иерар- хической структурой в виде дерева. Степень отличия реальной проект- ной структуры от дерева характеризуется невязкой структуры. Как оп- ределить невязку?
Известно, что полный граф (complete graph) с n вершинами имеет количество ребер e c
= n * (n-1) / 2, а дерево с таким же количеством вершин – существенно меньшее количество ребер e t
= n - 1.
Тогда формулу невязки можно построить, сравнивая количество ре- бер полного графа, реального графа и дерева. Для проектной струк- туры с n вершинами и е ребрами невязка определяется по выраже- нию
2)
(n
1)
(n
1)
n
(e
2 1)
(n
2 1)
(n n
2 1)
n
(e e
e e
e
Nev t
c t
Значение невязки лежит в диапазоне от 0 до 1. Если Nev = 0, то про- ектная структура является деревом, если Nev = 1, то проектная структу- ра – полный граф.
Ясно, что невязка дает грубую оценку структуры. Для увеличения точности оценки следует применить характеристики связности и сцеп- ления. Хорошая структура должна иметь низкое сцепление и высокую связность.
Л. Констентайн и Э. Йордан (1979) предложили оценивать структуру с помощью коэффициентов Fan_in(i) и Fan_out(i) модулей [5]. Большое значение Fan_in(i) – свидетельство высокого сцепления, так как являет- ся мерой зависимости модуля. Большое значение Fan_out(i) говорит о высокой сложности вызывающего модуля. Причиной является то, что для координации подчиненных модулей требуется сложная логика управления.
Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игнорировании веса связи. Здесь рассматриваются только управляющие потоки (вызовы модулей). В то же время информационные потоки, на- гружающие ребра структуры, могут существенно изменяться, поэтому нужна мера, которая учитывает не только количество ребер, но и коли- чество информации, проходящей через них.
С. Генри и Д. Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j) [1]. Они учитывают количество элементов и структур данных, из которых 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).
На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры:
269
S =
n
i 1
length(i) * (Fan_in(i) + Fan_out(i))
2
, где length(i) — оценка размера i-го модуля (в виде LOC- или FP- оценки).
6.3.2. Оценка сложности на основе связности и сцепления модулей
Одна из возможных моделей сложности модульной программной системы основывается на основных характеристиках ее модулей – связ- ности каждого модуля и сцеплении каждой пары модулей. Выше была дана числовая оценка (от 0 до 10) связности и сцепления модулей. Кста- ти заметим, что различные авторы дают в этом диапазоне несколько иные значения для каждого типа характеристики модуля. Для оценки сложности S программной системы выберем числовой диапазон от 0 до
1. При этом будем считать, что высокая связность и слабое сцепление характеризуется числом, близким к нулю. Таким образом, чем ближе значение S к единице, тем сложнее ПС. При таком подходе к значению числовой оценки нужно изменить значения коэффициентов СС (сила связности) и СЦ (сила сцепления) таким образом, как это приведено в табл. 6.3 и 6.4 [25].
Табл. 6.3
Уровни связности модулей
№ п/п
Связность модуля
Степень связности
1.
Функциональная
0 (сильная связность)
2.
Информационная (последовательная)
0,1 3.
Коммуникативная
0,3 4.
Процедурная
0,5 5.
Временная
0,7 6.
Логическая
0,9 7
По совпадению
1 (слабая связность)
Табл. 6.4
Уровни сцепления модулей
№ п/п
Сцепление модулей
Степень сцепления
1.
Независимое
0 (слабое сцепление)
2.
По данным
0,1 3.
По образцу
0,3 4.
По общей области
0,5 5.
По управлению
0,7 6.
По внешним ссылкам
0,9 7
По кодам
1,0 (сильное сцепление)
Далее предполагается, что зависимость первого порядка между каж- дой парой модулей задается по формуле [20]
270 0,15 (s i
+ s j
) + 0,7 c ij
, если c
ij
0, d
ij
= 0, если c ij
= 0,
1, если i = j.
Величина d ij представляет вероятность того, что модуль j придется изменить, если будет изменен модуль i, если рассматривать модули i и j вне контекста всей программной системы (отношение считается сим- метричным). Величины s i и s j обозначают связность этих модулей, а c ij
– сцепление. Если сцепления нет, то d ij
= 0. Матрица D может быть представлена неориентированным графом, вершинами которого служат модули, а ребрами – ненулевые значения зависимости первого порядка.
Эта матрица не отображает полную модель программы, так как в ней не отражены явно влияния зависимостей более высоких порядков (т.е. за- висимости второго, третьего и т. д. порядков). На рис. 6.4 показана со- вокупность модулей программы A, B, C, D, E.
Если изменится модуль A, то могут потребовать изменения модули
B и C (зависимости первого порядка). Однако может потребоваться из- менить модуль B и в том случае, если после изменения модуля A был изменен модуль C (зависимость второго порядка: ребра ac – cb). Как видно из рис. 6.4, для модуля B могла бы быть и зависимость третьего порядка: ребра ac – cd – de – eb (ребро eb показано пунктиром).
Рис. 6.4. Граф модулей программы
Для полного изображения зависимостей между любой парой моду- лей вычисляется полная матрица зависимостей. Это делается с помо- щью следующей последовательностью шагов.
1.
Найти все пути в графе (исключая циклы) между каждой парой модулей.
2.
Вычислить вероятности для каждого найденного пути как про- изведения вероятностей для соответствующих дуг.
3.
Вычислить зависимости между модулями, используя вероятно- сти для путей, но, не считая пути взаимно исключающими.
В результате буде получена вероятность того, что будет необходимо изменить один из модулей в случае изменения другого (снова предпола- гается, что отношение симметрично).
Рассмотрим пример. Пусть для графа модулей, изображенного на рис. 6.4, известны следующие исходные данные, характеризующие
6.3.1. Методы оценки сложности
Оценка сложности программной системы имеет большое значение в реализации проекта этой системы. От сложности системы зависит про- изводительность труда разработчиков, а следовательно трудоемкость, сроки разработки и стоимость проекта. Между сложностью и надежно- стью программной системы также существует тесная связь. Очевидно, что чем выше сложность программной системы, тем труднее обеспечить ее надежность.
При оценке сложности программ, как правило, выделяют три основ- ные группы метрик: метрики размера программ, метрики сложности потока управления программ и метрики сложности потока данных про- грамм [28, 29]. Оценки первой группы наиболее просты и поэтому по- лучили широкое распространение. Традиционной характеристикой раз- мера программ является количество строк исходного текста. Под стро- кой понимается любой оператор программы. К группе оценок размера программ можно отнести метрику Холстеда. За базу принят подсчет количества операторов и операндов используемых в программе, т.е. оп- ределение размера программы.
Непосредственное измерение размера программы, несмотря на свою простоту, дает хорошие результаты. Оценка размера программы недос- таточна для принятия решения о ее сложности, но вполне применима для классификации программ, существенно различающихся объемами.
При уменьшении различий в объеме программ на первый план выдви- гаются оценки других факторов, оказывающих влияние на сложность.
Таким образом, оценка размера программы есть оценка по номинальной шкале, на основе которой определяются только категории программ без уточнения оценки для каждой категории.
Одно из основных правил программирования – соблюдение просто- ты. Более простой считается та программа, которая легче для понима- ния отладки, сопровождения и модификации. Однако не существует общепринятого мнения, что делает программу простой. Проще та про- грамма, которая использует привычную систему обозначений. Про- грамма с небольшим числом уровней вложенности проще, чем про- грамма, в которой таких уровней много. Существует еще ряд правил достижения простоты программ, вероятно, проще вся программная сис- тема, которая тщательно спроектирована. Однако в любом случае же- лательно уметь определять меру сложности программной системы.
В простейшем случае сложность системы определяется как сумма мер сложности ее модулей. Сложность модуля может вычисляться раз- личными способами.
Например, М. Холстед предложил меру длины N модуля [39]:
N n1 * log2 (n1) + n2 * log2 (n2), где n1 – число различных операторов, п2 – число различных операн- дов.
265
В качестве второй метрики М. Холстед рассматривал объем V моду- ля (количество символов для записи всех операторов и операндов текста программы):
V = N * log 2 (n1 + n2).
Вместе с тем известно, что любая сложная система состоит из эле- ментов и системы связей между элементами и что игнорировать внут- рисистемные связи неразумно. Вторая наиболее представительная груп- па оценок сложности программ – метрики сложности потока управле- ния программ. Как правило, с помощью этих оценок оперируют либо плотностью управляющих переходов внутри программ, либо взаимосвя- зями этих переходов.
Одной из наиболее простых, но достаточно эффективных оценок сложности программ является метрика Т. Джилба [30], в которой логи- ческая сложность программы определяется как насыщенность програм- мы выражениями IF_THEN_ELSE. При этом вводятся две характери- стики:
1. СL – абсолютная сложность программы, характеризующаяся коли- чеством операторов условия;
2. cl – относительная сложность программы, характеризующаяся на- сыщенностью программы операторами условия, т.е. cl определяется как отношение CL к общему числу операторов.
Используя метрику Джилба, ее дополнили еще одной составляющей, а именно характеристикой максимального уровня вложенности опера- тора CLI, что позволило применить метрику Джилба к анализу цикли- ческих конструкций.
Т. МакКейб при оценке сложности ПС предложил исходить из то- пологии внутренних связей [2]. Для этой цели он разработал метрику цикломатической сложности:
V(G) = E - N + 2, где Е – количество дуг, a N – количество вершин в управляющем графе ПС. Это был шаг в нужном направлении. Дальнейшее уточнение оценок сложности потребовало, чтобы каждый модуль мог представ- ляться как локальная структура, состоящая из элементов и связей между ними.
Большой интерес представляет оценка сложности программ по ме- тоду граничных значений [28]. В этом методе вводится несколько до- полнительных понятий, связанных с графом программы.
Пусть имеется G = (V,E) – ориентированный граф программы с единственной начальной и единственной конечной вершинами (рис.
6.2). В этом графе число входящих в вершину дуг называется отрица- тельной степенью вершины, а число исходящих из вершины дуг – по- ложительной степенью вершины. Тогда набор вершин графа можно разбить на две группы: вершины, у которых положительная степень <=1; вершины, у которых положительная степень >=2.
Вершины первой группы назовем принимающими вершинами, а вершины второй группы – вершинами отбора. Для получения оценки по
266 методу граничных значений необходимо разбить граф G на максималь- ное число подграфов G’, удовлетворяющих следующим условиям: вход в подграф осуществляется только через вершину отбора; каждый подграф включает вершину (называемую нижней границей подграфа), в которую можно попасть из любой другой вершины под- графа. Например, вершина отбора, соединенная сама с собой дугой петлей, образует подграф.
Число вершин, образующих такой подграф, равно скорректирован- ной сложности вершины отбора. Для примера графа по рис. 6.2 можно составить таблицу характеристик подграфов (табл. 6.2).
Рис. 6.2. Пример графа
Табл. 6.2
Характеристики подграфов
Характеристики подгра-
фов программ
Вершины отбора
a b c d
Вершины перехода b,c b,d e,f g,h
Скорректированная слож- ность вершины графа
10 2
3 3
Вершины подграфа b,c,d,e,f,g,h,i,j b e,f g,h
Нижняя граница подграфа k d i j
Каждая принимающая вершина имеет скорректированную слож- ность, равную 1, кроме конечной вершины, скорректированная слож- ность которой равна 0. Скорректированные сложности всех вершин графа G суммируются, образуя абсолютную граничную сложность про- граммы. После этого определяется относительная граничная сложность программы:
S
0
=1– (v–1)/S
a
,
267 где S
0
– относительная граничная сложность программы; S
a
– абсо- лютная граничная сложность программы, v – общее число вершин графа программы.
Таким образом, относительная сложность программы равна
S
0
=1-(11/25)=0,56.
Таким образом, при комплексной оценке сложности ПС необходимо рассматривать меру сложности модулей, меру сложности внешних свя- зей (между модулями) и меру сложности внутренних связей (внутри модулей). Традиционно с внешними связями сопоставляют характери- стику «сцепление», а с внутренними связями — характеристику «связ- ность».
Иерархическая структура программной системы – основной резуль- тат предварительного проектирования. Она определяет состав модулей
ПС и управляющие отношения между модулями. В этой структуре мо- дуль более высокого уровня (начальник) управляет модулем нижнего уровня (подчиненным). Иерархическая структура не отражает проце- дурные особенности программной системы, то есть последовательность операций, их повторение, ветвления и т. д. Рассмотрим основные харак- теристики иерархической структуры, представленной на рис. 6.3 [30].
Рис. 6.3. Иерархическая структура программной системы
Первичными характеристиками являются количество вершин (моду- лей) и количество ребер (связей между модулями). К ним добавляются две глобальные характеристики: высота – количество уровней управле- ния; и ширина – максимальное из количеств модулей, размещенных на уровнях управления. В примере по рис. 6. высота = 4, ширина = 6.
Локальными характеристиками модулей структуры являются коэф- фициент объединения по входу и коэффициент разветвления по выходу.
Коэффициент объединения по входу Fan_in(i) – это количество моду- лей, которые прямо управляют i-м модулем. В примере для модуля n:
Fan_in(n) = 4. Коэффициент разветвления по выходу Fan_out(i) – это количество модулей, которыми прямо управляет i-й модуль. В примере для модуля m: Fan_out(m) = 3.
268
Возникает вопрос: как оценить качество структуры? Из практики проектирования известно, что лучшее решение обеспечивается иерар- хической структурой в виде дерева. Степень отличия реальной проект- ной структуры от дерева характеризуется невязкой структуры. Как оп- ределить невязку?
Известно, что полный граф (complete graph) с n вершинами имеет количество ребер e c
= n * (n-1) / 2, а дерево с таким же количеством вершин – существенно меньшее количество ребер e t
= n - 1.
Тогда формулу невязки можно построить, сравнивая количество ре- бер полного графа, реального графа и дерева. Для проектной струк- туры с n вершинами и е ребрами невязка определяется по выраже- нию
2)
(n
1)
(n
1)
n
(e
2 1)
(n
2 1)
(n n
2 1)
n
(e e
e e
e
Nev t
c t
Значение невязки лежит в диапазоне от 0 до 1. Если Nev = 0, то про- ектная структура является деревом, если Nev = 1, то проектная структу- ра – полный граф.
Ясно, что невязка дает грубую оценку структуры. Для увеличения точности оценки следует применить характеристики связности и сцеп- ления. Хорошая структура должна иметь низкое сцепление и высокую связность.
Л. Констентайн и Э. Йордан (1979) предложили оценивать структуру с помощью коэффициентов Fan_in(i) и Fan_out(i) модулей [5]. Большое значение Fan_in(i) – свидетельство высокого сцепления, так как являет- ся мерой зависимости модуля. Большое значение Fan_out(i) говорит о высокой сложности вызывающего модуля. Причиной является то, что для координации подчиненных модулей требуется сложная логика управления.
Основной недостаток коэффициентов Fan_in(i) и Fan_out(i) состоит в игнорировании веса связи. Здесь рассматриваются только управляющие потоки (вызовы модулей). В то же время информационные потоки, на- гружающие ребра структуры, могут существенно изменяться, поэтому нужна мера, которая учитывает не только количество ребер, но и коли- чество информации, проходящей через них.
С. Генри и Д. Кафура (1981) ввели информационные коэффициенты ifan_in(i) и ifan_out(j) [1]. Они учитывают количество элементов и структур данных, из которых 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).
На основе полных коэффициентов модулей вычисляется метрика общей сложности структуры:
269
S =
n
i 1
length(i) * (Fan_in(i) + Fan_out(i))
2
, где length(i) — оценка размера i-го модуля (в виде LOC- или FP- оценки).
6.3.2. Оценка сложности на основе связности и сцепления модулей
Одна из возможных моделей сложности модульной программной системы основывается на основных характеристиках ее модулей – связ- ности каждого модуля и сцеплении каждой пары модулей. Выше была дана числовая оценка (от 0 до 10) связности и сцепления модулей. Кста- ти заметим, что различные авторы дают в этом диапазоне несколько иные значения для каждого типа характеристики модуля. Для оценки сложности S программной системы выберем числовой диапазон от 0 до
1. При этом будем считать, что высокая связность и слабое сцепление характеризуется числом, близким к нулю. Таким образом, чем ближе значение S к единице, тем сложнее ПС. При таком подходе к значению числовой оценки нужно изменить значения коэффициентов СС (сила связности) и СЦ (сила сцепления) таким образом, как это приведено в табл. 6.3 и 6.4 [25].
Табл. 6.3
Уровни связности модулей
№ п/п
Связность модуля
Степень связности
1.
Функциональная
0 (сильная связность)
2.
Информационная (последовательная)
0,1 3.
Коммуникативная
0,3 4.
Процедурная
0,5 5.
Временная
0,7 6.
Логическая
0,9 7
По совпадению
1 (слабая связность)
Табл. 6.4
Уровни сцепления модулей
№ п/п
Сцепление модулей
Степень сцепления
1.
Независимое
0 (слабое сцепление)
2.
По данным
0,1 3.
По образцу
0,3 4.
По общей области
0,5 5.
По управлению
0,7 6.
По внешним ссылкам
0,9 7
По кодам
1,0 (сильное сцепление)
Далее предполагается, что зависимость первого порядка между каж- дой парой модулей задается по формуле [20]
270 0,15 (s i
+ s j
) + 0,7 c ij
, если c
ij
0, d
ij
= 0, если c ij
= 0,
1, если i = j.
Величина d ij представляет вероятность того, что модуль j придется изменить, если будет изменен модуль i, если рассматривать модули i и j вне контекста всей программной системы (отношение считается сим- метричным). Величины s i и s j обозначают связность этих модулей, а c ij
– сцепление. Если сцепления нет, то d ij
= 0. Матрица D может быть представлена неориентированным графом, вершинами которого служат модули, а ребрами – ненулевые значения зависимости первого порядка.
Эта матрица не отображает полную модель программы, так как в ней не отражены явно влияния зависимостей более высоких порядков (т.е. за- висимости второго, третьего и т. д. порядков). На рис. 6.4 показана со- вокупность модулей программы A, B, C, D, E.
Если изменится модуль A, то могут потребовать изменения модули
B и C (зависимости первого порядка). Однако может потребоваться из- менить модуль B и в том случае, если после изменения модуля A был изменен модуль C (зависимость второго порядка: ребра ac – cb). Как видно из рис. 6.4, для модуля B могла бы быть и зависимость третьего порядка: ребра ac – cd – de – eb (ребро eb показано пунктиром).
Рис. 6.4. Граф модулей программы
Для полного изображения зависимостей между любой парой моду- лей вычисляется полная матрица зависимостей. Это делается с помо- щью следующей последовательностью шагов.
1.
Найти все пути в графе (исключая циклы) между каждой парой модулей.
2.
Вычислить вероятности для каждого найденного пути как про- изведения вероятностей для соответствующих дуг.
3.
Вычислить зависимости между модулями, используя вероятно- сти для путей, но, не считая пути взаимно исключающими.
В результате буде получена вероятность того, что будет необходимо изменить один из модулей в случае изменения другого (снова предпола- гается, что отношение симметрично).
Рассмотрим пример. Пусть для графа модулей, изображенного на рис. 6.4, известны следующие исходные данные, характеризующие