Diagrammi di sequenza e implementazione

Direi di andare più in alto che puoi mentre includi ancora tutte le chiamate di metodo necessarie, ecc. per il tuo argomento. Il mio ragionamento per questo è che se includi ogni singola interazione, potresti anche scrivere il codice da solo.

Personalmente, ho sempre visto i diagrammi di sequenza più o meno come "guida" per l'implementatore. Non li ho mai visti come documenti viventi - se l'implementazione differisce dal design, non aggiornerò il diagramma (a meno che non sia diverso perché il mio disegno era sbagliato). Tuttavia, hai ragione nel presumere che dipenda in gran parte dal pubblico.

Se hai una squadra piena di sviluppatori esperti con conoscenza del tuo prodotto, dovresti essere in grado di lasciare alcune cose qua e là e fidarti di loro per riempire gli spazi con il loro miglior giudizio. Nel mio caso, di solito limito i miei diagrammi di sequenza a un particolare argomento, ad esempio "Elabora XYZ", e mostro solo chiamate di metodo e interazioni di oggetti che sono rilevanti per quell'argomento, tralasciando cose che sono ovvie o definite in un altro diagramma . Se sto scrivendo un diagramma per uno sviluppatore junior che sta imparando il progetto e il dominio, allora tendo ad essere più specifico.

L'unica ragione per cui includo ogni singola chiamata e interazione di metodo è se in realtà stai generando il codice dal modello. Ad esempio, ho lavorato su alcuni sistemi embedded in cui generiamo il nostro codice da un modello Rhapsody, quindi ovviamente in questo caso dovresti includere il più possibile.

• A un livello molto alto, i diagrammi di sequenza possono rappresentare interazioni di alto livello tra sistemi o sottosistemi ad un livello elevato.

• Se rappresentano interazioni tra classi effettive (o interfacce), sono carine perché ogni messaggio nel diagramma corrisponde direttamente a un metodo che deve avere la classe. Puoi quasi scrivere il tuo codice dai diagrammi di sequenza catturando i messaggi come metodi.

• Se rappresentano le interazioni tra i servizi, ogni messaggio rappresenta una richiesta o una risorsa che le API riceventi devono supportare.

Per quanto riguarda il livello di dettaglio, ho creato diagrammi di sequenza che rappresentano interazioni di alto livello, con molti dettagli di implementazione lasciati fuori, ai fini della documentazione di progettazione. Ma ho anche creato diagrammi di sequenza davvero dettagliati che spiegano metodi e parametri specifici tra le classi.

Dipende in gran parte da quali sono i tuoi bisogni. Ho trovato che i diagrammi di sequenza sono un ottimo modo per capire e comunicare soluzioni in cui i requisiti sono grandi e complicati, oltre a un modo di fare design di classe a un livello di dettaglio molto specifico.

Anche se non l'ho provato, si potrebbe essere in grado di creare un diagramma di sequenza di alto livello con messaggi di livello abbastanza alto come "Invia allarme al server" e quindi utilizzare l'allocazione UML per assegnarli a diagrammi di sequenza più dettagliati ottenuti come granulare è necessario in termini di mostrare sequenze di accesso, riconoscimenti e così via. Questo approccio potrebbe essere un modo ragionevole per collegare la versione "facile da comprendere per gli stakeholder" a (un numero di) "sufficientemente dettagliato per generare versioni di codice".

Sarei curioso di sapere se qualcuno ha effettivamente provato qualcosa del genere.