UML e Ingegneria Del Software, Dalla Teoria Alla Pratica (Luca Vetti Tagliati)(Giugno 2003) Hops

A Francesco e Anna, miei dolci genitori: a voi cui tutto devo. Silenzio assordante Eco smarrita Frastuono di preghiera inconsolata sussurrata nella notte.

IntroduzioneNemo propheta in patria

PrefazioneProbabilmente gran parte dei lettori di questo libro conosceranno svariati trattati relativi alla programmazione Object Oriented, magari in Java, e avranno partecipato alla costruzione di sistemi informatici pi o meno complessi. Altrettanto probabilmente, una buona percentuale avr constatato che non sempre il modo di produrre sistemi software segue un approccio, per cos dire, ingegneristico basato su un processo formale e che spesso il linguaggio di modellazione unificato (UML, Unified Modeling Language) recita un ruolo troppo marginale. Il problema che, sebbene lo UML sia un linguaggio magari di modellazione ma pur sempre un linguaggio non sempre chiaro come, quando e perch utilizzarlo. Ebbene, il presente libro si prefigge lobiettivo di fornire al lettore tutte le informazioni necessarie per utilizzare lo UML nel contesto dei processi di sviluppo del software, utilizzando un approccio operativo che per non trascuri limprescindibile teoria. Il libro stato scritto riducendo al minimo i prerequisiti, e conferendo particolare importanza agli esempi, specialmente quelli tratti da progetti reali, nella convinzione che un particolare legame con la realt quotidiana dellambiente lavorativo sia il mezzo pi idoneo per focalizzare rapidamente i concetti esposti nonch per procurare allautore vitto e alloggio a spese dello Stato. Ci nondimeno si cercato di non trascurare il pubblico pi esigente, inserendo nel libro diversi paragrafi di livello tecnico superiore. Si tratta tuttavia di sezioni dedicate a lettori che desiderano lapprofondimento, ben circoscritte e assolutamente opzionali, quindi non indispensabili alla comprensione di quanto

2

Introduzione

esposto. Il libro pertanto si presta ad essere fruito secondo diversi livelli di difficolt in base a necessit e obiettivi del lettore. Questo libro conferisce particolare enfasi a due grandi tematiche portanti: analisi dei requisiti utente e analisi e disegno del sistema. Quindi gli strumenti dello UML analizzati pi approfonditamente sono sia quelli utilizzati durante le relative fasi del processo di sviluppo del software sia quelli utilizzati pi frequentemente nel ciclo di vita del software: anche in questo contesto come rimarcato dallo stesso James Rumbaugh vale la famosa equazione dell80/20: l80% della modellazione di un sistema, tipicamente, necessita del 20% dei concetti dello UML. Ma quali sono i motivi che hanno spinto a scrivere un altro libro dedicato allo UML? Le risposte potrebbero essere due e molto semplici: perch in lingua italiana (o almeno in un suo surrogato); perch i libri dei Tres Amigos (James Rumbaugh, Ivar Jacobson, Grady Booch) pur essendo uno straordinario ausilio guai a non averne una copia, anche se mai aperta, poich si rischierebbe di suscitare giudizi di scarsa professionalit forse risentono del limite di essere poco accessibili a un pubblico non espertissimo di progettazione Object Oriented. Lidea di fondo del libro fornire un diverso livello di astrazione: i libri dei Tres Amigos offrono un livello molto elevato quasi filosofico mentre il presente vuole essere decisamente vicino alla pratica nel tentativo di fornire un supporto concreto a tutti coloro che utilizzano, o vorrebbero utilizzare, lo UML quotidianamente per costruire sistemi che funzionano. A tal fine sono stati utilizzati moltissimi esempi che, sebbene finiscano per rendere i capitoli decisamente corposi, sono comunque sezioni opzionali bench costellate di utili riflessioni. La scrittura del libro iniziata quasi congiuntamente alla pubblicazione della versione 1.2 dello UML e abbraccia un periodo di due anni di lavoro matto e disperatissimo. I contenuti sono costantemente revisionati e aggiornati sia al fine di renderlo via via conforme alle nuove specifiche, sia per integrare esempi sempre pi interessanti attinti dallesperienza lavorativa. Nella sua versione attuale, la variante dello UML di riferimento la 1.4, sebbene lautore stia controllando da vicino i lavori relativi alla versione 2. Tra le righe del libro fa capolino l(auto)ironia dellautore, coadiuvata alloccorrenza da quella dei collaboratori: ci sia al fine di rendere largomento meno gravoso, sia per evidenziare con spirito grottesco le distorsioni riscontrate nel modo di produrre il software in molte realt organizzative. Troppo spesso i vari manager sono sfrenatamente concentrati a consegnare i sistemi senza curare minimamente la crescita professionale del proprio personale e quindi, in ultima analisi, la qualit dei sistemi prodotti. Non il software che rifiuta lingegnerizzazione, ma i tecnici che rimangono intimoriti dalla progettazione:

UML e ingegneria del software: dalla teoria alla pratica

3

troppo spesso si ha la sensazione che la produzione del software sia ancora concepita come unarte piuttosto che come una scienza.

A chi rivoltoQuesto libro prevede un pubblico di potenziali lettori piuttosto vasto: tutti coloro che hanno a che fare con progetti basati sul paradigma Object Oriented (o Component Based). In particolare, potrebbe risultare vantaggioso per figure professionali che vanno dai tester ai programmatori, dagli architetti ai capi progetto, dai business analyst a, perch no, persone con ruoli a carattere pi commerciale. Gli architetti costituiscono sicuramente il pubblico ideale: loro, in effetti, dovrebbero essere in grado di utilizzare proficuamente il linguaggio durante tutta la fase di sviluppo del software, dallanalisi dei requisiti, al disegno del sistema, ai test di accettazione. I vantaggi che potrebbero ricavarne i programmatori scaturiscono essenzialmente dalla capacit di leggere i diagrammi forniti dagli architetti, per tradurli in codice e infine aggiornarli per far s che il disegno finale corrisponda alla reale implementezione del sistema. Non peccato mortale se limplementazione varia, entro certi limiti, dal modello di disegno sia perch non opportuno scendere eccessivamente in dettaglio nel disegno del sistema, sia perch non sempre possibile prevedere tutto fin dallinizio, inclusi malfunzionamenti di software fornito da terze parti. Nel mondo ideale la codifica dovrebbe essere immediata e senza troppe variazioni: nella realt non sempre cos. Variazioni in corso dopera sono normali fintantoch non stravolgano il disegno stesso. Sempre i programmatori, durante la codifica del disegno, dovrebbero avere bene in mente i casi duso oggetto dellimplementazione: essi descrivono la sequenza di azioni da svolgere nel caso in cui tutto funzioni correttamente e per gestire eventuali anomalie che potrebbero verificarsi. Per ci che concerne i capi progetto, in molti casi essi potrebbero aumentare la qualit del proprio lavoro utilizzando i diagrammi dei casi duso (use cases diagram) e pi in generale la relativa vista (use cases view, vista dei casi duso), sia al fine di coadiuvare il team nella cattura dei requisiti utente nel miglior modo possibile, sia per poter monitorare adeguatamente lo stato di avanzamento del progetto, sia per riuscire ad avere una pi intima conoscenza di cosa si sta costruendo. Il cliente alla fine verifica che il sistema realizzi correttamente quanto sancito nella use case view presente nel documento di analisi dei requisiti. I team leader, tra le altre attivit, potrebbero trarre enorme beneficio dallutilizzo dello UML per assolvere alle tipiche funzioni di coordinamento, supporto e addestramento del team e per coadiuvare i capi progetti nellanalisi della tempificazione al fine di renderla quanto pi reale possibile La tempificazione non esclusivo esercizio di fantasia: tempificare con successo non significa giocare al lotto con Microsoft Project. I tester dovrebbero essere in grado di validare, o, se si preferisce, di individuare malfunzionamenti eseguendo i famosi test a scatola nera (black box tests) per verificare che il sistema effettivamente aderisca alle specifiche catturate sempre dalla use case view.

4

Introduzione

Per terminare, i business analyst, nel loro lavoro di analisi dellorganizzazione del cliente e del relativo business, potrebbero utilizzare i diagrammi dello UML, per realizzare il famoso documento dei requisiti utente, modellando una prima versione del modello dei casi duso. Ci apporterebbe due validi risultati: semplificazione del lavoro dei tecnici responsabili delle fasi seguenti e accrescimento del livello di professionalit e della qualit della documentazione prodotta.

Consigli per la letturaVisto il grande impegno profuso nel redigere il presente libro, verrebbe voglia di consigliarne una lettura basata sul seguente algoritmo:Iterator pagineLibro = libroUML.iterator(); while ( pagineLibro.hasNext() ) { utente.read( pagineLibro.next() ) }

Chiss che ci possa essere realmente utile e possa fornire validi spunti soprattutto a coloro che non hanno molta esperienza dello UML e dei processi di sviluppo. Si comunque consapevoli di quanto poco e prezioso sia il tempo: si cercato di soddisfare le esigenze anche di coloro che sono desiderosi di arrivare direttamente al nocciolo degli argomenti senza perdere troppo tempo in tematiche ritenute meno interessanti. A tal fine il libro stato strutturato in modo da favorirne una fruizione diversificata dipendente dalle necessit dei singoli lettori. In particolare vi sono sezioni di elevata complessit dedicate ai lettori pi esigenti, che per possono essere assolutamente ignorate senza per questo precludersi la possibilit di comprendere quanto riportato negli altri paragrafi. Altre parti invece sono dedicate a considerazioni relative al processo di sviluppo: di nuovo, i lettori che volessero concentrare lattenzione unicamente sullo UML possono semplicemente sorvolare tali paragrafi. Infine, vi sono interi paragrafi dedicati allo stile da utilizzarsi per disegnare i vari diagrammi. Lobiettivo pertanto migliorare la forma senza entrare nel merito della semantica, quantunque le due caratteristiche non possano essere trattate in maniera completamente separata. Sebbene non siano di importanza fondamentale, questi paragrafi non sono neanche originati da un vezzo estetico. Si tratta di una serie regole che permettono di rendere i diagrammi pi eleganti, armoniosi, semplici, in poche parole pi accattivanti. Ci molto utile perch rende i diagrammi pi facilmente comprensibili, memorizzabili, concorre a ridurre le barriere psicologiche che spesso si innalzano nella mente dei fruitori dei diagrammi, ecc. I primi due capitoli (UML: che cosa , che cosa non e UML: struttura, organizzazione, utilizzo), considerata la genericit degli argomenti affrontati, possono risultare dispersivi


5

