Bon Vs Uml

BertrandMeyer champions BusinessObjectNotation (BON).

MartinFowler et al prefer UnifiedModelingLanguage (UML).

Discuss...

I'm not objecting to new ideas - don't get me wrong. I'm objecting to the presentation of very old ideas (classes, attributes, methods, interfaces and inheritance...) in yet another notation that people have to learn. The notation shouldn't even be important - I don't really want to have arguments about whether we draw clouds, rectangles or ovals. If most people draw classes as rectangles, I can live with that. The less time you spend cooking up a proprietary notation, the more time you have to chase new, refreshing ideas.

If you view Eiffel as a notation (as does Dr. Meyer), it precedes UML by quite a few years. Secondly, BON was perceived and developed in the early 90's (I saw a presentation by J.M.Nerson in '92), also preceding UML by some years. Thirdly, BON lends itself a lot more towards keeping things simple with few concepts and not many diagrams to go with those concepts, than does UML which IMNSHO looks more like the PL/1 of methods than anything else. How so? By including almost every modelling concept on this planet and not doing a good job of it either. Perhaps UML would benefit from having the principles of XP applied to it? As for proprietariness, UML is just as proprietary as BON or OPEN or RDD or any other method/notation you care to mention. What I really resist is being forced into this huge patchwork by marketing forces. I've read Martin Fowlers UML book and he's done a good job, but I had to put in a lot more effort understanding all the odd subtleties of UML, than I had to understand BON. To me simplicity is the ultimate goal (as it is in XP). UML is as far away from that goal as Microsoft is from writing a stable operating system :-) -- EirikMangseth

I prefer the relative simplicity and coherence of the BON too. Given the way the OMG works I can't see how UML could have avoided becoming an "everything but the kitchen sink" notation. My problem with BON, is simply that it's another, different graphical notation - something that should be easy to remedy. (... and I'm not suggesting that BON should have a sprawling meta-metamodel.) It's hardly surprising the UML is huge - just look at all the different uses that it's supposed to have - the union of a rather large set of ideas. Nevertheless, the UML has done a lot of good by reducing the proliferation of different notations... (I really like what you said about "...resist is being forced into this huge patchwork by marketing forces...".)

The algebraic specification community has suffered similarly from proliferation of specification languages. Each little research group can't afford to invest in their languages and tools on the same scale as the Z community. Individually, there's a lot of little features and enhancements in each of these algebraic languages and tools. Put them together and you have the promise of interoperable tools. The cost of this interoperability is a patchwork of inconsistent language features.

If we take your argument to the extreme (no pun intended), then ideally it would be sufficient to have only one programming language at hand, so to avoid the "proliferation of notations". Problem is that notation is syntax and the far more interesting thing is the underlying semantics. E.g. BON comes with a well defined grammar, so that every diagram can be specified textually as well as diagrammatically. So text and/or graphics are just presentations of the underlying model. Does UML have such a well defined grammar. If so, I could use BON, you could use UML and we could both exchange models. That's the level of interoperability you want, not that everybody has to draw rectangles, bubbles or whatever is the latest fad. -- EirikMangseth

Just about any argument taken to its extreme sounds silly. I agree with you about the syntax-semantics divide. What happens when you want to teach Java to a roomful of people, some of whom have read the old books on OMT, BON, Shlaer-Mellor ... [and so on]? You have code, and you want to summarize in on a class diagram. Do I draw 3 semantically identical diagrams in 3 notations, or do we all learn yet another syntax? I'm not saying its perfect, but its more productive than continually learning new ways to draw classes...

Agreeing on a common notation forces people to decide what it means. Just look at what the growing body of literature about formalizing parts of the UML. There are critics and numerous different interpretations. Now at least it's easier to discuss them.

You can't compare UML and BON as methods: UML is a family of languages and BON (regardless of its name) is a method. (It's clear from the Walden and Nerson book that BON is a method.) I don't see why BON can't just use a subset of the UML notation. That wouldn't mean adopting all the UML concepts.

Although his style is quite extreme, Bertrand Meyer is very right about certain aspects of UML. It's way too complicated. UML-diagrams have a tendency to look like abstract works of art, which, although perhaps artistically pleasing, do not add to the understanding of the software (to be) developed. I have been joking around with colleagues that UML might be the perfect tool to obscure any understanding of a design(see TwoWaysToDesign for more on this - anon). Sadly enough, this might be all too true.

With Rational Rose and similar programs, it is very easy to come up with diagrams that serve only to baffle a casual viewer (like a client). Sure, the BON-method could use a subset of UML for its notation, like any other developer is very likely to use subsets to avoid that the diagrams become an intangible mess. The thing is though that only a limited subset of UML is broadly applicable (boxes representing classes and lines representing relationships). Also, the class diagrams indeed resemble entity-relationship diagrams too much. THAT much actually, that I once experienced that a whole team of developers used them as such.

Meyer also objects against Use Cases and I agree with him. Within Jacobson's method (OOSE) they might have had a proper use, as for deriving Ideal Object Models and so forth. Within UML though their use is obscure to say the least. Too often I have seen how Use Cases get used for functional decomposition. This renders any effort to try to implement a system in a proper object-oriented way totally useless. It's not that Use Cases are bad in themselves, but people simply often don't understand them. Why they are included in a supposedly object-oriented notation is beyond me.

-- RichardSmol

I have a challenge for BertrandMeyer:

Create a single, small, internally consistent graphical modelling language. You must ensure that most major industrial players support this standard (otherwise of course, it won't be a standard). The language should be usable for OOA, OOD, OOP, requirements capture, conceptual modelling and component-based design. It should have a clean formal semantics and yet shouldn't alienate any major programming language cultures.

Your second requirement, "must ensure that most major industrial players support this standard", defines yourself the win, since only existing standards can meet this requirement. I suggest dropping it; the rest could in theory be met in reality but requiring support in advance is a hurdle nobody can jump. Your challenge would then have some degree of validity.

Not gonna happen. Of course, I look forward to being proved wrong.

Why just challenge BertrandMeyer? Why not Schlaer-Mellor, the Tres Amigos, Peter Coad, etc.? -- EirikMangseth

I am tired of shape examples anyhow. The application to non-geometric issues is suspect.

I've just worked out what's at the root of all this: the RightThing. I'd prefer WorseIsBetter.

No, the root of all this is "all singing, all dancing" software/methods (e.g. like UML) that tries to satisfy every imaginable whim there is :-) Quite contrary to the spirit of XP, me thinks. -- EirikMangseth