eclipsesource / papyrus-seqd Goto Github PK

The Sequence Diagram editor SHALL always delete from the diagram and from the model the elements that deletes except for comments and normal constraints.

It SHALL be possible to delete the Sequence Diagram itself. This implies at any fragment, message, lifeline, and any of its related elements will be deleted also. Only generic constraints and comments present in the diagram and any other element owned by interaction that is not related to the sequence diagram will be kept.

The lightweight sequence diagram feature's identifier org.eclipse.papyrus.uml.diagram.sequence.feature is the same as used by Papyrus for its sequence diagram. This makes it difficult, akward, or impossible to co-install with Papyrus to run the two sequence diagram implementations together.

At a minimum, there are run-time exceptions in the activation of extensions in the contributions plug-in because it cannot load classes from unresolved bundles resulting in a run-time workbench.

A deletion message SHALL be created (Palette or assistant) by providing the source (send event) and target (receive event) points. The message will be created between these points, or the closest ones than does not contradict any other requirement. The receive event message occurrence specification SHALL be a destruction occurrence specification and the corresponding destruction mark is located in the lifeline at that point.

The send and receive events of a message SHALL be aligned to the same vertical location (y-axis) if the vertical distance (y-axis) is less or equal to a predefined small value(~10pixels)

A reply message SHALL be created (Palette or assistant) by providing the source (send event) and target (receive event) points. The message will be created between these points, or the closest ones than does not contradict any other requirement.

A lifeline SHALL be created (Palette or assistant) by providing a location (hover point / drag rectangle). The lifeline will be created in that location or the closest possible location in the lifeline header area. Any existing lifeline located on the right side of that location will be shifted towards the right side to make place for the new diagram.

A create tool SHALL be available in the palette for lifelines.

A lifeline SHALL be reorder (change location and semantical order) by dragging it to a new location while keep pressed the ctrl key. The lifeline will be located at the drop location, or the closest one that does not contradict any other requirement, and the lifelines will be reorder. The gap left between the lifeline and the previous one, or the left side of the diagram will be removed. As result the distance between the previous lifeline and the next one will be equal to the distance between the lifeline and the next one before the reorder.

If a creation message creates a lifeline, it will keep its vertical position.

Fragments may be reorder semantically as consequence of the reorder of lifelines, to keep the defined order, top to bottom, left to right, when two subsets of fragments are unconnected.

Messages may need to change direction, so the position of its message ends may need to rearrange, if they are inside of the specification, or the execution specification itself, if the message end corresponds to the start of the execution specification.

The API should contain all the (non-trivial) actions required to create and edit a sequence diagrams: creation/deletion of elements (Lifeline, Messages, InteractionUse...), reordering of messages/fragments, ...

Note that trivial actions (Such as renaming an element) are not covered, as we can edit the UML Element directly. The API should expose actions which might require a more complex sequence of actions (Such as: creation of a message -> also create the Message Ends, insert them at the right location, ...)

The receive event (target) location of a message SHALL NOT be located before (in the y-axis) than the send event (source) location.

When fragments are created or moved around, SHALL keep a predefined distance with the graphical element above and below and when applicable with fragments and elements on the left and right, and elements and fragment below should be pushed when needed to enforce this constraint.

Graphical elements SHALL not overlap with each other.

• Create
• Move

Updated 22 November 2018

Padding SHALL NOT be enforced when the moving an element while holding the Ctrl key (Alt on Winux), which disables snapping to magnets/grid/guides.

• Padding override modifier key

The choice of Ctrl key on Mac platform is awkward because it must be pressed only after the mouse button, otherwise the context menu is shown per standard Mac UI behaviour. However, this is the GEF/GMF convention, so it is maintained here.

A create tool SHALL be available in the palette for each kind of message and grouped together under a single dropdown button. Once the tool is selected (for a specific type of message), the message is created by clicking first in the target (send event) and then another click for the target (receive event).

