Pieter Edelman
4 september

De aandacht bij softwareontwikkeling ligt vaak helemaal op het invullen van functionaliteit; voor zaken als onderhoudbaarheid, architectuur en performance is geen tijd. Terwijl het niet moeilijk hoeft te zijn, denkt softwaretrainer Onno van Roosmalen. Maar er zijn misverstanden recht te zetten rond Agile, architectuur, UML, objectgeoriënteerd programmeren en test-driven development.

‘Modelleren? Dat doen we niet. Design-patterns? Slaan we over. Wij werken namelijk agile.’ Onno van Roosmalen hoort het regelmatig voorbijkomen: Agile als excuus of zelfs smoes om de architectuur van software niet serieus te nemen. Als trainer op het gebied van softwareontwikkeling ziet hij dat er veel misverstanden bestaan rond de zaken die te maken hebben met niet-functionele eisen: architectuur, interfaces, performance, modelleren, onderhoudbaarheid, noem maar op.

Misverstanden die overigens goed te verklaren zijn, want ze hebben te maken met het ongrijpbare begrip van ‘softwarekwaliteit’. ‘Kwaliteit is voor heel veel mensen niet zichtbaar’, vertelt Van Roosmalen. ‘Als het werkt, dan werkt het en dan denken managers, opdrachtgevers en gebruikers dat het wel klaar is. Dan wordt het wel lastig om te beredeneren waarom je iets extra moet doen. Maar ontwikkelaars krijgen dat in de praktijk heel duidelijk terug.’

Veel van de misverstanden over softwarekwaliteit leven ook onder ontwikkelaars zelf. Populaire softwaretechnieken zoals test-driven development dragen daar niet aan bij, denkt hij: ‘Test-driven development is helemaal op functionaliteit gericht. Aspecten die typisch gelinkt zijn aan architectuur, zoals performance, herbruikbaarheid, uitbreidbaarheid en software-evolutie, zijn heel moeilijk te testen. Net als racecondities en deadlocks.’

Het idee leeft ook dat architectuur iets abstracts is dat van te voren bedacht moet worden en vervolgens de richting van het project in een keurslijf dwingt – een big bang-architectuur die in één keer goed moet zijn. ‘Maar dat kan niet; vaak weet je niet wat er straks gaat komen’, legt Van Roosmalen uit. ‘Het is natuurlijk wel goed om een idee te hebben van hoe je het wilt inrichten. Maar je ziet soms dat projecten zich al helemaal gaan voorbereiden op bepaalde toevoegingen. Dan denk ik vaak: ‘Ja, en komen die er dan ook?’’

Daarnaast verstoft de onderliggende theorie in de loop der tijd. Hij merkt dat bijvoorbeeld goed in zijn basistraining rond objectgeoriënteerd ontwerpen en modelleren. Daar komen cursisten langs met bijvoorbeeld een elektrotechnische achtergrond, maar ook met een informaticadiploma op zak. ‘Toch zie je dat heel veel van hen problemen procedureel ontleden in plaats van objectgeoriënteerd’, vertelt Van Roosmalen. ‘Dat sluipt er toch in als mensen onder druk software maken. Terwijl je echt opmerkelijk betere software kunt maken als je de richtlijnen goed toepast.’

‘In C# is het niet zo’

Van Roosmalen zelf heeft een heel andere achtergrond: hij studeerde natuurkunde in Nijmegen en promoveerde bij het Kernfysische Versneller Instituut in Groningen. Vervolgens maakte hij de oversteek naar Amerika, voor een postdocpositie bij het California Institute of Technology.

Het keerpunt kwam in 1987. Van Roosmalen en zijn vrouw wilden eigenlijk wel terug naar Nederland, en de banen lagen in de natuurkunde niet voor het oprapen. Toen er bij de TU Eindhoven een positie vrijkwam in de technische informatica, besloot Van Roosmalen daarop in te springen; zijn werk op het gebied van computational physics had zijn interesse in software en computers gewekt.

Van Roosmalen merkte bovendien dat hij lesgeven leuk vond. Voor zijn terugkeer naar Nederland had hij al drie jaar gedoceerd aan Yale, en toen begin jaren negen de objectgeoriënteerde technieken opkwamen, begon hij met trainingen voor bedrijven. Na de millenniumwisseling besloot hij zijn aanstelling bij de TUE af te bouwen en zich volledig op trainingen te storten. Nog steeds voor de Eindhovense universiteit overigens, die hem inhuurt voor de PDEng-opleiding Software Technology.

