Object oriented design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 84

Object-Oriented Design PowerPoint PPT Presentation


  • 91 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Object-Oriented Design

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


Strategy

Strategy

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


Objectives

Objectives

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


Example

Example

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


Analysis

Analysis

  • 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

Scheduler

Fstring(LastName)

Patient

Doctor

Fstring(FirstName)

DailySchedule

Appointment

:composite(contains)

:link(requests, send messages)


Operations

Operations

  • Doctor

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

    2. ShowAppointment:Display the sch

  • Patient

    1.InputName:

    2.ChooseDoctor:

    3.ChooseTimeSlot:

    4.SetAppointment: Schedule an Appt.


Operations1

Operations

  • 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

    1.Constructor:

    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 {

public:

TimeSlot( const unsigned n = 0 );

unsigned AsInteger() const;

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

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

private:

static unsigned StartHour;

static unsigned ApptLen;

unsigned intValue;

};


The appointment class

The Appointment class

class Appointment {

public:

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

private:

enum { NoDoctor = 9999 };

unsigned doctorNum;

TimeSlot timeSlot;

FString patientName;

};


The patient class

The Patient class

class Patient {

public:

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

private:

FString lastName;

FString firstName;

Appointment nextVisit;

};


The dailyschedule class

The DailySchedule class

class DailySchedule {

public:

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

private:

enum { MaxTimeSlots = 40 };

Appointment appointments[MaxTimeSlots];

};


The doctor class

The Doctor class

class Doctor {

public:

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

private:

unsigned id;

FString lastName;

DailySchedule schedule;

static FString doctorName[NumDoctors];

};


The scheduler class

The Scheduler class

class Scheduler {

public:

Scheduler( Doctor * docs );

void PrintAllAppointments( const char * fileName);

int ScheduleOneAppointment();

void ScheduleAllAppointments();

private:

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.ScheduleAllAppointments();

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;

cin.ignore(255,'\n');

if( n >= NumDoctors )

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

else

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

DailySchedule::DailySchedule()

{ 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 << " *** ";

else

os << " ";

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

}

return os;

}


The doctor class1

The Doctor class

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

Doctor::Doctor()

{ 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;

}//cis601source/chap5/doctors/


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

Modem

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

Mouse

Computer

Processor

Memory

Disk

Hard Disk

Floppy Disk

Booch-93 Notations

  • A B: Class A and B are associated

:Abstract Type

A


Booch 93 notations2

Mouse

Computer

Processor

Memory

Disk

Hard Disk

Floppy Disk

Printer

Monitor

Keyboard

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

(.cpp)

Specification

Name(.h)

Main program

name

Subsystem

names

A

B:Module A is dependent on module B


Module diagram1

Module diagram

User Interface Subsystem

GUI

Is dependent on

Aircraft

Repair Manuals

Maintenance log

Spare Parts

Multimedia

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

Class

Category diagram

Spare Parts

List

F16

Spare Parts List

F15

Spare Parts List

Spare Parts on order

gloabal


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

F-14

Engine

Wheel

Class diagram

:Abstract Type

V

A

:Virtual Type

:Friend Type

F

Internal Containment

External Containment

1

1

3

2


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

Start

Event[condition]/action

State

activities

Stop


Example1

Example

Start

Initialize Modem Steam

Setup

. Do configure modem for receive/transmit

. Do initialize modem buffer/pointers

.Do synchronize communications

Idle

Terminate()

Transmit()

Receive()

Receiving

.Do store data in modem buffer

Transmit

[modem buffer not empty]

Receive()

Transmitting

.Do transmit data a byte a time

[modem buffer is empty]

Termination

.Do flush modem buffer

.Do release phone line

.Do disable modem interrupt

.Do reset hardware

[buffer overflow]

/set comm. status

Transmit

[time out]/set comm. status

Error

.Do log error conditions

Stop


Interaction diagram

Interaction Diagram

  • Traces events within a design and defines the messages

  • (operations and events) between the objects.

Object

Object

Time

Events

Operation()


Example2

Example

Engineer

Marketing

Manager

Customer

Work Assignment

Design()

Review()

deliver product

Sell()

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

Order:message

Target

Object

Source

Object


Object diagram1

X

Object Diagram

Synchronization:

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


Example3

Engineer

Customer

Marketing

Manager

Example

3:Review()

1:Work Assignment

7:Lay off()

6:Report Sales

2:Design()

4:deliver Product

5:Sell()


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


Obstacles

Obstacles

  • 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

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


  • Login