1 / 39

Designing software architectures to achieve quality attribute requirements

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.

haru
Download Presentation

Designing software architectures to achieve quality attribute requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

  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: • Stimulus • Source of the stimulus • Environment • Artifact • Response • Response measure

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

  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 2. Use tactic 3. Make sure 1. Out of response measure

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

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

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

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

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

  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.

More Related