Object diagram

Object diagrams are derived from class

diagrams so object diagrams are dependent upon
class diagrams.
Just as an object is an instance of a class, an
object diagram could be viewed as an instance of
a class diagram.
The basic concepts are similar for class
diagrams and object diagrams. Object diagrams
also represent the static view of a system but this
static view is a snapshot of the system at a
particular moment. 1
 Purpose

The purpose of a diagram should be understood

clearly to implement it practically.
The purposes of object diagrams are similar to
class diagrams.
The difference is that a class diagram
represents an abstract model consists of classes
and their relationships. But an object diagram
represents an instance at a particular moment
which is concrete in nature. It means the object
diagram is more close to the actual system
behavior. 2
 Contd. Purpose

So the purpose of the object diagram can be

summarized as:
Forward and reverse engineering.
Object relationships of a system
Static view of an interaction.
Understand object behavior and their
relationship from practical perspective

3
 Basic Object Diagram Symbols and
Notations
Object names
Each object is represented as a rectangle,
which contains the name of the object and its
class underlined and separated by a colon.

4
 How to draw Object Diagram?

To capture a particular system, numbers of

class diagrams are limited.
But if we consider object diagrams then we can
have unlimited number of instances which are
unique in nature.
So only those instances are considered which
are having impact on the system.

5
 Contd.

Before drawing an object diagrams the

following things should be remembered and
understood clearly:
Object diagrams are consist of objects.
The link in object diagram is used to connect
objects.
Objects and links are the two elements used to
construct an object diagram.

6
 Contd.

Now after this the following things are to be

decided before starting the construction of the
diagram:
The object diagram should have a meaningful name to
indicate its purpose.
The most important elements are to be identified.
The association among objects should be clarified.
Values of different elements need to be captured to
include in the object diagram.
Add proper notes at points where more clarity is
required.
7
 Contd.

The following diagram is an example of an

object diagram. It represents the Order
management system which we have discussed in
Class Diagram. The following diagram is an
instance of the system at a particular time of
purchase. It has the following objects
Customer
Order
SpecialOrder
NormalOrder
8
Contd.

9
 Contd.

Now the customer object (C) is associated with

three order objects (O1, O2 and O3).
 These order objects are associated with special
order and normal order objects (S1, S2 and N1).
The customer is having the following three
orders with different numbers (12, 32 and 40) for
the particular time considered.
 Now the customer can increase number of
orders in future and in that scenario the object
diagram will reflect that.
10
 UML Component Diagram

Component diagrams are different in terms of nature

and behavior.
Component diagrams are used to model physical
aspects of a system.
Physical aspects are the elements like executables,
libraries, files, documents etc which resides in a node.
Model physical software components and the
interfaces between them .
Show the structure of the codeitself
Can be used to hide the specification
detail(i.e.,informationhiding) and focus on the
relationship between components 11
 Purpose

Component diagram is a special kind of

diagram in UML.
 The purpose is also different from all other
diagrams discussed so far.
 It does not describe the functionality of the
system but it describes the components used to
make those functionalities.

12
 Contd.

Model the structure of software releases;

Show how components integrate with current
system design.
Model source code and relationships between
files.
Specify the files that are compiled into an
executable

13
 Contd.

So the purpose of the component diagram can

be summarized as:
Visualize the components of a system.
Construct executables by using forward and
reverse engineering.
Describe the organization and relationships of
the components.

14
How to draw Component Diagram?

Component diagrams are used to describe the

physical artifacts of a system.
This artifact includes files, executables,
libraries etc. .
So before drawing a component diagram the
following artifacts are to be identified clearly:
Files used in the system.
Libraries and other artifacts relevant to the
application.
Relationships among the artifacts.
15
How to draw Component Diagram?

Now after identifying the artifacts the following

points needs to be followed:
Use a meaningful name to identify the
component for which the diagram is to be drawn.
Prepare a mental layout before producing using
tools.
Use notes for clarifying important points.

16
 Component Notation

A Component is a physical piece of a system,

