IMHO, in realtà non è necessario includere alcun condizionale o "loop" per lo stato di "attesa":

Qualsiasiattivitàrichiedeuncertoperiododitempoprimachesiacompletata.Seunrappresentantedelclienteèimmediatamentedisponibile,iltempoperl'attivitàdiattesaèzero,altrimentil'attivitàrichiederàsoloalcuniminutioforseore.Mailpoteredi"zero" è che può essere spesso gestito come qualsiasi altro numero, senza la necessità di distinzioni artificiali.

Ovviamente, se vuoi modellare esplicitamente l'attività "Wait", perché nel tuo sistema qualcosa di essenzialmente diverso accadrà durante una "vera attesa", vai con la tua soluzione 2.

I tuoi diagrammi sono corretti?

La guardia su un nodo decisionale deve essere posizionata sulla coda della linea e non sui nodi ( vedi UML 2.5 sezione 15.2.4 ). Quindi [free customer representative available] sulla parte superiore del diamante deve essere rimosso e il% in uscita[yes] e [no] cambiano in [customer representative available] e [customer representative not available] .

Dopo questo, entrambi i diagrammi sarebbero formalmente ok:

• La proposta 2 produrrebbe il risultato atteso se e solo se è garantito che un rappresentante del cliente è disponibile quando l'attività wait è completata. Questo non è ovvio, quindi un ramo migliore a sinistra, e metti il diamante di diamante in anticipo sulla decisione diamante, per essere sicuro di non continuare fino a quando un rappresentante è disponibile.

• La proposta 1 è completamente corretta. I nodi di controllo in un diagramma di attività sono nodi decisionali con diversi flussi in uscita o nodi di unione con diversi flussi in entrata ( vedi UML 2.5 sezione 15.3.2 ), ma fortunatamente entrambi possono essere combinati in un singolo diamante sul diagramma ( vedi UML 2.5 figura 15.34 nella sezione 15.3.4.3 ). È tuttavia un po 'meno leggibile rispetto ai nodi distinti.

• Lo sai già, ma avresti bisogno di un nodo finale dopo order .

Ma è davvero il modo migliore?

I tuoi diagrammi si basano sulla comprensione umana dell'attività wait (for representative) . Ma penso che siamo d'accordo che l'attesa non è in realtà un'attività ma piuttosto un'attività non.

Alternativa 1: utilizza un approccio basato sugli eventi con l'aiuto di accept-event-action chiamato Customer representative available che rappresenta ciò che stai aspettando. Unisci il flusso che ne esce con il tuo flusso normale. Attenzione: non usare l'allettante TimeEvent (simbolo del clessidra): è pensato per eventi che si verificano in momenti specifici ( vedi UML 2.5 sezione 13.4.10.1 )

Alternativa 2: rappresenta ciò che stai realmente facendo: stai trovando un rappresentante del cliente. Questo è il modo semplicissimo di mostrarlo.

Alternativa3(lamiapreferita):rappresentalaveracomplessitàdiunmondomultitasking,conl'usodi un fork e un controllo del join e tra tutto ciò che accade in parallelo:

Avere uno stato di "attesa", o attendere attività, non è implausibile, e a seconda del dominio, non è raro neanche. Contrassegnalo come tale e definisci per quanto tempo lo stato sarà attivo (cioè quanto tempo tornerà al punto di decisione).

Se il punto di decisione non deve essere esplicitamente esposto, puoi decidere e attendere lo stato in un'unica attività che si sposta sulla disponibilità di un operatore.

Nota a margine; se l'OP è una "dimostrazione" del flusso reale valutato nel progetto, ci sono altre opzioni per i modelli e la modellazione di questo comportamento che può essere utile investigare, ad esempio;

• FSM, uno stato con un evento che sposta la macchina nello stato "ordine"
• Se ci sono più flussi che richiedono la sincronizzazione, un join può essere un'idea migliore

A volte altre soluzioni potrebbero essere solo un altro modello o una riprogettazione di qualche tipo che rimuove lo stato di attesa. Detto questo, spesso la soluzione è solo lo stato di attesa perché questo è il comportamento del flusso di processo che viene modellato (indipendentemente dalla progettazione o dall'analisi).

Sulla seconda opzione aggiunta, il "wait until" richiede intrinsecamente un test per determinare se la condizione richiesta è soddisfatta, non sono sicuro che la seconda opzione modelli in modo appropriato.

Se usi le corsie preferenziali, penso che non sia necessario alcun meccanismo di attesa. È implicito che il rappresentante del cliente deve essere pronto a svolgere il compito.

Ecco un suggerimento fatto con PlantUml / PlantText :

ModificaEccounaltrosuggerimento( fonte ) con un più esplicito aspetta semantico che ti permetta di riagganciare.

Dovresti usare un ReceiveSignalAction per rappresentare la ricezione di un segnale che un consulente è pronto.

Spiacente, nessun strumento di modellazione disponibile al momento, aggiungerò il diagramma quando mi siedo al mio computer.