aios99-kt

8/11/2019 aios99-kt

http://slidepdf.com/reader/full/aios99-kt 1/17

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

[email protected]

We propose an approach where the modelling, design, and

implementation of agent-oriented information systems is based onbusiness 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.

is an emerging abstraction that the field of (business) information systems may also

benefit from. 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

(BDI) model [25]. Main components of such an agent are information

store that consists of the agent’s and goal store that consists of the agent’s .

These two stores form an agent’s 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 that arise from

his beliefs and goals. Agents communicate with each other and humans in some high-

level . 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 [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 fulfillthose goals. The process of requirements’ capture for cooperative information systems

8/11/2019 aios99-kt


includes the steps of , , and

s [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 adequateobjectives’ and requirements’ representation language should support a style

of specification which offers the possibility to model requirements adopting an

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.

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 therather 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 byusing metamodelling [8, 9] but we are not aware of their any further consequences. The

8/11/2019 aios99-kt


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 doesn’t therefore include

any semantics for actions. We have widened this approach by viewing

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

From the modelling point of view, we treat software agents as natural and convenient

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 .

When we take a look at the requirements’ description for some business, we find that the

of the business are represented in the form of a big number of different rules. A

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 connected to the business, which can be humans, organization units, or external

units like customers or suppliers, as and assign to them. Some of the actors

may be represented by software agents. Consequently,

. We view an agent’s action in a broader sense as something that the agent: 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 agent’s action 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

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 data in an information system [11]. Business rules are of : a

business rule describes a desirable, possible state that is either required or prohibited.

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, doesn’t require repairs, and is not scheduled for service during the planned

rental period.5. Each car must be serviced after every 10,000 kilometres.

8/11/2019 aios99-kt


Business rules can be divided into integrity constraints, derivations, and action rules.

is an assertion that must always be true. specifies that if

something is true, a certain action should be performed. 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 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’ beliefsthat constitute preconditions for their actions. This methodology consists of the

, , , and

. These steps should be applied in an

iterative manner.

Analogously to the definition presented in [28], we consider an 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. 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

of the problem domain that has [14]. In case of

our example of car rental (v. Figure 1), such functional organizational units are the

and . Each organizational functional unit consists of a set of roles. A

defines one or more prototypical job functions in an organization. A role can be

played by an 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 rentalcompany is represented by a which realizes its business rules. The service

depot is represented by the . In addition, there are 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 and

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

8/11/2019 aios99-kt


abstraction of the well-known of an information system

consisting of the tiers of application, user interface, and data [24].

Messages

Customers’ Database

Servicing Agent

MessagesMessages

MessagesMessages

Agent

Customers’

Database

Rentals’

Database

Branch AgentBranch 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

Secondly, a of the problem domain is created for agents representing

functional organizational units. The main components of the conceptual model are the

and . They can both be represented by an

of the problem domain. A 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

(), between them like e. g. subsumption (inheritance), aggregation, and

association, , and 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 arePresent, Assigned, Requires-Repairs , and Requires-Service.

8/11/2019 aios99-kt


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 while OO models can contain also procedural components, andontologies are 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 ,

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 and their attributes by .

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 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 Rental’s 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 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

8/11/2019 aios99-kt


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

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 agent’s virtual knowledge base is sufficient, integrity constraints, derivations, and

conditional parts of action rules described by the ontology can be directly mapped to the

agent’s Action rules in full are mapped to the agent’s that perform

8/11/2019 aios99-kt


according to pre-specified . Mappings of our example business rules to the agents’

beliefs and goals are given in the third column of Table 1.

An agent’s beliefs may be divided into elementary beliefs and deduced beliefs.

are beliefs that can always be directly represented in an agent’s

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 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. 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. 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 and 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 to execute actions.

Moreover, since we have the worst-case assumption, according to which the expressivepower 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 alreadypicked up some car from the car rental company.

8/11/2019 aios99-kt


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 agent’s beliefs, the agent’s

actions prescribed by the rule are executed through setting goals. For instance, the notionof 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 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.

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 isn’t 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 (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, theBranch Agent assigns the car to the reservation and informs the Rentals' Database Agent

8/11/2019 aios99-kt


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 thereply 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 weekdaynight at 6.00

1: request (reserve_car (custom er 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 (allocate_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)

8/11/2019 aios99-kt


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 theprocess by initiating a for performing the action with the lowest

possible cost. In our example, this is reflected by the all- or-roposals 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 car’s 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 AgentII 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: c fp (transfer_car (group rental-period))

2: propose ((t ransfer_car (group rental-period)) (Cost (140)))

3: c fp (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 ((t ransfer_car (group rental-period)) (Cost (200)))

7: request (transfer_car (group rental-period))

8: inform (Done (transfer_car (group rental-period)))

8/11/2019 aios99-kt


Since knowledge bases and databases with very different expressive power can be used as

agents’ virtual knowledge bases, we have chosen to , and to . Our

approach assumes the virtual knowledge base of an agent to be capable of representingelementary 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

[18]. According to this approach, an agent’s

knowledge is represented in two ways: as a belief base holding the agent’s model of the

world (including itself and other agents), and procedures or that use the declarative

knowledge in the belief base to direct the agent’s actions [18].

A Jam agent’s world model holds the facts (beliefs) that the agent uses to represent the

current state of the world [31]. Since a Jam agent’s 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 classCar_For_Rental that searches the agent’s 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);}

8/11/2019 aios99-kt


A Jam agent’s behaviour is invoked by specifying that the agent is to achieve. A

Jam agent’s defines a procedural specification for accomplishing a goal. Its

applicability is limited to a particular goal, and may be further constrained to a certain

and that has to be maintained. The procedure to follow in order to

accomplish the goal is given in the plan’s procedural [31]. For example, the business

rule specified in the fifth row and third column of Table 1 can be specified as thepersistent 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 plan’s variable $car, and the

actions in the agent’s body send the performative requesting to schedule the car $car forservice 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 Agent’s 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 can be programmed by .

Agent communication language used in our experimental system is a subset of ACL [20].

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

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. are those that say

“something will be done”, e. g. “whenever the coffee machine is empty, fill it up”.

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

8/11/2019 aios99-kt


responsibilities are respectively mapped to agents’ and and 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 : the , which describes agent classes and instances,

and the , which captures communications and control relationships

between agents. The 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.

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,

.

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

8/11/2019 aios99-kt


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 . 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 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 s 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].

8/11/2019 aios99-kt


[1] Y. Shoham, Agent-Oriented Programming, , 60(1), 51-92,

1993.

[2] G. de Michelis, E. Dubois, M. Jarke et al,

. 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, , 1(1), 7-38, 1998.

[6] G. M. Høydalsvik, G. Sindre, On the Purpose of Object-Oriented Analysis. In:

OOPSLA’93 Conference Proceedings, , October 1993, pp. 240-

253.

[7] R. L. Moore, Modeling Objects, , Vol. 6, No. 6, August 1996, pp.

35-40.

[8] T. Blanchard, Meta Model Elements as a Foundation for Implementation of Business

Rules, , October 15, 1995. Available athttp://saturne.info.uqam.ca/Labo_Recherche/Larc/MetamodelingWorkshop/Blanchard

[9] J. Odell, Meta-Modeling, , October 15,

1995. Available athttp://www.info.uqam.ca/Labo_Recherche/Larc/MetamodelingWorkshop/Odell/metamodeling/

[10] Ronald G. Ross, ,

Second Edition. Boston, Massachusetts, Database Research Group, Inc., 1997.

[11] , 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,

, 1(4), 227-234, 1988.

[13] E. Yourdon, K. Whitehead, J. Thomann, K. Oppel, P. Nevermann, . Yourdon Press, 1996.

[14] F. Farhoodi, I. Graham, A Practical Approach to Designing and Building Intelligent

Software Agents. In:

(PAAM’96), London, UK, April 1996, pp. 181-204.

[15] T. R. Gruber, A Translation Approach to Portable Ontologies, , 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:

,(LNAI Volume 1038), pp. 56-71, Springer-Verlag, Berlin, Germany, 1996.

[18] S. Hägg, F. Ygge,

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:

, 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] , FIPA 97 Specification. Available athttp://www.fipa.org/

8/11/2019 aios99-kt


[21] N. R. Jennings et al, Using Intelligent Agents to Manage Business Processes. In:

(PAAM’96), London,

UK, April 1996, pp. 345-360.

[22] .

Edited by Jennifer Widom and Stefano Ceri. Morgan Kaufmann Publishers, Inc., SanFrancisco, 1996.

[23] E. Tyugu, Using Classes as Specifications for Automatic Construction of Programs

in the NUT System, , 1(3–4), 315–334,

1994.

[24] Alex Berson, . McGraw-Hill, 1992.

[25] M. P. Georgeff, A. Lansky, Reactive reasoning and planning. In:

, Seattle, Washington,

USA, 1987, pp. 677–682.

[26] M. Barbuceanu, T. Gray, S. Mankovksi, Roles of Obligations in Multiagent

Coordination, , 13(1), 11–38, 1999.

[27] H. Herbst . Springer-Verlag, 1997.

[28] M. S. Fox, M. Barbuceanu, M. Gruninger, Jinxin Lin, An Organizational Ontology

for Enterprise Modeling. In

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,

, 13(1), 31-90, 1998.

[30] K. Mahalingam, M. N. Huhns,

. Available athttp://www.engr.sc.edu/research/CIT/people/faculty/huhns.html#pub

[31] M. J. Huber, . Available athttp://members.home.net:80/marcush/IRS/

[32] M. Wooldridge, N. R. Jennings, D. Kinny, A Methodology for Agent-Oriented

Analysis and Design. In:

, 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,

, 6(1), 67-94, 1997.

aios99-kt

Documents

Transcript of aios99-kt