Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09
Il Sistema Pubblico di Connettività
un progetto innovativo per la P.A. e per il Paese
20 gennaio 08 - Facoltà di Ingegneria - Università Roma Tre
Laboratorio di Tecnologie del SW:
esperienza di collaborazione con
Amministrazioni e Imprese
nello sviluppo di applicazioni di eGovernment
Valeriano Sandrucci, Enrico Vicario
Laboratorio Tecnologie del Software
Dipartimento Sistemi e Informatica
Centro per la Comunicazione e Integrazione dei Media
Università di Firenze
{Sandrucci,Vicario}@dsi.unifi.it
www.dsi.unifi.it/~vicario
1/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Laboratorio di Tecnologie del SW
Ingegneria Informatica (inginf05)
 Facoltà di Ingegneria, Dipartimento di Sistemi e Informatica - DSI
 Media Integration and Communication Center - MICC

People: 3+6
 E.Vicario, G.Bucci, A.Fantechi
 V.Sandrucci, J.Baldanzi, J.Torrini, L.Carnevali, L.Ridi, I.Bicchierai

Aree di competenza
 Testing, verifica di correttezza, valutazione di performance e dependability
in sistemi concorrenti Real Time con requisiti safety-critical
 Metodi di ingegneria del SW: processi di sviluppo, architetture,
principi e schemi di progetto, tecnologie, modellazione

Rapporti col territorio
 Galileo Selex, FinMeccanica, Regione Toscana, Azienda Ospedaliera
Universitaria di Careggi, Provincia di Firenze, CNIPA
 una varietà di piccole imprese nel settore ICT e SW
2/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

La natura incrementale dell’e-government
Egovernment: use of Information and Communication Technologies
combined with organisational change and new skills in order to
improve public services, democratic processes and public policies
 “The Role of eGovernment for Europe's Future,” Communication from the
Commission to the Council, the European Economic and Social Committee,
and the Committee of Regions, Brussels, 26.9.2003

Criticità specifiche
 Disegno complessivo non prevedibile e comunque aperto:
non una applicazione ma un sistema,
accoppiato alla evoluzione dei servizi e delle politiche
 Necessità di sviluppo concorrente:
autonomia delle amministrazioni,
molteplicità di fornitori,
legacy
 Finanziamento

Per rendere sostenibile il processo occorre
capacità di cooperazione e evoluzione
 Interoperabilità, integrabilità, condivisione, riuso, manutenibilità
3/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Il ruolo del settore pubblico
La metafora del piano regolatore
 Non soluzioni specifiche ma linee guida
 Conciliare l’evoluzione autonoma
con una integrazione armonica

Necessità per il settore pubblico di mantenere
il governo della architettura di scala enterprise
 DK Ministry of Science, Technology and Innovation, “White Paper on
Government Enterprise Architecture in Denmark”, June 2003.
4/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Quadro di riferimento comune
Architettura
 interfacce di cooperazione tra i componenti,
schemi di interazione, standards e tecnologie usati nell’integrazione

Strumenti di metodo condivisi
 orientati a favorire uniformità nel processo di fornitura,
dalla formulazione del capitolato alla documentazione di riscontro,
al processo di collaudo e manutenzione

Processo di governance
 capace di sostenere la visione di insieme
e guidare la condivisione e l’evoluzione
5/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09




6/38
Partizionamento delle responsabilità
Design Pattern Observer
Architectural Pattern Publish&subscribe
CART
1/3: Architettura
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Architettura: partizionamento delle responsabilità
Sistemi informativi locali dei singoli enti coordinati
 Rispondono alla specifica missione di ciascun ente
 Dipendono solo marginalmente dalla integrazione
 L’impatto della loro integrazione deve essere proporzionale
Uni Fi
livello
condiviso
cooperazione
Comune X

7/38
ASL n
Infrastruttura finalizzata al supporto della cooperazione
 Costituito con l'obiettivo specifico di supportare la cooperazione
 Mantenuto sotto il controllo diretto della autorità di coordinamento
livello
locale
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

