Using Non-Functional Requirementsto Systematically Select Among Alternativesin Architectural Design

Data Type ++ + weak positive satisficing strong positive satisficing very critical ! critical denied neutral undetermined satisficed ? Figure 5: Goal graph selecting among architectural alternatives for a KWIC system. The software architect also establishes new goals, such as Comprehensibility [System], which add to the number of goals. Goal Criticality. The software architect, on the one hand, has limited time; she has a number of goal con ict and synergy to deal with, on the other. In order to handle the situation, the architect prioritises goals, here into three categories: non-critical, critical, and very critical. This decision can be justi ed by way of design rationale. For example, treating modi ability, performance, and reusability as critical goals can be supported, via the vital few argumentation method, possibly with a market survey. With the prioritisation, the software architect can put emphasis on (very) critical goals, and readily resolve goal con ict. For example, as Modifiability [Data Rep] is considered very important, architectural design alternatives which strongly hurt the goal might be eliminated from further consideration, here Shared Data and Pipe & Filter. Evaluation and Selection. A particular architectural design can make a positive, negative, or no contribution to a goal. For example, the use of an abstract data type may help updatability, but at the cost of poorer time performance (Figure 5). Hence, selecting an architectural design requires careful examination of the degree of goal achievement, particularly for critical ones. Throughout the goal graph expansion process, the evaluation procedure propagates, via labels, the e ect of each design decision from o spring to parents. In assessing the degree of goal achievement, the evaluation procedure considers the type of link, and interacts with the software architect when uncertainties arise. Figure 5 shows a stage during software architectural design process, where one alternative is marked acceptable while the others are either denied or neutral. This kind of approach is made possible by earler goal reduction as application of \divide-and-conquer" paradigm. Disambiguation and re nement, via decomposition, have facilitated systematic codi cation of and search for NFR-related reusable knowledge, clearer understanding of tradeo s, and con ict resolution with design rationale which re ects the needs and characteristics of the intended application domain. Here, for example, the impact of using an abstract data type upon system modi ability is initially unclear, but re nement shows that ADTs support modi ability of data representation, which is critical, but hinder process modi ability. Throughout the process of architectural design, the software architect has been in control, posting NFR goals, browsing and choosing decomposition methods, design alternatives, and correlations, supporting or denying design decisions by way of design rationale, and observing goal assessment and selecting a particular architectural design. This process promotes communication, analysis, and comparison of architectural designs and principles. This process is used to support architectural design and results in a history record (with design rationale for both accepted and discarded alternatives considered), for later review, justi cation and evolution. 4 Related Work Our proposal draws on concepts, such as elements, components, and connectors, that have been identi ed as essential to portray architectural infrastructure, as advocated by Perry and Wolf [38], Garlan and Shaw [17], Abowd, Allen, and Garlan [1], Callahan [5], Mettala and Graham [28], and on earlier notions on information system architecture by Zachman [45]. In our view, our emphasis on NFRs is complementary to e orts directed towards identi cation and formalization of concepts for functional design. Concerning the role of NFRs, design rationale, and goal assessment, the proposal by Perry and Wolf [38] is of close relevance to our work. Perry and Wolf propose to use architectural style for constraining the architecture and coordinating cooperating software architects. They also propose that rationale, together with elements and form, constitute the model of software architecture. In our approach, weighted properties of the architectural form are justi ed with respect to their positive and negative contributions to the stated NFRs, and weighted relationships of the architectural form are abstracted into link types and labels, which can be interactively and semi-automatically determined. In our framework, we focus on the problem of systematically capturing and reusing knowledge about NFRs, design alternatives, tradeo s and rationale. Kazman, Bass, Abowd, and Webb [24] proposes a basis (called SAAM) for understanding and evaluating software architectures, and gives an illustration using modi ability. This proposal is similar to ours, in spirit, as both take a qualitative approach, instead of a metrics approach. In a similar vein but towards software reuse, Ning, Miriyala, and Kozaczynski [33] proposes an approach (called ABC), in which they suggest the use of NFRs to evaluate the architectural design, chosen from a reuse repository of domain-speci c software architectures, which closely meets very high-level requirements. Both SAAM and ABC are product-oriented, i.e., they use NFRs to understand and/or evaluate architectural products; ours, however, is process-oriented, i.e., it provides support for systematically dealing with NFRs during the process of architectural design. The NFR-Framework [7] [30] aims to improve software quality [9] [10] and has been tested on system types with a variety of NFRs, including accuracy, security and performance. Systems studied [13] include credit card [34, 8], public health insurance [7], government administration (Cabinet Documents [7] and Taxation Appeals [35]) and bank loan [12] information systems. The last study considered dealing with changes in requirements, including informativeness. The NFR-Framework also has an associated prototype tool: the NFR-Assistant [11] has been designed and implemented to deal with a variety of NFRs, primarily security, accuracy [7] [8], and (in progress) performance [35]. The NFR-Framework has been one of the subjects in a comparative study on several goal-oriented approaches by Finkelstein and Green [15] who use the meeting scheduler example as a basis of comparison. There are other uses of the NFR-Framework, including organization modelling by Yu [43, 44], and project risk management by Parmakson [36]. In our view, there are parallels to NFR-related work on information systems, and the current paper is one of the rst which considers adaptation of the NFR-Framework speci cally in the context of software architecture. 5 Conclusion This paper has proposed an approach to systematically guiding selection among architectural design alternatives, thus providing an alternative to an ad hoc approach. Our approach is intended to improve the software architect's ability to understand the high level system constraints and the rationale behind architectural choices, to reuse architectural knowledge concerning NFRs, to make the system more evolvable, and to analyse the design with respect to NFR-related concerns. More speci cally, our approach facilitates explicit representation of NFRs as (potentially) con icting or synergistic goals to be addressed during the process of architectural design, and use of such goals to rationalise the overall architectural design and selection process. Our approach also facilitates codi cation of knowledge about NFR-related architectural design and tradeo s, and systematic management and use of such knowledge. In order to help the software architect analyse design tradeo s, assess goal achievement, and select a particular architectural design, our approach o ers an interactive evaluation scheme in which design decisions are rationalised in terms of design rationale which re ects the needs and characteristics of the intended application domain. The underlying framework has already been applied to information systems. We have studied a number of such systems, considered NFRs which are relevant to them, and provided tool support. In the context of architectural design, however, our proposal is only preliminary, with its use illustrated only on a pedagogical example. Broader case studies are needed to gain experience and feedback, both bene ts and weaknesses, and to see whether our approach can be e ectively applied to industrial-strength domain-speci c software architectures, application-frameworks, and reference architectures. Our studies of NFRs in the context of information system development have helped us and domain experts evaluate the e ectiveness of the framework for such systems. Once a more codi ed catalogue of architectural methods is developed, it could be used in studies of using the framework to deal with architectural design. Along with feedback from industrial and academic experts, such studies would enhance the framework's coverage and evaluate its usefulness. A tool which embeds our approach is also needed to assist the software architect to systematically select among architectural design alternatives. Such a tool would incorporate knowledge about a variety of methods and correlations for a wide range of non-functional requirements. Our NFR-Assistant tool could serve as a starting point for such an architecture assistant tool. We have only illustrated the application of the NFR Framework to selecting among architectural design alternatives at a very abstract level. An important aspect of future work is to deal with more complex architectural problems, and to show the scalability of the framework. This of course requires codi cation of current and future knowledge about architectural alternatives and design criteria. The results, we trust, would be the provision of more satisfactory goal ass