1. Use Case Diagrams Contents
- History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization Extends - not part of curriculum
Say something about: there is much text – consentrate on highlights – all the text is meant to make the slides readable whitout me!

2. Grady Booch et al. use case-based analysis:
Use Cases Were Introduced by Ivar Jacobson in the Beginning of the 1990s.
“A use case is a specific way of using the system by performing some part of the functionality. Each use case constitutes a complete course of events initiated by an actor, and it specifies the interaction that takes place between an actor and the system…... The collected use cases specify all the existing ways of using the system.”
Grady Booch et al. use case-based analysis:
If you design a new house and you are reasoning about how you and your family will use it, this is use case-based analysis. You consider the various ways in which you‘ll use the house, and these use cases drive the design afterwards.
Each use case constitutes a complete course of events initiated by an actor
= Each use case is a complete series of events, from the point of view of the actor

3. Use Case Diagrams Contents
History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization
- Extends - not part of curriculum

4. Use Case Diagram - a Part of UML
Use case diagrams are often drawn in collaboration with users of the system. In essence use case diagrams will show, from an external point of view, how the system will be used by the various users - how the dialog between users and the system will be.
Use case diagrams are often the kind of diagrams one starts out with, they may be part of the requirements modeling. Users of the system can easily identify with the diagrams, after all the diagrams identify interactions that users have with the system when they wants to achieve some goal. If use cases are used extensively they can drive the whole development process.
So the focus is: What functionality is involved and who will ask for the provided services. How the services are carried technically out by the system is not addressed.
With users we don’t necessarily mean humans, external systems which interacts with the system under consideration will also be modeled as a user (actor).

5. Purpose of Use Cases
Capture the functional requirements of a system (what a system is supposed to do).
Validating systems, a correct design allows all use cases to be carried out (each use case is realized). Drive implementation and generate test cases.
Specify the context of a system.

6. Use Cases and Requirements
A use case describes a unit of behavior.
A functional requirement describes a law that governs behavior.
A use case can satisfy one or more functional requirements.
A functional requirement may be satisfied by one or more use cases.
skip

7. Use Case Driven Development
The focus will be on the user requirements (the use cases).
The use cases are the most important aspect of the design process.
Use cases are used through the whole development process, to track changes and define iterations.
Some see the examination of use cases as the main method of finding classes and objects in the system, other recommend an approach where use cases and conceptual class diagrams are developed in parallel.
skip

8. Some Possible Problems
Use cases are not inherently object oriented, so we can end up with a non-object-oriented system.
We might mistake design for requirements, e.g. specifying a sequence of interactions which in fact is only one of many sequence candidate to achieve the goal .

9. Use Case Refinement and Some Limitations
It is possible to work top down, first specifying use cases at a high level and then proceed with more elaborated use case diagrams (use case refinement).
Some limitations:
The interactions between objects inside the system are not modeled.
You can not model concurrency.

10. Use Case Diagrams Contents
- History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization Extends - not part of curriculum

11. Graphical Notation
An actor is a user role, a kind of stereotype. The actor is symbolized with a “stick man” figure with the name of the actor below the figure.
A use case is shown as an ellipse, with a name inside identifying the use case.
When an actor is involved in a use case, a line is drawn from the actor to the use case. We say that the actor communicates with the use case. Who is initiating the communication can be indicated by an arrowhead.
actor
use case
actor
use case
The actor initiate the communication.
actor
use case
The use case initiate the communication.
skip
Both actor and use case can initiate the communication.

12. Use Case Examples System Boundary register as student
adm
register for course
student
register for exam
instructor
works with course
lab
Say something about who initate the use case – arrow…
make/edit course
lecturer
System Boundary

13. Use Case Scenario
A use case is similar to a class, it represent a set of possible interactions (a pattern, use case type).
Different flows of events (scenarios) might be possible! A scenario is one possible interaction between the system an some actor(s).
A scenario can be seen as an instance of a use case, in the same way as an object is seen as an instance of a class.
Even if the scenarios are different for a use case, they all attempt to solve the same task!

