OBJECT MODELLING USING UML

SUBRAT//SE 1
 Analysis & Design
 Analysis emphasizes an investigation of the problem and
requirements rather than a solution.
 Design emphasizes a conceptual solution that fulfils the
requirements, rather than its implementation.
 During Object-Oriented Analysis, there is an emphasis on
finding and describing the objects or concepts in the problem
domain.
 During Object-Oriented Design there is an emphasis on
defining software objects and how they collaborate to fulfill the
requirements.
 In case of Library Information System some of the concepts
include Book, Library & Patron.
 In the Library system, a Book software object may have a title
attribute and getChapter method.
SUBRAT//SE 2
 Abstraction Dynamic Binding

Polymorphism Genericity

Encapsulation Composite Objects

Key Concept

Objects

Classes & Instances

ni st pec no C

Inheritance

Messages & Methods

SUBRAT//SE 3
 An Example
Consider a “Dice Game” in which a player rolls two dice. If the total
is 7,
they win; otherwise , they loose.

Define use cases

Define domain model

Define interaction diagrams

Define design class diagrams

SUBRAT//SE 4
 Define use cases

Requirement analysis may include a description of related domain

processes
which can be written as USE CASES which are written stories.
They are
very popular tool in requirement analysis.
Consider the use case of “Play a Dice
Game”
Play a Dice Game : A player picks up and rolls the dice. If the
dice face
value total 7 , they win; otherwise, they lose.

SUBRAT//SE 5
 Define a Domain Model

A decomposition of the domain involves an identification of the

concepts ,
attributes & associations that are considered noteworthy
(necessary). The
results can be expressed in a domain model, which is illustrated in a
set of Player 1 Rolls 2 Die
diagrams
Name that show domain concepts or objects.Face-Value

1 2
1 plays
Dice-Game 1 includes

Here the noteworthy concepts are player, die & dice game, with their
associations &
attributes. Domain model is not a description of software objects ; it is a
visualization SUBRAT//SE 6
of concepts in the real world domain.
 Define Interaction Diagrams
Object-Oriented Design (OOD) is concerned with defining software
objects
and their collaborations. A common notation to illustrate
these
collaborations is the interaction diagram. It shows the flow of
Formessages
a software implementation of the dice game the interaction
diagram is as
between software objects and thus the invocation of methods.
follows:-sending messages to instances of the Dice-Game & Die
classes. :Dice-Game Die1:Die Die2:Die
Play()
roll()

fv1:=get-Face-Value()

roll()

fv2:=get-Face-Value()

SUBRAT//SE 7
In the real world, a player rolls the dice , in the software design
the Dice
Game object “rolls” the dice (that is , sends messages to Die
objects)
Software objects designs & programs do take some inspirations from
real
world domains, but they are not direct models or simulations of the
real world.

SUBRAT//SE 8
 Define Design Class Diagrams

It is useful to create a static view of the class definitions with a

design class
diagram.
In the diceThis illustrates
game, the attributes
an inspection and methods
of the interaction of theleads
diagram classes.
to
the partial
design class diagram.
Dice-Game Die

die1:Die 1 2 faceValue:int
die2:Die
getFaceValue(): int
play()
roll()
A play message is sent to a DiceGame object , the DiceGame class
requires a
play method , while class die requires a roll and getFaceValue
method. It
SUBRAT//SE 9
shows software classes
 Model

A model is a complete description of a system from a particular

perspective. It can be graphical, textual, mathematical or program
code based. It helps manage complexity. It can be used for:-
 Analysis
 Specification
 Design
 Code Generation
 Testing etc…..

SUBRAT//SE 10
 UML

The Unified Modeling Language (UML) is a language for specifying ,

visualizing,
constructing, and documenting the artifacts (general term for work
product
like: code, database schema, web graphics, text documents, models,
The (UML) provides a set of notations (lines, rectangles, lines
diagrams
so etc) to software systems.
on…)of
create models of systems. It is not a system design or
development
methodology rather it can only be used to document OOA & design
UML can be used to construct nine different type of diagrams to
results
captureusing some methodology.
obtained
different views of a system.

