[Skip Navigation] [Remove Frame] [CS375] [Text Version] 04.html Thu Mar 26 14:25:56 PDT 2009

Contents


    CSci 375/04 Use Cases


    Table
    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous3Inception41-59Q1(1-59)-
    Today4Use Cases61-89-W1 (section 4.3)
    Next5More Requirements89-120Q2(61-120)-

    (Close Table)

    Input: Use Cases pages 61-89


    1. ++ My advice [ Advice in usecases ]
    2. + My page on use cases [ usecases.html ]
    3. + A use case is a collection scenarios of an actor using the system (and other actors perhaps) to achieve a goal.
    4. + Definitions
    5. actor::="Something with behavior, goals, ...".
    6. scenario::text="an instance of a use case...", a list of steps that an actor takes with the system responses.
    7. use_case::set(text)="a collection of related scenarios...".

    8. * A use case diagram gives a nice summary of names and relationships of the actors and the use cases in a system.
    9. * Motivation: why
    10. * Functional requirements?
    11. * Three Kinds of Actor: primary, secondary, off-stage.
    12. *** Four Use case Formats/Levels:
      1. +++ A name [ usecases.html#Level 1 -- Give it a name ]

        [briefs] [ Level 2 -- Brief Format in usecases ]

        [Hawian shirt] [ Level 3 -- Casual in usecases ]

        [Tuxedo] [ Level 4 -- Fully Dressed in usecases ]


    13. * Example
    14. Meaning of sections
    15. Two column format?
    16. ** Guidelines
      1. * no user-interface stuff
      2. * A use case name starts with a strong verb: make, deleted, manage, construct, find, discover, buy, sell.
      3. * TERSE. Delete words.
      4. ** Black box: no internal/invisible steps. Each step involves an external actor. Primary, secondary, or off stage.
      5. Actors and their goals.
      6. * How to find.
      7. * Tests for use cases: are they valuable, atomic, and not too large or small.


    Links on Use Cases

    [ Use_Case ] (Wikipedia), [ Basic_use_case_template ] (Alistair Cockburn's templates), [ UseCaseTemplate.html ] (Complex fully dressed template in HTML from MIT), and [ fullydressed.html ] (from here).

    Example of a Simple system

      System -- Shopping Aid

      Vision

      A handheld, wireless device that helps shoppers buy the items that they want. A shopper has a list of items that they want. They are sold at different stores. The device keeps an up-to-date list of wanted items as the user shops.

      Use Case -- Go Shopping

      The shopper inputs a list of wanted items and the system displays stores where they can be found. The shopper goes from store to store looking for the products that match their list. They buy a product at the first store where they find it, mark it as bought and the system updates their list or items and stores.

      Use Case -- Start Up

      Etc.

    . . . . . . . . . ( end of section Example of a Simple system) <<Contents | End>>

    Questions on Use Cases

    [ 04q.html ]
    (Exercises): Write a Use Case for...

    Next: More Requirements

    Prepare by reading [ 05.html ] and the assigned readings on that page. Submit a question for credit.

    Start Work Project Inception

    The deliverable artifacts and presentation are in [ w1.html ] and they are due at start of class 05.

    Standard Definitions

  1. CS202::= See http://cse.csusb.edu/dick/cs202/.
  2. CS372::= See http://cse.csusb.edu/dick/cs372/.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. DRY::XP="Don't Repeat Yourself".

  5. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  6. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  7. GoF::="Gang of Four", [ patterns.html#GoF ]
  8. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  9. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  10. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  11. OO::shorthand="Object-Oriented".

  12. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  13. patterns::="Documented families of problems and matching solutions", see Patterns.
  14. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  15. Process::="How to develop software".

  16. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  17. RUP::Process="Rational UP", a proprietary version of UP.

  18. SSD::="System Sequence Diagrams", see chapter 10.

  19. TBA::="To Be Announced".

  20. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  21. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  22. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need it now. In this class it means "It won't be on the final or in quizzes".

  23. XP::="Extreme Programming", the ultimate iterative code-centric, user-involved process.

End