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.     

A recommendation system for repairing violations detected by static architecture conformance checking

This paper describes a recommendation system that provides refactoring guidelines for maintainers when tackling architectural erosion. The paper formalizes 32 refactoring recommendations to repair violations raised by static architecture conformance checking approaches; it describes a tool—called ArchFix—that triggers the proposed recommendations; and it evaluates the application of this tool in two industrial‐strength systems. For the first system—a 21 KLOC open‐source strategic management system—our approach has indicated correct refactoring recommendations for 31 out of 41 violations detected as the result of an architecture conformance process. For the second system—a 728 KLOC customer care system used by a major telecommunication company—our approach has triggered correct recommendations for 624 out of 787 violations, as asserted by the system's architect. Moreover, the architects have scored 82% of these recommendations as having moderate or major complexity. Copyright © 2013 John Wiley & Sons, Ltd.     

The accuracy of dependency analysis in static architecture compliance checking

Architecture compliance checking (ACC) is an approach to verify conformance of implemented program code to high‐level models of architectural design. Static ACC focuses on the modular software architecture and on the existence of rule violating dependencies between modules. Accurate tool support is essential for effective and efficient ACC. This paper presents a study on the accuracy of ACC tools regarding dependency analysis and violation reporting. Ten tools were tested and compared by means of a custom‐made benchmark. The Java code of the benchmark testware contains 34 different types of dependencies, which are based on an inventory of dependency types in object oriented program code. In a second test, the code of open source system FreeMind was used to compare the 10 tools on the number of reported rule violating dependencies and the exactness of the dependency and violation messages. On the average, 77% of the dependencies in our custom‐made test software were reported, while 72% of the dependencies within a module of FreeMind were reported. The results show that all tools in the test could improve the accuracy of the reported dependencies and violations, though large differences between the 10 tools were observed. We have identified 10 hard‐to‐detect types of dependencies and four challenges in dependency detection. The relevance of our findings is substantiated by means of a frequency analysis of the hard‐to‐detect types of dependencies in five open source systems. © 2016 The Authors. Software: Practice and Experience Published by John Wiley & Sons, Ltd.     

Preserving architectural decisions through architectural patterns

Architectural decisions have emerged as a means to maintain the quality of the architecture during its evolution. One of the most important decisions made by architects are those about the design approach such as the use of patterns or styles in the architecture. The structural nature of this type of decisions give them the potential to be controlled systematically. In the literature, there are some works on the automation of architectural decision violation checking. In this paper we show that these works do not allow to detect all possible architectural decision violations. To solve this problem we propose an approach which: (i) describes architectural patterns that hold the architectural decision definition, (ii) integrates architectural decisions into an architectural model and, (iii) automates the architectural decision conformance checking. The approach is implemented using Eclipse modeling framework and its accompanying technologies. Starting from well-known architectural patterns, we show that we can formalize all those related to the structural aspect. Through two evaluations, we show that our approach can be adapted to different architecture paradigms and allows to detect more violations comparing to the existing approaches.     

Assessing architectural drift in commercial software development: a case study

Objectives: 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.     

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.     

An empirical investigation of architectural prototyping

Architectural prototyping is the process of using executable code to investigate stakeholders’ software architecture concerns with respect to a system under development. Previous work has established this as a useful and cost-effective way of exploration and learning of the design space of a system and in addressing issues regarding quality attributes, architectural risks, and the problem of knowledge transfer and conformance. However, the actual industrial use of architectural prototyping has not been thoroughly researched so far. In this article, we report from three studies of architectural prototyping in practice. First, we report findings from an ethnographic study of practicing software architects. Secondly, we report from a focus group on architectural prototyping involving architects from four companies. And, thirdly, we report from a survey study of 20 practicing software architects and software developers. Our findings indicate that architectural prototyping plays an important and frequent role in resolving problems experimentally, but less so in exploring alternative solutions. Furthermore, architectural prototypes include end-user or business related functionality rather than purely architectural functionality. Based on these observations we provide recommendations for effective industrial architectural prototyping.     

Controlling software architecture erosion: A survey

Software architectures capture the most significant properties and design constraints of software systems. Thus, modifications to a system that violate its architectural principles can degrade system performance and shorten its useful lifetime. As the potential frequency and scale of software adaptations increase to meet rapidly changing requirements and business conditions, controlling such architecture erosion becomes an important concern for software architects and developers. This paper presents a survey of techniques and technologies that have been proposed over the years either to prevent architecture erosion or to detect and restore architectures that have been eroded. These approaches, which include tools, techniques and processes, are primarily classified into three generic categories that attempt to minimise, prevent and repair architecture erosion. Within these broad categories, each approach is further broken down reflecting the high-level strategies adopted to tackle erosion. These are: process-oriented architecture conformance, architecture evolution management, architecture design enforcement, architecture to implementation linkage, self-adaptation and architecture restoration techniques consisting of recovery, discovery and reconciliation. Some of these strategies contain sub-categories under which survey results are presented.We discuss the merits and weaknesses of each strategy and argue that no single strategy can address the problem of erosion. Further, we explore the possibility of combining strategies and present a case for further work in developing a holistic framework for controlling architecture erosion.     

