Bestaande architecturen moeten bekend worden in het onderwijs

5 november 1998
Het ontwikkelen van kennis over softwarearchitecturen is van groot economisch belang voor de Nederlandse IT-industrie. Maar hoe wordt een informaticus een goede architect? Volgens dr Sjaak Brinkkemper moet er in het onderwijs meer nadruk worden gelegd op cases.
De universiteiten en het bedrijfsleven zouden een coördinerende rol kunnen spelen bij het verzamelen ervan. Dit is de zevende en laatste aflevering van een serie over softwarearchitectuur. Voorgaande artikelen verschenen
25 september, 2, 9, 16, 23 en 30 oktober.
Softwarearchitectuur is een van de motoren van de economie. Dit geldt niet alleen voor klanten, ook voor de IT-leverancier, voor de maatwerkpartner en voor de leverancier van pakketsoftware. De pakketsoftwarebranche genereert vrijwel zelfstandig allerlei vormen van werkgelegenheid en behoeften aan afgeleide diensten. Het succes van verschillende Nederlandse bedrijven is zonder meer te danken aan de architectuur van de producten. Zonder goede architectuur is een softwareproduct niet succesvol te maken.

Sjaak Brinkkemper

Om flexibel en dynamisch te kunnen reageren op veranderingen in hun omgeving dienen organisaties over flexibele, uitbreidbare softwaresystemen te beschikken. Nieuwe producten en diensten moeten snel kunnen worden ondersteund met adequate gegevensverwerkende systemen of procesbesturingen. Naarmate een bedrijf of overheidsinstelling sneller kan reageren met een innovatief geautomatiseerd systeem is de omzet of dienstverlening beter gegarandeerd.
Het verdiepen van de kennis en kunde in softwarearchitectuur is dus essentieel voor de uitbouw van de economische mogelijkheden van de Nederlandse IT-industrie. Hoe kan dit gerealiseerd worden? Wat maakt een informaticus tot een goede architect? Om deze vraag te beantwoorden is het zinvol te onderzoeken wat voor plaats ontwerpen en architectuur in andere vakgebieden innemen.
De ingenieurswetenschappen (bouwkunde, werktuigbouwkunde en elektronica) hebben de meest ontwikkelde praktijk van ontwerpen en een maatschappelijk aanvaarde positie verworven. Geen huis wordt gebouwd zonder architect, geen machine geconstrueerd zonder specificaties, geen printplaat gefabriceerd zonder design. In gammawetenschapppen als onderwijskunde (curriculumtechnologie, instructietechnologie) en bedrijfskunde (organizational design, Business Process Redesign) speelt ontwerpen een centrale rol. Ook in de medische disciplines voor protheseontwikkeling komt het ontwerpaspect sterk naar voren.
Er zijn drie zaken essentieel in de opleiding tot ontwerper of architect:
• theorie: kennis van architectuurprincipes en ontwerpnotaties;
• praktische vaardigheden: training in ontwerpen;
• referentiekader: kennis van cases uit het vakgebied.

Gemeengoed
Het aspect theorie is in vorige afleveringen van deze serie al voldoende belicht. Er zijn een flink aantal principes voor goede softwarearchitecturen gedocumenteerd: client/server, repository, gelaagde architecturen, polymorfie, information hiding, modulaire software
et cetera (zie ’Software Architecture’ van Shaw and Garlan). Notaties voor architecturen zijn er volop: datamodellen (ERD, Niam), procesmodellen (DFD, Isac, Activiteitendiagrammen), softwarestructuren (Structure charts), dynamiekmodellen (Petri-netten, State-Charts, State-transition diagram), formele technieken voor de betrouwbaarheid van componenten (Lotos, Z, VDM).
Een ieder die langer in de IT-industrie rondloopt weet dat formele technieken in de praktijk slechts in zeer speciale gevallen toepasbaar zijn. Voor algemeen gebruik zijn zij te hoog gegrepen voor de gemiddelde informaticus. Daarnaast is het gebrek aan mogelijkheden tot opschaling, dat wil zeggen het toepassen bij grote systemen, een ernstige tekortkoming. Wel dienen de toegepaste technieken formeel gefundeerd te zijn, zodat syntactische en semantische uitspraken te verifiëren zijn.
De keuze van een geschikte set notaties voor een softwarearchitectuur is niet te generaliseren. Afhankelijk van de context van het project of product kan zo’n verzameling technieken worden geselecteerd. We noemen dit een situationele methode ofwel method engineering. Standaardisatie in de desbetreffende branche van de IT-industrie kan randvoorwaarden opleggen aan deze keuze. Zo is het gebruik van entiteit/relatie-diagrammen in de sector van de administratieve software gemeengoed.

