Onderzoek naar toepassing van Agent Technologie binnen Reaal Verzekeringen

Onderzoek naar toepassing van Agent Technologie binnen Reaal Verzekeringen Alex Bongers [email protected] 11 oktober 2004

Software Agents

Voorwoord

Deze afstudeerscriptie vormt de afsluiting van mijn studie Cognitieve Kunstmatige Intelligentie aan de Universiteit Utrecht. Het onderwerp van deze scriptie komt voort uit een opdracht van Reaal Verzekeringen Nederland. Deze opdracht heeft me in staat gesteld praktijkervaring op te doen en tegelijkertijd deze scriptie op te stellen, twee vliegen in ´e´en klap dus. Tijdens mijn plezierige tijd bij de afdeling IT Architectuur van Reaal Verzekeringen heb ik veel steun en opbouwende kritiek gekregen van Henk Lof. Ook mijn begeleider vanuit de universiteit, Frank Dignum, heeft mij van nuttige kritiek voorzien. Ik wil hierbij iedereen bedanken voor de aansporingen tijdens het schrijven van deze scriptie, en dan met name Maartje, die voor mij als officieuze derde begeleider heeft opgetreden. Rest mij nog te zeggen: Bedankt allemaal!

Alex Bongers

Utrecht, oktober 2004

1

Software Agents

Samenvatting

Dit onderzoek stelt zich ten doel om de mogelijkheden van het gebruik van Agent Software Technologie voor Reaal Verzekeringen te onderzoeken aan de hand van een eenvoudige, representatieve casus. Een prototype op basis van deze casus zal worden gemaakt met behulp van Agent Software Technologie en op basis van de hiermee opgedane ervaringen worden conclusies getrokken en aanbevelingen gedaan. Deze aanbevelingen kunnen de basis zijn voor eventuele vervolgstappen die Reaal Verzekeringen kan nemen in de nabije toekomst voor wat betreft gebruikmaking van Agent Software Technologie. De centrale vragen die bij deze doelstelling aan de orde komen, zijn: 1. Wat is Agent Software Technologie? Agent Software Technologie is een nieuwe manier van software-ontwikkeling, gebruik makend van Software Agents. Software Agents worden in dit onderzoek als volgt gedefinieerd: Software Agents zijn autonome, probleemoplossende computationele (op software gebaseerde) entiteiten die in staat zijn om effectief te opereren in dynamische en open systemen. Ze worden vaak gebruikt in systemen waarbinnen ze samenwerken met andere Agents. Agents hebben verschillende kenmerken. Ten eerste zijn Agents autonoom, ze handelen met een zekere mate van zelfstandigheid, gebaseerd op de hen toegewezen verantwoordelijkheid. Ten tweede zijn Agents flexibel, omdat het mogelijk is voor ´e´en Agent om meerdere doelstellingen te hebben en meerdere manieren om deze te bereiken. Agents zijn ook robuust, doordat het mogelijk is voor een Agent (specifieker: de doelstelling(en) van deze Agent) om te falen. Daarnaast zijn Agents zowel pro-actief (reageren uit zichzelf) als reactief (reageren wanneer hierom expliciet gevraagd wordt). Tenslotte zijn Agents sociaal, omdat ze de mogelijkheid hebben om op een hoog niveau met elkaar te communiceren. Hiermee wordt bedoeld dat de communicatie kan verlopen aan de hand van abstracte concepten, zoals ’verzoeken’, ’aanvaarden’, ’informeren’ en dergelijke.

2

Software Agents

2. Welke Methoden, Technieken en Tools kunnen worden toegepast voor de ontwikkeling van een op Agent Technologie gebaseerd prototype? Als methode van procesontwerp is gekozen voor de methodiek van ’DEMO’. Dit vanwege de enerzijds goede aansluiting met de systeemontwerptechniek van ’Prometheus’, anderzijds vanwege de vele in dit onderzoek gevonden overeenkomsten tussen de Actoren binnen DEMO en Software Agents. Als systeemontwerpmethodologie is gekozen voor ’Prometheus’. Deze keuze is gemaakt op basis van de goede aansluiting van de geproduceerde systeemontwerpen van Prometheus met de Agent Software Toolkit ’JACK’, de (Agent Software) Tool die voor dit onderzoek is gekozen. JACK is gekozen vanwege zijn representatieve opzet van een Agent Software Toolkit en zijn veelzijdige en robuuste indruk.

3. Hoe kan een op Agent Technologie gebaseerd prototype met behulp van deze Methoden, Technieken en Tools ontwikkeld worden? In de casus van dit onderzoek wordt een geautomatiseerd verzekeringsaanvraagsysteem beschreven zoals dit operationeel is binnen ProteQ, een dochteronderneming van Reaal Verzekeringen. Het beschrijft de processen die door de klant aan de ene kant en het systeem aan de andere kant worden doorlopen om tot een automatische offerte- en verzekeringsaanvraag te komen via het internet. Er is in DEMO een gedetailleerd interactiemodel gemaakt op basis van het in de casus beschreven proces. Dit DEMO-model is daarna gebruikt als selectiekader in de systeemontwerpmethodologie van Prometheus, om zo de Agents die in het prototype gebruikt worden te defini¨eren. Het uit Prometheus voortgekomen Agent-systeemontwerp is daarna gebruikt om het prototype te implementeren met behulp van de Agent Software Toolkit JACK.

4. Wat zijn de ervaringen met het maken van dit prototype en welke conclusies kunnen hieruit getrokken worden? Voor wat betreft het modelleren van het bedrijfsproces zoals beschreven in de casus van dit onderzoek zijn er geen beperkingen van DEMO naar boven gekomen. DEMO is een goede keuze als modelleringsmethode van een bedrijfsproces, hoewel de nodige ervaring vereist is voor het maken van bruikbare modellen.

3

Software Agents

Ook voor wat betreft het maken van een systeemontwerp in Prometheus aan de hand van de beschrijving in de casus zijn er geen beperkingen ondervonden. Prometheus is over het algemeen een geschikte systeemontwerpmethodologie voor het ontwerpen van Agent-systemen, hoewel de laatste van de drie ontwerpfasen van Prometheus op dit moment nog beperkte meerwaarde biedt ten opzichte van de eerste twee ontwerpfasen. De Agent Software Toolkit JACK tenslotte is ook robuust en veelzijdig gebleken, op het gebruik van grote en complexe datasets na, hiervoor is het zogenaamde onderdeel ’beliefset’ op dit moment nog niet voldoende geschikt gebleken. Een eventuele koppeling met bestaande database-systemen zou hiervoor een oplossing kunnen zijn. Gekeken naar de verschillen in aanpak en mogelijkheden tussen Agent Technologie en de binnen Reaal Verzekeringen gebruikte vorm van objectgeori¨enteerde softwareontwikkeling, genaamd ’Component Based Development’, valt op dat Agent Software Technologie binnen CBD de volgende voordelen kan hebben. Agent Software Technologie biedt een decentrale besturing van een softwaresysteem. Tevens heeft Agent Software Technologie onder andere als meerwaarde de mogelijkheid tot uitgebreide redentatie over de selectie van de meest geschikte aanpak van een te nemen actie op dat moment. Software Agents bieden geen ondersteuning bij het ontwikkelen van zelflerende intelligente systemen.

5. Welke aanbevelingen kunnen gedaan worden op basis van de getrokken conclusies? Reaal Verzekeringen kan een eerste stap zetten richting de acceptatie van Agent Software Technologie door de mogelijkheden tot ontwikkeling van haar procescomponenten met behulp van Agent Software Technologie te onderzoeken. Deze procescomponenten kunnen daarna eventueel gekoppeld worden aan enerzijds legacy-systemen en anderzijds nieuwe technologie¨en zoals Neurale Netwerken. Reeds bestaande mogelijkheden van Software Agents zoals uitgebreide redenatie over selectie van aanpak zou nu al een optie kunnen zijn voor deze eventuele nieuwe varianten van procescomponenten.

4

Inhoudsopgave 1 Inleiding 1.1 Aanleiding . . . . . . . 1.2 Onderzoeksdoelstelling 1.3 Onderzoeksvraag . . . 1.4 Afgeleide hoofdvragen 1.5 Indeling Scriptie . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

8 8 9 9 10 11

2 Software Agents 2.1 Inleiding . . . . . . . . . . 2.2 Wat zijn Software Agents? 2.3 BDI en Software Agents . 2.4 OO en Software Agents .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

12 12 12 13 14

. . . . . . . . . . . . . . . . .

16 16 16 16 17 17 18 18 19 20 20 21 21 22 23 27 27 28

. . . . .

3 Methoden, Technieken en Tools 3.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . 3.2 Selectie van de Methoden, Technieken en Tools 3.2.1 Waarom DEMO? . . . . . . . . . . . . . 3.2.2 Waarom Prometheus? . . . . . . . . . . 3.2.3 Waarom JACK? . . . . . . . . . . . . . 3.3 Wat is DEMO? . . . . . . . . . . . . . . . . . . 3.3.1 Hoe werkt DEMO? . . . . . . . . . . . . 3.3.2 De Kernpunten van DEMO . . . . . . . 3.3.3 BDI en DEMO . . . . . . . . . . . . . . 3.3.4 Actoren en Software Agents . . . . . . . 3.4 Wat is Prometheus? . . . . . . . . . . . . . . . 3.4.1 Hoe werkt Prometheus? . . . . . . . . . 3.5 Wat is JACK? . . . . . . . . . . . . . . . . . . 3.5.1 Hoe werkt JACK? . . . . . . . . . . . . 3.6 Aansluitingen . . . . . . . . . . . . . . . . . . . 3.6.1 Aansluiting DEMO en Prometheus . . . 3.6.2 Aansluiting Prometheus en JACK . . .

5

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

INHOUDSOPGAVE

Software Agents

4 Experiment 4.1 Inleiding . . . . . . . . . . . . . . . . . . . 4.2 Casus . . . . . . . . . . . . . . . . . . . . 4.3 Ontwerpbeslissingen . . . . . . . . . . . . 4.4 Beschrijving . . . . . . . . . . . . . . . . . 4.4.1 Beschrijving van het DEMO-model 4.4.2 Beschrijving van Prometheus . . . 4.4.3 Beschrijving van het prototype . . 4.5 Ervaringen . . . . . . . . . . . . . . . . . 4.5.1 Ervaringen met DEMO . . . . . . 4.5.2 Ervaringen met Prometheus . . . . 4.5.3 Ervaringen met JACK . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

5 Conclusie 5.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Conclusies . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Conclusie DEMO . . . . . . . . . . . . . . . 5.2.2 Conclusie Prometheus . . . . . . . . . . . . 5.2.3 Conclusie JACK . . . . . . . . . . . . . . . 5.3 Het aspect Intelligentie . . . . . . . . . . . . . . . . 5.4 Antwoorden op de hoofdvragen . . . . . . . . . . . 5.5 Toepasbaarheid van Agent Technologie voor Reaal ringen . . . . . . . . . . . . . . . . . . . . . . . . . 6 Aanbevelingen 6.1 Inleiding . . . . . . . . . . . . . . . . . . . . . . 6.2 Aanbevelingen . . . . . . . . . . . . . . . . . . 6.2.1 Aanbevelingen voor wat betreft gebruik thode, Techniek en Tool . . . . . . . . . 6.2.2 Aanbevelingen voor Reaal Verzekeringen

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Verzeke. . . . . .

. . . . . . . . . . . . . . . . van de Me. . . . . . . . . . . . . . . .

A

29 29 29 30 31 31 32 41 44 44 44 45 48 48 48 48 49 49 51 53 54 55 55 55 55 56

A.1 De casus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . A.1.1 De processen . . . . . . . . . . . . . . . . . . . . . . .

59 59 59

B.1 De Systeem Specificatie Fase . . . . . . . . B.1.1 Specificatie van de systeemdoelen . . B.1.2 Hergroeperen van de systeemdoelen B.1.3 Functionaliteiten . . . . . . . . . . . B.1.4 Scenario’s . . . . . . . . . . . . . . . B.1.5 Alternatieve scenario’s . . . . . . . . B.1.6 Gebruikte percepts en actions . . . . B.1.7 Interne data bronnen . . . . . . . . .

62 62 62 65 67 70 72 72 72

B

6

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

INHOUDSOPGAVE

Software Agents

B.1.8 Externe data bronnen . . . . . . . . . . . . . . . . . . C

72

. . . . .

73 73 73 74 79 81

D.1 De JDE met het prototype . . . . . . . . . . . . . . . . . . . D.2 Een JACK programmacode-voorbeeld . . . . . . . . . . . . .

82 82 88

E.1 Het prototype in werking . . . . . . . . . . . . . . . . . . . .

89 89

C.1 De Architectuur Ontwerp Fase C.1.1 Datakoppeling diagram C.1.2 Agent beschrijvingen . . C.1.3 Samengesteld scenario . C.1.4 Interactie diagram . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

D

E

7

Hoofdstuk 1

Inleiding 1.1

Aanleiding

Software ontwikkeling is een zeer dynamisch vakgebied. Naarmate de ontwikkelingen in de informatietechniek toenemen komen er ook nieuwe ontwikkelingen op het gebied van software ontwikkeling. Bedrijven maken tegenwoordig veelvuldig gebruik van informatietechnologie, waar het ontwikkelen van zeer specialistische software bij komt kijken. Om de voortgang binnen een bedrijfstak bij te houden en tegelijkertijd concurrerend te blijven werken is het daarom noodzakelijk om onderzoek te doen naar nieuwe gebieden van software ontwikkeling. Daarom is er binnen Reaal Verzekeringen, een grote verzekeraar in Nederland, door haar afdeling IT Architectuur in het najaar van 2003 begonnen met een vooronderzoek (een zogenaamde ’verkenning’). Hierbij is gekeken naar nieuwe methoden en ontwikkelingen op het gebied van software en softwareontwikkeling [13]. De afdeling IT Architectuur is een onderdeel van Reaal Verzekeringen en heeft als taak de informatie- en applicatie-architectuur binnen Reaal in goede banen te leiden en te ontwikkelen, alsmede ook op de hoogte te blijven van de nieuwe ontwikkelingen die zich op het gebied van de ICT afspelen en deze te beoordelen op relevantie voor Reaal Verzekeringen. In dit vooronderzoek is met name gekeken naar het mogelijke potentieel van Agent Software Technologie. Er wordt geconcludeerd dat Agent Software Technologie een nieuwe stap is in de ontwikkeling van het vakgebied software engineering, dat de technologie zich al in een vergevorderd stadium bevindt (met name wat betreft Multi-Agent Systemen1 ) en dat de markt van aanbieders zich in de komende jaren op weg naar volwassenheid zal moeten begeven [13]. Agent Software Technologie [15] is gebaseerd op een nieuwe manier van software-ontwikkeling, gebruik makend van Software Agents2 . In de verkenning wordt aanbevolen om voorlopig geen investeringen in 1 2

Multi-Agent Systemen zijn systemen die gebruik maken van meerdere Software Agents voor een verdere uitleg van Software Agents, zie hoofdstuk 2

8

1.2 Onderzoeksdoelstelling

Software Agents

Agent Technologie te doen en de ontwikkelingen op dit gebied te volgen. Ook wordt aanbevolen om in 2004 of 2005 een experiment op beperkte schaal uit te voeren, om daarmee meer vertrouwd te raken met de concepten van Agent Technologie. Het management van IT Architectuur heeft besloten om deze aanbevelingen op te volgen. Dat heeft geleid tot dit onderzoek, dat zich ten doel stelt om de mogelijkheden van het gebruik van Agent Technologie voor Reaal Verzekeringen te onderzoeken door het maken van een prototype aan de hand van een eenvoudige, representatieve casus. Het prototype3 zal worden gemaakt met behulp van Agent Software Technologie en op basis van de hiermee opgedane ervaringen worden conclusies getrokken en aanbevelingen gedaan voor de eventuele vervolgstappen in de nabije toekomst. Binnen de vakgroep Intelligent Systems van de Faculteit der Informatica verbonden aan de Universiteit Utrecht wordt er al lange tijd onderzoek gedaan naar de mogelijkheden die Agent Software Technologie kan bieden. Deze vakgroep is dan ook bereid gevonden door IT Architectuur om haar assistentie te verlenen aan dit onderzoek binnen Reaal Verzekeringen. Om duidelijkheid te krijgen omtrent het doel van dit onderzoek is het noodzakelijk dat er helder voor ogen staat wat de doelstelling van het onderzoek is, welke centrale vraag gesteld kan worden en hoe deze centrale vraag uiteindelijk kan worden beantwoord.

1.2

Onderzoeksdoelstelling

Dit onderzoek stelt zich ten doel om de mogelijkheden van het gebruik van Agent Technologie voor Reaal Verzekeringen te onderzoeken aan de hand van een eenvoudige, representatieve casus. Een prototype op basis van deze casus zal worden gemaakt met behulp van Agent Software Technologie en op basis van de hiermee opgedane ervaringen worden conclusies getrokken en aanbevelingen gemaakt voor de eventuele vervolgstappen in de nabije toekomst.

1.3

Onderzoeksvraag

Naar aanleiding van de onderzoeksdoelstelling kan de centrale vraag als volgt geformuleerd worden: ”Hoe kan een prototype op basis van Agent Software Technologie ontwikkeld worden en in hoeverre is dit toepasbaar op de software ontwikkeling binnen Reaal Verzekeringen?” 3

een implementatie van software in een Agent Software Tookit

9

1.4 Afgeleide hoofdvragen

1.4

Software Agents

Afgeleide hoofdvragen

Uit de centrale vraag kunnen de volgende hoofd- en deelvragen geformuleerd worden: 1. Wat is Agent Software Technologie? • Wat zijn Software Agents? 2. Welke Methoden, Technieken en Tools kunnen worden toegepast voor de ontwikkeling van een op Agent Technologie gebaseerd prototype? • Welke Methode is geschikt om het bedrijfsproces schematisch weer te geven? • Hoe werkt deze Methode? • Welke Methodologie4 is geschikt om het (Agent) systeem te ontwerpen? • Hoe werkt deze Methodologie? • Welke (Agent) Software Tool is geschikt om het prototype in te implementeren? • Hoe werkt deze Tool? 3. Hoe kan een op Agent Technologie gebaseerd prototype met behulp van deze Methoden, Technieken en Tools ontwikkeld worden? • Hoe kan het bedrijfsproces aan de hand van de Methode weergegeven worden? • Hoe kan het Agentsysteem aan de hand van de Methodologie ontworpen worden? • Hoe kan het prototype in de Agent Software Tool ge¨ımplementeerd worden? 4. Wat zijn de ervaringen met het maken van dit prototype? 5. Welke conclusies kunnen uit de ervaringen afgeleid worden? 6. Welke aanbevelingen kunnen gedaan worden op basis van de conclusies? 4

ook wel: ontwerptechniek

10

1.5 Indeling Scriptie

1.5

Software Agents

Indeling Scriptie

