Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » UML2 » Problem reading model with SysML 1.3 stereotypes applied
Problem reading model with SysML 1.3 stereotypes applied [message #1223354] Mon, 23 December 2013 01:31 Go to next message
Raphael B is currently offline Raphael B
Messages: 3
Registered: April 2013
Junior Member
Hello,

I would like to read a UML model with SysML 1.3 stereotypes applied, but the stereotype applications are not recognized. Other stereotype applications are recognized, so I think my setup (profile definition/registration) is correct.

Anyway, here is my point: after trying a few things, I noticed that the stereotype applications do get recognized when I move the SysML stereotypes from their original Package to the root Profile. For example, when I move "Block" from the "Blocks" Package to the root, it works. In other words, it seems like the stereotype lookup is limited to the immediate packagedElements of the Profile.

Can anyone confirm this behavior, or am I doing something wrong?
Is there a workaround that doesn't involve modifying the UML model or the SysML profile?

I'm totally new to EMF and UML2, so I am not familiar at all with all the internal mechanisms.

Thanks!
Re: Problem reading model with SysML 1.3 stereotypes applied [message #1223788 is a reply to message #1223354] Tue, 24 December 2013 09:06 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 779
Registered: July 2009
Senior Member
Hi,

See some comments in-line, below.

HTH,

Christian


On 2013-12-23 15:28:46 +0000, Raphael B said:

> Hello,
>
> I would like to read a UML model with SysML 1.3 stereotypes applied,
> but the stereotype applications are not recognized.

What do you mean by "not recognized"? The
Element::isStereotypeApplied(...) API returns a negative?


> Other stereotype applications are recognized, so I think my setup
> (profile definition/registration) is correct.

Well, you'll know it's correct for SysML, too, if the
ProfileApplications referencing its various profiles resolve those
profiles and the getAppliedDefinition() API provides the correct Ecore
definitions.


> Anyway, here is my point: after trying a few things, I noticed that the
> stereotype applications do get recognized when I move the SysML
> stereotypes from their original Package to the root Profile. For
> example, when I move "Block" from the "Blocks" Package to the root, it
> works. In other words, it seems like the stereotype lookup is limited
> to the immediate packagedElements of the Profile.

The UML2 API requires Stereotypes to be contained directly by Profiles,
and those Profiles to be applied in the context of the UML packages
where you want to apply the stereotypes.

So, if your SysML profile is a Profile containing nested Packages that
have Stereotypes in them, then that will not work. Those nested
packages should instead be Profiles (not simple Packages) and those
Profiles must all be individually applied to your UML model in order to
use their stereotypes. Applying the top-level containing Profile is
not sufficient.


> Can anyone confirm this behavior, or am I doing something wrong? Is
> there a workaround that doesn't involve modifying the UML model or the
> SysML profile?
>
> I'm totally new to EMF and UML2, so I am not familiar at all with all
> the internal mechanisms.
>
> Thanks!
Re: Problem reading model with SysML 1.3 stereotypes applied [message #1224395 is a reply to message #1223788] Thu, 26 December 2013 10:39 Go to previous messageGo to next message
Raphael B is currently offline Raphael B
Messages: 3
Registered: April 2013
Junior Member
Christian, thank you for your help. See below.

>> I would like to read a UML model with SysML 1.3 stereotypes applied,
>> but the stereotype applications are not recognized.
>
> What do you mean by "not recognized"? The
> Element::isStereotypeApplied(...) API returns a negative?

by "not recognized", I mean that Element::isStereotypeApplied doesn't return the expected stereotypes, and the stereotype applications are deserialized as AnyTypeImpl.
by "recognized", I mean that Element::isStereotypeApplied does return the expected stereotypes, and the stereotype applications are deserialized as DynamicEObjectImpl.

>> Other stereotype applications are recognized, so I think my setup
>> (profile definition/registration) is correct.
>
> Well, you'll know it's correct for SysML, too, if the
> ProfileApplications referencing its various profiles resolve those
> profiles and the getAppliedDefinition() API provides the correct Ecore
> definitions.

Actually, getAppliedDefinition() returns null in my case. That doesn't seem to prevent me from reading the stereotype applications though.
From what I see, the applied definition reference is stored as an annotation. This annotation is not created at any point, but I guess I could go through all the profile applications, retrieve the definition, and add the annotation if needed.

>> Anyway, here is my point: after trying a few things, I noticed that the
>> stereotype applications do get recognized when I move the SysML
>> stereotypes from their original Package to the root Profile. For
>> example, when I move "Block" from the "Blocks" Package to the root, it
>> works. In other words, it seems like the stereotype lookup is limited
>> to the immediate packagedElements of the Profile.
>
> The UML2 API requires Stereotypes to be contained directly by Profiles,
> and those Profiles to be applied in the context of the UML packages
> where you want to apply the stereotypes.
>
> So, if your SysML profile is a Profile containing nested Packages that
> have Stereotypes in them, then that will not work. Those nested
> packages should instead be Profiles (not simple Packages) and those
> Profiles must all be individually applied to your UML model in order to
> use their stereotypes. Applying the top-level containing Profile is
> not sufficient.

That's what I was afraid of. Out of curiosity, is this behavior due to the way EMF works (e.g. the lookup in an EPackage won't look into subpackages), or is it specific to the implementation of profiles in UML2? I don't think this behavior was intended by the people who did UML/SysML.

Anyway, for the record, I solved my issue without touching the original profile by flattening the profile definition generated by Profile::define().

Raphael
Re: Problem reading model with SysML 1.3 stereotypes applied [message #1228145 is a reply to message #1224395] Mon, 06 January 2014 09:18 Go to previous messageGo to next message
Christian W. Damus is currently offline Christian W. Damus
Messages: 779
Registered: July 2009
Senior Member
Hi, Raphael,

Sorry for the delayed reply. See some responses in-line, below.

HTH,

Christian


On 2013-12-26 15:39:02 +0000, Raphael B said:

> Christian, thank you for your help. See below.
>
>>> I would like to read a UML model with SysML 1.3 stereotypes applied,
>>> but the stereotype applications are not recognized.
>>
>> What do you mean by "not recognized"? The
>> Element::isStereotypeApplied(...) API returns a negative?
>
> by "not recognized", I mean that Element::isStereotypeApplied doesn't
> return the expected stereotypes, and the stereotype applications are
> deserialized as AnyTypeImpl.

Ah, OK. The AnyTypes indicate that the EMF serialization layer
couldn't resolve the EPackage definition of the profile. That is,
either the XML namespace declaration for the stereotype instances in
question was missing (highly unlikely) or it simply couldn't be
resolved (much more likely). What does the location URI for the
corresponding namespace declaration look like?

The AnyTypes are a result of the "record unknown features" load option
that (I think) the UML resource factory applies by default.


> by "recognized", I mean that Element::isStereotypeApplied does return
> the expected stereotypes, and the stereotype applications are
> deserialized as DynamicEObjectImpl.
>
>>> Other stereotype applications are recognized, so I think my setup
>>> (profile definition/registration) is correct.
>>
>> Well, you'll know it's correct for SysML, too, if the
>> ProfileApplications referencing its various profiles resolve those
>> profiles and the getAppliedDefinition() API provides the correct Ecore
>> definitions.
>
> Actually, getAppliedDefinition() returns null in my case. That doesn't
> seem to prevent me from reading the stereotype applications though.

Do you mean that for a profile that is recognized,
getAppliedDefinition() also returns null? That doesn't seem right.
But a null does make sense for the EPackage definition that couldn't be
resolved (and which stereotype instances end up as AnyTypes).


> From what I see, the applied definition reference is stored as an
> annotation. This annotation is not created at any point, but I guess I
> could go through all the profile applications, retrieve the definition,
> and add the annotation if needed.

No, you shouldn't ever have to manipulate these annotations. They are
managed by the UML API. It creates the annotation at the time of
application of the profile, somewhere in the call tree of the
Package::applyProfile(...) operation.


>>> Anyway, here is my point: after trying a few things, I noticed that the
>>> stereotype applications do get recognized when I move the SysML
>>> stereotypes from their original Package to the root Profile. For
>>> example, when I move "Block" from the "Blocks" Package to the root, it
>>> works. In other words, it seems like the stereotype lookup is limited
>>> to the immediate packagedElements of the Profile.
>>
>> The UML2 API requires Stereotypes to be contained directly by Profiles,
>> and those Profiles to be applied in the context of the UML packages
>> where you want to apply the stereotypes.
>>
>> So, if your SysML profile is a Profile containing nested Packages that
>> have Stereotypes in them, then that will not work. Those nested
>> packages should instead be Profiles (not simple Packages) and those
>> Profiles must all be individually applied to your UML model in order to
>> use their stereotypes. Applying the top-level containing Profile is
>> not sufficient.
>
> That's what I was afraid of. Out of curiosity, is this behavior due to
> the way EMF works (e.g. the lookup in an EPackage won't look into
> subpackages), or is it specific to the implementation of profiles in
> UML2? I don't think this behavior was intended by the people who did
> UML/SysML.

I don't have an answer for this. I, too, would have expected that
application of a profile would implicitly apply sub-profiles, but in my
experience the UML API has done a good job of strictly implementing the
OMG-specified UML semantics where they are clearly defined. The
semantics of profiles have, I think, been one of the more
loosely-defined corners of the language, so there possibly has had to
be some "interpretation" in the Eclipse implementation. I just don't
know.

Looking at the UML 2.5 specification, I see the following in Section
12.3.3, the semantics of profiles:

"""
Applying a Profile means recursively applying all its nested and
imported Profiles.
"""

This is a pretty clear statement. :-) The Luna release has an
enhancement scheduled to implement the final UML 2.5; I'll add a note
to call this out as a potential to-do item for profiles.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=418466


>
> Anyway, for the record, I solved my issue without touching the original
> profile by flattening the profile definition generated by
> Profile::define().
>
> Raphael
Re: Problem reading model with SysML 1.3 stereotypes applied [message #1228252 is a reply to message #1228145] Mon, 06 January 2014 14:40 Go to previous message
Raphael B is currently offline Raphael B
Messages: 3
Registered: April 2013
Junior Member
Hello Christian,
Thank you for these answers! See my comments below:

> > by "not recognized", I mean that Element::isStereotypeApplied doesn't
> > return the expected stereotypes, and the stereotype applications are
> > deserialized as AnyTypeImpl.
>
> Ah, OK. The AnyTypes indicate that the EMF serialization layer
> couldn't resolve the EPackage definition of the profile. That is,
> either the XML namespace declaration for the stereotype instances in
> question was missing (highly unlikely) or it simply couldn't be
> resolved (much more likely). What does the location URI for the
> corresponding namespace declaration look like?

Actually, I don't have any location URI for the corresponding namespace. I just load the the corresponding Profile before loading my UML model. I might eventually use location URIs, but that's not my priority right now.

> The AnyTypes are a result of the "record unknown features" load option
> that (I think) the UML resource factory applies by default.

It seems so. I have AnyTypeImpls for xmi:Extensions, and for referenced elements for which a concrete type can't be figured out (HREFs with no xmi:type). But that's another story, unrelated to this topic.

> >>
> >> Well, you'll know it's correct for SysML, too, if the
> >> ProfileApplications referencing its various profiles resolve those
> >> profiles and the getAppliedDefinition() API provides the correct Ecore
> >> definitions.
> >
> > Actually, getAppliedDefinition() returns null in my case. That doesn't
> > seem to prevent me from reading the stereotype applications though.
>
> Do you mean that for a profile that is recognized,
> getAppliedDefinition() also returns null? That doesn't seem right.
> But a null does make sense for the EPackage definition that couldn't be
> resolved (and which stereotype instances end up as AnyTypes).
>
> > From what I see, the applied definition reference is stored as an
> > annotation. This annotation is not created at any point, but I guess I
> > could go through all the profile applications, retrieve the definition,
> > and add the annotation if needed.
>
> No, you shouldn't ever have to manipulate these annotations. They are
> managed by the UML API. It creates the annotation at the time of
> application of the profile, somewhere in the call tree of the
> Package::applyProfile(...) operation.

Let me give you more details on what I'm doing:
I am sequentially loading UML files (packages, profiles and finally my model) that haven't been created using EMF/UML2, so no annotations are present.
After loading a file, I look for any profile it contains. Each profile is then defined, and added to the EPackageNsURIToProfileLocationMap.
So when my UML model is read last, all the profiles and their definitions are "ready", and the stereotypes are recognized. However, I suspect that the "applied definition" annotation is not created when my model is parsed and a profile application is encountered.

> >> The UML2 API requires Stereotypes to be contained directly by Profiles,
> >> and those Profiles to be applied in the context of the UML packages
> >> where you want to apply the stereotypes.
> >>
> >> So, if your SysML profile is a Profile containing nested Packages that
> >> have Stereotypes in them, then that will not work. Those nested
> >> packages should instead be Profiles (not simple Packages) and those
> >> Profiles must all be individually applied to your UML model in order to
> >> use their stereotypes. Applying the top-level containing Profile is
> >> not sufficient.
> >
> > That's what I was afraid of. Out of curiosity, is this behavior due to
> > the way EMF works (e.g. the lookup in an EPackage won't look into
> > subpackages), or is it specific to the implementation of profiles in
> > UML2? I don't think this behavior was intended by the people who did
> > UML/SysML.
>
> I don't have an answer for this. I, too, would have expected that
> application of a profile would implicitly apply sub-profiles, but in my
> experience the UML API has done a good job of strictly implementing the
> OMG-specified UML semantics where they are clearly defined. The
> semantics of profiles have, I think, been one of the more
> loosely-defined corners of the language, so there possibly has had to
> be some "interpretation" in the Eclipse implementation. I just don't
> know.
>
> Looking at the UML 2.5 specification, I see the following in Section
> 12.3.3, the semantics of profiles:
>
> """
> Applying a Profile means recursively applying all its nested and
> imported Profiles.
> """
>
> This is a pretty clear statement. Smile The Luna release has an
> enhancement scheduled to implement the final UML 2.5; I'll add a note
> to call this out as a potential to-do item for profiles.
>
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=418466

Well, thanks! However, I'm not quite sure implementing that would solve the problem I had. Even by applying subprofiles, UML2 would still expect, for example in SysML, the Block stereotype to be in the Blocks package, and the Blocks package to have a specific namespace URI.

I think the real issue comes from the SysML XMI. It should either define subprofiles (not subpackages) with distinct URIs, or add package imports so that all the subprofiles are imported in the root profile and directly accessible using the SysML namespace. The current version makes it impossible to resolve stereotypes without looking into subpackages.

Also, I haven't found in the UML or XMI specs whether parsers should look at subpackages when resolving element names.

Raphael
Previous Topic:Problems in RedefinableTemplateSignature
Next Topic:No outline view in default UML editor?
Goto Forum:
  


Current Time: Mon Sep 01 09:55:25 EDT 2014

Powered by FUDForum. Page generated in 0.10594 seconds