Chapter 6 make it so complicated that there are no obvious Using - PDF document

Design Object-Oriented Software Engineering “There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to Chapter 6 make it so complicated that there are no obvious Using UML, Patterns, and Java System Design: deficiencies.” Decomposing the System - C.A.R. Hoare Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 Why is Design so Difficult? The Purpose of System Design ♦ Analysis: Focuses on the application domain Problem ♦ Design: Focuses on the solution domain � Design knowledge is a moving target � The reasons for design decisions are changing very rapidly ♦ Bridging the gap between desired and existing system in a � Halftime knowledge in software engineering: About 3-5 years New manageable way � What I teach today will be out of date in 3 years System ♦ Use Divide and Conquer � Cost of hardware rapidly sinking � We model the new system to be ♦ “Design window”: developed as a set of subsystems � Time in which design decisions have to be made ♦ Technique � Time-boxed prototyping Existing System Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 System Design Overview System Design System Design I (This week – Chapter 6) 0. Overview of System Design 1. Design Goals 1. Design Goals 8. Boundary De fi nition Conditions 2. Subsystem Decomposition Trade-offs Initialization Termination Failure 2. System System Design II: Addressing Design Goals (Next week – Decomposition Chapter 7) Layers/Partitions 7. Software Cohesion/Coupling Control 3. Concurrency Monolithic 4. Hardware/Software Mapping Event-Driven 3. Concurrency Threads 5. Persistent Data Management 6. Global Conc. Processes 4. Hardware/ Identification of 5. Data Software Resource Handling 6. Global Resource Handling and Access Control Threads Management Mapping Access control 7. Software Control Persistent Objects Special purpose Security Files Buy or Build Trade-off 8. Boundary Conditions Databases Allocation Data structure Connectivity Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Page 1

How to use the results from the Requirements Analysis for System Design How do we get the Design Goals? ♦ Nonfunctional requirements => � Activity 1: Design Goals Definition ♦ Functional model => Let’s look at a small example � Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling) ♦ Object model => � Current Situation: � Activity 4: Hardware/software mapping � Computers must be used in the office � Activity 5: Persistent data management ♦ Dynamic model => � Activity 3: Concurrency � What we want: � Activity 6: Global resource handling � A computer that can be used in mobile situations. � Activity 7: Software control ♦ Subsystem Decomposition � Activity 8: Boundary conditions Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Identify Current Technology Constraints Example: Current Desktop Development Direction where the user looks is Single Output irrelevant Device Fixed Network Connection Location of user does not matter Precise Input Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 10 Generalize Constraints using Technology Enable Establish New Design Goals Direction where the Direction where the user looks is user looks is Multiple Output Single Output irrelevant relevant Device Devices � Mobile Network Connection � Multiple Output Devices Dynamic Network Fixed Network � Location-Based Connection Connection Location of � Multimodal Input (Users Gaze, Users Location, …) Location-based user does not � Vague input matter Vague Input Precise Input Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 12 Page 2

Sharpen the Design Goals List of Design Goals ♦ Reliability � Good documentation � Location-based input ♦ Modifiability � Well-defined interfaces ♦ Maintainability � Input depends on user location � User-friendliness ♦ Understandability � Reuse of components � Input depends on the direction where the user ♦ Adaptability � Rapid development looks (“egocentric systems”) ♦ Reusability � Minimum # of errors � Multi-modal input ♦ Efficiency � Readability ♦ Portability � The input comes from more than one input device � Ease of learning ♦ Traceability of requirements � Dynamic connection � Ease of remembering ♦ Fault tolerance � Contracts are only valid for a limited time ♦ Backward-compatibility � Ease of use � Is there a possibility of further generalizations? ♦ Cost-effectiveness � Increased productivity ♦ Robustness � Low-cost � Example: location can be seen as a special case of context ♦ High-performance � Flexibility � User preference is part of the context � Interpretation of commands depends on context Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 13 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 14 Classroom Activity – Design Goals Relationship Between Design Goals End User Low cost Functionality ♦ Description: Identify and prioritize User-friendliness Increased Productivity the design goals for your project. Backward-Compatibility Ease of Use Runtime Traceability of requirements Ease of learning ♦ Process: Efficiency Fault tolerant Rapid development Flexibility Robustness � Meet as teams Reliability Choose a scribe to record design goals Portability � Good Documentation � Identify top 5 – 10 ordered design Client (Customer, goals (there may be more or less). Sponsor) Minimum # of errors � You have about 5 minutes. Nielson Modifiability, Readability Usability Engineering Reusability, Adaptability MMK, HCI Developer/ Rubin Well-defined interfaces Maintainer Task Analysis Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 15 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 16 Nonfunctional Requirements may give a clue for the Typical Design Trade-offs use of Design Patterns ♦ Read the problem statement again ♦ Functionality vs. Usability ♦ Use textual clues (similar to Abbot’s technique in Analysis) to ♦ Cost vs. Robustness identify design patterns ♦ Efficiency vs. Portability ♦ Rapid development vs. Functionality ♦ Text: “manufacturer independent”, “device independent”, ♦ Cost vs. Reusability “must support a family of products” � Abstract Factory Pattern ♦ Backward Compatibility vs. Readability ♦ Text: “must interface with an existing object” � Adapter Pattern ♦ Text: “must deal with the interface to several systems, some of them to be developed in the future”, “ an early prototype must be demonstrated” � Bridge Pattern Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 17 Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 18 Page 3