Indice 1 Introduzione........................................... 1 2 Il contesto............................................ 9 2.1 Il progetto MODA-ML................................9 2.1.1 Il Tessile/Abbigliamento italiano..............9 2.1.2 Obiettivi e risultati del progetto............10 2.2 ebXML............................................. 11 2.2.1 L’iniziativa ebXML............................12 2.2.2 La tecnologia ebXML...........................12 2.2.3 Il progetto MODA-ML ed ebXML..................14 3 Le tecnologie......................................... 17 3.1 Lo Unified Modeling Language (UML)................17 3.1.1 Che cos’è e che cosa non è UML................18 3.1.2 Architettura OMG per meta-modelli.............19 3.1.3 Il meta-modello UML...........................21 3.1.4 Estensibiltà e Profili di UML.................23 3.1.5 La notazione UML..............................28 3.2 UN/CEFACT Modeling Methodology (UMM)..............30 3.2.1 Introduzione..................................30 3.2.2 Fasi e workflow di UMM........................31 3.2.3 Il meta-modello UMM...........................32 3.2.4 Workflow: prodotti e concetti chiave..........35 3.3 Lo XML Metadata Interchange (XMI).................39 I
226
Embed
tesi.fabio.web.cs.unibo.ittesi.fabio.web.cs.unibo.it/twiki/pub/Tesi/UMLeEBXML/Tesi... · Web view1 Introduzione. 1. 2 Il contesto. 9. 2.1 Il progetto MODA-ML. 9. 2.1.1 Il Tessile/Abbigliamento
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
L’ENEA (Ente Nazionale per l’Energia l’Ambiente e le nuove tecnologie), in
collaborazione con altri enti di ricerca e tecnologici, sta sviluppando il progetto
MODA-ML (Middleware tOols and Documents to enhAnce the textile/clothing
supply chain through xML) [MML] per la standardizzazione dei dati di scambio
nella filiera del Tessile/Abbigliamento.
Il progetto è nato dall’esigenza di fornire una soluzione al problema, sempre più
diffuso negli ultimi anni, dell’interoperabilità tra imprese in scenari settoriali di
commercio elettronico e si è posto l’obiettivo di sviluppare un’architettura per
l’interoperabilità basata sull’adozione della tecnologia XML, in particolare sul
framework standard ebXML (electronic business XML) [ebXML], per le imprese
del settore Tessile/Abbigliamento italiano.
L’idea fondamentale è offrire alle imprese del settore un linguaggio comune per lo
scambio dei dati che possa essere facilmente integrabile nei processi produttivi delle
aziende più grandi e già dotate di un loro sistema informativo e,
contemporaneamente, che sia anche di facile utilizzo per le imprese più piccole e
con un basso livello di informatizzazione. Gli operatori che compongono la filiera
dispongono di sistemi informativi aziendali strutturalmente diversi e non
interoperabili; quindi, per permettere loro di scambiarsi i dati in assoluta libertà e
senza l'obbligo di utilizzare la stessa applicazione si è scelto di adottare XML per la
definizione di documenti elettronici scambiati tra i sistemi aziendali, stabilendo così
un'unica interfaccia condivisa da tutti.
Attualmente, il progetto ha già definito il linguaggio comune per lo scambio di
messaggi nella filiera del Tessile/Abbigliamento, ovvero il vocabolario specifico per
le transazioni del settore. Il vocabolario contiene informazioni sui tipi di documento
XML che vengono scambiati tra i segmenti della filiera e definisce una struttura
gerarchica formata da una serie di processi ed attività commerciali: ogni processo
1
racchiude una sequenza di attività composte da alcune transazioni, ciascuna
corrispondente a sua volta ad un singolo documento.
La gestione del vocabolario avviene per mezzo di un database chiamato MODA-
ML Dictionary (o Dizionario di MODA-ML). Questo strumento offre molte
funzionalità, in particolare funge da repository bilingue (italiano e inglese) di tutte le
strutture dati create e si occupa della loro gestione e del loro riutilizzo.
Con l’evolversi del progetto, il numero di processi e documenti di business definiti
dal vocabolario è cresciuto notevolmente e, di conseguenza, è aumentata la
complessità del framework. Ciò ha reso evidente un’esigenza non prevista all’inizio
dei lavori: rappresentare in modo completo e non ambiguo tutti gli scenari e i
documenti di business supportati dal vocabolario, ossia realizzare i modelli di tali
scenari e documenti e consentirne l’aggiornamento.
Ad una prima analisi i requisiti necessari per soddisfare efficacemente questa nuova
necessità sono risultati essere:
1. il Dizionario di MODA-ML deve essere l’unica fonte da cui attingere le
informazioni per la realizzazione dei modelli;
2. poiché il Dizionario supporta due lingue, devono essere realizzate altrettante
versioni di ciascun modello;
3. i modelli da realizzare devono rispettare un formalismo (da identificare), in
modo da fornire una rappresentazione della realtà non ambigua;
4. nei modelli devono essere trasferite tutte le informazioni del Dizionario,
ovviamente nei limiti imposti dal formalismo scelto;
5. deve essere realizzata un’applicazione che automaticamente acquisisce le
informazioni dal Dizionario di MODA-ML e le utilizza per realizzare gli
opportuni modelli.
Questo bisogno risulta evidente se si considera il numero piuttosto elevato,
ed il suo possibile aumento, di informazioni che compongono il vocabolario.
Un’applicazione automatica, infatti, consentirebbe di produrre rapidamente i
modelli di ogni nuovo scenario di business e garantirebbe l’assenza di errori
che potrebbero essere introdotti da una redazione manuale. Inoltre, in caso di
modifiche al vocabolario, l’aggiornamento manuale dei dati sarebbe limitato
2
al Dizionario, poiché per i relativi modelli si potrebbe sfruttare l’applicazione
automatica.
6. conseguentemente al requisito imposto al punto 5, i modelli devono essere
realizzati tanto in un formato machine-readable quanto in un formato
leggibile dall’utente.
Il lavoro di tesi si è svolto presso il centro di ricerche ENEA “Ezio Clementel” di
Bologna e si inserisce nell’ambito di sviluppo del progetto MODA-ML, con
l’intento di raggiungere, nel rispetto dei requisiti esposti precedentemente, due
obiettivi:
1. mappare i concetti definiti nel vocabolario MODA-ML nei formalismi del
sottoinsieme di UMM adottato da ebXML;
2. trovare (o progettare) e implementare uno strumento che denomineremo
MODA-MICS (MODA-ML Modeling Interface to CASE Systems) per la
realizzazione e la gestione automatica di questi modelli.
A tal fine, il lavoro è stato così organizzato:
individuazione e analisi delle metodologie e degli strumenti per la
modellazione dei processi di business (UMM e UML);
studio dell’applicabilità di tali metodologie alla realtà MODA-ML;
definizione dei modelli dei processi di business MODA-ML sulla base delle
conoscenze acquisite precedentemente;
adozione di un formato machine-readable (XMI) per la rappresentazione dei
modelli proposti;
progettazione e implementazione di un’applicazione software per la
realizzazione e visualizzazione dei modelli.
Questo lavoro, oltre al presente capitolo introduttivo, è composto da altri quattro
capitoli di cui si riassume brevemente il contenuto.
Nel capitolo 2 si fornisce una breve descrizione del contesto nel quale si è svolto il
lavoro di tesi, ossia il progetto MODA-ML ed ebXML. In particolare, sono illustrati
i problemi del settore Tessile/Abbigliamento italiano che il progetto si è proposto di
risolvere, le linee di intervento adottate e i risultati concreti già ottenuti. Inoltre,
3
essendo il framework MODA-ML ispirato allo standard ebXML, vengono introdotte
le caratteristiche salienti di questa architettura.
Nel capitolo 3 sono presentate le principali tecnologie adottate per la definizione e
la realizzazione dei modelli dei processi di MODA-ML: UMM, UML e XMI.
Lo scopo non è fornire una documentazione completa su queste tecnologie, ma dare
un’idea degli strumenti e delle opportunità che ciascuna di esse offre, al fine di
rendere più chiaro come e perché sono state utilizzate.
UMM (UN/CEFACT Modeling Methodology) è la metodologia per la modellazione
degli scenari di business sviluppata da UN/CEFACT ed esplicitamente
raccomandata dalle specifiche ebXML, quindi costituisce il riferimento per la
definizione dei modelli dei processi di business di MODA-ML.
UML (Unified Modeling Language) è il linguaggio grafico di modellazione adottato
da UMM, quindi il linguaggio utilizzato per i modelli MODA-ML. In particolare,
nel capitolo 3 si analizzano il meccanismo di estensione e il concetto di profilo
UML: il primo perché è utilizzato frequentemente per la definizione dei modelli di
business MODA-ML, il secondo perché il meta-modello definito da UMM per la
descrizione degli scenari di business può essere fondamentalmente considerato un
profilo UML.
Infine, XMI (XML Metadata Interchange) è il linguaggio machine-readable in cui si
è deciso di rappresentare i diagrammi UML dei processi MODA-ML. La scelta di
questo linguaggio è stata ovvia poiché il linguaggio, oltre ad essere stato definito per
la diretta rappresentazione dei modelli UML, si basa su XML, quindi risponde
perfettamente all’esigenza di avere un formato processabile da applicazioni
automatiche.
In particolare, si cerca di spiegare perché il linguaggio XMI consente la diretta
definizione dei diagrammi UML e di evidenziare un aspetto negativo del linguaggio:
il linguaggio non specifica in alcun modo come rappresentare graficamente gli
elementi XMI. Le specifiche, infatti, si limitano ad indicare due meccanismi per far
ciò: meccanismo di estensione (usato ad esempio da Rational Rose) o foglio di stile
XSLT. Per i fini di questa tesi è stato adottato un foglio di stile XSLT che trasforma
il documento XMI in documento SVG.
Nel capitolo 4 viene illustrata la struttura del vocabolario definito dal progetto
4
MODA-ML, al fine di dare una visione chiara e precisa della realtà da modellare.
Successivamente, si analizza la soluzione proposta da ebXML per la modellazione
di scenari di business tramite diagrammi UML e sono presentati i risultati del lavoro
svolto per associare i concetti definiti da ebXML e quelli definiti dal vocabolario
MODA-ML. Lo scopo di quest’analisi è stabilire se i modelli proposti da ebXML si
prestano a rappresentare gli scenari MODA-ML. Dall’analisi si deduce che tali
modelli non supportano tutti i concetti previsti nel Dizionario di MODA-ML.
Inoltre, si ritiene che non forniscano, all’utente inesperto di metodologie di business,
una visione semplice e immediata della realtà che si vuole rappresentare.
Per questi motivi, si propongono delle modifiche da apportare ai diagrammi
suggeriti da ebXML; i diagrammi risultanti dall’applicazione di queste modifiche
non violano la sintassi e la semantica definite da UML poiché esse sono effettuate
per mezzo dei meccanismi di estensione forniti dal linguaggio stesso. Queste
proposte si concretizzano nella presentazione di due possibili rappresentazioni dei
processi di business di MODA-ML usando diagrammi di sequenza UML.
Nell’ultima parte del capitolo, si discutono le motivazioni che hanno indotto
all’adozione del formato XMI per la rappresentazione dei diagrammi di sequenza,
vale a dire il bisogno di utilizzare un formato machine-readable in modo da
realizzare questi diagrammi in maniera automatica, previa acquisizione automatica
dei dati utili dal Dizionario. Questo requisito garantisce che l’unico supporto da
aggiornare manualmente in caso di modifiche al vocabolario sia il Dizionario.
Inoltre, viene illustrato come i diagrammi di sequenza UML dei processi di business
MODA-ML sono mappati in linguaggio XMI.
Il capitolo si conclude evidenziando la necessità di progettare ed implementare
un’applicazione capace di acquisire i dati dal Dizionario MODA-ML, utilizzarli per
produrre i diagrammi di sequenza in formato XMI e gestirne la visualizzazione,
poiché, come già detto, il linguaggio XMI non definisce tale aspetto. Non possono
essere utilizzati strumenti software esistenti poiché i molti tool (es: ArgoUML,
Poseidon for UML) per la creazione di diagrammi UML, pur supportando il formato
XMI e i meccanismi per la loro visualizzazione, non consentono l’importazione
automatica dei dati dal Dizionario e la successiva generazione dei diagrammi.
Quindi, dovendo queste operazioni essere svolte a mano e considerata l’elevata
5
quantità di dati nel Dizionario, questi strumenti risultano inutili per gestire
efficientemente la creazione e l’aggiornamento dei diagrammi.
Nel capitolo 5 si affrontano la progettazione e l’implementazione dell’applicazione
software che produce e visualizza i diagrammi di sequenza dei processi di business
di MODA-ML in formato XMI.
La fase di progettazione inizia con l’analisi dei requisiti che l’applicazione deve
soddisfare, più precisamente dei requisiti di architettura e dei requisiti funzionali.
Quindi, prosegue con la definizione dell’architettura che l’applicazione deve avere,
evidenziando due particolari esigenze:
- adottare un’architettura basata su applicazioni Internet, poiché si dovrà
fornire un servizio distribuito utilizzando una sorgente dati, il Dizionario di
MODA-ML, localizzata su un server centralizzato. La necessità di un
servizio distribuito deriva dall’organizzazione, in tante unità distribuite, degli
utenti dell’applicazione, vale a dire dello staff del progetto MODA-ML;
- rendere l’architettura quanto più possibile indipendente dal supporto che
attualmente implementa il Dizionario; questo perché il database (attualmente
MS-Access) potrebbe essere sostituito da un altro supporto o subire
modifiche alla propria struttura interna.
In seguito, si analizza quale meccanismo utilizzare per la visualizzazione dei
diagrammi XMI, l’ambiente di sviluppo dell’applicazione e come effettuare la
connessione al Dizionario MODA-ML.
Infine, si discute dell’implementazione vera e propria dell’architettura
precedentemente progettata. Concretamente, sono stati implementati i seguenti
moduli:
- interfaccia verso l’utente: consiste in alcune pagine ASP che permettono
all’utente di effettuare una serie di scelte (lingua, versione del Dizionario da
utilizzare, processi per i quali generare i diagrammi), di visionare lo stato di
avanzamento della generazione dei diagrammi e di visualizzare i diagrammi
desiderati. I moduli seguenti sono tutti richiamati all’interno di queste
pagine;
- supporto per l’acquisizione dei dati dal Dizionario: funzioni che reperiscono i
dati nel Dizionario e li restituiscono in una forma indipendente
6
dall’organizzazione data dal supporto di gestione dati adottato;
- generatore di diagrammi di sequenza in formato XMI: funzioni per la
realizzazione dei diagrammi di sequenza del processo di business specificato.
Questo modulo è stato progettato e implementato indipendentemente dal
supporto adottato per la gestione del Dizionario, quindi può essere utilizzato
anche se esso dovesse essere modificato o sostituito;
- visualizzatore dei diagrammi di sequenza: funzione che applica un foglio di
stile XSLT di default ad un documento XMI specificato e salva il risultato
della trasformazione su un file di destinazione. Il foglio di stile adottato
trasforma diagrammi di sequenza in formato XMI in oggetti grafici in
formato SVG. Anche la realizzazione del foglio di stile è stato lavoro di tesi.
Sostanzialmente il lavoro di tesi ha prodotto due risultati concreti:
1. i modelli formali per la rappresentazione dei processi di business di MODA-
ML conformi alla metodologia UMM;
2. un’applicazione software (MODA-MICS) per realizzare i modelli
automaticamente.
In conclusione, quindi, è possibile affermare che è l’esigenza del progetto MODA-
ML di avere un supporto automatico alla documentazione formale dei processi di
business supportati è stata soddisfatta.
7
8
2 Il contesto
Il capitolo fornisce una breve presentazione del contesto nel quale si è svolto il
lavoro di tesi, ossia il progetto MODA-ML ed il framework ebXML cui esso si è
ispirato.
2.1 Il progetto MODA-ML
Il progetto MODA-ML ha sviluppato un’architettura per l’interoperabilità basata
sull’adozione della tecnologia XML, in particolare sul framework standard ebXML,
per le imprese del Tessile/Abbigliamento italiano. Illustriamo le problematiche del
settore Tessile/Abbigliamento che il progetto si è proposto di risolvere, le soluzioni
adottate e gli obiettivi già raggiunti.
2.1.1 Il Tessile/Abbigliamento italiano
In Italia, il settore del Tessile/Abbigliamento ha una fisionomia particolare poiché è
costituito da moltissime aziende di medie, piccole e piccolissime dimensioni,
ciascuna delle quali partecipa ad una minima parte del processo produttivo in cui è
estremamente specializzata.
Affinché la filiera svolga un lavoro efficiente sarebbe necessario che le aziende che
la compongono collaborassero strettamente e agissero come se, insieme, formassero
un’unica azienda. Allo stato attuale però ciò non si verifica, soprattutto a causa della
non interoperabilità tra i sistemi che rende inefficiente il collegamento informativo
fra i vari segmenti della filiera; questa situazione rende difficile una pianificazione
ottimale dell’attività produttiva e, conseguentemente, i tempi totali di produzione di
un capo di abbigliamento risultano essere molto lunghi.
9
La soluzione per garantire competitività al settore potrebbe essere l’adozione di
framework e strumenti standard che consentano a ciascun sistema di interoperare
con gli altri indipendentemente dalla struttura interna e dall’architettura. In questo
contesto diventa strategica l’introduzione di nuovi modelli organizzativi e di nuove
tecnologie, come Internet, XML e correlate. Esse, infatti, permetterebbero la
gestione automatica dei documenti favorendo una maggiore condivisione delle
informazioni fra tutti gli operatori della filiera, dai produttori di materie prime ai
punti vendita, cosicché i tempi decisionali, amministrativi e di comunicazione tra le
diverse componenti della filiera sarebbero notevolmente ridotti [TA].
Queste scelte sono motivate dalle difficoltà riscontrate in passato nel tentativo di
rispondere a queste esigenze utilizzando altre tecnologie, ovvero EDI (inizio anni
’90) e i marketplace (fine anni ’90).
2.1.2 Obiettivi e risultati del progetto
Il progetto MODA-ML [MML] nasce dalla collaborazione fra ENEA, Politecnico di
Milano, Gruppo SOI, Domina, Institut Française Textil Habillement (IFTH) ed un
gruppo di aziende pilota, con il patrocinio dell’Unione Europea, nell’ambito del V
Programma Quadro di Ricerca e Sviluppo – Programma IST 2000 “Tecnologie della
Società dell’Informazione”.
Il progetto si pone l’obiettivo di rendere agevole la circolazione di informazioni
tecniche e gestionali tra aziende della filiera del Tessile Abbigliamento tramite lo
scambio di documenti XML via Internet [MMLexp].
Nel concreto il progetto vuole definire un insieme di documenti standard che
possano essere utilizzati per lo scambio di informazioni tra le aziende della filiera,
unitamente ai prototipi degli strumenti informatici che ne possano rendere più
semplice l’uso con gli eventuali sistemi informativi aziendali.
Si vuole quindi offrire alle imprese del settore un linguaggio comune per lo scambio
dei dati che possa essere facilmente integrabile nei processi produttivi delle aziende
più grandi e già dotate di un loro sistema informativo e, allo stesso tempo, che sia
anche di facile utilizzo per le imprese più piccole e con un basso grado di
10
informatizzazione.
L’utilizzo di XML per la definizione dei documenti consente ai sistemi informativi
delle aziende di scambiarsi dati senza l’obbligo di utilizzare la stessa applicazione,
ma scegliendo quella che ritengono più opportuna. Le aziende traggono vantaggio
da tale approccio poiché possono adottare un'unica interfaccia nel proprio sistema
informativo con la certezza che sia sufficiente per dialogare direttamente con tutti i
propri partner.
Il progetto MODA-ML costituisce un importante passo per la costruzione di un
linguaggio comune per il settore Tessile/Abbigliamento che si traduce in due
risultati concreti:
la definizione di tipi di documento XML e dizionario di termini relativi a
documenti generici (es.: ordine, bolla di spedizione, fattura, ecc…) e documenti
specifici dei flussi di vendita della parte di filiera tra Fornitore di tessuti e
Confezionista e tra questi e la Distribuzione, relativi agli aspetti di vendita,
tecnici e qualitativi dei prodotti ed all’avanzamento di produzione e vendite;
la realizzazione di alcuni semplici moduli software di pubblico uso per
maneggiare i documenti. Essi sono sviluppati e sperimentati dai partner
industriali in transazioni reali ed affrontano le problematiche del trasporto, della
sicurezza e della confidenzialità dei dati scambiati prevedendo una semplice
integrazione nei sistemi aziendali.
Grazie a questi strumenti le piccole e medie aziende possono consultare, inviare e
ricevere documenti semplicemente accedendo ad un archivio che potranno installare
anche su personal computer collegato con la posta elettronica. Le aziende con
maggiori competenze o più esigenti potranno maneggiare direttamente i documenti
XML con i propri sistemi oppure utilizzare una parte del software di MODA-ML
che è gratuito ed open source.
2.2 ebXML
ebXML è un framework standard basato su XML che consente alle aziende di
condurre transazioni elettroniche attraverso Internet. Analizziamo i problemi che
11
l’architettura si è proposta di risolvere e le soluzioni fornite. Infine, spieghiamo
perché il progetto MODA-ML ha scelto come riferimento proprio questo framework
e quali aspetti sono stati adottati.
2.2.1 L’iniziativa ebXML
L’iniziativa ebXML (Electronic Business XML) nasce nel novembre 1999 ad opera
di OASIS ed UN/CEFACT per risolvere il problema largamente diffuso di
consentire alle aziende di qualsiasi dimensione e dislocate in qualunque posizione
geografica di condurre delle transazioni elettroniche in modo semplice, affidabile e a
buon mercato [ebXML].
La soluzione proposta da ebXML è creare un singolo mercato elettronico globale in
cui le imprese possono incontrarsi e condurre affari tramite lo scambio di documenti
XML. Viene scelta la tecnologia XML grazie ai suoi costi (in termini di
acquisizione, adattamento ed integrazione) piuttosto contenuti poiché altre
tecnologie per il commercio elettronico sviluppate in questi anni, come ad esempio
EDI (Electronic Data Interchange), non hanno riscosso molto successo proprio per la
mancanza di questo requisito.
In sintesi, il progetto ebXML si è concretizzato nella definizione di un’architettura e
nella pubblicazione di un insieme di specifiche chiave per la realizzazione del
commercio elettronico; questi strumenti forniscono alle aziende un metodo standard
basato su XML per lo scambio di messaggi commerciali, per condurre rapporti
commerciali, per comunicare dati condividendo la stessa semantica e per definire e
registrare processi aziendali e commerciali.
2.2.2 La tecnologia ebXML
Esaminiamo l’approccio proposto da ebXML per dare vita ad una semplice
transazione od interscambio commerciale tra due partner (Figura 2.2.1) [ebTA].
La Società A viene a conoscenza dell'esistenza di un Registro (Registry) ebXML accessibile via Internet (Passo 1), ne esamina il contenuto e decide di realizzare la propria applicazione
12
conformemente allo standard ebXML (Passo 2). Se applicazioni e componenti ebXML-compliant adatti allo scopo già esistono, non occorre sviluppare software proprietario.
Figura 2.2.1 Architettura ebXML
La società A invia le informazioni riguardanti il suo Profilo Commerciale (Business Profile) al Registry, con il dettaglio dell'implementazione ed i link di riferimento. Il Profilo descrive capacità e vincoli della Società così come tutti gli scenari di business che essa supporta. Questi scenari sono descrizioni in formato XML dei Processi di Business (Business Processes) che la Società è in grado di produrre. Verificato che il formato ed i passaggi di ciascun Business Process sono corretti, viene spedita alla Società A una conferma (Passo 3). La Società B scopre gli scenari di business supportati dalla Società A nel Registry ebXML (Step 4), quindi segnala alla Società A l'intenzione di impegnarsi in uno scenario di business usando ebXML (Step 5). La Società B si dota di un'applicazione dedicata ebXML-compliant.
13
Prima di potersi impegnare in uno scenario di interscambio, la Società B invia all'Interfaccia (Interface) del software ebXML-compliant della Società A uno schema del business proposto. Tale schema delinea i processi di business ed altri specifici accordi approvati da ambo le parti, inoltre descrive i requisiti per lo scambio delle informazioni necessarie per il buon fine della transazione, eventuali piani di emergenza ed i requisiti relativi alla sicurezza. A questo punto la Società A accetta la proposta di business. Le Società A e B possono ora lanciarsi nell'eBusiness usando ebXML (Step 6). Questa panoramica concettuale introduce i seguenti concetti e l'architettura
sottostante:
un meccanismo standard per descrivere Processi di Business ed i modelli
delle informazioni ad essi associati;
un meccanismo per registrare e memorizzare Processi di Business e Meta-
Modelli di Informazioni così che essi possano essere condivisi e riutilizzati;
la scoperta di informazioni riguardanti ogni partecipante, ovvero:
- i Processi di Business da esso supportati;
- le Interfacce di Servizio di Business (Business Service Interfaces) che
esso offre a supporto del Processo di Business;
- i Business Message che sono scambiati tra le rispettive Interfacce;
- la configurazione tecnica circa il trasporto, la sicurezza e i protocolli
di codifica supportati;
un meccanismo per registrare e recuperare le informazioni suddette;
un meccanismo per descrivere l'esecuzione dello schema di business
un framework standardizzato per il Servizio di Messaging che permette
scambi di Messaggi sicuri ed affidabili fra i Partner Commerciali;
un meccanismo per configurare i rispettivi Messaging Service nel corso del
Business Process concordato in accordo con i vincoli definiti nello Schema
di Business.
14
2.2.3 Il progetto MODA-ML ed ebXML
Il gruppo di lavoro di MODA-ML ha analizzato i framework per il commercio
elettronico basati su XML e ha ritenuto che ebXML fosse il più adatto per il
progetto in questione grazie alla sua completezza, alla sua continuità con EDI e alla
sua indipendenza dalle applicazioni.
In particolare si è scelto di assumere come riferimento le specifiche di ebXML
relative al trasporto e al servizio di invio e ricezione dei messaggi, realizzando un
prototipo software dimostrativo di questo protocollo [MMLfr]. Per la modellazione
degli scenari di business, invece, le specifiche sono state seguite limitatamente
all’organizzazione degli scenari di business in tre livelli. Infine, per quanto riguarda
i template di Documento XML è stata adottata la struttura basata su Core
Components elementari (raccolti nel Dizionario), ma non sono state utilizzate le
regole di aggregazione dei Core Components poiché non sono risultate adeguate ai
fini del progetto.
15
16
3 Le tecnologie
Il capitolo analizza le principali tecnologie utilizzate per la rappresentazione dei processi di business MODA-ML: UMM, UML e XMI.UMM (UN/CEFACT Modeling Methodology) è la metodologia di modellazione che le specifiche ebXML raccomandano esplicitamente per la modellazione degli scenari di business, quindi è stata il riferimento per la realizzazione dei modelli dei processi di MODA-ML.UML (Unified Modeling Language) è il linguaggio grafico di modellazione adottato da UMM, quindi il linguaggio in cui sono stati realizzati i modelli dei processi di business di MODA-ML destinati alla documentazione utente.XMI (XML Metadata interchange) è un linguaggio di interscambio per meta-dati che, ai fini di questa tesi, è stato adottato per rappresentare i modelli dei processi di business di MODA-ML in formato machine-readable.
3.1 Lo Unified Modeling Language (UML)
UML (Unified Modeling Language) è il linguaggio visuale standard per specificare,
costruire, visualizzare e documentare manufatti sia di sistemi software sia di
processi produttivi e altri sistemi non strettamente software.
Esaminiamo brevemente le potenzialità del linguaggio e la notazione da esso
utilizzata ed effettuiamo un’analisi approfondita degli aspetti che possono aiutare a
capire come è stata effettuata la modellazione dei processi di business di MODA-
17
ML: il meta-modello e i meccanismi di estensione.
Per il lavoro di tesi è stata utilizzata la versione 1.5 delle specifiche.
3.1.1 Che cos’è e che cosa non è UML
UML [UML] è un linguaggio di rappresentazione di sistemi che possono essere
eterogenei per architettura, per tecnologie e per tipologia applicativa. È uno standard
internazionale, non un linguaggio proprietario; non è legato ad uno specifico
processo o a una singola impresa e non fornisce indicazioni sul proprio utilizzo, può
quindi essere usato da persone e gruppi che seguono approcci diversi.
È importante osservare che UML non è unicamente una notazione standard per la
descrizione di modelli object oriented di sistemi software, ma anche un meta-
modello che descrive la notazione stessa (questo aspetto verrà esaminato in seguito).
UML è nato per soddisfare l'esigenza di avere uno standard notazionale per l'analisi
e la modellazione ad oggetti ed ha obiettivi e finalità molteplici:
fornire un linguaggio di modellazione visuale che risulti di facile comprensione
e di semplice utilizzo;
fornire meccanismi di estensibilità e specializzazione per estendere i concetti
base (vedi paragrafo 3.1.4);
essere indipendente da ogni linguaggio di programmazione e da qualsiasi
processo di sviluppo;
specificare un formalismo base per capire il linguaggio di modellazione;
incoraggiare lo sviluppo di strumenti per la progettazione orientata agli oggetti.
Analizziamo ora gli ambiti di utilizzo di UML.
In primo luogo, può essere utilizzato dagli sviluppatori nelle fasi di analisi e
progettazione di un sistema in quanto permette di realizzare modelli completi,
precisi e non ambigui che possono essere utilizzati per scoprire eventuali problemi e
per ragionare sulle possibili soluzioni. In questo caso, la modellazione rispetta un
livello di accuratezza che risponde alle esigenze di chi sta realizzando il modello
poiché è lui che lo utilizzerà.
18
In secondo luogo, UML è un ottimo strumento di documentazione: in particolare,
quando le fasi di analisi, progettazione e sviluppo di un sistema vengono effettuate
da persone diverse o dalle stesse persone ma a distanza di tempo, è fondamentale
poter disporre di una documentazione del sistema chiara ed esauriente; questa
documentazione può essere data per mezzo dei modelli UML. In questo ambito,
occorre considerare che il modello sarà utilizzato da altre persone ed in base a ciò
stabilire il grado di precisione con cui realizzarlo.
Spiegato che cos'è UML, quali sono i suoi obiettivi e i suoi ambiti di utilizzo
puntualizziamo che cosa UML non è.
La prima precisazione da fare è che UML è un linguaggio di modellazione, non
metodo. Il metodo, infatti, è composto da un linguaggio di modellazione e da un
processo; poiché UML non definisce alcun processo di sviluppo, non può essere
considerato un metodo.
La seconda osservazione è che UML non è un linguaggio di programmazione
visuale, nel senso che non fornisce tutti i necessari supporti visivi e semantici per
essere definito linguaggio di programmazione.
UML definisce un meta-modello semantico, ma nessun tool di interfacciamento o di
memorizzazione, né da indicazioni su come realizzarli; ad esempio, non viene
specificato di che colore devono essere i diagrammi.
3.1.2 Architettura OMG per meta-modelli
OMG (Object Management Group) specifica un’architettura a quattro livelli per
meta-modelli che supporta la descrizione completa dei sistemi e delle architetture
software distribuiti. La chiave di questa architettura è MOF (Meta Object Facility)
[MOF], ragion per cui è denominata anche architettura MOF per meta-dati (Tabella
3.1.1).
Il Modello MOF è definito utilizzando se stesso come linguaggio di modellazione,
poiché è posto al livello più alto; ciò vuol dire che MOF è meta-modello di se stesso.
Il meta-modello UML è definito come il livello M2 dell'architettura, quindi, il meta-
modello UML è definito in termini del meta-metamodello MOF (Figura 3.1.1).
19
Meta-livello Termine MOF Significato Esempio
M3 meta-metamodello
Costituisce l'infrastruttura per l’architettura basata su meta-modelli e definisce il linguaggio per specificare i meta-modelli.
Modello MOF
M2 meta-metadatimetamodello
È un'istanza del meta-metamodello e definisce un linguaggio per specificare un modello.
Meta-modello UML
M1 meta-datimodello
È un'istanza di un metamodello. Definisce un linguaggio per descrivere un dominio informativo.
Modello UML
M0 dati Istanze dei modelli. Servono a descrivere uno specifico dominio di informazione.
Sistema reale
Tabella 3.1.1 Architettura MOF per meta-dati
M3
M2
M1
M0
:PersonaPolo:Auto
targa = AB700
PersonaAuto
targa = String +ha 1 0..*
Classifier
Class Association
+ownedElement 0..1
ClassAssociation
NamespaceModelElementRelationship
Classifier
LIVELLO ESEMPIO
<<metamodel>>metamodello UML
Modello Utente
<<metamodel>> meta-metamodello MOF
<<instanceOf>>
<<instanceOf>>
:Istanza 1 : Istanza 3: Istanza 220
Figura 3.1.1 Relazione tra architettura UML e architettura MOF3.1.3 Il meta-modello UML
Il meta-modello UML [UMLSp] è composto da numerosi elementi, collegati tra loro
secondo regole ben precise, che permettono di realizzare i sistemi da rappresentare.
Essendo molto complesso, è organizzato in diversi package logici che, a loro volta,
sono decomposti in subpackage.
I package che compongono il meta-modello UML sono esattamente tre: Foundation,
Behavior Elements e Model Management; i primi due sono ulteriormente
decomposti in altri package (Figura 3.1.2).
Figura 3.1.2 Metamodello UML
Il package Foundation rappresenta l'infrastruttura del linguaggio che specifica la
struttura statica dei modelli. È composto dai seguenti subpackage:
Core: specifica gli elementi base del meta-modello necessari per sviluppare un
modello ad oggetti e definisce uno scheletro in base al quale aggiungere al
Model Management
Behavior Elements
State Machines
Common Behavior
Collaborations
Activity Graphs
Actions Use cases
Foundation
Core
Data Types
ExtensionMechanisms
21
linguaggio costrutti come meta-classi, meta-associazioni e meta-attributi;
Extension Mechanisms: specifica come gli elementi del modello UML possono
essere caratterizzati ed estesi introducendo nuova semantica tramite stereotipi,
valori etichettati e vincoli;
Data Types: specifica i diversi tipi di dato che sono utilizzati da UML.
Il package Behavioral Elements specifica la struttura necessaria per definire i
comportamenti dinamici di un modello. I subpackage che lo compongono sono:
Common Behavioral: definisce i concetti di base per modellare comportamenti
dinamici. Fornisce l'infrastruttura di supporto per i subpackage Collaboration,
UseCases, StateMachines e Actions;
Collaborations: definisce i concetti necessari per esprimere il modo in cui i
diversi elementi di un modello interagiscono tra loro da un punto di vista
strutturale;.
Use Cases: specifica i concetti necessari per definire le funzionalità di entità
come i sistemi e sottosistemi senza specificarne la struttura interna;
State Machines: specifica un insieme di concetti che possono essere utilizzati
per modellare le transazioni di stato che coinvolgono le diverse parti di un
sistema;
Activity Graphs: estende il package State Machines aggiungendo nuovi concetti.
Entrambe i package definiscono i concetti necessari per modellare transizioni di
stato e condividono molti elementi del meta-modello;
Action: definisce i vari tipi di azione che possono formare un procedimento.
Infine, il package Model Management definisce gli elementi necessari per
organizzare modelli diversi e per raggruppare elementi che presentano caratteristiche
comuni.
Le specifiche UML descrivono ogni package in maniera semi-formale specificando:
sintassi astratta: definisce i costrutti che fanno parte del linguaggio e come i
costrutti possono essere costruiti in termini di altri costrutti; è fornita come un
modello descritto tramite un sottoinsieme di UML comprendente i diagrammi
delle classi UML e testo scritto in linguaggio naturale;
regole ben-formate: regolano la semantica statica, ovvero definiscono in che
modo un'istanza di un costrutto dovrebbe essere collegata con altre istanze di
22
costrutti affinché sia significativa. Sono fornite utilizzando sia un linguaggio
formale, chiamato Object Constraint Language (OCL) [OCL], che il linguaggio
naturale;
semantica (dinamica): definisce il significato dei costrutti ben formati ed è
descritta attraverso il linguaggio naturale; comprende la descrizione degli
elementi che compongono il meta-modello UML e delle relazioni tra essi.
3.1.4 Estensibiltà e Profili di UML
Uno degli obiettivi principali degli sviluppatori di UML è, da sempre, quello di
renderlo un linguaggio di modellazione quanto più generale possibile, in modo da
non relegarne l'utilizzo ad un contesto ristretto; allo stesso tempo però, deve poter
essere utilizzabile in ambiti più specifici.
Al fine di conciliare queste due esigenze è stato realizzato un nucleo basilare del
linguaggio valido per ogni ambiente, al quale si affianca un'insieme di meccanismi
di estensione controllata grazie ai quali la semantica degli elementi del meta-
modello può essere modificata dal modellista. Ciò permette sia di aggiungere nuovi
concetti e notazioni al fine di modellare opportunamente le aree non coperte dal
nucleo standard, sia di specializzare quelli esistenti per particolari domini.
È importante sottolineare che i meccanismi di estensione sono un modo di raffinare
la semantica di UML per uno specifico dominio, non un supporto per estensioni
semantiche arbitrarie; questo significa che le estensioni non possono mai essere in
conflitto o in contraddizione con la semantica di UML standard.
I meccanismi di estensione forniti da UML sono tre: stereotipi, valori etichettati
(Tagged Value) e vincoli [UMLSp].
Fra i tre, il meccanismo di estensione principale è quello degli stereotipi.
Uno stereotipo è la specializzazione di un elemento presente nel meta-modello UML
per il quale definisce valori e costrutti addizionali e, opzionalmente, una nuova
rappresentazione grafica; tutti gli elementi del modello marcati da uno o più
stereotipi ricevono questi valori e costrutti in aggiunta agli attributi, alle associazioni
e alle superclassi standard che essi hanno. Possono estendere qualunque elemento
presente nel meta-modello UML, quindi anche attributi, metodi, altri stereotipi e
23
così via. Ovviamente, i nomi degli stereotipi non devono collidere con i nomi di
elementi predefiniti del meta-modello UML o di elementi standard.
Gli stereotipi, quindi, sono un modo di definire sottoclassi virtuali delle meta-classi
di UML con nuovi meta-attributi e semantica aggiuntiva. Le nuove classi vengono
(virtualmente) aggiunte al meta-modello in fase di progettazione.
Gli stereotipi possono essere utilizzati per indicare differenze di significato, o di
uso, tra elementi del modello che hanno struttura identica, oppure per aggiungere
insiemi predefiniti di Tagged Value (associazione tra un attributo e il relativo valore)
e vincoli validi per tutte le istanze dello stereotipo stesso.
Il seguente esempio illustra la definizione e l'utilizzo di uno stereotipo (Figura
3.1.3).
Figura 3.1.3 Esempio di stereotipo
Lo stereotipo <<Persistent>> specializza la meta-classe del meta-modello
denominata Class. Esso può essere utilizzato per inserire informazioni aggiuntive
alle classi le cui istanze necessitano di essere memorizzate in forma permanente dal
sistema. Come vediamo nella parte sinistra della figura, lo stereotipo è rappresentato
attraverso un'apposita classe il cui stereotipo è <<stereotype>>. Tale classe è la
“client” di una relazione di dipendenza che la vincola all'elemento del meta-modello
che intende estendere, ossia la meta-classe Class. Vengono anche specificati dei
Tagged Value e dei vincoli. La parte destra della figura, invece, mostra una classe
<<metaclass>>Class
<<stereotype>>Persistent
TagsTableName : String[0..1]
SQLFile : Database
Constraints{TableName non dovrebbe
essere più lungo di 8 caratteri}
<<Persistent>>Aticolo
{TableName = Articolo}{database = eCommerce}
- id : String- name : String
- description : String...
getPrize()...
Metamodello Modello
24
marcata dallo stereotipo <<Persistent>>.
Il secondo meccanismo di estensione è quello dei valori etichettati.
Un valore etichettato è una coppia chiave-valore che può essere attribuita a
qualunque tipo di elemento del modello.
La chiave, denominata tag, rappresenta un particolare tipo di proprietà valida per
uno o più tipi di elementi del meta-modello mentre il valore è, appunto, il valore che
la proprietà assume. Sia il tag che il valore sono codificati come stringhe.
Con la versione 1.4 di UML i Tagged Value diventano tipizzati, perciò le relative
istanze possono assumere solo valori vincolati; i valori possono essere o valori di
tipi di dato semplice o riferimenti ad altri tipi di dato del modello.
I valori etichettati, quindi, sono un mezzo per aggiungere informazioni
supplementari a qualsiasi elemento del modello. Tipicamente sono utilizzati per
impostare informazioni specifiche relative a metodi, allo stato di avanzamento del
modello, dati necessari ad altri strumenti di sviluppo e così via; ad esempio, possono
essere sfruttati per specificare la versione della revisione di un diagramma o di un
suo elemento.
La versione 1.4 impone che qualora sia necessario definire dei Tagged Value debba
necessariamente essere definito anche uno stereotipo che li raggruppi; tuttavia, per
compatibilità con le versioni precedenti, è ancora possibile definire valori etichettati
non associati ad alcuno stereotipo.
Infine, c'è il meccanismo dei vincoli.
Il concetto di vincolo permette di rifinire le semantiche degli elementi del modello
attraverso specifiche scritte come espressioni di un determinato linguaggio che può
essere un apposito linguaggio per vincoli (OCL), un linguaggio di programmazione,
una notazione matematica o il linguaggio naturale. In sostanza, un vincolo è una
restrizione su uno o più valori di un modello o di un sistema (o parti di esso); può
essere associato ad un elemento del modello oppure ad uno stereotipo. Ovviamente i
vincoli non devono contraddire le semantiche di base ereditate.
UML definisce tre tipi standard di vincoli:
invariante (di una classe): un vincolo che deve essere sempre soddisfatto da tutte
le istanze di una classe;
precondizione (di un’operazione): un vincolo che deve essere sempre soddisfatto
25
prima dell’esecuzione di un’operazione;
postcondizione (di un’operazione): un vincolo che deve essere sempre
soddisfatto dopo l’esecuzione di un’operazione.
I meccanismi di estensione consentono di creare nuovi “Profili UML”.
Un profilo UML è un insieme predefinito di stereotipi, Tagged Value e vincoli che
collettivamente specializzano UML per uno specifico dominio o processo. Un
profilo non estende UML definendo dei nuovi concetti basilari, ma fornisce
convenzioni per applicare e specializzare UML standard per un particolare ambiente
o dominio. In generale, lo scopo di un profilo UML è permettere la costruzione e
l’interscambio di modelli UML che richiedono specifiche semantiche con un livello
di dettaglio al di là di quello che può essere espresso con UML standard (è
importante osservare che queste semantiche addizionali sono pienamente consistenti
con le semantiche generali di UML). Inoltre, i profili possono essere utilizzati per
derivare sottoinsiemi del meta-modello UML per particolari scopi. Concettualmente,
le definizioni dei profili determinano dei cambiamenti al meta-modello UML ma,
tecnicamente, sono istanze degli elementi del modello UML che possono essere
definite dagli utenti a livello di modello. Questo permette ai profili di essere
interscambiati tra i tool per la modellazione e di essere definiti dagli utenti finali dei
tool.
Un profilo può essere ottenuto in due modi:
utilizzando i meccanismi di estensione forniti da UML (stereotipi, Tagged
Value, vincoli); in tal caso viene chiamato “profilo leggero” (lightweight), in
quanto ottenuto con meccanismi propri del linguaggio;
utilizzando i meccanismi di estensione definiti dalle specifiche del MOF: si tratta
della definizione di nuove meta-classi da incorporare nella definizione formale
di MOF. In questo caso si parla di “profilo pesante” (heavyweight).
La definizione formale di un profilo, per essere consistente con l'approccio utilizzato
nel documento delle specifiche ufficiali, deve prevedere le seguenti sezioni:
insieme delle estensioni standard che definiscono il profilo stesso, ottenuto
attraverso l'opportuna applicazione dei meccanismi di estensione di UML al
sottoinsieme di interesse del meta-modello;
26
definizione della relativa semantica descritta attraverso il linguaggio naturale;
insieme delle regole ben formate, ossia insieme dei vincoli, espressi in
linguaggio naturale o per mezzo dell'OCL, appartenenti agli elementi introdotti
con il profilo;
elementi comuni del modello, ossia istanze degli elementi del meta-modello
UML espressi in termini del profilo;
eventuali estensioni a MOF .
Le specifiche, inoltre, stabiliscono alcuni requisiti che il concetto di profilo UML
deve soddisfare [Prf]; in particolare:
un profilo deve fornire un meccanismo per specializzare il meta-modello
standard di UML, ma che non violi la semantica dello stesso;
un profilo può essere definito solo per mezzo di stereotipi, valori etichettati e
vincoli;
l’interscambio di profili (e dei modelli cui sono stati applicati) tra tool dovrebbe
essere possibile utilizzando i meccanismi di interscambio esistenti, come UML
XMI (vedi paragrafo 3.3);
un profilo deve poter definire il sottoinsieme applicabile di meta-classi del meta-
modello UML;
un profilo deve poter fare riferimento a librerie UML di specifici domini dove
certi elementi del modello sono pre-definiti;
deve essere possibile eseguire alcune operazioni sui profili, ossia:
specializzazione (derivazione di un nuovo profilo da uno esistente, dove la
semantica del nuovo profilo non viola quella del vecchio) e composizione
(generazione di un nuovo profilo combinandone due o più reciprocamente
compatibili);
deve essere possibile specificare parti del profilo di un dato package o
subpackage;
la definizione dei valori etichettati dovrebbe essere formalizzata;
dovrebbe essere possibile definire estensioni UML che combinano profili e
librerie del modello in una singola unità logica.
I profili sono entrati a far parte integrante del linguaggio con la versione 1.4 e
attualmente ne sono stati formalmente incorporati due: il profilo per il “Software
27
Development Processes” e quello per il “Business Modelling”.
3.1.5 La notazione UML
UML, analizzato con una metodologia top down, è costituito da viste, diagrammi ed
elementi del modello.
Le viste (Figura 3.1.4) permettono di mostrare aspetti differenti di un sistema
attraverso la realizzazione di un certo numero di diagrammi. Sono astrazioni ognuna
delle quali analizza il sistema da modellare con un’ottica diversa, quindi, l’unione di
tali viste fornisce il quadro d’insieme.
Figura 3.1.4 Viste UML
La Vista dei casi d’uso è una vista ad alto livello di astrazione ed è utilizzata per
rappresentare i requisiti funzionali che il sistema deve implementare. A questo
livello di analisi è fondamentale concentrarsi sul cosa il sistema dovrà fare
astraendosi il più possibile dal come.
La Vista strutturale, invece, descrive come le funzionalità del sistema debbano
essere realizzate, in altre parole, analizza il sistema dall'interno.
La Vista di implementazione descrive come il codice debba essere accomunato in
opportuni moduli (package) evidenziandone le reciproche dipendenze.
La Vista comportamentale individua i processi e i processori al fine di utilizzare
efficientemente le risorse sia per poter stabilire l’esecuzione parallela degli oggetti,
sia per gestire correttamente eventuali eventi asincroni.
Vista dei casi d’usoDiagramma
dei casi d’uso
Vista Strutturale Vista di implementazioneDiagramma delle classi Diagramma dei componentiDiagramma degli oggetti Diagramma dei package
Vista VistaComportamentale d’Ambiente Diagramma di sequenza Diagramma di collaborazione Diagramma di dislocamento Diagramma di statoDiagramma delle attività
28
La Vista d’ambiente mostra l’architettura fisica del sistema e fornisce l’allocazione
delle componenti software nella struttura stessa.
I diagrammi permettono di esprimere le viste logiche per mezzo di grafici [UMLd]
ognuno dei quali è, tipicamente, destinato ad essere utilizzato per una particolare
vista (Tabella 3.1.2).
Categoria Diagrammi Caratteristiche
Diagrammi introduttivi Diagrammi dei casi d’ uso
Descrive iterazioni tipiche tra utente e sistema senza rivelare l’organizzazione interna del sistema.
Diagrammi di struttura statica
Diagrammi delle classi
Descrive i tipi degli oggetti che fanno parte del sistema, i loro attributi e operazioni, le relazioni statiche esistenti tra essi, i vincoli sulle relazioni.
Diagrammi degli oggetti Rappresentano le istanze dei diagrammi delle classi.
Diagrammi di interazione
Diagrammi di sequenzaDescrivono le interazioni tra gli oggetti del sistema specificando l’ordine temporale secondo il quale avvengono.
Diagrammi di collaborazione
Rappresenta le associazioni tra gli oggetti e le interazioni tra essi.
Diagrammi di statoDiagrammi di stato
Descrive gli stati in cui può trovarsi un certo oggetto e i cambiamenti di stato che subisce al verificarsi di determinati eventi.
Diagrammi delle attività Rappresentano sistemi di workflow o la logica interna di un processo.
Diagrammi di implementazione
Diagrammi dei packageMostra l’organizzazione delle classi in determinati moduli e le dipendenze tra essi.
Diagrammi dei componenti
Evidenzia l’organizzazione e le dipendenze esistenti tra i componenti di un sistema.
Diagrammi di dislocamento
Consente di rappresentare l’architettura hardware e software di un sistema.
Tabella 3.1.2 Diagrammi UML
Gli elementi del modello sono i concetti che permettono di realizzare i vari
diagrammi, essi indicano gli attori, le classi, i package, gli oggetti, ecc.
29
3.2 UN/CEFACT Modeling Methodology (UMM)
L’UN/CEFACT Modeling Methodology (UMM) è la metodologia sviluppata da
UN/CEFACT (United Nation Centre for Trade Facilitation and Electronic Business)
per modellare i Business Process e per supportare lo sviluppo delle generazioni EDI,
esistenti e future, per il commercio elettronico.
Individuiamo il campo di azione della metodologia e descriviamo le fasi in cui
suddivide il processo di modellazione, evidenziando come viene utilizzato il meta-
modello UML.
3.2.1 Introduzione
L’approccio seguito da UMM [UMM] consente di descrivere uno scenario Open-
EDI1 conformemente all’Open-edi reference model (ISO/IEC 14662) illustrato in
Figura 3.2.1.
Figura 3.2.1 Open-edi reference model
Secondo tale modello, ogni transazione di business è descritta attraverso due viste:
Business Operational View (BOV): si limita a quegli aspetti che riguardano lo
sviluppo di decisioni di business e impegni tra le organizzazioni;
BUSINESS
TRANSACTIONS
Open-edi Reference Model
Viewed as
Business aspectsof
business transaction
Information technology aspects of
business transaction
Functional Service View
Business Operational View
BOV RELATED STANDARDS
FSV RELATED STANDARDS
Comply with
Comply with
Converted by
Converted by
30
1 Uno scenario Open-EDI è un modo formale di specificare una classe di transazioni di business che hanno uno stesso obiettivo di business, come, ad esempio, l’acquisto e la gestione dell’inventario. Functional Service View (FSV): si concentra sugli aspetti implementativi e
tecnologici dell’Open-edi.
Il campo d’azione dell’UMM riguarda essenzialmente la Business Operational
View, poiché, ad eccezione della struttura dettagliata dei messaggi, le specifiche
relative alla Functional Service View sono al di fuori della portata della
metodologia. Come tale, UMM fornisce un procedimento per modellare, in modo
tecnologicamente neutrale e indipendente dall’implementazione, i processi di
business che implicano lo scambio d’informazioni.
3.2.2 Fasi e workflow di UMM
UMM adotta il metodo Unified Process (UP) sviluppato da Rational Corporation
[RUP]; secondo tale metodo tutti i progetti di sviluppo del software attraversano, nel
corso del tempo, una serie di fasi generali. Una fase è un intervallo tra due principali
milestone (tappe) in un progetto; entro ogni singola fase è possibile lavorare a
workflow multipli.
Le fasi, elencate nell’ordine di svolgimento, sono:
Inception
Elaboration
Construction
Transition.
Workflow Inception Elaboration Construction Transition
Business
ModellingRequirements
Analysis
Design
Implementation
Test
Deployment
ISV1 Users
UN/CEFACTMethodolog
y
B
O
V
FS
V
31
Il rettangolo tratteggiato indica l’area coperta da UMM.1ISV: Indipendet Software Vendors
Figura 3.2.2 RUP: fasi e workflow
UMM sviluppa le prime due fasi (Figura 3.2.2) al fine di definire i bisogni del
business, produrre scenari di business, oggetti di business e collaborazioni di
business.
Le fasi di Inception e Elaboration sono coperte da quattro workflow ognuno dei
quali si concentra su determinati obiettivi e analizza il dominio di business in esame
da una prospettiva (view) delimitata, producendo i corrispondenti modelli.
I workflow sono:
Business Modeling workflow: l’obiettivo è descrivere formalmente la
struttura e la dinamica delle operazioni tra le diverse parti entro il dominio di
business in modo che gli utenti, gli sviluppatori e i fornitori software abbiano
una comprensione comune del dominio e dei suoi requisiti.
Viene sviluppato il Business Domain View (BDV) meta-model;
Requirements workflow: lo scopo è capire quali sono i requisiti di business
che deve incontrare la soluzione di business scelta per l’area di business
selezionata. Viene sviluppato il Business Requirements View meta-model;
Analysis workflow: ha il compito di tradurre i requisiti di business in
specifiche object-oriented che costituiscono la base per la progettazione delle
soluzioni di business.
Viene sviluppato il Business Transaction View meta-model;
Design workflow: converte l’output del workflow precedente in messaggi
EDI o in una specifica object oriented che può essere usata da venditori
software indipendenti per sviluppare soluzioni di business usando svariate
tecnologie.
Viene sviluppato il Business Service View meta-model.
3.2.3 Il meta-modello UMM
La tecnica utilizzata da UMM per modellare le informazioni e i processi di business
si basa sullo Unified Modeling Language.
32
Al fine di facilitare e di supportare completamente la definizione delle informazioni
e dei processi di business, UMM estende il meta-modello UML per includere un
insieme di specifiche semantica e sintassi. Il meccanismo di estensione utilizzato è
quello degli stereotipi; il meta-modello UMM, quindi, è definito come profilo UML.
Il meta-modello UMM, chiamato e-Business Process Meta-model, è organizzato in
package (Figura 3.2.3).
Figura 3.2.3 Il meta-modello UMM
Ogni package definisce e descrive un insieme di componenti che permettono di
descrivere e analizzare i processi di business da una particolare prospettiva (o vista);
le viste sono:
Business Domain View (BDV): suddivide i processi di business in aree di
business e categorie di business;
Business Requirements View (BRV): cattura gli scenari dei casi d’uso, input,
output, vincoli e limiti del sistema per le transazioni commerciali e loro
interazioni;
Business Transaction View (BTV): cattura le semantiche dell’entità
informative del business e il loro flusso di scambio tra ruoli mentre eseguono le
attività di business;
Business Service View (BSV): specifica i servizi dei componenti di rete e gli
agenti e il loro scambio di messaggi come interazione necessaria per eseguire e
validare un processo di business.
Ciascuna vista viene sviluppata entro un determinato workflow da esperti di
Business Domain View Meta-model
Implementation Framework
View Meta-model
UML Meta-model(from Logical View)
Business Transaction View
Meta-model
Business Service View
Meta-model
Business Requirements View
Meta-model
33
business (Figura 3.2.4).
Workflows Meta Modello UML
Figura 3.2.4 Sviluppo di UN/CEFACT Modeling Methodology
Lo sviluppo di ciascuna vista produce determinati diagrammi UML (Figura 3.2.5);
per supportare lo sviluppo di questi diagrammi, UMM prevede l’utilizzo di un
Repository. Il Repository raccoglie terminologia, informazioni e modelli di business
relativi a molteplici domini e viene sistematicamente aggiornato.
Business DomainExpert
Business ProcessAnalyst
Message Designer
Software Developer
Implementation
Business Modeling
Requirements
Analysis
Design
BRV
BDV
BTV
BSV
BOV
FSV
Technical Modeler
34
Figura 3.2.5 Workflow e loro prodotti
3.2.4 Workflow: prodotti e concetti chiave
Ora saranno illustrati i principali passi da svolgere per sviluppare i workflow relativi
alla Business Operational View secondo UMM [UMMug] [BM].
Il primo workflow è il Business Modeling il cui principale obiettivo è
l’identificazione dei Business Process, ovvero casi d’uso adoperati per specificare i
requisiti relativi ai processi di business. A tal fine, il dominio di business in esame
viene decomposto in principali aree operative, le Business Area che, a loro volta,
Business Process and Information Models
Design
Business Document[Class Diagram]
Service Transaction[Sequence Diagram]
RequirementsBusiness Process
[Use Case Diagram]
Business Process Activity Model
[Activity Diagram]
Business Information[Class Diagram]
Analisys
Business Transaction Activity
[Activity Diagram]
Business Transaction[Object Flow Diagram]
Business Collaboration Protocol
[Object Flow Diagram]
Business Information[Class Diagram]
BusinessKnowledge
UN/CEFACT Development RepositoryLexiconLibrary
BusinessProcess
BusinessEntities
Core Components
Business ModelingBusiness Area
[Packages Diagram]
Process Area[Packages Diagram ]
Business Process [Use Case Diagram]
35
sono suddivise in Process Area; queste ultime sono collezioni di Business Process.
In Tabella 3.2.1 sono riportati i passi da seguire ed i relativi diagrammi UML da
realizzare all’interno del workflow.
Step Diagramma prodotto
1. Identifica e descrivi la Business Area.2. Identifica e descrivi la/e Process Area.
Diagrammi dei package.
3. Identifica i Business Process. Diagrammi dei package che identificano e categorizzano i Business Process entro le Business e Process Area disponibili nel Repository.
4. Identifica i Business Process dalla Business Process Library.
Diagramma dei casi d’uso.
5. Identifica i Business Process e i Partner.
Diagramma finale dei casi d’uso.
Tabella 3.2.1 Step e prodotti del Business Modeling Workflow
Il workflow successivo, il Requirements Workflow, descrive con maggior
dettaglio i processi di business identificati nel precedente passo.
In particolare si descrivono:
gli elementi che compaiono nei processi di business;
i processi di business nella forma di Business Collaboration (insieme di
attività e/o processi svolti dai partner per raggiungere un determinato
obiettivo di business);
le Business Entities, ovvero i concetti, le cose, i processi o gli eventi che
sono rilevanti durante l’esecuzione di una collaborazione di business.
È da sottolineare che per la descrizione degli elementi che compaiono nei
processi di business viene indicata l’ontologia per collaborazioni di business REA
(Resource-Event-Agent); un’ontologia per collaborazioni di business (o processi di
business) è una lista di cose o oggetti che potrebbero essere nell’esecuzione di una
collaborazione.
Osserviamo, inoltre, che nell’identificazione delle Business Collaboration occorre
specificare anche il loro tipo che può essere uno tra:
36
Business Collaboration Protocol: è una collaborazione di business che può
essere suddivisa in altre Business Collaboration e/o Business Transaction ;
Business Transaction: è l’unità atomica della collaborazione di business,
ovvero un’attività non ulteriormente scomponibile.
I passi da compiere all’interno del workflow sono illustrati nella Tabella 3.2.2.
Step Diagramma prodotto
1. Descrivi gli elementi che compaiono nei processi di business utilizzando l’ontologia per collaborazioni di business REA.2. Descrivi ogni Business Process (identificato nel workflow precedente) con maggior dettaglio.
Diagramma dei casi d’uso.
3. Identifica e descrivi le Business Collaboration iniziando con una collaborazione vasta e suddividendola in collaborazioni più piccole che devono essere ulteriormente descritte finché le Business Transaction sono identificate e descritte.
4. Definisci le Business Collaboration. Business Process Activity Model (diagramma delle attività).Conceptual Business Information Model (diagramma delle classi).Diagramma dei casi d’uso per i Business Process.Diagramma dei casi d’uso per i Business Collaboration.
5. Identifica e descrivi le Business Entities
Tabella 3.2.2 Step e prodotti del Requirements Workflow
Nell’Analysis workflow, coerentemente con le descrizioni dei casi d’uso per le
Business Collaboration e tutte le Business Transaction incluse fornite nel precedente
workflow, viene definita la coreografia delle Business Transaction entro le Business
Collaboration, attraverso un activity graph chiamato Business Collaboration
Protocol.
Ogni attività del Business Collaboration Protocol è una Business Transaction
Activity che è ulteriormente descritta da una Business Transaction che è a sua volta
un activity graph (c’è una relazione uno-a-uno tra Business Transaction Activity e
37
Business Transaction). Quindi, i termini Business Transaction Activity e Business
Transaction sono sinonimi dal punto di vista del business, ma si riferiscono a diverse
notazioni in UML.
Una Business Transaction è un’unità atomica di Business Process tra due partner che
coinvolge la spedizione di Business Information da un partner a l’altro e una risposta
opzionale. Una Business Transaction è composta da una Requesting Business
Activity eseguita dal partner che dà il via alla transazione e una Responding
Business Activity eseguita dall’altro partner. La Requesting Business Activity
produce in output una Business Information (rappresentata da un object flow state)
che costituisce l’input per la Responding Business Activity. La Business
Information creata dalla Responding Business Activity e rispedita alla Business
Activity di richiesta è opzionale.
I passi da seguire in questo workflow sono indicati nella Tabella 3.2.3.
Step Diagramma prodotto
1. Definisci un Business Collaboration Protocol per ogni Business collaboration use case.
Business Collaboration Object Flow Diagram.
2. Per ogni Business Transaction Activity, definisci un Business Transaction Activity Graph. Per ongi Business Transaction, identifica le informazioni della richiesta e le informazioni della risposta (opzionale).
Business Transaction Activity Graph (diagramma delle attività).Business Transaction Object Flow Diagram (diagramma delle attività).
3. Crea i diagrammi delle classi riusando strutture di informazioni esistenti
Diagramma delle classi finale delle Business Information
Tabella 3.2.3 Step e prodotti dell’Analysis Workflow
Gli obiettivi principali del Design workflow sono (Tabella 3.2.4):
descrivere le interazioni tra i vari componenti durante le collaborazioni di
business;
descrivere in maniera dettagliata i documenti di business utilizzati..
Step Diagramma prodotto
38
1. Descrivi lo scambio di messaggi che avviene durante le collaborazioni di business.
Diagramma di sequenza.
2. Descrivi i documenti di business scambiati. Diagramma delle classi.
Tabella 3.2.4 Step e prodotti del Design Workflow3.3 Lo XML Metadata Interchange (XMI)
XMI (XML Metadata Interchange) è il formato standard basato su XML che OMG
ha definito per consentire lo scambio di qualunque tipo di meta-dati esprimibile in
termini dello standard MOF.
Descriviamo le caratteristiche, i pregi e i difetti del linguaggio ed esaminiamo come
rappresentare i modelli UML in linguaggio XMI.
Per il lavoro di tesi è stata utilizzata la versione 1.2 delle specifiche.
3.3.1 Cos’è XMI
XMI [XMISp] integra le tre migliori tecnologie per modellazione e meta-dati
(Figura 3.3.1):
- XML;
- UML;
- MOF.
XML è utilizzato come sintassi di trasferimento e formato di interscambio. XMI
definisce due insiemi di regole di produzione che specificano come:
1. generare DTD XML da un meta-modello basato su MOF;
2. generare un documento XML codificando un modello basato su MOF
e viceversa.
Il DTD di un meta-modello permette di validare il file XML del relativo modello.
validate
XMI
XMLSintax and Encoding
MOFMetadata Definitions
and Management
UMLMeta-model Analysis
and Design
XML Streams (Models)
UMLModels
MOFMetaModels
XML DTD (Meta-Models)
UML 1.1
DTD
MOF 1.1
DTD
39
Figura 3.3.1 Rappresentazione semplificata dello XMI
3.3.2 Caratteristiche
Incorporando lo standard XML, XMI ne eredita tutte le caratteristiche ed i vantaggi
che esso offre; in particolare, evidenziamo la possibilità di poter trasportare i meta-
dati attraverso Internet.
Altre caratteristiche interessanti di XMI sono:
- la possibilità di trasferire meta-dati utilizzando più meta-modelli grazie
all’utilizzo dei namespace;
- capacità di trasferire solo parti di documenti;
- un documento XMI può far riferimento ad un elemento XMI di un altro
documento XML usando la tecnologia Xlink;
- XMI fornisce un meccanismo di estensione che consente di estendere il meta-
modello XMI;
- XMI è abilitato a trasferire sottoinsiemi di un modello.
Un aspetto, probabilmente negativo, di XMI è che non specifica in alcun modo
come rappresentare graficamente gli elementi XMI. Questo problema può essere
risolto in due modi:
1. sfruttando il meccanismo di estensione: si estende il meta-modello XMI
introducendovi le informazioni relative alla rappresentazione grafica
(generalmente, questa è la soluzione adottata dai CASE-tool per UML);
2. applicando al file XMI un foglio di stile XSLT.
3.3.3 XMI e UML
Le specifiche XMI forniscono le regole per trasformare meta-modelli basati su MOF
in DTD XML e per trasformare i relativi modelli in documenti XML.
Poiché le specifiche UML definiscono il meta-modello UML come un meta-modello
MOF, queste regole possono essere applicate direttamente al meta-modello e ai
modelli UML.
40
Consideriamo un esempio (Figura 3.3.2).
Figura 3.3.2 Modello UML “Dipartimento”
In Figura 3.3.2 è illustrato un modello UML che rappresenta una piccola parte di un
generico dipartimento universitario. Il file XMI per questo modello è illustrato in
In Figura 5.4.12 mostriamo uno dei file SVG generati.
102
103
Figura 5.4.12 draft_Fornituratessuti_Nsd.svg
104
5.4.5 Implementazione Main
La lista dei Processi selezionati dall’utente (paragrafo 5.3.2) viene inviata, tramite
FORM HTML, alla procedura principale dell’applicazione (main.asp). Questa
procedura gestisce la connessione al Dizionario (tramite la funzione Connessione del
modulo “Gestione Dizionario”) e per ogni processo ricevuto prepara il nome da
assegnare ai relativi file XMI ed SVG (vedi paragrafo 5.2.3), richiama il
“Generatore XMI” (tramite la funzione xmi_gen()), per la creazione del relativo file
XMI, e il “Generatore SVG” (tramite la funzione svg_gen()), per il corrispondente
file SVG (Figura 5.4.13).
Per ragioni di efficienza, la connessione al database è aperta una sola volta tramite la funzione Connessione() del modulo “Gestione Dizionario” ed è chiusa dopo avere creato i file di tutti i processi scelti.
105
Figura 5.4.13 Algoritmo procedura principale
svg_gen(ListaProcessi(ct))
FINE
Ci sono altri elementi in ListaProcessi ?
ListaProcessi elenco dei Processi scelti dall’utente
ct 0
ct ct + 1
xmi_gen(ListaProcessi(ct))
no
sì
INIZIO
Connessione(db)
Disconnect(db)
106
107
ConclusioniIl progetto MODA-ML, nel corso del suo sviluppo, ha implementato un numero
sempre crescente di processi e documenti di business per il settore
Tessile/Abbigliamento; conseguentemente, è aumentata la complessità del
framework, tanto che è sorta l’esigenza di avere una documentazione formale degli
scenari di business supportati che possa fornire agli utenti del progetto una visione
chiara e non ambigua degli scenari di business gestiti. Inoltre, essendo i processi e i
documenti di business supportati in quantità elevata e costantemente crescente, è
risultato evidente il bisogno di poter produrre questa documentazione in maniera
automatica, acquisendo dati dal supporto che attualmente li gestisce: il Dizionario di
MODA-ML.
Il lavoro di tesi si è posto l’obiettivo di fornire al progetto MODA-ML la
documentazione per i processi di business supportati dal framework definendo e
realizzando i modelli di tali processi.
Il primo compito è stato la definizione dei modelli dei processi di business; poiché il
progetto MODA-ML è ispirato allo standard ebXML, per fare ciò si è deciso di
seguire la metodologia di modellazione da esso indicata, vale a dire UMM. I
risultati ottenuti in questa fase sono:- mappatura dei concetti definiti dal vocabolario MODA-ML nei formalismi
del sottoinsieme di UMM adottato da ebXML;
- due soluzioni interscambiabili per rappresentare i processi di business di
MODA-ML tramite diagrammi di sequenza UML.
Successivamente, è stata svolta un’analisi per capire come rappresentare i modelli
definiti in linguaggio UML in un linguaggio machine-readable (XMI), in modo da
consentirne la creazione e l’aggiornamento tramite un’applicazione automatica.
Infine, poiché i tool per la creazione dei diagrammi UML, pur supportando il
formato XMI, non consentono l’importazione automatica dei dati dal Dizionario, è
stata progettata e implementata un’applicazione in grado di fare ciò. Tale
108
applicazione consente di acquisire automaticamente i dati dal Dizionario, generare i
diagrammi di sequenza in formato XMI, trasformare i diagrammi di sequenza in
formato XMI in diagrammi di sequenza in formato SVG. La struttura data all’applicazione è estremamente modulare in modo da consentirne quanto più possibile il riutilizzo.Nello studio svolto particolarmente complicata è risultata la comprensione dell’UMM; ciò è conseguenza del recente sviluppo della metodologia: la documentazione disponibile è molto poca, spesso incompleta e soggetta a continue revisioni, e pochi sono anche gli esempi di suo concreto utilizzo.Considerato ciò, quindi, nel volere applicare la metodologia risulta particolarmente vantaggioso poter disporre di un’applicazione, come quella realizzata dalla tesi, che richiede solo semplici dati di descrizione testuale e automaticamente genera i diagrammi UML-compliant richiesti. Questo vantaggio è stato verificato nell’ambito del lavoro di tesi utilizzando il Dizionario di MODA-ML come sorgente dati per l’applicazione.Le soluzioni proposte per la rappresentazione degli scenari di business di MODA-ML e l’applicazione realizzata per creare i relativi diagrammi di sequenza UML sono stati particolarmente apprezzati dallo staff del progetto MODA-ML, tanto che presto l’applicazione sarà disponibile on-line sul sito del progetto.Il lavoro svolto, tuttavia, non soddisfa completamente le esigenze del progetto, poiché, pur avendo fornito i modelli per rappresentare formalmente i processi di business supportati e un’applicazione software per realizzarli, lascia aperto il problema della rappresentazione della struttura e del contenuto dei documenti di business supportati dal framework.Per rappresentare la struttura e il contenuto dei documenti di business possono essere utilizzati i diagrammi delle classi di UML. Anche in questo caso il primo passo da compiere è l’analisi delle
109
soluzioni proposte da ebXML e UMM. Successivamente, occorre esaminare il Dizionario al fine di individuare tutte le informazioni che devono essere rappresentate e verificare se gli approcci proposti dai due standard possono essere utilizzati nel contesto MODA-ML, eventualmente proponendo degli adattamenti. Infine, è necessaria la realizzazione di una nuova applicazione software per la realizzazione automatica di questa documentazione. I risultati ottenuti da questa tesi quindi costituiscono sicuramente il punto di arrivo per quanto riguarda la modellazione dei processi di MODA-ML, ma sono anche il punto di partenza per la modellazione dei documenti MODA-ML. Il percorso svolto e le soluzioni proposte, infatti, presentano molte analogie con le problematiche che dovranno essere affrontate a questo scopo.
110
111
Appendice A UML: approfondimenti
A.1 La modellazione
La modellazione consiste nella costruzione del modello di un sistema di qualunque
tipo (software o altro) da sviluppare o già sviluppato. Un modello è una
rappresentazione visuale, formale e semplificata del sistema, e che permette di
analizzarne particolari caratteristiche tralasciandone altre non rilevanti; è quindi un
mezzo per facilitare la comprensione del sistema che rappresenta.
In generale, non è sufficiente un solo modello per descrivere un sistema, ma
occorrono più viste, ognuna delle quali si concentra su un numero limitato di aspetti;
questa necessità si avverte notevolmente in sistemi di medie e grandi dimensioni.
Ci sono dei requisiti che un modello deve soddisfare affinché sia idoneo al suo
scopo:
accuratezza: deve descrivere il sistema correttamente, completamente e senza
ambiguità;
coerenza: le diverse viste devono completarsi vicendevolmente per formare un
insieme senza contraddizioni;
semplicità: deve poter essere di facile comprensione a persone estranee al
processo di modellazione;
manutenibilità: deve poter essere semplice effettuare modifiche al modello
stesso.
Come detto inizialmente, i modelli vengono progettati nei processi di modellazione;
l'attuazione di un processo di modellazione è un fattore di particolare rilievo in due
fasi del ciclo di vita di un sistema:
progettazione del sistema;
documentazione del sistema.
Analizziamo il primo contesto.
112
Lo scopo della progettazione di un sistema è produrre delle specifiche che guidino
l'implementazione concreta dei componenti del sistema stesso.
L'utilizzo dei modelli per tale obiettivo porta notevoli vantaggi: in breve tempo e a
costi contenuti, i modelli permettono di definire in maniera chiara i requisiti del
sistema ed offrono una rappresentazione semplificata dello stesso. Questo significa
poter esaminare il comportamento e alcune caratteristiche (come affidabilità e
prestazioni) del sistema finale, poter effettuare adeguate analisi dei tempi di
sviluppo, migliori stime dei costi di produzione, eque distribuzioni del carico di
lavoro e così via; inoltre, è possibile studiare le reazioni del sistema a particolari
situazioni che possono perciò essere preventivamente e adeguatamente gestite.
La modellazione, quindi, permette di effettuare la progettazione di un sistema in
maniera molto efficiente e di ridurre notevolmente i fattori di rischio (come
l'insoddisfacente rendimento delle tecnologie adottate o la mancata corrispondenza
dei requisisti finali con quelli inizialmente richiesti) presenti nello sviluppo di ogni
progetto.
Esaminiamo ora l'importanza della modellazione per documentare il sistema
sviluppato.
La maggior parte delle volte il sistema realizzato viene utilizzato da utenti diversi
dai suoi sviluppatori o subisce aggiornamenti o modifiche per mano di persone che
non hanno partecipato al suo processo produttivo. Una buona documentazione dello
stesso sistema consente ai suoi utilizzatori e ai suoi nuovi sviluppatori di
comprenderlo a fondo, evitando loro di sottovalutare le sue potenzialità o apportare
modifiche incoerenti con i principi in base ai quali è stato sviluppato.
I modelli, gestendo la complessità del sistema e dando una descrizione completa e
non ambigua delle sue caratteristiche, rispondono perfettamente ai requisiti che una
buona documentazione dovrebbe avere.
Proprio per l'importanza della modellazione, in passato sono stati sviluppati molti
metodi di modellazione; tra i tanti, i tre che maggiormente sono stati apprezzati e
che sono stati il punto di partenza per la realizzazione di UML sono: Booch’93,
OOSE e OMT-2.
Ognuno dei tre è un metodo completo e in ognuno spiccano determinate
caratteristiche per cui, per determinati scopi, risulta più efficace degli altri; li
113
analizziamo brevemente.
Il metodo Booch ’93 definisce una notazione in cui il sistema viene analizzato e
suddiviso in un insieme di viste, ciascuna costituita da diagrammi di modello; inoltre
specifica un processo in base al quale il sistema viene studiato attraverso micro- e
macroviste di sviluppo. È molto efficace nelle fasi di disegno e di codifica dei
progetti.
Il metodo OOSE si basa quasi interamente sugli Use Case (casi d'uso), che
permettono di definire i requisiti iniziali del sistema così come vengono percepiti da
un attore esterno allo stesso, perciò risulta essere un supporto eccellente in fase di
analisi dei requisisti del sistema.
Infine, il metodo OMT-2 prevede che il sistema venga descritto attraverso un
numero preciso di modelli che si completano vicendevolmente; è molto efficace
nella fase di definizione dei requisisti del sistema. Inoltre, grazie all'accuratezza con
il quale viene realizzato, il modello fornisce un valido ausilio anche alla fase di test
del sistema.
Nei paragrafi successivi spiegheremo come, da questi tre metodi, è nato UML.
A.2 I linguaggi di modellazione e la guerra dei metodi
Un linguaggio di modellazione è il formalismo che un metodo usa per esprimere i
modelli (precisiamo che un linguaggio di modellazione non è necessariamente
legato ad uno specifico metodo). La differenza importante tra metodo e linguaggio
di modellazione è che il primo ha la nozione di processo di sviluppo, ovvero indica
ai progettisti cosa fare, come farlo, quando e perché, il secondo no.
Un linguaggio di modellazione deve includere:
elementi di modello: concetti fondamentali che compongono il modello e loro
significato;
notazione: riproduzione visuale degli elementi di modello;
linee guida: stili di utilizzo nell'applicazione concreta.
I linguaggi di modellazione orientati agli oggetti appaiono per la prima volta dopo la
prima metà degli anni '70, quando vari metodologi iniziano a sperimentare nuovi
approcci in fase di analisi e disegno object oriented che portano alla formulazione di
114
nuovi metodi di modellazione.
Il numero dei metodi aumenta da meno di 10 nel 1989 ad oltre 50 nel 1994; i più
apprezzati sono Booch'93 (ideato da Grady Booch), OMT-2 (il cui principale autore
è Jim Rumbaugh) e OOSE (di cui Ivar Jacobson è uno dei più importanti promotori).
Nonostante la vasta scelta però, nessun metodo sembra soddisfare completamente
gli utilizzatori dei metodi OO che così alimentano la “guerra dei metodi”. Nascono
quindi numerosi metodi di modellazione che finiscono col creare seri problemi: le
grandi aziende non sapendo quale processo adottare spesso ne sviluppano uno
proprietario, mentre le medie-piccole imprese affidano la scelta alla capacità e alla
saggezza dei propri sviluppatori; i risultati sono la totale incomunicabilità tra i vari
team di sviluppo e la completa incoerenza tra progetti sviluppati in tempi diversi e
sotto la direzione di persone diverse.
Inevitabilmente, quindi, sorge l'esigenza di avere un unico metodo capace di porre
fine alla proliferazione in atto.
UML nasce proprio in questi anni e, considerando i problemi esposti, è facile
immaginare perché abbia riscosso tanto successo e ricevuto prestigiose
collaborazioni.
A.3 La storia di UML
UML nasce nel 1994 quando Grady Booch e Jim Rumbaugh della Rational Software
Corporation iniziano a collaborare per unificare i loro metodi; a questa
cooperazione, dopo circa un anno, si unisce Ivar Jacobson che introduce nel
processo di unificazione il metodo OOSE.
Tre sono i motivi che spingono i tre uomini a cooperare: innanzitutto i loro metodi si
stanno già evolvendo verso una direzione comune; in secondo luogo, l’unificazione
dei significati e delle notazioni potrebbe giovare alla stabilità del mercato object-
oriented; infine, ritengono che la loro collaborazione potrebbe portare miglioramenti
a tutti e tre i singoli metodi.
Il primo frutto di questa collaborazione si ha nell'ottobre 1995 per opera di Booch e
Rumbaugh: viene rilasciata una bozza del Metodo Unificato (così è chiamato)
versione 0.8.
115
Poi, nel giugno e nell'ottobre 1996, successivamente all'arrivo di Jacobson alla
Rational e all'introduzione del metodo OOSE nel processo di unificazione, vengono
rilasciati i documenti UML 0.9 e 0.91.
Tuttavia sono ancora molte le questioni non risolte e, considerato l’elevato numero
di organizzazioni interessate ad utilizzare UML, viene istituito un consorzio di
partner di UML intenzionati ad investire risorse per raggiungere una solida
definizione del linguaggio. Il loro principale apporto consiste in conoscenze relative
a tecnologie, business modeling, meta-metamodelli, ambienti distribuiti e così via.
Tra questi, per il notevole contributo, citiamo: Digital Equipment Corp., HP, i-
[Diz] Thomas Imolesi, Creazione di framework per lo scambio dati fra imprese: Dizionario e Generatore di XML Schema in MODA-ML, Tesi di Laurea, Università degli Studi di Ferrara - Facoltà di Scienze Matematiche, Fisiche e Naturali - Corso di Laurea in Informatica, Sessione straordinaria A.A. 2001-2002
[ebBPAWG] Business Process Team, Business Process Analysis Worksheets &
Guidelines v1.0, Technical Report, 10 maggio 2001,
http://www.ebxml.org/specs/bpWS.pdf
[ebBPSS] Business Process Project Team ebXML - Business Process Specification
Schema v1.01, Technical Specification, 11 maggio 2001, http://www.e-