Extending UML for Agents and Goals A Tutorial

Extending UML for Agents and Goals: A Tutorial on Multi-Agent Systems Manuel Kolp University of Louvain

Why Agent-Oriented Software? l Next generation software engineering will have to support open, dynamic architectures where components can accomplish tasks in a variety of operating environments. l Consider application areas such as e. Business, application service provision, pervasive or P 2 P computing. l These all call for software components that find and compose services dynamically, establish/drop partnerships with other components and operate under a broad range of conditions. l Learning, planning, communication and negotiation become essential features for such software components. . agents! Manuel Kolp 2

What is an Agent? l A person, an organization, certain kinds of software. – Autonomous, pro-active, goal, knowledge oriented, adaptative – with/in its environment Intelligence l An agent has beliefs, goals (desires), intentions. l Agents are situated, autonomous, flexible, and social. l Human/organizational agents can’t be prescribed, they can only be partially described. Manuel Kolp 3

Why Worry About Human/Organizational Agents? l Because their goals lead to software requirements, and these influence the design of a software system. l Note the role of human/organizational agents in OOA, e. g. , use cases. l Also note the role of agents in up-and-coming requirements engineering techniques such as KAOS [Dardenne 93]. l In KAOS, requirements analysis begins with a set of goals; these are analysed/decomposed to simpler goals which either lead to software requirements, or are delegated to external agents. Manuel Kolp 4

A Social Computing Paradigm l Software Agent – Implemented with/in software technologies – Environment : humans, machines, other agents, platforms. – To be completely specified during implementation. l Beliefs correspond to (object) state, intentions constitute a runtime concept. For design-time, the interesting new concept agents have that objects don’t have is. . . goals! Multi-agent system: societies of individuals to achieve particular, possible common goals. Manuel Kolp 5

Agent: Individual Characteristics l Autonomous – Without direct external intervention. Without l Mobile – To transport itself from one environment to another. transport l Unpredictable – To act in not predictable ways, even if the initial conditions are known not predictable l Rugged – To deal with errors and incomplete data robustly. errors robustly Manuel Kolp 6

Agent: Social Characteristics l Interactive – To communicate with the environment and other agents. environment l Adaptive – capable of responding to other agents and/or its environment. responding environment l Sociable – To act in as a representative of some entity. representative l Proactive – goal-oriented, purposeful. Does not simply react to the environment. goal-oriented Manuel Kolp 7

Agent: Social Characteristics l Coordinative – To perform activities in a shared environment with other agents. shared l Cooperative – To coordinate with other agents to achieve a common purpose; common succeed or fail together l Competitive – Antisocial Agent : maximizes his absolute profit; eliminates Antisocial Agent conccurrents at a minimal cost Manuel Kolp 8

Agent: Rationale Characteristics l Intelligence for Agent – Knowledge (B. R. I. D. G. : beliefs, resources, intentions, desires, goals) Knowledge – Communicate with symbolic language symbolic l The Belief-Desire-Intention (BDI) agent model from philosophy and The Belief-Desire-Intention philosophy cognitive science. cognitive –An agent has beliefs about the world and desires to satisfy, driving it beliefs desires to form intentions to act. intentions –Mental states of an agent. Mental states Manuel Kolp 9

Inside the BDI Model Human Beliefs - perceived understanding of the world Goals or desires Agent - Belief, Desire, Intentions Beliefs - database of perceived world knowledge Goals or Desires Execution Engine Intentions -executing plans Accumulated behaviours Manuel Kolp Pre-compiled plans 10

Example: Agents at Work Goal/Desire/Need Contextual Beliefs Manuel Kolp New Beliefs/Facts Running Plan/Intention 11

Scenario for Office Supplying l A company that needs to order paper supplies enlist agents to monitor the quantity and usage patterns of monitor patterns paper in the company, launching buying agents when supplies are low. l Buying agents automatically collect information on collect vendors and products that may fit the needs of the fit needs company, evaluate the offerings, make a decision on decision which merchants and products to investigate, negotiate the transactions with the merchants, and negotiate finally place orders and make automated payments. orders automated In Pattie Maes, Robert H. Guttman, and Alexandros G. Moukas, Agents that buy and sell, Communications ACM, March 1999/Vol. 42, No. 3 that buy and sell Manuel Kolp 12

