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 bergenti@ce.unipr.it bergenti@frame-tech.it http://aot.ce.unipr.it http://www.frame-tech.it

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Thanks… Questions? AOT Lab FRAMeTech S.R.L. Parco Area delle Scienze, 181/A Via San Leonardo, 1 43100 Parma, Italy bergenti@ce.unipr.it bergenti@frame-tech.it http://aot.ce.unipr.it http://www.frame-tech.it ESAW 2003 - London