A Requirement Specification Language for Configuration Dynamics of Multiagent Systems

Transcription

1 A Requirement Speciication Language or Coniguration Dynamics o Multiagent Systems Mehdi Dastani, Catholijn M. Jonker, Jan Treur* Vrije Universiteit Amsterdam, Department o Artiicial Intelligence, De Boelelaan 1081a, 1081 HV Amsterdam, The Netherlands In agent-mediated applications, the system coniguration can change because o the creation and the deletion o agents. The behavior o such systems on the one hand depends on the dynamics o the system coniguration; on the other hand, behavior o such a system consists o the inormation dynamics o the system. We discuss coniguration and inormation dynamics o agent-mediated systems and deine a requirement language to express properties o those dynamics. A prototypical scenario or an agent-mediated system is discussed and some important requirements or this system are speciied. It is shown how these properties can be veriied automatically to evaluate system behavior Wiley Periodicals, Inc. 1. INTRODUCTION Requirements Engineering is a well-studied ield o research within sotware engineering; e.g., see Res Requirements speciy the required properties o a system, which include the unctions o the system, structure o the system, and static and dynamic properties. Recently requirements engineering or distributed and agent systems has been studied in some depth, e.g., see Res. 4 and 5. For agent-based systems, the dynamics or behavior o the system plays an important role in description o the successul operation o the system. To be able to express requirements unambiguously and to support veriication by automated tools, ormal requirement speciication languages or dynamics are important. Dynamics o agent-based systems can take dierent orms. Depending on the type o dynamics, dierent demands are imposed on the expressivity o a requirement speciication language. A simple orm o requirements or dynamics *Author to whom all correspondence should be addressed: treur@cs.vu.nl. jonker@cs.vu.nl. Current address: Utrecht University, Institute o Inormation and Computing Sciences, Padualaan 14, 3584 CH Utrecht, The Netherlands. mehdi@cs.vu.nl. INTERNATIONAL JOURNAL OF INTELLIGENT SYSTEMS, VOL. 19, (2004) 2004 Wiley Periodicals, Inc. Published online in Wiley InterScience ( DOI /int.10171

2 278 DASTANI, JONKER, AND TREUR Figure 1. The generic architecture o the agent-mediating systems. (close to unctional requirements) expresses reactive types o behavior. However, combinations o proactive and reactive behavior can require more complicated requirement expressions. Most types o behavior can be expressed using rather standard orms o temporal logic. 6 8 Additional complications arise i the evolution o a system over time is taken into account; then, temporal logics o the more standard types do not suice. Examples o behavior o this type are relative adaptive behavior (e.g., exercise improves skill ), in which two dierent possible histories have to be compared, and sel-modiying behavior, e.g., the behavior o one o the agents (e.g., initiating a creation action o an additional agent), leads to a dierent system coniguration. This article addresses speciications o requirements or the sel-modiying type o dynamics. As illustrations o this type o dynamics, consider sel-modiying extensions o agent-mediating systems such as brokering systems, matchmaking systems, and search engines. In these applications, a user interacts with the system and receives its personal assistant (PA), which in turn interacts with available intermediate and task-speciic agents to perorm the user task. The sel-modiication o these systems lies in the idea that agents (PA and task-speciic agents) are created and removed rom the system according to circumstances. An abstract multiagent architecture or such sel-modiying mediating systems is illustrated schematically in Figure 1. According to this architecture, sel-modiying mediating systems consist o dierent types o components or agents, including a central maintenance agent (MA), an environment component, PA agents (P-agent), and intermediate task-speciic agents (I-agent). The MA is responsible or initial interactions with users and the overall coniguration o the system. For example, a user who wants to buy a car communicates with the MA and requires a car brokering system. With respect to the received request, the MA speciies a car brokering system consisting o a car broker agent (which may already exist) and a PA agent or the user (which may already exist) in such a way that the car broker agent and PA agent can interact to respond adequately to the request. The MA can conclude that the coniguration o the system needs to be modiied. I so, then a speciication o necessary changes to the system is communicated to the environment component to modiy the system coniguration. The environment component represents all ingredients o the system except itsel and is responsible or the realization o system modiications. The environment component is assumed to have a causal relation with the actual environment o the agent-mediating system in the sense that i it includes the representation o a component, then the component exists in the actual environment, and i there is a

3 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 279 component in the actual environment, then it is represented in the environment component. Moreover, the environment component is assumed to include a subcomponent, which translates modiication plans, which it receives rom the MA, to an appropriate representation o system coniguration. By the causal relation between the environment component and the actual environment, the system coniguration is guaranteed to be modiied appropriately. The user can now delegate its car-buying task to its PA agent, which in turn can interact with the car broker agent to achieve the delegated user task. The user can decide to log-o rom the broking system, in which case the PA agent and the car broker agent either can be deleted rom the system or set idle. The MA and the environment processes orm the basic components o the system. They will be created at startup o the system and remain until the system terminates. An essential property o such sel-modiying agent-mediating systems is the dynamic nature o their coniguration: new agents are created and removed rom the system. The correct behavior o the system depends on its coniguration during its execution. For this reason, it is important to speciy coniguration properties o such systems during their execution. The speciication and veriication o such coniguration properties is the ocus o this study. The article is organized as ollows. In Section 2 and 3 state and design languages are introduced. In Section 4 and 5 a requirement language is introduced that can express, besides unctional and inormational requirements, those requirements that are concerned with the system coniguration during its execution. In Section 6, this requirement language is used to identiy a number o requirement types concerning the coniguration o agent-mediated systems. A scenario or an agent-mediating system will motivate these requirements. Section 7 discusses possibilities or the veriication o the requirements proposed in Section 6, and Section 8 concludes the study. 2. SYSTEM SEMANTICS The aim o this study is to speciy and veriy coniguration properties o sel-modiying agent systems. This requires that the behavior o a system is ormally understood in general, beore specializing to sel-modiying systems. In this section, irst attention is given to state languages, i.e., languages with which dierent states o systems can be expressed. In the second part o this section, the semantics o systems are deined in terms o inormation states o the system State Languages In general, a state o a system can be considered as a valuation o the language elements (i.e., an assignment o truth values) that are used within or between components o the system. Within agent systems the interaction with the external world (EW) and other agents plays a central role. Agents reason what communications, actions, and observations should be perormed based on inormation obtained through observation and communication. Agents urther determine how to interpret observation results and inormation received through communication.

4 280 DASTANI, JONKER, AND TREUR In general, these aspects can be represented by statements expressed in an ordersorted predicate language. The sorts o this language relevant or the mentioned aspects are the ollowing: ACTION INFORMATION_ELEMENT SIGN AGENT The objects belonging to the dierent sorts change rom system to system. The relevant predicates belonging to the language are the ollowing: to_be_perormed: to_be_observed: observation_result: communication_rom_to: ACTION INFORMATION_ELEMENT INFORMATION_ELEMENT SIGN INFORMATION_ELEMENT AGENT AGENT Using this language, it is possible to represent statements like communicated_by(request(personal-assistant), pos, user( Johnson )). In this expression, the application-speciic parts are terms o sort INFORMATION_ELEMENT and AGENT. This expression can be generated in the mediating system example i the user identiied as user( Johnson ) initiates a request or a PA. Another example expression particular to the example system is the representation o the decision to add a PA component called pers_ass: to_be_perormed(add(exists_comp- (pers_ass))). O course, or other applications, the content o the actions, inormation elements, and agents are appropriate or those applications Inormation States An understanding o system behavior can be obtained by describing the semantics o the system; see, e.g., Re. 9. The semantics can be studied rom a static and a dynamic perspective. The static semantics o a system speciication can be described by the inormation states o the system. In principle, an inormation state I o a (part o a) system S (e.g., the overall system or an input or output interace o an agent) is an assignment o truth values {true, alse, unknown} to the set o ground atoms describing the inormation within S. The language elements used to orm the ground atoms can be based on the state language o the system as addressed in the previous section. Inormation states relect the structure o the system. Beore a ormal deinition can be given, irst, the structure o the system has to be understood. A compositional system, seen as a composed component, consists o a number o components. A primitive component is a component that is not composed o other components. The behavior o a compositional system is determined by the speciication o the composition relation and control speciied over the components. The composition relation reers to the possibilities o inormation transer between components. The control reers to activation sequences o component

5 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 281 activations and inormation transer occasions, and, thereore, to the run-time dynamics o the system. A component receives inormation as input and by its own processing generates inormation in its output interace. At each moment, the inormation state o a component is deined by the inormation it has explicitly available in its interaces (i.e., the input and output interaces) and the inormation it has explicitly available internally at that moment. An inormation state o a system is deined inductively as ollows. DEFINITION. Inormation State: For any component C, input(c) denotes the input interace o C, output(c) denotes the output interace o C, and sc(c) denotes the set o subcomponents o C. For any D that is either a component or an interace o a component, AT(D) denotes the set o ground atoms o the language used to describe the inormation in D. Let TV be the set o truth values {alse, unknown, true}. 1. An inormation state o an interace D is a mapping I: AT(D) 3 TV. IS(D) denotes the set o all inormation states o interace D. 2. An inormation state o a primitive component C is a tuple I_input, I_output, where I_input is an inormation state o input(c) and I_output is an inormation state o output(c); IS(C) denotes the set o all inormation states o C. 3. For component C, an interace inormation state is a pair I_input, I_output, where I_input is an inormation state o input(c), and I_output is an inormation state o output(c). IntIS(C) denotes the set o all interace inormation states o C. 4. The set o all inormation states o a composed component C, is the set IS(C) IntIS(C) D sc(c) IS(D). So that one inormation state o C is a tuple I_int, I, where I_int is an interace inormation state o C, and I D sc(c) IS(D) is a tuple consisting o inormation states o the dierent subcomponents o C. 5. The set o all possible inormation states o a system S is denoted by IS(S). For example, consider a system S consisting o two components C1 and C2. Assume that AT(Input(C1)) AT(output(C1)) { p1, p2}, AT(input(C2)) { p2}, and AT(output(C2)) { p3}. Consider the ollowing inormation states: 1. I1 IS(input(C1)) is the inormation state o the input o C1 that is deined by I1(p1) true, I1(P2) unknown. 2. I2 IS(output(C1)) is the inormation state o the output o C1 that is deined by I2(P1) true, I2(p2) alse. 3. I3 IS(input(C2)) is the inormation state o the input o C2 that is deined by I3(p2) alse. 4. I4 IS(output(C2)) is the inormation state o the output o C2 that is deined by I4(p3) true. Then A, A, I1, I2, I3, I4 is an inormation state o S. The oregoing deinitions orm a standard application o logic to represent ormally reality, in this case the state o a sotware system or component (Figure 2). Note that the languages needed to describe the inormation in two (interaces o) components can be dierent, but they may overlap. More details and a more extensive deinition o compositional inormation states can be ound in Re. 9.

6 282 DASTANI, JONKER, AND TREUR Figure 2. Inormation state. The dynamic aspects o the semantics are based on evolutions o compositional inormation states over time (Figure 3). A trace o S is a sequence o inormation states (I t ) t N in IS(S). Given a trace o S, the inormation state o the input interace o an agent A at time point t is denoted by state S (, t, input( A)). Analogously, state S (, t, output( A)), denotes the inormation state o the output interace o agent A at time point t within system S. More details on ormal semantics o system speciications can be ound in Res. 9 and DESCRIBING DESIGNS In the previous section, the static and dynamic semantics o systems in general has been discussed. A number o agent-speciic language elements have been Figure 3. Traces o inormation states.

7 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 283 Table I. Important sorts in DL. Sort SP SP comp SP prim SP interace SP input SP output SCON SSIG SKB Description Sort or system parts; part names identiy speciic system components in the hierarchical system structure, interaces o those components, and connections between components Sort or system components Sort or primitive system components Sort or component interaces (i.e., input or output) Sort or component input interaces Sort or component output interaces Sort or connections between system components Sort or signatures used by components Sort or knowledge bases o primitive system components deined, but otherwise no application-speciic language elements were presented. The systems central to this work are sel-modiying agent systems. Beore speciications can be given or such systems, an expressive and generic language needs to be introduced that allows the representation o system conigurations. The language introduced here or that purpose is called design language (DL). A characteristic o the systems studied in this article is that they have some orm o compositional architecture. The reader should note that the proposed object-level language could be reormulated easily or dierent types o systems. A method or the design o compositional multiagent systems is the design method DESIRE; c. Re. 11. The language DL introduced here has been developed or the representation o compositional system designs. These systems consist o a number o components that interact with each other through certain types o connections. Components may or may not be composed o other components. Components that are not composed are called primitive components. These components are deined in terms o ingredients such as input and output interaces, control loop, signatures, embedded components (or nonprimitive components), and knowledge bases (or primitive components). The coniguration properties that are to be ormalized concern these ingredients and their structural relations. Although an exhaustive list o all ingredients that may be used in these types o systems is beyond the scope o this study, the most important ingredients are introduced. The design language DL is an order-sorted language that expresses the coniguration o multiagent systems. The sorts in DL identiy the ingredients in such systems. Although an exhaustive enumeration o all sorts is out o the scope o this study, some important sorts are mentioned in Table I. These sorts are partially ordered: SP prim SP comp SP, SP input SP interace SP, SP output SP interace, SCON SP. For example, SP prim SP states that primitive components are system parts. For all sorts S a set o constants (i.e., {c c is a constant o sort S}) and a set o variables (i.e., {x: S x is a variable o sort S}) are assumed. Also, a set o n-ary unctions (i.e., { n n is an n-ary unction or any n}) is assumed. For example, input: SP 3 SP is a unction that maps components to their input parts. Given the oregoing ingredients, the terms o the DL can be deined as ollows: 1. I c is a constant o sort S, then c is a term o sort S.

8 284 DASTANI, JONKER, AND TREUR Table II. Examples o predicates in DL. Predicate exists_comp: SP sub: SP SP connected_to: SP SP SCON has_input_sign: SP SSIG has_private_sign: SP SSIG has_knowbase: SPprim SKB Description Component exists Subcomponent relation between system components Components connected by connection Component uses input signature Component uses private signature Primitive component has knowledge base 2. I x: S is a variable o sort S, then x: S is a term o sort S. 3. I : S 1... S n 3 S is a n-ary unction and t i is a term o sort S i (i 1,..., n), then (t 1,..., t n ) is a term o sort S. These terms reer to ingredients o the system, which can be related to each other according to certain relations. These relations are denoted by sorted predicate symbols. Some important predicates are mentioned in Table II. Based on these sorted predicates, the ormulas o the DL can be deined as ollows: 1. I p: S 1... S n is a n-ary predicate and t i (i 1,..., n) is a term o sort S i, then P(t 1,..., t n ) is a ormula o DL. 2. I E 1 and E 2 are ormulas o DL, then E 1 E 2 and E 1 are ormulas o DL. Let sig be a signature o language. The ormula connected_to(agent PA, agent IA, rom_to 3 ) has_input_signature(agent PA, sig ) is a design ormula expressing that the personal assistant agent PA is connected to the intermediate agent agent IA by connection rom_to 3 and the agent agent PA uses input signature sig. 4. REASONING ABOUT SYSTEM CONFIGURATIONS Within the scope o the example sel-modiying agent-mediating system, DL expressions are used by the MA and the environment component to represent system conigurations. The coniguration o the system can be modiied by execution o modiication actions or plans that add/remove some system ingredients to/rom the system. The MA and the environment component use these modiication plans to modiy the system coniguration. Thereore, the language DL is extended to allow agents to determine design modiication plans and their executions. In addition to the expressions o these coniguration languages, agents need to represent knowledge about the domain o mediation. Thereore, a language, called domain language ( ), is assumed to express the knowledge about the domain o mediation. Finally, the components in the agent-mediating system communicate expressions rom DL and to exchange data about the domain o

9 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 285 Table III. Sorts o CAL. Sort S DEAT DEFOR DEFOR FOR INFORMATION_ELEMENT ACTION SIGN AGENT Description S sort(dl) sort( ) Sort or atomic ormulas rom DL Sort or ormulas rom DL Sort or positive DL ormulas (atomic ormulas or conjunction o positive ormulas) Sort or ormulas rom Sort or ormulas rom or DL Sort or actions Sort or truth values Sort or agent names mediation, the system coniguration, and modiication plans. The language, called communication action language (CAL), is used to communicate these expressions. The language CAL has terms that denote the expressions o DL and and uses the same predicates or communication, observation, and action determination as those that were introduced in Section 2. The language CAL has been developed to enable the expression o plans to modiy system conigurations. These plans are addition or deletion commands that add/delete an ingredient to/rom a system. To express these plans, terms are needed that denote system ingredients. Thereore, CAL terms will be generated or all DL terms and ormulas. For this purpose, all DL sorts have been imported into CAL and the sort DEFOR has been introduced or terms that denote DL ormulas. Moreover, two new subsorts, DEAT and DEFOR, respectively, have been introduced or terms that denote DL atomic and positive ormulas. A DL-positive ormula is one in which the negation symbol does not occur. Furthermore, statements about the domain expressed in also need to be available as terms in CAL. Let sort(l), unc(l), and pred(l) be the sets o sorts, unctions, and predicates rom some language L, respectively. The sorts in CAL are presented in Table III. Note that the ollowing subsort relations hold: DEAT DEFOR DE- FOR INFORMATION_ELEMENT and FOR INFORMATION_ELE- MENT. For all sorts a set o constants and a set o variables are assumed. The inal step to generate CAL terms or all DL expressions (DL terms and ormulas) is to introduce or each DL unction and predicate a CAL unction. Thereore, the ollowing CAL unctions are introduced: 1. For L being either DL or and all n-ary unction unc(l) and all sorts S, S 1,..., S n sort(l), where : S 1... S n 3 S, the unction : S 1... S n 3 S is an imported unction in CAL (unction rom L corresponds with unction in CAL). 2. For L being either DL or and all n-ary predicates p pred(l) and all sorts S 1,..., S n sort(l) where p: S 1... S n, predicate p is reormulated as a unction p : S 1... S n 3 DEAT and imported in CAL (predicate name p rom L corresponds to unction name p in CAL).

10 286 DASTANI, JONKER, AND TREUR Also, or each logical connective that connects DL ormulas, a CAL unction has been introduced as ollows: : DEFOR DEFOR 3 DEFOR : DEFOR DEFOR 3 DEFOR : DEFOR 3 DEFOR Similarly, the logical connectives that operate on ormulas are imported as CAL unctions. The unctions in CAL, which correspond with DL or unctions or predicates, are marked (by being underlined) in order to distinguish them rom their corresponding unctions or predicates rom DL and. Whenever there is no conusion, these underlying marks are let out. With the oregoing introductions, all terms o DL and are available in CAL, and all ormulas o DL and are available as terms in CAL. In addition to these unctions, two speciic plan-related unctions have been introduced in CAL that are used in to express plans or modiication o system coniguration. These two plan-related unctions are deined as ollows: add: DEFOR 3 ACTION delete: DEAT 3 ACTION Note that the add unction is not deined on negative DL ormulas because they do not speciy a unique system coniguration. Similarly, the delete unction has been deined only or atomic design expressions to avoid conusion in the semantics o the action. I the delete action would have been deined or nonatomic expressions, then what would, e.g., delete(a b) mean? Would the deletion o a be enough, or that o b? For all sorts a set o constants and a set o variables are assumed. Given these constants, variables, and unctions, CAL terms are deined in the usual way. The plans (CAL terms o sort ACTION) are limited to adding and deleting a positively (resp. atomically) stated system coniguration. The add unction maps a positive DL ormula to a plan, which when executed will result in a larger system coniguration. The positive DL ormula, which is the argument o the add unction, speciies the system ingredients that should be added to the system. As an example o CAL terms, consider the ollowing expression: add connected_to agent PA, agent IA, rom_to 3 has_input_signature agent PA, sig This expression denotes a plan to create a system consisting o agent PA and agent IA that are connected by connection rom_to 3 and, moreover, agent PA uses the input signature sig. The unction add should be interpreted as adding all system elements that occur in the design ormula but not yet included in the system in the given relation. The language CAL has the ollowing predicates:

11 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 287 to_be_perormed: to_be_observed: observation_result: communication_rom_to: ACTION INFORMATION_ELEMENT INFORMATION_ELEMENT SIGN INFORMATION_ELEMENT AGENT AGENT Based on the deined terms o the predicates, the ormulas o CAL can be deined as ollows: 1. I p: S 1... S n is a n-ary predicate and t i is a term o sort S i (i 1,..., n), then p(t 1,...,t n ) is an atomic ormula o the communication action language CAL. 2. All atomic CAL ormulas are CAL ormulas. 3. I E, E 1 and E 2 are CAL ormulas, then E and E 1 E 2 are CAL ormulas. As an example o a CAL ormula, consider the ollowing expression: to_be_perormed add connected_to agent PA, agent IA, rom_to 3 has_input_signature agent PA, sig )) is a design communication ormula, which states that the add-action should be perormed. 5. REQUIREMENT LANGUAGE In this section, a requirement language is introduced to speciy and veriy requirements or sel-modiying agent systems. Some examples are presented that are based on the example mediating system. This requirement language depends and builds on the language CAL used by the agents to represent and communicate inormation about either the domain o mediation or the system coniguration. Based on the language CAL, we deine the temporal coniguration requirements language (TCRL) to speciy and veriy the dynamic (inormation and coniguration) behavior o agent-mediating systems. In general, requirements can be distinguished into two types: inormation requirements and coniguration requirements. Inormation requirements ormulate properties related to the domain knowledge and coniguration properties ormulate properties related to the system coniguration. It is important to note that the introduction o the environment component in the example agent-mediating system and its causal relation with the actual environment make it possible to consider coniguration properties as a speciic type o inormation properties. In act, the causal relation makes it possible to derive coniguration properties o the system rom its representation in the environment component. Expressions o the languages DL and CAL are used by the components in the agent-mediating systems, while the expressions o the requirement language are used by an external observer to speciy the (inormation and coniguration) properties o the system behavior. In that sense, TCRL is a metalanguage with respect to DL and CAL.

