Community
Participate
Working Groups
Sequence diagram should support time and duration constraint and observation
There is a problem with creation : Leave the mouse in the upper part of the interaction, up the container. A tooltip appears to propose creation of DurationConstraint or DurationObservation. If selected, this action lauches a class cast exception. Creation from this place should be forbidden. Creation from palette by clicking at this place should not be authorized either.
A - Validation Time Observation : A1 - Create a async message, and a time observation on the source of the message. When moving this message, the time observation is always drawn on the right side of the lifeline where it should be drawn on the left side A2 - Same issue on an ES A3 - When a time observation is drawn on a messageEnd, if you try to reconnect the message, it takes into account the figure of the time observation. It shouldn't be A4 - When resizing an ES, the time observation doesn't follow the message end A5 - When a destructionEvent exists on a lifeline with a timeObservation, drawing a delete message remove graphically the timeObservation. But it can be dnd again on the destructionEvent afterwards. A6 - When creating several timeobservation on an occurrenceSpecification (semantically valid ?), labels are stack. B - Validation Time Constraint B1 - When creating a time constrain from the palette, the figure is not created exactly on the message but some pixels above. B2 - According to the validation plan, the time interval should be editable through the diagram. It is not the case. The name of the time constraint is edited instead. B3 - Actually it is too difficult to create a time interval or any kind of time expression. A specialized direct editor, or a mechanism should exist to ease the selection of a time interval. This editor should be generic to all value specifications. B4 - When a time interval is set, the node size is not correctly updated that truncates the label B5 - same as A1 B6 - same as B6 C - Validation Duration Observation C1 - Only work on message, it should work on other elements (ES, Lifeline, etc...) C2 - DnD doesn't work C3 - The constraint "The multiplicity of firstEvent must be 2 if the multiplicity of event is 2; otherwise, the multiplicity of firstEvent is 0." is not verified. It should be raised on MDT UML2 D - Validation Duration Constraint D1 - DurationConstraint doesn't work between two message ends of the same lifeline. D2 - Same as B3 D3 - On an ES, sometimes when resizing the ES, the duration constraint is not exactly drawn at the two extremity of the ES. D4 - same as B4. D5 - same as A6
*** Bug 313667 has been marked as a duplicate of this bug. ***
Created attachment 171628 [details] no interval duration
Created attachment 171629 [details] interval duration expected
https://bugs.eclipse.org/bugs/attachment.cgi?id=171628 Here what i had in the 1st print_screen : - no interval duration can be set using <min> <max> in the duration interval properties. -> no duration interval appear in the sequence diagram https://bugs.eclipse.org/bugs/attachment.cgi?id=171629 Here what i expected is in the 2nd print_screen : - interval duration in the sequence diagram The eclipse modeling tools build ID used : 20100318-1801 the papyrus ID used : 0.7.0v201006090603
Thank you for your contribution. Your problem actually refers to B3 / D2 : "Actually it is too difficult to create a time interval or any kind of time expression. A specialized direct editor, or a mechanism should exist to ease the selection of a time interval. This editor should be generic to all value specifications." The Duration Interval is actually correctly created. The min and max values must be first created in the containing package, using : NewChild > Packaged Element > Time Expression. Then you can assign them as min and max. Expressing what you want with the Time Expression is really difficult for the moment. If you want to use it right now, I suggest you keep the UML specification next to your computer. Direct edition of the time interval enables you to edit the duration constraint label for the moment, but it should at the end enable you to write your time expression in a more user friendly way.
I agree with previous remarks, entering Duration constraints is rather tedious. Improvements have been done with the automatic creation of DurationInterval but setting min and max is not so easy. We have to create Duration Elements which are not enabled in the Model Explorer and that are not present in the palette either. Your temporary solution "The min and max values must be first created in the containing package, using : NewChild > Packaged Element > Time Expression." ... is not feasible with the current Papyrus Model Explorer (Time Expression is not present in the menu). (I am using nightly build 829 N2010070631) Up to now I have shifted to UML Editor to create them.
Created attachment 175086 [details] Exemple of notation for observation used in composite diagram
I agree with previous comments related to usability issues of this feature which must be improved notably I add a few comments on notations and restrictions which are not conform to the specification. 1. Management of Observations Notation is not conform A similar representation as the one used in composite Diagram (notably using symbol @ and & ) would be appreciated (see attachment) A Time observation is not settable In the specification, Observations can be related to any Named Element, thus restriction on duration observation is not justified Duration Observation should not be limited to duration of message sending. 2. Timing constraints do not respect the UML notation Time Constraint : bar between label and point in the diagram is lacking Duration constraint : (vertical arrow) The vertical rectangle chosen as figure is too rigid The label sould be relocatable to improve clarity of diagrams (it is currently very confusing when several constraints are defined) It should be editable. DurationConstraints should be possible between events related to elements existing in different Lifelines
Hi, I am using Eclipse Modeling Tools: -Version: Helios Release -Build id: 20100617-1415 -Papyrus mdt version: 0.7.0v201007251735 When i create a duration constraint and i want to set min and max value, it is impossible. I have seen the previous messages to solve my problem, but since model explorer has changed, I can't find a way to set the extremums values. How can I do to set the min and max value? Is it possible in this papryus version or do I have to change my papyrus version?
(In reply to comment #11) > Hi, > > I am using Eclipse Modeling Tools: > > -Version: Helios Release > -Build id: 20100617-1415 > -Papyrus mdt version: 0.7.0v201007251735 > This is the same probleme to setting up min and max values on time constraint.
some recent fixes : - add the @ to TimeObservation - add the & to DurationObservation and remove "=duration" - by default add min and max Duration to the DurationInterval associated to the Duration Constraint. The default associated literals are Integer and the value can be changed in the properties view.
Ok this improves these facilities. Remarks on notations: You can also remove the "= now" for Time Observation. Add a small bar from the & towards the message for Duration Observations. Thanks for adding min and max duration to the Duration Interval. However, there is a pb with setting values. They can be changed in the property view but they are not refreshed in the diagram. It is necessary to close the model, then reopen it to have the diagram updated.
the refresh problem is fixed and committed. the =now have been removed, but I don't understand your other remark : "Add a small bar from the & towards the message for Duration Observations."
That means that the label of DurationObservation is prefixed by "&".
Created attachment 177629 [details] UML Time&Duration Observation Specification UML Time&Duration Observation Specification
One remaining bug with Time and Duration Observations is that one must to be able to attached a Time Observation to any kind of NamedElement, and a DurationObservtation between 1 or 2 NamedElement. This is what we have implemented for the Composite Diagram. Why not simply do the same as we in this diagram and not reusing the existing code? The usage of both Observation should be the same in SequenceDiagram than in Compoiste Diagram. See new attached documen that is extracted from the UML2 specification about the definition of Time and Duration Observation.
(In reply to comment #18) > Why not simply do the same as we in this > diagram and not reusing the existing code? The usage of both Observation should > be the same in SequenceDiagram than in Compoiste Diagram. See new attached > documen that is extracted from the UML2 specification about the definition of > Time and Duration Observation. Simply because this representation restrains the usage to only elements which are drawn in the diagram. In the UML specification, there are only 3 figures representing Time/Duration Constraint/Observation in sequence diagram : figure 14.26 (which by the way, uses the "=duration" and "=now" notation), figure 13.15 and figure 13.17. If you refer to these figures, you will see that the time bars appear clearly on Events starting/ending a message/execution, not on Lifelines, Execution or Messages. If we use the same representation as in the Composite Diagram with a correct UML model, all that would remain is a floating node linked to nothing in the diagram. If the user tries to use such a feature, all he will be able to result in is an Observation/Constraint on the message, or on the lifeline, without being able to control at which point of it the Observation/Constraint is linked.
There are two points in your answer 1. We indicated you a solution to reuse existing code and unify representations between diagrams You reject this solution with bad arguments. Of course the elements represented in composite diagrams are not the same as the one represented in the sequence diagram. Yes there is a slight difficulty in the sequence diagrams, since constraints are on or between occurrence specifications that the user cannot see in the diagram and not ES, messages and Lifelines that he can see. But you manipulate both without problem when you create synchronous messages for instance. There is no more sense in saying that the duration constraints will hang on nothing than saying that messages cannot be represented. The idea we suggested was to reuse a notation that for instance solves one pb to relate two points corresponding to two elements (what elements are may of course be different from one diagram to another). There is no contradiction with the proposal. 2. Figures are examples. The specification is given by the meta-model. A DurationConstraint defines a Constraint that refers to a DurationInterval. As a Constraint it can relate any elements. Since we are in a sequence diagram, elements can be any model element in the diagram. Nothing forbids the expression of a duration interval between two occurrence specifications in different lifelines for instance to denote an end-to-end duration constraint between the reception of a signal on one and the finish event of an execution specification on an other one. You limit such duration constraint to the transmission delay of a message. By the way, yes in the examples we can find example uses of the "=duration" and "=now" notation, but they are examples of expressions linked to the observation and are not a string written systematically. When you will provide support to build such expressions, you might propose these as possible default values. But they cannot be strings written automatically and not accessible to the user.
Created attachment 177713 [details] DurationConstraintDisplayPbWhen changing displaySide Impact on messages anchoring
Created attachment 177714 [details] DurationConstraintDisplayPbWhenMovingES Graphical Synchronization between ES and Duration is lost
On an other subject now, here are two pbs with graphical management of Duration constraints. 1. Changing side of display of a duration constraint (left side of ES instead of right side) has an impact on messages anchors. 2. Moving an ES with Duration constraint attached can result in disconnection between ES and and duration constraint display. First pb is systematic, the second one is not systematic but quite frequent (more than 50%) Context Build the following context: 1.Create two lifelines (with represents properties set) 2.Create an ES on the first LifelineStereotype (on the left) 3.Create a synchronous message towards the second lifeline (on the right); an ES is created on the second lifeline 4.Create a reply message towards the first lifline. Now here are the scenarios for first and second pb First 1.Create a duration constraint on the first lifeline between start an end of ES. 2.The constraint show up on the right side of the lifeline which is OK but confusing due to messages between the two lifelines. 3.Move the duration representation on the left side of the lifeline 4.The duration is moved but anchor point of reply message departure on the second lifeline is moved !!!! Second 1.Move the second ES downward. The display of the duration constraint shows an offset with the ES limits. 2.Undo the command. The ES comes back to its initial position, but sometimes the duration constraint stays down and most often there is a delta with the initial position. You can see the screen view in attached documents (bugs_AL 6 and 7).
Provide support for setting Time Constraint -------------------------------------------------- Setting min and max values for DurationInterval now works but no similar facility is provided for TimeInterval on Time Constraint. The TimeInterval is provided but min and max values cannot be set.
In the current version, modeling Duration Observation is still only possible on message. This limitation has to be removed. As previously explained, a DurationObservatioon has to be applicable between 1 or 2 NamedElement!
fix for comment 22 committed. problem mentioned in comment 21 is related to message router problems, I am still looking for a solution.
Has been fixed in 0.10.0
