Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures

Transcription

1 Lecture 19 Engineering Design Resolution: Generating and Evaluating Architectures Software Engineering ITCS 3155 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Nov. 11, 2008

2 Lecture Overview Today Chapter 10 How to Generate Software Architectures Functional decomposition Impact of quality attributes on architectural design 2

3 Announcements Look at Appendix B. This is the full AquaLush Case Study including SRS, Use Cases, SAD, Refer to this before handing in deliverable 3

4 Architectural Design In architectural design, we specify: Structure -- the software program s major parts Responsibilities Properties Interfaces Behavior -- interactions among software program s major parts High-level description of structure and behavior is called a software architecture (This is where we are ) 4

5 Generating and Improving Architectures Generate candidate architectures How? First step in architectural design resolution Commonly used techniques Functional decomposition Quality attribute-based decomposition Modifying existing architecture Elaborate architectural style Transform conceptual model 5

6 Techniques to Generate Architectures 1) Functional decomposition Look at the functional requirements from the SRS and USE Case documentation that we have already generated. More Later. 2) Quality attribute-based decomposition Start with the non-functional requirements to begin creating the architecture. More later. 6

7 Techniques to Generate Architectures 3) Modifying existing architecture Do you have access to existing system. Perhaps it can be used as the basis for creating the architecture of the new system. This is not commonly used for a couple of reasons. 1) may have no access to a similar system. 2) if you do have access to an existing system, you are probably replacing it. If that is the case, one could study it to determine what deficiencies the current system contains. 7

8 Techniques to Generate Architectures 4) Elaborate architectural style Design Patterns. A general reusable solution to a commonly occurring problem in software design. In other words, a template to solve a problem that is adapted to your specific problem 5) Transform conceptual model Chapter 11 next week 8

9 Functional Decomposition Define functional components that are coherent collections of functional and data requirements Study SRS and USE Cases Brainstorm Candidate modules Relationships between modules 9

10 AquaLush Use Case Set Irrigation Parameters Start up Toggle Irrigation Operator Manual Control Irrigation Irrigate Valve Make Repairs Maintainer Report Failures Sensor 10

11 AquaLush Use Case Set Irrigation Parameters Start up User interface Irrigation Control Toggle Irrigation Operator Manual Control Irrigation Irrigate Valve Make Repairs Maintainer Report Failures Monitor and repair Sensor 11

12 AquaLush Functional Decomposition AquaLush prioritized requirements Configure program at startup Control irrigation Manually Automatically Provide user interface Allow users to monitor and repair system 12

13 Functional Decomposition Example: AquaLush Components Irrigation Control Startup Monitor and Repair User Interaction We are displaying all our major components with simple boxes along with a legend. Legend Functional Component What are we missing? 13

14 Functional Decomposition Example: AquaLush Component Interactions Who communicates with each other? Now we are getting there. We are using a simple box and line diagram. Still not completely finished. 14

15 Functional Decomposition Example: AquaLush Data Storage (Option 1) Monitor and Repair Legend AquaLush State Functional Component Data Store User Interaction x x Irrigation Control Startup AquaLush Configuration y y Interacts With x Reads & Writes y x Reads y The configuration data must be stored in permanent storage. Failed/repaired parts are also stored. How does Irrigation Control know when the system changes? Answer: Polling 15

16 Functional Decomposition Example: AquaLush Data Storage (Option 2) User Interaction Monitor and Repair Irrigation Control Startup In this design Monitor and Repair notifies Irrigation Control when a change is made. AquaLush State AquaLush Configuration Irrigation Control reads data store for current state. Legend Functional Component Data Store x x y y Interacts With x Reads & Writes y x Reads y There are tradeoffs here!!! Increased Coupling!!! 16

17 Quality Attribute-based Decomposition Define modules and relationships to satisfy quality attributes Add modules and relationships later to meet functional and data needs 17

18 Quality Attributes We ve heard of quality attributes before but we called them Non-functional requirements Classes of Quality Attributes Development attributes Operational attributes Define modules and relationships to satisfy nonfunctional requirements Add modules and relationships later to meet functional and data needs 18

19 Quality Attributes A quality attribute is is a characteristic or or property of of a software product independent of of its its function that is is important in in satisfying stakeholder needs. Also known as Non-functional requirement 19

20 Development Attributes Applies to the Developer: Maintainability Correctability fixing bugs as they appear Improvability adding functionality Portability moving to another platform Modifiability changing functionality Reusability Are we creating modules that may be used by other systems Is it a priority? 20

21 Development Attributes Testability Is the design done in a way that facilitates the testing process What attribute helps in creating a system that is easy to test? Answer: Low coupling 21

22 Development Quality Attributes Maintainability Degree to which a product can be corrected, improved, or ported Specific maintainability attributes Modifiability Portability Reusability Degree to which a product s parts can be reused in another product or future versions Testability Degree to which a product s associated requirements can be validated through testing 22

