Precise Use Cases - Part 5

David Gelperin, LiveSpecs Software

Appendix: Additional PUC Examples

This appendix contains a substantial use case example that includes a performed course, two optional action courses, and exception handling macros. An example of the three-column, trialog format is also included.

1. An Example with Performed and Optional Action Courses,
   as well as Exception Handling Macros

Case Name: Build a Course Schedule

Risk Factors: Frequency of occurrence: 1 to 5 (1.3 avg.) times per student per quarter

Impact of failure:

likely case -- high

worst case -- high

Case Conditions:Invariants:

None

Preconditions:

University Web site is active

For student, system access status is signed on

Interactions

Basic course:

Student	University Web Site
ENTER 1. requests "Create a Schedule"
	2. If (For student, a schedule already exists 23%) displays existing schedule Else displays new schedule Endif
	3. displays list of available offering from the Course Catalog System, unless course registration is closed 8% or Course Catalog System is unavailable 3%
For each course request, actors repeat do "Add or Drop Courses"
	4. If (initial schedule has changed 80%) stores status, displays and prints schedule and schedule confirmation number Else displays invitation to return until registration close date Endif SUCCESS EXIT

Success course conditionsInvariants:

University Web site is active

Course registration is open

For Course Catalog system, status is available

Preconditions:

None

Post-conditions:

For student, system access status is signed on

For student, a schedule exists

For student, schedule, and course requests,

all approved requests are recorded, displayed, and printed along with associated confirmation number

all disapproved requests are explained

Performed Courses:

"Add or Drop Courses" (ADC):

ADC Invariants:

University Web site is active

For student, system access status is signed on course registration is open

For Course Catalog system, status is available

For student, a schedule exists

 

Student	University Web Site
1. requests course be a. added 88% b. dropped 12%
	2. If (add request) approves add request, unless a. course is full 18% b. prerequisites are not satisfied 7% c. conflict in schedule 2% d. course load is unacceptable 3% Else (drop) approves drop request, unless e. course is not in schedule 2%
	3. displays approved adds & drops as well as disapproved requests with reasons

ADC Post-conditions:

For student, schedule, and course request, request is approved or disapproved with reasons

Alternative Courses:

Optional Action

Log On after basic course ENTER

Log On Invariants:

University Web site is active

Log On Preconditions:

For student, system access status is signed off

Student	University Web Site
1. requests logon	2. requests logon info
3. provides logon info	4. If (logon info ok) displays welcome message Post-cond - For student, system access status is signed on Else requests correct logon info Endif
Until (logon info ok or three unsuccessful tries), actors repeat 3 to 4
	5. If (logon info ok) CONTINUE Else FAILURE EXIT Endif

Optional Action

Quit Registration

Quit Registration Invariants:

University Web site is active

Quit Registration Preconditions:

For student, system access status is signed on

 

Student	University Web Site
1. requests "Quit"	2. offers to save registration status
3. chooses a. save 93% b. no save 7%	4. If (save selected) stores status Post-cond - For student, approved courses, disapproved requests with reasons, and unprocessed requests are stored Endif
	5. offers to continue, instead of quit
6. chooses a. continue 7% b. quit 93%
	7. If (continue selected) CONTINUE Post-cond - For student, system access status is signed on Else SUCCESS EXIT Post-cond - For student, system access status is signed off Endif

Exception Handlers:

Exception Handling Macro 1 - Displays exception condition message

EHM1 Invariants: For system, <exception condition>

EHM1 Preconditions: None

 

Student	University Web Site
	1. displays <exception condition> message FAILURE EXIT

EHM1 Post-conditions:

For system, <exception condition> message is displayed

EHM1 applies to:

EH1 - SC 3a: course registration is closed

EH2 - SC 3b: catalog system is unavailable

Exception Handling Macro 2 - Add request disapproved

EHM2 Invariants: For student, schedule, and add request, <exception condition>

EHM2 Preconditions: For student and schedule, add request is pending

Student	University Web Site
	1. records request denial and displays <exception condition> message CONTINUE

EHM2 Post-conditions: For student and schedule add request is disapproved

EHM2 applies to:

EH3 - ADC 2a: course is full

EH4 - ADC 2b: prerequisites are not satisfied

EH5 - ADC 2c: conflict in schedule

EH6 - ADC 2d: course load is unacceptable

Exception Handler 7 - ADC 2e

EH7 Invariants: For student, schedule, and drop request, requested course is not in schedule

EH7 Preconditions: For student and schedule drop request is pending

 

Student	University Web Site
	1. records request denial and displays "only approved courses can be dropped" message CONTINUE

EH7 Post-conditions: For student and schedule drop request is disapproved

This example is derived from the example on page 123 in Alistair Cockburn's Writing Effective Use Cases (Addison-Wesley 2001).

2. Example of Three-Column Course Format

Case Name: Checkout items

Risk Factors:Frequency of occurrence: 10 to 200 per hour

Impact of failure:

likely case - low, checkout at another station

worst case - high, all stations down

Case Conditions

Invariants:

For system, a clerk available

Preconditions:

For customer, items to be checked out

For system, POS subsystem status is operational

Interactions

Basic course:

Customer	Checkout System
	Clerk	POS subsystem
ENTER 1. requests checkout and provides items
	Until all items are entered, actors repeat 2 to 4
	2. enters next item a. by scanning b. manually	3. displays line-item details
		4. displays running total
	5. requests payment
6. chooses a. credit or debt card b. cash or equivalent		7. If (credit or debit card is offered and payment amount is approved) accepts card payment Endif
	8. If (no card payment is accepted) accepts and deposits cash or equivalent, unless a. amount is insufficient Endif	9. records sale
		10. updates inventory
		11. prints receipt SUCCESS EXIT

Basic course Conditions

Invariants:

For system, a clerk available

For system, POS subsystem status is operational

Preconditions:

For customer, items to be checked out

For purchase amount, card payment or cash or cash equivalent is sufficient

Post-conditions:

For customer transaction, sale of all desired items is recorded and receipt is printed

For sold items, inventory updated

Go to page 4

Back to the archive list