Chapter 6 Using UML, Patterns, and Java System Design: Decomposing - PDF document

Object-Oriented Software Engineering Chapter 6 Using UML, Patterns, and Java System Design: Decomposing the System Podcast Ch06-01 ♦ Title : Introduction to System Design ♦ Description : Introduction to System Design; Design Goals and Tradeoffs; Finding Design Patterns ♦ Participants : Barry Kurtz (instructor); Brandon Winters, Sara Hyde, Cheng Vue (students) ♦ Textbook : Object-Oriented Software Engineering: Using UML, Patterns and Java by Bernd Bruegge and Allen H. Dutoit Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 2 Why is Design so Difficult? ♦ Analysis: Focuses on the application domain ♦ Design: Focuses on the solution domain � Design knowledge is a moving target � The reasons for design decisions are changing very rapidly � Halftime knowledge in software engineering: About 3-5 years � What I teach today will be out of date in 3 years � Cost of hardware rapidly sinking ♦ “Design window”: � Time in which design decisions have to be made Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 3 Page 1

System Design 1. Design Goals 8. Boundary Definition Conditions Trade-offs Initialization Termination Failure 2. System Decomposition Layers/Partitions 7. Software Cohesion/Coupling Control Monolithic Event-Driven 3. Concurrency Threads Conc. Processes 6. Global Identification of 4. Hardware/ 5. Data Threads Software Resource Handling Management Mapping Access control Persistent Objects Security Special purpose Files Buy or Build Trade-off Databases Allocation Data structure Connectivity Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 4 How to use the results from the RAD ♦ Nonfunctional requirements => � Activity 1: Design Goals Definition ♦ Functional model => � Activity 2: System decomposition (Selection of subsystems based on functional requirements, cohesion, and coupling) ♦ Object model => � Activity 4: Hardware/software mapping � Activity 5: Persistent data management ♦ Dynamic model => � Activity 3: Concurrency � Activity 6: Global resource handling � Activity 7: Software control ♦ Subsystem Decomposition � Activity 8: Boundary conditions Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 5 List of Design Goals � Good documentation ♦ Reliability � Well-defined interfaces ♦ Modifiability � User-friendliness ♦ Maintainability � Reuse of components ♦ Understandability � Rapid development ♦ Adaptability � Minimum # of errors ♦ Reusability ♦ Efficiency � Readability ♦ Portability � Ease of learning ♦ Traceability of requirements � Ease of remembering ♦ Fault tolerance � Ease of use ♦ Backward-compatibility � Increased productivity ♦ Cost-effectiveness � Low-cost ♦ Robustness � Flexibility ♦ High-performance Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 6 Page 2

Relationship Between Design Goals End User Low cost Functionality User-friendliness Increased Productivity Backward-Compatibility Ease of Use Runtime Traceability of requirements Ease of learning Efficiency Rapid development Fault tolerant Flexibility Robustness Reliability Portability Good Documentation Client (Customer, Sponsor) Minimum # of errors Modifiability, Readability Reusability, Adaptability Developer/ Well-defined interfaces Maintainer Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 7 Typical Design Trade-offs ♦ Functionality vs. Usability ♦ Cost vs. Robustness ♦ Efficiency vs. Portability ♦ Rapid development vs. Functionality ♦ Cost vs. Reusability ♦ Backward Compatibility vs. Readability Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 8 Exercise ch06-01-01 Give a particular example that you are familiar with for each of the tradeoffs listed on the previous slide. Don’t repeat the examples given by your classmates in their discussion. Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 9 Page 3

Nonfunctional Requirements may give a clue for the use of Design Patterns ♦ Read the problem statement again ♦ Use textual clues (similar to Abbot’s technique in Analysis) to identify design patterns ♦ Text: “manufacturer independent”, “device independent”, “must support a family of products” � Abstract Factory Pattern ♦ 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 10 Textual Clues in Nonfunctional Requirements ♦ Text: “complex structure”, “must have variable depth and width” � Composite Pattern ♦ Text: “must interface to an set of existing objects” � Façade Pattern ♦ Text: “must be location transparent” � Proxy Pattern ♦ Text: “must be extensible”, “must be scalable” � Observer Pattern ♦ Text: “must provide a policy independent from the mechanism” � Strategy Pattern Bernd Bruegge & Allen H. Dutoit Object-Oriented Software Engineering: Using UML, Patterns, and Java 11 Page 4