Sanity Check Before Proceeding

Unlike the other parts of this book where the ideas presented are fairly new to use case development, the use case community already has existing definitions of "precondition" and "postcondition" and how they relate to use cases. This makes for potential confusion when this chapter presents alternate perspectives and even an idea or two that conflict with the views often put forth by the use case community. One such difference I will mention now to hopefully prevent confusion as you start to read.

In this chapter, you will be looking at preconditions and postconditions of individual operations or steps that make up a use case.^[5] This is a different perspective from that of most use case literature that talks about pre- and postconditions of the use case "as a whole." One consequence of the latter perspective is that the use case community has focused primarily on preconditions that must be satisfied before the use case can start. But from a failure analysis and test design standpoint this is not sufficient: there are usually operations (for instance, later in the use case) whose preconditions are to be satisfied by the postcondition of another operation earlier in the same use case. While such preconditions do not prevent the use case from starting, their violation can translate into system failure nevertheless.

^[5] As a classifier in UML, use cases have attributes and operations. A use case operation represents "a piece of work the use case can perform." For additional details on the structure of use cases, refer to Rumbaugh, Jacobson, and Booch (2005).

While the presentation of pre- and postconditions in this chapter is, I believe, consistent with UML in general (The UML Reference Manual defines preconditions and postconditions in terms of operations [Rumbaugh, Jacobson, and Booch 2005]), the chapter could be a little confusing if you read it with the mindset that the only type of use case precondition is one that must be satisfied before the use case starts.

This issue and others are discussed in more detail near the end of this chapter; if you care to read ahead, see the "Further Thoughts: Preconditions, Postconditions, and Invariants in Use Cases" section. Remember, the goal of this chapter is not to rehash what has already been said about preconditions and postconditions in the use case literature. The goal of this chapter is to think outside the box a bit and present to you a look at preconditions and postconditions and how they relate to use cases from a whole new perspective, that of model-based specification.