Software Agents are Software Components

1. Software Agentsare Software Components Federico Bergenti bergenti@ce.unipr.it

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? • Reusability is a feature of the technology we use to build and assembly components.

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

4. Reusing Software Components • The infrastructure plays a central role in (this sort) of reusability • it enables interactions, • it supports substituibility. • 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).

5. Agents and Components • We ask for 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. Ascription Hypotesis Given a component, we can ascribe mental qualities, i.e., knowledge and goals, to it.

6. An Ideal Model of Reusability • Need to define what a “perfect” interaction is • we concentrate only on problem-independent issues, • we move all issues to the infrastructure because agents should take 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, • …

7. Semantic Interoperability • 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_to(C, S, g)) KSGCdone(delegate_to(C, S, g)) where delegate_to(C, S, g) is a sort of abstract action of C whose outcome is KCGSg.

8. Semantic Composability • 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,AMAS : solvesA(g), GCdone(delegate(C, g))!SMAS: solvesS(g),KSGCdone(delegate_to(C, S, g)) where delegate(C, g) is a sort of abstract action of C whose outcome is KC(XMAS : GXg).

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

10. Approximating the Ideal Model (1/2) • 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.

11. Approximating the Ideal Model (1/2) • Everyday components rely on object-oriented • 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.

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

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

14. Thanks… Questions?Comments?