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.