Nu de aanleiding en doelstelling van dit onderzoek bekend zijn, zal vervolgens aan de hand van de hoofd- en deelvragen worden geprobeerd de centrale vraag te beantwoorden. De opbouw van deze scriptie volgt de verschillende hoofd- en deelvragen zoals geformuleerd in 1.4. Ten eerste zal het volgende hoofdstuk een antwoord geven op de vraag wat Agent Software Technologie is. Dit zal gebeuren aan de hand van een uitleg van wat Software Agents zijn, wat de concepten zijn waarop ze zijn gebaseerd en hoe ze zich verhouden ten opzichte van object-geori¨enteerde software, de meest gangbare methode van software ontwikkeling op dit moment. Vervolgens wordt de keuze van de te gebruiken methode, methodologie en tool verantwoord en wordt hun onderlinge samenhang verklaard. Hierna volgt een beschrijving van de werking van de gebruikte methode, methodologie en tool. Deze onderdelen, tezamen met de casus, worden gebruikt in de ontwikkeling van het prototype. Dit hoofdstuk 3 geeft zo een antwoord op de hoofdvraag welke Methoden, Technieken en Tools kunnen worden toegepast voor de ontwikkeling van een op Agent Technologie gebaseerd prototype. Vervolgens is er een beschrijving van het gebruik van de gekozen methode, methodologie en tool tijdens de ontwikkeling van het prototype, gevolgd door de werking hiervan. Hierna volgen de opgedane ervaringen tijdens de ontwikkeling van het prototype. Dit hoofdstuk, hoofdstuk 4, beantwoordt de vraag hoe een op Agent Technologie gebaseerd prototype met behulp van deze Methoden, Technieken en Tools ontwikkeld kan worden, alsook de vraag wat de ervaringen met het maken van een prototype zijn. In hoofdstuk 5 worden uit deze ervaringen conclusies getrokken. Dit als antwoord op de vierde hoofdvraag. Hoofdstuk 6 tenslotte sluit deze scriptie af met aanbevelingen voor Reaal Verzekeringen voor wat betreft de nabije toekomst op het gebied van software-ontwikkeling.

11

Hoofdstuk 2

Software Agents Om duidelijkheid te krijgen voor wat betreft de betekenis en inhoud van Agent Technologie is het belangrijk dat er eerst duidelijkheid is wat betreft de definitie en werking van Software Agents, de eigenlijke bouwstenen en hoofdconcepten van Agent Technologie. Software Agents zijn derhalve het onderwerp van dit hoofdstuk.

2.1

Inleiding

Sinds de opkomst van internet is de manier van omgaan met informatie en de manier om deze informatie vast te leggen en te raadplegen veranderd. Onder andere is er een behoefte ontstaan naar nieuwe manieren van softwareontwikkeling om met deze nieuwe dynamische en open systemen om te kunnen gaan. Op dit moment is de veruit meest gebruikte methode voor softwareontwikkeling de object geori¨enteerde ontwikkelmethode. Dit is een bepaalde manier om het ontwerp, de constructie en de implementatie van software aan te pakken. Software wordt hierbij opgebouwd en samengevoegd uit componenten (objecten genoemd) afkomstig uit verschillende bronnen; de componenten op zich kunnen zijn ontwikkeld in verschillende programmeertalen. Uit onderzoek in gedistribueerde kunstmatige intelligentie1 [14] is eind jaren tachtig onderzoek begonnen naar zogenaamde ’Software Agents’.

2.2

Wat zijn Software Agents?

Software Agents worden in dit onderzoek als volgt gedefinieerd: Software Agents zijn autonome, probleemoplossende computationele2 entiteiten die in staat zijn om effectief te opereren in dynamische en open systemen. Ze 1

dit zijn systemen opgebouwd uit een gedecentraliseerde groep Agents die samen de oplossing van een probleem nastreven 2 op software gebaseerd

12

2.3 BDI en Software Agents

Software Agents

worden vaak gebruikt in systemen waarbinnen ze samenwerken met andere Agents, die op hun beurt weer andere doelstellingen kunnen hebben. In deze tekst zal vaak worden verwezen naar de begrippen ’Agents’ en ’Software Agents’, in dit onderzoek wordt met deze begrippen ´e´en en dezelfde entiteit aangeduid. Agents hebben verschillende kenmerken die ervoor zorgen dat ze erg geschikt zijn om in te zetten in deze nieuwe manier van software ontwikkeling [21]. Ten eerste zijn Agents autonoom, ze handelen met een zekere mate van zelfstandigheid, gebaseerd op de hen toegewezen verantwoordelijkheid. Ten tweede zijn Agents flexibel, omdat het mogelijk is voor ´e´en Agent om meerdere doelstellingen te hebben en meerdere manieren om deze te bereiken. Agents zijn ook robuust, doordat het mogelijk is voor een Agent (specifieker: de doelstelling(en) van deze Agent) om te falen. Daarnaast zijn Agents zowel pro-actief (reageren uit zichzelf) als reactief (reageren wanneer hierom expliciet gevraagd wordt). Tenslotte zijn Agents sociaal, omdat ze de mogelijkheid hebben om op een hoog niveau met elkaar te communiceren. Hiermee wordt bedoeld dat de communicatie kan verlopen aan de hand van abstracte concepten, zoals ’verzoeken’, ’aanvaarden’, ’informeren’ en dergelijke [7]. De hierboven genoemde kenmerken zijn precies de kenmerken die benodigd zijn in de computationele systemen van nu en die van de nabije toekomst.

2.3

BDI en Software Agents

Meestal worden Agents (en de daarbij behorende Agent Software Toolkit3 ) gemodelleerd naar cognitieve modellen die behoren bij hoger-niveau cognitieve eigenschappen. Deze cognitieve modellen omvatten concepten als: beliefs, knowledge, desires, intentions, et cetera. Het meest gebruikte model voor Agents is het ’Beliefs, Desires and Intentions’ model (ook wel: BDI) [9]. Het is een model dat als basisconcept gebruik maakt van de BDI theorie van rationale actie, dat oorspronkelijk ontwikkeld is door Michael Bratman [4]. Het is een theorie van praktisch redeneren, die zich in het bijzonder richt op de rol die intenties spelen op praktisch redeneren. Praktisch redeneren is redeneren gericht op acties [19] en bestaat uit tenminste twee verschillende activiteiten: 1. De beslissing welke stand van zaken er bereikt moet worden. 2. De beslissing hoe deze stand van zaken bereikt moet worden.

3

zie 3.5

13

2.4 OO en Software Agents

Software Agents

Dit BDI-model correspondeert op de volgende manier met Agents: • Beliefs komen overeen met de informatie die de Agent heeft over de wereld om hem heen. Deze informatie kan incompleet of incorrect zijn. • Desires representeren de stand van zaken die de Agent graag zou willen zien ontstaan. • Intentions representeren de Desires die de Agent zich heeft voorgenomen (ook wel: waar de Agent zich aan heeft gecommitteerd) om te bewerkstelligen. Er zijn veel verschillende formele4 modellen ontwikkeld die de onderlinge relatie tussen Beliefs, Desires en Intentions analyseren [14]. Daarnaast zijn er ook meer generieke BDI architecturen ontwikkeld, die als een uitbreiding van het oorspronkelijke BDI-model kunnen worden beschouwd, gericht op het doel om op basis hiervan Software Agents te construeren [14]. Iedere implementatie van een Agent Software Toolkit heeft zijn eigen opvattingen over BDI en de vertaling hiervan naar de werking van de toolkit.

2.4

OO en Software Agents

Met OO wordt hier bedoeld: de object-geori¨enteerde manier van software ontwikkelen. Agents zijn autonome entiteiten die interacteren met elkaar en met hun omgeving. Maar zijn het slechts objecten met extra attributen of behoren ze echt tot een totaal andere aanpak van software ontwikkelen? Belangrijk is dat Agents en objecten verschillend genoeg zijn om ze ook verschillend te behandelen [17]. De meeste bedrijven vereisen een balans tussen gestandaardiseerde procedures (een gecentraliseerd proces) en individueel initiatief (een gedecentraliseerd proces); een extreem van beide is fataal voor het bedrijf. Agentgebaseerde omgevingen kunnen ´en gecentraliseerd (de controle van het proces ligt op ´e´en plek) ´en gedecentraliseerd (gedistribueerde controle, de controle over het proces is verspreid over de verschillende Agents) te werk gaan, terwijl object-geori¨enteerde omgevingen voor dit laatste geen directe ondersteuning bieden. Hoewel Agents dus zeker gecentraliseerde systemen kunnen ondersteunen, bieden ze ook de mogelijkheid tot gedistribueerde procesafhandeling en hierdoor ook een ondersteuning voor een juiste balans hiertussen. In object-geori¨enteerde talen worden objecten gecre¨eerd door een klasse5 , eenmaal gecre¨eerd kan dit object niet meer van klasse veranderen. Agents bieden een meer flexibele aanpak. Een specifieke Agent kan tegelijkertijd, of 4 5

gebaseerd op Logica een indeling van objecten naar type

14

2.4 OO en Software Agents

Software Agents

op verschillende momenten, verschillende rollen vervullen (die van werknemer, klant of verkoper bijvoorbeeld). Hoewel een Agent op ´e´en moment de rol van werknemer aanneemt, verandert dit de Agent zelf niet, hij blijft dezelfde entiteit, hij gebruikt op dat moment slechts een verschillende set van kenmerken. Agenten kunnen zo verschillende rollen uitoefenen in verschillende domeinen. Als iemand naar zijn werk gaat, speelt hij de werknemer-rol. Als iemand daarna thuiskomt, verandert de rol in die van echtgenoot bijvoorbeeld. Object-geori¨enteerde talen bieden geen directe ondersteuning voor deze domein-specifieke mechanismen die vereist zijn voor Agent-gebaseerde omgevingen. De enkelvoudige klasse aanpak is effici¨ent en betrouwbaar, de meerdere dynamische klassenaanpak biedt flexibiliteit en modelleert onze perceptie van de wereld op een exactere manier. Agents ondersteunen echter beide aanpakken, de keuze ligt bij de ontwerper. Agent-communicatie kan op een hoger abstractieniveau plaatsvinden dan de communicatie tussen objecten in object-geori¨enteerde talen. Iedere Agent communiceert vanuit zijn eigen rol met een ander Agent. Voor deze communicatie bestaat een afgesproken standaard [7]. Een voordeel van communicatie op een hoger abstractieniveau is dat deze communicatie het gebruik van expliciete taalhandelingen toestaat [7], waardoor termen zoals ’verzoeken’, ’ontvangen’ en dergelijke expliciet kunnen worden gemaakt. Een Agent doet een verzoek aan een andere Agent en kan op de hoogte worden gebracht door de ontvangende Agent dat deze zijn verzoek heeft ontvangen en dat deze zich zal committeren aan de uitvoering van dit verzoek. Dit alles kan gebeuren zonder dat de verzoekende Agent op de hoogte is van de manier waarop dit verzoek door de ontvangende Agent zal worden uitgevoerd. Deze manier van communicatie is hiermee platform- en programmeertaal-onafhankelijk. Bij de ontwikkeling van software systemen kan er gekozen worden uit een mix van beide aanpakken. Sommige software ontwikkelaars hebben er een sterke voorkeur voor om Agents op te bouwen uit objecten en om de infrastructuur voor Agent-gebaseerde systemen boven op een support-systeem6 te bouwen dat ook gebruikt wordt in object-geori¨enteerde systemen. Deze benadering is ook de benadering die de voor dit onderzoek gekozen Agent Software Toolkit ’JACK’ heeft. Een Agent Software Toolkit is een praktisch toepasbare programmeertaal waarmee software geschreven kan worden die gebruik maakt van Software Agents. Software Agents worden dus gebouwd met behulp van een Agent Software Toolkit. Een Agent Software Toolkit leidt tot een praktische toepassing van Agent Technologie. Meer over een Agent Software Toolkit en de andere bouwstenen voor een Agent-gebaseerd systeem in het volgende hoofdstuk.

6

bijvoorbeeld een programmeertaal

15

Hoofdstuk 3

Methoden, Technieken en Tools 3.1

Inleiding

In dit hoofdstuk wordt de selectie van de te gebruiken onderdelen verantwoord en wordt de werking van de gekozen methode, ontwerpmethodologie en tool uitgelegd en beschreven. Deze methode, methodologie en tool zijn de bouwstenen waarop het ontwerp en de implementatie van het prototype is gebaseerd. Afsluitend volgt een verklaring van de onderlinge samenhang tussen de gekozen onderdelen.

3.2

Selectie van de Methoden, Technieken en Tools

Als methode van procesontwerp op basis van de casus1 is gekozen voor de methodiek van ’DEMO’. Na een schematische beschrijving van het bedrijfsproces wordt overgegaan op het systeemontwerp. Als technische methodologie van het systeemontwerp is gekozen voor ’Prometheus’. Na een specificatie van het (Agent) systeem wordt er overgegaan tot implementatie van dit systeemontwerp met behulp van de Agent Software Toolkit ’JACK’.

3.2.1

Waarom DEMO?

Agents weerspiegelen de echte wereld en kennen sociale interactie met elkaar. Het zoeken is naar een methodiek die ook deze sociale interactieprincipes onderkend. DEMO is een methode die aan deze eisen voldoet. Het is mogelijk om met DEMO een schematisch diagram van het proces dat de casus beschrijft op te stellen, zodat er een indeling ontstaat naar Actoren2 . Met 1 2

zie bijlage A zie 3.3

16

3.2 Selectie van de Methoden, Technieken en ToolsSoftware Agents

deze indeling van het proces in Actoren wordt een selectie naar verantwoordelijkheden binnen het proces van de casus bekend. De overtuiging is dat aan de hand van de Actor-definitie van DEMO Software Agents makkelijker kunnen worden ge¨ıdentificeerd. DEMO kan dan later tijdens het systeemontwerp optreden als een selectiekader van Agentfunctionaliteiten, vanwege de reeds benoemde verantwoordelijkheden binnen het proces dat de casus beschrijft. Meer hierover in hoofdstuk 4.

3.2.2

Waarom Prometheus?

Zoals ook bij de Agent Software Toolkits het geval is, zijn er in de loop der tijd ook verschillende soorten Agent Modellering Talen (ook wel: methodologi¨en) ontwikkeld. Enkele van de meest bekende Agent Modellering Talen zijn MESSAGE, TROPOS, MaSE en Prometheus [14]. Veel van de genoemde methodologi¨en verkeren nog in de onderzoeksfase, richten zich op slechts een beperkt deelgebied van Agent Systeem-modellering of zijn nog niet volledig in voldoende detail beschreven. De ontwikkelaars van de methodologie ’Prometheus’ geven duidelijk aan dat ze gedurende het totale ontwerpproces van hun methodologie nauw hebben samengewerkt met de makers van de Agent Software Toolkit JACK en dat het doorlopen van de methodologie Prometheus een goede basis is voor het implementeren van een Software Agent Systeem in JACK. Daarnaast heeft het onlangs verschijnen van het eerste volledig gedetailleerde boek [20] over de methodologie Prometheus, met daarin de benodigde stappen die kunnen worden doorlopen om tot een goed systeemmodel van een Agent Software Programma te komen, bijgedragen tot de keuze voor Prometheus.

3.2.3

Waarom JACK?

Er zijn in de loop der jaren zeer veel verschillende Agent Software Toolkits ontwikkeld en er zijn er nog meer in ontwikkeling. Enkele van de meest bekende Agent Programmeertalen zijn ZEUS, RETSINA, JADE en JACK. Al deze talen hebben hun specifieke voor- en nadelen, en na een overweging tussen deze Agent Toolkits op basis van de praktische toepasbaarheid, inzetbaarheid, technische ondersteuning en de volwassenheid van de ontwikkeltool (waaronder die van de ontwikkelomgeving3 ), is er gekozen voor de Agent Software Toolkit ’JACK’. Deze overweging is gemaakt met raadpleging van de meest recente versie van het boek ’Agent-Based Software Development’ [14]. In dit boek worden veel Agent Software Toolkits beschreven zodat het relatief eenvoudig is om deze op basis van de eigenschappen die hier zijn genoemd en de eigenschappen die in het boek worden verbonden aan iedere Agent Software Toolkit, met elkaar te kunnen vergelijken. De JACK 3

een ontwikkelomgeving is de ondersteunende gebruikersomgeving waarbinnen een programmeur programmacode kan ontwikkelen

17

3.3 Wat is DEMO?

Software Agents

Agent Taal is gebaseerd op een praktische, veelgebruikte programmeertaal en wordt door zijn ontwikkelaars aangeprezen als een commercieel en industrieel product, waarmee een mate van robuustheid gepaard moet gaan. De Agents zoals die in JACK worden gebruikt voldoen daarnaast aan de minimale set van Agent-eigenschappen zoals die in hoofdstuk 2 zijn genoemd; ze zijn autonoom, flexibel, robuust, pro- en reactief en sociaal. Hiermee is JACK representatief voor de familie van Agent Software Toolkits en daardoor een goede keuze als de tool waarin het prototype van dit onderzoek wordt ontwikkeld.

3.3

Wat is DEMO?

DEMO staat voor ’Design & Engineering Methodology for Organizations’. DEMO is oorspronkelijk ontwikkeld binnen de Technische Universiteit te Delft [6] en is gericht op het modelleren van bedrijfsprocessen om zo een kapstok te cre¨eren waarbinnen inrichtingsvraagstukken op een samenhangende manier kunnen worden uitgelegd (bijvoorbeeld informatietechnische inrichtingen). DEMO is een methode om schematisch een bedrijfsproces weer te geven. Deze schematische voorstelling van een bedrijfsproces maakt gebruik van een transactiesymbool tussen twee Actoren. Een Actor is een persoon als volbrenger van een Actor-rol. Een Actor-rol is een stuk authoriteit en verantwoordelijkheid dat aan iemand is toegewezen op basis van zijn competenties. Actoren zijn dus individuele sets van verantwoordelijkheden zoals die te onderkennen zijn binnen ieder bedrijfsproces.

3.3.1

Hoe werkt DEMO?

Actoren voeren twee soorten handelingen uit, te weten productie-acties en co¨ordinatie-acties. Productie-acties Door het verrichten van productie-acties dragen Actoren direct bij aan het realiseren van de functie van een organisatie. Voorbeelden van productieacties zijn het verkopen van goederen en het afsluiten van een verzekering. Er worden drie soorten productie-acties onderscheiden [5]: 1. Essenti¨ele productie-acties 2. Informationele productie-acties 3. Documentele productie-acties

18

3.3 Wat is DEMO?

Software Agents

Essenti¨ele acties beschrijven de kern van de business van een organisatie. Informationele acties betreft het verspreiden van kennis (over essenti¨ele acties) en het afleiden van nieuwe kennis uit bestaande. Documentele acties beschrijven het opslaan, transporteren, kopi¨eren et cetera van de documenten waarin die kennis is vastgelegd. Coo ¨rdinatie-acties Door het verrichten van co¨ordinatie-acties gaan Actoren verplichtingen over productie-acties aan en komen ze die na. Voorbeelden van co¨ordinatie-acties zijn het verzoeken en het beloven (van productie-acties). Productie-acties en co¨ordinatie-acties zijn de ’atomen’ van de bedrijfsprocessen in een organisatie. Ze komen altijd en all´e´en maar voor in universele patronen, transacties geheten. Transacties zijn de ’moleculen’ van bedrijfsprocessen. Bij het volbrengen van een transactie zijn twee actoren betrokken, de ene is de Initiator (bijvoorbeeld de klant) en de ander de Executor (bijvoorbeeld de leverancier). Een bedrijfsproces is dus een structuur van transacties.

3.3.2

De Kernpunten van DEMO

