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.     

An Approach for Recovering Distributed System Architectures

Reasoning about software systems at the architectural level is key to effective software development, management, evolution and reuse. All too often, though, the lack of appropriate documentation leads to a situation where architectural design information has to be recovered directly from implemented software artifacts. This is a very demanding process, particularly when involving recovery of runtime abstractions (clients, servers, interaction protocols, etc.) that are typical to the design of distributed software systems. This paper presents an exploratory reverse engineering approach, called X-ray, to aid programmers in recovering architectural runtime information from a distributed system's existing software artifacts. X-ray comprises three domain-based static analysis techniques, namely component module classification, syntactic pattern matching, and structural reachability analysis. These complementary techniques can facilitate the task of identifying a distributed system's implemented executable components and their potential runtime interconnections. The component module classification technique automatically distinguishes source code modules according to the executables components they implement. The syntactic pattern matching technique in turn helps to recognise specific code fragments that may implement typical component interaction features. Finally, the structural reachability analysis technique aids in the association of those features to the code specific for each executable component. The paper describes and illustrates the main concepts underlying each technique, reports on their implementation as a suit of new and off-the-shelf tools, and, to give evidence of the utility of the approach, provides a detailed account of a successful application of the three techniques to help recover a static approximation of the runtime architecture for Field, a publicly-available distributed programming environment.     

Software architecture correctness

Software quality stems from many factors, including implementation decisions, software architecture, and requirements. We focus on software architecture, which can enable or inhibit many of a software system's qualities. Because the cost of addressing quality concerns is a function of how late you address them (the later, the more costly), addressing them in the architectural or requirements phase makes sense     

Evolution Through Architectural Reconciliation

One of the possible scenarios in a system evolution cycle, is to translate an emergent set of new requirements into software architecture design and subsequently to update the system implementation. In this paper, we argue that this form of forward engineering, even though addresses the new system requirements, tends to overlook the implementation constraints. An architect must also reverse-engineer the system, in order to make these constraints explicit. Thus, we propose an approach where we reconcile two architectural models, one that is forward-engineered from the requirements and another that is reverse-engineered from the implementation. The final reconciled model is optimally adapted to the emergent set of requirements and to the actual system implementation. The contribution of this paper is twofold: the application of architectural reconciliation in the context of software evolution and an approach to formalize both the specification and transformation of the architectural models. The architectural modeling is based upon the UML 2.0 standard, while the formalization approach is based on set theory and first-order logic.     

Speaking Truth to Power

Whenever the author conducts an architectural assessment for software development projects, he endeavors to speak truth to power: those with true power never fear the truth. Sam Guckenheimer has observed that in software code there is truth. Code represents the stark reality of a software development organization's labor. There is also truth to be found in a system's architecture. Every system's architecture is molded by the forces that swirl around it, and the collective concerns of all the stakeholders represent the most dynamic forces shaping a system. The software development organization's unique task is to address all the essential concerns of all the important stakeholders and to ensure that they aren't blindsided by unexpected problems and stakeholders. This is why employing a process that incrementally and iteratively grows a system's architecture through the regular release of testable executables is so important. Such a process lets the software team engage the right stakeholders at the right time and to make the right decisions, neither too early nor too late. In creating a software-intensive system that's both relevant and beautiful, every stakeholder, no matter how close or how far from the code, deserves the truth     

An architecture for attacking the communication bottleneck in P systems

The distributed implementation of P systems on a cluster of processors has met with a bottleneck communications problem. When the number of membranes grows in the system, the network gets congested and the time taken to execute an evolution step degrades. In this article, we suggest a software architecture denominated “partially parallel evolution with partially parallel communication”, where some membranes are located in each processor, proxies are used to communicate with membranes located in different processors, and a policy of access control to the communications network is mandatory. With all this, we get a certain parallelism in the system and an acceptable functioning in communications. In addition to this, it establishes a series of equations that allows us to determine in the architecture the optimum number of processors needed, the time required to execute an evolution step, the number of membranes to be located in each processor, and the conditions to determine when it is best to use the distributed solution or the sequential one. This work was presented in part at the 12th International Symposium on Artificial Life and Robotics, Oita, Japan, January 25–27, 2007     

A large-scale study of architectural evolution in open-source software systems

