How to show C++ operation call stacks from object to object?

[F@lk]

Hi,
I tried a communication diagram to show how important C++ call stacks are wired between C++ objects. How can I illustrate the important fact here that method call a.op1() leads to method call b.op3()?

My first attempt was to create an accociation arrow between both objects, a and b, but how to label it in a way that op1() leads to op3()? I want to use the methods and attributes for that which I have parsed from the C++ code.

The scenario is this one:

Code: [Select]

class A {
   void op1() {
       op2();
   }
   void op2() {
      b.op3();
   }
   B b;
}

class B {
   void op3() {
   }
}

A a;


[F@lk]

Code: [Select]

+------+                +------+
|      | op1         op3|      |
|  a   #----------------#  b   |
|      |                |      |
+------+                +------+

If # were ports in my sketch, I could label them with op1 and op3 and connect both ports with an accociation. But this looks wrong to me.

[Geert Bellekens]

I would use sequence diagrams to show that aspect.

Don't try to add that to your class diagrams, as that will completely clutter things (what if you have 5 operations that each call 3 other operations?)

Class diagrams are meant to convey the structure of your system. Use a single dependency to indicate that A uses B in some way, but leave the details in the behavioral diagrams. (communication diagram, sequence diagram)

Geert

[F@lk]

I would use sequence diagrams to show that aspect.
Geert

Sequence diagrams do not provide free placing of the objects, which is very obstructive. The time aspect is not what I want to show, but I want to show how key operations of objects are wired. The interesting thing is just, a callstack begins with a certain operation and ends with a certain operation.

[Geert Bellekens]

The interesting thing is just, a callstack begins with a certain operation and ends with a certain operation.

Which is exactly what you can show in a sequence diagram.
I'm not sure if there are other diagrams that can illustrate this better.

Geert

[Uffe]

Hey guys,


Operations exist in UML, but not as first-order entities. Meaning they're not represented by elements and can't be the endpoints of connectors. This isn't a problem in and of itself -- you can simply decide to use some element to represent your operations -- unless you have your operations already represented in the proper UML way.

If you've got the operations modelled as UML operations (in class elements), you can use CallOperation Actions in an activity diagram, associating the actions with the actual operations as if they were classifiers. You can also drag-and-drop the operations directly onto the diagram to create the actions.

These actions don't represent the operations, it is important to note, but the operation calls. But you can use this notation with all the other features of activity diagrams, so you can create loops, branches (decisions), etc etc. There is some level of automation so if you rename an operation its actions sort of change name as well, but I don't think you can automatically get pins for the operation parameters or anything like that. But if your focus is the control flow rather than the data flow this shouldn't be too much of a concern.

HTH,


/Uffe

[F@lk]

If you've got the operations modelled as UML operations (in class elements), you can use CallOperation Actions in an activity diagram

An activity program means the blocks are events which happen at a certain time, and the arrows give the path of how the timeline runs from even to event. This means an activity diagram is not what I can use, because I don't want to show events in a timeline. I want to show the spatial structure of the program, which means the class instances living in the program, independently of the time. And I want to show important callstacks, starting from one object via several method calls to another object aiming in a target method call.
So the start point of the arrow is in my example A::op1() but the end point is B::op3().
I notice I cannot use a communication diagram for this because there is no concept of arrows which have a different meaning of the start point than the end point, but an arrow is always a single method call in such diagram type, which is a restriction that makes it impossible to model software call stacks between objects.

[Uffe]

I want to show the spatial structure of the program, which means the class instances living in the program, independently of the time.

This doesn't make sense. Instances are by nature time-dependent: they get created, exist for a time and then they are deleted. Classes are independent of time, but instances are not.

And I want to show important callstacks, starting from one object via several method calls to another object aiming in a target method call.
So the start point of the arrow is in my example A::op1() but the end point is B::op3().

This is not permitted in UML. Connectors link elements, they do not link operations (or attributes).

EA does have the Link to Element Feature function, which allows you to pseudo-link a connector to an attribute or an operation, rather than to the element as a whole (pretty much a direct violation of UML syntax). But that only works with attributes/operation defined in the element -- ie classifiers, not instances, and not inherited features. So if you want to use that function you'll have to use classes, not objects.

/Uffe

[F@lk]

I want to show the spatial structure of the program, which means the class instances living in the program, independently of the time.

