Dit document beschrijft wat een applicatie-architectuur is, wat een -architectuur toevoegt aan de kwaliteit van programmatuur en wat dat betekent voor de productiviteit van applicatie-ontwikkeling. Met andere woorden, het legt uit wat een applicatie-architectuur u kan opleveren.

Bommeljé Crompvoets en partners legt zich sinds haar oprichting in 1996 toe op applicatie-architecturen voor administratieve toepassingen. In dit document leest u hoe wij, als ervaren software engineers, u kunnen helpen met het overstappen naar applicatie-ontwikkeling onder architectuur.

Wij vinden het belangrijk om de bijdrage die onze advisering kan leveren aan de kwaliteit van programmatuurontwikkeling, duidelijk te maken aan niet-technisch betrokkenen. Mocht de inhoud van dit document vragen oproepen of onbeantwoord laten, dan verzoeken wij om kontakt met ons op te nemen.

Waar gaat het eigenlijk om?

Veel automatiseringsbedrijven of -afdelingen vragen aan ons om kennis aan te reiken die nodig is om applicaties onder architectuur te bouwen.

Maar wat betekent applicaties bouwen onder architectuur voor een manager die deadlines moet halen en klanten tevreden moet houden?

Dit verhaal beschrijft wat architectuur is en legt uit wat dat betekent in termen van voordelen, kosten, organisatie van de programmatuur- ontwikkeling, planningen en risiko's.

Wat is architectuur?

Architectuur wordt wel programming-in-the-large genoemd.
Programming-in-the-small gaat over de individuele programma- constructies die je leert op de Delphi-cursus en in het handboek. Programming-in-the-large gaat over de organisatie van programma- constructies in grotere eenheden.

Een architectuur is de wijze waarop programma-constructies in modules zijn ingedeeld en hoe die modules met elkaar interacteren. De architectuur van toepassingsprogramma's heet applicatie-architectuur. Een applicatie-architectuur is specifiek voor:

•     de gebruikte software-technologie;
•     de vereisten van de beoogde applicatie.

Een Clipper-programma voor DOS kent nu eenmaal andere programma- constructies dan dan een Internet-applicatie. En een administratieve multi user toepassing stelt andere eisen dan een besturings- programma voor een robot.

Bommeljé Crompvoets en partners heeft een generieke applicatie- architectuur ontwikkeld. Deze architectuur is voor toepassings- programma's die met Delphi en relationele database technologie (bijv. Interbase) gebouwd worden. De architectuur is geschikt voor administratieve multi user toepassingen (men spreekt ook wel van informatiesystemen).

Waarom is architectuur zo belangrijk?

Architectuur is belangrijk omdat het direct te maken heeft met de kwaliteit van programmatuur.
Wij hebben onze applicatie-architectuur ontworpen om oplossingen te bieden voor de centrale problemen van programmatuur-ontwikkeling:

•     beheersing van het ontwikkelproces;
•     betrouwbaarheid en robuustheid;
•     evolutionair ontwikkelen en onderhouden;
•     hergebruik;
•     efficiëntie en performantie.

Uit onze adviespraktijk weten wij dat veel applicaties kampen met steeds terugkerende problemen op het gebied van kwaliteit. Het toepassen van onze applicatie-architectuur biedt voordelen, wanneer de huidige wijze van applicatie-ontwikkeling te maken heeft (gehad) met één of meer van de volgende problemen:

•     het werd te laat opgeleverd;
•     het was bij oplevering niet voldoende stabiel;
•     testen is alleen mogelijk met de hele applicatie;
•     bug fixes introduceren problemen op andere plaatsen;
•     bug fixes kosten meer tijd en moeite dan verwacht;
•     nieuwe functies kosten meer tijd en moeite dan verwacht;
•     nieuwe functies introduceren een reponsetijdprobleem;
•     nieuwe functies verminderen de stabiliteit van de applicatie;
•     hergebruik van stukken programmatuur blijkt niet mogelijk;
•     responsetijden nemen toe naarmate de database groeit;
•     responsetijden nemen toe naarmate meer gebruikers actief zijn.

Kwaliteit versus productiviteit

De vraag is natuurlijk of het toepassen van een architectuur voor verbetering van kwaliteit wel rendabel is. Wat is het gevolg voor de productiviteit van de programmatuurontwikkeling?

Voor het beantwoorden van die vraag, is het zinvol om de huidige praktijk van programmatuurontwikkeling in ogenschouw te nemen.

 
De kosten van een toepassingsprogramma liggen voor slechts één zesde deel in de initiële ontwikkeling van de programmatuur. Vijf zesde deel van de kosten van een applicatie-programma worden na de eerste oplevering gemaakt: bug fixes, trouble shooting, beheer, onderhoud en uitbreiding. Het gaat daarbij om echte software engineering activiteiten. Help desk en technische ondersteuning komen daar dus nog bovenop.

Een architectuur realiseert in eerste instantie een besparing in het traject na de oplevering van de eerste versie. Daardoor komt software engineering capaciteit vrij voor het ontwikkelen van nieuwe functionaliteiten. In tweede instantie zal een architectuur dus bijdragen aan productiviteitsverbetering van applicatie-ontwikkeling. De heer Fujino, VP van NEC Corporation, zegt hierover: "Where quality is pursued, productivity will follow".