e a tratti tediosi. Sebbene non siano di importanza fondamentale, risultano utili per chiarire fin da subito cosa sia lo UML e il suo rapporto con le tecnologie attigue. A partire dal capitolo relativo ai casi duso, tutto diviene pi operativo e quindi scorrevole: si entra nel vivo dello UML! Infine presente un numero decisamente elevato di esempi attinti dal mondo del lavoro; tutti coloro certi di aver capito possono placidamente concentrarsi solo su alcuni di essi ignorando i restanti.

StrutturaQuesto libro stato strutturato in capitoli autonomi, in ognuno dei quali viene esaminato approfonditamente uno specifico argomento, cercando di limitare al massimo i rimandi ai capitoli successivi: non quindi necessario rincorrere gli argomenti per tutto il testo. Si tentato di ricostruire una sorta dunit dazione: Milan Kundera non approverebbe. Ci se da un lato offre evidenti vantaggi, dallaltro genera la necessit di introdurre inevitabili ridondanze

Capitolo 1 UML: che cosa , che cosa non Obiettivo del primo capitolo di presentare lo UML inquadrandolo nel suo contesto, chiarendo fin dal principio il rapporto esistente con le altre tecniche/metodologie che lo circondano. Il capitolo si apre con una breve panoramica storica dello Unified Modeling Language e delle motivazioni che hanno spinto i Tres Amigos ad affrontare lo straordinario progetto di un linguaggio di modellazione unificato. Si prosegue con una descrizione di cosa sia e cosa non sia lo Unified Modeling Language, della sua architettura e di quali siano gli obiettivi. Successivamente viene affrontato il tema dei pi diffusi processi di sviluppo del software e, in particolare, The Unified Software Development Process, Use Case Driven Object Modeling with UML, il Rational Unified Process (RUP), leXtreme Programming (XP) e lAgile Modeling (AM).

Capitolo 2 UML: struttura, organizzazione, utilizzoIl secondo capitolo interamente dedicato a una panoramica dello UML: vengono presentate le viste, i diagrammi e i meccanismi di estensione forniti dallo UML per aumentarne semantica e sintassi. Sono inoltre introdotti i profili, ossia collezioni di meccanismi di estensione predefiniti da utilizzarsi durante la modellazione di sistemi che utilizzano architetture standard quali ad esempio CORBA ed EJB (Appendice C) o per compiti specifici come la modellazione dellarea business.

6

Introduzione

Lobiettivo fornire unidea, quanto pi esauriente possibile, di cosa sia il linguaggio senza aver la pretesa che il lettore comprenda fin da subito tutti i concetti introdotti, per i quali sono presenti appositi capitoli di dettaglio. Importante iniziare a comprendere che lo UML fornisce tutta una serie di utensili, ciascuno dei quali risulta appropriato a scopi ben precisi e del tutto inadeguato ad altri: una vera e propria cassetta degli attrezzi. La descrizione dei vari manufatti che si prestano a essere realizzati per mezzo dello UML avviene nel contesto di un generico processo di riferimento.

Capitolo 3 Introduzione agli Use CaseNel terzo capitolo si focalizza lattenzione sulla teoria degli use case e sul relativo impiego rispettando rigorosamente le direttive dello UML. Nel capitolo seguente invece, ci si discoster sensibilmente dalle direttive standard, al fine di illustrare un utilizzo avanzato e maggiormente operativo dei casi duso. Dopo una breve disquisizione su cosa si intenda con i termini requisiti utente, si procede con lintroduzione della use cases view (vista dei casi duso), entrando finalmente nel vivo dello UML. Della vista dei casi duso sono descritte le due componenti: statica e dinamica. Per ci che riguarda la proiezione statica, sono descritti in dettaglio i diagrammi dei casi duso correlati da elementi e relazioni. Per ci che concerne la proiezione dinamica (ossia gli scenari), viene illustrata la versione standard basata sui flussi degli eventi e sui diagrammi dello UML atti a modellare comportamenti dinamici (diagrammi di sequenza, collaborazione, attivit, ecc.).

Capitolo 4 Modellazione avanzata degli Use CaseNel quarto capitolo viene illustrata una tecnica di utilizzo operativo per la cattura e la documentazione degli scenario dei casi duso che a volte si discosta sensibilmente dalle direttive standard. Modellare sistemi reali mette in luce una serie di problemi e lacune di cui si tratta raramente nei libri e nelle specifiche ufficiali dello UML. Si tratta di un capitolo di stampo decisamente pratico corredato da un notevole numero di esempi di casi duso pseudoreali. Sebbene non sia indispensabile esaminarli attentamente tutti, ognuno di essi stato selezionato in quanto fornisce una serie di spunti molto interessanti.

Capitolo 5 Completamento dellanalisi dei requisitiIl quinto capitolo verte sue due tematiche portanti: la presentazione di una tecnica dimostratasi particolarmente valida nellarduo compito dellanalisi dei requisiti utente e lillustrazione dei manufatti (artifact) che completano il modello dellanalisi dei requisiti.


7

Il problema che tenta di risolvere la tecnica di analisi dei requisiti esposta trovare una piattaforma di dialogo comune e costruttiva tra personale tecnico e clienti, in altre parole trovare un efficace raccordo tra i due diversi linguaggi tecnici: quello dellarea business e quello informatico. A tal fine viene sfruttato il formalismo degli activity diagram (diagramma delle attivit). Il modello dei casi duso, sebbene costituisca un artifact di importanza centrale nel contesto dei processi di sviluppo del software, da solo non assolutamente in grado di fornire sufficienti informazioni per il pieno svolgimento delle restanti fasi del ciclo di vita del sistema. La completa realizzazione della vista dei requisiti del sistema prevede la produzione di ulteriori manufatti complementari. In particolare, nel capitolo sono presentati artifact di notevole importanza, come il dettaglio delle interfacce, i test case, il documento dei requisiti non funzionali e le famosissime business rules.

Capitolo 6 Object Oriented in un chicco di granoIl sesto capitolo dedicato alla presentazione dei princpi fondamentali dellObject Oriented. Lobiettivo introdurre le nozioni utilizzate nei capitoli successivi, senza aver la presunzione di trattare in maniera approfondita un argomento cos importante e vasto. Il capitolo non poteva che iniziare con la definizione formale di oggetto e classe e delle relative relazioni, prosegue con lillustrazione degli elementi essenziali di cui composto un oggetto (identit, stato e interfaccia) e quindi presenta le tre leggi fondamentali dellObject Oriented (ereditariet, incapsulamento e polimorfismo). In questa sede si coglie loccasione per riportare alcuni errori tipicamente commessi da tecnici alle prime armi. Questa prima sezione termina con lintroduzione di due princpi fondamentale del disegno dei sistemi, note con i nomi di massima coesione e minimo accoppiamento. La parte conclusiva del capitolo dedicata al formalismo dellAbstract Data Type (tipo di dato astratto) e al Design By Contract (disegno per contratto).

Capitolo 7 Gli oggetti: una questione di classeIl settimo capitolo focalizzato sullillustrazione del formalismo dei diagrammi delle classi, probabilmente uno dei pi noti e affascinanti tra quelli definiti dallo UML. Nei processi di sviluppo del software, questo formalismo si presta a rappresentare formalmente molteplici artifact presenti in diversi stadi del processo. Nelle primissime fasi lo si adotta per rappresentare i modelli del dominio e di business, nello stadio di analisi utilizzato per dar luogo allomonimo modello, nella fase di disegno impiegato per progettare e documentare lorganizzazione in codice del sistema e cos via. Dopo aver illustrato come rappresentare in UML i concetti basilari di classi, interfacce, ecc., si passa allillustrazione delle diverse tipologie di relazioni. La modellazione di un sistema non richiede esclusivamente lidentificazione delle classi di cui composto, ma anche dei

8

Introduzione

legami che le interconnettono. Si prosegue pertanto passando in rassegna le relazioni con cui possibile collegare le classi tra loro. La sezione successiva del capitolo illustra il formalismo dei diagrammi degli oggetti (object diagram). Questi rappresentano una variante dei diagrammi delle classi, o meglio ne sono istanze e ne condividono gran parte della notazione. Rappresentano la famosa istantanea del sistema eseguita in un preciso istante di tempo di unipotetica esecuzione.

Capitolo 8 Le classi nei processiIl capitolo ottavo dedicato allillustrazione dellutilizzo del formalismo dei diagrammi delle classi nel contesto di un processo di sviluppo del software. In particolare si presentano le diverse versioni di modelli a oggetti, le loro propriet, un nutrito insieme di esempi e consigli, eventuali tranelli in cui possibile cadere, il rapporto di ciascuno di essi con i restanti, ecc. Si tratta di uno di quei capitoli che dovrebbe fornire risposte esaurienti agli interrogativi pi frequentemente posti allautore del libro. Il primo modello ad oggetti presentato quello relativo al dominio del problema (Domain Object Model). In particolare si presenta un processo pratico atto a semplificare lindividuazione delle classi appartenenti al modello e a inserirle in un contesto strutturato. Del processo viene fornito un esempio di applicazione, nel quale sono evidenziati errori ricorrenti e vengono dati utili consigli. Poich sempre meno frequente realizzare sistemi partendo dal nulla, mentre ormai prassi reingegnerizzare sistemi esistenti, si presenta una tecnica atta a realizzare prime versioni del modello a oggetti del dominio partendo dallanalisi di una base di dati del sistema. Il modello ad oggetti presentato successivamente quello relativo allarea business (Business Object Model). Si tratta di una versione molto simile a quello del dominio, in cui compaiono elementi aggiuntivi (work unit, unit di lavoro e worker, lavoratori). Pertanto si evidenziano le similitudini e le differenze con quello del dominio e si d quindi una serie di consigli relativi a quale usare, quando, e cos via. Teoricamente, in un processo di sviluppo andrebbero realizzati entrambi; nella pratica, per via di una serie di problemi relativi a tempo, budget, personale, ecc. normale trascurarne uno per concentrasi sullaltro. Il passo successivo consiste nel presentare il modello a oggetti di analisi (Analysis Model). Anche per questo modello viene presentata una tecnica utile per la sua realizzazione, una serie di consigli, nonch i vari tranelli in cui si pu correre il rischio di imbattersi. Nei progetti reali non sempre possibile realizzare il modello di analisi, per via dei soliti problemi (mancanza di tempo, personale, ecc.), pertanto si fornisce una serie di consigli su come ridurre il rischio generato dalla mancata realizzazione, su quando sia possibile trascurarlo, su quando invece opportuno realizzarlo, ecc. Prima di proseguire nella presentazione del modello successivo, viene presentato un formalismo di importanza storica per il processo di realizzazione dei vari modelli a oggetti che tuttora conserva delle aree di applicazioni, ossia il metodo delle CRC cards.


9