This doesn't make sense. Instances are by nature time-dependent: they get created, exist for a time and then they are deleted. Classes are independent of time, but instances are not.

When I want to show the scenario of all important objects in my software, and when I want to show in my diagram how they are connected to each other by important method call chains (callstacks), I need a structure diagram. I can for instance have 3 objects of the same class which are all processed by a relevant method call chain (callstack), pipelining so to speak.

And I want to show important callstacks, starting from one object via several method calls to another object aiming in a target method call.
So the start point of the arrow is in my example A::op1() but the end point is B::op3().

This is not permitted in UML. Connectors link elements, they do not link operations (or attributes).

EA does have the Link to Element Feature function, which allows you to pseudo-link a connector to an attribute or an operation, rather than to the element as a whole (pretty much a direct violation of UML syntax). But that only works with attributes/operation defined in the element -- ie classifiers, not instances, and not inherited features. So if you want to use that function you'll have to use classes, not objects.

/Uffe

At present I used the port connectors for my purposes, and connect 2 ports with a call chain accociation, and label the outgoing port of object 1 with the name of the lowest callstack method, and label the incoming port of object 2 with the name of the highest callstack method.

Code: [Select]

+------+                +------+
|      | op1         op3|      |
|  a   #----------------#  b   |
|      |                |      |
+------+                +------+
(# is that port quad. I know port has actually another UML meaning but I raped it for the sake of the missing UML feature)

[KP]

*snip* for the sake of the missing UML feature)

Well it's not really missing. Call charts existed well before UML - certainly, one of the methodologies I used in prehistoric times before UML had them (SASD? Yourdon?) - and the UML authors would have been well aware of them and would have made a conscious decision to leave them out.

I personally would either use CallOperationActions on an Activity diagram linked by something like a <<call>> Dependency, or use EA's profiler against running software.

[F@lk]

I personally would either use CallOperationActions on an Activity diagram linked by something like a <<call>> Dependency, or use EA's profiler against running software.

Do you mean such construction, where a and b are class instances and op1 and op3 are actions (all created by drag'n'drop from the model tree which was created from parsing the C++ source code)?:

Code: [Select]

+------+                +------+                +------+                +------+
|      |          use   |      | control flow   |      |           use  |      |
|  a   |--------------->|  op1 |--------------->|  op3 |--------------->|  b   |
|      |                |      |                |      |                |      |
+------+                +------+                +------+                +------+



[KP]

No, I meant something like this (no control flows)

Code: [Select]

+------+                +------+
|      |    <<call>>    |      |
|  op1 |- - - - - - - ->|  op3 |
|      |                |      |
+------+                +------+


But whatever works for you is fine

[F@lk]

No, I meant something like this (no control flows)
... snip...

aha OK, you meant a "dependency" with stereotype "call". Hmm, I tried it but must say it is very time-consuming to create a diagram this way, because depedencies as calls are not part of the toolbox but I have to go quite deep into the submenus to do such setup.
When I additionally create the caller objects of such call actions, it turns out it's also time- and space-consuming to create a diagram with 10 objects each one having 3 calls. I wish there was better modelling support especially for software.

[F@lk]

But whatever works for you is fine

This is the background of it all: https://www.dropbox.com/s/zp6rsqktc0uu8jt/20201211_094700.jpg?dl=0

You can see, first I used classes and ports to (wrongly) use them to show important call stacks in my software.
Now when I try to use proper UML syntax for call stacks by using objects, actions and dependencies of stereotype <<call>> you can see it all becomes quite space-consuming and hard to create. You know, it's just a part of the actual diagram which actually shows the survey for all 15 main objects we have in the core software, and how the control flow via the main calls is wired. I wish there was more support for such stuff which is essential for software modelling, because I have the patience but my team mates have not. They refuse UML because it's all so complicated to fastly create a diagram e.g. showing how objects are wired with important calls. ...And it takes so much space now while it could be smaller if you look at my first attempt which is the upper diagram.

(P.S.: The object "ProcessingFinished" in the lower diagram is actually a sub-object, and two such objects are connected with a signal-slot call mechanism. "Enqueue" is a method of the base class of the object.
BTW: Another big issue with Sparx EA is the problem that I have to manually rename actions if I rename methods and attributes of classes in the model tree. Actually a killer if one has 20 diagrams and has to refactor all UML actions after renaming class methods.)