Introductie 

De Nederlandse Belastingdienst heeft in de jaren 2008 en 2009 geprobeerd de complexiteit van de IT systemen te reduceren. De poging mislukte, omdat bleek dat de gekozen oplossingen uiteindelijk complexer werden dan de te reduceren problemen. Echter, een aantal projectleden gingen verder in eigen tijd. Zij waren er van overtuigd dat de zogenaamde “Rule based Approach” de Belastingdienst kon helpen in het verminderen van complexiteit en de kennis van de bestaande systemen te beheren. Uit het resultaat van deze inspanningen is het SpecificatieTeam voortgekomen.

In 2008 werd als regelsysteem gebruik gemaakt van Blaze Advisor van de FairIsaac Company (FICO). Alle regels van de Inkomstenbelasting werden geschreven in SRL (Structured Rule Language). Het team werd daardoor beïnvloedt door de “Rule based Approach” (het regel-gebaseerd werken). We weten inmiddels dat het belangrijk is bedrijfsregels op te schrijven in een taal die begrepen wordt door de “Business”. Omdat juristen en advocaten daardoor in staat zijn de regels te lezen, zijn ze ook in staat om de regels te valideren en zelfs te schrijven! Daarnaast wil het team dat de regeltaal zo strikt mogelijk is, vergelijkbaar met SRL, en maar op één manier te interpreteren. Als gevolg daarvan zal een machine de regels óók kunnen lezen. De taal, die we daarvoor ontwikkeld hebben, hebben we RegelSpraak genoemd.

Het SpecificatieTeam 

Om deze keer wel te kunnen slagen, zijn we op het idee gekomen een multidisciplinair team samen te stellen, een team dus waarvan de leden een verschillende achtergrond hebben. We zijn met 3 personen gestart. Gedurende de looptijd van het project zijn er leden bijgekomen en weer weggegaan. Op dit moment bestaat het SpecificatieTeam uit een interessante selectie expertises:

  • Op het gebied van Repositories (RuleXpress)
  • Wetten en wetteksten (fiscalisten)
  • Taal en patronen (regels, natuurlijke taal)
  • Helpdesk (damage en requirements)
  • Software ontwikkeling (databases, compilers, user interfaces)
  • Kunstmatige Intelligentie (user experience)
  • Domain deskundigen (inkomstenbelasting, BTW, douane, enz.)
  • Metagegevens (business en technisch)

 

RegelSpraak 

RegelSpraak is de Nederlandse vertaling van het woord RuleSpeak. RuleSpeak was ons vertrekpunt en van daar uit hebben we RegelSpraak ontwikkeld.

Op het moment dat we er aan begonnen, hadden we al erg veel regels in SRL, die we vervolgens zo veel mogelijk hebben herschreven als RuleSpeak statements. Vervolgens hebben we ook aan “code-mining” gedaan. We haalden de voorwaarden (regels) uit bestaande legacy stuur-tabellen, MS-Word documenten en programma code en vertaalden die naar RuleSpeak. Uiteindelijk verkregen we op die manier ongeveer 3000 regels en 4500 termen.

Onze beheer applicatie is op dit moment RuleXpress. Met behulp van dit gereedschap beheren we regels en termen. De Nederlandse Belastingdienst gebruikt een veelheid aan systemen en elk individueel systeem heeft zijn eigen termen. Het resulteert in veel synoniemen en homoniemen. Vanuit alle verschillende bestaande termen hebben we een unieke verzameling gedefinieerd en gebruiken deze termen in onze regels. De synoniemen worden aan deze termen verbonden, zodat de termen die oorspronkelijk in de systemen werden gebruikt weer kunnen worden opgehaald.

De termen en regels moeten worden gevalideerd en wijzigingen moeten worden toegevoegd. Hier ontstaat een probleem. De personen die in staat zijn om te valideren zijn dezelfde personen die de

bestaande systemen moeten onderhouden. Er moet dus een keuze worden gemaakt.

Keuze één is dat deze mensen hun normale werk blijven doen en de oude stuurtabellen aanleveren. In dit geval moet het SpecificatieTeam nieuwe en gewijzigde regels synchroniseren met de repository en kan er niet worden gevalideerd. Het voordeel is wel dat er geen verstoring optreedt met de bestaande legacy systemen. Die worden immers nog opgeleverd volgens de release/versie/patchlevel methode. Het gebrek aan tijd en capaciteit maakt dat dit een slechte keuze is.

Keuze twee is dat deze mensen direct nieuwe en gewijzigde regels in RuleSpeak met de editors van RuleXpress schrijven. Het voordeel is dat er meteen wordt geprofiteerd van regel-gebaseerd werken. Met de huidige werkwijze is het nodig om elk jaar een systeem in zijn geheel te kopieren, en dat is een hoop werk. Door te werken met regels die een begin- en/of einddatum van geldigheid hebben, wordt het eenvoudig om met delta’s te werken. Het voordeel is dat de regels kunnen worden gevalideerd en dat de Belastingdienst direct profiteert van regel-gebaseerd werken. De uitdaging is om onze RuleSpeak regels zodanig te transformeren dat de bestaande legacy systemen er mee kunnen worden gevoed.

Op dat moment werd RegelSpraak geboren. We sorteerden onze verzameling regels en voegden extra meta-gegevens toe. Onze regels voldoen aan bepaalde patronen. Voor elk patroon is een patroon beschrijving gemaakt. We staan alleen regels toe die aan deze patronen voldoen. We dwingen onszelf om dat te doen. De eigenschap van RegelSpraak is dat de regels de patronen strikt volgen, en dat de regels toch in Natuurlijke Taal geschreven zijn. Zodra men regels schrijft die aan een patroon voldoen, dan is men (in het algemeen) in staat om er een syntax controle op los te laten.

