In my UML model I have a system and its subcomponents that talk to each other. For Example, I have a computer and a RC robot where they talk via Bluetooth. Currently in the diagrams the flow is something like:
"Computer" triggers "setVelocity()" function of "RC car".
At this point, I want to refine the communication by saying that
computer sends "Movement" message
with velocity field is set to 100 and direction field is set to 0
which is acknowledged by RC car by sending ACK message
with message id "Movement" and sequence number X.
How do I do that?
EDIT: Clarification
Normally this is what my diagram looks like without protocol details:
But when I tried to add messages, there are at least 2 problems:
It seems like Computer first triggered the setVelocity() funciton and then sendBluetoothMessage() sequentially which are not sequential . The followings of setVelocity() are actually what happens inside that.
sendBluetoothMessage() is actually a function of Computer. But here it belongs to RC Car. (or am I wrong?) And the same things for ACK.
Thanks for the responses. You are gold!
Communication protocols in general
There are two main ways of representing the sending of a movement message between two devices:
A movement() operation on the target device, with parameters for the velocity and direction. You would typically show the exchange in a sequence diagram, with a call arrow from the sender to the receiver. The return message could just be label as ACK.
A «signal» Movement: Signals correspond to event messages. In a class diagram, they are represented like a class but with the «signal» keyword: velocity and direction would be attributes of that signal. ACK would be another signal. The classes that are able to receive the signals show it as reception (looks like an operation, but again with «signal» keyword).
In both cases, you would show the interactions of your communication protocol with an almost identical sequence diagram. But signals are meant for asynchronous communication and better reflect imho the nature of the communication. It's semantic is more suitable for your needs.
If you prefer communication diagram over interaction diagrams, the signal approach would be clearer, since communication diagrams don't show return messages.
Why signals is what you need (your edit)
With the diagrams, your edited question is much clearer. My position about the use of signals is unchanged: signals would correspond to the information exchanged between the computer and the car. So in a class diagram, you could document the «signal»Movement as having attributes id, velocity and direction:
In your sequence diagram, you'd then send and arrow with Movement (X,100,0). Signal allows to show the high level view of the protocol exchanges, without getting lost on the practical implementation details:
The implementation details could then be shown in a separate diagram. There are certainly several classes involved on the side of the computer (one diagram, the final action being some kind of sending) and on the side of the car (another diagram: how to receive and dispatch the message, and decode its content). I do not provide examples because it would very much look like your current diagram, but the send functions would probably be implemented by a communication controller.
If you try to put the protocol and its implementation in the same diagram, as in your second diagram, it gets confusing because of the lack of separation of concerns: here you say the computer is calling a send function on the car, which is not at all what you want. The reader has then difficulty to see what's really required by the protocol, and what's the implementation details. For instance, I still don't know according to your diagram, if setVelocity is supposed to directly send something to the car, or if its a preparatory step for sending the movement message with a velocity.
Last but not least, keep in mind that the sequence diagram represents just a specific scenario. If you want to formally define a protocol in UML, you'd need to create as well a protocol state machine that tells the valid succession of messages. When you use signals, you can use their name directly as state transition trigger/event.
If you really want to display this level of detail in a sequence diagram, it would look like this:
Notes:
For an asynchronous call, use an open arrowhead.
Use stacked bars to represent the call stack.
In the operation's argument list, write "argumentName=argumentValue" or just "argumentValue".
For messages for which the exact operation name is unknown or irrelevant, I use just a description without an argument list.
But be careful about which level of detail you want to show. Often, a sequence diagram becomes too complex if you display every operation in the call stack.
I was dealing with the same issue. I searched online and couldn't find something that I like. Hence I come up with this solution.
I show the communication ports on the sequence diagram and I draw communication dependent steps among port lines.
Here is a screenshot: my version of your problem.
Note: I haven't used bluetooth before so I am not sure about the acknowledge step. If this is something done automatically by the hardware( Like in the CAN Bus) I wouldn't draw it like this. I probabily wouldn't show it or I wouldn't add the function acknowledge(); and just draw the line between bluetooth port life lines.
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 have a doubt to model my system using UML Sequence Diagrams (yes, I know the State Machine Diagram is simpler to do this, but I need a Sequence Diagram).
Consider a simple train door system, where there is (A) an automatic controller that issues a command to (B) a mechanical opener (an actuator) to open or close the door. The system has some (C) sensors - that send feedback informing if the train is stopped or not; if the train is aligned at platform or not; if there is an emergency or not; if the door is opened, closed or partially opened/closed and; if there is a person or object in doorway - and the (D) door itself.
The controller issues commands to open and close the door based on the feedback of sensors (e.g., if the train is stopped, aligned at platform and the door is closed, it is safe to open it). Therefore, I need to receive the feedback before send the command. How do I represent the sensors and its information in UML Sequence Diagram? Considering each sensor as an actor? Considering the feedback as an found message?
I cannot represent this using the "pure UML" and need to use some extension for Real-time systems?
Thanks
SOLUTION: I represented each sensor as a lifeline. They send feedback to the controller within a loop, and based on the feedback I am able to issue a command.
I am not sure if this is correct.
The sensor is a life line like any other object. It can send messages like any object. Most likely these will be asynchronous messages. But depending on the protocol this could as well be synchronous ones. If needed you can add timing constraints to the messages: https://www.uml-diagrams.org/sequence-diagrams.html
I think you might be looking for something like this:
It is generated by ZenUML. Just put the following code into the editor to generate the above diagram:
#Starter(AutomaticController)
MechanicalOpener.tryOpen(door) {
stoped = Sensor1.isTrainStopped()
aligned = Sensor2.alignedAtPlatform()
closed = Sensor3.isDoorClosed()
if (stopped_and_aligned_and_closed) {
open(door)
}
}
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.
It's the first time I draw an UML sequence diagram and I am not sure about few things.
I have a beacon which is a raspberry pi with bluetooth dongle. The server asks the beacon to start to change it's ID periodically(startIDRotation). The beacon broadcast and change them after each interval. When the smartphone wants to make a request, it includes the detected IDs, that the beacon is broadcasting in the request, with the requested file and send the request to the server. The server uses a logic represented in another activity diagram to decide if the user has access or not to the file and send back a response to the smartphone.
The first question is, is it correct to draw the line between the beacon and the smartphone? Because the beacon is not sending the IDs specifically to the beacon, it's just broadcasting them over bluetooth.
Is it possible to make a reference to another diagram type as the decision diagram is an activity diagram?
The server sends a post request to the beacon to start the rotation once, but it keep the state of the beacon and know that it's rotating its IDs. Shall this be represented as synchronous as I did or asynchronous?
If you have any other remark please feel free to correct me.
is it correct to draw the line between the beacon and the smartphone?
Yes. The line represents a message. And the life line represent an individual instance. When the phone receives the broadcast, this is the message sent. Since you did draw an open arrow, it indicates an asynchronous call. So that's perfect.
Is it possible to make a reference to another diagram type ? as the decision diagram is an activity diagram.
Yes. And you will do it the way you did, by adding a diagram reference. This represents details at the covered area. You can as well add arbitrary diagram references as shown below.
shall this be represented as synchronous as I did or asynchronous ?
It depends. Most likely you will have a synchronous communacation (closed triangle) here, because the server want's to know whether the message has arrived and the beacon acknowledges the start of the activity.
Yes, Beacon sends (broadcasts) an asynchronous signal to a Smartphone so there should be a message line depicting it.
By Ref you reference another sequence diagram. If you want to represent some behaviour (activity that is described with some activity diagram), use a synchronous request that pings back to the same lifeline (from Server to Server) with the call to activity responsible to perform privileges check. You can also put name of executed action inside the execution specification (make the thin rectangle somewhat wider to squeeze it in - see 17.2.4.4 in UML specification).
All your lines represent asynchronous messages. To show synchronous message use a solid line with a filled triangle as an arrowhead. To present response use dashed line with an open arrowhead. If your specific message should be synchronous or asynchronous depends on your needs. Broadcast is asynchronous all other can be either synchronous or asynchronous.
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.