Main

Dispense del corso di Ingegneria del Software
Francesco Sisini
8 Marzo 2008
1
Indice
1 L’approccio ingegneristico 3
1.1 Il processo di sviluppo del software . . . . . . . . . . . . . . 5
1.2 Il piano del progetto . . . . . . . . . . . . . . . . . . . . . . . 5
2 I Requisiti del software 6

2.1 Classificazione dei requisiti . . . . . . . . . . . . . . . . . . . 7
2.1.1 Requisiti utente . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 requisiti di sistema . . . . . . . . . . . . . . . . . . . . 8
2.2 Requisiti funzionali e non funzionali . . . . . . . . . . . . . . 8
2.3 Il documento dei requisiti . . . . . . . . . . . . . . . . . . . . 9
2.4 Scrivere codice o documenti? . . . . . . . . . . . . . . . . . . 10
2.5 Raccolta e formalizzazione dei requisiti . . . . . . . . . . . . 11
2.5.1 Progetto ReadyReport . . . . . . . . . . . . . . . . . . 12
3 Le basi della progettazione 13

3.1 Dai requisiti di sistema al progetto . . . . . . . . . . . . . . . 13
3.2 Modelli del progetto ReadyReport . . . . . . . . . . . . . . . 15
3.2.1 Flusso dei dati nel sistema informativo ospedaliero . 16
3.2.2 Il contesto di ReadyReport . . . . . . . . . . . . . . . 16
3.2.3 Il flusso dei dati di ReadyReport . . . . . . . . . . . . 20
3.2.4 Architettura . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.5 Classificazione . . . . . . . . . . . . . . . . . . . . . . 20
3.2.6 Modello dei dati . . . . . . . . . . . . . . . . . . . . . 23
3.3 La progettazione . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3.1 L’architettura edilizia, un paragone . . . . . . . . . . 25
3.3.2 Vantaggi e svantaggi della progettazione . . . . . . . 26
3.4 Componenti, connettori e dati . . . . . . . . . . . . . . . . . . 26
3.4.1 I componenti . . . . . . . . . . . . . . . . . . . . . . . 26
3.4.2 I connettori . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Organizzazione, scomposizione e controllo . . . . . . . . . . 28
3.5.1 Organizzazione . . . . . . . . . . . . . . . . . . . . . . 28
3.5.2 Scomposizione in moduli . . . . . . . . . . . . . . . . 29
3.5.3 Controllo . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.6 La documentazione del progetto . . . . . . . . . . . . . . . . 30
3.7 Le viste di ReadyReport . . . . . . . . . . . . . . . . . . . . . 31
4 Sviluppo 37
4.1 Requisiti statici . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Requisiti dinamici . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.1 progettazione per prototipi . . . . . . . . . . . . . . . 38
4.2.2 Esempio pratico . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Requisiti complessi . . . . . . . . . . . . . . . . . . . . . . . . 39
2
5 I Design Pattern 41
5.1 Il pattern Mode View Controller (MVC) . . . . . . . . . . . . 42
5.2 Le web application ed il MVC . . . . . . . . . . . . . . . . . . . 42
5.2.1 La struttura delle WEB application . . . . . . . . . . . 44
5.2.2 Il pattern MVC per il controllo delle web application 45
5.3 Il pattern MVC in ReadyReport . . . . . . . . . . . . . . . . . 46
5.3.1 Il Model . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.2 Controller . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.3.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6 Verifica e convalida 49
6.1 Cominciare bene . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.2 Dopo la progettazione e dopo lo sviluppo . . . . . . . . . . . 50
6.3 I test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Omissioni 52
3
Introduzione
Qual’ é la differenza tra la programmazione e lo sviluppo di un sofware? La
programmazione di una macchina consiste nella codifica in un linguaggio
artificiale di un dato algoritmo. Quando un programmatore si dedica al-
la programmazione ha normalmente giá chiaro l’algoritmo e la sua attivitá
si concentra nell’individuarne la migliore implementazione nel linguaggio
scelto. Si puó affermare che la programmazione ha lo scopo di trasformare
un algoritmo espresso in un qualche linguaggio informale o pseudoformale
in un algoritmo espresso in un linguaggio di programmazione per cui esista
un compilatore e che tale attivitá deve essere svolta tenendo conto di tutti
gli aspetti tecnologici che possono ottimizzare l’esecuzione del programma
e sono indipendenti dalla logica propria dell’algoritmo (programmazione
parallela, ottimizzazione dei cicli...).
Lo sviluppo del software consiste nella organizzazione di una serie proces-
si e attivit con lo scopo di scrivere, documentare ed installare un insieme di
programmi, scripts e configurazioni di sistema che costituiranno una parte
o il tutto di un sistema informatico.
La differenza fondamentale che esiste quindi tra la programmazione e lo
sviluppo del software é che mentre la prima porta il programmatore a rela-
zionarsi con un sistema formale (il modello logico da cui si tra l’algoritmo)
il secondo é centrato su capacitá organizzative e di coordinamento di atti-
vitá reali e non formali.
In alcune realtá industriali esiste una netta separazione tra i ruoli di ar-
chitetto, ingegnere e sviluppatore del software, in altre chi si occupa dello
sviluppo stabilisce anche l’architettura ma non segue il processo ingegne-
ristico, in altre ancora non esiste una netta separazione di questi ruoli ne a
livello formale ne concreto.
Nella realtá produttiva italiana si trovano spesso delle situazioni in cui il
processo di sviluppo del software é seguito direttamente dagli sviluppato-
ri che il piú delle volte si occupano anche della definizione dell’architettura.
L’obiettivo di questo corso é di offrire agli studenti l’occasione per focaliz-
zare l’attenzione sulla problematica dello sviluppo del software. Dal mo-
mento che questo corso viene tenuto in un ateneo italiano e che statistica-
mente ci si puó aspettare che la maggior parte degli studenti svolgeran-
no la loro futura attivitá in questo paese i concetti saranno presentati nel-
l’ottica che le tre figure sopra citate (ingegnere, architetto e sviluppatore)
coesistano in un unica figura.
1 L’approccio ingegneristico
Lo sviluppo/manutenzione di un software puó nascere per vari motivi, tra
i quali si hanno:
4
• commessa di un cliente
• progetto interno ad un’azienda
• progetto interno ad una comunitá
• progetto Open Source di ampio respiro
L’approccio ingegneristico alla gestione di un progetto software non é so-

stanzialmente influenzato dalla natura del progetto. Dal punto di vista in-
gegneristico, l’obiettivo é quello di condurre in porto il progetto cercando
di ottenere il miglior risultato possibile impiegando le risorse in modo ade-
guato.
Per acquisire un approccio ingegneristico é necessario anzi tutto porre l’at-
tenzione sui problemi concreti legati alla gestione di un progetto cercando
di acquisire una visione razionale del progetto. Questo porta a dover anzi
tutto analizzare il contesto del progetto e catalogarlo per categorie.
Le principali categorie che si trovano in questo ambito sono:
Progetto (del cliente) : con progetto si intendono cose diverse ed il suo

significato é normalmente chiarito dal contesto. In questo caso si
intende l’idea che il cliente vuole trasformare in software.
Cliente : in generale é chi commissiona il progetto.
Requisiti : sono un insieme di qualitá e funzionalitá richieste al software

che si vuol sviluppare.
Vincoli : si intende normalmente un insieme di requisiti che sono indipen-

denti dagli obiettivi del progetto e riguardano invece dei requisiti sui
tempi e modi di condurre il processo di sviluppo del progetto.
Utenti finali : sono le persone o i sistemi che interagiranno in maniera

diretta con il software.
Finanziatore : persone o organizzazioni che finanziano il progetto, posso-

no essere assolutamente indipendenti dal cliente.
Tester : persone o sistemi che possono testare il software.
Architetto : stabilisce la struttura del software in termini di sottosistemi

piú semplici.
Sviluppatore : scrive e compila il codice.
La gestione dei prodotti di queste categorie e delle loro relazioni costituisce

l’aspetto principale della gestione di un progetto software.
Lo sviluppo di un progetto software é una serie di attivitá svolte da di-
versi attori che hanno un inizio uno sviluppo ed un termine. Ognuna di
5
esse costituisce quindi un processo e considerate tutte insieme definiscono
il processo di sviluppo (del software).
Queste attivitá sono svolte, decise e guidate normalmente da esseri umani
e pertanto non sono controllabili con la stessa precisione con cui é possibile
controllare le attivitá svolte da una macchina, inoltre il risultato di queste
attivitá ha spesso un carattere intangibile e questo rende ancor piú com-
plesso il loro controllo ma anche il loro monitoraggio.
Altre branche dell’ingegneria debbono occuparsi della gestione di processi
ed attivitá guidati dall’uomo ma, come si avrá modo di capire, l’ingegneria
del software spicca per la particolare complessitá di questa gestione. Le ra-
gioni di questo sono probabilmente da ricercarsi sia nel fatto che il prodotto
di questo processo ingegneristico é qualcosa che sta a metá tra il prodotto
ed il servizio ed é comunque non tangibile quanto nel fatto che ancora sia
gli ingegneri che i clienti non hanno ancora maturato una vera esperienza
con questi processi in quanto l’ingegneria del software ha poco meno di
quarant’anni.
1.1 Il processo di sviluppo del software

Gestire il processo di sviluppo é il compito dell’ingegneria del software.
Normalmente il processo di sviluppo viene suddiviso in quattro categorie
principali, queste sono:
Analisi dei requisiti : questa é l’insieme delle attivitá che hanno lo scopo
di chiarire e formalizzare l’obiettivo finale per cui il software viene
sviluppato (o modificato), l’insieme delle funzionalitá che il software
deve offrire e le qualitá che deve possedere.
Progettazione : comprende sia la progettazione del sistema software (ar-
chitettura, tecnologie e hardware) che la progettazione delle metodo-
logie, delle risorse e del team di sviluppo.
Sviluppo : si intende normalmente la scrittura, la compilazione ed il test
del codice.
Test e validazione : sono le attivitá per verificare la correttezza del soft-
ware la sua robustezza e l’affidabilitá.
Queste quattro macro attivtá (o fasi) del processo spesso non sono ben di-
stinte ed i loro contorni sfumano l’uno nell’altro. La sequenza e la pianifi-
cazione di queste fasi rappresenta un aspetto importante della gestione del
processo.
1.2 Il piano del progetto

