UML Activity Diagrams, OCL, Strutture Organizzative e Process Policies per arrivare a un modello di business completo e coerente: non resta che utilizzare questi ingredienti per arrivare a una applicazione J2EE pronta per la messa in produzione

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).

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.

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

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:

 dsml:dsml xmlns_dsml="http://www.dsml.org/DSML">top domain organization test top organizationalUnit Acme top organizationalRole Manager top organizationalUnit Professional Services 

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.

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.

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).

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.

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.

Riferimenti

[1] Doriano Gallozzi “Process Oriented Development – parte 1”
https://www.mokabyte.it/2004/12/busrules.htm

[2] “Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE”, parte 1
https://www.mokabyte.it/2004/07/mda-1.htm

[3] Jason T. Roff “Fondamenti di UML”, McGraw Hill

[4] Compuware OptimalJ
http://www.compuware.com/products/optimalj/

[5] “Scegliamo SOA per la nostra Infrastruttura Enterprise”
https://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

[7] “Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE”, parte 2
https://www.mokabyte.it/2004/09/mda-2.htm