14. The Actor
[2] ”The total set of actors within a use case model reflects everything that needs to exchange information with the system.”
Actors are external to the system.

15. [1] Time as an Actor
[1] ”When you need to model things that happens to your system at a specific point in time but which don’t seem to be triggered by any actor, you can introduce an actor called Time... An example of this would be an automatic system backup that runs every evening.”
Time

16. Actors and Class
It is common to have a class representing a special type of actors (e.g. Student) inside the system.
If you have a class representing a set of actors, you can mark this class with the stereotype ”actor”.
«actor»
Student

17. System Boundary
With the help of use cases system boundary can be defined.
This is particular useful if you have a complex system and split it up into sub system. Specifying the boundaries of each subsystem can make the separation between the subsystem clear.
Skip

18. From the UML 2.0 Specification
Subsystems

19. A Use Case Is Often Described in Clear Text - But There are no UML Standard for Use Case Specification
Example: Student register for course
Flow of events: The use case starts when the student brows the course register page, inserts the student card in the card reader and issues the right pin code. The system presents all possible courses for this student. The student select course and commits the entry by pressing the Enter button.
Alternative flow: The student can cancel a registration by pressing the Cancel button.

20. Some have: -(main) flow -alternative flow -exceptional flow flow
fail M4
1A2
2A1 M5
2A2 M6
Others have only main and alternative flow: ”An alternate course of action can represent an infrequently used path through the scenario, an exception, or an error condition.”

21. Use Case Diagrams Contents
History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization
- Extends - not part of curriculum

22. “Use Case Form” from Together (Together is a modeling tool)

23. The Use Case Text can also be given in a note

24. How To State A Use Case [2]
”A use case is most effectively stated from the perspective of the user as a present-tense verb phrase in active voice, that are precise and clear.”
”When it comes to writing text for use cases, expansive is much preferable to terse.”
[1]: <number> The <something> <some action>
E.g. ….
5. The ReservationMaker provides name, … 6. The System makes reservation and allocates tag to reservation. ….

25. Use Cases As Given in [1] Use case modeling proceeds as follows:
find the system boundary
find the actors
find use cases
The number of use cases can be limited by allowing branching and repetition:
if-statement and if-else-statement
for-loop and while-loop
(Instead of branching (if the use cases is complex) one can have a primary use case scenario and several secondary scenarios!)

26. Use Cases As Given in [1] continues...
A Use Case Specification
Use Case: <use case id>
Actors:
<actor 1>
<actor 2>
Preconditions:
1. <first precondition>
Flow of event:
1. <frist step>
Postcondition:
1. <first postcondition>
Alternative flow:
1. <first step>
The actors involved
in the use case
The system state before
the use case can begin
The sequence of declarative, time-ordered steps in the use case.
The system state when
the use case is over
The alternative flow can be used to capture branches that can occur at any point in the flow

27. Example: Make Quiz Logon to system as QuizMaker User Make quiz
Update quiz
«becomes»
Navigate
repository
Delete quiz
«include»
«include»
«include»
«include»
Make question
Edit quiz repository
«include»
«include»
Update question
QuizMaker
«include»
Add predefined
answer alternative
«include»
«include»
Delete question
«include»
«include»
Add predefined question
Make answer alternative
«include»
Update answer alternative
Delete answer alternative

28. GUI: View/Edit/Create Quiz
Make Quiz – example continues...
GUI: View/Edit/Create Quiz
editable text field
button
Browse Quizzes
Quiz
Quiz Name:
IKT413 Test
new
update
delete
Browse Selected
Questions
Question Text
What is UML an abbreviation for?
new
update
add predefined question
delete
Browse Selected Answer Alternatives
Answer Alternative Text
Correct- ness
Undefined Modeling Language
new
update
add predefined answer alternative
delete

