P. 1
Main

Main

|Views: 13|Likes:
Published by sisini

More info:

Published by: sisini on Oct 18, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

06/02/2013

pdf

text

original

Sections

  • 1.1 Il processo di sviluppo del software
  • 1.2 Il piano del progetto
  • 2.1.1 Requisiti utente
  • 2.1.2 requisiti di sistema
  • 2.2 Requisiti funzionali e non funzionali
  • 2.3 Il documento dei requisiti
  • 2.4 Scrivere codice o documenti?
  • 2.5.1 Progetto ReadyReport
  • 3.1 Dai requisiti di sistema al progetto
  • 3.2.1 Flusso dei dati nel sistema informativo ospedaliero
  • 3.2.2 Il contesto di ReadyReport
  • 3.2.3 Il flusso dei dati di ReadyReport
  • 3.2.4 Architettura
  • 3.2.5 Classificazione
  • 3.2.6 Modello dei dati
  • 3.3.1 L’architettura edilizia, un paragone
  • 3.3.2 Vantaggi e svantaggi della progettazione
  • 3.4.1 I componenti
  • 3.4.2 I connettori
  • 3.5.1 Organizzazione
  • 3.5.2 Scomposizione in moduli
  • 3.5.3 Controllo
  • 3.6 La documentazione del progetto
  • 3.7 Le viste di ReadyReport
  • 4.1 Requisiti statici
  • 4.2.1 progettazione per prototipi
  • 4.2.2 Esempio pratico
  • 4.3 Requisiti complessi
  • 5.1 Il pattern Mode View Controller (MVC)
  • 5.2.1 La struttura delle WEB application
  • 5.2.2 Il pattern MVC per il controllo delle web application
  • 5.3.1 Il Model
  • 5.3.2 Controller
  • 5.3.3 View
  • 6.1 Cominciare bene
  • 6.2 Dopo la progettazione e dopo lo sviluppo
  • 6.3 I test
  • 7 Omissioni

Dispense del corso di Ingegneria del Software

Francesco Sisini 8 Marzo 2008

1

Indice
1 L’approccio ingegneristico 1.1 Il processo di sviluppo del software . . . . . . . . . . . . . . 1.2 Il piano del progetto . . . . . . . . . . . . . . . . . . . . . . . I Requisiti del software 2.1 Classificazione dei requisiti . . . . . . . 2.1.1 Requisiti utente . . . . . . . . . . 2.1.2 requisiti di sistema . . . . . . . . 2.2 Requisiti funzionali e non funzionali . . 2.3 Il documento dei requisiti . . . . . . . . 2.4 Scrivere codice o documenti? . . . . . . 2.5 Raccolta e formalizzazione dei requisiti 2.5.1 Progetto ReadyReport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 5 5 6 7 7 8 8 9 10 11 12 13 13 15 16 16 20 20 20 23 23 25 26 26 26 27 28 28 29 29 30 31 37 37 38 38 39 39

2

3

Le basi della progettazione 3.1 Dai requisiti di sistema al progetto . . . . . . . . . . . . . . 3.2 Modelli del progetto ReadyReport . . . . . . . . . . . . . . 3.2.1 Flusso dei dati nel sistema informativo ospedaliero 3.2.2 Il contesto di ReadyReport . . . . . . . . . . . . . . 3.2.3 Il flusso dei dati di ReadyReport . . . . . . . . . . . 3.2.4 Architettura . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Classificazione . . . . . . . . . . . . . . . . . . . . . 3.2.6 Modello dei dati . . . . . . . . . . . . . . . . . . . . 3.3 La progettazione . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1 L’architettura edilizia, un paragone . . . . . . . . . 3.3.2 Vantaggi e svantaggi della progettazione . . . . . . 3.4 Componenti, connettori e dati . . . . . . . . . . . . . . . . . 3.4.1 I componenti . . . . . . . . . . . . . . . . . . . . . . 3.4.2 I connettori . . . . . . . . . . . . . . . . . . . . . . . 3.5 Organizzazione, scomposizione e controllo . . . . . . . . . 3.5.1 Organizzazione . . . . . . . . . . . . . . . . . . . . . 3.5.2 Scomposizione in moduli . . . . . . . . . . . . . . . 3.5.3 Controllo . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 La documentazione del progetto . . . . . . . . . . . . . . . 3.7 Le viste di ReadyReport . . . . . . . . . . . . . . . . . . . . Sviluppo 4.1 Requisiti statici . . . . . . . . . . . 4.2 Requisiti dinamici . . . . . . . . . . 4.2.1 progettazione per prototipi 4.2.2 Esempio pratico . . . . . . . 4.3 Requisiti complessi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2

5

I Design Pattern 5.1 Il pattern Mode View Controller (MVC) . . . . . . . . . . . . 5.2 Le web application ed il MVC . . . . . . . . . . . . . . . . . . . 5.2.1 La struttura delle WEB application . . . . . . . . . . . 5.2.2 Il pattern MVC per il controllo delle web application 5.3 Il pattern MVC in ReadyReport . . . . . . . . . . . . . . . . . 5.3.1 Il Model . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Controller . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verifica e convalida 6.1 Cominciare bene . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Dopo la progettazione e dopo lo sviluppo . . . . . . . . . . . 6.3 I test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Omissioni

41 42 42 44 45 46 47 47 49 49 50 50 51 52

6

7

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 alla programmazione ha normalmente gi´ chiaro l’algoritmo e la sua attivit´ a a 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 attivit´ deve essere svolta tenendo conto di tutti a 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 processi 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 relazionarsi con un sistema formale (il modello logico da cui si tra l’algoritmo) ´ il secondo e centrato su capacit´ organizzative e di coordinamento di attia vit´ reali e non formali. a In alcune realt´ industriali esiste una netta separazione tra i ruoli di ara chitetto, ingegnere e sviluppatore del software, in altre chi si occupa dello sviluppo stabilisce anche l’architettura ma non segue il processo ingegneristico, in altre ancora non esiste una netta separazione di questi ruoli ne a livello formale ne concreto. Nella realt´ produttiva italiana si trovano spesso delle situazioni in cui il a ´ 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 focalizzare l’attenzione sulla problematica dello sviluppo del software. Dal momento che questo corso viene tenuto in un ateneo italiano e che statistica´ mente ci si puo aspettare che la maggior parte degli studenti svolgeranno la loro futura attivit´ in questo paese i concetti saranno presentati nela 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 comunit´ a • progetto Open Source di ampio respiro ´ L’approccio ingegneristico alla gestione di un progetto software non e sostanzialmente 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 adeguato. ´ Per acquisire un approccio ingegneristico e necessario anzi tutto porre l’attenzione 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 qualit´ e funzionalit´ richieste al software a a che si vuol sviluppare. Vincoli : si intende normalmente un insieme di requisiti che sono indipendenti 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, possono 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 attivit´ svolte da dia versi attori che hanno un inizio uno sviluppo ed un termine. Ognuna di 5

Altre branche dell’ingegneria debbono occuparsi della gestione di processi ed attivit´ guidati dall’uomo ma. la compilazione ed il test del codice. a Progettazione : comprende sia la progettazione del sistema software (architettura. decise e guidate normalmente da esseri umani a ´ e pertanto non sono controllabili con la stessa precisione con cui e possibile controllare le attivit´ svolte da una macchina. 1. come si avr´ modo di capire. Sviluppo : si intende normalmente la scrittura. Normalmente il processo di sviluppo viene suddiviso in quattro categorie principali.2 Il piano del progetto ´ Il piano del progetto e un documento che viene redatto da chi ha la responsa´ bilit´ di gestire il processo di sviluppo ed e sicuramente un buon punto di a 6 . Le raa gioni di questo sono probabilmente da ricercarsi sia nel fatto che il prodotto ´ di questo processo ingegneristico e qualcosa che sta a met´ tra il prodotto a ´ 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.esse costituisce quindi un processo e considerate tutte insieme definiscono il processo di sviluppo (del software). Queste attivit´ sono svolte. tecnologie e hardware) che la progettazione delle metodologie. a Queste quattro macro attivt´ (o fasi) del processo spesso non sono ben dia stinte ed i loro contorni sfumano l’uno nell’altro. l’ingegneria a a del software spicca per la particolare complessit´ di questa gestione. inoltre il risultato di queste a ´ attivit´ ha spesso un carattere intangibile e questo rende ancor piu coma plesso il loro controllo ma anche il loro monitoraggio. 1. delle risorse e del team di sviluppo.1 Il processo di sviluppo del software ´ Gestire il processo di sviluppo e il compito dell’ingegneria del software. l’insieme delle funzionalit´ che il software a deve offrire e le qualit´ che deve possedere. queste sono: ´ Analisi dei requisiti : questa e l’insieme delle attivit´ che hanno lo scopo a di chiarire e formalizzare l’obiettivo finale per cui il software viene sviluppato (o modificato). Test e validazione : sono le attivit´ per verificare la correttezza del softa ware la sua robustezza e l’affidabilit´ . La sequenza e la pianificazione di queste fasi rappresenta un aspetto importante della gestione del processo.

