UML
Course Content Specification
Describe, exemplify, and implement Unified Modelling Language (UML):
Use case diagrams
Actors
Use cases
Relationships
What is UML?
Unified Modelling Language is a notation of symbols and diagrams to communicate object-oriented analysis and design.
It also documents the construction of a software system, including the business model, where the dynamic behaviour is represented.
Burdett, Arnold. BCS Glossary of Computing . BCS Learning & Development Limited. Kindle Edition.
Types of UML Diagrams At Advanced Higher
There are many different applications of UML diagrams but we will only be looking at two, they are:
Use case diagram shows the functionality of the system from the users’ perspective and is essentially non-technical.
Class diagrams show a class represented by a rectangle labelled by its name, attributes and operations. Classes may be associated similar to entity relationships. (These will be covered in the Object Oriented Programming Pages)
Burdett, Arnold. BCS Glossary of Computing . BCS Learning & Development Limited. Kindle Edition.
Use Case Diagrams
Use case diagrams are a means for specifying required usages of a system. Typically, they are used to capture the requirements of a system
Source: http://www.omg.org/spec/
This diagram is useful for representing the system from a users’ perspective, they:
Are used to gather the requirements of the system
Are used to get an outside view of the system
Identify the internal and external actors in a system
Show the interaction among the requirements of the system
Aid communication between the client and the developer
Components of a Use Case Diagram
We will focus on 4 main components to a Use Case Diagram
A System (System Boundary)
Actors
Use Cases
Relationships
UML - System/System Boundary
The system is used to define the scope of the use case and drawn as a rectangle. This an optional element but useful when visualising large systems. The system boundary represents the limits of the system being developed: only those actors and processes to be considered are illustrated within the system boundary.
UML - Actors
An actor interacts with the system being developed.
The actor may be a human or an entity that interacts with the system, for example another system or server, and is external to the system being developed.
An actor can be:
Primary
Secondary
Primary and Secondary Actors
A primary actor uses the system to achieve a goal. The Use Case documents the interactions between the system and the actors to achieve the goal of the primary actor. For example a customer buying an item.
A secondary actor is one that the system needs assistance from to achieve the primary actor’s goal. For example a cashier in a bank
Examples of different types of actors
A UML case diagram shows an actor by using the symbol:
The following are examples of actors, depending on the problem being solved.
Different types of actors that can be in a UML diagram
UML - Use Cases
A use case describes an action (process) or a sequence of actions (processes) that must be in the system being developed. They are represented using ellipses. These help to determine the requirements of the system under consideration, by describing the functionality that the system will provide.
A process may be initiated by an actor or may be started by the system itself, providing a useful result to an actor.
UML - Relationships
A use case diagram can have five types of relationship:
Association between an actor and a use case
Generalisation of an actor
Extension between two use cases
Include between two use cases
Generalisation of a use case
Each actor must be associated with at least one use case ( although can be connected with multiple use cases
Likewise a use case must be associated with at least one use case
An association is represented by a line with no arrowheads between the actor and use case
Generalisation
Generalisation of an actor means one actor can inherit the role of another actor. The descendant actor inherits all the use cases of the ancestor.
This means they would not need to be duplicated
A line, with a single solid arrowhead pointing at the ancestor actor, connects a descendant actor to the ancestor actor.
Extending between two use cases
Extending a basic use case provides additional functionality to the system.
An extended use case is connected to a basic use case using a dashed line, with a single solid arrowhead pointing at the basic use case. The label <<extend>> is placed on the line.
Extend indicates a conditional use case. So in the diagram above the Credit Card Payment use case may lead to the Calculate Interest use case.
Include between two use cases
An included use case is part of the basic use case. It is a mandatory process, as the basic use case is incomplete without it.
An included use case is connected to the basic use case using a dashed line with a single solid arrowhead, pointing at the common basic use case. The label <<include>> is placed on the line.
Generalisation of a use case
This is similar to generalisation of an actor.
A line, with a single solid arrowhead pointing at the ancestor use case, connects a descendant use case to the ancestor use case.
Creating a Use case Diagram (Scenario - Exam Type Question)
The owners of a monthly magazine decide to update the company website. The current website allows users to access online versions of articles printed in the monthly magazines. Requirements for the updated website are listed below.
The updated website will allow all users to:
access a maximum of five free articles every month
search for articles over 12 months old
subscribe to the full service using a secure payment system
The updated website will allow subscribed users to:
login to gain access to the full service
access any number of articles
search for articles without restriction
renew their subscription at a reduced rate using a secure payment system
Example Output
