The use case diagram
 
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:  
graphic
Google
 
Web xpdian.com