BCA SEM IV

Object Oriented Design – Chapter 5

Subject Material

Contents In this unit:

o Steps of object-oriented design, Creating design diagrams:
o Interaction diagrams, Sequence diagrams, Collaboration
diagrams
o Refinement of use case description and classes and relationships
o Identification of operations for implementations
o Detailed class diagram and design document, Generating test
cases from use cases
o Object-oriented design principles for improving software quality
o Moving towards implementation: activity diagrams and state
chart diagrams, storing persistent data in database
o Implementing the classes

Chapter Coverage: Object Oriented Design

Reference Book Singh Y., Malhotra R., Object oriented Software Engineering

Juhi Patel Page 1 of 22

 BCA SEM IV

INTRODUCTION

In chapter 2, we saw Object oriented software development life cycle:[ page 44 ].

This lifecycle has four phases which is different from the traditional SDLC.

OO requirement analysis

OO analysis

OO design

OO programming and testing

Purpose of each phase

OO requirement analysis

Capture requirements, create IRD and produce SRS

OO analysis (Static aspect of the system)

Define and analysis of classes and its types

Define and analysis of objects and relationships

Modeling of classes and creating class diagram

OO design (Dynamic aspect of the system)

Refine objects in detail (w.r.t programming languages, databases,

communication protocols)

Implement interactions among objects

Juhi Patel Page 2 of 22

 BCA SEM IV
Need of OOD phase
o In analysis phase, maintainable ideal model is created. Classes are not designed as per
implementation environment.
o The objects and relationships must be refined.
o Operations must be refined and updated according to the messages sent.
o Classes and relationships must be verified

Steps in OOD phase

1. Creation of interaction diagrams for each scenario.

a. Creation of sequence diagram
i. Identification of actor, objects and messages in a scenario.
ii. Identification of objects lifeline, focus of control and sequence of interaction.
iii. Refinement of sequence diagram

b. Creation of collaboration diagram

i. Identification of objects, links and messages.
ii. Identification of structural relationships between objects
iii. Identification of sequence of objects.

2. Refinement of classes and relationships identified in OOA phase.

a. Identification of operations from the sequence diagram
b. Construction of a detailed class diagram
c. Development of a detailed design
d. Creation of software design document
e. Generation of test cases from use cases.

Interaction diagrams
o Depicts communications between set of objects through message passing for each
scenario of a use case.
o Models dynamic aspect of the system.
o Operations and objects may be added , deleted or modified according to the need.

Interaction diagrams types

o Sequence diagram : SHOWS interaction among objects with respect to time. Objects –x
axis and timeline- y axis.
o Collaboration diagram : SHOWS the sequence in which objects send or receive
messages among themselves

Sequence diagrams

• In sequence diagrams, the messages send amongst objects are time ordered.
• It depicts the focus of control.
• Each sequence diagram represents one of the scenario of the use case.
• A separate sequence diagram may be created for an alternate flow in a use case.

Objects, lifeline and focus of control

Juhi Patel Page 3 of 22
 BCA SEM IV

Objects
• An object is an instance of a class
• It is shown by

Home

• Lifeline of the object depicts the amount of time an object is alive in the use case.
• The dashed line appearing on the vertical axis is known as the lifeline of an object.
• lifeline of object begins with an actor
actor sends some message to the object.
• It ends when it is no longer required in the sequence diagram.
• It is shown by

Focus of control

• Focus of control shows the time period for which the object is under interaction or
performing a specific event.
• Focus of control is represented by a rectangle.

Example of lifeline, object, and focus of control.

Messages
• Messages represent interaction between objects, in which sending object asks the receiving
object to perform some operation.
• Messages are represented by arrow from sending object to receiving object.

Juhi Patel Page 4 of 22

 BCA SEM IV

Types of messages

1. Simple message
2. Synchronous message
3. Asynchronous message
4. Procedure call
5. Return message
6. Reflexive message

Simple Message

• A simple message is used to represent interaction between objects that may not be a
procedure call.

Synchronous message

• When a synchronous type of message is sent, the sending object waits to receive a response
from the receiving object.

Asynchronous message

• When an asynchronous type of message is sent, the sending object does not wait to receive as
response from receiving object

Juhi Patel Page 5 of 22

 BCA SEM IV

Procedure call

• The outer sequence resumes after completion of the inner sequence of the procedure.

Return Message

• If some response value is given by a receiving object in response to some message obtained
by the sending object, this is called a return message.

