IL PROBLEMA

Un cliente ci ha chiesto lo sviluppo di un sistema per consentire ai suoi clienti B2B di configurare il prodotto prima di metterlo in ordine.

I Prodotti acquistabili sono divisi in parecchie famiglie e, trattandosi di regolatori per il flusso dei GAS, i criteri di selezione degli attributi dipendono da formule fisiche e chimiche complesse.

Inoltre il numero di opzioni richieste all’utente sono molto variabili da prodotto a prodotto.

Le competenze per la configurazione sono derivanti da anni di esperienza e risiedono in poche persone dello staff del cliente.

Le configurazioni possono cambiare nel tempo ed affinarsi man mano che si eseguono test sui regolatori.

APPROCCIO STANDARD

Sviluppo procedurale di un albero di configurazioni per ogni prodotto. Realizzazione di una interfaccia utente specifica.

Pro: forte customizzazione per ogni prodotto del configuratore

Contro:

• Scarsa flessibilità: il cambio di una sequenza di opzioni può invalidare quanto già sviluppato.
• Tempi di sviluppo lineari con il numero di prodotti da configurare (a regime si ipotizza 2 mesi per configuratore)
• Nessuna autonomia dal personale sviluppatore
• Codice poco modulare: ogni configuratore è a sé e modifiche di politiche generali implicano cambi di tutti i configuratori.
• Tempi lunghi di analisi perchè gli sviluppatori della applicazione, esterni allo staff del cliente (noi) hanno nulle competenze nell’ambito dei prodotti del cliente.

APPROCCIO FIGO!

Una bella applicazione web che si auto-configura parlando con un motore di regole.

Cos’è un motore di regole : Eccolo qui wikipedia

Pro:

• Forte flessibilità: un motore di regole è dichiarativo,risulta quindi semplice aggiungere regole che alterino il flusso delle domande in un qualunque punto della esecuzione senza perdere coerenza nel tutto
• Autonomia del cliente, previa formazione sul motore di regole
• Le regole di business sono sono molto più vicine alla logica con la quale il cliente ragiona che non ad una di programmazione
• Una applicazione come quella disegnata apre la possibilità di estendere logiche complesse anche su piattaforme differenti con un effort di sviluppo non lineare con il numero e la complessità dei prodotti configurati

Contro:

• Interfaccia standard: L’interfaccia del configuratore deve essere resa standard, è necessario uno studi di usabilità preciso che valga per tutte le interazioni necessarie per la configurazione di modelli differenti

beh, se avessi convito il cliente a seguire la prima strada avremmo avuto lavoro per anni. Non l’ho convinto 😉

COME ABBIAMO IMPLEMENTATO LA APPLICAZIONE

Scelta tecnologica:

Abbiamo scelto DROOLS Rule Engine della JBOSS community

Perchè?

• E’ open source
• Ha una interfaccia per il designer delle regole che per quanto bruttina e non del tutto solida è meglio della configurazione di XML per l’utente Business
• Consente l’utilizzo di regole anche da sistemi di WorkFlow come ad esempio Jboss JBPM o Bonita
• E’ in Java. Questo permette di ipotizzare il suo utilizzo anche i piattaforme Android. Ed è il linguaggio che conosciamo meglio

STRUTTURA DEL PROGETTO

Una applicazione JAVA che contenga il motore di DROOLS, si occupi di pilotarne la esecuzione su set di regole differenti a seconda del prodotto da configurare.

Ogni modello di Drools deve definire una serie di Oggetti e devono essere istanziati (Asserted) dalle regole di Drools così che la applicazione JAVA possa elencarli e quindi configurarsi.

I tipi di oggetto che abbiamo definito come standard sono:

• Opzioni
• Variabili
• Messaggi

Il modello di Drools genera le opzioni che devono essere mostrate all’utente, la applicazione Java li trasforma in richieste (Scelta singola, campo di input etc)

Ogni volta che una opzione è scelta, Java genera una Variabile nell’area di memoria di Drools che così può rispondere con altre opzioni.

In figura mostro un esempio di regola di tipo DECISION table che specifica tutte le prime opzioni necessarie per la configurazione . In questa figura sono opzioni di tipo a scelta singola

Nella seguente del tipo inserisci valore:

In questa si vede che per un tipo TEXTBOX possiamo anche definire dei Default che poi verranno processati dalla applicazione per essere proposti nel campo di testo.

GESTIONE DEGLI ERRORI

Ipotiziamo che uno dei textbox richieda la data di nascita.

Drools genera un oggetto Opzione (nome: “data di nascita”, tipo: “textbox” )

La applicazione java lo legge e mostra un campo del tipo

data di nascita : ____________

all’inserimento la app scrive in Drools un oggetto Variabile (nome:”data di nascita”, valore:”31/11/2024″)

A questo punto una regola dice

Se esiste un oggetto $v= Variabile(  nome= “data di nascita” , valore > oggi )

allora

• crea (assert) oggetto Messaggio (testo: “la data di nascita deve essere antecedente a oggi”)
• rimuovi (retract) $v.

Più semplice di così.

questo un esempio di regola .

PRIMA BOZZA DELLA APPLICAZIONE

EDIT – 20-11-14

Se interessa vedere altre evoluzioni della applicazione ecco qui un altro post sull’argomento “Gestire un motore di regole in modo umano”