+

Use Case Diagrams

Systems Analysis and DesignMichael Heron

+Introduction

We’ve spent a lot of time looking at class diagrams over the past few weeks. This week we’re going to introduce a new diagraming

notation.

Class diagrams represent a static view of the system. They’re about the architecture of the system, how the code

relates.

Today we’re going to talk about use case diagrams. The first of our dynamic views of the system.

Use diagrams cover all the ways in which an individual may interest with our system.

+Use Case Diagrams

Use case diagrams give a very high level overview of abstract interactions with a system. We don’t care about how, we only care about what.

They allow us to have many different views of a system. We may want a view for a normal user, a super user, a

privileged user and so on.

Use-case diagrams are made up of four elements. Actors The System Itself Use-Cases Relationships between Use Cases

+A simple example

+Use-Case Diagrams

Honestly, that’s how they look. Honest.

The stick figure is the actor. An individual or group of individuals who may interact with our

system.

The box is the system. In this case, a light switch.

The use cases are the circles. Switch on and switch off.

The lines are the relationships. A person has access to the switch on and switch off use cases.

+Use Cases

You will see that there’s no relationship between individual use cases. We don’t need to worry about how they work or what use

cases they influence. The diagram doesn’t show that before they are switched off

they must be switched on. We’ll handle that later.

Use cases represent each of the distinct activities that an actor may perform within our system. They tell us then what functionality we will need to expose

to a user in order for them to meet the system requirements.

This relates to visibility as discussed earlier in the module.

+Actors

Actors need not be real people. They can also be other computer systems.

Most actors are external entities. We have no control over them or what they may choose to

do. All we have control over is what functionality our system

will expose to them.

However, we may sometimes use use-case diagrams to show relationship between internal subsystems. In this case we may have more control over how the system

works, but we still represent them as external entities.

+Another Example

+Another Example

The use case diagram doesn’t represent causality. It doesn’t show in what order things must be done.

It shows the set of actions that an actor can perform. A file server can’t request a page. A web surfer can’t send a page.

We can also provide multiple use case diagrams for different actors. In fact, we will almost certainly do this.

But wait, there’s more…

+A Third Example

+A Third Example

This diagram shows a subdivision of use cases. Flash, Press Button and Release Button are separate activities. The Take Picture use case will make use of each of these All use-cases will be used at least once during the course of the use-

case execution. Not necessarily true in our example.

In this way we can show an association between individual use case elements.

This allows us to minimise the complexity of our diagram. Limit the number of abstract actions an actor can perform.

It also allows us to reuse elements. Important when it comes to documentation of use cases.

+Representing Inheritance

+Representing Inheritance

Use Case Diagrams are part of the UML standard, and thus are Object Oriented diagrams. So we need to be able to show inheritance.

For the majority of diagrams you develop, these probably will not be necessary.

Use case diagrams are most effective when they show abstract interaction. But you have the uses and extends relationships if you

need to represent something more complex or you need to cut down in documentation duplication.

+Documenting Use Cases

The diagrams are only one aspect of a use case. The next aspect is a use case description.

This is a meaty outline (sometimes on separate cards) of what each of the activities actually mean.

They will include as part of their design a series of scenarios. Usually provided in pseudocode.

The scenarios will cover the steps taken to carry out the use-case. Separate scenarios for exceptional conditions will also be

provided.

+Use Case Documentation

General comments and notes

Requirements: what it allows the actor to accomplish.

Constraints: Rules about what can and cannot be done with the use-case. These can be broken down into: Pre-conditions Post-conditions Invariants

Scenarios that detail the steps that must be taken to carry out the use-case. May include a number of scenarios to show exceptional conditions.

Scenario diagrams that depict the processing - we haven’t covered these yet but we will in weeks to come.

Additional attributes such as a change log, version number, complexity rating, and so on.

+Example

Use Case: Deal HandRequirements: Is used to ensure every player in a game of poker has five cards in their hand.

Pre-Conditions: The deck has 52 cardsPost-Conditions: All poker players have five cardsInvariants: The sum of the number of cards in each players hand and in the remaining deck is 52.

Scenarios:

Normal flow of events:

Let numPlayers be equal to the number of players repeat five times repeat a number of times equal to numPlayers Dealer removes card from top of deck Dealer deals card face-down to player Dealer moves clockwise to next player

Player Sits Out Hand

Let numPlayers be equal to the number of players minus one repeat five times repeat a number of times equal to numPlayers if current player is sitting out hand move onto next player Dealer removes card from top of deck Dealer deals card face-down to player Dealer moves clockwise to next playerScenario Diagrams: To followAdditonal Attributes: None as of yet

+Use-Case Documentation

There is no need for scenarios to be 100% complete the first time. As part of the additional attributes, we may include a formal

change log.

However, identifying what each use-case is supposed to do helps in identifying: Scope Completeness Overlap Ambiguity

They can direct you to answer the right kinds of questions.

+Identifying Use-Cases

As with classes, identifying use cases is part of the challenge. For this we use a system called event decomposition.

This allows us to identify the events to which a system must respond and then working out how it actually responds.

We concentrate on external stimuli for this. We treat our system as a black box. We don’t know what’s going on inside it. We just know there are ‘buttons we should be able to press’

We can do this through various ways. Roleplaying, for example.

+Event Decomposition

We look at three categories of events from the perspective of each actor.

External events – ones initiated by an external entity. ‘I come along and press a button’ For this, we need to identify the set of all the actors in our

system. Who are we writing this for?

We list the entities, and then outline what we think the full set of actions they would perform might be. Trying to identify the external entities in a piece of online

retail software may introduce customers, administrators, and external web pages.

+External Events

Entity Transactions

Customer Buy BookView shopping basketMake PaymentBrowse catalogueQuery book detailsQuery Account

Web-Page Query Query book detailsBrowse catalogue

Administrator Buy BookView Shopping BasketMake PaymentBrowse CatalogueQuery Book DetailsUpdate Book DetailsUpdate Customer DetailsAdd Catalogue EntryRemove Catalogue Entry

+Temporal Events

Temporal events are those that occur as a result of reaching a particular point in time. End of the day End of the week End of the month

Most systems will do some kind of ‘batch processing’ at this point. For simplicity of logistics.

We list, in a similar style to the external events, all of the time-related events we wish to capture.

+State Events

State events are those that occur when the internal data of a system are altered to the point that system processing is required. If the stock of an item drops below a number, order more

stock. Or send a message to procurement.

Usually these kind of state events occur as a consequence of other events. A customer buys an item. This triggers the state event.

They still need to be documented separately.

+Identifying Events

As with objects and classes, identifying events is an intellectual activity. This is a technique, not a guaranteed algorithm.

You still need to decide what makes sense and at what level of detail. What constitutes a single event?

There’s no hard and fast rule.

One useful technique is to consider it based on atomicity. If any significant time passes between one event and

another, it’s two separate events.

+Conclusion

Use case diagrams are part of the dynamic view of a system. They gives us an overview of what interfaces our precious code

must expose.

They come in the form of simple stick figures and boxes. And lines.

They can represent both association and inheritance. But we don’t worry too much about those until we need them.

Identifying events is hard. And will only become easier with experience.

Event decomposition can help with this.