”
Introduction | Using UML 2.0 (Use Case Diagrams) Page 2 of 14
Introduction
A Use case diagram shows the relationship between the system being described (as chunks of functionality
from an external perspective called use cases) and the external entities (called actors). The external entities
and use cases are separated in the diagram by the system boundary that represents the limits of what is
implemented by the system.
Within the system boundary are the parts that describe the system functionality from the user perspective.
There can be common elements that use cases draw on which would be separated out into another use case
(through an include relationship), extra pieces of functionality that deal with special cases or optional
functionality on a use case (through and extend relationship), or even extra use cases that can have
specialisations (more detail / functionality added).
Outside of the system boundary are the actors that interact with the system. This interaction is represented by
a communication line. A communication line is an unbroken line with no arrow heads indicating that the
communication is in both directions, or it will have an arrow head indicating that the communication is only in
one direction (although it could be argued that in almost all cases there is some sort of feedback, and hence
communication is in both directions throughout the interaction with a use case). The communication line is
drawn between the use case and the actor interacting with that chunk of functionality.
The components of a use case diagram include: The system boundary, system name, actors, use cases,
communication lines between actors (Note that these do not represent any direct interaction with the system.),
communication lines between actors and use cases, (include, extend, and inheritance) arrows
between use cases. These are detailed in the rest of this document. (Note there is no mention here about Test
cases, or packages.)
A use case diagram can represent different things depending on the level of the perspective that it is drawn at.
For this document, we will not focus on the organization level (shown in a business use case diagram), but we
will look at the system level use case diagram that describes the computer-based system being used, and the
chunks of functionality that are visible to the users and systems interacting with it.
System Boundary
System Name
Actor
Communication Line
Use Case
Extend
Include
Components of the system use case diagram | Using UML 2.0 (Use Case Diagrams) Page 3 of 14
Components of the system use case diagram
System Boundary
The system boundary defines the system. Everything INSIDE the system boundary will be a chunk of
functionality of the system from the perspective outside of the system (I.E use cases). Everything OUTSIDE the
system boundary will be something that interacts in some manner with your system (I.E Actors). The System
Boundary should be used in the following manner:
The system boundary should be a rectangle that all Use Cases of the system (or subsystem) reside
within.
The name of the system (or subsystem) should be displayed close to the top line of the system
boundary to make it clear what the boundary means
If the boundary is of a subsystem, it is recommended that the name be prefixed with subsystem
followed by the name. (EG: subsystem Accounts Payable)
Actors
Actors exist OUTSIDE the system boundary. They are external entities of some form that interact with your
system either directly or indirectly to execute a use case. Each Actor has a uniquely identifiable name
associated with it, and is represented in the diagram by an image (usually the stick figure shown above, but
they can be other representational images to show different systems). The only actors that should be shown
are:
A direct user of the system that DIRECTLY interacts with the system
An external actor that interacts with a user of the system (for example, a customer calling a telephone
operator to make a booking).
An external system that interacts with the system being described. (For example, your system might
interact with an external booking system or payroll system to get some information).
Time can be used as an actor in the analysis phase of the systems development lifecycle to show a
process that is initiated after a period of time or on a certain schedule. (e.g. automatically generating
and printing a weekly report, running a system backup or other operational tasks).
NOTE: As you go into a more detailed design perspective, this role represented by the time actor might
become part of the setup of the host operating system (Task Scheduler in Windows or CRON in UNIX style
systems), in the Analysis phase however, it is sufficient to show that these are time-initiated chunks of
functionality by having the TIME actor link with those particular use cases if there is no system defined as
having that role.
Components of the system use case diagram | Using UML 2.0 (Use Case Diagrams) Page 4 of 14
Use Cases
“
添加老师微信回复‘’官网 辅导‘’获取专业老师帮助，或点击联系老师1对1在线指导。
