RETRO-MODELLAZIONE CONCETTUALE DI BASI DI DATI RELAZIONALI

Transcript

1 simplengineering Service Oriented Architects RETRO-MODELLAZIONE CONCETTUALE DI BASI DI DATI RELAZIONALI L'APPROCCIO simplesoad 2.0 SE-LMA_WP SIMPLE ENGINEERING

2 SIMPLE ENGINEERING IS AN INDEPENDENT EUROPEAN GROUP SPECIALIZED IN SERVICE ORIENTED ARCHITECTURE (SOA) AND BUSINESS PROCESS MANAGEMENT (BPM). SIMPLE ENGINEERING: - OPERATES AS AN ARCHITECTURE & ENGINEERING FIRM AND PROVIDES A COMPLETE RANGE OF PROFESSIONAL SERVICES: ADVISING, PLANNING, ANALYSIS, DESIGN, CAPACITY PLANNING, SERVICE IMPLEMENTATION MANAGEMENT, TEST, VALIDATION, VERIFICATION, GOVERNANCE, AUDIT AND ASSESSMENT OF SOA/BPM; - HAS DEVELOPED SIMPLESOAD, A COMPLETE, DETAILED AND PROVEN METHODOLOGICAL FRAMEWORK FOR ANALYSIS, DESIGN AND CAPACITY PLANNING OF SOA/BPM, BASED ON A MODEL-DRIVEN APPROACH AT THE CONCEPTUAL, LOGICAL AND PHYSICAL LEVELS; - RUNS AN ARCHITECTURE & ENGINEERING SCHOOL, PROVIDES LEARNING, COACHING AND TECHNOLOGY TRANSFER SERVICES, CERTIFICATES COMPANIES AND PROFESSIONALS; - GRANTS COMMERCIAL LICENSES OF THE SIMPLESOAD METHODOLOGICAL FRAMEWORK TO CERTIFIED COMPANIES AND PROFESSIONALS; - RUNS AN ARCHITECTURE & ENGINEERING LAB AND PROVIDES DEPLOYMENT, CONFIGURATION, CONSULTING, SUPPORT, LEARNING AND COACHING SERVICES ON COTS (COMMERCIAL OFF-THE-SHELF) AND FOSS (FREE OPEN SOURCE SOFTWARE) SOA/BPM TECHNOLOGICAL INFRASTRUCTURE FRAMEWORKS. BLOG.SIMPLE-ENG.COM SIMPLESOAD IS A REGISTERED TRADEMARK OF SIMPLE ENGINEERING. Il presente documento è rilasciato sotto la licenza Creative Commons Attribuzione-Non commerciale- Non opere derivate 2.5 Italia disponibile al sito web o richiedendone copia a Creative Commons, 171 Second Street, Suite 300, San Francisco, California, 94105, USA. Il marchio simplesoad incluso nel documento è un marchio registrato di simple engineering s.r.l. Il marchio simplesoad può essere usato quando è riprodotto nel documento - e questo è utilizzato secondo i termini della licenza Creative Commons Attribuzione-Non commerciale-non opere derivate 2.5 Italia - o per citarne il titolo, salvo che tali usi possano essere associati all'offerta, alla promozione o alla fornitura di servizi, ivi inclusi servizi di consulenza, sul framework metodologico simplesoad. Fatto salvo quanto sopra e salvo espresso consenso scritto da parte di simple engineering s.r.l., è vietato qualsiasi uso del marchio simplesoad. SIMPLE ENGINEERING SE-LMA_WP /15

