1

Designing software architectures to achieve quality attribute requirements

F. Bachmann, L. Bass, M. Klein and C. SheltonIEE Proceedings Software

Tzu-Chin Chien

2

Outline

• Preface• This paper goal• Prior work• This paper approach• Experiment• Conclusion

3

Preface

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.

4

About this paper

• The authors describe a structure called a reasoning framework as a modularization of quality attribute knowledge.

1. User interface friendly (understandability)

2. Change independently (operability) reasoning

framework

5

Reasoning work

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

Reasoning framework

6

Outline

• Preface• This paper goal• Prior work• This paper approach• Experiment• Conclusion

7

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

8

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.

But there are two problems

+

9

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) .

10

2.The quality attribute model approach

• ISO9126 lists 6 primary and 21 secondary quality attribute knowledge and practice.

But there are three problems

11

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.

12

3.The intuitive design approach

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.

13

Attribute driven method

Architectural drivers

Pattern Tactics

Right?

Remaining functionality

Interface

Verify

Decompose

Part

Refine

Finish

Next part

14

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

15

Outline

• Preface• This paper goal• Prior work• This paper approach• Experiment• Conclusion

16

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.

17

This paper approach

• Combines three approaches (NFR,QAM, ADD)

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.

18

Reasoning framework

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

19

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)

20

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. Artifact5. Response6. Response measure

21

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.

22

Step2 & Step3

• Quality attribute model& Response measure

23

Step5: Architecture transformations (1)

• Tactics is needed before Architecture transformations

24

Step4: Architecture transformations (2)

• An architectural tactic can change the structure of an architecture

1. Out of response measure

2. Use tactic

3. Make sure

25

Outline

• Preface• This paper goal• Prior work• This paper approach• Experiment• Conclusion

26

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.

27

Figure

Problem’s data flow and their responsibility

28

Find quality attribute requirements

29

Satisfy a quality attribute goal (modifiability)

30

Response measure

Problem’s data flow and their responsibility

0.8 0.80.2

1

1

1*1 + 1*0.8 + 1*0.8 * 0.8+ 2*1 + 2 * 0.2 > 3 day

31

Architecture transformations : Abstract common service

32

Figure

33

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.

34

Table

35

Response measure

0.8

0.5

0.2 0.2

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

1

36

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.

37

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.

38

Outline

• Preface• This paper goal• Prior work• This paper approach• Experiment• Conclusion

39

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.