390 likes | 518 Vues
Designing software architectures to achieve quality attribute requirements. F. Bachmann, L. Bass, M. Klein and C. Shelton IEE Proceedings Software Tzu-Chin Chien. O utline. Preface This paper goal Prior work This paper approach Experiment Conclusion . Preface.
E N D
Designing software architectures to achieve quality attribute requirements F. Bachmann, L. Bass, M. Klein and C. Shelton IEE Proceedings Software Tzu-Chin Chien
Outline • Preface • This paper goal • Prior work • This paper approach • Experiment • Conclusion
Preface • Architecture is too abstract to understand. • Critical link between requirements engineering and design. • Architecture can grow, because software has become more and more complex.
About this paper • The authors describe a structure called a reasoning frameworkas a modularizationof quality attribute knowledge. User interface friendly (understandability) 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. Reasoning framework
Outline • Preface • This paper goal • Prior work • This paper approach • Experiment • Conclusion
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
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
NFR’s problem • The architect must rely on intuition to determine which decisions to consider. • 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) .
2.The quality attribute model approach • ISO9126 lists 6 primary and 21 secondary quality attribute knowledge and practice. But there are three problems
QAM’s problem • Not every quality attribute has an existing predictive method. • Not every architecture is amenable to analysis by various quality attribute models. (e.g. RMA:SJF preemptive) • Quality attribute models may not scale well.
3.The intuitive design approach • 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. Architectural driver
Attribute driven method Part Architectural drivers Right? Decompose Pattern Tactics Next part Remaining functionality Refine Interface Finish Verify
Short summary • Nonfunctional requirements approach • Choose quality goal • Quality attribute model • Find relationship among the concept , but not scale well • Attribute driven model • Scale well
Outline • Preface • This paper goal • Prior work • This paper approach • Experiment • Conclusion
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.
This paper approach • Combines three approaches (NFR,QAM, ADD) ADD Reduce problem of scale in using QAM Rational architectural decision QAM NFR Choose the most important quality attribute goal • 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.
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)
Step1: Quality attribute requirements A general scenario is a system independent description of a quality attribute requirement. It has six parts: • Stimulus • Source of the stimulus • Environment • Artifact • Response • Response measure
Step2: Satisfying a quality attribute • A single quality attribute requirement anddescribe the elements we use to determine whether it issatisfied by the current architecture design.
Step2 & Step3 • Quality attribute model& Response measure
Step5: Architecture transformations (1) • Tactics is needed before Architecture transformations
Step4: Architecture transformations (2) • An architectural tactic can change the structure of an architecture 2. Use tactic 3. Make sure 1. Out of response measure
Outline • Preface • This paper goal • Prior work • This paper approach • Experiment • Conclusion
Sample problem The problem is • to receive automotive sensor information • to determine whether the sensors suggest either a problem with the environment being sensed or with the sensors themselves.
Figure Problem’s data flow and their responsibility
Response measure Problem’s data flow and their responsibility 1 0.8 0.8 0.2 1 1*1 + 1*0.8 + 1*0.8 * 0.8+ 2*1 + 2 * 0.2 > 3 day
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.
Response measure 0.2 0.8 0.2 1 0.5 1*1 + 1*0.8 + 1*0.8 * 0.2 + 1*0.8*0.2*0.2 + 1 * 0.5 < 3 day
Using ADD to scale • There are three problems of scale associated with reasoning frameworks: • The number of codified reasoning frameworks is small. • Each reasoning framework should go deeper. • The solvers for any particular reasoning framework may not scale well with respect to the number of elements in the architecture.
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.
Outline • Preface • This paper goal • Prior work • This paper approach • Experiment • Conclusion
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.