[alg] document generatie met complexe logica.

[Alarmnummer]

Wat voor techniek gebruiken jullie om documenten te genereren waarin complexe logica zit zoals of iemand in aanmerking komt voor een lening (kan van veel dingen afhangen), of iemand dit jaar genoeg verdient heeft om een bepaald formulier in te vullen.

Waar plaatsen jullie de logica? Zit alles bij elkaar ingeplakt? Dus de complexiteit van enterprise applicaties (databases, transacties), de complexiteit van de businesslogic (of je in aanmerking komt voor een lening) en dan nog een keer de visuele opmaak.

Ik ben op dit moment bezit met de ontwikkeling van een ruleengine en ik wil met een eenvoudige koppeling deze ruleengine kunnen aanspreken van een template engine zoals velocity. Hierin kan het document mooi opgemaakt worden zonder dat je met de enterprise of businessrules problematiek hoeft te prutsen. Verder heeft de ruleengine ook de mogelijkheid om de database te raadplegen of om de gebruiker te vragen om informatie. Aan de hand van een vragensessie met een gebruiker kunnen dus redelijk complexe documenten opgezet worden.

Op deze manier krijg je dus een strakke scheiding tussen de 3 lagen.

Wat vinden jullie van dit idee? Weten jullie betere of andere oplossingen?


[edit]

code:

Hallo 
#if $engine.requestBool("is_man")
Meneer,
#else
Mevrouw,

we hebben op $engine.requestDatum("datum_overtreding") opgemerkt dat u 
veel te hard heeft op de $engine.requestString(locatie_overtreding). 

#if $engine.requestBool("rijbewijs_kwijt")
Daarom nemen we u rijbewijs af.
#else
Daarom komt u er dit keer vanaf met een waarschuwing.

Kusjes kusjes kusjes:
#if $engine.requestBool("agent_is_man")
Meneer agent.
#else
Mevrouw agent.

En dan een paar regels voor het kwijt raken van je rijbewijs:

code:

snelheidsovertreding = waargenomen_snelheid - toegestane_snelheid.
if snelheidsovertreding>50 then rijbewijs_kwijt.
if gedronken then rijbewijs_kwijt.
if voertuig = lada then rijbewijs_kwijt.

[ Voor 33% gewijzigd door Alarmnummer op 05-09-2004 16:53 ]

[Tomatoman]

Een algemene benadering voor zit soort problemen kan het gebruik van workflow managementsysteem zijn. Daarbij definieer je de workflow (in jouw geval een geautomatiseerd beslissingsproces) aan de hand van een soort stroomschema. De 'intelligentie' en het beslissingsmodel definieert de gebruiker door een workflowproces op te tuigen, de business logic is generiek en zit in het workflow managementsysteem ingebouwd. Het grote voordeel van deze benadering is dat je met een generieke tool specifieke beslissingsprocessen kun modelleren. De acties die onderweg worden uitgevoerd, zouden in jouw geval kunnen bestaan uit het invullen van een aantal variabelen die worden gebruik om het document te formatteren. In de verzekeringswereld zijn workflow managementsystemen een bekende manier voor bijvoorbeeld schadeafwikkeling of beoordeling van nieuwe aanvragen. Het is niet direct een antwoord op je vraag, maar je kunt je er eens in verdiepen.


Voor een leasemaatschappij heb ik ooit een model gevalideerd dat een preselectie deed bij financieringsaanvragen. De input bestond uit gegevens uit de balans en verlies- en winstrekening, de output bestond uit één van de twee volgende beslissingen:
• de leaseaanvraag wordt afgewezen;
• de leaseaanvraag wordt in behandeling genomen door een medewerker.
Het aanvankelijke model was gebouwd in Excel en dat bleek prima te voldoen voor dit specifieke geval. Alles zat bij elkaar ingeplakt.

De beoordeling bestond uit twee stappen. Als eerste waren er een paar knock-out-criteria. Was er bijvoorbeeld een negatief eigen vermogen, dan werd de aanvraag afgewezen. Als de knock-out-criteria waren gepasseerd, werden een aantal financiële gegevens vertaald in afzonderlijke scores. Het totaal van deze scores moest een bepaald minimum overschrijden om de leaseaanvraag door een medewerker in behandeling te laten nemen. In het uiteindelijke model werd via een webapplicatie de preselectie gedaan. Uiteraard was de opgemaakte webpagina helemaal onafhankelijk van het beoordelingsmodel. Het model leverde eenvoudigweg een uitkomst aan die als basis voor de berichten op het scherm diende.


