This unit covers simple use case models, modeling users’ routines, and getting users involved.

1. Arab Open University
2nd
Semester, 2006-2007
M301
Unit 4.2
Use Cases
reem.attas@arabou.org.sa

2. Reem AlAttas © 2
Topic Road Map
 Simple use case models
More details on use case models
Modeling users’ routines
Getting users involved

3. Reem AlAttas © 3
Use Case
Who does what?

4. Reem AlAttas © 4
Purposes of Use Cases
Help with the modeling of requirements.
Help with project planning and quality
assurance.
Offer a common language for agreeing the
functions of the software system.

5. Reem AlAttas © 5
Elements
Actors.
Use Cases.
Relationships.

6. Reem AlAttas © 6
Actor
 Anything outside a software system that
interacts with it.
 Not intended to represent a particular individual,
rather they tell us about a particular role.
 Can be:
 Human User.
 Other software system or device.

7. Reem AlAttas © 7
Problem

8. Reem AlAttas © 8
Tasks
1. Make reservation.
2. Check in.
3. Check out.

9. Reem AlAttas © 9
Use Case View  who does what

10. Reem AlAttas © 10
Add Boundary & Note
Boundary
Note

11. Reem AlAttas © 11
Boundary
Conceptual line that separates what we
are interested in from the rest of the world.

12. Reem AlAttas © 12
Conditions
Pre-condition: must be true before the use
case can be carried out.
Post-condition: must be true once the use
case has been completed.

13. Reem AlAttas © 13
Hotel Example Conditions (Check In)
 Pre-condition: must hold before a room can be allocated
to a guest.
 There must be a reservation for the guest and there must be at
least one room available (of the desired type) and the guest
must be able to pay for the room.
 Post-condition: must hold after a room has been
allocated to a guest.
 The guest will have been allocated to a room for the period
identified in the reservation, the room will have been identified as
being in use for a specific period and a bill will have been
opened for the duration of the stay.

14. Reem AlAttas © 14
Scenario
Description of a sequence of actions that
illustrate a piece of interesting behavior.
Just as an object is an instance of a class,
a scenario is said to be an instance of a
use case.

15. Reem AlAttas © 15
Possible Scenarios for Making a
Reservation at a Hotel.
Jill wants to reserve a room at the Ritz
Hotel for 14 July. A room is available for
that date and so the system makes a
reservation for the guest Jill  Lead to a
successful outcome.

16. Reem AlAttas © 16
… Possible Scenarios for Making a
Reservation at a Hotel
 Jack wants to reserve a room at the Savoy Hotel
for the first week of August. There is no single
room that is free for seven days in August, but
there is one room available for four days and
another of the same type for three days. The
system presents that option to Jack, who rejects
it  There is an exception to the main success
scenario.

17. Reem AlAttas © 17
Textual Description of a Use Case

18. Reem AlAttas © 18
… Textual Description of a Use Case

19. Reem AlAttas © 19
Topic Road Map
Simple use case models
 More details on use case models
Modeling users’ routines
Getting users involved

20. Reem AlAttas © 20
More About Actors

21. Reem AlAttas © 21
Stereotypes
 A way of adding detail to a model element
(relationship).
 You can define your own term and place it
between the angle brackets << >>.
 Ex: <<communication>>
 The UML provides some stereotypes that you
cannot redefine.
 <<include>>
 <<extend>>

22. Reem AlAttas © 22
<<include>>

23. Reem AlAttas © 23
<<extend>>

24. Reem AlAttas © 24
Extension Point

25. Reem AlAttas © 25
Use Case Description

26. Reem AlAttas © 26
… Use Case Description

27. Reem AlAttas © 27
… Use Case Description

28. Reem AlAttas © 28
Comparison
<<include>>  unconditional behavior
(must be performed).
<<extend>>  conditional behavior
(performed only when the condition is
true).

29. Reem AlAttas © 29
To extend or include?

30. Reem AlAttas © 30
… To extend or include?

31. Reem AlAttas © 31
Topic Road Map
Simple use case models
More details on use case models
 Modeling users’ routines
Getting users involved

32. Reem AlAttas © 32
Activity Diagram
Used to model the coordination and
sequencing of actions in order to achieve
a given purpose and, with a simple
extension, can show which actor is
responsible for which activity.
Help you investigate the flow of control
from one activity to another.

33. Reem AlAttas © 33
Example 3.1
Suppose, after a hard day’s work, you
decide to make yourself a hot drink. What
do you do to achieve that goal? What are
the actions and how do you organize
them?

34. Reem AlAttas © 34
Activity Diagram for Making a cup of
coffee

35. Reem AlAttas © 35
Dealing with a Dirty Cup

36. Reem AlAttas © 36
Using Decision Diamonds

37. Reem AlAttas © 37
An activity Diagram for Issuing a Copy
of a Book

38. Reem AlAttas © 38
An Activity Diagram for Returning a
Copy of a Book

39. Reem AlAttas © 39
Where to Use Activity Diagrams?
More oriented towards analysis  used to
find out which activities are to be
automated.
More towards implementation  help you
to identify how each of the operations
done.

40. Reem AlAttas © 40
Topic Road Map
Simple use case models
More details on use case models
Modeling users’ routines
 Getting users involved

41. Reem AlAttas © 41
Prototyping
Used to help with the design of the user
interface for the proposed software
system.
By working closely with the users you can
minimize or avoid any misunderstanding
that may lead to false expectations by
either the developer or the users.

42. Reem AlAttas © 42
Activity Diagram for the Prototyping
Process

43. TMA4 – Q2

44. Thank You!