Maar Van Roosmalen verzorgt dus ook trainingen voor ontwikkelaars die al een paar jaar in dienst zijn van een bedrijf. Een groot verschil met starters, merkt hij: hoe langer ontwikkelaars al achter het toetsenbord zitten, hoe ontvankelijker ze in de regel worden voor geavanceerde software-engineeringconcepten. ‘Je gaat dingen dan op een andere manier bekijken en je kunt ze denk ik wat meer op een rijtje zien. Het beklijft dan ook wat beter.’

‘In de meest objectgeoriënteerde programmeertalen kunnen objecten van dezelfde klasse bijvoorbeeld gewoon bij elkaars private attributen. Dat weten mensen vaak helemaal niet. Dan gaan ze het proberen, en dat blijkt dan te kloppen. En dan zeggen ze vaak iets van: ‘Maar in C# is het niet zo.’ En dan blijkt het daar precies zo te zijn’, geeft Van Roosmalen als voorbeeld. ‘Het lijkt elementair maar daar zitten belangrijke ideeën achter, en de meeste ontwikkelaars vinden het erg leuk om daar weer eens over te praten. De meeste trainingen gaan over het proces en zo, en niet over de techniek.’

Nov
28

Benelux RF Conference

Nijmegen

Learn about 5G, advanced technologies, powered by RF, radar, smart antennas

Defensief

Terwijl juist die kennis rond objectoriëntatie de basis vormt voor een groot deel van de architectuur in een typische applicatie. ‘Je krijgt daarmee vanzelf te maken met belangrijke software-eigenschappen als information hiding en encapsulatie, dus het idee dat je informatie lokaliseert en niet het hele systeem door gooit. In de praktijk zie je regelmatig dat een team een component van extra functionaliteit voorziet en dat er dan door het hele systeem dominosteentjes omvallen. Dat maakt het problematisch om iets toe te voegen. In veel webapplicaties zie je dat dat idee een beetje wordt gebroken’, aldus Van Roosmalen.

Nadenken over het verbergen van informatie gaat weer hand in hand met de manier waarop componenten elkaar aanspreken: de interface of api. ‘Daarmee kun je de gedetailleerde vorm van je objecten verbergen en zorgen dat er geen implementatiedetails naar buiten lekken. Je zorgt er dan voor dat de gebruiker alleen dát kan doen wat er nu wordt gevraagd, niet meer en niet minder’, legt Van Roosmalen uit.

Het idee daarachter is dat de evolutie van componenten zo kan worden ontkoppeld. Als een nieuwe versie van een component via een interface gewoon blijft doen wat hij voorheen deed, hoeft de software die erop gebouwd is niet direct aangepast te worden. Een ontwikkelteam dat tegen de component aan programmeert, kan de nieuwe versie rustig gebruiken zonder bang te zijn dat er in de tussentijd iets omvalt. Wanneer encapsulatie en interfaces op orde zijn, ontstaat dus bijna vanzelf een onderhoudbare, schaalbare architectuur die mee kan groeien met de toepassing.

De voorwaarde is wel dat teams zich defensief opstellen bij het ontwerpen van hun interface. ‘Je moet niet zomaar alles aanbieden wat andere teams vragen. Hoe meer je aanbiedt, hoe meer onbedoelde gebruiksmogelijkheden er zijn. De kans wordt dan groter dat dingen bij een nieuwe versie omvallen. Je kunt een interface later altijd uitbreiden, maar inkrimpen is een stuk lastiger’, stelt Van Roosmalen.

‘Ik heb daar een hele leuke workshop voor die ik met de TUE-trainees doe. Meerdere teams krijgen de opdracht om een component met een interface te ontwikkelen, en vervolgens moeten ze daar een functionele uitbreiding op maken – onverwacht natuurlijk; die hou ik geheim. Dan moeten ze proberen testcases te maken voor elkaars componenten die werken tegen de eerste variant, maar niet meer tegen de tweede. Dat zijn echt eyeopeners, want vaak is die testcase zo gemaakt.’

Trukendoos

Ontwikkelaars hoeven ook niet elke keer zelf het wiel uit te vinden. Voor veel problemen zijn er in de loop der jaren best practices vastgelegd, in de vorm van patterns. ‘Je kunt je architectuur bijvoorbeeld gelaagd inrichten: dat is een architectuur-pattern. Om de lagen zelf in te richten, gebruik je dan weer allerlei design-patterns.’