Agents @ Microsoft (. NET project) l Après vingt ans, les ordinateurs personnels ont été rejoints par une myriade d'engins - les ordinateurs de poche, les téléphones portables, les messagers d'engins sans fil. . . - que Microsoft se fait fort d'interconnecter. l L'idée force : ramener cette galaxie de gadgets sous un seul contrôle - celui du contrôle consommateur individuel, qui pourra décliner à sa guise ses « rôles » (vie individuel rôles privée, vie professionnelle) en un seul système. Les premiers exemples : passer système d'avance sa commande type à sa chaîne de restauration rapide favorite pour éviter la file, conjuguer les fichiers du calendrier personnel et du carnet d'adresses téléphoniques pour faire suivre, selon un ordre de priorité à choisir, certains appels téléphoniques quand on n'est pas à son poste habituel. l Chaque individu contrôlera souverainement l'usage de ses données personnelles, promet Dan'l Lewin (chargé du projet «. NET » , la plate-forme NET d'interconnexion universelle de Microsoft). Le Soir 11/08/2001 and Bill Gates, Keynotes Address, 17 th International Joint Conference Gates Address on Artificial Intelligence August 2001, Seattle, USA Manuel Kolp 13

Mobile Agent on the Internet Manuel Kolp 14

User Assistance l The animated help characters in Microsoft Office products. l Use bayesean networks to analyze and predict possible topics that the predict possible topics user may need help with. – Bill Gates, Keynotes Address, 17 th Bill Gates Keynotes Address International Joint Conference on Artificial Intelligence August 2001, Seattle, USA Manuel Kolp 15

Foreign Exchange Market L'euro a également succombé aux programmes de vente automatiques des institutions financières: les grands acteurs du marché des changes (banques, changes fonds, etc. ) utilisent en effet des programmes dits “agents intelligents” qui déclenchent automatiquement un ordre de vente dans certaines conditions. Il semble conditions que ces programmes se soient déclenchés ce mercredi matin à Londres après que l'euro a touché plusieurs fois le seuil des 88, 51 cents , explique un cambiste allemand. – from Le Soir 09/07/2000 Manuel Kolp 16

Searching the Web : bots, engines, crawler The original Lycos spiders have evolved into a multiagent system of cooperating components that can visit and analyze more than 10, 000 Web pages each day. – In Richard Green and Sangam Pant, Multiagent Data Collection in Lycos, Communication of the ACM, March 1999/Vol. 42, No. 3 l Manuel Kolp Alltheweb, Altavista, Yahoo, Hotbot, Google 17

Searching the Web : bots, engines, crawler Manuel Kolp 18

Technical E-Support Date: Sat, 17 Feb 2001 23: 32: 27 -0500 From: dellmobile@dell. com To: mkolp@cs. toronto. edu Subject: #3 OT##01# Case #: 200121712300 - Monitor #APTX# X-Mailer: Aptex Software Select. Response X-MIME-Autoconverted: from 8 bit to quoted-printable by smtp 6. us. dell. com Thank you for contacting Dell US e. Support Services, This first response to your request will be conducted by an artificial intelligence tool artificial intelligence designed to provide you with the fastest possible quality support. If the Automated quality support Response does not answer your question, please look at the bottom of this email for further instructions on how to contact us about this issue. ((SRMACSR video: Video. Cards_Mob 01042001 SRMACSR)) SRMACSR video: Video. Cards_Mob 01042001 SRMACSR ((SRCATSR D_M. Bad. Pixel SRCATSR)) SRCATSR --- Dell Automated Technical Assistant response --Manuel Kolp 19

Pricebots l Dynamically set prices of products in a dynamic environment l Intention: Maximize long term profit Intention l Desires: Optimize local price Desires l Beliefs: Beliefs – Competitor prices BDI Model – Buyer behavior model – Competitor behavior model l Barnesandnoble. com, Chapters. com, Borders. com Manuel Kolp 20

Pricebots Manuel Kolp 21

Bargain Finders Capture shoppers’ preferences for price and a limited set of products Returns a list of product offerings differentiated by price. Jango. exite. com Manuel Kolp 22

Recommendations/Notifications (E-mail) Manuel Kolp 23

Key Concepts for E-commerce Agents Customer Agent Business User Profile Manager E-mail Notifications Zip, age, gender, purchase history, preferences, interests, needs, … Match Profile with Catalog to offer personalized experience Catalog Item 1 Item 2 Item 3 … Predictions on profile & «business intelligence» , (data-mining, CRM) OR Match Extract Information from multiple sites about products user wants Manuel Kolp 24

