Clustering extents managed by non-MDR repositories

[Pieter Van Gorp-2]

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 extent
in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
everything seems fine.  However, we've just encountered a class cast
exception on line 752 of NBMDRepositoryImpl, which contains:
Object result =
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(NBMDRepositoryImpl.java:752)
        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
        at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)

Reading the source, it seems like our MDR/MagicDraw integration will
not work since  the MagicDraw classes do not implement internal MDR
classes like BaseObjectHandler.  Is this a fundamental limitation of
MDR or are we overlooking something?

Note that we've passed MagicDraw's repository as the single element of
the RefPackage array argument to createExtent.  On a 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: [phone]
       Fax: [phone]
       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
always has good company [Charles Evans Hughes]''

[Pieter Van Gorp-2]

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 extent
in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
everything seems fine.  However, we've just encountered a class cast
exception on line 752 of NBMDRepositoryImpl, which contains:
Object result =
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(NBMDRepositoryImpl.java:752)
        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
        at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
        at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)

Reading the source, it seems like our MDR/MagicDraw integration will
not work since  the MagicDraw classes do not implement internal MDR
classes like BaseObjectHandler.  Is this a fundamental limitation of
MDR or are we overlooking something?

Note that we've passed MagicDraw's repository as the single element of
the RefPackage array argument to createExtent.  On a 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: [phone]
       Fax: [phone]
       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
always has good company [Charles Evans Hughes]''

[Martin Matula]

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 extent
> in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
> everything seems fine.  However, we've just encountered a class cast
> exception on line 752 of NBMDRepositoryImpl, which contains:
> Object result =
> 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(NBMDRepositoryImpl.java:752)
> at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
> at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
> at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)
>
> Reading the source, it seems like our MDR/MagicDraw integration will
> not work since  the MagicDraw classes do not implement internal MDR
> classes like BaseObjectHandler.  Is this a fundamental limitation of
> MDR or are we overlooking something?
>
> Note that we've passed MagicDraw's repository as the single element of
> the RefPackage array argument to createExtent.  On a 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: [phone]
>        Fax: [phone]
>        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
> always has good company [Charles Evans Hughes]''

[Pieter Van Gorp-2]

Would we open Pandora's box by trying to pass our own implementation
of RefPackage that also implements BaseObjectHandler (and wraps the
MagicDraw model elements) when creating an extent?

This seems feasible when we only have to override a couple of methods
(like refMetaObject())... Do you know of other assumptions about
RefPackage in this context?

Thanks a lot in advance,
Pieter

On 2/15/06, Martin Matula <Martin.Matula@...> 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 extent
> > in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
> > everything seems fine.  However, we've just encountered a class cast
> > exception on line 752 of NBMDRepositoryImpl, which contains:
> > Object result =
> > 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(NBMDRepositoryImpl.java:752)
> >       at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
> >       at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
> >       at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)
> >
> > Reading the source, it seems like our MDR/MagicDraw integration will
> > not work since  the MagicDraw classes do not implement internal MDR
> > classes like BaseObjectHandler.  Is this a fundamental limitation of
> > MDR or are we overlooking something?
> >
> > Note that we've passed MagicDraw's repository as the single element of
> > the RefPackage array argument to createExtent.  On a 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: [phone]
> >        Fax: [phone]
> >        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
> > always has good company [Charles Evans Hughes]''
>

[Dimitrios Kolovos]

Hi,

Is it possible to retrieve the value of the corresponding xmi.id for a
RefObject using MDR? I have googled a lot but not found an answer.

Cheers,
Dimitrios

[Pieter Van Gorp-2]

Hi again, we've digged into the MDR sources a bit deeper and here's
our current understanding:

Clustering one extent in the other is possible as soon as MDR can
retrieve MOF IDs from the clustered elements.  Currently, only
clustering of extents managed by MDR is possible due to the following
line:
Object result =
packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate().getMofId(),
pkg);

