ВИЗУАЛЬНЫЙ АНАЛИЗ ПАКЕТОВ ПРОГРАММ

В.Ю.Романов, Д.Е. Намиот

Московский Государственный Университет имени М.В. Ломоносова, Россия

vladimir.romanov@gmail.com, dnamiot@gmail.com

 

Содержание

1. Введение

2. Метрики

3. Графы дефектов

4. Пост-графовые модели визуализации программных метрик

5. Заключение

Список литературы

 

Аннотация

В статье приводится обзор методов визуализации разнообразных метрик для программных систем. Основное назначение подобного рода анализа – это анализ качества программного обеспечения, а также интегрирование отдельных компонент (пакетов) в сложные программные комплексы. Многие современные системы (программные компоненты) с открытым кодом, например, представляют собой большие и достаточно сложные программные комплексы, интеграция которых в новый проект может представлять собой весьма непростую задачу. Задача становится еще более сложной, если нет доступа к исходным текстам интегрируемых компонент. Одной из наиболее известных систем визуализации структуры программ является язык UML. Вместе с тем, существует достаточно много других систем визуального отображения, которые применяются при анализе программного обеспечения. Именно это и является предметом рассмотрения данной статьи. В статье рассмотрены вопросы визуализации метрик пакетов программного обеспечения. Метрики программ есть одно из наиболее активных в использовании направлений, относящихся к анализу программного обеспечения. И визуальный анализ здесь является одним из наиболее часто используемых инструментов. В качестве моделей визуализации рассматриваются графовые и пост-графовые подходы. К числу первых, например, относятся графы дефектов и полиметрические расширения. К пост-графовым моделям визуализации относятся деревья-карты, деревья-кольца, ступенчатые чертежи и полярные диаграммы. Представленные в статье подходы к визуальному анализу программных метрик должны входить в арсенал исследователей и практиков в области программной инженерии.

 

Ключевые слова: качество программного обеспечения, анализ структур программ, анализ связей компонент, анализ данных, анализ программного обеспечения.

 

1. Введение

 

Первый элемент, который вызывает ассоциативные связи со словами “визуализация для программного обеспечения” – это, очевидно, Unified Modeling Language (UML) [1]. По своему назначению, UML есть визуальный язык моделирования. В частности, он может использоваться для анализа, проектирования и реализации программных систем. Диаграммы UML представляют собой один из наиболее известных способов графического представления программных компонент.

UML 2 поддерживает множество вариантов диаграмм, которые могут быть разделены на два типа [2]. Диаграммы представляют либо структурную информацию, либо поведенческие аспекты (включая взаимодействие). На рисунке 1 представлен набор диаграмм UML.

 

Рис. 1. Типы диаграмм в UML.

 

UML представляет собой, пожалуй, наиболее известный графический инструмент, связанный с анализом программных систем и комплексов. Использование UML достаточно подробно описано в литературе, поэтому в данной статье мы хотим остановиться на других методах визуального представления и визуального анализа, применяемых при разработке (сопровождении) программных систем. Такие методы есть, достаточно активно используются. Формально, это никак не связано с UML. В некоторых подходах можно заметить использование концепций UML в реализации, большинство же подходов к визуализации разрабатывались совершенно независимо.

 

2. Метрики

 

Метрики для программных систем – это функции, которые позволяют вычислять (“измерять”) некоторые стандартные значения (“измерения”), используемые в дальнейшем для разного рода сравнительного анализа [3]. Строго говоря, метрика — это функция (процесс измерения), но, в большинстве случаев, не делают разницы между процессом и результатом, отождествляя метрику именно с результатом измерения. Идея использования количественных показателей процесса, естественно, не нова. Очевидно, что именно цифровые (количественные) показатели являются фундаментом для любого сравнительного анализа. Соответственно, и визуализация используется в этой области очень часто [4]. Идеи использования количественных метрик (оценок) для программного обеспечения активно продвигаются многими производителями. Метрики используются для планирования, оценки стоимости, как показатели качества и для оценки производительности. На рисунке 2 представлен плагин для среды Eclipse, который позволяет отображать ряд метрик для Java проектов: System Complexity View, Class and Package Dependency View [5]

 

