Papers we love: Solving the bank with rebel

 
01 juli 2017

Soms kom je een paper tegen waar een aantal dingen op een verrassende manier samenkomen. Voor mij was dit bij Solving the bank with rebel. Het gaat over DSL’s, twee van de auteurs zijn docenten van me geweest, het bedrijf waarbij het onderzoek in de praktijk is gebracht is een partner van Sogyo waar velen van ons mee bekend zijn en ik heb het met een collega al eens over dit onderzoek gehad, zij het op een informele manier en puur vanuit interesse.

Dan de inhoud: waar gaat het eigenlijk over? De paper begint met een introductie van de context van het bedrijf. Dit is een financiële dienstverlener en heeft een lange, rijke IT-geschiedenis. Hierdoor zijn r ook een groot aantal verschillende systemen en is er dus ook en behoorlijke weerslag op beheer en ontwikkeling van het bedrijf. Enerzijds is dit door het complexe landschap waarbij er sprake is van een groot aantal interacties tussen de verschillende systemen, anderzijds doordat veel kennis nu alleen is vastgelegd in code en daarmee dus minder toegankelijk is voor niet-IT’ers. In de gevallen dat er wel documentatie bestaat is er vaak sprake van Word-, of Excel documenten en zijn deze vaak jaren niet bijgehouden en is de evolutie van de beschreven systemen er niet in meegenomen.

Het bedrijf streeft ernaar om het interne IT-landschap flink te moderniseren (zie o.a.). De kennis die nu dus in verschillende plekken is vastgelegd zal dus moeten worden verplaatst en vermoedelijk ook worden gecentraliseerd. Daarnaast is er sinds de bankencrisis van 2008 ook een duidelijke nieuwe trend ontstaan waarbij zaken als transparantie en accountability veel belangrijker zijn geworden. Om het bedrijf daarnaast snel te kunnen laten reageren op veranderingen in de markt is het ook wenselijk als de tijd tussen het opstellen en het valideren van requirements zo kort mogelijk kan zijn.

Omdat veel software van het bedrijf zich in het hetzelfde domein (financiële, klantrelatie) afspeelt is er een domein specifieke, formele specificatie taal genaamd ‘Rebel’ gecreëerd. Hiermee is het mogelijk om, voor het domein specifieke, constructies uit te drukken in code. Dit kan op een erg declaratieve manier, wat vervolgens ook nog gevisualiseerd kan worden.

Daarnaast is er ook een mogelijkheid om specificaties te verifiëren en hier simulaties van te draaien waarbij scenario’s kunnen worden uitgetest. De kracht van het eerste is dat er invarianten kunnen worden gedeclareerd waarbij je dus bepaald gedrag kunt afdwingen. In de paper wordt er een voorbeeld gebruikt waarbij er een betaalrekening is die geen negatief saldo mag hebben. Om deze invariant af te dwingen kan er met een model checker gekeken worden of deze invariant inderdaad stand houdt gegeven de toegestane mutaties.

Een tradeoff hierbij is dat er geen volledig bewijs volgt dat het model correct is, maar allen dat er geen tegenbewijs is gevonden dat het niet klopt. Hiermee kan er en functionele afweging worden gemaakt tussen doorlooptijd (beperkte hoeveelheid tijd om te verifiëren) en correctheid (accepteren van een kleine kans op onvolledigheid) waardoor er van een praktische en bruikbare verificatieslag gebruik gemaakt kan worden. Mocht er en overtreding van een van de opgegeven constraints worden gevonden dan wordt de trace van acties die zijn uitgevoerd teruggegeven zodat deze ook direct gereproduceerd kan worden.

Voor het uitvoeren van simulaties wordt de applicatie als een state machine gevisualiseerd. Er kunnen vervolgens per state ook alleen acties worden uitgevoerd die volgens de specificatie toegestaan zijn. Door de simulatie in te zetten kan er vroegtijdig in het ontwikkelprocess al door de business worden gecontroleerd of de software aan de verwachtingen voldoet. Het risico op een mismatch tussen enerzijds verwachtingen en anderzijds opgeleverde software wordt hiermee verkleind.

Het mooiste van deze paper vind ik de sectie “applying Rebel inside the Bank” waarbij er een deel van de producten die een vorm van een spaarrekening aanbieden zijn uitgewerkt in Rebel. Hierbij is er een scenario gevonden waarin de bestaande applicaties foutief gedrag zouden kunnen vertonen. Nu ging dit weliswaar om een “unlikely but real” scenario, maar er is wel en manco in de huidige software ontdekt.

Daarnaast is er ook expliciet een validatie geweest van de interne aannames over het domein. De initiële verwachting was dat bestaande product owners overweg zouden kunnen met de textuele specificatie van Rebel. Tijdens de evaluatie bleek dit echter niet zo te zijn en is er dus, naast de textuele variant, ook een mogelijkheid om een interactieve “documentatie” te genereren. Dit laat weer eens zien dat we altijd kritisch moeten zijn over de aannames die we maken, een valkuil waar we als beroepsgroep helaas nogal eens inlopen.


Over deze papers we love: binnen Sogyo hebben we de traditie dat we maandelijks een nieuwsbrief rondsturen. De nieuwsbrief gaat veel over interne feitjes, echter sinds februari 2015 verzorgd Kevin van der Vlist het topic: papers we love. Hij deelt met ons papers die interessant zijn om te lezen en ons kunnen inspireren. De topic is uitgegroeid tot een mooie verzameling die we ook graag hier willen delen.


Werken met ?
Kijk dan bij onze mogelijkheden voor zowel starters als ervaren engineers.


Categorieën: Gave Technologie


Plaats een reactie

Jouw emailadres wordt nooit gepubliceerd of gedeeld. Benodigde velden zijn met * gemarkeerd.