• EiffelStudio BON diagram tool

BON is useful for class diagrams, especially for Design by Contract. However, you should also develop good working skills in UML.

Getting Started with UML

The EiffelStudio IDE can display class diagrams in both BON and UML style. Try it out.

BON (Business Object Notation). BON (like UML) is a method for the analysis and design of object-oriented software. BON provides a textual and graphical notation for modelling the static and dynamic structure of OO software:

• BON has strong support for providing precise specifications of re-usable, industrial strength components via Design by Contract (preconditions, postconditions and class invariants), which includes subcontracting via the inheritance relationship. See example below.
• It supports a seamless method for turning software construction from specification to implementation into a single continuous process.
• It supports reversibility which is the ability to go back from implementation to specification.

BON is described in depth in the book Seamless Object-Oriented Software Architecture, Prentice Hall, 1994, by Kim Waldén and Jean-Marc Nerson. The textbook is now out of print but available from the BON website as a pdf.

The graphical shapes of BON can be drawn using Microsoft Office Visio (available on Windows workstations in the Prism Lab or for your Laptop via Dreamspark).

• Using the BON Visio Stencil (Visio 2013 and later), we can draw BON class and dynamic diagrams. A BON/Visio manual is available describing how to use Visio for the BON diagrams.
• This is the Stencil for stencil for Visio2010.

Here is an example of a contracted class CITIZEN using the BON notation:

Although BON may be used to design software to be implemented in any OO language, it shines when used with Eiffel. Here is a quote from Bertand Meyer:

The worldview underlying the Eiffel method is almost the reverse: treating the whole process of software development as a continuum; unifying the concepts behind activities such as requirements, specification, design, implementation, verification, maintenance and evolution; and working to resolve the remaining differences, rather than magnifying them.

Anyone who has worked in both specification and programming knows how similar the issues are. Formal specification languages look remarkably like programming languages; to be usable for significant applications they must meet the same challenges: defining a coherent type system, supporting abstraction, providing good syntax (clear to human readers and parsable by tools), specifying the semantics, offering modular structures, allowing evolution while ensuring compatibility.

The same kinds of ideas, such as an object-oriented structure, help on both sides. Eiffel as a language is the notation that attempts to support this seamless, continuous process, providing tools to express both abstract specifications and detailed implementations. One of the principal arguments for this approach is that it supports change and reuse. If everything could be fixed from the start, maybe it could be acceptable to switch notations between specification and implementation. But in practice specifications change and programs change, and a seamless process relying on a single notation makes it possible to go back and forth between levels of abstraction without having to perform repeated translations between levels.

(This problem of change is, in my experience, the biggest obstacle to refinement-based approaches. I have never seen a convincing description of how one can accommodate specification changes in such a framework without repeating the whole process. Inheritance, by the way, addresses this matter much better.)”

In BON diagrams, use mathematical notation to express contracts. See the BON textbook for more examples.