12 288 DASTANI, JONKER, AND TREUR Sort Table IV. Sorts o TCRL. Description S FOR M R M C T S sort(cal) Sort or ormulas rom CAL Sort or restricted states Sort or complete states Sort or time Sort or trace The requirement language TCRL is deined to express properties or requirements o agent-mediated systems concerning either their coniguration behavior or their inormation behavior. Coniguration behavior addresses questions such as what will be the system coniguration i the MA communicates a CAL expression to the environment component? Inormation behavior addresses questions such as what will be the system inormation state i a component sends an expression to another component? Thus, TCRL has been designed to allow the ormulation o expressions concerning the coniguration and inormation behavior o a system through time. For this reason, TCRL contains terms that denote system states, system traces, and time. System states and traces are introduced in Section 2. In light o the requirements that need to be ormulated, a system state addresses both the inormation content o the system and the structural coniguration state o the system. Moreover, TCRL contains predicates to represent relations between those terms. Thus, TCRL expressions can be used to speciy properties o the coniguration and inormation behavior o a system through time. For any order-sorted predicate language L, sorts, unctions, and predicates rom L are denoted by sort(l), unc(l), and pred(l), respectively. The sorts in TCRL are mentioned in Table IV. The sort FOR is or TCRL terms that denote CAL ormulas; M R and M C are sorts or terms that denote, respectively, a part o the system state and a complete system state; T is the sort or terms that denote time points; and, inally, is the sort or terms that denote system traces. Note that the order o sorts preserves under the import relation between languages. For example, the ollowing orders exist among the imported sorts in TCRL: SP comp SP, SP interace SP comp,sp input SP interace,sp output SP interace. Furthermore, DEFOR FOR and FOR FOR. For all sorts, a set o constants and a set o variables are assumed. For all n-ary unctions unc(cal) and all sorts S, S 1,..., S n sort(cal), where : S 1... S n 3 S, the unction : S 1... S n 3 S is an imported unction in TCRL. Also, or all n-ary predicate p pred(cal) and all sorts S 1,...,S n sort(cal), where p: S 1... S n, predicate p is reormulated as a unction p: S 1... S n 3 FOR and imported in TCRL. Finally, logical connectives that operate on CAL ormulas are imported as unctions, e.g., : FOR FOR 3 FOR : FOR3 FOR