Other Agents for Organizations Management – Nomadic Computing (SUN, Lotus, Oracle) – Datawarehouse, Data Mining, CRM (Oracle, Informix) – Call Centers, Internet Routing (Bell, AT&T, CISCO, Juniper) – Knowledge Management (Ernst & Young) – Information Management (Digital) – Groupware, Workflow (Lotus, IBM) – Personal schedule management (Qualcomm) – E-trading (Bank of Montreal) – E-Brokering (Amazon, Barnes & Noble, Ebay, Andersen Consulting) – Role and personnel management (People. Soft) – Enterprise Resource Planning (Baan) – Peer 2 Peer (Napster, Gnutella Protocols) – … Manuel Kolp 25

Life Cycle l 1. Early requirements: understanding a problem by studying an organizational setting; output : organizational model with relevant actors, their goals and inter-dependencies l 2. Late requirements: system-to-be described within its operational environment, with relevant functions and qualities l 3. Architectural design: global architecture defined in terms of interconnected subsystems l 4. Detailed design: behavior of each architectural component defined in detail l 5. Implementation: system implementation carried out consistently with detailed design Manuel Kolp 26

The Tropos Project i* Agent-oriented programming TROPOS GAIA KAOS Z AUML !! The GAP !! UML, Catalysis & Co. l te ra rly s u La ts Ea nt ct ign te e en hi des m m c ire Ar u u eq eq r r Manuel Kolp led i ta ign De es d n io t ta en lem p Im 27

The TROPOS Ontologies l (Formal) Specification of a conceptualization (= conceptual model) Formal conceptual model – Social -- the actors, their needs, obligations, capabilities Social actors – Intentional -- the relevant goals, how do they interrelate? Intentional goals How are they being met, and by whom? – Communicational -- how the actors dialogue with each other? Communicational dialogue – Process-oriented -- the relevant business processes Process-oriented processes – Structural -- the actors structuredwith their inter-relationships Structural Manuel Kolp 28

Example: A User 2 On-line Buying System l Media taxonomy – on-line catalog – DBMS l E-Shopping Cart – Check In – Buying – Check Out l Search Engine – catalog browser – Keywords – full-text l Billing Processor – $ transactions – orders l Multimedia – description – samples Manuel Kolp 29

1. Early Requirements Analysis with TROPOS l Understanding the problem by studying an organizational setting; organizational l Organizational model with relevant actors and respective goals. Organizational model l i* [Yu 95] l Running Example: A Business to Consumer System Goals are relative, fulfillment is collaborative !! Manuel Kolp 30

Insurance Company Maximize profits Customer Car repaired Manuel Kolp Insurance Company Customer happy Settle claim 31

The Strategic Dependency Model l Focus on social dependencies among actors rather than only social dependencies actor goals, actions etc. l Actors have goals, need tasks be carried out and resources to goals tasks resources be made available; l Dependencies define social & intentional relationships among social & intentional relationships actors, where one actor depends on another to satisfy a goal or satisfice a softgoal, execute a process or furnish a resource; l Dependencies can be goal dependencies, task dependencies, resource dependencies or soft goal dependencies l Softgoals are distinguished from goals because they do not Softgoals have a formal definition, and are amenable to a different (more qualitative) kind of analysis (not well-defined). qualitative Manuel Kolp 32

Four Kinds of Social Dependencies Goal Task Manuel Kolp Resource Softgoal … Social Dependency 33

An Insurance Example D Customer happy Appraise damages D D Fair repair appraisal D D Resource Task Secure employment D D Goal Minimize repairs D D Continue business D Insurance Company D D Owner Repairs covered D D D Manuel Kolp Premium payment D D Maximize estimate D D D Pay repairs D D Car repaired D D Body Shop Claims payout D Softgoal Appraiser 34

Tasks vs Goals l Tasks are processes actors perform to fulfill goals. l In general, there will be many alternative tasks (possibly by different actors) for fulfilling a goal. l When actors are assigned goals, they are (or, ought to be) able to fulfil them by carrying out one or more tasks, and/or through delegation to other actors. l A delegated goal may not be achievable by the dependee actor (who is supposed to achieve it); in this case, the depender actor has to look for an alternative solution. Manuel Kolp 35

Softgoals l Functional goals, such as “Handle Customers Orders” : well defined goals in the sense that they admit a formal definition. l Not all goals are functional. l “Increase Market Share”, “Happy Customers” or “Easily Adaptable System” : qualities that the software system should adhere to. l Non functional Goals: softgoals, “fuzzy goals” (clouds) with no clearcut softgoals criteria for satisfaction; l Hence softgoals are satisficed, not satisfied. satisficed l How well the system accomplishes its functions Manuel Kolp 36