Lultimo modello a oggetti presentato, probabilmente il pi noto, quello di disegno (Design Object Model). Di questo dovrebbero esistere almeno due versioni: quello di specifica e quello di implementazione. Il primo dovrebbe essere realizzato prima dellinizio della codifica, mentre il secondo il risultato dellevoluzione che il disegno subisce durante limplementazione (variazioni in corso dopera). Come al solito si riportano immancabili esempi, consigli su come realizzarlo ecc. Il capitolo si conclude cercando di rispondere alla fatidica domanda: Quando un modello a oggetti di disegno si pu considerare ben costruito?.

Capitolo 9 I diagrammi di interazioneLe parti che costituiscono un qualsivoglia sistema non sono assemblate per persistere semplicemente in una posizione stabile, bens interagiscono tra loro scambiandosi messaggi al fine di raggiungere uno scopo ben preciso. Pertanto la descrizione di ogni comportamento necessita di essere modellata sia attraverso una prospettiva che mostri la struttura statica degli elementi cooperanti, sia mediante unaltra che illustri il relativo comportamento dinamico. Obiettivo del presente capitolo e di quello successivo illustrare i formalismi forniti dallo UML per modellare comportamenti dinamici. In particolare nel capitolo nono lattenzione focalizzata sui diagrammi di interazione (interaction diagram). Con questo nome si indicano i diagrammi di sequenza (sequence diagram) e quelli di collaborazione (collaboration diagram). Quantunque permettano di mostrare lo stesso contenuto informativo, si diversificano per laspetto dellinterazione cui attribuita maggiore importanza: i diagrammi di sequenza enfatizzano lo scambio dei messaggi nel tempo, mentre i diagrammi di collaborazione attribuiscono maggiore importanza allorganizzazione degli oggetti coinvolti nellinterazione modellata. Lutilizzo di questi diagrammi comprende quasi tutte le fasi dei processi di sviluppo del software: si va dallanalisi dei requisiti in cui possono essere utilizzati per illustrare gli scenari dei casi duso (soprattutto i diagrammi di sequenza), alla fase di analisi e disegno in cui mostrano le dinamiche interne del sistema. Si tratta di diagrammi ampiamente utilizzati nei capitoli precedenti e che, nel capitolo nono, trovano unillustrazione completa. Di questi due diagrammi presentato in modo approfondito il formalismo, consigli su come e quando utilizzarli, ecc. Il tutto sempre coadiuvato da un consistente insieme di esempi nonch dalle sezioni dedicate ai consigli relativi allo stile.

Capitolo 10 Le attivit di statoIn questo capitolo viene conclusa lillustrazione dei diagrammi dello UML destinati a modellare comportamenti dinamici. In particolare sono illustrati i diagrammi degli stati (state chart diagram) e quelli di attivit (activity diagram). Anche in questo caso si tratta di

10

Introduzione

diagrammi ampiamente utilizzati nel corso dei capitoli precedenti che per nel capitolo decimo sono affrontati in maniera organica. I diagrammi degli stati descrivono il ciclo di vita di automi a stati finiti. Pi precisamente, possibili sequenze di stati e azioni attraverso le quali istanze di opportuni elementi possono procedere durante il relativo ciclo di vita. Tale evoluzione leffetto delle reazioni innescate in tali istanze al verificarsi di opportuni eventi discreti. I diagrammi di attivit (discendenti dei celebri diagrammi di flusso, flowchart diagram) sono una variante di quelli degli stati, ove gli stati rappresentano lesecuzione di azioni o sottoattivit e le transizioni sono innescate dal completamento di tali azioni o sottoattivit. Questi diagrammi possono prevedere un considerevole utilizzo nelle fasi di analisi dei requisiti, che, tipicamente, si affievolisce nelle restanti fasi del processo di sviluppo del software. I diagrammi delle attivit trovano grande applicazione nella fase di analisi dei requisiti dove sono impiegati per mostrare gli scenari dei casi duso. Nelle restanti fasi tendono a essere utilizzati qualora vi sia la necessit di mostrare comportamenti concorrenti e la precisa allocazione delle responsabilit. Sempre i diagrammi delle attivit recitano un ruolo di primissima importanza ogniqualvolta sia necessario illustrare graficamente processi e sottoprocessi. I diagrammi degli stati sono utilizzati indistintamente in tutte le fasi del processo di sviluppo del software qualora vi sia la necessit di illustrare il ciclo di vita di oggetti (anche composti) che possono evolvere attraverso un insieme finito di stati. Di questi due diagrammi illustrato approfonditamente il formalismo, consigli su come e quando utilizzarli, ecc. Il tutto sempre coadiuvato da un consistente insieme di esempi nonch dalle sezioni dedicate ai consigli relativi allo stile grafico.

Capitolo 11 Anche gli aspetti fisici sono importantiIl libro si conclude con la presentazione dei diagrammi forniti dallo UML per modellare aspetti fisici del sistema: ossia i diagrammi di implementazione (implementation diagram). Con questo termine ci si riferisce ai diagrammi dei componenti (component diagram) e a quelli di dispiegamento (deployment diagram). I diagrammi dei componenti mostrano appunto la struttura dei componenti di cui composto il sistema, inclusi gli elementi che li specificano (classificatori) e i manufatti che li implementano. I diagrammi di dispiegamento mostrano la struttura dei nodi che costituiscono larchitettura fisica del sistema e nei quali vengono installati i componenti. Questi diagrammi si prestano anche a utilizzi pi estesi. Nella modellazione dellarea business, per esempio, i componenti mostrano procedure di business e manufatti, mentre i nodi rappresentano organizzazioni e risorse del business. Sebbene costituiscano il modello fisico, la loro produzione inizia gi dalle primissime fasi dellanalisi dei requisiti, poich considerazioni di carattere architetturale forniscono importantissimi feedback allo studio di fattibilit dei requisiti.


11

Di questi diagrammi, in particolare di quello dei componenti, sono mostrate importanti lacune evidenziate (quasi completamente riassorbite dalla versione 2 di UML), illustrato ampiamente il formalismo, sono forniti consigli su come e quando utilizzarli, un consistente insieme di esempi, vengono proposte indicazioni relative allo stile grafico, ecc.

Appendice A UML e i linguaggi di programmazione non OOSebbene UML sia un linguaggio di modellazione ideato per la progettazione di sistemi OO e component-based, si presta a essere utilizzato per la produzione di sistemi che prevedano linguaggi di programmazione non basati su tali paradigmi. Ci vero per utilizzando opportune cautele. NellAppendice A sono illustrati utili criteri, idee e problematiche relative allutilizzo dello UML con linguaggi di programmazione non OO.

Appendice B UML e la modellazione di basi di dati non OOObiettivo dellappendice B illustrare una sorta di profilo utilizzabile per modellare basi di dati fondati su paradigmi non OO. In particolare lattenzione focalizzata sulle basi di dati relazionali, sebbene i concetti esposti si prestino a essere estesi anche a basi di dati fondati su diversi paradigmi.

Appendice C Il profilo EJBLappendice C dedicata ad una breve illustrazione di un profilo (non standard) utilizzabile per la modellazione di sistemi component based fondati sullarchitettura Sun EJB. Brevemente, un profilo una particolare estensione dello UML, o meglio una collezione di estensioni predefinite, le quali nascono dallesigenza di standardizzare lutilizzo dello UML per domini o scopi o tecnologie ampiamente diffuse.

Appendice D GlossarioUn utile glossario di riferimento costituisce lAppendice D.

Appendice E Bibliografia ragionataUn elenco di libri, riviste e siti web di riferimento.

RingraziamentiCome ogni libro che si rispetti anche qui presente limmancabile e doverosa sezione dedicata ai ringraziamenti. In primo luogo la personale riconoscenza dellautore va al fantastico team che lo ha assistito e coadiuvato durante tutto il ciclo di sviluppo del libro. In particolare si ringraziano gli amici Roberto Virgili, (www.RobertoVirgili.com, team leader architetto nonch sviluppatore di sistemi distribuiti, vero e proprio formatore di menti il quale, tra laltro, ha sostenuto per primo lidea del libro: i lettori sanno quindi a chi rivolgersi per le eventuali ritorsioni), e ad Antonio Rotondi (Antonio.Rotondi @Artech.freeserve.co.uk, team leader, architetto di sistemi distribuiti e infrastrutture di sicurezza che negli ultimi anni ha lavorato intensamente allo sviluppo di sistemi per la gestione di smart card). Si tratta di due tecnici informatici di profonda levatura ed esperienza, veri e propri profeti dellarte di realizzare sistemi informatici che funzionano. Ringraziamenti aggiuntivi spettano a Gianluca Pignalberi, (Gianluca.Pignalberi @caspur.it, attualmente applicativo presso il CASPUR, Consorzio Interuniversitario per le Applicazioni di Supercalcolo Per Universit e Ricerca, esperto di metodi di Intelligenza Artificiale applicati allelaborazione delle immagini e di Linguistica Computazionale) sempre prodigo di consigli e preziosi suggerimenti, specie relativi alla sfera delle strutture dati e dei linguaggi formali. Un particolare ringraziamento va poi a Francesco Saliola che ha curato la redazione e limpaginazione del libro. Ulteriori ringraziamenti spettano a Giovanni Puliti (Java enthusiast, esperto di Java e tecnologie annesse, scrittore, articolista e direttore della rivista web www.MokaByte.it) e a Claudio Bergamini (amministratore di profonda conoscenza tecnica e rara lungimiranza., www.imolainfo.it) che hanno creduto nel libro e si sono adoperati proficuamente affinch il progetto potesse vedere la luce di Internet. Altri ringraziamenti doverosi spettano ai familiari dellautore e a tutti i veri amici, presenti nei tanti momenti di bisogno. La profonda riconoscenza e il ringraziamento dellautore spettano poi a tutti coloro che accoglieranno linvito di leggere il libro e a fornire le proprie riflessioni, al fine di arricchire il presente lavoro rendendolo sempre pi vicino alle tipiche esigenze dei progetti reali. Dulcis in fundo forse un ringraziamento particolare, molto particolare, va ai sedicenti tecnici, i vari gatto e volpe onnipresenti in tutte le organizzazioni. A tutti coloro che, chiusi nella loro arroganza, si sentono perpetuamente pi furbi, patrigni dispensatori di consigli sempre troppo gratuiti. Agli adepti delle ditte a conduzione familiare, che obbligano giovani professionisti a combattere contro muri di gomma, a lavorare sempre di pi e a dare costantemente il meglio di s fino alla nausea per dimostrare che la qualit non alberga esclusivamente nei libri di teoria Ammesso che queste persone siano in grado di capirla!


13

