RE: [mdr-users] Clustering extents managed by non-MDR repositories

Hi Pieter,

What level of diagramming support do you require from a Magic Draw
integration, how about XMI in conjunction with UML 2.0 Diagram
Interchange?

I'm going to be working on a basic transformation from Magic Draw native
format to UML 2.0 Diagram Interchange
http://www.omg.org/cgi-bin/doc?ptc/2005-06-04 (via XMI), pretty much
just capturing the model element usage and linkage (including linkage
type) on diagrams, with some positional information for a regeneration
of a basic class diagram in SVG (which some work has already been done
http://uml2svg.sourceforge.net/). Be aware that UML 2.0 Diagram
Interchange is a general metamodel and can and has been used in
conjunction with other metamodels such as UML 1.4, I do have a MOF 1.4
XMI version that I can contribute with a semantic bridge back to
MOF::Element (in our case Reflective:RefObject).

I think the same approach would work with MDR, possibly without a UML
2.0 transformation as I believe the metamodels between MDR and Magic
Draw are compatible via XMI support in MDR (I believe from memory) or
using the existing UML 1.4 support. If there's some way we can
collaborate on this prototype, I would be interested. I agree there is a
lot of effort involved in faithfully reproducing Magic Draw diagrams in
UML 2.0 Diagram Interchange, but it's not always the case that the full
diagram information is required in the repository.

I have considered other designs for an integration however at the moment
this is my best candidate for our immediate use cases.

Nick.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Pieter Van Gorp
Sent: 16 February 2006 20:48
To: [email protected]
Subject: Re: [mdr-users] Clustering extents managed by non-MDR
repositories

Hi again,
> however the internals of MDR may rely on some lookups of objects by=20
> MOFID which will not work if the object is not managed by MDR.
Do you mean that the MOFID is used to perform a lookup in the storage
system directly?  If so, we're indeed in reasonably deep trouble.

Perhaps Petr can provide some insight on the lookup/storage system?=20
We're convinced that the JMI standard approach we're trying to implement
is still the simplest and best performing approach. Writing code that
copies the contents of the MagicDraw repository would really lock us in
since MagicDraw does not story diagram info (symbols) in a MOF compliant
manner and a loss of diagram info is unacceptable for our project.
Perhaps there's even another possible architecture: we could generate
wrappers for model elements such that MDR thinks he manages the UML
model.  The wrappers would however delegate any transformation call to
the MagicDraw repository... Sounds complex and a lot of work to me...

Therefore, thanks a lot already for your info but we'd still like to
learn some more internals of the lookup/storage system before we give up
the cross-repository clustering architecture... anyone?

Or perhaps we're overlooking yet another integration approach that beats
the ones we've talked about in simplicity?

Thanks for your insights,
Pieter.

On 2/16/06, Martin Matula <[email protected]> wrote:
> I think it will not be that simple. For all relationships between=20
> objects (not just for clustering) MOFID object is used instead of the=20
> actual object. MDR is then able to retrieve the object based on a
MOFID.
> refMofId() returns String, not MOFID object. You can create a MOFID=20
> object from a String, however the internals of MDR may rely on some=20
> lookups of objects by MOFID which will not work if the object is not=20
> managed by MDR.
> In the light of this, I don't know this for sure, but I think the=20
> simple solution you propose will not work.
> Martin
>
> Pieter Van Gorp wrote:
> > Hi again, we've digged into the MDR sources a bit deeper and here's=20
> > our current understanding:
> >
> > Clustering one extent in the other is possible as soon as MDR can=20
> > retrieve MOF IDs from the clustered elements.  Currently, only=20
> > clustering of extents managed by MDR is possible due to the=20
> > following
> > line:
> > Object result =3D
> > packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate
> > ().getMofId(),
> > pkg);
> >
> > More specifically, the MOF ID is retrieved through the delegate,=20
> > which is MDR specific.  Would it be sufficient if we added a=20
> > type-check for finding model elements managed by other repositories?

> > We could check whether pkg is an instance of BaseObjectHandler and=20
> > if it is not we could query for MOF IDs by means of refMofId()=20
> > instead of going over the delegate...
> >
> > Perhaps there's more to it, but this already seems like a feasible=20
> > plan.  If you would acknowledge that there will not be too much=20
> > extra code to be changed, we could give it a try.  Any changes can=20
> > be integrated into the latest official MDR source later.
> >
> > Thanks again,
> > Pieter.
> >
> > On 2/16/06, Pieter Van Gorp <[email protected]> wrote:
> >
> >>Would we open Pandora's box by trying to pass our own implementation

> >>of RefPackage that also implements BaseObjectHandler (and wraps the=20
> >>MagicDraw model elements) when creating an extent?
> >>
> >>This seems feasible when we only have to override a couple of=20
> >>methods (like refMetaObject())... Do you know of other assumptions=20
> >>about RefPackage in this context?
> >>
> >>Thanks a lot in advance,
> >>Pieter
> >>
> >>On 2/15/06, Martin Matula <[email protected]> wrote:
> >>
> >>>Hi Pieter,
> >>>this is a limitation of MDR.
> >>>Martin
> >>>
> >>>Pieter Van Gorp wrote:
> >>>
> >>>>Hi all,
> >>>>is it possible to cluster extents managed by non-MDR repositories?
> >>>>
> >>>>More specifically, we're trying to create a cluster of the UML=20
> >>>>extent in MagicDraw 10.  If you look at the interfaces of=20
> >>>>MagicDraw and MDR, everything seems fine.  However, we've just=20
> >>>>encountered a class cast exception on line 752 of
NBMDRepositoryImpl, which contains:
> >>>>Object result =3D
> >>>>packages.put(((BaseObjectHandler)pkg.refMetaObject())._getDelegate
> >>>>().getMofId(),
> >>>>pkg);
> >>>>
> >>>>This raises:
> >>>>java.lang.ClassCastException:
com.io_software.catools.tas.mof.model.PackageImpl
> >>>>      at
org.netbeans.mdr.NBMDRepositoryImpl.collectPackageInstances(NBMDReposito
ryImpl.java:752)
> >>>>      at
org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java
:466)
> >>>>      at
org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java
:292)
> >>>>      at=20
> >>>>org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:
> >>>>196)
> >>>>
> >>>>Reading the source, it seems like our MDR/MagicDraw integration=20
> >>>>will not work since  the MagicDraw classes do not implement=20
> >>>>internal MDR classes like BaseObjectHandler.  Is this a=20
> >>>>fundamental limitation of MDR or are we overlooking something?
> >>>>
> >>>>Note that we've passed MagicDraw's repository as the single=20
> >>>>element of the RefPackage array argument to createExtent.  On a=20
> >>>>type level, that's OK but it's at the dynamic type cast that
things go wrong...
> >>>>
> >>>>Thanks in advance,
> >>>>--
> >>>>Pieter Van Gorp
> >>>>       Teaching and Research Assistant
> >>>>       FOrmal Techniques in Software engineering (FOTS)
> >>>>       University of Antwerp
> >>>>       Middelheimlaan 1
> >>>>       2020 Antwerpen - Belgium
> >>>>       Office: G.304
> >>>>       Phone: +32 3 265 38 71
> >>>>       Fax: +32 3 265 37 77
> >>>>       http://www.fots.ua.ac.be/~pvgorp/research/
> >>>>       http://motmot.sourceforge.net/
> >>>>
> >>>>``A man has to live with himself, and he should see to it that he=20
> >>>>always has good company [Charles Evans Hughes]''
> >>>
>