Extending UML using Stereotypes <> <> Media Items <> Consult Catalogue <> <> Buy Media Items Customer <> Continuous Supply Media Shop <> <> <> <> <

Formal Analysis and Model-Checking Entity Media. Item Entity Attribute constant item. Type : Item. Type, price : Amount, In. Stock : Boolean Attribute constant Dependency Buy. Media. Items Dependency Type goal Type Mode achieve Mode Depender Customer Dependee Media. Retailer Dependee Attribute constant item : Media. Item Attribute Fulfillment condition for depender media : Media. Item(self. item. type media. type item. price media. price) [the customer expects to get the best price for the type of item] Dependency Continuous. Supply Dependency Type goal Type Mode maintain Mode Depender Media. Retailer Dependee Media. Supplier Dependee Attribute constant item : Media. Item constant Fulfillment condition for depender buy : Buy. Item(Just. Created(buy) buy. item. in. Stock) [the media retailer expects to get items in stock as soon as someone is interested to buy them] Manuel Kolp 38

Dynamics Specification Proc check. Out. Catalogue. Consultation(catalogue) Proc < catalogue : failed(catalogue) close. Catalogue(catalogue) > ( < cancel. Consultation reinitialize. Catalogue(catalogue) > || < timeout 90 reinitialize. Catalogue(catalogue) > ) < catalogue : In. Process. Consultation Stop. Consultation close. Catalogue(catalogue) > End. Proc Manuel Kolp 39

Strategic Rationale Model l Graph with four main types of nodes -- goal, task, resource, and softgoal -- and two main types of links -- means-ends links and process decomposition links. l Describes the criteria in terms of which each actor selects among alternative dependency configurations. l Means-ends relate goals to tasks that can satisfy these goals: “Given goal (end) G, how can I decompose it (means) in order to find a way to fulfill it”. l Task decomposition links relate tasks to other component tasks l Tasks can also be decomposed to goals. Manuel Kolp 40

Functional Alternatives: Insurance Example alternative one Verify policy Handle claim centrally Prepare offer Manuel Kolp Agent handles claim Claim be settled alternative three alternative two Body Shop handles claim 41

Strategic Rationale Model: Insurance Claims Handling Actor boundary Get accident info Handle claim Verify policy Settle claim Prepare offer Determine fault Whose fault? Settlement cost? Determine cost to settle D D D Manuel Kolp Minimal repairs D D Witness Appraise damage D D Doctor D D D Injury info D D Sufficient treatment D D Police Accident info Insurance Company Appraiser 42

Rationale View: E-business example Manuel Kolp 43

2. Late Requirements (Strategic Relationships) ”Organizational Map” Functions and qualities for the system within its environment Manuel Kolp 44

Late Requirements - System Rationale Model ”Rationale Map” Medi@ Manuel Kolp 45

Goal-Oriented Analysis l Goal-oriented analysis focuses on early requirements analysis phases, when alternatives are being explored and evaluated. l During goal-oriented analysis, we start with initial goals such as “Higher profits”, “Faster time-to-market”, “Schedule meeting”, “Easily maintainable system”, “Good performance” etc. and keep decomposing them until we have reduced them to alternative collections of design decisions each satisfying the initial goals. l Initial goals may be organization oriented; they may also be conflicting, so the analysis must facilitate the discovery of tradeoffs and the search of the full space of alternatives, rather than a subset. Manuel Kolp 46

The NFR framework : Building Goals Models l To arrive at a more qualitative framework for modeling goals, we also need to extend the set of relationships between goals beyond means-ends links: l • + (++): one goal contributes positively (very positively) towards the fulfillment of another goal; l • - (--) one goal contributes negatively (very negatively) towards the fulfillment of another goal; l sub: one goal subsumes another, I. e. , if the first goal is fulfilled, so is the second; l With these enhancements, we can build goal models which might be useful for strategic decision analysis Manuel Kolp 47

Minimal effort Collection effort Rapidity of Order Minimal Interaction Minimal conflicts Matching effort - - Availability + + - ++ … Goal Analysis Handle Customer Order Collect orders ++ By person By system Selected Items Manually Automatically By phone By Fax Manuel Kolp Have updated invoices With Shopping Cart 48

Leaving Goals Dependencies is a Novelty l Goals and Softgoals generally operationalized/metricized during Late Requirements (e. g. KAOS – van Lamsweerde 93) l Ex. : Security operationalized by interfaces which minimize input/output or access restriction to sensitive information. l Steps through which goals are to be fulfilled are frozen in the requirements l Systems fragile and less reusable. l Whenever there is a need for flexibility, reusability, modularity Manuel Kolp 49

