AOSE

AOSEAdvanced 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 317-370, 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 ProcessGaia 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 Process1. 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).


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.






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.






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.


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 agenttypes.

– Instance qualifiers are used to specifyhow many instances of each type mustexist.

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 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

http://www.auml.org/

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

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 QuoteSeller

Place Order

1.1: Supplier 1.3: Retailer

1.1.2Sales

1.1.1Production

1.3.2Inventory

1.3.1Purchasing

Buyer

Supplier Retailer

WarehouseManager

1.2: HaulageFirm

Hauler

Hauler

DeliverGoods

CollectGoods

WarehouseManager

Haulage FirmTransportManager

RequestDelivery

… …

TransportManager


0: Scenario: Supply Chain

BuyerSeller

Organisational Unit Diagram System Behaviour Diagram: Level 1.2

1.1: Supplier 1.3: Retailer

1.1.2Sales

1.1.1Production

1.3.2Inventory

1.3.1Purchasing

1.2: HaulageFirm

HaulerHaulerTransport

Manager

Assign toDelivery

… …

TransportManager

CompleteDelivery

Example: Supply ChainSystem Behaviour: Obtain Quote

Buyer

Seller

1.request,quote(?item, ?amt)

Buyer Seller

request, quote(?item, ?amt)

UML Collaboration Diagrams

AUML Protocol Diagram

4.inform,

quote(?id, ?item,?price)

WarehouseManager

request, checkStock(?item)

inform, available(?item, ?amt)

inform, unavailable(?item)

xinform, unavailable(?item)

inform, quote(?id, ?item, ?price)

2.request,checkStock(?item)

3.inform,

available(?item,?amt)

WarehouseManager

Buyer

Seller

1.request,quote(?item, ?amt)

4b.inform,

unavailable(?item)

2.request,checkStock(?item)

3b.inform,

unavailable(?item)

WarehouseManager


ItemReorder Level

Reached

request,quote(?item, ?amt)

Buyer Seller

System Behaviour: Obtain Quote

Warehouse Manager

Create Quotation

request,availability(?item) Check Item

Availability

xGenerate Price

For Item

inform,availability(?item, ?amt)

inform,quote(?id, ?item, ?price)Record

Quotation

inform, unavailable(?item)Destroy QuotationSet Item as

unavailable

inform,unavailable(?item)

Identify Suppliers

StoreQuotation

Test-Driven Implementation

Create a set of Test Agents

Create application agents and integrate

tests using Test Agent

Integrate and Debug Application Agents

Test-Driven Implementation

Release & Review

Test-Driven Implementation Design

Refactor & Enhancement

Initial Design

Finish of Project

Integrated Development Process Require- ments

Specification

AOSE

Documents

Transcript of AOSE