Formalizing the Reusability of
Software Agents
Federico Bergenti
AOT Lab
Parco Area delle Scienze, 181/A
43100 Parma, Italy
[email protected]
http://aot.ce.unipr.it
FRAMeTech S.R.L.
Via San Leonardo, 1
43100 Parma, Italy
[email protected]
http://www.frame-tech.it
Formalizing the Reusability of Software Agents
Software Reuse
• In principle, any artifact of the software lifecycle
can be reused
–
–
–
–
a
a
a
a
piece of specification (e.g., a use case),
piece of design (e.g., design pattern, architecture),
linkable module (e.g., DLL, .NET module),
pieces source code (e.g., STL).
• We focus on reusing linkable modules
– what do we need to deliver reusable modules?
– what is the maximum level of reusability we might
expect from a given technology?
ESAW 2003 - London
2
Formalizing the Reusability of Software Agents
Software Components
• Reusable (linkable) modules
that we assembly to build a
complete system.
• The functionality of the system
is developed making
components interact.
• The infrastructure is the glue
that enables interactions
Infrastructure
– linker of the operating system,
– CORBA, Web services, …,
– tuple spaces, blackboards.
• The infrastructure comprises
– a model (with associated
semantics) of the interaction,
– a communication means.
ESAW 2003 - London
3
Formalizing the Reusability of Software Agents
Substituibility
• Two possibilities of reuse
– reusing readymade components (component reuse),
– reusing a complete system that is customized by using new
components instead of old components (framework reuse).
• Historically, only the first was understood
– object-oriented inheritance as a means to reuse the code of base
classes in derived classes.
• Today, the second in largely preferred
– frameworks have been replacing libraries for a decade.
• Both are enabled by substituibility
– we substitute a component with another equivalent (from our
point of view), yet different, component.
ESAW 2003 - London
4
Formalizing the Reusability of Software Agents
Reusing Software Components
• The infrastructure plays a central role in (this sort) of
reusability
– it enables interactions,
– it supports substituibility.
• This is not strange, reusability is a feature of the
technology we use to build and assembly components.
• Today infrastructures put severe constraints on
reusability because they have limited models of
– interactions (e.g., object-oriented interactions are implemented
through method calls only),
– substituibility (e.g., object-oriented implements substituibility
with inheritance, that relies mainly on method signatures).
ESAW 2003 - London
5
Formalizing the Reusability of Software Agents
An Ideal Model of Reusability (1/3)
• In order to define an ideal model of (this sort) of
reusability, we need a “perfect” infrastructure
– “perfect” interaction,
– “perfect” substituibility.
• In the ideal world,
– interaction is solely driven by the solution we are designing for
the problem and no other constraints are imposed,
– substituibility depends only on what a component is used for and
not on how it is used.
• Informal concepts describing this ideal model are
available.
• We can formalize them using the ascription hypothesis.
ESAW 2003 - London
6
Formalizing the Reusability of Software Agents
An Ideal Model of Reusability (2/3)
Ascription Hypotesis
Given a component, we can ascribe mental qualities, i.e.,
knowledge and goals, to it.
• We require less than what is normally required
– components can be irrational, still we can ascribe
knowledge and goals to them,
– we do not need to be able to ascribe a mental state
to a component from the outside, components that
declare their mental state are sufficient.
• Components described in terms of their mental
qualities are agents.
ESAW 2003 - London
7
Formalizing the Reusability of Software Agents
An Ideal Model of Reusability (3/3)
• Need to define what a “perfect” interaction is
– we concentrate only on problem-independent issues,
– we move all such issues to the infrastructure because
agents should care of the problem only.
• Informally, an infrastructure enables a “perfect”
interaction if it puts no constraints in terms of
–
–
–
–
the different languages that agents use,
the need of knowing the peer before interacting,
the need of knowing the peer after interacting,
…
ESAW 2003 - London
8
Formalizing the Reusability of Software Agents
Semantic Interoperability (1/2)
• Normally, it is considered a first step towards
semantic composability.
• Abstracts away communication details from the
interaction.
Definition of Semantic Interoperability (Client Standpoint)
Given two agents C and SacquaintanceC, they are said to be
semantically interoperable if and only if
g : GCg, GCdone(delegate(C, S, g))  KSGCdone(delegate(C, S, g))
where delegate(C, S, g) is a sort of abstract action of C whose outcome
is KCGSg.
ESAW 2003 - London
9
Formalizing the Reusability of Software Agents
Semantic Interoperability (2/2)
The definition states that if (and only if)
C has a goal and
C wants some S to bring
GCg
then, S knows of this wish
 KSGCdone(delegate(C, S, g))
