Va bene semplificare un diagramma di sequenza (raggruppamento di linee vita)?

Pensa a perché stai facendo il diagramma di sequenza. Chi è il tuo pubblico e cosa ne ricaverà.

UML non è sempre richiesto. Se stai uscendo da un certo senso dell'obbligo di "progettare" fai un passo indietro e pensa per un minuto. Se è semplicemente tradizione nel tuo negozio dare un'occhiata a ciò che le persone hanno fatto e chiedere quanto sia utile e perché.

Ho visto persone creare diagrammi di progettazione che dovevano essere delle dimensioni di un tavolo per conferenze da stampare abbastanza grande da leggere il testo. Questi documenti erano buoni per una risata ma non molto altro.

Sono un grande sostenitore in un foglio di carta. Credo anche nell'astrazione. Mentre sono tentato di dire che va bene raggruppare un gruppo di oggetti su una linea di vita se sono chiaramente etichettati ma devo chiedere, sei assolutamente sicuro che questo non sia un segno di un problema con il design?

Se è difficile disegnare diagrammi su carta è probabile che sia difficile navigare nel codice. Prendi in considerazione l'uso di astrazioni, schemi di facciata e non fare domande. Nessuna di queste garanzie consente di suddividerla in singoli singoli fogli di carta coerenti, ma è certamente di aiuto.

Se insisti a rimanere con il tuo attuale design, dovrai trovare un modo ragionevole per descriverlo così com'è. Nel tuo caso hai tre componenti di interesse su 26. Raccomando l'uso di un cloud. Non è la parola d'ordine. L'icona La rete ha utilizzato da tempo un'icona a forma di nuvola per dire "qui passiamo sopra un mucchio di cose di cui non abbiamo bisogno di parlare ora". Indica chiaramente il cloud in modo che sia chiaro dove inizia e finisce e non devi rappresentare i suoi componenti interni. Puoi dare al cloud un'ancora di salvezza e si adatta subito.

Non è un UML formale, ma se comunica ciò di cui hai bisogno, a chi importa?

Non dovresti semplificare i diagrammi fino al punto in cui non riflettono più la realtà. Penso che sia una buona cosa mettere a fuoco diagrammi su aspetti particolari del sistema per migliorare la chiarezza, ma non si vogliono avere modelli che diano alle persone un'impressione sbagliata del proprio sistema. Lo scenario migliore è che ci sia confusione quando qualcuno inizia con la visualizzazione e poi guarda l'implementazione.

Penso che il tuo primo passo dovrebbe essere quello di restringere l'ambito dei tuoi modelli visivi. Ad esempio, se vuoi mostrare la topologia generale del sistema distribuito, considera un diagramma di implementazione , mostrando i nodi e i pezzi che rientrano in ciascun nodo e in che modo sono collegati. Se hai un flusso di lavoro, puoi mostrare il flusso di lavoro generale in un diagramma delle attività . Quando vuoi aprire un nodo o uno dei componenti che risiedono sul nodo, puoi guardare diagrammi di classe più dettagliati per la struttura statica e diagramma di sequenza o diagramma temporale per mostrare come i metodi vengono chiamati all'interno di un nodo particolare. Potresti utilizzare un diagramma di comunicazione o una forma modificata di un diagramma di sequenza (se non sei preoccupato di attenersi a un formale UML), per mostrare i messaggi di livello superiore che fluiscono tra i nodi per una determinata operazione.

Se il sottosistema non è sotto il tuo controllo immediato, non fornire un diagramma altamente dettagliato che mostri come funzionerà. Invece, definisci gli input e gli output usando UML e altri metodi grafici o testuali, ma mantienilo alto. Lascia che gli implementatori creino modelli più dettagliati.

In generale, guarda la discussione di Martin Fowler sulle modalità UML - tienilo al livello appropriato di dettaglio per i tuoi scopi . Inoltre, guarda i principi di Agile Modeling - massimizza il ROI dei tuoi modelli, usa più modelli in cui ogni modello cattura un aspetto specifico del tuo software, si concentra sulla produzione di software di lavoro su modelli dettagliati, e si concentra sulla comunicazione di contenuti (soprattutto in modo chiaro ed efficiente) piuttosto che sulla rappresentazione di quel contenuto.

In questo approccio, probabilmente avrai più modelli visivi, ma ogni modello visivo sarà più piccolo, il che li renderà più facili da leggere e mantenere (o decidere di scartare senza perdere altri pezzi dell'immagine).