Sloppiness nei diagrammi di attività

Naviga le tue risposte
7

Come follow-up di questa domanda Ho iniziato a scavare nelle specifiche UML relative al flusso di controllo nei diagrammi delle attività. Considera questo semplice esempio:

Si noti che non ha né ActivityInitial né ActivityFinal . So (anche se in realtà non riesco a trovare la posizione) che le specifiche indicano che un flusso è terminato quando non ha un fronte in uscita. Quindi, se viene passato [terminate] , il flusso si fermerà dopo Final come se avesse raggiunto un FlowFinal . Ma - e qui ci sono le mie domande:

  • Analogamente a un margine in uscita mancante, un bordo in entrata mancante significa che il flusso deve iniziare qui? Quindi nel mio esempio, il flusso inizierà a Implicit ?
  • Poiché loop? ha un solo margine in uscita protetto, cosa succederà al token se non passa (credo che sarà bloccato).
  • È necessario un nodo unione per unire i bordi di Decision e l'azione Implicit in Action ? (Suppongo che tu non ne abbia bisogno dal momento che un Action accetterà tutti i token offerti e non aspetterà come un Join farebbe per tutti arrivare.)

Utilizza la citazione dalle recenti specifiche UML nella tua risposta.

    
posta Thomas Kilian 20.09.2016 - 12:59
fonte

1 risposta

6

  1. Sì, il flusso inizierà a Implicit . Dalla specifica UML 2.5:

    [15.2.3.2 Activity Nodes]

    An ActivityNode is enabled to begin execution when specified conditions are satisfied on the tokens offered to it on incoming ActivityEdges...

    [15.2.3.6 Activity Execution]

    ... nodes that do not have incoming edges and require no input data to execute are immediately enabled.

  2. Il DecisionName verrà bloccato dall'offerta di token sul suo bordo in uscita.

    • Per quanto ho capito, le specifiche non menzionano cosa succederà al token in dettaglio. Credo che dire " il bordo in uscita verrà bloccato e quindi il token rimarrà bloccato " non è troppo sbagliato. Dalla specifica UML 2.5:

      [15.3.3.6 Decision Nodes]

      A token offered on the primary incoming edge of a DecisionNode shall not traverse any outgoing edge for which the guard evaluates to false.

    • Per InitialNodes, la specifica afferma quanto segue:

      [15.3.3.1 Initial Node]

      If the token offered by an InitialNode is not immediately accepted, or is otherwise blocked from moving downstream (for example by an ActivityEdge guard), then it remains on the InitialNode.

  3. Qui è richiesto un MergeNode, perché i due bordi in entrata sono uniti in modo implicito , il che significa che entrambi i bordi devono offrire un token affinché l'attività inizi l'esecuzione. Dalla specifica UML 2.5:

    [15.5.3.1 Executable Nodes]

    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.

risposta data 20.09.2016 - 15:22
fonte

Leggi altre domande sui tag

In un'architettura aziendale, dove viene utilizzato il Localizzatore di servizi più appropriato e perché? Un'ampia API per diversi microservizi rispetto a molte piccole API ciascuna con la propria API