OOSE Lab File

myCampusNotes.com
 USE CASE DIAGRAMS
The use case model identifies the requirements of the system in terms of the functionality that must exist to
achieve the goals set out by the user or to solve a problem identified by the user.

Uses cases describe the major behaviors that you identify in the requirements and describe the value that the
results give the users; they do not describe how the system operates internally.

Use case diagrams depict the relationships between the uses cases and actors and activity diagrams to describe
the flow of objects and control in each identified behavior.

A use case is a list of steps, typically defining interactions between a role (known as actor) and a system, to
achieve a goal.
Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or
functions provided by the system to its users.
Use Case Diagram includes
1. Use Case
2. Actor
3. System

Use Case

A use case describes a function that a system performs to achieve the users goal. A use case must yield an
observable result that is of value to the user of the system.

Use cases contain detailed information about the system, the systems users, relationships between the system
and the users, and the required behavior of the system. Use cases do not describe the details of how the system
is implemented.

Each use case describes a particular goal for the user and how the user interacts with the system to achieve that
goal. The use case describes all possible ways that the system can achieve, or fail to achieve, the goal of the
user.

Each use case must have a unique name that describes the action that the system performs. Use case names are
often short phrases that start with a verb, such as Place Order Online.

A use case is displayed as an oval that contains the name of the use case.

Actors

An actor represents a role of a user that interacts with the system that you are modeling. The user can be a
human user, an organization, a machine, or another external system.
Actors are external to the system. They can initiate the behavior described in the use case or be acted upon by
the use case. and exchange data with the system.

Each actor has a unique name that describes the role of the user who interacts with the system.An actor is
displayed as a line drawing of a person.

System Boundary:
A system boundary defines the scope of what a system will be. A system can not have infinite functionality. A
system boundary of a use case diagram defines the limits of the system. The system boundary is shown as a
rectangle spanning all use cases in the system.
Place actors outside the system's boundaries.

Relationships in Use Case Diagram:

A relationship between two use cases is basically a dependency between the two use cases.

Relationship among actors and use cases reduce systems model complexity.

Use case relationships can be of following types:

Communicates: The participation of an actor in a use case is shown by connecting the actor symbol to
use case symbol by a solid path. The actor is said to 'communicates' with the use case. This is only
relation between an actor and use cases.

Extends: An extends shows the relationships between use cases. Relationship between
use case A and use case B indicates that an instance of use case B may include (subject
to specified in the extension) the behavior specified by A. An 'extends' relationship
between use cases is depicted with a directed arrow having a dotted shaft. The tip of
 arrowhead points to the parent use case and the child use case is connected at the base of
the arrow. The stereotype <extends> identifies as an extend relationship.

Include or uses: When a use case is depicted as using functionality of another functionality of another
use case, this relationship between the use cases is named as an include or uses relationship.

A uses relationship from use case A to use case B indicates that an instance of the use case will also
include the behavior as specified by B. An include relationship is depicted with a directed arrow having
a dotted shaft. The tip of arrowhead points to the child use case and the parent use case connected at
base of the arrow. The stereotype <include> identifies the relationship as an include relationship.

Generalization: A generalization relationship is also a parent-child relationship between use cases. The
child use case in the generalization relationship has the underlying business process meaning, but is an
enhancement of the parent use case. In a use case diagram, generalization is shown as a directed arrow
with a triangle arrowhead. The child use case is connected at the base of the arrow. The tip of the arrow
is connected to the parent use case.
 EXPERIMENT NO.1

AIM: Draw Use Case diagram for EXAMINATION PORTAL

 EXPERIMENT NO.2

AIM: Draw Use Case diagram for RAILWAY RESERVATION SYSTEM.

 EXPERIMENT NO.3

AIM: Draw Use Case diagram for LIBRARY MANAGEMENT SYSTEM

 EXPERIMENT NO.4

AIM: Draw Use Case diagram for AIRLINE RESERVATION SYSTEM

 EXPERIMENT NO.5

AIM: Draw Use Case diagram for HOTEL MANAGEMENT SYSTEM

 EXPERIMENT NO.6

AIM: Draw a use case diagram for a ticket distributor for a train system. The system includes two actors: a
traveler who purchases different types of tickets and a central computer system that maintains a reference
database for the tariff. Use cases should include BuyOneTicket, BuyWeeklyCard and UpdateTariff. Also
include the following exceptional cases TimeOut (i.e. traveler look too long to insert the right amount),
TransactionAborted (i.e. traveler selected the cancel button without completing the transaction),
DistributorOutOfChange, and DistributorOutOfPaper.
 EXPERIMENT NO.7