3 INTRODUZIONE Non sono rare le situazioni in cui un'organizzazione gestisce sistemi patrimoniali (legacy) di cui ha perso parzialmente la conoscenza: il sistema è utilizzato quotidianamente, le sue decisioni sono accettate, ma è difficile spiegarle e giustificarle. Le evoluzioni sono difficili e costose. L'organizzazione padroneggia solo parzialmente e in modo frammentato il modello concettuale del sistema. Il task di retro-modellazione dei sistemi patrimoniali e, in particolare, di retromodellazione concettuale delle basi di dati patrimoniali - che ne costituisce solo un aspetto, anche se molto importante, e che è l'oggetto specifico di questo documento - può essere decomposto in due sub-task: La costituzione di una rappresentazione fedele e al giusto livello di dettaglio e precisione del sistema patrimoniale. Tale rappresentazione costituisce la base per poter in seguito compiere la retro-modellazione a livello concettuale, e cioè per ricostruire il corpo concettuale di cui lo schema fisico è una rappresentazione. La costituzione del corpo concettuale, a partire dal modello del sistema patrimoniale risultato dell'attività di cui al punto precedente. Questo documento presenta i modelli, i processi, i metodi, le pratiche e gli strumenti per la retro-modellazione concettuale delle basi di dati patrimoniali, tema che oggi interessa particolarmente le imprese e le amministrazioni. L'interesse è dovuto al fatto che le basi di dati patrimoniali ospitano spesso risorse informative d'importanza strategica e di grande valore, ma che la loro struttura attuale, risultato di anni di manutenzione, frena, se non impedisce, la possibilità di offrire servizi a valore aggiunto su tali risorse. I modelli, sia della base patrimoniale sia del corpo concettuale, devono appoggiarsi su meta-modelli standard. Questo consente la loro comprensione da parte di persone che non hanno partecipato alla loro costruzione, e a cui sono affidati, ad esempio, compiti di progettazione di applicazioni e servizi. Inoltre il modello concettuale deve permettere di eseguire altri compiti per trasformazione (eventualmente automatica) di modelli, in applicazione dell'approccio MDA (Model Driven Architecture) [MDA]. Il paragrafo 'Meta-modelli standard per il Database Reverse Engineering' presenta in modo conciso i meta-modelli standard per rappresentare (a) la struttura fisica della base, i componenti software e hardware e l'ambiente operativo, e (b) il corpo concettuale del dominio business. I processi, i metodi e le pratiche di modellazione devono permettere di costruire modelli standard (cioè conformi a meta-modelli standard) di qualità, in modo efficace ed efficiente. Un metodo, anche molto rapido e produttivo, la cui applicazione conduce alla costruzione di un modello non standard ha un valore molto relativo. I metodi e le pratiche utilizzabili si basano fondamentalmente sull'interazione con gli esperti di dominio, e cioè: (a) per la modellazione fisica della base patrimoniale, con gli amministratori, gli esercenti e i progettisti; (b) per la retro-modellazione del corpo concettuale e delle regole business del dominio, con gli esperti e analisti business, i progettisti e gli sviluppatori. Il paragrafo 'Processi, metodi e pratiche per il Database Reverse Engineering' presenta succintamente un SIMPLE ENGINEERING SE-LMA_WP /15

4 processo, dei metodi e delle pratiche che permettono di costruire rapidamente e a costi contenuti dei modelli standard di qualità, sia della base di dati sia del corpo concettuale. Gli strumenti di supporto alle attività di modellazione devono da un lato poter manipolare perfettamente i meta-modelli standard - evitare di indurre un lock-in proprietario sul modello - e dall'altro essere disponibili sul mercato. UML costituisce il linguaggio di base per la modellazione [UML], e quindi lo strumento principale di supporto dei task di modellazione è un UML Modeler che manipola modelli interoperabili (e cioè conformi allo standard UML 2). Il programma ADM/KDM (vedi in seguito) tende a stimolare lo sviluppo di tool con capacità d'ispezione e di colletta automatica d'informazioni sulle basi di dati patrimoniali. Il paragrafo 'Strumenti per il Database Reverse Engineering' presenta concisamente la problematica degli strumenti di supporto. META-MODELLI STANDARD PER IL DATABASE REVERSE ENGINEERING ADM/KDM L'OMG ha lanciato nel 2003 la task force Architecture-Driven Modernization, la cui "missione" è stata definita: "Create specifications and promote industry consensus on modernization of existing applications" [ADM]. La task force ha prodotto nel 2007 la versione 1.0 e nel 2009 la Versione 1.1 del Knowledge Discovery Meta-model [ADM/KDM]. KDM specifica l'insieme dei concetti comuni che permettono di descrivere e comprendere i sistemi esistenti, in vista appunto di una loro "modernizzazione". Il meta-modello KDM, costituito da classi e associazioni UML, permette di rappresentare le informazioni, le loro relazioni e gli ambienti operazionali dei sistemi software esistenti all interno di un organizzazione. Figura 1. Layers, packages e separation of concerns in KDM. In particolare il meta-modello KDM fornisce un formato comune di scambio che garantisce l interoperabilità tra gli strumenti di analisi e modernizzazione a supporto della modellazione dei sistemi patrimoniali. Il meta-modello rappresenta gli elementi dei sistemi patrimoniali come reti di classi e associazioni predefinite, organizzate in dodici packages idealmente collocati in quattro strati (layer) - vedi la Figura 1, ripresa dalle specifiche KDM. SIMPLE ENGINEERING SE-LMA_WP /15