Рис. 2. Визуализация метрик для Java проекта [5]

 

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

Для оценки качества программных проектов были предложены наборы объектно-ориентированных метрик [6-8], которые позволяют оценивать исходные тексты программ, написанных на различных объектно-ориентированных языках программирования. Результаты измерения качества проектов с помощью объектно-ориентированных метрик представлялись в виде таблиц, содержащих числовые значения для десятков предопределенных метрик (колонок таблицы) и сотен измеренных элементов проекта (строк таблицы). Решение о том, каким образом следует интерпретировать представленные в табличной форме значения метрик, как их использовать для выполнения рефакторинга системы с целью улучшения характеристик проекта, оставлялось на усмотрение пользователю инструмента измерения [9]. При этом визуализация структуры модели программного обеспечения и визуализация результатов измерения качества этого программного обеспечения очень важны.

 

3. Графы дефектов

 

В данном разделе мы опишем визуальные структуры, используемые для отображения и поиска дефектов в объектно-ориентированном коде. Для визуализации результатов поиска дефектов используются два полиметрических представления [6]. Представление (вид) «черновик класса» - это полиметрический вид с уровневой визуализацией, показывающей потоки управления класса и доступ к атрибутам класса. Вид «сложность системы» показывает иерархию наследования с указанием сложности каждого элемента – количества атрибутов, методов класса и его объема в строках или байтах. Эти два полиметрических вида используются для визуализации обнаруженных дефектов [9].

В основе визуального представления лежит изображение графа. Узлы графа при этом используются для представления элементов модели программной системы или их абстракций. Ребра используются для представления отношений между этими элементами. Такая графическая нотация традиционно используется для представления моделей. Для визуализации полиметрической информации об элементах модели используются расширения графической нотации, показанные на рисунке 3.

 

Рис. 3. Модель полиметрического расширения [9]

 

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

 

Рис. 4 Полиметрический граф [10]

 

Цвет узла графа представляет измерение третьей метрики для такого элемента модели. Значения цвета могут задаваться в шкале серого цвета для представления всех значений метрики, либо определенными цветами для выделения элементов, значение метрики которых превысили некоторое пороговое значение. Например, высота узла представляет собой метрику Number Of Methods (NOM) показывающую количество методов в классе, ширина узла представляет метрику Number Of Attributes (NOA) показывающую количество атрибутов в классе, а оттенки серого цвета узла представляет значения метрики Lines Of Code (LOC).

В некоторых формах представления координаты узла представляют собой значения двух метрик. Естественно, что для такого полиметрического вида требуется наличие системы координат. Толщина и цвет ребра графа могут дополнительно представлять в полиметрическом виде значения еще двух метрик. Например, так мы можем представлять интенсивность вызова методов одного класса из методов другого класса.

В качестве метрик для такого рода графов могут использоваться самые разные измерения. Например, абстрактность (Abstractness) [11], нестабильность (Instability) [12], метрики наследования (Inheritance), размера/сложности (Size&Complexity) и связанности (Coupling) [13].

В частности, к метрикам размера и сложности относится следующее: Number Of Packages (NOP) – количество пакетов, Number Of Classes (NOC) – количество классов, Number Of Methods (NOM) – количество методов, Line Of Code (LOC) – количество строк кода в системе. Часто используемым значением является Сyclomatic Сomplexity (CYCLO) [6] – метрика определяющая насколько код программы является разветвленным (так называемая условная сложность). Например, значение метрики 0.2 означает, что новая ветвь добавляется через каждые 5 строк.

Базовым визуальным представлением (отображением) является так называемая пирамида обзора (рисунок 5) [14].

 

Рис. 5. Пирамида обзора [15]

 

В таком представлении метрики одной категории располагаются рядом, в одной области. Значения метрик из одной категории принимают возрастающие значения и показываются шириной узла. Таким образом, получается изображение ступенчатой пирамиды, как и показано на рисунке 5.Для ступеней этой пирамиды вычисляются средние пропорции. Например, пропорция LOC / NOM = 9.27 показывает, насколько хорошо код распределен среди методов.