More specifically, the MOF ID is retrieved through the delegate, which
is MDR specific.  Would it be sufficient if we added a type-check for
finding model elements managed by other repositories?  We could check
whether pkg is an instance of BaseObjectHandler and if it is not we
could query for MOF IDs by means of refMofId() instead of going over
the delegate...

Perhaps there's more to it, but this already seems like a feasible
plan.  If you would acknowledge that there will not be too much extra
code to be changed, we could give it a try.  Any changes can be
integrated into the latest official MDR source later.

Thanks again,
Pieter.

On 2/16/06, Pieter Van Gorp <pieter@...> wrote:

> Would we open Pandora's box by trying to pass our own implementation
> of RefPackage that also implements BaseObjectHandler (and wraps the
> MagicDraw model elements) when creating an extent?
>
> This seems feasible when we only have to override a couple of methods
> (like refMetaObject())... Do you know of other assumptions about
> RefPackage in this context?
>
> Thanks a lot in advance,
> Pieter
>
> On 2/15/06, Martin Matula <Martin.Matula@...> 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 extent
> > > in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
> > > everything seems fine.  However, we've just encountered a class cast
> > > exception on line 752 of NBMDRepositoryImpl, which contains:
> > > Object result =
> > > 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(NBMDRepositoryImpl.java:752)
> > >       at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
> > >       at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
> > >       at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)
> > >
> > > Reading the source, it seems like our MDR/MagicDraw integration will
> > > not work since  the MagicDraw classes do not implement internal MDR
> > > classes like BaseObjectHandler.  Is this a fundamental limitation of
> > > MDR or are we overlooking something?
> > >
> > > Note that we've passed MagicDraw's repository as the single element of
> > > the RefPackage array argument to createExtent.  On a 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: [phone]
> > >        Fax: [phone]
> > >        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
> > > always has good company [Charles Evans Hughes]''
> >
>

[Tom Morris]

> Is it possible to retrieve the value of the corresponding
> xmi.id for a
> RefObject using MDR? I have googled a lot but not found an answer.

RefBaseObject.refMofId() returns the value that will get serialized in the
xmi.id field.

Tom

[Martin Matula]

I think it will not be that simple. For all relationships between
objects (not just for clustering) MOFID object is used instead of the
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
object from a String, however the internals of MDR may rely on some
lookups of objects by MOFID which will not work if the object is not
managed by MDR.
In the light of this, I don't know this for sure, but I think the 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
> our current understanding:
>
> Clustering one extent in the other is possible as soon as MDR can
> retrieve MOF IDs from the clustered elements.  Currently, only
> clustering of extents managed by MDR is possible due to the following
> line:
> Object result =
> packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate().getMofId(),
> pkg);
>
> More specifically, the MOF ID is retrieved through the delegate, which
> is MDR specific.  Would it be sufficient if we added a type-check for
> finding model elements managed by other repositories?  We could check
> whether pkg is an instance of BaseObjectHandler and if it is not we
> could query for MOF IDs by means of refMofId() instead of going over
> the delegate...
>
> Perhaps there's more to it, but this already seems like a feasible
> plan.  If you would acknowledge that there will not be too much extra
> code to be changed, we could give it a try.  Any changes can be
> integrated into the latest official MDR source later.
>
> Thanks again,
> Pieter.
>
> On 2/16/06, Pieter Van Gorp <pieter@...> wrote:
>
>>Would we open Pandora's box by trying to pass our own implementation
>>of RefPackage that also implements BaseObjectHandler (and wraps the
>>MagicDraw model elements) when creating an extent?
>>
>>This seems feasible when we only have to override a couple of methods
>>(like refMetaObject())... Do you know of other assumptions about
>>RefPackage in this context?
>>
>>Thanks a lot in advance,
>>Pieter
>>
>>On 2/15/06, Martin Matula <Martin.Matula@...> 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 extent
>>>>in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
>>>>everything seems fine.  However, we've just encountered a class cast
>>>>exception on line 752 of NBMDRepositoryImpl, which contains:
>>>>Object result =
>>>>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(NBMDRepositoryImpl.java:752)
>>>>      at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
>>>>      at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
>>>>      at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)
>>>>
>>>>Reading the source, it seems like our MDR/MagicDraw integration will
>>>>not work since  the MagicDraw classes do not implement internal MDR
>>>>classes like BaseObjectHandler.  Is this a fundamental limitation of
>>>>MDR or are we overlooking something?
>>>>
>>>>Note that we've passed MagicDraw's repository as the single element of
>>>>the RefPackage array argument to createExtent.  On a 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: [phone]
>>>>       Fax: [phone]
>>>>       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
>>>>always has good company [Charles Evans Hughes]''
>>>