5 Ogni package definisce un insieme di elementi del meta-modello il cui scopo è di rappresentare un certo aspetto della conoscenza dei sistemi patrimoniali. Nel livello Infrastructure layer, Core e kdm contengono gli elementi comuni del metamodello e costituiscono l infrastruttura per gli altri package. Source definisce gli elementi per costruire l'inventario dei sorgenti dei sistemi software esistenti e specifica il meccanismo dei collegamenti di tracciabilità tra gli elementi KDM e la loro originale rappresentazione nel codice sorgente. Nel livello Program Elements layer, Code contiene i costrutti necessari a rappresentare elementi del codice eseguibile e le loro associazioni, mentre Action si focalizza sulla descrizione del comportamento e sulle relazioni tra il flusso di controllo e il flusso dei dati. Nel livello Resource layer, Platform definisce i costrutti che permettono di rappresentare l ambiente operativo di runtime del sistema patrimoniale, mentre UI fornisce i tratti per rappresentare le interfacce utente. Event descrive gli elementi del meta-modello (stati, transizioni ed eventi) necessari a rappresentare aspetti comportamentali delle applicazioni. Data fornisce i costrutti in grado di rappresentare organizzazioni di dati anche molto complesse, come ad esempio file di record, database relazionali, flussi di dati strutturati, schemi XML e documenti. Infine, nel livello Abstractions layer, Structure fornisce i costrutti per definire gli elementi architetturali (sottosistemi, package, ecc.) delle applicazioni patrimoniali; Conceptual definisce invece i costrutti del modello concettuale del dominio business; Build definisce gli elementi capaci di catturare l'aspetto della configurazione e dell'istallazione delle applicazioni. La presentazione esaustiva di KDM è fuori della portata di questo documento. Per i bisogni dell'attività di Database Reverse Engineering sono necessari i soli package Data (Resource layer) e Conceptual (Abstractions layer). Il package Data offre gli elementi necessari a modellare un database relazionale fisico. Nello specifico: (i) la classe Catalog consente di rappresentare una base di dati relazionale (il contenitore padre di tutti gli schemi relazionali di un particolare dominio); (ii) la classe RelationalSchema permette di modellare ogni singolo schema contenuto nel database di riferimento; (iii) la classe DataEvent permette di rappresentare i diversi eventi che possono verificarsi all interno di un database e che possono far scatenare l esecuzione di stored procedure (conosciuta anche con il nome di trigger). In particolare, un trigger è rappresentato da un elemento CallableUnit contenuto da uno specifico RelationalSchema (il container); il CallableUnit a sua volta è associato all evento che lo scatena (rappresentato da un DataEvent) attraverso una relazione di Calls. Per quanto riguarda le tabelle e le viste presenti in un particolare schema, queste sono rappresentate rispettivamente dalle classi RelationalTable e RelationalView, mentre le corrispondenti colonne (riferite anche con il nome di field) sono modellate dalla classe ItemUnit associandogli gli opportuni tipi rappresentati dalle classi Datatype. Le chiavi primarie di una tabella (o vista) sono rappresentate dalla classe UniqueKey che costituisce un gruppo di uno o più ItemUnit (colonne), mentre le chiavi esterne sono rappresentate dalla classe ReferenceKey anch essa costituente un gruppo di uno o più ItemUnit: la relazione tra la chiave esterna e la chiave primaria è rappresentata dalla classe KeyRelationship. Infine, la classe Index è utilizzata per rappresentare eventuali indici all interno di una tabella. Per i vincoli d integrità intra-relazionale (vincoli di tuple e/o vincoli di dominio) è utilizzato il linguaggio standard UML Object Constraint Language [OCL]. SIMPLE ENGINEERING SE-LMA_WP /15

