The document discusses various UML diagrams including use case diagrams, describing use cases as interactions between actors and systems to achieve goals, use case elements such as actors, scenarios, and relationships including generalization, extension, and inclusion. It provides examples of use case diagrams and templates for an ATM system and a school management system.

1. UNIT I UML DIAGRAMS
Introduction to OOAD – Unified Process –
UML diagrams – Use Case – Class Diagrams–
Interaction Diagrams – State Diagrams –
Activity Diagrams –
Package, component and Deployment Diagrams.

2. Use Case
List of actions (event steps),
defining the interactions b/w a role (actor) and a system,
to achieve a goal.

3. Introduction
• Use cases are not an object-oriented artifact
– They are written stories of using a system to meet the goals.
• Use Case concept was introduced by Ivar Jacobson
• Use Case corresponds to a sequence of transaction,
in which each transaction is invoked from outside the system, and engages
internal objects to interact with one-another and with the system surrounding.

4. Introduction
• Usecases represent specific flow of system
• A usecase diagram is a graph of actors ,a set of usecases enclosed by a
system boundary,communication association b/w actors and usecases

5. Actors
• An actor is a role that a user plays with respect to the system
• Use cases are initiated by actors and describe the flow of events that these
actors set-off
• Actor: External entity interacts (behavior) with the system
– Such as a person (identified by role), computer system, or organization; for
example, a cashier.
• Types of Actors
1. Primary Actor
2. Supporting Actor
3. Offstage Actor

6. Actors
– An actor may be external system that needs some information from the
currrent

7. Types of Actors
• Primary Actor
– Has user goals fulfilled through using services of the SuD (System under Discussion).
– e.g., the cashier.
• Supporting Actor
– Provides a service (for example, information) to the SuD
– e.g., the automated payment authorization service.
– Often a computer system, but could be an organization or person.
• Offstage Actor
– Has an interest in the behavior of the use case, but is not primary or supporting
– e.g., a government tax agency

8. Scenarios
• Scenario
– It is a sequence of actions and interactions
b/w actors and the system .
– It is also called a use case instance.
• For example, the scenario of successfully
purchasing items with cash
• A use case is a set of scenarios tied
together by a common user goal.
I would like a
book of stamps,
please.
That will
be $7.80.
Here is
$10.
Thanks. Here
are your
stamps and
your change.
Yes.
OK. Will
that be all?

9. Capturing Scenarios
• Primary scenario
– Corresponds to the main system interactions, usually the ‘success’ scenario
• Alternate scenarios
– Correspond to less frequent interactions and exceptions
• Format for capturing a use case involves
1. Describing its primary scenario as a sequence of numbered steps and
2. Alternatives as variations on that sequence.

10. Example
Use Case
Text

11. Use Case Diagram
Graphic depiction of the interactions
among the elements of a system

12. Use Case Diagram
• Use case diagrams
– Specify the events of a system and their flows.
– Shows the relationship among the actors & use-case within a system
– Never describes how they are implemented.
• Use case diagrams are used at following places :
– Requirement analysis and high level design.
– Modeling the context of a system.
– Reverse engineering.
– Forward engineering.

13. Purpose of Use Case Diagram
• Purpose of use case diagram
– To identify functions and how roles interact with them
– To capture the dynamic aspect of a system
– Used to gather requirements of a system.
– Used to get an outside view of a system.
– Identify external and internal factors influencing the system.

14. Notations in Use Case Diagram
• Use case diagrams consists of
– Actors,
– Use cases,
– System, and
– Package
• Actor is any entity that performs a role in one given system
An actor could be
a person, organization or an external system

15. Use Case Diagram Objects
• A use case represents a function or an action within the
system
• Its drawn as an oval and named with the function.

16. Use Case Diagram Objects
• System is an optional element
– Used to define the scope of the use case
– Drawn as a rectangle.
– Useful when your visualizing large systems
• Package is optional element
– Used to group together use cases
– Extremely useful in complex diagrams.

17. Relationships in Use Case Diagrams
• Use case relationships can be one of the following:
1. Communicates (Association)
2. Extends
3. Include or uses
4. Generalization

18. Communicates (Association)
• Participation of an actor in a use case is shown by
– Connecting the actor symbol to use case symbol by a solid path.
• Actor is said to 'communicates' with the use case.
• This is only relation between an actor and use cases

19. Generalization
• This relationship is a parent-child relationship b/w use cases
• In this relationship,
– Child use case is an enhancement of the parent use case.
• It is shown as a directed arrow with a triangle arrowhead.
– Child use case is connected at the base of the arrow.
– Tip of the arrow is connected to the parent use case.

20. Consider the following step-by-step outlines to use cases for a simple
phone system:
Place Local Call
1.Caller lifts receiver.
2.System presents dial-tone.
3.Caller dials a digit.
4.System turns off dial-tone.
5.Caller enters remainder of number.
6.System analyzes the number.
7.System finds corresponding party.
8.System connects the parties.
9.Parties disconnect.
Place Long-Distance Call
1.Caller lifts receiver.
2.System presents dial-tone.
3.Caller dials a digit.
4.System turns off dial-tone.
5.Caller enters remainder of number.
6.System analyzes the number.
7.System sends number to other system.
8.System connect the lines.
9.Parties disconnect.

22. Extends
• An extends shows the relationships between use cases.
• Tip of arrowhead points to the parent use case
• Child use case is connected at the base of the arrow
• Example : Validating the user for a system.
– A invalid password is extension of validating password use case

23. Extend is a directed relationship that specifies how and when
the behavior defined in usually supplementary (optional)
extending use case can be inserted into the behavior defined in
the extended use case.

24. Include (Uses)
• In this relationship,
– A use case includes the functionality described in another use case
• Tip of arrowhead points to the child use case
• Parent use case connected at base of the arrow.
Deposit Funds and Withdraw Cash use cases
include Customer Authentication use case.
Checkout use case includes several use cases –
Scan Item, Calculate Total and Tax, and Payment

25. Generalization Extend Include
Base use case could be
abstract use case(incomplete)
or
concrete (complete).
Base use case is complete
(concrete) by itself, defined
independently.
Base use case is incomplete
(abstract use case).
No explicit location to use
specialization.
Has at least one explicit
extension location.
No explicit inclusion location but
is included at some location.
No explicit condition to use
specialization.
Could have optional extension
condition.
No explicit inclusion condition.

26. A use case with most of scenarios found in use case diagrams

27. A use case
template for an
ATM system

29. Generalization

31. school-management-system