Voor softwareontwikkelaars lijkt componenten gebaseerde ontwikkeling iets nieuws

De Lego-weg naar Rome

Omdat de vraag naar componentgebaseerde ontwikkeling (cbd) groeit, staat de methode in de schijnwerpers en lijkt het alsof cbd iets geheel nieuws is. Maar het is zo oud als de weg naar Rome, zo meent Patrick Savalle, ontwerper methoden en technieken bij Synalyse. Volgens hem is cbd de manier waarop iedereen - behalve de softwareontwikkelaar - al eeuwenlang systemen bouwt. Wat alledaags is in de elektronica of werktuigbouw, is echter zeldzaam in de softwareontwikkeling: een bouwmarkt vol Lego-achtige bouwstenen die zich eenvoudig laten combineren tot een nieuw systeem.

Laten we één ding vooraf met elkaar afspreken: we gaan de discussie over component-based development (cbd) niet voeren alsof zaken als encapsulatie (inkapseling), abstractie, data-hiding, modulariteit en hiërarchie verworvenheden van objectoriëntatie of zelfs informatica zijn. Dat gebeurt al veel te vaak. Er wordt regelmatig geschreven dat cbd dit soort eigenschappen heeft overgenomen van objectoriëntatie, maar dat is pure onzin. Dat Grady Booch, één van de makers van de UML ('Unified Modeling Language'), deze principes in zijn boek noemt als de principes van het objectmodel is al ernstig genoeg, het zette een groot deel van de industrie op het verkeerde been. 'Structured-programming' of procedureel programmeren kent exact dezelfde principes. Iedere zinnige vorm van modellering maakt gebruik van deze principes. Het zijn geen principes van objectoriëntatie, het zijn gewoon kenmerken van goed vakmanschap.
Laten we ons bezig houden met zaken die voor de discussie wél relevant zijn. Systemen worden complexer, dus de vraag naar echte 'Legobouw' of componentgebaseerde ontwikkeling wordt groter. De gedachte is - en naar mijn mening terecht - dat cbd softwareontwikkeling eenvoudiger maakt. Het is echter onduidelijk wat cbd precies is.
Welnu, cbd is de manier waarop iedereen - behalve de softwareontwikkelaar - systemen bouwt, en al eeuwen bouwt. Cbd is namelijk zo oud als de weg naar Rome, waarover strijdwagens reden die werden samengesteld uit standaard onderdelen. Wat zo algemeen is in de elektronica of werktuigbouw, is echter enorm bijzonder in de software-engineering: een bouwmarkt vol met onderdelen die zich makkelijk laten combineren tot een nieuw systeem. In de software-engineering is cbd nog steeds niet uitgevonden.
Waar gaan al die discussies over cbd dan over? Bestaat componentgebaseerde ontwikkeling nou wel of niet? Om te kunnen bepalen of cbd bestaat, moeten we eerst definiëren wat cbd precies is. Degenen die hier de ironie van inzien, hebben gelijk.

Zwarte dozen

