Hi Christian,
first, thanks for the initiative to setup the wiki page. I think,
it's a good overview of what exists today.
Dynamic
Profile Definition tool?) to define Stereotype Constraints
without actually going through all the steps to create a
Profile, Required Stereotype, ... The user could e.g. specify
a new Constraint for all "uml::Class", and Papyrus would under
the hoods create a new Profile, a new required Stereotype
extending Class, attach the constraint to this Stereotype,
then define & apply the profile on the current model. Part
of this tooling already exists (I'm not sure what the status
of this tool is exactly today), so it could be extended for
supporting Constraints.
[cwd] I would hesitate to work too much magic under the covers
because eventually users have to deal with the reality of the
implementation, be it profiles or whatever, especially in a team
scenario when considering change, merging, and conflicts (which Ed
also highlights). And again, required extensions bother me
perhaps more than they should; I find them irksome. Not exactly a
rational reaction, I suppose ...
I agree not to do too much magic under the hood. Defining for
instance a profile explicitly and then associating constraints
with stereotypes is probably not too much to ask for a user.
However, I recently discovered the need for defining constraints
on elements, but adding stereotypes would not be an optimal
solution: UML-RT has additional constraints on states, but adding
a stereotype (as currently done with the stereotype RTState) to
each state of a capsule's state-machine is redundant since all
states of a state-machine within a capsule are implicitly
"real-time" states. While it might be possible to "lift" the
constraints on the state-machine level in this case, it might
still be good to be able to associate constraints with
non-stereotyped elements.
Another issue related to custom messages is how to specify these
in a profile. There is a solution to do this in OCL, but not all
constraints can be expressed in OCL. Papyrus has a specific
stereotype applied to constraints to define this message, but it
is only taken into account when a plugin.xml is generated. Thus,
we would need to define a common way to specify the messages that
works for OCL and non-OCL constraints and regardless how you embed
your constraint rules (and ideally allow for
internationalization).
Best regards
Ansgar
On 12/04/2014 08:13 PM, Christian W. Damus wrote: