This is a lecture on Systems Analysis and design. It focuses on use case diagrams.

1. +
Use Case Diagrams
Systems Analysis and Design
Michael Heron

2. +
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.

3. +
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

4. +
A simple example

5. +
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.

6. +
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.

7. +
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.

8. +
Another Example

9. +
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…

10. +
A Third Example

11. +
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.

12. +
Representing Inheritance

13. +
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.

14. +
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.

15. +
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.

16. +
Example
Use Case: Deal Hand
Requirements: Is used to ensure every player in a game of poker has five cards in their hand.
Pre-Conditions: The deck has 52 cards
Post-Conditions: All poker players have five cards
Invariants: 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 player
Scenario Diagrams: To follow
Additonal Attributes: None as of yet

17. +
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.

18. +
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.

19. +
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.

20. +
External Events
Entity Transactions
Customer Buy Book
View shopping basket
Make Payment
Browse catalogue
Query book details
Query Account
Web-Page Query Query book details
Browse catalogue
Administrator Buy Book
View Shopping Basket
Make Payment
Browse Catalogue
Query Book Details
Update Book Details
Update Customer Details
Add Catalogue Entry
Remove Catalogue Entry

21. +
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.

22. +
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.

23. +
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.

24. +
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.