As discussed on the wiki, various operations on interaction models and sequence diagrams need to understand the ordering dependencies amongst the elements of an UML Interaction, such as

• diagram editing, to understand the impact of any modification on dependent structures and visuals — e.g., what needs to move to make space for inserted elements
• interaction (semantic) editing — e.g., what needs to be deleted that depends on an element being deleted
• automatic diagram layout, to determine the horizontal and vertical flow of the visualization, grouping, etc.

It is expected that this Dependency Graph structure can be inferred entirely from the interaction (semantic) model, irrespective of the visualization in the diagram, but that perhaps existing visualization can provide hints such as user preference for relative importance of dependencies. So, the graph can be computed on-the-fly whenever it is needed, including inputs from the diagram if necessary, and needs not be maintained/synchronized over time. Accordingly, the Dependency Graph API

• must provide
  • an operation to compute the graph of an Interaction, optionally also with a Diagram visualizing it that is to be the target of any editing or other operations informed by the graph
  • an operation to query the Vertex in the graph for some Element in the Interaction
  • operations to query the semantic Element (and diagram View) represented by a Vertex
  • operations to query the Edges incoming and outgoing a Vertex that lead from and to other vertices, respectively
  • operations to query the source (dependency) and target (dependent) vertices of an Edge
• optionally provides
  • an operation to query the initial Vertex of the graph (which probably would always represent the Interaction, itself)
  • operations to query all predecessors and successors of a Vertex in dependency order
  • a Visitor protocol for walking the predecessors and successors of a Vertex
• needs not provide
  • operations to add or remove vertices and edges in the graph, as the graph is always computed from the model

As edges encode dependencies between elements in the interaction, the primary example being the ordering dependency (in time and/or visual layout), it may be necessary to associate some details of these dependencies on the Edge API. These may include some kind of weight for relative importance of the dependency, dimensionality (horizontal or vertical in the layout), grouping, etc. It is expected that these details also can be inferred from the model alone. Elaboration of these details is not in the scope of this issue but should "fall out" out the various use cases in which the Dependency Graph is employed.

A message SHALL be moved (change location) by dragging it to a new location. The source and target lifelines SHALL NOT change, neither the order of the fragments, the fragments following the message will be shift down or up by the same amount that the message itself.

However, any attempt of moving the message upwards over the previous fragment, SHALL NOT be allowed, and the corresponding forbidden cursor will be displayed.

A implementation of the Semantic dependency graph which each node represents an interaction fragment or other elements used in a interaction.

Nodes can be single node or may group in Clusters.

Examples of Single nodes are nodes that represent:

• MessageOcurrenceSpecification
• Gates
• ExecutionOcurrenceSpecification
• Or just end / start marks of some fragment.
• Creation and destruction Lifeline marks

And Clusters nodes are groups of nodes. We distinguish two types of clusters, group cluster and fragment cluster.

A Cluster (group Cluster ) contains:

• The fragments enclosed in a ExecutionSpecifications
• The InteractionFragments of a InteractionOperand in a single lifeline, together with the start and end marks.
• The start and end mark of a InteractionUse in one of the covered lifelines

And the FragmentCluster contains:

• All the corrresponding clustersin each of the covered lifelines of a InteractionOperand.
• The fragments corresponding to all the operands of a CombinedFragment
• The clusters with the start and end marks of a InteractionUse
• The nodes and groups defined for a lifeline Lifelines.

The interaction graph provides simple methods to relocate and delete nodes in the graph.

The nodes are tagged with a slot which represent a vertical position with fragments are located constrained to one single fragment per slot, except for:

• Two endpoints of the same message can be located in the same slot.
• All the start marks in all the lifelines for an InteractionUse / CombinedFragment / InteractionOperand must be in the same slot.
• All the end marks in all the lifelines for an InteractionUse / CombinedFragment / InteractionOperand must be in the same slot.
• The receiveEvent of a message can not be in a Slot located before the one for the sendEvent of the same message
• The start OccurrenceSpecification of an ExecutionSpecification and the ExecutionSpecification itself must be in the same Slot
• The Slot '0' is reserved for the lifeline clusters.

