object oriented design
Skip this Video
Download Presentation
Object-Oriented Design

Loading in 2 Seconds...

play fullscreen
1 / 84

Object-Oriented Design - PowerPoint PPT Presentation

  • Uploaded on

Object-Oriented Design. Lesson #13. Note: CIS 601 notes were originally developed by H. Zhu for NJIT DL Program. The notes were subsequently revised by M. Deek. Activities in Software Development. Problem Analysis Solution Design Coding Documenting Testing Maintenance. Strategy.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Object-Oriented Design' - elroy

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
object oriented design

Object-Oriented Design

Lesson #13

Note: CIS 601 notes were originally developed by H. Zhu for NJIT DL Program. The notes were subsequently revised by M. Deek

activities in software development
Activities in Software Development
  • Problem Analysis
  • Solution Design
  • Coding
  • Documenting
  • Testing
  • Maintenance
  • One basic way to deal with complexity: Divide and Conquer.
  • Systems can be divided into modules (Objects or Classes).
  • The challenge is to ensure effective communication between different parts of the program without destroying the divisions.
  • We are concerned with producing software that satisfies user requirements.
  • The primary means to do so is to produce software with a clean internal structure.
the tasks of oo design
The Tasks of OO Design

We need to specify:

  • The needed classes
  • The public interface
  • The protected interface
the need for a clean internal structure
The Need for a Clean Internal Structure

To simplify:

  • Testing
  • Porting
  • Maintenance
  • Extension
  • Re-organization
  • Understanding
characteristics of successful software
Characteristics of Successful Software

It has an extended life where it might be:

  • worked on by a succession of programmers and designers
  • ported to new hardware
  • adapted to unanticipated uses
the development cycle
The Development Cycle
  • Create an overall design
  • Find standard components and then customize the components for this design.
  • Create new standard components and then customize the components for this design.
  • Assemble design.
design for change
Design for Change
  • The system must be designed to remain as simple as possible under a sequence of changes.
  • Aim for:
    • flexibility
    • extensibility
    • portability
  • OOD can support the above.
design steps of ood
Design Steps of OOD
  • Find the Concepts/Classes and their fundamental relationships.
  • Refine the Classes by specifying the sets of Operations on them
    • classify these operations: constructors, destructors, etc.
    • consider minimalism, completeness, and convenience
design steps
Design Steps
  • Refine the classes by specifying their dependencies on other classes:
    • Inheritance
    • Use dependencies
  • Specify the interfaces for the classes:
    • separate functions into public and protected operations
    • specify the exact type of the operations on the classes.
finding classes
Finding Classes
  • Good design must capture and model some aspects of reality.
  • Look at the application rather than the abstractions.
  • Usually nouns correspond to classes and verbs represent functions.
  • When ordering new videotapes from a supplier, the store manager creates a purchase order, fills in the date, the supplier’s name , address, and enters a list ofvideotapes to be ordered. The purchase order is added to a permanent list of purchases. When one or more video tapes are received from a supplier, a clerk locates the original purchase order and makes a record of each tape that was received. A record of the videotape is then added to the store’s inventory. When all tapes listed on a particular purchase order have been received, the manager sends a payment to the supplier and the purchase order is given a completion date.
specifying operations
Specifying operations
  • Consider how an object of the class is constructed, copied, and destroyed.
  • Define the minimal set of operations required by the concept the class is representing.
  • Consider which operations could be added for notational convenience and include only important ones.
specifying operations1
Specifying Operations
  • Consider which operations are to be virtual.
  • Consider what commonality of naming and functionality can be achieved across all the classes of the component.
operations on a class
Operations on a Class
  • Foundation:
    • Constructors, destructors, and copy operators
  • Selectors:
    • Operations that do not modify the state of an object.
  • Modifiers:
    • Operations that modify the state of an object.
operations on a class1
Operations on a Class
  • Conversion Operators:
    • Operations that produce an object of another type based on the value (state) of the object to which they are applied.
  • Iterators:
    • Operations that process data members containing collections of objects.
specifying dependencies
Specifying Dependencies
  • The key dependencies to consider in the context of design are inheritance and use relationships.
  • Overuse can lead to inefficient and incomprehensible designs.
