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

OO Design Pyramid

Supports hardware/softwaresystem mapping (packages)

Class definitions, hierarchies,generalizations (modules)

External and internal interfaces(module coupling)

Data structure & algorithm design for attributes & operations (detailed design)

[From SEPA 5/e]

incre

asin

g d

eta

il

OOA to OOD[From SEPA 5/e]

Subsystem Design System Decomposition

• 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

F:SubsystemE:Subsystem G:Subsystem

D:SubsystemC:SubsystemB:Subsystem

A: Subsystem Layer 1

Layer 2

Layer 3

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

VM4

VM3

VM2

VM1C1attropr

C1attropr

C1attropr

C1attropr

C1attropr

C1attropr

C1attropr

C1attropr

Problem

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

Closed Architecture (Opaque Layering)

A virtual machine can only call operations from the layer below

Goal: High maintainability

VM4

VM3

VM2

VM1C1

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

Open Architecture(Transparent Layering)

A virtual machine can call operations from any layers

Goal: Runtime efficiency

VM4

VM3

VM2

VM1C1

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

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

TIER 1:CLIENT

TIER 2:SERVER

TIER 3:BACKEND

Application serveroffloads processing

to tier 3

Intershop Architecture

SOURCE: INTERSHOP

Selligent Architecture

SOURCE: SELLIGENT

KMT Packages &HW/SW Mapping

•Special Purpose•Build (Custom)•Dual P3 rack•TCP/IP Network•C++

Analyzer

•Special Purpose•Build (Custom)•Dual P3 rack •TCP/IP Network•C++

Generator

•Special Purpose•Build (Custom)•Typical PC•TCP/IP Network•JDK 1.2.1

KMT Client

Contracts How subsystems interact:

• List requests

• For each request, indicate which operations are needed to implement

• Create a collaboration table orcollaboration 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[From SEPA 5/e]

public String getResult(String s){};

WORK 18 Remove the engine.

e.g., Java Class API(method signatures)

e.g., string-basedmessage protocol

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, characteristicsthe nature of the class

• responsibilitiesfunctions provided by the class

• collaboratorspart-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-ViewDesign Pattern:Separate internalrepresentation fromhow data is displayedto the user

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 commentsexample: Collections.sort()

Questions?