• Non ci sono risultati.

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

N/A
N/A
Protected

Academic year: 2021

Condividi "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"

Copied!
45
0
0

Testo completo

(1)

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.

(2)

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

(3)

 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.

(4)

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

(5)

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

(6)

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

(7)

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

(8)

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

(9)

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;

(10)

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.

(11)

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.

(12)

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.

(13)

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.

(14)

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à

(15)

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.

(16)

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

(17)

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à

(18)

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)

(19)

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

(20)

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

(21)

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

(22)

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.

(23)

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.

(24)

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.

(25)

 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

(26)

 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.

(27)

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.

(28)

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.

(29)

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.

(30)

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.

(31)

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.

(32)

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

(33)

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)

(34)

Di seguito riportiamo una rappresentazione di come ADO si connette a OLE DB.

(35)

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")

(36)

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)

(37)

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

(38)

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

(39)

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)

(40)

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

(41)

'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

(42)

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

(43)

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

(44)

End If End If Next oMegaRoot.MegaCommit MsgBox ("Terminato") Exit Sub Eccezione: Log (Err.Description) End Sub

(45)

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

Figura

Figura 33 : La cartografia di processo
Diagramma  di
Diagramma  che  permette  di  stabilire  le  relazioni  gerarchiche/funzionali  tra  le  unità  organizzative  dell’azienda
Figura 34 : La cartografia applicativa
+7

Riferimenti

Documenti correlati

Even though the RBM state is by far more effective for N´eel states endowed with a particularly simple sign structure, it provides a significant improvement over the original

Le formule di corrispondenza realizzano una corrispondenza biunivoca tra punti dell'ellissoide (definiti dalle coordinate geografiche , ) e punti della carta (definiti

Il reticolato geografico è presente sulla cornice con inviti intervallati di 1’ = 60”. La tecnica più corretta e precisa consiste nel disegnare il reticolato unendo gli inviti

Il Datum è definito dall’ellissoide di Bessel con 3 diversi orientamenti a seconda della zona (Genova – Roma M.Mario e Castanea delle Furie) Ufficialmente la rappresentazione

The HERSCHEL payload con- sisted of a telescope, HERSCHEL EUV Imaging Telescope (HEIT), and two coronagraphs, HECOR (helium corona- graph) and SCORE (sounding

In summary, the three mutants showed different struc- tural and thermodynamic properties: N84D has no effect on structure and stability despite the acquisition of a negatively

The Italian data collection followed the research design proposed for this work package (see EU-OSHA, 2017a) with two peer dialogue workshops (employers and employers’

• EQUIVALENTE: rappresenta fedelmente le aree; viene utilizzata per costruire carte tematiche dell’intera..