From its very inception, the study of software architecture has recognized architectural decay as a regularly occurring phenomenon in long-lived systems. Architectural decay is caused by repeated, sometimes careless changes to a system during its lifespan. Despite decay’s prevalence, there is a relative dearth of empirical data regarding the nature of architectural changes that may lead to decay, and of developers’ understanding of those changes. In this paper, we take a step toward addressing that scarcity by introducing an architecture recovery framework, ARCADE, for conducting large-scale replicable empirical studies of architectural change across different versions of a software system. ARCADE includes two novel architectural change metrics, which are the key to enabling large-scale empirical studies of architectural change. We utilize ARCADE to conduct an empirical study of changes found in software architectures spanning several hundred versions of 23 open-source systems. Our study reveals several new findings regarding the frequency of architectural changes in software systems, the common points of departure in a system’s architecture during the system’s maintenance and evolution, the difference between system-level and component-level architectural change, and the suitability of a system’s implementation-level structure as a proxy for its architecture.     

An exploratory study of architectural effects on requirements decisions

The question of the “manner in which an existing software architecture affects requirements decision-making” is considered important in the research community; however, to our knowledge, this issue has not been scientifically explored. We do not know, for example, the characteristics of such architectural effects. This paper describes an exploratory study on this question. Specific types of architectural effects on requirements decisions are identified, as are different aspects of the architecture together with the extent of their effects. This paper gives quantitative measures and qualitative interpretation of the findings. The understanding gained from this study has several implications in the areas of: project planning and risk management, requirements engineering (RE) and software architecture (SA) technology, architecture evolution, tighter integration of RE and SA processes, and middleware in architectures. Furthermore, we describe several new hypotheses that have emerged from this study, that provide grounds for future empirical work. This study involved six RE teams (of university students), whose task was to elicit new requirements for upgrading a pre-existing banking software infrastructure. The data collected was based on a new meta-model for requirements decisions, which is a bi-product of this study.     

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.     

Software evolution through rapid prototyping

Rapid prototyping is defined, and its role in software evolution is examined. Software evolution refers to all activities that change a software system. It differs from maintenance in that the latter is done after the initial development, whereas evolution activities are interleaved with the initial development and continue after the delivery of the initial version of the system. In the author's approach to rapid prototyping, software systems are delivered incrementally and requirements analysis continues throughout the process, interleaved with implementation and evolution. The focus is on reducing requirements errors through prototyping before undertaking the incremental implementation effort for each deliverable version of the system. The evolution of a hyperthermia system is considered as an example     

软件体系结构驱动的运行环境

由于软件体系结构以隐性的方式存在，结构的问题被传播到平台内，运行时软件体系结构不能在应用层次上被观察和控制，系统难以联机动态演化．在现有的中间件平台之上设计了一个面向应用、开放的、软件体系结构驱动的分布式远行环境SADRE（Software Architecture—Driven Runtime Environment），软件体系结构在可运行系统中以一类实体显性地表示,体系结构描述作为核心元素被整个分布式运行环境共事，成为系统调度、通信的依据．从而驱动用户应用的运行．SADRE为灵活的动态体系结构提供了良好的支持，提高了系统的柔性和扩展性．     

The Irrelevance of Architecture

The architecture of a software-intensive system is largely irrelevant to its end users. Far more important to these stakeholders is the system's behavior, exhibited by raw, naked, running code. Most interesting system tests should be based on the use cases that are identified incrementally over the system's life cycle, the same use cases that the system's architects used to guide their design decisions. Testers can conduct other system tests only after the system's architecture is crisp. Just as analysts use a system's architecture as scaffolding along which to climb and examine the details of every edge, so too can testers use a system's architecture to devise tests that are relevant to the particular texture of that implementation     

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.     

χSuds-SDL: A Tool for Testing Software Architecture Specifications

Available statistical data shows that the cost of repairing software faults rises dramatically in later development stages. In particular, the new technology of generating implementation code from architectural specifications requires highly reliable designs. Much research has been done at this stage using verification and validation techniques to prove correctness in terms of certain properties. A prominent approach of this category is model checking (Atlee, J.M., and Gannon, J. 1993. State-based model checking of event-driven systems requirements. IEEE Trans. Software Eng., 19(1): 24–40.) Such approaches and the approach of software testing are complementary. Testing reveals some errors that cannot be easily identified through verification, and vice versa. This paper presents the technology and the accompanying tool suite to the testing of software architecture specifications. We apply our state-of-the-art technology in software coverage testing, program diagnosis and understanding to software architectural designs. Our technology is based on both the control flow and the data flow of the executable architectural specifications. It first generates a program flow diagram from the specification and then automatically analyses the coverage features of the diagram. It collects the corresponding flow data during the design simulation to be mapped to the flow diagram. The coverage information for the original specification is then obtained from the coverage information of the flow diagram. This technology has been used for C, C++, and Java, and has proven effective (Agrawal, H., Alberti, J., Li, J.J., et al. 1998. Mining system tests to aid software maintenance, IEEE Computer July, pp. 64–73.)     

Linguistic and architectural requirements for personalized digital libraries