From i* to Agent Concepts Manuel Kolp 50

3. Architectural Design l Architecture in terms of interconnected social components. social l 3 levels – 1 Macro level : Organizational Styles (Organization Theory) level • Vertical Integration, Pyramid, Joint Venture, Structure in 5, Bidding, Hierarchical Contracting, Co-optation, Takeover – 2 Micro level : Patterns (Agent, COOPIS Community) level Agent, COOPIS • Broker, Matchmaker, Contract-Net, Mediator, Monitor, Embassy, Wrapper, Master-Slave, . . . – 3 Atomic : Social and intentional concepts – i* Manuel Kolp 51

Organization Styles for Architecture l Organization Theory, Strategic Alliances, … l Mintzberg, Scott, Galbraith, … Mintzberg l Studies alternatives and models for (business) organizations models l Model the coordination of business stakeholders -- individuals, coordination physical or social systems -- to achieve common (business) goals Manuel Kolp 52

Structure in 5 l Operational core : basic operations -- the input, processing, core basic operations output associated with running the organization. l Strategic apex : executive, strategic decisions. apex strategic l Support : Assists the operation core for non-operational services Support Assists outside the basic flow of operational procedures. l Technostructure : standardizes the behavior of other Technostructure standardizes components, help the system adapt to its environment. adapt l Middle line : Actors who join the apex to the core. Middle line join Manuel Kolp 53

Structure in 5 in i* and Telos metaconcepts TELL CLASS Structure. In 5 Meta. Class IN Class WITH /*Class is a Meta. Class*/ attribute name: String part, exclusive. Part, dependent. Part Apex. Meta. Class: Class Coordination. Meta. Class: Class Middle. Agency. Meta. Class: Class Support. Meta. Class: Class Operational. Core. Meta. Class: Class END Structure. In 5 Meta. Class In i* Manuel Kolp In Telos 54

Joint Venture in i* and Telos metaconcepts TELL CLASS Joint. Venture. Meta. Class IN Class WITH /*Class is a Meta. Class*/ attribute name: String part, exclusive. Part, dependent. Part Joint. Management. Meta. Class: Class part, exclusive. Part /*exclusive and independent part*/ Principal. Partner. Meta. Class: Class part /*shared and independent part*/ Secondary. Partner. Meta. Class: Class END Joint. Venture. Meta. Class In Telos Manuel Kolp 55

Hierarchical Contracting and Vertical Integration Manuel Kolp 56

Cooptation and Bidding Manuel Kolp 57

Non Organizational (Classical) Architecture Styles Layered Architecture (Mobile Robot) Pipe-filter Manuel Kolp Main Program & Sub-Routines 58

Mobile Robot Layered Architecture Need to establish direct communication Data & control hierarchies not separated Prevent manipulation of components Information exchange not always straight-forward RWI Robots (irobot. com): ATRV, B 21 r, B 14 r, Magellan Manuel Kolp 59

The Mobile Robot Case Study l Activities a mobile robot has to accomplish: - Acquiring the input provided by sensors, - Controlling the motion of its wheels and other moveable part, - Planning its future path. l External Factors: - Obstacles may block the robot’s path, - Sensor inputs may be imperfect, - The robot may run out of power, - Mechanical limitations may restrict accuracy - The robot may manipulate hazardous materials, - Unpredictable events may leave little time for responding. Manuel Kolp 60

Other Classical Mobile Robot Architectures l Control loop : Controller initiates the robot actions. Also monitors their consequences, adjusting future plans based on the return information l Task Trees : Hierarchies of tasks. Parent tasks initiate child tasks. Temporal dependencies between tasks permit selective concurrency. Manuel Kolp 61

Mobile Robot Architecture: Structure-in-5 [4, 14] More distributed architecture Manuel Kolp 62

Joint Venture l Architecture organized around - A central joint manager assuming the overall supervisor/ coordinator role for the other agent components: - A high level path planner, - A module that monitors the environment for landmarks, - A perception subsystem that receives and interprets sensors data. - A motor controller and l Components can also interact directly with each other. Manuel Kolp 63