finanziatori. Hardware e software : i componenti hardware e software necessari per ´ lo sviluppo del progetto.partenza. architetti. strumentali. L’espressione artistica pura. una stima del budget (risorse economiche a disposizione di chi sviluppa) ed una stima del valore del progetto. I rischi vengono spesso classificati come: tecnologici. Questo documento non deve descrivere i requisiti e l’architettura del progetto. dei requisiti e di stima (dei tempi e delle risorse). 7 . organizzativi. sviluppatori ed ingegneri) i punti seguenti: ´ Introduzione : gli scopi del progetto e cio che si intende realizzare. i sentimenti ed altre categorie ´ non ingegneristiche possono dissociarsi da questo assioma. le parti che partecipano al progetto. il pensiero libero. E bene che anche il cliente abbia una a versione di questo documento. Il piano del progetto permette di chiarire l’organizzazione del progetto e ´ le varie attivit´ che verranno svolte. utenti. Principi progettuali : eventuali principi progettuali che saranno rispettati. Organizzazione : le parti in gioco ed i ruoli che ciascuno copre all’interno del progetto. ´ A partire da questo piano e possibile pianificare l’analisi dei requisiti che saranno argomento del prossimo paragrafo. Licenze e brevetti : si descrive la politica di tutela dei diritti d’autore che si intende applicare oltre alla eventuale necessit´ di dotarsi di specifiche a licenze o per lo sviluppo o per il cliente. lo scopo di questo documento e quello di chiarire nella mente dei soggetti che parteciperanno al progetto (clienti. questi elementi infatti saranno chiariti e approfonditi nel corso del ´ progetto stesso. Rischi del progetto : sono una serie di eventi e circostanze su cui non si ha il controllo diretto. Questa voce puo riferirsi sia al team di sviluppo che al cliente. Attivit´ e tempistica o pianificazione : l’elenco delle attivit´ principali e a a la loro pianificazione nel tempo (questo paragrafo sar´ soggetto a a molte variazioni nel corso dello sviluppo del progetto). L’organizzazione dei team di analisi. del personale. ma cio che viene ´ prodotto dall’uomo in termini di beni e servizi e soggetto a requisiti. sviluppo e test. 2 I Requisiti del software ´ Qualsiasi opera ingegneristica e soggetta a ben determinati requisiti.

1 Selezione degli esami di cui pubblicare il referto Il di il La in sistema deve permettere all’operatore della diagnostica selezionare gli esami (di cui si vuole pubblicare referto) da una lista ottenuta a partire dalla worklist. ´ dell’analisi e dalla documentazione dei requisiti e materia viva e tuttora in discussione. Alcuni ingegneri professano la necessit´ di applicare metodi a formali e procedure di qualit´ per la gestione dei requisiti (metodi Heaa vyweight o Monumental). a 2. scelta di questa opzione deve essere preselezionata base alla scelta del paziente (memorizzata sul RIS).I requisiti qualit´ e funzionalit´ che il software deve possedere e fornire per a a essere considerato conforme ai propositi ed agli obiettivi che ne hanno determinato lo sviluppo. Nell’ambito dell’ingegneria del software la problematica dell’acquisizione.1.1 Classificazione dei requisiti I requisiti vengono normalmente classificati come requisiti utente e requisiti di sistema. 8 . anche se ovviamente la prospettiva sotto cui questi saranno osservati dipender´ ovviamente dal ruolo svolto dall’ attore. Questa prima classificazione si riferisce non tanto alla qualit´ del a requisito quanto al linguaggio usato per specificarlo ed al livello di dettaglio a cui il requisito fa riferimento. questi debbono essere assolutamente ben noti a tutti gli attori che partecipano al progetto. ´ Il punto di vista di questo corso e che indipendentemente dalla metodologia che si intende usare per la documentazione dei requisiti. 2.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 essere progettato e sviluppato per essere conforme a dette caratteristiche. altri hanno sviluppato delle metodologie leggere che in linea di principio permettono di seguire l’ingegneria dei requisiti in maniera snella e produttiva. ´ 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.

jsp Action: createexaminationcredential input: worklist. I requisiti funzionali descrivono cosa il sistema deve offrire e fare.jsp processedby: securityman model: wlEJB success: worklist. WEB 3.1 Action: showworklist Input: mainmenu.1. Il requisito utente WEB 3.1 visto sopra da origine a diverse specifiche funzionali.jsp error: dicomerror.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 Requisiti funzionali e non funzionali I requsiti ( sia utente che di sistema) si classificano in funzionali e non funzionali.jsp processedby: dicombridge model: wlEJB success: worklist. di un model e delle API per accedere alla work-list. Facendo ancora riferimento al progetto a per lo sviluppo del servizio di download dei record medici.2 requisiti di sistema I requisiti di sistema devono descrivere le funzionalit´ del sistema in termia ni molto vicini al paradigma di sviluppo utilizzato per il progetto.jsp 2. In altri termini se il progetto segue un approccio procedurale (tipo linguaggio C) alcuni requisiti di sistema possono essere descritti come funzioni specificandone il prototipo e l’algoritmo di base. 1 Il 9 . vediamo che le macro funzionalit´ del servizio sono: a ´ Model View Controller e un pattern architetturale per dividere la logica di presentazione dei dati dal controllo delle azioni dell’utente. 2. Nel contesto di una architettura basata (anche) sul pattern MVC1 questo requisito comporta la definizione di alcune action di una view.jsp error: secrity. ´ La loro caratteristica principale e che sono normalmente associati a specifiche macro funzionalit´ del sistema.

2/Tomcat/Mysql su piattaforma Linux. organizzativi : sono spesso indipendenti dagli obiettivi del progetto e si riferiscono alle modalit´ di sviluppo e documentazione del progeta to in se. R. a a 2. a R. funzionali e non funzionali del progetto. Sui server saranno virtualizzati gli ambienti web che consisteranno in un Jboss 4.2 Il servizio di download deve essere garantito 7/7 giorni. Il servizio deve essere attivo anche durante le operazioni di manutenzione.1 visto in precedenza e riferito alla macro funzionalit´ 1 a ´ ed e un esempio di requisito funzionale. Per esempio un cliente potrebbe richiedere che al progetto lavorino solo sviluppatori senior. di prodotto : specificano alcune qualit´ complessive del prodotto. Accesso dal web ai propri dati medici ´ Il requisito WEB 3. ´ e un esempio di requisito utente non funzionale.esterni : sono imposti dall’ambiente informatico o reale. la velocit´ nel processare le transazioni e la portabia a lit´ su differenti piattaforme.3 Il documento dei requisiti Nel documento dei requisiti vanno vanno riportati i requisiti utente e di sistema. Preparazione di credenziali di accesso per l’utenza finale (generare coppia username/password o certificato digitale) 3. a 10 . I requsiti non funzionali sono spesso classificati come: R. 24/24 ore. Due esempi sono il supporto di un protocollo per la comunicazione con un sistema esterno e la conformit´ con le specifiche WAI per l’accessibilit´ . coa me l’affidabilit´ . Lo stesso requisito espresso in termini di sistema diventa: RR 4. ´ La stesura di questo documento e senz’altro pesante e tediosa e spesso il documento dei requisiti risulta datato gi´ durante la sua redazione.2 Il servizio http realizzato installando una copia di server in cluster.1. Opzionalit´ sui record da rendere accessibili all’utenza a 2. Il requisito: RR 4.

Le sezioni architettura del sistema e modelli del sistema possono precedere le sezioni sui requisiti. diagrammi di flusso ecc. Descrizione delle interfacce tra i a moduli. Si possono separare i requisiti funzionali da quelli non funzionali Architettura del sistema : descrizione dei principali moduli e delle funzionalit´ che vi sono implementate. 11 . ´ Sicuramente una cosa che vale la pena chiarirsi e che un processi di svilup´ po software ha scarse possibilit´ di successo se e lasciato completamente a a se steso. Queste metodologie propongono che i requisiti siano raccolti in corso d’opera e gestiti in maniera ´ piu o meno diretta dagli sviluppatori. Requisiti utente : l’elenco numerato secondo un dato criterio dei requisiti utente. ´ E molto difficile trarre delle considerazioni che abbiano una validit´ genea rale. 2. Requisiti di sistema : elenco ordinato dei requisiti funzionali e non funzionali del sistema. casi d’uso. ´ Ad uno sviluppatore creativo puo dar noia ricevere un documento con le specifiche di sistema mentre potrebbe gradire le specifiche utente.diagrammi degli oggetti.4 Scrivere codice o documenti? Scrivere documentazione costa energie e concentrazione.In alcune metodologie il documento dei requisiti viene visto come una adempimento formale privo di interesse pratico. Modelli del sistema : diagrammi delle classi. 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. 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.

2. Il processo continua con una prima raccolta informale dei requisiti allo scopo di definire la fattibilit´ del progetto. purch´ il progetto una volta realizzato non determini a e ´ nuove esigenze a cui esso puo rispondere. 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 progetto Documento di fattibilità Documento dei requsiti Figura 1: Ingegneria dei requisiti processi di sviluppo.2 In questa fase l’analista si incontra con gli stackeholrealt´ per molti progetti ed in special modo per i progetti software che riguardano a l’automazione di processi aziendali. Il processo puo essere schematizzato come ´ in figura 1. Questi dopo essere stati raccolti vengono formalizzati nel documento dei ´ requisiti e quindi convalidati.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. L’analisi della fattibilit´ produce il documento di fattibilit´ e a condizioa a ne che esso sia positivo si procede con l’analisi e la raccolta dei requisiti. a L’analisi della fattibilit´ deve tener conto sia di eventuali impedimenti teca nologici che della reale necessit´ dello sviluppo del progetto. la raccolta e l’analisi dei requisiti continuano per tutto 2 In 12 . Va da se che a ´ un progetto di cui nessuno sente realmente l’esigenza e con ogni probabilit´ destinato a fallire.

Questi sono gli stackeholder del sistema. Non esiste un metodo universalmente valido per condurre le interviste. 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. quindi immediata e leggera. a a a La pratica dell’ingegneria del software ha portato nel tempo al consolidarsi di metodologie per assistere tutte le fasi del processo. 2. ´ il ciclo di vita del software sviluppato. Questa attivit´ quindi non solo non e limitata alla a fase iniziale della progettazione ma spesso continua anche nella fase di manutenzione. ´ ´ ´ 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. il responsabile dei sistemi informativi.1 Progetto ReadyReport Il progetto ReadyReport coinvolge l’amministratore delegato della struttura sanitaria. Alcuni degli stackeholder si riveleranno veri attori del sistema.5. In realt´ essi vengono coinvolti nel a processo di raccolta in maniera diversa. 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 sensibilit´ . mentre altri non parteciperanno ad alcuno scenario. Attende il proprio turno. Passa in accettazione e paga il ticket. 3 Questo termine indica le persone che saranno influenzate in maniera piu o meno diretta ´ del sistema in via di sviluppo 13 . la segreteria della radiologia. disponibilit´ al dialogo e capacit´ espressiva.der3 e cerca di trarre i requisiti utente e di sistema per mezzo di interviste. Per la raccolta dei requisiti si fa ora largo uso di diagrammi che hanno lo scopo di contestualizzare i requisiti in specifici scenari di utilizzo e di semplificare il corso delle interviste e la loro successiva analisi. le loro aspettative e gli aspetti che maggiormente li preoccupano. i medici radiologi. In linea di principio ognuno di essi andrebbe intervistato per raccogliere la sua versione dei requisiti. SCENARIO: Il paziente viene sottoposto ad esame radiologico NOME: Esame Radiologico Il paziente si reca presso la struttura sanitaria. L’utilit´ di questi diagrammi e che sono molto intuitivi ed esplia cativi e consentono di analizzare il sistema dal punto di vista dell’utente in maniera grafica. 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. Questi diagrammi sono detti diagrammi dei casi d’uso o use cases e fanno parte del linguaggio di modellazione UML. i fornitori del PACS e del RIS e gli utenti del servizio di radiologia. i tecnici della diagnostica.

La spiegazione di questa dipendenza discende direttamente dalla essenza stessa del requisito di sistema: 14 . Allo stesso modo mostrando i casi d’uso agli attori questi potranno facilmente riconoscere errori ed omissis. Il tecnico seleziona il record per la pubblicazione del referto sul web. Il tecnico di diagnostica riceve i dati del paziente da RIS. I casi d’uso per questo scenario sono riportati in figura 2. Se un analista deve passare le consegne ad un collega i casi d’uso chiariranno subito quali sono gli attori da intervistare ed in quali contesti. Esegue l’esame. ReadyReport Mostra lista delle prestazioni Tecnico Diagnostica Predispone l'esame per l'accesso dal web Figura 2: Casi d’uso per lo scenario Esame radiologico ´ In questo scenario si identifica un unico attore che e il tecnico della diagnostica. Il tecnico stampa la username e la password per il paziente e le consegna.1 Le basi della progettazione Dai requisiti di sistema al progetto La progettazione di un software e l’analisi dei requisiti di sistema sono sono due fasi interdipendenti che evolvono insieme in maniera ciclica reiterando l’una nell’altra. 3 3. Anche il sistema di accettazione e di pagamento del ticket non interagiscono con il sistema. Il paziente entra nello scenario ma non partecipa ad alcune attivit´ a con il sistema RR. La rappresentazione grafica aiuta sia il dialogo con gli attori che il successivo momento di analisi. Il sistema RR mostra il record del paziente con il relativo numero della prestazione.si presenta in diagnostica e si posiziona per l’esame.

Tecnico Diagnostica prestazioni.jsp Controller EJB DB RIS lista prestazioni lista prestazioni lista prestazioni SQL Query Resultset Figura 3: Diagramma di sequenza per lo scenario Esame radiologico 15 .

classi e informazioni del sistema stesso e quindi costituisce l’incipit (il principio)dell’analisi progettuale. Questo porta alla definizione dei requisiti di sottositema e quindi ad una prima scelta di architettura. E ragionevole supporre che questo sistema debba essere installato in un ambiente in cui sia gi´ presente un sistema informativo. L’uso dei diagrammi contribuisce alla definizione dei modelli del sistema. Informazioni : i requisiti che esprimono le associazioni tra le entit´ portaa no alla definizione semantica dei dati. Comportamento : i requisiti sono riferiti al comportamento del sistema cio´ al processo delle informazioni e/o alla modifica dello stato del e sistema in base agli eventi. Nella pratica prima di identificare il contesto per il progetto in sviluppo risulta conveniente produrre un diagramma del comportamento del sistema esistente.Contesto : i requisiti debbono riferirsi al sistema da sviluppare e non a quanto gi presente. comportamento. 16 . architettura. Il primo passo per la definizione dei requisiti di sistema di ReadyReport ´ e la definizione dei confini stessi del sistema. Tali entit´ debbono essere analizzate e a classificate. Architettura : gi´ nella fase di analisi il sistema viene analizzato in sottosia stemi. Risulta che l’analisi dei requisiti di sistema passa per lo studio del contesto.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. Nel paragrafo successivo verranno presentati alcuni diagrammi relativi al progetto ReadyReport. 3. Una volta tracciati i confini risulter´ piu semplice identificare le interfacce ed i protocolli per la a ´ comunicazione tra ReadyReport ed il resto del sistema. ´ Lo studio dei punti visti sopra risulta notevolmente piu chiaro se condotto per mezzo di diagrammi. Classi : i requisiti sono spesso riferiti all’interazione di persone e sistemi con il sistema in sviluppo. piu in generale i sistemi informativi dedicati alle strutture sanitarie sono detti HIS (Health Information System) o in italiano SIO (Sistema Informativo Ospedaliero). Bisogna pertanto evidenziare i confini tra il sistema e l’ambiente. I sistemi informativi dedicati a alle esigenze dei reparti di radiologia sono detti RIS (Radiological Informa´ tion System).

2. Segue immediatamente 17 .2 Il contesto di ReadyReport L’analisi condotta per la definizione del Data-Flow del processo diagnostico ha evidenziato i confini dei sistemi RIS e PACS. 6 e rappresentato il percorso dei dati per una prestazione radiologica. 3.1 Flusso dei dati nel sistema informativo ospedaliero Paziente Dati Morfologia Accettazione Acquisizione immagine Refertazione 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. La definizione del flusso dei dati nel ´ sistema preesistente e importante per definire il contesto e l’architettura del ReadyReport.3.2. in particolare si evidenziano i processi e i DataBase di competenza del sistema RIS e PACS. 5. ´ Nelle figure 4.

In evidenza il sottositema RIS. 18 .Paziente Dati Morfologia Referto Refertazione Accettazione Acquisizione immagine Prenotazione prestazione RIS Immagine RIS-DB Immagine PACS Figura 5: Diagramma di sequenza per lo scenario Flusso dei dati per l’esecuzione di una prestazione radiologica.

In evidenza il sottosistema PACS.Paziente Dati Morfologia Refertazione Accettazione Acquisizione immagine Immagine Prenotazione prestazione PACS Immagine Referto PACS RIS-DB Figura 6: Diagramma di sequenza per lo scenario Flusso dei dati per l’esecuzione di una prestazione radiologica. 19 .

Il diagramma del conte´ sto e riportato in figura 7. 4 Digital 20 . specifica per lo scambio di dati e servizi tra gli applicativi medici. disponibilit´ e risorse. Questo scenario complica il progetto iniziale. nel caso in questione a ´ RR. scadenze. Si supponga. a titolo di esempio. con il WEB. non e sempre univocamente determinato dalle condizioni ambientali ma ´ puo essere modificato per adattarlo alle esigenze o ai vincoli di progetto.che il sistema RR dovr´ interagire con questi due sottosistemi e. infatti viene inserito tra le parti un nuovo elemento (il fornitore del RIS) con le proprie esigenze. obiettivi. RIS READYREPORT WEB PACS Figura 7: Diagramma di sequenza per lo scenario Diagramma del contesto per il sistema RR. che il RIS presente presso una struttura sanitaria non presenti una interfaccia di comunicazione DICOM4 per lo scambio dei dati con altre applicazioni. Imaging and Communication in Medicine. come dea dotto dall’oggetto stesso del progetto. Il committente potrebbe temere quea sto scenario e optare per una soluzione in cui le funzioni svolte dal RIS siano ricoperte dal progetto RR. 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 richiedere le specifiche per l’integrazione. Il contesto in cui si trover´ ad operare un sistema.

vengono impiegati per descrivere le classi (come costrutti di codice) e le relazioni tra esse che saranno sviluppate.3. La definizione di questo diagramma ´ e un primo passo verso la definizione del progetto del sistema in cui gi´ si a delinea un database dedicato (RR-DB). I processi (funzioni sui dati) visti nel diagramma del flusso dei dati vengono riferiti ai sottosistemi identificati in questo diagramma. Come si e visto nei ´ paragrafi precedenti la definizione dei requisiti di sistema e semplificata dalla definizione di sottosistemi. 3. In questo caso si impiegano questi diagrammi per dare una rappresentazione della struttura (fig 11) e dell’organico (fig 10) di un servizio sanitario. In fig 9 e riportata l’architettura del sistema RR. ´ L’analisi funzionale di questi requisiti sistema e semplificata da un diagramma del flusso dei dati (fig 8). 3. Autenticazione e download referti .2. 21 . file di risorse). Esportazione dei referti sul web : i referti pronti debbono essere pubblicati sul web. cio´ nella fase di progettae zione.2. In questo modo la definizione dei requi´ siti porta alla definizione dell’architettura e viceversa. librerie. eseguibili.5 Classificazione ´ I digrammi delle classi e degli oggetti sono tra i piu usati nelle metodologie basate sul linguaggio UML.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. Nella fase di raccolta e formalizzazione dei requisiti questi modelli sono spesso impiegati per fornire una rappresentazione razionale delle entit´ a coinvolte nel progetto e solo successivamente. Questi diagrammi possono venire usati in tutte le fasi del processo.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 prestazione devono essere preparate le credenziali di accesso dal web al referto relativo alla prestazione stessa.2.

encription e decription key Referto Referto Credenziali Prestazione RIS-DB RR-DB Download Utente del servizio Figura 8: Diagramma del flusso dei dati 22 . password.Tecnico diagnostica Export referti Criptazione dei referti Generazione user_name.

Gestione Prestazioni/credenziali DB-RR Gestione Referti Accesso agli utenti Figura 9: Architettura del sistema RR. 23 . Dipendente Nome Cognome IdDipendente Tecnico Diagnostica IDSala Medico Reparto referta() eseguiPrestazione() Radiologo refertaImmagine() Figura 10: Classificazione dell’organico.

La progettazione di un sistema informatico (software applicativo o sistema informativo) consiste nella definizione (chiara e precisa) della struttura statica e dinamica del sistema. La ricerca delle nuove entit´ e delle relazioni tra queste porta a alla definizione dei diagrammi concettuali e logici dei dati.3 La progettazione ´ Un sistema informatico e sempre caratterizzato da una sua struttura statica ´ ed una dinamica. cos quando ci si riferisce alla struttura statica di un sistema si devono intendere i componenti con cui 24 . Il concetto di struttura di un sistema rimane spesso oscuro e capita di impiegarlo in modo improprio o comunque ambiguo. 3. La struttura statica e descrivibile in termini di componenti hardware e di componenti software che sono disposti (schierati) nei ´ componenti hardware.Figura 11: Descrizione della struttura sanitaria.6 Modello dei dati Nella fase di analisi dei requisiti di sistema vengono normalmente anche analizzati i Database esistenti e delineate nuove entit´ che entrano in gioco a nel progetto. In figura 12 sono riportati gli schemi logici dei Database del RIS e di RR. mentre la struttura dinamica e l’organizzazione del sistema in termini di processi e scambio di dati durante l’esecuzione del programma. Questi possono venire rappresentati in termini di stereotopi UML. Il termine struttura deriva direttamente dal concetto di costruzione.2. 3.