13 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 289 Table V. Predicates o TCRL. Predicate : T T holds_ino_r: M R FOR SIGN holds_ino_c: M C FOR SP interace SIGN holds_struct_r: M R DEFOR SIGN holds_struct_c: M C DEFOR SP SIGN Description Time-ordering relation Formula holds a truth value indicated by sign in a state Formula holds a truth value indicated by sign in an interace state o a component Design ormula holds a truth value indicated by sign in a state Design ormula holds a truth value indicated by sign in a state o a component Some speciic unctions or the trace requirement language TCRL are as ollows: input: output: state_r: state_c: SP comp 3 SP input SP comp 3 SP output T SP interace 3 M R T 3 M C Given the unctions as deined here, the terms o TCRL are deined in the usual way. To speciy the behavior o the system through time, predicates are introduced that express the validity o ormulas regarding either the inormation state o the system (FOR) or the state o coniguration o the system (DEFOR) at particular time points. These predicates are hold_ino_r, hold_struct_r, hold_ino-c, and hold_struct_c. The dierence between these predicates is that the _c predicates express the validity o a ormula with respect to a complete state whereas the _r predicates express the validity o a ormula with respect to a partial state. This distinction is useul because one and the same ormula rom FOR can be used by dierent components and thus have dierent truth values in those dierent components. The _ino_ predicates reer to the validity o a ormula with respect to inormation states; _struct_ predicates reer to structural states o the system (system coniguration). These predicates are mentioned in Table V. Formulas o TCRL are deined in the usual way: 1. I p: S 1... S n is a n-ary predicate and t i is a term o sort S i (i 1,..., n), then p(t 1,..., t n ) is an expression o the requirement language TCRL. 2. I E 1 and E 2 are TCRL expressions and x: S is a variable o sort S, then E 1 E 2, E 1 E 2, E SE 1,?x: SE 1 are ormulas o TCRL. Let be a design ormula o sort DEFOR, agent MA is the MA, let SYS denote the whole multiagent system, and then the ollowing TCRL ormula states that in all system traces and at any time point i the output o the MA is a communication ormula expressing a creation action (i.e., to_be_perormed(add( ))); then, some time later the system is modiied according to the creation action:

14 290 DASTANI, JONKER, AND TREUR Figure 4. Import relation between :,? t: T holds_ino_c state_c :, t: T, to_be_perormed add, output agent MA, true? t : T t : T t: T holds_struct_c state_c :, t : T,, SYS, true In the ollowing, quantiied expressions such as? t : T, t : T t: T... are abbreviated to? t : T t: T.... Note that there is an ordering relation between deined languages (DL, CAL,, and TCRL) according to which one language imports terms and ormulas rom another language. This import ordering relation is illustrated in Figure REQUIREMENTS FOR AN EXAMPLE SCENARIO In this section, we use the requirement language TCRL to express a number o requirements that speciy relevant properties concerning both coniguration as well as inormation behavior o agent-mediated systems. To motivate these requirements, we introduce a scenario where the system coniguration is modiied Example Scenario Consider a scenario or a system consisting o three components called User Agent (UA), MA, and EW. At a certain time point, the UA may need a PA agent and communicates an appropriate request to the MA. The MA generates an action (to be executed in the environment) to create a PA agent or the UA. Ater the PA agent is created (now the system consists o our components), the UA can communicate with its PA agent and require certain inormation to be provided by the PA agent. This scenario can be described as the ollowing sequence o pairs indicating the system coniguration and the system inormation states, respectively: 1. System structure consists o UA, MA, and EW; UA (internally) identiies the need or a PA. 2. System structure consists o UA, MA, and EW; UA generates a service request on its output or PA.

