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
    20%
        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
    Diagrams
Introduction to Use Case Diagrams

   Use Cases:
       Technique for capturing functional requirements of a
        system
       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
        failures:
            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
    system.
   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

                         Credit
       A way to      Authorization
                         Service
        conceive
                                                   Pay Fines


        and
        illustrate
                                                  Rent Items



        the use                                    Manage

        cases.         Clerk
                                                 Memberships
                                                                    Customer

       Usually                                     Log In

        created
        during the                                 Manage
                                                  Inventory

        initial use    Manager
                                                                        Admin-
                                                                        istrator

        case                                    Manage Users


        analysis.
 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
     transaction.

    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
          draft.
            Useful during early requirements and scope

             analysis

              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
                                          payment.
Use Case Diagram
UML Second Pass: Use Case
Diagrams
                     Used during requirements
                     elicitation to represent external
                     behavior
                    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
                     environment
 Actors
               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
                   „guarantees‟)
                  Special requirements
                                     The <<extend>>
                                     Relationship
                                          <<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
             <<extend>>
                          NoChange         case.
OutOfOrder                                The direction of a
                                           <<extend>> relationship is
                                           to the extended use case
                 Cancel
      The <<include>> Relationship

     Passenger                                      An <<include>>
                                                     relationship represents
                                                     behavior that is factored
                       PurchaseMultiCard             out of the use case.
PurchaseSingleTicket
                                                    An <<include>>
                                                     represents behavior that
                              <<include>>
                                                     is factored out for reuse,
      <<include>>                                    not because it is an
                                                     exception.
                                                    The direction of a
                 CollectMoney                        <<include>>
  <<extend>>                        <<extend>>
                                                     relationship is to the
                                                     using use case (unlike
                                                     <<extend>>
     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
Machine
            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
             ATM
                 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
                  owns
                 Every night, the information about
                  the current day transactions are
                  transferred to the bank
             From time to time an employee
              manually
                 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
captured?
   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
    system
       People, other systems, hardware, software,
        networks…
       They are roles, not necessarily full-fledged objects
   Actors are not part of the system
       They are just at the boundary (external to the
        system)
       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?
                             Technician
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
    association
                  Handle Session
Customer
                                         Bank
                  Transfer Daily



                    Maintain
                                       Technician
Diagramming Use Cases
Stereotyped Dependencies
                     Handle
                     Session
    « include »                « include »
             « include »
 Verify
  Card                               Handle
                 « include »       Transaction
  Authentify
   Customer
                                      « extend »
          Get Customer
           Information                 Deliver
                                       Receipt
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
Generalization
               Handle
             Transaction



   Handle                   Handle
   Deposit                 Withdrawal

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




                 Specialized
Elaborating scenarios
Use Case and Scenarios
   Use cases classify the ways of using the
    system
   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
    transaction.
                                  Customer    Get Customer
6. The Customer quits.
                                               Information
7. The ATM ejects the card.
Postcondition: the ATM is free
Elaborating Scenarios for Use Cases
Alistair Cockburn’s style (2)
                               Variants
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
                                    card.
  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
                                    quit
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
Scenarios
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
    session