Post on 02-Jun-2018
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
kuldar.taveter@vtt.fi
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
http://slidepdf.com/reader/full/aios99-kt 2/17
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
http://slidepdf.com/reader/full/aios99-kt 3/17
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
http://slidepdf.com/reader/full/aios99-kt 4/17
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
http://slidepdf.com/reader/full/aios99-kt 5/17
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
http://slidepdf.com/reader/full/aios99-kt 6/17
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
http://slidepdf.com/reader/full/aios99-kt 7/17
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
http://slidepdf.com/reader/full/aios99-kt 8/17
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
http://slidepdf.com/reader/full/aios99-kt 9/17
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
http://slidepdf.com/reader/full/aios99-kt 10/17
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
http://slidepdf.com/reader/full/aios99-kt 11/17
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
http://slidepdf.com/reader/full/aios99-kt 12/17
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
http://slidepdf.com/reader/full/aios99-kt 13/17
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
http://slidepdf.com/reader/full/aios99-kt 14/17
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
http://slidepdf.com/reader/full/aios99-kt 15/17
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
http://slidepdf.com/reader/full/aios99-kt 16/17
[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
http://slidepdf.com/reader/full/aios99-kt 17/17
[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.