AIM: Draw use case of an ATM system with at least 3 different actors that interact with system.
 INTERACTION DIAGRAM
Interaction diagram is used to describe some type of interactions among the different elements in the model. So
this interaction is a part of dynamic behavior of the system.

This interactive behavior is represented in UML by two diagrams

1. Sequence diagram.
2. Collaboration diagram.

The basic purposes of both the diagrams are similar.

Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the
structural organization of the objects that send and receive messages.

To choose between these two diagrams the main emphasis is given on the type of requirement. If the time
sequence is important then sequence diagram is used and if organization is required then collaboration diagram
is used.

The purposes of interaction diagram can be describes as:

To capture dynamic behavior of a system.

To describe the message flow in the system.
To describe structural organization of the objects.
To describe interaction among objects.

The following things are to be identified clearly before drawing the interaction diagram:

Objects taking part in the interaction.

Message flows among the objects.
The sequence in which the messages are flowing.
Object organization.

A single diagram is not sufficient to describe the dynamic aspect of an entire system so a set of diagrams are

used to capture is as a whole.

The interaction diagrams are used when we want to understand the message flow and the structural
organization. Now message flow means the sequence of control flow from one object to another and structural
organization means the visual organization of the elements in a system.

In a brief the following are the usages of interaction diagrams:

To model flow of control by time sequence.

To model flow of control by structural organizations.
For forward engineering.
For reverse engineering.

The Sequence Diagram:

Sequence diagrams are used to capture the order of messages flowing from one object to another. A sequence
diagram is an interaction diagram that shows how processes operate with one another and in what order. It is a
construct of a Message Sequence Chart. A sequence diagram shows object interactions arranged in time
sequence. It depicts the objects and classes involved in the scenario and the sequence of messages exchanged
between the objects needed to carry out the functionality of the scenario. Sequence diagrams are typically
associated with use case realizations in the Logical View of the system under development. Sequence diagrams
are sometimes called event diagrams, event scenarios.

The Collaboration Diagram:

The second interaction diagram is collaboration diagram. It shows the object organization as shown below. Here
in collaboration diagram the method call sequence is indicated by some numbering technique as shown below.
The number indicates how the methods are called one after another.

The collaboration diagrams are used to describe the structural organizations of the objects taking part in the
interaction.

The method calls are similar to that of a sequence diagram. But the difference is that the sequence diagram does
not describe the object organization whereas the collaboration diagram shows the object organization.
 EXPERIMENT NO.8

AIM: Draw sequence and collaboration diagram for Library Management System.

LOGIN
Sequence Diagram:

Collaboration Diagram:
ISSUE BOOK
Sequence Diagram:

Collaboration Diagram
RETURN BOOK
Sequence Diagram:

Collaboration Diagram:
 EXPERIMENT NO.9

AIM: Draw sequence and collaboration diagram for Airline Reservation System.

LOGIN

Sequence Diagram:

Collaboration Diagram:
BOOK TICKET

Sequence Diagram:

Collaboration Diagram:
CANCEL TICKET

Sequence Diagram

Collaboration Diagram:
DETAILS

Sequence Diagram:

Collaboration Diagram:
 EXPERIMENT NO.10

AIM: Draw sequence and collaboration diagram for Railway Reservation System.

LOGIN

Sequence Diagram:

Collaboration Diagram:
DETAILS

Sequence Diagram:

Collaboration Diagram:
BOOK TICKET

Sequence Diagram:

Collaboration Diagram:
CANCEL TICKET

Sequence Diagram:

Collaboration Diagram:
 EXPERIMENT NO.11

AIM: Draw sequence and collaboration diagram for Examination Portal.

LOGIN

Sequence Diagram:

Collaboration Diagram:
TAKE TEST & SELECT COURSE
Sequence Diagram

Collaboration Diagram
RESULT
Sequence Diagram

Collaboration Diagram
 EXPERIMENT NO.12

AIM: Draw sequence and collaboration diagram for an Hotel Management System,.

LOGIN

Sequence Diagram:

Collaboration Diagram:
BOOK ROOMS
Sequence Diagram