specifying interfaces
Specifying Interfaces
  • Private functions are not considered at this stage.
  • The interface should be implementation independent (more than one implementation should be possible).
  • All operators in a class should support the same level of abstraction.
reorganizing the class hierarchy
Reorganizing the Class Hierarchy
  • Typically, initial organization of classes may not be adequate and therefore, may have to be reorganize to improve the design and/or implementation.
  • The two most common reorganizations of a class hierarchy are:
    • factoring of two classes into a new class.
    • splitting a class into two new ones.
use of models
Use of Models
  • Whenever possible, design and programming should be based on previous work.
  • This allows the designer to focus on a the important issues at any given time.
experimentation and analysis
Experimentation and Analysis
  • Prototyping is frequently used for experimenting.
  • Different aspects of a system may be prototyped independently, such as the graphical user interface.
  • Analysis of a design and/or implementation can be an important source of insight.
example doctor s office scheduling
Example:Doctor’s office scheduling
  • Specification:
    • The program allows to schedule appointments for patients.
    • The office has multiple doctors, each with a daily schedule divided into 15-minute appointment slots beginning from 8:00am to 6:00pm.
    • We also want to print out separate daily schedules for each doctor, listing the time and patient name of each appointment.
    • All output directed to the screen, except for the doctors’ schedules, which will be written to a file for later printing.
    • For simplicity: Each doctor has only one appointment day.
  • Finding classes:
    • Doctor
    • Patient
    • DailySchedule
    • Appointment
    • Scheduler (Interface to the user)
scenario of the process
Scenario of the process
  • Scheduler requests the patient’s name;
  • Patient chooses a doctor;
  • Scheduler displays doctor’s schedule, showing available appointment slots;
  • Patient requests the specific slot;
  • Scheduler adds the appointment to the doctor’s schedule, and adds the appointment to the patient’s record;
  • Scheduler confirms the appointment.
class dependencies
Class dependencies









:link(requests, send messages)

  • Doctor

1. AddToSchedule: Add an appt. to the Dr’s Sch.

2. ShowAppointment:Display the sch

  • Patient




4.SetAppointment: Schedule an Appt.

  • DailySchedule

1.SetAppointment: Add an appt to the sch.

2.IsTimeSlotFree:Find out if a particular slot is available

3.ShowAppointments: Display the schd appt

  • Appointment


2.IsScheduled: Find out if an appt schd for the current Appt

  • Scheduler

1.ScheduleOneAppointment: p-appt-d

2.ScheduleAllAppointments:input p, request d, update d

3.PrintAllAppointment: print all the schd appt for all Ds

additional classes
Additional Classes
  • TimeSlot:
    • Handles the translation and formatting of appointment times.
  • FString:
    • Deals with string data members.
the timeslot class
The TimeSlot class

