Transcript Tutorial on CAMLE Methodology

Tutorial 1:
CAMLE: Caste-centric Agent-Oriented
Methodology of Software Development
－－Meta-model, Languages and Environment
Hong Zhu
Dept. of Computing and Electronics
School of Technology
Oxford Brookes University, Oxford, UK
Email: [email protected]
Outline
Part 1: Background
– What is agent-orientation?
– Why agent-orientation?
– Overview of agent-oriented software engineering
Part 2: CAMLE methodology
–
–
–
–
Meta-model: conceptual model of agent-oriented systems
Modeling: language CAMLE and modeling environment
Specification: Language SLABS
Programming:
• Agent/object oriented programming in SLABSp
• Pure agent-oriented programming in CAOPLE
– Language
– CAVM: virtual machine
Conclusion
– Future research directions
24/3/2009
2
Part 1: Background
1. What is agent orientation?
– Illustrate through an example
• Solution in structured approach
• Solution in object-oriented approach
• Solution in agent-oriented approach
More details will be covered in part 3
Introductive Example
Summer School
A summer school is organised to teach a number
of classes. Some classes are scheduled to be hold
at the same time, but, of course, at different
classrooms. Students can choose the classes to
attend. Students may be unfamiliar with the site
where classes are. The question is how to make
sure that students go to the right classes.
Example adapted from:
Design Patterns Explained, by Shalloway, A. & Trott, J., 2002
24/3/2009
4
Structured Programming
(Stepwise Refinement)
1. Get a list of people in the class
2. For each person on the list Do:
① Find the next class he/she is attending
② Find the location of the class
③ Find the way to get from your classroom to
the person’s next class
④ Tell the person how to get their next class
24/3/2009
5
Structured Analysis and Design
Next
Class
Instructor
Location_to
Class
Get
Student
student
list
List of
students
Class lists
24/3/2009
Find
Location
Class
class
locations
location
Find
next
class
Location_from
Next
class
Student
schedules
Next
class
Find
route to
class
Map
Site maps
Route
Give
Route,
direction Next class
Student
6
Object-Oriented Approach
Tc: TClass
TClass
Location
Instructor
1. GoFrm(Tc)
Time
St: Student
Student
2. FindRoute(Tc, nxt)
Schedule: *TClass
GoFrm(cl: TClass)
…
Map
FindRoute(st,fn)
Mp: Map
Change of responsibility in finding out the route to the
next classroom from the instructor to the students
24/3/2009
7
Agent-Oriented Approach
Inform
Set
Global
schedule
Organiser
Set
Local
knowledge
Inform
Expected Students’ Behaviour
sStudent. [ time: AttendClass(C)]
if time is before GlobalSchedule.C.start-time
24/3/2009
Instructors
Access
Teach
Access
Access
Access
Students
Change of responsibility
on students’ behaviour
from Summer School to
students themselves.
8
2. Why Agent-orientation
• Problems in current methodologies:
– Analysis of OO methodology
• Requirements of the new methodology:
– Analysis of the problem domain and solution space
Problems
mapping into
a solution
awkwardly
Problems
nicely
represented in
a methodology
Solutions directly
supported by
technology &
infrastructure
Why need a new methodology?
New
technology
and
infrastructure
OO Philosophy
• A good information system’s structure should
reflect the structure in the real world in order for
the system to be easy to understand, easy to
develop and to maintain and easy to reuse.
Isomorphism Hypothesis
An information system can and should be constructed with a
structure that reflects the real world’s structure.
• Everything is an object.
Universal Hypothesis
An information system can and should be constructed from
objects and nothing else.
24/3/2009
10
Conceptual Model of Object-Orientation
Structural Aspect of OO
(Simplified UML Metamodel)
Model Element
Instance
Classifier
Relationship
Class
Feature
Association
Generalization
Whole-part
Behavior
Feature
Method
24/3/2009
Structural
Feature
Association
end
Attribute
11
Dynamic Aspect of OO
• An object executes a method if and only if
the method is called (i.e. a corresponding
message is received);
• The method to be executed when a
messages is received is determined at runtime according to inheritance relation
(dynamic binding);
• An object is created and destroyed by other
objects.
24/3/2009
12
An Analysis of OO Meta-Model
• In the world of a zoo, we have objects of tigers,
rabbits and carrots. However, in an OO information
system,
Structural mismatch:
– The rabbit cannot move
to find carrots unless
there is a ‘remote
controller’;
– A rabbit cannot see if
there is a tiger unless
the tiger sends a
message to the rabbit;
Need additional elements
in the system.
Behavioural mismatch:
Need additional behaviour
rules.
The problem is in the meta-model.
24/3/2009
13
Problem Domain and Solution Space
Development Practice
Infrastructure & Technologies
 Internet and Web technology
(Grid, P2P, Cloud, WS, Semantic
web, etc.)
 Wireless and mobile computing