6 Il package Conceptual fornisce gli elementi di tracciatura del mapping fra il modello KDM e il modello SBVR (Semantics of Business Vocabulary and Business Rules [SBVR]). In particolare, fornisce le classi TermUnit per referenziare i concetti e nomi SBVR, FactUnit per referenziare i tipi di fatti SBVR e RuleUnit per referenziare le regole strutturali e operative SBVR (vedi Figura 2 ripresa dalle specifiche KDM). Figura 2. SVBR e KDM. L'interesse di un tale mapping è la tracciabilità del corpo concettuale e delle regole business al modello della base di dati patrimoniale costruito a partire dal package Data. SBVR Abbiamo visto che KDM (package Conceptual) utilizza, per la rappresentazione del livello concettuale, SBVR, che emerge come lo standard federatore per la rappresentazione dei modelli concettuali, dei vocabolari e delle regole business strutturali e operative. SBVR permette di esprimere i concetti, i termini, le relazioni tra i concetti e le regole di un dominio business in un formato che, se da un lato è molto vicino al linguaggio naturale - si tratta di linguaggio naturale semplificato e standardizzato - dall'altro è perfettamente rigoroso (ha la potenza espressiva della logica del primo ordine estesa). SBVR risolve brillantemente il dilemma tra grado di leggibilità del modello da parte degli esperti di dominio e livello di formalizzazione e disambiguazione dello stesso, all'intenzione degli architetti e i progettisti. A partire da SBVR, notazione propria al Business Model, esistono approcci di trasformazione meccanica verso il Platform Independent Model e il Platform Specific Model (vedi Figura 3 ripresa dalle specifiche SBVR). SIMPLE ENGINEERING SE-LMA_WP /15

7 Figura 3. Posizione di SBVR in MDA. Le capacità espressive di SBVR possono essere riassunte nei seguenti punti: Categorizzazione gerarchica e multidimensionale dei concetti, con tassonomie e schemi di categorizzazione. Definizione di sinonimi, abbreviazioni, rinvii, dizionari multilingue per un solo insieme di significati. Specifica formale e non ambigua di definizioni intensionali ed estensionali dei concetti. Definizione delle connessioni tra i concetti, e cioè la struttura semantica di un universo del discorso in un dominio business. Formulazione di regole business strutturali e operative sulla base della struttura del corpo concettuale. Proposizione di modelli di documento per facilitare la leggibilità e la trasmissione del corpo concettuale e delle regole. Specifiche di base per strumenti di visualizzazione e navigazione all'interno dei corpi concettuali e terminologici e delle collezioni di regole su base semantica (per i fornitori di strumenti di supporto alla modellazione SBVR). Gestione delle nozioni di appartenenza e di condivisione dei corpi concettuali e delle collezioni di regole - integrazione di corpi concettuali creati separatamente - integrazione di dizionari non SBVR (minimizzazione del numero di definizioni from scratch). SBVR propone due stili complementari di rappresentazione: La rappresentazione testuale, di tipo lemma enciclopedico che, per ogni concetto fornisce elementi sotto forma di didascalie come: Definizione, Sorgente, Dizionario, Concetto generale, Tipo di concetto, Necessità, Possibilità, Schema di riferimento, Nota, Esempio, Sinonimo, Vedi, Tema ecc.. La rappresentazione diagrammatica (BOM - Business Object Model), che si appoggia sulle strutture UML [UML] per la rappresentazione dei concetti e dei SIMPLE ENGINEERING SE-LMA_WP /15

8 tipi di fatti utilizzando convenzioni la cui comprensione è intuitiva (un esempio è fornito nel diagramma della Figura 4). class Circolarità Anagrafica data +data dece sso +comune nascita comune +data nascita +comune resid enza sesso cittadino +nome +cognome Meaning and Repre senta tion Vocabulary::text +codice com une Cittadini per sesso: sesso m f Figura 4. Esempio di BOM/SBVR. SIMPLE ENGINEERING SE-LMA_WP /15

9 PROCESSI, METODI E PRATICHE PER IL DATABASE REVERSE ENGINEERING Schema Fisico Contenuto del DB Viste Utente in DDL Estrazione Strutture Dati Schema Globale in DDL Viste Utente in Linguaggio Host Modello KDM Frammenti di Codice in Linguaggio Host Concettualizzazione Strutture Dati Modello SBVR Figura 5. Processo di Database Reverse Engineering. In termini grossolani, il problema di reverse engineering (RE) per una base di dati può essere formulato come segue: date delle espressioni nel linguaggio DDL/Host di strutture dati esistenti (schemi globali e/o viste) e dati i requisiti operativi conosciuti (come ad esempio: DBMS utilizzato, requisiti di prestazione, ecc.) trovare un possibile schema concettuale di cui queste strutture dati costituiscono una rappresentazione. Il processo di Database Reverse Engineering proposto è illustrato nel diagramma della Figura 5. Il processo proposto organizza i due task essenziali della retro-modellazione concettuale di basi di dati patrimoniali, e cioè: (i) Recupero di strutture dati esistenti dalle espressioni in linguaggio DDL/Host (il processo inverso della progettazione fisica, denominato anche Estrazione delle Strutture Dati); (ii) Costruzione di un possibile schema concettuale che ne definisce la semantica (processo inverso della progettazione, denominato anche Concettualizzazione delle Strutture Dati). ESTRAZIONE DELLE STRUTTURE DATI Questa fase produce una descrizione completa delle strutture dati in accordo allo schema relazionale fisico della base di dati sotto studio. Il risultato finale di tale processo è un SIMPLE ENGINEERING SE-LMA_WP /15

10 modello KDM dello schema globale della base dati. In sintesi, il processo si compone di due sottofasi eseguite in iterazione (nei casi "difficili" in almeno due cicli): Individuazione e formalizzazione delle strutture - con l'aiuto dell'esperto, sono individuate e in seguito formalizzate negli elementi del package Data le strutture dati esplicite e implicite (nascoste) che sono sotto il controllo del DBMS. Le sorgenti di tale attività di analisi sono lo schema fisico, le viste utente, lo schema in DDL, e il contenuto stesso del data base. Individuazione e formalizzazione dei vincoli - sempre con l'aiuto e sotto la sorveglianza dell'esperto, individuazione e formalizzazione dei vincoli d'integrità sulle strutture modellate nel passo precedente; il modello KDM elaborato/prodotto nella fase precedente è arricchito di annotazioni contenenti espressioni nel linguaggio OCL [OCL]; le sorgenti di tale attività sono i frammenti di codice in DDL e in linguaggio Host, sia per i vincoli e i trigger (stored procedures), sia per le viste utente. Il processo comporta un'analisi approfondita della struttura fisica del database (espressioni DDL) e del codice sorgente delle applicazioni che interagiscono con la base stessa, presupponendo perciò una forte interazione con il conoscitore della base di dati fisica e l esperto della programmazione (nel linguaggio utilizzato - per esempio COBOL). Il modello KDM finale è così ottenuto per costruzione, in maniera incrementale e iterativa, dall analisi degli elementi (tabelle, indici, vincoli intra-relazionali, inter-relazionali, ecc.) presenti nel DBMS all'analisi degli statement SQL presenti nel codice sorgente. A causa della grande complessità della struttura fisica di basi di dati che hanno più di un decennio di vita (constatata sperimentalmente), causata dagli interventi continui e ripetuti di manutenzione e di ottimizzazione, le due sotto-fasi presentate sono spesso compiute in almeno due cicli: nella prima iterazione la seconda sotto-fase (Individuazione e formalizzazione dei vincoli) rende spesso evidenti le carenze e le imperfezioni del risultato della prima (Individuazione e formalizzazione delle strutture). Una seconda iterazione sulle strutture è quindi necessaria per consolidare il modello "statico" e in seguito per finalizzare i vincoli. E' consigliabile organizzare alla fine della prima iterazione una review indipendente di progetto. CONCETTUALIZZAZIONE DELLE STRUTTURE DATI L'obiettivo di questa fase è di determinare la semantica dello schema logico del database partendo dal modello KDM (con annotazioni OCL) ottenuto nella fase di estrazione delle strutture dati. Il risultato di tale processo è un modello SBVR che rappresenta i concetti e i tipi di fatti del dominio sotto studio e le regole business strutturali (vincoli). Le regole operative (consegne per l'azione), che si appoggiano sui dati contenuti nella base e quindi sui concetti retro-modellati, non sono generalmente formalizzate nell'attività di retromodellazione della base dati, ma piuttosto all'occasione dell'analisi e modellazione dei processi business in essere, attività la cui descrizione esula dal contenuto di questo documento. Anche questa fase è eseguita in due sotto-fasi: Costruzione del corpo concettuale - Il processo di concettualizzazione si articola in tre attività: (i) De-ottimizzazione dello Schema, (ii) Indipendenza dal DBMS e (iii) Normalizzazione Concettuale. Nella fase di De-ottimizzazione SIMPLE ENGINEERING SE-LMA_WP /15

11 dello Schema sono evidenziati ed eliminati dal modello KDM i costrutti non semantici, in particolare le strutture di ottimizzazione (ad esempio gli indici). Nella fase di Indipendenza dal DBMS invece si evidenziano i costrutti idiosincratici del DBMS utilizzato, che sono sostituiti da costrutti equivalenti, indipendenti dal DBMS utilizzato. Infine nella fase di Normalizzazione Concettuale è ricostruita la struttura concettuale di alto livello del dominio di riferimento, che generalmente si è persa sia durante la fase originaria di progettazione del database, sia soprattutto a causa delle azioni di manutenzione e ottimizzazione successive. In particolare in tale fase sono applicate tecniche di trasformazione di schemi, eliminazione delle ridondanze (de-normalizzazione) e integrazione di schemi attraverso l applicazione di operatori concettuali di Fusione, Decomposizione, Generalizzazione e Specializzazione. Il modello SBVR finale prodotto è così ottenuto in maniera incrementale e iterativa attraverso una trasformazione di modelli; ogni trasformazione è effettuata ponendo la massima attenzione alla conservazione dell equivalenza semantica tra il modello di partenza e quello di arrivo, con il risultato che il modello finale SBVR così ottenuto risulta semanticamente rappresentativo del modello KDM. Questa sotto-fase è eseguita dall'analista con l'aiuto all'esperto, a cui il modello è ovviamente sottoposto per review e validazione. Formalizzazione delle regole business - In questa fase, le regole (vincoli, condizioni...) espresse in OCL sono trasformate in regole SBVR sulla base del corpo concettuale prodotto nella prima fase e del mapping tra tale corpo e il modello KDM. Si tratta anche qui di reverse modeling, del processo inverso rispetto alla progettazione che consiste nel tradurre le regole SBVR in espressioni OCL. Le regole SBVR ottenute sono ovviamente sottoposte all'esperto, ma non per validazione nel senso della progettazione: il problema da risolvere in questa fase non è se le regole sono corrette dal punto di vista del business, ma se traducono fedelmente a livello business ciò che è effettivamente implementato. Se la prima fase (Estrazione delle strutture dati) e la sotto-fase di cui al punto precedente hanno fornito risultati corretti, la trasformazione dei vincoli OCL in regole SBVR è quasi-meccanizzabile [Cabot et al. 2010]. Se la conclusione del processo è che le regole implementate non sono corrette dal punto di vista business, questo conferma a posteriori la necessità del processo di DRE. Anche questa sequenza è spesso eseguita in due cicli in cui il corpo concettuale e la collezione di regole business sono prima prodotti in versione provvisoria e in seguito in versione finale. Review indipendenti di progetto sono necessarie nei momenti chiave della fase e del processo nella sua interezza. STRUMENTI PER IL DATABASE REVERSE ENGINEERING L'attività di Database Reverse Engineering è un'attività di modellazione. Lo strumento principale di tale attività è un UML Modeler, di preferenza allineato alla versione 2.3 di UML (la versione 2 comporta modifiche sostanziali del meta-modello UML della versione 1). Un UML Modeler standard (IBM Rational Software Architect, Sparx Enterprise Architect,...) copre l'80% dei bisogni di modellazione (ADM/KDM, SBVR BOM). In virtù dell'approccio nativo UML, l'interoperabilità dei modelli rispetto ai Modeler è garantita (grazie a XMI, formato standard interoperabile d'import/export di modelli prodotti da Modeler differenti). In SIMPLE ENGINEERING SE-LMA_WP /15

12 data odierna, SBVR non è ancora dotato di strumenti specifici per costruire e manipolare corpi concettuali e collezioni di regole business, presenti come prodotti standard disponibili sul mercato. Un requisito importante per tali strumenti è la facilità d'integrazione con un UML Modeler. Da segnalare comunque lo sviluppo di un plug-in KDM per Eclipse [KDMAnalytics]. Un'altra pista di estremo interesse riguarda i tool che facilitano l'estrazione automatica d'informazioni dal sistema patrimoniale. Tali strumenti sono necessariamente basati su sistemi multi-agenti dotati di un livello d'"intelligenza", che percorrono il sistema patrimoniale (eventualmente distribuito) per estrarne le informazioni riguardanti gli strati bassi del modello. In data odierna, tale approccio non ha ancora prodotto strumenti disponibili sul mercato. CONCLUSIONE Abbiamo presentato in questo documento l'approccio di simple engineering per la retro-modellazione concettuale di basi di dati patrimoniali. Gli aspetti salienti di tale approccio possono essere riassunti nei punti seguenti: Approccio Model Driven Engineering, per modellazione e trasformazione di modelli. Approccio ADM/KDM, di modernizzazione delle applicazioni. Distinzione tra il modello fisico della base di dati patrimoniale e il retromodello concettuale del dominio business rappresentato. Adozione di meta-modelli standard (OMG), sia per il modello fisico (KDM) sia per il modello concettuale (SBVR). Distinzione tra i modelli e i processi, metodi e pratiche per costruirli - il modello è comprensibile anche da parte di chi non ha partecipato e non ha le competenze e l'esperienza per partecipare alla sua costruzione. Metodo di costruzione dei modelli sistematico, sostenibile e rapido, grazie anche alla scelta degli standard - facilità di modellazione in UML da parte dell'architetto, facilità di lettura e comprensione del corpo SBVR da parte dell'esperto business. Strumenti di supporto largamente disponibili (UML Modeler) e interoperabili, che non inducono il lock-in proprietario sui modelli prodotti. In una situazione in cui l'organizzazione che gestisce una base di dati patrimoniale ha perduto la padronanza del modello concettuale, la retro-modellazione concettuale appare come un task ineludibile per affrontare progetti di architetture di servizi (SOA). Uno dei punti di forza della service orientation è che la distinzione tra sistema e servizio (contratto) consente di integrare nelle architetture di servizi i sistemi patrimoniali, tra cui le basi di dati strategiche dell'organizzazione, attraverso la realizzazione di wrapper che implementano il passaggio dall'interfaccia alla funzione. Gran parte del codice dei wrapper è generato automaticamente attraverso framework disponibili e largamente diffusi come Axis2 [Axis2], che fornisce lo skeleton da riempire con invocazioni alle funzioni del sistema patrimoniale - nel caso qui trattato, alle funzioni di lettura e aggiornamento della base di dati. SIMPLE ENGINEERING SE-LMA_WP /15