In welke mate het bouwen onder architectuur productiviteitswinst oplevert, is alleen in te schatten, indien de organisatie beschikt over een base line aan metingen van de productiviteit van programmatuurontwikkeling zoals die nu plaatsvindt.

Om een snelle start te maken met applicatie-ontwikkeling onder architectuur, kan gebruik gemaakt worden van de Advanced Delphi Architecture (ADA), een zogenaamd applicatieraamwerk dat Bommeljé Crompvoets en partners heeft gemaakt ter ondersteuning van de applicatie-architectuur. ADA biedt een verzameling technische voorzieningen en programma-sjablonen. Wij gebruiken ADA om al onze applicaties te bouwen en blijven ADA steeds verbeteren.

Het gebruik van ADA kan overigens geen substituut zijn voor kennisoverdracht die wij leveren door middel van advisering of mentoring . Inzicht in de technologie en begrip van de architectuur zijn essentieel voor het juist toepassen ervan. De voordelen van een architectuur blijven afhankelijk van het programming-in-the-small.

Wat een architectuur niet oplevert

Wij willen de architectuur-benadering niet als panacee presenteren en te hoog gespannen verwachtingen wekken. Een architectuur is niet een magisch recept waardoor opeens alles goed gaat.

Een architectuur is geen garantie dat een toepassing ook daadwerkelijk beantwoordt aan de verwachtingen van de gebruikers in termen van functionaliteit. De vertaling van informatie-behoeften van gebruikers naar specificaties voor benodigde functionaliteit in een applicatie, is het domein van de probleem-analyse. Communicatie tussen automatiseerder en materiedeskundige is hierbij de beslissende suksesfaktor.

Een architectuur geeft ook geen recept voor de menselijke aspecten van het managen van programmatuurontwikkeling. Toch kan een architectuur wel helpen. Een architectuur geeft namelijk - op termijn - de mogelijkheid om een ontwikkel-opdracht uit te drukken in hanteerbare eenheden werk. Daardoor zal een opdracht gemakkelijker voldoen aan de SMART criteria: specifiek, meetbaar, acceptabel, realistisch en tijdgebonden. Effectieve communicatie daarover tussen de opdrachtgever en opdrachtnemer (baas en knecht) blijft natuurlijk wel de suksesfaktor en die ligt buiten het bereik van de architectuur.

Hoe werkt een architectuur?

Hoe komt het dat het organiseren van programma-constructies in modules de kwaliteit van software verbetert?

Een architectuur groepeert programma-constructies in modules en bepaalt de manier waarop modules interacteren. Een architectuur doet dat op een nivo dat het hele software-systeem omvat. Het is dus de globale organisatie van programmatuur.

Het streven is daarbij dat modules een hoge mate van interne samenhang hebben, maar weinig onderlinge afhankelijkheden. Men spreekt van high cohesion, low coupling. De bedoeling is dat modules zoveel mogelijk autonoom zijn.

Een module stelt zijn functionaliteit ter beschikking aan "de buitenwereld" door middel van een interface. Interfaces moeten zo klein mogelijk zijn en glashelder gedefinieerd en gedocumenteerd zijn. Men spreekt van narrow and well-defined interfaces.

Het zijn deze grondslagen van een architectuur die voor de volgende belangrijke kwaliteiten van programmatuur zorgen.

Hergebruik en efficiëntie

De mate van autonomie van iedere module bepaalt hoe gemakkelijk deze kan worden hergebruikt. Hergebruik maakt programmatuur efficiënt. Efficiënte programmatuur doet niet meer dan nodig en is daardoor optimaal performant.

Evolutie en onderhoud

De mate van samenhang in een samenstel van modules bepaalt hoe gemakkelijk of moeilijk dat geheel kan worden uitgebreid of gewijzigd. Een goed gedefinieerde architectuur kent weinig afhankelijkheden tussen modules, maakt deze afhankelijkheden zichtbaar en is daardoor evolutionair uit te breiden.

Betrouwbaarheid en robuustheid

Betrouwbaarheid en robuustheid slaat op het vermogen om te gaan met onverwachte of bijzondere situaties. Vaak probeert men deze kwaliteiten te verbeteren door middel van testen.

Door modules separaat te ontwikkelen en te testen, neemt de betrouwbaarheid van programmatuur dramatisch toe.

Een goed gedefiniëerde architectuur heeft zelf een eenvoudige struktuur, waardoor het de complexiteit van de software reduceert. Complexiteit is de grootste vijand van betrouwbaarheid. (Sun Tsu: "See simplicity in the complex.")

Beheersbaarheid van het proces

Met een eenvoudig stelsel van goed gedefinieerde modules, wordt software een telbare grootheid. Een architectuur maakt daardoor het ontwikkelproces planbaar en beheersbaar. (G.J. Caesar: "Verdeel en heers.")

Copyright © 2000 Bommeljé Crompvoets en partners

Het is toegestaan dit artikel in zijn geheel te kopiëren en te verspreiden, mits de tekst woordelijk in tact blijft en deze notitie bevat. Het is toegestaan om deze tekst te citeren, of te wijzigen, mits de oorspronkelijke auteur en houder van het copyright vermeld worden.
You may republish this paper verbatim, including this notation. You may update, correct, or expand the material, provided that you include a notation stating the original author and copyright holder.