Introduzione
Nella prima parte di questo articolo ([1]) abbiamo introdotto l'approccio cosiddetto Process Oriented, orientato a quelle applicazioni che lasciano intravedere, al loro interno, un vero e proprio "flusso di lavoro", ossia un insieme di task, svolti da un insieme di attori, cui è assegnato un insieme di ruoli. Si è evidenziato anche come, servendosi per lo sviluppo dei modelli previsti da MDA ([2]), il formalismo più idoneo a costruire un PIM destinato a contenere tutti gli ingredienti necessari e sufficienti a garantire un approccio Process Oriented sia costituito dagli UML Activity Diagrams ([3]), adatti proprio in quanto in grado di rappresentare efficacemente i "flussi di lavoro" che intercorrono tra i task individuati all'interno della nostra applicazione. Laddove poi si ritenga necessario intervenire imponendo vincoli nell'ambito dei nostri Activity Diagrams - ad esempio per "forzare" il passaggio attraverso un ramo piuttosto che un altro - si utilizzerà quella potente estensione dell'UML costituita dall'OCL (Object Constraint Language). Se infine aggiungiamo la possibilità di definire ruoli e attori e di combinarli nell'ambito di un modello di struttura organizzativa secondo opportune "policy" abbiamo tutti gli ingredienti che ci occorrono, e possiamo senz'altro rivolgere la nostra attenzione a un caso concreto.

Business Case
L'applicazione che ci accingiamo a sviluppare deve gestire le chiamate all'interno di un semplice sistema di CRM, per il quale immaginiamo di aver disegnato il Class Diagram di figura 1. Esso è costituito dalle tre classi Customer (il cliente oggetto del sistema), Call (le chiamate effettuate associate ai clienti registrati) e ServiceAgreement (livello di servizio assegnato a ciascun cliente).

Figura 1 - Class Diagram del sistema CRM

Il nostro business case prevede che quando arriva una chiamata da parte di un cliente (Customer) al sistema, essa venga processata via email, tramite telefonata o a cura di un tecnico a seconda del livello di servizio del cliente chiamante. In seguito a tale processamento, la soluzione prescelta verrà individuata e attuata, con la conseguente successiva chiusura della chiamata.

Tutto quanto abbiamo detto può pertanto essere rappresentato mediante l'Activity Diagram di figura 2.

Figura 2 - Process Model del sistema CRM

Come si può notare dalla figura 2, è necessario imporre una condizione affinchè venga percorso un ramo piuttosto che un altro dopo l'activity Assess Severity. Tali condizioni possono essere viste come vincoli sul diverso livello di "service agreement" (serviceLevel) associato al cliente chiamante, e possono quindi essere implementate servendosi del linguaggio formale OCL nel modo seguente:

customer.serviceAgreement.serviceLevel =
crm::domain::class::ServiceLevelEnum::SILVER
customer.serviceAgreement.serviceLevel =
crm::domain::class::ServiceLevelEnum::GOLD

In generale quindi, OCL ci permette di gestire il flusso di lavoro all'interno della nostra applicazione facendo in modo che segua un cammino piuttosto che un altro.
Quale saranno i prossimi passi? Prima di tutto costruire un modello di struttura organizzativa, con le rispettive unità, attori e ruoli. Successivamente sarà necessario definire le cosiddette Process Policies, ossie le "regole di ingaggio" dei vari attori - con i rispettivi ruoli - all'interno del nostro processo.

Struttura Organizzativa
Il modello della nostra Organizzazione sarà un insieme di dati JNDI-compliant (non dimentichiamoci che il prodotto ultimo del nostro lavoro sarà una applicazione J2EE). Nel caso del tool che stiamo impiegando per lo sviluppo del nostro esempio (Compuware OptimalJ [4]), le informazioni JNDI in questione vengono memorizzate in file DSML contenuti nella nostra user directory, e possono - se richiesto - essere anche essere messe a disposizione di un LDAP server, al fine di centralizzarne la gestione.
Definiamo quindi la nostra organizzazione, denominata ACME (la fantasia non è il nostro forte, è vero....) contenente i seguenti dipartimenti (altrimenti detti Unit):

