Introduzione
"Business as usual", ovvero Business sempre e comunque, come se si trattasse di qualcosa di abituale. Forse chi ha ideato questo modo di dire aveva in mente solo il Business in quanto tale, e non si è mai posto l'obiettivo di formalizzarne le regole. Con ogni probabilità non era un suo problema. Con elevata probabilità è il problema invece di molti di noi, che dobbiamo affrontare il Business con l'esigenza e la necessità di analizzarne i vari aspetti al fine di pervenire a corrette ed efficienti implementazioni. Questo è appunto l'argomento del presente articolo, le cosiddette "Business Rules", nella loro generalità e categorizzazione, cercando di estrarre tutti gli elementi necessari a passare dall'ambito Business "puro" all'ambito Business tecnologico e implementativo, quello in cui si decide come procedere avendo inquadrato in modo preciso cosa fare e perchè.

Le Business Rules: cosa sono e a che servono
Cominciamo con una semplice definizione: una Business Rule è qualcosa di orientato al business e ad esso dedicata.
Questa definizione, apparentemente così ovvia, non deve però ingannare.
Una Business Rule infatti, pur avendo un diretto impatto su aspetti tecnici e implementativi, si trova a monte di questi, che vengono poi espressi nei cosiddetti Business Requirements (requisiti di Business): ad esempio l'utilizzo di un certo DBMS, o le modalità di interazione con un determinato client.
Dal Business quindi le Business Rules come formalizzazione, poi l'analisi per arrivare ai Business Requirements e infine la scelta della implementazione che si considera più appropriata.
Il punto di partenza però richiede di affrontare il Business e raccogliere gli elementi caratterizzanti le Business Rules. Quali sono? Come descritto in dettaglio in rif.[1], una Business Rule viene espressa utilizzando elementi propri del mondo Business, e quindi:

• termini, ovvero sostantivi aventi un ben determinato e riconosciuto significato (per esempio un conto corrente è tale in quanto possiede un saldo)
• fatti, ovvero frasi che interconnettono termini tramite congiunzioni e preposizioni in un contesto significativo dal punto di vista del business (per esempio un cliente di una banca possiede almeno un conto corrente)
• regole, ovvero frasi complete che aggiungono valore in termini conoscitivi ovvero abilitano o disabilitano lo svolgersi di determinate azioni basandosi su contenuti conoscitivi (per esempio vincoli, condizioni o calcoli)

Tutto quanto detto può essere considerato un pò come l'insieme degli ingredienti base di una qualunque Business Rule, così come illustrato nella fig.1.

Figura 1 - Business Rules Taxonomy Tree

Come passo successivo, cerchiamo di evidenziare le principali proprietà di una Business Rule. Più precisamente, essa deve essere:

• Dichiarativa, ossia non procedurale. Non descrive i passi necessari ad ottenere un determinato risultato
• Atomica, ossia tale da essere applicabile ad un ben determinato aspetto del business senza poter essere ulteriormente suddivisa pena la perdita di significatività. Indivisibile, ma auto-contenuta e completa
• Esplicita, ossia tale da poter essere espressa tramite diagrammi UML (rif. [2]) o sfruttando linguaggi formali naturali, come ad esempio l'OCL (rif.[3])
• Orientata al business, ossia richiesta e definita per scopi dichiaratamente di business, non tecnici

Le Business Rules: categorie
Abbiamo fin qui illustrato caratteristiche e proprietà delle Business Rules. A questo punto, possiamo anche presentarne una suddivisione in categorie.
Più in dettaglio, le Business Rules possono essere di tipo:

• Strutturale, quando descrivono elementi strutturali del business, e collegano tra loro dei termini. Un esempio potrebbe essere "Un cliente possiede un indirizzo"
• Comportamentale, in quanto orientate ad aspetti comportamentali del business. Ne esistono diversi sottotipi, in particolare:
  • Condizioni, predicati che determinano l'esecuzione di altri predicati
  • Vincoli di Integrità, proprietà che devono essere sempre verificate
  • Autorizzazioni, privilegi che possono essere applicati ad uno o più elementi del business
