Generating, Evaluating, Improving, and Selecting Software Architectures

1. Generating, Evaluating, Improving, and Selecting Software Architectures

2. Objectives • To survey architecture generation techniques • To illustrate generation techniques • To introduce the idea of virtual devices • To survey improvement techniques • To present the use of scenarios and profiles for architectural evaluation • To present the use of prototypes for architectural evaluation

3. Topics • Architectural generation techniques • Functional decomposition • Quality-attribute-based decomposition • Virtual devices and device interface modules • Architecture improvement techniques • Evaluating architectural alternatives • Scenarios, profiles, utility trees • Prototypes • Selecting architectural alternatives

4. Generation Techniques 1 • Determine FunctionalComponents—Create components responsible for realizing coherent collections of functional and data requirements. • Determine Components Based on QualityAttributes—Form components to meet non-functional requirements, then add components to fill functional and data requirements gaps.

5. Generation Techniques 2 • Modify an ExistingArchitecture—Alter an architecture for a similar program. • Elaborate an ArchitecturalStyle—An architectural style is a paradigm of program or system constituent types and their interactions (more on this later). Elaborate a style to form an architecture. • Transform a ConceptualModel—Modify a conceptual model from a problem to a solution description.

6. AquaLush Functional Decomposition 1

7. AquaLush Functional Decomposition 2

8. AquaLush Functional Decomposition 3

9. AquaLush Functional Decomposition 4

10. Achieving Adaptability A standard way to achieve hardware adaptability is to use a device interface module containing virtual devices. A virtual device is a software simulation of, or interface to, a real hardware device or system.

11. Virtual Device Characteristics • Simulates an “ideal” device that • Does exactly one job completely (cohesion) • Has a simple, consistent, complete interface (simplicity) • Is loosely coupled to the rest of the program (coupling) • Hides its implementation (information hiding) • Never changes (stability) • Typically realized as a family of components for different real devices or systems

12. AquaLush Quality-Attribute-Based Decomposition 1

13. AquaLush Quality-Attribute-Based Decomposition 2

14. AquaLush Quality-Attribute-Based Decomposition 3

15. Improving Alternatives • CombineAlternatives—Combine the best features of two or more alternatives • Impose an ArchitecturalStyle—Modify an architecture that almost fits a style so that it does fit the style • Apply Mid-Level DesignPatterns—Modify an architecture to take advantage of mid-level design patterns

16. Evaluating Alternatives • How can designers determine whether a program built to an architectural specification will satisfy its requirements before the program is built? • No one knows how to guarantee this, but several techniques make it more likely. • We examine the use of scenarios and prototypes for evaluation.

17. Scenarios A scenario is an interaction between a product and particular individuals. • Use case instances are interactions between and a product and actors • Broader view because now we consider interactions between a product and any individual

18. Scenario-Writing Heuristics 1 • Label each scenario with a descriptive phrase. • Write simple declarative sentences in the active voice. • Write scenario descriptions in three parts. • Initial state of product and its environment • Activity flow between product and individuals • Final state of the product and its environment

19. Scenario-Writing Heuristics 2 • Make a principal in the interaction the subject of a sentence describing the activity flow. • Describe the initial and final states of both the product and its environment. • State target outcome measures whenever possible. • Proofread the description.

20. Profiles A profile is a set of scenarios used to evaluate whether a product is likely to meet a set of requirements. • Examples: usage profile, reliability profile • Scenarios in profiles should have weights • Profiles are formed by choosing 3 to 10 representative scenarios from all those that fit a profile

21. Creating Profiles and Scenarios • A utility tree is a tree whose sub-trees are profiles and whose leaves are scenarios. • Label the root “utility.” • Add children with profile names that reflect product requirements. • Fill in scenarios for each profile. • Brainstorm scenarios • Rationalize the list • Weight each scenario • Eliminate low-weight scenarios until each profile has 3 to 10 leaves • Write scenario descriptions.

22. Example Utility Tree

23. Evaluating and Selecting with Scenarios • Walk through each scenario. • Judge how well a design alternative supports the scenario. • Record a judgment for each scenario. • Use a selection technique to choose an alternative. • Pros and cons • Multi-dimensional ranking • Scenarios weights are normalized • Judgments are quantified

24. Evaluating and Selecting with Prototypes • Prototypes may be built to test out design alternatives. • Scenario walkthroughs may give rise to a need for prototyping. • Prototypes provide the factual basis for selection using • Pros and cons; • Multi-dimensional ranking.

25. Summary • Several complimentary techniques can be used to generate and improve architectural alternatives. • Building profiles consisting of weighted scenarios and walking through them is a solid technique for evaluating architectural alternatives. • Prototypes can also supply data for architectural evaluation. • Previously discussed techniques can be applied to select alternatives.