Business Object Notation

CategoryMethodology:

Applying Object-Oriented Analysis and Design, Jean-Marc Nerson, Communications of the ACM, vol 35, no.9, Sept. 1992, pages 63-74.

and SeamlessObjectOrientedSoftwareArchitecture (ISBN 0-13-031303-3 )

BertrandMeyer has this spin on it: http://www.eiffel.com/products/bon.html

Main emphases:

Seamlessness
Reversibility
Software Contracting (aka DesignByContract)

Despite having the word "notation", it is a notation and a method.

See...

"An introduction to BON." (A really nice summary.)

  http://www.elj.com/eiffel/rp/bon-intro.pdf   (dead link) try
  http://www.cse.yorku.ca/~paige/Bon/bon.html

A Comparison of the Business Object Notation and the Unified Modeling Language. (Another introduction to BON, with comparisons to UML.)

http://www.cs.yorku.ca/techreports/1999/CS-1999-03.html

A very brief overview: (Ovals for classes. More detail in a class than UML. Can be done in text, in addition to 2D graphics.)

http://www.elj.com/elj/v1/n2/bm/bon/

A note on using BON -- the sequence of steps. (BON groups classes into "clusters.")

http://www.cs.usask.ca/homepages/grads/moa135/856/OO/node4.html

Based on reading "a Comparison of the Business Object Notation and the Unified Modeling Language" (referenced above)...

Being "reversable" and "seamless" focuses the notation on ReverseEngineering of existing code: They're arguing that anything not automatically derivable from the source code should not allowed be in the modeling language. Their argument would be correct if the only way to do design was to reverse engineer existing code. But in real systems there can be substantial practical benefit to having a way to express concepts that are abstract, even if they map into similar language constructs as other concepts.

For example, BON forbids one-to-one relationships because the static class definition that supports them is indistinguishable from that for a one-to-many. One may as well forbid C "for" loops because a "while" loop to do the same work will produce the same machine code.

The fact that one cannot easily and automatically reverse-engineer designer intent from source code is not an adequate reason to forbid the designer from having intent. -- JeffGrigg

(...shades of TheSourceCodeIsTheDesign. ;-)

Now for the nit-picking:

See figure 5 on page 15 for a sample BON "object communication diagram, with scenario box," and figure 6 on page 16 for a comparison of a UML collaboration diagram with a BON communication diagram (with scenario box). I find the UML diagram simpler, more expressive, and easier to read; the opposite of their conclusion. The BON diagrams require too much manual cross-referencing between graphical and textual documents to figure out what's going on.

For all their criticism of state machines (as not being automatically reverse-engineerable from source code), section 3.3.1 (end of page 16) recommends that you use UML state transition diagrams (or something similar) if you want to model that kind of behavior. -- JeffGrigg

I don't see how people can compare BON and UML since BON is a methodology and UML is a family of modelling languages.

BON might have started life as a notation for Eiffel programmers but any serious reader of the BON book will recognise that the BON book has a strong emphasis on process. The BON book contains charts showing the dependencies between what developers must do.

I can't see any reason why BON can't be performed using UML. (We can easily use a limited subset of UML and adopt stereotypes and tagged values for BON-specific constructs.)