The Decision View's Role in Software Architecture Practice

Abstract

A "decision view" provides a useful addition and complement to more traditional sets of architectural views and viewpoints; it gives an explanatory perspective that illuminates the reasoning process itself and not solely its results. This decision view documents aspects of the architecture that are hard to reverse-engineer from the software itself and that are often left tacit. The decision view and the decisions that it captures embody high-level architectural knowledge that can be transferred to other practitioners, merged when systems are merged, and offer useful support for the maintenance of large and long-lived software-intensive systems. This article leads the reader through a succession of epiphanies: from design to architecture, then architecture representation to architecture design methods, and finally to architectural design decisions.

The strengths and weaknesses of software architecture design in the RUP, MSF, MBASE and RUP-SOA methodologies: A conceptual review

“…Essentially a Software Architecture conveys relevant system's information on its components, interrelationships and expected fundamental properties [1][2][3][4][5]. Components and interrelationships are fundamental design pieces in any Software Architecture [1][2][3][4][5].…”

“…In the context of modern software engineering, Software Architecture (SA) artifacts are considered firstclass artifacts [1][2][3][4][5]. A first-class artifact implies that such an element is a highly important factor and should be considered mandatory to be elaborated in a high-quality system development methodology, and that its omission or partial elaboration can lead to a flawed software design and lately to a wrong software product [3].…”

Industrial Implementation of a Documentation Framework for Architectural Decisions

“…The perspective of looking at software architecture as a set of architecture decisions is widely recognized [1], [2]. However, architecture decisions are often not explicitly documented in practice but reside in the architect's mind as tacit knowledge and are only implicit in the models that the architect creates [2], [3]; even though explicit capturing and documentation of architecture decisions has been associated with a multitude of benefits, such as avoiding knowledge vaporization, supporting change impact estimation, increasing system understanding, improving knowledge sharing, and facilitating architecture evaluation [2], [3], [4].…”

“…However, architecture decisions are often not explicitly documented in practice but reside in the architect's mind as tacit knowledge and are only implicit in the models that the architect creates [2], [3]; even though explicit capturing and documentation of architecture decisions has been associated with a multitude of benefits, such as avoiding knowledge vaporization, supporting change impact estimation, increasing system understanding, improving knowledge sharing, and facilitating architecture evaluation [2], [3], [4]. This gap between industry practice and the benefits demonstrated by research persists, although researchers have proposed many approaches to incorporate the documentation of architecture decisions in architecture practice [5].…”

On the Composition and Reuse of Viewpoints across Architecture Frameworks

“…A survey we recently conducted on the industrial needs from architectural languages [4] revealed that 85% of the 48 interviewed practitioners use multiple views when architecting a software system, with a total of nine different views and a predominant use of structural, behavioral, and physical views reported. One consequence of the tenet of using multiple views is a growing body of viewpoints that have become available (such as [1], [5], [6]) and supported by Architecture Description Languages (ADLs). A second consequence is the rise of architecture frameworks as coordinated sets of viewpoints.…”