[Edit]
Jouw benadering gaat uit van een engine die tijdens het genereren van de brief de variabelen berekent. Dat lijkt me geen goede benadering. De aard van de brief wordt immers bepaald door het resultaat dat de engine heeft geleverd en de engine moet derhalve al klaar zijn met het bepalen van de variabelen voordat de brief in elkaar wordt gezet. Jij kijkt met je eigen opzet pas halverwege de brief of het een 'u bent stout geweest' brief wordt of een 'u moet uw maandelijkse bijdrage nog betalen' brief. Dat impliceert dat je voor beide brieven dezelfde template gebruikt. Niet handig lijkt me, je kunt beter twee verschillende templates gebruiken, waarbij de engine de keuze maakt welke template van toepassing is.

[ Voor 16% gewijzigd door Tomatoman op 05-09-2004 17:58 ]

[Alarmnummer]

tomatoman schreef op 05 september 2004 @ 17:42:
Jouw benadering gaat uit van een engine die tijdens het genereren van de brief de variabelen berekent. Dat lijkt me geen goede benadering. De aard van de brief wordt immers bepaald door het resultaat dat de engine heeft geleverd en de engine moet derhalve al klaar zijn met het bepalen van de variabelen voordat de brief in elkaar wordt gezet. Jij kijkt met je eigen opzet pas halverwege de brief of het een 'u bent stout geweest' brief wordt of een 'u moet uw maandelijkse bijdrage nog betalen' brief. Dat impliceert dat je voor beide brieven dezelfde template gebruikt. Niet handig lijkt me, je kunt beter twee verschillende templates gebruiken, waarbij de engine de keuze maakt welke template van toepassing is.

Het is uiteraard niet de bedoeling dat iedere mogelijke brief hierin opgemaakt gaat worden. Maar in 1 template brief kunnen wel verschillende variaties in uitgedrukt worden. Misschien had de overledene wel kinderen of niet. Je wilt niet voor iedere mogelijke situatie een aparte brief gaan maken.

En het is verder een mogelijkheid en geen verplichting om aan de hand van een vragensessies een brief te laten invullen (dus de engine te laten draaien tijdens het invullen van de template). Bv een belasting formulier. Goaldriven ruleengines zijn erg handig om op een efficiente manier informatie uit gebruikers te trekken omdat geen vragen gesteld worden waarvan de antwoorden er toch niet toe doen.

In de verzekeringswereld zijn workflow managementsystemen een bekende manier voor bijvoorbeeld schadeafwikkeling of beoordeling van nieuwe aanvragen. Het is niet direct een antwoord op je vraag, maar je kunt je er eens in verdiepen.

Ik weet eerlijk gezegd niet wat een workflow management systeem nu precies doet. Maar ik neem aan dat intern een collectie met regels staan die geevalueerd worden, en dan is het in essentie een ruleengine/expertsysteem. En dat is ook exact hetgene wat wij oa willen leveren.

[ Voor 22% gewijzigd door Alarmnummer op 05-09-2004 18:25 ]

[Antediluvian]

Ik denk dat je best een hiërarchische beslissings engine maakt waarbij iedere vraag uiteen getrokken is zodat je eventueel een andere hiërarchie dynamisch kan bepalen.
Bv: je hebt 5 beslissingenpunten die elk hun input en output hebben.

Zo kan je voor een bepaald document/input/situatie een beslissingsboom vastleggen, bv:

code:

A: ->True:  B
   ->False: C
B: ->True:  D
   ->False: D
C: ->True:  D
   ->False: E
...

Op het einde van de verwerking van de boom zouden al je benodigde variabelen moeten opgevuld zijn, bv:

code:

A zet bij true:  BriefTemplate = Waarschuwing
                 Boete += 0 EUR
A zet bij false: BriefTemplate = Boete
                 Boete += 10 EUR
B zet bij true:  BriefTemplate = Boete
                 Boete += 15 EUR
B zet bij false: BriefTemplate = Boete
                 Boete += 50 EUR
...
E zet bij true:  BriefTemplate = Arrestatie
                 Boete = onbepaald

Op die manier zijn er de verschillende beslissingspunten te hergebruiken voor verschillende situatie; bv: een wegcontrole gebruikt boom 1 en een thuiscontrole gebruikt boom 1.

Het is eventueel ook mogelijk om voor de bepaling van de template een additief systeem te gebruiken waarbij bv de waarde 1 gelijk is aan een waarschuwing en waarde 10 gelijk is aan een arrestatie.