ScuseLe personali scuse dellautore vanno ai teorizzatori dellinformatica, agli autori dei vari testi sacri, e in primo luogo ai Tres Amigos. Il loro contributo alla semplificazione del processo di sviluppo dei sistemi informatici cos evidente da non richiedere assolutamente commenti. Si tratta di vere oasi di formazione intellettuale nel deserto degli Azzeccagarbugli, di fari che illuminano la rotta di tutti coloro per i quali linformatica una scienza Ci nonostante si ritenuto opportuno non prendersi troppo sul serio, permettendosi ironie anche nei confronti dei mostri sacri non solo nel senso etimologico del termine dellinformatica Daltronde i cimiteri sono gremiti di lapidi che declamano: Qui giace una persona insostituibile. Le scuse personali dellautore sono rivolte ai lettori pi attenti, se, talune volte, limpeto di voler illustrare concetti complessi nel modo pi semplice possibile possa aver travolto la trattazione erudita e portato a frasi fuorvianti. Ci nonostante si deciso si perseverare diabolicamente in tale direzione confidenti che quando il saggio indica la luna solo lo stolto fissa il dito. Le scuse finali sono relative alla voluminosit del libro Attualizzando una frase che Voltaire usava scrivere nelle lettere alla sua amica: vi porgo le mie scuse per la voluminosit della lettera, ma proprio non ho avuto tempo per scriverne una concisa.

Breve biografia dellautoreLuca Vetti Tagliati nato a Roma il 03/12/1972 (ottima annata per il vino). Ha da sempre studiato IT: quando allasilo bucava i fogli di carta con la matita, manifestava i primi sintomi da programmatore di schede perforate. Ha iniziato a lavorare professionalmente nel 1991 occupandosi di sistemi firmware ed assembler per microprocessori della famiglia iAPXx286. Nel 1994/95 ha intrapreso il lungo cammino nel mondo Object Oriented grazie al meraviglioso linguaggio C++. Nel 1996 si trovato catapultato nel mondo Java. Negli ultimi anni ha applicato la progettazione/programmazione Component Based in settori che variano dal mondo delle smart cards (collaborazione con la Datacard, www.datacard.com) a quello del trading bancario (www.hsbc.com). Attualmente lavora come consulente presso la sede londinese della banca HSBC con funzioni di chief designer, team leader e membro del gruppo PEG (Processing Engineering Group) istituito per stabilire un processo di sviluppo standard da applicarsi per lo sviluppo di sistemi software. Il PEG si avvale della collaborazione di persone del calibro di John Daniels ([BIB15]) e Frank Armour ([BIB14]). rintracciabile per ingiurie ed eventuali apprezzamenti presso lindirizzo [email protected].

14

Introduzione

Convenzioni graficheIl carattere senza grazie, accoppiato a unopportuna icona, utilizzato per evidenziare parti di testo meritevoli di particolare attenzione oppure dedicati esclusivamente a un pubblico esperto.

Il carattere piccolo indica parti di testo che riportano considerazioni non fondamentali: nonostante le informazioni contenute in tali parti di testo possano risultare interessanti per alcuni lettori, si tratta di nozioni che non sono indispensabili e che possono essere tranquillamente tralasciate senza pregiudicare la comprensione del testo restante.

Licona della lampadina, congiuntamente al carattere senza grazie viene utilizzata per mettere in luce un determinato concetto chiave, un consiglio pratico o un altro argomento che meriti particolare attenzione.

Licona del pericolo generico viene utilizzata per evidenziare sezioni, parti o paragrafi aventi una difficolt intrinseca elevata e dedicati a un pubblico esperto. Si tratta comunque di paragrafi completamente opzionali la cui lettura e comprensione non assolutamente indispensabile per lapprendimento di quanto riportato nei paragrafi e capitoli successivi. Ad ogni modo, non scarseggiano mai ampie descrizioni testuali atte a rendere accessibili a tutti anche le trattazioni pi complesse.

Licona degli ingranaggi stata utilizzata per evidenziare sezioni, parti o paragrafi dedicati ai processi di sviluppo del software. Tutti coloro allettati unicamente dal linguaggio dello UML e quindi interessati fino ad un certo punto ai processi di sviluppo, possono tranquillamente disinteressarsi di questi paragrafi.

Licona della tavolozza dei colori evidenzia paragrafi contenenti linee guida per il miglioramento delleleganza e della comprensibilit dei diagrammi. Lobiettivo pertanto migliorare lo stile senza entrare nel merito della semantica in altre parole si focalizza lattenzione sullo strato di presentazione sebbene poi le due caratteristiche non possano essere trattate in maniera completamente disgiunta.

Capitolo

1Beati monoculi in regno caecorum

UML: che cosa , che cosa non IntroduzioneObiettivo del presente capitolo fornire una panoramica generale sullo UML: il capitolo pertanto risulta essere decisamente corposo, quasi onnicomprensivo e non sempre di facile comprensione. Il fattore positivo che si pu procedere tranquillamente nella lettura del testo pur non comprendendo appieno quanto riportato. Il consiglio per tutti coloro che si accostano allo UML per la prima volta di leggerlo comunque, magari molto rapidamente, una prima volta, con lintento di tornare a rileggerlo in un secondo momento, quando si sar in possesso di una maggiore familiarit con il linguaggio stesso. Allora si potranno apprezzare maggiormente gli argomenti illustrati e si potr comprendere pienamente il rapporto che intercorre tra lo UML e le tecnologie correlate. Lobiettivo del capitolo chiarire sin da subito, e in modo inequivocabile, che cosa sia e che cosa non sia lo UML e, quindi, quali siano le relative aree di competenza e gli obiettivi. A tal fine vengono presentate anche altre tecnologie strettamente correlate con lo UML, nella convinzione che ci, aiutando a definire pi distintamente i confini dello UML, concorra a fornire una visione pi completa e precisa dello stesso. Si ritenuto altres utile fornire un conciso quadro storico della situazione presente prima e durante levoluzione dello UML, al fine di evidenziare le motivazioni teoriche che hanno spinto i cosiddetti Tres Amigos (Grady Booch, James Rumbaugh, Ivar Jacobson) ad affrontare il superbo progetto del linguaggio unificato. Sebbene sia opinione comune di molti tecnici che lo UML rappresenti semplicemente una notazione standard per la creazione di modelli Object Oriented di sistemi, in realt molto di pi. Esso possiede una definizione rigorosa di metamodello, istanza del meta-metamodello noto con la sigla MOF (Model-Object Facility). Si tratta di concetti

2

Capitolo 1. UML: che cosa

, che cosa non

molto eleganti e affascinanti, a elevato livello di astrazione (la relativa descrizione riportata nellapposita appendice). Tali concetti meriterebbero, in effetti, una trattazione pi rigorosa (le specifiche ufficiali constano di oltre 500 pagine) rispetto a quella riportata, ma ovviamente e fortunatamente ci esula dagli obiettivi del presente libro. Il problema che si pone a questo punto che il metamodello dello UML descritto per mezzo dello UML stesso: unistanza che definisce la classe (ci rievoca il ricordo del compilatore del linguaggio C scritto in linguaggio C). Si tratta indubbiamente di una scelta molto elegante, ma che, come incoveniente, pu creare seri problemi a tutti coloro che affrontano lo UML per la prima volta: come andare a lezione di Inglese senza conoscerne una parola e assistere a spiegazioni esclusivamente in lingua impartite da un insegnante di madrelingua che non faccia altro che parlare e parlare. La trattazione pi approfondita riportata nellappendice A: stata inserita in questo contesto solo al fine di rendere i lettori consapevoli delle specifiche formali, nonostante la relativa illustrazione venga ripresa e argomentata nel corso di tutto il libro. Se i vari concetti dovessero risultare troppo enigmatici non c da preoccuparsi pi di tanto: si pu utilizzare tranquillamente lo UML senza averne capito il metamodello (si pu tranquillamente progammare in C senza sapere come sia stato realizzato il relativo compilatore). I paragrafi successivi a quelli relativi al metamodello sono dedicati alla trattazione dei metodi di sviluppo (i famosi processi) sia da un punto di vista generale illustrazione delle principali dottrine (Use case Driven, Architecture Centric e Iterative and Incremental) , sia da un punto di vista particolare presentazione dei processi pi diffusi (The Unified Software Development Process, frutto del lavoro dei Tres Amigos, Use case Driven Object Modeling with UML, OPEN Process patrocinato dallOPEN Consultorium e Object-Orient Software Process). Per questioni di completezza viene fornita una brevissima introduzione delleXtreme Programming (XP) con tutte le relative perplessit generate e la relativa evoluzione fornita dalleXtreme Modelling o Agile Modeling, in cui, fortunatamente, lattenzione viene nuovamente spostata sulla fase di modellazione. Il capitolo termina con limmancabile parte dedicata ai tool disponibili in commercio, con una brevissima illustrazione, quanto pi oggettiva possibile, dei relativi pregi e difetti.

La modellazioneOgni qualvolta, in una disciplina dellingegneria, vi sia la necessit di realizzare un manufatto, indipendentemente dalla dimensione e dal settore di interesse (una casa, un grattacielo, un particolare meccanismo, un ponte, un dipartimento di unazienda, e cos via) si procede cercando di realizzarne un modello. Lobiettivo produrre, in tempi relativamente brevi e soprattutto a costi contenuti, una versione razionalizzata e semplificata del sistema reale che, tuttavia, consenta di evidenziarne laspetto finale e di studiarne prestazioni, affidabilit, comportamento, ecc

UML dalla teoria alla pratica

3