Il piano del progetto é un documento che viene redatto da chi ha la responsa-
bilitá di gestire il processo di sviluppo ed é sicuramente un buon punto di
6
partenza.
Questo documento non deve descrivere i requisiti e l’architettura del pro-
getto, questi elementi infatti saranno chiariti e approfonditi nel corso del
progetto stesso, lo scopo di questo documento é quello di chiarire nella
mente dei soggetti che parteciperanno al progetto (clienti, utenti, finanzia-
tori, architetti, sviluppatori ed ingegneri) i punti seguenti:
Introduzione : gli scopi del progetto e ció che si intende realizzare, le

parti che partecipano al progetto, una stima del budget (risorse eco-
nomiche a disposizione di chi sviluppa) ed una stima del valore del
progetto.
Organizzazione : le parti in gioco ed i ruoli che ciascuno copre all’interno

del progetto. L’organizzazione dei team di analisi, sviluppo e test.
Rischi del progetto : sono una serie di eventi e circostanze su cui non si ha
il controllo diretto. I rischi vengono spesso classificati come: tecnolo-
gici, del personale, organizzativi, strumentali, dei requisiti e di stima
(dei tempi e delle risorse).
Hardware e software : i componenti hardware e software necessari per

lo sviluppo del progetto. Questa voce puó riferirsi sia al team di
sviluppo che al cliente.
Attivitá e tempistica o pianificazione : l’elenco delle attivitá principali e

la loro pianificazione nel tempo (questo paragrafo sará soggetto a
molte variazioni nel corso dello sviluppo del progetto).
Licenze e brevetti : si descrive la politica di tutela dei diritti d’autore che si

intende applicare oltre alla eventuale necessitá di dotarsi di specifiche
licenze o per lo sviluppo o per il cliente.
Principi progettuali : eventuali principi progettuali che saranno rispettati.
Il piano del progetto permette di chiarire l’organizzazione del progetto e

le varie attivitá che verranno svolte. É bene che anche il cliente abbia una
versione di questo documento.
A partire da questo piano é possibile pianificare l’analisi dei requisiti che
saranno argomento del prossimo paragrafo.
2 I Requisiti del software

Qualsiasi opera ingegneristica é soggetta a ben determinati requisiti. L’e-
spressione artistica pura, il pensiero libero, i sentimenti ed altre categorie
non ingegneristiche possono dissociarsi da questo assioma, ma ció che viene
prodotto dall’uomo in termini di beni e servizi é soggetto a requisiti.
7
I requisiti qualitá e funzionalitá che il software deve possedere e fornire per
essere considerato conforme ai propositi ed agli obiettivi che ne hanno de-
terminato lo sviluppo.
Nell’ambito dell’ingegneria del software la problematica dell’acquisizione,
dell’analisi e dalla documentazione dei requisiti é materia viva e tuttora in
discussione. Alcuni ingegneri professano la necessitá di applicare metodi
formali e procedure di qualitá per la gestione dei requisiti (metodi Hea-
vyweight o Monumental), altri hanno sviluppato delle metodologie leggere
che in linea di principio permettono di seguire l’ingegneria dei requisiti in
maniera snella e produttiva.
Il punto di vista di questo corso é che indipendentemente dalla metodolo-
gia che si intende usare per la documentazione dei requisiti, questi debbono
essere assolutamente ben noti a tutti gli attori che partecipano al progetto,
anche se ovviamente la prospettiva sotto cui questi saranno osservati di-
penderá ovviamente dal ruolo svolto dall’ attore.
2.1 Classificazione dei requisiti

I requisiti vengono normalmente classificati come requisiti utente e requisiti
di sistema. Questa prima classificazione si riferisce non tanto alla qualitá del
requisito quanto al linguaggio usato per specificarlo ed al livello di detta-
glio a cui il requisito fa riferimento.
2.1.1 Requisiti utente

sono formulati in un linguaggio comprensibile agli utenti finali del sistema
e descrivono le caratteristiche del sistema e non come il sistema debba es-
sere progettato e sviluppato per essere conforme a dette caratteristiche.
Di seguito é riportato un esempio della formulazione di un requisito utente
per un servizio di accesso via web ai record medici (ReadyReport) che una
casa di cura intende sviluppare per poi offrirlo ai propri utenti:
WEB 3.1 Selezione degli esami di cui pubblicare il referto
Il sistema deve permettere all’operatore della diagnostica

di selezionare gli esami (di cui si vuole pubblicare
il referto) da una lista ottenuta a partire dalla worklist.
La scelta di questa opzione deve essere preselezionata
in base alla scelta del paziente (memorizzata sul RIS).
8
La formulazione chiara dei requisiti utente e la loro presa di visione
da parte degli utenti finali e del cliente costituisce una ottima base per lo
sviluppo del progetto.
2.1.2 requisiti di sistema

I requisiti di sistema devono descrivere le funzionalitá del sistema in termi-
ni molto vicini al paradigma di sviluppo utilizzato per il progetto. In altri
termini se il progetto segue un approccio procedurale (tipo linguaggio C)
alcuni requisiti di sistema possono essere descritti come funzioni specifi-
candone il prototipo e l’algoritmo di base.
Il requisito utente WEB 3.1 visto sopra da origine a diverse specifiche fun-
zionali. Nel contesto di una architettura basata (anche) sul pattern MVC1
questo requisito comporta la definizione di alcune action di una view, di un
model e delle API per accedere alla work-list,
WEB 3.1
Action: showworklist
Input: mainmenu.jsp
processedby: dicombridge
model: wlEJB
success: worklist.jsp
error: dicomerror.jsp
Action: createexaminationcredential
input: worklist.jsp
processedby: securityman
model: wlEJB
success: worklist.jsp
error: secrity.jsp
2.2 Requisiti funzionali e non funzionali

I requsiti ( sia utente che di sistema) si classificano in funzionali e non fun-
zionali. I requisiti funzionali descrivono cosa il sistema deve offrire e fare.
La loro caratteristica principale é che sono normalmente associati a specifi-
che macro funzionalitá del sistema. Facendo ancora riferimento al progetto
per lo sviluppo del servizio di download dei record medici, vediamo che le
macro funzionalitá del servizio sono:
1 IlModel View Controller é un pattern architetturale per dividere la logica di
presentazione dei dati dal controllo delle azioni dell’utente.
9
1. Opzionalitá sui record da rendere accessibili all’utenza
2. Preparazione di credenziali di accesso per l’utenza finale (generare

coppia username/password o certificato digitale)
3. Accesso dal web ai propri dati medici
Il requisito WEB 3.1 visto in precedenza é riferito alla macro funzionalitá 1

ed é un esempio di requisito funzionale.
Il requisito:
RR 4.2
Il servizio di download deve essere garantito 7/7 giorni,
24/24 ore.
Il servizio deve essere attivo anche durante le operazioni
di manutenzione.
é un esempio di requisito utente non funzionale. Lo stesso requisito espres-

so in termini di sistema diventa:
RR 4.2
Il servizio http realizzato installando una copia di server in cluster.
Sui server saranno virtualizzati gli ambienti web che consisteranno
in un Jboss 4.2/Tomcat/Mysql su piattaforma Linux.
I requsiti non funzionali sono spesso classificati come:
R. di prodotto : specificano alcune qualitá complessive del prodotto, co-

me l’affidabilitá, la velocitá nel processare le transazioni e la portabi-
litá su differenti piattaforme.
R. organizzativi : sono spesso indipendenti dagli obiettivi del progetto e

si riferiscono alle modalitá di sviluppo e documentazione del proget-
to in se. Per esempio un cliente potrebbe richiedere che al progetto
lavorino solo sviluppatori senior.
R.esterni : sono imposti dall’ambiente informatico o reale. Due esempi so-

no il supporto di un protocollo per la comunicazione con un sistema
esterno e la conformitá con le specifiche WAI per l’accessibilitá.
2.3 Il documento dei requisiti

Nel documento dei requisiti vanno vanno riportati i requisiti utente e di
sistema, funzionali e non funzionali del progetto.
La stesura di questo documento é senz’altro pesante e tediosa e spesso il
documento dei requisiti risulta datato giá durante la sua redazione.
10
In alcune metodologie il documento dei requisiti viene visto come una
adempimento formale privo di interesse pratico. Queste metodologie pro-
pongono che i requisiti siano raccolti in corso d’opera e gestiti in maniera
piú o meno diretta dagli sviluppatori.
Indipendentemente dal metodo di formalizzazione di cui si intende fare
uso é una buona norma pensare alla struttura che deve o dovrebbe avere il
documento dei requisiti:
Glossario : elenco e definizione dei termini tecnici presenti nel resto del
documento.
Requisiti utente : l’elenco numerato secondo un dato criterio dei requi-

siti utente. Si possono separare i requisiti funzionali da quelli non
funzionali
Architettura del sistema : descrizione dei principali moduli e delle fun-

zionalitá che vi sono implementate. Descrizione delle interfacce tra i
moduli.
Requisiti di sistema : elenco ordinato dei requisiti funzionali e non fun-

zionali del sistema.
Modelli del sistema : diagrammi delle classi,diagrammi degli oggetti, casi

d’uso, diagrammi di flusso ecc.
Le sezioni architettura del sistema e modelli del sistema possono precedere

le sezioni sui requisiti.
2.4 Scrivere codice o documenti?

Scrivere documentazione costa energie e concentrazione, la domanda se ne
valga la pena sembra scontata.
Sicuramente é poco produttivo scrivere pagine di requisiti se poi queste
non vengono lette dal cliente ne dagli sviluppatori.
Ad uno sviluppatore creativo puó dar noia ricevere un documento con le
specifiche di sistema mentre potrebbe gradire le specifiche utente.
É molto difficile trarre delle considerazioni che abbiano una validitá gene-
rale.
Sicuramente una cosa che vale la pena chiarirsi é che un processi di svilup-
po software ha scarse possibilitá di successo se é lasciato completamente a
se steso.
11
2.5 Raccolta e formalizzazione dei requisiti
La stesura del piano del progetto é il primo dei passi formali nella gestione
di un processo di sviluppo. Il processo continua con una prima raccol-
ta informale dei requisiti allo scopo di definire la fattibilitá del progetto.
L’analisi della fattibilitá deve tener conto sia di eventuali impedimenti tec-
nologici che della reale necessitá dello sviluppo del progetto. Va da se che
un progetto di cui nessuno sente realmente l’esigenza é con ogni probabi-
litá destinato a fallire, purché il progetto una volta realizzato non determini
nuove esigenze a cui esso puó rispondere.
L’analisi della fattibilitá produce il documento di fattibilitá e a condizio-
ne che esso sia positivo si procede con l’analisi e la raccolta dei requisiti.
Questi dopo essere stati raccolti vengono formalizzati nel documento dei
requisiti e quindi convalidati. Il processo puó essere schematizzato come
in figura 1. La raccolta dei requisiti é uno dei momenti fondamentali del
Presentazione
del progetto
Studio di
fattibilità
Raccolta dei
requisiti
Formalizzazione
dei requisiti
Convalida
Piano del Documento di Documento dei

