ebon-discuss Mailing List for The Extended BON Toolsuite

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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)

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (4)	Sep (1)	Oct	Nov	Dec
2002	Jan (1)	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2003	Jan	Feb	Mar	Apr	May	Jun	Jul (1)	Aug	Sep	Oct	Nov	Dec

ebon-discuss Mailing List for The Extended BON Toolsuite

ebon-discuss — General discussion about the Extended BON toolsuite.