about this goal
GCdone(delegate(C, S, g))
• If we assume a common (limited) model of the world
and a common language, then semantic interoperability
is practical (even if not ideal).
• Today, the work directed towards semantic
interoperability (e.g., DAML-S) is limited by the use of
task delegation instead of goal delegation.
ESAW 2003 - London
10
Formalizing the Reusability of Software Agents
Semantic Composability (1/2)
• Starting from semantic interoperability, we can
abstract away the requirement of agents
knowing each other
– before the interaction,
– after the purpose of the interaction has been
achieved.
Definition of Semantic Composability
Given a set of n agents MAS={A1, A2, …, An}, they are said to be
semantically composable if and only if
CMAS, g : GCg, SMAS : solvesS(g)  KSGCdone(delegate(C, S, g))
where solvesA are the goals that A can solve.
ESAW 2003 - London
11
Formalizing the Reusability of Software Agents
Semantic Composability (2/2)
The definition states that the agents in a MAS are
semantically composable if (and only if)
CMAS
C lives in the MAS
g : GCg
and C has a goal
if there is an S in the MAS
SMAS : solvesS(g)
capable of solving it
then, C can delegate the
 KSGCdone(delegate(C, S, g))
goal to S
• This is compatible with the common approach of
explicitly choosing the agent to interact with
– if C wants S to achieve goal j for it, then the goal g of C would
be g=KSGCGSj.
ESAW 2003 - London
12
Formalizing the Reusability of Software Agents
Semantic Substituibility
• Framework reusability requires plugging new
agents to customize a complete systems to new
requirements.
• What we want to capture is that, from the point
of view of any possible agent interested in the
interaction, new and old agents provide the
same services.
Definition of Semantic Extensibility (Substituibility)
Given two agents B and D, we can say that D is a semantic extension
of B if and only if
g : solvesB(g)  solvesD(g)
ESAW 2003 - London
13
Formalizing the Reusability of Software Agents
Approximating the Ideal Model (1/4)
•
Everyday components rely on object-oriented
infrastructures to approximate ideal reusability
–
–
–
•
stateA  KA, the knowledge of the component is approximated
with the state of the component,
postcondition-of-next-callA  GA, the goals of a component are
approximated with a singleton set containing the postcondition
of the method that the component is about to invoke,
postconditionsA  solvesA, the goals a component can solve are
approximated with the set of postconditions of its methods.
Nothing is said about the state of the environment.
Poorer models of components (e.g., Javabeans)
support poorer approximations.
ESAW 2003 - London
14
Formalizing the Reusability of Software Agents
Approximating the Ideal Model (2/4)
• The infrastructure provides only a message delivery
service.
• Only tasks can be delegated
g=done(execute-the-body-of-a-method)
• Need for an explicit knowledge of components before
and after the interaction.
• Substituibility is implemented with inheritance
– static (design-time),
– semantics embedded in methods signatures.
ESAW 2003 - London
15
Formalizing the Reusability of Software Agents
Approximating the Ideal Model (3/4)
•
ParADE (BDI) agents
– BA  KA, we approximate the knowledge of the agent
with what the agent beliefs,
– IA  GA, we approximate the goals of an agent with
the intentions that it reasoned from its knowledge of
and from its internal rules,
– capableA  solvesA, we approximate the goals that
an agent can solve with the postconditions of its
feasible actions.
•
ParADE infrastructure provides a transparent
matchmaking service.
ESAW 2003 - London
16
Formalizing the Reusability of Software Agents
Approximating the Ideal Model (4/4)
• The matchmaking service guarantees that
– agents do not need to know each other nor before
nor after the interaction,
– interaction is mainly driven by goal delegation.
• Goal-driven, declarative behavior is embedded in
an imperative Java code.
• The matchmaker implements substituibility
because it reasons on published capabilities.
ESAW 2003 - London
17
Formalizing the Reusability of Software Agents
Discussion (1/2)
• The definitions that we provided put some constraints on
software infrastructures that wants to support better
approximations to (this sort of) ideal reusability.
• Infrastructures should
– be a means for transferring knowledge and goals (mainly goals),
and not only for moving data,
– support agents finding each other transparently, i.e., without an
explicit request (from the agent or from the programmer),
– allow agents finding problem solvers and not just task executors,
– enable choosing a problem solver on the basis of what it can do
and not on how it can describe its capabilities.
ESAW 2003 - London
18
Formalizing the Reusability of Software Agents
Discussion (2/2)
• Some “intelligence” is moved to the infrastructure
– still, we do not program the infrastructure.
• Better approximations to the ideal model are obtained
with better reasoning capabilities
– in the agents,
– in the infrastructure.
• Reasoning can be
– only in agents,
– domain-dependent part in agents together with domainindependent part in the infrastructure.
ESAW 2003 - London
19
Formalizing the Reusability of Software Agents
Thanks…
Questions?
AOT Lab
FRAMeTech S.R.L.
Parco Area delle Scienze, 181/A
Via San Leonardo, 1
43100 Parma, Italy
43100 Parma, Italy
[email protected]
[email protected]
http://aot.ce.unipr.it
http://www.frame-tech.it
ESAW 2003 - London
20