С помощью сцепления (Coupling) метрик определяется насколько сцепление интенсивно и распределено. Метрика CALLS представляет общее число вызовов различных методов в системе. Если какой либо метод вызывается в другом методе многократно, то он учитывается только один раз. Вторая метрика вычисляется как сумма метрик FUNOUT [6] (количество вызванных методом классов) для всех методов системы. То есть классов, из которых операции вызывают методы.

С использованием указанных значений метрик вычисляются две пропорции: интенсивность сцепления Coupling Intensity = CALLS / NOM, и дисперсия сцепления Coupling Dispersion = (FANOUT / Operation Call). Высокое значение интенсивности сцепления означает чрезмерное общение метода со своими «коллегами». Высокое значение дисперсии сцепления означает чрезмерное общение с «коллегами» из других классов. Например, значение 0.2 для дисперсии означает, что каждый второй вызов направлен в другой класс.

Верхние элементы пирамиды обзора представляют метрики, описывающие использование в системе иерархии классов и полиморфизма. Эти метрики определяют, насколько измеряемая система является объектно-ориентированной. Первая метрика - Average Number of Derived Classes (ANDC) вычисляется как общее число прямых подклассов класса, деленное на количество классов в измеряемой системе. Интерфейсы и библиотечные классы в таком подсчете не учитываются. Если у класса нет потомков, то этот класс добавляет 0 к значению метрики ANDC. Вторая метрика - Average Hierarchy Height (AHH) есть общая высота наследования. Она вычисляется как сумма метрик Height of the Inheritance Tree (HIT) - высоты дерева наследования вычисленной для всех классов являющихся корнем в дереве наследования. Для классов, которые не имеют предков, значение метрики HIT равно 0. Таким образом, метрика ANDC представляет ширину деревьев наследования системы, а метрика AHH представляет глубину этих деревьев. Как можно видеть, пирамида обзора предоставляет показанные черным цветом значения прямых метрик (зависят от размера системы) и показанные зеленым пропорции (не зависимые от размера системы). Для интерпретации полученных пропорций предлагается использовать статистические данные, которые получены в результате измерения систем написанных на языках Java (45 систем) и C++ (37 систем) [16]:

 

Рис.6. Статистические значения пропорций

 

Как непосредственный инструмент получения исходных данных в наших проектах практически везде выступали плагины для Eclipse [17]. Именно Eclipse является стандартным инструментом для всех работ по программной инженерии в Лаборатории Открытых информационных технологий факультета ВМК МГУ имени М.В. Ломоносова [18].

Для графовых моделей необходимо заметить, что сама по себе задача изображения (визуализации) графов существуют, конечно, и безо всякой связи с анализом метрик программного обеспечения просто в силу широкого использования представлений в виде графов в самых разных областях. Достаточно упомянуть хотя бы растущий интерес к графовым базам данных (представление социальных сетей и т.п.) [19]. Из отечественных работ в этой области можно отметить статью [20] и монографию [21].

 

4. Пост-графовые модели визуализации программных метрик

 

В данном разделе рассмотрены методы визуализации метрик программного обеспечения, которые не основаны на представлении в виде графов.

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

На рисунке 7 показана карта распределения для графического редактора Jedit [22]. Красным цветом, в частности, на рисунке показаны классы ядра, представляющие классы и интерфейсы, расположенные в верхней части иерархии наследования. Голубым цветом показаны классы, представляющие собой интерфейс пользователя. Зеленым цветом показываются внутренние классификаторы редактора с различной видимостью классификатора.

 

 

Рис.7. Карта распределения для редактора JEdit

 

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

Карты распределения являются достаточно гибким способом визуализации и применимы к папкам/файлам, пакетам/классам, классам/методам и другим группам. Отображаемые свойства элементов должны быть взаимно исключающими. Для навигации по картам распределения можно использовать вложенность таких карт, перемещаясь, например, от карты, показывающей вложенность исполняемых файлов в папки, к карте, показывающей вложенность в файл пакетов языка Java [23].