progetto fattibilità requsiti
Figura 1: Ingegneria dei requisiti
processi di sviluppo.2 In questa fase l’analista si incontra con gli stackehol-

2 Inrealtá per molti progetti ed in special modo per i progetti software che riguardano
l’automazione di processi aziendali, la raccolta e l’analisi dei requisiti continuano per tutto
12
der3 e cerca di trarre i requisiti utente e di sistema per mezzo di interviste.
L’impostazione delle interviste puó essere piú o meno formale ció che con-
ta é che l’analista riesca a focalizzare le esigenze dei propri interlocutori, le
loro aspettative e gli aspetti che maggiormente li preoccupano.
Non esiste un metodo universalmente valido per condurre le interviste. Di-
versamente da un magistrato infatti un analista non puó disporre dei propri
interlocutori come meglio crede ma deve (per amore o per forza) rispettare
la loro sensibilitá, disponibilitá al dialogo e capacitá espressiva.
La pratica dell’ingegneria del software ha portato nel tempo al consolidarsi
di metodologie per assistere tutte le fasi del processo. Per la raccolta dei
requisiti si fa ora largo uso di diagrammi che hanno lo scopo di contestua-
lizzare i requisiti in specifici scenari di utilizzo e di semplificare il corso
delle interviste e la loro successiva analisi. Questi diagrammi sono detti
diagrammi dei casi d’uso o use cases e fanno parte del linguaggio di modella-
zione UML. I casi d’uso di riferiscono ad uno scenario (a volte identificano
uno scenario) e descrivono graficamente l’interazione tra gli utenti ed il
sistema. L’utilitá di questi diagrammi é che sono molto intuitivi ed espli-
cativi e consentono di analizzare il sistema dal punto di vista dell’utente in
maniera grafica, quindi immediata e leggera.
2.5.1 Progetto ReadyReport

Il progetto ReadyReport coinvolge l’amministratore delegato della struttu-
ra sanitaria, la segreteria della radiologia, i medici radiologi, i tecnici della
diagnostica, il responsabile dei sistemi informativi, i fornitori del PACS e
del RIS e gli utenti del servizio di radiologia. Questi sono gli stackeholder
del sistema. In linea di principio ognuno di essi andrebbe intervistato per
raccogliere la sua versione dei requisiti. In realtá essi vengono coinvolti nel
processo di raccolta in maniera diversa. Il primo passo dopo l’identifica-
zione degli attori é di provare a tracciare i principali scenari applicativi e
quindi definire i casi d’uso del sistema con gli attori individuati.
Alcuni degli stackeholder si riveleranno veri attori del sistema, mentre altri
non parteciperanno ad alcuno scenario.
SCENARIO: Il paziente viene sottoposto ad esame radiologico

NOME: Esame Radiologico
Il paziente si reca presso la struttura sanitaria. Passa

in accettazione e paga il ticket. Attende il proprio turno,
il ciclo di vita del software sviluppato. Questa attivitá quindi non solo non é limitata alla
fase iniziale della progettazione ma spesso continua anche nella fase di manutenzione.
3 Questo termine indica le persone che saranno influenzate in maniera piú o meno diretta
del sistema in via di sviluppo
13
si presenta in diagnostica e si posiziona per l’esame.
Il tecnico di diagnostica riceve i dati del paziente
da RIS. Esegue l’esame. Il sistema RR mostra il
record del paziente con il relativo numero della
prestazione.
Il tecnico seleziona il record per la pubblicazione
del referto sul web. Il tecnico stampa la username
e la password per il paziente e le consegna.
ReadyReport
Mostra lista delle

prestazioni
Predispone l'esame
Tecnico per l'accesso dal
Diagnostica web
Figura 2: Casi d’uso per lo scenario Esame radiologico
In questo scenario si identifica un unico attore che é il tecnico della diagno-

stica. Il paziente entra nello scenario ma non partecipa ad alcune attivitá
con il sistema RR. Anche il sistema di accettazione e di pagamento del tic-
ket non interagiscono con il sistema. I casi d’uso per questo scenario sono
riportati in figura 2. La rappresentazione grafica aiuta sia il dialogo con gli
attori che il successivo momento di analisi. Se un analista deve passare le
consegne ad un collega i casi d’uso chiariranno subito quali sono gli atto-
ri da intervistare ed in quali contesti. Allo stesso modo mostrando i casi
d’uso agli attori questi potranno facilmente riconoscere errori ed omissis.
3 Le basi della progettazione

3.1 Dai requisiti di sistema al progetto
La progettazione di un software e l’analisi dei requisiti di sistema sono so-
no due fasi interdipendenti che evolvono insieme in maniera ciclica rei-
terando l’una nell’altra. La spiegazione di questa dipendenza discende
direttamente dalla essenza stessa del requisito di sistema:
14
Tecnico prestazioni.jsp Controller EJB DB RIS
Diagnostica
lista prestazioni
lista prestazioni
lista prestazioni
SQL Query
Resultset
Figura 3: Diagramma di sequenza per lo scenario Esame radiologico
15
Contesto : i requisiti debbono riferirsi al sistema da sviluppare e non a
quanto gi presente. Bisogna pertanto evidenziare i confini tra il siste-
ma e l’ambiente.
Comportamento : i requisiti sono riferiti al comportamento del sistema

cioé al processo delle informazioni e/o alla modifica dello stato del
sistema in base agli eventi.
Architettura : giá nella fase di analisi il sistema viene analizzato in sottosi-

stemi. Questo porta alla definizione dei requisiti di sottositema e quindi
ad una prima scelta di architettura.
Classi : i requisiti sono spesso riferiti all’interazione di persone e siste-

mi con il sistema in sviluppo. Tali entitá debbono essere analizzate e
classificate.
Informazioni : i requisiti che esprimono le associazioni tra le entitá porta-

no alla definizione semantica dei dati.
Risulta che l’analisi dei requisiti di sistema passa per lo studio del contesto,
comportamento, architettura, classi e informazioni del sistema stesso e
quindi costituisce l’incipit (il principio)dell’analisi progettuale.
Lo studio dei punti visti sopra risulta notevolmente piú chiaro se condotto
per mezzo di diagrammi. L’uso dei diagrammi contribuisce alla definizione
dei modelli del sistema.
Nel paragrafo successivo verranno presentati alcuni diagrammi relativi al
progetto ReadyReport.
3.2 Modelli del progetto ReadyReport

Il progetto ReadyReport ha l’obiettivo di introdurre un servizio per il do-
wnload dei referti radiologici all’interno di una struttura sanitaria. É ragio-
nevole supporre che questo sistema debba essere installato in un ambiente
in cui sia giá presente un sistema informativo. I sistemi informativi dedicati
alle esigenze dei reparti di radiologia sono detti RIS (Radiological Informa-
tion System), piú in generale i sistemi informativi dedicati alle strutture
sanitarie sono detti HIS (Health Information System) o in italiano SIO (Si-
stema Informativo Ospedaliero).
Il primo passo per la definizione dei requisiti di sistema di ReadyReport
é la definizione dei confini stessi del sistema. Una volta tracciati i con-
fini risulterá piú semplice identificare le interfacce ed i protocolli per la
comunicazione tra ReadyReport ed il resto del sistema. Nella pratica pri-
ma di identificare il contesto per il progetto in sviluppo risulta conveniente
produrre un diagramma del comportamento del sistema esistente.
16
3.2.1 Flusso dei dati nel sistema informativo ospedaliero
Paziente
Dati Morfologia
Acquisizione
Accettazione Refertazione
immagine
Prenotazione prestazione
Immagine Immagine
Referto
PACS
RIS-DB
Figura 4: Diagramma di sequenza per lo scenario Flusso dei dati per l’esecuzione
di una prestazione radiologica.
Nelle figure 4, 5, 6 é rappresentato il percorso dei dati per una presta-

zione radiologica, in particolare si evidenziano i processi e i DataBase di
competenza del sistema RIS e PACS. La definizione del flusso dei dati nel
sistema preesistente é importante per definire il contesto e l’architettura del
ReadyReport.
3.2.2 Il contesto di ReadyReport

L’analisi condotta per la definizione del Data-Flow del processo diagnosti-
co ha evidenziato i confini dei sistemi RIS e PACS. Segue immediatamente
17
Paziente
Dati
Morfologia
Referto Refertazione
Accettazione
Acquisizione
immagine
RIS
Immagine
Immagine
RIS-DB
PACS
di una prestazione radiologica. In evidenza il sottositema RIS.
18
Paziente
Dati Morfologia
Refertazione
Acquisizione
Accettazione
immagine
PACSImmagine
Immagine
Referto
PACS
RIS-DB
di una prestazione radiologica. In evidenza il sottosistema PACS.
19
che il sistema RR dovrá interagire con questi due sottosistemi e, come de-
dotto dall’oggetto stesso del progetto, con il WEB. Il diagramma del conte-
sto é riportato in figura 7.
Il contesto in cui si troverá ad operare un sistema, nel caso in questione
RR, non é sempre univocamente determinato dalle condizioni ambientali ma
puó essere modificato per adattarlo alle esigenze o ai vincoli di progetto.
Si supponga, a titolo di esempio, che il RIS presente presso una struttu-
ra sanitaria non presenti una interfaccia di comunicazione DICOM4 per lo
scambio dei dati con altre applicazioni. La comunicazione e lo scambio di
dati con questo sottosistema deve allora seguire una strada non standard e
potrebbe rivelarsi necessario interpellare il fornitore del sistema per richie-
dere le specifiche per l’integrazione.
Questo scenario complica il progetto iniziale, infatti viene inserito tra le
parti un nuovo elemento (il fornitore del RIS) con le proprie esigenze, obiet-
tivi, scadenze, disponibilitá e risorse. Il committente potrebbe temere que-
sto scenario e optare per una soluzione in cui le funzioni svolte dal RIS
siano ricoperte dal progetto RR.
RIS
READYREPORT WEB
PACS
Figura 7: Diagramma di sequenza per lo scenario Diagramma del contesto per il

sistema RR.
4 Digital Imaging and Communication in Medicine, specifica per lo scambio di dati e

