Figura 4.1: Occultamento delle informazioni interne all’oggetto.
Polimorfismo Metodi con lo stesso nome hanno una semantica diversa,
secondo il contesto in cui vengono richiamati (concetto di overriding). La progettazione del software secondo il paradigma orientato agli og- getti cerca di ottenere i seguenti obiettivi:
• la scomposizione del problema in sottoproblemi, ognuno dei quali
viene risolto attraverso un singolo modulo software. La soluzione al problema generale `e ottenuta mediante l’interazione tra questi componenti, che espongono interfacce ben definite;
• riunione delle classi in archivi per facilitarne il riutilizzo;
• riuso del prodotto a vari livelli (tutta l’applicazione o solo alcuni
componenti, documenti di analisi o di progetto, ecc.).
4.2
UML e il contesto dell’automazione
Durante gli anni ’90 furono introdotte nel mercato dell’Information Tech- nology parecchie metodologie per il design e la progettazione di sistemi software. Vi era un problema, per`o: ognuna di queste tecnologie aveva il suo insieme proprio di notazioni e simboli che differiva, a volte in modo rilevante, dalle altre. In particolare, eccellevano tre di queste metodologie:
46 La progettazione informatica
• OMT (Rumbaugh);
• Booch 1991;
• OOSE (Jacobson).
Ognuno di questi metodi aveva, naturalmente, i suoi punti di forza e i suoi punti deboli. Ad esempio, l’OMT si rivelava ottimo in analisi e debole nel design. Booch 1991, al contrario, eccelleva nel disegno e peccava in analisi. OOSE aveva il suo punto di forza nell’analisi dei requisiti e del comportamento di un sistema ma si rivelava debole in altre aree.
Successivamente, Booch scrisse il suo secondo libro che adottava i prin- cipi di analisi utilizzati da Rumbaugh e Jacobson nelle loro rispettive me- todologie. A sua volta, Rumbaugh pubblic`o una serie di articoli (conosciuti come OMT-2) che descrivevano parecchie delle tecnologie di disegno di Booch. In sostanza, i tre metodi stavano convergendo verso un’unica visio- ne che incorporasse le qualit`a migliori che ognuno di essi aveva mostrato. L’unico problema che restava era il fatto che ogni metodo portava ancora con s`e la propria notazione.
Tale problema non era da sottovalutare in quanto l’uso di simbologia differente portava facilmente confusione sul mercato a causa del fatto che un determinato simbolo poteva avere un significato differente per analisti e disegnatori differenti.
Finalmente, dopo un periodo di tempo in cui and`o avanti la cosidetta “guerra della metodologia” ci si rese conto che era assolutamente neces- sario produrre uno standard che unificasse anche la notazione utilizzata. Fu cos`ı che, nell’Ottobre del 1995, nacque la prima bozza dell’UML (Unified
Modeling Language) [7], ovvero l’unificazione delle notazioni e delle idee
prodotte da Booch, Rumbaugh e Jacobson per modellare un sistema soft- ware. La prima versione ufficiale, prodotta dall’OMG (Object Management
Group) [8] fu rilasciata nel Luglio del 1997 e nel Novembre dello stesso
anno l’UML venne adottato come standard.
Elenchiamo, qui di seguito, alcuni dei benefici derivanti dall’utilizzo del linguaggio UML:
4.2 UML e il contesto dell’automazione 47
• un sistema software, grazie al linguaggio UML, viene disegnato pro- fessionalmente e documentato ancor prima che ne venga scritto il
relativo codice da parte degli sviluppatori. Si sar`a cos`ı in grado di conoscere in anticipo il risultato finale del progetto su cui si sta lavorando;
• poich´e la fase di disegno del sistema precede la fase di scrittura del
codice, ne consegue che questa `e resa pi`u agevole ed efficiente, oltre al fatto che in tal modo `e pi`u facile scrivere del codice riutilizzabile in futuro. I costi di sviluppo, dunque, si abbassano notevolmente con l’utilizzo del linguaggio UML;
• `e pi`u facile prevedere e anticipare eventuali “buchi” nel sistema. Il software che si scrive, si comporter`a esattamente come ci si aspetta senza spiacevoli sorprese finali;
• l’utilizzo dei diagrammi UML permette di avere una chiara idea, a
chiunque sia coinvolto nello sviluppo, di tutto l’insieme che costituisce il sistema. In questo modo, si potranno sfruttare al meglio anche le risorse hardware in termini di memoria ed efficienza, senza sprechi inutili o, al contrario, rischi di sottostima dei requisiti di sistema;
• grazie alla documentazione del linguaggio UML diviene ancora pi`u facile effettuare eventuali modifiche future al codice. Questo, ancora, a tutto beneficio dei costi di mantenimento del sistema.
La comunicazione e l’interazione tra tutte le risorse umane che prendono parte allo sviluppo del sistema `e molto pi`u efficiente e diretta. Parlare la stessa “lingua” aiuta ad evitare rischi di incomprensioni e quindi sprechi di tempo.
L’applicazione dei modelli UML a un contesto come quello dell’automa- zione di edifici consente di massimizzare la produttivit`a dello sviluppatore potendo fornire al cliente una rappresentazione comprensibile e favorisce la stesura delle specifiche tecniche da considerare per l’implementazione del sistema.
48 La progettazione informatica
4.3
UML e metodologie per la progettazione del soft-
ware
L’utilizzo di una metodologia rigorosa nel design e nella progettazione di un software (vedi [9] e [10]) aumenta la complessit`a del lavoro di documen- tazione da effettuare, ma fornisce indicazioni preziose sulle fasi da seguire e migliora la cognizione di causa sull’intero progetto.
Una sintesi delle operazioni da svolgersi per una corretta serializzazio- ne del lavoro pu`o essere riassunta nei seguenti passaggi:
Raccolta dei requisiti `E la prima fase del lavoro congiunto con il cliente che, partendo dalle sue intenzioni iniziali e dai suoi desideri, ha lo scopo di produrre un documento informale, scritto in linguaggio natu- rale, che elenchi i requisiti e le specifiche richiesti. In pratica questo primo documento serve a circoscrivere i limiti del lavoro successivo. Deve essere breve e il pi`u possibile accurato;
Stesura del Glossario In questa fase si deve definire la terminologia del
progetto, identificando con precisione le entit`a (persone, ruoli, luoghi, oggetti materiali, eventi, strutturazioni, ecc.) coinvolte nel sistema del mondo reale (ovvero del dominio di business) che hanno importanza per il sistema informatico obiettivo del progetto. `E importante iden- tificare con precisione le entit`a allo scopo sia di definire meglio i loro scenari d’uso (Use Case), sia di individuare le classi entit`a (Class
Diagram di analisi). Il risultato di questa fase `e il glossario;
Stesura degli Use Case In questa fase devono essere individuati con pre-
cisione gli scenari di interazione fra il sistema e gli attori, ovvero le entit`a esterne al sistema con cui esso interagisce e comunica. I passi necessari in questa fase possono essere cos`ı suddivisi:
1. Definizione esatta del boundary o confine del sistema (entro sistemi particolarmente complessi questa fase pu`o anche essere applicata a sottosistemi);