25 .Figura 12: Schema logico dei Database.

con questo si a vuol sottolineare che l’attivit´ della progettazione ha lo scopo di anticipaa re. Dopo alcune considerazioni risulta che si dovr´ realizzare un complesso di strade per l’accesso alle abitazioni. guidare. ´ Per evitare questi scenari. 3. si parla in questo caso di sotto strutture. 10 palazzine da 12 interni e una schiera da villette a due piani mono-famigliari. ´ ´ In una situazione reale pero piu browser potrebbero connettersi allo stesso server e questi dovr´ implementare una strategia di parallelismo per gestire a le connessioni. imporre o suggerire la struttura di un sistema prima che questo venga costruito.1 L’architettura edilizia. nelle costruzioni civili si e soliti consultare degli architetti per definire un’architettura. le case potrebbero essere costruite lontano dalle strade e la pista ciclabile potrebbe essere un tratto asfaltato non collegato alle vie di comunicazione.3. Alcuni aspetti della dinamica di un sistema sono gi´ determinati dalla sua struttura (statica) altri invece sono definia ti solo a livello dinamico. E molto importante tenere in considerazione che possono esistere delle differenze importanti tra la struttura dinamica e quella statica. Spesso i componenti di un sistema hanno una propria struttura. 26 . E chiaro che durante l’esecuzione del sistema esister´ un istanza del web-server ed una del browser ed un traffico a di pacchetti TCP tra i due che si scambieranno dei messaggi e dei dati secondo il protocollo HTTP. ´ Un sistema informatico puo essere sviluppato senza nessun progetto ma esso avr´ sempre una propria struttura statica e dinamica. La struttura dinamica deve considerare i processi attivi durante l’esecuzio´ ne del sistema e la comunicazione tra questi. in altri termini progettare la struttura (statica) di un sistema significa pensare al sistema in termini di componenti che appunto lo compongono.´ questo e stato costruito e le relazioni strutturali tra di essi. Questi sanno raffigurare il lo scenario finale per mezzo di schemi progettuali che permettono di verificare la funzionalit´ dei progetti prima di realizzarli e di fornire gli schemi per la a messa in opera e la costruzione. 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. proiettare. La realizzazione di queste specifiche prive di una previa progettazione potrebbe essere assolutamente inutilizzabile. a le piste ciclabili ed un parco giochi per i bambini. prevedere. egli intende costruire 20 villette bi-famigliari. un paragone Si supponga che un costruttore disponendo di un certo capitale di investimento decida di realizzare un agglomerato ad uso residenziale.

