aose
DESCRIPTION
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 - PowerPoint PPT PresentationTRANSCRIPT
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).
The Analysis Process1. 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 Process1. 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 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.
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 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
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
Example: Supply Chain
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
Example: Supply Chain
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