Agent Quality Attributes for Mobile Robots l Coordinativity. Agents must be able to coordinate with other agents to achieve a common purpose or simply their local goals. A mobile robot has to coordinate the actions it undertakes to achieve its objective with the reactions forced on it by the environment. l Predictability. Agents can have a high degree of autonomy in the way they undertake action and communication in their domains. Difficult to predict individual characteristics as part of determining the behavior of the system at large. For a mobile robot, never will all the circumstances of the operation be fully predictable. The architecture must provide the framework in which the robot can act even when faced with incomplete information. Manuel Kolp 64

Agent Quality Attributes for Mobile Robots l Failability-Tolerance. A failure of one agent does not imply a failure of the whole system. Needs to check completeness and accuracy of information and transactions. Can implement replicated capabilities. Must prevent the failure of the robot’s operation and its environment. Local problems like reduced power supply, unexpectedly opening doors should not necessarily imply the failure of the mission. l Adaptability. Agents must to adapt to modifications in their environment. Must allow changes to the component’s communication protocol, dynamic manipulations of agents. Application for mobile robots frequently requires experimentation and reconfiguration. Changes in assignments require regular modification. Manuel Kolp 65

Strengths and Weaknesses of Robot Architectures Loop Layers Task Tree S-in-5 Joint-Vent. Coordinativity - - +- ++ ++ Predictability +- + ++ Failability-Tol. + +- + + + Adaptability +- +- + + +- Manuel Kolp 66

Coordinativity l Control loop: Simplicity is a drawback when dealing with complex tasks, no leverage for decomposing the software into more precise components. l Layers: services and requests between adjacent layers. Transactions not always straight-forward. Need to skip layers to coordinate behavior. l Task trees: clear separation of action and reaction. Allows incorporation of concurrent agents. Components have little interaction with each other. l Structure-in-5: separates data (sensor control, interpreted results, world model) from control (motor, navigation, scheduling, planning and userlevel) hierarchies l Joint venture: Components interact via the joint manager for strategic decisions. They indicate their interest, the joint manager returns them such information or mediates the request to other partner component. Manuel Kolp 67

Predictability l Control loop: Reduces the unpredictable through iteration only. No framework if more subtle steps are needed. l Layers: Abstraction - uncertain at the lowest level become clear with the added knowledge in the higher layers. l Task trees: less clear. Exeption handlers when the assumptions it is based on turn out to be erroneous. l Structure-in-5: Abstraction levels in the structure-in-5 addresses the need for managing unpredictability. Lower levels only involve resources and task dependencies while higher ones propose intentional relationships. l Joint-venture: Central position and role of the joint manager is a means for resolving conflicts and prevent unpredictability. Manuel Kolp 68

Failability-Tolerance l Control loop: Simplicity makes duplication of components and behavior easy and reduces the chance of errors creeping into the system. l Layers: Many checks at different levels into the system. But control and transactions may need to skip layers to check the system behavior. l Task trees: Exception, wiretapping and monitoring can be integrated to take into account the needs for integrity, reliability, completeness. l Structure-in-5: checks integrated at different abstraction levels - redundancy from different perspectives. Not restricted to adjacent layers. Separated data and control hierarchies, can be verified independently. l Joint-venture: Joint manager proposes a central message server/controller. Can support exception, wiretapping supervising or monitoring to guarantee non-failability, reliability and completeness. Manuel Kolp 69

Adaptability l Control loop: Components are separated from each other and can be replaced or added independently. Precise manipulation inside components, at a level detail not shown. l Layers: Interdependencies between layers prevent the addition of new components or deletion of existing ones. l Task trees: Implicit invocation makes incremental manipulation of components straightforward. Sufficient to register new ones, no existing one feels the impact. l Structure-in-5: Isolates components, allows dynamic manipulation. No more than 5 components: Refined tuning inside components. l Joint-venture: Manipulation of components by registering them to the joint manager. Dependencies must be updated. Joint manager cannot be removed. Manuel Kolp 70

Legolog for Office Delivery Robot (Structure-in-5) l Cognitive Robotics development environment for Robotics experimentation with and demonstration of research on the LEGO® MINDSTORMSTM Robotics Invention System l http: //www. cs. toronto. edu/cogrobo/Legolog/ l OR Le. JOS (http: //lejos. sourceforge. net) + JACK agents Manuel Kolp 71

A Joint-Venture E-commerce Architecture E-business styles: on web, protocols, technologies Not on business processes, NFRs No organization of the architecture, conceptual high-level perspective From Security, Availability, Adaptability Manuel Kolp 72

4. Detailed Design l Architectural Agent components defined in details in terms of inputs, o l UML extensions: Tropos Proposal – Tropos offers a set of concepts and a methodology for developing – These concepts can be accommodated within UML in terms of new – One can also use UML/AUML diagrams and other techniques from Manuel Kolp 73