SUBRAT//SE 11
 State
State
Diagrams
Class
Diagrams
Use Case Diagrams
Use Case
Diagrams State
Use Case Use Case
Diagrams State
Diagrams
Use Case Diagrams Object
Diagrams
Diagrams
Sequence Diagrams
Diagrams
Diagrams

Scenario State
Scenario
Diagrams State
Diagrams
Collaboration
Diagrams UML Component
Diagrams
Diagrams Diagrams

Scenario Component
Scenario
Diagrams
Component
Diagrams
Deployment
Statechart
Diagrams Diagrams
Diagrams Diagrams
Activity
Diagrams

SUBRAT//SE 12
The UML diagrams can capture the following views of a system:-
Structural View
User’s View
Behavioral View
Implementation View
Environmental View

User’s View defines the facilities made available by the system to

its users.
The User’s View captures the external users’ view of the system in
terms of
the facilities offered by the system. It can be considered as the
Thecentral view view defines the kinds of objects (classes)
structural
and
important
all other to
views
the are expressed to conform to this view.
understanding of the working of a system and to its
implementation. It also
SUBRAT//SE
captures the relationships among the classes (objects). 13
 Behavioral View

Structural View -Sequence diagram

-Class diagram -Collaboration diagram

-Object diagram -State-chart diagram

-Activity diagram

User’s view
-Use Case
Diagram

Implementation View Environmental View

-Component diagram -Deployment diagram

SUBRAT//SE 14
The behavioural view captures how objects interact with each
other to realize the system behaviour.

The implementation view captures the important components of

the system and their dependencies.

The environmental view models how the different components

are implemented on different pieces of hardware.

It is not necessary to draw all the diagrams for a software design

using UML. For a simple system , the use case model , class
diagram, one of the interaction diagrams is sufficient.
For a system in which the objects undergo many state changes, a
state chart diagram may be necessary.
For a system, which is implemented on a large number of
hardware
components , a deployment diagram may be necessary. 15
SUBRAT//SE
 USE CASE MODEL

• A use-case model represents the use-case view of the system. A use-case view of a
system may consist of many use case diagrams.

• An use-case diagram shows (the system) the actors, the use-cases and the
relationship among them.

• Use cases represent the different ways in which a system can be used by the users.

• It is a view of a system that emphasizes the behavior as it appears to outside

users. A use case model partitions system functionality into transactions (‘use cases’)
that are meaningful to users (‘actors’).

SUBRAT//SE 16
The use cases partitions the system behaviour into transactions
such that each transactions performs some useful action from the
user’s point of view.
Use case means : What the user’s can do using the system?

For the LIS, the use cases could be:-

