Architectural Violations Research Articles

Understanding software architecture erosion: A systematic mapping study

AbstractArchitecture erosion (AEr) can adversely affect software development and has received significant attention in the last decade. However, there is an absence of a comprehensive understanding of the state of research about the reasons and consequences of AEr, and the countermeasures to address AEr. This work aims at systematically investigating, identifying, and analyzing the reasons, consequences, and ways of detecting and handling AEr. With 73 studies included, the main results are as follows: (1) AEr manifests not only through architectural violations and structural issues but also causing problems in software quality and during software evolution; (2) non‐technical reasons that cause AEr should receive the same attention as technical reasons, and practitioners should raise awareness of the grave consequences of AEr, thereby taking actions to tackle AEr‐related issues; (3) a spectrum of approaches, tools, and measures has been proposed and employed to detect and tackle AEr; and (4) three categories of difficulties and five categories of lessons learned on tackling AEr were identified. The results can provide researchers a comprehensive understanding of AEr and help practitioners handle AEr and improve the sustainability of their architecture. More empirical studies are required to investigate the practices of detecting and addressing AEr in industrial settings.

Architecture violations detection and visualization in the continuous integration pipeline

AbstractNew 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.

Detecting Architectural Violations Using Responsibility and Dependency Constraints of Components

Detecting Architectural Violations Using Responsibility and Dependency Constraints of Components

The WGB method to recover implemented architectural rules

Context: The identification of architectural rules, which specify allowed dependencies among architectural modules, is a key challenge in software architecture recovery. Existing approaches either retrieve a large set of rules, compromising their practical use, or are limited to supporting the understanding of such rules, which are manually recovered.Objective: To propose and evaluate a method to recover architectural rules, focusing on those implemented in the source code, which may differ from planned or conceptual rules.Method: We propose the WGB method, which analyzes dependencies among architectural modules as a graph, adding weights that correspond to the proposed module dependency strength (MDS) metric and identifies the set of implemented architectural rules by solving a mathematical optimization problem. We evaluated our method with a case study and an empirical study that compared rules extracted by the method with the conceptual architecture and source code dependencies of six systems. These comparisons considered efficiency and effectiveness of our method.Results: Regarding efficiency, our method took 45.55 s to analyze the largest system evaluated. Considering effectiveness, our method captured package dependencies as extracted rules with a reduction of 87.6%, on average, to represent this information. Using allowed architectural dependencies as a reference point (but not a gold standard), provided rules achieved 37.1% of precision and 37.8% of recall.Conclusion: Our empirical evaluation shows that the implemented architectural rules recovered by our method consist of abstract representations of (a large number of) module dependencies, providing a concise view of dependencies that can be inspected by developers to identify occurrences of architectural violations and undocumented rules.

DCL 2.0: modular and reusable specification of architectural constraints

BackgroundDue to the abstract nature of software architecture concepts, ensuring the correct implementation of architectural decisions is not a trivial task. Divergences between the planned architecture and source code may occur in the early stages of the software development, which denotes a phenomenon known as software architecture erosion. Architectural conformance checking techniques have been proposed to tackle the problem of divergences between the planned architecture and source code. Among such techniques, we can note the DCL (dependency constraint language), which is a domain-specific language that has interesting results in architectural conformance contexts. However, the current version of DCL has some limitations, such as lack of modularity and low degree of reuse, which may prevent its adoption in real software development scenarios. In this article, we extend DCL with a reusable, modular, and hierarchical specification.MethodWe propose and evaluate DCL 2.0—an extension of the original DCL—and its tool in a real-world development scenario of a large system used by a government branch of Minas Gerais, Brazil.ResultWe were able to detect 771 architectural violations where 74% of them could only be detected due to the new violation types proposed in DCL 2.0.ConclusionBy using DCL 2.0 herein presented, it was possible to conclude the following: (i) DCL 2.0 proved importance in helping the development team consistently address violations, and (ii) after using DCL 2.0 for months, the number of architectural violations being committed into the system branches was reduced to zero. Therefore, we argue that DCL 2.0 can have a positive impact on the architectural conformance of systems.

Architecture Conformance Checking in Dynamically Typed Languages.

