Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione

1. 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

2. Sommario
Introduzione ....................................................................................................... 2
1. Storia dell’ingegneria del software ................................................................ 4
1.1 Ingegneria del Software ............................................................................. 6
2. Ciclo di Vita del Software................................................................................ 8
2.1 Processi di sviluppo software ................................................................... 12
2.2 Metodologie.............................................................................................. 13
3. Rational Unified Process ............................................................................... 24
3.1 Le fasi del RUP ........................................................................................ 29
3.2 Aspetti statici del RUP ............................................................................ 32
4. Identificazione delle problematiche di progetto.......................................... 34
4.1 EURIDICE .............................................................................................. 34
4.2 Analisi dello scenario ............................................................................... 36
4.3 Approfondimento ..................................................................................... 39
4.4 Riassumendo ............................................................................................45
5. Approccio...................................................................................................... 47
5.1 Guida Metodologica alla progettazione ................................................... 51
6. Progettazione di un Caso d’uso .................................................................... 69
6.1 Considerazioni generali sulla realizzazione di un caso d’uso.................. 73
6.2 Progettazione esemplificativa del Caso d’uso WP26.P2.UC3.2 .............. 75
6.2.1 Diagramma di sequenza del Flusso principale ................................. 80
6.2.2 Diagramma delle classi del Flusso Principale ................................... 84
6.2.3 Approfondimento del Notify Management ..................................... 86
6.2.4 Diagramma delle Classi WP26.P2.UCR 3.2 Prova ............................ 93
Conclusioni e Discussione................................................................................. 96
1

3. Introduzione
Il qui presente lavoro di tesi triennale in Ingegneria Informatica si
colloca nel contesto del progetto europeo, già in carico alla società Insiel
S.p.a., EURIDICE (EURopean Inter-Disciplinary research on Intelligent
Cargo for Efficient, safe and environment-friendly logistics) cofinanziato
dalla Commissione Europea nell’ambito del Settimo Programma Quadro
(Seventh Framework Programme -FP71) .
EURIDICE è un progetto di Ricerca che coinvolge 22 partner
provenienti da 9 paesi europei che collaborano con la finalità di
implementare il concetto di Cargo Intelligente, si tratta quindi di un progetto
di logistica che prevede sia la realizzazione della struttura essenziale che la
concreta dimostrazione della fattibilità degli obiettivi di progetto.
All’inizio di questo lavoro di tesi, nel progetto, si era giunti alla
conclusione della fase di analisi e quindi si doveva iniziare la fase
progettazione o design.
Obiettivo di questa tesi è dettagliare la metodologia di progettazione
considerando le caratteristiche di un progetto collaborativo internazionale e
fornire le linee guida per il design.
A tal proposito è necessario inquadrare le problematiche inerenti lo
sviluppo di un progetto distribuito fra un gran numero di partner dislocati in
vari paesi europei, quindi verificarne l’impatto allo specifico punto di
progresso del progetto ed individuare il metodo di lavoro ed infine produrre
una guida operativa a supporto della corrente fase di progettazione
1 http://cordis.europa.eu/fp7/home_en.html
2

4. corredata da un esempio pratico, ovvero la progettazione completa di un
reale Use Case del progetto Euridice.
Il lavoro di tesi è stato suddiviso in sei capitoli.
Il primo capitolo introduce la materia di interesse, ripercorrendo
brevemente la storia dell’ingegneria del software fino alla odierna
definizione.
Nel secondo capitolo si descrive accuratamente il concetto
fondamentale di ciclo di vita del software, esponendo come esso sia
composto e i principali tipi di modelli applicati allo sviluppo dei progetti
software.
All’interno del terzo capitolo si espone il modello di un processo
software iterativo sviluppato da Rational Software cioè il Rational Unified
Process. Esso riveste una fondamentale importanza nell’odierna visione della
produzione dei progetti software.
Il quarto capitolo presenta Euridice ed analizza in fasi successive le
problematiche sollevate da un progetto internazionale collaborativo per
l’organizzazione del lavoro.
Nel quinto capitolo si delinea l’effettivo impatto delle problematiche
sollevate nella precedente analisi e si definisce un metodo di lavoro per la
progettazione.
Infine il sesto capitolo si compone della effettiva realizzazione di un
caso d’uso ovvero della esemplificazione pratica del metodo di progettazione
scelto ad un segmento dei risultati della fase di analisi.
3

