Che cosa è la BBT

La BBT RulesEngine è un ambiente per lo sviluppo di applicazioni basate su Modelli di Conoscenza, composti da oggetti e da regole (decision and validity) che li relazionano.
E' dotata di un "rule engine"che si occupa di attivare le regole quando necessario.

Gli esperti del problema definiscono le regole senza doversi curare di quando queste regole debbano essere attivate, sarà il rule engine che si farà carico di attivare le regole giuste al momento giusto. Questa funzionalità permette di svincolare la creazione e la gestione delle regole dal contesto applicativo facilitando enormemente l'attività di manutenzione.

 

 

 

Terminologia della BBT

Box: è il modello di conoscenza;

Elements: sono gli oggetti definiti all' interno del Box;

Properties: proprietà degli elementi;

Validity rules: regole di validità. Sempre attive in fase di utilizzo dell' applicazione, hanno l' obiettivo di restringere il campo di scelta delle possibili soluzioni;

Decision rules: regole di decisione. Attivate su richiesta, hanno l' obiettivo di valorizzare elementi in base al contesto e, di conseguenza, accelerare il percorso verso le possibili soluzioni;

BBT Methods: metodi propri della BBT che consentono di cooperare con l' Engine della BBT;

User Methods: sono procedure in parte standard (in dotazione alla BBT) ed in parte scritte dall' utente per risolvere problematiche particolari;

Sheet: contenitore di oggetti. Il loro obiettivo è creare ordini all' interno del Box;

 

WEB Pages: sono le pagine costruite in automatico dalla BBT per la definizione dell' interfaccia utente;

I componenti principali

Box: è il modello di conoscenza. Di fatto l' archivio che memorizza gli oggetti, le regole che li relazionano e le pagine WEB che definiscono l' interfccia utente;

Rule Engine: è il motore inferenziale. Il suo principale lavoro è quello di attivare la Knowledge Base, quando richiesto, per fornire riposte alle richieste e gestirne le interazioni con la Web-Interface;

BBW-UI: applicativo Web che consente la costruzione del Box. Permette di creare gli oggetti, le decision rules, le validity rules, la user  interface (tecnologia Web) e i metodi richiesti per personalizzare l' applicazione utente;

Engine-DLL: mette a disposizione dell' utente esperto le primitive più significative dell' Engine;

BBProcedures.dll: metodi utili per la gestione della User Experience e non solo, accessibili sia all' utenza che sviluppa customizzazioni che all' utenza che si limita alla sola costruzione/gestione del Box;;

Web-MVC Controls: libreria di controlli predefiniti per la costruzione delle pagine WEB necessarie alla User Interface;

Template C#-MVC: progetto preimpostato per lo sviluppo dell' Applicazione. Il progetto può prevedere DLL customizzate che operano sugli elementi della BOX e CSS personalizzati per migliorare la grafica delle pagine;

 

I connettori

Con il termine connettore identifichiamo una DLL che viene resa disponibile nell' ambiente BBT e che consente di integrare questo ambiente ad altri quali ad es. il CRM.

I connettori disponibili sono:

SQL connector: questa libreria consente di utilizzare l' ambiente SQL sia per la storicizzazione delle informazioni utilizzate dall' applicazione che per il recupero di eventuali informazioni come ad es. i Listini piuttosto che le Anagrafiche .....;

Sugar CRM connector: l' ambiente Sugar gestisce tutte le informazioni commerciali e l' ambiente BBT gestisce la configurazione. In ambiente Sugar CRM si crea l' Offerta, quindi si richiama il Configuratore (BBT) per compilarla e valorizzarla: il Configuratore acquisisce tutte le informazioni commerciali necessarie (info commerciali del Cliente, listini di vendita, condizioni commercialidi vendita, ....), configura l' offerta in base alle regole definite sul proprio modello e ritorna i risultati al CRM che stampa ed invia l' offerta. La parte di acquisizione info dal CRM non richiede scrittura di metodi customizzati in quanto completamente implementata all' interno della BBT;

Solidworks connector: nel momento in cui dispongo di tutti i modelli 3D dei componenti che consentono, ad es., di costruire una famiglia di macchine, questo connettore consente alla BBT di creare il Modello 3D della macchina configurata o di modificare lo stesso modello a seguito di una modifica della configurazione. Ovviamente a questo punto si aprono scenari più che mai interessanti;

 

Lo sviluppo di un progetto in ambiente BBT

L' immagine che segue schematizza lo sviluppo di un progetto in ambiente BBT.

 

 

Vediamo come entra in gioco la BBT nelle varie fasi del progetto:

Analisi

A meno dei primi incontri in cui si definisce sostanzialmente l' obiettivo che si vuole raggiungere e si definiscono gli eventuali vincoli a cui attenersi, questa fase vede un importante utilizzo della BBT che porta alla stesura del Box, delle pagine Web e delle azioni che l' applicazione o lo stesso Box dovranno attivare in base alla evoluzione dell' applicazione.

Di fatto durante la fase di analisi si arriva a costruire un primo prototipo il cui obiettivo è quello di verificare se l' analisi che si sta sviluppando è o meno coerente con le aspettative.

Affinamento del prototipo

Il prototipo costruito in fase di analisi è ancora grezzo, nel senso che può sicuramente dare un' idea precisa di come può operare l' applicazione, di quali saranno le informazioni gestite, della struttura dell' interfaccia, ma alcuni passaggi rimangono ancora discorsivi e non si vede l' effettiva operatività: in buona sostanza ci sono parti che devono essere customizzate come ad esempio la gestione di un DB-SQL, particolari controlli di congruenza dei dati, ... Queste customizzazioni in questa fase richiedono per lo più l' utilizzo di metodi che possono già essere disponibili sulla DLL BBProcedures o richiedono di essere sviluppati (DLL custom dell' applicativo).

Presentazione e verifica del prototipo

La BBT entra in gioco in questa fase solo nel caso in cui ci siano piccole modifiche da apportare al Box che riguardano l' architetettura dell' interfaccia piuttosto che l' inserimento o la modifica di alcune regole. A seguire potranno essere necessari interventi più significativi.

Test del prototipo

Una volta verificato ed approvato, il prototipo deve essere testato: in questa fase è ovviamente coinvolto sia chi ha costruito il Box (sostanzialmente l' esperto del problema e/o l' analista) sia chi si è occupato delle customizzazioni (solitamente chi sviluppa).

Affinamento dell' applicazione

Di massima in questa fase ci si dedica all' interfaccia WEB per cui sono fondamentalmente coinvolte risorse in grado di operare sui CSS. In alcuni casi potrebbe essere richiesto un affinamento del Box (sostanzialmente le regole) o qualche customizzazione per migliorare l' operatività dell' interfaccia.