Eclipse Community Forums: UML2 » Can I control the placement of stereotypes within XMI?

Help

Home

Home » Modeling » UML2 » Can I control the placement of stereotypes within XMI?

Show: Today's Messages :: Show Polls :: Message Navigator

Can I control the placement of stereotypes within XMI? [message #470950]

Thu, 15 February 2007 23:21

Billy Dennigan

Messages: 8
Registered: July 2009

Junior Member

Hi,

We are having considerable problems with merging uml 2.0.2 files due to
the fact that the stereotypes are stored at the bottom of the file instead
of inline with their base element.
In particular, whenever two users add anything to the file, new
stereotypes are appended to the end of the existing set of stereotypes.
This means that two users have effectively modified the same area of the
file and almost always results in a conflict when merging their work.
Does anyone know if it's possible to control the location of these
stereotypes within the file? Personally I'd like to be able to store them
inline with their base element, although I fear there may be risks
attached to changing the document structure like that.
Failing that, if there was a way of making them appear in the same order
as their base element it would alleviate the problem of conflicts whenever
multiple users add elements to the model.
Any ideas, or does anyone else have this problem?

Many thanks,

Billy.

Report message to a moderator

Re: Can I control the placement of stereotypes within XMI? [message #470953 is a reply to message #470950]

Fri, 16 February 2007 17:07

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Billy,

I don't believe you'll be able to insert the stereotype applications with
their base element.
That would be quite a fundamental change that could render your saved files
incompatible with other applications.
Have a look at the posting "Source Control File Merging" on Feb 1...It seems
like you are not the only one with merge issues.

Changing the order of stereotype applications should be possible and result
in compatible file format. I'll have to investigate to find the easiest way
for you to rearrange these items and which functions you have to override
but I don't see that this would get you much further.

- James.

"Billy Dennigan" <bdennigan@curamsoftware.com> wrote in message
news:aff0254eaf9e127f810fc1493f357cef$1@www.eclipse.org...
> Hi,
>
> We are having considerable problems with merging uml 2.0.2 files due to
> the fact that the stereotypes are stored at the bottom of the file instead
> of inline with their base element.
> In particular, whenever two users add anything to the file, new
> stereotypes are appended to the end of the existing set of stereotypes.
> This means that two users have effectively modified the same area of the
> file and almost always results in a conflict when merging their work.
> Does anyone know if it's possible to control the location of these
> stereotypes within the file? Personally I'd like to be able to store them
> inline with their base element, although I fear there may be risks
> attached to changing the document structure like that. Failing that, if
> there was a way of making them appear in the same order as their base
> element it would alleviate the problem of conflicts whenever multiple
> users add elements to the model. Any ideas, or does anyone else have this
> problem?
>
> Many thanks,
>
> Billy.
>
>

Report message to a moderator

Re: Can I control the placement of stereotypes within XMI? [message #470960 is a reply to message #470953]

Wed, 21 February 2007 12:31

Billy Dennigan

Messages: 8
Registered: July 2009

Junior Member

Hi James,

Thanks for the response. I've succeeded in rearranging the order of these
elements by overriding method 'XMLSaveImpl.writeTopObjects(List)', sorting
a copy of the list, and passing this on to 'super.writeTopObjects'.

This has improved the situation because it means that if two users add
elements to the model, the stereotype elements are (usually) inserted at
different locations in the set of stereotypes at the end of the file. So a
conflict does not result and these additions can be merged together
automatically. Previously this scenario would result in a merge conflict
because both developers would each have caused a new element to be added
to the exact same location of the file.

Resolving merge conflicts, when they do occur, in this part of the file is
still very difficult though because these elements are out of context i.e.
separated from their base element. So we've also added a 'logical name'
attribute to our stereotype which we set equal to the 'name' of the base
element and makes it easier to identify each of the stereotype entries.

Another question: when processing the list in
'XMLSaveImpl.writeTopObjects(List)', the second (or third) and subsequent
entries are instances of 'DynamicEObjectImpl' which correspond to my
stereotype entries. Is there an easy way to obtain the EObject class which
corresponds to the core uml object for this stereotype? I want this in
order to be able to determine the name, parent, etc of the underlying uml
object. This would help me improve my afore-mentioned sorting strategy.

Many thanks,

Billy.

Report message to a moderator

Re: Can I control the placement of stereotypes within XMI? [message #470967 is a reply to message #470960]

Thu, 22 February 2007 03:43

james bruck

Messages: 1724
Registered: July 2009

Senior Member

Hi Billy,

Have a look at UMLUtil.getBaseElement(..). I believe that's what you are
looking for.

- James.

"Billy Dennigan" <bdennigan@curamsoftware.com> wrote in message
news:409521ee3d6cefad81061a6965e39ad5$1@www.eclipse.org...
> Hi James,
>
> Thanks for the response. I've succeeded in rearranging the order of these
> elements by overriding method 'XMLSaveImpl.writeTopObjects(List)', sorting
> a copy of the list, and passing this on to 'super.writeTopObjects'.
>
> This has improved the situation because it means that if two users add
> elements to the model, the stereotype elements are (usually) inserted at
> different locations in the set of stereotypes at the end of the file. So a
> conflict does not result and these additions can be merged together
> automatically. Previously this scenario would result in a merge conflict
> because both developers would each have caused a new element to be added
> to the exact same location of the file.
>
> Resolving merge conflicts, when they do occur, in this part of the file is
> still very difficult though because these elements are out of context i.e.
> separated from their base element. So we've also added a 'logical name'
> attribute to our stereotype which we set equal to the 'name' of the base
> element and makes it easier to identify each of the stereotype entries.
> Another question: when processing the list in
> 'XMLSaveImpl.writeTopObjects(List)', the second (or third) and subsequent
> entries are instances of 'DynamicEObjectImpl' which correspond to my
> stereotype entries. Is there an easy way to obtain the EObject class which
> corresponds to the core uml object for this stereotype? I want this in
> order to be able to determine the name, parent, etc of the underlying uml
> object. This would help me improve my afore-mentioned sorting strategy.
>
> Many thanks,
>
> Billy.
>
>
>

Report message to a moderator