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

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 <[email protected]> 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: [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
> > 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 <[email protected]> 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 =3D
> > > 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 <[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
> > >>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 <[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
> > >>>>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 =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
> > >>>>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: +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
> > >>>>always has good company [Charles Evans Hughes]''
> > >>>
> >
>