Упоминавшиеся выше графы (деревья) могут быть достаточно большими. Соответственно, навигация для такого рода изображений может быть затруднена. Способ визуализации с помощью более компактных карт деревьев позволяет более рационально использовать пространство экрана. Все дерево в этом случае представляется прямоугольником. Каждое поддерево, в свою очередь, представляется прямоугольником в родительском прямоугольнике. Первый уровень в иерархии представляется с помощью вертикального расщепления родительского прямоугольника. Второй уровень расщепляет родительский прямоугольник горизонтально. Такое чередование вертикального и горизонтального расщепления продолжается при перемещении на следующие уровни иерархии. Это проиллюстрировано на рисунке 8, где показаны дерево и соответствующая ему карта.

 

 Рис.8. Принцип конструирования дерева-карты [23]

 

Пример использование карты дерева для представления дерева, состоящего из элементов Java - программы: пакетов, классов и методов приведен на рисунке 9. Весь прямоугольник в целом представляет пакет языка Java. Вложенные прямоугольники первого уровня с белыми границами — классы языка Java. Вложенные прямоугольники представляют методы класса. С помощью цвета методов показываются значения метрик, вычисленных для этих методов. Для представления значений метрик возможно использование не только цвета, но также ширины и высоты прямоугольников. В этом случае необходимо использование более сложных алгоритмов для компактного заполнения пространства родительского прямоугольника.

 

Рис.9. Визуализация структуры Java программы с помощью карты дерева [24]

 

Еще один способ компактного представления – это так называемые деревья-кольца [25]. Те же самые цели, что и с картами - более компактное представление на экране и упрощение навигации. Деревья — кольца показывают топологию и размер узлов дерева [26]. Пример использования такого дерева приведен на рисунке 10.

 

Рис.10. Принцип конструирования деревьев-колец [24]

 

Размер узла в этом случае определяется углом сектора, занимаемого на диаграмме. На дереве-кольце можно показать с помощью цвета и размера узла две метрики. К недостатку данного метода визуализации следует отнести необходимость интерактивного масштабирования диаграммы. Достоинством такого способа визуализации, по сравнению с деревьями-картами, является более ясное представление вложенности элементов программы.

Как видно из предшествующего описания – все это разные способы представления деревьев. Еще один подход, используемый при визуализации метрик – это так называемый ступенчатый чертеж (icicle plot) [28]. Каждая «строка» чертежа представляет собой уровень дерева, как показано на рисунке 11. Каждая строка разбивается в соответствии с числом узлов-потомков у поддерева. В отличие от деревьев-колец, ступенчатый чертеж может содержать пустое пространство. Размер и цвет узла в каждой линии могут представлять значения метрик для этого. Этот способ представления лучше показывает структуру дерева, чем дерево-карта, но имеет меньшее количество представляемых метрик

 

 Рис.11. Принцип конструирования ступенчатого чертежа

 

Визуальное представление «элементы файла» (File Dot) позволяет оценить содержимое файла, основываясь на элементах строк [29]. Файл представляется как сетка, состоящая из квадратов. Каждый квадрат представляет строку файла с исходными текстами программы. Такое представление может быть использовано для визуализации значений метрик при оценке сложности кода или визуализации управляющей структуры кода. Пример визуализации управляющих конструкций программы приведен на рисунке 12. Такой способ визуализации файла кода может применяться также для представления авторства кода, кода модифицирующего или только использующего переменные, кода, имеющего доступ к глобальным переменным и т.д. Для большей наглядности, авторы в работе [30] предложили 3-х мерные расширения для такого рода визуализации. Вместе с тем, все, что связано с трехмерным представлением программных метрик может быть темой отдельной статьи.

