Over software architectuur

 

Er bestaan al talrijke definities van het begrip architectuur en het heeft daarom weinig zin om er nog een aan deze lijst toe te voegen. Het is veel zinvoller om eens te bezien hoe architectuur benut kan worden en wat de consequenties van architectuurkeuzes zijn!

 

Er zijn twee aspecten, die de aandacht verdienen. Het eerste is een principe, dat geldt voor alle zaken, waarbij modelleren een rol speelt. In deze situatie kunnen beschrijvingen van de modellen gesplitst worden in een deelgroep, die alleen het passieve relationele deel behandelt en een deelgroep, die het actieve deel van de modellen behandelt. Deze opsplitsing is niet erg hard, maar in het algemeen is het niet moeilijk om uit te maken in welk van de twee categorieŽn een beschrijving thuishoort.

De beschrijvingen van het passieve relationele deel kunnen zonder problemen gepubliceerd worden. Deze beschrijvingen bevatten toch alleen maar informatie, die uiteindelijk in gebruikshandboeken, referentieboeken of zelfs advertenties terecht zou komen. Tegelijkertijd bevatten de beschrijvingen voldoende informatie om er bruikbare schetsen of zelfs skeletten van het gemodelleerde systeem mee te kunnen construeren.

De beschrijving van het actieve deel bevat juist informatie, die men grotendeels zal willen verbergen. Het bevat de domeinkennis van de ontwerpers, en die wil men graag te gelde maken. Door dit actieve deel op juiste wijze in te kapselen is het mogelijk om deze kennis op effectieve wijze te verbergen.

Als de passieve relationele deelgroep van de beschrijvingen in geschikte vorm op een publiekelijk toegankelijke vergaarplaats (repository) gepubliceerd wordt, zodat de informatie zowel door mensen als door geautomatiseerde hulpmiddelen geÔnterpreteerd kan worden, dan kunnen deze hulpmiddelen automatisch skeletten van de gepubliceerde ontwerpelementen construeren. Met behulp van deze skeletten kunnen prototypen gebouwd worden, waarbij snel aan het licht komt of de betrokken componenten in het gekozen doel passen en of dat doel Łberhaupt haalbaar is. Dit kan de bouw van modulaire systemen belangrijk versnellen en het risico van projecten sterk verminderen.

 

Het tweede aspect betreft de relationele helderheid. Dit concept kan het eenvoudigst uitgelegd worden aan de hand van zijn tegendeel: de potentiŽle relationele complexiteit. De potentiŽle relationele complexiteit wordt gekenmerkt door het aantal relaties, dat een nieuweling tegenkomt, wanneer hij voor het eerste een ontwerp analyseert. Het is ook de complexiteit, waar een reverse engineering tool mee te maken krijgt. Als men een fout bemerkt en niet weet waar de oorzaak gezocht moet worden, dan moet men ook al deze relaties af, totdat de fout ontdekt wordt. Relationele helderheid heeft dus alles te maken met de beheersbaarheid van een ontwerp. Het is mogelijk om aan te tonen dat de relationele helderheid van op modules gebaseerde ontwerpen ťťn tot twee ordegroottes beter ligt, dan de relationele helderheid van vergelijkbare monolithische systemen.

 

Op componenten gebaseerde softwareontwikkeling werkt op dit moment enigszins op desktop computers en in internettoepassingen. Dit komt omdat in deze omgevingen een passende infrastructuur aanwezig is, die het gebruik van softwarecomponenten effectief ondersteunt. Een dergelijke infrastructuur is echter nog lang niet op alle platforms aanwezig. Vooral in het domein van de in middelen beperkte en in echte tijd opererende ingebedde toepassingen beschikken nog niet over een op softwaremodules passende infrastructuur. Het voor elke losse toepassing bouwen van een passende infrastructuur is niet doenlijk. Het is niet alleen kostbaar, het is ook tegenstrijdig met de principes van hergebruik waar de componenten technologie nu juist op mikt.

Wachten totdat een leverancier van operating systems met een bruikbare oplossing komt is ook geen haalbare kaart. Bovendien is de kans groot, dat elke leverancier met een eigen oplossing komt, die niet strookt met de oplossingen, die zijn concurrenten brengen. Een betere oplossing is, dat een of meer leveranciers van ontwerp- en bouwhulpmiddelen met de geÔnteresseerden samenwerkt om een stuk gereedschap te ontwikkelen, dat niet alleen helpt om de softwarecomponenten te ontwerpen en te bouwen, maar dat ook in staat is om een passende werkende infrastructuur toe te voegen, waarin de componenten met elkaar kunnen samenwerken.

Een dergelijk samenwerkingsverband veroorzaakt op deze wijze een open markt, waarin een groot aantal onafhankelijke spelers mee kan doen met het bouwen van zeer gecompliceerde op componenten gebaseerde systemen

Indien de gebruikte componententechnologie gebaseerd is op een onderliggend objectmodel, dat gebruik maakt van een schaalbaar communicatieprotocol, dan wordt het relatief gemakkelijk om de allerkleinste apparaten met de allergrootste systemen te verbinden. Op die wijze ontstaat dan een nieuwe economie, welke gebaseerd is op informatietechnische communicatie en informatietechnische handel.

 

Deze concepten worden met wat meer diepgang behandeld in de nu volgende documenten en presentaties.

 

 

Documenten en presentaties

Html

Architecture overview document
Business perspective
Architecture document
Architecture presentation
COP versus OOP
Dilemma for embedded applications
Demonstrating the feasibility
Separate domain IP from architecture

XML based technology

XML based technology presentation

De softwarebouwers bakken er nog niets van

Overview architecture

Business Perspective

Architecture

Demonstrating the feasibility

XML based technology

XML based technology presentation

De softwarebouwers bakken er nog niets van

 

 

U wordt vriendelijk verzocht om Uw eigen mening te geven

 

U kunt beslissen om een of meer van de bovenstaande documenten op te halen. Indien U deze informatie gebruikt, dan verzoek ik U, om daarbij naar deze web-site te refereren. Enkele van de PowerPoint presentaties bevatten notities. Het kan nuttig zijn om de betreffende presentatie, voordat U hem bekijkt, af te drukken met de optie dat ook de notities afgedrukt worden.