Interoperabilità e cooperazione applicativa: elementi di ...
Transcript of Interoperabilità e cooperazione applicativa: elementi di ...
DINFODipartimento diIngegneria dell'informazione
Interoperabilità e cooperazione applicativa:elementi di progettazione
Samuele InnocentiDipartimento di Ingegneria dell'Informazione
Firenze, 2 ottobre 2015
2
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Contenuti
● Introduzione al contesto● Definizioni di cooperazione applicativa e
interoperabilità● Architettura e scelta dei pattern● Principi, linee guida e buone pratiche ● Alcuni esempi
3
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
C'era una volta...
4
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Lo scenario
INFRASTRUTTURADI CONNETTIVITA'
Alcune definizioni di infrastruttura
Il complesso degli impianti che consentonoe condizionano un'attività [wikipedia]
l'insieme delle parti necessarie ad articolare un ambienteper adeguarlo a particolari esigenze [treccani]
Insieme di strutture secondarie e complementari di una strutturadi base, necessarie affinché quest'ultima possa funzionare [corriere.it]
Insieme di strutture date per scontate per rendere operativa una una attività
APP APPflusso informativo
5
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Lo scenario
APP APPflusso informativo
INFRASTRUTTURADI CONNETTIVITA'
Alcune definizioni di infrastruttura
Il complesso degli impianti che consentonoe condizionano un'attività [wikipedia]
l'insieme delle parti necessarie ad articolare un ambienteper adeguarlo a particolari esigenze [treccani]
Insieme di strutture secondarie e complementari di una strutturadi base, necessarie affinché quest'ultima possa funzionare [corriere.it]
Insieme di strutture date per scontate per rendere operativa una una attività
6
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Interoperabilità e cooperazione applicativa: specifica capacità di due o più sistemi informativi connessi in rete.– capacità che essi devono avere, affinché l’applicazione, operante in ciascun sistema, sia in
grado di disporre automaticamente, per le proprie finalità applicative, dei dati che sono producibili e/o acquisibili solo attraverso il processo elaborativo delle applicazioni operanti negli altri sistemi informativi.
● Interoperabilità: capacità di due o più sistemi informativi di scambiarsi informazioni e di attivare, a suddetto scopo, processi elaborativi nelle rispettive applicazioni.– adozione di uno stesso formato di interscambio dei dati e di un protocollo di comunicazione
condiviso.
● Cooperazione applicativa: capacità di uno o più sistemi informativi di avvalersi, ciascuno nella propria logica applicativa, dell’interscambio automatico di informazioni con gli altri sistemi, per le proprie finalità applicative.– Un’applicazione nel corso del suo processo elaborativo può far uso di informazioni elaborate da
un’altra applicazione.
● L’interoperabilità è un prerequisito essenziale per la cooperazione applicativa.● La cooperazione applicativa in rete ha luogo quando ciò avviene in modo
automatico.
Definizioni di cooperazione applicativa e interoperabilità
[www.progettoicar.it]
7
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● La cooperazione applicativa e l'interoperabilità NON sono semplice somma di sistemi, tecnologia e tecnica
● Alla base della cooperazione applicativa e dell'interoperabilità esiste una esigenza di condividere… animata da interessi
● La cooperazione applicativa e l'interoperabilità sono parte di “un processo”
● La cooperazione applicativa e l'interoperabilità devono essere garantite nel tempo
Osservazioni
8
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Sistema– un insieme di elementi distinti (incluse le persone)
– che sono connessi o correlati
– e lavorano assieme
– per realizzare una combinazione significativa di funzionalità e qualità
– la combinazione di funzionalità e qualità non può essere realizzata individualmente dai singoli elementi
● Complesso– composto di parti interconnesse o intrecciate
Sistema complesso
9
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Portare servizi di base, consolidati o da consolidare nell'infrastruttura
● Per abilitare lo sviluppo e la crescita di applicazioni e servizi a valore aggiunto(1)
● Per “le persone, le imprese, la società”
L'idea
(1) attività che aggiungono il valore, attività per le quali il cliente è disposto a pagare.[...] In particolare l’attività deve essere analizzata lungo gli aspetti: valore che il cliente associa alla determinata attività e valore che è disposto a pagare per quella attività. [http://www.lean.polimi.it/glossario.html]
10
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Sistema complesso... costituito e usato da persone
APPLICATION LAYER
Sistema per sostenere le interazioni tra persone
11
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Stima delle possibili interconnessioni
App 1 App 2
App 3 App 4
All'aumentare delle applicazionii link “crescono” come
n∗(n−1)
2
12
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Complessità delle relazioni
App 1 App 2
App 3 App 4
Complessità:● Tecnologiche● Geografiche● Organizzative● Economiche● Sociali● Politiche● Culturali● Ambientali● ...
13
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Person to Person (P2P)● Person to Business (P2B)● Person to Government (P2G)● Business to Business (B2B)● Business to Government (B2G)● Business to Person (B2P)● Government to Government (G2G)● Government to Business (G2B)● Government to Person (G2P)
Classificazione delle interazioni
INT
ER
AZ
ION
IM
ED
IAT
E D
AL
LA R
ET
E
14
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Personale e Home (a livello individuale o familiare)● Locale o Aziendale (a livello cittadino, PMI, enti
locali)● Area Vasta (a livello provinciale o regionale)● Nazionale● Continentale o Enterprise (istituzioni pubbliche o
private, multinazionali)● Globale
Livelli geografici di cooperazione applicativa
15
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● SaaS (Software as a Service)– modello di distribuzione del software applicativo dove un produttore di
software sviluppa e gestisce un'applicazione web che mette a disposizione dei propri utenti via internet.
● PaaS (Platform ad a Service)– distribuzione di piattaforme di elaborazione (Computing platform) e di
solution stack come servizio. Gli elementi del PaaS permettono di sviluppare, testare, implementare e gestire le applicazioni aziendali senza i costi e la complessità associati all'acquisto, la configurazione, l'ottimizzazione e la gestione dell'hardware e del software di base
● IaaS (Infrastructure as a Service) || HaaS (Hardware as a Service)– Insieme di tecnologie che permettono, tipicamente sotto forma di un
servizio offerto da un provider all'utente, di memorizzare/archiviare e/o elaborare dati (tramite CPU o software) grazie all'utilizzo di risorse hardware/software distribuite e virtualizzate in rete in un'architettura
Il mercato offre una pseudo “cooperazione” applicativa
[wikipedia]
16
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Qualità della cooperazione applicativa
● Condivisa● Di compromesso● Standardizzata● Documentata● Normata● Regolamentata● Inclusiva
● Aperta● Trasparente● Imparziale● Efficace● Efficiente● Etica● Sostenibile
17
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Ci vuole una architettura per l'infrastruttura di cooperazione– Like any other complex structure, software [ndr architecture] must
be built on a solid foundation. Failing to consider key scenarios, failing to design for common problems, or failing to appreciate the long term consequences of key decisions can put your application at risk. Modern tools and platforms help to simplify the task of building applications, but they do not replace the need to design your application carefully, based on your specific scenarios and requirements. The risks exposed by poor architecture include software that is unstable, is unable to support existing or future business requirements, or is difficult to deploy or manage in a production environment [http://msdn.microsoft.com/en-us/library/ee658098.aspx]
Architettare la cooperazione applicativa
18
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
1) Software application architecture is the process of defining a structured solution that meets all of the technical and operational requirements, while optimizing common quality attributes such as performance,
security, and manageability. It involves a series of decisions based on a wide range of factors, and each of these decisions can have considerable impact on the quality, performance, maintainability, and overall success of the application. [http://msdn.microsoft.com]
2) “Software architecture encompasses the set of significant decisions about the organization of a software system including the selection of the structural elements and their interfaces by which the system is composed; behavior as specified in collaboration among those elements; composition of these structural and
behavioral elements into larger subsystems; and an architectural style that guides this organization.
Software architecture also involves functionality, usability, resilience, performance, reuse, comprehensibility, economic and technology constraints, tradeoffs and aesthetic concerns.” [Philippe Kruchten, Grady Booch, Kurt Bittner, and Rich Reitman]
3) “The highest-level breakdown of a system into its parts; the decisions that are hard to change; there are
multiple architectures in a system; what is architecturally significant can change over a system's lifetime; and, in the end, architecture boils down to whatever the important stuff is.” [Patterns of Enterprise Application Architecture, Martin Fowler]
4) “The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the
relationships among them. Architecture is concerned with the public side of interfaces; private details of elements—details having to do solely with internal implementation—are not architectural.” [Software Architecture in Practice (2nd edition), Bass, Clements, and Kazman]
Alcune definizioni di architettura
19
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Ingredienti
Funzionalità
Complessità
Organizzazione e cultura
Costi
Abilità
Qualità
Processi
Tecnologie
L'architettura è la ricetta, l'architetto è il cuoco
20
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Guida la scelta e la negoziazione dei requisiti● Rispetta i vincoli ed integra i requisiti● Riconosce l’importanza di tutte le parti interessate
e delle loro relazioni● Orchestra il sistema di elementi e le interrelazioni,
per fornire globalmente le qualità desiderate● Disciplina la comprensione delle relazioni tra la
struttura interna del sistema e le sue qualità esterne
● Sostiene il sistema nel suo complesso
Il ruolo della architettura
21
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Vincoli (ciò che esiste e non può essere violato)– fisici
● es. geografici, spaziali
– sociali● es. digital division, asset aziendali
– artificiali● es. normative, leggi, organizzazione del lavoro
– economici● es. budget
● Requisiti (ciò che dobbiamo o vogliamo rispettare)– funzionali
● Specificano una funzione che il sistema o un componente deve essere in gradi di realizzare
– non funzionali● Dichiarano come il sistema o un componente deve comportarsi (comportamento del sistema)
Vincoli e requisiti
22
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Tom Kelliher, CS 319, 1998
Analisi dei requisiti
23
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Accoppiamento● Eterogeneità● Autonomia● Maneggiabilità● Adattabilità● Sicurezza● Scalabilità
Requisiti non funzionali
Medjahed, Benatallah, Bouguettaya, Ngu and Elmagarmid. “Business-to-business interactions: issues and enabling technologies”, VLDB Journal, 2003
24
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Classificazione dei requisiti non funzionali
[http://cnx.org/content/m14621/latest/]cfr IEEE 830-1993 (SRS)
25
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Qualità interne ed esterne (ISO/IEC 9126-1:2001)
● Funzionalità (idoneità, accuratezza, interoperabilità, sicurezza)– La capacità del prodotto software i fornie funzioni che incontrino le necessità dichiarate e
implicite● Reliability (maturità, tolleranza ai guasti, recuperabilità)
– La capacità del prodotto software di mantenere un livello specifico di prestazioni● Usabilità (comprensibilità, apprendibilità, operabilità, attrattività)
– La capacità del prodotto software di essere compreso, appreso, utilizzato e attattattivo per l'utente
● Efficienza (comportamento nel tempo, utilizzo delle risorse)– La capacità del prodotto software di fornire adeguate prestazioni, relativa alle risorse utilizzate,
sotto prestabilite condizioni● Manutenibilità (analizzabilità, modificabilità, stabilità, verificabilità)
– La capacità del prodotto software di essere modificato. Le modifiche possono includere correzioni, miglioramenti o adattamenti a cambiamenti nell'ambiente, nei requisiti e specifiche funzionali
● Portabilità (adattabilità, installabilità, coesistenza, sostituibilità)– La capacità del prodotto software di essere conforme a standard o convenzioni relative alla
portabilità
26
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● normativo (“scienza”)– basato su soluzioni preesistenti → “deve essere così”
● razionale (“scienza”)– basato su principi per affrontare cambiamenti nelle
necessità, nelle preferenze o nelle circostanze
● partecipativo (“arte”)– riconosce la complessità dovuta alla presenza di una
molteplicità di parti interessate → il consenso
● pragmatico (“arte”)– basato su euristiche che codificano il “buon senso
comune” motivato dalla esperienza collettiva
Progettare con metodo, esperienza e intuizione
27
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Le fasi un progetto
realizza output e determina outcomes/effetti
bisogni/esigenze
supporto alle decisioni piano di sviluppo
decisione “politica”
progetto tecnico
copertura finanziaria per le fasi di produzione e manutenzione
28
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Note sui fattori di insuccesso dei progetti
● I principali fattori di insuccesso dei progetti non riguardano gli aspetti tecnici
● Problemi manageriali– mancanza di supporto da parte della direzione
– mancanza di risorse (umane, materiali, knowhow)
– mancanza di pianificazione
– clima interno
● Problemi sui requisiti– requisiti incompleti
– mancato coinvolgimento degli utenti
– attese irrealistiche
– cambiamento dei requisiti in corso d'opera
– progetti cancellati perché non più utili
29
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● In che modo è possibile affrontare/progettare problemi/sistemi ad alto livello di complessità?– partizionare (decomporre) il sistema/problema
progressivamente in unità più piccole e più semplici (divide et impera)
● È sufficiente che le varie parti siano “semplici”?– è necessario che anche le interconnessioni siano “semplici”
– utilizzare criteri di partizionamento/decomposizione in grado di ridurre la complessità delle interconnessioni tra le parti
Affrontare la complessità
La scelta delle parti e delle interconnessioni tra di esse definisce la “struttura” di un sistema (topologia)
30
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Decomporre il sistema in sottosistemi, gestibili separatamente, per dominarne la complessità– Siano P=problema, C=complessità di P, E=sforzo
per la risoluzione di P
● Dati 2 problemi P1 e P2, con C(P1)>C(P2), assumendo che E(P1)>E(P2) allora C(P1+P2)>C(P1)+C(P2) e conseguentemente E(P1+P2)>E(P1)+E(P2)
Osservazione
La scomposizione introduce il problema della comunicazione tra le varie parti, il che aggiunge anche
la complessità per l'interfacciamento
31
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Separation of concerns.– Divide your application into distinct features with as little overlap in functionality as possible. The
important factor is minimization of interaction points to achieve high cohesion and low coupling. However, separating functionality at the wrong boundaries can result in high coupling and complexity between features even though the contained functionality within a feature does not significantly overlap.
● Single Responsibility principle.– Each component or module should be responsible for only a specific feature or functionality, or
aggregation of cohesive functionality.
● Principle of Least Knowledge (also known as the Law of Demeter or LoD).– [ndr Information Hiding]
– A component or object should not know about internal details of other components or objects.
● Don’t repeat yourself (DRY). You should only need to specify intent in one place.– For example, in terms of application design, specific functionality should be implemented in only one
component; the functionality should not be duplicated in any other component.
● Minimize upfront design.– Only design what is necessary. In some cases, you may require upfront comprehensive design and
testing if the cost of development or a failure in the design is very high. In other cases, especially for agile development, you can avoid big design upfront. If your application requirements are unclear, or if there is a possibility of the design evolving over time, avoid making a large design effort prematurely. This principle is sometimes known as YAGNI ("You ain’t gonna need it").
Principi guida
[msdn.microsoft.com/library]
32
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Ciascun sistema è utile nella misura in cui consente di perseguire l'obiettivo e ottenere dei risultati– quali sono i risultati desiderati?
– quale è il motivo per cui un sistema viene costruito?
– quali sono i bisogni delle parti interessate al sistema?
● La definizione del problema da affrontare spesso non è nota o è mal definita, quindi è necessario:– identificare coppie problema-soluzione
– lavorare a stretto contatto con le parti interessate
Non perdere di vista l'obiettivo...
33
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● parti interessate e interessi– chi ha interessi nel sistema? (stakeholders)
● punti di vista e viste– principio della separazione degli interessi, con
riferimento agli interessi principali del sistema
● stili architetturali– esperienze significative pregresse
● tattiche (locali) e strategie (globali) architetturali– come evolverà; dove condurre; obiettivi da raggiungere
… e focalizzare l'attenzione
34
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Un sistema viene realizzato per perseguire gli obiettivi di diverse parti interessate al sistema– utenti → chi userà il sistema
– amministratori → chi gestisce, verifica e manutiene il sistema
– clienti/acquirenti → chi paga per il sistema
– sviluppatori → chi crea e implementa
– ma anche decisori, comunità, associazioni, influenti, lobby ...
● Ciascun attore ha interessi sul sistema (funzionali e non funzionali)– l’architettura deve tenere in considerazione e sostenere gli
interessi sottesi, smussando i contrastanti, tra le parti interessate
Compromessi
35
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● un singolo criterio di partizionamento/decomposizione non è di solito sufficiente per dominare la complessità di un sistema– utile decomporre e descrivere il sistema secondo un insieme di viste
architetturali, indipendenti ma correlate
● ciascuna vista architetturale definisce un modello (una descrizione parziale) del sistema – che si occupa di un insieme coeso di interessi
● le viste sono utili per comprendere, progettare, validare ed attuare l’architettura; per descrivere e comunicare l’architettura alle varie parti interessate
● la selezione e realizzazione delle viste può essere guidata da opportuni punti di vista (es. funzionale, delle informazioni, della concorrenza, di deployment)
Viste e punti di vista
36
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Le viste architetturali consentono di descrivere in modo efficace la struttura di un sistema, ma l’architettura non è interessata solo alla struttura dei sistemi– Analysis Model
– Design Model
– Implementation Model
– Software Architecture Document
– Architecture Notes
– Design Guidelines
– Programming Guidelines
– Architectural Prototype
– Architecure Presentation
Documentare, descrive, giustificare
37
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● I pattern sono un metodo per condividere esperienze progettuali– in generale, un pattern ha lo scopo di condividere una soluzione provata
ed ampiamente applicabile ad un particolare problema di progettazione, descritta in una forma standard che possa essere riusata
– un pattern (o stile) architetturale codifica una esperienza significativa nella realizzazione di un’architettura
● Uno stile architetturale– mette a sistema una certa combinazione di requisiti (soprattutto di
qualità) da raggiungere
– propone una soluzione in termini di elementi, relazioni tra elementi e criteri di decomposizione (spesso nell’ambito di una singola vista)
– discute la soluzione e i termini delle diverse qualità su cui la soluzione impatta
Pattern e stili architetturali
38
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Categoria Stile architetturale
Communication Service-Oriented Architecture (SOA),Message Bus
Deployment Client/Server,N-Tier, 3-Tier
Domain Domain Driven Design
Structure Component-Based,Object-Oriented,Layered Architecture
Esempi di stili architetturali
[http://msdn.microsoft.com/en-us/library/ee658117.aspx]
39
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Principali stili architetturali
[http://msdn.microsoft.com/en-us/library/ee658117.aspx]
40
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Pattern architetturali
[http://en.wikipedia.org/wiki/Architectural_pattern]
41
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Tattiche e le strategie architetturali devono essere pianificate per progettare coerentemente
– una tattica architetturale è una decisione/scelta di progetto che influenza il controllo di un attributo di qualità (breve e medio periodo)
– una strategia architetturale è una collezione di attività, tattiche e linee guida per far sì che un sistema esibisca un insieme di proprietà di qualità correlate al fine ultimo (lungo periodo)
Tattiche e strategie
42
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Le applicazioni si scambiano dati con un “protocollo” → Data formats for data exchange
● Nel caso della interoperabilità si potrebbe parafrasare “Information formats for information exchange”
● Le informazioni (nella forma di dati) interoperabili devono essere ricevute, interpretate, elaborate e trasmesse automaticamente in maniera integra, coerente e semanticamente corretta
Non dimentichiamo l'interoperabilità
43
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Le qualità del dato interoperabile ideale
● Completo → per esportare/integrare/diffondere● Primario → sufficientemente “granulare”● Tempestivo → accesso rapido e immediato● Accessibile → senza contratto o sottoscrizione o pagamento● Leggibile → machine-readable in processi automatici● Non proprietario → usabile da altre applicazioni● Libero da licenze con limiti d'uso → ©/brevetti non sostenibili● Riutilizzabile → per creare nuove risorse informative● Ricercabile → trovabile con facilità● Permanente → ciclo di vita “infinito”
Open Government Directive, USA, 2009
44
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Quale è lo schema strutturale?– È strutturato o flat? Di quali parti si compone? Come sono tra loro
relazionate?
● Quale è la codifica?– Formato binario o testo? Testo che codifica in formato binario?
Quale repertorio di caratteri?
● Quali convenzioni e interpretazioni assumere?– La forma del dato è predefinita? Quali convenzioni si adottano?
Quali prassi si sottendono?
● Quali elaborazioni posso eseguire senza perdere il senso e gli intenti dell'autore?– È possibile rileggerlo e riprodurlo nello stesso identico modo di chi lo
ha generato?
Riconoscere l'interoperabilità
45
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Alcuni esempi di dati NON interoperabili
● Standard proprietari– non documentati pubblicamente
– documentati parzialmente
– legacy
● Soluzioni commerciali personalizzate
Osservazione: non basta lo standard!
46
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Il mercato sviluppa offerte di interoperabilità
● OpenData
47
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Per una reale interoperabilità
● Digitalizzare+dematerializzare+descrivere, ogni risorsa (rendendola elaborabile)
● Automatizzare l'elaborazione delle informazioni in tutto il loro ciclo di vita:– Da quando l'informazione viene creata, inviata,
ricevuta a quando viene archiviata, inoltrata, duplicata, cancellata
48
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
ESEMPI
49
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Sistema Pubblico di Connettività (SPCoop)
50
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Comunicazione in SPCoop
51
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Flash sulla cooperazione applicativa in RT
Dominio dell’EnteNAL
Porta diDominio
CRIC
Gestore Eventi
Registro SICAsecondario (UDDI)
VPN CART
Porta di DominioCART
Gestione eMonitoraggio
Porta di DominioNAL
NAL
SIL
Agente digestione e
monitoraggio
Dominio dell’Ente
Componente diIntegrazione
PortaleCART
Internet
SPC
NICAGateway ICAR
by
ecosistemadi applicazioni
Publish&Subscribe
52
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
● Termini di utilizzo documenti SPCoop● Glossario generale e termini significativi d'uso comune● Inquadramento generale delle specifiche SPCoop● Specifiche della Busta di e-gov● Specifiche della Porta di dominio● Specifiche dell'Accordo di servizio● Specifiche del Registro SICA● Nomenclatura e semantica● LInee guida busta di e-gov● Qualificazione della Porta di dominio● Qualificazione Porta di dominio concorso regioni● Raccomandazioni stesura Accordi di servizio● Gestione federata delle Identità digitali
[http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/sistema-pubblico-connettivita/architettura-generale]
Documentazione e non solo
53
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Per l'iscrizione alla laurea in medicina e chirurgia e professioni sanitarie è previsto un limite massimo con programmazione nazionale, mediante assegnamento ministeriale dei posti alle singole sedi
● Concorso ministeriale che avviene lo stesso giorno in tutta Italia
● Localmente emerge l'esigenza di automatizzare il processo amministrativo e la logistica per adempiere all'obbligo istituzionale
Un esempio di cooperazione applicativa locale
54
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Il ministero bandisce il concorso e ne definisce alcuni aspetti normativi ed organizzativi– chi può partecipare, come inviare la domanda, data di
svolgimento, regole di svolgimento dei test, valutazione dei punteggi, graduatoria nazionale, ecc
● I candidati sottomettono la domanda di partecipazione ad un ateneo (prima scelta)
● I candidati partecipano ai test in quell'ateneo● Il ministero pubblica la graduatoria nazionale● I candidati vincitori possono iscriversi all'ateneo per il
quale hanno acquisito diritto
Il caso in estrema sintesi
55
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Dal 2007 UniFi (Polo Biomedico e Tecnologico) ha iniziato ad informatizzare e automattizzare il processo delle selezioni in area medica– Miglioramenti continui
– Cadenze annuali
● Alcune tappe significative– 2008 – adozioni di apparati industriali
– 2009 – sistema in alta disponibilità ed alta affidabilità per servire una area vasta, eliminazione completa della carta, gestione logistica e rendicontazione automatica
– 2010 – reingegnerizzazione del sistema e sperimentazione della virtualizzazione sottosistemi non critici
– 2011 – pagamenti elettronici e automazione delle immatricolazioni
– 2012 – eliminazione completa di tecnologie non-free
– 2013 – completa virtualizzazione dell'architettura hw
Informatizzazione del processo
56
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Startup
app
web server
db
Selezionedel pattern3-tier
● MACRO FASE 1 – (2007) budget inesistente, tempi ristretti → una scommessa
php
apache
mysql
SelezionepiattaformeHW/SW
mysql v4
SceltaimplementativaHW/SW
apache v2
php v5
banalmenteLAMP su 1 vecchio server
57
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Pianificare e realizzare
● MACRO FASE 2 – (2008) la fase 1 è un successo e le risorse arrivano: iniziamo a decomporre i sevizi
app
web server
db
Server dedicatoalle iscrizioni
Server dedicato Alla base dati
web server
appServer peraltre web appnon “critiche”
Sistema UPS
Redundat Power
58
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Verificare e migliorare
Cluster bilanciamento di carico
Cluster web server
Cluster database
● MACRO FASE 3 – (2009-2010) l'utenza si espande, evitiamo i rischi → two-nines verificati (downtime<4gg/anno)
Storage distribuito condiviso
Data centerin alta affidabilitàe alta disponibilità
man
agem
ent
Sistema UPS
netw
orki
ng
Redundat Power
MACRO FASE 4 – (2013) virtualizziamo per abbattere gestione, manutenzione ed esercizio (anche a livello applicativo) → Obiettivo three-nines (downtime<9h/anno)
59
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● 2011 – il Codice dell'Amministrazione Digitale impone i pagamenti elettronici da parte delle PA– Il sistema deve necessariamente adeguarsi
– E deve integrarsi con la rendicontazione elettronica dei pagamenti allo sportello bancario
● 2012 – Oracle acquista Sun Microsystem ed eredita MySQL– La nostra architettura stratificata consente di migrare a PostgreSQL:
una scelta ponderata, ma anche etica
– Impatto sul sw applicativo: non era stato sempre usato sql standard e neanche db abstraction layer
– Senza formazione/consulenze esterne non ci sono strumenti per validare/valutare il sistema
Interferenze esterne
60
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
La cooperazione applicativa
SistemaInformativo
Iscrizioni (polo)
Sistema gestione studenti
Graduatorie nazionali
Pagamenti ee rendicontazione
SegreteriestudentiLogistica
Resp.procedimento
Altri attori che partecipano direttamente o indirettamente al processo
Uff. tecnici
È la tesoreria di UniFi
Non è pubblicità
61
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
COD_FISCALE NOT NULL VARCHAR2(16) IDENTIFICATIVO VARCHAR2(20) COGNOME NOT NULL VARCHAR2(50) NOME NOT NULL VARCHAR2(40) SESSO VARCHAR2(1) DT_NASCITA VARCHAR2(8) COD_NAZIONE VARCHAR2(3) COD_ISTAT VARCHAR2(6) COD_CITTA VARCHAR2(6) COD_ISTAT_RES VARCHAR2(6) CAP_RES VARCHAR2(5) COD_CITTA_RES VARCHAR2(6) FRAZ_RES VARCHAR2(40) COD_ISTAT_DOM VARCHAR2(6) CAP_DOM VARCHAR2(5) COD_CITTA_DOM VARCHAR2(6) FRAZ_DOM VARCHAR2(40) RESIDENZA VARCHAR2(50) NUM_CIVICO_RES VARCHAR2(15) DOMICILIO VARCHAR2(50) NUM_CIVICO_DOM VARCHAR2(15) PRESSO VARCHAR2(30) TEL_PREF VARCHAR2(4) TEL_NUM VARCHAR2(10) DOTTORE VARCHAR2(1) DIVULGA_DATI VARCHAR2(1) POSTA VARCHAR2(1) EMAIL VARCHAR2(40)
● Pattern RTL: Extract → Transform → Load● Schema dati concordato● Codifiche dati coerenti● Trasmissione/Ricezione tracciato
– invio schedulato
● Compromesso tra le parti– Il più debole si deve adattare
– Il più debole deve sostenere i costi
Sottosistema “graduatorie” || “immatricolazione”
5001 TASSA IMMATRICOLAZIONE FASCIA 15001 TASSA IMMATRICOLAZIONE FASCIA 15002 TASSA IMMATRICOLAZIONE FASCIA 25002 TASSA IMMATRICOLAZIONE FASCIA 25003 TASSA IMMATRICOLAZIONE FASCIA 35003 TASSA IMMATRICOLAZIONE FASCIA 35004 TASSA IMMATRICOLAZIONE FASCIA 45004 TASSA IMMATRICOLAZIONE FASCIA 45005 TASSA IMMATRICOLAZIONE FASCIA 55005 TASSA IMMATRICOLAZIONE FASCIA 55006 TASSA IMMATRICOLAZIONE FASCIA 65006 TASSA IMMATRICOLAZIONE FASCIA 65007 TASSA IMMATRICOLAZIONE FASCIA 7
62
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Sottosistema pagamento elettronico (SOA+RTL)
“The Broker”
Iscrizioneconcorsi
unifi
PagamentoEventi
unifi o aouc
Iscrizioneconcorsi OSS
aouc
WS
WSGestisce il carrello ordini, la rendicontazionee e lo stato dei pagamenti allo sportello e con carta di credito
Querciasincro RX
win vm
SPID&R
Protocollo proprietario
samba
Sistema Processi Integrati Didattica e Ricerca
63
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Sottosistema pagamento elettronico (RTL)
“The Broker”
Iscrizioneconcorsi
unifi
PagamentoEventi
unifi o aouc
Iscrizioneconcorsi OSS
aouc
WSGestisce il carrello ordini, la rendicontazionee e lo stato dei pagamenti allo sportello e con carta di credito
Querciasincro RX
win vm
SPID&R
samba
WSProtocollo proprietario
Sistema Processi Integrati Didattica e Ricerca
64
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Sottosistema pagamento elettronico (SOA)
“The Broker”
Iscrizioneconcorsi
unifi
PagamentoEventi
unifi o aouc
Iscrizioneconcorsi OSS
aouc
WSGestisce il carrello ordini, la rendicontazionee e lo stato dei pagamenti allo sportello e con carta di credito
Querciasincro RX
win vm
SPID&R
samba
WSProtocollo proprietario
Sistema Processi Integrati Didattica e Ricerca
65
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
La App SmartUnifi: cooperazione e interoperabilità
Infrastrutturadi integrazione
OpendataComune di Firenze
Sito web DSUToscana
APITwitter/YouTube...
OpenStreet Map
Gestionali e siti webdi Ateno
Archivi bibliotecheOPAC
66
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
Dipartimento di Architettura
DipartimentoIngegneria dell'Informazione
Comune di Firenze
Area Comunicazione eRelazioni Esterne
Direzione Generale
Servizi Informatici di Ateneo
Sistema Bibliotecario
Amministrazione di Ateneo
STUDENTI
APP
Gli attori istituzionali
67
Cooperazione applicativa e interoperabilità: elementi di progettazioneDINFODipartimento diIngegneria dell'informazione
Firenze, 2 ottobre 2015
Condizioni necessarie la cooperazione applicativa
● Accordi tra le parti (dal basso o calati dall'alto): protocolli di intesa, disposizioni di legge, piano di intenti, normativa, politiche
● Progetto, organizzazione e pianificazione● Finanziamento e/o copertura finanziaria● Architettura e infrastruttura (HW/SW) condivise,
inclusive, capillari, standardizzate e scalabili● Implementazione, manutenzione, disponibilità
del servizio e monitoraggio garantiti (qualità del servizio)
68
Cooperazione applicativa e interoperabilità: elementi di progettazione
Firenze, 2 ottobre 2015
DINFODipartimento diIngegneria dell'informazione
● Esistono infrastrutture di cooperazione applicativa?– Si, tante, pubbliche e private, globali, locali, ...
– In generale verticalizzate su particolari domini● eGovernment → federazione di PA● Banking → sistema interbancario (EDI e Financial EDI)● Peer-to-peer → singoli individui (eMule, torrent, ...)● Commercial → enterprise platform● Cloud → cloud computing, cloud sharing, virtualization
● Un “ISO/OSI” per la cooperazione applicativa ed interoperabilità” è un miraggio, ma forse non è necessario
Conclusioni
DINFODipartimento diIngegneria dell'informazione
Interoperabilità e cooperazione applicativa:elementi di progettazione
Samuele InnocentiDipartimento di Ingegneria dell'[email protected]
“Il successo dipende dalla preparazione precedente,e senza una tale preparazione c'è sicuramente il fallimento.”(Confucio)
Firenze, 2 ottobre 2015