Reuse, components and services

A frame of reference—only available in Dutch

Voldoen aan de eisen die vanuit de business aan de systeemontwikkeling worden gesteld — sneller en goedkoper, bij gelijke of hogere kwaliteitseisen — stelt nieuwe, hoge eisen aan het ontwikkelproces. Hergebruik speelt hierbij een rol van betekenis. Reuse oriented development, zo zou de aanpak genoemd kunnen worden waarbij, op basis van componentgewijs ontwikkelen en door gebruik te maken van servicearchitecturen, optimaal gebruik wordt gemaakt van dat, wat reeds beschikbaar is.
Wil Leeuwis biedt een begrippenkader om de discussie over hergebruik, componentgewijs ontwikkelen en servicearchitecturen te vereenvoudigen.

Componentgewijs ontwikkelen (component based development, CBD) en servicearchitecturen (service oriented architectures) hebben veel raakvlakken. Beide zijn pragmatische oplossingen voor problemen waarmee de systeemomwikkeling wordt geconfronteerd. Ten eerste leidt de noodzaak sneller te ontwikkelen tot het zoeken naar mogelijkheden tot hergebruik. Traditionele inzichten van gestructureerd ontwerp en programmering, gecombineerd met objectgeoriënteerde principes leiden tot een nieuwe ontwikkelaanpak: componentgewijs ontwikkelen. Ten tweede maken gedistribueerde applicaties communicatie tussen programma's noodzakelijk. Dit leidt tot een verbreding en verdieping van het client/server-model. De aandacht verplaatst zich van hardware- naar softwareaspecten, communicatie tussen servers onderling speelt een belangrijke rol en client/server-architecturen groeien uit tot servicearchitecturen.

Een component is een onderdeel, een deel van een groter geheel. Een service is een handeling die op verzoek wordt verricht. De betekenis van deze woorden is afhankelijk van de context waarin ze worden gebruikt. Wanneer de context niet duidelijk is, is de betekenis dat ook niet, met misverstanden en spraakverwarring tot gevolg.¹ Omdat componentgewijs ontwikkelen en servicearchitecturen in het middelpunt van de belangstelling staan, is er behoefte aan een begrippenkader bij de in de praktijk gegroeide situatie. In dit artikel wordt beoogd daaraan een bijdrage te leveren, met hergebruik van code als vertrekpunt. Hergebruik is de drijvende kracht achter componentgewijs ontwikkelen — hergebruik willen vanwege de te realiseren voordelen ervan — maar ook achter servicearchitecturen, waar hergebruik soms moet omdat een andere oplossing (praktisch gezien) onmogelijk is.

Hergebruik van code

‘The essence of reuse is using what already exists to achieve what is desired’ (Goldberg en Rubin, 1995). Hergebruik van code betekent dat een programmeur tijdens het bouwen van een programma(onderdeel) bestaande code gebruikt in plaats van nieuwe code toe te voegen. Een programmeur kan code hergebruiken omdat hij daar zelf voor kiest, of omdat de organisatie dat voorschrijft. Organisaties kunnen drie motieven voor hergebruik hebben, al dan niet in combinatie: kostenverlaging, verkorting van de doorlooptijd en kwaliteitsverbetering.²
Hergebruik vindt plaats op verschillende organisatieniveaus, te beginnen op individueel niveau: iedere programmeur heeft wel een privé-verzameling van allerlei stukken en stukjes code.
Op een hoger organisatieniveau bestaat er project- en systeemgerelateerd hergebruik. Vaak ontstaat dit vanzelf in het verlengde van individueel hergebruik, maar het kan ook een gestuurde activiteit zijn. In dat laatste geval zijn de basisingredienten beschikbaar voor een doorgroei naar organisatiebreed georganiseerd hergebruik. Ten slotte bestaat er, al dan niet commercieel, hergebruik over de grenzen van organisaties heen.

