Home » Modeling » Papyrus » Setting values for stereotype properties typed by profile defined classes
|
| Re: Setting values for stereotype properties typed by profile defined classes [message #1419441 is a reply to message #1419406] |
Mon, 08 September 2014 16:18   |
|
Hi,
Your use case works for me when I define ListNode in the profile as a
DataType, not a Class. If I recall correctly, Papyrus does not support
the instantiation of profile-defined classes, only data types, which
should work pretty much exactly as you would expect your class to work.
HTH,
Christian
On 2014-09-08 15:15:08 +0000, Johan Van Noten said:
> Scenario:
>
> Create a profile.
> Create one stereotype with a property linkHead, typed by a profile
> defined class LinkNode. This linkHead is the start of the archetypal
> LinkedList, built by chaining objects of type LinkNode. Although not
> being a practically useful example, it clearly shows the issue (see
> below).
> You obtain something like
>
> Create a model and apply the defined profile.
> Create a class diagram, put a Class on it and apply the defined stereotype.
> Create a LinkNode using the + in the right-hand side of the properties editor.
> You obtain a screen like:
>
>
>
> Problem:
> It seems impossible to edit the properties of the profile defined class
> "LinkNode".
> In this example, it means you can't create "next" LinkNodes.
> Also (to be expected) the model explorer doesn't seem to provide any
> workaround for this case.
>
> Generalization:
> As far as I see, this is true for any use of profile defined classes,
> rendering them not useful for now.
>
> Question?
>
> Am I overlooking a way to assign these values?
> Is this confirmed to be a missing / planned feature?
>
>
> Example Eclipse project is attached...
>
> <image>
> <image>
> <image>
|
|
|
| Re: Setting values for stereotype properties typed by profile defined classes [message #1420125 is a reply to message #1419441] |
Tue, 09 September 2014 14:33 |
 Johan Van Noten
Messages: 87
Registered: July 2009 |
Member |
|
|
Hi Christian,
Thanks for your quick answer.
Your proposed change looks trivial, but I have to admit that I spent several hours today realizing its consequences.
First, a word on the semantics of my original example shown above.
For me, it would mean that any Class to which I apply the stereotype MyStereotype, would own some LinkedList of ListNodes (totally useless, but clearly stating the issue).
To be able to express this ownership, I defined in the profile that "listHead", as well as "next" have Composite aggreggation.
Otherwise, the LinkedList would not be "owned" by the stereotype.
Stereotypes, composite aggregation, classes/datatypes
According to the UML Spec (2.5, section 12.3.3):
- profile-defined types can be used as types for properties in the profile
- profile-defined types are defined to be classes or datatypes (and a few others) defined in the profile
and additionally, that section states:
Quote:Furthermore, a Property of a Stereotype or Profile-defined Class can have composite aggregation if and only if its type is a Profile-defined Class whereas a Property of a Stereotype or Profileddefined Class or DataType shall have aggregation = AggregationKind::none if its type is a Profile-defined DataType, PrimitiveType or Enumeration.
Unfortunately, if I understand it correctly, that last rule invalidates the solution you proposed.
(Of course you couln't really know that, because I didn't talk about my ownership requirement, the Composite aggregation.)
Additionally, the specification of DataType (10.2) states
Quote:DataTypes model Types whose instances are distinguished only by their value.
Although not explicitely stated, this means for me that instances of a DataType are unique (only one instance having the same value) and immutable over their lifetime. This would mean that Datatypes are not the suitable candidates for storing dynamically changing values. Anyway, that is not so much to the point for this post.
Conclusion... a bug? missing feature? both?
I conclude that profile-define classes are not as equal to profile-defined Datatypes as they seem.
I would be inclined to derive two Papyrus bugs from this, but I would like to check with you guys before doing so:
- Bug: Create a profile-defined Datatype D. Create a property p on a stereotype or a profile-defined Class and type it by that Datatype D. Make p's aggreggation Composite. Validate.
No validation error is given, while this is explicitely forbidden by the spec.
- Lacking feature: To have composite aggregation, the spec forces me to use profile-defined classes. Unfortunately, Papyrus can't handle them in the stereotype application view yet. This prevents me from creating any legal profile containing a 'complex' data structure.
Looking for a confirmation or an ear slap...
Thanks,
Johan
|
|
|
| Re: Setting values for stereotype properties typed by profile defined classes [message #1420804 is a reply to message #1420125] |
Wed, 10 September 2014 13:52 |
|
Hi, Johan,
Find some replies in-line, below.
HTH,
Christian
On 2014-09-09 14:33:14 +0000, Johan Van Noten said:
> Hi Christian,
>
> Thanks for your quick answer.
> Your proposed change looks trivial, but I have to admit that I spent
> several hours today realizing its consequences.
>
> First, a word on the semantics of my original example shown above.
> For me, it would mean that any Class to which I apply the stereotype
> MyStereotype, would own some LinkedList of ListNodes (totally useless,
> but clearly stating the issue).
> To be able to express this ownership, I defined in the profile that
> "listHead", as well as "next" have Composite aggreggation.
> Otherwise, the LinkedList would not be "owned" by the stereotype.
Right. It is usually recommended to have at least one stereotype
define a composite aggregation for any non-abstract class in the
profile, otherwise instances of that class could only be contained at
the root level of a resource, which could be awkward to manage. Other
assocations to a class in a profile may be non-composite in order to
share class instances.
> Stereotypes, composite aggregation, classes/datatypes
> According to the UML Spec (2.5, section 12.3.3):
>
> profile-defined types can be used as types for properties in the profile
> profile-defined types are defined to be classes or datatypes (and a
> few others) defined in the profile
>
> and additionally, that section states:
> Quote:
>> Furthermore, a Property of a Stereotype or Profile-defined Class can
>> have composite aggregation if and only if its type is a Profile-defined
>> Class whereas a Property of a Stereotype or Profileddefined Class or
>> DataType shall have aggregation = AggregationKind::none if its type is
>> a Profile-defined DataType, PrimitiveType or Enumeration.
>
>
> Unfortunately, if I understand it correctly, that last rule invalidates
> the solution you proposed.
> (Of course you couln't really know that, because I didn't talk about my
> ownership requirement, the Composite aggregation.)
Well, yes and no. It makes no sense for DataTypes to be involved in
composite associations (or, IMO, associations at all) because they are
value types, not object types. When you define a DataType in a
profile, that DataType is converted to an EClass in the profile's Ecore
definition and all properties typed by that DataType are converted to
containment EReferences. So, in Ecore terms, it's like composite
aggregation (EDataTypes do not have structure, so UML maps DataType to
EClass).
The problem with DataTypes, of course, is that because they are value
types, they necessarily cannot be shared. For that, you really do need
Classes.
> Additionally, the specification of DataType (10.2) states
> Quote:
>> DataTypes model Types whose instances are distinguished only by their value.
>
> Although not explicitely stated, this means for me that instances of a
> DataType are unique (only one instance having the same value) and
> immutable over their lifetime. This would mean that Datatypes are not
> the suitable candidates for storing dynamically changing values.
> Anyway, that is not so much to the point for this post.
> Conclusion... a bug? missing feature? both?
> I conclude that profile-define classes are not as equal to
> profile-defined Datatypes as they seem.
Sorry, I didn't mean to suggest that the DataType would be equivalent
in practice to a Class. Only that the support in Papyrus for Classes
in profiles is not complete whereas for DataTypes it is more complete
and that maybe your particular situation would be as well served by a
DataType. Others in this newsgroup can better comment on what kinds of
profile-defined classifiers Papyrus supports (I have forgotten the
details of a past discussion on the subject).
> I would be inclined to derive two Papyrus bugs from this, but I would
> like to check with you guys before doing so:
>
> Bug: Create a profile-defined Datatype D. Create a property p on a
> stereotype or a profile-defined Class and type it by that Datatype D.
> Make p's aggreggation Composite. Validate.
> No validation error is given, while this is explicitely forbidden by the spec.
> Lacking feature: To have composite aggregation, the spec forces me to
> use profile-defined classes. Unfortunately, Papyrus can't handle them
> in the stereotype application view yet. This prevents me from creating
> any legal profile containing a 'complex' data structure.
>
>
> Looking for a confirmation or an ear slap...
>
> Thanks,
> Johan
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 06:39:23 GMT 2024
Powered by FUDForum. Page generated in 0.03003 seconds |
] 
Search
Help
Register
Login
Home