The order and the content of the Slots defines the semantical order. It vertical position (y-coordinate) defined the graphical position.

For a Message end, the x-coordinate is calculated based on the graphical position of the lifeline, the side where its opposite end is located (to the left / to the right) and the execution specification deepness. Special treatment is needed for MessageEnds:

• corresponding to a gate, the graphical constraint defined for that elements are used.
• corresponding to floating point (lost or found MessageEnds), the graphical constraint defined for that elements are used.
• corresponding to a Lifeline creation mark, where the x-coordinate is located in the left side or right side of the lifeline boundary.

So the slot can easily provide the location and boundaries of fragments and groups to be used for validation and for calculating visual feedbacks during the graphical edit operation.

It SHALL possible to delete creation messages. The message ends will be deleted and the receive message end it is first one on the lifeline, the lifeline header will be restored to the top of the diagram, to the lifeline header area.

The semantic order of fragments will be recalculated.

The fragments following the removed message ends shall be shifted up by a distance equivalent or closest to the distance from the previous fragments with the removed fragments that do not break the semantic order.

A creation message SHALL be created (Palette or assistant) by providing the source (send event) and target (receive event) points. If the receive event location is the top most in the lifeline, the head of the lifeline SHALL be shift down so the middle point of the head correspond with the intended receive event location and the message will be created between the send event location or the closest one than does not contradict any other requirement, and the middle point of the left or right side of the lifeline head, choosing the closest one to the send location. Otherwise the message will be created between these points, or the closest ones than does not contradict any other requirement.

When a deletion message receive event destruction occurrence specification becomes the last occurrence specification in the receiving lifeline, the lifeline bottom line point is set to the location of the destruction occurrence specification.

When a message has its send, and receive events aligned (same vertical position), this alignment will be always maintained, except for explicitly move or reorder the message end along the lifeline. Under any other circumstance the aligned will be maintained.

When a message is deleted, moved or reorder, any execution specification that triggers SHALL be also deleted, moved or reorder together with the message.

It SHALL be possible to move a message anchor by dragging it to new position, or the closest one that does not contradict any other requirement, along the lifeline. The semantical order of fragments SHALL not be changed, and the following fragments SHALL be moved by an equivalent distance upward or downward.

However, the anchoring point is constraint to maintain the send event before receive event constraint and SHALL not be moved upwards over the previous fragment.

It SHALL possible to delete deletion messages. The message ends will be deleted and the receive message end it is the end on the lifeline, the lifeline destruction mark will be removed, and the end of the lifeline body line will be restored to the bottom of the diagram, close to the bottom side of the interaction container.

The semantic order of fragments will be recalculated.

The fragments following the removed message ends shall be shifted up by a distance equivalent or closest to the distance from the previous fragments with the removed fragments that do not break the semantic order.

When a creation message receive event message occurrence specification is set such as it become the first occurrence specification in the receiving lifeline, the lifeline SHALL be shift down so the middle point of the head correspond with the intended receive event location and the message will be created between the send event location the closest one than does not contradict any other requirement, and the middle point of the left or right side of the lifeline head, choosing the closest one to the send event location.

The goal of this task is to display a minimal sequence diagram, and integrate it in the Papyrus editor (Including anything that we can get "for free").

This task covers the basic GMF integration to get a read-only diagram: Figures + Layout, EditParts, EditPartProvider

It SHALL be possible to change the lifeline of a message anchor by dragging it to a new position in another lifeline, or the closest one that does not contradict any other requirement, while holding the ctrl key.

The message end (and any related fragments) will be moved and inserted at that point in the other lifeline and the semantical order will be recalculated. Following fragments may be rearranged to keep the minimum distance with the inserted fragment.

