Softwareontwikkelaars zijn sterk afhankelijk van hun hulpmiddelen. Ze gebruiken speciale tekstverwerkers om hun programma’s te schrijven en ‘compilers’ en ‘linkers’ om deze teksten in machinecode om te zetten. Dat is echter nog het minste. Zodra het project omvangrijk en ingewikkeld wordt, zijn specialistische hulpmiddelen nodig om eerst een geschikt ontwerp te kunnen maken. In deze eerste van twee afleveringen zet een systeemarchitect van Philips Semiconductors de tekortkomingen van object-oriëntatie af tegen de zegeningen van softwarecomponenten.
Ontwerpmethodieken kunnen verschillende uitgangspunten hebben. Voor niet al te grote projecten wordt nog vaak de functioneel gestructureerde analyse en ontwerptechniek gebruikt. Deze wijze van werken analyseert de taken die uitgevoerd moeten worden en verdeelt deze in sub-taken. Een verdeling die doorgaat totdat taken ontstaan die elke programmeur gemakkelijk in een routine kan omzetten. De taken worden in routines geïmplementeerd en vervolgens samengevoegd om tot een werkend geheel te komen.
Een zinvolle aanpak als bij analyse van het probleemgebied maar weinig groepen met gelijksoortig gedrag zijn te vinden. Zijn dit soort groepen juist wél in ruime mate aanwezig, dan is het beter om gebruik te maken van een modernere aanpak: de objectgeoriënteerde technologie. De term object slaat hierbij op de leden van klassen waarvan de individuen gelijkwaardig gedrag vertonen.
Object-oriëntatie
Naast klassenwijd gedrag bezitten deze objecten ook individuele en klassenwijde eigenschappen en relaties. De objectgeoriënteerde werkwijze optimaliseert verregaand het hergebruik van een eenmaal geschreven code. Bij deze methodiek let men niet alleen op de functionaliteit, maar ook op de onderwerpen waarop deze functies werken.
Helaas vertonen de meest gebruikte hulpmiddelen voor het ontwerpen en bouwen van objectgeoriënteerde systemen nogal wat gebreken. Zij zijn in het bijzonder slordig in het effectief inkapselen van objecten. C++ kent bijvoorbeeld zogenaamde friend classes en friend functions die zonder meer de inkapseling kunnen doorbreken. Bovendien is het communicatieprotocol tussen objecten niet eenduidig vastgelegd. Zo kan men attributen van objecten rechtstreeks benaderen, of op een wat beter beheersbare wijze via get/set-functies. Daarnaast is er geen eenduidige wijze om instanties van klassen tijdelijk op te slaan of via netwerken te versturen.
De objectgeoriënteerde technologie laat het vooral afweten, wanneer men bij het bouwen zoveel mogelijk gebruik wil maken van reeds aanwezige modules. Om deze tekortkoming te herstellen is de softwarecomponenten-technologie ontworpen. Er bestaat inmiddels een aantal variaties van deze technologie. De meest bekende zijn de op Java gebaseerde Javabeans en de op Microsofts COM (Component Object Model) gebaseerde Active-X-technologie.
Softwarecomponenten
In een gesloten werkomgeving of in een gesloten markt spelen de eerder genoemde nadelen van de objectgeoriënteerde aanpak slechts een minieme rol. De tekortkomingen worden echter cruciaal in situaties waarin voor een open markt geproduceerd moet worden. Softwarecomponenten zijn beter toegerust om een open markt te bedienen. De softwarecomponenten-technologie is kampioen in hergebruik van het werk van onafhankelijke partijen. De objectgeoriënteerde technologie is kampioen in hergebruik van eigen ontwikkelingen en levert daardoor de meest flexibele en snelste aanpassingmogelijkheid.
De softwarecomponenten-technologie is afhankelijk van een passende infrastructuur die de softwarecomponenten beheert en ze met elkaar laat communiceren. Daartegenover is de objectgeoriënteerde technologie afhankelijk van de ondersteuning van de klassenbibliotheken die de onderlinge samenhang van de klassen beheren. Wanneer de objectgeoriënteerde technologie als enige wordt ingezet, dan ontstaan vaak grote monolithische systemen. De architectonische structuur in deze systemen wordt meestal slechts voor een klein deel gereflecteerd in de structuur van de klassenbibliotheken. Dit betekent dat er in grote complexe systemen veel kruisrelaties kunnen bestaan die onderhoud en verdere uitbreiding moeilijk beheersbaar maken. Deze technologie vereist derhalve een groot inzicht en vakkennis van de ontwerpers en de bouwers. Een eis die minder van kracht is bij gebruik van de softwarecomponenten-technologie. De inzet van een geïntegreerde ontwikkelomgeving die de gebruikte klassenbibliotheek maximaal ondersteunt, kan de beheerstaak aanmerkelijk verlichten.
Voor elk van de genoemde technologieën bestaan inmiddels gespecialiseerde hulpmiddelen. Merkwaardig is dat voor elk van de genoemde technologieën aparte ontwerphulpmiddelen en aparte bouwhulpmiddelen bestaan. Het komt maar zelden voor dat deze hulpmiddelen gezamenlijk en in geïntegreerde vorm aangeboden worden. Als dat dan al gebeurt, dan is het doelgebied meestal de ondersteuning van de bedrijfsvoering. Dat wil zeggen dat programmeurs die andere doelgebieden bedienen, normaliter niet over voldoende geïntegreerde hulpmiddelen beschikken. Toch is er wel degelijk behoefte aan dergelijke middelen.
Voor de objectgeoriënteerde technologie bestaan inmiddels al zeer volwassen en doeltreffende gereedschappen. Daarom vooral aandacht voor de gereedschappen ten behoeve van de softwarecomponenten-technologie.
De behoefte
In steeds meer systemen is een aanzienlijke hoeveelheid software aanwezig, die een essentieel onderdeel van de functionaliteit regelt. De markt hiervoor groeit veel harder dan het aantal beschikbare programmeurs. Bovendien neemt naast de omvang ook de complexiteit van de software snel toe. Deze situatie is alleen het hoofd te bieden, wanneer zoveel mogelijk van de geproduceerde software opnieuw is te gebruiken. De kans, dat een kleine brok software herbruikbaar is, is in het algemeen groter dan het opnieuw toepassen van grote software-subsystemen. Het bijeenbrengen van een aantal bij elkaar behorende functies in een zelfstandige module biedt een aantal unieke voordelen.
Door de beperkte omvang kan de module volledig getest worden. Daardoor is het mogelijk om de functionaliteit van de module onvoorwaardelijk te garanderen. Bovendien zal na regelmatig gebruik de module een vertrouwd en gemakkelijk herkenbaar deel van de nieuw te bouwen toepassingen vormen. Ook is het mogelijk om van dergelijke modules verhandelbare producten te maken. Het ligt daarom in de verwachting dat de markt voor softwarecomponenten een grote vlucht zal nemen. Voor het zover is moet echter nog een groot aantal hindernissen genomen worden. Een van de belangrijkste hindernissen: softwarecomponenten kunnen niet functioneren zonder een passende infrastructuur. Deze infrastructuur verzorgt het relatiebeheer, de taakverdeling, de geheugenvoorziening en de onderlinge communicatie. In een goed ontwerp is de infrastructuur precies toegesneden op de behoefte. Voor toepassingen die op de desktop of op Internet draaien is die reeds aanwezig, maar voor andere doelen nog niet.
Om hergebruik zoveel mogelijk te stimuleren moeten software-onderdelen niet langer ontworpen worden voor één enkele toepassing. In plaats daarvan moeten softwarecomponenten ontworpen worden voor zoveel mogelijk hergebruik in een compleet toepassingsgebied. Gereedgekomen componenten moeten geregistreerd worden op een voor geïnteresseerden toegankelijke plaats. De componenten moeten zoveel mogelijk gebruik maken van gelijksoortige interfaces. Een interface bestaat uit een groep bij elkaar horende functies die een samenhangende service bieden. Gebruik van standaard interfaces verhoogt de kans op hergebruik en vergemakkelijkt het toepassen van de component. Ook de specificaties van deze standaard interfaces dienen op een voor geïnteresseerden toegankelijke plaats te vinden zijn.
Open markt
Softwarecomponenten zijn bij uitstek toegerust om een open markt te bedienen. Om hier optimaal gebruik van te kunnen maken is het nodig dat de ontwerp- en bouwgereedschappen hergebruik van componenten en van ontwerpdetails zo goed mogelijk ondersteunen. De algoritmen, die het functioneren van een softwarecomponent beschrijven, bevatten kennis die men graag zou willen afschermen. Typedefinities, interfacespecificaties en de specificatie van de architectuur van softwarecomponenten bevatten kennis die uiteindelijk toch in de gebruikshandboeken terecht komt. Gegevens dus die zonder gevaar van ongewild weglekken van geïnvesteerde kennis op een publiekelijk toegankelijke plaats voor alle geïnteresseerden beschikbaar gesteld kunnen worden.
Het is mogelijk om dergelijke informatie tegelijk leesbaar en automatisch verwerkbaar in een ontwerpscript op te nemen. Dit opent de mogelijkheid om een open markt voor software componenten te stimuleren met behulp van een serie repositories. De repositories worden dan onderhouden door aanbieders van softwarecomponenten of door onafhankelijke instanties. De vorm van zo’n repository kan een web-site zijn waar een aantal ontwerpscripts in opgetuigde html-pagina’s opgenomen zijn.
Geschikte ontwerp- en bouwgereedschappen kunnen deze informatie gebruiken door de geadverteerde herbruikbare typedefinities, interfacespecificaties en architectuurbeschrijvingen als ontwerpelementen in nieuwe ontwerpen aan te bieden. Het ontwerp- en bouwgereedschap is niet in staat om volledig functionerende componenten uit de binnengehaalde informatie af te leiden. Het is echter wel mogelijk om op grond van deze informatie, voldoende functionerende skeletten van softwarecomponenten te genereren.
Op die wijze kan een werkend prototype gebouwd worden, dat zich uitstekend leent om de bruikbaarheid van de betreffende component goed te beoordelen. Besluit de ontwerper een geadverteerd pakket van softwarecomponenten te gebruiken, dan levert de repository een directe link naar de leverancier. Om automatische verwerking van het script te garanderen laat de taal, waarin het ontwerpscript geschreven is, niet toe dat elk gewenst detail toegelicht wordt. Een opgetuigde html-pagina levert echter voldoende mogelijkheden om ‘links’ op te nemen naar documenten die de geadverteerde ontwerp-elementen in groter detail beschrijven.
De voorziening
Het voorgaande tekent de eisen waaraan een toekomstig ontwerp- en bouwsysteem voor toepassingen op basis van softwarecomponenten moet voldoen. Vooraleerst moet het een geïntegreerd ontwerp- en bouwsysteem zijn. Het moet een infrastructuur kunnen leveren of kunnen ondersteunen, waarin herbruikbare componenten kunnen functioneren. Het gereedschap moet hulp bieden bij het zoeken naar passende, bestaande componenten.
Bovendien moet het de aanmaak van nieuwe componenten ondersteunen. Daarbij moet het hulp bieden bij het vinden van passende standaard interfaces. Het ontwerp- en bouwsysteem moet de skeletten van nieuwe softwarecomponenten kunnen genereren. Het is zeer wenselijk, dat reeds bestaande (volgens oudere technologieën gebouwde) software zonder grote inspanning in deze skeletten is in te passen. Dat houdt in dat softwarecomponenten in de meest gangbare programmeertalen geschreven moeten kunnen worden.
Daarnaast moeten softwarecomponenten vanuit elk van deze talen gebruikt kunnen worden. Als het hulpmiddel zelf een infrastructuur aflevert, dan moet deze zo goed mogelijk toegesneden zijn op de ontworpen toepassing. Wanneer het ontwerp klaar is en men opdracht geeft tot de bouw, dan moet het systeem een werkend prototype opleveren. Dit moet ook gelden als een aantal van de componenten alleen nog maar als skelet aanwezig is. Het is dan eenvoudiger om vanaf een vroeg stadium allerlei belangrijke karakteristieken van het nieuwe systeem te onderzoeken of te testen. Veel van de benodigde informatie is aanwezig of te genereren. Daardoor is het ontwerp- en bouwsysteem ook in staat om automatisch een groot deel van de systeemdocumentatie tot in tamelijk fijn detail te produceren.
De geïntegreerde ontwerp- en bouwomgeving moet ook hulp bieden bij het ontwerpen, bouwen en testen van losse softwarecomponenten. Dit is noodzakelijk om onafhankelijke producenten de kans te bieden mee te doen in het geschetste proces.
Doelgebieden
Volgens insiders groeit Component Based Development (CBD) snel op het terrein van de ondersteuning van de bedrijfsvoering. Daarnaast vinden softwarecomponenten gretig toepassing op de desktop zelf. Vooral in Internettoepassingen zijn ze populair. Op Internet wordt zowel van Active-X als van Javabeans gebruik gemaakt. Verder zijn veel Active-X-toepassingen op het MS Windows-platform te vinden. En ook Windows zelf schakelt deze technologie steeds vaker in.
In ingebedde software is de softwarecomponenten-technologie nog niet te vinden. Er bestaan wel besloten oplossingen, maar nog geen oplossingen die zich op een open markt richten. Voor de meeste van de huidige ingebedde systemen vormt de extra ruimte die de ondersteuning van softwarecomponenten met zich mee brengt, een onoverkomelijke hindernis.
Bovendien zijn er, afgezien van Windows CE, nog geen ingebedde besturingssystemen, die softwarecomponenten ondersteunen. Zodra er echter geïntegreerde ontwerp- en bouwomgevingen komen die voor ingebedde systemen niet alleen de softwarecomponenten, maar ook een toegesneden infrastructuur genereren, zal ook in dit gebied de situatie snel veranderen. Het ondersteunen van distribueerbare softwarecomponenten voor ingebedde systemen zal voorlopig nog wel beperkt blijven tot de zeer zware toepassingen.
Ondersteuning van gedistribueerde softwarecomponenten kost al gauw vele honderden Kbyte. Ondersteuning van kaal COM hoeft echter niet veel meer te kosten dan enkele tientallen Kbyte. Javabeans is een techniek waarbij distribueerbaarheid van componenten standaard gewaarborgd is. Deze technologie vraagt daarom een zeer hoog ondersteuningsniveau.
De technologie
Invoering van een totaal nieuwe aanpak kan op weinig ondersteuning rekenen. Daarom dient de geïntegreerde ontwerp- en bouwomgeving gebruik te maken van gevestigde technologieën. Voor de implementatie van softwarecomponenten komen twee technologieën in aanmerking. De eerste is Microsofts COM-technologie en de tweede die van Javabeans – twee niet direct vergelijkbare technologieën.
De Javabeans-technologie maakt gebruik van de faciliteiten van de Java-taal en van een lichte vorm van remote process call (RMI). Daarmee is het mogelijk om op eenvoudige wijze via netwerken gedistribueerde toepassingen te bouwen. Javabeans zijn dan ook zeer geschikt voor het bouwen van hulpmiddelen die de bedrijfsvoering ondersteunen. COM kent een groter scala van communicatiemogelijkheden. Deze lopen van een directe link binnen een proces tot gedistribueerde communicatie via netwerken. Dit laatste wordt ondersteund door een uitbreiding van COM: het Distributed Component Object Model (DCOM).
Microsoft beschouwt deze aanpak als een van zijn sleutelactiviteiten. Om die reden heeft Microsoft een wat meer aansprekende naam voor deze technologie gekozen: Active-X. Deze technologie leunt voor een belangrijk deel op voorzieningen uit MS Windows – platformafhankelijk dus. Dit betekent echter niet dat Active-X tot het MS Windows-platform beperkt blijft. Langzaam maar zeker ontstaat ook op andere platformen een gelijksoortige ondersteuning. Vaak gebeurt dit door derde partijen. Daar waar DCOM ondersteund wordt, zijn de op Active-X gebaseerde softwarecomponenten, net als Javabeans, uitstekend geschikt voor het ondersteunen van de bedrijfsvoering.
Java en daarmee Javabeans pretenderen geheel platformonafhankelijk te zijn. Daartegenover staat, dat COM (met een aantal kleine restricties) taalonafhankelijk is. De platformafhankelijkheid van Active-X geldt geenszins voor het onderliggende COM. Wel is het zo dat compilers voor COM-ondersteuning enkele niet-standaardtrucs moeten kunnen uitvoeren. Bovendien moet een eventueel toegepaste Java Virtual Machine wel erg veel op de versie van Microsoft lijken.
Beperkt men zich echter tot C en C++, dan is het zeer wel mogelijk om op willekeurige platformen een werkende versie van COM te implementeren. Door zijn COM-fundament is de Active-X-technologie veel schaalbaarder dan de Javabeans-technologie, terwijl ook de platformafhankelijkheid van DCOM betrekkelijker wordt. Het voorgaande betekent dat COM een goede kandidaat is om de softwarecomponenten van de eerder geschetste geïntegreerde ontwerp- en bouwsysteem vorm te geven. Als de te ontwerpen toepassing niet op een platform draait dat Active-X ondersteunt, dan moet het ontwerp- en bouwsysteem zelf de infrastructuur voor de ondersteuning van COM (en eventueel DCOM) leveren.
Hans van Leunen is senior system software architect bij Philips Semiconductors
Deel 2
In het vervolgartikel gaat de auteur ondermeer in op bestaande hulpmiddelen, de haalbaarheid van softwarecomponent-technologie, hybride componenten en enkele reële bezwaren.
Bij deze zoektocht naar het Ultieme Gereedschap is het wellicht zinvol terug te grijpen naar het artikel ‘Software in de leer bij hardware’ (week 17, 24 april 1998, pagina 60) van de hand van dezelfde scribent.