Nel campo dell’informatica, sappiamo che un programma è una sequenza di istruzioni eseguite da un dispositivo elettronico digitale, al fine di risolvere un particolare problema.

Lo sviluppo di un software segue un iter ben determinato. Questo è detto ciclo di vita del software. Cioè, in altre parole, i passi che ci sono fra l'idea di un software e la sua realizzazione finale.

Uno dei più importanti ciclo di vita seguito dagli ingegneri è quello qui schematizzato:

Che cosa rappresentano questi passi?

La prima fase è quella di Analisi, che consiste nel raccogliere tutti i requisiti funzionali. Questo viene fatto interrogando l'utente finale o il committente. La domanda a cui si deve rispondere è: “Cosa deve fare il software?”. Una volta completato questo punto, si passa alla Progettazione, la fase in cui, appunto, si deve progettare la soluzione. Qui la domanda a cui dare risposta è: ”Come deve farlo il software?”.

Solo dopo queste due prime fasi abbiamo lo Sviluppo, cioè la scrittura vera e propria, mediante un linguaggio di programmazione, del codice finale che poi, dato in pasto ad un dispositivo elettronico digitale, produrrà la soluzione al mio problema iniziale. La fase successiva è il Collaudo, in cui si eseguono tutti i test necessari per verificare che il software rispetti i requisiti e che si comporti sempre nel modo atteso.

Nell'ultima fase, la Manutenzione, ci si concentra sulla correzione di errori e perfezionamenti vari.

In realtà il ciclo non si conclude con questa fase, poiché a seconda delle modifiche da effettuare, è necessario ripartire dal principio.

Va detto che questo modello, detto a cascata, non è l'unico approccio per la realizzazione di un software.

La branca che studia l’evoluzione del software durante le sue fasi è l’ ingegneria del software .

In che modo vengono raccolti i requisiti?

Quando si progetta una casa ad esempio, tutti i vari requisiti che deve avere, come metratura, disposizione interna, impianti vari, tipologia materiali, ecc. non vengono scritti un po’ alla rinfusa per poi essere passati a chi gestisce il cantiere. Come puoi immaginare, invece, esistono dei progetti, disegni, mappe, schemi, tabelle, normative, ecc., tutte riportate e descritte mediante strumenti standard noti e accettati da tutti. Nell’ingegneria del software è la stessa cosa. Il cliente non va dallo sviluppatore per dargli la descrizione del suo problema, così come l’acquirente della casa non va di certo a dare i requisiti direttamente al muratore.

Pertanto le prime due fasi, analisi e progettazione, ricoprono un ruolo di primaria importanza nel ciclo di vita del software. Nel corso degli anni è emersa sempre più forte l’esigenza di rendere standard queste fasi, o meglio, trovare un linguaggio accettato da tutti per la raccolta dei requisiti e la progettazione delle funzionalità del software. Il linguaggio UML, Unified Modeling Language, è ormai lo standard universalmente riconosciuto per la modellazione e la specifica di un software.

L’UML dispone di una numerosa serie di diagrammi e schemi, i quali possono essere usati per rappresentare sostanzialmente due cose: le necessità del committente finale per la soluzione di un suo problema (requisiti) e la descrizione del software, in termini di componenti e comportamenti.

Ma era proprio necessario questo nuovo linguaggio?

L’utilizzo dell’UML introduce degli indubbi vantaggi, vediamo quali:

  • Viene proposta una modellazione universalmente accettata di tutto l’insieme, visione che può essere interpretata senza ambiguità da chiunque è coinvolto nel processo o ne è parte attiva: clienti, analisti, programmatori, ecc. sia nel momento stesso di sviluppo, che in quelli successivi. Questo rende la comunicazione più efficace e diminuisce gli sprechi di tempo.
  • Un sistema software, grazie al linguaggio UML, viene descritto, modellato e documentato ancor prima di mettere mano al suo codice. In tal modo si riesce a sapere già da subito quali sono i comportamenti attesi e i risultati finali che otterremo.
  • La conseguenza del punto precedente è che si ha uno sviluppo del codice sorgente più agevole ed efficiente, con la conseguenza che i costi globali si abbasseranno notevolmente
  • Sarà più facile prevedere eventuali mancanze nel sistema, ad esempio requisiti non rispettati o comportamenti non desiderati.
  • Chiarire i dettagli del sistema già dalle prime fasi dello sviluppo, permette anche di sfruttare al meglio le risorse hardware, come la CPU o la memoria, senza inutili sprechi o, al contrario, evitare di sottostimare i requisiti di partenza.

Vediamo un esempio

Uno dei diagrammi principali a cui si ricorre in fase di analisi è il così detto Diagramma dei casi d’uso. Questo deve rappresentare gli attori del sistema (cioè le figure che ne fanno parte) e le sue varie funzionalità. E’ un modello descrittivo del sistema che andiamo a studiare, mediante una rappresentazione rigorosa.

Supponiamo di voler sviluppare un software che gestisca la vendita online di prodotti.

Una prima approssimazione di diagramma dei casi d’uso potrebbe essere il seguente:

Come puoi vedere, il diagramma descrive ad alto livello le funzionalità che il sistema deve avere. Gli omini stilizzati sono chiamati attori e possono essere sia umani che interagiscono, sia entità digitali, come dei servizi.

Ad esempio, notiamo che l’attore ‘cliente web’ può essere specializzato in due figure differenti a seconda che sia già registrato nel sistema o no. Oppure si evince che la funzione pagamento coinvolge il servizio di autenticazione, ecc. Ovviamente questo schema può essere poi ulteriormente raffinato e completato.

In definitiva l’UML offre molte tipologie di diagrammi come questo, ciascuno dei quali è stato pensato per arricchire la visione complessiva dell’intero sistema. Alla fine otterremo una sua completa descrizione mediante un linguaggio rigoroso ma facilmente interpretabile da tutte le figure coinvolte.