Open cdamus opened 6 years ago
You may want to have a look at the gerrit contribution we did for neon, using xtext.
https://git.eclipse.org/r/#/c/85194/
Synch and Asynch messages are implemented, but no implementation for create or return messages.
We need to double-check whether the implementation is aligned with the UML specification (see chapter 17.4.4 page 579ff).
That is exactly the section on which basis the current implementation was created.
Are we looking for more test coverage? What is the deliverable expected?
Sorry, I don't have a specific scenario that is clearly non-compliant... I just wanted to take a note that we should double-check and make sure it is compliant. I'll try to do some testing with the current implementation wrt the UML spec.
I think we can close this issue, can't we? Message labels seem to be implemented in a compliant manner now and update correctly, as far as we tested them.
I think we can close this issue, can't we? Message labels seem to be implemented in a compliant manner now and update correctly, as far as we tested them.
Yes, we have display of the message labels, but have we integrated direct editing? With support for the signature and arguments?
No, but there are a couple of other issues on this topic already: #273 But we can move this issue to Milestone 6, where direct editing is due to keep the information. Thanks!
Summary
The lightweight sequence diagram needs GMF Label Parsers for presentation and direct-editing of message names in the diagram.
Initial Requirements
R1. Message numbering
The user must have the option to
This numbering is apart from any other content of a message label, as described in following sections. Moreover, it is not accessible in the direct editor; it is strictly computed from the sequencing of messages in the interaction model. Message numbers are presented before (to the left of in left-to-right locales) the message label as specified by UML.
Hierarchical numbering conforms to the sequence expression specification for Communication Diagrams in §17.9.1.3 of the UML 2.5.1 specification. This includes the
a
,b
, etc. names for concurrent messages in a parallel combined fragment.R2. Message Signatures
If the message references a behavioral feature as its signature, then a textual representation of that feature should be shown as the label. This will typically be an
Operation
of the receiving class (actual behavioral feature) or aSignal
(implied behavioral feature) for which the receiving class has aReception
(that being the actual feature). Or, in the case of a component port receiving the message, anOperation
of some providedInterface
.Note that, per §17.4.3.1 of the UML 2.5.1 specification, a message that has a signature must have the same name as that signature. Accordingly, the name will be fixed and not editable for any message that has a signature.
R3. Direct Editing
Support for direct editing of the message label must conform to the label syntax prescribed in §17.4.4.1 of the UML 2.5.1 specification. Three input schemes are offered for the user to choose from (in the diagram preferences):
Lifeline
's representedConnectableElement
. Conformance to the UML standard syntax is enforced by the in-line editorAs indicated in the description of R1, above,