and communication
 Pervasive and wearable computing
 Agent technology (e.g. ontology,
ACL, protocols)
 Multiple core CPU hardware
24/3/2009
 Out-sourcing,
 COTS,
 Open source,
 Service orientation
•
•
•
•
•
•
•
Novel applications
E-commerce,
E-science,
E-government,
Online entertainments,
Online education,
Virtualisation,
Pervasive computing,
14
Challenges to Methodology
Current State
• System centric
Development targets at the
construction of a self-contained
functionally complete system
• Control centric
Design concentrates on how
components control each other
• Human centric
Communication between
developers is assumed, and its
effectiveness is the central problem
of software methodology
• Reliability centric
Reliability as the most important
quality criterion of software systems
• Reuse centric
Reusability as a most desirable
feature, and the main hope of
improving software productivity
24/3/2009
New Requirements
• Service centric
Development targets at provide a set
of services, which may be not a
system in traditional sense
• Cooperation centric
Design focuses on how a service
cooperate with others, even the
unknowns
• Run-time centric
Communication between developers
cannot be assumed, it is replaced by
communications between
components at run-time
• Robustness centric
How to continue services in the
presence of failures become more
and more important
• Evolution centric
Sustainability for long term evolution
becomes the focus
15
New Features of Computational Entities
• Autonomous resources
– Different owners of resources
• Proactive behaviour
– Hollywood model:
‘You don’t call me. I’ll call you’
– Watch the environment, then
take appropriate actions
• Collaborative interaction
Agent!
– Complicated interaction protocol
– Search-binging-invocation
• Persistent lifespan
– Continuously running
– Last forever
24/3/2009
16
3. Overview of Agent
Orientation
• Models of agents
• Agent-oriented software
development methodologies
24/3/2009
17
Various agent models
• Mentalistic models
– An agent consists of a number of aspects of mental
states and behave according to the state of its mental
state and its view of the environment
• Game theoretic models
– An agent and the system consists of a number of
variables a utility function defined on the variables and
the agent take actions to maximise the utility
• Reactive models
– An agent senses the changes in its environment and
take actions according to a set of predefined rules.
24/3/2009
18
Mentalistic models of agents
• BDI agent has the mental state variables of
– Belief: the agent’s view of the environment. According
to its local information of the environment, it beliefs the
system is in certain state;
– Desire: the states of the environment and the agent
that it want to be in.
– Intension: the state of the system and the agent that it
want to be in by taking certain sequence of action in
the relatively near future.
• Other mental state variables:
– Goal: the state of the system and the agent that the
agent wants to be in eventually;
– Plan: the sequence of actions that the agent will take
in the immediate future;
24/3/2009
19
Genealogy of AO methodologies
Henderson-Sellers, B. and Giorgini, P., Agent-Oriented
Methodologies, Idea Group, 2005, Page 7.
24/3/2009
20
Agent-oriented SE Methodologies
• Gaia (Zambonelli, Jennings, and Wooldridge, 2003 )
– Based on organization-oriented abstraction in which software
systems are conceived as organized society and agents are seen
as role players. The implementation is towards object-oriented. No
languages at all.
• Tropos (Bresciani, Giorgini, Giunchiglia, Mylopoulos and
Perini, 2004)
– Uses of notions related to mental states like belief, intention, plan,
goals, etc., to represent the abstraction of agent’s state and
capability.
– The implementation is based on AI technology.
• i* (Yu, E. et al.)
– Focus on requirements analysis using agent concepts.
– Notation for requirements specification.
• AUML (Bauer, Muller, and Odell, 2001)
24/3/2009
– Extension of UML notation with notation to represent agents and
agent classes.
– In lack of a well-defined semantics and meta-model. Currently, it
only has a static meta-model.
21
Part 2
CAMLE Methodology
Caste-centric
Agent-oriented
Methods
Languages and
Environments
24/3/2009
22
Overview
of
CAMLE
Methodology
Tool-Level
Maintenance &
Testing Tools
(AquIS)
Modelling
Tools & Env.
Formal
Reasoning
(Scenario
Calculus)
Programming
Env. & Virtual
Machine (CAVM)
Method-Level
MAS Architecture of
Growth Environment
Development
process model
(Growth Model)
Modelling,
Analysis &
Design
(CAMLE)
Development of Web Services
Implementation
Specification & Programming
(SLABS)
(SLABSp,
CAOPLE)
Meta-Level
Caste-Centric Meta-Model of MAS
24/3/2009
23
A brief history of caste-centric
Pre-CAMLE
Agent-based framework, process and tools for quality assurance of web-based applications
1999-2000
Caste-centric metamodel and SLABS language (FAABS 2000, IJSEKE 2001, MAMA 2000)
2002
Informal modelling notation (ICFEM 2002, AOIS 2002)
Dynamic caste language facility and enhance SLABS specification language (AAMAS 2003)
2003
CAMLE modelling language (GCC 2003, IAT 2003)
Inception of agent-oriented programming language (JMLC'2003)
CAMLE modelling environment (COMPSAC 2004, SELMAS 2004)
2004
SLABS’ application to Web Services (GCC 2004)
Programming language SLABSp (APSEC 2004)
CAMLE’s application to Web services (WORDS 2005)
2005
Scenario calculus (SEKE 2005)
Scenario calculus applied to formal analysis of agent communities
2006
Adaptive caste mechanism (AOSDM’06@SEKE 2006)
Framework and methodological principles of agent-oriented information systems
Formal approach to engineering emergency (EEDAS 2007, CEC 2007)
2007
Design programming language CAOPLE
Design and implementation of virtual machine CAVM (SEKE 2008)
2008
24/3/2009
Case study of caste-centric methodology in healthcare MAS
24
1. CAMLE Meta-model
• Structure and static features
– Agent
– Caste
– Multi-agent systems and Environment
• Behaviour and dynamic features
– Communication mechanism
– Behaviour rules
24/3/2009
25
Meta-Model of Caste-centric Agents
Classifier
Relation
Agent
Object
Caste
Class
Caste-Centric Meta-Model
Agent = <Data, Operations, Behaviour>Environment
Castes = { agents | structure& behaviour property}
MAS = {Agentn}nI
Environmenttime(Agent, MAS)  MAS – {Agent}
Communication( A to B)
= A.Action + B.Observation
24/3/2009
State
space
Action
space
Inheritance
Aggregation
Migration
Behavior
rules
Environment
description
26
Agent
Agents are active computational entities that
situate in their designated environments and
encapsulate
– Data: the state of the agent (visible, or internal)
– Operations: the actions that an agent can take
(visible or internal)
– Behaviour: the rules the control the agent’s
actions and state changes
24/3/2009
27
Description of Agents in SLABS
Name: castes (Instantiation)
Visible state-variables and actions
Invisible state-variables and actions
Environment
description
24/3/2009
Behaviour-specification
28
Student’s Behaviour
Beginning
of school
Setup
schedule
Time to
class
In right
mode
Select next class
Time to
class
Not fancy
any class
Have a rest
Find class location
Work out route
Attend class
24/3/2009
29
Another Student’s Behaviour
Beginning
of school
Make
friends with
other
students
Friend
Go to Class
Time to
class
Follow a friend to
the class
Time to
class
Friend
Go to Pub
Follow the friend
to the pub
Buy friend a
drink
24/3/2009
30
Caste
A caste is a set of agents that have same structural
and behavioral characteristics.
• Multiple classification:
– An agents can be a member of a number of castes.
• Dynamic classification:
– Agent can change their caste membership at run-time by
join a caste or quit from a caste
• Autonomous part-whole relationship:
–Aggregate: Independent but collaborative
–Composite: Parts are cooperative, but controlled by the
whole
–Congregation: Parts are autonomous, cooperative and
rely on the whole to benefits from the membership.
24/3/2009
31
Description of Castes in SLABS
Name <= castes (instantiation)
Visible state-variables and actions
Invisible state-variables and actions
Environment
description
24/3/2009
Behaviour-specification
32
Designated Environment
• Explicitly specification of environment by
declaring which agent is in its environment
– All: Caste -- All the agents in the caste
– Agent: Caste -- A specific agent of the caste
– Var: Caste -- A variable agent in the caste
• An agent can change its environment
– By joining a caste
– By quitting a caste
– By changing the value of environment variables
• The environment of an agent can also change
beyond the agent’s control
– Other agents join or quit a caste that is a part of the
agent’s environment
• The environment is not completely open, not
closed, not fixed.
24/3/2009
33
2. Specification Language
SLABS
24/3/2009
34
Specification of Behaviours in SLABS
Format of behaviour rules:
Behaviour-rule ::= [<rule-name>] pattern |[ prob]-> event,
[if Scenario] [where pre-cond];
Pattern
Meaning
$
The wild card, which matches with all actions
t
Silence
X
Action variable, which matches an action
An action Act that takes place with
Act (a1, ...ak)
parameters match (a1, ...ak)
[p1,..., pn]
24/3/2009
The previous sequence of events match the
patterns p1, ..., pn
35
Scenario Descriptions in SLABS
A scenario is a combination of a set of agents’ behaviours and states
that describe a global situation in the operation of the system.
Scenario
Predicate
A=B (or AB)
Meaning
The state of the agents satisfies the predicate
The identifiers A and B refer to the same (or different) agent
AC
Agent A is in the caste C
A:P
Agent A's behaviour matches pattern P
XC.Sc
[m]XC.Sc
The scenario Sc[X/A] is true for all agents A in caste C.
There are m agents in caste C such that Sc[X/A] is true, where the
default value of the optional expression m is 1.
S1 & S2
Both scenario S1 and scenario S2 are true
S1  S2
Either scenario S1 or S2 or both are true
S
{XC | Sc}
XC.Sc
24/3/2009
Scenario S is not true
The set of agents in caste C such that Sc[X/A] is true
The number of agents A in caste C such that Sc[X/A] is true
36
3/25/2000
Examples of Scenarios
(1) Maze: !n, m{1,..,10}. Bean(n, m)=False.
It describes the situation in the mice-maze system
when there is no bean left in the maze.
(2) pParties.t2000:[nominate(Bush)] || t2000=(4/2000).
It describes the situation that at least one agent in the
class Parties took the action nominate(Bush) at the time of
April 2000.
(3) ( x Citizen.[vote(Bush)] /  x Citizen.[$]) > 1/ 2
It describes the situation that more than half of the
agents in the class Citizen took the action of vote(Bush).
24/3/2009
37
Examples of Rules
[!SpareMoney>£2000] -> Buy(ShareX);
If (XBroker.[Buy(ShareX)])  (XBroker.[$])/2
[!SpareMoney£2000 & SpareMoney  £500] ->
Save(SpareMoney, BankX, AccoundTypeY);
if BankX:[!AccountTypeY_Rate=Z]
& WBanks.W:[!AccountTypeU_RateZ]
[!SpareMoney<£500] -> Spend(SpareMoney, BarX);
if GCMS.G:[Suggest(BarX)].
24/3/2009
38
3. Modeling Language and Environment
CAMLE
• Language
– Collaboration diagrams
– Caste diagrams
– Behaviour + Scenario diagrams
• Tools and Environment
– Model construction tools
– Consistency checkers
– Transformation from models to formal
specifications
24/3/2009
39
Example: Caste Diagram
Caste
Caste node
Aggregation
Inheritance
Congregation
University
Migration
Composition
Participation
Student
Undergraduate
24/3/2009
Department
University Member
Alumni
Postgraduate
Faculty
PhD student
Secretary
Staff
Manager
Module
Manager
40
Examples: Collaboration Diagrams
Supervisor:
Faculties
Report progress
PhD Students
Faculties
Suggest
research topic
Personal Tutor:
Faculties
Give
Practical
Lecture
Class
Academic Advice
Undergraduates
Request Reference
Department
Action Announce_Module_Result, Submit_Class_List,
Assign_Teaching_Task, Report_Accomplishment
Students
Announce_Module_Result
Select module
Submit_Class_List
Faculties
Assign_Teaching_Task
Report_Exam_Results
24/3/2009
Module
Manager
Report_
Accomplishment
Notify(Module_list,
Exam_Results)
Staff
Manager
Head of Dept:
Faculty
Instruction
41
Example: Behaviour Diagram
Status=Final Year
Average = ‘A’
Postgraduate
course available
Personal Tutor:
Faculties
Request
reference
Agree as referee
CS: Dept Office
Behaviour of a
final year student
Apply
Postgraduate
course
Offer Postgraduate
course
JOIN(Postgraduates);
QUIT(Undergraduates)
24/3/2009
42
Modeling Environment
24/3/2009
43
Architecture of Modelling Environment
Users’
Requirements
Formal
Specifications
Graphic User
Interface
Specification
Generator
Model
Manager
Diagram
Editor
Partial
Diagram
Generator
Wellformedness
Checker
Behaviour/
Collaboration
Checker
Caste/
Collaboration
Checker
Consistency
Checker
Controller
Behaviour
Model
Checker
Collaboration
Model Checker
General/
Specific
Checker
Caste/
Behaviour
Checker
Cross level
Checker
Graphic
Models
24/3/2009
Check
Result
44
4. Application to Web Services
The basic feature of Web Services:
• autonomous
Each web service provider controls its own resources and in
charge of its own behaviour
• active and pro-active
WS components are not just waiting for another elements to call.
They may make initiative actions
• persistent computational entities:
WS components are supposed to run continuously and retain their
state over a long period
• sociable
WS dynamically discovers other web services and establish links
between them at runtime
Basic features of WS matches the characteristics of agents at the
highest abstraction level, but do not match many concrete models
of agents, such BDI and game models.
24/3/2009
45
Caste-Centric View of WS
Each web service provider/requester can be
considered as an agent, in particular
– Visible state
as the information published on the Internet
– Invisible state
as the internal state of the service
– Visible Actions
as the provided services
– Invisible actions
as the events internal to the implementation of the service
– Behaviour rules
the code that determines the way that the web service fulfils its
tasks
Note: an agent can be implemented as a compound agent, i.e. it
consists of several agents.
24/3/2009
46
Modelling WS Application Systems
• From service provider’s perspectives
– how developers of service provider model the service
provider system
• Define the functionality and usage of the services without give
away unnecessary implementation details
• Define the assumptions on the usages of the services without
over restricting the development of the users of the services
• From service requester’s perspectives
– how the design knowledge of the service provider
specified in the model are used by the developers of the
requesters
24/3/2009
47
Service Provider’s Perspective
Step 1: identify the types of agents participate
in the operation of the system and specify
them as castes
24/3/2009
48
Step 2: Identify the communications between
service providers and requesters and
represent the results in general collaboration
diagrams
24/3/2009
49
Step 3: Identify the scenarios in which service
providers and requester collaborate with
each other and represent the scenarios in
scenario-specific collaboration diagrams
– Scenario 1: to set up an auction for a seller
While collaboration diagrams are expressive enough to describe
workflows in the form of action sequences, it is not capable of
expressing the semantics of business rules.
24/3/2009
50
– Scenario 2: to run an online auction to sell the
item to buyers
Sub-scenario of
bid successful
Sub-scenario of
bid failed
24/3/2009
51
Step 4: Identify and specify behaviours rules
for the service provider and represent them
as behaviour diagrams for the provider caste
Example: Behaviour rules for auction service providers in the
interaction with buyers.
 When a buyer requested to join the auction, its credit must be checked
and the membership issued if its credit is OK;
 When receives a bid from a member buyer, it must acknowledge of the
receipt of the bid with a unique bid identifier;
 Every received bid must be compared with the current best bid. If the
new bid beats the current best bid, the new bid becomes the current best
bid; otherwise, a failure message is sent to the bidder;
 By the scheduled finish time of the auction, an acceptance message must
be sent to the bidder of the best bid;
 Payment from the bid winner must be cleared and fund transferred to the
seller with commission charged with the agreed commission rate.
24/3/2009
52
Example: A Rule of Provider Caste
Rule: When a buyer requested to join the auction, its credit
must be checked and the membership issued if its credit is
OK.
24/3/2009
53
Step 5: identify and specify the assumptions on the
service requesters’ behaviour and also represent
them as behaviour diagrams for their castes
Example: Behaviour rules for buyers in the interactions with the
auction service provider.
• A buyer must join an auction before the scheduled start date of
the auction and become a member of the auction before it
submits any bid;
• A buyer’s bid for an item must be better than the current
best bid for the item;
• By the scheduled finish time of the auction, only the best
bid is accepted and its buyer must buy the item;
• If a buyer’s bid is beaten by another bid (from another
bidder or from the same buyer), the beaten bid is failed,
which means the buyer cannot buy the item;
• A buyer can quit from the auction only if after its bid failed.
24/3/2009
54
Note
• The complete protocol for the interaction between
buyer and the auctioneer is expressed as two sets
of rules.
– One is for the auctioneer, and
– One for the buyers
• The model from the service provider’s perspective
consists of the following
– A caste diagram describes the architecture of the
system from provider’s view
– A set of collaboration diagram describes
communications and scenarios
– A set of beahviour diagram, one for each caste
• the Buyer caste, the Seller caste, and the auction provider
24/3/2009
55
Service Requester’s Perspective
Example:
Consider an online flight ticketing service that sells air
tickets of an airline via an e-commerce web site.
Business rules:
– Example: to sell the unsold tickets by online auction when
the time reaches 7 days before the scheduled date of flight.
– The normal business rules and process of the software is
specified as a caste called TicketSeller.
Architectural solutions:
– Agents that sell tickets by online auction must also obey
the auction protocol.
– Two solutions: sub-caste vs dynamic casteship
24/3/2009
56
Solution 1: Sub-Caste
• A new caste SellByAuction is created
24/3/2009
57
Solution 2: Dynamic Casteship
• Agents of the TicketSeller can join the
caste Seller
24/3/2009
58
Overall Structure of CAMLE Models of WS
Model for Developing Service A
Model of the agents that
provide service B
Model of the agents that
request service B
Model of the agents
that implement the
internal business logic
of service B
Model for Developing
Service B
Model of the agents that
provide service A
Model of the agents that
request service A
Model of the agents that
provide service C
Model of the agents that
request service C
Model of the agents
that implement the
internal business
logic of service A
Model of the agents
that implement the
internal business
logic of service C
Model for Developing Service C
Modelling and specification of WS is not just a problem of defining the interface
+ workflow. It is more closely related to semantics that are beyond ontology.
24/3/2009
59
5. Programming Language SLABSp
• To gain experiences in directly implementing
MAS in an agent-oriented programming
language as a key step toward a new paradigm
• Experiments with the design and implementation
of agent-oriented programming languages
based on the caste centric meta-model
– To test the feasibility of the concepts and language
facilities of agent-oriented programming language
– To test the caste-centric agent-oriented programming
style
See (Wang, Shen & Zhu, 2004, 2005a, 2005b) for details.
24/3/2009
60
Structure of SLABSp Programs
agent ::=
(Java-Import)*
‘agent’ name [‘extends’ name (‘,’ name)*]
‘{’ (element | Java-Definition)* ‘}’
caste ::=
(Java-Import)*
‘caste’ name [‘extends’ name (‘,’ name)*]
‘{’ (element | Java-Definition)*
‘}’
element ::=
state-element
| action-element
| behavior-element
24/3/2009
61
state-element ::=
[‘internal’] ‘state’ type-id id ‘(’ parameter-list ‘)’
‘{’ (Java-Definition | getf | setf )* ‘}’
getf ::= ‘get’ ‘{’ Java-Code ‘}’
setf ::= ‘set’ ‘{’ Java-Code ‘}’
action-element ::=
[‘internal’] ‘action’ id ‘(’ parameter-list ‘)’
‘{’ ‘do’ ‘{’ Java-Code ‘}’ (Java-Definition)* ‘}’
behavior-element ::=
‘behavior’ id ‘{’ ‘do’ ‘{’ Java-Code ‘}’ ‘}’
‘when’ ‘{’ pattern ‘}’
‘while’ ‘{‘ scenario ‘}’
24/3/2009
62
scenario ::=
agent-id ‘:’ pattern
| relation-expression
| ‘for’ (number | ‘all’) caste-id `:’ pattern
| scenario ‘and’ scenario
| scenario ‘or’ scenario
| ‘not’ scenario
pattern ::= ‘[’ sequence-unit (‘,’ sequence-unit)* ‘]’
sequence-unit ::=
action-pattern
| ‘!’ state-assertion
24/3/2009
63
Example 1
import java.lang.*;
caste Worker{
state int flag() {
int v = 0;
get {return v;}
set {v = value;}
}
action sleep(){
do{ System.out.println(getAgentName() + " : I'm so tired, ~zZ");
try{ Thread.sleep(10*1000); // 10 seconds
}catch(InterruptedException e){ }
} }
action work(){ // work hard
do{ System.out.println(getAgentName() + " : I'm full of energy! #####"); }
}
behavior sleep(){
do{ state flag() = 1; action sleep(); } }when{ [! state flag() == 0] } while{ }
behavior work(){
do{ state flag() = 0; action work(); } }when{ [state flag() == 0] } while{ }
}
24/3/2009
64
Example 2
24/3/2009
65
Overview of the implementation of SLABSp
SLABSp Source
(*.p)
SLABSp
Library
SLABSp Compiler
Java Source
(*.java)
Java Agent
Components
Java Compiler
Java Bytecode
(*.class)
SLABSp Runtime Platform
Java Virtual Machine
24/3/2009
66
Runtime Platform
• Based on JVM
Security
Naming
Lifecycle
JacPlatform
Platform
JacAgentContainer
Codebase
JacCasteContainer
Communicate
Evolution
Distribute
JacAgent
Container
Distribute
JacCaste
<<Interface>>
Runnable
Administration
More details can be found in (Ji, Shen & Zhu, 2004, 2005a)
24/3/2009
67
Dynamic execution process
The agent periodically checks condition of its
behavior rules.
behavior
behavior
Behavior rule
<<Thread>>
Agent
Action
Action
Action
An action will be
taken if the condition
of a behavior rule is
satisfied.
The condition of the
behavior rules are
defined in terms of
environment
scenarios.
Scenario
Scenario
Scenario
The evaluation of a scenario depends on the states
and actions of the agents in the environment.
Environment
Agent
Agent
Agent
24/3/2009
Caste
Caste
Caste
68
6. Pure Agent-oriented
programming language
CAOPLE
• The language CAOPLE
• Virtual machine CAVM
24/3/2009
69
Example: A Simple CAOPLE Program (1)
caste Peer;
observes all p in Peer;
action say(word: String) { };
Init say(“Hello”);
endcaste Peer.
caste FriendlyPeer <=Peer;
body
when exist p in Peer: [say(“Hello”)]
-> then say(“Welcome”);
end;
endcaste FriendlyPeer.
caste CheerfulPeer <=Peer;
body
when exist p in Peer: [say(“Hello”)]
-> then say(“Hi, good morning.”);
end;
endcaste CheerfulPeer.
24/3/2009
Main features:
Network transparency:
• Multiple agents running
on computers over a
network
• Code deployed on
different computers
Heterogeneous
behaviours in
response to an event
70
Example: A Simple CAOPLE Program (2)
caste Peer;
observes all p in Peer;
action say(word: String) { };
Init say(“Hello”);
endcaste Peer.
caste Display<= Textbox;
observes all p in Peer;
var m: String;
body
when exist p in Peer: [say(m)]
->begin
Output(
AgentID(p)# “ says: ” # m);
end
end
endcaste Display
24/3/2009
Separation of concerns:
• Computation algorithm
• Input/output
• Book keeping
caste Monitor;
observes all p in Peer;
var MessageCount: Integer;
init MessageCount := 0;
body
when exist p in Peer: [say(x)]
->begin
MessageCount :=
MessageCount + 1;
end
end
endcaste Monitor
71
Example: A Simple CAOPLE Program (3)
caste Peer;
observes all p in Peer;
action say(word: String) { };
Init say(“Hello”);
endcaste Peer.
Context and environment
caste SmartPeer <=Peer;
Observes LocalDateTime: DateTime;
body
When
LocalDateTime.Day = Monday
-> Join (FriendlyPeer);
LocalDateTime.Day <> Monday
-> Join (CheerfulPeer);
end;
endcaste SmartPeer.
24/3/2009
Adaptive behaviour
• An agent can
autonomously join and
quit a caste to change its
role and so to change its
behaviour
• An agent’s behaviour can
be context sensitive to the
change in its environment
Adaptation of
behaviour according
to the context
72
Overview of CAOPLE Language
Prog ::= {<TypeDec> }* {<CasteDec>}*
<TypeDec> ::= type <TypeExp> {; <TypeExp>} end
<TypeExp> ::= <PrimitiveType>|<StructureType>
<CasteDec> ::=
caste <CasteName>[<parameters>] [Inheritances];
[<EnvironmentDecs>]
[<StateDecs>]
[<ActionDecs>]
init <statement>;
body
[<LocalDecs>;]
<Statement>
endcaste <CasteName>
24/3/2009
73
<EnvironmentDecs> ::= observes {<EnvDec> ; }
<EnvDec> ::= <AgentId>
| all <ID> in <CasteID>
| var <IDList> in <CasteID> [:=<AgentID>]
| set <IDList> in <CasteID> [:=<AgentSetExp>]
<StateDecs> ::= { <StateDec> ; }
<StateDec> ::= var <IDList>:<Type>[:= <ConstExp>]
<ActionDecs> ::= {<ActionDec> ; }
<ActionDec> ::=
action <IDList> [ ( <ParameterList> )] [<ActionBody>]
<ActionBody> ::= <Statement>
24/3/2009
74
<Statement>::=
<Assignment>
| begin <Statement> {; <Statement>} end
| <ActionEvent>
| <CasteEvent>
| <AgentEvent>
| <WhenStatement> | <withStatement>
| <LoopStatement> | <ForAllStatement>
| <IfStatement>
| <CaseStatement>
<WithStatement> ::=
with <Exp> do <Statement> end
<WhenStatement> ::=
When {<Scenario> -> <Statement> } End
24/3/2009
75
<CasteEvent> ::=
join <CasteID>[( <ActuralPara> )]
|quit <CasteID>
|suspend <CasteID>
|resume <CasteID>
<AgentEvent> ::=
create [<var> of] <CasteID>[( <ActuralPara> )] [@<URL>]
| destroy [<var>]
24/3/2009
76
7. Virtual Machine CAVM: Architecture
Communication
Engine
Computer C2
Computer C1
CE2
Computer Cn
LEEk
CE1
Computer C3
LEE1
LEE2
LEE3
Local Execution
Engine
24/3/2009
77
Structure of LEE
network
local
Communication Manager
Memory Space
Agent Am
context data
Program Space
Central
Processing
Unit (CPU)
Context
Registers
List of Loaded Castes (LLC)
…
Loader
PC
Environment data
List of Agents (LoA)
24/3/2009
Agent A1
context data
network
object code
OC1
object code
OC2
…
object code
OCn
78
Structure of CE
network
local
network
Publication Space
Agent A1 s/a
data
…
Agent Ai s/a
data
Membership List
(of active Agents)
24/3/2009
Receiver
Dispatcher
Communication
Manager
Deployment
Manager
Membership
Manager
Caste
object code
79
Deploy & Execute CAOPLE Programs
CAOPLE
Source Code
Compile
CAVM Object Code
Caste SC1 Caste SC
n
Caste OC1
Caste OCn
Deploy
Computer C2
Computer C1
CE1
CE2
Computer Cn
Computer C3
LEE1
24/3/2009
LEEk
LEE2
80
Caste Deployment
The deployment tool supports distributed deployment of
object code through the internet.
24/3/2009
81
CAVM’s Messages
A
a
<create or join>
LEE
Register/Unregister
<member list>
CE
<destroy or quit>
observe
<env. instructions> b
LEE
<upd. instructions> a
A
update
CE
<pub space>
update
b
<dyn. membership>
LEE
A
instanceset
CE
<member list>
a a
a
24/3/2009
82
CAVM Instructions
• Three categories of CAVM instructions
– computation instructions perform computation
and local control functions
– interaction instructions deal with the
interactions between agents and castes
– external invocation instructions are those
operations facilitating CAVM’s interaction with
native environment, and debugging purpose
24/3/2009
83
Examples of Instructions
•
•
•
•
•
•
•
•
•
•
•
…
loadcaste 0
agentnew
agentalloc
dup
storevar 3
agentreg
sendmessage
agentregpost
agentready
…
24/3/2009
# load a caste referenced by constant[0]
# create new agent context
# allocate agentInfo (memory space)
# duplicate agentinfo at the stack top
# store agent's variable to localvar[3]
# prepare and push the register message
# send the message
# postprocess the response
# mark agent context as ready
84
Implementation
• A prototype system of CAVM has been
implemented with C/C++
– LEE and CE are realized as two separate
CLR console servers
– GUI Management tool
– make use of .NET platform for XML
processing and messaging support
24/3/2009
85
Experiments with CAVM
• 5 experiments
– basic functions
of LEE and CE
– deployment and
interaction
– performance
and scalability
– centralized
(localhost) vs.
distributed (LAN)
24/3/2009
Peer-1:
Monitor-1:
caste Peer;
action sayHello()
begin //do nothing end
body
sayHello()
endcaste Peer
caste Monitor;
observes
all p in Peer;
var
numOfPeers: Integer;
init
numOfPeers := 0;
body
when
exist p in Peer:[sayHello()]
->
begin
numOfPeers
:= numOfPeers + 1;
output(
“Number of Peers:”,
numOfPeers);
end
end
endcaste Monitor
Peer-2:
caste Peer;
observes all p in Peer;
action sayHello()
begin //do nothing end
action welcome(P:
AgentID of Peer)
begin //do nothing end
body
when exist p in Peer:
[sayHello()]
-> if (p<>self)
then welcome(p);
end;
endcaste Peer
86
Exp. 1 and 2 - basic
Exp.1 and Exp.2 - Instructions
Exp.1 and Exp.2 - Messages
5
50
40
Exp.1
Exp.2
30
20
10
0
0
20
40
60
Number of Agents
80
100
Messages/ms
Instructions/ms
60
4
3
Exp.1
Exp.2
2
1
0
0
20
40
60
80
100
Number of Agents
• Peer-1 + Monitor-1 (Exp1: centralized; Exp2: distributed)
– The performances of LEE in terms of IPmS (Instruction per Milli-second) and
MPmS increase as the agent number increases
– reached the peak when the number of agents was around 20, then gradually
decreased
– satisfactory scalability - performance decreases slowly as the number of
Peer-1 agents increases from 40 to 100
24/3/2009
87
Exp. 3 - scalability centralized
Exp.3 - Instructions
Exp.3 - Messages
20
Messages/ms
Instructions/ms
25
15
10
5
0
10
20
30
40
50
60
70
80
Number of Agents
90
100
1.4
1.2
1
0.8
0.6
0.4
0.2
0
10
20
30
40
50
60
70
80
90
100
Number of Agents
• Peer-2 centralized
– agents are created and added into the system one by
one - up to 100 agents on one LEE.
– same pattern of performance change with agent
numbers
24/3/2009
88
Exp. 4 - scalability distributed
Exp.4 - Messages
10
0.6
8
0.5
Messages/ms
Instructions/ms
Exp.4 - Instructions
6
4
2
0.4
0.3
0.2
0.1
0
0
100
200
300
400
500
Number of Agents
600
100
200
300
400
500
600
Number of Agents
• Peer-2 distributed
– LEEs are hosted by 1-6 PCs connect by LAN
– Each LEE hosts 100 agents, so the total agent
numbers in the system are from 100 up to 600
24/3/2009
89
Exp. 5 - execution time
Exp. 5 - Messages
Exp. 5 - Instructions
80
0.2
Messages/ms
0.25
Instructions/ms
100
60
40
20
0.15
0.1
0.05
0
0
0
500
1000
1500
2000
Execution Time (ms)
2500
0
500
1000
1500
2000
2500
Execution Time (ms)
• Peer-0 + Monitor-0
– average performance measures over execution time
of Peer-0 and Monitor-0 (the example we used before)
– observations among agents from different castes.
24/3/2009
90
Conclusion
• Agent-orientation provides a more powerful
metaphor for the development of information
systems
– Agent/object mixture approach: ‘Agents manipulates
objects’, rather than ‘everything is object’.
– Pure agent-orientation approach: ‘Everything is agent’
• Agent-orientation suitable for emerging
technologies and novel applications, including
web services applications, pervasive computing,
etc.
– Shift of focus from control to cooperation
• CAMLE provides a coherent set of language
facilities supports the principle of agentorientation
24/3/2009
91
Work in Progress and Future Work
• Developing the compiler of CAOPLE
programming language
• Developing GUI library for CAOPLE
• Tools support scenario calculus (automated
reasoning about emergent behaviours in MAS)
• Implementation of CAVM for other computation
platforms such as, sensor network platform,
handheld devices, mobile phones, etc.
• Agent-oriented programming for multiple core
hardware platform
• Design patterns for caste centric multi-agent
systems
24/3/2009
92
Acknowledgement
The work reported in this tutorial are
based on collaborations with my colleagues
and students at Oxford Brookes University,
UK, and The National University of Defence
Technology, China, which include Lijun Shan,
Dr. Bin Zhou, Prof. Ji Wang, Rui Shen, Prof.
Xinjun Mao, David Lightfoot, Dr. Sue
Greenwood, Dr. Yanlong Zhang, Qingning
Huo, Dr. Fang Wang, etc.
24/3/2009
93
References
For the list of publications on caste centric
methodology, please see
http://cms.brookes.ac.uk/staff/HongZhu/Publ
ication.htm
24/3/2009
94