Design Pattern l Identify the interrelationships among a group of software components describing their responsibilities, collaborations and structural relationships. Composite Manuel Kolp 74

Design Pattern: Composite l Problem: Representing whole-part hierachies so that whole and part objects offer the same interface to client objects. l Context: Composite and component object are required to offer the same behaviour, i. e, be treated in the same way l Forces: – Composite or component should belong to the same inheritance hierarchy. – The need to represent whole-part hierarchies indicates the need for an aggregation structure l Solution : Combine inheritance and aggregation hierarchies. Manuel Kolp 75

Composite Pattern: Media Clip Manuel Kolp 76

Social Patterns Monitor Matchmaker Contract-Net Manuel Kolp 77

Example: Matchmaker l Locates a provider corresponding to a consumer request for service, l Then hands the consumer a handle to the chosen provider directly. l Contrary to the broker who directly handles all interactions between the consumer and the provider, the negotiation for service and actual service provision are two distinct phases. l Used in the horizontal contracting and joint venture styles. Manuel Kolp 78

Agent Customer Capabilities Build a request to query the matchmaker Handle a services ontology Query the matchmaker for a service Find alternative matchmakers Request a service to a provider Manage possible provider failures Monitor the provider’s ongoing processes Ask the provider to stop the requested service Provider Handle a services ontology Advertise a service to the matchmaker Withdraw the advertisement Use an agenda for managing the requests Inform service the customer of the acceptance of the request Inform the customer of a service failure Inform the customer of success of a service Matchmak er Manuel Kolp Update the local database Handle a services ontology Use an agenda for managing the customer requests Search the name of an agent for a service Inform service the customer of the unavailability of agents for a 79

Social Patterns Mediator Embassy Manuel Kolp 80

Assigning Agent Roles to Actors Manuel Kolp 81

In UML with Stereotypes <> <> Fwd Source Change <> <> Locate Source Match. Monitor <> <> Route Info Request <> Provide Information <> Info Searcher Profile Customer On-line Catalogue <> <> Query Information Source <> Hits Information <> <> Notify Change Mediator <> <> Translate Response Wrapper <> Ask for Info Advertising Statistics Processor Manuel Kolp 82

Example: Peer-to-Peer Application (Gnutella) Manuel Kolp 83

Mediators and Contract-Net in Gnutella Manuel Kolp 84

Notification in Gnutella Manuel Kolp 85

Acceptance or Denial Manuel Kolp 86

Class Diagram Manuel Kolp Shopping Cart UML Classes 87

Communication – Agent Interaction Protocol Manuel Kolp 88

Communication – FIPA-ACL - AUML <> Customer Manuel Kolp <> Shopping Cart The Checkout Dialogue 89

Dynamics: Plan Diagram Manuel Kolp 90

Dynamics Manuel Kolp Check Out Plan 91

An Agent Platform: JACK l JACK Intelligent Agents is an agent-oriented development environment built on top of the Java programming language. l JACK's integration with Java is analogous to the relationship between the C++ and C languages. l The JACK Agent Language has been developed to provide agentoriented specific extensions to Java. l http: //www. agent-software. com Manuel Kolp 92

JACK BDI Agents l Agents in JACK are intelligent in the sense they model reasoning behavior according to the BDI model. l Following this model, JACK agents can be considered autonomous software components that have explicit goals to achieve (desires). l To describe how they should go about achieving these desires, these agents are programmed with a set of plans (intentions). l Each plan describes how to achieve a goal under varying circumstances. l Set to work, the agent pursues its given goals (desires), adopting the appropriate plans (intentions) according to its current set of data (beliefs) about the state of the world. Manuel Kolp 93

JACK functional constructs l To support the BDI agents, JACK has five main constructs. – Agents – Database relations to store beliefs and data that an agent has acquired. – Goals and Events to identify the goals (desires) and messages that an agent can achieved or respond to. A Goal in JACK is a special event due to the OO nature of JAVA. – Manuel Kolp 94

Java BDI Agent Implementation in JACK Manuel Kolp 95

Related Proposals l l AUML is a recent proposal for agent modeling; its emphasis is on agent coordination+communication. l UML has been recently extended to include goals for business modeling applications; l Manuel Kolp Goal-Oriented Analysis (GOA) has been researched in Requirements Engineering since the ‘ 80 s; unlike other proposals, i* goals are relative and fulfillment is cooperative; also other GOA frameworks focus on the transformation from early to late requirements. i* is a mature modeling framework, has been formalized in a variety of settings and comes with a methodology for doing actor and goal analysis. 96