servizi tra gli applicativi medici.
20
3.2.3 Il flusso dei dati di ReadyReport
L’analisi dei requisiti di sistema per RR evidenzia che le funziono principali
che devono essere offerte dal sistema sono:
Produzione delle credenziali di accesso : dopo l’esecuzione di una pre-

stazione devono essere preparate le credenziali di accesso dal web al
referto relativo alla prestazione stessa.
Esportazione dei referti sul web : i referti pronti debbono essere pubbli-
cati sul web.
Autenticazione e download referti .
L’analisi funzionale di questi requisiti sistema é semplificata da un dia-

gramma del flusso dei dati (fig 8). La definizione di questo diagramma
é un primo passo verso la definizione del progetto del sistema in cui giá si
delinea un database dedicato (RR-DB).
3.2.4 Architettura
La descrizione dell’architettura di un sistema consiste nella scomposizione
del sistema in sottosistemi e nella loro identificazione con eventuali compo-
nenti fisici (Database, librerie, eseguibili, file di risorse). Come si é visto nei
paragrafi precedenti la definizione dei requisiti di sistema é semplificata
dalla definizione di sottosistemi. In questo modo la definizione dei requi-
siti porta alla definizione dell’architettura e viceversa. In fig 9 é riportata
l’architettura del sistema RR.
I processi (funzioni sui dati) visti nel diagramma del flusso dei dati vengo-
no riferiti ai sottosistemi identificati in questo diagramma.
3.2.5 Classificazione
I digrammi delle classi e degli oggetti sono tra i piú usati nelle metodologie
basate sul linguaggio UML. Questi diagrammi possono venire usati in tutte
le fasi del processo.
Nella fase di raccolta e formalizzazione dei requisiti questi modelli sono
spesso impiegati per fornire una rappresentazione razionale delle entitá
coinvolte nel progetto e solo successivamente, cioé nella fase di progetta-
zione, vengono impiegati per descrivere le classi (come costrutti di codice)
e le relazioni tra esse che saranno sviluppate.
In questo caso si impiegano questi diagrammi per dare una rappresenta-
zione della struttura (fig 11) e dell’organico (fig 10) di un servizio sanitario.
21
Tecnico
diagnostica
Export referti Criptazione dei referti
Generazione
user_name, password,
encription e decription
key
Referto
Referto Credenziali
Prestazione
RIS-DB
RR-DB
Download
Utente del
servizio
Figura 8: Diagramma del flusso dei dati
22
Gestione Prestazioni/credenziali
Gestione Referti
DB-RR
Accesso agli utenti
Figura 9: Architettura del sistema RR.
Dipendente
Nome
Cognome
IdDipendente
Tecnico Diagnostica Medico

IDSala Reparto
referta()
eseguiPrestazione()
Radiologo
refertaImmagine()
Figura 10: Classificazione dell’organico.
23
Figura 11: Descrizione della struttura sanitaria.
3.2.6 Modello dei dati

Nella fase di analisi dei requisiti di sistema vengono normalmente anche
analizzati i Database esistenti e delineate nuove entitá che entrano in gioco
nel progetto. La ricerca delle nuove entitá e delle relazioni tra queste porta
alla definizione dei diagrammi concettuali e logici dei dati. Questi possono
venire rappresentati in termini di stereotopi UML. In figura 12 sono riportati
gli schemi logici dei Database del RIS e di RR.
3.3 La progettazione
Un sistema informatico é sempre caratterizzato da una sua struttura statica
ed una dinamica. La struttura statica é descrivibile in termini di compo-
nenti hardware e di componenti software che sono disposti (schierati) nei
componenti hardware, mentre la struttura dinamica é l’organizzazione del
sistema in termini di processi e scambio di dati durante l’esecuzione del
programma.
La progettazione di un sistema informatico (software applicativo o sistema
informativo) consiste nella definizione (chiara e precisa) della struttura sta-
tica e dinamica del sistema.
Il concetto di struttura di un sistema rimane spesso oscuro e capita di im-
piegarlo in modo improprio o comunque ambiguo. Il termine struttura
deriva direttamente dal concetto di costruzione, cos quando ci si riferisce
alla struttura statica di un sistema si devono intendere i componenti con cui
24
Figura 12: Schema logico dei Database.
25
questo é stato costruito e le relazioni strutturali tra di essi, in altri termini
progettare la struttura (statica) di un sistema significa pensare al sistema in
termini di componenti che appunto lo compongono.
Spesso i componenti di un sistema hanno una propria struttura, si parla in
questo caso di sotto strutture.
La struttura dinamica deve considerare i processi attivi durante l’esecuzio-
ne del sistema e la comunicazione tra questi. É molto importante tenere in
considerazione che possono esistere delle differenze importanti tra la strut-
tura dinamica e quella statica. Alcuni aspetti della dinamica di un sistema
sono giá determinati dalla sua struttura (statica) altri invece sono defini-
ti solo a livello dinamico. Per fare un esempio se si considera un sistema
web-based a livello statico possiamo indicare la macro struttura come un
web-server ed un web-browser. É chiaro che durante l’esecuzione del si-
stema esisterá un istanza del web-server ed una del browser ed un traffico
di pacchetti TCP tra i due che si scambieranno dei messaggi e dei dati se-
condo il protocollo HTTP.
In una situazione reale peró piú browser potrebbero connettersi allo stesso
server e questi dovrá implementare una strategia di parallelismo per gestire
le connessioni.
Un sistema informatico puó essere sviluppato senza nessun progetto ma
esso avrá sempre una propria struttura statica e dinamica, con questo si
vuol sottolineare che l’attivitá della progettazione ha lo scopo di anticipa-
re, prevedere, guidare, proiettare, imporre o suggerire la struttura di un
sistema prima che questo venga costruito.
3.3.1 L’architettura edilizia, un paragone

Si supponga che un costruttore disponendo di un certo capitale di investi-
mento decida di realizzare un agglomerato ad uso residenziale. egli inten-
de costruire 20 villette bi-famigliari, 10 palazzine da 12 interni e una schiera
da villette a due piani mono-famigliari. Dopo alcune considerazioni risulta
che si dovrá realizzare un complesso di strade per l’accesso alle abitazioni,
le piste ciclabili ed un parco giochi per i bambini. La realizzazione di queste
specifiche prive di una previa progettazione potrebbe essere assolutamen-
te inutilizzabile, le case potrebbero essere costruite lontano dalle strade e
la pista ciclabile potrebbe essere un tratto asfaltato non collegato alle vie di
comunicazione.
Per evitare questi scenari, nelle costruzioni civili si é soliti consultare degli
architetti per definire un’architettura. Questi sanno raffigurare il lo scena-
rio finale per mezzo di schemi progettuali che permettono di verificare la
funzionalitá dei progetti prima di realizzarli e di fornire gli schemi per la
messa in opera e la costruzione.
26
3.3.2 Vantaggi e svantaggi della progettazione
Si puó decidere di progettare perché si ama farlo o perché lo si ritiene ne-
cessario. Nella prima ipotesi é inutile distinguere vantaggi e svantaggi, in
quanto si sa che l’amore é cieco. Nella seconda ipotesi, visto che la pro-
gettazione é un attivitá dispendiosa, frustrante e mal retribuita é giusto
analizzare in maniera profonda l’effettiva necessitá di farlo e quali sono i
vantaggi che ci si aspetta.
Una regola semplice é la seguente: progettare bene aiuta molto, progettare male
danneggia moltissimo, non progettare per niente é assurdo.
3.4 Componenti, connettori e dati

Il termine architettura deriva dal greco. L’etimologia non é chiarissima ma
sostanzialmente é l’unione delle parole αρχι e τeχνη cioé inizio o prima
e arte, intesa anche come costruzione, il senso piú accreditato é quello di
ció che viene prima della costruzione, cioé la proiezione dell’opera avanti nel
tempo o meglio il progetto.
Pensare l’architettura significa allora costruire prima con la mente o con dei
modelli. L’architetto sa mettere in relazione dei modelli astratti di un si-
stema con il sistema reale e ció gli permette di progettare la soluzione del
sistema.
Gli elementi di base usati nell’architettura del software sono:
Componente : é un unitá software astratta o reale che puó avere uno stato
interno e agisce sui dati trasformandoli.
Connettore : é un meccanismo astratto per la comunicazione tra i compo-

nenti.
Dato : é un elemento di informazione trasferito tra componenti per mezzo

di un connettore.
3.4.1 I componenti
Un tempo la categoria di componente era limitata a unitá fisiche software
cioé sostanzialmente a oggetti gestibili dal filesystem. Il concetto di compo-
nente é stato peró esteso nel senso visto sopra.
Se si vuole analizzare una applicazione complessa scritta in linguaggio C,
un componente puó essere un modulo che espone un interfaccia, cioé una
collezione di funzioni e proprietá, o direttamente una funzione.
Il significato che attribuiamo alla categoria componente dipende fortemen-
te dal contesto e dal grado di astrazione dell’analisi.
Se si sta analizzando un complesso sistema distribuito in cui prendono par-
te anche alcuni eseguibili C, questi saranno visti come componenti mentre
la loro scomposizione funzionale rimarrá nascosta e non parteciperá alla
27
definizione dell’architettura, in questa prospettiva una funzione C non é
un componente.
3.4.2 I connettori
I connettori sono astrazioni dei metodi impiegati per scambiare i dati tra i
componenti:
Chiamata a funzione : é una tecnica che usa il PC per guidare il flusso

delle istruzioni su un microprocessore e una struttura dati (lo STACK
o alcuni registri) per scambiare i dati tra due componenti. Il tipo di
messaggio é normalmente asimmetrico.
Chiamata a procedura remota (RPC) : é un servizio (middleware) che con-

sente lo scambio di dati tra componenti distribuiti su una rete in
maniera analoga alla chiamata a funzione.
Eventi : gli eventi sono un esempio di comunicazione asicrona.
Flussi (stream) : sono impiegati per il trasferimento di grosse moli di dati.

Le pipe UNIX e le socket TCP/UDP sono esempi di connettori a flusso.
Compilatore
Analizzatore Generatore di
Ottimizzatore
semantico codice
Analizzatore
sintattico
Analizzatore
lessicale
Repository
Albero Tabella dei

sintattico simboli
Editor
Editor sintattico Debugger
Figura 13: Organizzazione a repository di un ambiente di sviluppo.
28
Software
Server
Kernel
Figura 14: Semplificazione di un architettura a microkernel.
3.5 Organizzazione, scomposizione e controllo

