Sisteme Bazate pe Reguli. Implementarea Unui Calculator

Sisteme Bazate pe Reguli. Implementarea Unui Calculator

Byadmin ianuarie 1, 2024

Sisteme bazate pe reguli. Implementarea unui calculator

de oferte folosind Drools Business Rules Engine.

Introducere

Sisteme bazate pe reguli
Generalitati
Istoric
Algoritm matematic (algoritmul Rete)
Utilizare (avantaje, dezavantaje, etc.)
Implementări

Implementarea Drools
Introducere
Arhitectura, etc.
Reguli
Tabel de decizie
Utilizare

Implementarea unui calculator de oferte
Introducere
Use-case
Arhitectura
Tehnologie folosita
Logica
Design
Integrare
Posibilitati de dezvoltare ulterioara

Anexe

Introducere

Daca semaforul arată culoarea roșie, atunci te oprești. Dacă este verde, poți să treci.

Viața noastră este în mare măsură guvernată de reguli și de cele mai multe ori nici nu suntem conștienți de ele. Toate acțiunile noastre sau din jurul nostru sunt consecințe ale unor condiții. Deși cuvântul –regulă– ne face să ne gândim la acte legislative sau regulamente, sursa regulilor este foarte diferită, ele pot fi date de caracteristicile noastre biologice sau de mediul înconjurător. Regulile nu se aplică doar indivizilor umani, ci guvernează tot ceea ce ne înconjoară, definind acțiuni ale obiectelor condiționate de anumite caracteristici. O regula spune ce trebuie făcut intr-un anumit caz, dar nu spune cum trebuie făcut.

Încă de la primele începuturi, aplicațiile software au fost bazate pe reguli, probabil instrucțiunea IF fiind prima la care s-au gândit părinții informaticii. Deși toată logica unei program este bazată pe reguli, acest lucru nu este deloc explicit. Primele aplicații care au evidențiat în mod clar regulile au fost sistemele expert, bazele de cunoștințe ale acestora cuprind pe lângă metode de rezolvare, euristici sau fapte și un set semnificativ de reguli.

În ultimii ani se observă o nouă tendință în aplicarea sistemelor bazate pe reguli, altfel decât pentru sisteme expert. Motoarele de reguli (rules engine) pot fi instrumente foarte utile în externalizarea logicii aplicației, în anumite cazuri aceasta conducând la avantaje semnificative, atât pentru dezvoltatori, cât și pentru utilizatori.

Lucrarea de față își propune să prezinte aspecte generale ale sistemelor bazate pe reguli, algoritmul matematic ce practic dă putere motoarelor de reguli, diverse implementări și să prezinte ceva mai în detaliu un sistem de management al regulilor, actual și foarte performant, dezvoltat în limbajul Java de către comunitatea JBoss.

Un exemplu de externalizare a logicii unei aplicații software este prezentat in partea a doua, evidențiind avantajele unei astfel de abordări în contextul dat. Exemplul are la bază un caz aflat în curs de implementare într-un proiect complex pentru o companie lider mondial în producția și implementarea de soluții de comunicare dedicate companiilor.

Capitolul 1 – Sisteme bazate pe reguli

Introducere

Inteligență artificială e un vast domeniu de cercetare din cadrul informaticii, focusat pe încercarea de a face computerele să gândească ca și oamenii. Inteligență artificială include discipline precum Rețele Neuronale, Algoritmi Genetici, Arbori de Decizie sau Sisteme Expert. În zilele noastre, aplicațiile software ce tratează acest domeniu se împart în mare în trei direcții: sisteme bazate pe cunoștințe, inteligență artificială și sisteme hibrid. Sistemele bazate pe reguli includ sistemele expert, sistemele bazate pe reguli, limbaje formale și agenți inteligenți. Inteligența artificială cuprinde rețele neuronale, algoritmi genetici și alți algoritmi de optimizare. Alte tehnici, precum sistemele fuzzy pot intra în ambele categorii.

1.1 – Sisteme bazate pe reguli și sisteme expert. Sunt evidențiate sistemele bazate pe reguli [1]

Deși rețelele neuronale și algoritmii genetici oferă multe tehnici utile pentru rezolvarea efectivă și eficientă a problemelor inteligenței artificiale, sistemele expert au făcut posibile abordarea unor probleme în mod practic și realist. Sistemele bazate pe reguli au fost primele aplicații comerciale ale cercetării realizate în domeniul Inteligentei Artificiale.

Sistemele expert fac parte din sistemele bazate pe cunoștințe și au rolul de a încorpora expertiza din diverse specializări. Un sistem expert este proiectat să acționeze ca un expert uman când este consultat în problem din domeniul său de activitate. El poartă un dialog cu utilizatorul, punând întrebări standard, iar pe baza răspunsurilor încearcă să ajungă la o concluzie. Baza de cunoștințe a sistemelor expert e construită pe un sistem de reguli. [2]

1.2 – Componentele sistemelor expert [2]

Componentele sistemelor expert:

Baza de cunoștințe – o reprezentare declarativă, de cele mai multe ori sub formă de reguli;

Memoria de lucru – datele specifice problemei ce trebuie rezolvate;

Motorul de inferență – pe baza informației venite de la utilizator încearcă să localizeze date despre problemă în memoria de lucru, prin corelare cu datele din baza de cunoștințe;

Interfața utilizator – controlul dialogului dintre utilizator și sistem.

În cadrul sistemelor expert se observă și existența a trei roluri majore:

Expertul – sau specialistul, adică persoana ce are deține expertiza în domeniul său de activitate;

Inginerul sistemului expert – persoana responsabilă cu introducerea cunoștințelor expertului în baza de cunoștințe;

Utilizatorul – persoana care consultă sistemul expert, căutând răspuns sau rezolvare pentru o anumită problema.

Primul sistem de succes a fost DENDRAL, realizat de Fiegenbaum la începutul anilor ’60. Acesta a demonstrat o tehnică de rezolvare a problemelor care nu era caracteristică Inteligenței Artificiale. Programul simula capacitățile de analiză și decizie ale unui chimist expert. O serie întreagă de sisteme expert pentru domenii variate (geologie, diagnostică medicală, explorare, etc.) au fost create folosind conceptele descrise de Fiegenbaum în DENDRAL. Comunitățile de Inteligență Artificială au acceptat sistemele bazate pe reguli ca programe inteligente deoarece foloseau cunoștințe specifice unui domeniu pentru a rezolva un set (restrâns) de probleme.[5]

Câțiva ani mai târziu, un alt sistem expert a devenit celebru: MYCIN. A fost dezvoltat în cinci sau șase ani la începutul anilor ’70 la Universitatea Stanford. A fost scris in Lisp ca parte a lucrării de doctorat a lui Edward Shortliffe sub îndrumarea lui Bruce Buchanan și Stanlez N. Cohen. Sistemul a fost realizat cu scopul de a identifica bacteriile ce cauzau infecții severe (precum meningita) și de a recomanda antibiotice cu doze corespunzătoare greutății pacientului. MYCIN folosea un motor de inferență simplu si o bază de cunoștințe de aproximativ 600 de reguli. Pentru a primi o soluție, cel care rula aplicația trebuia să răspundă la o serie lungă de întrebări cu răspuns binar (da sau nu). La final era oferită o listă de posibile bacterii vinovate de starea pacientului, fiecare bacterie având un factor de certitudine si o listă de medicații.[5]