Architectural erosion is a recurrent problem faced by software architects, which might be even more severe in systems implemented in dynamically typed languages. The reasons are twofold: (i) some features provided by such languages make developers more propitious to break the planned architecture (e.g., dynamic invocations and buildings), and (ii) the developers’ community lacks tool support for monitoring the implemented architecture. To address these shortcomings, this paper presents an architectural conformance and visualization approach based on static code analysis techniques and on a lightweight type propagation heuristic. The central idea is to provide the developers’ community with means to control the architectural erosion process by reporting architectural violations and visualizing them in high-level architectural models, such as reflexion models and DSMs. This paper also describes a tool—called ArchRuby—that implements our approach. We evaluate our solution in three real-world systems identifying 48 architectural violations of which the developers had no prior knowledge. We also measure the effectiveness of our type propagation heuristic reporting that (i) the number of analyzed types raises 5% on the average and (ii) certain violations are only detected due to our heuristic.

Five Years of Software Architecture Checking: A Case Study of Eclipse

Over time, source code tends to drift from the intended software architecture, often resulting in the loss of desired software qualities. To help keep code aligned with the intended architecture, the developers of core parts of the open source Eclipse platform introduced API Tools to express and check architectural rules. Researchers analyzed five years of Eclipse architecture-checking reports that API Tools produced. They investigated what kinds of rules the developers found helpful to check, how code diverged from the intended architecture, and how the developers dealt with architectural violations over time. This article is part of a special issue on Software Architecture.

Real-Time Reflexion Modelling in architecture reconciliation: A multi case study

ContextReflexion Modelling is considered one of the more successful approaches to architecture reconciliation. Empirical studies strongly suggest that professional developers involved in real-life industrial projects find the information provided by variants of this approach useful and insightful, but the degree to which it resolves architecture conformance issues is still unclear. ObjectiveThis paper aims to assess the level of architecture conformance achieved by professional architects using Reflexion Modelling, and to determine how the approach could be extended to improve its suitability for this task. MethodAn in vivo, multi-case-study protocol was adopted across five software systems, from four different financial services organizations. Think-aloud, video-tape and interview data from professional architects involved in Reflexion Modelling sessions were analysed qualitatively. ResultsThis study showed that (at least) four months after the Reflexion Modelling sessions less than 50% of the architectural violations identified were removed. The majority of participants who did remove violations favoured changes to the architectural model rather than to the code. Participants seemed to work off two specific architectural templates, and interactively explored their architectural model to focus in on the causes of violations, and to assess the ramifications of potential code changes. They expressed a desire for dependency analysis beyond static-source-code analysis and scalable visualizations. ConclusionThe findings support several interesting usage-in-practice traits, previously hinted at in the literature. These include (1) the iterative analysis of systems through Reflexion models, as a precursor to possible code change or as a focusing mechanism to identify the location of architecture conformance issues, (2) the extension of the approach with respect to dependency analysis of software systems and architectural modelling templates, (3) improved visualization support and (4) the insight that identification of architectural violations in itself does not lead to their removal in the majority of instances.

Mining architectural violations from version history

Software architecture conformance is a key software quality control activity that aims to reveal the progressive gap normally observed between concrete and planned software architectures. However, formally specifying an architecture can be difficult, as it must be done by an expert of the system having a high level understanding of it. In this paper, we present a lightweighted approach for architecture conformance based on a combination of static and historical source code analysis. The proposed approach relies on four heuristics for detecting absences (something expected was not found) and divergences (something prohibited was found) in source code based architectures. We also present an architecture conformance process based on the proposed approach. We followed this process to evaluate the architecture of two industrial-strength information systems, achieving an overall precision of 62.7 % and 53.8 %. We also evaluated our approach in an open-source information retrieval library, achieving an overall precision of 59.2 %. We envision that an heuristic-based approach for architecture conformance can be used to rapidly raise architectural warnings, without deeply involving experts in the process.

Experimenting with software testbeds for evaluating new technologies

The evolution of a new technology depends upon a good theoretical basis for developing the technology, as well as upon its experimental validation. In order to provide for this experimentation, we have investigated the creation of a software testbed and the feasibility of using the same testbed for experimenting with a broad set of technologies. The testbed is a set of programs, data, and supporting documentation that allows researchers to test their new technology on a standard software platform. An important component of this testbed is the Unified Model of Dependability (UMD), which was used to elicit dependability requirements for the testbed software. With a collection of seeded faults and known issues of the target system, we are able to determine if a new technology is adept at uncovering defects or providing other aids proposed by its developers. In this paper, we present the Tactical Separation Assisted Flight Environment (TSAFE) testbed environment for which we modeled and evaluated dependability requirements and defined faults to be seeded for experimentation. We describe two completed experiments that we conducted on the testbed. The first experiment studies a technology that identifies architectural violations and evaluates its ability to detect the violations. The second experiment studies model checking as part of design for verification. We conclude by describing ongoing experimental work studying testing, using the same testbed. Our conclusion is that even though these three experiments are very different in terms of the studied technology, using and re-using the same testbed is beneficial and cost effective.