Probleem
Training in ontwerpen heeft tot doel de softwarearchitect praktische vaardigheden bij te brengen. Hoe gaat een softwarearchitect te werk? Hier is nauwelijks onderzoek naar gedaan. Enige jaren
geleden onderzochten onderzoekers van het Software Engineering Research
Center (Serc) in het Socrates-project hoe ervaren ontwerpers te werk gingen door ze gedurende drie dagen in een praktijkomgeving te plaatsen en hun gehele werkproces te documenteren op video en transcriptprotocollen. De uit het onderzoek verkregen ontwerpkennis bleek maar ten dele generaliseerbaar in de verbetering van Case-tools.
In een studie naar probleemoplossing bij ontwerpers in de bouwkunde, werktuigbouwkunde en instructietechnologie (Goel en Pirolli van de University of Berkeley) bleken de ontwerpers onder meer de volgende activiteiten uit te voeren:
• uitgebreide probleemstructurering;
• transformatie van doelstellingen in de specificatie van artefacten;
• gebruik van een voor het vakgebied ontwikkelde notatie;
• decompositie van de oplossing;
• persoonlijke en geïnstitutionaliseerde evaluaties en stopcriteria;
• modellering van de performance.
De volgorde van deze activiteiten ligt niet vast en ook worden ze meerdere keren herhaald toegepast. Elke ervaren softwarearchitect zal deze lijst herkennen. Maar hoe word je een ervaren softwarearchitect en hoe kunnen deze vaardigheden in het reguliere opleidingsprogramma voor informatici in het HBO en WO worden opgenomen en geoefend?
Door de beperkingen van de faciliteiten en de afbakening van de verschillende vakken in het curriculum is het niet eenvoudig realistische opdrachten door studenten uit te laten voeren. Telkens weer wordt het bibliotheekvoorbeeld uit de kast gehaald om te leren specificeren. Sommige opleidingen hebben dan ook multidisciplinaire ontwerpopdrachten in het curriculum om de studenten in groepjes in een enigszins realistische context te laten werken aan een IT-probleem. Ook in bedrijfsstages en afstudeeronderzoeken komt een groot aantal studenten in aanraking met een of meer softwarearchitecturen. Gedegen training met realistische problemen blijft echter een probleem.
Het vreemde in ons vakgebied is dat zelfs ervaren softwarearchitecten in hun carrière maar een referentiekader opbouwen van slechts tien tot twintig
systemen. Bovendien laat deze kennis zich heel moeilijk overdragen. In de bouwkunde is de situatie juist omgekeerd: velen zijn bekend met de architectuur van allerlei gebouwen, maar er zijn relatief veel minder ontwerpprincipes bekend.
In de opleiding tot bouwkundig in-
genieur en architect worden allerlei bouwwerken bouwkundig geanalyseerd (Euromast, Evoluon, Kubuswoningen van Blok, Newmetropolis, Arena, ING-hoofdkantoor). Ook nemen de studenten de ontwerpen van bepaalde architecten (Oud, Van Eyk, Rietveld, Dudok) of van stromingen (Bauhaus, Nieuwe Zakelijkheid) uitgebreid door. Studiereizen en bezichtigingen zijn vanzelfsprekende zaken. Deze onderwijsvorm heet in onderwijskundig jargon het werken met cases en is een uitstekend middel om
in beperkte tijd veel praktische kennis
op te doen.