1.2 Baza de cunoștințe

Baza de cunoștințe a sistemelor bazate pe reguli poate conține diverse forme, dar experiența a arătat ca cele mai simple și mai utile cunoștințe sunt formate din reguli și din stări de fapt. Regulile pot fi complexe, iar stările de fapt pot include secvențe, structuri, atribute și relații între ele.

Exemple:

Stare de fapt – Peștele trăiește în apă.

Regulă – Dacă animalul trăiește în apă și este vertebrat, atunci este pește.

Majoritatea sistemelor de cunoștințe sunt formate din sisteme bazate pe reguli.

Regulile pot fi considerate un subset de afirmații logice. Regulile au doua componente: a parte stânga (LHS – left-hand side) ce reprezintă un antecedent, o premisă, o condiție sau o afirmație și o parte dreapta (RHS- right-hand side) ce reprezintă o consecință, concluzie, acțiune sau răspuns. [1]

Exemple de reguli:

1.3 Mecanismul de raționament (execuția regulilor)

“Creierul” sistemelor bazate pe reguli este motorul de inferență (Inference Engine – așa cum este el referit în literatura despre Inteligență Artificială). Mecanismul de raționament este esența motorului de inferență, care are rolul de a aplica regulile din baza de reguli asupra faptelor din baza de fapte.

Procesul de căutare și potrivire a unei perechi regulă – fapt poartă numele de Pattern Matching. Motorul de inferență al sistemelor bazate pe reguli scanează partea stângă a fiecărei reguli din baza de cunoștințe până găsește una ce se potrivește cu problema dată. Atunci regula se activează dând semnalul execuției părții din dreapta a regulei.

1.3 – Reprezentarea schematică a motorului de inferență[14]

Regulile sunt stocate în Baza de reguli, iar faptele ce trebuiesc căutate de către motorul de interferență de găsesc în Baza de fapte. Sunt cazuri în care mai multe perechi reguli-fapte sunt găsite, ceea ce duce la conflicte. Agenda controlează ordinea de execuție a conflictelor folosind o strategie de rezolvare a conflictelor.

Mecanismul de raționament al motorului de inferență este cel ce conferă performanță sistemului. La o primă vedere un sistem bazat pe reguli pare o înlănțuire de condiții if-then, iar o simplă iterație asupra tuturor condițiilor este suficientă. Cu o astfel de implementare performanța sistemelor bazate pe reguli lasă de dorit. Însă algoritmul Rete rezolvă această problema performanței.

1.4 Algoritmul Rete

Algoritmul Rete a fost conceput de către Dr. Charles L. Forgy de la Carnegie Mellon University în anul 1974. Avantajul major al algoritmului este eficiența pe care o aduce, dar aceasta are un cost: folosește foarte multă memorie pentru a memora condițiile.

Cuvântul Rete este inspirat din limba latina și se referă la o rețea. Algoritmul generează o rețea pe baza condițiilor extrase din reguli. El oferă o descriere logică generalizată a unei implementări de funcționalitate responsabilă pentru potrivirea tuplurilor (fapte) vs producții (reguli) într-un sistem de potrivire de șabloane (Pattern Matching). O producție este constituită din una sau mai multe condiții și un set de acțiuni care trebuie să fie luate pentru fiecare set complet de fapte ce se potrivesc condițiilor. Condițiile testează atributele faptelor, incluzând tipul faptelor. Algoritmul Rete prezintă următoarele caracteristici majore:

• Elimină anumite tipuri de redundanță prin folosirea partajată a nodurilor

• Salvează potriviri parțiale când face uniuni între diferite tipuri de fapte. Aceasta, la rândul ei, permite sistemelor de producție să evite reevaluarea completă a tuturor faptelor de fiecare dată când se fac schimbări în memoria de lucru a sistemului. Folosind Rete sistemul nu trebuie să evalueze decât schimbările din memoria de lucru. Aceasta permite eliminarea eficientă a elementelor de memorie când faptele sunt retrase din memoria de lucru.

Algoritmul Rete este larg folosit în implementarea de funcționalitate de potrivire în domeniul paterrn matching-ului care exploatează un ciclu potrivește-rezolvă-acționeaza pentru a suporta înlănțuirea înainte și inferențele.

1.4 – Reprezentarea nodurile Rete [15]

Retele sunt grafuri directate aciclice care reprezintă seturi de reguli de nivel înalt. Acestea sunt în general reprezentate la rulare folosind rețele de obiecte în memorie. Aceste rețele se potrivesc pe condițiile de la reguli pentru a obține fapte. Rețelele Rete acționează ca un tip de procesor al interogărilor relaționale, făcând proiecții, selecții si join-uri condiționat de un număr arbitrar de numere sau tupluri de date.

Când faptele sunt adăugate la memoria de lucru, motorul creează elemente în memorie (WME – working memory element) pentru fiecare fapt. Faptele sunt n-tupluri, și de aceea pot conține un număr oarecare de elemente. Fiecare WME poate conține un întreg n-tuplu sau, alternativ, fiecare fapt poate fi reprezentat printr-un set de WME-uri unde fiecare WME conține un tuplu de lungime fixă. În acest caz, tuplurile sunt triplete în general.

Fiecare WME intră în rețeaua Rete într-un singur nod rădăcină. Nodul rădăcină trece fiecare WME către copii săi, și fiecare WME poate fi propagat prin rețea, posibil fiind stocat încare WME poate conține un întreg n-tuplu sau, alternativ, fiecare fapt poate fi reprezentat printr-un set de WME-uri unde fiecare WME conține un tuplu de lungime fixă. În acest caz, tuplurile sunt triplete în general.

Fiecare WME intră în rețeaua Rete într-un singur nod rădăcină. Nodul rădăcină trece fiecare WME către copii săi, și fiecare WME poate fi propagat prin rețea, posibil fiind stocat în memorii intermediare, pană când ajunge la un nod terminal.[6]

1.5 Metode de execuție a regulilor

Există două modalități importante de execuție a regulilor:

înlănțuirea înainte (forward chaining)

înlănțuirea înapoi (backward chaining)

Înlănțuirea înainte începe cu datele existente și folosește reguli de inferență pentru a trage concluzii din mai multe date până când scopul este atins. Un motor de inferență care folosește înlănțuirea înainte caută prin regulile de inferență pentru a găsi pe cea pentru care clauza daca (if) este adevărată. După aceasta concluzionează clauza atunci (then) și adaugă informația la baza de cunoștințe. Continuă să facă acest lucru până când un scop este atins. Pentru ca datele disponibile determină ce inferențe se folosesc această metodă se numește bazată pe date (data driven).