• Technical Support
  
• Professional Services

Definiamo poi i seguenti ruoli:

• Manager
  
• SupportEngineer
  
• Consultant

Figura 3 - Modellare l'Organizzazione

In figura 3 il wizard di definizione della struttura, in cui si può notare che si fa riferimento a un file denominato Hierarchy.xml contenente proprio la struttura che stiamo modellando, e di cui viene riportato qui sotto un frammento:

<?xml version="1.0" encoding="utf-8" ?>
- <dsml:dsml xmlns:dsml="http://www.dsml.org/DSML">
- <dsml:directory-entries>
- <dsml:entry dn="dc=test,dc=com">
- <dsml:objectclass>
<dsml:oc-value>top</dsml:oc-value>
<dsml:oc-value>domain</dsml:oc-value>
<dsml:oc-value>organization</dsml:oc-value>
</dsml:objectclass>
- <dsml:attr name="dc">
<dsml:value>test</dsml:value>
</dsml:attr>
</dsml:entry>
- <dsml:entry dn="ou=Acme,dc=test,dc=com">
- <dsml:objectclass>
<dsml:oc-value>top</dsml:oc-value>
<dsml:oc-value>organizationalUnit</dsml:oc-value>
</dsml:objectclass>
- <dsml:attr name="ou">
<dsml:value>Acme</dsml:value>
</dsml:attr>
</dsml:entry>
- <dsml:entry dn="cn=Manager,ou=Acme,dc=test,dc=com">
- <dsml:objectclass>
<dsml:oc-value>top</dsml:oc-value>
<dsml:oc-value>organizationalRole</dsml:oc-value>
</dsml:objectclass>
- <dsml:attr name="cn">
<dsml:value>Manager</dsml:value>
</dsml:attr>
</dsml:entry>
- <dsml:entry dn="ou=Professional Services,ou=Acme,dc=test,dc=com">
- <dsml:objectclass>
<dsml:oc-value>top</dsml:oc-value>
<dsml:oc-value>organizationalUnit</dsml:oc-value>
</dsml:objectclass>
- <dsml:attr name="ou">
<dsml:value>Professional Services</dsml:value>
</dsml:attr>
</dsml:entry>
...........................................................

Definiamo ora 3 attori, e precisamente:

• Emily Malin
  
• Thomas Smith
  
• Roger Carroll

E infine le seguenti regole di assegnazione dei ruoli agli attori:

• Emily è il Manager delle unit Professional Services e Technical Support
  
• Thomas è un SupportEngineer nella unit Technical Support
  
• Roger è un Consultant nella unit Professional Services

In figura 4 i vari wizard impiegati per per operazioni sopra presentate.

Figura 4 - Definizione di Ruoli e Attori

Anche in questo caso le diverse informazioni sono state inserite in un file DSML denominato People.xml, analogo al precedente Hierarchy.xml, ma destinato a contenere anche la mappatura tra gli attori appena definiti e i corrispondenti ruoli all'interno della Organizzazione. L'ultima cosa che manca è assegnare gli attori alle diverse attività (task) del processo, ossia definire le Process Policies.

Process Policies
In generale possiamo definire "policy" una combinazione di un privilegio (ad esempio di lettura o esecuzione o scrittura) con una regola che definisce a chi assegnare tale privilegio. Nel caso del nostro esempio, dichiariamo le seguenti "policy" (le diverse attività indicate fanno riferimento alla figura 2):

• ProcessInitiation-tutti gli impiegati del Technical Support possono raccogliere una chiamata.
  
• AssessSeverity- tutti gli impiegati del Technical Support possono determinare la priorità di una chiamata, basandosi sul valore del serviceLevel
  
• Email-un SupportEngineer può inviare una email di supporto
  
• Telephone-un SupportEngineer può effettuare supporto telefonico
  
• SendEngineer-il Manager della unit Professional Services può inviare un Consultant presso un cliente
  