In de keuken
Onderwijs met cases dient ook in de opleiding voor softwarearchitect veel sterker ontwikkeld te worden. Er zijn vele systemen die de interesse wekken van iedere softwarearchitect: het 008-systeem van KPN Telecom, de reisplanner van de NS, de MS Office-applicaties, de transactiesystemen van de Amsterdamse beurs. Ter illustratie zijn drie cases beschreven, om een indruk te geven van de architectuurprincipes die hun oorsprong vinden in verschillende ontwikkelings- of gebruiksfactoren (zie kader). Voor het onderwijs met cases (de casemethode) zijn twee zaken van belang: de casebeschrijving en caseopdracht. Casebeschrijvingen van softwarearchitecturen kunnen onder meer bestaan uit:
• authentieke documentatie van het softwaresysteem (definitiestudie, functioneel ontwerp, technisch ontwerp);
• een beschrijving van de context van de ontwikkeling (ontwikkelings- en doelplatform, ontwerpbeslissingen);
• een beschrijving van de context van het gebruik (gebruikerscategorieën, performance-eisen, kwaliteitseisen);
• interviews met betrokkenen.
Vele typen opdrachten kunnen op grond van dit uitgebreide materiaal aan studenten worden gegeven: het verklaren van allerlei ontwerpbeslissingen, het geven en motiveren van een advies, een oordeel vellen over bepaalde kwaliteitsaspecten zoals flexibiliteit en portabiliteit.
Een wezenlijk probleem bij deze aanpak is het verzamelen van cases in de IT-industrie. Wie gaat cases verzamelen en waarover? Leveranciers van pakketsoftware willen zeker niet te veel in hun keuken laten kijken en de architectuur van hun producten prijsgeven. De meeste commerciële producten kunnen in categorieën worden ingedeeld. Voor iedere categorie bestaat er vaak een standaardarchitectuur waarvan al veel te leren valt (zie case 1 en 2).
Aangezien veel maatwerksystemen bij de overheid met publieke gelden zijn gebouwd, is er in principe de mogelijkheid dat deze architecturen worden vrijgegeven voor onderzoek en onderwijs. Voor de IT-bedrijven die de systemen hebben ontwikkeld, is dit ook attractief aangezien ze een zeker prestige kunnen ontlenen aan de selectie als onderwijscase (zie case 3). Architecturen van maatwerksystemen in de private sector kunnen slechts worden beschreven als het strategisch belang niet speelt. Voorbeelden zijn een personeelsadministratiesysteem, een routeplanner of een toegangscontrolesysteem.
Een coördinerende rol voor het verzamelen en documenteren van cases is weggelegd voor een samenwerkingsverband van universiteiten en bedrijfsleven (Fenit). Een zogenaamd case-clearinghouse kan als centraal depot voor cases en onderwijsmateriaal fungeren, net zoals de Harvard Business School dat voor managementcases is. Als softwarearchitecten in hun opleiding het opstellen van een case als opdracht krijgen, kan het mes aan twee kanten snijden: goed opgeleide architecten en een groeiende verzameling cases. Brandstof genoeg voor de economische motor.

