Upload
stanley-caldwell
View
230
Download
2
Tags:
Embed Size (px)
Citation preview
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?