The document discusses use case modeling in UML. It identifies the most commonly used UML diagrams as use case diagrams, activity diagrams, sequence diagrams, class diagrams, and statechart diagrams. It then provides details on use case diagrams, including the components (actors, use cases, boundary), relationships (include, extend), and steps for creating a use case model.

1. Use Case Modeling

2. Kendall & Kendall © 2005 Pearson Prentice Hall 18-2
Commonly Used UML Diagrams
The most commonly used UML diagrams are:
– Use case diagram, describing how the system is
used.
• The starting point for UML modeling.
– Use case (not a diagram).
– Activity diagram.
• Each use case may create one activity diagram.

3. Kendall & Kendall © 2005 Pearson Prentice Hall 18-3
Commonly Used UML Diagrams
The most commonly used UML diagrams
(continued):
– Sequence diagram, showing the sequence of
activities and class relationships.
• Each use case may create one or more sequence
diagrams.
• A collaboration diagram is an alternative to a sequence
diagram.

4. Kendall & Kendall © 2005 Pearson Prentice Hall 18-4
Commonly Used UML Diagrams
The most commonly used UML diagrams
(continued):
– Class diagram, showing classes and relationships.
• Sequence diagrams and CRC cards are used to
determine classes.
– Statechart diagram.
• Each class may create a statechart diagram, useful for
determining class methods.

5. Kendall & Kendall © 2005 Pearson Prentice Hall 18-5
Overview of UML Diagrams

6. Use Cases
• Depiction of a system’s behavior or
functionality under various conditions as the
system responds to requests from users
• Full functioning for a specific business purpose

7. Kendall & Kendall © 2005 Pearson Prentice Hall 18-7
Use Case Diagram
• A use (yoos) case describes what the system does,
not how it does the work.
• The use case model reflects the view of the system of
the user outside of the system.
• Symbols are:
– Actor, a stick figure.
– Use case, an oval.
– Connecting lines.

8. UML Use Case Diagram Symbols
Use Case
Actor
Boundary
Connection
Include relationship
Extend relationship
<<include>>
<<extend>>

9. Kendall & Kendall © 2005 Pearson Prentice Hall 18-9
Actors
• Represent role played by one or more users
• Exist outside of the system
• May be a person, another system, a device, such as a
keyboard or Web connection
• Can initiate an instance of a use case
• May interact with one or more use cases and a use
case may involve one or more actors

10. Kendall & Kendall © 2005 Pearson Prentice Hall 18-10
Actors (Continued)
• Actors may be divided into two groups:
• Primary actors supply data or receive
information from the system
• Secondary actors help to keep the system
running or provide help
– Help desk, analysts, programmers, etc.

11. What is a Boundary?
• A boundary is the dividing line between the
system and its environment.
• Use cases are within the boundary.
• Actors are outside of the boundary.

12. Kendall & Kendall © 2005 Pearson Prentice Hall 18-12
Use Case
• Consists of three things:
– An actor (user) that initiates an event.
– An event that triggers a use case.
– The use case that performs the actions triggered
by the event.

13. Kendall & Kendall © 2005 Pearson Prentice Hall 18-13
Use Case (Continued)
• Better to create fewer use cases
• 20 use cases for a large system
• 50 use cases would be the maximum for a
large system
• Can nest use cases, if needed

14. What is a Connection?
• A connection is an association between an
actor and a use case.
• Depicts a usage relationship
• Connection does not indicate data flow

15. Kendall & Kendall © 2005 Pearson Prentice Hall 18-15
Use Case Relationships
• Communicates
– Connect an actor to a use case
• Includes
– Use case contains a behavior that is common to
more than one use case.
– The common use case is included in other use
cases.
– Dotted arrow points toward common use case.

16. What is an <<include>> Relationship?
• A connection between two use cases
• Indicates a use case that is used (invoked) by
another use case
• Links to general purpose functions, used by
many other use cases

17. Kendall & Kendall © 2005 Pearson Prentice Hall 18-17
Use Case Relationships (Continued)
• Extends
– A different use case handles variations or
exceptions from the basic use case.
– Arrow goes from extended to basic use case.
• Generalizes
– One thing is more general than another thing.
– Arrow points to the general thing.

18. What is an <<extend>> Relationship?
• A connection between two use cases
• Extends a use case by adding new behavior or
actions
• Specialized use case extends the general use
case

19. Kendall & Kendall © 2005 Pearson Prentice Hall 18-19
Use Case Relationships

22. Kendall & Kendall © 2005 Pearson Prentice Hall 18-22
Steps for Creating a
Use Case Model
The steps required to create a use case model
are:
– Review the business specifications and identify
the actors within the problem domain.
– Identify the high-level events and develop the
primary use cases that describe the events and
how actors initiate them.

23. Kendall & Kendall © 2005 Pearson Prentice Hall 18-23
Steps for Creating a
Use Case Model
• The steps required to create a use case model
are (continued):
– Review each primary use case to determine
possible variations of flow through the use case.
– Develop the use case documents for all primary
use cases and all important use case scenarios.