Normalmente , useresti UML per lo scopo che descrivi. UML fondamentalmente si scompone in due tipi di diagrammi: strutturali e comportamentali.

strutturali includono: composizione, distribuzione, pacchetto, classe, oggetto e componente. I diagrammi comportamentali includono: sequenza, macchina a stati, comunicazione, caso d'uso, attività e panoramica delle interazioni.

A seconda di ciò che stai cercando di trasmettere, scegli alcuni di questi diagrammi che rappresentano al meglio qualsiasi cosa tu stia cercando di trasmettere, e così facendo permetti alla conversazione di "salire di livello". Invece di parlare di metodi, parametri e codice, stai parlando di sequenze di interazioni o dipendenze di classi statiche o di qualsiasi schema tu scelga di creare.

Ho allegato un esempio di un diagramma di sequenza (uno dei diagrammi di comportamento). A me personalmente piace il diagramma di sequenza perché è proprio nel mezzo del processo di artefatti del design - approssimativamente un numero uguale di diagrammi dipende da esso in quanto si aspetta come input. Trovo che i diagrammi di input siano in genere "compresi" in ogni caso, o il diagramma di sequenza già implica la loro esistenza. Tuttavia, a volte eseguo sia diagrammi di classi statiche che diagrammi di sequenza (uno strutturale e uno diagramma comportamentale).

link

Non ho mai visto questo diagramma prima della mia vita, ma posso dire una serie di cose su questo sistema. Ci sono quattro componenti principali (i nomi nel tuo sistema - tipicamente le classi): View, Controller, Data Proxy e Data Provider. Le frecce sono "comportamenti" o invocazioni di metodi. Un diagramma di sequenza è fondamentalmente buono per mostrare una singola interazione importante tra un gruppo di componenti. Hai un diagramma di sequenza per ogni flusso importante attraverso il tuo sistema. Da questo particolare diagramma posso dire che "Controller" espone un metodo chiamato "phoneIsComplete ()", che a sua volta dipende dal metodo "lookupPhone ()" di DataProviderProxy, che a sua volta dipende dal metodo "lookupPhone ()" di DataProvider.

Ora potresti gemere e pensare "uggg ... questo non mi dà una grande immagine del sistema - sono solo le interazioni individuali attraverso il sistema". A seconda della sofisticazione del sistema, ciò potrebbe essere una preoccupazione valida (i sistemi semplici possono sicuramente cavarsela con solo una raccolta di diagrammi di sequenza). Quindi, passiamo ai diagrammi strutturali e guardiamo qualcosa come un diagramma di classi statiche:

link

I diagrammi delle classi ci aiutano a capire due cose importanti: cardinalità e tipi di relazioni di classe. Le classi possono essere correlate l'una con l'altra in diversi modi: associazione, aggregazione e composizione. Tecnicamente parlando, c'è una differenza tra "relazioni di classe statiche" e "relazioni di istanza". Tuttavia, in pratica vedi queste linee sfocate. La differenza principale è che le relazioni di classe statiche di solito non includono la cardinalità. Diamo un'occhiata all'esempio sopra e vediamo cosa possiamo vedere. In primo luogo, possiamo vedere che "Ordine speciale" e "Ordine normale" sono sottotipi di "Ordini" (eredità). Possiamo anche vedere che un Cliente ha N ordini (che possono essere "Ordini normali", "Ordini" o "Ordini speciali") - l'oggetto Cliente non lo sa veramente. Possiamo anche vedere un numero di metodi (nella metà inferiore di ogni casella di classe) e proprietà (metà superiore di ogni riquadro di classe).

Potrei continuare a parlare di diagrammi UML per molto tempo, ma questo è il punto di partenza. Speriamo che questo aiuti.

TLDR; Scegli un diagramma UML comportamentale e uno strutturale, impara come crearlo e otterrai ciò che stai cercando di ottenere.

Se hai difficoltà a descrivere cose come la struttura di alto livello del tuo programma funziona e come le classi funzionano bene insieme, considera la seguente massima:

A picture is worth a thousand words.

Il modo in cui dipingi un'immagine sul codice è fornire esempi di codice. Molti di questi. Ecco come si crea un nuovo cliente (codice). Questo è il modo in cui elabori un ordine (codice). Non solo questo dà al consumatore del tuo codice un punto di partenza, illustra come tutti gli oggetti si connettono e interagiscono. Se stavo usando il tuo codice, il più grande favore che potresti fare è fornire molti esempi di codice.

Il modo in cui dipingi un'immagine per un utente finale è fornire screenshot. Molti di questi. Schermata dopo lo screenshot che illustra, se si desidera eseguire questa attività, questo è ciò che si fa prima, questo è ciò che si fa dopo, ecc.

UML, sebbene spesso usato per modellare il software prima che venga creato, potrebbe essere utile. Esistono diversi diagrammi che illustrano casi d'uso, interazioni di classe, ecc. Ecc. Puoi vedere di più a riguardo qui .

Trovo link uno strumento estremamente utile per descrivere l'interazione tra componenti all'interno di un'applicazione o tra servizi in un'applicazione distribuita. Semplifica molto il processo di creazione e manutenzione dei diagrammi di sequenza UML.

La cosa bella è che se consideri che ciascuna linea di vita sia l'interfaccia o la classe della tua applicazione (di solito modellino solo i grandi giocatori), ogni riga che scorre in quella classe rappresenta un metodo che devi supportare.

Inoltre, ci sono alcune opzioni di download per ottenere l'immagine. Ci sono anche alcuni semplici modi per incorporare il diagramma in un wiki. Quindi è un ottimo strumento di comunicazione per descrivere l'interazione tra componenti o servizi in un sistema, oltre a comunicare con il team.