1. Formalizing the Reusability of Software Agents
Federico Bergenti
AOT Lab
FRAMeTech S.R.L.
Parco Area delle Scienze, 181/A
Via San Leonardo, 1
43100 Parma, Italy

2. Software Reuse
In principle, any artifact of the software lifecycle can be reused
a piece of specification (e.g., a use case),
a piece of design (e.g., design pattern, architecture),
a linkable module (e.g., DLL, .NET module),
a 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 London

3. 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
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.
Infrastructure
ESAW London

4. 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 London

5. 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 London

6. 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 London

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

8. 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 London

9. 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 London

10. Semantic Interoperability (2/2)
The definition states that if (and only if)
C has a goal and
GCg
C wants some S to bring about this goal
GCdone(delegate(C, S, g))
then, S knows of this wish
 KSGCdone(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 London

11. 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 London

12. Semantic Composability (2/2)
The definition states that the agents in a MAS are semantically composable if (and only if)
C lives in the MAS
CMAS
and C has a goal
g : GCg
if there is an S in the MAS capable of solving it
SMAS : solvesS(g)
then, C can delegate the goal to S
 KSGCdone(delegate(C, S, g))
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 London

13. 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 London

14. 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 London

15. 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 London

16. 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 London

17. 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 London

18. 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 London

19. 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 domain-independent part in the infrastructure.
ESAW London

20. Thanks… Questions? AOT Lab FRAMeTech S.R.L.
Parco Area delle Scienze, 181/A
Via San Leonardo, 1
43100 Parma, Italy
ESAW London