Расчет основных метрик объектно-ориентированного программирования при помощи асд uml map

See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/277952273
РАСЧЕТ ОСНОВНЫХ МЕТРИК ОБЪЕКТНО-ОРИЕНТИРОВАННОГО
ПРОГРАММИРОВАНИЯ ПРИ ПОМОЩИ АСД UML MAP
Conference Paper · April 2015
CITATIONS
READS
0
1,120
2 authors:
Olga Deryugina
Mikhail Volovich
Sberbank
Moscow State University of Instrument Engineering and Informatics
16 PUBLICATIONS 22 CITATIONS
5 PUBLICATIONS 5 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
UML class diagram refactoring tool View project
Psychological Platform View project
All content following this page was uploaded by Olga Deryugina on 09 June 2015.
The user has requested enhancement of the downloaded file.
SEE PROFILE
УДК 004.4
ВОЛОВИЧ М.Е., ДЕРЮГИНА ОА.
РАСЧЕТ ОСНОВНЫХ МЕТРИК ОБЪЕКТНООРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ ПРИ ПОМОЩИ
АСД UML MAP
В статье рассмотрены основные метрики структурного программирования,
объектно-ориентированные метрики, сервис-ориентированные метрики в
контексте применениях их для решения задач поисковой программной
инженерии (SBSE). Приведен пример расчета объектно-ориентированной
метрики DIT на основе АСД UML Map.
The article describes the basic metrics of structured programming , object- oriented
metrics , service- oriented metrics in the context of their application for solving
search software engineering (SBSE). An example of calculation of object-oriented
metrics DIT based on the SDA UML Map.
Введение
В связи с активным развитием поискового подхода (SBSE – Search
Based Software Engineering) к проектированию архитектуры программного
обеспечения[7]
возникает
проблема
определения
критериев
эффективности, необходимых для задания целевой функции для алгоритма
поиска.
Одним из возможных способов задания целевой функции в данном
случае
является
обеспечения.
использование
Выбор
проектирования
тех
или
архитектуры
стандартных метрик
иных
метрик
программного
зависит
от
(объектно-ориентированное,
уровня
сервис-
ориентированное, распределённое в облаке и т.д.).
Цель
данной
работы
–
рассмотреть
основные
метрики
программного обеспечения в контексте их использования в процессе
решения задач SBSE (Search Based Software Engineering); описать
возможности расчета стандартных объектно-ориентированных метрик,
предоставляемые предложенной в [6] абстрактной структурой данных
(АСД) UML Map.
Обзор стандартных метрик программного обеспечения
В [8] обозначены следующие 3 задачи для использования метрик
программного обеспечения:
1. Классификация приложений по сложности анализа.
2. Оценка трудоемкости анализа частей одного приложения.
3. Профилирование
приложения
с
целью
автоматического
выявления потенциально интересных для аналитика фрагментов кода.
В зависимости от уровня абстрагирования и этапа проектирования
программного обеспечения можно выделить:
1) метрики структурного программирования
2) объектно-ориентированные метрики
3) сервис-ориентированные метрики
Метрики структурного программирования
В основном метрики структурного программирования вычисляются
на основе исходного кода, т. е. их нельзя применять на этапе
проектирования архитектуры приложения.
Количественные метрики
В качестве преимущества количественных метрик можно отметить
их простоту.
1. SLOC – Source Lines of Code (Количество строк кода).
Данная метрика может применяться для классификации приложений
по объему.
2. Среднее число строк для функций.
3.
Метрики
показатели,
как
Холстеда
число
–
используют
такие
количественные
уникальных операторов программы,
число
уникальных операндов программы, общее число операторов, общее число
операндов. На основе данных показателей определяются уровень качества
программирования, сложность понимания программы, трудоемкость
кодирования программы, уровень языка выражения, информационное
содержание программы [8].
4. Метрики Джилба – позволяют определить насыщенность кода
программы операторами условия и цикла. Вычисляются как cl = CL/n, где
cl – относительная сложность программы по Джилбу, CL – количество
операторов условия и/или цикла, n – общее число операторов программы.
5. ABC-метрика включает в себя оценку количества присваиваний
(Assignment),
вызовов
функций
(Branch)
и
логических
проверок
(Condition). Записывается в виде ABC = <a,b,c>.
Метрики сложности потока управления
Метрики анализа потока управления (кроме метрик Вудворта)
основаны на анализе графа потока управления программы. Рассмотрим
некоторые из них:
1. Цикломатическая сложность (метрика МакКейба) – вычисляется
для графа потока управления процедуры или функции по формуле V(p) = e
– n + 2p, где e – количество дуг, n – количество вершин, p – число
компонент связности графа потока управления.
Метрика МакКейба может вычисляться для всей системы, если
построен общий граф потока управления на основе графа вызовов, либо
для отдельных модулей, классов, методов и других единиц[8]. При этом
сложность условий для циклов и операторов условного перехода не
учитывается.
2. Интервальная метрика Майерса введена с целью учета сложности
предикатов для циклов и операторов условного перехода. В качестве
оценки используется интервал [V(G),V(G)+h], где h для простых
предикатов равно нулю, а для n-местных h=n-1 (n-местный предикат
зависит от n переменных).
3. Метрика Хансена оценивает сложность программы (функции)
парой (цикломатическая сложность, число операторов), что позволяет
проводить дополнительный анализ структурированности программы.
Метрики сложности потока данных
Основаны на анализе потока данных в программе. Рассмотрим
некоторые из них:
1. Метрика Чепина выражается формулой Q =
,
где a1, a2, a3, a4 - весовые коэффициенты, P – переменные, вводимые для
расчетов и обеспечения вывода, M – модифицируемые или создаваемые
внутри программы переменные, C – управляющие переменные, T паразитные, не используемые переменные. Метрика позволяет оценивать
прочность
отдельно
взятого
модуля
по
характеру
использования
переменных.
2. Метрика спена оценивает число обращений к переменной между
её первым и последним появлением в программе.
3. Метрика обращений к глобальным переменным сравнивает
количество
фактических
и
возможных
пар
(модуль,
глобальная
переменная), т. е. соотношение количества фактических обращений
модуля к глобальным переменным и количества возможных обращений,
показывающее вероятность несанкционированного изменения глобальной
переменной[8].
Объектно-ориентированные метрики
Классические
объектно-ориентированные
метрики,
введенные
Chidamber and Kemerer в 1994 г. [2], основаны на базовых понятиях ООП:
 зацепление (cohesion);
 зависимость (dependence);
 связанность (coupling);