Zoals hierboven al genoemd maakt DEMO schematisch gebruik van een transactiesymbool tussen twee Actoren. Dit transactiesymbool beeldt een set van communicatie-acties tussen twee Actoren uit. Een transactie vindt plaats tussen twee entiteiten, een Initiator en een Executor. Elke transactie die plaatsvindt tussen Actoren in DEMO kan opgedeeld worden in vier communicatieonderdelen, te weten: 1. Verzoeken 2. Beloven 3. Verklaren 4. Aanvaarden Zie figuur 3.1 voor het in DEMO gebruikte transactiesymbool en de opdeling daarvan in de vier communicatieonderdelen. In de verzoek -stap verzoekt de Initiator de Executor tot het uitvoeren van een taak. De Executor beoordeelt dit verzoek en als hij dit verzoek besluit aan te nemen, belooft de Executor de Initiator dat hij de taak gaat uitvoeren. Als de Executor de taak heeft uitgevoerd verklaart deze de oplevering hiervan aan de Initiator, waarna de Initiator het resultaat beoordeelt en na een positieve beoordeling zal aanvaarden.

19

3.3 Wat is DEMO?

Software Agents

Figuur 3.1: Het DEMO transactiesymbool

3.3.3

BDI en DEMO

Het eerder in Hoofdstuk 2 genoemde Belief, Desires en Intentions model is ook aanwezig in de werking van DEMO. Als een Initiator of Executor een communicatieve actie uitvoert op een van de vier communicatieonderdelen zoals in 3.3.2 genoemd, gaat daar eigenlijk altijd een impliciet intentiefeit aan vooraf. Namelijk: de Initiator of de Executor heeft voordat hij communiceert de intentie om dit te gaan doen. Ditzelfde geldt voor productie-acties; een Initiator of Executor heeft bij belofte van uitvoer hiervan altijd de intentie om deze te gaan uitvoeren. Dit zijn de Intentions binnen DEMO. Een co¨ordinatiefeit is een feit binnen de ’intersubjectwereld-toestand’. Met de intersubjectwereld wordt binnen DEMO bedoeld: de communicatieve actie die tussen Actoren plaats vindt. Een productiefeit is een feit binnen de ’objectwereld-toestand’. Met de objectwereld wordt binnen DEMO bedoeld: de wereld waartoe de feiten die het resultaat zijn van transacties behoren. Samen geven deze twee toestanden op een willekeurig moment de Beliefs weer die een Actor op dat moment heeft. Dit zijn de Beliefs binnen DEMO. Zoals eerder al genoemd vervult een Actor een rol. In de uitvoering van zijn rol wordt de Actor geleid en gedreven door zijn authoriteit en zijn verantwoordelijkheid. De drijfveer die de Actor tot zijn acties aanzet is de Desire van een Actor. De authoriteit en verantwoordelijkheid die een Actor heeft gekregen voedt zijn Desires. Dit zijn de Desires binnen DEMO.

3.3.4

Actoren en Software Agents

Actoren en Software Agents hebben veel overeenkomsten met elkaar. Ten eerste zijn Software Agents autonoom (en kennen daarom ieder hun eigen verantwoordelijkheden), hebben ze sociale interactie met elkaar en weerspiegelen ze de echte wereld4 . De Actoren binnen DEMO zijn tevens individuele sets van verantwoordelijkheden die communicatieve acties met elkaar aan 4

de wereld zoals wij, mensen, die om ons heen ervaren

20

3.4 Wat is Prometheus?

Software Agents

kunnen gaan. Te tweede komt de rol die een Actor vervult voort uit zijn toebedeelde verantwoordelijkheid. De in 2.4 genoemde rollen van Software Agents komen overeen met deze rolvervulling van Actoren binnen DEMO. Als laatste overeenkomst tussen Actoren en Software Agents is hierboven in 3.3.3 aangegeven dat het concept van BDI zowel in DEMO aanwezig is, alsook in de werking van Software Agents. Uit deze drie genoemde overeenkomsten blijkt dat Software Agents veel gemeen hebben met de Actoren zoals die binnen DEMO gebruikt worden.

3.4

Wat is Prometheus?

Prometheus is een iteratieve methodologie die het gehele Agent software ontwikkelingsproces omvat en die gericht is op het ontwikkelen van Software Agents, resulterend in een specificatie die kan worden ge¨ımplementeerd in JACK Agent Software5 .

3.4.1

Hoe werkt Prometheus?

Schematisch weergegeven ziet de opbouw volgens de Prometheus-methodologie om tot een Agent Software Systeem te komen er zo uit:

Figuur 3.2: De Prometheus-methodologie 5

zie 3.5

21

3.5 Wat is JACK?

Software Agents

Zoals te zien is in figuur 3.2 onderkent Prometheus drie ontwerpfasen: 1. De Systeem Specificatie Fase 2. De Architectuur Ontwikkel Fase 3. De Gedetailleerde Ontwikkel Fase Hieronder volgt een beschrijving van de inhoud van elk van deze drie fasen: De Systeem Specificatie Fase De Systeem Specificatie Fase richt zich op het identificeren van de doelen van het systeem, samen met de manier waarop deze moeten worden afgehandeld. Hieruit volgen de functionaliteiten die binnen het systeem aanwezig moeten zijn om het proces in goede banen te leiden. Om beter het doel van het systeem te begrijpen wordt daarna gebruik gemaakt van scenario’s. Een scenario is een mogelijke volgorde van een samenhangend geheel van functionaliteiten weergegeven als een unieke set van interacties tussen de gebruiker en het systeem. De Architectuur Ontwikkel Fase In de Architectuur Ontwikkel Fase wordt bepaald welke Agents het systeem zal bevatten en hoe deze Agents zullen interacteren. Enkele bepalende ontwerp onderdelen die in deze fase gebruikt worden zijn: Het Datakoppeling diagram (dat de functionaliteiten aan datasets relateert), Agent beschrijvingen (de schematische uitwerkingen van de werking van de Agents) en het Interactie Diagram, dat de interactie tussen de Agents schematisch uitbeeldt en specificeert, gebaseerd op Agent UML Sequence Diagrams [3], [16]. De Gedetailleerde Ontwikkel Fase In de Gedetailleerde Ontwikkel Fase wordt de interne werking van iedere Agent beschreven, alsook de manier waarop het zijn taken in het totale systeem zal kunnen bereiken. De nadruk ligt op het defini¨eren van interne Events, Plannen en gedetailleerde data structuren. Hieruit worden Agent Overzicht Diagrammen gemaakt (de mogelijkheden van deze Agent), Plan beschrijvingen (de uitgeschreven werking van een plan) en Data beschrijvingen (een gedetailleerde beschrijving van de datasets).

3.5

Wat is JACK?

De Agent Software Toolkit JACK is een zogenaamde Multi-Agent Software Toolkit (ook wel: Multi-Agent Systeem). Dit houdt in dat er met deze Agent Software Tookit een Agent-gebaseerd softwaresysteem kan worden 22

3.5 Wat is JACK?

Software Agents

ontwikkeld, waarbinnen meerdere Software Agents samen het softwaresysteem uitmaken. De JACK Agent Toolkit bestaat uit een uitgebreide set van tools, klassen en bibliotheken die allen gebaseerd zijn op en ontwikkeld zijn in de programmeertaal JAVA. JAVA is een object-geori¨enteerde programmeertaal ontwikkeld door Sun Microsystems [18] en is momenteel de meest gebruikte object-geori¨enteerde programmeertaal ter wereld. De JACK Development Environment (ook wel: JDE), de ontwikkelomgeving van JACK, kan worden onderscheiden in vier verschillende componenten: 1. De JACK Agent Taal is een superset6 van JAVA en introduceert nieuwe semantische en syntactische eigenschappen, nieuwe klassen, interfaces en methoden om zo om te kunnen gaan met Agent-gebaseerde concepten. 2. De JACK Compiler compileert de JACK Agent Taal naar pure JAVA programma-code, zodat deze compatibel is en blijft met alle andere JAVA-code ter wereld. 3. De JACK Agent Kernel zet de run-time omgeving op waarbinnen de JACK Agents werken, biedt netwerkondersteuning en biedt de onderliggende Agent-functionaliteit die is gedefinieerd binnen de JACK Agent Taal. 4. De JACK Object Browser (ook wel: JACOB) stelt de programmeur in staat om onder andere Beliefsets7 aan te maken. De JACK Agent Taal is de programmeertaal waarin het prototype van dit onderzoek is geprogrammeerd. Laten we deze taal eens wat beter bekijken.

3.5.1

Hoe werkt JACK?

JACK is opgebouwd uit verschillende onderdelen, te weten: • Agents • Events • Plannen • Meta-Level Reasoning • Beliefsets • Overige Onderdelen Je kunt als JACK-programmeur binnen de JACK Development Environment (ook wel: JDE) deze verschillende onderdelen defini¨eren. 6 7

een superset is een verzameling met als onderdeel ´e´en of meerdere deelverzamelingen zie 3.5.1

23

3.5 Wat is JACK?

Software Agents

Agents Agents zijn de eigenlijke objecten waar het allemaal om draait. Aan een Agent ’hangt’ de programmeur binnen de JDE de verschillende andere hierboven opgesomde onderdelen. Een Agent geeft aan welke Events hij intern of extern versturen kan, op welke Events hij kan reageren (ook wel: welke Events hij kan afhandelen), welk Plan of welke Plannen hij daarvoor kan gebruiken en welke Beliefset(s) hij gebruikt (uitleest en/of schrijft). Events Events maken de basis uit van alle activiteit die zich binnen een Agentgebaseerd systeem afspeelt. Zonder Events heeft een Agent meestal geen acties uit te voeren. Telkens wanneer er zich een Event voordoet, begint een Agent een taak om deze af te handelen. Deze taak kan worden gezien als de ’rode draad’ van activiteiten binnen de Agent. Deze taak zorgt ervoor dat de Agent moet kiezen tussen de Plannen die hij ter beschikking heeft. Zo kiest de Agent als reactie op een Event ´e´en Plan of een set van Plannen (zie 3.5.1), totdat de taak, en daarmee het Event, uiteindelijk slaagt of faalt. Zoals hierboven beschreven stimuleren Events een Agent in het nemen van actie. Er zijn drie verschillende typen Events: 1. Interne stimuli; dit zijn Events die een Agent naar zichzelf stuurt, meestal als resultaat van een redenatieproces dat zich in een Plan van de Agent heeft afgespeeld. Deze interne Events spelen een belangrijke rol in de voortdurende uitvoerfase van een Agent en de redenatiestappen die deze neemt. 2. Externe stimuli; dit zijn berichten van andere Agents, of gegevens van de omgeving waarin de Agent zich bevindt (ook wel: ’percepts’). 3. Motivatie stimuli; dit zijn Events die de motivaties van een Agent kunnen activeren, de in 2.3 genoemde ’Intentions’. Deze drie typen Events zijn te verdelen over twee soorten categorie¨en: Normale Events en BDI Events. Normale Events Normale Events zijn Events die een enkele, onmiddellijke reactie losmaken van een Agent. Wanneer een Normale Event wordt ontvangen door een Agent, start de Agent een taak om deze af te handelen. Deze taak houdt in dat de Agent het eerste Plan selecteert en uitvoert dat toepasbaar is voor dit Event (zie 3.5.1). Faalt dit Plan, dan faalt de taak, en stopt de uitvoering van het Event binnen deze Agent.

24

3.5 Wat is JACK?

Software Agents

BDI Events BDI Events zijn een andere vorm van Events. Een van de belangrijkste kenmerken van het BDI-model op een conceptueel niveau is dat het intentiegeori¨enteerd gedrag modelleert (binnen Agents), in plaats van Plan-geori¨enteerd gedrag. Dit wil zeggen dat de Agent zich committeert tot het gewenste resultaat (bij falen van een geselecteerd toepasbaar Plan, wordt het volgende geselecteerde Plan binnen de set van Plannen geprobeerd, et cetera), niet tot de methode die gekozen is om dit resultaat te behalen (zoals bij Normale Events het geval is: de uitvoering van het eerste toepasbare Plan, en niet meer dan dat). Dit verschil in gedrag wordt veroorzaakt door zogenaamde BDI Events. Dit zijn Events die ervoor kunnen zorgen dat er een speciaal soort Plan wordt uitgevoerd binnen een Agent, een zogenaamd ’Meta-Level Reasoning’ Plan. Zodra er een Event van dit type BDI Event opduikt, gaat JACK op zoek naar een aanwezig Meta-Level Reasoning Plan. Voor de werking en uitleg van een Meta-Level Reasoning Plan, zie 3.5.1. Door middel van deze BDI Events is het dus mogelijk een Agent te committeren aan de uitvoer van een taak. Het verschil tussen Normale en BDI Events Het verschil tussen Normale Events en BDI Events komt tot uiting in het effect dat ze hebben op een Agent. Terwijl Normale Events informatie representeren waarop de Agent reageert, zorgen BDI Events ervoor dat een Agent een doel nastreeft. Ook komt het verschil tot uiting in de manier waarop een Agent een Plan selecteert voor uitvoering. Bij Normale Events zoals hierboven beschreven, selecteert de Agent het eerste toepasbare Plan voor een gegeven Event en voert slechts dat Plan uit. BDI Events kunnen complexer en krachtiger worden afgehandeld. Dit proces wordt Meta-Level Reasoning genoemd (zie hiervoor 3.5.1). Plannen Agents hebben de beschikking over ´e´en of meerdere Plannen. Plannen beschrijven een volgorde van acties die een Agent kan uitvoeren wanneer een Event optreed. Een Plan kan slechts op ´e´en Event reageren, maar kan meerdere Events intern of extern versturen. Telkens wanneer er een Event is verstuurd en een Agent neemt de taak op zich om dit Event af te handelen, kijkt de Agent of hij een Plan heeft dat aangeeft dit Event af te kunnen handelen. Plannen kunnen worden gezien als de stukken code van meer conventionele programmeertalen zoals JAVA [18]. Ze beschrijven, in detail, precies wat een Agent moet doen wanneer er een gegeven Event optreedt. Met een aantal van deze Plannen heeft een Agent een set mogelijkheden en procedurele kennis waarop hij kan steunen wanneer dit nodig is. Plannen hebben de mogelijkheid om aan de Agent kenbaar te maken wanneer ze toepasbaar zijn in een gegeven situatie. Als een Plan van deze mogelijkheid 25

3.5 Wat is JACK?

Software Agents

gebruik maakt, kijkt een Agent eerst of het Plan of de Plannen die aangeven een bepaald Event af te handelen ook daadwerkelijk aangeven toepasbaar te zijn op dat moment in de gegeven situatie. Meta-Level Reasoning Onder Meta-Level Reasoning binnen JACK wordt het redeneren over selectie van de uitvoering van een Plan uit een gegeven set toepasbare Plannen bedoeld. Zijn er meerdere Plannen toepasbaar voor een gegeven BDI Event, dan kiest de Agent een van de Plannen uit de samengestelde set van toepasbare Plannen om uit te voeren. Dit kiezen van een Plan uit de toepasbare set van Plannen gebeurt door een speciaal Plan, het Meta-Level Reasoning Plan genoemd. Een Meta-Level Reasoning Plan is een Plan dat alleen reageert op ´e´en soort Event, het ’PlanChoice’ Event. Dit interne PlanChoice Event wordt actief binnen de Agent als er zich een situatie voordoet waarin er meerdere toepasbare Plannen zijn die eenzelfde BDI Event kunnen afhandelen. Het Meta-Level Reasoning Plan kan zogenaamde redenatiecode bevatten; code die bestaat uit specifieke JACK Agent Taal methoden. Een Agent kan dus een set van toepasbare Plannen opstellen voor een gegeven BDI Event, redenatie hierop toepassen met behulp van het Meta-Level Reasoning Plan om zodoende een beredeneerde keuze te kunnen maken uit de set van toepasbare plannen en intelligent te kunnen handelen op het moment dat dit gekozen Plan faalt. Dit intelligent handelen houdt bijvoorbeeld in dat de Agent de mogelijkheid neemt om een ander Plan uit de set te kiezen, dus om het Event op een mogelijk andere manier aan te pakken. Het is ook mogelijk dat de Agent de set van toepasbare Plannen opnieuw opstelt op het moment dat zijn initieel gekozen Plan faalt, zodat deze nieuwe set niet meer het gefaalde Plan bevat. Beliefsets Iedere beliefset waar een Agent gebruik van maakt wordt binnen JACK een beliefsetrelatie genoemd. Het beschrijft een set van beliefs die de agent kan hebben in termen van waardevelden (variabelen). Wanneer de Agent een nieuw belief wil aannemen, geeft het een bepaalde waarde aan deze velden en voegt dit nieuwe belief toe aan de beliefsetrelatie. Dit zorgt voor de aanmaak van een nieuwe tuple. Een tuple is niets meer dan een set van variabelen op hetzelfde niveau (ook wel: een n-dimensionale tabel). Elk belief dat een Agent op een bepaald moment heeft opgeslagen in een gegeven beliefsetrelatie, wordt gerepresenteerd als een tuple. Tuples kunnen true (waar) of false (onwaar) zijn. Dit true of false zijn laat het ’belief’ aspect van de tuple zien. Als het tuple true is dan is de Agent overtuigd van het feit dat dit belief een ware aanname is. Als het tuple false is, dan is de Agent overtuigd van het feit dat dit belief een onware aanname is.

26

3.6 Aansluitingen

Software Agents

Het feit dat beliefsetrelaties hun data als beliefs in plaats van als ’absolute waarheden’ representeren onderscheidt hen van de meeste andere programmeerbare data-opslag mechanismen en stelt Agents in staat om meer realistischer rationaal gedrag te laten zien. Agents behandelen de kennis die ze hebben niet als absolute waarheden, maar meer als beliefs die laten zien wat ze hebben geleerd of wat hen is verteld over de wereld om hen heen op dit moment. Net zoals mensen gaan Agents ervan uit dat deze beliefs waar zijn totdat er een nieuw feit ontdekt wordt dat de huidige beliefs van de Agent tegenspreekt, in dat geval zal hij de beliefs automatisch hieraan aanpassen. Overige Onderdelen JACK Agents kennen zogenaamde ’Capabilities’. Dit zijn groeperingen van functioneel overeenkomende Plannen onder ´e´en noemer. Capabilities dienen slechts ´e´en doel: een handige groepering in Plannen onderbrengen wanneer deze bijvoorbeeld in aantal onoverzichtelijk worden. Wegens de relatief beperkte opzet van de casus komen Capabilities verder niet meer aan de orde in dit onderzoek. JACK kent ook zogenaamde ’simple queries’ en ’complex queries’. Dit zijn zoekopdrachten van een eenvoudige of meer complexe aard die kunnen worden uitgevoerd over een bestaande beliefset. Een onderdeel dat hiermee verbonden is zijn de zogenaamde ’Views’. Hiermee is het mogelijk om twee of meerdere beliefsets aan elkaar te koppelen zodat er ´e´en gecombineerde beliefset ontstaat. Hierop is dan met een complex of een simple query een zoekopdracht uit te voeren, zodat er naar combinaties van gegevens kan worden gezocht. Opnieuw is het door de opzet van de casus en daarmee het prototype niet van meerwaarde gebleken om gebruik te maken van deze Views. Ze komen daarom verder niet meer aan de orde in dit onderzoek.

3.6 3.6.1

Aansluitingen Aansluiting DEMO en Prometheus

