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

Transcriptie

1 Samenvatting RegelSpraak is een Nederlands RuleSpeak dialect. Het is een gestructureerde Nederlandse Natuurlijke Taal. RegelSpraak is opgebouwd volgens vooraf gedefinieerde patronen. Deze patronen kunnen ook worden geschreven als formele grammatica. Deze grammatica kan worden gecompileerd naar een bepaalde RegelSpraak Compiler, afhankelijk van het domein.

2 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 codemining 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

3 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

4 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 <statement> tag. Deze tag bevat ofwel een <text> tag voor reguliere tekst (gepresenteerd als zwrte tekst in de GUI), ofwel een <termref> 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 <statement> 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. Asserted Versioning Op dit moment zijn de meeste IT systemen gebouwd volgens de versie/release/patlevel methode. In praktijk komt dat neer op het kopieren van de meest recente (tagged) release, om van daarui t de nieuwe ontwikkeling in te zetten. Wanneer parallel wordt ontwikkeld, worden aftakkingen gemaakt, die later weer worden samengevoegd. Optredende conflicten worden met de hand opgelost. Wij willen het regel-gebaseerd werken adopteren. Dat vrijwaart ons van releases en versies. Door het mechanisme van geldigheid van een regel, met een bepaalde waarde voor begindatum en een bijbehorende waarde voor einddatum, heeft men alleen nog te maken met delta s. De les die we geleerd hebben uit de projecten van 2008/2009, vertelden ons op te passen en bewust te zijn van complexe situaties die optreden zodra je met Tijd gaat werken! Een elegante oplossing wordt geboden door gebruik te maken van bi-temporele gegevens. Bi-temporeel werken is geen eenvoudig onderwerp, maar indien correct toegepast bevrijdt het je wel van heel veel complexiteit! Het voordeel van bi-temporeel werken is, dat het praktisch mogelijk wordt om te Tijdreizen. Het is dan

5 mogelijk om naar een versie van een term of regel te verwijzen die geldig is op een bepaalde periode in de tijd. Ook is het mogelijk naar een vorige versie ervan te verwijzen die (toevallig) fout was, maar geldig gedurende dezelfde periode. Bi-temporele databases zijn zeldzaam, dus hebben we er zelf een implementatie voor gebouw d rond MySQL, conform de richtlijken van RichardT. Snodgrass. We creëerden onze bi-temporele tabellen in een MySQL database, 1) omdat het open source is, 2) het ondersteund JDBC, 3) het maakt deel uit van Glassfish, en 4) we hebben er ervaring mee. Er bestaan verschillende benaderingswijzen om bi-temporele tabellen te maken; wij kozen de variant met 1 primaire sleutel die gevormd wordt door een GUID. We moesten het framework ervoor zelf schrijven, dus dat hebben we gedaan. Alle tabellen hebben dezelfde structuur, dat wil zeggen een ID, bi-temporele attributen (2 datums en 2 datumtijd stempels) en een XML string. De XML string wordt gezien als een object. De XML objecten worden verwerkt met een Java DOM parser. Referentiele integriteit en domeinwaarden zijn in feite regels, dus in ons geval hebben we die niet als DDL geschreven (!) maar in RegelSpraak. ReguloParolo ReguloParolo is de Esperanto vertaling van het woord RegelSpraak. Gedurende de pilotfase en het gebruik van RuleXpress als beheeromgeving, zijn er ongeveer een 100-tal requirements ontstaan. Een regel beheeromgeving die aan alle door ons opgestelde eisen en wensen voldoet betaat vandaag de dag (nog) niet. Als team spreken we over ReguloParolo altijd als de ultieme gereedschap, die ons helpt om reg els en termen te beheren. Een van de meest belangrijke features is de ondersteuning van Tijdreizen en de integratie van historie (tracability) en de afwezigheid van versie/release/patchlevel nummer. Deze mechanismen zijn alle geïntegreerd in het gereedschap en (uiteraard) regel gebaseerd. ReguloParolo kan commercieel worden gebouwd, als open source worden ontwikkeld, of beide. We zijn om die reden een asset gestart op de site, genaamd reguloparolo. Dit zou een mogelijk tot samenwerking kunnen leiden. Bouwblokken Samenvattend is hier een lijst van wat we aan componenten gebruiken en/of wat we nodig hebben: RuleXpress als beheeromgeving (editor) voor de termen en de regels RegelSpraak als regeltaal ANTLR voor het genereren van compilers Eclipse voor Java ontwikkeling en ANTLR integratie SUN Glassfish Applicatie (Web) Server MySQL als (bi-temporele) database Notepad++ als editor voor XML- en vergelijkbare bestanden OSGi als Eclipse dynamisch class loader framework (bi-temporeel moet worden toegevoegd) ReguloParolo als paradigma en discussie platform voor regelbeheer