Cosa sono, quando servono

Le Validity Rules (definiti anche vincoli) sono regole il cui obiettivo è quello di validare o invalidare scelte: il rapporto domanda/risposta che si stabilisce tra l' utente e la BBT avviene tramite l' utilizzo di pagine Web che riportano gli elementi utili per formulare le domande e gli elementi utili per verificare le risposte. Compito principale delle VR è quello di invalidare possibili risposte in contrasto con il contesto in cui si sta operando. A differenza delle Decision Rule che vengono attivate da eventi ben definiti (Command Button, evento di change value di un elemento, evento di init di una pagina, ...) le VR sono sempre attive ed agiscono sull' intero modello.

Nella definizione anagrafica delle VR hanno valenza le info seguenti:

  • Is Active: se true la VR è attiva, se false è non attiva e di conseguenza non influisce sulla selezione dei dati;
  • Is Graphic: possibilità di rappresentare graficamente la VR e convertirla nel formato tabellare. Si ricorda che il motore della BBT interpreta sempre e solo il formato tabellare delle VR;
  • Undefined Are: definisce la tipologia di ramo che viene sempre considerato come false. Questo implica che nella rappresentazione grafica se Undefined Are = ARE-FALSE un nodo deve sempre avere almeno un punto End = true altrimenti è un nodo non considerato, cioè un nodo che non ha alcuna rilevanza ai fini della VR;

A titolo esemplificativo analizziamo i vincoli che seguono:

 

 

La VR relaziona le nostre attività operative con la tipologia di progetto che si sta seguendo. 

Per progetti di tipo CPQ che possono coinvolgere sia la BBT che l' ambiente Guru, le attività possibili sono la Consulenza ed il ProjectManagement

Per progetti di tipo SUPPORTO che possono coinvolgere sia la BBT che l' ambiente Guru, è possibile la sola attività Supporto.

L' attività Sviluppo è prevista nel solo caso in cui si parli di progetto Development BBT.

Le restanti attività (nella VR non si vedono in quanto raggruppate nella voce Otherwise: Documentazione e Commerciale) possono essere attivate su tutte le tipologie di progetto.

 

   
 

Con Ambiente si identifica la tecnologia su cui si basa lo sviluppo di un progetto.

La VR in questo caso relaziona il Cliente ed il progetto vincolando i progetti che si basano su tecnologia BBT ai Clienti che utilizzano tale tecnologia.

Stessa cosa vale per la tecnologia Guru: l' ambiente GEN identifica una tecnologia generica, in ogni caso non specifica nè di Guru nè della BBT.

 

La struttura delle VR può essere definita statica nel senso che una volta definita e rilasciata con il Modello, non può essere modificata dal codice dell' applicazione: se la devo modificare devo intervenire sul Modello e rilasciare il Modello stesso. Dal codice dell'applicazione rimane comunque possibile agire sui contenuti delle VR in base al contesto in cui si sta operando validando o invalidando determinati rami. Se ad es. nel modello definisco un elemento lista che contiene un insieme di domande che devono essere effettuate per ottenere un risultato, io posso agire sulle stesse validandole o invalidandole in funzione del contesto in cui mi sto muovendo. Come ulteriore esempio possiamo pensare ad un configuratore che condiziona la scelta di opzioni o componenti alla loro giacenza: la struttura della VR è impostata in modo statico (cioè questa condizione è prevista dal modello) ma le sue risposte sono dinamiche, dipendono cioè dal contesto che viene esaminato al momento della richiesta. Sarà una DR che esaminando la giscenza di una opzione o di un prodotto lo renderà valido o invalido.

 

In una applicazione BBT le VR diventano fondamentali e necessarie là dove esiste l' esigenza di guidare le scelte dell' operatore, eliminando le possibilità di errore. Ipotizziamo di creare una applicazione per configurare una macchina: quando abbiamo terminato la configurazione ovviamente la macchina deve poter essere prodotta senza problemi, così come deve prevedere gli opzionali che abbiamo scelto ed il suo costo deve essere corretto e congruente con le scelte fatte. Ne segue che non sono ammesse risposte errate, pertanto l' utente deve essere guidato nelle sue scelte. Stesso ragionamento nel caso in cui si ipotizzi di costruire una applicazione per gestire un questionario il cui obiettivo sia quello di capire se l' operatore è o meno adatto ad una certa funzione. Di esempi se ne possono fare tanti. Di contro se pensiamo ad una applicazione di Work Flow ci rendiamo conto che questa tipologia di regole ha una minore valenza.