Paris Avgeriou

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.

VxBPEL: Supporting variability for Web services in BPEL

Web services provide a way to facilitate the business integration over the Internet. Flexibility is an important and desirable property of Web service-based systems due to dynamic business environments. The flexibility can be provided or addressed by incorporating variability into a system. In this study, we investigate how variability can be incorporated into service-based systems. We propose a language, VxBPEL, which is an adaptation of an existing language, BPEL, and able to capture variability in these systems. We develop a prototype to interpret this language. Finally, we illustrate our method by using it to handle variability of an example.

Variability in Software Systems—A Systematic Literature Review

Context: Variability (i.e., the ability of software systems or artifacts to be adjusted for different contexts) became a key property of many systems. Objective: We analyze existing research on variability in software systems. We investigate variability handling in major software engineering phases (e.g., requirements engineering, architecting). Method: We performed a systematic literature review. A manual search covered 13 premium software engineering journals and 18 premium conferences, resulting in 15,430 papers searched and 196 papers considered for analysis. To improve reliability and to increase reproducibility, we complemented the manual search with a targeted automated search. Results: Software quality attributes have not received much attention in the context of variability. Variability is studied in all software engineering phases, but testing is underrepresented. Data to motivate the applicability of current approaches are often insufficient; research designs are vaguely described. Conclusions: Based on our findings we propose dimensions of variability in software engineering. This empirically grounded classification provides a step towards a unifying, integrated perspective of variability in software systems, spanning across disparate or loosely coupled research themes in the software engineering community. Finally, we provide recommendations to bridge the gap between research and practice and point to opportunities for future research.

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.

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.

A documentation framework for architecture decisions

In this paper, we introduce a documentation framework for architecture decisions. This framework consists of four viewpoint definitions using the conventions of ISO/IEC/IEEE 42010, the new international standard for the description of system and software architectures. The four viewpoints, a Decision Detail viewpoint, a Decision Relationship viewpoint, a Decision Chronology viewpoint, and a Decision Stakeholder Involvement viewpoint satisfy several stakeholder concerns related to architecture decision management. With the exception of the Decision Stakeholder Involvement viewpoint, the framework was evaluated in an industrial case study. The results are promising, as they show that decision views can be created with reasonable effort while satisfying many of the stakeholder concerns in decision documentation.

How do architecture patterns and tactics interact? A model and annotation

Software architecture designers inevitably work with both architecture patterns and tactics. Architecture patterns describe the high-level structure and behavior of software systems as the solution to multiple system requirements, whereas tactics are design decisions that improve individual quality attribute concerns. Tactics that are implemented in existing architectures can have significant impact on the architecture patterns in the system. Similarly, tactics that are selected during initial architecture design significantly impact the architecture of the system to be designed: which patterns to use, and how they must be changed to accommodate the tactics. However, little is understood about how patterns and tactics interact. In this paper, we develop a model for the interaction of patterns and tactics that enables software architects to annotate architecture diagrams with information about the tactics used and their impact on the overall structure. This model is based on our in-depth analysis of the types of interactions involved, and we show several examples of how the model can be used to annotate different kinds of architecture diagrams. We illustrate the model and annotation by showing examples taken from real systems, and describe how the annotation was used in architecture reviews. Tactics and patterns are known architectural concepts; this work provides more specific and in-depth understanding of how they interact. Its other key contribution is that it explores the larger problem of understanding the relation between strategic decisions and how they need to be tailored in light of more tactical decisions.

First workshop on sharing and reusing architectural knowledge

The first SHARK (SHAring and Reusing architectural Knowledge) workshop, attempted to explore the state of the art as well as the state of the practice in this emerging field. This workshop report presents the themes of the workshop, it summarizes the results of the discussions held about various topics, and suggests some research topics that are worthwhile to pursue in the future.

Architectural knowledge and rationale: issues, trends, challenges

The second workshop on Sharing and Reusing Architectural Knowledge (SHARK) and Architecture rationale and Design intent (ADI) was held jointly with ICSE 2007 in Minneapolis. This report presents the themes of the workshop, summarizes the results of the discussions held, and suggests some topics for future research.