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?
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.
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 :-(
Related
in uml - system sequence diagram, can the system ask input from the actor (see attached picture)
In my example, the scenario is: system is prompting a confirmation input from user and user is to enter in the input.
Wondering if this is the correct representation for it? I asked as usually I have done it the other way round, in which actor gives input to the system and system return the output based on input...
Preliminary remark
The practice of showing an actor in an interaction diagram is well accepted and quite common.
Nevertheless, in principle, an UML interaction diagram such as a sequence diagram, should show interactions between lifelines within an enclosing classifier:
The actor being external to your system, it’s not a part of any enclosing classifier in your system.
As a consequence, this is valid UML only if the scope of your model is larger than the IT system, i.e. you model the organisatiin that uses your IT system.
Moreover the message semantic is not clearly defined for human participants, which is exactly the issue behind your question
Be consistent
If you choose to go on with your modeling approach and consider the actor as any other classifier, then your actor instance should behave as any other object.
The flow of messages shows which object is the sender of the message and which object responds. You should consistently keep this logic, as you did in your diagram. It will be btw one of the rare place on your model where you can show that the system is at the origin of this specific interaction and not the user. (hint: don’t forget the execution specification on the lifeline: it’ll increase the readability)
If you would materialize the free-will of the actor by an arrow/message in the opposite direction, you would only increase the ambiguity further: this would give the impression that the actor is at the initiative of the message, and that the actor could send a completely different message instead. And I’m not sure that your system is designed for responding to arbitrary messages from the user.
Another alternative?
A less ambiguous alternative could be to show the interaction between a system core element and an element that represents the UI: the UI element acts as proxy for the user, but since it’s an object like any other, the interpretation of message flows is unambiguous.
This is one of the idea behind the ECB decomposition, the C being a use-case specific controller (so it links this interaction to the requirements) and the B being the UI boundary exposed to a specific kind of actors (without entering into UI details).
Short Answer: Yes
Of course, the context of this interaction cannot be the system, since the actor is outside of the system. However, it is allowed to not model the context and let the interaction be its own context. Or you could introduce a Context Class, that contains the Actor and the system. But these are only formal considerations.
More important is, whether it is useful to do this. I would say, it can be. Describing how an actor will interact with the system is one outcome of analysing the use cases. Many people will use text to describe this, but in complicated cases, UML behavior diagrams, like activity diagrams or sequence diagrams can be used.
I would reconsider using a synchroneous message here, though. Communication with a human actor is by nature asynchroneous. You never know, whether the message arrives, whether the actor understands it and whether the actor responds with the appropriate reply message.
PS: The reply message should show the name of the message it replys to, not some arbitrary text. If you want, you can show the return value after a colon (confirmationInput():Answer)
Confirmation is vague.
As a response to user input this part would be missing in your SD. Being incomplete would not be wrong. In that case you just describe that part which starts from the confirmation.
As part of some system activity (e.g. you have a control process which detects over-heating and asks the user to continue with a shut down or so) that part would not show the start of the use case being likely something like "Observe XY".
In any case using system as life line to the right seems pretty much pointless. One would be interested in which object of the system is asking for confirmation.
The question is always: what does the editor of the diagram want to tell someone else.
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.
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:
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:
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:
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
Basically there are three different ways to specify such situations.
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.
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.
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.
Use an Interaction with Parameters:
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:
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.
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
A common multi-threaded implementation is to have some class where Method_A() is running in a thread and sits blocked waiting for some signal/event member variable (e.g. WaitForSingleObject).
Interacting classes running in different thread will then call Method_B() which does some work, sets the signal/event variable, perhaps does some more work, then returns.
How do I represent this interaction on a Sequence Diagram?
Should I have two lifelines, one for each thread, even though they are operating on the same instance of the class? My modelling tool (Enterprise Architect 12) doesn't allow the same class to appear twice on a Sequence Diagram, so seems to discourage this.
Edit: Geert has noted that the Sequence Diagram should use instances, not classes, which is a fair comment. However the problem is the same: multiple lifelines would imply multiple instances, but in the question Method_A() and Method_B() are operating on the same instance, just from different threads. How can that be represented?
The approach I have decided to take is to add two lifelines for the same instance, then label one lifeline with the <<thread>> stereotype and add the thread it runs in to the name:
I realise this is probably not standard UML, but it seems to get across all the information I want to express in a clear manner, which is the most important thing, right?
Martin Fowler does mention a few times in his book that sometimes a non-normative diagram is actually clearer. So that's my excuse. :)
(Edit You can solve it by just using asynchronous messages as #sim points out. That will just do. The answer below is showing what is going on under the hood. So if you don't care about the details, go with that answer.)
You are asking more a design than an UML question. Namely, how do concurrent instances talk to each other. You said first
Method_A() is running in a thread and sits blocked waiting
which simply means that it can not accept anything since it is blocked. Now, guessing from the context of your question, I assume that you still want to communicate with that instance since
in different thread will then call Method_B()
So, in order to be able to accept a message the instance must be in an appropriate state. There are a couple of ways to achieve that. One simple is, if the according OS has support for that, to return to the scheduler and tell him that it's waiting for some message.
Now when method_b is being called you know inside Object1 that you are in some kind of idle state inside method_a and do appropriate (return-) action.
Another way would be to poll the scheduler for incoming messages and handle them.
You need to keep in mind that sending a message usually not directly deals with the instance but tells the system scheduler to interact with the appropriate instance (at least in most OSs).
I just remember from the Modula2 compiler I once wrote that it has a concept of coroutines which allows a concurrent thread to run within the compiled code. But basically that is just mapped to two independent threads running under the hood of a semi-single one and you'd depict that with two life-lines when going into detail.
N.B.: Rather than method it should be operation (since that is was is invoked by a message; while the method is what is implemented inside the operation). And as per common convention they should start with a lower case char.
And also: do NOT use classes in a SD. Unfortunately EA still allows that (why? Ask them!). Somewhere hidden in their docs there is a sentence that you must use instances. Else the model will break. A SD is always (!) a sample sequence of instances talking to each other. Classes do not talk, they are just blueprints for the instances.
You should never use classes in sequence diagrams, but instead use instances/lifelines that have your class as classifier.
If you hold the control down when dragging a class to a sequence diagram you can choose to drop is as instance instead of as class.
This way you can add as many as you want for the same class.
The notation you are looking for is an asynchronous message. You could theoretically express this using a single lifeline. But this wouldn't be readable. So a possibility would be having two instances of a threadclass in your class and show the interaction between the instances. But never show classes in a sequence diagram.
But why are you using a sequence diagram at all? For such internal behavour an activity diagram is most likely more appropriate. There you can use send and receive messages elements to express such a behavour per thread. Or if it shall be shown in one diagram, you can use fork.
In a sequence diagram, when should a message originate from an occurrence specification and when should it originate from an execution specification?
Likewise, when should the message's target be each of the two?
Clarification of terms
I understand that the terms occurrence specification and execution specification might not be familiar to most, as such I point them out on a sequence diagram.
In the following depiction, there are two messages (marked in red):
m12 which leads from and to occurrence specifications, and
m2 which leads from an occurrence specification to an execution specification (the cyan-coloured block).
(source)
Most tools capable of drawing UML sequence diagrams place an execution specification on both sides by default -- why is that? -- as is the case with Visual Paradigm
and MagicDraw
A nice summary of the terms is found at uml-diagrams.org.
The UML spec says on pp. 578
An ExecutionOccurrenceSpecification represents, on a lifeline, the start event or the end event of an ExecutionSpecification.
and
An ExecutionOccurrenceSpecification is represented by the start or finish endpoint of the vertical box for an ExecutionSpecification on a lifeline. See Figure 17.2.
So they just mark the point in time when something happens. Actually there are a number of examples in the spec where timing constraints are also applied in conjunction with ExecutionOccurrenceSpecification.
On p. 567:
ExecutionSpecifications are represented as thin rectangles (gray or white) on the lifeline (see 17.3.4 (Lifeline)).
We may also represent an ExecutionSpecification by a wider labeled rectangle, where the label usually identifies the action that was executed. An example of this can be seen in Figure 17.16.
Simply speaking: there is something happening in a black box.
Now for an OccurrenceSpecification there is a recursive definition in the specs on p. 566:
The semantics of an OccurrenceSpecification is just the trace of that single OccurrenceSpecification.
The understanding and deeper meaning of the OccurrenceSpecification is dependent upon the associated Message and the information that it conveys.
(Wow!) But then on p. 567:
OccurrenceSpecifications are merely syntactic points at the ends of Messages or at the beginning/end of an ExecutionSpecification.
Actually an OccurrenceSpecification is just a more general form of the ExecutionOccurrenceSpecification.
While fig. 17.2 uses ExecutionSpecification the following figures 17.3 etc. do no use them. So you are free to use them at your will.
The point where the message starts/ends is always an occurrence.
The execution specification shows the instance that is active. For the initiating instance it is not defined if there should be an execution occurrence or not. Thus various case tool developers took various approaches. If you can decide, you can depict if the instance remain active (e.g waiting for an answer) but that's modeler's choice.
Your question was, why some tools show execution specifications on both sides. The reason is simply, that their support for Interaction Diagrams is sorely lacking. Neither the sender nor the receiver of a message is required to execute anything, thus no execution specification is necessary.
While it might often be the case, that the sender executes some behavior, in the course of which some message gets sent, and that the receiver of a message executes a behavior in reaction to receiving a message, this is not always the case. The sender might send spontaneously and the receiver might ignore the message. Even if something gets executed, the modeler might choose not to mention it. An Interaction diagram shows some interesting occurences, but it is by no means required to show all possible occurrences.
A message might start or end at an ExecutionOccurrenceSpecification, but it could also just be a MessageOccurrenceSpecification. An ExecutionSpecification could also be independent of a Message. Maybe the modeler wants to express, that an Object is executing something, whithout beeing disturbed by any messages. It is even possible to define the behavior that is being executed. However I have not found a tool that supports this mandatory feature of UML.
So the answer is, that the tools should allow any combination of Messages and ExecutionSpecifications, since it is entirely up to the modeler, which Occurrences she wants to show.
I have a question regarding UML Sequence diagram.
Let's say we have an object Customer, KioskUI, KioskService and the KioskService has the last process called showNotification(); does the method showNotification goes to the Customer object or KioskUI?
If KioskUI, does the object have to return a variable to the Customer object as "<----- notification", or we no longer have to return something from the KioskUI to the Customer?
Since sequence diagram only focus on how process operates with one another my other question is, is a tangible object like a printed report is no longer needed to be shown in the sequence diagram or does it have to?
In object oriented systems it is good to see sequence diagrams as depictions of objects sending messages to each to communicate.
Arrows in these diagrams show the sender/receiver relation between objects in time, where the label for the arrow depict the message itself, e.g. a method call with arguments.
You are asking if the backwards arrow should point to KioskUI or the Customer object. The answer is simple, it depends on who sent the message, e.g. where will the method call "showNotification()" return. You have to decide this, but I guess KioskUI is a natural choice.
So the answer is, you should show the backwards arrow to the Customer only if there was an forward arrow from Customer (this should be depicted using the box on the lifeline unless it was an asynchronous call).
What is needed to be depicted in a diagram is always a choice depending on your need and UML makes no difference as long as it is a Classifier I guess, which means anything which can have an instance can be there - classes, components, actors, nodes,... For example I saw many use case realizations done as sequence diagrams with actors as objects with lifelines.