information tokens as supplied by information providers on the net; value is added to such tokens by individually constructing information artifacts over them with the goal of information consumer satisfaction; (2) the services required for artifact construction and use – on the information level as well as on the level of the software artifacts required for these processes – rely heavily on powerful binding environments for multi-medial, persistent and networked information; (3) the processes of artifact construction and use are in themselves valuable sources of information about artifacts; for the exploitation of such process information, digital libraries employ advanced tracing environments. We derive linguistic and architectural requirements for digital libraries from these above essentials. On the language level we concentrate on generalized requirements for the typing, binding and scoping of library entities and services. On the system level we discuss architectural requirements in terms of orthogonal persistence, open extensibility, platform independence, mobility and reflection. We present Tycoon, a polymorphic, higher-order language and its system, and demonstrate its potential for digital libraries. We evaluate Tycoon's rich conceptual basis (data, functions and threads), library-based extensibility, powerful binding mechanisms, its orthogonal persistence and its capability of network-wide data, code and thread migration. We conclude by referring to an interdisciplinary digital library project in Art History Research based on icons, texts and data. Here, Tycoon effectively supports the process of individually customizing and scaling library services thus generalizing the notion of a query language into that of a persistent personal reference library. Received: 1 August 1996 / Accepted: 15 November 1996     

一种发现运行时软件体系结构的方法

运行时软件体系结构能够准确描述目标系统的真实状态和行为,对指导软件的维护和演化起着重要的作用。本文提出了一种发现运行时体系结构的方法,利用系统实现与体系结构风格之间的对应关系,定义了一种基于规则的转换映射;将收集到的底层系统事件解释成体系结构层面的操作,从而可获取运行时体系结构视图;通过一个即时通信系统实例说明了该方法的可行性。     

基于B/S的双CCD相机精度靶测控系统软件架构设计

上位机软件是双CCD相机精度靶测控系统中非常重要的一部分;针对精度靶测控系统软件存在后期功能拓展难、维护效率低、使用升级复杂等问题;先进行了对该类软件的调查研究,然后分析上位机测控软件功能需求,根据软件的需求分析,设计了一种基于B/S架构的精度靶测控系统上位机软件实现方案;软件架构采用了浏览器和服务器方式专有的三层结构,在中间层设计了TCP服务器,提高软件的功能拓展性,降低了实现代码的耦合性;采用了Netty通信技术框架及其非阻塞技术实现了TCP服务器底层,设计了专有的解码方法接收下位机数据及发送控制指令;通过模拟测试,能够满足下位机频繁发送数据,上位机稳定接收和可靠运行的功能需求,软件的结构设计合理,扩展性和维护性良好。     

基于模式匹配的软件架构恢复的研究

行业软件的开发常常是一个不断进化的过程。架构恢复对干软件维护和软件进化至关重要。本文介绍了软件架构恢复策略的框架、步骤和相关研究；描述了基于模式匹配进行软件架构恢复的方法，着重介绍了该架构恢复所基于的恢复环境、执行过程和模武匹配算法的具体实现。最后，给出了对Clips系统进行实验所得到的恢复结果的评估。     

A systematic review of software architecture evolution research

Context

Software evolvability describes a software system’s ability to easily accommodate future changes. It is a fundamental characteristic for making strategic decisions, and increasing economic value of software. For long-lived systems, there is a need to address evolvability explicitly during the entire software lifecycle in order to prolong the productive lifetime of software systems. For this reason, many research studies have been proposed in this area both by researchers and industry practitioners. These studies comprise a spectrum of particular techniques and practices, covering various activities in software lifecycle. However, no systematic review has been conducted previously to provide an extensive overview of software architecture evolvability research.

Objective

In this work, we present such a systematic review of architecting for software evolvability. The objective of this review is to obtain an overview of the existing approaches in analyzing and improving software evolvability at architectural level, and investigate impacts on research and practice.

Method

The identification of the primary studies in this review was based on a pre-defined search strategy and a multi-step selection process.

Results

Based on research topics in these studies, we have identified five main categories of themes: (i) techniques supporting quality consideration during software architecture design, (ii) architectural quality evaluation, (iii) economic valuation, (iv) architectural knowledge management, and (v) modeling techniques. A comprehensive overview of these categories and related studies is presented.

Conclusion

The findings of this review also reveal suggestions for further research and practice, such as (i) it is necessary to establish a theoretical foundation for software evolution research due to the fact that the expertise in this area is still built on the basis of case studies instead of generalized knowledge; (ii) it is necessary to combine appropriate techniques to address the multifaceted perspectives of software evolvability due to the fact that each technique has its specific focus and context for which it is appropriate in the entire software lifecycle.