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:
