Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [mdt-papyrus.dev] Evolution of the model validation solution in Papyrus

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:
Hi,

Thanks for comments so far.  See some replies in-line, below.

I’ll try to update the wiki page, too.

Cheers,

Christian



-- 
Ansgar Radermacher                CEA/DRT/DILS/LISE
http://www-list.cea.fr/index.htm
phone: +33 16908 3812
mailto: ansgar.radermacher@xxxxxx

Back to the top