-1

I want to know what is wrong with my diagrams? please help me through the following diagram:

enter image description here

UML ACTIVITY DIAGRAM

Christophe
  • 68,716
  • 7
  • 72
  • 138
Maria Fard
  • 11
  • 1

1 Answers1

2

There are a couple of issues here:

  • the initial node should have an outgoing edge going to Login. If this is missing, one could understand that nothing would ever happen. While this could be debated (see comments) it’s best to avoid ambiguity.
  • Confirm placement seekers form has two outgoing edges. This is not illegal, but only one target may accept it at a time and the UML semantics do not define which one. If you want both target actions to happen, you should add a fork node (and later a join node to synchronize the parallel flows). If you want only one, then avoid the ambiguity by using a decision node in-between.
  • Receive confirmation notification has no outgoing edge. This is not illegal and is similar to and is similar to a flow final situation. Nevertheless this might raise the question if something was forgotten; the systematic use of a flow-final or activity end node is less ambiguous for the reader. Therefore, if this was a parallel flow, you'd need this one to have an edge either to a flow final node (to consume the token and end this parallel branch) or to the join node mentioned above, before continuing and reaching the activity final node. If this an alternative flow, then you should add an edge to an activity final node.
Christophe
  • 68,716
  • 7
  • 72
  • 138
  • I agree that the initial node should have an outgoing edge. However, its omission doesn't mean that nothing ever happens. The defined semantics is, that all actions without incoming flows get enabled. In this diagram this has exactly the same effect as a control flow between the initial node and `Login` – Axel Scheithauer Mar 10 '21 at 11:01
  • Sorry, but your statement about the semantics of two outgoing controlflows is outdated. In UML 2 it means, that both get a token. It is thus an implicit fork. You might want to add it explicitely to avoid misinterpretation, but it is in fact valid and consistent. – Axel Scheithauer Mar 10 '21 at 11:01
  • A missing outgoing edge on `receive confirmation notification` just means that no token is produced when the action finishes execution. So, the effect is exactly the same as connecting it to a flow final node. I would suggest to add this, to make the diagram more readable, but it is not strictly necessary. I agree, that you probably want to connect it to a join node before the activity final node, because it should only end after both actions are finished. – Axel Scheithauer Mar 10 '21 at 11:07
  • @AxelScheithauer Thank you for these constructive remarks. However, I think that the semantics are not as clear-cut as you suggest: UML 2.5.1 is far from obsolete. On page 373 "*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***", and "*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***". Did I misunderstand? – Christophe Mar 10 '21 at 18:14
  • @AxelScheithauer But I accept your argument regarding the absence of token produced regarding the flow-final. I have deep inside my brain still some petri-net reminiscences that tell me to be very strict with tokens ;-) Regarding your first remark, could you help me find the related paragraph? I'm stuck at "*An ActivityNode is enabled to begin execution when specified conditions are satisfied **on the tokens offered to it on incoming ActivityEdges***" and the para of the initial node, and would like to find back the semantic that you explained regarding nodes without incomming edge. – Christophe Mar 10 '21 at 18:27
  • Page 373 is the default behavior for abstract ActivityNodes, which is overwritten by ExecutableNodes. There it says (page 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 agree, that this can be misleading, but at least the specification references this chapter immediately before the sentence you cite. – Axel Scheithauer Mar 10 '21 at 18:30
  • On page 471 it says: _" If the AcceptEventAction has no incoming edges, by the usual rules, it is enabled when its immediately containing Activity (or StructuredActivityNode) begins execution."_ Its funny that I can't find this _"usual rule"_ anywhere. I'm pretty sure though that it is in effect. And in at least one simulation engines it does work this way. – Axel Scheithauer Mar 10 '21 at 18:46
  • I found it on page 376: _" nodes that do not have incoming edges and require no input data to execute are immediately enabled."_ – Axel Scheithauer Mar 10 '21 at 18:48
  • @AxelScheithauer Thank you Axel for having taken the time to find these references and for this constructive exchange. I have edited accordingly to smoothen the wording, but nevertheless encourage the use of the expected form. – Christophe Mar 10 '21 at 19:38