such as a compiled object le, piece of source
code, shared library or Enterprise Java Bean
(EJB).

17
Contd.

18
Contd.

19
 UML Use Case Diagram

To model a system the most important aspect is to

capture the dynamic behaviour. To clarify a bit in
details, dynamic behaviour means the behaviour of
the system when it is running
Use case diagrams are used to visualize, specify,
construct, and document the (intended) behavior of
the system, during requirements capture and
analysis.
Provide a way for developers, domain experts and
end-users to Communicate.
Serve as basis for testing.
Use case diagrams contain use cases, actors, and
their relationships. 20
 Purpose

The purpose of use case diagram is to capture the

dynamic aspect of a system.
Use case diagrams are used to gather the
requirements of a system including internal and
external influences. i.e.
the purposes of use case diagrams can be as follows:
Used to gather requirements of a system.
Used to get an outside view of a system.
Identify external and internal factors influencing the
system.
Show the interacting among the requirements are
actors. 21
 Contd.

There are three important parts in a use

case diagram:
 scenario,
 actor and
use case.

22
 Use Case name

• Use cases specify desired behavior.

• A use case is a description of a set of sequences of
actions, including variants, a system performs to
yield an observable result of value to an actor.
• Use case is task or the goal performed by the end
user.
• a collection of related success and failure
scenarios, describing actors using the system to
‫ניתוח מערכות מידע‬

support a goal.
• Each sequence represent an interaction of actors
with the system. 23
 Specifying the Behavior of a Use Case
• Describing the flow of events within the use
case.
• Can be done in natural language, formal
language or pseudo-code.
• Includes: how and when the use case starts
and ends; when the use case interacts with
actors and what objects are exchanged; the
‫ניתוח מערכות מידע‬

basic flow and alternative flows of the

behavior.
24
 Actors
name

• An actor represents a set of roles that users of

use case play when interacting with these use
cases.
• Actors can be human or automated systems.
• Actor is the who of the system, in other words
the end user.
• Actors are entities which require help from the
‫ניתוח מערכות מידע‬

system to perform their task or are needed to

execute the system’s functions.
• Actors are not part of the system.
25
Contd.

26
Contd.

27
Contd.

28
 Contd.

Scenario - a specific sequence of

actions and interactions between actors
and the system .
A sequence of steps that describe the
interactions between an actor and the
system.

29
 How to draw Use Case Diagram?

Use case diagrams are considered for high level

requirement analysis of a system. So when the
requirements of a system are analyzed the
functionalities are captured in use cases.
when we are planning to draw an use case
diagram we should have the following items
identified.
Functionalities to be represented as an use case
Actors
Relationships among the use cases and actors.
30
 Contd.

So after identifying the above items we have to follow the

following guidelines to draw an efficient use case diagram.
The name of a use case is very important. So the name
should be chosen in such a way so that it can identify the
functionalities performed.
Give a suitable name for actors.
Show relationships and dependencies clearly in the diagram.
Do not try to include all types of relationships. Because the
main purpose of the diagram is to identify requirements.
Use note when ever required to clarify some important
points.

31
 Use-Case Diagrams (POST)

POST: Point of Sale Terminal

Use Case
POST
System Boundary

Buy Item

Log In

Cashier Customer
Refund a Purchased Item

Adapted from Larman “Applying UML and Patterns”

32
 Relationships between Use Cases
 A communicates relationship between an
actor and a use case indicates that the actor
initiates the use case. An actor may initiate
one or more use cases.
1. Generalization - use cases that are specialized
versions of other use cases.
2. Include - use cases that are included as parts
of other use cases. Enable to factor common
‫ניתוח מערכות מידע‬

behavior.
3. Extend - use cases that extend the behavior of
other core use cases. Enable to factor variants.
33
 1. Generalization
• A generalization relationship between
actors or use cases indicates that one actor
parent
or use case (the child) inherits the
characteristics of another actor or use case
(the parent). The child actor may initiate all
of the use cases that the parent can initiate.
• The child use case inherits the
child
behavior and meaning of the
‫ניתוח מערכות מידע‬

