Appendice A – La cartografia
La cartografia è la rappresentazione simbolica ma veritiera della realtà di studio, sia essa un territorio geografico o un’azienda.
Si distinguono due diverse tipologie di cartografia : la cartografia dei
processi e la cartografia applicativa.
Così come una cartina geografica mostra del territorio solo le città e le vie di comunicazione, la cartografia dei processi mostra (in modo strutturato) come un’azienda crea valore, mettendo in risalto le fasi necessarie all’erogazione dei servizi (cosa si fa), l’operatività legata ad essi (come e chi fa che cosa) ed altri aspetti che dipendono dall’analisi in corso.
Allo stesso modo la cartografia applicativa mostra e classifica le applicazioni che costituiscono il Sistema Informativo aziendale, mettendo in risalto le dipendenze, le informazioni detenute e scambiate, e in modo particolare le correlazioni con i processi aziendali.
Le cartografie di processo e applicativa hanno come presupposto l’utilizzo di una simbologia ed un linguaggio uniforme che da significato alle mappe rendendole confrontabili e coerenti.
Inoltre la formalizzazione attraverso la cartografia delle relazioni tra i processi e le applicazioni consentono agli analisti di organizzazione di comunicare in modo efficace con gli analisti dei sistemi informativi e condividere con loro una visione univoca della realtà.
Nel nostro caso specifico la cartografia di processo e applicativa hanno molti punti di contatto che formalizzano le relazioni tra i prodotti/servizi erogati dalla Regione Lombardia ed il S.I.R. che li supporta.
Cartografia dei processi
Le principali caratteristiche della struttura utilizzata per la cartografia dei
processi per Lombardia Informatica sono mostrate nella figura seguente.
Figura 33 : La cartografia di processo
La struttura si basa su due o, molto più raramente, su tre livelli di processo. Si parla quindi di:
macroprocesso, che rappresenta l’aggregazione dei processi in cui è
coinvolta la struttura organizzativa in analisi. Processo Attività Diagramma delle attività Diagramma di flusso della procedura z Macroprocesso Diagramma di scomposizione del macroprocesso Procedura Operazione
processo che modella le isole produttive, la creazione del valore. Nel
caso in cui ci fosse bisogno di 3 livelli si parlerebbe di ulteriore scomposizione del processo in sottoprocessi. Nel seguito del documento, per semplicità, parleremo però di processo come ultimo livello di scomposizione.
I singoli processi sono poi scomposti in attività che rappresentano le principali fasi che concorrono alla trasformazione degli elementi in entrata (input) nel risultato definito (outcome).
L’operatività a sostegno delle attività (e quindi dei processi) è rappresentata attraverso le procedure che descrivono ad un livello di dettaglio non elevato come l’attività viene eseguita.
La procedura viene descritta attraverso un flusso di operazioni che rappresentano l’intervento di un attore dell’organizzazione nell’ambito di una o più attività dell’azienda: le operazioni, “concatenate”, in logica sequenza o in parallelo conducono ad un definibile risultato intermedio.
Il massimo livello di dettaglio in termini di operatività viene espresso attraverso i compiti. Questi ultimi sono in estrema sintesi le azioni semplici che giornalmente sono eseguite nel compimento di operazioni.
Tipologie di Diagrammi
Le viste utilizzate per la cartografia dei processi sono le seguenti.
Modello grafico che permette di scomporre un macroprocesso in più processi componenti.
Diagramma di
scomposizione
Oggetto descritto: Macroprocesso
Tipologie di oggetti MEGA utilizzati: Processi (macroprocessi, processi)
Natura del diagramma MEGA: Diagramma di processo
Modello grafico che permette di rappresentare le principali attività che compongono il processo, indipendentemente dagli attori che le realizzano. Alle attività sono associate le procedure che ne descrivono l’operatività. I requisiti dei sistemi applicativi a supporto del processo possono essere rilevati al livello di dettaglio delle attività.
Diagramma delle Attività
Oggetto descritto: Processo
Tipologie di oggetti utilizzati: Processi Attività Procedure Attori Messaggi Funzionalità
Natura del diagramma MEGA: Diagramma di processo
Modello grafico utilizzato per descrivere una o più attività nel suo dettaglio operativo. Il diagramma mostra il flusso operativo delle operazioni svolte, i relativi esecutori e i flussi di informazioni scambiati.
Il diagramma di flusso può raggiungere un altissimo livello di dettaglio ed essere rappresentato tramite una successione di compiti - task di livello elementare – anziché di operazioni. I requisiti dei sistemi applicativi a supporto del processo sono rilevati a questo livello di dettaglio. Diagramma di flusso
della procedura
Oggetto descritto: Procedura
Tipologie di oggetti utilizzati: Attori; Operazioni/Compiti Messaggi; Condizioni; Temporizzatori; Note. Funzionalità
Natura del diagramma: Diagramma di flusso
Diagramma che permette di stabilire le relazioni gerarchiche/funzionali tra le unità organizzative dell’azienda.
Organigramma
Cartografia applicativa
Le principali caratteristiche della struttura utilizzata per la cartografia
applicativa dei S.I. da Lombardia Informatica sono mostrate nella figura
seguente.
Figura 34 : La cartografia applicativa
L’applicazione è l’oggetto principale che rappresenta appunto le applicazioni informatiche del sistema, è l’elemento su cui si focalizza la modellazione. Il diagramma di contesto di una applicazione serve a definirne le interazioni con il Sistema Informativo, mentre il diagramma dei servizi ha lo scopo di definire le funzionalità che l’applicazione implementa.
Diagramma dei Servizi
Diagramma di Contesto
Tipologie di Diagrammi
Le viste utilizzate per la Cartografia dei Sistemi Informativi sono le seguenti.
Il contesto dell’applicazione mostra le relazioni dirette che ha l’applicazione con altre applicazioni. In questa vista sono presenti tutte le applicazioni esterne e le basi di dati con cui l’applicazione descritta scambia dati.
Diagramma di Contesto
Oggetto descritto: Applicazione
Tipologie di oggetti MEGA utilizzati: Applicazione
Base dati Messaggio
Natura del diagramma MEGA: Diagramma di Architettura Applicativa
La vista dei servizi raccoglie e propone i servizi forniti da un’applicazione ai suoi clienti.
Diagramma dei Servizi
Oggetto descritto: Applicazione
Tipologie di oggetti utilizzati: Applicazione
Appendice B – Lo strumento di Business Process
Management ed Enterprise Architecture : MEGA
In questa appendice verranno introdotti i concetti di Business Process
Management e di Entrprise Architecture, utilizzati ai fini della nostra
trattazione e verrà mostrato lo strumento impiegato a supporto di tali attività.
Il Business Process Management (BPM) è l’insieme di attività necessarie per definire, ottimizzare, monitorare e integrare i processi aziendali, al fine di creare un processo orientato a rendere efficiente ed efficace il business dell’azienda.
Tanto maggiori sono il numero e la varietà di attori coinvolti nei processi quanto lo è il beneficio che trae l’azienda da una definizione strutturata e puntuale dei medesimi.
L’Enterprise Architecture pone invece il proprio focus sulla definizione del modello organizzativo ed operativo attraverso un insieme di viste interrelate.
L’Enterprise Architecture fornisce quindi le linee guida per sviluppare l’architettura informativa/informatica a supporto del business aziendale.
La gestione dei processi e del patrimonio informativo aziendale hanno seguito la metodologia analizzata nel Capitolo 2.
Mega è lo strumento utilizzato a supporto del Business Process
MEGA
L’ambiente di lavoro MEGA è di supporto alle attività del processo di studio e progettazione dei Sistemi Informativi, svolte da Lombardia Informatica.
MEGA è strutturato secondo la seguente architettura:
Figura 35 : Architettura di MEGA
In particolare l’ambiente di lavoro MEGA è costituito da:
Metodologie per lo studio dei processi e dei sistemi informativi;
Un linguaggio ed una simbologia per la cartografia dei processi e dei
sistemi;
Il repository può essere analizzato con gli opportuni strumenti messi a disposizione da MEGA e sulla base delle informazioni estrapolate sarà possibile realizzare deliverable sotto-forma di documenti e/o siti web.
Figura 36 : Il repository MEGA
A livello architetturale, MEGA è costituito da ambienti (Environment) ognuno dei quali consente a più utenti di condividere gli stessi dati.
L'ambiente di lavoro raggruppa una o più basi dati, compresa la base sistema.
In particolare la base sistema contiene:
Metamodello (struttura della base)
Elenco degli utenti dell'ambiente e il loro profilo Grafo degli utenti
Elenco delle basi
Strumenti standard o personalizzati
Dialoghi(consente di “dialogare” con la base senza passare per
l'interfaccia grafica)
Selettori (strumento che permette di selezionare gli oggetti di un certo
tipo grazie ad uno o più criteri di ricerca)
Descrittori (strumento utilizzato per estrarre le informazioni
memorizzate nella base dati e produrre una documentazione cartacea o ipertestuale)
Modelli di documento
Di seguito riportiamo una breve descrizione dei moduli MEGA utilizzati ai fini dello svolgimento del progetto : MEGA Process, MEGA Architecture e MEGA API.
MEGA Process
MEGA Process è lo strumento per l’analisi di processo che assiste nell’ottimizzazione e nella concezione dei processi aziendali.
Questo modulo permette quindi di descrivere i processi, nonché i principali attori dell’azienda e di valutarli e consente inoltre di descrivere la sequenza dettagliata delle operazioni realizzate durante l’esecuzione delle procedure supportando la definizione delle esigenze di informatizzazione, che verranno trasmesse ai nuclei di progettazione.
Lo strumento offre inoltre funzionalità di zoom per passare progressivamente da un processo alla formalizzazione delle sue procedure, ed è quindi perfettamente allineato con l’approccio top-down.
Sulla base del principio di integrazione, MEGA Process consente di effettuare una sola volta le modifiche che saranno riportate in tutti i processi in cui gli elementi coinvolti sono utilizzati.
Questo modulo consente anche di analizzare le prestazioni dei processi e delle procedure, e calcolare indicatori che evidenziano i possibili miglioramenti da effettuare. In particolare permette di calcolare: il tempo effettivo medio di esecuzione, il tempo totale per ogni risultato possibile, i tempi di attesa e il costo delle diverse risorse.
MEGA Process è anche strumento di reportistica e consente di produrre in maniera automatica, a partire dalla descrizione degli elementi contenuti nel repository, sia documenti che il sito Intranet che descrive i processi e le procedure utilizzate nell’azienda.
Per quanto concerne i documenti, offre la possibilità di modificarne la forma, e crearne dei nuovi.
In particolare:
La generazione del documento viene effettuata automaticamente I documenti hanno una presentazione standardizzata
Le descrizioni vengono automaticamente riutilizzate nei vari documenti L’uniformità tra i documenti è garantiti
MEGA Process offre le massime potenzialità se integrato con MEGA Architecture.
MEGA Architecture
MEGA Architecture permette alle aziende di descrivere e di analizzare l’architettura dei sistemi informativi.
Questo prodotto, quando integrato con MEGA Process permette di intrecciare i due livelli distinti di analisi dell’organizzazione, i processi ed i sistemi informativi, portando ad un modello decisamente esaustivo del funzionamento dell’azienda.
In particolare MEGA Architecture permette di descrivere e di analizzare l’architettura dei sistemi informativi:
Sul piano applicativo : rappresentando le applicazioni e gli strumenti
informatici elementari, le basi dati e i flussi informativi scambiati, i siti delle installazioni dell’azienda, i protagonisti interni ed esterni, le attività, così come le componenti Internet/Intranet;
Sul piano tecnico : considerando i principali mezzi informatici
dell’azienda (reti, server, workstation, stampanti, fire-wall, hub, ecc);
Mega Architecture permette dunque di riprodurre graficamente un sistema informativo, ed in particolare supporta le seguenti tipologie di descrizione:
Rappresentare un sistema informativo complesso ed esteso; Realizzare la mappa delle applicazioni e delle basi dati; Urbanizzare un sistema informativo;
Rappresentare la suddivisione funzionale di un’applicazione; Descrivere le collaborazioni tra le applicazioni;
Ottimizzare un’architettura client / server; Descrivere un’architettura tecnica.
Di segutio viene riportata la figura che mostra le relazioni tra MEGA Process e MEGA Architecture.
Figura 38 : Collegamenti tra MEGA Process e MEGA Architecture
In particolare le operazioni descrivono ciò che gli impiegati dell’azienda fanno, mentre i Servizi descrivono le risorse software che rendono possibile il lavoro degli impiegati.
Pertanto il collegamento operazione\servizio risponde alla domanda “Cosa serve per?"
L’insieme di MEGA Process e MEGA Architecture consente di rappresentare in maniera chiara e coerente l’azienda di riferimento.
In tal modo risulta estremamente semplice stabilire una mappatura dell’organizzazione e del sistema informatico dell’azienda.
P ro c e s s i P ro c e d u re O p e ra z io n i A p p lic a z io n i S e rviz i F u n z io n a lità
MEGA API
MEGA API è il modulo che permette di accedere ai dati contenuti nel repository MEGA.
In particolare l’utente può creare strumenti Windows utilizzando dati MEGA e automatizzare i lavori di amministrazione.
È possibile accedere al repository attraverso il Visual Basic Script (VB Script), scrivendo codice direttamente dall’ambiente, oppure utilizzando il Visual Basic (VB) e producendo dei programmi esterni a MEGA.
Tale modulo viene quindi utilizzato soprattutto per automatizzare gli aggiornamenti al repository con operazioni troppo dispendiose se effettuate manualmente.
Appendice C – Giuda alla simbologia MEGA
I processi e le procedure presenti nell’elaborato, sono stati rappresentati attraverso le simbologie definite da Lombardia Informatica per lo studio e la progettazione dei sistemi informativi.
Di seguito viene illustrata la simbologia utilizzata e il relativo significato.
ATTORE INTERNO
Descrive un'unità operativa interna all’azienda.
Nome della classe MEGA Attore
Campi da valorizzare
• Interno/esterno: interno ATTORE ESTERNO
Specifica tipologia di attore indicante un’entità esterna all’azienda, che comunica con esso tramite scambio di informazioni, documenti o materiali (contribuenti, fornitori, outsourcer).
e Attore Esterno
Nome della classe MEGA Attore
Campi da valorizzare
• Interno/esterno: esterno
Macroprocesso MACROPROCESSO
Aggregazione dei processi in cui è coinvolta l’U.O. in analisi
Nome della classe MEGA Processo
Campi da valorizzare • Commento PROCESSO
È un'aggregazione omogenea di attività interfunzionali finalizzate alla erogazione di un output finito. Tale output rappresenta la creazione del valore.
Nome della classe MEGA Processo
Campi da valorizzare • Commento ATTIVITÀ
Le attività rappresentano la scomposizione del processo nelle principali fasi CONCETTUALI che concorrono alla trasformazione degli elementi in entrata (input) nel risultato definito (outcome).
Le attività possono rappresentare delle fasi sequenziali di un sottoprocesso oppure essere dei trattamenti indipendenti (attività che non sono in una relazione di sequenzialità).
Nome della classe MEGA Attività
Nome della classe MEGA Procedura
Campi da valorizzare
• Commento OPERAZIONE
L’operazione rappresenta l’intervento di un attore dell’organizzazione nell’ambito di una procedura. La procedura operativa è la sequenza di operazioni necessarie a raggiungere un output.
Nome della classe MEGA Operazione
Campi da valorizzare:
• Commento (modalità di esecuzione)
MESSAGGIO
Rappresenta un flusso di informazioni o di
documentazione scambiato all'interno dell'azienda o tra l'azienda e il suo ambiente esterno.
Nome della classe MEGA Messaggio
Campi da valorizzare:
• Commento (solo se necessario a spiegare il contesto della comunicazione)
FUNZIONALITA’
Indica il servizio atteso da un attore per portare a compimento una operazione, o più genericamente, l’esigenza di automatizzazione di una attività. Dire che la funzionalità è coperta significa che tale servizio è effettivamente erogato da una applicazione. Le funzionalità servono ad esprimere, direttamente sui processi, i requisiti per l’evoluzione o per il
concepimento dei sistemi informativi. La funzionalità esprime il requisito in modo
indipendente dalla tecnologia utilizzata per fornirlo.
Nome della classe MEGA Funzionalità
Campi da valorizzare:
• Commento (indica il dettaglio del requisito) CONDIZIONE
Segue un controllo o una verifica. Permette di
scomporre il flusso operativo principale in sottoflussi. La scelta del sottoflusso da percorrere dipende dalla soddisfazione o meno della condizione rappresentata. condizione ?
Nome della classe MEGA Condizione
Collegamenti chiave da valorizzare
• Operazioni/Messaggi successivi e relativi predicati
Nome della classe MEGA Temporizzatore
RIFERIMENTO ESTERNO
Link dinamico ad un file o ad un indirizzo web
intranet/internet raggiungibile dalla postazione in uso.
Nome della classe MEGA Riferimento Esterno Campi da valorizzare
• Tipologia (URL/File) • Percorso
NOTA
A seconda della tipologia specificata è utilizzata per: • fornire ulteriori informazioni relativamente ad
un determinato oggetto (Tipo nota)
• esplicitare delle criticità relative a come certe attività/operazioni/compiti siano mal
supportate o completamente non supportate da alcun sistema applicativo (Tipo anomalia)
Nome della classe MEGA Nota
Campi da valorizzare
• Tipo (Nota, Anomalia) • Commento Nota descrittiva ! Criticità Riferimento esterno
APPLICAZIONE
L’applicazione rappresenta l’automatizzazione di una serie di azioni a sostegno dell’operatività dei processi. Un’applicazione può essere logica (un raggruppamento di applicativi o delle pagine ASP) o fisica (un
componente effettivo, un’eseguibile).
Nome della classe MEGA Applicazione
Caratteristiche da valorizzare • Commento
SERVIZIO
Il servizio è la rappresentazione di una o più funzioni di supporto all’operatività offerte da un’applicazione. Ad esempio, tra i servizi di un browser web, c’è la navigazione della pagine web, la gestione dei bookmark e in alcuni casi la gestione della posta elettronica.
Il servizio va associato alle funzionalità che esprimono i requisiti di un sistema.
Nome della classe MEGA Servizio
Collegamenti chiave da valorizzare • Applicazione che lo definisce • Funzionalità implementata
Nome della classe MEGA Base dati
Caratteristiche da valorizzare • Commento
Collegamenti chiave da valorizzare
• Applicazione che la gestisce/consulta/aggiorna ALTRI OGGETTI
Altri oggetti servono a completare la modellazione per la cartografia dei S.I.:
- Messaggio - Funzionalità
- Riferimento Esterno - Nota
Il loro significato è già stato specificato nella parte di Cartografia di processo.
Appendice D – COBIT & ITIL
COBIT
La metodologia Cobit (Control Objectives for Information and related Technology, a supporto del management per l'It Governance) è stata sviluppata dal'It Governance Institute, un'organizzazione no profit che ha come obiettivo la comprensione e l'utilizzo delle metodologie attraverso il management operativo e gli specialisti It.
Si tratta di un approccio alla verifica dei sistemi informativi, sviluppato per permettere la comprensione alla Direzione, all'audit interno e alle funzioni di controllo della natura dei controlli e delle potenziali criticità esistenti.
Cobit si basa su un framework process-based che si fonda su tre livelli
logici di classificazione (Attività, Processi e Domini), così da permettere l'individuazione per ciascun livello delle risorse IT da sottoporre a controllo. La metodologia si compone di un insieme di 34 obiettivi di controllo, uno per ciascuno dei principali processi IT, e di circa trecento obiettivi di controllo raggruppati in quattro domini: “Organizzazione e pianificazione”, “Acquisizione e realizzazione”, “Erogazione del servizio e assistenza” e monitoraggio.
Il modello di maturità dei processi del Cobit è uno strumento di It governance che consente di misurare i livelli di evoluzione dei processi It rispetto al controllo interno.
Tale modello permette alle organizzazioni di rilevare il proprio grado di maturità in una scala che va dal non esiste (0) a ottimo (5).
Gli auditor possono utilizzare questa scala per supportare la direzione nel governo dell'It, ovvero nell'esercizio della responsabilità di direzione relativamente all'utilizzo dell'Information technology in modo efficace come in ogni altro settore del business.
ITIL
ITIL (Information Technology Infrastructure Library) è il Framework di
management dei processi IT più largamente diffuso ed accettato nel mondo.
È stato sviluppato negli ultimi anni ’80 dall’OGC (Office of Government Commerce), ad oggi conosciuto come CCTA (Central Computer and Telecommunications Agency).
Già dalla metà degli anni ’90 ITIL è stato adottato come standard per il Service Management aziendale.
ITIL è quindi un framework “customizzabile” di best practices che descrive
i processi necessari per governare in maniera efficace ed efficiente l’infrastruttura IT aziendale.
ITIL è definito da un insieme di libri che forniscono le linee guida per tale
gestione, ciascuno per ogni differente aspetto dell’IT Management.
Ad oggi ITIL sta diventando una linea guida “de facto” per la distribuzione dei servizi IT, consentendo alle società che lo utilizzano, di allineare l’informatica con gli obiettivi del business.
Di seguito viene riportato e descritto il Framework ITIL.
Service Delivery (Erogazione Servizi): (comprende i Processi di
Service Level Management, Availability Management, IT Services Continuity Management, Capacity Management, Financial Management of IT Services - in pratica Gestione dei Costi dei Servizi)
Comprende i processi richiesti per la pianificazione e l’erogazione di servizi IT di qualità.
Service Support (Supporto Servizi): (comprende la funzione di: Service
Desk -sviluppo del Help Desk,- e i Processi: Incident Management, Problem Management, Change Management, Configuration Management, Release Management).
Descrive i processi associati con il supporto e le attività di manutenzione giornaliere associate con la fornitura dei servizi IT.
ICT Infrastructure Management (Gestione Infrastruttura):comprende
tutti gli aspetti della gestione dell’infrastruttura ICT, dall’identificazione delle esigenze di business, all’offerta in gara, sino al test, all’installazione, alla messa in funzione, all’operatività e all’ottimizzazione dei componenti ICT e dei servizi IT.
Planning to Implement Service Management (Pianificazione dello
Sviluppo della Gestione Servizi): esamina i problemi e le attività coinvolte nella pianificazione, implementazione e miglioramento dei processi di Service Management all’interno di una organizzazione. Esso indirizza anche i problemi associati con i cambiamenti culturali ed organizzativi (Cultural and Organisational Change), lo sviluppo di una visione, la strategia ed il più appropriato metodo di approccio.
Application Management (Gestione delle Applicazioni): questo
modulo copre il ciclo di vita dello sviluppo software e del successivo utilizzo e pone l’accento sulle interrelazioni tra la concezione e sviluppo
The Business Perspective (La Prospettiva Aziendale): fornisce consigli
ed una guida per aiutare il personale IT a comprendere come possa contribuire al raggiungimento degli obiettivi di business e come i loro ruoli e servizi possano essere meglio allineati ed utilizzati per massimizzare il loro contributo.
Security Management (Gestione della Sicurezza): dettaglia il processo
di pianificazione e gestione di un definito livello di sicurezza per le informazioni ed i servizi IT, inclusi tutti gli aspetti relativi alla reazione agli incidenti di sicurezza. Include anche la valutazione e la gestione dei rischi e delle vulnerabilità, e l’implementazione delle contromisure a costi giustificabili.
Appendice E – ADO, ODBC, OLE DB
Un po’ di storia
Non molti anni fa, l'unico modo per accedere alle fonti di dati era quello di utilizzare le API ODBC.
ODBC è tuttora un protocollo standard introdotto per mascherare le differenze tra i vari database.
L'API ODBC consiste in un insieme di funzioni C in grado, tramite opportuni driver, di accedere a diverse fonti di dati.
Questo modo di operare si è rivelato da subito molto ostico e poco adatto per tecnologie orientate agli oggetti.
Per questa ed altre ragioni venne introdotto DAO, un modello orientato agli oggetti che mascherava l'operato delle API ODBC.
DAO può essere utilizzato da Visual Basic, da Visual C++ e dai prodotti della famiglia Office.
Il limite più grande di DAO è quello di poggiarsi ad un motore di database locale denominato Jet Engine.
Tuttavia, con la versione 4 di Visual Basic vide la luce una nuova metodologia studiata appositamente per connessioni a database remoti ed applicazioni di tipo enterprise.
Stiamo parlando di RDO che purtroppo poteva essere utilizzata esclusivamente da Visual Basic. Il modello ad oggetti RDO è simile a DAO, ma la conversione da un modello all'altro non era del tutto immediata. Successivamente, grazie a Visual Basic 5 ed Office 97, il modello DAO è stato potenziato introducendo ODBCDirect. Il vantaggio principale di ODBCDirect risiedeva principalmente nel fatto che utilizzava un modello del tutto simile a DAO, ma senza utilizzare il Jet Engine locale per connessioni a database remoti. Nonostante tutto ODBCDirect non ebbe molto successo.
La novità fu introdotto con la prima versione di ADO, che poteva essere utilizzata già a partire da Visual Basic 5.
Applicazioni server ASP scritte in VBScript o Java Script utilizzano ADO come unico strumento per accedere al database.
ADO non deve essere visto come l'ennesimo modello che si poggia a ODBC per accedere ai dati.
L'architettura di ADO è strutturalmente diversa rispetto a tutti i suoi predecessori, in quanto ADO è l'ultimo strato di una tecnologia denominata OLEDB, un modello orientato agli oggetti che, utilizzando COM, è in grado di dialogare con diverse fonti di dati in un modo totalmente nuovo.
Prima di dare una descrizione architetturale di ADO introduciamo i concetti propedeutici di ODBC e OLE DB, già introdotti nella resoconto della storia.
ODBC
ODBC sta per Open Database Connectivity ed è un meccanismo pensato agli inizi degli anni ‘90 per uniformare dietro una comune interfaccia API l'accesso ad un crescente numero di database server – sia desktop che Client/Server.
ODBC definisce un insieme di funzioni che attraverso oggetti logici come il datasource, la sessione, il resultset permettono di incapsulare sia la tabella che il comando che effettivamente ritrova i record e li restituisce all'utente. ODBC oggigiorno è supportato praticamente da tutti i maggiori protagonisti del mercato database a parte ovviamente Microsoft : Oracle, IBM, Informix, Sybase, MySQL, Interbase eccetera.
ODBC è uno standard accettato in tutto il mondo e su tutte le piattaforme. ODBC dispone di un motore runtime (ODBC Manager) che riceve le chiamate alle singole API del ODBC SDK e individua il giusto driver ODBC capace di dialogare con il motore di database.
ODBC Manager prima e il driver poi, formano il canale tra l'applicazione client e il database server. Ovviamente basta cambiare driver perché la stessa identica applicazione, con immutata la logica di business, riesca a parlare con un diverso database server.
Questa architettura presenta tuttavia un problema di fondo.
Ciascun database dispone di un suo linguaggio di query, in una certa misura diverso da server a server.
Tuttavia la API comune ha bisogno di un linguaggio unico e possibilmente universale per formulare le query.
Questo linguaggio è stato individuato in SQL e SQL alla fine è diventato anche il linguaggio di riferimento dei database server.
SQL è stato standardizzato nel 1992, ma differenze di programmazione tra piattaforma e piattaforma restano. Ciascun database alla fine dispone del suo SQL che è compatibile con uno o più livelli di standard, ma conta alcune estensioni proprietarie che complicano il porting del codice.
Tutta l'architettura ODBC ha finito per essere legata strettamente a SQL non tanto a livello dei client quanto a livello dei driver sottostanti la cui struttura non è così generale come ci si potrebbe aspettare. Nessuno si è mai posto il problema di trattare con ODBC dati che non fossero provenienti da tabelle relazionali limitando al testo ASCII e alle tabelle Excel (in ogni caso dati rettangolari) le pochissime escursioni fuoripista.
In termini di architettura, i dati che la sorgente dati recupera sono copiati direttamente nella memoria dell'applicazione e ciò fa sì che letture/scritture corpose, formate da ampi blocchi di record, siano privilegiate. ODBC dà il meglio di sé quando si tratta di fare pesanti fetching di record sequenziali. È un po' meno efficiente se si tratta di saltare da un record all'altro e fare query selezionate di certi record e non di altri.
Una volta che i driver ODBC sono diventati uno dopo l'altro affidabili e stabili, ODBC è diventato un modo assolutamente ragionevole di accedere ai dati, scavalcando anche l'uso delle API dirette fornite dai database vendor. Anzi, il driver ODBC ha finito per assorbire buona parte delle API almeno nel caso dei database di livello enterprise.
OLE DB
OLE DB è l'interfaccia di programmazione strategica a livello di sistema per l'accesso ai dati.
È un'architettura di database basata su COM (componenti) che consente di accedere in rete o tramite Internet a numerosi tipi di origini dati, inclusi i dati relazionali e non, i file di posta, i file flat e i fogli di calcolo.
OLE DB generalizza il concetto di client e di server introducendo consumer e provider come terminologie alternative.
Nell'architettura OLE DB l'applicazione che accede ai dati viene definita "consumatore di dati", mentre il programma che consente l'accesso nativo ai dati viene definito "provider di database”.
Il driver della tecnologia ODBC, viene rimpiazzato dal provider, mentre il ruolo dell'ODBC Manager viene totalmente assorbito dal Service Control Manager (SCM) di COM ovvero quell'entità che si preoccupa di individuare e creare in locale, in remoto e in ogni luogo istanze del componente COM indicato.
Mentre il client ODBC maneggia direttamente i dati all'interno della sua memoria, il client OLE DB ricorre ai servizi di un modulo consumer e i dati sono restituiti tramite un oggetto COM che espone oltre ai dati anche i metodi per lavorarci sopra (rowset). Il dialogo avviene sempre tramite interfacce COM.
Dall'applicazione si parla sempre direttamente con il modulo che capisce SQL e che è in grado di restituirci i dati.
Di seguito viene riportata l’immagine che raffigura l’architettura OLE DB e la confronta con quella ODBC.
Figura 42 : Architettura OLE DB Vs architettura ODBC
OLE DB accede pertanto alle singole fonti dati attraverso un cosiddetto provider.
Ad oggi sono stati sviluppati da Microsoft:
un provider per ODBC utilizzabile per tutte le fonti dati per le quali
esista un driver ODBC (ovviamente le prestazioni non sono granché dato che è necessario attraversare un livello in più prima di arrivare al motore di DataBase);
un provider nativo per il motore Jet, per l’accesso ai dati contenuti in
DataBase MDB; è quello che viene maggiormente preso in considerazione in questo tutorial;
un provider nativo per SQL Server; un provider nativo per Oracle; un provider nativo per Index Server;
un provider nativo per Microsoft ADSI (Active Directory Service
ADO
ADO (ActiveX Data Objects) nasce da Microsoft nell’inverno del 1996.
È un componente COM (Component Object Model) che si interfaccia con i provider OLE DB e che facilita la scrittura di applicazioni per l'accesso ai dati (consumer).
Rappresenta uno strato tra il linguaggio di programmazione e l’interfaccia OLE DB.
ADO è composto da più livelli di oggetti :
Connection (rappresenta la connessione al database) Recordset (rappresenta un insieme di record del database) Command (rappresenta un comando SQL )
Record (rappresenta un insieme di dati)
Stream (rappresenta uno stream di dati, ad esempio proveniente da un
file di testo o da una pagina web)
Error (immagazzina errori)
Field (rappresenta un campo del database) Parameter (rappresenta un parametro SQL)
Di seguito riportiamo una rappresentazione di come ADO si connette a OLE DB.
Appendice F –
S.I.S.M.A. : Il Codice
Di seguito viene riportato il codice dei Moduli SISMA descritti nel Paragrafo 5.2.
Modulo Configuration.bas
Sub Config()
On Error GoTo Eccezione
'Leggi da file .ini il nome dell'environmentPath
environmentPath = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Mega", "environmentPath", "", environmentPath, 300, ".\Miofile.ini")
environmentPath = Left$(environmentPath, i%) environmentPath = LTrim$(RTrim$(environmentPath))
'Leggi da file .ini il nome della Base di Mega
dbMega = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Mega", "dbName", "", dbMega, 300, ".\Miofile.ini") dbMega = Left$(dbMega, i%)
dbMega = LTrim$(RTrim$(dbMega))
'Leggi da file .ini il nome dell'utente
megaUserName = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Mega", "megaUserName", "", megaUserName, 300, ".\Miofile.ini")
megaUserName = Left$(megaUserName, i%) megaUserName = LTrim$(RTrim$(megaUserName))
'Leggi da file .ini la password dell'utente MEGA
megaUserPwd = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Mega", "megaUserPwd", "", megaUserPwd, 300, ".\Miofile.ini")
megaUserPwd = Left$(megaUserPwd, i%) megaUserPwd = LTrim$(RTrim$(megaUserPwd))
'Leggi da file .ini il provider del db
dbProvider = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Database", "dbProvider", "", dbProvider, 300, ".\Miofile.ini")
dbUser = Left$(dbUser, i%) dbUser = LTrim$(RTrim$(dbUser))
'Leggi da file .ini la password del db
dbPwd = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Database", "dbPwd", "", dbPwd, 300, ".\Miofile.ini") dbPwd = Left$(dbPwd, i%)
dbPwd = LTrim$(RTrim$(dbPwd))
'Leggi da file .ini il path del file di backup
backupPath = Space$(300) num = Trim(Str(n))
i% = GetPrivateProfileString("Backup", "path", "", backupPath, 300, ".\Miofile.ini")
backupPath = Left$(backupPath, i%) backupPath = LTrim$(RTrim$(backupPath))
Exit Sub
Eccezione:
Log (Err.Description)
Modulo DbConnection.bas
Sub LeggiDb()
On Error GoTo Eccezione
Dim rs As ADODB.Recordset
Set cn = New ADODB.Connection
Set rs = New ADODB.Recordset
connessione = "Provider=" & dbProvider & ";Password=" & dbPwd & ";User ID=" & dbUser & ";Data Source=" & dbSource & ";Persist Security Info=True"
cn.Open (connessione)
sqlCountAttivi = "SELECT COUNT(*) FROM strutture_organizzative WHERE STATO_STRUTTURA=0 AND DENOMINAZIONE!='Null'"
rs.Open sqlCountAttivi, cn lenghtAttivi = rs.Fields(0) rs.Close
sqlCountInattivi = "SELECT COUNT(*) FROM strutture_organizzative WHERE STATO_STRUTTURA=1 AND DENOMINAZIONE!='Null'"
rs.Open sqlCountInattivi, cn lenghtInattivi = rs.Fields(0) ReDim attoriAttiviCode(lenghtAttivi) ReDim attoriInattiviCode(lenghtInattivi) ReDim attoriAttiviName(lenghtAttivi) ReDim attoriInattiviName(lenghtInattivi) rs.Close
sqlAttivi = "SELECT CODICE_HR,DENOMINAZIONE FROM strutture_organizzative WHERE STATO_STRUTTURA=0 AND DENOMINAZIONE!='Null' ORDER BY CODICE_HR DESC"
rs.Open sqlAttivi, cn
For i = 1 To lenghtAttivi
attoriAttiviCode(i) = rs("CODICE_HR") nome1 = rs("DENOMINAZIONE")
nome2 = Replace(nome1, Chr(34), "") 'elimina il carattere " eventualmente presente nella stringa denominazione
attoriAttiviName(i) = Replace(nome2, "'", "") 'elimina il carattere ' eventualmente presente nella stringa denominazione
attoriInattiviName(i) = Replace(nome2, "'", "") 'elimina il carattere ' eventualmente presente nella stringa denominazione
rs.MoveNext Next rs.Close Set rs = Nothing cn.Close Set cn = Nothing Exit Sub Eccezione: Log (Err.Description) End Sub
Modulo MegaConnection.bas
Sub ConnettiMega()
On Error GoTo Eccezione
' Definisco il path dell'ambiente
Set oMegaEnvironment = oMegaApplication.Environments.Item(environmentPath)
'Setto l'utente
'Set oMegaUser = oMegaEnvironment.Users.Item(userName)
' Setto il nome dell'utente e la password
oMegaEnvironment.CurrentAdministrator = megaUserName oMegaEnvironment.CurrentPassword = megaUserPwd
' Definisco il nome della base
Set oMegaDatabase = oMegaEnvironment.Databases.Item(dbMega)
'Setto la transazione
Set oMegaTransaction = oMegaEnvironment.Transactions.Item(1)
'Eseguo backup logico
file = backupPath & Year(Date) & Month(Date) & Day(Date) & " " & Hour(Time) & "h" & Minute(Time) & "m" & Second(Time) & "s" & " " & oMegaDatabase.Name & ".mgr" prop = "Meta=off,data=full,Technical=off,CommandFormat=mgr,fileopen=rewrite" oMegaDatabase.LogicalSave file, prop
Set oMegaRoot = oMegaDatabase.Open() ' questa non so se serve
Set oMegaRoot = oMegaRoot.GetRoot()
Exit Sub
Eccezione:
Log (Err.Description)
Modulo MegaUpdate.bas
Sub UpdateInsertMega()
On Error GoTo Eccezione
Dim myAttori As MegaCollection
Dim attoreDoppio As MegaObject
Dim attorePadre As MegaCollection
Dim myAttore As MegaObject
Dim attoriCollection As MegaCollection
Dim attoriSelection As MegaCollection
Dim key As MegaCollection
Dim insertKey As MegaObject
Set attoriCollection = oMegaRoot.GetCollection("Attore") 'collezione degli attori sul repository
For i = 1 To lenghtAttivi
queryAttore = "SELECT [Attore] WHERE [Codifica attore]='" & attoriAttiviCode(i) & "'"
Set myAttori = oMegaRoot.GetSelection(queryAttore)
If myAttori.Count = 0 Then 'L'attore non esiste e va inserito
nomeAttore = attoriAttiviName(i)
If Len(nomeAttore) > 63 Then
'Se nome dell'attore maggiore di 63 caratteri non si riesce a crearlo con il suo vero nome
Set myAttore = attoriCollection.Create
myAttore.SetProp "Codifica attore", attoriAttiviCode(i) 'Inserisce valore nell'attributo Codifica attore
myAttore.SetProp "Commento", "Il nome dell'attore estratto era maggiore di 63 caratteri. Il suo nome originario era : " & nomeAttore 'Inserisce commento
Else
'Il nome dell'attore da inserire è inferiore a 63 caratteri
Set attoriSelection = oMegaRoot.GetSelection("SELECT [Attore] WHERE [Nome]='" & nomeAttore & "'")
If attoriSelection.Count = 0 Then
Set myAttore = attoriCollection.Create(nomeAttore)
myAttore.SetProp "Codifica attore", attoriAttiviCode(i) 'Inserisce valore nell'attributo Codifica attore
Else
Set myAttore = attoriCollection.Create
myAttore.SetProp "Codifica attore", attoriAttiviCode(i) 'Inserisce valore nell'attributo Codifica attore
myAttore.SetProp "Commento", "Esisteva già un attore i nome :" & nomeAttore 'Inserisce commento
End If
'Cerco attore padre
codicePadre = "RL1"
codiceFiglio = Mid(attoriAttiviCode(i), 4) 'toglie RL1 dalla stringa
Dim j As Integer
j = 1
While Mid(codiceFiglio, j, 1) Like "0" j = j + 1
Wend
If j < 6 Then 'J indica il j-esimo carattere di codiceFiglio !=0 in questo caso l'attore può essere una struttura, una Unità operativa oppure una Unità organizzativa
If j = 4 Then
myAttore.SetProp "Livello organizzativo", "UO"
ElseIf j = 6 Then
myAttore.SetProp "Livello organizzativo", "ST"
ElseIf j = 7 Then
myAttore.SetProp "Livello organizzativo", "PO"
End If
padre = Mid(codiceFiglio, j, 7 - j - 1) 'elimino gli 0 in testa al codice del figlio e tolgo gli ultimi due caratteri
For k = 0 To j
codicePadre = codicePadre & "0"
Next
codicePadre = codicePadre & padre 'individua l'attore padre dell'attore
ElseIf j = 6 Then 'La'attore può essere una Dc, una DG oppure una SG
If Mid(codiceFiglio, 7) Like "0" Then
codicePadre = codicePadre & "000000" & Mid(codiceFiglio, 6, 1) myAttore.SetProp "Livello organizzativo", "SG"
ElseIf Mid(codiceFiglio, 7) Like "1" Then
End If
If codicePadre Like "0" Then
'L'attore è un assessorato. Non ha attore padre
Else
queryAttorePadre = "SELECT [Attore] WHERE [Codifica attore]='" & codicePadre & "'"
Set attorePadre = oMegaRoot.GetSelection(queryAttorePadre) If attorePadre.Count = 0 Then
'Non esiste l'attore padre
Else
'esiste l 'attore padre del nuovo inserito attori = oMegaRoot.GetCollection("Attore") Set a = attorePadre.Item(1) Set b = a.GetCollection("Componente") b.Add myAttore End If End If Else
'l'attore esiste e non va creato
End If Next oMegaRoot.MegaCommit MsgBox ("Terminato") Exit Sub Eccezione: Log (Err.Description) End Sub Sub UpdateDeleteMega()
On Error GoTo Eccezione
Dim myAttoriTrovati As MegaCollection Dim myAttori As MegaCollection Dim myAttore As MegaObject Dim delKey As MegaObject
For i = 1 To lenghtInattivi
queryAttoriTrovati = "SELECT [Attore] WHERE [Codifica attore]='" & attoriInattiviCode(i) & "'"
Set myAttoriTrovati = oMegaRoot.GetSelection(queryAttoriTrovati)
If myAttoriTrovati.Count = 0 Then
Else
'Nel repository MEGA ci sono strutture inattive da eliminare
queryAttore = "SELECT [Attore] WHERE [Codifica attore]='" & attoriInattiviCode(i) & "'" & _
" AND [Messaggio-Inviato] is null AND [Messaggio-Ricevuto] is null" & _ " AND [Actor (UML)] is null AND [Applicazione] is null" & _
" AND [Applicazione gestita] is null AND [Attività] is null" & _ " AND [Base Dati] is null AND [Class] is null" & _
" AND [Generico] is null AND [Indicatore] is null" & _
" AND [Libreria utilizzata] is null AND [Obiettivo realizzato] is null" & _
" AND [Operazione] is null AND [Problema riscontrato] is null" & _
" AND [Requisito soddisfatto] is null AND [Riferimento esterno] is null" & _
" AND [Rischio] is null AND [Ruolo] is null" & _
" AND [Scheda di valutazione] is null AND [TaggedValue] is null" & _ " AND [Vincolo] is null AND [isa] is null" & _
" AND [Documento] is null AND [Controllo gestito] is null" & _
" AND [Documento diffuso] is null AND [Funzione aziendale] is null" & _ " AND [Ipotesi] is null AND [Posto di lavoro] is null" & _
" AND [Procedura] is null AND [Processo] is null" & _
" AND [Processo Gestito] is null AND [Progetto] is null" & _
" AND [Progetto realizzato] is null AND [Raccoglitore di dati] is null" & _
" AND [Requisito imposto] is null AND [Sito] is null" & _ " AND [Specifico] is null AND [Workflow gestito] is null" & _ " AND [Obiettivo assegnato] is null" & _
" AND [Parola-chiave] is null" & _
" AND ([Descrizione] is null OR[Descrizione].[Natura]='Organigramma' OR [Descrizione].[Nome breve]='Organigramma')" & _
" AND ([Diagramma] is null OR [Diagramma].[Natura]='Organigramma' OR [Diagramma].[Nome breve]='Organigramma')" & _
" AND ([Componente] is null OR [Componente].[Livello Organizzativo]='SG'
OR [Componente].[Livello Organizzativo]='DG'OR [Componente].[Livello
Organizzativo]='DC' OR [Componente].[Livello Organizzativo]='UO' OR
[Componente].[Livello Organizzativo]='ST' OR [Componente].[Livello
Organizzativo]='PO')" 'vincolo su impatto del componente
Set myAttori = oMegaRoot.GetSelection(queryAttore)
If myAttori.Count = 1 Then
Set myAttore = myAttoriTrovati.Item(1)
myAttore.Delete ("NoHierarchy") ' gli oggetti che dipendono gerarchicamente dall'oggetto eliminato, non vengono a loro volta eliminati
Else
'L'attore ha impatto e non può essere eliminato; l'attore viene collegato alla parola chiave da eliminare
End If End If Next oMegaRoot.MegaCommit MsgBox ("Terminato") Exit Sub Eccezione: Log (Err.Description) End Sub
Modulo ErrorHandler.bas
Sub Log(exc As String)
Dim FF As Integer
FF = FreeFile
Open ".\log\log.txt" For Append As #FF Print #FF, Now & " : " & exc
Close #FF