Activation/deactivation of life lines behaves strangely?

Question

Hi,

I've been testing with both a production version (8023) and some beta versions (8025beta2) (8030beta8 and beta9), and it seems the life line activation (and deactivation) feature for sequence diagrams is not working to well - at least not if we are to use UML style of sequence diagrams.

Sometimes the error message 'Only activate command can occur before message are sent' is shown and this seems to hapen slightly arbitrarily and in situations it should not happen. The problem is also connected to the statement in the manual:
"The activate and deactivate apply on the previous message." If this is what has been implemented - well, it often explains the observed behaviour but I think it is insufficient.

Example 1:  Show a single life line that is active from start in this diagram (this diagram shows something happening for an active participant), and what is happening is described by a ref box and then the diagarm ends... (should be the same with rnote over Alice...)

participant Alice
activate Alice
ref over Alice : A
deactivate Alice

Problem: We recieve an error message for an Ok diagram

Example 2: The interesting part is that the following commands does not generate the same error message(?), only a slightly uggly diagram is drawn:

participant Alice
activate Alice
ref over Alice : A

The diagram is uggly in the sense that we don't see an active Alice prior to the ref, nor do we see more than a few pixels of Alice below the ref.

Example 3: If we now recieve a message then things chage. Alice becomes active and performs (should peform) something described by a ref and then terminate...