29. Simplified PIM for Quiz-system
Quizzee
0..*
0..*
QuizResult
- id : String
- date : Date
0..* 1 1
Quiz
<<concept>>
id : String
creationDate : Date
Simplified PIM for Quiz-system
0..*
0..*
0..*
0..*
Question
Answer
- creationDate : Date
0..*
0..*
Correctness
0..*
0..*
- value : double
AnswerAlternative
+chosen
0..*

30. Use Case: Logon to system as QuizMaker
Make Quiz – example continues...
Use Case: Logon to system as QuizMaker
Actors:
User which becomes QuizMaker
Precondition:
1. User has started the application that lets you define quizzes
Flow of events:
1. while User has not supplied valid <user name> and <password> User supplies <user name> and <password> if <user name> or <password> not valid then
System gives message <“user name or password incorrect”>
1.3. else
System displays “View/Edit/Create Quiz”-dialog window System load first quiz in repository to dialog window
System gives ok notification to QuizMaker
Postcondition:
1. The user has been logged onto the system as QuizMaker or the application has exited.
Alternative flow:
1. The User can cancel the operation at any time - in which case the application exits.

31. Use Case: Navigate repository
Make Quiz – example continues...
Use Case: Navigate repository
Actors:
QuizMaker
Precondition:
1. System has displayed “View/Edit/Create Quiz”-dialog window
Flow of events:
1. The QuizMaker presses one of the following button: <first quiz>, <next quiz>, <previous quiz> and <last quiz>
2. The system loads the quiz which the QuizMaker navigated to.
Postcondition:
Alternative flow:
1. The quiz repository is empty – in which case the <quiz name>-field is left blank.

32. Use Case: Make Quiz QuizMaker
Actors:
QuizMaker
Precondition:
QuizMaker has supplied <quiz name> and selected <quiz new>
Flow of events:
1. if <quiz name> already used then
1.1. System gives message <“in use”> to QuizMaker
2. else
2.1 System gives ok notification to QuizMaker
Postcondition:
1. There is a quiz called <quiz name> in the <quiz repository>
Alternative flow:

33. Use Case Diagrams Contents
- History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization Extends - not part of curriculum

34. Relationships Between Use Cases
There are at least three types of relationships:
Include
Generalization
extends
precedes
Use of these features will typically make a use case diagram more complex to read, so they should be used with caution.

35. Stereotypes in UML
Extends and includes is represented with dependency arrow. The dependency arrow is already used, because of this extends and include must be stereotypes. In UML stereotype names are included in << and >>.
The following definition can be found in “UML Notation Guide” from Rational Software: “A stereotype is, in effect, a new class of modeling element that is introduced at modeling time. It represents a subclass of an existing modeling element with the same form (attributes and relationships) but with a different intent.”

36. Use Case Diagrams Contents
History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization
- Extends - not part of curriculum

37. Include
Validate student
Register for course
«include»
base
The include relationship indicates that the base use case incorporates the behavior of the other use case.
The base use case is dependent of the included use case but not the opposite way.
Functionality shared between two use cases can in this way be extracted out and described in a separate use case.

38. Specifying an Inclusion Point
Use Case: Student register for course
Actors:
Student
Precondition:
1. The Student has browsed to the course register page
Flow of events:
1. The Student write <user name> and <password>.
2. include( Validate student )
3. The System presents all possible courses for this student.
4. The Student select course and commits the entry by pressing the <Enter>- button.
Postcondition:
Alternative flow:

39. More On Include
Include is used to define functionality that is common to several use cases, a modularization technique.
If we see that a component can be used, we can model this by a separate use case describing the component.
A scenario that is an instance of the base use case will typically contain a sub scenario from the included one.
Skip

40. Use Case Diagrams Contents
- History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization Extends - not part of curriculum

