Agenda

— UML - Use Case Diagrams

— UML - Interaction Diagrams
UML - Use Case Diagrams
— The purpose of use case diagram is to capture the dynamic aspect of a system.

— However, this definition is too generic to describe the purpose, as other four diagrams (activity, sequence,
collaboration, and Statechart) also have the same purpose.

— We will look into some specific purpose, which will distinguish it from other four diagrams.

— Use case diagrams are used to gather the requirements of a system including internal and external influences.

— These requirements are mostly design requirements. Hence, when a system is analyzed to gather its functionalities,
use cases are prepared and actors are identified.

— When the initial task is complete, use case diagrams are modelled to present the outside view.

— In brief, the purposes of use case diagrams can be said to be as follows −

— Used to gather the requirements of a system.
— Used to get an outside view of a system.
— Identify the external and internal factors influencing the system.
— Show the interaction among the requirements are actors.
UML - Use Case Diagrams
— Use case diagrams are designed with 4 major
elements
— Actors
— System
— Use Cases
— Relationships between actors and use cases

— Actors
— Actor is an external entity, any “object” or person
that has behavior associated with it.
— You can picture an actor as a user of the IT system.
— Generally, the users are actors but often systems can
be actors as well. Actor names should not
correspond to job titles.
— Ticket vending machine allows commuters to buy
tickets. So Commuter is our actor in this case.
— Customer is an actor for the money vending
machine.
UML - Use Case Diagrams
— System
— System is used to define the scope of the use case and drawn as a rectangle.
— This an optional element but useful when your visualizing large systems.
— For example you can create all the use cases and then use the system object to
define the scope covered by your project. Or you can even use it to show the
different areas covered in different releases.

— Use Case
— Use cases represent the activities that actors perform with the help of your system
in the pursuit of a particular goal.
— We need to define what those users (actors) need from the system.
— Use case should reflect user needs and goals, and should be initiated by an actor.
— Business actor Customer participating in the business use case should be
connected to the use case by association.
UML - Use Case Diagrams
— The ultimate goal of the customer in relation to our money vending machine is to
withdraw money.
— So we are adding Withdrawal use case.
— Withdrawing money from the vending machine might involve a bank for the
transactions to be made.
— So we are also adding another actor – Bank. Both actors participating in the use case
should be connected to the use case by association.
— Money vending machine provides Withdrawal use case for the customer and Bank
actors.
UML - Use Case Diagrams
— Relationships between Actors and Use cases
— Use cases could be organized using following relationships:
— Generalization
— Association
— Extend
— Include

— Generalization between Use Cases

— There may be instances where actors are associated with similar use cases.
— In such case a Child use case inherits the properties and behavior of the parent use.
— Hence we need to generalize the actor to show the inheritance of functions. They are represented by a solid line with a
large hollow triangle arrowhead.
UML - Use Case Diagrams
— Association between Use Cases
— Associations between actors and use cases are indicated in use case diagrams by solid lines.
— An association exists whenever an actor is involved with an interaction described by a use case.

— Extend
— There are some functions that are triggered optionally. In such cases the extend relationship is used and the
extension rule is attached to it. Thing to remember is that the base use case should be able to perform a
function on its own even if the extending use case is not called.
— Extend relationship is shown as a dashed line with an open arrowhead directed from the extending use
case to the extended (base) use case. The arrow is labeled with the keyword «extend».

— Include
— It is used to extract use case fragments that are duplicated in multiple use cases. It is also used to simplify
large use case by splitting it into several use cases and to extract common parts of the behaviors of two or
more use cases.
— Include relationship between use cases which is shown by a dashed arrow with an open arrowhead from
the base use case to the included use case. The arrow is labeled with the keyword «include».
— Use cases deal only in the functional requirements for a system. Other requirements such as business rules,
quality of service requirements, and implementation constraints must be represented separately.
UML - Use Case Diagrams
— The diagram shown below is an example of a simple use case diagram with all the elements
marked.
UML - Use Case Diagrams
— Basic Principles for Successful Application of Use cases
— Keep it simple by telling stories
— Be productive without perfection
— Understand the big picture
— Identify reuse opportunity for use cases
— Focus on value
— Build the system in slices
— Deliver the system in increments
— Adapt to meet the team’s needs

— Use case diagrams can be used for −

— Requirement analysis and high level design.
— Model the context of a system.
— Reverse engineering.
— Forward engineering.

— Guidelines to draw an efficient use case diagram

— The name of a use case is very important. 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, as the main purpose of the diagram is to identify the requirements.
— Use notes whenever required to clarify some important points.
UML - Interaction Diagrams
— This interactive behavior is represented in UML by two diagrams known as
Sequence diagram and Collaboration diagram.

— The basic purpose 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.

— The purpose of interaction diagram is −

— To capture the dynamic behaviour of a system.
— To describe the message flow in the system.
— To describe the structural organization of the objects.
— To describe the interaction among objects.
UML - Interaction Diagrams
— The sequence diagram captures the time sequence of the message flow
from one object to another and the collaboration diagram describes the
organization of objects in a system taking part in the message flow.

— 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
UML - Interaction Diagrams
— Interaction diagrams are used when we want to understand the
message flow and the structural organization.

— Message flow means the sequence of control flow from one object to
another. Structural organization means the visual organization of the
elements in a system.

— Interaction diagrams can be used −

— To model the flow of control by time sequence.
— To model the flow of control by structural organizations.
— For forward engineering.
— For reverse engineering.
UML - sequence diagram
— The sequence diagram has four objects (Customer, Order, SpecialOrder
and NormalOrder).

— The following diagram shows the message sequence for SpecialOrder

object and the same can be used in case of NormalOrder object.

— It is important to understand the time sequence of message flows.

— The message flow is nothing but a method call of an object.

UML - sequence diagram

— The first call is sendOrder () which is a

method of Order object.

— The next call is confirm () which is a

method of SpecialOrder object and the
last call is Dispatch () which is a
method of SpecialOrder object.

— The following diagram mainly

describes the method calls from one
object to another, and this is also the
actual scenario when the system is
running.
UML - collaboration diagram
— The second interaction diagram is the collaboration diagram.

— It shows the object organization as seen in the following diagram.

— In the collaboration diagram, the method call sequence is indicated by

some numbering technique.

— The number indicates how the methods are called one after another.

— We have taken the same order management system to describe the

collaboration diagram.
UML - collaboration diagram
— Method calls are similar to that of a sequence
diagram.

— However, difference being the sequence

diagram does not describe the object
organization, whereas the collaboration
diagram shows the object organization
— .
— To choose between these two diagrams,
emphasis is placed on the type of
requirement.

— If the time sequence is important, then the

sequence diagram is used.

— If organization is required, then

collaboration diagram is used.