Het overervingsmechanisme dat objectgeoriënteerde programmeertalen (OOP's) bieden, is een vorm van uitnodigen tot en faciliteren van hergebruik die in de programmeertaal is ingebouwd. Succesvol hergebruik van code is bij gebruik van OOP's als C++ en Java dan ook eenvoudiger te realiseren dan bij procedurele talen als Cobol. Voor een organisatie die voor de keuze van een nieuwe programmeertaal staat, is dit aspect van OOP's een aandachtspunt.³

Hergebruik van code is een activiteit die wordt gecombineerd met het schrijven van nieuwe code, met als eindresultaat een nieuw programma(onderdeel). Het is mogelijk code achteraf als hergebruikte code te identificeren als stukken code worden geïncorporeerd in het programma zonder dat daar wijzigingen op worden aangebracht. Deze vorm van hergebruik wordt aangeduid als componentgewijs ontwikkelen. De herbruikbare eenheid bij componentgewijs ontwikkelen is de component.
Een andere vorm van hergebruik waarbij code nog explicieter identificeerbaar blijft, is wanneer deze niet wordt geincorporeerd in het programma zelf, maar aanwezig is in een ander programma, en kan worden aangeroepen. Deze vorm van hergebruik is mogelijk binnen een servicearchitectuur. De herbruikbare eenheid in een servicearchitectuur is de service.
Identficatie achteraf van gebruikte code is niet mogelijk wanneer wordt gebruikgemaakt van sjablonen. Deze vormen het ruwe uitgangsmateriaal dat door de programmeur aangepast wordt aan de specifieke eisen van het programma dat wordt vervaardigd .

Beheer en infrastructurele voorzieningen

Sjablonen vragen geen extra infrastructurele voorzieningen in het bouwproces. De extra beheersmatige voorzieningen die getroffen moeten worden, voornamelijk in de sfeer van afspraken over hergebruik, zijn eenvoudig. Dit is in contrast met de beide andere vormen van hergebruik, waar goed ingerichte processen voor configuratiemanagement, wijzigingsbeheer en versiebeheer voorwaardelijk zijn voor succes: ‘(...) the benefits of reuse progressively increase as we practice reuse at higher levels of the CMM. The practice of reuse at the lower levels may not result in a net benefit’ (Lim, 1998). Additioneel daaraan vraagt organisatiebreed hergebruik ook een duidelijke organisatorische inbedding (Jacobson e.a., 1997 en Lim, 1998). Servicearchitecturen stellen naast de eisen die componentgewijs ontwikkelen aan de organisatie en de processen stelt, ook (hoge) eisen aan de infrastructuur. In figuur 1 worden de verschillende aspecten van hergebruik samengebracht.

Figuur 1: Toenemende complexiteit van beheer en infrastructurele voorzieningen

Figuur 1 lijkt te suggereren dat de opbrengsten van hergebruik door gebruik te maken van een servicearchitectuur hoger zijn dan die van componentgewijs ontwikkelen. Waarom zou je anders de toenemende complexiteit van beheer en infrastructurele voorzieningen accepteren? Deze vraag is terug te voeren op de keuzecriteria voor de verschillende vormen van hergebruik.

De begrippen

Hieronder worden allereerst de begrippen sjabloon, component en service nader uitgewerkt, waarna ze worden vertaald naar de praktijk.

• Een sjabloon is een combinatie van declaraties en/of instructies die als basis dient voor een programma(onderdeel). Een sjabloon is geen programma(onderdeel): het wordt aangepast aan de specifieke eisen die aan het te vervaardigen programma(onderdeel) worden gesteld. Sjablonen worden ook wel ‘framework’ of ‘template’ genoemd.
• Een component is een combinatie van declaraties en/of instructies. Een component wordt in zijn geheel en ongewijzigd opgenomen in het programma(onderdeel) dat wordt gebouwd. Een component kan zijn samengesteld uit andere componenten, zoals wordt geïllustreerd in figuur 2.

Figuur 2: Samengestelde componenten

In component X zijn verschillende componenten opgenomen, waaronder DatumRoutines en, daarbinnen, BepaalVerschilInDagen en ControleerDatum. Hoewel elders ook kopieën van de componenten DatumRoutines, BepaalVerschilInDagen en ControleerDatum kunnen voorkomen, is er behalve het gegeven dat het kopieën van elkaar zijn, geen relatie tussen deze componenten.

• Een service is een door een gebeurtenis geïnitieerde actie van een component (figuur 3). De actie, het uitvoeren van (een deel van) de instructies van de component, wordt veroorzaakt door een gebeurtenis, een situatieverandering. De component wordt door een bericht over de gebeurtenis geïnformeerd. Services impliceren dus interfaces (afspraken over de syntaxis van de berichten) en communicatie (afspraken over de wijze waarop de berichten worden overgebracht).

Figuur 3: Componenten en services

In deze figuur zijn twee componenten weergegeven: X en Y. In plaats van in beide de component DatumRoutines op te nemen, is deze code in een separate component opgenomen. X en Y maken nu gebruik van de services die de component DatumRoutines biedt. Ze sturen daartoe een bericht. Ontvangst van dit bericht leidt tot de uitvoering van de noodzakelijke instructies. Hiertoe behoort ook het informeren van de 'vragende' component over het resultaat.

Verschil componenten en services

De code waaruit een programma bestaat, kan op twee manieren worden beschouwd: statisch en dynamisch. Statisch beschouwd is een programma een verzameling van coderegels in een gegeven volgorde. Dynamisch beschouwd worden deze coderegels in een bepaalde volgorde uitgevoerd. Deze uitvoeringsvolgorde kan, dat spreekt voor zich, ingrijpend afwijken van de statische volgorde van de coderegels (figuur 4).
Deze verschillende beschouwingswijzen worden zelden expliciet verwoord, maar zitten wel besloten in de manier waarop over code gesproken wordt, zoals bijvoorbeeld in ‘opnemen van code’ (statisch) en ‘aanroepen van code’ (dynamisch).
Bij componenten ligt de nadruk op het statische aspect: de betreffende code wordt op de aangegeven plaats ingevoegd in het programma(onderdeel) dat wordt gebouwd. Voor een service ligt de nadruk op het dynamische aspect: de betreffende code wordt aangeroepen en uitgevoerd.

Figuur 4: Coderegels statisch en dynamisch beschouwd

Het verschil tussen een component en een service is zoiets als het verschil tussen een vierkant en een oppervlakte. Zoals vierkant en oppervlakte verschillende aspecten van een tweedimensionale figuur benadrukken, zo zijn component en service woorden die de verschillende aspecten van code benadrukken. Het verschil tussen het realiseren van hergebruik door gebruik te maken van een component of door gebruik te maken van een service, is wel goed te verwoorden: de code van de component die wordt hergebruikt, maakt deel uit van het programma(onderdeel) dat wordt gebouwd, terwijl de service alleen wordt aangeroepen.

Van theorie naar praktijk

In de abstracte termen die hierboven zijn behandeld, is het verschil tussen het realiseren van hergebruik door componenten of door services niet principieel. Vanuit technisch oogpunt is dat wel het geval. De criteria die de keuze voor component of service bepalen, zijn dan ook voornamelijk technisch van aard. Het gepresenteerde componentbegrip stelt geen grens stelt aan de grootte van een component. De bedrijfsregel
if bedrag> 1000
 then nettobedrag := bedrag * 0,95
 else nettobedrag := bedrag
endif
is een component, evenals de combinatie van alle programmatuur die binnen een organisatie operationeel is. Een dergelijk componentbegrip is te ruim om in de praktijk zinvol te kunnen gebruiken. In dit artikel is de keuze gemaakt het begrip component te reserveren voor programma's en onderdelen van programma's.⁴
Hoewel de verschillen in besturingssystemen een echte definitie van het begrip programma bemoeilijken, zal de volgende omschrijving voor de meeste gevallen voldoen: een programma is een component die direct of indirect op verzoek van een mens (gebruiker, beheerder, operator) door het besturingssysteem wordt gestart; dit ter onderscheid van de componenten die automatisch worden gestart met of op aangeven van het programma waarvan ze deel uitmaken.
Deze omschrijving biedt een aanknopingspunt om componenten te onderscheiden in onafhankelijke componenten (programma's) en afhankelijke componenten (programmaonderdelen). Dit is een goede basis voor een helder onderscheid tussen componentgewijs ontwikkelen en servicearchitecturen; tussen het component- en het servicebegrip (figuur 5):
— componentgewijs ontwikkelen houdt zich bezig met de relaties tussen afhankelijke componenten in de context van de grotere component waarvan deze deel uitmaken;
— de servicearchitectuur houdt zich bezig met de relaties tussen programma's in de context van de logische en fysieke infrastructuur waarvan deze programma's deel uitmaken.

Figuur 5: De scope van componentgewijs ontwikkelen en van servicearchitecluren in relatie tot het aggregatieniveau van coderegels

Ontwikkelomgevingen

Met de geformuleerde begrippen kan de stap naar de praktijk worden gemaakt. In ontwikkelomgevingen worden programma's in broncode via compileren, linken en laden uitvoeringsgereed gemaakt (figuur 6). Als resultaat van een programmeerproces ontstaat een sourceprogramma. Dit verwijst naar daarin op te nemen componenten in sourcevorm die, afhankelijk van de gebruikte taal (Cobol of C⁺⁺), bijvoorbeeld copysets of includemembers worden genoemd. Tijdens de compilatie ontstaat hieruit een objectprogramma: een programma in machinecode waarin verwijzingen staan naar modulen, eveneens in machinecode. Het linken voegt het objectprogramma en statische modulen samen tot een uitvoerbaar programma, de load-module genoemd. De modulen worden statisch genoemd omdat ze vanaf dat moment deel uitmaken van de load, en wijzigingen in de module niet leiden tot aanpassing van de load. Om een nieuwe versie van een statische module op te nemen, moet het linkproces opnieuw worden uitgevoerd. Dynamische modulen worden opgenomen op het moment van laden van het programma (direct voor de uitvoering) of later (op het moment dat ze worden aangeroepen). Uit het laadproces ontstaat een executable; een uitvoerbaar programma.

Figuur 6: Compileren, linken, laden en uitvoeren

Copysets en statisch of dynamisch te linken modulen zijn componenten. Modulen, met name dynamische, hebben echter een aantal serverkenmerken: copysets worden in de broncode opgenomen en maken deel uit van de statische verzameling coderegels, maar modulen worden vanuit de broncode aangeroepen: CALL module USING parameters. Dat de uitvoerbare code deel uitmaakt van het programma dat de CALL bevat, neemt niet weg dat de module een service levert.
Het feit dat een dynamische module pas op uitvoeringstijd wordt opgenomen in het programma, geeft een grote mate van onafhankelijkheid. De module kan immers worden aangepast zonder dat het aanroepende programma aanpassing behoeft. Ook dit vertoont overeenkomsten met de servicearchitectuur waarbij servers in veel opzichten onafhankelijk van elkaar zijn. Een essentieel element van de servicearchitectuur ontbreekt echter: de verschillende kopieën hebben geen relatie. Bij een server komen alle verzoeken op één plaats binnen zodat coördinatie, prioritering enzovoorts mogelijk zijn.
In de cyclus van compileren, linken, laden en uitvoeren worden de resultaten van het compileren en linken opgeslagen en speelt de sourcevorm van het programma verder geen rol bij de uitvoering ervan. Bij Java is de sourcevorm altijd de basis voor de uitvoering. Er is weliswaar sprake van een compilatie (naar bytecodeformaat), maar deze vindt voor elke uitvoering plaats. Het resultaat van de compilatie, de bytecode, is platformonafhankelijk. Dat is in termen van (mogelijkheden van) hergebruik het onderscheid tussen Java en alle andere op dit moment gebruikte programmeertalen. De bytecode wordt door een — uiteraard wel per platform verschillende — Java Virtual Machine geïnterpreteerd en uitgevoerd: ‘write once, run anywhere’.

De snelle ontwikkeling van Java, niet alleen van Java als programmeertaal, maar ook die van de ontwikkel- en deploymentomgeving, is van belang voor de ontwikkeling van het hergebruik in ontwikkelorganisaties. Als de drijvende krachten (op dit moment zijn dat Sun en IBM) Java blijvensteunen en als de belofte ‘write once, run anywhere’ gestand wordt gedaan, dan zal Java het systeemontwikkellandschap over een paar jaar ingrijpend hebben gewijzigd. Het feit dat Java een OOP is betekent ook een stevige wind in de rug voor hergebruik.

Keuzecriteria

De uiteindelijke keuze voor een vorm van herbruik hangt af van de situatie. Uit onderstaande criteria blijkt dat de keuze voor sjabloneneenvoudig is. Tussen componenten of services is het minder gemakkelijk kiezen:

• noodzaak tot aanpassing van code
De mogelijkheid code aan te passen bestaat alleen bij sjablonen. Bij componenten en services is de code een gegeven voor de programmeur. Dit impliceert dat wanneer de code aangepast moet worden, sjablonen de enige oplossing zijn. Daar waar aanpassing niet nodig is, verdient het gebruik van componenten of services de voorkeur vanwege de herkenbaarheid van het gebruik ervan.

In de praktijk is de grens tussen sjabloon enerzijds en component en service anderzijds niet zo gemakkelijk te trekken. Door in een component of service verschillende functies te bieden die geselecteerd kunnen worden door de waarde van een invoervariabele, vervalt de noodzaak de code aan te passen. Hierdoor kan wat eigenlijk een sjabloon had ‘moeten’ zijn, toch als component of service worden gerealiseerd. Dit vindt op grote schaal plaats in pakketten waarin allerlei zaken door middel van parameters kunnen worden ingesteld. Andere grensvervagingen worden geboden door programmeertalen of ontwikkelomgevingen, zoals de REPLACING-optie in het COPY-statement in Cobol.

• in principe
Op grond van de omschrijvingen van componenten en services kan de vraag worden gesteld voor welke van de twee er, al het andere gelijkblijvend, in principe zou moeten worden gekozen. Het antwoord op die vraag is: voor componenten. Gebruik van componenten is minder complex dan het gebruik van een servicearchitectuur. Gebruik van services creëert immers de additionele noodzaak tot communicatie tussen afzonderlijke programma's, en dat is een complicerende factor.

Hiermee is de vraag naar de criteria voor het gebruik van componenten of services gereduceerd tot de vraag onder welke condities van services gebruik moet worden gemaakt. Een mogelijkheid is om services te koppelen aan resources: ‘The role of a server program is to serve multiple clients who have an interest in a shared resource owned by the server’ (Orfali e.a., 1996).

• resource in het spel
Wanneer voor de uitvoering resources noodzakelijk zijn, verdienen services de voorkeur boven componenten. Resources zijn het criterium om een keuze te maken voor een component (geen resource, dan component) of een service (als resource, dan service). De meest voorkomende resource is data, maar ook andere resources kunnen een rol spelen. Denk bijvoorbeeld aan de fysieke verbinding met het internet via een webserver.

De regel ‘als resource, dan service’ is aanvechtbaar. De vraag ‘waarom zou je een dataıbase via een server benaderen als deze op hetzelfde systeem staat waarop ook het programma draait?’ is ten slotte terecht. Er is een criterium dat meer ruimte laat voor componenten: alleen services gebruiken als een oplossing met componenten onmogelijk is.

• oplossing met componenten onmogelijk
De meest voor de hand liggende reden om hergebruik met een service te realiseren, is dat het onmogelijk is het te realiseren met componenten. Dit is het geval als er een noodzakelijke platformovergang in het spel is. Hiermee is het antwoord gegeven op de vraag die bij figuur 1 werd gesteld: waarom kiezen voor servicearchitecturen terwijl dit complexer is dan oplossingen op basis van componenten?

De noodzaak van een platformovergang is altijd terug te voeren op de toegang tot bepaalde resources. Zo heeft bijvoorbeeld een server met als service het uitvoeren van een ‘modulus-11-check’ geen reden van bestaan: dit kan eenvoudig als component op verschillende platforms worden gerealiseerd. Anders ligt dat met een server die als service ‘het bepalen van het actuele openstaande saldo van een klant’ heeft. Deze service is gebonden aan het platform waarop de database zich bevindt. Realisatie in de vorm van een component zou het hergebruik beperken tot het platform waarop de database zich bevindt. Dit is voldoende motivatie om hergebruik te realiseren met een service.⁶

Gebruikmaken van services betekent communicatie tussen programma's. Communicatie tussen programma's op verschillende machines of platformen noodzaakt tot het gebruik van middleware. Performance is dan vaak het eerste praktische probleem dat zich aandient, en het is maar al te vaak een probleem dat vet en in kapitalen mag worden geschreven. In zo'n situatie kan het noodzakelijk zijn een deel van de voordelen van de servicegeoriënteerde benadering op te geven, over te gaan tot replicatie van de resources, en de services machine-of platformgebonden te realiseren.

Servicearchitecturen zijn relatief nieuw. Door er gebruik van te maken leren we hoe we er het best mee om kunnen gaan. Dat betekent voortschrijdend inzicht: criteria die aangeven wanneer we er wel en wanneer we er beter geen gebruik van kunnen maken, zullen daardoor aan verandering onderhevig zijn. Zo zouden bijvoorbeeld beveiliging en beheersing van complexiteit tot nieuwe criteria kunnen leiden.

Het ontwikkelproces

Hergebruik van code vindt plaats tijdens het programmeren. Hergebruik en het denken in termen van componenten en services drukken echter hun stempel op het gehele ontwikkelproces. Eerder is al opgemerkt dat de betekenis van de begrippen component en service contextafhankelijk is, en dat blijkt uit de verschillende componenten en services die in de loop van het ontwikkelproces worden onderkend: conceptuele of logische (modellen en beschrijvingen die aan fysieke componenten en services ten grondslag liggen), fysieke (code), technische (schermelementen zoals knoppen, menu’s en dialoogvensters) en bedrijfs-of businesscomponenten en -services (bedrijfsregels). Voor sjablonen geldt hetzelfde, bijvoorbeeld in de vorm van design patterns en frameworks. Wordt er zuiver objectgeoriënteerd gewerkt, dan wordt het begrip component veelal ook in OO-termen omschreven: ‘A component is a high-quality type, class or other UML workproduct, designed, documented and packaged to be reusable’ (Jacobson e.a., 1997).
De veelheid aan betekenissen die aan de begrippen component, service en sjabloon wordt toegekend, is inherent aan het algemene karakter ervan, en is daarmee ook onvermijdelijk. De consequentie hiervan is dat elke ontwikkelorganisatie die ze zonder problemen wil gebruiken, de moeite moet nemen ze voor eigen gebruik te omschrijven.

Inter- en intraprogrammastructuur

Met het ontwikkelproces als invalshoek kunnen componenten en services gerelateerd worden aan twee niveaus van structurering van instructies. Bij de realisatie van een systeem wordt het geheel aan instructies dat tezamen de functionaliteit van het systeem vormt, als volgt gestructureerd:
• interprogramma
Functies worden gegroepeerd in programma's die ten opzichte van elkaar worden gestructureerd
• intraprogramma
Binnen elk programma worden instructies gestructureerd in, binnen de context van het programma, onderscheiden functies.

Bij het bepalen van de interprogrammastructuur is de servicearchitectuur leidend. Enerzijds geeft het gekozen model duidelijk aan welke functies in de verschillende lagen moeten worden gepositioneerd. Anderzijds bepalen reeds beschikbare services welke functionaliteit kan worden hergebruikt en welke nog moet worden ontwikkeld.
Bij het bepalen van de intraprogrammastructuur staat componentgewijs ontwikkelen centraal. Elk programma wordt gestructureerd op een zodanige wijze dat optimaal hergebruik plaatsvindt: bestaande services en componenten worden gebruikt en nieuwe functies worden waar mogelijk als herbruikbare componenten gerealiseerd.

Veranderende rollen

Herbruikbare componenten en services vragen een zekere mate van generalisatie, maar wie stelt die generieke eisen en wensen op? Van de individuele gebruiker kan dit in het algemeen niet worden verwacht, omdat het generieke karakter impliceert dat aan de wensen van verschillende gebruikers wordt voldaan. Ook van de ontwerper mag dit niet worden verwacht. Als dat wel zo was, zou het formuleren van de (eenvoudigere) niet-generieke eisen en wensen immers zéker door de ontwerper alleen gedaan kunnen worden — de ervaring leert echter anders.⁷

Als het aantal herbruikbare componenten en services nog gering is (wat samen zal gaan met een beperkte generalisatie, waardoor de toepasbaarheid ook gering is) moet de organisatie hierop worden aangepast.⁸ Dit betekent dat bij het bepalen van herbuikbaarheid niet wordt gezocht naar zaken die zonder meer bruikbaar zijn, maar dat wat beschikbaar is, wordt aangepast, ofwel generieker wordt gemaakt. Op deze manier kan hergebruik geleidelijk groeien. Daarbij ontstaan verschillende rollen: enerzijds ontwikkelaars die herbruikbare componenten en services beheren en generieker maken en anderzijds ontwikkelaars die deze herbruikbare eenheden gebruiken en aanvullen met specifieke, niet-herbruikbare code. Een voorwaarde voor succesvol hergebruik is dat deze twee typen ontwikkelaars nauw samenwerken.

Dat rollen in het ontwikkelproces aan verandering onderhevig zijn, heeft met meer factoren te maken dan de opkomst van componenten en services, en dat geldt zeker voor de beweging van meer naar minder gespecialiseerde rollen. De aan de watervalmethode gekoppelde rollen van informatieanalist, functioneel ontwerper, technisch ontwerper en programmeur maken plaats voor de aan incrementele en iteratieve methoden gekoppelde rol van systeemontwikkelaar die analyse, ontwerp en programmering in zich combineert. Servicearchitecturen en componentgewijs ontwikkelen dragen bij aan de integratie van het functioneel ontwerp (de beantwoording van de wat-vraag) en het technisch ontwerp (de beantwoording van de hoe-vraag), doordat het gebruik van herbruikbare eenheden met het ‘wat’ ook direct invulling geeft aan het ‘hoe’.

Componenten en services bieden de mogelijkheid het ontwikkelproces te verbeteren: het wordt sneller en/of goedkoper en krijgt door hergebruik een betere kwaliteit. Maar hergebruik komt niet vanzelf op een organisatiebreed niveau. Evenmin ontstaat een bij de organisatiedoelstellingen aansluitende mix van ‘sneller, goedkoper en beter’ uit zichzelf. Dat vraagt onder meer om visie, aanpassingen in organisatie en processen, regie, investeringen en tijd.

Noten

1. Het woord component is afgeleid van het Latijnse compositus = samengesteld, het woord service van het Latijnse servio = dienen. Het Engelse woord component verandert bij vertaling in het Nederlands niet. Het zou kunnen worden vertaald met dienst, maar dat zou de verwarring (dienstenarchitectuur?) alleen maar groter maken.
2. Dat hergebruik de doorlooptijd verkort en de kosten verlaagt tijdens een bouwproces waarin wordt gebruikgemaakt van bestaande code, is evident. Dat hergebruik van kwalitatief hoogwaardige herbruikbare code een positieve invloed heeft op de kwaliteit van het product waarin de code wordt gebruikt, behoeft ook nadere toelichting. Het bepalen van kosten en opbrengsten van hergebruik is echter complexer, zie hiervoor bijvoorbeeld Managing Software Reuse (Lim, 1998).
3. Dit is uiteraard in nog grotere mate het geval bij de keuze van een nieuwe aanpak voor de systeemontwikkeling als geheel — analyse, ontwerp, bouw.
4. Deze keuze sluit aan bij omschrijvingen die voor component worden gegeven: ‘A component is a piece of software small enough to create and maintain, big enough to deploy and support, and with standard interfaces for interoperability.’ (Orfali, 1996).
5. Een programma wordt in de context van een servicearchitectuur overigens wel server program of kortweg server genoemd.
6. Tenzij replicatie van de database én mogelijk is, én een beter alternatief is dan de service.
7. Hier is een nuancering op haar plaats: voor componenten en services met een infrastructureel of technisch karakter zijn door gebruikers geformuleerde eisen en wensen minder of in het geheel niet van belang, en juist deze zijn vaak zeer generiek.
8. Dit heeft ook gevolgen voor de budgettering. Brooks (1995) gaf in 1975 al aan dat generaliseren en integreren leidt tot drie tot negen maal hogere kosten. Projectbudgetten bieden budgettair niet de ruimte en een projectorganisatie is niet geschikt voor het realiseren van generieke oplossingen (Kranenburg e.a., 1999).

Literatuur

Brown, William J., e.a.. AntiPatterns, Refactoring Software, Architectures and Projects in Crisis, Wiley, 1998, ISBN 0471 19713 O.
Goldberg en Rubin: Succeeding with Objects, Decision Frameworks for Project Management, Addison-Wesley, 1995, ISBN 0 201 62873 3.
Jacobson, Ivar, e.a.. Software Reuse, Architecture, Process and Organization for Business Success, Addison-Wesley, 1997, ISBN 0 201 924765.
Kranenburg, Kees, e.a.. De moderne softwarefabriek, De organisatie en werking van een software development & maintenance center, 1999, tenHagenStam, ISBN 90 763 0470 X.
Lim, Wayne c.. Managing Software Reuse, A Comprehensive Guide to Strategically Reengineering the Organization for Reusable Components, Prentice Hall, 1998, ISBN 0 135523737
Orfali, Robert, e.a.: The Essential Client/Server Survival Guide, 2nd Edition, Wiley, 1996, ISBN 0471 153257.
Paulk, Mark c., e.a.: The Capability Maturity Model: Guidelines for Improving the Software Process, Addison Wesley, 1994, ISBN 0 201 54664 7.

original publication: Wil Leeuwis, in: informatie, September 2000, p. 9-17. © 2000, informatie.