“Als het werkt, denken managers dat het zo goed als klaar is.”

Softwareontwikkeling richt zich vaak volledig op het invullen van functionaliteit; er is geen tijd voor zaken als onderhoudbaarheid, architectuur en performance. Terwijl het niet moeilijk hoeft te zijn, zegt softwaretrainer Onno van Roosmalen, maar er zijn misverstanden over Agile, architectuur, UML, objectgeoriënteerd programmeren en testgestuurd ontwikkelen.

Modelleren? Dat doen we niet. Ontwerppatronen? Die slaan we over. Omdat we agile werken. Onno van Roosmalen hoort het regelmatig: Agile als excuus of zelfs voorwendsel om softwarearchitectuur niet serieus te nemen. Als trainer op het gebied van softwareontwikkeling ziet hij dat er veel misverstanden zijn rond de onderwerpen die met niet-functionele eisen te maken hebben: architectuur, interfaces, performance, modellering, onderhoudbaarheid, noem maar op.

Misverstanden die eenvoudig te verklaren zijn omdat ze te maken hebben met het ongrijpbare begrip ‘softwarekwaliteit’. “Kwaliteit is voor veel mensen niet zichtbaar,” zegt Van Roosmalen. “Als het werkt, dan werkt het en managers, klanten en gebruikers denken dat het zo goed als klaar is. Het wordt heel moeilijk om te beargumenteren waarom je iets extra’s moet doen. Ontwikkelaars krijgen daar in de praktijk wel duidelijk rendement van.”

Veel van deze misverstanden over softwarekwaliteit leven ook onder de ontwikkelaars zelf. Populaire softwaretechnieken, zoals testgestuurde ontwikkeling, dragen hier volgens hem niet aan bij: “Test-driven development richt zich volledig op functionaliteit. Aspecten die typisch gekoppeld zijn aan architectuur, zoals prestaties, herbruikbaarheid, uitbreidbaarheid en software-evolutie, zijn erg moeilijk te testen. Net als race conditions en deadlocks.”

“Er is ook het idee dat architectuur iets abstracts is dat van tevoren bedacht moet worden, waardoor de richting van het project in een keurslijf wordt gedwongen – een big bang architectuur die in één keer goed moet zijn. Maar dat kan niet; vaak weet je niet wat er komen gaat,” legt Van Roosmalen uit. “Natuurlijk is het goed om een idee te hebben van hoe je het wilt inrichten. Maar soms zie je dat projecten zich al voorbereiden op bepaalde toevoegingen. Dan denk ik vaak: ja, en komen die er dan echt?”

Bovendien verstoft de onderliggende theorie na verloop van tijd. Dat merkt hij bijvoorbeeld goed in zijn basistraining over Emergent Object-Oriented Design in the Age of AI (OOAD). Hij komt deelnemers tegen met bijvoorbeeld een elektrotechnische achtergrond, maar ook mensen met een IT-diploma. “Toch zie je dat veel van hen problemen procedureel ontleden in plaats van objectgeoriënteerd”, zegt Van Roosmalen. “Dat sluipt erin als mensen onder druk software maken, terwijl je eigenlijk opvallend betere software kunt maken als je de richtlijnen goed toepast.”

Zo werkt het niet in C#’.

Zelf heeft Van Roosmalen een heel andere achtergrond: hij studeerde natuurkunde in Nijmegen en promoveerde aan het Kernfysische Versneller Instituut in Groningen. Daarna maakte hij de sprong naar Amerika voor een postdocpositie aan het California Institute of Technology.

Het keerpunt kwam in 1987. Van Roosmalen en zijn vrouw wilden eigenlijk terug naar Nederland, maar banen in de natuurkunde lagen niet voor het oprapen. Toen er een functie in de technische informatica vrijkwam aan de Technische Universiteit Eindhoven, besloot Van Roosmalen deze kans te grijpen; zijn werk op het gebied van de computationele natuurkunde had zijn interesse voor software en computers gewekt.

Bovendien merkte Van Roosmalen dat hij graag les gaf. Voor zijn terugkeer naar Nederland gaf hij al drie jaar les op Yale en toen begin jaren negentig objectgeoriënteerde technieken opkwamen, begon hij met trainingen voor bedrijven. Na de millenniumwisseling besloot hij zijn dienstverband bij de TUE af te bouwen om zich uiteindelijk volledig te kunnen richten op het geven van trainingen. Hij werkt nog steeds voor de Universiteit Eindhoven, die hem inhuurt voor de PDEng-opleiding Software Technology.

