UML Behavioral Modeling Diagrams

Use Case diagramsJerry Myong

1

2

Use Cases

• For analysts who want to model user and system interactions.– Define behavior, requirements and constraints in the form of scripts or

scenarios.• Use Case Model

– Captures the requirements of a system.• Communicates with users and other stakeholders what the system is intended to do.

– Components• Actors - external entities are referred to as actors.

– Represent roles which may include human users, external hardware or other systems.– Usually drawn as a named stick figure, or alternatively as a class rectangle with the «actor»

keyword.

• Use cases - a single unit of meaningful work– Provides a high-level view of behavior observable to someone or something outside the system.– Notation for a use case is an ellipse.

• Uses connector - connecting line with an optional arrowhead showing the direction of control (refer to “System Boundary” diagram below)

– May have multiplicity (e.g., 0 .. 1, 0 .. *) values at each end

3

Use Cases• Use case typically includes:

– Name and description - Normally named as a verb-phrase and given a brief informal textual description.

– Requirements - Define the formal functional requirements that a use case must supply to the end user.

• Correspond to the functional specifications found in structured methodologies.• Requirement is a contract or promise that the use case will perform an action or provide some value to the system.

– Constraints - Condition / restriction that a use case operates under and includes pre and post conditions.

• Pre - Conditions that need to be met before the use case can proceed.• Post - Conditions that must be true after execution of the use case.

– Scenarios - Formal description of the flow of events that occur during the execution of a use case instance.

• Defines the specific sequence of events between the system and the external actors. Normally described in text *Corresponds to the textual representation of the sequence diagram.

– “Included” Use Case• A reference to an included use case has the following syntax:

– [condition_statement] “include” use_case_name• The included use case describes a lower-level goal (more detailed) than the base use case.• Every step in a use case is written as sentence about a goal that succeeds.

– If the goal is broken out into its own use case, then the step "calls" the sub-use case, or it "includes the behavior" of the "included" use case.

– The verb phrase part of that sentence is the name of a potential sub-use case (“Included” Use Case).

4

Use Cases

• “Extending” Use Case– A base use case can have several extension points– Each extension point has a unique name that identifies one or several

locations in the behavior sequence of the base use case

• Extension point – is where an extending use case is added– Marker in the logic of a base use case indicating where extension is

allowed» Example: “Extension points: <step #>: Use case <#> <Use case name>

– In the figure below, the name of the extension is listed in the Extension Points compartment of the base use case

5

Use Cases

• “Inherits” Use Case (realizes Generalization Relationship)In UML modeling, a generalization relationship is a relationship in which one model element (the child) is based on another model element (the parent).

– Generalization relationships are used in use case diagrams (as well as class, component, deployment diagrams)

• “Inherits” Use Case – “A generalization relationship between use cases implies that the child use case contains all the attributes, sequences of behavior and extension points defined in the parent use case, and participates in all the relationships of the parent use case”---- Writing Effective Use Cases, A. Cockburn, 1999

6

Use Cases

• Base Course of Action - “Use the ATM”• Included Use Case – “Withdraw Cash”

– An arrow goes from the base use case to the included use case, signifying that the base use case "knows about" the included one

– Use the stereotype of <<include>> on a dependency relationship– <<include>> dependency can be viewed as:

• Invocation of a use case by another one– Same idea of a function call or invoking a method

– Use <<include>> dependencies whenever one use case needs the behavior of another

7

Use Case diagrams

• Extending Use Case - “Spell Check”– Use an arrow going from the extending use case back to the

base use case• Signifies that the extending use case "knows about" the base use

case• The reverse of the "includes" relation.

8

Use Case diagrams

• Extending Use Case– Extension Points - point at which an extending use case is

added• Marker in the logic of a base use case indicating where extension is

allowed. (stereotype <<extend>> marks extension use case)

– Why use them?• Conceptually inserts additional action sequences into the base use-

case sequence• Picks up the course of behavior, and when done, deposits the actor

back at the point (extension) in the base use case that got interrupted.

• Just a scenario extension that outgrew the use case in which it was embedded.

• Alistair Cockburn recommends: “Don't use extension use cases, unless you have a really good reason. If you do use them, absolutely don't expose the extension points in the use case diagram.” ---- Writing Effective Use Cases, A. Cockburn, 1999

9

Use Case diagrams

• “Inherits” Use Case - “Do one transaction” (parent)• Inheriting use case would completely replace one or more of the scenarios

(paths) of the “parent” use case• Good test phrases for any "generalized" concept is "generic" or "some kind