Semi-automated architectural abstraction specifications for supporting software evolution

In this paper we present an approach for supporting the semi-automated architectural abstraction of architectural models throughout the software life-cycle. It addresses the problem that the design and implementation of a software system often drift apart as software systems evolve, leading to architectural knowledge evaporation. Our approach provides concepts and tool support for the semi-automatic abstraction of architecture component and connector views from implemented systems and keeping the abstracted architecture models up-to-date during software evolution. In particular, we propose architecture abstraction concepts that are supported through a domain-specific language (DSL). Our main focus is on providing architectural abstraction specifications in the DSL that only need to be changed, if the architecture changes, but can tolerate non-architectural changes in the underlying source code. Once the software architect has defined an architectural abstraction in the DSL, we can automatically generate architectural component views from the source code using model-driven development (MDD) techniques and check whether architectural design constraints are fulfilled by these models. Our approach supports the automatic generation of traceability links between source code elements and architectural abstractions using MDD techniques to enable software architects to easily link between components and the source code elements that realize them. It enables software architects to compare different versions of the generated architectural component view with each other. We evaluate our research results by studying the evolution of architectural abstractions in different consecutive versions of five open source systems and by analyzing the performance of our approach in these cases.     

Two controlled experiments on model-based architectural decision making

ContextIn recent years, architectural design decisions are becoming more and more common for documenting software architectures. Rather than describing the structure of software systems, architectural decisions capture the design rationale and – often reusable – architectural knowledge. Many approaches and tools have been proposed in the literature to support architectural decision making and documentation (for instance, based on models, ontologies, or templates). In this context, the capturing, organization, and effective reuse of architectural knowledge has gained a lot of attention.ObjectiveHowever, there is little empirical evidence about the supportive effect of reusable architectural knowledge on the effectiveness and efficiency of architectural decision making.MethodTo investigate these aspects, we conducted two separate controlled experiments with software architecture students in which we tested the supportive effect of reusable decision models in decision making and documentation.ResultsOur results show that the use of reusable decision models can significantly increase both the efficiency and the effectiveness of novice architects.ConclusionWe can report, that our findings are in line with similar studies and support the claims regarding reusable architectural design decisions in principle.     

Besouro: A framework for exploring compliance rules in automatic TDD behavior assessment

ContextThe improvements promoted by Test-Driven Design (TDD) have not been confirmed by quantitative assessment studies. To a great extent, the problem lies in the lack of a rigorous definition for TDD. An emerging approach has been to measure the conformance of TDD practices with the support of automated systems that embed an operational definition, which represent the specific TDD process assumed and the validation tests used to determine its presence and quantity. The empirical construction of TDD understanding and consensus building requires the ability of comparing different definitions, evaluating them with regard to practitioners’ perception, and exploring code information for improvement of automatic assessment.ObjectiveThis paper describes Besouro, a framework targeted at the development of systems for automatic TDD behavior assessment. The main rationale of Besouro’s design is the ability to compare distinct operational definitions, evaluate them with regard to users’ perception, and explore code information for further analysis and conformance assessment improvement.MethodWe developed an architecture with clear separation of concerns, which enables to vary: (a) the atomic events and respective metrics to be collected from developing and testing environments; (b) the organization of atomic events in streams of actions or processes; and (c) the classification and assessment components for each set of operational definitions adopted. The architecture also includes a mechanism for on-line user assessment awareness and feedback, and integrates event-related information with the respective code in a code version system.ResultsWe illustrate the usefulness of Besouro’s features for understanding the actions and processes underlying TDD through a prototype developed to support an experiment based on user feedback. We show how it was possible to compare variations of a same operational definition by exploring users’ feedback, and use source code to improve the automatic classification of TDD practices.ConclusionUnderstanding the actions and processes underlying successful TDD application is key for leveraging TDD benefits. In the absence of a rigorous definition for TDD, the proposed approach aims at building consensus from experimentation and empirical validation.     

Problems and their mitigation in system and software architecting

ContextToday, software and embedded systems act as enablers for developing new functionality in traditional industries such as the automotive, process automation, and manufacturing automation domains. This differs from 25–30 years ago when these systems where based on electronics and electro-mechanical solutions. The architecture of the embedded system and of the software is important to ensure the qualities of these applications. However, the effort of designing and evolving the architecture is in practice often neglected during system development, whilst development efforts are centered on implementing new functionality.ObjectiveWe present problems and success factors that are central to the architectural development of software intensive systems in the domain of automotive and automation products as judged by practitioners.MethodThe method consisted of three steps. First, we used semi-structured interviews to collect data in an exploratory manner. As a second step, a survey based on problems extracted from the interview data was used to investigate the occurrence of these problems at a wider range of organizations. In order to identify and suggest how to mitigate the problems that were considered important, we finally performed root cause analysis workshops, and from these a number of success factors were elicited.ResultsA total of 21 problems have been identified based on the interview data, and these are related to the technical, organizational, project, and agreement processes. Based on the survey results, the following four problems were selected for a root cause analysis: (1) there is a lack of process for architecture development, (2) there is a lack of method or model to evaluate the business value when choosing the architecture, (3) there is a lack of clear long-term architectural strategy, and (4) processes and methods are less valued than knowledge and competence of individuals.ConclusionIn conclusion, the following identified success factors are crucial components to be successful in developing software intensive systems: (1) define an architectural strategy, (2) implement a process for architectural work, (3) ensure authority for architects, (4) clarify the business impact of the architecture, and (5) optimize on the project portfolio level instead of optimizing each project.     

