Softwaretooling - Error!

42 | 3
Achtergrond Modelgebaseerde ontwikkeling
Statemachines modelleren doen we in de
informatica al meerdere decennia. Van
oudsher ligt het accent daarbij op speci-
catie, ontwerp en documentatie. De laatste
jaren zijn hier engineeringaspecten bij gekomen,
zoals modelanalyse, modelvericatie
en codegeneratie. De voordelen hiervan zijn
overduidelijk: minder ontwerp- en implementatiefouten,
zodat we een aanzienlijke
winst kunnen bereiken in productiviteit.
Toch blijft het oppassen. Tools die toestandsdiagrammen
veriëren, hebben namelijk
hun beperkingen. Ten onrechte rekent een
ontwikkelaar er soms op dat een succesvolle
vericatie een garantie is voor het genereren
van foutvrije broncode. Neem de ervaringen
van Ericsson met de ASD:Suite (Bits&Chips
8, 2012). De ontwikkelaars in Rijen lijken niet
te beseen dat Verums claim van foutvrije
code uitsluitend geldt voor de geverieerde
eigenschappen van de statemachines, zoals
deadlocks en onvoorziene stimuli.
Gegenereerde code zou honderd procent
foutvrij zijn als de softwareontwikkelaars onfeilbaar
zijn. In dat hypothetische geval zou
het gebruik van een vericatietool echter volstrekt
overbodig zijn. In de praktijk kunnen
in geverieerde modellen nog tal van onvolkomenheden
verborgen zitten. Ik zal dat illustreren
aan de hand van twee voorbeelden.
In deze voorbeelden is er sprake van interactie
tussen een client- en een servercomponent.
De communicatie van de client
naar de server bestaat uit synchrone functieaanroepen;
de informatie-uitwisseling
de andere kant op loopt via asynchrone
callbacks. De server brengt deze callbacks
onder in een queue, waar ze worden afgehandeld
door een aparte thread.
De interactie tussen client en server kunnen
we beschouwen als een protocol en
speciceren met twee protocolstatemachines
(PSM’s). De ene PSM beschrijft de interface
voor de rol van de server, de andere
doet dat vanuit de clientrol. Om beide duidelijk
te kunnen beschrijven, gebruiken we
twee UML-stereotypes – zelf te deniëren
eigenschappen die we aan een object kunnen
toekennen. Een NativeTrigger-stereotype is
een interne trigger die binnen een object
Valkuilen bij statemachineverificatie
Een succesvolle verificatie is geen garantie voor het genereren van foutvrije broncode.
Gebruikers van bijvoorbeeld ASD moeten op hun hoede blijven voor deadlock en
andere problemen, zoals Tis Veugen illustreert aan de hand van twee voorbeelden.
Tis Veugen
(client of server) optreedt en een transitie
tot gevolg heeft met een bijbehorende actie.
Een Ignore-stereotype bij een zelftransitie
geeft aan dat de stimulus wordt ‘verwerkt’
zonder enige actie te ondernemen.
Sessiemanagement
Het eerste voorbeeld komt uit de ASD-praktijk.
De problematiek geldt evenwel voor
willekeurig welke vericatietool. Om het
voorbeeld algemeen te houden, heb ik de namen
van de objecten en functies gewijzigd.
Het handelt om een deur (of een lade van
een dvd-speler) die voortijdig kan worden
geopend of gesloten.
Figuur 1 toont de PSM voor de serverrol.
Deze statemachine start altijd in de toestand
Closed, met een gesloten deur. De client kan
met de functie Open() verzoeken de deur te
openen. Het uitvoeren van deze beweging gebeurt
in de toestand Opening. Als de server
de deur volledig heeft geopend, wordt de callbackfunctie
CbOpened() uitgevoerd, gevolgd
door de transitie naar de toestand Opened.
Op eenzelfde wijze kan de deur weer worden
gesloten. De client kan een lopende activiteit
voortijdig onderbreken door in de toestand
Opening een Close()-call te doen om de
deur te sluiten, of in de toestand Closing een
Open()-aanroep om de deur te openen.
De PSM vanuit het oogpunt van de client
staat weergegeven in Figuur 2. Deze statemachine
ziet er wat onoverzichtelijk uit
door de callbacks die nog onderweg kunnen
zijn. In de meeste gevallen kunnen we die
echter negeren. Dit modelleren we expliciet
met de zelftransities waaraan het stereotype
Ignore is gekoppeld. Merk op dat er een
groot verschil is tussen een te negeren trigger
en een niet-gemodelleerde trigger die
wel optreedt in een toestand. In het laatste
geval zou er sprake zijn van een bug in het
protocol of in de aanroepende component.
Een vericatietool kan via trial-and-error
helpen om de te negeren callbacks compleet
krijgen. Uiteindelijk zal vericatie van het
PSM-paar succesvol zijn. Toch is de correctheid
van de statemachines slechts schijn. Bedenk
maar eens wat er gebeurt als de client
de calls Open(), Close() en Open() achter el-
Figuur 1: De serverrol in het deurprotocol
Figuur 2: De clientrol in het deurprotocol
Figuur 3: Verbeterde serverrol in het deurprotocol
Figuur 4: Verbeterde clientrol in het deurprotocol