Documenting after the fact: Recovering architectural design decisions

Software architecture documentation helps people in understanding the software architecture of a system. In practice, software architectures are often documented after the fact, i.e. they are maintained or created after most of the design decisions have been made and implemented. To keep the architecture documentation up-to-date an architect needs to recover and describe these decisions.This paper presents ADDRA, an approach an architect can use for recovering architectural design decisions after the fact. ADDRA uses architectural deltas to provide the architect with clues about these design decisions. This allows the architect to systematically recover and document relevant architectural design decisions. The recovered architectural design decisions improve the documentation of the architecture, which increases traceability, communication, and general understanding of a system.     

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.     

CHARMY: A Framework for Designing and Verifying Architectural Specifications

Introduced in the early stages of software development, the Charmy framework assists the software architect in making and evaluating architectural choices. Rarely, the software architecture of a system can be established once and forever. Most likely poorly defined and understood architectural constraints and requirements force the software architect to accept ambiguities and move forward to the construction of a suboptimal software architecture. Charmy aims to provide an easy and practical tool for supporting the iterative modeling and evaluation of software architectures. From an UML-based architectural design, an executable prototype is automatically created. Charmy simulation and model checking features help in understanding the functioning of the system and discovering potential inconsistencies of the design. When a satisfactory and stable software architecture is reached, Java code conforming to structural software architecture constraints is automatically generated through suitable transformations. The overall approach is tool supported.     

Mining Patterns from Change Logs to Support Reuse-Driven Evolution of Software Architectures

Modern software systems are subject to a continuous evolution under frequently varying requirements and changes in systems’ operational environments. Lehman’s law of continuing change demands for long-living and continuously evolving software to prolong its productive life and economic value by accommodating changes in existing software. Reusable knowledge and practices have proven to be successful for continuous development and evolution of the software effectively and efficiently. However, challenges such as empirical acquisition and systematic application of the reusable knowledge and practices must be addressed to enable or enhance software evolution. We investigate architecture change logs — mining histories of architecture-centric software evolution — to discover change patterns that 1) support reusability of architectural changes and 2) enhance the efficiency of the architecture evolution process. We model architecture change logs as a graph and apply graph-based formalism (i.e., graph mining techniques) to discover software architecture change patterns. We have developed a prototype that enables tool-driven automation and user decision support during software evolution. We have used the ISO-IEC-9126 model to qualitatively evaluate the proposed solution. The evaluation results suggest that the proposed solution 1) enables the reusability of frequent architectural changes and 2) enhances the efficiency of architecture-centric software evolution process. The proposed solution promotes research efforts to exploit the history of architectural changes to empirically discover knowledge that can guide architecture-centric software evolution.     

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.     

Quality-aware analysis in product line engineering with the orthogonal variability model

Software product line engineering is about producing a set of similar products in a certain domain. A variability model documents the variability amongst products in a product line. The specification of variability can be extended with quality information, such as measurable quality attributes (e.g., CPU and memory consumption) and constraints on these attributes (e.g., memory consumption should be in a range of values). However, the wrong use of constraints may cause anomalies in the specification which must be detected (e.g., the model could represent no products). Furthermore, based on such quality information, it is possible to carry out quality-aware analyses, i.e., the product line engineer may want to verify whether it is possible to build a product that satisfies a desired quality. The challenge for quality-aware specification and analysis is threefold. First, there should be a way to specify quality information in variability models. Second, it should be possible to detect anomalies in the variability specification associated with quality information. Third, there should be mechanisms to verify the variability model to extract useful information, such as the possibility to build a product that fulfils certain quality conditions (e.g., is there any product that requires less than 512?MB of memory?). In this article, we present an approach for quality-aware analysis in software product lines using the orthogonal variability model (OVM) to represent variability. We propose to map variability represented in the OVM associated with quality information to a constraint satisfaction problem and to use an off-the-shelf constraint programming solver to automatically perform the verification task. To illustrate our approach, we use a product line in the automotive domain which is an example that was created in a national project by a leading car company. We have developed a prototype tool named FaMa-OVM, which works as a proof of concepts. We were able to identify void models, dead and false optional elements, and check whether the product line example satisfies quality conditions.     