Een ontwikkeltraject loopt altijd van functie naar vorm. Functie is de enige eigenschap die bekend is aan het begin van het traject en vorm is datgene wat uiteindelijk de functie moet 'dragen' of beschikbaar stellen. Een ontwikkeltraject bestaat daarom ruwweg uit twee delen: een functiemodelleringsdeel en een vormmodelleringsdeel.
Als een systeem een zodanig ingewikkelde functie heeft, dat de bepaling van de juiste vorm lastig is, dan moet het systeem worden opgedeeld in delen met een eenvoudigere functie. Door het systeem recursief te beschouwen als een compositie van steeds kleinere zwarte dozen ('black boxes'), ontstaan meerdere niveaus van aggregatie met op het laagste niveau de zwarte dozen wier functie wel eenvoudig is vorm te geven. De zwarte dozen representeren een functie middels een nog onbepaalde vorm en hebben expliciete in- én uitgangen. Functiemodellering is dus voor een belangrijk deel bedoeld om complexiteit te vermijden en vertrouwt daarvoor op hiërarchie en zwarte dozen.
De zwarte dozen van het laagste niveau moeten vervolgens worden vormgegeven: het vormmodelleringdeel. Vormmodellering is het systeem functie-voor-functie 'invullen' met een specifieke vorm. In ons geval met softwarevorm ofwel programmacode. Dit is een relatief eenvoudige invuloefening, omdat complexiteit geen groot probleem meer is: daar heeft de functiemodellering voor gezorgd.
Tot zover is het verhaal duidelijk en weinig controversieel (hoewel weinig projecten worden uitgevoerd met functiemodellering), maar hoe passen componenten in dat geheel? Ook dat is eenvoudig: voor de zojuist genoemde invuloefening is voor elke functie die moet worden vormgegeven, te kiezen tussen een kant-en-klare vorm of een nog te ontwerpen vorm. Als de ontwerper geluk heeft, liggen alle benodigde vormen kant-en-klaar op de plank. Dit geluk kan hij trouwens een handje helpen door het functiemodel te laten aansluiten op de functies van reeds beschikbare componenten.
Is dat niet mogelijk, dan moet hij zelf een geschikte vorm ontwerpen en programmeren. Of solderen, uitfrezen of assembleren, want waar staat geschreven dat elke vorm een softwarevorm moet zijn? Zolang de vorm maar de juiste functie levert en voldoet aan de kenmerken van een echte 'black box'. De hier beschreven ontwikkelwijze is bij uitstek geschikt om software-engineering te integreren met andere vormen van engineering, of om het softwaresysteem naadloos te integreren met het omringende bedrijfsproces.
Deze specifieke wijze van ontwikkelen noemen we cbd. Componenten zijn deelsystemen, die, om als Lego te kunnen worden gebruikt, zijn voorzien van expliciete en gestandaardiseerde ingangen en uitgangen. Die ook, om goed te kunnen worden afgebeeld op het functiemodel, een functionele clustering van bouwstenen vertegenwoordigen. En die bovendien geschikt zijn om het systeem deel-voor-deel samen te stellen óf te ontwerpen.
Componenten zijn niets meer of minder dan zwarte dozen in standaardformaat! Of meer formeel: een component is een functionele clustering van bouwstenen, voorzien van gestandaardiseerde en expliciete in- en uitgangen.

Objecten

Hoe passen nu objecten in dit plaatje? Zijn objecten zulke kant-en-klare vormen, ofwel componenten? Dat is een beetje vreemde vraag, want objecten bestaan niet echt! Omdat het werkelijke softwaresysteem een onoverzichtelijke en veranderlijke verzameling van bits en bytes is, gebruikt de ontwerper een metafoor: hij stelt het systeem voor als een verzameling interacterende objecten. Objecten zijn eenheden van operaties en waarden die samenwerken door elkaar berichten te sturen. Objecten zijn echter geheel denkbeeldig: de ontwerper werkt met 'classes'. Het zijn de classes die de programmeur intikt. Laten we objecten dus voortaan vergeten. De 'object-metafoor' is heel bruikbaar, maar het zijn de eigenschappen van de classes waar we mee te maken krijgen zodra we voor objecttechnologie kiezen. Objecten worden niet als product opgeleverd, classes wel.
De class is een stukje code dat exact beschrijft wat de mogelijkheden van een object zijn. Een class is een type en een object is een denkbeeldige instantie van dat type, zoals wij allemaal instanties van het type mens zijn. Classes kunnen niet worden 'genest' (als een nest pannen in elkaar geschoven), zoals zwarte dozen. In plaats daarvan worden classes 'plat' verbonden door zogenaamde aggregatierelaties, ter representatie van echte hiërarchie.
Classes hebben ook geen expliciete aansluitingen zoals zwarte dozen. Aan de interface van een class is weliswaar te zien welke berichten er naar de objecten van die class kunnen worden gestuurd, maar niet welke berichten de objecten zélf weer versturen. Classes (en daarmee ook objecten) hebben dus 'onderwaterkoppelingen'. Het ontbreken van hiërarchie en de impliciete koppelingen sluiten classes, en daarmee objecten, uit als kandidaat voor componenten.
Objectoriëntatie is naar mijn mening onbegrepen technologie. Het is namelijk 'wittedoos-technologie', geschikt voor het modelleren van vorm. Net als datamodellering en 'structured-programming'. Objectoriëntatie is vanwege het ontbreken van zwartedoos-elementen niet geschikt om een compleet ontwikkeltraject mee uit te voeren en zou in principe vooraf moeten worden gegaan door functiemodellering. Om werkelijk effectief te zijn, zou objectoriëntatie moeten worden gecombineerd met een technologie die classes zodanig kan verpakken dat ze samen wél een zwarte doos vormen. Zodat objectoriëntatie kan aansluiten op functiemodellering. En die technologie is cbd. Het kringetje is nu rond. Cbd is geen speciale vorm van objectoriëntatie. Het heeft daar net zoveel mee te maken als telescopen met sterrenkunde, zou je kunnen zeggen.

