Progetto Euridice

Click here to load reader

  • date post

    18-May-2015
  • Category

    Documents

  • view

    877
  • download

    0

Embed Size (px)

description

Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione

Transcript of Progetto Euridice

  • 1. UNIVERSITA DEGLI STUDI DI TRIESTEFACOLTA DI INGEGNERIACORSO DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICATESI DI LAUREAIN SISTEMI INFORMATIVI PROGETTO EURIDICE: IDENTIFICAZIONE ED APPLICAZIONEDELLA METODOLOGIA DIPROGETTAZIONE Relatore Laureando Chiar.mo Prof. Fulvio SbroiavaccaStefano Costanzo Correlatrice Dott.ssa Forcolin MargheritaAnno accademico 2008 2009

2. Sommario Introduzione ....................................................................................................... 21. Storia dellingegneria del software ................................................................ 4 1.1 Ingegneria del Software ............................................................................. 62. Ciclo di Vita del Software................................................................................ 8 2.1 Processi di sviluppo software ................................................................... 12 2.2 Metodologie.............................................................................................. 133. Rational Unified Process ............................................................................... 24 3.1 Le fasi del RUP ........................................................................................ 29 3.2 Aspetti statici del RUP ............................................................................ 324. Identificazione delle problematiche di progetto.......................................... 34 4.1 EURIDICE .............................................................................................. 34 4.2 Analisi dello scenario ............................................................................... 36 4.3 Approfondimento ..................................................................................... 39 4.4 Riassumendo ............................................................................................455. Approccio...................................................................................................... 47 5.1 Guida Metodologica alla progettazione ................................................... 516. Progettazione di un Caso duso .................................................................... 69 6.1 Considerazioni generali sulla realizzazione di un caso duso.................. 73 6.2 Progettazione esemplificativa del Caso duso WP26.P2.UC3.2 .............. 756.2.1 Diagramma di sequenza del Flusso principale ................................. 806.2.2 Diagramma delle classi del Flusso Principale ................................... 846.2.3 Approfondimento del Notify Management ..................................... 866.2.4 Diagramma delle Classi WP26.P2.UCR 3.2 Prova ............................ 93Conclusioni e Discussione................................................................................. 96 1 3. Introduzione Il qui presente lavoro di tesi triennale in Ingegneria Informatica sicolloca nel contesto del progetto europeo, gi in carico alla societ InsielS.p.a., EURIDICE (EURopean Inter-Disciplinary research on IntelligentCargo for Efficient, safe and environment-friendly logistics) cofinanziatodalla Commissione Europea nellambito del Settimo Programma Quadro(Seventh Framework Programme -FP71) .EURIDICE un progetto di Ricerca che coinvolge 22 partnerprovenienti da 9 paesi europei che collaborano con la finalit diimplementare il concetto di Cargo Intelligente, si tratta quindi di un progettodi logistica che prevede sia la realizzazione della struttura essenziale che laconcreta dimostrazione della fattibilit degli obiettivi di progetto.Allinizio di questo lavoro di tesi, nel progetto, si era giunti allaconclusione della fase di analisi e quindi si doveva iniziare la faseprogettazione o design.Obiettivo di questa tesi dettagliare la metodologia di progettazioneconsiderando le caratteristiche di un progetto collaborativo internazionale efornire le linee guida per il design.A tal proposito necessario inquadrare le problematiche inerenti losviluppo di un progetto distribuito fra un gran numero di partner dislocati invari paesi europei, quindi verificarne limpatto allo specifico punto diprogresso del progetto ed individuare il metodo di lavoro ed infine produrreuna guida operativa a supporto della corrente fase di progettazione 1 http://cordis.europa.eu/fp7/home_en.html 2 4. corredata da un esempio pratico, ovvero la progettazione completa di unreale Use Case del progetto Euridice.Il lavoro di tesi stato suddiviso in sei capitoli. Il primo capitolo introduce la materia di interesse, ripercorrendobrevemente la storia dellingegneria del software fino alla odiernadefinizione. Nelsecondo capitolosi descriveaccuratamente il concettofondamentale di ciclo di vita del software, esponendo come esso siacomposto e i principali tipi di modelli applicati allo sviluppo dei progettisoftware. Allinterno del terzo capitolo si espone il modello di un processosoftware iterativo sviluppato da Rational Software cio il Rational UnifiedProcess. Esso riveste una fondamentale importanza nellodierna visione dellaproduzione dei progetti software. Il quarto capitolo presenta Euridice ed analizza in fasi successive leproblematiche sollevate da un progetto internazionale collaborativo perlorganizzazione del lavoro. Nel quinto capitolo si delinea leffettivo impatto delle problematichesollevate nella precedente analisi e si definisce un metodo di lavoro per laprogettazione. Infine il sesto capitolo si compone della effettiva realizzazione di uncaso duso ovvero della esemplificazione pratica del metodo di progettazionescelto ad un segmento dei risultati della fase di analisi. 3 5. 1. Storia dellingegneria del softwareLesigenza di creare una disciplina che si occupasse dei processiproduttivi e delle metodologie di sviluppo finalizzate alla realizzazione disistemi software si comincia a sentire attorno alla fine degli anni sessanta.Nasce difatti la necessit di sviluppare prodotti sempre pi complessi edevoluti che rispondano alle richieste delle grandi utenze. Pi precisamente dal 1950 al 1965 lo sviluppo del software personaleera alquanto limitato: tutti i programmi venivano sviluppati in batch2, gliinformatici erano pochi ed apprendevano direttamente sul campo. Ci cheveniva sviluppato era pensato per un unico cliente o talvolta addirittura peruna unica macchina. Inoltre era comune che ad ogni progetto lavorasse econtinuasse a lavorare una sola persona, senza per richiedere che venissescritta alcuna forma di documentazione. Fino alla nascita dell'ingegneria del software, la realizzazione diprodotti software consisteva soprattutto nel mettere insieme una sequenza diistruzioni di codice per realizzare compiti ben specifici. Dal 1965 al 1975 si assiste allo sviluppo di software pensato per piutenti e per dei sistemi particolari per i quali la correttezza del risultatodipende anche dal tempo di risposta. Inserendo quindi un limite temporale2 Il termine batch risale all'epoca della programmazione per schede perforate. In quel contesto, iprogrammatori solitamente non avevano accesso diretto al computer, bens preparavano i propriprogrammi "off-line" e li passavano a un amministratore di sistema, il quale aveva il compito dimandarli in esecuzione quando possibile (accodandoli rispetto ad altri programmi in esecuzione espesso accorpando pi programmi in un'unica unit di esecuzione), restituendo poi in seguito irisultati dell'elaborazione agli interessati.4 6. ad un sistema informatico nasce una famiglia di programmi che devonorispondere ad eventi esterni entro tempi prestabiliti, nasce il concetto di real-time.Nel 1968 la conferenza NATO tenuta a Garmisch, in Germania, rendechiaro il problema rappresentato dall'incapacit di produrre nei tempiprevisti software affidabile e rispondente ai requisiti. A partire dal 1972 efino al 1988 vengono introdotte nuove tecnologie, nascono i sistemidistribuiti e si afferma la figura specializzata del sistemista informatico. Ilcosto dell'hardware si abbassa considerevolmente e di conseguenza latecnologia informatica comincia a diffondersi rapidamente. Organizzazionicome il Pentagono spingono fortemente lo studio di modelli che permettanodi minimizzare la quantit di errori all'interno dei software. Il livelloqualitativo del software si eleva, si tende a controllare lo sviluppo delsoftware cercando di sviluppare prodotti di qualit a causa della concorrenzaaffermatasi tra le software house.Con l'introduzione delle tecnologie informatiche anche nel settoreindustriale e commerciale, bacini di utenza non pi tecniche sentonol'esigenza di informatizzare le proprie strutture. Il cambiamento del tipo diutenza genera lesigenza di curare l'interfaccia grafica presentata all'utenteper renderne pi intuitivo lutilizzo.Il software come prodotto industriale diventa anche oggetto di unattento esame per estendere le capacit di realizzazione dello stesso. Nasce inpratica un concetto simile alle ottimizzazioni da catena di montaggio per leindustrie del secolo scorso che avevano similmente stravolto il modo diprodurre apparecchiature meccaniche. 5 7. 1.1 Ingegneria del Software Per software engineering si intende quella disciplina che si occupa dei processiproduttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemisoftware.L'ingegneria del software si propone degli obiettivi legati all'evoluzionedello sviluppo del software, inteso come attivit industriale, sia da un puntodi vista tecnologico (per esempio attraverso la definizione di nuovi linguaggidi programmazione) che metodologico (per esempio il perfezionamento deimodelli di ciclo di vita del software). Essa identifica quindi unaformalizzazione del processo di realizzazione e di manutenzione di unsistema informativo. Si parla quindi di ciclo di vita3 del software, disciplinache comprende e regolamenta tutte le fasi di un prodotto dalla sua ideazionee realizzazione fino alla conduzione e infine dismissione.Il concetto di qualit viene applicato anche a questa disciplina vista lanecessit di rilasciare un prodotto perfettamente funzionante, documentato efacilmente manutenibile.Per qualit del software si intende la misura in cui un prodotto softwaresoddisfa un certo numero di aspettative rispetto sia al suo funzionamento siaalla sua struttura interna. Per rendere valutabile ci vengono introdotte duefamiglie di parametri: esterni ed interni. I primi si riferiscono alla qualit delsoftware cos come percepita dai suoi utenti, e includono correttezza,affidabilit, efficienza, usabilit. I secondi si riferiscono alla qualit del3 L'espressione ciclo di vita del software si riferisce alla scomposizione di attivit direalizzazione di prodotti software in sottoattivit fra loro coordinate, il cui risultato finale ilprodotto stesso e tutta la documentazione a esso associata.6 8. software cos come percepita dagli sviluppatori, ed includono verificabilit,manutenibilit, riparabilit, evolvibilit, riusabilit, portabilit, leggibilit,modularit. L'ingegneria del software definisce quindi dei modelli e linsieme diprocessi, ovvero sequenze di fasi per la realizzazione di un sistema software,tutte documentate e ispezionabili, che permettano di realizzare prodottisempre pi evoluti e di qualit.7 9. 2. Ciclo di Vita del SoftwareIl concetto di ciclo di vita e di processo software coincide con la nascitadell'ingegneria del software, in quanto rappresenta un passaggio storicodallo sviluppo del software inteso come attivit artigianale, ovvero affidataalla libera creativit dei singoli individui, a un approccio pi industriale, incui la creazione di programmi e sistemi software viene considerata come unprocesso complesso che richiede pianificazione, controllo, e documentazioneappropriati. L'espressione ciclo di vita del software si riferisce al modo in cui unametodologia di sviluppo o un modello di processo scompongono l'attivit direalizzazione di prodotti software in sottoattivit fra loro coordinate, il cuirisultato finale il prodotto stesso e tutta la documentazione a esso associata.Fondamentalmente le attivit costituenti il processo di sviluppo sono: la fase di Analisi, ovvero lindagine preliminare sulle caratteristiche che il sistema deve esibire e sul contesto in cui il prodotto software deve inserirsi. Questa fase pu essere scomposta in sottoattivit quali: la definizione del problema - comprendere il problema che il sistema chiamato a risolvere; lo studio di fattibilit - stabilire se gli obiettivi dello sviluppo sono ragionevoli e raggiungibili sia in dal punto di vista tecnico che economico; l'analisi del dominio - comprendere il contesto o dominio applicativo in cui il sistema dovr agire; 8 10. la determinazione dei requisiti - specifica dettagliatamente le funzioni da svolgere, i servizi da erogare e le caratteristiche non funzionali richieste per il sistema;In senso pi ampio si pu dire che lanalisi ha lo scopo di definire, ilpi precisamentepossibile, il problema. Questa fase svoltaessenzialmente grazie alla raccolta delle informazioni attraverso colloquicon il cliente.Lattivit di analisi si conclude con la produzione di un documentoche descrive in modo preciso, ma comprensibile al cliente, ci che far ilsistema, tale documento viene definito Documento dei requisiti. nella fase di progettazione, in funzione dei requisiti evidenziatidall'analisi, si definisce la struttura del sistema da realizzare. Anchequesta fase pu essere suddivisa in sotto attivit:architettura - definisce le specifiche del prodotto. I requisiti vengono riformulati in modo da essere comprensibili agli sviluppatori ed aderenti alla tecnologia che verr utilizzata. Nella fase di analisi il software pu esser stato suddiviso in moduli di alto livello, bisogna definire come essi si relazionano e quali siano i loro vincoli non funzionali. Questa sottofase porta alla stesura del documento delle specifiche, esse possono essere di due tipi: funzionali enonfunzionali. Leprime rappresentano le funzionalit del software, le seconde invece rappresentano i vincoli ai quali deve sottostare il software (tempi, utilizzo di hardware particolari, logistica);progetto dettagliato - definisce in modo preciso i moduli che comporranno il software e la loro struttura interna. Viene definita9 11. la loro interfaccia ed i dati ai quali possono accedere. Questa sottofase riveste un ruolo importante dunque perch si attuano scelte su come si realizzer effettivamente il prodotto software; nella fase di implementazione, o codifica, che si procede con larealizzazione concreta del sistema; questa tipicamente consiste nellarealizzazione dei vari moduli costituenti. Nella maggior parte dei casi possibile distinguere almeno due sottoattivit per i singoli moduli checostituiscono il sistema: Codifica e Verifica. Complessivamente si tratta diuna fase piuttosto tecnica, tutte le decisioni principali sono state presenelle fasi precedenti;la fase di collaudo, volta a misurare in che modo il sistema realizzatosoddisfa i requisiti stabiliti nella fase di analisi, ovvero a valutarne lacorrettezza rispetto alle specifiche. Quando ogni modulo individualmente corretto si passa allintegrazione dei moduli. Vienequindi testato il sistema complessivo: viene confrontato il documentodelle specifiche funzionali e non funzionali (Are we building the productright?).Quando il sistema si comporta in accordo con il documento dellespecifiche, si passa allinstallazione dello stesso nel suo ambiente e siprocede al collaudo. Il collaudo comprova da parte dellutente che ilprodotto soddisfa i suoi bisogni ed obiettivi. A questo scopo si confrontail sistema con il documento dei requisiti (Are we building the rightproduct?);la fase di manutenzione, che comprende tutte le attivit di modifica delsoftware successive al suo rilascio presso il cliente o la sua immissione sul10 12. mercato. Queste attivit possono essere volte a correggere errori del software, adattarlo a nuovi ambienti operativi, estenderne le funzionalit o a revisionarne operazioni regolamentate da nuove leggi. La manutenzione incide sui costi poich modifica al software comporta ovviamente la necessit di nuovi test, sia relativi alle nuove funzionalit eventualmente introdotte, sia mirati a verificare che le modifiche apportate non abbiano compromesso funzionalit preesistenti. Una linea standard di verifica prevede dei test sui moduli similarmente alla precedente fase di test, ovvero si testa che i moduli funzionino singolarmente e che una volta assemblati continuino a funzionare; In tutti i cicli di vita del software svolge inoltre un ruolo essenziale ladocumentazione dei prodotti delle varie sottoattivit.11 13. 2.1 Processi di sviluppo softwareLa maggior parte delle metodologie di sviluppo del software consiste,almeno in linea di principio, in un linguaggio di modellazione e un processo.Il linguaggio di modellazione la notazione usata dalle metodologie peresprimere le caratteristiche di progetto, mentre il processo una serie dipassi, una sorta di elenco che aiuti ad ottenere risultati di alta qualit in untempo prefissato. Il processo software composto da alcune attivit cherappresentano un insieme di compiti da svolgere per sviluppare un software: Attivit portanti: unaseriedi compiti da svolgere necessariamente; Attivit ausiliarie: possono aumentare la qualit di un software da produrre, di solito tali attivit sono considerate dalle aziende che cercano una certa qualit. Tali attivit non riguardano il progetto in s ma piuttosto l'azienda; Coloro che, individualmente o in gruppo, lavorano allo sviluppo o allamodifica di un software, adottano necessariamente un certo approccio nelmodo di relazionarsi con i propri clienti, nell'organizzare il proprio lavoro,nella scelta delle tecniche da utilizzare. In modo consapevole o meno, ognisviluppatore o gruppo di sviluppatori software ha un proprio processo disviluppo, esso definito dal proprio modo di lavorare, basato sulla propriaesperienza, sulla propria cultura, e sul contesto culturale ed organizzativo incui si trova ad operare. La storia dei successi e degli insuccessi dei progetti di svilupposoftware ha insegnato che ogni processo di sviluppo ha i propri pregi ed ipropri limiti. E che un processo di sviluppo inadeguato alle concrete esigenzedello specifico progetto pu condurre al fallimento del progetto stesso, ocomunque all'insoddisfazione dei clienti e degli stessi sviluppatori. 12 14. 2.2 MetodologieNel campo delle scienze esatte un modello una formalizzazioneprecisa della una realt mediante equazioni matematiche. Nello sviluppo delsoftware, il modello chiaramentemenopreciso, ma comunquelapplicazione di un modello, magari impreciso ma aderente al caso, pursempre preferibile alla non applicazione di un modello. Questa affermazione particolarmente evidente per lo sviluppo diprogetti software, a tal riguardo nel tempo si sono affermate numerose ediverse metodologie per rispondere al progresso tecnologico e alconseguente modificarsi delle potenzialit del software. Vediamo ora alcune diverse tipologie di modelli:Modello a cascataQuesto modello caratterizzato da un rigida suddivisione in passisequenziali ognuno dei quali definisce una attivit che opera su un insiemedi ben definiti input e produce determinati output che serviranno come inputdella fase successiva. Importante sottolineare che viene regolamentata ladocumentazione delle varie fasi del processo. Il modello a cascata tradizionale prevede le seguenti fasi:studio di fattibilit: ha lo scopo di determinare se intraprendere losviluppo del sistema;analisi dei requisiti: ha lo scopo di determinare che cosa far il sistema;progettazione: ha lo scopo di determinare come il sistema far quantostabilito nella prima fase, e in particolare la sua suddivisione inmoduli e le relazioni fra di essi; 13 15. sviluppo o codifica: creazione dei moduli con un linguaggio di programmazione; collaudo: esecuzionedi prove per verificare la correttezza dell'implementazione dei singoli moduli; test di integrazione: esecuzione di prove per verificare la correttezza del funzionamento complessivo del sistema; manutenzione: segue la consegna o delivery del prodotto al cliente, e comprende tutte le attivit volte a migliorare, estendere e correggere il sistema nel tempo; Nel contesto di una specifica organizzazione, il modello a cascata puessere ridefinito in molti modi, inoltre un'organizzazione pu formalizzareulteriormente il processo definendo standard e imponendo vincoli perquanto riguarda la natura, il formato, la struttura e i contenuti dei documentiprodotti nelle varie fasi, tipicamente allo scopo di consentire un controllo pirigoroso sullo stato di avanzamento del progetto e sulla qualit del lavorosvolto. Il modello ha giocato un ruolo importante nello sviluppo del softwareper superare i limiti del processo del code and fix e infine ha fissato dueconcetti: Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione; Limplementazione del prodotto deve essere rimandata fino a quando non sono perfettamente chiari gli obiettivi. Il maggior pregio di questo metodo di lavoro certamente lasemplificazione del controllo dellandamento del progetto tramite lasuddivisione del ciclo di vita in fasi successive ben definite. Le diverse14 16. metodologie che adottano questo modello si distinguono essenzialmente perla suddivisione e specificazione delle fasi in sottofasi pi elementari, nelladefinizione di standard di documentazione e nella individuazione dimomenti di verifica, detti milestone, al termine o durante ciascuna attivit.Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasipersegue lobiettivo di assegnare a ciascuna fase la soluzione diproblematiche specifiche e di rendere, per quanto possibile, le fasiindipendenti allo scopo di poterne parallelizzare le attivit.Bench ladozione di questi principi appaia estremamente produttiva,la loro applicazione pratica ha come effetto collaterale, soprattutto per iprogetti di grandi dimensioni, una pericolosa dilazione temporale. Adesempio, normalmente lindividuazione delle strutture dati e dellefunzionalit del sistema sono affrontate con metodologie diverse e,soprattutto per i progetti di grandi dimensioni, contemporaneamente eseparatamente da gruppi di lavoro differenti. Nel primo caso i risultati sonoformalizzati con uno Schema Entity-Relationship e nel secondo con unmetodo di scomposizione funzionale. Solo quando queste due attivitterminano viene avviata una ulteriore attivit di armonizzazione deirispettivi risultati.Un ulteriore problema di questa impostazione deriva dalla necessit diterminare completamente tutta la fase di analisi dei requisiti e progetto percominciare limplementazione e quindi verificarne sul campo le conclusioni.Il modello, quindi, una semplificazione della realt che non trovapiena applicazione in quanto vengono applicati i seguenti tre principi: Linearit: spesso si hanno cicli di feedback per la correzione degli errori. Tale feedback deve essere lineare e quindi non si possono15 17. effettuare salti a ritroso ma vanno ripercorse tutte le fasi in manieralineare; Rigidit: ogni fase viene congelata quando si passa alla fase successivaper cui non possibile uninterazione tra clienti e sviluppatori duranteil ciclo di vita dopo la parte iniziale; Monoliticit: tutto il modello orientato alla singola data di rilascioche spesso si pone a mesi o anni dopo linizio della prima fase per cuise vengono commessi eventuali errori o cambiano i requisiti, questiverranno implementati dopo parecchio tempo e comunque alla fase diconsegna seguir subito un altro adattamento perch il software sargi obsoleto; Concludendo quindi, in base alle nozioni appena riportate si possonoidentificare i maggiori problemi del modello: difficile stimare le risorse e i costi in maniera accurata finch non siastata svolta almeno la prima fase di analisi; La specifica dei requisiti produce un documento scritto che vincola ilprodotto da sviluppare e ci non sempre soddisfa le esigenze delcliente perch si tratta pur sempre di specifiche basate su undocumento che non sempre aiuta nel definire le esigenze, che invece,appaiono subito chiare dopo il primo rilascio del software. Inoltre taledocumento deve essere completo e chiaro prima di procedere allosviluppo, ma non sempre ci possibile; Lutente non in grado di comprendere i formalismi utilizzati perdescrivere i requisiti dellapplicazione, si corre quindi il rischio dipassare alla fase di progetto con una documentazione non del tuttoaderente agli obiettivi del cliente;16 18. Si comprende come gli alti costi del software siano dovuti, nel modelloa cascata, a causa proprio delle specifiche poco complete e ai molti interventisuccessivi per introdurre funzionalit non previste in partenza. La curva dicosto degli errori in questo modello esponenziale proprio perch data lamonoliticit pi tardi ci si accorge di un errore e pi profonda dovr essere lacorrezione da apportare.Modello esplorativoSe non si possono determinare le specifiche, non pu essere definita lacorrettezza del sistema, ossia la corrispondenza con le specifiche. In questi casi viene utilizzato il concetto di adeguatezza, ossiacorrispondenza con i bisogni e gli obiettivi del cliente. Il modello esplorativoconsiste in una successione di prototipi che viene fatta convergere verso unasoluzione adeguata, soddisfacente per il cliente. Non si tratta di una vera metodologia quanto piuttosto di un approcciosperimentale e iterativo allo sviluppo: ad ogni iterazione viene costruito unprototipo e presentato alla valutazione critica del cliente, che lo pu accettarecome adeguato alle sue esigenze, oppure pu indicare nuovi criteri e requisitiche il sistema deve possedere. Nei passi finali il prototipo viene affinato ad ogni ciclo finch vieneaccettato dal cliente. Questo modello presenta due caratteristiche salienti: Non vi distinzione tra prototipo finale e prodotto. Questo normalmente non risulta vantaggioso per il fornitore; Vi un forte coinvolgimento del cliente nella fase di sviluppo rispetto al modello a cascata con conseguenti costi anche per il cliente. 17 19. Modello incrementaleQuesto modello caratterizzato dalla scomposizione del processo inuna serie di passi sequenziali da ripetere ad ogni termine del cicloprecedente. Per poter applicare questo modello consigliabile avere unavisione molto chiara dellintero progetto, perch occorre fare in modo che larealizzazione della generica versione k risulti utile per la realizzazione dellaversione k+1. Per fare ci bisogna eseguire con cura la fase di analisi (definizione delproblema, analisi di fattibilit, e cos via) e poi procedere con literazione delseguente ciclo di attivit: analisi dei requisiti progetto codifica test o collaudo Importante osservare che ogni iterazione ha un piano, degli obiettiviverificabili e criteri di valutazione propri, ci permette un migliore controllodel lavoro. Ogni qual volta che si termina una iterazione del ciclo si ha realizzatouno o pi moduli funzionanti che vengono integrati e testati con quelliprecedentemente sviluppati creando una versione funzionante del progettoche implementa un sottoinsieme finito delle funzionalit del progettosoftware totale. Si procede in maniera analoga fino allennesima iterazione equindi alla conclusione del ciclo con il rilascio della versione finale. Questo tipo di approccio offre delle differenze sostanziali rispetto ilmodello a cascata visto in precedenza; organizzando le iterazioni cercando didare una priorit di messa in opera non solo dipendente dallutilit18 20. incrementale dei vari moduli ma soppesando anche le criticit degli stessi possibile affrontare i rischi del progetto fin dallinizio, in modo sistematico. Inoltre operare con un sistema stratificato di release permette unamaggiore flessibilit per gestire eventuali cambiamenti esterni (tecnologie,leggi) o interni (errori nel documento dei requisiti) e favorisce lapartecipazione del cliente alla vita del progetto; tutto ci accresce ovviamenteil costo per il cliente ma offre la possibilit di fornire velocemente softwarefunzionante e fornire risultati di valore poich questo modello consente unaprogettazione adeguata, in quanto porta ad un progetto solido. Object Oriented NellObject Oriented limportanza fondamentale rivestitadallapproccio che si adotta per la scomposizione del problema. Questometodo mira infatti ad una decomposizione di un sistema mediantelastrazionedi oggetti,che diversa dalla decomposizionefunzionale/procedurale. Tutti i linguaggi ad oggetti includono sempre untipo di modulo chiamato classe, esso uno schema dichiarativo che definiscetipi di oggetti. La dichiarazione di classe contiene implicitamente ladefinizione dei dati e dei metodi che operano su di essi. Per poter continuare la spiegazione liberamente si introducono ledefinizioni di alcuni termini propri dell Object Oriented specifici delladefinizione di una classe:Classe: Nome collettivo di tutti gli oggetti che hanno gli stessi metodi evariabili di istanza (dichiarazione di tipo);Oggetto: Entit strutturata (codice, dati) e proprietaria di uno Stato la cuistruttura invisibile allesterno delloggetto;19 21. Stato: Lo stato di un oggetto si accede e manipola mediante messaggi cheinvocano metodi, quindi non direttamente accessibile;Variabili di istanza: Variabili contenute nelloggetto che rappresentano il suostato interno;Messaggio: Richiesta ad un oggetto di invocazione di uno dei suoi metodi;Metodo: Azione che accede o manipola lo stato interno delloggetto (di solitole variabili di istanza), limplementazione di tale azione nascosta al clienteche spedisce messaggi alloggetto. Approfondita ora la definizione e terminologia di una classe risulta pisemplice introdurre i concetti propri dellObject Oriented: Classificazionela definizione di classi rappresenta lidentificazione di un insieme di attributi(variabili di istanza) e di operazioni (metodi) propri di oggetti simili. Proprioper questo motivo si pu dire che una classe descrive un insieme di oggetti elo rappresenta tramite unastrazione degli attributi rilevanti; Responsabilitogni classe ha una responsabilit limitata ai comportamenti che essa prevede(ai metodi che implementa); Ereditarietquesto concetto indica che una classe, detta sottoclasse, pu essere unraffinamento di unaltra andando cos a richiedere alcune variabili e/ometodi aggiuntivi rispetto alla classe raffinata, che viene denominatasuperclasse. Il vantaggio quindi lutilizzo condiviso delle definizioni diattributi e codice in classi diverse, rendendo quindi sufficiente la soladefinizione delle variabili e dei metodi aggiuntivi; 20 22. Generalizzazionepu rivelarsi opportuno evidenziare sottoinsiemi definibili come ulteriori tipidi oggetto allinterno di classi gi identificate. Questo concetto identificabilebanalmente come la relazione di contenimento in insiemistica (un sempliceesempio pu essere Veicolo Moto); Polimorfismosi vuole rendere standard che le operazioni con lo stesso significatoposseggano lo stesso nome anche se implementazioni diverse. Si intuisce cheesse verranno identificate univocamente dallinsieme di variabili su suioperano (esempio calcolo_area su figure geometriche diverse); Information Hidingogni classe nasconde tutto ci che non essenziale condividere,impedendone cos laccesso o la modifica diretta e non facilmentecontrollabile dallesterno; Gettati i punti essenziali dellObject Oriented si pu vedere ora lastruttura della sua applicazione, limitiamoci a descrivere una scomposizionein tre fasi: Analisi, Design e Realizzazione.I processi Analisi Object Oriented hanno tutti la seguente struttura: Identificazione dei requisiti; Inquadramento di scenari e delle interazioni fra attore e sistema (casiduso); Estrazione delle componenti candidate; Costruzione di un modello di relazioni fra le componenti; Costruzione di un modello di comportamento delle componenti; Revisione dellanalisi rispetto ai casi duso;21 23. Interessante approfondire come la descrizione in linguaggio naturaledei requisiti pu essere interpretata direttamente nella identificazione delleentit e dei loro attributi e metodi. Se si provvede a separare ogni frase deirequisiti in gruppi attinenti agli stessi soggetti risulta chiaro come ognisostantivo pu essere identificato come oggetto ed ogni verbo pu essereidentificato come metodo. Ovviamente necessario porre attenzione aisignificati di sinonimi e differenti modi di riferirsi al medesimo oggetto. Dopo aver completato la fase di analisi si ha dunque una totalescomposizione del problema in componenti e dei modelli in cui vengonodefinite le loro relazioni e i loro comportamenti. La fase di Design deve oraspecificare completamente queste componenti facendo riferimento anche aivincoli tecnologici che si impongono al progetto. Bisogna misurare il grado di indipendenza dei vari componenti. Inutilesottolineare che le componenti di un sistema dovrebbero riportare un bassoaccoppiamento, limitando il numero di dipendenze e lasciando solamentequelle funzionalmente rilevanti e necessarie. Si rivela essenziale definire una gerarchia fra i componenti del sistema,riducendo le dipendenze e vincolando la topologia delle relazioni fra imoduli. Unastruttura gerarchicaforma la basedel progettodecomponendone il dominio e facilitandone lo sviluppo in parallelo.Riassumendo i concetti dellapproccio Object Oriented al design si pu direche: le componenti vengono classificate astrazione e incapsulamento sono meccanismi principali dellastrutturazione il sistema finale rispecchia il dominio del problema possibile la concorrenza dei processi (thread multipli) 22 24. Nellesporre lObject Oriented infine non riveste particolare importanzadescrivere la fase di realizzazione. Questo perch se le precedenti fasi sonostate eseguite con la dovuta meticolosit e non sono presenti errori, si trattasolamente di riportare le classi nel o nei linguaggi scelti e di sviluppare leinterfacce necessarie, riducendosi cos ad una mera procedura diprogrammazione. 23 25. 3. Rational Unified Process Il Rational Unified Process un modello di un processo softwareiterativo sviluppato da Rational Software. Esso provvede a fornire unapproccio disciplinato per lassegnazione dei compiti e delle responsabilitallinterno di una organizzazione di sviluppo software. Il suo obiettivo garantire una produzione di alta qualit che trovi un punto di incontro fra leesigenze dei clienti e le tempistiche e il budget dellazienda. Il R.U.P. nondefinisce un singolo, specifico processo, bens un framework adattabile chepu dar luogo a diversi processi in diversi contesti, esso pensatoprincipalmente per i progetti di grandi dimensioni.Interessante sapere come nato, i creatori del RUP partirono dalladiagnosi di un campione di progetti software falliti, allo scopo di identificarecause tipiche o generali di fallimento. Quindi confrontarono questainformazione con la struttura dei processi software descritti in letteratura eapplicati nella pratica, cercando di identificare le soluzioni proposteprecedentemente. L'elenco dei motivi di fallimento identificati comprendeper esempio: Gestione ad hoc dei requisiti; Comunicazione ambigua e non precisa; Architettura fragile ,incapace di sopportare situazioni di particolarecriticit; Incapacit di gestire la complessit; Inconsistenze nei requisiti, nel progetto o nelle implementazioni; Collaudo insufficiente; Valutazione soggettiva dello stato del processo; Incapacit di affrontare il rischio; Propagazione non controllata delle modifiche;24 26. Insufficiente automazione;Il RUP si pu descrivere come una collezione di best practices mirate aevitare questi e altri problemi, e come un ambiente di gestione dei processiche facilita l'applicazione di tali pratiche. Il processo fu progettatoutilizzando strumenti tipici della progettazione del software; in particolare,esso fu descritto in termini di un meta modello object-oriented, espresso inUML.Per lappunto chiameremo da ora in poi queste diverse metodologie diapproccio descritte dal RUP come processi o best practices, vediamo ora lesei pi importanti:Sviluppo software iterativo (Develop Software Iteratively)Disciplina dei requisiti (Manage Requirement)Utilizzo di architetture a componenti (Use Component-basedArchitectures)Verifica della qualit del software (Verify Software Quality)Controllo dei cambiamenti (Control changes to software)Modellizzazione Visuali (Visually Model Software)Disciplina dei requisitiIl RUP descrive come identificare e tracciare i documenti funzionalinecessari, definirei vincoli, estrarre, organizzare e comunicaresemplicemente i requisiti del business. Le nozioni di use case e di scenarisono state dimostrare essere degli eccellenti modi di procedere al fine dicatturare e definire i requisiti funzionali ed assicurare che essi guidinocorrettamente il design, limplementazione e il test del software, portandolocos ad adempire fedelmente alle necessit del cliente.Sviluppo software iterativo 25 27. La tecnologia di oggi ci offre dei sistemi software estremamentecomplessi, non possibile definire sequenzialmente e di primo acchitolintero problema, effettuarne il design, codificarlo e testarlo solo al terminedel processo produttivo. Un approccio iterativo richiesto per permettereuna comprensione progressiva del progetto e quindi un suo raffinamento alfine di far crescere leffettiva soluzione migliore su questo ciclo di iterazionimultiple. Questa struttura permette tramite lo sviluppo dei maggiori oggettidi rischio nelle prime iterazioni, di mantenere sotto controllo il rischiodurante tutto il ciclo di vita del software. Un approccio iterativo facilitaladeguamento degli obiettivi di progetto ai cambiamenti, andando a ridurresignificativamente il costo dei cambiamenti dovuti ad errori a qualsiasilivello.Controllo dei cambiamentiLabilit di controllo e gestione dei cambiamenti essenziale perrendere ogni necessit di alterazione accettabile e permettere di tracciarecome essa inevitabilmente affonder e richieder delle modifiche nelprogetto. Questo processo descrive come controllare, tracciare e monitorare icambiamenti per poter sviluppare iterativamente ed efficacemente a frontedel presentarsi di errori.Verifica della qualit del softwareOggigiorno cattive performance applicative e scarsa affidabilit sonocomuni fattori che segnano linaccettabilit del software. Quindi, si rendenecessario un controllo qualitativo basato sui requisiti sullaffidabilit, lafunzionalit, le performance delle applicazioni e dellintero sistema. Il RUPmette a disposizione dei parametri valutativi per i test di pianificazione,design,implementazione,esecuzionee valutazione. importante26 28. comprendere che la qualit costruita nel processo, in tutte le attivit, affetta da ogni partecipante al progetto, ha dei criteri e parametri divalutazione definiti e non deve essere trattata come una attivit separatasvolta da un gruppo dedicato come aggiunta al progetto. Utilizzo di architetture a componenti Il processo centrato sul definire la linea guida di una architetturaeseguibile robusta e svilupparne velocemente alcune parti, prima diimpegnare le risorse per uno sviluppo massivo. Esso descrive comedisegnare una architettura ricuperabile che sia flessibile ed adattabile aicambiamenti, e come intuibile che favorisca il riutilizzo del softwareinterno. I componenti non sono meri moduli ma sottosistemi che adempiono aspecifiche funzioni. Il RUP provvede a definire un approccio sistematico perla definizione dellarchitettura utilizzando componenti nuovi e/o preesistenti. Modellizzazione Visuali Questo processo mostra come modellizzare in maniera visuale ilprogetto software per catturare la struttura e il comportamento delle variecomponenti. Lastrazione visuale aiuta a comunicare differenti aspetti delprogetto, come gli elementi combacino nel sistema, accertare che i blocchisiano in linea con il codice, mantenere la consistenza tra il design elimplementazione e favorisce la comunicazione disambigua con il cliente. Lostandard industriale Unified Modeling Language il fondamento per unamodellizzazione visuale di successo. Lo UML uno strumento per analisti e progettisti di sistemi orientatiagli oggetti che consente di modellare, rappresentare e documentare sistemi27 29. software. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, JimRumbaugh e Ivar Jacobson (detti "i tre amigos") sotto l'egida dello OMG, chetuttora gestisce lo standard di UML. Questo linguaggio di modellazione visuale un insieme di elementi edi regole, di specifica formale ed offre un notevole vantaggio; infatti anche iprogettisti e gli analisti di sistemi informativi utilizzano figure e diagrammiper visualizzare il risultato del loro lavoro: il sistema software. Durante lefasi di analisi e progettazione vengono generati dei modelli che consentonodi identificare e separare le caratteristiche di un sistema reale. Il progettistadovr quindi decidere quali caratteristiche sono rilevanti per il sistema chesta costruendo, inserirle e definire le relazioni tra gli elementi del modello.Ci avviene anche se il tipo di prodotto finale che risulta dalla progettazionenon necessariamente visuale. Il Rational Unified Process quindi uno schema generale di unprocesso, da adattare alle diverse tipologie di progetto, esso si articola in unaserie di iterazioni con lo scopo di ridurre progressivamente i rischi, a partireda quelli principali (es. incomprensionisui requisiti, incertezzeimplementazione). In ogni iterazione si svolgono, in misura e in percentualidiverse, le tipiche attivit di sviluppo (es. gestione dei requisiti, design,implementazione, test) adottando cos un modello incrementale che si svolgeattraverso la realizzazione ed eventualmente il rilascio dellapplicazione inmodo progressivo guidata per dai casi duso e dalle priorit architetturali. La definizione dellarchitettura applicativa e tecnologica costituisce ilfondamento tecnico dellapplicazione e del progetto, ed il consolidamentodella stessa avviene solo quando si certi della sua fattibilit tecnica. Fino aquando larchitettura non consolidata non esistono elementi sufficienti per 28 30. determinare i tempi, i costi e i rischi dellintervento progettuale con laprecisione necessaria per la stipulazione di un contratto. 3.1 Le fasi del RUPNel RUP, il ciclo di vita di un processo software viene suddiviso in ciclidi sviluppo, a loro volta scomposti in fasi. Le fasi previste sono: Inception Phase Elaboration Phase Construction Phase Transition Phase Ogni fase si conclude con una milestone per indicare il raggiungimentodi obiettivi stabiliti in fase di definizione del progetto stesso. Inception Phase Questa fase si pu considerare come una particolare elaborazione eprecisazione del concetto generale di analisi di fattibilit. Lo scopo principale quello di delineare nel modo pi accurato possibile il business case, ovverocomprendere il tipo di mercato al quale il progetto afferisce e identificare glielementi importanti affinch esso conduca a un successo commerciale. Fra glistrumenti utilizzati ci sono un modello dei casi d'uso, la pianificazioneiniziale del progetto, la valutazione dei rischi, una definizione grossolana deirequisiti e la identificazione delle interazioni ad alto livello. Alla fine di questa fase presente la prima milestone maggiore delprogetto, detta "Lifecycle Objective Milestone". I criteri di valutazione per laInception Phase sono: 29 31. Coincidenza del rapporto definizione dello scopo e costo stimato con le aspettative del cliente;Comprensione e definizione dei requisiti, evidenziato della corretta redazione degli use cases primari;Credibilit dei costi stimati, priorit, rischi e organizzazione del processo di sviluppo;Presenza di ampia ed accurata documentazione su ogni prototipo architetturale sviluppato;Resoconto delle spese attuali e pianificazione delle future;Il progetto pu essere abbandonato o ridimensionato in manieraconsiderevole nel caso non passi questa milestone.Elaboration PhaseLobiettivo principale di questa fase analizzare il dominio delproblema, stabilire una base architetturale, sviluppare un piano del progettoed eliminare i fattori di rischio pi elevato del progetto. Questa fase deveconcludersi con il superamento di una milestone detta "LifecycleArchitecture Milestone". A questo scopo devono essere soddisfatti i seguenticriteri:Sviluppato un modello dei casi d'uso completo all'80%Fornire la descrizione dell'architettura del sistemaSviluppata un'architetturaeseguibileche dimostrail completamento degli use cases significativiEseguita una revisione del business case e dei rischiCompletata una pianificazione del progetto complessivoRedazione di un manuale utente preliminare (opzionale) 30 32. Se il progetto non passa questa milestone, potrebbe ancora essereabbandonato, oppure dovr essere revisionato. Al termine di questa fase sitransita infatti in una situazione di rischio pi elevato, in cui le modificheall'impostazione del progetto saranno pi difficili e dannose. Construction Phase Durante questa fase, tutte le componenti vengono sviluppate edintegrate al prodotto, e infine vengono testate. Nella construction phase , inun certo senso, un processo manifatturiero in cui lenfasi viene dedicata alladistribuzione, controllo e gestione delle risorse per ottimizzare i costi emassimizzare la qualit. Molti progetti sono sufficientemente estesi perpermettere una organizzazione parallela nella realizzazioni di alcunecomponenti. Queste attivit parallele possono accelerare significativamente ilrilascio ma incrementa notevolmente la complessit di gestione delle risorsee sincronizzazione dei workflow. Al termine della Construction Phase c la cos denominata InitialOperational Capability Milestone, essa deve determinare se quello che stato prodotto pu considerarsi operativo senza esporre lintero progetto aqualche rischio. Gli output essenziali di questa fase sono: Il prodotto software pianificato da realizzare funzionante ed integrato sulla piattaforma adeguata Il manuale utente Una descrizione della release corrente Transistion Phase Questa fase si propone di attuare la transizione del prodotto sviluppatoal cliente, facilmente intuibile che una volta installato si renderannonecessari degli interventi correttivi o sviluppativi che richiederanno delle 31 33. nuove release. La Transition Phase si introduce quando lo sviluppo iterativosi porta ad un punto sufficiente per permettere il rilascio al cliente, i tipicirequisiti per fare ci sono che il libello di qualit del sottosistema completatosia accettabile e che la documentazione utente sia disponibile. In questomodo la transizione del prodotto al cliente porter un risultato positivo perentrambe le parti, permettendo ad esempio di validare il nuovo sistema e diiniziare a formare il personale. Con la Production Release Milestone si vuole valutare seeffettivamente il cliente soddisfatto di ci che gli si propone e se ildispendio registrato di risorse contro quello programmato accettabile. Aquesto punto, se gli obiettivi sono stati raggiunti possibile iniziare un altrociclo di sviluppo, in alcuni casi questa milestone coincide con la fine dellainception phase del ciclo successivo. 3.2 Aspetti statici del RUPIl meta modello applicato dal RUP per descrivere e controllare unprocesso utilizza quattro concetti cosiddetti "statici", ovvero che sono definitinello stesso modo per tutti i processi: WorkerUn ruolo identifica un certo insieme di responsabilit attribuite aun certo insieme di partecipanti al progetto(I ruoli rispondono alla domanda chi?); ArtifactGli artefatti sono il prodotto delle attivit del processo; includonodocumenti, modelli, componenti software e via dicendo(Gli artefatti rispondono alla domanda cosa?); 32 34. WorkflowUn workflow una sequenza di attivit che producono unrisultato in un tempo osservabile(I workflow rispondono alla domanda quando?); AttivitLe attivit sono i compiti specifici portati a termine daipartecipanti del progetto(Le attivit rispondono alla domanda come?);33 35. 4. Identificazione delle problematiche di progetto4.1 EURIDICE Il progetto Euridice, un progetto cofinanziato dalla CommissioneEuropea, che si prefigge la realizzazione del concetto di "Cargo Intelligente"come veicolo di ottimizzazione del settore logistico. E un Integrated Projectcon un budget di circa 14 M e un partenariato di 22 partner provenienti da 9paesi europei che include aziende leader nelle tecnologie software, mobile,wireless e RFID, rinominati centri di ricerca, operatori logistici, istituzioni eutenti finali.Lobiettivo del progetto la creazione di una architettura e diapplicazioni pilota atte a verificarne la validit e lusabilit nel mercato deitrasporti europei.Potendo installare dispositivi con una certa capacit elaborativadirettamente sulla merce, questa potrebbe essere in grado di riconoscere ilcontesto in cui si trova, prendere decisioni e segnalare eventuali anomalie,questo in estrema sintesi il Cargo Intelligente che pu quindi diventareun attore primario nei processi di trasporto e delivery, e fornire informazioniin tempo reale dettagliate ed affidabili al sistema centrale.Il continuo dialogo fra dispositivi di diverso livello automatizzaprocedure oggi affidate allutente umano e migliora le tempistiche elefficienza di molte fasi dipendenti dai trasporti: velocit di consegna, caricoe scarico, programmazione della produzione in funzione degli arrivi deisemilavorati, ottimizzazione visti doganali e controlli, tracciabilit in tempoutile della posizione della merce e dei veicoli, programmazione del percorso 34 36. centralizzata, disposizione di informazioni sullo stato della merce in temporeale e cos via.Risulta immediato realizzare le potenzialit di tale progetto e al tempostesso risulta evidente che le difficolt che si potranno presentare non sonopoche.Viene generalizzato Euridice ad un progetto generico portandosi cos inuna situazione favorevole ad unanalisi delle possibili problematiche di unprogetto di questo tipo.Ci si pone quindi in uno scenario in cui un consorzio di aziende siassociano per sviluppare un progetto di ricerca europeo. Tali aziende sonodistribuite in vari paesi e non sono specializzate negli stessi settori. Partendoda questi presupposti si procede allidentificazione delle problematiche. 35 37. 4.2 Analisi dello scenarioPrendendo in considerazione il sopra descritto scenario ci si pufacilmente rendere conto delle enormi implicazioni gestionali di un simileprogetto, anche se fosse sviluppato da una singola azienda. Per iniziare adanalizzarne le problematiche infatti porremo proprio questa ipotesi, ovveroche solo una azienda si occupi del suo sviluppo per poi ampliare lapanoramica.Nonostante ci si ponga in un ambiente molto semplificato peranalizzare limpatto del problema, ci si rende immediatamente conto cheessendo preso in esame un progetto di ricerca e sviluppo su un temacommissionato, lo scopo non sar definito sufficientemente a priori. Proprioper questo sarebbe saggio stimare con la dovuta accortezza la duratapreventiva delle fasi del progetto, soprattutto quelle iniziali di analisi,dilatandone leggermente i tempi stimati per permettere di poter far fronte inmaniera meno incisiva a ridefinizioni dovute a sviluppi e/o a funzioniintrodotte in fasi successive. 36 38. Dato che i progetti di ricerca finanziati dallUnione Europea sonoindetti tramite un concorso fra gli sviluppatori, al suo interno sarannoproposte applicazioni tecnologiche innovative e soprattutto un utilizzo diprodotti hardware e software del tutto nuovi. Proprio questi potrebberorivelarsi una lama a doppio taglio, aumentando sicuramente il livello delprogetto di ricerca ma andando ad incidere significativamente sullonere dasostenere per il suo sviluppo. Alcune tecnologie nascenti infatti sono cosnuove da non esser state ancora assimilate, o nemmeno conosciute,allinterno dellazienda ove il costo diretto di produzione di un progettodipende largamente dalla preparazione e dalla cultura dei dipendenti.Inoltre capita frequentemente che i nuovi prodotti ancora mai utilizzatirealmente su vasta scala o allinterno di un progetto industrialesufficientemente elaborato per cercare di sfruttarne tutte le peculiarit, sianoaffetti da vari errori di funzionamento nelle versioni distribuite e necessitinoquindi di una vasta comunicazione fra azienda sviluppatrice e casa madreper la correzione.Queste considerazioni non sono necessariamente un danno per ilprogetto ma sicuramente ne aumentano il costo e rendono pi ardua la stimadei tempi necessari alle varie fasi del progetto. Spostandoci ora in una fase un po pi avanzata, si render importantedefinire degli standard per lorganizzazione dei contenuti e della forma deideliverables delle varie fasi, essendo un progetto internazionale, essicostituiranno le tappe e la prova dei progressi del lavoro non solo ai ProjectManager che lo dirigeranno ma probabilmente anche ad esaminatoridellUnione Europea ed ai responsabili delle aziende affiliate per il progetto.Proprio con questi soggetti infatti lazienda dovr periodicamenterelazionarsi per ottenere i requisiti e i chiarimenti necessari al correttoproseguimento della vita del progetto. Per fare ci infatti sar necessario del 37 39. personale qualificato sia per quanto riguarda il colloquio con gli altri soggettiesterni, sia per quanto riguarda la conoscenza dei vari paesi ove risiedono leaziende collaboratrici. Infatti una problematica da sempre riscontrata nellafase di analisi lomissione di dettagli di un certo peso per una correttaimpostazione del progetto poich il soggetto che deve descrivere il processoli ritiene cos scontati che dimentica di farne menzione nei colloqui. Tutto ci ovviamente accentuato dal fatto che lazienda sviluppatrice e quellacollaboratrice possono non essere connazionali andando cos a limitaresignificativamente quel margine di conoscenza che permette solitamenteallanalista, tramite domande mirate e lesperienza, di identificare edeliminare le sopradette omissioni. Incisive saranno quindi le competenzelinguistiche e culturali per potersi avvalere efficacemente delle collaborazionicon aziende estere. Bisogna ricordare che nonostante la tecnologia modernaci permetta di essere in contatto ventiquattro ore su ventiquattro con tutto ilmondo, certe questioni sia per un fatto diplomatico che da un punto di vistapratico sarebbero da risolvere di persona; il che risulta problematico data lapossibile lontananza geografica con determinati soggetti coinvolti nelprogetto. Per poter sviluppare alla massima efficienza un progetto sarebbenecessario poter utilizzare, di volta in volta, la metodologia pi congenialeed adattarla ad esso. In realt ogni azienda sviluppatrice di software ha unasua metodologia affermata che stata negli anni assorbita dal personale, conprecisi modi di lavorare che personalizza lazienda sia al suo interno chedallesterno. Questo metodo non ovviamente rigido ma viene adattato, conflessibilit propria di ogni azienda, al progetto in corso per permettere unaottimizzazione dei costi allazienda. Quindi presumibile che nonostante ilprogetto sia di ricerca, il suo cammino sar comunque aderente al modusoperandi dellazienda sviluppatrice. 38 40. Lattenzione ad altre procedure produttive di carattere pi scontatocome definizione del cammino critico delle varie sottofasi del progetto,lottimizzazione del tempo tramite una messa in parallelo delle stesseformando diversi workgroup e loro controllo tramite milestones; si daranno,per il momento, per pienamente efficienti ed assimilate dallaziendasviluppatrice. La stessa funzionalit dei deliverables per le fasi successiveper non del tutto scontata dato che si dovuto apporvi alcune modifichenella struttura e soprattutto nella lingua utilizzata per adoperarli, comemenzionato in precedenza, in ambito europeo. 4.3 ApprofondimentoConclusasi la prima fase di analisi dellimpatto del problema ora si pronti ad approfondire la struttura dellazienda sviluppatrice. Comepremesso nella descrizione dello scenario la realizzazione di tale progettonon affidata ad un unica azienda ma ad un insieme di aziende softwareaffiliate per tale scopo e da alcune aziende collaboratrici, che saranno poi iprimi utilizzatori dei piloti del progetto. La distribuzione in diversi paesi ditali soggetti implica un notevole incremento della difficolt di coordinazione,essa gi problematica di per se dato il numero delle aziende coinvolte.Quindi si proceda ad ampliare il soggetto analizzato in precedenza AziendaSviluppatrice considerando per invariato il rapporto fra essa e gli altrisoggetti come lUnione Europea e lapproccio alle nuove tecnologie.39 41. Si pu immediatamente identificare un vantaggio del nuovodiagramma, il problema menzionato in precedenza sui problemi deglianalisti nel colloquiare con aziende non connazionali e sulle relativeproblematiche dovute alla lontananza si possono affievolire o risolveregrazie alla disposizione di diversi partner dislocati in differenti paesieuropei. Per analizzando meglio la situazione ci si rende conto che ilproblema di comunicazione si spostato allinterno del gruppo sviluppatoredata la variet di partner presenti. Questo non dovrebbe costituire una gravecomplicanza rispetto alla situazione analizzata in precedenza poich ilproblema di comunicazione gi esposto con le aziende si affievolito e lastandardizzazione e linternalizzazione dei documenti interni allazienda(deliverables) era gi stata preventivata seppure per altre cause. Lungi dallessere risolto il problema di composizione eterogenea delgruppo sviluppatore che introdurr sicuramente altre problematiche, per lomeno per quanto riguarda la necessit di ridefinire i documenti interni si pudire che non ne aumenta la complessit gi preventivata.40 42. Si pensi ora alla composizione dei workgroup in unaziendasviluppatrice. Per favorire la produttivit si tende ad aggregare gli elementipi adatti ad un certo compito nello stesso gruppo per poi affidargli il ruolomigliore alle loro capacit. Se questo ragionamento si applica anche per unaazienda sviluppatrice risulta palese che si potr avere dei gruppi di lavoroeterogenei trasportando tutte le problematiche precedentemente sollevate alivello aziendale anche negli stessi workgroup. La risoluzione di tali problemi risulta concorde con i ragionamentiintrodotti in precedenza, ovvero la standardizzazione degli artefatti e unacollaborazione aperta mediante molti dei canali di comunicazione che latecnologia moderna mette a disposizione. Riferendosi alla struttura che abbiamo dato per scontata nella primaanalisi ci si deve necessariamente rende conto che ognuno dei partnercoinvolti avr una sua metodologia affermata e operativa al suo interno.Questa non necessariamente sar simile a quella di un altro qualsiasi partner.Generalmente la differente etnia provoca una grossa differenza del modo dipensare, della cultura e delle conoscenze gi su un singolo individuo quindinon cos astratto preventivare, pensando a livello aziendale, di trovarsi difronte ad almeno una differente metodologia per paese di dislocazione deipartner. La problematica legata al linguaggio ora amplificata dal numero disoggetti coinvolti. Scendendo nel dettaglio delle aziende infatti, nonostante lapercentuale di personale con una conoscenza dellinglese alquanto limitatasia molto bassa in una singola azienda, ci si accorge che deve per forzacontare un numero congruo di persone se applicata allintero gruppo disviluppo. Questo fatto pu portare a difficolt di alcuni workgroup di crearemateriale standard per le fasi successive. Il riscontrarsi di problemicomunicazione altrettanto plausibile ovviamente, nel caso sia necessario 41 43. colloquiare con altri workgroup non connazionali assegnati a sottofasirelazionate ad essi. Naturalmente non un problema di primaria importanzapoich con un minimo di collaborazione interna aziendale, un intelligentecreazione dei workgroup e assegnazione ai vari compiti la situazione arginabile. Comunque per implicher una maggiore attenzione in certe fasie una inadattabilit di una certa percentuale di personale a determinaticompiti, il che porta ovviamente ad un probabile aumento di tempo e denaroimpiegato nellorganizzazione del lavoro. Parlando ora di suddivisione del lavoro, per quanto riguarda unadistribuzione delle fasi lavorative ad un numero elevato di soggetti didevono ricordare le basi della ottimizzazione del lavoro. Infatti non dettoche pi persone si impiegano allo stesso progetto, maggiore sar laproduttivit del team; poich superata una certa soglia si comincia aspendere pi tempo per la comunicazione interna che per lo sviluppo insenso stretto. Tutto questo senza considerare che ogni soggetto coinvolto habisogno di un livello specifico di conoscenza dellavanzamento del progettogenerale, portando cos ad aumentare i tempi necessari alla comunicazioneinterna delle informazioni. Questo discorso si pu applicare sia al livello didettaglio esposto che riferito al numero di workgroup operativi in unprogetto. Spezzettando in troppe parti il lavoro si creano, a parte leproblematichegeneriche di comunicazione appenaaccennate, delledipendenze forzate dal lavoro altrui che non sempre permettono lo svolgersidel lavoro in parallelo delle attivit. Anzi esse probabilmente tendono aportare scompiglio, ritardi ed a periodi di improduttivit di alcuni deiworkgroup. Senza considerare che queste conseguenze si possonoripercuotereed amplificare notevolmentenel casole dipendenzeintercorrano fra gruppi di lavoro appartenenti a differenti partner (nonconnazionali). Per questo assolutamente necessario imporre uno standardanche sulle piccole fasi e non solo sui deliverables finali delle varie attivit. 42 44. Deve esserci omogeneit nei tool utilizzati per le varie attivit e se proprioci non risulta possibile a livello globale, almeno fra quelle attivit che sonoin relazione di dipendenza diretta. Essenziale per un progetto di queste dimensioni e per la quantit disoggetti coinvolti, realizzare che ogni partner una azienda a se stante che,anche se sta collaborando con le altre per il progetto, tender a dimostrare unsuo orgoglio aziendale, per cos dire. Questa problematica non banaleperch la base della collaborazione redditizia la non competitivit deipartner perlassegnazionedei compiti(la competitivit non necessariamente dannosa, anzi fa bene in molti altri ambiti fungendo dasprone per migliorare se stessi, la qualit e la velocit del lavoro). Per poter comprendere appieno le implicazioni del problema si deveanalizzare come avviene lassegnazione dei compiti in una struttura coscomplessa, come al solito partiamo da un livello generale e moltosemplificato del problema. Al fine di realizzare al meglio un progetto, la logica imporrebbe diassegnare le fasi pi critiche ai soggetti migliori e le fasi restanti ai gruppiqualificati in ordine di importanza delle varie attivit, invece il problemaandrebbe affrontato da un punto di vista inverso. Siccome la resistenza di unoggetto diretta funzione dellanello pi debole, sarebbe meglio assegnaread ogni gruppo lattivit che lui pu svolgere meglio rispetto tutte le altreattivit restanti. Applicando questo ragionamento per si viene a creare laproblematica accennata in precedenza. Se ogni team viene assegnato inquesta ottica non detto che a certe aziende arrivino incarichi appaganti oche dimostrino credibilit ed di importanza nella loro partecipazione alprogetto. Bisogna assolutamente sfasare questa sensazione mettendo inchiaro che ogni partner di egual importanza, anche se non di egual peso sulprogetto. Lobiettivo del gruppo di sviluppo non dimostrare quale sia lagerarchia di qualit delle aziende coinvolte, ma realizzare il prodotto meglio 43 45. possibile sfruttando tutti i partner coinvolti nel modo migliore per il finecollettivo. La risoluzione ideale per render appagati tutti del proprio operatoe della propria appartenenza al gruppo di sviluppo sarebbe unaassegnazione a rotazione delle attivit di maggiore importanza nelle varieiterazioni del progetto. Questo sarebbe nuovamente in contraddizione con ilmetodo di assegnazione suggerito. Come accade molto spesso nella pratica,si dimostra necessario considerare caso per caso ed applicare il punto diincontro fra i vari metodi produttivi e diplomatici per il bene della stabilitcomune. La quantit di problematiche sollevate semplicemente per strutturare illavoro necessario per leffettiva realizzazione del progetto suggerisce cheprobabilmente la dichiarazione della tempistica di progetto si rivelerinadeguata. Quasi ogni problema che stato analizzato, come dannocollaterale, apportava un aumento di tempo e del costo del lavoro e ci sonoprobabilit non nulle, proprio come in qualsiasi altro progetto, di incapparein errori non direttamente dipendenti dalle considerazioni da effettuate. Lapossibilit di un ritardo nei tempi molto alta e esso non sar da riferire altermine edotto dallUnione Europea ma da quello effettivo stimato delprogetto conclusasi completamente la fase di analisi. 44 46. 4.4 RiassumendoIn seguito allanalisi appena presentata, risultano essenziali molteprocedure nel complesso del progetto: Nel definire il progetto bisogna essere in grado di quantificare evalutare correttamente limpatto di tecnologie particolari sul processo disviluppo. Iniziare a formare il personale con largo anticipo e non durante ilprogetto sia ai fini linguistici che tecnologici necessari per una ottimaleadeguatezza della forza lavoro ai compiti imminenti. A fine di stimare la tempistica di progetto necessario collezionareinformazioni dettagliate non solo sulle aziende coinvolte, ma su tutti idipendenti che verranno impiegati al progetto e sui workgroup in cuioperano solitamente, naturalmente ad un livello di aggregazione dei datiadeguato (risulta ovvio che per il fine preposto non costituisce nessuna utilitsapere il nome o lindirizzo del soggetto in questione ma solamente le sueabilit, conoscenze ed attitudini lavorative). Definire in modo preciso e non ambiguo le relazioni (e mediante checanali) che intercorrono fra il gruppo di sviluppo e i soggetti esterni, come ivalutatori dellUnione Europea e i collaboratori delle aziende esterne.Importante definire inoltre le relazioni per la comunicazione fra i varipartner, creando molti canali di comunicazione e ben funzionantiassegnando ad essi personale adatto e qualificato. Siccome il progetto in esame un progetto di ricerca risulta adeguatodilatare opportunamente le tempistiche di alcune fasi e preventivare almenouna iterazione aggiuntiva per eventuali evoluzioni delle funzionalit e degliscopi del progetto. Il pessimismo nella stima caratteristica di capacit45 47. realistiche dellazienda e diminuisce il rischio di disillusioni per il protrarsidel termine di sviluppo. Inoltre nel qual caso tutto procedesse al meglio ci sitroverebbe ad aver ultimato il compito prima della scadenza dichiaratalasciando tempo per rifiniture successive del prodotto che aumentano lasoddisfazione finale del cliente ma che, nel caso di scadenze troppo brevi,non vengono attuate per la scarsa disponibilit di tempo. Definire di comune accordo fra i partner degli standard interni per lametodologia di sviluppo, la struttura e il contenuto dei deliverables, lafrequenza e la profondit dei controlli periodici di avanzamento del lavoro;ma soprattutto definire ad un livello sufficiente di dettaglio le sottofasi dellaAnalisi e della Progettazione indicandone subito le dipendenze al fine dievitare parallelismi impossibili. Lideale sarebbe ottenere un diagramma diGantt funzionale delle fasi di analisi e progettazione includendo, comeprecedentemente menzionato, le dilazioni opportune dei tempi e alcune fasiriparatorie per fornire un margine accettabile alle incertezze non meglioquantificabili ad inizio del progetto. Questo diagramma ovviamente non puessere assolutamente definitivo ma deve aiutare a programmare il lavoroevolvendo assieme alla precisa definizione del progetto. 46 48. 5. ApproccioLo sviluppo effettivo di un progetto di ricerca internazionale ecollaborativo sar estremamente complesso, specialmente dal punto di vistacoordinativo. Come stato visto dallanalisi delle problematiche principaliriscontrabili in questo tipo di progetto, la maggior parte delle difficoltsaranno per lappunto dovute alla distribuzione e al controllo dei compiti. I dettagli dei ponti di collegamento possibili fra le varie aziende edeventuali raccomandazioni su essi sono di scarsa importanza dal punto divista della metodologia a cui bisogner ricorrere. Questo poich il come si collabora influisce parzialmente sulle fasi daintraprendere e dagli artefatti da realizzare, al pi implicher delle restrizionisulla lingua utilizzata o sulle tempistiche di produzione. Lo stesso discorso applicabile anche alle problematiche di stima deitempi di progetto, il fatto che il tempo previsto subisca dei dilatamentidovuti alla struttura dellazienda sviluppatrice non sar direttamenteimputabile alla metodologia applicata bens alla complessit della struttura.Infatti si pu affermare che, qualsiasi sia il metodo di lavoro scelto, laprobabilit di un ritardo comunque stabile e principalmente dipendentedallorganizzazione su cui viene applicato tale metodo. Lunica problematica rimanente quindi la presenza di differenticompetenze distribuite allinterno delle varie aziende affiliate e dei gruppi dilavoro. Ci porta ad un bivio di entit notevole, o si opera una pesanteistruzione del personale per eliminare il problema o si attua una modificadella metodologia al fine di poter essere approcciata anche da chi ha scarsenozioni in tale materia. 47 49. La situazione ideale prevedrebbe ovviamente il colmare le lacune delpersonale, investendo cos sui propri dipendenti ed aumentando il valoredella propria azienda. Ma una manovra del genere nella pratica estremamente difficile, specialmente data la natura internazionale delprogetto in esame. Daltro canto un livellamento troppo drastico di una qualsiasimetodologia otterrebbe s un facile assorbimento dal personale noncompetente, ma comporterebbe senza ombra di dubbio degli effetti negativienormi sul prodotto finale. A seguito di queste ultime considerazioni si deve prendere atto cheluna o laltra via non sono percorribili nella realt di un progettointernazionale, a parte rari casi. In generale quindi lapproccio applicabileconsisterebbe in uno snellimento di una metodologia molto versatile, al finedi poter effettuare con un buon livello di dettaglio le fasi principali previobreve istruzione del personale. Alcune fasi o artefatti delle metodologie diprogetto infatti non sono particolarmente complesse e un dipendente mediopu riuscire a svolgerle con successo senza particolari preparazioni, ma consicuramente lausilio di una buona documentazione. Data la necessit diflessibilit e di segmentazione necessarie ad una metodologia per poteressere snellita in modo proficuo al fine preposto, si prender inconsiderazione lapproccio iterativo ed incrementale messo a disposizionedal Rational Unified Process. Esso infatti risulta essere un metodoincredibilmente ampio e versatile, proprio per sua costruzione, e quindiperfettamente aderente al problema in esame. Lobiettivo quindi propriolidentificazione di una fetta del RUP che calzi con il progetto in lavoro,ovvero trovare una buona guida metodologica per permettere una buonaorganizzazione e resa lavorativa.48 50. Inserendo questo lavoro in un progetto di ricerca gi avviato da diversianni come Euridice, risulta difficoltoso estendere questa procedurasullintera metodologia. Inoltre un tale compito risulterebbe di difficolt benpi elevata e sicuramente laprirsi di una discussione generale sullosnellimento del RUP in tutte le sue fasi per lapplicazione a progetti del tiposopraesposto comporterebbe discussioni pressoch infinite nellambitoanalistico. Rifacendosi alle spiegazioni del metodo menzionate nel capitoloapposito presentiamo a seguire una figura esplicativa della struttura diuniterazione prevista dal metodo RUP applicata ad Euridice.Come visibile nella figura, le fasi iniziali sono state scomposte edettagliate per fornire maggiore dettaglio. Inoltre si pu osservare che sonostate utilizzate le nomenclature tipiche dellUnified Modeling Language. Perla fase di analisi si applicato ovviamente la Use Case Analysis o Analisi percasi duso. 49 51. Lo sviluppo di Euridice era per lappunto giunto alla conclusione dellafase di analisi. Sar ora necessario cimentarsi nella fase di progettazione, chenel caso specifico includer la realizzazione dei casi duso definiti nella fasedi analisi. Lo scopo quindi quello di identificare il numero minimo diartefatti necessari ad una completa progettazione, seguendo il metodo dellarealizzazione dei casi duso facendo riferimento al linguaggio UML.50 52. 5.1 Guida Metodologica alla progettazione Vengono di seguito descritti brevemente i fondamenti necessari allacomprensione degli artefatti risultanti dalla fase di analisi per poter poiproseguire correttamente nella progettazione.Essendo la realizzazione dei casi duso tramite diagrammi UML unapproccio visuale alla progettazione degli stessi, esiste un vasto numero dimodi per procedere. Inevitabilmente lavorando in modo visuale si pucogliere il sistema in esame da un solo punto di vista, quindi scontato chesaranno necessari vari diagrammi per una rappresentazione completa delcaso.Verr reso necessario e quindi descritto il minor numero possibile didiagrammi cercando comunque di mantenere una completa definizione nellarealizzazione del caso duso. Inoltre il metodo UML mette talvolta adisposizione pi diagrammi che rappresentano lo stesso concetto ma inmaniere differenti. In caso tale punto di vista sia rivesta fondamentaleimportanza nella definizione della UCR allora si propender per queldiagramma pi semplicemente sviluppabile.Use Case I casi duso costituiscono un ottimo strumento per ottenere una visionedinsieme delsistema che si sta analizzando, rappresentano uncomportamento dal punto di vista dellutilizzatore del sistema e sonofinalizzati a modellare il dialogo tra utilizzatore e sistema. Per questo si diceche i casi duso forniscono una visione del progetto. Infatti essi: descrivono linterazione fra attori e sistema, non la logica interna della funzione;51 53. sono espressi in linguaggio naturale e sono comprensibili anche alettori non tecnici; descrivendo i casi duso si definiscono i requisiti funzionali diprogetto; possono essere un valido ausilio nel dialogo con lutente ed ingenerale con esponenti non tecnici; Lattore unentit esterna al sistema, pu essere umano o un altrosistema, che fornisce lo stimolo a cui esso risponde con specificicomportamenti. Tutto ci definito nella Analisi dei casi duso che siconclude quando la maggior parte dei casi duso stata descritta. Per ognuno di essi devono essere stati definiti: precondizioni, attoricoinvolti, obiettivi, svolgimento principale degli eventi dello scenario,svolgimenti alternativi e post condizioni.Nella fase di design si dovr prendere in considerazione quindi questicasi duso e delle loro descrizioni, che sono il risultato della fase di analisi, ediniziare a definirli prendendo in considerazione anche i requisiti tecnologiciche vengono scelti per il progetto. 52 54. Lo scopo essenziale chiarire come gli attori interloquiscano con i varicasi duso e di che dati abbiamo effettivamente bisogno per operare. Alloscopo di fare ci si tender per un approccio visuale utilizzando lo standardUML anchese sarnecessarioallegare comunqueunabuonadocumentazione scritta. Use Case Realization La realizzazione dei casi duso, o UCR, rappresenta la prospettiva dellaprogettazione dei casi duso derivati dalla fase di analisi. Ogni artefattoprodotto durante la fase di design andrebbe associato al caso duso da essoanalizzato, ma proprio per poter disaccoppiare la fase di analisi da quella didesign si introduce il concetto di UCR.Siccome nella fase di design si deve tener conto dei vincoli tecnologici sipu intuire che un singolo caso duso pu essere progettato in pi modidiversi. Quindi possono esistere diversi UCR associati allo stesso caso duso,e siccome gli artefatti della fase di design vengono di conseguenza associatiallo specifico UCR si facilit la gestione separata degli use case realizzatinella fase di analisi dalla loro realizzazione.Questa strategia particolarmente indicata per progetti di grandidimensione ove lo stesso caso duso pu essere progettato in modo diversoper la necessit del suo utilizzo su diverse piattaforme.Per rappresentare tutto ci si utilizza un diagramma della realizzazionedei casi duso sar semplicemente sufficiente trattare ogni UCR come unageneralizzazione dei caso duso con una notazione del tipo UC UCR come 53 55. visibile nella figura successiva. Per ogni UCR necessario identificare gli oggetti che partecipano allacomposizione del caso duso. Al fine di descrivere completamente un casoduso il linguaggio UML mette a disposizione una grande variet didiagrammi. Lo scopo di questa fase di identificare per ogni UCR tutti glielementi statici e dinamici coinvolti.Gli elementi statici di un oggetto sono i dati persistenti di cui necessitaper operare e le relazioni che lo legano ad altri oggetti. Gli elementi dinamiciinvece possono essere descritti come le modalit di collaborazione fra oggettiper realizzare una determinata funzione.Evidenziamo anzitutto tre tipi di oggetti e loro notazione in UML: Entit che rappresentano i dati persistenti di cui necessita lo UC Interfacce sono oggetti necessari per il corretto dialogo con elementi esterni (input/output) Controlli che rappresentano la logica di business del sistemaPer ogni use case realization si dovranno evidenziare almeno treoggetti: unEntit, uninterfaccia e un controllo. 54 56. La figura seguente mostra un diagramma per la realizzazione di uncaso duso Receive Deposit Item, si pu notare che il livello di descrizione molto alto e serve quindi solo ad identificare gli oggetti coinvolti. Unaclasse e i suoi oggetti possono spesso partecipare a svariate realizzazionidifferenti di un caso duso.Definendo gli UCR probabilmente si nota che alcuni oggetti vengonoimpiegati in un numero elevato di casi. consigliato dunque controllarecome un oggetto debba essere realmente strutturato per favorirne lariusabilit attraverso i vari UCR. I diagrammi pi importanti per la corretta realizzazione dei casi dusosono i seguenti: Sequence Diagram : descrive un preciso scenario di un caso duso seguendone la linea temporale Class Diagram : evidenzia i contenuti statici del caso duso State Diagram : analizza il comportamento e la vita di un oggetto attraverso tutti i casi duso che lo utilizzano Nelledescrizioniseguenti verranno fornite delle sempliciesemplificazioni di ogni tipo di diagramma per permetterne una pi rapidacomprensione. Inoltre nel Capitolo 6 verranno applicati praticamente ad un 55 57. caso duso di Euridice fornendo un ulteriore approfondimento al metodi disviluppo dei sopra esposti diagrammi. 56 58. Diagrammi di SequenzaIl diagramma di sequenza rientra negli Iteration Diagrams. Lobiettivodi questa categoria di diagrammi descrivere come un gruppo di oggetticooperi per realizzare una funzione. Nello specifico del Sequence diagram, esso analizza un singolosvolgimento del caso duso (principale o alternativo) e il modo in cui vienesvolto dalla collaborazione tra un insieme di oggetti, specificando lasequenza dei messaggi scambiati tra gli stessi. Possono essere evidenziatinodi decisionali e/o iterazioni. Questo tipo di diagramma viene anche detto di interazione in quantomostra le interazioni tra oggetti del sistema, modella il comportamentodinamico del sistema ed evidenzia in particolare lordine temporale delloscambio di messaggi. Tutti i tipi di oggetto che vengono richiamati per svolgere linterazionedevono essere rappresentati da un riquadro nella parte superiore deldiagramma. Le linee verticali rappresentano la linea della vita, o lifeline, delloggettosuo proprietario nellarco di durata dellinterazione. Per mostrare quando un oggetto attivo si include un riquadro diattivazione che viene riportato sulla sua lifeline. Quando un oggetto viene eliminato si appone una X sul puntotemporalmente corretto e si interrompe la sua lifeline. Tutti i messaggi scambiati fra due oggetti durante la loro vita sonorappresentati da una freccia del tipo sorgentedestinatario e per ognuna diloro deve essere indicato almeno il nome di tale messaggio. Possono poiessere presenti messaggi prodotti dallo stesso oggetto che ne il destinatario,essi si chiamano self-call. Importante sottolineare che nonostante la notazione 57 59. del messaggio, esso rappresenta la chiamata del sorgente ad una funzionedel destinatario. I messaggi possono essere fondamentalmente di due tipi: Sincronolemittente attende una risposta da parte del destinatario Asincronola risposta del ricevente, se contemplata, potr essere inviata in unqualsiasi momento successivo Se un messaggio ha una condizione per il suo invio si parla dimessaggio condizionato e viene rappresentato tramite la specifica inparentesi quadre della sua condizione di invio. Questi messaggi vengonoinviati quindi solo se al percorri mento temporale sulla lifeline delloggettotale requisito soddisfatto nel superamento del messaggio condizionato. Per indicare una iterazione di un messaggio si indica allinizio del nomedello stesso un * , questo star a significare che il messaggio in questioneviene inviato pi volte a pi oggetti che per rientrano nella stessa categoria.58 60. Generalmente si consiglia lutilizzo di descrizioni testuali sulla partesinistra del diagramma in tutti gli snodi principali per favorirne la leggibilit.Diagrammi delle Classi Lobiettivo dei diagrammi delle classi visualizzare la parte statica delsistema rappresentando tutti gli oggetti, con i relativi attributi ed operazioni,che lo compongono. I collegamenti fra le classi rappresentano le associazioni cheintercorrono fra esse. Tali associazioni possono essere corredate da uninsieme di informazioni aggiuntive, per esempio relative alla molteplicit: Uno-a-uno ad ogni occorrenza delloggetto A si pu associare univocamente unoccorrenza delloggetto B e viceversa; (Es dipendentematricola) Uno-a-Molti per ogni occorrenza delloggetto B si pu associarne una sola delloggetto A, ma per ognuna delloggetto A possono essercene un qualsiasinumerodelloggettoBassociate;(EsProject ManagerProgetto) Molti-a-Molti: per ogni occorrenza delloggetto A si possono associare pi occorrenze delloggetto B e viceversa; (Es deliverableautore) consigliato inserire una nomenclatura alle associazioni la dove cifavorisca una maggiore leggibilit al diagramma. 59 61. Questi diagrammi utilizzano diversi concetti base del paradigmaObject-Oriented ed altri correlati, fra questi se ne distingueranno perimportanza quattro: Aggregazione,Composizione,DipendenzaeGeneralizzazione. Ognuna delle sopra citate viene rappresentata medianteuna particolare freccia che connette le due classi coinvolte. Laggregazione un particolare tipo di associazione che prevede unarelazione fra delle entit autonome ed una che pu essere definita solo dalla,per lappunto, aggregazione di esse. Un buon esempio risulta un automobile:essa composta dallaggregazione di carrozzeria, motore, ruote e cos via. La composizione una relazione forte, pu essere descritta in manierasimilare allaggregazione con la differenza che le entit che vengono messe inrelazione di composizione seguono poi il ciclo di vita dellistanza composta.Importante sottolineare che ogni oggetto pu essere componente di un solooggetto composto alla volta, il che differisce palesemente dallesempioutilizzato in precedenza dellautomobile; ove per esempio un motore puessere montato su pi tipi di auto. Una associazione di dipendenza sta ad indicare che un cambiamento diun attributo di una classe pu andare richiedere modifiche negli attributidellaltra, non necessariamente implicato il viceversa. Alcune classi possono avere diverse varianti, ed ogni variante puavere diversi ruoli nel sistema. Per rendere tutto ci rappresentabile in undiagramma delle classi si ricorre al concetto di generalizzazione. Essa siindica con una freccia del tipo sottoclasse sopraclasse come si pu vederenella figura seguente per LibroPregiato che specifica loggetto Libro. Ilsignificato di tale azione e della notazione sono sufficientemente espliciti danon richiedere ulteriori dilunga menti in proposito. 60 62. Ogni oggetto viene rappresentato tramite un rettangolo suddiviso in trescomparti, rispettivamente dedicati al nome della classe, agli attributi e alleoperazioni. La visibilit di ogni attributo e di ogni operazione specificata in UMLattraverso l'uso di vari simboli: - visibilit privata: l'attributo accessibile solo dall'interno della classe usando i propri metodi; + visibilit privata:l'attributo o il metodo accessibile anche dall'esterno; # visibilit protetta: l'attributo o il metodo viene ereditato da tutte le classi da questa derivate.61 63. Gli attributi devono essere indicati per nome con eventualmente il tipoe il valore di default seguendo il seguente standard: nome_visibile : tipo = valore_default Es autore_anno_morte : data = Null Lelenco delle operazioni evidenziate in questo diagramma rappresentalinsieme delle principali operazioni eseguibili allinterno dello UCR.Importante specificare che non tutte le operazioni delle classi hanno lostesso impatto sul sistema. Infatti risulta estremamente utile distinguere lesemplici query (operazioni sugli attributi) da quelle operazioni che vanno amodificarli (operazioni di update).La sintassi completa per la descrizione delle operazioni in UML laseguente: nome_visibile ( lista parametri ) : tipo_risultato_op {propriet} Es libro_pregiato_valorizza ( ) : float { } 62 64. Diagrammi di Stato utile utilizzare il diagramma di stato per evidenziare come sicomporta un oggetto attraverso pi casi duso, esso infatti specifica tutto ilciclo di vita di tale oggetto e definisce le regole che ne governano letransizioni di stato. Risulta chiaro dunque descrivere questo tipo di diagramma come unautoma a stati finiti, pertanto esso sar costituito da stati, attivit etransizioni. Quando un oggetto in un certo stato infatti, solo determinati eventicauseranno una transizione di stato e non tutti. Viene utilizzatoprincipalmente come completamento della descrizione degli oggetti. Data lasua natura specifica non risulta sempre naturale svilupparlo correttamente epu sembrare non sempre utile al procedere del lavoro, infatti direttamentedipendente del progetto quali diagrammi siano pi o meno efficaci perprocedere.63 65. Il punto di partenza chiaramente indicato nel digramma, cos comeogni stato collocato in un riquadro con allinterno il suo nome ed eventualiattivit ad esso associato. Ogni transizione graficamente indicata da una freccia che devepresentare la cos detta guardia dellazione, ovvero una condizione chesolamente se risulta essere vera mette in opera la transizione di stato. Nullavieta di mettere in evidenza self-transition importanti che bench nondeterminino un cambiamento di stato possono stare ad indicare particolarioperazioni periodiche di controllo o comunque degne di nota ai finiprogettuali. Importante in questi diagrammi mettere in evidenza eventuali statimorti, ovvero quegli stati che presentano una o pi transizioni in ingressoma nessuna in uscita. Inoltre possono essere dichiarate Super-stati, chevengono rappresentati da un riquadro che include tutti gli stati che ne fannoparte. Questa tecnica utile per introdurre eventuali controlli aggiuntivi. Peresempio essi possono essere temporali, nel caso si voglia intraprendereunazione al decorrere di un certo periodo senza il verificarsi di uncambiamento di stato, o condizionali quando si vogliono effettuare deicontrolli pi specifici. Poniamo un esempio con riferimento allimmagine precedente:evidenziando un superstato In Movimento andando ad inglobare gli statiascesa al piano e scesa al piano possiamo notare che abbiamo solo duetipi di transizioni, ovvero richiesta piano e raggiungimento piano. Seponiamo un controllo di tipo temporale su questa superclasse del tipo after ( [tempo di percorrenza di un piano]*{[numero piani]+1} )possiamo inserire una transizione che ponga ad esempio il sistema in statomorto di Guasto. 64 66. Diagrammi di Collaborazione Il diagrammi di collaborazione, come il diagrammi di sequenza,rientrano nella categoria dei diagrammi di interazione. Essi mirano amostrare le collaborazioni e le interazioni tra le istanze specifiche cherealizzano i casi duso. Questo tipo di diagramma, in particolare, specifica gli oggetti checollaborano tra loro in un certo scenario ed enfatizza le relazioni strutturalitra gli oggetti; quindi sono utilissimi per la fase di analisi e di design,sopratutto per creare una bozza di una collaborazione tra gli oggetti. Diagrammi di collaborazione e diagrammi di sequenza sonoeffettivamente molto simili. Infatti si pu passare agevolmente dallunaallaltra rappresentazione e si differenziano per laspetto dellinterazione cheenfatizzano. Nei diagrammi di sequenza il concetto fondamentale levoluzionetemporale del singolo caso duso attraverso gli oggetti coinvolti, mentre neidiagrammi di collaborazione vengono evidenziati i legami tra gli oggetti.Risulta quindi semplice utilizzare questa rappresentazione per definire unascomposizione funzionale degli oggetti implicati, ad esempio la definizionedi packages. Per tracciare correttamente un diagramma di collaborazione vengonorappresentati tutti gli oggetti coinvolti tramite dei riquadri contenenti i loronomi. Ogni messaggio viene rappresentato da una freccia con terminazionedipendente se il mittente attender la risposta in tempo reale