Vanwege de in 3.2.1 beschreven mogelijkheid om DEMO als selectiekader voor groepering van Agent-functionaliteiten op te laten treden, alsmede de in 3.3.4 beschreven relatie tussen de Actoren van DEMO en Software Agents, zijn door middel van Prometheus en met gebruik van het DEMO model als selectiekader de benodigde Agents onderkend. In deze relatie haakt het ontworpen DEMO-model in op de systeemontwerpstap van Prometheus.

27

3.6 Aansluitingen

3.6.2

Software Agents

Aansluiting Prometheus en JACK

In de Gedetailleerde Ontwikkel Fase van Prometheus wordt er gestreefd naar een opzet en definitie van Agents zoals die door JACK wordt gehanteerd. In de Gedetailleerde Ontwikkel Fase worden definities met namen zoals ’Agents’, ’Capabilities’ en ’Plannen’ gehanteerd (gelijk aan de benamingen binnen JACK) en wordt er vanuit de gedetailleerde functionaliteitbeschrijvingen van de verschillende systeemonderdelen JACK-voorbeeldcode afgeleid. In het gebruikte boek behorende bij de Prometheus methodologie staat tevens letterlijk geschreven: ’Many of the Prometheus concepts map directly to JACK’ (paragraaf 10.2 van [20]). Prometheus sluit hiermee aan op de Multi-Agent Software Toolkit JACK.

28

Hoofdstuk 4

Experiment 4.1

Inleiding

In dit hoofdstuk wordt eerst de verantwoording en een beschrijving van de casus gegeven. Vervolgens worden de gemaakte ontwerpbeslissingen met betrekking tot het onderzoek beargumenteerd, gevolgd door een beschrijving van de werkwijze bij gebruik van de gekozen methode, methodologie en tool. Tenslotte volgen de ervaringen die met deze onderdelen zijn opgedaan tijdens de uitvoering van het onderzoek.

4.2

Casus

In de casus1 van dit onderzoek wordt een geautomatiseerd verzekeringsaanvraagsysteem beschreven zoals dit operationeel is binnen een dochteronderneming van Reaal Verzekeringen. Het beschrijft de processen die door de klant aan de ene kant en het systeem aan de andere kant worden doorlopen om tot een automatische offerte- en verzekeringsaanvraag te komen via het internet. De casus houdt kort samengevat in dat de klant voor hetzij een offerteaanvraag, hetzij een directe verzekeringsaanvraag een formulier kan invullen, dat daarna door het systeem wordt gecontroleerd op volledigheid en juistheid van gegevens. Na controle van het formulier kan het systeem indien nodig overgaan tot een risicotechnische beoordeling, afhankelijk van het soort verzekering. Als een handtekening van de klant is ontvangen kan het systeem overgaan tot acceptatie, danwel afwijzing van de aangevraagde verzekering. Als de benodigde criteria om de aanvraag automatisch te accepteren of af te wijzen ontbreken binnen het systeem, moet een menselijke acceptant (hier verder ’menselijke expert’ genoemd) deze criteria aan het systeem leveren. In het geval van een weigering van de verzekeringsaanvraag krijgt de klant 1

zie bijlage A

29

4.3 Ontwerpbeslissingen

Software Agents

altijd de reden van weigering gecommuniceerd. In het geval van een acceptatie wordt de polis naar de klant gestuurd en is de eerste betaling van de klant tevens de acceptatie en activering van de polis. Voor een volledige beschrijving van de casus die voor dit onderzoek is gemaakt, zie bijlage A. Deze casus representeert een belangrijk primair proces voor Reaal Verzekeringen. Het behandelt een onderwerp waarvan de verwachting is dat Agent Software Technologie hiervoor een andere aanpak kan laten zien. Deze verwachtingen zijn gebaseerd op de in paragraaf 2.2 van hoofdstuk 2 genoemde eigenschappen van Software Agents. De in 2.2 genoemde eigenschap van een decentrale aanpak van de besturing van het door de casus beschreven proces kan mogelijk een andere invalshoek geven op het ontwerp en de ontwikkeling van software. De verwachting is ook dat de sociale interactie tussen Software Agents zal leiden tot een meer flexibelere, verfijnde, en in hogere mate geautomatiseerde aanpak van het door de casus beschreven proces. Tenslotte kan de aanpak met behulp van Software Agents mogelijk een mate van intelligentie, in de vorm van ’learning-ability’ (bijvoorbeeld een zelflerende automatische verzekeringsbeoordelaar in het geval van de casus), laten zien in de afhandeling van het in de casus beschreven proces. Het prototype van dit onderzoek is op basis van deze casus ontwikkeld en is daarmee een vereenvoudigd, representatief voorbeeld van een softwareoplossing binnen Reaal op basis van Agent Software Technologie.

4.3

Ontwerpbeslissingen

De casus zoals die voor dit onderzoek is opgesteld, beschrijft de gehele werking van een geautomatiseerd verzekeringsaanvraagsysteem. Een dergelijk systeem is uitgebreid en vergt veel ontwikkeltijd. De tijd die voor dit onderzoek beschikbaar is gesteld is niet voldoende om een dergelijk compleet systeem opnieuw te ontwerpen en ontwikkelen op basis van Agent Technologie. Gekozen is daarom voor de uitwerking van het Offerte Aanvraag Scenario (zie tabel 4.4), dat is omgezet naar een Interactie Diagram (zie figuur 4.3). Dit Interactie Diagram geeft de interactie tussen de Agents weer. Het Offerte Aanvraag Scenario (weergegeven in het Interactie Diagram) komt overeen met de andere ontworpen scenario’s2 op basis van de casus. Het is relatief eenvoudig mogelijk om aan de hand van dit werkende prototype een verdere uitbreiding te maken naar een systeem zoals beschreven in de totale casus. Het omvat het toevoegen van een implementatie van de andere ontworpen scenario’s aan het bestaande prototype. 2

zie bijlage C

30

4.4 Beschrijving

4.4 4.4.1

Software Agents

Beschrijving Beschrijving van het DEMO-model

Figuur 4.1: Het DEMO-model bij de casus In het gedetailleerde DEMO-interactiemodel op basis van de casus, zoals weergegeven in figuur 4.1, zijn de verschillende onderkende Actoren uitgebeeld met rechthoekige vlakken. Deze Actoren nemen elk een deel van de verantwoordelijkheid van de taakvolbrenging binnen het proces op zich. Tussen de verschillende Actoren zijn transactiesymbolen3 te zien, met telkens ´e´en of meerdere Actoren als Initiator en ´e´en Actor als Executor van een transactie. Links in het model is de Klant gemodelleerd als een systeemkern (het grijze rechthoekige vlak ’S1’) waarvan de interne werking niet bekend kan worden geacht. Rechts is de systeemkern van ProteQ (het kader ’S2’), 3

zie figuur 3.1 in hoofdstuk 3

31

4.4 Beschrijving

Software Agents

een dochteronderneming van Reaal Verzekeringen, aangegeven. Hierbinnen zijn de verschillende Actoren en de interacties hiertussen (de transactiesymbolen) weergegeven. Dit onderzoek zal zich met name op de in het figuur gearceerde Actoren richten, omdat de niet gearceerde Actoren slechts een ondersteunende rol vervullen in het proces. De Actoren en de daarbij behorende transacties die een ’(I)’ als toevoeging aan hun naam hebben, behoren tot het informationele niveau. De overige informationele en documentele processen zijn achterwege gelaten, vanwege hun niet essenti¨ele rol binnen de casus en vanwege het feit dat toevoeging van deze processen aan het DEMO-model de leesbaarheid en overzichtelijkheid van het model niet ten goede komen. Er volgt nu een uitleg van het DEMO-model zoals weergegeven in figuur 4.1. Een klant heeft een informatieverzoek, dat door de Actor ’InformatieVerschaffer’ wordt afgehandeld. Vervolgens stuurt deze het verzoek, afhankelijk van het type, door aan de Actoren ’Offerteopsteller’, ’Verzekeringsluiter’, ’Wijziger’, of ’Be¨eindiger’. De ’Offerteopsteller’ en ’Verzekeringsluiter’ leggen het verzoek daarna voor aan de Actor ’Beoordelaar’, waarna eventueel de Actor ’Beheerder’ de polis in beheer neemt. De ’Wijziger’ gaat afhankelijk van het type wijzigingsverzoek eerst via de ’Beoordelaar’ of direct naar de ’Beheerder’. De ’Be¨eindiger’ legt het verzoek zonder tussenkomst van de ’Beoordelaar’ voor aan de ’Beheerder’. De ’Beoordelaar’ wordt eventueel geassisteerd door de Actor ’Criterialeveraar’ (in dit onderzoek is dat een mens), die extra voorwaarden (criteria) aanlevert, en/of de Actor ’Financieel Beheerder’, die een financieel klantbeeld aanlevert. Een Actor ’Productontwikkelaar’ levert de initi¨ele productvoorwaarden of past deze aan. De Actor ’Prolongeerder’ zorgt daarna voor de eventuele activering van een polis en de incassering van premies. Resultaten van genomen acties worden door de ’Offerteopsteller’, ’Verzekeringsluiter’, ’Wijziger’, ’Be¨eindiger’ of de ’InformatieVerschaffer’ zelf teruggekoppeld aan de klant.

4.4.2

Beschrijving van Prometheus

Om in dit onderzoek tot een beschrijving van een Agent Software Systeem te komen zijn de ontwerpstappen die Prometheus voorstelt in [20] gevolgd en uitgevoerd. De stappen die voor de casus niet zijn uitgevoerd zijn bewust achterwege gelaten, omdat de casus kleinschalig van opzet is en omdat er al een bedrijfsprocesmodel in DEMO is gemaakt op basis van de casus. Prometheus gaat niet uit van enige voorkennis bij het ontwerpen van een systeemmodel, ook niet van een al aanwezig bedrijfsprocesmodel, iets dat

32

4.4 Beschrijving

Software Agents

wel voorhanden is bij dit onderzoek, in de vorm van het DEMO model4 . Vanwege de in 3.2.1 beschreven mogelijkheid om DEMO als selectiekader voor groepering van Agent-functionaliteiten op te laten treden, alsmede de in 3.3.4 beschreven relatie tussen de Actoren van DEMO en Software Agents hebben we door middel van Prometheus en met gebruik van het DEMO model als selectiekader de benodigde Agents onderkend. DEMO functioneert hierin als groeperingskader van functionaliteiten, resulterend in de Agentdefini¨ering. In bijlage B is de uitwerking van de Prometheus Systeem Specificatie Fase te vinden en in bijlage C de uitwerking van de Architectuur Ontwikkel Fase. De Gedetailleerde Ontwikkel Fase is achterwege gelaten, mede omdat er vanuit de Architectuur Ontwikkel Fase genoeg afgeleide gegevens zijn om zonder tussenkomst van de Gedetailleerde Ontwikkel Fase aan de slag te kunnen in de voor dit onderzoek gekozen Agent Programmeer Taal ’JACK’. Nu volgt een uitgebreide beschrijving van de totstandkoming van het systeemontwerp met behulp van Prometheus, te beginnen bij de eerste ontwerpfase: de Systeem Ontwerp Fase. De Systeem Ontwerp Fase De Systeem Ontwerp Fase is opgenomen in bijlage B. Voorafgaande aan het eerste onderdeel van de Systeem Ontwerp Fase moet een omschrijving van het systeem op papier worden gezet. Hierna kan begonnen worden met het eerste onderdeel. Als eerste onderdeel van de Systeem Specificatie Fase zijn de systeemdoelen uit de systeemdoelomschrijving ge¨ıdentificeerd (te herkennen aan de dikgedrukte, cursieve gedeelten) en daarna opgesomd (zie vanaf B.1.1 in bijlage B voor deze genomen stappen). Een voorbeeld van dit bovengenoemde traject van systeemdoelidentificering en -opsomming wordt hieronder gegeven aan de hand van een gedeelte van de eerste zin in de systeemdoelomschrijving5 , welke luidt: ”We willen een systeem maken dat het mogelijk maakt voor een klant om online een (autoverzekerings)offerte of autoverzekering af te sluiten..” Hieruit volgt de systeemdoelidentificering: ”We willen een systeem maken dat het mogelijk maakt voor een klant om (online) een (autoverzekerings)offerte of (auto)verzekering af te sluiten..” 4 5

zie figuur 4.1 zie B.1.1 in bijlage B

33

4.4 Beschrijving

Software Agents

Vervolgens wordt de opsomming van deze vier afgeleide ge¨ıdentificeerde systeemdoelen gemaakt, te weten: • (online) verzekeringssysteem • in eerste instantie alleen autoverzekeringen • offerte kunnen aanbieden • verzekering kunnen aanbieden en afhandelen Na deze opsomming zijn de gelijksoortige en overlappende doelen samengevoegd en gegroepeerd tot een nieuwe lijst van systeemdoelen (met subdoelen), die na een herhaling van de samenvoeging en hergroepering-stap uitmondt in een lijst van functionaliteiten (zie vanaf B.1.2 voor deze genomen stappen). Als voorbeeld bij deze genomen stappen volgt nu de afleiding van de eerste drie hierboven opgesomde afgeleide systeemdoelen: Na verfijning van de drie systeemdoelen worden deze in eerste instantie onder ieder een eigen doel geschaard: (Online) verzekeringssysteem • mogelijkheden om direct (online) een verzekering af te sluiten In eerste instantie alleen autoverzekeringen • aanbod beperken tot autoverzekeringen Offerte kunnen aanbieden • offerte opstellen met klant • offerte direct beoordelen • gehonoreerde offerte aanbieden aan klant • (nog) niet gehonoreerde offerte communiceren naar klant Maar bij hergroepering komen twee van de doelen te vallen onder de onderkende functionaliteit ’Offreren’. Het eerste doel ((Online) verzekeringssysteem) wordt als een gegeven eigenschap van het systeem en niet als een na te streven doel beschouwd. Het wordt hierdoor niet verder meegenomen in de volgende stappen. De hergroepering van de doelen in de onderkende functionaliteit ’Offreren’ geeft nu: 34

4.4 Beschrijving

Software Agents

Offreren In eerste instantie alleen autoverzekeringen • aanbod beperken tot autoverzekeringen Offerte kunnen aanbieden • offerte opstellen met klant • offerte direct boordelen • gehonoreerde offerte aanbieden aan klant • (nog) niet gehonoreerde offerte communiceren naar klant Hierna wordt van deze onderkende functionaliteit een beschrijving gegeven, waarbij onder andere de subdoelen als de acties van de functionaliteit kunnen worden beschouwd (zie vanaf B.1.3 voor de functionaliteitsbeschrijvingen). Als voorbeeld volgt hier de beschrijving van de functionaliteit ’Offreren’: Beschrijving: Deze functionaliteit draagt zorg voor de interactie met de klant vanaf het moment dat deze klant te kennen heeft gegeven een offerte te willen hebben Goals: Maak offerte, lever offerte Acties: 1. Stel offerte op met klant 2. Controleer ingevuld offerteverzoek op juistheid en volledigheid 3. Laat offerte beoordelen 4. Stuur positief beoordeelde offerte aan klant 5. Communiceer negatief beoordeelde offerte naar klant Triggers: Offerteaanvraag, beoordeelde offerte, offerte is aangemaakt [INTERN] Gebruikte informatie: Klantgegevens, offerteaanvraag, beoordelingsgegevens Geproduceerde informatie: Klantgegevens, offertegegevens, offerte, afgewezen offerteaanvraag Nu kunnen de scenario’s behorende bij elke functionaliteit worden opgesteld. Deze scenario’s laten zien wat de acties zijn die moeten worden uitgevoerd in het systeem om de doelen behorende bij de functionaliteit te behalen. De gebruikte afkortingen behorende bij de functionaliteiten zijn samengevat in tabel 4.1. Als een afkorting in een scenariotabel tussen haakjes (bijvoorbeeld ’(O)’) is geplaatst wil dit zeggen dat de functionaliteit in kwestie op dat moment geen actieve functie heeft. Zie vanaf B.1.4 in bijlage B voor alle in dit 35

4.4 Beschrijving

Software Agents

onderzoek afgeleide scenario’s. De gebruikte afkortingen van de onderkende functionaliteiten zijn: Functionaliteit Offreren Verzekeren Beheren Service Klantinteractie Beoordelen

Afkorting O V BH S K B

Tabel 4.1: De afkortingen van de functionaliteiten Een voorbeeld van een afgeleid scenario behorende bij de functionaliteit ’Offreren’ is: Nr. 1. 2. 3. 4. 5. 6. 7. 8.

Type Goal Goal Action Action Goal Other Percept Action

Omschrijving bepaal klantvraag lever offerte stel offerte op met klant controleer ingevulde offerte beoordeel offerte beoordeling afwachten beoordeling ontvangen bied offerte wel/niet aan

Functionaliteit K O O O B (O) (O) O

Tabel 4.2: Offerte Aanvraag Scenario Na de ontworpen scenario’s volgen nog twee mogelijke alternatieve scenario’s waar verder in dit onderzoek geen gebruik meer van wordt gemaakt, maar die zijn opgenomen vanwege de volledigheid bij het gebruik van de methodologie (zie B.1.5). Dan volgen nog door Prometheus voorgeschreven opsommingen, zoals de gebruikte ’percepts’ (input) en ’actions’ (output). Prometheus gaat uit van het feit dat deze twee vormen van input en output soms extra systeemonderdelen vereisen, zoals sensoren en de daarbij behorende informatieverwerking, iets dat in dit onderzoek voor het prototype niet geldt. Als laatste onderdeel van de Systeem Specificatie Fase volgt nog een korte opsomming van de interne en externe databronnen (zie B.1.7 en B.1.8).

36

4.4 Beschrijving

Software Agents

De Architectuur Ontwerp Fase De Architectuur Ontwerp Fase is opgenomen in bijlage C. Eenmaal aangekomen bij de Architectuur Ontwerp Fase van Prometheus wil Prometheus dat er een diagram gemaakt wordt waarin de koppelingen van de onderkende functionaliteiten met de gebruikte datasets worden aangegeven. Dit om een idee te krijgen van de afhankelijkheden van de functionaliteiten voor wat betreft de gebruikte data. Prometheus spoort de ontwerper aan om steeds kritisch te blijven kijken naar dit diagram om zo te komen tot een zo minimaal mogelijke afhankelijkheid met een zo krachtig mogelijke werking. Het diagram is weergegeven in figuur 4.2.

Figuur 4.2: Het Data-model bij de casus De pijlen tussen de functionaliteiten hebben de volgende betekenis: een enkele pijl staat voor een lees-actie, een dubbele pijl betekent een lees- en schrijfactie. De dataset ’Risicobeoordelingscriteria’ is de enige externe dataset in dit diagram6 . De volgende stap in deze tweede ontwerpfase van Prometheus bestaat uit het afleiden van de Agents uit de onderkende functionaliteiten. Vanwege het al eerder genoemde gebruik van de methode DEMO als selectiekader voor het 6

nota bene: dit diagram geeft niet de gebruikte beliefsets in het uiteindelijke prototype weer, omdat beliefsets niet gelijk (hoeven te) zijn aan datasets

37

4.4 Beschrijving

Software Agents