Come si é giá precisato, la progettazione dell’architettura di un sistema con-
siste nel descrivere detto sistema in termini di sottosistemi e delle relazioni
tra questi. Dal punto di vista ingegneristico é molto importante poter iden-
tificare l’architettura di un sistema a partire da uno stile architetturale noto.
5 Lo stile architetturale é definito a partire dall’organizzazione, scomposizio-
ne modulare e dal modo di controllo del sistema.
3.5.1 Organizzazione
Si puó parlare di stile di organizzazione di un software quando questo rag-
giunge una certa complessitá tale da poter considerare il sistema come com-
posto da diversi sottosistemi.
L’organizzazione allora si riferisce alla scelta dei componenti e dei connet-
tori per la comunicazione tra i sottosistemi.
Organizzazione a Repository (Database condiviso) : il sistema é compo-

sto da diversi moduli che lavorano su un Database condiviso. la co-
municazione tra i componenti é mediata dal DB e i componenti risul-
tano cosı́ disaccoppiati. Ovviamente i componenti dovranno comu-
5 Questa esigenza risulta chiara se si pensa che l’ingegnere ha come obiettivo non la crea-
tivitá ma il produrre un risultato solido ed affidabile. L’innovazione é ben accetta quando

porta a risultati migliori o a soluzioni non percorribili con le architetture note.
29
nicare con il componente Database, ma a questo livello questa comu-
nicazione é vista come un dettaglio. Un esempio di organizzazione a
repositry si ha negli ambenti di compilazione (vedi figura 13).
Modello client-server : bisogna anzi tutto notare che per sistemi comples-
si si ha spesso la presenza di diversi stili di organizzazione che colla-
borano alla definizione del sistema, cosı́ un sistema puó essere sia a
repositiry che client-server.
Nell’organizzazione client-server alcuni componenti detti server espon-
gono dei servizi che vengono consumati dai client.
I componenti si connettono per mezzo di RPC o di stream.
L’architettura Client-server puó essere stratificata in piú livelli e ora-
mi si parla di architetture distribuite.
Modello stratificato : questo stile di organizzazione si pone come obiet-

tivo di nascondere i componenti in strati isolati e di definire dei li-
velli gerarchici per la comunicazione tra di essi. É una conseguen-
za diretta della programmazione bottom-top. Un esempio di software
sviluppato secondo questo stile sono i sistemi operativi a microkernel
3.5.2 Scomposizione in moduli

Normalmente il progettista del software prende visione dello schema ar-
chitetturale che é stato prodotto (in molti casi da lui stesso) nella fase di
analisi dei requisiti e a partire da quello deriva una prima architettura del
progetto individuando lo stile di organizzazione adatto ad ogni macro com-
ponente.
Il modello che deriva da questa fase differisce dal primo in quanto il pro-
gettista stá giá considerando la scomposizione in componenti dal punto di
vista tecnologico in termini di componenti e connettori e non piú solo come
macro contenitori di funzionalitá.
Al termine di questa fase i componenti individuati vengono scomposti in
ulteriori moduli. La scomposizione in moduli, o modularizzazione ha lo sco-
po di meglio organizzare i requisiti di sistema (specie non funzionali) e di
fornire agli sviluppatori un progetto piú semplice da seguire e da suddivi-
dere tra il team di sviluppo.
In base al paradigma di sviluppo che si é scelto per il progetto la scomposi-
zione modulare consisterá in una scomposizione orientata alle classi e alla
tipizzazione o in una scomposizione orientata alle funzioni.
3.5.3 Controllo
Un sistema software é composto da un insieme di componenti. Affiché si
possa parlare di sistema é necessario che tali componenti collaborino per
30
ottenere un certo comportamento o risultato. La logica con cui questi colla-
borano é definita in maniera esplicita dal sistema di controllo che regola
l’esecuzione dei componenti in base ad uno stato del sistema o ad eventi
che si presentano.
Se tutta la logica di controllo viene accentrata all’interno di un singolo com-
ponente si parla di controllo centralizzato, quando invece il controllo é sud-
diviso tra i vari componenti il controllo e decentralizzato. Un esempio di
controllo centralizzato si ha nei programmi C dove il controllo principale
del sistema risiede nella funzione main che chiama le altre funzioni per ese-
guire dei compiti specifici. I sistemi guidati da eventi come i sistemi basati
su un interfaccia grafica sono invece normalmente sistemi decentralizzati.
I sistemi software fanno comunque spesso uso simultaneamente di entram-
be queste tecniche di controllo e la loro categorizzazione é utile per saper
riconoscere lo stile di controllo di un determinato sottositema.
3.6 La documentazione del progetto

Progettare il software a due scopi:
• ottenere un modello del sistema
• ottenere un progetto del sistema
Il modello del sistema permette a chi si occupa dell’architettura del sistema

di verificarne la conformitá ai requisiti (funzionali e non funzionali) prima
che il sistema sia sviluppato6 , il progetto invece serve agli sviluppatori co-
me traccia e guida nell’attivitá di sviluppo.
La linea guida per produrre un modello ed un progetto puó essere quella no-
to come le 4 viste + 1. Questo metodo consiste nel produrre dei diagrammi
del sistema che descrivano:
Vista logica : diagrammi delle classi e dei componenti che costituiscono il

sistema
Vista del processo : diagrammi di sequenza, collaborazione, attivitá, sta-

to e temporizzazione che descrivono il comportamento del sistema in
termini di istanze degli oggetti e flusso dei dati durante l’esecuzione.
Vista development : i package in cui sono raggruppate le classi del pro-

getto.
Vista di schieramento : mostra i nodi principali del sistema e la distribu-

zione dei componenti sui nodi.
6Imodelli di sistema aiutano queste verifiche ma alla pratica in assenza di un qualche
prototipo é ben difficile eseguire queste valutazioni.
31
Il linguaggio di elezione per la produzione di questi diagrammi é l’UML.
Normalmente il processo di progettazione prende il la dal modello architet-
turale che viene definito durante l’analisi dei requisiti (fig. 9). A partire da
questo modello si identificano i principali componenti del sistema. Il pro-
gettista analizza i moduli individuati nella fase dei requisiti e comincia ad
ipotizzare uno stile organizzativo, di controllo e di modularizzazione per
il sistema. Spesso la suddivisione in macro componenti individuate nella
fase di ingegneria dei requisiti non é rispettata nella fase di progettazione.
Nella fase dei requisiti infatti la scomposizione del sistema in sottosistemi
riflette una esigenza di chiarezza logica e funzionale mentre nella fase di
progettazione si devono dividere o accorpare i componenti tenendo conto
degli obiettivi di performance, sicurezza, affidabilitá, scalabilitá e deploy-
ment.
Il primo diagramma che viene prodotto é normalmente un diagramma che
descriva i componenti principali quindi le classi che costituiscono questi
componenti, quindi é normale partire con una vista logica. Quando i com-
ponenti e le classi sono stati individuati si cerca di descriverne il loro com-
portamento in fase di esecuzione del sistema e si passa quindi alla vista del
processo. L’organizzazione delle classi in package ha lo scopo di rendere
piú semplice l’attivitá di sviluppo e di riutilizzo del codice, questa vista
viene prodotto di norma quando sono giá state individuate le classi del
sistema, ma non sarebbe sbagliato comunque anche far precedere questa
vista a quella logica.
La vista di schieramento (deployment) mostra come i vari componenti sa-
ranno distribuiti sui nodi del sistema. Questa vista é fondamentale per
rendersi conto delle caratteristiche di scalabilitá, performance e sicurezza
del sistema.
La quinta vista é normalmente meno formale. Il suo scopo é di collegare le
altre viste in un ottica di casi d’uso.
3.7 Le viste di ReadyReport

Analizzando lo schema architetturale del sistema ReadyReport e collegan-
dolo all’analisi dei requisiti risulta che i tre moduli principali dovranno
essere organizzati come client-server. La gestione dei pazienti, cioé la pro-
duzione delle credenziali per l’accesso dal web e la produzione delle imma-
gini della prestazione devono essere possibili da ogni diagnostica. Il modo
piú semplice per ottenere questo requisito non funzionale é che questo mo-
dulo sia organizzato come un client server. La scelta ricade sullo sviluppo
di una web application. Lo stesso ragionamento si applica alla gestione dei
referti. Dal momento che la politica di gestione degli accessi per i due mo-
duli sará sostanzialmente la stessa si decide di accorpare i due componenti
in un’ unica web application.
La vista logica dei componenti per il progetto ReadyReport é riportata in
32
figura 15.
Dalla figura 15 si deduce che il la web-application ReadyReport comunica
con la Diagnostica per mezzo di un’architettura a repository. Il dettaglio
del componente MainController é illustrato in figura 18. Il core di questo
componente é una servlet Java a cui vengono dirette tutte le richieste http
provenienti dal browser. Le pagine HTML caricate sul browser sono gene-
rate dinamicamente dalle pagine jsp. L’insieme di queste pagine costituisce
i due componenti CredenzialiUtente ed ExportReferti. La comunicazione
tra le pagine jsp e la servelt avviene secondo una logica MVC. Questo é
documentato nel progetto tramite i contratti informali GestioneCredenziali
e GestioneReferti. Questi sono informali in quanto non sono verificabili a
compile time e si riferiscono al set di valori possibili che possono essere pas-
sati dalle pagine HTML alla servelt per il parametro op che stabilisce quale
azione debba essere intrapresa dalla servlet.
Il diagramma di deployment 19 infine evidenzia che le due web-application
saranno schierate su due server diversi (uno interno alla LAN e l’altro sulla
DMZ requisito non funzionale) per questioni di sicurezza.
Figura 15: Vista logica del progetto RR
33
Figura 16: Vista logica del progetto RR, diagramma delle classi.
34
Figura 17: Vista di development (packeging).
35
Figura 18: Vista del processo, dettaglio di una sequenza.
36
Figura 19: Vista di schieramento.
37
4 Sviluppo
Lo sviluppo del software consiste nella produzione di codice sorgente e nel-
la successiva compilazione e debug. Lo sviluppo del codice segue sempre la
fase di progettazione ma spesso lo sviluppo del codice é anche l’incipit per
una nuova fase di ingegneria dei requisiti e di progettazione.
La fase dello sviluppo comincia con la generazione automatica del codice
da parte degli strumenti CASE (Computer Aided Software Engineering) e
con il completamento del codice stesso da parte degli sviluppatori che ba-
sandosi sul progetto prodotto nella fase precedente implementano le fun-
zionalitá ed i requisiti di sistema basandosi sulle specifiche raccolte e for-
malizzare nella fase di ingegneria dei requisiti.
Ipotizzando che nella fase dei requisiti questi siano stati analizzati con com-
pletezza e correttamente, che nella fase di progettazione si sia delineato
correttamente il modello del sistema ed il progetto, segue per logica che la
fase di sviluppo, se condotta correttamente, debba portare ad una fase di
verifica e quindi completamento del progetto.
Purtroppo questo sillogismo é verificato in una bassa percentuale di casi.
In molti casi si ha che la fase dei requisiti é condotta solo approssimativa-
mente e quella di progettazione manca completamente. Questi casi non
sono neanche presi in considerazione in questo ragionamento. Un soft-
ware mal progettato se funziona é solo per pura fortuna e la fortuna nella
scienza non esiste. Il nostro interesse invece é per quelle situazioni in cui
le fasi dei requisiti e della progettazione sono condotte correttamente ma
dopo lo sviluppo al momento della messa in produzione del software ri-
sulta che questo non soddisfa i requisiti attesi. La domanda a cui si cerca di
rispondere é cosa accada in questi casi.
4.1 Requisiti statici