[Martin Matula]

Not true in general.
You can write your own XMIReferenceResolver and XMIReferenceProvider
where you can maintain mapping between the generated/read xmi.id and MOF ID.
Martin

Tom Morris wrote:
>>Is it possible to retrieve the value of the corresponding
>>xmi.id for a
>>RefObject using MDR? I have googled a lot but not found an answer.
>
>
> RefBaseObject.refMofId() returns the value that will get serialized in the
> xmi.id field.
>
> Tom

[Pieter Van Gorp-2]

Hi again,
> however the internals of MDR may rely on some
> lookups of objects by 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?
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 <Martin.Matula@...> wrote:

> I think it will not be that simple. For all relationships between
> objects (not just for clustering) MOFID object is used instead of the
> 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
> object from a String, however the internals of MDR may rely on some
> lookups of objects by MOFID which will not work if the object is not
> managed by MDR.
> In the light of this, I don't know this for sure, but I think the 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
> > our current understanding:
> >
> > Clustering one extent in the other is possible as soon as MDR can
> > retrieve MOF IDs from the clustered elements.  Currently, only
> > clustering of extents managed by MDR is possible due to the following
> > line:
> > Object result =
> > packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate().getMofId(),
> > pkg);
> >
> > More specifically, the MOF ID is retrieved through the delegate, which
> > is MDR specific.  Would it be sufficient if we added a type-check for
> > finding model elements managed by other repositories?  We could check
> > whether pkg is an instance of BaseObjectHandler and if it is not we
> > could query for MOF IDs by means of refMofId() instead of going over
> > the delegate...
> >
> > Perhaps there's more to it, but this already seems like a feasible
> > plan.  If you would acknowledge that there will not be too much extra
> > code to be changed, we could give it a try.  Any changes can be
> > integrated into the latest official MDR source later.
> >
> > Thanks again,
> > Pieter.
> >
> > On 2/16/06, Pieter Van Gorp <pieter@...> wrote:
> >
> >>Would we open Pandora's box by trying to pass our own implementation
> >>of RefPackage that also implements BaseObjectHandler (and wraps the
> >>MagicDraw model elements) when creating an extent?
> >>
> >>This seems feasible when we only have to override a couple of methods
> >>(like refMetaObject())... Do you know of other assumptions about
> >>RefPackage in this context?
> >>
> >>Thanks a lot in advance,
> >>Pieter
> >>
> >>On 2/15/06, Martin Matula <Martin.Matula@...> 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 extent
> >>>>in MagicDraw 10.  If you look at the interfaces of MagicDraw and MDR,
> >>>>everything seems fine.  However, we've just encountered a class cast
> >>>>exception on line 752 of NBMDRepositoryImpl, which contains:
> >>>>Object result =
> >>>>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(NBMDRepositoryImpl.java:752)
> >>>>      at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:466)
> >>>>      at org.netbeans.mdr.NBMDRepositoryImpl.createExtent(NBMDRepositoryImpl.java:292)
> >>>>      at org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:196)
> >>>>
> >>>>Reading the source, it seems like our MDR/MagicDraw integration will
> >>>>not work since  the MagicDraw classes do not implement internal MDR
> >>>>classes like BaseObjectHandler.  Is this a fundamental limitation of
> >>>>MDR or are we overlooking something?
> >>>>
> >>>>Note that we've passed MagicDraw's repository as the single element of
> >>>>the RefPackage array argument to createExtent.  On a 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: [phone]
> >>>>       Fax: [phone]
> >>>>       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
> >>>>always has good company [Charles Evans Hughes]''
> >>>
>