A method for module architecture verification and its application on a large component-based system

A method for module architecture verification is described, which yields support for checking on an architectural level whether the implicit module architecture of the implementation of a system is consistent with its specified module architecture, and which facilitates achieving architecture conformance by relating architectural-level violations to the code-level entities that cause them, hence making it easier to resolve them. Module architecture conformance is needed to enable implementing and maintaining the system and reasoning about it. We describe our experience having applied the proposed method to check a representative part of the module architecture of a large industrial component-based software system.     

Knowledge based quality-driven architecture design and evaluation

Modelling and evaluating quality properties of software is of high importance, especially when our every day life depends on the quality of services produced by systems and devices embedded into our surroundings. This paper contributes to the body of research in quality and model driven software engineering. It does so by introducing; (1) a quality aware software architecting approach and (2) a supporting tool chain. The novel approach with supporting tools enables the systematic development of high quality software by merging benefits of knowledge modelling and management, and model driven architecture design enhanced with domain-specific quality attributes. The whole design flow of software engineering is semi-automatic; specifying quality requirements, transforming quality requirements to architecture design, representing quality properties in architectural models, predicting quality fulfilment from architectural models, and finally, measuring quality aspects from implemented source code. The semi-automatic design flow is exemplified by the ongoing development of a secure middleware for peer-to-peer embedded systems.     

Style-based modeling and refinement of service-oriented architectures

Service-oriented architectures (SOA) provide a flexible and dynamic platform for implementing business solutions. In this paper, we address the modeling of such architectures by refining business-oriented architectures, which abstract from technology aspects, into service-oriented ones, focusing on the ability of dynamic reconfiguration (binding to new services at run-time) typical for SOA.The refinement is based on conceptual models of the platforms involved as architectural styles, formalized by graph transformation systems. Based on a refinement relation between abstract and platform-specific styles we investigate how to realize business-specific scenarios on the SOA platform by automatically deriving refined, SOA-specific reconfiguration scenarios.Research partially supported by the European Research Training Network SegraVis (on Syntactic and Semantic Integration of Visual Modelling Techniques)     

Managing architectural decision models with dependency relations, integrity constraints, and production rules

Software architects consider capturing and sharing architectural decisions increasingly important; many tacit dependencies exist in this architectural knowledge. Architectural decision modeling makes these dependencies explicit and serves as a foundation for knowledge management tools. In practice, however, text templates and informal rich pictures rather than models are used to capture the knowledge; a formal definition of model entities and their relations is missing in the current state of the art. In this paper, we propose such a formal definition of architectural decision models as directed acyclic graphs with several types of nodes and edges. In our models, architectural decision topic groups, issues, alternatives, and outcomes form trees of nodes connected by edges expressing containment and refinement, decomposition, and triggers dependencies, as well as logical relations such as (in)compatibility of alternatives. The formalization can be used to verify integrity constraints and to organize the decision making process; production rules and dependency patterns can be defined. A reusable architectural decision model supporting service-oriented architecture design demonstrates how we use these concepts. We also present tool support and give a quantitative evaluation.     

A language-independent approach to the extraction of dependencies between source code entities

ContextSoftware networks are directed graphs of static dependencies between source code entities (functions, classes, modules, etc.). These structures can be used to investigate the complexity and evolution of large-scale software systems and to compute metrics associated with software design. The extraction of software networks is also the first step in reverse engineering activities.ObjectiveThe aim of this paper is to present SNEIPL, a novel approach to the extraction of software networks that is based on a language-independent, enriched concrete syntax tree representation of the source code.MethodThe applicability of the approach is demonstrated by the extraction of software networks representing real-world, medium to large software systems written in different languages which belong to different programming paradigms. To investigate the completeness and correctness of the approach, class collaboration networks (CCNs) extracted from real-world Java software systems are compared to CCNs obtained by other tools. Namely, we used Dependency Finder which extracts entity-level dependencies from Java bytecode, and Doxygen which realizes language-independent fuzzy parsing approach to dependency extraction. We also compared SNEIPL to fact extractors present in language-independent reverse engineering tools.ResultsOur approach to dependency extraction is validated on six real-world medium to large-scale software systems written in Java, Modula-2, and Delphi. The results of the comparative analysis involving ten Java software systems show that the networks formed by SNEIPL are highly similar to those formed by Dependency Finder and more precise than the comparable networks formed with the help of Doxygen. Regarding the comparison with language-independent reverse engineering tools, SNEIPL provides both language-independent extraction and representation of fact bases.ConclusionSNEIPL is a language-independent extractor of software networks and consequently enables language-independent network-based analysis of software systems, computation of design software metrics, and extraction of fact bases for reverse engineering activities.