il pattern Observer
uno schema OOD
Disaccoppiamento e consistenza:
 subject ha una variabile di stato che deve essere osservata
da oggetti di vario tipo (observer_A e observer_B)


Prima soluzione: subject pubblica un metodo
con il quale observer può ottenere lo stato
Problema: observer deve aggiornare lo stato quando?
 Prima di farne uso!
 Ma potrebbe essere necessario osservare tutti i cambiamenti
• e.g. gli interessi su un conto corrente
8/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

il pattern Observer
inversione di responsabilità della notifica
attribuiamo al subject la responsabilità
di notificare agli observers che il suo stato è cambiato
(Inversione di responsabilità)
 Quando cambia il suo stato, subject invoca il metodo notify
 Notify invoca update su tutti gli observers
9/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

10/38
il pattern Observer
struttura
definisce una dipendenza uno-a-molti per cui quando un oggetto
modifica il suo stato tutti i suoi dipendenti ne ricevono notifica
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

il pattern Observer
inversione di responsabilità della sottoscrizione
Installazione dinamica con responsabilità a carico dell’observer
 Observer si registra su subject con attach/detach
 Subject notifica agli osservatori registrati con notify
 In ricezione del notify, observer invoca get_State
11/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Trasposizione architetturale: Publish & Subscribe
Publish & Subscribe (broker)
 Equivalente architetturale del pattern observer,
con analoga motivazione e struttura
12/38
CART: Cooperazione Applicativa della Regione Toscana
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Rete e nodi di calcolo

Componenti applicativi

Componenti middleware sul NAL

Interazione
13/38
 CRIC, NAL, SIL
 Xml su http
 Proxy applicativi,
Sole facade, frameworkCA
 Sun1 Application Server, repository
 Prevalente stile publish & subscribe
 Possibile “anche” la richiesta di servizio
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09



14/38
Strumenti di Metodo condivisi: 2/3
Buone pratiche di sviluppo
Processo di certificazione
(Pratiche di gestione del processo di fornitura)
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Documentazione del SW

Organizzazione delle componenti applicative

Documentazione delle interfacce
15/38
 Core diagrams di UML
 Rappresentazione in livelli di dettaglio
 Formato della documentazione
 Partizionamento e separazione delle responsabilità
 Schemi di progetto comunicabili e riusabili
 Architectural e design patterns
 Formati di scambio
 Implementazioni di riferimento aperte
 Strumenti di supporto al testing
Buone pratiche
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Processo di certificazione
Strumento di attuazione del quadro di riferimento
 Promuove requisiti metodologici e architetturali
al di là dei soli requisiti funzionali di ciascun componente

Requisiti di interoperabilità
 Proxy: garantire il corretto utilizzo delle funzionalità
della infrastruttura di cooperazione applicativa
 Proxy: creare condizioni che facilitino
l’integrazione di componenti SIL
 SIL: garantire il corretto funzionamento dei servizi
esposti verso la infrastruttura di cooperazione

Requisiti architetturali
 Creare elementi di coerenza tra applicazioni diverse
che facilitino l’integrazione e l’evoluzione

Requisiti di documentazione
 Abilitare la visione di insieme
16/38
Requisiti di interoperabilità: Interfaccia proxy - FrameworkCA
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Il proxy accede al framework CA
esclusivamente attraverso
la facciata standard (sole facade)
 invio messaggi, invocazione servizi
 costruzione di messaggi conformi alla busta e-Toscana
 lettura e cancellazione di messaggi
nel repository degli eventi del NAL
 propagazione di richieste a provider
di servizi dislocati sui SIL

Il proxy deve esporre funzionalità
che lo rendono monitorabile a livello sistemistico
 servizio che restituisce uno stato OK/Warning/Trouble

Il proxy deve tenere traccia del suo stato in un log xml
 periodicamente aggiornato dal proxy
 riporta dettagli sullo stato di funzionamento della applicazione
17/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Requisiti di interoperabilità: Interfaccia proxy - SIL
Documentazione statica dell’interfaccia
 Nello schema di cooperazione per eventi
• formato degli eventi in XMLSchema
con annotazione del significato dei singoli campi
• validazione degli eventi rispetto allo schema XML
con segnalazione delle incongruenze
 Nello schema di cooperazione per richieste di servizio
• Il proxy media la comunicazione
tra FCA e SIL fornitore del servizio

Documentazione dinamica dell’interfaccia
 Applicazione di test
• Testa le funzionalità implementate dal proxy
 Implementazione di riferimento
• esemplifica un possibile modo di interfacciamento del SIL verso il proxy
• distribuita come codice aperto
18/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Il SIL ha la responsabilità di definire
l’interfaccia di eventuali servizi esposti
verso l’infrastruttura di cooperazione


19/38
Requisiti di interoperabilità: Sistemi Informativi Locali
formato della richiesta di servizio
(RichiestaServizioData.xml)
formato dei messaggi di risposta
(documentato attraverso XMLSchema
con annotazione del significato dei campi)
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Requisiti architetturali: Proxy applicativi
Modello di cooperazione
 Prevalente uso dello schema
di cooperazione per eventi
 Ammessa cooperazione per richiesta di servizio
 Evoluzione orientata verso schema ad eventi

Separazione delle responsabilità
 interfaccia verso il SIL
logica di dominio
interfaccia verso FCA
 Architettura interna
per logiche di dominio complesse
 Riduzione delle dipendenze
attraverso interfacce documentate
e organizzazione in packages dei moduli
20/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Requisiti di documentazione: proxy
Documentazione del sw
 Diagrammi dei casi di uso per funzionalità esposte
 Diagrammi di interazione per scenari operativi significativi
 Diagrammi delle classi e dei packages
• Descrizione di eventuali
schemi di progetto caratterizzanti
 Schemi ER o UML-DataModelingProfile
di eventuali tabelle su database

Caratteristiche della documentazione
 Rappresentazione su diversi livelli di dettaglio
 Documentazione non incrementale
 Identificativo di associazione tra sw e documentazione

21/38
Punto di vista del progettista
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Requisiti di documentazione: proxy
Documentazione di installazione,
configurazione ed esercizio
 Configurazione dell’application server
S1AS e eventuali altri requisiti
 Procedura di installazione e deploy
del proxy e delle applicazioni di test
 Manuale di gestione e manutenzione
in esercizio del proxy
 Caratterizzazione qualitativa del carico offerto
• Tipologia, distribuzione temporale e quantità dei flussi

22/38
Punto di vista dell’amministratore
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

(Pratiche di gestione del processo di fornitura)
Metodologia del processo di fornitura
 insieme organico di buone pratiche dal bando al collaudo
 definizione degli artefatti che devono accompagnare lo sviluppo,
 formalismi e linee guida metodologiche nella produzione della
documentazione di riscontro nella formalizzazione dei requisiti e nella
documentazione delle soluzioni adottate
 pratiche dei test interni documentati al rilascio
 pratiche della fase di collaudo e dispiegamento delle applicazioni realizzate.

Approccio





23/38
Analisi delle pratiche correnti presso RT,CNIPA e altri Enti
Definizione e sperimentazione in casi pilota
Standardizzazione,
Diffusione e formazione verso Enti e Fornitori
Esperienza nella commissione di collaudo di CG-SICA
 Gerardo Canfora (Università del Sannio), Giuseppe di Battista (Università di
Roma 3), Enrico Vicario Università di Firenze, Valter Antonelli (CNIPA), Mario
Terranova (CNIPA) +
Claudio Bortone (CNIPA), Alfio Raia (CNIPA), Stefano Fuligni (CNIPA),
Francesco Tortorelli (CNIPA)
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09


24/38
Requests For Commments – RFC
(Indicizzazione semantica)
Processo di Governance: 3/3
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Il metodo dei Requests For Comments (RFC)
Governo di un impianto di cooperazione applicativa P&S
 standardizzazione dei tracciati dei messaggi informativi veicolati
 gestione delle autorizzazioni nelle sottoscrizioni

Esiste un punto di controllo e gestione tecnica centralizzato
 tra i maggiori pregi dell’architettura.