I modelli, importantissimi in tutti i processi di sviluppo, trovano la loro pi completa legittimazione nellambito di sistemi di dimensioni medie e grandi. In tali circostanze la complessit di questi sistemi nella loro interezza ne rende molto difficoltosa la comprensione. quindi maggiormente avvertita la necessit di avvalersi di modelli in grado di descrivere, in maniera semplificata, sistemi comunque complessi. Si vedr come lo UML, grazie alla sua organizzazione in viste (Views), risponda alla logica necessit della mente umana di concentrarsi, in ogni istante, su un numero limitato di aspetti del sistema ritenuti importanti per la particolare fase del processo di sviluppo, rimandando a momenti successivi lanalisi degli aspetti rilevanti per le altre viste. Oltre ai motivi gi citati, i modelli sono basilari poich, avvalendosi anche del feedback fornito dai committenti, permettono di definire i requisiti del sistema in maniera chiara e, con la cooperazione del proprio gruppo, di razionalizzarne il processo di sviluppo. I vantaggi che se ne ricavano sono diversi: adeguate analisi dei tempi, migliori stime dei costi, piani pi precisi di allocazione delle risorse, distribuzioni pi affidabili del carico di lavoro, e cos via. Si riesce quindi a risparmiare tempo e denaro, a ridurre i fattori di rischio presenti in ogni progetto, a studiare la risposta del sistema a particolari sollecitazioni, e via di seguito. Nonostante il grande valore apportato allingengeria del software dallutilizzo della modellazione, troppo spesso in molte organizzazioni, questa meravigliosa tecnica rimane ancora una chimera. A nessuno appartenente al settore dellingegneria edile verrebbe in mente di costruire interamente un grattacielo, per poi studiarne la risposta a sollecitazioni di carattere sismico. Il buon senso risorsa purtroppo sempre rara suggerisce di procedere con la realizzazione di una versione miniaturizzata sulla quale condurre tutti gli studi del caso. Non necessariamente un processo di modellazione genera un oggetto tangibile: talvolta si tenta di rappresentare un complesso reale per mezzo di eleganti sistemi di disequazioni e quindi lintero modello si risolve in una raffinata astrazione. Tutto ci che fin troppo scontato in molte discipline dellingegneria non lo nel settore dellinformatica. In molte organizzazioni e qui non si pensi a un limite riscontrabile solo nelle piccole realt la produzione del software ancora unattivit, per cos dire, artigianale in cui il relativo processo di sviluppo del software prevede tre fasi: analisi dei requisiti, implementazione e test Forse. Si provi a immaginare che cosa potrebbe accadere se si avviasse la progettazione di un ponte a partire da specifiche sommarie, magari comunicate verbalmente o, peggio ancora, se si partisse subito a costruirlo materialmente, magari affidandosi allesperienza di qualche costruttore. Inconcepibile eh? Tutto ci, bench possa sembrare fuori dal mondo, molto spesso prassi comune nel mondo dellingengeria informatica. Malgrado siano stati versati fiumi dinchiostro sullargomento, e svariati gruppi di ricerca lavorino a tempo pieno per la definizione di nuovi standard di analisi, in molte organizzazioni, soprattutto italiane, anche di comprovato prestigio, tale attivit ancora considerata prettamente accademica, vezzo di giovani neolaureati perch, in ultima analisi, di

4


, che cosa non

scarsa utilit nel mondo reale, dove lobiettivo produrre codice e lesperienza in grado di sopperire a tutto. Linevitabile risultato che spesso si procede cominciando paradossalmente da una delle ultime fasi del processo di ingegnerizzazione del software, ossia dalla stesura del codice (paragonabile alla costruzione del ponte di cui si parlava nellesempio). Si inizia concentrandosi prematuramente sul modo in cui redigere il codice ed, eventualmente, alla fine si scrivono due righe di analisi, magari demandando il tedioso incarico allultimo arrivato nel team, al baldo giovane di turno. I rischi che si corrono sono noti a tutti e possono generare delle veniali anomalie note in letteratura informatica come crisi del software. In molte occasioni lautore potrebbe citarne diverse, ma preferirebbe evitare vitto e alloggio a carico dello Stato pu accadere che, a progetto ultimato e pronto per la consegna, ci si accorga dellerrata architettura. Non da escludere, nel peggiore dei casi, che, per via di uno sviluppo interamente incentrato sulla fase di codifica, e quindi privo della visione globale che solo un buon processo di modellazione pu apportare, sia praticamente impossibile integrare i moduli prodotti in parallelo o che sia necessario costruire estemporanei moduli di interfacciamento o, ancora, che il sistema preveda percorsi cos tortuosi da renderlo praticamente inutilizzabile. Lunico vantaggio, in questo modo di procedere che si placano, almeno sul momento, gli stati dansia di taluni manager, i quali diventano improvvisamente irrequieti quando il team non genera codice, anche se nel frattempo si stanno affrontando delicate e impegnative fasi di analisi e/o disegno. Lalibi che viene rispolverato lo scarso tempo a disposizione, dimenticando quanto incida il processo di manutenzione sullintero ciclo di vita del software: il famoso risparmio della massaia. A onor del vero, gli eventuali fallimenti non sono sempre imputabili a tecnici/commerciali che vendono limpossibile, di manager informaticamente poco lungimiranti o di capi-progetto invisibili (detti in gergo ghost) che un giorno sono a favore di una soluzione e il giorno dopo di quella opposta Maschere e pugnali! Molto spesso qui doveroso procedere con un po di sana autocritica gli stessi progettisti si sentono pi a loro agio quando si deve affrontare un problema di programmazione, piuttosto che quando si deve affrontare la modellazione di un sistema. Probabilmente non suoner nuova la frase Che noia! Non ne posso pi! Ma quando si comincia a scrivere del codice?. Probabilmente si tratta anche delleredit di una dannosa abitudine: allinizio i sistemi non erano cos complessi, le metodologie di progettazione erano quasi inesistenti, i problemi e gli imprevisti dellimplementazione erano di quantit e entit tutto sommato limitate, tali da rendere quasi giustificabile la contrazione del processo di modellazione. Eppure da allora alcune cose dovrebbero essere cambiate E pensare che, da oltre un decennio, in ambito accademico si afferma che la programmazione un incidente anche molto piacevole se si vuole dellinformatica.


5

Figura 1.1 La vignetta dellaltalenaQuello che voleva l'utente... Quello che ha capito il business analyst... Quello che ha progettato l'architetto...

Quello che hanno realizzato i programmatori...

Come hanno installato gli installatori...

Quello di cui aveva realmente bisogno l'utente...

Nella realt, troppo spesso si liquidano prematuramente le fasi di analisi e disegno del software per tuffarsi a testa bassa nella programmazione. Come nella celebre vignetta dellaltalena, tutti sono felici e contenti, almeno fino al momento di appenderla al ramo dellalbero. La temporanea soddisfazione viene vinta dalla triste constatazione che, a causa del modo superficiale in cui si operato, necessario operare un taglio ortogonale alla base del tronco dellalbero per poter ospitare il seggiolino. In altre realt, pu succedere di realizzare unanalisi adeguata, di produrre modelli sofisticati ad elevato livello di astrazione da fornire al team di sviluppatori object disoriented. Una situazione del genere potrebbe ingenerare qualche problema, magari per spiegare che con la frase loverloading dei metodi non si intende sovraccaricare il processo di sviluppo di metodologie.

6


, che cosa non

Questo per evidenziare che gli strumenti da utilizzare in fase di analisi, purtroppo, possono anche dipendere, in gran misura, dal team con cui si lavora. Provate a fornire, sempre allo stesso team di cui sopra, un class diagram (diagramma delle classi) Non si otterranno grossi risultati, neanche con lesempio dellentomologo (qualcuno ricorda la catalogazione degli insetti un tempo tanto cara a taluni manuali?). Premesso ci, va comunque ribadito che il processo di analisi e modellazione unattivit estremamente creativa, strettamente dipendente dalle capacit, dalla cultura e dallesperienza dei singoli: insomma un vero e proprio bene soggettivo. Il bello si fa per dire che non esiste un manuale delle soluzioni corrette con il quale confrontarsi alla fine del proprio studio: solo il tempo fornir i verdetti. A tutti coloro per i quali tale introduzione, e in generale la domanda why do we model?, pi che scontata, felicitazioni di cuore! Significa che si trovano a lavorare presso la APBDM (leggasi Azienda Pi Bella Del Mondo). Purtroppo le realt lavorative non sono sempre cos, e la dice lunga il fatto che anche i fondatori dellUML abbiano deciso di dedicare allargomento un intero paragrafo sia del libro [BIB01], sia delle specifiche ufficiali dello UML. Per terminare, sintetizzando al massimo il concetto si pu dire che si modella essenzialmente per due motivi: aumentare la propria comprensione sia di un problema sia di eventuali soluzioni ipotizzate; comunicare.

Qualit di un modelloIllustrato il concetto di modello cui si ricorrer ampiamente in tutto il libro si ritiene opportuno evidenziarne brevemente le qualit peculiari utili nel contesto dello sviluppo di sistemi software. Le propriet che deve possedere un modello dovrebbero essere tenute a mente e guidare la fase di progettazione del sistema, al fine di produrne versioni di migliore qualit. Un modello dovrebbe essere: accurato: deve descrivere il sistema correttamente, completamente e senza ambiguit; consistente: le diverse viste devono completarsi vicendevolmente per formare un insieme coerente (la completezza di unerma bifronte); semplice: deve poter essere compreso, senza troppi problemi, da persone estranee al processo di modellazione;


7

manutenibile: la variazione dello stesso deve essere la pi semplice possibile.

Nascita e sviluppo di UMLLa babele dei metodiUno degli obiettivi che hanno caratterizzato il lavoro dei Tres Amigos stato realizzare un linguaggio di modellazione che unificasse e incorporasse le caratteristiche migliori dei linguaggi esistenti intorno agli anni Novanta. In particolare, come citato esplicitamente nel documento delle specifiche [BIB07], lo UML scaturito principalmente dalla fusione dei concetti presenti nei metodi di Grady Booch, OMT (Object Modeling Technique di cui Rumbaugh era uno dei principali fautori) e OOSE (Object Oriented Software Engineering /Objectory di cui Ivar Jacobson era uno dei pi importanti promotori). Agli inizi degli anni Novanta, ossia poco prima dellavvio dei lavori per lo UML, i suddetti metodi erano probabilmente quelli pi apprezzati, a livello mondiale, dalla comunit Object Oriented. Brevemente, il metodo di Booch, diventato famoso nel settore con il nome di metodo delle nuvolette, definisce una notazione in cui il sistema viene analizzato e suddiviso in un insieme di viste, ciascuna costituita dai diagrammi di modello. Il metodo non si limita a un linguaggio di modellazione, ma contiene anche un processo, in base al quale, il sistema viene studiato attraverso micro- e macroviste di sviluppo, secondo un classico schema incrementale e iterativo. Il metodo di Booch, a detta degli esperti, sembrerebbe molto efficace soprattutto in fase di disegno e di codifica, mentre presenterebbe qualche lacuna nelle varie fasi di analisi. LOMT un linguaggio di modellazione, sviluppato presso la General Electric, rilevatosi particolarmente efficace nella fase di esplorazione dei requisiti. In maniera speculare al metodo precedente, questultimo sembrerebbe essere carente nella fase della formulazione delle soluzioni, mentre risulterebbe particolarmente accurato nellesplorazione delle specifiche nel dominio del problema. LOMT prevede che il sistema venga descritto attraverso un preciso numero di modelli che si completano vicendevolmente. Grazie alla sua accuratezza nella fase di analisi dei requisiti, il modello fornisce un valido ausilio anche alla fase di test di sistema. Infine i metodi OOSE e Objectory (in gran parte dovuti al lavoro di Jacobson) si basano, quasi interamente, sugli Use Case (casi duso). Poich gli Use Case permettono di definire i requisiti iniziali del sistema cos come vengono percepiti da un attore esterno allo stesso, i metodi OOSE e Objectory si sono dimostrati particolarmente efficaci nello spazio dellanalisi nel dominio del problema. Anche questi metodi forniscono una serie di informazioni e linee guida su come passare dallanalisi dei requisiti al disegno del sistema. Altri metodi degni di essere menzionati sono Fusion (elaborato presso i laboratori della Hewlett-Packard) e il metodo Coad/Yourdon (noto anche come OOA/OOD Object

8


, che cosa non

Oriented Analisys / Object Oriented Design) che vanta il primato di essere stato uno dei primi metodi di analisi e disegno di sistemi Object Oriented. Negli anni intercorsi tra il 1989 ed il 1994, oltre ai metodi appena citati, considerati tra i pi importanti, se ne contarono addirittura una cinquantina. Questi andarono ad alimentare quella che fu definita guerra dei metodi: la famosa Babele tra i modelli software con la conseguente incomunicabilit. Ovviamente ciascuno di questi presentava punti di forza, lacune, un proprio formalismo, una nomenclatura proprietaria e un peculiare processo di sviluppo. Tutto ci finiva per minare alla base lo sviluppo di processi di progettazione pi accurati e rendeva difficoltosa la realizzazione di opportuni tool di supporto. Altri inconvenienti, sempre frutto dellincomunicabilit dei metodi, erano legati allimpossibilit di far circolare informazioni tra team di aziende diverse, alla difficolt di rendere rapidamente produttive nuove risorse allocate al progetto e cos via. In ultima analisi si finiva per fornire un pretesto ai vari team analisi-disegno repellenti.

