Precise Use Cases - Page 4

David Gelperin, LiveSpecs Software

9. PUC modeling guidelines

1. A use case may require access to specific resources (e.g., document files or applications) to be successful and an inter-actor may be able to enable this access (e.g., by opening a file or signing onto an application). In this situation, define an optional action to be inserted at the start of the use case that specifies resource enabling if the resources are not accessible e.g. inter-actor log on.

Using this approach removes most dependencies between use cases, except for multiple cases that reference the same application entity. For example, if one use case creates a document named "bob" and the next one tries to create a document with the same name, the inter-actor should get a different response than if the first use case had not occurred.

2. Sometimes, there may be confusion in choosing between an "<action>, unless" and an "if (<selection condition>)". The guidelines are:

1. when an action is always to be done, unless some exception condition is TRUE, use an "action, unless" . An exception condition is one that is intended to be exceptional. Sometimes it may actually be the rule, e.g., the printer may usually be inoperative.

2. when an action is to be done sometimes, but not other times, use an "if (<selection condition>)" e.g., for adding some courses and deleting others use an if.

3. Model the flow of information, not user interface design nor navigation details. Use input actions like - enters, provides, or requests rather than fills in a form, clicks a button, or links to a specific web page. See the discussion of essential use cases in [4].

Additional recommendations can be found in [11].

10. A development process for suites of PUCs

PUCs are too detailed for effective use during early interactive elicitation. Their development can be characterized as the descriptive (as opposed to prescriptive) programming of interactive processes. Therefore, development of PUCs should start after some requirements have already been captured using a less formal style of use case [26]. Initial forms can be as informal as the user stories used in XP development [1] or any of the styles described in [6] or [21]. PUC development and informal elicitation can co-occur.

The initial PUCs should be developed by stakeholder teams. This precise modeling process will expose misunderstandings, disagreements, and confusion. After a solid foundation of common understanding has been established, PUCs can be developed "off line" by an analyst or tester, but they will require stakeholder support to answer the inevitable questions and to review the results. The issues uncovered during PUC development, if uncovered before system design, could be PUC's most important contribution to quality.

A suite of use cases can be developed as follows:

1. Identify system, clarify scope, and list functions
2. Identify inter-actors and relationships
3. Identify goals of primary inter-actors
4. Identify domain and system entities (e.g., an order) associated with the goals
5. Develop use cases for [critical] goals
6. Factor common operations into their own cases and similar cases into parameterized cases
7. Organize the suite

Identify inter-actors with the following questions:

• For the new system or change:
• Who/What directly benefits?
• Who/What is directly impacted?
• Which services are needed to enable successful functioning and who/what supplies them?

Identify goals of the primary inter-actors as follows:

• Identify those directly helped by the proposed system or change (these are the primary inter-actors)
• Identify primary inter-actor job responsibilities, with priorities
• Identify strategies for carrying out the relevant responsibilities
• Identify goals (and sub-goals) associated with the selected strategy
• For each goal, identify which inter-actors share the goal; when, how often, and why the goal is important; and what happens if the goal is not met

Develop a use case as follows:

1. Create an id and goal-based title
2. Write a minimal basic course
3. Add exception conditions to the course
4. Develop a rich set of inter-actor friendly alternative courses
5. Factor similar alternatives into course macros
6. To shorten a course, factor out a group of steps into another course or into a use case (operation-level)
7. Add course conditions (invariant, pre, and post) to each course and macro
8. Add supplemental info to the case

Identify course conditions as follows:

Post-conditions & Invariants

• For each step, ask: What conditions caused by this step will always be TRUE at the end of the course?
• Identify any invariants among the post-conditions
• For each variable in a post-condition, identify any relevant invariants for that variable

Pre-conditions & Invariants

• For each step, ask: What conditions must be TRUE from the beginning of the course to enable this step?
• Identify any invariants among the pre-conditions
• For each variable in a pre-condition, identify any relevant invariants for that variable

Review the suite of PUCs with stakeholders and subject matter experts and modify as needed

11. Test coverage criteria for PUCs

To describe test coverage, we need a few definitions. Single-goal use cases accomplish one and only on user goal. Multiple-goal cases accomplish two or more user goals. Transitional use cases cause entity state transitions e.g., returns a book, while non-transitional cases do not e.g. display copies borrowed. An ordered pair of transitional cases referencing the same entity may be valid or invalid. For example, a customer record can only be updated, after it is created.

For a set of PUCs, a test suite should cover:

• every (valid) ordered pair of single-goal cases where one or both are non-transitional
• every (valid & invalid) ordered pair of transitional cases that reference the same entity
• every multiple-goal case

If this is too expensive, then either cover every ordered pair of "high or medium risk" use cases or just cover every ordered pair of "high risk" use cases. In either case, cover every multiple-goal case.

Within a single-goal case, a test suite should cover every step in the basic course, performed courses, and alternative courses.

A use case will normally contain multiple scenarios i.e., complete execution paths, because it contains repetition cycles and alternative courses. A scenario may have multiple interpretations, because it contains input alternatives and derived conditions for inputs (e.g., invalid) or states (e.g., unavailable). There are usually many distinct ways to interpret a derived condition e.g., many distinct ways to be invalid or state.

For a use case, the test suite should cover every:

1. repetition cycle 0 (if possible), 1, and an even number of times
2. unique cause + 1 interpretation [13] of selection, repetition, alternative course, and derived conditions
3. input alternative

In addition, the test suite should cover:

1. output boundaries
2. valid and invalid input boundary values [18].

If one or more of these criteria causes the test suite to be "too big" (i.e., unaffordable because criteria are too strong), risk information must be used to weaken or delete criteria.