participant Alice
[->Alice : A
activate Alice
ref over Alice : Something
deactivate Alice

...well, then the resulting diagram shows a ref box over Alice at a point where Alis is not active?

Example 4: If we add a new participant Bob, and wants to describe that Bob becomes active after the "ref Something" on Alice has happened - well we can't...

participant Alice
participant Bob
[->Alice : A
activate Alice
ref over Alice : Something
deactivate Alice
activate Bob

...as this gives a diagram where Bob seems to have been active from the same time as Alice. Althouth that could be true (in UML there is formaly no known order between activations on two lifelenes unless there is a message between them)  it is often the case that the author of the diagram knows about a timing behaviour or relations between life lines and describes this relation using text in note boxes or free text outside the diagram. Hence it cannot be the task of the diagram tool to limit the possibilities for the author to decide on the activation point of a life line too much...

My guess is that the root cause to all this is what is stated in the manual - only messages are considered, not the other constructs that references a presumably active life line:

• ref over Alice - if Alice was active immediately before the ref, then it shall (in the lack of a way to specify a 'deactivating ref') be active immediately afer too.
• for some group elements (loop, opt, break) each covered life line will (must) have the same activity status after the construct as it had before.
• for other constructs (typically alt) the activity state may actually change - the tricky part is that it must change in the same way in each part of the alt construct.

To be more practical, the activate and deactivate commands should relate to the last "ref/group/rnote over participant" statments in the same way as it relates to messages. The exeption is that if it is the first activate command in the entire diagram it shoud activate itsparticipant immediately, and if it is only the first command to reference a particular participant (other participants have already been acted upon) it should activate that participant at a point in time (y-position) that corresponds to the last y-position that anything else that referenced any lifeline occured or changed in the diagram (i.e. start or end of a ref or rnote box or any other group element, a message or an activate or deactivate command). With such an algorithm we give control over when Bob becomes activated to the author of the diagram - he/she can move the statemet 'activate Bob' upwards in Example 4 to achieve the desiered effect.

Hopefully these things can be corrected without too much worries about backwards compatibility - as the current behavior in several cases render the diagarms in a non-intuitive way.

Best Regards and thanks in advance,

Peter

Answer 1

I think the proposed solution is too complicated. Why not start drawing the activation bar when the active command is given and end the activation bar when the deactivate command is given? So don't relate the activation bar to messages,ref/group/mote over stuff but make it a graphical optional aid which give the author complete freedom about how (s)he wants to use activation bars.

(of course I don't know if this would be easy to implement without breaking backward compatibility )

 

With regards,

another Peter

Comments

Currently the deactivation command looks backwards along the life line  for when the last life line "activity" occured, and will typcally use the sending of a message as such a point and terminate the lifeline exactly at the point of sending the message. Which makes good sense if it is a synchronous call, not so good if it is asynchronous. PlantUM probably don't 'know' the difference, it only draws arrows as requested. For other constructs (ref/alt/...) it is a bad idea to terminate the life line exactly as we leave the box - there it will make sense to do as you suggest - deactivate a small distance after the box. Hence, for deactivation I agree with your statement except when a synchronous message is the last thing prior to the deactivate command - and hence the algorithm need to investigate and care about what type of construct did reference the life line prior to the deactivate. Similar argument can be made for the activate command. Finally, when we have the commands "activate A" and "activate B" after each other as the first two commands - then we most likely want to express that A and B was active from start of the diagram - not that they gradually became active. That fact could perhasp be described by some extra notation when declaring the participants, which would simplify the algorithm along the way you propose.
In summary - I don't think it can be made precisely as simple as you suggest, but what I tried to propose was not intended to be that much more complicated.
Br, Peter

PS. Or we could request two forms of these commands;
- deactivate <participant> {here}
where the precense of the trailing but optional keyword 'here' would implement exacly what you suggest and without it the command will behave exactly as today, and consequently, the command....
- activate <participant> {here|fromstart}
...would do the corresponding (without error messages), that is, activate from the positin in the diagram drawing we hapen to be at - or from the start of the diagram.
These new keywords would also be a perfectly backwards compattible extension!!
DS.

---

+1 for your activate <participant> {here|fromstart} / deactivate <participant> {here} proposal!  

With regards,
another Peter

Answer 2

First, thanks to both of you for your detailed post.

As the first Peter says, one first issue comes from the fact that only messages are considered.
We agree that the current situation is not satisfactory, and that we need to improve it.

Here we are facing several issues:

- 1) The current internal layout engine is not very flexible concerning lifeline.
The good news is that we have started a new layout engine (see http://plantuml.com/teoz.html ) to overcome those limitations. (but there are still some work to do on this new layout engine)

- 2) We really want to preserve backward compatibility. That is, with new versions of PlantUML, and even with the new Teoz engine, we really want that "old" diagrams with activate/deactive generate the same image, even if the syntax is not very logical.

- 3) The current syntax is too verbose. There are too many activate/deactivate lines in sequence diagrams.

So here is our proposal: let's define a completely new syntax, that would overcome all limitations listed by Peter in the first post.

It's very simple to add new keywords instead of activate/deactivate.
We could have something less verbose.

And this would help to support backward compatiblity (since activate/deactivate could just be deprecated keyword, but still working).

So we need some creative idea here.
For example, what about extending ++/-- notation for activation / deactivation ?

We could have something like:

ref over Alice++
ref over ++Alice
Bob++ -> Alice++
++Bob -> Alice++
Bob++ -> ++Alice
++Bob -> ++Alice
Bob++ && Alice--

The exact meaning of all those lines has yet to be defined, but this could provide a high flexibility. Any though ?

To conclude, whatever the final syntax is, we need to first finish our work on Teoz, and this will take some time (weeks/months).

So let's use this delay to define a nice and consistent syntax about lifeline. And your help will be very appreciate for this task.
 

Comments

Ok!  Do you have page with a summary of the syntax supported or proposed for Teoz, so we know what to test and discuss?
Br/Peter

---

Are there any updates on this?

In particular, I am interested in that the activated lifeline should extend below the note.

    participant Bob
    participant Alice
    Bob -> Alice: Hello
    activate Alice
    note over Alice : Decides not\nto answer
    deactivate Alice

I know about the workaround where you add the line
   Alice [hidden]-> Alice
just before the deactivation, but that is not good enough for me, as I am using this in some macros where there sometimes will be a note box as the last thing before the deactivation, and sometimes not.

---

The following example is working for us:

http://www.plantuml.com/plantuml/uml/NOj12W8n34NtFKKyW1Tm8QEuy11kOlkHGfkKD1t1qrjG16Vv_dj_wSxcevQmQyQFokJG5xaDX3PDZhcnE9tr_iUdaYF2N6b__00Tw8fID73qlBBZsuWwI5VOBxiWveHEqzp4bLZw4nOIDiy5aaOjRm00

Is it what you are expecting ?