onderkennen van de Agents voor dit onderzoek is het aantal functionaliteiten, op de functionaliteit ’service’ na, ´e´en op ´e´en omgezet in Agents. Uit de functionaliteit ’Service’ zijn twee Agents afgeleid, de Agent ’Wijziger’ en de Agent ’Be¨eindiger’, in overeenstemming met de in het DEMO-model onderkende Actoren. Vanwege een grotere gelijkenis in functionaliteit (’Service’) dan in afhankelijkheid en verantwoordelijkheid zijn uit de functionaliteit ’Service’ deze twee Agents afgeleid. In totaal zijn er nu negen Agents, opgesomd in tabel 4.3. Deze Agents worden vervolgens gedetailleerd beschreven in C.1.2 van bijlage C. Naam Offerte Opsteller Verzekering Sluiter Beoordelaar Criteria Leveraar Polis Opsteller Beheerder Wijziger Be¨eindiger Informatie Verschaffer

Afkorting OO VS BO CL PO BH W BI IV

Tabel 4.3: De negen Agents met hun afkortingen Na het vaststellen van de te gebruiken Agents en de beschrijving hiervan, is Prometheus aangekomen bij de voor dit onderzoek gebruikte, laatste stap. Uit het gekozen ’Offerte Beoordelen Scenario’ wordt nu het ’Interactie Diagram’ opgesteld. Het interactiediagram geeft de interacties tussen de onderkende Agents binnen het systeem schematisch weer. We voegen daartoe het scenario ’offerte aanvragen’ (tabel C.11) samen met het scenario ’beoordelen’ (tabel C.12) (beiden zijn afkomstig uit de Specificatie Fase van Prometheus) tot een nieuw samengevoegd scenario ’offerte aanvragen en beoordelen’ (zie tabel C.13 in C.1.3). Een kopie van dit samengevoegde ’offerte aanvragen en beoordelen’ scenario is hier afgedrukt in tabel 4.4. Uit dit samengevoegde scenario wordt nu het eigenlijke interactiediagram afgeleid en opgesteld waarop het prototype wordt gebaseerd. Zie figuur 4.3 voor het diagram. De ’KL’ in het interactiediagram is de naam voor de Agent ’Klant’ waarvoor in het prototype ook een Agent is gecre¨eerd (de Agent ’Klant’ wordt gevoed met informatie die door een mens wordt ingevoerd in het prototype, zie hiervoor 4.4.3). De ’+’ en ’-’ aanduidingen die te zien zijn boven de interactielijnen met de nummers 11 en 16 corresponderen met de optionele stappen in het ’offerte aanvragen en beoordelen scenario’ (aangegeven met ’OPT’ in kolom ’Opt.Keuze’ in tabel 4.4). Dit wil zeggen dat afhan-

38

4.4 Beschrijving

Nr. 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 29. 20.

Type Percept Goal Goal Action Action Action Goal Other Action Other Percept Action Action Other Percept Action Action Percept Action Action Action

Software Agents

Omschrijving klantvraag ontvangen bepaal klantvraag lever offerte stel offerteaanvraag op met klant controleer ingevulde offerteaanv comm.ingev.off.formulier beoordeel aanvraag beoordeling afwachten fin.beheerder risicobeoordeling risicobeoordeling afwachten risicobeoordeling ontvangen risicobeoordeling mens. expert laten beoordelen mens. beoordeling afwachten mens. beoordeling ontvangen update set criteria mens. beoordeling beoordeling ontvangen communiceer afwijzing stel offerte op bied offerte aan

Agent IV IV OO OO OO OO BO (OO) BO (BO) (BO) BO CL (BO) (BO) BO BO (OO) OO OO OO

Opt.Keuze

OPT

OPT

Tabel 4.4: Offerte Aanvraag en Beoordeel Scenario

39

4.4 Beschrijving

Software Agents

Figuur 4.3: Het interactiediagram afgeleid van het ’Offerte Aanvraag en Beoordeel Scenario’ in tabel 4.4

40

4.4 Beschrijving

Software Agents

kelijk van een positieve (’+’) of negatieve (’-’) uitkomst van een beslissing de daarmee gekoppelde verdere interactiestappen moeten worden genomen. De bedoeling van Prometheus is om op deze wijze voor ieder scenario of samengesteld scenario een interactiediagram op te stellen en om deze interactiediagrammen samen te implementeren in een Agent Software Toolkit. Zoals ook al in 4.3 is verklaard is het prototype slechts ontworpen op basis van dit interactiediagram wegens tijdsdruk, vandaar ook de keuze om slechts ´e´en interactiediagram af te leiden voor dit onderzoek.

4.4.3

Beschrijving van het prototype

JACK is de Multi-Agent Software Toolkit waarbinnen het Multi-Agent protoype op basis van de casus is ge¨ımplementeerd. Hieronder volgt de beschrijving van de werking van het prototype. Zie figuur 4.4 voor een afbeelding van de JACK Development Environment (de JDE) met daarin het prototype. Zie ook figuren (D.1), D.2, D.3, D.4 en D.5 in bijlage D voor de verschillende onderdelen van het prototype. Er is ook een voorbeeld van JACK-programmacode behorende bij het Plan ’BeoordeelBeforeAndAfterNoon 12’, te vinden in figuur D.6. Voor een beter overzicht van de doorlopen stappen in het prototype, zie het interactiediagram weergegeven door figuur 4.3 in 4.4.2 (of figuur C.2 in bijlage C). De nummers zoals verwerkt in de namen van de plannen van het prototype corresponderen met die van de interactiestappen zoals aangegeven in het interactiediagram. Ook de namen zoals gegeven aan de gecre¨eerde Agents in het prototype corresponderen met die van de Agents in het interactiediagram. Bij initialisatie van het programma worden de vijf Agents gecre¨eerd (Klant ’KL’, InformatieVerschaffer ’IV’, OfferteOpsteller ’OO’, Beoordelaar ’BO’ en CriteriaLeveraar ’CL’) en wordt de klant om gegevens gevraagd. Dit gebeurt door middel van invoervensters op het scherm waarin de klant (in dit geval een mens) gevraagd wordt naar zijn of haar naam, adres, woonplaats, automerk, autotype en autogewicht7 . Deze gegevens worden vervolgens opgeslagen door de Agent ’Klant’ in zijn Beliefset (genaamd ’Aanvraag’) en doorgestuurd naar de Agent ’InformatieVerschaffer’. Deze bepaalt het type klantvraag (in het geval van dit prototype is dit vooralsnog altijd een aanvraag van het type ’offertevraag’) en stuurt deze offertevraag door naar de Agent ’OfferteOpsteller’. Deze Agent legt de gegevens vervolgens voor aan de Agent ’Beoordelaar’ om door hem beoordeeld te worden. De Beoordelaar kent verschillende Plannen voor de uitvoer van de beoor7

zie E.1 in bijlage E

41

4.4 Beschrijving

Software Agents

Figuur 4.4: De JDE met daarbinnen de JACK-onderdelen

42

4.4 Beschrijving

Software Agents

deling. Afhankelijk van de systeemtijd8 van dat moment zal de Beoordelaar kiezen welk Plan (’BeoordeelBeforeNoon’, ’BeoordeelAfterNoon’ of ’BeoordeelBeforeAndAfterNoon 12’) zal worden aangewend om de beoordeling uit te voeren. Dit voorbeeld van het selecteren van een geschikt Plan aan de hand van de systeemtijd is gekozen om te laten zien dat gedurende run-time9 Agent Software Systemen flexibiliteit kunnen laten zien, dat wil zeggen: zelf een keuze kunnen maken over het verdere verloop van de gekozen actie. Op het moment dat de Beoordelaar een zogenaamd BDI Event (zie BDI Events in 3.5.1) ziet verschijnen, gaat deze Agent na over welke Plannen hij de beschikking heeft om dit BDI Event af te handelen. Afhankelijk van de systeemtijd (door de Plannen zelf wordt aan de Agent aangegeven of ze op dat moment toepasbaar zijn of niet) kiest de Beoordelaar met zijn Meta-Level Reasoning Plan (genaamd ’MetaPlan KiesBeoordeelPlan 6’) welk Plan zal worden aangewend voor de beoordeling van de autogegevens. Een MetaLevel Reasoning Plan is een plan dat de mogelijkheid heeft om de lijst met toepasbare Plannen van zijn Agent van dat moment in te zien en hieruit een Plan te selecteren dat als eerste zal worden toegepast om te proberen het binnengekomen Event af te handelen (zie ’Plannen’ in 3.5.1). De Beoordelaar kijkt nu of de autogegevens die hem zijn voorgelegd reeds aanwezig zijn in zijn Beliefset (genaamd ’Criteria’) en zo ja, of deze offerteaanvraag op basis van deze autogegevens door hem mag worden geaccepteerd of afgewezen. Indien de voorgelegde autogegevens niet bekend zijn bij de Beoordelaar zal deze de hulp van de Agent ’CriteriaLeveraar’ (in dit geval een mens) inroepen. Er worden in dat geval invoervensters getoond waarin de CriteriaLeveraar aan kan geven of de voorgelegde autogegevens in het vervolg moeten leiden tot een automatische acceptatie of afwijzing, dan wel dat deze autogegevens voortaan bij ieder voorkomen door een menselijke expert moeten worden geaccepteerd dan wel afgewezen. Na de beoordeling ontvangt de OfferteOpsteller het eindoordeel van de Beoordelaar en stelt de OfferteOpsteller op basis van dit oordeel een offerte op (deze wordt op het scherm in een venster getoond10 ), waarin het oordeel is opgenomen. Het eindoordeel wordt door de OfferteOpsteller doorgegeven aan de Klant die zo op de hoogte wordt gesteld van een acceptatie dan wel afwijzing van zijn oorspronkelijke offerte-aanvraag. Op afbeelding E.1 en E.2 in bijlage E is het prototype in werking te zien. 8

de systeemtijd van het besturingssysteem waarop het prototype actief is de tijdsduur gedurende welke het programma actief is 10 zie E.2 in bijlage E 9

43

4.5 Ervaringen

4.5

Software Agents

Ervaringen

In het volgende onderdeel worden de ervaringen die zijn opgedaan met de gekozen methode, methodologie en tool, beschreven. Als eerste komt de gekozen methode DEMO aan bod. Daarna de opgedane ervaringen met de gekozen methodologie (ook wel: systeemontwerptechniek) Prometheus en tenslotte de ervaringen met de gekozen Agent Software Toolkit JACK, opgedeeld in de relevante onderdelen en aspecten van deze Agent Programmeertaal. Tijdens de beschrijving van de ervaringen is er met name gelet op de mogelijkheden en de beperkingen van de onderdelen tijdens het ontwikkelproces van het prototype.

4.5.1

Ervaringen met DEMO

De mogelijkheden van DEMO liggen op het vlak van de bedrijfsprocesmodellering. Het proces zoals in de casus beschreven is een voorbeeld van een bedrijfsproces en is geen probleem gebleken voor DEMO. Met hulp van een computerprogramma waarmee schema’s kunnen worden gemaakt zijn de Actoren en de transacties hiertussen weergegeven. Daarna is het zaak om aan te geven welke van de onderkende Actoren tot de systeemkern behoren. Alle Actoren in dit onderzoek behalve de Klant-Actor vallen binnen deze kern (S2 in figuur 4.1). Zo is het gedetailleerde interactiemodel van het bedrijfsproces zoals beschreven in de casus ontworpen. DEMO stelt de ontwerper in staat om nog meer mogelijke typen modellen te ontwerpen met als basis ´e´en en hetzelfde bedrijfsproces (zoals een procesmodel, een feitenmodel en een interstrictiemodel [6]), maar voor dit onderzoek volstaat het ontworpen gedetailleerde DEMO-interactiemodel. Een ontwerper van een DEMO model heeft ook de mogelijkheid om te beslissen op welk niveau het model het proces weergeeft. Voor het model van dit onderzoek is het essenti¨ele niveau voldoende, vanwege het gebruik van het DEMO model als input voor de systeemontwerpmethodologie Prometheus. Voor wat betreft het modelleren van het bedrijfsproces zoals beschreven in de casus van dit onderzoek zijn er geen beperkingen van DEMO naar boven gekomen.

4.5.2

Ervaringen met Prometheus

Het is mogelijk om zonder zogenaamd ’voorwerk’ of voorkennis van een systeem aan de hand van deze methodologie te komen tot een werkbaar Agent Software Systeemontwerp. In dit onderzoek is er de beschikking over een DEMO-model voor wat betreft de (bedrijfs)procesmodellering, maar om te komen tot een werkbaar Agent Software Systeemontwerp op basis van Prometheus is het niet noodzakelijk om over een dergelijk model te beschikken.

44

4.5 Ervaringen

Software Agents

Hoewel de methodologie van Prometheus uitgaat van een systeemontwerp dat vooral geschikt is om ge¨ımplementeerd te worden in de Agent Software Tookit JACK, is het ook mogelijk om het uiteindelijke systeemontwerp te implementeren in een andere Agent Software Toolkit naar keuze. Voor wat betreft het maken van een systeemontwerp aan de hand van de beschrijving in de casus zijn er geen beperkingen van Prometheus naar boven gekomen.

4.5.3

Ervaringen met JACK

De JACK JDE Om het prototype te implementeren is gebruikgemaakt van de JACK Development Environment (ook wel: JDE). Dit is de ontwikkelomgeving die speciaal is toegespitst op het programmeren in de JACK Agent Taal. Deze ontwikkelomgeving biedt de programmeur via een grafische interface het gemak van het grafisch toevoegen of aanpassen van de benodigde onderdelen die samen de JACK Agent Taal uitmaken. De programmeur heeft door de mogelijkheid om de onderdelen in een boomstructuur toe te voegen of aan te passen een duidelijk overzicht over de huidige opzet en voortgang van het programma-in-wording. De JDE integreert de meeste noodzakelijke onderdelen die worden gebruikt tijdens het ontwikkelproces, maar voor het maken van een beliefset moet er een ander programma worden gebruikt. Dit programma heet JACOB (zie 3.5). Tijdens de ontwikkelperiode zijn er geen tekortkomingen ontdekt in de mogelijkheden die de ontwikkelomgeving JDE biedt. De JACK Agent Taal De JACK Agent Taal is een uitgebreide taal met veel mogelijkheden. De taal is tijdens het ontwikkelproces van dit onderzoek robuust gebleken. Mede dankzij de basis, die bestaat uit de beproefde programmeertaal JAVA [18], is de JACK Agent Taal relatief snel aan te leren en is de syntax helder en duidelijk. De JACK Agent Taal is beperkt voor wat betreft de ingebouwde mogelijkheden tot het maken van een gebruikersinterface, hier zijn nagenoeg geen mogelijkheden voor ingebouwd en deze moeten daarom ook door de programmeur zelf worden toegevoegd met behulp van JAVA, zoals in het geval van dit onderzoek is gebeurd. Het concept Agent daarentegen is duidelijk en uitgebreid doorgevoerd in de JACK Agent Taal. Een Agent is een ’kapstok’ waar de verschillende onderdelen (Events, Plannen, Beliefsets, et cetera) aan moeten worden ’gehangen’. Agents kunnen zelf ook programmacode bevatten en op Agentniveau is het mogelijk om het domein en bereik van sommige onderdelen aan te geven (op Agentniveau kan bijvoorbeeld voor iedere Beliefset van die 45

4.5 Ervaringen

Software Agents

Agent aangegeven worden of alle andere Agents, alleen Agents van dit type Agent, of zelfs alleen deze Agent gebruik mag maken van de Beliefset). Aan Events kan eenvoudig via keuzelijstjes het type (normaal of BDI) en soort worden toegekend. De eventueel door het Event gebruikte variabelen en dergelijke zijn eenvoudig aan te maken, in te voeren en te wijzigen. De Plannen vormen het onderdeel waar de meeste ’uitvoercode’ (de programmacode die het daadwerkelijk uitvoeren van taken beschrijft) binnen JACK aanwezig is. Een Plan is zowel grafisch via een diagram te ontwerpen, als ook via een meer gebruikelijk code-invoervenster binnen de JDE11 . De opbouw van een Plan is duidelijk aangegeven en via een grafische opdeling binnen de JACK JDE van Plannen in stukjes functionaliteit (’relevance’, ’body’, ’JAVA code’, et cetera) is het duidelijk waar welke soort programmacode thuishoort. Beliefsets moeten, zoals al eerder in dit verslag aangegeven, ontworpen worden in een apart programma. Hiervoor is een aparte handleiding aanwezig. Hierna kan via het importeren van een aangemaakte Beliefset verder worden gewerkt met de Beliefset vanuit de JACK JDE. Beliefsets zijn daarna als elk ander onderdeel binnen de JACK Agent Taal aan te roepen, te koppelen et cetera. Plannen en Events kunnen beide gebruik maken van (eventueel eigen) Beliefsets. Er zijn twee niveau’s van toegang tot een Beliefset : alleen lezen of zowel lezen als schrijven. Aan Beliefsets kunnen tenslotte simple- of complex queries worden ’gehangen’ in de JACK JDE (zie ’Overige Onderdelen’ in 3.5.1). Wat betreft de overige onderdelen zijn de ervaringen te beperkt om hier beschreven te kunnen worden, vanwege de al eerder genoemde keuze om voor dit prototype sommige onderdelen niet te gebruiken (zie ’Overige Onderdelen’ in 3.5.1). De JACK Compiler en de JACK Agent Kernel De ervaringen voor wat betreft de mogelijkheden met de JACK Compiler en Agent Kernel zijn positief. Foutmeldingen die de Compiler weergeeft zijn begrijpelijk en gemaakte fouten in de code (syntactisch zowel als semantisch) zijn, mede hierdoor, relatief snel op te sporen. Er zijn verschillende mogelijkheden tot code-tracing. Code-tracing is het laten verlopen van de afhandeling van programmacode in vooraf bepaalde pauzestappen of met een stapsgewijze snelheid, zodat er zo nauwkeurig kan worden gezocht naar optredende problemen in de programmacode. De JACK Agent Kernel biedt onder andere de mogelijkheid om de Agents op fysiek verschillende systemen te laten werken waarbij de onderlinge communicatie in de achtergrond wordt afgehandeld door de Kernel, die deze mogelijkheid tot distributie over een netwerk standaard ondersteunt. Er kunnen verschillende protocollen worden gekozen waarin de netwerkcommunicatie verloopt. 11

zie figuur D.6 in bijlage D

46

4.5 Ervaringen

Software Agents

Beperkingen voor wat betreft performance of stabiliteit zijn niet gevonden tijdens het implementatieproces van dit onderzoek. Tot zover de, overwegend positieve, ervaringen die zijn opgedaan met DEMO, Prometheus en JACK tijdens de uitvoer van dit onderzoek. De conclusies die hieruit getrokken kunnen worden, zullen verder beschreven worden in het volgende hoofdstuk.

47

Hoofdstuk 5

Conclusie 5.1

Inleiding

In dit hoofdstuk worden aan de hand van de opgedane ervaringen en gelet op de voor dit onderzoek gestelde onderzoeksvraag, conclusies getrokken voor wat betreft de bruikbaarheid en mogelijkheden van de gebruikte procesmodelleringsmethode, systeemontwerpmethodologie en Agent Technologie en de toepasbaarheid hiervan op Reaal Verzekeringen. Er wordt daarna ingegaan op het aan het begin van dit onderzoek veronderstelde intelligentieaspect van Agent Technologie. Tot slot volgt de beantwoording van de voor dit onderzoek gestelde centrale vraag en de daaruit geformuleerde hoofdvragen.