The resulting anchoring points SHALL maintain the send event before receive event constraint.

Any related fragment or element that cannot be inserted in the new lifeline should be
removed from the diagram (i.e. a gate).

For creation and deletion messages, the creation and deletion mark are applied to the new lifeline, if applicable.

Any matching signature that not match anymore, should be removed from the message.

It SHALL be possible to creation messages using a diagram assistant by clicking on the edge assistant mark on the source element and dragging to the target element. And finally select the message sort from a popup menu.

It SHALL be possible to delete an asynch message. The message ends will be deleted.

The semantic order of fragments will be recalculated.

The fragments following the removed message ends shall be shifted up by a distance equivalent or closest to the distance from the previous fragments with the removed fragments that do not break the semantic order.

It SHALL be possible to delete a lifeline. Any fragment and any related fragment and element will be removed. The gap between the deleted lifeline and the previous one will be removed by shifting any following lifeline towards the left by a distance equivalent to the removed gap.

The Sequence Diagram editor SHALL show only elements with a notation defined for Sequence Diagrams. This is, lifelines, messages, interaction uses, combined fragments, operands, gates, invariants, continuations general ordering, time constraints, and duration constraints. It SHALL also display generic constraints and comments. Any other elements owned by the interaction SHALL not be displayed in any way in the Sequence Diagram.

We should document the plug-in architecture as @rschnekenbu has outlined it, to make sure the plug-in dependencies etc. is clear to everyone.

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

• R1.1 show or hide message numbering in the diagram
• R1.2 when showing message numbers, use either
  • R1.2.1 simple numbers: 1, 2, 3, ...
  • R1.2.2 hierarchical numbers: 1, 1.1, 1.2, 1.2.1, 1.3, 2, ...

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 a Signal (implied behavioral feature) for which the receiving class has a Reception (that being the actual feature). Or, in the case of a component port receiving the message, an Operation of some provided Interface.

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):

• R3.1 structured label: as per the specification cited above, with syntax highlighting and content-assist for selection of signature names, operation parameter names, and signal attribute names from the contextual model based on the type of the Lifeline's represented ConnectableElement. Conformance to the UML standard syntax is enforced by the in-line editor
• R3.2 free-form label: the user can type any text. No syntax highlighting, content assist, or validation is provided
• R3.3 hybrid: the user can type any text, with content-assist to select the name of the signature element. No validation is provided, nor syntax highlighting

As indicated in the description of R1, above,

• R3.4 the sequence number (if any) is not presented in the Direct Editor for editing by the user

A message SHALL be reorder (change location and semantical order) by dragging it to a new location while keep pressed the ctrl key.

However, the source and target lifelines SHALL NOT change, the message will be located at the drop location, or the closest one that does not contradict any other requirement, and the fragments will be reorder. and gap left between the message and the previous fragment, or the bottom line of the lifeline heads, will be removed. As result the distance between the previous fragment and the next one will be equal to the distance between the message and the next one before the reorder.

It SHALL be possible to create lifelines using a diagram assistant by hovering on the top part of the interaction, the lifeline header area.

The sequence diagram editor SHALL reconciliate the graphical elements with the uml elements.

• Graphical elements (notation views) without elements should be removed.
• For UML elements without a graphical representation, a graphical representation SHALL be added at the right place using the principles described in #23.
• Displaced graphical elements SHALL be removed and new ones added at the right position using the principles described in #23. If for some reason the reconciliation cannot be achieved, a notification should be display to the user asking for recreation of the whole diagram, by deleting it and recreate it again.

Currently we only publish the Papyrus Sequence diagram features on the update site available at github.eclipsesource.com/papyrus-seqd. As Papyrus SEQD will have a dependency to EMF Facade, we should include it in the Papyrus Sequence diagram features, so that it will be available on the update site until EMF Facade has a deployment on its own.