Necessario cmq un processo di consenso tra portatori di interesse
 Pubbliche Amministrazioni dei diversi livelli, fornitori, utenti finali stessi

Processo RFC (Request For Comments)
 riproduce il ben noto meccanismo di standardizzazione su Internet
(http://it.wikipedia.org/wiki/Request_for_Comments)
 supporta a livello organizzativo e tecnico la partecipazione di soggetti diversi
nella standardizzazione di eventi e tracciati informativi

Attuatori
 Comitato eToscana, Centro Tecnico, partecipanti ai singoli standards
25/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09
26/38
eToscana compliance
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

RFC infrastrutturali e applicative
RFC applicative
 Definiscono standards sull’uso dell’infrastruttura in un dominio applicativo
 RFC81 - COMET: Ciclo di vita delle sperimentazioni cliniche

RFC Infrastrutturali
 Definiscono standards legati alla infrastruttura e al suo governo
 RFC17 – struttura di una RFC applicativa
27/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09
28/38
RFC81: sperimentazioni cliniche
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09
29/38
RFC17: RFC Applicativo e.Toscana
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Dalle RFC al sistema-delle-RFC
Oltre 100 RFC standardizzate o in via di standardizzazione
 Complessità di ricerca e garanzia di consistenza
30/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Sistema di indicizzazione semantica
Annotare i tracciati rispetto a modelli ontologici
 In principio possibile sostituire XSD con ontologie
 Non conveniente per ragioni di pratica e legacy

Casi d’uso abilitati
 verificare se una nuova RFC
è consistente rispetto all’insieme
di quelle che la precedono
 ricerca di una o più RFC
che insistono su un concetto,
ad esempio per identificare l’insieme dei tracciati impattati da una modifica;
 costruzione di filtri capaci di verificare la consistenza semantica dei contenuti
di messaggi scambiati sul CART (prospettiva di sperimentazione).

31/38
Possibile integrazione con catalogo schemi e ontologie in CG-SICA
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Un caso applicativo
Gestione delle sperimentazioni cliniche
 Processo interno ad un Centro di Sperimentazione
 Cooperazione con i sistemi informativi Ragionale e Nazionale



32/38
Problema delle procedure
Architettura di workflow management
Cooperazione
Un caso di cooperazione
applicazione di gestione delle sperimentazioni cliniche
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Un progetto della Azienda Ospedaliera Universitaria Careggi (AOUC)
 sostenuto da RT nell'ambito di DGR 788/2006 –
 Migliorare e potenziare i settori preposti alla ricerca biomedica,
 in particolare il Comitato Etico per la sperimentazione clinica dei medicinali

Sottoprogetto
 Automazione della gestione del flusso delle attività
nel processo di sperimentazione clinica

People:
 Daniela Matarrese, Lorenzo Bartoli, Cristina Berdondini, Riccardo Sforza
 Pierangelo Geppetti, Alessandro Mugelli, Silvia Benemei, Michele Vietri
 Enrico Vicario, Fabrizio Baldini, Graziella Magnolfi, Jacopo Baldanzi,
Valeriano Sandrucci
33/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Esiti e sviluppi
In uso presso AOUCareggi
 Richiesta da vari altri Centri di Sperimentazione in Toscana
 Un caso di successo
 Un centinaio di centri di sperimentazione in Italia (11 solo in Toscana)

Sviluppi
 Integrazione con anagrafe pazienti, estensione al profilo scientifico
 Integrazione con AIFA
• Il problema del doppio debito informativo

I soggetti coinvolti nell’integrazione con AIFA
 AIFA (Ministero Affari Sociali)
• CINECA
 CNIPA
 Regione Toscana
• Azienda Ospedaliera Universitaria di Careggi
• Stlab.unifi
34/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09
XML - comunicazione COMET
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<NotificaRichiestaAutorizzazioneSperimentazione xmlns="http://regione.toscana.it/sanita/comet/">
<IdUniversale>AOUCMonocentrica1227116844281</IdUniversale>
<SIL_Mittente>SPCAslTest_SPCRegioneToscana_SPCSISComet_SIL_F</SIL_Mittente>
<DataPubblicazione>2008-11-19+01:00</DataPubblicazione>
<CodiceSperimentazione>AOUCMonocentrica</CodiceSperimentazione>
<StrutturaSperimentazione>
<Pubblica tipoStruttura="AOU">
<Codice>090903</Codice>
<Descrizione>Azienda Ospedaliera Universitaria Careggi</Descrizione>
</Pubblica>
</StrutturaSperimentazione>
<Organizzazione>
<Codice>7</Codice>
<Descrizione>Gianfranco Gensini</Descrizione>
</Organizzazione>
<OggettoSperimentazione>DANTE
Dual ANtiplatelet therapy Tailored on the Extent of platelet inhibition</OggettoSperimentazione>
<ComitatoSperimentazione>COMITATO ETICO PER LA SPERIMENTAZIONE CLINICA DEI MEDICINALI
DELL'AZIENDA OSPEDALIERO-UNIVERSITARIA CAREGGI DI FIRENZE</ComitatoSperimentazione>
<SperimentazioneClinica tipoSperimentazioneClinica="Farmacologica">
<ClassificazioneFarmaco/>
<Farmaco>
<Descrizione>clopidogrel</Descrizione>
<ATC5>B01AC04</ATC5>
</Farmaco>
</SperimentazioneClinica>
<Modalita>Monocentrica</Modalita>
<Fase>III: pazienti (molti)</Fase>
<Ambito></Ambito>
<Destinatari>
<Sesso>
<Maschi>true</Maschi>
<Femmine>true</Femmine>
</Sesso>
<Eta>
<Adulti_da_18_a_44>true</Adulti_da_18_a_44>
</Eta>
</Destinatari>
<DisegnoStudio tipoDisegnoStudio="Random">
<Aperto-Cieco>Aperto</Aperto-Cieco>
<Controllo>Si</Controllo>
</DisegnoStudio>
<Placebo>No</Placebo>
<OrganizzazionePromotore>No profit</OrganizzazionePromotore>
</NotificaRichiestaAutorizzazioneSperimentazione>
35/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Passi
 flusso AIFA
(D.Min.Sett.08)
 applicazione di ricezione
con interfaccia applicativa
 Registrazione CG-SICA
(accordo di servizio +
modello ontologico)
 Estensione del flusso
regionale COMET
per includere flusso AIFA
(nuova RFC)
 Estensione applicazione
gestione sperimentazioni
cliniche
 Gateway CART/AIFA
tramite CG-SICA
36/38
Architettura di integrazione
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Ricadute
Integrazione tra Centro Sperimentazione Clinica e AIFA via CG-SICA
 Applicabile a un centinaio di centri di sperimentazione clinica

Sperimentazione di uso del CG-SICA
 Accordo di servizio
 Catalogo delle ontologie
 Porta di dominio

Sperimentazione di una soluzione di integrazione CART/CG-SICA
 Un gateway attestato sul CART agisce da sostituto
nell’assolvimento del debito informativo verso AIFA
 Sperimentazione di trasferimento da catalogo RFC-eToscana
a modelli ontologici su CG-SICA
 Valorizza l’architettura CART
 La integra con CG-SICA
37/38
Enrico Vicario – www.dsi.unifi.it/~vicario
SPC – Roma3 - Gen.09

Circa l’astrazione e la concretezza
 - Ma qual’è la pietra che sostiene il ponte?
- Il ponte non è sostenuto da questa o quella pietra,
ma dalla linea dell’arco che esse formano.
- Perché mi parli delle pietre?
E’ solo dell’arco che m’importa.
- Senza pietre non c’è arco.
Italo Calvino, Le città invisibili.

Di cosa parliamo?
 Strumenti e metodi di ingegneria del SW, Architetture SW,
Cooperazione applicativa, UML, Java, Tecnologie
Reti di calcolatori, Sicurezza, Telematica,
Pratica del collaudo, Metodi di testing, Gestione dei contratti,
…
38/38
Conclusioni