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