Le motivazioniIl presente libro viene pubblicato dopo pi di sette anni da quando Grady Booch e James Rumbaugh iniziarono i lavori alla Rational Software Corporation (1994). Probabilmente si trattato della tecnologia giusta al momento giusto (ci potrebbe far impallidire anche il buon Murphy), visto il grande successo riscosso e le prestigiose collaborazioni che hanno contributo alla sua realizzazione. Tra i partner si contano alcune delle aziende pi importanti nel settore della Computer Science, tra le quali IBM, Oracle, Microsoft, Sun Microsystem, Texas Instruments, MCI Systemhouse, Hewlett-Packard, e cos via. Il clamoroso successo riscosso molto probabilmente dovuto alla necessit, avvertita da tutta la comunit Object Oriented, di disporre di un unico linguaggio di modellazione che mettesse finalmente termine alla proliferazione degli anni precedenti. La guerra dei metodi ha finito per costituire un serio limite allevoluzione di una rigorosa metodologia di sviluppo del software. Le aziende che producevano tool di supporto al processo di sviluppo del software, i famosi CASE (Computer Aided Software Engineering), avevano notevoli problemi nello scommettere, sul linguaggio da adottare. Si trattava di affidare la politica di sviluppo dellazienda al successo di un metodo: vera e propria roulette russa. Lidea di produrre plug-in per il supporto degli altri linguaggi risultava uno sforzo troppo impegnativo e costoso, vista la significativa disomogeneit degli stessi. Dal canto loro le aziende di Information Tecnhnology non riuscivano a orientarsi bene nello scegliere un metodo da utilizzare come standard interno. Linvestimento per la produzione di processi proprietari e per laddestramento del personale risultava cos elevato, che lo spettro di una scelta sbagliata rendeva di fatto molto difficile qualsiasi decisione e quindi finiva per produrre una certa immobilit. Le grandi aziende finivano per crearsi un proprio processo proprietario, basato sul bagaglio delle esperienze accumulate, e quindi


9

assolutamente non supportato. Nelle imprese medio-piccole, molto spesso, tutto era demandato alla capacit e alla saggezza dei singoli architetti. Il risultato era una totale incomunicabilit tra i vari team di sviluppo e una discrepanza di metodi presenti in progetti sviluppati in tempi diversi e sotto la direzione di persone diverse. La confusione imperante generava diversi problemi anche ai singoli tecnici, desiderosi di utilizzare un linguaggio di modellazione che agevolasse il lavoro di tutti i giorni e che fosse supportato da tool commerciali. Tali situazioni prepararono il terreno ideale alla sollecita accettazione del progetto di unificazione dei metodi. Non a caso, il progetto avviato alla Rational Software Comporation suscit limmediato consenso di tutta la comunit OO. Altro fattore non trascurabile che i fautori (i Tres Amigos) del progetto dello UML erano padri dei metodi pi conosciuti ed utilizzati. Chiaramente laccettazione e il supporto del progetto da parte di altri metodologi non coinvolti nel lavoro fu tuttaltro che scontato: ma questo un altro discorso. Se a tutto ci si aggiunge il fatto che il linguaggio nonproprietario si pu ben capire che la sua affermazione era garantita sin dallinizio della sua invenzione. Si tratta infatti di un linguaggio completamente aperto, tanto che le aziende sono incoraggiate a integrarlo nei propri metodi di sviluppo del software e che le imprese produttrici di CASE possono liberamente produrre software di supporto allo UML.

La genesiOriginariamente il lavoro fu iniziato dai Dos Amigos Grady Booch e James Rumbaugh, con lintento di produrre un nuovo metodo, detto metodo unificato che raccogliesse il meglio dei metodi Booch e OMT-2, del quale Rumbaugh era stato uno dei principali promotori. Nel 1995 si un a loro Ivar Jacobson, fautore del metodo denominato OOSE (Object Oriented Software Engineering): il terzetto si era cos costituito. Lazienda che promuove il progetto la Rational Software Corporation che, dal canto suo, provvede anche ad assorbire la Objective Systems, azienda svedese che aveva sviluppato e distribuito il software Objectory. A questo punto il quadro era completo e lo standard in lavorazione fu ribattezzato Unified Modeling Language. La prima versione, la celebre 1.0, fu disponibile nel gennaio 1997. Lo UML uno strumento di analisi molto versatile, nato per risolvere le problematiche connesse con la progettazione Object Oriented del software, ma che ben si adatta a essere utilizzato negli ambienti pi disparati. Esso stato, per esempio, utilizzato alla Cadence per la produzione di un dispositivo di compressione vocale operante a livello di porta fisica. Ancora, una delle aziende fornitrici della US Navy ha utilizzato lo UML come linguaggio di progettazione di un sistema darma di nuova generazione. Unazienda sanitaria si avvalsa dello UML nella realizzazione di un modello per il trattamento dei pazienti, e cos via. Visto lenorme successo riscosso nellapplicazione industriale e nel mondo accademico e considerato il relativo riconoscimento a livello di standard (UML 1.0 stato proposto

10


, che cosa non

Figura 1.2 Diagramma dei componenti dellevoluzione dello UML. Nel diagramma sono riportati due stereotipi, etichettati rispettivamente con i termini inglesi refine e document. Per ora basti sapere che uno stereotipo una specializzazione di un elemento standard UML. In particolare refine una versione della relazione di dipendenza il cui significato piuttosto intuitivo. In generale lasserzione che un oggetto B dipende da un oggetto A (visualizzata per mezzo di una freccia tratteggiata in direzione delloggetto A), indica che una variazione alloggetto indipendente (A) produce la necessit di revisionare ed eventualmente aggiornare loggetto dipendente (B). Lo stereotipo document rappresenta una particolare versione dellelemento package, che, in questa fase, pu essere considerato come un contenitore di oggetti. La similitudine con le cartelle del file system piuttosto immediata. Una directory (o cartella che dir si voglia) in grado di contenere eventuali altre cartelle e file delle pi svariate tipologie (audio, filmati, grafici, testo, e cos via).

2002 - 2004 (Pianificate revisioni significative)

document

UML 2.0refine

Q3 2001 (Pianificate minori revisioni)

document

UML 1.4refine

Q3 1999

document

UML 1.3refine

Q2 1998document

UML 1.2refine document

Nessuna modifica significativa

Q3 1997 OMG acquisice lo UML

UML 1.1

Unificazione dei precedenti modelli quali Booch, OMG, Objectory

allObject Managment Group nel gennaio 1997), gli stessi ideatori, i Tres Amigos, dichiararono ormai conclusa la loro esperienza in questo ambito tanto da dedicarsi a nuove sfide Allo stato attuale lo sviluppo dellUML affidato a una task force appartenente


11

allOMG, la famosa RTF (Revision Task Force per che fantasia), diretta da Chris Kobyrn. Obiettivo di tale gruppo accogliere e analizzare suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni (bugs), colmare eventuali lacune e cos via. Attualmente disponibile la versione 1.4 (risultato dellattivit della seconda RTF) e si sta lavorando, alla versioni 2.0 come mostrato nel paragrafo seguente. Levoluzione dello UML mostrata in fig. 1.2, attraverso il diagramma dei componenti, uno degli strumenti messi a disposizione dal linguaggio.

UML 2.0A questo punto viene da interrogarsi legittimamente su come stiano procedendo i lavori per la versione 2.0 (etichettata spaventosamente come major revision), che cosa sia lecito attendersi per i legami con la serie 1.x dello UML, e cos via. Figura 1.3 Decomposizione delle attivit dello UML 2.0 in sottogruppi. Le linee culminanti con un diamante rappresentano relazioni di composizione dette anche whole-part (tutto-parte). In particolare, nel contesto oggetto di studio, indicano che la versione UML 2.0 costituita dalla documentazione prodotta dalla RTF Infrastructure, Superstructure e OCL.

document

UML 2.0

document

UML 2.0 Superstructure

Pianificata per Q4 2002

document

document

UML 2.0 Infrastructure

UML 2.0 OCL

Pianificata per 2004

document

UML 1.4

12


, che cosa non

Molto probabilmente uno degli impegni pi importanti consiste nel proseguire nella direzione, gi intrapresa con la versione 1.4, dello studio delle necessit dei sistemi component-based. Ci al fine di adeguare sempre pi lo UML allo stato dellarte della tecnologia e quindi di fornire soluzioni concrete alle esigenze dei tecnici coinvolti nella realizzazione di sistemi basati sui componenti. Si consideri il diagramma riportato nella figura precedente. Come annunciato in precedenza dallo OMG, la RTF per la versione 2.0 stata suddivisa (questa volta ufficialmente) in tre parti.

Infrastruttura (Infrastructure RFP, OMG document ad/00-09-01)Come suggerisce il nome, obiettivo di questa RTF consiste nel curare miglioramenti relativi alla struttura base del metamodello UML, riguardanti il core, i meccanismi di estensione, le facility del linguaggio ecc. In particolare i relativi obiettivi sono di allineare larchitettura dello UML agli altri standard gestiti dallOMG (quali per esempio il MOF, Meta Object Facility, Meta-data Interchange XMI), ristrutturare il linguaggio al fine di renderlo pi comprensibile ed estenderlo mantenendo per la semantica e la notazione attuale. (Per ulteriori informazioni consultare lappendice A).