Daarom geeft Van Roosmalen ook trainingen aan ontwikkelaars die al een paar jaar bij een bedrijf in dienst zijn. Een groot verschil met starters, merkt hij: hoe langer ontwikkelaars achter het toetsenbord zitten, hoe ontvankelijker ze over het algemeen worden voor geavanceerde software engineering concepten. “Je begint op een andere manier naar dingen te kijken en ik denk dat je dingen meer in context kunt zien. Het blijft iets beter hangen.”

“In de meeste objectgeoriënteerde programmeertalen hebben objecten van dezelfde klasse bijvoorbeeld direct toegang tot elkaars privéattributen. Mensen weten dat vaak helemaal niet. Dan proberen ze het en blijkt het waar te zijn. Ze zeggen dan vaak zoiets als: ‘Maar zo is het niet in C#.’ En dan blijkt het daar weer precies hetzelfde te zijn,” geeft Van Roosmalen als voorbeeld. “Het lijkt elementair, maar er zitten belangrijke ideeën achter, en daar praten de meeste ontwikkelaars graag nog eens over. De meeste trainingen gaan over het proces en zo, en niet over de technische dingen.”

Verdedigend

“Het is precies deze kennis van objectoriëntatie die de basis vormt voor een groot deel van de architectuur in een typische applicatie. Hierdoor krijg je automatisch te maken met belangrijke software-eigenschappen als information hiding en encapsulation, oftewel het idee dat je informatie lokaliseert en niet door het hele systeem gooit. In de praktijk zie je regelmatig dat een team één component voorziet van extra functionaliteit en dat vervolgens het hele systeem als dominostenen begint om te vallen. Dat maakt het problematisch om iets toe te voegen. In veel webapplicaties zie je dat dat idee een beetje doorgeslagen is,” zegt Van Roosmalen.

En dan, nadenken over het verbergen van informatie gaat hand in hand met de manier waarop componenten met elkaar communiceren: de interface of API. “Hiermee kun je de gedetailleerde vorm van je objecten verbergen en ervoor zorgen dat er geen implementatiedetails uitlekken. Zo zorg je ervoor dat de clientcode alleen kan doen wat er op dat moment gevraagd wordt, niet meer en niet minder,” legt Van Roosmalen uit.

Het idee hierachter is dat de evolutie van componenten op deze manier ontkoppeld kan worden. Als een nieuwe versie van een component blijft doen wat het vroeger deed via een interface, dan hoeft de software die erop gebouwd is niet onmiddellijk aangepast te worden. Een ontwikkelteam dat tegen het component programmeert, kan de nieuwe versie veilig gebruiken zonder bang te zijn dat er tijdens het proces iets zal omvallen. Wanneer inkapseling en interfaces in orde zijn, wordt er bijna automatisch een onderhoudbare, schaalbare architectuur gecreëerd die kan meegroeien met de applicatie.

Dit vereist echter dat teams een defensieve houding aannemen bij het ontwerpen van hun interfaces. “Je moet niet alles aanbieden wat andere teams vragen. Hoe meer je aanbiedt, hoe meer onbedoelde toepassingen er zijn. Dit vergroot de kans dat dingen omvallen bij een nieuwe versie. Je kunt een interface later altijd nog uitbreiden, maar downsizen is een stuk lastiger,” zegt Van Roosmalen.

“Ik heb daar een hele leuke workshop voor, die ik met de TUE-stagiairs doe. Verschillende teams krijgen de opdracht om een component met een interface te ontwikkelen. Daarna moeten ze daar een functionele uitbreiding op maken – onverwacht natuurlijk; dat hou ik geheim. Vervolgens moeten ze proberen testgevallen te maken voor elkaars componenten die werken tegen de eerste variant, maar niet meer tegen de tweede. Dit zijn echte eye-openers, want vaak zijn zulke tests in een mum van tijd gemaakt.

Trukendoos

Ontwikkelaars hoeven het wiel niet elke keer opnieuw uit te vinden. Voor veel problemen zijn in de loop der jaren best practices opgesteld in de vorm van patronen. “Je kunt bijvoorbeeld je architectuur in lagen indelen: dat is een architectuurpatroon. Om die lagen te structureren, gebruik je verschillende design-patronen.”