Collaboration Diagram
CHECK OUT
Sequence Diagram

Collaboration Diagram
 CLASS DIAGRAM

The class diagram is the main building block of object oriented modelling. It is used both for general conceptual
modelling of the systematics of the application, and for detailed modelling translating the models
into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram
represent both the main objects, interactions in the application and the classes to be programmed.

A class diagram in UML is a type of static structure diagram that describes the structure of a system by showing
the system's classes, their attributes, operations (or methods), and the relationships among objects.

UML provides mechanisms to represent class members, such as attributes and methods, and additional
information about them.
To specify the visibility of a class member (i.e., any attribute or method) these are the following notations that
must be placed before the member's name:
"+" Public
"-" Private
"#" Protected

UML CLASS DIAGRAMS HAS FOLLOWING COMPONENTS:

1. Links
A Link is the basic relationship among objects.
2. Association
An association represents a family of links. Binary associations (with two ends) are normally represented as a
line. An association can be named, and the ends of an association can be adorned with role names, ownership
indicators, multiplicity, visibility, and other properties.
3. Aggregation
Aggregation is a variant of the "has a" association relationship; aggregation is more specific than association. It
is an association that represents a part-whole or part-of relationship. As a type of association, an aggregation
can be named and have the same adornments that an association can. However, an aggregation may not involve
more than two classes.

4. Generalization
The Generalization relationship ("is a") indicates that one of the two related classes (the subclass) is considered
to be a specialized form of the other (the super type) and superclass is considered as 'Generalization' of
subclass.
The generalization relationship is also known as the inheritance or "is a" relationship.
5. Dependency
Dependency is a weaker form of bond which indicates that one class depends on another because it uses it at
some point in time. One class depends on another if the independent class is a parameter variable or local
variable of a method of the dependent class. This is different from an association, where an attribute of the
dependent class is an instance of the independent class.
6. Multiplicity
This association relationship indicates that (at least) one of the two related classes make reference to the other.
This relationship is usually described as "A has a B".

0..1 No instances, or one instance

1 Exactly one instance

0..* or * Zero or more instances

1..* One or more instances

 EXPERIMENT NO.13

AIM: Draw class diagram representing the relationship between parents and children. Take into account that a
person can have both a parent and a child. Annotate with roles and multiplicities.
 EXPERIMENT NO.14

AIM: Draw class diagram of an ATM system.

 EXPERIMENT NO.15

AIM: Draw a class diagram representing a book defined by the following statement: A book is composed of a no. of
parts which in turn are composed of no. of chapters. Chapters are composed of sections. Focus only on classes and
relationships. Add multiplicity to the class diagram.
 EXPERIMENT NO.16

AIM: Draw class diagram for Hospital Management System.

 EXPERIMENT NO.17

AIM: Draw class diagram for Library Management System.

 EXPERIMENT NO.18

AIM: Draw class diagram for Airline Reservation System.

 EXPERIMENT NO.19

AIM: Draw class diagram for a ticket distributor for a train system.
 ACTIVITY DIAGRAM

Activity diagram is another important diagram in UML to describe dynamic aspects of the system.
Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The
activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. This flow can be sequential, branched or
concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc.

Purpose:
The basic purposes of activity diagrams are similar to other four diagrams. It captures the dynamic behaviour of
the system. Other four diagrams are used to show the message flow from one object to another but activity
diagram is used to show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only used for visualizing dynamic
nature of a system but they are also used to construct the executable system by using forward and reverse
engineering techniques.
It does not show any message flow from one activity to another. Activity diagram is some time considered as
the flow chart. Although the diagrams looks like a flow chart but it is not. It shows different flow like parallel,
branched, concurrent and single.So the purposes can be described as:

Draw the activity flow of a system.

Describe the sequence from one activity to another.

Describe the parallel, branched and concurrent flow of the system.

How to draw Activity Diagram?

Activity diagrams are mainly used as a flow chart consists of activities performed by the system. But activity
diagram are not exactly a flow chart as they have some additional capabilities. These additional capabilities
include branching, parallel flow, swim lane etc.
The main element of an activity diagram is the activity itself. An activity is a function performed by the system.
After identifying the activities we need to understand how they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements:
o Activities
o Association
o Conditions
o Constraints
Once the above mentioned parameters are identified we need to make a mental layout of the entire flow. This
mental layout is then transformed into an activity diagram.
Example:
 EXPERIMENT NO.20

