Software Architecture as a Set of Architectural Design ...

1 Software Architecture as a Set of Architectural Design DecisionsAnton JansenDepartment of Computing ScienceUniversity of GroningenPO BOX 800, 9700 AV, The BoschSoftware & Application Technologies LabNokia Research CenterPO BOX 407, FI-00045, architectures have high costs for change, arecomplex, and erode during evolution. We believe theseproblems are partially due to knowledge vaporization. Cur-rently, almost all the knowledge and information about thedesign decisions the Architecture is based on are implicitlyembedded in the Architecture , but lack a first-class repre-sentation. Consequently, knowledge about these Design de-cisions disappears into the Architecture , which leads to theaforementioned problems. In this paper, a new perspectiveon Software Architecture is presented, which views softwarearchitecture as a composition of a set of explicit Design de-cisions. This perspective makes Architectural Design deci-sions an explicit part of a Software Architecture .

2 Conse-quently, knowledge vaporization is reduced, thereby allevi-ating some of the fundamental problems of Software IntroductionSoftware Architecture [17] has become a generally ac-cepted concept in research and industry. The importance ofstressing the components and their connectors of a softwaresystem is generally recognized and has led to better controlover the Design , development, and evolution of large andincreasingly dynamic Software systems [4].Although the achievements of Software Architecture areformidable, still some problems remain. The complexity,high costs of change, and Design erosion are some of thefundamental problems of Software Architecture . We believethese problems are partially due to knowledge , almost all the knowledge and information regard-ing the Design decisions on which the Architecture is basedon ( results of domain analysis, Architectural styles used,trade-offs made etc.) are implicitly embedded in the archi-tecture, but lack a first class current perspective on Software Architecture lacksthis notion of Architectural Design decisions, although ar-chitectural Design decisions play a crucial role in softwarearchitecture, during Design , development, evolution,reuse and integration of Software architectures.

3 In Design ,the main concern is which Design decision to make. In de-velopment, it is important to know which and why certaindesign decisions have been taken. Architecture evolutionis about making new Design decisions or removing obso-lete ones to satisfy changing requirements. The challengeis to do this in harmony with the existing Design of Software Architecture is the use of earlier tried andtested combinations of Design decisions ( Design pat-terns or components). In the integration of systems, themain concern is the unification of the Design decisions andtheir address this, we propose a new perspective on soft-ware Architecture : we define Software Architecture as thecomposition of a set of Architectural Design decisions. Thisreduces the knowledge vaporization of Design decision in-formation, since Design decisions have become an explicitpart of the contribution of this paper threefold. First, the prob-lems with the current perspective on Software architectureare presented.

4 Second, it develops the notion of softwarearchitecture as the composition of a set of explicit architec-tural Design decisions. Third, various views are presentedfor visualizing this new Architecture remainder of this paper is organized as follows. Theconcept of Architectural Design decisions is presented in sec-tion 2. In section 3, the problems of Software architecturewith respect to Architectural Design decisions are explainedin more depth. The next section introduces Archium, ourapproach to describe Software Architecture as a set of ar-chitectural Design decisions. The approach is applied to acase and illustrated with various views on Design decisionsin section 6. After this, related work is discussed. The paperconcludes with future work and conclusions in section Architectural Design decisionsAlthough the term Architectural Design decision is of-ten used [7, 10, 4], a precise definition is hard to find. There-fore, we define an Architectural Design decision as:A description of the set of Architectural additions, subtrac-tions and modifications to the Software Architecture , the ra-tionale, and the Design rules, Design constraints and addi-tional requirements that (partially) realize one or more re-quirements on a given the definition of Architectural Design decisions usingthe following elements:RationaleThe reasons behind an Architectural Design deci-sion are the rationale of an Architectural Design change is made to the Software rulesanddesign constraintsare prescriptions forfurther Design decisions.