Superstruttura (Superstructure RFP, OMG document ad/00-09-02)Obiettivo di questa RTF elaborare proposte atte a incorporare le best practices in aree particolarmente sensibili, come lo sviluppo di sistemi basati sui componenti, i modelli architetturali, quelli eseguibili e dellarea business. In particolare necessario studiare ulteriormente le soluzioni per: la gestione degli eventi nei diagrammi delle attivit; migliorare lillustrazione dellincapsulamento con particolare riferimento ai diagrammi di stato e di sequenza; ridefinire la semantica di relazioni come la generalizzazione, associazione, ecc. il supporto dello sviluppo component-based di sistemi software; il supporto per architetture a tempo di esecuzione, favorendone la descrizione del comportamento dinamico e leventuale rappresentazione gerarchica.

Object Constraint Language (OMG document ad/00-09-03)Il nome di questa RTF evidenzia chiaramente quale sia la relativa area di competenza: lOCL. Gli obiettivi sono di presentare proposte atte ad aumentare il livello di specializzazione dellOCL per lutilizzo UML. Ci dovrebbe semplificare il lavoro degli utenti, favorendo laumento di formalit dei vari modelli prodotti.


13

Da diverso tempo in corso un dibattito allinterno dellOMG stesso, teso a investigare la necessit di introdurre unulteriore Task Force con lobiettivo di studiare larea relativa allo scambio di modelli UML prodotti da tool diversi. Il nome di tale gruppo dovrebbe essere Diagram Interchange RFP. Sebbene in tale direzione ci sia gi stato un impegno iniziale della seconda RTF, il relativo interesse stato focalizzato principalmente sulla semantica e non sulla problematica specifica dello scambio concreto di diagrammi. Come ben noto a tutti i tecnici informatici, laumento del parallelismo nello svolgimento di attivit presenta evidenti vantaggi riduzione dei tempi grazie al lavoro in parallelo, maggiore specificit delle tematiche affrontate, ecc. a fronte dei quali per, sono presenti tutta una serie di problematiche. In questo caso sono relative essenzialmente allincremento del lavoro necessario sia per lintegrazione delle proposte avanzate dai singoli gruppi, sia per il mantenimento della coerenza tra le varie parti costituenti le specifiche finali. Pertanto, ulteriore preoccupazione della RTF per la revisione 2.0 dello UML controllare lo sviluppo parallelo delle varie task force al fine di far s che le varie componenti lavorino nella stessa direzione e producano la major revision preservando la coerenza e le strutture delle precedenti versioni mostratesi particolarmente efficaci.

Obiettivi dello UMLVengono di seguito descritti gli obiettivi che i Tres Amigos si sono prefissi di raggiungere attraverso lo sviluppo dello UML. La relativa descrizione stata tratta direttamente dal documento ufficiale delle specifiche [BIB07]. Scopi principali dello UML sono: Fornire agli utenti un linguaggio di modellazione visuale pronto ad essere utilizzato per sviluppare e scambiare modelli espressivi. Chiaramente, risulta molto importante che un linguaggio di analisi e disegno Object Oriented standard (OA&D Object Analysis & Design) fornisca tutti i concetti necessari alla sua diretta utilizzazione nelle fondamentali attivit del processo di produzione di un modello software. Lo UML ha consolidato un insieme nucleare di concetti di modellazione, necessari in molte applicazioni reali, presenti in molti metodi di progrettazione e tool di modellazione disponibili sul mercato. Fornire meccanismi di estensione e specializzazione al fine di accrescere i concetti presenti nel nucleo. Uno dei punti fermi che ha guidato il lavoro dei Tres Amigos stato realizzare un linguaggio di modellazione quanto pi generale possibile, in modo da non relegarne lutilizzo a un dominio specifico. In prima analisi, si sarebbe potuto raggiungere tale obiettivo corredando lo UML di un numero di elementi molto elevato, in modo tale da fornire gli strumenti specificamente necessari a tutte le esigenze dei vari ambienti e delle varie architetture. Si sarebbe potuto, ad esem-

14


, che cosa non

pio, includere nello UML tutta una serie di elementi specifici per la modellazione di sistemi CORBA, EJB, ecc. Tutto ci per avrebbe sicuramente portato a un conflitto con unaltra esigenza, altrettanto importante di quella dellapplicazione dellUML in campi specifici: mantenere il linguaggio il pi semplice possibile, al fine di massimizzarne laccettazione da parte della comunit Object Oriented. La soluzione a queste esigenze contrastanti stato realizzare un nucleo del linguaggio basilare, valido per ogni ambiente, corredato da una serie di strumenti che consentano di aggiungere nuova semantica e sintassi al linguaggio stesso per utilizzi specifici dello UML. Il risultato che i concetti fondamentali del linguaggio vengono utilizzati cos come sono, senza ulteriori estensioni, per la maggior parte del sistema: vige, anche in questo contesto, la famosa legge empirica dell80/20: l80% del progetto utilizza il 20% dei concetti dello UML. Per quanto riguarda la restante parte e per progetti molto specifici possibile sia aggiungere nuovi concetti e notazioni, al fine di modellare opportunamente le aree non coperte dal nucleo dello UML, sia specializzare quelle gi esistenti per particolari domini dellapplicazione. Supportare specifiche che risultino indipendenti da un particolare linguaggio di programmazione o processo di sviluppo. Lo UML stato concepito con lobiettivo di supportare plausibilmente tutti i linguaggi di programmazione. Quindi stato reso idoneo allutilizzo nei pi svariati ambienti produttivi, che ricorrono a una vasta gamma di tecnologie, e inoltre si fatto in modo di preservare la sua adattabilit a sviluppi futuri. Chiaramente lo UML risulta particolarmente indirizzato a linguaggi di programmazione Object Oriented. Pertanto parte della sua efficacia viene attenuata da linguaggi che non realizzano tale paradigma. Come solitamente succede, molto dipende dallutilizzatore. Per esempio si pu programmare in C seguendo il paradigma Object Oriented, al limite aiutandosi con un sistema evoluto di macro (le prime versioni di compilatori C++ altro non erano che preprocessori del linguaggio C, C-front). Si altres cercato di rendere lo UML idoneo a essere utilizzato con molteplici metodi di sviluppo: pu essere proficuamente adoperato per esprimere i prodotti generati dalle varie fasi di cui ogni processo composto. Fornire le basi formali per comprendere il linguaggio di modellazione. Un linguaggio di modellazione deve necessariamente essere preciso e al contempo offrire una complessit contenuta. I formalismi non dovrebbero ricorrere allutilizzo di nozioni matematiche di basso livello e distanti dal dominio del modello. Tali insiemi di nozioni teoriche e di definizioni operative risulterebbero essere una forma diversa di programmazione e implementazione, non idonea a tutte le fasi del processo di sviluppo del software. Lo UML fornisce una definizione formale del del modello, utilizzando un metamodello espresso attraverso il diagramma delle classi dello stes-


15

so UML. Esso presenta pertanto un adeguato formalismo e una complessit molto contenuta. Incoraggiare la crescita del mercato dei tool Object Oriented. Lesistenza di un linguaggio di modellazione standard doveva e cos stato eliminare tutti quei problemi analizzati nel paragrafo dedicato alle motivazioni dello UML: difficolt per le aziende di selezionare standard da adottare, frustrazione da parte dei tecnici di fronte alla proliferazione dei metodi, difficolt di circolazione dei vari modelli prodotti, impedimenti per le aziende creatrici di CASE di individuare metodi da automatizzare, ecc. Pertanto, una volta rimossi i problemi alla base dello sviluppo formale dellOO, venne incrementata la crescita del mercato dei prodotti commerciali per il supporto dello UML. Si tratt di un vero e proprio toccasana per tutta la comunit Object Oriented. Supportare concetti di sviluppo di alto livello come componenti, collaborazioni, framework e pattern. Ulteriore obiettivo dello UML fu la chiara definizione dei concetti succitati poich ci essenziale per trarre i massimi benefici dal paradigma Object Oriented e in particolare da quello della riusabilit. Integrare le best practices. Unaltra motivazione alla base dello UML stata integrare le pratiche mostratesi vincenti nella realizzazione di progetti reali. Ci risultato particolarmente utile al fine di offrire sin da subito un linguaggio maturo che inglobasse il meglio delle tecniche di comprovata validit.

Che cosa lo UMLSecondo le specifiche [BIB07] lo Unified Modeling Language un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, sia di processi produttivi e altri sistemi non strettamente software. UML rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella modellazione di vasti e complessi sistemi. Lo UML permette di visualizzare, per mezzo di un formalismo rigoroso, manufatti dellingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni adottate. Tale linguaggio favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale non legato alle singole imprese. In teoria, un qualunque tecnico, di qualsivoglia nazionalit, dipendente della pi ignota delle software house, con un minimo di conoscenza dellUML dovrebbe essere in grado di leggere il modello del progetto e di comprenderne ogni dettaglio senza troppa fatica e, soprattutto, senza le ambiguit tipiche del linguaggio naturale. Come al solito qualche problema pu sempre emergere, ma si tratterebbe comunque di problemi di poca entit. Un conto non comprendere qualche

16


, che cosa non

dettaglio, un altro non comprendere assolutamente cosa voleva realizzare lautore; situazione tipica di alcuni progetti ribattezzati temini di scuola superiore: si tratta di documenti tipicamente corposi quando non si sicuri meglio scrivere tanto in cui il 99% del contenuto relativo alla descrizione, assolutamente non organica, di nozioni teoriche copiate da appositi libri e il restante 1% a embrioni di soluzioni. I vantaggi che derivano dal poter disporre di un modello del sistema sono notevoli e fin troppo evidenti. Basti pensare alla non indifferente semplificazione del processo di manutenzione che, da solo, tipicamente incide pi del 50% nel ciclo di vita dei sistemi software ben progettati; alla possibilit di allocare risorse aggiuntive in corso dopera, riducendo il rischio che ci diventi controproducente (anche si tratta spesso di un finto rimedio a cui si ricorre in prima istanza: sarebbe un po come pensare che, poich una donna impiega nove mesi per dare alla luce un bambino, se si allocassero tre donne, ecco che lo stesso figlio potrebbe essere disponibile in tre), e cos via. Disporre di un linguaggio per descrivere un sistema costringe il progettista stesso ad analizzare, con maggior minuzia, aspetti del sistema, anche di un certo rilievo, i quali, viceversa, potrebbero incautamente venir trascurati da unanalisi non molto rigorosa. Per ci che concerne lutilizzo dello UML per specificare, bisogna tener presente che in questo contesto lespressione si riferisce alla possibilit di realizzare modelli completi, precisi e non ambigui. Lo UML dispone di tutti i meccanismi necessari per la specifica di qualsiasi dettaglio ritenuto rilevante in ogni fase del ciclo di vita del software e quindi, in ultima analisi, per produrre modelli accurati. Lo UML, permette di realizzare modelli che si prestano ad essere implementati con diversi linguaggi di programmazione, sebbene risulti particolarmente efficace per la progettazione di sistemi Object Oriented. In effetti possibile realizzare un mapping esplicito tra un modello UML e un linguaggio di programmazione. Chiaramente, tale legame risulta pi immediato per i linguaggi fortemente basati sul paradigma Object Oriented, quali C++, Java, Small-Talk, Ada, ecc. Sul mercato sono presenti diversi tool, in grado di generare codice a partire dal relativo modello, sia interattivamente durante la fase di disegno, sia su richiesta. Lesistenza di queste funzionalit, sebbene ancora non del tutto mature, dovrebbe far capire che limplementazione veramente un dettaglio del disegno, specie con linguaggi come Java. La generazione automatica di una prima implementazione del sistema risulta particolarmente utile quando il modello deve essere realizzato parallelamente (cio sempre!), poich fornisce, ai diversi sviluppatori, lo scheletro eventualmente con qualche metodo implementato delle classi fondamentali del sistema che dovrebbero presentare uninterfaccia stabile e ben definita. Sebbene alcuni tools tentino, in alcuni casi particolari, di dettagliare determinati metodi con il codice appropriato, probabilmente ancora un po prematuro azzardarsi a utilizzare appieno tale funzionalit, a meno che non si tratti di meri metodi get / set di propriet.


