Onderzoek naar toepassing van Agent Technologie binnen Reaal Verzekeringen

Onderzoek naar toepassing van Agent Technologie binnen Reaal Verzekeringen Alex Bongers alex.bongers@phil.uu.nl 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 één 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 één 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ëren. 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ënteerde 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ën 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 8 1.1 Aanleiding............................. 8 1.2 Onderzoeksdoelstelling...................... 9 1.3 Onderzoeksvraag......................... 9 1.4 Afgeleide hoofdvragen...................... 10 1.5 Indeling Scriptie......................... 11 2 Software Agents 12 2.1 Inleiding.............................. 12 2.2 Wat zijn Software Agents?.................... 12 2.3 BDI en Software Agents..................... 13 2.4 OO en Software Agents..................... 14 3 Methoden, Technieken en Tools 16 3.1 Inleiding.............................. 16 3.2 Selectie van de Methoden, Technieken en Tools........ 16 3.2.1 Waarom DEMO?..................... 16 3.2.2 Waarom Prometheus?.................. 17 3.2.3 Waarom JACK?..................... 17 3.3 Wat is DEMO?.......................... 18 3.3.1 Hoe werkt DEMO?.................... 18 3.3.2 De Kernpunten van DEMO............... 19 3.3.3 BDI en DEMO...................... 20 3.3.4 Actoren en Software Agents............... 20 3.4 Wat is Prometheus?....................... 21 3.4.1 Hoe werkt Prometheus?................. 21 3.5 Wat is JACK?.......................... 22 3.5.1 Hoe werkt JACK?.................... 23 3.6 Aansluitingen........................... 27 3.6.1 Aansluiting DEMO en Prometheus........... 27 3.6.2 Aansluiting Prometheus en JACK........... 28 5

INHOUDSOPGAVE Software Agents 4 Experiment 29 4.1 Inleiding.............................. 29 4.2 Casus............................... 29 4.3 Ontwerpbeslissingen....................... 30 4.4 Beschrijving............................ 31 4.4.1 Beschrijving van het DEMO-model........... 31 4.4.2 Beschrijving van Prometheus.............. 32 4.4.3 Beschrijving van het prototype............. 41 4.5 Ervaringen............................ 44 4.5.1 Ervaringen met DEMO................. 44 4.5.2 Ervaringen met Prometheus............... 44 4.5.3 Ervaringen met JACK.................. 45 5 Conclusie 48 5.1 Inleiding.............................. 48 5.2 Conclusies............................. 48 5.2.1 Conclusie DEMO..................... 48 5.2.2 Conclusie Prometheus.................. 49 5.2.3 Conclusie JACK..................... 49 5.3 Het aspect Intelligentie...................... 51 5.4 Antwoorden op de hoofdvragen................. 53 5.5 Toepasbaarheid van Agent Technologie voor Reaal Verzekeringen............................... 54 6 Aanbevelingen 55 6.1 Inleiding.............................. 55 6.2 Aanbevelingen.......................... 55 6.2.1 Aanbevelingen voor wat betreft gebruik van de Methode, Techniek en Tool................. 55 6.2.2 Aanbevelingen voor Reaal Verzekeringen........ 56 A 59 A.1 De casus.............................. 59 A.1.1 De processen....................... 59 B 62 B.1 De Systeem Specificatie Fase.................. 62 B.1.1 Specificatie van de systeemdoelen............ 62 B.1.2 Hergroeperen van de systeemdoelen.......... 65 B.1.3 Functionaliteiten..................... 67 B.1.4 Scenario s......................... 70 B.1.5 Alternatieve scenario s.................. 72 B.1.6 Gebruikte percepts en actions.............. 72 B.1.7 Interne data bronnen................... 72 6

INHOUDSOPGAVE Software Agents B.1.8 Externe data bronnen.................. 72 C 73 C.1 De Architectuur Ontwerp Fase................. 73 C.1.1 Datakoppeling diagram................. 73 C.1.2 Agent beschrijvingen................... 74 C.1.3 Samengesteld scenario.................. 79 C.1.4 Interactie diagram.................... 81 D 82 D.1 De JDE met het prototype................... 82 D.2 Een JACK programmacode-voorbeeld............. 88 E 89 E.1 Het prototype in werking.................... 89 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 Systemen 1 ) 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 Agents 2. In de verkenning wordt aanbevolen om voorlopig geen investeringen in 1 Multi-Agent Systemen zijn systemen die gebruik maken van meerdere Software Agents 2 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 prototype 3 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 Software Agents 1.4 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 Methodologie 4 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 Software Agents 1.5 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ënteerde 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ënteerde 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 intelligentie 1 [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 computationele 2 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 één 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 één 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 Toolkit 3 ) 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 formele 4 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ënteerde 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 én gecentraliseerd (de controle van het proces ligt op één plek) én gedecentraliseerd (gedistribueerde controle, de controle over het proces is verspreid over de verschillende Agents) te werk gaan, terwijl object-georiënteerde 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ënteerde talen worden objecten gecreëerd door een klasse 5, eenmaal gecreëerd kan dit object niet meer van klasse veranderen. Agents bieden een meer flexibele aanpak. Een specifieke Agent kan tegelijkertijd, of 4 gebaseerd op Logica 5 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 één 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ënteerde talen bieden geen directe ondersteuning voor deze domein-specifieke mechanismen die vereist zijn voor Agent-gebaseerde omgevingen. De enkelvoudige klasse aanpak is efficiënt 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ënteerde 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-systeem 6 te bouwen dat ook gebruikt wordt in object-georiënteerde 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 casus 1 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 Actoren 2. Met 1 zie bijlage A 2 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ën) ontwikkeld. Enkele van de meest bekende Agent Modellering Talen zijn MESSAGE, TROPOS, MaSE en Prometheus [14]. Veel van de genoemde methodologiën 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 ontwikkelomgeving 3 ), 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ëren 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ördinatie-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ële productie-acties 2. Informationele productie-acties 3. Documentele productie-acties 18

3.3 Wat is DEMO? Software Agents Essentiële acties beschrijven de kern van de business van een organisatie. Informationele acties betreft het verspreiden van kennis (over essentiële acties) en het afleiden van nieuwe kennis uit bestaande. Documentele acties beschrijven het opslaan, transporteren, kopiëren et cetera van de documenten waarin die kennis is vastgelegd. Coördinatie-acties Door het verrichten van coördinatie-acties gaan Actoren verplichtingen over productie-acties aan en komen ze die na. Voorbeelden van coördinatie-acties zijn het verzoeken en het beloven (van productie-acties). Productie-acties en coördinatie-acties zijn de atomen van de bedrijfsprocessen in een organisatie. Ze komen altijd en alléén 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