AOSE

1. AOSE Advanced Software Engineering University College Dublin December 2007 Dr Rem Collier

2. AOSE Introduction to Methodologies

3. Introduction • Many AOSE Methodologies have been proposed. • Knowledge Engineering Based Approaches: • MAS-CommonKADS • Agent Specific Approaches: • GAIA • ROADMAP • SODA • Object-Oriented Based Approaches: • MESSAGE • Prometheus • MaSE • PASSI • AUML • In this course we will look at GAIA

4. AOSE GAIA Methodology

5. Recommended Reading • Michael Wooldridge, Nicholas R. Jennings, and David Kinny, “The Gaia methodology for agent-oriented analysis and design”, in Journal of Autonomous Agents Multi-Agent Systems Vol. 3, No. 3, pp 285–312, 2000 • Franco Zambonelli, Nicholas R. Jennings, Michael Wooldridge, “Developing Multiagent Systems: The Gaia Methodology”, in ACM Transactions of Software Engineering and Methodology, Vol. 12, No. 3, pp 317-370, July 2003

6. Why Look at GAIA? • It’s different from other approaches: • It is founded upon a set of concepts that are well-suited for multi-agent systems. • It does not deal directly with particular modelling techniques • It is not tied to a single implementation. • However, GAIA does not: • Include support for the capturing and modelling of system requirements. • Offer any insights as to how the design may be implemented.

7. GAIA – Domain Characteristics • Agents are coarse-grained computational systems, each making use of significantcomputational resources. • GAIA-designed systems maximise some globalquality measure, but may be sub-optimal from the point of view of thesystem components. • Gaia is not intended for systems that admit the possibility oftrue conflict. • GAIA makes noassumptions about the delivery platform. • Agents are heterogeneous, in that different agents may be implemented usingdifferent programming languages, architectures, and techniques.

8. GAIA – Domain Characteristics • GAIA supports the development of closed systems. • The organisation structure of the system is static, in that inter-agent relationshipsdo not change at run-time. • The abilities of agents and the services they provide are static, in that they do notchange at run-time. • The overall system contains a comparatively small number of different agent types(less than 100).

9. GAIA & Organisational Structures • To adequately model the target system, the analysis phase of GAIA adopts the view of the system as an organisation. • Their rationale for this is that the concept of an organisation fits with the concept of a multi-agent system: • A multi-agent system is comprised of a set of computational entities (agent) that play roles, and whose global system behaviour is realised through the interactions that occur between those entities. • Key Point: roles are a good level of abstraction for modelling the structure of an organisation.

10. The GAIA Process Gaia encourages a developer to think of buildingagent-based systems as a process of organisational design.

11. ANALYSIS PHASE

12. The Roles Model • Identifies the roles that agents will play in the final system. • Informally, roles are more or less identical to the notion of an office in the sense that the “President of the United States” and the “Minister of Education” are offices. • Initially, GAIA characterises each role by two types of attribute: • The permissions associated with the role. • What types of resource does it need to fulfil the role, and in what ways does it need to exploit them. • The responsibilities of the role. • What activities is the agent required to undertake when playing this role, and how should it use those activities to achieve the goals associated with the role. • Support for the construction of this model takes the form of a Role Schema template.

13. The Role Schema Template • This template specifies a set of fields that must be completed for each role in the model. • Central to this template are the Permissions and Responsibilities fields. • The entries for Protocol and Activities field are derived from the Responsibilities field.

14. Permissions • Permissions specify resource requirements for roles: • What resources that can legitimately be used to carry out the role (I.e. what can be spent), and • What are the resource limits within which the role executor must operate (I.e. what cannot be spent). • While, in practice, resources may take many forms (e.g. money, man-hours effort), GAIA adopts the view of a resource as “the information or knowledge the agent has”. • That is, in order to carry out a role, an agent will typically be able to access certain information. • Some roles might generate information; • Others may need to access a piece of information, but not modify it; • Thus, permissions are defined as access rights for pieces of information!

15. Permissions • The types of permission allowed in GAIA are: • Read Access. The role must be able to access the specified information, but does not need to modify that information. • E.g. reads coffeeStatus • Write Access. The role must be able to modify the value of the specified information. • E.g. changes coffeeStock • Create Access. The role creates/generates the specified information. • E.g. generates coffeeStatus • In addition, GAIA supports role templatisation through the parameterisation of permissions. • That is, it is possible to supply a role with information. • E.g. reads supplied coffeeMaker