Полярная диаграмма (Radar chart) предназначена для одновременной визуализации нескольких свойств элемента программной системы [31]. Из центра диаграммы (полюса) рисуется несколько осей координат. По каждой оси откладывается значение метрики. Минимальные значения помещаются в центре диаграммы. Максимальные значения на конце оси координат. Значения по каждой оси масштабируются линейно. Затем значения на каждой из осей соединяются ломаной линией. На рисунке 13 показана визуализация значений метрик используемых для оценки исходного кода программы. В частности, на этой диаграмме показаны количество функций в классе, количество строк кода, количество комментариев и операторов.

 

Рис.12. Визуализация управляющих конструкций в файлах [30].

 

Полярные диаграммы удобны также для визуализации эволюции программного обеспечения.

 

Рис.13. Метрики на полярной диаграмме.

 

Полярную диаграмму можно использовать и для сравнения на диаграмме значений метрик. Некоторые из метрик программной системы являются взаимосвязанными. Например, в каком либо из отношений класс/пакет может быть клиентом/поставщиком отношения. Класс может быть предком/потомком отношения наследования. Некоторые метрики вычисляются на основе количества таких отношений. Поэтому используемые для отображения значений метрик оси полярной диаграммы имеет смысл расположить симметрично (слева и справа). Полученное изображение значений метрик напоминает изображение бабочки, давшее название такого рода диаграммам [32]. На рисунке 14 показана диаграмма с такими симметрично отражаемыми метриками, показывающими взаимосвязь пакетов друг с другом.

 

 

Рис. 14. Бабочка.

 

На диаграмме представлены значения следующих метрик:

ASC (Number of Ancestor State as Client). Количество доступов к переменным экземпляра родительского класса определенного в другом пакете.

RFP (Number of Class References From Other Packages). Количество ссылок на классы из классов, принадлежащих другим пакетам, на классы, принадлежащие анализируемому пакету.

EIC (Number of External Inheritance as Client). Количество отношений наследования, в которых анализируемый класс есть потомок, а родительский класс расположен в другом пакете.

EIP (Number of External Inheritance as Provider). Количество отношений наследования, где родительский класс в анализируемом пакете, а класс-потомок в другом пакете.

NCP (Number of Classes in a Package). Количество классов в пакете.

Левое крыло «бабочки» на диаграмме показывает, что пакет предоставляет другим пакетам. Правое крыло показывает, что пакет использует из других пакетов. Нижняя часть бабочки показывает, входят ли в пакет классы, имеющие потомков в других пакетах, а также являются ли классы пакета потомками классов из других пакетов.

 

5. Заключение

 

 В данной статье мы остановились на визуальном представлении метрик для программного обеспечения. Тогда как UML (и в целом – представление на основе графов) являются общеизвестным инструментом для графического представления программных компонент, существуют много других подходов, не связанных (по крайней мере, непосредственно) с визуализацией графов и используемых для графического анализа метрик программного обеспечения. Нам кажется, что представленные в данном обзоре подходы должны входить в арсенал исследователей и практиков в области программной инженерии. Из элементов, не вошедших в данный обзор можно отметить все средства трехмерной визуализации. Это активно развивающееся направление заслуживает отдельной статьи.

 

