Enrico Vicario – vicario SPC – Roma3 - Gen.09 1/38 Il Sistema Pubblico di Connettività un...

Enrico Vicario – www.dsi.unifi.it/~vicarioSPC – Roma3 - Gen.09

1/38

Il Sistema Pubblico di Connettività un progetto innovativo per la P.A. e per il Paese

Laboratorio di Tecnologie del SW:esperienza di collaborazione con

Amministrazioni e Impresenello sviluppo di applicazioni di eGovernment

Valeriano Sandrucci, Enrico VicarioLaboratorio Tecnologie del Software

Dipartimento Sistemi e InformaticaCentro per la Comunicazione e Integrazione dei Media

Università di Firenze

{Sandrucci,Vicario}@dsi.unifi.itwww.dsi.unifi.it/~vicario

20 gennaio 08 - Facoltà di Ingegneria - Università Roma Tre


2/38

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


3/38

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à


4/38

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.

Il ruolo del settore pubblico


5/38

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


6/38

1/3: Architettura

Partizionamento delle responsabilità Design Pattern Observer Architectural Pattern Publish&subscribe CART


7/38

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

Infrastruttura finalizzata al supporto della cooperazione Costituito con l'obiettivo specifico di supportare la cooperazione Mantenuto sotto il controllo diretto della autorità di coordinamento

Architettura: partizionamento delle responsabilità

Comune X

Uni Fi

ASL n

cooperazionelivellolocale

livellocondiviso


8/38

il pattern Observeruno 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


9/38

il pattern Observerinversione 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


10/38

il pattern Observerstruttura

definisce una dipendenza uno-a-molti per cui quando un oggetto modifica il suo stato tutti i suoi dipendenti ne ricevono notifica


11/38

il pattern Observerinversione 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


12/38

Trasposizione architetturale: Publish & Subscribe

Publish & Subscribe (broker) Equivalente architetturale del pattern observer,

con analoga motivazione e struttura


13/38

CART: Cooperazione Applicativa della Regione Toscana

Rete e nodi di calcolo CRIC, NAL, SIL Xml su http

Componenti applicativi Proxy applicativi,

Sole facade, frameworkCA

Componenti middleware sul NAL Sun1 Application Server, repository

Interazione Prevalente stile publish & subscribe Possibile “anche” la richiesta di servizio


14/38

Strumenti di Metodo condivisi: 2/3

Buone pratiche di sviluppo Processo di certificazione (Pratiche di gestione del processo di fornitura)


15/38

Documentazione del SW Core diagrams di UML Rappresentazione in livelli di dettaglio Formato della documentazione

Organizzazione delle componenti applicative Partizionamento e separazione delle responsabilità Schemi di progetto comunicabili e riusabili Architectural e design patterns

Documentazione delle interfacce Formati di scambio Implementazioni di riferimento aperte Strumenti di supporto al testing

Buone pratiche


16/38

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


17/38

Requisiti di interoperabilità: Interfaccia proxy - FrameworkCA

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


18/38

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 XMLcon 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


19/38

Requisiti di interoperabilità: Sistemi Informativi Locali

Il SIL ha la responsabilità di definire l’interfaccia di eventuali servizi esposti verso l’infrastruttura di cooperazione

formato della richiesta di servizio(RichiestaServizioData.xml)

formato dei messaggi di risposta (documentato attraverso XMLSchemacon annotazione del significato dei campi)


20/38

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 dominiointerfaccia verso FCA

Architettura interna per logiche di dominio complesse

Riduzione delle dipendenze attraverso interfacce documentatee organizzazione in packages dei moduli


21/38

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

Punto di vista del progettista


22/38

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

Punto di vista dell’amministratore


23/38

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


24/38

Processo di Governance: 3/3

Requests For Commments – RFC (Indicizzazione semantica)


25/38

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


26/38

eToscana compliance


27/38

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


28/38

RFC81: sperimentazioni cliniche


29/38

RFC17: RFC Applicativo e.Toscana


30/38

Dalle RFC al sistema-delle-RFC

Oltre 100 RFC standardizzate o in via di standardizzazione Complessità di ricerca e garanzia di consistenza


31/38

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

Possibile integrazione con catalogo schemi e ontologie in CG-SICA


32/38

Un caso applicativo

Gestione delle sperimentazioni cliniche Processo interno ad un Centro di Sperimentazione Cooperazione con i sistemi informativi Ragionale e Nazionale

Problema delle procedure Architettura di workflow management Cooperazione


33/38

Un caso di cooperazioneapplicazione di gestione delle sperimentazioni cliniche

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


34/38

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


35/38

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>DANTEDual 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>


36/38

Architettura di integrazione

Passi flusso AIFA

(D.Min.Sett.08)

applicazione di ricezionecon interfaccia applicativa

Registrazione CG-SICA(accordo di servizio + modello ontologico)

Estensione del flusso regionale COMET per includere flusso AIFA(nuova RFC)

Estensione applicazionegestione sperimentazionicliniche

Gateway CART/AIFAtramite CG-SICA


37/38

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


38/38

Conclusioni

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, TecnologieReti di calcolatori, Sicurezza, Telematica, Pratica del collaudo, Metodi di testing, Gestione dei contratti, …

Enrico Vicario – vicario SPC – Roma3 - Gen.09 1/38 Il Sistema Pubblico di Connettività un...

Documents

Transcript of Enrico Vicario – vicario SPC – Roma3 - Gen.09 1/38 Il Sistema Pubblico di Connettività un...