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.
Related
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.
I am developing a simple microservice that has a cyclical nature:
waits until someone pubblish a message on an MQTT topic
performs actions
sends a reply and then waits for the next message
I need to share with others all the steps of creating this microservice.
I was thinking of using an activity diagram but all the examples I found don't seem to cover this type of behavior.
What is the more appropriate UML diagram to describe cyclic operation and why?
One thing to keep in mind is that there is no command to stop receiving messages, it starts receiving as soon as it is started and stops only when it is terminated.
You decribe the details of an activity that is best modelled with an activity diagram.
There are more than one way to model your case. For example:
The cyclic nature of what you describe is already an implementation view: you imagine a loop in your code that repeats the steps. You can show such a control flow in your diagram if you want.
You could as well model a single iteration as an activity, and consider that the activity starts when there's something to process.
Finally, you could use object flow and their build-in bufering capabilities to model the full system including your queue.
This is best modeled by using an activity diagram.
Waiting for an incoming message can be modeled by an Accept Event action. Sending back a reply can be modeled by a Send Signal action.
The pictures below are almost equivalent. The left picture starts processing an incoming message even when the processing of the previous message has not yet ended. The right picture waits for the previous message to be fully processed and then starts accepting a new message.
I would recommend the picture on the left, because it is the simplest. If you want to stress the cyclical nature, or if it is important to convey that the service only processes messages one by one, you could choose the picture on the right.
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)
}
}
I am working on representing interactions of a system that pulls conversations using webhook events in a system sequence diagram.
The actors of User, The system and the External System that sends webhook events that i have registered too already.
Is there a way to represent that or should i don't represent it at all since it's a system - system interaction only and it's not fired by the user?
A Webhook is usually an HTTP call. HTTP calls are synchronous. Synchronous messages are represented in a sequence diagram by an arrow with a filled triangular arrowhead (as opposed to asynchronous messages, which have an open arrowhead).
If you want to represent a Webhook event in a sequence diagram, you must draw the sending system and the receiving system as lifelines and draw an arrow from the sending system to the receiving system.
You may also choose not to represent this message at all. It depends on the audience. Who is using your sequence diagram? If they may be interested in the Webhook, then draw it. Otherwise, don't draw it.
I am new with UML and trying to draw an action made by the actor itself, and not sent to another actor. In this very simple example:
after receiving the code, the server has to verify if the userCode is equal to code. If this is the case, the server has to add the user to the verifiedUserList. It should be something like [userCode == code] addToVerifiedList(userid).
Is it possible to draw such a scenario or sequence diagram to concentrate only on the communication between different actors?
I am also not sure if the triangle should be filled or not. I use a REST web-server to perform POST and GET request for all the communications, is that considered as synchronous or asynchronous?
You can model it like this:
The alt fragment here has an ok part, where the addToVerified operation is called (a self-call). In the else part some error action is taken. And the return to the user will likely contain some informative message, which is not explicitly shown here.
The filled message arrows means, that the operation is executed synchronously. The open arrows denote asynchronous operation. I'm not that firm with HTTP protocol, but IIRC, POST/GET are both sent asynchronously and the difference is just the URL creation. Also the return message from the server will be sent asynchronously.