Object Oriented Design

Object Oriented Design

 After the OOA phase, further refinement of
designed classes begins with Object Oriented
Design (OOD) phase.
 In OOD phase the detailed class diagram is
constructed and the interaction diagrams are
created.
 The classes (along with their attributes and
operations, and their relationships are refined
keeping in mind the implementation
environment including programming languages,
databases and communication protocols.
Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

There are many reasons to have the design phase:
 In analysis phase ideal model is created. The aim is to build a
maintainable model. The classes identified are not designed as per
the implementation environment. Thus the analysis classes need to
be transformed taking in view the implementation environment.
 The objects along with their relationships need to be refined. The
operations must be refined and updated according to the messages
sent between objects.
 The classes along with their relationships must be verified so that a
well focused and detailed class model can be built.

Refined
on the basis of Design objects

Analysis
implementation
classes
environment

Interaction Diagrams
The steps involved in OOD are given below:
 Creation of interaction diagrams for each scenario
 Creation of sequence diagram
 Identification of actors, objects and messages in a scenario of a use
case.
 Identification of object’s lifeline, focus of control and sequence of
interaction.
 Refinement of sequence diagram
 Creation of collaboration diagram
 Identification of object, links and messages.
 Identification of structural relationship between objects.
 Identification of sequence of messages

 Refinement of classes and relationships identified in OOA
phase
 Identification of operations from sequence diagram
 Construction of detailed class diagram
 Development of detailed design
 Creation of software design document
 Generation of test cases from use cases

 An interaction diagram depicts the communications between
set of objects through message passing among themselves.
 Interaction diagram models the dynamic aspect of the system.
 For each use case an interaction diagram or one particular
flow (scenario) of the use case is constructed.
 The interaction between objects starts by sending messages to
each other. Thus, the messages including their parameter are
defined

 In UML, interaction diagram is of two types:
 sequence diagram and
 collaboration diagram.
 A sequence diagram shows the interaction amongst objects with
respect to time. In a sequence diagram, the objects appear on X-
axis and the time lines are shown in Y-axis.
 A collaboration diagram depicts the sequence which the object
send or receive messages amongst themselves.

Sequence Diagram
 An object is an instance of a class and is depicted by:
 Objectname:classname
 The dashed line appearing on the vertical axis is known as the lifeline
of the object.
 The lifeline of an object depicts the amount of time the object is alive
in the use case. The lifeline of the object begins as soon as the actor
sends some message to the object.
 There is a focus of control which is represented by rectangle.
 The rectangle starts with the beginning of a set of procedure, or action
and ends when the procedure is completed.

Sequence Diagram
Ram : Student
Object with timeline in a sequence diagram

Sequence Diagram
: BookController
Focus of control in a sequence diagram

Sequence Diagram
Messages
 Messages are an important element in a sequence diagram.
Messages represent interaction between object, in which
sending object asks the receiving object to perform some
operation.
 Messages are represented by arrows from the sending objects
to the receiving object

Sequence Diagram
: bookController : Book

Sequence Diagram
• Synchronous messages: When synchronous type of message is
sent, the sending object waits to receive a response from the receiving
object.
Object1 : Object2 :
Class1 Class2
Synchronous
message

Sequence Diagram
• Asynchronous messages: When asynchronous type of message is
sent, the sending object does not wait to receive as response from the
receiving object.
Object1 : Object2 :
Class1 Class2
Asynchronous
message

Sequence Diagram
Object1 : Object2 :
Class1 Class2
message( )
Procedure
call

Sequence Diagram
Object1 : Object2 :
Class1 Class2
message( )
return message

Sequence Diagram
• A message can also be sent by an object to itself. This type of
message is known as reflexive message.
Object1 :
Class1

Sequence Diagram
• A new object can be created anytime during the sequence diagram.
• The new object can be created when required and is placed below the
calling object.
• The calling object then sends a message of creation to the new object.
• An object may be destroyed during the interaction between objects.
• The destruction of an object is represented by a big X, which signify the
end of the life of an object.
• The messages give rise to operations.

Sequence Diagram
Object1 :
Class1
<<create>> Object2 : Class2
message()

Sequence Diagram
• In order to construct a sequence diagram, we must first identify the
objects participating in the use case.
• The objects in the OOD can be identified quickly by the classes
identified in the OOA phase.
• As the work for creating use case diagrams, writing use case
description and identification of classes with their relationships is done
in earlier phases, a good architecture and design of the software can
be created at an earlier stage. Since the work of identifying classes for
issue book use case was done earlier in the OOA phase, the objects
can easily be identified.
• The objects participating in the issue book use case are created for the
classes: BarcodeReader, IssueBookInterface, IssueBookController,
Member, Transaction, and Book.
• If required new objects may be introduced keeping the implementation
environment in mind.
Sequence Diagram
: Library Staff : BarcodeReader : IssueBookInterface : IssueBookController : Transaction : Member : Book

Sequence Diagram
 The sequence diagram for the basic flow scenario of ‘issue book’ use
case will follow the following steps:
 The barcode of book is read through the barcode reader.
 The issue book interface object accepts the book barcode.
 The member barcode is read through the barcode.
 The issue book interface accepts the member barcode.
 The issue book message is sent to the controller object.
 After validating the valid membership and number of books in member account
the controller sends the message to transaction object so that the book is issued.
 The information is finally saved to member and book objects.

read barcode of the book
accept barcode of the book
Read book
barcode ID
Accept book
barcode ID
read barcode of the member
accept barcode of the member
Read member display member details
barcode ID
destroy barcode object
Accept member
barcode ID
Destroy
BarcodeReader
object get the book issued
get the book issued
Notify the validate the membership and account of the member
controller issue
book request get the book issued
The member can increment number of books issued to the member

get the book
issued thus the update the issue status of the book
controller sends
issue book
message
Sequence Diagram
 There are two types of control structures centralized control structure
(fork shaped) and decentralized control structure (stair-case shape).
 In centralized control structure, the controlling objects are responsible
for managing the flow of sending and receiving messages.
 These controlling objects decide when which object will be activated
and order in which messages will be sent. In decentralized control
structure, the participating objects directly communicate with other
objects without any controlling object.

Sequence Diagram
Object1 : Class1 Object2 : Class2 Object3 : Class3 Object4 : Class4
Centralized control structure

Sequence Diagram
Object1 : Class1 Object2 : Class2 Object3 : Class3 Object4 : Class4
Decentralized control structure

getBookBarcodeID( )
Read book acceptBookBarcodeID(bookBarcodeID)
barcode ID
Accept book
barcode ID
getMemberBarcodeID( )
Read member acceptMemberBarcodeID(memberBarcodeID)
displayMemberDetails(memberBarcodeID)
barcode ID
<<destroy>>
Accept member
barcode ID
Destroy
BarcodeReader
issueBook(bookBarcodeID, memberBarcodeID)
object issueBook(bookBarcodeID, memberBarcodeID)
validate(memberBarcodeID)
Send issue book issueBook(bookBarcodeID, memberBarcodeID)

request
incrementBook(memberBarcodeID)
The member can

get the book updateIssueStatus(bookBarcodeID)
issued thus the
controller sends
issue book
message
Sequence Diagram
 We may create a separate sequence diagram for each scenario in
the use case.
 The use case description is divided into two parts one containing
basic flow and other containing alternative flows.
 A basic flow in the use case description depicts the most
important functionality that is going to occur most of the times in
the use case.

: Library Staff : BarcodeReader : IssueBookInterface : IssueBookController : Member
Read book getBookBarcodeID( )

acceptBookBarcodeID(bookBarcodeID)
barcode ID
Accept book
barcode ID
Read member getBookBarcodeID( )
barcode ID acceptMemberBarcodeID(memberBarcodeID)
Accept member <<destroy>>
barcode ID
Destroy
BarcodeReader
object
Send issue book issueBook(bookBarcodeID, memberBarcodeID)
request
An error message Invalid Membership
is returned as Invalid Membership
membership is
Invalid Membership
invalid
: Library Staff : BarcodeReader : IssueBookInterface : IssueBookController : Member
getBookBarcodeID( )
barcode ID
Accept book
barcode ID
Read member getBookBarcodeID( )
barcode ID acceptMemberBarcodeID(memberBarcodeID)
Accept member displayMemberDetails(memberBarcodeID)
<<destroy>>
barcode ID
Destroy
BarcodeReader
object
Send issue book
request issueBook(bookBarcodeID, memberBarcodeID)
An error message
is returned as Account full
account of Account full
member is full Account full
Sequence Diagram
Creating Sequence Diagram of use cases with extensions
 A use case may contain exceptional cases which are modeled through extends
relationship between two use cases.
 In the interaction diagram the extends relationship may be modeled by
procedure call i.e. inserting the functionality of extended use case.
 For example, fine calculation use case extends the return book use case. Thus,
the use case description of the fine calculation use case extends the use case
description of return book. During execution of the sequence diagram, the fine
calculation procedure is inserted. The position of the procedure call can be
determined by the use case description of return book.

: Library Staff : BarcodeReader : ReturnBookInterface : ReturnBookController : Transaction : Member : Book
Read book getBookBarcodeID( )

acceptBookBarcodeID(bookBarcodeID)
barcodeID displayMemberDetails(memberBarcodeID)
<<destroy>>
Return book returnBook(bookBarcodeID)

and check fine
status returnBook(bookBarcodeID)
retrieveMember(bookBarcodeID)
[member=student] checkFine(bookBarcodeID)
status of fine=false
Fine does not returnBook(bookBarcodeID)

exist hence return
the book
decrementBook(memberBarcodeID)
updateIssueStatus(bookBarcodeID)
Return book
and save the
information to
Object Oriented
database
Software Engineering by Yogesh Singh & Ruchika Malhotra
: Library Staff : BarcodeReader : ReturnBookInterface : ReturnBookController : Transaction : Member : Book
getBookBarcodeID( )
barcodeID displayMemberDetails(memberBarcodeID)
<<destroy>>
Return book
and check fine returnBook(bookBarcodeID)
returnBook(bookBarcodeID)
status retrieveMember(bookBarcodeID)
[member=student] checkFine(bookBarcodeID)
status of fine=true
<<create>>
: FineCalculator
Fine exists calculateFine(bookBarcodeID, memberBarcodeID)
hence create
fine calculator
object calculateFine(bookBarcodeID, memberBarcodeID)
<<create>>
: FineStatus
Notify fine saveFine(bookBarcodeID, memberBarcodeID, fine)
amount to actor
<<destroy>>
fine amount
<<destroy>>
fine amount
Return book fine amount
and save the returnBook(bookBarcodeID)
information to
decrementBook(memberBarcodeID)
database

Sequence Diagram
Example 1:
 Consider login use case of LMS. Draw sequence diagram for it.
Basic Flow 1: Login

(i)The system requests that the actor enters his/her login Id and
password information.
(ii)The actor enters his/her login Id and password.
(iii)The actor enters into the system.

Sequence Diagram
: Library Staff : LoginInterface : LoginController : Login

Enter LoginID
User enters
loginID and Enter Password
password
Login(loginID, password)
System
validates Login(loginID, password)
loginID and
validate(loginID, password)
password
User
sucessfully
logins into
the system
Sequence Diagram
Example 1:
 Consider login use case of LMS. Draw sequence diagram for it.
Alternative Flow 1: Invalid login Id/password

If in the Login flow, the actor enters an invalid login Id and/or
password or leaves the login Id and /or password empty, the system
displays an error message. The actor returns to the beginning of the
basic flow.

Sequence Diagram
: Library Staff : LoginInterface : LoginController : Login

Enter LoginID
User enters
loginID and Enter Password
password
Login(loginID, password)
System
validates Login(loginID, password)
loginID and
validate(loginID, password)
password
Invalid loginId/password
User is not Invalid loginId/password
allowed to
login into Invalid loginId/password
the system

Exercise
 The proposed software product is the Hospital Patient Management System
(HPMS). The system will be used to allocate beds to patients on a priority basis,
and to assign doctors to patients in designated wards as need arises. Doctors will
also use the system to keep track of the patients assigned to them. Nurses who
are in direct contact with the patients will use the system to keep track of
available beds, the patients in the different wards, and the types of medication
required for each patient. The current system in use is a paper-based system. It is
too slow and cannot provide updated lists of patients within a reasonable
timeframe. Doctors must make rounds to pick up patients’ treatment cards in
order to know whether they have cases to treat or not. The intentions of the
system are to reduce over-time pay and increase the number of patients that can
be treated accurately.
 Draw Sequence diagram for “allocate bed” use case

Collaboration Diagrams
 Unlike sequence diagrams, in collaboration diagrams the
sequence of events is not time ordered.
 Collaboration diagrams depict the flow of events of a scenario in
a use case.
 It shows the interaction between objects by organizing them.

Objects, Links and Messages
 Similar to the sequence diagrams, objects are depicted by
rectangles (objectname:classname).
 The links between objects are depicted by arrows and the
direction of the link is depicted by directional arrow.
 The directional arrow shows the numbered message sent from the
sending object to the receiving object

Object1 : Class1
1: getData()
Object2 : Class2

 Although the messages are shown in collaboration diagram, however
the time for which the object is alive and the time till which an object
participates in an operation is missing in this diagram.
 The objects have the same representation as in sequence diagrams.
 The parameters can be specified inside the parenthesis of the message.
The sequence number of the message is separated by the message name
by a colon (:).

 A link in a collaboration diagram can represent multiple messages
whereas a link in the sequence diagram can depict only one single
message.
Object1 : Class1
1: getData( )
2: sendValue(a)
Object2 : Class2

Creating Collaboration Diagrams
 The objects participating in the use case must be identified in order to
create a collaboration diagram.
 The objects for ‘issue book’ use case have already been identified for
the sequence diagram.
 The sequence of messages is determined and each link between objects
consists of the message that it sends during interaction along with the
sequence number of the message.

5: displayMemberDetails(memberBarcodeID)
7: issueBook(bookBarcodeID, memberBarcodeID)
: Library Staff 2: acceptBookBarcodeID(bookBarcodeID) : IssueBookInterface : Member

4: acceptMemberBarcodeID(memberBarcodeID)
1: getBookBarcodeID( )
3: getMemberBarcodeID( )
6: <<destroy>>
9: validate(memberBarcodeID)
11: incrementBook(memberBarcodeID)
: BarcodeReader
12: updateIssueStatus(bookBarcodeID)

: Transaction : IssueBookController : Book

Example 2:
 Consider ‘login’ use case of LMS. Draw collaboration diagram
for this use case.

1: Enter LoginID
2: Enter Password
3: Login(loginID, password)
: Library Staff : LoginInterface
4: Login(loginID, password)
5: validate(loginID, password)
: LoginController : Login
Refinement of Use Case
Description
 The use cases are refined during design phase when

implementation environment and other details are considered.
 We may also consider the steps which an actor follows while
actually interacting with the system and how the sequence of
messages are sent amongst objects.
 The flow of events is the very essential part of a use case. It
usually describes the sequence of actions by the actors and the
responses of the system to these actions.

Description
 As the actions between system and actors are identified, the

designer may have to modify the flow of events in the initial use
case descriptions.
 In UML, interaction diagram may prove to be very helpful in
refining the flow of events in the use case descriptions. The
understanding of the system increases as we create these
diagrams.

Description
Basic Flow
1 Student/faculty/employee membership number is read through barcode
reader.
2 The system displays information about the student/faculty/employee.
3 Book information is read through bar code reader.

4 The system checks the reservation status of the book.
5 The system validated the membership and number of books issued in the
account.
6 The system checks whether the member fine exceeds the maximum
limit of fine.
7 The book is issued for the specified number of days and the return date of
the book is calculated.

8 The book and student/faculty/employee information is saved into the
database.
9 If the book is reserved by the same member then it is marked as
unreserved.
Description
 In issue book use case, three alternative flows are added during the in depth
study of exceptional cases.
 The “Book is already reserved” alternative flow was not considered earlier
which is quite possible in practice. If a student may ask for a “reserved book”,
permission for the same should be denied by the LMS.
 Alternative flow “fine exceeds the specified limit” is added in which a student
may want to get a book issued while his/her fine limit has been exceeded.
 Other Alternative flow “Unable to read entry” is also added in order to
represent the exceptional case when the barcode of the book or member could
not be read by the system.

Description
Alternative Flow 1: Unauthorized member

If the system doesn’t validate the member’s (student/faculty/employee)
membership number (due to membership expiry or any other reason), then an
error message is flagged and the use case ends.
Alternative Flow 2: Account is full
If the student/faculty/employee has requested a book in Account and it is full,
i.e. he/she has already maximum number of books issued on his/her name,
then the request for issue is denied and the use case ends.
Alternative Flow 3: Book is already reserved
If the book is already reserved by some other member of the library, then the
request for issue is denied and the use case ends.
Alternative Flow 4: Fine exceeds the specified limit
If the fine of the student exceeds the specified limit, then the request for issue is
denied and the use case ends.

Description
Alternative Flow 5: Unable to read entry

If the barcodeID or memberID is unreadable, then an error message is flagged
and the use case returns to the beginning of the basic flow.
Alternative Flow 6: Invalid entry
If in the issue book flow, the actor enters an invalid barcodeID and/or
memberID or leaves the barcodeID and/or memberID empty, the system
displays an error message. The actor returns to the beginning of the basic flow.
Alternative Flow 7: User exits
This allows the user to exit at any time during the use case. The use case ends

Description
 The design phase updates the use cases and may modify other related diagrams.
 We may also find need of new use cases to simplify complex steps and increase
the reusability.
 Thus, continuous refinement is a key to development of software through
iterative process.
 The understanding of the system continuously increases and this brings changes
in the various models and documents that are produced and finally results in the
development of the source code.
 Use case descriptions are the medium through which our continuous increase in
knowledge of the system is reflected.

: Library Staff : BarcodeReader : IssueBookInterface : IssueBookController : ReserveBook : Transaction : FineStatus : Member : Book
getBookBarcodeID( )
barcode ID
Accept book
barcode ID
getMemberBarcodeID( )
Read member acceptMemberBarcodeID(memberBarcodeID)
barcode ID
Accept member <<destroy>>
barcode ID
Destroy
BarcodeReader
object
Notify the
controller issue reserveStatus(bookBarcodeID, memberBarcodeID)
book request
The member can validate(memberBarcodeID)

get the book
issued thus the [member=student] checkMaxFine(memberBarcodeID)
controller sends
issue book issueBook(bookBarcodeID, memberBarcodeID)
message
incrementBook(memberBarcodeID)
[reserve=member] changeReserveStatus(bookBarcodeID, memberBarcodeID)

Identification of Operations to
Reflect the Implementation
Environment
 The messages (procedure call) sent form the sender object to the
receiver object in a sequence diagram becomes operation of the
receiver object.
 The operations of classes in issue book use case are identified
from sequence diagram

Environment
Class Operation Name Parameter Paramet Return Return Description
er type value type
BarcodeReader getBookBarcodeID - - - - This operation reads book
barcodeID of the book.
getMemberBarcodeI - - - - This operation reads book
D memberID of the member.
destroy - - - - This operation destroys the
object.
IssueBookInterfac acceptBookBarcodeI bookBarcodeID Long - - This operation accepts barcode
e D ID of book from barcode
reader.
acceptMemberBarco memberBarcodeI Long - - This operation accepts barcode
deID D ID of member from barcode
reader.
issueBook bookBarcodeID Long - - This operation issues book to a
member of the library.
memberBarcodeI Long -
D
IssueBookControll issueBook bookBarcodeID Long - - This operation issues book to a
er member of the library.
Environment
Transaction issueBook bookBarcode Long - - This operation issues
ID book to a member of
memberBarc Long - the library.
odeID
ReserveBook reserveStatus bookBarcode Long boole boole This operation checks

ID an an whether the book has
memberBarc Long been reserved or not.
odeID
FineStatus checkMaxFine memberBarc Long boole boole This operation checks
odeID an an whether the fine of the
member has reached its
maximum limit.

Environment
Member validate memberBarc Long boole boole This operation
odeID an an validates the
membership and
account of the
member.
incrementBook memberBarc Long - - This operation
odeID increments the number
of books in member
account.
displayMember memberBarc Long Mem Mem This operation returns
Details odeID ber ber the details of the
Detai objec member.
ls t
Book updateIssueStat bookBarcode Long - - This operation changes
us ID the issue status of the
book.
Environment
Example 3:
 Consider login use case of LMS. Identify detailed operations for
each class along with their parameters and return values. Describe
the purpose of each operation.

Environment
Class Operation Paramete Parameter Return Description
Name r type value
LoginInterface login loginID string - This operation
password string - allows the actor to
login into the
system.
LoginController login loginID string - This operation
password string - allows the actor to
login into the
system.
Login validate loginID string - This operation
password string - validates the login
ID and password of
the actor.
Construction of Detailed Class
Diagram
 The portions of class diagram were created in OOA phase. Now
the classes are refined i.e. new classes have been added,
relationships and attributes are refined and detailed set of
operation are identified.
 The detailed class diagram is created in OOD phase.

Development of Detailed Design
 A detailed design is constructed for all the classes identified in the

system.
 The tabular representation of each class with detailed description
can be used to construct the design. The detailed design is finally
handed over to the programmer.
 The detailed design increases the understanding of the system and
helps the programmer in developing the source code. The detailed
design of each class will facilitate the developer’s team to easily
understand each individual class.

Class name
Class type
Description
Attributes Attribute 1
Attribute 2
………….
Attribute n
Operations Operation 1
Operation 2
…………..
Operation n
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
Date actualDOR
Operations void issueBook(bookBarcodeID : Long, memberBarcodeID : Long)
member retrieveMember(bookBarcodeID : Long)
boolean checkFine(bookBarcodeID)
void returnBook(bookBarcodeID : Long)
Class name Book
Class type Entity
Description This class is used to store the details of each book in the library
Attributes Long bookBarcodeID
String subjectDescriptor
String ISBN
String bookTitle
String language
String authorName
String publisher
Boolean issueStatus
Operations void updateIssueStatus(bookBarcodeID : Long)
void saveDetails( )
Object Oriented Software Engineering by Yogesh Singh & Ruchika
string deleteBook(bookBarcodeID Malhotra
: Long)
Generating Test Cases from Use
Cases
 Test cases are integral part of any testing activity. The creation of
test cases and executing them when the source code is available
ensures that a robust, defect free and high quality system is
constructed. A tester may ask the following questions:
 What is the exact functionality of the system?
 What are the exceptional or error conditions that may occur in the system?
 How to decide when the system has been tested completely?

Cases
 Commonly used Testing Terminology
 Testing is very important and essential activity that continues
throughout the software development life cycle.
 Test case: A test case may execute a particular path of the program or
verify a given requirement of the system. A test case consists of inputs
given to the program and its expected outputs from the program.
 Test suite: A test suite consists of set of test cases. Test suite may consist
of set of successful test cases and set of unsuccessful test cases.

Cases
Commonly used Testing Terminology
 Test design and procedure: Test design and procedure consists of detailed
set of instruction for setting, designing and interpreting the results for a
given test case.
 Test coverage: Test coverage defines the extent to which the test cases are
covered by a given test for a given use case, class or system.
 Test results: Test results are a repository in which all the results and data
produced during the execution of a program are kept.

Cases
Use case
Test suite
consists of generates
Test cases
requires
Test design and

procedure
produces
Test results
Cases
Deriving Test Cases from Use Cases: A Five Step Process
 A systematic approach may follow the following steps in order
to derive test cases from use cases:
 Creation of use case scenario matrix
 Identification of variables in a use case
 Identification of different input states of variables
 Design of test case matrix
 Assigning actual values to input variables

Cases
Step 1: Creation of use case scenario matrix
 The scenarios may consist of one or more basic flows and one or
more alternative flows.
 A use case and scenarios have one to many relationships.
 A use case scenario matrix represents combinations of all
possible basic and alternative flows.

Cases
Scenario number Originatin Alternative Next

and description g flow flow Alternative
flow
Scenario 1
Scenario 2

Cases
Scenario number and Originating Alternative flow
description flow
Scenario 1- Issue book basic Basic Flow 1
flow
Scenario 2- Issue book Basic Flow 1 Alternative Flow 1
alternative flow: Unauthorized
student/faculty/employee
alternative flow: Account is full
alternative flow: Book is
already reserved

Cases
Scenario number and Originating Alternative flow
description flow
alternative flow: Fine exceeds
the specified limit
alternative flow: Unable to read
entry
alternative flow: Invalid entry
alternative flow: User Exits

Cases
Step 2: Identification of variables in a use case
 We have to identify all input variables which have been used in
every use case.
 For an issue book use case, we use ‘bookBarcodeID’ and
‘memberBarcodeID’ as inputs for entering into the use case.
 These are two input variables for issue book use case.

Cases
Step 3: Identification of different input states of variable
 An input variable may have different states and behaviour of the system may
change if the state of a variable is changed. Any variable may have at least
two states i.e.: valid state and invalid state. In the test case matrix (see step 4)
three types of values are used to specify the type of values expected by the
test case: valid input, invalid input and N/A. these terms are defined below:
 Valid input indicates the input condition that must be true for the basic flow to execute.
 Invalid input indicates the input condition that must be true for the alternative flow to
execute.
 N/A indicates that the corresponding input is not applicable to the particular test case for
the given scenario.

Cases
Step 4: Design of test case matrix
 A test case consists of set of input values, expected result and
actual result.
 A common format for representing a test case corresponding to a
given use case scenario is to use a test matrix. In the test matrix
the row represents a test case and the columns represent test case
id, Scenario Name and description, inputs, expected output,
actual output and remarks.

Cases
Test Scenario Input 1 Input 2 Expected Actual Remarks
Case Name and Output output (if any)
Id description
TC1 Scenario 1
TC2 Scenario 2
TC3 Scenario 3
TC4 Scenario 3

Cases
Test Scenario Name memberBar bookBarcod Expected Remarks (if any)
case and description codeID eID output
Id
TC1 Scenario 1- Valid input Valid input Book is issued --
Issue book basic successfully
flow
TC2 Scenario 2- Valid input Valid Membership The membership of a
Issue book /Invalid input expired member in the library is
alternative flow: not validated by the
Unauthorized system.
student/faculty/
employee
TC3 Scenario 3- Valid input Valid input Account full The account of a
Issue book member has reached the
alternative flow: maximum limit of books
Account is full that can be issued.
Cases
Test Scenario Name memberB bookBarcod Expected Remarks (if any)
case and description arcodeID eID output
Id
TC4 Scenario 4- Issue Valid Valid input Book is Book is already
book alternative input reserved reserved by some other
flow: Book is member in the library.
already reserved
TC5 Scenario 5- Issue Valid Valid input Fine exceeds The fine of the member
book alternative input the specified exceeds the maximum
flow: Fine limit permissible limit.
exceeds the
specified limit
TC6 Scenario 6- Issue Invalid Invalid input Error The specified barcode
book alternative input of the member/book is
flow: Unable to not in a readable
read entry format.
Cases
Test Scenario Name and memberB bookBarcod Expected Remarks (if any)
case description arcodeID eID output
Id
TC7 Scenario 7- Issue book Valid Invalid input Invalid book Book barcode is invalid
alternative flow: /Invalid barcode
Invalid entry input
TC8 Invalid Valid Invalid Member barcode is
input /Invalid member invalid
input barcode
TC9 Valid Book barcode Book barcode cannot
input is blank be blank
TC10 Valid input Member Member barcode
barcode is cannot be blank
blank

Cases
Id
TC11 Scenario 8- Issue book Valid Valid input User comes --
alternative flow: User input out of the
Exits system

Cases
Step 5: Assigning actual values to input variables
 Now we have created the scenario matrix, identified the
variables with their input conditions, and created test matrix.
 Its time now to provide actual data values to the input variables
for each test case.
 It is not possible to execute test cases and generate test results
without providing real data to a test case.

Cases
Test Scenario Name memberBar bookBarcod Expected Remarks (if any)
case and description codeID eID output
Id
TC1 Scenario 1- 1024 40925 Book is issued --
Issue book basic successfully
flow
TC2 Scenario 2- 1035 * Membership The membership of a
Issue book expired member in the library is
alternative flow: not validated by the
Unauthorized system.
student/faculty/
employee
TC3 Scenario 3- 1095 41256 Account full The account of a
Issue book member has reached the
alternative flow: maximum limit of books
Account is full that can be issued.
Cases
Test Scenario Name memberB bookBarcod Expected Remarks (if any)
case and description arcodeID eID output
Id
TC4 Scenario 4- Issue 1095 41257 Book is Book is already
book alternative reserved reserved by some other
flow: Book is member in the library.
already reserved
TC5 Scenario 5- Issue 1089 455602 Fine exceeds The fine of the member
book alternative the specified exceeds the maximum
flow: Fine limit permissible limit.
exceeds the
specified limit
TC6 Scenario 6- Issue - - Error The specified barcode
book alternative of the member/book is
flow: Unable to not in a readable
read entry format.
Cases
Id
TC7 Scenario 7- Issue book 3456 456 Invalid book Book barcode is invalid
alternative flow: barcode
TC8 Invalid entry 3 45667 Invalid book Member barcode is
barcode invalid
TC9 3456 Book barcode Book barcode cannot
is blank be blank
TC10 56788 Member Member barcode
barcode is cannot be blank
blank

Cases
Id
TC11 Scenario 8- Issue book 3456 56789 User comes --
alternative flow: User out of the
Exits system

Cases
Example: Consider the problem statement of the LMS. Construct
scenario diagram and generate test cases from login use case.

Use Case Testing
Alternative
Flow 2
Alternative
Flow 1
Alternative Flow 3 Alternative Flow 3
Use case ends Use case ends
(a) (b)
Alternative Flow 1: Invalid login Id/password
Alternative Flow 2: Invalid Entry
Alternative Flow 3: User exits
Use Case Testing
Scenario 1- Login Basic Flow 1

Scenario 2- Login basic flow: Basic Flow 1 Alternate Flow 1
Invalid login Id/password
Scenario 3- Login basic flow: Basic Flow 1 Alternate Flow 3
User Exit
Scenario 4- Change Password Basic Flow 2
Scenario 5- Change password Basic Flow 2 Alternate Flow 2
basic flow: Invalid Entry
Scenario 6- Change password Basic Flow 2 Alternate Flow 3
basic flow: User Exit

Use Case Testing
Test Scenario Name Input 1 Input 2 Input 3 Input 4 Input 5 Expected output Remarks
case Id and description (if any)
Login Password Old New Confirm
id password passwor passwor
d d
TC1 Scenario 1- Valid Valid n/a n/a n/a User is allowed to --
Login input input login
TC2 Scenario 2- Invalid Valid n/a n/a n/a Login id invalid Login id
Login basic input input does not
flow: Invalid exist in
Entry database
TC3 Valid Invalid n/a n/a n/a Password invalid Password
input input does not
exist in
database
TC4 Invalid Invalid n/a n/a n/a Login id and Login id
input input password invalid and
Password
do not exist
TC5 Scenario 3- Valid Valid n/a n/a n/a User comes out of the --
Login basic /Invalid /Invalid system
flow: Exit input input
Use Case Testing
TC6 Scenario 4- n/a n/a Valid input Valid Valid User is allowed to Password is
Change password input input change password changed in
the database
TC7 Scenario 5- n/a n/a Invalid Valid Valid Old password invalid If old
Change password input /Invalid /Invalid password is
basic flow: Invalid input input not valid,
entry other entries
become do
not care
entries
TC8 n/a n/a Valid input Invalid Valid New password invalid Password is
input /Invalid not in the
input specified
format
TC9 n/a n/a Valid input Valid Valid Confirm password does New and
input input not match new confirm
password password
entries are
different
TC10 Scenario 6- n/a n/a Valid Valid Valid User is allowed to exit --
Change password /Invalid /Invalid /Invalid and returns to login
basic flow: Exit input input input screen
Use Case Testing
Test Scenario Login Id Password Old New Confirm Expected output Remarks (if any)
case Name and pass pass passwor
Id description word word d
TC1 Scenario 1- 011645216 Abc123 n/a n/a n/a User is allowed to --
Login 57 login
TC2 Scenario 2- 1234 Abc123 n/a n/a n/a Login id invalid Login id is not in specified format
Login basic which is less than 11 characters
TC3 flow: Invalid 011645216 R34 n/a n/a n/a Password invalid Password is not in specified
Entry 57 format which is less than 4
characters
TC4 1234 R34 n/a n/a n/a Login id/password Login id and password are not in
invalid the specified format. Login id is
less than 11 characters and
password is less than 4 characters.
TC5 Scenario 3- * * n/a n/a n/a User comes out of --
Login basic the system
flow: Exit

Use Case Testing
TC6 Scenario 4- n/a n/a Abc1 Abc1 Abc124 User is allowed to --
Change 23 24 change password
password
TC7 Scenario 5- n/a n/a Abc1 * * Old password Old password does not match the
Change invalid corresponding password in the
password database. Other entries (new
basic flow: password and confirm password)
Invalid entry become do not care.
TC8 n/a n/a Abc1 R12 * New password New password is not in the
23 invalid specified format which is less than
4 characters. Other entries
(confirm password) become do
not care.
TC9 n/a n/a Abc1 Abc1 Abc125 Confirm password --
23 24 does not match new
password
TC10 Scenario 6- n/a n/a * * * User is allowed to --
Change exit and returns to
password login screen
basic flow:
Exit
Object Oriented Design Principles
for Improving Software Quality
 Coad and Yourdon defined a set of design principles for improving
the quality of a software.
 Cohesion: The 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.
The number of messages (sent and received) between classes should be
reduced. Inheritance based coupling between classes should be increased.
 Design clarity: The vocabulary used should be correct, concise,
unambiguous and consistent. The names of the classes along with their
attributes and operations should convey their intended meaning. The meaning
and purpose of the class along with its responsibilities should be clear.

Object Oriented Design Principles
for Improving Software Quality
 Coad and Yourdon defined a set of design principles for
improving the quality of a software.
 Class hierarchy depth: The concept of generalization-specialization
should be used wherever it is necessary. In other words, unnecessary and
excessive use of inheritance (only for the sake of increasing reusability)
should be avoided. Inheritance hierarchy should represent solution to a
problem.
 Simple classes and objects: Excessive attributes should be avoided in a
class. Class definition should be simple, clear, concise and
understandable.

Object Oriented Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object Oriented Design

Uploaded by

Copyright:

Available Formats

Object Oriented Design

Object Oriented Design

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

on the basis of Design objects

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object with timeline in a sequence diagram

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Focus of control in a sequence diagram

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

: Library Staff : BarcodeReader : IssueBookInterface : IssueBookController : Transaction : Member : Book

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

The member can increment number of books issued to the member

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object1 : Class1 Object2 : Class2 Object3 : Class3 Object4 : Class4

Centralized control structure

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object1 : Class1 Object2 : Class2 Object3 : Class3 Object4 : Class4

Decentralized control structure

Send issue book issueBook(bookBarcodeID, memberBarcodeID)

The member can

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Read book getBookBarcodeID( )

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Read book getBookBarcodeID( )

Return book returnBook(bookBarcodeID)

Fine does not returnBook(bookBarcodeID)

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Basic Flow 1: Login

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

: Library Staff : LoginInterface : LoginController : Login

Alternative Flow 1: Invalid login Id/password

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

: Library Staff : LoginInterface : LoginController : Login

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

: Library Staff 2: acceptBookBarcodeID(bookBarcodeID) : IssueBookInterface : Member

10: issueBook(bookBarcodeID, memberBarcodeID)

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra

: Library Staff : LoginInterface

 The use cases are refined during design phase when

Object Oriented Software Engineering by Yogesh Singh & Ruchika Malhotra