17

Il mapping tra modello e linguaggio di programmazione permette anche la realizzazione di funzioni di reverse engineering: fornendo a un opportuno tool i codici sorgenti o, talune volte anche quelli compilati, questo in grado di ricostruire a ritroso il modello fino, ovviamente, alla fase di disegno. Purtroppo non si ancora riusciti a realizzare un tool in grado di ricostruire i requisiti del cliente: un vero peccato! Il processo diretto (engineering) e quello inverso (reverse engineering) determinano quello che in gergo viene definito round-trip engineering. Nel mondo ideale, la funzione di reverse non dovrebbe mai venir utilizzata In quello reale invece molto apprezzata, e tutto dipende dalluso che se ne fa. In fase di disegno, probabilmente non opportuno disegnare tutto dettagliatamente; verosimilmente opportuno lasciare qualche margine ai programmatori (tutto in funzione delle loro capacit). Sono ritenute assolutamente naturali e accettabili modifiche del modello in fase di codifica, fintantoch queste non stravolgano il modello stesso. Durante la fase di codifica pu anche accadere di accorgersi che una data libreria non funziona come dovrebbe, o che c qualche lacuna nel modello, o che risulta opportuno cambiare qualche strategia al fine di ottenere un codice pi efficiente Tutto ci normalissimo. Tuttavia, nelleventualit che le modifiche generino uno stravolgimento del modello, piuttosto che procedere nellimplementazione sarebbe forse opportuno introdurre unopportuna iterazione della fase di disegno e successiva codifica. Per ci che concerne lutilizzo dello UML per la fase di documentazione, la tentazione di considerare il tutto fin troppo ovvio forte; ma la famosa vocina dellesperienza si fa sentire. Un progetto, per quanto ben congegnato, potrebbe perdere gran parte del suo fascino se poco documentato, o addirittura potrebbe finire per non essere compreso e in futuro non venire correttamente aggiornato. Per terminare, lo UML fornisce sia dei meccanismi molto formali, sia del testo libero da aggiungere, ogni qual volta lo si ritenga necessario, a parti ritenute poco chiare o particolarmente complesse, al fine di aumentarne il livello di dettaglio.

Che cosa non lo UMLRiportata la definizione formale del linguaggio, si ritiene opportuno ribadirne il concetto da un altro punto di vista: che cosa lo UML non . Potrebbe sembrare ridondante e invece probabilmente il caso del melius abundare quam deficere: c sempre il distratto di turno. In primo luogo, sebbene ci dispiaccia a molte persone, lo UML non un linguaggio di programmazione visuale, anche se questa sar probabilmente la sua naturale evoluzione). In ogni modo, chi ritiene che la modellazione sia inutile in quanto coincidente con la codifica sappia che lo UML non gli sar di particolare aiuto. Il linguaggio di modellazione definisce un metamodello semantico ma non un tool di interfacciamento o di memorizzazione, e nemmeno un modello in grado di essere eseguito.

18


, che cosa non

La documentazione dello UML include molti suggerimenti utili alle aziende che si occupano di realizzare dei tool di supporto, ma non stabilisce ogni necessario particolare. Per esempio, non vengono presi in considerazione dettagli quali la selezione dei colori da utilizzare nella costruzione di diagrammi, la navigazione allinterno del modello, le modalit con cui memorizzare le informazioni, e cos via. Infine lo UML non un processo di sviluppo, sebbene alcuni tecnici tendano a confondere i ruoli: lo UML solo un linguaggio di modellazione e, in quanto tale, si presta a rappresentare i prodotti generati nelle varie fasi di cui un processo composto. Pertanto lo UML, contrariamente ai processi, non fornisce alcuna direttiva su come fare evolvere il progetto, n attraverso quali fasi farlo transitare, n tantomeno su quali siano i manufatti da produrre, o su chi ne sia responsabile ecc.

Metamodello e meta-metamodelloDefinizioni di metamodello e meta-metamodelloContrariamente a convinzioni comuni in molti tecnici, lo Unified Modeling Language, non unicamente una notazione standard per la descrizione di modelli Object Oriented di sistemi software; si tratta bens di un metamodello definito rigorosamente che, a sua volta, istanza di un meta-metamodello definito altrettanto formalmente. Si provveder ora a illustrare brevemente i succitati concetti e le inerenti relazioni, senza avere la pretesa di fornirne una descrizione dettagliata, per la quale si rimanda sia allapposita Appendice A, sia a testi specializzati e in particolare al documento di specifica dellOMG. Ancora una volta si tratta di una materia cos vasta che, probabilmente, meriterebbe un libro a s stante. Ma largomento ha unimportanza e un fascino cos elevato che sarebbe stato un vero peccato escluderlo dalla trattazione del presente libro. Un metamodello un modello a sua volta istanza di un meta-metamodello, fruibile per esprimere una sua istanza di modello: lUML (metamodello) permette di realizzare diversi modelli Object Oriented (modelli definiti dallutente). Il metamodello dello UML definisce la struttura dei modelli UML. Un metamodello non fornisce alcuna regola su come esprimere concetti del mondo OO, quali ad esempio classi, interfacce, relazioni e cos via, ma esso rende possibile avere diverse notazioni che si conformano al metamodello stesso. Per esempio, in UML una classe viene rappresentata da un rettangolo suddiviso in tre sezioni. Unaltra notazione (in modo molto originale ma poco appropriato) potrebbe stabilire di rappresentare il concetto di classe per mezzo di un apposito pseudo-codice e di visualizzare le relazioni graficamente. Entrambe le notazioni, se definite rigorosamente, rappresentano istanze del metamodello, e sono quindi valide a tutti gli effetti. Un metamodello pu specificare che una relazione di associazione deve avere due o pi terminazioni di associazione, ma non prescrive assolutamente che essa vada rappresentata per mezzo di una linea che connette due classi.


19

Cos come avviene nella relazione che lega le classi agli oggetti una volta definita una classe si possono avere svariate istanze della stessa (oggetti) analogamente possibile progettare un numero infinito di varianti dello UML (istanze del metamodello). Al fine di evitare unennesima proliferazione di dialetti sembrerebbe che non appena si lasci un minimo spazio di azione, i generatori naturali di entropia tendano a prendere il sopravvento lo OMG ha anche definito la notazione standard conforme al metamodello, comunemente denominata UML. A dire il vero le cose non sono proprio andate cos; si piuttosto utilizzata una metodologia Bottom-up: partendo da un oggetto concreto (lo UML) e procedendo per astrazioni successive, stata definita la classe (il metamodello). Nelle sue prime apparizioni ufficiali lo UML era composto semplicemente da una notazione grafica, fruibile per rappresentare modelli di sistemi Object Oriented. Quando poi giunto il momento della sottomissione allo OMG, per il riconoscimento ufficiale di standard (gennaio 1997), si reso necessario conferirgli una veste pi formale. Cos a partire dalla versione 1.1 lo UML definisce rigorosamente un metamodello e la notazione atta alla formulazione di modelli Object Oriented conformi a esso. Fin qui quasi tutto chiaro Forse. Volendo per procedere oltre, i concetti diventano un po pi articolati. In effetti, cos come in molti linguaggi di programmazione Object Oriented esiste il concetto di metaclasse (classe le cui istanze sono costituite da altre classi), anche il metamodello unistanza di unentit di livello di astrazione superiore: il meta-metamodello. Un meta-metamodello un modello che definisce un linguaggio per esprimere un metamodello. Chiaro no? La relazione tra il meta-metamodello e il metamodello paragonabile a quella esistente tra il metamodello e il modello. Lo UML definito in termini di un meta-metamodello denominato MOF: Meta Object Facility. Nella fig. 1.4 viene illustrato graficamente quanto emerso fino a questo punto: relazioni esistenti tra il meta-metamodello, il metamodello e il modello dellutente. Scorrendo il diagramma dallalto verso il basso si assiste a una graduale diminuzione del livello di astrazione: se si fosse deciso di visualizzare un ulteriore livello, si sarebbero trovate entit istanze della classe del modello dellutente: oggetti. Se per esempio si realizzasse un prototipo di un sistema di commercio elettronico (i famosi siti .com), a livello del modello realizzato dallarchitetto, si troverebbero classi, opportunamente relazionate tra loro, del tipo: Categoria, SottoCategoria (probabilmente lorganizzazione in Categorie si presta ad essere rappresentata per mezzo del pattern Composite), Prodotto, Utente, Profilo, e cos via. Se poi si volesse visualizzare lulteriore livello, listanza delluser model, bisognerebbe inserire oggetti, istanze di tali classi, come per esempio il Prodotto di codice X, avente prezzo Y, della categoria Z, e cos via. Per avere unidea pi chiara, si consultino la tab. 1.1 e il diagramma riportato nella fig. 1.5. Come si pu notare, nel modello di analisi compare una classe denominata Ordine appartenente al dominio del problema. La classe unistanza della metaclasse, presente nel package UML metamodello e contiene attributi ed operaz

UML e Ingegneria Del Software, Dalla Teoria Alla Pratica (Luca Vetti Tagliati)(Giugno 2003) Hops

Documents

Transcript of UML e Ingegneria Del Software, Dalla Teoria Alla Pratica (Luca Vetti Tagliati)(Giugno 2003) Hops