Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 1 Design “There are 2 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 make it so complicated that there are no obvious deficiencies.” - C.A.R. Hoare

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2 Why is Design so Difficult?  Analysis: Focuses on the application domain  Design: Focuses on the implementation domain  Design knowledge is a moving target  A design decision’s rationale changes rapidly  Half-life of knowledge in software engineering: About 3-4 years   What’s done today is out of date in 3 years  Cost of hardware rapidly sinking  Design window: Time frame for making design decisions.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 3 The Purpose of System Design  Bridge the gap between desired & existing system.  Use Divide & Conquer  Model the new system as a set of subsystems. Problem Existing System New System

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 4 System Design 2. System Layers/Partitions Coherence/Coupling 5. Data 1. Design Goals Definition Trade-offs 4. Hardware/ Special purpose Software Buy or Build Trade-off Allocation Connectivity 3. Concurrency Data structure Persistent Objects Files Databases Management Access control Security 6. Global Resource Handling 8. Boundary Conditions Initialization Termination Failure Decomposition Mapping 7. Software Control Identification of Threads Monolithic Event-Driven Threads Conc. Processes

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 5 Use the Requirements Analysis for System Design  Nonfunctional requirements =>  Activity 1: Design Goals Definition  Use Case model =>  Activity 2: System decomposition  Define subsystems based on functional requirements, coherence, & 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  Activity 8: Boundary conditions

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 6 Activity diagram for system design

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 7 Section 1. Design Goals  Reliability  Modifiability  Understandability  Adaptability  Reusability  Efficiency  Portability  Traceability  Fault tolerance  Backward-compatibility  Cost-effectiveness  Robustness  High-performance  Good documentation  Well-defined interfaces  User-friendliness  Reuse of components  Rapid development  Minimum # of errors  Readability  Ease of learning  Ease of remembering  Ease of use  Increased productivity  Low-cost  Flexibility

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 8 Relationship Between Design Goals Reliability Low cost Increased Productivity Backward-Compatibility Traceability of requirements Rapid development Flexibility Client End User (Customer, Portability Good Documentation Runtime Efficiency Sponsor) Developer/ Maintainer Minimum # of errors Modifiability, Readability Reusability, Adaptability Well-defined interfaces Functionality User-friendliness Ease of Use Ease of learning Fault tolerant Robustness

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 9 Typical Design Goal 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 Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10 Nonfunctional Requirements Suggest Design Patterns  The problem statement identifies potential 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 Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11 Nonfunctional Requirements Suggest Design Patterns  Text: “complex structure”, “must have variable depth & 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 Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12 Section 2. System Decomposition  Subsystem (UML: Package)  Interrelated classes, associations, operations, events, & constraints  Seed for subsystems: UML Objects & Classes.  Service  Group of operations provided by the subsystem  Seed for services: Subsystem use cases  Service is specified by Subsystem interface  Specifies interaction & information flow between subsystems.  Well-defined & small.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13 Services & Subsystem Interfaces  Service: A set of related operations with a common purpose  E.g., Notification subsystem service  LookupChannel()  SubscribeToChannel()  SendNotice()  UnsubscribeFromChannel()  Services are defined in System Design  Subsystem Interface: Set of typed, related operations.  Subsystem Interfaces are defined in Object Design

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 14 Coupling & Coherence  Goal: Reduction of complexity  Coherence measures the interdependence of classes  Coherent: The subsystem’s classes are related via associations.  Low coherence: Lots of misc & aux objects, no associations  Coupling measures dependencies between subsystems  Coupled: Modifications to 1 subsystem impact other subsystems  E.g., change of model, massive recompilation, … (Illustrate: CPU architecture vs. subsystem by gate type)  Subsystems should maximize coherence & minimize coupling.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 15 Example: STARS Subsystem Decomposition Good decomposition or too interconnected? ModelingAuthoringWorkorderRepairInspection Augmented Reality Workflow

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16 STARS as a 3-layered Architecture RepairInspectionAuthoring Augmented Reality WorkflowModeling

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 17 Partitions & Layers  Partition  Decomposition into independent (or weakly-coupled) subsystems that provide services on the same level of abstraction.  Layer  A subsystem providing services to a higher level of abstraction  A layer depends only on lower layers  A layer has no knowledge of higher layers  System decomposition uses layers & partitions.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18 Layer 1 Layer 2 Layer 3 Subsystem Decomposition into Layers CX subsystems  Consumer, Producer, ProductionNetwork, TaskServer, MarketMaker  What are associations?  Is there a layering?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 19 Layer & Partition Relationships between Subsystems  Layer relationship  Layer A “Calls” Layer B (runtime)  Layer A “Depends on” Layer B (“make” dependency, compile)  Partition relationship  The subsystems have mutual but limited knowledge of each other  Partition A “Calls” partition B and partition B “Calls” partition A

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20 Virtual Machine  A system is seen as a sequence of virtual machines, each built in terms of the ones below. VM4 VM3 VM2 VM1 C1 attr opr C1 attr opr C1 attr opr C1 attr opr C1 attr opr C1 attr opr C1 attr opr C1 attr opr Problem Existing System

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21 Virtual Machine …  A virtual machine is an abstraction  It provides a set of attributes & operations.  A virtual machine is connected to higher & lower level virtual machines by "provides services for" associations.  There are 2 architectural types of virtual machines:  closed  open.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22 Closed Architecture (Opaque Layering)  Virtual machine only calls operations from the layer below  Design goal: Strong encapsulation  High maintainability VM4 VM3 VM2 VM1 C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 23 Open Architecture (Transparent Layering)  A virtual machine can call operations from any layers below  Design goal: Runtime efficiency  Violates the Law of Demeter: A method invokes methods only of 1) “this”, 2) its parameters, 3) members of “this”, 4) local objects. VM4 VM3 VM2 VM1 C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op C1 attr op

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 24 Properties of Layered Systems  Layered systems are hierarchical.  Hierarchy reduces complexity.  Closed architectures are more portable.  Open architectures may be more efficient.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 25 Software Architectures  Subsystem decomposition  Identify subsystems, services, & their relationship to each other.  Architectures  Client/Server Architecture  Peer-To-Peer Architecture  Repository Architecture  Model/View/Controller  Pipes & Filters Architecture

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 26 Client/Server Architecture  1 or many servers provides service to clients, instances of subsystems.  Client calls the server, which performs some service  Client uses the server’s interface (its service)  Server responds asap  Users interact only with the client

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 27 Client/Server Architecture  Often used in database systems  Front-end: User application (client)  Back end: Database access & manipulation (server)  Functions performed by client  Customized user interface  Front-end processing of data  Access to database server across the network  Functions performed by the database server  Centralized data management  Data integrity & database consistency  Database security  Concurrent operations (multiple user access)

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 28 Design Goals for Client/Server Systems  Portability  Server can be installed on a variety of machines/OSs. Functions in a variety of network environments  Transparency  The server may itself be distributed (why?), but provides 1 "logical" service  Performance  Client performs interactive display-intensive operations (view construction)  Server provides [some] CPU-intensive operations  Scalability  Server has spare capacity to handle spikes in client requests  Flexibility  Adapts to a variety of user interfaces (client decouples user from server)  Reliability  System should survive individual node & communication link failure

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 29 Peer-to-Peer Architecture  Clients can be servers & servers can be clients: both are peers  More difficult because of possibility of deadlocks

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30 Application Presentation Session Transport Network DataLink Physical Frame Packet Bit Connection Format Message Level of abstraction Example of a Peer-to-Peer Architecture  OSI Reference Model  OSI = Open System Interconnection  Reference model defines 7 layer network protocol & communication methods between layers.

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 31 Middleware Allows You To Focus On Application Layer Application Presentation Session Transport Network DataLink Physical Socket CORBA TCP/IP Object Ethernet Wire

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 32 Model/View/Controller  Subsystems are classified into 3 different types  Model subsystem: Responsible for application domain knowledge  View subsystem: Responsible for displaying application domain objects to the user  Controller subsystem: Responsible for interactions with the user & model changes.  MVC is a special case of a repository architecture  Model subsystem implements the central datastructure, the Controller subsystem explicitly dictate the control flow Controller Model subscriber notifier initiator * repository1 1 * View

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 33 A File System based on the MVC Architecture

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 34 Sequence of Events Controller InfoView Model 2.User types new filename 1. Views subscribe to event 3. Request name change in model 4. Notify subscribers 5. Updated views FolderView Should model notify all subscribers of all changes? Are all views local to model?

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35 Repository Architecture  Subsystems access/modify data from 1 data structure  Subsystems are loosely coupled (interact only via repository)  Control flow is dictated by central repository (triggers) or by the subsystems (locks, synchronization primitives) Subsystem Repository createData() setData() getData() searchData()

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 36 Examples of Repository Architecture  Database Management Systems (DBMS)  Modern Compilers  Linda, JavaSpaces LexicalAnalyzer SyntacticAnalyzer SemanticAnalyzer CodeGenerator Compiler SyntacticEditor ParseTree SymbolTable Repository SourceLevelDebugger Optimizer

Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 37 Summary  System Design  Decomposes the system into manageable subsystems  Design Goals Definition  Describe & prioritize important system qualities  Order the values against which design options are evaluated  Subsystem Decomposition  Each subsystem should be coherent.  Subsystems should be loosely coupled.