15 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 291 Table VI. State transition operations. Operation In scenario Explication Communication initiation UA: need or PA UA: speciic ino need PA: itting answer Communication event UA to MA: requests a PA UA to PA: speciic ino request PA to UA: itting answer Action initiation MA decides to create PA (World) interaction event MA to EW: add(pa) Action execution EW executes add(pa) 3. System structure consists o UA, MA, and EW; MA has the user service request or PA on its input. 4. System structure consists o UA, MA, and EW; MA generates to_be_perormed (add(pa)) on its output. 5. System structure consists o UA, MA, and EW; EW has to_be_perormed(add(pa)) on its input. 6. System structure consists o UA, MA, EW, and PA; EW has E (the eect o add(pa)) on its output; UA (internally) identiies which speciic inormation is needed. 7. System structure consists o UA, MA, EW, and PA; UA generates inormation request on its output. 8. System structure consists o UA, MA, EW, and PA; PA has the inormation request on its input; PA (internally) identiies a itting answer. 9. System structure consists o UA, MA, EW, and PA; PA has an answer to the inormation request on its output. 10. System structure consists o UA, MA, EW, and PA; UA has the answer on its input. Given the oregoing sequence o system states, the ollowing types o state transition operations can be distinguished: communication initiation, communication event, action initiation, (world) interaction event, and action execution. In Table VI the state transition operations within the example scenario are explicated Relevant Properties In this section, the requirement language TCRL is used to speciy some important properties o the system in the scenario mentioned previously. These properties are distinguished into three classes called global, basic, and semantic properties. The global properties concern the behavior o the system as a whole; the basic properties concern the behavior o the system parts; and the semantic properties are the assumed generic properties or the type o system Global Properties Two important global properties or the example mentioned previously are speciied by the ollowing requirements.

