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