Introduzione
Capita a volte che l'applicazione che ci accingiamo
a sviluppare debba essere organizzata secondo un vero
e proprio "flusso di lavoro", nel quale un
insieme di azioni vengono svolte da un insieme di attori
(umani o automatici), che interagiscono scambiandosi
dati e attivando determinate altre azioni, assegnate
via via secondo determinate "regole di ingaggio".
Non si sta parlando di "workflow" nel senso
letterale del termine, giacchè esso riguarda
piuttosto veri e propri insiemi di applicazioni (anche
tecnologicamente disomogenee) che collaborano e interagiscono.
Il nostro, piuttosto, è un contesto meramente
applicativo, in cui il "flusso di lavoro"
agisce e si snoda all'interno di una singola applicazione.
E' proprio questo il tipo di situazione che ci accingiamo
a presentare. In questa prima parte, in particolare,
si discuterà dell'opportunità di adottare
un simile approccio e dei benefici che esso può
offrire, rimandando alla seconda parte una trattazione
più concreta dell'argomento, proprio per mostrarne
"sul campo" le potenzialità.
Le
Business Rules procedurali
Durante le fasi di progettazione e sviluppo di una applicazione,
ci si deve necessariamente confrontare anche con l'implementazione
dei requisiti di business, le cosiddette "Business
Rules", già oggetto di una trattazione specifica
su queste pagine (vedere [1]). Come descritto in quell'articolo,
si è visto che esse sono suddivisibili in diverse
categorie, a seconda del particolare carattere che assumono:
in particolare esse possono essere di tipo Strutturale,
Comportamentale, Derivativo e Procedurale, queste ultime
- sensibilmente più complesse - legate a tutte
quelle situazioni in cui il flusso applicativo segue
un andamento che passa attraverso un insieme di "task"
logicamente interconnessi tra di loro, eseguiti da "attori"
- automatici o meno - attivati secondo determinate regole
o "policies". Questo tipo di situazione, in
cui il flusso applicativo è asservito a un vero
e proprio "flusso di lavoro", suggerisce un
approccio diverso allo sviluppo di una applicazione
rispetto a come esso viene tradizionalmente pensato.
In questo caso infatti, si parla di "Process Oriented
Development" (POD nel seguito).
Il
POD come approccio allo sviluppo
Partiamo dall'inizio. Immaginando di adottare per lo
sviluppo della nostra applicazione la metodologia MDA
proposta da OMG (Model Driven Architecture, [2]), il
primo passo consiste nel costruire un modello che "catturi"
i soli aspetti di business (quello che in ambito MDA
viene definito PIM, Platform Independent Model). Il
PIM che dovremo costruire sarà poi modellato
ad hoc a seconda del tipo di applicazione che desideriamo
ottenere. In particolare, possiamo distinguere tre differenti
tipi di applicazioni, e precisamente:
-
Data Oriented, focalizzate su strutture di dati e
relativa manipolazione. Un PIM adatto a modellare
tali applicazioni sarà basato sugli UML Class
Diagram
- Service
Oriented, in cui l'obiettivo è fornire un insieme
di servizi. L'applicazione in questione è focalizzata
su caratteristiche comportamentali che vengono isolate
in servizi con basso livello di accoppiamento. Essi
normalmente cooperano l'uno con l'altro, scambiando
dati, ovvero coordinando e riutilizzando step semplici
in step più complessi.
- Process
Oriented, dedicate alla implementazione di processi
di business, in cui il processo è inteso come
insieme di attività organizzate in sequenza.
Nella
sottostante figura 1, viene riportata una rappresentazione
schematica dei tre tipi di applicazioni qui presentate.
Figura 1 - Applicazioni orientate a Dati, Servizi,
Processi
Come
evidenziato in figura, ciascuno dei tre tipi di applicazioni
appena descritte può servirsi di quelle - per
così dire - di livello immediatamente "antecedente".
Ad esempio, si nota come le applicazioni Service Oriented,
che sono meccanismi per modellare servizi, possano a
loro volta essere basate su manipolazioni semplici o
complesse di dati (ossia su applicazioni Data Oriented).
In questo caso, il nostro PIM conterrà un insieme
di regole per il collegamento logico di alcune sottoparti
di un Class Diagram. Un esempio? La nostra applicazione
Service Oriented vuole ottenere una "vista composita"
su un insieme di dati. Il nostro PIM sarà costituito
da un Class Diagram con in più la definizione
di un Servizio che aggrega alcune parti del Class Diagram
medesimo in una "vista logica". Come si traduce
tutto questo in termini di codice Java? Proviamo a pensare
al ben noto Pattern J2EE detto Session Façade
(descritto dettagliatamente in [3]), implementabile
impiegando un EJB (un Session Bean) che esegue la logica
applicativa e che funge, appunto, da "façade",
cioè da "facciata" nei confronti del
"presentation tier", esattamente come un proxy.
Tale Session Bean è poi connesso a un insieme
di Entity Bean responsabili di fornirgli i dati che
gli necessitano che vengono, per così dire, "aggregati"
a cura del Session Bean medesimo nella "vista composita"
richiesta, che viene poi inviata al "presentation
tier". Semplificando al massimo, il nostro Session
Bean può essere visto come la parte "mid
tier" di una piccola applicazione Service Oriented
che utilizza quanto elaborato dai diversi Entity Bean
coinvolti, ciascuno dei quali può essere visto
come una mini-applicazione Data Oriented. Nella figura
2, la schematizzazione di un semplice esempio di vista
aggregata "clienti e ordini".
Figura 2 - Esempio di Session Facade
Alla
stessa maniera, immaginando un processo di business
di una certa complessità, modellato come sequenza
di attività da assegnare a diversi "attori"
secondo determinate regole, non è sbagliato in
linea di principio supporre che esso possa essere costituito
da una collezione di Servizi, o meglio, di applicazioni
di tipo Service Oriented.
Qui però il Class Diagram corredato di eventuali
regole di aggregazione non basta più: quale formalismo
possiamo utilizzare per modellare un PIM destinato a
rappresentare applicazioni Process Oriented?
Activity
Diagrams
Come specificato in [4], gli Activity Diagrams permettono
di analizzare un sistema secondo le informazioni fornite
proprio dalla elaborazione dei diversi Use Case individuati
in fase iniziale, giacchè permettono di modellare
i flussi di lavoro che intercorrono tra di essi. Gli
Activity Diagrams sono estremamente utili, in quanto
permettono di spiegare a chi li legge quali sono le
condizioni necessarie perchè un Use Case sia
valido nonchè le condizioni, o gli stati, in
cui viene lasciato un sistema a fronte del completamento
di quel particolare Use Case. Nel Processo Unificato,
che è un processo iterativo (vedere anche [5]),
la fase di modellazione degli Activity Diagrams permette
di scoprire anche ulteriori Use Case che in precedenza
non erano stati presi in considerazione. Nella sottostante
figura 3, un esempio di Activity Diagram relativo alla
gestione delle chiamate in un ipotetico sistema CRM.
Figura 3 - Esempio di Activity Diagram
Osservando
la figura 3, si possono facilmente individuare gli elementi
di base di un Activity Diagram, e cioè:
-
Attività, che costituiscono i task del processo,
indicati in figura tramite rettangoli con angoli arrotondati
- Stati,
che indicano le varie condizioni o punti salienti
di un sistema, e che in figura 2 sono rappresentati
con quadratini recanti la denominazione del processo
modellato tramite quel diagramma ("Call"
nel caso in esame, a significare che si tratta del
processo di gestione delle chiamate nel sistema CRM)
- Transizioni,
destinate a rappresentare il flusso di controllo tra
stati e attività, ovvero tra le diverse attività,
e sono indicate con frecce
Gli
Activity Diagrams quindi costituiscono il mezzo più
idoneo a permetterci di modellare PIM destinati ad applicazioni
POD. Resta però da definire un punto: nel caso
in cui si abbiano transizioni multiple all'interno di
un processo rappresentato da un Activity Diagram, come
imporre le condizioni di percorrenza di un flusso piuttosto
che di un altro? Come formalizzarle? Secondo quali regole?
OCL:
Object Constraint Language
Sempre osservando con attenzione la figura 3, si nota
anche che, per ciascun ramo indicante una transizione,
è stato utilizzato un formalismo per esprimere
la condizione affinchè si passi proprio per quel
ramo. Tale formalismo fa parte di un linguaggio appositamente
messo a punto per esprimere vincoli tra i diversi oggetti
componenti un sistema. Se dalla frase appena detta estraiamo
i tre termini utilizzati "linguaggio", "vincoli"
e "oggetti" e li traduciamo in inglese, otteniamo
Object Constraint Language (abbreviato in OCL), che
è proprio il nome dato in ambito OMG a tale formalismo.
Senza entrare ulteriormente nei meriti di OCL, per il
quale si rimanda ad esempio a [4] ma anche a [6], qui
ci basta sapere che è una potente estensione
di UML che non modifica lo stato di un oggetto, ma piuttosto
indica le condizioni affinchè si verifichi un
tale passaggio di stato. Nel caso di applicazioni Process
Oriented, OCL è un mezzo estremamente potente
che ci permette di modellare pre e post-condizioni alle
funzionalità del sistema, così come i
cosiddetti invarianti, ossia condizioni che devono sempre
essere vere durante tutta la durata di vita del sistema
stesso.
Modelli
Organizzazionali
A questo punto, abbiamo individuato il contesto in cui
utilizzare l'approccio POD, sappiamo che occorre impiegare
gli UML Activity Diagrams e possiamo specificare le
diverse condizioni tramite il formalismo OCL. Cosa ci
manca ancora? Individuare i diversi attori coinvolti
nel Processo e assegnare a ciascuno di essi l'insieme
dei ruoli che competono loro. Questo significa sostanzialmente
che occorre definire ancora due cose, e cioè:
- Un
Modello Organizzazionale, cioè specificare
la propria organizzazione con le sue parti, i vari
attori, i possibili ruoli (la figura 4 fornisce un
esempio)
Figura 4 - Modello Organizzazionale
- Le
Policy, cioè associare in modo opportuno gli
attori a ciascuna parte della organizzazione e i ruoli
agli attori coinvolti (vedere un esempio in figura
4)
Figura 5 - Definizione Ruoli
POD vs BPM
Come abbiamo accennato nella introduzione, quando si
parla di POD si intende fornire un approccio basato
su UML e dintorni (OCL nel nostro caso), per modellare
applicazioni Process Oriented, in cui il flusso applicativo
possa essere disegnato come un vero e proprio workflow.
La parola workflow però, in questo specifico
contesto, non deve far pensare a problematiche di tipo
BPM (Business Process Management), rispetto alle quali
il posizionamento dell'approccio POD è completamente
diverso. Mentre infatti il focus dell'approccio BPM
è dedicato alla gestione e monitoring di processi
di business, e quindi aggiunge valore a livello business
management, POD è invece esplicitamente dedicato
allo sviluppo, e costituisce quindi uno strumento di
estrema potenza dedicato agli sviluppatori, giacchè
aggiunge valore a livello application development. BPM
viene utilizzato in contesti in cui i diversi task componenti
un determinato processo interagiscono con applicativi
differenti costruiti con tecnologie spesso variegate.
POD, per contro, è un insieme di task contenuti
all'interno dello scope di un'unica applicazione. Uno
strumento specificamente BPM inoltre, deve possedere
un Business Process Engine (ad esempio [7]), mentre,
nel nostro caso, il prodotto ultimo di un approccio
POD sarà una applicazione J2EE pronta per il
deployment su qualsiasi piattaforma, senza necessità
alcuna di Business Process Engine.
Conclusioni
In questa prima parte si è inquadrato il POD,
Process Oriented Development, come approccio alla modellazione
e sviluppo di applicazioni orientate al processo, in
cui i diversi elementi siano costituiti da differenti
task assegnati ad attori. Si è anche evidenziato
come POD e BPM siano approcci sostanzialmente diversi,
proprio in virtù del diverso livello cui aggiungono
valore (application development e business management,
rispettivamente). Focalizzando la nostra attenzione
su quelle applicazioni che per le quali è POD
l'approccio ideale, abbiamo poi preso in considerazione
i metodi e formalismi più idonei al nostro scopo,
e cioè gli Activity Diagrams di UML, laddove
i vari vincoli siano specificati tramite OCL. Completando
il tutto con una opportuna definizione del modello organizzazionale
in seno al quale nasce la applicazione POD e delle relative
Process Policies, abbiamo ora sul tavolo tutti gli ingredienti
necessari, e non resta quindi che procedere al loro
impiego, magari servendosi di un esempio pratico. Questo
è proprio ciò che vedremo nel prossimo
numero.
Bibliografia
[1]
Mokabyte -"Le Business Rules nelle Applicazioni
J2EE", http://www.mokabyte.it/2004/12/busrules.htm
[2]
Mokabyte - "Uso della Model Driven Architecture
nello Sviluppo di Applicazioni J2EE", parte 1 http://www.mokabyte.it/2004/07/mda-1.htm
e parte 2 http://www.mokabyte.it/2004/09/mda-2.htm)
[3]
Deepak Alur, John Crupi, Dan Malks - "Core J2EE
Patterns - Best Practices and Design Strategies",
Java 2 Platform Enterprise Edition Series, 2001
[4]
Jason T. Roff "Fondamenti di UML", McGraw
Hill
[5]
Mokabyte -"Il Processo Unificato nelle Applicazioni
J2EE", http://www.mokabyte.it/2005/05/rup.htm
[6]
UML Resource Page, http://www.uml.org/
[7]
Compuware UnifaceFlow - http://www.compuware.com/products/optimalflow/default.htm
Doriano Gallozzi è
nato a Roma nel 1964 e si è laureato in Ingegneria
Elettronica (indirizzo Informatica) nel 1989. Da sempre
interessato a problematiche di analisi, progettazione
e sviluppo di Sistemi Informativi, ha lavorato per diversi
anni in aziende del settore informatico italiano (gruppo
ENI, gruppo Telecom Italia), dove ha acquisito diverse
esperienze tanto nel campo della progettazione e sviluppo
del software (in ambiente M/F come in ambiente distribuito)
quanto nel campo dei RDBMS (DBA su diversi progetti
per clienti finali quali Telecom Italia). Da gennaio
2000 lavora nella Divisione Prevendita di Compuware
Italia. La sua attività verte principalmente
sulla piattaforma J2EE e tecnologie correlate, ma anche
su ambiti tecnologici quali l'Enterprise Application
Integration, i Portali Web, gli strumenti di Business
Process Management.
|