• DescribeSolution-un Consultant oppure un SupportEngineer può occuparsi della individuazione e descrizione della soluzione per una chiamata
  
• ResolveCall- un Consultant oppure un SupportEngineer può chiudere una chiamata "marcandola" come "risolta"

Per definire le Process Policies ci serviamo del Process Policies Explorer. Nella figura 5 l'editing delle policy relative al task SendEngineer.

Figura 5 - Process Policies

Deployment
A questo punto, possiamo dire che il nostro PIM (Platform Independent Model) è completamente definito e contiene anche tutti gli elementi necessari a definire la parte processuale della nostra applicazione, comprese le parti relative alla organizzazie completate dalle diverse Process Policies. Secondo la metodologia MDA, il nostro modello di business ci permette di derivare i successivi PSM (Platform Specific Model) e, come ultimo step, di costruire tutto il codice Java che costituisce l'applicazione J2EE finale (figura 6).

Figura 6 - PIM Process Oriented in ambito MDA

Non serve altro che compilare tale applicazione ed effettuarne il deployment. Essa offrirà una interfaccia web-based in cui sarà possibile visualizzare un link (tasklist) che permetterà l'accesso - secondo le credenziali utente specificate quando si sono definiti i diversi attori - ai task del processo. In figura 7 la tasklist in questione e l'accesso di Emily, il quale appartenendo alla unit Technical Support (ne è il Manager) possiede i diritti di ProcessInitiation (hyperlink start sulla sua tasklist) e può quindi far partire materialmente il processo di raccolta e gestione chiamate.

Figura 7 - Deployment della Tasklist

POD e SOA
Un'ultima considerazione prima di chiudere l'argomento. Si parla molto di SOA in questi tempi, in quei contesti in cui si discute di applicazioni focalizzate al Servizio (vedere anche [5] e [6]). Come si pone l'approccio POD rispetto a SOA? A ben guardare, SOA pone l'accento sull'importanza di realizzare Servizi, ma da sola non riesce a coprire completamente la complessità intrinseca che deriva dallo sviluppo di tali applicazioni; l'approccio POD, per contro, offre agli sviluppatori un mezzo rapido e coerente per assemblare in modo logico il flusso che intercorre tra i diversi Servizi e far confluire il tutto in una applicazione completa e funzionante, come nell'esempio trattato in questo articolo. POD cioè interviene a completare quanto messo a punto e raccolto da SOA, proprio in virtù di questa caratteristica di "collante" tra i vari Servizi. L'approccio POD, cioè, è focalizzato sia su "cosa" sia su "come", proprio perchè si tratta di un approccio "architetturale applicativo" e non di una "architettura di integrazione".

Conclusioni
In questa seconda parte dell'articolo dedicato alle applicazioni Process Oriented, l'intento era quello di illustrare quanto presentato nel numero precedente servendosi di un esempio pratico semplice ma - ci auguriamo - sufficientemente significativo. Sviluppando applicazioni J2EE con la metodologia MDA, l'approccio POD viene visto come un modo per arricchire e completare il PIM servendosi degli UML Activity Diagram estesi con l'OCL. Tutto ciò costituisce una solida base su cui costruire applicazioni J2EE pronte per il deployment, in cui gli aspetti process oriented sono stati completamente "catturati" nel modello PIM, che essendo indipendente dalla tecnologia, resta valido e stabile per qualsiasi futura attività di manutenzione evolutiva e correttiva.

Bibliografia
[1] Mokabyte -"Process Oriented Development - parte 1", 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] Jason T. Roff "Fondamenti di UML", McGraw Hill
[4] Compuware OptimalJ - http://www.compuware.com/products/optimalj/
[5] Mokabyte -"Scegliamo SOA per la nostra Infrastruttura Enterprise" http://www.mokabyte.it/2005/07/soamda.htm
[6] M. Blechar, M. Hotle "ARAD Methods and Tools: Improve Productivity and ROI" - Gartner Group, october 11, 2004

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.