Software Architecture as a Set of Architectural Design Decisions PDF

Software Architecture as a Set of Architectural Design Decisions Anton Jansen Jan Bosch Department of Computing Science Software & Application Technologies Lab University of G...

Software Architecture as a Set of Architectural Design Decisions Anton Jansen Jan Bosch Department of Computing Science Software & Application Technologies Lab University of Groningen Nokia Research Center PO BOX 800, 9700 AV, The Netherlands PO BOX 407, FI-00045, Finland [email protected] [email protected] Abstract this notion of architectural design decisions, although ar- chitectural design decisions play a crucial role in software Software architectures have high costs for change, are architecture, e.g. during design, development, evolution, complex, and erode during evolution. We believe these reuse and integration of software architectures. In design, problems are partially due to knowledge vaporization. Cur- the main concern is which design decision to make. In de- rently, almost all the knowledge and information about the velopment, it is important to know which and why certain design decisions the architecture is based on are implicitly design decisions have been taken. Architecture evolution embedded in the architecture, but lack a first-class repre- is about making new design decisions or removing obso- sentation. Consequently, knowledge about these design de- lete ones to satisfy changing requirements. The challenge cisions disappears into the architecture, which leads to the is to do this in harmony with the existing design decisions. aforementioned problems. In this paper, a new perspective Reuse of software architecture is the use of earlier tried and on software architecture is presented, which views software tested combinations of design decisions (e.g. design pat- architecture as a composition of a set of explicit design de- terns or components). In the integration of systems, the cisions. This perspective makes architectural design deci- main concern is the unification of the design decisions and sions an explicit part of a software architecture. Conse- their assumptions. quently, knowledge vaporization is reduced, thereby allevi- ating some of the fundamental problems of software archi- To address this, we propose a new perspective on soft- tecture. ware architecture: we define software architecture as the composition of a set of architectural design decisions. This reduces the knowledge vaporization of design decision in- formation, since design decisions have become an explicit 1 Introduction part of the architecture. Software architecture has become a generally ac- The contribution of this paper threefold. First, the prob- cepted concept in research and industry. The importance of lems with the current perspective on software architecture stressing the components and their connectors of a software are presented. Second, it develops the notion of software system is generally recognized and has led to better control architecture as the composition of a set of explicit architec- over the design, development, and evolution of large and tural design decisions. Third, various views are presented increasingly dynamic software systems. for visualizing this new architecture perspective. Although the achievements of software architecture are formidable, still some problems remain. The complexity, The remainder of this paper is organized as follows. The high costs of change, and design erosion are some of the concept of architectural design decisions is presented in sec- fundamental problems of software architecture. We believe tion 2. In section 3, the problems of software architecture these problems are partially due to knowledge vaporization. with respect to architectural design decisions are explained Currently, almost all the knowledge and information regard- in more depth. The next section introduces Archium, our ing the design decisions on which the architecture is based approach to describe software architecture as a set of ar- on (e.g. results of domain analysis, architectural styles used, chitectural design decisions. The approach is applied to a trade-offs made etc.) are implicitly embedded in the archi- case and illustrated with various views on design decisions tecture, but lack a first class representation. in section 6. After this, related work is discussed. The paper The current perspective on software architecture lacks concludes with future work and conclusions in section 8. 1 2 Architectural design decisions Design decisions are cross cutting and intertwined: Design decisions are often intertwined with each Although the term “architectural design decision” is of- other, as they work in close relationship together. ten used [7, 10, 4], a precise definition is hard to find. There- Furthermore, they typically affect multiple parts of the fore, we define an architectural design decision as: design simultaneously. This leads to the situation that the design decision information is fragmented across A description of the set of architectural additions, subtrac- various parts of the design, making it hard to find and tions and modifications to the software architecture, the ra- change the decisions. Both effects increase the overall tionale, and the design rules, design constraints and addi- complexity of the software architecture, as numerous tional requirements that (partially) realize one or more re- seemingly unrelated relationships (e.g. dependencies) quirements on a given architecture. between architectural entities are introduced. With the definition of architectural design decisions using Design rules and constraints are violated: During the following elements: the evolution of the system, designers can easily violate design rules and constraints arising from previously Rationale The reasons behind an architectural design deci- taken design decisions. Violations of these rules sion are the rationale of an architectural design decision. It and constraints lead to architectural drift and its describes why a change is made to the software architecture. associated problems (e.g. increased maintenance costs). Design rules and design constraints are prescriptions for As design rules and constraints influence future design further design decisions. Rules are mandatory guidelines, decisions, they have a steering influence on the future whereas constraints limit the design to remain sound. direction of the architecture. Design constraints Design constraints describe the oppo- Obsolete design decisions are not removed: When site side of design rules. They describe what is not allowed obsolete design decisions are not removed, the system in the future of the design, i.e. they prohibit certain behav- has the tendency to erode more rapidly. In the current iors. design practice removing design decisions is avoided, Additional requirements A design decision may result in because of the effort needed, and the unexpected effects additional requirements to be satisfied by the architecture. this removing can have on the system. These new requirements need to be addressed by additional design decisions. As a result of these problems, the developed systems have a high cost of change, and they tend to erode quickly. Also, An architectural design decision is therefore the outcome the reusability of the architectural artifacts is limited if de- of a design process during the initial construction or the sign decision knowledge vaporizes into the design. These evolution of a software system. Architectural design deci- problems are caused by the focus in the software archi- sions, among others, may be concerned with the application tecture design process on the resulting artifacts, instead of domain of the system, the architectural styles and patterns the decisions that lead to them. Although the effects of used in the system, COTS components and other infrastruc- the made decisions are present in the design, the decisions ture selections as well as other aspects needed to satisfy the themselves are not visible. Clearly, design decisions cur- system requirements. rently lack a representation in software architecture designs. We propose to view a software architecture as a set of Defining software architecture as a set of architectural explicit architectural design decisions. In this perspective, design decisions is a step forward in solving the aforemen- the software architecture is the result of the architectural tioned problems. This would also help the architect with: design decisions made over time. Guarding the conceptual integrity of the software ar- chitecture. The design decisions describe the rules and 3 Problems of software architecture constraints, which should be obeyed. In current prac- tice, software engineers and architects often break un- The current perspective on software architecture lacks a awarely the conceptual integrity of the architecture. Ex- clear view on why the architecture looks as it does [6, 14]. plicit design decisions help in creating the necessary In the current notion of a software architecture, the results awareness and reference points for these constraints and of the design decisions underlying the architecture are im- rules. plicitly embedded within the architecture. Consequently, Explicit design space exploration helps the architect knowledge about the design decisions underlying the archi- in preventing from making obvious mistakes. It forces tecture is lost. This vaporization of design decision the architect to self reflect upon the software architec- information leads to a number of problems associated with ture. Furthermore, it enables communication of the ex- software architecture: plored design space with others.  Analysis of both the software architecture and the de- Solutions Architectural design decision sign process. For example, in evolution the architect wants to play “what if” scenario’s of considered design Solution 1 Motivation decisions in the context of existing ones. Motivates Improved traceability of the design decisions and Solve Problem Cause Cause their relationship to features, design aspects, concerns, and among themselves. This helps the architect with Architectural obtaining a better understanding of the software archi- Selects Decision Results in Modification tecture. Makes Solution X Trade-off However, the following requirements need to be satisfied to Modifies realize this: In context First class architectural design decisions are required to Context describe a software architecture as a set of design decisions. Architectural Requirements design Furthermore, first class design decisions can be communi- decisions cated, related and reasoned about. This provides informa- tion about the architecture, which is currently often missed. Figure 1. Model for architectural design deci- Explicit architectural changes form the bridge between sions the first class architectural entities and the architectural de- sign decisions. This is needed to have a well-defined rela- tionship between the proposed solutions of an architectural decision and the involved architectural entities. This is mainly due to the ill-defined relationship between Support for modification, subtraction, and addition these design decision models and software architectures. changes are required to have sufficient expressiveness. The Therefore, we have developed an approach called Archium, characteristic types of change often distinguished are the which tries to define this relationship. Archium maintains corrective, perfective, and adaptive types. However, the this relationship during the complete life-cycle of the sys- focus of this classification is on the reasons behind the tem. In this paper the focus is on the software architecture change, not on the effect of the changes. aspects of Archium. The approach is based on a concep- Clear, bilateral relationship between architecture and tual architectural design decision model, which describes realization Viewing a software architecture as a set of de- the elements of architectural design decisions and their rela- sign decisions, makes evolution an inherent part of the de- tionships in greater detail than the abstract design decision scription of an architecture. Changes in the architecture models. In the remainder of this section, this conceptual will have an effect on the realization of the system and vice model is presented. versa. It is therefore important to have a bilateral relation- ship between the software architecture and the realization. 4.1 Architectural design decision model First class architectural concepts As software architec- Figure 1 presents our conceptual model for architectural ture deals with abstractions, it is important to define these design decisions. At the heart of the model is the Problem abstractions in a first class way. Abstraction choices are element, which together with the Motivation and Cause ele- very subjective and greatly influences the resulting architec- ments describes the problem, a Motivation why the problem ture. Expressing these abstractions in a consistent and uni- is a problem, and the Causes of this problem. The Problem form way is therefore essential for software architectures. is the goal the architectural design decision wants to solve. The solutions element contains the Solutions that have been proposed to solve the problem at hand. A Decision is made, 4 Archium which solution should be used, resulting in an Architectural modification changing the Context. The aforementioned problems of section 3 clearly show To solve the described Problem, one or more potential that the notion of an architectural design decision is an im- Solutions can be thought up and proposed. For each of portant one. Currently, no models for representing architec- the proposed solutions, we define the following elements tural design decisions exist. Some general design deci- (which are not shown in the figure 1) : sion models do facilitate the description of abstract el- ements of an architectural design decision model, but these Description The description element described the so- approaches fail to satisfy most of our requirements. lution being proposed. The needed modifications are  explained and rationale for these modifications is pro- Composition Model Composition Composition Design Fragment Technique Configuration Composition vided. Design rules A potential solution can have one or more Architectural Model composes Design decision model composes connects design rules. Design rules define partial specifications composes to which the realization of one or more architectural en- Connector Port Component Entity Design Fragment tities has to conform. This allows a solution to define incorporates based on parts of how it should be realized in order to have a so- Abstract Interface Delta Design Decision lution that solves the problem. Connector Design constraints Besides design rules, a solution can have design constraints. Design constraints define limitations or constraints on the further design of one or Figure 2. Meta-model of a software architec- more architectural entities. These limitations and con- ture with first class design decisions straints have to be obeyed for the potential solution to solve the problem at hand. Consequences The consequences element is a descrip- tion of the expected consequences of the solution on the consists of three sub-models: an architectural model, a de- architecture. The element should provide additional ra- sign decision model, and a composition model. The ar- tionale behind the pros and cons of the solution. chitectural model defines software architecture concepts, Pros This model element describes the expected ben- which are similar to the concepts used in existing archi- efit(s) from this solution to the overall design and the tecture models. The design decision model contains impact on the requirements. design decisions as a first class concept. The composition Cons Solutions can also have a downside. The ex- model introduces the model elements needed to unite the pected negative impact on the overall design is as im- two previous sub-models. Each sub-model is explained in portant as the positive side. more detail in the remaining part of this section. A (trivial) running example of a subsystem of a measure- Translating the conceptual model into concrete model(s) ment system exemplifies the different concepts. The mea- is a big challenge. Our earlier investigation revealed surement system acquires certain properties of a physical a gap between design decisions and software architecture item that enters the system for measurement. The architec- models. Therefore, the rest of this paper focuses on the in- ture of this system is visualized in the top of figure 4. teraction between architectural design decisions and soft- ware architecture. Specifically, we discuss how the de- cision, solution, architectural modification, software ar- 5.1 Architectural Model chitecture, and architectural design decisions conceptual model elements are modeled and formalized to describe a The architectural model of Archium meta-model uses software architecture as a set of design decisions. concepts of the Component & Connector view. The re- lationships of these concepts is visualized in figure 2. Fol- 5 Archium meta-model lowing is a more in-depth description of these concepts and their relationships: In Archium, the functionality of the architectural modifi- Component Entity is an abstraction of a component. A cation is expressed as a change in functionality. New func- component entity describes the decomposition aspect of a tionality is regarded as the change of nothing to something. component. The functionality of a component entity is not In this perspective, Archium is fundamentally different than defined in the component entity itself, but in the deltas re- most other design methods, as it does not promote design lated to the component entity. A component in Archium is for or with change, but rather designing using change. a specific instance of a component entity with known func- A software architecture in Archium is described as a set tionality, i.e. the deltas incorporated in the component entity of changes, which together form the software architecture. instance are known. To be more precise, in Archium a so f tware archictecture = dd1 + dd2 +... + ddn, where ddx is a design decision. The For example, in the measurement system (see top of figure exact elements required to achieve this are described in the 4) a decomposition has been made in two parts, which are rest of this section. made up of the Measurement Item and the Sensor compo- The Archium approach is based on a meta-model, which nent entities. The Measurement Item component entity rep- describes the central concepts of our approach and their re- resents the object to be measured and the Sensor measures lationships. Figure 2 presents this meta-model. The model some properties of the measured object. Delta is the first-class representation of a change to the Key behavior of a component entity, which is provided by the Component deltas already incorporated in the component entity. A com- Tradeoff ponent entity incorporating a delta includes the modifica- Delta tion of the delta to its behavior. The merging of the behav- Chooses ior of different deltas is performed using the elements of the Required port composition model (see section 5.3). Provided port In the example, the functionality of the Measurement Item Connector and Sensor components are defined in the SensorDelta and Rationale MIDelta deltas. The SensorDelta contains the functionality to measure an item and the MIDelta has the functionality to Realization Realization Realization Realization store these measurements. These changes are not visible in figure 4, as they are being incorporated into the components. Interface A definition of a collection of method signatures, Observable Logger representing a specific named semantic. Port An external visible interface required or provided by a delta or connector. A port represents the provided or re- quired “service” of a delta or connector. Deltas and connec- Observable History UI tors are only allowed to communicate with others through their defined ports. Ports of a delta and connector can be connected together, to form a connection, thereby creating Figure 3. Example of a design decision a specific configuration of deltas and connectors. In the measurement system (see figure 4), two ports are de- fined: a provided port for the Sensor and a required port tural design decisions and the architectural concepts is de- for the Measurement Item. Both ports are not defined in the fined using the concept of a design fragment. Following is component entities, but are part of the deltas incorporated a more in-depth description of both concepts: in the components. Connector defines the “glue” between one or more deltas, Design Fragment is an architectural fragment defining a i.e. a connector is a first class representation of the interac- collection of architectural entities. An architectural entity tion or communication between these deltas. The ports of a can be part of multiple design fragments. A design fragment connector can be bound to the provided and required ports is a boundary-less container for maintaining trace-ability. of deltas, thereby forming the “glue” between them. A con- The primary use is to define the scope of a solution of a de- nector therefore defines the specific functionality used for sign decision. For example, a design fragment can contain the communication between connected ports. deltas and their configuration of (abstract) connectors, com- In the example, the communication between the Sensor and ponent entities incorporating certain deltas, and other de- the Measurement Item is defined in the connector CMISen- sign fragments, which describe a particular solution. A de- sor. sign fragment is therefore a (partial) description of the sys- Abstract Connector is an abstraction from a Connector, tem, which can include explicit change (modeled as deltas) as it does not have an interface associated with it. It defines and structure, i.e. component entities and (abstract) connec- the communication type (i.e. synchronous, asynchronous) tors. between two or more deltas. In addition, it defines a set of In Archium, the concept of a software architecture and a de- connectors that actually communicate between these deltas. sign pattern are specializations of the design fragment con- The abstract connector used in our example defines that the cept. The first class concept of a design fragment makes SensorDelta and MIDelta communicate using method in- these two concepts elements in the Archium model. A soft- vocation with each other. In addition, the abstract connec- ware architecture is a design fragment describing the system tor contains the connector CMISensor connecting the two as a whole. This description consists of the component enti- deltas. ties and (abstract) connectors and their configuration, which is a specialized subset of the architectural entities a design 5.2 Design Decision Model fragment can contain. For example, the architecture of the measurement system In this subsection, the design decision model part of itself is a design fragment. Figure 4 visualizes this, with Archium is presented. The relationship between architec- the architectural entities (Measurement Item, CMISensor, Sensor) being enclosed within the SensorFragment. Key LoggerFragment Design patterns are often seen as predefined design deci- Observable sions, which is not completely true. They define predefined Role CObsLog Logger Component «» «» parts of design solutions, which can be reused. However, design patterns still need to be instantiated and configured SensorFragment Delta in a design decision to be of use in a specific architecture. «» «» Measurement CMISensor Sensor Design Decision is a first class concept in Archium. It de- Item fines the solutions considered and the one decided upon (i.e. Design Fragment the decision) to solve a described problem (see figure 3). A software architecture (i.e. a design fragment) describes the Design context in which this design decision is made. The con- Fragment Composition sidered potential solutions consists of one or more design DesignFragmentComposition1 fragments, which act upon this context design fragment by Observable Role changing it according to the selected solution. Measurement Required Port CMISensor Sensor Item Figure 3 presents an example of a design decision. It con- «» «» Provided Port sists of the rationale described in section 4.1, a decision el- CObsLog Logger ement, and one or more solution elements. Each solution Connector contains its own rationale and a realization part. The real- ization is a design fragment, which is mapped onto a design fragment representing the architecture. The mapping is ex- plained in more detail in the next subsection. ResultFragment A design decision is regarded a change function within CMISensor Sensor Archium. It has optional parameters, which are the de- Measurement sign fragment describing the context the design decision Item changes. Applying a design decision on this context design CObsLog Logger fragment results in a new design fragment, which includes the design decision it originate from. This explains the mu- tual relationship between a design fragment and design de- Figure 4. Example of the composition of two cision in the Archium meta-model (figure 2). design fragments An example of the application of a design decision is pro- vided in figure 4. In this case, the measurement system needs to be changed to allow monitoring of the activities within the system. The design decision is made to change of composition techniques include: Inheritance, Delegation, the SensorFragment to include a logger. This design deci- Replacement, and Adapter (adapt a port interface). sion is presented in figure 3. The logger logs the actions of the Measurement Item on the Sensor. This modification For example, in figure 4 a composition technique is used is defined in the LoggerFragment, which is another design to describe how the provided port of the ObservableDelta fragment. The composition of the design fragments, as a reacts on the activities on the required port of Measuremen- means to change the measurement system, is described in tItem. the next subsection. Composition Configuration specifies how a component entity incorporates a certain delta. The composition config- 5.3 Composition Model uration uses composition techniques to specify the change on a per port basis. In this sense, the composition configu- The composition model is responsible for relating the ration is nothing more than a set of composition techniques changes of the design decision model to the elements of the to describe the way in which a delta changes a component architectural model. It defines the way in which a delta in- entity. teracts with other composed deltas. In Archium, the follow- Design Fragment Composition is used to define how a ing first class citizens are concerned with describing this: design fragment can change another design fragment. It uses composition configurations and design fragments to re- Composition Technique describes the way in which a late architectural entities of one design fragment to another, delta changes a port of a component entity. For example, it thereby creating a new changed design fragment. can define that a delta introduces a new port to the compo- nent entity, subtracts, or modifies an existing one. Examples For the example of figure 4, the design fragment composi- tion composes the LoggerFragment and SensorFragment. Platform It uses a composition configuration to relate the Observ- Web Distribution ableDelta with the MeasurementItem. General server architecture style CORBA realization 6 Athena case Servlet Engine Arbiter The previous section introduced the Archium meta- Platform model and illustrated parts of in on a trivial example. In Python ORB Domain this section, we validate our approach by applying it on a Object/ Managers case. First, the case is introduced, after which two design decisions are presented in more detail. Database Database abstraction Key Refines 6.1 Introduction Fraud Depends on Fraud Athena is a submit system for (automatic) judging, re- Integration Design Decision viewing, manipulation, and archiving of computer program sources. The primary use is supporting students to learn programming. To develop the programming skills of a stu- Figure 5. Design decisions of Athena dent, he or she has to practice a lot. Small programming ex- ercises are often used for this end. However, providing feed- back on these exercises is laborious and time-consuming. Athena helps students (and teachers) by testing their solu- straints hinder a more elaborate description. Based on the tions to functional correctness and provides feedback (e.g. different elements of Archium’s design decision model (see test results, test inputs, compilation information etc.) on section 4.1) the Fraud and Fraud Integration design deci- this. sion are described. Both design decisions are made after The architecture of Athena (called “Original design”) is the initial deployment of the system. They are described as illustrated on the top of figure 6. Athena uses a three tier follows: architectural style consisting of the Database, Middleware, and Client component. The Middleware component con- Fraud design decision sists of a Connection Broker, which provides database ab- Problem Some of the students don’t create solutions for the straction and connection handling. The Domain Object rep- exercises themselves, but rather copy the work of their fel- resents the different specific domain objects used in Athena low students. Motivation A result of this is that the students (e.g. Student, Submission, Assignment etc.). The Manager don’t obtain an adequate programming experience, which provides query and instantiation services for the Client and is required for more advanced courses. Cause The large Domain Object components. In the Client component, stu- number of students (100+) in courses where Athena is used dents submit their work with the help of the Submission leads to anonymity and a small chance to get caught. On top Client. The Arbiter tests this work and students can view of this, the high pressure resulting from the strict deadlines the results with the Student Web Interface. Teachers and imposed by the system increases the temptation to commit their assistants configure Athena with the help of the Man- fraud. Context The original design of the Athena system, agement Tool. as depicted on the top of figure 6. Potential solutions 6.2 Design decisions Moss Description Moss is an anti-fraud system, which The software architecture of Athena is the result of mul- employs various code finger printing techniques to tiple design decisions. Figure 5 presents a part of these de- detect plagiarism. The Moss system uses a client- sign decisions in a design decision dependency view. An ar- server architecture. The client consists of perl script, chitect would like to navigate between this view and other which communicates with the Moss Internet server over views on the architecture. The view allows for the man- TCP/IP. The client provides the user with an URL point- agement of the dependencies among design decisions. For ing to the results of the analysis. example, “what if” scenario’s can be played, where the im- Design rules For each assignment it should be clear pact of potential design decisions is examined. whether it should be scanned for fraud or not. The focus in the remainder of this section is on one Design constraints Moss works in a batch oriented dependency between two design decisions, as space con- way, all the data to be tested for fraud should be de-  Original Design livered at once and increments are not possible. Database Middleware Client Consequences The Athena middleware becomes de- Manager Arbiter pendent on the Moss server. Connection Management Tool Pros +Good confident fraud detection. +Can ignore Broker Student Web base frameworks provided to students +Support multi- Domain Object Interface ple programming languages +Free in use Submission Client Cons -Integration and archiving of the analysis results can be difficult. JPlag Moss Solution Description JPlag is a plagiarism detection sys- Moss tem similar to Moss. JPlag parses the submitted files Fraud and searches for similarities in their parse trees. The JPlag Solution JPlag architecture uses a client-server architecture. The JPlag Java client sends the files for scanning to the server. The results of the analysis can be viewed through a web in- Original Design + Fraud terface. Moss Design rules For each assignment it should be clear Database Middleware Client whether it should be scanned for fraud or not. Manager Arbiter Design constraints JPlag works in a batch oriented Management way, all the data to be tested for fraud should be de- Connection Broker Tool livered at once and increments are not possible. Domain Student Web Interface Consequences The Athena middleware becomes de- Object Submission pendent on the JPlag server. Client Pros +Free in use Cons -Supports a relative small number of program- Notification Solution ming languages -No demo available Submission Connection Fraud Reporting Fraud Configuration Broker >Student Web Interface Notification >Domain Object >Management Tool Decision The Moss solution is chosen, as it supports more Fraud programming languages and can ignore base frameworks Fraud Report >Domain Object Scanner >Middleware Moss provided to the students. Architectural modification The architectural modification of this design decision is depicted User-requested Solution in figure 6. Moss Fraud Integration Submission Manager >Manager Fraud integration design decision Fraud Scanner Fraud Management Problem The Moss Internet server should be integrated >Middleware >Management Tool with the Athena system. Motivation The Athena users should use the anti-fraud functionality in a transparent way. Original Design + Fraud + Fraud Integration Cause The need for a fraud system, as described in Fraud Database Middleware Client design decision. Context The design of the Athena system, Manager Arbiter as depicted in figure 6 under the title “Original Design + Connection Management Tool Fraud”. Broker Student Web Potential solutions Interface Domain Object Notification Submission Fraud Client Description The Fraud Scanner with the help of the Scanner Fraud Configuration and the Moss server keeps the Fraud Report for an assignment up-to-date. The Fraud Moss Reporting uses the Fraud Report to inform the users. Design rules The Domain Object responsible for the Key processing of the student submissions should notify the Required Port Design Alternative Design Fraud Scanner, when a new submission for an assign- Component Connector Delta Provided Port Fragment Chosen Decision ment is made. Design constraints The availability of the Moss server Figure 6. Two design decisions of Athena may not interfere with the submission process. Consequences Every submission by a student leads to  a new Fraud Report. Remark that the description of the design decisions itself Pros +The data for Fraud Reporting is instantly avail- was sufficient to describe the software architecture evolu- able +Allows for immediate feedback on the detection tion and its reasons. For example, the Archium model con- of fraud tains all the information needed to explain why the Fraud Cons -Heavy load induced on the Moss server Scanner component is part of the system. Usually with User-requested the term “architecture”, the latest incarnation of a design Description The user initiates a fraud analysis. The is meant. In this case this would be the architecture illus- Fraud Scanner delivers the analysis using the Moss trated on the bottom of figure 6. However, as showed, this server. architecture is the result of a number of design decisions. Design rules The Submission Manager should provide the student submissions for a fraud analysis for the 7 Related work Fraud Scanner. Design constraints Fraud analysis should be only per- Archium employs concepts from the field of software ar- formed, when a user requests for this information in the chitecture. Important concepts in this field are com- Management Tool. ponents and connectors, which are believed to lead to bet- Consequences The result of the fraud analysis is not ter control over the design, development and evolution of stored in the Athena system, but by Moss. large and increasingly dynamic software architectures. Pros +Relatively easy to develop +Light load induced Software architecture documentation approaches [7, 10] try on the Moss server to provide guidelines for the documentation of software ar- Cons -Automatic fraud feedback to students is not chitectures. However, guidelines for design decisions are available. absent in these approaches, whereas Archium does provide them. Decision The decision is made to use the Notification solu- Architectural Description Languages (ADLs) de- tion, which provides a more active feedback from the sys- scribe software architectures in a formal language, which tem to the users. Architectural modification The architec- support first class architectural concepts. Whereas ADLs tural modification is presented in figure 6. try to describe an architecture, Mae and Archium try to describe the evolution leading to an architecture. Mae Figure 6 presents a view on these two design decisions, is an architectural change management tool, which tracks which visualizes part of the history of the Athena architec- changes to an architecture definition by a revision manage- ture with the help of design decisions. The top displays the ment system. However, it lacks the notion of a design deci- architecture on which the Fraud design decision is based. sion and delta. Therefore, it can only track arbitrary changes The realization and choice part of the Fraud design decision and not the dependencies between design decisions the ar- is shown together with the “resulting” architecture below chitect is interested in. them. The same is done for the Fraud Integration design Component languages like ArchJava and Koala decision. are programming languages supporting some architectural Note that in the view of design decision (figure 6) the concepts first-class to various degrees. Archium shares mapping of the change elements onto the architecture is vi- some the concepts of these component languages, but dif- sualized in the change element themselves. For example, fers as design decisions and architectural change are first- in the Notification of the Fraud Integration design decision class citizens. the Submission Notification delta is mapped onto the Do- AOP with its implementations like AspectJ and main Object. This mapping is defined with the help of the genVoca are approaches using different techniques to composition model (see section 5.3). However, the visual- achieve multiple separation of concerns. Traditional use of ization of this mapping is not visible in this view. Instead, AOP focuses on the code level, on the other hand Archium when the mapping is not clear from the delta name, the > focusses on the cross-cutting concerns of design decisions symbol followed by the target of the delta is used to clarify at the architectural level. the mapping. A design pattern is a special type of design decision. De- From both design decisions emerge a number of addi- sign patterns are sets of predefined design decisions with tional requirements. For example, in the Fraud design de- known functionality and behavior. The rationale of these cision an Internet connection to the Moss server is now re- decisions, as documented in the description of a design pat- quired for the Athena system to function completely. The tern, can be related to the realization. Archium differs same happens with the Fraud integration design decision, from as it keeps design patterns first class in the realiza- where requirements are needed about the expected feedback tion. of the fraud system. Knowledge systems like IBIS model decision processes and try to capture the rationale or knowledge used 9th European software engineering conference, pages 48– in these processes. Design decision models are a spe- 57. ACM Press, 2003. cial type of knowledge system, as they try to capture ratio- J. Bosch. Software architecture: The next step. In Soft- nale of design decisions. Archium expands these decision ware Architecture, First European Workshop (EWSA), vol- ume 3047 of LNCS, pages 194–199. Springer, May 2004. models, as it integrates the decision model with an architec- P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, tural model. R. Little, R. Nord, and J. Stafford. Documenting Software Architectures, Views and Beyond. Addison Wesley, 2002. 8 Conclusion J. Conklin and M. L. Begeman. gibis: a hypertext tool for exploratory policy discussion. ACM Transactions on Infor- mation Systems (TOIS), 6(4):303–331, 1988. Architectural design decisions play an important role in E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design the design, development, integration, evolution, and reuse Patterns - Elements of Reusable Object-Oriented Software. of software architectures. However, the notion of architec- Addison Wesley, 1994. tural design decisions is not part of the current perspective C. Hofmeister, R. Nord, and D. Soni. Applied software ar- on software architectures. We have identified several prob- chitecture. Addison Wesley, 2000. A. G. J. Jansen and J. Bosch. Evaluation of tool support for lems due to this, including high costs of change, design ero- architectural evolution. In Proceedings of the 19th IEEE In- sion, and limited reuse, which are primarily caused by the ternational Conference on Automated Software Engineering vaporization of these design decisions into the architecture. (ASE), pages 375–378. IEEE, September 2004. To address these problems, we propose a new perspec- G. Kiczales, E. Hilsdale, J. Hugunin, M. Kersten, J. Palm, tive on software architecture, where software architectures and W. G. Griswold. An overview of AspectJ. Lecture Notes are described as set of design decisions. The presented in Computer Science, 2072:327–355, 2001. Archium approach is centered around this idea. Archium G. Kiczales, J. Lamping, A. Menhdhekar, C. Maeda, models for the first time the relationship between software C. Lopes, J.-M. Loingtier, and J. Irwin. Aspect-oriented programming. In M. Akşit and S. Matsuoka, editors, Pro- architecture and design decisions in detail. It uses a concep- ceedings ECOOP, volume 1241, pages 220–242. Springer- tual model consisting of the notions of deltas, design frag- Verlag, 1997. ments, and design decisions to describe a software archi- P. Kruchten. An ontology of architectural design decisions tecture. The different concepts were exemplified with the in software intensive systems. In 2nd Groningen Workshop Athena case. on Software Variability, pages 54–61, December 2004. Ongoing and future work on Archium includes the devel- G. Malpohl. Jplag website. http://www.jplag.de/. opment of tool support (see ) facilitating experimentation N. Medvidovic and R. N. Taylor. A classification and comparison framework for software architecture description of the various concepts. In addition, we intend to add sup- languages. IEEE Transactions on Software Engineering, port for multiple views on the architecture as different views 26(1):70–93, 2000. show different concerns about the architecture [7, 10]. D. E. Perry and A. L. Wolf. Foundations for the study of This paper presented a first step in modeling the perspec- software architecture. ACM SIGSOFT Software Engineering tive of software architectures as a set of design decisions. Notes, 17(4):40–52, 1992. Many research challenges remain in this perspective. For W. Regli, X. Hu, M. Atwood, and W. Sun. A survey of de- example, how can we distinguish important design deci- sign rationale systems: Approaches, representation, capture sions? What are interesting relationships between design and retrieval. Engineering with Computers, 16(3-4):209– 235, December 2000. decisions? What are the crucial factors influencing a design S. Schleimer, D. S. Wilkerson, and A. Aiken. Winnow- decision? ing: local algorithms for document fingerprinting. In SIG- MOD ’03: Proceedings of the 2003 ACM SIGMOD inter- References national conference on Management of data, pages 76–85, New York, NY, USA, 2003. ACM Press. J. Tyree and A. Akerman. Architecture decisions: Demysti- J. Aldrich, C. Chambers, and D. Notkin. Archjava: connect- fying architecure. IEEE Software, 22(2):19–27, 2005. ing software architecture to implementation. In Proceedings A. van der Hoek, M. Mikic-Rakic, R. Roshandel, and of the 24th international conference on Software engineer- N. Medvidovic. Taming architectural evolution. In Proceed- ing, pages 187–197. ACM Press, 2002. ings of the 8th European software engineering conference Archium website,. http://www.archium.net. held jointly with 9th ACM SIGSOFT international sympo- E. L. A. Baniassad, G. C. Murphy, and C. Schwanninger. sium on Foundations of software engineering, pages 1–10. Design pattern rationale graphs: Linking design to source. ACM Press, 2001. In Proceedings of the 25th ICSE, pages 352–362, May 2003. R. van Ommering, F. van der Linden, J. Kramer, and L. Bass, P. Clements, and R. Kazman. Software architecture J. Magee. The koala component model for consumer elec- in practice 2nd ed. Addison Wesley, 2003. tronics software. IEEE Computer, 33(3):78–85, march D. Batory, J. Liu, and J. N. Sarvela. Refinements and multi- 2000. dimensional separation of concerns. In Proceedings of the