of".• If you find yourself describing a generic interaction (or actor), then you have

a candidate for "generalizes”; “inheritance” principle

10

Use Case diagrams

• System Boundary - Usual to display use cases as being inside the system and actors as being outside the (ATM) system.

11

Use Case Guidelines (by Alistair Cockburn)

• Reminders

– Write something readable

• Casual, readable use cases are still useful, whereas unreadable use cases won't get read

• Work breadth-first, from lower precision to higher precision– Precision Level 1: Primary actor's name and goal– Precision Level 2: The use case brief, or the main success scenario– Precision Level 3: The extension conditions– Precision Level 4: The extension handling steps

• For each step– Show a goal succeeding– Capture the actor's intention, not the user interface details– Have an actor pass information, validate a condition, or update state– Write between-step commentary to indicate step sequencing (or lack

of)– Ask "why" to find a next-higher level goal (lower precision)

12

Use Case Guidelines (by Alistair Cockburn)

• For data descriptions:

– Precision Level 1: Data nickname

– Precision Level 2: Data fields associated with the nickname

– Precision Level 3: Field types, lengths, and validations

13

Use Case Writing Process (by Alistair Cockburn)

• Name the system scope

• Brainstorm and list the primary actors Find every human and non-human primary actor, over the life of the system

• Brainstorm and exhaustively list user goals for the system

• Select one use case to expand Consider writing a narrative to learn the material

• Write the main success scenario (MSS) Use 3 to 9 steps to meet all interests and guarantees

• Brainstorm and exhaustively list the extension conditions Include all that the system can detect and must handle

• Write the extension-handling steps Each will end back in the MSS, at a separate success exit, or in failure

• Extract complex flows to sub use cases; merge trivial sub use cases Extracting a sub use case is easy, but it adds cost to the project

• Readjust the set: Add, Subtract, Merge, as needed

14

Questions?

Use Case diagrams

15

A little Quiz!

Q1. The “Use Case Model” captures the requirements of a system, by communicating with users and other stakeholders in (choose best answer):

1. How the system is supposed to work.2. What the system will do for the users.3. What the system will do for stakeholders.4. What the system is intended to do.

Q2. In regards to <include> use cases, use <<include>> dependencies whenever one use case needs the ______ of another.

Q3. Think of an <<include>> dependency as an ________ of a use case by another one – same idea of a function call or invoking a method:

1. Inclination2. Intoxication3. Invocation4. Annihilation

Q4. In regards to <<extends>> use cases, one use case may be used to _______ the behavior of another.

Q5. In regards to “inheriting” use cases, the inheriting use case would completely _______ one or more of the courses of action of the inherited use case.

Q6. In regards to a System Boundary, it is usual to display use cases as being _______ the system and actors as being _______ the system.

Q7. An extending use case, conceptually inserts additional action ________ into the ________ use-case sequence

Q8. “Spell Check” is an example of what type of use case?

Q9. “Withdraw Cash” is an example of what type of use case?

Q10. For each use case step: Capture the actor’s __________, not the user interface details.

Q11. When writing the main success scenario (MSS), use 3 to 9 steps to meet all ________ and _________.

16

Quiz Answers!Q1. The “Use Case Model” captures the requirements of a system, by communicating with users and other stakeholders in (choose best

answer):

1. How the system is supposed to work.2. What the system will do for the users.3. What the system will do for stakeholders.4. What the system is intended to do.

Q2. In regards to <include> use cases, use <<include>> dependencies whenever one use case needs the _ behavior_ of another.

Q3. Think of an <<include>> dependency as an ________ of a use case by another one – same idea of a function call or invoking a method:

1. Inclination2. Intoxication3. Invocation 4. Annihilation

Q4. In regards to <<extends>> use cases, one use case may be used to __extend__ the behavior of another.

Q5. In regards to “inheriting” use cases, the inheriting use case would completely __ replace__ one or more of the courses of action of the inherited use case.

Q6. In regards to a System Boundary, it is usual to display use cases as being _ inside_ the system and actors as being _outside_ the system.

Q7. An extending use case, conceptually inserts additional action _sequences_ into the _base_ use-case sequence

Q8. “Spell Check” is an example of what type of use case? Extends

Q9. “Withdraw Cash” is an example of what type of use case? Inherits or Includes

Q10. For each use case step: Capture the actor’s _intention_, not the user interface details.

Q11. When writing the main success scenario (MSS), use 3 to 9 steps to meet all _interests_ and _guarantees_.