diagrammi di flusso (anni '50):

• descrizione di algoritmi sequenziali

reti di Petri (anni '60):

• descrizione di algoritmi concorrenti
• sofisticata teoria matematica
• true concurrency

estensioni delle reti di Petri (dagli anni '70 in poi):

• v. il sito http://www.informatik.uni-hamburg.de/TGI/PetriNets
• standardizzazione ISO (in corso) per le high level Petri Nets: http://www.petrinets.info/standard.php

diagrammi di attività UML (anni '90)

• azioni:
• flussi o archi:
  • concorrenti :
  • alternativi (branch/merge):

quando si usano:

• modellazione di workflow, processi concorrenti, etc.

partizioni (generalizzano le swimlanes di UML 1)

segnali

• temporali
• di input
• di output

passaggio di parametri (oggetti) lungo gli archi

• box
• pin: suscettibili di trasformazioni

regioni di espansione <<concurrent>>

• fine di flusso per istanze concorrenti

specifica di join (condizioni aggiuntive alla sincronizzazione)

interaction overview = interazioni + attività : come avviene la fusione?

• diagrammi di attività, ma con diagrammi di interazione come azioni
• frame di interazione, con operatore sd o ref (interaction use)

secondo lo standard UML 2, un'attività è la forma più semplice di interazione

• priva di riferimenti a oggetti, messaggi, lifeline ...

si può dunque usare un diagramma di interazione generale per

1. modellare un'interazione, ad es. uno scenario di caso d'uso, ad un alto livello di astrazione mediante frame ref,
2. e quindi raffinarne il livello di dettaglio specificando le attività di riferimento mediante diagrammi di sequenza o di attività

N.B. i flussi nei diagrammi di interazione generale sono soggetti a vincoli più restrittivi che nei diagrammi di attività

• in particolare, la nidificazione di coppie di nodi fork/join e branch/merge deve essere appropriata (parentesizzazione)