Dr Sjaak Brinkkemper is als Senior Process Engineer bij Baan Company R&D verantwoordelijk voor de procesgebieden Requirements Management en Design. Met dank aan dr Cees Terlouw van de Universiteit van Twente.
Voorbeelden van architectuurprincipes
Uitkeringssysteem
Uitkeringssystemen zijn meestal systemen die worden ontwikkeld en onderhouden in opdracht van de overheid. Voorbeelden zijn het huursubsidiesysteem en de systemen voor sociale uitkeringen. In de jaren tachtig zijn de systemen voor kinderbijslag en de AOW van de Sociale Verzekeringsbank (SVB) grondig vernieuwd. Bij de overheidsystemen is allereerst van belang dat de privacy van de burger is gewaarborgd; een authorisatie-protocol zorgt ervoor dat niet iedereen willekeurig gegevens van een ander kan opvragen.
Daarnaast bevatten deze systemen enorme volumes aan data. Bij de invoering van het kinderbijslagsysteem in 1990 waren de gegevens van twee miljoen huishoudens inclusief kinderen geregistreerd in een database die na compressie nog
10 Gigabyte beslaat. De totale programmatuur omvat meer dan 2500 modules met in totaal 685.000 regels Cobol. Bij dagelijks gebruik voeren zo’n 700 medewerkers van de SVB 500.000 transacties uit (25 per seconde), wat resulteert in 50.000 vaststellingen en betalingen.
Een uitkeringssysteem is applicatietechnisch een rechttoe-rechtaan systeem. Het bevat een registratiemodule voor de invoer en wijzigingen van gegevens van de uitkeringsgerechtigde en een berekeningsmodule voor het berekenen en uitbetalen van de uitkering. De SVB wenst op elk moment inzicht te kunnen verschaffen in de status van de behandeling van elke willekeurige aanvraag.
In het kinderbijslagsysteem is een logistieke component opgenomen, die de naam kreeg ’pijplijn van perspex’, die inzicht geeft in het proces zonder de mogelijkheid tot gegevensmutatie te bieden. Met behulp van deze component, een soort workflowsysteem avant la lettre, kan iedere medewerker vaststellen wat de status is van een bepaalde aanvraag en een schatting maken van de resterende doorlooptijd van de aanvraag.
ERP-systeem
Enterprise resource planningsystemen zijn een nieuw type pakketsoftware dat voortkomt uit de productie-industrie en in de kern is gebaseerd op algoritmen voor productie- en goederenplanning (MRP, Just-in-Time, TQM). Bekende leveranciers van ERP-systemen zijn SAP, Peoplesoft, Oracle en Baan. Significante eigenschappen van deze pakketten zijn dat ze op vele platformen beschikbaar zijn en vele geïntegreerde applicaties bezitten.
Leveranciers van pakketsoftware willen dat hun producten op zoveel mogelijk verschillende platformen beschikbaar zijn ten einde een zo groot mogelijke markt te bedienen. Deze portabiliteitseis kan onderscheiden worden in vijf dimensies:
• hardwareplatform (IBM, Digital, Compac, HP, Siemens);
• besturingssysteem (Windows, Unix, OS/2,);
• gebruikersinterface (Windows, X-Windows, alfanumeriek, Internet-browser);
• DBMS (Oracle, Sybase, Informix, DB2, SQLServer, RBD, Adabas);
• middleware (Corba, Dcom).
Om de applicatieontwikkeling zo efficiënt mogelijk te laten zijn moet de software zoveel mogelijk platformonafhankelijk zijn. Drivers die platformonafhankelijke logica naar platformafhankelijke logica omzetten, realiseren de portabiliteit. Het vereist wel een gedegen keuze voor een ontwikkelingstaal en bijbehorende omgeving, omdat veel van deze omgevingen al de doelplatformen beperken.
Het integratieve karakter van de applicatiesoftware maakt dat verschillende applicaties dezelfde delen van de database willen lezen of bijwerken. Voor elke set applicatiedata geldt een zekere verzameling van integriteitsregels, de data-integriteitsregels. Voorbeelden zijn dat een eenmaal ingevoerde geboortedatum niet meer gewijzigd mag worden of dat een order alleen maar uit het systeem verwijderd mag worden als alle orderregels reeds verwijderd zijn. In principe mag geen enkele applicatie de integriteit van de data schaden, hetgeen impliceert dat deze code bij elke applicatie herhaald of aangeroepen moet worden. ERP-systemen realiseren dit door een aparte Data Access-laag (Dal) te introduceren waarin de data-integriteit wordt geregeld. In deze laag worden deze regels dan gecodeerd, waarna alle andere applicaties toegang hebben tot de data zonder zich te hoeven bekommeren om de integriteit.
Diagram-editor
Een diagram-editor is een grafisch tool voor een bepaalde symbolische notatie. De meeste diagram-editors kunnen een hele verzameling van notaties ondersteunen. Bekende voorbeelden zijn SDW, Visio, ABC Flowcharter, Statemate, Aris en Dem. SDW ondersteunt bijvoorbeeld ERD, DFD, Bubblecharts en Isac.
Diagramtechnieken kenmerken zich door een beperkte set symbolen, die met verbindingssymbolen onderling verbonden kunnen worden en waarvoor allerlei specifieke regels gelden. Als we als voorbeeld een dataflow-diagram (DFD) nemen dan zijn er symbolen voor process, data store en externe agent, die onderling verbonden worden met dataflows (pijlen). De regels zijn bijvoorbeeld dat er geen directe pijl van een data store naar een externe agent mag of dat het voorkomen moet worden dat er meer dan zeven processen in een diagram staan.
Een diagram-editor bevat modules voor de gebruikersinterface en voor de interface (Data Access Module) met de Repository, waarin alle gegevens van de diagrammen worden opgeslagen inclusief de grafische lay-out. De centrale logica om diagrammen te kunnen tekenen is gesplitst in een generiek en een specifiek deel. Het generieke deel zorgt onder meer voor de weergave van symbolen op het scherm, de berekening van alignement en de aansturing van kleur en tekstprimitiva.
Het specifieke deel leest bij elk gebruik de diagramdefinitie in, bestaande uit de verbindings- en samenstellingsregels van de diagramtechniek. Hierdoor worden de regels actief gemaakt en is het alleen maar mogelijk correcte diagrammen van die techniek te tekenen. Deze architectuur voorkomt dus dat er voor elke diagramtechniek een aparte module geschreven moet worden, die allemaal afzonderlijk onderhouden moeten worden bij veranderingen. Moderne diagram-editors gebruiken XML voor de beschrijving van diagram-editors.
 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!