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.
An attempt to formally define the semantics of the elements of architectural decision models is presented in @cite_0 . It borrows the notation from @cite_6 , introducing sets of architectural decision alternatives, issues and outcomes. The proposed semantics defines the meaning of an architectural decision as a set of software systems in which this decision is implemented. Similarly, the meaning of various relationships between issues and alternatives is defined with reference to respective sets of software systems. The set of all software systems is finite @cite_0 but unbounded, what makes the presented definitions suitable for verifications with the use of approach, rather than @cite_3 . Another drawback of this work is the lack of definition of the semantics of the whole architectural decision model. Each element on the model is considered separately.
@cite_0 @cite_3 @cite_6
2344257933 1895387792 2162923122
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 Software Abstractions Daniel Jackson introduces an approach to software design that draws on traditional formal methods but exploits automated tools to find flaws as early as possible. This approach--which Jackson calls "lightweight formal methods" or "agile modeling"--takes from formal specification the idea of a precise and expressive notation based on a tiny core of simple and robust concepts but replaces conventional analysis based on theorem proving with a fully automated analysis that gives designers immediate feedback. Jackson has developed Alloy, a language that captures the essence of software abstractions simply and succinctly, using a minimal toolkit of mathematical notions. This revised edition updates the text, examples, and appendixes to be fully compatible with the latest version of Alloy (Alloy 4). The designer can use automated analysis not only to correct errors but also to make models that are more precise and elegant. This approach, Jackson says, can rescue designers from "the tarpit of implementation technologies" and return them to thinking deeply about underlying concepts. Software Abstractions introduces the key elements: a logic, which provides the building blocks of the language; a language, which adds a small amount of syntax to the logic for structuring descriptions; and an analysis, a form of constraint solving that offers both simulation (generating sample states and executions) and checking (finding counterexamples to claimed properties). 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.