Spiegato che cosa si intende per sviluppo software e forniti al lettore gli strumenti necessari per produrre diagrammi UML, possiamo iniziare la trattazione del linguaggio definendo i possibili diagrammi che possono essere realizzati. In questo elenco verranno citati solo i diagrammi più utilizzati, tralasciando volutamente gli altri. Al fine di comprendere molto rapidamente la guida si consiglia di avere già qualche esperienza, anche di base, della logica della programmazione ad oggetti. Comunque sia, durante la trattazione dei vari argomenti, verranno effettuati dei richiami di programmazione ad oggetti per quanto riguarda classi, oggetti ed ereditarietà.
Diagramma delle classi (Class Diagram)
E’ il diagramma più importante nella modellazione UML e rappresenta la struttura intera del nostro progetto. Come dice la parola stessa, il diagramma delle classi, rappresenta le varie classi presenti collegate tra di loro dalle rispettive relazioni. Proprio grazie al diagramma delle classi è possibile tradurre il progetto modellato in progetto concreto con la stesura del codice. Ma che cosa rappresenta una classe? Una classe identifica un insieme di oggetti che hanno simili proprietà e compiono simili azioni.
Diagramma degli oggetti (Object Diagram)
Molto simile al diagramma delle classi; in questo diagramma vengono rappresentati gli oggetti, ovvero le istanze concrete di una classe, e le varie relazione presenti. E’ un diagramma di tipo statico, ovvero è un diagramma che rappresenta il sistema in un certo istante di tempo ed è una sorta di fotografia della struttura del sistema nel momento dello scatto. Per questo motivo digrammi degli oggetti ad istanti differenti potranno differire sia per numero di oggetti presenti sia per i valori relativi agli attributi di un oggetto. Ipotizziamo infatti di voler modellare una chat internet: avremo presumibilmente una classe server e una utente. Il diagramma degli oggetti all’inizio del processo vedrà presente solo un unico oggetto, l’oggetto Server, mentre se eseguissimo una modellazione ad istanti successivi avremo sicuramente, oltre all’oggetto Server anche vari oggetti Utente che sono connessi . Data la sua dipendenza dal tempo non è un diagramma troppo utilizzato.
Diagramma dei casi d’uso (Use case Diagram)
Questo tipo di diagramma è molto utile per modellare il funzionamento dinamico di una certa funzionalità del sistema. Uno dei vantaggi di questi diagrammi è il fatto di essere estremamente semplici da leggere anche da chi non ha esperienze di UML in quanto sono molto intuitivi. Per fare un esempio pratico di diagramma di un caso d’uso potrebbe essere quello di modellare l’azione di prelievo di soldi da uno sportello di una banca: l’utente inserisce la carta, selezione la funzionalità “prelievo”, inserisci il pin relativo alla carta, digita l’importo, prende i soldi e ritira la carta.
Diagramma di stato (State Diagram)
E’ il diagramma utilizzato per mostrare il comportamento di un determinato sistema. E’ molto utile per mostrare come un sistema si comporta in relazione ad input ricevuto da un utente. Per riallacciarsi all’esempio del prelievo di soldi potremo fare un digramma di stato dello sportello bancomat: inizialmente lo sportello si trova nello stato di “wait”, poi appena l’utente inserisce la carta si passa nello stato “ready”, a seconda dell’input si passa ad un altro stato e così via. In questi diagrammi è buona norma rappresentare anche le situazioni di errore come per esempio la situazione in cui l’utente sbagli per tre volte il pin nel qual caso si entrerà, per esempio, nello stato “trattieni carta” per poi passare nuovamente allo stato di “wait” in attesa di un’altra operazione.
Diagramma di attività (Activity Diagram)
Il diagramma viene utilizzato per mostrare le varie attività che vengono eseguite per espletare una determinata funzione prevista dal sistema. Questo diagramma è utilizzato, principalmente, per mostrare i vari passi che un algoritmo, di qualsiasi genere, compie prima di produrre il risultato atteso. Se il sistema da progettare implementa algoritmi abbastanza complessi, conviene sempre creare un diagramma delle attività per non compiere errori di progettazione.
Diagramma di sequenza (Sequence Diagram)
E’ un diagramma che per certi versi è legato al diagramma dei casi d’uso. Il diagramma di sequenza mostra le varie azioni compiute dall’utente e dal sistema quando viene richiesto un determinato servizio, mostrando tutte le interazioni tra i due e tra eventuali sotto-sistemi.
Nei prossimi capitoli andremo ad analizzare, più approfonditamente, ognuno dei diagrammi sopra citati.