1.5 – Schema logică a principiului de înlănțuire înainte în execuția regulilor[14]

Înlănțuirea înapoi începe cu o listă de obiective și merge înapoi pentru a vedea dacă există date care sa ajute să concluzioneze aceste obiective. Un motor de inferență bazat pe aceasta modalitate de înlănțuire caută în regulile de inferență până când găsește una care prinde clauza atunci (then) care se potrivește cu scopul propus. Dacă partea de daca (if) a acestei reguli de inferență găsite nu este cunoscută ca fiind adevărată atunci este adăugată la lista de scopuri. Pentru ca lista de scopuri determină care reguli sunt selectate această metodă se numește bazată pe scopuri (goal driven).

1.6 – Schema logică a principiului de înlănțuire înapoi în execuția regulilor [14]

1.6 Arhitectura

Din punct de vedere arhitectural, privit mai în detaliu, un sistem bazat pe reguli are doua componente majore: baza de cunoștințe (reguli) și nucleul sistemului. Teoretic, acesta din urmă poate lucra cu orice set de reguli indiferent de domeniu de bază.

1.7 – Reprezentare schematică a arhitecturii unui sistem bazat pe reguli

Nucleul include module software al căror scop este să:

permită dialogul dintre utilizator și sistem

permită editarea de noi reguli

translateze regulile într-o formă recunoscută de sistem

execute regulile

Capitulul 2 – Sisteme de management al regulilor

2.1 Evoluția sistemelor sistemelor bazate pe reguli

Pentru multă vreme singura aplicabilitate a sistemelor bazate pe reguli a fost in cadrul Inteligenței Artificiale, cu predilecție ca bază pentru Sistemele Expert. Pe de altă parte însă, tot timpul, regulile au făcut parte intrinsecă din cadrul aplicațiilor software chiar dacă nu la nivel explicit sau declarativ, ci procedural intercalate în codul sursă. Un exemplu elocvent este sistemul de reguli implementat în majoritatea programelor de email: dacă emailul primit îndeplinește anumite condiții, atunci aplicația client trebuie să execute niște operații sau să mute viitoarele mesaje ce îndeplinesc condițiile într-un anumit director.

2.1 – Exemplu din Microsoft Outlook – sistem de reguli

implementat în mod convențional

În anii 90, procedeele de management din afaceri au încercat să țină pasul vitezei schimbărilor, al globalizării și al progresului tehnologic prin introducerea sistemelor de reguli, al procedurilor. A apărut astfel termenul de Business Rule fiind definit ca o structura ce constrânge sau definește aspectele afacerii și intenționează să servească structura afacerii, să controleze sau influențeze caracteristicile afacerii. [8]

Aplicațiile software destinate managementului întregului flux operațional din cadrul companiilor au început să capteze regulile de business (de afaceri) într-un format simplu și limbaj clar accesibil tuturor părților implicate în dezvoltarea programelor informatic: proprietarul produsului, business analist, arhitect, programator, testor, integrator, etc. Regulile de business descriu practic logica aplicației, așa numit-ul business logic.

2.2 Procesul de dezvoltare al sistemelor informatice

Metoda convențională

Pentru a înțelege cu adevărat importanța sistemelor de management al regulilor, trebuie analizat modul clasic, convențional de dezvoltare al sistemelor informatice complexe destinate managementului fluxului de lucru din cadrul companiilor. Figura 2.2 prezintă o privire de ansamblu, foarte simplificată, asupra rolurilor persoanelor implicate și al modului de lucru.[10]

2.2 – Reprezentare schematică a metodei de dezvoltare convenționale

Câteva considerente:

Proprietarul sistemului informatic (business owner) – este persoana ce a comandat sistemul informatic și care plătește pentru el. În cele mai multe cazuri este o persoană desemnată de către compania ce va folosi sistemul informatic. Implicarea proprietarului este cumva limitată odată ce a creat principalele cerințe ale sistemului (requirements specifications).

Întregul proces implică acceptarea de către proprietar a faptului că sistemul va avea erori, iar că testarea poate ajunge chiar la o treime din timpul alocat dezvoltării. Orice schimbare poate aduce noi erori și restrânge oportunitățile de a reduce numărul de erori.

Fiecare rol este important în cadrul dezvoltării. Analiștii interpretează cerințele sistemului, arhitecții realizează concepția sistemului iar programatorii realizează programul informatic pe baza documentelor produse de analiști și arhitecți. Apoi intervin testorii și cei ce se ocupă de integrarea sistemului făcând aplicația accesibilă utilizatorilor finali.

Procesul este unul foarte laborios, poate dura ani de zile și avea costuri foarte mari. Nu de puține ori proiectele sunt oprite din cauza epuizării bugetelor.

Procesul este unul ciclic, după ce prima versiune este finalizată, urmează alte cerințe ceea ce face ca procesul să se repete ducând la dezvoltarea unei alte versiuni.

Business Rule Management System (BRMS)

Experiența anilor 90 când avântul dezvoltării sistemelor informatice pentru companii a consumat bugete importante, a dus la căutarea unui altfel de mod de dezvoltare care să elimine unele neajunsuri din cadrul procesului clasic de dezvoltare. Sistemele bazate pe reguli un scopul de a reduce dependența de programatori, de a scurta timpul de implementare a unei noi cerințe și de testare și nu în ultimul rând de a conferi proprietarului sistemului posibilitatea de a fi “mai aproape” de programul ce îi este destinat.

Sistemele de management al regulilor fac sistemele bazate pe reguli mai valoroase oferind utilizatorilor pe lângă posibilitatea de a crea reguli noi, gestionarea baza de reguli și un set de instrumente pentru analiză și punere în valoare a rezultatelor.

Aplicațiile complexe au mai multe nivele privit din punct de vedere arhitectural. Au un nivel al prezentării (presentation layer) – interfață utilizator, un nivel al logicii organizaționale (business logic) și unul al persistență (persistence layer) – stochează datele. Nivelul de mijloc este cel ce implementează logica aplicației, iar cerințele pentru modificare ei sunt mai frecvente decât pentru restul aplicației. [9]

În loc să includă logica în nivelul de mijloc, sistemele de management al regulilor o separă aproape total și oferă posibilitatea de a o externaliza, punând-o sub controlul unui singur rol: business analist.

2.3 – Sistem de Management al Regulilor

Sistem de Management al Regulilor conține câteva părți principale: un editor de reguli ce oferă posibilitatea de a crea sau modifica reguli, o baza de reguli, un motor de execuție și un modul ce permite generarea de cod ce reprezintă regulile de business, de logică.[9]

2.3 Diferențe dintre sistemele bazate pe reguli și sisteme informatice convenționale

Funcționalitatea programelor informatice dezvoltate în mod convențional implică, putem spune, transformarea unor cerințe bine definite într-un sistem ce produce un rezultat bine definit. În cazul sistemelor expert, rezultatul nu poate fi clar definit de la început, el depinde de volumul de cunoștințe și cum sunt ele interpretate. [3]

