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

1. 20 gennaio 08 - Facoltà di Ingegneria - Università Roma Tre 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 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

2. 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 dependabilityin 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. 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. 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.

5. 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. 1/3: Architettura • Partizionamento delle responsabilità • Design Pattern Observer • Architectural Pattern Publish&subscribe • CART

7. Architettura: partizionamento delle responsabilità Uni Fi livellocondiviso ASL n Comune X livellolocale • 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 cooperazione

8. 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. 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. 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. 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. Trasposizione architetturale: Publish & Subscribe • Publish & Subscribe (broker) • Equivalente architetturale del pattern observer, con analoga motivazione e struttura

13. 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. Strumenti di Metodo condivisi: 2/3 • Buone pratiche di sviluppo • Processo di certificazione • (Pratiche di gestione del processo di fornitura)

15. Buone pratiche • 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 progettocomunicabili e riusabili • Architectural e design patterns • Documentazione delle interfacce • Formati di scambio • Implementazioni di riferimento aperte • Strumenti di supporto al testing

16. Processo di certificazione • Strumento di attuazione del quadro di riferimento • Promuove requisiti metodologici e architetturalial 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 diverseche facilitino l’integrazione e l’evoluzione • Requisiti di documentazione • Abilitare la visione di insieme

17. Requisiti di interoperabilità: Interfaccia proxy - FrameworkCA • Il proxy accede al framework CAesclusivamente 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. Requisiti di interoperabilità: Interfaccia proxy - SIL • Documentazione statica dell’interfaccia • Nello schema di cooperazione per eventi • formato degli eventi in XMLSchemacon 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. 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. 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 SILlogica di dominiointerfaccia verso FCA • Architettura interna per logiche di dominio complesse • Riduzione delle dipendenze attraverso interfacce documentatee organizzazione in packages dei moduli

21. 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. 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. (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. Processo di Governance: 3/3 • Requests For Commments – RFC • (Indicizzazione semantica)

25. 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. eToscana compliance

27. 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. RFC81: sperimentazioni cliniche

29. RFC17: RFC Applicativo e.Toscana

30. Dalle RFC al sistema-delle-RFC • Oltre 100 RFC standardizzate o in via di standardizzazione • Complessità di ricerca e garanzia di consistenza

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

36. 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. 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. 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, …