Progetto Euridice

98
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

description

Progetto Euridice: Identificazione ed Applicazione delle metodologie di Progettazione

Transcript of Progetto Euridice

Page 1: Progetto Euridice

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

Page 2: Progetto Euridice

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

Page 3: Progetto Euridice

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

Page 4: Progetto Euridice

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.

Page 5: Progetto Euridice

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.

Page 6: Progetto Euridice

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.

Page 7: Progetto Euridice

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.

Page 8: Progetto Euridice

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

Page 9: Progetto Euridice

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;

Page 10: Progetto Euridice

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

Page 11: Progetto Euridice

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

Page 12: Progetto Euridice

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

Page 13: Progetto Euridice

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.

Page 14: Progetto Euridice

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;

Page 15: Progetto Euridice

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

Page 16: Progetto Euridice

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

Page 17: Progetto Euridice

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;

Page 18: Progetto Euridice

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.

Page 19: Progetto Euridice

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à

Page 20: Progetto Euridice

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;

Page 21: Progetto Euridice

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;

Page 22: Progetto Euridice

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;

Page 23: Progetto Euridice

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)

Page 24: Progetto Euridice

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.

Page 25: Progetto Euridice

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;

Page 26: Progetto Euridice

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

Page 27: Progetto Euridice

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

Page 28: Progetto Euridice

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

Page 29: Progetto Euridice

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

Page 30: Progetto Euridice

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:

Page 31: Progetto Euridice

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)

Page 32: Progetto Euridice

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

Page 33: Progetto Euridice

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?);

Page 34: Progetto Euridice

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?);

Page 35: Progetto Euridice

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

Page 36: Progetto Euridice

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.

Page 37: Progetto Euridice

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.

Page 38: Progetto Euridice

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

Page 39: Progetto Euridice

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.

Page 40: Progetto Euridice

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.

Page 41: Progetto Euridice

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.

Page 42: Progetto Euridice

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

Page 43: Progetto Euridice

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

Page 44: Progetto Euridice

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

Page 45: Progetto Euridice

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.

Page 46: Progetto Euridice

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à

Page 47: Progetto Euridice

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.

Page 48: Progetto Euridice

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.

Page 49: Progetto Euridice

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.

Page 50: Progetto Euridice

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.

Page 51: Progetto Euridice

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.

Page 52: Progetto Euridice

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;

Page 53: Progetto Euridice

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.

Page 54: Progetto Euridice

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 è

Page 55: Progetto Euridice

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.

Page 56: Progetto Euridice

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

Page 57: Progetto Euridice

56

caso d’uso di Euridice fornendo un ulteriore approfondimento al metodi di

sviluppo dei sopra esposti diagrammi.

Page 58: Progetto Euridice

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

Page 59: Progetto Euridice

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.

Page 60: Progetto Euridice

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.

Page 61: Progetto Euridice

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.

Page 62: Progetto Euridice

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.

Page 63: Progetto Euridice

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 { } “

Page 64: Progetto Euridice

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.

Page 65: Progetto Euridice

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

Page 66: Progetto Euridice

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.

Page 67: Progetto Euridice

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.

Page 68: Progetto Euridice

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()

Page 69: Progetto Euridice

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.

Page 70: Progetto Euridice

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.

Page 71: Progetto Euridice

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

Page 72: Progetto Euridice

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.

Page 73: Progetto Euridice

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

Page 74: Progetto Euridice

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.

Page 75: Progetto Euridice

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.

Page 76: Progetto Euridice

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

Page 77: Progetto Euridice

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

Page 78: Progetto Euridice

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

Page 79: Progetto Euridice

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.

Page 80: Progetto Euridice

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.

Page 81: Progetto Euridice

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.

Page 82: Progetto Euridice

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.

Page 83: Progetto Euridice

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()

Page 84: Progetto Euridice

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.

Page 85: Progetto Euridice

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.

Page 86: Progetto Euridice

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

*

Page 87: Progetto Euridice

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.

Page 88: Progetto Euridice

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.

Page 89: Progetto Euridice

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()

Page 90: Progetto Euridice

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

Page 91: Progetto Euridice

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.

Page 92: Progetto Euridice

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()

Page 93: Progetto Euridice

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:

Page 94: Progetto Euridice

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

Page 95: Progetto Euridice

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.

Page 96: Progetto Euridice

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

Page 97: Progetto Euridice

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.

Page 98: Progetto Euridice

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.