Reservation System: Request Ticket Reservation System -> Database: Check Availability Database -> Reservation System: Ticket Details Reservation System -> Traveler: Display Available Tickets Traveler -> Reservation System: Select Ticket Reservation System -> Payment Gateway: Initiate Payment Payment Gateway -> Traveler: Request Payment Traveler -> Payment Gateway: Payment Details Payment Gateway -> Reservation System: Payment Confirmation Reservation System -> Traveler: Ticket Receipt Collaboration Diagram: Traveler Reservation System Database Payment Gateway Traveler - Reservation System"> Reservation System: Request Ticket Reservation System -> Database: Check Availability Database -> Reservation System: Ticket Details Reservation System -> Traveler: Display Available Tickets Traveler -> Reservation System: Select Ticket Reservation System -> Payment Gateway: Initiate Payment Payment Gateway -> Traveler: Request Payment Traveler -> Payment Gateway: Payment Details Payment Gateway -> Reservation System: Payment Confirmation Reservation System -> Traveler: Ticket Receipt Collaboration Diagram: Traveler Reservation System Database Payment Gateway Traveler - Reservation System">
OOSE File
OOSE File
OOSE 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.
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.
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 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.
1. Sequence diagram.
2. Collaboration diagram.
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 following things are to be identified clearly before drawing the interaction diagram:
A single diagram is not sufficient to describe the dynamic aspect of an entire system so a set of diagrams are
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.
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
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
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".
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 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 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:
BOOK FLIGHT
CANCEL TICKET
EXPERIMENT NO.22
ISSUE BOOK
RETURN BOOK
EXPERIMENT NO.23
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:
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
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