5 Rules are mandatory guidelines,whereas constraints limit the Design to remain constraintsDesign constraints describe the oppo-site side of Design rules. They describe what is not allowedin the future of the Design , they prohibit certain requirementsA Design decision may result inadditional requirements to be satisfied by the new requirements need to be addressed by additionaldesign Architectural Design decision is therefore the outcomeof a Design process during the initial construction or theevolution of a Software system. Architectural Design deci-sions, among others, may be concerned with the applicationdomain of the system, the Architectural styles and patternsused in the system, COTS components and other infrastruc-ture selections as well as other aspects needed to satisfy thesystem propose to view a Software Architecture as a set ofexplicit Architectural Design decisions. In this perspective,the Software Architecture is theresultof the architecturaldesign decisions made over Problems of Software architectureThe current perspective on Software Architecture lacks aclear view on why the Architecture looks as it does [6, 14].

6 In the current notion of a Software Architecture , the resultsof the Design decisions underlying the Architecture are im-plicitly embedded within the Architecture . Consequently,knowledge about the Design decisions underlying the archi-tecture is lost [20]. This vaporization of Design decisioninformation leads to a number of problems associated withsoftware Architecture : Design decisions are cross cutting and intertwined: Design decisions are often intertwined with eachother, as they work in close relationship , they typically affect multiple parts of thedesign simultaneously. This leads to the situation thatthe Design decision information is fragmented acrossvarious parts of the Design , making it hard to find andchange the decisions. Both effects increase the overallcomplexity of the Software Architecture , as numerousseemingly unrelated relationships ( dependencies)between Architectural entities are introduced.

7 Design rules and constraints are violated:Duringthe evolution of the system, designers can easily violatedesign rules and constraints arising from previouslytaken Design of these rulesand constraints lead to Architectural drift [17] and itsassociated problems ( increased maintenance costs).As Design rules and constraints influence future designdecisions, they have a steering influence on the futuredirection of the Architecture . Obsolete Design decisions are not removed:Whenobsolete Design decisions are not removed, the systemhas the tendency to erode more rapidly. In the currentdesign practice removing Design decisions is avoided,because of the effort needed, and the unexpected effectsthis removing can have on the a result of these problems, the developed systems havea high cost of change, and they tend to erode quickly. Also,the reusability of the Architectural artifacts is limited if de-sign decision knowledge vaporizes into the Design .

8 Theseproblems are caused by the focus in the Software archi-tecture Design process on the resulting artifacts, insteadofthe decisions that lead to them. Although the effects ofthe made decisions are present in the Design , the decisionsthemselves are not visible. Clearly, Design decisions cur-rently lack a representation in Software Architecture Software Architecture as a set of architecturaldesign decisions is a step forward in solving the aforemen-tioned problems. This would also help the architect with: Guarding the conceptual integrityof the Software ar-chitecture. The Design decisions describe the rules andconstraints, which should be obeyed. In current prac-tice, Software engineers and architects often break un-awarely the conceptual integrity of the Architecture . Ex-plicit Design decisions help in creating the necessaryawareness and reference points for these constraints andrules. Explicit Design space explorationhelps the architectin preventing from making obvious mistakes.

9 It forcesthe architect to self reflect upon the Software architec-ture. Furthermore, it enables communication of the ex-plored Design space with others. Analysisof both the Software Architecture and the de-sign process. For example, in evolution the architectwants to play what if scenario s of considered designdecisions in the context of existing ones. Improved traceabilityof the Design decisions andtheir relationship to features, Design aspects, concerns,and among themselves. This helps the architect withobtaining a better understanding of the Software , the following requirements need to be satisfied torealize this:First class Architectural Design decisionsare required todescribe a Software Architecture as a set of Design , first class Design decisions can be communi-cated, related and reasoned about. This provides informa-tion about the Architecture , which is currently often Architectural changesform the bridge betweenthe first class Architectural entities and the Architectural de-sign decisions.

10 This is needed to have a well-defined rela-tionship between the proposed solutions of an architecturaldecision and the involved Architectural for modification, subtraction, and additionchanges are required to have sufficient expressiveness. Thecharacteristic types of change often distinguished are thecorrective, perfective, and adaptive types. However, thefocus of this classification is on the reasons behind thechange, not on the effect of the , bilateral relationship between Architecture andrealizationViewing a Software Architecture as a set of de-sign decisions, makes evolution an inherent part of the de-scription of an Architecture . Changes in the architecturewill have an effect on the realization of the system and viceversa. It is therefore important to have a bilateral relation-ship between the Software Architecture and the class Architectural conceptsAs Software architec-ture deals with abstractions, it is important to define theseabstractions in a first class way.