Diagrammi UML di applicazioni multi-thread

Per le applicazioni a thread singolo mi piace usare i diagrammi di classe per avere una panoramica dell'architettura di quell'applicazione. Questo tipo di diagramma, tuttavia, non è stato molto utile quando si è cercato di comprendere applicazioni multithread / simultanee pesantemente, ad esempio perché diverse istanze di una classe "vivono" su thread diversi (il che significa che l'accesso a un'istanza è salvato solo da quello thread su cui vive). Di conseguenza, le associazioni tra le classi non significano necessariamente che posso chiamare metodi su quegli oggetti, ma invece devo effettuare quella chiamata sul thread dell'oggetto di destinazione.

La maggior parte della letteratura che ho approfondito su argomenti come la progettazione di applicazioni simultanee, distribuite e in tempo reale con UML di Hassan Gomaa aveva alcune idee interessanti, come disegnare i confini del filo in diagrammi di oggetti, ma nel complesso sembrava un po 'troppo accademico e prolisso per essere davvero utile.

Non voglio usare questi diagrammi come una visione di alto livello del dominio problematico, ma piuttosto come una descrizione dettagliata delle mie classi / oggetti, delle loro interazioni e delle limitazioni dovute ai limiti del thread che ho menzionato sopra.

Vorrei quindi sapere:

1. Quali tipi di diagrammi hai trovato più utili per comprendere le applicazioni multi-thread?
2. Esistono estensioni al classico UML che tengono conto delle peculiarità delle applicazioni multi-thread, ad esempio tramite annotazioni che illustrano che
   • alcuni oggetti potrebbero vivere in un certo thread mentre altri non hanno affinità di thread;
   • alcuni campi di un oggetto possono essere letti da qualsiasi thread, ma scritti solo da uno;
   • alcuni metodi sono sincroni e restituiscono un risultato mentre altri sono asincroni che accodano le richieste e restituiscono i risultati, ad esempio tramite un callback su un thread diverso.

Le informazioni più importanti su come avvengono le esecuzioni dei thread possono essere rappresentate da quello che è noto come diagramma di sequenza . Ecco un esempio da Wikipedia

Questo diagramma disegna essenzialmente l'elenco degli eventi insieme a una direzione su una singola linea verticale spesso chiamata linea di vita . In questo caso, ogni thread è proprietario della propria linea di vita. Il diagramma consente di rappresentare tutti i tipi di eventi come sincrono, asincrono, ecc.

L'altra cosa più importante in tali sistemi sono i diagrammi di stato o i diagrammi di stato. Di solito, questo vale solo se il modello è rappresentato come una macchina a stati. Tuttavia, nella maggior parte dei sistemi multi-thread (dove i thread non sono banali) è meglio che siano progettati per funzionare con algoritmi isolati per stati diversi.

Esistono altri tipi di diagramma come il diagramma di interazione e il diagramma di comunicazione, ma penso che provare a disegnare il diagramma di sequenza e i diagrammi di stato metterà la massima chiarezza.

La mia risposta è complementare a quella di Dipan in quanto riguarda i diagrammi di sequenza UML. Ho scoperto che anche uno stile che non è UML puro al 100% va bene. Dai un'occhiata ai diagrammi utilizzati nei modelli di concorrenza . Alcuni sono quasi UML (ma questo non è assolutamente standard):

Se hai familiarità con wait / notification nella sincronizzazione del thread Java, apprezzerai il seguente diagramma di sequenza dal documento che ho citato:

Per le applicazioni multi-thread che utilizzano la stessa classe, il trucco potrebbe essere quello di trascinare la stessa classe in ciascun modello che rappresenta un thread. Potresti avere la stessa classe con viste diverse e navigare nel modello e nel codice facendo clic sulla classe, sul diagramma o sul codice. So che l'unione del modello non è un concetto ben noto ma funziona davvero bene con Eclipse con Omondo.

Voglio dire che quando modello una grande applicazione che è composta da più di un progetto. Creo un modello per ciascun progetto e poi li unisco all'interno di un progetto più ampio. Tutta la modellazione viene eseguita utilizzando i diagrammi di classe, che è il modello che ho ottenuto quando ho invertito l'intero progetto dal codice Java a UML. Voglio dire che nel mio esempio uso il codice esistente e lo capovolgo in un singolo modello UML, quindi unisco tutto questo codice inverso che ha creato i modelli UML in un singolo modello di grandi dimensioni. È inoltre possibile creare più modelli anziché invertire il codice esistente. Funziona in entrambi i modi: alla creazione senza codice o in fase di reverse engineering con codice esistente.

Non so se abbia senso, ma potresti forse creare un modello di grandi dimensioni, raggruppando sotto-modelli per ogni thread come quello che faccio con la modellazione multi-progetti? Spero che questo aiuto.