LEERKERN

4.3 Modelmatige ontwikkelmethoden

Introductie

Het ontwikkelen van kennisgebaseerde systemen is een complexe zaak. Modelmatige ontwikkelmethoden kunnen de kennistechnoloog ondersteunen bij deze taak. Een modelmatige aanpak biedt een aantal duidelijke voordelen. Doordat modellen op abstracte wijze aspecten van de werkelijkheid kunnen beschrijven, kunnen zij worden toegepast om op efficiënte en effectieve wijze informatie te verkrijgen over de werkelijkheid. Modellen stellen ontwikkelaars in staat om de complexiteit van hun taak te reduceren tot werkbare proporties. Zo hoeven zij niet in één keer alle aspecten tegelijkertijd in beschouwing te nemen, maar kunnen ze elk aspect in een afzonderlijk model analyseren, waarbij de diepgang van de invulling van het model kan worden gevarieerd afhankelijk van de fase waarin het project zich bevindt. Daarnaast kan de ontwikkeling van de modellen worden verdeeld over meer ontwikkelaars, waardoor parallel werken mogelijk wordt gemaakt. De onderlinge afstemming van de modellen maakt deel uit van het model zelf en wordt gebruikt om de modellen consistent met elkaar te houden. Na het voltooien van de modellen, is het vervolgens mogelijk om het implementeren ervan parallel uit te voeren. Uit de modellen kunnen subsystemen of modulen worden samengesteld die parallel ontwikkeld kunnen worden. Modellen helpen om de analytische complexiteit te beheersen, doordat elk model slechts één bepaald aspect van de werkelijkheid op abstracte wijze beschrijft. Deze eigenschap van modellen kan ook een belangrijke bijdrage leveren aan een verbetering van de communicatie tussen gebruikers, ontwikkelaars, opdrachtgever en materiedeskundigen.

In deze paragraaf worden twee bekende modelmatige aanpakken geïntroduceerd. Meer over (deze en andere) methodologiëen wordt behandeld in de cursus ‘Projectmanagement en methodologie van kennissysteemontwikkeling’.

4.3.1 CommonKADS

CommonKADS is de methodologie die binnen de kennistechnologie, met name in Nederland, maar ook in de Verenigde Staten, Groot-Brittannië en Japan, wordt toegepast bij de ontwikkeling van (voornamelijk stand alone) kennissystemen. Hierbij wordt een modelgestuurde ontwikkelproces gebruikt. CommonKADS voorziet daarvoor in technieken die de acquisitie en modellering van kennis mogelijk maken. Binnen CommonKADS kan het basisaspect ‘kennis’ expliciet worden gemodelleerd. Ook kent het een organisatiemodel waarmee de sociaal-organisatorische context van het te ontwikkelen systeem kan worden gemodelleerd (basisaspect ‘organisatie’)

De CommonKADS-methodologie biedt een gestructureerde aanpak en is gebaseerd op een aantal basisprincipes.

Kennistechnologie is iets anders dan graven in het hoofd van een expert; het bestaat uit het construeren van verschillende modellen van menselijke kennis.

Aanvankelijk werd kennistechnologie gezien als een proces waarbij kennis moest worden onttrokken uit het hoofd van een expert en moest worden omgezet in computationele vorm. Vandaag de dag wordt kennistechnologie benaderd als een modelleringsactiviteit. Een model is een doelmatige abstractie van de werkelijkheid. Modelleren is dan het construeren van een goede beschrijving (die goed genoeg is voor het beoogde doel) van slechts enkele aspecten van kennis. Dit soort modellen zijn bruikbaar, omdat details van expertkennis noch makkelijk toegankelijk zijn, noch noodzakelijk voor de meeste projecten. Een model maakt het mogelijk te focussen op bepaalde aspecten en andere te negeren. In de CommonKADS-benadering behelst een kennistechnologieproject de constructie van een set aspectmodellen die samen een belangrijke deel vormen van de in het project op te leveren producten. De CommonKADS ‘model suite’ is een handzaam instrument om het kennistechnologieproces op te delen en te structureren.