5.2 5.2.1

Conclusies Conclusie DEMO

Dankzij de reeds aanwezige kennis van DEMO binnen de afdeling IT Architectuur van Reaal Verzekeringen is het opstellen van het gedetailleerd DEMO-interactiemodel een relatief eenvoudige taak gebleken. Er moet worden opgemerkt, dat om een goed en sluitend DEMO model van een proces op te stellen de nodige ervaring vereist is. Als echter aan deze voorwaarden van kennis en ervaring kan worden voldaan, blijkt het gebruik van de methode DEMO krachtig en uitgebreid voor wat betreft het beschrijven van een proces. De meerwaarde van DEMO als selectiekader in het afbakenen van de Agent-functionaliteiten in het verdere verloop van het systeemontwerpproces is groot; het voorkomt een tijdrovend proces van herhalende groepering van functionaliteiten indien dit DEMO-model niet voorhanden is. Wellicht dat de meerwaarde van een ontworpen DEMO-model bij relatief zeer eenvoudige procesbeschrijvingen niet direct merkbaar is, maar bij het voor dit onderzoek beschreven proces (een relatief eenvoudig beschreven proces)

48

5.2 Conclusies

Software Agents

is dit al duidelijk wel het geval.

5.2.2

Conclusie Prometheus

De handvaten zoals aangereikt door de Prometheus methodologie zijn helder en duidelijk voor wat betreft de eerste twee van de drie ontwerpfasen die samen de methodologie beschrijven: de Systeem Specificatie Fase en de Architectuur Ontwikkel Fase. Eenmaal aangekomen in de derde fase, die van de Gedetailleerde Ontwerp Fase, wordt het praktische nut van de ontwerpmethode voor een deel teniet gedaan door de ogenschijnlijk steeds algemener wordende praktische handleiding om van de twee voorgaande fasen te komen tot een detailbeschrijving van het systeem-in-wording. Er wordt bijvoorbeeld voor wat betreft het onderwerp van data representatie (paragraaf 9.5 van [20]) wel genoemd dat JACK zogenaamde Beliefsets kent, maar er wordt daarna niets mee gedaan. Deze ondervonden ogenschijnlijke tekortkoming heeft waarschijnlijk voornamelijk te maken met het feit dat de hier gebruikte handleiding een eerste versie is; iets dat in de toekomst hopelijk snel zal veranderen. Vermeld moet worden dat in dit onderzoek de Gedetailleerde Ontwerp Fase niet daadwerkelijk is uitgevoerd, vanwege de hier genoemde ogenschijnlijke vrijblijvendheid van deze laatste ontwerpfase, tijdsbeperkingen aan het onderzoek en de relatief beperkte schaal van het in dit onderzoek ontworpen systeem. De meerwaarde van deze laatste ontwerpstap van Prometheus is kortom voor de uitvoering van dit onderzoek niet duidelijk genoeg naar voren gekomen. Dat neemt niet weg dat aan de hand van de handleiding bij deze methodologie relatief snel een werkbaar systeemontwerp ontworpen is, dat zonder veel aanpassing is ge¨ımplementeerd in de Agent Software Toolkit JACK.

5.2.3

Conclusie JACK

Agent Oriented Software [1], de ontwikkelaars van JACK, hebben een goede, robuuste taal ontwikkeld, gebaseerd op JAVA, met veel mogelijkheden. De taal is voor programmeurs met kennis van JAVA (of een andere programmeertaal gebaseerd op object-ori¨entatie) snel aan te leren, hoewel de idee¨en en de mogelijkheden van de toegevoegde Software Agent concepten duidelijk verschillen van die van de traditionele aanpak van software-ontwikkeling. Het is gedurende de ontwikkelperiode gebleken dat het programmeren van Agent Software een andere manier van ontwikkelen en kijken naar softwareontwikkeling vereist. Dit uit zich in zekere mate ook in het ontwikkelen van JACK Agent code. Veel ontwerpvragen die gedurende de ontwikkeling moeten worden beantwoord zijn op verschillende manieren aan te pakken, maar het blijft op dit moment nog aftasten welke aanpak de beste is voor welke ontwerpvraag. Dit is hoogstwaarschijnlijk vanwege de nog beperkte ervaring

49

5.2 Conclusies

Software Agents

die aanwezig is met het oplossen van terugkerende ontwerpvragen in een Agent Software systeem. Een vuistregel voor generieke antwoorden op veel voorkomende implementatievragen is kortom nog niet bekend, begrijpelijk voor een dergelijk nieuwe aanpak van software-ontwerp en -implementatie. JACK biedt mogelijkheden voor communicatie tussen Software Agents, hoewel deze helaas niet de taalhandelingen zoals beschreven in de FIPA standaard (Foundation for Intelligent Physical Agents, [7]) volgen. Zoals ook al in het vorige hoofdstuk aangegeven, is het eenvoudig gebleken het gemaakte interactie model, en dus de benodigde interacties, te implementeren tussen de Software Agents met behulp van de mogelijkheden van de JACK Software Toolkit. Het meest veelbelovende onderdeel van JACK is het onderdeel MetaLevel Reasoning. De potentie van dit onderdeel is groot, hoewel er in dit onderzoek wegens tijdsdruk maar een beperkte ervaring mee is opgedaan. Het is een onderdeel dat al goed uitgewerkt lijkt te zijn, door de vele mogelijkheden van planselectie en door de potentiele kracht die er van het combineren van deze mogelijkheden lijkt uit te gaan. Het is een onderdeel dat op dit moment al goed toepasbaar is en het zal nog meer dan in dit onderzoek het geval is, zijn meerwaarde in dynamische processen kunnen tonen. Het succesvol afhandelen van dynamische processen vereist nog meer flexibiliteit voor wat betreft run-time redenatie over planselectie dan dat dit bij statische processen het geval is, omdat de omgeving bij dynamische processen in meerdere mate onderhevig is aan veranderlijke factoren. Deze omgang met veranderende factoren in de omgeving kan succesvol worden aangepakt met Meta-Level Reasoning. Veruit de meeste mogelijkheden van de onderdelen waaruit de JACK Agent Programmeertaal is opgebouwd zijn goed bevallen, op de mogelijkheden van de Beliefset na. De kracht van de Beliefset zit vooral in de extra mogelijkheden die er zijn vanwege de integratie met de JACK ontwikkelomgeving en het feit dat het een integraal onderdeel is van de JACK Agent Taal. Deze voordelen uiten zich voornamelijk op de volgende vlakken: • De mogelijkheid om automatisch events te laten opkomen wanneer er veranderingen zijn gemaakt op een beliefset. • De keuze uit ’Open World’ en ’Closed World’ semantiek. Closed World beliefsets hebben als aanname dat als er een tuple niet aanwezig is, het belief dat deze tuple representeert onwaar (false) is, terwijl Open World beliefsets voor niet aanwezige tuples de extra optie ’onbekend’ kennen.

50

5.3 Het aspect Intelligentie

Software Agents

• Het gebruiksgemak vanwege de aanwezigheid en aanpasbaarheid van de beliefset binnen de JACK ontwikkelomgeving. Tijdens het gebruik van de Beliefset (zie 3.5.1) in dit onderzoek is gestuit op enkele beperkingen van dit onderdeel binnen de JACK Agent Taal. De Beliefset van JACK wordt op dit moment nog ongeschikt geacht voor het gebruik van grote hoeveelheden data met complexe koppelingen, vanwege de beperkte mogelijkheden om relationele verbanden intern en tussen andere Beliefsets onderling, aan te geven. Tijdens de voorbereidende en globale ontwerpfase van dit onderzoek ging het oorspronkelijke plan uit van een Agent ’Beoordelaar’ die intensiever en gecompliceerder om moest gaan met zijn Beliefset(s) dan uiteindelijk mogelijk is gebleken. Bijvoorbeeld het implementeren van zogenaamde grenswaarden in een Beliefset of Plan bleek een (voor het tijdsbestek van dit onderzoek) dusdanige opgave met de beperkte Beliefsetmogelijkheden, dat hiervan is afgezien. Met grenswaarden wordt hier bijvoorbeeld een afwijzing van alle auto’s ouder dan dertig jaar bedoeld. Dit gezegd hebbende lijkt een mogelijke koppeling met JACK en een extern database softwarepakket hier een eventuele oplossing voor, met als belangrijk nadeel dat bovengenoemde voordelen van een ge¨ıntegreerde Beliefset bij het koppelen met een extern database softwarepakket komen te vervallen. Deze mogelijke koppelingsmogelijkheid is echter niet nader door dit onderzoek vastgesteld. De JACK Agent Compiler en de JACK Agent Kernel hebben een positieve indruk achtergelaten. De Compiler is robuust en geeft begrijpelijke foutmeldingen, de Kernel heeft standaard de mogelijkheid om de JACK Software Agents gedistribueerd over een netwerk te laten samenwerken.

5.3

Het aspect Intelligentie

Intelligentie is een controversieel begrip zonder eenduidige definitie. De betekenis die in dit onderzoek aan het begrip intelligentie (van een Agent Systeem) is verbonden is er een van de mate van leermogelijkheden, redeneren en flexibiliteit van een Agent Systeem. Bij aanvang van dit onderzoek was de veronderstelling dat er een hoge mate van zogenaamde ’learning ability’ (ook wel: de mogelijkheid tot leren) standaard aanwezig is in Software Agents (zie 4.2). Dit blijkt een verkeerde veronderstelling. De mogelijkheid tot ’leren’ is niet meer of minder aanwezig dan in andere software systemen. Er is tot de conclusie gekomen dat de ’intelligentie’ van het ontwikkelde Agent Systeem voornamelijk in de mate van redeneren en selectie over mogelijke toepasbare aanpakken gezocht moet worden. Op dit vlak van redeneren en selecteren (het zogenaamde Meta-Level Reasoning, zie 3.5.1) is een Agent Software Systeem in hoge mate in staat om flexibiliteit ten tonele te voeren. Het is voor Software Agents mogelijk om te redeneren over de aanpak van een op51

5.3 Het aspect Intelligentie

Software Agents

komend Event (te beschouwen als een ontstaand probleem dat moet worden aangepakt). Afhankelijk van de staat van de omgeving waarin de Agents zich bevinden, de beliefs die de Agent op dat moment heeft en de aard van het Event (het probleem), besluit de Agent op dat moment over de aanpak van het probleem. De mogelijkheid tot ’leren’, hoewel op dit moment nog niet standaard aanwezig binnen Software Agents, kan eventueel wel toegevoegd worden in de vorm van een mogelijke koppeling van Agents met zogenaamde ’Neurale Netwerken’1 of ’Regel-gebaseerde Systemen’2 (ook wel: ’Rule-based Systems’). De mogelijkheid tot koppeling hiermee is in dit onderzoek niet nader bekeken. Neurale Netwerken zijn specifieke netwerken die opgebouwd worden uit knopen en de verbindingen daartussen. Neurale Netwerken ontlenen hun naam aan de mogelijke eigenschappen die ze delen met de netwerken zoals die zich mogelijk in onze hersenen bevinden, namelijk netwerken van neuronen (de knooppunten) verbonden met elkaar (het netwerk). Een specifieke eigenschap van Neurale Netwerken is dat ze de mogelijkheid bezitten om te ’leren’ in de zin van het zich eigen maken van de mogelijkheid om op een bepaalde input een output te leveren en als deze output onjuist blijkt, zichzelf zo aan te passen dat een volgende keer de correcte output ook tot de mogelijkheden behoort; een proces dat continue kan worden gemaakt binnen een neuraal netwerk. Een Regel-gebaseerd systeem bestaat uit een set productieregels, meestal van de vorm: ’ALS [conditie] DAN [actie]’ en een controle mechanisme dat zoekt naar regels om deze toe te passen in een gegeven situatie. Verschillende regels kunnen van toepassing zijn in een gegeven situatie en het controlemechanisme heeft een methode om ´e´en van de verschillende in competitie-met-elkaar-zijnde regels toe te passen. Wanneer een regel wordt toegepast (er is aan de [conditie] voldaan), wordt zijn [actie] gedeelte uitgevoerd. Dit [actie] gedeelte verandert meestal de situatie, zodat het weer mogelijk is voor nieuwe regels om van toepassing te worden op deze veranderde situatie.

1 2

een voorbeeld hiervan is het op JAVA gebaseerde Neurale Netwerk ’Joone’ [11] een voorbeeld hiervan is het open bron systeem ’JESS’ [10]

52

5.4 Antwoorden op de hoofdvragen

5.4

Software Agents

Antwoorden op de hoofdvragen

In dit onderzoek zijn antwoorden gegeven op de hoofd- en deelvragen zoals geformuleerd in 1.4. Op de vraag: ’Wat is Agent Software Technologie?’ is door hoofdstuk 2 een antwoord gegeven door uitleg te geven over het kernbegrip van Agent Software Technologie: ’Software Agents’. De vraag: ’Welke Methoden, Technieken en Tools kunnen worden toegepast voor de ontwikkeling van een op Agent Technologie gebaseerd prototype?’ is behandeld in hoofdstuk 3. In dit hoofdstuk is gekozen voor het gebruik van een methode voor procesbeschrijving, is een systeemontwerpmethodologie gekozen en gebruikt en aan de hand hiervan is een prototype van een Agent Software systeem ontwikkeld met behulp van de gekozen Agent Software Toolkit. De mogelijkheden en de werking van de gekozen methode, methodologie en tool zijn hierbij nader uitgelegd. Hoofdstuk 4 geeft vervolgens antwoord op de vraag hoe een op Agent Technologie gebaseerd prototype met behulp van deze Methoden, Technieken en Tools ontwikkeld kan worden. Dit gebeurt door een beschrijving van het gebruik van de gekozen methode, methodologie en tool te geven, en door te laten zien hoe het uiteindelijke prototype intern werkt. De vraag ’Wat zijn de ervaringen met het maken van een prototype?’ wordt beantwoord door aan de hand van de opgedane ervaringen met de gebruikte methode, methodologie en tool en de werkwijze bij gebruik van dezen een beschrijving te geven van de ervaren mogelijkheden en beperkingen hiervan. Dit hoofdstuk tenslotte, trekt conclusies uit de beschreven ervaringen met de gebruikte onderdelen. Hiermee is de vraag ’Welke conclusies kunnen uit de ervaringen afgeleid worden?’ beantwoord. Door bovenstaande volgorde van selectie, gebruik, ervaringen en conclusies toe te passen op de geselecteerde procesbeschrijvingsmethode, systeemontwikkelmethodologie en Agent Software Toolkit is er een prototype ontworpen op basis van een casus die ten grondslag aan dit onderzoek is ontwikkeld. Hiermee is een antwoord gegeven op de centrale vraag van dit onderzoek: ”Hoe kan een prototype op basis van Agent Software Technologie ontwikkeld worden en in hoeverre is dit toepasbaar op de software ontwikkeling binnen Reaal Verzekeringen?”

53

5.5 Toepasbaarheid van Agent Technologie voor Reaal Verzekeringen Software Agents

5.5

Toepasbaarheid van Agent Technologie voor Reaal Verzekeringen

Een dergelijk systeem gebaseerd op Agent Technologie als beschreven en ontworpen in dit onderzoek is toepasbaar binnen Reaal Verzekeringen, hoewel er een andere manier van kijken naar systeemontwerp en softwareontwikkeling voor nodig is. Het is waarschijnlijk mogelijk Agent Software Systemen zoals de hier toegepaste Agent Software Toolkit JACK te koppelen met bestaande systemen om zo een eerste aanzet te kunnen maken naar gebruik van Agent Technologie binnen Reaal Verzekeringen. Deze eventuele mogelijkheid tot koppeling is evenwel niet door dit onderzoek vastgesteld. Zoals reeds beschreven in 2.4 zijn Agent Systemen in staat om te gaan met (bestaande) gecentraliseerde systemen, alsook met de eigenlijke voorkeur voor gedecentraliseerde systemen. De verwachting van dit onderzoek op basis van de opgedane ervaring met een Agent Software Systeem is ook dat de meerwaarde en toepasbaarheid van Agent Technologie groter wordt als de vraag naar automatisering binnen een onderneming zoals Reaal Verzekeringen toeneemt. Des te meer er bijvoorbeeld gekoppeld moet worden met andere externe systemen en des te meer interactie er tussen deze verschillende systemen moet plaatsvinden, des te bruikbaarder zal de inzet van Software Agents hiervoor zijn. Wegens de nog beperkte ervaring met het grootschalig gebruik van Agent Technologie binnen (grote) organisaties is het nog onduidelijk in hoeverre de toepasbaarheid hiervan van meerwaarde is op de bestaande methoden van systeemontwerp en softwareontwikkeling binnen Reaal Verzekeringen. Duidelijk is echter wel, dat Agent Technologie een belangrijke mate van flexibiliteit en robuustheid kan leveren, die verder kan gaan dan de huidige systemen tot nu toe hebben kunnen laten zien.

54

Hoofdstuk 6

Aanbevelingen 6.1

Inleiding

In dit laatste hoofdstuk wordt ingegaan op de laatste hoofdvraag, die luidt: ’Welke aanbevelingen kunnen gedaan worden op basis van de conclusies?’. Op basis van de in het vorige hoofdstuk getrokken conclusies en de daarvoor beschreven ervaringen zullen nu enkele aanbevelingen voor Reaal Verzekeringen worden opgesteld. Er wordt hiervoor gekeken naar de verschillen in aanpak en mogelijkheden tussen Agent Technologie en de binnen Reaal Verzekeringen gebruikte vorm van object-geori¨enteerde softwareontwikkeling, genaamd ’Component Based Development’.

6.2 6.2.1

Aanbevelingen Aanbevelingen voor wat betreft gebruik van de Methode, Techniek en Tool

Bij het gebruik van DEMO als procesmodelleringsmethode in combinatie met Prometheus als systeemontwerptechniek is het aan te raden om slechts de eerste twee van de in totaal drie ontwerpstappen van de Prometheus methodologie te volgen in het ontwerpen van het Agent-systeem. Dit is vooral aan te raden bij gebruik van een relatief eenvoudige systeemprocesbeschrijving met eventueel veelvuldig gebruik van Beliefsets in het systeemontwerp. Bij het gebruik van de Agent Software Tookit JACK als ontwikkeltool voor Agent Software Systemen is het aan te raden om voor gebruik van grote datasets koppelingen, zo dit mogelijk is, op te zetten met bestaande Database Management Systemen (ook wel: DBMS). De bestaande Beliefsets als onderdeel van JACK zijn op dit moment nog ongeschikt voor grote hoeveelheden data.

55

6.2 Aanbevelingen

6.2.2

Software Agents

Aanbevelingen voor Reaal Verzekeringen