Alcuni progetti software nascono per sviluppare dei sistemi o prodotti di
cui al momento della progettazione sono ben note sia lo scopo che la mo-
dalitá di funzionamento.
Si consideri per esempio lo sviluppo di un Codec, di un Driver o anche di
una rete neurale per il Pattern Recogniction. Questi software possono avere
un grado alto di complessitá ma hanno una caratteristica importante, sono
cioé delle specie di scatole nere che espletano una ben determinata funzio-
ne all’interno di un piú generico processo.
Quando questi software vengono richiesti il loro ruolo é giá ben determina-
to ed altri componenti dipendono dalla risposta funzionale di questi. Con
queste premesse é normale che chi richiede il software sia ben concentra-
to nel comunicare con gli analisti ed abbia la percezione della criticitá dei
requisiti. Il committente avrá premura di verificare di essere capito corret-
tamente e di controllare che tutte le parti del sistema comunichino tra loro
38
correttamente senza voli di fantasia.
I progetti condotti in queste condizioni possono seguire la sequenza Analisi
→ Progettazione → Sviluppo → Verifica con successo.
4.2 Requisiti dinamici

Alcuni progetti software nascono in capo ai committenti per rendere auto-
matici dei processi controllati da operatori umani.
Spesso le fasi precise di questi processi non rispondono a dei principi rigo-
rosi ma sono solo scelte di compromesso dovute anche alle varie limitazioni
del controllo umano sul processo.
Il processo di automazione procede spesso (e questo é naturale) attraver-
so la automazione delle singole fasi. L’informatizzazione delle singole fasi
puó portare peró a a dover richiedere nuovi vincoli o ad offrire nuove pos-
sibilitá, capita allora che l’informatizzazione modifichi i requisiti del siste-
ma.
Questa possibilitá non é affatto un caso limite ma anzi succede con una
frequenza significativa. Se l’informatizzazione di un processo modifica il
processo stesso é chiaro che i requisiti evolvono con il progetto stesso e
questo porta ad una seria difficoltá quando si cerchi di separare rigorosa-
mente la fase dei requisiti da quelle della progettazione e dello sviluppo.
Il processo di sviluppo di un tale tipo di sistema é sostanzialmente un si-
stema in retroazione.
Nella pratica reale dell’ingegneria del software il tipo si retroazione dei si-
stemi si risolve sempre in retroazione negativa e questo significa che dopo
un certo numero di volte che i requisiti vengono raccolti, che si rivedono
i progetti e si torna allo sviluppo il sistema tende a diventare stabile e si
converge alla soluzione voluta.
Se da un lato ripetere l’intero processo di sviluppo piú volte é poco efficien-
te, dall’altro questo sembra essere al momento l’unico approccio (ma ben
vengano altri!) funzionante. Per evitare peró di rendere eccessivamente co-
stosi (e noiosi) certi progetti si puó ricorrere alla tecnica della progettazione
per prototipi.
4.2.1 progettazione per prototipi

Si tratta di rivedere il percorso visto fin’ora in modo da renderlo piú legge-
ro e flessibile permettendo cosı́ di poterlo ripetere piú volte senza sprechi
eccessivi di tempo e denaro. Questo si puó ottenere mirando alla progetta-
zione e allo sviluppo di un prototipo anziché del prodotto finale.
Lo scopo del prototipo é quello di innescare il meccanismo di retroazione
del sistema in modo da poterne seguire l’evoluzione dei requisiti.
Il vantaggio del prototipo é che questo viene sviluppato in tempi rapidi ri-
nunciando solitamente ad uno sviluppo curato e sicuro scendendo quindi
39
a compromessi sulla qualitá del software.
Affinché questo approccio sia conveniente é necessario alleggerire anche la
fase della progettazione. Nella pratica si é dimostrato che un buon approc-
cio alla protitipizzazione sia ha cercando di unificare la fase di progetta-
zione e di sviluppo. Questo non significa non progettare, anzi progettare
molto ma realizzare subito quanto progettato. Seguendo lo sviluppo per
prototipi la produzione delle quattro viste ad ogni ciclo diventa eccessivo.
Al termine dei cicli di retroazione, cioé quando i requisiti si stabilizzano di-
venta fondamentale riscrivere il codice secondo le regole della buona qua-
litá. Per evitare di dover riscrivere interamente il codice al termine dei cicli
di sviluppo si puó ricorrere alla tecnica di refactoring che consiste nel dedi-
care con costanza qualche ora alla settimana al rivedere il codice scritto in
precedenza per renderlo adeguato alla produzione.
4.2.2 Esempio pratico

Ilprogetto ReadyReport (RR) nasce per offrire il servizio di ritiro dei refer-
ti radiologici via web. Prima dell’introduzione del RR i referti venivano
archiviati in formato testuale in un DB relazionale, poi stampati e firmati
manualmente dal medico refertante.
Gli analisti ed i progettisti di RR dopo aver analizzato il processo di refer-
tazione esistente lo replicano sul RR e definiscono la procedura di export
dei referti basandosi sul referto testuale presente sul DB.
Questo approccio peró si rivela inadatto giá alle prime verifiche sul campo
in quanto il referto scaricato dal web non puó essere firmato manualmente
dal medico.
Si decide allora di modificare la procedura di refertazione esistente impo-
nendo ai medici di firmare il referto con la propria SmartCard. Il referto
non viene piú archiviato nel DB ma direttamente come file PDF.
La procedura di export deve essere completamente rivista.
4.3 Requisiti complessi

Nei paragrafi precedenti si é analizzata la difficoltá intrinseche nei progetti
i cui requisiti vengono influenzati dalla informatizzazione. Un caso diverso
si ha per i sistemi i cui requisiti rimangono sostanzialmente stabili durante
la fase di informatizzazione ma che presentano requisiti difficili da analiz-
zare e chiarire.
In altri termini si tratta spesso di progetti rivolti all’informatizzazione di
processi complessi di cui non esiste una documentazione chiara, anzi spes-
so il processo viene documentato chiaramente per la prima volta proprio
durante la sua informatizzazione.
Un approccio che si é rivelato piuttosto efficiente in questi casi é quello del-
40
Analisi di parte
dei requisiti
Formalizzazione
dei requsiti
Progettazione di
parte del sistema
Sviluppo
Installazione
Incontro con gli

stackholder
Figura 20: Schema delle fasi principali dello sviluppo evolutivo.
41
lo sviluppo in evoluzione. L’idea alla base di questa metodologia é quella di
far crescere il software per funzionalitá, via via che queste vengono chiarite
nel rapporto con gli stackholder (fig. 20)
Il razionale di questo approccio non é immediato ma é molto importante.
L’ostacolo principale in questi progetti é ovviamente la raccolta dei requisi-
ti. Questi potrebbero essere raccolti in forma completa e definitiva prima di
iniziare la fase di progettazione e quindi di sviluppo, allora perché si pro-
fessa lo sviluppo evolutivo? La risposta é un po’ psicologica, gli stackholder
infatti dopo qualche incontro iniziale si stancano di aver intorno analisti
che fanno delle domande e questo mina alla base il processo di ingegneria
dei requisiti, per questo lo stratagemma di fornire una base (funzionante e
ben testata) di requisiti ma non completa incita gli stackholder a continuare
il processi dei requsiti per arrivare alla conclusione.
5 I Design Pattern
Un Design Pattern é un modello architetturale ben definito per ottenere un
preciso risultato.
L’idea dei design pattern nasce direttamente dall’architettura civile dove se
ne fa comunemente uso. Si pensi ad esempio alla necessitá di introdurre un
accesso per persone deambulanti con carrozzina in una scuola. La risposta
moderna é l’inserimento di una rampa liscia a fianco delle scale.
Uno dei vantaggi dei design pattern é che costituiscono una piattaforma
comune di dialogo tra progettista e sviluppatore, esattamente come accade
nell’ingegneria civile.
I Design Pattern sono caratterizzati da:
Nome : il nome con cui il pattern é conosciuto nella comunitá.
Contesto : una descrizione chiara e breve del contesto applicativo in cui si

sono dimostrati utili e in cui sono stati realmente applicati.
Esigenza o problema : la descrizione dell’esigenza e o problema che il

pattern assolve (risolve).
Caratteristiche e punti di forza : descrizione dei punti di forza della solu-

zione.
Partecipanti : le entitá (oggetti, classi e componenti) che compongono la

soluzione.
Struttura : la descrizione architetturale della soluzione, completa di tutte

le viste e diagrammi necessari per la sua comprensione.
Collaborazioni : eventuali altri pattern a cui il pattern puó essere associa-

to.
42
5.1 Il pattern Mode View Controller (MVC)
In questo paragrafo sará brevemente introdotto il pattern MVC. Nel pa-
ragrafo successivo si analizzerá la presenza di questo pattern all’interno
dell’architettura del progetto ReadyReport.
Nome : Model View Controller.
Contesto : Si vuole sviluppare un’applicazione che prevede un’interfac-

cia grafica composta da diversi moduli (maschere, form o che dir si
voglia).
Esigenza o problema : Si desidera collocare il codice che implementa il

modello logico matematico del sistema in uno strato diverso da quel-
lo dell’interfaccia utente .
Caratteristiche e punti di forza :
• Il flusso dei dati e delle operazioni risulta controllato principal-

mente da un unico componente, in questo modo diventa sem-
plice verificare come il sistema regola il flusso dei dati.
• Gli elementi di interfaccia possono essere modificati, integrati o
eliminati con estrema semplicitá.
Partecipanti :
Model : Rappresenta i componenti e le classi che implementano il

