I have found in internet the following activity diagram:
I can't understand why from Recieve order action there are two control flows (to Ship order and Bill customer). Are they parallel? Then why there is NOT fork. How to understand this diagram? Please, explain.
This is simply a bad example.
Judging from the context there should be a fork to indicate that both Ship order and Bill customer should happen in parallel.
Then there should be a Join before Send confirmation to indicate that both flows should have finished before the Send confirmation is executed.
It's perfectly valid UML 2. The first action requires no tokens, so it can start immediately. When the first action finishes, it offers tokens to two other actions and they can start. The last action cannot start until all required tokens are offered. When the last action is done, the containing activity is also done.
Forks just copy tokens. Joins just merge tokens. Thus, forks and joins are often unnecessary.
Please see Conrad Bock's excellent series of articles on activity diagrams in the Journal of Object Technology.
I did not check if this is a recent amendment to the UML specification but the current version 2.5 (chapter 15.2.3.2) states (emphasis set on my own):
As an ActivityNode may be the source for multiple ActivityEdges, the same token can be offered to multiple targets. However, the same token can only be accepted at one target at a time (unless it is copied, whereupon it is not the same token, see ForkNodes in sub clause 15.3 and ExecutableNodes in sub clause 15.5). If a token is offered to multiple ActivityNodes at the same time, it shall be accepted by at most one of them, but exactly which one is not completely determined by the Activity flow semantics. This means that an Activity model in which non-determinacy occurs may be subject to timing issues and race conditions. It is the responsibility of the modeler to avoid such conditions in the construction of the Activity model, if they are not desired.
From that point of view, I would argue that #Jim L.'s answer might be deprecated. I assume that, at least in the current version of UML, the diagram in question does not reflect the modeler's intention. A fork seems to be not only the clean way but the only right way to go, now.
Related
I have two flows going to the same action. The action is Make Payment. One flow is for rent, and other is for purchase. In both cases customer has to pay. I want to use one payment action for both flows. Or should I use merge node and then connect the output to make payment action. I am not sure whether I can use merge node or not, because both flows are independent of each other. I have uploaded a picture.
This one caught me on the wrong foot. When there are multiple unguarded transitions going out of a state/action an implicit fork is issued so multiple tokens leave and travel independently. P. 401:
When an ExecutableNode completes an execution, the control token representing that execution is removed from the ExecutableNode and control tokens are offered on all outgoing ControlFlows of the ExecutableNode. That is, there is an implicit fork of the flow of control from the ExecutableNode to its outgoing ControlFlows.
I seemed to remember that analogously two incoming transitions mean that both have to deliver a token. And reading on (above) on p. 401:
An ExecutableNode shall not execute until all incoming ControlFlows (if any) are offering tokens. That is, there is an implicit join on the incoming Control Flows. Specific kinds of ExecutableNodes may have additional prerequisites that must be satisfied before the node can execute.
Now when you look at p. 425 you find
A merge node is a control node that brings together multiple alternate flows. It is not used to synchronize concurrent flows but to accept one among several alternate flows.
So here you are. You need to merge beforehand to make it correct.
N.B.: If you are modeling informally (so in a certain domain where this is documented) you could live with your notation since it's often used. Theory and practice... It's not recommended, though.
Just to add to Thomas Kilian answer
Can you model like that at all? Yes. But it will mean implicit Join so both flows has to complete in order to start the Make Payment action. This is allowed but not what you want to achieve.
Can you model like this in your case? No. This will have a different behaviour than what you want to achieve (join rather than merge).
Can you use Merge node before the activity to obtain expected results? Yes, that's absolutely correct and preferred way of merging flows when we want to continue when just one incoming flow completes. The fact that the flows are separately triggered does not pose a problem.
Can you achieve the same without Merge node? Yes, you can use parameters and parameter sets. You can use one parameter and the flows coming to that parameter create an implicit merge. Also if you have parameter sets defined action starts when all parameters of just one parameters set is offered a token but that means different sets of parameters are passed with different flows. Yet the approach with parameters is possible only if you have some parameters to pass. Besides it'll more difficult to understand so I would discourage such approach until you really know what you're doing.
After searching the net and a couple of old fashioned books I own, I still haven't found my answer to how to model an activity for a specific use case.
I am fairly new to UML and thus activity diagrams.
The activity is Add hotel. This is fictional, but the issue is exactly the same as my issue. My contract prevents me from talking about the real deal to third parties.
In this activity the user provides necessary details and has two optional actions that he can choose at anytime while in the Add hotel activity:
Add hotel chain
Add loyalty program
As said these are optional and not mandatory. The user is also able to proceed to save the entered data.
However, when choosing one of these actions, I imagine another activity diagram should be invoked, named the same as the choice the user made. In this activity all relevant stuff is entered and at the endpoint the user returns to the Add a hotel activity after which the user has the option to choose the optional activities again or proceed to save the provided data.
The only somewhat relevant answer I found was this one
But as I understand it, a fork means all actions after it have to be carried out before the flow will continue after the join.
And in case of a decision, only one option can be chosen.
The actions 1 and 2 above, are also available from other locations in the application. I just need to make them available on the Add hotel activity.
So how would I go about modelling optional actions that are available all the time during the flow of an activity? And why should it be done that way (if not obvious after reading)
Also, does it matter if these optional actions are Atomic actions or CallBehavior actions?
Like is said, I'm fairly new to UML, so it might well be possible that I interpret some things wrongly.
You're correct in the assumption that a fork will continue in all paths. To make an optional process simply use a Decision node (looks like a lozenge). From there you can proceed to your two optional actions or skip. Finally join the path again with the very same lozenge to merge the optional paths.
Basically it might look like this (not taking all the details of your activity into account):
Just ignore all those fuzzy details about different actions. Atomic is enough for a start.
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.
I have the below UML activity diagram for a shopping cart use case. It has several decision and fork nodes but there are no corresponding join/merge nodes. Could you please show me:
how to correct the diagram by introducing the merge/join nodes.
how to modify the diagram so that a customer can repeat the process (of adding more products to the shopping cart).
Thank you.
You should look into the token concept. It is introduced in petri nets and also used in the UML activity diagram.
Decision nodes produce one token only, i.e. they follow just one outgoing path. To merge such paths, of which only was is followed, you can use a merge node. Which just looks like a reversed decision node and is able to consume exactly one token. A diamond with multiple incoming edges.
If you use a parallelization node to start concurrent execution paths, you have multiple tokens leaving the parallelization node. To merge these kind of paths, you can use a synchronization node, it looks like a reversed parallelization node and has to consume one token per incoming edge.
(source: amg at www.lcc.uma.es)
Do you have an initial activity element anywhere? Makes it a bit easier to read. To your question, the merge should be used as opposed to having multiple connectors coming into the same activity. For instance, "Acknowledge Msg" should have a merge above it that the other branches can flow into.
As for how to make it repeatable, you may want an "Add to Cart" action, and prior to a "Checkout" action, have a Decision with guards for "Shopping Complete" (which goes to the Checkout action) and "Continue Shopping" (which goes back to "Enter Product #").
I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD and Activity diagram?
Actually, it's reasonably logical. You only have to look at the names.
In data flow diagrams, the lines between "boxes" represent data that flows between components of a system. Because these only show the flow of data, they do not give an indication of sequencing.
In activity diagrams, those lines are simply transitions between activities and do not represent data flow at all. They more represent the sequencing of activities and decisions. You can tell from these what order things happen in.
That's a simplistic explanation but should be a good starting point. Further information can be garnered from Wikipedia for DFDs and activity diagrams.
Explicit bias: I'm a DFDs proponent.
#John is correct that Activity diagrams can be used to represent object flow. #pax equally correct they seldom are.
Two big DFD advantages for me:
Link to object model. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Very useful for consistency and ensuring your thinking is joined up.
They de-emphasise control flow. Far too often designs over-constrain sequencing. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. So the default is over-serialisation. DFDs don't. They lay bare the real sequence dependencies without any extra effort on the part of the user. Consequently they also make it easier to see causal relationships. If processes a and b both require data input D then it's obvious on the diagram. And hence parallel activity is obvious.
Don't get me wrong - I'm not against Activity diags. Where control flow is the primary consideration I'll use an AD over a DFD. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases.
Of course, YMMV.
Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. That being said, the better approach is to always practice the story line and answer in simple answers.
One final comment regarding the age of tools and products. Remember that in most cases these are running the business and work pretty darn good. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown.
We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. One must weigh the consequences and understand if the replacement can handle workload. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes?
My apologies for taking it in that direction. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability.
Data Flow represents flow within one module or one independent code. However Sequence Diagram represents sequence of activity in between different modules.
Yes at some points they may pass the same messages.
I basically use Sequence diagram in interface documents which will be shared with other modules/elements, however DFD will be used in Low level design documents which will be used to develop the code within one module or network element.
If we look closer to a dataflow diagram, we can notice that when a node collects data from all its edges, it starts to process them. And to process, it needs an activity token, which represents access to a processor. Usually the process of obtaining that token is omitted, but it has to exist. Typically, the whole node as a token is put in a double-ended queue, where on the other end of that queue free activities (processors or threads) are stored. A thread pool is a perfect example of such a queue, and the nodes ready to work are represented as tasks. As soon as a node meets activity, they both are taken from the queue and actual processing starts. When processing finishes, activity is returned to the queue. This way we can think of activity as a special kind of token.
So both dataflow and activity diagrams are just simplified variants of a general active-data-flow diagram, with either activities or data tokens omitted. But generally, both kinds of tokens can be represented in a diagram simultaneously.
Programmers used to think about threads as activities, but if we look at them closer, we notice that when a thread is ready to execute, it gets in a line to processors, and real execution starts only when a free processor switch to that thread. This is absolute analogy as tasks are executed on a thread pool. So from simplified point of view, a thread is an activity, and from more rigorous point of view a thread is a data token and the only real activity is a physical processor. This shows that activity tokens are not different from data tokens. And indeed, we can omit the route of node chasing an activity and consider a dataflow node as an activity itself, which starts to work immediately when all its edges (inputs) contain data.