Evaluating reuse and program understanding in ArchMine architecture recovery approach

Several architecture recovery approaches have been proposed in the literature with distinct goals. ArchMine, an architecture recovery approach based on dynamic analysis and data mining, aims at assisting in program understanding and software reuse by detecting cohesive classes that implement a set of related functionalities, i.e., architectural elements. It is supported by a tool set integrated into a reuse-based software development environment. In order to better reach the proposed goals, ArchMine is integrated with two other approaches, namely: ArqCheck, an architectural evaluation approach based on inspection, and ArchToDSSA, a domain variability detection approach. ArchMine and its tool set have been detailed in previous works. The contribution of this paper is to describe how ArchMine and its tool set were evaluated and refined through a series of evaluation studies. These evaluations allowed us to gradually refine the approach based on the lessons learned. In the final study, within an industrial context, the integration between ArchMine and ArqCheck is evaluated.     

A classification and comparison of model checking software architecture techniques

Software architecture specifications are used for many different purposes, such as documenting architectural decisions, predicting architectural qualities before the system is implemented, and guiding the design and coding process. In these contexts, assessing the architectural model as early as possible becomes a relevant challenge. Various analysis techniques have been proposed for testing, model checking, and evaluating performance based on architectural models. Among them, model checking is an exhaustive and automatic verification technique, used to verify whether an architectural specification conforms to expected properties. While model checking is being extensively applied to software architectures, little work has been done to comprehensively enumerate and classify these different techniques.The goal of this paper is to investigate the state-of-the-art in model checking software architectures. For this purpose, we first define the main activities in a model checking software architecture process. Then, we define a classification and comparison framework and compare model checking software architecture techniques according to it.     

Architecture-directed refinement

As critical computer systems continue to grow in complexity, the task of showing that they execute correctly becomes more difficult. For this reason, research in software engineering has turned to formal methods, i.e., rigorous approaches to demonstrating the correctness of software systems. Unfortunately, the formal methods currently used in the design of concurrent systems do not provide any mechanisms for specifying and reasoning about the mapping of software to hardware. As a result, architectural constraints, even though they play an important role in the design process, are left out of the formal framework. We show how to state architectural constraints in a formal notation, how to prove that programs are allocated correctly to the underlying architecture, and how to factor architectural considerations into a program derivation process which uses a mixture of specification and program refinements. The approach is illustrated by the derivation of two related programs that solve the same problem but are designed to work on distinct architectures     

FORM: A feature-;oriented reuse method with domain-;specific reference architectures

Systematic discovery and exploitation of commonality across related software systems is a fundamental technical requirement for achieving successful software reuse. By examining a class/family of related systems and the commonality underlying those systems, it is possible to obtain a set of reference models, i.e., software architectures and components needed for implementing applications in the class. FORM (Feature-;Oriented Reuse Method) supports development of such reusable architectures and components (through a process called the “domain engineering”) and development of applications using the domain artifacts produced from the domain engineering. FORM starts with an analysis of commonality among applications in a particular domain in terms of services, operating environments, domain technologies, and implementation techniques. The model constructed during the analysis is called a “feature” model, and it captures commonality as an AND/OR graph, where AND nodes indicate mandatory features and OR nodes indicate alternative features selectable for different applications. Then, this model is used to define parameterized reference architectures and appropriate reusable components instantiatable during application development. Architectures are defined from three different viewpoints (subsystem, process, and module) and have intimate association with the features. The subsystem architecture is used to package service features and allocate them to different computers in a distributed environment. Each subsystem is further decomposed into processes considering the operating environment features. Modules are defined based on the features on domain technology and implementation techniques. These architecture models that represent an architecture at different levels of abstraction are derived from the feature hierarchy captured in the feature model. Modules serve as basis for creating reusable components, and their specification defines how they are integrated into the application (e.g., as-;is integration of pre-;coded component, instantiation of parameterized templates, and filling-;in skeletal codes). Our experiences have shown that for the electronic bulletin board and the private branch exchange (PBX) domains, “features” make up for a common domain language and the main communication medium among application users and developers. Thus, the feature model well represents a “decision space” of software development, and is a good starting point for identifying candidate reusable components.     

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.     