Additional Readings Information Systems [1] J. Castro, M. Kolp, and J. Mylopoulos. Towards Requirements-Driven Information Systems Engineering. Information Systems, Elsevier, 2002. [2] J. Castro, M. Kolp, and J. Mylopoulos. Developing Agent-Oriented Information Systems for the Enterprise. In B. Sharp, editor, Enterprise Information Systems II, Kluwer Publishing, 2002. [3] J. Castro, M. Kolp, and J. Mylopoulos. A Requirements-Driven Development Methodology. In Proc. of the 13 th Int. Conf. on Adv. Information Systems Engineering, CAi. SE’ 01, Interlaken, Switzerland, June 2001. Knowledge Systems [4] M. Kolp, P. Giorgini, and J. Mylopoulos. Multi-Agents Systems as Social Structures. Autonomous Agents and Multi-Agents Systems, Kluwer Publishing, 2002. [5] A. Perini, P. Bresciani, F. Giunchiglia, P. Giorgini, and J. Mylopoulos. A Knowledge Level Software Engineering Methodology for Agent Oriented Programming. In Proc. of the 5 th Int. Conf on Autonomous Agents, Agents’ 01, Montreal, Canada, May 2001. [6] M. Kolp, P. Giorgini, and J. Mylopoulos. A Goal-Based Organizational Perspective on Multi-Agents Architectures. In Proc. of the 8 th Int. Conf. on Intelligent Agents: Agent Theories, Architectures, and Languages, ATAL’ 01, Seattle, USA, Aug. 2002. [7] X. Wang and Y. Lespérance. Agent-Oriented Requirements Engineering using Con. Golog and i*. In Proc. of the 3 rd Int. Bi-Conf. on Agent-Oriented Information Systems, AOIS’ 01, Montreal, Canada, May 2001. [8] G. Gans, M. Jarke, S. Kethers, and G. Lakemeyer: Modeling the Impact of (Dis)trust in Agent Networks. In Proc. of the 3 rd Int. Bi-Conf. on Agent-Oriented Info Systems, AOIS’ 01, Interlaken, Switzeland, June 2001 Manuel Kolp 97

Additional Readings Conceptual Modeling [9] A. Fuxman, P. Giorgini, M. Kolp, and J. Mylopoulos. Information systems as Social Structures. In Proc. of the 2 nd Int. Conf. on Formal Ontologies for Information Systems, FOIS’ 01, Ogunquit, USA, Oct. 2001. [10] J. Mylopoulos, A. Fuxman, and P. Giorgini. From Entities and Relationships to Social Actors and Dependencies. In Proc. of the 19 th Int. Conf. on Conceptual Modeling, ER’ 00, Salt Lake City, USA, Oct. 2000. [11] L. Lu and E. Yu. Modelling Strategic Actor Relationships to Support Intellectual Property Management. In Proc. of the 20 th Int. Conf. on Conceptual Modeling, ER’ 01, Yokohama, Japan, Nov. 2001. Software Engineering [12] J. Mylopoulos, J. Castro, and M. Kolp, Tropos: A Framework for Requirements-Driven Software Development. In J. Brinkkemper and A. Solvberg (eds. ), Information Systems Engineering: State of the Art and Research Themes, Springer-Verlag, June 2000. [13] A. Fuxman, M. Pistore, J. Mylopoulos, and P. Traverso. Model Checking Early Requirements Specification in Tropos. In Proc. of the 5 th Int. Symposium on Requirements Engineering, RE’ 01, Toronto, Canada, Aug. 2001. [14] M. Kolp, J. Castro, and J. Mylopoulos. A Social Organization Perspective on Software Architectures. In Proc. of the 1 st Int. Workshop From Software Requirements to Architectures, STRAW’ 01, Toronto, Canada, May 2001. [15] L. Lu and E. Yu. From Requirements to Architectural Design - Using Goals and Scenarios. In Proc. of the 1 st Int. Workshop From Software Requirements to Architectures, STRAW’ 01, Toronto, Canada, May 2001. UML [16] J. Mylopoulos, M. Kolp, and J. Castro. UML for Agent-Oriented Software Development: The Tropos proposal. In Proc. of the 4 th Int. Conf. on the Unified Modeling Language UML’ 01, Toronto, Canada, Oct. 2001. Manuel Kolp 98