Bug 531548 - Message::validateSignatureIsSignal ignores Signal owned attributes
Summary: Message::validateSignatureIsSignal ignores Signal owned attributes
Status: NEW
Alias: None
Product: MDT.UML2
Classification: Modeling
Component: Core (show other bugs)
Version: 5.3.0   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: UML2 Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2018-02-22 14:11 EST by Christian Damus CLA
Modified: 2018-02-24 03:19 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Damus CLA 2018-02-22 14:11:53 EST
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.
Comment 1 Kenn Hussey CLA 2018-02-23 18:13:27 EST
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...
Comment 2 Ed Willink CLA 2018-02-24 03:19:05 EST
(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.