[ebon-discuss] Re: BON diagrams - Static *and* Dynamic

[Joseph R. K. <ki...@ac...>]

Hi all,

Quality BON support for Eiffel, as well as other languages and systems, is=20
a subject near and dear to my heart.

I have been working on-and-off for some time on the EBON tool suite.  EBON=20
is currently a lexer, parser, and intermediate representation of an=20
extended version of BON.  For more information, please see=20
<http://sourceforge.net/projects/ebon/> for more information.  I am=20
attempting to have a first release finished in time for the International=20
Eiffel Programming Contest deadline this Halloween.

The real issue with static vs. dynamic descriptions of systems is that, in=20
general, static views have a well-understood semantics and can be=20
automatically extracted and kept in sync with a system's source code, as=20
mentioned by Rapha=EBl in another email.

On the other hand, for nearly all specification languages, dynamic diagrams =

do *not* have a well-understood semantics, and thus their interpretation=20
(informally by the people using the model, i.e., programmers, designers,=20
and managers, as well as formally by the systems manipulating the model,=20
i.e., compilers, CASE tools, and theorem proving environments) are=20
ambiguous, are not automatically extractable, nor can be kept in sync with=20
a system.

The standard example (and easy target) for these criticisms is UML.  UML is =

now on its fourth major revision, is nearing (over?) a 1000 pages of=20
"specification", 100,000s of pages of technical texts, and has legions of=20
expensive consultants and tools to help explain what each little box or=20
arrow means.

BON is one of those rare specification languages that *does* have a=20
well-understood, though incompletely specified, dynamic semantics.  I=20
suspect it is because there are still some ambiguities in BON's dynamic=20
semantics, and because supporting a dynamic view of a system is simply=20
*hard* to do, that EiffelStudio does not support BON dynamic diagrams as of =

yet.  My plan is to fully support them in EBON and I have been working on a =

formal semantic of EBON for some time to achieve this goal.

BON's dynamic diagrams let one describe the important scenarios of your=20
system (user-level use-cases, internal and external testing scenarios,=20
important sequences of events for particular functionality, etc.).  They=20
also provide a refinement structure for client interactions via labeled=20
actions and call traces.  Finally, they provide basic object structuring=20
notions such as object groups and stacks.

Unfortunately, until a quality tool supports the full BON notation (both=20
textual, like the EBON package, and graphical, like EiffelStudio), and=20
until such time that more quality examples of dynamic diagram use are=20
available, the utility of dynamic diagrams is extremely limited.

I highly suggest reading Walden and Nerson's "Seamless Object-Oriented=20
Software Architecture", available at <http://www.bon-method.com/>, for more =

information.

Best,
Joe Kiniry
---
Joseph R. Kiniry                    ID 78860581      ICQ 4344804
SOS Group, University of Nijmegen  http://www.cs.kun.nl/~kiniry/
KindSoftware, LLC                   http://www.kindsoftware.com/
Board Chair: NICE                    http://www.eiffel-nice.org/


> Message: 3
>    Date: Sat, 12 Jul 2003 11:09:47 -0400
>    From: "Mark Bruscke" <br...@ab...>
> Subject: BON diagrams - Static vs Dynamic
>
> Hi Colin (and anyone else who might comment),
>     Your remark:
>
>> > This is true, but the dynamic diagrams are the only useful ones.
>
> struck me as illuminating.  I wonder if you would flesh-out my
> understanding of your point of view.
>
>     From the applications I've worked on, I would have written ". . . the
> STATIC diagrams . . . ".  I've always worked on applications where the
> data in it's static state has been the dominant problem. If you could
> figure out the right data structures, writing the algorithms to perform
> the computations wasn't such a hard problem to solve and understand.
>
>     Nevertheless, I recognize that my experience is not broadly
> representative of the universe of application domains.  I think it's
> probably an accurate perception of most business applications, but there
> must  be many other domains where a static view is less useful than a
> dynamic view.
>
>     It seems to me that this debate is roughly analogous to a debate =
among
> mechanical draftsmen.  The standard is that you draw a top and a side and
> a face view of a 3-dimensional object (to be manufactured).  Now, if the
> object is a regular cube; then only one such view will suffice.  If it's
> an irregular cube (e.g., a shipping carton), then 2 views will suffice.
> But, if it is an irregular shaped object (e.g., a pylon for mounting an
> engine on a wing), then more than 3 views is probably required. Draftsmen
> might reasonably disagree as to how many views need to be drawn of an
> object with many irregular faces.
>
>     If this analogy is appropriate, then the project manager needs to
> size-up the application domain as being best represented by a static,
> dynamic, or some other view.  He might correctly judge that the static
> view is not only dominant, this single view will suffice.  In that case,
> BON's limitation is entirely - or at least largely - acceptable.  If a
> small part of the application domain is characterized by interesting
> dynamic behavior, then that small part might be diagrammed in, e.g.,
> Visio.  That's a tragedy, albeit a small one, because that Visio diagram
> has no hard link to the source (and, consequently, is vulnerable to being
> not maintained).
>
>     Conversely, if the dynamic view is dominant, then BON's limitation is
> truely unfortunate.  Most of one's diagrams will have to be drawn in =
Visio
> or some CASE tool with little or no integration with the Eiffel source.
>
>    If most of the "work" (i.e., the application domains that present
> themselves as candidate application development projects) are
> characterized by primarily interesting static complexity, then BON's
> class diagrams are the most important functionality to be provided.
> Perhaps dynamic diagrams deserve to be the second functionality to be
> provided.
>
>    However, if the work is about equally divided between application
> domains with interesting static and dynamic complexity, then BON's class
> diagrams solve only half the problem.
>
>    Am I on the right track here?  Any sense whether the "work" is
> predominatly characterized by static complexity?
>
>     Regards,
>      Mark
>
>>
>> ----- Original Message -----
>> From: "Colin Paul Adams" <co...@co...>
>> To: <ise...@ya...>
>> Sent: Wednesday, July 09, 2003 9:58 PM
>> Subject: Re: [ise_users] BON Diagrams
>>
>>
>> > >>>>> "Raphael" =3D=3D Rapha=EBl Simon [ES] <Rapha> writes:
>> >
>> >     Raphael> EiffelStudio only supports static diagrams. One of the
>> >     Raphael> reasons why EiffelStudio does not support dynamic
>> >     Raphael> diagrams is the lack of reverse engineering support that
>> >     Raphael> they would imply. So you could have diagrams describing
>> >     Raphael> certain behaviors and have the code do something
>> >     Raphael> different with no ways for the tool to check for these
>> >     Raphael> discrepancies. With static diagrams you are guaranteed
>> >     Raphael> that the diagrams and the code are always in sync.
>> >
>> > This is true, but the dynamic diagrams are the only useful ones.
>> > --
>> > Colin Paul Adams
>> > Preston Lancashire

> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 7
>    Date: 12 Jul 2003 21:43:31 +0100
>    From: Colin Paul Adams <co...@co...>
> Subject: Re: BON diagrams - Static vs Dynamic
>
>>>>>> "Mark" =3D=3D Mark Bruscke <br...@ab...> writes:
>
>     Mark> Hi Colin (and anyone else who might comment), Your remark:
>
>     >> > This is true, but the dynamic diagrams are the only useful
>     >> ones.
>
>     Mark> struck me as illuminating.  I wonder if you would flesh-out
>     Mark> my understanding of your point of view.
>
>     Mark>    Am I on the right track here?  Any sense whether the
>     Mark> "work" is predominatly characterized by static complexity?
>
> I just find it very easy to visualise inheritance hierarchies in my
> head, so I find the static diagrams of little use (at least, more
> trouble to untangle than is worth the effort).
>
> On the other hand, I find it difficult to work out how different
> clients are collaborating without a collaboration diagram (or
> something similar).
>
> Note that it's not a deficiency in BON - BON has these diagrams - just
> EiffelStudio doesn't implement them.
> --
> Colin Paul Adams
> Preston Lancashire
>

> ________________________________________________________________________
> ________________________________________________________________________
>
> Message: 9
>    Date: Sun, 13 Jul 2003 14:04:53 +1000
>    From: Peter Horan <pe...@de...>
> Subject: Re: BON diagrams - Static vs Dynamic
>
> Colin Paul Adams wrote:
>>
>> >>>>> "Mark" =3D=3D Mark Bruscke <br...@ab...> writes:
>>
>>     Mark> Hi Colin (and anyone else who might comment), Your remark:
>>
>>     >> > This is true, but the dynamic diagrams are the only useful
>>     >> ones.
>>
>>     Mark> struck me as illuminating.  I wonder if you would flesh-out
>>     Mark> my understanding of your point of view.
>>
>>     Mark>    Am I on the right track here?  Any sense whether the
>>     Mark> "work" is predominatly characterized by static complexity?
>>
>> I just find it very easy to visualise inheritance hierarchies in my
>> head, so I find the static diagrams of little use (at least, more
>> trouble to untangle than is worth the effort).
>>
>> On the other hand, I find it difficult to work out how different
>> clients are collaborating without a collaboration diagram (or
>> something similar).
>
> I find the static view good to assess (in)consistencies in the code.
>
> I would like a dynamic view which allowed one to see objects - that is a
> graphical mapping of the debug window in the IDE. In the IDE, it is
> shown as a tree. I would like to look at objects as nodes and references
> as arcs in a graph. I would like to pick an object and be able to
> specify how many links to traverse from it. I would also like to be able
> to show selected parameter values in the nodes. Effectively, this is a
> collaboration diagram created from the runtime snapshot.
>
> A lot of my design thinking starts from this object view which is mapped
> back to the static class view in order to create the code.
> --
> Peter Horan                     School of Information Technology
> pe...@de...             Deakin University
> +61-3-5227 1234 (Voice)         Geelong, Victoria 3217, AUSTRALIA
> +61-3-5227 2028 (FAX)           http://www.cm.deakin.edu.au/~peter
>
> -- The Eiffel guarantee: From specification to implementation
> -- (http://www.cetus-links.org/oo_eiffel.html)