Componententechnologie reduceert complexiteit

In de loop der jaren zijn wij systemen gaan maken die meer functionaliteit bieden en er is niets dat erop wijst dat deze trend de komende jaren zal worden doorbroken. De complexiteit van de systemen is sterk gestegen, enerzijds door de toename in functionaliteit en anderzijds door de koppeling van deze systemen onderling (binnen een organisatie of tussen organisaties). Hoe we die complexiteit moeten uitdrukken is een boeiend vraagstuk, waar nog geen algemeen bevredigend antwoord op is gegeven. Dat gaan we hier ook niet proberen, want ook al zouden we zo’n maat hebben, dan is daarmee het probleem van de beheersing van de groeiende complexiteit niet opgelost. Het is gebruikelijk dat wetenschappers en praktijkprofessionals zich van tijd tot tijd zorgen maken over deze ontwikkelingen. Klassieke goeroes in dit verband zijn onder meer Edsger Dijkstra en David Parnas. Het doet echter geen recht aan de vele andere auteurs die met goede voorbeelden en suggesties de complexiteitsproblematiek onder de aandacht brengen, te zeggen dat hun bijdragen ‘oude wijn in nieuwe zakken’ zijn. Er verandert namelijk veel in de informatica, zowel in theorie als in praktijk en het probleem van de onbeheersbaar lijkende complexiteit openbaart zich steeds in nieuwe gedaanten. Ook zijn er nieuwe methoden die beloven de complexiteit beter te beteugelen, maar die toch weer blijken te falen. We moeten bedenken dat ook dit een natuurlijk verschijnsel is: we zullen altijd proberen de grenzen van ons kunnen op te zoeken en die te verleggen en dan zal steeds blijken, dat oude methoden niet meer voldoen in de nieuwe situatie. Dat zijn eigenlijk gezonde verschijnselen en we zouden er blij mee moeten zijn, ware het niet dat velen van ons het gevoel hebben dat we het veel beter zouden kunnen doen met betere methoden, technieken en tools. Eén van de oplossingen voor de beheersing van de complexiteit is het componentgebaseerd ontwikkelen van systemen. Twee werelden Vaak wordt de vergelijking gemaakt met de elektrotechniek, waar men er al jaren in slaagt de miniaturisering door te zetten met een evenredige vergroting van capaciteit en processingsnelheid. Inderdaad is de elektrotechniek een goed voorbeeld voor de informatica, met name de hoge graad van componentisering met plug en play-faciliteiten. Door het ontwikkelen van parametriseerbare componenten kunnen we systemen sneller en goedkoper ontwikkelen. Omdat componenten meerdere malen gebruikt zullen worden, kunnen we ons permitteren ze beter te ontwerpen en beter te verifiëren. Het ontwikkelen van systemen uit generieke componenten staat in de informatica nog in de kinderschoenen. Enerzijds zien we kleinschalige componenten in de vorm van herbruikbare classes uit objectgeoriënteerde talen die via method calls aangeroepen kunnen worden; anderzijds zien we grootschalige componenten in de vorm van softwarepakketten die door application program interfaces (api’s) geactiveerd kunnen worden. Deze twee typen verschillen enorm, zowel van omvang als in interfacing en het lijken wel twee gescheiden werelden te zijn. De eerste soort tref je vooral aan als bibliotheken voor programma-ontwikkeling, vaak in het publieke domein meegeleverd met een ontwikkelomgeving. De belangrijkste voorbeelden zijn de J2EE- en.Net-omgevingen. Het tweede type, de softwarepakketten, zie je voornamelijk in de wereld van informatiesystemen. Bekende voorbeelden zijn de ERP-achtige pakketten, die vaak nog monolithisch zijn en als ze componentgebaseerd zijn werken ze vaak alleen goed samen met componenten van dezelfde producent. Het wachten is op de tijd, dat deze leveranciers hun systemen in kleine componenten met een heldere functionaliteit opsplitsen en deze los gaan verkopen. Dan kunnen we best of breed-oplossingen gaan ontwikkelen. We stevenen langzaam af op een situatie waarin een levendige handel in componenten ontstaat, waarbij componentleveranciers en system integrators de marktpartijen vormen. Overigens is de componententechnologie in de wereld van informatiesystemen veel verder ontwikkeld dan in die van de embedded systemen, hetgeen vreemd is omdat embedded systemen dichter bij de elektrotechniek zitten, waar de componententechnologie, zoals gezegd, wel goed ontwikkeld is. Het ontwikkelen van systemen krijgt een andere vorm: het klassieke programmeren wordt vervangen door het zoeken naar geschikte componenten, het configureren en integreren van deze componenten. Door de opkomst van de componententechnologie zijn er nieuwe typen componenten ontstaan zoals de coördinatiesoftware, die de samenwerking tussen componenten regelt door zowel de conversie van uit te wisselen gegevens als door de volgorde van taken te bewaken. Hier zien we dat de workflow engines en middleware als het ware samensmelten. Het wordt een nieuwe uitdaging om functionaliteit met een generiek karakter te isoleren en tot een herbruikbare component uit te bouwen. We moeten ons wel realiseren dat het maken van een dergelijke herbruikbare component soms meer kost dan het inbouwen van de eerder genoemde functionaliteit in een grotere applicatie. Hoewel de componententechnologie vele voordelen biedt, is het geen panacee. Er zijn vier grote problemen. In de eerste plaats: Hoe delen we een systeem goed op in componenten en hoe beheersen we zo’n systeem gedurende zijn levensloop? Ten tweede: Hoe bepalen we of een gegeven component doet wat we willen? Ten derde: Hoe passen we componenten aan die bijna maar niet helemaal doen wat we willen? En ten vierde: Hoe regelen we de coördinatie tussen componenten? Vooral dit laatste is veel moeilijker dan men denkt en vereist goede modellering en verificatie van de interactieprocessen. Problemen De eerste vraag - Hoe delen we een systeem in componenten op? - is de basis van wat vandaag softwarearchitectuur wordt genoemd. Er wordt veel over geschreven, er zijn best practices, maar echt steekhoudende theorie is er nog niet. Voor de tweede vraag - Hoe bepaal je of een component doet wat je wilt? - hebben we eigenlijk geen geschikte methoden en technieken beschikbaar. Er zijn al sinds de jaren tachtig goede specificatietechnieken, zoals Z en VDM, waarin heel nauwkeurig vastgelegd kan worden wat een systeem of component moet doen, maar deze technieken zijn te moeilijk voor de modale ontwerper en te tijdrovend in de toepassing. Daar komt nog bij dat we een bestaande component zoeken die vermoedelijk al een goede specificatie heeft. Het vinden is dus de kunst. Toch heeft elke zoekmethode iets van de gewenste functionaliteit nodig. Een aantrekkelijke manier is, het gebruik maken van een reeds bekende specificatie en alleen de afwijkingen ten opzichte van deze referentiespecificatie aangeven. De ontwikkelingen op het gebied van patronen zijn voor dit vraagstuk belangrijk: immers we moeten snel het ‘patroon’ van de gewenste component kunnen vinden. Voor het derde probleem - Hoe passen we componenten aan? - zijn er in de wereld van de kleinschalige componenten diverse technieken, zoals het gebruik van inheritance en object wrapping. Voor grootschalige componenten zijn er eigenlijk geen technieken beschikbaar. Hier speelt een extra probleem, namelijk dat twee componenten die samen moeten werken een overlappende, maar elkaar niet overdekkende functionaliteit kunnen hebben. Een voorbeeld vinden we in twee componenten van verschillende pakketten, een CRM-component en een productieplanningcomponent van een ERP-systeem. Beide hebben een database met klantgegevens, maar er worden verschillende attributen bijgehouden. De vierde vraag - Hoe regelen we de coördinatie tussen de componenten? - is waarschijnlijk het moeilijkst. Dit is al het geval met enkele grootschalige componenten met ingewikkelde interactieprotocollen. Het idee dat de mens dit soort gedrag goed kan overzien is een illusie, er zijn software tools voor nodig om de coördinatie te verifiëren. Allereerst is het nodig om deze interactiepatronen nauwkeurig te specificeren. Er zijn procestalen als Petrinetten of procesalgebra’s voor nodig om dit te doen. Het aantal informatici in de praktijk dat met deze methoden om kan gaan, is gering. Wel zien we dat er steeds meer procestalen in de praktijk ontwikkeld worden, maar helaas zijn die niet altijd even goed. Typische voorbeelden zijn de activity diagrams uit de UML-familie met een dubieuze semantiek en de nieuwe industriestandaard-in-wording BPEL (business process execution language). Als ontwerpers een inconsistent raamwerk gebruiken om hun systemen in te ontwerpen, kun je niet verwachten dat ze er goede systemen mee maken. Self-made Dit fenomeen is in de informatica erger dan in andere disciplines, zoals de elektrotechniek. Een van de grote oorzaken is, dat er zoveel self-made-informatici actief zijn. Dit is in ons land erger dan in andere westerse landen omdat we relatief laat met informatica-opleidingen zijn begonnen en dat het aantal goed opgeleide informatici dat jaarlijks op de markt komt, aanzienlijk kleiner is dan het aantal starters in dit vakgebied. Veel praktijk-informatici hebben een ander vak gestudeerd en zijn een baan gaan zoeken in de informatica bij gebrek aan werkgelegenheid in hun eigen vak, of ze zijn gelokt door de hoge salarissen. Hoewel dit vaak heel intelligente mensen zijn, die een bepaalde techniek prima onder de knie hebben, missen zij het diepere inzicht in de informatica en zijn vaak niet in staat te beoordelen welke aanpak het beste is en op welke ontwikkeling zij moeten inzetten. Een mooie anekdote is die van een softwarehuis dat een softwarepakket op de markt bracht en zich had laten verleiden tot de levering van een functie die in staat zou zijn vast te stellen of een willekeurige, door de gebruikers zelf te programmeren module op consistente wijze met het pakket zou kunnen samenwerken. Dit betekent dat de functie onder meer moet vaststellen of de aangeboden module wel netjes zal stoppen, gegeven de toestand van de database van het systeem. Dit probleem staat bekend als het haltingprobleem en er is reeds voor de tweede wereldoorlog bewezen dat het onoplosbaar is. Het is dan ook geen wonder dat de betreffende functie nooit gerealiseerd is en dat de gebruikersgroep zeer ontevreden bleef. Gebrek aan beschikbare kennis was de oorzaak van dit onnodige conflict. Het zou een mooi doel zijn van de kenniseconomie om niet alleen meer jonge informatici op te leiden, maar ook te investeren in de opleiding van de self-made-informatici en in software tools, waarmee zij hun producten kunnen verifiëren. Offshore Een relatief nieuw fenomeen is de outsourcing van ontwikkeling en beheer van softwaresystemen naar lagelonenlanden. Deze zogeheten offshore-industrie bloeit geweldig in India en Oost-Europa, en China is hard op weg de andere in te lopen. Behalve dat de lonen in die landen aanzienlijk lager zijn, is het aanbod van mensen met een goede bèta-opleiding groot, zodat verwacht mag worden dat ook de kwaliteit niet minder maar eerder beter zal zijn. Deze ontwikkeling is enerzijds een bedreiging voor onze werkgelegenheid, maar biedt anderzijds nieuwe uitdagingen, ook in het licht van de componententechnologie. Wij zullen immers moeten aangeven wat gemaakt moet worden en, gezien de fysieke en culturele afstand met de ontwikkelaars in het Oosten, zullen wij veel beter moeten specificeren dan wanneer wij software in eigen kring ontwikkelen. Om dit te doen zullen we een softwaresysteem in goed gedefinieerde componenten moeten opsplitsen en moeten beschikken over effectieve en efficiënte methoden en tools om enerzijds onze specificaties te toetsen op fouten en anderzijds te verifiëren of de geleverde componenten wel aan de specificaties voldoen. Hoewel er vele nuttige methoden voor specificatie en verificatie ontwikkeld zijn, zijn ze zelden toegepast op grote systemen. Dus hier zal nog heel wat ontwikkeling nodig zijn. Tevens zal dit leiden tot nieuwe softwaretools om deze taken te ondersteunen of over te nemen van de mens. De componententechnologie maakt het heel goed mogelijk softwaresystemen geleidelijk te transformeren door het component voor component te vervangen. Daarnaast kunnen we componenten in een systeem vervangen door een component die door derden beheerd wordt en die als een (web)service te gebruiken is. Ook het beheersen van zulke componentgebaseerde systemen zal aanleiding zijn voor nieuwe methoden en tools. Door de lage ontwikkelingskosten in het Oosten zullen wij meer softwaresystemen in ontwikkeling nemen, omdat de baten gemakkelijker tegen de kosten zullen opwegen. Zo zal er in het Westen toch veel werk voor informatici blijven, maar vermoedelijk wel op een hoger niveau. Kortom, componententechnologie kan zeker bijdragen aan het beheersen van de complexiteit van systemen, maar er is meer kennis nodig om betrouwbare systemen te krijgen. Vermoedelijk geeft de opkomst van de offshore-industrie ons een goede stimulans. AUTEUR: Kees van Hee Kees van Hee is hoogleraar informatica aan de TU/e en directeur van LaQuSo, het laboratorium voor verificatie en validatie van softwaresystemen. Voorheen is hij 16 jaar actief geweest als management- en ICT-consultant bij onder meer Deloitte.