Process Oriented Development: il processo alla base dello sviluppo

I parte: un approccio diverso ai requisiti di businessdi

Sviluppo orientato ai processi: modellare processi per modellare applicazioni. Il workflow aggiunge valore allo sviluppo.

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.

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

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.

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)

  • 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 5)

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.

Riferimenti bibliografici

[1]
"Le Business Rules nelle Applicazioni J2EE"
http://www.mokabyte.it/2004/12/busrules.htm

[2]
"Uso della Model Driven Architecture nello Sviluppo di Applicazioni J2EE"
http://www.mokabyte.it/2004/07/mda-1.htm
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]
"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

Condividi

Pubblicato nel numero
100 ottobre 2005
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…
Articoli nella stessa serie
Ti potrebbe interessare anche