16 292 DASTANI, JONKER, AND TREUR GR1 (UA-EW Impact). I at time point t the agent UA generates a service request Q to MA on its output, and there exists a design description E such that E would realize Q, then a time point t t exists such that EW has such an E on its :, t: T, Q: SLTERM [ holds_ino_r(state_r( :, t: T, output(ua)), communication_rom_to(q: SLTERM, UA, MA), true)? E: DEFOR structure_realizes_service(e: DEFOR, Q: SLTERM)? t : T t: T? E: DEFOR structure_realizes_service(e: DEFOR, Q: SLTERM) holds_ino_r(state_r( :, t : T, output(ew)), E: DEFOR, true) Note that SLTERM is an assumed sort that reers to the service language terms by which the user denotes the kind o service (s)he is interested in. Examples that illustrate SLTERM expressions are request(personal-assistant) and request (car-brokering-system). GR2 (Creation Successulness). I at time point t the agent UA generates a service request Q (e.g., or having a PA) to MA on its output, and R is the behavior required or service request Q, then a time point t t exists such that the system coniguration contains the necessary structure (e.g., pers_ass) and the system shows behavior :, t: T, Q: SLTERM [ holds_ino_r(state_r( :, t: T, output(ua) ), communication_rom_to(q: SLTERM, UA, MA), true)? E: DEFOR, d1: T, d2: T [ structure_realizes_service(e: DEFOR, Q: SLTERM) SB1 R (E: DEFOR, d1: T, d2: T)? t : T t: T, E : DEFOR, d1: T, d2: T [ structure_realizes_service(e : DEFOR, Q: SLTERM) holds_ino_r(state_r( :, t : T, output(ew)), E : DEFOR, true) SB1 R (E : DEFOR, d1: T, d2: t1: T, t2: T, t3: T, t4: T [ t2: T t1: T d1: T t1: T t3: T t2: T d2: T t4: T t3: T d2: T R( :, t3: T, t4: T, pers_ass) The term SB1 R is a scheme o properties that relate a structure E: DEFOR to behavior R. The occurrence o R makes it a scheme. The terms SB1 R and R occurring in this property are deined and explained in Section

17 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS Basic Properties The basic properties are divided in three subclasses called agent properties, world properties, and transer properties. These properties are deined as ollows Agent Properties An agent property reers to the behavior o a speciic agent. An important agent property or the example mentioned previously is speciied by the ollowing requirement. AR1 (MA Action Initiation Successulness). I at time point t the agent MA has a service request Q (e.g., a request or a PA) on its input, and there exists an E which is a system coniguration that can satisy the service request Q, then a time point t t exists such that MA or such an E has to_be_perormed(add(e)) on its :, t: T, Q: SLTERM, [ holds_ino_r(state_r( :, t: T, input(ma)), communication_rom_to(q: SLTERM, UA, MA), true)? E: DEFOR structure_realizes_service(e: DEFOR, Q: SLTERM)? E : DEFOR [ holds_ino_r(state_r( :, t: T, input(ma)), observation_result(e : DEFOR, pos), true) structure_realizes_service(e : DEFOR, Q: SLTERM)? t : T t: T? E: DEFOR [structure_realizes_service (E: DEFOR, Q: SLTERM) holds_ino_r(state_r( :, t : T, output(ma)), to_be_perormed(add(e: DEFOR)), E : DEFOR [ structure_realizes_service(e : DEFOR, Q: SLTERM) holds_ino_r(state_r( :, t : T, output(ma)), to_be_perormed(add(e : DEFOR)), true) equal(e: DEFOR, E : DEFOR) World Properties The required properties o the behavior o the environment component are speciied as ollows. ER1 (EW Action Execution Successulness). I at time point t the world component EW has to_be_perormed( ) on its input, and is the eect o perorming, then a time point t t exists such that EW has on its output.

18 294 DASTANI, JONKER, AND :, t: T, : ACTION, : DEFOR, [ holds_ino_r(state_r( :, t: T, input(ew) ), to_be_perormed( : ACTION), true)? t : T t: T [ holds_ino_r(state_r( :, t : T, output(ew) ), : DEFOR, true) is_eect_o( : DEFOR, : ACTION) where the predicate is_eect_o(, ) is deined as x: x: DEAT is_eect_o( x, add( x)) is_eect_o( x, delete( x)) Transer Properties The transer properties speciy that inormation transer between agents takes place in a proper manner. Two important transer properties are speciied by the ollowing requirements. TR1 (Transer UA-MA). I at time point t the agent UA generates a request or MA on its output, then a time point t t exists such that MA has this request on its :, t: T, : FOR [ holds_ino_r(state_r( :, t: T, output(ua)), communication_rom_to( : FOR, UA, MA), true)? t : T t: T holds_ino_r(state_r( :, t : T, input(ma)), communication_rom_to( : FOR, UA, MA), true) Note that the property TR1 also could be speciied using a variables over SP instead o the speciic reerences to output(ua) and input(ma). The TR1 property then can be instantiated or every inormation transer between components by instantiating the proper interaces o those components or the variables over SP. TR2 (Transer MA-EW). I at time point t the agent MA generates to_be_perormed( ) or EW on its output (Note that is o type ACTION such that it is either add(e) or delete(e)), then a time point t t exists such that EW has to_be_perormed( ) on its :, t: T, : ACTION [ holds_ino_r(state_r( :, t: T, output(ma)), to_be_perormed( : ACTION), true)? t : T t: T

19 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 295 holds_ino_r(state_r( :, t : T, input(ew)), to_be_perormed( : ACTION), true) Semantic and Coherence Properties The semantic properties speciy the assumed generic properties o the system. The ollowing semantic properties are distinguished Semantic Properties This property guarantees that i a system description holds in (the inormational state o) the environment, then the actual system coniguration (its structural state) is indeed described by that description. RA1. I at time point t in trace the world component EW has description E on its output, then at time point t in trace the system has structure E (i.e., the system description E is :, t: T, E: DEFOR [ holds_ino_r(state_r( :, t: T, output(ew)), E: DEFOR, true) holds_struct_c(state_c( :, t: T), E: DEFOR, true) Coherence Property The coherence properties speciy a relation between the inormational and structural states o the actual system at any point in time. Two important properties that guarantee the coherency o the system are as ollows: CA1. At any time t in any trace i a ormula has a truth value in the inormational state or a speciic system part, then this system part actually is part o the system structure (in the structural :, t: T, C: SP, : FOR,E: DEFOR, tv: TV [ holds_ino_r(state_r( :, t: T, interace(c: SP) ), : FOR,tv: TV)? : SSIG [ holds_struct_r(state_r( :, t: T, SYS), exists_comp(c: SP), true) holds_struct_r(state_r( :, t: T, SYS), has_interace_signature( : SSIG, C: SP), true) holds_struct_r(state_r( :, t: T, SYS), is_ormula_o( : FOR, : SSIG), true)

20 296 DASTANI, JONKER, AND TREUR CA2. At any time t in any trace i the system has a certain structure (in its structural state), then the ormulas that can be evaluated in this system structure have truth values (in the system s inormational :, t: T, C: SP, : FOR, E: DEFOR, : SSIG [ [ holds_struct_r(state_r( :, t: T, SYS), exists_comp(c: SP), true) holds_struct_r(state_r( :, t: T, SYS), has_interace_signature( : SSIG, C: SP), true) holds_struct_r(state_r( :, t: T, SYS), is_ormula_o( : FOR, : SSIG), true)? tv: TV holds_ino_r(state_r( :, t: T, interace(c: SP) ), : FOR, tv: TV) Structure-Behavior Properties In this section (required), behavior is related to structure properties and service requests. In this section R( :, t1: T, t2: T, C: SP) stands or a scheme o behavioral requirements that can be instantiated by a speciic requirement. As an example, pers_ass_req( :, t1: T, t2: T, C: SP) denotes the requirement that i a component C receives a request on its input, then the component C produces an answer within a reasonable time or that request on its output. In the ormalization o this requirement INFO is a sort or the content o requests and A: INFO [ holds_ino_r(state_r( :, t1: T, input(c: SP) ), request( A: INFO), true)? t: T,? B: INFO [ t1: T t: T t1: T t2: T holds_ino_r(state_r( :, t: T, output(c: SP) ), answer_or(b: INFO), true) By deining such abbreviations or the requirements o interest or the system in question, a powerul scheme o structure-behavior properties can be ormulated: SB1 R and SB2 R. Let SB1 R (E: DEFOR, d1: T, d2: T) denote the ollowing scheme o structure-behavior properties: I between time points t1 and t2 the system has structure E: DEFOR, then R is true between t1 and t2 d2 or all periods o suicient length (d1 t1: T, t2: T, t3: T, t4: T [ t2: T t1: T d1: t [t1: T, t2: T holds_struct_c(state_c( :, t: T), E: DEFOR, true) t1: T t3: T t2: T d2: T t4: T t3: T d2: T

21 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS 297 R( :, t3: T, t4: T, pers_ass) In the next structure-behavior scheme o properties SB2 R, the link is made between a service request Q, the behavior R that satisies Q, and the possible structures E: DEFOR that can realize R. Scheme SB2 R denotes the ollowing scheme o structure-behavior Q: SLTERM [ intended_service R (Q: SLTERM)? E: DEFOR, d1: T, d2: T [ SB1 R (E: DEFOR, d1: T, d2: T) structure_realizes_service(e: DEFOR, Q: SLTERM) This scheme expresses that or all service requests Q, i by expressing Q the user intends to obtain the service speciied by R, then a system coniguration E exists such that the structure E can be used to realize the requested service Q, and that (SB1 R ) the intended service R will indeed be delivered under the condition that the system satisies coniguration E during an appripriate time. 7. SYSTEM EVALUATION Development o a system is only then complete when the system behavior is veriied against the required properties. In Section 3, certain properties or the proposed scenario system have been introduced. Veriying such properties may be quite complex. This section shows that such complexity can be reduced by introducing appropriate intermediate properties. By means o the intermediate properties the global properties can be proved more easily and more eiciently by using proo patterns. The intermediate properties can be derived rom basic properties Intermediate Properties In this article, intermediate properties are chosen so that they speciy the output/output relations between dierent system components. The reason or ormulating them in that ormat is the ease with which they can be used in proo patterns. Two important intermediate properties are as ollows. IR1 (UA-MA Interaction). I at time point t the agent UA generates a service request Q or MA on its output, and there exists an E which is a structure with which Q can be realized, then, i necessary to service the request, a time point t t exists such that MA or such an E has to_be_perormed(add(e)) on its :, t: T, Q: SLTERM

22 298 DASTANI, JONKER, AND TREUR [ holds_ino_r(state_r( :, t: T, output(ua) ), communication_rom_to(q: SLTERM, UA, MA), true)? E: DEFOR structure_realizes_service(e: DEFOR, Q: SLTERM)? E : DEFOR [ holds_ino_r(state_r( :, t: T, output(ew)), observation_result(e : DEFOR, pos), true) structure_realizes_service(e : DEFOR, Q: SLTERM)? t : T t: T, E: DEFOR structure_realizes_service (E: DEFOR, Q: SLTERM) [ holds_ino_r(state_r( :, t : T, output(ma)), to_be_perormed(add(e: DEFOR)), E : DEFOR [ structure_realizes_service(e : DEFOR, Q: SLTERM) holds_ino_r(state_r( :, t : T, output(ma) ), to_be_perormed(add(e : DEFOR) ), true) equal(e: DEFOR, E : DEFOR) IR2 (MA-EW Interaction). I at time point t MA has an action (e.g., to_be_perormed(add(e)) or to_be_perormed(delete(e))) on its output, then a time point t t exists such that the output o EW relects the eect o the action (e.g., E is, respectively, is not on its :, t: T, : ACTION, : DEFOR [ holds_ino_r(state_r( :, t: T, output(ma) ), to_be_perormed( : ACTION), true) is_eect_o( : DEFOR, : ACTION)? t : T t: T holds_ino_r(state_r( :, t : T, output(ew) ), : DEFOR, true) 7.2. The Use o Proo Patterns The ollowing logical relationships hold between the dierent properties. 1. Intermediate properties are implied by transer properties and agent or world properties: TR1 & AR1 IR1 TR2 & ER1 IR2 2. Intermediate properties can be chained to indirect interaction properties expressing indirect impact o one component on another one: IR1 & IR2 GR1

23 CONFIGURATION DYNAMICS OF MULTIAGENT SYSTEMS Indirect intermediate properties imply the global properties, assuming representation and coherence properties and structure-behavior relationships: GR1 & RA1 & CA1 & SB2 GR Checking Properties Given a trace or set o traces, all o the aorementioned properties can be checked automatically. To this end, a sotware environment has been developed in Prolog. I, e.g., the property GR2 is checked, the outcome can be one o the ollowing: 1. Indeed GR2 satisied 2. GR2 is dissatisied; in this case, given the logical relationships deined by the proo patterns, at least some o the basic properties also are dissatisied; which one(s) also can be ound by running the checking sotware or all o the basic properties; the outcome o this check points to where the problem originates. For more details o this model-checking environment and its use in diagnosis, see Re DISCUSSION The requirements speciication language introduced in this study can be used in a number o ways. First, it allows or speciication o requirements on the system structure over time. Most other requirement languages (e.g., Res. 7, 13 and 14) only allow or speciication o inormational system states, or a given, ixed system structure. In our language it is possible to reer to both the structural state o the system and the inormational state o it. A second use is that a broad class o behavioral properties can be speciied o the system or o speciic parts o the system, e.g., agents. Not only can, e.g., reactiveness and proactiveness properties be speciied, but also properties expressing adaptive behavior, such as exercise improves skill, which are relative to (comparing two alternatives or) the history can be expressed in this language (in standard orms o temporal logic dierent alternative histories can not be compared). A third and more sophisticated use is to speciy requirements on the dynamics o the process o modiication o the system structure over time, e.g., as initiated and perormed by the system (e.g., one o its agents) itsel. Here, requirements on, e.g., agent behavior and the dynamics o the system structure and their relationships can be speciied. For example, it can be expressed whether a system modiication initiation by one o the agents occurs and whether it is successul. Requirements can be speciied at dierent levels o aggregation. For example, a requirement or the overall system can be reined into requirements o dierent parts o the system, i.e., requirements on speciic agents and on speciic interactions between agents, which, together, logically imply the global requirement. For more details o reinement in the context o compositional veriication o multiagent systems, see Re. 10.