De huidige bestaande methode voor systeem en software-ontwikkeling binnen Reaal verzekeringen is die van ’Component Based Development’ [2], [12] (ook wel: CBD). CBD is een specifieke vorm van object-geori¨enteerde software ontwikkeling [8]. Het is een manier om het ontwerp, de constructie en de implementatie van software aan te pakken. Software wordt hierbij samengevoegd uit componenten afkomstig uit verschillende bronnen; de componenten op zich kunnen zijn ontwikkeld in verschillende programmeertalen en kunnen op verschillende platformen werken. Bij de methode van CBD is er een centrale aansturing van de onderliggende componenten aanwezig. CBD bestaat uit drie lagen (zie figuur 6.1): een Interactiecomponentenlaag, een Procescomponentenlaag en de Bedrijfscomponentenlaag. Een Interactiecomponent spreekt een Procescomponent uit de Procescomponentenlaag aan, die op zijn beurt een Bedrijfscomponent uit de Bedrijfscomponentenlaag aanstuurt, of wederom een Interactiecomponent. De Bedrijfscomponenten kunnen (koppelingen met) datasets bevatten. Alle taak-uitvoering gebeurt via zogenaamde ’services’, waarover elke component uit een van de drie lagen kan beschikken. Aansturing gebeurt door het hi¨erarchisch aanspreken van de services van de verschillende componenten via een communicatieprotocol.

Figuur 6.1: CBD: Centrale Aansturing Agent Technologie biedt een andere invalshoek, een nieuwe manier van software ontwerp- en ontwikkeling. Het is te bezien als het uitvoeren van CBD op een ander abstractieniveau; de procesmodellering wordt op een andere manier ingevuld. In plaats van de procesaansturing via een centrale component

56

6.2 Aanbevelingen

Software Agents

werkt Agent Technologie met decentrale Agents die elk hun eigen intenties, plannen, datasets en beliefs kunnen hebben (zie figuur 6.2). Hierdoor ontstaat een betere aansluiting met ’Real World Modelling’1 . Concepten die binnen Agent Technologie gebruikt worden, zoals Agent, Plan en Beliefset sluiten beter aan bij Real World Modelling dan CBD-begrippen zoals procescomponent, bedrijfscomponent en data, waarvan het niet snel duidelijk is welke aansluiting deze begrippen kennen in de ’echte wereld’2 .

Figuur 6.2: Agent Software Technologie: Decentrale Agents Naast software-ontwerp treden er ook verschillen op bij software-implementatie met gebruik van Agent Technologie (een Agent Software Toolkit) in vergelijking met een object-geori¨enteerde aanpak zoals CBD. Wat biedt de Agent Software Toolkit JACK nu meer of minder ten opzichte van CBD bij de ontwikkeling van software?

1 2

het modelleren naar model van de wereld zoals wij, mensen, die om ons heen ervaren de wereld zoals wij, mensen, die om ons heen ervaren

57

6.2 Aanbevelingen

Software Agents

Meer: • Een goede aansluiting in de omgang met dynamische processen (Krachtige mogelijkheden voor wat betreft scheduling. Krachtig redeneren over en selecteren op Plannen, kortom: Meta-Level Reasoning (zie 3.5.1)) • Een meer gedistribueerde en gedecentraliseerde manier van aansturing • Kennis versus data (door het gebruik van zogenaamde Beliefsets heeft data een betere aansluiting met de echte wereld (zie 3.5.1)) Minder: • Een standaard beperkte ondersteuning van grote datasets • Een minder hierarchische en centrale manier van aansturing Zoals uit dit verslag naar voren komt, kunnen Software Agents de rol van een object (en in CBD-termen: component) innemen, maar ze zijn ook tot meer dan dat in staat. Een Multi-Agent Systeem, bestaande uit meerdere interacterende Agents, biedt een gedecentraliseerde aanpak van systeemontwerp en -ontwikkeling. Beliefsets, interne en externe Events en de mogelijkheid om te redeneren over de selectie van een aanpak, alsmede de mogelijkheid om hiermee de modellering en ontwikkeling van dynamische systemen uit te voeren, zijn een greep uit de extra mogelijkheden die Agent Software Technologie kan bieden. Reaal Verzekeringen kan een eerste stap zetten richting de acceptatie van Agent Software Technologie door de mogelijkheden tot ontwikkeling van procescomponenten met behulp van Agent Software Technologie te onderzoeken. Daarna zijn er twee uitbreidingsrichtingen met deze procescomponenten mogelijk. Enerzijds kan overgegaan worden tot aansluiting van deze procescomponenten met behulp van koppeling3 via bedrijfsprocescomponenten met legacy-systemen4 . De andere richting met betrekking tot deze procescomponenten is een uitbreiding hiervan met nieuwe technologie¨en, zoals de eventuele koppeling aan een zelflerend systeem (zie 5.3). Een optie die echter nu al aanwezig is, is de uitbreiding van deze procescomponenten op basis van Agent Software Technologie met gebruik van reeds bestaande mogelijkheden die Software Agents nu al bieden, zoals bijvoorbeeld de inzet van Meta-Level Reasoning (zie 3.5.1). Aan Reaal Verzekeringen de keuze. Welke deze ook moge worden, Agent Software Technologie zal een serieuze optie worden voor software-ontwikkeling in de nabije toekomst! 3 4

de eventuele mogelijkheid tot koppeling is door dit onderzoek niet nader bekeken reeds bestaande systemen

58

Bijlage A

A.1

De casus

Onderdeel van Reaal verzekeringen is de ’direct writer’ ProteQ. Een ’direct writer’ is een online verzekeringstak waar een klant direct een offerte kan aanvragen of meteen een verzekering kan afsluiten. Deze biedt verzekeringsproducten aan de klant aan via het internet (http://www.proteq.nl). De klant kan op de website kiezen tussen een breed aanbod aan producten en diensten (informatie, offerte, premieberekening, aanvraag verzekering).

A.1.1

De processen

Op verzoek krijgt de klant rechtstreeks informatie, offertes, premieberekeningen via het internet. Hieronder worden de belangrijkste/omvangrijkste processen kort beschreven: Offreren Bij het aanvragen van de offerte of het aanvragen van een verzekering wordt gecontroleerd of het formulier volledig en juist is ingevuld. Tevens vindt daarnaast indien nodig een risicotechnische beoordeling plaats (bijvoorbeeld in het geval van een autoverzekering: Jaguars worden door ProteQ niet verzekerd). Een offerte kan vervolgens gebruikt worden als verzekeringsaanvraag (zie hieronder). Nadat de offerte aanvraag is ingevuld produceert het systeem een offerte en stelt deze via internet beschikbaar aan de klant. De offertegegevens worden in het systeem geregistreerd. Afsluiten verzekering Bij het aanvragen van een verzekering wordt gecontroleerd of het formulier volledig en juist is ingevuld. Tevens vindt daarnaast indien nodig een risicotechnische beoordeling plaats. Ook kan het zijn dat de klant een tweede formulier moet invullen met daarin een soort van betrouwbaarheidsverklaring (een verklaring dat er geen informatie is achtergehouden en dergelijke).

59

A.1 De casus

Software Agents

Indien nodig en toegestaan wordt een voorlopig bewijs van verzekering afgegeven. Wijze van aanvragen Verzekeringen kunnen op twee manieren worden aangevraagd: 1. Via een offerte. Een offerte kan gebruikt worden als aanvraagformulier voor een verzekering. De gegevens op de offerte komen overeen met de benodigde gegevens op de aanvraag. De klant kan dan vervolgens na uitprinten en ondertekening - de ondertekende offerte als aanvraag per post naar ProteQ toesturen. Omdat het systeem zelf de uitgegeven offertes bijhoudt en het aan de klant verstrekte offerte formulier een identificatie heeft (barcode), kan na ontvangst en scanning, het document gekoppeld worden aan de elektronische offerte (en tevens gearchiveerd). Nadat gecontroleerd is dat er aan de gegevens op de offerte niets veranderd is en de handtekening gezet is, kan vervolgens de verdere beoordeling en afhandeling van de verzekeringsaanvraag plaatsvinden. 2. Via een rechtsstreekse verzekeringsaanvraag. Indien gekozen wordt voor een verzekeringsaanvraag krijgt de klant een formulier te zien dat hij invult. Het systeem controleert of de klant het formulier volledig heeft ingevuld en voert een risicotechnische beoordeling uit. Vervolgens print de klant het formulier, voorziet deze van zijn handtekening en stuurt het formulier via de post op naar ProteQ. Omdat het systeem zelf de ingevulde verzekeringsaanvragen bijhoudt en de door de klant geprinte aanvraag een identificatie heeft (barcode), kan na ontvangst en scanning, het document gekoppeld worden aan de elektronische aanvraag (en tevens worden gearchiveerd). Nadat gecontroleerd is dat er aan de gegevens op de aanvraag niets veranderd is en de handtekening gezet is, kan vervolgens de verdere beoordeling en afhandeling van de verzekeringsaanvraag plaatsvinden. Verdere beoordeling Alvorens de aanvraag te accepteren, vindt verdere risicotechnische controle plaats. Deze controle wordt eerst door het systeem uitgevoerd en kan leiden tot drie situaties: 1. geaccepteerde aanvragen: hiervoor kan een polis worden aangemaakt 2. afgewezen aanvragen 3. aanvragen die door een acceptant nader beoordeeld moeten worden, omdat hiervoor voor ’het systeem’ de criteria ontbreken 60

A.1 De casus

Software Agents

Indien de derde situatie hierboven zich voordoet zal onze Agent Software aan de menselijke acceptant moeten proberen de criteria te achterhalen op basis waarvan deze uiteindelijk besloten heeft om af te wijzen of toe te staan en deze criteria toe te voegen aan zijn eigen acceptatiekader. (op dit moment is het zo dat alle via internet ontvangen aanvragen nog door een acceptant gezien moeten worden: maar dat is omdat het systeem niet ’geautoriseerd is’ om in een internet situatie ’zelf te accepteren’). Na de beoordeling vindt de definitie acceptatie of afwijzing van de aanvraag plaats. Het resultaat van deze beslissing kan leiden tot een actie waarin de klant van de beslissing op de hoogte wordt gebracht (per email). Bij een afwijzing gebeurt dit altijd. Bij acceptatie gebeurd dit alleen indien blijkt dat de tijd die nodig is om de klant een polis te verzenden langer zal zijn dan twee weken. In dat geval wordt tevens een voorlopig bewijs van verzekering gezonden. Opmaken en verzenden polis Vervolgens wordt aan de hand van de aanvraaggegevens een polis opgemaakt. Deze wordt, voorzien van een briefje, naar de klant gestuurd. Acceptatie klant Indien de klant niet meer reageert en begint met het betalen van de periodieke verzekeringspremie, wordt ervan uitgegaan dat de klant de polis heeft geaccepteerd. Beheer Nadat de polis verzonden is kan deze in beheer worden genomen. Het beheerproces zorgt voor: • beschikbaarstelling van informatie over polis en klant • uitvoeren van prolongaties (het periodiek innen van premies bij de klant) • initi¨eren van contractverlengingen

61

Bijlage B

B.1

De Systeem Specificatie Fase

B.1.1

Specificatie van de systeemdoelen

We willen een systeem maken dat het mogelijk maakt voor een klant om online een (autoverzekerings)offerte of autoverzekering af te sluiten, te wijzigen of te be¨eindigen. Het systeem moet al deze klantvragen kunnen afhandelen en meteen nagaan of de offerte of verzekeringsaanvraag zal worden gehonoreerd door het systeem. Het systeem heeft tot doel om de hoeveelheid ‘nader te beoordelen’ aanvragen te minimaliseren. Om dit te bereiken moet het systeem actief zijn in het beoordelen of toevoegen van criteria. Is honorering niet direct mogelijk, dan moet er een menselijke expert naar de klantaanvraag kijken en moet de klant op een later tijdstip hiervan op de hoogte worden gebracht. Het systeem verzorgt vervolgens de aanmaak van de polis en het beheer hiervan. Identificatie init¨ıele systeemdoelen We willen een systeem maken dat het mogelijk maakt voor een klant om (online) een (autoverzekerings)offerte of (auto)verzekering af te sluiten, te wijzigen of te be¨ eindigen. Het systeem moet al deze klantvragen kunnen afhandelen en meteen nagaan of de offerte of verzekeringsaanvraag zal worden gehonoreerd door het systeem. Het systeem heeft tot doel om de hoeveelheid ‘nader te beoordelen’ aanvragen te minimaliseren. Om dit te bereiken moet het systeem actief zijn in het beoordelen of toevoegen van criteria. Is honorering niet direct mogelijk , dan moet er een menselijke expert naar de klantaanvraag kijken en moet de klant op een later tijdstip hiervan op de hoogte worden gebracht. Het systeem verzorgt vervolgens de aanmaak van de polis en het beheer hiervan.

62

B.1 De Systeem Specificatie Fase

Software Agents

Afgeleide Systeemdoelen • (online) verzekeringssysteem • in eerste instantie alleen autoverzekeringen • offerte kunnen aanbieden • verzekering kunnen aanbieden en afhandelen • wijziging verzekering afhandelen • be¨eindiging verzekering afhandelen • klantvraag afhandeling • streven naar directe afhandeling door middel van directe communicatie over de honorering van de offerte en/of verzekering door de verzekeraar naar de klant toe • actieve beoordeling aan de hand van en/of toevoeging van de criteria • als directe afhandeling niet mogelijk is, dan menselijke expert inschakelen en klant zo spoedig mogelijk uitsluitsel geven • aanmaak polis afhandelen • beheer polis afhandelen

Systeemdoelen verfijning Fase (Online) verzekeringssysteem • mogelijkheden om direct (online) een verzekering af te sluiten In eerste instantie alleen autoverzekeringen • aanbod beperken tot autoverzekeringen Offerte kunnen aanbieden • offerte opstellen met klant • offerte direct beoordelen • gehonoreerde offerte aanbieden aan klant • (nog) niet gehonoreerde offerte communiceren naar klant

63

B.1 De Systeem Specificatie Fase

Software Agents

Verzekering kunnen aanbieden en afhandelen • verzekering opstellen met klant • verzekering direct beoordelen • gehonoreerde verzekering aanbieden aan klant • (nog) niet gehonoreerde verzekering communiceren naar klant Wijziging verzekering afhandelen • klant vragen om soort wijziging • verzekering direct beoordelen • gehonoreerde gewijzigde verzekering aanbieden aan klant • (nog) niet gehonoreerde wijziging communiceren naar klant Be¨eindiging verzekering afhandelen • verzekering be¨eindingen • be¨eindiging naar klant communiceren Klantvraag afhandeling • klant vragen wat hij wil doen (offerte, verzekering, wijzigen of be¨eindigen) Streven naar directe afhandeling door middel van directe communicatie over de honorering van de offerte en/of verzekering door de verzekeraar naar de klant toe • gehonoreerd verzoek direct naar klant communiceren • (nog) niet-gehonoreerd verzoek direct naar klant communiceren Actieve beoordeling aan de hand van en/of toevoeging van de criteria • criteria als leidraad nemen voor beoordeling • als afwijkende of nieuwe criteria bekend, deze toevoegen aan de huidige set van criteria

64

B.1 De Systeem Specificatie Fase

Software Agents

Als directe afhandeling niet mogelijk is, dan menselijke expert inschakelen en klant zo spoedig mogelijk uitsluitsel geven • als criteria niet duidelijk of aanwezig, dan hulp en kennis van menselijke expert inroepen • als afwijkende of nieuwe criteria bekend, deze toevoegen aan de huidige set van criteria Aanmaak polis afhandelen • gehonoreerde polis opstellen aan de hand van klantgegevens Beheer polis afhandelen • gehonoreerde polis in beheer nemen

B.1.2

Hergroeperen van de systeemdoelen

Offreren In eerste instantie alleen autoverzekeringen • aanbod beperken tot autoverzekeringen Offerte kunnen aanbieden • offerte opstellen met klant • offerte direct boordelen • gehonoreerde offerte aanbieden aan klant • (nog) niet gehonoreerde offerte communiceren naar klant Verzekeren Verzekering kunnen aanbieden en afhandelen • verzekering opstellen met klant • verzekering direct beoordelen • gehonoreerde verzekering aanbieden aan klant • (nog) niet gehonoreerde verzekering communiceren naar klant Aanmaak polis afhandelen • gehonoreerde polis opstellen aan de hand van klantgegevens

65

B.1 De Systeem Specificatie Fase

Software Agents

Beheren Beheer polis afhandelen • gehonoreerde polis in beheer nemen Service Wijziging verzekering afhandelen • klant vragen om soort wijziging • wijzigingsverzoek direct beoordelen • gehonoreerde gewijzigde verzekering aanbieden aan klant • (nog) niet gehonoreerde wijziging communiceren naar klant Be¨eindiging verzekering afhandelen • verzekering be¨eindingen • be¨eindiging naar klant communiceren Klant Interactie Klantvraag afhandeling • klant vragen wat hij wil doen (offerte, verzekering, wijzigen of be¨eindigen) • gehonoreerd verzoek direct naar klant communiceren • (nog) niet-gehonoreerd verzoek direct naar klant communiceren Beoordelen Actieve beoordeling aan de hand van en/of toevoeging van de criteria • criteria als leidraad nemen voor beoordeling • als afwijkende of nieuwe criteria bekend, deze toevoegen aan de huidige set van criteria Als directe afhandeling niet mogelijk is, dan menselijke expert inschakelen en klant zo spoedig mogelijk uitsluitsel geven • als criteria niet duidelijk of aanwezig, dan hulp en kennis van menselijke expert inroepen • als afwijkende of nieuwe criteria bekend, deze toevoegen aan de huidige set van criteria 66

B.1 De Systeem Specificatie Fase

B.1.3

Software Agents

Functionaliteiten

Functionaliteit beschrijvingen Offreren functionaliteit Beschrijving: Deze functionaliteit draagt zorg voor de interactie met de klant vanaf het moment dat deze klant te kennen heeft gegeven een offerte te willen hebben Goals: Maak offerte, lever offerte Acties: 1. Stel offerte op met klant 2. Controleer ingevuld offerteverzoek op juistheid en volledigheid 3. Laat offerte beoordelen 4. Stuur positief beoordeelde offerte aan klant 5. Communiceer negatief beoordeelde offerte naar klant Triggers: Offerteaanvraag, beoordeelde offerte, offerte is aangemaakt [INTERN]) Gebruikte informatie: Klantgegevens, offerteaanvraag, beoordelingsgegevens Geproduceerde informatie: Klantgegevens, offertegegevens, offerte, afgewezen offerteaanvraag Verzekeren functionaliteit Beschrijving: Deze functionaliteit draagt zorg voor de interactie met de klant vanaf het moment dat deze klant te kennen heeft gegeven een verzekering te willen hebben. Goals: Sluit polis, Stel polis op Acties: 1. Stel verzekering op met klant 2. Controleer ingevuld offerteverzoek op juistheid en volledigheid 3. Laat verzekering beoordelen 4. Stel een polis op 5. Stuur positief beoordeelde polis aan klant 6. Communiceer negatief beoordeelde verzekering naar klant Triggers: Verzekeringsaanvraag, beoordeelde verzekering, (maak polis [INTERN]) Gebruikte informatie: Klantgegevens, beoordelingsgegevens Geproduceerde informatie: Klantgegevens, polissen, afgewezen verzekeringsaanvraag

67

B.1 De Systeem Specificatie Fase

Software Agents

