Espressioni

Identicano eettivamente tutti gli elementi che costituiscono il processo di bu- siness, con una sintassi specica e una serie di operazioni permesse. Per vincolare il

corretto inserimento dell'espressione, sono stati implementati dei controlli che per- mettono di segnalare esplicitamente eventuali errori di inserimento e la posizione esatta del punto di errore.

Si indica di seguito la sintassi scelta per il linguaggio. Sequence Flow ;

Il carattere ";" viene utilizzato per identicare un connettore fra due elementi, quello che precede il simbolo e quello che lo segue. Per non aumentare il livello di complessità dell'espressione, si è scelto di non permettere altri tipi di connettori. Nella parte nale del capitolo riporteremo alcune regole per l'utilizzo dei sequence ow.

Dopo aver approfondito i prossimi elementi, utilizzeremo i sequence ow all'in- terno di alcuni esempi.

Eventi e(<name><type[-EventDenition]>)

Denizione di un evento con un nome specico. Il nome e il tipo sono da- ti obbligatori e quest'ultimo, in particolare, è utilizzato per denire il successivo tag xml dell'evento. Se scrivessimo un tipo non esistente, di fatto, genereremmo un tag non interpretabile dai tool di realizzazione dei processi di business. La scelta, seppur apparentemente non coerente con il resto dei controlli imposti, è stata fatta per non vincolarsi alla sintassi di una singola piattaforma ma permet- tere l'utilizzo di tipi evento disponibili su vari sistemi, preoccupandosi ovviamente di non utilizzare l'xml creato su strumenti che non possano supportarlo. Esiste inoltre, per l'attributo type, la possibilità di specicare un'espressione opzionale, nella forma -EventDenition. Tramite questa denizione, se passata in fase di

creazione, andremo a denire la decorazione dell'evento, per denirne l'eettivo comportamento. In caso no nsia presente il parametro, l'evento intermedio sarà di tipo generico.

E' possibile costruire 3 tipi di eventi:

ˆ start, costruiti automaticamente dopo i caratteri := ; ˆ intermediate, che possono essere di tipo throw o catch; ˆ end, costruiti quando inseriamo il carattere ..

Gli eventi intermedi, sia throw che catch, come discusso nel capitolo 2, possono avere un'ulteriore denizione nelle seguenti categorie:

ˆ message; ˆ timer; ˆ signal;

Nel caso in cui non si indichi alcuna denizione ulteriore, l'evento sarà generico. Come precedentemente detto, per scelta, il motore non vincola alcun tipo di evento lasciando all'utilizzatore la possibilità di denire quanto necessario per il suo processo.

Tratteremo nel prossimo capitolo nel dettagli la costruzione dell'xml a fronte del tipo di un evento.

Per imporre il vincolo di un solo evento Start e un solo evento End, si è deciso di non permettere la creazione di questo tipo di eventi che saranno aggiunti auto- maticamente alla struttura xml. Il motore aggiungere quindi lo Start dopo aver

Figura 3.2: P<name:DemoProject>

lavorato i caratteri ":=" mentre 'evento End sarà aggiunto quando si troverà il "." nale, carattere di ne denizione.

A scopo d'esempio creiamo un processo con solo evento iniziale e nale total- mente scollegati, generati dall'espressione:

P< name : DemoProject := .

Task t(<name><type>)

Per permettere una gestione semplicata della sintassi di input senza aumentare la complessità, abbiamo scelto di utilizzare solo i Task come tipi di attività. Nella denizione del task sarà obbligatorio inserire il nome mentre il tipo, che risponde alle stesse caratteristiche elencate per l'evento in termini di generazione dell'xml, può non essere presente permettendo la creazione di un task generico.

I task possono essere di 4 tipi fondamentali:

ˆ generico, con possibilità di omettere l'attributo di tipo generic; ˆ message, di tipo send per invio messaggi;

ˆ message, di tipo receive per ricezione messaggi; ˆ user, per attività che svolge l'utente.

Come già detto per i processi, anche in questo caso il motore lascia libertà di valorizzare l'attributo type con un valore accettato dalla notazione xml. Sarà onere

Figura 3.3: P<name:DemoProject>

dell'utilizzatore vericare la giusta tipologia di task da creare per il suo processo e la relativa sintassi.

Arricchendo il processo precedente otteniamo: P< name : DemoProject :=

t< name : UserTask , type : user > .

Gateway (...+...x...|...)

I gateway sono identicati dai caratteri di parentesi tonde "( )". Tutto quello che viene inserito nelle parentesi seguirà uno dei rami dei gateway. La direzione del gateway è "divergente" nel caso di parentesi aperta e "convergente" nel caso di parentesi chiusa. All'interno delle parentesi è obbligatorio ci sia un simbolo che identichi il tipo di operazione logica svolta. In particolare per scelte progettuali si è scelto di implementare solo le operazioni XOR, rispondente al simbolo x , AND, rispondente al simbolo + ed OR, rispondente al simbolo |. In caso di errore nell'inserimento del simbolo dell'operazione o della sintassi di apertura e chiusura delle parentesi, è previsto la segnalazione di eccezione che identichi esattamente il problema.

I gateway possono essere innestati, costruendo un'espressione che mantenga il usso logico di apertura-chiusura parentesi che permetta di rispettare il usso del

Figura 3.4: P<name:DemoProject>

processo. Nella parte nale del capitolo riporteremo alcune indicazioni che sarebbe opportuno prendere in considerazione nella costruzione.

Continuando l'utilizzo del processo precedente avremo (g. 3.4): P< name : DemoProject :=

t< name : UserTask , type : user >; (

t< name : Parallel1 , type :send > +

t< name : Parallel2 , type :send > ) ;

t< name : FinalTask , type : generic > .

Cicli

I cicli sono blocchi di espressioni complesse, sintetizzate con pochi caratteri di inizio e ne. Possono contenere singoli oggetti o scelte multiple e altri cicli. Per scelte progettuali sono stati implementati due tipi di ciclo:

ˆ Ciclo 0..n

Si raccomanda di seguire le regole indicate a ne capitolo per non aumentare eccessivamente il livello di complessità dell'espressione, con conseguenti errori di parsing o problemi nella visualizzazione del diagramma corretto.

Ciclo 1..n *[...]*

L'espressione racchiusa tra i simboli citati permette di realizzare cicli che ese- guono alcuni rami da una a n volte. I gateway esclusivi utilizzati per il ciclo sono aggiunti implicitamente senza controllo dell'utente.

Dall'esempio precedente avremo (g 3.5): P< name : DemoProject :=

t< name : UserTask , type :user > ; *[

(

t< name : Parallel1 , type :send > +

t< name : Parallel2 , type :send > ) ;

]*;

t< name : FinalTask , type : generic >.

Ciclo 0..n @[...]@

L'espressione racchiusa tra i simboli citati permette di realizzare cicli che ese- guono alcuni rami da zero ad n volte. I gateway esclusivi utilizzati per il ciclo sono aggiunti implicitamente senza controllo dell'utente.

Dal processo precedente otterremo (g 3.6): P <name : DemoProject :=

Figura 3.6: P<name:DemoProject> @[

(

t< name : Parallel1 , type :send > +

t< name : Parallel2 , type :send > ) ;

]@ ;

t< name : FinalTask , type : generic > .

Si noti che la rappresentazione graca del ciclo (0..n) può riportare alcune pic- cole sovrapposizioni di elementi. Il problema è però facilmente superabile spo- stando manualmente, nel diagramma, gli elementi sovrapposti, per evitare gli accavallamenti.