search

eclipse-uml2 / uml2

An EMF-based implementation of the UML 2.x metamodel for the Eclipse platform.
Eclipse Public License 2.0
5 stars 4 forks source link

Message::validateSignatureIsSignal ignores Signal owned attributes #94

Open eclipse-uml2-bot opened 1 week ago

eclipse-uml2-bot commented 1 week ago

| --- | --- | | Bugzilla Link | 531548 | | Status | NEW | | Importance | P3 normal | | Reported | Feb 22, 2018 14:11 EDT | | Modified | Feb 24, 2018 03:19 EDT | | Version | 5.3.0 | | Reporter | Christian Damus |

Description

Eclipse, Papyrus, UML2 Oxygen.2

The implementation (in MessageOperations class) of the Message::validateSignatureIsSignal(...) operation doesn't consider the attributes owned by a signal. It only attempts to match the message arguments with attributes inherited by the signal from its supertypes.

So, for the common case of signals that are root types, if they have attributes, then every message that encodes arguments for that signal type will be reported as invalid by this rule.

I suggest to use allAttributes() instead of inheritedMember() to get the attributes of the signal.

Also, if that problem were fixed, we would have the inconvenience that message arguments that are LiteralSpecifications are required by this rule to have their types explicitly set, despite that the literal's type is implied by its metaclass.

eclipse-uml2-bot commented 1 week ago

By Kenn Hussey on Feb 23, 2018 18:13

Thanks for the bug report, Christian. Since inheritedMember subsets member, it could perhaps just use getMembers() instead. The problem should also be reported to the OMG so that the specification can be corrected (since the current implementation is based on the OCL from the specification).

Contributions most welcome...

eclipse-uml2-bot commented 1 week ago

By Ed Willink on Feb 24, 2018 03:19

(In reply to Christian W. Damus from comment #0)

Also, if that problem were fixed, we would have the inconvenience that message arguments that are LiteralSpecifications are required by this rule to have their types explicitly set, despite that the literal's type is implied by its metaclass.

This is a matter of perspective.

From a UML model consumer's perspective (e.g for the WFRs), the UML model should be complete, i.e. not require application of a set of inference rules.

From a UML model creator's perspective, it is tedious to have to specify gratuitously redundant information.

Clearly somewhere there can be an inference algorithm that infers/checks the redundant properties. Eclipse UML2 could provide this as a UMLUtil capability, and IMHO creators such as Papyrus should take responsibility for invoking it automatically. Manual creators using the UML Model Editor may need an Infer Redundant Properties menu action/quick fix to make WFR warnings go away.