5. 1. Storia dell’ingegneria del software
L’esigenza di creare una disciplina che si occupasse dei processi
produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di
sistemi software si comincia a sentire attorno alla fine degli anni sessanta.
Nasce difatti la necessità di sviluppare prodotti sempre più complessi ed
evoluti che rispondano alle richieste delle grandi utenze.
Più precisamente dal 1950 al 1965 lo sviluppo del software personale
era alquanto limitato: tutti i programmi venivano sviluppati in batch2, gli
informatici erano pochi ed apprendevano direttamente sul campo. Ciò che
veniva sviluppato era pensato per un unico cliente o talvolta addirittura per
una unica macchina. Inoltre era comune che ad ogni progetto lavorasse e
continuasse a lavorare una sola persona, senza però richiedere che venisse
scritta alcuna forma di documentazione.
Fino alla nascita dell'ingegneria del software, la realizzazione di
prodotti software consisteva soprattutto nel mettere insieme una sequenza di
istruzioni di codice per realizzare compiti ben specifici.
Dal 1965 al 1975 si assiste allo sviluppo di software pensato per più
utenti e per dei sistemi particolari per i quali la correttezza del risultato
dipende anche dal tempo di risposta. Inserendo quindi un limite temporale
2 Il termine batch risale all'epoca della programmazione per schede perforate. In quel contesto, i
programmatori solitamente non avevano accesso diretto al computer, bensì preparavano i propri
programmi "off-line" e li passavano a un amministratore di sistema, il quale aveva il compito di
mandarli in esecuzione quando possibile (accodandoli rispetto ad altri programmi in esecuzione e
spesso accorpando più programmi in un'unica unità di esecuzione), restituendo poi in seguito i
risultati dell'elaborazione agli interessati.
4

6. ad un sistema informatico nasce una famiglia di programmi che devono
rispondere ad eventi esterni entro tempi prestabiliti, nasce il concetto di real-
time.
Nel 1968 la conferenza NATO tenuta a Garmisch, in Germania, rende
chiaro il problema rappresentato dall'incapacità di produrre nei tempi
previsti software affidabile e rispondente ai requisiti. A partire dal 1972 e
fino al 1988 vengono introdotte nuove tecnologie, nascono i sistemi
distribuiti e si afferma la figura specializzata del sistemista informatico. Il
costo dell'hardware si abbassa considerevolmente e di conseguenza la
tecnologia informatica comincia a diffondersi rapidamente. Organizzazioni
come il Pentagono spingono fortemente lo studio di modelli che permettano
di minimizzare la quantità di errori all'interno dei software. Il livello
qualitativo del software si eleva, si tende a controllare lo sviluppo del
software cercando di sviluppare prodotti di qualità a causa della concorrenza
affermatasi tra le software house.
Con l'introduzione delle tecnologie informatiche anche nel settore
industriale e commerciale, bacini di utenza non più tecniche sentono
l'esigenza di informatizzare le proprie strutture. Il cambiamento del tipo di
utenza genera l’esigenza di curare l'interfaccia grafica presentata all'utente
per renderne più intuitivo l’utilizzo.
Il software come prodotto industriale diventa anche oggetto di un
attento esame per estendere le capacità di realizzazione dello stesso. Nasce in
pratica un concetto simile alle ottimizzazioni da catena di montaggio per le
industrie del secolo scorso che avevano similmente stravolto il modo di
produrre apparecchiature meccaniche.
5

7. 1.1 Ingegneria del Software
Per software engineering si intende quella disciplina che si occupa dei processi
produttivi e delle metodologie di sviluppo finalizzate alla realizzazione di sistemi
software.
L'ingegneria del software si propone degli obiettivi legati all'evoluzione
dello sviluppo del software, inteso come attività industriale, sia da un punto
di vista tecnologico (per esempio attraverso la definizione di nuovi linguaggi
di programmazione) che metodologico (per esempio il perfezionamento dei
modelli di ciclo di vita del software). Essa identifica quindi una
formalizzazione del processo di realizzazione e di manutenzione di un
sistema informativo. Si parla quindi di ciclo di vita3 del software, disciplina
che comprende e regolamenta tutte le fasi di un prodotto dalla sua ideazione
e realizzazione fino alla conduzione e infine dismissione.
Il concetto di qualità viene applicato anche a questa disciplina vista la
necessità di rilasciare un prodotto perfettamente funzionante, documentato e
facilmente manutenibile.
Per qualità del software si intende la misura in cui un prodotto software
soddisfa un certo numero di aspettative rispetto sia al suo funzionamento sia
alla sua struttura interna. Per rendere valutabile ciò vengono introdotte due
famiglie di parametri: esterni ed interni. I primi si riferiscono alla qualità del
software così come è percepita dai suoi utenti, e includono correttezza,
affidabilità, efficienza, usabilità. I secondi si riferiscono alla qualità del
3 L'espressione ciclo di vita del software si riferisce alla scomposizione di attività di
realizzazione di prodotti software in sottoattività fra loro coordinate, il cui risultato finale è il
prodotto stesso e tutta la documentazione a esso associata.
6

8. software così come è percepita dagli sviluppatori, ed includono verificabilità,
manutenibilità, riparabilità, evolvibilità, riusabilità, portabilità, leggibilità,
modularità.
L'ingegneria del software definisce quindi dei modelli e l’insieme di
processi, ovvero sequenze di fasi per la realizzazione di un sistema software,
tutte documentate e ispezionabili, che permettano di realizzare prodotti
sempre più evoluti e di qualità.
7

9. 2. Ciclo di Vita del Software
Il concetto di ciclo di vita e di processo software coincide con la nascita
dell'ingegneria del software, in quanto rappresenta un passaggio storico
dallo sviluppo del software inteso come attività artigianale, ovvero affidata
alla libera creatività dei singoli individui, a un approccio più industriale, in
cui la creazione di programmi e sistemi software viene considerata come un
processo complesso che richiede pianificazione, controllo, e documentazione
appropriati.
L'espressione ciclo di vita del software si riferisce al modo in cui una
metodologia di sviluppo o un modello di processo scompongono l'attività di
realizzazione di prodotti software in sottoattività fra loro coordinate, il cui
risultato finale è il prodotto stesso e tutta la documentazione a esso associata.
Fondamentalmente le attività costituenti il processo di sviluppo sono:
la fase di Analisi, ovvero l’indagine preliminare sulle caratteristiche che il
sistema deve esibire e sul contesto in cui il prodotto software deve
inserirsi. Questa fase può essere scomposta in sottoattività quali:
• la definizione del problema - comprendere il “problema” che il
sistema è chiamato a risolvere;
• lo studio di fattibilità - stabilire se gli obiettivi dello sviluppo sono
ragionevoli e raggiungibili sia in dal punto di vista tecnico che
economico;
• l'analisi del dominio - comprendere il contesto o dominio
applicativo in cui il sistema dovrà agire;
8

10. • la determinazione dei requisiti - specifica dettagliatamente le
funzioni da svolgere, i servizi da erogare e le caratteristiche non
funzionali richieste per il sistema;
In senso più ampio si può dire che l’analisi ha lo scopo di definire, il
più precisamente possibile, il problema. Questa fase è svolta
essenzialmente grazie alla raccolta delle informazioni attraverso colloqui
con il cliente.
L’attività di analisi si conclude con la produzione di un documento
che descrive in modo preciso, ma comprensibile al cliente, ciò che farà il
sistema, tale documento viene definito “Documento dei requisiti”.
nella fase di progettazione, in funzione dei requisiti evidenziati
dall'analisi, si definisce la struttura del sistema da realizzare. Anche
questa fase può essere suddivisa in sotto attività:
• architettura - definisce le specifiche del prodotto. I requisiti
vengono riformulati in modo da essere comprensibili agli
sviluppatori ed aderenti alla tecnologia che verrà utilizzata. Nella
fase di analisi il software può esser stato suddiviso in moduli di
alto livello, bisogna definire come essi si relazionano e quali siano
i loro vincoli non funzionali. Questa sottofase porta alla stesura
del documento delle specifiche, esse possono essere di due tipi:
funzionali e non funzionali. Le prime rappresentano le
funzionalità del software, le seconde invece rappresentano i
vincoli ai quali deve sottostare il software (tempi, utilizzo di
hardware particolari, logistica);
• progetto dettagliato - definisce in modo preciso i moduli che
comporranno il software e la loro struttura interna. Viene definita
9

11. la loro interfaccia ed i dati ai quali possono accedere. Questa
sottofase riveste un ruolo importante dunque perché si attuano
scelte su come si realizzerà effettivamente il prodotto software;
è nella fase di implementazione, o codifica, che si procede con la
realizzazione concreta del sistema; questa tipicamente consiste nella
realizzazione dei vari moduli costituenti. Nella maggior parte dei casi è
possibile distinguere almeno due sottoattività per i singoli moduli che
costituiscono il sistema: Codifica e Verifica. Complessivamente si tratta di
una fase piuttosto tecnica, tutte le decisioni principali sono state prese
nelle fasi precedenti;
la fase di collaudo, è volta a misurare in che modo il sistema realizzato
soddisfa i requisiti stabiliti nella fase di analisi, ovvero a valutarne la
correttezza rispetto alle specifiche. Quando ogni modulo è
individualmente corretto si passa all’integrazione dei moduli. Viene
quindi testato il sistema complessivo: viene confrontato il documento
delle specifiche funzionali e non funzionali (“Are we building the product
right?”).
Quando il sistema si comporta in accordo con il documento delle
specifiche, si passa all’installazione dello stesso nel suo ambiente e si
procede al collaudo. Il collaudo comprova da parte dell’utente che il
prodotto soddisfa i suoi bisogni ed obiettivi. A questo scopo si confronta
il sistema con il documento dei requisiti (“Are we building the right
product?”);
la fase di manutenzione, che comprende tutte le attività di modifica del
software successive al suo rilascio presso il cliente o la sua immissione sul
10

12. mercato. Queste attività possono essere volte a correggere errori del
software, adattarlo a nuovi ambienti operativi, estenderne le funzionalità
o a revisionarne operazioni regolamentate da nuove leggi. La
manutenzione incide sui costi poiché modifica al software comporta
ovviamente la necessità di nuovi test, sia relativi alle nuove funzionalità
eventualmente introdotte, sia mirati a verificare che le modifiche
apportate non abbiano compromesso funzionalità preesistenti. Una linea
standard di verifica prevede dei test sui moduli similarmente alla
precedente fase di test, ovvero si testa che i moduli funzionino
singolarmente e che una volta assemblati continuino a funzionare;
In tutti i cicli di vita del software svolge inoltre un ruolo essenziale la
documentazione dei prodotti delle varie sottoattività.
11

13. 2.1 Processi di sviluppo software
La maggior parte delle metodologie di sviluppo del software consiste,
almeno in linea di principio, in un linguaggio di modellazione e un processo.
Il linguaggio di modellazione è la notazione usata dalle metodologie per
esprimere le caratteristiche di progetto, mentre il processo è una serie di
passi, una sorta di elenco che aiuti ad ottenere risultati di alta qualità in un
tempo prefissato. Il processo software è composto da alcune attività che
rappresentano un insieme di compiti da svolgere per sviluppare un software:
Attività portanti: una serie di compiti da svolgere
necessariamente;
Attività ausiliarie: possono aumentare la qualità di un software
da produrre, di solito tali attività sono considerate dalle aziende
che cercano una certa qualità. Tali attività non riguardano il
progetto in sé ma piuttosto l'azienda;
Coloro che, individualmente o in gruppo, lavorano allo sviluppo o alla
modifica di un software, adottano necessariamente un certo approccio nel
modo di relazionarsi con i propri clienti, nell'organizzare il proprio lavoro,
nella scelta delle tecniche da utilizzare. In modo consapevole o meno, ogni
sviluppatore o gruppo di sviluppatori software ha un proprio processo di
sviluppo, esso è definito dal proprio modo di lavorare, basato sulla propria
esperienza, sulla propria cultura, e sul contesto culturale ed organizzativo in
cui si trova ad operare.
La storia dei successi e degli insuccessi dei progetti di sviluppo
software ha insegnato che ogni processo di sviluppo ha i propri pregi ed i
propri limiti. E che un processo di sviluppo inadeguato alle concrete esigenze
dello specifico progetto può condurre al fallimento del progetto stesso, o
comunque all'insoddisfazione dei clienti e degli stessi sviluppatori.
12

14. 2.2 Metodologie
Nel campo delle scienze esatte un modello è una formalizzazione
precisa della una realtà mediante equazioni matematiche. Nello sviluppo del
software, il modello è chiaramente meno preciso, ma comunque
l’applicazione di un modello, magari impreciso ma aderente al caso, è pur
sempre preferibile alla non applicazione di un modello.
Questa affermazione è particolarmente evidente per lo sviluppo di
progetti software, a tal riguardo nel tempo si sono affermate numerose e
diverse metodologie per rispondere al progresso tecnologico e al
conseguente modificarsi delle potenzialità del software.
Vediamo ora alcune diverse tipologie di modelli:
Modello a cascata
Questo modello è caratterizzato da un rigida suddivisione in passi
sequenziali ognuno dei quali definisce una attività che opera su un insieme
di ben definiti input e produce determinati output che serviranno come input
della fase successiva. Importante sottolineare che viene regolamentata la
documentazione delle varie fasi del processo.
Il modello a cascata tradizionale prevede le seguenti fasi:
studio di fattibilità: ha lo scopo di determinare se intraprendere lo
sviluppo del sistema;
analisi dei requisiti: ha lo scopo di determinare che cosa farà il sistema;
progettazione: ha lo scopo di determinare come il sistema farà quanto
stabilito nella prima fase, e in particolare la sua suddivisione in
moduli e le relazioni fra di essi;
13

15. sviluppo o codifica: creazione dei moduli con un linguaggio di
programmazione;
collaudo: esecuzione di prove per verificare la correttezza
dell'implementazione dei singoli moduli;
test di integrazione: esecuzione di prove per verificare la correttezza
del funzionamento complessivo del sistema;
manutenzione: segue la consegna o delivery del prodotto al cliente, e
comprende tutte le attività volte a migliorare, estendere e correggere il
sistema nel tempo;
Nel contesto di una specifica organizzazione, il modello a cascata può
essere ridefinito in molti modi, inoltre un'organizzazione può formalizzare
ulteriormente il processo definendo standard e imponendo vincoli per
quanto riguarda la natura, il formato, la struttura e i contenuti dei documenti
prodotti nelle varie fasi, tipicamente allo scopo di consentire un controllo più
rigoroso sullo stato di avanzamento del progetto e sulla qualità del lavoro
svolto.
Il modello ha giocato un ruolo importante nello sviluppo del software
per superare i limiti del processo del “code and fix” e infine ha fissato due
concetti:
• Il processo di sviluppo del software deve essere soggetto a disciplina e
pianificazione;
• L’implementazione del prodotto deve essere rimandata fino a quando
non
sono perfettamente chiari gli obiettivi.
Il maggior pregio di questo metodo di lavoro è certamente la
semplificazione del controllo dell’andamento del progetto tramite la
suddivisione del ciclo di vita in fasi successive ben definite. Le diverse
14

16. metodologie che adottano questo modello si distinguono essenzialmente per
la suddivisione e specificazione delle fasi in sottofasi più elementari, nella
definizione di standard di documentazione e nella individuazione di
momenti di verifica, detti milestone, al termine o durante ciascuna attività.
Per ottimizzare il ciclo di vita, la scomposizione delle fasi in sottofasi
persegue l’obiettivo di assegnare a ciascuna fase la soluzione di
problematiche specifiche e di rendere, per quanto possibile, le fasi
indipendenti allo scopo di poterne parallelizzare le attività.
Benché l’adozione di questi principi appaia estremamente produttiva,
la loro applicazione pratica ha come effetto collaterale, soprattutto per i
progetti di grandi dimensioni, una pericolosa dilazione temporale. Ad
esempio, normalmente l’individuazione delle strutture dati e delle
funzionalità del sistema sono affrontate con metodologie diverse e,
soprattutto per i progetti di grandi dimensioni, contemporaneamente e
separatamente da gruppi di lavoro differenti. Nel primo caso i risultati sono
formalizzati con uno Schema Entity-Relationship e nel secondo con un
metodo di scomposizione funzionale. Solo quando queste due attività
terminano viene avviata una ulteriore attività di armonizzazione dei
rispettivi risultati.
Un ulteriore problema di questa impostazione deriva dalla necessità di
terminare completamente tutta la fase di analisi dei requisiti e progetto per
cominciare l’implementazione e quindi verificarne sul campo le conclusioni.
Il modello, quindi, è una semplificazione della realtà che non trova
piena applicazione in quanto vengono applicati i seguenti tre principi:
• Linearità: spesso si hanno cicli di feedback per la correzione degli
errori. Tale feedback deve essere lineare e quindi non si possono
15

17. effettuare salti a ritroso ma vanno ripercorse tutte le fasi in maniera
lineare;
• Rigidità: ogni fase viene congelata quando si passa alla fase successiva
per cui non è possibile un’interazione tra clienti e sviluppatori durante
il ciclo di vita dopo la parte iniziale;
• Monoliticità: tutto il modello è orientato alla singola data di rilascio
che spesso si pone a mesi o anni dopo l’inizio della prima fase per cui
se vengono commessi eventuali errori o cambiano i requisiti, questi
verranno implementati dopo parecchio tempo e comunque alla fase di
consegna seguirà subito un altro adattamento perché il software sarà
già obsoleto;
Concludendo quindi, in base alle nozioni appena riportate si possono
identificare i maggiori problemi del modello:
• È difficile stimare le risorse e i costi in maniera accurata finché non sia
stata svolta almeno la prima fase di analisi;
• La specifica dei requisiti produce un documento scritto che vincola il
prodotto da sviluppare e ciò non sempre soddisfa le esigenze del
cliente perché si tratta pur sempre di specifiche basate su un
documento che non sempre aiuta nel definire le esigenze, che invece,
appaiono subito chiare dopo il primo rilascio del software. Inoltre tale
documento deve essere completo e chiaro prima di procedere allo
sviluppo, ma non sempre ciò è possibile;
• L’utente non è in grado di comprendere i formalismi utilizzati per
descrivere i requisiti dell’applicazione, si corre quindi il rischio di
passare alla fase di progetto con una documentazione non del tutto
aderente agli obiettivi del cliente;
16

18. Si comprende come gli alti costi del software siano dovuti, nel modello
a cascata, a causa proprio delle specifiche poco complete e ai molti interventi
successivi per introdurre funzionalità non previste in partenza. La curva di
costo degli errori in questo modello è esponenziale proprio perché data la
monoliticità più tardi ci si accorge di un errore e più profonda dovrà essere la
correzione da apportare.
Modello esplorativo
Se non si possono determinare le specifiche, non può essere definita la
correttezza del sistema, ossia la corrispondenza con le specifiche.
In questi casi viene utilizzato il concetto di adeguatezza, ossia
corrispondenza con i bisogni e gli obiettivi del cliente. Il modello esplorativo
consiste in una successione di prototipi che viene fatta convergere verso una
soluzione adeguata, soddisfacente per il cliente.
Non si tratta di una vera metodologia quanto piuttosto di un approccio
sperimentale e iterativo allo sviluppo: ad ogni iterazione viene costruito un
prototipo e presentato alla valutazione critica del cliente, che lo può accettare
come adeguato alle sue esigenze, oppure può indicare nuovi criteri e requisiti
che il sistema deve possedere.
Nei passi finali il prototipo viene affinato ad ogni ciclo finché viene
accettato dal cliente. Questo modello presenta due caratteristiche salienti:
• Non vi è distinzione tra prototipo finale e prodotto. Questo
normalmente non risulta vantaggioso per il fornitore;
• Vi è un forte coinvolgimento del cliente nella fase di sviluppo
rispetto al modello a cascata con conseguenti costi anche per il
cliente.
17

19. Modello incrementale
Questo modello è caratterizzato dalla scomposizione del processo in
una serie di passi sequenziali da ripetere ad ogni termine del ciclo
precedente. Per poter applicare questo modello è consigliabile avere una
visione molto chiara dell’intero progetto, perché occorre fare in modo che la
realizzazione della generica versione k risulti utile per la realizzazione della
versione k+1.
Per fare ciò bisogna eseguire con cura la fase di analisi (definizione del
problema, analisi di fattibilità, e così via) e poi procedere con l’iterazione del
seguente ciclo di attività:
• analisi dei requisiti
• progetto
• codifica
• test o collaudo
Importante osservare che ogni iterazione ha un piano, degli obiettivi
verificabili e criteri di valutazione propri, ciò permette un migliore controllo
del lavoro.
Ogni qual volta che si termina una iterazione del ciclo si ha realizzato
uno o più moduli funzionanti che vengono integrati e testati con quelli
precedentemente sviluppati creando una versione funzionante del progetto
che implementa un sottoinsieme finito delle funzionalità del progetto
software totale. Si procede in maniera analoga fino all’ennesima iterazione e
quindi alla conclusione del ciclo con il rilascio della versione finale.
Questo tipo di approccio offre delle differenze sostanziali rispetto il
modello a cascata visto in precedenza; organizzando le iterazioni cercando di
dare una priorità di messa in opera non solo dipendente dall’utilità
18

20. incrementale dei vari moduli ma soppesando anche le criticità degli stessi è
possibile affrontare i rischi del progetto fin dall’inizio, in modo sistematico.
Inoltre operare con un sistema stratificato di release permette una
maggiore flessibilità per gestire eventuali cambiamenti esterni (tecnologie,
leggi) o interni (errori nel documento dei requisiti) e favorisce la
partecipazione del cliente alla vita del progetto; tutto ciò accresce ovviamente
il costo per il cliente ma offre la possibilità di fornire velocemente software
funzionante e fornire risultati di valore poiché questo modello consente una
progettazione adeguata, in quanto porta ad un progetto solido.
Object Oriented
Nell’Object Oriented l’importanza fondamentale è rivestita
dall’approccio che si adotta per la scomposizione del problema. Questo
metodo mira infatti ad una decomposizione di un sistema mediante
l’astrazione di oggetti, che è diversa dalla decomposizione
funzionale/procedurale. Tutti i linguaggi ad oggetti includono sempre un
tipo di modulo chiamato classe, esso è uno schema dichiarativo che definisce
tipi di oggetti. La dichiarazione di classe contiene implicitamente la
definizione dei dati e dei metodi che operano su di essi.
Per poter continuare la spiegazione liberamente si introducono le
definizioni di alcuni termini propri dell’ Object Oriented specifici della
definizione di una classe:
Classe: Nome collettivo di tutti gli oggetti che hanno gli stessi metodi e
variabili di istanza (dichiarazione di tipo);
Oggetto: Entità strutturata (codice, dati) e proprietaria di uno Stato la cui
struttura è invisibile all’esterno dell’oggetto;
19

21. Stato: Lo stato di un oggetto si accede e manipola mediante messaggi che
invocano metodi, quindi non è direttamente accessibile;
Variabili di istanza: Variabili contenute nell’oggetto che rappresentano il suo
stato interno;
Messaggio: Richiesta ad un oggetto di invocazione di uno dei suoi metodi;
Metodo: Azione che accede o manipola lo stato interno dell’oggetto (di solito
le variabili di istanza), l’implementazione di tale azione è nascosta al cliente
che spedisce messaggi all’oggetto.
Approfondita ora la definizione e terminologia di una classe risulta più
semplice introdurre i concetti propri dell’Object Oriented:
Classificazione
la definizione di classi rappresenta l’identificazione di un insieme di attributi
(variabili di istanza) e di operazioni (metodi) propri di oggetti simili. Proprio
per questo motivo si può dire che una classe descrive un insieme di oggetti e
lo rappresenta tramite un’astrazione degli attributi rilevanti;
Responsabilità
ogni classe ha una responsabilità limitata ai comportamenti che essa prevede
(ai metodi che implementa);
Ereditarietà
questo concetto indica che una classe, detta sottoclasse, può essere un
raffinamento di un’altra andando così a richiedere alcune variabili e/o
metodi aggiuntivi rispetto alla classe raffinata, che viene denominata
superclasse. Il vantaggio è quindi l’utilizzo condiviso delle definizioni di
attributi e codice in classi diverse, rendendo quindi sufficiente la sola
definizione delle variabili e dei metodi aggiuntivi;
20

22. Generalizzazione
può rivelarsi opportuno evidenziare sottoinsiemi definibili come ulteriori tipi
di oggetto all’interno di classi già identificate. Questo concetto è identificabile
banalmente come la relazione di contenimento in insiemistica (un semplice
esempio può essere Veicolo Moto);
Polimorfismo
si vuole rendere standard che le operazioni con lo stesso significato
posseggano lo stesso nome anche se implementazioni diverse. Si intuisce che
esse verranno identificate univocamente dall’insieme di variabili su sui
operano (esempio “calcolo_area” su figure geometriche diverse);
Information Hiding
ogni classe nasconde tutto ciò che non è essenziale condividere,
impedendone così l’accesso o la modifica diretta e non facilmente
controllabile dall’esterno;
Gettati i punti essenziali dell’Object Oriented si può vedere ora la
struttura della sua applicazione, limitiamoci a descrivere una scomposizione
in tre fasi: Analisi, Design e Realizzazione.
I processi Analisi Object Oriented hanno tutti la seguente struttura:
• Identificazione dei requisiti;
• Inquadramento di scenari e delle interazioni fra attore e sistema (casi
d’uso);
• Estrazione delle componenti candidate;
• Costruzione di un modello di relazioni fra le componenti;
• Costruzione di un modello di comportamento delle componenti;
• Revisione dell’analisi rispetto ai casi d’uso;
21

23. Interessante approfondire come la descrizione in linguaggio naturale
dei requisiti può essere interpretata direttamente nella identificazione delle
entità e dei loro attributi e metodi. Se si provvede a separare ogni frase dei
requisiti in gruppi attinenti agli stessi soggetti risulta chiaro come ogni
sostantivo può essere identificato come oggetto ed ogni verbo può essere
identificato come metodo. Ovviamente è necessario porre attenzione ai
significati di sinonimi e differenti modi di riferirsi al medesimo oggetto.
Dopo aver completato la fase di analisi si ha dunque una totale
scomposizione del problema in componenti e dei modelli in cui vengono
definite le loro relazioni e i loro comportamenti. La fase di Design deve ora
specificare completamente queste componenti facendo riferimento anche ai
vincoli tecnologici che si impongono al progetto.
Bisogna misurare il grado di indipendenza dei vari componenti. Inutile
sottolineare che le componenti di un sistema dovrebbero riportare un basso
accoppiamento, limitando il numero di dipendenze e lasciando solamente
quelle funzionalmente rilevanti e necessarie.
Si rivela essenziale definire una gerarchia fra i componenti del sistema,
riducendo le dipendenze e vincolando la topologia delle relazioni fra i
moduli. Una struttura gerarchica forma la base del progetto
decomponendone il dominio e facilitandone lo sviluppo in parallelo.
Riassumendo i concetti dell’approccio Object Oriented al design si può dire
che:
• le componenti vengono classificate
• astrazione e incapsulamento sono meccanismi principali della
strutturazione
• il sistema finale rispecchia il dominio del problema
• è possibile la concorrenza dei processi (thread multipli)
22

24. Nell’esporre l’Object Oriented infine non riveste particolare importanza
descrivere la fase di realizzazione. Questo perché se le precedenti fasi sono
state eseguite con la dovuta meticolosità e non sono presenti errori, si tratta
solamente di riportare le classi nel o nei linguaggi scelti e di sviluppare le
interfacce necessarie, riducendosi così ad una mera procedura di
programmazione.
23

25. 3. Rational Unified Process
Il Rational Unified Process è un modello di un processo software
iterativo sviluppato da Rational Software. Esso provvede a fornire un
approccio disciplinato per l’assegnazione dei compiti e delle responsabilità
all’interno di una organizzazione di sviluppo software. Il suo obiettivo è
garantire una produzione di alta qualità che trovi un punto di incontro fra le
esigenze dei clienti e le tempistiche e il budget dell’azienda. Il R.U.P. non
definisce un singolo, specifico processo, bensì un framework adattabile che
può dar luogo a diversi processi in diversi contesti, esso è pensato
principalmente per i progetti di grandi dimensioni.
Interessante è sapere come è nato, i creatori del RUP partirono dalla
diagnosi di un campione di progetti software falliti, allo scopo di identificare
cause tipiche o generali di fallimento. Quindi confrontarono questa
informazione con la struttura dei processi software descritti in letteratura e
applicati nella pratica, cercando di identificare le soluzioni proposte
precedentemente. L'elenco dei motivi di fallimento identificati comprende
per esempio:
• Gestione ad hoc dei requisiti;
• Comunicazione ambigua e non precisa;
• Architettura fragile ,incapace di sopportare situazioni di particolare
criticità;
• Incapacità di gestire la complessità;
• Inconsistenze nei requisiti, nel progetto o nelle implementazioni;
• Collaudo insufficiente;
• Valutazione soggettiva dello stato del processo;
• Incapacità di affrontare il rischio;
• Propagazione non controllata delle modifiche;
24

26. • Insufficiente automazione;
Il RUP si può descrivere come una collezione di best practices mirate a
evitare questi e altri problemi, e come un ambiente di gestione dei processi
che facilita l'applicazione di tali pratiche. Il processo fu progettato
utilizzando strumenti tipici della progettazione del software; in particolare,
esso fu descritto in termini di un meta modello object-oriented, espresso in
UML.
Per l’appunto chiameremo da ora in poi queste diverse metodologie di
approccio descritte dal RUP come processi o “best practices”, vediamo ora le
sei più importanti:
• Sviluppo software iterativo (Develop Software Iteratively)
• Disciplina dei requisiti (Manage Requirement)
• Utilizzo di architetture a componenti (Use Component-based
Architectures)
• Verifica della qualità del software (Verify Software Quality)
• Controllo dei cambiamenti (Control changes to software)
• Modellizzazione Visuali (Visually Model Software)
Disciplina dei requisiti
Il RUP descrive come identificare e tracciare i documenti funzionali
necessari, definire i vincoli, estrarre, organizzare e comunicare
semplicemente i requisiti del business. Le nozioni di “use case” e di scenari
sono state dimostrare essere degli eccellenti modi di procedere al fine di
catturare e definire i requisiti funzionali ed assicurare che essi guidino
correttamente il design, l’implementazione e il test del software, portandolo
così ad adempire fedelmente alle necessità del cliente.
Sviluppo software iterativo
25

27. La tecnologia di oggi ci offre dei sistemi software estremamente
complessi, non è possibile definire sequenzialmente e di primo acchito
l’intero problema, effettuarne il design, codificarlo e testarlo solo al termine
del processo produttivo. Un approccio iterativo è richiesto per permettere
una comprensione progressiva del progetto e quindi un suo raffinamento al
fine di far crescere l’effettiva soluzione migliore su questo ciclo di iterazioni
multiple. Questa struttura permette tramite lo sviluppo dei maggiori oggetti
di rischio nelle prime iterazioni, di mantenere sotto controllo il rischio
durante tutto il ciclo di vita del software. Un approccio iterativo facilita
l’adeguamento degli obiettivi di progetto ai cambiamenti, andando a ridurre
significativamente il costo dei cambiamenti dovuti ad errori a qualsiasi
livello.
Controllo dei cambiamenti
L’abilità di controllo e gestione dei cambiamenti è essenziale per
rendere ogni necessità di alterazione accettabile e permettere di tracciare
come essa inevitabilmente affonderà e richiederà delle modifiche nel
progetto. Questo processo descrive come controllare, tracciare e monitorare i
cambiamenti per poter sviluppare iterativamente ed efficacemente a fronte
del presentarsi di errori.
Verifica della qualità del software
Oggigiorno cattive performance applicative e scarsa affidabilità sono
comuni fattori che segnano l’inaccettabilità del software. Quindi, si rende
necessario un controllo qualitativo basato sui requisiti sull’affidabilità, la
funzionalità, le performance delle applicazioni e dell’intero sistema. Il RUP
mette a disposizione dei parametri valutativi per i test di pianificazione,
design, implementazione, esecuzione e valutazione. È importante
26

28. comprendere che la qualità è costruita nel processo, in tutte le attività, è
affetta da ogni partecipante al progetto, ha dei criteri e parametri di
valutazione definiti e non deve essere trattata come una attività separata
svolta da un gruppo dedicato come aggiunta al progetto.
Utilizzo di architetture a componenti
Il processo è centrato sul definire la linea guida di una architettura
eseguibile robusta e svilupparne velocemente alcune parti, prima di
impegnare le risorse per uno sviluppo massivo. Esso descrive come
disegnare una architettura ricuperabile che sia flessibile ed adattabile ai
cambiamenti, e come è intuibile che favorisca il riutilizzo del software
interno.
I componenti non sono meri moduli ma sottosistemi che adempiono a
specifiche funzioni. Il RUP provvede a definire un approccio sistematico per
la definizione dell’architettura utilizzando componenti nuovi e/o preesistenti.
Modellizzazione Visuali
Questo processo mostra come modellizzare in maniera visuale il
progetto software per catturare la struttura e il comportamento delle varie
componenti. L’astrazione visuale aiuta a comunicare differenti aspetti del
progetto, come gli elementi combacino nel sistema, accertare che i blocchi
siano in linea con il codice, mantenere la consistenza tra il design e
l’implementazione e favorisce la comunicazione disambigua con il cliente. Lo
standard industriale Unified Modeling Language è il fondamento per una
modellizzazione visuale di successo.
Lo UML è uno strumento per analisti e progettisti di sistemi orientati
agli oggetti che consente di modellare, rappresentare e documentare sistemi
27

29. software. Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim
Rumbaugh e Ivar Jacobson (detti "i tre amigos") sotto l'egida dello OMG, che
tuttora gestisce lo standard di UML.
Questo linguaggio di modellazione visuale è un insieme di elementi e
di regole, di specifica formale ed offre un notevole vantaggio; infatti anche i
progettisti e gli analisti di sistemi informativi utilizzano figure e diagrammi
per visualizzare il risultato del loro lavoro: il sistema software. Durante le
fasi di analisi e progettazione vengono generati dei modelli che consentono
di identificare e separare le caratteristiche di un sistema reale. Il progettista
dovrà quindi decidere quali caratteristiche sono rilevanti per il sistema che
sta costruendo, inserirle e definire le relazioni tra gli elementi del modello.
Ciò avviene anche se il tipo di prodotto finale che risulta dalla progettazione
non è necessariamente visuale.
Il Rational Unified Process quindi è uno schema generale di un
processo, da adattare alle diverse tipologie di progetto, esso si articola in una
serie di iterazioni con lo scopo di ridurre progressivamente i rischi, a partire
da quelli principali (es. incomprensioni sui requisiti, incertezze
implementazione). In ogni iterazione si svolgono, in misura e in percentuali
diverse, le tipiche attività di sviluppo (es. gestione dei requisiti, design,
implementazione, test) adottando così un modello incrementale che si svolge
attraverso la realizzazione ed eventualmente il rilascio dell’applicazione in
modo progressivo guidata però dai casi d’uso e dalle priorità architetturali.
La definizione dell’architettura applicativa e tecnologica costituisce il
fondamento tecnico dell’applicazione e del progetto, ed il consolidamento
della stessa avviene solo quando si è certi della sua fattibilità tecnica. Fino a
quando l’architettura non è consolidata non esistono elementi sufficienti per
28

30. determinare i tempi, i costi e i rischi dell’intervento progettuale con la
precisione necessaria per la stipulazione di un contratto.
3.1 Le fasi del RUP
Nel RUP, il ciclo di vita di un processo software viene suddiviso in cicli
di sviluppo, a loro volta scomposti in fasi. Le fasi previste sono:
• Inception Phase
• Elaboration Phase
• Construction Phase
• Transition Phase
Ogni fase si conclude con una milestone per indicare il raggiungimento
di obiettivi stabiliti in fase di definizione del progetto stesso.
Inception Phase
Questa fase si può considerare come una particolare elaborazione e
precisazione del concetto generale di analisi di fattibilità. Lo scopo principale
è quello di delineare nel modo più accurato possibile il business case, ovvero
comprendere il tipo di mercato al quale il progetto afferisce e identificare gli
elementi importanti affinché esso conduca a un successo commerciale. Fra gli
strumenti utilizzati ci sono un modello dei casi d'uso, la pianificazione
iniziale del progetto, la valutazione dei rischi, una definizione grossolana dei
requisiti e la identificazione delle interazioni ad alto livello.
Alla fine di questa fase è presente la prima milestone maggiore del
progetto, detta "Lifecycle Objective Milestone". I criteri di valutazione per la
Inception Phase sono:
29

31. • Coincidenza del rapporto definizione dello scopo e costo stimato
con le aspettative del cliente;
• Comprensione e definizione dei requisiti, evidenziato della
corretta redazione degli use cases primari;
• Credibilità dei costi stimati, priorità, rischi e organizzazione del
processo di sviluppo;
• Presenza di ampia ed accurata documentazione su ogni prototipo
architetturale sviluppato;
• Resoconto delle spese attuali e pianificazione delle future;
Il progetto può essere abbandonato o ridimensionato in maniera
considerevole nel caso non passi questa milestone.
Elaboration Phase
L’obiettivo principale di questa fase è analizzare il dominio del
problema, stabilire una base architetturale, sviluppare un piano del progetto
ed eliminare i fattori di rischio più elevato del progetto. Questa fase deve
concludersi con il superamento di una milestone detta "Lifecycle
Architecture Milestone". A questo scopo devono essere soddisfatti i seguenti
criteri:
• Sviluppato un modello dei casi d'uso completo all'80%
• Fornire la descrizione dell'architettura del sistema
• Sviluppata un'architettura eseguibile che dimostra il
completamento degli use cases significativi
• Eseguita una revisione del business case e dei rischi
• Completata una pianificazione del progetto complessivo
• Redazione di un manuale utente preliminare (opzionale)
30

32. Se il progetto non passa questa milestone, potrebbe ancora essere
abbandonato, oppure dovrà essere revisionato. Al termine di questa fase si
transita infatti in una situazione di rischio più elevato, in cui le modifiche
all'impostazione del progetto saranno più difficili e dannose.
Construction Phase
Durante questa fase, tutte le componenti vengono sviluppate ed
integrate al prodotto, e infine vengono testate. Nella construction phase è, in
un certo senso, un processo manifatturiero in cui l’enfasi viene dedicata alla
distribuzione, controllo e gestione delle risorse per ottimizzare i costi e
massimizzare la qualità. Molti progetti sono sufficientemente estesi per
permettere una organizzazione parallela nella realizzazioni di alcune
componenti. Queste attività parallele possono accelerare significativamente il
rilascio ma incrementa notevolmente la complessità di gestione delle risorse
e sincronizzazione dei workflow.
Al termine della Construction Phase c’è la così denominata “Initial
Operational Capability Milestone”, essa deve determinare se quello che è
stato prodotto può considerarsi operativo senza esporre l’intero progetto a
qualche rischio. Gli output essenziali di questa fase sono:
• Il prodotto software pianificato da realizzare funzionante ed
integrato sulla piattaforma adeguata
• Il manuale utente
• Una descrizione della release corrente
Transistion Phase
Questa fase si propone di attuare la transizione del prodotto sviluppato
al cliente, è facilmente intuibile che una volta installato si renderanno
necessari degli interventi correttivi o sviluppativi che richiederanno delle
31

33. nuove release. La Transition Phase si introduce quando lo sviluppo iterativo
si porta ad un punto sufficiente per permettere il rilascio al cliente, i tipici
requisiti per fare ciò sono che il libello di qualità del sottosistema completato
sia accettabile e che la documentazione utente sia disponibile. In questo
modo la transizione del prodotto al cliente porterà un risultato positivo per
entrambe le parti, permettendo ad esempio di validare il nuovo sistema e di
iniziare a formare il personale.
Con la “Production Release Milestone” si vuole valutare se
effettivamente il cliente è soddisfatto di ciò che gli si propone e se il
dispendio registrato di risorse contro quello programmato è accettabile. A
questo punto, se gli obiettivi sono stati raggiunti è possibile iniziare un altro
ciclo di sviluppo, in alcuni casi questa milestone coincide con la fine della
inception phase del ciclo successivo.
3.2 Aspetti statici del RUP
Il meta modello applicato dal RUP per descrivere e controllare un
processo utilizza quattro concetti cosiddetti "statici", ovvero che sono definiti
nello stesso modo per tutti i processi:
• Worker
Un ruolo identifica un certo insieme di responsabilità attribuite a
un certo insieme di partecipanti al progetto
(I ruoli rispondono alla domanda chi?);
• Artifact
Gli artefatti sono il prodotto delle attività del processo; includono
documenti, modelli, componenti software e via dicendo
(Gli artefatti rispondono alla domanda cosa?);
32

34. • Workflow
Un workflow è una sequenza di attività che producono un
risultato in un tempo osservabile
(I workflow rispondono alla domanda quando?);
• Attività
Le attività sono i compiti specifici portati a termine dai
partecipanti del progetto
(Le attività rispondono alla domanda come?);
33

35. 4. Identificazione delle problematiche di progetto
4.1 EURIDICE
Il progetto Euridice, è un progetto cofinanziato dalla Commissione
Europea, che si prefigge la realizzazione del concetto di "Cargo Intelligente"
come veicolo di ottimizzazione del settore logistico. E’ un Integrated Project
con un budget di circa 14 M€ e un partenariato di 22 partner provenienti da 9
paesi europei che include aziende leader nelle tecnologie software, mobile,
wireless e RFID, rinominati centri di ricerca, operatori logistici, istituzioni e
utenti finali.
L’obiettivo del progetto è la creazione di una architettura e di
applicazioni pilota atte a verificarne la validità e l’usabilità nel mercato dei
trasporti europei.
Potendo installare dispositivi con una certa capacità elaborativa
direttamente sulla merce, questa potrebbe essere in grado di riconoscere il
contesto in cui si trova, prendere decisioni e segnalare eventuali anomalie,
questo in estrema sintesi è il “Cargo Intelligente” che può quindi diventare
un attore primario nei processi di trasporto e delivery, e fornire informazioni
in tempo reale dettagliate ed affidabili al sistema centrale.
Il continuo dialogo fra dispositivi di diverso livello automatizza
procedure oggi affidate all’utente umano e migliora le tempistiche e
l’efficienza di molte fasi dipendenti dai trasporti: velocità di consegna, carico
e scarico, programmazione della produzione in funzione degli arrivi dei
semilavorati, ottimizzazione visti doganali e controlli, tracciabilità in tempo
utile della posizione della merce e dei veicoli, programmazione del percorso
34

36. centralizzata, disposizione di informazioni sullo stato della merce in tempo
reale e così via.
Risulta immediato realizzare le potenzialità di tale progetto e al tempo
stesso risulta evidente che le difficoltà che si potranno presentare non sono
poche.
Viene generalizzato Euridice ad un progetto generico portandosi così in
una situazione favorevole ad un’analisi delle possibili problematiche di un
progetto di questo tipo.
Ci si pone quindi in uno scenario in cui un consorzio di aziende si
associano per sviluppare un progetto di ricerca europeo. Tali aziende sono
distribuite in vari paesi e non sono specializzate negli stessi settori. Partendo
da questi presupposti si procede all’identificazione delle problematiche.
35

37. 4.2 Analisi dello scenario
Prendendo in considerazione il sopra descritto scenario ci si può
facilmente rendere conto delle enormi implicazioni gestionali di un simile
progetto, anche se fosse sviluppato da una singola azienda. Per iniziare ad
analizzarne le problematiche infatti porremo proprio questa ipotesi, ovvero
che solo una azienda si occupi del suo sviluppo per poi ampliare la
panoramica.
Nonostante ci si ponga in un ambiente molto semplificato per
analizzare l’impatto del problema, ci si rende immediatamente conto che
essendo preso in esame un progetto di ricerca e sviluppo su un tema
commissionato, lo scopo non sarà definito sufficientemente a priori. Proprio
per questo sarebbe saggio stimare con la dovuta accortezza la durata
preventiva delle fasi del progetto, soprattutto quelle iniziali di analisi,
dilatandone leggermente i tempi stimati per permettere di poter far fronte in
maniera meno incisiva a ridefinizioni dovute a sviluppi e/o a funzioni
introdotte in fasi successive.
36

38. Dato che i “progetti di ricerca” finanziati dall’Unione Europea sono
indetti tramite un concorso fra gli sviluppatori, al suo interno saranno
proposte applicazioni tecnologiche innovative e soprattutto un utilizzo di
prodotti hardware e software del tutto nuovi. Proprio questi potrebbero
rivelarsi una lama a doppio taglio, aumentando sicuramente il livello del
progetto di ricerca ma andando ad incidere significativamente sull’onere da
sostenere per il suo sviluppo. Alcune tecnologie nascenti infatti sono così
nuove da non esser state ancora assimilate, o nemmeno conosciute,
all’interno dell’azienda ove il costo diretto di produzione di un progetto
dipende largamente dalla preparazione e dalla “cultura” dei dipendenti.
Inoltre capita frequentemente che i nuovi prodotti ancora mai utilizzati
realmente su vasta scala o all’interno di un progetto industriale
sufficientemente elaborato per cercare di sfruttarne tutte le peculiarità, siano
affetti da vari errori di funzionamento nelle versioni distribuite e necessitino
quindi di una vasta comunicazione fra azienda sviluppatrice e casa madre
per la correzione.
Queste considerazioni non sono necessariamente un danno per il
progetto ma sicuramente ne aumentano il costo e rendono più ardua la stima
dei tempi necessari alle varie fasi del progetto.
Spostandoci ora in una fase un po’ più avanzata, si renderà importante
definire degli standard per l’organizzazione dei contenuti e della forma dei
deliverables delle varie fasi, essendo un progetto internazionale, essi
costituiranno le tappe e la prova dei progressi del lavoro non solo ai Project
Manager che lo dirigeranno ma probabilmente anche ad esaminatori
dell’Unione Europea ed ai responsabili delle aziende affiliate per il progetto.
Proprio con questi soggetti infatti l’azienda dovrà periodicamente
relazionarsi per ottenere i requisiti e i chiarimenti necessari al corretto
proseguimento della vita del progetto. Per fare ciò infatti sarà necessario del
37

39. personale qualificato sia per quanto riguarda il colloquio con gli altri soggetti
esterni, sia per quanto riguarda la conoscenza dei vari paesi ove risiedono le
aziende collaboratrici. Infatti una problematica da sempre riscontrata nella
fase di analisi è l’omissione di dettagli di un certo peso per una corretta
impostazione del progetto poiché il soggetto che deve descrivere il processo
li ritiene così scontati che dimentica di farne menzione nei colloqui. Tutto ciò
è ovviamente accentuato dal fatto che l’azienda sviluppatrice e quella
collaboratrice possono non essere connazionali andando così a limitare
significativamente quel margine di conoscenza che permette solitamente
all’analista, tramite domande mirate e l’esperienza, di identificare ed
eliminare le sopradette omissioni. Incisive saranno quindi le competenze
linguistiche e culturali per potersi avvalere efficacemente delle collaborazioni
con aziende estere. Bisogna ricordare che nonostante la tecnologia moderna
ci permetta di essere in contatto ventiquattro ore su ventiquattro con tutto il
mondo, certe questioni sia per un fatto diplomatico che da un punto di vista
pratico sarebbero da risolvere di persona; il che risulta problematico data la
possibile lontananza geografica con determinati soggetti coinvolti nel
progetto.
Per poter sviluppare alla massima efficienza un progetto sarebbe
necessario poter utilizzare, di volta in volta, la metodologia più congeniale
ed adattarla ad esso. In realtà ogni azienda sviluppatrice di software ha una
sua metodologia affermata che è stata negli anni assorbita dal personale, con
precisi modi di lavorare che personalizza l’azienda sia al suo interno che
dall’esterno. Questo metodo non è ovviamente rigido ma viene adattato, con
flessibilità propria di ogni azienda, al progetto in corso per permettere una
ottimizzazione dei costi all’azienda. Quindi è presumibile che nonostante il
progetto sia di ricerca, il suo cammino sarà comunque aderente al modus
operandi dell’azienda sviluppatrice.
38

40. L’attenzione ad altre procedure produttive di carattere più scontato
come definizione del cammino critico delle varie sottofasi del progetto,
l’ottimizzazione del tempo tramite una messa in parallelo delle stesse
formando diversi workgroup e loro controllo tramite milestones; si daranno,
per il momento, per pienamente efficienti ed assimilate dall’azienda
sviluppatrice. La stessa funzionalità dei deliverables per le fasi successive
però non è del tutto scontata dato che si è dovuto apporvi alcune modifiche
nella struttura e soprattutto nella lingua utilizzata per adoperarli, come
menzionato in precedenza, in ambito europeo.
4.3 Approfondimento
Conclusasi la prima fase di analisi dell’impatto del problema ora si è
pronti ad approfondire la struttura dell’azienda sviluppatrice. Come
premesso nella descrizione dello scenario la realizzazione di tale progetto
non è affidata ad un’ unica azienda ma ad un insieme di aziende software
affiliate per tale scopo e da alcune aziende collaboratrici, che saranno poi i
primi utilizzatori dei piloti del progetto. La distribuzione in diversi paesi di
tali soggetti implica un notevole incremento della difficoltà di coordinazione,
essa già problematica di per se dato il numero delle aziende coinvolte.
Quindi si proceda ad ampliare il soggetto analizzato in precedenza “Azienda
Sviluppatrice” considerando però invariato il rapporto fra essa e gli altri
soggetti come l’Unione Europea e l’approccio alle nuove tecnologie.
39

41. Si può immediatamente identificare un vantaggio del nuovo
diagramma, il problema menzionato in precedenza sui problemi degli
analisti nel colloquiare con aziende non connazionali e sulle relative
problematiche dovute alla lontananza si possono affievolire o risolvere
grazie alla disposizione di diversi partner dislocati in differenti paesi
europei. Però analizzando meglio la situazione ci si rende conto che il
problema di comunicazione si è spostato all’interno del gruppo sviluppatore
data la varietà di partner presenti. Questo non dovrebbe costituire una grave
complicanza rispetto alla situazione analizzata in precedenza poiché il
problema di comunicazione già esposto con le aziende si è affievolito e la
standardizzazione e l’internalizzazione dei documenti interni all’azienda
(deliverables) era già stata preventivata seppure per altre cause.
Lungi dall’essere risolto il problema di composizione eterogenea del
gruppo sviluppatore che introdurrà sicuramente altre problematiche, per lo
meno per quanto riguarda la necessità di ridefinire i documenti interni si può
dire che non ne aumenta la complessità già preventivata.
40

42. Si pensi ora alla composizione dei workgroup in un’azienda
sviluppatrice. Per favorire la produttività si tende ad aggregare gli elementi
più adatti ad un certo compito nello stesso gruppo per poi affidargli il ruolo
migliore alle loro capacità. Se questo ragionamento si applica anche per una
azienda sviluppatrice risulta palese che si potrà avere dei gruppi di lavoro
eterogenei trasportando tutte le problematiche precedentemente sollevate a
livello aziendale anche negli stessi workgroup.
La risoluzione di tali problemi risulta concorde con i ragionamenti
introdotti in precedenza, ovvero la standardizzazione degli artefatti e una
collaborazione aperta mediante molti dei canali di comunicazione che la
tecnologia moderna mette a disposizione.
Riferendosi alla struttura che abbiamo dato per scontata nella prima
analisi ci si deve necessariamente rende conto che ognuno dei partner
coinvolti avrà una sua metodologia affermata e operativa al suo interno.
Questa non necessariamente sarà simile a quella di un altro qualsiasi partner.
Generalmente la differente etnia provoca una grossa differenza del modo di
pensare, della cultura e delle conoscenze già su un singolo individuo quindi
non è così astratto preventivare, pensando a livello aziendale, di trovarsi di
fronte ad almeno una differente metodologia per paese di dislocazione dei
partner.
La problematica legata al linguaggio ora è amplificata dal numero di
soggetti coinvolti. Scendendo nel dettaglio delle aziende infatti, nonostante la
percentuale di personale con una conoscenza dell’inglese alquanto limitata
sia molto bassa in una singola azienda, ci si accorge che deve per forza
contare un numero congruo di persone se applicata all’intero gruppo di
sviluppo. Questo fatto può portare a difficoltà di alcuni workgroup di creare
materiale standard per le fasi successive. Il riscontrarsi di problemi
comunicazione è altrettanto plausibile ovviamente, nel caso sia necessario
41

43. colloquiare con altri workgroup non connazionali assegnati a sottofasi
relazionate ad essi. Naturalmente non è un problema di primaria importanza
poiché con un minimo di collaborazione interna aziendale, un intelligente
creazione dei workgroup e assegnazione ai vari compiti la situazione è
arginabile. Comunque però implicherà una maggiore attenzione in certe fasi
e una inadattabilità di una certa percentuale di personale a determinati
compiti, il che porta ovviamente ad un probabile aumento di tempo e denaro
impiegato nell’organizzazione del lavoro.
Parlando ora di suddivisione del lavoro, per quanto riguarda una
distribuzione delle fasi lavorative ad un numero elevato di soggetti di
devono ricordare le basi della ottimizzazione del lavoro. Infatti non è detto
che più persone si impiegano allo stesso progetto, maggiore sarà la
produttività del team; poiché superata una certa soglia si comincia a
spendere più tempo per la comunicazione interna che per lo sviluppo in
senso stretto. Tutto questo senza considerare che ogni soggetto coinvolto ha
bisogno di un livello specifico di conoscenza dell’avanzamento del progetto
generale, portando così ad aumentare i tempi necessari alla comunicazione
interna delle informazioni. Questo discorso è si può applicare sia al livello di
dettaglio esposto che riferito al numero di workgroup operativi in un
progetto. Spezzettando in troppe parti il lavoro si creano, a parte le
problematiche generiche di comunicazione appena accennate, delle
dipendenze forzate dal lavoro altrui che non sempre permettono lo svolgersi
del lavoro in parallelo delle attività. Anzi esse probabilmente tendono a
portare scompiglio, ritardi ed a periodi di improduttività di alcuni dei
workgroup. Senza considerare che queste conseguenze si possono
ripercuotere ed amplificare notevolmente nel caso le dipendenze
intercorrano fra gruppi di lavoro appartenenti a differenti partner (non
connazionali). Per questo è assolutamente necessario imporre uno standard
anche sulle piccole fasi e non solo sui deliverables finali delle varie attività.
42

44. Deve esserci omogeneità nei tool utilizzati per le varie attività e se proprio
ciò non risulta possibile a livello globale, almeno fra quelle attività che sono
in relazione di dipendenza diretta.
Essenziale per un progetto di queste dimensioni e per la quantità di
soggetti coinvolti, è realizzare che ogni partner è una azienda a se stante che,
anche se sta collaborando con le altre per il progetto, tenderà a dimostrare un
suo orgoglio aziendale, per così dire. Questa problematica non è banale
perché la base della collaborazione redditizia è la non competitività dei
partner per l’assegnazione dei compiti (la competitività non è
necessariamente dannosa, anzi fa bene in molti altri ambiti fungendo da
sprone per migliorare se stessi, la qualità e la velocità del lavoro).
Per poter comprendere appieno le implicazioni del problema si deve
analizzare come avviene l’assegnazione dei compiti in una struttura così
complessa, come al solito partiamo da un livello generale e molto
semplificato del problema.
Al fine di realizzare al meglio un progetto, la logica imporrebbe di
assegnare le fasi più critiche ai soggetti migliori e le fasi restanti ai gruppi
qualificati in ordine di importanza delle varie attività, invece il problema
andrebbe affrontato da un punto di vista inverso. Siccome la resistenza di un
oggetto è diretta funzione dell’anello più debole, sarebbe meglio assegnare
ad ogni gruppo l’attività che lui può svolgere meglio rispetto tutte le altre
attività restanti. Applicando questo ragionamento però si viene a creare la
problematica accennata in precedenza. Se ogni team viene assegnato in
questa ottica non è detto che a certe aziende arrivino incarichi appaganti o
che dimostrino credibilità ed di importanza nella loro partecipazione al
progetto. Bisogna assolutamente sfasare questa sensazione mettendo in
chiaro che ogni partner è di egual importanza, anche se non di egual peso sul
progetto. L’obiettivo del gruppo di sviluppo non è dimostrare quale sia la
gerarchia di qualità delle aziende coinvolte, ma realizzare il prodotto meglio
43

45. possibile sfruttando tutti i partner coinvolti nel modo migliore per il fine
collettivo. La risoluzione ideale per render appagati tutti del proprio operato
e della propria appartenenza al gruppo di sviluppo sarebbe una
assegnazione a rotazione delle attività di maggiore importanza nelle varie
iterazioni del progetto. Questo sarebbe nuovamente in contraddizione con il
metodo di assegnazione suggerito. Come accade molto spesso nella pratica,
si dimostra necessario considerare caso per caso ed applicare il punto di
incontro fra i vari metodi produttivi e diplomatici per il bene della stabilità
comune.
La quantità di problematiche sollevate semplicemente per strutturare il
lavoro necessario per l’effettiva realizzazione del progetto suggerisce che
probabilmente la dichiarazione della tempistica di progetto si rivelerà
inadeguata. Quasi ogni problema che è stato analizzato, come danno
collaterale, apportava un aumento di tempo e del costo del lavoro e ci sono
probabilità non nulle, proprio come in qualsiasi altro progetto, di incappare
in errori non direttamente dipendenti dalle considerazioni da effettuate. La
possibilità di un ritardo nei tempi è molto alta e esso non sarà da riferire al
termine edotto dall’Unione Europea ma da quello effettivo stimato del
progetto conclusasi completamente la fase di analisi.
44

46. 4.4 Riassumendo
In seguito all’analisi appena presentata, risultano essenziali molte
procedure nel complesso del progetto:
Nel definire il progetto bisogna essere in grado di quantificare e
valutare correttamente l’impatto di tecnologie particolari sul processo di
sviluppo.
Iniziare a formare il personale con largo anticipo e non durante il
progetto sia ai fini linguistici che tecnologici necessari per una ottimale
adeguatezza della forza lavoro ai compiti imminenti.
A fine di stimare la tempistica di progetto è necessario collezionare
informazioni dettagliate non solo sulle aziende coinvolte, ma su tutti i
dipendenti che verranno impiegati al progetto e sui workgroup in cui
operano solitamente, naturalmente ad un livello di aggregazione dei dati
adeguato (risulta ovvio che per il fine preposto non costituisce nessuna utilità
sapere il nome o l’indirizzo del soggetto in questione ma solamente le sue
abilità, conoscenze ed attitudini lavorative).
Definire in modo preciso e non ambiguo le relazioni (e mediante che
canali) che intercorrono fra il gruppo di sviluppo e i soggetti esterni, come i
valutatori dell’Unione Europea e i collaboratori delle aziende esterne.
Importante definire inoltre le relazioni per la comunicazione fra i vari
partner, creando molti canali di comunicazione e ben funzionanti
assegnando ad essi personale adatto e qualificato.
Siccome il progetto in esame è un progetto di ricerca risulta adeguato
dilatare opportunamente le tempistiche di alcune fasi e preventivare almeno
una iterazione aggiuntiva per eventuali evoluzioni delle funzionalità e degli
scopi del progetto. Il pessimismo nella stima è caratteristica di capacità
45

47. realistiche dell’azienda e diminuisce il rischio di disillusioni per il protrarsi
del termine di sviluppo. Inoltre nel qual caso tutto procedesse al meglio ci si
troverebbe ad aver ultimato il compito prima della scadenza dichiarata
lasciando tempo per rifiniture successive del prodotto che aumentano la
soddisfazione finale del cliente ma che, nel caso di scadenze troppo brevi,
non vengono attuate per la scarsa disponibilità di tempo.
Definire di comune accordo fra i partner degli standard interni per la
metodologia di sviluppo, la struttura e il contenuto dei deliverables, la
frequenza e la profondità dei controlli periodici di avanzamento del lavoro;
ma soprattutto definire ad un livello sufficiente di dettaglio le sottofasi della
Analisi e della Progettazione indicandone subito le dipendenze al fine di
evitare parallelismi impossibili. L’ideale sarebbe ottenere un diagramma di
Gantt funzionale delle fasi di analisi e progettazione includendo, come
precedentemente menzionato, le dilazioni opportune dei tempi e alcune fasi
riparatorie per fornire un margine accettabile alle incertezze non meglio
quantificabili ad inizio del progetto. Questo diagramma ovviamente non può
essere assolutamente definitivo ma deve aiutare a programmare il lavoro
evolvendo assieme alla precisa definizione del progetto.
46

48. 5. Approccio
Lo sviluppo effettivo di un progetto di ricerca internazionale e
collaborativo sarà estremamente complesso, specialmente dal punto di vista
coordinativo. Come è stato visto dall’analisi delle problematiche principali
riscontrabili in questo tipo di progetto, la maggior parte delle difficoltà
saranno per l’appunto dovute alla distribuzione e al controllo dei compiti.
I dettagli dei ponti di collegamento possibili fra le varie aziende ed
eventuali raccomandazioni su essi sono di scarsa importanza dal punto di
vista della metodologia a cui bisognerà ricorrere.
Questo poiché il come si collabora influisce parzialmente sulle fasi da
intraprendere e dagli artefatti da realizzare, al più implicherà delle restrizioni
sulla lingua utilizzata o sulle tempistiche di produzione.
Lo stesso discorso è applicabile anche alle problematiche di stima dei
tempi di progetto, il fatto che il tempo previsto subisca dei dilatamenti
dovuti alla struttura dell’azienda sviluppatrice non sarà direttamente
imputabile alla metodologia applicata bensì alla complessità della struttura.
Infatti si può affermare che, qualsiasi sia il metodo di lavoro scelto, la
probabilità di un ritardo è comunque stabile e principalmente dipendente
dall’organizzazione su cui viene applicato tale metodo.
L’unica problematica rimanente è quindi la presenza di differenti
competenze distribuite all’interno delle varie aziende affiliate e dei gruppi di
lavoro. Ciò porta ad un bivio di entità notevole, o si opera una pesante
istruzione del personale per eliminare il problema o si attua una modifica
della metodologia al fine di poter essere approcciata anche da chi ha scarse
nozioni in tale materia.
47

49. La situazione ideale prevedrebbe ovviamente il colmare le lacune del
personale, investendo così sui propri dipendenti ed aumentando il valore
della propria azienda. Ma una manovra del genere nella pratica è
estremamente difficile, specialmente data la natura internazionale del
progetto in esame.
D’altro canto un livellamento troppo drastico di una qualsiasi
metodologia otterrebbe sì un facile assorbimento dal personale non
competente, ma comporterebbe senza ombra di dubbio degli effetti negativi
enormi sul prodotto finale.
A seguito di queste ultime considerazioni si deve prendere atto che
l’una o l’altra via non sono percorribili nella realtà di un progetto
internazionale, a parte rari casi. In generale quindi l’approccio applicabile
consisterebbe in uno snellimento di una metodologia molto versatile, al fine
di poter effettuare con un buon livello di dettaglio le fasi principali previo
breve istruzione del personale. Alcune fasi o artefatti delle metodologie di
progetto infatti non sono particolarmente complesse e un dipendente medio
può riuscire a svolgerle con successo senza particolari preparazioni, ma con
sicuramente l’ausilio di una buona documentazione. Data la necessità di
flessibilità e di segmentazione necessarie ad una metodologia per poter
essere snellita in modo proficuo al fine preposto, si prenderà in
considerazione l’approccio iterativo ed incrementale messo a disposizione
dal Rational Unified Process. Esso infatti risulta essere un metodo
incredibilmente ampio e versatile, proprio per sua costruzione, e quindi
perfettamente aderente al problema in esame. L’obiettivo quindi è proprio
l’identificazione di una fetta del RUP che calzi con il progetto in lavoro,
ovvero trovare una buona guida metodologica per permettere una buona
organizzazione e resa lavorativa.
48

50. Inserendo questo lavoro in un progetto di ricerca già avviato da diversi
anni come Euridice, risulta difficoltoso estendere questa procedura
sull’intera metodologia. Inoltre un tale compito risulterebbe di difficoltà ben
più elevata e sicuramente l’aprirsi di una discussione generale sullo
snellimento del RUP in tutte le sue fasi per l’applicazione a progetti del tipo
sopraesposto comporterebbe discussioni pressoché infinite nell’ambito
analistico.
Rifacendosi alle spiegazioni del metodo menzionate nel capitolo
apposito presentiamo a seguire una figura esplicativa della struttura di
un’iterazione prevista dal metodo RUP applicata ad Euridice.
Come è visibile nella figura, le fasi iniziali sono state scomposte e
dettagliate per fornire maggiore dettaglio. Inoltre si può osservare che sono
state utilizzate le nomenclature tipiche dell’Unified Modeling Language. Per
la fase di analisi si è applicato ovviamente la Use Case Analysis o Analisi per
casi d’uso.
49

51. Lo sviluppo di Euridice era per l’appunto giunto alla conclusione della
fase di analisi. Sarà ora necessario cimentarsi nella fase di progettazione, che
nel caso specifico includerà la realizzazione dei casi d’uso definiti nella fase
di analisi. Lo scopo è quindi quello di identificare il numero minimo di
artefatti necessari ad una completa progettazione, seguendo il metodo della
realizzazione dei casi d’uso facendo riferimento al linguaggio UML.
50

52. 5.1 Guida Metodologica alla progettazione
Vengono di seguito descritti brevemente i fondamenti necessari alla
comprensione degli artefatti risultanti dalla fase di analisi per poter poi
proseguire correttamente nella progettazione.
Essendo la realizzazione dei casi d’uso tramite diagrammi UML un
approccio visuale alla progettazione degli stessi, esiste un vasto numero di
modi per procedere. Inevitabilmente lavorando in modo visuale si può
cogliere il sistema in esame da un solo punto di vista, quindi è scontato che
saranno necessari vari diagrammi per una rappresentazione completa del
caso.
Verrà reso necessario e quindi descritto il minor numero possibile di
diagrammi cercando comunque di mantenere una completa definizione nella
realizzazione del caso d’uso. Inoltre il metodo UML mette talvolta a
disposizione più diagrammi che rappresentano lo stesso concetto ma in
maniere differenti. In caso tale punto di vista sia rivesta fondamentale
importanza nella definizione della UCR allora si propenderà per quel
diagramma più semplicemente sviluppabile.
Use Case
I casi d’uso costituiscono un ottimo strumento per ottenere una visione
d’insieme del sistema che si sta analizzando, rappresentano un
comportamento dal punto di vista dell’utilizzatore del sistema e sono
finalizzati a modellare il dialogo tra utilizzatore e sistema. Per questo si dice
che i casi d’uso forniscono una visione del progetto. Infatti essi:
• descrivono l’interazione fra attori e sistema, non la logica interna della
funzione;
51

53. • sono espressi in linguaggio naturale e sono comprensibili anche a
lettori non tecnici;
• descrivendo i casi d’uso si definiscono i requisiti funzionali di
progetto;
• possono essere un valido ausilio nel dialogo con l’utente ed in
generale con esponenti non tecnici;
L’attore è un’entità esterna al sistema, può essere umano o un altro
sistema, che fornisce lo stimolo a cui esso risponde con specifici
comportamenti. Tutto ciò è definito nella Analisi dei casi d’uso che si
conclude quando la maggior parte dei casi d’uso è stata descritta.
Per ognuno di essi devono essere stati definiti: precondizioni, attori
coinvolti, obiettivi, svolgimento principale degli eventi dello scenario,
svolgimenti alternativi e post condizioni.
Nella fase di design si dovrà prendere in considerazione quindi questi
casi d’uso e delle loro descrizioni, che sono il risultato della fase di analisi, ed
iniziare a definirli prendendo in considerazione anche i requisiti tecnologici
che vengono scelti per il progetto.
52

54. Lo scopo essenziale è chiarire come gli attori interloquiscano con i vari
casi d’uso e di che dati abbiamo effettivamente bisogno per operare. Allo
scopo di fare ciò si tenderà per un approccio visuale utilizzando lo standard
UML anche se sarà necessario allegare comunque una buona
documentazione scritta.
Use Case Realization
La realizzazione dei casi d’uso, o UCR, rappresenta la prospettiva della
progettazione dei casi d’uso derivati dalla fase di analisi. Ogni artefatto
prodotto durante la fase di design andrebbe associato al caso d’uso da esso
analizzato, ma proprio per poter disaccoppiare la fase di analisi da quella di
design si introduce il concetto di UCR.
Siccome nella fase di design si deve tener conto dei vincoli tecnologici si
può intuire che un singolo caso d’uso può essere progettato in più modi
diversi. Quindi possono esistere diversi UCR associati allo stesso caso d’uso,
e siccome gli artefatti della fase di design vengono di conseguenza associati
allo specifico UCR si facilità la gestione separata degli use case realizzati
nella fase di analisi dalla loro realizzazione.
Questa strategia è particolarmente indicata per progetti di grandi
dimensione ove lo stesso caso d’uso può essere progettato in modo diverso
per la necessità del suo utilizzo su diverse piattaforme.
Per rappresentare tutto ciò si utilizza un diagramma della realizzazione
dei casi d’uso sarà semplicemente sufficiente trattare ogni UCR come una
generalizzazione dei caso d’uso con una notazione del tipo UC UCR come è
53

55. visibile nella figura successiva.
Per ogni UCR è necessario identificare gli oggetti che partecipano alla
composizione del caso d’uso. Al fine di descrivere completamente un caso
d’uso il linguaggio UML mette a disposizione una grande varietà di
diagrammi. Lo scopo di questa fase è di identificare per ogni UCR tutti gli
elementi statici e dinamici coinvolti.
Gli elementi statici di un oggetto sono i dati persistenti di cui necessita
per operare e le relazioni che lo legano ad altri oggetti. Gli elementi dinamici
invece possono essere descritti come le modalità di collaborazione fra oggetti
per realizzare una determinata funzione.
Evidenziamo anzitutto tre tipi di oggetti e loro notazione in UML:
• Entità
che rappresentano i dati persistenti di cui necessita lo UC
• Interfacce
sono oggetti necessari per il corretto dialogo con elementi
esterni (input/output)
• Controlli
che rappresentano la logica di business del sistema
Per ogni use case realization si dovranno evidenziare almeno tre
oggetti: un’Entità, un’interfaccia e un controllo.
54

56. La figura seguente mostra un diagramma per la realizzazione di un
caso d’uso “Receive Deposit Item”, si può notare che il livello di descrizione
è molto alto e serve quindi solo ad identificare gli oggetti coinvolti. Una
classe e i suoi oggetti possono spesso partecipare a svariate realizzazioni
differenti di un caso d’uso.
Definendo gli UCR probabilmente si nota che alcuni oggetti vengono
impiegati in un numero elevato di casi. È consigliato dunque controllare
come un oggetto debba essere realmente strutturato per favorirne la
riusabilità attraverso i vari UCR.
I diagrammi più importanti per la corretta realizzazione dei casi d’uso
sono i seguenti:
• Sequence Diagram : descrive un preciso scenario di un caso d’uso
seguendone la linea temporale
• Class Diagram : evidenzia i contenuti statici del caso d’uso
• State Diagram : analizza il comportamento e la vita di un oggetto
attraverso tutti i casi d’uso che lo utilizzano
Nelle descrizioni seguenti verranno fornite delle semplici
esemplificazioni di ogni tipo di diagramma per permetterne una più rapida
comprensione. Inoltre nel Capitolo 6 verranno applicati praticamente ad un
55

57. caso d’uso di Euridice fornendo un ulteriore approfondimento al metodi di
sviluppo dei sopra esposti diagrammi.
56

58. Diagrammi di Sequenza
Il diagramma di sequenza rientra negli Iteration Diagrams. L’obiettivo
di questa categoria di diagrammi è descrivere come un gruppo di oggetti
cooperi per realizzare una funzione.
Nello specifico del Sequence diagram, esso analizza un singolo
svolgimento del caso d’uso (principale o alternativo) e il modo in cui viene
svolto dalla collaborazione tra un insieme di oggetti, specificando la
sequenza dei messaggi scambiati tra gli stessi. Possono essere evidenziati
nodi decisionali e/o iterazioni.
Questo tipo di diagramma viene anche detto di interazione in quanto
mostra le interazioni tra oggetti del sistema, modella il comportamento
dinamico del sistema ed evidenzia in particolare l’ordine temporale dello
scambio di messaggi.
Tutti i tipi di oggetto che vengono richiamati per svolgere l’interazione
devono essere rappresentati da un riquadro nella parte superiore del
diagramma.
Le linee verticali rappresentano la linea della vita, o lifeline, dell’oggetto
suo proprietario nell’arco di durata dell’interazione.
Per mostrare quando un oggetto è attivo si include un riquadro di
attivazione che viene riportato sulla sua lifeline.
Quando un oggetto viene eliminato si appone una “X” sul punto
temporalmente corretto e si interrompe la sua lifeline.
Tutti i messaggi scambiati fra due oggetti durante la loro vita sono
rappresentati da una freccia del tipo sorgente→destinatario e per ognuna di
loro deve essere indicato almeno il nome di tale messaggio. Possono poi
essere presenti messaggi prodotti dallo stesso oggetto che ne è il destinatario,
essi si chiamano self-call. Importante sottolineare che nonostante la notazione
57

59. del messaggio, esso rappresenta la chiamata del sorgente ad una funzione
del destinatario.
I messaggi possono essere fondamentalmente di due tipi:
• Sincrono
l’emittente attende una risposta da parte del destinatario
• Asincrono
la risposta del ricevente, se è contemplata, potrà essere inviata in un
qualsiasi momento successivo
Se un messaggio ha una condizione per il suo invio si parla di
messaggio condizionato e viene rappresentato tramite la specifica in
parentesi quadre della sua condizione di invio. Questi messaggi vengono
inviati quindi solo se al percorri mento temporale sulla lifeline dell’oggetto
tale requisito è soddisfatto nel superamento del messaggio condizionato.
Per indicare una iterazione di un messaggio si indica all’inizio del nome
dello stesso un “ * ”, questo starà a significare che il messaggio in questione
viene inviato più volte a più oggetti che però rientrano nella stessa categoria.
58

60. Generalmente si consiglia l’utilizzo di descrizioni testuali sulla parte
sinistra del diagramma in tutti gli snodi principali per favorirne la leggibilità.
Diagrammi delle Classi
L’obiettivo dei diagrammi delle classi è visualizzare la parte statica del
sistema rappresentando tutti gli oggetti, con i relativi attributi ed operazioni,
che lo compongono.
I collegamenti fra le classi rappresentano le associazioni che
intercorrono fra esse. Tali associazioni possono essere corredate da un
insieme di informazioni aggiuntive, per esempio relative alla molteplicità:
• Uno-a-uno
ad ogni occorrenza dell’oggetto A si può associare univocamente
un’occorrenza dell’oggetto B e viceversa;
(Es° dipendente↔matricola)
• Uno-a-Molti
per ogni occorrenza dell’oggetto B si può associarne una sola
dell’oggetto A, ma per ognuna dell’oggetto A possono essercene un
qualsiasi numero dell’oggetto B associate; (Es° Project
Manager↔Progetto)
• Molti-a-Molti:
per ogni occorrenza dell’oggetto A si possono associare più
occorrenze dell’oggetto B e viceversa; (Es° deliverable↔autore)
È consigliato inserire una nomenclatura alle associazioni la dove ciò
favorisca una maggiore leggibilità al diagramma.
59

61. Questi diagrammi utilizzano diversi concetti base del paradigma
Object-Oriented ed altri correlati, fra questi se ne distingueranno per
importanza quattro: Aggregazione, Composizione, Dipendenza e
Generalizzazione. Ognuna delle sopra citate viene rappresentata mediante
una particolare freccia che connette le due classi coinvolte.
L’aggregazione è un particolare tipo di associazione che prevede una
relazione fra delle entità autonome ed una che può essere definita solo dalla,
per l’appunto, aggregazione di esse. Un buon esempio risulta un automobile:
essa è composta dall’aggregazione di carrozzeria, motore, ruote e così via.
La composizione è una relazione forte, può essere descritta in maniera
similare all’aggregazione con la differenza che le entità che vengono messe in
relazione di composizione seguono poi il ciclo di vita dell’istanza composta.
Importante sottolineare che ogni oggetto può essere componente di un solo
oggetto composto alla volta, il che differisce palesemente dall’esempio
utilizzato in precedenza dell’automobile; ove per esempio un motore può
essere montato su più tipi di auto.
Una associazione di dipendenza sta ad indicare che un cambiamento di
un attributo di una classe può andare richiedere modifiche negli attributi
dell’altra, non necessariamente è implicato il viceversa.
Alcune classi possono avere diverse varianti, ed ogni variante può
avere diversi ruoli nel sistema. Per rendere tutto ciò rappresentabile in un
diagramma delle classi si ricorre al concetto di generalizzazione. Essa si
indica con una freccia del tipo sottoclasse sopraclasse come si può vedere
nella figura seguente per LibroPregiato che specifica l’oggetto Libro. Il
significato di tale azione e della notazione sono sufficientemente espliciti da
non richiedere ulteriori dilunga menti in proposito.
60

62. Ogni oggetto viene rappresentato tramite un rettangolo suddiviso in tre
scomparti, rispettivamente dedicati al nome della classe, agli attributi e alle
operazioni.
La visibilità di ogni attributo e di ogni operazione è specificata in UML
attraverso l'uso di vari simboli:
“-” visibilità privata: l'attributo è accessibile solo dall'interno della
classe usando i propri metodi;
“+” visibilità privata: l'attributo o il metodo è accessibile anche
dall'esterno;
“#” visibilità protetta: l'attributo o il metodo viene ereditato da tutte le
classi da questa derivate.
61

63. Gli attributi devono essere indicati per nome con eventualmente il tipo
e il valore di default seguendo il seguente standard:
“ nome_visibile : tipo = valore_default ”
Es° “ autore_anno_morte : data = Null ”
L’elenco delle operazioni evidenziate in questo diagramma rappresenta
l’insieme delle principali operazioni eseguibili all’interno dello UCR.
Importante è specificare che non tutte le operazioni delle classi hanno lo
stesso impatto sul sistema. Infatti risulta estremamente utile distinguere le
semplici query (operazioni sugli attributi) da quelle operazioni che vanno a
modificarli (operazioni di update).
La sintassi completa per la descrizione delle operazioni in UML è la
seguente:
“ nome_visibile ( lista parametri ) : tipo_risultato_op {proprietà} “
Es° “ libro_pregiato_valorizza ( ) : float { } “
62

64. Diagrammi di Stato
È utile utilizzare il diagramma di stato per evidenziare come si
comporta un oggetto attraverso più casi d’uso, esso infatti specifica tutto il
ciclo di vita di tale oggetto e definisce le regole che ne governano le
transizioni di stato.
Risulta chiaro dunque descrivere questo tipo di diagramma come un
automa a stati finiti, pertanto esso sarà costituito da stati, attività e
transizioni.
Quando un oggetto è in un certo stato infatti, solo determinati eventi
causeranno una transizione di stato e non tutti. Viene utilizzato
principalmente come completamento della descrizione degli oggetti. Data la
sua natura specifica non risulta sempre naturale svilupparlo correttamente e
può sembrare non sempre utile al procedere del lavoro, infatti è direttamente
dipendente del progetto quali diagrammi siano più o meno efficaci per
procedere.
63