Lecture 18: Object-Oriented Design Software Engineering Lecture 18: Object-Oriented Design

Today’s Topics Chapter 22, SEPA/5e (also: Bruegge & Dutoit, Object-Oriented Software Engineering) Subsystem Design & Architectures Class & Object Design Message Design Responsibility Design

Data structure & algorithm design for attributes & operations (detailed design) increasing detail External and internal interfaces (module coupling) Class definitions, hierarchies, generalizations (modules) Supports hardware/software system mapping (packages) OO Design Pyramid [From SEPA 5/e]

OOA to OOD [From SEPA 5/e]

Subsystem Design System Decomposition Hardware / Software Mapping Layers & Partitioning (packages) Cohesion / Coupling Hardware / Software Mapping Special Purpose Buy/Build Resource Allocation Connectivity

Coupling and Cohesion Goal: Reduce complexity Cohesion measures dependence among classes High cohesion: classes in a subsystem perform similar tasks and are related via associations Low cohesion: miscellaneous objects, no associations

Coupling & Cohesion [2] Coupling measures dependencies between subsystems High coupling: Changes to one subsystem have high impact on the other subsystem Design should maximize cohesion and minimize coupling: How can we partition an O-O system to achieve loose coupling?

Partitions and Layers Partitions are independent (weakly-coupled) subsystems that provide services on the same level of abstraction Layers are subsystems that provide services to a higher level of abstraction Layers only depend on lower layers, have no knowledge of higher layers In an object-oriented design such as JEWEL, each subsystem makes its layer a subclass of the generic layer class provided by the UI subsystem. Each individual subsystem must provide for its own zoom and refresh methods. Ideally the refresh method will be called for every draw operation. The UI subsystem is responsible for knowing when to call for a refresh (but the UI group will not have to implement it itself: it is a callback method implemented by the visualization and GIS group). All the interfaces with UI (such as how UI will provide the other groups with selection information) should be well documented and agreed on by all groups.

Layer Example Decomposition Heuristics No more than 7+/-2 subsystems More subsystems increase coherence but also complexity (more services) No more than 5+/-2 layers

Subsystem Relationships Layer relationships A calls B (runtime) A depends on B (compile time) Partition relationships Subsystems have mutual but not deep knowledge about each other A calls partition B and B calls A

Virtual Machine (Dijkstra, 1965) Systems are layers of virtual machines Problem VM1 C1 C1 C1 attr attr attr opr opr opr C1 C1 VM2 attr attr opr opr C1 VM3 C1 attr attr opr opr C1 VM4 attr opr Existing System

Virtual Machine An abstraction providing attributes and operations A subsystem connected to higher- and lower-level virtual machines by provides services for associations Can implement two types of software architecture: closed and open architectures A virtual machine can be seen a collection of classes instead of a single class. This module uses services provided by lower level virtual machines and provides a service to higher level machines Key concept in structuring and providing abstraction, but slightly out of out of date, cannot deal with distributed architectures. Works still well for single processor architectures (tasks)

Closed Architecture (Opaque Layering) A virtual machine can only call operations from the layer below Goal: High maintainability VM4 VM3 VM2 VM1 C1 attr op

Open Architecture (Transparent Layering) A virtual machine can call operations from any layers Goal: Runtime efficiency C1 attr op C1 attr op C1 attr op VM1 C1 attr op C1 attr op VM2 C1 attr op C1 attr op VM3 C1 attr op C1 attr op VM4

Open vs. Closed Architectures Layered systems are desirable hierarchy reduces complexity Closed architectures more portable Open architectures can be more efficient Prefer closed architecture, unless performance constraints require an open architecture

Hardware / Software Mapping Each layer (subsystem, virtual machine) can reside on a different hardware / software platform Subsystem decomposition is the basis for multi-tier architecture client-server web server / application server / database server can improve security as well as maintainability

Typical 3-Tier Web Architecture CLIENT TIER 2: SERVER TIER 3: BACKEND Application server offloads processing to tier 3

Intershop Architecture SOURCE: INTERSHOP

Selligent Architecture SOURCE: SELLIGENT

KMT Packages & HW/SW Mapping Analyzer Special Purpose Build (Custom) Dual P3 rack TCP/IP Network C++ KMT Client Special Purpose Build (Custom) Typical PC TCP/IP Network JDK 1.2.1 Generator Special Purpose Build (Custom) Dual P3 rack TCP/IP Network C++ KMT Packages & HW/SW Mapping

Contracts How subsystems interact: Contracts include message format List requests For each request, indicate which operations are needed to implement Create a collaboration table or collaboration graph, depending on the complexity of the contract Contracts include message format method call (for objects) structured data (other protocols)

Collaboration Table [From SEPA 5/e]

Types of Contracts WORK 18 Remove the engine. e.g., string-based message protocol WORK 18 Remove the engine. e.g., Java Class API (method signatures) public String getResult(String s){}; Types of Contracts [From SEPA 5/e]

Collaboration Graph [From SEPA 5/e]

Object & Class Design Refine the details of classes using: Sequence Diagrams CRC Cards Goal: Completed Class Diagram attributes (fully typed) methods (full signatures) associations (inheritance, aggregation, etc.)

Class-Reponsibility-Collaborator Abbreviation: CRC Cards Identify and organize class details “Index Cards” approach: name, type, characteristics the nature of the class responsibilities functions provided by the class collaborators part-of, knowledge-of, depends-on

CRC Index Card [From SEPA 5/e]

CRC Formal Review Distribute index cards to reviewers Use cases grouped into categories Read each use case, passing a token from one person to another when a class is named Holder of the class card reads responsibilities, which are reviewed by all Cards refined as necessary

Class Diagram for KMT Client Model-View Design Pattern: Separate internal representation from how data is displayed to the user Class Diagram for KMT Client

Detailed Design Internal data structures and program logic for each method signature identified in the detailed class diagram Pseudocode/PDL, flowcharts, etc. Java: Specify algorithm & data structures in javadoc comments example: Collections.sort()

Questions?