41. Validate student with pin code
Generalization
Validate student
Validate student with pin code
parent
child
The generalization relationship indicates that the child will inherits the behavior and meaning from the parent use case. The child can alter or/and extend the behavior of the parent, but it should be possible to substitute the child for the parent every place the parent is used.
Typically much of the use case text of the parent is repeated for the child – and then modified or extended.

42. Use Case Diagrams Contents
- History - The Role of Use Cases - Graphical Notation - Use case scenario Actor System Boundary - Use Case Text - One Use Case Approach - Use Case relations Include Generalization Extends - not part of curriculum

43. Extend
If a use case incorporates two or more clearly different scenarios (i.e., the two scenarios are quite similar except for a section that is different) – and some condition dictates which - this can be modeled by an extend relation.
So the extend relationship can be used to model behavior that the user sees as optional or as an exception on normal behavior. The base use case can incorporate the extended behavior under certain conditions otherwise stand alone.
Comment to point one: The two scenarios are joined to one use case and the section that differs is put in a use case that extends it!

44. Issue Diploma Extension points <exams not completed>
Extend - The Notation
Condition: {exams not complete}
Extension point: exams not completed
Issue Diploma Extension points <exams not completed>
Issue Incomplete
Diploma
«extend»
base
exception
You should specify:
The condition under which the extended use case applies
At which point the condition is tested and the behavior may diverge; this point is called the extension point.

45. Specifying an Extension Point
Use Case: Issue Diploma
Actors:
Admin
Precondition:
Flow of events:
1. Admin enter student name.
2. <exams not completed> The system produces a diploma
Postcondition:
Alternative flow:
Use Case: Issue Incomplete Diploma
Actors:
Admin
Precondition: 1. The student has been selected
2. Some exams are missing
Flow of events:
1. The system produces an incomplete diploma
Postcondition:
Alternative flow:

46. Use Case from Booch et al.
Place order Extension points
set priority
Place
rush order
«extend»
Condition: {rush order}
Extension point: set priority
«include»
Track
order
«include»
Validate
user
Check
password

47. UML 2.0
Extend
This relationship specifies that the behavior of a use case may be augmented by an additional use case. The extension takes place at one or more specific extension points defined in the extended use case. Note, however, that the extended use case is defined independently of the extending use case. Use case extension is intended to be used when there is some additional behavior that should be added, conditionally, to the behavior defined in another use case (which is meaningful independently of the extending use case)....
Semantics If the condition of the extension is true at the time the first extension point is reached during the execution of the extended use case, then all of the appropriate behavior fragments of the extending use case will also be executed. If the condition is false, the extension does not occur. The individual fragments are executed as the corresponding extension points of the extending use case are reached. Once a given fragment is completed, execution continues with the behavior of the extended use case following the extension point. Note that even though there are multiple use cases involved, there is just a single behavior execution.
skip

48. Extend and Generalization
This relations are very similar, some claim that UML would be better off with only one of them!
How to select one of them:
Extend: If you wants to describe extra behavior that is to be used under certain condition; a condition that is tested at run time.
Generalization: If you have a specialization of a whole use case.

49. Another relationship between use cases
[2]”You use precedes to indicate that one use case precedes another within a logical sequence.”
«precedes»
Buyer
logon
Issue Diploma

50. References
[1] Jim Arlow and Ila Neustadt: UML and The Unified Process, 2002, Addison-Wesley
[2] Doug Rosenberg and Kendall Scott: Use Case Driven Object Modeling with UML: A Practical Approach, Addison-Wesley
- Ivar Jacobson: Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1994
- Martin Fowler with Kendall Scott: UML Distilled. Addison-Wesley, 1997
- Grady Booch, James Rumbaugh, Ivar Jacobson: The Unified Modeling Language User Guide.Addison-Wesley, 1999
- Terry Quatrani: Visual Modeling with Rational Rose and UML. Addison-Wesley, 1998
- Daniel Tkach, Walter Fang and Andrew So: Visual Modeling Technique, 1996
- Alistair Cockburn’s Web:
- Rational software:
- Alistair Cockburn: