Course Overview

IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

Course Aim and Intended Learning Outcome

Course Aim:
To provide necessary skills and competencies to analyze and design a system using
object-oriented approach

Intended Learning Outcomes:

After following this course, students should be able to
▪ describe Object Oriented Analysis and Design concepts and apply them to solve
problems
▪ define UML (Unified Modeling Language) and its various types of diagrams
▪ prepare Object Oriented Analysis and Design documents for a given problem using
Unified Modeling Language
▪ explain the transition from analysis to design
▪ describe the key activities in the component-based software engineering (CBSE)
process

© e-Learning Centre, UCSC 2

Required Tools
ArgoUML or
StarUML or
Visual Paradigm-Community Edition or
any tool that supports UML 1.4 and higher

© e-Learning Centre, UCSC 3

References/ Reading Materials:
Ref 1: Alan Dennis, Barbara Haley, David Tegarden,
Systems analysis design, An Object-Oriented Approach
with UML : an object oriented approach, 5th edition,
John Wiley & Sons, 2015, ISBN 978-1-118-80467-4
Ref 2: Ian Somerville, Software Engineering, 10th
edition, Pearson , Pearson Education, 2016, ISBN: 978-
0133943030
Ref 3: https://www.geeksforgeeks.org/computer-aided-
software-engineering-case/
Ref 4.: https://www.uml-diagrams.org/

© e-Learning Centre, UCSC 4

1 : System Concepts for Object Modelling

IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students

• will learn the following Object Oriented concepts
➢Classes and Objects
➢ Methods and Messages
➢ Encapsulation and Information Hiding
➢ Inheritance
➢ Polymorphism and Dynamic Binding
• will be introduced to Unified Modeling Language (UML)
and its 14 diagrams mentioned below.
Class, Object, Use Case, Activity, Sequence, Communication,
Package, State, Component, Deployment, Interaction Overview,
Composite Structure, Timing , Profile

© e-Learning Centre, UCSC 6

 Intended Learning Outcomes

At the end of this lesson, you will be able to;

• Identify and describe the Object-Oriented concepts

• Define Unified Modeling Language (UML) and its various types of

diagrams

© e-Learning Centre, UCSC 7

 List of Subtopics

1.1 Classes and Objects [Ref 1: Pg. 19-20]

1.2 Methods and Messages [Ref 1: Pg. 20]
1.3 Encapsulation and Information Hiding [Ref 1: Pg. 20]
1.4 Inheritance [Ref 1: Pg. 21]
1.5 Polymorphism and Dynamic Binding [Ref 1: Pg. 22]
1.6 Introduction to Unified Modeling Language (UML) [Ref 1:
Pg. 34-35, Ref 4]

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object Oriented
Approach with UML : an object oriented approach, 5th edition, John Wiley & Sons, 2015, ISBN
978-1-118-80467-4
Ref 4.: https://www.uml-diagrams.org/

© e-Learning Centre, UCSC 8

1.1 Classes and Objects

• A problem can be divided into subjects.

• Subjects are used as logical divisions for development of
large systems
• Each subject is generally considered as a problem domain

Subjects eg. Airport Management System

Radar control Baggage Handling Passenger

Processing

© e-Learning Centre, UCSC 9

1.1 Classes and Objects

• We understand the real world through ideas that are

organized into recognizable patterns and concepts.
• Concepts can be divided into following types :
Tangible - book
Roles - doctor
Relational - marriage
Intangible - time, quality
Judgmental - good pay
Event - Purchase, loan

© e-Learning Centre, UCSC 10

 1.1 Classes and Objects
System concepts for object modeling

• In the real-world interaction of these concepts allow

complex operations to be performed.
Library System
Core Concepts - Borrowing, Returning of books, Book registration,
Member registration (Use Cases)
Concepts - Member, Copy, Book (Classes)

* He knows certain facts - eg. Name

address etc.
* Also perform certain activities
Instance of a
Member Concept

© e-Learning Centre, UCSC 11

1.1 Classes and Objects

• Classes
• Represent the concepts that are to be modeled.
• Initial Step in OOA is the identification of Actors, Use
cases, classes (Problem Domain).
• Library System: identify Use Cases-Borrowing books,
returning of books , registration of Books in a library
system
• Classify type of expected users (Actors) of the system
( Librarian, Member etc.)
• Classes in a library system - Book, Copy,
Member etc. (problem Domain Classes)

© e-Learning Centre, UCSC 12

1.1 Classes and Objects

• Objects (Instances of Classes)

• Something that is or is capable of being seen, touched,
or otherwise sensed and about which users store data
and associate behavior
• Types of objects
• Person: e.g. employee, customer, instructor, student
• Place: e.g. warehouse, building, room, office
• Thing: e.g. product, vehicle, computer, videotape
• Event: e.g. an order, payment, invoice, application
• Sensual: e.g. phone call, meeting

© e-Learning Centre, UCSC 13

1.1 Classes and Objects

• Attributes and Services

by examining the descriptions/documents given by the
users, event type concepts (Scenarios) can be identified.
• Attributes : The data that represents characteristics of
interest about an object.
• Services : The set of things that an object can do and
that correspond to functions that act on the object’s
data or attributes.

© e-Learning Centre, UCSC 14

 System concepts for
1.1 Classes and Objects
object modeling
• Attributes and Services

Borrowing of Books
eg. Library System
Main Actions Return of Books
Reservation of Books
Each Action Involves with Pool of Objects
(Instance of a Class)
Each Class offers
* Various Services
* Contains information reflected as Attributes

© e-Learning Centre, UCSC 15

 1.1 Classes and Objects
Objects
eg.
- A Toshiba
Washing Machine
- A Panasonic
Washing Machine
e.g. Class WashingMachine
Attributes brandName
modelName
serialNumber
capacity
addClothes()
Services addDetergent()
removeClothes()

© e-Learning Centre, UCSC 16

1.1 Classes and Objects
Another Example

© e-Learning Centre, UCSC 17

1.1 Classes and Objects
System concepts for object modeling

• A principle used to derive attributes and services

* What the specific concept knows ?

- attributes
* What are the responsibilities of a class ?
- services
Services operate when they are involved through message
connections.
Student knows how to draw a rectangle
but he will not draw unless somebody ask
him to draw
Another example : TV and Remote

© e-Learning Centre, UCSC 18

1.2 Methods and Messages

Message – Communication that occurs when one object

invokes another object’s method (behavior) to request
information or some action

© e-Learning Centre, UCSC 19

 System concepts for object modeling
1.2 Methods and Messages

• Message Passing
• In a system, objects work together.
• They do this by sending messages to one another.
• One object sends another a message to perform an operation.
• The receiving object performs that operation.
eg. A TV and a Remote

© e-Learning Centre, UCSC 20

S 1.2 Methods and Messages concepts for object
modeling
• Message Passing
• When you want to watch a TV show,
• You hunt round for a remote,
• Settle into your favorite chair and
• Push the On Button.
• What happens?
• The remote object sends a message (literally!) to the TV object to turn
itself on.
• The TV object receives the message.
• It knows how to perform the turn-on operation and turns itself on.

© e-Learning Centre, UCSC 21

1.2 Methods and Messages concepts for object
modeling
• Message Passing
• When you want to watch a different channel,
• You click the appropriate button on the remote,
• Remote object sends a different message change channel to the TV
object.
• The remote can also communicate with the TV via other messages
for changing the volume, muting the volume etc..

© e-Learning Centre, UCSC 22

1.2 Methods and Messages m concepts for object
modeling
• Message Passing
• Let’s go back to interfaces for a moment.
• Most of the things you do from the remote, you can also do by
getting out of the chair, going to the TV, and clicking buttons on the
TV.
• The interface the TV presents to you is obviously not the same
interface it presents to the remote.

© e-Learning Centre, UCSC 23

 and Messages m
1.2 Methods and Messages
concepts for object modeling
• Each object offers services within the realm of its
responsibility.
Object B
Object A
MI MI MI MI
Service B1
Service A1 Service B2
Service A2
* Objects use other objects services through message passing

* An object may even call its own services

© e-Learning Centre, UCSC 24

 and Messages m
1.2 Methods and Messages
concepts for object modeling

Message interaction Methods

© e-Learning Centre, UCSC 25

 1.3 Encapsulation and Information Hiding

• Data Abstraction
➢ A mechanism to reduce and filter out details so that one
can focus on a few concepts at a time. Focus on Essentials
➢ Filter out an object’s properties and operations until just
the ones you need are left.
➢ Ignore the irrelevant. Ignore the unimportant.
eg. Book – Bookshop you bought -Not important
• Abstraction, information hiding, and encapsulation are very
different, but highly-related, concepts.
• One could argue that abstraction is a technique that help us identify
which specific information should be visible, and which information
should be hidden.
• Encapsulation is then the technique for packaging the information
in such a way as to hide what should be hidden and make visible
what is intended to be visible.

© e-Learning Centre, UCSC 26

1.3 Encapsulation and Information Hiding
System concepts for object
modeling
• Encapsulation
• Packaging of several items together into one unit (both
attributes and behavior of the object), Also protects
the contents.
• The only way to access or change an object’s attribute
is through that object’s specific behavior.
• Objects encapsulates what they do.
• That is, they hide the inner workings of Eg. Class BankAcount
their operations {
• from the outside world Private: Balance
………
• and from other objects Withdraw(int)
Deposit(int)
}
© e-Learning Centre, UCSC 27
 System concepts
1.3 Encapsulation for object
and Information modeling
Hiding

When an object carries out its operations, those operations

are hidden.
E.g. When most people watch a television show,
- they usually don’t know or care about the complex
electronics that sit behind the TV screen
- or the operations that are happening.
The TV hides
its operations
from the
person
watching it.

© e-Learning Centre, UCSC 28

1.3 Encapsulation and Information Hiding
• Information Hiding
• The principle of information hiding suggests that only
the information required to use a software module be
published to the user of the module.
• Typically, this implies that the information required to
be passed to the module and the information returned
from the module are published.
• It is not relevant to know exactly how the module
implements the required functionality
• We really do not care how the object performs its
functions, as long as the functions occur.
• In object-oriented systems, combining encapsulation
with the information-hiding principle supports treating
objects as black boxes.(a black box is a device or object
which can be viewed in terms of its inputs and outputs
without any knowledge of its internal workings.)

© e-Learning Centre, UCSC 29

1.3 Encapsulation and Information Hiding

© e-Learning Centre, UCSC 30

1.3 Encapsulation and Information
System concepts Hiding
for object modeling

Why is this important?

• In the software world, encapsulation helps cut down on
the potential for bad things to happen.
• In a system that consists of objects, the object depends
on each other in various ways.
• If one of them happen to malfunction, software
engineers must change it in some way.
• Hiding its operations from other objects means it
probably won’t be necessary to change those other
objects.

© e-Learning Centre, UCSC 31

1.3 Encapsulation and Information Hiding
System concepts for object modeling

• Turning from software to reality, you see the importance

of encapsulation.

eg. Your computer monitor, hides its operations from your

computers CPU.
When something goes wrong with your monitor, you
either fix or replace it.
You probably won’t have to fix or replace the CPU
along with it.

© e-Learning Centre, UCSC 32

1.3 Encapsulation and Information Hiding
System concepts for object modeling

• An object hides what it does from other objects and

from outside world
• But an object does have to present a “face“ to the
outside world, so you can initiate those operations.
eg. A TV, has a set of buttons either on
the TV or on a remote.
The TV’s buttons are called interfaces.

© e-Learning Centre, UCSC 33

1.3 Encapsulation and Information Hiding

Cannot access (private)

- Private : cannot access from outside objects

+ Public : can access from outside objects

© e-Learning Centre, UCSC 34

1.3 Encapsulation and Information Hiding
System concepts for object modeling

• Encapsulation is done through the definition of region of

access.
• Region of access defines the accessibility of the services
or attributes in a class.
•In C++ (OO programming Language)
• 3 types of access regions: private, public, protected
•In Java
• Access modifiers: default, public, private, protected,
• Static modifier, final modifier, synchronized modifier, native
modifier

© e-Learning Centre, UCSC 35

1.4 Inheritance

• The concept wherein methods and/or attributes defined in

a class can be inherited or reused by another class.
• The data modeling literature suggests using inheritance to
identify higher-level, or more general, classes of objects.
• Common sets of attributes and methods can be organized
into super-classes.
• Typically, classes are arranged in a hierarchy whereby the
super-classes, or general classes, are at the top and the
subclasses, or specific (specialized) classes, are at the
bottom.
e.g. some individuals in the room might be classified as STUDENTS
and TEACHERS. Thus, STUDENT and TEACHER classes are members of
the class PERSON

© e-Learning Centre, UCSC 36

1.4 Inheritance

© e-Learning Centre, UCSC 37

 1.4 Inheritance
m concepts for object modeling
• Generalization / Specialization
• A technique wherein the attributes and behaviors that
are common to several types of classes are grouped /
abstracted into their own class called a supertype.
• The attributes and methods of the supertype class are
then inherited by those classes (subtype)
• Sometimes abbreviated as gen/spec.
• Generalization is the term that we use to denote abstraction
of common properties into a base class. When we
implement Generalization in a programming language, it is
called Inheritance.

© e-Learning Centre, UCSC 38

 1.4 Inheritance

Generalization
Specialization
Student
GPA firstName
Classification lastName
Person
birthdate
firstName enroll gender
lastName displayGPA walk
birthdate Inheritable
Attributes
+ jump
gender Teacher talk
And
walk sleep
behavior rank
jump
talk
sleep lecture

© e-Learning Centre, UCSC 39

1.4 Inheritance
An Example of UML (Unified Modeling Language) Representation of
Generalization /Specialization

Specialization
Generalization

© e-Learning Centre, UCSC 40

1.4 Inheritance
System concepts for object modeling

• Generalization / Specialization

Vehicle
Person

Bus Car Truck

Student Teacher

* Specialized classes inherit from the parent class

© e-Learning Centre, UCSC 41

1.5 Polymorphism and Dynamic Binding

• Polymorphism is the concept that different objects can

respond to the same message in different ways.
• It allows different forms of the same service to be
defined.
• Sometimes an operation has the same name in different
classes.
eg. You can open a door, you can open a window, or
a bank account. In each case, you are performing
a different operation.

© e-Learning Centre, UCSC 42

1.5 Polymorphism and Dynamic Binding
• We can simply send a message to an object, and that
object will be responsible for interpreting the message
appropriately.
• For example, if an artist sent the message ‘draw yourself’
to a square object, a circle object, and a triangle object,
the results would be very different, even though the
message is the same.

© e-Learning Centre, UCSC 43

1.5 Polymorphism and Dynamic Binding

Related terms used in OO programming language

• Function Overloading,
• Operator Overloading,
• Method Overriding

© e-Learning Centre, UCSC 44

1.5 Polymorphism and Dynamic Binding

In some programming languages,

function overloading or method
overloading is the ability to create
multiple functions of the same name
with different implementations.

© e-Learning Centre, UCSC 45

 System concepts for object modeling
1.5 Polymorphism and Dynamic Binding

Polymorphism
Overriding – a technique
whereby a subclass
(subtype) uses an
attribute or behavior of
its own instead of an
attribute or behavior
inherited from the class
(supertype).

© e-Learning Centre, UCSC 46

 1.5 Polymorphism and Dynamic Binding

SyPolymorphism – Operator Overloading

In languages like C++, we can change the way operators work
for user-defined types like objects and structures. This is
known as operator overloading.
Suppose we have created three objects c1, c2 and result
from a class named Complex that represents complex
numbers.
we can redefine how the + operator works and use it to add
the complex numbers of c1 and c2 by writing the following
code:
result = c1 + c2;
instead of something like
result = c1.addNumbers(c2);
stem concepts for object modeling

© e-Learning Centre, UCSC 47

kad

1.5 Polymorphism and Dynamic Binding

Operator Overloading in C++

class complex
{
float real,imag;
public : complex operator+(complex&);
complex() { } //default constructor
complex(float r, float s) // constructor
{ real=r; imag=s;}
void printcomplex( )
{
std::cout<<”Real component=”<<real<<’\n’;
std::cout<<”Imaginary component=”<<imag;
}
};

© e-Learning Centre, UCSC 48

kad

1.5 Polymorphism and Dynamic Binding

complex operator+(complex&);
• Definition of the operator is like a member function, except the
operator symbol is prefixed by the keyword operator.
complex complex::operator+(complex &a) {
complex z;
z.real=real+a.real; int main()
z.imag=imag+a.imag; {
return z; complex var1(1.2,3.4), var2(4.5,6.5), outc;
} outc=var1+var2;
outc.printcomplex();
}

Sample Output :
Real component = 5.7
Imaginary component = 9.9

© e-Learning Centre, UCSC 49

 1.5 Polymorphism and Dynamic Binding
• Polymorphism is made possible through dynamic binding. Dynamic,
or late, binding is a technique that delays typing the object until run-
time. The specific method that is actually called is not chosen by the
object-oriented system until the system is running.
• This is in contrast to static binding. In a statically bound system, the
type of object is determined at compile-time. Therefore, the
developer has to choose which method should be called instead of
allowing the system to do it.
• This is why most traditional programming languages have
complicated decision logic based on the different types of objects in
a system.
• For example, in a traditional programming language, instead of
sending the message Draw yourself to the different types of
graphical objects we would have to write decision logic using a case
statement or a set of if statements to determine what kind of
graphical object we wanted to draw, and we would have to name
each draw function differently
(e.g., draw square, draw circle, or draw triangle). Th is obviously
makes the system much more complicated and difficult to
understand.
© e-Learning Centre, UCSC 50
 1.6 Introduction to Unified Modeling Language (UML)
• Until 1995, object concepts were popular but implemented
in many different ways by different developers.
• Each developer had his or her own methodology and
notation (e.g., Booch, Coad, Moses, OMT, OOSE)
• Then in 1995, Rational Software brought three industry
leaders together to create a single approach to object-
oriented systems development.
• Grady Booch, Ivar Jacobson, and James Rumbaugh worked
with others to create a standard set of diagramming
techniques known as the Unified Modeling Language (UML).
• The objective of UML was to provide a common vocabulary
of object-oriented terms and diagramming techniques rich
enough to model any systems development project from
analysis through implementation.

© e-Learning Centre, UCSC 51

1.6 Introduction to Unified Modeling Language (UML)

• UML , A visual modeling language enables system

builders to create blueprints that capture their
visions in a standard, easy-to-understand way
• Provides a mechanism to effectively share and
communicate these visions with others (Technical
or Nontechnical)

© e-Learning Centre, UCSC 52

1.6 Introduction to Unified Modeling Language
(UML)

• It most directly unifies the methods of

• Booch,
• Rumbaugh (OMT) and
• Jacobson
as well as the best ideas from several other methodologies.

© e-Learning Centre, UCSC 53

1.6 Introduction to Unified Modeling Language
(UML)

UML Inputs

Booch Rumbaugh Jacobson

Mayer
Odell
Pre and post
classification
UML conditions

Shlaer-Mellor Harel
Object life cycles State charts

Gamma et al Wirfs-Brook
Frameworks, Responsibilities
Embly
Patterns, Fusion
Singleton
notes Operation descriptions
classes
Message numbering

© e-Learning Centre, UCSC 54

1.6 Introduction to Unified Modeling Language
(UML)

• The UML does not prescribe a method

for developing systems—only a
notation that is now widely accepted as
a standard for object modeling.

© e-Learning Centre, UCSC 55

1.6 Introduction to Unified Modeling Language (UML)

UML History
• The first public draft version – (version 0.8) – Oct 1995
• Feedback from public and Ivor Jacobson’s inputs included – (ver. 0.9 Jul 1996,
ver. 0.91 Oct 1996)
• Ver 1.0/1.1 was presented to OMG group for standardization in July/Sep 1997.
• Nov 1997 – UML adopted as the standard modelling language by OMG
• Ver 1.2 - June 1998
• Ver 1.3 – Dec 1998
• Ver 1.4 – 2000
• Ver 2.0 – 2003
• Ver 2.1 – 2007
• Ver 2.2 - 2009
• Ver 2.3 – 2010,
• Ver 2.4 –Jan 2011
• Ver 2.5 June 2015

© e-Learning Centre, UCSC 56

UML Components and Capabilities

• The UML consists of a number of graphical elements that

combine to form diagrams.
• Because it is a language, the UML has rules for combining
these elements.
• Lets look at the diagrams before looking at the elements
and rules.
• The purpose of the diagrams is to present multiple views
(model) of a system.
• UML 2.5 include 14 different diagrams.

© e-Learning Centre, UCSC 57

• UML diagrams are divided into two categories.
- Structure Diagrams :
Seven diagram types represent structural
information,
-Behaviour Diagrams :
other seven represent general types of behavior..

© e-Learning Centre, UCSC 58

UML Diagrams

© e-Learning Centre, UCSC 59

 Context Models

• Context models are used to illustrate the operational

context of a system
• they show what lies outside the system boundaries.
• Use Case Diagram can be used to represent a Context model
for a system.
• There is no single diagram in UML that would map to the
definition

© e-Learning Centre, UCSC 60

Context Models

© e-Learning Centre, UCSC 61

• UML include many different diagrams.
Class Diagrams :
• Shows set of classes, interfaces, and collaborations and their
relationships.
• Most common diagram found in modelling object-oriented
system.
• Address the static view of a system.
class: a category or group of things that have the same attributes
and the same behaviours.

© e-Learning Centre, UCSC 62

Class Diagram (UML 1.*)
e.g. School =Faculty

© e-Learning Centre, UCSC 63

Object Diagrams :
• Models actual object instances with current attribute
values.
• Shows a set of objects and their relationships.
• Provides a snap shot of the system’s objects at one point
in time.

© e-Learning Centre, UCSC 64

Object Diagram
e.g. Is being attacked by
thisWhiteQueen:Queen thisBlackKnight:Knight

Is strategically positioned against

thisWhitePawn:Pawn

© e-Learning Centre, UCSC 65

Use Case Diagrams :
• Shows a set of use cases and actors and their
relationships.
• A tried-and-true technique for gathering
information.

• Graphically describes who will use the

system and in what ways the user expects to
interact with the system.

© e-Learning Centre, UCSC 66

 Use Case Diagram
Order Processing

<<extend>>

<<Communicate>> Request Catalogue

Place Order
<<Include>>

Arrange Payment
Generalization Generalization
Order
Clerk
Arrange Credit
Pay Cash

© e-Learning Centre, UCSC 67

State Diagrams :

• Shows a state machine consisting of states,

transitions, events and activities.
• Models how events can change the state of an
object over its lifetime,
• show both the various states of an object and
the transactions between those states.

© e-Learning Centre, UCSC 68

State Diagrams
e.g. Course Registration

Add student[ count < 10] ]]

Add Student /
Initialization Set count =0 00
do: Initialize course Openn
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10] ]

Cancel

do: Notify registered students Closed

Cancel do: Finalize course

© e-Learning Centre, UCSC 69

Sequence Diagrams:
• An Interaction diagram that emphasizes the time-
ordering of messages.
• Graphically depicts how objects interact with each other
via messages in the execution of a use case or operation.
• Illustrates how messages are sent and received between
objects and in what sequence.

© e-Learning Centre, UCSC 70

Sequence Diagrams
e.g. Lending Books in a Library
a borrowing A borrower : A borrowed copy A copy : copy A book : book
: librarian form borrower : borrowedCopy

Enter Borrower IdcheckBorrowerExist( )

process
checkOverdue( ) getOverdueDetails( )

checkOverlimit( )

Enter copy id checkBorrowable( )

getBookDetails( )

confirm borrowing informBorrower( )

informBorrowedCopy( )

© e-Learning Centre, UCSC 71

Activity Diagram :

• A diagram that shows the flow from activity to activity

within a system.
• Address the dynamic view of a system.

© e-Learning Centre, UCSC 72

Activity Diagram

© e-Learning Centre, UCSC 73

Communication Diagrams :
• An interaction diagram that emphasizes the structural
organization of the objects that send and receive
messages.
• Shows the interaction of objects via messages.
• Also known as collaboration diagram in UML 1.X.

© e-Learning Centre, UCSC 74

Communication Diagrams : e.g. Lending of Books
1: Enter borrower id
2: checkBorrowerExist( )
3: process
4: checkOverdue( )
7: Enter copy i d
6: checkOverli mit( )
11: confirm borrowi ng borrowing 12: i nformBorrower( )
form

a borrower :
borrower

: l ibrari an
5: getOverdueDetails( )
13: i nformBorrowedCopy( )

8: checkCopyExist( )
10: checkBorrowabl e( )
a borrowed copy : a book :
borrowedCopy book

9: getBookDetai ls( )

a copy :
copy

© e-Learning Centre, UCSC 75

Component Diagram :
• Shows the organizations and dependencies
among a set of components.

• Address the static implementation view of a

system.

© e-Learning Centre, UCSC 76

Component Diagrams in UML 1.* and 2.*

© e-Learning Centre, UCSC 77

Deployment Diagram
• Shows the configuration of run time processing nodes
and the components live on them.
• Shows the physical architecture of a computer-based
system.
• It can show computers, their connections with one
another, and show the software that sits on each
machine.

© e-Learning Centre, UCSC 78

 Deployment Diagram

Registration Database
Server

LecturerOptions.exe

Main Library
Building

StudentOptions.exe StudentOptions.exe

© e-Learning Centre, UCSC 79

Composite Structure Diagrams :
• Decomposes the internal structure of a class.
• New in UML 2.0.

• A diagram which shows something about the

class’s internal structure.
e.g.
PERSON

Mind Body

© e-Learning Centre, UCSC 80

Interaction Overview Diagrams :
• New in UML 2.0.

• Replace some of the activities in the activity diagram

with sequence / communication diagrams (or a
combination of the two)

• Shows how objects interact within each activity of a use

case.

© e-Learning Centre, UCSC 81

Interaction Overview Diagram
e.g.
:User :LibraryDatabase
find()

Find book goToLocation()

:User :Librarian
Borrow book processCheckOutRequest()
takeBook()

Leave library :User :Guard

verifyCheckOut()

exitLibrary()

© e-Learning Centre, UCSC 82

1.6 Introduction to Unified
Modeling Language (UML)

Timing Diagrams :

• New in UML 2.0.

• A diagram which show

s how long an object is in
particular state. a

• Specially useful when d

esigning embedded
software for devices.

© e-Learning Centre, UCS

C
83
 Timing Diagram : e.g.
:WashingMachine
Spinning

Rinsing

Washing

Soaking

0 5 10 15 20 25 30 35

© e-Learning Centre, UCSC 84

Package Diagrams:

• A diagram which combines a number of classes or

components into a subsystem

© e-Learning Centre, UCSC 85

1.6 Introduction to Unified Modeling Language (UML)

Package Diagram e.g.

University
System
InformatiorTV
High-Level Use-Case
Diagram

Manage Loan and

->
UML Diagrams Grants

Firfandial
Administrator

Manage Fees

Student

Scheduler

Enrollment
-- >

© e-Learning Centre, UCSC

Manage
Seminars

Professor
I
86
1.6 Introduction to Unified Modeling Language (UML)
Package in a Package Diagram

Computers

MobileDevice LapTop

PocketPC PalmOS

© e-Learning Centre, UCSC

I
87
Profile Diagram
Describes lightweight extension mechanism to the UML
Profiles allow adaptation of the UML meta-model for
different:
• platforms (such as J2EE or .NET), or
• domains (such as real-time or business process modeling).

© e-Learning Centre, UCSC 88

Profile Diagram eg.

© e-Learning Centre, UCSC 89

2. Object Oriented Software Development
Process
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will be exposed to the

• Object Oriented Systems Analysis
• Phases and Workflows of Unified Process

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• define Object Oriented Systems Analysis and
explain its benefits
• Identify the fundamental principles and
characteristics of object-oriented systems analysis
and design
• Explain the Unified Process, and its extensions
• describe the phases and workflows of Unified
Process

© e-Learning Centre, UCSC 3

 List of Subtopics

2.1 Introduction to Object Oriented Systems Analysis and

Design [Ref 1: Pg. 23-25]
2.2 Benefits of OOAD [Ref 1: Pg. 25]
2.3 The Unified Process [Ref 1: Pg. 25-34]
2.3.1 Phases
2.3.2 Workflows

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object
Oriented Approach with UML : an object oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4
© e-Learning Centre, UCSC 4
 2.1 Introduction to Object Oriented Systems Analysis and
Design (OOAD)
• The primary difference between a traditional approach like
structured design and an object-oriented approach is how a
problem is decomposed.
• In traditional approaches, the problem-decomposition
process is either process-centric or data-centric.
• In the object-oriented approach, the focus is on capturing the
structure and behavior of information systems into small
modules that combines both data and process.

An Example of a Class in OOAD

Contains both data and processes

© e-Learning Centre, UCSC 5

2.1 Introduction to Object Oriented Systems Analysis and
Design (OOAD)

• According to the creators of the Unified Modeling Language

(UML), Grady Booch, Ivar Jacobson, and James Rumbaugh,
any modern object-oriented approach to developing
information systems must be
➢ use-case driven,
➢ architecture-centric, and
➢ iterative and incremental.

© e-Learning Centre, UCSC 6

Use-Case driven,
• Use Cases are the primary modeling tools defining the behavior
of the system.
• A use case describes how the user interacts with the system to
perform some activity, such as placing an order or making a
reservation.
• The use cases are used to identify and to communicate the
requirements for the system to the programmers. (Use Case
Modeling is described in Section 4)
• Use cases are inherently simple because they focus on only one
business process at a time. In contrast, the process model
diagrams used by traditional structured methodologies are far
more complex because they require the systems analyst and user
to develop models of the entire system.
• In contrast to structured methodologies, a Use Case focuses on
only one business process at a time, so developing models is
much simpler.
© e-Learning Centre, UCSC 7
 Architecture-Centric
• Architecture-centric means that the underlying software architecture
of the system drives the specification, construction, and
documentation of the system.
• Modern object-oriented systems analysis and design approaches
should support at least three separate but interrelated architectural
views of a system: functional, static, and dynamic.
• The functional, or external, view describes the behavior of the
system from the perspective of the user. (eg Use Case
Diagram)
• The structural, or static, view describes the system in terms of
attributes, methods, classes, and relationships. (eg. Class
Diagram)
• The behavioral, or dynamic, view describes the behavior of the
system in terms of messages passed among objects and state
changes within an object. (eg. Sequence, State diagrams)

© e-Learning Centre, UCSC

I
8
 Iterative and Incremental
• Object-oriented systems analysis and design approaches
emphasize iterative and incremental development involving
continuous testing and refinement throughout the life cycle.
INCREMENTAL VS ITERATIVE Xÿbla

£
& Incremental: Build one part completely at a time based on the
original idea.

fed jg, & &

Iterative: Build a rough version, validate this and continue building
/? bilding more quality and functionality in.

iilpil % ft

© e-Learning Centre, UCSC

I
9
Iterative and Incremental cont…
• In other words Systems analysts(SA) develop their
understanding of a user’s problem by building up the three
architectural views little by little.
• Here the approach is
• SA will first work with the user to create a functional
representation of the system. (Use Case model)
• Next SA will attempt to build a structural representation
of the evolving system. (Class Model)
• Thereafter SA will distribute the functionality of the
system over the evolving structure to create a
behavioural representation of the evolving system.
(Sequence diagram-or an Interaction model))

© e-Learning Centre, UCSC 10

Iterative and Incremental cont…
Object Oriented

Functional
View

Structural Behavioral
View View

© e-Learning Centre, UCSC 11

2.2 Benefits of Object-Oriented Analysis
Design
• OO concepts enable analysts to break a complex system into
smaller, more-manageable modules, and later combine the
modules to form an Information System.
• This modularity makes systems development easier to grasp,
easier to share among members of a project team, and easier to
communicate to users.
• By modularizing systems development, the project team actually
is creating reusable pieces that can be plugged into other
systems.
• When there are reusable components, new projects don’t have to
start completely from scratch, hence can save development time.
• It improves the quality of the system due to program reuse. The
principles of encapsulation and data hiding help the developer to
develop systems that cannot be tampered by other parts of the
system.
© e-Learning Centre, UCSC 12
2.3 The Unified Process
• The Unified Process is a specific methodology that maps
out when and how to use the various Unified Modeling
Language (UML) techniques for object-oriented analysis
and design
• The primary contributors were Grady Booch, Ivar
Jacobsen, and James Rumbaugh (UML Authors).
• UML provides structural support for developing the
structure and behavior of an information system, the
Unified Process provides the behavioral support.
• The Unified Process is use-case driven, architecture-
centric, and iterative and incremental.
• The Unified Process is a two-dimensional systems
development process described by a set of phases and
workflows.
• It is Popular with large scale projects
© e-Learning Centre, UCSC 13
The Unified Process
• The phases Unified process are inception, elaboration,
construction, and transition.
• The workflows include business modeling, requirements,
analysis, design, implementation, test, deployment,
configuration and change management, project
management, and environment.

© e-Learning Centre, UCSC 14

 2.3.1 Phases of Unifies Process
• The phases of the Unified Process support an analyst in
developing information systems in an iterative and
incremental manner.
• The phases describe how an information system evolves
through time.
• Depending on which development phase the evolving
system is currently in, the level of activity varies over the
workflows.
• Each workflow approximates the amount of activity that
takes place during the specific phase. (see previous figure)
Eg. The inception phase initially involves more on the
Engineering work flows such as business modeling and
requirements workflows while the test and deployment
workflows are overlooked.

© e-Learning Centre, UCSC 15

 Phases of Unifies Process cont…

Inception phase initially involves more on business modeling and

requirements workflows
© e-Learning Centre, UCSC 16
Phases of Unifies Process cont.…
• Each phase contains a set of iterations, and each iteration
uses the various workflows to create an incremental version
of the evolving system.
• As the system evolves through the phases, it improves and
becomes more complete.
• Each phase has objectives, activities, and incremental
deliverables.

© e-Learning Centre, UCSC 17

Four Phases of Unifies Process

• Inception - Do we understand what we are building?

Establish the business case for the project.
• Elaboration - Do we understand how to build it? Establish a
project plan and a sound architecture
• Construction - Are we ready to release in the near future?
Grow the system
• Transition - Can we release now? Supply the system to its
end users

© e-Learning Centre, UCSC 18

Inception Phase
• Inception phase is very similar to the planning phase of
a traditional SDLC approach.
• In this phase, a business case is made for the proposed
system. This includes feasibility analysis that should
answer questions such as the following:
• Do we have the technical capability to build it (technical
feasibility)?
• If we build it, will it provide business value (economic
feasibility)?
• If we build it, will it be used by the organization
(organizational feasibility)?
• To answer these questions, the development team
mainly performs work related primarily to the business
modeling, requirements, and analysis workflows.

© e-Learning Centre, UCSC 19

Inception Phase cont….
• Supporting workflows relevant to these flows are project
management and environment (see figure given in slide 16)
• Important primary deliverables from the inception phase :
➢a vision document that sets the scope of the project;
➢primary requirements and constraints, Initial Use Case
model presented to users
➢the feasibility and risks associated with the project;
➢necessary environment to develop the system;
➢Initial Project Plan and major milestones with cost
estimates;
➢One or several prototypes serving as a proof of concept.
➢some aspects of the problem domain classes being
implemented and tested.

© e-Learning Centre, UCSC 20

Inception Phase cont….

© e-Learning Centre, UCSC 21

Elaboration Phase
• When we typically think about object-oriented systems
analysis and design, the activities related to the elaboration
phase of the Unified Process are the most relevant.
• The analysis and design workflows are the primary emphasis
during this phase.
• Continues with developing the vision document, while
finalizing the business case.
• Revise the risk assessment and eliminate highest risk elements
of the project.
• Establish and validate the System Architecture.
• Complete a project plan in sufficient detail to allow the
stakeholders to be able to agree with constructing the actual
final system.
• Gather the requirements, build the UML structural and
behavioral models.
© e-Learning Centre, UCSC 22
Elaboration Phase
•
➢ the UML structure and behavior diagrams.
➢ description of the software architecture
➢ an executable of a baseline version of the evolving
information system.
➢ devised Business case and Risk list
• The baseline version serves as the foundation for all later
iterations.
• By providing a solid foundation at this point, the developers
have a basis for completing the system in the construction
and transition phases.

© e-Learning Centre, UCSC 23

Construction Phase
• The construction phase focuses heavily on programming the
evolving information system.
• This phase is mainly concerned with the implementation
workflow. However, the requirements workflow and the analysis
and design workflows also are involved with this phase.
• Missing requirements are identified, and the analysis and design
models are completed.
• During the last iteration, the deployment workflow uses intensely.
• The configuration and change management workflow, with its
version-control activities, becomes extremely important during
the construction phase.
• The primary deliverable of this phase is an implementation of the
system that can be released for beta and acceptance testing.

© e-Learning Centre, UCSC

I
24
Transition Phase
• Like the construction phase, the transition phase addresses aspects
typically associated with the implementation phase of a traditional SDLC
approach.
• Its primary focus is on the testing and deployment workflows. Essentially,
the business modeling, requirements, and workflows should have been
completed in earlier iterations of the evolving information system.
• Depending on the results from the testing workflow, some redesign and
programming activities on the design and implementation workflows could
be necessary, but they should be minimal at this point.
• From a managerial perspective, the project management, configuration and
change management, and environment are involved.
• Some of the activities that take place are beta and acceptance testing, fine-
tuning the design and implementation, user training, and rolling out the
final product onto a production platform.
• The primary deliverable is the actual executable information system. The
other deliverables include user manuals, a plan to support the users, and a
plan for upgrading the information system in the future.
© e-Learning Centre, UCSC 25
2.3.2 Workflows
• The workflows describe the tasks or activities that a
developer performs to evolve an information system
over time.
• The workflows of the Unified Process are grouped into
two broad categories: engineering and supporting.

Engineering Workflows:
➢Engineering workflows include business-modeling,
requirements, analysis, design, implementation, test,
and deployment workflows.
➢The engineering workflows deal with the activities that
produce the technical product (i.e., the information
system).

© e-Learning Centre, UCSC 26

Business Modeling Workflow
• Uncovers problems and identifies potential projects within a
user organization.
• Aids management in understanding the scope of the
projects.
• The primary purpose of business modeling is to ensure that
both developer and user organizations understand where
and how the to-be-developed information system fits into
the business processes of the user organization.
• Primarily executed during the inception phase
• The activities that take place are most closely associated
with the planning phase of the traditional SDLC; however,
requirements gathering, and use-case and business process
modeling techniques also help us to understand the
business situation.
© e-Learning Centre, UCSC 27
Requirements Workflow
• Includes extracting both functional and nonfunctional
requirements.
• Typically, requirements are gathered from project
stakeholders, such as end users, managers within the end
user organization, and even customers.
• The requirements workflow is used mostly during the
inception and elaboration phases.
• The identified requirements are very helpful for developing
the vision document and the use cases used throughout the
development process.
• Additional requirements tend to be discovered throughout
the development process.

© e-Learning Centre, UCSC 28

Analysis Workflow
• The analysis workflow is predominantly associated with the
elaboration phase, but like the requirements workflow, it is possible
that additional analysis will be required throughout the
development process.
• Primarily addresses the creation of an analysis model of the problem
domain.
• The analyst begins designing the architecture associated with the
problem domain; using UML.
• the analyst creates structural and behavior diagrams that depict a
description of the problem domain classes and their interactions.
• The primary purpose of the analysis workflow is to ensure that both
the developer and user organizations understand the underlying
problem and its domain without overanalyzing.
• A second purpose of the analysis workflow is to identify useful
reusable classes for class libraries. By reusing predefined classes, you
can speed up the development process.
© e-Learning Centre, UCSC 29
 Design Workflow
• The design workflow transitions the analysis model into a
design model that can be used to implement the system
• The analysis workflow concentrated on understanding the
problem domain, whereas the design workflow focuses on
developing a solution that will execute in a specific
environment.
• Basically, the design workflow simply enhances the
description of the evolving system by adding classes that
address the environment (boundary classes) of the system
to the evolving analysis model.
• The design workflow uses activities such as detailed
problem domain class design, optimization of the evolving
information system, database design, user-interface design,
and physical architecture design.
• The design workflow is associated primarily with the
elaboration and construction phases of the Unified Process.
© e-Learning Centre, UCSC 30
Implementation Workflow
• The primary purpose of the implementation workflow is
to create an executable solution based on the design
model.
• This includes not only writing new classes but also
incorporating reusable classes from executable class
libraries into the evolving solution.
• The new classes and their interactions with the
incorporated reusable classes must be tested.
• In the case of multiple groups performing the
implementation, the programmers also must integrate
individually tested modules to create an executable
version of the system.
• The implementation workflow is associated primarily with
the elaboration and construction phases.

© e-Learning Centre, UCSC 31

Testing Workflow
• The primary purpose of the testing workflow is to increase the
quality of the evolving system.
• Testing includes unit testing , integration testing, user
acceptance testing, and the actual alpha testing of the soft
ware.
• Testing should go on throughout the development of the
system.
• Testing of the analysis and design models occurs during the
elaboration and construction phases, whereas implementation
testing is performed primarily during the construction and, to
some degree, transition phases.
• Basically, at the end of each iteration during the development
of the information system, some type of test should be
performed.
© e-Learning Centre, UCSC 32
Deployment Workflow
• Mostly associated with the transition phase of the
Unified Process.
• Includes activities such as soft ware packaging,
distribution, installation, and beta testing.
• When deploying the new system into a user
organization, the developers might have to convert
the current data, interface the new soft ware with
the existing soft ware, and train the end user to use
the new system.

© e-Learning Centre, UCSC 33

2.3.2 Workflows cont….

• The workflows describe the tasks or activities that a

developer performs to evolve an information system
over time.
• The workflows of the Unified Process are grouped into
two broad categories: engineering and supporting.
• Already looked at engineering workflows

Supporting Workflows
• Include the project management, configuration and
change management, and environment workflows.
• The supporting workflows focus on the managerial
aspects of information systems development.
© e-Learning Centre, UCSC 34
 Project Management Workflow
• Whereas the other workflows associated with the
Unified Process are technically active during all four
phases, the project management workflow is the
only truly cross-phase workflow.

© e-Learning Centre, UCSC 35

 Project Management Workflow
• Information systems tend to grow or evolve over
time. At the end of each iteration, a new incremental
version of the system is ready for delivery.
• The project management workflow is quite important
owing to the complexity of the two-dimensional
development model of the Unified Process
(workflows and phases).
• This activities of the workflow include
➢ identifying and managing risks, managing scope,
➢ estimating the time to complete each iteration and the
entire project,
➢estimating the cost of the individual iteration and the
whole project, and
➢tracking the progress being made toward the final
version of the evolving information system.
© e-Learning Centre, UCSC 36
Configuration and Change Management Workflow
• The configuration and change management workflow are
associated mostly with the construction and transition phases.
•

• The evolving information system comprises a set of artifacts

(e.g., diagrams, source code, and executables).
• During the development process, these artifacts are modified.
• The artifacts themselves should be handled as any expensive
asset would be handled—access controls must be put into place
to safeguard the artifacts from being stolen or destroyed.
• The artifacts are modified on a regular basis; therefore, a good
version control mechanism should be established.
• Finally, a good deal of project management , information needs
to be captured (e.g., author, time, and location of each
modification).
© e-Learning Centre, UCSC 37
Environment Workflow

• During the development of an information system, the

development team needs to use different tools and
processes.
• The environment workflow addresses these needs. For
example, a CASE tool that supports the development of an
object-oriented information system via the UML could be
required.
• Other necessary tools include programming environments,
project management tools, and configuration management
tools.
• The environment workflow involves acquiring and installing
these tools.
• Even though this workflow can be active during all the phases
of the Unified Process, it should be involved primarily with
the inception phase.
© e-Learning Centre, UCSC 38
Extension to Unified Process
❖Some weaknesses of Unified Process
• It does not address staffing, budgeting, or contract
management issues.
• It does not address issues relating to maintenance, operations,
or support of the product once it has been delivered.
• does not address cross- or inter-project issues.
❖Therefore it is not a complete software process; it is only a
development process.
❖To address these omissions, Ambler and Constantine suggest
adding a production phase and two workflows: the operations
and support workflow and the infrastructure management
workflow.
❖In addition to these new workflows, the test, deployment, and
environment workflows are modified, and the project
management and the configuration and change management
workflows are extended into the production phase.
© e-Learning Centre, UCSC 39
Production Workflow
• Concerned primarily with issues related to the software
product after it has been successfully deployed.
• Focuses on issues related to updating, maintaining, and
operating the soft ware.
• Unlike the previous phases, there are no iterations or
incremental deliverables.
• Based on the activities that take place during this
phase, no engineering workflows are relevant.
• The supporting workflows that are active during this
phase include
➢configuration and change management workflow,
➢project management workflow,
➢new operations and support workflow, and
➢infrastructure management workflow.

© e-Learning Centre, UCSC 40

Operations and Support Workflow
• Addresses issues related to supporting the current
version of the software and operating the software
daily.
• Activities include
➢creating plans for the operation and support of the soft ware
product once it has been deployed,
➢creating training and user documentation,
➢putting into place necessary backup procedures,
➢monitoring and optimizing the performance of the soft ware,
and
➢performing corrective maintenance on the soft ware.
• This workflow becomes active during the construction
phase; its level of activity increases throughout the
transition and, finally, the production phase.

© e-Learning Centre, UCSC 41

Infrastructure Management Workflow

• Primary purpose is to support the development of

the infrastructure necessary for the development.
• When the development and maintenance of a
problem-domain architecture model goes beyond
the scope of a single project and reuse is going to
occur, the infrastructure management workflow is
essential.

© e-Learning Centre, UCSC 42

Existing Workflow Modifications and Extensions
• In addition to the workflows that were added to
address deficiencies contained in the Unified
Process, existing workflows had to be modified
and/or extended into the production phase.
• These workflows include the test, deployment,
environment, project management, and
configuration and change management workflows.

© e-Learning Centre, UCSC 43

Refinement of the Unified Process
• Rational Unified Process (RUP) is a refinement of the Unified
Process that was created by Rational Software (now owned by
IBM).
• It uses a series of software tools along with a process framework
to define how to carry out the activities needed to run a software
project,
• A modern generic process derived from the work on the UML and
associated process
• RUP is included in the IBM Rational Method Composer (RMC)
product which allows customization of the process.
• Agile Unified Process (AUP) is a simplified version of the Rational
Unified Process (RUP) developed by Scott Ambler. It describes a
simple, easy to understand approach to developing business
application software using agile techniques
• The Open Unified Process (OpenUP) is a part of the Eclipse
Process Framework (EPF), an open source process framework
developed within the Eclipse Foundation. Its goals are to make it
easy to adopt the core of the Rational Unified Process (RUP) /
Unified Process.
© e-Learning Centre, UCSC 44
3. Computer Aided Systems Engineering

IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will be introduced to

• Computer aided Software Engineering (CASE)
• Case tools and their Evolution
• Popular categories of Case Tools

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• define the term Computer aided Software
Engineering (CASE).
• describe Case tools and their evolvement.
• identify popular categories of Case Tools.

© e-Learning Centre, UCSC 3

 List of Subtopics

Computer Aided Systems Engineering (2 hours)

3.1 Introduction to CASE and CASE tools [Ref 1 Pg 77]
3.2 Evolution of CASE tools [Ref 1: 77-79 , Ref 3, Ref Teacher’s
Note]
3.3 Popular Classification of CASE tools [Ref 1 77, 79 ,Ref 3, Ref
Teacher’s Note]

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object
Oriented Approach with UML : an object oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4
Ref3 : https://www.geeksforgeeks.org/computer-aided-software-engineering-case/

© e-Learning Centre, UCSC 4

3.1 Introduction to CASE and CASE tools

• Computer aided software engineering (CASE) is the

implementation of computer assisted tools and methods in
software development.
• CASE ensures a disciplined approach and helps designers,
developers, testers, managers and other stakeholders in
system development to see the project milestones during
the development.
• CASE is also considered as a warehouse to store documents
related to projects such as
• business plans,
• requirements
• design specifications etc.

© e-Learning Centre, UCSC 5

3.1 Introduction to CASE and CASE tools

• Computer-aided software engineering (CASE) is a category of software

that automates all or part of the development process.
• Some CASE software packages are used primarily to support the analysis
workflow to create integrated diagrams of the system and to store
information regarding the system components.
• Some tools support the design workflow that can be used to generate
code for database tables and system functionality.
• Some tools contain functionality that supports tasks throughout the
system-development process.
• Some tools are considered as established software development
support tools (e.g. interactive debuggers, compilers, etc.)
• Some tools support only planning, analysis and design stages of the
software development life cycle(SDLC).
• They are also tools that are helpful in all the stages of SDLC, from
Requirement gathering to Testing and documentation.

© e-Learning Centre, UCSC 6

3.1 Introduction to CASE and CASE tools

• CASE comes in a wide variety options in terms of complexity and

