Sotfware-ontwikkeling met componenten (cbd) als gestructureerde aanpak van systeemontwikkeling vraagt om een zeer stringente definitie van het concept component. Een algemeen erkende definitie van de term component ontbreekt echter. Een cbd-architect plaatst componenten in perspectief en zet cbd tegenover andere ontwikkelingstechnieken als information engineering en object oriëntatie.
Component-based development (cbd) wordt algemeen beschouwd als de volgende stap voorwaarts in de ontwikkeling van informatiesystemen. Aan cbd worden onder meer de voordelen van herbruikbaarheid, vervangbaarheid, flexibiliteit en minder complexe systeemontwikkeling toegeschreven. Bij al deze voordelen is het goed om te weten dat er veel verschillende opvattingen over componenten bestaan [7]. Een algemeen erkende definitie van de term component ontbreekt echter.
Het gemeenschappelijke element bij de verschillende definities is veelal ‘een onderdeel van een systeem dat afgescheiden kan worden van de rest van het systeem’ [6], een definitie die veel te algemeen is voor cbd. Om de toegeschreven voordelen te kunnen verwezenlijken, hebben we een stringentere definitie voor de term component nodig.
Een component is een zelfstandig af te leveren pakket software-services, met de volgende kenmerken [1,2,3]:
De services van een component worden aangeboden via goed gedefinieerde, stabiele interfaces.
Een component is ingekapseld, wat wil zeggen dat de specificatie en de implementatie van elkaar gescheiden zijn. Verder kan een component worden vervangen door andere componenten die (minimaal) dezelfde set operaties bieden. En tot slot is een component volkomen onafhankelijk van de implementatie van andere componenten. Afhankelijkheden tussen componenten zijn enkel toegestaan via het aanroepen van elkaars interfaces.
Het voordeel van de eis tot inkapseling is dat een gebruiker alleen de specificatie van de ingekapselde software hoeft te kennen. Hierdoor kan de implementatie worden aangepast zonder dat dit gevolgen heeft voor gebruikers van de component.
Soorten componenten
De definitie van een component zegt nog niets over de omvang of inhoud van de component. Componenten kunnen variëren van een OCX-control op een gebruikersinterface tot een groot subsysteem. Componenten kunnen ruwweg worden opgesplitst in infrastructuurcomponenten en bedrijfscomponenten.
Infrastructuurcomponenten bieden services waarmee ontwikkelaars andere applicaties of componenten kunnen samenstellen. Hieronder volgt een aantal voorbeelden.
Componenten voor een gebruikersinterface bestaan uit besturingselementen voor een gebruikersinterface, zoals knoppen, keuzelijsten en tab-controls.
Componenten voor een technische infrastructuur bieden technische functies zoals communicatieondersteuning en transactiebesturing.
Componenten voor een systeeminfrastructuur bieden algemene systeemondersteunende functies zoals applicatie-autorisatie of foutafhandeling.
Componenten voor een applicatie- of bedrijfsinfrastructuur bieden algemene bedrijfsroutines zoals valutaconversie of renteberekeningen.
Bedrijfscomponenten bieden operaties ter directe ondersteuning van de bedrijfsprocessen. Deze componenten ondersteunen persistentie van de gegevens. Ze kunnen worden onderverdeeld op basis van hun fijnmazigheid en inhoud. Zo zijn de volgende subcategorieën te onderscheiden.
Met bedrijfsobjectcomponenten worden de gegevens en functies van een bedrijfsobject geïmplementeerd, bijvoorbeeld een klantcomponent of een ordercomponent.
Met taakgerichte componenten (functiecomponenten) worden bepaalde bedrijfsactiviteiten uitgevoerd. Deze activiteiten kunnen de operaties van een of meer bedrijfsobjecten omspannen.
Subsysteemcomponenten bestaan uit volledige subsystemen, waarbij vaak een gedeelte van de functionaliteit via interfaces ter beschikking wordt gesteld.
Perspectieven van een component
Voor cbd is een aantal definities geïntroduceerd die stringenter zijn dan alleen ‘een onderdeel van een systeem dat afgescheiden kan worden van de rest van het systeem’. In het algemeen vallen deze definities onder een van de volgende drie perspectieven [7].
In het ‘package’-perspectief is sprake van een component als eenheid van levering. In het service-perspectief is een component verlener van services (wordt ook wel interface-perspectief genoemd). In het integriteitsperspectief is een component een ingekapselde eenheid die onafhankelijk is van de implementatie van andere componenten.
Deze perspectieven scherpen elkaar aan. De eerder gegeven definitie van een component komt overeen met het derde, meest stringente, perspectief.
Het package-perspectief is het meest algemene perspectief met de minste beperkingen en tevens het basisconcept voor componenten dat door UML [4] wordt gehanteerd. Hierbij is ‘een component een herbruikbaar onderdeel dat als fysieke verpakking voor modelelementen dient’. De nadruk ligt op hergebruik. Deze algemene definitie dekt elk onderdeel dat bij applicatieontwikkeling opnieuw gebruikt kan worden, zoals documenten, broncodebestanden, objectmodules, programmabibliotheken, databases, enzovoort.
Het service- of interfaceperspectief is het perspectief dat bij de belangrijkste standaardcomponentmodellen wordt gehanteerd (Dcom, Corba en Java Beans). Hier is een component een softwarepakket dat zijn services via interfaces aanbiedt. Een interface is een verzameling van operaties en wordt gezien als een contract tussen de verlener en de gebruiker van de services. Dit perspectief introduceert tevens het grote verschil tussen de specificatie van een component (wat wordt er gedaan) en de implementatie van een component (hoe wordt dit gedaan) [7].
Door de nadruk te leggen op de interface is de complexiteit van de systeemontwikkeling danig te reduceren. Het enige dat een gebruiker over een component hoeft te weten, is het gedrag dat door de interfaces gespecificeerd wordt. De gebruiker hoeft niet te weten hoe de component intern werkt. Zolang de interface ongewijzigd blijft, kunnen diverse alternatieve implementaties ingezet worden. Aangezien de componentmodellen tevens een binaire standaard vormen, faciliteren zij de assemblage van componenten die in verschillende tools en programmeertalen gemaakt zijn.
Het integriteitsperspectief. Het concept van ‘een softwarepakket dat zijn services aanbiedt via interfaces’ vormt echter geen garantie dat de componenten onafhankelijk van elkaar kunnen worden vervangen. Stel dat bij de implementaties van twee componenten dezelfde databasetabel wordt gebruikt. Als de implementatie van de ene component wordt gewijzigd, heeft dit zeker gevolgen voor de werking van de andere component, hoewel er niets is veranderd aan de interfaces.
Een component is pas echt ‘plug-and-play’ als deze onafhankelijk is van de implementatie van andere componenten. Een component kan wel samenwerken met andere componenten, maar dan alleen via de interfaces. Als de componenten alleen van elkaar afhankelijk zijn op het niveau van hun specificatie en dus niet op het niveau van hun implementatie, heeft een wijziging veel minder gevolgen.
Cbd versus oo en ie
Cbd wordt vaak aangeprezen als een compleet nieuwe methode, een heel nieuw paradigma, kortom: een revolutionair concept. Dit roept dan ook direct de vraag op wat cbd onderscheidt van andere methoden zoals ‘information engineering’ (ie) en ‘object orientation’ (oo). Zijn ie en oo nu verouderd, overbodig en onbruikbaar geworden, of vormen ze daarentegen de enige echte basis voor cbd en een must om alle mogelijkheden van cbd te benutten?
‘Information engineering’ en ‘object orientation’ zijn beide beproefde methoden voor systeemontwikkeling. Er zijn reeds vele goede systemen gebouwd met ie of oo, en ze kunnen dus zeker niet als afgedaan of verouderd worden beschouwd. In feite zijn cbd, ie en oo niet meer dan andere manieren om hetzelfde probleem aan te pakken. Ofschoon elke methode het probleemgebied vanuit zijn eigen invalshoek benadert, blijken zij elkaar eerder aan te vullen dan dat ze conflicterend zijn. Cbd heeft zelfs veel van de concepten en bewezen technieken overgenomen van zowel ie en oo.
Cbd en ie
Van ie heeft cbd de bedrijfsgerichte aanpak overgenomen, de aandacht voor de verschillende architecturen en de clustertechnieken waarmee een complex probleem opgesplitst kan worden in kleinere, behapbare brokken.
Daar waar de traditionele ie echter neigt naar volledig geïntegreerde databases en sterk gekoppelde applicaties, richt cbd zich meer op geïntegreerde, maar losjes gekoppelde applicaties. Hiermee worden de gevolgen van wijzigingen minder ingrijpend, ontstaat meer flexibiliteit en worden veel van de praktische problemen opgelost die bij grootschalige ie-projecten zijn opgetreden.
Cbd en oo
Het afschermen van data en het combineren van gegevens en operaties in hetzelfde ‘object’ zijn concepten die duidelijk afkomstig zijn van oo. Gedragsgeoriënteerde analysetechnieken zijn bijzonder waardevol om de componentarchitecturen vast te leggen [5].
We mogen echter niet vergeten dat de interface niet tot de standaardconcepten van oo behoort, hoewel bepaalde oo-talen zoals Java hiervoor wel ondersteuning bieden [8]. Daarnaast zijn veel oo-methoden voornamelijk op systeemontwerp en programmeertechnieken gericht, zodat een oo-aanpak doorgaans kleine fijnmazige componenten oplevert. Dit is op zich niet voordelig of nadelig te noemen. De definitie van een component zegt namelijk niets over de omvang. Als we echter meer inzicht in en meer greep op grootschalige componentarchitecturen willen krijgen, moeten we niet alleen naar oo-programmeertechnieken kijken maar ook naar andere concepten.
Veel oo-experts beweren dat cbd alleen kan worden verwezenlijkt door de componenten met oo-talen te bouwen. Een blik op het service-perspectief van een component maakt al snel duidelijk dat de interne structuur van de component niet van belang is voor cbd. Zodoende is ook de taal en tool waarmee men een component implementeert niet essentieel voor cbd. Voor het praktisch gebruik is het echter wel van belang of de taal of tool de cbd-concepten goed ondersteunt.
Concepten en voordelen
Cbd wordt verondersteld voordelen te bieden met betrekking tot herbruikbaarheid, flexibiliteit, vervangbaarheid en minder ingewikkelde systeemontwikkeling. In veel publicaties wordt overdreven veel aandacht aan het herbruikbaarheidsaspect geschonken, waardoor een vertekend beeld is ontstaan dat grote kans op teleurstellingen geeft. De andere drie aspecten leveren misschien wel veel meer voordelen voor een bedrijf op.
De algemene definitie, ‘een onderdeel van een systeem dat afgescheiden kan worden van de rest van het systeem’, vormt een prima uitgangspunt voor de structuur van elk type systeem. Ingenieurs en architecten gebruiken dit concept al jaren bij het ontwerpen van gebouwen, organisaties, elektrische- en mechanische systemen en sinds kort ook informatiesystemen. De splitsing van een systeem in subsystemen of ‘componenten’ is een belangrijke stap in de richting van minder ingewikkelde systemen.
De definitie van het ‘package-perspectief’ legt de meeste nadruk op hergebruik. En het opnieuw gebruiken van bestaande broncode en documenten heeft zijn waarde al ruimschoots bewezen in de IT-branche. De voordelen van concepten zoals sjablonen, broncodeverzamelingen en gedeelde bibliotheken moeten zeker niet worden onderschat.
Bij de service- en integriteitsperspectieven ligt de nadruk meer op flexibiliteit, vervangbaarheid en minder ingewikkelde systeemontwikkeling. Flexibiliteit verwijst hier naar het gemak waarmee een applicatie kan worden aangepast aan veranderende behoeften. De flexibiliteit is er enorm mee gebaat als wijzigingen slechts een beperkt gedeelte van het systeem beïnvloeden. Dit vraagt om componentarchitecturen die zo zijn opgezet dat de meeste wijzigingen die men kan voorzien, slechts één component raken en bij voorkeur de interface ongemoeid laten. Het feit dat componenten alleen via hun interface van elkaar afhankelijk zijn, maakt het mogelijk de ene component door de andere te vervangen zolang ze dezelfde interface hebben. Systeemontwikkeling wordt hiermee veel minder gecompliceerd, omdat de (andere) componenten als ‘zwarte doos’ te beschouwen zijn: alleen de interactie via hun interfaces is relevant.
Dit betekent overigens niet dat service-gerichte componenten geen hergebruik ondersteunen. Integendeel, het interfaceconcept stelt de investering in de verzameling van componenten veilig, omdat hiermee componenten kunnen worden samengevoegd die met verschillende tools en talen zijn gemaakt.
Hoewel het service-perspectief van een component veel voordelen biedt, is dit lang niet overal de beste oplossing. Een analyse van een componentarchitectuur moet altijd uitgaan van het doel van de architectuur. Als er alleen componenten zijn gedefinieerd om een beter inzicht in de systeemconcepten te krijgen, heeft het weinig zin van tevoren al te besluiten elke component als service-gerichte component te implementeren. Het splitsen van componenten door er een interface tussen te voegen heeft alleen zin als die interface stabiel blijft bij de meeste te voorziene wijzigingen. Als dat niet het geval is, brengt het aanzienlijke extra ontwikkelingskosten met zich mee.
Kennis van architectuur
Er bestaan vele verschillende definities van de term component, variërend van heel algemene tot zeer stringente. Cbd vraagt als gestructureerde aanpak van systeemontwikkeling om een zeer stringente definitie van het concept component. De meeste nadruk wordt gelegd op het integriteits- en service-perspectief als randvoorwaarde voor echte ‘plug-and-play’-vervangbaarheid van componenten.
Voor cbd zijn geen oo-tools of -talen vereist, hoewel veel van de concepten van oo worden toegepast. Cbd is niet hetzelfde als oo of ie, maar levert hiermee ook geen conflicten op. Ze liggen in feite in elkaars verlengde.
Het gebruik van componenten biedt veel voordelen en het perspectief dat iemand daarbij moet hanteren, is afhankelijk van het voordeel dat het best aansluit op de behoeften. Een componentarchitectuur moet daarom altijd beoordeeld worden op haar doel. Het heeft weinig zin om van tevoren al te besluiten alle geïdentificeerde ‘componenten’ in een architectuur te implementeren als service-gerichte componenten.
Een goede definitie van een component is één ding, maar daarmee is nog niet duidelijk wanneer een component een zinvolle component is. Hiervoor is kennis van architecturen en hun ontwerp vereist, het onderwerp van een volgend artikel.
Aernout van Veluwen, cbd-architect Sterling Software, Amsterdam
Literatuur en informatie
[1] Advisor: Glossary and Concepts. Advisor is de cbd-informatiebron van Sterling Software voor Cool:Spex. http://www.sterling.com/products.
[2] Component-Based Development Fundamentals, Cool:Gen Electronic Books. Electronic Books is de online informatiebron van Sterling Software voor Cool:Gen.
[3] Cbd 96 Standards, Cool:Gen Electronic Books. Electronic Books is de on line informatiebron van Sterling Software voor Cool:Gen.
[4] Fowler, M., Scott, K.: UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley.
[5] D’Souza, D., Wills, A.: Objects, components, and frameworks with UML: A catalysis approach, Addison-Wesley.
[6] Lassing, N.H., Rijsenbrij, D.B.B., Vliet., J.C. van: A View on Components, Proceedings of the 9th International Dexa Workshop on Database and Expert Systems Applications, Ieee Computer Society, Los Alamitos, 768-777.
[7] Cheesman, J.: What is a Component, Sterling Software White Paper, 5 februari 98.
[8] Taylor, D., Objects in Business, Object Magazine, 7(10), december 1997 .
Sterling Sofware hanteert het integriteitsperspectief. Dit is het meest stringente perspectief voor de definitie van een component. In zijn visie moet ‘component based development’ een gestructureerde aanpak van systeemontwikkeling zijn op basis van service-gerichte componenten die het integriteitsbeginsel aanhangen. Dit betekent overigens niet dat de andere benaderingen van componenten onbruikbaar of ongegrond zijn. Integendeel, in veel situaties komen andere componentconcepten goed van pas. Als we echter over componenten spreken in verband met CBD, verwijzen we hiermee naar de stringente definitie aan het begin van dit artikel.
