A questo punto abbiamo terminato la nostra panoramica sull’UML. Al termine di questa guida il lettore avrà compreso l’enorme potenzialità che questo linguaggio di modellazione offre, infatti, con tutti i possibili diagrammi che è possibile realizzare possiamo rappresentare la struttura del nostro progetto, aspetti statici e dinamici di funzionamento, relazioni tra i vari componenti costituenti il progetto stesso e molto altro. E’ possibile che il lettore si senta, al termine della lettura, disorientato data la multitudine di strumenti messi a disposizione e una domanda che molti si pongono è: per il mio progetto, devo realizzare tutti questi diagrammi? Secondo i puristi della progettazione e dello sviluppo software la modellazione di tutti questi diagrammi è necessaria, ma all’atto pratico quasi nessuna azienda che produce software compie questo lavoro. Essendo realisti, se si dovesse modellare tutti questi digrammi per ogni progetto il tempo di realizzazione di un software si triplicherebbe rispetto al normale. Dunque, dato che non tutti i diagrammi, sono così importanti per un corretto funzionamento del software è giusto trovare un compromesso di realizzazione. Potrete capire quali sono i diagrammi indispensabili dalla lunghezza della trattazione nella guida. Infatti, volutamente, si è voluto dare spazio maggiormente ad alcuni diagrammi rispetto ad altri data la loro importanza.
Sicuramente possiamo affermare che il diagramma delle classi è un requisito fondamentale. E’ impensabile progettare un sistema di grosse dimensioni funzionanti senza alle spalle un lavoro di modellazione delle classi. Per quanto riguarda i diagrammi dei casi d’uso possiamo dire che molti potrebbero essere tralasciati, ma è buona norma realizzarli, soprattutto la parte testuale, per mostrare al committente come vengono espletate le varie funzionalità. Molto spesso, una stessa operazione (per esempio l’acquisto su un sito di e-commerce) viene svolta seguendo processi diversi che magari, secondo logiche di marketing, possono portare a vantaggi dal punto di vista delle vendite. Dunque i casi d’uso sono necessari per mostrare come si opera in maniera comprensibile a tutti. Per i diagrammi di sequenza diciamo che è buona norma svilupparli solo per le funzionalità critiche o comunque abbastanza complesse dove è necessario schematizzare chi compie cosa. Per operazioni semplici si può tranquillamente ometterne il diagramma di sequenza. Stessa cosa vale per i diagrammi di attività; solitamente si utilizzano per schematizzare procedimenti o algoritmi complessi dove è necessario capire la sequenza di operazioni per compiere eventuali ottimizzazioni. I diagrammi degli stati, come abbiamo visto, sono uno strumento molto potente, ma solitamente si usano quando il sistema si presta bene alla schematizzazione a stati. Per esempio lo sportello bancomat o l’erogatore di bibite o un distributore di benzina si prestano bene a questa modellazione, mentre altre problematiche, come per esempio la realizzazione di un editor testuale non è facilmente schematizzabile come una macchina a stati. Per quanto concerne il diagramma degli oggeti, come è stato detto anche . dalla lista delel cose fondamentali, questo diagramma.
Date queste piccole linee guida e fornite al lettore gli strumenti principali che l’UML mette a disposizione, la cosa migliore è inventarsi un progetto da realizzare (come è stato fatto per l’esempio dello zoo) e costruire su questo progetto i principali diagrammi. E’ anche possibile effettuare delle ricerche in internet di esami di ingegneria del software assegnati agli studenti da parte di professori universitari.