Van Roosmalen verzorgt een training geheel gewijd aan dit onderwerp. ‘Dat is natuurlijk heel breed, maar het idee erachter is vooral te laten zien dat je die trukendoos hebt. Eigenlijk is dat een van mijn favoriete trainingen, omdat je dan echt over softwareontwerp praat en omdat je er allerlei problemen uit de praktijk mee kunt aanpakken. Er komen ook hele andere technische aspecten bij kijken, zoals state machines met mogelijke deadlocks.’

Van Roosmalen verzorgt ook samen met een oud-collega van de TUE een vervolgcursus rondom een ander architectuurthema: realtime gedrag. ‘Typisch heb je het dan over problemen met systemen die verschillende taken tegelijk moeten uitvoeren waar tijdseisen aan worden gesteld. In de meeste moderne programmeertalen kun je tegenwoordig concurrent programmeren, en dat geeft hele aparte problemen zoals racecondities en deadlocks.’

Ook hier gaat het vaak in de basis al mis, merkt Van Roosmalen: ‘Heel veel mensen die realtimeproblemen hebben, gebruiken een besturingssysteem zoals Microsoft Windows. Tsja, dat is geen realtime operating system. Er zitten wel veel dingen in als realtime prioriteit enzovoorts. Maar er ontbreken heel veel andere dingen die ook noodzakelijk zijn voor realtime gedrag. Dan moet je een beetje op je hoofd gaan staan om het goed te krijgen.’

‘Je hebt in realtime systemen bijvoorbeeld te maken met het probleem van priority inversion, waarbij een taak met een lage prioriteit een resource claimt waardoor taken met hogere prioriteit daar geen gebruik van kunnen maken. Er zijn mechanismes om dat minimaal te houden, en die moeten in het operating system zitten.’

Vendor lock-in

Van Roosmalen verzorgt ook een basistraining rond Sysml, een variant van UML voor systeemengineering. Systeemengineers modelleren veel, maar toch wordt Sysml in de praktijk maar mondjesmaat gebruikt. Daar is een reden voor: ‘Er wordt voor systeemengineering heel veel gebruikgemaakt van commercieel beschikbare tools, zoals Matlab en Simulink. Dat zijn geen gestandaardiseerde modellen. Dat willen toolleveranciers ook helemaal niet, want dan raken ze misschien business kwijt. Die spelen op vendor lock-in.’

‘Maar met Sysml kun je die modellen toch met elkaar integreren en een overkoepelend model maken van je systeem. De OMG, de standaardisatiegroep achter Sysml, heeft geprobeerd om die modelleertechnieken zo in te richten dat het geheel alles afdekt en tegelijkertijd methodologisch goed in elkaar steekt. Dat is behoorlijk goed gelukt, maar dat maakt die modelleertalen wel vreselijk groot.’

Wat Van Roosmalen betreft, zouden ook softwareontwikkelaars modelleren wel wat serieuzer mogen nemen. Tijdens zijn cursussen leunt hij zelf sterk op UML – gedeeltelijk omdat een training te kort is om uitgebreid te gaan programmeren, hoewel er wel programma’s worden meegegeven als proof of concept. Maar ook omdat het goede aanknopingspunten biedt om over de klassestructuur te redeneren en over de architectuur na te denken.

Ook voor UML geldt dat de meeste softwareontwikkelaars het weleens een keer hebben gezien, maar de drempel om er echt mee aan de slag te gaan, is vrij hoog. ‘Het maken van een goed model vergt ook wel echt een investering voordat het zich gaat terugbetalen’, beaamt Van Roosmalen. Daarnaast ontbreekt het softwareontwikkelaars ook wel een beetje aan de discipline die systeemontwikkelaars wel hebben, merkt hij.

Maar dat is opnieuw een symptoom van het feit dat kwaliteit in software slecht te zien is en zich pas op termijn laat gelden, terwijl dat bij systeemengineering natuurlijk anders ligt. Voor programmeurs is het dus toch zaak om kwaliteit op de kaart te zetten. En in tegenstelling tot wat soms wordt gedacht, kan Agile daar juist mee helpen, stelt Van Roosmalen: ‘In het Agile Manifesto staat gewoon dat je aandacht moet hebben voor softwarekwaliteit. Daar staan hele zinnige dingen over in, maar je moet wel aan die leer vasthouden.’