A software architecture is the result of multiple decisions made by a software architect. These decisions are called architectural decisions, as they bring solutions to architectural problems. Relations between decisions can be captured in architectural decision models. Such models are then a form of reusable knowledge for software architects. Several models have been described in the literature, introducing necessary concepts and relations. These concepts and relations were usually explained using natural language. Not much work has been done so far on their formal definitions. Specifically, such a definition of an architectural decision model is still missing. The purpose of this paper is filling this gap by providing the formal definition of an architectural decision model at both syntax and semantics levels. At the syntax level, different concepts and relations that are elements of a model have been mathematically defined. At the semantics level, the meaning of a model has been defined in a form of denotational semantics. The formalization not only allows for better understanding of architectural decision models but opens the possibility to reason on such models, e.g., checking their consistency - something that is very limited for the models proposed so far. A practical example of the semantics of an architectural decision model is also presented.
All software systems are built as a result of a set of design decisions that are made during the architecting phase. At present, there is still a lack of appropriate notations, methods and tools for recording and exploiting these architectural design decisions. In addition, the need for maintaining and evolving the decisions made in the past turns critical for the success of the evolution of the system. In this research paper we extend a previous work to detail those issues related to the evolution 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. In the field of software architecture, there has been a paradigm shift from describing the outcome of architecting process mostly described by component and connector (know-what) to documenting architectural design decisions and their rationale (know-how) which leads to the production of an architecture. This paradigm shift results in emergence of various models and related tools for capturing, managing and sharing architectural design decisions and their rationale explicitly. This paper analyzes existing architectural design decisions models and provides a criteria-based comparison on tools that support these models. The major contribution of this paper is twofold: to show that all of these models have a consensus on capturing the essence of an architectural design decision; and to clarify the major difference among the tools and show what desired features are missing in these 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. 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.  Throughout the software design process, developers must make decisions and reify them in code. The decisions made during software architecting are particularly significant in that they have system-wide implications, especially on the quality attributes. However, architects often fail to adequately document their decisions because they don't appreciate the benefits, don't know how to document decisions, or don't recognize that they're making decisions. This lack of thorough documentation. This paper provides information about a decision's rationale and consequences, architecture patterns can help architects better understand and more easily record their decisions. Architectural knowledge consists of architecture design as well as the design decisions, assumptions, context, and other factors that together determine why a particular solution is the way it is. Except for the architecture design part, most of the architectural knowledge usually remains hidden, tacit in the heads of the architects. We conjecture that an explicit representation of architectural knowledge is helpful for building and evolving quality systems. If we had a repository of architectural knowledge for a system, what would it ideally contain, how would we build it, and exploit it in practice? In this paper we describe a use-case model for an architectural knowledge base, together with its underlying ontology. We present a small case study in which we model available architectural knowledge in a commercial tool, the Aduna Cluster Map Viewer, which is aimed at ontology-based visualization. Putting together ontologies, use cases and tool support, we are able to reason about which types of architecting tasks can be supported, and how this can be done. We believe that a key to demystifying architecture products lies in the architecture decisions concept. We can make the architecture more transparent and clarify its rationale for all stakeholders by explicitly documenting major architecture decisions.