Post on 16-Feb-2019
transcript
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
3.3.1 Cos’è XMI....................................................................................................39
3.3.2 Caratteristiche..............................................................................................40
3.3.3 XMI e UML.................................................................................................40
4 Analisi e individuazione degli obiettivi.......................................................................43
I
4.1 Gli scenari di business di MODA-ML.................................................................44
4.1.1 I processi di business di MODA-ML...........................................................44
4.2 ebXML e la modellazione degli scenari di business............................................45
4.2.1 ebXML e UMM...........................................................................................46
4.2.2 Business Process Specification Schema......................................................47
4.2.3 Rappresentazione delle collaborazioni di business tramite..........................50
diagrammi UML...................................................................................................50
4.3 La modellazione degli scenari di business di MODA-ML...................................56
4.3.1 Associazione tra MODA-ML ed ebXML....................................................56
4.3.2 Rappresentazione degli scenari di business MODA-ML con......................58
diagrammi UML...................................................................................................58
4.3.3 Il Dizionario di MODA-ML........................................................................62
4.3.4 Mapping tra Dizionario e diagrammi di sequenza.......................................63
4.4 La creazione dei modelli degli scenari di business di MODA-ML.............69
4.4.1 La scelta di XMI..........................................................................................69
4.4.2 Mapping tra diagrammi di sequenza e XMI................................................69
4.4.3 Esempio........................................................................................................72
4.4.4 Strumenti software.......................................................................................75
5 MODA-MICS: Progettazione e Implementazione.....................................................79
5.1 Analisi dei requisiti...............................................................................................79
5.1.1 Requisiti architetturali..................................................................................79
5.1.2 Requisiti funzionali......................................................................................81
5.2 Architettura...........................................................................................................83
5.2.1 Architettura software....................................................................................83
5.2.2 Meccanismo XSLT......................................................................................85
5.2.3 Repository dei file e regole di naming.........................................................85
5.2.4 Ambiente di sviluppo...................................................................................86
5.2.5 Connessione al Dizionario di MODA-ML...................................................87
5.3 Interfaccia utente..................................................................................................87
5.3.1 Interfaccia Staff: scelta della lingua e della versione del Dizionario...........88
5.3.2 Interfaccia Staff: scelta dei Processi............................................................89
5.3.3 Interfaccia Staff: stato di avanzamento della procedura di generazione......90
II
5.3.4 Interfaccia Utenti: visualizzazione dei diagrammi di sequenza..................91
5.4 Implementazione..................................................................................................92
5.4.1 Implementazione funzioni “Gestione Dizionario”.......................................92
5.4.2 “Generatore XMI”: implementazione delle funzioni principali..................94
5.4.3 “Generatore XMI”: il problema degli attributi ID e IDREF........................96
5.4.4 Implementazione modulo “Generatore SVG”...........................................100
5.4.5 Implementazione Main..............................................................................104
Conclusioni...................................................................................................................107
Appendice A UML: approfondimenti.........................................................................111
A.1 La modellazione.................................................................................................111
A.2 I linguaggi di modellazione e la guerra dei metodi...........................................113
A.3 La storia di UML...............................................................................................114
A.4 I diagrammi UML..............................................................................................116
A.4.1 Il diagramma dei casi d’uso......................................................................116
A.4.2 I diagrammi di struttura statica.................................................................119
A.4.3 I diagrammi d’interazione.........................................................................122
A.4.4 I diagrammi di stato..................................................................................125
A.4.5 I diagrammi d’implementazione...............................................................128
A.4.6 Il diagramma dei componenti....................................................................130
A.4.7 Il diagramma di dislocamento...................................................................131
Appendice B UMM: approfondimenti........................................................................133
B.1 Esempio: vendita di prodotti usando un catalogo..............................................133
elettronico.................................................................................................................133
Appendice C BPSS......................................................................................................147
Bibliografia...................................................................................................................149
Ringraziamenti.............................................................................................................153
III
IV
1 Introduzione
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
concordato (Collaboration Protocol Agreement - CPA);
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
Figura 3.3.3.
Dipartimento
Insegnante
membroDi
compostoDa
LettoreProfessore Assistente
<XMI version="1.2" xmlns:UML="org.omg/UML1.5">
<XMI.header>
<XMI.model xmi.name="Dipartimento" href="Dipartimento.xmi"/>
<XMI.metamodel xmi.name="UML" href="UML.xmi"/>
</XMI.header>
<XMI.content>
<UML:Class name="Dipartimento" xmi.id="Dipartimento"/>
<UML:Class name="Insegnante" xmi.id="Insegnante"/>
<UML:Class name="Professore" xmi.id="Professore"
generalization="Insegnante"/>
<UML:Class name="Lettore" xmi.id="Lettore" generalization="Insegnante"/>
<UML:Class name="Assistente" xmi.id="Assistente”
generalization="Insegnante"/>
<UML:Association>
<UML:Association.connection>
<UML:AssociationEnd name="compostoDa" type="Insegnante"/>
<UML:AssociationEnd name="membroDi" type="Dipartimento"/>
</UML:Association.connection>
</UML:Association>
</XMI.content>
</XMI>
header XMI
modello
UML
41
Figura 3.3.3 Dipartimento.xmiOra modelliamo un’istanza del modello Dipartimento (Figura 3.3.4).
Figura 3.3.4 Istanza UML del modello “Dipartimento”
La trasformazione XMI per l’istanza UML in Figura 3.3.4 è illustrata in Figura
3.3.5.
SSMMFF:Dipartimento
Vitali:Insegnante
Gessa:Assistente
<XMI version="1.2" xmlns:Dip="Dipartimento">
<XMI.header>
<XMI.model xmi.name="SSMMFF" href="SSMMFF.xmi"/>
<XMI.metamodel xmi.name="Dipartimento" href="Dipartimento.xmi"/>
</XMI.header> <XMI.content>
<Dip:Dipartimento name="SSMMFF">
<Dip:Dipartimento.compostoDa>
<Dip:Professore name="Vitali" xmi.id="prof_uno"/>
<Dip:Assistente name="Gessa" xmi.id="ass_uno"/>
</Dip:Dipartimento.compostoDa>
</Dip:Dipartimento>
</XMI.content>
</XMI>
header XMI
istanza
delmodello UML
42
Figura 3.3.5 SSMMFF.xmi
43
4 Analisi e individuazione degli obiettiviNel corso dello sviluppo del progetto MODA-ML, il numero sempre crescente di
processi e documenti di business implementati dal framework ne ha aumentato la
complessità, tanto che sono sorte tre esigenze non previste all’inizio dei lavori:
1. generare automaticamente una documentazione completa e
non ambigua di tutti gli scenari di business supportati dal framework, ovvero
definire e realizzare i modelli di tali scenari;
2. riflettere sui relativi modelli gli eventuali aggiornamenti
apportati al vocabolario;
3. trasportare le informazioni relative agli scenari di business
memorizzate nel Dizionario di MODA-ML in un formato machine-readable,
in modo che possano essere direttamente utilizzate da tool CASE.
In questo capitolo sarà proposta un’unica soluzione per risolvere questi tre problemi,
ossia creare i modelli in un formato machine-readable. Ovviamente, ciò implica
l’adozione di modelli capaci di incorporare tutte le informazioni custodite nel
Dizionario di MODA-ML e, al tempo stesso, conformi ad una metodologia di
modellazione coerente.
Poiché MODA-ML si basa sul framework standard ebXML, si analizzano le
metodologie di modellazione da esso proposte, cercando di capire come adattare le
soluzioni fornite alle esigenze del progetto MODA-ML; successivamente, sono
definiti i modelli dei processi di business di MODA-ML, viene individuato il
formato machine-readable nel quale esprimerli e lo strumento software necessario
per realizzarli e visualizzarli in forma grafica, in modo da poterli anche includere
nella documentazione relativa al progetto MODA-ML già esistente.
44
4.1 Gli scenari di business di MODA-ML
Al fine di avere una visione chiara e precisa della realtà da modellare, analizziamo
gli scenari di business supportati dal framework MODA-ML.
4.1.1 I processi di business di MODA-ML
Il progetto MODA-ML [MODA-ML], seguendo l’approccio proposto dalle
specifiche ebXML, suddivide il lavoro svolto dai vari segmenti della filiera del
Tessile/Abbigliamento in una serie di processi. Ogni processo è costituito da una
sequenza di attività a loro volta composte da una o più transazioni; per transazione
s’intende lo scambio di un documento tra due segmenti della filiera. Inoltre, per ogni
processo sono identificati gli attori, ovvero i segmenti filiera che danno vita agli
scambi di documenti relativi alle attività del processo. Attualmente, tutti i processi
definiti vedono in gioco due attori, ma ciò non esclude che possano essere
individuati processi con un numero arbitrario di attori.
Come esempio, descriviamo il processo “Fornitura Tessuti” (Figura 4.1.1):
Figura 4.1.1 Processo MODA-ML Fornitura Tessuti
Il processo “Fornitura Tessuti” descrive le fasi attraverso le quali il Fornitore di
tessuti fornisce i tessuti al Confezionista; il processo è composto da tre attività:
“Scelta Tessuti”: il Confezionista sceglie i tessuti a partire da listini e schede
tecniche forniti dal Fornitore di tessuti;
“Acquisto Tessuti”: il Confezionista acquista i tessuti dal Fornitore di tessuti;
“Spedizione Tessuti”: il Fornitore di tessuti invia la merce ordinata al
Confezionista.
Scelta Tessuti
Acquisto Tessuti
Spedizione Tessuti
Fornitore di tessuti Confezionista
45
Analizziamo, come esempio, le transazioni che compongono l’attività “Acquisto
Tessuti” (Figura 4.1.2) e i documenti scambiati in ciascuna di esse.
Figura 4.1.2 Attività MODA-ML “Acquisto Tessuti”
Nella prima transazione dell’attività, “Ordine”, viene scambiato il documento
TEXOrder.xml; questo documento è emesso dal Confezionista e specifica tutti i dati
necessari per ordinare una fornitura di tessuto.
Il documento scambiato nella seconda transazione, “Risposta ordine”, è
TEXOrdResponse.xml e viene inviato dal Fornitore di tessuti in risposta ad un
ordine di fornitura di tessuto.
Nella transazione seguente, “Modifica ordine”, il Confezionista invia il documento
TEXOrdChange.xml che gli consente di modificare un ordine di fornitura di tessuto
emesso precedentemente.
Il documento scambiato nell’ultima transazione, “Avanzamento ordine”, è
TEXOrdStatus.xml; viene emesso dal Fornitore di tessuti per riportare al
Confezionista lo stato di avanzamento dei suoi ordini.
Nei prossimi capitoli analizzeremo le metodologie di modellazione proposte da
ebXML per poi applicarle ai concetti di MODA-ML appena esposti.
4.2 ebXML e la modellazione degli scenari di business
Le specifiche ebXML raccomandano esplicitamente l’utilizzo di UMM per la
modellazione degli scenari di business e definiscono una vista aggiuntiva del meta-
modello UMM, il Business Process Specification Schema (BPSS), per la diretta
modellazione degli scenari ebXML. Illustriamo i concetti definiti dal BPSS e,
poiché le specifiche non forniscono alcuna indicazione su come modellare questi
Fornitoredi
Tessuti
Ordine
Avanzamento ordine
Modifica ordine
Risposta ordineConfezionista
46
concetti utilizzando i diagrammi UML, presentiamo l’approccio adottato a tale
scopo.
4.2.1 ebXML e UMM
Le specifiche ebXML non impongono la modellazione dei processi e delle
informazioni di business, tuttavia nel caso in cui gli sviluppatori o gli utenti di
software basato su ebXML decidano di farlo, è esplicitamente raccomandato
l’utilizzo di UMM [ebTA]. La metodologia UMM e il suo meta-modello, infatti,
permettono di specificare tutte le informazioni utili per descrivere uno scenario di
business in ambito ebXML, in modo forse più dettagliato del necessario. Per questo
motivo, ebXML fornisce una vista aggiuntiva del meta-modello UMM: il Business
Process Specification Schema (BPSS). Questa vista è sostanzialmente un
sottoinsieme del meta-modello UMM e permette di specificare direttamente gli
elementi richiesti per configurare un sistema runtime per eseguire collaborazioni di
business ebXML (Figura 4.2.1) [ebBPSS].
Figura 4.2.1 Meta-modello UMM e BPSS
UMM
UMM Business Process and Information Model
UMM Business Process and Information
Modeling
UMM Business Libraries
UMMMethodology
UMMMeta Model
(UML Profile) Business Process Information
ebXMLebXML
Business Process Specification Schema
ebXML CC Document
Metamodel
ebXMLBusiness ProcessSpecification
ebXMLDocument Specification
47
4.2.2 Business Process Specification Schema
Il Business Process Specification Schema (BPSS) fornisce la semantica, gli elementi
e le proprietà necessari per definire collaborazioni di business ebXML-compliant;
una collaborazione è un insieme di interazioni tra partner che, interagendo, si
scambiano una serie di documenti di business. Ciascun partner gioca uno o più ruoli
nella collaborazione.
L’architettura del BPSS consiste delle seguenti componenti:
versione UML del BPSS;
versione XML del BPSS;
regole di Produzione (Production Rules) che definiscono il mapping fra la
versione UML e la versione XML dello Schema;
definizione dei Segnali di Business (messaggi utilizzati per segnalare lo stato
delle transazioni di business).
La vediamo illustrata in Figura 4.2.2 [ebBPSS].
* Nel rettangolo tratteggiato sono racchiusi i componenti del BPSS
Figura 4.2.2 Relazione tra il BPSS di ebXML e UMM, CPP/CPA e Core Components
*
UMM Metamodel
SemanticSubset
UMM Pattern
Specification Schema (UML)
Business Signal Definitions
Production Rules
Specification Schema(XML)
DTD W3C Schema
TP Document DTD’s
CPP CPADefinizione dei Docuementi di
Business
CoreComponents
48
Al fine di avere una visione completa di tutti gli elementi (e delle relazioni tra essi)
di cui si dispone per modellare le collaborazioni di business, riportiamo la versione
UML del BPSS (Figura 4.2.3), limitandoci ad illustrare solo i concetti utili per la
modellazione del mondo MODA-ML.
Figura 4.2.3 Sottoinsieme dell’ebXML Business Process Specification Schema
(versione UML del BPSS completa in Appendice C)
Il BPSS supporta due livelli di collaborazioni di business: le Binary Collaboration
e le Multiparty Collaboration.
Una Binary Collaboration è sempre tra due ruoli; questi ruoli sono chiamati
Authorized Roles poiché rappresentano gli attori (partner) autorizzati a partecipare
Business Transaction
0..1 +requesting +responding 0..1
1 n
+documentEnvelope +documentEnvelope
n 1
RequestingBusinessActivity RespondingBusinessActivity
Document Envelope
+transaction +transaction
1 1
+requester +responder
1
CollaborationActivity
BusinessTransactionActivity
BusinessDocumentn 1
Authorized Role BinaryCollaboration
BusinessActivity
49
alla collaborazione.
Una Multiparty Collaboration, invece, è una collaborazione a cui partecipano più di
due ruoli ed è definita in termini di due o più Binary Collaboration.
Una Binary Collaboration è espressa come un insieme di Business Activity tra due
Authorized Roles della Binary Collaboration. Ogni Business Activity riflette uno
stato nella collaborazione. La Business Activity può essere una Business
Transaction Activity, cioè l’attività di condurre una singola Business Transaction,
o una Collaboration Activity, cioè l’attività di condurre un’altra Binary
Collaboration.
Grazie a questa proprietà della Binary Collaboration di poter specificare altre Binary
Collaboration è possibile usare ricorsivamente le Binary Collaboration. Ogni Binary
Collaboration, quindi, è un protocollo riusabile tra due ruoli.
Le Binary Collaboration non forniscono alcuna informazione sull’ordine di
esecuzione delle Business Transaction Activity e delle Collaboration Activity.
Questa informazione è fornita dalla Business Choreography che consiste nella
specifica dell’ordine delle transizioni tra gli stati della Binary Collaboration, ossia le
Business Activity.
Una Business Transaction è l’unità atomica di lavoro in un accordo commerciale
tra due business partner che giocano, nella transazione, uno il ruolo di Initialing
Role e l’altro il ruolo di Responding Role.
Anche la Business Transaction è un protocollo riusabile tra due ruoli. Il suo riuso è
possibile facendovi riferimento da una Binary Collaboration attraverso l’uso di
Business Transaction Activity. Una Business Transaction è composta da una
Requesting Business Activity e una Responding Business Activity.
Alla Requesting Business Activity è associato un Document Envelope, mentre alla
Responding Business Activity possono essere associati zero o più Document
Envelope. Il Document Envelope rappresenta il flusso di documenti tra i ruoli e fa
riferimento ad un Business Document (documento di business) principale e,
opzionalmente, ad uno o più attachment relativi al Business Document principale.
50
4.2.3 Rappresentazione delle collaborazioni di business tramite diagrammi UML
Il BPSS definisce i concetti necessari per descrivere in modo completo le
collaborazioni di business ebXML, ma non fornisce alcuna indicazione precisa
relativamente a come rappresentarle utilizzando i diagrammi UML.
Prendendo come guida la metodologia UMM, cerchiamo di capire come e perché
utilizzare i diagrammi UML per modellare le collaborazioni di business ebXML
[ebBPAWG] [sup].
Il primo passo è capire cosa effettivamente dobbiamo rappresentare e,
conseguentemente, scegliere il tipo di diagramma, tra quelli offerti da UML, che
meglio si presta a farlo.
Gli aspetti da rappresentare sono tre:
Binary Collaboration;
Business Transaction;
Business Choreography.
Iniziamo ad esaminare le Binary Collaboration.
Come analizzato precedentemente, una Binary Collaboration descrive un insieme
di Business Activity condotte tra due Authorized Role, specificando chi tra questi è
l’InitialingRole e chi il RespondingRole. In altre parole, una Binary Collaboration
definisce un gruppo di interazioni tra due oggetti.
Il diagramma UML indicato in questi casi è il diagramma di sequenza che,
appunto, permette di modellare la comunicazione tra un oggetto ed un altro in
relazione al trascorrere del tempo [UML].
In questo tipo di diagramma gli oggetti sono rappresentati con dei rettangoli
disegnati vicino alla sommità del diagramma e sono disposti in una qualsiasi
sequenza da sinistra verso destra. Da ogni rettangolo si diparte una linea tratteggiata
verso il basso, denominata "linea della vita" (lifeline), lungo la quale si trova un
piccolo rettangolo chiamato "attivazione" (activation). L'activation rappresenta
l'esecuzione di un'operazione di cui l'oggetto si fa carico. La lunghezza del
rettangolo, invece, rappresenta la durata dell'activation. Lo illustriamo in Figura
4.2.4:
51
Figura 4.2.4 Notazione grafica per gli oggetti nei diagrammi di sequenza
Ogni messaggio scambiato tra gli oggetti, viene disegnato a partire dalla lifeline
dell'oggetto che invia il messaggio e arriva sulla lifeline dell'oggetto a cui il
messaggio è diretto.
I messaggi possono essere di due tipi:
sincrono: se un oggetto invia un messaggio sincrono, allora si attende che gli
venga restituita una risposta al messaggio stesso prima di poter continuare
con altre operazioni (notazione grafica: );
asincrono: se un oggetto invia un messaggio asincrono, non attende che gli
venga inviata alcuna risposta prima di continuare con altre operazioni
(notazione grafica: ).
Inoltre, viene utilizzata anche la notazione per indicare il ritorno da un
messaggio (non è un nuovo messaggio).
Il trascorrere del tempo viene indicato dalla direzione verticale. Graficamente il
tempo viene fatto partire alla base di ogni oggetto e proseguire fino in basso. Ad
esempio, un messaggio che si trovi più vicino all'oggetto rispetto ad un altro
(rispetto alla direzione verticale) si verifica prima nel tempo.
Tornando alla rappresentazione delle Binary Collaboration, quindi, l’Initialing Role
e il Responding Role possono essere modellati come oggetti UML.
Per quanto riguarda le Business Transaction Activity, invece, definiamo uno
stereotipo, <<BTA>>, che estende la classe Message del meta-modello UML. La
classe Message rappresenta le interazioni tra gli oggetti e graficamente è raffigurata
con i vari tipi di frecce illustrati precedentemente; definendo un suo stereotipo, ne
specifichiamo un nuovo significato, ovvero l’esecuzione di una Business
Transaction Activity. Come notazione grafica utilizziamo quella dei messaggi
asincroni; logicamente la freccia parte dall’Initialing Role ed arriva al
52
RespondingRole. Ugualmente, per le Collaboration Activity definiamo lo stereotipo
<<CA>> [Kim02].
Consideriamo il seguente esempio: un Venditore e un Compratore sono gli
Authorized Role partecipanti alla Binary Collaboration “Acquisto prodotto”. Le
Business Transaction Activity della Binary Collaboration sono: “Ordine prodotto”,
“Avviso di spedizione” e “Avviso di ricezione del prodotto”. Nelle Business
Transaction Activity “Ordine prodotto” e “Avviso di ricezione del prodotto” il
Venditore gioca il ruolo di Initialing Role e il Venditore quello di Responding Role;
nella Business Transaction Activity “Avviso di spedizione” avviene il contrario.
Vediamo la rappresentazione della Binary Collaboration tramite diagramma di
sequenza in Figura 4.2.5.
Figura 4.2.5 Binary Collaboration “Acquisto prodotto”
Osserviamo, però, che nel diagramma manca un’informazione, cioè la Business
Transaction cui fa riferimento la Business Transaction Activity. Per aggiungere
questo dato, possiamo utilizzare nuovamente uno dei meccanismi di estensione
offerti da UML, quello dei tagged value. Infatti, aggiungendo un tagged value “BT”
alla classe <<BTA>> riusciamo ad indicare quale Business Transaction viene
Compratore:RespondingRole
Venditore:InitialingRole
<<BTA>>Avviso di spedizione
Compratore:InitialingRole
Venditore:RespondingRole
<<BTA>>Ordine prodotto
<<BTA>>Avviso di ricezione del prodotto
53
eseguita dalla Business Transaction Activity.
Come esempio, consideriamo la Business Transaction “Ordine” eseguita dalla
Business Transaction Activity “Ordine prodotto” illustrata precedentemente (Figura
4.2.6):
Figura 4.2.6 Come specificare le Business Transaction eseguite dalle Business Transaction Activity
Proseguiamo con l’analisi delle Business Transaction.
Una Business Transaction è un insieme di flussi di documenti; c’è sempre un flusso
di richiesta, mentre possono esserci zero o più flussi di risposta. Associati con ogni
flusso di documenti possono esserci uno o più segnali di business. Modellare una
Business Transaction, quindi, significa modellare la sequenza dei flussi di
documenti che fanno parte della Requesting Business Activity e della Responding
Business Activity.
Il diagramma UML per fare ciò è, anche in questo caso, il diagramma di sequenza,
modellando i Document Envelope e i Business Signal come messaggi asincroni
(Figura 4.2.7).
Figura 4.2.7 Rappresentazione delle Business Transaction
:Requesting Activity
:Responding Activity
Flusso di richiesta
Ack I
Acceptance Ack
Flusso di risposta
Ack l II
Compratore:InitialingRole
Venditore:RespondingRole
<<BTA>>Ordine prodotto
BT: Ordine
54
Nel diagramma, però, occorre inserire l’informazione relativa ai Business Document
cui fa riferimento il Document Envelope; anche in questo caso ricorriamo al
meccanismo dei tagged value. Aggiungiamo, quindi, il tagged value “BD” alla
classe Message per indicare il Business Document cui fa riferimento il Document
Envelope.
Come esempio, modelliamo la Business Transaction “Ordine” (Figura 4.2.8) della
Business Transaction Activity illustrata precedentemente (Figura 4.2.6).
Figura 4.2.8 Business Transaction “Ordine”
L’ultimo aspetto da modellare è la Business Choreography, ossia l’ordine di
esecuzione delle Business Activity all’interno della Binary Collaboration.
Considerando che ogni Business Activity è uno stato della Binary Collaboration, si
tratta di rappresentare una sequenza di transizioni tra stati; il diagramma UML che
può essere utilizzato per far ciò è il diagramma delle attività.
Un diagramma delle attività è un insieme di stati e transizioni tra essi; ogni stato
rappresenta l’esecuzione di un’opportuna attività, mentre le transizioni
rappresentano le relazioni tra i diversi stati e indicano le condizioni necessarie per il
verificarsi della transizione stessa [UML].
La notazione grafica per i diagrammi delle attività è la seguente (Tabella 4.2.1):
:Requesting Activity
:Responding Activity
Flusso di richiesta
BD: documento ordine
Ack I
Flusso di risposta
BD: documento conferma ordine
Ack II
Response Document Flow
Receipt Ack. Signal II
55
Elemento Notazione
Stato iniziale
Stato finale
Altri stati
Transizione
Tabella 4.2.1 Elementi dei diagrammi delle attività
Poiché ogni Business Activity è uno stato della Binary Collaboration, basta
realizzare un diagramma delle attività in cui ogni stato è una Business Activity e le
transizioni tra essi rispettano le condizioni di transizione tra le Business Activity
entro la Binary Collaboration.
In Figura 4.2.9 illustriamo la Business Choreography relativa alla Binary
Collaboration “Acquisto prodotto” (Figura 4.2.5).
Figura 4.2.9 Business Choreography “Acquisto prodotto”
Nome stato
Ordine prodotto
Avvisospedizione
Avviso di ricezionedel prodotto
56
4.3 La modellazione degli scenari di business di MODA-ML
Effettuiamo la mappatura tra i concetti definiti dalle specifiche MODA-ML e quelli
definiti dalle specifiche ebXML e, sulla base della soluzione fornita nel paragrafo
4.2, presentiamo due possibili rappresentazioni degli scenari di business MODA-
ML. Inoltre, illustriamo come le rappresentazioni proposte consentono di modellare
tutte le informazioni mantenute nel Dizionario.
4.3.1 Associazione tra MODA-ML ed ebXML
Esaminiamo come relazionare i termini definiti nelle specifiche MODA-ML al
BPSS, iniziando con l’analizzare il concetto di transazione, che in MODA-ML è
l’unità elementare di una collaborazione di business, fino ad arrivare al concetto più
ampio, quello di processo.
Per quanto riguarda il concetto di Transazione, le specifiche MODA-ML
implementano solo parzialmente il Business Process Specification Schema.
Secondo il BPSS, infatti, l’unità atomica di una collaborazione di business è la
Business Transaction Activity; ogni Business Transaction Activity fa riferimento ad
una Business Transaction che è composta esattamente da una Requesting Business
Activity, a cui è associato un Document Envelope, e una Responding Business
Activity, a cui possono essere associati zero o più Document Envelope.
In MODA-ML, invece, ogni transazione è sempre costituita semplicemente
dall’invio di un documento e non da una coppia “documento di richiesta –
documento di risposta”, come previsto da ebXML. Questa scelta è stata effettuata
per permettere agli attori di poter inviare anche solo alcuni dei messaggi previsti.
Tuttavia, secondo la definizione di Business Transaction del BPSS, è possibile non
specificare alcun Business Document nella Responding Business Activity. Grazie a
questa possibilità, è possibile mappare ogni transazione MODA-ML in una Business
Transaction in cui la Requesting Business Activity ha come Business Document
associato il documento scambiato nella transazione, mentre alla Responding
Business Activity non è collegato alcun Business Document.
57
Le Attività MODA-ML sono sequenze di transazioni e fanno parte di un Processo
MODA-ML; quindi è possibile affermare che le Attività sono le Binary
Collaboration eseguite dalle Collaboration Activity che fanno parte della Binary
Collaboration che è il Processo.
Infine, gli Attori MODA-ML sono gli Authorized Role del BPSS.
In Figura 4.3.1 illustriamo il sottoinsieme del BPSS relativo ai concetti appena
discussi, inserendo dei commenti al fine di esplicitare le associazioni con MODA-
ML.
Figura 4.3.1 Business Process Specification Schema e MODA-ML
Business Transaction
1
n
0..1 +requesting +responding 0..1
1 n
+documentEnvelope +documentEnvelope
AttivitàMODA-ML
TransazioneMODA-ML
n 1
RequestingBusinessActivity RespondingBusinessActivity
Document Envelope
+transaction +transaction
1 1
+requester +responder
1
CollaborationActivity
BusinessTransactionActivity
BusinessDocumentn 1
Authorized Role
AttoreMODA-ML
DocumentoMODA-ML
BinaryCollaboration
BusinessActivity
ProcessoMODA-ML
58
4.3.2 Rappresentazione degli scenari di business MODA-ML con diagrammi UML
Analizziamo ora come modellare gli scenari di business definiti dalle specifiche
MODA-ML tramite diagrammi UML.
Le scelte effettuate cercano di integrare il bisogno di avere una soluzione conforme
alle specifiche ebXML, quindi compatibile con UMM, con l’esigenza di offrire dei
diagrammi immediatamente comprensibili agli utenti finali.
Volendo utilizzare la soluzione proposta nel paragrafo 4.2.3, dovremmo realizzare i
diagrammi di sequenza relativi alle Binary Collaboration (Attività MODA-ML) in
cui riportare l’insieme delle Business Transaction Activity (Transazione MODA-
ML) e specificare i ruoli di Initialing Role e Responding Role giocati dai partner
(Attori MODA-ML); inoltre, occorrerebbe un diagramma di sequenza per ciascuna
Business Transaction e i diagrammi delle attività relativi alle Business
Choreography per indicare la sequenza di esecuzione delle Business Transaction
Activity.
Questa soluzione, essendo molto dettagliata, rischia di essere dispersiva e non offre,
all’utente non esperto dell’architettura ebXML, una visione immediata degli scenari
di business, contrariamente al nostro obiettivo. Per questi motivi, decidiamo di
tralasciare parte delle informazioni richieste dal BPSS modificando la soluzione
proposta precedentemente come segue.
Utilizziamo i diagrammi di sequenza per la rappresentazione delle Business
Transaction Activity (Transazione MODA-ML) entro le Binary Collaboration
(Attività MODA-ML), ma non indichiamo i ruoli di Initialing Role e Responding
Role giocati dagli attori, poiché possono comunque essere dedotti dalla direzione
delle frecce. In questo modo è possibile specificare nel diagramma di sequenza
anche l’ordine secondo cui vengono eseguite le Business Transaction Activity.
Ad esempio, modelliamo l’attività MODA-ML “Acquisto tessuti” (Figura 4.3.2), già
presa in esame nel paragrafo 4.1.
59
Figura 4.3.2 Attività MODA-ML “Acquisto tessuti” (Binary Collaboration)
Ora, per ogni Business Transaction dovrebbe essere realizzato un diagramma di
sequenza come quello in Figura 4.3.3.
Figura 4.3.3 Transazione MODA-ML “Ordine” (Business Transaction)
Ciò però non ha molto senso poiché, come esaminato in precedenza, in MODA-ML
le Business Transaction non hanno mai un documento di risposta ed il messaggio di
acknoledgment è opzionale.
Quello che è utile fare, invece, è aggiungere l’informazione relativa all’unico
documento scambiato nella Business Transaction eseguita dalla Business
Transaction Activity nel diagramma di sequenza relativo alla Binary Collaboration.
Il diagramma risultante è illustrato in Figura 4.3.4.
Ordine
BD: TEXOrder.xml
Ack
:RequestingActivity
:Responding Activity
<<BTA>>
OrdineBT: Ordine
<<BTA>>
Risposta Ordine
BT: Risposta Ordine
<<BTA>>
Modifica Ordine
BT: Modifica Ordine
<<BTA>>
Avanzamento Ordine
BT: Avanzamento Ordine
AR: Fornitore diTessuti
AR:Confezionista
60
Figura 4.3.4 Attività MODA-ML “Acquisto Tessuti”(Binary Collaboration)
Infine, per favorire l’immediata comprensione del diagramma, sarebbe utile poter
specificare i nomi dell’Attività e del Processo cui ci stiamo riferendo nel diagramma
stesso. Per fare ciò, possiamo utilizzare un altro degli elementi offerti da UML: il
commento. La notazione grafica per il commento è illustrata in Figura 4.3.5.
Figura 4.3.5 Notazione grafica UML per commento
I commenti possono essere inseriti in qualunque punto del diagramma, possono
essere liberi, ciò non fare riferimento ad alcun elemento del diagramma, o associati
ad un elemento; nel secondo caso, il commento è collegato all’elemento cui si
riferisce tramite una linea tratteggiata.
Vediamo, in Figura 4.3.6, il diagramma di sequenza completo dell’Attività
“Acquisto Tessuti”.
AR:FornitorediTessuti
AR:Confezionista
<<BTA>>
Ordine
BD: TEXOrder.xml<<BTA>>
Risposta Ordine
BD: TEXOrdResponse.xml<<BTA>>
Modifica Ordine
BD: TEXOrdChange.xml<<BTA>>
Avanzamento Ordine
BD: TEXOrdStatus.xml
Questo è un commento
61
Figura 4.3.6 Attività MODA-ML “Acquisto Tessuti” (Binary Collaboration)
Volendo rappresentare tutte le Attività che compongono un Processo tramite un
unico diagramma di sequenza, proponiamo una soluzione alternativa a quella
appena presentata.
Per la modellazione delle Business Transaction Activity seguiamo i criteri della
soluzione precedente, quindi riuniamo le Business Transaction Activity di tutte le
Attività del processo in un unico diagramma di sequenza, rispettando l’ordine di
esecuzione delle Attività. Poi, per indicare quali Business Transaction Activity
appartengono ad una determinata Attività associamo un commento (che riporta il
nome dell’Attività) alla prima Business Transaction Activity dell’Attività e
assumiamo che ne fanno parte tutte le Business Transaction Activity seguenti, fino a
che non ce n’è una che indica l’inizio di una nuova Attività (Figura 4.3.7).
AR:Fornitore diTessuti
AR:Confezionista
<<BTA>>
Ordine
BD: TEXOrder.xml<<BTA>>
Risposta Ordine
BD: TEXOrdResponse.xml<<BTA>>
Modifica Ordine
BD: TEXOrdChange.xml<<BTA>>
Avanzamento Ordine
BD: TEXOrdStatus.xml
Processo “Fornitura Tessuti”
Attività “Acquisto Tessuti”
62
Figura 4.3.7 Rappresentazione alternativa di un Processo (Binary Collaboration)rispetto a quella in Figura 4.3.6
4.3.3 Il Dizionario di MODA-ML
Attualmente, le numerose informazioni relative ai processi della filiera e ai
documenti scambiati sono memorizzate su una base di dati MS-Access chiamata
MODA-ML Dictionary (o Dizionario di MODA-ML). Il Dizionario [Diz], quindi, è
la fonte (l’unica) da cui attingere i dati per realizzare i diagrammi di sequenza
relativi ai processi della filiera; lo analizziamo per determinare i dati cui si dispone e
studiare come inserirli nei diagrammi di sequenza.
Il Dizionario mantiene fedelmente la gerarchia “Processi - Attività – Transazioni”
dettata dalle specifiche MODA-ML. Esaminiamo ora in dettaglio le informazioni
relative ai processi, alle attività, agli attori e ai documenti.
Per ogni Processo e per ciascuna Attività sono disponibili le seguenti informazioni:
Processo X
Attore 2Attore 1
<<BTA>>
…
BD: …<<BTA>>
…
BD: …<<BTA>>
…
BD: …<<BTA>>
…
BD: …<<BTA>>
…
BD: …
Attività 1
Attività 2
63
un codice identificativo numerico univoco;
il nome, in italiano e in inglese;
una breve descrizione, in italiano e in inglese.
Per le attività sono specificati l’ordine cronologico d’esecuzione all’interno del
processo cui ciascuna appartiene e la sequenza ordinata delle transazioni che ne
fanno parte; inoltre, per ciascuna transazione, sono indicati il documento scambiato,
l’attore che lo spedisce (sender) e l’attore che lo riceve (receiver).
Relativamente agli Attori si hanno queste informazioni:
un codice identificativo numerico univoco;
il nome, in italiano e in inglese;
una breve descrizione, in italiano e in inglese.
Per i Documenti, invece, sono forniti i seguenti dati:
un codice identificativo numerico univoco;
il nome, in italiano e in inglese;
una breve descrizione , in italiano e in inglese;
lo scopo, in italiano e in inglese;
la data di rilascio.
4.3.4 Mapping tra Dizionario e diagrammi di sequenza
Cerchiamo di capire se e come tutte le informazioni presenti nel Dizionario possono
essere inserite nel modello di diagramma di sequenza presentato nel paragrafo 4.3.2;
non consideriamo le informazioni relative ai documenti poiché per la loro
modellazione sono necessari dei diagrammi di classe la cui realizzazione non è stata
studiata nell’ambito della tesi.
Osserviamo che tutte le informazioni sono sia in italiano che in inglese; ciò
comporta la realizzazione di altrettante versioni dei diagrammi di sequenza.
Usiamo una tabella (Tabella 4.3.1) per evidenziare le informazioni nel Dizionario e
se hanno o no riscontro nel diagramma di sequenza (consideriamo solo i dati in
italiano poiché i dati in inglese sono gestiti allo stesso modo nella realizzazione della
versione inglese dei diagrammi).
64
Dati nel Dizionario Corrispondenza nel diagramma di sequenza
ID processo nessuna
Nome processo commento
Descrizione processo nessuna
ID Attore nessuna
Nome attore AR (Authorized Role)
Descrizione attore nessuna
ID attività nessuna
Nome attività commento
Descrizione attività nessuna
ID transazione nessuna
Nome transazione BTA (Business Transaction Activity)
Nome del documento BD (Business Document)
Tabella 4.3.1 Associazione tra dati del Dizionario e dati del diagramma di sequenza
Come si può vedere, la descrizione attore, la descrizione processo e la descrizione
attività non sono state considerate durante l’analisi degli scenari MODA-ML per la
realizzazione dei diagrammi di sequenza; tuttavia sarebbe molto utile inserire queste
informazioni nei diagrammi poiché espliciterebbero i termini utilizzati nel
diagramma stesso. Questo è possibile aggiungendo un commento associato ad ogni
elemento che ha una descrizione.
Il diagramma di sequenza di Figura 4.3.6, quindi, si arricchisce come mostrato in
Figura 4.3.8.
65
Figura 4.3.8 Attività “Acquisto Tessuti”
I codici identificativi, invece, servono esclusivamente per la gestione interna della
base di dati, quindi non sarebbe di alcuna utilità riportarli nel diagramma di
sequenza.
4.3.6 Esempio: modellazione del processo “Fornitura Tessuti”
Come esempio, modelliamo l’intero processo MODA-ML “Fornitura Tessuti”
(illustrato nel paragrafo 4.1). Costruendo i diagrammi di sequenza per ciascuna
attività come spiegato nei precedenti paragrafi, otteniamo il diagramma in Figura
4.3.9 che modella l’intero processo.
Processo “Fornitura Tessuti”
Fornitura tessuti al Confezionista da parte del Fornitore di tessuti
Attività “Acquisto Tessuti”
Il Confezionista acquista i tessuti dal Fornitore di tessuti
AR:FornitorediTessuti
AR:Confezionista
<<BTA>>
Ordine
BD: TEXOrder.xml<<BTA>>
Risposta Ordine
BD: TEXOrdResponse.xml<<BTA>>
Modifica Ordine
BD: TEXOrdChange.xml<<BTA>>
Avanzamento Ordine
BD: TEXOrdStatus.xml
Produttore di indumenti
Produttore di tessuti
66
Attività “Acquisto Tessuti”
Il Confezionista acquista i tessuti dal Fornitore di tessuti
AR:Fornitore di tessuti
AR:Confezionista
<<BTA>>
Ordine al fornitore di tessuti
BD: TEXOrder.xml<<BTA>>
Risposta Ordine
BD: TEXOrdResponse.xml<<BTA>>
Modifica Ordine
BD: TEXOrdChange.xml<<BTA>>
Avanzamento Ordine
BD: TEXOrdStatus.xml
Produttore di indumenti
Produttore di tessuti
Processo “Fornitura Tessuti”
Fornitura tessuti al Confezionista da parte del Tessitore
Attività “Scelta Tessuti”
Il Confezionista sceglie i tessuti a partire da listini e schede tecniche forniti dal Fornitore di tessuti
AR:Fornitore di Tessuti
AR:Confezionista
<<BTA>>
Listino tessuti
BD: TEXCatalog.xml<<BTA>>
Scheda anagrafica tessuto
BD: TEXCollection.xml <<BTA>>
Previsione collezione tessuti
BD: TEXCollection.xml
Produttore di indumenti
Produttore di tessuti
67
Figura 4.3.9 Processo MODA-ML “Fornitura Tessuti” (Binary Collaboration)
Prima rappresentazione
Adottando la soluzione che prevede la realizzazione di un unico diagramma di
sequenza per processo, otteniamo il diagramma in Figura 4.3.10.
Attività “Spedizione Tessuti”
Il Fornitore di tessuti invia la merce ordinata al Confezionista
AR:Fornitoredi Tessuti
AR:Confezionista
<<BTA>>
Richiesta spedizione tessuto
BD: .TEXDesRequest.xml<<BTA>>
Avviso spedizione tessuto
BD: TEXDesAdvise.xml<<BTA>>
Report qualità pezza
BD: TEXQualityRpt.xml<<BTA>>
Fattura tessitore
BD: .TEXInvoice.xml
Produttore di indumenti
Produttore di tessuti
68
Figura 4.3.10 Processo MODA-ML “Fornitura Tessuti” (Binary Collaboration)Seconda rappresentazione
<<BTA>>
Listino tessuti
BD:TEXCatalog.xml<<BTA>>
Scheda Anagrafica tessuto
BD:TEXSheet.xml<<BTA>>
Previsione Collezione tessuti
BD: TEXCollection.xml<<BTA>>
Ordine al fornitore di tessuti
BD:TEXOrder.xml<<BTA>>
Risposta ordine al fornitore di tessuti
BD: TEXOrdResponse.xml
Processo “Fornitura tessuti”Fornitura tessuti al Confezionista da parte
del Tessitore
Attività “Scelta tessuti”
Scelta dei tessuti a partire ….
<<BTA>>
Modifica ordine al fornitore di tessuti
BD: TEXOrdChange.xml<<BTA>>
Avanzamento ordine
BD: TEXOrdStatus.xml<<BTA>>
Richiesta spedizione tessuto
BD: TEXDesRequest.xml<<BTA>>
Avviso spedizione del tessuto
BD: TEXDesAdvise.xml<<BTA>>
Report Qualità pezza
BD: TEXQualityRPT.xml
<<BTA>>
Fattura tessitore
BD:TEXInvoice.xml
AR:Confezionista
AR:Fornitore di tessuti
Attività “Acquisto tessuti”Acquisto dei tessuti …
Attività “Spedizione
tessuti”Spedizione dei tessuti
…
69
4.4 La creazione dei modelli degli scenari di business di MODA-ML
Nel paragrafo precedente abbiamo analizzato come modellare i processi MODA-
ML, determinando quali diagrammi UML realizzare, i criteri secondo cui costruirli e
come utilizzare i dati del Dizionario. Ora, essendo UML un linguaggio grafico,
stabiliamo quale formato adottare per rappresentare questi diagrammi in un formato
machine-readable (vedi paragrafo 4.1.1) e cerchiamo di spiegare come il linguaggio
UML viene mappato nel formato scelto.
4.4.1 La scelta di XMI
OMG fornisce un formato standard per lo scambio di modelli UML, ossia XMI.
Come analizzato nel paragrafo 3.3, il linguaggio XMI descrive in maniera completa
e diretta qualunque modello UML; inoltre, XMI è definito tramite XML, perciò un
documento XMI può essere processato da applicazioni automatiche.
XMI, quindi, è il linguaggio che risponde perfettamente alle nostre esigenze poiché
ci permette di esprimere i modelli precedentemente definiti senza perdita di
informazione o di coerenza e, allo stesso tempo, è machine-readable.
4.4.2 Mapping tra diagrammi di sequenza e XMI
Come spiegato nel paragrafo 3.3, per rappresentare un diagramma UML in
linguaggio XMI occorre utilizzare gli elementi definiti nel DTD UML di XMI; il
passo successivo è individuare quali sono gli elementi relativi ai diagrammi di
sequenza e le relazioni esistenti tra essi e capire come utilizzarli per rappresentare i
nostri diagrammi.
Sapendo che:
a) i diagrammi di sequenza che sviluppiamo sono istanze di un modello, a cui
assegniamo il nome di “Modello MODA-ML”;
b) il Modello MODA-ML è istanza del meta-modello UML;
70
c) gli elementi del meta-modello UML hanno una corrispondenza biunivoca
con gli elementi del DTD UML di XMI;
possiamo affermare che se individuiamo gli elementi del meta-modello UML
istanziati dal Modello MODA-ML, possiamo identificare direttamente quali
elementi del DTD UML utilizzare e come utilizzarli per rappresentare i diagrammi
di sequenza (Figura 4.4.1).
Figura 4.4.1 Relazione tra diagrammi di sequenza e DTD UML di XMI
Spieghiamo le relazioni illustrate in Figura 4.4.1.
- mapping 1: dal modello MODA-ML al meta-modello UML:
il modello MODA-ML che descrive i processi di collaborazione è illustrato in
Figura 4.4.2.
Figura 4.4.2 Modello MODA-ML
La sezione del meta-modello UML che definisce e descrive gli elementi relativi
Processo Attività Transazione
Attori
1..*
2
1..* 1..* 1..* 1..*
Documento
1..*
1
Modello Moda-ML
Meta-Modello UML
DTD UMLdi
XMIMAPPINGMAPPING
Diagrammi di sequenza dei
processi Moda-ML
1 2
3
71
ai diagrammi di sequenza è il package Collaboration. Le relazioni di istanziazione
tra il package Collaboration e il modello di MODA-ML (Figura 4.4.2) sono
mostrate, in maniera estremamente semplificata, in Figura 4.4.3.
Figura 4.4.3 Relazioni tra il package Collaboration di UML e il modello MODA-
ML
- mapping 2: dal meta-modello UML al DTD UML di XMI:
ogni elemento del meta-modello UML è descritto da un elemento o un attributo
del DTD UML di XMI. In Figura 4.4.4 ne illustriamo un esempio.
(dal Package Collaboration) (dal DTD UML di XMI)
Figura 4.4.4 Corrispondenze tra Meta-modello UML e DTD UML di XMI
- mapping 3: dal Modello MODA-ML al DTD UML di XMI:
a questo punto, sapendo quali sono gli elementi del meta-modello UML che
descrivono il Modello MODA-ML (Figura 4.4.3) e gli elementi del DTD UML
Collaboration CollaborationInstanceSet
MessageInstance
Processo Attività TransazioneAttori
<<instanceOf>> <<instanceOf>> <<instanceOf>> <<instanceOf>>
Message
name: String + predecessor
*
<!ELEMENT UML:Message
(…|UML:Message.predecessor |…) >
<!ATTLIST UML:Message
name CDATA #IMPLIED>
<!ELEMENT UML:Message.predecessor
(UML:Message)* >
Mapping
72
ad essi corrispondenti, possiamo stabilire le corrispondenze tra il modello
MODA-ML e gli elementi del DTD UML (Tabella 4.4.1).
Entità MODA-ML Elemento XMI
Processo Collaboration
Attività CollaborationInstanceSet
Attore Object
Transazione Message
Documento XML TaggedValue
Tabella 4.4.1 Corrispondenza tra modello MODA-ML e DTD UML
4.4.3 Esempio
Consideriamo, ad esempio, due scambi di documenti dell’Attività “Acquisto tessuti”
del Processo MODA-ML “Fornitura tessuti” (Figura 4.4.5) e analizziamo il
corrispondente file xmi.
Figura 4.4.5 Attività “Acquisto tessuti” (ridotta a due Transazioni)
Il documento XMI per questo diagramma di sequenza è illustrato in Figura 4.4.6.
<XMI xmi.version="1.2" xmlns:UML="org.omg.xmi.namespace.UML">
Fornitore di Tessuti
Confezionista
<<BTA>>
Ordine
BD: TEXOrder.xml
<<BTA>>
Risposta Ordine
BD: TEXOrdResponse.xml
73
…<XMI.content>
…<UML:Model xmi.id="model" name="model" isSpecification="false" isRoot="false"
isLeaf="false" isAbstract="false">…<UML:Collaboration xmi.id="coll_11" name="Fornitura tessuti">
…<UML:CollaborationInstanceSet xmi.id="cis_12" name="Acquisto tessuti">
<UML:ModelElement.comment><UML:Comment xmi.idref="comm_12"/>
</UML:ModelElement.comment><UML:CollaborationInstanceSet.interactionInstanceSet>
<UML:InteractionInstanceSet xmi.id="iis_12"/></UML:CollaborationInstanceSet.interactionInstanceSet><UML:CollaborationInstanceSet.collaboration>
<UML:Collaboration xmi.idref="coll_11"/></UML:CollaborationInstanceSet.collaboration><UML:CollaborationInstanceSet.participatingInstance>
<UML:Object xmi.idref="obj_1"/><UML:Object xmi.idref="obj_2"/>
</UML:CollaborationInstanceSet.participatingInstance><UML:CollaborationInstanceSet.participatingLink>
<UML:Link xmi.idref="link_14"/><UML:Link xmi.idref="link_15"/>
</UML:CollaborationInstanceSet.participatingLink></UML:CollaborationInstanceSet>
<UML:Object xmi.id="obj_1" name="Fornitore di tessuti"> …
<UML:Instance.linkEnd><UML:LinkEnd xmi.idref="linkend_r_14"/><UML:LinkEnd xmi.idref="linkend_s_15"/>
</UML:Instance.linkEnd><UML:Instance.ownedLink>
<UML:Link xmi.id="link_15"> …
</UML:Link></UML:Instance.ownedLink>
</UML:Object>
<UML:Object xmi.id="obj_2" name="Confezionista"><UML:Instance.linkEnd>
<UML:LinkEnd xmi.idref="linkend_s_14"/><UML:LinkEnd xmi.idref="linkend_r_15"/>
</UML:Instance.linkEnd><UML:Instance.ownedLink>
<UML:Link xmi.id="link_14">
Processo
Attore
Attore
Attività
74
…</UML:Link>
</UML:Instance.ownedLink></UML:Object>
<UML:Message xmi.id="mess _14" name="Ordine al fornitore di tessuti"><UML:Message.conformingStimulus>
<UML:Stimulus xmi.idref="stim_14"/></UML:Message.conformingStimulus>
</UML:Message><UML:Stimulus xmi.id="stim_14" name="stimulus_14">
<UML:ModelElement.taggedValue><UML:TaggedValue xmi.id="tv_14">
<UML:TaggedValue.dataValue>TEXOrder.xml</UML:TaggedValue.dataValue>
<UML:TaggedValue.type><UML:TagDefinition xmi.idref="td_20"/>
</UML:TaggedValue.type></UML:TaggedValue>
</UML:ModelElement.taggedValue><UML:Stimulus.sender>
<UML:Object xmi.idref="obj_2"/></UML:Stimulus.sender><UML:Stimulus.receiver>
<UML:Object xmi.idref="obj_1"/></UML:Stimulus.receiver><UML:Stimulus.communicationLink>
<UML:Link xmi.idref="link_14"/></UML:Stimulus.communicationLink>
</UML:Stimulus>
<UML:Message xmi.id="mess_15" name="Risposta ordine del fornitore di tessuti">
<UML:Message.conformingStimulus><UML:Stimulus xmi.idref="stim_15"/>
</UML:Message.conformingStimulus></UML:Message><UML:Stimulus xmi.id="stim_15" name="stimulus_15">
<UML:ModelElement.taggedValue><UML:TaggedValue xmi.id="tv_15">
<UML:TaggedValue.dataValue>TEXOrdResponse.xml</UML:TaggedValue.dataValue><UML:TaggedValue.type>
<UML:TagDefinition xmi.idref="td_20"/></UML:TaggedValue.type>
</UML:TaggedValue></UML:ModelElement.taggedValue><UML:Stimulus.sender>
<UML:Object xmi.idref="obj_1"/></UML:Stimulus.sender><UML:Stimulus.receiver>
<UML:Object xmi.idref="obj_2"/></UML:Stimulus.receiver><UML:Stimulus.communicationLink>
<UML:Link xmi.idref="link_15"/></UML:Stimulus.communicationLink>
Transazione
Transazione
Documento XML
Documento XML
75
</UML:Stimulus>
</UML:Collaboration>
<UML:Comment xmi.id="comm_cis_12" visibility="public" isSpecification="false" body="Attività di acquisto tessuti">
<UML:Comment.annotatedElement><UML:CollaborationInstanceSet xmi.idref="cis_12"/>
</UML:Comment.annotatedElement></UML:Comment>
<UML:TagDefinition xmi.id="td_20" name="business document"> …
</UML:TagDefinition> …
</UML:Model></XMI.content>
</XMI>
Figura 4.4.6 Attività “Acquisto tessuti” ridotta
In Figura 4.4.6 non sono riportati tutti i nodi necessari per descrivere il diagramma
in Figura 4.4.5, in quanto lo scopo è fornire semplicemente un’idea della struttura
che i documenti XMI avranno. Le frecce in Figura 4.4.6 evidenziano i dati MODA-
ML riportati dagli elementi.
4.4.4 Strumenti software
In commercio esistono diversi CASE tool che supportano la realizzazione di
diagrammi UML offrendo la possibilità di importare ed esportare le informazioni
relative ai diagrammi in formato XMI. Esempi sono Rational Rose [RR], prodotto
dalla Rational Software Corporation, e Poseidon for UML [Pos], sviluppato da
Gentleware.
Questi strumenti consentono di realizzare i documenti XMI definiti
precedentemente, ma non soddisfano completamente le nostre esigenze per due
motivi:
1. non è possibile importare automaticamente le informazioni dal Dizionario;
2. non riescono a visualizzare i documenti realizzati poiché i documenti XMI
standard non prevedono le estensioni necessarie per la visualizzazione (vedi
Descrizione Attività
76
paragrafo 3.3.2).
In Figura 4.4.7, Figura 4.4.8 e Figura 4.4.9 riportiamo il risultato
dell’importazione del file XMI relativo al processo “Fornitura tessuti” in
Poseidon for UML. Come si può vedere il tool riesce ad individuare tutti gli
elementi riportati nel documento ma la finestra di visualizzazione del diagramma
(quella in alto a destra) è vuota.
Figura 4.4.7 Attori del processo “Fornitura tessuti” e messaggi inviati dal
Confezionista
77
Figura 4.4.8 Dettagli di un messaggio inviato dal Confezionista
Figura 4.4.9 Tagged value associato al messaggio in Figura 4.4.8
Nel prossimo capitolo quindi saranno discusse la progettazione e l’implementazione
dell’applicazione software (MODA-MICS) capace di acquisire automaticamente i
dati dal Dizionario, di generare i diagrammi di sequenza in formato XMI e di
gestirne la visualizzazione.
78
79
5 MODA-MICS: Progettazione e
Implementazione
In questo capitolo sono discusse la progettazione e l’implementazione
dell’applicazione software (MODA-MICS: MODA-ML Modeling Interface to
CASE Systems) che produce e visualizza i diagrammi di sequenza dei processi di
business MODA-ML in formato XMI. In particolare sono evidenziati e motivati i
requisiti che l’applicazione deve avere e le scelte implementative che hanno
comportato.
5.1 Analisi dei requisiti
Definiamo i requisiti di architettura e i requisiti funzionali che le esigenze del
progetto MODA-ML richiedono all’applicazione.
5.1.1 Requisiti architetturali
L’applicazione da realizzare è un’applicazione Web che ha due obiettivi principali
(Figura 5.1.1):
produrre i diagrammi di sequenza in formato XMI;
visualizzare i documenti XMI.
80
Figura 5.1.1 Architettura obiettivo
Per la generazione dei file XMI occorrono, come input, i dati conservati nel
Dizionario, quindi è necessario realizzare un’applicazione (A in Figura 5.1.1) di
supporto per il reperimento di queste informazioni. Facciamo notare che anche se il
Dizionario MODA-ML è, attualmente, implementato su data base MS-Access, in
futuro, questo supporto potrebbe essere sostituito o subire modifiche
all’organizzazione interna dei dati. Per questo motivo, ci è richiesto di progettare il
software mantenendo, dove possibile, la totale indipendenza dalle modalità di
implementazione del Dizionario.
Per la visualizzazione dei file XMI (vedi paragrafo 3.3) abbiamo due possibilità:
utilizzare il meccanismo di estensione supportato da XMI, oppure applicare ai
documenti un foglio di stile XSLT. Considerato che la principale esigenza del
progetto MODA-ML è visualizzare i diagrammi di sequenza su browser, decidiamo
di adottare un foglio di stile [XSLT]. I file XMI, quindi, saranno processati da un
motore XSL (B in Figura 5.1.1) e trasformati in un formato adatto ad essere
visualizzato su Web. Questo consente di generalizzare il foglio di stile non
limitandone l’utilizzo ai file XMI generati con le informazioni nel Dizionario.
Il formato di destinazione scelto è SVG (Scalable Vector Graphic) (Figura 5.1.1).
Dizionario
MODA-ML
INPUT OUTPUT
XMI
INPUT
OUTPUT
SVG
A
B
81
SVG [SVG] è un linguaggio standard di grafica vettoriale bidimensionale basato su
XML; è stato sviluppato dal consorzio W3C ed è giunto, il 15 gennaio 2003, alla
versione 1.1. Le funzionalità che il linguaggio offre per manipolare gli elementi
visuali stanno aprendo nuovi orizzonti nella progettazione grafica per il Web, tanto
che qualcuno ipotizza che SVG potrebbe diventare il linguaggio universale per la
realizzazione di pagine Web in sostituzione dei linguaggi esistenti, in particolare
HTML. Alla luce di ciò e considerato che SVG è comunque supportato, tramite
appositi plug-in, dai browser web più utilizzati (ad es: Internet Explorer, Netscape,
Mozilla, Opera), riteniamo che sia il linguaggio più adatto per il nostro utilizzo.
In sostanza, quindi, l’applicazione produrrà due versioni dei modelli dei processi di
business di MODA-ML:
- versione XMI, che è machine-readable e UML-compliant;
- versione SVG, per la diretta visualizzazione su browser e l’inserimento nella
documentazione già esistente.
5.1.2 Requisiti funzionali
Richiamiamo alcuni aspetti, esaminati precedentemente, ed esaminiamo i requisiti
che impongono alla progettazione del sistema.
1. Esistono più versioni del Dizionario MODA-ML (2002-1, 2002-2, 2003-1, 2003-
draft).
Ciò implica che per uno stesso Processo ci saranno più file XMI e più file SVG,
cioè tanti quante sono le versioni del Dizionario; conseguentemente, deve essere
realizzato un meccanismo di naming per la gestione delle varie versioni. Inoltre,
l’applicazione deve richiedere all’utente di specificare la versione del Dizionario
da utilizzare per generare i file XMI e i corrispondenti SVG.
2. Il Dizionario MODA-ML supporta sia la lingua italiana sia la lingua inglese.
Questo comporta la generazione di due versioni, una per lingua, di ogni
diagramma di sequenza.
3. Sono state definite due rappresentazioni dei modelli per i processi di MODA-
ML: una utilizza un unico diagramma di sequenza per ogni Processo riunendovi
in maniera sequenziale le Transazioni di tutte le Attività del Processo; l’altra
82
rappresenta le Attività singolarmente, usando un diagramma di sequenza per
ciascuna di esse.
Ciò, ovviamente, richiede al sistema la generazione di entrambe le versioni dei
modelli.
In sostanza, quindi, per ogni Processo e versione del Dizionario, ci saranno
quattro file XMI e quattro file SVG (Figura 5.1.2).
Figura 5.1.2 File generati per un processo presente in due versioni del Dizionario
4. L’applicazione fornisce due servizi principali: la creazione e la visualizzazione
dei diagrammi di sequenza.
Le funzioni di generazione e visualizzazione dei diagrammi di sequenza devono
Dizionario MODA-ML versione 2002-2
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Proc.
Lingua: inglese
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Proc. Lingua: italiano
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: italiano
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: inglese
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Proc.
Lingua: inglese
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Proc. Lingua: italiano
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: italiano
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: inglese
Dizionario MODA-ML versione 2003-1
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Proc.
Lingua: inglese
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Proc. Lingua: italiano
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: italiano
Processo1.xmi
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: inglese
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Proc.
Lingua: inglese
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Proc. Lingua: italiano
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: italiano
Processo1.svg
Rappresentazione: 1 diagr. di sequ. per Att.
Lingua: inglese
83
essere gestite differentemente. Il servizio di visualizzazione deve essere
consentito a tutti gli utenti del progetto MODA-ML (staff e generici). La
funzione di creazione dei file, invece, deve essere accessibile solo allo staff del
progetto. Ciò richiede la realizzazione di un meccanismo di autenticazione degli
utenti che consente di controllare l’accesso ai servizi.
5. Potrebbero essere effettuate modifiche solo ad alcuni dei Processi presenti nel
Dizionario.
Ciò spinge ad ottimizzare la funzione di generazione dei diagrammi richiedendo
all’utente di specificare i Processi per i quali effettuare la generazione. In questo
modo, in caso di variazioni a parti del Dizionario, si evita di rigenerare i
diagrammi su cui non si ripercuotono le modifiche apportate.
5.2 Architettura
Discutiamo circa l’architettura software dell’applicazione, il meccanismo da
utilizzare per la visualizzazione dei diagrammi XMI, l’organizzazione da dare ai file
generati, l’ambiente di sviluppo dell’applicazione e come effettuare la connessione
al Dizionario MODA-ML.
5.2.1 Architettura software
Al fine di soddisfare i requisiti esposti nel precedente capitolo, cerchiamo di dare
alla nostra applicazione un’architettura quanto più modulare possibile. Per questo
motivo, organizziamo il software in quattro moduli (Figura 5.2.1):
“Gestione Dizionario”: si occupa di reperire i dati del Dizionario e di
restituirli in una forma indipendente dalla loro organizzazione nel database
MS-Access;
“Generatore XMI”: sfruttando le funzioni del modulo “Gestione Dizionario”,
acquisisce i dati relativi alle Attività, agli Attori, alle Transazioni e ai
Documenti di un Processo specificato e li usa per creare il diagramma di
sequenza in formato XMI;
84
“Generatore SVG”: applica la trasformazione XSLT ad un dato diagramma
di sequenza in formato XMI; il risultato è il diagramma di sequenza in
formato SVG;
“Interfaccia utente”: gestisce le interazioni con l’utente, in particolare: il
servizio di autenticazione, la scelta della versione del Dizionario da
utilizzare, la selezione dei processi per i quali generare i diagrammi, la scelta
della lingua, la visualizzazione dei diagrammi.
Figura 5.2.1 Architettura software
In questo modo, il modulo “Gestione Dizionario” sarà sviluppato presupponendo
l’utilizzo dell’attuale database MS-Access, ma i restanti gruppi di funzioni potranno
essere realizzati ignorando completamente le modalità di memorizzazione e
organizzazione dei dati necessari per la creazione dei diagrammi di sequenza. Ne
derivano due vantaggi:
anche se il data base MS-Access dovesse essere strutturalmente modificato o
sostituito da un altro supporto, sarà possibile riutilizzare l’applicazione
limitandosi a sostituire le funzioni “Gestione Dizionario”;
XMI
Gestione DizionarioFunzioni per il reperimento dati nel Dizionario
Generatore XMIFunzioni per la generazione file XMI
Generatore SVGProcedura per la generazione
file SVG
Interfaccia Utente
DizionarioMODA-
ML
SVGStaff Utenti generici
Utentiregistrati
File di configurazione
85
il modulo “Generatore XMI” potrà essere sfruttato, oltre che per la
modellazione dei processi di business MODA-ML, per la modellazione dei
processi di qualsiasi altro framework collaborativo;
il modulo “Generatore SVG” potrà essere adoperato per la generazione dei
diagrammi di sequenza in formato SVG utilizzando come input qualunque
diagramma di sequenza in formato XMI, non solo quelli generati da questa
applicazione.
5.2.2 Meccanismo XSLT
Possiamo scegliere di effettuare la trasformazione XSLT in due modi:
- in maniera dinamica: ogni volta che dall’interfaccia si inoltra una richiesta di
visualizzazione di un diagramma occorre caricare il file XMI, il foglio di
stile, effettuare la trasformazione e ritornare il risultato al browser
richiedente;
- in maniera statica: si salva una tantum il risultato della trasformazione XSLT
in un file destinazione con estensione .svg; in questo modo, quando
l’applicazione riceve una richiesta, la risposta è già pronta.
Ovviamente, la prima soluzione risulta essere molto più elegante della seconda,
tuttavia, adottandola si rischierebbe di sovraccaricare di lavoro il server sul quale
l’applicazione sarà eseguita; per questo motivo, decidiamo di adottare la modalità
statica.
5.2.3 Repository dei file e regole di naming
Tutte le versioni dei file XMI ed SVG di tutti i Processi di MODA-ML sono
organizzate in un Repository di file.
Lo scopo del Repository è fornire, in ogni momento, allo staff e agli utenti finali del
progetto MODA-ML, la visione completa dei modelli di tutti in Processi di MODA-
ML e la possibilità di scaricare gratuitamente, o visualizzare via Web, i file
desiderati.
Coerentemente alla struttura adottata per la gestione di altra documentazione del
86
progetto MODA-ML, il Repository è organizzato in cartelle, una per ciascuna
versione del Dizionario. Ogni cartella raccoglie tutte le versioni dei file XMI e SVG
generati utilizzando la corrispondente versione del Dizionario. Il nome assegnato ad
una cartella è uguale al nome del file della relativa versione del Dizionario (ad
esempio: “moda-ml-diz-2001-2”).
I nomi dei file, invece, sono così composti:
versioneDizionario_nomeprocesso_versionemodello.estensione
La stringa “nomeprocesso” è ottenuta modificando il nome del Processo cui il file si
riferisce nel seguente modo:
- si eliminano gli spazi bianchi;
- si applicano opportune trasformazioni agli eventuali caratteri speciali.
La stringa “versionemodello” è assegnata in base alla versione del modello adottata:
- 1sd: indica la versione con un unico diagramma di sequenza che raccoglie le
Transazioni di tutte le Attività del Processo;
- Nsd: indica la versione con un diagramma di sequenza per ogni Attività del
Processo.
Ad esempio, i file relativi al Processo “Fornitura Tessuti” generati usando la
versione 2003-1 del Dizionario sono:
- 2003-1_FornituraTessuti_1sd.xmi;
- 2003-1_FornituraTessuti_Nsd.xmi;
- 2003-1_FornituraTessuti_1sd.svg;
- 2003-1_FornituraTessuti_Nsd.svg.
5.2.4 Ambiente di sviluppo
Il generatore di diagrammi di sequenza è stato sviluppato su piattaforma Microsoft
come applicazione ASP per il Web server IIS.
La scelta di realizzare un’applicazione ASP piuttosto che implementare un
programma tradizionale, cioè compilato e direttamente eseguibile, è stata dettata
dalla necessità di fornire un servizio distribuito utilizzando una sorgente dati, il
Dizionario di MODA-ML, localizzata su un server centralizzato.
Occorre un servizio distribuito poiché lo staff del progetto MODA-ML che si
87
occuperà di generare i diagrammi di sequenza ogni qualvolta sarà necessario, è
organizzato in tante unità distribuite su tutto il nord Italia.
Il linguaggio di scripting scelto, sia per la sua semplicità che per coerenza con altre
applicazioni sviluppate nell’ambito del progetto MODA-ML, è VBScript.
5.2.5 Connessione al Dizionario di MODA-ML
Il collegamento tra il Dizionario di MODA-ML e il generatore dei diagrammi di
sequenza avviene per mezzo dell’interfaccia ODBC (Open Database Connectivity)
messa a disposizione dal sistema operativo Microsoft Window. Per interrogare il database non abbiamo utilizzato pre-query definite nello stesso
database ma, di volta in volta, abbiamo specificato la query SQL più opportuna
all’interno del modulo “Gestione Dizionario”.
5.3 Interfaccia utente
L’interfaccia utente si suddivide in due parti:
- Staff: interfaccia verso i generatori di diagrammi XMI ed SVG;
- Utenti: interfaccia per scaricare e visualizzare i file XMI ed SVG.
L’“Interfaccia Staff” è stata progetta con il preciso obiettivo di fornire allo staff
MODA-ML un servizio quanto più efficiente possibile. Grazie ad essa, infatti, è
possibile selezionare la versione del Dizionario da utilizzare e i processi per i quali
generare diagrammi; in questo modo, in caso di modifiche solo ad alcuni processi
nel Dizionario, è possibile evitare di rigenerare tutti i diagrammi.
Ovviamente, essendo l’“Interfaccia Staff” collegata ai generatori di diagrammi può
accedervi solo lo staff del progetto.
L’“Interfaccia Utenti”, invece, è stata realizzata per consentire, al team e agli utenti
generici del progetto MODA-ML, l’accesso al repository dei file offrendo sia la
possibilità di visualizzarli su browser che di scaricarli gratuitamente.
5.3.1 Interfaccia Staff: scelta della lingua e della versione del Dizionario
L’utente può accedere al Generatore di diagrammi di sequenza attraverso la pagina
88
web illustrata in Figura 5.3.1.
Figura 5.3.1 Pagina di accesso al Generatore di diagrammi di sequenza
Le bandierine permettono di scegliere la lingua, mentre il menù a tendina consente
di selezionare la versione del Dizionario (Figura 5.3.2); chiaramente, da questo
momento in poi, i messaggi per l’utente saranno nella lingua corrispondente alla
bandierina scelta.
Figura 5.3.2 Scelta versione Dizionario (versione della pagina in lingua italiana)
L’elenco delle versioni del Dizionario viene creato dinamicamente (Figura 5.3.3): al
momento della richiesta, l’applicazione cerca automaticamente le versioni del
Dizionario presenti in una directory specificata in un file di configurazione e
89
fornisce all’utente i nomi dei file trovati.
Function find_file(directory)
'directory: nome della directory in cui effettuare la ricerca
Set fso = CreateObject("Scripting.FileSystemObject")
Set directory = fso.GetFolder(directory)
Set fc = directory.Files
Dim Array()
Dim i
i = 0
num = directory.Files.Count - 1
ReDim Array(num)
For Each file in fc
'per i file .mdb, prendo solo il nome base
Array(i) = Replace(file.name,".mdb","")
i = i + 1
Next
find_file = Array
End Function
Figura 5.3.3 Funzione per la ricerca delle versioni del Dizionario
5.3.2 Interfaccia Staff: scelta dei Processi
Una volta ricevuta indicazione sulla versione del Dizionario da utilizzare,
l’applicazione, sfruttando le funzioni del modulo “Gestione Dizionario”, fornisce
all’utente la lista dei Processi presenti nel Dizionario (Figura 5.3.4).
90
Figura 5.3.4 Scelta dei Processi
Dopo che l’utente ha selezionato i Processi, viene avviata la procedura di creazione
dei relativi file XMI ed SVG.
5.3.3 Interfaccia Staff: stato di avanzamento della procedura di generazione
Man mano che i file XMI ed i corrispondenti SVG vengono generati, l’applicazione
fornisce, per ciascuno di essi, le seguenti informazioni (Figura 5.3.5):
il nome del file;
il Processo cui si riferisce il file;
Attività, Transazioni e Attori che compongono il Processo;
esito, positivo o negativo, della procedura di generazione.
91
Figura 5.3.5 Stato di avanzamento della procedura di generazione
5.3.4 Interfaccia Utenti: visualizzazione dei diagrammi di sequenza
L’utente può visualizzare e scaricare i diagrammi di sequenza, sia in formato XMI
che in formato SVG, tramite la pagina web in Figura 5.3.6.
92
Figura 5.3.6 Stato di avanzamento della procedura di generazione
L’elenco dei file disponibili, raggruppato per versione del Dizionario, è creato
dinamicamente al momento della richiesta.
5.4 Implementazione
Descriviamo come è stata implementata l’architettura presentata nel paragrafo 5.3.
5.4.1 Implementazione funzioni “Gestione Dizionario”
Il modulo “Gestione Dizionario” (file gest_diz.asp) implementa tutte le funzioni
necessarie per accedere al Dizionario MODA-ML e reperire i dati relativi ai
Processi, alle Attività, alle Transazioni, ai Documenti e agli Attori.
Le funzioni implementate sono le seguenti:
93
- Connessione: gestisce la connessione ODBC al database;
- Find_Proc1: restituisce l’elenco dei nomi di tutti Processi presenti nel
Dizionario.
- Find_Proc2: trova i nomi e le relative descrizioni, di tutti Processi presenti nel
Dizionario;
- Find_Att: restituisce la lista dei nomi, e le corrispondenti descrizioni, di tutte
le Attività che fanno parte del Processo indicato dal parametro
passato;
- Find_Doc: restituisce l’elenco dei nomi, nella lingua indicata dal parametro
passato e i rispettivi mittente e destinatario di tutte le Transazione
che fanno parte dell’Attività indicata dal parametro passato;
- Find_NameDoc: fornisce il nome del documento XML scambiato nella
Transazione indicata dal parametro passato;
- Find_Actor: individua i nomi degli Attori che partecipano all’Attività indicata
dal parametro passato.
Tutte le funzioni, ad eccezione di Connessione e Find_NameDoc, hanno un
parametro che specifica lingua in cui devono essere restituiti i nomi e le descrizioni.
Come esempio, riportiamo la funzione Find_Att (Figura 5.4.2).
Function Find_Att(pr,cnn2, lingua)
'Cerca le attività facenti parte del processo con identificativo pr
'cnn2: connessione al db, già aperta
'pr: identificativo processo
'lingua: italiana o inglese
Dim SQLa
If (lingua = "it") Then
SQLa="SELECT ID, Attivita, Descrizione "
Else
SQLa="SELECT ID, Activity, Description "
End If
SQLa=SQLa & ", R.Posizione "
SQLa=SQLa & "FROM ATTIVITA A, REL_ProAtt R WHERE A.ID = R.Attivita And R.Processo=" & pr
SQLa=SQLa & " ORDER BY R.Posizione"
94
Set rs2 = Server.CreateObject("ADODB.Recordset")
rs2.ActiveConnection = cnn2
rs2.Open SQLa
Dim MyArray
MyArray = rs2.GetRows()
Set rs2 = Nothing
Find_Att = MyArray
End Function
Figura 5.4.1 Funzione Find_Att
5.4.2 “Generatore XMI”: implementazione delle funzioni principali
Il modulo “Generatore XMI” (generatore_xmi.asp) gestisce la creazione del
diagramma di sequenza, in formato XMI, di un processo specificato. Essendo
necessari i dati del Dizionario per la realizzazione del diagramma, il modulo sfrutta
le funzioni del gruppo “Gestione Dizionario”.
I passi essenziali dell’algoritmo implementato per la generazione di un diagramma
di sequenza sono illustrati in Figura 5.4.2.
95
Figura 5.4.2 Algoritmo per la generazione di un file XMI
no
sì
sì
Inserisci Nodi del Processo
Inserisci Nodi delle Transazioni e dei Documenti
Crea DOM
Inserisci Nodi Header XMI
no
no
Ci sono altre Transazioni nell’Attività?
sìCi sono altri Attori che
fanno parte dell’Attività?
Inserisci Nodi dell’Attore
Inserisci Nodi dell’Attività
FINE
Genera XMI
Ci sono altre Attività che fanno parte del Processo?
INIZIO
96
Per la creazione del documento XMI ci siamo serviti dell’oggetto DOM (Document
Object Model) (Figura 5.4.3). I primi nodi ad essere inseriti nell’albero DOM sono
quelli relativi all’header del documento XMI (header.inc.asp); a seguire, sono
aggiunti i nodi contenenti i dati del Processo (processo.inc.asp) (Figura 5.4.4), delle
Attività (attivita.inc.asp), degli Attori (attori.inc.asp), delle Transazioni e dei
Documenti (messaggi.inc.asp). Ovviamente, prima di poter effettuare ciascuno di
questi inserimenti, è eseguita un’opportuna funzione del modulo “Gestione
Dizionario” per il reperimento delle informazioni necessarie. Dopo aver inserito tutti
i nodi nell’albero DOM viene creato il relativo file XMI.
Set xmiDoc=Server.CreateObject("Msxml2.DOMDocument.4.0")
xmiDoc.setProperty "SelectionLanguage", "XPath"
xmiDoc.setProperty"SelectionNamespaces","xmlns:UML=""org.omg.xmi.namespace.UML"""
Figura 5.4.3 Creazione oggetto DOM
Set nuovo_nodo = xmiDoc.createElement("UML:Collaboration")
padre.AppendChild(nuovo_nodo)
Call AssegnaAttributo(xmiD, nuovo_nodo, "xmi.id", id)
Call AssegnaAttributo(xmiD, nuovo_nodo, "name", nome_processo)
Call AssegnaAttributo(xmiD, nuovo_nodo, "isSpecification", "false")
Call AssegnaAttributo(xmiD, nuovo_nodo, "isRoot", "false")
Call AssegnaAttributo(xmiD, nuovo_nodo, "isLeaf", "false")
Call AssegnaAttributo(xmiD, nuovo_nodo, "isAbstract", "false")
Figura 5.4.4 Inserimento nodi Processo
5.4.3 “Generatore XMI”: il problema degli attributi ID e IDREF
I documenti XMI che rappresentano i diagrammi di sequenza sono caratterizzati da
un elevato numero di elementi che fanno riferimento gli uni agli altri tramite gli
attributi “ID e IDREF”. Per questo motivo, sono stati necessari lo studio e
97
l’implementazione di un meccanismo capace di gestire efficacemente la creazione e
l’assegnazione di questi attributi.
Il primo problema che ci siamo posti è stato come memorizzare il valore di un certo
attributo ID per poi poterlo riutilizzare negli opportuni IDREF.
Basandoci sulla considerazione che ogni elemento di un documento XMI concorre a
rappresentare nel diagramma di sequenza un’informazione del Dizionario, abbiamo
deciso di mantenere i valori degli attributi ID insieme ai dati del Dizionario.
Ad esempio, consideriamo i dati degli Attori del Processo “Fornitura tessuti”
acquisite sfruttando le funzioni del modulo “Gestione Dizionario”; immediatamente
dopo averli ottenuti, assegniamo a ciascuna istanza un identificatore univoco (Figura
5.4.5).
Nome Attore Descrizione ID
Fornitore di tessuti … xxx
Confezionista … yyyy
Figura 5.4.5 Mantenimento dell’Attributo ID di ciascun Attore
In questo modo, ogni volta che nel documento XMI l’attributo IDREF di un certo
elemento deve far riferimento ad un determinato Attore, sappiamo esattamente quale
valore utilizzare.
Ad esempio, nella descrizione di ciascuna Attività (nodo CollaborationInstanceSet)
occorre far riferimento agli Attori (Object) che vi prendono parte (Figura 5.4.6);
ricordiamo che gli Attori (Object) sono definiti altrove nel documento.
<UML:CollaborationInstanceSet xmi.id="aaa" name="Scelta tessuti">…<UML:CollaborationInstanceSet.participatingInstance>
<UML:Object xmi.idref="xxx"/><UML:Object xmi.idref="yyy"/>
</UML:CollaborationInstanceSet.participatingInstance>...
</UML:CollaborationInstanceSet><UML:CollaborationInstanceSet xmi.id="bbb" name="Acquisto tessuti">
…<UML:CollaborationInstanceSet.participatingInstance>
98
<UML:Object xmi.idref="xxx"/><UML:Object xmi.idref="yyy"/>
</UML:CollaborationInstanceSet.participatingInstance>...
</UML:CollaborationInstanceSet>
<UML:Object xmi.id="xxx" name="Fornitore di tessuti">…
</UML:Object>
<UML:Object xmi.id="yyy" name="Confezionista">…
</UML:Object>
Figura 5.4.6 Esempio di utilizzo Attributi ID e IDREF
Quindi, per assegnare agli attributi IDREF dei nodi Object figli del nodo
CollaborationInstanceSet il valore esatto, basta assegnare il valore ID associato
all’Attore cui ciascun nodo si riferisce.
Il secondo problema che si è presentato è stato decidere quali valori assegnare a
questi attributi. Sapendo che il valore dell’attributo ID deve essere univoco
all’interno del documento, abbiamo ritenuto opportuno usare valori numerici
generati tramite un contatore che ha valore iniziale zero ed è incrementato di uno
dopo ogni suo utilizzo.
Considerando, ad esempio, gli Attori e l’Attività dell’esempio in Figura 5.4.6
avremo (Figura 5.4.7 e Figura 5.4.8):
Nome Attività Descrizione ID
Scelta tessuti … 3
Acquisto tessuti … 6
Nome Attore Descrizione ID
Fornitore di tessuti … 4
Confezionista … 5
Figura 5.4.7 Mantenimento dell’Attributo ID di Attori e Attività
<UML:CollaborationInstanceSet xmi.id="3" name="Scelta tessuti">…
99
<UML:CollaborationInstanceSet.participatingInstance><UML:Object xmi.idref="4"/><UML:Object xmi.idref="5"/>
</UML:CollaborationInstanceSet.participatingInstance>...
</UML:CollaborationInstanceSet><UML:CollaborationInstanceSet xmi.id="6" name="Acquisto tessuti">
…<UML:CollaborationInstanceSet.participatingInstance>
<UML:Object xmi.idref="4"/><UML:Object xmi.idref="5"/>
</UML:CollaborationInstanceSet.participatingInstance>...
</UML:CollaborationInstanceSet>
<UML:Object xmi.id="4" name="Fornitore di tessuti">…
</UML:Object>
<UML:Object xmi.id="5" name="Confezionista">…
</UML:Object>
Figura 5.4.8 Esempio di assegnazione di valori agli Attributi ID e IDREF
A questo punto però si è posto un ulteriore problema: alcune entità MODA-ML sono
descritte da più elementi XMI.
Ad esempio, un’Attività è descritta dall’elemento CollaborationInstanceSet e
dall’elemento Comment, il che comporterebbe una collisione di valori (Figura
5.4.9):
<UML:CollaborationInstanceSet xmi.id="3" name="Scelta tessuti"><UML:ModelElement.comment>
<UML:Comment xmi.idref="3"/></UML:ModelElement.comment>
…</UML:CollaborationInstanceSet>
…<UML:Comment xmi.id="3" body="Descrizione ">
<UML:Comment.annotatedElement><UML:CollaborationInstanceSet xmi.idref="3"/>
</UML:Comment.annotatedElement></UML:Comment>
Figura 5.4.9 Caso di assegnazione di valori non univoci all’attributo ID
Per ovviare questo problema, decidiamo di assegnare agli attributi ID un valore
100
composto:
codiceelemento_codicenumerico
dove il codice numerico è il valore generato utilizzando il contatore, mentre il codice
elemento è una stringa che identifica l’elemento cui l’attributo appartiene.
La versione corretta dell’esempio in Figura 5.4.9 quindi è (Figura 5.4.10):
<UML:CollaborationInstanceSet xmi.id="cis_3" name="Spedizione tessuti"><UML:ModelElement.comment>
<UML:Comment xmi.idref= "comm_3"/></UML:ModelElement.comment>
…</UML:CollaborationInstanceSet>
…<UML:Comment xmi.id="comm_3" body="Scambio di istruzioni per la
spedizione dei tessuti"><UML:Comment.annotatedElement>
<UML:CollaborationInstanceSet xmi.idref="cis_3"/></UML:Comment.annotatedElement>
</UML:Comment>
Figura 5.4.10 Esempio di assegnazione di valori univoci all’attributo ID
5.4.4 Implementazione modulo “Generatore SVG”
Il modulo “Generatore SVG” (generatore_svg.asp) gestisce la creazione di un file
SVG applicando una trasformazione XSLT ad un file XMI specificato.
Questa procedura si basa completamente sull’utilizzo dell’oggetto DOM: il file XMI
di origine e il foglio di stile sono caricati in due oggetti DOM; poi, eseguendo la
funzione transformNode() sull’oggetto DOM relativo al file XMI, viene applicata la
trasformazione XSLT e il risultato è inviato ad un albero DOM di destinazione.
Dopo di ciò, il DOM destinazione è memorizzato su file (Figura 5.4.11).
Sub svg_gen(xmi_file, nome_file)
‘Generatore di file SVG
‘xmi_file: file XMI che deve essere trasformato
‘nome_file: nome da assegnare al file SVG che deve essere generato
101
Dim svgFile
‘Preparo l’oggetto DOM per il documento XMI
Set source = Server.CreateObject(“Msxml2.DOMDocument.4.0”)
source.async = false
source.load(Server.MapPath(xmiFile))
‘Preparo l’oggetto DOM per il risultato della
trasformazione
Set SVGcode = Server.CreateObject(“Msxml2.DOMDocument.4.0”)
SVGcode.async = false
‘Preparo l’oggetto DOM per il foglio di stile
Set style = server.CreateObject(“Msxml2.DOMDocument.4.0”)
style.async = false
style.load(Server.MapPath(“toSVG.xsl”))
‘Applico la trasformazione XSLT
SVGcode = source.transformNode(style)
svgFile = nome_file
svgFile = Server.MapPath(svgFile)
Set objFS = CreateObject(“Scripting.FileSystemObject”)
Set objFile = objFS.CreateTextFile(svgFile, true)
objFile.Write(SVGcode)
Response.Write “</BR>” & (“File salvato”) & “</BR>”
objFile.close()
‘Libero la memoria
Set objFile = Nothing
Set objFS = nothing
Set source = Nothing
Set style = Nothing
Set xmiDoc=Nothing
End Sub
Figura 5.4.11 Procedura Generatore SVG
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-
Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle,
Rational Software, Texas Instruments e Unisys.
Il risultato finale dello sforzo dei partner UML è UML 1.0, sottoposto nel gennaio
1997 all'approvazione dell'Object Management Group (OMG) per essere adottato
come standard per l'Analisi e il Disegno OO.
Mentre questa versione viene analizzata, molte organizzazioni annunciano
l’adozione di UML come standard interno, mentre i partner UML iniziano a lavorare
alla versione 1.1, poi presentata all’OMG nel settembre 1997.
Nel novembre 1997 UML diviene ufficialmente standard OMG; da allora la sua
evoluzione è a carico dell’OMG. Le specifiche ufficiali sono reperibili al sito
www.omg.org.
Dopo la prima versione ufficiale, sono state sviluppate le seguenti: 1.2 nel dicembre
1998, 1.3 nel giugno 1999, 1.4 nel maggio 2001, 1.5 nel marzo 2003, e sono
attualmente in corso i lavori relativi a UML 2.0 (Figura A.1).
116
Figura A.1 Storia di UML
A.4 I diagrammi UML
A.4.1 Il diagramma dei casi d’uso
Un diagramma dei casi d’uso è un grafo che permette di visualizzare un caso
d’uso, ove un caso d’uso è una tipica interazione tra un utente e il sistema. Descrive
le modalità di utilizzo del sistema da parte di uno o più utilizzatori senza rivelare
l’organizzazione interna dello stesso sistema.
I diagrammi dei casi d’uso possono essere definiti a livelli diversi ossia possono
rappresentare l’intero sistema o parti di esso.
1999
1998
1997OMG adotta UML
2001pianificate minori revisioni
2003pianificateminori revisioni
Revisione editoriale senza cambiamenti
tecnici rilevanti
Unificazione dei precedenti modelli quali Booch, OMG
e Objectory
200?pianificate maggiori revisioni
<< document >>UML 1.2
<< document >>UML 1.3
<< document >>UML 1.5
<< document >>UML 2.0
<< document >>UML 1.4
<< document >>UML 1.1
117
Gli elementi e le reazioni che compongono il diagramma sono illustrati in Tabella
A.1 e in Tabella A.2:
Elemento Sintassi
Caso d’uso
Attore
Tabella A.1 Elementi che compongono il diagramma dei casi d’uso
Relazioni Sintassi Associazione
Estensione <<extend>>
Generalizzazione
Inclusione <<include>>
Tabella A.2 Relazioni che compongono il diagramma dei casi d’uso
Spieghiamo ora il significato di ciascun elemento:
caso d’uso: è una classe che definisce una funzionalità o un servizio che il
sistema offre agli attori;
attore: è un ruolo che un utente di un caso d’uso può impersonare interagendo
con esso. Gli attori sono soggetti esterni al sistema; non sono necessariamente
persone fisiche: un attore può essere, ad esempio, un sistema esterno che
richiede delle informazioni al sistema che si sta progettando;
associazione: indica la partecipazione di un attore in un caso d’uso;
estensione: indica una relazione da un caso d’uso esteso a un caso d’uso base,
specificando come il comportamento per il caso d’uso esteso può essere inserito
nel comportamento definito per il caso d’uso base;
generalizzazione: indica una relazione tra un caso d’uso più generale e un caso
d’uso più specifico;
Nome del Caso d'Uso
118
inclusione: indica una relazione da un caso d’uso base a un caso d’uso incluso,
specificando come il comportamento per il caso d’uso incluso viene inserito nel
comportamento definito per il caso d’uso base.
La Figura A.2 mostra una tipica struttura di un diagramma dei casi d’uso:
Figura A.2 Esempio di diagramma dei casi d’uso
I diagrammi dei casi d’uso risultano particolarmente utili durante la fase di specifica
dei requisiti del sistema, per modellare i requisiti di un utente o gli scenari di testing,
oppure per derivare modelli strutturali e comportamentali del sistema da realizzare.
Riportiamo un esempio di caso d'uso relativo ad un possibile scenario di una
biblioteca (Figura A.3):
Figura A.3 Caso d’uso Biblioteca
Attore
Caso d’uso 1
Caso d’uso 2
Caso d’uso 3
<<uses>>
<<extends>>
Manutenzione
Manutenzione testi
Manutenzione utenti
<<uses>>
<<uses>>
Supervisore
Responsabile
Situazione generale utenti
Situazione utente
<<uses>>
Utente
Ricerca titoli
Richiesta titiolo non disponibile
<<extends>>
Prestiti in corso
Statistiche prestiti
119
A.4.2 I diagrammi di struttura statica
Verranno ora esaminati i diagrammi di struttura statica, ovvero quei diagrammi
utilizzati durante la fase di progettazione di un sistema per descriverne l’architettura.
Il primo diagramma appartenente a questa categoria ad essere analizzato è il
diagramma delle classi.
Questo tipo di diagramma ha lo scopo di descrivere i tipi degli oggetti nel sistema, le
diverse relazioni statiche esistenti tra essi, le operazioni e gli attributi di una classe
ed i vincoli sulle relazioni.
Una classe è la descrizione di un insieme di oggetti (istanze della classe) che
condividono certe caratteristiche comuni; è rappresentata da un rettangolo
scomposto in tre parti (Figura A.4):
Figura A.4 Classe
Un attributo rappresenta una proprietà che è condivisa da tutti gli oggetti
appartenenti ad una data classe; ad esempio, se una classe rappresenta una persona,
dei possibili attributi sono nome e cognome. Un'operazione rappresenta un servizio
che può essere richiesto a qualche oggetto appartenente alla classe e che modifica il
comportamento del sistema a cui l'oggetto appartiene; in genere, modifica lo stato ed
il valore degli attributi dell'oggetto.
UML mette a disposizione diverse classi speciali, ciascuna con caratteristiche ben
definite. Ad esempio, la classe Interfaces (interfaccia) permette di specificare le
operazioni esternamente visibili di una classe o di un altro componente senza
specificarne la struttura interna (Figura A.5).
Figura A.5 Interfaccia
Le classi possono essere in relazione tra loro; UML definisce diversi tipi di relazione
Nome della Classe
Attributi
Operazioni
<< interface >>NomeClasse
120
statiche tra classi; i principali sono: generalizzazione e associazione.
La generalizzazione indica una relazione tra una classe di carattere generico (il
genitore) e una classe di tipo specifico (il figlio). La classe genitore è chiamata
superclasse, mentre la classe figlio è chiamata sottoclasse. La sottoclasse eredita tutti
gli attributi e le operazioni della superclasse dalla quale è derivata, inoltre, le
sottoclassi possono definire attributi e metodi propri o ridefinire i metodi ereditati
per estendere o modificare le responsabilità della superclasse. È possibile sostituire
riferimenti a qualsiasi oggetto di una superclasse con qualsiasi oggetto delle
sottoclassi da questa derivate.
Riportiamo un esempio in Figura A.6.
Figura A.6 Esempio di generalizzazione
Nell'esempio in Figura A.6, Persona è la superclasse, mentre Dottore e Infermiera
sono le sottoclassi.
Un’associazione indica la relazione esistente tra le istanze delle classi; graficamente
è rappresentata da una linea che connette le due classi coinvolte sopra la quale è
possibile scrivere il nome dell’associazione stessa e la direzione di lettura.
Ogni associazione ha due ruoli, ognuno dei quali corrisponde ad una direzione
dell’associazione, e una molteplicità, che indica quanti oggetti possono partecipare
all’associazione. È possibile mostrare i ruoli scrivendoli sul diagramma vicino la
linea orizzontale dalla parte della classe che svolge un determinato ruolo;
ugualmente è possibile fare per le molteplicità.
Consideriamo il seguente esempio: si vuole mostrare la relazione tra la classe
Commesso e la classe Negozio che stabilisce che un Commesso può lavorare al
massimo in un Negozio e che un Negozio deve avere almeno un Commesso (Figura
A.7).
Persona
InfermieraDottore
121
1..* 1..* lavora in 0..1
impiegat impiegato datore di lavoro
Figura A.7 Esempio di associazione
Due particolari tipi di associazioni sono le aggregazioni e le composizioni (Figura
A.8); le prime definiscono una relazione part-of e sono caratterizzate da un
diamante bianco all’estremità del componente intero. Le seconde definiscono in
modo univoco un’entità come parte di un intero (e se l’intero viene cancellato
scompaiono anche le sue parti) e sono rappresentate con un diamante nero
all’estremità del componente intero.
1
3..* *
Figura A.8 Esempio di aggregazioni e composizioni
Dal diagramma in Figura A.8 emerge la differenza tra composizioni e aggregazioni:
l’eliminazione di un poligono (classe Poligono) implica la cancellazione di tutti i
suoi punti (classe Punto), ma non dello stile (classe Stile) ad esso aggregato. Inoltre,
un’istanza della classe Punto può essere sia in un poligono che in un cerchio, ma non
entrambe; un’istanza della classe Stile, invece, può essere in più poligoni e cerchi.
È importante osservare che ci sono tre modi ben distinti di concepire e comprendere
un diagramma delle classi:
prospettiva concettuale: il diagramma rappresenta i concetti del dominio in
esame, ma non è detto che tali concetti troveranno corrispondenza nel sistema
finale;
prospettiva analitica: il diagramma rappresenta le interfacce dei moduli che
CommessoNegoz
io
1 1 1
Poligono Cerchioraggio
Punto
Stile
colore
122
verranno implementati in seguito;
prospettiva implementativa: le classi rappresentano gli effettivi moduli software
che dovranno essere implementati.
Capire la prospettiva è cruciale per leggere ed interpretare i diagrammi delle classi.
Il secondo tipo di diagramma di struttura statica è il diagramma degli oggetti.
I diagrammi degli oggetti costituiscono una variante dei diagrammi delle classi;
vengono utilizzati per rappresentare gli oggetti istanze delle classi con i relativi
legami riportati in modo esplicito, mostrando una fotografia del sistema scattata ad
un istante di tempo preciso. Quindi, mentre un diagramma delle classi è sempre
valido, un diagramma degli oggetti fornisce una possibile istantanea del sistema
valida in un determinato istante di tempo.
Scopo dei diagrammi degli oggetti è dettagliare le relazioni presenti nei diagrammi
delle classi ritenute poco chiare o piuttosto complicate.
La Figura A.9 mostra un possibile diagramma degli oggetti ottenuto istanziando il
diagramma delle classi del precedente esempio:
Figura A.9 Esempio di diagramma degli oggetti
A.4.3 I diagrammi d’interazione
Il prossimo gruppo esaminato è quello dei diagrammi d’interazione, che vengono
utilizzati per descrivere il comportamento dinamico del sistema in quanto
evidenziano in che modo gruppi di oggetti collaborano per compiere un determinato
lavoro. Tipicamente un diagramma d’interazione illustra il comportamento di un
singolo caso d’uso, mostrando alcuni oggetti d’esempio e i messaggi che si
Triangolo StileUno
PuntoA PuntoB PuntoC
123
scambiano nell’ambito di quello specifico caso d’uso.
Risultano utili anche in fase di modellazione (quando il livello di astrazione è molto
basso) per documentare l’utilizzo di classi, per illustrare come funzionalità
complesse siano realizzate attraverso l’interazione (scambio di messaggi), e così via.
In base all'aspetto dell'interazione a cui viene conferito maggior rilievo, i diagrammi
d'interazione vengono suddivisi in:
diagrammi di sequenza : focalizzano l’attenzione sull’ordine temporale dello
scambio dei messaggi;
diagrammi di collaborazione: mettono in risalto l’organizzazione degli oggetti
che si scambiano i messaggi.
Li analizziamo più approfonditamente.
Un diagramma di sequenza è un grafo che mostra la sequenza di messaggi scambiati
tra diversi oggetti per l’esecuzione di uno specifico compito.
I componenti del diagramma sono oggetti, messaggi e tempo.
Gli oggetti sono disegnati vicino la sommità del diagramma e sono disposti in
sequenza da sinistra verso destra. Essi possono essere inseriti in un qualunque ordine
che semplifichi la comprensione del diagramma. Da ogni rettangolo si diparte una
linea tratteggiata verso il basso, denominata "linea della vita" (lifeline), lungo la
quale si trova un piccolo rettangolo chiamato "attivazione" (activation). L'activation
rappresenta l'esecuzione di un'operazione di cui l'oggetto si fa carico mentre la
lunghezza del rettangolo rappresenta la durata dell'activation (Figura A.10).
Figura A.10 Notazione grafica per gli oggetti nei diagrammi di sequenza
Un messaggio viene disegnato a partire dalla lifeline dell'oggetto da cui parte il
messaggio e arriva sulla lifeline dell'oggetto a cui il messaggio è diretto. Ci sono due
tipi di messaggio (Tabella A.3):
Tipo Descrizione Notazione
:: Nome
124
sincrono l’oggetto che lo ha inviato deve attendere la risposta prima di poter continuare con altre operazioni
asincrono l’oggetto che lo ha inviato non deve attendere che gli venga inviata alcuna risposta prima di continuare con altre operazioni
Tabella A.3 Tipi di messaggio nei diagrammi di sequenza
Inoltre, la notazione rappresenta il ritorno da un messaggio; non è un
nuovo messaggio.
Il trascorrere del tempo viene rappresentato in direzione verticale. Il tempo,
graficamente, viene fatto partire alla base di ogni oggetto e proseguire fino in basso.
Ad esempio, un messaggio che si trovi più vicino all'oggetto rispetto ad un altro
(rispetto alla direzione
verticale), si verificherà prima nel tempo.
La Figura A.11 illustra il diagramma di sequenza di un possibile scenario di una
biblioteca.
Figura A.11 Diagramma di sequenza Biblioteca
Un diagramma di collaborazione può essere visto come un'estensione di un
diagramma di oggetti in quanto rappresenta le associazioni tra gli oggetti ed in più
consente di mostrare i messaggi che essi si inviano per interagire.
verifica disponibilità
:Responsabile :Utente :Testo :Prestito
verifica utente
cerca testo
[prestito possibile](consegna testo)
[prestito possibile](registra prestito)
[prestito possibile](impegna testo)
[prestito possibile](stampa motivazioni)
125
Gli oggetti sono rappresentati con dei rettangoli e i messaggi scambiati con delle
frecce che puntano all'oggetto che riceve il messaggio stesso. Tali frecce sono
posizionate vicino la linea di associazione tra gli oggetti e una label vicino alla
freccia indica la specifica del messaggio. Occorre aggiungere anche un numero
accanto alla freccia che indica l’ordine in cui il messaggio appare nella sequenza.
La Figura A.12 mostra il diagramma di collaborazione di un possibile scenario di
una biblioteca.
Figura A.12 Diagramma di collaborazione Biblioteca
Ovviamente, ci sono delle situazioni in cui è più opportuno utilizzare uno dei due
tipi di diagramma piuttosto che l’altro. Consideriamo, ad esempio, il loro utilizzo
nella Use Cases View, ossia per fornire l’illustrazione grafica di scenari, situazione
in cui il livello di astrazione è molto elevato e mancano particolari di tipo
implementativo. I diagrammi di sequenza sono molto utili in tale contesto, ma i
diagrammi di collaborazione risultano esserlo molto meno, in quanto verrebbero
visualizzati pochissimi oggetti con molte connessioni.
A.4.4 I diagrammi di stato
I diagrammi di stato vengono utilizzati per descrivere gli stati in cui può trovarsi
un certo oggetto e i cambiamenti di stato che subisce al verificarsi di determinati
eventi. Essenzialmente descrivono automi a stati finiti e pertanto sono costituiti da
:Utente
:Utentebibliteca
:Prestito
: Libro
interfaccia richiesta: interfaccia
controllo richiesta
9: 5: 2:14:
3: ControlloUtentePerPrestito
8: 4:
7: PrestitiDelCliente()
11: richiesta(cod_libro)
12: Prestito()
1: RichiestaPrestito
10: err: utente deve restituire 6: err: utente non censito()15: err: libro già in prestito
126
un insieme di stati, transazioni tra di essi, eventi ed attività. Ogni stato rappresenta
un periodo di tempo ben delimitato della vita di un oggetto durante il quale l’oggetto
stesso soddisfa precise condizioni.
I diagrammi di stato, quindi, modellano la possibile storia della vita di un oggetto,
ragion per cui concorrono a rappresentarne il comportamento dinamico.
Gli elementi che compongono un diagramma di stato sono (Tabella A.4):
gli stati in cui può trovarsi un oggetto durante il suo ciclo di vita;
le transizioni, etichettate con eventi, che rappresentano le relazioni tra i diversi
stati in cui può trovarsi un oggetto e indicano le condizioni necessarie per il
verificarsi di una transizione di stato.
Elemento Notazione
Stato iniziale
Stato finale
Altri stati
Transizione
Tabella A.4 Elementi del digramma di stato
In Figura A.13, riportiamo l'esempio di un diagramma di stato relativo ad una
biblioteca.
Nome
Variabili di Stato
Attività
acquisto
in ritardo
in prestitoprestito(data)
restituzione (data restituzione)
restituzione (data scadenza termini restituzione)
acquisizione libro(dati libro, autori, editore)
cancellazione libro(ISDN)
cancellazione libro(ISDN)
sollecito
127
Figura A.13 Diagramma di stato Biblioteca
I diagrammi di stato sono molto indicati per descrivere il comportamento di un
oggetto attraverso diversi casi d'uso, mentre non sono adatti per modellare scenari
che coinvolgono più oggetti che collaborano insieme.
Un caso particolare di diagramma di stato è costituito dai diagrammi delle attività.
Questi ultimi servono per rappresentare sistemi di workflow, oppure la logica interna
di un processo di qualunque livello, dai business process ai processi di dettaglio.
Solitamente vengono utilizzati per descrivere attività che si svolgono in parallelo e
possono sincronizzarsi in qualche modo.
Ogni stato rappresenta l’esecuzione di un’opportuna attività e la transizione da
quello stato al successivo è generata dallo svolgersi dell’attività stessa.
Consideriamo ad esempio il caso della biblioteca (Figura A.14):
Richiesta testo
[disponibile]
Prendi Libro
Aggiorna Calendario
[disponibile]
Compila Modulo
Verifica disponibilità
Aggiorna richiesta
128
Figura A.14 Diagramma delle attività Biblioteca
Si consiglia di ricorrere ai diagrammi delle attività nelle seguenti situazioni:
nell’analisi di un caso d’uso quando ancora non è necessario allocare le azioni
agli oggetti ma basta sapere quali attività si verificheranno e le eventuali
dipendenze tra esse;
per comprendere il workflow attraverso più casi d’uso;
trattando con le applicazioni multi-thread.
Sono sconsigliati per mostrare le interazioni tra gli oggetti o per descrivere il
comportamento degli stessi durante il loro ciclo di vita.
A.4.5 I diagrammi d’implementazione
L’ultimo gruppo è quello dei diagrammi di implementazione, ovvero quei
diagrammi inerenti agli aspetti implementativi, che vengono generalmente utilizzati
per mostrare l’organizzazione del codice sorgente e le relazioni tra componenti
software e hardware. Comprendono tre tipi di diagrammi: diagrammi dei package,
dei componenti e di dislocamento.
In UML il termine “package” viene utilizzato per indicare il raggruppamento delle
classi in unità ad alto livello. I diagrammi dei package mostrano, appunto,
l’organizzazione delle classi in determinati moduli e le dipendenze tra di essi.
Un package può contenere elementi del modello di tipo diverso; in particolare,
129
possono essere contenute gerarchie di package innestati. Un package definisce un
“namespace” per i suoi componenti.
Esaminiamo gli elementi di un diagramma dei package (Tabella A.5):
Elemento Descrizione Sintassi Package gruppo di elementi del modello
Import una dipendenza che indica che i contenuti pubblici del package obiettivo sono aggiunti al namespace del package sorgente
<<import>>
Access una dipendenza che indica che i contenuti pubblici del package obiettivo sono disponibili nel namespace del package sorgente
<< access>>
Tabella A.5 Elementi del diagramma dei package
Esiste una dipendenza tra due elementi se cambiamenti alla definizione di un
elemento possono causare cambiamenti all’altro. Esiste una dipendenza tra due
package se esistono dipendenze tra due classi nel package.
La seguente Figura A.15 mostra un esempio di diagramma dei package:
Figura A.15 Esempio di diagramma dei package
L’utilizzo dei diagrammi dei package è fortemente incoraggiato nello sviluppo di
progetti di grandi dimensione in quanto consentono di organizzare le classi in unità
logiche distinte e permettono di ottenere viste differenti a diversi livelli di
Nome
MagazzinioVenditeCliente Ordine
Posizione Articolo
Scorte Ordini
130
astrazione, semplificando così la complessità di tali progetti.
A.4.6 Il diagramma dei componenti
Il diagramma dei componenti evidenzia l’organizzazione e le dipendenze esistenti
tra i componenti di un sistema. Ciascun componente rappresenta una parte del
sistema, ovvero moduli di codice eseguibile dotati di identità e con un’interfaccia
ben specificata. Un componente è tipicamente costituito da un insieme di elementi
(interfacce, classi, ecc.) che risiedono nel componente stesso. I componenti possono
essere organizzati in package.
Un componente viene rappresentato nel seguente modo (Figura A.16):
Figura A.16 Componente
Il diagramma dei componenti illustra la proiezione statica dell’implementazione del
sistema e, pertanto, è strettamente connesso al diagramma delle classi.
Riportiamo un esempio in Figura A.17:
Figura A.17 Esempio di diagramma dei componenti
Componenete Software
Database server
<< Table >>Ordini
<< Table >>Clienti
Forum InserimentoOrdine
Il Forum conosce il DataBase Server e può essere coinvolto da ognisuo cambiamento
131
A.4.7 Il diagramma di dislocamento
L’ultimo diagramma è il diagramma di dislocamento; questo diagramma permette
di rappresentare, a diversi livelli di dettaglio, l’architettura hardware e software del
sistema, illustrandone gli elementi fisici (computer, reti, dispositivi, …)
opportunamente interconnessi e i moduli software allocati su ciascuno di essi. In
sintesi, evidenzia la struttura run-time dei componenti, ovvero del sistema dei
processi e degli oggetti presenti in esso.
I principali elementi di un diagramma di dislocamento sono i nodi e gli archi.
I nodi, raffigurati da parallelepipedi, rappresentano componenti hardware,
all’interno dei quali sono presenti uno o più componenti software. Gli archi indicano
flussi di comunicazione tra componenti software diversi (Figura A.18).
Figura A.18 Esempio di diagramma di dislocamento
Generalmente si preferisce usare i diagrammi di dislocamento piuttosto che i
diagrammi dei componenti poiché mostrano le relazioni non solo tra i componenti
software, ma anche tra quelli hardware.
connessione
Internet nodo
<<processor>>server primario
<<processor>>server
<<processor>>server
<<processor>>server
<<netwoek>> rete locale
<<processor>>server di cache
<<processor>>server di cache
nodo
modem
132
133
Appendice B UMM: approfondimenti
B.1 Esempio: vendita di prodotti usando un catalogo elettronico
Si consideri il seguente scenario:
“ Un Buyer (compratore) vuole effettuare un ordine tramite il catalogo di un Seller.
Per far ciò il Buyer, per prima cosa, deve determinare se ha o meno una versione
aggiornata del catalogo, se no, deve inviare una richiesta del catalogo e il Seller gli
deve inviare la versione elettronica del catalogo.
Una volta ottenuto il catalogo, il Buyer decide se ordinarvi uno o più prodotti; se no
la transazione termina.
Se il Buyer decide di effettuare un ordine, deve verificare se è già registrato presso il
Seller, poiché egli accetta solo Buyer registrati. Se il Buyer non è registrato, invia al
Seller le sue informazioni. Dopo aver verificato le informazioni e il credito del
Buyer, il Seller invia l’identificativo del Buyer (IDBuyer).
Prima di ordinare, il Buyer verifica se il prezzo corrente del prodotto è disponibile,
se no, il Buyer richiede una quotazione e il Seller gliela fornisce. Nota che una
richiesta per una quotazione, come anche un ordine, può essere rivista e approvata
da un’autorità regolare. Sulla base della quotazione il Buyer decide se ordinare il/i
prodotto/i o meno. Se no, la transazione è completata.
Se il Buyer vuole ordinare il/i prodotto/i (in accordo con il prezzo noto o con la
quotazione richiesta) invia un ordine al Seller. Una volta che l’ordine è stato
accettato e il prodotto spedito, il Seller addebita la carta di credito del Buyer e avvisa
Buyer dell’avvenuta spedizione.
Finché il Buyer non riceve il prodotto ordinato, può richiedere lo stato dell’ordine al
Seller, il quale, quindi, gli risponde. Il ciclo di richiesta e invio di informazioni sullo
stato dell’ordine può essere effettuato più volte.
Quando il Buyer riceve il prodotto ordinato la transazione è completata con
134
successo.
L’intero workflow può essere eseguito più volte.
Si assume che non si verifichino eccezioni durante il caso di business esaminato e
che il Buyer non cancelli né cambi un ordine una volta che il numero dell’ordine è
stato emesso.”
Tale scenario sarà ora modellato secondo l’UN/CEFACT Modeling Methodology.
Business Modeling Workflow
Il dominio di business che si sta considerando è il dominio di un’impresa che
produce prodotti e servizi per i Compratori.
Il primo step consiste nell’identificare le Business Area che compongono il dominio,
che sono:
Manufacturing
Retail
Financial
Transport
Services
L’esempio considerato coinvolge una compagnia che vende vari prodotti tramite
catalogo, quindi la Business Area inerente è Retail.
La struttura del dominio è illustrata usando un diagramma dei package UML, Figura
B.1.
Figura B.1 Business Area/Process Area Packages
A questo punto vengono definite tutte le possibili Process Area dentro la Business
Area d’interesse:
Marketing
<<BusinessArea >>Manufacturing
<<BusinessArea >>Retail
<<BusinessDomainModel>>International Supply Chain
<<BusinessArea >>Transport
<<BusinessArea >>Financial
<<BusinessArea >>Services
135
Ordering
Distribution
Settlement
Regulatory
Il caso di business considerato comprende l’ordine di prodotti da catalogo e il
pagamento dell’ordine tramite carta di credito, quindi le Process Area connesse sono
Ordering e Settlement.
La Process Area Ordering si compone dei seguenti Business Process:
Obtain Customer ID
Obtain Product List
Obtain Quote
Place Order
Obtain Order Status
Per quanto riguarda la Process Area Settlement, invece, individuiamo un solo
Business Process:
Debit Credit Card
Dall’analisi effettuata emerge la seguente situazione riportata in Figura B.2.
Figura B.2 Business Area Retail
Vengono cercate la Business Process Area Library (Repository) e i modelli di
Business AreaRetail
Process AreaSettlement
Process AreaOrdering
Business ProcessObtain Product List
Business ProcessObtain Customer ID
Business ProcessObtain Quote
Business ProcessPlace Order
Business ProcessObtain Status
Business ProcessDebit Credit Card
136
business process con Business e Process Area simili. I Business Process identificati
e categorizzati entro le Business e Process Area attualmente disponibili nella Library
(Repository) sono illustrati in Figura B.3.
Figura B.3 Business Process relativi alla Business Area Retail presenti nella Library
Il modello può essere rifinito con un livello di dettaglio maggiore se si considera che
il processo OrderWithQuote può essere scomposto in due processi: ObtainQuote e
PlaceOrder (FiguraB.4).
<<Business Area>>Retail
<<BusinessProcess>>DebitCreditCard
<<ProcessArea >>Settlement
<<ProcessArea >>Ordering
<<BusinessProcess>>ObtainProductList
<<BusinessProcess>>ObtainOrderStatus
<<BusinessProcess>>OrderWithQuote
Seller
<<BusinessProcess>>ObtainProductList
<<BusinessProcess>>PlaceOrder
<<BusinessProcess>>ObtainQuote
SellerBuyer
<<BusinessProcess>>ObtainOrderStatus
SellerBuyer
Settlement<<Process Area>>
Retail <<Business Area>>
<<BusinessProcess>>OrderWithQuoteBuyer
Ordering <<Process Area>>
<<BusinessProcess>>DebitCreditCard
BankSeller
137
Figura B.4 Use Case Diagram per i Business Process supportati dalla Library
L’ultimo passo del workflow consiste nella realizzazione del diagramma UML Use
Case che illustra le relazioni tra Business Partner e Business Process (Figura B.5)
Figura B.5 Use Case Diagram finale per i Business Process supporatati dalla Library
Requirements Workflow
Ogni business process identificato nel workflow precedente viene descritto con
<<BusinessProcess>>ObtainProductList
<<BusinessProcess>>OrderWithQuote
<<BusinessProcess>>ObtainOrderStatus
<<BusinessProcess>>DebitCreditCard
<<BusinessProcess>>Place Order
<<BusinessProcess>>ObtainQuote
Buyer
Bank
Seller
<<include>> <<include>>
138
maggiore dettaglio (Figura B.6).
Figura B.6 Use Case Diagram con tutti i Business Process individuati
Si procede quindi con l’identificazione delle Business Collaboration (Figura B.7).
Figura B.7 Business Collaboration
Come illustrato dalla Figura B.7, ci sono tre Business Collaboration: la più ampia è
Order From Catalog ed è composta da Ordering e Settlement.
<<BusinessProcess>>ObtainProductList
<<BusinessProcess>>ObtainQuote
<<BusinessProcess>>ObtainCustomerID
<<BusinessProcess>>DebitCreditCard
<<BusinessProcess>>PlaceOrder
Buyer
Bank
Seller
<<BusinessProcess>>ObtainOrderStatus
<< Business Domain Model>>Order From Catalog
<<Business Collaboration>> Ordering
<<Process Area>>Ordering
<<Business Process>>Obtain Price List
<<Business Process>>Obtain Customer ID
<<Business Process>>Obtain Quote
<<Business Process>>Obtain Status
<<Business Process>>Place Order
<<Process Area>>Settlement
<<Business Collaboration>> Settlement
<<Business Process>>Debit Credit Card
<<Business Area>>Retail
139
Poiché sia Order From Catalog che Ordering e Settlement possono essere suddivise
in ulteriori business collaboration e/o transaction, sono considerate Business
Collaboration Protocol.
Un esempio di Business Transaction, invece, è dato dal business process Obtain
Customer ID, in quanto non può essere suddiviso in ulteriori business collaboration
e/o transaction.
Una volta identificata, una Business Collaboration può essere rappresentata con un
Business Process Activity Model (Figura B.8).
Figura B.8 Business Process Activity Model relativo alla Business Collaboration
Order From Catalog
Osserviamo che durante l’analisi della Business Collaboration è emerso che il Seller
dovrebbe notificare al Buyer che il prodotto è stato spedito; è stato quindi introdotto
un ulteriore business process, NotifyBuyerOfShipment.
[reject] [accepted]
[valid catalog on hand]
ObtainProductList
ObtainCustomerID
ObtainQuote
DebitCreditCard NotifyBuyerOfShipment
ObtainOrderStatus
PlaceOrder
[no valid catalog on hand]
[no customer ID from this seller]
[no quote required]
[got customer ID from this seller]
[quote required]
[requote request]
[exit no order placed]
[order status required][shipment received]
[product shipped]
[order fullfieled]
140
La Figura B.9 illustra il diagramma Business Process Use Case completo.
Figura B.9 Business Process Use Case
La Figura B.10 è il Business Collaboration Use Case Diagram che, invece, mostra
che Order From Catalog si suddivide in due collaboration (Order e Settlement) che
usano, oltre ai precedenti, anche i due nuovi business process identificati
ObtainProductList
ObtainQuote
ObtainCustomerID
DebitCreditCard
PlaceOrder
Buyer
Bank
Seller
ObtainOrderStatus
NotifyBuyerofShipment
<<Business CollaborationUseCase>>OrderFromCatalog
141
Figura B.10 Business Collaration Use Case
Analizziamo ora più dettagliatamente la collaboration Obtain Customer ID: la
richiesta dell’ID e la risposta sono essenziali nella collaborazione; inoltre, anche la
business entity Customer Information è rilevante nella collaborazione e si dovrebbe
assumere che le informazioni relative al customer siano incluse nella richiesta
dell’ID. Realizziamo il Conceptual Business Information Model che illustra queste
informazioni (Figura B.11).
<<Business CollaborationUseCase>>Order
ObtainQuote
DebitCreditCardObtainProductList
Buyer
Bank Seller
ObtainOrderStatus
<<Business CollaborationUseCase>>Settlement
ObtainIDBuyer
PlaceOrder
NotifyBuyerofShipment
142
Figura B.11 Conceptual Business InformationModel – Obtain Custumer ID
Analysis Workflow
Il primo passo consiste nella realizzazione di un object flow diagram per ogni
Business Collaboration Use Case identificato nel workflow precedente. Come
esempio, illustriamo il Business Collaboration Object Flow Diagram relativo alla
business transaction activity della collaborazione Obtain Customer ID (Figura
B.12).
143
Figura B.13 Business Collaboration Protocol (Object Flow diagram) –
ObtainCustomerID
Per ogni business transaction activity identificata nella collaborazione Order From
Catalog occorre selezionare un business transaction pattern e i ruoli di chi inizia e di
chi risponde dei partner individuati.
Lo illustriamo con uno Use Case Diagram (Figura B.14).
Figura B.14 Order From Catalog- Use Case Diagram
Per ogni Business Transaction activity deve essere definito un business transaction
<<CommercialTransactionActivity>>DebitCreditCard
Bank
<<QueryResponseActivity>>ObtainProductList
<<RequestResponseActivity>> ObtainQuote
<<RequestResponseActivity>>ObtainCustomerID
<<CommercialTransactionActivity>>PlaceOrder
<<RequestConfirmActivity>>ObtainOrderStatus
<<NotificationActivity>>NotifyBuyerofShipment
Buyer Seller
144
activity graph, come illustrato in Figura B.15.
Figura B.15 Obtain CustomerID-Business Transaction
L’ultimo passo consiste nella realizzazione del diagramma delle classi Final
Business Information Model relativo alle Business Information della business
transaction activity Obtain Customer ID (Figura B.16, Figura B.17).
+Buyer
1..*
+Shipping
0..1
+Billing
<<enumeration>>Country
<<enumeration>>GeographicalRegion
<<enumeration>>Currency
<<enumeration>>AmountType
-Balance-…
<<enumeration>>AddressType
-Billing-Shipping-...
<<enumeration>>PartyType
-Buyer-…
<<enumeration>>AccountType
-CreditCard-…
<<enumeration>>AddressLineType
-StreetName-StreetNumber-HouseNumber-BuildingIdentifier-Floor-...
<<BusinessObject>>Contact
+PhoneNumber: String +MobileNumber[0..1]: String+FaxNumber[0..1]: String+EmailAddress[0..1]: String
<<BusinessObject>>Amount
+Value: Real+Currency
<<BusinessObject>>Address
+Addressee: String+PostalCodeID: String+PostalCodeLocation[0..1]: String+Country: Country-GeographicalRegion[0..1]:GeographicalRegion
<<BusinessObject>>AddressLine
+Key: AddressLineType+Detail: String
<<BusinessObject>>Account
+BankID: Integer+AccountType String+AccountID: Integer+AccountHolder: String+StartDate: Date+EndDate: Date
<<BusinessObject>>Party
+LegalName: String +ShortName[0..1]: String+OfficialRegistrationIDNumber: String+ OfficialRegistrationAuthority: String
<<BusinessObject>>HederInformation
+ReferenceID: String+RespondByDate: Date
<<BusinessEntity>>CustomerInformation
<<BusinessService>>BuyerSystem
+SubmitRegistrationRequest()
<<InformationEnvelope>>RegistrationRequestEnvelope
<<BusinessInformation>>RegistrationRequest
<<instanties>>
+RegistrationRequestHeader
+CreditCard
0..*
[SUCCESS] [CONTROLFAILURE]
<<BusinessAction>>SubmitRegistrationResponse
RegistrationResponse<<RequestResponseActivity>>SubmitRegistrationRequest
RegistrationRequest
Buyer Seller
145
Figura B.16 Registration Request – Business Information Model finale
+Balance
<<enumeration>>RegistrationStatus
-Approved-Rejected-...
<<enumeration>>PartyType
-Customer-…
<<BusinessObject>>HederInformation
+ReferenceID: String
<<BusinessObject>>RegistrationDetails
+Status: RegistrationStatus+ReasonCode[0..1]: RegistrationRegection+ReasonText[0..1]: String
<<BusinessObject>>Party
+PartyID: String
<<BusinessObject>>HederInformation
+ReferenceID: String
<<BusinessEntity>>CustomerInformation
<<BusinessService>>SellerService
+SubmitRegistrationResponse ()
<<InformationEnvelope>>RegistrationResponseEnvelope
<<BusinessInformation>>RegistrationResponse
<<instanties>>
+RegistrationResponseHeader +RegistrationRequestHeader
+Customer0..1
<<enumeration>>RegistrationRejection
-AccountExpired-CreditLimitToLow-MissingInformation
146
Figura B.17 Registration Response – Business Information Model finale
147
Appendice C BPSS
Figura C.1 Versione UML del Business Process Specification Schema
148
149
Bibliografia
[BM] Business Process Analysis Working Group, “Business Modelling for
UN/CEFACT”, CEFACT/2000/BP024, 14 marzo 2000,
http://www.unece.org/cefact/docum/download/00bp024.pdf
[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-
bxml.org/specs/ebBPSS.pdf
[ebTA] ebXML Technical Architecture Project Team, ebXML Technical Architec-
ture Specification v1.0.4, Technical Specification, 16 febbraio 2001,
http://www.ebxml.org/specs/ebTA.pdf
[ebXML] http://www.ebXML.org
150
[Kim02] HyoungDo Kim, Conceptual Modeling and Specification Generation for
B2B Business Process based on ebXML, SIGMOD Record, Vol. 31, No. I,
marzo 2002,
http://www.acm.org/sigmod/record/issues/0203/SPECIAL/6.dokim.pdf
[MML] http://www.moda-ml.net
[MMLfr] Guido Cucchiara, Piergiorgio Censoni, Piero De Sabbata, Luca Mainetti,
Massimo Marzocchi, Thomas Imolesi, “Creation of an XML vertical
framework for Electronic data exchange in Textile/Clothing sector:
MODA-ML”, 2003
[MMLexp] Alberto Bucciero, Luca Mainetti, Massimo Marzocchi, Thomas Imolesi,
Aurelio Muzzarelli, “Strumenti a supporto della creazione di framework
di scambio dati XML: l’esperienza di MODA-ML”, Congresso AICA,
Settembre 2002, Lecce
[MOF] OMG, Meta Object Facility version 1.4, OMG document formal/02-04-03,
aprile 2002, http://www.omg.org/technology/documents/formal/mof.htm
[OCL] OMG, Object Constraint Language Specification, OMG document ad97-08-
08, http://www.www.omg.org/docs/ad97-08-08.pdf
[Pos] Gentleware, Poseidon for UML, http://www.gentleware.com
[Prf] Profile Working Group, Requirements for UML Profiles version 1.0, OMG
document ad/99-12-32 , dicembre1999, http://www.omg.org/docs/ad/99-12-
32.pdf
151
[RR] Rational, Rational Rose, http://www.rational.com
[RUP] Philippe Kruchten, Rational Unified Process – Introduzione, Addison-
Wesley 2000
[sup] Michael Rebstock, Supporting Interactive Multi-Attribute Electronic Negoti-
ations with ebXML, Proceedings of the 36th Hawaii International Conference
on System Sciences, 2003, http://www.hicss.hawaii.edu/HICSS36/HICSSpa-
pers/DTESC04.pdf
[SVG] SVG Working Group, Scalable Vector Graphics (SVG) 1.1 Specification,
W3C Recommendation, 14 gennaio 2003, http://www.w3.org/TR/SVG/
[TA] Pieraugusto Pozzi, Marco Casagni, Piero De Sabbata, Fabio Vitali,
Commercio Elettronico e XML – Scenari, tecnologie, applicazioni,
FrancoAngeli
[UML] James Rambaugh, Ivar Jacobson, Grady Booch, The Unified Modeling
Language Reference Manual, Addison-Wesley, 1998
[UMLd] Martin Fowler, Kendall Scott, UML Distilled – Applying the standard
object modeling language, Addison-Wesley
[UMLSp] OMG, Unified Modeling Language Specification version 1.5, OMG
document formal/03-03-01, marzo 2003,
http://www.omg.org/technology/documents/formal/uml.htm
152
[UMM] Techniques and Methodologies Working Group, UN/CEFACT Modeling
Methodology, CEFACT/TMWG/N090R10, novembre 2001, http://
www.untmg.org/doc_bpwg.html
[UMMug] Techniques and Methodologies Working Group , UN/CEFACT Modeling
Methodology (UMM) User Guide, CEFACT/TMG/N093, 22 settembre
2003, http://www.untmg.org
[XMISp] OMG, XML Metadata Interchange (XMI) Specification version 1.2, OMG
document formal/02-01-01, gennaio 2002, http://www.omg.org/techno-
logy/documents/formal/xmi.htm
[XSLT] J. Clark, XSL Transformations (XSLT) Version 1.0, W3C Recommendation,
16 novembre 1999, http://www.w3.org/TR/xslt
153
Ringraziamenti
Desidero ringraziare il prof. Fabio Vitali per avermi dato la possibilità di realizzare
questa tesi e per la sua disponibilità.
Un ringraziamento particolare a Piero De Sabbata per i suoi insegnamenti, per la sua
pazienza e per avermi offerto l’opportunità di proseguire il lavoro iniziato con la
tesi.
Ringrazio Nicola Gessa per il contributo offertomi per la realizzazione della tesi.
Grazie alle persone che in questi anni universitari mi sono sempre state vicine, mi
hanno sempre sostenuto e senza le quali non sarei arrivata al termine: i miei genitori,
mio fratello Simone, il mio ragazzo David e la mia carissima amica Sasà.
Ringrazio i ragazzi e le ragazze di X-Lab con i quali ho condiviso questo anno di
lavoro, in particolare Massimo e Thomas per il supporto che mi hanno dato.
Infine, ringrazio tutti i parenti e gli amici che stanno condividendo con me questo
giorno speciale.
154