IPlasma

iPlasma - це платформа, створена як університетський проект у Румунії, для оцінки якості об'єктно-орієнтованого проектування. Основні результати вимірювання вона відображає у вигляді піраміди (The Overview Pyramid), що відображає значення ключових показників якості вимірюваної об'єктно-орієнтованої системи разом із порівнянням цих значень зі стандартними діапазонами даних показників.

The Overview Pyramid

The Overview Pyramid відображає три основні аспекти об'єктно-орієнтованого проектування:

1. Розмір та складність (наскільки великою та складною є система).
2. Зв'язність (якою мірою класи (об'єкти) пов'язані один з одним).
3. Спадкування (як добре і чи використовується концепція спадкування).

Отже, Overview Pyramid, дозволяє описати і охарактеризувати загальну структуру об'єктно-орієнтованої системи, шляхом кількісного аспекту складності, взаємозв'язку та використання спадкування. Основна ідея даної піраміди зібрати в одному місці найбільш значущі виміряні показники об'єктно-орієнтованої системи, так щоб інженер зміг бачити і інтерпретувати в одному кадрі все, що потрібно, щоб отримати перше враження про систему.

Основні аспекти

Розмір та складність

У лівій частині Overview Pyramid міститься інформація (у вигляді кількісних значень), що характеризує розмір і складність системи. Розмір і складність: прямі показники (тобто, показники обчислюються безпосередньо з вихідного коду). Прямі метрики необхідні для опису системи в простому й абсолютному вираженні. Метрики, що описують розмір і складність, ймовірно, одні із найпростіших і широко використовуваних показників. Вони вважаються найбільш значними модульними одиницями об'єктно-орієнтованої системи, від найвищого рівня (наприклад, пакетів або імен), аж до найнижчого рівня одиниць (тобто рядків коду і незалежні блоки функціональності). Для кожного показника є одна метрика в Overview Pyramid, що вимірює його. Метрики розміщені по одному на рядок зверху вниз. Розмір та складність характеризується 5-ма метриками:

• NOP (Number of packages) — число пакетів
• NOC (Number of classes) — число класів
• NOM (Number of methods) — число методів
• LOC (Lines of code) — кількість рядків коду
• CYCLO (Cyclomatic complexity) — цикломатична складність

Окрім отриманих кількісних показників по кожній метриці: NOP, NOC, NOM, LOC, CYCLO — Overview Pyramid також відображає кількісні значення співвідношень між ними (що вираховуються між двома метриками послідовно знизу вверх): CYCLO/LOC, LOC/NOM, NOM/NOC, NOC/NOP. Всі ці чотири пропорції мають дві основні характеристики: незалежність та порівнянність. У той час як прямі метрики впливають один на одного (наприклад, система 100 класів, ймовірно, має менше методів ніж з 10000 класів), ці пропорції між ними є незалежними один від одного. Що дозволяє порівнювати якість різних за розміром об'єктно-орієнтованих систем. Для характеристики розміру та складності системи використовують значення результатів наступних пропорцій:

• Високий рівень структурування (NOC / NOP). Цей показник дає читачеві перше враження від рівня структурування системи. Іншими словами, значення цієї пропорції відображає наскільки пакети ретельно розроблені.
• Структурування класів (NOM / NOC). Цей показник дає підказку про якість дизайну класу, вона показує, як між класами розподіляються операції.
• Структурування методів (LOC / NOM). Це вказує на те, наскільки добре код розподіляється між операціями. Дуже високі цифри показують, що операції системи є досить «важкими». Це може бути використано як перша ознака, що система побудована з точки зору процедурного програмування.
• Внутрішня складність операції (CYCLO / LOC). Це останнє відношення характеризує, скільки умовних складностей (розгалужень) нас очікують в операціях.

Зв'язність

Друга (права) частина Overview Pyramid містить інформацію про рівень зв'язності класів в системі, за допомогою операції викликів. Зв'язність: прямі показники. Ключові питання при спробі охарактеризувати рівень зв'язності є: Наскільки інтенсивний і як розсіяний зв'язок в системі? Дві прямі метрики, що це відображають:

• CALLS — метрика, що вказує на кількість викликів методу, тобто ця метрика підраховує загальну кількість різних викликів операцій в системі, шляхом підсумовування кількості користувацьких операцій. Якщо операція Foo() викликається три рази методом f1 (), то вона враховується тільки один раз.
• FANOUT — число інших методів, що викликає даний метод, обчислюється як сума розгалуженням метрики (тобто класів, з яких операції викликають методи) для всіх користувальницьких операцій. Цей показник відображає інформацію про те, як розсіяні виклики операції в класах.

Знову ж таки, наведені значення цих двох метрик лише описують загальну суму зв'язності в системі, але їх важко використовувати для характеристики системи по відношенню до взаємозв'язку. Тому, використовуючи ряд операцій (NOM), можна обчислити дві пропорції, які краще характеризують зв'язок системи.