The sequence diagram editor SHALL differentiate between move an element or fragment, that is change its location and shift down, up, left or right any following element without change the semantic order of fragments and lifelines, from reorder fragments or lifelines, that is to be able to change the order of fragments or lifeline by removing it from the current position and inserting it in the new location between two existing fragments or lifelines.

Updated 22 November 2018

The user's intention to re-order elements SHALL be indicated by holding down the Cmd key (Ctrl on Winux). Absent this modifier, the moving of an element

• SHALL position the element at the intended new location and all subsequent elements in the trace SHALL be moved down in the case that the element is dragged downwards in the diagram
• SHALL position the element only directly below the preceding element in the trace (with padding per #26) and no higher

Note that this implies that dragging an element down the diagram without the keyboard modifier will make space in the diagram by pushing elements down, into which space then new elements may be inserted. It is not possible to make space by pushing elements up the diagram as there is a hard ceiling on the layout (that being the lifeline heads).

As a stretch goal, the pointer cursor MAY be changed to something indicative of semantic re-ordering instead of simply moving when the Cmd key is pressed, to indicate to the user that

• re-order when Cmd key is pressed
• move following trace to make space for moved element when moving an element down
• semantic re-ordering cursor

The diagram SHALL handle the move, reorder, and deletion of multiple selected elements.

It SHALL be possible to delete a reply message.

The message ends will be deleted and if the send message end correspond to the finish occurrence of the execution specification, a new finish occurrence specification is inserted instead of the removed message end.

The semantic order of fragments will be recalculated.

The fragments following the removed message ends shall be shifted up by a distance equivalent or closest to the distance from the previous fragments with the removed fragments that do not break the semantic order.

It SHALL be possible to delete a synch message. The message ends and the execution specification it triggers, if any, will be deleted in cascade.

The semantic order of fragments will be recalculated.

The fragments following the removed message ends shall be shifted up by a distance equivalent or closest to the distance from the previous fragments with the removed fragments that do not break the semantic order.

To ease testing, we should publish a p2 repository for the latest build. For now, I suggest to do this via Github pages, but I'll check, if there is another easier way to do it without Eclipse infrastructure.

If the send event message occurrence specification of the reply message is located close enough (by a predefined value) to the bottom line of an execution specification, the execution specification SHALL take as finish occurrence specification.

It SHALL be possible to move (change location) a lifeline by dragging it to a new location.

An asynch message SHALL be created (Palette or assistant) by providing the source (send event) and target (receive event) points. The message will be created between these points, or the closest ones than does not contradict any other requirement.

• A synch message SHALL be created (Palette or assistant) by providing the source (send event) and target (receive event) points.
• The message will be created between these points, or the closest ones than does not contradict any other requirement.
• An execution specification SHALL be created in the lifeline with a predefined height.
• The user will be asked for the type of the execution specification, BehaviorExecutionSpecification or ActionExecutionSpecification.
• The start occurrence specification SHALL be set to the message occurrence specification for the receive event.
• Optionally (determined by user configuration), a Reply message will be created between the same ends, but in opposite direction and if so, the finish occurrence specification of the execution specification SHALL correspond to the send event message occurrence specification of the reply message.

It SHALL be possible re-create a sequence diagram from the uml interaction element using a predefined padding values between fragments, and default sizes for interaction uses and lifelines.

It SHALL be possible to reorder a message anchor by dragging it to a new position, or the closest one that does not contradict any other requirement, along the lifeline while holding the ctrl key.

The message end (and any related fragments) will be inserted at that point and the semantical order will be recalculated. Following fragments may be rearranged to keep the minimum distance with the inserted fragment.

The resulting anchoring points SHALL maintain the send event before receive event constraint.

If a reply message finishes the specification, this is, the finish occurrence specification of the execution specification corresponds with the send event message occurrence specification of the reply message, the receive event of the message must be located in the same lifeline than the send event of the message starting the execution specification, if any.