Het kennisniveauprincipe: concentreer bij kennismodellering eerst op de conceptuele structuur van kennis en bewaar het programmeren voor later.
Veel software-ontwikkelaars hebben de begrijpelijke neiging om het computersysteem te zien als referentiekader tijdens analyse en ontwerpactiviteiten. Echter, nog belangrijker dan het systeem dat gebouwd moet worden, is de menselijke kant: de werkelijke situatie waarop kennistechnologie betrekking heeft, de gebruikers en hun gedrag op de werkplek, ingebed in een breder organisatorisch kader van probleemoplossen. In de Common
KADS-benadering is dat het belangrijkste oogpunt. Het kennisniveau-principe (voor het eerst naar voren gebracht door Alan Newell, 1982) stelt dat kennis moet worden gemodelleerd op een conceptueel niveau, zodanig dat het onafhankelijk is van de manier waarop het wordt geïmplementeerd. Deze concepten die worden gebruikt bij het modelleren van kennis, hebben betrekking op en weerspiegelen het werkelijke domein en worden weergegeven in een vocabulair, dat begrijpelijk is voor de betrokkenen. In de CommonKADS-benadering wordt het ontwerp van kennisgebaseerde systemen ‘structure-preserving design’ genoemd, omdat het de geanalyseerde structuur van de kennis volgt en behoudt.

Kennis heeft een stabiele interne structuur, die is te analyseren door het onderscheiden van specifieke kennistypen en rollen.
Het spreekt voor zich dat kennis, redeneren en probleemoplossen complexe fenomenen zijn. Dat wil echter niet zeggen dat ze chaotisch zijn: kennis lijkt een redelijk stabiele interne structuur te hebben, waarin steeds weer vergelijkbare patronen zijn te herkennen. Hoewel de architectuur van kennis gecompliceerd is, heeft het wel degelijk een begrijpelijke structuur. Dit is een praktisch aanknopingspunt voor een succesvolle kennisanalyse. Conceptueel gezien helpen kennisniveaumodellen om de essentie van menselijk probleemoplossen te begrijpen door ‘knowledge typing’. Een belangrijk resultaat van moderne kennistechnologie is dat menselijke expertise kan worden geanalyseerd in termen van stabiele en generieke kenniscategorieën, -patronen en -structuren. Kennis wordt daarom gemodelleerd als een goed gestructureerd functioneel geheel, waarvan de delen verschillende, beperkte en gespecialiseerde rollen spelen in menselijk probleemoplossen.

Een kennisproject moet worden aangestuurd vanuit ervaringen op een ‘spiraalgecontroleerde’ manier.
De ontwikkeling van een eenvoudig of veelvoorkomend type informatiesysteem vindt meestal plaats volgens een vaststaand managementtraject. Dit wordt met name duidelijk in het watervalmodel (zie paragraaf 4.2.1). Kennis is echter te rijk en te ingewikkeld om te kunnen passen in een dergelijke rigide aanpak. Rapid prototyping is daarom heel populair bij de ontwikkeling van kennisgebaseerde systemen, omdat het leren en maken van aanpassingen gedurende het traject mogelijk maakt. Nadelen van rapid prototyping zijn echter de ad-hoc-benadering, de moeilijke voorspelbaarheid en bestuurbaarheid van het project. Common
KADS hanteert daarom een configureerbare en gebalanceerde projectaanpak, die flexibeler is dan het watervalmodel en meer gecontroleerd dan rapid prototyping. Kennis-projectmanagement volgt een spiraalbenadering die gestructureerd leren mogelijk maakt. Hierbij fungeren tussenresultaten of stadia van de CommonKADS-modellen als wegwijzers voor de volgende te nemen stap.

Figuur 4.3.1 geeft de CommonKADS model suite weer, die een praktische weerspiegeling is van genoemde principes. Het vormt de kern van de CommonKADS kennistechnologie-methodologie.

fi040301.gif (3597 bytes)

Figuur 4.3.1 De CommonKADS model suite

