(ref.doc)kim 030993

(Posting in comp.object. Reformatted)
[...]

BON promotes the following ideas:

1. Seamlessness through pure object-oriented concepts.
   Most other published O-O methods are hybrids which include ERD
   diagrams, state/transition diagrams or data flow diagrams as part
   of their standard notation.  This breaks the seamlessness, keeps
   the barrier between specification and implementation, and prevents
   large scale reuse.  (Most O-O methods today hardly even mention
   polymorphism and dynamic binding, but only concentrate on the
   simple encapsulation part.  This is not enough.)

2. Software contracting.
   A software components industry requires well specified and correct
   products.  We believe the Design by Contract paradigm invented by
   Bertrand Meyer is absolutely crucial for increasing software
   quality and changing the general attitude of software designers and
   programmers.  BON emphasizes the contracting part and includes
   special notation for it.  Again, other published methods at best
   mention specification by contracting, but do not give it the
   attention it deserves.

3. Typed interface descriptions.
   Static typing is not only a means to generate more efficient code
   or catch certain types of implementation errors.  It is just as
   much an aid for classification and precise specification.  Instead
   of relying on ambiguous naming conventions, important information
   can be spelled out exactly.  Also, any kind of formal specification
   becomes nearly impossible to use with an untyped notation.

4. Scalability.  
   To be useful in real-life situations a notation must scale up from
   the simplified text book examples.  We need views on different
   levels of detail, and with different aspects emphasized.  BON uses
   recursive clustering to achieve a scalable notation; all graphical
   elements used have both an abstracted and an expanded form. By
   selectively abstracting or expanding various parts in a system,
   many different views can be created.

5. Simplicity and space economy.
   BON takes a minimalistic view both regarding the number of
   notational elements and the space they occupy.  For example, we
   only use two basic relations: inheritance and client/supplier (the
   latter with variants for aggregation and shared resources). These
   relations are then generalized to also cover relations between
   clusters and classes/clusters (with clearly specified semantics).
   To get any kind of overview, a user needs to be able to see more
   than just a few classes on one page.

6. Basis for intelligent case tools.
   We believe there is a potential for much more automatic support in
   object-oriented case tools (and also a much greater need, because
   of the higher compression of information in O-O systems).  With
   typing and contracts, tools can be made much more intelligent,
   whereas with untyped notations things are pretty much limited to
   pure textual browsing, since there is simply not enough semantic
   content in the descriptions.

BON keeps the static and dynamic aspects of modeling separate.
Instead of using state/transition diagrams for the dynamic part,
(which in most cases has no natural mapping to and from the eventual
implementation anyway), the BON dynamic notation is designed to
describe scenarios with message passing between objects and thus serve
as a complement to the static model both for finding classes and for
checking that a proposed static architecture will indeed be able to
fulfill the required behavior.

>
>  (I have heard Nerson say that "BON" is not a good name, but he can't
>  think of a better one offhand).

Well, we realized that it was not the name BON that was bad, it was
the interpretation, so since February 1993 the BON acronym instead
stands for "Business Object Notation".

>Actually, to call it a "methodology" is not really correct.  Its a
>notation with a bunch of rules attached, some of which can be enforced
>by a tool, some of which cannot but should still be observed.

This may have been the case several years ago, but is certainly not
true today.  BON is a fully documented method just as much as any of
the others out there.  I just spent the better part of the summer
writing a thorough description of the BON model and notation, and the
steps and activities of the BON method.

Whether the text will be convincing enough to place BON among the
major players in the OOA/OOD field is of course always an open
question.  We certainly hope so, and I look forward to hearing your
opinion when you have read the book.

>							  Most
>of its constructs map directly to Eiffel syntax, and its a good
>notation for documenting an Eiffel design.

It is true that the notation maps easily to Eiffel, but this is
because Eiffel directly supports the major modeling concepts of BON:
classes as abstract data types, strong typing, genericity, abstract
classes, multiple inheritance, and the contracting model.

The syntax is not important here. (We also use something similar to
Eiffel in our textual notation which can be used by case tool
implementors or in non-graphical contexts as an alternative to the
graphical notation.)

However, BON is language independent, and may also be mapped to
e.g. C++. (Of course, if the implementation language does not support
certain of the basic concepts, such as multiple inheritance and
genericity, the BON user would need to avoid using these in the
analysis and design model.)

The book, whose preliminary title is "Seamless Architecturing of
Object-Oriented Software" (by Jean-Marc Nerson and Kim Walden), will
be published by Prentice-Hall hopefully around Christmas or early next
year.

We are planning to use the word "Architecturing" in the title to
signify the process of creating a software architecture.  I have a
feeling that the word "architecture" is sometimes used as a verb, but
I cannot find any support for this in avaliable dictionaries.

I would appreciate if some native English speaking computer
professionals (in both Europe and the USA) could email me an opinion
about this. Would "Architecturing" _sound_ right (perhaps stretching
normal usage a bit, but in a natural direction) or would it just sound
silly?


Best regards,

Kim Walden
Enea Data AB, Sweden
[email protected]