Methoden

De nadruk ligt in cbd-discussies dus nog te veel op objectoriëntatie. Componenten zijn geen grote objecten en de ware kracht van cbd kan niet gemakkelijk worden benut met implementaties die hun oorsprong vinden in de objecttechnologie. Component Object Model, Javabeans of Corba zijn bepaald niet ideaal als het gaat om 'cbd-enabling techniques'. Daarvoor is hun 'objecterfenis' te groot. Objectoriëntatie is wél bruikbaar als onderdeel van het cbd-traject. Als een manier van vormgeving van de component. Naast 'structured-programming' en datamodellering.
De nadruk ligt ook nog te veel op technische aspecten in plaats van methodische aspecten. Meer dan iets anders is cbd een methode. Het is daarom vreemd dat sommige ontwikkelaars van cbd-methoden hun eigen methode een UML-variant noemen. UML ('Unified Modeling Language') is een notatie, geen methode. En als notatie heeft UML (nog) geen componentondersteuning. Een UML-component is heel wat anders dan de component die we in dit artikel bedoelen.
Omdat cbd een methode van softwareontwikkeling is, zou men mogen verwachten dat er een grote keuze uit goede cbd-methoden bestaat. Zijn goede methoden voor softwareontwikkeling echter al schaars, goede methoden voor cbd zijn uiterst zeldzaam. Zo leunt bijvoorbeeld Catalysis sterk op objectoriëntatie en maakt het daardoor dezelfde fouten. Het ziet in alles componenten, maar kent niet het concept van afnemende en aanbiedende interfaces. Het is gebaseerd op het componentloze UML en is door de enorme mate van technische detaillering in begeleidende zaken als documentatie en beschrijvingen, ook nog eens erg moeilijk.
Een andere methode, Select Perspective, schrijft een bruikbaar traject voor, maar vergeet daarbij technieken te beschrijven. Het is bij lange na niet concreet genoeg om te kunnen doorgaan voor een methode. Hoeveel methoden voor echte cbd trajecten bestaan er nog naast de twee genoemde? UML is geen methode. RUP ('Rational Unified Process') is projectfasering. Hoeveel blijft er dan nog over? Zelfs één van de standaard-boeken op het vakgebied, 'Component Software' van Clemens Szyperski, zwijgt in alle talen over cbd-methoden.

Fundamenten