issue-book
Query-book
Return book
Create-number
Add-book etc…
A use cases typically represents a sequence of interactions
between
the user and the system. These interactions consist of one main
line sequence (represents the normal interaction between a user &
the system. SUBRAT//SE 17
In the mainline sequence of the withdraw-cash the use case
supported by a bank ATM would be:
Insert the card
Enter password
Select amount withdraw option
Enter the amount to be withdrawn
Complete the transaction
Get amount

The use cases model represents a functional or process model of a

system.
• A use case
– is always initiated by an actor.
– provides a value to an actor.
– must always be connected to at least one actor.
– must be a complete description.
SUBRAT//SE 18
Use Case Modeling: Core Elements

Construc
A c t o r N a m
U
e

use case SUBRAT//SE 19

Use Case Modeling: Core Relationships

Construct

associatio
<<extend>>

SUBRAT//SE 20
 Construc <<include>>

The mainline sequence and each of the variations( which occurs

when some specific conditions hold.) are called scenarios or

include
instances by a common goal.

SUBRAT//SE 21
 Text Description
The text description should define the details of the interaction
between the user and the computer and other aspects of the
use case. It should include all the behaviour associated with the use
case in terms of the mainline sequence, different variations to the
normal behaviour , the system responses associated with the use
case, the exceptional conditions that may occur in the behaviour,
etc.

SUBRAT//SE 22
 ACTOR

• An actor is something or someone that interacts with the system.

• Actor communicates with the system by sending and receiving

messages.

• An actor provides the stimulus to activate an use case.

• Message sent by an actor may result in more messages to actors

and to use cases.

• Actors can be ranked: primary and secondary; passive and active.

• Actor is a role not an individual instance.

SUBRAT//SE 23
Finding Actors

• The actors of a system can be identified by answering a

number of questions:

– Who will use the functionality of the system?

– Who will maintain the system?

– What devices does the system need to handle?

– What other system does this system need to interact?

– Who or what has interest in the results of this system?

SUBRAT//SE 24
Example

Play Move

Actor (Player) Tic-tac-toe game

SUBRAT//SE 25
 Boundary Use Case
Actor
Library System

Borrow
Employee
Client

Order Title

Fine Remittance

Supervisor

• A generalized description of how a system will be used.

• Provides an overview of the intended functionality of the system
SUBRAT//SE 26
 Example
A supermarket needs to develop the following software to
encourage regular customers. For this, the customer needs to
supply his residence address , telephone number , and the driving
license. Each customer who registers for this scheme is assigned a
unique customer number (CN) by the computer. A customer can
present his CN to the check out staff when he makes any purchase.
In this case, the value of his purchase is credited against his CN. At
the end of each of year , the supermarket awards surprise gifts to
10 customers who make the highest total purchase over the year.
Also, it awards a 22 carat gold coin to every customer who
purchases exceed Rs. 10,000. the entries against the CN are reset
on the last day of every year after the prize winners’ lists are
generated. Draw the use case diagram & text description.
SUBRAT//SE 27
Use Case Model

register-
customer

customer
register-
sales

sales clerk
select
winners

Super Market
manager Prize Scheme

SUBRAT//SE 28
Text Description
Use Case-1: register customer: Using this case , the customer
can register himself by providing the necessary details.
Scenario 1: Mainline sequence:
 Customer: select register customer option.
 System: display prompt to enter name, address, and telephone
number.
 Customer: enter the necessary values
 System: display the generated id and the message that the
customer has been successfully registered.
Scenario 2: Variations
 System : displays the message that the customer has already
registered.
 System: displays the message that some input information has
not been entered. The system displays a prompt to enter the
missing value.
SUBRAT//SE 29
Use Case-2: register sales: Using this case , the clerk can
register the details of the purchase made by a customer.
Scenario 1: Mainline sequence:
 Clerk: selects the register sales option.
 System: displays prompt to enter purchase details & the id of the
customer.
 Clerk: enters the required details.
 System: displays a message of having successfully registered the
sale.

Use Case-3: select winners: Using this case , the manager can
generate the winner list.
Scenario 1: Mainline sequence:
 Manager: selects the select winner option.
 System: displays the gold coin and the surprise gift winner list.

SUBRAT//SE 30
Finding Use Cases
• For each actor ask these questions:

– Which functions does the actor require from the system?

– What does the actor need to do?

– Could the actor’s work be simplified or made efficient by new

functions in the system?

– What events are needed in the system?

– What are the problems with the existing systems?

– What are the inputs and outputs of the system?

SUBRAT//SE 31
Generalization
It can be used when we have one use case that is similar to another,
but does something slightly differently or something more.
Generalization works the same way with use cases as it does with
classes.
Pay membership
fee

Pay through credit Pay through library

card pay card

SUBRAT//SE 32
 Includes
The includes relationship involves one use case including the
behaviour of another use case in its sequence of events and actions.
The includes relationship occurs when you have a chunk of behaviour
that is similar across a number of use cases.

In the includes relationship, a base use case compulsory and

automatically includes the behaviour of the common use case.

<<includes>>

Base use case Common use case

SUBRAT//SE 33
 Issue- Renew-
book book

<<includes>>
<<includes>>
<<includes>>

<<includes>>

Updated
Check Get user
selected
reservation selection
books

SUBRAT//SE 34
 Extends
It allows to show optional system behaviour. An optional system
behaviour is executed only under certain conditions. It is normally
used to capture alternate paths or scenarios.

<<extends>>
Base use case Common use case

SUBRAT//SE 35
Use Case Packaging

• Packages of use cases can be very useful in assigning work

to sub-teams.

Portfolios

Create
Aggregate
New
Portfolios
Portfolio
Generate
View
Portfolio
Portfolio
Report

SUBRAT//SE 36
Use Case Packaging

Accounts

Query Print
balance balance
sheet

Receive
Make
grant
payments

SUBRAT//SE 37
Example
• Captures system functionality as seen by users

SUBRAT//SE 38
 CLASS DIAGRAMS

A class diagram describes the static structure of a

system.

The static structure of a system consists of a number of

class diagrams and their dependences.

The main constitutes of a class diagram are classes

and their relationships : generalization, aggregation,
association, and various kinds of dependencies.

SUBRAT//SE 39
Classes

A class is a description of a set of objects that share the same

attributes, operations, (relationships, and semantics).

An attribute is a named property of a class that describes a

range of values that instances of the property may hold.

An operation is a service that can be requested from an object to

affect behavior.

Classes are represented as solid outline rectangles with

compartments.

The class names is usually written using mixed case convention

and begins with an uppercase. The class names are usually
chosen to be singular nouns.

SUBRAT//SE 40
Class Notation

Name

Attributes

Operations

SUBRAT//SE 41
Alternative Class Notations

Name Name

Attributes Attributes

Name
Operations Operations

Responsibilities
italics abstract

SUBRAT//SE 42
Example

Library Member

Member name
Address
Phone number
E-Mail address

issueBook();
retunBook();
findPendingBooks();

SUBRAT//SE 43
Attributes
An attribute is a named property of a class that describes a range
of values that instances of the property may hold.
These are listed with their names and may optionally contain
specification of their type , an initial value and constraints.

Attribute names are written left justified using plane type letters,
and the name should begin with a lowercase letters.
Attribute names may be followed by a square brackets containing
a multiplicity expression. An attribute without square bracket
must hold one value.

Attribute names may be followed by a equal sign and an initial

value that is used to initialize the attributes of the newly created
objects.

SUBRAT//SE 44
Operation
An operation is something that is supported by a class and
invoked by objects of other classes.
These are typically left-justified , in plane type and always begin
with a lowercase letter.
Abstract operations are written in italics.

An operation may have a return type consisting of a single return

type expression.

An operation may have a class scope ( shared among all the

objects of the class) and is denoted by underlining the operation
name.

SUBRAT//SE 45
Association

• An association is a structural relationship within which classes

or objects are connected to each other. (An association
between objects is called a link.)
A link is a physical or conceptual connection between objects
instances.
An association describes a group of links with a common
structure and common semantics.

An association is a binary relation between two classes but three

or more different classes may be involved in an association. A
class can have an association relationship with itself called
recursive association.

SUBRAT//SE 46
Association between two classes is represented by drawing a
straight line between the concerned classes.

1 Borrowed by
*
Library Member Book

The name of the association is written along side the association

line. An arrowhead may be placed on the association line to
indicate the reading direction of the association.

Many books may be borrowed by a library member.

SUBRAT//SE 47
 Association Multiplicity
• On each side of the association relation, the multiplicity is
noted as an individual number or as a value range.
• The multiplicity indicates how many instances of one class are
associated with the other.
• Value ranges of multiplicity are noted by specifying the
minimum and maximum value separated by dots like 1.5
• An asterisk is a wild card and means many.
• Possible values same as for classes: explicit value, range, or *
for “many”
• Example: a Person is employed by one Company; a Company
employs one or more Persons

*
Person Company
1

SUBRAT//SE 48
Aggregation
Aggregation is a “whole/part” or “has a” relationship within which
one class represents a larger thing that consists of smaller things.

The Aggregation takes the responsibility of forwarding messages

to the appropriate parts.

Aggregation is represented by the diamond symbol at the

composite end of a relationship.

Company

Department

SUBRAT//SE 49
 1 * 1 *
Document Paragraph Line

An Aggregation relationship can not be reflexive that is an object

cannot contain objects of its own class.

SUBRAT//SE 50
Composition

Composition is a special form of aggregation within which the

parts are inseparable from the whole.

The composition relationship is represented as a filled diamond

drawn at the composite-end.

Window

Frame

SUBRAT//SE 51
 Inheritance

The inheritance relationship is represented by means of an empty

arrow pointing from the subclass to the super class.

Library Book

issuable reference

Issuable single Issuable Reference single Reference

volume book Bookset Volume book BookSet

issuable
discriminators
reference
SUBRAT//SE 52
The set of subclasses of a class having the same discriminator is
called a partition.

SUBRAT//SE 53
Dependency

A dependency is a “using” relationship within which the change in

the specification of one class may affect another class that uses it

Dependencies are shown in dotted arrows.

Dependent class Independent class

Two important reasons for dependency among classes are the

following:-
A class invokes the methods provide by another class
A class uses a specific interface of another class.

SUBRAT//SE 54
 OBJECT DIAGRAMS

Object diagram show the snapshot of the objects in a system at a

point in time.
It shows instances of classes, that’s why it is also called instance
diagram.
The objects are drawn using rounded rectangles. Built during
analysis and design

Library Member

SUBRAT//SE 55
 INTERACTION DIAGRAMS

An interaction diagram shows you, step−by−step, one of the

flows through a use case: what objects are needed for the flow,
what messages the objects send to each other, what actor
initiates the flow, and what order the messages are sent.

Interaction diagrams are models that describe how groups of

objects collaborate to realize some behaviour.

Each interaction diagram realizes the behaviour of a single use

case.
Interaction diagrams are of two types:-
01. Sequence diagrams
02. Collaboration diagrams

SUBRAT//SE 56
The two diagrams are equivalent in the sense that any one
diagram can be derived automatically from the other.

An Interaction diagram shows a number of example objects and

the messages that are passed between the objects within a use
case.

SUBRAT//SE 57
 SEQUENCE DIAGRAMS

A sequence diagram is an interaction diagram that emphasizes the

time ordering of messages.

It shows interaction among objects as a two-dimensional chart

which is read from top to bottom.
The objects participating in the interaction are shown at the top of
the chart as boxes attached to a vertical dashed line.
Inside the box the name of the object is written with a colon
separating it from the name of the class, and both the name of
the object and the class are underlined.

The objects appearing at the top signify that the objects already
existed when the use case execution was initiated.

SUBRAT//SE 58
A lifeline is a vertical dashed line that represents the lifetime of
an object which indicates the existence of the object at any
particular point of time.

The rectangle drawn on the lifeline is called the activation

symbol and indicates that the object is active as long as the
rectangle exists.

Each message is indicated as an arrow between the lifelines of

two objects. The messages are shown in chronological order.

A sequence diagram shows a particular sequence of messages

exchanged between a number of objects.
Sequence diagrams also show behavior by showing the ordering
of message exchange.

SUBRAT//SE 59
Sequence diagrams can be used in conjunction with use-cases at
the requirements phase, or at the design phase they can be used
to show the system’s behavior that corresponds to a use-case.

Sequence diagrams can be used to generate test cases for the

software product.

Each message is labelled with the message name. Some control

information can also be included. Two types are particularly
valuable:-
1. A condition indicates that a message is sent , only if the
condition is true.
2. An iteration marker (*) shows the message is sent many times
to multiple receiver objects.

SUBRAT//SE 60
Components of Sequence Diagrams

Object (an instance of a class)

instance name
– shown as a box at the can be omitted
top of a vertical dashed :OrderEntryWindow (means anonymous
line instance)
– instance syntax
Object
instanceName:ClassName

Lifeline
Lifeline
– dashed line, represents
time flow

SUBRAT//SE 61
• Messages :ProductOrder :StockItem

– communication
between objects Message
check()
– method calls at the
implementation level needsToReorder()

• Special message types

Self-delegation
– self-delegation
– return
Return
• show returns only if
it adds to clarity
– <<create>>
– <<destroy>>

SUBRAT//SE 62
• Two kinds of control :Order :ProductOrder :StockItem
information:
*prepare()
check()
– message conditions Iteration
• message is sent [check=“true”]
only if the condition remove()
is true message
condition

– iteration marker: *
• message sent to
multiple receiver
objects

SUBRAT//SE 63
• Focus of control (or :Order :ProductOrder :StockItem
activation) can be shown
in sequence diagrams as a *prepare()
thin rectangle put on top of check()
Iteration
the lifeline of an object
• Shows the period of time [check=“true”]
during which the given remove()
message
object is in control of the condition
flow
• It is optional to use focus of
control rectangles in a
sequence diagram
focus of control
– use it when it adds to or activation
clarity
lifeline

SUBRAT//SE 64
Example

:OrderEntryWindow :Order :ProductOrder :StockItem

prepare()
*prepare()
check()

[check=“true”]
remove()

needsToReorder()

[needsToReorder=“true”]
<<create>>
:ReorderItem

[check=“true”]
<<create>>
:DeliveryItem

SUBRAT//SE 65
SUBRAT//SE 66
Example (LAS) for renew book use case
:Library Book
:Library Book :Library
Renewal :Book
:Library Boundary Register Member
controller

renewBook
FindMemberBorrowing

displayBorrowing
bookselected
*find

selectBook [reserved]

apology
update

[reserved]

apology
conform

conform
updateMemberBorrowing

SUBRAT//SE 67
 COLLABORATION DIAGRAMS

A Collaboration diagram shows both the structural &

behavioural aspects explicitly where as sequence diagram shows
only behavioural view.

The structural aspect of collaboration diagram consists of objects

and the links existing between them. Here the object is also
called a collaborator.
The link between objects is shown as a solid line & can be used to
send messages between two objects. The message is shown as a
labeled arrow placed near the link.
Messages are prefixed with sequence numbers.

SUBRAT//SE 68
A use case of the collaboration diagrams in our development
process would be to help us determine which classes are
associated with which other classes.

The behavioural aspect is described by the set of messages

exchanged among the different collaborators.

SUBRAT//SE 69
 6:*find

:Library Book :Book

[reserved] Register
10: bookselected
9: update
8: apology

5: conform
[reserved]

1: renewBook 7: apology
:Library Book
:Library
Renewal
Boundary
controller
3: displayBorrowing

2: FindMemberBorrowing
4:selectBook

12: conform :Library

Member

11: updateMemberBorrowing

Collaboration diagram for renew book use case

SUBRAT//SE 70
 ACTIVITY DIAGRAMS
The activity diagram focuses on representing activities or chunks
of processing which may or may not correspond to the methods of
classes.
An activity is a state with an internal action & one or more
outgoing transitions with automatically follow the termination of
the internal activity.
Activity diagrams are similar to procedural flow charts. The
difference is that activity diagrams support description of parallel
activities and synchronization aspects involved in different
activities.

While an interaction diagram looks at the objects that pass

messages, an activity diagram looks at the operations that are
passed among objects.

SUBRAT//SE 71
Activity diagrams are normally employed in business process
modeling. This is carried out during the initial stage of
requirements analysis & specification.
These diagrams can be used to develop interaction diagrams
which help to allocate activities (responsibilities) to classes.

SUBRAT//SE 72
Academic section Accounts section Hostel office Hospital Department

Check
student
records

receive
fees

Allot
hostel Create
hospital
record
Receives
Register in
fees
courses
Conduct
medical
Allot
examination
room

Issue
identity
card Student admission procedure at IIT
SUBRAT//SE 73
The diagram shows the part played by different components of
the institute in the admission procedure. After the fees are
received at the account section , parallel activities start at the
hostel office , hospital & the department.

After all these activities complete the identity card can be issued
by the academic section.

SUBRAT//SE 74