parent use case.

• The child may add to or
override the behavior of its parent.
34
 More about Generalization
registration

non-graduate graduate
‫ניתוח מערכות מידע‬

registration registration

35
 Relationships between Actors
• Generalization.

student
‫ניתוח מערכות מידע‬

graduate non-graduate
student student

36
 2. Include

An includes relationship suggests that one use case

must include another.
In other words, running one use case means that the
other must be run as well.
One use case may be included by one or more other
use cases.
You have a piece of behavior that is similar across
many use cases.
Break this out as a separate use-case and let the other
ones “include” it.
It is denoted by a dashed unidirectional arrow from
the source use case(s) to the target use case. 37
 Contd. Include
<<include>>
base included

• The base use case explicitly incorporates the

behavior of another use case at a location
specified in the base.
• The included use case never stands alone. It
‫ניתוח מערכות מידע‬

only occurs as a part of some larger base that

includes it.
38
 Contd.
• Enables to avoid describing the same flow of
events several times by putting the common
behavior in a use case of its own.

updating
grades <<include>>
verifying
student id
‫ניתוח מערכות מידע‬

output <<include>>
generating

39
 Extends relationship

An extends relationship is used when one use case

optionally extends the functionality provided by
another.
 In other words, if one use case runs, an extending
use case may or may not run.
Extend relationship between Use Cases (one UC
calls Another under certain condition; think of if-
then decision points).
A use-case is similar to another one but does a
little bit more.
40
 Contd. Extend
<<extend>>
base extending

• The base use case implicitly incorporates the

behavior of another use case at certain points
called extension points.
• The base use case may stand alone, but under
certain conditions its behavior may be
extended by the behavior of another use
‫ניתוח מערכות מידע‬

case.

41
 Contd. Extend
• Enables to model optional behavior or
branching under conditions.

<<extend>> Exam-grade
Exam copy
request appeal
‫ניתוח מערכות מידע‬

42
 Example

place
place <<extend>>
conference
phone call
call
cellular
network receive
receive <<extend>>
additional
phone call
call
‫ניתוח מערכות מידע‬

use
user scheduler
Cellular Telephone

43
 ‫ניתוח מערכות מידע‬
‫‪Example‬‬

‫‪44‬‬
 Exercise- Money Withdraw
• Use Case: Withdraw Money
• Purpose: To withdraw some cash from user’s bank
account
• Overview: The use case starts when the customer inserts
his credit card into the system. The system requests the
user PIN. The system validates the PIN. If the validation
succeeded, the customer can choose the withdraw
operation else alternative 1 – validation failure is
executed. The customer enters the amount of cash to
withdraw. The system checks the amount of cash in the
user account, its credit limit. If the withdraw amount in
‫ניתוח מערכות מידע‬

the range between the current amount + credit limit the

system dispense the cash and prints a withdraw receipt,
else alternative 2 – amount exceeded is executed.
45
 Contd. Money Withdraw (cont.)
• Actors: Customer
• Pre Condition:
– The ATM must be in a state ready to accept transactions
– The ATM must have at least some cash on hand that it
can dispense
– The ATM must have enough paper to print a receipt for at
least one transaction
• Post Condition:
– The current amount of cash in the user account is the
‫ניתוח מערכות מידע‬

amount before the withdraw minus the withdraw amount

– A receipt was printed on the withdraw amount
– The withdraw transaction was audit in the System log file
46
 Example- Money Withdraw (cont.)
 Typical Course of events:

Actor Actions System Actions

1. Begins when a Customer arrives at ATM

2. Customer inserts a Credit card into ATM 3. System verifies the customer ID and status

5. Customer chooses “Withdraw” operation 4. System asks for an operation type

7. Customer enters the cash amount 6. System asks for the withdraw amount
8. System checks if withdraw amount is legal

9. System dispenses the cash

10. System deduces the withdraw amount from
‫ניתוח מערכות מידע‬

account

11. System prints a receipt

13. Customer takes the cash and the receipt 12. System ejects the cash card

47