8
Uploaded by
bt06528
Uploaded by
bt065221CSC101T
Object Oriented Design and Programming
UML use case Diagram
USECASE DIAGRAM
•Use case diagrams are used to depict the context of the system to be built and the
functionality provided by that system.
•They depict who (or what) interacts with the system.
•They show what the outside world wants the system to do.
• Use cases are represented with a labeled oval shape.
• Stick figures represent actors in the process, and the actor's participation in the system is modeled
with a line between the actor and use case.
• To depict the system boundary, draw a box around the use case itself.
• UML use case diagrams are ideal for:
• Representing the goals of system-user interactions
• Defining and organizing functional requirements in a system
• Specifying the context and requirements of a system
• Modeling the basic flow of events in a use case
Common components include:
Actors: The users that interact with a system. An actor can be a person, an organization, or an outside
system that interacts with your application or system. They must be external objects that produce or
consume data.
System: A specific sequence of actions and interactions between actors and the system. A system may also
be referred to as a scenario.
Goals: The end result of most use cases. A successful diagram should describe the activities and variants
used to reach the goal.
NOTATIONS
• Actors are entities that interface with the system.
• They can be people or other systems.
• Actors, which are external to the system they are using, are depicted as
stylized stick figures.
Relationship
Two relationships used primarily for organizing use case models are
both powerful
• «include» relationship
• «extend» relationship
• "The include relationship is intended for reusing behavior modeled by another use case, whereas the
extend relationship is intended for adding parts to existing use cases as well as for
modeling optional system services“
• Include = reuse of functionality (i.e. the included functionality is used or could be used elsewhere in the
system). Include therefore denotes a dependency on another use case.
• Extends = adding (not reusing) functionality and also any optional functionality. Extends therefore can
denote one of two things:
1. adding new features/capabilities to a use case (optional or not)
2. any optional use cases (existing or not).
• Include = reuse of functionality
Extends = new and/or optional functionality
• Include is used to extract use case fragments that are duplicated in multiple use cases.
• The included use case cannot stand alone and the original use case is not complete without the
included one.
• This should be used sparingly and only in cases where the duplication is significant and exists by design
(rather than by coincidence).
• For example, the flow of events that occurs at the beginning of every ATM use case (when the user
puts in their ATM card, enters their PIN, and is shown the main menu) would be a good candidate for
an include.
• Extend is used when a use case adds steps to another first-class use case.
• For example, imagine "Withdraw Cash" is a use case of an Automated Teller Machine (ATM).
• "Assess Fee" would extend Withdraw Cash and describe the conditional "extension point" that is
instantiated when the ATM user doesn't bank at the ATM's owning institution.
• Notice that the basic "Withdraw Cash" use case stands on its own, without the extension.
