Si è già accennato nell'introduzione circa la similitudine tra i
diagrammi UML e una cianografia. È, però, importante capire bene ed
approfondire un attimo il concetto di "Visual Modeling" prima di andare
avanti.
Abbiamo già utilizzato, precedentemente, il termine Sistema. Ma, prima di tutto, cosa è esattamente un Sistema (informatico)?
Un Sistema
è una combinazione di componenti software e hardware che fornisce una
soluzione ad un'esigenza del mondo reale (business problem).
Per far sì che un Sistema sia efficiente, sarà necessario recepire bene
le richieste del cliente e fare in modo che esse vengano condivise e
recepite come requisiti indispensabili dall'intero team di lavoro.
Successivamente, si useranno tali requisiti per generare il codice
necessario alla costruzione del Sistema assicurandosi, andando avanti
nella scrittura del codice, che non si perda di vista l'obiettivo
finale. Tale procedimento prende il nome di "Modeling" (o, se preferite, modellazione).
Il "veccho" metodo di modeling dei sistemi, conosciuto anche come "Metodo a Cascata"
(Waterfall Method), si basava sul fatto che i vari passi che
costituivano il processo di sviluppo di un sistema fossero sequenziali
(l'inizio di uno avveniva soltanto dopo il termine di un altro).
Quello che accadeva seguendo il waterfall method era che le persone del
team si trovavano a lavorare su task differenti e spesso, non avevano
alcun modo di comunicare a discapito di importanti questioni inerenti
il Sistema stesso. Un altro punto debole
del waterfall method era il fatto che esso prevedeva che si concedesse
la maggior parte del tempo alla scrittura del codice, togliendolo, in
tal modo, all'analisi ed al disegno che invece rappresentano la base
per un solido progetto.
Il Visual Modeling, che ha
soppiantato ormai il waterfall method, altro non è che il processo che
prevede la visualizzazione grafica di un modello, utilizzando un
insieme ben definito di elementi grafici, che nel linguaggio UML sono
rappresentati dai 9 Diagrammi di base.
Il processo per la costruzione di un Sistema coinvolge molte persone: Prima di tutto il cliente, ovvero la persona che desidera avere una risoluzione ad un problema o ad una sua esigenza. Un analista ha il compito di documentare il problema del cliente e trasmettere tali informazioni agli sviluppatori,
i quali costituiscono la parte del team che si occupa di implementare
il codice, testarlo ( con il supporto di un team apposito per il test)
e installarlo sull'hardware dei computer.
Questo tipo di suddivisione dei compiti è necessario poiché al giorno
d'oggi i sistemi sono diventati davvero molto complessi e la conoscenza
è divenuta molto più specializzata da non poter essere gestita soltanto
da una persona.
Il Visual Modeling prevede una continua interazione tra i vari membri
del team di lavoro. Analisti e disegnatori, per esempio, necessitano di
un continuo scambio di vedute per permettere che i programmatori
possano basarsi su una solida informazione. A loro volta, i
programmatori devono interagire con gli analisti ed i disegnatori per
condividere le loro intuizioni, modificare i disegni e consolidare il
codice.
Il vantaggio di tale tipo di approccio è che la conoscenza generale del
team cresce notevolmente, ognuno è in grado di capire a fondo il
sistema e il risultato finale non può che essere un sistema più solido
(con il cliente più soddisfatto!).