Reflexive message

• A message can also be sent by an object itself is known as reflexive message.

Juhi Patel Page 6 of 22
 BCA SEM IV

• New object can be created when required and may be destroyed during the interaction.
• The destruction of an object is represented by a big X, which signifies end of an object.

Creation of sequence diagram

• Identify objects participating in the use case.

• External entity that will initiate the sequence diagram is identified.
• Sequence diagram begins with when some message is sent by an external entity.

Example:

Juhi Patel Page 7 of 22

 BCA SEM IV
Example: Sequence diagram for basic flow of login.

Example : Sequence diagram of alternative flow of login use case.

Juhi Patel Page 8 of 22

 BCA SEM IV

Juhi Patel Page 9 of 22

 BCA SEM IV

Control Structure types

Centralized (FORK SHAPED)
Decentralized (STAIR CASE SHAPED)

o In centralized structure, the controlling objects are responsible for the sending and
receiving of messages.
o They decide activation of objects and flow of messages

o Advantage:
o the parts of functionality can be easily reused
o Always allow to add new operations in sequence diagrams
Example of centralized control structure

Here report generator generates report for other classes i.e. can,bottle,crate.

Juhi Patel Page 10 of 22

 BCA SEM IV
-

o In decentralized control structure,

structure, the participating objects directly communicate with
other objects without any controlling object.
o It is preferable when the messages are strongly coupled with each other.

Juhi Patel Page 11 of 22

 BCA SEM IV
Sequence diagram with extension
• In the interaction diagram, the extends relationship may be modelled by the procedure
call.
• i.e inserting functionality of the extended use case.
• Example:
fine calculation use case extends the return book use case.

Collaboration Diagram

• In collaboration diagram, sequence of events is not time ordered.

• Depicts flow of events of a scenario in a use case.

• Objects, links and messages

– Objects are depicted by rectangle (objectname:classname)
– Links between objects are depicted by arrows.
– Directional arrow shows numbered message sent from sending object to receiving object.

Juhi Patel Page 12 of 22

 BCA SEM IV

• In collaboration diagram, time for which object is alive and time till which an object participates
in an operation are missing.
• A link in collaboration diagram can represent multiple messages

Juhi Patel Page 13 of 22

 BCA SEM IV
Refinement of Use case Description

• Use cases are refined during design phase.

• Actions between actors and system are identified.
• Refining the flow of events in the use case description.

Juhi Patel Page 14 of 22

 BCA SEM IV

• Because of refinement of use case description

• Modify other related diagrams (i.e Use case scenario diagram, sequence
diagram, collaboration diagram etc…)

Refinement of classes and Relationships

• Classes are further refined after the modification of use cases, interaction diagrams including
sequence diagram and collaboration diagram.

Refinement of operations to reflect the implementation environment

• Messages( procedure call) sent from sender object to receiver object become operations of the
receiver object.

Juhi Patel Page 15 of 22

 BCA SEM IV

Class Operation Parameter Parameter Return value Return Description

name type type

Login Login loginID String - - This operation allows the

actor to
Interface Password String - -
login into the system

Login Login loginID String - - This operation allows the

actor to
Controller Password String - -
login into the system

Login Validate loginID String - - This operation validates the

login ID
password string Boolean Boolean
and Password of the actor.
true/false

Construction of detailed class diagram

• In OOD, new classes are refined i.e new classes have been added, relationships and attributes
are refined and detailed set of operations are identified.

Development of detailed design

• Detailed design is constructed for all classes identified in the system.

• Detailed design is finally handed over to the programmer.
• Detailed design
• Increases the understanding of the system
• Helps the programmer in developing the source code

Class name
Class type
Description
Attributes Attribute 1
Attribute 2
:
Attribute n
Operations Operation 1
Operation 2
:
Operation n

Juhi Patel Page 16 of 22

 BCA SEM IV
Class name Transaction
Class type Entity
Description This class is used to store the details of each transaction i.e issue and return

Attributes Long bookBarcodeID

Long memberBarcodeID
Date dateofissue
Date expectedDOR

Operations Void issueBook(bookBarcodeID : Long, memberBarcodeID: Long)

Member retrieveMemebr(bookBarcodeID : Long)
Boolean checkFine(bookBarcodeID: Long)
Void returnBook( bookBarcodeID : Long)

Testing terminology

• Test cases are an integral part of any testing activity.