modello logico matematico del sistema. Comprende le classi che
rappresentano lo stato del sistema.
View : Rappresenta i componenti che hanno il compito di fornire
l’interfaccia di controllo per l’utente (controlli) e che mostrano
lo stato del sistema attraverso i controlli stessi o con grafici.
Controller : Riceve le notifiche degli eventi di interfaccia dai viewer,
chiama i conseguenti metodi del model quindi rende accessibili
ai viewer lo stato del model.
Struttura : La struttura di base é delineata nel diagramma di figura 21.
Collaborazioni : Questo pattern viene spesso associato nei sistemi ad even-

ti al pattern Observer.
5.2 Le web application ed il MVC

Una applicazione web é un’applicazione caratterizzata dal ricevere in input
dei parametri passati per mezzo di METHOD http tipicamente GET e POST e
restituire in output una risposta sempre protocollata http.
43
Model
Fornisce il modello logico e lo stato

del sistema (dati)
Controller
Seleziona la vista
Visualizza i dati del modello
Notifica gli eventi
View
Figura 21: Il diagramma del pattern MVC.
La risposta é tipicamente un contenuto visualizzabile su un web browser,

quindi tipicamente un contenuto HTML, XHTML, XML .... La risposta vie-
ne creata dinamicamente dal codice e oltre ai dati che debbono essere visua-
lizzati sul browser comprende anche il codice base per la visualizzazione
dei controlli (liste, bottoni, campi di testo ecc.) necessari all’utente per il
controllo dell’applicazione.
Questo tipo di applicazioni si appoggiano quasi sempre a dei componen-
ti software server detti Container o Application Server. Il ruolo di questi é
quello di gestire le richieste http in arrivo e le risposte in uscita isolando
le applicazioni dalla gestione dei problemi legati alle connessioni TCP-IP e
alla concorrenza.
Quando un server (Container o Application Server che dir si voglia) riceve
una richiesta per una risorsa gestita da una data web application, passa il
controllo esecutivo alla applicazione rendendogli disponibili anche tutti i
dati contenuti nella richiesta (Request) http giunta al server.
La web application esegue le proprie elaborazioni come accedere ad un da-
tabase, eseguire dei conti ecc. Le elaborazioni eseguite dalla web application
sono di norma parametrizzate ed i parametri sono quelli che giungono dal-
le pagine HTML protocollati nella request secondo il protocollo HTTP.
Durante l’elaborazione la web application costruisce via via la risposta (Re-
sponse che sará inviata al client (per esempio un browser). In genere la
costruzioni consiste nella definizione incrementale di una stringa che rap-
presenta un documento HTML.
44
Lo stile di controllo di una web application é sostanzialmente implementato
nella logica con cui si costruiscono i collegamenti tra i vari moduli della web
application.
5.2.1 La struttura delle WEB application

Le web application hanno tipicamente una struttura modulare che ricalca
quasi fedelmente l’insieme dei documenti web (pagine HTML o affini) che
l’applicazione produce. Ogni modulo é associato alla pagine web che pro-
duce in una relazione uno a uno (fig. 22). Normalmente nelle applicazioni
moderne (da dopo il 2000) le operazioni che definiscono il modello logico
non sono direttamente implementate nel codice dei moduli di interfaccia
ma sono collocate dentro delle specifiche classi. Dal momento che i con-
Home.jsp
Home.js
p
ModelloLogico ListaPrestazioni.jsp
produciListaPrestazioni()
copiaImmaginiDalPacs()
esportaRefertiSulWEB()
ListaPrestazioni.js
produciListaWeb()
p
CopiaImmagini.jsp
CopiaImmagini.js
p
Figura 22: Relazioni tra i moduli di una web application e le pagine generate.
trolli per la navigazione sono direttamente inseriti in ogni pagina creata si

ha che lo stile di controllo é decentrato. In figura 23 é riportato una descri-
zione pittorica dei collegamenti tra le varie pegine web di una web appli-
cation, tali collegamenti sottointendono nella realtá il controllo della web
application.
Dalle figure 22 e 23 si deduce che sebbene il modello logico sia definito nel-
la classe ModelloLogico le sequenze di chiamate per eseguire le operazioni
sul modello provengono direttamente dal codice di interfaccia.
45
Home.jsp ListaWeb.jsp
ListaWeb.jsp
Home.jsp
Export.jsp ListaPrestazioni.jsp
Export.jsp ListaPrestazioni.jsp
CopiaImmagini.jsp
CopiaImmagini.jsp
Figura 23: Collegamenti esistenti tra le pagine web generate dalla web
application.
5.2.2 Il pattern MVC per il controllo delle web application

Il controllo decentrato, specie per applicazioni che contano un discreto nu-
mero di moduli, porta a seri problemi nella gestione della complessitá ap-
plicativa.
Una soluzione che si é rivelata concretamente utile per la gestione di web
application di queste dimensioni é l’adozione del MVC per il controllo ap-
plicativo. Rispetto all’architettura mostrata nelle figure 22 e 23 si tratta di
inserire un nuovo elemento (tipicamente una classe) che svolgerá la fun-
zione di Controller (figura 24). I controlli presenti nelle pagine HTML ge-
nerate dirigeranno le richieste http direttamente al Controller passando
ad esso i parametri acquisiti ed un parametro (per esempio un parametro
denominato op) che determina il tipo di azione richiesta dall’utente.
In base al valore del parametro op il Controller:
1. esegue una serie di operazioni sul Model
2. ottiene dal Model l’istanza di una classe che rappresenta una vista
dello stato dell’applicazione (in Java si tratta spesso di javabeans)
3. reindirizza il controllo dell’output al modulo designato che normal-
mente avrá direttamente accesso alla classe vista.
Un aspetto importante di questa architettura sono le citate viste. Queste
sono classi che non implementano praticamente nessuna operazione parti-
colare se non incapsulare nel proprio stato tutti i dati che determinano lo
46
ListaWeb.jsp Export.jsp
ListaWeb.jsp Export.jsp
<<Servlet>>
Controller CopiaImmagini.jsp
CopiaImmagini.jsp
ModelloLogico
produciListaPrestazioni()
copiaImmaginiDalPacs()
produciListaWeb()
Figura 24: Introduzione del Controller.
stato applicativo che deve essere mostrato dal viewer, per esempio i record
di una tabella o per il progetto RR la lista delle prestazioni eseguite.
In java queste classi sono tipicamente dei javabeans. Queste classi sono
prodotte dal ModelloLogico sotto sollecitazione del Controller e sono re-
se disponibili ai viewers (fig. 25) per esempio ponendole visibili a livello di
Session.
Infine si puó notare che nelle web application java il model é spesso
realizzato come un EnterpriseJavaBean (EJB).
5.3 Il pattern MVC in ReadyReport

Nel progetto RR le due web application sono caratterizzate dall’utilizzo del
pattern MVC. Il contesto é corretto in quanto si sta sviluppando un sistema
che prevede una serie di pagine web come interfaccia. Il problema é senti-
to in quanto si vuole centralizzare in un’unica classe per lo meno il codice
che accede al DB. I punti di forza non sono semplicemente attraenti ma
rappresentano il vero motivo di questa scelta architetturale, ottenere una
struttura del codice assolutamente chiare riguardo alla gestione del flusso
dei dati e degli eventi.
Si vedrá ora di analizzare come il pattern MVC sia stato implementato al-
l’interno del progetto.
47
ListaWeb.jsp Export.jsp CopiaImmagini.jsp
<<bean>> <<bean>>
ListaWeb Risultato
ModelloLogico
produciListaPrestazioni() <<Servlet>>
copiaImmaginiDalPacs() Controller
produciListaWeb()
Figura 25: Il diagramma mostra la relazione tra i beans e le jsp.
5.3.1 Il Model
Il Model per il progetto ReadyReport é implementato nel componente AccessoDB
(figura 18). In questo componente sono presenti le classi che hanno la re-
sponsabilitá di eseguire le operazioni sui dati. In particolare in questo com-
ponente sono presenti anche le classi che che contengono il codice SQL spe-
cifico per la gestione dei dati nel DB, questo peró (l’accesso al DB) é mediato
dai driver jdbc.
Sebbene non sia necessario disporre Il componente AccessoDB nel container
che offre l’interfaccia HTTP alla web application, si é deciso di sviluppare
questo componente come un EJB (Enterprise Java Bean) e quindi di dispor-
lo dentro un container per sfruttare i servizi che il container offre per la
gestione delle transazioni.
5.3.2 Controller
Il controller é stato implementato come una classe Servlet, cioé una classe
Java che implementa l’interfaccia Servlet.
Il nucleo di base del controller consiste in un costrutto Switch-case (o
if-else if-else) in cui i vari case corrispondono con un possibile in-
sieme dei valori che sono passati dai viewer al controller per mezzo del
parametro op.
48
if(op.equalsIgnoreCase("addpatient"))
{
b=deployPatientResource(request.getParameter("name"),
request.getParameter("fname"),
request.getParameter("nhc"),request.getParameter("dicomid"));
RequestDispatcher rd=
this.getServletContext().getRequestDispatcher("/importadcm.jsp");
if(b)
{
request.setAttribute("deployed",b);
request.setAttribute("message",message);
rd.forward(request,response);
}
}
else if(op.equalsIgnoreCase("addresource"))
{
request.setAttribute("performanceid","");
b=deployIndexedResource(
request.getParameter("performanceid"),
request.getParameter("NationalHealthNumber"));
this.getServletContext().getRequestDispatcher("/importadcm.jsp");
if(b) request.setAttribute("deployed","Operazione riuscita");
else request.setAttribute("deployed","Operazione NON riuscita");
request.setAttribute("performanceid",
request.getParameter("performanceid"));
}else if(op.equalsIgnoreCase("performancelist"))
{
//Data
String idscanner=request.getParameter("idscanner");
logger.debug("idscanner="+idscanner);
if(idscanner=="")idscanner=request.getParameter("ids");
...
request.getSession().setAttribute("performancelist",
getPerformanceList(idscanner, new Integer( year).intValue(),
...
}
else if(op.equalsIgnoreCase("plist"))
{
49
this.getServletContext().getRequestDispatcher("/performancelist.jsp");
In base al CASE attivato il controller chiama una operazione interna alla

classe e da li vengono chiamati i metodi sul Model.
5.3.3 View
I componenti viewer sono implementati come pagine jsp. Questi si inter-
facciano al controller tramite l’interfaccia lasca definita dall’insieme di va-
lori definiti nello switch-case del controller cioé le stringhe addpatient,
addresource, performancelist, plist....É importante notare che que-
sta interfaccia non definisce un vero tipo ma é solo un contratto tra i viewer
ed il controller.
6 Verifica e convalida
La quarta fase del processo software consiste nella verifica e convalida dei
requisiti funzionali e non funzionali.
In genere con verifica si intende la fase in cui ci si accerta che il software
lavori come stabilito nelle specifiche. Le specifiche sono peró solo una rap-
presentazione scritta delle aspettative di chi userá il software e quindi po-
trebbero (come giá ampiamente discusso nei paragrafi precedenti) differire
dalle reali esigenze dei committenti. Per questo prima di rilasciare un soft-
ware si procede anche con la fase di convalida in cui si verifica se le speci-
fiche implementate sono proprio ció che ci si attendeva.
Al termine di una fase di sviluppo7 si dispone di un prodotto/prototipo le
cui caratteristiche possono essere osservate e testate similmente a quanto si
fa per un manufatto.
Le caratteristiche di ogni buon prodotto software devono essere:
Correttezza : il software deve essere conforme alle specifiche definite nella

fase dei requisiti.
Soliditá (Robustezza) : il software deve gestire eventuali errori che si pos-

sono produrre nelle fasi di I/O e di processo dei dati evitando che
il sistema ospitante (tipicamente un Sistema Operativo) debba inter-
romperne l’ esecuzione.
Efficienza : il software deve fare un uso razionale delle risorse del sistema.
In questa sezione si analizzeranno le metodiche attualmente accettate

per la verifica del software.
7 Qui si intende che lo sviluppo di un sistema puó avvenire in diverse fasi.
50
6.1 Cominciare bene
La fase di verifica di un sistema puó essere lunga e difficile e spesso alcune
difformitá dai requisiti risultano solo dopo diverso tempo che il software
é giá in esercizio. Per questo motivo é meglio condurre l’intero ciclo di
sviluppo seguendo un principio di qualitá e non riversare tutta la respon-
sabilitá alla singola fase della verifica.
É bene notare che questo approccio di qualitá non é in contrasto con la meto-
dologia di sviluppo prototipale a patto che ad ogni ciclo di sviluppo segua
una fase di refactoring8 .
Un metodo per produrre codice di qualitá e quello di seguire delle Best
Pratics:
Utilizzo di pattern : l’utilizzo di design pattern consiste nell’impiegare de-
gli schemi noti e giá testati per ottenere un dato risultato. Impiegare
i design pattern evita di introdurre potenziali errori in un prodot-
to e velocizza le fasi di test in quanto le strutture del codice sono
immediatamente riconoscibili.
Scelta dei linguaggi : la scelta del linguaggio con cui sviluppare il soft-
ware puó influenzare la capacitá effettiva degli sviluppatori di pro-
durre codice corretto e robusto.
Incapsulamento : in un progetto modulare é bene che le responsabilitá

del codice siano ben definite per ogni modulo. Un esempio é l’uso
dei meccanismi per la gestione dell’integritá referenziali dei dati sul
database.
Design by Contract : é una tecnica di programmazione che permette di

evidenziare gli errori di design evitando di gestire alcuni tipi di ec-
cezione e trattandoli invece come delle contraddizioni del design.
Ogni contraddizione viene segnalata a chi testa il sistema mediante
un qualche meccanismo (errori bloccanti o file di log).
Utilizzo di registri (log) : la fase di verifica e convalida continua anche

dopo il rilascio di un prodotto. Per questo é sempre bene che ad ogni
sistema sia accompagnato un log (registro) che consenta di verificare
la presenza di errori o problemi.
6.2 Dopo la progettazione e dopo lo sviluppo

Se il progetto di un sistema e sufficientemente dettagliato é possibile ana-
lizzarlo per verificare se l’eventuale sistema che seguirá il progetto (cioé il
risultato dello sviluppo) sará conforme ai requisiti e alle specifiche.
La fase di ispezione e verifica di un progetto é molto importante e se ben
8 Ristrutturazione razionale del codice sviluppato in fretta.
51
condotta permette di risparmiare molto tempo nelle successive fasi di veri-
fica del prodotto (cioé il sistema sviluppato).
Molti sistemi peró vengono sviluppati seguendo dei processi di sviluppo
prototipale e tipicamente questa metodologia di processo impone l’uso di
progetti a basso livello di dettaglio. Pertanto l’ispezione dei progetti il piú
delle volte permette di verificare la presenza di errori evidenti di sistema
e architettonici ma piú difficilmente potrá mettere in luce delle difformitá
dalle specifiche funzionali. Buona parte della fase di verifica deve essere
quindi condotta direttamente sul codice.
6.3 I test
La fase culminale del processo di verifica e di quello di convalida é la fase
dei test. In questa fase si verifica sperimentalmente se il sistema risponde
agli input come ci si aspetta.
La fase di test é divisa in tre momenti:
Sviluppo dei test : si decide quali funzionalit testare e come testarle.
Test : si testa sperimentalmente il sistema.
Documentazione dei risultati (Repots) : si documentano i risultati dei te-
st.
Lo sviluppo dei test é una fase critica, infatti se si dispone di un buon piano
di test é probabile che la maggior parte degli eventuali difetti del sistema
sia evidenziato in questi test, se invece il piano é incompleto la fase di test
fornisce una falsa sensazione di tranquillitá.
Un buon piano dei test deve portare alla verifica del 100% del codice e di
tutti i possibili input del sistema.
La documentazione della fase di test é importante e costituisce un elemento
fondamentale nella gestione della qualitá del progetto.
Tipicamente un documento di test dovrá riportare le seguenti informazioni:
Funzionalitá : la funzionalitá (o il requisito di sistema) che si vuole testa-

tre.
Principio di verifica : il principio o il metodo su cui si basa la verifica
(stimolazione del sistema con input utente e verifica dell’output).
Descrizione dei test : descrizione dettagliata sulla modalitá con cui sará
eseguito il test.
Dati in ingresso : insieme dei dati usati per il test
Risultati attesi : risposta attesa dal sistema
Risultati ottenuti : risposta ottenuta.
52
7 Omissioni
Queste dispense sono state scritte in itinere durante il primo anno in cui
l’autore ha tenuto il corso di Ingegneria del Software presso l’Ateneo di
Ferrara.
Buona parte del lavoro dovrá essere completata e limata. In particolare sono
stati saltati alcuni argomenti importanti che per ragioni di tempo e di orga-
nizzazione non hanno trovato spazio all’interno di questa prima versione
del corso. Di seguito si riportano la lista degli argomenti piú importanti
che lo studente interessato ai temi dell’ingegneria del software dovrebbe
completare autonomamente:
Analisi e specifiche dei sistemi critici
Specifiche formali
Progettazione dei sistemi Real-Time
Ingegneria del software basata sui componenti
Test del software
Convalida dei sistemi critici
Gli argomenti elencati si trovano nei libri comunemente usati per i corsi di
Ingegneria del Software.
53

Main

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Main

Uploaded by

Copyright:

Available Formats

Dispense del corso di Ingegneria del Software

2 I Requisiti del software 6

3 Le basi della progettazione 13

• progetto interno ad un’azienda

• progetto interno ad una comunitá

• progetto Open Source di ampio respiro

L’approccio ingegneristico alla gestione di un progetto software non é so-

Progetto (del cliente) : con progetto si intendono cose diverse ed il suo

Cliente : in generale é chi commissiona il progetto.

Requisiti : sono un insieme di qualitá e funzionalitá richieste al software

Vincoli : si intende normalmente un insieme di requisiti che sono indipen-

Utenti finali : sono le persone o i sistemi che interagiranno in maniera

Finanziatore : persone o organizzazioni che finanziano il progetto, posso-

Tester : persone o sistemi che possono testare il software.

Architetto : stabilisce la struttura del software in termini di sottosistemi

Sviluppatore : scrive e compila il codice.

La gestione dei prodotti di queste categorie e delle loro relazioni costituisce

1.1 Il processo di sviluppo del software

1.2 Il piano del progetto

Introduzione : gli scopi del progetto e ció che si intende realizzare, le

Organizzazione : le parti in gioco ed i ruoli che ciascuno copre all’interno

Hardware e software : i componenti hardware e software necessari per

Attivitá e tempistica o pianificazione : l’elenco delle attivitá principali e

Licenze e brevetti : si descrive la politica di tutela dei diritti d’autore che si

Principi progettuali : eventuali principi progettuali che saranno rispettati.

Il piano del progetto permette di chiarire l’organizzazione del progetto e

2 I Requisiti del software

2.1 Classificazione dei requisiti

2.1.1 Requisiti utente

WEB 3.1 Selezione degli esami di cui pubblicare il referto

Il sistema deve permettere all’operatore della diagnostica

2.1.2 requisiti di sistema

2.2 Requisiti funzionali e non funzionali

2. Preparazione di credenziali di accesso per l’utenza finale (generare

3. Accesso dal web ai propri dati medici

Il requisito WEB 3.1 visto in precedenza é riferito alla macro funzionalitá 1

é un esempio di requisito utente non funzionale. Lo stesso requisito espres-

I requsiti non funzionali sono spesso classificati come:

R. di prodotto : specificano alcune qualitá complessive del prodotto, co-

R. organizzativi : sono spesso indipendenti dagli obiettivi del progetto e

R.esterni : sono imposti dall’ambiente informatico o reale. Due esempi so-

2.3 Il documento dei requisiti

Requisiti utente : l’elenco numerato secondo un dato criterio dei requi-

Architettura del sistema : descrizione dei principali moduli e delle fun-

Requisiti di sistema : elenco ordinato dei requisiti funzionali e non fun-

Modelli del sistema : diagrammi delle classi,diagrammi degli oggetti, casi

Le sezioni architettura del sistema e modelli del sistema possono precedere

2.4 Scrivere codice o documenti?

Piano del Documento di Documento dei

Figura 1: Ingegneria dei requisiti

processi di sviluppo.2 In questa fase l’analista si incontra con gli stackehol-

2.5.1 Progetto ReadyReport

SCENARIO: Il paziente viene sottoposto ad esame radiologico

Il paziente si reca presso la struttura sanitaria. Passa

del sistema in via di sviluppo

Mostra lista delle

Figura 2: Casi d’uso per lo scenario Esame radiologico

In questo scenario si identifica un unico attore che é il tecnico della diagno-

3 Le basi della progettazione

Figura 3: Diagramma di sequenza per lo scenario Esame radiologico

Comportamento : i requisiti sono riferiti al comportamento del sistema

Architettura : giá nella fase di analisi il sistema viene analizzato in sottosi-

Classi : i requisiti sono spesso riferiti all’interazione di persone e siste-

Informazioni : i requisiti che esprimono le associazioni tra le entitá porta-