[Nick Dowler]

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: pietervangorp@... [mailto:pietervangorp@...] On Behalf
Of Pieter Van Gorp
Sent: 16 February 2006 20:48
To: users@...
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
> 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?
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 <Martin.Matula@...> wrote:
> I think it will not be that simple. For all relationships between
> objects (not just for clustering) MOFID object is used instead of the
> 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
> object from a String, however the internals of MDR may rely on some
> lookups of objects by MOFID which will not work if the object is not
> managed by MDR.
> In the light of this, I don't know this for sure, but I think the
> 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
> > our current understanding:
> >
> > Clustering one extent in the other is possible as soon as MDR can
> > retrieve MOF IDs from the clustered elements.  Currently, only
> > clustering of extents managed by MDR is possible due to the
> > following
> > line:
> > Object result =
> > packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate
> > ().getMofId(),
> > pkg);
> >
> > More specifically, the MOF ID is retrieved through the delegate,
> > which is MDR specific.  Would it be sufficient if we added a
> > type-check for finding model elements managed by other repositories?

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

> >>of RefPackage that also implements BaseObjectHandler (and wraps the
> >>MagicDraw model elements) when creating an extent?
> >>
> >>This seems feasible when we only have to override a couple of
> >>methods (like refMetaObject())... Do you know of other assumptions
> >>about RefPackage in this context?
> >>
> >>Thanks a lot in advance,
> >>Pieter
> >>
> >>On 2/15/06, Martin Matula <Martin.Matula@...> 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
> >>>>extent in MagicDraw 10.  If you look at the interfaces of
> >>>>MagicDraw and MDR, everything seems fine.  However, we've just
> >>>>encountered a class cast exception on line 752 of

NBMDRepositoryImpl, which contains:
> >>>>Object result =
> >>>>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
> >>>>org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:
> >>>>196)
> >>>>
> >>>>Reading the source, it seems like our MDR/MagicDraw integration
> >>>>will not work since  the MagicDraw classes do not implement
> >>>>internal MDR classes like BaseObjectHandler.  Is this a
> >>>>fundamental limitation of MDR or are we overlooking something?
> >>>>
> >>>>Note that we've passed MagicDraw's repository as the single
> >>>>element of the RefPackage array argument to createExtent.  On a
> >>>>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: [phone]
> >>>>       Fax: [phone]
> >>>>       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
> >>>>always has good company [Charles Evans Hughes]''
> >>>
>

[Dimitrios Kolovos]

Thanks for your reply. I have done that and it works. Now I keep the
xmi.id<->RefObject mapping in a HashSet. Is there any way to attach the
xmi.id to the RefObject itself so that I do not have keep the mapping
information separately?

Cheers,
Dimitrios

Martin Matula wrote:

> Not true in general.
> You can write your own XMIReferenceResolver and XMIReferenceProvider
> where you can maintain mapping between the generated/read xmi.id and
> MOF ID.
> Martin
>
> Tom Morris wrote:
>
>>> Is it possible to retrieve the value of the corresponding xmi.id for
>>> a RefObject using MDR? I have googled a lot but not found an answer.
>>
>>
>>
>> RefBaseObject.refMofId() returns the value that will get serialized
>> in the
>> xmi.id field.
>>
>> Tom
>
>

[Pieter Van Gorp-2]

Hi Nick,
thanks for your message.  Today my collegue made some good progress
with the cross-repository clustering approach.  Monday, we'll do
another pair programming session and try to finish that integration
approach.  If we encounter major problems then we'll have to try other
options.  Your work seems to be a good starting point!

