Is it valid to have the following combined join and fork nodes in a UML activity diagram or is it wrong?
I searched online and in some UML books but I cannot find a clear answer or a similar example.
The idea is to have two actions (1 and 2) that need to be completed and then synchronised before the start of actions 3 and 4.
Should I just introduce a sync action between a join and a fork node to be on the safe side?
Yes, that is valid.
In the UML specifications version 2.5.1 you'll find on page 391
The functionality of a JoinNode and a ForkNode can be combined by
using the same node symbol, as illustrated in Figure 15.31. This
notation maps to a model containing a JoinNode with all the incoming
ActivityEdges shown in the diagram and one outgoing ActivityEdge to a
ForkNode that has all the outgoing ActivityEdges shown in the diagram.
I wonder if this how you want it done?
Fork end merge
Related
I'm modelling an activity diagram for a project. Directly after initial node is it okay to use a decision node. I just google for it. But I fail to find similar examples even.
Eg:- imagine a person can Search for a dog name or Select the category animal, then dog likewise at the very beginning.......
One of my team mates mention that according to above example those are two different activities and we should create two activity diagrams for it.
This is allowed under condition.
The rules concerning the input flow(s) of a decision node are (formal 2017 § 15.3.3.6 Decision Nodes page 390) :
A DecisionNode shall have at least one and at
most two incoming ActivityEdges, and at least one outgoing ActivityEdge. ... If the DecisionNode has only one
incoming edge, then it is the primary incoming edge. If the primary incoming edge of a DecisionNode is a ControlFlow,
then all outgoing edges shall be ControlFlows and, if the primary incoming edge is an ObjectFlow, then all outgoing edges
shall be ObjectFlows.
Also knowing (§ 15.3.3.1 Initial Node page 387) :
The outgoing ActivityEdges of an InitialNode must all be ControlFlows.
that means in your case, and supposing there is no other input edge to the DecisionNode, all outgoing edges of the DecisionNode shall be ControlFlows, else this is not allowed
Your team mate isn't wrong. This is a design question which should have been clarified beforehand. Activities are functional parts inside of use cases. They represent scenarios like "sunny day", various error scenarios, etc. And again one step back the use cases represent the added value the system under consideration represents for its primary actor.
Now from your examples it's hard to tell what that system should be. Search for dog name could be a use case, but in which context? Is it to name a new dog or to search for an existing dog in a database? Same for Select animal category(and then dog?). Both do not make much sense as use cases. Once you come up with meaningful use cases you can tell exactly which steps the activities should have as actions. Only then you can have the need to decide. The decision which use case to actually use it outside the system and you wont see the steps done for it.
As a recommendation: Bittner/Spence have an excellent book about use cases which (unlike the UML specification) makes a lot of sense. There are also other well known authors teaching the same school (along Ivar Jacobson).
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'm designing some Sequence Diagrams for my project and decided to divide login and register use cases, creating two different diagrams (thought was a wise choice to separate concerns and simplify).
Now, when Register process is finished, I would like to tell the diagram to follow some path inside Login Diagram. Is that what Lost message is for? Like calling an event outside the diagram? Please clarify.
This is a Gate. UML 2.5 Specs:
17.4.4.3 Gate
Gates are just points on the frame, the ends of the messages. They may have an explicit name (see Figure 17.4).
17.12.9 Gate [Class]
17.12.9.1 Description
A Gate is a MessageEnd which serves as a connection point for relating a Message which has a MessageEnd (sendEvent / receiveEvent) outside an InteractionFragment with another Message which has a MessageEnd (receiveEvent / sendEvent) inside that InteractionFragment.
I'm learning Activity diagram in UML and now I'm confused with the following diagram for representing procedures when calling a pizza.
I think a merge node should be added before the join node because if not, the join node will wait forever. Is that correct?
Thank you.
I think you are right.
There should be a merge node merging the two flows coming from the decision right after Ask for toppings and a merge node to merge the two flows that have been split by the decision right after Deliver Pizza
A join node will only continue if it gets a token from all incoming flows, which will never happen if those flows are mutually exclusive because of a decision earlier on.
I am trying to draw an activity diagram in UML 2. I have an action called "splitter" which takes an object and split it into two groups of objects called A and B. These new objects undergo two different flows in the activity diagrams in parallel. I am wondering if UML2 supports taking multiple output from an action. How can I emphasize on the parallelism without using a fork symbol?
Your action can have two outgoing data flows - either using pins or connecting the two outgoing links to different object nodes. After this from either the pins or the nodes you can start two different flows. There is no need to use fork.
The activity diagram provides two kinds of flows: control flow and object flow. The "fork" is used for control flow only.
According you question it looks like you are talking about object flow. There is no any kind of "parallelism" in UML notation for object flow.