13 Il problema tecnico dell'interoperabilità è spesso di facile soluzione: resta il problema più complesso della collaborazione applicativa (di cui l'interoperabilità è condizione necessaria ma non sufficiente) tra il sistema patrimoniale e altri sistemi e utenti, utilizzatori potenziali dei servizi offerti dalla base. Questa collaborazione può rivelarsi difficile, in una situazione in cui l'organizzazione non conosce il corpo concettuale di cui la base è una rappresentazione: la definizione stessa di contratti di servizio sostenibili appare problematica. Una volta ricostruito il corpo concettuale, si aprono più possibilità: Ristrutturazione della base: a partire dal retro-modello concettuale, definire un nuovo modello logico e fisico. simplesoad 2.0, il framework metodologico di simple engineering, propone una procedura, basata su risultati conosciuti, per passare da un corpo concettuale sostenibile SBVR, e cioè un corpo concettuale che possiede certe caratteristiche che facilitano la trasformazione, ad uno schema di base relazionale in quinta forma normale per trasformazione meccanica diretta [simplesoad]. La tracciabilità del processo di retro-modellazione concettuale e della trasformazione verso lo schema in quinta forma normale permette di gestire facilmente la migrazione dei dati dalla base patrimoniale alla base ristrutturata. La base ristrutturata, essendo una rappresentazione diretta della persistenza dei fatti espressi in coerenza con il modello concettuale, facilita la definizione e l'implementazione di servizi a valore aggiunto. La controindicazione alla ristrutturazione della base è nella quantità (e qualità!) del codice applicativo patrimoniale preesistente da modificare per permettergli di accedere alla base ristrutturata. Definizione di servizi (contratti) a partire dal corpo concettuale retro-modellato e implementazione degli adapter necessari. La controindicazione di questa seconda scelta, che preserva il codice patrimoniale di accesso alla base, è nell'eventuale complessità degli adapter. Le due possibilità vanno valutate caso per caso, sapendo che la seconda è comunque provvisoria, e che alla fine esigenze di affidabilità funzionale e di manutenibilità imporranno la ristrutturazione della base. Il gruppo simple engineering offre, nell'ambito della sua attività di Studio, prestazioni standard di retro-modellazione concettuale di basi di dati patrimoniali. I modelli SBVR prodotti possono essere multi-lingua (inglese e francese oltre che italiano). Dopo una breve valutazione preliminare, simple engineering offre una prestazione forfettaria che ha come risultati: il modello KDM (fisico), il modello SBVR (concettuale), della base di dati patrimoniale. A questa prestazione di primo livello può aggiungersi la prestazione di ristrutturazione della base che ha come risultato: il modello concettuale SBVR sostenibile (per predisporlo alla trasformazione in modello UML), il modello UML (ottenuto per trasformazione meccanica dal modello SBVR), SIMPLE ENGINEERING SE-LMA_WP /15

14 il modello relazionale in quinta forma normale (ottenuto per trasformazione meccanica del modello UML), la procedura di migrazione dalla base patrimoniale alla base ristrutturata. Anche questa seconda prestazione può essere valutata su base forfettaria. A corredo, lo Studio simple engineering offre naturalmente tutta la gamma delle sue prestazioni standard. La retro-modellazione concettuale delle basi di dati patrimoniali è anche oggetto di attività di formazione e coaching da parte della Scuola simple engineering, nell'ambito di un progetto o come pura attività didattica, e di prestazioni di veglia tecnologica e di benchmarking di tool da parte del Lab simple engineering. RIFERIMENTI [ADM] Architecture-Driven Modernization - [ADM/KDM] Architecture-Driven Modernization (ADM): Knowledge Discovery Meta-Model (KDM), OMG; Version 1.1, Document Number: formal/ ; Standard document URL: [Axis2] Apache Axis2/Java, [Batini et al. 1983] Batini, C., Lenzerini, M., Moscarini, M., View integration, in Methodology and tools for data base design, Ceri, S., (Ed.)North-Holland, [Batini et al. 1992] Batini, C., Ceri, S., Navathe, S., B., Conceptual Database Design, Benjamin/Cummings, [Cabot et al. 2010] Cabot, J., Pau, R., Raventos, R., From UML/OCL to SBVR specifications: A challenging transformation, Information Systems, Volume 35, Issue 4, June [Joris et al. 1992] Joris, M., Van Hoe, R., Hainaut, J-L., Chandelon M., Tonneau C., Bodart F. et al., PHENIX : methods and tools for database reverse engineering, in Proc. 5th Int. Conf. on Software Engineering and Applications, Toulouse, 7-11 December, [Hainaut 1991] Hainaut, J-L, Database Reverse Engineering, Models, Techniques and Strategies, in Preproc. of the 10th Conf. on Entity-Relationship Approach, San Mateo (CA), [Hainaut et al. 1993] Hainaut, J-L., Chandelon M., Tonneau C., Joris M., Contribution to a Theory of Database Reverse Engineering, in Proc. of the IEEE Working Conf. on Reverse Engineering, Baltimore, May 1993 [KDMAnalytics] [OCL] Object Constraint Language - Version formal/ SIMPLE ENGINEERING SE-LMA_WP /15

15 [SBVR] Semantics of Business Vocabulary and Business Rules (SBVR), v1.0 - OMG Available Specification - OMG Document Number: formal/ Standard document URL: [simplesoad] simple engineering - simplesoad 2.0 Reference Manual - R [UML] - Unified Modeling Language: Superstructure - version formal/ SIMPLE ENGINEERING SE-LMA_WP /15