class TimeSlot {


TimeSlot( const unsigned n = 0 );

unsigned AsInteger() const;

friend istream & operator >>(istream & inp, TimeSlot & T);

friend ostream & operator <<(ostream & os, const TimeSlot & T);


static unsigned StartHour;

static unsigned ApptLen;

unsigned intValue;


the appointment class
The Appointment class

class Appointment {



Appointment ( const TimeSlot & aTime,

unsigned docNum, const Patient & P);

const FString & GetPatientName() const;

const TimeSlot & GetTime() const;

int IsScheduled() const;

void SetTime( const unsigned n );

friend ostream & operator <<( ostream & os,const Appointment & A );


enum { NoDoctor = 9999 };

unsigned doctorNum;

TimeSlot timeSlot;

FString patientName;


the patient class
The Patient class

class Patient {



void InputName();

unsigned ChooseDoctor() const;

TimeSlot ChooseTimeSlot(const Doctor & D) const;

const Appointment & GetAppointment() const;

const FString & GetFirstName() const;

const FString & GetLastName() const;

int IsScheduled() const;

void SetAppointment( const Appointment & A );

friend ostream & operator <<( ostream & os, const Patient & P );


FString lastName;

FString firstName;

Appointment nextVisit;


the dailyschedule class
The DailySchedule class

class DailySchedule {



int IsTimeSlotFree( const TimeSlot & T ) const;

void SetAppointment( const Appointment & A );

void ShowAppointments( ostream & os ) const;

friend ostream & operator <<( ostream & os,

const DailySchedule & DS );


enum { MaxTimeSlots = 40 };

Appointment appointments[MaxTimeSlots];


the doctor class
The Doctor class

class Doctor {



int AddToSchedule( const Appointment & A );

const DailySchedule & GetSchedule() const;

void SetId( const unsigned );

void SetLastName( const FString & L );

const FString & GetLastName() const;

void ShowAppointments( ostream & ) const;

static const FString & GetDoctorName( unsigned index );

static void SetDoctorName(unsigned, const FString & nam);


unsigned id;

FString lastName;

DailySchedule schedule;

static FString doctorName[NumDoctors];


the scheduler class
The Scheduler class

class Scheduler {


Scheduler( Doctor * docs );

void PrintAllAppointments( const char * fileName);

int ScheduleOneAppointment();

void ScheduleAllAppointments();


Doctor * doctors;


the main program
The main Program

#include "doctors.h"

static Doctor doctorArray[NumDoctors];

int main()

{ cout << "Doctors Office Scheduling Program\n\n";

Scheduler officeSchedule( doctorArray );


officeSchedule.PrintAllAppointments( "appts.txt" );

return 0;


the implementation
The Implementation
  • The Time Slot
  • h : hour value
  • sa: the starting appointment time
  • aph: appointments per hour
  • m: minute value
  • al: the appointment length in minutes

timeslot = (h-sa)*aph+m/al

E.g: timeslot = (12-8)*4+20/15=17

The 17th slot.

the timeslot class1
The TimeSlot class

unsigned TimeSlot::StartHour = 8;

unsigned TimeSlot::ApptLen = 15;

istream & operator >>( istream & inp, TimeSlot & T )

{ char buf[20];

inp.getline( buf, 20 ); // get a line of input

istrstream aStream( buf, 20 );

unsigned h, m;

char ch;

aStream >> dec >> h >> ch >> m;

unsigned aph = 60 / TimeSlot::ApptLen;

if( h < T.StartHour ) // afternoon hour?

h += 12; // add 12 to hours

T.intValue = ((h - TimeSlot::StartHour)* aph) + (m / TimeSlot::ApptLen);

return inp;


the timeslot class2
The TimeSlot class

ostream & operator <<( ostream & os, const TimeSlot & T )

{ unsigned aph = 60 / T.ApptLen; // 4 = 60 / 15

unsigned h = (T.intValue / aph ) + T.StartHour; // (S / 4) + 8

unsigned m = (T.intValue % aph ) * T.ApptLen; // (S % 4) * 15

char oldfill = os.fill('0');

os << setw(2) << h << ':' << setw(2) << m;

os.fill( oldfill );

return os;


the appointment class1
The Appointment class

Appointment::Appointment ( const TimeSlot & aTime,

unsigned docNum, const Patient & aPatient )


timeSlot = aTime;

doctorNum = docNum;

patientName = aPatient.GetLastName();

patientName.Append( ", " );

patientName.Append( aPatient.GetFirstName() );


the appointment class2
The Appointment class

ostream & operator <<( ostream & os, const Appointment & A )


os << "Dr. "

<< Doctor::GetDoctorName(A.doctorNum) << ", "

<< "Time: "

<< A.timeSlot;

return os;


the patient class1
The Patient class

void Patient::InputName()

{ cout << "Patient's last name: ";

cin >> lastName;

cout << "Patient's first name: ";

cin >> firstName;


the patient class2
The Patient class

unsigned Patient::ChooseDoctor() const

{ for(unsigned i = 0; i < NumDoctors; i++)

cout << i << ": " << Doctor::GetDoctorName(i) << '\n';

unsigned n = 0;

int ok = 0;

do {

cout << "Enter a doctor number: ";

cin >> n;


if( n >= NumDoctors )

cout << "Number out of range!\n";


ok = 1;

} while( !ok );

return n;


the patient class3
The Patient class

TimeSlot Patient::ChooseTimeSlot( const Doctor & D ) const

{ cout << '\n'

<< "Daily Schedule of Dr. " << D.GetLastName() << '\n'

<< "........................................" << '\n'

<< D.GetSchedule() << '\n'

<< "Enter a time (format hh:mm): ";

TimeSlot aSlot;

cin >> aSlot;

return aSlot;


the patient class4
The Patient class

ostream & operator <<( ostream & os, const Patient & P )


os << "Patient " << P.firstName << ' '

<< P.lastName << '\n'

<< "has been scheduled as follows:" << '\n'

<< P.nextVisit << endl;

return os;


the dailyschedule class1
The DailySchedule class


{ for(unsigned i = 0; i < MaxTimeSlots; i++)

appointments[i].SetTime( i );


int DailySchedule::IsTimeSlotFree( const TimeSlot & aTime ) const

{ unsigned n = aTime.AsInteger();

return !appointments[n].IsScheduled();


void DailySchedule::SetAppointment( const Appointment & app )

{ unsigned n = app.GetTime().AsInteger();

appointments[n] = app;


the dailyschedule class2
The DailySchedule class

void DailySchedule::ShowAppointments( ostream & os ) const


for(unsigned i = 0; i < MaxTimeSlots; i++)


if( appointments[i].IsScheduled())

os << appointments[i].GetTime() << " "

<< appointments[i].GetPatientName()

<< endl;



the dailyschedule class3
The DailySchedule class

ostream & operator <<( ostream & os, const DailySchedule & DS )

{ for(unsigned i = 0; i < DS.MaxTimeSlots; i++)


os << DS.appointments[i].GetTime();

if( DS.appointments[i].IsScheduled())

os << " *** ";


os << " ";

if( i % 4 == 3 ) os << '\n';


return os;


the doctor class1
The Doctor class

FString Doctor::doctorName[NumDoctors]; //Static member.


{ id = 0;}

int Doctor::AddToSchedule( const Appointment & app )

{ if( schedule.IsTimeSlotFree( app.GetTime()))

{ schedule.SetAppointment( app );

return 1;


return 0;


the doctor class2
The Doctor class

void Doctor::ShowAppointments( ostream & os ) const


os << "Appointments for Dr. "

<< lastName << '\n'

<< ".................................."

<< '\n';

schedule.ShowAppointments( os );

os << endl;


booch s ood
Booch’s OOD
  • Booch-93 Notations
  • An object is an entity that has a:
    • A.state: attributes
    • B.behavior: the operations
    • C.Identity: each instance is unique
booch 93 notations

rate, status, settings;

tranmit(), receive(), and status()

Booch-93 Notations

Class name

1.A class: Modem

Class attributes(data)

Methods,operations or functions

Dashed line symbolizes a class

booch 93 notations1





Hard Disk

Floppy Disk

Booch-93 Notations
  • A B: Class A and B are associated

:Abstract Type


booch 93 notations2





Hard Disk

Floppy Disk




Booch-93 Notations
  • A B: Class A is-a Class B(inherits)
  • A B: Class A has a Class B (contains)
  • A B: Class A uses Class B (send messages)
booch 93 notations3
Booch-93 Notations
  • Process diagram
  • Category diagram
  • Module diagram
  • Class diagram
  • Class specification
  • Object diagram
  • State Transaction diagram
  • Interaction diagram

Static Model

Dynamic Model

module diagram
Module diagram
  • The module diagram presents a high-level view of the system
  • and partitions a system in terms of subsystems and modules;
  • A subsystem is a collection of modules;
  • A module is a collection of classes.

Body name




Main program





B:Module A is dependent on module B

module diagram1
Module diagram

User Interface Subsystem


Is dependent on


Repair Manuals

Maintenance log

Spare Parts


Maintenance subsystem

category diagram
Category diagram
  • The category diagram facilitates the presentation and partitioning of a subsystem and module into logical and cohesive categories.
  • A category organizes a group of classes in a set.
category diagram1
Category Name


Category diagram

Spare Parts



Spare Parts List


Spare Parts List

Spare Parts on order


class diagram
Class diagram
  • A class diagram is used to show the relationships between the classes.
    • Containment: Identify how a system class maintains its subsystem class: external & internal.
    • Cardinality: specify the number of instances associated classes.
      • Exactly one: 1
      • 0 or more : n, 0..n
      • 1 or more:1..n
      • Range: 10..30
      • Range or number:2..4, 8
class diagram1
Class diagram
  • Properties: is enclosed in an upside-down triangle.
    • Abstract
    • Friend
    • virtual
  • Expert controls: identify access levels.
    • Public
    • Protected
    • Private
    • Implementation.
class diagram2



Class diagram

:Abstract Type



:Virtual Type

:Friend Type


Internal Containment

External Containment





state transaction diagram
State Transaction Diagram
  • Defines the dynamic behavior of an object by identifying
  • possible states. Identifies the events and operations that cause the object to transition from one state to another.
    • An event occurs
    • Guarded Condition is evaluated
    • Action is performed
    • State transition takes place








Initialize Modem Steam


. Do configure modem for receive/transmit

. Do initialize modem buffer/pointers

.Do synchronize communications






.Do store data in modem buffer


[modem buffer not empty]



.Do transmit data a byte a time

[modem buffer is empty]


.Do flush modem buffer

.Do release phone line

.Do disable modem interrupt

.Do reset hardware

[buffer overflow]

/set comm. status


[time out]/set comm. status


.Do log error conditions


interaction diagram
Interaction Diagram
  • Traces events within a design and defines the messages
  • (operations and events) between the objects.











Work Assignment



deliver product


Report sales

Lay off()

object diagram
Object Diagram
  • Presents the same information as the interactive diagram except that it shows greater details
    • Interaction
    • Synchronization
    • Role
    • Visibility
    • Data flow
    • Direction






object diagram1
XObject Diagram


Simple: to depict a single thread control

Synchronous: the operation that takes place after

the target object accepts the request.

Timeout: the operation must be completed within

a specified amount of time

Asynchronous: sends a message, continues without waiting

Balking: the message is passed only if the target is ready

to receive it. The operation is abandoned if not ready







1:Work Assignment

7:Lay off()

6:Report Sales


4:deliver Product


maintenance for object oriented software
Maintenance for Object-Oriented Software
  • Object-Oriented paradigm promotes maintenance
      • Product consists of independent units
      • Encapsulation (conceptual independence)
      • Information hiding (physical independence)
      • Message-passing is sole communication
  • Three obstacles
    • Complete inheritance hierarchy can be large
    • Consequences of polymorphism and dynamic binding
    • Consequences of inheritance
size of inheritance hierarchy
Size of Inheritance Hierarchy

class UndirectedTree { ...

void displayNode (Node a);

... }

class DirectedTree public: UndirectedTree {


class RootedTree public: DirectedTree { ...

void displayNode (Node a);



size of inheritance hierarchy1
Size of Inheritance Hierarchy

class BinaryTree public: RootedTree {

… }

class BalancedBinaryTree public: BinaryTree {

Node hhh;

displayNode (hhh);


size of inheritance hierarchy2
Size of Inheritance Hierarchy
  • To find out what displayNode does in BalancedBinaryTree
    • Must scan entire tree
    • Inheritance tree may be spread over entire product
    • Opposite to ”independent units”
  • Solution
    • CASE tools can flatten inheritance tree
consequences of inheritance
Consequences of Inheritance
  • Create new subclass by inheritance
    • Does not affect superclasses
    • Does not affect any other subclasses
  • Modify this new subclass
    • Again, no affect
  • Modify a superclass
    • All descendent subclasses are affected
consequences of inheritance1
Consequences of Inheritance
  • Inheritance can have
    • positive effects on development,
    • negative effects on maintenance
polymorphism and dynamic binding
Polymorphism and Dynamic Binding
  • Product fails on invocation myFile.open ()
  • Which version of open contains the fault?
    • CASE tool cannot help (static tool)
    • must trace, need run-time tracer (debugger).
  • Polymorphism and dynamic binding can have
    • positive effect on development,
    • negative effect on maintenance
software maintenance
Software Maintenance
  • Usually means redesign and re-implementation.
  • When flexibility, extensibility, and portability are emphasized in the design, maintenance problems can be addressed easily.
re use
  • code re-use and design are often reasons behind choosing a new programming language or a new design strategy.
  • Not enough emphasis is placed on re-use:
    • productivity measured in lines of code.
    • managers may be valued by the size of their group.
    • profit may be a percentage of the development cost.
software re use
Software Re-use
  • Software is reusable if:
    • it works
    • it is comprehensible
    • it can co-exist with other software not written to co-exist with.
    • it is supported
    • it is economical (maintenance cost)
  • Object-Orientation supports re-use, but need tools and standards, such as COM/OLE, CORBA.
readings assignments
Readings & Assignments
  • Reading:
    • Chapter 5