3. ´ Dato : e un elemento di informazione trasferito tra componenti per mezzo di un connettore. ´ 3. Nella prima ipotesi e inutile distinguere vantaggi e svantaggi. non progettare per niente e assurdo. cio´ una e collezione di funzioni e propriet´ . ´ Una regola semplice e la seguente: progettare bene aiuta molto. Se si vuole analizzare una applicazione complessa scritta in linguaggio C. 3. L’etimologia non e chiarissima ma ´ sostanzialmente e l’unione delle parole αρχι e τ χνη cio´ inizio o prima e ´ ´ e arte. progettare male danneggia moltissimo.4 Componenti.2 Vantaggi e svantaggi della progettazione ´ Si puo decidere di progettare perch´ si ama farlo o perch´ lo si ritiene nee e ´ cessario. Nella seconda ipotesi. frustrante e mal retribuita e giusto a analizzare in maniera profonda l’effettiva necessit´ di farlo e quali sono i a vantaggi che ci si aspetta. Pensare l’architettura significa allora costruire prima con la mente o con dei modelli. questi saranno visti come componenti mentre la loro scomposizione funzionale rimarr´ nascosta e non parteciper´ alla a a 27 .4. o direttamente una funzione. il senso piu accreditato e quello di ci´ che viene prima della costruzione. connettori e dati ´ Il termine architettura deriva dal greco. intesa anche come costruzione. in ´ quanto si sa che l’amore e cieco. visto che la pro´ ´ gettazione e un attivit´ dispendiosa. Il concetto di compoe ´ ´ nente e stato pero esteso nel senso visto sopra. cio´ la proiezione dell’opera avanti nel o e tempo o meglio il progetto.3. Se si sta analizzando un complesso sistema distribuito in cui prendono parte anche alcuni eseguibili C. ´ un componente puo essere un modulo che espone un interfaccia. Gli elementi di base usati nell’architettura del software sono: ´ ´ Componente : e un unit´ software astratta o reale che puo avere uno stato a interno e agisce sui dati trasformandoli. ´ Connettore : e un meccanismo astratto per la comunicazione tra i componenti. a Il significato che attribuiamo alla categoria componente dipende fortemente dal contesto e dal grado di astrazione dell’analisi. 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.1 I componenti Un tempo la categoria di componente era limitata a unit´ fisiche software a cio´ sostanzialmente a oggetti gestibili dal filesystem.

Compilatore Ottimizzatore Analizzatore semantico Generatore di codice Analizzatore sintattico Analizzatore lessicale Repository Albero sintattico Tabella dei simboli Editor Editor sintattico Debugger Figura 13: Organizzazione a repository di un ambiente di sviluppo.´ definizione dell’architettura. ´ Chiamata a procedura remota (RPC) : e un servizio (middleware) che consente lo scambio di dati tra componenti distribuiti su una rete in maniera analoga alla chiamata a funzione. Flussi (stream) : sono impiegati per il trasferimento di grosse moli di dati. Il tipo di ´ messaggio e normalmente asimmetrico. Le pipe UNIX e le socket TCP/UDP sono esempi di connettori a flusso.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. 3. 28 . Eventi : gli eventi sono un esempio di comunicazione asicrona. in questa prospettiva una funzione C non e un componente.

la progettazione dell’architettura di un sistema consiste nel descrivere detto sistema in termini di sottosistemi e delle relazioni ´ tra questi. L’innovazione e ben accetta quando a porta a risultati migliori o a soluzioni non percorribili con le architetture note. scomposizione e controllo ´ a Come si e gi´ precisato. Dal punto di vista ingegneristico e molto importante poter identificare l’architettura di un sistema a partire da uno stile architetturale noto. Ovviamente i componenti dovranno comuı 5 Questa esigenza risulta chiara se si pensa che l’ingegnere ha come obiettivo non la crea´ tivit´ ma il produrre un risultato solido ed affidabile. L’organizzazione allora si riferisce alla scelta dei componenti e dei connettori per la comunicazione tra i sottosistemi. 3. 29 . 5 Lo stile architetturale e definito a partire dall’organizzazione. 3. scomposizio´ ne modulare e dal modo di controllo del sistema.5.Software Server Kernel Figura 14: Semplificazione di un architettura a microkernel.5 Organizzazione. ´ Organizzazione a Repository (Database condiviso) : il sistema e composto da diversi moduli che lavorano su un Database condiviso. la co´ municazione tra i componenti e mediata dal DB e i componenti risultano cos´ disaccoppiati.1 Organizzazione ´ Si puo parlare di stile di organizzazione di un software quando questo raggiunge una certa complessit´ tale da poter considerare il sistema come coma posto da diversi sottosistemi.

cos´ un sistema puo essere sia a ı repositiry che client-server. Modello stratificato : questo stile di organizzazione si pone come obiettivo di nascondere i componenti in strati isolati e di definire dei li´ velli gerarchici per la comunicazione tra di essi. Un esempio di software sviluppato secondo questo stile sono i sistemi operativi a microkernel 3. Il modello che deriva da questa fase differisce dal primo in quanto il progettista st´ gi´ considerando la scomposizione in componenti dal punto di a a ´ vista tecnologico in termini di componenti e connettori e non piu solo come macro contenitori di funzionalit´ . 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 complessi si ha spesso la presenza di diversi stili di organizzazione che colla´ borano alla definizione del sistema. La scomposizione in moduli. a Al termine di questa fase i componenti individuati vengono scomposti in ulteriori moduli.5.nicare con il componente Database. 3. Nell’organizzazione client-server alcuni componenti detti server espongono dei servizi che vengono consumati dai client. I componenti si connettono per mezzo di RPC o di stream. o modularizzazione ha lo scopo di meglio organizzare i requisiti di sistema (specie non funzionali) e di ´ fornire agli sviluppatori un progetto piu semplice da seguire e da suddividere tra il team di sviluppo. ´ ´ L’architettura Client-server puo essere stratificata in piu livelli e orami si parla di architetture distribuite. Affich´ si e ´ possa parlare di sistema e necessario che tali componenti collaborino per 30 .3 Controllo ´ Un sistema software e composto da un insieme di componenti. ´ In base al paradigma di sviluppo che si e scelto per il progetto la scomposizione modulare consister´ in una scomposizione orientata alle classi e alla a tipizzazione o in una scomposizione orientata alle funzioni.5. ma a questo livello questa comu´ nicazione e vista come un dettaglio. E una conseguenza diretta della programmazione bottom-top.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 componente.

Se tutta la logica di controllo viene accentrata all’interno di un singolo com´ ponente si parla di controllo centralizzato. Vista di schieramento : mostra i nodi principali del sistema e la distribuzione dei componenti sui nodi. 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. 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. a ´ La linea guida per produrre un modello ed un progetto puo essere quella noto come le 4 viste + 1.ottenere un certo comportamento o risultato. 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 eseguire dei compiti specifici. collaborazione. 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. I sistemi guidati da eventi come i sistemi basati su un interfaccia grafica sono invece normalmente sistemi decentralizzati. attivit´ . 6I 31 . quando invece il controllo e suddiviso tra i vari componenti il controllo e decentralizzato. Vista development : i package in cui sono raggruppate le classi del progetto. il progetto invece serve agli sviluppatori come traccia e guida nell’attivit´ di sviluppo. staa to e temporizzazione che descrivono il comportamento del sistema in termini di istanze degli oggetti e flusso dei dati durante l’esecuzione. 3. modelli di sistema aiutano queste verifiche ma alla pratica in assenza di un qualche ´ prototipo e ben difficile eseguire queste valutazioni.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 conformit´ ai requisiti (funzionali e non funzionali) prima a che il sistema sia sviluppato6 .

