11/5/01OO Design1 Design Object-Oriented Design. 11/5/01OO Design2 Object-Oriented Design The process of determining the architecture, and specifying

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


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


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)


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!


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.


Subsystem Model

The most common reason of having subsystem is “divide and conquer”

Others reasons are • reuse• dividing the work – CS625/CS630• etc.


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


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


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


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


Design Object Model

Consists of the classes, their attributes, operations, and interrelationships among the classes


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


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)


Notation

See page 285


Design Scenarios

Define system behaviors at a concrete level Include information regarding how to trigger

the scenarios


Design Scenarios: Purposes

Define a complete set of functional specifications that define the externally visible behaviors

Define the assumptions and outcomes of Design OIDs


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!


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


Design Scenarios: Approach #2

Start with Analysis Scenarios Need to make design decision at the

early stage


Design Scenarios: Notation

Name Trigger

• can be a method or a user event

Assumption Outcome Note


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


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


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


Design OID: Techniques (2)

Make sure the parameters and return values are well defined, especially for large systems

Clearly indicate control and threading data


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


Design OID: Notation

Focus of control multitasking process and subsystem boundary

Example on page 302


Design OID: Good News

Only the major design scenarios are documents and developed into Design OID


Design State Models

About the same as the Analysis state model One diagram for each class


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


Rejected Design Alternatives

List the rejected designs decisions with reasons


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

Documents

11/5/01OO Design1 Design Object-Oriented Design. 11/5/01OO Design2 Object-Oriented Design The process of determining the architecture, and specifying