AIM: Draw activity diagram for ATM .

 EXPERIMENT NO.21

AIM: Draw activity diagram for AIRLINE RESERVATION SYSTEM.

LOGIN

BOOK FLIGHT

CANCEL TICKET
 EXPERIMENT NO.22

AIM: Draw activity diagram for LIBRARY MANAGEMENT SYSTEM.

LOGIN

ISSUE BOOK
RETURN BOOK
 EXPERIMENT NO.23

AIM: Draw activity diagram for HOTEL MANAGEMENT SYSTEM.

LOGIN

BOOK ROOM
CANCEL BOOKING

GENERATE BILL
 EXPERIMENT NO.24

AIM: Consider the process of ordering a pizza over phone. Draw an activity diagram representing each step of
process from picking the phone to eating pizza. Include activities that are need to perform.
 STATE TRANSITION DIAGRAM

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states
of a component in a system. The states are specific to a component/object of a system.
A State chart diagram describes a state machine. Now to clarify it state machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal events.
State chart diagram defines states it is used to model lifetime of an object.

Purpose:
State chart diagram is one of the five UML diagrams used to model dynamic nature of a system. They define
different states of an object during its lifetime. And these states are changed by events. So Statechart diagrams
are useful to model reactive systems. Reactive systems can be defined as a system that responds to external or
internal events.
State chart diagram describes the flow of control from one state to another state. States are defined as a
condition in which an object exists and it changes when some event is triggered. So the most important purpose
of State chart diagram is to model life time of an object from creation to termination.
State chart diagrams are also used for forward and reverse engineering of a system. But the main purpose is to
model reactive system.
Following are the main purposes of using State chart diagrams:

To model dynamic aspect of a system.

To model life time of a reactive system.

To describe different states of an object during its life time.

Define a state machine to model states of an object.

How to draw State chart Diagram?

State chart diagram is used to describe the states of different objects in its life cycle. So the emphasis is given on
the state changes upon some internal or external events. These states of objects are important to analyze and
implement them accurately.
State chart diagrams are very important for describing the states. States can be identified as the condition of
objects when a particular event occurs.
Before drawing a State chart diagram we must have clarified the following points:
Identify important objects to be analyzed.

Identify the states.

Identify the events.

 EXPERIMENT NO.25

AIM: Draw state chart diagram for ORDER PROCESSING SYSTEM .

 EXPERIMENT NO.26

AIM: Consider a traffic light system at 4 way cross roads assume simplest algorithm for cycling through lights.
Identify states of system and draw state chart remembering each light has green, red, yellow.
 EXPERIMENT NO.27

AIM: Draw a state chart diagram for HOTEL MANAGEMENT SYSTEM.

 EXPERIMENT NO.28

AIM: Draw a state chart diagram for AIRLINE RESERVATION SYSTEM.

 DEPLOYMENT DIAGRAM

A deployment diagram in the Unified Modeling Language models the physical deployment
of artifacts on nodes. To describe a web site, for example, a deployment diagram would show what hardware
components ("nodes") exist (e.g., a web server, an application server, and a database server), what software
components ("artifacts") run on each node (e.g., web application, database), and how the different pieces are
connected (e.g. JDBC, REST, RMI).
The nodes appear as boxes, and the artifacts allocated to each node appear as rectangles within the boxes. Nodes
may have sub nodes, which appear as nested boxes. A single node in a deployment diagram may conceptually
represent multiple physical nodes, such as a cluster of database servers.
There are two types of Nodes:

1. Device Node
2. Execution Environment Node
Device nodes are physically computing resources with processing memory and services to execute software,
such as typical computer or mobile phones. An execution environment node (EEN) is a software computing
resource that runs within an outer node and which itself provides a service to host and execute other executable
software elements.
Deployment diagram shows execution architecture of systems that represent the assignment (deployment) of
software artifacts to deployment targets (usually nodes).

Nodes represent either hardware devices or software execution environments. They could be connected through
communication paths to create network systems of arbitrary complexity.

Artifacts represent concrete elements in the physical world that are the result of a development process and are
deployed on nodes.
 EXPERIMENT NO.29

AIM: Draw deployment diagram for AIRLINE RESERVATION SYSTEM .

 EXPERIMENT NO.30

AIM: Draw deployment diagram for HOSPITAL MANAGEMENT SYSTEM .