> 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).
Are the MDR models only to be exported to SVG or can you import the
UML 2.0 Diagram Interchange model XMI back into MagicDraw?

> 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.
AFAIK MagicDraw does not implement the UML 1.4 + DI standard... and
our use case is really
 1 editing UML models in MD
 2 checking consistency rules
 3 interactively repair violations
 4 continue editing the UML models in MD

Therefore, it's really unacceptable that an intermediate step to MDR
would result in a loss of diagram info.

Curious to learn more about your tool/project,
Pieter

On 2/17/06, Nick Dowler <nick.dowler@...> wrote:

> 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: pietervangorp@... [mailto:pietervangorp@...] On Behalf
> Of Pieter Van Gorp
> Sent: 16 February 2006 20:48
> To: users@...
> 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
> > 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?
> 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 <Martin.Matula@...> wrote:
> > I think it will not be that simple. For all relationships between
> > objects (not just for clustering) MOFID object is used instead of the
> > 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
> > object from a String, however the internals of MDR may rely on some
> > lookups of objects by MOFID which will not work if the object is not
> > managed by MDR.
> > In the light of this, I don't know this for sure, but I think the
> > 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
> > > our current understanding:
> > >
> > > Clustering one extent in the other is possible as soon as MDR can
> > > retrieve MOF IDs from the clustered elements.  Currently, only
> > > clustering of extents managed by MDR is possible due to the
> > > following
> > > line:
> > > Object result =
> > > packages.put(((BaseObjectHandler)(pkg.refMetaObject()))._getDelegate
> > > ().getMofId(),
> > > pkg);
> > >
> > > More specifically, the MOF ID is retrieved through the delegate,
> > > which is MDR specific.  Would it be sufficient if we added a
> > > type-check for finding model elements managed by other repositories?
>
> > > We could check whether pkg is an instance of BaseObjectHandler and
> > > if it is not we could query for MOF IDs by means of refMofId()
> > > instead of going over the delegate...
> > >
> > > Perhaps there's more to it, but this already seems like a feasible
> > > plan.  If you would acknowledge that there will not be too much
> > > extra code to be changed, we could give it a try.  Any changes can
> > > be integrated into the latest official MDR source later.
> > >
> > > Thanks again,
> > > Pieter.
> > >
> > > On 2/16/06, Pieter Van Gorp <pieter@...> wrote:
> > >
> > >>Would we open Pandora's box by trying to pass our own implementation
>
> > >>of RefPackage that also implements BaseObjectHandler (and wraps the
> > >>MagicDraw model elements) when creating an extent?
> > >>
> > >>This seems feasible when we only have to override a couple of
> > >>methods (like refMetaObject())... Do you know of other assumptions
> > >>about RefPackage in this context?
> > >>
> > >>Thanks a lot in advance,
> > >>Pieter
> > >>
> > >>On 2/15/06, Martin Matula <Martin.Matula@...> 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
> > >>>>extent in MagicDraw 10.  If you look at the interfaces of
> > >>>>MagicDraw and MDR, everything seems fine.  However, we've just
> > >>>>encountered a class cast exception on line 752 of
> NBMDRepositoryImpl, which contains:
> > >>>>Object result =
> > >>>>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
> > >>>>org.segravis.icons.helper.Driver.loadClusteringExtent(Driver.java:
> > >>>>196)
> > >>>>
> > >>>>Reading the source, it seems like our MDR/MagicDraw integration
> > >>>>will not work since  the MagicDraw classes do not implement
> > >>>>internal MDR classes like BaseObjectHandler.  Is this a
> > >>>>fundamental limitation of MDR or are we overlooking something?
> > >>>>
> > >>>>Note that we've passed MagicDraw's repository as the single
> > >>>>element of the RefPackage array argument to createExtent.  On a
> > >>>>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: [phone]
> > >>>>       Fax: [phone]
> > >>>>       http: