Package suvi.alg.contracts

Design-by-Contract [Meyer1997] decorators [Gamma1995] for the algorithm interfaces.

See:
Description

Class Summary

Asserts	Assertions shared by multiple contract decorators.
ComponentLayoutPolicyContract	Design-by-Contract decorator for the ComponentLayoutPolicy-interface.
EdgeRoutingPolicyContract	Design-by-Contract decorator for the EdgeRoutingPolicy-interface.
GraphLayoutAlgContract	Design-by-Contract decorator for the GraphLayoutAlg-interface.
NodeOrderingPolicyContract	Design-by-Contract decorator for the NodeOrderingPolicy-interface.
NodePositioningPolicyContract	Design-by-Contract decorator for the NodePositioningPolicy-interface.
NodeRankingPolicyContract	Design-by-Contract decorator for the NodeRankingPolicy-interface.

Package suvi.alg.contracts Description

Design-by-Contract [Meyer1997] decorators [Gamma1995] for the algorithm interfaces.

The intention behind Design-by-Contract as described in [Meyer1997] is to specify the contracts between software entities in the form of executable assertions such as preconditions, postconditions and invariants. The Eiffel programming language directly supports Design-by-Contract.

Using Design-by-Contract, it is theoretically possible to prove that a program will never give an incorrect result (it will instead produce an assertion violation). In practise, however, the Design-by-Contract assertions in most programs are not designed rigorously enough to prove that the program only produces correct results. This does not mean that Design-by-Contract would be useless. It can be an effective way to quicly uncover many kinds of programming errors.

The Java language does not directly support Design-by-Contract, but by using the Decorator [Gamma1995] pattern to attach contract checking responsibilities to objects dynamically, we can achieve certain benefits that are similar to the benefits offered by direct language support. In particular, the contract checking decorators allow the shared assertions to be expressed just once. The decorators also make it possible to selectively turn contract checking on and off based on performance issues. These are not small benefits. It is not uncommon to see programs, written in languages that do not support Design-by-Contract, littered with repeated assertions that can not easily be selectively turned on and off.

Note that the intention of Design-by-Contract assertions is to uncover programming errors. This can be more formally described by the following principle: If a program is correct, then the observable behavior of the program will not be changed by deletion of all the Design-by-Contract assertions in the program. You should not interpret this as a suggestion to assume that the Design-by-Contract assertions in your program are sufficient to prove that the program is correct and to remove the assertions when the program is released.