In questa guida tratteremo gli aspetti dell'analisi e della progettazione orientata agli oggetti. Per fare ciò utilizzeremo un linguaggio di modellazione chiamato UML (Unified Modelling Language), il quale ci aiuterà a rappresentare, soprattutto graficamente, cosa il nostro programma dovrà fare. Inoltre l'UML fornisce una rappresentazione molto chiara e compatta dell'intera struttura dell'applicazione che andremo ad analizzare.
Un po' di storia
Per quanto riguarda l'età dell'UML possiamo dire che è abbastanza recente in quanto la prima versione dell'UML è stata redatta dall'OMG (Object Management Group) nel 1997. Possiamo dire che le prime tecniche per la modellazione della struttura di un'applicazione risalgono a circa una decina di anni prima rispetto al rilascio del linguaggio UML vero e proprio. Queste metodologie, presentate da enti diversi, avevano i loro pregi e i loro difetti, ma il grande problema, in quel periodo, era che le varie metodologie proposte non presentavano un set di simboli universali, ma ogni metodologia ne adottava uno diverso dalle altre. Questa mancanza di simboli universali portava a conseguenti problemi di interpretazione, infatti un simbolo che per una metodologia di modellazione rappresentava l'associazione, magari per un'altra metodologia rappresentava una specializzazione di una classe. Questo causava frequenti incomprensioni nella lettura degli schemi prodotti e quindi si sentì l'esigenza di dover stabilire un set di simboli universali e creare una metodologia unica. Da questa volontà di standardizzare questo linguaggio, nacque appunto l'UML che racchiude i principali punti di forza delle metodologie che precedentemente erano state proposte.
A cosa serve UML?
Adesso il lettore potrebbe chiedersi: ma quale è la vera utilità dell'UML? Iniziamo con il fare un'analogia pratica applicata alla vita reale: UML è il linguaggio che consente di realizzare il progetto che un costruttore segue per realizzare la sua opera. E' impensabile costruire un palazzo senza un solido progetto iniziale da seguire fedelmente. Capito quindi, nella pratica cosa è l'UML, vediamo i principali punti di forza del linguaggio:
L'UML è un linguaggio molto semplice da imparare e molto intuitivo e ciò consente un rapido apprendimento di tutte le metodologie più importanti. Inoltre è estramente più semplice leggere uno schema di un'applicazione fatto in UML piuttosto che leggere il codice sorgente dell'applicazione stessa. Infatti la lettura dello schema UML permette una rapida comprensione delle varie funzionalità e tutte le relazioni tra i vari oggetti che la compongono, tutto ciò anche senza una conoscenza approfondita dell'UML. Situazione opposta è la lettura di codice sorgente di un'applicazione con un gran numero di classi: ciò richiede sicuramente molto più tempo rispetto alla lettura di uno schema UML e richiede un elevatissima conoscenza del linguaggio in cui l'applicazione è stata scritta.
La modifica di uno schema UML è estremamente più semplice rispetto ad una modifica da apportare ad un codice sorgente già scritto. Infatti molti dei bug che i software presentano sono dovuti ad un'errata fase di progettazione, che ha portato i programmatori a modificare la struttura del programma in fase di scrittura del codice. Immaginate infatti di programmare in C++ e avere una classe che possiede un certo numero di attributi e diversi metodi che compiono delle operazioni su questi attributi. Ad un certo punto della stesura del codice vi accorgete che un attributo dichiarato come string debba essere modificato in char *. Dovremo rimettere le mani in tutta la classe in quanto dovranno essere modificati tutti i file header con i prototipi dei vari metodi e anche tutte le varie implementazioni dei metodi. Capite bene che se si ha a che fare con progetti di grosse dimensioni ciò può portare ad uno spreco di tempo molto consistente ed un'alta probabilità di introdurre bug nel software.
In sostanza possiamo dire che se si crea un modello UML robusto e ben strutturato non avremo nessun problema a convertirlo in righe di codice e poi in un programma realmente funzionante. La raccomandazione che posso farvi è che conviene sempre spendere qualche ora in più nella revisione e nel miglioramento del vostro modello UML piuttosto che modificare successivamente il codice sorgente dell'applicazione.
