My question is about the merge node in the UML activity diagram, when and why to use it?
Merge node example:
A merge node accepts a single token to continue processing. Other nodes need tokens at all incoming edges to start processing. So if a flow is split by a decision you have a single token passing at one side of it. In order to reach the Join at the lower end, you need to collect either flow left and right to collect the single token and pass it on.
N.B.: Activity diagrams have their root in Petri nets. You could consult Wikipedia to see how they work in detail. There also a couple of answers here on SO.
I was reading about statechart diagrams, which are diagrams that model the different states that one or more instances of one or more classes can be.
An object can go from one state to the other through a transition, which is represented using arrow with an event and eventually a action to that event over and respectively below it.
My problem now is that I don't understand exactly what are OR and AND decompositions in a statechart diagram. Could you please give me an explanation (since I've not found around any)?
I would really appreciate a concrete example with the corresponding picture or diagram.
The following picture is an example for an OR. Consider a token traveling from Initial to the Choice (diamond). Here the token travels either to the left or right guided by the constraints which test the condition checked in Choice. From then where they are they next transit through the following unnamed diamond to Continued. You might leave away the joining diamond and draw the transitions directly to Continued.
The AND condition looks like this:
The first Fork(the bar) duplicates the token and sends them to Either and Or. The Join behind these states waits for two tokens to arrive before it sends only one token further to Continued.
Fork and Join use the same symbol. They wait until all incoming tokens arrive and then send as many tokens as there are outgoing transitions. So they are actually some split personality. But mostly they are used the one or the other way.
I am currently Designing UML Diagrams for a distributed backed made up of 8 nodes, which handle specific operations depending on the message received from the web Client.
The problem I have is that, the initial node which acts as the "Gate of Entry" to all messages and interactions generated from the Client-end, does not contain concrete operations that could be denoted as "Standard Use cases" but only a multitude of message flows pertaining to client-end use cases operations that flow throw this point.
But I also desperately require a method to show a process mapping between the client-end Use Case and initial node Use Case processes for consistency sake. If these messages are not mapped, the following the flow of operations from the Client-end to Server-end will be somewhat complicated.
Unfortunately due to the complexity of the system I have a problem of designing the whole System in a single diagram too.
Some Possible Improvisations considered
• To create "Place holder" like Use Case Ext. notation to indicate an extension.
E.g. The client-end has a place new order Use Case from which a message flows through initial node to the back-end nodes. In order to create connectivity indicate a Use Case which would read Place new order Ext. and this would signify a connectivity but would only point to a message flow.(But I am not sure if this practice is largely excepted in UML.)
• Only rely on Sequence and communication diagrams aim to show how "things" interact, each lifeline designating one of the system components. But I feel is that the correlation between Client-end and Back-end Use Case will not be very clear.
I also checked for similar problems on this forum and there were a few but did not explicitly answer my question.so I thought of posting this question.
Can someone please suggest what would be the best option in showing information flow in this highly event-driven distributed information system such as this - One of the above mentioned or any other options that I may have overlooked?
Have you considered using component diagrams, where the components have ports and the ports accept (and produce) signals instead of operations? A signal is basically a message / event.
You can also model signals as classes at the high level, or in as much detail as you need. You could model some of the properties of an application-level signal such that you can show how a component demultiplexes based on some property before forwarding the message along to an output port.
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.