Cohesion определяет то, насколько сильно связаны методы внутри
класса.
Coupling
отражает
степень
взаимозависимости
между
компонентами системы. Классы считаются зависимыми, если метод одного
класса использует метод или атрибут другого. Принцип объектноориентированного проектирования GRASP предполагает максимальное
увеличение параметра cohesion системы и как следствие минимизацию
значения параметра coupling.
Зависимость
(dependence)
в
программной
системе
означает
непосредственную связь между сущностями системы X&Y: программист,
изменяющий X, должен учитывать неизбежное влияние на Y[1].
К основным объектно-ориентированным метрикам [2] относятся:
1) Coupling Between Object (CBO – Связанность объектов) – число не
связанных наследованием классов, с которыми связан данный класс.
Отражает степень взаимосвязанности компонентов системы.
2) Response For a Class (RFC – Вызовы класса) – число методов
класса и число вызываемых данными методами методов. Определяет
степень сообщения между классами системы.
3) Lack of Cohesion in Methods (LCOM – Недостаток зацепления в
методах) – число пар методов, которые не имеют общих переменных
минус число пар методов, которые имеют разделяемые переменные класса.
4) Weighted Methods per Class (WMC – Взвешенные методы класса) –
определяется как суммарная сложность методов класса. Если все величины
сложности равны 1, то WMC равно число методов класса.
5) Depth of Inheritance Tree (DIT – Высота дерева наследования) –
число уровней дерева наследования классов. DIT корневого класса дерева
наследования равна 0.
6) Number of Children (NOC – Число потомков) – число
непосредственных подклассов данного класса.
Большая часть описанных выше метрик (кроме DIT и CBO) может быть
рассчитана на основе исходного кода системы, но не на основе UML
диаграммы. В связи с этим возникает необходимость разработки метрик,
позволяющих оценить систему на этапе проектирования для применения
эволюционного поиска.
На данном этапе исследователи применяют различные метрики[5,4],
набор
общепринятых
метрик
объектно-ориентированных
программных систем пока что не утверждён.
моделей
По этой причине зачастую результаты применения эволюционного
подхода к проектированию архитектуры сложно оценить объективно.
Можно лишь говорить о том, что значение целевой функции было
повышено на n-е количество процентов. Вопрос формулировки самой
целевой функции пока что не проработан в достаточной мере.
Среди
общих
рекомендаций
можно
отметить
стремление
к
повышению внутреннего сцепления классов и модулей системы и
уменьшение взаимозависимости между классами и интерфейсами. С
другой стороны, необходима балансировка между величиной сцепления и
размерами отдельных структурных элементов системы.
Сервис-ориентированные метрики
С развитием сервис-ориентированного подхода к проектированию
программного обеспечения все актуальнее становится разработка сервисориентированных метрик программного-обеспечения. На сегодняшний
день разработаны сервис-ориентированные метрики, часть из которых
является
аналогией
с
метриками
объектно-ориентированного
программирования.
Рассмотрим некоторые из них, приведенные в работе[3]:
1. Coupling of Service (CoS – Связанность сервиса) – число других
сервисов, над которыми данный сервис производит операции.
2. Service Coupling Factor (SCF – Фактор связанности сервисов) –
определяется следующим образом:
|| NS(
,где:
- множество сервисов системы,
CoS(c) – связанность сервиса c,
NS – число сервисов системы,
множество сервисов, которые являются потребителями услуг сервиспровайдеров.
3. System’s Service Coupling (SSC – Связанность сервисов системы) –
степень связанности заданной системы
:
|| SC(
,где:
- множество сервисов системы,
CoS(c) – связанность сервиса c,
SC ( ) – число сервисов-потребителей услуг для множества сервисов
SP ( ) – число сервисов-провайдеров услуг для множества сервисов
,
,
множество сервисов, которые являются потребителями услуг сервиспровайдеров.
В
результате
рассмотрения
объектно-ориентированного
основных
и
метрик
структурного,
сервис-ориентированного
программирования можно сделать вывод о том, что классические метрики
объектно-ориентированного
программирования
и
их
модификации
удобнее всего подходят для использования в качестве элементов целевой
функции в процессе эволюционной трансформации UML моделей.
Связано это с тем, что метрики структурного программирования
основаны на исходном коде программной системы. Метрики сервисориентированного программирования могут быть использованы после
введения в UML соответствующих сущностей.
Объектно-ориентированные метрики (за исключением некоторых)
позволяют оценивать разрабатываемую программную систему на уровне
модели, отвлекаясь от программной реализации (которой на этапе
проектирования попросту и нет).
Кроме того, в соответствии с принципами MDA на основе одной и
той же модели может быть сгенерировано несколько программных
реализаций. Гораздо интереснее в таком случае проводить анализ
исходной модели.
Расчёт стандартных объектно-ориентированных метрик на
основе UML Map
Расчет стандартных объектно-ориентированных метрик может
проводиться различными способами.
При наличии исходного кода удобно воспользоваться такими
средствами, как CLANG, основанный на технологии LLVM.
При необходимости анализа разрабатываемой программной системы
на этапе проектирования UML модели можно производить расчет метрик
на основе XMI представления, но данный вариант не является
эффективным с точки зрения вычислительной сложности.
АСД UML Map, предложенная в [6], являющаяся отображением
UML модели программной системы, представленной в формате XMI,
позволяет удобно вычислять такие объектно-ориентированные метрики,
как CBO, NOC и DIT, избежав необходимости производить постоянный
парсинг XMI-файла.
Пример кода для вычисления величины DIT класса:
//Depth of Inheritance Tree
public Integer getClassDIT (String classID, ClassDiagram classDiagram ){
Integer classDIT = 0, classDITMax=0;
for (Entry<String, Relation> entry : (classDiagram.getRelations()).entrySet())
{
Relation relation = entry.getValue();
classDIT = 0;
if (relation.getType().equals("generalization")) {
if (relation.getEndId().equals(classID)) {
classDIT++;
classDIT = getClassDIT(relation.getStartId(), classDiagram, classDIT);
if (classDIT > classDITMax) classDITMax = classDIT;
}
}
}
return classDITMax;
}
public Integer getClassDIT (String classID, ClassDiagram classDiagram, Integer classDIT ){
Integer classDITMax=classDIT;
for (Entry<String, Relation> entry : (classDiagram.getRelations()).entrySet())
{
Relation relation = entry.getValue();
if (relation.getType().equals("generalization")) {
if (relation.getEndId().equals(classID)) {
classDIT++;
classDIT = getClassDIT(relation.getStartId(), classDiagram, classDIT);
if (classDIT > classDITMax) classDITMax = classDIT;
}
}
}
return classDITMax;
}
Рисунок 1 - Диаграмма классов «Customers»
Результат вычисления NOC для классов диаграммы классов,
представленной на рис.1:
---------------------------------------------------------------------------------Customer DIT: 2
CorporateCustomer DIT: 1
Bank DIT: 0
PersonalCustomer DIT: 0
Расчет объектно-ориентированных метрик на этапе проектирования
позволяет
получить
дополнительную
информацию
о
структурной
сложности системы и отслеживать эти показатели при изменении модели.
Заключение
В
статье
программирования,
рассмотрены
основные
метрики
объектно-ориентированные
структурного
метрики,
сервис-
ориентированные метрики.
Сделаны следующие выводы:
 объектно-ориентированные метрики (за исключением некоторых)
позволяют оценивать разрабатываемую программную систему на уровне
модели, отвлекаясь от программной реализации (которой на этапе
проектирования попросту и нет);
 набор общепринятых метрик объектно-ориентированных моделей
программных систем не утверждён;
 результаты применения эволюционного подхода к проектированию
архитектуры сложно оценить объективно;
 возникает необходимость разработки метрик, позволяющих оценить
систему на этапе проектирования для применения эволюционного поиска;
 вопрос формулировки целевой функции в процессе эволюционного
поиска пока что не проработан в достаточной мере;
 расчет
объектно-ориентированных
метрик
на
основе
XMI
представления трудоемок;
 АСД UML Map позволяет удобно вычислять такие объектноориентированные метрики, как CBO, NOC и DIT.
Список используемых источников
1. Cheikhi L., Al-Qutaish R. E., Idri A., Sellami A. Chidamber and Kemerer ObjectOriented Measures: Analysis of their Design from the Methology Perspective // International
Journal of Software Engineering and Its Applications. Vol.8, No.2 (2014), pp.359-374
2. Chidamber S. R., Kemerer C. F. A metrics suite for object oriented design. IEEE
Trans. Software Eng., 20(6):476–493, 1994.
3. Hofmeister H., Wirtz G. Supporting Service-Oriented Design with Metrics //
EDOC 2008, pp. 191–200 (2008)
4. Räihä, O. A survey on search-based software design. Computer Sci. Rev., 2010, 4,
203–249.
5. Simons C. L., And Parmee I.C. Single and multi-objective genetic operators in
object-oriented conceptual software design. In: Proceedings of the Genetic and Evolutionary
Computation Conference (GECCO’07), 2007 1957 – 1958.
6. Волович М. Е., Дерюгина О. А. Верификация UML моделей программных
систем // Cloud of Science. 2015. №1.
7. Дерюгина О. А. Применение методов поисковой программной инженерии
для решения задач объектно-ориентированного проектирования архитектуры
приложений // Образовательная среда сегодня и завтра. Сборник научных трудов IX
Международной научно-практической конференции. под общей редакцией Г.Г.
Бубнова, Е.В. Плужника, В.И. Солдаткина. 2014. – С. 197-200.
8. Ледовских
И.
Метрики
сложности
кода
//
http://www.ispras.ru/ru/preprints/docs/prep_25_2013.pdf (Проверено 28.03.2015)
9. Плужник Е.В., Никульчев Е.В., Лукьянчиков О.И. Проектирование
распределенных информационных систем обработки больших объемов данных в
гибридной облачной инфраструктуре // Вестник Рязанского радиотехнического
университета. 2014. № 4
Сведения об авторах
Волович Михаил Евгеньевич
к.т.н., доцент кафедры «Управление и моделирование систем»
Московский
государственный
университет
информационных
радиотехники и электроники, г. Москва
E-mail: i@volovich.me
технологий,
Дерюгина Ольга Александровна
аспирантка кафедры «Управление и моделирование систем»
Московский
государственный
университет
информационных
радиотехники и электроники, г. Москва
E-mail: O.a.derugina@yandex.ru
технологий,
View publication stats