Van Roosmalen geeft een training die volledig aan dit onderwerp is gewijd: Design Patterns en Emergent Architecture. Dat is natuurlijk heel breed, maar het idee erachter is vooral om te laten zien dat je die trukendoos hebt. “Eigenlijk is dat een van mijn favoriete trainingen, omdat je het echt hebt over het ontwerpen van software en omdat je er allerlei praktische problemen mee kunt aanpakken. Er komen ook heel andere technische aspecten bij kijken, zoals toestandsmachines met mogelijke deadlocks.”

Van Roosmalen geeft samen met een oud-collega van de TUE ook een vervolgcursus over een ander architectuurthema: real-time gedrag. Typisch heb je het dan over problemen met systemen die meerdere gelijktijdige taken moeten uitvoeren onderhevig aan timing-eisen. Tegenwoordig kun je met de meeste moderne programmeertalen concurrency programmeren, en dat geeft aanleiding tot heel bijzondere problemen zoals race conditions en deadlocks.

Ook hier gaat het in de basis al mis, merkt Van Roosmalen op: “Veel mensen die realtime problemen hebben, gebruiken een besturingssysteem als Microsoft Windows. Nou, dat is geen real-time besturingssysteem. Het bevat wel veel dingen zoals realtime prioriteiten enzovoort. Maar er ontbreken veel andere dingen die ook nodig zijn voor real-time gedrag. Dan moet je een beetje op je hoofd gaan staan om het goed te krijgen.”

“In realtime systemen heb je bijvoorbeeld het probleem van prioriteitsomkering, waarbij een taak met lage prioriteit een bron claimt zodat taken met hogere prioriteit er geen gebruik van kunnen maken. Er zijn mechanismen om dit tot een minimum te beperken en die moeten in het besturingssysteem zitten.”

Verkoper-lock-in

Van Roosmalen geeft ook een basistraining rond SysML, een variant van UML voor systems engineering. Systeemengineers modelleren veel, maar toch wordt SysML in de praktijk maar mondjesmaat gebruikt. Daar is een reden voor: “Voor systems engineering worden veel commercieel beschikbare tools gebruikt, zoals Matlab en Simulink. Deze leveren geen gestandaardiseerde modellen. Dat is ook helemaal niet wat tool vendors willen, want dan zouden ze business kunnen verliezen. Ze spelen in op vendor lock-in.”

Maar met SysML kun je deze modellen toch met elkaar integreren en een overkoepelend model van je systeem maken. De OMG, de standaardisatiegroep achter SysML, heeft geprobeerd deze modelleertechnieken zo te combineren dat het geheel alles omvat en tegelijkertijd methodologisch verantwoord is. “Dat is aardig gelukt, maar het maakt de modelleringstalen wel ontzettend groot.”

Wat Van Roosmalen betreft zouden softwareontwikkelaars het modelleren ook wat serieuzer moeten nemen. Tijdens zijn cursussen maakt hij zelf veel gebruik van UML – deels omdat een training te kort is om uitgebreid te gaan programmeren, hoewel er wel programma’s worden aangeleverd als proof of concept. Maar ook omdat het goede aanknopingspunten biedt om te redeneren over de klassenstructuur en na te denken over de architectuur.

“Wat UML betreft: de meeste softwareontwikkelaars hebben het wel eens gezien, maar de drempel om er echt mee aan de slag te gaan is vrij hoog. Het maken van een goed model vergt echt een investering voordat het loont,” beaamt Van Roosmalen. Daarnaast missen softwareontwikkelaars ook een beetje de discipline die systeemontwikkelaars wel hebben, merkt hij op.

Maar dat is weer een symptoom van het feit dat kwaliteit in software moeilijk te zien is en zich pas op de lange termijn laat voelen, terwijl dat bij systems engineering natuurlijk anders is. “Voor programmeurs is het daarom belangrijk om kwaliteit op de kaart te zetten. En in tegenstelling tot wat soms gedacht wordt, kan Agile daarbij helpen,” zegt Van Roosmalen: “In het Agile Manifesto staat gewoon dat je aandacht moet besteden aan softwarekwaliteit. Daar staan hele zinnige dingen in, maar je moet wel in de praktijk brengen wat er gepredikt wordt.”

Dit artikel is geschreven door Pieter Edelman, tech-redacteur van Bits&Chips.