Presentation is loading. Please wait.

Presentation is loading. Please wait.

Lecture 18: Object-Oriented Design

Similar presentations


Presentation on theme: "Lecture 18: Object-Oriented Design"— Presentation transcript:

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

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

3 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]

4 OOA to OOD [From SEPA 5/e]

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

6 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

7 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?

8 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.

9 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

10 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

11 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

12 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)

13 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

14 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

15 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

16 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

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

18 Intershop Architecture
SOURCE: INTERSHOP

19 Selligent Architecture
SOURCE: SELLIGENT

20 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

21 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)

22 Collaboration Table [From SEPA 5/e]

23 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]

24 Collaboration Graph [From SEPA 5/e]

25 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.)

26 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

27 CRC Index Card [From SEPA 5/e]

28 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

29 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

30 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()

31 Questions?


Download ppt "Lecture 18: Object-Oriented Design"

Similar presentations


Ads by Google