simplengineering
Service Oriented Architects
RE T RO -M O D E L LAZI ON E
CON CE TTUAL E D I BAS I D I
D ATI RE LA Z I ON AL I
L'APPROCCIO simpleSOAD® 2.0
SE-LMA_WP2010101303
SIMPLE ENGINEERING 2004 - 2011
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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.
WWW.SIMPLE-ENG.COM
BLOG.SIMPLE-ENG.COM
SIMPLESOAD® IS A REGISTERED TRADEMARK OF SIMPLE ENGINEERING.
Il presente documento è rilasciato sotto la licenza Creative Commons Attribuzione-Non commercialeNon opere derivate 2.5 Italia disponibile al sito web
http://creativecommons.org/licenses/by-nc-nd/2.5/it/
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®.
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 2 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 3 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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.
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 4 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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].
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 5 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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).
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 6 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 7 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
tipi di fatti utilizzando convenzioni la cui comprensione è intuitiva (un esempio
è fornito nel diagramma della Figura 4).
class Circolarità Anagrafica
+comune
nascita
+data
dece sso
data
+data
nascita
comune
+comune
resid enza
sesso
+nome
cittadino
Meaning and
Repre senta tion
+cognome Vocabulary::text +codice
com une
Cittadini per sesso: sesso
m
f
Figura 4. Esempio di BOM/SBVR.
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 8 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
PROCESSI, METODI E PRATICHE PER IL DATABASE REVE RSE
ENGINEERING
Contenuto del
DB
Schema
Fisico
Viste Utente
in DDL
Viste Utente
in Linguaggio
Host
Estrazione
Strutture Dati
Schema
Globale in DDL
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
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 9 /15
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 10 /1 5
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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 DAT ABASE REVERSE ENGINE ERING
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
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 11 /1 5
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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.
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 12 /1 5
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
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),
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 13 /1 5
simpleSOAD® 2.0


Retro-modellazione concettuale di basi di dati relazionali
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 - http://adm.omg.org/
[ADM/KDM] Architecture-Driven Modernization (ADM): Knowledge Discovery Meta-Model
(KDM), OMG; Version 1.1, Document Number: formal/2009-01-02; Standard document
URL: http://www.omg.org/spec/KDM/1.1
[Axis2] Apache Axis2/Java, http://ws.apache.org/axis2/
[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, 1983.
[Batini et al. 1992] Batini, C., Ceri, S., Navathe, S., B., Conceptual Database Design,
Benjamin/Cummings, 1992.
[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 2010.
[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, 1992.
[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), 1991.
[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] http://kdmanalytics.com/kdmsdk/download.php
[OCL] Object Constraint Language
http://www.omg.org/spec/OCL/2.2
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
-
Version
2.2
-
formal/2010-02-01
-
SE- L MA_ WP2 01 0 10 13 0 3 - 14 /1 5
simpleSOAD® 2.0
Retro-modellazione concettuale di basi di dati relazionali
[SBVR] Semantics of Business Vocabulary and Business Rules (SBVR), v1.0 - OMG Available
Specification - OMG Document Number: formal/2008-01-02 - Standard document URL:
http://www.omg.org/spec/SBVR/1.0/PDF
[simpleSOAD] simple engineering - simpleSOAD® 2.0 Reference Manual - R2010070101
[UML] - Unified Modeling Language: Superstructure - version 2.3 - formal/2010-05-05 http://www.omg.org/spec/UML/2.3/Superstructure
SI MPL E EN GI N EERI NG 2 00 4 - 2 01 1
SE- L MA_ WP2 01 0 10 13 0 3 - 15 /1 5