16. Responsibilities • Responsibilities define the functionality required by the role. They are divided into two categories: • Liveness Responsibilities. Those that, intuitively, state that “something good happens”. That is, they specify what must be done. • Safety Responsibilities. Those that, intuitively, state that “nothing bad happens”. That is, they specify invariants that must be maintained during the execution of the role.

17. Liveness Responsibilities • Liveness responsibilities are things that the agent must do while playing the role. • As such, they tend to follow certain patterns. For example: • Guaranteed Response type achievement goals take the form “a request is always followed by a response”. • Infinite Repetition type achievement goals take the form “x will happen infinitely often”. • In the context of a coffee maker, liveness responsibilities include: • whenever the coffee pot is empty, fill it up; and • whenever fresh coffee is brewed, make sure the workers know about it. • GAIA represents liveness properties as liveness expressions. These are basically regular expressions.

18. Liveness Expressions • A liveness expression takes the form ROLENAME = expression where, ROLENAME is the name of the role and expression is the liveness expression. • The atomic components of a liveness expression are either activities or protocols. • Activities are fundamental actions that must be directly executable by the agent. They are represented here by activity identifiers. • Protocols define interactions with other roles. These are defined in the Interaction Model. They are represented here by protocol identifiers. • These atomic components can be combined with a number of operators to form the liveness expressions.

19. Liveness Expressions • For example: COFFEEFILLER = (Fill . InformWorkers . CheckStock . AwaitEmpty)w • Reuse and readability is also supported: COFFEEFILLER = (All)w All = Fill . InformWorkers . CheckStock . AwaitEmpty

20. Safety Responsibilities • Safety responsibilities define invariants that must remain true during the execution of the role. • These invariants take the form of predicate expressions that define constraints which apply to the variables listed in the permissions field of a role. • For example, the invariant that the coffee stock is never empty can be represented by the following safety expression: coffeeStock > 0 • It is implicitly assumed that these responsibilities will apply across all states of the system execution. • If the role is infinitely long, then the invariant will always remain true.

21. Example Schema

22. The Interactions Model • The interaction model seeks to identify the interactions that will occur in the implemented system. • As such, the model is comprised of a set of protocol definitions – one for each type of inter-role interaction. • A protocol definition combines: • purpose: brief textual description of the nature of the interaction (e.g., .informationrequest., .schedule activity. and .assign task.); • initiator: the role(s) responsible for starting the interaction; • responder: the role(s) with which the initiator interacts; • inputs: information used by the role initiator while enacting the protocol; • outputs: information supplied by/to the protocol responder during the course ofthe interaction; • processing: brief textual description of any processing the protocol initiator performsduring the course of the interaction.

23. Protocol Definition Example

24. The Analysis Process • Identify the roles in the system. • For each role, identify and document the associated protocols. 3. Using the protocol model as a basis, elaborate the roles model. 4. Iterate stages (1) - (3).

25. The Analysis Process • Identify the roles in the system. Roles in a system will typically correspond to: • individuals, either within an organisation or acting independently; • departments within an organisation; or • organisations themselves. Output: A prototypical roles model, a list of the key roles that occur in thesystem, each with an informal, unelaborated description. • For each role, identify and document the associated protocols. 3. Using the protocol model as a basis, elaborate the roles model. 4. Iterate stages (1) - (3).

26. The Analysis Process • Identify the roles in the system. • For each role, identify and document the associated protocols. Protocols are thepatterns of interaction that occur in the system between the various roles (e.g. a protocol may correspond to an agent in the role of Buyer submittinga bid to another agent in the role of Seller). Output: An interaction model, which captures the recurring patterns of inter- roleinteraction. 3. Using the protocol model as a basis, elaborate the roles model. 4. Iterate stages (1) - (3).

27. The Analysis Process • Identify the roles in the system. • For each role, identify and document the associated protocols. 3. Using the protocol model as a basis, elaborate the roles model. Output: A fully elaborated roles model, which documents the key rolesoccurring in the system, their permissions and responsibilities, together with theprotocols and activities in which they participate. 4. Iterate stages (1) - (3).

28. DESIGN PHASE

29. The Design Process • The goal of the design process is to transform the analysis models into a sufficiently low level of abstraction that traditional design techniques may be used to implement agents. • It involves the generation of three models that identify: • The agent types and agent instances that will make up the system (Agent Model). • The main services that are required to realise the model (Service Model). • The lines of communication between the different agents (Acquaintance Model). • Remember: GAIA has been designed for closed systems that have a static organisational structure!

