I'm fairly new to Visual Paradigm and I noticed the auto-numberign feature on the messages of the sequence diagram, which I like a lot since it gives you a visual guidance specially when the diagram gets really large. Then I found myself in a situation like this one in this fragment where I did not agree with the number it assigned message PIN Entered. Although I thought I could just manually change it to what made more sense to me, a 1.4, my question is: is there a way to make VP notice the relation of continuity between Request PIN and PIN Entered without just adjusting the values manually?
Regarding on how to set different ways of numbering sequence messages in Visual Paradigm, you should read the section "Setting different ways of numbering sequence messages" from the How to Draw Sequence Diagram? guide from Visual Paradigm.
In summary, just right click on the diagram's background, select Sequence Number and then choose your option from the pop-up menu.
Regarding your specific example, as #sim has already answered, the diagram you have provided is wrong. If we read just the diagram, it says:
The card is inserted by the ATM Customer to the ATM.
The ATM verifies the card with the Bank.
If the card is valid, the ATM asks the ATM Customer for the PIN.
If the card is invalid, the ATM ejects the card.
Anyway the ATM Custumer enters the PIN.
It only makes sense that the ATM Custmer enters the PIN only when the card is valid. Therefore that sequence message (that reply) should be a reply to the Request PIN message. Something like this:
And as #Sim has also already suggested, it's a good idea to use separate sequence diagrams for different scenarios.
Obviously you are using the sequence diagram as an analysis tool, not a design tool. In such a usage it can be ok to use the syntax in a less strict form. Thought, this makes it hard for a program to determine what you are modelling and what is your intended sequence.
In your modelled sequence, you return a PIN in the reply message 2.2, but this makes only sense as reply to message 1.3. As message 1.3 and 2.1 are different, it is not possible for a program to determine to which message the reply message belongs. I propose to clean up the diagram and e.g., abort after returning the card or even better, use seperated sequence diagrams for main success scenarios and aborting scenarios.
Related
I have a flow of events and alternative events for a Login use case.
Basic Flow:
The actor enters his/her name and password.
The system validates the entered name and password and logs the actor into the system.
Alternative Flows:
Invalid Name/Password: If, in the Basic Flow, the actor enters an invalid name and/or password, the system displays an error message. The actor can choose to either return to the beginning of the Basic Flow or cancel the login, at which point the use case ends.
I come up with this diagram:
I was said that there is no need for an intermediate Login Screen life line. How should I design the diagram now, according to conditions given above?
This diagram is not bad. It is however somewhat confusing, because:
Login is not really a use-case, even if it's a popular practice. This has however no impact on your SD diagram itself.
Showing actors in a sequence diagram is not formally correct, even if it's a popular practice.
Login Screen is in fact a part of System, which creates a kind of implicit redundancy.
Don't worry about too much about the two first points, if this is the kind of practices that your teacher showed you.
The last point could easily be addressed:
The last lifeline could be more specific about the internals (example here), or,
Keep only two lifelines, one for the actor and one for the system. THis is in my view the better alternative when you use actors in a SD.
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.
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 an analysis exam tomorrow and one of my designs is a sequence diagram. I do not know if I have got it right. Its pretty simple, its supposed to illustrate a teacher who creates an assignment and posts it to a schools website, then a student gets a notice and the teacher is able to edit or add more files to the assignment. Repeat
Is it something wrong with this diagram? What could I have changed?
What are some key points about sequence diagram that I could say in my oral exam.
Strictly speaking, what you draw is NOT a sequence diagram in UML spec. There are more than one correct ways to draw a sequence diagram for a given flow.
Here is a sequence diagram I created with ZenUML (I created this tool btw). There are a few key items in a sequence diagram - lifeline, message and fragment.
This answer is certainly late for the exam, but your diagram looks ok. For the sake of completeness, here some minor remarks:
the messages are certainly all asynchronous (i.e. the website will not wait for the student to answer the notification before it continues its job); so the arrows should have an open head
you could consider using a combined fragment (with operator loop) around the interactions related to the addition of a file, to show that this part may be repeated.
all messages in your diagram describe interactions. The wording "web page is updated" suggests a state, whereas a wording "notify student of the update" would be more consistent with the rest.
the first execution occurence ("activation bar" on the lifeline) on the website should start with the incoming message that triggers the related activity. Similarly, for the student I'd put a small activation bar after each notification, instead of a continuous one.
I have made an activity diagram for gym management, but i am facing a problem how will i connect Receptionist with Admin, According to requirement activity between Admin and receptionist takes place only through notification and i have made a signal and receptor for notification. Please also check if every notation is right and suggest me for modification?
I am sorry for not answering at once - several times had I looked at your picture, and, frightened, retreated.
You really tried and did something. It is good. But... You have put Use Cases directly into the activity diagram. So as is, it has no sense.
Let's take a customer. He has his swimlane. Good. According to your diagram, the customer comes and decides, what to do - immediately leave, join or inquiry. It doesn't matter, if he joins or inquiries, the result is common (why had he been choosing?) - he gives some unknown message to the receptionist. He never gets something back, never he does smth. else, he remains here and becomes immortal, because even his death won't finish his state of being here, waiting for some reaction from anybody. Poor man!
I don't think it is necessary to analyze here other swimlanes - they are even worse.
Better divide your work into levels.
Use Case diag. Define, who are actors (you have defined them well) and what are their interaction with system and its parts.
As the next stage you can make a deployment diagram - where are components of the system and maybe, actors, located and what messages they send to each other, defined.
And only now you can start with Activity diagram.
Also notice, that you'll have to return and correct the elders diagrams when you'll come to a dead end or some radical changes in the younger ones. You'll meet with both, be sure.
And when you have some problem with some diagram, come here, write down what you had BEFORE it (you didn't), what you have done on this stage (you did it) and we'll be able to help.