Regels die syntactisch correct zijn, kan men compileren. Compileerbare regels kunnen worden geïnterpreteerd of uitgevoerd. Op deze manier kunnen we onze RegelSpraak regels in elk ander gewenst formaat transformeren en er zelfs onze bestaande lecacy systemen mee voeden. Ergo, met RegelSpraak hebben we de beschikking over uitvoerbare (executable) regels.

 

RegelSpraak Compiler 

Met dat we voor keuze twee kozen, realiseerden we ons dat we naar een compiler moesten zoeken. Een compiler voor RegelSpraak bestaat niet, dus hebben we die zelf gemaakt. We herschreven de patronen als formele grammatica regels. Voor elk domein ontwikkelden we een zogenaamd G-bestand. Grammatica bestanden kunnen worden gecompileerd tot een compiler, met gereedschap dat daar speciaal voor is gemaakt (compiler compiler).

Voor de constructie en ontwikkeling van een grammatica bestand maken we gebruikt van de ANTLRWorks GUI workbench. Op iteratieve wijze ontwikkelen we grammatica’s voor elk domein. Deze grammatica’s controleren of de RegelSpraak syntactisch correct is. Zodra ieder mogelijk RegelSpraak statement herkend wordt, kan een compiler worden gegenereerd. We willen de compilers echter niet alleen voor syntax controle gebruiken, we willen er ook zogenoemde productie regels aan toe voegen op bepaalde plaatsen tijdens de herkenningsfase. Het resultaat hiervan is dat een bepaalde RegelSpraak compiler uitvoer kan produceren in elk gewenst formaat.

We hebben inmiddels compilers gebouwd voor een aantal van onze legacy systemen. Een voorbeeld hiervan is de “fiscale voorcontrole”; dit systeem controleert op fiscale correctheid van de gegevens die door de belastingbetaler worden aangeleverd. De RegelSpraak statements, die verzameld worden in een verzameling die wij “fiscale voorcontrole” hebben genoemd, worden gecompileerd naar een spreadsheet met diverse tabbladen (Microsoft Excel). Deze spreadsheet vormt direct de stuurtabellen voor een bestaand (legacy) syteem.

Een ander voorbeeld is de “rekenserver”. De RegelSpraak statements worden gecompileerd naar technisch ontwerp documenten in de vorm van PDF bestanden. Hier wordt ook de bestaande legacy bediend. Op dit moment worden PDF documenten met de hand vertaald naar COBOL/CICS en C-code. Het is denkbaar om direct naar COBOL en/of C-code te compileren. Pre- en post-conditie regels kunnen ook als RegelSpraak statements worden geschreven. De ontwikkeling van de

bijbehorende patronen en van daaruit de bijbehorende grammatica levert ons een compiler die zowel in staat is ons de formele constructie van de Rekenserver te geven, als de programma code (Cobol, C, Java, Blaze, enz.)!

Door het allemaal op deze manier te doen, hebben we aangetoond dat het mogelijk is om regels te schrijven in Nederlandse Natuurlijke Taal, die kunnen worden gelezen door mensen (deskundigen). Tegelijkertijd kunnen dezelfde regels (omdat ze zo strikt zijn geformuleerd) worden gelezen en verwerkt door een computer. Het toont tevens aan dat RegelSpraak kan worden getransformeerd naar elk denkbare vorm.

 

Compileren 

Om de statements voor een bepaalde verzameling in zijn geheel (als batch) te kunnen compileren, gebruiken we het ANTRL gereedschap in de vorm van Eclipse plugins.

Een grammatica bestand wordt getransformeerd in een lexical analyzer en een parser. RegelSpraak statements worden herkend door de analyzer, omgevormd tot tokens, en op sytax gecontroleerd door de parser.

RuleXpress heeft een filter mechanisme wat ons helpt om een XML rapport samen te stellen voor een bepaalde verzameling. Dit rapport bevat zowel de termen (en als zodanig de meta-gegevens) als de regels. De regel zelf wordt technisch gezien geëxporteerd als een tag. Deze tag bevat ofwel een tag voor reguliere tekst (gepresenteerd als zwrte tekst in de GUI), ofwel een tag voor termen (blauw onderstreept in de GUI).

Het onderscheid tussen tekst of een term alleen is niet genoeg voor onze compilers. Daarom voegen we een profiel attribuut aan de meta-gegevens toe. Een Java StatementReader klasse leest het XML bestand en haalt daar de tags uit. Door die te combineren met de profiel attributen ontstaat een RegelSpraak statement. Dit statement “weet” of een term een standaard term is, ofwel een rol, een functie of een enumeratie, of anderszins.

Een Java SpreadSheet klasse transformeert statements naar een Microsoft Excel Spreadsheet. Een Java RekenServer klasse transformeert statements naar PDF documenten. enzovoort …

Gedurende de “proof-of-concept” fase hebben we ook experimenten gedaan om RegelSpraak te compileren naar HTML web pagina’s inclusief JavaScript en CSS ondersteuning, en er aldus interactieve formulieren van gemaakt. Door er JSP gecodeerde pagina’s van te maken en deze op een web server te zetten (Sun Glassfish), verkregen we formulieren met logica (berekeningen) vanuit dezelfde verzameling regels.