17spm_L05
Detailing Use Cases
SPM 2017 © Ron Poet Lecture 5 1
Detailing Use Cases
� The use case diagram provides a useful overview of the system
functionality and has helped us to refine the project description and
understand the system boundary.
� The next step is to go into more detail for each use case.
� We will learn more about the system functionality and be in a position
SPM 2017 © Ron Poet Lecture 5 2
� We will learn more about the system functionality and be in a position
where we can start to design the system.
� The most important details that we want to discover are the flow of
events.
Scenarios
� A scenario is a single example of a use case being used.
� The scenario will use actual sample data, rather than general terms.
o Do not say assign a teacher to a duty
o Do say “Assign Ron to the Tuesday 3-5 level 1 lab.”
SPM 2017 © Ron Poet Lecture 5 3
o
� There will be many different scenarios, describing different ways that
the use case can go.
� The different scenarios can have different outcomes.
� One aim of the requirements gathering phase is to try and list all
possible scenarios for each use case.
Alternatives
� A scenario cannot have any if statements, but the use case, which is the
combination of all the scenarios, probably will.
� The “Request Teachers” scenario can lead to a successful request
being made.
� Alternatively, the class director may make mistakes in the details,
SPM 2017 © Ron Poet Lecture 5 4
� Alternatively, the class director may make mistakes in the details,
which can be verified by our system, leading to alternate scenarios.
The Primary Scenario
� There will be one main scenario where everything goes right. This is
the reason why the use case was generated.
� This is often called the “happy day” scenario.
� Secondary scenarios often involve exceptional circumstances, such as
requesting teaching for a Sunday Lab.
SPM 2017 © Ron Poet Lecture 5 5
requesting teaching for a Sunday Lab.
� It is not always necessary to write up every secondary scenario in
detail.
o Complicated secondary scenarios do need to be detailed.
o But we do not want to write the whole of the system in English
first before programming it later.
� It is often sufficient to list the names of all the secondary scenarios.
Request Teachers Secondary Scenarios
� Class does not exist
o Option to create the class
� Class does not have a lab
o Option to create the lab
SPM 2017 © Ron Poet Lecture 5 6
o
� Suggested teacher not in the system.
o Option to add teacher to the system
Flow of Events
� There are several different styles for writing the flow of events. The
most common are
o Informal text.
o Numbered steps.
SPM 2017 © Ron Poet Lecture 5 7
o Activity diagrams.
� Here are the use cases for the some of the PTT example, written in the
numbered steps style.
Request Teachers Primary Scenario
� Rob accesses the system and brings up class 1.
� He enters the lab for Tuesday 10-12 in semester 1.
� He enters the need for a tutor and an undergraduate demonstrator.
� He enters the Lab for Wednesday 3-5 in semester 1.
SPM 2017 © Ron Poet Lecture 5 8
� He enters the need for a tutor and an undergraduate demonstrator.
� He suggests Jeremy as the tutor for this lab.
Request Teachers Flow of Events
1. For each lab associated with the class, enter class and lab name, day
and time and weeks during which it will run.
2. Enter skills level required for each person. A lab may be staffed by
more than one person. Skills levels are tutor, graduate demonstrator,
undergraduate demonstrator.
SPM 2017 © Ron Poet Lecture 5 9
undergraduate demonstrator.
3. Enter suggested teachers, to help the recruiter.
4. Notify PTT Director.
Alternatives in the Numbered List Style
� Alternatives can be indicated using if statements.
o If the class does not exist then
o a) Create the class.
� Repetition can be indicated using for or while statements.
o For each lab
SPM 2017 © Ron Poet Lecture 5 10
o For each lab
o A) Enter lab name, day and time.
o B) While more suggestions to make
o Suggest a teacher
o end
o end
� Don’t get carried away and provide too much detail at this stage.
o It is not worth trying to code everything during requirements gathering.
Activity Diagrams
� Activity diagrams are an alternative way of showing the logical
structure of the use case details.
� They are useful with more complex use cases and provide a graphical
way of detailing the algorithm.
� They are not good at showing repetition.
SPM 2017 © Ron Poet Lecture 5 11
� They are not good at showing repetition.
� Components of an activity diagram are
o Activities: rounded rectangle
o Decisions: diamond
o Guards on decisions (if statements): text inside []
o Fork initiating parallel activity: solid bar
o Join terminating parallel activity: solid bar
o Start: solid circle, Stop: donut
Coffee Break Activity Diagram
Find
Beverage
[found coffee]
[no coffee]
[found cola]
[no
cola]
SPM 2017 © Ron Poet Lecture 5 12
Put coffee
in filter
Add
water
Get
Cups
Brew
Coffee
Get Can
of Cola
[found cola]
Drink
Beverage
Request Teachers Activity Diagram
More Labs?
Enter Lab
Details
Notify PTT
Director
[Yes]
[No]
SPM 2017 © Ron Poet Lecture 5 13
Suggest
Teacher
Enter Teacher
Details
Details
[No]
[suggestion]
[No]
[more
teachers]
Pre and Post Conditions
� We may occasionally find it useful to record the state of the system
before a use case starts and also the state when it has finished.
� The use case will then have a precondition and a postcondition.
� A precondition is a brief description of the state of the system just
before the use case starts.
SPM 2017 © Ron Poet Lecture 5 14
before the use case starts.
� Similarly, a postcondition is the state of the system after the use case
has finished.
� If we look at the “Request Teachers” use case, then
o The precondition is that the class director has logged on to the
system
o The post condition is that a valid request for teachers has been
recorded by our system.
Usefulness of Pre and Post Conditions
� The use case code can check that the preconditions have been satisfied
before carrying on.
� The code will then guarantee that the postconditions are met.
� We can link pre and post conditions by making sure that the use cases
are done in the right order.are done in the right order.
� We can then prove that our system does what it is expected to do.
� Proof by induction
o The preconditions are always true.
o Therefore the postconditions, the preconditions for the next step,
are also true.
o Provided the initial state is correct.
SPM 2017 © Ron Poet Lecture 5 15
Rationale
� Each use case should have a rationale, the reason for the use case.
� Also a short English description of what it does.
� The rational for the request Teachers use case is:
The class director records all the labs that he plans to run and
SPM 2017 © Ron Poet Lecture 5 16
the staff he would like to employ. This will allow the PTT director
to either give permission for the labs to go ahead or else refuse
permission.
It is envisaged that informal discussions will have taken place
before this request, but entering the request into the system allows
the PTT director to use the system to calculate the cost of the labs.
Internal Use Cases
� Many different use cases can have similar functionality.
� This can be represented by an internal ‘use case’
o Several user facing use cases can include a common use case.
� A use case might be quite complicated.
o Specialised functionality can be represented by an internal use case
that extends the original use case.
� In both these cases we are starting to think about how we can design
the system.
o These internal use cases are usually discovered during the
requirements gathering phase.
o It is useful to record them at this time.
SPM 2017 © Ron Poet Lecture 5 17
Include Relationship
� One use case can use another with a <
o The arrow goes towards the included use case.
� Several use cases can use Find Teacher
SPM 2017 © Ron Poet Lecture 5 18
� Cancel Assignment
1. The administrator selects the class and lab.
2. The administrator selects the teacher involved using Find Teacher.
3. The teacher’s assignment is cancelled.
4. Confirm and Exit.
Include Relationship (2)
<
SPM 2017 © Ron Poet Lecture 5 19
Cancel Assignment Find Teacher
<
Extending Use Cases
� One use case extends another if it has a special case with additional
steps.
� The additional steps extend the original use case.
� A common path is initially followed in both use cases, but the flow of
control then diverges, to rejoin later on.
SPM 2017 © Ron Poet Lecture 5 20
control then diverges, to rejoin later on.
� Normally one path is the main stream and the other is the extension.
� The main use case has the common initial steps and also mentions an
extension point (or more than one), where branching can take place.
o The extension point is just a string.
Extending Use Cases (2)
� The extension use case is connected to the main one by an
<
o The arrow points towards the main use case.
o It only includes the extra steps that take place after the extension
use case diverges from the main one.
SPM 2017 © Ron Poet Lecture 5 21
use case diverges from the main one.
o Flow of control must also mention the extension point that it uses.
o The extension use case details must also start with a conditional
statement, the condition for taking the extended path.
o Inside []
Example: Cancel Assignment
1. The administrator selects the class and lab.
2. The administrator selects the teacher involved.
3. The teacher’s assignment is cancelled.
Add Replacement Extension Point.
SPM 2017 © Ron Poet Lecture 5 22
4. Confirm and Exit.
Example: Add Replacement
� [ If another teacher has agreed to cover this assignment ]
� Add Replacement Extension Point.
1. The administrator selects the teacher.
2. The teacher is assigned to the class and lab.
SPM 2017 © Ron Poet Lecture 5 23
Cancel Assignment
Add Replacement
<
Actor Inheritance
� It is possible for two actors to be very similar, but have significant
differences as well.
� This shows up on the use case diagram.
� We can simplify the diagram by saying that one actor inherits from
another actor.
SPM 2017 © Ron Poet Lecture 5 24
another actor.
� We can add another actor: Administrator.
o PTT Director and Payer both inherit from Administrator.
o They are both special cases of Administrator.
o They are an Administrator + extra functionality.
� This is represented by arrows connecting PTT Director and Payer to
Administrator.
Actor Inheritance (2)
Administrator
Enter New
Teacher
SPM 2017 © Ron Poet Lecture 5 25
PTT Director
Assign
Teacher
Check Budget
Detailed Use Case Description Document
� This is the structure I would like for the Use Case Details document
that you will hand in as part of assessed exercise 1.
� One per use case.
� Not all sections are needed for every use case.
SPM 2017 © Ron Poet Lecture 5 26
o Just fill in the sections that you think are applicable.
o Some of the marks are for judging what is important.
� Rationale
o The reasoning behind the need for this use case.
� Actors
o A list of actors who communicate with this use case.
Use Case Document (2)
� Priority
o The importance of this use case to the project.
� Status
o Where are we in developing this use case.
SPM 2017 © Ron Poet Lecture 5 27
o
o How certain are we that it is correct and complete.
� Preconditions
o Assumptions made.
� Postconditions
o The state the system will be left in.
� Extension Points and Included Use Cases.
Use Case Document (3)
� Flow of Events
o Either a numbered list or an activity diagram.
o Both could be included if that would improve clarity.
� User Interface
SPM 2017 © Ron Poet Lecture 5 28
o If the use case interacts with people then include a description of
the user interface, possibly using wire frames and story boards.
� Scenarios
o A list of scenarios used, together with a brief description of what
each does.
� Other Requirements
o Non functional requirements that impact on this use case.