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

AOSE Introduction to Methodologies

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

AOSE GAIA Methodology

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 , July 2003

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.

GAIA – Domain Characteristics Agents are coarse-grained computational systems, each making use of significant computational resources. GAIA-designed systems maximise some global quality measure, but may be sub-optimal from the point of view of the system components. –Gaia is not intended for systems that admit the possibility of true conflict. GAIA makes no assumptions about the delivery platform. –Agents are heterogeneous, in that different agents may be implemented using different programming languages, architectures, and techniques.

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

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.

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

ANALYSIS PHASE

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.

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.

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!

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

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.

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.

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.

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

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.

Example Schema

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.,.information request.,.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 of the interaction; –processing: brief textual description of any processing the protocol initiator performs during the course of the interaction.

Protocol Definition Example

The Analysis Process 1.Identify the roles in the system. 2.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).

The Analysis Process 1.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 the system, each with an informal, unelaborated description. 2.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).

The Analysis Process 1.Identify the roles in the system. 2.For each role, identify and document the associated protocols. Protocols are the patterns 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 submitting a bid to another agent in the role of Seller). Output: An interaction model, which captures the recurring patterns of inter- role interaction. 3. Using the protocol model as a basis, elaborate the roles model. 4. Iterate stages (1) - (3).

The Analysis Process 1.Identify the roles in the system. 2.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 roles occurring in the system, their permissions and responsibilities, together with the protocols and activities in which they participate. 4. Iterate stages (1) - (3).

DESIGN PHASE

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!

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 more agent roles with one or more agent types. –Instance qualifiers are used to specify how many instances of each type must exist.

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.

The Services Model

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

The Design Process The GAIA Design Process can be summarised as follows: 1.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. 2.Develop a Service Model by examining the activities, protocols, and safety and liveness properties of each role. 3.Develop an Acquaintance Model from the Interaction Model and the Agent Model.

Agent UML

Introduction Proposed extension to UML. –Details available from –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

AUML Protocol Diagram Supports Parameterized Templates. Messages constrained to communicative acts. Optional AND, OR, XOR connectors for lifelines. Multiple threads of interaction: –Concurrent: all together now –Decision: 0 or more –Selection: exactly 1

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

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

Example: Supply Chain 0: Scenario: Supply Chain BuyerSeller Organisational Unit Diagram System Behaviour Diagram: Level : Supplier1.3: Retailer Sales Production Inventory Purchasing 1.2: Haulage Firm Hauler Transport Manager Assign to Delivery … … Transport Manager Complete Delivery

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

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

Test-Driven Implementation