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.
Various methods and tools for architectural decision modeling have been surveyed in @cite_4 @cite_9 . In general, the role of architectural decision models can be twofold. They can be used to document decisions that have already been made and or to ontologize the decision making process in a given domain. In the first case, decisions are usually documented in a form of textual descriptions of their attributes, sometimes accompanied with illustrating diagrams @cite_14 @cite_11 @cite_10 @cite_13 @cite_5 @cite_8 . In the latter case, architectural decision models focus on showing possible decisions and relationships between them within the decision making process @cite_12 @cite_6 .
@cite_13 @cite_14 @cite_4 @cite_8 @cite_9 @cite_6 @cite_5 @cite_10 @cite_12 @cite_11
2162923122 2344257933 1981396776 1966654106
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. The architecture of a software system results from decisions made by the developers throughout the software life cycle. Any decision pertaining to software architecture is called an architectural decision. Architectural decision modelling captures the dependencies that exist between the decisions and serves as a foundation for knowledge management and reuse. Several models have been described in the literature, using natural language to explain the basic notions and class diagrams to show relations between them. However, a formal definition of an architectural decision is still missing. This paper analyzes existing architectural decision models and provides a formal background for the basic notions that all the models have consensus on. The major contribution of this paper is twofold: to propose a set-theoretic definition of the semantics of architectural decisions; and to show an explicit interpretation of basic relationships that exist in the architectural knowledge. The formalization can help in understanding the meaning of architectural decisions and the meaning of relations that exist between the decision elements. UML-based metamodel for architectural design decisions is also presented. 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. 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.