Il Sistema Pubblico di Connettivit

1
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 SWesperienza 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_at_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 36
• 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 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, 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 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 2003.

5
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
1/3 Architettura

• Partizionamento delle responsabilità
• Design Pattern Observer
• Architectural Pattern Publishsubscribe
• 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
• Limpatto della loro integrazione deve essere
  proporzionale
• Infrastruttura finalizzata al supporto della
  cooperazione

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 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
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 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
  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
  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
  diverseche facilitino lintegrazione e
  levoluzione
• 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

18
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
  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 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
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(RichiestaServ
  izioData.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 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
(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 PS
• 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)
• 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 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
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 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
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 nellintegrazione con AIFA
• AIFA (Ministero Affari Sociali)
• CINECA
• CNIPA
• Regione Toscana
• Azienda Ospedaliera Universitaria di Careggi
• Stlab.unifi

35
XML - comunicazione COMET

• lt?xml version"1.0" encoding"UTF-8"
  standalone"yes"?gt
• ltNotificaRichiestaAutorizzazioneSperimentazione
  xmlns"http//regione.toscana.it/sanita/comet/"gt
• ltIdUniversalegtAOUCMonocentrica1227116844281lt/I
  dUniversalegt
• ltSIL_MittentegtSPCAslTest_SPCRegioneToscana_SPC
  SISComet_SIL_Flt/SIL_Mittentegt
• ltDataPubblicazionegt2008-11-190100lt/DataPubbl
  icazionegt
• ltCodiceSperimentazionegtAOUCMonocentricalt/Codic
  eSperimentazionegt
• ltStrutturaSperimentazionegt
• ltPubblica tipoStruttura"AOU"gt
• ltCodicegt090903lt/Codicegt
• ltDescrizionegtAzienda Ospedaliera
  Universitaria Careggilt/Descrizionegt
• lt/Pubblicagt
• lt/StrutturaSperimentazionegt
• ltOrganizzazionegt
• ltCodicegt7lt/Codicegt
• ltDescrizionegtGianfranco
  Gensinilt/Descrizionegt
• lt/Organizzazionegt
• ltOggettoSperimentazionegtDANTE
• Dual ANtiplatelet therapy Tailored on the Extent
  of platelet inhibitionlt/OggettoSperimentazionegt
• ltComitatoSperimentazionegtCOMITATO ETICO PER
  LA SPERIMENTAZIONE CLINICA DEI MEDICINALI

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