De architectuur van een complex geautomatiseerd systeem wordt meestal bepaald door een kleine groep van nauw samenwerkende architecten. Zij maken gebruik van (deel)modellen, die als uitgangspunt dienen bij het maken van bijvoorbeeld objecten en componenten. Een architect geeft inzicht in de samenstelling van architecturen.
Er bestaan evenzoveel definities van architectuur als er schrijvers over dit onderwerp zijn. Dit tekent niet zozeer de verwarring als wel het grote aantal gebieden waarin architectuur een rol speelt. Het doelgebied in dit artikel is het terrein van hardware en software in geautomatiseerde systemen. De architectuur van een complex geautomatiseerd systeem wordt meestal bepaald door een kleine groep van nauw samenwerkende architecten. Hun uitgangspunten zijn de eisen van de klant, de bestaande regels en de ter beschikking staande methodieken. De uitgangspunten zijn vaak tegenstrijdig en vrijwel altijd onvolledig. De architecten moeten hun ervaring en hun combinatorische en creatieve talenten benutten om tot een coherente visie te komen. Deze visie wordt vervolgens door de systeembouwers gebruikt bij het daadwerkelijk neerzetten van het systeem. Een architectuur bestaat dus feitelijk uit een aantal aanzichten van een model van het te bouwen systeem. Deze kunnen de vorm hebben van tekeningen, schema’s, maquettes, prototypes of geschreven documenten. In de meest moderne vorm bestaan deze aanzichten uit een verzameling van onderling gekoppelde ‘elektronische’ documenten. De aanwezige verbanden kunnen dan automatisch naar voren gehaald worden. Grafisch weergegeven abstracties leveren in één blik een waardevol overzicht.
Een architectuur is niet statisch, maar leeft mee met het project waarmee hij verbonden is. In het begin van het project zijn de aanzichten nog tamelijk schetsmatig. Later worden ze steeds gedetailleerder.
De geproduceerde aanzichten leveren een hoog abstractieniveau. Dit maakt ze tot een uitstekend middel bij het zoeken naar herbruikbare bestanddelen. Hergebruik wordt het best gestimuleerd wanneer de architecten bij hun analyse behalve het huidige doelproduct ook het hele toepassingsgebied in beschouwing nemen.
Relatie met modelleren
Modelleren is een vorm van abstraheren van een natuurlijke omgeving of van een kunstmatig concept. Om het model te kunnen realiseren is het nodig om eerst te onderzoeken uit welke modelleringselementen het opgebouwd kan worden. Een complex model is op te splitsen in een aantal deelmodellen. Primitieve modellen kunnen niet op zinvolle wijze verder in deelmodellen worden opgesplitst. Wel bevatten ook deze modellen nog een aantal modelleringselementen: eigenschappen, relaties, gedragsaspecten,communicatie, inkapseling en coördinatie.
Eigenschappen en relaties behoren tot de categorie van de bezittingen (attributen) van een individu. Sommige modelleringsmethodieken beschouwen beperkingen als een aparte categorie van modelleringselementen. Hier behandelen we beperkingen als eigenschappen van het gemodelleerde onderwerp.
Gedragsaspecten en communicatie zijn complexe begrippen die vermengd zijn met eigenschappen en relaties. Gedrag kan worden gesplitst in groepsgewijs gedrag en de invloed van de interne status van het groepslid. Door deze invloed krijgt het gedrag zijn individuele karakter. De interne status is opgebouwd uit eigenschappen en relaties. Dit valt onder de categorie van de bezittingen. Communicatie loopt via relaties. Via dit relatiepad wordt een bericht of commando overgebracht. Het bericht bestaat uit attributen. Bij aankomst veroorzaakt het bericht een reactie. Deze reactie kan zich beperken tot een verandering van de interne status van de ontvanger. Erg belangrijk is dat de communicatie volgens een vooraf vastgelegd protocol verloopt, anders heeft communicatie geen zin.
Deze beschouwing leidt tot een andere verzameling van primitieve modelleringselementen: attributen, groepswijde gedragsaspecten,protocol, reactie, inkapseling en coördinatie.
Deze verzameling is voor architecten beter bruikbaar omdat systeembouwers vaak directe implementaties voor deze modelleringselementen hebben. Ingeval van software krijgen we dan het beeld, zoals weergegeven in figuur 1.
Klassenbibliotheek
De gedragsaspecten en het communicatieprotocol zijn modelleringselementen die een groepswijde of zelfs nog ruimere reikwijdte hebben. Dit levert voordelen op, omdat deze aspecten dus niet voor elk individueel model afzonderlijk ontworpen en gebouwd hoeven te worden. Bij grote en complexe systemen is het daarom zinvol om te zoeken naar deelmodellen, die een gelijkwaardig gedrag vertonen. Door deze deelmodellen in groepen samen te brengen kunnen equivalentieklassen gebouwd worden. Als tegelijkertijd de modellen ingedeeld worden in een rangorde van simpel naar complex, dan zijn complexe modellen uit eenvoudiger modellen af te leiden. Op die wijze ontstaat een boomstructuur van equivalentieklassen. Een klassenbibliotheek is een verzameling van dergelijke equivalentieklassen waarin voor elke afgeleide klasse alleen het verschil met zijn voorvaderen opgeslagen is.
Het gebruik van een klassenbibliotheek heeft grote voordelen, maar kan ook ernstige nadelen hebben. De boomstructuur nodigt uit om veelvuldig gebruikte diensten in de topklassen onder te brengen. Dit heeft het voordeel dat alle lager gesitueerde klassen automatisch van deze diensten profiteren en dat alle met deze klassenbibliotheek gebouwde systemen over deze diensten kunnen beschikken. Het nadeel is dat op deze wijze ingebouwde diensten door hun verwevenheid met de rest van de bibliotheek moeilijk aan vernieuwde omstandigheden aangepast kunnen worden. Bovendien leidt het er toe dat deelstructuren van de klassenbibliotheek niet samen kunnen worden toegepast in een andere, onafhankelijk opgezette klassenbibliotheek. Klassenbibliotheken hebben in de praktijk nog een extra nadeel, dat alleen een rol speelt als onafhankelijke partijen met de bibliotheek moeten kunnen werken. Het is bijna onmogelijk om de klassenbibliotheek op efficiënte wijze verder uit te breiden, zonder dat men over de broncode van de bibliotheek beschikt. Bovendien is het ondoenlijk om een toepassing die met de bibliotheek gebouwd is, te debuggen zonder dat inzicht in de broncode gegeven wordt. De klassenbibliotheken zijn vaak zo groot en zo complex dat de beste documentatie ervan de broncode zelf is. Een klassenbibliotheek wordt daarom vaak vergezeld van krachtige navigatiehulpmiddelen.
De meeste op equivalentieklassen gebaseerde ontwerp- en bouwsystemen springen slordig om met het modelleringselement inkapseling. Het gevolg is dat allerlei extra relaties en meerdere vormen van communicatieprotocollen ontstaan, die feitelijk onnodig en zelfs onnatuurlijk zijn. Hierdoor daalt de beheersbaarheid van het ontwerp aanzienlijk. Dit kan bij grote complexe systemen desastreuze vormen aannemen.
Objectgeoriënteerde technologie
Ondanks de hierboven opgesomde nadelen heeft de objectgeoriënteerde technologie een grote vlucht genomen. Dit is voor een deel te danken aan het feit dat in een groot aantal situaties de genoemde nadelen geen noemenswaardige rol spelen. Voor een ander deel is het te danken aan de zeer krachtige hulpmiddelen die het objectgeoriënteerd ontwerpen en bouwen ondersteunen. Deze hulpmiddelen zijn samengebracht in een geïntegreerde ontwikkelomgeving.
De genoemde nadelen spelen met name geen rol van betekenis wanneer een gesloten groep ontwikkelaars een serie samenhangende producten ontwerpt en bouwt. Zolang de gebruikte klassenbibliotheken beheersbaar blijven, is de objectgeoriënteerde technologie in deze situatie de meest ideale oplossing. Klassenbibliotheken hebben de neiging om exponentieel te groeien. Daardoor bestaat er gevaar dat deze op den duur onbeheersbaar worden.
De opgesomde nadelen maken de objectgeoriënteerde technologie minder geschikt voor het bedienen van een open markt, waarin onafhankelijke partijen bijdragen in de totstandkoming van een doelsysteem.
Metamodel
Om effectief met de modelleringselementen te kunnen werken, is het nodig om te beschikken over overeenkomstige metamodelleringselementen. Dit zijn hulpmiddelen die de modelleringselementen voldoende nauwkeurig omschrijven. De leden van een klasse van equivalente modellen worden omschreven in een typedefinitie. De typedefinitie wordt, als het goed is, maar één maal binnen een werkomgeving geproduceerd. Vervolgens wordt ernaar verwezen via een referentie, die kortweg met ’type’ aangeduid wordt. In programmeertalen staan de typedefinities van standaard typen vaak verborgen. Op zich zijn attributen te beschouwen als deelmodellen of als referenties naar deelmodellen. Zij hebben dus ook een typedefinitie en een type. Hetzelfde geldt voor de methoden. Voor methoden volstaat men vaak met een schetsmatige omschrijving, die wordt aangeduid met de term ‘functieprototype’. Het bijbehorende type heet ‘functietype’.
Om hergebruik en gebruiksgemak te stimuleren is het zinvol om methoden samen te brengen in geordende groepen, waarin de methoden tezamen een consistente service vertegenwoordigen. Om de inkapseling te verbeteren, kan men dan besluiten om de toegang tot de implementatie van een model alleen toe te staan via een ingangspunt van een dergelijk interface. Als er meer dan één interface aanwezig is, dan moet wel een mechanisme worden toegevoegd dat het navigeren tussen deze interfaces mogelijk maakt. Zo’n interface vormt een kunstmatig geconstrueerd submodel. Net zoals alle normale modellen heeft het een typedefinitie en een type. De typedefinitie van een interface bevat naast een naam ook een unieke identificatie, welke via een guid (‘globally unique identifier’, wereldwijd unieke identificatie) weergegeven wordt.
De metamodelleringselementen zijn bij uitstek geschikt om hergebruik te optimaliseren en te stimuleren. Immers, als een architect gebruik maakt van metamodelleringselementen die reeds bij andere systemen toegepast worden, dan is de kans groot dat de herbruikbaarheid van het eindproduct en van de samenstellende componenten stijgt. Het zal zeker het hergebruik van deze producten stimuleren.
Objecten en componenten
De objectgeoriënteerde ontwerp- en bouwmethodiek is een technologie die gebruik maakt van vaak diepgelaagde klassenbibliotheken. Objectgeoriënteerde systemen zijn meestal grote monolieten, welke door een gesloten groep ontwerpers en bouwers samengesteld worden.
De eenkennigheid van diepgelaagde klassenbibliotheken en de vaak slappe houding ten opzichte van inkapseling van de objectgeoriënteerde methodologie heeft ertoe geleid dat naar andere benaderingen gezocht is. Op deze wijze is de op componenten gebaseerde ontwikkeling ontstaan. Deze aanpak betekent geen revolutie maar een verlegging van aandachtspunten. Er wordt meer nadruk gelegd op correcte inkapseling. Tegelijkertijd worden de regelmatige diensten ingebouwd in een centraal gelegen dienstverlener die voor alle individuen op identieke wijze toegankelijk is. De voordelen die hiermee bereikt worden zijn een eenduidig communicatieprotocol en een beter aanpasbare dienstverlening.
De componentgebaseerde ontwerp- en bouwmethodiek maakt gebruik van harde inkapseling en centrale diensten. Als er al sprake is van een of meer klassenbibliotheken, dan zijn deze zeer ondiep. Meestal staat elke klasse apart. Elk individu beschikt over een dunne servicelaag, via welke hij het contact met de centrale dienstverlening en met andere componenten onderhoudt. Componentgeoriënteerde systemen zijn vaak door meerdere onafhankelijk van elkaar werkende partijen gebouwd. Meestal kunnen deze systemen nog worden uitgebreid of aangepast met andere componenten. Onder bepaalde voorwaarden kan de uitwisseling of uitbreiding op een werkend systeem toegepast worden.
Een belangrijk verschil tussen objectgeoriënteerde systemen en componentgeoriënteerde systemen is dus dat objectgeoriënteerde systemen over een gedistribueerde gesloten infrastructuur beschikken, terwijl componentgeoriënteerde systemen over een open en centraal gelegen infrastructuur beschikken.
Softwarecomponenten worden veelal in pakketten aangeboden. Deze pakketten bevatten een aantal klassen van softwarecomponenten. De term ‘component’ wordt zowel gebruikt voor de pakketten als voor de klassen en hun leden. Uit de context van de omschrijving moet blijken welke van deze drie bedoeld wordt.
Potentiële relationele complexiteit
De potentiële relationele complexiteit wordt gekenmerkt door het aantal onbekende relaties dat een leek of automaat tegenkomt, wanneer hij voor het eerst met een ontwerp geconfronteerd wordt. De potentiële relationele complexiteit, of beter nog het antoniem relationele duidelijkheid, heeft een directe relatie met de beheersbaarheid van een ontwerp. Inkapseling heeft een zeer heilzame werking op de relationele duidelijkheid. Als we een platte functiebibliotheek (api) vergelijken met een gelaagde api, dan is de potentiële relationele complexiteit van een vierlaags api ongeveer 30 procent lager dan die van een platte api. Vergelijken we dit met een op componenten gebaseerd ontwerp, dan is de potentiële relationele complexiteit daarvan één tot twee ordegroottes lager! Afhankelijk van hoe met inkapseling en overerving omgesprongen wordt, ligt de potentiële relationele complexiteit van een objectgeoriënteerd systeem ergens tussen een platte api en een vergelijkbaar componentgeoriënteerd systeem.
Tweedeling
Architectuur voldoet aan een universeel principe dat ook op andere terreinen zichtbaar is. Het is mogelijk om de architectuur te verdelen in een passief relationeel deel en een actief deel. Deze verdeling is niet strikt complementair, maar tegelijkertijd voldoende significant en helder, dat er een interessant gebruik van gemaakt kan worden. (De website http://sites.netscape.net/hansvanleunen gaat dieper in op de tweedeling van de architectuur en op het begrip potentiële relationele complexiteit.)
Het passieve relationele deel van de architectuur bevat geen informatie die tot het feitelijke intellectuele eigendom van de ontwerpgroep behoort. Deze gegevens zouden toch in beschrijvingen of handboeken verschijnen. Er is dan ook weinig op tegen om deze informatie op publiekelijk toegankelijke plaatsen ter beschikking te stellen. Tegelijkertijd bevat dit deel van de architectuur nog wel voldoende informatie om er testbare skeletten mee te kunnen bouwen. Voor componenten betekent dit, dat men een skelet kan bouwen waarmee is na te gaan of deze component in de passieve relationele architectuur van het geheel past.
Het invullen van het actieve deel van de architectuur is veel uitgebreider en complexer. Dit gedeelte bevat juist wel het intellectuele eigendom van de ontwerpers. Daarom zal men deze informatie effectief willen afschermen. De componententechnologie kan daarvoor effectieve hulpmiddelen leveren.
Dit concept is te benutten door een voor mens en machine leesbare beschrijving van ontwerpelementen op publiekelijk toegankelijke vergaarplaatsen (repositories) ter beschikking te stellen. Een goed medium hiervoor is Internet of een intranet. Als men nu de beschikking heeft over een ontwerp- en bouwhulpmiddel dat dergelijke informatie uit een of meer repositories kan filteren en er vervolgens automatisch skeletten van kan maken, dan kan men de ontwerptijd aanmerkelijk versnellen. Op deze wijze kan ook een open markt voor componenten ontstaan. Immers, als het hulpmiddel concludeert dat het skelet van de geselecteerde component past, dan kan men besluiten om de volledige component – bijvoorbeeld via e-handel – aan te schaffen.
XML
Een ideaal hulpmiddel hiervoor is XML. Sinds 1998 bestaat er een standaard voor deze uitbreidbare opmaaktaal. In XML-bestanden wordt de over te brengen inhoud op hiërarchisch gestructureerde wijze opgeslagen. In bijbehorende DTD-bestanden (Document Type Definition) of schema-bestanden wordt de hiërarchische structuur gedefinieerd. In een bijbehorend XSL-bestand kan vervolgens weergegeven worden hoe de in het XML-bestand opgeslagen informatie op een website weergegeven dient te worden. De nieuwste versies van de webbrowsers zijn in staat om dergelijke combinaties zonder verdere hulpmiddelen weer te geven. Inmiddels zijn er hulpmiddelen om de inhoud van XML-bestanden zonder hulp van XSL-bestanden te kunnen bekijken en eventueel te wijzigen. Daarbij wordt het DTD-bestand of het schema-bestand benut om er voor te zorgen dat de structuur van het aangepaste XML-bestand aan de gestelde eisen blijft voldoen. Dit betekent, dat men zonder over het hulpmiddel te beschikken dat het oorspronkelijke XML-bestand gegenereerd heeft, toch in staat is om het bestand te bekijken en eventueel op correcte wijze aan te passen.
De Object Management Group (http://www.omg.org) werkt samen met ISO werkgroep W3C (http://www.W3C.org) om deze technologie geschikt te maken voor het uitwisselen van ontwerpgegevens via algemeen of lokaal toegankelijke repositories. Het trefwoord hierbij is XMI (Extendable Interchange Format). XMI combineert MOF (Meta Object Facility) en UML (Unified Modelling Language) met XML (Extendable Markup Language). Grote maatschappijen zijn al druk bezig deze mogelijkheden te onderzoeken en, voor zover als dat nu al mogelijk is, te implementeren.
Open terrein
Op de desktop zijn de noodzakelijke ondersteunende infrastructuren aanwezig voor zowel op COM gebaseerde softwarecomponenten als voor op Java Beans gebaseerde softwarecomponenten. Deze luxe bestaat niet op alle platforms. Er is met name geen geschikte infrastructuur voor het domein van de in hulpbronnen beperkte en met echte tijd werkende ingebedde toepassingen (‘resource restricted real-time embedded applications’). De leveranciers van besturingssystemen zouden daarin soelaas kunnen bieden. De kans is echter groot dat elk van deze leveranciers met een eigen oplossing komt. Een betere oplossing zou verkregen worden als een onafhankelijke leverancier van ontwerp en programmeerhulpmiddelen erin zou slagen om een geschikt hulpgereedschap te maken. Dit hulpmiddel moet dan niet alleen de gewenste softwarecomponenten helpen ontwerpen en bouwen. Het moet ook een passende en zo zuinig mogelijk toegesneden infrastructuur aanleveren, zodat na compileren en linken een werkend en testbaar prototype ontstaat. De geproduceerde infrastructuur is specifiek voor het onderliggende besturingssysteem. De softwarecomponenten zijn onafhankelijk van het besturingssysteem. De binaire vorm van op COM gebaseerde softwarecomponenten is afhankelijk van de machine taal, welke door de cpu ondersteund wordt.
Het hierboven geïntroduceerde idee om ontwerpelementen via repositories te publiceren maakt het mogelijk om een synoniem van de IC-handboeken voor softwarecomponenten neer te zetten. Men kan zelfs denken aan de ondersteuning van hybride componenten. Een dergelijke hybride component bestaat uit een of meerdere IC’s met een laag software eromheen, die naar zijn omgeving reageert als één enkele component.
J.A.J. van Leunen, senior systeemsoftware-architect, Philips Semiconductors
Figuur 1. Implementatie van modelleringselementen in de software.
Modelleringselement | Realisatie |
Attributen | Velden van gegevensstructuren |
Groepswijde gedragsaspecten | Klassenmethode |
Protocol | Programmeertaal + functieprototypen |
Reactie | Aanroep van routine |
Inkapseling | Abstract datatype |
Coördinatie | Taak beheer en synchronisatie primitieven geleverd door het besturingssysteem |