I know that with Sequence Diagram, one can present some combined fragment such as alt (if/else), option (while), loop, break and parallel.
But is it possible to represent the following relation:
Actor sends 1 of the message from message set (3 messages).
In the screenshot, the actor wants to send TestOperation or TestOperation2 or TestOperation3, the reply would be the same in the complex system.
Is above possible or do I have to draw 3 sequence diagram with the only change being the message sent?
Thank you!
Simple answer: yes, you can do that. Since you use asynch messages the calls pile up. But that's only possible if the called object can handle concurrent calls. Or the other way around: it must be implemented in a way that it can receive asynchronous calls.
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.
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.
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.
I have a part of my program which can be called by various events. Each event however does something different before making use of this part. How can I represent these using a diagram? I was thinking of a flowchart but as far as I know a flow chart can have one start terminal, right?
Thanks a lot for the help,
Regards,
Krt_Malta
UML Activity Diagram.
http://www.ibm.com/developerworks/rational/library/2802.html
You have a "wait for event" node that has multiple incoming events. Each event has a different state transition.