Use Cases Can Not Have
Preconditions or Postconditions
Analysis Paralysis
We have experienced that preconditions and postconditions with use cases have caused problems on project teams. On one project, arguments about them stalled the team for several months. Disagreements on which conditions existed and where they should be documented were the cause of this analysis paralysis. It was a shame because these conditions do not even belong to use cases!
Use Cases Are Defined by the Object Management Group (OMG)
The OMG is a consortium of hundreds of companies and organizations that sets standards for the IT industry. Well known OMG standards include CORBA and UML.The UML standard defines use cases. To read the full definition, download the
Superstructure specification (opens in a new window)
and read Chapter 16 Use Cases.
What Does the UML Specification Say About Preconditions and Postconditions?
The UML 2.x specification says that preconditions and postconditions belong to the class Behavior. The most common behaviors are:
- activities
- interactions
- state machines
The UML class UseCase is a BehavioredClassifier. See section 16.3.6 UseCase (from UseCases) that says a use case is a:
• BehavioredClassifier (from BasicBehaviors, Communications)The relevant part of Figure 13.6 - Common Behavior shows that a BehavioredClassifier can
1) possibly have at most one behavior of its own or
2) can own any number of behaviors
Note that the one special behavior a use case may own is still a subset of ownedBehavior on the diagram - the set of all behaviors the use case owns. This one behavior is set apart to allow for behavior of the use case itself, e.g., a constructor.It also means that a use case can own other behaviors - in particular interactions that are made up of steps in the use case.
How the Building Requirements Consensus™ Methodology Applies UML Definitions
The Building Requirements Consensus™ Methodology defines a use case as:A use case is a set of interactions with a system
that provides a perceivable benefit of value
to someone or something (the user)
playing the use case's role (or part)
from the perspective of the user.The UML Specification description of an interaction in section 14.3.13 is:
"An interaction is a unit of behavior that focuses on
the observable exchange of information between ConnectableElements."The ConnectableElements for a use case are:
1) the someone or something that is playing the use case's role and
2) the use case itself. An example interaction is:
The user submits a new customer and the system displays an updated list that includes the new customer. Note that the Building Requirements Consensus™ Methodology use case definition explicitly includes the concept of interactions.
Preconditions and Postconditions for
Use Cases?
The conclusion is that since a use case is not a Behavior it cannot have pre or post conditions. Each behavior that the use case owns can have a pre or post condition but not the use case itself. You can think of it this way: A use case is a container for its behaviors. The Building Requirements Consensus™ Methodology thinks about behaviors as interactions. An interaction is a user action/system response set. Since a use case cannot have pre- or post- conditions, you now have one less reason for analysis paralysis.
But What About
"The user must be authorized"?
Continue on to
use case precondition example.
From Exceptions to UC Concepts 201
From Use Case Preconditions to Building Requirements Consensus™ Home
|
