UML sequence diagram - When to start and end activation box

Question

I am using the c language. I created one lifeline for each file. I am confused about the activation box. Many people said an activation box indicates an object is active and processing a task. In case of c language, can I say an activation box indicates a function is running?

For the example below, is my UML sequence diagram correct?

Diagram on plantuml.com

file1.c

void func1a(void)
{
    func2a();
}

file2.c

void func2a(void)
{
    func3a();
}

void func2b(void)
{
    ......
}

file3.c

void func3a(void)
{
    func3b();
}

void func3b(void)
{
    func2b();
}

Answer 1

1. Should I use a new activation box for func3b()?

Typically, yes.

Messages sent on their own lifeline have a special form. The lifeline then sends the recursion from an activity bar. While the activation is still running, a new activation starts on the same lifeline. Their starting point is the sent message, and you use this type of message, for example, if an operation is performed several times. Now, the object must refer to itself. Messages between two lifelines can also cause overlapping activations. The specifications of activations are described in more detail below.

^{Lifeline with recursion and overlapping activation The lifeline object sends a message pointing to itself. The second, overlapping activation receives the recursion.}
ionos.com - sequence-diagrams

In OOP they like to say message rather than method or function.

2. Activation box for file1 should be ended here or after func2a()?

End it after it ends. It ends after every thing it has called has returned. Unless you're doing some asynchronous concurrent multi-threaded thing.

Answer 2

There is no mandatory one-to-one mapping between code and UML. The question is what you want to express in UML: the low level implementation details as close as possible to your code? Or the higher-level design behind your code and the implementation language constraints.

The "activation box" ("execution specification" in UML-speak) shows indeed that some execution is happening on the lifeline:

• Since your lifelines corresponds to the file, if one function calls another in the same file, like with func3b(), you can represent it with overlapping execution specifications, as you did. However, if you want to document the high-level design, and if the functional decomposition of the same activity of file3 into different functions is only an implementation detail (especially if func3b() would be a static that is never called from elsewhere), you could as well keep the main execution specification.
• The same applies to func2b() in your diagram. If you document the low level function calls you should consider an overlapping execution specification, to be consistent with what you did with func3b(). But again, from a high-level perspective, you could consider that it's the same processing and that func2b() is just a message (implemented with a synchronous call) to be dealt with within the same processing.
• About the length of the box for file1, there is little said in the UML specs about time synchronisation between lifelines. The only thing guaranteed, is that things on the same lifelines are done in the expected order. You could therefore, end your execution specification just after the call.
  However, it is a good practice, to keep visual consistency between the lifelines, especially if those are expected to return and if you're interested in documenting low-level function calls. In the latter case, you should even consider to show the reply messages (even if return is void): These dotted arrows would go back from the end of the activation box of the callee, to the ongoing activation box of the caller. This practice would help, as the overlapping boxes, to represent the most accurately the details of the functions calling each other and waiting for the execution control to come back, if this is what you are looking for.

Answer 3

What you call an "activation box" is officially an execution specification. It marks the beginning and end of some execution.

Some people seem to think, that they should always be there. However, if you don't care about these occurrences, you don't need to model them. Do you care?

Since your functions are synchroneous messages, they should have a corresponding reply message. This also applies, when no return value is expected. The reply then simply means, that the recepient of the message finished processing the message.

You are not obliged to model reply messages. If however you want to show, that a message is being sent before replying, it might be necessary. For example, func3b() invokes func2b(). This is usually done before replying, so it is an important piece of information. Of course, the execution typically ends with the reply. So, it is not necessary to model both.

In your case func2b() is sent at the same time as the end of the execution specification. I don't think this is what happens in reality. There should be a small gap between func2b() and the end of the execution.

func3a() and func3b() trigger different executions. As I said, you don't have to model them, but in reality, there are two executions.

func2a() is synchroneous and therefore needs to wait for the reply. And the reply can only occur after all the other synchroneous functions have finished. This can somehow be guessed from the context, but it would be much better to show this by modeling the reply. Enlarging its execution so that it ends at the same height as those on the other lifelines has no meaning. Sequence diagrams don't define an ordering of occurrences on different lifelines. So, here a reply would definitely be necessary.

A complete model would look like this:

PlantUML

As I said, you don't need to model all executions and messages. However, you should make sure, that is unambiguously showing what you mean.