11/5/01 OO Design 1
Design
Object-Oriented Design
11/5/01 OO Design 2
Object-Oriented Design
The process of • determining the architecture, and
• specifying the classes needed to implement a software product in
CONCURRENTLY
11/5/01 OO Design 3
Design In General
Transfer the results of analysis phase into the design of a software solution
Define the overall S/W architecture For OO Design
• Non-private attributes, operations, and algorithms are defined for design objects
• Implementation-oriented new objects are defined
11/5/01 OO Design 4
More About Design
The boundary between design and implementation is both flexible and subjective
The goal of design is to achieve sufficient agreement on interface definition and internal structure that implementation work may then BE proceed independently in parallel
11/5/01 OO Design 5
Design Work Products Design Guidelines System Architecture APIs Target Environment Sub-system model Design Object Model Design Scenarios Design Object Interaction Diagrams Design State Models Design Class Descriptions Rejected Design Alternatives Database tables
Milestone #6
Milestone #7
11/5/01 OO Design 6
Design Guidelines
A set of rules that help in defining the design deliverables and guiding the design process
Extension of analysis guidelines Recycle as much as possible Address the work products apply to design
11/5/01 OO Design 7
System Architecture The set of project wide design decisions Should cover the following areas
• Structure-- how to layer and partition the S/W• Communication patterns among the components• Other communication issues• distribution • Persistence• Security• Error handling• Recovery• H/W and S/W configurations
11/5/01 OO Design 8
More On System Architecture
Created by the “Project Architect” Restricts what a developer can do May include assumptions
• For example, “Use VBScript on all the ASP pages except the first page, assuming client environment is IE4 or later.”
Nonfunctional requirements may affect this part greatly
11/5/01 OO Design 9
Examples On System Architecture
Structure-- how to layer and partition the S/W• Show the software layers such as ODBC
Communication patterns among the components• Specify all the inter-component communication is
achieved through the database Other communication issues
• Client to server communication using HTTP (TCP/IP) Distribution
• Using DBMS’ replication feature Persistence
• All the persistence data should be stored in the database
11/5/01 OO Design 10
Examples On System Architecture Security
• Users need to be authenticated through LDAP Error handling
• Critical sections need to use try … catch … final structure
Recovery• Relay on the database to provide check point • Use “transaction” operation to make data changes are
atomic Debugging
• Each class need to provide a method “displayState” that prints out the values of all the members.
H/W and S/W configurations• Client environment is IE6 or later, Win3264 OS, X86 CPU, etc
11/5/01 OO Design 11
APIs
One of the two• Application Programming Interfaces• Architecture Program Interface
One view of APIs are that they are a collection of public methods
This view enable the sub/system to be used without the needs to understand a class’ internal details, especially for applications that provide some services
11/5/01 OO Design 12
Target Environment
The environment in which the application will operate
Come from non-functional requirements It should specify
• H/W• OS• runtime environment
It should provide specifications for both clients and servers (database, IIS, etc)
11/5/01 OO Design 13
Target Environment
This work product ensures that both the user and the system architect share a common understanding of the operating environment
For distributed system you need to specify all the possible clients and servers, especially clients!
Users’ opinions count here!
11/5/01 OO Design 14
Subsystem Model
Is a partitioning of a system into subsystems and delegation of system responsibilities.
There are many ways to divide the system. A subsystem may contain sub-subsystem. A subsystem model identifies existing
subsystems that are to be reused as well as those that need to be constructed.
11/5/01 OO Design 15
Subsystem Model
The most common reason of having subsystem is “divide and conquer”
Others reasons are • reuse• dividing the work – CS625/CS630• etc.
11/5/01 OO Design 16
How To Partition A System
Developed V.S. under-developing Already divided at the analysis phase Divided by physical boundaries
• For example, Staff, Student, classes
After Design Object Model for less amount of communication
11/5/01 OO Design 17
More About Sub-system
Once a subsystem is identified, it is treated as a system in its own right• May have its own workbook
Subsystem model shows the interaction among sub systems
Each use case must be mapped into a subsystem or subsystems
Most use cases should be contain with a single subsystem
11/5/01 OO Design 18
The Subsystem Model Includes 1. Subsystem diagram
• A. subsystems• B. contracts
2. For each subsystem• A. Name• B. Description• C. Contracts
2. For each contract• A. Name• B. Description• C. API• D. Notes
11/5/01 OO Design 19
Subsystem can be larger enough to have its own workbook
Balancing the amount of work should not be a Criterion for partition a system. However, that is what you will do because CS430
Subsystem Model
11/5/01 OO Design 20
Design Object Model
Consists of the classes, their attributes, operations, and interrelationships among the classes
11/5/01 OO Design 21
Design Object Model
Document the static aspect of an OO solution to a problem
Shows the structure of the software system, not the problem domain
An analysis class may be mapped into two or more classes. For example• One for data processing • One for data presentation
May introduce new classes• Security
11/5/01 OO Design 22
Design Object Model
Start with Analysis Object Model Add new classes for views and utilities May consult with Design OID and Design
State Models for completeness/correctness Consider subclass carefully May need to consider accessibility (public,
protected, private)
11/5/01 OO Design 23
Notation
See page 285
11/5/01 OO Design 24
Design Scenarios
Define system behaviors at a concrete level Include information regarding how to trigger
the scenarios
11/5/01 OO Design 25
Design Scenarios: Purposes
Define a complete set of functional specifications that define the externally visible behaviors
Define the assumptions and outcomes of Design OIDs
11/5/01 OO Design 26
Design Scenarios: Approaches
Approach #1 (emphasize on mechanisms). Transform Analysis OIDs into Design OIDs, then transform the corresponding Analysis scenarios
Approach #2 (emphasize on interfaces). Transform Analysis scenarios first, then analysis OIDs.
IBM recommends approach #1 Key: Scenarios and OIDs are closely linked!
11/5/01 OO Design 27
Design Scenarios: Approach #1
Working on Design OIDs based on Analysis OIDs.
Once a Design OID is created, its corresponding Design Scenario is created or updated
11/5/01 OO Design 28
Design Scenarios: Approach #2
Start with Analysis Scenarios Need to make design decision at the
early stage
11/5/01 OO Design 29
Design Scenarios: Notation
Name Trigger
• can be a method or a user event
Assumption Outcome Note
11/5/01 OO Design 30
Design Scenarios: Example
Name: User rents a tape Trigger: a correct video id is entered Assumption:
• A rental object is defined (REN_getRenalID() returns not null)
• The video is available (VID_videoAvailable(Vid) returns true)
Outcome • Video count decrement(VID_VideoCountDecrease(Vid))
• Tape is recorded rented by user (REN_AddTape(RID, VID))
Note• id can either be entered by an employee or bar code reader
11/5/01 OO Design 31
Design Object Interaction Diagrams (OIDs)
Is used for dynamic modeling Is a graphical representation of object
collaborations Involve newly added classes for control,
interface, communication, distribution, and storage (may come from reusable code)
Is architecture driven• Client/Server implementation should be different
from desk top implementation
11/5/01 OO Design 32
Design OID: Techniques
Start with everything you have:• use cases, analysis and design scenarios, and analysis OIDs
Consider the responsibilities of newly added design classes
Reflect the interaction among objects in Design Object Model
Always start with a task and ask: which object can handle this task
11/5/01 OO Design 33
Design OID: Techniques (2)
Make sure the parameters and return values are well defined, especially for large systems
Clearly indicate control and threading data
11/5/01 OO Design 34
Design OID: Techniques (3)
Have the group work on a couple together Have every group member work on several Have another meeting to review the results Update the Design Object Model, if
necessary
11/5/01 OO Design 35
Design OID: Notation
Focus of control multitasking process and subsystem boundary
Example on page 302
11/5/01 OO Design 36
Design OID: Good News
Only the major design scenarios are documents and developed into Design OID
11/5/01 OO Design 37
Design State Models
About the same as the Analysis state model One diagram for each class
11/5/01 OO Design 38
Design Class Descriptions
Very much the same as analysis class descriptions
For developers map out members and methods for
• public • protected• private
See book for notation changes
11/5/01 OO Design 39
Rejected Design Alternatives
List the rejected designs decisions with reasons
11/5/01 OO Design 40
Database Design
Not from IBM Define all the tables
• The name• Columns• Data type and size of all columns• Restrictions on all columns (default value, initial value,
allow NULL, etc)• Key• Foreign keys
Other important business rules