View
883
Download
0
Category
Preview:
DESCRIPTION
Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione
Citation preview
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
1
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
2
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
3
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.
4
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.
5
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.
6
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.
7
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à.
8
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;
9
• 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
10
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
11
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à.
12
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.
13
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;
14
� 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
15
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
16
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;
17
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.
18
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à
19
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;
20
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;
21
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;
22
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)
23
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.
24
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;
25
• 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
26
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
27
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
28
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
29
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:
30
• 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)
31
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
32
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?);
33
• 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?);
34
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
35
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.
36
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.
37
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
38
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.
39
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.
40
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.
41
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
42
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à.
43
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
44
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.
45
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à
46
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.
47
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.
48
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.
49
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.
50
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.
51
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;
52
• 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.
53
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 è
54
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.
55
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
56
caso d’uso di Euridice fornendo un ulteriore approfondimento al metodi di
sviluppo dei sopra esposti diagrammi.
57
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
58
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.
59
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.
60
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.
61
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.
62
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 { } “
63
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.
64
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”.
65
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.
66
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.
67
Un esempio di immediata comprensione può essere un ordine a magazzino:
GESTIONE ORDINI
1:preparazione ordine ()
6:[presente]:aggiunta in ordine()
MAGAZZINO
2: presente:=controlla ()
3: [presente]:aggiorna il magazzino()
4: necessario:=necessità riordino ()
5: [necessario]:nuovo riordine ()
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
1 : preparazione ordine ()
1.3:[presente]:aggiunta in ordine()
MAGAZZINO
1.1 : presente:= controlla ()
1.2 : [presente]: aggiorna magazzino()
1.2.1: necessario:= necessità riordino()
1.2.2 :[necessario]: nuovo riordine()
68
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.
69
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.
70
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
71
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.
72
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
73
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.
74
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.
75
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.
WeatherCriticalService
WP26.P2.UC3.1 Book a place in the parking area
SDAG
Intelligent Cargo Carrier
WP26.P2.UC3.2 update cargo status
76
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.
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.
WP26.P2.UCR3.2 provaWP26.P2.UC3.2 update cargo status
77
Dopo attenta analisi e con alcune evoluzioni successive è stato
individuato il seguente diagramma ECI per l’UCR3.2:
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
PositionAreaChecker
NotificationControl
PositionControl
Cargo Status
Area
MobileNotification SOAPNotification
Cargo
Parking
Notification
78
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.
79
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.
80
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.
81
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.
82
Notify Menagement
PositionControl
<<control>>
Cargo Status
<<entity>>
PositionAreaChecker
<<control>>
NotificationControl
<<control>>
Area
<<entity>>
Notification
<<boundary>>
1 : PeriodicalWakeup()
2 : ReadCoordinates()
3 : IsPositionWithinArea()
4 : check := IsPositionWithin()
5 [check] : changed := Refresh()
6 [changed] : NotifyRequest()
7 : NotifyGenerator()
8 : SendNotify()
83
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.
84
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.
85
Cargo Status
<<entity>>
-date: Timestamp
-status: String
+Refresh(check): String
+GetStatus(): String
NotificationControl
<<control>>
+NotifyRequest(cargoID, changed)
-NotifyGeneration(cargoID, changed)
Area
<<entity>>
-areaID: Integer
-areaDescription: String
-majorLatitude: Float
-minorLatitude: Float
-majorLongitude: Float
-minorLongitude: Float
+IsPositionWithin(latitude, longitude): Boolean
Position Control
<<control>>
-latitude: Float
-longitude: Float
+ReadCoordinates(): Float, Float
PositionAreaChecker
<<control>>
-check: Boolean
-changed: String
+IsPositionWithinArea(longitude, latitude): Boolean
-PeriodicalWakeup()
Notification
SOAPNotification
<<boundary>>
+SendNotify(message)
MobileNotification
<<boundary>>
+SendNotify(messagge)
Cargo
<<entity>>
-cargoID: Integer
-description: String
-cargoStatus: CargoStatus
Parking
<<entity>>
-parkingNumber: Integer
1
*
ParkingPlace
<<entity>>
-code: Integer
1
*
86
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.
87
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.
88
Outgoing Cargo
PositionAreaChecker
<<control>>
NotificationControl
<<control>>
Cargo
<<entity>>
Client
<<entity>>
Notification
<<boundary>>
1 [changed] : NotifyRequest()
2 : NotifyGenerator()
3 : client := GetClient()
4 : *Get()
5 : SendNotify()
89
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
90
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.
91
Incoming Cargo
NotificationControl
<<control>>
PositionAreaChecker
<<control>>
Cargo
<<entity>>
Carrier
<<entity>>
IeCompany
<<entity>>
SDAG Inform
ation
<<entity>>
Notification
<<boundary>>
1 [changed] : NotifyRequest()
2 : NotifyGenerator()
3 : BuildingMessageCarrier()
4 : carrier := GetCarrier()
5 : *Get()
6 : SendNotify()
7 : BuildingMessageIeCompany()
8 : ieCompany := GetIeCompany()
9 : *Get()
10 : SendNotify()
11 : BuildingMessageSDAG()
12 : *Get()
13 : SendNotify()
92
NotificationControl
<<control>>
+NotifyRequest(cargoID, changed)
-NotifyGeneration(cargoID, changed)
-BuildingMassegeIeCompany(cargoID): String
-BuildingMessageCarrier(cargoID): String
-BuildingMessageSDAG(): String
-BuildingMessageClient(cargoID): String
Notification
SOAPNotification
<<boundary>>
+SendNotify(message)
MobileNotification
<<boundary>>
+SendNotify(messagge)
Cargo
<<entity>>
-cargoID: Integer
-description: String
-client: Client
-ieCompany: IeCompany
-carrier: Carrier
-cargoStatus: CargoStatus
+GetClient(cargoID): Client
+GetIeCompany(cargoID): IeCompany
+GetCarrier(cargoID): Carrier
Carrier
<<entity>>
-id: Integer
-description: String
-mail: String
-telephone: Integer
-address: String
Client
<<entity>>
-id: Integer
-description: String
-mail: String
-telephone: Integer
-address: String
IeCompany
<<entity>>
-id: Integer
-description: String
-mail: String
-telephone: Integer
-address: String
SDAG Inform
ation
<<entity>>
-description: String
+ReadInfo(): String
In seguito a quanto visto in questo approfondimento dei due possibili flussi
del “Notify Management” è possibile ampliare considerevolmente il
diagramma delle classi introdotto in precedenza. Si provvede ad una
rappresentazione parziale mirata alla generazione delle notifiche:
93
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
94
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.
95
Cargo Status
<<entity>>
-date: Timestamp
-status: String
+Refresh(check): String
+GetStatus(): String
NotificationControl
<<control>>
+NotifyRequest(cargoID, changed)
-NotifyGeneration(cargoID, changed)
-BuildingMassegeIeCompany(cargoID): String
-BuildingMessageCarrier(cargoID): String
-BuildingMessageSDAG(): String
-BuildingMessageClient(cargoID): String
Area
<<entity>>
-areaID: Integer
-areaDescription: String
-majorLatitude: Float
-minorLatitude: Float
-majorLongitude: Float
-minorLongitude: Float
+IsPositionWithin(latitude, longitude): Boolean
Position Control
<<control>>
-latitude: Float
-longitude: Float
+ReadCoordinates(): Float, Float
PositionAreaChecker
<<control>>
-check: Boolean
-changed: String
+IsPositionWithinArea(longitude, latitude): Boolean
-PeriodicalWakeup()
Notification
SOAPNotification
<<boundary>>
+SendNotify(message)
MobileNotification
<<boundary>>
+SendNotify(m
essagge)
Cargo
<<entity>>
-cargoID: Integer
-description: String
-client: Client
-ieCompany: IeCompany
-carrier: Carrier
-cargoStatus: CargoStatus
+GetClient(cargoID): Client
+GetIeCompany(cargoID): IeCompany
+GetCarrier(cargoID): Carrier
Parking
<<entity>>
-parkingNumber: Integer
1*
Carrier
<<entity>>
-id: Integer
-description: String
-mail: String
-telephone: Integer
-address: String
Client
<<entity>>
-id: Integer
-description: String
-mail: String
-telephone: Integer
-address: String
IeCompany
<<entity>>
-id: Integer
-description: String
-mail: String
-telephone: Integer
-address: String
SDAG Inform
ation
<<entity>>
-description: String
+ReadInfo(): String
ParkingPlace
<<entity>>
-code: Integer
*1
96
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.
97
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.
Recommended