• Derivativo, se descrivono aspetti del Business derivati da altri, ovvero da elaborazioni. In tal senso, possono essere pensate come derivate dalle rule strutturali, ovvero da quelle comportamentali
• Procedurale, se si tratta di quei determinati aspetti del Business generalmente formalizzati nei cosiddetti "Use Case". In questo caso esse possono essere implementate tramite meccanismi e regole di navigazione, autenticazione/autorizzazione e anche messaging

Nella figura 2 una ricapitolazione schematica dei tipi base delle Business Rules.

Figura 2 - Tipi di Business Rules

Implementare le Business Rules: dove, quando, come?
Prima di domandarsi come affrontare il problema della implementazione di una Business Rule - passaggio dagli aspetti tipici del Business ad aspetti tecnici - occorre porsi il problema di dove e quando implementarla, e non è affatto un aspetto banale, anche perchè si tratta di qualcosa che influenza molto l'implementazione tecnica stessa.
Quando e dove una Business Rule deve agire significa definirne i due parametri cosiddetti "moment" e "level".
Un esempio potrà servire a chiarire meglio il tutto.

Si immagini che per implementare la nostra Business Rule si richieda che un determinato campo sulla user interface (un campo di una JSP, tanto per fissare le idee) debba contenere dati conformi a un determinato formato (ad esempio un codice fiscale deve avere i primi 3 caratteri formati da consonanti del cognome, i successivi 3 consonanti del nome ecc.).
Domandiamoci se la validazione debba avvenire immediatamente, ossia direttamente sulla JSP o in una fase successiva, ad esempio a cura di un EJB dedicato a tale scopo.
Decidere "quando" validare tale campo (cioè in modalità "immediata" -sulla JSP - o in modalità "differita" - sull'EJB tier) significa focalizzare alcuni aspetti decisivi per scegliere l'implementazione più appropriata.
Nel primo caso si potrebbe pensare ad un semplice frammento di JavaScript da inserire nella JSP, mentre nel secondo caso potremmo pensare a qualcosa di più sofisticato, ad esempio una espressione regolare implementata in un Business Method di un componente EJB.
Qual'è la scelta migliore? Nessuna ed entrambe, perchè entrambe presentano aspetti positivi e negativi.
Il JavaScript processa con notevole rapidità i dati da esaminare, ma in tal modo si ottiene un'applicazione client-dependent: nel caso in cui si renda necessario cambiare la GUI da JSP a Swing, ad esempio, tutto l'eventuale JavaScript "immerso" nelle JSP va perduto.
Nella seconda ipotesi (EJB tier) il risultato rende la procedura di validazione immune da modifiche sulla GUI, ma richiede altresì, per tale validazione, che l'intero contenuto della form di input venga inviato all'EJB tier, con conseguente maggiore lentezza del processo complessivo.
Notiamo come, avendo messo a confronto due differenti "moment" della business rule, si è pervenuti a due differenti possibili implementazioni, sensibilmente diverse tra loro.

Figura 3 - Moment di una Business Rule

Un altro aspetto da tenere in adeguata considerazione riguarda il cosiddetto "level", ossia a quale livello di dettaglio dobbiamo spingere l'effetto della nostra implementazione (quello che si dice lo "scope" di una Business Rule).
Precisamente, quanti e quali elementi saranno coinvolti nella nostra implementazione? Un semplice campo in una JSP (e quindi probabilmente un attributo di una tabella in un DBMS, come nel caso dell'esempio precedente), o piuttosto un insieme di valori, ad esempio gruppi di attributi combinati tra di loro secondo determinati criteri?
Facciamo un esempio. L'implementazione della nostra Rule richiede di valorizzare un ipotetico campo "stato civile" di una serie di informazioni in un sistema anagrafico con il valore "coniugato/a". Come impatto avremo, in caso di cittadino di sesso femminile, che sarà necessario anche modificare anche il suo cognome aggiungendo quello del marito.

Figura 4 - Level di una Business Rule

Individuare correttamente "moment" e "level" è molto importante, ma può non bastare ancora a decidere l'implementazione più idonea di una Business Rule.
Altri elementi che devono necessariamente essere tenuti in considerazione sono infatti i seguenti:

• Stabilità - la Rule è soggetta a frequenti cambiamenti?
• Riusabilità - la Rule può essere riapplicata ad altri oggetti di business?
• Portabilità - l'implementazione scelta rende la Rule portabile?

Un esempio
Un esempio concreto potrà aiutare a chiarire meglio i vari concetti sin qui presentati.
Immaginiamo di avere l'esigenza di voler conoscere, in un sistema di CRM, quanto tempo impiegano mediamente le chiamate effettuate dai clienti ad essere risolte.
Il Class Diagram di tale sistema è riportato nella figura 5.
Immaginiamo che l'implementazione preesistente di questo sistema preveda le chiamate (Call in fig.5) come parti aggregate (composizione) di ciascun cliente (Customer in fig.5), e sia quindi necessario, per arrivare alle informazioni sulle chiamate, navigare su ciascuna istanza di Customer,

Figura 5 - Class Diagram Sistema CRM

Cerchiamo di frenare la nostra tentazione di incalliti sviluppatori e scrivere immediatamente il codice, e facciamo qualche considerazione preventiva.
Dove dovrà operare la nostra Rule? Direttamente sul front end? Probabilmente no, dato che dovrà effettuare calcoli di tipo quasi statistico su insiemi di dati preesistenti, perciò - si suppone - provenienti da un repository (un DBMS).
Dovrà poi lavorare su diverse istanze di dati dei vari clienti memorizzati nel sistema, poichè per ciascuna istanza di cliente (Customer) dovrà analizzarne le chiamate (Call) individuando quelle effettuate e risolte.
Magari si desidera anche che l'implementazione scelta mantenga un certo grado di flessibilità ai cambiamenti e sia quanto più possibile riutilizzabile, anche da altre implementazioni di altre Business Rules.
Il calcolo della differenza tra le date potrebbe essere implementato con il seguente frammento di codice:

long factorMilliSec = 60000*60*24; // trasforma un giorno in millisecondi
return(long)((toDate.getTime()-fromDate.getTime())/(factorMilliSec));

e tale frammento, che potremmo chiamare timeDifference, potrebbe essere inserito in una apposita libreria che funge da repository, proprio al fine di promuoverne la futura riutilizzabilità da parte di altre componenti della nostra applicazione.

Utilizzando ad esempio lo strumento Compuware OptimalJ (rif.[4]), possiamo definire una libreria cosiddetta di espressioni di business e denominarla crmrules. In essa inseriremo, come modulo componente, anche il frammento timeDifference di cui sopra

Figura 6 - Business Expression Librar
(clicca sull'immagine per ingrandire)

A questo punto, è sufficiente modellare un Business Method sull'Entity Bean del Cliente (classe CustomerBean.java nel nostro caso) e inserirvi dentro una chiamata alla parte di codice (timeDifference) messa a disposizione dalla libreria di espressioni crmrules.
Il Business Method completo potrebbe essere il seguente:

java.util.Date today = new java.util.Date(); //imposta data di oggi
int counter=0;
for (Iterator i=callColl.iterator();i.hasNext();) {
CallData callBrowse = (CallData) i.next(); //ciclo chiamate ciascun cliente
if (resolved==callBrowse.getCallResolved()) { //selezione chiamate risolte
counter++;
returnValue = returnValue +
Crmrules.timeDifference(callBrowse.getCallTimestamp(),today);
}
}
if (counter == 0) // gestione divisione per zero
returnValue = 0;
else
returnValue = (long)returnValue/counter; // valore medio

return returnValue;

Nella figura 7 viene riportato come appare questo tipo di implementazione in OptimalJ. Il Business Method è stato denominato averageAgeCall e appartiene all'Entity Bean CustomerBean.java

Figura 7 - Utilizzo in un Entity Bean di una Business Expression
(clicca sull'immagine per ingrandire)

Nell'esempio appena presentato abbiamo affrontato la problematica di implementazione della Business Rule proponendo, tra le varie possibili, una soluzione indipendente dal client, eseguita sull'EJB tier e codificata in modo estremamente flessibile, giacchè una parte del codice scritto è stato inserito in un repository di espressioni riutilizzabili.

Ancora più veloci? Le Business Rules dinamiche
Per quanto possa essere accessibile il codice che inseriamo in una libreria comune, se la nostra applicazione si trova in esercizio e occorre modificare qualcosa, è necessario apportare la modifica sul sorgente, ricompilare, preparare nuovamente il package EAR (Enterprise Archive Repository) e ripetere nuovamente tutta la procedura di deployment, e ciò anche se la modifica da fare è molto piccola.
Consideriamo ad esempio il seguente minuscolo frammento di codice Java, che potrebbe chiamarsi checkLimit all'interno di una libreria di espressioni rules come quelle viste più sopra:

boolean b = false;
if(totalPrice > 100000) {
b = true;
}
return b;

La nostra applicazione si trova in esercizio e il nostro utente ci comunica che la soglia affinchè la variabile b divenga true deve valere 200000, perchè sono cambiate le regole del Business! Proviamo ad immaginare quanto tempo ci costa apportare la modifica richiesta sul codice e rimettere tutto in esercizio. Il primo passo ci costa pochissimo, il secondo decisamente troppo.
Come fare allora?
Semplice: rendere il frammento checkLimit dinamico. A tale scopo, basta valorizzarne opportunamente una delle proprietà, il cosiddetto flag dynamic.

Quando il flag dynamic vale false (valore di default), OptimalJ genera una classe Java che ha il nome della libreria di espressioni e contiene al suo interno il codice di ciascuna di esse.
Nel nostro caso ad esempio, la classe Java generata si chiama Rules.java e contiene il frammento di codice checkLimit (figura 8)

Figura 8 -Business Expression statiche
(clicca sull'immagine per ingrandire)

Se ora il flag viene posto a true, il frammento di codice viene tradotto in un file XML che può essere "allegato" alla applicazione da mettere in esercizio. Tramite una ulteriore facility di OptimalJ, denominata Business Expression Server, il contenuto di tale file XML viene letto ogni 10 secondi, e non è difficile immaginare che modifiche come quella sopra menzionata saranno attuabili in modo immediato, perchè richiederanno semplicemente di modificare il file di testo XML.
In figura 9, dettaglio del file XML relativo al frammento checkLimit

Figura 9 -Business Expression dinamiche
(clicca sull'immagine per ingrandire)

Si può notare come in questo caso i tempi di maintenance e re-deploy saranno letteralmente annullati.

Conclusioni
Le Business Rules rappresentano il punto, estremamente critico, in cui occorre acquisire informazioni e elementi provenienti dall'ambito Business e indirizzarli verso l'ambito requisiti tecnici, per giungere a una corretta e accorta implementazione. Proprio a tal fine, a monte di questo processo, occorre focalizzare quegli aspetti atti a guidarci attraverso la scelta della implementazione più idonea tra le varie possibili. Ecco quindi che quando la nostra Business Rule opererà, su quali informazioni agirà, quanto dovrà essere flessibile ai cambiamenti saranno alcuni degli elementi da inquadrare, e con la massima precisione possibile. Velocizzare la risposta ai cambiamenti è un obiettivo di primaria importanza, anche e soprattutto in un mondo tecnologico in continua e costante evoluzione, dove il Time-to-market spesso fa la differenza tra un successo e un fallimento.

Bibliografia

[1] Compuware Lab "HowBusiness Rules enable rapid response to change" - online pdf copy su http://javacentral.compuware.com/members/downloads/whitepapers.htm

[2] Object Management Group UML Resource Page- http://www.uml.org/

[3] Jos Warmer, Anneke Kleppe "The Object Constraint Language Second Edition: Getting Your Models Ready for MDA", Booch Jacobson Rumbaugh - Addison Wesley

[4] Compuware Lab "OptimalJ Community" - http://javacentral.compuware.com

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 collaborato per diversi anni con 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 collabora con la 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 Modeling.