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

Presentazione sul tema: "Il Sistema Pubblico di Connettività un progetto innovativo per la P. A"— Transcript della presentazione:

1 Il Sistema Pubblico di Connettività un progetto innovativo per la P. A
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 La presentazione affronta il problema della maintenance nel contesto di applicazioni per internet: sistemi informativi, portali, servizi, … (Esclusione: sistemi embedded e infrastrutture di controllo, sistemi bancari con vincoli di legacy, …) In questo contesto in questi anni si fronteggiano due approcci di sviluppo XP e UP Ci interessa piu’ capire come sviluppare un sistema per renderlo capce di evolvere, piuttosto che capire come fare evolvere un sistema qualsiasi

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 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 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, 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à
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 Comune X Uni Fi ASL n livello locale livello condiviso cooperazione

8 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

9 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

10 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

11 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

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 Organizzazione delle componenti applicative
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 progetto comunicabili 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 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 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 Doppia responsabilità, verso il CRIC e verso il SIL non devono essere effettuati accessi diretti ad alcuno dei servizi esposti da componenti del sistema centrale directory server (LDAP), code di messaggi, servizi web.

18 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 Al fine di permettere lo sviluppo di componenti di cooperazione dei SIL che abilitano l’uso delle funzionalità del proxy, si rende necessaria una definizione non ambigua delle caratteristiche della interfaccia di comunicazione.

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 XMLSchema con 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 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

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 ( 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 Gestione delle sperimentazioni cliniche
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 progetto della Azienda Ospedaliera Universitaria Careggi (AOUC)
Un caso di cooperazione applicazione 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 In uso presso AOUCareggi
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=" <IdUniversale>AOUCMonocentrica </IdUniversale> <SIL_Mittente>SPCAslTest_SPCRegioneToscana_SPCSISComet_SIL_F</SIL_Mittente> <DataPubblicazione> :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 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

37 Integrazione tra Centro Sperimentazione Clinica e AIFA via CG-SICA
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 Circa l’astrazione e la concretezza
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, Tecnologie Reti di calcolatori, Sicurezza, Telematica, Pratica del collaudo, Metodi di testing, Gestione dei contratti, …