Introduction to UML Diagrams Use Case Diagrams - PowerPoint - PowerPoint

Document Sample
Introduction to UML Diagrams Use Case Diagrams - PowerPoint - PowerPoint Powered By Docstoc
					Introduction to UML Diagrams:
      Use Case Diagrams

     Georgia State University
      CIS 3300 Spring 2010
UML Modeling
   You can model 80% of most problems
    by using about 20% UML
   In this course, we will discuss those
        UML 1.0 Primary Diagrams
   Use Case diagrams
       Describe the functional behavior of the system as seen
        by the user.
   Sequence diagrams
       Describe the dynamic behavior between actors and the
        system and between objects of the system.
   Class diagrams
       Describe the static structure of the system: Objects,
        Attributes, and Associations.
        UML Primary Diagrams (Cont)

   State Machine diagrams
       Describe the dynamic behavior of an individual object
        as a finite state machine.
   Activity diagrams
       Model the dynamic behavior of a system, in particular
        the workflow, i.e. a flowchart.
UML 1.0 – Other Diagrams
   Communication      Package Diagrams
Introduction to Use Case Diagrams

   Use Cases:
       Technique for capturing functional requirements of a
       Describe typical interactions between users of a
        system and the system itself.
   A scenario is a sequence of steps describing an
    interaction between a user and a system.
   Scenarios model the goal of the user (an actor).
       An actor is a role that a user plays with respect to
        the system.
   A use case is a set of scenarios tied together by
    a common user goal.
  Introduction to Use Case Diagrams:
  „Buy a Product‟ Scenario
The customer browses the catalog and adds desired items to the shopping
basket. When the customer wishes to pay, the customer describes the ship-
ping and credit card information and confirms the sale. The system checks
the authorization on the credit card and confirms the sale both immedi-
ately and with a follow-up call.

  Who is the actor?

  What is the actor‟s goal?

  What if the customer is a regular customer and you
  Already know shipping and credit card information?

  What happens if credit card authorization fails?
Contents of a Use Case
   Main success scenario
       Sequence of numbered steps
   „Other‟ scenarios:
       Variations on the main success scenario
       Are „extensions,‟ can be successes or
            Conditions that result in different interactions
             from those described in the main success
             scenario (MSS).
Example Use Case Text
Introduction to Use Case Diagrams

   Types:
       business use cases
       system use cases (our focus)
   Use cases tell a story of actors using a
   They illustrate functional requirements, by
    the stories they tell.
   Complementary with a functional
    requirements list.
Identifying Use Cases
   Major distinct, complete, end-to-end
    processes of using a system.
   Not usually one step, but a complete story.
       Common “mistake”!
   Examples
       Rent Videos
       Return Videos
       Pay Fines
Use Case Diagram               "robo-actor"
                                                   Video Store
                               sy stem agent
                                               Information System

                                                 Query For Items

       A way to      Authorization
                                                   Pay Fines

                                                  Rent Items

        the use                                    Manage

        cases.         Clerk

       Usually                                     Log In

        during the                                 Manage

        initial use    Manager

        case                                    Manage Users

 A Sample Detailed Use Case
Use Case: Rent Items
Typical Course of Events

              Actor Intentions                             System Responsibility

1. Customer arrives at a checkout with
   videos (and/or less often, video games)
   to rent.
2. The    Customer         presents  their 3. Presents membership information, and
   membership identification to the Clerk,    status of loans (usually nothing on loan,
   who enters it into the system.             and no outstanding fines).
4. For each video or game, the Clerk 5. Presents accumulating list of rental
   records the item identification into the item titles, due dates, total rental fee,
   system.                                  and any late charges.
6. Clerk informs Customer of total charge,
   and asks for payment.
7. Customer pays Clerk by cash or credit.
8. Clerk records payment into system.           9. If a credit payment, authorizes it.
                                                10. Generates receipt and loan report.
11. Clerk gives receipt and loan report to
    Customer, who then leaves with the
    rental items.

Alternative Courses

    Step 7. Customer has insufficient cash. Request a credit payment, cancel the
     transaction, or deduct rental items until transaction can be paid for.

    Step 7: Customer has unpaid late charges and will not pay them. Customer must pay
     them before renting more items, so either collect full payment, or cancel the

    Step 9. Failure to authorize credit payment, either because of insufficient credit or
     inactive authorization service. Request cash payment instead.
            A Sample Summary Use Case
         Same principles a detailed use case, but simplifies
          steps and details, as a low-fidelity incomplete first
            Useful during early requirements and scope


              Actor Intentions                System Responsibilities
