Chapter 5. Use Case Preconditions, Postconditions, and Invariants: What They Didn t Tell You, But You Need to Know

Chapter 5. Use Case Preconditions, Postconditions, and Invariants: What They Didn't Tell You, But You Need to Know!

With the growth in popularity of use case-driven development, in some cases being applied to product components requiring high assurancee.g., safety-critical ^[1] or mission-critical systemsthere is an increased need for a systematic means of doing failure analysis and test design from use cases.

^[1] See, for example, the role of use cases in "drive by wire" cars in Johannessen et al. (2001).

From a black-box testing perspective, preconditions and postconditions are the quintessential elements of a use case, saying what it does without saying how. They are the ideal basis for black-box testing; what more could one need for specifying tests? And in failure analysis, preconditions play the role of specifying those conditions under which the use case is intended to work correctly, and conversely the conditions under which the system might fail. A system can then be implemented by using techniques such as design by contract or defensive programming , where routines check their preconditionscalled assertions because they assert what the routine assumes to be truebefore running. If the precondition is false, the routine can handle the exception safely (i.e., fail safe ). ^[2]

^[2] Storey (1996) discusses the role of assertions in safety-critical systems and Binder (2000) looks at their use in automated testing.

In reality, however, few use cases are produced with preconditions and postconditions of substance enough to test from. If you look at your favorite book on use cases, you are likely to find use cases with preconditions but no postconditions (the significance of which will make sense later) and postconditions with no preconditions. And even when both are present, you would likely be hard pressed to tell what a use case did based solely on the pre- and postconditions . While developers may be willing to keep use cases informal (Cockburn, 2002) ^[3] when it comes to failure analysis and test design, something a bit more concrete is needed; hence, a number of proposals for making use cases more test-ready have appeared. ^[4]

^[3] See Alistair Cockburn's "Use Cases, Ten Years Later" (2002) for a discussion of this topic.

^[4] See, for example, (Binder 2000) and David Gelperin's "Precise Use Cases."

In this chapter, we look briefly at the history of preconditions and postconditions and learn what they forgot to tell you in "Use Case 101": preconditions can be calculated from postconditions , and often with little more than simple algebra! The usefulness of this fact should be obvious from a black-box testing and failure analysis standpoint: given a black-box's outputs (the postcondition), you can calculate the set of inputs and starting states which produce it (the precondition) and conversely the inputs and starting states, which are excluded, could spell system failure, and might warrant error handling tests. In this chapter, we also discuss invariants, which are to use cases what safety requirements are to safety-critical systems. This chapter concludes with some suggestions on working smart to apply the techniques presented, including a section that gives you the very least you need to know to apply the lessons of model-based specification today .