A nessun programmatore piace scrivere documentazione, e questo, al di la delle apparenze e dei luoghi comuni, è il miglior motivo per utilizzare l'UML!.
L'UML infatti non è una metodologia, ma solo uno standard per la documentazione visuale del software, cioè per realizzare schemi descrittivi, utilizzabile sia in funzione di progetto che documentativa. Ciò permette di sfuttare solo le caratteristiche a noi comode, senza essere per questo costretti a seguire complesse procedure.
La specifica prevede diversi tipi di diagrammi:
I diagrammi possono essere suddivisi sulla base di differenti categorie a seconda che descrivano la struttura, il comportamento oppure le interazioni (questa è la classificazione ufficiale, ma ne esistono altre):
In tutti i diagrammi i commenti vengono rappresentati in questo modo,
e possono essere associati ad un punto del diagramma tramite una linea tratteggiata.
Tutti gli elementi che rappresentano delle istanze possono essere descritti come "nomeclasse : nomeistanza".
E' generalmente il primo dei diagrammi realizzato in fase di studio di un nuovo progetto, e descrive le funzionalità disponibili ai vari attori, ed il legame tra le stesse.
Il sistema nel suo complesso è rappresentato come un rettangolo, all'interno del quale sono poste le varie funzionalità. Se il sistema è uno solo spesso questa indicazione viene omessa.
La relazione di inclusione fra use-case, indica che la funzione rappresentata da uno dei due use-case (quello alla base della freccia) include completamente la funzione rappresentata dall'altro. La relazione di estensione è rappresentata in modo analogo.
Ognuno dei casi d'uso può essere dettagliato tramite diagrammi di attività e sequenza.
L'activity diagram è una generalizzazione del classico diagramma di flusso. Viene generalmente utilizzato per dettagliare un'attività o un algoritmo.
Le linee verticali (swimline) separano le attività effettuate dei vari elementi coinvolti.
Le linee orizzontali rappresentano dei punti di fork o join di attività svolte in parallelo.
I rombi rappresentano scelte.
Il diagramma di sequenza rappresenta in senso verticale l'ordine temporale degli eventi (messaggi) coinvolti.
I normali messaggi vengono rappresentati da una linea continua, mentre i messaggi di ritorno (ricevuta) si rappresentano con una linea tratteggiata
I messaggi possono rappresentare qualsiasi interazione fra gli elementi, quindi anche chiamate di funzioni.
Rappresenta i differenti possibili stati di un generico oggetto e le transizioni tra gli stessi.
Ogni stato è rappresentato da un rettangolo con spigoli arrotondati, mentre le frecce di congiunzione rappresentano le transizioni.
Gli siati iniziale e finale sono rappresentati da circoli pieni (quello finale è coronato).
Un circolo vuoto rappresenta un punto di decisione
Rappresenta la struttura statica di un codice ad oggetti
Ognuno dei rettangoli rappresenta una classe nella quale metodi e proprietà possono o meno venire rappresentati.
La visibilità è rappresentata dai seguenti caratteri:
+ : pubblico
- : privato
# : protetto
~ : package (java)
I segmenti rappresentano i rapporti tra le classi e sono qualificati dal simbolo di terminazione:
* nessun simbolo : associazione generica
* rombo vuoto: aggregazione (la classe contiene...)
* rombo pieno: composizione (forma forte di aggregazione)
* triangolo: derivazione (ereditarietà)
I numeri rappresentano la molteplicità del rapporto, cioè quanti oggetti di una certa classe sono associati ad un altra.
Il component diagram rappresenta la composizione del sistema nei suoi elementi software, mentre il deployment diagram rappresenta la distribuzione fisica. Le due rappresentazioni possono essere unificate, in modo da rappresentare sia i componenti software che la loro distribuzione hardware.
Gli elementi contenitori saranno quindi le sedi hardware dei vari componenti software, rappresentati come in figura.
I segmenti tratteggiati tra i componenti rappresentano le dipendenze, mentre i segmenti continui tra i nodi rappresentano le associazioni.