Abstract

Processes for evaluating software architecture (SA) help to investigate problems and potential risks in SA. It is derived from many studies that proposed a plethora of systematic SA evaluation methods, while industrial practitioners currently refrain from applying them since they are heavyweight. Nowadays, heterogeneous software architectures are organized based on the new infrastructure. Hardware and associated software allow different systems, such as embedded, sensor-based, modern AI, and cloud-based systems, to cooperate efficiently. It brings more complexities to SA evaluation. Alternatively, lightweight architectural evaluation methods have been proposed to satisfy the practitioner’s concerns, but practitioners still do not adopt these methods. This study employs a systematic literature review with a text analysis of SA’s definitions to propose a comparison framework for SA. It identifies lightweight features and factors to improve the architectural evaluation methods among industrial practitioners. The features are determined based on the practitioner’s concerns by analyzing the architecture’s definitions from stakeholders and reviewing architectural evaluation methods. The lightweight factors are acquired by studying the five most commonly used lightweight methods and the Architecture-based Tradeoff Analysis Method (ATAM), the most well-known heavyweight method. Subsequently, the research addresses these features and factors.

Highlights

  • It is essential to detect software architecture (SA) problems before software development, but it is not easy to analyze SA because of software heterogeneity and the arrangement of software components [1,2]

  • Internet of Things (IoT) devices with resource limitations are programmed with high-complex languages, such as Python, C++, and even Java, which significantly differ from the traditional monolithic SA

  • The existing literature was reviewed to remind us of the past research on using SA evaluation methods to identify the proposed framework’s main features in the first stage

Read more

Summary

Introduction

It is essential to detect software architecture (SA) problems before software development, but it is not easy to analyze SA because of software heterogeneity and the arrangement of software components [1,2]. The problematic SA leads to project failure; different big, upfront designs are sketched based on the experiences of software analysts to explore the SA problems in the early phase [3]. Modern SA works based on various Flask web servers and local Raspberry servers, connected via cloud technology to a central platform. They receive user requests and control the protocol through a REST API to command microcontrollers and detect sensor faults. It is very difficult to analyze the intercommunication of all those elements [4,5]

Methods
Results
Discussion
Conclusion
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call