30. The Agent Model • The goal of this model is to identify what types of agent must exist. • Informally, an agent type is modelled as a set of roles that an instance of that type must play. • Types are represented using agent type trees. • These trees associate one or moreagent roles with one or more agenttypes. • Instance qualifiers are used to specifyhow many instances of each type mustexist.

31. The Services Model • In GAIA, a service is basically a function of an agent. • That is, the service model is used to refine the protocols, activities and responsibilities of the agent. • In general, there will be at least one service per protocol. • The service model specifies: inputs, outputs, pre-conditions, and post-conditions for each service (activity). • For example: • The CheckStock activity will take as input the stock level and some threshold value, and will simply compare the two. • The pre- and post-conditions will both state that the stock level is greater than zero.

32. The Services Model

33. The Acquaintance Model • This third model specifies the lines of communication between the agent types.

34. The Design Process • The GAIA Design Process can be summarised as follows: • Create an Agent Model: • Aggregate the roles into agent types and refine to form an agent type hierarchy • Document the instances of each agent type using instance annotations. • Develop a Service Model by examining the activities, protocols, and safety and liveness properties of each role. • Develop an Acquaintance Model from the Interaction Model and the Agent Model.

35. Agent UML

36. Introduction • Proposed extension to UML. • Details available from http://www.auml.org/ • Supports concurrent threads of interaction, and thus agent protocols • Concept of a role is changed to fit agent view • Currently, AUML is a goal—not an existing modelling language. • Many proposed models, but only one is standardised: Protocol Diagrams

37. AUML Protocol Diagram • Supports Parameterized Templates. • Messages constrained tocommunicative acts. • Optional AND, OR, XORconnectors for lifelines. • Multiple threads ofinteraction: • Concurrent: all together now • Decision: 0 or more • Selection: exactly 1

38. SADAAM • Simple Agile Methodology based on (Agent) UML. • System Behaviour Diagram (system overview): UML. • Organisational Diagram (hierarchy of organisations): custom diagram • Protocol Diagram (model interactions): AUML • Collaboration Diagram (model interactions): UML • Activity Diagram (model activities): UML • Basic Process: • Model the Organisation & System Behaviours • Select some behaviours as a release & model interactions / activities for each. • Use Test-Driven Approach to implement release

39. Example: Supply Chain Organisational Unit Diagram System Behaviour Diagram: Level 0 0: Scenario: Supply Chain Retailer Supplier Place Order 1.2: Haulage Firm 1.1: Supplier 1.3: Retailer Obtain Quote Buyer Seller Transport Manager Hauler Warehouse Manager Warehouse Manager Deliver Goods Collect Goods 1.1.1 Production 1.1.2 Sales 1.3.1 Purchasing 1.3.2 Inventory Request Delivery … … Haulage Firm Transport Manager Hauler Seller Buyer

40. Example: Supply Chain Organisational Unit Diagram System Behaviour Diagram: Level 1.2 0: Scenario: Supply Chain 1.2: Haulage Firm 1.1: Supplier 1.3: Retailer Assign to Delivery Complete Delivery Hauler Transport Manager Transport Manager Hauler 1.1.1 Production 1.1.2 Sales 1.3.1 Purchasing 1.3.2 Inventory … … Seller Buyer

41. Example: Supply Chain System Behaviour: Obtain Quote Warehouse Manager Buyer Buyer Buyer Seller 1. request, quote(?item, ?amt) 4. inform, quote(?id, ?item, ?price) request, quote(?item, ?amt) request, checkStock(?item) 1. request, quote(?item, ?amt) 4b. inform, unavailable(?item) inform, unavailable(?item) x Seller Seller inform, unavailable(?item) inform, available(?item, ?amt) 2. request, checkStock(?item) 3. inform, available(?item, ?amt) inform, quote(?id, ?item, ?price) 3b. inform, unavailable(?item) 2. request, checkStock(?item) AUML Protocol Diagram Warehouse Manager Warehouse Manager UML Collaboration Diagrams

42. Example: Supply Chain System Behaviour: Obtain Quote Buyer Seller Warehouse Manager Item Reorder Level Reached request, quote(?item, ?amt) request, availability(?item) Identify Suppliers Create Quotation Check Item Availability inform, availability(?item, ?amt) Generate Price For Item x inform, quote(?id, ?item, ?price) Record Quotation Store Quotation inform, unavailable(?item) inform, unavailable(?item) Set Item as unavailable Destroy Quotation

43. Test-Driven Implementation