• Інтенсивність (CALLS / Operation). Цей показник позначає рівень співпраці (взаємозв'язок) між операціями, тобто, як багато інших операцій викликаються в середньому від кожної операції.
• Дисперсія (FANOUT / Operation Call). Цей показник є індикатором того, скільки зв'язність включає в себе безліч класів.

Спадкування

Верхня частина: Спадкування. У верхній частині Overview Pyramid немає «сходів», як у попередніх випадках. Вона складається з двох показників, які забезпечують загальну характеристику використання спадкування. Ці метрики показують, наскільки в системі використовується концепція спадкування, згідно об'єктно-орієнтованої парадигми, тобто чи має місце використання ієрархії класів і поліморфізм.

Inheritance (scheme)

Ці дві метрики характеризують наявність та форму ієрархії класів:

• ANDC (Average Number of Derived Classes) — середня кількість похідних класів, тобто середнє число прямих підкласів класу. Враховуються усі класи, що визначені в досліджуваній системи, окрім інтерфейсів та бібліотек класів в Java або C #. Якщо клас не має похідних класів, то він позначається значенням 0 для ANDC. Отримане значення метрика є першим свідченням того, наскільки широко абстракції уточняються за допомогою спадкування.

На рисунку вище представлено як обчислюється ANDC. По-перше, ми вважаємо, що існує 19 класів, так як ми не беремо до уваги Q, тому що це бібліотека класів, ми також не враховуємо T, тому що це інтерфейс. З 19 класів, 11 не мають підкласів, на відміну від: всіх чотирьох класів D, H, J, L, що мають по одному прямому нащадку (підкласу) та трьох класів B, E, N, в яких є 2 прямих підкласів для кожного, а також є один клас А із чотирма прямими нащадками. Таким чином, ANDC обчислюється за формулою:

• AHH (Average Hierarchy Height) — середня висота дерева ієрархії. Метрика обчислюється як середня висота дерева спадкування (HIT) серед корінних класів, визначених у системі. AHH є середня максимальна довжина шляху від кореня до його найглибшого підкласу. Клас вважається коренем, якщо він не є похідним від іншого класу, що належить до аналізованої системи. Інтерфейси Java або C # не враховуються. Автономні класи, що не мають нащадків, вважаються коренем із значенням HIT=0. Число говорить нам, наскільки глибоко клас в ієрархії. Низька чисельність припускає плоску структуру ієрархії класів.

Для того, щоб проілюструвати як обчислюється AHH необхідно повернутися до зразку системи, зображеної на рис. 3.4. По-перше, ми повинні визначити корені класів. На підставі специфікації AHH, ми визначаємо п'ять корнів: A, N, R (оскільки він є похідним від бібліотеки класів), S і U (оскільки реалізація інтерфейсу не робить U підкласом). Для цих кореневих класів значення для HIT метрики: HIT (А) = 4, HIT (N) = 1, HIT (R) = 0, HIT (S) = 0, HIT (U) = 0.Таким чином, AHH обчислюється за формулою: 4 +1 +0 +0 +0, тому AHH =5 Чому були обрані саме ці дві пропорції і чому вони є достатніми? Вони захоплюють два взаємодоповнюючих аспекти ієрархії класів: в той час ANDC дає нам уявлення про ширину спадкування дерев, а значення метрики AHH показує, що ієрархії класів, як правило, або глибока або дрібна. Два показника дають нам перші натяки про те, чи слід очікувати інтенсивного використання відношень спадкування (ANDC) і, якщо це так, вони допомагають нам зрозуміти, наскільки глибокими є ці ієрархії (АНН).

Завантажити

iPlasma являє собою інтегроване середовище для аналізу якості об'єктно-орієнтованого програмного забезпечення. iPlasma був успішно використаний для аналізу об'єктно-орієнтованих систем, включаючи дуже великі системи з відкритим кодом (> 1 MLOC), як напр. Mozilla (C + +, 2560000 LOC) та Eclipse, (Java, 1360000 LOC). iPlasma був також використаний як консультація для промислових партнерів, більшість з них беруть участь в розробці великих програмних додатків для систем телекомунікацій. Даний продукт може бути завантажений з http://loose.upt.ro/iplasma/iplasma.zip [Архівовано 4 березня 2016 у Wayback Machine.].

Джерела

M. Lanza and R. Marinescu, Object-Oriented Metrics in Practice: Using Software Metrics to Characterize, Evaluate, and Improve the Design of Object-Oriented Systems. Springer, 2006. http://www.springer.com/gp/book/9783540244295 [Архівовано 13 березня 2015 у Wayback Machine.]

iPlasma: An Integrated Environment for Quality Analysis of Object-Oriented Software Systems https://web.archive.org/web/20150214164909/http://loose.upt.ro/reengineering/research/iplasma