Figuur 4.3.1 bestaat uit drie groepen modellen in drie lagen, omdat er grofweg drie soorten vragen moeten worden beantwoord.

Waarom? (Environment)
Waarom is een kennissysteem een mogelijke hulp of oplossing? Voor welke problemen? Welke voordelen, kosten en organisatorische gevolgen heeft het? Begrip van de organisatorische context en omgeving is hier het belangrijkste punt.

Wat? (Concept)
Wat is de aard en structuur van de betreffende kennis? Wat is de aard en de structuur van de bijbehorende communicatie? De conceptuele omschrijving van de toegepaste kennis in een taak is hier het belangrijkste punt.

Hoe? (Artefact)
Hoe moet de kennis worden geïmplementeerd in het systeem? Hoe zien software-architectuur en computationele mechanismen eruit? De technische aspecten van de computerrealisatie zijn hier het belangrijkste punt.

Al deze vragen worden beantwoord door het ontwikkelen van aspectmodellen. CommonKADS heeft een set voorgedefinieerde modellen, waarbij binnen elk model wordt gefocussed op een deelaspect, maar die te samen een begrijpelijk beeld vormen.

Organisatiemodel
Het organisatiemodel ondersteunt de analyse van belangrijke eigenschappen van een organisatie. Het heeft als doel het ontdekken van problemen en mogelijkheden van kennissystemen, het onderzoeken van de haalbaarheid en het beoordelen van de gevolgen die een kennistechnologietraject zal hebben op de organisatie.

Taakmodel
Taken zijn relevante onderdelen van bedrijfsprocessen. Het taakmodel analyseert zowel de globale taakopzet, de invoer en uitvoer van een taak, precondities en performance-criteria als benodigde bronnen, hulpmiddelen en competenties.

Agentmodel
Agenten zijn uitvoerders van een taak. Een agent kan een mens zijn, een informatiesysteem of welke andere entiteit dan ook, die in staat is om een taak uit te voeren. Het agentmodel beschrijft de eigenschappen van agenten, in het bijzonder hun competenties, de autoriteit die ze hebben om te handelen en de voorwaarden die hieraan verbonden zijn. Verder zet het de communicatieverbindingen tussen agents die een taak uitvoeren, op een rij.

Kennismodel
Het doel van het kennismodel is om de typen en structuren van de kennis die bij het uitvoeren van een taak wordt gebruikt, tot in detail expliciet te maken. Het levert een begrijpelijke implementatie-onafhankelijke beschrijving op van de rollen van verschillende kenniscomponenten die een rol spelen bij het probleemoplossen. Dit maakt het kennismodel tot een belangrijk middel voor de communicatie met experts en gebruikers over de probleemoplosaspecten van het systeem, zowel tijdens de ontwikkeling als tijdens het draaien van het systeem.

Communicatiemodel
Omdat er verschillende agenten betrokken zijn bij een taak, is het belangrijk om de communicatieve transacties tussen betrokken agenten te modelleren. In het communicatiemodel gebeurt dit (net als in het kennismodel) op een conceptueel en implementatie-onafhankelijke manier.

Ontwerpmodel
De genoemde Common
KADS modellen kunnen tezamen worden gezien als de specificatie van eisen voor het kennissysteem, opgebouwd uit verschillende aspecten. Gebaseerd op deze specificatie van eisen geeft het ontwerpmodel een technische systeemspecificatie in termen van architectuur, implementatieplatform, software-modulen, representatiemethoden en computationele mechanismen die nodig zijn om de in het kennismodel en communicatiemodel vastgelegde functies te implementeren.

