CSci 375/04 Use Cases
Table| Date | # | Topic (Participation 2pt) | Study pages (2 pts) | Quiz(15 pts) | Project Work(10 pts)
|
|---|
| Previous | 3 | Inception | 41-59 | Q1(1-59) | -
|
| Today | 4 | Use Cases | 61-89 | - | W1 (section 4.3)
|
| Next | 5 | More Requirements | 89-120 | Q2(61-120) | -
|
(Close Table)
Input: Use Cases pages 61-89
- ++ My advice
[ Advice in usecases ]
- + My page on use cases
[ usecases.html ]
- + A
use case
is a collection scenarios of an actor using the system
(and other actors perhaps) to achieve a goal.
- + Definitions
- actor::="Something with behavior, goals, ...".
- scenario::text="an instance of a use case...", a list of steps
that an actor takes with the system responses.
- use_case::set(text)="a collection of related scenarios...".
- * A use case diagram gives a nice summary of names and relationships
of the actors and the use cases in a system.
- * Motivation: why
- * Functional requirements?
- * Three Kinds of Actor: primary, secondary, off-stage.
- *** Four Use case Formats/Levels:
- +++ A name
[ usecases.html#Level 1 -- Give it a name ]
[ Level 2 -- Brief Format in usecases ]
[ Level 3 -- Casual in usecases ]
[ Level 4 -- Fully Dressed in usecases ]
- * Example
- Meaning of sections
- Two column format?
- ** Guidelines
- * no user-interface stuff
- * A use case name starts with a strong verb: make, deleted, manage,
construct, find, discover, buy, sell.
- * TERSE. Delete words.
- ** Black box: no internal/invisible steps.
Each step involves an external actor. Primary, secondary, or off stage.
- Actors and their goals.
- * How to find.
- * 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
- CS202::= See http://cse.csusb.edu/dick/cs202/.
- CS372::= See http://cse.csusb.edu/dick/cs372/.
- DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
- DRY::XP="Don't Repeat Yourself".
- ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm,
Ivar Jacobsen simplified "Essential" UP.
- Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
- GoF::="Gang of Four",
[ patterns.html#GoF ]
- 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 ]
- Grades::= See http://cse.csusb.edu/dick/cs375/grading/.
- 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.
- OO::shorthand="Object-Oriented".
- OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
- patterns::="Documented families of problems and matching solutions", see
Patterns.
- Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.
- Process::="How to develop software".
- RJB::=The author of this document,
RJB="Richard J Botting, Comp Sci Dept, CSUSB".
- RUP::Process="Rational UP", a proprietary version of UP.
- SSD::="System Sequence Diagrams", see chapter 10.
- TBA::="To Be Announced".
- UML::="Unified Modeling Language".
[ Unified_Modeling_Language ]
- UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.
- 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".
- XP::="Extreme Programming", the ultimate iterative code-centric, user-involved
process.