UML Weekend Crash Course™ - To Parent Directory

70
Saturday Morning
Much of this language is borrowed from the “programming by contract” concept, developed
and implemented by Bertrand Meyer in the creation of the Eiffel programming language. One
chief goal of the programming by contract concept is to define each unit as autonomous,
whether the unit is an object or a Use Case. Each unit should remain as independent from
others as possible, also referred to as being loosely coupled. Unit independence allows each
unit to be maintained without requiring corresponding changes in other units. This reduces
the cost of development and maintenance of the system.
Assumptions
Typically, developers think of assumptions as bad, something to be avoided. Here, I’m applying
the concept in a positive way. In order for the Use Case to work properly, certain conditions
must be true within the system.
You agree, or you contract, never to invoke this Use Case unless you know that all the
needed conditions have been met. In other words, assumptions describe a state of the system
that must be true before you can use the Use Case. These conditions are not tested by
the Use Case (contrast this later with the pre-conditions). For example, consider the tasks
of performing authentication and authorization. A standard security check feature typically
handles these functions. Each subsequent Use Case assumes that the user could not access
the Use Case had he not made it past the security check. Consequently, you would rarely if
ever include the security check in each Use Case.
So how does this help you with the design of the system If one Use Case can’t work and
should not even be accessed unless another Use Case has first done its job, this condition
dictates the order of execution. The assumptions give you explicit clues about the sequence
of execution for Use Cases (that is, the workflow).
Tip
Place common Use Case assumptions into a system-level document instead
of including them in every Use Case narrative.
Pre-conditions
Pre-conditions are easily confused with assumptions. Like assumptions, pre-conditions
describe a state of the system that must be true before you can use the Use Case. But unlike
assumptions, these conditions are tested by the Use Case before doing anything else. If the
conditions are not true, the actor is refused entry.
Most programmers have coded pre-conditions nearly every time they write a method or
subroutine call that has parameters. When you write code, what are the first lines of code
that you write in a function or method that has parameters You validate the parameters.
You test to make certain that the conditions are right to proceed with the rest of the code.
Failure in these tests would mean problems for the subsequent code, so the call is refused
and turned back to the requester. You established and tested the pre-conditions for execution
of your method or function.
These rules or pre-conditions need to be published along with the interface to your Use
Case. For example, a typical interface can only tell the client to provide two integer values
and a character string. It can’t tell them the rules that say that the first integer must be a