Het organisatiemodel, het taakmodel en de agentmodellen tesamen analyseren de organisatorische omgeving en bijbehorende succesfactoren voor een kennissysteem. Het kennismodel en het communicatiemodel vormen de conceptuele beschrijving van de probleemoplosfuncties en de gegevens die het kennissysteem gebruikt of moet leveren. Het ontwerpmodel vertaalt dit in een technische specificatie die de basis vormt voor de implementatie van een software-systeem. Dit proces wordt weergegeven in figuur 4.3.1. Merk op, dat niet in alle gevallen alle modellen hoeven te worden geconstrueerd. Dit hangt af van de doelen van het project en de ervaringen die gaandeweg het project zijn opgedaan. Hiertoe moet een keuze worden gemaakt door het projectmanagement. Overeenkomstig, produceert een CommonKADS-project drie typen van producten:
– Common
KADS-modeldocumenten
– projectmanagementinformatie
– kennissysteem-software.
Daarnaast biedt Common
KADS richtlijnen voor het afbeelden van haar modellen op kennistechnologische ontwikkelomgevingen. CommonKADS heeft echter twee nadelen.
– In de Common
KADS-methode wordt veel aandacht besteed aan het basisaspect kennis. Het besteedt daarentegen weinig aandacht aan integratie met conventionele informatiesystemen (basisaspecten distributie en communicatie).
–In Common
KADS wordt een eigen notatiewijze gebruikt, die niet aansluit bij een notatiewijze die in de automatisering veel wordt toegepast.

4.3.2 System development framework

Naar aanleiding van de nadelen van CommonKads heeft Kenniscentrum CIBIT het System development framework (SDF) ontwikkeld. SDF is geen nieuwe methodologie, maar is een raamwerk dat onder meer de Yourdon systems method (YSM) en de CommonKADS-methodologie integreert.

Bij de ontwikkeling van SDF heeft Kenniscentrum CIBIT bewust gekozen voor een integratie tussen YSM en CommonKADS om de volgende redenen.
YSM is bekend en één van de meest toegepaste methodologieën voor de ontwikkeling van niet-kennisintensieve informatiesystemen. Dat maakt YSM een goede ‘conventionele’ methodologie om als uitgangspunt te nemen voor SDF.
YSM wordt ondersteund door een verscheidenheid aan technieken. Een aantal technieken, zoals data flow diagrams (DFD’s), heeft een grote bekendheid en verspreidingsgebied.
– Er zijn case-tools die de technieken van
YSM ondersteunen. Zo is bijvoorbeeld de System Development Workbench (SDW) aangepast om ook SDF te ondersteunen.
– Common
KADS is één van de meest toegepaste methodologieën voor de ontwikkeling van kennissystemen. Het is een praktische methodologie die zeer goede technieken biedt voor het expliciet modelleren van kennis.
– Common
KADS kent een model om de socio-organisatorische omgeving van het systeem te analyseren. Hiermee kan gedurende het gehele project geanticipeerd worden op eventuele faalfactoren vanuit de omgeving.
– Zowel Common
KADS als YSM kennen beide een modelgestuurde aanpak. Daardoor waren beide methodologieën goed te integreren.

Aangezien de kennistechnologie wordt ingezet in aanvulling op de ontwikkeling van conventionele informatiesystemen, is daarbij gekozen om de methodologie YSM een centrale plaats te geven in het SDF-raamwerk. De specifieke methoden en technieken uit CommonKADS die het mogelijk maken om kennis expliciet te modelleren, zijn toegevoegd aan YSM in de notatie die herkenbaar is voor systeemontwikkelaars die de technieken van YSM gebruiken. Als aanvulling op YSM is tevens het organisatiemodel van CommonKADS toegevoegd aan het SDF raamwerk om zo de sociaal-organisatorische omgeving van het kennisintensieve informatiesysteem te kunnen modelleren.