Het enige dat je dan moet doen vanuit de front end is parameters opvullen, een bepaalde beslissingsboom kiezen (eventueel naargelang van de parameters) en dan na de verwerking de resultaat parameters terug opvragen en het document met de gedefinieerde template opmaken opmaken.

[ Voor 3% gewijzigd door Antediluvian op 05-09-2004 20:33 ]

[Alarmnummer]

Ik zie niet in waarom je zo moeilijk moet gaan doen.

Ik gebruik gewoon een ruleengine om mijn document van informatie te voorzien. Als het document informatie nodig heeft, moet de juiste query aan de ruleengine gesteld worden en de ruleengine zal proberen om een antwoord af te leiden. Misschien moet de gebruiker gevraagd worden, misschien een database, misschien moeten andere regels opgelost worden of misschien zijn er defaults. De template hoeft hier niet van op de hoogte te zijn. Hij weet dat de ruleengine zijn queries kan oplossen en hoe dat dus gebeurt, is voor hem niet interessant.

Een paar regels uit een oud systeem waar ik mee bezig ben geweest:

code:

    //---------------------------------------------------------------
    //Feitelijke leeftijd van de betrokkene
    //---------------------------------------------------------------
    If 
        Leeftijd_betrokkene >= 16
    Then
        Leeftijd_betrokkene_is_16_of_ouder := TRUE
    Else 
        Leeftijd_betrokkene_is_16_of_ouder := FALSE;
    
        
    //---------------------------------------------------------------
    //Toepassing Opportuniteitsbeginsel, MvA 27 745, 17 juni 2002, art 167 lid 2 & 242 lid 2 WvSv
    //---------------------------------------------------------------
    IF 
        NOT Afbeelding_is_door_verdachte_zelf_vervaardigd
    Then
        Afbeelding_vervaardigd_met_instemming_betrokkene := FALSE
    ;
    
    IF
            Afbeelding_vervaardigd_met_instemming_betrokkene
        AND
            Afbeelding_vervaardigd_voor_eigen_gebruik_betrokkene
        AND
            Leeftijd_betrokkene_is_16_of_ouder
    Then    
        //De afbeelding is vervaardigd met instemming en voor eigen gebruik van de betrokken 16 of 17 jarige
        Geen_noodzaak_voor_strafrechtelijk_optreden_door_toepassing_opportuniteitsbeginsel := TRUE
        Source_url := "file:projects/kinderporno/bronnen/bagattel.htm"
    Else
        Geen_noodzaak_voor_strafrechtelijk_optreden_door_toepassing_opportuniteitsbeginsel := FALSE
        Source_url := "file:projects/kinderporno/bronnen/bagattel.htm"
    ;

[ Voor 56% gewijzigd door Alarmnummer op 05-09-2004 20:45 ]

[unclero]

Ik ben persoonlijk van mening dat bij een dergelijk systeem een logischer programmeertaal beter is dan een procedurele programmeertaal.

Dus in plaats van procedures te gaan definieren, ga je alleen de regels zetten waar het aan voldoet. Een en ander vergelijkbaar met Prolog.

Voorbeeld:

code:

REGEL HuurSubsisidie(loon,huurprijs,leeftijd)

PRIORITEIT
     HuurSubsidie(loon,,):
          (loon > minimum_loon) = Nee.
     HuurSubsidie(,huurprijs,):
          (huurprijs > maximum_prijs) = Nee.
     HuurSubsidie(,huurprijs,leeftijd):
          (huurprijs < maximum_prijs)&&(leeftijd > leeftijdscategorie(huurprijs)) = Nee.
     enz...

*mompel* bij mij op het bedrijf gebruiken we zo een zelfontwikkelde logische programmeertaal om complexe taalkundige constructies op te kunnen bouwen.

[Alarmnummer]

unclero schreef op 06 september 2004 @ 14:27:
Ik ben persoonlijk van mening dat bij een dergelijk systeem een logischer programmeertaal beter is dan een procedurele programmeertaal.

Mee eens. De ruleengine heeft als basis een door ons/mij zelf ontwikkelde prolog core met heel veel mooie extra`s zoals exceptions, module systeem, datadriven rules (binnenkort) en valt naadloos te integreren met java enterprise omgevingen omdat het dus helemaal ontwikkeld is in Java (en in het ontwerp er ook rekening mee is gehouden)

*mompel* bij mij op het bedrijf gebruiken we zo een zelfontwikkelde logische programmeertaal om complexe taalkundige constructies op te kunnen bouwen.

Koel

[ Voor 5% gewijzigd door Alarmnummer op 06-09-2004 16:18 ]