Architecture analysis of enterprise systems modifiability: a metamodel for software change cost estimation

Enterprise architecture models can be used in order to increase the general understanding of enterprise systems and specifically to perform various kinds of analysis. The present paper proposes a metamodel for enterprise systems modifiability analysis, i.e. assessing the cost of making changes to enterprise-wide systems. The enterprise architecture metamodel is formalized using probabilistic relational models, which enables the combination of regular entity-relationship modeling aspects with means to perform enterprise architecture analysis. The content of the presented metamodel is validated based on survey and workshop data and its estimation capability is tested with data from 21 software change projects. To illustrate the applicability of the metamodel an instantiated architectural model based on a software change project conducted at a large Nordic transportation company is detailed.     

Knowledge centered assessment pattern: an effective tool for assessing safety concerns in software architecture

In software-based systems, the notion of software failure is magnified if the software in question is a component of a safety critical system. Hence, to ensure a required level of safety, the product must undergo expensive rigorous testing and verification/validation activities. To minimize the cost of quality (COQ) associated with the development of safety critical systems, it becomes imperative that the assessment of intermediate artifacts (e.g., requirement, design documents or models) is done efficiently and effectively to maximize early defect detection and/or defect prevention. However, as a human-centered process, the assessment of software architecture for safety critical systems relies heavily on the experience and knowledge of the assessment team to ensure that the proposed architecture is consistent with the software functional and safety requirements.The knowledge centered assessment pattern (KCAP) acts as effective tool to assist assessment teams by providing key information on what architectural elements should be assessed, why they should to be assessed, and how they should be assessed. Furthermore, the use of KCAP highlights cases where the software architecture has been properly, over, under, or incoherently engineered.     

An integrated toolset for developing extensible applications

Financial-services IT systems should feature functional extensibility - an architectural mechanism to extend a system's functional capabilities. The paper describes an architecture and toolset provide the infrastructure to build extensible applications based on a services model.     

Application of knowledge-based approaches in software architecture: A systematic mapping study

ContextKnowledge management technologies have been employed across software engineering activities for more than two decades. Knowledge-based approaches can be used to facilitate software architecting activities (e.g., architectural evaluation). However, there is no comprehensive understanding on how various knowledge-based approaches (e.g., knowledge reuse) are employed in software architecture.ObjectiveThis work aims to collect studies on the application of knowledge-based approaches in software architecture and make a classification and thematic analysis on these studies, in order to identify the gaps in the existing application of knowledge-based approaches to various architecting activities, and promising research directions.MethodA systematic mapping study is conducted for identifying and analyzing the application of knowledge-based approaches in software architecture, covering the papers from major databases, journals, conferences, and workshops, published between January 2000 and March 2011.ResultsFifty-five studies were selected and classified according to the architecting activities they contribute to and the knowledge-based approaches employed. Knowledge capture and representation (e.g., using an ontology to describe architectural elements and their relationships) is the most popular approach employed in architecting activities. Knowledge recovery (e.g., documenting past architectural design decisions) is an ignored approach that is seldom used in software architecture. Knowledge-based approaches are mostly used in architectural evaluation, while receive the least attention in architecture impact analysis and architectural implementation.ConclusionsThe study results show an increased interest in the application of knowledge-based approaches in software architecture in recent years. A number of knowledge-based approaches, including knowledge capture and representation, reuse, sharing, recovery, and reasoning, have been employed in a spectrum of architecting activities. Knowledge-based approaches have been applied to a wide range of application domains, among which “Embedded software” has received the most attention.     

Providing Architectural Languages and Tools Interoperability through Model Transformation Technologies

Many architectural languages have been proposed in the last 15 years, each one with the chief aim of becoming the ideal language for specifying software architectures. What is evident nowadays, instead, is that architectural languages are defined by stakeholder concerns. Capturing all such concerns within a single, narrowly focused notation is impossible. At the same time, it is also impractical to define and use a “universal” notation, such as UML. As a result, many domain-specific notations for architectural modeling have been proposed, each one focusing on a specific application domain, analysis type, or modeling environment. As a drawback, a proliferation of languages exists, each one with its own specific notation, tools, and domain specificity. No effective interoperability is possible to date. Therefore, if a software architect has to model a concern not supported by his own language/tool, he has to manually transform (and, eventually, keep aligned) the available architectural specification into the required language/tool. This paper presents DUALLy, an automated framework that allows architectural languages and tools interoperability. Given a number of architectural languages and tools, they can all interoperate thanks to automated model transformation techniques. DUALLy is implemented as an Eclipse plugin. Putting it in practice, we apply the DUALLy approach to the Darwin/FSP ADL and to a UML2.0 profile for software architectures. By making use of an industrial complex system, we transform a UML software architecture specification in Darwin/FSP, make some verifications by using LTSA, and reflect changes required by the verifications back to the UML specification.     

Architectural evolution of FamiWare using cardinality-based feature models

ContextAmbient Intelligence systems domain is an outstanding example of modern systems that are in permanent evolution, as new devices, technologies or facilities are continuously appearing. This means it would be desirable to have a mechanism that helps with the propagation of evolution changes in deployed systems.ObjectiveWe present a software product line engineering process to manage the evolution of FamiWare, a family of middleware for ambient intelligence environments. This process drives the evolution of FamiWare middleware configurations using cardinality-based feature models, which are especially well suited to express the structural variability of ambient intelligence systems.MethodFamiWare uses cardinality-based feature models and clonable features to model the structural variability present in ambient intelligence systems, composed of a large variety of heterogeneous devices. Since the management evolution of configurations with clonable features is manually untreatable due to the high number of features, our process automates it and propagates changes made at feature level to the architectural components of the FamiWare middleware. This is a model driven development process as the evolution management, the propagation of evolution changes and the code generation are performed using some kind of model mappings and transformations. Concretely we present a variability modelling language to map the selection of features to the corresponding FamiWare middleware architectural components.ResultsOur process is able to manage the evolution of cardinality-based feature models with thousands of features, something which is not possible to tackle manually. Thanks to the use of the variability language and the automatic code generation it is possible to propagate and maintain a correspondence between the FamiWare architectural model and the code. The process is then able to calculate the architectural differences between the evolved configuration and the previous one. Checking these differences, our process helps to calculate the effort needed to perform the evolution changes in the customized products. To perform those tasks we have defined two operators, one to calculate the differences between two feature model configurations and another to create a new configuration from a previous one.ConclusionOur process automatically propagates the evolution changes of the middleware family into the existing configurations where the middleware is already deployed and also helps us to calculate the effort in performing the changes in every configuration. Finally, we validated our approach, demonstrating the functioning of the defined operators and showing that by using our tool we can generate evolved configurations for FamiWare with thousands of cloned features, for several case studies.     

Reliability-driven deployment optimization for embedded systems

One of the crucial aspects that influence reliability of embedded systems is the deployment of software components to hardware nodes. If the hardware architecture is designed prior to the customized software architecture, which is often the case in product-line manufacturing (e.g. in the automotive domain), the system architect needs to resolve a nontrivial task of finding a (near-)optimal deployment balancing the reliabilities of individual services implemented on the software level.In this paper, we introduce an approach to automate this task. As distinct to related approaches, which typically stay with quantification of reliability for a specific deployment, we target multi-criteria optimization and provide the architect with near-optimal (non-dominated) deployment alternatives with respect to service reliabilities. Toward this goal, we annotate the software and hardware architecture with necessary reliability-relevant attributes, design a method to quantify the quality of individual deployment alternatives, and implement the approach employing an evolutionary algorithm.