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.
@cite_6 , decisions made are distinguished from decisions required from the architect. The proposed UML metamodel for capturing architectural decisions contains, among others, three core entities: , and . An instance of ADIssue (an architectural decision issue) informs the architect that a single architecture design problem has to be solved, whereas instances of ADAlternative (architectural decision alternatives) present possible solutions to this problem. These two entities provide reusable background information. Finally, instances of ADOutcome (architectural decision outcomes) present an actual decision made to solve the problem including its rationale. The mentioned UML metamodel is complemented with formal definitions for a rich set of relationships between alternatives, alternatives and issues, and issues alone. However, the formal definitions of their semantics are missing.
@cite_6
2344257933 2162923122 1981396776 2786674049
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. 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. 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. In this paper, we present the results of long-term research conducted in order to study the contribution made by software models based on the Unified Modeling Language (UML) to the comprehensibility of Java source-code deprived of comments. We have conducted 12 controlled experiments in different experimental contexts and on different sites with participants with different levels of expertise (i.e., Bachelor’s, Master’s, and PhD students and software practitioners from Italy and Spain). A total of 333 observations were obtained from these experiments. The UML models in our experiments were those produced in the analysis and design phases. The models produced in the analysis phase were created with the objective of abstracting the environment in which the software will work (i.e., the problem domain), while those produced in the design phase were created with the goal of abstracting implementation aspects of the software (i.e., the solution application domain). Source-code comprehensibility was assessed with regard to correctness of understanding, time taken to accomplish the comprehension tasks, and efficiency as regards accomplishing those tasks. In order to study the global effect of UML models on source-code comprehensibility, we aggregated results from the individual experiments using a meta-analysis. We made every effort to account for the heterogeneity of our experiments when aggregating the results obtained from them. The overall results suggest that the use of UML models affects the comprehensibility of source-code, when it is deprived of comments. Indeed, models produced in the analysis phase might reduce source-code comprehensibility, while increasing the time taken to complete comprehension tasks. That is, browsing source code and this kind of models together negatively impacts on the time taken to complete comprehension tasks without having a positive effect on the comprehensibility of source code. One plausible justification for this is that the UML models produced in the analysis phase focus on the problem domain. That is, models produced in the analysis phase say nothing about source code and there should be no expectation that they would, in any way, be beneficial to comprehensibility. On the other hand, UML models produced in the design phase improve source-code comprehensibility. One possible justification for this result is that models produced in the design phase are more focused on implementation details. Therefore, although the participants had more material to read and browse, this additional effort was paid back in the form of an improved comprehension of source code.