Object-Oriented Modeling Using UML

1
Object-Oriented ModelingUsing UML

• CS 3331
• Section 2.4 Modeling Requirements with Use Cases

2
Outline

• Intro. to UML
• Use cases and use case diagrams
• Use case scenarios
• Case study

3
Unified Modeling Language (UML)

• Notation for object-oriented modeling
• Standardized by Object Management Group (OMG)
• Consists of 12 different diagrams
• Use case diagram
• Class diagram
• State machine diagram
• Sequence diagram
• Activity diagram
• Deployment diagram
• Q Why so many different diagrams?

4
Modeling Requirements

• Whatre requirements?
• Requirements vs. design
• How to describe requirements?

5
Describing Requirements

• One way to describe a system is to create a
  story, the interaction between a user and the
  system.
• This story should be just one path through the
  system, start to finish, that a user will want to
  take.
• E.g., ATM

6
Use Cases

• A use case defines a sequence of actions
  performed by a system that yields an observable
  result of value to a user (called an actor).
• Characteristics
• A use case is typically initiated by an actor.
• A use case provides value to an actor.
• A use case is complete.

7
Documenting Use Cases

• Use case diagrams, consisting of
• system
• actors
• use cases

system boundary
Goldmine
actor
use case
8
Elements of Use Case Diagram

• Actor
• Represents a role played by external entities
  that interact with the system
• Use case
• Describes what the system does (i.e.,
  functionality)
• Interaction between an actor and the system
• Relationship
• Extension (or generalization) among actors
• Association between actors and use cases
• Dependency among use cases include, extend, and
  generalization

9
Example Goldmine
Goldmine
ltltincludegtgt
ltltincludegtgt
ltltextendgtgt
10
Relationships between Use Cases

• Include dependency
• Always initiated (idea similar to method call)
• Explicitly stated in including use case
• Extend dependency
• Conditionally initiated (similar to callback or
  exception handling)
• Implicitly (or not) stated in extended use case
• Generalization
• Similar to subclassing (generalization/specializat
  ion)

11
Guidelines

• Identify actors
• Roles played by external entities that interact
  with the system (humans, machines or other
  systems)
• Importance define the boundary of the system
• Identify uses cases by asking for each actor
• Tasks, data, events, etc. it wants to perform,
• Identify relationships between/among
• Actors and use cases
• Use cases
• Actors

12
Exercise (5 minutes)

• Form a pair
• Draw a use case diagram for the Connect Four game
  by identifying
• Actors
• System boundary
• Use cases

13
Use Cases Revisited

• How to describe a use case itself?
• A scenario is a sequence of steps describing an
  interaction between a user and a system.
• The customer browses the catalog and adds
  desired items to the shopping basket. When the
  customer wishes to pay, the customer describes
  the shipping and credit card information and
  confirms the sale. The system checks the
  authorization on the credit card and confirms the
  sale both immediately and with a follow-up email.
• What if the credit card authorization fails? A
  separate scenario!

14
Use Cases (Cont.)

• A use case is a set of scenarios tied together by
  a common user goal (e.g., success and failure
  together, and other alternative paths).
• A use case can be documented by describing all
  its scenarios.

15
Use Case Scenarios
16
Guidelines

• Identify a main success scenario (MSS)
• Assume that every thing goes well, i.e., no
  exceptions and no errors.
• Write each step of the scenario, from start to
  end.
• Check each step of the MSS to identify
• Alternatives, exceptions, and error cases
• If significant, introduce new (secondary)
  scenarios for them.
• Merge the MSS and alternatives/exceptions into a
  single coherent description.
• Avoid design/implementation dependent terms,
  e.g., button click or menu selection.

17
Style Guidelines (Ambler, 2005)

• Use case names begin with strong verbs.
• While use cases do not imply timing, order cases
  from top to bottom to imply timing (improves
  readability).
• The primary actors should appear in the top left.
• Actors are associated with one or more use cases.
  
• Do not use arrows on the actor-use case
  relationship.
• Do not show actors interacting with each other.
• Apply ltltincludegtgt when you know exactly when to
  invoke the use case. These should rarely nest
  more than 2 deep.
• Avoid using ltltextendgtgt.

18
Case Study E-book Store

• Identify the main actors and the key use cases
  for an e-bookstore, and draw a use case diagram.
  Describe the use case scenario for the most
  important use case.
• The core requirements of the e-bookstore are to
  allow its customers to browse and order books,
  music CDs, and computer software through the
  Internet. The main functionalities of the system
  are to provide information about the titles it
  carries to help customers make purchasing
  decisions handle customer registration, order
  processing, and shipping and support management
  of the system, such as adding, deleting, and
  updating titles and customer information.

19
Sample Solution
ltltincludegtgt
ltltextendgtgt
ltltincludegtgt
20
Sample Solution (Cont.)
Use Case Shop Description Browse the catalog
and place an order Actors Customer Precondition
The customer is already registered Main
scenario User System
Carry out Logon Show info about the titles Add
the title to the shopping cart Display shopping
cart contents and shipping and billing
address Validate payment method Process order
issue e-receipt and notify warehouse for
shipping
Repeat the following until done Search and
browse titles Select a title to buy Done
with shopping and check out Confirm order and
payment method
Alternative The customer saves the shopping
cart without checking out. Exceptional
Customer authentication fails repeat the logon
procedure. Payment validation fails prompt
the customer for new payment information.
21
Exercise

• Form a pair.
• Document the use cases of the Connect Four game
  by identifying and defining their use case
  scenarios.