Architectural Drift Research Articles

DOMICO: Checking conformance between domain models and implementations

AbstractAs a predominant design method for microsservices architecture (MSA), domain‐driven design (DDD) utilizes a series of standard patterns in both models and implementations to effectively support the design of architectural elements. However, an implementation may deviate from its original domain model that uses certain patterns. The deviation between a domain model and its implementation is a type of architectural drift, which needs to be detected promptly. This paper proposes an approach, namely DOMICO, to check the conformance between the domain model and its implementation, by which the conformance is formalized by defining eight common structural patterns of domain modeling and their representations in both models and the corresponding source code. Based on the formalization, our approach can not only identify the discrepancies (e.g., divergence, absence, and modification) with respect to pattern elements, but also detect possible violations of 24 compliance rules imposed by the patterns. To validate DOMICO, we performed a case study to investigate its use in a supply chain project and its performance. The results show that DOMICO can accurately identify 100% inconsistency issues in the cases examined. As the first conformance checking approach for DDD, DOMICO can be integrated into the regular domain modeling process and help ensure the conformity of microservice implementations to models.

Detecting deviations in the code using architecture view-based drift analysis

ContextOne of the key requirements for the code is conformance with the architecture. Architectural drift implies the diverging of the implemented code from the architecture design of the system. Manually checking the consistency between the implemented code and architecture can be intractable and cumbersome for large-scale systems. ObjectiveThis article proposes a holistic, automated architecture drift analysis approach that explicitly focuses on the adoption of architecture views. The approach builds on, complements, and enhances existing architecture conformance analysis methods that do not adopt a holistic approach or fail to address the architecture viewpoints. MethodA model-driven development approach is adopted in which architecture views are represented as specifications of domain-specific languages. The code in its turn, is analyzed, and the architectural view specifications are reconstructed, which are then automatically checked with the corresponding architecture models. ResultsTo illustrate the approach, we have applied a systematic case study research for an architecture drift analysis of the business-to-customer (B2C) system within a large-scale software company. ConclusionThe case study research showed that divergences and absences of architectural elements could be detected in a cost-effective manner with the proposed approach.

On the Understandability of Temporal Properties Formalized in Linear Temporal Logic, Property Specification Patterns and Event Processing Language

Temporal properties are important in a wide variety of domains for different purposes. For example, they can be used to avoid architectural drift in software engineering or to support the regulatory compliance of business processes. In this work, we study the understandability of three major temporal property representations: (1) Linear Temporal Logic (LTL) is a formal and well-established logic that offers temporal operators to describe temporal properties; (2) Property Specification Patterns (PSP) are a collection of recurring temporal properties that abstract underlying formal and technical representations; (3) Event Processing Language (EPL) can be used for runtime monitoring of event streams using Complex Event Processing. We conducted two controlled experiments with 216 participants in total to study the understandability of those approaches using a completely randomized design with one alternative per experimental unit. We hypothesized that PSP, as a highly abstracting pattern language, is easier to understand than LTL and EPL, and that EPL, due to separation of concerns (as one or more queries can be used to explicitly define the truth value change that an observed event pattern causes), is easier to understand than LTL. We found evidence supporting our hypotheses which was statistically significant and reproducible.

Architecture conformance analysis using model‐based testing: A case study approach

SummaryContext: The architectural drift problem defines the discrepancy between the architecture description and the code. Deviations of the code from the architecture can occur if architectural constraints as defined in the architectural models are not implemented in the code. For large‐scale systems, manually checking the consistency of the architecture with the code is not trivial and cumbersome.Objective: The overall objective of this paper is to propose and analyze the effectiveness and practicality of an architecture conformance analysis approach using model‐based testing (ACAMBT) approach for checking the consistency between architectural models and the code. Hereby, we consider the case whereby the architecture is assumed correct, and the code needs to align with the architecture.Method: We propose a model‐based testing that uses architectural views to automatically derive test cases for checking the architectural constraints in the code. We have evaluated the approach and the corresponding toolset for a real industrial case study using a systematic case study protocol. Further, we have adopted exhaustive fault‐injection techniques to detect the constraint violations.Results: The evaluation of the approach on real code showed that deviations with the architectural constraints could be easily detected in the code.Conclusion: We can conclude that ACAMBT is effective for identifying inconsistencies between the architecture views and the code for the defined view constraints. Our survey study with practitioners showed that adopting the ACAMBT approach is practical and easy to use. The approach as such can be considered as a complimentary tool to the existing testing and reflexion modeling approaches.

Reconciling software architecture and source code in support of software evolution

Abstract Even in the eighties, the need of managing software evolution has been detected as one of the most complex aspects of the software lifecycle. In this context, software architecture has been highlighted as an integral element of the software evolution process. However, no matter how much effort is put into the architecture, it must eventually be translated into source code. The potential misalignment between architecture and code can lead to failures in the evolution process in terms of economic impacts, failed expectations, and so on. In this article we report on a design science research study that we pursued to answer three research questions. First, we have studied whether and in how far it is possible to design an approach that both enforces the integration between software architecture and source code to avoid architectural erosion and architectural drift and, at the same time, provides automatic guidance to developers to carry out the required change tasks in each evolution steps. Second, we have studied whether this approach may be applied in realistic (open source) cases. Finally, we have analysed whether it is realizable at acceptable costs (in terms of development effort) in comparison to the overall development efforts roughly spent on the evolution of the projects in focus.

