0 valutazioniIl 0% ha trovato utile questo documento (0 voti)
29 visualizzazioni17 pagine
This document proposes an approach for modeling, designing, and implementing agent-oriented information systems based on business rules. It describes how business rules can be expressed as the beliefs and goals of software agents. The agents' beliefs and goals can then be implemented through a combination of knowledge and procedural reasoning. The approach aims to address limitations of object-oriented modeling for capturing global business rules and supporting a declarative style of requirements specification.
This document proposes an approach for modeling, designing, and implementing agent-oriented information systems based on business rules. It describes how business rules can be expressed as the beliefs and goals of software agents. The agents' beliefs and goals can then be implemented through a combination of knowledge and procedural reasoning. The approach aims to address limitations of object-oriented modeling for capturing global business rules and supporting a declarative style of requirements specification.
This document proposes an approach for modeling, designing, and implementing agent-oriented information systems based on business rules. It describes how business rules can be expressed as the beliefs and goals of software agents. The agents' beliefs and goals can then be implemented through a combination of knowledge and procedural reasoning. The approach aims to address limitations of object-oriented modeling for capturing global business rules and supporting a declarative style of requirements specification.
Business Rules' Approach to the Modelling, Design, and
Implementation of Agent-Oriented Information Systems
Kuldar Taveter VTT Information Technology (Technical Research Centre of Finland) P.O.Box 1201, FIN-02044 VTT, Finland Tel. +358 9 456 6044, fax +358 9 456 6027 kuldar.taveter@vtt.fi Abstract We propose an approach where the modelling, design, and implementation of agent-oriented information systems is based on business rules. By using an example of car rental, we show how the process of agent-oriented modelling and design could look like. It starts from the modelling of autonomous functional units of an organization by agents, and continues by modelling a common understanding of the problem domain and its business rules for the agents by creating an ontology. We show how business rules can be further expressed through beliefs and goals of the agents, and how business processes can be described through repetitive setting and realization of the agents goals, and through high-level communication between the agents. We also show how beliefs and goals of such agents can be implemented as a combination of hybrid knowledge and procedural reasoning. 1. INTRODUCTION Agent is an emerging abstraction that the field of (business) information systems may also benefit from. Intelligent software agent can be defined as a piece of software that acts on behalf of a human user and exhibits some aspects of intelligent behaviour. Within the framework of this paper, we are interested in agents that follow the so-called belief- aesire-intention (BDI) model [25]. Main components of such an agent are information store that consists of the agents beliefs and goal store that consists of the agents goals. These two stores form an agents virtual knowledge base which is called virtual because it is necessarily not implemented as a classical knowledge base. For example, the beliefs' part of an agent's virtual knowledge base may consist of some existing database that the agent wraps. A software agent is capable of performing actions that arise from his beliefs and goals. Agents communicate with each other and humans in some high- level agent communication language. Messages in such a language can, for example, be query, inform, request, and agree. An agent can also be defined as a unit that can be programmed in terms of beliefs and goals [1]. According to the emerging paradigm of cooperative information systems [2], information systems are viewed as consisting of agents who relate to each other as a social organization. Agents cooperate when they share goals and work together to fulfill those goals. The process of requirements capture for cooperative information systems includes the steps of iaentifying the agents in the environment, mapping business goals to system goals, and operationali:ing these system goals by reaucing them into constraints that agents can be responsible for through their actions [2]. We have followed these steps in our work. Under the paradigm of cooperative information systems, once captured organizational objectives and systems requirements must also be kept alive and remain a part of the running system, due to ongoing evolution of the system. An adequate objectives and requirements representation language should support a aeclarative style of specification which offers the possibility to model requirements adopting an aerial view perspective. For example: the borrowing of a book should be followed by its return within the next three weeks [2]. In our opinion representing organizational objectives and systems requirements as business rules is a step towards this kind of language. 2. PROBLEM STATEMENT Unfortunately, the existing methods of modelling and designing object-oriented systems like e. g. UML [3], and the corresponding CASE-tools like e. g. Rational Rose [4] and programming languages only partially fit the needs of agent-oriented cooperative information systems. The reasons lie in the differences between the notions of object and agent. In particular, while an object's state is determined by the values of its attributes, the state of an agent is determined by the information in its virtual knowledge base. Another important difference is that in the object-oriented case, the decision whether to perform a certain action or not, lies with the object that invokes the corresponding operation (method), but in the agent case, the decision lies with the agent that received the request [5]. Agents thus promote autonomous action and decision-making which enables peer-to- peer interaction, while objects are better suited to the more rigid client-server model [26]. Moreover, agent communication languages are based on well-defined, small sets of general communicative actions, whereas objects communicate through unrestricted and idiosyncratic messages with ad hoc semantics [26]. As a result of all this, UML diagrams can only limitedly be used for modelling agent-oriented systems as it is done in section 3.4 of this paper. On the other hand, object-oriented representations and the corresponding CASE-tools do not support the declarative style of requirements specification which according to [2] should support a natural mapping of stakeholders informal statements in terms of their formal counterparts. Such statements are often represented in the form of rules that are generally hard to capture in a nice object-oriented structure. Although this is true for rules of any problem domain (see e. g. the paper [7]), we will be using the examples from the rather well-studied area of business rules (see e. g. [10, 11, 27]) throughout this paper. The reason is that rules have a global nature, i. e. posssibly involve objects of several object types. This doesn't fit with the principle of encapsulation that we have in object- oriented systems. For example, the rule "product of the type A should never be cheaper than product of the type B" involves two different object classes: it cannot be expressed within just one class. The rule "when the payment of a bill is two weeks overdue, it is required to send a reminder to the customer" involves several object classes, an action, and time, and cannot therefore be encapsulated within one specific class [6]. There have been proposals to express business rules in an object-oriented fashion by using metamodelling [8, 9] but we are not aware of their any further consequences. The rule-modelling approach described in [10] and [11] enables to model global business rules in a natural way. This approach is, however, data-centered, and doesnt therefore include any semantics for actions. We have widened this approach by viewing business rules as agents beliefs that are preconaitions for their actions. This may constitute a powerful paradigm for information systems modelling, design, and implementation. In the following we will take a closer look at our proposed approach. 3. OUR APPROACH From the modelling point of view, we treat software agents as natural and convenient antropomorphic abstractions of functional business units/actors and also external units/actors like customers or suppliers. From the technical point of view, we see software agents in business information systems as rule-basea intelligent aistributea units that implement business ana aatabase logic. he are interestea in how agents unaerstooa in this way coula be utili:ea in business information systems ana how they coula facilitate the moaelling aesign ana aevelopment of such systems When we take a look at the requirements description for some business, we find that the goals of the business are represented in the form of a big number of different rules. A business rule is defined as a statement that defines or constrains some aspect of the business [11]. Alternatively, a business rule may be defined as a law or custom that guides the behaviour or actions of the actors connected to the organization [12]. We view all actors connected to the business, which can be humans, organization units, or external units like customers or suppliers, as agents and assign actions to them. Some of the actors may be represented by software agents. Consequently, business rules aefine ana constrain agents actions. We view an agents action in a broader sense as something that the agent aoes: a human may make a decision, an agent wrapping a database may execute certain retrieval primitives, a statistical computation agent may run certain mathematical procedures, and one agent may send a message to another agent [1]. Please note that our approach is different from the traditional object-oriented approach where action is understood as something that changes the state of an object, and where actions and data belong together. Our agents action may change the state of one or more data objects, but the latter is not true for our agents because they make use of information contained in aifferent databases and other information sources which fully corresponds to the spirit of cooperative information systems described in [2]. A business rule expresses specific constraints on the creation, updating, and removal of persistent data in an information system [11]. Business rules are of aeclarative nature: a business rule describes a desirable, possible state that is either required or prohibited. Examples of business rules from the problem domain of car rental are: 1. A customer must not be blacklisted. 2. A customer may have only one car at any time. 3. The rental rate of a rental is inferred from the rental rate of the group of the car assigned to the rental. 4. A car can be allocated for a rental when it is physically present, is not assigned to any rental, doesnt require repairs, and is not scheduled for service during the planned rental period. 5. Each car must be serviced after every 10,000 kilometres. Business rules can be divided into integrity constraints, derivations, and action rules. Integrity constraint is an assertion that must always be true. Action rule specifies that if something is true, a certain action should be performed. Derivation is a statement of knowledge that is derived from other knowledge in the enterprise. The rules of Examples 1 and 2 are integrity constraints, the rule of Example 3 is a derivation, and the rules of Examples 4 and 5 are action rules. Business rules control business processes. A business process can be defined as a collection of activities that takes one or more kinds of input, and creates an output that is of value to the customer. A business process describes from start to finish the sequence of events required to produce the product or service [13]. Examples of business processes are booking for a seminar, purchasing an umbrella, renting a car, and servicing a car. Business processes typically involve several different autonomous units of an organization. Often business processes also cross organizational boundaries. We have worked out a preliminary methodology how information systems could be modelled on a high level of abstraction by making use of business rules as agents beliefs that constitute preconditions for their actions. This methodology consists of the moaelling of functional organi:ational units by agents, moaelling of the problem aomain by ontology, mapping the ontology to the agents beliefs ana goals, and moaelling of business processes through the agents interactions. These steps should be applied in an iterative manner. 3.1 Modelling Functional Organizational Units by Agents Analogously to the definition presented in [28], we consider an organization to be a set of constraints, expressed as business rules, on the activities performed by agents. According to our methodology, firstly functional organizational units of the organization to be modelled are found. Functional organizational unit can be defined as an entity for managing the performance of activities to achieve one or more goals of the organization [29]. Each functional organizational unit maintains knowledge about a certain functional subfiela of the problem domain that has common business rules ana goals [14]. In case of our example of car rental (v. Figure 1), such functional organizational units are the branch and service aepot. Each organizational functional unit consists of a set of roles. A role defines one or more prototypical job functions in an organization. A role can be played by an organi:ation-agent which includes both human members of an organization and software agents helping them [28]. Each functional organizational unit can thus be represented by one or more software agents. In our example, each branch of the car rental company is represented by a Branch Agent which realizes its business rules. The service depot is represented by the Servicing Agent. In addition, there are Customers Agents which represent external users of the Branch Agents services to them by e. g. managing user interfaces for clerks working in branch offices or managing user interfaces (e. g. Java applets) utilized in reservations done through Internet. Please note that the name Customers Agent is justified even if such an agent is a part of the car rental company because it is also in the interests of the company to represent customers requirements and wishes as adequately and precisely as possible. The Rentals Database Agent and Customers Database Agent respectively mediate databases of rental agreements and customers. These databases have been separated because in addition to the business of car rental, the company has hotels and an airline which share the customers database with it. As we can see, the resulting agent architecture is a variation on a higher level of abstraction of the well-known three-tierea architecture of an information system consisting of the tiers of application, user interface, and data [24]. Messages Customers Database Servicing Agent Messages Messages Messages Messages Agent Customers Database Rentals Database Branch Agent Branch Agent Customers' Agent Branch Agent Messages Messages Pick-ups and drop-offs Reservations Pick-ups and drop-offs Reservations Messages Reservations Pick-ups and drop-offs Messages Messages Messages Rentals Database Agent Customers' Agent Customers' Agent Messages Figure 1. The architecture of an agent-oriented system of car rental 3.2 Domain Modelling by Ontology Secondly, a conceptual moael of the problem domain is created for agents representing functional organizational units. The main components of the conceptual model are the information moael and organi:ation moael. They can both be represented by an ontology of the problem domain. A problem-oriented ontology is a description by truth values of the concepts and relationships of the problem domain that exist for an agent or more commonly for a community of agents [15]. An ontology consists of the concepts (classes), relations between them like e. g. subsumption (inheritance), aggregation, and association, functions, and axioms of the problem domain. The ontology of car rental worked out by us contains e. g. the following concepts: Rental, Customer, Car-For-Rental, Branch, Car-Group, and Car-Model. The concept Rental has subconcepts Reservation-Request, Rental-Reservation, Allocated-Rental, Effective- Rental, and Terminated-Rental, representing different states of a rental agreement. The concept Customer has subconcepts Blacklisted, Has-Car, and Should-Be-Contacted (if a car is not returned on time). Some of the subconcepts of the concept Car-For-Rental are Present, Assigned, Requires-Repairs, and Requires-Service. Ontologies can be viewed as extensions of object-oriented (OO) models of problem domains described e. g. in [13]. However, most OO frameworks neither provide the necessary axioms that constrain the interpretation and well-formed use of the terms defined by them, nor support other ontological constructs, such as metamodels (i. e. defining a model by using the model itself) [30]. The other differences are that ontologies are fully aeclarative while OO models can contain also procedural components, and ontologies are less implementation-orientea than e. g. OO models in UML [3] because the goal of an ontology is to describe a piece of the real world as exactly as possible for agents, and not to specify software directly. Due to their high expressive power, ontologies enable to represent naturally business rules which in our interpretation make up a central part of the specification of the problem domain. Integrity constraints, derivations, and conditional parts of action rules can all be declaratively represented by an ontology. We will subsequently illustrate this statement by some examples expressed in Ontolingua [16] that we used for creating the ontology of car rental. In Ontolingua concepts are represented by frames and their attributes by slots. Representations in Ontolingua of the example business rules from the beginning of section 3 are given in the second column of Table 1. The number of the corresponding example business rule is contained in the first column of the table. According to the semantics of Ontolingua, all free variables that appear in the examples have implicit universal quantification. The rule of the type integrity constraint of Example 1 can be expressed as shown in the first row and second column of Table 1. The expression means that a customer assigned to any Rental-Reservation or its subconcept should not belong to the subconcept Blacklisted of Customer. Customer-Of is a slot of the frames representing the concept Rental and its subconcepts. The integrity constraint of Example 2 can be expressed as shown in the second row and column of Table 1 where the relationship Has-Car is defined as: (<=> (Has-Car ?Customer) (Exists (?Rental) (And (Effective-Rental ?Rental) (= ?Customer (Customer-Of ?Rental))))) This rule states that a customer should not be simultaneously involved in two or more rentals belonging to the Rentals subconcept Effective. A rental belongs to Effective if the customer of the rental has picked up the car. The derivation formulated in Example 3 can be expressed in Ontolingua as shown in the third row and second column of Table 1. This rule determines that the rental rate of a Rental-Reservation, expressed by its slot Rental-Rate-Of, is inferrea from the rental rate of the car group that the car assigned to the rental belongs to. The group of a car is expressed by the slot Car-Group-Of of the frame of Car-For-Rental, and the rental rate of a car group is expressed by the slot Rental-Rate of the frame of Car-Group. The conditional part of the action assertion of Example 4 can be stated as the function of Ontolingua that looks like shown in the fourth row and second column of Table 1. This function maps the given branch, car group, and rental period to the car that, according to the data in the information system, is physically present at the branch (i. e. belongs to the RuIe OntoIogy BeIiefs and GoaIs 1 (=> (Rental-Reservation ?Rental) (Not (Blacklisted (Customer-Of ?Rental)))) GOAL ((Not (Blacklisted (Customer-Of ?Rental))) do create_rental_reservation (?X) end-do) 2 (=> (Effective-Rental ?Rental) (Not (Has-Car (Customer-Of ?Rental)))) GOAL ((Not (Has-Car (Customer-Of ?X))) do create_effective_rental (?X) end-do) 3 (=> (Rental-Reservation ?Rental) (= (Rental-Rate-Of ?Rental) (Rental-Rate (Car-Group-Of (Car-Of ?Rental))))) compute_rental_rate (?Rental) 4 (<=> (= (Available-For-Rental ?Branch ?Group ?Rental-Period) ?Car) (And (Branch ?Branch) (Car-Group ?Group) (Time-Range ?Rental-Period) (Present ?Car) (= (Belongs-To ?Car) ?Branch) (= (Car-Group-Of ?Car) ?Group) (Not (Assigned ?Car)) (Not (Requires-Repairs ?Car)) (Not (Overlaps (Scheduled-For- Service-At ?Car) ?Rental-Period)))) GOAL ((= (Available-For-Rental Y Group-A (Rental-Period-Of R)) ?Car) do allocate_car (?Car, R) end-do) 5 (<=> (Requires-Service ?Car) (And (Not (Scheduled-For-Service ?Car)) (>= (Mileage-Since-Last-Service ?Car) 10000))) GOAL ((Requires-Service ?Car) do schedule_for_service (?Car) end-do) Table 1. Correspondences between business rules, their representations in Ontolingua, and agents beliefs and goals subconcept Present of Car-For-Rental), belongs to the specified branch and car group, is not assigned to any other Rental and doesn't require repairs (i. e. does not belong to the subconcepts Assigned and Requires-Repairs of Car-For-Rental), and whose planned rental period, expressed by the term ?Rental-Period, does not overlap with the scheduled service period of the car (if any), expressed by the slot Scheduled-For-Service-At of the frame of Car-For-Rental. And finally, the conditional part of the action rule of Example 5 can be expressed as the relation of Ontolingua shown in the fifth row and second column of Table 1. This relation returns the truth value true if and only if a car ?Car belongs to the subconcept Requires- Service of Car-For-Rental, i. e. when its mileage since last service, represented by the value of the slot Mileage-Since-Last-Service of the frame of Car-For-Rental, is equal or greater than 10,000, and when the car is not already scheduled for service. 3.3 Mapping the Ontology to the Agents' Beliefs and Goals Thirdly, the ontological model of the problem domain is mapped to the individual agents representing functional organizational units treated in section 3.1. If the expressive power of an agents virtual knowledge base is sufficient, integrity constraints, derivations, and conditional parts of action rules described by the ontology can be directly mapped to the agents beliefs Action rules in full are mapped to the agents goals that perform actions according to pre-specified plans. Mappings of our example business rules to the agents beliefs and goals are given in the third column of Table 1. An agents beliefs may be divided into elementary beliefs and deduced beliefs. Elementary beliefs are beliefs that can always be directly represented in an agents virtual knowledge base. Some of the elementary beliefs from the domain of car rental are (Rental-Reservation X) (X is an instance of the concept Rental-Reservation), (Car-Group Group-A) (the concept Group-A is an instance of the meta-concept Car-Group), (Instance- Of X Group-A) (the car X is an instance of the car group Group-A), and (Next-Higher- Group Group-A Group-B) (Group-A is one-level higher car group than Group-B). Even less expressive knowledge bases, like e. g. relational databases, are capable of representing elementary beliefs. Deduced beliefs are deduced from the elementary beliefs of an agent by making use of the universal and existential quantifiers and , implication and equivalence operators and , and/or mathematical operators. More powerful inference rules can also be introduced if an agent really needs them. Some examples of deduced beliefs are (= (Available-For-Rental Y Group-B Z) X) (the car X of the car group Group-B belonging to the branch Y is available for rental during the time period Z), (Requires-Service X) (the car X requires service), and (= (Rental-Rate-Of R) 150) (the rental rate of the rental agreement R is 150). Special group of deduced beliefs is made up by integrity constraints. An integrity constraint declares what state of affairs the premise state of affairs implies. For example, according to the integrity constraint presented in the first row and second column of Table 1, the existence of any instance of Rental- Reservation implies that the customer of that rental reservation, identified by the value of the corresponding slot, is not an instance of the concept Blacklisted. If this implication is not satisfied, the agent's virtual knowledge base should issue the corresponding error message. Subsequently we'll introduce actions into our model. Action can be defined as something that executes and possibly changes the state of one or more instances of one or more concepts [11]. As such, actions cannot be represented by ontologies, which are meant for representing static, declarative knowledge. For example, we can specify by the ontology of car rental that the subconcepts (i. e. possible states) of the concept Rental are Reservation-Request, Rental-Reservation, Allocated, Effective, and Terminated. But we cannot specify by means of the ontology when and how an instance of the concept Rental changes from one subconcept to other (i. e. from one state to another). In order to represent action rules in full that we cannot do by means of an ontology, we assign actions to agents and make use of the agents' condition-triggered goals to execute actions. Moreover, since we have the worst-case assumption, according to which the expressive power of the beliefs' part of an agent's virtual knowledge base is lower than the expressive power of an ontology used in modelling, we also express integrity contraints through actions. For example, the integrity constaint of Example 1 can be equivalently expressed as shown in the first row and third column of Table 1. The expression says that a rental reservation may be accepted (i. e. the state of an instance of Rental changed from Reservation-Request to Rental-Reservation) only if the customer of that rental is not blacklisted. In the same manner, the integrity constraint of Example 2 can be represented as shown in the second row and third column of Table 1 where the state of an instance of Rental is changed from Allocated-Rental to Effective-Rental only if the customer has not already picked up some car from the car rental company. The derivation of Example 3 can be expressed through an ordinary computational action shown in the third row and column of Table 1. The action is tied to the goal of the corresponding Branch Agent of accepting the rental reservation. While the conditional part of an action rule evaluates the agents beliefs, the agents actions prescribed by the rule are executed through setting goals. For instance, the notion of goal enables us to represent the action rule of Example 4 in the way shown in the fourth row and third column of Table 1. This goal specifies that the agent must allocate a car ?Car of the car group Group-A to the rental reservation R for the rental period of R to be picked up at the branch Y if such a car is available, that is if the function Available-For- Rental evaluates to true. If there are no available cars, the function Available-For-Rental returns the truth value false, and the action is not performed. The action rule of Example 5 can be expressed as shown in the fifth row and third column of Table 1. This statement means that the goal to execute the action schedule_for_service on a car represented by ?Car is set for the agent for effectuation if the condition Requires- Service becomes true for any car ?Car. Effectuation of goals can also be time-dependent like in the following example: GOAL ((= (1.7.1999;18.00,00) Now) do allocate_car (Instance-A1-1, R) end-do) Now stands for the current time. The example says that the car identified by Instance-A1- 1 should be allocated to the rental agreement R on the 1st of July 1999 at 6.00 P.M. 3.4 Modelling Business Processes through Agent Interactions Fourthly, business processes are modelled through agent interactions on the system-wide level, as is shown in the agent interaction diagram in Figure 2. To simplify, the parameters of agent messages have been partly omitted in the figure. A business process of renting a car is depicted in the figure. The process starts with the request of the Customers' Agent to the Branch Agent to reserve for its customer a car of such-and-such car group and model for a certain rental period to be picked up at the branch of the receiving Branch Agent and dropped off at some other branch (message 1). After having received the reservation request, the Branch Agent turns to the Customers Database Agent to ask isnt the customer, who initiated the request, blacklisted (message 2). If the Branch Agent receives a negative reply (message 3), he creates the rental reservation (message 4), and the Customers' Agent is informed that the reservation has been accepted (message 6). Before that, the Branch Agent sets the goal to allocate a car to the rental reservation in question (message 5). It doesn't allocate a car right away because the systems requirements contain the business rule according to which cars are allocated to rental reservations due for pick-up the following working day at the end of each working day. This rule is reflected by the precondition for the plan (procedural specification for accomplishing a goal) of the goal set by message 5 and other goals of the same kind to execute the plan every weekday night at 6.00. A car to the rental reservation under discussion is also allocated a weekday night before the pick-up day by realizing the respective goal and executing the corresponding plan. The allocation involves the two following messages. Firstly, the Branch Agent searches its virtual knowledge base for an available car with the required parameters (message 7). If the car has been found, the Branch Agent assigns the car to the reservation and informs the Rentals' Database Agent about the new state Allocated-Rental of the rental agreement (message 8). On the following day, the customer comes to pick up the car. The Customers Agent asks the Branch Agent to authorize the pick-up (message 9). As any customer may only have one car at any time, the Branch Agent makes sure that the customer does not already have a car rented from any branch of the company by asking that from the Rentals Database Agent (message 10) which consults the database of all rentals that it mediates. Since the reply is negative (message 11), the rental is authorized by the Branch Agent, and the Rentals Database Agent is informed about the change of state of the given rental agreement to Effective-Rental (message 12). The Customers Agent is informed that the pick-up has been authorized (message 13), and the car can be handed over to the customer at the branch. Figure 2. Business process modelling with an agent interaction diagram Customers Agent Branch Agent Customers Database Agent Rentals Database Agent Every weekday night at 6.00 1: request (reserve_car (customer rental-period drop-off-branch group model)) 6: inform (Done (reserve_car (...))) 7: get_available_car (reservation $car) 9: request (authorize_pick_up (...)) 13: inform (Done (authorize_pick_up (...))) 5: ACHIEVE (all ocate_car (reservation)) 2: query-if (Blacklisted customer) 3: inform (Not (Blacklisted customer)) 8: inform (Allocated-Rental car customer rental-period pick-up-branch drop-off-branch) 10: query-if (Has-Car customer) 11: inform (Not (Has -Car customer)) 12: inform (Effective-Rental car customer rental-period pick-up-branch drop-off-branch) 4: create_rental_reservation (... $reservation) As another example of modelling business processes through agent interactions, the process of negotiations of three branch agents about transferring a car is depicted in Figure 3. The requirements contain the business rule according to which if more cars have been requested than are available in a car group at a branch, the branch manager may ask other branches whether they have cars they can transfer to him. This business rule can be automated with the help of agents. The agent of the branch needing a car starts the process by initiating a contract net for performing the action transfercar with the lowest possible cost. In our example, this is reflected by the call-for-proposals message that the Branch Agent I broadcasts to other branch agents (e. g. messages 1 and 3). The parameters parts of these messages contain the car group and the period a car is required for. The Branch Agents II and III, whose branches happen to have a suitable car, respond with the propose messages where each of them specifies the cost of the cars transfer from its branch to the branch of the Branch Agent I (messages 2 and 4). The costs that are calculated by the Branch Agents II and III take into account the distance between the branches and possible losses of the "donor" branch due to the transfer. Since the cost to transfer a car from the branch of the Branch Agent II appears to be lower than the cost to transfer a car from the branch of the Branch Agent III, the proposal of the Branch Agent II is accepted (message 5) without any preconditions on the Branch Agent I's part (the parameter (true) of the message). The proposal of the Branch Agent III is accordingly rejected (message 6) by stating that the reason for rejection is too high cost of transfer. The business process ends with the request of the Branch Agent I to the Branch Agent II to perform the actual transfer (message 7), and the reply of the Branch Agent II telling that a car has been dispatched (message 8). Figure 3. Negotiations of branch agents about transferring a car Branch Agent I Branch Agent II Branch Agent III 1: cfp (transfer_car (group rental-period)) 2: propose ((transfer_car (group rental-period)) (Cost (140))) 3: cfp (transfer_car (group rental-period)) 6: reject-proposal ((transfer_car (group rental-period)) (Cost-Too-High (200))) 5: accept-proposal ((transfer_car (group rental-period)) (true)) 4: propose ((transfer_car (group rental-period)) (Cost (200))) 7: request (transfer_car (group rental-period)) 8: inform (Done (transfer_car (group rental-period))) 3.5 Implementing the Agents Since knowledge bases and databases with very different expressive power can be used as agents virtual knowledge bases, we have chosen to represent explicitly only elementary beliefs, and to operationali:e (i e represent proceaurally) aeaucea beliefs of agents. Our approach assumes the virtual knowledge base of an agent to be capable of representing elementary beliefs at least at the level of the Assertion Language (AL) of the proposed Open Knowledge Base Connectivity Standard (OKBC) [19]. The AL is a first-order language with conjunction and predicate symbols, but without disjunction, explicit quantifiers, relation or function symbols, implication, negation, or equality. Consequently, even relational databases, let alone object-oriented databases, are AL-compliant. Using the methodology described in sections 3.1 3.4, we have implemented an experimental agent-oriented information system of car rental. In our implementation we have utilized Java-based Jam agents [31] that are based on the approach of hybria knowleage ana proceaural reasoning [18]. According to this approach, an agents knowledge is represented in two ways: as a belief base holding the agents model of the world (including itself and other agents), and procedures or plans that use the declarative knowledge in the belief base to direct the agents actions [18]. A Jam agents world model holds the facts (beliefs) that the agent uses to represent the current state of the world [31]. Since a Jam agents belief base can contain only simple propositions, whose arguments order, semantics, and typing is unconstrained [31], it is capable of representing only elementary beliefs. Consequently, all deduced beliefs should be represented procedurally. For example, the deduced belief, whose ontological representation is given in the fifth row and second column of Table 1, can be implemented as the following OKBC-compliant static Java method of the class Car_For_Rental that searches the agents virtual knowledge base for a car requiring service and returns the corresponding instance of the Java class Car_For_Rental or null if no such a car was found: public static Car_For_Rental requiresService () { boolean returnValue = null; Enumerator e = kb.enumerate_class_instances (Car_For_Rental); e.prefetch (); while (e.has_more_p ()) { Node car = e.next (); Values2 values = kb.get_slot_value (Car_For_Rental, Mileage_Since_Last_Service); if (values.secondValue().number >= 10000) returnValue = car; } e.free (); return (returnValue); } A Jam agents behaviour is invoked by specifying goals that the agent is to achieve. A Jam agents plan defines a procedural specification for accomplishing a goal. Its applicability is limited to a particular goal, and may be further constrained to a certain preconaition and context that has to be maintained. The procedure to follow in order to accomplish the goal is given in the plans procedural boay [31]. For example, the business rule specified in the fifth row and third column of Table 1 can be specified as the persistent goal ACHIEVE schedule_for_service of the Branch Agent that is implemented as a Jam agent. The plan for accomplishing this goal looks like as follows: Plan: { NAME: "Plan of scheduling a car for service" DOCUMENTATION: "This is a plan for the top-level goal of scheduling cars for service." GOAL: ACHIEVE schedule_for_service; BODY: WHEN : TEST (requiresService $car) { ATOMIC { EXECUTE connectToAgentAsClient 5557 tte1038.tte.vtt.fi $in $out; EXECUTE sendMessage $out (perform(schedule_for_service $car)); } } POST schedule_for_service; } The user-defined primitive function requiresService of Jam returns true if a car to be scheduled for service was found and false otherwise. In the first case the corresponding instance of the Java class Car_For_Rental is assigned to the plans variable $car, and the actions in the agents body send the performative requesting to schedule the car $car for service to the Servicing Agent. At the lower level, the Jam function requiresService invokes the Java method of the same name that was presented above. Every cycle of the Branch Agents work maximally only one car is returned and scheduled for service by the plan for the goal schedule_for_service. After achieving the goal, the agent will set the goal to execute the plan anew by the POST action. This example thus also reveals how iterations can be programmed by repetitive setting of goals. Agent communication language used in our experimental system is a subset of ACL [20]. 4. RELATED WORK The most recent work treating the modelling and design of agent-oriented information systems is [32] where a general methodology for agent-oriented analysis and design is presented. The proposed methodology deals with both the macro-level (societal) and the micro-level (agent) aspects of systems. In the analysis phase of the methodology, the roles in the system are identified and the patterns of interaction that occur in the system between various roles are recognized. The functionality of each role is defined by its liveness and safety responsibilities. Liveness responsibilities are those that say something will be done, e. g. whenever the coffee machine is empty, fill it up. Safety responsibilities relate to the absence of some undesirable condition arising, e. g. the coffee stock should never be empty. In the design phase, the liveness and safety responsibilities are respectively mapped to agents services and pre- and postconaitions on each service. Liveness and safety responsibilities thus bear a close resemblance to business rules. The difference from our work is that the methodology proposed in [32] is general, while our approach is more domain-specific and tied to the BDI agent architecture described in [25]. Another similar methodology and modelling technique that is specifically related to BDI agents is presented in [17]. The developed models extend object-oriented models. The main separation in the models is between external and internal models. There are two primary external moaels: the agent moael, which describes agent classes and instances, and the interaction moael, which captures communications and control relationships between agents. The internal moaels represent the beliefs, goals, and plans of particular agent classes. The work [17] is similar to ours in dealing with agents roles, beliefs, goals, and plans. The main differences are that our work does not describe agent classes and instances and puts more emphasis on the modelling of agents beliefs. In the work described in [21] agents are directly applied to managing business processes. The main difference from our work is that [21] focuses on the interaction and negotiation aspects of business processes, and does not explicitly treat conceptual models of the problem domain, and agents beliefs and goals. Another difference is that the main emphasis of our work is on developing an integrated approach to the modelling, design, and implementation of agent-oriented information systems, and not just on implementing specific agent-based systems. The paper [26] also concentrates on the interaction aspects of agents of the domain of integrated supply chain management, and particularly on the agents mutual obligations and interdictions. Conceptual modelling of the problem domain is included in the paper [33] where concepts and relations between concepts are defined in hierarchies and rules that are used for automatic generation of prototype agent applications directly from their specifications. The latter is also one of our future intentions. 5. CONCLUSIONS AND FUTURE WORK Our approach is based on the rather well-developed methodology of capturing information systems requirements in the form of business rules (see e. g. [10, 11, 27])). Implementation of business rules has been traditionally connected to (active) databases [22]. We have widened the sphere of business rules use by showing that they can also be interpreted as agents' beliefs and preconditions for agents actions. With our approach, agents are viewed as meta-level intelligent objects that implement business rules and thus control the behaviour of data objects. Basea on the case stuay of car rental that we have usea in our work, the following generalized conclusions can be made: 1. Integrity constraints, derivations, and conditional parts of action rules can be expressed as beliefs of software agents. 2. Action rules in full can be expressed as goals of software agents. 3. Processes can be described through repetitive setting and realization of agents' goals, and through high-level communication between the agents. 4. Agents beliefs and goals representing business rules can be satisfactorily implemented by using a combination of hybrid knowledge and procedural reasoning. True, further formalization, verification, and validation of our work needs to be done, but this will be one of the subjects of our future work. We think that our approach can make the design and implementation of complicated information systems considerably easier by raising the level of abstraction. We believe that just like object-oriented programming has given rise to object-oriented modelling and design, agent-oriented programming, that is programming in terms of agents beliefs and goals, may give rise to the proper agent-oriented modelling and design. We hope our work to be a step towards that. We think that agents are well-suited for use in cooperative information systems where both data and application logic are distributed like e. g. in our experimental information system of car rental. We hope our work to be a step from the currently predominant client/server systems towards the peer-to-peer systems of the future. A major weakness of our work is dealing with agents interactions. We feel that additional techniques for modelling interactions need to be introduced. Perhaps we also need agents of a special type to coordinate interactions between the agents representing functional organizational units. Like it was mentioned before, our future aims include further formalization, verification, and validation of our work. Another important aim is is to work out the environment that would enable semiautomatic generation of ob/ect-orientea implementations of agent- orientea business information systems from their high-level descriptions by ontologies and in terms of agents' beliefs and goals. This could be done by e. g. using the system NUT [23]. 6. REFERENCES [1] Y. Shoham, Agent-Oriented Programming, Artificial Intelligence, 60(1), 51-92, 1993. [2] G. de Michelis, E. Dubois, M. Jarke et al, Cooperative Information Systems. A Manifesto. Available at http://www.sts.tu-harburg.de/projects/EUCAN/manifesto.html [3] See http://www.rational.com/uml/index.jtmpl [4] See http://www.rational.com/products/rose/index.jtmpl [5] N. R. Jennings, K. Sycara, M. Wooldridge, A Roadmap of Agent Research and Development, Autonomous Agents ana Multi-Agent Systems, 1(1), 7-38, 1998. [6] G. M. Hydalsvik, G. Sindre, On the Purpose of Object-Oriented Analysis. In: OOPSLA93 Conference Proceedings, ACM Sigplan Notices, October 1993, pp. 240- 253. [7] R. L. Moore, Modeling Objects, Ob/ect Maga:ine, Vol. 6, No. 6, August 1996, pp. 35-40. [8] T. Blanchard, Meta Model Elements as a Foundation for Implementation of Business Rules, Metamoaeling in OO OOPSLA95 horkshop, October 15, 1995. Available at http://saturne.info.uqam.ca/Labo_Recherche/Larc/MetamodelingWorkshop/Blanchard [9] J. Odell, Meta-Modeling, Metamoaeling in OO OOPSLA95 horkshop, October 15, 1995. Available at http://www.info.uqam.ca/Labo_Recherche/Larc/MetamodelingWorkshop/Odell/metamodeling/ [10] Ronald G. Ross, The Business Rule Book. Classifying Defining ana Moaeling Rules, Second Edition. Boston, Massachusetts, Database Research Group, Inc., 1997. [11] GIDE Business Rules Pro/ect Final Report, October, 1997. Prepared by D. Hay and K. A. Healy. Available at http://www.guide.org/ap/apbrules.htm [12] F. Van Assche et al, Information systems development: a rule-based approach, Knowleage-Basea Systems, 1(4), 227-234, 1988. [13] E. Yourdon, K. Whitehead, J. Thomann, K. Oppel, P. Nevermann, Mainstream Ob/ects. An Analysis ana Design Approach for Business. Yourdon Press, 1996. [14] F. Farhoodi, I. Graham, A Practical Approach to Designing and Building Intelligent Software Agents. In: Proceeaings of the First International Conference ana Exhibition on the Practical Application of Intelligent Agents ana Multi-Agent Technology (PAAM96), London, UK, April 1996, pp. 181-204. [15] T. R. Gruber, A Translation Approach to Portable Ontologies, Knowleage Acquisition, 5(2), 199-220, 1993. Available at http://ksl-web.stanford.edu/knowledge- sharing/papers/README.html#ontolingua-intro [16] See http://www-ksl-svc.stanford.edu:5915 [17] D. Kinny, M. Georgeff, A. Rao, A Methodology and Modelling Technique for Systems of BDI Agents. In: Agents Breaking Away. Proceeaings of the Seventh European horkshop on Moaelling Autonomous Agents in a Multi-Agent horla, (LNAI Volume 1038), pp. 56-71, Springer-Verlag, Berlin, Germany, 1996. [18] S. Hgg, F. Ygge, Agent-Orientea Programming in Power Distribution Automation. An Architecture a Language ana their Applicability Licentiate Thesis, Lund University, 1995. [19] V. K. Chaudri, A. Farquhar, R. Fikes, P. D. Karp, J. P. Rice, OKBC: A Programmatic Foundation for Knowledge Base Interoperability. In: Proceeaings of the Fifteenth National Conference on Artificial Intelligence (AAAI-98), July 26-30, 1998, Madison, Wisconsin, USA, pp. 600-607. Available at http://www-ksl- svc.stanford.edu:5915/doc/papers/ksl-98-08/index.html [20] Agent Communication Language, FIPA 97 Specification. Available at http://www.fipa.org/ [21] N. R. Jennings et al, Using Intelligent Agents to Manage Business Processes. In: Proceeaings of the First International Conference ana Exhibition on the Practical Application of Intelligent Agents ana Multi-Agent Technology (PAAM96), London, UK, April 1996, pp. 345-360. [22] Active Database Systems. Triggers ana Rules for Aavancea Database Processing. Edited by Jennifer Widom and Stefano Ceri. Morgan Kaufmann Publishers, Inc., San Francisco, 1996. [23] E. Tyugu, Using Classes as Specifications for Automatic Construction of Programs in the NUT System, Journal of Automatea Software Engineering, 1(34), 315334, 1994. [24] Alex Berson, ClientServer Architecture. McGraw-Hill, 1992. [25] M. P. Georgeff, A. Lansky, Reactive reasoning and planning. In: Proceeaings of the Sixth National Conference on Artificial Intelligence (AAAI-87), Seattle, Washington, USA, 1987, pp. 677682. [26] M. Barbuceanu, T. Gray, S. Mankovksi, Roles of Obligations in Multiagent Coordination, Appliea Artificial Intelligence, 13(1), 1138, 1999. [27] H. Herbst Business Rule-Orientea Conceptual Moaeling (Contributions to Management Science). Springer-Verlag, 1997. [28] M. S. Fox, M. Barbuceanu, M. Gruninger, Jinxin Lin, An Organizational Ontology for Enterprise Modeling. In. Simulating Organi:ations. Computational Moaels of Institutions ana Groups Edited by M. J. Prietula, K. M. Carley, and L. Gasser. AAAI Press / The MIT Press, 1998. [29] M. Uschold, M. King, S. Moralee, and Y. Zorgios, The Enterprise Ontology, The Knowleage Engineering Review, 13(1), 31-90, 1998. [30] K. Mahalingam, M. N. Huhns, Ontology Tools for Semantic Reconciliation in Distributea Heterogeneous Information Environments. Available at http://www.engr.sc.edu/research/CIT/people/faculty/huhns.html#pub [31] M. J. Huber, Jam Agents in a Nutshell. Available at http://members.home.net:80/marcush/IRS/ [32] M. Wooldridge, N. R. Jennings, D. Kinny, A Methodology for Agent-Oriented Analysis and Design. In: Proceeaings of the 3ra International Conference on Autonomous Agents (Agents-99), Seattle, Washington, USA, May 1-5, 1999 (to appear). Available at http://gryphon.elec.qmw.ac.uk/dai/pubs/ [33] F. M. T. Brazier, B. M. Dunin-Keplicz, N. R. Jennings, J. Treur, DESIRE: Modelling Multi-Agent Systems in a Compositional Formal Framework, International Journal of Cooperative Information Systems, 6(1), 67-94, 1997.