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,

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

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

Cheers,

Christian




On Dec 3, 2014, at 07:27, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

Hi,


In this specific case, I think "DSML Validation" means "Profile-/Stereotype- specific validation" (i.e. extension of default UML Validation for a specific Language/Profile)

[cwd]  That’s a subset of what I mean, yes.  There could be other domain-specific concerns such as libraries.  If a certain language-specific/runtime-specific/whatever library is imported in a model, there may be additional constraints implied for that model as belonging to a domain-specific context.


> I don't understand not defining a stereotype.

That's a common request from users to be able to add some constraints to UML without using a Profile (i.e. a Lightweight mechanism), but it really seems to be a bad practice. What could possibly make sense is to provide a specific tool (Related to the 

[cwd]  What specifically makes it a bad practice?  That could help to inform our requirements.  And note that I’m not necessarily thinking about avoiding profiles altogether; just thinking that maybe always creating stereotypes isn’t the best/only solution.


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 ...


In addition to these new features, I think some things already exist which are not (completely/at all) integrated in Papyrus, e.g. Constraints Severity/Message/Kind..., Complete OCL Support...


Camille




On Dec 3, 2014, at 03:02, Ed Willink <ed@xxxxxxxxxxxxx> wrote:

Hi Christian

Requirements

  • extensible validation for DSMLs, contributing domain-specific constraints via profiles and/or other mechanisms
  • users should be able to select which constraints to include/exclude in the validation operation
  • it should not be necessary for a profile to define a stereotype extending a metaclass just to define constraints for that metaclass (this leads to required extensions). A profile should be able to constrain a referenced metaclass without reference to any stereotype
Beyond being obviously a good idea, I'm not sure what extensible validation for DSMLs means. AFAICS DSML is just a politically more acceptable/exciting term than the discredited UML modeling. So if UML validation works, DSML validation works too.

[cwd] I mean simply providing a way to apply domain-specific (application-specific, custom) constraints on UML models.  What does “UML validation” mean?  If it means checking the UML well-formedness rules, then that doesn’t account for domain-specific needs.  If it means incorporating constraints defined in profiles, then that may be sufficient, but that still needs to be built on some validation framework, which is the point of this discussion.


It would be good to allow users to have a validation configuration so that large projects can easily switch between quick / thorough / aspectX / ... validation configurations. So a model of validation configurations behind a DSL.

[cwd] A good idea.  This is similar to the configurations that we’re working on for automated tests in the Papyrus build.


I don't understand not defining a stereotype. This seems to require a UML change/extension. UML supports mandatory stereotype application so constraints defined in a stereotype can be applied automatically, if their profile is applied.

[cwd] The requirement here is some means of adding constraints to, for example, UML metaclasses without the need for required metaclass extensions.  If I may “think out loud” a bit, could it be as simple as adding an owned rule to a profile and referencing the metaclass that it constrains? (maybe not; how important is the “context”?)  In any case, there are aspects of required extensions that I personally don’t like.  The stereotype, as such, doesn’t provide any special meaning because it’s applied to all elements.  It only distinguishes its extended elements from elements in an unprofiled model.  Would it even make sense to define multiple required extensions of the same metaclass in a profile?  I don’t see why one would do that.  And the mechanics in the Eclipse implementation of actually requiring the EObject manifestation of the stereotype application is awkward.


===================

OCL 2.5 will probably introduce a small profile to support gaps in UML

a) Integer/Real precision/rounding/overflow

b) InstanceSpecification validation enable/disable

[cwd]  Oh, yeah.  I remember this.


Perhaps something more helpful can be provided in respect of validation control.

    Regards

        Ed Willink



Back to the top