Genetic variability and bottleneck analyses of kanni adu goat population using Microsatellite Markers

Microsatellite data on 25 loci were generated and utilized to evaluate the genetic architecture and mutation drift equilibrium of Kanni Adu goats of southern Tamil Nadu. The genetic diversity analysis of Kanni Adu goats displayed higher level of within breed variability in terms of mean number of alleles per locus (11.24±0.87) and heterozygosity values (Ho = 0.677±0.041, He = 0.857±0.016). Within population inbreeding estimate (Fis =0.215±0.040) showed moderate level of inbreeding, which warrant adoption of appropriate breeding strategies under field conditions. The polymorphism information content (PIC) value ranged from 0.531 to 0.915 suggested higher polymorphism in this breed. In general, the sign, standardized difference and Wilcoxon rank tests indicated heterozygosity excess in Kanni Adu goat population in infinite alleles and two-phase model and non-significant in stepwise mutation model. Hence, the mode-shift indicator test was utilized and it indicated the absence of genetic bottleneck in the recent past in Kanni Adu goats. It suggests that any unique alleles present in this breed may not have been lost. The study indicated that Kanni Adu goats exhibited substantial amount of genetic variation as reflected from the heterozygosity and number of alleles per locus.

Long-Term Product Line Sustainability with Planned Staged Investments

Software product lines (SPL) are long-living systems that enable systematic reuse in application engineering. Product-specific changes over time can result in architecture drift, which requires updating assumptions made in the SPL's reuse infrastructure. A model called planned staged investments supports SPL rearchitecting in a sustainable way. The key idea is to use two different operational phases--investment and harvesting--to coordinate the competing, parallel needs of redesign and reuse.

Unusable Software Is Useless, Part 2

In this installment, I turn my attention to the internals of software-centric systems, since usability is also of prime importance for the architectures we create. Ultimately, unusable architectures can lead to architecture drift, complex code, and other consequences that are costly to fix.

Unusable Software Is Useless, Part 1

Usability has a significant impact on the success of software-centric systems and products. For example, if a software system doesn't support end users in their daily work, it won't be used productively. Likewise, if developers don't understand their software's architecture, architecture drift and complex code are obvious consequences. Ultimately, failing to design usable software could seriously degrade a project's ability to deliver on time, budget, functionality, and quality. In the next two installments of this column, I explore selected yet essential activities, methods, and techniques that support pragmatic architects in the development of systems for use. This particular installment focuses on operational usability; I focus on two aspects that significantly contribute to designing systems that are accepted by customers and end users: business suitability and ergonomics.

Assessing architectural drift in commercial software development: a case study

AbstractObjectives: Software architecture is perceived as one of the most important artefacts created during a system's design. However, implementations often diverge from their intended architectures: a phenomenon called architectural drift. The objective of this research is to assess the occurrence of architectural drift in the context of de novo software development, to characterize it, and to evaluate whether its detection leads to inconsistency removal. Method: An in vivo, longitudinal case study was performed during the development of a commercial software system, where an approach based on Reflexion Modelling was employed to detect architectural drift. Observation and think‐aloud data, captured during the system's development, were assessed for the presence and types of architectural drift. When divergences were identified, the data were further analysed to see if identification led to the removal of these divergences. Results: The analysed system diverged from the intended architecture, during the initial implementation of the system. Surprisingly however, this work showed that Reflexion Modelling served to conceal some of the inconsistencies, a finding that directly contradicts the high regard that this technique enjoys as an architectural evaluation tool. Finally, the analysis illustrated that detection of inconsistencies was insufficient to prompt their removal, in the small, informal team context studied. Conclusions: Although the utility of the approach for detecting inconsistencies was demonstrated in most cases, it also served to hide several inconsistencies and did not act as a trigger for their removal. Hence additional efforts must be taken to lessen architectural drift and several improvements in this regard are suggested. Copyright © 2010 John Wiley & Sons, Ltd.

Approche centrée architecture pour l'évolution dynamique de systèmes d'information

Work on architecture-cenired software development has been undertaken during the past years, leading to architecture description languages with high expressive power. We focus on the impact those new approaches may have on the software evolution management, namely supporting the evolution issues at earlier development phases than the usual coding/maintenance time. Several evolution possibilities may be envisaged, depending on whether the evolution is or is not foreseen during the design phase, and on whether the evolution takes place during the software execution or not. Existing works address some of these possibilities, but mainly concern the software evolution at the implementation level. Handling the inconsistency between architecture and code becomes an issue, known as the architectural drift. In this paper we present how, by using specific language mechanisms and a dedicated virtual machine, the ArchWare languages and environment allow us to cover the identified evolution possibilities, on the svstem architecture.

Stochastic model of crack paths in composites based on the Langevin equation

A stochastic model based on the Langevin equation was used to describe crack paths in composites. A single crack path in a fiberglass reinforced epoxy matrix composite was used to predict Langevin parameters quantifying architectural drift and material variability. The predicted Langevin parameters were consistent with moderate architectural drift (Langevin drift parameter of 0.04 ± 0.02) and moderate material variability (Langevin variability parameter of 0.05 ± 0.03). These Langevin parameters were then used to predict a family of crack paths exhibiting the same stochastic characteristics as the original crack path. Architectural drift was qualitatively related to the orientation of the reinforcing phase. A strong correlation between the predicted and experimental crack path suggests the utility of the Langevin model to quantify crack paths.