Why DOESN'T this Star UML Sequence Diagram have the activation "rectangle" in the Control object?

Question

Why DOESN'T this Star UML Sequence Diagram have the activation "rectangle" in the Control object? Am I doing something wrong? Should I set something in Star UML?

How can I add the activation "rectangle" in the Control object?

Answer 1

The simple answer is: because that's how the designers of Star UML designed it to be.

In Star UML if nothing initiates (triggers) the Execution Occurrence (that's the formal name of that rectangle) then... there is no Execution Occurrence. If you want to have it, you need to trigger it somehow (e.g. by self-referencing Initiation message).

I didn't find any option to change that behaviour. I haven't been using the Star UML for quite some time but since the free version has been abandoned earlier than I've started using it, I believe nothing has changed since.

If you're using the newer, proprietary version, you can send a request to the dev team of Star UML to add it as a functionality.

Answer 2

Well, this is because no tool I know of implemented sequence diagrams correctly. According to UML it should be possible to define ExecutionSpecifications (aka activations) independent of any Messages.

However, many tool vendors seem to assume, that an ExecutionSpecification must be started by a message. I can see, where they come from, since every execution has a cause. The problem is that sequence diagrams are not about causality, but about possibly occurring sequences of events. Sequence diagrams don’t mean, that this is the only possible sequence.

If we accept that the tool wants to start an ExecutionSpecification with a Message, the behavior of Star UML is consistent. Please note that a create message (i.e. messageSort=createMessage) does not call the constructor:

UML: A CreateObjectAction is an Action that creates a direct instance of a given Classifier and places the new instance on its result OutputPin. The Action has no other effect. In particular, no Behaviors are executed

I know, this is about Actions, but why should a create message be different? Also, there is a constraint that stops create messages from having a signature:

signature_refer_to

The signature must either refer an Operation (in which case messageSort is either synchCall or asynchCall or reply) or a Signal (in which case messageSort is asynchSignal).

That means, you cannot reference a constructor in the create message. You will need to call the constructor explicitly. The sender of this message is the same Lifeline that created the new object. It should not be a self message, since this is not what is happening in reality and is therefore a workaround.

There is another option. You can make the class an active class.

An active object is an object that, as a direct consequence of its creation, commences to execute its classifierBehavior

Many tools show an ExecutionSpecification covering the whole lifeline for an active Class. Maybe your Class is meant to be active?

PS: Of course, this is not completely correct, since the classifier behavior also needs to be started explicitly:

A StartObjectBehaviorAction is a CallAction that starts the execution […] of the classifierBehavior of an object

That means, it doesn’t start automatically. We need an ActionExecutionSpecification to start it. Very few tools support this :-(