functionality.
• Many good tools are available in the marketplace to support
object-oriented systems development,
e.g., ArgoUml, Visual Paradigm, Enterprise Architect, and IBM’s
Rational Rose etc.

ArgoUML - https://argouml.en.softonic.com/

https://www.visual-paradigm.com/download/community.jsp

• Popular categories of CASE tools will be discussed later.

© e-Learning Centre, UCSC 7

3.1 Introduction to CASE and CASE tools

• There are number of CASE tools available to simplify various

stages of Software Development Life Cycle.

Eg. Business Analysis and modelling,

Project management tools,
Design and Development toots,
Testing,
Maintenance etc

© e-Learning Centre, UCSC 8

3.1 Introduction to CASE and CASE tools

CASE tools can be broadly categorized as:

• Classic CASE tools - Established software
development support tools (e.g. interactive
debuggers, compilers, etc.)
• Real CASE tools - Can be separated into three
different categories, depending on where in the
development process they are most involved in:

© e-Learning Centre, UCSC 9

3.1 Introduction to CASE and CASE tools

Classic CASE Tools

• They are long‐established computerized tools
that support developers.
• Compilers and interpreters falls into this
category.
eg. Dev C++

© e-Learning Centre, UCSC 10

3.1 Introduction to CASE and CASE tools
Real CASE tools
• Real CASE tools can be broadly divided into the following
categories based on their use at a particular SDLC stage:
• Upper Case Tools
• Lower Case Tools
• Integrated Case Tools
I-CASE Has a
Central Repository
-Stores all information
Related to the Project

© e-Learning Centre, UCSC 11

3.1 Introduction to CASE and CASE tools
Central Repository
• A major difference between classic and real CASE
tools is that real CASE tools have a repository which
stores all the information related to the project.
• Real CASE tools require a central repository which
can serve as a source of integrated and consistent
information.
• Central repository is a central place of storage
where product specifications, requirement
documents, related reports and diagrams etc. are
stored.
• It is also serves as a data dictionary.

© e-Learning Centre, UCSC 12

Upper Case Tools
• Used in planning, analysis and design stages of
SDLC.
• Supports Business modeling.
• They do not support implementing , testing and
maintenance.
Eg. Diagramming tools such as UML tools which
support drawing of UML diagrams.
StarUML, ArgoUML

© e-Learning Centre, UCSC 13

3.1 Introduction to CASE and CASE tools
Lower CASE Tools
• Used in implementation, testing and maintenance
stages of SDLC.
• Do not support Planning, Analysis and Design
Eg. Tools to support code generation.
Eclipse

© e-Learning Centre, UCSC 14

 3.1 Introduction to CASE and CASE tools

Integrated CASE Tools : I-CASE

• They are helpful in all the stages of SDLC, from

Requirement gathering to Testing and documentation
Eg.
Visual Paradigm - https://www.visual-paradigm.com/
Enterprise Architect - http://www.sparxsystems.com/products/ea/

© e-Learning Centre, UCSC 15

 3.1 Introduction to CASE and CASE tools
Benefits of using I-CASE tools for System
Development
• Tasks can be completed and altered faster.
• Development documentation is centralized. Better and more
consistent documentation – because the tools make it easier to
create them and check for consistency.
• Information is illustrated through diagrams, which are typically easier
to understand.
• Reduce the maintenance costs.
• Improve software quality and enforce discipline. They check for
completeness, consistency, and contradictions using the Central
Repository.
• Substantial savings in software development resources.
• Shorter time to market.
• Reduced generation of defects. Increased automatic identification of
defects and their correction during development.

© e-Learning Centre, UCSC 16

 3.1 Introduction to CASE and CASE tools

Benefits of using I-CASE tools for System Development cont…

• Many modern CASE tools that support object-oriented
systems development support a development
technique known as round-trip engineering. Round-trip
engineering supports not only code generation but also
the reverse engineering of UML diagrams from code. In
this way, the system can evolve via diagrams and via
code in a round-trip manner.
e.g. generate a java class directly from a class diagram(Forward
Engineering), generate a sequence diagram from an existing
java program (Reverse Engineering)

© e-Learning Centre, UCSC 17

 3.2 Introduction
Evolution of CASEto
tools
CASE Tools
Era before CASE tools
- Systems Analysts use
pencil and paper for
modelling.
- Editing was not easy.
- Later introduced graphics
editors to support
modelling.
- Case tools Were
Introduced in early 1980’s
- No UML

© e-Learning Centre, UCSC 18

 3.2 Evolution of CASE tools
Introduction to CASE Tools
Era before CASE tools cont….
- Modeling notations were
introduced before graphics
editors
- The first structured method for
document process flow, was
known as the "flow process
chart“. It was introduced by
Frank and Lillian Gilbreth to
members of the American
Society of Mechanical
Engineers (ASME) in 1921.
- Latest UML activity diagrams
A simple flowchart representing a process
were very similar but there are for dealing with a non-functioning lamp.
differences too.
© e-Learning Centre, UCSC 19
 Introduction to CASE Tools
3.2 Evolution of CASE tools

Era before CASE tools cont….

- In the late 1970s data-flow
diagrams (DFDs) were
introduced and used with
structured analysis and design
(Gane and Sarson, 1979).
- DFDs show the flow of data
from external entities into the
system, showed how the data
moved from one process to
another, as well as its logical
storage.

© e-Learning Centre, UCSC 20

Introduction to CASE Tools
3.2 Evolution of CASE tools

Era before CASE

tools cont….
- Modeling
notations for
DFDs
- Gane and
Sarson Popular
Notation
- No Standard

© e-Learning Centre, UCSC 21

 3.2 Evolution of CASE tools

Era before CASE tools cont….

- Data modeling introduced in the
1970s driven by the need to
properly model databases.
- Peter Chen, an attendee at the
Enterprise Data World conference,
popularized the Entity-Relationship
model in a paper published in 1976.
- Chens paper considered to be the
beginning of the Data Modeling
practice as it is known today. ERD for an Order Processing
- Since then many notations System
introduced. Cross feet, Oracle. Draw
oracle notation etc.
© e-Learning Centre, UCSC 22
3.2 Evolution of CASE tools
Introduction to CASE Tools
Era before CASE tools cont….
- Modeling notations for ERDs
- Chens notation is a popular
notation.

ERD Notations (No standard)

© e-Learning Centre, UCSC 23

Introduction to CASE Tools
3.2 Evolution of CASE tools

Era before CASE tools cont….

- Word Processors (around since 1964)
- Diagram Editors
- Intelligent Diagram Editors (DesignAid-Early 80’s)

© e-Learning Centre, UCSC 24

3.2 Evolution of CASE tools
Era before CASE tools cont….
Intelligent Diagram Editors
Eg. Automatically detect syntactic check and semantic checks
in DFDs

E1
 E2
Process 1

E1  D1



© e-Learning Centre, UCSC 25
3.2 Evolution of CASE tools
History of CASE (Computer Aided Software
Engineering)

• Computer Aided Software Engineering was originally used

by Nastec Corporation of Southfield, Michigan in 1982.
• CASE tools are set of software application programs, which
are used to automate SDLC activities.

© e-Learning Centre, UCSC 26

3.2 Evolution of CASE tools

CASE tools in 80’s

• 4GL products
Evolved from enhanced query languages and report
generators into application development tools.
Eg. Nomad, Focus,
Dbase III +, Foxpro 1.0 (Popular in late 80s)
• Analysis Tools, Design tools (Assist user to sketch blueprints,
Interface design tools. )
• Most supported only some phases of the SDLC

© e-Learning Centre, UCSC 27

Evolvement of CASE Tools

CASE tools in ‘80s

• Excelerator introduced in 1984 by Index
Technology.
• Excelerator became popular and was the best seller
in 1989 (According to the PC Magazine of January
1990).
• Over 100 companies were offering nearly 200
different CASE tools (According to the PC
Magazine of January 1990).

© e-Learning Centre, UCSC 28

Evolvement of CASE Tools
Excelerator
• Excelerator combines the Yourdan/Demarco
Structured Analysis methodology with data
modeling and structured design methodologies.
• Supported both Yourdan and Gane/Sarson notation
for data-flow diagrams.
• Excelerator also supported Ward & Mellor notation
for state, control, and event modeling.
• ERD could be drawn using both Chen and Merise
notation.
• Structure charts and Jackson structure diagrams
were provided to help analyze process logic.
© e-Learning Centre, UCSC 29
Evolvement of CASE Tools

CASE tools in 90’s

- Usually confirm to some system development
methodology.
- Included some of the latest versions of earlier
mentioned CASE tools (80’s).
- Automate part or all of the supported
methodology.

© e-Learning Centre, UCSC 30

Evolvement of CASE Tools

CASE tools in ‘90s

When using these CASE tools the organizations had
to consider
- whether the features of a CASE tool fit the
methods they use in system development or
- whether they wish to modify their methods to
obtain CASE benefits.

© e-Learning Centre, UCSC 31

 Evolution of CASE tools
Some of the PC CASE tools that were available in early 90’s.
Product Vendor Hardware
Analyst Designer ToolKit Yourdon IBM PC and Compatibles
Automate + LBMS IBM PC and Compatibles
CASE 2000 Nastec Corp. IBM PC Compatibles, VAZ
Workstations
Excelerator Index Technologies IBM PC Compatibles,
Sun, Apollo
Information Engineering Knowledge Ware IBM PC Compatibles, IBM
Workbench MVs, DEC VAX
Teamwork Cadre Technologies Sun,Apollo,VAX, HP 9000
Deft Deft Inc. Macintosh
Oracle *CASE Oracle Corp. IBM PC and Compatibles,
Sun

© e-Learning Centre, UCSC 32

 Evolution of CASE tools
Popular System Development Methodologies used in 90’s
with their supportive techniques

SD Methods Techniques
HIPO-Hierarchical Input Process FHD,IPO charts
Output Charts
LSDM-LearMouth Structured DFD,ERD,Data Analysis, ELH
Development Method
SSADM (Structured System DFD,ERD,Data Analysis, ELH
Analysis and Design Methodology)
YSM-Yourdon Structured Method DFD,ERD, STD,SC
Oracle* Method DFD,ERD, Data Analysis, FHD,
Matrix Plotting
JSD-Jackson Structured Method PSD

© e-Learning Centre, UCSC 33

Evolution of CASE tools
Briefly look at 3 CASE tools that were popular in early 90’s
Automate Plus (Version 3.0)
• Automate + was a commercially available CASE tool for IBM PC and
compatible machines.
• The LSDM (Learmouth Structured Development Method), is the only
System development methodology supported by this tool.
• Only supported techniques used in LSDM. ie DFD,ERD, ELH
• DFDs (Yourdan/Demarco and Gane & Sarson) were supported by the tool
whereas only the Benchman/Chen (arrow head) and Martin (Crowsfeet)
notations for ERD were supported.
• User had to select the notations required at the installation time.
• Version 3.0 of Automate + supported only up to the system design stage.

© e-Learning Centre, UCSC 34

Evolution of CASE tools

Deft (Version 3.1)

• Deft was a commercially available CASE tool for Macintosh

PCs.
• It does not support any of the traditional design
methodologies directly.
• It supports the techniques such as DFD,ERD and PSD.
• For DFDs it supported Yourdan/Demarco and Gane and
Sarson notations where as for ERD it supported
Benchman/Chen, Martin and IRM notations.
• Gateway module allowed the user to ‘reverse engineer’ an
Ingress SQL or QUEL database the user had already created.
© e-Learning Centre, UCSC 35
Evolution of CASE tools

Oracle *CASE
(CASE * Designer ver. 1.1 , CASE *Dictionary ver. 5.0)
• Oracle *CASE was a commercially available CASE tool for
SUN workstations, IBM PC’s and compatibles.
• Oracle *CASE supported only a method call CASE
*Method.
• It supported four techniques namely DFD,ERD, FHD and
Matrix Plotter.
• It supported only Gane & Sarson notation for DFDs and
Oracle *CASE notation (its own) for ERD.
• It uses an Oracle relational database repository.
• Oracle *CASE can generate default applications, customize
forms and reports.
© e-Learning Centre, UCSC 36
Evolvement of CASE Tools

OO CASE Tools
• In the mid nineties, with the rise of Object Orientation,
the traditional CASE tools were perceived as a failure
by many people.
• The first OO CASE tools had the notation battle to fight
(before 1997 Nov.)
• After the introduction of UML in 1997 this problem
was resolved. (Main authors of UML -Rumbaugh,
Booch, and Jacobson )
• New set of CASE tools that supported UML diagrams
were introduced after 1997.
e.g. IBM’s Rational Rose, Sparx Systems Enterprise Architect
etc.

© e-Learning Centre, UCSC 37

 Popular Classification of CASE tools

• Diagramming Tools
• Project Management Tools
• Documentation Tools
• Configuration Management Tools
• Programming Tools
• Quality Assurance Tools

Some tools supports several of these categories

© e-Learning Centre, UCSC 38

3.3 Popular Classification of CASE tools

Diagramming tools
• These tools are used to represent system components,
data and control flows in a graphical form.
• Diagrammatic Representation of system in different view
points.
Examples
• StarUML, ArgoUML - used for creating UML diagrams
• MS Visio
• Draw.io
• Lucidchart
• Creately
• PlantUML- is an open-source tool and syntax for
creating diagrams from plain-text definitions.

© e-Learning Centre, UCSC 39

Popular Classification of CASE tools

Diagramming tools cont..

