Software Engineering – Use Case Diagrams / Descriptions

UML & Use Cases

UML stands for Unified Modelling Language. They are diagrams to help aid the creation, visualisation and documentation of various aspects of the software engineering process.

For requirements, we use Use Cases. Use Cases come in pairs, so we have:

• Use Case Diagram: an overview of the system


• Use Case Description: details about each function (more later)

Actors and Use Cases

An Actor is something that performs use cases upon a system. An Actor is just an entity, meaning it can be a Human or other artefacts that directly play an external role in the system – as long as they either directly use the system or is used by the system.

For each Use Case we have to know entry conditions (preconditions) and Exit conditions (post-conditions), So basically “What is true before the Use Case” and “What is true after the Use Case”.

A use case in software engineering is a description of a system’s behavior as it responds to a request that originates from outside of that system. In other words, a use case describes "who" can do "what" with the system in question. The use case technique is used to capture a system's behavioral requirements by detailing scenario-driven threads through the functional requirements.

http://en.wikipedia.org/wiki/Use_case

Use Case Diagrams

So, lets have a quick look at what a Use Case diagram should look like:



This is a Use Case for a Library System. It is fairly identical to the one that can be found in Ian Sommerville’s book Software Engineering Edition 8, 2007, on page 156 Figure 7.7 (for those of you who want to study this a little further :) )

Here we can see that the Actors of the system are the ‘Library Users’, ‘Library Staff’ and ‘Suppliers’. And as with all Use Case Diagrams, Actors MUST be represented as stick people.

Each class of interaction for the system is represented as a named eclipse, all placed inside a box that is also named. This name is the name for the who system, eg “Library System”.

What this diagram shows is that a Library user (a member of the public) can search for articles, and then print them off using the system. A member of the Library Staff can see Catalogue services, such as where they get their books from and what they have in stock – on top of this, both Library Users and Staff have User Administration privileges.
The final actor – the Suppler, can only interact with the Catalogue Service, as they do not have user administration privileges since they only supply the books to the required Library.

Use Case Description

A Use Case description is a detailed description of for each of the classes of interaction within a given Use Case Diagram:



So as a quick example, a Use Case Description for say Article Search would be something like:

Use Case Name	Searching for an Article
Participating Actors	Library User
Flow of Events	User enters search terms System searches' articles from file System displays all articles matching terms User searches for article from given list and clicks on the one they need System displays that article to the user
Alternative Flows	2.a   System has no articles to search 2.b   System informs user and exits 3.a   System finds no articles matching users terms 3.b   System informs user and exits 4.a   User can’t find article in the list 4.b   User exits and tries more search terms
Entry Conditions	User has correct user authentication and a valid search term
Exit Conditions	User finds correct article, or user exits searching system due to article not being found