[language] Constraints are not distinguishable

[eclipse-ocl-bot]

| --- | --- | | Bugzilla Link | 264927 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 14, 2009 05:39 EDT | | Modified | May 27, 2011 08:11 EDT | | Blocks | 318248 | | Reporter | Ed Willink |

Description

M5

Possibly more a query than a bug.

After switching to use the UML-binding for my OCL editor, I'm unclear how to persist the root of the resulting OCL AST.

A Resource.contents comprising Ecore Constraints was no problem.

A Resource.contents comprising UML Constraints complains that the Constraints are not owned.

A Resource.contents comprising a Model containing many UML Constraints complains that the Constraints are not distinguisable.

Is there a better structure for a Constraint AST, or should Constraint.name be set to some unique value, or should Constraint distinguishability validation be suppressed?

[eclipse-ocl-bot]

By Christian Damus on Feb 16, 2009 14:34

(In reply to comment #0)

M5

Possibly more a query than a bug.

After switching to use the UML-binding for my OCL editor, I'm unclear how to persist the root of the resulting OCL AST.

A Resource.contents comprising Ecore Constraints was no problem.

Yeah, because the Ecore Constraint metaclass doesn't have any constraints. ;-)

A Resource.contents comprising UML Constraints complains that the Constraints are not owned.

Yes, in the UML, only packages may be root elements. Although, this constraint is only useful in a UML modeling context ...

A Resource.contents comprising a Model containing many UML Constraints complains that the Constraints are not distinguisable.

NamedElements are assumed to be addressable by name, from textual languages like OCL. For some elements, like Classes, it's clearly not good to have ambiguity in the name resolution. The severity of this problem in Constraints (being NamedElements, also) is possibly not so clear.

Is there a better structure for a Constraint AST, or should Constraint.name be set to some unique value, or should Constraint distinguishability validation be suppressed?

Well, the concrete syntax of OCL allows constraint names to be specified by the user, so they may already be non-unique from the source. I don't think that there is a better structure, and I wouldn't even be concerned about the must-be-owned constraint. This is one of the reasons that the UML deliberately doesn't indicate how or when its constraints should be checked, or even what it really signifies when they are violated. Especially, in the OCL context, an application probably shouldn't enforce these constraints: OCL has its own constraints that are meaningful to the structure of OCL, not of UML models (i.e., I don't consider OCL constraints as being UML models).

On one occasion when I implemented the namespace-members-distinguishability constraint in a commercial product that shall go unnamed, I specifically excluded unnamed elements from the check. Since a NamedElement that has no name (simple and qualified names then both being null) isn't referenceable by name from a textual language anyway, considering multiple unnamed elements to be indistinguishable is completely pointless.

I would recommend raising an issue to the UML RTF to change this constraint to consider only elements that actually have names. I don't know whether the UML2 team would consider anticipating such a change by enhancing their implementation of that constraint ... James?

[eclipse-ocl-bot]

By James Bruck on Feb 17, 2009 13:43

Hi guys,

Has there been an official RTF issue raised against this? \ I would have to evaluate the impact of any changes but I'm open to any enhancements you may propose.

[eclipse-ocl-bot]

By Ed Willink on Feb 17, 2009 14:30

James: I tend to feel that UML is too clever for me, so I'm reluctant to raise the RTF myself.

---

I've been trying to come up with workarounds, but it seems clear that the name of an OCL constraint is meaningless in a global context.

def's typically have no name but could get one from the constrained element.

inv's typically have a name but in a large OCL document there could be many same-named inv's for different classes. Constraints are not inherently scoped. They could be grouped by Package and Class, but that would involve duplicate structure.

So Christian's suggestion of ignoring unnamed Constraints doesn't help.

---

A more fundamental problem is: given an OCL editor that produces an OCL AST, what tool is going to use that AST, and how should the AST be structured to be valid and mutually compatible?

From this point of view a synthetic Package, Class structure will guarantee non-portability.

Probably the best solution is to emulate the Ecore solution, a Resource.contents full of UML Constraint objects. The isOwned validation should just keep quiet if the 'owner' is the eResource().

[eclipse-ocl-bot]

By Christian Damus on Feb 17, 2009 15:28

(In reply to comment #2)

Hi guys,

Has there been an official RTF issue raised against this?

I know that I haven't raised the issue ... If it makes sense to you, then I can do that.

(In reply to comment #3)\

def's typically have no name but could get one from the constrained element.

Yes, the concrete syntax doesn't provide a means to specify the name, though placement of a def constraint in a UML model does.

A more fundamental problem is: given an OCL editor that produces an OCL AST, what tool is going to use that AST, and how should the AST be structured to be valid and mutually compatible?

Clearly, OMG's expectation is that tools will use the concrete syntax, not the AST, otherwise it would have been more completely and consistently specified. :-)

UML defined some constraints here that make sense in the context of a UML model but which don't account for the different needs of metamodels extending it, like OCL. And, OCL didn't account for the constraints that it inherits from UML. Given this mismatch, probably the best approach is just to generate the simplest possible structure. The fact that it violates some constraints doesn't mean that a tool shouldn't be able to consume it (though the tool may choose to report these violations as problems).

From this point of view a synthetic Package, Class structure will guarantee non-portability.

Probably the best solution is to emulate the Ecore solution, a Resource.contents full of UML Constraint objects.

I'm inclined to agree.

The isOwned validation should just keep quiet if the 'owner' is the eResource().

That doesn't work for UML, though. Resources are not a UML concept as composite aggregation is.

[eclipse-ocl-bot]

By Ed Willink on Feb 17, 2009 15:44

The isOwned validation should\ just keep quiet if the 'owner' is the eResource().

That doesn't work for UML, though. Resources are not a UML concept as\ composite aggregation is.

But if the validation is implemented in Java, the eResource() can be tested.\ (I only meant to diminish the isOwner validation for a Constraint.)

def's typically have no name but could get one from the constrained element.

Yes, the concrete syntax doesn't provide a means to specify the name, though\ placement of a def constraint in a UML model does.

Surely

def: xxx...

can be changed to

def xxx: xxx...

providing an explicit name?

[eclipse-ocl-bot]

By Christian Damus on Feb 17, 2009 15:52

(In reply to comment #5)

Surely

def: xxx...

can be changed to

def xxx: xxx...

providing an explicit name?

Certainly, but it's not spec'd that way. That doesn't mean it was deliberate, nor that it wouldn't make sense to change the implementation anyway. :-)

[eclipse-ocl-bot]

By Ed Willink on Feb 17, 2009 16:14

(In reply to comment #6)

def xxx: xxx...

is supported by the current MDT OCL parser and AST.

[eclipse-ocl-bot]

By Christian Damus on Feb 17, 2009 17:42

(In reply to comment #7)

(In reply to comment #6)

def xxx: xxx...

is supported by the current MDT OCL parser and AST.

Ah, indeed. As in spec §12.12.6. I had the def: constraint confused with the attribute constraints syntax. It is the initial- and derived-value expressions that inexplicably omits the optional name (§12.12.4, initOrDerValueCS). That really just seems like an oversight and, given how hopelessly the grammars in the spec are out to lunch anyway, I would not be averse to OCL anticipating a resolution of that problem, if it would help.

[eclipse-ocl-bot]

By Ed Willink on Feb 18, 2009 04:15

If I was revising the OCL spec, I would define the 'distinguishable Constraint name' as a package scoped name to be deduced from the scoped name of the first constrained element, with the explicitly provided name optionally overriding the final name in the path.

If you care to turn the above into a better considered OCL issue please do. I don't appreciate sufficient of the UML aspects.

For my OCL editor purposes, I think that I will create an overridden UML validator that suppresses the Constraint isOwned winges. If James cares to do that as standard UML2 functionality it would save me a little effort and avoid surprises for anyone opening an OCL AST file with a 'Sample Ecore Editor'. The warning is particularly irritating: somewhere somethings are not distinct.