1. Customer presents items to rent.
2. Clerk records items.                   3. Remember rented items.
                                          4. Calculate and present price.
5.       Customer pays.                   6. Authorize and record
Use Case Diagram
UML Second Pass: Use Case
                     Used during requirements
                     elicitation to represent external
                    Actors represent roles, that is,
                     a type of user of the system
  Passenger         Use cases represent a
                     sequence of interaction for a
                     type of functionality
                    The use case model is the set
                     of all use cases. It is a complete
PurchaseTicket       description of the functionality
                     of the system and its
               An actor models an external entity
                which communicates with the system:
                   User
                   External system
                   Physical environment
               An actor has a unique name and an
                optional description.
               Examples:
Passenger          Passenger: A person in the train
                   GPS satellite: Provides the system with
                    GPS coordinates
Use Case
                 A use case represents a class of
                   functionality provided by the
                   system as an event flow.
                 A use case consists of:
                  Unique name

                  Participating actors

                  Pre-conditions

                  Entry conditions (triggers)

                  Flow of events

PurchaseTicket    Exit conditions (success
                  Special requirements
                                     The <<extend>>
                                          <<extend>> relationships
                    Passenger              represent exceptional or
                                           seldom invoked cases.
                                          The exceptional event flows
                                           are factored out of the main
                 PurchaseTicket            event flow for clarity.
                                          Use cases representing
  <<extend>>              <<extend>>
                                           exceptional flows can
                                           extend more than one use
                          NoChange         case.
OutOfOrder                                The direction of a
                                           <<extend>> relationship is
                                           to the extended use case
      The <<include>> Relationship

     Passenger                                      An <<include>>
                                                     relationship represents
                                                     behavior that is factored
                       PurchaseMultiCard             out of the use case.
                                                    An <<include>>
                                                     represents behavior that
                                                     is factored out for reuse,
      <<include>>                                    not because it is an
                                                    The direction of a
                 CollectMoney                        <<include>>
  <<extend>>                        <<extend>>
                                                     relationship is to the
                                                     using use case (unlike
     NoChange                      Cancel            relationships).
Relating Use Cases
   When creating the use case diagram, it
    can be useful (in terms of
    comprehension and simplification) to:
       factor out shared sub-processes
            use the <<includes>> relationship
       show precedence order (with exceptions)
            use the <<extends>> relationship
Contents: ATM
Requirements Capture
   A simplified Automatic Teller Machine
   Which requirements are to be captured?
   The activities in Requirement capture
       Identification of system boundaries: actors
        and use cases
       Diagramming use cases
       Elaborating scenarios
       Diagramming scenarios
A Simplified Automatic Teller
            The ATM is associated with only
             one bank
                It gives access to all the accounts the
                 customer owns in the bank
            Several types of transactions can
             be chained in a single session
                Withdrawal, deposit, transfer between
                 the customer‟s own accounts,
                 consulting an account
                The customer may obtain a printed
                 receipt for each transaction
A Simplified Automatic Teller
Machine (cont. 1)
            The card contains
                 an ID number
                 an expiration date
                 a secret code
            The card must be verified by the
                 The customer cannot make more
                  than 3 attempts to enter the correct
                  code, otherwise the card is swallowed
            Interface
                 Keyboard and screen, with menus
                 The customer may cancel the current
                  transaction at meaningful points
A Simplified Automatic Teller
Machine (cont. 2)
             The connections with the bank
              are kept to a minimum
                 When a session is opened, a
                  connection makes it possible to
                  known all the accounts the customer
                 Every night, the information about
                  the current day transactions are
                  transferred to the bank
             From time to time an employee
                 empties the machine and/or fills it
                  with bank notes
                 supplies consumables and does any
                  maintenance that may be needed
Which requirements are to be
   Functional requirements
       Modeled as Use Cases
   Non functional requirements
       Some are specific to one use case
       Some relate to technical issues addressed
        by implementation diagrams and models
       Other in some supplementary documents,
        out of the UML scope…
Identifying System Boundaries
Identifying Actors
   Actors are anything which interface with the
       People, other systems, hardware, software,
       They are roles, not necessarily full-fledged objects
   Actors are not part of the system
       They are just at the boundary (external to the
       They won‟t produce code!
Identifying System Boundaries
Identifying Actors (cont.)
   ATM example
       Customer using the       Customer
        teller machine
       Bank
       Maintenance
        technician                        Bank

       What about the
        card itself?
Identifying System Boundaries
Identifying Use Cases
   Use cases describe the services the
    system must perform from the point of
    view of the actors
       Functional description
       From an usage point of view
   Diagramming Use Cases
   Top Level Use Case Diagram
                                   system boundary
                  Handle Session
                  Transfer Daily

Diagramming Use Cases
Stereotyped Dependencies
    « include »                « include »
             « include »
  Card                               Handle
                 « include »       Transaction
                                      « extend »
          Get Customer
           Information                 Deliver
Diagramming Use Cases
Stereotyped Dependencies

   « include »
       The included use case is a mandatory part of the
        including one (functionality-wise, not actor-wise)

            Included   « include » Including

   « extend »
       The extending use case is an optional part of the
        extended one (functionality-wise, not actor-wise)

           Extending   « extend » Extended
Diagramming Use Cases

   Handle                   Handle
   Deposit                 Withdrawal

      Handle         Handle
      Consult        Transfer
Diagramming Use Cases
   The specialized and generalized use
    cases are in a “sort of” relationship

Elaborating scenarios
Use Case and Scenarios
   Use cases classify the ways of using the
   To each use case correspond many possible
    usage scenarios
   Thus scenarios
       are instances of use cases
       specify use cases
   Each use case has generally
       a primary scenario, possibly several (a few)
       several secondary (more exceptional) scenarios
  Elaborating Scenarios for Use Cases
  Alistair Cockburn’s style (1)

Use Case: Handle Session                   Handle
Precondition: the ATM is free              Session
Primary Scenario
                                  « include »   « include »
1. The Customer inserts the
    card into the ATM.
2. The ATM verifies the card
    validity.                    Verify                Handle
3. The Customer authentifies      Card               Transaction
    with the ATM.
4. The ATM gets the Customer           « include »
    information from the Bank.
                                                « include »
5. The Customer selects a        Authentify
                                  Customer    Get Customer
6. The Customer quits.
7. The ATM ejects the card.
Postcondition: the ATM is free
Elaborating Scenarios for Use Cases
Alistair Cockburn’s style (2)
Use Case: Handle Session       2a The card is invalid; the ATM
                                    swallows it; this ends the
Precondition: the ATM is free       session.
Primary Scenario               3a The Customer fails to
1. The Customer inserts the         authentify; the ATM swallows
    card into the ATM.              the card; this ends the
2. The ATM verifies the card        session.
    validity.                  4a The connection with the Bank
3. The Customer authentifies        is impossible or interrupted;
    with the ATM.                   the ATM ejects the card; this
4. The ATM gets the Customer        ends the session.
    information from the Bank. 5a The Customer may quit
5. The Customer selects a           immediately.
    transaction.               6a The Customer chooses to
6. The Customer quits.              perform another transaction;
7. The ATM ejects the card.         goto step 5.
Postcondition: the ATM is free * The Customer may cancel the
                                    session; the ATM ejects the
  Elaborating scenarios
  Primary Scenario
Use Case: Handle Session        5. The customer performs
Scenario: Primary (typical)         a transaction
Precondition: the ATM is free   6. When the transaction is
1. The scenario starts              finished, the customer
    when the customer               may ask for another
    inserts the card                transaction (go to 5) or
2. The card is accepted
                                7. The scenario is finished
3. The customer enters the          when the customer
    secret code correctly           decides to quit; the card
4. The ATM gets the                 is ejected
    customer information        Postcondition: the ATM is free
    from the bank
Elaborating scenarios
Example of Secondary
Use Case: Handle Session        5. The card is ejected and
Scenario: Secondary                 the scenario is finished
    (customer interrupt)        Postcondition: the ATM is free
Precondition: the ATM is free
1. The scenario starts
    when the customer
    inserts the card
2. The card is accepted
3. The customer enters the
    secret code correctly
4. The customer cancel the