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.
Related
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 :-(
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.
The picture is taken from the book "UML # Classroom". The text says "the registration is via e-mail, that is, asynchronous".
In actuality, I believe, there would be no "Student" and "Professor" objects involved in the process. Rather an interface, a call to a mail server and in general, nothing that would tell the viewer of the diagram what is really going on.
That makes sense to me because it has an illustrative purpose. The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
If I am tasked with a high level view of class diagram and high level sequence diagrams of a particular interaction, if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
The methods of the classes in the sequence diagram would only resemble the methods in a class diagram at a low level.
Not necessary, all depends on the goal of the sequence diagram, you can have classes at design level (may be allowing to generate code) but having them in a sequence diagram giving a semantic (high) level. You can also show these classes in class/package/... diagrams without low detail so not at design level.
The only rule is to have diagram saying something useful, and following UML specification of course. Do not forget UML is not a method but a language, it does not indicate how it must be used.
Remark you can put note in a diagram to help saying explicitly its level/goal in case you are afraid it is confusing because not 100% limited/dedicated to design even using classes part of the design.
if I am then asked why the classes of the class diagram don't have any of the methods of the sequence diagram, am I right to say that they simply don't have to?
yes, because the goal is not necessary to show a sequence of calls but for instance a higher level.
Should I reach a compromise with the sequence diagram wherein I try to make the calls similar to what will be going on in the program?
Of course you can do too.
Notice a sequence diagram (so in fact an interaction) has limited features, while for instance an activity allows to model a behavior in detail without the same limitations.
My requirement : I want to come up with a suitable UML diagram based on the case which is described below. I need to know which UML will best suit this condition.
The case : Two object A and B in the form of "Application Forms" interacts with each other.Certain event in object A triggers a state change of object B.Both object interacts with each other for a Use Case.
I tried using State Diagram but it fails as here 2 object interact with each other to change the state of one object, whereas State diagram is suitable to depict state change of one object only without showing interaction with another object which is causing state change.
My requirement is to show both interaction and state change together in the same diagram.Is it possible?
Any suggestion on this which UML diagram is suitable for this?
UML uses two different diagrams for each behavior, one for State (State Machine Diagram) and one for Interaction (could be the communication diagram or the sequence diagram).
Since the Interface of a class doesn't change when it's state changes (by applying the State Pattern for example), the interaction should not really change from the perspective of the caller, sure, internally all kinds of things might be going on, but that should not really matter.
The way I'd model this is to describe which states your objects are in and which scenario will play out. That will result in a few interactions and possibly state changes. Then pick a new scenario, either using the end-state of the previous one as a starting point, or describing a new starting state.
That way each scenario is clearly defined, the interaction diagram shows how the objects interact, and multiple State Diagrams with the active state highlighted can show the changes in state and thus behavior of the different objects.
There is no diagram that gracefully combines both, since one (the state machine) is a static diagram, showing all possible options, while the other describes the interaction.
Sure you could play around with creative naming, as suggested (ObjectA/State) as your different objects in the interaction type diagrams, but it would not result in a very clear picture. What you're trying to describe here is a story, a sequence of events and how those events impact the different states of the objects. So your scenario's are the story on a high level, the communication diagrams the stories on a much more detailed level and the state machine diagram the snapshots of specific situations.
Model your states in the state diagram as such: (Object / ObjectState).
For example:
States (A/uninitialized) , (A/initialized), ...
Should work then.
State diagram, sequence diagram, communication diagram and the whole answer by #jessehouwing is fine, but I think there is an easier and more natural way:
(1) http://agilemodeling.com/style/activityDiagram.htm, Figure 3. Submitting expenses
Note that this is UML 1.4 activity diagram. Current UML notation is slightly diferent. Dashed lines represent Object flow : Chapter 3.90.2.2 Object flow ...Objects that are input to or output from an action may be shown as object symbols. A
dashed arrow is drawn from an action state to an output object, and a dashed arrow is drawn from an input object to an action state. The same object may be (and usually is) the output of one action and the input of one or more subsequent actions...
and (2) http://www.uml-diagrams.org/document-management-uml-activity-diagram-example.html
show an examples of how you can combine object states and UML activity diagram. The pictures are activity diagrams and the orange rectangles highlight points where objects with states (the part in [some state]) are shown. The purple rectangles show authors who were robbed.
I have a equipment which I am representing with a class and there are two actors a remote and local operator who can put the equipment on or off. Both actors will use the functionality of the equipment. But How do I now represent them using sequence diagram, since if I draw an event from both local and remote its going to show at the equipment the one happened after the other but in reality two actors are using the same function and can invoke it any time. So how do I represent the two actors in the below sequence diagram.
P.S. The RAN40L is the equipment and CMS is remote operator and Simulator Operator is the local operator.
As it happens I have extensive experience from the defence industry, including naval CMS, so I am familiar with the domain.
The crucial question is, as always with UML, what you want to show in the diagram, which of course ties in with what you are showing in other diagrams. No diagram is ever read in isolation and you will never capture the entire radar functionality in a single sequence diagram.
Remember that a sequence diagram is intended to show things happening in a strict sequence. It is possible to show some rudimentary concurrency using the appropriate fragment, but if you want to show that the two actors do exactly the same thing, that the sequence is in fact one and the same in both cases, then the sequence diagram is the wrong place to show that.
Assuming that this sequence is intended as an elaboration of a use case, then the solution is to replace the two actors with a single actor, eg "Radar Controller". This actor can then be specialized into CMS and Simulator, which makes sense if the radar is unaware of, or unconcerned with, who is interacting with it in some (use) cases but not in others.
If the radar never makes the distinction, there shouldn't be two actors at all. The actors must make sense to the system they're interacting with, otherwise there's something wrong with your actor model.
So one solution is to structure the use cases as below.
http://sdedit.sourceforge.net/images/webserver.png
This is a good example where two actors are used. It is default to put one actor to the opposite the other (this is not done in the example).
Actor is considered to be just another object in the sequence diagram. You can plase arbitrarily many actors and use them just like any other object, no restrictions in this sense.
There are some stylistic guidelines though, most of all regarding Actors positioning on the diagram. It is a common practice to show the actores on the border of the diagram, keeping internal system objects inside. Moreover, human actors are typically shown on the left side, while system actors are kept on the right. Actors should not be "mixed" with system objects. Here is a simple example:
Everything in behavioral diagram is executed after behavior defined by diagram started.
If actors interacts individually, and their interaction are not moxed in single execution, you must draw diagram for each case.
I would say you need two diagrams, each for one actor.