• Ensures robust, defect free and high quality system.
• Test cases may be created from basic flow and alternate flow of use case
diagram.
• They can be created in requirement analysis phase but as use case are refined
in design phase, it is created in the design phase.

Test Case Terms

Term Definition

Test case Executes a particular part of the program to verify a given requirement of
the system

Test suite Collection of test cases (successful/unsuccessful)

Test design & Detailed set of instructions for setting , designing and interpreting the
procedure results of a test case.

Test coverage Extent to which test cases are covered by a given test

Test result Repository which stores all the results and data produced during program
execution.

Juhi Patel Page 17 of 22

 BCA SEM IV

Generating test cases from use cases

o Test case are an integral part of any testing activity.

o Test cases derived from use case,
It will help to improve development process
Testing efficiency
Quality of developed product

• After the construction of a detailed designed, software design description(SDD) document may
be prepare.
• The SDD document can serve as a primary medium for communicating software design
information.
• It simply translates the requirements into description of software attribute, operations and
interfaces.

Deriving test cases from use case

1. Creation of use case scenario matrix.

2. Identification of variables in a use case.
3. Identification of different input states of variables.
4. Design of test case matrix.
5. Assigning actual values to input values

Juhi Patel Page 18 of 22

 BCA SEM IV

Creation of use case scenario matrix

• Scenario matrix shows both alternative and basic flows.

Scenario number and Originating flow Alternative flow Next alternative flow
description

Scenario 1

Scenario 2

2. Identification of variables in a use case

• identify all input variables which have been used in every use case.
• Example:
• bookBarcodeID and memberBarcodeID as input variables for entering into the
use case.
• These variables will be given as input to the system and some response is
expected from system

3. Identification
dentification of different input states of variables

• An input variable may be different states.

• Two states
» Valid state
» Invalid state
• In test case matrix, three types of values expected
• Valid input indicates the input condition that must be true for basic flow to
execute
• Invalid input indicates the input condition that must be true for alternative flow
to execute
• N/A indicates that the corresponding
corresponding input is not applicable to the particular test
case.

4. Design of Test Case Matrix

• A test case consists of a input values, expected result and actual result

Test case Scenario Input 1 Input 2 Expected Actual Remarks

ID name and output output (if any)
description

TC1 Scenario 1

Juhi Patel Page 19 of 22

 BCA SEM IV
TC2 Scenario 2

Test case matrix for issue book use case

Test Scenario name memberBardoceID bookBarcodeID Expected Remarks (if

case and description output any)
ID

TC1 Scenario 1 – Valid input Valid input Book is issued

Issue book basic successfully
flow

TC2 Scenario 2 – Valid input Valid/invalid input Membership Membership is

Issue book expired not validate by
alternative flow: system
unauthorized
member

TC3 Scenario 3 – Valid input Valid input Account full Member

alternative flow : reached
Account is full maximum limit
of book

5. Assigning actual value to input variables

• To provide actual data values to the input variable for each use case.

Test Scenario name memberBardoceID bookBarcodeID Expected output Remarks (if any)
case ID and
description

TC1 Scenario 1 – 1024 40925 Book is issued

Issue book basic successfully
flow

TC2 Scenario 2 – 1024 * Membership Membership is

Issue book expired not validate by
alternative flow: system
unauthorized
member

TC3 Scenario 3 – 1095 41256 Account full Member reached

alternative flow maximum limit of
: Account is full book

Juhi Patel Page 20 of 22

 BCA SEM IV

Improving software quality

• Coad and Yourdon(1991) defined a set of design principles for improving quality of
software product.
• Cohesion
• Coupling
• Design clarity
• Class hierarchy depth
• Simple classes and objects

Cohesion
– Attributes and operations in a class should be highly cohesive.
– Each operation should be designed to fulfill one single purpose.

Coupling
– Interaction coupling between classes should be kept minimum.
– Number of messages(sent and received) between classes should be reduced.

Design clarity

– Vocabulary used should be correct, concise (short), unambiguous and consistent.

– Names of the classes along with their attributes and operations should convey
intended meaning.
– Meaning and purpose of the class along with its responsibility should be clear.

Class hierarchy depth

– Concept of generalization-specialization should be used whenever necessary.

Simple classes and objects

– Excessive attributes should be avoided in a class.

– Class definition should be simple, clear, concise and understandable.

Juhi Patel Page 21 of 22

 BCA SEM IV

Juhi Patel Page 22 of 22