Scheiden essentie van implementatie
De ontwikkeling van een (kennisintensief) informatiesysteem vloeit voort uit een behoefte om een kennisintensief bedrijfsproces te ondersteunen. Welke ondersteuning het systeem moet bieden, het doel van het systeem en het gewenste gedrag, worden uit deze behoefte afgeleid. Allerlei methoden, technieken en tools uit zowel de Informatietechnologie (
IT) als de kennistechnologie (KT) bieden mogelijkheden om bepaalde informatieverwerkende functionaliteit te kunnen realiseren. De essentie van het ontwikkelen van informatiesystemen bestaat met name uit het enerzijds definiëren van de gewenste functionaliteit en anderzijds de keuze van technieken en methoden om deze te kunnen implementeren. Om dit goed te kunnen beheersen, is het nodig om eerst de essentie te beschrijven in een apart model (wat doet het systeem?), om daarna pas in een implementatiemodel te beschrijven hoe het geïmplementeerd gaat worden met behulp van een combinatie van technieken die de IT en KT leveren. In navolging van YSM wordt in SDF een duidelijk onderscheid gemaakt tussen de beschrijving van de essentie van het probleem en een beschrijving van de oplossing voor dit probleem. De essentie van het probleem verwijst naar de (huidige of gewenste) functionaliteit van het systeem, zonder dat daarbij gerefereerd wordt aan de techniek die wordt ingezet om deze functionaliteit te implementeren. Dit resulteert in twee centrale modellen: het essentiële model en het implementatiemodel.

Deze gescheiden benadering levert de volgende voordelen op.
– Er kunnen meerdere implementatiemodellen worden opgesteld voor één essentieel model. Hierdoor kunnen alternatieve oplossingen worden overwogen.
– De verzameling methoden en technieken die de
IT en KT bieden, groeit sterk. Doordat het essentiële model implementatie-onafhankelijk is, kan in een later stadium door het opstellen van een nieuw implementatiemodel worden geëvalueerd of deze nieuwe technieken het essentiële model effectiever of efficiënter kunnen implementeren.

In figuur 4.3.2 wordt het SDF-raamwerk kort weergegeven.

fi040302.gif (9341 bytes)

Figuur 4.3.2 Het SDF-raamwerk

De scheiding tussen de essentie van het probleem en de oplossing hiervoor komt tot uitdrukking in de twee piramiden. De linkerpiramide bevat de (sub)modellen uit het essentiële model. De rechterpiramide geeft het implementatiemodel weer.

Het essentiële model en het implementatiemodel richten zich puur op het (kennisintensieve) informatiesysteem zelf. Het essentiële model bevat weliswaar een omgevingsmodel, maar daarin wordt alleen de interactie beschreven tussen het systeem en zijn directe omgeving (gebruikers en overige systemen). Het omgevingsmodel beschrijft echter niet de plaats in de organisatie waarin het systeem wordt ingezet en welke organisatorische elementen beïnvloed zullen worden door het systeem. Het organisatiemodel kan worden gebruikt om de omgeving van het systeem diepgaand te beschrijven.

De spiraal staat voor het iteratieve ontwikkelproces, waarbij telkens na een gedeelte van de essentiële modellering getoetst wordt wat de gevolgen van deze modellering zijn voor de implementatie daarvan. De spiraal benadrukt tevens het feit dat de inhoud van de modellen los staat van de projectfasering. Meerdere projectmanagementmethoden zijn daarom mogelijk: lineair (waterval), incrementeel, iteratief of risicogestuurde.

Het essentiële model
In het essentiële model wordt de essentie van het probleem beschreven. In het essentiële model staat de vraag ‘Wat doet het systeem?’ centraal. Het essentiële model wordt gevormd door vier modellen, die in tabel 4.3.1 kort worden omschreven.

TABEL 4.3.1 Korte omschrijving modellen in het essentiële model

Model Doel Basisaspect
Omgevingsmodel Afbakening systeem en omgeving. Hiermee wordt vastgelegd:
– Systeemgrens
– Doel en functionaliteit van het systeem
Doelen en eisen
Procesmodel Modellering:
– Kennisintensieve en niet- kennisintensieve functies binnen systeem
– Groepering van functies in (abstracte processen)
– Gegevensstromen tussen functies en processen.
Functies
Domeinmodel Modellering:
– Gegevens gebruikt door het systeem. Beschrijving entiteiten (objecten) binnen het domein en hun onderlinge relaties. Gegevens gerelateerd aan gegevensstromen in procesmodel.
– Kennisrelaties die worden toegepast door de kennisintensieve functies in het procesmodel.
Gegevens en relaties
Kennis
Besturingsmodel Modellering:
– De volgorde waarin de processen en functies in het procesmodel moeten worden uitgevoerd.
Besturing