Principala diferență dintre un program bazat pe reguli și un program convențional rezida din faptul că un sistem expert lucrează cu cunoștințe găsite prin căutări, pe când convențional se lucrează cu date, prelucrate prin algoritmi. [4]

O altă diferență este dată de structura programului. În programarea clasică cunoștințele sunt inserate intrinsec în cadrul codului, iar controlul se face prin algoritmi. Intr-un sistem bazat pe reguli componenta de stocare a cunoștințelor și cea de interpretare sunt total separate.

Separarea explicită a bazei de reguli față de cea de control face foarte ușoară adăugarea de noi cunoștințe chiar și după ce s-a terminat dezvoltarea aplicației software. In programarea convențională acest lucru este posibil doar printr-un nou proces de dezvoltare, ducând la o nouă versiune a programului. Acest aspect este foarte important mai ales din punct de vedere economic, dezvoltarea continuă a unui sistem convențional este semnificativ mai costisitoare decât popularea cu cunoștințe a unui sistem bazat pe reguli.

Într-un sistem bazat pe reguli, după ce s-a finalizat structura de bază, modificările sunt simplu de implementat, cunoștințele fiind reprezentate explicit, ci nu implicit în interiorul codului. Un nucleu bine definit al unui sistem expert poate fi utilizat în domenii diferite în funcție de domeniul bazei de cunoștințe la care este conectat.

2.4 Avantaje ale sistemelor bazate pe reguli

Ușor de înțeles – Regulile sunt mai ușor de înțeles pentru un business analist sau un programator decât codul sursă din limbajele de programare. Controlul persoanelor calificate (business analist) asupra programului este mult mai facil.

Programare declarativă – Motoarele de reguli permit să spui “ce să faci” dar nu și “cum să faci”. Folosirea regulilor face mult mai ușoară exprimarea unor soluții la probleme complexe pentru că regulile sunt mai ușor de citit și înțeles decât codul sursă. Regulile permit soluționarea unor probleme foarte complexe.

Separarea logicii de partea de date (externalizarea business logic-ului) – Datele sunt păstrate în nivelul de date, iar logica este inclusă în reguli. În programarea orientată obiect, logica poate fi forte bine organizată în reguli în loc să fie distribuită în diverse obiecte și controlere.

Ciclu de viață independent – Regulile pot fi create și testate într-un ciclu de dezvoltare diferit față de aplicația principală, mult mai rapid și fără a fi nevoie de procese de recompilare sau reinstalare a sistemului informatic principal.

Schimbări rapide (flexibilitate) – În unele domenii de activitate logica ce trebuie implementată în aplicație se poate schimba foarte des. În astfel de situații un sistem bazat pe reguli răspunde mult mai rapid schimbării, poate și foarte ușor adaptat.

Centralizarea informației – folosind reguli se creează un loc unic care însumează toate cunoștințele, toată informația. În mod ideal, regulile pot fi ușor de citit și înțeles, caz în care pot fi folosite și ca documentație.

Utilizatorii experți pot controla regulile – Acesta opțiune, coroborată cu celelalte de mai sus, fac ca aplicația să fie cu adevărat în mâinile persoanelor cărora le este destinată, utilizatorii nu mai sunt dependenți de întreg procesul de dezvoltare (arhitect, programator, testor, integrator, etc.) atunci când e nevoie de o schimbare.[11]

2.5 Dezavantaje ale sistemelor bazate pe reguli

Pe de altă parte sistemele bazate pe reguli au și o serie de dezavantaje. Tot timpul, dezvoltarea unui sistem pentru a rezolva probleme complexe va fi foarte complicată și trebuie să ținem cont și de posibilele dezavantaje.

Pregătirea – La prima implementare a unui sistem bazat pe reguli programatorii trebuie învățați să adopte un alt stil de abordare a problemei, stil diferit de ceea ce au fost obișnuiți și în plus trebuie să învețe ți despre motoarele de reguli.

Depanarea – Mediile de dezvoltare în limbajele de programare oferă modalități foarte avansate de depanare a codului sursă, lucru foarte util în identificarea erorilor. În cazul regulilor, nu există sisteme de depanare, făcând identificarea erorilor mult mai dificilă.

Memoria consumată – Algoritmul Rete aflat în spatele motorului de inferență este un foarte mare consumator de memorie. În unele cazuri memoria disponibilă poate impune o limitare, deși în zilele noastre memoriile sunt relativ ieftine.

Recursivitatea – Interacțiunea dintre reguli poate duce uneori, mai ales în sisteme complexe, la apariția fenomenului de recursivitate, ceea ce poate cauza dificultăți în depanare și testare.

2.6 Când să utilizăm reguli

Sistemele bazate pe reguli sunt diferite, fiecare are propriile avantaje dar și dezavantaje. În primul rând trebuie ținut cont de faptul că rezolvarea unei probleme informatice pe bază de reguli nu este o soluție magică, este doar diferită, oferă o altă perspectivă de a privi o problemă. Uneori oferă avantaje, alteori nu.

Regulile sunt potrivite pentru:

Domenii în care apar schimbări frecvent, afectând logica aplicației

Rezolvarea problemelor complexe, în care algoritmii clasici nu pot oferi soluții, sau baza problemei nu este înțeleasă în totalitate

Rezolvarea unor probleme simple, dar pentru care structurarea sub formă de reguli se pretează mult mai bine.

Utilizatorii experți vor să aibă control asupra sistemului informatic. Ei sunt experți în domeniul lor de activitate, dar sunt persoane non-tehnice din punct de vedere al informaticii.

Nu este necesar ca întreaga aplicație să fie bazată pe reguli, este suficient dacă doar anumite module, bine alese, sa fie implementate prin reguli. Regulile pot fi incluse în aplicație în mod direct sau apelate ca și serviciu (webservice).

2.7 Când să nu utilizăm reguli

Pe cât posibil este bine să evităm folosirea sistemelor bazate pe reguli în următoarele cazuri:

În cadrul proiectelor cu un număr redus de reguli. Pentru astfel de cazuri, folosirea sistemelor bazate pe reguli nu se justifică.

Dacă logica aplicației este bine definită și nu se va modifica în timp.

Dacă performanța este un criteriu important sau există limitări ale memorie.

Dacă aplicația este planificată să se elaboreze într-un singur ciclu, fără necesitatea de a adăuga sau schimba funcționalități de-a lungul timpului.[7]

2.8 Soluții existente având ca baza sistemele de reguli

La ora actuală există mai multe sisteme de dezvoltare bazate pe reguli, atât soluții comerciale cât și soluții open-sorce. Dintre cele mai importante putem aminti:

BizTalk (Microsoft)

Drools (JBoss)

ILOG JRules (IBM)

Oracle Business Rules Engine (Oracle)

Jess (Java Expert System Shell – motor de reguli bazat pe Java)

Pegasystems (PegaRules)

Multe dintre sistemele bazate pe reguli, în special cele comerciale, oferă multe alte funcționalități, servicii sau instrumente.