• You can also use any I-Case tools to draw most of
the diagrams.
eg. Visual Paradigm supports UML, ERD, DFD, PERT,
Organization charts, BPMN, CRC cards etc.
(https://www.visual-paradigm.com/)

© e-Learning Centre, UCSC 40

Popular Classification of CASE tools

Diagramming tools cont..

PlantUML(https://plantuml.com/)
• PlantUML is an open-source tool and syntax for creating
diagrams from plain-text definitions. You use simple text
syntax to describe a type of diagram, as well as the
elements which make up the diagram.
• Using this plain text syntax and a rendering server / plugin
to convert your text into diagrams, you can draw any
architectural diagram that you need when designing a
system.

© e-Learning Centre, UCSC 41

Popular Classification of CASE tools
Diagramming tools cont..

PlantUML

• Textual UML tools market is one of the fastest-growing

segment in the UML tools market.
• They provide some kind of lightweight solution to draw
some models.
• It has been used to allow blind students to work with UML.
PlantUML also helps blind software engineers to design and
read UML diagrams.

© e-Learning Centre, UCSC 42

Popular Classification of CASE tools
Diagramming tools cont..

PlantUML Example
@startuml
left to right direction
actor "Food Critic" as fc
rectangle Restaurant {
usecase "Eat Food" as UC1
usecase "Pay for Food" as UC2
usecase "Drink" as UC3
}
fc --> UC1
fc --> UC2
fc --> UC3
@enduml

© e-Learning Centre, UCSC 43

Popular Classification of CASE tools
Project Management Tools
• Used for project planning, cost and effort estimation, project
scheduling, resource planning, and progress monitoring of a
project.
• Help managers to comply project execution with every
mentioned step in software project management.
• Help in storing and sharing real-time project information like time
tracking etc. throughout the organization.
Examples
• Trello
• TeamWork
• Basecamp
• JIRA -Focus on issue tracking (Agile PM tool)
• etc
© e-Learning Centre, UCSC 44
Popular Classification of CASE tools
Documentation Tools or Help Authoring Software
• Documentation tools generate documents for technical
users and end users.
• Technical users are mostly in-house professionals of the
development team who refer to system manual, reference
manual, training manual, installation manuals etc.
• The end user documents describe the functioning and how-
to of the system such as user manual.
• Training Manuals, Installation Manual, User Manuals can be
generated by documentation tools.
Examples: Doxygen, DrExplain, Adobe Robohelp ,
Confluence etc.

© e-Learning Centre, UCSC 45

Popular Classification of CASE tools

Configuration Management (CM) Tools

• Configuration management is a systems engineering
process for establishing consistency of a product’s
attributes throughout its life.
• In the technology world, configuration management is an
IT management process that tracks individual configuration
items of an IT system.
• Configuration management helps engineering teams build
robust and stable systems through the use of tools that
automatically manage and monitor updates to
configuration data.

© e-Learning Centre, UCSC 46

Popular Classification of CASE tools
Configuration Management (CM) Tools cont…
• An instance of software is released under one version.
Configuration Management tools deal with
• Version ,Baseline configuration and Change control management
• Bug tracking and Blogging can be done by CM tools
Examples
• Git, (free and open-source distributed version control system)
• Docker
• Terraform etc.

© e-Learning Centre, UCSC 47

Popular Classification of CASE tools
Programming Tools cont….
• These tools consist of programming environments like
IDE (Integrated Development Environment), in-built
modules library and simulation tools.
• These tools provide comprehensive aid in building
software product and include features for simulation
and testing.
• Software tools are used to accomplish and investigate
the business processes, document the development
process of the software and optimize all the processes.
• By using these tools in the software development
process, the outcome of the projects will be more
productive.
• Using the development tools, a developer can easily
maintain the workflow of the project.
© e-Learning Centre, UCSC 48
Programming Tools cont….
Examples
• Eclipse - Eclipse is a popular IDE that is used by Java developers in
computer programming. It is used to develop applications not only in
Java but also in other programming languages like C, C++, C#, PHP,
ABAP etc.
• Netbeans - Netbeans is an open source and a free software
development tool written in Java that develops web, mobile, and
desktop applications easily and quickly. It uses C / C++, PHP,
JavaScript, Java etc.
• Bootstrap – Bootstrap is an open source and free framework for
developing responsive websites and mobile-first projects using CSS,
HTML, and JS. Bootstrap is widely used to design faster and simpler
websites.
• Adobe Dreamweaver – Adobe Dreamweaver is an exclusive software
program and programming editor that is used for creating simple or
complex websites. It supports many markup languages like CSS, XML,
HTML, and JavaScript.
© e-Learning Centre, UCSC 49
Programming Tools cont….
• Microsoft Visual Studio is an integrated
development environment from Microsoft. It is used
to develop computer programs, as well as websites,
web apps, web services and mobile apps.
• Android Studio is the official IDE for Android
application development, based on IntelliJ IDEA.
• Etc.

© e-Learning Centre, UCSC 50

 Quality Assurance Tools
• Quality assurance(QA) in a software organization is
monitoring the engineering process and methods
adopted to develop the software product in order to
ensure conformance of quality as per organization
standards.
• QA tools are utilized by many organizations to assist in
monitoring and managing their quality initiatives.
• QA tools consist of configuration and change control
tools and software testing tools.
Examples: Apache JMeter is an open source, Java-
based, load testing tool that can be used to analyze the
functional behavior of a system and measure the
performance of a system under a load test.

© e-Learning Centre, UCSC 51

Quality Assurance Tools cont..
• LambdaTest is an automation testing tool for desktop & web
applications.
• TestProject is a 100% FREE end-to-end test automation
platform for web, mobile, and API testing.
• IBM Rational Functional Tester is primarily intended for
automated functional testing & regression testing. It also
allows you to perform data-driven and GUI testing.
• IBM Rational Performance Tester tool is designed for doing
automated performance testing over web and server-based
apps.

© e-Learning Centre, UCSC 52

Quality Assurance Tools cont..
Apache JMeter
• Apache JMeter is a software that can perform load test,
performance-oriented business (functional) test, Stress
test, etc., on different protocols or technologies.
Performance Test − This test sets the best possible
performance expectation under a given configuration of
infrastructure. It also highlights early in the testing process if
any changes need to be made before the application goes into
production.
Load Test − This test is basically used for testing the system
under the top load it was designed to operate under.
Stress Test − This test is an attempt to break the system by
overwhelming its resources.

© e-Learning Centre, UCSC 53

 Summary
• Computer aided software engineering (CASE) is the
implementation of computer assisted tools and methods in
software development.
• Computer-aided software engineering (CASE) is a category
of software that automates all or part of the development
process.
• Some CASE software packages are used primarily to support
the analysis workflow to create integrated diagrams of the
system and to store information regarding the system
components.
• Many good tools are available in the marketplace to support
object-oriented systems development.
e.g., ArgoUml, Visual Paradigm, Enterprise Architect, and
IBM’s Rational Rose etc.

© e-Learning Centre, UCSC 54

 Summary cont…
• CASE tools can be broadly categorized as Classic CASE tools (
Established software development support tools ) and Real
CASE tools (Can be separated into three different categories,
depending on where in the development process they are
most involved in).
• Real CASE tools require a central repository which can serve
as a source of integrated and consistent information.
• Upper Case Tools are diagramming tools such as UML tools
which support drawing of UML diagrams.
e.g. ArgoUML
• Lower Case Tools are tools to support code generation.
e.g. Eclipse
• I-Case tools are helpful in all the stages of SDLC, from
requirement gathering to testing and documentation.
e.g. Visual Paradigm

© e-Learning Centre, UCSC 55

 Summary cont…

• There are many benefits of using I-CASE tools for System Development
such as tasks can be completed and altered faster, can reduce maintenance
costs etc.
• Before graphics editors were introduced to support modelling, Systems
Analysts use pencil and paper for modelling. Case tools were Introduced in
early 1980’s.
• CASE tools in 1980s – 4GL products such as Dbase III +, Foxpro 1.0 ,
Excelerator.
• CASE tools in 90’s - Usually confirm to some system development
methodology. E.g. Automate + , Deft, Oracle CASE
• OO Case tools - In the mid nineties, with the rise of Object Orientation, the
traditional CASE tools were perceived as a failure by many people.
• UML diagrams were introduced after 1997 and the notation issue was
resolved.
• Examples of OO Case tools- IBM’s Rational Rose, Sparx Systems Enterprise
Architect etc.

© e-Learning Centre, UCSC 56

Summary cont…

Popular Classification of CASE tools

• Diagramming Tools
• Project Management Tools
• Documentation Tools
• Configuration Management Tools
• Programming Tools
• Quality Assurance Tools

© e-Learning Centre, UCSC 57

4. Business Process Identification with Use
Case Modelling
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section, students will be introduced to

• Use Case Modeling with their benefits.
• Components of a Use Case Diagram, and steps
involved in drawing the diagram.
• The elements of a Use Case description.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• describe the benefits of Use-Case Modeling
• define actors, use cases and use-case
relationships
• identify and describe the steps for preparing a
use-case model

© e-Learning Centre, UCSC 3

 List of Subtopics
4. Business Process Identification with Use Case
Modelling (5 hours)
4.1 Introduction to Use-Case Modeling [Ref 1: Pg. 119-121]
4.2 Elements of a Use Case Diagram [Ref 1: Pg. 121-126]
4.2.1 Actors
4.2.2 Use Cases
4.2.3 Use Case Relationships
4.3 Creating a Use Case Diagram [Ref 1: Pg. 126-129]
4.4 Business Process Documentation with Use Cases and Use-
Case Descriptions [Ref 1: Pg. 140-152]
4.4.1 Elements of a Use-Case Description
4.4.2. Creating Use-case Descriptions

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object
Oriented Approach with UML : an object oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4
© e-Learning Centre, UCSC 4
4.1 Introduction to Use-Case Modeling

• Originally conceived by Dr. Ivar Jacobson in 1986.

• Proved to be a valuable aid in meeting the challenges of
determining what a system is required to do from a user and
stakeholder perspective.
• A best practice for defining, documenting and
understanding of an information system’s functional
requirements.

© e-Learning Centre, UCSC 5

4.1 Introduction to Use-Case Modeling

• All object-oriented systems development approaches are

use-case driven, architecture-centric, and iterative and
incremental.
• A use case is a formal way of representing the way a
business system interacts with its environment.
• Essentially, a use case is a high-level overview of the
business processes in a business information system.
• Use cases can document the current system or the new
system being developed.
• Given that object-oriented systems are use-case driven, use
cases also form the foundation for testing and for user-
interface design.

© e-Learning Centre, UCSC 6

4.1 Introduction to Use-Case Modeling
• It is the process of modeling a system’s functions in terms of
• business events
• who initiated the events
• how the system responds to those events
• An approach that facilitates user-centered development - a
process of systems development based on understanding
the needs of the stakeholders and the reasons why the
system should be developed

© e-Learning Centre, UCSC 7

4.1 Introduction to Use-Case Modeling

• Popular in non-object development environments

because of its usefulness in communicating with
users.
• Facilitates and encourages user involvement
• Provides a tool for capturing functional
requirements
• Provides a tool for requirements traceability
• Provides a framework for driving the system
development project

© e-Learning Centre, UCSC 8

4.1 Introduction to Use-Case Modeling

Use-case diagram
• Depicts the interactions between the system and external
systems / users.
• Graphically describes who will use the system and in
what ways the user expects to interact with the system
• A Subject Boundary represents the scope of the subject

Subject Boundary

UseCase1

Actor1 UseCase2

Actor3
UseCase1

Actor2

© e-Learning Centre, UCSC 9

4.2 Elements of a Use Case Diagram
Actor
• Anyone or anything that needs to interact with the
system to exchange information.
• Represented graphically as a stick figure labeled
with the name of the role the actor plays.
• Can be associated with other actors using a
specialization/superclass association, (see later)
• Is placed outside the subject boundary.

© e-Learning Centre, UCSC 10

 4.2 Elements of a Use Case Diagram

Actor
• An Actor may
• Only input information to the system.
• Only receive information from the system.
• Input and receive information to and from the system.

• Typically, they are found in the problem statement and by

conversations with customers and domain experts.

e.g. Librarian in a Library System

Grocery clerk in a Super Market

© e-Learning Centre, UCSC 11

4.2 Elements of a Use Case Diagram

Actors :
There are primarily four types of Actors.

- Primary Business Actor

- Primary System Actor
- External Server Actor
- External Receiver Actor

© e-Learning Centre, UCSC 12

4.2 Elements of a Use Case Diagram

Types of Actors
• Primary Business Actors – Benefits from the execution of use
cases by receiving some thing measurable.
e.g. Employee receiving a pay cheque.

• Primary System Actors - Directly Interfaces with the system to

trigger an event.
e.g. Grocery Clerk – Scan customer buying Items .

© e-Learning Centre, UCSC 13

 4.2 Elements of a Use Case Diagram

Types of Actors cont…

• External Server Actor

e.g. Credit bureau authorizing the charging by a credit card.

• External Receiver Actor

e.g. Warehouse receiving a package order to prepare a shipment.

© e-Learning Centre, UCSC 14

4.2 Elements of a Use Case Diagram
Actor Generalization

It factors out behaviour common to two or more actors

into a parent actor

Search library
inventory

Customer

Apply for
membership
Check out
books
Visitor Search library Patron
inventory
Visitor
Apply for
Check out membership
Patron books
© e-Learning Centre, UCSC 15
4.2 Elements of a Use Case Diagram

Use Case
• A behaviorally related sequence of steps both
automated and manual for the purpose of
completing a single business task.
• Describe system functions from the perspective of
external users in a manner they understand.
• They are the primary elements in software
development.
• They represent the functionality provided by the
system. i.e. what capabilities will be provided to an
actor by the system.

© e-Learning Centre, UCSC 16

4.2 Elements of a Use Case Diagram
Use Case
• Can extend another use case. (see later)
• Can include another use case. (see later)
• Is placed inside the system boundary.
• Is labeled with a descriptive verb–noun phrase.

© e-Learning Centre, UCSC 17

 4.2 Elements of a Use Case Diagram

Relationships
• Associations (also called <<Communicates>>)
• A relationship between an actor and a use case in which
an interaction occurs between them
• Modeled as a solid line connecting the actor and the use
case
• May be bidirectional or unidirectional
• UML 2.5 allows multiplicity

© e-Learning Centre, UCSC 18

 4.2 Elements of a Use Case Diagram
Multiplicity of an Actor/Use Case (UML 2.5)
• Required actor may be explicitly denoted using multiplicity 1 or
greater.
• UML 2.5 also allows actor to be optional.
• Multiplicity 0..1 of actor means that the actor may or may not
participate in any of their associated use cases.

© e-Learning Centre, UCSC 19

4.2 Elements of a Use Case Diagram

Use Case Diagram for an appointment system

© e-Learning Centre, UCSC 20

 4.2 Elements of a Use Case Diagram

Multiplicity of an Actor / Use Case (UML 2.5)

• When a use case has an association to an actor with a
multiplicity that is greater than one at the actor end, it means
that more than one actor instance is involved in the use case.

Two or more Player actors are involved in the Play Game use case.
Each Player participates in one Play Game.

© e-Learning Centre, UCSC 21

 4.2 Elements of a Use Case Diagram
Relationships
• Extend <<extend>>
• <<extend>> provides a way to insert new behaviour
into an existing use case.
• The extension use case extends the functionality of
the original use case.
• Shows optional behavior of a Use Case
• Depicted as an arrow headed line (either solid /
dashed)
• Has an arrow drawn from the extension use case to
the base use case.

© e-Learning Centre, UCSC 22

 4.2 Elements of a Use Case Diagram

Example: Extend Relationships

Extension Use Case

Refer Catalogue

Place New Order

© e-Learning Centre, UCSC 23

 4.2 Elements of a Use Case Diagram
Another Example for Extend Relationships

Base Use Case Return book

<<extend>>

Borrow book Issue fine

Librarian

Extension Use Case

© e-Learning Centre, UCSC 24

 4.2 Elements of a Use Case Diagram

Relationships
• Include <<include>>
• The base use case explicitly incorporates the
behavior of another use case.
• The relationship between the abstract use case
and use case that uses it.

© e-Learning Centre, UCSC 25

 4.2 Elements of a Use Case Diagram
Relationships
• include
• Another use case uses or includes the abstract use case.

ChangeEmployeeDetails

FindEmployee
Manager ViewEmployeeDetails
Details

DeleteEmployeeDetails

© e-Learning Centre, UCSC 26

 4.2 Elements of a Use Case Diagram
Relationships
• Depends on <<depends on>>
• A relationship between use cases indicating that
one use case cannot be performed until another
use case has been performed.
• e. g. banking business – use case ‘ Make a Withdrawal’
cannot be performed until the use case ‘Make a Deposit’
has been executed.
• Most analysts draw a separate diagram to show
dependency relationship.

© e-Learning Centre, UCSC 27

 4.2 Elements of a Use Case Diagram
Relationships

• Depends on
Establish
Bank Account
Make a
Deposit
Make a
Withdrawal

© e-Learning Centre, UCSC 28

 4.2 Elements of a Use Case Diagram
Relationships
• Relationships
• Generalization
• A relationship between actors created to simplify the
drawing when an abstract actor inherits the role of multiple
real actors

© e-Learning Centre, UCSC 29

 4.2 Elements of a Use Case Diagram

• Relationships
Search library
• Generalization inventory

Customer

Apply for
membership Check out
books
Visitor Search library Patron
inventory Visitor
Apply for
membership
Check out
Patron books

© e-Learning Centre, UCSC 30

4.2 Elements of a Use Case Diagram
Include, extend and generalization Compared

© e-Learning Centre, UCSC 31

A Use Case Diagram: An Example

© e-Learning Centre, UCSC 32

4.3 Creating a Use Case Diagram

• The first step is to review the requirements

definition. This helps the analyst to get a complete
overview of the underlying business process being
modeled.
• The second step is to identify the subject’s
boundaries. This helps the analyst to identify the
scope of the system. However, as we work through
the development process, the boundary of the
system most likely will change.
• The third step is to identify the primary actors and
their goals. The primary actors involved with the
system come from a list of stakeholders and users.
The goals represent the functionality that the
system must provide to the actor
© e-Learning Centre, UCSC 33
4.3 Creating a Use Case Diagram

• As actors are identified and their goals are

uncovered, the boundary of the system will change.
• The fourth step is to simply identify the business
processes and major use cases.
• The fifth step is to carefully review the current set
of use cases. It may be necessary to split some of
them into multiple use cases or merge some of
them into a single use case. Also, based on the
current set, a new use case may be identified.

© e-Learning Centre, UCSC 34

4.3 Creating a Use Case Diagram

• Basically, drawing the use-case diagram is

straightforward once use cases have been detailed.
• The only parts drawn on the use-case diagram are
the system boundary, the use cases themselves,
the actors, and the various associations between
these components.

© e-Learning Centre, UCSC 35

4.4 Business process documentation with use cases
and use case descriptions

• Use-case diagrams provide top level view of the basic

functionality of the business processes contained in the evolving
system.
• Use-case descriptions provide a means to more fully document
the different aspects of each individual use case.
• Use-case descriptions contain all the information needed to
document the functionality of the business processes.
• Although a use case may contain several paths that a user can
take while interacting with the system, each possible execution
path through the use case is referred to as a scenario.
• Another way to look at a scenario is as if a scenario is an
instantiation of a specific use case. Scenarios are used
extensively in behavioral modeling

© e-Learning Centre, UCSC 36

4.4 Business process documentation with use cases
and use case descriptions

Scenario – e.g. Purchase Items

• Customer Reviews items in the Shopping Cart
• Customer provides payment and shopping
information
• System validate payment Information and respond
with confirmation of order
• System will send confirmation of order details to
customer in an email.

© e-Learning Centre, UCSC 37

4.4 Business process documentation with use cases
and use case descriptions

• When creating use-case descriptions, the project team must

work closely with the users to fully document the functional
requirements.
• Organizing the functional requirements and documenting them
in a use-case description are a relatively simple process, but it
takes considerable practice to ensure that the descriptions are
complete enough to use in structural and behavioral modeling.
• A use-case description or Use Case narrative contains all the
information needed to build the structural and behavioral
diagrams that follow, but it expresses the information in a less-
formal way that is usually simpler for users to understand.

© e-Learning Centre, UCSC 38

4.4 Business process documentation with use cases
and use case descriptions

An Example :
Make Old Patient
Appointment

© e-Learning Centre, UCSC 39

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------

Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors: Importance of the
Other Interested Use Case – typically
Stakeholders:
Description: high , medium , low

There is no standard template for Use Case Narratives.

© e-Learning Centre, UCSC 40
4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------
Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Entity that triggers the
Other Participating Actors:
creation of the Use
Other Interested
Stakeholders: Case. E.g. Document
Description:

© e-Learning Centre, UCSC 41

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------

Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors:
Other Interested Who benefits from
Stakeholders: the use case
Description:

© e-Learning Centre, UCSC 42

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------
Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors:
Other Interested
Stakeholders: Facilitating Actors
Description:

© e-Learning Centre, UCSC 43

4.4 Business process documentation with use cases
and use case descriptions
e.g. High Level Version of a Use-Case Narrative

Author (s): ---------------------- Date:----------------------

Version: ------------------

Use-Case Name:
Use-Case ID: Use-Case Type
Priority: Business Requirements:
Source:
Primary Business Actor:
Other Participating Actors:
General understanding
Other Interested
Stakeholders: of problem domain and
Description: scope
In brief
© e-Learning Centre, UCSC 44
Sample High-Level Use-Case Narrative

© e-Learning Centre, UCSC 45

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
Typically another
- Trigger Use Case that must
- Typical Course of Events be previously
- Alternate Courses executed.
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 46

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger
Time receiving a cheque.
- Typical Course of Events
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 47

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as eg. Borrowing :

- Preconditions checkMember,
- Trigger checkOverdue,
- Typical Course of Events checkOverLimit,
checkCopyBorrowable,
- Alternate Courses
confirm Borrowing
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 48

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Errors, Confirm Messages
- Typical Course of Events
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 49

4.4 Business process documentation with use cases
and use case descriptions

e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Receipt Delivered to the
- Typical Course of Events Customer
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 50

 Summary
• Use Case Modeling is the process of modeling a system’s
functions in terms of business events, who initiated the
events, and how the system responds to those events.
• Shows the interactions between the system and external
systems / users.
• Graphically describes who will use the system and in what
ways the user expects to interact with the system.
• A Subject Boundary represents the scope of the subject.
• The elements of a use-case diagram include actors, use cases,
subject boundaries, and a set of relationships among actors,
actors and use cases, and use cases. These relationships
consist of association, include, extend, dependency and
generalization relationships.
• Actor is anyone or anything that needs to interact with the
system to exchange information.

© e-Learning Centre, UCSC 51

 Summary cont…
• Actors can be associated with other actors using a
specialization/superclass association and are labelled with a
noun phrase.
• A use case represents a major piece of system functionality.
• A Use Case can extend another use case or can include
another use case.
• A Use Case is placed inside the system boundary and is
labeled with a descriptive verb–noun phrase.
• An association relationship links an actor with the use case(s)
with which it interacts.
• An include relationship represents the inclusion of the
functionality of one use case within another and has an arrow
drawn from the base use case to the used use case.

© e-Learning Centre, UCSC 52

 Summary cont…
• An extend relationship represents the extension of the use
case to include optional behavior and has an arrow drawn
from the extension use case to the base use case.
• Generalization relationship represents a specialized use case
to a more generalized one and has an arrow drawn from the
specialized use case to the base use case.
• Steps to create a Use Case Diagram are:
• review the requirements definition, identify the subject’s boundaries,
identify the primary actors and their goals, simply identify the
business processes and major use cases, and carefully review the
current set of use cases.
• It may be necessary to split some of them into multiple use cases or
merge some of them into a single use case. Also, based on the current
set, a new use case may be identified.

© e-Learning Centre, UCSC 53

 Summary cont…
• Use-case descriptions/narratives provide a means to more
fully document the different aspects of each individual use
case.
• Use-case descriptions contain all the information needed to
document the functionality of the business processes.
• A use-case description or Use Case narrative contains all the
information needed to build the structural and behavioral
diagrams that follow, but it expresses the information in a
less-formal way that is usually simpler for users to
understand.
• Most analysts first start with a high-level version of a narrative
and subsequently prepare the expanded version. There is no
standard template exist for use case narratives.

© e-Learning Centre, UCSC 54

5-Business Process Modelling with Activity
Diagram
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will

• Be introduced to Activity Diagrams with their
benefits
• Learn Components of a Activity Diagram, and
steps involved in drawing the diagram
• Learn to Verify and Validate the Business
Processes and Functional Models

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• Able to describe the benefits of using Business
Process Modelling with Activity Diagram
• Able to model Use-Case activities using Activity
Diagrams
• Able to Identify and describe the steps for
preparing an Activity diagram
• Able to Identify and draw swim lanes,
synchronization bars in activity diagrams
• Able to draw an Activity Diagram for a given
Scenario
© e-Learning Centre, UCSC 3
 List of sub topics
5. Business Process modeling with Activity Diagrams
(3 hours)
5.1 Introduction to Activity Diagrams [Ref 1: Pg. 129-130]
5.2 Elements of an Activity Diagram [Ref 1: Pg. 131-136]
5.2.1 Actions and Activities
5.2.2 Object Nodes
5.2.3 Control Flows and Object Flows
5.2.4 Control Nodes (Initial, final-activity, final-flow, decision,
merge, fork, and join)
5.1.4 Swimlanes
5.3 Creating Activity Diagrams [Ref 1: Pg. 136-140]
5.4 Verifying and Validating the Business Processes and
Functional Models [Ref 1: Pg. 153-157]

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An
Object Oriented Approach with UML : an object oriented approach, 5th
edition, John Wiley & Sons, 2015, ISBN 978-1-118-80467-4

© e-Learning Centre, UCSC 4

5.1 Introduction to Activity Diagrams

• Models the process steps or Use Case activities of

the system.
• They represents the dynamics of a system.
• They are similar to flow charts.
• They graphically show the work flow of a system.

© e-Learning Centre, UCSC 5

5.1 Introduction to Activity Diagrams

• They show the flow of control from activity to

activity in the system.
• They show what activities can be done in parallel,
( That is where they are different from flowcharts.)
• They also show alternative paths through the flow.
• used to model the behavior in a business process
independent of objects. Hence they can be used
with Non object oriented approaches.

© e-Learning Centre, UCSC 6

5.1 Introduction to Activity Diagrams

• After creating a use case diagram, activity

diagrams may be created to represent the flow
across use cases or they may be created to
represent the flow within a particular use case.
• Activity diagrams may also be created to show
the workflow for an operation.

© e-Learning Centre, UCSC 7

5.2 Elements of an Activity Diagrams

Activity diagrams contain :

• Activities,
• Transitions between activities,
• Decision points,
• Synchronization bars.
• Swimlanes

© e-Learning Centre, UCSC 8

5.2 Elements of an Activity Diagrams

Activity

• Represented in UML by a rounded rectangle.

• Activity represents the performance of some
behavior in the work flow.

© e-Learning Centre, UCSC 9

Transitions

• Transitions are used to show the passing of the

flow of control from activity to activity.
• They are typically triggered by the completion of
the behavior in the originating activity.

© e-Learning Centre, UCSC 10

Decision Points

• When modeling the workflow of a system, it is

often necessary to show where the flow of control
branches based on a decision point.
• The transition from a decision point contain a guard
condition.

© e-Learning Centre, UCSC 11

 Decision Points cont..

• The guard condition is used to determine which

path from the decision point is taken.
• Decisions along with their guard conditions allow
you to show alternative paths through a work flow.

© e-Learning Centre, UCSC 12

Merge Point

• Two or more flows come in and one flow

goes out.
• This combines flows that were previously
separated by decisions.
• Processing continues with any one flow
coming into the merge.

© e-Learning Centre, UCSC 13

Synchronization Bars

• In a workflow there are typically some

activities that may be done in parallel.
• A synchronization bar allows you to specify
what activities may be done concurrently.

© e-Learning Centre, UCSC 14

Join

• Synchronization bars used to show joins

in the workflow.
• ie. What activities must complete
before processing may continue.
• All actions coming into the join must be
completed before processing continues.

© e-Learning Centre, UCSC 15

Fork

• Synchronization bars can also be used to

show forks in the workflow.
• Actions on parallel flows beneath the folk
can occur in any order or concurrently.

© e-Learning Centre, UCSC 16

 An object node
• Is used to represent an object that is connected to a
set of object flows.
• Is labeled by its class name.

An Object Node

© e-Learning Centre, UCSC 17

Activity control nodes overview.
Parallel activities

© e-Learning Centre, UCSC 18

Swim lanes

• Swim lanes may be used to partition an

activity diagram.
• This facility allows activity diagrams to
expand and show who has the
responsibility for each activity in a
process.

© e-Learning Centre, UCSC 19

Swim lanes cont…

Eg:- Consider a consulting firm and the business

process involved in meeting a new client;
Following are the activities:
- A salesperson calls the client and sets up an
appointment.
- If the appointment is onsite, corporate technicians
prepare a conference room for a presentation.

© e-Learning Centre, UCSC 20

Swim lanes cont…

- If the appointment is offsite, a consultant prepares

a presentation on a laptop.
- The consultant and the salesperson meet with the
client at the agreed-upon location and time.
- The salesperson follows up with a letter.
- If the meeting has resulted in a statement of a
problem, the consultant creates a proposal and
sends it to the client

© e-Learning Centre, UCSC 21

 An Activity Diagram

© e-Learning Centre, UCSC 22

Eg. Activity diagram for Manage appointment Use Case

© e-Learning Centre, UCSC 23

© e-Learning Centre, UCSC 24
New concepts included in UML 2.0
Passage of time =>
Eg. Accept time event

3-6 Min

Eg. Action Node Open Door Close Door

Wait 10 seconds

Send company tax return

End of business year occurred

© e-Learning Centre, UCSC 25

New concepts included in UML 2.0
cont…
• Exception activity
• Use to show an interrupting activity.

• Subactivity indicator
• Action invokes another
activity

© e-Learning Centre, UCSC 26

5.3 Creating Activity Diagrams

• There are five steps in creating an activity diagram to

document and model a business process.
1. choose a business process that was previously identified
to model.
2. identify the set of activities necessary to support the
business process.
3. identify the control flows and nodes necessary to
document the logic of the business process.
4. identify the object flows and nodes necessary to support
the logic of the business process.
5. layout and draw the activity diagram to document the
business process.

© e-Learning Centre, UCSC 27

5.4 Verifying and Validating the Business Processes
and Functional Models

• We need to verify and validate the current set of

functional models to ensure that they faithfully
represent the business processes under consideration.
• for example, we must be sure that the activity
diagram(s), use-case descriptions, and use-case
diagrams all describe the same functional
requirements.
• Before we describe the specific tests to consider, we
describe walkthroughs, a manual approach that
supports verifying and validating the evolving models.

© e-Learning Centre, UCSC 28

Verification and Validation through Walkthroughs
• A walkthrough which is a review of the different models and
diagrams created during functional modeling.
• This interactive review typically is completed by a team
whose members come from the development team and the
client.
• The purpose of a walkthrough is to thoroughly test the
consistency of the functional models to the functional
requirements.
• a walkthrough uncovers errors or faults in the evolving
specification. However, a walkthrough does not correct
errors—it simply identifies them. Error correction is to be
accomplished by the team after the walkthrough is
completed.

© e-Learning Centre, UCSC 29

 Verification and Validation through Walkthroughs cont….
Typical members of a walkthrough are :
• the presenter : should be played by the person who is primarily
responsible for the specific representation being reviewed. This
individual presents the representation to the walkthrough team.
• recorder, or scribe: should be a member of the analysis team. This
individual carefully takes the minutes of the meeting by recording
all significant events that occur during the walkthrough. In
particular, all errors that are uncovered must be documented so
that the analysis team can address them.
• Another role is to have someone who raises issues regarding
maintenance of representation. Owing to the emphasis on
reusability in object-oriented development, this role becomes
particularly crucial.
• And someone must be responsible for calling, setting up, and
running the walkthrough meetings.

© e-Learning Centre, UCSC 30

Functional Model Verification and Validation

• suggested three different representations for the functional model:

❖ activity diagrams,
❖use-case descriptions,
❖and use-case diagrams.
• These three representations should be consistent among themselves.
Eg- When comparing an activity diagram to a use-case description there
should be at least one event recorded in the normal flow of events,
sub flows, or alternative/exceptional flows of the use-case description
for each activity or action that is included on an activity diagram, and
each event should be associated with an activity or action.
- Objects portrayed as an object node in an activity diagram must be
mentioned in an event in the normal flow of events, sub flows, or
alternative/exceptional flows of the use-case description.
- Sequential order of the events in a use-case description should occur
in the same sequential order of the activities contained in an activity
diagram.

© e-Learning Centre, UCSC 31

 Summary
• Models the process steps or Use Case activities of the system
and graphically show the work flow of a system.
• After creating a use case diagram, activity diagrams may be
created to represent
➢ the flow across use cases or
➢ the flow within a particular use case.
➢ to show the workflow for an operation.
• Activity diagrams contain activities, transitions between
activities, decision points, synchronization bars and
swimlanes.
• Synchronization bars used to show joins in the workflow
which shows what activities must complete before processing
may continue.
• Synchronization bars can also be used to show forks in the
workflow. Actions on parallel flows beneath the folk can occur
in any order or concurrently

© e-Learning Centre, UCSC 32

 Summary cont..
• Swim lanes may be used to partition an activity diagram. This
facility allows activity diagrams to expand and show who has the
responsibility for each activity in a process.
• We need to verify and validate the current set of functional
models (use case, activity diagrams, use case descriptions) to
ensure that they consistently represent the business processes
under consideration.
• Walkthroughs is a manual approach that supports verifying and
validating the evolving models.
• The purpose of a walkthrough is to thoroughly test the
consistency of the functional models to the functional
requirements.
• a walkthrough uncovers errors or faults in the evolving
specification. However, a walkthrough does not correct errors but
simply identifies them.

© e-Learning Centre, UCSC 33

 6. Structural Modelling using Class,
Package Diagrams
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview
In this section students will
• learn how the objects underlying the behavior
modeled in the business process and functional
models are organized and presented,
• be introduced to Class Diagrams with their
benefits.
• learn CRC cards, Object Diagram, and steps
involved in creating them
• learn to Verify and Validate the diagrams.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes
At the end of this lesson students will be able to
• understand the rules and style guidelines for creating
CRC cards, class diagrams, and object diagrams,
• identify the UML concepts of Stereotypes,
• create Structural Models using CRC cards,
• draw Class Diagrams and Object Diagrams,
• illustrate the definitions of association, composition
relationships between classes in the system,
• define reflexive relationships,
• illustrate the application of generalization and
specialization principles to discover super
class/subclass relationships,
• verify and validate the Structural Model.

© e-Learning Centre, UCSC 3

 List of Subtopics
6. Structural Modelling using Class Diagrams (6 hours)
6.1 Introduction to structural modeling [Ref 1: Pg. 163-164]
6.2 Basic elements of structural models [Ref 1: Pg. 164-166,
Ref 4]
6.2.1 Classes, Attributes, and Operations
6.2.2 Relationships
6.2.2.1 Association
6.2.2.2 Aggregation, Composition
6.2.2.3 Generalization
6.3 Object Identification [Ref 1: Pg. 166-172]
6.3.1 Textual Analysis
6.3.2 Brainstorming
6.3.3 Common Object Lists
6.3.4 Patterns
© e-Learning Centre, UCSC 4
 List of Subtopics cont…
6.4 CRC Cards [Ref 1: Pg. 172-175]
6.4.1 Responsibilities and Collaborations
6.4.2 Elements of a CRC Card
6.4.3 Role-Playing CRC Cards with Use Cases
6.5 Class, Package Diagrams [Ref 1: Pg. 176-184, Pg. 263-265]
6.6 Creating Structural Models using CRC cards and Class
Diagrams [Ref 1: Pg. 185-194]
6.7 Verifying and Validating the Structural Model [Ref 1: Pg.
194-197]

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems

analysis design, An Object-Oriented Approach with UML:
an object-oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4

© e-Learning Centre, UCSC 5

6.1 Introduction to Structural Modeling
• During analysis, analysts create business process and
functional models to represent how the business
system will behave.
• At the same time, analysts need to understand the
information that is used and created by the business
system (e.g., customer information, order information).
• A structural model is a formal way of representing the
objects that are used and created by a business system.
• It illustrates people, places, or things about which
information is captured and how they are related to
one another.
• The structural model is drawn using an iterative process
in which the model becomes more detailed and less
conceptual over time.

© e-Learning Centre, UCSC 6

6.1 Introduction to Structural Modeling

• In analysis, analysts draw a conceptual model, which shows

the logical organization of the objects without indicating
how the objects are stored, created, or manipulated.
• This model is free from any implementation or technical
details, hence the analysts can focus more easily on
matching the model to the real business requirements of
the system.
• In design, analysts evolve the conceptual structural model
into a design model that reflects how the objects will be
organized in databases and software.
• At this point, the model is checked for redundancy, and the
analysts investigate ways to make the objects easy to
retrieve.

© e-Learning Centre, UCSC 7

6.1 Introduction to Structural Modeling
• Structural models represent the things, ideas, or
concepts contained in the domain of the problem.
• They also allow the representation of the
relationships among the things, ideas, or concepts.
• Typically, structural models are shown using CRC
cards, class diagrams, and, in some cases, object
diagrams.

© e-Learning Centre, UCSC 8

 6.2 Basic Elements of Structural Models
Classes, Attributes, and Operations
Objects
eg.
- A Toshiba
Washing
e.g. Class WashingMachine Machine
Attributes brandName - A Panasonic
modelName Washing
serialNumber Machine
capacity
addClothes()
Services addDetergent()
/Operations removeClothes()

© e-Learning Centre, UCSC 9

6.2 Basic Elements of Structural Models
The Need for Relationships

• All systems are made up of objects and

classes.
• Conceptually, objects do not exist in isolation.
• System behavior is achieved through the
interactions of the objects in the system.

© e-Learning Centre, UCSC 10

6.2 Basic Elements of Structural Models
The Need for Relationships

Example :
• When a member wants to borrow a book in a
library system (borrowing use case), the system has
to interact with the following objects:
book, copy, borrower and borrowed copy
• For the borrowing use case following are some of
the messages that these objects have to send and
receive.
checkBorrowerId , checkCopyBorrowable,
checkOverdue, checkOverlimit etc.
© e-Learning Centre, UCSC 11
6.2 Basic Elements of Structural Models
The Need for Relationships

• When there is an object interaction, it

indicates there is a Relationships
between the corresponding classes.
• A relationship is a semantic connection
between classes.
• It allows one class to know about the
attributes, operations of another class.

© e-Learning Centre, UCSC 12

6.2 Basic Elements of Structural Models
Relationships

• There are many different types of relationships

that can be defined, but all can be classified
into three basic categories of data abstraction
mechanisms:
• Association Relationships,
• Aggregation/Composition Relationships, and
• Generalization Relationships.

© e-Learning Centre, UCSC 13

6.2 Basic Elements of Structural Models
Associations
• Indicate a connection (a link) between classes.
• Each class can send messages to the other.
• It can be bi-directional or unidirectional.
• In UML 2;
• Bi-directional associations are drawn without
arrowheads altogether.
• Unidirectional associations have a single arrow.

Customer 1 0..* Orders

Borrower 1 0..5 BorrowedCopy

© e-Learning Centre, UCSC 14
6.2 Basic Elements of Structural Models
Associations

Example
• PersonDetails object has an object reference to the
Address object, but not vice versa.
• Messages can only be sent from PersonDetails to
Address.

Person Details Address

Unidirectional Link

© e-Learning Centre, UCSC 15

6.2 Basic Elements of Structural Models
Associations

• An aggregation is a stronger form of association.

• It is a relationship between a whole and its parts or
composition.
Aggregation
(Removed in
UML 2.0)
0..* 0..*
Aircraft Engine
1 1..*
School Department

Composition
© e-Learning Centre, UCSC 16
 6.2 Basic Elements of Structural Models
Specifying Relationships
• Association Relationships

• Aggregation
Stronger form of Association

• Generalization

• Dependency Relationship
Weaker form of relationship

Client Supplier

© e-Learning Centre, UCSC 17

6.2 Basic Elements of Structural Models
Specifying Relationships
• Association Syntax
Associations may have:
- an association name , role names , multiplicity
and navigability
Role name

+Employer +Employee
Company Person
1 *
Navigability
Multiplicity

© e-Learning Centre, UCSC 18

6.2 Basic Elements of Structural Models
Specifying Relationships

• An Association may be named.

eg. employs
• Usually the name of the association is an active verb or
verb phrase that communicates the meaning of the
relationship.
eg. a Lecturer teaches a Course
• Association name is optional.
• Names are added to improve the clarity .
• Aggregation relationships typically are not named. They
are read using the words “has”, “part of” or “contains”.

© e-Learning Centre, UCSC 19

 6.2 Basic Elements of Structural Models
Role Names

• The end of an association where it connects to a

class is called an association role.
• Role name can be used instead of association
names.
• It is a noun that describes the reason the
relationship exists.
• The role name is placed on the association near the
class it modifies.
+Teacher
Course Offering Lecturer
© e-Learning Centre, UCSC 20
6.2 Basic Elements of Structural Models
Role Names

• A role name may be placed on one or both ends of

an association line.
• It is not necessary to have both a role name and an
association name.

+Teacher
Course Offering Lecturer

© e-Learning Centre, UCSC 21

6.2 Basic Elements of Structural Models
Multiplicity Indicators

1 Exactly one

0..* Zero or more

1..* One or more

0..1 Zero or one

5..8 Specific Range (5,6,7 or 8)

© e-Learning Centre, UCSC 22

6.2 Basic Elements of Structural Models
Reflexive Relationships

• Sometimes a class is in an association with itself.

• This can happen when a class has objects that can
play a variety of roles.
• This is shown on the class diagram as a reflexive
association or aggregation.
• Role names rather than association names are
typically used for reflexive relationships.

© e-Learning Centre, UCSC 23

6.2 Basic Elements of Structural Models
Reflexive Relationships cont…

• One Course object playing the role of Prerequisite

is related to zero or more course objects.
• One Course object is related to zero or more course
objects playing the role of Prerequisite.

CourseOffering Course +Pre-requisites

0..*
0..*

© e-Learning Centre, UCSC 24

6.2 Basic Elements of Structural Models
Inheritance (Generalization)

• Provides the capability to create a hierarchy of

classes.
• Common structure and behavior are shared among
classes.
• The term super-class is the name given to the class
holding the common information.
• The descendants are called subclasses.
• A subclass inherits all attributes, operations, and
relationships that are defined for all of its super-
classes.

© e-Learning Centre, UCSC 25

6.2 Basic Elements of Structural Models
Inheritance (Generalization)

• An inheritance relationship:
• is not a relationship between different objects.
• is a relationship between different classes.
• is never named.
• Role names are not used.
• Multiplicity does not apply.
• Inheritance is the key to reuse.
• A class can be created for one application
• A sub class may be created to add more
information needed for a different application.

© e-Learning Centre, UCSC 26

6.2 Basic Elements of Structural Models
Inheritance (Generalization)

• There are two ways to find inheritance in any

system: Generalization and Specialization.
• Generalization provides the capability to create
super-classes that encapsulate structure and
behavior common to several classes.
• Specialization provides the ability to create
subclasses that represent refinement to the super-
class. Typically structure and behavior are added to
the new subclass.

© e-Learning Centre, UCSC 27

6.2 Basic Elements of Structural Models
Single Inheritance vs. Multiple Inheritance

• With Single inheritance, a class has one set of

parents.
• Savings A/C is a kind of Account.
• Multiple inheritance involves more than one chain
of super-classes.
• Interest cheque A/C is a kind of Savings A/C and
also a kind of Current A/C.

© e-Learning Centre, UCSC 28

 6.3 Object Identification

•
•
•
•
•
•

© e-Learning Centre, UCSC 29

6.3 Object Identification

• The analyst performs textual analysis by reviewing

the use-case diagrams and examining the text in the
use-case descriptions to identify potential objects,
attributes, operations, and relationships.
• The nouns in the use case suggest possible classes,
and the verbs suggest possible operations.

© e-Learning Centre, UCSC 30

6.3 Object Identification

• Brainstorming is a process that a set of individuals

suggest potential classes that could be useful for
the problem under consideration.
• Once a sufficient number of candidate objects
have been identified, the participants should
discuss and select which of the candidate objects
should be considered further.
• Further brainstorming can take place to identify
potential attributes, operations, and relationships
for each of the identified objects.

© e-Learning Centre, UCSC 31

6.3 Object Identification

• A common object list is simply a list of objects

common to the business domain of the system.
• There are libraries of reusable objects that have
been created for different business domains.
• These objects can be used as the initial list objects.

© e-Learning Centre, UCSC 32

6.3 Object Identification

• There are many definitions of a pattern.

• A pattern is simply a useful group of collaborating classes
that provide a solution to a commonly occurring problem.
• Patterns provide a solution to commonly occurring
problems, and hence they are reusable.
• We can look at the objects previously identified through
textual analysis, brainstorming, and/or common object lists
and see if it makes sense to map any of them into any
predefined reusable patterns.
• If we are developing a business information system in one of
the business domains where patters have been identified,
then the patterns developed for that domain may be a very
useful starting point in identifying needed classes and their
attributes, operations, and relationships.
© e-Learning Centre, UCSC 33
6.4 CRC Card
• CRC (Class–Responsibility–Collaboration) cards are used to
document the responsibilities and collaborations of a class.
Responsibilities and Collaborations
• Responsibilities : Knowing , Doing
• Collaboration : Objects working together to service a
request
• Object oriented systems are made up of objects working
together to provide functionality.
• CRC cards can help to form a “bridge” from structural model
to behavioral model.

© e-Learning Centre, UCSC 34

6.4 CRC Card
CRC Card Template

Class Name :BankAccount

Responsiblities Collaborators
Maintain Balance Bank

Other classes that may

Collaborate with
Candidate Class BankAccount Class to
realize the responsibility

© e-Learning Centre, UCSC 35

 Sample CRC Card
(No Standard Template)

© e-Learning Centre, UCSC 36

6.4 CRC Card

• Extremely simple technique

• Rather than using diagrams to develop models use
4 x 6 index cards
• Rather than indicating attributes and operations on
the cards, they identify responsibilities and
collaborators

© e-Learning Centre, UCSC 37

6.4 CRC Card
Elements of a CRC Card

• The name of the class, at the top

• The responsibilities of the class, on the
left-hand side
• The collaborators of the class, which help
to carry out each responsibility, on the
right-hand side of the card

Many templates exist

© e-Learning Centre, UCSC 38

6.4 CRC Card
Role-Playing CRC Cards with Use Cases

• CRC cards are used to document the essential

properties of a class.
• Once the cards are filled out, the analyst can use the
cards in role-playing
• Each CRC card should be assigned to an individual who
will perform the operations for the class on the CRC
card.
• It is used to uncover missing properties by executing the
different scenarios associated with the use cases.
• Role-playing also can be used as a basis to test the
clarity and completeness of the evolving representation
of the system.

© e-Learning Centre, UCSC 39

Typical steps in , Role-Playing CRC Cards with Use Cases
1. Create CRC Cards : Create the CRC cards first and then transfer the
information into a class diagram later.
2. Review CRC Cards : Review the CRC cards to determine if
additional candidate objects, attributes, operations, and
relationships are missing.
3. Role-Play the CRC Cards : Each CRC card should be assigned to an
individual who will perform the operations for the class on the
CRC card.
4. Create Class Diagram : Information contained on the CRC cards is
transferred to the class diagrams.
5. Review Class Diagram : review the structural model for missing
and/or unnecessary classes, attributes, operations, and
relationships.
6. Incorporate Patterns : incorporate useful patterns into the
evolving structural model. A useful pattern is one that would allow
the analyst to more fully describe the underlying domain of the
problem being investigated.
7. Review the Model: validate the structural model, including both
the CRC cards and the class diagram.

© e-Learning Centre, UCSC 40

6.5 Class, Package Diagrams

Stereotypes and Classes

A Stereotype is a mechanism you can use to
categorize your classes.
• Say you want to quickly find all of the forms in the
model,
• You could create a stereotype called form, and
assign all of your windows to this stereotype.
• To find your forms later, you would just need to
look for the classes with that stereotype.

© e-Learning Centre, UCSC 41

6.5 Class, Package Diagrams
Stereotypes and Classes
• There are three primary class stereotypes in
UML.

Boundary

Entity

Control
© e-Learning Centre, UCSC 42
6.5 Class, Package Diagrams
Stereotypes and Classes

Boundary Class:
• They provide the interface to a user or another
system. (ie. Interface to an actor).
• Handles communication between system
surroundings and the inside of the system.
• To find the Boundary classes, you can examine your
Use Case diagram.

© e-Learning Centre, UCSC 43

6.5 Class, Package Diagrams
Stereotypes and Classes

Boundary Class:
• At a minimum there must be, one Boundary class
for every actor-use case interaction.
• Boundary class allows actor to interact with the
system.

Use Case 1
Actor 1
Boundary Class
© e-Learning Centre, UCSC 44
 6.5 Class, Package Diagrams
Stereotypes and Classes
Boundary Class:
• You do not necessarily have to create a unique
Boundary class for every actor-use case pair.
• Two actors may initiate the same use case.
• They might both use the same Boundary class to
communicate with the system.
Actor 1

Actor 2 Use Case 1

Boundary Class
© e-Learning Centre, UCSC 45
6.5 Class, Package Diagrams
Stereotypes and Classes

These are classes that mediate between the subject

(System boundary) and its environment.
• User Interface class – classes that interface between the
system and humans;
• System Interface class – classes that interface with other
systems;
• Device Interface class – classes that interface with
external devices such as sensors;

© e-Learning Centre, UCSC 46

6.5 Class, Package Diagrams
Stereotypes and Classes

Entity Class
• They are needed to perform task internal to the
system. Reflect a real world entity.
Identifying Entity Classes
Noun/Verb Analysis
• Identify the nouns and noun phrases

© e-Learning Centre, UCSC 47

6.5 Class, Package Diagrams
Stereotypes and Classes

Entity Class
• The initial list of nouns must be filtered
because it could contain nouns that are ,
• outside the problem domain.
• just language expressions.
• redundant.
• attributes.

© e-Learning Centre, UCSC 48

 6.5 Class, Package Diagrams
Stereotypes and Classes

Control Class:
• Sequencing behaviour specific to one or more
use cases.
• There is typically one control class per use case.
• Co-ordinates the events needed to realise the
behaviour specified in the use case.
E.g. Running or executing the use case.

© e-Learning Centre, UCSC 49

6.5 Class, Package Diagrams
Finding Controller Classes

• Simple behavior can often be distributed between

Boundary or Entity classes.
• Consider more complex behavior of the system as
described by the use cases.
• Work out how these behavior should be partitioned
among the analysis classes.
• Control classes process messages from an interface
class and respond to them by sending and receiving
messages from the entity classes.

© e-Learning Centre, UCSC 50

 6.5 Class, Package Diagrams
Class Diagrams
• They are backbone of nearly all OO
Methods/Processes.
• A class diagram describes the types of objects in the
system and the various kinds of static relationships
that exist among them.
• It also shows the attributes and services of a class
and the constraints that apply to the way objects are
connected.
Book
UML Notation Accno
Title
for a Class Author
GetAuthor(int)
© e-Learning Centre, UCSC 51
 Can be a Composition-depends on
the problem domain. This will be an
6.5 Class, Package Diagrams association with latest UML versions
Class Diagram Example

© e-Learning Centre, UCSC 52

 6.5 Class, Package Diagrams
Package Diagrams
• A Package is a general construct that can be applied to any of the
elements in UML models. A package is a collection of logically
related UML elements.
• Package diagram is used to simplify complex class diagrams,
you can group classes into packages.
• A package diagram is effectively a class diagram that only shows
packages. They are used to simplify complex class diagrams,
• By grouping classes to packages we can look at the higher-level
view of the model.
• Package diagrams help you to maintain control over a system’s
overall structure

© e-Learning Centre, UCSC 53

6.5 Class, Package Diagrams
An Example of a Package Diagram

© e-Learning Centre, UCSC 54

6.5 Class, Package Diagrams
Package Diagram Syntax

© e-Learning Centre, UCSC 55

6.6 Creating Structural Models using CRC cards
and Class Diagrams
• Creating a structural model is an incremental and iterative
process whereby the analyst makes a rough cut of the model
and then refines it over time.
• A use-case–driven process that can be used to create the
structural model of a problem domain.
• Create CRC Cards : Create the CRC cards first and then transfer the information
into a class diagram later.
• Role-Play the CRC Cards : Each CRC card should be assigned to an individual
who will perform the operations for the class on the CRC card. Role-playing the
CRC cards, requires to apply the three role-playing steps. Review Use Cases,
Identify Relevant Actors and Objects, Role Play Scenarios
• Create Class Diagram : Information contained on the CRC cards is transferred
to the class diagrams.
• Review Class Diagram : Review the structural model for missing and/or
unnecessary classes, attributes, operations, and relationships.
• Review the Model : Validate the structural model, including both the CRC
cards and the class diagram.
© e-Learning Centre, UCSC 56
6.7 Verifying and Validating the Structural Model
• Before creating behavioral models of the problem domain, we
need to verify and validate the structural model.
• Walkthroughs with the power of role-playing can be used to
more completely verify and validate the structural model that
will underlie the business processes and functional models.
• First the analyst walks through the model, explaining each part
of the model to developers and users.
• He needs to describe all the reasoning behind the decision to
include each of the classes in the structural model.
• Each class should be linked back to at least one use case.
• Every CRC card should be associated with a class on the class
diagram, and vice versa.

© e-Learning Centre, UCSC 57

6.7 Verifying and Validating the Structural Model
• The responsibilities listed on the front of the CRC card must be
included as operations in a class on a class diagram, and vice
versa. Every responsibility and operation must be checked.
• Collaborators on the front of the CRC card imply some type of
relationship on the back of the CRC card and some type of
association that is connected to the associated class on the
class diagram.
• Attributes listed on the back of the CRC card must be included
as attributes in a class on a class diagram, and vice versa.
• The object type of the attributes listed on the back of the CRC
card and with the attributes in the attribute list of the class on
a class diagram implies an association from the class to the
class of the object type.

© e-Learning Centre, UCSC 58

6.7 Verifying and Validating the Structural Model

• The relationships included on the back of the CRC

card must be portrayed using the appropriate
notation on the class diagram.
E.g. Generalization, composition, association, association
class etc.

• Verify and validate the functional model will ensure

the consistency of the structural representations
such as CRC cards and class diagrams.

© e-Learning Centre, UCSC 59

 Summary
• During analysis, analysts create business processes and
functional models to represent how the business system will
behave.
• At the same time, analysts need to understand the
information that is used and created by the business system
such as customer information, order information in an order
processing system.
• A structural model is a formal way of representing the objects
that are used and created by a business system.
• Typically, structural models are shown using CRC cards, class
diagrams, and, in some cases, object diagrams.
• All systems are made up of objects and classes. Conceptually,
objects do not exist in isolation. System behavior is achieved
through the interactions of the objects in the system.

© e-Learning Centre, UCSC 60

 Summary cont..
• A relationship is a semantic connection between classes. It
allows one class to know about the attributes, operations of
another class
• All can be classified into three basic categories of data
abstraction mechanisms: Association relationships.
Aggregation/Composition relationships (part of) , and
Generalization relationships (kind of).
• Sometimes a class is in an association with itself. This is called
reflexive relationship.
• The multiplicity is an indication of how many objects may
participate in the given relationship or the allowable number
of instances of the element.

© e-Learning Centre, UCSC 61

 Summary cont..
• Different approaches have been suggested to aid the analyst
in identifying a set of candidate objects for the structural
model.
• The four most common approaches to identify set of
candidate objects for the structural model are Textual analysis,
Brainstorming, Common object lists, and Patterns.
• The analyst performs textual analysis by reviewing the use-
case diagrams and examining the text in the use-case
descriptions to identify potential objects, attributes,
operations, and relationships. The nouns in the use case
suggest possible classes, and the verbs suggest possible
operations.
• Brainstorming is a process that a set of individuals suggest
potential classes that could be useful for the problem under
consideration.

© e-Learning Centre, UCSC 62

 Summary cont..

• A common object list is simply a list of objects common to the

business domain of the system.
• A pattern is simply a useful group of collaborating classes that
provide a solution to a commonly occurring problem.
• CRC cards are used to document the responsibilities and
collaborations of a class.
• In Role playing each CRC card should be assigned to an
individual who will perform the operations for the class on the
CRC card. It is used to uncover missing properties by executing
the different scenarios associated with the use cases.

© e-Learning Centre, UCSC 63

 Summary cont..
• A Stereotype is a mechanism you can use to categorize your
classes. Three stereotypes used for classes are Boundary,
Entity and Control.
• Boundary class provide the interface to a user or another
system.
• Entity classes are problem domain classes.
• Control Classes Co-ordinates the events needed to realize
the behaviour specified in the use case.
• A class diagram describes the types of objects in the system
and the various kinds of static relationships that exist among
them.

© e-Learning Centre, UCSC 64

 Summary cont..
• Creating a structural model is an incremental and iterative process
whereby the analyst makes a rough cut of the model and then refines
it over time.
• Before we move on to creating behavioral models of the problem
domain, we need to verify and validate the structural model.
• A use-case–driven process can be used to create the structural model
of a problem domain. Steps involve , Create CRC Cards, Role-Play the
CRC Cards, Create Class Diagram, Review Class Diagram , Validate the
structural models, including both the CRC cards and the class diagram.
• Walkthroughs with the power of role-playing can be used as a way to
more completely verify and validate the structural model that will
underlie the business processes and functional models.
• Verify and validate the functional model will ensure the consistency of
the structural representations such as CRC cards and class diagrams
***
© e-Learning Centre, UCSC 65
7. Behavioural Modelling using Interaction
Diagrams
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview
In this section students will
• develop scenarios to the system to describe how
Use Cases are realized as interactions among
societies of objects,
• describe a scenario using sequence diagrams and
communication diagrams.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes
At the end of this lesson students will be able to
• understand the rules and style guidelines for
sequence and communication diagrams,
• understand the processes used to create sequence
and communication diagrams,
• understand the relationship between the behavioral
models, structural models and functional models.

© e-Learning Centre, UCSC 3

 List of Subtopics
7. Behavioural Modelling using Interaction Diagrams (5 hours)
7.1 Introduction to Behavioural Modeling using Interaction
Diagrams [Ref 1: Pg. 203-204]
7.2 Sequence Diagrams [Ref 1: Pg. 204-215]
7.2.1 Elements of a Sequence Diagram
7.2.2 Creating Sequence Diagrams
7.3 Communication Diagrams [Ref 1: Pg. 216-221]
7.3.1 Elements of a Communication Diagram
7.3.2 Creating a Communication Diagram

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object-
Oriented Approach with UML : an object-oriented approach, 5th edition, John
Wiley & Sons, 2015, ISBN 978-1-118-80467-4

© e-Learning Centre, UCSC 4

 7.1 Introduction to Behavioural
Modeling using Interaction Diagrams
• Behavioral models describe the internal dynamic
aspects of an information system that supports the
business processes in an organization.
• During analysis, behavioral models describe what
the internal logic of the processes is without
specifying how the processes are to be
implemented.
• Later, in the design and implementation phases, the
detailed design of the operations contained in the
object is fully specified.

© e-Learning Centre, UCSC 5

 7.1 Introduction to Behavioural Modeling
using Interaction Diagrams
• The flow of events for a use case is captured in text,
whereas scenarios are captured in Interaction
diagrams.
• UML 1.x uses two types of Interaction Diagrams
o Sequence Diagrams,
o Collaboration/Communication Diagrams
• UML 2.0 introduces 2 more.
o Timing Diagrams,
o Interaction overview Diagrams
• Each Diagram is a graphical view of the scenario
typically associated with Use Cases in the mode

© e-Learning Centre, UCSC 6

 7.2 Sequence Diagrams
Sequence diagrams shows the
• object interactions arranged in time sequence.

• objects and classes involved in the scenario.

• sequence of messages exchanged between the

objects needed to carry out the functionality of the
scenario.

© e-Learning Centre, UCSC 7

Elements of a Sequence Diagram

Focus of Control (Activation Bar)

© e-Learning Centre, UCSC 8

Elements of a Sequence Diagram cont…

© e-Learning Centre, UCSC 9

 Creating Sequence Diagrams

• In UML, an object in a sequence diagram is drawn

as a rectangle, containing the name of the object,
underlined.
• An object can be named in one of the three ways:
• Object name,
• Object name and its class,
• Class name (anonymous object)

© e-Learning Centre, UCSC 10

 Creating Sequence Diagrams cont..

• UML Notation for objects and messages in a

sequence diagrams is shown below:

ACCNo-3545 :
:Borrower
Borrowed Copy

getOverdueDetails

Messages between objects

© e-Learning Centre, UCSC 11
Sequence Diagrams and Boundary classes
• Boundary classes are added to sequence diagrams to
show the interaction with the user or another
system.
• During the early analysis phases, boundary classes
are shown on a sequence diagram only to capture
and document the interface requirements.
• Actual messages from the actor to boundary class
with their sequencing information will depend on the
application framework that will be selected later in
development.

© e-Learning Centre, UCSC 12

 System Sequence Diagrams

• The system sequence diagram is a tool used by

some Analysts in logical design phase.
• The system sequence diagram helps to identify the
high-level messages that enter and exit the system.
o Later these messages will become the responsibility of
individual objects.
o These individual objects will fulfill those responsibilities
by communicating with other objects.

© e-Learning Centre, UCSC 13

 System Sequence Diagrams

Boundary object

messages
Actor

return messages

© e-Learning Centre, UCSC 14

e.g.

© e-Learning Centre, UCSC 15

 Use Case Narratives for Borrowing
Scenario: Library System
e.g. Borrowing Scenario Flow of Events
Main Flow
Librarian enters the borrower id.
System checks whether borrower id exist.
If not exist (E-1) end use case.
else Process
Check for Overdue Books.
If yes (E-2) end use case
Check Over limit (E-3)
If yes (E-3) end use case
© e-Learning Centre, UCSC 16
 Use Case Narratives cont..
Enter copy id
Check Borrow able (E-4)
If No (E-4) end use case
Librarian Confirm Borrowing (C-5)
Update Borrowed Copy details

Alternate Flows
E-1 : Borrower id exist
E-2 : There are overdue books
E-3 : Borrower has already borrowed 5 books (max)
E-4 : Copy is not borrow able
C-1 : Confirm borrowing Message box

© e-Learning Centre, UCSC 17

Initial Steps in Drawing Sequence
Diagram for Borrowing Scenario

© e-Learning Centre, UCSC 18

Borrowing Sequence Diagram with objects and messages
© e-Learning Centre, UCSC 19
Borrowing Sequence Diagram with objects and messages
© e-Learning Centre, UCSC 20
Borrowing Sequence Diagram with objects and messages
© e-Learning Centre, UCSC 21
Borrowing Sequence Diagram with objects and messages
© e-Learning Centre, UCSC 22
Borrowing Sequence Diagram
After mapping objects to classes and messages to methods
23
 Sequence Diagrams cont..

• Sequence diagrams should be kept as simple

as possible then
• it is easy to see:
o the objects,
o object interactions,
o the messages between the objects, and
o the functionality captured by the scenario.

© e-Learning Centre, UCSC 24

 Sequence Diagrams cont..

How to handle conditional logic in a sequence

diagram? (if, then, else logic that exists in the real
world)
• If the logic is simple, involving only a few messages:
o add the logic to one diagram and use notes to
communicate the choices to be made.
• If the logic is complex, involves complicated messages,
o draw a separate diagram- one for the if case, one for the
then case, and one for the else case.

This is done to keep the diagrams simple as possible.

© e-Learning Centre, UCSC 25
 Sequence Diagrams cont..

• In most I-CASE tools, diagrams may be linked to one

another.
• This allows the user to navigate through a set of
diagrams.

© e-Learning Centre, UCSC 26

 Focus of Control (Activation Bar)
• The focus of control is a small rectangle, that will let
you know which object has control at a particular
point in time.
• This is one of the differences between Sequence
and a Communication diagram.
• The focus of control is shown only on a sequence
diagram. (optional)
:Lecturer Math 1101 - Section1 :
CourseManager CourseOffering
Focus
of Control
Add Lecturer

© e-Learning Centre, UCSC 27

 Self Message(non-recursive) vs Self
Recursive Message
• A self message is a message that an object sends to
itself.
• It is a message that represents the invocation of
message of the same lifeline.
• A self message can represent
o a recursive call of an operation, or
o one method calling another method belonging to the
same object.

© e-Learning Centre, UCSC 28

How does Recursion work?

© e-Learning Centre, UCSC 29

Self Message (Recursive)
C++ example

30

© e-Learning Centre, UCSC 30

Self Message (Recursive)

© e-Learning Centre, UCSC 31

Self Message(non recursive) vs Self
Recursive Message

Non-Recursive Recursive
© e-Learning Centre, UCSC 32
 Message Constraints

Message interactions happen only if the condition is true

© e-Learning Centre, UCSC 33
E.g. Sequence Diagram: Add Details of a new Course

© e-Learning Centre, UCSC 34

 Framing in Sequence Diagrams

• Frame is a UML 2.* feature.

• One can frame a sequence diagram by surrounding
it with a border and adding a compartment in the
upper left corner.
• The compartment contains information that
identifies the diagram.
• These interaction fragments can be combined.
• Gives you a quick and easy way to reuse part of one
sequence diagram in another.

© e-Learning Centre, UCSC 35

 Interaction Fragment

Interaction Fragment
• An interaction fragment allows you to group related
messages in a sequence diagram.

The User sends a request to

the Account Page.
The two alternative responses
and the conditions on which
they depend, are contained
within an interaction fragment.

© e-Learning Centre, UCSC 36

 Combined Fragment

Combined Fragment
• is a subtype of interaction fragment.
• defines an expression of interaction fragments.
• defines by an interaction operator and
corresponding interaction operands.

© e-Learning Centre, UCSC 37

 Combined Fragment: Interaction
Operators
• A combined fragment defines an expression of
interaction fragments
• The following operators are commonly used in a
combined fragment expression
• Alt
• Opt
• Par
• Loop

© e-Learning Centre, UCSC 38

CLICK TO EDIT MASTER TITLE STYLE
• Click to edit Master text styles
• Second level
• Third level
• Fourth level
• Fifth level

© e-Learning Centre, UCSC 39

CLICK TO EDIT MASTER TITLE STYLE
• Click to edit Master text styles
• Second level
• Third level
• Fourth level
• Fifth level

© e-Learning Centre, UCSC 40

 Alt and Else Operators

• The interaction operator alt designates that the

combined fragment represents a choice of
behavior.
• At most one of the operands will be chosen.
• The chosen operand must have an explicit or implicit
guard expression that evaluates to true at this point in
the interaction.
• An implicit true guard is implied if the operand has no
guard.
• The set of traces that defines a choice is the union of the
(guarded) traces of the operands.

© e-Learning Centre, UCSC 41

 Alt and Else Operators

• An operand guarded by else designates a guard

that is the negation of the disjunction of all other
guards in the enclosing combined fragment.
• If none of the operands has a guard that evaluates to
true, none of the operands are executed and
• the remainder of the enclosing interaction fragment is
executed.

© e-Learning Centre, UCSC 42

CLICK TO EDIT MASTER TITLE STYLE
• Click to edit Master text styles
• Second level
• Third level
• Fourth level
• Fifth level

© e-Learning Centre, UCSC 43

Example of a Combined Fragment

© e-Learning Centre, UCSC 44

CLICK TO EDIT MASTER TITLE STYLE
• Click to edit Master text styles
• Second level
• Third level
• Fourth level
• Fifth level

© e-Learning Centre, UCSC 45

© e-Learning Centre, UCSC 46
 Opt and Break Operators
• Option: The interaction operator opt designates a
choice of behavior where either the (sole) operand
happens or nothing happens.
• Break: The interaction operator break represents a
breaking scenario: The operand is a scenario that is
performed instead of the remainder of the
enclosing interaction fragment.
• A break operator with a guard is chosen when the guard
is true
• The break operand is ignored, and the rest of the
enclosing interaction fragment is chosen when the guard
of the break operand is false.

© e-Learning Centre, UCSC 47

Opt Operator

© e-Learning Centre, UCSC 48

Loop and Break Operators

© e-Learning Centre, UCSC 49

 Parallel Operator

• Parallel: The interaction operator par designates a

parallel merge between the behaviors of the
operands of a combined fragment.
• The event occurrences of the different operands can be
interleaved in any way as long as the ordering imposed
by each operand is preserved.
• A parallel merge defines a set of traces that describes all
the ways that event occurrences of the operands may be
interleaved.

© e-Learning Centre, UCSC 50

 Critical Operator

• Critical: The interaction operator critical designates

that the combined fragment represents a critical
region.
• The traces of the region cannot be interleaved by other
event occurrences (on the Lifelines covered by the
region). This means that the region is treated atomically
by the enclosing fragment

© e-Learning Centre, UCSC 51

 Example of a Critical Region

The Operator must make sure to forward a 911-call to the Emergency

object before doing anything else. Normal calls can be freely interleaved.
© e-Learning Centre, UCSC 52
 Ref Operator
• Ref: Ref operator refers to a diagram defined
elsewhere with the sd operator

© e-Learning Centre, UCSC 53

 7.3 Communication Diagrams

© e-Learning Centre, UCSC 54

Elements of a Communication Diagram

© e-Learning Centre, UCSC 55

 Creating a Communication Diagrams

• An alternative way to show a scenario.

• Shows Object interactions organized around the
objects and their links to each other.
• A communication diagram contains:
o Objects drawn as rectangles.
o Links between objects shown as lines connecting the
linked objects.
o Messages shown as text and an arrow that points from
the client to the supplier.

© e-Learning Centre, UCSC 56

 Communication Diagrams cont..

UML Notation for objects, links and messages in a

communication diagram.

:LecturerCourseManager
1:Add Lecturer
3:Delete Lecturer

Math 101-Section 1:CourseOffering

© e-Learning Centre, UCSC 57

 Communication Diagrams cont..
Why do you need two different diagrams?
• Sequence diagrams :
o Show a scenario in a time-based order: what happens
first and what happens next.
o Customers can easily read and understand sequence
diagrams.
o Useful in early analysis phases.
• Communication diagrams :
o Tend to provide the big picture for a scenario.
o Organized around the object links to one another.
o Used more in the design phase of development

© e-Learning Centre, UCSC 58

 Communication Diagrams cont..
1: Enter borrower id
2: checkBorrowerExist( )
3: process
4: checkOverdue( )
7: Enter copy i d
6: checkOverli mit( )
11: confirm borrowi ng borrowing 12: i nformBorrower( )
form

a borrower :
borrower

: l ibrari an
5: getOverdueDetails( )
13: i nformBorrowedCopy( )

8: checkCopyExist( )
10: checkBorrowabl e( )
a borrowed copy : a book :
borrowedCopy book

9: getBookDetai ls( )

a copy :
copy

© e-Learning Centre, UCSC 59

Message Numbering in a Communication
Diagram
• A Sequence diagram is read from top to bottom.
• So, Message numbering is not necessary.
• A Collaboration diagram, however, losses its
sequencing information, if you do not have message
numbering.
• Message numbering can be turn on/off in Rational
Rose.

© e-Learning Centre, UCSC 60

Types of Messages in UML 2.*

© e-Learning Centre, UCSC 61

 Summary
• Behavioral models describe the internal dynamic aspects of
an information system that supports the business processes
in an organization.
• The flow of events for a use case is captured in text, whereas
scenarios are captured in Interaction diagrams.
• There are four interaction diagrams in UML 2.0.
Sequence Diagrams, Communication Diagrams, Timing
diagrams and Interaction overview diagrams.
• Each Diagram is a graphical view of the scenario typically
associated with Use Cases in the model.
• Sequence diagrams show object interactions arranged in time
sequence. It shows the sequence of messages exchanged
between the objects needed to carry out the functionality of
the scenario.
© e-Learning Centre, UCSC 62
 Summary cont..
• Boundary classes are added to sequence diagrams to show the
interaction with the user or another system.
• Actual messages from the actor to boundary class with their sequencing
information will depend on the application framework that will be
selected later in development.
• Keep sequence diagrams simple so that it is easy to see the objects,
object interactions, the messages between the objects, and the
functionality captured by the scenario.
• The focus of control is a small rectangle, that will let you know which
object has control at a particular point in time.
• Sequence diagrams show a scenario in a time-based order (what
happens first and what happens next).
• Customers can easily read and understand sequence diagrams. They are
useful in early analysis phases.
• An interaction fragment allows you to group related messages in a
sequence diagram.
• Combine fragment is a subtype of interaction fragment. It defines an
expression of interaction fragments defined by an interaction operator
and corresponding interaction operands

© e-Learning Centre, UCSC 63

 Summary cont..

• Communication diagrams, like sequence diagrams,

essentially provide a view of the dynamic aspects of an
object-oriented system. They can show how the members of
a set of objects collaborate to implement a use case or a
use-case scenario.
• Communication diagrams are equivalent to sequence
diagrams, but they emphasize the flow of messages through
a set of objects, whereas the sequence diagrams focus on
the time ordering of the messages being passed.
• Communication Diagrams tend to provide the big picture for
a scenario organized around the object links to one another.
They are used more in the design phase of development
*****

© e-Learning Centre, UCSC 64

8. Behavioural State Machines and Other
UML diagrams
IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will learn to

• draw state transition diagrams that provide
additional analysis techniques for classes with
significant dynamic behavior.
• timing, interaction Overview, Composite
Structure, Component, Deployment and
Profile Diagrams.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• understand the processes used to create
behavioral state machines, and CRUDE matrices,
• understand the relationship between the
behavioral models and the structural and
functional models,
• understand the Timing, interaction Overview,
Composite Structure, Component, Deployment
and Profile Diagrams.

© e-Learning Centre, UCSC 3

 List of sub topics

8 Behavioural State Machines and Other UML diagrams (5 hours)

8.1 Behavioural State Machines [Ref 1: Pg. 221-229]
8.1.1 States, Events, Transitions, Actions, and Activities
8.1.2 Elements of a Behavioral State Machine
8.1.3 Guidelines for Creating Behavioral State Machines
8.1.4 Creating a Behavioral State Machine
8.2 CRUDE Analysis [Ref 1: Pg. 229-232]
8.3 Verifying and Validating the Behavioral Model [Ref 1: Pg. 233-235]
8.4 Other UML Diagrams [Ref 1: Pg. 34-36, Ref 4]
Timing, interaction Overview, Composite Structure, Component,
Deployment and Profile Diagrams

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis design, An Object-
Oriented Approach with UML: an Object-Oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4
© e-Learning Centre, UCSC 4
8.1 Behavioural State Machines

• Some of the classes in the class diagrams represent

a set of objects that are quite dynamic and they
pass through a variety of states over the course of
their existence.
• Example: a patient can change over time from being
new to current to former based on his or her status with
the doctor’s office.
• A behavioral state machine is a dynamic model that
shows the different states through which a single
object passes during its life in response to events,
along with its responses and actions.

© e-Learning Centre, UCSC 5

8.1 Behavioural State Machines

More Examples:
• After an appropriate amount of time, a washing machine changes its
state from Washing to Rinsing.
• Hotel room changes its state to available, reserved and occupied.
• UML State diagram captures these kinds of changes.
• UML State Transition Diagrams shows:
• Life history showing the different states of a given object.
• The events or messages that cause a transition from one
state to another.
• The actions that results from a state change.
• State Diagrams are created only for classes with
significant dynamic behaviour.
eg. Hotel Room in a Hotel Reservation System

© e-Learning Centre, UCSC 6

8.1 Behavioural State Machines

Modeling Dynamic Behaviour

• Interaction diagrams can be studied to
determine the dynamic objects.
• Objects receive and send many messages.
• If you have an attribute called status.
• This can be a good indicator of various
states.

© e-Learning Centre, UCSC 7

States
Condition or Situation during the life of an object

• eg. HotelRoom object can be in one of the

following states.
• Occupied, Available, Reserved
• eg. Course object (in a course registration system)
can be in one of the following states.
• Initialization,Open, Close,Cancel
UML Notation for a State

© e-Learning Centre, UCSC 8

State Transitions
• A State Transition represents a change from an originating
state to a successor state.
• An action can accompany a state transition.
• A State Transition is represented by an arrow that points
from the originating state to the successor state.

UML Notation for State Transition

© e-Learning Centre, UCSC 9

Special States

• There are two special states that are added to the

state transition diagram.
• Start state – Each diagram must have one and only
one start state.
• Stop state – An object can have multiple stop
states.

Start State Stop State

© e-Learning Centre, UCSC 10

Guidelines for creating State Diagrams
•E

• The third step is to determine the sequence of the states that

an object will pass through during its lifetime.
• The fourth step is to identify the transitions between the
states of the objects and to add the events, actions, and
guard conditions associated with the transitions.
•

© e-Learning Centre, UCSC 11

State Diagram –Hotel Room Class

© e-Learning Centre, UCSC 12

State Diagram– Course Class

Initialization Closed

add student
cancel cancel
closed
cancel
Open Canceled

add student

© e-Learning Centre, UCSC 13

State Transition Details

• A State Transition may have the following

associated with:
• an action and/or
(behaviour that occurs when the state transition
occurs.)
• a guard condition
(allows state transition only if it is true.)
• A State Transition may also trigger an event
A message that is sent to another object in the system.

© e-Learning Centre, UCSC 14

 State Diagram
Course Offering with State Details

Add student[ count < 10 ]

Add Student /
Initialization Set count = 0
Open
do: Initialize course
entry: Register student
exit: Increment count

Cancel

Cancel [ count = 10 ]

Canceled
do: Notify registered students
Closed
Cancel
do: Finalize course

© e-Learning Centre, UCSC 15

State Details

• Activity:
• Behaviour that an object carries out while it is in
a particular state.
• An activity is shown inside the state itself,
preceded by the word do and a colon.
• Entry Action:
• Behaviour that occurs while the object is
transitioning into the state.
• Shown inside the state, preceded by the word
entry and colon.

© e-Learning Centre, UCSC 16

State Details cont…

• Exit Action:
• Occurs as part of the transition out of a state.
• Shown inside the state, preceded by the word
exit and colon.
• The behaviour in an activity, entry action, or
exit action can include sending an event to
some other object.

© e-Learning Centre, UCSC 17

State Details con…

• In this case, the activity, entry action, or exit

action is preceded by a ^

Do:^Target.Event(Arguments)

Target - object receiving the event

Event - message being sent
Arguments – parameters of the message being sent

Example:
Do:^CourseRoster.Create

© e-Learning Centre, UCSC 18

UML 2.0 State Diagrams

• UML 2.0 has added some new state relevant

symbols called connection points.
• They represent points of entry into a state or
exists out of a state.
• Let us look at the different states of a book in
a library.

© e-Learning Centre, UCSC 19

UML 2.0 State Diagrams

• At first the book is residing on a shelf.

• If a borrower has called in to reserve the book, a
librarian retrieves the book and brings it into
the state of “Being checked out”.
• If a borrower comes to the library, browses
through the shelves, selects the book, and
decides to borrow it.
• Again it enters into the state of “Being checked
out”, but in a different way.

© e-Learning Centre, UCSC 20

UML 2.0 State Diagrams

• You can think of each way of getting to the

Being-checked-out state as going through a
separate entry point
• Suppose the borrower is trying to borrow
more than the allotted limit or has number
of unpaid fines.
• If that is the case the book abruptly exits via
an exit point, from “Being-checked-out”
state
© e-Learning Centre, UCSC 21
Entry points and exit point in a UML state
diagram

[reserved]

Residing on shelf Being Checked Out

ended

© e-Learning Centre, UCSC 22

Why are State diagrams important?

The state diagram:

• models the changes that just one object goes
through.
• help analysts, designers, and developers
understand the behavior of the objects in a system.
A class diagram and an object diagram:
• shows only static aspects of a system.
• do not show the dynamic details of the behaviors.

© e-Learning Centre, UCSC 23

Why are State diagrams important?

• Developers, in particular, have to know

• how objects are supposed to behave because
they have to implement these behaviors in
software.
• Developers have to make that object do
something.
• State diagrams ensure that they won’t have to guess
about what the object is supposed to do.

© e-Learning Centre, UCSC 24

8.2 CRUDE Analysis

• Also can be used to identify complex objects.

• These objects are candidates for state modeling with a
behavioral state machine.

© e-Learning Centre, UCSC 25

8.2 CRUDE Analysis

Eg. CRUDE Matrix for the “Make Patient Appointment” Use Case
in a Medical care system
• CRUDE analysis also can be used to identify complex objects.
• The more (C)reate, (U)pdate, or (D)elete entries in the column
associated with a class, the more likely the instances of the
class have a complex life cycle.
• As such, these objects are candidates for state modeling with
a behavioral state machine.

© e-Learning Centre, UCSC 26

Verifying and Validating the Behavioral Model

The sequence and communication diagrams

• models the interaction among instances of classes that work
together to support the business processes included in a
system, whereas,
The behavioral state machine
• describes the state changes through which an object
traverses during its lifetime, and
The CRUDE matrix
• represents a system-level overview of the interactions
among the objects in the system.
• combines walkthroughs to more completely verify and
validate the behavioral models.

© e-Learning Centre, UCSC 27

8.3 Verifying and Validating the Behavioral Model
• First, every actor and object included on a sequence
diagram must be included as an actor and an object on
a communication diagram, and vice versa.
• Every message that is included on a sequence diagram
must appear as a message on an association in the
corresponding communication diagram, and vice versa.
• The sequence number included as part of a message
label in a communications diagram implies the
sequential order in which the message will be sent.
Therefore, it must correspond to the top-down
ordering of the messages being sent on the sequence
diagram.

© e-Learning Centre, UCSC 28

8.3 Verifying and Validating the Behavioral Model cont..

• All transitions contained in a behavior state

machine must be associated with a message being
sent on a sequence and communication diagram,
and it must be classified as a (C)reate, (U)pdate, or
(D)elete message in a CRUDE matrix.
• All entries in a CRUDE matrix imply a message
being sent from an actor or object to another actor
or object. If the entry is a (C)reate, (U)pdate, or
(D)elete, then there must be an associated
transition in a behavioral state machine that
represents the instances of the receiving class.

© e-Learning Centre, UCSC 29

8.4 Other UML Diagrams

Component Diagrams
• Component diagrams are used to
• visualize the physical components in a system. These
components are libraries, packages, files, etc.
• depict how components are wired together to form
larger components or software systems.
• illustrate the structure of arbitrarily complex systems.
• Component diagrams can also be described as a
static implementation view of a system.
• Component diagrams contain mainly components,
interfaces and relationships.
• Components are related via dependency relationships.

© e-Learning Centre, UCSC 30

Component diagram

<<EXE>>
Lecturer
Options

<<DLL>> CoursesAPI
Courses

(UML 1.X notation)

© e-Learning Centre, UCSC 31

Component diagram

A Component diagram (UML 2.0) that shows

how the Order System component depends
on other components
© e-Learning Centre, UCSC 32
8.4 Other UML Diagrams cont.

Deployment Diagram
• The deployment diagram shows the physical
architecture of a computer-based system.
• It can show
• the computers and devices,
• their connections with one another
• the software that sits on each machine
• It maps the software architecture to the hardware
architecture.

© e-Learning Centre, UCSC 33

Deployment Diagram

• Deployment diagrams are used only for distributed

systems.
• The main hardware item is a node, a generic name
for any kind of computing resource.

UML node icon

© e-Learning Centre, UCSC 34

Deployment Diagram

Registration Database
Server

LecturerOptions.exe

Main Library
Building

StudentOptions.exe StudentOptions.exe

© e-Learning Centre, UCSC 35

8.4 Other UML Diagrams cont.

What is New in UML 2.0

• New Diagrams: Composite Structure Diagram
• Show classes internal structure
EXAMPLE

PERSON

Mind Body

© e-Learning Centre, UCSC 36

8.4 Other UML Diagrams cont.

What is New in UML 2.0

• New Diagrams: Interaction Overview Diagram
• Expands the Activity Diagram
Example:
Consider three activities in visiting a library

© e-Learning Centre, UCSC 37

Interaction Overview Diagram

• Let's analyze each activity

Find Book : Ask library database to locate the book.
Database responds by telling you to go to the books
location.
Borrow Book : Ask the librarian to check the book out to
you. After checkout, the librarian tells you to take the book.
Leave Library : You can leave the library only if a guard
verifies that you have checked out the book.

© e-Learning Centre, UCSC 38

 :User :LibraryDatabase
find()
goToLocation()

:User :Librarian
processCheckOutRequest()
takrBook()

:User :Guard
verifyCheckOut()

exitLibrary()
© e-Learning Centre, UCSC 39
8.4 Other UML Diagrams cont.

What is New in UML 2.0

• New Diagrams: Timing Diagram
• Design to show how long an object is in a state.
• Sequence diagrams does not show the durations explicitly.

Spinning

Rinsing
:WashingMachine
Washing

Soaking

0 5 10 15 20 25 30 35
© e-Learning Centre, UCSC 40
 UML Profiles

• A lightweight extension mechanism for UML

• Concepts partially present in earlier versions
• Stereotypes. <<entity>>
• Tagged Values {author=Siman Silva}
• Established as a specific meta-modeling technique in
UML 2.0
• Contains mechanisms that allow meta classes from existing
meta models to be extended.
• Ability to tailor the UML meta model for different platforms
or domains.

© e-Learning Centre, UCSC 41

UML Profile Diagrams

• Profile diagram is structure diagram

• Describes lightweight extension mechanism to the
UML by defining custom stereotypes, tagged
values, and constraints.
• Profiles allow adaptation of the UML metamodel
for different:
- platforms (such as J2EE or .NET), or
- domains (such as real-time or business process
modeling).

© e-Learning Centre, UCSC 42

UML Diagrams

© e-Learning Centre, UCSC 43

Basic UML Profile Diagram Structure
UML Profiles provide a generic extension mechanism for
building UML models in particular domains.

© e-Learning Centre, UCSC 44

UML Profile Diagrams

Eg..

Ref. http://www.uml-diagrams.org/profile-diagrams.html
© e-Learning Centre, UCSC 45
Summary
• A behavioral state machine is a dynamic model that shows
the different states through which a single object passes
during its life in response to events, along with its responses
and actions.
• State Diagrams are created only for classes with significant
dynamic behaviour.
• State diagrams mainly depict states and transitions. States
are represented with rectangles with rounded corners that
are labeled with the name of the state. Transitions are
marked with arrows that flow from one state to another,
showing how the states change.
• A State Transition may have the following associated with:
• an action: behaviour that occurs when the state
transition occurs, and/or
• a guard condition: allows state transition only if it is true.

© e-Learning Centre, UCSC 46

Summary cont..
• One useful technique to identify how the underlying
objects in the problem domain work together to
collaborate in support of the use cases is CRUDE
analysis.
• CRUDE analysis uses a CRUDE matrix, in which each
interaction among objects is labeled with a letter for the
type of interaction:
• C for Create, R for Read or Reference, U for Update, D for
Delete, and E for Execute.
• We can combine walkthroughs with CRUDE matrices to
more completely verify and validate the behavioral
models.

© e-Learning Centre, UCSC

 Summary cont..
• A Component diagram shows how different elements of your
system have been grouped together and the link between
these components.
• A Deployment diagram takes you one step further and
describes on which hardware elements do these components
reside.
• Composite Structure Diagram shows the internal structure of
the class, whereas Timing diagram is design to show how long
an object is in a state.
• An interaction overview diagram is a form of activity diagram
in which the nodes represent interaction diagrams.
• Profile diagram is a kind of structural diagram in the UML, that
provides a generic extension mechanism for customizing UML
models for particular domains and platforms.
*****
© e-Learning Centre, UCSC 48
 9. Object Oriented Design

IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will learn

• the activities involved in object-oriented design.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• understand the verification and validation of the
analysis models,
• understand the transition from analysis to
design,
• create package diagrams, verify and validate
them.

© e-Learning Centre, UCSC 3

 List of sub topics

9.1 Introduction to Object Oriented Design [Ref 1: Pg. 240-241]

9.2 Verifying and Validating the Analysis Models [Ref 1: Pg.242-257]
9.2.1 Balancing Functional and Structural Models
9.2.2 Balancing Functional and Behavioral Models
9.2.3 Balancing Structural and Behavioral Models
9.3 Evolving Analysis Models into Design Models [Ref 1: Pg. 257-262]
9.4 Package Diagrams [Ref 1: Pg. 262-268]
9.4.1 Guidelines for Creating Package Diagrams
9.4.2 Creating Package Diagrams
9.4.3 Verifying and Validating Package Diagrams

Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems analysis

design, An Object Oriented Approach with UML: an object
oriented approach, 5th edition, John Wiley & Sons, 2015, ISBN
978-1-118-80467-4

© e-Learning Centre, UCSC 4

 9.1 Introduction to Object Oriented Design
• The purpose of analysis is to figure out the business
needs.
• The purpose of design is to decide how to build the
system.
• The major activity that takes place during design is
evolving the set of analysis representations into design
representations.
• An important initial part of design is to examine several
design strategies and decide which will be used to build
the system.
• e. g. Systems can be built from scratch, purchased and
customized, outsourced to others etc.
• The project team needs to investigate the viability of each
alternative. This decision influences the tasks that are to
be accomplished during design.

© e-Learning Centre, UCSC 5

9.1 Introduction to Object Oriented Design cont…

• Design includes activities such as designing the user

interface, system inputs, and system outputs, which
involve the ways that the user interacts with the
system.
• Physical architecture decisions are made regarding
the hardware and software that will be purchased to
support the new system and the way that the
processing of the system will be organized.
e.g. The system can be organized so that its
processing is centralized/distributed.

© e-Learning Centre, UCSC 6

9.2 Verifying and Validating the Analysis Models
Before we evolve our analysis representations into design
representations:
• We need to verify and validate the current set of
analysis models to ensure that they faithfully represent
the problem domain under consideration.
• We need to give attention on ensuring that the
different models are consistent.
e.g.
➢ We must be sure that the activity diagram(s), use-
case descriptions, and use case diagrams all describe
the same functional requirements.
➢ Transitions on a behavioral state machine are
associated with operations contained in a class
diagram.

© e-Learning Centre, UCSC 7

9.2 Verifying and Validating the Analysis Models
Balancing Functional and Structural Models:
• We must ensure that the two sets of models are consistent with
each other.
• The activity diagrams, use-case descriptions, and use-case diagrams
must agree with the CRC cards and class diagrams that represent the
evolving model of the problem domain.
E.g.
➢Every class on a class diagram and every CRC card must be associated
with at least one, use case and vice versa.
➢Every activity or action contained in an activity diagram and every
event contained in a use-case description should be related to one or
more responsibilities on a CRC card and one or more operations in a
class on a class diagram and vice versa.
➢Every object node on an activity diagram must be associated with an
instance of a class on a class diagram and a CRC card or an attribute
contained in a class and on a CRC card.
➢Every attribute and association/aggregation relationships contained
on a CRC card (and connected to a class on a class diagram) should
be related to the subject or object of an event in a use-case
description. © e-Learning Centre, UCSC 8
9.2 Verifying and Validating the Analysis Models
Balancing Functional and Behavioral Models
• We must ensure that the two sets of models are consistent with
each other.
• The activity diagrams, use-case descriptions, and use-case diagrams
must agree with the sequence diagrams, communication diagrams,
behavioral state machines, and CRUDE matrix.
Eg.
➢The sequence and communication diagrams must be associated with
a use-case on the use-case diagram and the use-case description.
➢Actors on sequence diagrams, communication diagrams, and/or
CRUDE matrices must be associated with actors on the use-case
diagram or referenced in the use case description, and vice versa.
➢Messages on sequence and communication diagrams, transitions on
behavioral state machines, and entries in a CRUDE matrix must be
related to activities and actions on an activity diagram and events
listed in a use-case description, and vice versa.
➢All complex objects represented by an object node in an activity
diagram must have a behavioral state machine that represents the
object’s lifecycle, and vice versa.
© e-Learning Centre, UCSC 9
9.2 Verifying and Validating the Analysis Models
Balancing Structural and Behavioral Models
• We must ensure that the two sets of models are consistent with
each other.
➢Objects that appear in a CRUDE matrix must be associated with
classes that are represented by CRC cards and appear on the
class diagram, and vice versa.
➢Behavioral state machines must be associated with instances
(objects) of classes on a class diagram and with a CRC card that
represents the class of the instance.
➢Communication and sequence diagrams contain objects that
must be an instantiation of a class that is represented by a CRC
card and is located on a class diagram.
➢Messages contained on the sequence and communication
diagrams, transitions on behavioral state machines, and cell
entries on a CRUDE matrix must be associated with
responsibilities and associations on CRC cards and operations in
classes and associations connected to the classes on class
diagrams.
➢The states in a behavioral state machine must be associated
with different values of an attribute or set of attributes that
describe an object.
© e-Learning Centre, UCSC 10
9.3 Evolving Analysis Models into Design Models

• After successfully verifying and validating the analysis models, we

need to begin evolving them into appropriate design models.
• In the analysis we defined the functional requirements whereas
in systems design, we address both the functional and
nonfunctional requirements.
• When evolving the analysis model into the design model, you
should first carefully review the use cases and the current set of
classes (their operations and attributes and the relationships).
✓Are all the classes necessary? Are there any missing classes?
✓Are the classes fully defined?
✓Are any attributes or methods missing?
✓ Do the classes have any unnecessary attributes and methods?
✓Is the current representation of the evolving system optimal?

© e-Learning Centre, UCSC 11

9.3 Evolving Analysis Models into Design Models
• Object-oriented systems development is both incremental and iterative.
Hence, we must review the analysis models again.
• Start looking at the models of the problem domain through a design lens.
• Factoring, partitions and collaborations, and layers can be used to evolve
problem domain-oriented analysis models into optimal solution domain-
oriented design models.
Factoring: Factoring is the process of separating out a module into a stand-
alone module (new class or new method)
Eg. When reviewing a set of classes, it may be discovered that they have a
similar set of attributes and methods. The new class can be related to the
existing classes through a generalization (a-kind-of) or possibly through an
aggregation (has-parts) relationship.
Partitions and Collaborations: in the evolution of the system, it might make
sense to split the representation into a set of partitions. A partition is the
object-oriented equivalent of a subsystem. An easy approach to model
partitions and collaborations is the use of packages and package diagrams.
A good place to look for potential partitions is the collaborations modeled in
UML’s communication diagrams.
© e-Learning Centre, UCSC 12
9.3 Evolving Analysis Models into Design Models

Layers: To successfully evolve the analysis model of the system into a

design model of the system, we must add the system environment
information. One useful way to do this, without overloading the
developer, is to use layers.
A layer represents an element of the software architecture of the evolving
system.
We have focused only on one layer in the evolving soft ware architecture:
the problem domain layer.
There should be a layer for each of the different elements of the system
environment (e.g., data management, user interface, physical
architecture).
Like partitions and collaborations, layers also can be portrayed using
packages and package diagrams
Eg. Problem Domain Layers – Employee, Customer
Data Management Layers - DataInputStream, FileInputStream
Human–Computer Interaction Layers- Button, Panel
Refer Recommended text for other examples.

© e-Learning Centre, UCSC 13

9.4 Package Diagrams
• In UML, collaborations, partitions, and layers can be represented by
a higher-level construct: a package . A package serves the same
purpose as a folder on your computer.
• A package is a general construct that can be applied to any of the
elements in UML models.
Symbols used in a Package diagram:
Package: Is a logical grouping of UML elements. It is used to simplify
UML diagrams by grouping related elements into a single higher-level
element.

Dependency Relationship:
Represents a dependency between packages: If a package is changed, the
dependent package also could have to be modified.
Has an arrow drawn from the dependent package toward the package on
which it is dependent.
© e-Learning Centre, UCSC 14
Package Diagram
e.g.

UML Diagrams

© e-Learning Centre, UCSC 15

9.4 Package Diagrams
Guidelines for Creating Package Diagrams
1. Set Context : example- problem domain layer
2. Cluster Classes : cluster the classes together into
partitions based on the relationships that the classes
share. The relationships include generalization,
aggregation, the various associations, and the message
sending that takes place between the objects in the
system.
3. Create Packages : example -place the clustered classes
together in a partition and model the partitions as
packages. In an Appointment System, Appointment
package , Patient package etc.
4. Identify Dependencies : identify the dependency
relationships among the packages.
5. Draw Diagram : To increase the understandability of the
dependency relationships among the different packages, a
pure package diagram that shows only the dependency
relationships among the packages can be created.
© e-Learning Centre, UCSC 16
9.4 Package Diagrams
Verifying and Validating Package Diagrams
• Like all the other models, package diagrams need to be
verified and validated.
• The identified packages must make sense from a problem
domain point of view.
• All dependency relationships must be based on message-
sending relationships on the communications diagram, cell
entries in the CRUDE matrix, and associations on the class
diagram.

© e-Learning Centre, UCSC 17

Summary
• The major activity that takes place during design is evolving
the set of analysis representations into design
representations.
• Design also includes activities such as designing the user
interface, system inputs, and system outputs, which involve
the ways that the user interacts with the system.
• Physical architecture decisions are made regarding the
hardware and soft ware that will be purchased to support
the new system and the way that the processing of the
system will be organized.
• Design also includes activities such as designing the user
interface, system inputs, and system outputs, which involve
the ways that the user interacts with the system.

© e-Learning Centre, UCSC 18

Summary cont..
• Before we evolve our analysis representations into design
representations, we need to verify and validate the current
set of analysis models to ensure that they faithfully
represent the problem domain under consideration.
• We must ensure that the Functional and Structural models
are consistent with each other. Eg. The activity diagrams,
use-case descriptions, and use-case diagrams must agree
with the CRC cards and class diagrams that represent the
evolving model of the problem domain.
• We must ensure that the Functional and Behavioral models
are consistent with each other. Eg. The activity diagrams,
use-case descriptions, and use-case diagrams must agree
with the sequence diagrams, communication diagrams,
behavioral state machines, and CRUDE matrix.
© e-Learning Centre, UCSC 19
Summary cont..
• We must also ensure that the two Structural and Behavioral
models are consistent with each other.
• After successfully verifying and validating the analysis
models, we need to begin evolving them into appropriate
design models.
• Factoring, partitions and collaborations, and layers can be
used to evolve problem domain-oriented analysis models
into optimal solution domain-oriented design models.
• In UML, collaborations, partitions, and layers can be
represented by a higher-level construct: a package.
• A package serves the same purpose as a folder on your
computer. A package is a general construct that can be
applied to any of the elements in UML models.

© e-Learning Centre, UCSC 20

Summary cont..
• Like all the other models, package diagrams need to be
verified and validated.
• The identified packages must make sense from a problem
domain point of view.
• All dependency relationships must be based on message-
sending relationships on the communications diagram, cell
entries in the CRUDE matrix, and associations on the class
diagram.
*****

© e-Learning Centre, UCSC 21

10. Component Based Software Engineering

IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will learn

• the key activities in the component-based software
engineering (CBSE) process,
• what is meant by a software component that may be
included in a program as an executable element;
• the key elements of software component models and the
support provided by middleware for these models;
• three different types of component composition and some of
the problems that have to be resolved when components are
composed to create new components or systems.

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• understand the component-based software
engineering (CBSE) process concerned with
developing standardized components based on a
component model, and composing these into
application systems;
• know the principal activities in the CBSE process for
reuse and the CBSE process with reuse;
• describe the three different types of component
composition and some of the problems that have to
be resolved when components are composed to
create new components or systems.

© e-Learning Centre, UCSC 3

 List of sub topics

10 Component Based Software Engineering (3 hours)

10.1 Introduction to Component Based Software
Engineering (CBSE) [Ref2: 465-467]
10.2 Components and Component Models [Ref 2: Pg. 467-473]
10.3 CBSE Processes [Ref 2: Pg. 473-480]
10.3.1 CBSE for Reuse
10.3.2 CBSE with Reuse
10.4 Component Composition [Ref 2: Pg. 480-486]

© e-Learning Centre, UCSC 4

10.1 Introduction to Component Based
Software Engineering (CBSE)

• Many new systems – now developed by configuring COTS

(Commercial off the shelf)
• Cannot use if it does not meet their requirements.
• For custom software, CBSE is an effective , reuse oriented
way to develop new enterprise systems.

© e-Learning Centre, UCSC 5

10.1 Introduction to Component Based
Software Engineering (CBSE)

• CBSE emerged in late 1990s.

Motivation:
• OO development had not led to extensive reuse as originally
suggested.
• Single object classes were too detailed and specific to reuse.
• Selling or distributing objects as individual reusable
components were practically impossible.

© e-Learning Centre, UCSC 6

Component- based Software Engineering (CBSE).

• Components are higher level abstractions than objects.

• They are defined by their interfaces.
• Larger than individual objects.

CBSE: is the process of

• defining,
• Implementing
• Integrating
Loosely coupled , independent components into
systems.

© e-Learning Centre, UCSC 7

Essentials of Component- based Software
Engineering (CBSE).

1. Independent Components that are completely

specified by their interfaces.
• There should be a clear separation between the
component interface and its implementation.

© e-Learning Centre, UCSC 8

Essentials of
Component- based Software Engineering (CBSE).

2. Component standards that facilitates the

integration of components.
• These standards are embedded in a component model.
• They define (minimum): How component interfaces should
be specified, How components communicate.
• If components confirm to standards, their operation is
independent of the Programming Language.
• Components written in different languages can be
integrated into the same system.

© e-Learning Centre, UCSC 9

Essentials of
Component- based Software Engineering (CBSE).

3. Middleware that provides software support for

component integration
• To make independent, distributed components work
together, you need middleware support that handles
component communications.

© e-Learning Centre, UCSC 10

Essentials of
Component- based Software Engineering (CBSE).

4. A development process that is geared to

component-based software engineering.
• Allows requirements to evolve, depending on the
functionality of available components.

© e-Learning Centre, UCSC 11

CBSE and Design Principles

• Apart from the benefits of reuse, CBSE is based on sound

software engineering design principles:
• Components are independent so do not interfere with
each other;
• Component implementations are hidden;
• Communication is through well-defined interfaces;
• Component platforms are shared and reduce
development costs.

© e-Learning Centre, UCSC 12

CBSE problems

• Component trustworthiness - how can a

component with no available source code be
trusted?
• Component certification - who will certify the
quality of components?
• Emergent property prediction - how can the
emergent properties of component compositions
be predicted? Especially when they are integrated
with other components.

© e-Learning Centre, UCSC 13

CBSE problems

• Multiple standards (eg. COM, EJB) have hindered

the uptake of CBSE.
• Impossible for components developed using different approaches to
work together.
• Components that are developed for different platforms, such as .NET
or J2EE, cannot interoperate.
• The standards and protocols proposed were complex and difficult to
understand.
• In response to these problems, the notion of a component as
a service was developed.

© e-Learning Centre, UCSC 14

Component as a Service Provider

• The component is an independent, executable

entity. It does not have to be compiled before it is
used with other components.
• The services offered by a component are made
available through an interface and all component
interactions take place through that interface.

© e-Learning Centre, UCSC 15

 Component characteristics 1
Standardised Component standardisation means that a component that is
used in a CBSE process has to conform to some standardised
component model. This model may define component
interfaces, component meta-data, documentation, composition
and deployment.
Independent A component should be independent – it should be possible to
compose and deploy it without having to use other specific
components. In situations where the component needs
externally provided services, these should be explicitly set out
in a ‘requires’ interface specification.
Composable For a component to be composable, all external interactions
must take place through publicly defined interfaces. In
addition, it must provide external access to information about
itself such as its methods and attributes.

© e-Learning Centre, UCSC 16

 Component characteristics 2

Deployable To be deployable, a component has to be se lf-contained and

must be able to operate as a stand-alone entity on some
component platform that implements the component model.
This usually means that the component is a binary component
that does not have to be compiled before it is deployed.
Documented Components have to be fully documented so that potential
users of the component can decide whether or not they meet
their needs. The syntax and, ideally, the semantics of all
component interfaces have to be specified.

© e-Learning Centre, UCSC 17

Component interfaces

Components have two related interfaces.

• Provides interface
• Defines the services that are provided by the
component to other components.
In UML – Circle is used
• Requires interface
• Defines the services that specifies what services must be
made available for the component to execute as
specified.
• In UML – Semi Circle is used

© e-Learning Centre, UCSC 18

 Component interfaces
Requires int erface Provides int erface
Defines the services Defines the services
fromthe component’s Component that are pro vided
environment that it by the component
uses to other co mponents

In a UML component diagram, the “provides” interface for a component

is Indicated by a circle at the end of a line from the component icon

In the UML the symbol for a “requires” interface is a semicircle at the

end of a line from the component icon.

© e-Learning Centre, UCSC 19

A data collector component
Designed to collect and collate information from an
array of sensors over a period.

Requires int erface Provides int erface

addSensor
sensorManagement removeSensor
star tSensor
Data collector stopSensor
sensorData testSensor
initialise
repor t
listAll

© e-Learning Centre, UCSC 20

 A data collector component
• The provides interface include methods to initialize, add, remove,
start, stop, and test sensors.
• The report method returns the sensor data that has been collected.
• listAll method provides information about the attached sensors.

Requires int erface Provides int erface

addSensor
Use to removeSensor
sensorManagement
Connect star tSensor
The Data collector stopSensor
Components testSensor
sensorData
to the
initialise
sensors
repor t
listAll
© e-Learning Centre, UCSC 21
Adaptor linking a Data Collector and a Sensor

• Adaptor component can be used when a

component wishes to make use of another but
there is an incompatibility between the provides
and required interfaces of the components.

© e-Learning Centre, UCSC 22

Adaptor linking a Data Collector and a Sensor

Eg. To issue a collect command sensorData(“Collect”)

• Adaptor passes the input string, identifies the command
(eg. “Collect”) and calls the sensor.getData to collect the
sensor value. It then returns the result to the Data
Collector.

© e-Learning Centre, UCSC 23

Adaptor linking a Data Collector and a Sensor

Similarly, Data Collector can interact with different types

of sensors. A separate Adaptor which converts the
sensor command from Data Collector to actual sensor
interface is implemented for each type of sensor.

© e-Learning Centre, UCSC 24

Component models

• A component model is a definition of standards for

component implementation, documentation and
deployment.
• Examples of component models
• WebServices model
• EJB model (Enterprise Java Beans)
• COM+ model (.NET model)
• CORBA Component Model
• The component model specifies how interfaces should be
defined and the elements that should be included in an
interface definition.

© e-Learning Centre, UCSC 25

 Basic elements of a component model
Customisation
Naming
convention

Compositio n Documentation

Inter face Specific Meta-data Evolution

Packag ing
definition inter faces access suppor t

Usage Deployment
Inter faces
information and use
Component model

© e-Learning Centre, UCSC 26

Middleware support – Components implemented as
program units

• Component models are the basis for middleware that

provides support for executing components.
• Component model implementations provide:
• Platform services that allow components written
according to the model to communicate;
• Horizontal services that are application-independent
services used by different components.
• To use services provided by a model, components are
deployed in a ‘container’.
• This is a set of interfaces used to access the service
implementations.

© e-Learning Centre, UCSC 27

 Component model
services Support Services
(Application-independent services used
by different components)

Horizontal s ervices

Component Transaction Resource

management management management

Concurrency Persistence Security

Fundamental Services (enable components to communicate and

interoperate in a distributed environment)
Platform services

Inter face Exception Component

Addressing
definition management communications

© e-Learning Centre, UCSC 28

 CBSE processes

There are two types of CBSE processes:

1. Development for reuse This process is concerned with
developing components or services that will be reused in
other applications. It usually involves generalizing existing
components. Knows the components that you will be working
with.
2. Development with reuse This is the process of developing
new applications using existing components and services. You
do not know what components are available.

© e-Learning Centre, UCSC 29

Have access to source code You may not have access
CBSE Processes
to generalize them to source code

© e-Learning Centre, UCSC 30

CBSE Processes

Process of
acquiring
components
for reuse or
development
into a reusable
© e-Learning Centre, UCSC component 31
CBSE Processes

Managing
company’s
reusable
components
© e-Learning Centre, UCSC . 32
CBSE Processes

process of
checking a
component and
certifying that it
meets its
specification © e-Learning Centre, UCSC 33
CBSE Processes

includes components
and information about
their use
© e-Learning Centre, UCSC 34
Component development for reuse

• Components developed for a specific application usually

have to be generalized to make them reusable. –associated
cost
• A component is most likely to be reusable if it associated
with a stable domain abstraction (business object).
• For example, in a hospital stable domain abstractions are
associated with the fundamental purpose - nurses, patients,
treatments, etc.

© e-Learning Centre, UCSC 35

Component development for reuse

• Components for reuse may be specially

constructed by generalising existing components.
• Component reusability should
• reflect stable domain abstractions;
• hide state representation;
• be as independent as possible;
• publish exceptions through the component interface.

© e-Learning Centre, UCSC 36

To make a component cost effective

• Cost savings from future reuse vs cost of making

• Cost of Making:
➢ Documentation cost,
➢ Component validation,
➢ Making it more generic

© e-Learning Centre, UCSC 37

Changes for reusability

• Remove application-specific methods.

• Change names to make them general.
• Add methods to broaden coverage.
• Make exception handling consistent.
• Add a configuration interface for component adaptation.
• Integrate required components to reduce dependencies.

© e-Learning Centre, UCSC 38

Legacy system components

• Existing legacy systems that fulfil a useful business function

can be re-packaged as components for reuse.
• This involves writing a wrapper component that implements
provides and requires interfaces then accesses the legacy
system.
• Although costly, this can be much less expensive than
rewriting the legacy system.

© e-Learning Centre, UCSC 39

Component Development with reuse

Need a complete set

of requirements
© e-Learning Centre, UCSC 40
Component Development with reuse

First look for components

that are available locally
or from trusted suppliers.
e.g Google code
© e-Learning Centre, UCSC 41
Component Development with reuse

If user requirements
cannot be satisfied from
available components
© e-Learning Centre, UCSC 42
Component Development with reuse

You may choose a component

model and implementation platform
© e-Learning Centre, UCSC 43
Component Development with reuse

Some usable components may be

unsuitable or do not work properly
with other chosen components.
© e-Learning Centre, UCSC 44
Component Composition

• Process of integrating components with each other

(with or without glue code) to create a system or
another component.
• Several different ways exist
• Sequential Composition
• Hierarchical Composition
• Additive Composition

© e-Learning Centre, UCSC 45

 Component Composition (Sequential)

• The services offered by Component A

are called and the results returned by
A are then used in the call to the
services offered by component B.
• Extra glue code required to call the
services in the right order and ensure
compatibility.

© e-Learning Centre, UCSC 46

Component Composition (Hierarchical)

• This type of composition occurs when

one component calls directly on the
services provided by another
component.
• The ‘provides’ interface of the called
component must be compatible with
the ‘requires’ interface of the calling
component.

© e-Learning Centre, UCSC 47

Component Composition (Additive)

• This occurs when two or more

components are put together
(added) and,
• Create a new component,
which combines their
functionality.

© e-Learning Centre, UCSC 48

Component Composition (Additive)

• The components are

called separately through
the external interface of
the composed component.
• A and B are not dependent
and do not call each other.

© e-Learning Centre, UCSC 49

Component Composition

• When composing reusable components that have not been

written for your application:
• You may need to write adaptors or ‘glue code’ to
reconcile the different component interfaces.
• When choosing compositions, you have to consider
• required functionality of the system
• non-functional requirements and
• how easy is to replace one component when the system
is changed.

© e-Learning Centre, UCSC 50

Summary
• CBSE is the process of defining, Implementing and Integrating, loosely
coupled, independent components into systems.
• Components are higher level abstractions than objects and they are
defined by their interfaces.
• Independent Components that are completely specified by their
interfaces so that there should be a clear separation between the
component interface and its implementation.
• There should be component standards that facilitates the integration of
components.
• To make independent, distributed components work together, you need
middleware support that handles component communications.
• A development process that is geared to component-based software
engineering allows requirements to evolve, depending on the
functionality of available components.
• Characteristics of components are standardized, independent,
composable, deployable and documented.

© e-Learning Centre, UCSC 51

Summary cont..
• Provides component interface defines the services that are
provided by the component to other components. In UML Circle
symbol is used for the Provides interface.
• Requires interface defines the services that specifies what
services must be made available for the component to execute as
specified. In UML Semi Circle is used for the Requires interface
• Component composition is the process of “wiring” components
together to create a system.
• Types of composition include sequential composition, hierarchical
composition, and additive composition.
• When composing reusable components that have not been
written for your application, you may need to write adaptors or
“glue code” to reconcile the different component interfaces.
*****

© e-Learning Centre, UCSC 52

11. System Modelling using Case Studies

IT 3106– Object Oriented Analysis and Design

Level II - Semester 3

© e-Learning Centre, UCSC

 Overview

In this section students will

• Learn how to prepare Object Oriented Analysis
and Design documents for a given problem
using Unified Modeling Language

© e-Learning Centre, UCSC 2

 Intended Learning Outcomes

At the end of this lesson students will be able to

• Understand the processes of OOAD
• Prepare Object Oriented Analysis and Design
documents for a given problem using Unified
Modeling Language

© e-Learning Centre, UCSC 3

 List of sub topics

11.0 Prepare Object Oriented Analysis and Design documents

for the Case Studies given in the VLE.
Ref 1: Alan Dennis, Barbara Haley, David Tegarden, Systems
analysis design, An Object Oriented Approach with UML :
an object oriented approach, 5th edition, John Wiley &
Sons, 2015, ISBN 978-1-118-80467-4

© e-Learning Centre, UCSC 4

Case Study 1 – Sarasavi Library

• Sarasavi is a popular library with a large collection

of books. It has a collection of nearly 500 books.
These books are available for loan as well as for
reference by registered members, free of charge
and there is also a category called “Registered
visitors” who are permitted reference facilities only.
• The functions of the Sarasavi library can be
categorised as below:
Loan Process, Return Process, Reservation process,
Inquiry Process, Overdue Report Process, Book
Registration Process and User Registration process.

© e-Learning Centre, UCSC 5

Case Study 1 – Sarasavi Library Conti…
• Loan Process:
The borrower collects from the racks and brings the copies he
wants to borrow to the counter. Librarian will check whether
the borrower has overdue books. The borrower is not allowed
to borrow any copies until the overdue books are returned.
The maximum number of copies allowed to be held after being
borrowed is 5 per user at any one time. When issuing a copy,
the Librarian will check the status of each copy. The status of
each copy indicates whether it is referenced or borrowable. A
two-week loan period is allowed per borrowable copy. The
Librarian can choose to accept or cancel the request for a loan.
The borrower is then informed of the expected return date of
each of copies held, if the loan is accepted. The Librarian
keeps all the loan details.

© e-Learning Centre, UCSC 6

Case Study 1 – Sarasavi Library Conti…

• Return Process:
The copy to be returned is brought to the counter. The
Librarian accepts the return and checks the status of the
copy. If the copy is already reserved, the librarian takes
steps to inform the member who has reserved the copy.
• Reservation Process:
The member informs the Librarian about the books he
wants to reserve. The Librarian accepts the reservation
depending on the status of the copies. If the reservation is
accepted, the Librarian keeps all the reservation details.

© e-Learning Centre, UCSC 7

Case Study 1 – Sarasavi Library Conti…
• Inquiry Process:
The Librarian can also handle inquiries from the borrower about the
availability of a book. A facility is also available for a borrower/registered
visitor to check the availability of a book. The inquiries may be done by
knowing the specific book accession number or knowing a part or whole of
the title or author. If it is in the catalogue, Librarian will inform the
borrower the status of the book. The status indicates whether the book is
available, referenced or not, and in the case of availability of multiple
copies, whether all/some/no copies are loaned out, or reserved.

• Overdue Report Process:

A report containing the following information is produced at the end of
each week. Borrower code, name, address, sex, expected return date,
accession number, book title and author/s.

© e-Learning Centre, UCSC 8

 Case Study 1 – Sarasavi Library
Conti…
Book Registration Process:

The Librarian also registers new books into the library. This registration may also be an addition of a new
copy. However, a maximum of 10 copies are allowed to be registered per book number. The Librarian
records the classification, book title, publisher, whether the copy is reference or borrowable.

The book number comprises

X 9999
4 byte integer staring from 0001 for each classification

classification
(1 byte classification)

The copy number in case of multiple copies has the same structure with an extra number appended at the
end.

© e-Learning Centre, UCSC 9

Case Study 1 – Sarasavi Library Conti…
• User Registration Process:
New borrowers may also be registered. The following is captured
for the user registration.
User Number, Name, Sex, National identity card number and
Address.
• Management Reports:
The following reports are needed for the management to support
their decision-makings.
• A summary report of the total no of books borrowed, returned and
reserved in each month.
• A bar chart to illustrate the above figures.
• Number of borrowings for each book in the library in the
descending order of the number of borrowings.
*******
© e-Learning Centre, UCSC 10
Drawing a Use Case model

A Use Case model can be developed by following the

steps below.
• Identify the Actors (role of users) of the system.
• identify all roles played by the users relevant to
the system for each category of users, .
• Identify what the users required the system to
be performed to achieve the goals.
• Create use cases for every goal.
• Draw the Use case model
• Identify use case to use case relationships

© e-Learning Centre, UCSC 11

Identify the System Actors

• Anyone or anything that needs to interact with the system

to exchange information.

Registered Member
Librarian

Registered Visitor

Payment Clerk

Management Staff
© e-Learning Centre, UCSC 12
Use Cases

• Book Registration What is a Use Case?

▪ It is a typical interaction between
• Member Registration a user and a computer system.
▪ They are the primary elements in
• Inquiry software development.
▪ They represent the functionality
• Reservation provided by the system. i.e. what
capabilities will be provided to an
• Lending actor by the system.

• Returning
• Pay Fine
• Generate Reports

© e-Learning Centre, UCSC 13

 Identify the use cases that are responsibilities of each
actor

Actors Use Cases

Registered Member Inquiry, Reservation

Librarian Inquiry, Reservation, Book Registration,

Member Registration, Generate
Reports, Returning ,Lending

Registered Visitor Inquiry

Payment Clerk Pay Fine

Management Staff Generate Reports

Note : Certain functionalities are assumed. They are not very clear from the Case Study.
© e-Learning Centre, UCSC 14
 Use Case Diagram
• Relationships
• Extend <<extend>>
• <<extend>> provides a way to insert new behaviour
into an existing use case.
• The extension use case extends the functionality of the
original use case.
• Shows optional behavior of a Use Case
• Depicted as an arrow headed line (either solid/dashed)
• Has an arrow drawn from the extension use case to the
base use case.
Extension Use Case Base Use Case

© e-Learning Centre, UCSC 15

Use Case Diagram

base use case

Return book

<<extend>>

Borrow book Issue fine

Librarian
extension use case

© e-Learning Centre, UCSC 16

 Example of <<extend>> Relationship cont..

• Conditional extensions

Return book

<<extend>> <<extend>>

Issue warning Issue fine

Librarian

First offense Not first offense

© e-Learning Centre, UCSC 17

Example of <<extend>> Relationship cont..

• a library system in which borrowers are given a warning the

first time a book is returned over-due and are fined only
subsequently.
• We can model this by adding a new extension use case,
IssueWarning, and then placing conditions on the
<<extend>> relationships. The conditions are Boolean
expression evaluates to true.
• This is not mentioned in the Case Study

© e-Learning Centre, UCSC 18

Use Case Diagram

• Relationships <<include>>
• Include
• The base use case explicitly incorporates the
behavior of another use case.
• The relationship between the abstract use
case and use case that uses it.
Eg. CheckOverdue use case can be a
<<include>> use case to both Lending and
Returning. In both cases need to check
overdue books.
© e-Learning Centre, UCSC 19
© e-Learning Centre, UCSC 20
Prepare Use Case Narratives for the Use
Cases
e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Typically, another Use Case
that must be previously
- Typical Course of Events
executed.
- Alternate Courses
- Post conditions
etc. are included.
( for more information Refer pg258 of Ref 1 )

© e-Learning Centre, UCSC 21

Prepare Use Case Narratives for the Use Cases
e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger
Time receiving a cheque.
- Typical Course of Events
- Alternate Courses
- Post conditions
etc. are included.
( for more information Refer pg258 of Ref 1 )

© e-Learning Centre, UCSC 22

Use-Case Modelling
e.g. Expanded Version of a use-case narrative
eg. Borrowing :
More details such as checkMember,
- Preconditions checkOverdue,
CheckOverLimit,
- Trigger
checkCopyBorrowable,
- Typical Course of Events Confirm Borrowing
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 23

Use-Case Modelling
e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Errors, Confirm
- Typical Course of Events Messages
- Alternate Courses
- Post conditions
etc. are included.

© e-Learning Centre, UCSC 24

Use-Case Modelling
e.g. Expanded Version of a use-case narrative

More details such as

- Preconditions
- Trigger Receipt Delivered to the
- Typical Course of Events Customer
- Alternate Courses
- Post conditions
etc. are included.
( for more information Refer pg259 of Ref 3 )

© e-Learning Centre, UCSC 25

Identify the Objects

How to Identify Objects

• Go through the Case Study
• Pick out the nouns.
• Filter list of nouns to identify the objects
Identify the object interactions for each scenario (eg. Object
interactions for Lending scenario)

© e-Learning Centre, UCSC 26

 A Library System: Lending Scenario – Identify Objects
Objects
• Librarian enters the borrower id.
• System checks whether borrowerMember
id exist.
• Check for Overdue Books. Member , BorrowedCopy
• Check Over limit
Member, BorrowedCopy
• Enter copy id Copy, Book
• Check Copy Borrowable
• Librarian Confirm Borrowing
BorrowedCopy
• Update Borrowed Copy details

© e-Learning Centre, UCSC 27

 A Library System: Reservation Scenario-Identify
Objects
Objects
• Librarian/Member enters the borrower id.
• System checks whether borrower
Member
id exist.
• Check for Overdue Books. Member , BorrowedCopy
• Enter Book id
• Check Book has Borrowable Copies Copy, Book
• Librarian Confirm Reservation
• Update Reserved Copy details ReservedCopy

© e-Learning Centre, UCSC 28

Library System – Typical Classes

• Member
• Book
• Copy
• BorrowedCopy
• ReservedCopy

© e-Learning Centre, UCSC 29

Member Book

1 1..* 1

1..*
Copy
1
1

0..3 0..1 0..*

0..2
Borrowed Copy Reserved Copy

Class Diagram for the library system

© e-Learning Centre, UCSC 30
How to draw a sequence Diagram
• Identify a set of objects that will participate in the general collaboration (or use
case scenario)
• You should know the primary actor(s) who activates the use case
• Consider the first point of the scenario (or if you get it from the first point of the
flow of event of a use case)
• Consider what the system need to be done in order to response to the actor,
when the actor send the message to the system
• What the system need to be handled before the return message response back
from the system?
• E.g. A customer inserted an ATM card to the machine, the system will display
"input pin number" in the normal scenario,
• Guess, what will be handled inside the ADM by a set of objects at the "back" of
the system? Something like, read and verify the ATM card (card reader), read
the card information of the card holder (by the bank) and ask for the pin, or,
return "invalid card type, insert another card", and etc.
• By this way, you will identify the candidate objects and operations of the target
application for that particular scenario and you can also use these information
as a basis to derive the class diagram incrementally.
• Repeat each of the point of the scenario (or flow of event) and until you
complete all the points in the scenario.
• One can ignore the return messages if he likes.

© e-Learning Centre, UCSC 31

Drawing the sequence diagram for Lending
(borrowing) Scenario

Eg. Borrowing Scenario Flow of Events section of the Use

Case narrative
Main Flow
Librarian enters the borrower id.
System checks whether borrower id exist.
If not exist (E-1) end use case.
Else Process
Check for Overdue Books.
If yes (E-2) end use case
Check Over limit (E-3)
If yes (E-3) end use case
© e-Learning Centre, UCSC 32
Use Case Narratives cont..
Enter copy id
Check Borrow able (E-4)
If No (E-4) end use case
Librarian Confirm Borrowing (C-5)
Update Borrowed Copy details

Alternate Flows
E-1 : Borrower id exist
E-2 : There are overdue books
E-3 : Borrower has already borrowed 5 books (max)
E-4 : Copy is not borrowable
C-1 : Confirm borrowing Message box

© e-Learning Centre, UCSC 33

Top level Sequence Diagram for Borrowing
Scenario

© e-Learning Centre, UCSC 34

Borrowing Sequence Diagram with objects and messages
(first User interaction)
© e-Learning Centre, UCSC 35
Borrowing Sequence Diagram with objects and messages
(2nd User interaction)
© e-Learning Centre, UCSC 36
Borrowing Sequence Diagram with objects and messages
(3rd User interaction)
© e-Learning Centre, UCSC 37
Borrowing Sequence Diagram with objects and messages
(4th User interaction)
© e-Learning Centre, UCSC 38
Borrowing Sequence Diagram
After mapping objects to classes and messages to methods
Other sequence diagrams can be drawn similarly
© e-Learning Centre, UCSC 39
Case Study 2
Hotel Reservation System
A Hotel consisting of 100 rooms needs to computerize their
manual Hotel Reservation System. The systems analyst who
was assigned to this project has visited the Hotel and he has
gathered the following information about the system. The
following text describes his findings.
The 100 rooms available are categorized into different room
types and each room type has different rates. The number of
rooms in different types and the corresponding rates are as
follows:
Room Type Room No. from/to Rate/Night
Single 1 to 60 Rs. 1000
Double 61 to 89 Rs. 1800
Suite 90 to 100 Rs. 5000
© e-Learning Centre, UCSC 40
Case Study 2
Hotel Reservation System cont…
A Customer can reserve a room by calling the hotel receptionist.
The receptionist will answer customer’s queries regarding the room
types, room rates, modes of payments available and any discounts
the customer is entitled to etc. The receptionist will then take the
following particulars from the customer, if customer wishes to
proceed with the reservation.
Customer’s name, Contact address, Country, Sex,
Type of accommodation, the period of stay, expected check in date.
Subsequently the receptionist will check the room availability. If a
room is available, the customer is informed about the room
availability. If customer accepts the reservation, a room number is
allocated at the same time. The customer is also informed if a
room is not available.

© e-Learning Centre, UCSC 41

 Case Study 2
Hotel Reservation System cont…
A customer can cancel the reservation at any time. It can be done by calling or by
sending a fax. The receptionist is also responsible for handling the cancellations.
When the customer checks-in at the hotel on the reserved date, the receptionist
will obtain the customers desired mode of payment. The customer may be
entitled to a discount based on the payment mode selected.

The different payment modes and their discounts are as follows:

Payment Modes Discount
Cash - No discount
Traveler’s Cheque - 2% eg. AMEX, Cooks etc.
Credit Card - 3% eg. Diners, Master etc.
Company - Depend upon the company,
Eg. NEC 12%, IBM 10% etc.

© e-Learning Centre, UCSC 42

Case Study 2
Hotel Reservation System cont…

The Customer can checks-out from the hotel at any time by

informing the receptionist. The receptionist will immediately
inform the billing Clerk to handle the billing. The details about
the Payments such as discounts given, company name, kind of
traveler’s cheques used, and credit card details etc. are
preserved for any future reference.

If the customer needs to extend the stay, he/she may do so by

informing the receptionist. Receptionist will check the room
availability and extension is accepted if rooms are available.

© e-Learning Centre, UCSC 43

System Actors

• Receptionist
• Billing Clerk
• Customer

According to the Case Study Customer is not a System Actor

© e-Learning Centre, UCSC 44

Use Cases

• Receptionist
Make Reservation, Cancel Reservation, Check-In,
Check-out, Inquiry, Extended stay
• Billing Clerk
Make Payment

© e-Learning Centre, UCSC 45

 A Solution

© e-Learning Centre, UCSC 46

Identifying the Classes

• Let's Look at the Nouns .

• The initial list of nouns must be filtered because, it could
contain nouns that are
➢ outside the problem domain.
➢ language expressions.
➢ redundant.
➢ attributes.

© e-Learning Centre, UCSC 47

Case Study 2
Hotel Reservation System

A Hotel consisting of 100 rooms needs to computerize their

manual Hotel Reservation System. The systems analyst who
was assigned to this project has visited the Hotel and he has
gathered the following information about the system. The
following text describes his findings.
The 100 rooms available are categorized into different room
types and each room type has different rates. The number of
rooms in different types and the corresponding rates are as
follows:
Room Type Room No. from/to Rate/Night
Single 1 to 60 Rs. 1000
Double 61 to 89 Rs. 1800
Suite 90 to 100 Rs. 5000

© e-Learning Centre, UCSC 48

Case Study 2
Hotel Reservation System cont…

A Customer can reserve a room by calling the hotel receptionist.

The receptionist will answer customer’s queries regarding the room
types, room rates, modes of payments available and any discounts
the customer is entitled to etc. The receptionist will then take the
following particulars from the customer, if customer wishes to
proceed with the reservation.
Customer’s name, Contact address, Country, Sex,
Type of accommodation, the period of stay, expected check in date.
Subsequently the receptionist will check the room availability. If a
room is available, the customer is informed about the room
availability. If customer accepts the reservation, a room number is
allocated at the same time. The customer is also informed if a
room is not available.

© e-Learning Centre, UCSC 49

 Case Study 2
Hotel Reservation System cont…
A customer can cancel the reservation at any time. It can be done by calling or
by sending a fax. The receptionist is also responsible for handling the
cancellations.
When the customer checks-in at the hotel on the reserved date, the
receptionist will obtain the customers desired mode of payment. The customer
may be entitled to a discount based on the payment mode selected.

The different payment modes and their discounts are as follows:

Payment Modes Discount
Cash - No discount
Traveler’s Cheque - 2% eg. AMEX, Cooks etc.
Credit Card - 3% eg. Diners, Master etc.
Company - Depend upon the company,
Eg. NEC 12%, IBM 10% etc.

© e-Learning Centre, UCSC 50

Case Study 2
Hotel Reservation System cont…
The Customer can checks-out from the hotel at any time by
informing the receptionist. The receptionist will immediately
inform the billing Clerk to handle the billing. The details about
the Payments such as discounts given, company name, kind of
traveler’s cheques used, and credit card details etc. are
preserved for any future reference.

If the customer needs to extend the stay he/she may do so by

informing the receptionist. Receptionist will check the room
availability and extension is accepted if rooms are available.

© e-Learning Centre, UCSC 51

List of Nouns

Hotel, Room, Type of

accommodation, the
Room type, Rate, Room No, period of stay, expected
Single, Double Suite, check in date.
Customer, Reservation
Receptionist, Payment, Reserved date, Cash,
Trav. Cheque, Credit
Discount, Customer’s name, Card, Company,
Contact address, Country,
Billing Clerk
Sex,

© e-Learning Centre, UCSC 52

Potential Classes

• Room
• Customer
• Payment : Cash, CreditCard, Company, Trav. Cheques
• Reservation
• Room Rate

© e-Learning Centre, UCSC 53

© e-Learning Centre, UCSC 54
Draw the sequence diagrams

• Prepare Use case narratives for each use case

• Draw sequence diagrams(Refer Case Study 1 Solution)
• You may refer the Lecture slides to draw the other UML
diagrams.

© e-Learning Centre, UCSC 55

Summary
A Use Case model can be developed by following the steps
below.
▪ Identify the Actors (role of users) of the system.
▪ For each category of users, identify all roles played by the
users relevant to the system.
▪ Identify what the users required the system to be
performed to achieve these goals.
▪ Create use cases for every goal.
▪ Draw the Use case model
▪ Identify use case to use case relationships

© e-Learning Centre, UCSC 56

 Summary cont..
A Class model can be drawn using the following steps
• Go through the Case Study
• Pick out the nouns.
• Filter list of nouns to identify the objects
• Prepare use case narratives for each use case
• Identify the objects need to interact during the scenario using
the flow of events.
• Complete the class model.
Sequence diagrams can be drawn using the following steps
• Identify a set of objects that will participate in the general
collaboration (or use case scenario)

© e-Learning Centre, UCSC 57

Summary cont..
A Sequence diagram can be drawn using the following steps
• Identify a set of objects that will participate in the general
collaboration (or use case scenario)
• You should also identify the primary actor(s) who activates
the use case
• Consider what the system need to be done in order to
response to the actor, when the actor send the message to
the system
• Most Analyst ignore the return messages in sequence
diagrams.
• Subsequently you can identify the candidate objects and
operations of the target application for that particular
scenario

******

© e-Learning Centre, UCSC 58