Design There are 2 ways of constructing a

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 1

Why is Design so Difficult? ¨ Analysis: Focuses on the application domain ¨ Design: Focuses on the implementation domain w Design knowledge is a moving target w A design decision’s rationale changes rapidly t t What’s done today is out of date in 3 years t ¨ Half-life of knowledge in software engineering: About 3 -4 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 2

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

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

Use the Requirements Analysis for System Design ¨ Nonfunctional requirements => w Activity 1: Design Goals Definition ¨ Use Case model => w Activity 2: System decomposition t ¨ Define subsystems based on functional requirements, coherence, & coupling. Object model => w Activity 4: Hardware/software mapping w Activity 5: Persistent data management ¨ Dynamic model => w w 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 5

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

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

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

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 9

Nonfunctional Requirements Suggest Design Patterns ¨ The problem statement identifies potential design patterns ¨ Text: “manufacturer independent”, “device independent”, “must support a family of products” w Abstract Factory Pattern ¨ Text: “must interface with an existing object” w 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” w Bridge Pattern Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 10

Nonfunctional Requirements Suggest Design Patterns ¨ Text: “complex structure”, “must have variable depth & width” w Composite Pattern ¨ Text: “must interface to an set of existing objects” w Façade Pattern ¨ Text: “must be location transparent” w Proxy Pattern ¨ Text: “must be extensible”, “must be scalable” w Observer Pattern ¨ Text: “must provide a policy independent from the mechanism” w Strategy Pattern Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 11

Section 2. System Decomposition ¨ Subsystem (UML: Package) w Interrelated classes, associations, operations, events, & constraints w Seed for subsystems: UML Objects & Classes. ¨ Service w Group of operations provided by the subsystem w Seed for services: Subsystem use cases ¨ Service is specified by Subsystem interface w Specifies interaction & information flow between subsystems. w Well-defined & small. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 12

Services & Subsystem Interfaces ¨ Service: A set of related operations with a common purpose w E. g. , Notification subsystem service t Lookup. Channel() t Subscribe. To. Channel() t Send. Notice() t Unsubscribe. From. Channel() w Services are defined in System Design ¨ Subsystem Interface: Set of typed, related operations. w Subsystem Interfaces are defined in Object Design Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 13

Coupling & Coherence ¨ Goal: Reduction of complexity ¨ Coherence measures the interdependence of classes w Coherent: The subsystem’s classes are related via associations. w Low coherence: Lots of misc & aux objects, no associations ¨ Coupling measures dependencies between subsystems w Coupled: Modifications to 1 subsystem impact other subsystems t 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 14

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

STARS as a 3 -layered Architecture Repair Inspection Augmented Reality Authoring Workflow Modeling Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 16

Partitions & Layers ¨ Partition w Decomposition into independent (or weakly-coupled) subsystems that provide services on the same level of abstraction. ¨ Layer w A subsystem providing services to a higher level of abstraction w A layer depends only on lower layers w 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 17

Subsystem Decomposition into Layers Layer 1 Layer 2 Layer 3 CX subsystems w Consumer, Production. Network, Task. Server, Market. Maker w What are associations? w Is there a layering? Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 18

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

Virtual Machine ¨ A system is seen as a sequence of virtual machines, each built in terms of the ones below. Problem C 1 attr opr C 1 attr opr VM 2 C 1 attr opr VM 1 C 1 attr opr VM 3 VM 4 Existing System Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 20

Virtual Machine … ¨ A virtual machine is an abstraction w 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: w closed w open. Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 21

Closed Architecture (Opaque Layering) ¨ ¨ Virtual machine only calls operations from the layer below Design goal: Strong encapsulation High maintainability C 1 attr op op op VM 1 C 1 attr op op C 1 attr op Bernd Bruegge & Allen Dutoit C 1 attr op VM 2 VM 3 VM 4 Object-Oriented Software Engineering: Conquering Complex and Changing Systems 22

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

Properties of Layered Systems ¨ Layered systems are hierarchical. w 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 24

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

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 26

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

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

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 29

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

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

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

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

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

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) Repository Subsystem Bernd Bruegge & Allen Dutoit create. Data() set. Data() get. Data() search. Data() Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35

Examples of Repository Architecture Compiler Syntactic. Analyzer Semantic. Analyzer Optimizer Code. Generator Lexical. Analyzer ¨ Database Management Systems (DBMS) ¨ Linda, Java. Spaces Parse. Tree Symbol. Table Modern Compilers ¨ Repository Bernd Bruegge & Allen Dutoit Source. Level. Debugger Object-Oriented Software Engineering: Conquering Complex and Changing Systems Syntactic. Editor 36

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