The problem of conceptualisation is the first step towards the identication of the functional requirements of a system. This article proposes two extensions of well-known object oriented techniques: UER (User-Environment-Responsibility) technique and enhanced CRC (Class-ResponsibilityCollaboration) cards. UER technique consists of (a) looking for the users of systems and describing the ways the system is used; (b) looking for the objects of the environment and describing the possible interactions; and (c) looking for the general requirements or goals of the system, the actions that it should carry out without explicit interaction. The enhanced CRC cards together with the internal use cases technique is used for dening collaborations between agents. These techniques can be easily integrated in UML (Unied Modelling Language) [2], dening the new notation symbols as stereotypes

Garijo Ayestaran, Mercedes

Iglesias Fernandez, Carlos Angel

Servicio de Coordinación de Bibliotecas de la Universidad Politécnica de Madrid

UER Tehnique: Coneptualisation for
Agent Oriented Development
Carlos A. Iglesias
Departamento Ingeniera de Sistemas Telematios, Universidad Politenia de Madrid
E.T.S.I. Teleomuniaion, Ciudad Universitaria s/n, 28040 Madrid (Spain)
And
Meredes Garijo
Departamento Ingeniera de Sistemas Telematios, Universidad Politenia de Madrid
E.T.S.I. Teleomuniaion, Ciudad Universitaria s/n, 28040 Madrid (Spain)
Abstrat
The problem of oneptualisation is the rst
step towards the identiation of the funtional
requirements of a system. This artile pro-
poses two extensions of well-known objet oriented
tehniques: UER (User-Environment-Responsibility)
tehnique and enhaned CRC (Class-Responsibility-
Collaboration) ards. UER tehnique onsists of (a)
looking for the users of systems and desribing the
ways the system is used; (b) looking for the objets
of the environment and desribing the possible inter-
ations; and () looking for the general requirements
or goals of the system, the ations that it should arry
out without expliit interation. The enhaned CRC
ards together with the internal use ases tehnique
is used for dening ollaborations between agents.
These tehniques an be easily integrated in UML
(Unied Modelling Language) [2℄, dening the new
notation symbols as stereotypes.
Keywords: Agent Oriented Software Engineering,
multi-agent systems modelling, autonomous agents
modelling, environment ases, goal ases
1. Introdution
The problem of oneptualisation is the rst step
towards the identiation of the funtional require-
ments of a system. One of the most extended teh-
niques for getting a rst idea of the system is the Use
Case tehnique [5℄. The tehnique onsists in identi-
fying the possible users of the systems, and the possi-
ble user goals, desribing ways of ahieving these user
goals, that are alled use ases. Usually, dierent use
ases an be ombined with the relationships extends
(if a use ase is an extension of another one) or uses
(if a use ase is a part of another one). This teh-
nique is very simple and intuitive and has been very
suessful for requirements eliitation and validation.
This tehnique an be used for oneptualising a
multiagent system, as desribed in [4℄. Nevertheless,
autonomous agents are distinguished beause they do
not need a user that supervises their exeution. So,
while with use ases we have to answer the question
\How is used my system?", we ould ask ourselves for
other requirements of our system suh as: \When and
how my system at and reat to the environment?"
(environment ases) and \What are the goals of the
system?" (responsibility or goal ases). This artile
introdues these new onepts in the oneptualisa-
tion phase and the orresponding tehniques and no-
tations.
In order to oneptualise an agent-based system,
two general tehniques are proposed: the new UER
ases tehnique (setion 2), that deals with the iden-
tiation of use, reation and goal ases of an agent
or a multiagent system, and the enhaned Class-
Collaboration-Responsibility Cards tehnique (se-
tion 3) that deals with the identiation of respon-
sibilities, plans and ollaborations of an agent. Both
tehniques are omplementary. the UER tehnique
an be used for both autonomous or multiagent sys-
tems (for identifying use, reative and goal ases of
the whole system). The enhaned CRC ards are only
used for oneptualising multiagent systems, sine
they guide the denition of ollaborative senarios.
2. UER tehnique
The UER (User-Environment-Responsibility) teh-
nique proposes the ombination of user, environment
and responsibility-driven analysis for oneptualising
a system from an agent-oriented perspetive. This
tehnique an be used for oneptualising a partiu-
lar autonomous agent or the general requirements of
a multiagent system.
User-Centered Analysis. The potential users
(alled ators) of the system are identied, together
with their possible tasks or funtions. The result of
this analysis is the set of use ases. This analysis an-
swers the question: How are the possible uses of the
multiagent system?
Environment-Centered Analysis. Agents an be sit-
uated in an environment, and this environment needs
to be modelled. In partiular, we are interested in
modelling how the system an at and reat to this
environment. The result of this analysis is the set of
reation ases. This analysis answers the question:
How the multiagent system has to reat to the envi-
ronment?
Responsibility-driven Analysis. In ontrast with
usual software systems, multiagent systems an at
proatively. The user an desire that the system has
some responsibilities, that is, the user an assign some
goals or responsibilities to the system and the system
arries out these responsibilities without a diret de-
mand. This analysis answers the question: What are
the goals of the system? The main dierene of goal
ases from the user ases, is that the uses ases show
how the system gives an answer to a user request,
while the goal ases show how the system behaves
when some ondition is fullled.
User-Centered Analysis
A use ase [5℄, [6℄, [7℄ desribes the possible intera-
tions or uses of a user with the system. System users
are alled ators, and represent external entities of
the system. Use ases an be ombined, pointing out
if a use ase extends or uses a previous use ase.
User-Centered Analysis onsists of the following
steps [5℄, [6℄, [8℄, [7℄:
 Identify the ators. It is speially relevant to iden-
tify the roles played by the ators. Eah role is on-
sidered a dierent ator. There are two general kinds
of ators: human ators (round head) and software
ators (square head), as shown in Fig. 1.
1
 Identify the use ases. This proess an be arried
out by answering the following questions [5℄, [7℄:
{ What are the main tasks or funtions arried out
by eah ator?
{ What system information is aquired, produed
or hanged by eah ator?
{ Does any ator inform about external hanges in
the system environment?
{ What information is needed by eah system ator?
{ Does any ator desire to be informed about unex-
peted hanges?
 Group the use ases if they are variations of the
same subjet (for example, 'move a heavy stone',
'move a light stone').
 Determine the interations of eah identied use
ase.
 Desribe the use ases, using both a graphial no-
tation [3℄, [2℄, [7℄ and textual templates.
 Consider every possible exeption that an happen
during the interations and how this aets to the use
ases.
 Look for relationships among the use ases: extrat
ommon parts and point out if a use ase adds the
interations of another use ase (relationship \uses")
or adds information ontained in another use ase (re-
1
This distintion is used for desribing later the interations, using an
agent ommuniation language based on speeh ats or not.
lationship \extends" or \inludes"). A use ase an
also inherit the general interation of an abstrat use
ase with the `relationship \instantiates".
 Desribe the interations of eah senario, using
MSC (Message Sequene Chart) notation [3℄. MSC
has been seleted beause is a standardised formal
desription tehnique with a textual and graphial
grammar. Some of the relevant features for our pur-
poses are the availability of a language (HMSC, High
Level MSC) for dening the phases of the interation,
and the denition of operators for expressing alterna-
tives, exeptions and onurrene in the same dia-
gram. Sequene and ollaboration diagrams do not
allow to express these issues in suh an easy way, but
an also be used.
Environment Centered Analysis
The goal of environment entered analysis is to
identify the relevant objets of the environment and
the possible ations and reations of the agent. This
will be later used for agent sensor modelling.
Environment Centered Analysis onsists of the fol-
lowing steps:
 Identify objets of the environment. This objets
are shown in the use ase diagram as louds (Fig. 1).
This symbol an be dened in UML as an stereotype.
 Identify the possible events oming from eah ob-
jets and establish a hierarhy if possible.
 Identify the possible ations eah agent an arry
out on the environment objets.
 Desribe (in natural language) the reation ases
oming from interation with the environment. De-
sribe in detail eah possible senario. Think if there
are several senarios oming from the same reation
ase, and if every senario is autonomous (it is only
managed by the agent that reeives the stimuli) or
ooperative (it is managed in ooperation with other
agents).
 Group related reative ases with the relationships
\uses", \extends", \inludes" or \instantiates". For
example, \avoid obstale" an group dierent senar-
ios for avoiding an obstale depending on its nature,
and an be avoided in an autonomous way (e.g. just
going to the left of the obstale) or in a ooperative
way (e.g. asking for help to move it).
 Desribe the reative goal: its name, the ativa-
tion ondition (e.g. a wall very lose), the deativa-
tion ondition and the suessful and failure ondition
(when the reation has been eetive or not).
Goal Driven Analysis
Goal driven analysis deals with the denition of
requirements of the system, that should be fullled
without the diret interation with the user.
Goal Driven Analysis onsists of the following
steps:
 Identify responsibilities (goals) of the system that
require some ation. Some of the hints for identifying
these goals are:
{ Look for non funtional requirements, suh as
time requirements (e.g. 'Give an answer before 5 min-
utes') or seurity requirements (e.g. 'Buy a produt
in a seure way'). Sometimes the agent needs to arry
out speial ations to ahieve these goals.
{ Desribe when some internal variable of the agent
an reah a not desired value and some ation should
be arried out. For example, high/low temperature,
too many proesses, et.).
{ Desribe undesired states, possible failures of the
system that should require ation to be avoided.
 Desribe the proative goal: its name, its type (per-
sistent, priority, et.), the ativation ondition (e.g.
no fuel or idle), the deativation ondition and the
suessful and failure ondition (when the plan has
been eetive or not).
 Group related goals using the relationships \uses",
\extends", \inludes" or \instantiates".
stonedetect
moveAskHelp
SetMission
Avoid
out of fuel
Operator
::Robot
R1::Robot
<<includes>>
Plan not
to collide
Fig. 1. Robot UER ases
Example
In order to illustrate the tehnique, we an on-
sider a 'robot world' where there are a set of robots
that transport boxes from one plae to another. The
robots need fuel to run and should not be bloked
by stones. Human operators an order the robots to
move one box from an origin to a destination or to
stop a task.
User-Centered Analysis. In this ase, the fol-
lowing ators (Fig. 1) an be identied: another robot
that helps the robot to move a heavy box and a hu-
man operator that sets the mission of the robot (e.g.
move a box from one position to a destination).
After some analysis, the use ase SetMission an
be further rened as shown in Fig. 2. The general
ase SetMission onsists of asking for a mission, that
is aepted or refused. SetMission is a generalisation
of the possible missions: TransportBox and Count-
Boxes. The use ase TransportBox an be inluded by
the ase FindAndTransportBox, where the user just
establishes the number of a partiular box and where
it should be delivered.
SetMission
TransportBox CountBoxes
FindAndTransportBox
<<include>>
Fig. 2. Relationship between use ases
One the ators and use ases have been deter-
mined, they are desribed with textual templates and
MSCs as a graphial notation. For example, Fig. 3
shows the interations of the use ase SetMission.
The operator requests to arry out a mission and the
robot an give two alternative answers, to aept or to
refuse the mission. The messages of the MSC follow
the syntax <speeh-at> (<ontent>).
deny(reason)
agree()
alt
msc SetMission
request (mission, par)
Operator ::Robot
Fig. 3. Senario of the use ase
Environment-Centered Analysis One environ-
ment objet an be identied: the stone, that the
agent detet, ount and an move. The relevant at-
tributes of the stone for the agent are its position, its
number and its weight. The agent needs sensors to
detet that there is a stone and not to ollide with it,
so this is the main reation ase: Detet. When an ob-
stale is deteted, the reation ase the agent should
try not to ollide (reation ase Avoid Collision), that
inludes the detetion of the stone. Several senarios
an be thought for avoiding the ollision: the agent
deides to avoid the obstale, for example going to the
left (reation ase AvoidObstale), deides to stop be-
ause there is no way out (reation ase Stop), deides
to move alone the obstale (reation ase MoveAlone)
or deides to ask for help to other agent to move the
box (reation ase AskHelp
2
.
2
As the reader probably has observed, AskHelp was previously dened
<<include>>
Stop
Detect
MoveAlone AskHelpAvoidObstacle
AvoidCollision
{incomplete}
Fig. 4. Relationship between reation ases
Goal Driven Analysis
Two requirements (goals) have been identied: the
robot should not ollide with the stones or robots and
the robot should not get out of fuel.
The rst requirement (goal ase Plan not to ollide)
is similar to the reation ase AvoidObstale. The
dierene is that we want that the robot try to avoid
an obstale even when it does not reeive any stimuli
from the sensors. For example, if the robot an selet
two alternative paths to transport a box, the seletion
an take into aount the position of the rest of the
robots that ould eventually ollide with it.
The seond requirement (goal ase Avoid out of
fuel) an be further rened as shown in Fig. 5. This
goal ase an be ativated when an indiator of out
of fuel is ativated, being a kind of \internal reation
ase". Another possible senario is that the robot an
go to the fuel station when is idle to avoid being out
of fuel (goal aseGo Station if idle).
Avoid
out of fuel
Indicator
out of fuel
Go Station
if idle
Fig. 5. Relationship between goal ases
After identifying the ases, it is needed to desribe
the dierent senarios and attributes of eah ase. For
example, the goal Go Station if idle is a persistent
goal whose ativation ondition is being low of fuel
and being idle. The deativation ondition an be to
reeive an order while ahieving the goal. The goal is
ahieved if the tank of fuel is lled and fails in other
ase. Another alternative ould be to maintain this
goal ative even if there is an ongoing order but the
fuel station is lose. These two poliies need to be
tested on the environment.
as a use ase; but the roles are interhanged. As a use ase, the robot
reeived the petition and now it is the initiator of the petition.
3. Enhaned CRC ards and internal use
ases
The well known CRC (Class Responsibility Col-
laboration) ards [1℄, [9℄ tehnique provides a method
for organising the relevant lasses for modelling a sys-
tem. This tehnique was initially used [1℄ for teahing
objet fundamentals in a ollaborative environment.
The tehnique onsists of lling ards. Eah ard has
a lass name and two olumns. The left olumn shows
the responsibilities of the lass, that are the tasks the
lass an perform or knowledge it has, and the right
olumn show the lasses that ollaborate to ahieve
these tasks or obtain this knowledge.
This tehnique an be easily modied froman agent
perspetive. A CRC is lled for eah agent role,
desribing its lass. Eah CRC is divided into ve
olumns (table I): goals assigned, plans for ahieving
these goals, knowledge needed to arry out the plans,
ollaborators in these plans, and servies used in the
ollaboration. The bak side of the CRC is used for
annotations or extended desription of the front side.
Internal use ases are also based on RDD [9℄ and
its CRC (Class Responsibility Collaboration) ards.
Taking as input the use ases of the oneptualisation
phase and some initial agents, we an think that eah
agent \uses" other agent(s), and an use these agents
with dierent roles. We look for suh an agent in
our agent-library for reusing, ombining in this way
the top-down and bottom-up approah. The external
use ases oming from the ators of the multiagent
system are deomposed in use ases that are assigned
to agent roles of the system.
4. Conlusions
This artile has proposed several tehniques that
an be used for oneptualising a system from an
agent perspetive.
UER tehnique onsiders three perspetives for
oneiving the system: studying the 'uses' of external
ators, studying the interations with the objets of
the environment, and studying the responsibilities or
goals of the system. This tehnique an be used for
oneiving a partiular agent or the requirements of
a multiagent system.
This artile also proposes an agent-oriented version
of CRC ards that an be used in onjuntion with
the use ases tehniques. These tehniques deal with
nding ollaborations between agents in a multiagent
system and provide a method for agent reusability.
These tehniques have the advantage of be-
ing easily integrated in the urrent objet-oriented
CASE tools using UML and are integrated in
a wider agent-oriented methodology alled MAS-
CommonKADS [3℄.
Agent: Robot1 Class: Robot
Goals Plans Knowledge Collaborator Servie
Maintain fuel Go FS if idle FS Ontology FS Clerk Ask For Fuel
Go FS if Fuel
Indiator On
FS Ontology FS Clerk Ask For Fuel
TABLE I
Example of Agent oriented CRC Card. FS: Fuel-Station
5. Aknowledgements
This researh is funded in part by the Spanish Gov-
ernment under the CICYT projets TIC91-0107 and
TIC94-0139.
The authors would like to thank the students that
are applying the methodology for many suggestions
and omments.
6. Referenes
[1℄ Kent Bek and Ward Cunningham. A labora-
tory for teahing objet-oriented thinking. In
OOPSLA'89 Conferene Proeedings, New Or-
leans, Louisiana, USA, Otober 1989.
[2℄ Ivar Jaobson Grady Booh, James Rumbaugh.
The Unied Modeling Language User Guide. Ad-
dison Wesley, 1998.
[3℄ Carlos A. Iglesias, Meredes Garijo, Jose C.
Gonzalez, and Juan R. Velaso. Analysis
and design of multiagent systems using MAS-
CommonKADS. In AAAI'97 Workshop on Agent
Theories, Arhitetures and Languages, Provi-
dene, RI, July 1997. ATAL. (An extended ver-
sion of this paper has been published in INTEL-
LIGENT AGENTS IV: Agent Theories, Arhite-
tures, and Languages, Springer Verlag, 1998.
[4℄ Carlos A. Iglesias, Meredes Garijo, Jose C.
Gonzalez, and Juan R. Velaso. Analysis
and design of multiagent systems using MAS-
CommonKADS. In M. Wooldridge,M. Singh, and
A. Rao, editors, INTELLIGENT AGENTS IV:
Agent Theories, Arhitetures, and Languages,
volume 1365, pages 313{329. Springer-Verlag,
1998. (A redued version of this paper has been
published in AAAI'97 Workshop on Agent Theo-
ries, Arhitetures and Languages.
[5℄ I. Jaobson, M. Christerson, P. Jonsson, and
G.

Overgaard. Objet-Oriented Software Engi-
neering. A Use Case Driven Approah. ACM
Press, 1992.
[6℄ Roger S. Pressman. Software Engineering: A
Pratitioner's Approah. MGraw-Hill, 4th edi-
tion, 1996.
[7℄ James Rumbaugh. Getting started. using use
ases to apture requirements. JOOP Journal
of Objet Oriented Programming, pages 8{23,
September 1994.
[8℄ James Rumbaugh. OMT: The development
model. JOOP Journal of Objet Oriented Pro-
gramming, pages 8{16, 76, May 1995.
[9℄ R.Wirfs-Brok, B.Wilkerson, and L.Wiener. De-
signing Objet-Oriented Software. Prentie-Hall,
1990.


UER technique: conceptualisation for agent oriented development

Iglesias Fernández, Carlos Ángel

Archivo Digital UPM

http://oa.upm.es/21147/1/INVE_MEM_1999_126675.pdf

UER technique: conceptualisation for agent oriented development

Abstract

Similar works

Full text

Available Versions

Servicio de Coordinación de Bibliotecas de la Universidad Politécnica de Madrid

Archivo Digital UPM