Beheren functionaliteit Beschrijving: Deze functionaliteit draagt zorg voor het beheer van de polis vanaf het moment dat de klant een verzekering heeft afgesloten, en de deactivatie ervan als de klant wil be¨eindigen Goals: Beheer een polis, deactiveer een polis Acties: 1. Neem de polis in beheer 2. Als de polis wordt be¨eindigd, deactiveer de polis dan, en neem hem uit beheer Triggers: Aanmaak polis, be¨eindiging polis, (beheer polis [INTERN]) Gebruikte informatie: polissen Geproduceerde informatie: polissen Service functionaliteit Beschrijving: Deze functionaliteit draagt zorg voor de interactie met de klant vanaf het moment dat deze klant te kennen heeft gegeven een polis te willen wijzigen of be¨eindigen. Goals: Wijzing een bestaande polis, be¨eindig een polis Acties: 1. Vraag klant om soort wijziging/be¨eindiging 2. Controleer ingevulde wijziging/be¨eindiging 3. Laat wijzigingsverzoek beoordelen 4. Maak gewijzigde polis op 5. Stuur (positief beoordeelde) polis aan klant 6. Beheer deze polis 7. Communiceer negatief beoordeelde wijzigingsaanvraag naar klant 8. Be¨eindig een polis 9. Communiceer be¨eindiging van polis naar klant Triggers: Wijzigingsaanvraag, beoordeeld wijzigingsverzoek, be¨eindigingsverzoek, (wijzig polis [INTERN]), (be¨eindig polis [INTERN]) Gebruikte informatie: Klantgegevens, wijzigingsaanvraag, beoordelingsgegevens Geproduceerde informatie: Klantgegevens, gewijzigde polis, afgewezen wijzigingsaanvraag, be¨eindigde polis

68

B.1 De Systeem Specificatie Fase

Software Agents

Klantinteractie Functionaliteit Beschrijving: Deze functionaliteit draagt zorg voor de interactie met de klant Goals: De communicatie met de klant naar diens tevredenheid afhandelen Acties: 1. Vraag klant wat hij wil doen 2. Communiceer resultaat van de actie van de verzekeraar direct naar de klant 3. Als er nog geen resultaat bekend is communiceer dit naar klant en neem op een later tijdstip weer contact met de klant op Triggers: Klantvraag Gebruikte informatie: Klantgegevens, klantvraag Geproduceerde informatie: geen Beoordelen Functionaliteit Beschrijving: Deze functionaliteit draagt zorg voor de beoordeling van een offerteaanvraag of verzekeringsaanvraag of –wijziging aan de hand van de vooraf bekende door de verzekeraar vastgelegde criteria Goals: Een positief of negatief beoordeelde offerte-, verzekerings- of wijzigingsaanvraag Acties: 1. Voer de beoordeling uit met de criteria als leidraad 2. Als er afwijkende of nieuwe criteria bekend zijn voeg deze toe aan de huidige set van criteria 3. Update de set van criteria, als er onduidelijkheid is tussen de klantaanvraag en de criteria die van toepassing zijn roep dan de hulp van een menselijke expert in Triggers: Offerteaanvraag, verzekeringsaanvraag, wijzigingsaanvraag, (beoordeeld [INTERN]) Gebruikte informatie: Klantgegevens, produktgegevens, set van criteria, ev. menselijke expert Geproduceerde informatie: Gehonoreerde offerte-, verzekerings- of wijzigingsaanvraag, afgewezen offerte, verzekerings- of wijzigingsaanvraag, e.v. aangepaste set van criteria

69

B.1 De Systeem Specificatie Fase

Functionaliteit Offreren Verzekeren Beheren Service Klantinteractie Beoordelen

Software Agents

Afkorting O V BH S K B

Tabel B.1: De Functionaliteiten met hun afkortingen

B.1.4

Scenario’s Nr. 1. 2. 3. 4. 5. 6. 7. 8.

Type Goal Goal Action Action Goal Other Percept Action

Omschrijving bepaal klantvraag lever offerte stel offerte op met klant controleer ingevulde offerte beoordeel offerte beoordeling afwachten beoordeling ontvangen bied offerte wel/niet aan

Functionaliteit K O O O B (O) (O) O

Tabel B.2: Offerte Aanvraag Scenario Nr. 1. 2. 3. 4. 5. 6. 7. 8.

Type Goal Goal Action Action Goal Other Percept Action

Omschrijving bepaal klantvraag maak polis stel verzekering op met klant controleer ingevulde verzekering beoordeel verzerkeringsaanvraag beoordeling afwachten beoordeling ontvangen bied polis wel/niet aan

Functionaliteit K V V V B (V) (V) V

Tabel B.3: Verzekeren aanvraag scenario

70

B.1 De Systeem Specificatie Fase

Nr. 1. 2. 3. 4. 5. 6. 7. 8.

Type Goal Goal Action Action Goal Other Percept Action

Omschrijving bepaal klantvraag wijzig een polis vraag klant om soort wijziging controleer ingevulde wijziging beoordeel wijzigingsaanvraag beoordeling afwachten beoordeling ontvangen bied polis wel/niet aan

Software Agents

Functionaliteit K S S S B (S) (S) S

Tabel B.4: Wijzigen Aanvraag Scenario Nr. 1. 2. 3. 4. 5. 6.

Type Goal Goal Action Action Action Action

Omschrijving bepaal klantvraag be¨eindig een polis vraag klant om soort wijziging controleer ingevulde be¨eindiging polis be¨eindigen comm. be¨eindig naar klant

Functionaliteit K S S S S S

Tabel B.5: Be¨eindigen aanvraag scenario Nr. 1. 2. 3. 4. 5. 6.

Type Goal Action Action Action Action Action

Omschrijving bepaal klantvraag offerteaanvraag doorsturen verzekeringsaanvraag doorsturen wijziginsaanvraag doorsturen be¨eindingsaanvraag doorsturen overige klantvraag zelf afhandelen

Functionaliteit K O V S S K

Tabel B.6: Klantinteractie scenario Nr. 1. 2. 3. 4. 5. 6. 7. 8. 9.

Type Goal Action Other Percept Action Other Percept Action Action

Omschrijving beoordeel aanvraag fin.beheerder risicobeoordeling risicobeoordeling afwachten risicobeoordeling ontvangen mens. Expert laten beoordelen mens. Beoordeling afwachten mens. Beoordeling ontvangen update set criteria aanvraag is gehonoreerd of niet Tabel B.7: Beoordelen Scenario

71

Functionaliteit B B (B) (B) B (B) (B) B B

B.1 De Systeem Specificatie Fase

B.1.5

Software Agents

Alternatieve scenario’s

Alternatief 1: De klant wil een andere verzekering dan een autoverzekering afsluiten Alternatief 2: De menselijke expert geeft aan dat de klantgegevens voortaan kunnen leiden tot een automatische honorering

B.1.6

Gebruikte percepts en actions

Percepts: Zie in de ’Percepts’ in bovenstaande scenario’s bij de kolom ’Type’ Actions: Zie in de ’Actions’ in bovenstaande scenario’s bij de kolom ’Type’

B.1.7

Interne data bronnen

Klantgegevens Offertegegevens Polissen Be¨eindige Polissen Beoordelingsgegevens Criteria/Voorwaarden

B.1.8

Externe data bronnen

Risicobeoordelingscriteria: BKR (bureau kredietregistratie) FISH (betrouwbaarheid/fraude in het verleden) RDW (eigenaarscontrole auto) Taxatiegegevens e.d.

72

Bijlage C

C.1 C.1.1

De Architectuur Ontwerp Fase Datakoppeling diagram

Figuur C.1: Het Data-model bij de casus

73

C.1 De Architectuur Ontwerp Fase

Naam Offerte Opsteller Verzekering Sluiter Beoordelaar Criteria Leveraar Polis Opsteller Beheerder Wijziger Be¨eindiger Informatie Verschaffer

Software Agents

Afkorting OO VS BO CL PO BH W BI IV

Tabel C.1: De negen Agents met hun afkortingen

C.1.2

Agent beschrijvingen

Naam Beschrijving Cardinaliteit Levensduur

Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Offerte Opsteller sluit offerte af, bied offerte aan instantiatie op offerteaanvraag klant afsluiten na uitloggen klant of lange periode van inactiviteit. (als klant al bekend: lees klantgegevens) sluit klantgegevens connectie, sluit offertegegevens connectie offreren klantgegevens klantgegevens, offertegegevens maak offerte, lever offerte offerteaanvraag, beoordeelde offerte offerteopmaak met klant, offertecontrole , offerteverzending naar klant, offerteweigering communicatie naar klant

Tabel C.2: Offerte Opsteller

74

C.1 De Architectuur Ontwerp Fase

Naam Beschrijving Cardinaliteit Levensduur

Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Software Agents

Verzekering Sluiter sluit verzekering af, stel polis op bied polis aan instantiatie op verzekeringsaanvraag klant. Afsluiten na uitloggen klant of lange periode van inactiviteit. (als klant al bekend: lees klantgegevens) , lees polissen, lees verzekeringsgegevens sluit klantgegevens connectie, sluit polissen connectie, sluit verzekeringsgegevens connectie verzekeren klantgegevens klantgegevens, polis, verzekeringsgegevens Sluit verzekering af, stel polis op verzekeringsaanvraag, beoordeelde verzekering verzekeringsopmaak met klant, polisopmaak , polisverzending naar klant, polisweigering communiceren naar klant

Tabel C.3: Verzekering Sluiter

Naam Beschrijving Cardinaliteit Levensduur Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Beheerder beheer bestaande polissen , deactiveer be¨eindigde polissen permanent lees polissen sluit polissen connectie beheren polissen polissen beheer polis, deactiveer een polis aanmaak polis, be¨eindiging polis beheer polis, deactiveer polis

Tabel C.4: Beheerder

75

C.1 De Architectuur Ontwerp Fase

Naam Beschrijving Cardinaliteit Levensduur Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Software Agents

Wijziger wijzig een bestaande polis instantiatie op aanvraag poliswijziging afsluiten na afronding wijziging (als klant al bekend: lees klantgegevens) sluit klantgegevens connectie service klantgegevens, beoordelingsgegevens wijzig een polis wijzigingsaanvraag, beoordeeld wijzigingsverzoek ontdek welke wijziging klant wil doorvoeren , wijzig bestaande polis(sen) Tabel C.5: Wijziger

Naam Beschrijving Cardinaliteit Levensduur Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Be¨eindiger be¨eindig een bestaande polis instantiatie op aanvraag polisbe¨eindiging afsluiten na afronding be¨eindiging. (als klant al bekend: lees klantgegevens) ,open be¨eindigde polissen sluit klantgegevens connectie, sluit be¨eindigde polissen connectie service klantgegevens, beeindigde polissen be¨eindingde polissen be¨eindig een polis be¨eindigingsverzoek ontdek welke polis klant wil be¨eindigen , be¨eindig bestaande polis(sen)

Tabel C.6: Be¨eindiger

76

C.1 De Architectuur Ontwerp Fase

Naam Beschrijving Cardinaliteit Levensduur

Initialisatie

Afsluiting

Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Software Agents

Beoordelaar beoordeel aanvragen klant instantiatie op aanvraag offertebeoordeling , aanvraag verzekeringsbeoordeling, of aanvraag wijzigingsbeoordeling. Afsluiten na afronding beoordeling. (als klant al bekend: lees klantgegevens) , lees criteria/voorwaarden, lees risicobeoordelingscriteria sluit klantgegevens connectie, sluit criteria/voorwaarden connectie, sluit risicobeoordelingscriteria beoordelen klantgegevens, criteria/voorwaardengegevens , risicobeoordelingscriteria criteria/voorwaardengegevens beoordeel een aanvraag offerteaanvraag, verzekeringsaanvraag , wijzigingsaanvraag beoordelen aanvraag, inroepen hulp menselijke expert, updaten set criteria

Tabel C.7: Beoordelaar Naam Beschrijving

Cardinaliteit Levensduur

Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Criteria Leveraar beredeneer de criteria/voorwaarden verbonden aan een verzekeringsprodukt en lever extra criteria/voorwaarden instantiatie op beoordeling offerte of verzekering(swijziging). Afsluiten na afronding beoordeling. lees criteria/voorwaarden sluit criteria/voorwaarden connectie beoordelen criteria/voorwaardengegevens criteria/voorwaardengegevens lever extra criteria/voorwaarden beoordeling offerte of verzekering(swijziging) beredeneer over bestaande citeria/voorwaarden, lever extra criteria/voorwaarden inpasbaar in de bestaande set

Tabel C.8: Criteria Leveraar 77

C.1 De Architectuur Ontwerp Fase

Naam Beschrijving Cardinaliteit Levensduur Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Software Agents

Polis Opsteller stel nieuwe polis op instantiatie op gehonoreerde verzekering afsluiten na aanmaak polis ontvang gegevens van Verzekering Sluiter verzekeren klantgegevens, polissen stel een nieuwe polis op gehonoreerde verzekering stel polis op

Tabel C.9: Polis Opsteller

Naam Beschrijving Cardinaliteit Levensduur Initialisatie Afsluiting Inbegrepen functionaliteit Gebruikte gegevens Geproduceerde gegevens Goals Percepts Actions

Informatie Verschaffer stuur de vraag van een klant door naar de betreffende Agent permanent (als klant al bekend: lees klantgegevens) sluit klantgegevens connectie klantinteractie klantgegevens klantgegevens stuur klantvraag door klantvraag vraag de klant welke vraag hij of zij heeft

Tabel C.10: Informatie Verschaffer

78

C.1 De Architectuur Ontwerp Fase

C.1.3

Software Agents

Samengesteld scenario Nr. 1. 2. 3. 4. 5. 6. 7. 8.

Type Goal Goal Action Action Goal Other Percept Action

Omschrijving bepaal klantvraag lever offerte stel offerte op met klant controleer ingevulde offerte beoordeel offerte beoordeling afwachten beoordeling ontvangen bied offerte wel/niet aan

Agent K O O O B (O) (O) O

Tabel C.11: Offerte Aanvraag Scenario Nr. 1. 2. 3. 4. 5. 6. 7. 8. 9.

Type Goal Action Other Percept Action Other Percept Action Action

Omschrijving beoordeel aanvraag fin.beheerder risicobeoordeling risicobeoordeling afwachten risicobeoordeling ontvangen mens. Expert laten beoordelen mens. Beoordeling afwachten mens. Beoordeling ontvangen update set criteria aanvraag is gehonoreerd of niet

Tabel C.12: Beoordelen Scenario

79

Agent B B (B) (B) B (B) (B) B B

C.1 De Architectuur Ontwerp Fase

Nr. 0. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 29. 20.

Type Percept Goal Goal Action Action Action Goal Other Action Other Percept Action Action Other Percept Action Action Percept Action Action Action

Omschrijving klantvraag ontvangen bepaal klantvraag lever offerte stel offerteaanvraag op met klant controleer ingevulde offerteaanv comm.ingev.off.formulier beoordeel aanvraag beoordeling afwachten fin.beheerder risicobeoordeling risicobeoordeling afwachten risicobeoordeling ontvangen risicobeoordeling mens. expert laten beoordelen mens. beoordeling afwachten mens. beoordeling ontvangen update set criteria mens. beoordeling beoordeling ontvangen communiceer afwijzing stel offerte op bied offerte aan

Software Agents

Agent IV IV OO OO OO OO BO (OO) BO (BO) (BO) BO CL (BO) (BO) BO BO (OO) OO OO OO

Opt.Keuze

OPT

OPT

Tabel C.13: Offerte Aanvraag en Beoordeel Scenario

80

C.1 De Architectuur Ontwerp Fase

C.1.4

Software Agents

Interactie diagram

Figuur C.2: Het interactiediagram afgeleid van het Offerte Aanvraag en Beoordeel scenario

81

Bijlage D

D.1

De JDE met het prototype

82

D.1 De JDE met het prototype

Software Agents

Figuur D.1: De JDE met daarbinnen de JACK-onderdelen

83

D.1 De JDE met het prototype

Software Agents

Figuur D.2: De JDE met daarbinnen een Agent

84

D.1 De JDE met het prototype

Software Agents

Figuur D.3: De JDE met daarbinnen een Event

85

D.1 De JDE met het prototype

Software Agents

Figuur D.4: De JDE met daarbinnen een Plan

86

D.1 De JDE met het prototype

Software Agents

Figuur D.5: De JDE met daarbinnen een Beliefset

87

D.2 Een JACK programmacode-voorbeeld

D.2

Software Agents

Een JACK programmacode-voorbeeld

Figuur D.6: De JDE met daarbinnen een Plan-code venster

88

Bijlage E

E.1

Het prototype in werking

Figuur E.1: Het protoype vraagt de klant gegevens

89

E.1 Het prototype in werking

Software Agents

Figuur E.2: Het protoype laat de beoordeling zien

90

Bibliografie [1] Agent Oriented Software, The JACK Agent Software Programming Toolkit, http://www.agent-software.com, 2004 [2] M. Aoyama, New age of software development: How component-based software engineering changes the way of software development, In Proceedings of International Workshop on Component-Based Software Engineering, Kyoto, Japan, 1998 [3] B. Bauer, J.P. M¨ uller, J.J. Odell, Agent UML: A Formalism for Specifying Multiagent Interaction, Agent-Oriented Software Engineering, Paolo Ciancarini and Michael Wooldridge eds., Springer-Verlag, Berlin, pp. 91-103, 2001 [4] M.E. Bratman, Intentions, Plans, and Practical Reason, Harvard University Press, Cambridge (MA), 1987 [5] J.L.G. Dietz, Introductie tot DEMO / Een reis door Kabouterland, 1996 [6] J.L.G. Dietz, V.E. van Reijswoud, DEMO Modelling Handbook, vol. 1, ver. 2, 1999 [7] FIPA, FIPA Communicative Act Library Specification, http://www. fipa.org/specs/fipa00037/SC00037J.html, 2002 [8] G. Florijn, Distributie en Componenten, White Paper, Software Engineering Research Centre, 1998 [9] M. Georgeff, B. Pell, M. Pollack, M. Tambe, M. Wooldridge, The Belief-Desire-Intention model of Agency, in Intelligent Agents V: Agent Theories, Architectures, and Languages, 5th International Workshop, ATAL’98, Proceedings, Springer-Verlag, pp 1-10, 1999 [10] JESS, the Rule Engine for the JAVA Platform, http://herzberg.ca. sandia.gov/jess/, 2004 [11] Joone, the Java Object Oriented Neural Engine, http://www. jooneworld.com/, 2004

91

BIBLIOGRAFIE

Software Agents

[12] H. Lof, Inleiding CBD, Presentatie, 2000 [13] H. Lof, Software Agents, Verkenningen, 2003 [14] M. Luck, R.Ashri, M. D’Inverno, Agent Based Software Development, Artech House Publishers, London, 2004 [15] J.J. Odell ed., Agent Technology Green Paper, ver. 1, Agent Working Group OMG Document ec/2000-08-01, 2000 [16] J.J. Odell, Agent UML: What is It and Why Do I Care, Presentation to Net.ObjectDays 2003 and ER 2003, 2003 [17] J.J. Odell, Objects and Agents Compared, Journal of Object Technology, vol. 1, no. 1, pp. 41-53, 2002 [18] Sun Microsystems, The JAVA Programming Language, http://java. sun.com, 2004 [19] J.R. Wallace, Practical Reason, The Stanford Encyclopedia of Philosophy (Winter 2003 Edition), Edward N. Zalta ed., 2003 [20] M. Winikoff, L. Padgham, Developing Intelligent Agent Systems: A Practical Guide, http://www.cs.rmit.edu.au/agents/prometheus/, John Wiley and Sons Ltd, Melbourne, Australia, 2004 [21] M. Wooldridge, N. Jennings, Intelligent Agents: Theory and Practice, Knowledge Engineering Review, vol 10, no. 2, Cambridge University Press, 1995

92