[gme-users] RE: [udm-users] BON2 vs. UDM

[Akos Ledeczi]

You may not be surprised that I have some problems with
the emails below :)

First of all the whole premise is false in my view. It is
like saying let's do away with C++ and only use Java. Death
to all C++ programmers!

It is simple: if you do not like/want to use BON2, then don't.

Now, some more technical points. BON2 is GME-specific, UDM
is a generic tool. So, there are GME-specific things
that you can do with BON2, that you cannot do with UDM.

For example, you can write add-ons with BON2. YOu can have
access to editing events. You have access to the gme registry
of objects. Finally, BON2 uses on-demand instantiation of
objects. The BON-extender interpreter gives you control on
how you want to have your API generated. It also parses
existing interpreters, so that user code is preserved.
Furthermore, it uses the GME meta-model, not an automatically
translated one, so you do not have to deal with the "hacks"
the translator does for you. And what it does not do (see
Adi's very short "in favor of BON2" points :)

That's all folks,
Akos



Aditya Agrawal wrote:

> -----Original Message-----
> From: Abdullah Sowayan
> Sent: Friday, April 09, 2004 3:43 PM
> To: udm-users; gme-users
> Subject: [udm-users] BON2 vs. UDM
>
> Other than supporting current interpreters, what is the economical 
> justification for maintaining two separate model traversal APIs (BON2 
> and UDM). Is there something that BON2 offers that UDM doesn’t? If so, 
> can’t similar features be incorporated into UDM thus we’d be focusing 
> our effort in a single unified model traversal technology?
>
> [Adi]
>
> This is a good point that Abdullah has raised. I don’t know why the 
> two efforts are continuing simultaneously but I can point out the 
> positive and negative points of each interface as per my knowledgeJ.
>
> Places where UDM scores over BON
>
>    1. If you want to add/delete some model elements temporarily and
>       then run the transformation: E.g. GME’s metamodeling interface
>       has multiple sheets and ObjectProxy’s while from the
>       meta-interpreter point of view it should be one single sheet
>       with a monolithic metamodel. One way to implement this would be
>       a preprocessing step that converts multiple sheets into one
>       sheet and there second step would be the meta-interpreter. To
>       implement such things using BON a set of temporary data
>       structures are created and populated to form this information.
>    2. Merging two interpreter written for the same paradigm: This is
>       based on another problem I faced with BON. There were two
>       interpreters written for the same paradigm called “MILAN”. Later
>       on the requirements of the project chaged such that my
>       interpreter needed to call some functions written in the other
>       interpreter. This however was not possible because both the
>       interpreters had our own customization of the CBuildel classes
>       and thus the two interpreter codes could not be compiled together.
>    3. Cannot make a command line utility of the BON interpreter: BON
>       interface can only be used to write GME interpreters. The same
>       code cannot be used to produce an equivalent command line
>       utility which becomes very important for automation of tool chains.
>    4. Two BON interfaces cannot be used at the same time: If I want to
>       traverse one GME model and produce another that belongs to a
>       different paradigm I don’t think BON allows you to create two
>       BON based projects at the same time. For these cases you have to
>       use the COM interface on the target end. I may be wrong about
>       this though.
>    5. BON by default is paradigm specific: The lack of paradigm
>       specific API for BON missing for some. Now I hear that it has
>       been added in BON2
>
> UDM on the other hand can seamlessly tackle all the above mentioned 
> issues. UDM based data networks can be copied with one API command and 
> you can have any number of projects opened and manipulated at the same 
> time. We usually have the same code used for a GME interpreter, 
> command line tool and also make it a library for other interpreter to 
> call. It provides an easy to use paradigm specific API with complete 
> read and COMPLETE write support. The biggest advantage of UDM is that 
> it is not restricted to only the mga format. The same code can be used 
> on a paradigm specific gme independent XML file which can be used as a 
> way to interchange with other tools.
>
> Places where BON scores over UDM
>
>    1. Reference ports: Currently UDM is not able to provide the user
>       with the information about which reference port a particular
>       connection port is associated with.
>    2. Implementation and Interface Inheritance and equivalence: The
>       MetaGME2UML interpreter currently doesn’t not support Interface
>       and implementation inheritance and equivalence.
>
> I agree with Abdullah that one API for traversing the models will help 
> every one around.
>
> Thanks,
>
> Adi
>
>------------------------------------------------------------------------
>
>_______________________________________________
>gme-users mailing list
>gme-users at list.isis.vanderbilt.edu
>http://list.isis.vanderbilt.edu/mailman/listinfo/gme-users
>  
>