Het implementatiemodel
Het implementatiemodel is een aan technologiegebonden beschrijving van het informatiesysteem dat is beschreven in het essentiële model. In het implementatiemodel staat de vraag ‘Hoe doet het systeem het?’ centraal. Het implementatiemodel wordt gevormd door vier modellen, die in tabel 4.3.2 kort worden omschreven.

TABEL 4.3.2 Korte omschrijving modellen in implementatiemodel

Model Doel Basisaspect
Processormodel Toekenning van processen en functies in het procesmodel aan één of meer processoren. Processors zijn individuele informatie-verwerkers die zichzelf kunnen besturen (computer-hardware, machines, mensen). Extra functies/processen worden toegevoegd voor onderlinge coördinatie. Distributie
Techniek
Model Human-Computer Interaction (HCI) Voor elke processor in het processormodel die met een mens communiceert, wordt de besturing en inhoud van de gebruikersinteractie vastgelegd. Extra functies/processen voor het realiseren van interactie worden toegevoegd. Communicatie
Software environment-
model
Per processor worden processen en functies toegekend aan software-eenheden. Software-eenheden zijn bijvoorbeeld: kant en klare programmatuur, DBMS (Database Management Systemen)’en, ontwikkelomgevingen, herbruikbare componenten, objecten of frameworks. Distributie
Techniek
Module model Per software-eenheid wordt de modulaire software-architectuur vastgelegd. Functies worden verder uitgewerkt:
– beschrijving algoritme voor niet kennisintensieve functies
– beschrijving redeneermechanisme voor kennisintensieve functies
– richtlijnen voor een directe afbeelding op high-level ontwikkelomgevingen maken deel uit van
SDF.
Methode van datatransformatie

Het organisatie model
In het organisatiemodel van Common
KADS wordt aandacht besteed aan het basisaspect organisatie. Achterliggend is de aanname dat door het modelleren van de organisatorische context van het systeem, de kans op falen van een project wordt verkleind.

De componenten van de organisatie die met behulp van het organisatiemodel worden gemodelleerd, zijn in tabel 4.3.3 gepresenteerd.

TABEL 4.3.3 Beschrijving van de componenten in het organisatiemodel

Component Omschrijving
Organisatorische context Beschrijving van de effecten van de omgeving van de organisatie met betrekking tot de mogelijkheden en/of de verwachte resultaten van de invoering van een kennissysteem.
Knelpunten en kansen Een geprioriteerde lijst van verbeterpunten met betrekking tot de informatie- en kennishuishouding in de organisatie.
Huidige probleem Het verbeterpunt dat de organisatie momenteel wil aanpakken.
Oplossingen Mogelijke alternatieve oplossingen voor het huidige probleem.
Structuur De organisatiestructuur.
Processen De bedrijfsprocessen binnen de organisatie.
Kennis Omschrijving van de kennis die in de bedrijfsprocessen wordt toegepast voor het uitvoeren van kennisintensieve functies.
Rollen en functies De rollen die mensen vervullen in het bedrijfsproces.
Mensen De mensen in de organisatie.
Macht De standpunten en machtspositie die de participanten in het project hebben.
Computermiddelen De IT-infrastructuur van de organisatie.
Andere middelen Gebouwen, geld, werkruimte, enzovoorts.

Naast de beschrijving van de componenten in het organisatiemodel, bevatten ook de onderlinge relaties tussen de componenten veel relevante informatie voor het beantwoorden van voorgaande vragen.

Ontwikkelingen in SDF
Omdat binnen de conventionele systeemontwikkeling steeds meer gebruik wordt gemaakt van nieuwe benaderingen en (bijbehorende) notatiewijzen, zoals objectgeoriënteerde benaderingen en UML, zal het raamwerk in de toekomst ondersteuning bieden aan combinaties van verschillende methodologiën, notatiewijzen en projectmanagementmethoden.

> Opgave 4.3.1