Atunci când se alege un anumit motor de reguli, ar trebui ținut cont de următoarele:

Algoritmul matematic și performanță

Capacitatea de colaborare dintre programatori și analiști

Capacitatea de integrare în medii de dezvoltare sau instrumente cunoscute (ex. Eclipse, Excel, etc.)

Posibilitatea de integrarea în sisteme existente

Posibilități de editare, depanare și testare a regulilor

Cursuri de pregătire și oferirea de suport tehnic când e necesar.

Capitolul 3 – Drools

3.1 Ce este Drools?

Drools este un sistem de management al regulilor (business rule management system, pe scurt BRMS) dezvoltat ca și proiect open-source sub Licență Apache 2.0 și inclus în platforma JBoss de la Red Hat.

Dezvoltarea proiectului a început în 2001, prima versiune având un sistem liniar de căutare al regulilor, sistem rescris în versiunea 2.0 și înlocuit cu algoritmul Rete. Versiunea 3.0 a introdus noul formal .drl pentru reguli, iar următoarele versiuni au adus îmbunătățiri constante și noi funcționalități. Actualmente Drools a ajuns la versiune 6.0, o versiune stabilă și matură făcând din Drools unul dintre cele mai puternice sisteme de reguli bazate pe Java.

Platforma Drools constă din câteva module importante:

Expert – practic implementarea sistemului de inferență

Fusion – responsabil pentru procesarea evenimentelor

Flow – combină regulile și procesele

Guvnor – conține o bază de reguli, posibilități de editare printr-o interfață grafică și instrumente pentru gestionarea unui număr mare de reguli

Planner – un pachet general de aplicații destinate optimizării și planificării activităților

Unul din avantajele oferite programatorilor este posibilitatea de integrare în platforma de dezvoltare Eclipse. Ea oferă posibilități de depanare și testare precum și set foarte util de instrumente necesare dezvoltării de aplicații.

3.2 Sistemul de reguli în Drools

Drools și-a dezvoltat propriul limbaj și sintaxă de scriere a regulilor. Ele sunt grupate în fișiere cu extensia .drl care la rândul lor pot fi grupate in pachete după modelul package implementat in Java. Limbajul conține cuvinte rezervate (exemplu: rule, when, then și end) și oferă și posibilitatea de introducere a comentariilor.

package drools_exemplu;

rule ”exemplu 1”

when

Cont(balanta < 100) //conditie

then

system.out.prinln(”Balanta contului este ” +

”mai mica decat 100”) //consecinta

end

3.1 – Exemplu de regulă în Drools

Regula de mai sus se execută pentru fiecare instanță a bean-ului Cont a cărui balanță este mai mică decât 100. Regulile în Drools respectă caracteristicile generale ale regulilor, având o parte stânga LHS și una dreaptă RHS (vezi capitolul xx).

Bean-ul Cont este un obiect Java de tip POJO și trebuie să conțină pe lângă metodele clasice de get și set și implementări ale metodelor equals și hashCode. Drools trebuie să știe când două obiecte sunt logic egale.

Având regula și clasa POJO corespondentă, execuția regulei este relativ simplă:

public class ExempluDrools {

public static final void main(String[] args) {

KnowledgeBase knowledgeBase = createKnowledgeBase();

StatefulKnowledgeSession session = knowledgeBase .newStatefulKnowledgeSession();

try {

Cont cont = new Cont();

cont.setBalanta(50);

session.insert(cont);

session.fireAllRules();

} finally {

session.dispose();

}

3.2 – Exemplu de execuție a unei reguli

KnowledgeBase – este interfața care gestionează o colecție de reguli. Este oarecum similară cu baza de cunoștințe. Drools oferă o singură implementare a acestei interfețe, este serializabilă și o dată creată poate fi refolosită. Implementarea este bazată pe algoritmul Rete.

StatefulKnowledgeSession – este interfață principală pentru interacțiunea cu motorul de interferență din Drools. Conține metode pentru adăugare, editare sau extrage fapte. Probabil cea mai interesantă metodă a sa este fireAllRules care este folosită pentru execuția regulilor. La final nu trebuie uitată metoda dispose, altfel memoria nu este eliberată.

private static KnowledgeBase createKnowledgeBase() {

KnowledgeBuilder builder = KnowledgeBuilderFactory

.newKnowledgeBuilder();

builder.add(ResourceFactory

.newClassPathResource("exemplu.drl"),

ResourceType.DRL);

if (builder.hasErrors()) {

throw new RuntimeException ( builder.getErrors().toString());

}

KnowledgeBase knowledgeBase = KnowledgeBaseFactory .newKnowledgeBase();

knowledgeBase.addKnowledgePackages( builder.getKnowledgePackages());

return knowledgeBase;

}

3.3 – Exmplu conținând o metodă ce crează un KnowledgeBase obiect

KnowledgeBuilder – este o interfață responsabilă pentru crearea unui KnowledgePackage obiect pe baza regulei date.

Pentru o mai bună înțelegere, întregul proces poate fi reprezentat grafic.

3.4 – Procesul de creare unui obiect KnowledgeSession

Regulile pot declara variabile după cum urmează:

$cont: Cont( $type : type)

Drools recunoaște toate tipurile native din Java. Exemple:

String: Client (nume == ”Andrei”)

Expresii regulate: Client (nume matches ”[A-Z][a-z]+”) Operatorul matches suportă orice expresie validă definită în java.util.regexp API.

Date: Cont ( data_creare > ”12.05.2014”)

Boolean: Tranzactie (esteAprobata == true)

Enum: Cont (type == Cont.Type.ECONOMISIRE)

De asemenea, Drools suportă comentarii pe o singură linie (# sau //) sau pe mai multe (/* …*/).

Dupa cum am amintit, regulile pot fi grupate în pachete, iar import-ul în cadrul fișierului de reguli are același scop ca și importul în clasele Java. Importul oferă posibilitatea de a folosi clase și tipuri definite în din alte pachete.

Regulile pot folosi variabile globale, asignate unei sesiuni. Ele sunt utile pentru importul sau exportul de parametri.

Funcțiile sunt niște caracteristici foarte utile. Ele pot fi incluse în condiții sau în consecința unei reguli. Se scriu folosind standardul Java.

function double calculeazaPatratul( double value) {

return value * value;

}

3.5 – Exemplu de funcție definită în fișierul de reguli.

Dialectul specifică sintaxa folosită în expresii, fie că sunt condiții sau consecințe. Valoarea prestabilită este Java, iar Drools mai suportă un alt tip: mvel. În fișierul de reguli, chiar după definirea pachetului se specifică dialectul: dialect ”mvel”.

În cadrul condițiilor Drools suportă o serie de operatori, unii declarați implicit, alții sub formă de cuvinte rezervate:

and Client (nume == ”Popescu”, varsta < 26)

or Client (nume == ”Popescu” || varsta < 26)

not not Client (type == Client.Type.PREMIUM)

exists Client (type == Client.Type.PREMIUM)

eval – evaluează o expresie și retunrează true sau false

this – la fel ca în Java, operatorul this poate fi folosit avand aceiași funcție

Pentru lucrul cu colecțiile Drools oferă 3 posibilități: contains, memeberOf și from. Primele două pot și folosite și pentru negare, cu not.

Prioritatea regulilor

Când toate condițiile dintr-o reglă sunt îndeplinite, se spune că regula este activată. După ce toate regulile sunt evaluate vom avea probabil câteva reguli active. Motorul de reguli va extrage o regulă și o va executa (fire). Regula este aleasă pe baza unei strategii în caz de conflict care folosește mai multe criterii pentru a lua decizia ce regulă este mai potrivită pentru execuție. După ce regula este executată se reevaluează toate posibilele modificări ale condițiilor, deoarece regula executată poate duce la activarea sau dezactivarea altor reguli.

Atributele regulilor

Atributele sunt folosite pentru a modifica comportamentul standard al regulilor. Toate atributele se definesc între cuvintele cheie rule și when.

Salience (prioritate) este un atribut important și este folosit în strategia de rezolvare a conflictelor, cea care decide care regulă este executată prima în cazul în care mai multe reguli îndeplinesc condiția. Cu cât mai mare este valoarea dată atributului salience, cu atât este mai mare probabilitatea ca și regula să fie executată cu prioritate. Valoarea predefinită este 0.

No-loop este un atribut care cere motorului de reguli să execute o regulă numai o singura dată.

3.3 Tabele de decizie

Tabelele de decizie reprezintă o formă de scriere a regulilor într-o formă mult mai inteligibilă mai ales pentru persoane non-tehnice. Sunt utile cu predilecție în cazuri în care există multe reguli similare dar cu valori diferite. Regulile care folosesc aceiași condiție, dar cu parametrii diferiți.

Tabelele de decizie pot fi reprezentate ca și tabele Excel (fișiere .xls) sau prin fițiere ce conțin valori separate prin virgulă (comma separated values – în fișiere .csv). Este de așteptat ca versiunile viitoare de Drools să includă și un editor web de reguli în sistem tabel de decizie.

Conceptul tabelelor de decizie este oarecum învechit dar dovedit în timp ca fiind foarte viabil și des utilizat. De aceea a fost preluat de Drools dar este folosit doar pentru generare de reguli, fiind folosit într-un mod indirect.

3.6 – Tabel de decizie în format Excel.

În tabelele de decizie, primele linii definesc pe baza unor cuvinte cheie informații utile pentru Drools, inclusiv condițiile și acțiunile. Aceste linii pot fi ascunse pentru a nu deranja vizual utilizatorii filierelor Excel. Apoi fiecare linie este utilizată pentru a defini o regula, iar fiecare coloană pentru a defini o condiție sau o consecință. Se preferă utilizarea unui set de culori ce să delimiteze clar condițiile de partea de consecințe.

Dintre avantajele utilizării tabelelor de decizie putem aminti:

Ușor de citit și interpretat

Foarte ușor de modificat

Asigură o separare clară dintre regulă și datele aferente

Toate funcțiile de formatare/editare ale unei aplicații de gen Excel pot fi folosite suplimentar, ducând la avantaje suplimentare în folosirea tabelelor de decizie.

Dezavantaje ale tabelelor de decizie

Depanarea și testarea devin foarte dificile. Este preferabil transformarea tabelelor de decizie în fișiere de reguli .drl și făcută acolo testarea.

Nu se recomandă pentru seturi de reguli total diferite, fără condiții comune.

Capitolul 4 – Implementarea unui calculator

de oferte folosind Drools

4.1 Procesul de ofertare. Generalități

În cadrul relațiilor comerciale, atât între persoane juridice cât și între persoane juridice și persoane fizice, procesul de achiziție al unui produs, serviciu sau un set de produse sau servicii se desfășoară, în genere, după următorul scenariu:

agentul de vânzări (departamentul de vânzări) discută cu clientul asupra produsului (serviciului) sau setului de produse (servicii) ce se doresc achiziționate. În cazul achiziției unui set de produse și servicii, discuțiile inițiale se focusează doar pe elementele principale ce caracterizează achiziția. Produsele secundare (auxiliare) nu sunt încă evidențiate și nici măcar cunoscute deoarece persoanele din vânzări nu au întotdeauna o formare tehnică astfel încât să cunoască toate detaliile tehnice, iar pe de altă parte clientul este interesat doar de produsele principale ce definesc achiziția. La acest pas se creează oferta inițială.

pe baza ofertei inițiale, departamentul de ofertare pregătește o listă detaliată incluzând fiecare produs sau serviciu ce trebuie inclus pe baza interdependențelor. Lista detaliată se returnează departamentului de vânzări.

agentul de vânzări pregătește oferta detaliată și o prezintă clientului. De la caz la caz se mai pot oferi discount-uri.

Secvența prezentată mai sus se poate repeta în câteva cicluri totale sau parțiale, în funcție de negocierile purtate între client și vânzător.

Grafic putem reprezenta astfel:

4.1 Secvența operaților în cadrul procesului de ofertare

Întreg procesul de ofertare este oarecum simplu și poate fi capturat în implementarea unei aplicații software. La ora actuală există pe piață o multitudine de aplicații specializate în ofertare, majoritatea oferind doar suport în editarea ofertelor. În funcție de dimensiunea afacerii, acestea pot fi foarte complexe, iar în cazul companiilor mici o simplă foaie de calcul în Excel este suficientă.

Dacă cerințele sunt clare iar datele ce afectează fiecare pas din cadrul procesului nu se schimbă, atunci nu sunt probleme. Dacă însă acele date se modifică atunci poate apare necesitatea modificării și adaptării aplicației astfel încât să includă noile cerințe. În unele domenii de activitate și pentru aplicații complexe, un proces de dezvoltarea ulterioară poate însemna luni de zile ca și timp de execuție și implicit un buget pe măsură.

Într-un sistem ca și cel din figura anterioară, cele mai frecvente schimbări pot apărea în cadrul elaborării devizului detaliat și în cadrul discount-urilor oferite de vânzător. Un sistem informatic care să permită modificări doar în cadrul acestor module ar simplifica întregul proces de adaptare al aplicației la cerințe noi. În funcție de anumite condiții, un sistem pe bază de reguli ar putea fi de mare ajutor.

4.2 Caz particular. Ofertarea în cadrul unei companii ce produce și instalează soluții pentru comunicare în mediul enterprise

4.2.1 Definirea temei

Problema dată are la bază procesul de ofertare descris pe scurt in subcapitolul precedent. Sistemul informatic implementat în trecut și folosit de către companie pentru a facilita elaborarea ofertelor s-a dovedit depășit de necesitatea de a se adapta mereu condițiilor în continuă schimbare.

Compania produce și instalează sisteme de telefonie în mediul enterprise. Contractele de instalare vizează companii mari și discuțiile se poartă în jurul numărului de centrale telefonice și aparate telefonice. Acestea sunt cuprinse în ofertele inițiale, dar în cadrul elaborării ofertelor detaliate trebuie ținut cont de totalitatea componentelor ce trebuiesc incluse. Fiecare centrală telefonică conține un software de administrare, un set de licențe și un număr de diverse componente auxiliare (suport, sursă alimentare, conectori, etc.). La fel, fiecare aparat telefonic conține diverse elemente auxiliare. De aici rezultă necesitatea unui modul de administrare al posibilelor configurații, iar elementele ce dictează și influențează o configurație se schimbă relativ frecvent.

Pentru fiecare element din oferta detaliată se calculează efortul necesar instalării, pentru că acesta poate varia. Costul final se obține luând în calcul și rata orară care este diferită în funcție de țara unde are loc instalarea. Mai mult, la oferta finală se mai aplică o serie de discount-uri decise de către de departamentul de vânzări, discount-uri ce nu se pot încadra într-un format prestabilit.

Ca și concluzie putem spune că este necesară implementarea unui sistem informatic care pe baza ofertelor primite de la aplicația de gestionare a vânzărilor, să permită o posibilitate foarte flexibilă în definirea configuraților ce vor fi returnate aplicației de vânzări, precum și posibilitatea de calculare a prețului pentru fiecare element din oferta detaliată.

Soluția propusă

Soluția aleasă are la bază un motor de reguli. Acesta va face ca întreg procesul să fie foarte flexibil, dând posibilitatea specialiștilor din departamentele tehnice să definească configurații pe bază de reguli. Simplificat putem exemplifica:

Daca centrala telefonică este de tipul X și sunt incluse N aparate telefonice, atunci sunt necesare M licențe de tip Y și sursă de alimentare de tip Z și N conectori de tip W.

În mod real e puțin diferit, fiecare reper este reprezentat sub forma unui număr unic de identificare al produsului sau serviciului.

Pentru interconectarea cu aplicația destinată departamentului vânzări se vor folosi web servicii, precum și o interfață grafică construită dinamic, pe bază de reguli necesară vizualizării și editării configurațiilor stabilite pe bază de reguli.

4.3 Diagrama Use-Case

Folosind o diagramă use case, interacțiunile principalilor actori cu sistemul poate fi reprezentată astfel:

4.2 – Interacțiunea utilizatorilor cu sistemul

Sistemul de management al vânzărilor este o aplicație separată ce nu face scopul acestei lucrări, dar pentru o buna înțelegere este necesară prezentarea sa alături de sistemul pe bază de reguli.

4.4 Arhitectura sistemului

Arhitectura sistemului este pe trei nivele: de prezentare, logic și de persistență. În cadrul nivelului logic se găsește sistemul pe bază de reguli ce conține două web servicii, unul pentru configurații și unul pentru prețuri. Server-ul folosit este JBoss ce va rula toate cele trei componente prezentate în figura de mai jos: web servicii, partea de server a interfeței grafice (dezvoltată în Eclipse RAP) și sistemul bazat pe reguli.

4.3 – Arhitectura sistemului

Pentru nivelul de persistență este folosită o baza de date MongoDB. În ea se stochează colecțiile de produse/servicii și prețurile aferente pentru fiecare țară.

Interfața grafică dezvoltată în Eclipse RAP conține componente generate dinamic pe bază de regulilor ce definesc configurațiile. Sistemul de management al vânzărilor a fost reprezentat simplificat deoarece nu este de interes pentru lucrarea curentă.

Adițional există o serie de procese ce interconectează aplicația bazată pe reguli cu alte aplicații din sistem și populează baza de date cu informații actualizate. Prețurile provin de la aplicația de prețuri (pricing), iar produsele sunt definite și administrate de către o aplicație dedicată. Procesele de sincronizare sunt setate să ruleze în fiecare noapte, perioadă când activitatea în rețea e relativ redusă.

Modulul pentru generatul regulilor pe baza fișierelor Excel poate rula independent, iar regulile rezultate se pot introduce runtime în serverul JBoss, neafectând funcționarea acestuia.

4.5 Tehnologii folosite

4.5.1 Java

Atât aplicația în cauză, cât și restul aplicațiilor din întregul sistem sunt dezvoltate în tehnologii și framework-uri ce au la baza Java. Pentru sisteme complexe, Java este la ora actuală cea mai potrivită tehnologie, printre avantaje putând enumera:

este ușor de învățat, a fost concepută să fie simplă și de aceea este foarte ușor de scris, compilat și depanat.

este un limbaj de programare orientat obiect POO și această caracteristică permite dezvoltarea de programe modulare și să reutilizeze codul.

este independentă de platforma. Poate rula pe diferite sisteme de operare grație mașinii virtuale.

este distribuită. Este concepută să poată rula în rețea, distribuită pe diverse sisteme.

este sigură, nu are găuri de securitate.

este robustă, adică fiabilă. Compilatorul este capabil să identifice multe probleme încă din faza de compilare

este multithreding, adică are capacitatea de a rula mai multe procese simultan.

4.5.2 Drools BRMS

Este motorul de reguli descris în capitolul precedent. În aplicația de față este componenta principală a sistemului și tema a proiectului. Din totalitatea modulelor Drools, doar Drools Expert este folosit în realizarea aplicației.

4.5.3 Eclipse RAP

Remote Appliction Platform (cunoscută și sub numele vechi de Rich Ajax Platform) reprezintă un framework bazat pe Java pentru dezvoltarea aplicațiilor pentru desktop (RCP), web sau platforme mobile.

Platforma oferă un set de componente SWT API ce permit dezvoltatorilor să scrie aplicații web folosind componente. Fiecare componentă este translatată automat în limbaj JavaScript, marele avantaj oferit programatorilor este independența față de cod HTML, stiluri CSS și cod JavaScript. Folosind RAP, un programator poate dezvolta aplicații web fără a fi necesar să scrie cod folosind tehnologiile web precizate anterior.

Un punct forte ale aplicațiilor din Eclipse îl reprezintă conceptul de modularizare de la OSGi. Acesta oferă un mediu dinamic de rulare a modulelor, numite bundle-uri. Bundle-urile sunt versionabile și fiecare își definește dependințele față de celelalte bundle-uri, exportându-și interfețele într-un fișier manifest. Serviciile OSGi pot comunica între ele și să extindă alte module ce permite dezvoltarea unei aplicații cu cuplaj mic (loose coupling).

4.5.4 MongoDB

MongoDB este o implementare de baze date nerelaționară opensource, scris în C++ și orientată pe documente. Conceptul larg răspândit în cadrul bazelor de date, de înregistrare este înlocuit în MongoDB cu un model mult mai flexibil numit document.

În MongoDB o bază de date este, de fapt, o colecție de documente. Practic tabelele devin colecții, iar liniile (rows) devin documente. Nu are schemă, iar câmpurile nu sunt predefinite. Structura unui document este similară cu un document XML sau unul JSON. [12]

Un alt avantaj major al lui MongoDB este scalabilitatea. Aceasta vine din faptul ca nu este o bază de date relaționară.

4.5.5 Maven

Maven este un instrument dezvoltat de Apache și este dedicat managementului proiectelor Java. Este un instrument puternic și bine structurat, folosește un fișier XML pentru a descrie cum este construit proiectul, dependințele față de alte componente și module externe, ordinea în care sunt incluse precum și plugin-urile necesare.

Maven downloadează în mod dinamic librăriile Java necesare din repository-uri predefinite sau din cel central și le stochează într-o locație temporară. Acest top de management al proiectului, în care declarăm dependințele, ajută mult în dezvoltare deoarece elimină problemele frecvente generate de lipsa librăriilor și configurarea acestora.

4.5.6 Eclipse IDE

Principalul element folosit pentru dezvoltarea aplicației este Eclipse, un IDE (Integrated development environment) scris în Java. Constă dintr-un spațiu de lucru (workspace) de bază și un set foarte extins de plugin-uri.

4.6 Funcționare

Deși logica este clară, aplicația în sine este una foarte complexă datorită volumului mare de reguli și mai ales a numărului mare de condiții și consecințe din cadrul regulilor.

Interfața grafică

Interfața grafică este una foarte simplă, fiind dedicată în special unui număr redus de persoane, fie unor specialiști din cadrul companiei client, fie unor persoane ce asigură mentenanță și suport. Este dezvoltată folosind Eclipse RAP.

Modulul Flexible UI (UI este prescurtarea de la User Interface) permite vizualizarea configurațiilor. O configurație reprezintă un set de produse ce sunt grupate în pachete respectând anumite ierarhi. Configurațiile sunt administrate de specialiștii companiei client și sunt controlate pe baza unor seturi de reguli, majoritatea condițiilor având ca și consecință includerea sau excluderea unor produse. Interfața grafică aferentă modulului Flexible UI este construită dinamic pe baza regulilor de configurare.

4.4 – Interfața grafică dedicată administrării configurațiilor

Modulul BOM este destinat cu precădere personalului ce oferă suport și mentenanță, oferă trei submodule foarte utile pentru monitorizare și depanare, oferind utilizatorilor o serie de rapoarte. Practic, câteva funcționalități sunt similare fișierelor log convenționale, diferența majoră e ca aici informație e prezentată tabelar sau in format Excel, ceea ce le face mult mai ușor de utilizat.

Request Search permite vizualizarea ofertelor prelucrate de către sistem, include funcții pentru căutare și filtrare.

4.4 Interfața grafică: căutarea și filtrarea requesturilor

făcute de către aplicația dedicată vânzărilor

O caracteristică foarte utilă în depanare este posibilitatea de a vizualiza cererile primite și răspunsurile date de către sistem în comunicația cu sistemul de management al vânzărilor. Sunt prezentate obiectele SOAP.

4.6 – Vizualizarea obiectelor SOAP din comunicația pe web service

Convertor Protocol oferă posibilitatea de a vizualiza mesajele de atenționare și eroare, funcție similară cu a fișierelor clasice de logare, cu diferența că aici sunt prezentate în format Excel.

4.7 Generarea de rapoarte ce conțin erori și atenționări în format Excel

4.8 – Exemplu de raport ce prezintă erorile procesului de ofertare

Nivelul logic

Nivelul aflat la mijloc în arhitectura 3-tier este nivelul ce implementează logica aplicației. În cazul aplicației de față nucleul este compus din logică bazată pe reguli ce sunt prelucrate cu ajutorul Drools.

4.9 – Exemplu de tabel Excel conținând reguli

Folosirea fișierelor Excel pentru editarea regulilor este probabil cea mai importantă caracteristică a aplicației. Excel-ul este foarte utilizat și putem spune chiar iubit în compania client, de aceea posibilitatea de a-l utiliza în conjuncție cu sistemul de ofertare a fost foarte bine primită de utilizatori. Dar principalul avantaj vine din faptul ca oferă flexibilitate sistemului, utilizatorii principali, așa numiții power-useri au posibilitatea să schimbe comportamentul sistemului doar editând date in fișierul Excel.

Tabelul Excel este construit pe baza specificației Drools legată de tabelele de decizie (subcapitolul 3.3 – Tabele de decizie), iar utilizatorii au fost învățați cum sa-l utilizeze fără a modifica primele 11 rânduri unde e implementată partea de Drools.

După editare, fișierele Excel sunt convertite de către sistem în fișiere de reguli Drools (.drl) , iar apoi aceste fișiere sunt doar copiate pe server, fiind interpretate runtime de către serverul JBoss.

4.10 – Exemplu de fișier de reguli generat pe baza unui fișier de reguli Excel

Folosind fișiere cu reguli, intervenția programatorilor în implementarea unei schimbări este minimizată, când aplicația va fi stabilă va fi necesar doar un inginer de sistem, responsabil pentru integrare.

4.11 – Secvență de cod responsabilă pentru conversia unui fișier Excel în reguli Drools

Execuția regulilor de către Drools se face conform secvenței de cod prezentate în subcapitolul 3.2. Implementarea în cazul real este ceva mai complexă datorită altor elemente ce intervin, dar logica rămâne aceiași.

4.12 – Secvență de cod ce evidențiază execuția regulilor

Capitolul 5 – Concluzii

Bibliografie

[1] Adrian A. Hopgood, Intelligent Systems for Engineers and Scientists, CRC Press 2001 (p.31)

[2] Denis Merritt, Building Expert Systems in Prolog, Amzi! Inc., 2000 (p. 1-3)

[3] Jay Liebowitz, The Handbook of Applied Expert Systems, CRC Press, 1997 (p. 5-5)

[4] Donald Arthur Waterman, A guide to expert systems, Addison-Wesley Publishing Company, 1986

[5] Dan W. Patterson, Introduction to Artificial Inteligence and Expert Systems, Prentice-Hall of India, 1990 (p.7, 13, 75-76)

[6] Ernest Friedman-Hill, JESS in Action, Manning Publications Co., 2003 (p. 136 -139)

[7] Michal Bali, Drools JBoss Relues 5.0 Developers Guide, PACKT Publishing, 2009

[8] Malcolm Chisholm, How to Build A Business Rules Engine: Extending Application Functionality Through Metadata Engineering, Morgan Kaufmann Series, 2003 (p. 5-6)

[9] E. Bauer, The business rule approach, University of Paderborn

[10] Tony Morgan, Business Rules and Information Systems: Aligning IT with Business Goals, Addison-Wesley, 2002 (p. 10 – 13)

[11] Geoffrey Wisemann, Real-World Rule Engines, InfoQ website, 2006

[12] Dorin Cârstoiu, Sisteme de baze de date distribuite, Cartea universitară, 2013 (p.60 – 61)

[13] http://docs.jboss.org/drools/release/6.0.1.Final/drools-docs/html/index.html

[14] http://docs.jboss.org/drools/release/5.3.0.Final/drools-expert-docs/html/

[15] http://en.wikipedia.org/wiki/Rete_algorithm