BON Business Object Notation and/or design by contract for Python?

[Kurt B. Kaiser]

"Brad Clements" <bkc at Murkworks.com> writes:

> Has anyone examined BON (Business Object Notation)

I bought a copy of the book years ago and read through it fairly carefully.
It's pretty interesting.

BON was an unfortunate name  :-)

> http://www.bon-method.com/index_normal.htm (sorry frames)? This book
> was published in 1996 and is out of print, but the full text is
> available at the website in PDF format. Also there's a Visio tool on
> the site for doing BON layout. There's also a text only version of
> BON specification
>
> I'm especially interested in the "two way" aspect of BON and it's relative
> open-ness compared to UML.

I've never been a UML fan.  BON looked better.

Reverse engineering is essential to avoid having the documentation
decouple from the code.  Rational Rose has "two-way" UML, IIRC.

> Has anyone tried BON? (on a Python project or not)

ISE "implemented" BON, but it was a terrible job.  Last time I looked,
it was very buggy, the demo crashed all the time, and only implemented
the static part of BON.  That was 2 - 3 years ago, I haven't checked
back.  It's /gotta/ be better by now, but a real implementation has to
include the dynamic part :-)

http://archive.eiffel.com/products/bon.html

BON now appears to be part of EiffelStudio, but only in the $5000 version.
It doesn't look like I'm going to be able to update my opinion  :-)

http://www.eiffel.com/products/studio52/feature_comp.html

> BON supports invariants, which leads to design by contract. (I haven't done
> any design by contract yet)

DBC is quite interesting.  Most of the examples I've seen use it
incorrectly, IMHO.  They essentially end up writing the code twice,
once in the precondition/postcondition, and once in the body of the
method.

-- 
KBK