Use case model basics
Use cases describe interactions between users of
the system (called actors) and use cases (a complete functional
unit) that is offered by the system being
modelled.
A use case is normally described using a verb and
a noun. The verb identifies what is being done and the noun
identifies to what entity the verb applies to.
A definition of an actor is: Any external entity
that makes use of the system being modelled. This means that any
person, device or external system that have access to, or make use
of the information and functions present in the system being
modelled can be considered an actor.
Within use cases there are a number of
relationships that can be modelled:
-
Association. An actor has an association with a
use case. This means that the actor makes use of the functionality
inherent in the use case, or is directly affected by it by
receiving messages or information from the use
case.
-
Generalization. The generalization relationship
allows for the modelling of parent- child relationships where the
parent's behaviour is inherited by the child, but will be modified
for execution of the child.
-
Include.
Modelling the include relationship is useful when reusable
functionality needs to be modelled. An included use case's
functionality will always be executed as part of the including
(base) use case's functionality.
-
Extend.
The extend relationship allows for the modelling of optional
functionality that can be executed conditionally. The functionality
in the extending use case will not affect the execution of the base
use case.
Use case modelling provides a black box approach
to functional modelling. This is especially true in early phases of
modelling where systems are defined by exploring the functions that
will be necessary. In the early phases the emphasis is on compiling
a (as near as possible to) complete definition of functionality.
How these functions will work and how it is implemented is not
considered until much later.
Consider the following business
scenario:
A student has to compile a course schedule for a
semester. In order to do this, the student has to register for two
primary courses and four secondary courses. The faculty wants all
tasks to be automated within a system in such a way that the
students can compile their course schedules on their own by using
only the system. To this end they have tasked a business analyst to
model the business scenario for them.
To compile a use case model the business analyst
has to identify the actors and use cases involved in the system. To
start - the actors defined are the students who will register. This
also leads to the obvious functionality; that of being able to
register for a course.
In order to register for the courses the students
will need to reference a list of courses available. Such lists are
already available from an existing system: the course catalogue
system. As it does not form a part of our current system, it can be
considered an external entity and as such are modelled as an
actor.
In digging through the requirement, the business
analyst is informed that the processes for registering for primary
and secondary courses are subtly different. This necessitates the
definition of two different functions: Register primary course and
Register secondary course. Once all courses are registered the
student has to be able print out the course schedule, although this
requirement is an optional function.
A meeting with the faculty reminds the business
analyst that the system has to have the ability for students to log
in with their different user identification codes to be able to
create course schedules. This immediately highlights the
requirement for the students to be created as a user and some sort
of administrator to administer the user identifications. All use of
functions in the system must also be logged via the mechanism of an
audit trail.
Building the use case
diagram
Step one. With all of the information available identify
the actors. From the above- mentioned the following are
applicable:
-
-
Student
- primary actor to use the registration function
-
Course
catalogue system - provides information regarding the available
courses
-
Administrator - Creates user ID's for the students
in order to log in.
Step two. Identify the functions:
-
-
Register
course - primary function to allow students to register for
courses
-
Register
primary course/Register secondary course - child functions of the
above mentioned function
-
Login -
the function that allows the students to gain access to the
register course functions.
-
Register
user - a function whereby the users of the system can be
defined.
-
Create
audit trail - to log the individual interactions with the
system
-
Print
course schedule - to optionally print the course
schedule
(Note. This brings us to the conclusion that
the Administrator must be able to log in as well in order to create
the users of the system. We can handle this in two ways: The
administrator may have an association with the Login function, or a
generalized actor may be created: Registered user, who will have
common characteristics to both Student and Administrator, but each
of the specialized actors will have behaviour that is unique to
them.)
Step three. Model the relationships:
The users (actors) will use functionality (use
cases) as follows:
|
Actor
|
Use case
|
Relationship
|
|
Registered
user
|
Login
system
|
Association - The registered user will make use of
the functionality of this use case. This implies that the
Administrator role and the Student role will use this function via
the Generalization relationship with Registered
user
|
|
Student
|
Register
course
|
Association - The student is associated with the
use of this use case.
|
|
|
Print course schedule
|
There is no direct relationship visible, but the
optional use of this use case is implied through the extend
relationship. The condition under which the use case is executed is
documented under the base use case: Register
course
|
|
|
Register primary course
|
There is no direct relationship visible, but the
use of this use case is implied through the generalization
relationship. The use of this use case, follows from the concept
that the behaviour (and the use of) is inherited from the parent
use case (Register course).
|
|
|
Register secondary course
|
See
previous.
|
|
|
Create audit
trail
|
There is no direct relationship visible, but the
use of this use case is implied through the include
relationship.
|
|
Course catalogue
system
|
Register
course
|
The course catalogue system provides information
to the use case and as such is associated to the use case: Register
course. The Generalization relationship to Register primary course
and Register secondary course implies that the course catalogue
system is referenced by these uses cases.
|
|
Administrator
|
Register
user
|
Association - The Administrator is associated with
the use of this use case.
|
The resulting diagram will look something like
this:
