I want to create activity diagram for information system that I have programmed.
Thing is, I have many functions that accept 3-5 input arguments and it is important for me to show them on activity diagram. How can I do that?
If I represent function as an action node, how do I represent 3-5 input edges and still make diagram readable?
Well, if your system is complicated, the model will be complicated, there is no way around it (unless a birds eye view suffices for your needs).
However, a diagram is not the model. You can choose to display only the information relevant for the viewpoint of the reader. For example you could hide all the Object Flows and only display the Pins. A good tool will then mark the Input and Output Pins with small arrows to indicate their nature.
You could also have a convention that all Output Pins are implicitly connected the one Input Pin with the same name and Type. Of course this convention should be clear to all readers of the diagram and the model should still include all Object Flows. Then you only need to show Object Flows, when the connection is ambiguous.
Finally you could combine the Types of the multiple Pins into one structured Class and thereby reduce the number of Input Pins to one per action. This could also help to find more meaningful abstractions. Of course this only works, when all Object Flows are originating from the same Action.
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 would like to to create a sequence diagram to show some interaction, and then use that sequence diagram as an interaction occurrence (sub-sequence) on other sequence diagrams. The point is I would like to apply the sub-sequence each time to a different object instance that is involved in the interaction in the sub-sequence. In my case the instances are simply various file artifacts. Is there any legitimate way of doing this prescribed by UML?
EDIT: some more clarification of my context:
I have 2 main sequence diagrams where I want to reuse the sub-sequence as an interaction occurrence
on the 1st main sequence there is one file for which the sub-sequence has to be applied 3 times
on the 2nd main sequence there are 3 different files for which the sub-sequence has to be applied 3 times
the files are read by the same object instance
I model reading from a file by a call arrow stereotyped as <<read>> to a on object instance which represents the file.
I need to reference the file somehow in the sub-sequence, but I haven't found a good and simple way of doing this.
Complicated, but formally (almost) correct solution with Collaborations
Just using InteractionUses is not enough, because this doesn't allow you to assign the actual roles in the main interaction to the generic roles of your used interaction.
Collaborations, CollaborationUses and Role Bindings can be used for this.
See my example here:
This defines a Collaboration with generic roles sender, relay and receiver and shows the interaction between them.
You can now use this collaboration in a concrete situation:
Class S uses the Collaboration two times with different role bindings to its parts (A, B and C are assumed to be able to send and receive Sig1).
With these definitions you can now create your main sequence diagram:
Unfortunately, this is not correct UML, even though there is an example in the specification (I filed an Issue https://issues.omg.org/browse/UMLR-768). You will have to fake this notation until the taskforce comes up with a fix. How to fake it, depends on how strict your tool implements the specification.
Advantage: formally correct and versatile solution, backed by an example in the specification
Disadvantage: complicated and difficult to explain, not completely usable, because of a bug in the specification
Basically there are three different ways to specify such situations.
Using a gate. Whith gates you specify the sequence with messages that start or end at a gate that is defined and in most tools (if usable at all) not shown explicitly. Instead it is modelled with messages starting or ending at the interaction border.
Similar as gates are lost and found messages. These are special messages that pass out the control to another sequence or returns from one. Such as in the case before you can define a set of further diagrams specifying the interaction in more details.
Using abstraction, which is my favorit for most of the cases. This means you extract the common interface from the classes and specify the interaction against the interface instead of the concrete classes.
Use an Interaction with Parameters:
Now we would like to reference the Lifelines of the main Interaction in the arguments of the InteractionUse. Unfortunately, in UML this is not possible, since arguments are ValueSpecifications and they cannot reference another modelelement.
However, NoMagic suggested and implemented an additional ValueSpecification, called ElementValue, that does exactly this. I think this would be a valuable addition to UML and hopefully it will be added some day. Up to then, only MagicDraw users can use this solution (as far as I know).
With this non standard element, we can model this:
The connection between the lifelines is now via the arguments for the parameters of the generic interaction. Technically the lifelines would not need to be explicitely covered by the Interaction Use, but I think that it makes sense to do it (shown in my tool with a non standard circle on the border of the Interaction Use).
Advantage:
compact and versatile solution, almost conformant to the standard
Disadvantage:
uses a non standard model element, currently only available to MagicDraw users.
pragmatic non conformant solution with covered lifelines:
The collaboration and parameter solutions allow to specify it (almost) formally correct. However, in many cases, a simplified model would be sufficient. In your case, for example, you only have two participants and they have different types. So, even though there is no formal connection between the lifelines of the used interaction, and those of the main interaction, there would be no ambiguity. You could use the covered attribute of the InteractionUse to specify, which of the lifelines (files) you are targeting at a specific InteractionUse. Could that be the pragmatic solution, you are looking for?
Advantage:
compact solution
Disadvantage:
not conformant to UML, ambiguous in more complicated situations
In UML Sequence Diagrams you have the combined fragment type Alt to branch based on different values for parameters. But let's say that in the middle of your sequence you are waiting for one of two different messages from two different external actors and you shall branch the code depending on which one arrives, what would be the best way to model this? And to make the question a little more challenging, let's throw in the possibility that neither message comes (triggering a timeout).
Without a better solution, I would divide the sequence diagram into multiple sequence diagrams, each new one starting with the one of the two possible messages. Or possibly just go over to state machines. But is their a not too convoluted way that would allow me to show these different cases within one sequence diagram?
I would simply go for the two SDs which you can name accordingly. One should always keep in mind that a SD shall highlight a certain aspect of a complex chain of actions in a system. Trying to put more and more information in a single SD will mess it up and hinder more than it helps.
It is also possible to use diagram fragments which allows navigation through zooming into the two fragments.
The timing diagram will not really help here. You would still need a large alt-fragment to show the sequences depending on which message arrived first.
In addition to the answer I referred in the comment, I made a little sample with a duration constraint for the timeout.
If you have a lot of conditional logic to show Activity Diagrams are an alternative. They do not have object responsibilities or a time axis, but because of this they can freely use two dimensions to show flow control.
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 simple flow which I would like to describe using UML in best way possible. I have no experience with UML and do not want to chose ridiculous diagram type.
DataA --> ProcessorA --> DataB --> ProcessorB ... --> DataN -->ProcessorN
In nutshell, Data is collection of data in some structure and Processor x transform input data into data to be used by Processor X + 1.
Where Data and Processor are actual classes and it would be nice to show how this works in code - for processing a certain data usually the new processor must be created with the data object, something like process() method invoked on it which returns data as input for next processor.
I tried to study dynamic UML diagrams but I am not sure which type is best to use for this.
Activity diagram is a perfect choice for data flow behaviors. You can use them to show everything you stated and lots more, especially if you complement acticity diagram with some other UML diagrams. In this case I would recommend class diagram, as these data structures are probably important and should also been specified.
Here is a simple example of your situation.
The following diagram is an activity diagram:
It is very intuitive and I guess you will be able to interpret it even without studying UML. Besides this simple sequence flow, you can also model paralel activities, choices (if-then for example), events, responsabiities, etc. You can even "open" the single activities and model then internally with another level of activities.
Those grey elements show the data that is flowing in and out of single actions/activities.
The best thing in UML is combining several diagrams to show different aspects of your problem. Here it is reasonable to somehow explain how the Data A, Data B and other data objects actually look like. In UML there is a diagram for this, a class diagram:
I showed just basic features here. Classes model complex data, are usually equipped with attributes and have realtionshipss of different kinds with other classes. Here you can see how the actial data look like (in contrast to activity, which shows what is done with the data)
Class diagram is one of the structural UML diagrams, while activity diagram is typical behavior diagram. They work best together.
I presume that the sequence diagram would be the best one for your case, because your lifeline would represent your object (or class) and the interaction message between your object would represent your method.
You would also have a chronology with this diagram. This diagram is focus on the interaction from your object.
You can see it : http://en.wikipedia.org/wiki/Sequence_diagram