Perchè i nodi fork e join sono necessari in UML

1

Ho qualche background in reti di Petri , e nel mio ultimo addestramento UML, il formatore ha spiegato come i diagrammi di attività sono essenzialmente una forma di una rete di Petri con semantica di rete di Petri.

Ora leggiamo che i simboli fork e join sono usati per modellare la concorrenza nei diagrammi di attività UML, e sono un po 'incerto se sono effettivamente necessari o se servono a uno scopo più profondo.

Sembra che una forcella possa essere sostituita da un'azione non operante che trasmette da un collegamento in entrata a molti in uscita. Lo stesso vale per un nodo join, che potrebbe essere sostituito da un nodo no-op che sincronizza le frecce in entrata. Molte volte, l'azione non operatoria può essere eliminata collegando direttamente le frecce all'azione che porta alla forcella o seguendo il "join".

L'unica cosa che potrebbe indicare la necessità di un nodo di join sarebbe la "specifica di join", ma sembra un caso di utilizzo raro.

Ecco un esempio di una valutazione petri-net senza fork e join:

    
posta wirrbel 25.10.2018 - 15:15
fonte

2 risposte

3

Normalmente c'è solo un singolo stato attivo. Fork crea più stati attivi che possono quindi propagarsi indipendentemente.

C'è una cosa che ti manca per quanto riguarda il join: puoi passare il join solo quando tutti gli input sono in arrivo. Questo non può essere modellato semplicemente da più connessioni in entrata.

Puoi modellare perfettamente gli stati tra fork e join creando un prodotto cartesiano e poi modellando in modo esauriente tutte le transizioni tra di loro.

Forchetta e unione semplificano il diagramma mantenendo visibili gli stati logici di ciascuna parte.

    
risposta data 25.10.2018 - 15:24
fonte
1

La specifica UML link afferma

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.

In altre parole, l'UML specifica che i token non vengono copiati di default. La copia di token per impostazione predefinita è ciò che ho assunto dalle mie esposizioni precedenti alle reti di Petri.

    
risposta data 25.10.2018 - 20:42
fonte

Leggi altre domande sui tag