Developing Formal Specifications of MAS in SLABS
Download
Report
Transcript Developing Formal Specifications of MAS in SLABS
SLABS
-- A Formal Specification Language for
Agent-Oriented Software Engineering
Hong Zhu
Dept of Computing,
School of Technology, Oxford Brookes University
Wheatley Campus, Oxford, OX33 1HX, UK
Email: [email protected]
AFM Seminar, Jan. 2003
1
Outline
• Introduction
– Motivation and context
• Conceptual model of multi-agent systems
– Agent, caste, and environment
• Overview of the SLABS language
• Developing specifications in SLABS
– Process and notations for agent-oriented modelling
• Example:
– Amalthaea- A multi-agent evolutionary ecosystem
• Conclusion
AFM Seminar, Jan. 2003
2
Introduction
What Are Agents
‘An agent is an encapsulated computer system that is situated in some
environment, and that is capable of flexible, autonomous actions in
that environment in order to meet its design objectives.’
(N.R. Jennings,1999)
– Autonomy:
The capability of controlling over its internal state and action
– Pro-activity:
The capability of initiating actions to achieve its goal
– Re-activity:
The capability of responding to events in the environment
– Social ability:
The capability of interacting with other artificial agents and humans
AFM Seminar, Jan. 2003
3
Why Agent-Orientation
• Agent-orientation:
Software development that treats agents as first class entities
throughout the whole lifecycle and uses agents as basic building
blocks of software systems.
• Advantages:
– A rich metaphor for software system modelling and
analysis that
• matches the real world
• contains object-orientation as subset
– A modularity and encapsulation facility that
• highly composable
• suitable for dynamic environments such as the Internet and the
Web
AFM Seminar, Jan. 2003
4
Current State of Art
• AI domination in research on agent technology
– Research on agent technology is mostly in the AI area
– Formal logic and formal model of agents are dominated
by mentalist theories of agents such as BDI and game
theory, e.g.
• Object orientation of implementation and methods
– Implementation of agent-based systems mostly in objectoriented languages, such as Java
– Tools and platforms for developing agent-based systems
are mostly targeted to implement agents in object-oriented
languages
– Recent diagrammatic notations and methods for ‘agentoriented’ analysis, design and modelling begin with
agents, but aim to derive an object-oriented program
• Wooldridge, M., Jennings, N., Kinny, D., 1999
• Bauer, B., Muller, J.P., and Odell, J. , 2001
AFM Seminar, Jan. 2003
5
Why Formal Specification of MAS
• Lack of rigor is one of the main factors that hampers the
wide adoption of agent technology
– (Brazier, Dunin-Keplicz, Jennings, Treur, 1997)
• Agent technology is increasingly applied to safety critical
areas
• Difficulty in understanding and predicting agents’
intelligent behaviours
• Lack of language facilities and tools to realise the
potential of agent-orientation
AFM Seminar, Jan. 2003
6
Components of Agent-Oriented Methodology
Modelling,
Analysis&Design
(A Diagrammatic
Notation)
Specification
& Formal
Logic
(SLABS)
Development Process
(Growth Model)
Implementation
& Programming
Language
Computational
Model of MAS
Maintenance
& Testing
(AquIS)
Model of Tools and
Software Environments
Conceptual Model of MAS
AFM Seminar, Jan. 2003
7
Conceptual Model of MAS
The Concept of Agent
Agents are encapsulated active computational entities
comprising data, operations and behaviours that situate
in their designated environments.
– Data represents an agent's state.
– Operations are the actions that an agent can take.
– Behaviour is a collection of sequences of state changes and
operations performed by the agent in the context of its
environment.
– Encapsulation means that:
• an agent's state can only be changed by the agent itself.
• an agent has its own rules that govern its behaviour in its
designated environment.
AFM Seminar, Jan. 2003
8
A Constructive Definition of Agents
Agents are active computational entities with a structure
comprising the following elements.
–Name, the agent’s identity.
–Environment description, what the agent interacts with.
–State, a set of variables divided into two parts: the visible
state and internal state.
–Actions, the atomic actions that the agent can take.
• Each action has a name and may have parameters.
• An action can be externally visible or only internally visible
–Behaviour rules, which determine the behaviour of the
agent.
AFM Seminar, Jan. 2003
9
Caste: The Central Concept of Our Model
• Castes are natural evolution of the notion of class
– Agents are instances of castes. The agents of a caste, thus,
have common structural and behavioural characteristics.
– Castes have inheritance relations between them.
• Castes are not static classification of concepts
– An agent can joint into a caste and retreat from a caste
dynamically at run-time.
– Caste can model and implement other notions in agent
metaphor
• Roles
• Agent society, etc.
AFM Seminar, Jan. 2003
10
The Model of MAS
Summary
Agent = <Data, Operations, Behaviour>Environment
Castes = { agents | structure characteristics
& behaviour characteristics}
Multi-agent system MAS = {Agentn}nI
Environment time (Agent, MAS) MAS – {Agent}
Communication( A to B) = A.Action + B.Observation
AFM Seminar, Jan. 2003
11
The SLABS language
SLABS stands for Specification Language for Agent-Based
Systems.
– Based on my previous work on the language STOC
– Proposed in FAABS’2000;
– Definition of syntax and semantics
• Journal of Software Engineering and Knowledge Engineering, Nov. 2001;
• AAMAS’2003: Semantics of dynamic castes
– Examples:
• Personal assistant: Maxims
• Speech-act
• Ants
• Communication protocol
• Evolutionary multi-agent ecosystem (Amalthaea)
• Distributed synchronisation algorithm
• Web services
AFM Seminar, Jan. 2003
12
Specifications in SLABS
• A specification of a multi-agent system in SLABS
consists of a set of specifications of agents and castes.
Name <= castes (instantiation)
Visible state-variables and actions
Invisible state-variables and actions
Agent
description
Environment
Behaviour-specification
description
Name: castes (Instantiation)
Visible state-variables and actions
Caste
description
AFM Seminar, Jan. 2003
Invisible state-variables and actions
Environment
Behaviour-specification
description
13
Inheritance
Let C be a caste specified as follows.
Caste C <= C1(x11:=exp11, …, x1n1:= exp1n1),
…, Ck(xk1:=expk1, …, xknk:=expknk )
ENV
EC1, …, ECw;
VAR
*v1:T1, …, *vm:Tm; u1:S1, …, ul:Sl;
ACTION *A1(p1), …, *As(ps); B1(q1), …, Bt(qt);
RULES
R1, R2, …, Rh
End C;
• Caste C inherits from C1, …, Ck the state space, actions,
environment descriptions, and behaviour rules
• Caste C also has its additional state space, actions,
environment descriptions and behaviour rules
AFM Seminar, Jan. 2003
14
Inherited State Space and Actions
• Let SV(C) and SI(C) denote the visible and invisible
state spaces of a caste C, respectively.
SV(C) = {C.v1:T1, …, C.vm:Tm}
SI(C) = {C.u1:S1, …, C.uj:Sj}
k
k
S V (Cx )
x 1
S I (Cx )
x 1
• Let SV(C) and SI(C) denote the visible and invisible
action spaces of caste C, respectively.
k
SV(C)
= {C.A1(p1), …, C.As(ps)}
SI(C) = {C.B1(q1), …, C.Bt(qt)}
V (Cx )
x 1
k
I (Cx )
x 1
AFM Seminar, Jan. 2003
15
Inherited Environment and Behaviour Rules
• Let RULE(C) denote the set of behaviour rules of caste
C. We have that
RULE(C) = {R1, …, Rh}
k
RULE (Cx )
x 1
• Let ENV(C) denote the environment for caste C, we
have that
k
ENV(C)= {EC1, …, ECw}
AFM Seminar, Jan. 2003
ENV (Cx )
x 1
16
Dynamic Caste
• Let agent A be a member of castes C1, C2, …, Cn at run-time t.
The state space of agent A at time t is denoted by SA,t.
S VA,t
n
S V (Ci )
i 1
S AI ,t
n
S I (Ci )
i 1
The set of actions that an agent can take at time t is denoted by SA,T.
SVA,t
n
SV (Ci )
S IA,t
i 1
n
S I (Ci )
i 1
The set of rules that agent A must satisfy at time t is the set RULEA,t
RULEA,t
n
RULE(Ci )
i 1
AFM Seminar, Jan. 2003
17
Changing Environments
The environment of agent A at run-time t is denoted by EnvA,t
EC
t
, where
ECENV *A ,t
agent
n
ENV *A,t
ENV (Ci )
i 1
t
{agent}
All : Caste t { X | X t Caste}
x : Caste t { Ak } , if x:= Ak
AFM Seminar, Jan. 2003
18
Behaviour Rules
• An agent's behaviour is defined by a set of rules as
its responses to environment scenarios.
Behaviour-rule ::=
[<rule-name>] pattern|[ prob]->event,
[if Scenario]
[where pre-cond] ;
• For example: The behaviour rule for search engines
[$] |-> Search_Result(keywords, urls);
if A:[Search(Self, keywords)]
AFM Seminar, Jan. 2003
19
Patterns of Agent’s Behaviour
Pattern
Meaning
$
The wild card, which matches with all actions
~
The silence event
Variable
P^k
! Predicate
Act(a1, ...ak)
[p1,..., pn]
AFM Seminar, Jan. 2003
It matches an action
A sequence of k events that match pattern P
The state of the agent satisfies the predicate
An action Act that takes place with parameters
match (a1, a2, ...ak)
The previous sequence of events match the
patterns p1, ..., pn
20
Scenarios
Scenario
Meaning
A: P
Agent A's behaviour matches pattern P
XC: P
The behaviours of all agents in caste C match pattern P
[m]XC: P
At least m agents in caste C whose behaviour match P
XC: P
The number of agents in C whose behaviour matches P
S1 & S2
The situation when both scenario S1 and S2 are true
S1 S2
The situation when either scenario S1 or S2 or both are true
S
The situation when scenario S is not true
AFM Seminar, Jan. 2003
21
Process of Developing Specification in SLABS
When an agent’s behaviour is too complicated
Architectural
analysis
Formal Spec
in SLABS
Structural
Model
Interaction
analysis
Interaction
Model
Derivation of
formal spec
Behaviour
Rules
Scenario
analysis
•
Architectural analysis: identify the agents and castes.
•
Interaction analysis: identify the interactions between the agents by
recognising their visible actions and states
•
Scenario analysis: identify the scenarios that an agent will deal
with and its designed behaviour in such a scenario.
AFM Seminar, Jan. 2003
22
Diagrammatic Notation for Agent Models
Nodes
Agent
A
B
A
B
A
B
B
Links
AFM Seminar, Jan. 2003
Caste
Agent B observes the visible behaviour of
agent A
Agent A takes an action that agent B observes
for all agents in the environment
Agent B observes the visible behaviour of all
agents in the caste A
Agent B observes the visible behaviour of all
agents in its environment
Each agent in caste B observes the visible
behaviour of a specific agent XB in caste A
A
B
A
B
Every agent in caste B observes the visible
behaviour of all agents in the caste A
A
B
Every agent in caste B observes the visible
behaviour of agent A
23
Decomposition and Refinement
AgentX
Action Act1(...); Act2 (....)
Action ActInternal(...)
E1
E2
C1
AFM Seminar, Jan. 2003
ActInternal(...)
Act1(...)
Y1
Y2
Act2(...)
24
Example: Amalthaea
• Developed at MIT Media Laboratory
by A. Moukas et al.1997
• Main purpose:
– To assist its users in finding
interesting information on the web.
• Main feature:
– Multi-agent system: two species of
agents
• filtering agents model and
monitor the interests of the user
• discovery agents model the
information sources.
– Evolutionary: agents evolve,
compete and collaborate in a
market-like ecosystem.
– Keep track of the changing interests
of the user.
AFM Seminar, Jan. 2003
25
Amalthaea’s Overall Architecture
AFM Seminar, Jan. 2003
26
Amalthaea’s Architecture in AML
User
Rate(url, r)
Present_Digest(url)
Interface
Pass_Rate(url, r)
Store(url, wkv),
Query(url, wkv)
Database
Submit(url, confidence)
Extract(file)
Ecosystem
Stored(url, wkv,succ)
Query_Result(url, wkv, answer)
Search(engine, keywords)
WKV
Extractor
Extracted(file, wkv)
Search_Result(keywords, urls)
Search engine
AFM Seminar, Jan. 2003
27
Specification of Simple Agents
Interface
Action Present_Digets(url: URL)
Pass_Rate (url: URL, rate: {1, 2, 3, 4, 5})
User
[$] |-> Pass_Rate(url, r); if User: [Rate(url, r)]
Ecosystem [$] |-> Present_digest(url); if Ecosystem: [Submit(url)]
WKV Generator
Action Extracted (f: HTML_file, k: WKV)
All
AFM Seminar, Jan. 2003
[$] |-> Extracted(f, wkv) ; if A:[Extract(f)]
28
Specification of Simple Agents (continue)
Search Engines
Action Search_Result (K: Keywords, urls: set of URL)
All
[$] |-> Search_Result(keywords, urls); if A: [Search( Self, keywords)]
Database
Action Query_Result (url: URL, wkv: WKV, answer:{'yes', 'no'})
Stored (url: URL, wkv: WKV, answer:{'success', 'failure'})
All
[$, Stored(url, wkv, ‘success’), $^k || k0 ] |-> Query_Result(url, wkv, 'yes');
if A:[Query(url, wkv)]
~ [$, Stored(url, wkv, ‘success’), $^k || k0 ] |-> Query_Result(url, wkv, 'no');
if A:[Query(url, wkv)]
[$] |-> Stored(url, wkv, 'success'); if A:[Store(url, wkv)]
User
Action Rate(url: URL, r: {1, 2, 3, 4, 5})
Interface
AFM Seminar, Jan. 2003
[$] |-> Rate(url, r);
if Interface: [$, Present_Digest(url), $^k || N > k 0 ]
29
Decomposition of the Ecosystem
Ecosystem
Action Search(E: Engine, K: Keywords); Submit(url: URL, confidence: Real);
Store(url:URL, wkv: WKV); Extrat(F: HTML_file);
Query(url, URL, wkv: WKV);
Pass-Rate(url, r)
Credit(Agent, c)
Submit(url, confidence)
Pay(c)
Information
filtering agents
Interface
Interest(keywords)
Available(url, wkv)
Search(engine, keywords)
Search
Information
Engines
discovery agents
Search_Result(keywords, urls)
Extract(file)
Credit(Agent, c)
Store(url, wkv)
Query(url, wkv)
Database
Stored(url, wkv)
Query_Result(url, wkv, ans)
Extracted(file, wkv)
WKV Generator
AFM Seminar, Jan. 2003
30
Internal Structure of IFAs
Genotype
Phenotype
Fitness
(Credits)
Weight
Weight
Weight
Keyword
Keyword
Keyword
Creation
User
Date
Created?
Execution
code
Internal State:
Var
Fitness: Integer;
CreationDate: Date;
UserCreated: Bool;
Genotype: WKV;
AFM Seminar, Jan. 2003
31
Identification of Scenarios
Four scenarios are identified for IFAs:
–
Scenario 1: when the Ecosystem credits the agent.
–
Scenario 2: when it is the time to pay the rent.
–
Scenario 3: announce interests in a topic.
–
Scenario 4: select url when the information about
a topic is available after an information discovery
agent retrieved from the Internet.
AFM Seminar, Jan. 2003
32
Behaviour Descriptions
• In scenario 1, when the Ecosystem takes an internal action of
crediting the agent, the agent will increase the fitness by the
amount of the credit assigned.
[!(fitness=x) ] |-> !(fitness = x+c);
if Ecosystem: [credit(self, c)]
• In scenario 2, when it is the time to pay the rent, the agent
will take a visible action of pay and decrease the fitness by
the amount of payment.
[!(fitness=x) ] |-> t: pay(c) !(fitness = x-c);
where pay_time(t)
pay_time: Time Bool
pay_time(t) = true; t mod 100 = 0
pay_time(t) = false; t mod 100 0
AFM Seminar, Jan. 2003
33
Specification of IFAs
IFA
Action Recommend(Title, URL); Request(keywords); Pay Rental (Natural)
Var
Fitness: Integer; Creation Date: Date; User Created: Bool;
Genotype: WKV
All: IDA
[!(fitness=x) ] |-> !(fitness = x+c); if Ecosystem: [credit(self, c)]
[!(fitness=x) ] |-> t: pay(c) !(fitness = x-c); where pay_time(t)
Ecosystem [$] |-> Interest(keys(Self.genotype));
[Interest(keywords)] |-> Submit(url, confidence);
Interface
if AIDA: [Available(urls, wkv)]
where confidence=Distance(genotype, wkv)
and confidence > threshold
AFM Seminar, Jan. 2003
34
Specification of DFAs
Action
Var
All: IFA
Ecosystem
E: Search
Engines
Database
WKV
Generator
IDA
Search(engine:Search Engine, keywords: set of keywords, max, min: Natural)
Pay (rent: Natural); Extract(f: HTML_file); Query(url: URL, wkv: WKV)
Store(url: URL, wkv: WKV); Available(url: URL, wkv: WKV)
Fitness: Integer; Creation Date: Date; SearchEngine: Search Engines
NumberOfkKeywords, MinimumHits, MaximunHits: Natural
[!(fitness=x) ] |-> !(fitness = x+c); if Ecosystem: credit(Self, c)
[!(fitness=x) ] |-> t: pay(c) !(fitness = x-c); where pay_time(t)
[$] |-> search(Self.SearchEngine, keywords, Self.minimum_hit, Self.maximum_hit);
if A: [Interest(keywords)], where Good_Track_Record(A)=true
[search(Engine, keywords, min, max) ]
|-> Forall file {f at u | u urls}. Extract(file);
if Engine:[Search_Result(keyword, urls)]
[Extract(file)] |-> Query(url, wkv); if WKV Generator : [Extracted(file, wkv)]
[Query(url, wkv)] |-> Available(url, wkv);
if DataBase:[Query_Result(url, wkv, 'no')]
AFM Seminar, Jan. 2003
35
Behaviour of the Ecosystem
• Scenario 1: Credit the agents
– Scenario: when the Interface passed the user's rating on a
presented digest to the Ecosystem
– Action: the system assign credits to the filtering agents
that proposed the item and the discovery agent that
retrieved it.
– Rule in SLABS:
[$] |-> (Credit(A, c1), Credit(B, c2)) ;
if
Interface: [Pass_rate( url, r)]
& A: [$, Submit(url, confidence), $^k]
& B: [Available(url, wkv), $^k'],
where c1=Credit_IFA(r, confidence) and
c2=Credit_IDA(r)
AFM Seminar, Jan. 2003
36
• Scenario 2: Evolution
– Scenario: After all agents paid rental
– Actions: Purge bad agents and produce offspring from
good agents
– Rule of purge:
[!(AIFAIDA)] |-> Purge(A) !(AIFAIDA) ;
if
X:IFA:[Pay(c)] and Y:IDA:[Pay(c)] and
Interface:[Pass_rating(rn)^N]
where APurgeSet & PurgeSet{X| XIFA or XIDA} &
XPurgeSet.YPurgeSet. (X.fitnessY.Fitness}
& ||PurgeSet|| = Number_of_Purges(<rn>n=1,...,N)
– Rule of production of offspring:
[!(AIFAIDA)] |-> Generate(A) !(AIFAIDA) ;
if X:IFA:[Pay(c)] & Y:IDA:[Pay(c)] &
Interface:[Pass_rating(rn)^N],
where ANewAgentSet
AFM Seminar, Jan. 2003
37
The Ecosystem
Ecosystem
Action Search(E: Engine, K: Keywords); Submit(url: URL, confidence: Real)
Store(url:URL, wkv: WKV); Extract_WKV(F:HTML_file);
Query(url, URL, wkv: WKV)
Var
IFA: Caste Information_Filtering_Agents;
IDA: Caste Information_Discovery_Agents
Action Purge(A: Agent);
Generate(A: Agent)
[$] |-> (Credit(A, c1), Credit(B, c2)) ;
if Interface: [Pass_rating( url, r)] & A: [$, Submit(url, confidence), $^k]
& B: [Available(url, wkv), $^k'],
Interface
where c1=Credit_IFA(r, confidence) and c2=Credit_IDA(r, confidence)
All: Search [!(AIFAIDA)] |-> Purge(A) !(AIFAIDA) ;
if X:IFA:[Pay(c)] & Y:IDA:[Pay(c)] & Interface:[Pass_rating(rn)^N]
Engines
where APurgeSet and PurgeSet{X| XIFA or XIDA}
Database
and XPurgeSet.YPurgeSet. (X.fitnessY.Fitness}
and ||PurgeSet|| = Number_of_Purges(<rn>n=1,...,N)
WKV
[!(AIFAIDA)] |-> Generate(A) !(AIFAIDA) ;
Generator
if X:IFA:[Pay(c)] & Y:IDA:[Pay(c)] & Interface:[Pass_rating(rn)^N]
where ANewAgentSet & NewAgentSetSpec
AFM Seminar, Jan. 2003
38
Conclusion
• Strength
– In comparison with specification in Z: expressive and
suitable for multi-agent systems
• The evolution process as well as other intelligent behaviour of
MAS can be clearly and naturally described.
– In comparison with BDI logic, etc.: it bridges the gap
between informal and formal notations
• Helped to understand the system’s behaviour, and avoided over
dependence on AI terminology
• Informal models can be naturally transformed into the overall
structure of the formal specification.
• Weakness
– Cannot be implemented directly at the moment
– Lack of support to formally prove and analyse system’s
properties
AFM Seminar, Jan. 2003
39
Further Work
• Further development of the SLABS language
– Implementation of a syntax checker and editing tool
– Applications to solve problems in software engineering
research, such as
•
•
•
•
web services
component technology
software architecture
Aspect-oriented programming, etc.
• Logic for formal proofs and analysis of MAS
• Modelling language
– To automate the transformation from the diagrammatic
notation to formal specification in SLABS
– A diagrammatic notation to support scenarios analysis
• Computational model and programming languages
AFM Seminar, Jan. 2003
40