Architecture violations detection and visualization in the continuous integration pipeline

Abstract

New code in projects can introduce violations that deviate the code implementation from the intended architecture. This process is known as architecture erosion. In this article, we propose an approach for recovering the implemented architecture, and detecting violations when comparing it with the intended architecture. Given a code repository, the continuous integration pipeline calls the solution to detect the incidences of architecture violations as well as some quality and social metrics. This data is presented in metric‐centered views that help development teams to manage architecture erosion. Our approach is based on model‐driven engineering techniques since models serve to represent the code, and a model‐based pattern language helps us to automate the search for violation occurrences and execute corresponding actions (e.g., creation/assignment of issues). We confirm the approach benefits in a real project implemented by a software developing company, in a sample project available on the internet, and in a software development course, including 20 projects, where every single project decreases its architecture violations density through time.

DOMICO: Checking conformance between domain models and implementations

“…For example, Stefanie Jasser 14 proposed to dynamically check the implementation's conformance with six predefined architectural security rules which are formalized with a controlled natural language. By using a model‐based pattern language, an approach 30 that enables architects to verify the presence of predefined architectural rules was proposed for identifying architecture violations at design and implementation level in continuous integration pipelines. The model‐based testing technique was also utilized to automatically derive test cases for checking the architectural constraints in codes 31 .…”

Warnings: Violation symptoms indicating architecture erosion

“…Rationale: Violation symptoms in code review comments are described in natural language, but there is a lack of evidence regarding how developers describe these violation symptoms. Specifically, we are interested in the terms and linguistic patterns 4 that developers use to denote violation symptoms. Establishing a list of the terms and linguistic patterns used by practitioners can subsequently provide a basis for the automatic identification of violation symptoms through natural language processing techniques.…”

“…The resulting gap between the intended and implemented architectures is defined as architecture erosion [1,2], and has been described using different terms in the literature and practice, such as architectural decay, degradation, and deterioration [1,3]. Architecture erosion can negatively affect quality attributes of software systems, such as maintainability, performance, and modularity [3,4].…”

“…For the sake of brevity, we refer to violation symptoms of architecture erosion as violation symptoms in the rest of this paper. https://doi.org/10.1016/j.infsof.2023.107319 Received 20 September 2022; Received in revised form 19 July 2023; Accepted 3 August 2023 While a handful of temporary violation symptoms might be innocuous regarding the software system, the accumulation of architecture violations can lead to architecture erosion [2,4,5], severely impacting run-time and design-time qualities. Therefore, identifying and monitoring violation symptoms is crucial to reveal inconsistencies between the implementation and the intended architecture; eventually this can help to, at least partially, repair architecture erosion [1,5].…”

Impacts, causes, and solutions of architectural smells in microservices: An industrial investigation

“…[4][5][6] Yet this has received scant attention from scientific research. Distinct from traditional architectural issues (e.g., architectural erosions, 33,34 architectural debts 3 ), Architectural Smell (AS), is a metaphor describing poor architectural decisions that are claimed to negatively impact system maintainability. 9,35 As an indicator of potential architectural problems, 11 this metaphor has been used to pinpoint refactoring opportunities for evolving software architecture, 8,12 including microservice boundaries.…”