• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Progetto Euridice
 

Progetto Euridice

on

  • 1,032 views

Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione

Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione

Statistics

Views

Total Views
1,032
Views on SlideShare
1,032
Embed Views
0

Actions

Likes
0
Downloads
8
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Progetto Euridice Progetto Euridice Document Transcript

    • UNIVERSITA’ DEGLI STUDI DI TRIESTE FACOLTA’ DI INGEGNERIA CORSO DI LAUREA TRIENNALE IN INGEGNERIA INFORMATICA TESI DI LAUREA IN SISTEMI INFORMATIVI PROGETTO EURIDICE: IDENTIFICAZIONE ED APPLICAZIONE DELLA METODOLOGIA DI PROGETTAZIONE Relatore Laureando Chiar.mo Prof. Fulvio Sbroiavacca Stefano Costanzo Correlatrice Dott.ssa Forcolin Margherita Anno accademico 2008 – 2009
    • Sommario Introduzione ....................................................................................................... 2 1. Storia dell’ingegneria del software ................................................................ 4 1.1 Ingegneria del Software ............................................................................. 6 2. Ciclo di Vita del Software................................................................................ 8 2.1 Processi di sviluppo software ................................................................... 12 2.2 Metodologie.............................................................................................. 13 3. Rational Unified Process ............................................................................... 24 3.1 Le fasi del RUP ........................................................................................ 29 3.2 Aspetti statici del RUP ............................................................................ 32 4. Identificazione delle problematiche di progetto.......................................... 34 4.1 EURIDICE .............................................................................................. 34 4.2 Analisi dello scenario ............................................................................... 36 4.3 Approfondimento ..................................................................................... 39 4.4 Riassumendo ............................................................................................45 5. Approccio...................................................................................................... 47 5.1 Guida Metodologica alla progettazione ................................................... 51 6. Progettazione di un Caso d’uso .................................................................... 69 6.1 Considerazioni generali sulla realizzazione di un caso d’uso.................. 73 6.2 Progettazione esemplificativa del Caso d’uso WP26.P2.UC3.2 .............. 75 6.2.1 Diagramma di sequenza del Flusso principale ................................. 80 6.2.2 Diagramma delle classi del Flusso Principale ................................... 84 6.2.3 Approfondimento del Notify Management ..................................... 86 6.2.4 Diagramma delle Classi WP26.P2.UCR 3.2 Prova ............................ 93 Conclusioni e Discussione................................................................................. 96 1
    • Introduzione Il qui presente lavoro di tesi triennale in Ingegneria Informatica si colloca nel contesto del progetto europeo, già in carico alla società Insiel S.p.a., EURIDICE (EURopean Inter-Disciplinary research on Intelligent Cargo for Efficient, safe and environment-friendly logistics) cofinanziato dalla Commissione Europea nell’ambito del Settimo Programma Quadro (Seventh Framework Programme -FP71) . EURIDICE è un progetto di Ricerca che coinvolge 22 partner provenienti da 9 paesi europei che collaborano con la finalità di implementare il concetto di Cargo Intelligente, si tratta quindi di un progetto di logistica che prevede sia la realizzazione della struttura essenziale che la concreta dimostrazione della fattibilità degli obiettivi di progetto. All’inizio di questo lavoro di tesi, nel progetto, si era giunti alla conclusione della fase di analisi e quindi si doveva iniziare la fase progettazione o design. Obiettivo di questa tesi è dettagliare la metodologia di progettazione considerando le caratteristiche di un progetto collaborativo internazionale e fornire le linee guida per il design. A tal proposito è necessario inquadrare le problematiche inerenti lo sviluppo di un progetto distribuito fra un gran numero di partner dislocati in vari paesi europei, quindi verificarne l’impatto allo specifico punto di progresso del progetto ed individuare il metodo di lavoro ed infine produrre una guida operativa a supporto della corrente fase di progettazione 1 http://cordis.europa.eu/fp7/home_en.html 2
    • corredata da un esempio pratico, ovvero la progettazione completa di un reale Use Case del progetto Euridice. Il lavoro di tesi è stato suddiviso in sei capitoli. Il primo capitolo introduce la materia di interesse, ripercorrendo brevemente la storia dell’ingegneria del software fino alla odierna definizione. Nel secondo capitolo si descrive accuratamente il concetto fondamentale di ciclo di vita del software, esponendo come esso sia composto e i principali tipi di modelli applicati allo sviluppo dei progetti software. All’interno del terzo capitolo si espone il modello di un processo software iterativo sviluppato da Rational Software cioè il Rational Unified Process. Esso riveste una fondamentale importanza nell’odierna visione della produzione dei progetti software. Il quarto capitolo presenta Euridice ed analizza in fasi successive le problematiche sollevate da un progetto internazionale collaborativo per l’organizzazione del lavoro. Nel quinto capitolo si delinea l’effettivo impatto delle problematiche sollevate nella precedente analisi e si definisce un metodo di lavoro per la progettazione. Infine il sesto capitolo si compone della effettiva realizzazione di un caso d’uso ovvero della esemplificazione pratica del metodo di progettazione scelto ad un segmento dei risultati della fase di analisi. 3
    • 1. Storia dell’ingegneria del software L’esigenza di creare una disciplina che si occupasse dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software si comincia a sentire attorno alla fine degli anni sessanta. Nasce difatti la necessità di sviluppare prodotti sempre più complessi ed evoluti che rispondano alle richieste delle grandi utenze. Più precisamente dal 1950 al 1965 lo sviluppo del software personale era alquanto limitato: tutti i programmi venivano sviluppati in batch2, gli informatici erano pochi ed apprendevano direttamente sul campo. Ciò che veniva sviluppato era pensato per un unico cliente o talvolta addirittura per una unica macchina. Inoltre era comune che ad ogni progetto lavorasse e continuasse a lavorare una sola persona, senza però richiedere che venisse scritta alcuna forma di documentazione. Fino alla nascita dell'ingegneria del software, la realizzazione di prodotti software consisteva soprattutto nel mettere insieme una sequenza di istruzioni di codice per realizzare compiti ben specifici. Dal 1965 al 1975 si assiste allo sviluppo di software pensato per più utenti e per dei sistemi particolari per i quali la correttezza del risultato dipende anche dal tempo di risposta. Inserendo quindi un limite temporale 2 Il termine batch risale all'epoca della programmazione per schede perforate. In quel contesto, i programmatori solitamente non avevano accesso diretto al computer, bensì preparavano i propri programmi "off-line" e li passavano a un amministratore di sistema, il quale aveva il compito di mandarli in esecuzione quando possibile (accodandoli rispetto ad altri programmi in esecuzione e spesso accorpando più programmi in un'unica unità di esecuzione), restituendo poi in seguito i risultati dell'elaborazione agli interessati. 4
    • ad un sistema informatico nasce una famiglia di programmi che devono rispondere ad eventi esterni entro tempi prestabiliti, nasce il concetto di real- time. Nel 1968 la conferenza NATO tenuta a Garmisch, in Germania, rende chiaro il problema rappresentato dall'incapacità di produrre nei tempi previsti software affidabile e rispondente ai requisiti. A partire dal 1972 e fino al 1988 vengono introdotte nuove tecnologie, nascono i sistemi distribuiti e si afferma la figura specializzata del sistemista informatico. Il costo dell'hardware si abbassa considerevolmente e di conseguenza la tecnologia informatica comincia a diffondersi rapidamente. Organizzazioni come il Pentagono spingono fortemente lo studio di modelli che permettano di minimizzare la quantità di errori all'interno dei software. Il livello qualitativo del software si eleva, si tende a controllare lo sviluppo del software cercando di sviluppare prodotti di qualità a causa della concorrenza affermatasi tra le software house. Con l'introduzione delle tecnologie informatiche anche nel settore industriale e commerciale, bacini di utenza non più tecniche sentono l'esigenza di informatizzare le proprie strutture. Il cambiamento del tipo di utenza genera l’esigenza di curare l'interfaccia grafica presentata all'utente per renderne più intuitivo l’utilizzo. Il software come prodotto industriale diventa anche oggetto di un attento esame per estendere le capacità di realizzazione dello stesso. Nasce in pratica un concetto simile alle ottimizzazioni da catena di montaggio per le industrie del secolo scorso che avevano similmente stravolto il modo di produrre apparecchiature meccaniche. 5
    • 1.1 Ingegneria del Software Per software engineering si intende quella disciplina che si occupa dei processi produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi software. L'ingegneria del software si propone degli obiettivi legati all'evoluzione dello sviluppo del software, inteso come attività industriale, sia da un punto di vista tecnologico (per esempio attraverso la definizione di nuovi linguaggi di programmazione) che metodologico (per esempio il perfezionamento dei modelli di ciclo di vita del software). Essa identifica quindi una formalizzazione del processo di realizzazione e di manutenzione di un sistema informativo. Si parla quindi di ciclo di vita3 del software, disciplina che comprende e regolamenta tutte le fasi di un prodotto dalla sua ideazione e realizzazione fino alla conduzione e infine dismissione. Il concetto di qualità viene applicato anche a questa disciplina vista la necessità di rilasciare un prodotto perfettamente funzionante, documentato e facilmente manutenibile. Per qualità del software si intende la misura in cui un prodotto software soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia alla sua struttura interna. Per rendere valutabile ciò vengono introdotte due famiglie di parametri: esterni ed interni. I primi si riferiscono alla qualità del software così come è percepita dai suoi utenti, e includono correttezza, affidabilità, efficienza, usabilità. I secondi si riferiscono alla qualità del 3 L'espressione ciclo di vita del software si riferisce alla scomposizione di attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato finale è il prodotto stesso e tutta la documentazione a esso associata. 6
    • 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 l’insieme di processi, ovvero sequenze di fasi per la realizzazione di un sistema software, tutte documentate e ispezionabili, che permettano di realizzare prodotti sempre più evoluti e di qualità. 7
    • 2. Ciclo di Vita del Software Il concetto di ciclo di vita e di processo software coincide con la nascita dell'ingegneria del software, in quanto rappresenta un passaggio storico dallo sviluppo del software inteso come attività artigianale, ovvero affidata alla libera creatività dei singoli individui, a un approccio più industriale, in cui la creazione di programmi e sistemi software viene considerata come un processo complesso che richiede pianificazione, controllo, e documentazione appropriati. L'espressione ciclo di vita del software si riferisce al modo in cui una metodologia di sviluppo o un modello di processo scompongono l'attività di realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato 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 l’indagine 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
    • • 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 l’analisi ha lo scopo di definire, il più precisamente possibile, il problema. Questa fase è svolta essenzialmente grazie alla raccolta delle informazioni attraverso colloqui con il cliente. L’attività di analisi si conclude con la produzione di un documento che descrive in modo preciso, ma comprensibile al cliente, ciò che farà il sistema, tale documento viene definito “Documento dei requisiti”. nella fase di progettazione, in funzione dei requisiti evidenziati dall'analisi, si definisce la struttura del sistema da realizzare. Anche questa 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 e non funzionali. Le prime 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 definita 9
    • 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 la realizzazione concreta del sistema; questa tipicamente consiste nella realizzazione dei vari moduli costituenti. Nella maggior parte dei casi è possibile distinguere almeno due sottoattività per i singoli moduli che costituiscono il sistema: Codifica e Verifica. Complessivamente si tratta di una fase piuttosto tecnica, tutte le decisioni principali sono state prese nelle fasi precedenti; la fase di collaudo, è volta a misurare in che modo il sistema realizzato soddisfa i requisiti stabiliti nella fase di analisi, ovvero a valutarne la correttezza rispetto alle specifiche. Quando ogni modulo è individualmente corretto si passa all’integrazione dei moduli. Viene quindi testato il sistema complessivo: viene confrontato il documento delle specifiche funzionali e non funzionali (“Are we building the product right?”). Quando il sistema si comporta in accordo con il documento delle specifiche, si passa all’installazione dello stesso nel suo ambiente e si procede al collaudo. Il collaudo comprova da parte dell’utente che il prodotto soddisfa i suoi bisogni ed obiettivi. A questo scopo si confronta il sistema con il documento dei requisiti (“Are we building the right product?”); la fase di manutenzione, che comprende tutte le attività di modifica del software successive al suo rilascio presso il cliente o la sua immissione sul 10
    • 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 la documentazione dei prodotti delle varie sottoattività. 11
    • 2.1 Processi di sviluppo software La 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 per esprimere le caratteristiche di progetto, mentre il processo è una serie di passi, una sorta di elenco che aiuti ad ottenere risultati di alta qualità in un tempo prefissato. Il processo software è composto da alcune attività che rappresentano un insieme di compiti da svolgere per sviluppare un software: Attività portanti: una serie di 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 alla modifica di un software, adottano necessariamente un certo approccio nel modo di relazionarsi con i propri clienti, nell'organizzare il proprio lavoro, nella scelta delle tecniche da utilizzare. In modo consapevole o meno, ogni sviluppatore o gruppo di sviluppatori software ha un proprio processo di sviluppo, esso è definito dal proprio modo di lavorare, basato sulla propria esperienza, sulla propria cultura, e sul contesto culturale ed organizzativo in cui si trova ad operare. La storia dei successi e degli insuccessi dei progetti di sviluppo software ha insegnato che ogni processo di sviluppo ha i propri pregi ed i propri limiti. E che un processo di sviluppo inadeguato alle concrete esigenze dello specifico progetto può condurre al fallimento del progetto stesso, o comunque all'insoddisfazione dei clienti e degli stessi sviluppatori. 12
    • 2.2 Metodologie Nel campo delle scienze esatte un modello è una formalizzazione precisa della una realtà mediante equazioni matematiche. Nello sviluppo del software, il modello è chiaramente meno preciso, ma comunque l’applicazione di un modello, magari impreciso ma aderente al caso, è pur sempre preferibile alla non applicazione di un modello. Questa affermazione è particolarmente evidente per lo sviluppo di progetti software, a tal riguardo nel tempo si sono affermate numerose e diverse metodologie per rispondere al progresso tecnologico e al conseguente modificarsi delle potenzialità del software. Vediamo ora alcune diverse tipologie di modelli: Modello a cascata Questo modello è caratterizzato da un rigida suddivisione in passi sequenziali ognuno dei quali definisce una attività che opera su un insieme di ben definiti input e produce determinati output che serviranno come input della fase successiva. Importante sottolineare che viene regolamentata la documentazione delle varie fasi del processo. Il modello a cascata tradizionale prevede le seguenti fasi: studio di fattibilità: ha lo scopo di determinare se intraprendere lo sviluppo 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à quanto stabilito nella prima fase, e in particolare la sua suddivisione in moduli e le relazioni fra di essi; 13
    • sviluppo o codifica: creazione dei moduli con un linguaggio di programmazione; collaudo: esecuzione di 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 può essere ridefinito in molti modi, inoltre un'organizzazione può formalizzare ulteriormente il processo definendo standard e imponendo vincoli per quanto riguarda la natura, il formato, la struttura e i contenuti dei documenti prodotti nelle varie fasi, tipicamente allo scopo di consentire un controllo più rigoroso sullo stato di avanzamento del progetto e sulla qualità del lavoro svolto. Il modello ha giocato un ruolo importante nello sviluppo del software per superare i limiti del processo del “code and fix” e infine ha fissato due concetti: • Il processo di sviluppo del software deve essere soggetto a disciplina e pianificazione; • L’implementazione del prodotto deve essere rimandata fino a quando non sono perfettamente chiari gli obiettivi. Il maggior pregio di questo metodo di lavoro è certamente la semplificazione del controllo dell’andamento del progetto tramite la suddivisione del ciclo di vita in fasi successive ben definite. Le diverse 14
    • metodologie che adottano questo modello si distinguono essenzialmente per la suddivisione e specificazione delle fasi in sottofasi più elementari, nella definizione di standard di documentazione e nella individuazione di momenti di verifica, detti milestone, al termine o durante ciascuna attività. Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi persegue l’obiettivo di assegnare a ciascuna fase la soluzione di problematiche specifiche e di rendere, per quanto possibile, le fasi indipendenti allo scopo di poterne parallelizzare le attività. Benché l’adozione di questi principi appaia estremamente produttiva, la loro applicazione pratica ha come effetto collaterale, soprattutto per i progetti di grandi dimensioni, una pericolosa dilazione temporale. Ad esempio, normalmente l’individuazione delle strutture dati e delle funzionalità del sistema sono affrontate con metodologie diverse e, soprattutto per i progetti di grandi dimensioni, contemporaneamente e separatamente da gruppi di lavoro differenti. Nel primo caso i risultati sono formalizzati con uno Schema Entity-Relationship e nel secondo con un metodo di scomposizione funzionale. Solo quando queste due attività terminano viene avviata una ulteriore attività di armonizzazione dei rispettivi risultati. Un ulteriore problema di questa impostazione deriva dalla necessità di terminare completamente tutta la fase di analisi dei requisiti e progetto per cominciare l’implementazione e quindi verificarne sul campo le conclusioni. Il modello, quindi, è una semplificazione della realtà che non trova piena 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 possono 15
    • effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera lineare; • Rigidità: ogni fase viene congelata quando si passa alla fase successiva per cui non è possibile un’interazione tra clienti e sviluppatori durante il ciclo di vita dopo la parte iniziale; • Monoliticità: tutto il modello è orientato alla singola data di rilascio che spesso si pone a mesi o anni dopo l’inizio della prima fase per cui se vengono commessi eventuali errori o cambiano i requisiti, questi verranno implementati dopo parecchio tempo e comunque alla fase di consegna seguirà subito un altro adattamento perché il software sarà già obsoleto; Concludendo quindi, in base alle nozioni appena riportate si possono identificare i maggiori problemi del modello: • È difficile stimare le risorse e i costi in maniera accurata finché non sia stata svolta almeno la prima fase di analisi; • La specifica dei requisiti produce un documento scritto che vincola il prodotto da sviluppare e ciò non sempre soddisfa le esigenze del cliente perché si tratta pur sempre di specifiche basate su un documento che non sempre aiuta nel definire le esigenze, che invece, appaiono subito chiare dopo il primo rilascio del software. Inoltre tale documento deve essere completo e chiaro prima di procedere allo sviluppo, ma non sempre ciò è possibile; • L’utente non è in grado di comprendere i formalismi utilizzati per descrivere i requisiti dell’applicazione, si corre quindi il rischio di passare alla fase di progetto con una documentazione non del tutto aderente agli obiettivi del cliente; 16
    • Si comprende come gli alti costi del software siano dovuti, nel modello a cascata, a causa proprio delle specifiche poco complete e ai molti interventi successivi per introdurre funzionalità non previste in partenza. La curva di costo degli errori in questo modello è esponenziale proprio perché data la monoliticità più tardi ci si accorge di un errore e più profonda dovrà essere la correzione da apportare. Modello esplorativo Se non si possono determinare le specifiche, non può essere definita la correttezza del sistema, ossia la corrispondenza con le specifiche. In questi casi viene utilizzato il concetto di adeguatezza, ossia corrispondenza con i bisogni e gli obiettivi del cliente. Il modello esplorativo consiste in una successione di prototipi che viene fatta convergere verso una soluzione adeguata, soddisfacente per il cliente. Non si tratta di una vera metodologia quanto piuttosto di un approccio sperimentale e iterativo allo sviluppo: ad ogni iterazione viene costruito un prototipo e presentato alla valutazione critica del cliente, che lo può accettare come adeguato alle sue esigenze, oppure può indicare nuovi criteri e requisiti che il sistema deve possedere. Nei passi finali il prototipo viene affinato ad ogni ciclo finché viene accettato 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
    • Modello incrementale Questo modello è caratterizzato dalla scomposizione del processo in una serie di passi sequenziali da ripetere ad ogni termine del ciclo precedente. Per poter applicare questo modello è consigliabile avere una visione molto chiara dell’intero progetto, perché occorre fare in modo che la realizzazione della generica versione k risulti utile per la realizzazione della versione k+1. Per fare ciò bisogna eseguire con cura la fase di analisi (definizione del problema, analisi di fattibilità, e così via) e poi procedere con l’iterazione del seguente ciclo di attività: • analisi dei requisiti • progetto • codifica • test o collaudo Importante osservare che ogni iterazione ha un piano, degli obiettivi verificabili e criteri di valutazione propri, ciò permette un migliore controllo del lavoro. Ogni qual volta che si termina una iterazione del ciclo si ha realizzato uno o più moduli funzionanti che vengono integrati e testati con quelli precedentemente sviluppati creando una versione funzionante del progetto che implementa un sottoinsieme finito delle funzionalità del progetto software totale. Si procede in maniera analoga fino all’ennesima iterazione e quindi alla conclusione del ciclo con il rilascio della versione finale. Questo tipo di approccio offre delle differenze sostanziali rispetto il modello a cascata visto in precedenza; organizzando le iterazioni cercando di dare una priorità di messa in opera non solo dipendente dall’utilità 18
    • incrementale dei vari moduli ma soppesando anche le criticità degli stessi è possibile affrontare i rischi del progetto fin dall’inizio, in modo sistematico. Inoltre operare con un sistema stratificato di release permette una maggiore flessibilità per gestire eventuali cambiamenti esterni (tecnologie, leggi) o interni (errori nel documento dei requisiti) e favorisce la partecipazione del cliente alla vita del progetto; tutto ciò accresce ovviamente il costo per il cliente ma offre la possibilità di fornire velocemente software funzionante e fornire risultati di valore poiché questo modello consente una progettazione adeguata, in quanto porta ad un progetto solido. Object Oriented Nell’Object Oriented l’importanza fondamentale è rivestita dall’approccio che si adotta per la scomposizione del problema. Questo metodo mira infatti ad una decomposizione di un sistema mediante l’astrazione di oggetti, che è diversa dalla decomposizione funzionale/procedurale. Tutti i linguaggi ad oggetti includono sempre un tipo di modulo chiamato classe, esso è uno schema dichiarativo che definisce tipi di oggetti. La dichiarazione di classe contiene implicitamente la definizione dei dati e dei metodi che operano su di essi. Per poter continuare la spiegazione liberamente si introducono le definizioni di alcuni termini propri dell’ Object Oriented specifici della definizione di una classe: Classe: Nome collettivo di tutti gli oggetti che hanno gli stessi metodi e variabili di istanza (dichiarazione di tipo); Oggetto: Entità strutturata (codice, dati) e proprietaria di uno Stato la cui struttura è invisibile all’esterno dell’oggetto; 19
    • Stato: Lo stato di un oggetto si accede e manipola mediante messaggi che invocano metodi, quindi non è direttamente accessibile; Variabili di istanza: Variabili contenute nell’oggetto che rappresentano il suo stato interno; Messaggio: Richiesta ad un oggetto di invocazione di uno dei suoi metodi; Metodo: Azione che accede o manipola lo stato interno dell’oggetto (di solito le variabili di istanza), l’implementazione di tale azione è nascosta al cliente che spedisce messaggi all’oggetto. Approfondita ora la definizione e terminologia di una classe risulta più semplice introdurre i concetti propri dell’Object Oriented: Classificazione la definizione di classi rappresenta l’identificazione di un insieme di attributi (variabili di istanza) e di operazioni (metodi) propri di oggetti simili. Proprio per questo motivo si può dire che una classe descrive un insieme di oggetti e lo rappresenta tramite un’astrazione degli attributi rilevanti; Responsabilità ogni classe ha una responsabilità limitata ai comportamenti che essa prevede (ai metodi che implementa); Ereditarietà questo concetto indica che una classe, detta sottoclasse, può essere un raffinamento di un’altra andando così a richiedere alcune variabili e/o metodi aggiuntivi rispetto alla classe raffinata, che viene denominata superclasse. Il vantaggio è quindi l’utilizzo condiviso delle definizioni di attributi e codice in classi diverse, rendendo quindi sufficiente la sola definizione delle variabili e dei metodi aggiuntivi; 20
    • Generalizzazione può rivelarsi opportuno evidenziare sottoinsiemi definibili come ulteriori tipi di oggetto all’interno di classi già identificate. Questo concetto è identificabile banalmente come la relazione di contenimento in insiemistica (un semplice esempio può essere Veicolo Moto); Polimorfismo si vuole rendere standard che le operazioni con lo stesso significato posseggano lo stesso nome anche se implementazioni diverse. Si intuisce che esse verranno identificate univocamente dall’insieme di variabili su sui operano (esempio “calcolo_area” su figure geometriche diverse); Information Hiding ogni classe nasconde tutto ciò che non è essenziale condividere, impedendone così l’accesso o la modifica diretta e non facilmente controllabile dall’esterno; Gettati i punti essenziali dell’Object Oriented si può vedere ora la struttura della sua applicazione, limitiamoci a descrivere una scomposizione in 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 (casi d’uso); • Estrazione delle componenti candidate; • Costruzione di un modello di relazioni fra le componenti; • Costruzione di un modello di comportamento delle componenti; • Revisione dell’analisi rispetto ai casi d’uso; 21
    • Interessante approfondire come la descrizione in linguaggio naturale dei requisiti può essere interpretata direttamente nella identificazione delle entità e dei loro attributi e metodi. Se si provvede a separare ogni frase dei requisiti in gruppi attinenti agli stessi soggetti risulta chiaro come ogni sostantivo può essere identificato come oggetto ed ogni verbo può essere identificato come metodo. Ovviamente è necessario porre attenzione ai significati di sinonimi e differenti modi di riferirsi al medesimo oggetto. Dopo aver completato la fase di analisi si ha dunque una totale scomposizione del problema in componenti e dei modelli in cui vengono definite le loro relazioni e i loro comportamenti. La fase di Design deve ora specificare completamente queste componenti facendo riferimento anche ai vincoli tecnologici che si impongono al progetto. Bisogna misurare il grado di indipendenza dei vari componenti. Inutile sottolineare che le componenti di un sistema dovrebbero riportare un basso accoppiamento, limitando il numero di dipendenze e lasciando solamente quelle 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 i moduli. Una struttura gerarchica forma la base del progetto decomponendone il dominio e facilitandone lo sviluppo in parallelo. Riassumendo i concetti dell’approccio Object Oriented al design si può dire che: • le componenti vengono classificate • astrazione e incapsulamento sono meccanismi principali della strutturazione • il sistema finale rispecchia il dominio del problema • è possibile la concorrenza dei processi (thread multipli) 22
    • Nell’esporre l’Object Oriented infine non riveste particolare importanza descrivere la fase di realizzazione. Questo perché se le precedenti fasi sono state eseguite con la dovuta meticolosità e non sono presenti errori, si tratta solamente di riportare le classi nel o nei linguaggi scelti e di sviluppare le interfacce necessarie, riducendosi così ad una mera procedura di programmazione. 23
    • 3. Rational Unified Process Il Rational Unified Process è un modello di un processo software iterativo sviluppato da Rational Software. Esso provvede a fornire un approccio disciplinato per l’assegnazione dei compiti e delle responsabilità all’interno di una organizzazione di sviluppo software. Il suo obiettivo è garantire una produzione di alta qualità che trovi un punto di incontro fra le esigenze dei clienti e le tempistiche e il budget dell’azienda. Il R.U.P. non definisce un singolo, specifico processo, bensì un framework adattabile che può dar luogo a diversi processi in diversi contesti, esso è pensato principalmente per i progetti di grandi dimensioni. Interessante è sapere come è nato, i creatori del RUP partirono dalla diagnosi di un campione di progetti software falliti, allo scopo di identificare cause tipiche o generali di fallimento. Quindi confrontarono questa informazione con la struttura dei processi software descritti in letteratura e applicati nella pratica, cercando di identificare le soluzioni proposte precedentemente. L'elenco dei motivi di fallimento identificati comprende per esempio: • Gestione ad hoc dei requisiti; • Comunicazione ambigua e non precisa; • Architettura fragile ,incapace di sopportare situazioni di particolare criticità; • 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
    • • Insufficiente automazione; Il RUP si può descrivere come una collezione di best practices mirate a evitare questi e altri problemi, e come un ambiente di gestione dei processi che facilita l'applicazione di tali pratiche. Il processo fu progettato utilizzando strumenti tipici della progettazione del software; in particolare, esso fu descritto in termini di un meta modello object-oriented, espresso in UML. Per l’appunto chiameremo da ora in poi queste diverse metodologie di approccio descritte dal RUP come processi o “best practices”, vediamo ora le sei più importanti: • Sviluppo software iterativo (Develop Software Iteratively) • Disciplina dei requisiti (Manage Requirement) • Utilizzo di architetture a componenti (Use Component-based Architectures) • Verifica della qualità del software (Verify Software Quality) • Controllo dei cambiamenti (Control changes to software) • Modellizzazione Visuali (Visually Model Software) Disciplina dei requisiti Il RUP descrive come identificare e tracciare i documenti funzionali necessari, definire i vincoli, estrarre, organizzare e comunicare semplicemente i requisiti del business. Le nozioni di “use case” e di scenari sono state dimostrare essere degli eccellenti modi di procedere al fine di catturare e definire i requisiti funzionali ed assicurare che essi guidino correttamente il design, l’implementazione e il test del software, portandolo così ad adempire fedelmente alle necessità del cliente. Sviluppo software iterativo 25
    • La tecnologia di oggi ci offre dei sistemi software estremamente complessi, non è possibile definire sequenzialmente e di primo acchito l’intero problema, effettuarne il design, codificarlo e testarlo solo al termine del processo produttivo. Un approccio iterativo è richiesto per permettere una comprensione progressiva del progetto e quindi un suo raffinamento al fine di far crescere l’effettiva soluzione migliore su questo ciclo di iterazioni multiple. Questa struttura permette tramite lo sviluppo dei maggiori oggetti di rischio nelle prime iterazioni, di mantenere sotto controllo il rischio durante tutto il ciclo di vita del software. Un approccio iterativo facilita l’adeguamento degli obiettivi di progetto ai cambiamenti, andando a ridurre significativamente il costo dei cambiamenti dovuti ad errori a qualsiasi livello. Controllo dei cambiamenti L’abilità di controllo e gestione dei cambiamenti è essenziale per rendere ogni necessità di alterazione accettabile e permettere di tracciare come essa inevitabilmente affonderà e richiederà delle modifiche nel progetto. Questo processo descrive come controllare, tracciare e monitorare i cambiamenti per poter sviluppare iterativamente ed efficacemente a fronte del presentarsi di errori. Verifica della qualità del software Oggigiorno cattive performance applicative e scarsa affidabilità sono comuni fattori che segnano l’inaccettabilità del software. Quindi, si rende necessario un controllo qualitativo basato sui requisiti sull’affidabilità, la funzionalità, le performance delle applicazioni e dell’intero sistema. Il RUP mette a disposizione dei parametri valutativi per i test di pianificazione, design, implementazione, esecuzione e valutazione. È importante 26
    • comprendere che la qualità è costruita nel processo, in tutte le attività, è affetta da ogni partecipante al progetto, ha dei criteri e parametri di valutazione definiti e non deve essere trattata come una attività separata svolta da un gruppo dedicato come aggiunta al progetto. Utilizzo di architetture a componenti Il processo è centrato sul definire la linea guida di una architettura eseguibile robusta e svilupparne velocemente alcune parti, prima di impegnare le risorse per uno sviluppo massivo. Esso descrive come disegnare una architettura ricuperabile che sia flessibile ed adattabile ai cambiamenti, e come è intuibile che favorisca il riutilizzo del software interno. I componenti non sono meri moduli ma sottosistemi che adempiono a specifiche funzioni. Il RUP provvede a definire un approccio sistematico per la definizione dell’architettura utilizzando componenti nuovi e/o preesistenti. Modellizzazione Visuali Questo processo mostra come modellizzare in maniera visuale il progetto software per catturare la struttura e il comportamento delle varie componenti. L’astrazione visuale aiuta a comunicare differenti aspetti del progetto, come gli elementi combacino nel sistema, accertare che i blocchi siano in linea con il codice, mantenere la consistenza tra il design e l’implementazione e favorisce la comunicazione disambigua con il cliente. Lo standard industriale Unified Modeling Language è il fondamento per una modellizzazione visuale di successo. Lo UML è uno strumento per analisti e progettisti di sistemi orientati agli oggetti che consente di modellare, rappresentare e documentare sistemi 27
    • software. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar Jacobson (detti "i tre amigos") sotto l'egida dello OMG, che tuttora gestisce lo standard di UML. Questo linguaggio di modellazione visuale è un insieme di elementi e di regole, di specifica formale ed offre un notevole vantaggio; infatti anche i progettisti e gli analisti di sistemi informativi utilizzano figure e diagrammi per visualizzare il risultato del loro lavoro: il sistema software. Durante le fasi di analisi e progettazione vengono generati dei modelli che consentono di identificare e separare le caratteristiche di un sistema reale. Il progettista dovrà quindi decidere quali caratteristiche sono rilevanti per il sistema che sta costruendo, inserirle e definire le relazioni tra gli elementi del modello. Ciò avviene anche se il tipo di prodotto finale che risulta dalla progettazione non è necessariamente visuale. Il Rational Unified Process quindi è uno schema generale di un processo, da adattare alle diverse tipologie di progetto, esso si articola in una serie di iterazioni con lo scopo di ridurre progressivamente i rischi, a partire da quelli principali (es. incomprensioni sui requisiti, incertezze implementazione). In ogni iterazione si svolgono, in misura e in percentuali diverse, le tipiche attività di sviluppo (es. gestione dei requisiti, design, implementazione, test) adottando così un modello incrementale che si svolge attraverso la realizzazione ed eventualmente il rilascio dell’applicazione in modo progressivo guidata però dai casi d’uso e dalle priorità architetturali. La definizione dell’architettura applicativa e tecnologica costituisce il fondamento tecnico dell’applicazione e del progetto, ed il consolidamento della stessa avviene solo quando si è certi della sua fattibilità tecnica. Fino a quando l’architettura non è consolidata non esistono elementi sufficienti per 28
    • determinare i tempi, i costi e i rischi dell’intervento progettuale con la precisione necessaria per la stipulazione di un contratto. 3.1 Le fasi del RUP Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli di 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 raggiungimento di obiettivi stabiliti in fase di definizione del progetto stesso. Inception Phase Questa fase si può considerare come una particolare elaborazione e precisazione del concetto generale di analisi di fattibilità. Lo scopo principale è quello di delineare nel modo più accurato possibile il business case, ovvero comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinché esso conduca a un successo commerciale. Fra gli strumenti utilizzati ci sono un modello dei casi d'uso, la pianificazione iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei requisiti e la identificazione delle interazioni ad alto livello. Alla fine di questa fase è presente la prima milestone maggiore del progetto, detta "Lifecycle Objective Milestone". I criteri di valutazione per la Inception Phase sono: 29
    • • 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 maniera considerevole nel caso non passi questa milestone. Elaboration Phase L’obiettivo principale di questa fase è analizzare il dominio del problema, stabilire una base architetturale, sviluppare un piano del progetto ed eliminare i fattori di rischio più elevato del progetto. Questa fase deve concludersi con il superamento di una milestone detta "Lifecycle Architecture Milestone". A questo scopo devono essere soddisfatti i seguenti criteri: • Sviluppato un modello dei casi d'uso completo all'80% • Fornire la descrizione dell'architettura del sistema • Sviluppata un'architettura eseguibile che dimostra il completamento degli use cases significativi • Eseguita una revisione del business case e dei rischi • Completata una pianificazione del progetto complessivo • Redazione di un manuale utente preliminare (opzionale) 30
    • Se il progetto non passa questa milestone, potrebbe ancora essere abbandonato, oppure dovrà essere revisionato. Al termine di questa fase si transita infatti in una situazione di rischio più elevato, in cui le modifiche all'impostazione del progetto saranno più difficili e dannose. Construction Phase Durante questa fase, tutte le componenti vengono sviluppate ed integrate al prodotto, e infine vengono testate. Nella construction phase è, in un certo senso, un processo manifatturiero in cui l’enfasi viene dedicata alla distribuzione, controllo e gestione delle risorse per ottimizzare i costi e massimizzare la qualità. Molti progetti sono sufficientemente estesi per permettere una organizzazione parallela nella realizzazioni di alcune componenti. Queste attività parallele possono accelerare significativamente il rilascio ma incrementa notevolmente la complessità di gestione delle risorse e sincronizzazione dei workflow. Al termine della Construction Phase c’è la così denominata “Initial Operational Capability Milestone”, essa deve determinare se quello che è stato prodotto può considerarsi operativo senza esporre l’intero progetto a qualche 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 sviluppato al cliente, è facilmente intuibile che una volta installato si renderanno necessari degli interventi correttivi o sviluppativi che richiederanno delle 31
    • nuove release. La Transition Phase si introduce quando lo sviluppo iterativo si porta ad un punto sufficiente per permettere il rilascio al cliente, i tipici requisiti per fare ciò sono che il libello di qualità del sottosistema completato sia accettabile e che la documentazione utente sia disponibile. In questo modo la transizione del prodotto al cliente porterà un risultato positivo per entrambe le parti, permettendo ad esempio di validare il nuovo sistema e di iniziare a formare il personale. Con la “Production Release Milestone” si vuole valutare se effettivamente il cliente è soddisfatto di ciò che gli si propone e se il dispendio registrato di risorse contro quello programmato è accettabile. A questo punto, se gli obiettivi sono stati raggiunti è possibile iniziare un altro ciclo di sviluppo, in alcuni casi questa milestone coincide con la fine della inception phase del ciclo successivo. 3.2 Aspetti statici del RUP Il meta modello applicato dal RUP per descrivere e controllare un processo utilizza quattro concetti cosiddetti "statici", ovvero che sono definiti nello stesso modo per tutti i processi: • Worker Un ruolo identifica un certo insieme di responsabilità attribuite a un certo insieme di partecipanti al progetto (I ruoli rispondono alla domanda chi?); • Artifact Gli artefatti sono il prodotto delle attività del processo; includono documenti, modelli, componenti software e via dicendo (Gli artefatti rispondono alla domanda cosa?); 32
    • • Workflow Un workflow è una sequenza di attività che producono un risultato in un tempo osservabile (I workflow rispondono alla domanda quando?); • Attività Le attività sono i compiti specifici portati a termine dai partecipanti del progetto (Le attività rispondono alla domanda come?); 33
    • 4. Identificazione delle problematiche di progetto 4.1 EURIDICE Il progetto Euridice, è un progetto cofinanziato dalla Commissione Europea, che si prefigge la realizzazione del concetto di "Cargo Intelligente" come veicolo di ottimizzazione del settore logistico. E’ un Integrated Project con un budget di circa 14 M€ e un partenariato di 22 partner provenienti da 9 paesi europei che include aziende leader nelle tecnologie software, mobile, wireless e RFID, rinominati centri di ricerca, operatori logistici, istituzioni e utenti finali. L’obiettivo del progetto è la creazione di una architettura e di applicazioni pilota atte a verificarne la validità e l’usabilità nel mercato dei trasporti europei. Potendo installare dispositivi con una certa capacità elaborativa direttamente sulla merce, questa potrebbe essere in grado di riconoscere il contesto in cui si trova, prendere decisioni e segnalare eventuali anomalie, questo in estrema sintesi è il “Cargo Intelligente” che può quindi diventare un attore primario nei processi di trasporto e delivery, e fornire informazioni in tempo reale dettagliate ed affidabili al sistema centrale. Il continuo dialogo fra dispositivi di diverso livello automatizza procedure oggi affidate all’utente umano e migliora le tempistiche e l’efficienza di molte fasi dipendenti dai trasporti: velocità di consegna, carico e scarico, programmazione della produzione in funzione degli arrivi dei semilavorati, ottimizzazione visti doganali e controlli, tracciabilità in tempo utile della posizione della merce e dei veicoli, programmazione del percorso 34
    • centralizzata, disposizione di informazioni sullo stato della merce in tempo reale e così via. Risulta immediato realizzare le potenzialità di tale progetto e al tempo stesso risulta evidente che le difficoltà che si potranno presentare non sono poche. Viene generalizzato Euridice ad un progetto generico portandosi così in una situazione favorevole ad un’analisi delle possibili problematiche di un progetto di questo tipo. Ci si pone quindi in uno scenario in cui un consorzio di aziende si associano per sviluppare un progetto di ricerca europeo. Tali aziende sono distribuite in vari paesi e non sono specializzate negli stessi settori. Partendo da questi presupposti si procede all’identificazione delle problematiche. 35
    • 4.2 Analisi dello scenario Prendendo in considerazione il sopra descritto scenario ci si può facilmente rendere conto delle enormi implicazioni gestionali di un simile progetto, anche se fosse sviluppato da una singola azienda. Per iniziare ad analizzarne le problematiche infatti porremo proprio questa ipotesi, ovvero che solo una azienda si occupi del suo sviluppo per poi ampliare la panoramica. Nonostante ci si ponga in un ambiente molto semplificato per analizzare l’impatto del problema, ci si rende immediatamente conto che essendo preso in esame un progetto di ricerca e sviluppo su un tema commissionato, lo scopo non sarà definito sufficientemente a priori. Proprio per questo sarebbe saggio stimare con la dovuta accortezza la durata preventiva delle fasi del progetto, soprattutto quelle iniziali di analisi, dilatandone leggermente i tempi stimati per permettere di poter far fronte in maniera meno incisiva a ridefinizioni dovute a sviluppi e/o a funzioni introdotte in fasi successive. 36
    • Dato che i “progetti di ricerca” finanziati dall’Unione Europea sono indetti tramite un concorso fra gli sviluppatori, al suo interno saranno proposte applicazioni tecnologiche innovative e soprattutto un utilizzo di prodotti hardware e software del tutto nuovi. Proprio questi potrebbero rivelarsi una lama a doppio taglio, aumentando sicuramente il livello del progetto di ricerca ma andando ad incidere significativamente sull’onere da sostenere per il suo sviluppo. Alcune tecnologie nascenti infatti sono così nuove da non esser state ancora assimilate, o nemmeno conosciute, all’interno dell’azienda ove il costo diretto di produzione di un progetto dipende largamente dalla preparazione e dalla “cultura” dei dipendenti. Inoltre capita frequentemente che i nuovi prodotti ancora mai utilizzati realmente su vasta scala o all’interno di un progetto industriale sufficientemente elaborato per cercare di sfruttarne tutte le peculiarità, siano affetti da vari errori di funzionamento nelle versioni distribuite e necessitino quindi di una vasta comunicazione fra azienda sviluppatrice e casa madre per la correzione. Queste considerazioni non sono necessariamente un danno per il progetto ma sicuramente ne aumentano il costo e rendono più ardua la stima dei tempi necessari alle varie fasi del progetto. Spostandoci ora in una fase un po’ più avanzata, si renderà importante definire degli standard per l’organizzazione dei contenuti e della forma dei deliverables delle varie fasi, essendo un progetto internazionale, essi costituiranno le tappe e la prova dei progressi del lavoro non solo ai Project Manager che lo dirigeranno ma probabilmente anche ad esaminatori dell’Unione Europea ed ai responsabili delle aziende affiliate per il progetto. Proprio con questi soggetti infatti l’azienda dovrà periodicamente relazionarsi per ottenere i requisiti e i chiarimenti necessari al corretto proseguimento della vita del progetto. Per fare ciò infatti sarà necessario del 37
    • personale qualificato sia per quanto riguarda il colloquio con gli altri soggetti esterni, sia per quanto riguarda la conoscenza dei vari paesi ove risiedono le aziende collaboratrici. Infatti una problematica da sempre riscontrata nella fase di analisi è l’omissione di dettagli di un certo peso per una corretta impostazione del progetto poiché il soggetto che deve descrivere il processo li ritiene così scontati che dimentica di farne menzione nei colloqui. Tutto ciò è ovviamente accentuato dal fatto che l’azienda sviluppatrice e quella collaboratrice possono non essere connazionali andando così a limitare significativamente quel margine di conoscenza che permette solitamente all’analista, tramite domande mirate e l’esperienza, di identificare ed eliminare le sopradette omissioni. Incisive saranno quindi le competenze linguistiche e culturali per potersi avvalere efficacemente delle collaborazioni con aziende estere. Bisogna ricordare che nonostante la tecnologia moderna ci permetta di essere in contatto ventiquattro ore su ventiquattro con tutto il mondo, certe questioni sia per un fatto diplomatico che da un punto di vista pratico sarebbero da risolvere di persona; il che risulta problematico data la possibile lontananza geografica con determinati soggetti coinvolti nel progetto. Per poter sviluppare alla massima efficienza un progetto sarebbe necessario poter utilizzare, di volta in volta, la metodologia più congeniale ed adattarla ad esso. In realtà ogni azienda sviluppatrice di software ha una sua metodologia affermata che è stata negli anni assorbita dal personale, con precisi modi di lavorare che personalizza l’azienda sia al suo interno che dall’esterno. Questo metodo non è ovviamente rigido ma viene adattato, con flessibilità propria di ogni azienda, al progetto in corso per permettere una ottimizzazione dei costi all’azienda. Quindi è presumibile che nonostante il progetto sia di ricerca, il suo cammino sarà comunque aderente al modus operandi dell’azienda sviluppatrice. 38
    • L’attenzione ad altre procedure produttive di carattere più scontato come definizione del cammino critico delle varie sottofasi del progetto, l’ottimizzazione del tempo tramite una messa in parallelo delle stesse formando diversi workgroup e loro controllo tramite milestones; si daranno, per il momento, per pienamente efficienti ed assimilate dall’azienda sviluppatrice. La stessa funzionalità dei deliverables per le fasi successive però non è del tutto scontata dato che si è dovuto apporvi alcune modifiche nella struttura e soprattutto nella lingua utilizzata per adoperarli, come menzionato in precedenza, in ambito europeo. 4.3 Approfondimento Conclusasi la prima fase di analisi dell’impatto del problema ora si è pronti ad approfondire la struttura dell’azienda sviluppatrice. Come premesso nella descrizione dello scenario la realizzazione di tale progetto non è affidata ad un’ unica azienda ma ad un insieme di aziende software affiliate per tale scopo e da alcune aziende collaboratrici, che saranno poi i primi utilizzatori dei piloti del progetto. La distribuzione in diversi paesi di tali 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 “Azienda Sviluppatrice” considerando però invariato il rapporto fra essa e gli altri soggetti come l’Unione Europea e l’approccio alle nuove tecnologie. 39
    • Si può immediatamente identificare un vantaggio del nuovo diagramma, il problema menzionato in precedenza sui problemi degli analisti nel colloquiare con aziende non connazionali e sulle relative problematiche dovute alla lontananza si possono affievolire o risolvere grazie alla disposizione di diversi partner dislocati in differenti paesi europei. Però analizzando meglio la situazione ci si rende conto che il problema di comunicazione si è spostato all’interno del gruppo sviluppatore data la varietà di partner presenti. Questo non dovrebbe costituire una grave complicanza rispetto alla situazione analizzata in precedenza poiché il problema di comunicazione già esposto con le aziende si è affievolito e la standardizzazione e l’internalizzazione dei documenti interni all’azienda (deliverables) era già stata preventivata seppure per altre cause. Lungi dall’essere risolto il problema di composizione eterogenea del gruppo sviluppatore che introdurrà sicuramente altre problematiche, per lo meno per quanto riguarda la necessità di ridefinire i documenti interni si può dire che non ne aumenta la complessità già preventivata. 40
    • Si pensi ora alla composizione dei workgroup in un’azienda sviluppatrice. Per favorire la produttività si tende ad aggregare gli elementi più adatti ad un certo compito nello stesso gruppo per poi affidargli il ruolo migliore alle loro capacità. Se questo ragionamento si applica anche per una azienda sviluppatrice risulta palese che si potrà avere dei gruppi di lavoro eterogenei trasportando tutte le problematiche precedentemente sollevate a livello aziendale anche negli stessi workgroup. La risoluzione di tali problemi risulta concorde con i ragionamenti introdotti in precedenza, ovvero la standardizzazione degli artefatti e una collaborazione aperta mediante molti dei canali di comunicazione che la tecnologia moderna mette a disposizione. Riferendosi alla struttura che abbiamo dato per scontata nella prima analisi ci si deve necessariamente rende conto che ognuno dei partner coinvolti 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 di pensare, della cultura e delle conoscenze già su un singolo individuo quindi non è così astratto preventivare, pensando a livello aziendale, di trovarsi di fronte ad almeno una differente metodologia per paese di dislocazione dei partner. La problematica legata al linguaggio ora è amplificata dal numero di soggetti coinvolti. Scendendo nel dettaglio delle aziende infatti, nonostante la percentuale di personale con una conoscenza dell’inglese alquanto limitata sia molto bassa in una singola azienda, ci si accorge che deve per forza contare un numero congruo di persone se applicata all’intero gruppo di sviluppo. Questo fatto può portare a difficoltà di alcuni workgroup di creare materiale standard per le fasi successive. Il riscontrarsi di problemi comunicazione è altrettanto plausibile ovviamente, nel caso sia necessario 41
    • colloquiare con altri workgroup non connazionali assegnati a sottofasi relazionate ad essi. Naturalmente non è un problema di primaria importanza poiché con un minimo di collaborazione interna aziendale, un intelligente creazione dei workgroup e assegnazione ai vari compiti la situazione è arginabile. Comunque però implicherà una maggiore attenzione in certe fasi e una inadattabilità di una certa percentuale di personale a determinati compiti, il che porta ovviamente ad un probabile aumento di tempo e denaro impiegato nell’organizzazione del lavoro. Parlando ora di suddivisione del lavoro, per quanto riguarda una distribuzione delle fasi lavorative ad un numero elevato di soggetti di devono ricordare le basi della ottimizzazione del lavoro. Infatti non è detto che più persone si impiegano allo stesso progetto, maggiore sarà la produttività del team; poiché superata una certa soglia si comincia a spendere più tempo per la comunicazione interna che per lo sviluppo in senso stretto. Tutto questo senza considerare che ogni soggetto coinvolto ha bisogno di un livello specifico di conoscenza dell’avanzamento del progetto generale, portando così ad aumentare i tempi necessari alla comunicazione interna delle informazioni. Questo discorso è si può applicare sia al livello di dettaglio esposto che riferito al numero di workgroup operativi in un progetto. Spezzettando in troppe parti il lavoro si creano, a parte le problematiche generiche di comunicazione appena accennate, delle dipendenze forzate dal lavoro altrui che non sempre permettono lo svolgersi del lavoro in parallelo delle attività. Anzi esse probabilmente tendono a portare scompiglio, ritardi ed a periodi di improduttività di alcuni dei workgroup. Senza considerare che queste conseguenze si possono ripercuotere ed amplificare notevolmente nel caso le dipendenze intercorrano fra gruppi di lavoro appartenenti a differenti partner (non connazionali). Per questo è assolutamente necessario imporre uno standard anche sulle piccole fasi e non solo sui deliverables finali delle varie attività. 42
    • Deve esserci omogeneità nei tool utilizzati per le varie attività e se proprio ciò non risulta possibile a livello globale, almeno fra quelle attività che sono in relazione di dipendenza diretta. Essenziale per un progetto di queste dimensioni e per la quantità di soggetti coinvolti, è realizzare che ogni partner è una azienda a se stante che, anche se sta collaborando con le altre per il progetto, tenderà a dimostrare un suo orgoglio aziendale, per così dire. Questa problematica non è banale perché la base della collaborazione redditizia è la non competitività dei partner per l’assegnazione dei compiti (la competitività non è necessariamente dannosa, anzi fa bene in molti altri ambiti fungendo da sprone per migliorare se stessi, la qualità e la velocità del lavoro). Per poter comprendere appieno le implicazioni del problema si deve analizzare come avviene l’assegnazione dei compiti in una struttura così complessa, come al solito partiamo da un livello generale e molto semplificato del problema. Al fine di realizzare al meglio un progetto, la logica imporrebbe di assegnare le fasi più critiche ai soggetti migliori e le fasi restanti ai gruppi qualificati in ordine di importanza delle varie attività, invece il problema andrebbe affrontato da un punto di vista inverso. Siccome la resistenza di un oggetto è diretta funzione dell’anello più debole, sarebbe meglio assegnare ad ogni gruppo l’attività che lui può svolgere meglio rispetto tutte le altre attività restanti. Applicando questo ragionamento però si viene a creare la problematica accennata in precedenza. Se ogni team viene assegnato in questa ottica non è detto che a certe aziende arrivino incarichi appaganti o che dimostrino credibilità ed di importanza nella loro partecipazione al progetto. Bisogna assolutamente sfasare questa sensazione mettendo in chiaro che ogni partner è di egual importanza, anche se non di egual peso sul progetto. L’obiettivo del gruppo di sviluppo non è dimostrare quale sia la gerarchia di qualità delle aziende coinvolte, ma realizzare il prodotto meglio 43
    • possibile sfruttando tutti i partner coinvolti nel modo migliore per il fine collettivo. La risoluzione ideale per render appagati tutti del proprio operato e della propria appartenenza al gruppo di sviluppo sarebbe una assegnazione a rotazione delle attività di maggiore importanza nelle varie iterazioni del progetto. Questo sarebbe nuovamente in contraddizione con il metodo di assegnazione suggerito. Come accade molto spesso nella pratica, si dimostra necessario considerare caso per caso ed applicare il punto di incontro fra i vari metodi produttivi e diplomatici per il bene della stabilità comune. La quantità di problematiche sollevate semplicemente per strutturare il lavoro necessario per l’effettiva realizzazione del progetto suggerisce che probabilmente la dichiarazione della tempistica di progetto si rivelerà inadeguata. Quasi ogni problema che è stato analizzato, come danno collaterale, apportava un aumento di tempo e del costo del lavoro e ci sono probabilità non nulle, proprio come in qualsiasi altro progetto, di incappare in errori non direttamente dipendenti dalle considerazioni da effettuate. La possibilità di un ritardo nei tempi è molto alta e esso non sarà da riferire al termine edotto dall’Unione Europea ma da quello effettivo stimato del progetto conclusasi completamente la fase di analisi. 44
    • 4.4 Riassumendo In seguito all’analisi appena presentata, risultano essenziali molte procedure nel complesso del progetto: Nel definire il progetto bisogna essere in grado di quantificare e valutare correttamente l’impatto di tecnologie particolari sul processo di sviluppo. Iniziare a formare il personale con largo anticipo e non durante il progetto sia ai fini linguistici che tecnologici necessari per una ottimale adeguatezza della forza lavoro ai compiti imminenti. A fine di stimare la tempistica di progetto è necessario collezionare informazioni dettagliate non solo sulle aziende coinvolte, ma su tutti i dipendenti che verranno impiegati al progetto e sui workgroup in cui operano solitamente, naturalmente ad un livello di aggregazione dei dati adeguato (risulta ovvio che per il fine preposto non costituisce nessuna utilità sapere il nome o l’indirizzo del soggetto in questione ma solamente le sue abilità, conoscenze ed attitudini lavorative). Definire in modo preciso e non ambiguo le relazioni (e mediante che canali) che intercorrono fra il gruppo di sviluppo e i soggetti esterni, come i valutatori dell’Unione Europea e i collaboratori delle aziende esterne. Importante definire inoltre le relazioni per la comunicazione fra i vari partner, creando molti canali di comunicazione e ben funzionanti assegnando ad essi personale adatto e qualificato. Siccome il progetto in esame è un progetto di ricerca risulta adeguato dilatare opportunamente le tempistiche di alcune fasi e preventivare almeno una iterazione aggiuntiva per eventuali evoluzioni delle funzionalità e degli scopi del progetto. Il pessimismo nella stima è caratteristica di capacità 45
    • realistiche dell’azienda e diminuisce il rischio di disillusioni per il protrarsi del termine di sviluppo. Inoltre nel qual caso tutto procedesse al meglio ci si troverebbe ad aver ultimato il compito prima della scadenza dichiarata lasciando tempo per rifiniture successive del prodotto che aumentano la soddisfazione 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 la metodologia di sviluppo, la struttura e il contenuto dei deliverables, la frequenza e la profondità dei controlli periodici di avanzamento del lavoro; ma soprattutto definire ad un livello sufficiente di dettaglio le sottofasi della Analisi e della Progettazione indicandone subito le dipendenze al fine di evitare parallelismi impossibili. L’ideale sarebbe ottenere un diagramma di Gantt funzionale delle fasi di analisi e progettazione includendo, come precedentemente menzionato, le dilazioni opportune dei tempi e alcune fasi riparatorie per fornire un margine accettabile alle incertezze non meglio quantificabili ad inizio del progetto. Questo diagramma ovviamente non può essere assolutamente definitivo ma deve aiutare a programmare il lavoro evolvendo assieme alla precisa definizione del progetto. 46
    • 5. Approccio Lo sviluppo effettivo di un progetto di ricerca internazionale e collaborativo sarà estremamente complesso, specialmente dal punto di vista coordinativo. Come è stato visto dall’analisi delle problematiche principali riscontrabili in questo tipo di progetto, la maggior parte delle difficoltà saranno per l’appunto dovute alla distribuzione e al controllo dei compiti. I dettagli dei ponti di collegamento possibili fra le varie aziende ed eventuali raccomandazioni su essi sono di scarsa importanza dal punto di vista della metodologia a cui bisognerà ricorrere. Questo poiché il come si collabora influisce parzialmente sulle fasi da intraprendere e dagli artefatti da realizzare, al più implicherà delle restrizioni sulla lingua utilizzata o sulle tempistiche di produzione. Lo stesso discorso è applicabile anche alle problematiche di stima dei tempi di progetto, il fatto che il tempo previsto subisca dei dilatamenti dovuti alla struttura dell’azienda sviluppatrice non sarà direttamente imputabile alla metodologia applicata bensì alla complessità della struttura. Infatti si può affermare che, qualsiasi sia il metodo di lavoro scelto, la probabilità di un ritardo è comunque stabile e principalmente dipendente dall’organizzazione su cui viene applicato tale metodo. L’unica problematica rimanente è quindi la presenza di differenti competenze distribuite all’interno delle varie aziende affiliate e dei gruppi di lavoro. Ciò porta ad un bivio di entità notevole, o si opera una pesante istruzione del personale per eliminare il problema o si attua una modifica della metodologia al fine di poter essere approcciata anche da chi ha scarse nozioni in tale materia. 47
    • La situazione ideale prevedrebbe ovviamente il colmare le lacune del personale, investendo così sui propri dipendenti ed aumentando il valore della propria azienda. Ma una manovra del genere nella pratica è estremamente difficile, specialmente data la natura internazionale del progetto in esame. D’altro canto un livellamento troppo drastico di una qualsiasi metodologia otterrebbe sì un facile assorbimento dal personale non competente, ma comporterebbe senza ombra di dubbio degli effetti negativi enormi sul prodotto finale. A seguito di queste ultime considerazioni si deve prendere atto che l’una o l’altra via non sono percorribili nella realtà di un progetto internazionale, a parte rari casi. In generale quindi l’approccio applicabile consisterebbe in uno snellimento di una metodologia molto versatile, al fine di poter effettuare con un buon livello di dettaglio le fasi principali previo breve istruzione del personale. Alcune fasi o artefatti delle metodologie di progetto infatti non sono particolarmente complesse e un dipendente medio può riuscire a svolgerle con successo senza particolari preparazioni, ma con sicuramente l’ausilio di una buona documentazione. Data la necessità di flessibilità e di segmentazione necessarie ad una metodologia per poter essere snellita in modo proficuo al fine preposto, si prenderà in considerazione l’approccio iterativo ed incrementale messo a disposizione dal Rational Unified Process. Esso infatti risulta essere un metodo incredibilmente ampio e versatile, proprio per sua costruzione, e quindi perfettamente aderente al problema in esame. L’obiettivo quindi è proprio l’identificazione di una fetta del RUP che calzi con il progetto in lavoro, ovvero trovare una buona guida metodologica per permettere una buona organizzazione e resa lavorativa. 48
    • Inserendo questo lavoro in un progetto di ricerca già avviato da diversi anni come Euridice, risulta difficoltoso estendere questa procedura sull’intera metodologia. Inoltre un tale compito risulterebbe di difficoltà ben più elevata e sicuramente l’aprirsi di una discussione generale sullo snellimento del RUP in tutte le sue fasi per l’applicazione a progetti del tipo sopraesposto comporterebbe discussioni pressoché infinite nell’ambito analistico. Rifacendosi alle spiegazioni del metodo menzionate nel capitolo apposito presentiamo a seguire una figura esplicativa della struttura di un’iterazione prevista dal metodo RUP applicata ad Euridice. Come è visibile nella figura, le fasi iniziali sono state scomposte e dettagliate per fornire maggiore dettaglio. Inoltre si può osservare che sono state utilizzate le nomenclature tipiche dell’Unified Modeling Language. Per la fase di analisi si è applicato ovviamente la Use Case Analysis o Analisi per casi d’uso. 49
    • Lo sviluppo di Euridice era per l’appunto giunto alla conclusione della fase di analisi. Sarà ora necessario cimentarsi nella fase di progettazione, che nel caso specifico includerà la realizzazione dei casi d’uso definiti nella fase di analisi. Lo scopo è quindi quello di identificare il numero minimo di artefatti necessari ad una completa progettazione, seguendo il metodo della realizzazione dei casi d’uso facendo riferimento al linguaggio UML. 50
    • 5.1 Guida Metodologica alla progettazione Vengono di seguito descritti brevemente i fondamenti necessari alla comprensione degli artefatti risultanti dalla fase di analisi per poter poi proseguire correttamente nella progettazione. Essendo la realizzazione dei casi d’uso tramite diagrammi UML un approccio visuale alla progettazione degli stessi, esiste un vasto numero di modi per procedere. Inevitabilmente lavorando in modo visuale si può cogliere il sistema in esame da un solo punto di vista, quindi è scontato che saranno necessari vari diagrammi per una rappresentazione completa del caso. Verrà reso necessario e quindi descritto il minor numero possibile di diagrammi cercando comunque di mantenere una completa definizione nella realizzazione del caso d’uso. Inoltre il metodo UML mette talvolta a disposizione più diagrammi che rappresentano lo stesso concetto ma in maniere differenti. In caso tale punto di vista sia rivesta fondamentale importanza nella definizione della UCR allora si propenderà per quel diagramma più semplicemente sviluppabile. Use Case I casi d’uso costituiscono un ottimo strumento per ottenere una visione d’insieme del sistema che si sta analizzando, rappresentano un comportamento dal punto di vista dell’utilizzatore del sistema e sono finalizzati a modellare il dialogo tra utilizzatore e sistema. Per questo si dice che i casi d’uso forniscono una visione del progetto. Infatti essi: • descrivono l’interazione fra attori e sistema, non la logica interna della funzione; 51
    • • sono espressi in linguaggio naturale e sono comprensibili anche a lettori non tecnici; • descrivendo i casi d’uso si definiscono i requisiti funzionali di progetto; • possono essere un valido ausilio nel dialogo con l’utente ed in generale con esponenti non tecnici; L’attore è un’entità esterna al sistema, può essere umano o un altro sistema, che fornisce lo stimolo a cui esso risponde con specifici comportamenti. Tutto ciò è definito nella Analisi dei casi d’uso che si conclude quando la maggior parte dei casi d’uso è stata descritta. Per ognuno di essi devono essere stati definiti: precondizioni, attori coinvolti, obiettivi, svolgimento principale degli eventi dello scenario, svolgimenti alternativi e post condizioni. Nella fase di design si dovrà prendere in considerazione quindi questi casi d’uso e delle loro descrizioni, che sono il risultato della fase di analisi, ed iniziare a definirli prendendo in considerazione anche i requisiti tecnologici che vengono scelti per il progetto. 52
    • Lo scopo essenziale è chiarire come gli attori interloquiscano con i vari casi d’uso e di che dati abbiamo effettivamente bisogno per operare. Allo scopo di fare ciò si tenderà per un approccio visuale utilizzando lo standard UML anche se sarà necessario allegare comunque una buona documentazione scritta. Use Case Realization La realizzazione dei casi d’uso, o UCR, rappresenta la prospettiva della progettazione dei casi d’uso derivati dalla fase di analisi. Ogni artefatto prodotto durante la fase di design andrebbe associato al caso d’uso da esso analizzato, ma proprio per poter disaccoppiare la fase di analisi da quella di design si introduce il concetto di UCR. Siccome nella fase di design si deve tener conto dei vincoli tecnologici si può intuire che un singolo caso d’uso può essere progettato in più modi diversi. Quindi possono esistere diversi UCR associati allo stesso caso d’uso, e siccome gli artefatti della fase di design vengono di conseguenza associati allo specifico UCR si facilità la gestione separata degli use case realizzati nella fase di analisi dalla loro realizzazione. Questa strategia è particolarmente indicata per progetti di grandi dimensione ove lo stesso caso d’uso può essere progettato in modo diverso per la necessità del suo utilizzo su diverse piattaforme. Per rappresentare tutto ciò si utilizza un diagramma della realizzazione dei casi d’uso sarà semplicemente sufficiente trattare ogni UCR come una generalizzazione dei caso d’uso con una notazione del tipo UC UCR come è 53
    • visibile nella figura successiva. Per ogni UCR è necessario identificare gli oggetti che partecipano alla composizione del caso d’uso. Al fine di descrivere completamente un caso d’uso il linguaggio UML mette a disposizione una grande varietà di diagrammi. Lo scopo di questa fase è di identificare per ogni UCR tutti gli elementi statici e dinamici coinvolti. Gli elementi statici di un oggetto sono i dati persistenti di cui necessita per operare e le relazioni che lo legano ad altri oggetti. Gli elementi dinamici invece possono essere descritti come le modalità di collaborazione fra oggetti per 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 sistema Per ogni use case realization si dovranno evidenziare almeno tre oggetti: un’Entità, un’interfaccia e un controllo. 54
    • La figura seguente mostra un diagramma per la realizzazione di un caso d’uso “Receive Deposit Item”, si può notare che il livello di descrizione è molto alto e serve quindi solo ad identificare gli oggetti coinvolti. Una classe e i suoi oggetti possono spesso partecipare a svariate realizzazioni differenti di un caso d’uso. Definendo gli UCR probabilmente si nota che alcuni oggetti vengono impiegati in un numero elevato di casi. È consigliato dunque controllare come un oggetto debba essere realmente strutturato per favorirne la riusabilità attraverso i vari UCR. I diagrammi più importanti per la corretta realizzazione dei casi d’uso sono i seguenti: • Sequence Diagram : descrive un preciso scenario di un caso d’uso seguendone la linea temporale • Class Diagram : evidenzia i contenuti statici del caso d’uso • State Diagram : analizza il comportamento e la vita di un oggetto attraverso tutti i casi d’uso che lo utilizzano Nelle descrizioni seguenti verranno fornite delle semplici esemplificazioni di ogni tipo di diagramma per permetterne una più rapida comprensione. Inoltre nel Capitolo 6 verranno applicati praticamente ad un 55
    • caso d’uso di Euridice fornendo un ulteriore approfondimento al metodi di sviluppo dei sopra esposti diagrammi. 56
    • Diagrammi di Sequenza Il diagramma di sequenza rientra negli Iteration Diagrams. L’obiettivo di questa categoria di diagrammi è descrivere come un gruppo di oggetti cooperi per realizzare una funzione. Nello specifico del Sequence diagram, esso analizza un singolo svolgimento del caso d’uso (principale o alternativo) e il modo in cui viene svolto dalla collaborazione tra un insieme di oggetti, specificando la sequenza dei messaggi scambiati tra gli stessi. Possono essere evidenziati nodi decisionali e/o iterazioni. Questo tipo di diagramma viene anche detto di interazione in quanto mostra le interazioni tra oggetti del sistema, modella il comportamento dinamico del sistema ed evidenzia in particolare l’ordine temporale dello scambio di messaggi. Tutti i tipi di oggetto che vengono richiamati per svolgere l’interazione devono essere rappresentati da un riquadro nella parte superiore del diagramma. Le linee verticali rappresentano la linea della vita, o lifeline, dell’oggetto suo proprietario nell’arco di durata dell’interazione. Per mostrare quando un oggetto è attivo si include un riquadro di attivazione che viene riportato sulla sua lifeline. Quando un oggetto viene eliminato si appone una “X” sul punto temporalmente corretto e si interrompe la sua lifeline. Tutti i messaggi scambiati fra due oggetti durante la loro vita sono rappresentati da una freccia del tipo sorgente→destinatario e per ognuna di loro deve essere indicato almeno il nome di tale messaggio. Possono poi essere presenti messaggi prodotti dallo stesso oggetto che ne è il destinatario, essi si chiamano self-call. Importante sottolineare che nonostante la notazione 57
    • del messaggio, esso rappresenta la chiamata del sorgente ad una funzione del destinatario. I messaggi possono essere fondamentalmente di due tipi: • Sincrono l’emittente attende una risposta da parte del destinatario • Asincrono la risposta del ricevente, se è contemplata, potrà essere inviata in un qualsiasi momento successivo Se un messaggio ha una condizione per il suo invio si parla di messaggio condizionato e viene rappresentato tramite la specifica in parentesi quadre della sua condizione di invio. Questi messaggi vengono inviati quindi solo se al percorri mento temporale sulla lifeline dell’oggetto tale requisito è soddisfatto nel superamento del messaggio condizionato. Per indicare una iterazione di un messaggio si indica all’inizio del nome dello stesso un “ * ”, questo starà a significare che il messaggio in questione viene inviato più volte a più oggetti che però rientrano nella stessa categoria. 58
    • Generalmente si consiglia l’utilizzo di descrizioni testuali sulla parte sinistra del diagramma in tutti gli snodi principali per favorirne la leggibilità. Diagrammi delle Classi L’obiettivo dei diagrammi delle classi è visualizzare la parte statica del sistema rappresentando tutti gli oggetti, con i relativi attributi ed operazioni, che lo compongono. I collegamenti fra le classi rappresentano le associazioni che intercorrono fra esse. Tali associazioni possono essere corredate da un insieme di informazioni aggiuntive, per esempio relative alla molteplicità: • Uno-a-uno ad ogni occorrenza dell’oggetto A si può associare univocamente un’occorrenza dell’oggetto B e viceversa; (Es° dipendente↔matricola) • Uno-a-Molti per ogni occorrenza dell’oggetto B si può associarne una sola dell’oggetto A, ma per ognuna dell’oggetto A possono essercene un qualsiasi numero dell’oggetto B associate; (Es° Project Manager↔Progetto) • Molti-a-Molti: per ogni occorrenza dell’oggetto A si possono associare più occorrenze dell’oggetto B e viceversa; (Es° deliverable↔autore) È consigliato inserire una nomenclatura alle associazioni la dove ciò favorisca una maggiore leggibilità al diagramma. 59
    • Questi diagrammi utilizzano diversi concetti base del paradigma Object-Oriented ed altri correlati, fra questi se ne distingueranno per importanza quattro: Aggregazione, Composizione, Dipendenza e Generalizzazione. Ognuna delle sopra citate viene rappresentata mediante una particolare freccia che connette le due classi coinvolte. L’aggregazione è un particolare tipo di associazione che prevede una relazione fra delle entità autonome ed una che può essere definita solo dalla, per l’appunto, aggregazione di esse. Un buon esempio risulta un automobile: essa è composta dall’aggregazione di carrozzeria, motore, ruote e così via. La composizione è una relazione forte, può essere descritta in maniera similare all’aggregazione con la differenza che le entità che vengono messe in relazione di composizione seguono poi il ciclo di vita dell’istanza composta. Importante sottolineare che ogni oggetto può essere componente di un solo oggetto composto alla volta, il che differisce palesemente dall’esempio utilizzato in precedenza dell’automobile; ove per esempio un motore può essere montato su più tipi di auto. Una associazione di dipendenza sta ad indicare che un cambiamento di un attributo di una classe può andare richiedere modifiche negli attributi dell’altra, non necessariamente è implicato il viceversa. Alcune classi possono avere diverse varianti, ed ogni variante può avere diversi ruoli nel sistema. Per rendere tutto ciò rappresentabile in un diagramma delle classi si ricorre al concetto di generalizzazione. Essa si indica con una freccia del tipo sottoclasse sopraclasse come si può vedere nella figura seguente per LibroPregiato che specifica l’oggetto Libro. Il significato di tale azione e della notazione sono sufficientemente espliciti da non richiedere ulteriori dilunga menti in proposito. 60
    • Ogni oggetto viene rappresentato tramite un rettangolo suddiviso in tre scomparti, rispettivamente dedicati al nome della classe, agli attributi e alle operazioni. La visibilità di ogni attributo e di ogni operazione è specificata in UML attraverso 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
    • Gli attributi devono essere indicati per nome con eventualmente il tipo e il valore di default seguendo il seguente standard: “ nome_visibile : tipo = valore_default ” Es° “ autore_anno_morte : data = Null ” L’elenco delle operazioni evidenziate in questo diagramma rappresenta l’insieme delle principali operazioni eseguibili all’interno dello UCR. Importante è specificare che non tutte le operazioni delle classi hanno lo stesso impatto sul sistema. Infatti risulta estremamente utile distinguere le semplici query (operazioni sugli attributi) da quelle operazioni che vanno a modificarli (operazioni di update). La sintassi completa per la descrizione delle operazioni in UML è la seguente: “ nome_visibile ( lista parametri ) : tipo_risultato_op {proprietà} “ Es° “ libro_pregiato_valorizza ( ) : float { } “ 62
    • Diagrammi di Stato È utile utilizzare il diagramma di stato per evidenziare come si comporta un oggetto attraverso più casi d’uso, esso infatti specifica tutto il ciclo di vita di tale oggetto e definisce le regole che ne governano le transizioni di stato. Risulta chiaro dunque descrivere questo tipo di diagramma come un automa a stati finiti, pertanto esso sarà costituito da stati, attività e transizioni. Quando un oggetto è in un certo stato infatti, solo determinati eventi causeranno una transizione di stato e non tutti. Viene utilizzato principalmente come completamento della descrizione degli oggetti. Data la sua natura specifica non risulta sempre naturale svilupparlo correttamente e può sembrare non sempre utile al procedere del lavoro, infatti è direttamente dipendente del progetto quali diagrammi siano più o meno efficaci per procedere. 63
    • Il punto di partenza è chiaramente indicato nel digramma, così come ogni stato è collocato in un riquadro con all’interno il suo nome ed eventuali attività ad esso associato. Ogni transizione è graficamente indicata da una freccia che deve presentare la così detta guardia dell’azione, ovvero una condizione che solamente se risulta essere vera mette in opera la transizione di stato. Nulla vieta di mettere in evidenza self-transition importanti che benché non determinino un cambiamento di stato possono stare ad indicare particolari operazioni periodiche di controllo o comunque degne di nota ai fini progettuali. Importante in questi diagrammi è mettere in evidenza eventuali stati morti, ovvero quegli stati che presentano una o più transizioni in ingresso ma nessuna in uscita. Inoltre possono essere dichiarate Super-stati, che vengono rappresentati da un riquadro che include tutti gli stati che ne fanno parte. Questa tecnica è utile per introdurre eventuali controlli aggiuntivi. Per esempio essi possono essere temporali, nel caso si voglia intraprendere un’azione al decorrere di un certo periodo senza il verificarsi di un cambiamento di stato, o condizionali quando si vogliono effettuare dei controlli più specifici. Poniamo un esempio con riferimento all’immagine precedente: evidenziando un superstato “In Movimento” andando ad inglobare gli stati “ascesa al piano” e “scesa al piano” possiamo notare che abbiamo solo due tipi di transizioni, ovvero “richiesta piano” e “raggiungimento piano”. Se poniamo 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 stato morto di “Guasto”. 64
    • Diagrammi di Collaborazione Il diagrammi di collaborazione, come il diagrammi di sequenza, rientrano nella categoria dei diagrammi di interazione. Essi mirano a mostrare le collaborazioni e le interazioni tra le istanze specifiche che realizzano i casi d’uso. Questo tipo di diagramma, in particolare, specifica gli oggetti che collaborano tra loro in un certo scenario ed enfatizza le relazioni strutturali tra 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 sono effettivamente molto simili. Infatti si può passare agevolmente dall’una all’altra rappresentazione e si differenziano per l’aspetto dell’interazione che enfatizzano. Nei diagrammi di sequenza il concetto fondamentale è l’evoluzione temporale del singolo caso d’uso attraverso gli oggetti coinvolti, mentre nei diagrammi di collaborazione vengono evidenziati i legami tra gli oggetti. Risulta quindi semplice utilizzare questa rappresentazione per definire una scomposizione funzionale degli oggetti implicati, ad esempio la definizione di packages. Per tracciare correttamente un diagramma di collaborazione vengono rappresentati tutti gli oggetti coinvolti tramite dei riquadri contenenti i loro nomi. Ogni messaggio viene rappresentato da una freccia con terminazione dipendente se il mittente attenderà la risposta in tempo reale o meno. Su ognuna delle frecce figuranti i vari messaggi devono essere apposti dei nomi identificativi degli stessi seguendo una numerazione progressiva che permetta di dare un senso sequenziale all’insieme dei messaggi. 65
    • Viene applicata una numerazione a tutti i messaggi per evidenziarne la successione delle relazioni ma ovviamente questo metodo rende più difficoltoso visualizzare la corretta successione delle interazioni fra gli oggetti rispetto ad una linea temporale delle azioni verticale. Nelle prime raffigurazioni UML si utilizzava una notazione numerica intera progressiva, essa però non risulta di facile lettura nel caso di un insieme complesso di messaggi. Un buon esempio del perché tale notazione risultasse complicata era poiché si potevano avere gap notevoli fra operazioni indotte dal medesimo messaggio ma raffigurate sequenzialmente con tutto il loro svolgimento nel diagramma. 66
    • Un esempio di immediata comprensione può essere un ordine a magazzino: GESTIONE ORDINI MAGAZZINO 1:preparazione ordine () 2: presente:=controlla () 3: [presente]:aggiorna il magazzino() 4: necessario:=necessità riordino () 5: [necessario]:nuovo riordine () 6:[presente]:aggiunta in ordine() Come si può vedere chiaramente nella prima colonna ci sono i messaggi riferiti alla gestione ordini e nella seconda al magazzino. Risulta quindi chiaro che tra la prima operazione e la sua diretta conseguenza nella condizione ideale 1->2->6 è presente un divario numerico notevole considerata la natura dell’esempio. Proprio per risolvere questo problema è stata introdotta la notazione numerica decimale di sequenza, simile alla convenzione per le versioni software. Riproponiamo quindi lo stesso esempio con la nuova notazione: GESTIONE ORDINI MAGAZZINO 1 : preparazione ordine () 1.1 : presente:= controlla () 1.2 : [presente]: aggiorna magazzino() 1.2.1: necessario:= necessità riordino() 1.2.2 :[necessario]: nuovo riordine() 1.3:[presente]:aggiunta in ordine() 67
    • Risulta immediato come una tale numerazione indica più semplicemente ed efficacemente la dipendenza dei messaggi e i vari cammini alternativi, senza tuttavia eccedere con il valore numerico. Un’altra convenzione sui messaggi è di evidenziare in parentesi quadre le condizioni di invio e in parentesi tonde l’insieme di parametri da inviare con essi. Si possono distinguere i messaggi semplici dai condizionati ovviamente per la presenza degli elementi in parentesi quadra, mentre per evidenziare i messaggi iterati si applica sul numero degli stessi un asterisco “ * ”; come visibile nella figura precedente. 68
    • 6. Progettazione di un Caso d’uso Per dimostrare quindi l’efficacia del metodo di lavoro scelto e la completezza dei diagrammi descritti per la definizione della realizzazione di un caso d’uso, si procede ora ad un esempio pratico di applicazione. Per lo scopo viene scelto lo scenario S7 che si colloca nei trasporti su strada destinati al passaggio dei Trasporti merce al confine sloveno. L’obiettivo è di evitare la congestione e gli incidenti ottimizzando l’utilizzo delle infrastrutture stradali e dei parcheggi attraverso: • il ricalcolo automatico del percorso del mezzo in base al suo carico, al suo stato, al traffico e le condizioni meteo e le disponibilità nelle aree di parcheggio; • il dialogo fra il cargo e il gestore dell’infrastruttura SDAG allo scopo di acquisire le autorizzazioni necessarie e la prenotazione di un parcheggio; • la diagnosi di eventi anormali sul carico e l’automatizzazione dell’intervento dei sistemi di sicurezza della struttura di sosta; Una particolarità di questo scenario è che in presenza di vento forte viene impedito il transito in Slovenia a determinati tipi di automezzi, rendendosi quindi necessaria la sosta presso apposite zone di sdoganamento. Nel caso specifico si fa riferimento alla S.D.A.G. - Stazioni Doganali Autoportuali Gorizia. Per identificare la collocazione dell’esempio di progettazione di un caso d’uso adatto si ispeziona il frutto della fase di Analisi già portata a termine nello sviluppo del progetto Euridice. Il deliverable W26 descrive, tramite la analisi per casi d’uso, cosa dovrà fare il pilota dello scenario S7. 69
    • Per facilitare la comprensione delle figure seguenti si introduce una breve descrizione degli attori coinvolti nello scenario s7. Nome Attore Descrizione Producer Il produttore è la compagnia responsabile per la produzione e la contrassegna delle merci Carrier Il corriere rappresenta la ditta individuale incaricata per il trasporto delle merci da Milano in Slovenia Infrastructure Operator Indica il generico operatore dell’infrastruttura su cui si muovono le merci SDAG SDAG è il responsabile per la gestione delle aree di posteggio e servizio di dogana goriziano EPSA Euridice Pilot System Application, è un sistema che combina le componenti di Euridice per realizzare delle specifiche applicazioni utente Intelligent Cargo Rappresenta l’insieme di controlli e sistemi del Cargo che prende attivamente parte ai processi di business 70
    • Come è evidenziato dalla figura seguente si sono andati a definire quattro casi d’uso principali: l’identificazione del cargo, la rivelazione di anomalie sul percorso e il ricalcolo automatico, la prenotazione automatica delle aree di parcheggio, la gestione del sistema di sicurezza. Andando al livello di dettaglio successivo del caso d’uso “UC3 – Automation of pre-booking of parking areas” si può notare come la struttura dell’analisi per casi d’uso sia estremamente vasta ed ogni piccola parte può essere scomposta in successivi casi da analizzare e descrivere. 71
    • Si prenda in considerazione dunque il “WP26.P2.UC3.2 update cargo status”. La notazione indica che è il secondo caso d’uso della scomposizione del terzo Use Case del pilota 2 del Workpackage 26. Si veda ora la descrizione testuale che viene associata ad ogni singolo UC: Nome del UC Aggiornamento dello stato del cargo (Update cargo status) ID caso d’uso WP26.P2.UC3.2 Obiettivo Aggiornare lo stato del cargo notificando il cambiamento dipendentemente dal contesto ai vari attori coinvolti Descrizione Il cargo aggiorna il suo stato quando entra ed esce dall’area SDAG Attori Principali Intelligent Cargo SDAG Importanza Alta Precondizioni Il cargo è riconosciuto ed identificato nel sistema Flusso principale Aggiornamento dello stato del cargo sull’ingresso nella zona Una volta arrivato nell’area SDAG il cargo entra nella zona dei parcheggi e si dirige al suo posto. EPSA comunica che il mezzo è arrivato al carrier, a SDAG e all’impresa di import-export. Lo stato del cargo viene aggiornato. Di particolare importanza: posizione, data, ora. Il nuovo stato viene registrato in EPSA. Aggiornamento dello stato del cargo sull’uscita dalla zona Quando il cargo esce dall’area SDAG, l’Intelligent Cargo comunica con EPSA aggiornando lo stato. Di particolare importanza: posizione, data, ora. Questi dati vengono registrati in EPSA. EPSA comunica che il cargo ha lasciato l’area SDAG al cliente finale Post condizioni Lo stato del cargo è aggiornato. Flussi alternativi 72
    • 6.1 Considerazioni generali sulla realizzazione di un caso d’uso Una volta identificato quale caso d’uso realizzare però non è sufficiente una mera applicazione dei metodi descritti. Come era stato già accennato, un risultato della fase di analisi così alto lascia una grande libertà di manovra nella successiva fase di progettazione. Di fondamentale importanza quindi individuare da subito quali saranno i pilastri del caso d’uso specificati nella use case analisi. Con ogni probabilità essi saranno essenziali ponti di collegamento con altre parti del progetto e quindi non possono essere modificati minimamente dalla progettazione del caso. Nel capitolo precedente si è definita una linea guida abbastanza precisa su come operare, a cui ci si atterrà. Rifacendosi al discorso affrontato nelle considerazioni di un progetto internazionale collaborativo sviluppato da un consorzio di aziende è facilmente intuibile l’utilità di utilizzo degli UCR. La possibilità di associare più realizzazioni allo stesso UC può essere utilizzata non solo per effettive differenze di piattaforma su cui vanno implementati i casi d’uso, ma anche come metodo di verifica e di scambio di opinioni all’interno del gruppo di aziende associate. In un ambiente in cui il lavoro viene distribuito fra gruppi con competenze variegate, difficilmente è possibile operare lo stesso livello di controllo su tutti i gruppi impegnati nella progettazione. Per una più rapida distribuzione delle conoscenze necessarie ad operare si può incaricare due gruppi paralleli di progettare il medesimo caso d’uso per poi metterli a confronto per ottenere una realizzazione più completa. 73
    • Il principale problema della progettazione infatti è riuscire ad affrontare il problema descritto negli use case isolando correttamente il suo dominio ed analizzandolo da ogni punto di vista nel modo più completo possibile. Proprio per questo motivo sono consigliate fasi di brainstorming per trovare idee per strutturare la realizzazione del caso d’uso. Dalle considerazioni precedenti risulta quindi chiaro che la fase di progettazione otterrà un risultato di certo migliore se strutturata in modo tale da mettere a lavorare gruppi di persone. Deve essere presente una buona collaborazione all’interno del gruppo e soprattutto deve essere presente almeno una figura specializzata addetta, anche se non a tempo pieno, al controllo dell’operato. Durante il periodo di tirocinio ho personalmente partecipato a riunioni di brainstorming dedicate proprio alla progettazione dei casi d’uso. Posso testimoniare quindi per esperienza diretta che parlando con altre persone occupate sul progetto si chiariscono le inevitabili incomprensioni che possono sorgere in progetti così vasti, e si affrontano tematiche lasciate erroneamente in secondo piano. La tecnica di brainstorming applicata praticamente alla progettazione risulta molto utile, forse per la stessa natura della fase (ovvero finalizzata a specificare il “come” fare qualcosa) risulta particolarmente efficace la discussione di ogni possibile modo possibile di operare. 74
    • 6.2 Progettazione esemplificativa del Caso d’uso WP26.P2.UC3.2 Si procede ora alla progettazione effettiva del caso d’uso scelto tramite a realizzazione dei diagrammi e il susseguirsi delle fasi descritte in precedenza. Può risultare utile approfittare dell’ispezione al risultato dell’analisi del caso d’uso UC3 per operare una piccola correzione al diagramma UML. Nel tracciare questo tipo di diagrammi non dovrebbe fare la sua comparsa il sistema in sviluppo, ovvero l’EPSA, poiché non è certamente il sistema in costruzione ad scatenare l’evento che genera questo caso di utilizzo dell’EPSA. Le cause potrebbero essere introdotte dalla condizione rilevata di vento forte che va poi ad influenzare il sistema mettendolo così nell’ottica di questo caso. Ipotizzando l’attore WeatherCriticalService che genera l’input al sistema in caso di mal tempo rilevato, si può modificare così il diagramma UML. WP26.P2.UC3.1 Book a place in the parking area SDAG WeatherCriticalService WP26.P2.UC3.2 update cargo status Intelligent Cargo Carrier 75
    • Per coerenza con il metodo scelto prima di ogni altra cosa si associa lo Use Case Realization al caso d’uso WP26.P2.UC3.2. WP26.P2.UC3.2 update cargo status WP26.P2.UCR3.2 prova Da questo momento ogni considerazione viene riferita al “WP26.P2.UCR3.2 prova” che rappresenta una possibile realizzazione del caso d’uso originario. Si procede all’ispezione della descrizione del caso d’uso cercando di isolare correttamente il dominio di esso. Per introdursi alla progettazione vera e propria è conveniente realizzare una rappresentazione sommaria degli elementi coinvolti per stabilire quali elementi della logica di business saranno coinvolti nel caso d’uso, quali interfacce saranno necessarie per gli input/output di funzionamento del caso e soprattutto su quali dati esso andrà ad operare. Un buono strumento per operare in questo primo passo di raffigurazione per diagrammi del caso d’uso è fornito da quello che si potrebbe definire un diagramma delle classi semplificato o diagramma ECI (Entità Controllo Interfaccia). Tutte le informazioni essenziali al suo corretto tracciamento sono state descritte nella sezione dedicata ai diagrammi della progettazione nella guida metodologica stilata in precedenza. 76
    • Dopo attenta analisi e con alcune evoluzioni successive è stato individuato il seguente diagramma ECI per l’UCR3.2: Area Parking PositionControl PositionAreaChecker Cargo NotificationControl Cargo Status Notification MobileNotification SOAPNotification Inizialmente erano state definiti solo tre elementi basilari (un controllo, un’interfaccia e un’entità) per poi andare ad espanderli fino al raggiungimento dell’attuale diagramma ECI. Il “PositionControl” e il “PositionAreaChecker” inizialmente erano un unico controllo, ma analizzando meglio le specifiche dei dispositivi montati sui cargo si è pensato di separare la reale logica di controllo dell’appartenenza ad un’area di parcheggio dalla semplice identificazione della posizione del cargo. Questa seconda funzione infatti è delegata al GPS del cargo che mantiene traccia continua delle sue coordinate geografiche. In questo modo il “PositionControl” ha le coordinate del cargo, mentre il controllo vero e proprio sarà un evento periodico affidato principalmente al “PositionAreaChecker”. Come suggerisce il nome esso avrà il compito di 77
    • controllare se il cargo è o meno in un’area conosciuta, ovvero la zona di parcheggio SDAG. I dati che serviranno per operare al “PositionAreaChecker” saranno quindi le coordinate del cargo, fornite dall’altro controllo, e le coordinate dell’area conosciuta. Per precisazione le zone doganali SDAG sono divise in parcheggi composti da diverse piazzole per i vari tipi di carichi, a loro volta suddivisi nei posteggi numerati veri e propri. Per semplicità si è indicata la natura composta dei dati mediante l’associazione all’entità Area di un’altra entità Parking contenente i dati relativi alle zone di parcheggio. L’obiettivo centrale del caso d’uso 3.2 è di aggiornare lo stato del Cargo. Esso sarà senz’altro un attributo dell’entità Cargo. Pensando alle utilità effettive della modifica di stato però ci si rende facilmente conto che non è un banale aggiornamento di un attributo a spingere il sistema ad effettuare questo controllo periodico, bensì la necessità di informazione riferita alla posizione del cargo in tempo reale. Viene così introdotta l’idea di uno storico degli stati del cargo, rappresentato dall’entità Cargo Status associata al Cargo. La tenuta di uno storico degli stati del cargo è un ottimo incremento di utilità di questa funzione, anche se la sua presenza non era specificata letteralmente nell’analisi di questo caso d’uso. Il problema delle notifiche poteva sembrare irrilevante a primo impatto, ma essenzialmente servirà un controllo adibito al compito per identificare che tipo di variazione di stato è avvenuta e di conseguenza generare, o richiedere, le notifiche. Si può parlare di richiedere poiché nella UCR non si collocano definitivamente le locazioni delle varie componenti nel sistema, ma si cerca di identificare ciò di cui ci sarà bisogno per svolgere i compiti preposti e soprattutto come svolgerli. 78
    • Per rappresentare l’importanza della identificazione e generazione delle notifiche sono stati introdotti nel diagramma ECI: un controllo “NotificationControl” che verrà adibito ad identificatore delle notifiche necessarie in corrispondenza a quale variazione di stato è avvenuta e un’interfaccia “Notification” che si occuperà dell’invio delle notifiche ai vari destinatari. Prendendo in considerazione i vari tipi di comunicazione delle notifiche però si individuano due metodologie principali. La prima avverrà attraverso una notifica web che interesserà le società coinvolte. Non si può definire a questo livello di dettaglio se questo tipo di notifica avverrà tramite messaggio di posta elettronica o tramite aggiornamento delle informazioni visibili dai vari destinatari all’interno dei vari servizi offerti dal sistema, ma semplicemente identificandolo come processo necessario. Il secondo metodo è attraverso notifiche a cellulari, come per esempio all’autista del cargo. Per le stesse considerazioni prese in visione per la metodologia precedente non si potrà dire se tale notifica avverrà tramite sms o tramite email o qualche altro formato compatibile con il dispositivo mobile, ma come già detto questo non riveste fondamentale importanza a questo livello. Vengono così introdotte due generalizzazioni dell’interfaccia “Notification”, una per le notifiche indirizzate ai servizi web “SOAPNotification” e la seconda indirizzata alle notifiche per cellulari “MobileNotification”. È importante a questo punto ripercorrere velocemente la descrizione del caso d’uso in esame per assicurarsi che gli elementi principali coinvolti in ogni flusso possibile del caso siano presenti in questo primo diagramma delle classi semplificato. 79
    • 6.2.1 Diagramma di sequenza del Flusso principale Tramite il precedente approccio con un diagramma ECI si è provveduto ad identificare sommariamente tutti i vari elementi che verranno impiegati nei vari flussi del caso d’uso. Si è provveduto poi a stilare una spiegazione discorsiva delle funzioni degli elementi e delle motivazioni che hanno portato alla loro identificazione. Viene ora tracciato il diagramma di sequenza per il flusso principale del caso d’uso per determinare in che modalità e per quali fini ogni elemento comunicherà con gli altri durante il percorri mento normale del caso d’uso. Porre in evidenza le modalità e le motivazioni di interazione fra elementi porta anche alla identificazione dei metodi dei vari elementi. Venga ora descritto il flusso generico del caso d’uso in maniera discorsiva al fine di identificare tutti gli elementi coinvolti nella versione generica di sviluppo degli eventi. Il “PositionControl” mantiene le coordinate GPS attuali del cargo in continuo, esso quindi non avrà alcuna altra funzione di iniziativa. Il “PositionAreaChecker” dovrà effettuare un’operazione periodica di controllo per verificare se il cargo si è spostato all’interno o all’esterno di un’area. Per fare ciò avrà ovviamente bisogno delle coordinate GPS mantenute dal “PositionControl” e delle coordinate dei vertici dell’area nota su cui dovrà testare l’appartenenza. Queste ultime saranno memorizzate nella entità “Area”. In base al controllo appena effettuato sulla posizione viene identificato quindi lo stato attuale del cargo, esso va aggiornato nel storico mantenuto dall’entità “Cargo Status” prendendo qualche avvertenza nel caso esso sia effettivamente mutato nell’ultima iterazione. 80
    • A questo punto il “PositionAreaChecker” dovrà comunicare il suo operato al “NotificationControl” in modo che possano venir generate le notifiche necessarie al caso. Questa ultima operazione però deve essere eseguita solo in caso di una permutazione nello stato del cargo. Nel caso lo stato non abbia subito variazioni non c’è motivo di delegare la decisione di non-notifica ad un altro elemento, si decide quindi per tenere all’interno dell’elemento “PositionAreaChecker” anche questo tassello logico per evitare di creare interazioni inutili fra elementi. Rimangono a questo punto solo le operazioni di generazione effettiva delle notifiche necessarie con loro inoltro tramite l’interfaccia “Notification”. Si traccia ora il diagramma delle sequenze del flusso principale del caso d’uso basandosi esclusivamente sulla sequenza descrittiva appena espressa. Per chiarezza e leggibilità, tale diagramma viene riportato in una pagina dedicata. 81
    • <<control>> <<control>> <<entity>> <<entity>> <<control>> <<boundary>> PositionAreaChecker PositionControl Area Cargo Status NotificationControl Notification 1 : PeriodicalWakeup() 2 : ReadCoordinates() 3 : IsPositionWithinArea() 4 : check := IsPositionWithin() 5 [check] : changed := Refresh() Notify Menagement 6 [changed] : NotifyRequest() 7 : NotifyGenerator() 82 8 : SendNotify()
    • Per snellire il diagramma di sequenza sono state eliminate, come di consuetudine, tutte le risposte tipiche ai messaggi rappresentati. Sono indicate inoltre molte variabili condizionali che permettono la rappresentazione unica di buona parte della casistica del flusso principale. Per limitazioni del software freeware utilizzato non è possibile visualizzare a schermo nei diagrammi tutte le variabili passate nell’attivazione dei metodi, esse appaiono infatti nell’ispezione del formato elettronico nelle proprietà dei vari messaggi. Questo fatto è stato sottolineato per una possibile piccola incomprensione nella struttura della casistica dei messaggi 4 e 5. Sembrerebbe che se il valore di ritorno del metodo “IsPositionWithin()” non è tale da innescare il messaggio 5, allora non si assegna un valore alla variabile che funge da condizione per il messaggio 6. Ovviamente all’effettiva realizzazione del sistema queste variabili non serviranno semplicemente a definire se un messaggio deve o non deve essere inviato, infatti all’interno della stessa riga condizionata per il messaggio 5 potrà esserci comunque un riferimento per impostare un valore dell’altra variabile nel caso di “else”. Questo fraintendimento è dovuto alla impossibilità di rappresentare efficacemente su questo tipo di diagrammi la casistica dato che essi sono preposti essenzialmente all’analisi di un unico flusso alla volta. In questo diagramma si è operato lo stesso in quanto era un caso relativamente semplice da rappresentare e comunque è prevista la presenza di una descrizione testuale esplicativa delle scelte effettuate. 83
    • 6.2.2 Diagramma delle classi del Flusso Principale In base alle considerazioni fatte e alle interazioni individuate fra gli elementi essenziali nel diagramma delle sequenze ora si disegna la prima versione del diagramma delle classi. Come punto di partenza verrà utilizzato il diagramma ECI descritto in precedenza, associando ad ogni elemento individuato un generico oggetto composto da attributi e metodi. In questo primo stadio nel diagramma delle classi verranno inseriti solo gli attributi e i metodi essenziali già individuati. Si pone un’unica eccezione per le due generalizzazioni dell’interfaccia “Notification” che verranno riportate con i medesimi metodi per maggiore chiarezza del diagramma. Per chiarezza e leggibilità, anche questo diagramma viene riportato in una pagina dedicata. Dato che il numero di attributi e metodi da rappresentare cresce velocemente, da questo punto in poi ogni diagramma troppo esteso per essere rappresentato nel testo verrà inserito in una pagina dedicata. 84
    • <<control>> <<control>> PositionAreaChecker Position Control <<entity>> Area -check: Boolean -latitude: Float -changed: String -longitude: Float -areaID: Integer -areaDescription: String +IsPositionWithinArea(longitude, latitude): Boolean +ReadCoordinates(): Float, Float -majorLatitude: Float -PeriodicalWakeup() -minorLatitude: Float -majorLongitude: Float -minorLongitude: Float +IsPositionWithin(latitude, longitude): Boolean <<control>> 1 NotificationControl +NotifyRequest(cargoID, changed) -NotifyGeneration(cargoID, changed) * <<entity>> Cargo <<entity>> -cargoID: Integer Parking -description: String -parkingNumber: Integer -cargoStatus: CargoStatus 1 Notification 85 <<entity>> * Cargo Status <<entity>> ParkingPlace -date: Timestamp <<boundary>> <<boundary>> -status: String -code: Integer SOAPNotification MobileNotification +Refresh(check): String +SendNotify(message) +SendNotify(messagge) +GetStatus(): String
    • Nonostante il diagramma delle classi fosse la versione basilare estratta dal solo dall’approfondimento del flusso principale ci si può rendere facilmente conto che risulta essere molto completo per il compito che si prepone in questo caso d’uso. Unica osservazione rimane sulle funzioni del “NotificationControl” poiché deve generare le notifiche e quindi avrà bisogno di un collegamento diretto con i dati relativi al “Cargo”. Per poi lasciare la questione dell’invio all’interfaccia “Notification”. Ci si propone quindi di realizzare in dettaglio anche la parte dedicata al “Notify Management” che era stata evidenziata già nel diagramma di sequenza per poter definire completamente questo UCR. Infine c’è un dettaglio che riguardo l’accesso ai dati del “PositionAreaChecker”, esso infatti non ha bisogno di alcun collegamento con i dati diretti del cargo, ma solo con lo storico del Cargo Status. Si provvederà a modificare le associazioni nella prossima versione del diagramma delle classi. 6.2.3 Approfondimento del Notify Management Affrontando il problema delle diverse gestioni delle notifiche in questo modo ha permesso un’unificazione del flusso principale nella descrizione tramite diagrammi appena approntata, lasciando le fondamentali differenze circoscritte in un’area minore. Rileggendo attentamente la descrizione del caso d’uso in esame si nota come l’impostazione generica anche all’interno della casistica risulti la medesima, cambiando solo i destinatari delle varie notifiche da generare. 86
    • Fondamentalmente rimane valida la struttura: RichiestaNotifica *GenerazioneNotifica InvioNotifica però bisogna definire due situazioni principali di differenziazione delle notifiche, le stesse che vengono evidenziate nella descrizione del caso d’uso nel Flusso Principale, la gestione sull’evento di Cargo entrante in zona di parcheggio e sul Cargo uscente da una zona di posteggio. Viene quindi analizzata la sequenza delle interazioni far gli elementi in ciascuno dei due casi per identificare eventuali elementi mancanti o associazioni ancora omesse per una corretta realizzazione del caso d’uso. Cargo Uscente La definizione del diagramma di sequenza per questa sottoparte del caso d’uso risulta estremamente semplice poiché la generazione delle notifiche in questo caso prevede un’unica notifica inviata al Cliente finale della merce trasportata dal Cargo in questione. Risulta quindi banale affermare che il “NotificationControl” dovrà semplicemente ottenere l’identificativo del cliente associato al cargo e reperire tutti i suoi dati necessari alla generazione della notifica. In questo momento ignoriamo deliberatamente la tipologia di invio della notifica dato come si sta andando a definire la realizzazione del caso d’uso, già il “NotificatioControl” probabilmente non sarà più fisicamente sul cargo ma farà parte dell’architettura centrale, quindi la progettazione in dettaglio anche della notifica nel sistema centrale elude il dominio attuale. Vediamo quindi il diagramma di sequenza per il cargo uscente. 87
    • <<control>> <<control>> <<entity>> <<entity>> <<boundary>> PositionAreaChecker NotificationControl Cargo Client Notification 1 [changed] : NotifyRequest() 2 : NotifyGenerator() Outgoing Cargo 3 : client := GetClient() 4 : *Get() 5 : SendNotify() 88
    • Cargo Entrante Sull’evento del cargo in ingresso in un’area di parcheggio vengono richieste tre notifiche: al corriere, alla ditta di import-export incaricata e a SDAG. Ognuna di queste notifiche avrà delle sue caratteristiche e modalità che però ignoriamo per le stesse considerazioni sul dominio fatte per il caso precedente. Infatti la quantità di attributi da reperire, in quale ordine porli su un form ed altri discorsi del genere legati alla notifica reale sono privi di importanza in questo caso. Importante sarà focalizzare l’attenzione sul fatto che il “NotificationControl” dovrà generare i messaggi e iterare la procedura di Creazione Notifica per tre volte, oppure richiamare tre metodi dedicati ognuno ad un tipo di notifica. In questo esempio di progettazione per la realizzazione di un caso d’uso opteremo per la seconda opzione per due ragioni principali: risulta più facilmente rappresentabile in un diagramma delle sequenze e in generale in dei diagrammi UML, vista la quantità di notifiche differenti previste all’interno di questo caso d’uso (solamente quattro) risulta inutile anche solo porre il problema di un metodo generico che si adatti alle diverse tipologie di notifiche. Nel qual caso un tale costrutto si riveli utile in seguito ad un’ispezione approfondita attraverso tutti gli UCR, esso comunque verrà progettato in un secondo momento e per motivazioni diverse da queste quattro notifiche. Il procedimento della Generazione Notifica risulterà essere sempre il medesimo descritto nel caso precedente, fatta eccezione per la notifica da inviare a SDAG. In entrambi gli altri casi infatti, Corriere e ditta di import-export, il “NotificationControl” dovrà reperire gli identificativi relazionati al Cargo in esame e reperire le informazioni necessarie alla composizione della notifica. Viene sollevata l’eccezione nel caso della notifica a SDAG poiché non sarà necessario reperire alcun identificatore per tale destinatario vista la sua particolare natura in 89
    • questo caso d’uso. In seguito a questa ultima eccezione si avvalora la scelta effettuata in precedenza per la distinzione dei vari processi di Creazione Notifica. Si procede quindi alla determinazione del diagramma di sequenza del Notify Management sul cargo in ingresso in un’area di parcheggio. 90
    • <<control>> <<control>> <<entity>> <<entity>> <<entity>> <<entity>> <<boundary>> PositionAreaChecker NotificationControl Cargo Carrier IeCompany SDAG Information Notification 1 [changed] : NotifyRequest() 2 : NotifyGenerator() Incoming Cargo 3 : BuildingMessageCarrier() 4 : carrier := GetCarrier() 5 : *Get() 6 : SendNotify() 7 : BuildingMessageIeCompany() 8 : ieCompany := GetIeCompany() 9 : *Get() 10 : SendNotify() 11 : BuildingMessageSDAG() 12 : *Get() 13 : SendNotify() 91
    • <<control>> NotificationControl <<entity>> <<entity>> Carrier SDAG Information +NotifyRequest(cargoID, changed) -id: Integer -NotifyGeneration(cargoID, changed) -description: String -description: String -BuildingMassegeIeCompany(cargoID): String -mail: String -BuildingMessageCarrier(cargoID): String +ReadInfo(): String -telephone: Integer -BuildingMessageSDAG(): String -address: String -BuildingMessageClient(cargoID): String <<entity>> Cargo -cargoID: Integer <<entity>> -description: String Client -client: Client -id: Integer -ieCompany: IeCompany -description: String -carrier: Carrier -mail: String -cargoStatus: CargoStatus -telephone: Integer Notification +GetClient(cargoID): Client -address: String +GetIeCompany(cargoID): IeCompany +GetCarrier(cargoID): Carrier <<entity>> rappresentazione parziale mirata alla generazione delle notifiche: IeCompany <<boundary>> <<boundary>> SOAPNotification MobileNotification -id: Integer -description: String 92 +SendNotify(message) -mail: String +SendNotify(messagge) -telephone: Integer -address: String diagramma delle classi introdotto in precedenza. Si provvede ad una del “Notify Management” è possibile ampliare considerevolmente il In seguito a quanto visto in questo approfondimento dei due possibili flussi
    • Come è possibile vedere dal diagramma precedente sono state inserite numerose entità associate al Cargo per la reperibilità delle informazioni necessarie alle creazioni notifiche presenti nel “NotificatioControl”. L’entità associata ai dati di SDAG è stata associata direttamente al controllo poiché, come è stato fatto notare in precedenza, probabilmente questa parte del caso d’uso non si svilupperà sul cargo ma all’interno della architettura principale ove vi sarà una diretta reperibilità dei dati. Inoltre non era logicamente associabile l’entità Cargo con l’entità SDAG, essendo quest’ultima un punto fermo nello scenario di cui questo caso d’uso fa parte. 6.2.4 Diagramma delle Classi WP26.P2.UCR 3.2 Prova La realizzazione del diagramma complessivo delle classi è del tutto scontata a questo punto della realizzazione, si tratta semplicemente di comporre in un unico diagramma tutto ciò che è stato progettato fino ad ora. Importante sottolineare alcune scelte sia sulla struttura che sulla rappresentazione di alcuni piccoli dettagli all’interno del diagramma. Come era stato già specificato nella piccola guida del capitolo precedente, con le nozioni essenziali al corretto delineamento dei diagrammi di questa fase, ogni attributo e metodo evidenziato nel diagramma delle classi ha un simbolo di segno che lo precede ad indicare se è un elemento con visibilità pubblica o privata. In merito al criterio di assegnazione di tale visibilità si è proceduto con lo stesso metodo applicato solitamente nei costrutti object-oriented, ovvero mantenere tutti gli attributi interni privati rendendo quindi impossibile la loro modifica dall’esterno dell’elemento. Come è normale uso infatti sono stati forniti metodi che forniscono e lavorano sugli attributi interni operando così i servizi di utilità dell’elemento 93
    • mantenendo al contempo un ottimo grado di controllo. Sono stati inoltre omessi la maggior parte dei metodi più banali e standard, identificabili genericamente come “Set” e “Get” dei vari attributi interni dei vari elementi. La parte rilevante di essi è stata indicata solo all’interno di quegli elementi di importanza chiave nella realizzazione del caso d’uso in esame. Come affermato in precedenza, viene apportata la modifica della associazione fra il “PositionAreaChecker” e il “Cargo” poiché il primo non ha alcun interesse diretto nei dati del cargo ma solamente nello storico degli stati, che è rappresentato dall’entità “Cargo Status”. A seguito di tutto ciò che è stato definito in questa realizzazione si traccia il diagramma delle classi dello UCR 3.2 Prova, visibile nella pagina seguente. 94
    • <<control>> <<entity>> <<entity>> <<control>> PositionAreaChecker Area ParkingPlace Position Control -check: Boolean -areaID: Integer -code: Integer -latitude: Float -changed: String -areaDescription: String -longitude: Float -majorLatitude: Float +IsPositionWithinArea(longitude, latitude): Boolean -minorLatitude: Float +ReadCoordinates(): Float, Float -PeriodicalWakeup() 1 -majorLongitude: Float -minorLongitude: Float 1 * * +IsPositionWithin(latitude, longitude): Boolean <<entity>> <<entity>> Parking Cargo Status -parkingNumber: Integer -date: Timestamp -status: String +Refresh(check): String <<entity>> +GetStatus(): String Cargo <<control>> -cargoID: Integer NotificationControl -description: String -client: Client +NotifyRequest(cargoID, changed) -ieCompany: IeCompany -NotifyGeneration(cargoID, changed) -carrier: Carrier -BuildingMassegeIeCompany(cargoID): String <<entity>> -cargoStatus: CargoStatus -BuildingMessageCarrier(cargoID): String Carrier -BuildingMessageSDAG(): String +GetClient(cargoID): Client -BuildingMessageClient(cargoID): String -id: Integer +GetIeCompany(cargoID): IeCompany -description: String +GetCarrier(cargoID): Carrier -mail: String -telephone: Integer -address: String <<entity>> SDAG Information -description: String <<entity>> <<entity>> Client IeCompany +ReadInfo(): String 95 Notification -id: Integer -id: Integer -description: String -description: String -mail: String -mail: String -telephone: Integer -telephone: Integer <<boundary>> <<boundary>> -address: String -address: String SOAPNotification MobileNotification +SendNotify(message) +SendNotify(messagge)
    • Conclusioni e Discussione Il lavoro svolto in questa tesi ha consentito di raggiungere gli obiettivi prefissati. Infatti è stata individuata correttamente una guida metodologica sufficiente al conseguimento dello scopo preposto. La tipologia di progetto in esame era troppo ampia per averne colto tutti gli aspetti nella breve analisi effettuata nel capitolo dedicato. Perciò si è preferito mettere in evidenza le problematiche che più andavano ad influire sulla progettazione, ossia il punto a cui è giunto il progresso di Euridice. Una volta identificato quindi il metodo più idoneo allo svolgimento della fase di progettazione, nello specifico del progetto alla realizzazione dei casi d’uso, si è proceduto ad applicarlo selezionando appositamente un caso d’uso adatto ad una semplice esemplificazione del metodo. Nonostante questo proposito però, essendo stata svolta la realizzazione di un unico caso d’uso, resta aperto il problema di esemplificare due dei diagrammi selezionati nel metodo. Cioè il diagramma di stato che per eccessiva semplicità del caso d’uso scelto non sarebbe risultato più significativo degli stessi diagrammi presenti negli esempi della breve guida metodologica stilata. Inoltre non si è reso necessario tracciare un diagramma di collaborazione poiché anch’esso non risultava significativo ai fini della specifica realizzazione del caso d’uso scelto. Come sarebbe dovuto risultare chiaro dalla guida infatti entrambi i diagrammi di interazione presentati, il diagramma di sequenza e il diagramma di collaborazione, mettono in evidenza due aspetti leggermente differenti dello stesso punto di vista sul caso d’uso. 96
    • Inoltre nel caso specifico dei pilot di Euridice i diagrammi di stato e di collaborazione non saranno previsti in ogni realizzazione ma solo per certi Use Case di specifico interesse. Concludendo, questo lavoro di tesi sarà utilizzato come esempio di realizzazione di un caso d’uso per l’esemplificazione della linea da seguire per tale procedimento per tutti i pilot di Euridice. 97