Consider adding the "every pair of input partition values" [28] criterion, if you have an adequate budget surplus and its incremental cost-effectiveness has been shown.

12. Related work

Others have proposed adding rigor to usage descriptions. Proposals have entailed Message Sequence Charts and Process Algebra [2], Abstract State Machine Language [14], Activity Diagrams [20], and Modular Petri Nets [29]. These alternatives, however, do not present the application choices, essential to effective test design, as clearly and completely as PUCs. More importantly, these other approaches have not evolved from informal forms of the same technique. Effective informal forms make transition to formality much easier.

The Object Constraint Language [27] has been proposed for specifying conditions, but does not satisfy the understandability requirement.

13. Acknowledgements

This work owes an enormous debt to Alistair Cockburn's book [6]. I am also grateful to Ian Alexander, James Bach, Sofia and Stanislov Passova and Natan Aronshtam for helpful comments.

14. References

[1] Extreme Programming info available at www.extremeprogramming.org/rules/userstories.html

[2] Andersson, Michael and Bergstrand, Johan "Formalizing Use Cases with Message Sequence Charts" MS Thesis, Lund Institute of Technology May 1995 Available at www.efd.lth.se/~d87man/EXJOBB/Formal_Approach_to_UC.html

[3] Armour, Frank and Miller, Granville Advanced Use Case Modeling Addison Wesley 2001

[4] Constantine, Larry and Lockwood, Lucy "Structure and Style in Use Cases for User Interface Design" Available at www.foruse.com/Resources.htm#style

[5] Constantine, Larry and Lockwood, Lucy Software for Use ACM Press Addison Wesley 1999

[6] Cockburn, Alistair Writing Effective Use Cases Addison-Wesley 2001

[7] Cockburn, Alistair "Use Cases, Ten Years Later" STQE, SQE, Vol. 4, No. 2, March/April 2002

[8] DeMarco, Tom Structured Analysis and System Specification Prentice-Hall 1978

[9] Gelperin, David "Precise Usage Model for Library Management System" Available at www.LiveSpecs.com

[10] Gelperin, David "Precise Use Case Examples" Available at www.LiveSpecs.com[also included as an appendix]

[11] Gelperin, David "Modeling Alternative Courses in Detailed Use Cases" Available at www.LiveSpecs.com

[12] Gelperin, David "Specifying Consequences with Action Contracts" Available at www.LiveSpecs.com

[13] Gelperin, David "Testing Complex Logic" Available at www.LiveSpecs.com

[14] Grieskamp, Wolfgang, Lepper, Markus, Schullte, Wolfram, and Tillmann, Nikolai "Testable Use Cases in the Abstract State Machine Language" in Proceedings of Asia-Pacific Conference on Quality Software (APAQS'01), December 2001.

[15] Garcia, Alessandro F., Rubira, Cecilia M. F., Romanovsky, Alexander, Xu, Jie. "A Comparative Study of Exception Handling Mechanisms for Building Dependable Object-Oriented Software". Journal of Systems and Software, Elsevier, Vol. 59, Issue 2, November 2001, pp. 197-222.

[16] Ivar Jacobson et al Object-Oriented Software Engineering Addison-Wesley 1992

[17] Jungmayr, Stefan and Stumpe, Jens "Another Motivation for Usage Modeling: Generation of User Documentation" Proceedings of CONQUEST '98, Nuernberg, Germany, September 28-29, 1998

[18] Kaner, Cem, Falk, Jack, Nguyen, Hung Quoc Testing Computer Software John Wiley 1999

[19] Kulak, Daryl and Guiney, Eamonn Use Cases: Requirements in Context ACM Press Addison-Wesley 2000

[20] Kosters, Georg, Six, Hans-Werner, and Winter, Mario "Coupling Use Cases and Class Models as a Means for Validation and Verification of Requirements Specifications" Requirements Engineering Journal, Vol. 6, No. 1 2001 pp 3-17

[21] Larman, Craig Applying UML and Patterns Prentice-Hall PTR 2002

[22] Rumbaugh, James "Getting Started : Using Use Cases to Capture Requirements" Journal of OO Programming, SIGS Publications, Vol. 7, No. 5, Sept 1994 pp 8-10, 12, & 23

[23] Runeson, Per and Regnell, Bjom "Derivation of an integrated opertational profile and use case model" 9^th Symposium on SRE IEEE press Nov. '98 pp. 70-79

[24] Schneider, Geri and Winters, Jason P. Applying Use Cases Addison Wesley 1998

[25] Thelin, Thomas, Runeson, Per, and Regnell, Bjorn "Usage-based reading - an experiment to guide reviewers with use cases" Information and Software Tech. 43 (2001) pp. 925-938

[26] Wiegers, Karl E. "Listening to the Customer's Voice" Software Development, March 1997

[27] Warmer, Jos and Kleppe, Anneke. The Object Constraint Language Addison Wesley 1999

[28] Williams, Clay and Paradkar, Amit "Efficient Regression Testing of Multi-Panel Systems" IEEE International Symposium on Software Reliability Engineering, Nov. 1999

[29] Woo, Jin Lee, Sung, Doek Cha, and Yong, Rae Kwon "Integration and Analysis of Use Cases Using Modular Petri Nets in Requirements Engineering" IEEE Transactions on Software Engineering, Vol. 24, No. 12, December 1998

---

Related Methods & Tools articles

• Understanding Use Case Modeling
• Precise Use Cases
• Estimating With Use Case Points

More Unified Modeling Language UML Knowledge

• Unified Modeling Language Portal
• UML Tools Directory

---

Go to page 3

Go the Appendix

Back to the archive list