De principes van cbd zijn eenvoudig en de technologie is er altijd al geweest, gek genoeg. Al lang voordat iemand wist wat Javabeans of Active-X waren, was het mogelijk om echte componenten te maken. Het recept: zorg voor begrijpelijke klonten code met een duidelijke, gezamenlijke functie, maak al hun koppelingen met andere componenten expliciet, verbind ze met gestandaardiseerde stekkers en klaar is Kees. Toch blijft de softwarewereld maar zoeken naar één of andere exotische implementatie die alles moet gaan oplossen.
Tot nu toe ontbraken gewoon de juiste conceptuele fundamenten, beschikbaar gesteld door een goede methode. Een methode die zorgt voor de integratie van de verschillende betrokken deelmethoden zoals objectmodellering, datamodellering en functiemodellering. En voor aansluiting op andere vakgebieden, want cbd is in alle opzichten een integrerende methode van ontwikkelen. Componenten kunnen op vele manieren worden ontworpen en geprogrammeerd, zonder dat de gebruiker van de component dat hoeft te weten. Componenten hoeven zelfs niet eens een softwarevorm te hebben. Als we eenmaal in componenten denken, maakt het niet meer uit of dat nu softwarecomponenten, mechanische componenten of zelfs 'menselijke componenten' zijn. Hiermee kan het softwaresysteem worden ontworpen als integraal onderdeel van zijn omgeving. De voordelen daarvan zijn natuurlijk groot.

Vijf stappen

De weg naar cbd is dus meer een kwestie van een paar kleine stappen terug dan een grote stap vooruit. In feite zijn er vijf stappen. Allereerst: 'Vertrouw op gezond verstand'. Val niet voor hypes en stop met napraten. Cbd is zo oud als de weg naar Rome, goed vakmanschap begon niet in de informatica. Probeer software te zien als een fysiek iets en volg de analogie met bijvoorbeeld elektronica. Denk in termen van fysieke bouwstenen. Bedenk ook dat een component geen Com-object of Javabean is, het is een conceptueel hulpmiddel. Cbd is een methode, geen product.
De tweede stap is het bij elkaar brengen van de bedrijfskundige en de informaticus. Componenten zorgen ervoor dat een softwareontwikkelaar zijn platte class- en datamodellen kan laten aansluiten op de hiërarchische functiemodellen van de bedrijfskundige (class-modellen en datamodellen hebben geen verschillende niveaus van aggregatie en zijn structureel gezien plat in tegenstelling tot functiemodellen). Geef ze hetzelfde denkraam (methode, vocabulaire) en ze kunnen probleemloos samenwerken.
Stap nummer drie is het herwaarderen van de objectoriëntatie. Plaats objectoriëntatie niet op de eerste plaats, begin het traject met conventionele functiemodellering. De functiemodellering is bepalend voor de uiteindelijke kwaliteit van het systeem en de mate waarin cbd-strategieën kunnen slagen. Objectoriëntatie is niet de enige keuze om componenten mee vorm te geven. Omdat cbd juist in het vormmodelleringdeel zorgt voor eenvoud, is de noodzaak voor toepassing van objectoriëntatie ook veel kleiner dan in 'conventionele' trajecten.
Stap vier: vereenvoudigen. Cbd is namelijk een belofte van eenvoud. Componenten zijn complexiteitremmers. Die belofte kan alleen worden ingelost als alles wat u gebruikt, eenvoudig is. De hulpmiddelen, de middleware, de ontwerpnotatie, de methode, zelfs de begeleidende documentatie van dit alles moet gewoon begrijpelijk zijn. Zorg ervoor dat de complexiteit verdwijnt, niet verschuift!
En ten slotte de allerbelangrijkste stap: gebruik een methode. Want behalve dat softwareontwikkeling als één van de weinige engineeringdisciplines nog niet beschikt over echte cbd, is het ook één van de weinige engineeringdisciplines waar het werken zonder methoden volledig geaccepteerd is. En dat is niet slim van mensen die zichzelf professionals noemen. Een goede methode is een denkraam en zorgt voor synergie en houvast, al was het maar omdat door toepassing van een goede methode alle ontwikkelaars hetzelfde vocabulaire gebruiken.
 

Patrick Savalle Ontwerper Methoden En Technieken Synalyse

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Lees verder


Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2002-04-12T00:00:00.000Z Patrick Savalle
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.