cio´ la proe duzione delle credenziali per l’accesso dal web e la produzione delle immagini della prestazione devono essere possibili da ogni diagnostica. 9). sicurezza. ´ La vista logica dei componenti per il progetto ReadyReport e riportata in 32 . Lo stesso ragionamento si applica alla gestione dei referti. Quando i componenti e le classi sono stati individuati si cerca di descriverne il loro comportamento in fase di esecuzione del sistema e si passa quindi alla vista del processo. La vista di schieramento (deployment) mostra come i vari componenti sa´ ranno distribuiti sui nodi del sistema. affidabilit´ .7 Le viste di ReadyReport Analizzando lo schema architetturale del sistema ReadyReport e collegandolo all’analisi dei requisiti risulta che i tre moduli principali dovranno essere organizzati come client-server. performance e sicurezza a del sistema. 3. A partire da questo modello si identificano i principali componenti del sistema. Normalmente il processo di progettazione prende il la dal modello architetturale che viene definito durante l’analisi dei requisiti (fig. Questa vista e fondamentale per rendersi conto delle caratteristiche di scalabilit´ . Il modo ´ ´ piu semplice per ottenere questo requisito non funzionale e che questo modulo sia organizzato come un client server. ma non sarebbe sbagliato comunque anche far precedere questa vista a quella logica. Il suo scopo e di collegare le altre viste in un ottica di casi d’uso. Il progettista analizza i moduli individuati nella fase dei requisiti e comincia ad ipotizzare uno stile organizzativo. Dal momento che la politica di gestione degli accessi per i due moduli sar´ sostanzialmente la stessa si decide di accorpare i due componenti a in un’ unica web application. quindi e normale partire con una vista logica. L’organizzazione delle classi in package ha lo scopo di rendere ´ piu semplice l’attivit´ di sviluppo e di riutilizzo del codice. di controllo e di modularizzazione per il sistema. scalabilit´ e deploya a ment. La scelta ricade sullo sviluppo di una web application. 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. questa vista a viene prodotto di norma quando sono gi´ state individuate le classi del a sistema. ´ Il primo diagramma che viene prodotto e normalmente un diagramma che descriva i componenti principali quindi le classi che costituiscono questi ´ componenti. ´ ´ La quinta vista e normalmente meno formale.´ Il linguaggio di elezione per la produzione di questi diagrammi e l’UML. La gestione dei pazienti. Spesso la suddivisione in macro componenti individuate nella ´ fase di ingegneria dei requisiti non e rispettata nella fase di progettazione.

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. Figura 15: Vista logica del progetto RR 33 . 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 passati dalle pagine HTML alla servelt per il parametro op che stabilisce quale azione debba essere intrapresa dalla servlet. La comunicazione ´ tra le pagine jsp e la servelt avviene secondo una logica MVC. 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. Le pagine HTML caricate sul browser sono generate dinamicamente dalle pagine jsp. Dalla figura 15 si deduce che il la web-application ReadyReport comunica con la Diagnostica per mezzo di un’architettura a repository.figura 15. L’insieme di queste pagine costituisce i due componenti CredenzialiUtente ed ExportReferti.

diagramma delle classi. 34 .Figura 16: Vista logica del progetto RR.

35 .Figura 17: Vista di development (packeging).

36 . dettaglio di una sequenza.Figura 18: Vista del processo.

Figura 19: Vista di schieramento. 37 .

a Si consideri per esempio lo sviluppo di un Codec. Ipotizzando che nella fase dei requisiti questi siano stati analizzati con completezza e correttamente. 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 risulta che questo non soddisfa i requisiti attesi.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 modalit´ di funzionamento. sono a cio´ delle specie di scatole nere che espletano una ben determinata funzioe ´ ne all’interno di un piu generico processo. ´ In molti casi si ha che la fase dei requisiti e condotta solo approssimativamente e quella di progettazione manca completamente. 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 basandosi sul progetto prodotto nella fase precedente implementano le funzionalit´ ed i requisiti di sistema basandosi sulle specifiche raccolte e fora malizzare nella fase di ingegneria dei requisiti. che nella fase di progettazione si sia delineato correttamente il modello del sistema ed il progetto. La domanda a cui si cerca di ´ rispondere e cosa accada in questi casi. Un soft´ ware mal progettato se funziona e solo per pura fortuna e la fortuna nella ´ scienza non esiste. Questi casi non sono neanche presi in considerazione in questo ragionamento. Con ´ queste premesse e normale che chi richiede il software sia ben concentrato nel comunicare con gli analisti ed abbia la percezione della criticit´ dei a requisiti. segue per logica che la fase di sviluppo. ´ a Quando questi software vengono richiesti il loro ruolo e gi´ ben determinato ed altri componenti dipendono dalla risposta funzionale di questi. 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.4 Sviluppo Lo sviluppo del software consiste nella produzione di codice sorgente e nella successiva compilazione e debug. di un Driver o anche di una rete neurale per il Pattern Recogniction. Questi software possono avere un grado alto di complessit´ ma hanno una caratteristica importante. ´ Purtroppo questo sillogismo e verificato in una bassa percentuale di casi. debba portare ad una fase di verifica e quindi completamento del progetto. se condotta correttamente. Il committente avr´ premura di verificare di essere capito correta tamente e di controllare che tutte le parti del sistema comunichino tra loro 38 . 4.

capita allora che l’informatizzazione modifichi i requisiti del sistea ma. Questo si puo ottenere mirando alla progettazione e allo sviluppo di un prototipo anzich´ del prodotto finale.correttamente senza voli di fantasia.2 Requisiti dinamici Alcuni progetti software nascono in capo ai committenti per rendere automatici dei processi controllati da operatori umani. dall’altro questo sembra essere al momento l’unico approccio (ma ben ´ vengano altri!) funzionante. ´ Il vantaggio del prototipo e che questo viene sviluppato in tempi rapidi rinunciando solitamente ad uno sviluppo curato e sicuro scendendo quindi 39 . Nella pratica reale dell’ingegneria del software il tipo si retroazione dei sistemi si risolve sempre in retroazione negativa e questo significa che dopo un certo numero di volte che i requisiti vengono raccolti. ´ ´ Se da un lato ripetere l’intero processo di sviluppo piu volte e poco efficiente.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. L’informatizzazione delle singole fasi ´ ´ puo portare pero a a dover richiedere nuovi vincoli o ad offrire nuove possibilit´ . ´ Il processo di automazione procede spesso (e questo e naturale) attraverso la automazione delle singole fasi.2. 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 difficolt´ quando si cerchi di separare rigorosaa mente la fase dei requisiti da quelle della progettazione e dello sviluppo. Spesso le fasi precise di questi processi non rispondono a dei principi rigorosi ma sono solo scelte di compromesso dovute anche alle varie limitazioni del controllo umano sul processo. e ´ Lo scopo del prototipo e quello di innescare il meccanismo di retroazione del sistema in modo da poterne seguire l’evoluzione dei requisiti. ´ Il processo di sviluppo di un tale tipo di sistema e sostanzialmente un sistema in retroazione. che si rivedono i progetti e si torna allo sviluppo il sistema tende a diventare stabile e si converge alla soluzione voluta. Per evitare pero di rendere eccessivamente co´ stosi (e noiosi) certi progetti si puo ricorrere alla tecnica della progettazione per prototipi. 4. I progetti condotti in queste condizioni possono seguire la sequenza Analisi → Progettazione → Sviluppo → Verifica con successo. 4. ´ Questa possibilit´ non e affatto un caso limite ma anzi succede con una a frequenza significativa.

anzi spesso il processo viene documentato chiaramente per la prima volta proprio durante la sua informatizzazione. ´ Questo approccio pero si rivela inadatto gi´ alle prime verifiche sul campo a ´ in quanto il referto scaricato dal web non puo essere firmato manualmente dal medico. Il referto ´ non viene piu archiviato nel DB ma direttamente come file PDF. a ´ Affinch´ questo approccio sia conveniente e necessario alleggerire anche la e ´ fase della progettazione. anzi progettare molto ma realizzare subito quanto progettato.2 Esempio pratico Ilprogetto ReadyReport (RR) nasce per offrire il servizio di ritiro dei referti radiologici via web. In altri termini si tratta spesso di progetti rivolti all’informatizzazione di processi complessi di cui non esiste una documentazione chiara. Prima dell’introduzione del RR i referti venivano archiviati in formato testuale in un DB relazionale.3 Requisiti complessi ´ Nei paragrafi precedenti si e analizzata la difficolt´ intrinseche nei progetti a i cui requisiti vengono influenzati dalla informatizzazione. poi stampati e firmati manualmente dal medico refertante. 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 analizzare e chiarire.a compromessi sulla qualit´ del software. La procedura di export deve essere completamente rivista. Si decide allora di modificare la procedura di refertazione esistente imponendo ai medici di firmare il referto con la propria SmartCard. Questo non significa non progettare. Seguendo lo sviluppo per prototipi la produzione delle quattro viste ad ogni ciclo diventa eccessivo. 4. ´ ´ Un approccio che si e rivelato piuttosto efficiente in questi casi e quello del40 . Per evitare di dover riscrivere interamente il codice al termine dei cicli a ´ di sviluppo si puo ricorrere alla tecnica di refactoring che consiste nel dedicare con costanza qualche ora alla settimana al rivedere il codice scritto in precedenza per renderlo adeguato alla produzione. Gli analisti ed i progettisti di RR dopo aver analizzato il processo di refertazione esistente lo replicano sul RR e definiscono la procedura di export dei referti basandosi sul referto testuale presente sul DB.2. Nella pratica si e dimostrato che un buon approccio alla protitipizzazione sia ha cercando di unificare la fase di progettazione e di sviluppo. Al termine dei cicli di retroazione. cio´ quando i requisiti si stabilizzano die venta fondamentale riscrivere il codice secondo le regole della buona qualit´ . 4.

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

´ Collaborazioni : eventuali altri pattern a cui il pattern puo essere associato. classi e componenti) che compongono la a soluzione. 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. L’idea alla base di questa metodologia e quella di far crescere il software per funzionalit´ . esattamente come accade nell’ingegneria civile. 20) ´ ´ Il razionale di questo approccio non e immediato ma e molto importante. via via che queste vengono chiarite a nel rapporto con gli stackholder (fig. 42 . Questi potrebbero essere raccolti in forma completa e definitiva prima di iniziare la fase di progettazione e quindi di sviluppo. completa di tutte le viste e diagrammi necessari per la sua comprensione. 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. L’idea dei design pattern nasce direttamente dall’architettura civile dove se ne fa comunemente uso. a Contesto : una descrizione chiara e breve del contesto applicativo in cui si sono dimostrati utili e in cui sono stati realmente applicati. 5 I Design Pattern ´ Un Design Pattern e un modello architetturale ben definito per ottenere un preciso risultato. ´ Uno dei vantaggi dei design pattern e che costituiscono una piattaforma comune di dialogo tra progettista e sviluppatore. Partecipanti : le entit´ (oggetti. Esigenza o problema : la descrizione dell’esigenza e o problema che il pattern assolve (risolve). ´ L’ostacolo principale in questi progetti e ovviamente la raccolta dei requisiti. allora perch´ si proe ´ fessa lo sviluppo evolutivo? La risposta e un po’ psicologica. Si pensi ad esempio alla necessit´ di introdurre un a accesso per persone deambulanti con carrozzina in una scuola. La risposta ´ moderna e l’inserimento di una rampa liscia a fianco delle scale. Caratteristiche e punti di forza : descrizione dei punti di forza della soluzione.´ lo sviluppo in evoluzione. I Design Pattern sono caratterizzati da: ´ Nome : il nome con cui il pattern e conosciuto nella comunit´ . Struttura : la descrizione architetturale della soluzione.

chiama i conseguenti metodi del model quindi rende accessibili ai viewer lo stato del model.1 Il pattern Mode View Controller (MVC) In questo paragrafo sar´ brevemente introdotto il pattern MVC. integrati o eliminati con estrema semplicit´ . • Gli elementi di interfaccia possono essere modificati. Caratteristiche e punti di forza : • Il flusso dei dati e delle operazioni risulta controllato principalmente da un unico componente. in questo modo diventa semplice verificare come il sistema regola il flusso dei dati.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. a Partecipanti : Model : Rappresenta i componenti e le classi che implementano il modello logico matematico del sistema. form o che dir si voglia). ´ Struttura : La struttura di base e delineata nel diagramma di figura 21.5. Controller : Riceve le notifiche degli eventi di interfaccia dai viewer. Collaborazioni : Questo pattern viene spesso associato nei sistemi ad eventi al pattern Observer. 43 . Esigenza o problema : Si desidera collocare il codice che implementa il modello logico matematico del sistema in uno strato diverso da quello dell’interfaccia utente . 5. Nome : Model View Controller. 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. Nel paa ragrafo successivo si analizzer´ la presenza di questo pattern all’interno a dell’architettura del progetto ReadyReport. Contesto : Si vuole sviluppare un’applicazione che prevede un’interfaccia grafica composta da diversi moduli (maschere.

.. XHTML.) necessari all’utente per il controllo dell’applicazione. 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. campi di testo ecc. Quando un server (Container o Application Server che dir si voglia) riceve una richiesta per una risorsa gestita da una data web application. eseguire dei conti ecc. In genere la a costruzioni consiste nella definizione incrementale di una stringa che rappresenta un documento HTML. 44 .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. Le elaborazioni eseguite dalla web application sono di norma parametrizzate ed i parametri sono quelli che giungono dalle pagine HTML protocollati nella request secondo il protocollo HTTP. ´ La risposta e tipicamente un contenuto visualizzabile su un web browser.. quindi tipicamente un contenuto HTML. La risposta viene creata dinamicamente dal codice e oltre ai dati che debbono essere visualizzati sul browser comprende anche il codice base per la visualizzazione dei controlli (liste. XML . Questo tipo di applicazioni si appoggiano quasi sempre a dei componen´ ti software server detti Container o Application Server. passa il controllo esecutivo alla applicazione rendendogli disponibili anche tutti i dati contenuti nella richiesta (Request) http giunta al server. bottoni. Durante l’elaborazione la web application costruisce via via la risposta (Response che sar´ inviata al client (per esempio un browser). La web application esegue le proprie elaborazioni come accedere ad un database.

In figura 23 e riportato una descrizione pittorica dei collegamenti tra le varie pegine web di una web application. Dal momento che i con- Home.2. trolli per la navigazione sono direttamente inseriti in ogni pagina creata si ´ ´ ha che lo stile di controllo e decentrato. 5.js p ModelloLogico produciListaPrestazioni() copiaImmaginiDalPacs() esportaRefertiSulWEB() produciListaWeb() ListaPrestazioni.jsp ListaPrestazioni.´ 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.jsp CopiaImmagini.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. 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.js p Figura 22: Relazioni tra i moduli di una web application e le pagine generate.js p CopiaImmagini. 22). tali collegamenti sottointendono nella realt´ il controllo della web a application.jsp Home. 45 . Dalle figure 22 e 23 si deduce che sebbene il modello logico sia definito nella classe ModelloLogico le sequenze di chiamate per eseguire le operazioni sul modello provengono direttamente dal codice di interfaccia. Ogni modulo e associato alla pagine web che produce in una relazione uno a uno (fig.

2 Il pattern MVC per il controllo delle web application Il controllo decentrato.jsp Figura 23: Collegamenti esistenti tra le pagine web generate dalla web application.jsp ListaPrestazioni. In base al valore del parametro op il Controller: 1.jsp ListaWeb.jsp Home. porta a seri problemi nella gestione della complessit´ apa plicativa. ottiene dal Model l’istanza di una classe che rappresenta una vista dello stato dell’applicazione (in Java si tratta spesso di javabeans) 3. esegue una serie di operazioni sul Model 2.jsp Export.Home. Rispetto all’architettura mostrata nelle figure 22 e 23 si tratta di inserire un nuovo elemento (tipicamente una classe) che svolger´ la funa zione di Controller (figura 24).jsp ListaWeb. reindirizza il controllo dell’output al modulo designato che normalmente avr´ direttamente accesso alla classe vista.jsp CopiaImmagini. 5. specie per applicazioni che contano un discreto numero di moduli. ´ 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 applicativo.jsp Export.jsp CopiaImmagini. a Un aspetto importante di questa architettura sono le citate viste. Queste sono classi che non implementano praticamente nessuna operazione particolare se non incapsulare nel proprio stato tutti i dati che determinano lo 46 .2. I controlli presenti nelle pagine HTML generate 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.jsp ListaPrestazioni.

47 . Queste classi sono prodotte dal ModelloLogico sotto sollecitazione del Controller e sono rese disponibili ai viewers (fig.jsp Export. In java queste classi sono tipicamente dei javabeans. Il contesto e corretto in quanto si sta sviluppando un sistema ´ che prevede una serie di pagine web come interfaccia. Si vedr´ ora di analizzare come il pattern MVC sia stato implementato ala l’interno del progetto.jsp ModelloLogico produciListaPrestazioni() copiaImmaginiDalPacs() esportaRefertiSulWEB() produciListaWeb() Figura 24: Introduzione del Controller. ´ ´ Infine si puo notare che nelle web application java il model e spesso realizzato come un EnterpriseJavaBean (EJB).3 Il pattern MVC in ReadyReport Nel progetto RR le due web application sono caratterizzate dall’utilizzo del ´ pattern MVC.jsp ListaWeb.jsp Export. per esempio i record di una tabella o per il progetto RR la lista delle prestazioni eseguite. Il problema e sentito in quanto si vuole centralizzare in un’unica classe per lo meno il codice che accede al DB. stato applicativo che deve essere mostrato dal viewer. 5.jsp <<Servlet>> Controller CopiaImmagini. I punti di forza non sono semplicemente attraenti ma rappresentano il vero motivo di questa scelta architetturale.ListaWeb. 25) per esempio ponendole visibili a livello di Session.jsp CopiaImmagini. ottenere una struttura del codice assolutamente chiare riguardo alla gestione del flusso dei dati e degli eventi.

Sebbene non sia necessario disporre Il componente AccessoDB nel container ´ che offre l’interfaccia HTTP alla web application.jsp CopiaImmagini.2 Controller ´ Il controller e stato implementato come una classe Servlet. si e deciso di sviluppare questo componente come un EJB (Enterprise Java Bean) e quindi di disporlo dentro un container per sfruttare i servizi che il container offre per la gestione delle transazioni. In particolare in questo coma 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.1 Il Model ´ Il Model per il progetto ReadyReport e implementato nel componente AccessoDB (figura 18). 5.3.jsp <<bean>> ListaWeb <<bean>> Risultato ModelloLogico produciListaPrestazioni() copiaImmaginiDalPacs() esportaRefertiSulWEB() produciListaWeb() <<Servlet>> Controller Figura 25: Il diagramma mostra la relazione tra i beans e le jsp. 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 insieme dei valori che sono passati dai viewer al controller per mezzo del parametro op. 5. cio´ una classe e Java che implementa l’interfaccia Servlet.jsp Export. 48 .ListaWeb.3. In questo componente sono presenti le classi che hanno la responsabilit´ di eseguire le operazioni sui dati.

intValue().if(op. getPerformanceList(idscanner.getParameter("nhc").forward(request.response). request. request.getParameter("fname"). request.setAttribute("performanceid".getParameter("idscanner"). } } else if(op. request.getServletContext().getParameter("name"). if(b) { request. new Integer( year). rd. }else if(op. .setAttribute("deployed".request.jsp").getServletContext(). logger.getParameter("performanceid").equalsIgnoreCase("plist")) { RequestDispatcher rd= 49 .getSession(). RequestDispatcher rd= this. request."").getParameter("NationalHealthNumber")).equalsIgnoreCase("performancelist")) { //Data String idscanner=request. if(idscanner=="")idscanner=request.setAttribute("performancelist". else request..message).getRequestDispatcher("/importadcm...response).forward(request.setAttribute("deployed".getParameter("performanceid")).b)."Operazione riuscita").jsp"). b=deployIndexedResource( request. request. rd. if(b) request. } else if(op."Operazione NON riuscita"). .getParameter("ids").debug("idscanner="+idscanner).equalsIgnoreCase("addresource")) { request.getRequestDispatcher("/importadcm.setAttribute("deployed".equalsIgnoreCase("addpatient")) { b=deployPatientResource(request.setAttribute("performanceid". request.getParameter("dicomid")). RequestDispatcher rd= this.setAttribute("message"..

50 .E importante notare che que´ sta interfaccia non definisce un vero tipo ma e solo un contratto tra i viewer ed il controller. In questa sezione si analizzeranno le metodiche attualmente accettate per la verifica del software. Efficienza : il software deve fare un uso razionale delle risorse del sistema..getRequestDispatcher("/performancelist. In genere con verifica si intende la fase in cui ci si accerta che il software ´ lavori come stabilito nelle specifiche. 6 Verifica e convalida La quarta fase del processo software consiste nella verifica e convalida dei requisiti funzionali e non funzionali. Per questo prima di rilasciare un software si procede anche con la fase di convalida in cui si verifica se le speci´ fiche implementate sono proprio cio che ci si attendeva. 5. Solidit´ (Robustezza) : il software deve gestire eventuali errori che si posa sono produrre nelle fasi di I/O e di processo dei dati evitando che il sistema ospitante (tipicamente un Sistema Operativo) debba interromperne l’ esecuzione..this.3 View I componenti viewer sono implementati come pagine jsp.forward(request.jsp"). Le specifiche sono pero solo una rappresentazione scritta delle aspettative di chi user´ il software e quindi poa trebbero (come gi´ ampiamente discusso nei paragrafi precedenti) differire a dalle reali esigenze dei committenti.3. 7 si dispone di un prodotto/prototipo le Al termine di una fase di sviluppo cui caratteristiche possono essere osservate e testate similmente a quanto si fa per un manufatto. performancelist. plist. In base al CASE attivato il controller chiama una operazione interna alla classe e da li vengono chiamati i metodi sul Model. e ´ addresource.response). rd. Le caratteristiche di ogni buon prodotto software devono essere: Correttezza : il software deve essere conforme alle specifiche definite nella fase dei requisiti. 7 Qui ´ si intende che lo sviluppo di un sistema puo avvenire in diverse fasi. Questi si interfacciano al controller tramite l’interfaccia lasca definita dall’insieme di valori definiti nello switch-case del controller cio´ le stringhe addpatient.getServletContext()..

´ Incapsulamento : in un progetto modulare e bene che le responsabilit´ a ´ del codice siano ben definite per ogni modulo. 6. Scelta dei linguaggi : la scelta del linguaggio con cui sviluppare il soft´ ware puo influenzare la capacit´ effettiva degli sviluppatori di proa durre codice corretto e robusto. a ´ ´ E bene notare che questo approccio di qualit´ non e in contrasto con la metoa dologia di sviluppo prototipale a patto che ad ogni ciclo di sviluppo segua una fase di refactoring8 . a ´ La fase di ispezione e verifica di un progetto e molto importante e se ben 8 Ristrutturazione razionale del codice sviluppato in fretta.1 Cominciare bene ´ La fase di verifica di un sistema puo essere lunga e difficile e spesso alcune difformit´ dai requisiti risultano solo dopo diverso tempo che il software a ´ a ´ e gi´ in esercizio. ´ Design by Contract : e una tecnica di programmazione che permette di evidenziare gli errori di design evitando di gestire alcuni tipi di eccezione e trattandoli invece come delle contraddizioni del design. Utilizzo di registri (log) : la fase di verifica e convalida continua anche ´ dopo il rilascio di un prodotto. 51 . Ogni contraddizione viene segnalata a chi testa il sistema mediante un qualche meccanismo (errori bloccanti o file di log).6. Impiegare a i design pattern evita di introdurre potenziali errori in un prodotto e velocizza le fasi di test in quanto le strutture del codice sono immediatamente riconoscibili. Per questo motivo e meglio condurre l’intero ciclo di sviluppo seguendo un principio di qualit´ e non riversare tutta la respona sabilit´ alla singola fase della verifica.2 Dopo la progettazione e dopo lo sviluppo ´ Se il progetto di un sistema e sufficientemente dettagliato e possibile analizzarlo per verificare se l’eventuale sistema che seguir´ il progetto (cio´ il a e risultato dello sviluppo) sar´ conforme ai requisiti e alle specifiche. Per questo e sempre bene che ad ogni sistema sia accompagnato un log (registro) che consenta di verificare la presenza di errori o problemi. Un esempio e l’uso dei meccanismi per la gestione dell’integrit´ referenziali dei dati sul a database. Un metodo per produrre codice di qualit´ e quello di seguire delle Best a Pratics: Utilizzo di pattern : l’utilizzo di design pattern consiste nell’impiegare degli schemi noti e gi´ testati per ottenere un dato risultato.

´ La fase di test e divisa in tre momenti: Sviluppo dei test : si decide quali funzionalit testare e come testarle.condotta permette di risparmiare molto tempo nelle successive fasi di verifica del prodotto (cio´ il sistema sviluppato). 52 .3 I test ´ La fase culminale del processo di verifica e di quello di convalida e la fase dei test. se invece il piano e incompleto la fase di test fornisce una falsa sensazione di tranquillit´ . Pertanto l’ispezione dei progetti il piu delle volte permette di verificare la presenza di errori evidenti di sistema ´ e architettonici ma piu difficilmente potr´ mettere in luce delle difformit´ a a dalle specifiche funzionali. ´ Lo sviluppo dei test e una fase critica. 6. e ´ 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. Buona parte della fase di verifica deve essere quindi condotta direttamente sul codice. 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. Principio di verifica : il principio o il metodo su cui si basa la verifica (stimolazione del sistema con input utente e verifica dell’output). a Tipicamente un documento di test dovr´ riportare le seguenti informazioni: a Funzionalit´ : la funzionalit´ (o il requisito di sistema) che si vuole testaa a tre. Descrizione dei test : descrizione dettagliata sulla modalit´ con cui sar´ a a eseguito il test. ´ La documentazione della fase di test e importante e costituisce un elemento fondamentale nella gestione della qualit´ del progetto. Dati in ingresso : insieme dei dati usati per il test Risultati attesi : risposta attesa dal sistema Risultati ottenuti : risposta ottenuta. In questa fase si verifica sperimentalmente se il sistema risponde agli input come ci si aspetta. Test : si testa sperimentalmente il sistema. Documentazione dei risultati (Repots) : si documentano i risultati dei test. a Un buon piano dei test deve portare alla verifica del 100% del codice e di tutti i possibili input del sistema.

In particolare sono a stati saltati alcuni argomenti importanti che per ragioni di tempo e di organizzazione non hanno trovato spazio all’interno di questa prima versione ´ del corso. Buona parte del lavoro dovr´ essere completata e limata.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. 53 . 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.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->