Список литературы

 

  1. Agarwal R., Sinha A. P. Object-oriented modeling with UML: a study of developers' perceptions. Communications of the ACM. 2003. Vol. 46. No. 9. Pp. 248-256.
  2. OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.4.1. Object Management Group. Retrieved Oct 2015
  3. Fenton N., Bieman J. Software metrics: a rigorous and practical approach. CRC Press, 2014.
  4. Wettel R., Lanza M. Visual exploration of large-scale system evolution. Reverse Engineering, 2008. WCRE'08. 15th Working Conference on. IEEE, 2008. pp. 219-228.
  5. X-Ray plugin http://xray.inf.usi.ch/xray.php
  6. Mark Lorenz and Jeff Kidd. Object-Oriented Software Metrics: A Practical Guide. Prentice-Hall, 1994.
  7. Boehm B., Brown W. Value-based software metrics. IEE Seminar Digests, 2004(909):4–6, 2004.
  8. Demeyer S., Ducasse S., Nierstrasz O. Finding Refactorings via Change Metrics. OOPSLA ‘00, 10/00 Minneapolis, MN, USA 2000 ACM ISBN 1-58113-200-x/00/0010
  9. Романов В.Ю. Визуализация для измерения и рефакторинга программного обеспечения. International Journal of Open Information Technologies. 2013. Т. 1. №. 9. С. 1-10.
  10. Caserta P., Zendra O. Visualization of the static aspects of software: a survey. Visualization and Computer Graphics, IEEE Transactions on. 2011. Vol. 17. No. 7. Pp. 913-933.
  11. Robert C. Martin. Designing Object Oriented Applications using UML, 2d.ed. Prentice Hall, 1999
  12. Романов В. Ю. Инструмент обратного проектирования и рефакторинга программного обеспечения написанного на языке Java. International Journal of Open Information Technologies. 2013. Т. 1. №. 8. С. 1-6.
  13. Harrison R., Counsell S., Nithi R. Coupling metrics for object-oriented design. Software Metrics Symposium, 1998. Metrics 1998. Proceedings. Fifth International. IEEE, 1998. pp. 150-157.
  14. Lanza M., Marinescu R. Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems. Springer Science & Business Media, 2007.
  15. PHP depend http://pdepend.org/screenshots/full/pyramid.html Retrieved: Dec, 2015
  16. Lanza M., Ducasse S. Polymetric Views—A Lightweight Visual Approach to Reverse Engineering, Transactions on Software Engineering (TSE). IEEE Computer Society. Vol. 29, pp. 782–795. 2003
  17. Lüer C. Evaluating the Eclipse platform as a composition environment. 3 rd International Workshop on Adoption-Centric Software Engineering. 2003. 59 p.
  18. Намиот Д., Сухомлин В. О проектах лаборатории ОИТ. International Journal of Open Information Technologies. 2013. Vol. 1. No. 5. Pp. 18-21.
  19. Jindal A. et al. Vertexica: your relational friend for graph analytics! Proceedings of the VLDB Endowment. 2014. Vol. 7. No. 13. Pp. 1669-1672.
  20. Касьянов В.Н., Касьянова Е.В. Визуализация информации на основе графовых моделей. Научная визуализация. 2014. Т. 6, №1. С. 31 – 50.
  21. Касьянов В.Н., Касьянова Е.В. Визуализация графов и графовых моделей. Сибирское Научное Издательство, 2010.
  22. Ducasse S., Girba T., Kuhn A. Distribution Map. In Proceedings of 22nd IEEE International Conference on Software Maintenance (ICSM '06). IEEE Computer Society. p.203-212. 2006.
  23. Романов В. Ю. Визуализация программных метрик при описании архитектуры программного обеспечения. International Journal of Open Information Technologies. 2014. Т. 2. №. 2. С. 21-28.
  24. Panopticode http://sourceforge.net/projects/panopticode/ Retrieved: Dec, 2015
  25. Therón R. Hierarchical-temporal data visualization using a tree-ring metaphor. Smart graphics. Springer Berlin Heidelberg, 2006. Pp. 70-81.
  26. John T. Stasko, Richard Catrambone, Mark Guzdial, and Kevin Mcdonald. An evaluation of space-filling information visualizations for depicting hierarchical structures. International Journal Humain-Computer Studies, 53(5):663–694, 2000.
  27. Ducasse S. et al. Visualization of Practices and Metrics. Squale project Workpackage. 2010. Vol. 1.
  28. Kruskal J. B., Landwehr J. M. Icicle plots: Better displays for hierarchical clustering. The American Statistician. 1983. Vol. 37. No. 2. Pp. 162-168.
  29. Abram Hindle, Michael W. Godfrey, and Richard C. Holt. Reading beside the lines: Indentation as a proxy for complexity metrics. In ICPC ’08: Proceedings of the 2008 The 16th IEEE International Conference on Program Comprehension, pages 133–142, Washington, DC, USA, 2008. IEEE Computer Society.
  30. Marcus A., Feng L., Maletic J. I. 3D representations for software visualization. Proceedings of the 2003 ACM symposium on Software visualization. ACM, 2003. Pp. 27-ff.
  31. Stephane Ducasse, Michele Lanza, and Laura Ponisio. Butterflies: A visual approach to characterize packages. In Proceedings of the11th EEE International Software Metrics Symposium (METRICS’05), pp. 70–77. IEEE Computer Society, 2005
  32. Martin Pinzger, Harald Gall, Michael Fischer, and Michele Lanza. Visualizing multiple evolution metrics. In Proceedings of SoftVis 2005 (2nd ACM Symposium on Software Visualization), pp. 67–75, St. Louis, Missouri, USA, May 2005.


THE VISUAL ANALYSIS OF SOFTWARE PACKAGES

V.Y. Romanov, D.E. Namiot

Lomonosov Moscow State University, Russian Federation

vladimir.romanov@gmail.com, dnamiot@gmail.com

 

Abstract

This paper provides an overview of methods for software metrics visualization. The main goal of this kind of analysis is an analysis of the quality of the software, as well as the integration of individual components (packages) in the complex software systems. For example, many modern software packages (open source software components) are quite large and complex software systems, so, their integration into any new project could be a very difficult task. The task becomes even more difficult if there is no access to the source code of integrated components. One of the most well-known visualization approaches for software systems is UML. However, there are many other visualization approaches which can be used for analysis of software packages. In our paper, we provide a survey of approaches for software metrics visualization. Software metrics is among of the most active areas of use relating to the software engineering. And visual analysis is one of the most commonly used tools here. As per visualization models, we present graph visualization and post-graph approaches. Presented in the article approaches to visual analysis software metrics should be included in the arsenal of researchers and practitioners in the field of software engineering.

 

Keywords: quality of the software, software metrics, software analysis, visual data analysis.

 

References

 

  1. Agarwal R., Sinha A. P. Object-oriented modeling with UML: a study of developers' perceptions. Communications of the ACM. 2003. Vol. 46. No. 9. Pp. 248-256.
  2. OMG Unified Modeling Language (OMG UML), Superstructure. Version 2.4.1. Object Management Group. Retrieved Oct 2015
  3. Fenton N., Bieman J. Software metrics: a rigorous and practical approach. CRC Press, 2014.
  4. Wettel R., Lanza M. Visual exploration of large-scale system evolution. Reverse Engineering, 2008. WCRE'08. 15th Working Conference on. IEEE, 2008. pp. 219-228.
  5. X-Ray plugin http://xray.inf.usi.ch/xray.php
  6. Mark Lorenz and Jeff Kidd. Object-Oriented Software Metrics: A Practical Guide. Prentice-Hall, 1994.
  7. Boehm B., Brown W. Value-based software metrics. IEE Seminar Digests, 2004(909):4–6, 2004.
  8. Demeyer S., Ducasse S., Nierstrasz O. Finding Refactorings via Change Metrics. OOPSLA ‘00, 10/00 Minneapolis, MN, USA 2000 ACM ISBN 1-58113-200-x/00/0010
  9. Romanov V.Ju. Vizualizacija dlja izmerenija i refaktoringa programmnogo obespechenija [Visualization for measuring and refactoring software]. International Journal of Open Information Technologies. 2013. Vol. 1. No. 9. Pp. 1-10. [In Russian]
  10. Caserta P., Zendra O. Visualization of the static aspects of software: a survey. Visualization and Computer Graphics, IEEE Transactions on. 2011. Vol. 17. No. 7. Pp. 913-933.
  11. Robert C. Martin. Designing Object Oriented Applications using UML, 2d.ed. Prentice Hall, 1999
  12. Romanov V. Ju. Instrument obratnogo proektirovanija i refaktoringa programmnogo obespechenija napisannogo na jazyke Java [A tool for reverse engineering and refactoring of software written in Java]. International Journal of Open Information Technologies. 2013. Vol. 1. No.. 8. Pp. 1-6. [In Russian]
  13. Harrison R., Counsell S., Nithi R. Coupling metrics for object-oriented design. Software Metrics Symposium, 1998. Metrics 1998. Proceedings. Fifth International. IEEE, 1998. pp. 150-157.
  14. Lanza M., Marinescu R. Object-oriented metrics in practice: using software metrics to characterize, evaluate, and improve the design of object-oriented systems. Springer Science & Business Media, 2007.
  15. PHP depend http://pdepend.org/screenshots/full/pyramid.html Retrieved: Dec, 2015
  16. Lanza M., Ducasse S. Polymetric Views—A Lightweight Visual Approach to Reverse Engineering, Transactions on Software Engineering (TSE). IEEE Computer Society. Vol. 29, pp. 782–795. 2003
  17. Lüer C. Evaluating the Eclipse platform as a composition environment. 3 rd International Workshop on Adoption-Centric Software Engineering. 2003. 59 p.
  18. Namiot D., Suhomlin V. O proektah laboratorii OIT [About the projects of the ICU Laboratory]. International Journal of Open Information Technologies. 2013. Vol. 1. No. 5. Pp. 18-21. [In Russian]
  19. Jindal A. et al. Vertexica: your relational friend for graph analytics! Proceedings of the VLDB Endowment. 2014. Vol. 7. No. 13. Pp. 1669-1672.
  20. Kas'janov V.N., Kas'janova E.V. Vizualizacija informacii na osnove grafovyh modelej [Information Visualization on the Base of Graph Models]. Scientific Visualization. 2014. Vol. 6, No.1. Pp. 31 – 50. [In Russian]
  21. Kas'janov V.N., Kas'janova E.V. Vizualizacija grafov i grafovyh modelej [Visualization of graphs and graph models]. Siberian Scientific Publishing House, 2010. [In Russian]
  22. Ducasse S., Girba T., Kuhn A. Distribution Map. In Proceedings of 22nd IEEE International Conference on Software Maintenance (ICSM '06). IEEE Computer Society. p.203-212. 2006.
  23. Romanov V. Ju. Vizualizacija programmnyh metrik pri opisanii arhitektury programmnogo obespechenija [Visualization of software metrics when describing the software architecture]. International Journal of Open Information Technologies. 2014. Vol. 2. No.. 2. Pp. 21-28. [In Russian]
  24. Panopticode http://sourceforge.net/projects/panopticode/ Retrieved: Dec, 2015
  25. Therón R. Hierarchical-temporal data visualization using a tree-ring metaphor. Smart graphics. Springer Berlin Heidelberg, 2006. Pp. 70-81.
  26. John T. Stasko, Richard Catrambone, Mark Guzdial, and Kevin Mcdonald. An evaluation of space-filling information visualizations for depicting hierarchical structures. International Journal Humain-Computer Studies, 53(5):663–694, 2000.
  27. Ducasse S. et al. Visualization of Practices and Metrics. Squale project Workpackage. 2010. Vol. 1.
  28. Kruskal J. B., Landwehr J. M. Icicle plots: Better displays for hierarchical clustering. The American Statistician. 1983. Vol. 37. No. 2. Pp. 162-168.
  29. Abram Hindle, Michael W. Godfrey, and Richard C. Holt. Reading beside the lines: Indentation as a proxy for complexity metrics. In ICPC ’08: Proceedings of the 2008 The 16th IEEE International Conference on Program Comprehension, pages 133–142, Washington, DC, USA, 2008. IEEE Computer Society.
  30. Marcus A., Feng L., Maletic J. I. 3D representations for software visualization. Proceedings of the 2003 ACM symposium on Software visualization. ACM, 2003. Pp. 27-ff.
  31. Stephane Ducasse, Michele Lanza, and Laura Ponisio. Butterflies: A visual approach to characterize packages. In Proceedings of the11th EEE International Software Metrics Symposium (METRICS’05), pp. 70–77. IEEE Computer Society, 2005
  32. Martin Pinzger, Harald Gall, Michael Fischer, and Michele Lanza. Visualizing multiple evolution metrics. In Proceedings of SoftVis 2005 (2nd ACM Symposium on Software Visualization), pp. 67–75, St. Louis, Missouri, USA, May 2005.