Re: [mdt-papyrus.dev] Timing Diagram: More than one state invariant?

["Christian W. Damus" <give.a.damus@xxxxxxxxx>]

Thanks, Camille.

It seems that the magic sauce I was missing was the means of creating event-occurrences in another state than the first.  After playing around some more, I discovered that it is necessary to drag a segment of the lifeline (which is manifest as a state invariant in the model; I hadn’t noticed that before) from the first state into another state.  Then the label of that other state actually appears in the diagram.

(the integrated help doesn’t cover usage of the timing diagram, so I was a bit lost)

Cheers,

Christian

On Wed, Apr 22, 2015 at 4:04 AM, LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:

Hi Christian,

 

 

I think the idea is that only the first State needs to create the “timeline”. Then, if you create additional state definitions, they will reuse the same “timeline”

 

There are however some bugs, as the new State Definitions appear only if they have at least one occurrence specification associated to them

 

Two lifelines, 3 state definitions for each:

 

<image003.png>

 

I can confirm that some exceptions occur, also (Probably the NPEs you were mentioning)

 

Camille

 

De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de Christian W. Damus
Envoyé : mardi 21 avril 2015 22:28
À : Papyrus Project list
Objet : [mdt-papyrus.dev] Timing Diagram: More than one state invariant?

 

Hi, Team,

 

Does anyone know why the timing diagram does not allow the user to create more than one state invariant on a lifeline?

 

The diagram, itself, suggests by the use of a plural form that one should be able to create more than one (see below).  However, in the CustomFullLifelineStateDefinitionCompartmentCreationEditPolicy class responsible for creating state invariants, the code is clearly creating a state invariant in the model only if it would be the first one covering the lifeline (see below).  If there is already a state invariant, then this edit policy creates only a view for the next one, without a semantic element to back it (which actually results in an NPE that I have “fixed" in my workspace).

 

What is intended here?  Should there only be at most one state invariant covering a lifeline?  Or should it allow multiple?

 

Thanks,

 

Christian

<image002.png>