Designing software architectures to achieve quality attribute requirements F. Bachmann, L. Bass, M. Klein and C. Shelton IEE Proceedings Software Tzu-Chin Chien 1

Outline Preface This paper goal Prior work This paper approach Experiment Conclusion 2

Preface 3 1.Architecture is too abstract to understand. 2.Critical link between requirements engineering and design. 3.Architecture can grow, because software has become more and more complex.

About this paper The authors describe a structure called a reasoning framework as a modularization of quality attribute knowledge. 4 1.User interface friendly (understandability) 2.Change independently (operability) reasoning framework

Reasoning work Each reasoning framework provides mechanisms that will transform the architecture with respect to a given quality attribute theory. 5 Reasoning framework

Outline Preface This paper goal Prior work This paper approach Experiment Conclusion 6

Prior work There are three basic approaches to software architecture design with respect to quality attribute requirements. – 1. Nonfunctional requirement approach (NFR) – 2. The quality attribute model approach – 3. The intuitive design approach 7

1.Nonfunctional requirement approach (NFR) This idea is that the best one can be determined is that various architectural decisions help or hurt various quality attributes. 8 But there are two problems +

NFR’s problem 1.The architect must rely on intuition to determine which decisions to consider. 2.Whether a particular decision will help or hurt a particular quality attribute is very much a question of context. e.g. Using modularization too much would hurt performance, but it supports deployment onto multiple processors will help performance (not hurt it). 9

2.The quality attribute model approach ISO9126 lists 6 primary and 21 secondary quality attribute knowledge and practice. 10 But there are three problems

QAM’s problem 1.Not every quality attribute has an existing predictive method. 2.Not every architecture is amenable to analysis by various quality attribute models. (e.g. RMA:SJF preemptive) 3.Quality attribute models may not scale well. 11

3.The intuitive design approach 12 Architectural driver These methods are effective at organizing requirements but depend to a large extent on the architect to find solutions for the satisfaction of specific quality attribute requirements.

Attribute driven method 13 Architectural drivers Pattern Tactics Right? Remaining functionality Interface Verify Decompose Part Refine Finish Next part

Short summary 1.Nonfunctional requirements approach – Choose quality goal 2.Quality attribute model – Find relationship among the concept, but not scale well 3.Attribute driven model – Scale well 14

Outline Preface This paper goal Prior work This paper approach Experiment Conclusion 15

This paper approach A key concept in our design philosophy is describing an architecture partially in terms of responsibilities. Example: The checking of a password in support of an authentication requirement is a responsibility of the software. 16

This paper approach Combines three approaches (NFR,QAM, ADD) 17 NFR QAM ADD Choose the most important quality attribute goal Rational architectural decision Reduce problem of scale in using QAM Modularizing quality attribute It can be used inside a general design model.

Reasoning framework One of the inputs into a reasoning framework is a description of the current state of the architecture design. 18

This paper approach Steps – 1. find quality attribute requirements – 2. satisfy a quality attribute goal – 3. response measure – 4. architectural transformations (when the result in step3 missed) 19

Step1: Quality attribute requirements A general scenario is a system independent description of a quality attribute requirement. It has six parts: 1.Stimulus 2.Source of the stimulus 3.Environment 4.Artifact 5.Response 6.Response measure 20

Step2: Satisfying a quality attribute A single quality attribute requirement and describe the elements we use to determine whether it is satisfied by the current architecture design. 21

Step2 & Step3 Quality attribute model& Response measure 22

Step5: Architecture transformations (1) 23 Tactics is needed before Architecture transformations

Step4: Architecture transformations (2) 24 An architectural tactic can change the structure of an architecture 1. Out of response measure 2. Use tactic 3. Make sure

Outline Preface This paper goal Prior work This paper approach Experiment Conclusion 25

Sample problem The problem is 1.to receive automotive sensor information 2.to determine whether the sensors suggest either a problem with the environment being sensed or with the sensors themselves. 26

Figure 27 Problem’s data flow and their responsibility

Find quality attribute requirements 28

Satisfy a quality attribute goal (modifiability) 29

Response measure 30 Problem’s data flow and their responsibility *1 + 1* *0.8 * *1 + 2 * 0.2 > 3 day

Architecture transformations : Abstract common service 31

Figure 32

Change The costs of modifying the responsibilities ‘convert input into internal syntax’ and ‘determine sensor status’ are reduced since the common services have been removed from them. The new responsibility ‘receive input from sensor’ must be assigned a cost of modification. 33

Table 34

Response measure *1 + 1* *0.8 * *0.8 * 0.2 * * 0.5 < 3 day 1

Using ADD to scale There are three problems of scale associated with reasoning frameworks: 1.The number of codified reasoning frameworks is small. 2.Each reasoning framework should go deeper. 3.The solvers for any particular reasoning framework may not scale well with respect to the number of elements in the architecture. 36

Use of reasoning framework within ADD This paper modify 2b and 2c of ADD Original : Choose architectural patterns and tactics that satisfy the architecture drivers, and Allocate remaining functionality. Now: Choose architectural patterns and tactics and allocate functionality to satisfy the architectural drivers with the assistance of codified reasoning frameworks. Architecture drivers : There are many different opinions and preferences when it comes to how we should deal with software architecture. 37

Outline Preface This paper goal Prior work This paper approach Experiment Conclusion 38

Conclusion This enables a method that uses quality attribute reasoning frameworks to treat them in a “plug and play” fashion. A formal approach does not support designing for non-explicit requirements. The reasoning frameworks require a level of formality in specification of variables that is not always natural to an architect. 39