Architecture metrics: a servey of the potential to improve softwar

Architecture metrics: a servey of the potential to improve softwar

Software development hinges on well-crafted architecture, a foundational phase that influences the entire system. This study investigates using architectural design metrics, which quantify various aspects of architecture. We conducted a systematic mapping study, analysing existing literature to unde...

Full description

Saved in:
Bibliographic Details
Date:2024
Main Author: Liubchenko, V.V.
Format: Article
Language:Ukrainian
Published: PROBLEMS IN PROGRAMMING 2024
Subjects:
software architecture design metrics
systematic mapping study
software design evaluation
architectural quality attributes
UDC 004.05
Online Access:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/625
Tags: Add Tag
No Tags, Be the first to tag this record!
Journal Title:Problems in programming
Download file: Pdf

Institution

Problems in programming
id pp_isofts_kiev_ua-article-625
record_format ojs
resource_txt_mv ppisoftskievua/e4/74884ff2b6f8bb74b5d453c304a71be4.pdf
spelling pp_isofts_kiev_ua-article-6252025-02-15T10:14:48Z Architecture metrics: a servey of the potential to improve softwar Архітектурні метрики: огляд потенціалу для покращення програмного забезпечення Liubchenko, V.V. software architecture design metrics; systematic mapping study; software design evaluation; architectural quality attributes UDC 004.05 метрики архитектурного проєктування; систематичне дослідження публікацій; оцінювання проєкту програмного забезпечнння; атрибути якості архітектури УДК 004.05 Software development hinges on well-crafted architecture, a foundational phase that influences the entire system. This study investigates using architectural design metrics, which quantify various aspects of architecture. We conducted a systematic mapping study, analysing existing literature to understand how these metrics are currently employed. Our findings reveal a limited yet promising landscape. Metrics exist to assess design stability, understandability, modularity, and security. Notably, several studies explore gauging the "option-generation ability" of an architecture and its potential to generate different design choices. However, a gap exists in directly using these metrics for fault prediction. Existing research primarily focuses on the "reverse" effect, where metrics from later development stages (like code) are used to identify architectural issues. Overall, this study highlights the underutilised potential of architectural design metrics. While current research demonstrates the effectiveness of a relatively simple set of metrics for various purposes, further exploration is warranted. Future efforts should delve into data accumulation and investigate models for using these metrics for predictive purposes, ultimately enhancing software quality and development processes.Problems in programming 2024; 2-3: 99-106 Розроблення програмного забезпечення залежить від добре продуманої архітектури, яка впливає на всю систему. У цьому дослідженні розглядається використання метрик архітектурного проєктування, які кількісно оцінюють різні аспекти архітектури. Ми провели систематичне картографічне дослідження, проаналізувавши існуючу літературу, щоб зрозуміти, як ці метрики використовуються зараз. Наші висновки показують обмежений, але багатообіцяючий ландшафт. Існують метрики для оцінки стабільності, зрозумілості, модульності та безпеки проєкту. Зокрема, кілька досліджень вивчають вимірювання «здатності генерувати варіанти» архітектури та її потенціалу генерувати різні проєктні варіанти. Однак існує прогалина у безпосередньому використанні цих метрик для прогнозування несправностей. Існуючі дослідження зосереджені переважно на «зворотному» ефекті, коли метрики з більш пізніх етапів розроблення (наприклад, характеристики коду) використовуються для виявлення архітектурних проблем. Загалом, це дослідження підкреслює недостатньо використаний потенціал метрик архітектурного проєктування. Хоча поточні дослідження демонструють ефективність відносно простого набору метрик для різних цілей, подальші дослідження є виправданими. Майбутні зусилля повинні бути спрямовані на накопичення даних і дослідження моделей для використання цих метрик з метою прогнозування, що в результаті підвищить якість програмного забезпечення та покращить процеси розробки.Problems in programming 2024; 2-3: 99-106  PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2024-12-17 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/625 10.15407/pp2024.02-03.099 PROBLEMS IN PROGRAMMING; No 2-3 (2024); 99-106 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2024); 99-106 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2024); 99-106 1727-4907 10.15407/pp2024.02-03 uk https://pp.isofts.kiev.ua/index.php/ojs1/article/view/625/677 Copyright (c) 2024 PROBLEMS IN PROGRAMMING
institution Problems in programming
baseUrl_str https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date 2025-02-15T10:14:48Z
collection OJS
language Ukrainian
topic software architecture design metrics
systematic mapping study
software design evaluation
architectural quality attributes
UDC 004.05
spellingShingle software architecture design metrics
systematic mapping study
software design evaluation
architectural quality attributes
UDC 004.05
Liubchenko, V.V.
Architecture metrics: a servey of the potential to improve softwar
topic_facet software architecture design metrics
systematic mapping study
software design evaluation
architectural quality attributes
UDC 004.05
метрики архитектурного проєктування
систематичне дослідження публікацій
оцінювання проєкту програмного забезпечнння
атрибути якості архітектури
УДК 004.05
format Article
author Liubchenko, V.V.
author_facet Liubchenko, V.V.
author_sort Liubchenko, V.V.
title Architecture metrics: a servey of the potential to improve softwar
title_short Architecture metrics: a servey of the potential to improve softwar
title_full Architecture metrics: a servey of the potential to improve softwar
title_fullStr Architecture metrics: a servey of the potential to improve softwar
title_full_unstemmed Architecture metrics: a servey of the potential to improve softwar
title_sort architecture metrics: a servey of the potential to improve softwar
title_alt Архітектурні метрики: огляд потенціалу для покращення програмного забезпечення
description Software development hinges on well-crafted architecture, a foundational phase that influences the entire system. This study investigates using architectural design metrics, which quantify various aspects of architecture. We conducted a systematic mapping study, analysing existing literature to understand how these metrics are currently employed. Our findings reveal a limited yet promising landscape. Metrics exist to assess design stability, understandability, modularity, and security. Notably, several studies explore gauging the "option-generation ability" of an architecture and its potential to generate different design choices. However, a gap exists in directly using these metrics for fault prediction. Existing research primarily focuses on the "reverse" effect, where metrics from later development stages (like code) are used to identify architectural issues. Overall, this study highlights the underutilised potential of architectural design metrics. While current research demonstrates the effectiveness of a relatively simple set of metrics for various purposes, further exploration is warranted. Future efforts should delve into data accumulation and investigate models for using these metrics for predictive purposes, ultimately enhancing software quality and development processes.Problems in programming 2024; 2-3: 99-106
publisher PROBLEMS IN PROGRAMMING
publishDate 2024
url https://pp.isofts.kiev.ua/index.php/ojs1/article/view/625
work_keys_str_mv AT liubchenkovv architecturemetricsaserveyofthepotentialtoimprovesoftwar
AT liubchenkovv arhítekturnímetrikioglâdpotencíaludlâpokraŝennâprogramnogozabezpečennâ
first_indexed 2025-07-17T09:47:21Z
last_indexed 2025-07-17T09:47:21Z
_version_ 1850409835936350208
fulltext Архітектура програмного забезпечення 99 УДК 004.05 http://doi.org/10.15407/pp2024.02-03.099 В.В. Любченко АРХІТЕКТУРНІ МЕТРИКИ: ОГЛЯД ПОТЕНЦІАЛУ ДЛЯ ПОКРАЩЕННЯ ПРОГРАМНОГО ЗАБЕЗПЕЧЕННЯ Розроблення програмного забезпечення залежить від добре продуманої архітектури, яка впливає на всю систему. У цьому дослідженні розглядається використання метрик архітектурного проєктування, які кількісно оцінюють різні аспекти архітектури. Ми провели систематичне картографічне до- слідження, проаналізувавши існуючу літературу, щоб зрозуміти, як ці метрики використовуються за- раз. Наші висновки показують обмежений, але багатообіцяючий ландшафт. Існують метрики для оцінки стабільності, зрозумілості, модульності та безпеки проєкту. Зокрема, кілька досліджень вив- чають вимірювання «здатності генерувати варіанти» архітектури та її потенціалу генерувати різні проєктні варіанти. Однак існує прогалина у безпосередньому використанні цих метрик для прогно- зування несправностей. Існуючі дослідження зосереджені переважно на «зворотному» ефекті, коли метрики з більш пізніх етапів розроблення (наприклад, характеристики коду) використовуються для виявлення архітектурних проблем. Загалом, це дослідження підкреслює недостатньо використаний потенціал метрик архітектурного проєктування. Хоча поточні дослідження демонструють ефек- тивність відносно простого набору метрик для різних цілей, подальші дослідження є виправданими. Майбутні зусилля повинні бути спрямовані на накопичення даних і дослідження моделей для вико- ристання цих метрик з метою прогнозування, що в результаті підвищить якість програмного забезпе- чення та покращить процеси розробки. Ключові слова: метрики архитектурного проєктування, систематичне дослідження публікацій, оці- нювання проєкту програмного забезпечнння, атрибути якості архітектури. V. Liubchenko ARCHITECTURE METRICS: A SURVEY OF THE POTENTIAL TO IMPROVE SOFTWARE Software development hinges on well-crafted architecture, a foundational phase that influences the entire system. This study investigates using architectural design metrics, which quantify various aspects of archi- tecture. We conducted a systematic mapping study, analysing existing literature to understand how these metrics are currently employed. Our findings reveal a limited yet promising landscape. Metrics exist to as- sess design stability, understandability, modularity, and security. Notably, several studies explore gauging the "option-generation ability" of an architecture and its potential to generate different design choices. How- ever, a gap exists in directly using these metrics for fault prediction. Existing research primarily focuses on the "reverse" effect, where metrics from later development stages (like code) are used to identify architec- tural issues. Overall, this study highlights the underutilised potential of architectural design metrics. While current research demonstrates the effectiveness of a relatively simple set of metrics for various purposes, further exploration is warranted. Future efforts should delve into data accumulation and investigate models for using these metrics for predictive purposes, ultimately enhancing software quality and development pro- cesses. Keywords: software architecture design metrics, systematic mapping study, software design evaluation, ar- chitectural quality attributes. Вступ Розроблення програмного забезпе- чення (ПЗ) значною мірою покладається на архітектурне проєктування – ключовий етап, який суттєво впливає на кінцеву сис- тему. По суті, архітектурне проєктування передбачає створення високорівневої абс- тракції топології, функціональності та по- ведінки системи, що закладає основу для детального проєктування та реалізації. Іс- нує багато визначень архітектури ПЗ, але всі вони, як правило, стосуються компоне- нтів, модулів та їхніх взаємозв'язків. © В.В.Любченко, 2024 ISSN 1727-4907. Проблеми програмування. 2024. №2-3 Архітектура програмного забезпечення 100 Керуючись усталеними моделями проєктування, найкращими практиками та міркуваннями зацікавлених сторін, архіте- ктурне проєктування має надавати пріори- тет дотриманню перевірених методологій. Цей процес часто передбачає пошук комп- ромісів для узгодження суперечливих ці- лей. Ретельно спланований дизайн є неза- мінним на всіх етапах створення та розви- тку системи, особливо при внесенні змін та адаптації. Якісна архітектура слугує основою для поточної розробки ПЗ. Логічно припу- стити, що атрибути архітектурного дизай- ну формують якості окремих артефактів розробки та ПЗ в цілому. Якби ми могли кількісно описати ці залежності та впливи, то могли б передбачити характеристики цих артефактів і всієї програмної системи. Набори даних, які зазвичай викори- стовуються в емпіричних дослідженнях програмної інженерії, такі як репозиторії NASA, переважно містять характеристики коду та метрики дефектів. Отже, доречно дослідити використання та призначення метрик, що описують архітектурний ди- зайн, в опублікованих дослідженнях. Самі собою метрики не визначають якість архітектури як хорошу чи погану. Однак вони слугують цінними допоміж- ними засобами для архітекторів, висвіт- люючи потенційні проблемні елементи та сфери, які потребують вдосконалення в їх- ніх проєктах. Інструмент аналізу архітек- тури ПЗ обчислює різні метрики, дотри- муючись певних рекомендацій щодо мет- рик ПЗ, а саме: - метрики мають бути зрозуміли- ми та простими для розуміння та застосування. - метрики повинні відповідати очікуванням та практичному досвіду інженерів. - метрики повинні давати одно- значні результати. - метрики мають підтримувати математичну узгодженість. - метрики мають бути застосовні до різних мов програмування. - метрики повинні пропонувати дієві ідеї для покращення якості та продуктивності ПЗ. Основна мета цієї статті – узагаль- нити існуючий досвід використання мет- рик архітектурного проєктування. Крім то- го, ми прагнемо визначити перспективні сфери їхнього застосування для покращен- ня процесу розроблення ПЗ, так і кінцево- го продукту. 1. Метод дослідження Ми провели систематичне дослі- дження публікацій, щоб проаналізувати іс- нуючі публікації про використання метрик архітектурного дизайну ПЗ. Це досліджен- ня є цінним інструментом для вивчення еволюції досліджень у цій галузі з плином часу. Нижче ми описуємо методологію, яка була використана у процесі проведен- ня цього дослідження. Основною метою цього досліджен- ня є систематизація метрик, що характе- ризують дизайн архітектури та методи їх- нього застосування в процесах програмної інженерії, з фокусом на моделях якості та мета-моделях. Для досягнення цієї мети ми дослідили простір метрик проєктуван- ня ПЗ та їх підтримку для процесів про- грамної інженерії. Це дослідження має на меті надати огляд сучасних досліджень з оцінки архітектури ПЗ, зосереджуючись на метриках, визначених для архітектур- них діаграм. Питання дослідження є на- ступними: RQ1. Які метрики застосовуються до архітектурного дизайну? Це питання є ключовим, оскільки воно формує основу нашого розуміння того, як вимірюється та оцінюється архітектурний дизайн. RQ2. Для яких цілей вони застосо- вуються? Щоб відповісти на ці запитання, було розроблено процес пошуку. Ми провели пошук у чотирьох до- відкових базах даних: IEEE Xplore, ACM Digital Library, ScienceDirect та Elsevier, щоб знайти статті про метрики проекту- вання архітектури. Основними ключовими словами були "дизайн архітектури ПЗ" та "метрики". Пошук охоплював поля назви, ано- тації та ключові сліва, а також сформульо- ваний пошуковий рядок: Архітектура програмного забезпечення 101 ("software architecture design") AND (("metrics" OR "measuring")). Цей рядок було закодовано відпо- відно до синтаксичного формату кожної відповідної бази даних. Пошук у базах дав початковий на- бір з 97 статей. Ці статті пройшли фільтра- цію у два етапи на основі попередньо ви- значених критеріїв відбору На першому етапі ми використову- вали ряд критеріїв включення та виклю- чення для розгляду та відбору статей. До розгляду включалися статті написані анг- лійською мовою, опубліковані в журналах або матеріалах конференцій, тема яких по- в'язана з проектуванням та вимірюванням архітектури ПЗ. З розгляду були виключе- ні статті, написані як систематичні дослі- дження публікацій, або предметом яких є не ПЗ, а архітектура апаратної інфраструк- тури. Також були виключені статті про ме- трики призначені для конкретної характе- ристики якості, такої як безпека. На другому етапі фільтрація базу- валася на ознайомленні з повним текстом. Як наслідок були відфільтровані, напри- клад, роботи з метрик подібності, метрик детального проектування та програмного коду, залежностей між властивостями коду та "запахом" архітектури, а також бази знань про архітектуру. Після процедури відбору для сис- тематичного картографічного дослідження було відібрано лише 19 первинних робіт, що становить лише 19,6% від початкового набору даних. Така обмежена кількість пі- дкреслює очевидний брак значного досві- ду успішного застосування таких метрик. 2. Результати аналізу Перша метрика, яка нас цікавить, – це вартість, пов'язана з еволюцією архітек- турних проєктів [1]. Еволюція програмгої архітектури передбачає зміни в компонен- тах та з'єднувачах. Для оцінки еволюції ав- тори запропонували метрики на основі операцій перезапису: додавання, видален- ня та модифікація. Автори визначили вар- тість змін як зважену суму вартості кожної операції. Метрика досить складна, її засто- сування дуже специфічне. Того ж року в [2] було описано цілу низку архітектурних метрик, зокрема, зв'я- зність, зчеплення, складність сервісів, кі- лькість послуг на компонент, fan-in і fan- out, глибина сценарію. Це дослідження ці- каве тим, що більшість перелічених мет- рик були використані в багатьох пізніших дослідженнях. Також тут зроблено спробу встановити зв'язок з фазою аналізу вимог: метрика глибини сценарію орієнтована на складність сценаріїв використання, а не на внутрішню складність самої архітектури. Зупинимося на метриках зчеплення, які залишаються затребуваними протягом багатьох років. В [3] запропоновано визна- чати зчеплення на основі кількості вимог, пов'язаних з програмним компонентом, кі- лькості функцій та середній взаємодії між функціями в межах компонентів. В [4] введено метрику відсутності зчеплення, яка вимірює схожість між операціями в межах певних сервісів та їхній взаємозв'я- зок. В [5] емпірично досліджено практичну життєздатність метрик зчеплення на рівні сервісів у контексті застосування архітек- тури мікросервісів. В [6] було представлено набір мет- рик стабільності та модульності проєкту. Зокрема, автори розробили метрику вола- тильності для оцінки стабільності рішень на основі кількості умов навколишнього середовища, що впливають на них, та ши- роти їхнього впливу. Для модульності ав- тори представили метрику «Рівень незале- жності», спрямовану на вимірювання здат- ності проєкту сприяти пошуку і заміні мо- дулів. В [7] було представлено комплекс- ну метрику «Баланс компонентів», яку ут- ворюють два показники: розбиття системи, яке оцінює ступінь декомпозиції системи на розумну кількість компонентів, та рів- номірність розмірів компонентів, яка оці- нює узгодженість розмірів компонентів у системі. У наступному дослідженні [8] ті ж автори розглянули дві метрики рівня архі- тектури: баланс компонентів та профілі за- лежностей. В [9] було введено спеціальну мет- рику для комплексної оцінки розміру сис- теми та зусиль, необхідних для управління її загальною архітектурою. Абсолютний Архітектура програмного забезпечення 102 індекс програмних елементів визначає за- гальну кількість програмних елементів, що використовуються в системі. Дослідження [10] зосереджене на взаємодіях в архітектурі. Введено дві мет- рики: коефіцієнт взаємодії компонента (ві- дношення вихідних взаємодій до вхідних) та відсоток взаємодії між компонентами (відношення суми вхідних та вихідних вза- ємодій до максимальної кількості потен- ційних взаємодій). На відміну від попередніх дослі- джень, у [11] запропоновано використову- вати фундаментальні метрики: кількість компонентів, кількість з'єднувачів (неза- лежно від їхнього спрямування) та кіль- кість елементів (сукупність компонентів та з'єднувачів). Автори назвали ці метрики зрозумілістю, пропонуючи прямий підхід до оцінки зрозумілості системи. У дослідженні [12] було зібрано та структуровано попередню компіляцію ар- хітектурних метрик відповідно до точок зору та доменів. Тим не менше, дослі- дження дійшло висновку, що оцінка зага- льної корисності архітектурних метрик за- лишається відкритим дослідницьким пи- танням. Цікавим є [13], яке зосередилося на кількісній оцінці архітектурного занепаду, спираючись на метрики когерентних взає- модій, нестабільності та якості модуляри- зації. Автори також визначили нові метри- ки для виявлення архітектурних запахів: двонаправлений зв'язок компонентів, щільність та покриття архітектурного за- паху. Ці метрики допомагають інженерам передбачати помилки системи. У [14] автори класифікували вста- новлені метрики в ієрархічну структуру і ввели нові агреговані метрики, що охоп- люють структурну якість і системні харак- теристики, зокрема гнучкість. Це дозволи- ло оцінити ефективність метрик на етапі проєктування архітектури. У [15] розглядалися метрики зв'яз- ків між вимогами та архітектурним проєк- том: Traced Requirements per Component визначає кількість вимог на компонент, а Traced Components per Requirement оцінює кількість компонентів на вимогу. Ці зале- жності можуть бути індикаторами дефек- тів ПЗ. У [16] представлено метрики рівня архітектури для оцінки якості: рівень роз'єднання (Decoupling Level), що оцінює розділеність системи на автономні модулі, і вартість розповсюдження (Propagation Cost), що оцінює щільність зв'язку всере- дині системи. Також використовувались метрики баланс компонентів і профілі за- лежностей. Ефективність цих метрик була підтверджена практиками. Дослідження [17] зосереджене на метриках безпеки в архітектурній моделі, оцінюючи вразливість точок входу в ком- позитних елементах. Це дослідження ак- центує увагу на вивченні безпеки як атри- буту якості. В [18] розглядаються метрики для архітектури мікросервісів, що встановлю- ють зв'язок між архітектурними метриками та метриками часу виконання. Це робить можливим проведення оцінок під час проєктування. Проте, нещодавня робота [19] вказує, що загальновживані метрики, такі як зв'язність, розмір, зчеплення та складність, також придатні для оцінки ар- хітектури на основі сервісів. 3. Таксономія архітектурних метрик Кластеризація метрик, що викорис- товуються в архітектурному проєктуванні, утворює таксономію метрик. Надамо опис цієї таксономії. 1. Кластер метрик структурної цілі- сності фокусується на основних структур- них аспектах архітектури, включаючи те, наскільки добре компоненти організовані та взаємодіють один з одним, а також на- скільки стабільною та збалансованою є си- стема. 1.a. Група метрик згуртованості оцінює ступінь взаємозв'язку та ефектив- ної спільної роботи елементів у межах мо- дуля або компонента. 1.a.1. Архітектурна реляційна коге- рентність оцінює ступінь, за якого компо- ненти або модулі в архітектурі ПЗ функці- Архітектура програмного забезпечення 103 онально пов'язані між собою та ефективно працюють разом. 1.a.2 Зв'язність визначає, наскільки добре елементи в межах компонента пов'я- зані один з одним та виконують єдину сфокусовану функцію. 1.a.3 Показник відсутності зв'язнос- ті ідентифікує компоненти з елементами, які погано пов'язані один з одним. 1.a.4. Коефіцієнт зв'язних взаємодій – це співвідношення взаємодій всередині компонента у порівнянні з взаємодіями з іншими компонентами. 1.b. Група метрик складності оці- нює складність конструкції та взаємодій системи, що може вплинути на ремонто- придатність та зрозумілість. 1.b.1. Двонаправлений зв'язок ком- понентів вимірює кількість залежностей між двома компонентами, де кожен з них залежить від іншого. 1.b.2 Зчеплення – це ступінь взає- мозалежності між компонентами. 1.b.3 Рівень роз'єднання визначає ступінь незалежності між компонентами. 1.c. Група метрик залежностей ана- лізує взаємозв'язки та залежності між різ- ними компонентами, які можуть впливати на надійність та модульність системи. 1.c.1. Профілі залежностей опису- ють типи та шаблони залежностей між компонентами. 1.c.2. Включення (Fan-in) визначає кількість компонентів, які залежать від пе- вного компонента. 1.c.3. Розширення (Fan-out) визна- чає кількість компонентів, від яких даний компонент не залежить. 1.c.4. Витрати на поширення оці- нюють зусилля, необхідні для того, щоб зміни в одному компоненті поширилися на інші компоненти, на які вони впливають. 1.d. Група метрик розміру та одно- рідності оцінює розподіл розмірів та одно- рідність компонентів, що може вплинути на керованість та збалансованість архітек- тури. 1.d.1. Баланс компонентів визначає, чи є розподіл функціональності між ком- понентами збалансованим або асиметрич- ним. 1.d.2. Рівномірність розміру компо- нентів визначає узгодженість у розмірі компонентів, що вимірюється кількістю методів, розміром інтерфейсів компонент тощо. 1.d.3 Кількість компонентів / з'єд- нувачів / операцій визначає загальну кіль- кість відповідних елементів у системі. 1.d.4. Кількість послуг компонента визначає кількість послуг, що надаються одним компонентом. 1.e. Група метрик стабільності оці- нює, наскільки архітектура є стійкою до змін та наскільки добре вона підтримує свою цілісність з плином часу. 1.e.1 Стабільність архітектури вимі- рює стійкість архітектури до змін та збоїв. 1.д.2. Нестабільність вимірює схи- льність архітектури до збоїв та помилок. 2. Група метрик адаптивності та еволюційності розглядає здатність системи адаптуватися до змін та еволюціонувати з часом, а також деталізацію її компонентів, що впливає на гнучкість та масштабова- ність. 2.a. Група метрик адаптивності ви- мірює легкість, з якою система може бути адаптована до нових вимог або умов. 2.a.1 Абсолютний індекс адаптив- ності системи був розроблений для кількі- сної оцінки ступеню, до якого програмна система може адаптуватися до змін у ви- могах, середовищі або технологіях. 2.a.2 Показник вартості еволюції оцінює зусилля, необхідні для модифікації архітектури в майбутньому. 2.b. Група метрик волатильності вимірює частоту та ступінь змін в системі, вказуючи на те, наскільки динамічною та схильною до змін є архітектура. 2.b.1. Волатильність проєкту вимі- рює, як часто архітектурний проєкт потрі- бно змінювати через внутрішні або зовні- шні фактори. 2.c. Група метрик деталізації оцінює рівень деталізації та декомпозиції сервісів або компонентів, що впливає на гнучкість та масштабованість. 2.c.1. Метрика гранулярності серві- сів оцінює розмір та обсяг сервісів у про- грамній архітектурі. Архітектура програмного забезпечення 104 2.c.2. Показник розбиття системи вимірює загальний стан та ремонтоприда- тність системної архітектури. 3. Кластер метрик складності та ре- монтопридатності досліджує складність системи, яка впливає на те, наскільки архі- тектура є ремонтопридатною та зрозумі- лою. Він також визначає «запахи» архітек- тури, які можуть вказувати на більш гли- бокі проблеми. 3.a. Група складності оцінює склад- ність дизайну та взаємодій системи, що може вплинути на ремонтопридатність та зрозумілість. 3.a.1 Складність сервісів вимірює складність функціональних можливостей, що надаються сервісами в архітектурі. 3.a.2. Показники складності взаємо- дії «вхід-вихід» вимірюють складність вза- ємодії між компонентом та його зовнішнім середовищем. 3.a.3. Масштаб впливу визначає ступінь, за якого зміна в одному компоне- нті впливає на інші компоненти. 3.b. Група метрик «архітектурних запахів» визначає проблеми або «запахи» в архітектурі, які можуть вказувати на гли- бші проблеми або області для покращення. 3.b.1. Покриття архітектурного «за- паху» вимірює відсоток шаблонів проєкту- вання, визначених як потенційні проблеми. 3.b.2. Щільність архітектурного «запаху» підраховує кількість потенційних проблем, виявлених на компонент проєкту. 4. Кластер метрик відстежуваності та інших атрибутів якості включає метри- ки, пов'язані з відстежуваністю вимог та компонентів, а також атрибути якості, які не вписуються в інші групи. 4.a. Група метрик простежуваності вимірює, наскільки добре вимоги та ком- поненти можуть бути простежені в систе- мі, що впливає на підзвітність та зрозумі- лість. 4.a.1. Кількість простежуваних компонентів на одну вимогу показує, скі- льки компонентів пов'язано з однією вимо- гою. 4.a.2. Кількість відстежених вимог на компонент показує, за скільки вимог ві- дповідає один компонент. 4.b. Група різних метрик включає інші метрики, які не вписуються в інші ка- тегорії, але все одно дають цінну інформа- цію про архітектуру. 4.b.1. Глибина сценарію (Depth of Scenario) визначає кількість компонентів, задіяних у конкретному користувацькому сценарії. 4.b.2. Рівень незалежності (Independence Level) вимірює, наскільки автономними є компоненти. 4.b.3. Якість модульності вимірює, наскільки добре архітектура розділена на незалежні, багаторазово використовувані модулі. 4.b.4. Захищені точки входу вимі- рюють кількість чітко визначених точок доступу для взаємодії з компонентом. Обговорення та висновки Дослідження показали, що метрики проєктування архітектури ПЗ можуть бути цінними для дизайнерів. Ці метрики допо- магають дизайнерам оцінити два важливих аспекти архітектури: її здатність генерува- ти різні варіанти проєктів та її стабільність за різних зовнішніх умов. Ми помітили, що рішення на основі метричних стратегій найчастіше викорис- товуються для ідентифікації архітектурно- го занепаду. Ці метрики можуть визначити зростання архітектурної нестабільності з еволюцією системи, визначити ймовір- ність класів, що сприяють архітектурним невідповідностям, і діагностувати анома- лії, чи є агломерації або окремі компонен- ти більш корельованими з архітектурними проблемами. Ми також бачимо, що метрики архі- тектурного проєктування можна викорис- товувати для вимірювання атрибутів якос- ті. Хоча у вступі обговорювався поте- нціал метрик архітектурного проєктування для прогнозування несправностей, жодне з існуючих досліджень не розглядає це пи- тання безпосередньо. Існуючі дослідження зосереджені на взаємозв'язку між метри- ками різних етапів розробки. Однак ці до- слідження аналізують «зворотній» ефект, коли метрики з більш пізніх етапів (напри- Архітектура програмного забезпечення 105 клад, характеристики коду) застосовують- ся для виявлення архітектурних проблем, таких як ерозія дизайну або анти-патерни. Підсумовуючи, можна сказати, що потенціал використання метрик архітекту- рного проєктування використовується не повністю. Існуючі дослідження показали, що один набір відносно простих метрик може бути успішно використаний для різ- них архітектурних рішень. Тому немає принципових перешкод для використання цих метрик для прогнозування характерис- тик артефактів наступних етапів розробки та ПЗ в цілому. Отже, подальші дослі- дження мають бути спрямовані на накопи- чення даних та дослідження моделей, які можуть бути використані для прогнозу- вання. Література 1. M. Aoyama, Metrics and analysis of software architecture evolution with discontinuity, International Workshop on Principles of Software Evolution (IWPSE '02), 2002, P. 103–107. doi: 10.1145/512035.512059. 2. J. Muskens, M. R. V. Chaudron, R. Westgeest, Software architecture analysis tool: software architecture metrics collection, 3rd PROGRESS Workshop on Embedded Systems, 2002, P. 128–139. 3. H. Venkitachalam, J. Richenhagen, A. Schlosser, T. Tasky, Metrics for Verification and Validation of Architecture in Powertrain Software Development, First International Workshop on Automotive Software Architecture (WASA '15), 2015, P. 27–33. doi: 10.1145/2752489.2752496. 4. O. Al-Debagy, P. Martinek, A Metrics Framework for Evaluating Micro- services Architecture Designs, Journal of Web Engineering, 2020. Vol. 19, no. 3–4. P. 341–370. doi: 10.13052/jwe1540-9589.19341. 5. M. G. Moreira, B. B. N. De França, Analysis of Microservice Evolution using Cohesion Metrics, 16th Brazilian Symposium on Software Components, Architectures, and Reuse (SBCARS '22), 2022, P. 40–49. doi: 10.1145/3559712.3559716. 6. K. Sethi, Y. Cai, S. Wong, A. Garcia and C. Sant'Anna, From retrospect to prospect: Assessing modularity and stability from software architecture, Joint Working IEEE/IFIP Conference on Software Architecture & European Conference on Software Architecture, 2009, P. 269-272. doi: 10.1109/WICSA.2009.5290817. 7. E. Bouwers, J. P. Correia, A. v. Deursen, J. Visser, Quantifying the Analyzability of Software Architectures, Ninth Working IEEE/IFIP Conference on Software Architecture, 2011, P. 83–92. doi: 10.1109/WICSA.2011.20. 8. E. Bouwers, A. van Deursen, J. Visser, Evaluating usefulness of software metrics: An industrial experience report, 35th International Conference on Software Engineering (ICSE), 2013, P. 921–930. doi: 10.1109/ICSE.2013.6606641. 9. D. Perez-Palacin, R. Mirandola, J. Merseguer, Software architecture adaptability metrics for QoS-based self-adaptation, Joint ACM SIGSOFT conference -- QoSA and ACM SIGSOFT symposium – ISARCS on Quality of software architectures – QoSA and architecting critical systems – ISARCS (QoSA-ISARCS '11), 2011, P. 171–176. doi: 10.1145/2000259.2000288. 10. U. Tiwari, S. Kumar, In-out interaction complexity metrics for component-based software, SIGSOFT Softw. Eng. Notes, 2014. Vol. 39(5). P. 1–4. doi: 10.1145/2659118.2659135. 11. S. Stevanetic, T. Haitzer, U. Zdun, Supporting Software Evolution by Integrating DSL-based Architectural Abstraction and Understandability Related Metrics, European Conference on Software Architecture Workshops (ECSAW '14), 2014. Article 19, P. 1– 8. doi: 10.1145/2642803.2642822. Архітектура програмного забезпечення 106 12. O. Zimmermann, Metrics for architectural synthesis and evaluation: requirements and compilation by viewpoint: an industrial experience report, Second International Workshop on Software Architecture and Metrics (SAM '15), 2015, P. 8– 14. 13. D. Le, Architectural-Based Speculative Analysis to Predict Bugs in a Software System, 38th International Conference on Software Engineering Companion (ICSE-C), 2016, P. 807–810. 14. S. Orlov, A. Vishnyakov, Decision Making for the Software Architecture Structure Based on the Criteria Importance Theory, Procedia Computer Science, 2017. Vol. 104. P. 27–34. doi: 10.1016/j.procs.2017.01.050. 15. B. Nassar, R. Scandariato, Traceability Metrics as Early Predictors of Software Defects?, IEEE International Conference on Software Architecture (ICSA), 2017, P. 235– 238. doi: 10.1109/ICSA.2017.12. 16. W. Wu et al., Software Architecture Measurement—Experiences from a Multinational Company, Lecture Notes in Computer Science, 2018. Vol. 11048. doi: 10.1007/978-3-030- 00761-4_20. 17. M. Buitrago, I. Borne, J. Buisson, Deriving metrics for software architectures from the "protected entry points" security patterns, 38th ACM/SIGAPP Symposium on Applied Computing (SAC '23), 2023, P. 1473–1475. doi: 10.1145/3555776.3577816. 18. N. Knoll, R. Lichtenthäler, An Experimental Evaluation of Relations Between Architectural and Runtime Metrics in Microservices Systems, 13th International Conference on Cloud Computing and Services Science – CLOSER, 2023, P. 147– 154. doi: 10.5220/0011728600003488. 19. M. H. Hasan, M. H. Osman, N. I. Admodisastro, M. S. Muhammad, From Monolith to Microservice: Measuring Architecture Maintainability, International Journal of Advanced Computer Science and Applications, 2023. Vol. 14(5). doi: 10.14569/IJACSA.2023.0140591. Одержано: 08.04.2024 Внутрішня рецензія отримана: 21.04.2024 Зовнішня рецензія отримана: 26.04.2024 Про автора: Любченко Віра Вікторівна, Доктор технічних наук ORCID: 0000-0002-4611-7832 Місце роботи автора: Національний університет «Одеська політехніка», пр. Шевченка, 1, Одеса, 65044, Україна. E-mail: lvv@op.edu.ua Телефон: +38-048-705-85-66

Similar Items