|Re: Preferences for validation in UML2 [message #1750212 is a reply to message #1750157]
||Sun, 18 December 2016 14:38
| Johan Van Noten
Registered: July 2009
I find the topic "preferences for validation" somewhat misleading.
The needs go beyond "preferences".
I think it is important to correctly position the use case backing this post.
Suppose a modeler/toolsmith is using Papyrus for the following use case:
* Create a domain specific language on top of papyrus: something like SysML, Papyrus-RT, or something company specific.
* As any language, it comes with additional domain concepts, some additional validations, etc
* Sometimes, even some constraint "relaxations" are required (e.g. a compliant SysML tool requires such relaxation, see http://www.omg.org/issues/issue19813.txt)
So, the use cases from a tools' perspective are in my opinion:
* Keep most of the underlying validations without change
e.g. SysML keeps most UML validations
e.g. MyOwnDSL built on top of SysML probably keeps most of SysMLs validations
* Make a underlying validation domain specific: keep the constraint without any modification, but change the message in order for it to be understandable by the domain-specific user.
* Avoid duplicate validation issues. Often a DSL complies with the underlying language, making it even stricter.
If a constraint in UML is violated, this will also violate the more specific constraint in the DSL.
With the current implementation, the user receives two validation errors, while only the strictest one would be desired.
In this case, the stricter validation should "overrule" the default one (disable it and define a new stronger one).
* Add constraints (default case, 'easy' to do)
A simple "preference" mechanism doesn't feel like the appropriate solution to these requirements, does it?
|Re: Preferences for validation in UML2 [message #1750213 is a reply to message #1750212]
||Sun, 18 December 2016 15:28
| Ed Willink
Registered: July 2009
Indeed this is a very different use case. If a UML-extending specification such as SysML violates UML constraints, it is very dubious to maintain that SysML is a UML extension.
Eventually, at the specification level the specification author's heads need to be banged together to remove the conflict. Either a too-strong UML constraint is weakened, or SysML refactoring removes the need for violation. If a real compromise is required, the troublesome Constraint can be written in terms of a virtual operation that can be overridden appropriately. cf. NamedElement::isDistinguishableFrom, Namespace::membersAreDistinguishable(), Element::mustBeOwned()
In the meantime at the tooling level, you are dealing with major developments not casual changes, so I think that adequate solutions can be found by introducing a probably hand-written UML4SysML adapter layer that overrides the UMLFactory to ensure that fixed classes are used. It may be sufficient just to override UMLValidator. With more co-operation, you can introduce the virtual operations into the UML constraints.
Powered by FUDForum
. Page generated in 0.03159 seconds