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.     

Harmonizing architectural decisions with component view models using reusable architectural knowledge transformations and constraints

Architectural design decisions (ADDs) have been used in recent years for capturing design rationale and documenting architectural knowledge (AK). However, various architectural design views still provide the most common means for describing and communicating architectural design. The evolution of software systems requires that both ADDs and architectural design views are documented and maintained, which is a tedious and time-consuming task in the long run. Also, in lack of a systematic and automated support for bridging between ADDs and architectural design views, decisions and designs tend to become inconsistent over time. In our proposal, we introduce a reusable AK transformation language for supporting the automated transformation of reusable AK knowledge to component-and-connector models, the architectural design view used most commonly today. In addition, reusable consistency checking rules verify the consistency between decisions and designs. We evaluate our approach in an industrial case study and show that it offers high reusability, provides automation, and can, in principle, deal with large numbers of recurring decisions.     

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.     

SHADD: A scenario-based approach to software architectural defects detection

Although a good architecture is not sufficient to guarantee the success of a software product, undoubtedly it is essential to support the product quality. Evaluating software architecture provides early insight into product capabilities and limitations. The earlier in the life cycle the problems are detected, the cheaper it is to fix them. In this paper, at first, a review on well-known scenario-based methods to evaluate software architectures is presented, and their advantages and limitations are discussed. Then, a method named SHADD with different characteristics is introduced to detect architectural defects. Using a scenario-based approach, the proposed method finds out the critical aspects and potential problems threatening the system from the stakeholder’s point of view. Scenarios are then used as a basis for the process of architectural defects detection. SHADD and its elements are specified in a systematic form and an illustration of its application on the architecture of a real system is also presented. The results show that SHADD can be used to detect those architectural defects which may be uncovered during the application of conventional evaluation methods.     

Software architectural patterns in practice: an empirical study

Software architecture involves a series of decisions based on many factors in a wide range of software development. Architects face recurring issues in different software architecture design, and to reduce huge cost and risks, software architecture decisions can rely on a set of idiomatic patterns commonly named architectural styles or patterns. Architectural pattern determines the vocabulary of components and connectors that are used in instances of the pattern together with a set of constraints to combine the two. Little contemporary data exists to document actual practices used by software professionals when selecting and incorporating architectural patterns for their projects in industry. Therefore, a comprehensive survey of software professionals was conducted to attempt to discover these practices. This exploratory survey and its quantitative results offer opportunities for further interpretation and comparison. Data from this survey are presented in this paper and include characteristics of projects, practices, organizations, and practitioners related to the usage of architectural patterns. Some of the notable findings include that architectural patterns are widely used in software projects with the Model–View–Controller being the most common. Despite reported difficulties in incorporating architectural patterns, the majority of the software professionals revealed that patterns were the most essential for completing the projects. The most difficult pattern to implement and the most expensive to adopt was the peer-to-peer, while the easiest was the client–server.

     

Quality-driven architecture development using architectural tactics

This paper presents a quality-driven approach to embodying non-functional requirements (NFRs) into software architecture using architectural tactics. Architectural tactics are reusable architectural building blocks, providing general architectural solutions for common issues pertaining to quality attributes. In this approach, architectural tactics are represented as feature models, and their semantics is defined using the Role-Based Metamodeling Language (RBML) which is a UML-based pattern specification notation. Given a set of NFRs, architectural tactics are selected and composed, and the composed tactic is used to instantiate an initial architecture for the application. The proposed approach addresses both the structural and behavioral aspects of architecture. We describe the approach using tactics for performance, availability and security to develop an architecture for a stock trading system. We demonstrate tool support for instantiating a composed tactic to generate an initial architecture of the stock trading system.     

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.     

Architecture compliance checking at run-time

In this paper, we report on our experiences with architecture compliance checking – the process of checking whether the planned or specified software architecture is obeyed by the running system – of an OSGi-based, dynamically evolving application in the office domain. To that end, we first show how to dynamically instrument a running system in the context of OSGi in order to collect run-time traces. Second, we explain how to bridge the abstraction gap between run-time traces and software architectures, through the construction of hierarchical Colored Petri nets (CP-nets). In addition, we demonstrate how to design reusable hierarchical CP-nets. In an industry example, we were able to extract views that helped us to identify a number of architecturally relevant issues (e.g., architectural style violations, behavior violations) that would not have been detected otherwise, and could have caused serious problems like system malfunctioning or unauthorized access to sensitive data. Finally, we package valuable experiences and lessons learned from this endeavor.     

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.     

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.     

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.     

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.     

The Decision View's Role in Software Architecture Practice

A decision view provides a useful complement to the traditional sets of architectural views and viewpoints. It gives an explanatory perspective that illuminates the reasoning process itself and not solely its results. The decision view documents aspects of the architecture that are hard to reverse-engineer from the software itself and that are often left tacit. The decision view and the decisions that it captures embody high-level architectural knowledge that can be transferred to other practitioners and merged when systems are merged, and they offer useful support for maintaining large, long-lived software-intensive systems. This article leads readers through a succession of epiphanies: from design to architecture, then architecture representation to architecture design methods, and finally to architectural design decisions.     

Assessing architectural evolution: a case study

This paper proposes to use a historical perspective on generic laws, principles, and guidelines, like Lehman’s software evolution laws and Martin’s design principles, in order to achieve a multi-faceted process and structural assessment of a system’s architectural evolution. We present a simple structural model with associated historical metrics and visualizations that could form part of an architect’s dashboard. We perform such an assessment for the Eclipse SDK, as a case study of a large, complex, and long-lived system for which sustained effective architectural evolution is paramount. The twofold aim of checking generic principles on a well-know system is, on the one hand, to see whether there are certain lessons that could be learned for best practice of architectural evolution, and on the other hand to get more insights about the applicability of such principles. We find that while the Eclipse SDK does follow several of the laws and principles, there are some deviations, and we discuss areas of architectural improvement and limitations of the assessment approach.     

Using software evolution to focus architectural recovery

Ideally, a software project commences with requirements gathering and specification, reaches its major milestone with system implementation and delivery, and then continues, possibly indefinitely, into an operation and maintenance phase. The software system's architecture is in many ways the linchpin of this process: it is supposed to be an effective reification of the system's technical requirements and to be faithfully reflected in the system's implementation. Furthermore, the architecture is meant to guide system evolution, while also being updated in the process. However, in reality developers frequently deviate from the architecture, causing architectural erosion, a phenomenon in which the initial, “as documented' architecture of an application is (arbitrarily) modified to the point where its key properties no longer hold. Architectural recovery is a process frequently used to cope with architectural erosion whereby the current, “as implemented” architecture of a software system is extracted from the system's implementation. In this paper we propose a light-weight approach to architectural recovery, called Focus, which has three unique facets. First, Focus uses a system's evolution requirements to isolate and incrementally recover only the fragment of the system's architecture affected by the evolution. In this manner, Focus allows engineers to direct their primary attention to the part of the system that is immediately impacted by the desired change; subsequent changes will incrementally uncover additional parts of the system's architecture. Secondly, in addition to software components, which are the usual target of existing recovery approaches, Focus also recovers the key architectural notions of software connector and architectural style. Finally, Focus does not only recover a system's architecture, but may in fact rearchitect the system. We have applied and evaluated Focus in the context of several off-the-shelf applications and architectural styles to date. We discuss its key strengths and point out several open issues that will frame our future work.