2
votes

I would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?

EDIT: some more clarification of my context:

  • I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
  • on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
  • on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
  • the files are read by the same object instance
  • I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.

I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.

4
I'm not using that very often, but diagram gates should be what you're looking for?qwerty_so

4 Answers

3
votes

Complicated, but formally (almost) correct solution with Collaborations

Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.

Collaborations, CollaborationUses and Role Bindings can be used for this. See my example here: Collaboration defined with an Interaction This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.

You can now use this collaboration in a concrete situation: Collaboration uses Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).

With these definitions you can now create your main sequence diagram: Sequence Diagram with Interaction Uses Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.

Advantage: formally correct and versatile solution, backed by an example in the specification

Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification

2
votes

Basically there are three different ways to specify such situations.

  1. Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
  2. Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
  3. Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
1
votes

Use an Interaction with Parameters: generic Interaction

Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.

However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).

With this non standard element, we can model this: enter image description here

The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).

Advantage: compact and versatile solution, almost conformant to the standard

Disadvantage: uses a non standard model element, currently only available to MagicDraw users.

1
votes

pragmatic non conformant solution with covered lifelines:

The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?

Advantage: compact solution

Disadvantage: not conformant to UML, ambiguous in more complicated situations