In vrijwel alle takken van ontwerp, of het nu om consumentenelektronica gaat of om vliegtuigen, maken ontwerpers gebruik van standaard onderdelen. Deze zijn uitvoerig getest en hebben in de praktijk bewezen dat ze geen verborgen gebreken vertonen. Bij het ontwerpen van software is dat nog niet het geval. Ontwerpen op basis van componenten staat nog in de kinderschoenen. Standaarden zijn er inmiddels in overvloed, maar de blokjes passen niet goed op elkaar. Het zal nog zeker tot het jaar 2000 duren voor het Lego-principe volledig bij het ontwerpen van software is doorgedrongen.
Zou u met een gerust hart in een vliegtuig stappen dat is gebouwd met onderdelen die net uit het laboratorium komen? Of gaat u liever aan boord van een ouderwets vliegtuig dat is geconstrueerd met onderdelen die de afgelopen tien jaar hun betrouwbaarheid hebben bewezen? Ontwerpers uit alle industrieën maken het liefst gebruik van onderdelen die in de praktijk betrouwbaar blijken. Hergebruik is een grondbeginsel van ontwerpen. Diverse analisten verwachten dat tegen het eind van deze eeuw de meeste applicatiesoftware is opgebouwd uit herbruikbare componenten. Bibliotheken met deze componenten gaan daarom een steeds belangrijker rol spelen.
Het is niet te laat om herbruikbare software te ontwikkelen, maar het is allesbehalve te vroeg. Jan Baan is een van de grote voorvechters van een industriële aanpak van het ontwerpen van software. Al jaren pleit hij voor de softwarefabriek.
De barrières voor hergebruik van software lijken vooral cultureel bepaald, technische hinderpalen zijn er niet. De meeste automatiseringsafdelingen beschouwen elk project nog steeds als iets geheel nieuws. Het komt nog weinig voor dat een programmeur een applicatie kan bouwen op basis van macro’s, subroutines en componenten die hij vergaart via het doorzoeken van bibliotheken.
Toegankelijke bibliotheek
Meestal beschouwen de ontwikkelafdelingen elk project als uniek, terwijl elk project toch vaak voor een deel bestaat uit dezelfde componenten. In de praktijk hebben veel ontwikkelaars er een hekel om een component te ontwikkelen en die in een voor iedereen toegankelijke bibliotheek op te bergen. Op die manier doen zij het werk, terwijl anderen ervan kunnen profiteren, zo vinden zij. Dat probleem speelt bijvoorbeeld bij de automatiseringsafdeling van het GAK, die op kleine schaal werkt met herbruikbare software. Zolang deze vicieuze cirkel niet wordt doorbroken zal het ontwerpen van herbruikbare software niet op grote schaal doorbreken.
Uiteraard is het zo dat er hoge initiële investeringen nodig zijn en opleidingen en trainingen van ontwikkelaars. Hoewel de kosten voor het bouwen van herbruikbare componenten hoog zijn, zullen de kosten drastisch afnemen als de componenten is opeenvolgende projecten worden gebruikt. Analisten hebben berekend dat over een periode van drie jaar de kosten van herbruikbare software een tiende zullen bedragen van de initiële kosten.
Behoorlijke discrepantie
Tussen de leveranciers van software voor herbruikbare componenten en de praktijkmensen bestaat een behoorlijke discrepantie. Zo schetst Paul Bassett, hoofd onderzoek en tevens oprichter van softwareleverancier Netron, een optimistisch beeld van hergebruik van software.
Bassett stelt dat 30 tot 50 procent van de software tegenwoordig opnieuw wordt gebruikt. Menig chief information officer (cio) komt bij navraag tot ramingen die ten minste 10 procent lager liggen. Het is waarschijnlijk geen toeval dat sommige cio’s stellen dat 60 procent van de softwareprojecten mislukt. Charles Kreitzberg, president van adviesbureau Cognetics, stelt zelfs dat een kwart van de projecten nooit afkomt. Als projecten al afkomen, dan zijn ze te laat klaar of ze zitten ver boven begroting.
Toch denken niet alleen de leveranciers van deze software, maar ook verscheidene analisten dat hergebruik van software op den duur zal doorbreken. De vraag is alleen hoe lang dat nog zal duren. Mike Bleechar, directeur onderzoek van de applicatie-ontwikkelafdeling van Gartner Group, voorspelt dat de componentenmarkt in het jaar 2001 maar liefst zeven miljard dollar zal bedragen. Hiervan gaat het grootste deel (vijf miljard) op aan services en de rest aan softwarecomponenten.
Repository als basis
Het maken van verzamelingen van herbruikbare softwarecomponenten, ongeacht welk type, heeft weinig zin als de ontwikkelomgeving niet is gebaseerd op een repository (centrale opslag). Als je niet weet wat je hebt, hoe kun je het dan opnieuw gebruiken? Repositories beschikken over slimme methoden voor het opslaan, browsen en onderzoeken van componenten. Dit is belangrijk, want de grote belemmering om componenten weer te gebruiken ligt vooral op het organisatorische vlak. Elke methode om componenten of specificaties van componenten handiger te kunnen vinden, draagt immers bij tot het gemak van hergebruik.
De definitie van softwarecomponenten is niet langer beperkt tot desktop-GUI, gebaseerd op een enkel object-model. Componenten kunnen nu betrekking hebben op een grote verscheidenheid van functionaliteit, zoals protocollen voor de communicatie tussen applicaties, beveiliging en authentificatie en de toegang tot systemen. De industrie gaat nu ook steeds meer de kant op van ingewikkelder componenten voor zakelijke processen en complete toepassingen.
Daarom moet er een overzicht zijn van alle componenten in de vorm van zijn interfaces en een omschrijving van de functionaliteit, ongeacht het onderliggende object model. Dit overzicht moet op een overzichtelijke manier toegankelijk zijn voor alle ontwikkelaars binnen een organisatie. Het zijn repositories die hiervoor geschikt zijn. Bovendien zijn repositories tot veel meer in staat dan het eenvoudig opslaan van componenten in de vorm van een catalogus. De huidige componenten repositories combineren de beste aspecten van componenten catalogi (browsing en visualisatie) met de high-end ontwikkelfunctionaliteit van traditionele repositories van mainframe-omgevingen. Dat wil zeggen dat ze ook de architectuur in zich herbergen voor het besturen van het hergebruik van componenten. Want de mainframe-omgeving heeft immers ervaring met zaken als: versiebeheer, beveiliging en statistische analyses. De zaak wordt nog ingewikkelder doordat het bij het ontwerpen op basis van componenten gebruikelijk is dat dit moet gebeuren op basis van verschillende typen softwaremodules uit meerdere bronnen.
Het Lego-principe
Bij de discussie over componenten doemt de vergelijking met de blokjes van het Lego-speelgoed steeds weer op. Bij Lego passen de blokjes altijd op elkaar. De kleine op de kleine en de grote op de grote. Bovendien passen vier kleine blokken weer precies op een grote. Het ontwikkelen van software is nog lang niet zo ver. Toch zal het die kant op moeten, omdat anders het werken met componenten beperkt blijft tot een afdeling of een horizontale of verticale applicatie.
De belangrijkste eigenschap van componenten is waarschijnlijk dat ze altijd op elkaar passen, zodat een ontwikkelaar systemen kan bouwen met behulp van goed gespecificeerde interfaces. Een component kan alleen worden opgeroepen via de juiste interface. Geïsoleerde componenten worden afgeschermd van alle andere componenten, services en applicaties.
Het afschermen van componenten vermindert het risico dat een verandering in een bepaalde component doordringt in een andere component en zo de werking van een applicatie beïnvloedt. Dit stelt ontwikkelaars tevens in staat problemen te vereenvoudigen in makkelijk te gebruiken componenten.
Het gebruik van ‘gewone’ componenten en herbruikbare en de combinatie van beide heeft tot gevolg dat er een mechanisme moet zijn dat dit garandeert. Bovendien moet er controle zijn op de functionaliteit van componenten en op de interfaces. Repositories zijn bij uitstek geschikt voor deze taak.
Diverse categorieën
Diverse indelingen van componenten zijn mogelijk. Ze kunnen bijvoorbeeld worden ingedeeld per functie die ze binnen een applicatie vervullen. Sommige componenten ondersteunen de technische infrastructuur van een bepaald systeem. Voorbeelden van deze soort componenten zijn ‘gebruikersinterface controls’ of componenten die zorgen voor de communicatie tussen applicaties.
Andere componenten zijn meer afgestemd op het functioneren van zakelijke processen. Ook kan men componenten indelen op basis van hun omvang. Fijnmazige componenten zijn relatief klein en zijn te gebruiken in een grote verscheidenheid van applicaties. Deze kleine componenten liggen dichter bij de code en individueel werken ze binnen een kleiner gebied. Omdat ze zo fijnmazig zijn en op een laag abstractieniveau opereren, hebben ‘class libraries’ en ingebouwde componenten niet veel invloed op het verhogen van de productiviteit van de ontwikkelaar, voor wat betreft grote applicaties. Aan de andere kant zijn ze, dankzij hun beperkte functionaliteit, wel makkelijk opnieuw te gebruiken in diverse applicaties.
Standaard en bedrijfseigen
Meestal onderscheidt men twee soorten ‘class libraries’; standaard bibliotheken en bedrijfseigen bibliotheken. Bij standaard libraries gaat het bijvoorbeeld om C++-libraries. Leveranciers van 4GL leveren vaak bedrijfseigen libraries met vooraf gedefinieerde componenten bij hun softwarehulpmiddelen.
Deze componenten zijn meestal gebaseerd op de wensen van ontwikkelaars die met deze talen werken. Veel van de 4GL-leveranciers hebben een repository voor het werken met hun componenten. Het nadeel is dat deze repositories beperkt zijn tot het gebruik van een specifiek hulpmiddel.
In tegenstelling tot C++ is er geen internationale standaard voor ingebouwde software-componenten. Dat is het slechte nieuws. Het goede nieuws is dat er op dit gebied maar drie de facto standaarden zijn. De eerste is Active X controls, gebaseerd op het DCOM (Distributed Component Object Model) van Microsoft. Het gebruik hiervan is zo alom verspreid dat DCOM voor velen synoniem is met de term ‘componenten’.
De tweede standaard voor softwarecomponenten is IBM’s Open Doc, gebaseerd op SOM (System Object Model) en de gedistribueerde versie DSOM dat op zijn beurt is gebaseerd op de CORBA (Common Object Request Broker Architecture) van de Object Management Group. De derde de facto standaard voor ingebouwde softwareobjecten zijn de Java-applets.
Grote componenten
Ingebouwde componenten en ‘classes’ zijn een manier om systemen te bouwen met voorgefabriceerde software ‘onderdelen’, maar deze manier gaat niet ver genoeg. Het ontwikkelen van systemen op basis van componenten wordt pas volledig benut als men er niet alleen eenvoudige applicaties mee kan bouwen, maar ook ingewikkelde, grote systemen. Dat kan alleen op basis van krachtiger op servers gebaseerde componenten die geschikt zijn voor diverse platformen.
Om complete applicaties te bouwen is het nodig dat componenten en classes op de een of andere manier met elkaar worden verbonden. Meestal gebeurt dat met code van de derde generatie. Zogenoemde framework-omgevingen hebben als doel de hoeveelheid integratiecode te verminderen. Frameworks zijn een soort componenten die zijn ontworpen als maatwerksoftware.
Ontwikkelaars bouwen systemen met frameworks op basis van subroutines die worden opgeroepen door het framework. In vergelijking met class libraries en ingebouwde componenten geven frameworks een aanzienlijke verhoging van de productiviteit van ontwikkelaars. Dat is vooral te danken aan het feit dat een framework de diverse componenten al met elkaar verbindt, zodat de ontwikkelaar dat niet meer hoeft te doen.
Weer een niveau hoger op de schaal van componenten ligt de applicatie. Ze verhogen de productiviteit enorm, maar door hun omvang, specifieke functionaliteit zijn ze minder flexibel waardoor de mate van hergebruik laag is.
Wim Amerongen,
freelance medewerker Computable
Bankenfusie
De Britse Chemical Bank werkt al sinds 1988 volgens het principe van het hergebruik van code. Het grote voordeel kwam er echter pas uit in 1996 toen de bank werd overgenomen door de Chase Manhattan Bank. "We moesten onze grootboeken aan elkaar koppelen en die verbinden met CIIS (Chemical’s Corporate Information Interchange System)", stelt Laszlo Szabo, die in zijn functie van vice-president verantwoordelijk is voor de financiële verslaglegging.
Voor de overname had Chase enkele legacy interface-componenten gebouwd. De bank had hierin flink geïnvesteerde en wilde de componenten opnieuw gebruiken voor het maken van verbindingen met de Chemical Bank. Hergebruik werd hier uit nood geboren, geeft Szabo toe. "We hadden het liefst een nieuw systeem gebouwd dat helemaal op de eisen en wensen van de nieuwe combinatie was afgestemd. Maar daar hadden we te weinig geld voor. Bovendien was hergebruik van componenten de enige manier waarop we de deadline konden halen."
Hij gebruikte Netron Frames, een tool voor hergebruik, om de twee grootboeken aan elkaar te koppelen. Dankzij deze ervaring ligt het hergebruik van code nu op ruim 90 procent bij toepassingen als online verslaggeving.
Seminar: Software in losse componenten
Binnenkort is een softwarepakket ook in afzonderlijke stukjes te koop: componenten of building blocks. Een blokje facturering een blokje klantenbeheer, .. componenten van verschillende origine samen vormen dan software die bijna op maat geschreven is. Een manier van werken die een belangrijke invloed zal hebben op de organisatie van de IT-afdeling en op die van de softwareleveranciers. Analyse, prototyping en training, zullen zeker wijzigingen ondergaan onder invloed van de opkomst van de componenten.
Expert in deze materie, prof.dr.ir. Jacques Van den Bulcke van de Universiteit te Leuven, geeft een overzicht van de technologische wijzigingen. Wat zijn componenten, hoe worden ze aan elkaar gelijmd en waarom lukt dat niet altijd, zijn maar enkele van de aspecten die hij zal aanhalen. Ook de invloed op case tools vormt een belangrijk onderdeel in zijn betoog. En wie weet worden binnenkort ook de case tools als componenten verkocht. Datum: woensdag 22 oktober, 14.00-15.00.
