Continuiamo adesso il nostro esempio sul prestito dei libri. Come nel caso precedente mostriamo il diagramma UML ultimato per poi commentarlo in maniera dettagliata:
Premettiamo che nel diagramma sopra mostrato sono stati inseriti dei blocchettini che non sono necessari, ma ciò è stato fatto per rendere il diagramma più chiaro e leggibile dato che l’editor non permette molta personalizzazione. Dunque passando all’analisi del diagramma vediamo che il gestore clienti, non appena ricevuto il ritorno della precedente operazione, effettua una richiesta all’oggetto utente per verificare se ha superato il numero massimo di prestiti concessi contemporaneamente. Come vediamo questa richiesta, non svolge direttamente nessuna operazione, ma delega il calcolo all’operazione verifica prestiti. Questo tipo di operazione è diversa rispetto alle altre precedentemente mostrate in quanto non c’è interazione con altri oggetti, ma tutto avviene all’interno dell’oggetto. Ciò vuol dire che operazioni di questo tipo possono essere calcoli matematici, esecuzione di algoritmi ed in generale quella serie di operazioni necessarie per raggiungere un risultato. Infine si ha l’operazione richiesta di aggiornamento dei prestiti della biblioteca.
Abbiamo, in questo diagramma, modellato le sequenze necessarie per il prestito di un libro nel caso in cui alcune condizioni siano soddisfatte. E’ buona norma modellare anche gli scenari in cui per esempio l’utente ha superato il numero massimo di prestiti oppure che il libro non è disponibile. Data la semplicità dei diagrammi e la somiglianaza con quelli mostrati precedentemente possiamo lasciare al lettore, per esercizio, la realizzazioni di questi diagrammi. Come abbiamo avuto modo di vedere nel’esercizio precedente la costruzione dei diagrammi di sequenza è abbastanza semplice e segue i seguenti step:
- Per prima cosa si posizionano gli oggetti che già sono stati istanziati al momento della rappresentazione del diagramma.
- Si creano le chiamate da un oggetto ad un altro. Nel caso in cui la chiamata istanzi un oggetto questo deve essere posto in quella posizione per mantenere la correttezza di esecuzione dal punto di vista temporale.
- Dopo ogni chiamata si inserisce nel diagramma il ritorno relativo descrivendo brevemente il risultato.
- Si itera il processo per ogni chiamata da un oggetto ad un altro.
E’ importante fare una considerazione riguardo i diagrammi di sequenza. Come abbiamo detto nei capitoli precedenti il diagramma delle classi e quello dei casi d’uso presentano alcuni gradi di libertà per quanto riguarda la progettazione, ma per i diagrammi di sequenza ciò non avviene. Infatti partendo da uno stesso diagramma delle classi non è possibile, per una stessa operazione, creare due diagrammi di sequenza diversi ed entrambi corretti. Questo perchè, le operazioni indicate dalle frecce, richiamano uno o più metodi che un oggetto possiede e dunque delegare la stessa operazione ad un altro oggetto che non possiede questi metodi significa modellare un diagramma di sequenza inconsistente. Progettare un diagramma inconsistente, ovviamente, compromette il corretto funzionamento del software che andremo a realizzare. I diagrammi di sequenza sono utili anche per vedere se ciò che abbiamo realizzato è corretto dal punto di vista concettuale. Infatti se per esempio modificassimo il diagramma di sequenza delegando all’oggetto utente il controllo se un libro è in prestito o meno implementando questa funzionalità nella classe, avremo un software perfettamente funzionante, ma sbagliato concettualmente in quanto non ha senso che la classe utente faccia questo controllo.
Un sistema ben progettato ha una struttura simile a quella mostrata nel diagramma di sequenza, ovvero per ogni funzionalità che il sistema possiede dovrebbe essere presente una classe che gestisce la funzionalità effettuando i vari controlli e i vari aggiornamenti. In questo modo, in caso di malfunzionamenti, è possibile individuare subito il “responsabile” e modificare eventuali parti del codice che presentano dei bug.