23 Operational Attributes Applies to the User, Customer and Developer: Performance Metric Latency startup time OR time delay between the moment something is initiated, and the moment one of its effects begins or becomes detectable Memory usage Throughput - the amount of work that a computer does in a given time period. ISDN has a latency of about 10ms. Its thoughput may only be twice that of a modem, but its latency is ten times better, and that's the key reason why browsing the web over an ISDN link feels so much better than over a modem. 23

24 Operational Quality Attributes Availability Reliability Security Readiness for use Metric: downtime Behaves according to requirements under normal operating conditions Metric: mean time to failure Resistance to harm or cause harm by hostile acts or influences 24

25 Architectural Decisions to Address Quality Attributes Performance Localize time-intensive operations and optimize minimize communications Use large rather than fine-grain components Security Use a layered architecture with critical assets in the inner layers Safety Localize safety-critical features in a small number of sub-systems Availability Include redundant components and mechanisms for fault tolerance Maintainability Use fine-grain, replaceable components 25

26 Architectural Conflicts Large-grain components improves performance reduces maintainability Redundant data improves availability makes security more difficult May decrease performance Localizing safety-related features simplifies security more communication so degraded performance 26

27 AquaLush Quality Attribute-based Decomposition AquaLush prioritized non-functional requirements 1. Reusability Main irrigation software components must be reused in future versions 2. Modifiability Must accommodate changes in irrigation strategy 3. Hardware adaptability Must work with various valve types, sensors, displays, keypads, screen buttons 4. Reliability We can trust the system to perform accurately 27

28 Quality Attribute Decomposition Example: Addressing Reusability Reusability requirements can be met by making parts highly modular Small, cohesive parts Parts hide information Loosely coupled to other parts Irrigation module must be reusable Create a separate irrigation module 28

29 Quality Attribute Decomposition Example: Addressing Modifiability Irrigation Control module must have modifiable strategies Can also be met by making Irrigation Control module highly modular Can replace or modify individual strategies Irrigation Control Manual Irrigation Control Automatic Irrigation Control Legend Module Part Of 29

30 Quality Attribute Decomposition Example: Addressing Hardware Adaptability A standard way to achieve hardware adaptability use a device interface module that contains virtual devices A virtual device is is a software simulation of, of, or or interface to, to, a real hardware device or or system. 30

31 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) If physical device changes, only implementation of virtual device changes Not the virtual device interface! Typically realized as a family of components for different real devices or systems A device interface module, in our case 31

32 Virtual Device What is this is an example of? Design Pattern!!! The adapter design pattern 32

33 Quality Attribute Decomposition Example: Addressing Hardware Adaptability 33

34 Quality Attribute Decomposition Example: Addressing Reliability One strategy for making systems reliable is to make modules small and interactions simple Already the case here! 34

35 Quality Attribute Decomposition Example: Addressing Missing Requirements User Interface Irrigation Control Manual Irrigation Control Automatic Irrigation Control Need a user interface! Valve Sensor Device Interface Display Keypad Screen Buttons Legend Module Interacts With Part Of 35

36 The 2 Architectures: User Interface Irrigation Control Manual Irrigation Control Automatic Irrigation Control Valve Sensor Device Interface Display Keypad Screen Buttons Legend Module Interacts With Part Of 36

37 Generating Architectures Commonly used techniques Functional decomposition Quality attribute-based decomposition Transform conceptual model (next week) Modifying existing architecture (we don t have one) Elaborate architectural style (soon) 37

38 Architectural Design Process We ve generated Now, how do we: Improve? Evaluate? Select? SRS Architectural Design Process SRS : Problem SAD : Solution Analyze SRS Generate/Improve Candidate Architectures Evaluate Candidate Architectures Select Architecture [else] [adequate architecture] Finalize Architecture SAD 38

39 Improving Architectural Alternatives Combine Alternatives Combine the best features of two or more alternatives Example: Combine quality attribute generated with function decomposition generated alternatives Impose an Architectural Style Modify an architecture that almost fits a style so that it does fit the style Apply Mid-Level Design Patterns Modify an architecture to take advantage of mid-level design patterns 39

40 Evaluating Architectural Alternatives Two primary techniques Scenarios Prototypes Techniques may be complementary 40

41 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 (compare strengths and weaknesses) Multi-dimensional ranking Scoring matrix 41

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

43 Example Utility Tree AquaLush Utility Tree Profiles correspond to nonfunctional and functional requirements! Importance of Scenario (weight) Functional requirements Non-functional requirements 43

44 Scoring Matrix Quantify the scenario values (H = 3, M = 2, L = 1) Normalize so that the sum of the scenario weights are 1. Do this by dividing the scenario values by the sum of the scenario weights. Create the scoring matrix for all candidate architectures See Fig (p. 306) 44

45 Scenario Add a Valve type A developer modifies the AquaLush source code and design documents so that AquaLush supports a new type of valve. The developer completes the process in two days. How do the two designs handle this scenario? 45

46 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 (examine strength and weaknesses) Multi-dimensional ranking (scoring matrix) Disadvantage - expensive 46

47 Summary Generating Software Architectural Designs Using: 1) Functional Requirements 2) Quality Attributes 47