La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

Enrico Vicario – www.dsi.unifi.it/~vicario SPC – Roma3 - Gen.09 1/38 Il Sistema Pubblico di Connettività un progetto innovativo per la P.A. e per il Paese.

Presentazioni simili


Presentazione sul tema: "Enrico Vicario – www.dsi.unifi.it/~vicario SPC – Roma3 - Gen.09 1/38 Il Sistema Pubblico di Connettività un progetto innovativo per la P.A. e per il Paese."— Transcript della presentazione:

1 Enrico Vicario – SPC – 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 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 20 gennaio 08 - Facoltà di Ingegneria - Università Roma Tre

2 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 3/38 La natura incrementale delle-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 Enrico Vicario – SPC – Roma3 - Gen.09 4/38 La metafora del piano regolatore Non soluzioni specifiche ma linee guida Conciliare levoluzione 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 Il ruolo del settore pubblico

5 Enrico Vicario – SPC – Roma3 - Gen.09 5/38 Quadro di riferimento comune Architettura interfacce di cooperazione tra i componenti, schemi di interazione, standards e tecnologie usati nellintegrazione 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 levoluzione

6 Enrico Vicario – SPC – Roma3 - Gen.09 6/38 1/3: Architettura Partizionamento delle responsabilità Design Pattern Observer Architectural Pattern Publish&subscribe CART

7 Enrico Vicario – SPC – Roma3 - Gen.09 7/38 Sistemi informativi locali dei singoli enti coordinati Rispondono alla specifica missione di ciascun ente Dipendono solo marginalmente dalla integrazione Limpatto 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 cooperazione livello locale livello condiviso

8 Enrico Vicario – SPC – Roma3 - Gen.09 8/38 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 Enrico Vicario – SPC – Roma3 - Gen.09 9/38 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 Enrico 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

11 Enrico Vicario – SPC – Roma3 - Gen.09 11/38 il pattern Observer inversione di responsabilità della sottoscrizione Installazione dinamica con responsabilità a carico dellobserver Observer si registra su subject con attach/detach Subject notifica agli osservatori registrati con notify In ricezione del notify, observer invoca get_State

12 Enrico Vicario – SPC – Roma3 - Gen.09 12/38 Trasposizione architetturale: Publish & Subscribe Publish & Subscribe (broker) Equivalente architetturale del pattern observer, con analoga motivazione e struttura

13 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico 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)

15 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 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 lintegrazione 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 lintegrazione e levoluzione Requisiti di documentazione Abilitare la visione di insieme

17 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 18/38 Requisiti di interoperabilità: Interfaccia proxy - SIL Documentazione statica dellinterfaccia 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 dellinterfaccia 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 Enrico Vicario – SPC – Roma3 - Gen.09 19/38 Requisiti di interoperabilità: Sistemi Informativi Locali Il SIL ha la responsabilità di definire linterfaccia di eventuali servizi esposti verso linfrastruttura di cooperazione formato della richiesta di servizio (RichiestaServizioData.xml) formato dei messaggi di risposta (documentato attraverso XMLSchema con annotazione del significato dei campi)

20 Enrico Vicario – SPC – Roma3 - Gen.09 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 dominio interfaccia verso FCA Architettura interna per logiche di dominio complesse Riduzione delle dipendenze attraverso interfacce documentate e organizzazione in packages dei moduli

21 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 22/38 Requisiti di documentazione: proxy Documentazione di installazione, configurazione ed esercizio Configurazione dellapplication 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 dellamministratore

23 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 24/38 Processo di Governance: 3/3 Requests For Commments – RFC (Indicizzazione semantica)

25 Enrico Vicario – SPC – Roma3 - Gen.09 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 dellarchitettura. 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) (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 Enrico Vicario – SPC – Roma3 - Gen.09 26/38 eToscana compliance

27 Enrico Vicario – SPC – Roma3 - Gen.09 27/38 RFC infrastrutturali e applicative RFC applicative Definiscono standards sulluso dellinfrastruttura 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 Enrico Vicario – SPC – Roma3 - Gen.09 28/38 RFC81: sperimentazioni cliniche

29 Enrico Vicario – SPC – Roma3 - Gen.09 29/38 RFC17: RFC Applicativo e.Toscana

30 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 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 duso abilitati verificare se una nuova RFC è consistente rispetto allinsieme di quelle che la precedono ricerca di una o più RFC che insistono su un concetto, ad esempio per identificare linsieme 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 Enrico Vicario – SPC – Roma3 - Gen.09 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 Enrico Vicario – SPC – Roma3 - Gen.09 33/38 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 Enrico Vicario – SPC – Roma3 - Gen.09 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 nellintegrazione con AIFA AIFA (Ministero Affari Sociali) CINECA CNIPA Regione Toscana Azienda Ospedaliera Universitaria di Careggi Stlab.unifi

35 Enrico Vicario – SPC – Roma3 - Gen.09 35/38 XML - comunicazione COMET AOUCMonocentrica SPCAslTest_SPCRegioneToscana_SPCSISComet_SIL_F :00 AOUCMonocentrica Azienda Ospedaliera Universitaria Careggi 7 Gianfranco Gensini DANTE Dual ANtiplatelet therapy Tailored on the Extent of platelet inhibition COMITATO ETICO PER LA SPERIMENTAZIONE CLINICA DEI MEDICINALI DELL'AZIENDA OSPEDALIERO-UNIVERSITARIA CAREGGI DI FIRENZE clopidogrel B01AC04 Monocentrica III: pazienti (molti) true true Aperto Si No No profit

36 Enrico Vicario – SPC – Roma3 - Gen.09 36/38 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 Enrico Vicario – SPC – Roma3 - Gen.09 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 nellassolvimento del debito informativo verso AIFA Sperimentazione di trasferimento da catalogo RFC-eToscana a modelli ontologici su CG-SICA Valorizza larchitettura CART La integra con CG-SICA

38 Enrico Vicario – SPC – Roma3 - Gen.09 38/38 Conclusioni Circa lastrazione e la concretezza - Ma qualè la pietra che sostiene il ponte? - Il ponte non è sostenuto da questa o quella pietra, ma dalla linea dellarco che esse formano. - Perché mi parli delle pietre? E solo dellarco che mimporta. - 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, …


Scaricare ppt "Enrico Vicario – www.dsi.unifi.it/~vicario SPC – Roma3 - Gen.09 1/38 Il Sistema Pubblico di Connettività un progetto innovativo per la P.A. e per il Paese."

Presentazioni simili


Annunci Google