Anton Jansen

Software Architecture as a Set of Architectural Design Decisions

Software architectures have high costs for change, are complex, and erode during evolution. We believe these problems are partially due to knowledge vaporization. Currently, almost all the knowledge and information about the design decisions the architecture is based on are implicitly embedded in the architecture, but lack a first-class representation. Consequently, knowledge about these design decisions disappears into the architecture, which leads to the aforementioned problems. In this paper, a new perspective on software architecture is presented, which views software architecture as a composition of a set of explicit design decisions. This perspective makes architectural design decisions an explicit part of a software architecture. Consequently, knowledge vaporization is reduced, thereby alleviating some of the fundamental problems of software architecture.

A comparative study of architecture knowledge management tools

Recent research suggests that architectural knowledge, such as design decisions, is important and should be recorded alongside the architecture description. Different approaches have emerged to support such architectural knowledge (AK) management activities. However, there are different notions of and emphasis on what and how architectural activities should be supported. This is reflected in the design and implementation of existing AK tools. To understand the current status of software architecture knowledge engineering and future research trends, this paper compares five architectural knowledge management tools and the support they provide in the architecture life-cycle. The comparison is based on an evaluation framework defined by a set of 10 criteria. The results of the comparison provide insights into the current focus of architectural knowledge management support, their advantages, deficiencies, and conformance to the current architectural description standard. Based on the outcome of this comparison a research agenda is proposed for future work on AK tools.

Tool Support for Architectural Decisions

In contrast to software architecture models, architectural decisions are often not explicitly documented, and therefore eventually lost. This contributes to major problems such as high-cost system evolution, stakeholders mis-communication, and limited reusability of core system assets. An approach is outlined that systematically and semi-automatically documents architectural decisions and allows them to be effectively shared by the stakeholders. A first attempt is presented that partially implements the approach by binding architectural decisions, models and the system implementation. The approach is demonstrated with an example demonstrating its usefulness with regards to some industrial use cases.

Enriching software architecture documentation

The effective documentation of Architectural Knowledge (AK) is one of the key factors in leveraging the paradigm shift toward sharing and reusing AK. However, current documentation approaches have severe shortcomings in capturing the knowledge of large and complex systems and subsequently facilitating its usage. In this paper, we propose to tackle this problem through the enrichment of traditional architectural documentation with formal AK. We have developed an approach consisting of a method and an accompanying tool suite to support this enrichment. We evaluate our approach through a quasi-controlled experiment with the architecture of a real, large, and complex system. We provide empirical evidence that our approach helps to partially solve the problem and indicate further directions in managing documented AK.

Design Decisions: The Bridge between Rationale and Architecture

Software architecture can be seen as a decision making process; it involves making the right decisions at the right time. Typically, these design decisions are not explicitly represented in the artifacts describing the design. They reside in the minds of the designers and are therefore easily lost. Rationale management is often proposed as a solution, but lacks a close relationship with software architecture artifacts. Explicit modeling of design decisions in the software architecture bridges this gap, as it allows for a close integration of rationale management with software architecture. This improves the understandability of the software architecture. Consequently, the software architecture becomes easier to communicate, maintain and evolve. Furthermore, it allows for analysis, improvement, and reuse of design decisions in the design process.

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.

Evaluation of tool support for architectural evolution

Evolution of software architectures is, different from architectural design, an area that only few tools have covered. We claim this is due to the lack of support for an important concept of architectural evolution: the notion of architectural design decisions. The absence of this concept in architectural evolution leads to several problems. In order to address these problems, we present a set of requirements that tools should support for architectural evolution. We evaluate existing software architecture tools against these architectural requirements. The results are analyzed and an outline for future research directions for architectural evolution tool support is presented.

Collaborative Software Architecting Through Knowledge Sharing

In the field of software architecture, there has been a paradigm shift from describing the outcome of the architecting process to documenting architectural knowledge, such as design decisions and rationale. Moreover, in a global, distributed setting, software architecting is essentially a collaborative process in which sharing and reusing architectural knowledge is a crucial and indispensible part. Although the importance of architectural knowledge has been recognized for a considerable period of time, there is still no systematic process emphasizing the use of architectural knowledge in a collaborative context. In this chapter, we present a two-part solution to this problem: a collaborative architecting process based on architectural knowledge and an accompanying tool suite that demonstrates one way to support the process.

First class feature abstractions for product derivation

The authors have observed that large software systems are increasingly defined in terms of the features they implement. Consequently, there is a need to express the commonalities and variability between products of a product family in terms of features. Unfortunately, technology support for the early aspect of a feature is currently limited to the requirements level. There is a need to extend this support to the design and implementation level as well. Existing separation of concerns technologies, such as AOP and SOP, may be of use here. However, features are not first class citizens in these paradigms. To address this and to explore the problems and issues with respect to features and feature composition, the authors have formalised the notion of features in a feature model. The feature model relates features to a component role model. Using our model and a composition algorithm, a number of base components and a number of features may be selected from a software product family and a product derived. As a proof of concept, the authors have experimented extensively with a prototype Java implementation of their approach.

Sharing the Architectural Knowledge of Quantitative Analysis

Sharing the architectural knowledge of architectural analysis among stakeholders proves to be troublesome. This causes problems in and with architectural analysis, which can have serious consequences for the quality of a system being developed, as this quality might be incompletely or wrongly assessed. This paper presents a domain model, which can be used as a common ground among analysts and architects to capture and explicitly share such knowledge. This enables a way to overcome some of the obstacles imposed by the multi-disciplinary context in which architectural analysis takes place. To apply the domain model in practice, we have created a tool implementing (part of) this domain model for capturing and using explicit architectural knowledge during analysis. We validate the tool and domain model in the context of an industrial case study.