aguilar, j., bessembel, i., cerrada, m., hidrobo, f

ARTICULO

Una Metodologıa para el Modelado de Sistemas de

Ingenierıa Orientado a Agentes

Aguilar, J., Bessembel, I., Cerrada, M., Hidrobo, F., Narciso, F.

Universidad de Los AndesMerida, Venezuela, 5101

{aguilar,ibc,cerradam,hidrobo,fnarciso}@ula.ve

Resumen

En este artıculo se presenta una metodologıa que comprende las fases de conceptualizacion, analisis,diseno, codificacion y pruebas de sistemas de ingenierıa basados en agentes, fundamentada en lametodologıa MultiAgent Systems for INtegrated Automation (MASINA), desarrollada para especi-ficar sistemas multiagentes en ambientes de automatizacion industrial. La metodologıa propuestausa el Lenguaje de Modelado Unificado (UML), ampliamente usado para modelar sistemas de soft-ware, y la Tecnica de Desarrollo de Sistemas de Objetos (TDSO), la cual es una herramienta parala especificacion formal de modelos orientados a objetos. Siguiendo los lineamientos metodologicospara la especificacion de sistemas de ingenierıa, MASINA se inicia con la fase de conceptualizacionque permite identificar aquellos componentes del sistema que seran considerados agentes y proponerla arquitectura del sistema multiagentes correspondiente. Estos agentes y sus interrelaciones sonespecificados e implementados en las fases restantes de la metodologıa propuesta, usando diagramasUML en la fase de analisis y diseno, y plantillas de TDSO en la fase de diseno.

Palabras clave: Sistemas Multiagentes, Metodologıa para Modelado de Sistemas, Modelado deSistemas Multiagentes, Sistemas de Ingenierıa.

1. Introduccion

La tecnologıa de agentes esta siendo ampliamenteutilizada en la academia en los ultimos anos; co-mo consecuencia, la industria se ha interesado enadoptar esta tecnologıa para desarrollar sus pro-pios productos [4, 6, 7, 19, 32, 33, 35, 37, 42, 51].En general, las metodologıas para el desarrollode Sistemas Multi-Agentes (SMA) existentes hansurgido como extensiones tanto de metodologıasorientadas a objetos, como de metodologıas deingenierıa del conocimiento, dada la estrecharelacion entre estas. Ahora bien, no existe unametodologıa dominante en esta area, y las ex-istentes contienen debilidades y desventajas im-portantes que no permiten su utilizacion en am-bientes de diseno complejo.

Atendiendo a la creciente demanda de aplica-ciones basadas en agentes en el area de con-trol y automatizacion [19, 32, 33, 35, 51], la

metodologıa MultiAgent Systems for INtegratedAutomation (MASINA) [8] surge como una prop-uesta metodologica para la especificacion e imple-mentacion de sistemas basados en agentes en am-bientes de automatizacion industrial, la cual hasido usada en [3, 4, 7, 9, 10, 14, 15, 18, 55]. En par-ticular, existen tres caracterısticas fundamentalesen ambientes industriales que requieren especialatencion desde el punto de vista del modelado ori-entado a agentes: por un lado, los requerimientosde tiempo real, que demandan la existencia demodelos de coordinacion y comunicacion que seanprecisos y eficientes; por otro lado, la generacionde conocimiento, que debe ser incorporado en ladinamica de gestion de los agentes. Finalmente,el problema de heterogeneidad, que debe ser in-tegrado en las formas de articulacion comunitariapor los agentes.

Las diferentes contribuciones de MASINA, enrelacion a las metodologıas existentes, son varias.Por un lado, permite plasmar en un modelo de

Inteligencia Artificial, Revista Iberoamericana de IA. Num. 38 (2008), pp. 39-60.ISSN: 1137-3601. c©AEPIA (http://erevista.aepia.org)

40 Inteligencia Artificial Vol. 12, Num. 38, 2008

inteligencia el proceso de inteligencia a nivel indi-vidual (mecanismos de aprendizaje, razonamien-to, etc.) y colectivo (modelado de la inteligenciacolectiva usando ontologıas, etc.). Por otro la-do, permite el uso de tecnicas inteligentes paraespecificar tareas que debe realizar un agente.Ademas, permite caracterizar una gran cantidadde aspectos necesarios en los procesos de coor-dinacion entre agentes: planificacion emergente,formas de resolucion de conflictos, etc., la comu-nicacion directa o indirecta entre agentes, las con-versaciones entre los agentes a traves de actos dehabla (interacciones), entre otras cosas, para locual propone modelos de coordinacion y comu-nicacion precisos. Tambien es posible representaraspectos como el uso modelos de referencia paraespecificar agentes, o la especificacion del nivel deabstraccion al que pertenece un agente (si formaparte de un SMA que tiene multiples capas), oespecificarlo como un SMA, entre otras cosas.

Por otro lado, el Lenguaje de Modelado Unificado(UML, siglas en ingles) es un lenguaje grafico quepermite visualizar, especificar y documentar cadauna de las partes que comprende el diseno de soft-ware. UML permite modelar de manera conceptu-al aspectos tales como: objetos, procesos y reglasde negocio, ası como tambien elementos concretosde sotfware como: clases, bases de datos y com-ponentes reusables [40].

La Tecnica de Desarrollo de Sistemas de Obje-tos (TDSO) se utiliza para la especificacion decomponentes de software, que soporta todos losconstructos de la orientacion por objetos, con lainclusion de una guıa para el desarrollo de laspruebas del sistema modelado [13, 38].

En este artıculo se propone una metodologıaque combina los aspectos considerados enMASINA [8] con las versatilidades ofrecidas porUML, para visualizar graficamente las activi-dades/funciones/comunicaciones de los agentes,y por TDSO, para la definicion del universode clases, y la especificacion de las clases y losmetodos de los componentes de software queimplementan los agentes concebidos, dando lu-gar a una metodologıa formal para modelar sis-temas de ingenierıa orientados a agentes. De estamanera, la principal contribucion de esta nuevametodologıa propuesta es incorporar a las bon-dades de MASINA, elementos de modelado grafi-co y de especificacion de componentes que per-mite definir claramente la arquitectura de agentespara un sistema de software, resaltando la diferen-cia entre componentes y agentes, actividades, ser-

vicios y tareas, aspectos que no estan claramentediferenciados en las metodologıas existentes. Deesta manera, la metodologıa propuesta en estetrabajo permite especificar sistemas multiagentesde forma precisa, facilitando el proceso de im-plantacion en ambientes reales complejos.

Esta metodologıa ha sido utilizada previamenteen los proyectos industriales financiados porPDVSA (Industria Petrolera Venezolana): “De-sarrollo de la Ingenierıa de Diseno de la Arqui-tectura de Software Sistemica que permita imple-mentar las funcionalidades y tecnologıas identifi-cadas en las mesas corporativas de Arquitecturay de Aplicaciones sobre la plataforma Net-DAS2.0. de PDVSA-Sur”, y “Desarrollo del Medio deGestion de Servicios de la Arquitectura de Apli-caciones sobre Plataforma Net-Das 2.0”; y en eldiseno de un sistema de control y supervisionpropuesto en [45].

2. Marco Referencial

La mayorıa de las metodologıas propuestas parael desarrollo de sistemas basados en agentes hansurgido como extensiones y/o modificaciones deotras metodologıas. En este sentido, se puedendistinguir tres grandes grupos, el primero basadoen metodologıas orientadas a objetos [17, 21, 22,29, 34, 48, 50, 52]; el segundo en metodologıasprovenientes de ingenierıa del conocimiento [26,29, 30, 31, 47]; y el tercero, en el paradigma deagentes [12, 16, 20, 23, 41, 43, 53, 54]. En esta sec-cion describiremos algunos aspectos relevantes deestas metodologıas, en [27, 28] se presentan anali-sis exhaustivos de diferentes metodologias para eldesarrollo de sistemas basados en agentes.

Entre las metodologıas para especificacion deagentes basadas en orientacion a objetos se desta-can las propuestas de Kinny [34], Burmeister[17] y MASE propuesta por Wood [52]. Kinnydefine una metodologıa para SMA que amplıaOMT (Object Modelling Technique); por su la-do, Burmesiter describe una metodologıa paradisenar agentes, extendiendo metodologıas orien-tadas a objetos, en la cual se distinguen tres mod-elos: modelo del agente, modelo de organizacion ymodelo de cooperacion. Sin embargo, en su mode-lo de cooperacion, las interacciones son demasiadosimples y no permiten considerar aspectos com-plejos de coordinacion. Wood parte de una especi-ficacion inicial del sistema y produce un conjun-to de documentos de diseno formal en un estilo

Inteligencia Artificial Vol. 12, Num. 38, 2008 41

basado en graficos. Sin embargo, ninguna de es-tas metodologıas toma en consideracion el uso demodelos de analisis genericos y todas tratan alagente como un objeto completo, lo que consti-tuye una vision erronea puesto que los agentesrepresentan un nivel de abstraccion mas elevadoque los objetos.

Con respeto a las metodologıas surgidas dela ingenierıa del conocimiento, existen dosmetodologıas relevantes que comparten sus basesen la metodologıa CommonKADS [26, 29, 30,47], conocidas como CoMoMAS [26] y MAS-CommonKADS [31], siendo esta ultima la quemejor cubre los elementos de especificacion deun SMA. La metodologıa MAS-CommonKADS esuna extension de la metodologıa CommonKADSpara modelar SMA, agregando aspectos de lasmetodologıas orientadas a objetos como OMT,Object Oriented Software Engineering (OOSE) yResponsibility Driving Design (RDD). Consisteen seis fases, de las cuales se derivan siete mode-los que integrados generan la solucion basada enagentes al problema planteado. En sı, estos mod-elos representan a los componentes (agentes) delsistema, sus interrelaciones, tareas, entre otros as-pectos. Sin embargo, esto no significa que este ex-enta de debilidades, entre las que se pueden men-cionar: la dificultad para especificar un agentecomo un SMA, la falta de manejo de esquemasdinamicos de comunicacion, y la ausencia de mod-elos de aprendizaje y de coordinacion.

Las metodologıas surgidas de la propia teorıa deagentes se fundamentan en una estructuracionsocial, donde existen individuos (agentes), gru-pos y organizaciones. Entre estas metodologıas sepueden senalar a Cassiopeia [20], Gaia [53, 54],HLIM [23], Prometheus [43], SODA [41] y Tropos[16]. El problema comun en estas metodologıas esque la fase de analisis y/o especificacion se basa enel paradigma de agentes, y no se toma en cuentaque un modelo de analisis general puede dar co-mo resultado que un esquema multiagentes no seael mas apropiado, esto es, algunos componentesdel sistema pudieran no ser necesariamente con-cebidos como agentes; ademas, el principal ele-mento de diseno es el papel social del agente y nosus componentes.

En [27, 28] se presentan analisis y comparacionesentre metodologıas existentes para el desarrol-lo de sistemas de software orientados a agentes,donde se resalta la necesidad de disponer demetodologıas que resulten en la definicion demodelos de interaccion y cooperacion que no sean

abstractos y que capturen las relaciones y depen-dencias entre agentes, ası como sus roles dentrodel sistema.

El paradigma de agentes esta siendo ampliamenteusado como enfoque de modelado de sistemasde control y desarrollos industriales, debido a lanaturaleza descentralizada de los problemas dedichas areas [33] y la complejidad de los ambi-entes de negocio y manufactura [35]. Por tan-to, con el fin de integrar las multiples perspec-tivas de los ambientes industriales y sus intere-ses (control, supervision, mantenimiento, planifi-cacion, informatica), y ası lograr el alcance de unobjetivo global, diversos trabajos han sido orien-tados a la proposicion de arquitecturas basadasen SMA [37, 42, 51]. Estos trabajos prestan masatencion a los aspectos de comunicacion con vis-tas generales a la fase de conceptualizacion.

Ası pues, en vista de la potencialidad del uso deSMA en ambientes industriales, surge MASINA[8] a partir de los trabajos realizados en [4, 5,6, 15, 32] como una metodologıa para la especi-ficacion de SMA en dichos ambientes. MASINAes una extension del modelo orientado a objetosMAS-CommonKADS, y se basa en el mismo ci-clo de desarrollo, con modificaciones que permitenincorporar comportamientos inteligentes (apren-dizaje, razonamiento, etc.), especificar los aspec-tos de comunicacion, coordinacion, integracion,y un agente como un SMA. Particularmente,la posibilidad de especificar un agente como unSMA, analogamente al concepto de holarquıa ensistemas holonicos [25], es una posibilidad quepermite la metodologıa en los casos que sea re-querido por la complejidad del agente a disenar,ası como tambien, usar modelos de referencia enla especificacion de un agente.

A continuacion se presenta la metodologıaMASINA [8] y la tecnica TDSO. Se omite la de-scripcion de UML por ser una herramienta am-pliamente conocida [1, 24, 40, 44, 46, 49].

2.1. MASINA

La metodologıa MASINA [8] es una extension deMAS-CommonKADS, la cual consta de las fas-es de conceptualizacion, analisis, diseno, codifi-cacion y pruebas, integracion, y operacion y man-tenimiento.

En la fase de conceptualizacion de MASINA,a diferencia de lo propuesto en MAS-


CommonKADS, no solo se definen los serviciosrequeridos del sistema y quienes lo requieren,sino que se hace una primera identificacion deaquellos componentes del sistema que puedenser considerados agentes y se propone unaarquitectura preliminar del SMA. En MAS-CommonKADS, esta arquitectura es concebidaen la fase de diseno. MASINA sigue haciendouso de los diagramas de casos de uso de UML enesta fase de conceptualizacion.

En la fase de analisis de MASINA se reducena cinco los seis modelos propuestos en MAS-CommonKADS, los cuales se consideran sufi-cientes para describir las caracterısticas basicasde los SMA (ver figura 1). Particularmente,MASINA hace uso de los modelos de agente,tareas, comunicacion, coordinacion y sustituye elmodelo de experiencia de MAS-CommonKADSpor el modelo de inteligencia.

×î��3îJ��

ax��3a¦�x½aÔ

×î��3îJ��

Ô¦�x��

×î��3îJ��

½î×ëxa½Ô½aîx

×î��3îJ��

�Ô��Ô�

×î��3îJ��

½îî��axÔ½aîx

�Ô0îxÔJGJÔ^��x��

��Ô3a0Ô

��Ô3a0Ô

ax��Ô½�ëÔJ½îx

î��î�JÔ¦�x��

Figura 1: Modelos de MASINA para analisis

En el modelo de agente, MASINA especifica, aligual que MAS-CommonKADS, las caracterısti-cas de un agente tales como habilidades, y ser-vicios, entre otras. Ademas, a este modelo se leagregan dos atributos: componentes del agenteque permite indicar si el mismo es un SMA (per-mite representar niveles de abstraccion o jerar-quıas en el diseno del SMA), y marco de referen-cia para indicar si la arquitectura del agente bajodiseno esta basada en un modelo de referencia da-do.

En el modelo de tareas, MASINA agrega nuevosatributos, uno para especificar las tareas que re-quieren el uso de tecnicas inteligentes, y otro paradescribir el macro-procedimiento (sub-tareas)que se debe seguir para la ejecucion de dichatarea. Ası, los agentes pueden usar tecnicas in-teligentes (Redes Neuronales Artificiales, Algorit-

mos Geneticos, etc.) en funcion del tipo de tareasque realizan (sean o no ellos inteligentes).

En el modelo de experiencia de MAS-CommonKADS solo se especifica lo concerniente a la expe-riencia que se va acumulando en un agente, perono se consideran otros elementos que permitenal agente tener un comportamiento inteligente.MASINA, en su modelo de inteligencia, describetodos los aspectos necesarios para incorporar lanocion de inteligencia a un agente.

El modelo de inteligencia propuesto es presen-tado en la figura 2, con sus atributos, las rela-ciones entre ellos, y su interrelacion con los demasmodelos de MASINA. Se propone un esquemaque integra conceptos como experiencia, repre-sentacion de conocimiento (conocimiento de do-minio, conocimiento estrategico, conocimiento detareas), mecanismo de aprendizaje, y mecanismode razonamiento. Este modelo se activa a travesdel modelo de tareas, por tareas especificas queconlleven a procesos de razonamiento, aprendiza-je, etc.

En MASINA, el modelo de coordinacion permiteespecificar las conversaciones que se dan entre losagentes. A diferencia de MAS-Common KADS, elmodelo de coordinacion de MASINA se centra enla definicion de las conversaciones que permitenuna comunicacion coordinada entre los agentes,y no en los actos de habla especıficamente in-volucrados, los cuales pasan a ser detallados en elmodelo de comunicacion de MASINA. Las inter-acciones (actos de habla) presentes en una con-versacion dada entre agentes, se representan, anivel grafico, a traves de un diagrama de secuen-cia de UML (ver figura 3). Estos actos de hablason detallados en el modelo de comunicacion.

El modelo de coordinacion de MASINA permiteuna descripcion mas detallada de cada conver-sacion, tal y como se muestra en la figura 4. Eneste modelo se especifica el esquema de coordi-nacion, la planificacion, el mecanismo de comu-nicacion directa o de comunicacion indirecta, elmetalenguaje y la ontologıa.

MAS-Common KADS no describe el modelode comunicacion detalladamente, sino que losupone derivado del modelo de coordinacion. EnMASINA, el modelo de comunicacion consideralas interacciones de una manera mas amplia ypropone un modelo de comunicacion que describelos actos de habla involucrados en las conversa-ciones entre los agentes del SMA, detalladas en elmodelo de coordinacion.


î��3Jax�¦½Ô�ë��JÔa03G�

^¦�u��a�¦£3Ô3�º3ºaÑ¦è½J¦½ëÔ3�º3ºaÑ¦è½�J½ÿDJ�3è½x[��Ñax3Ô¦r��Ja�3½Ô�½��x�Jº3�a J·[�Jº�½Ô�½3��JÔa03G�î��3Jax�¦½Ô�½3�º[3ÿa03�a J

Î¦J¦�a�a�Jº¦åxº�3º�üa�¦

�3ÿ¦�½Ô�ÿ½�¦J¦�a�a�Jº¦ëü�Jº�½*[�½ÿ¦½��¦Ô[��A�¦��x¦½*[�½ÿ¦½ü�J�� X�3Ô¦½Ô��¦Joa3uaÿaÔ3Ô

î��3Jax�¦ Ô��30¦J3�a�Jº¦

·[�Jº�½Ô�½aJo¦��3�a J·[�Jº�½Ô�½3ÿa��Jº3�a J�a�¦½Ô�½aJo��J�a3�3ÿ3�a J [ºaÿaÔ3Ô�3��3�´uG�ºaÑ¦£åÑ3ÿ[3�a Jråxº�3º�üa3½Ô�½uËx*[�Ô3½Ô�x¦ÿ[�a¦J�x

åâ��a�J�a3

��x�Jº3�a J�a�¦X�3Ô¦½Ô�½�¦Joa3uaÿaÔ3Ôåx*[��3½Ô�A�¦��x3�a�Jº¦½£�¦º¦�½Ô�½aJo��J�a3r

Î¦J¦�a�a�Jº¦Ô�½ù¦�aJa¦

ëº�au[º¦ù�x��a��a J�a�¦�3ÿ¦�½�¦�½¦�axa J�3ÿ¦�½3�º[3ÿ�3ÿ¦��x½î3â�½'½îaJ�

Î¦J¦�a�a�Jº¦ Ô�½�3��3x

^¦�u��½Ô�½º3��3ëü�Jº�½*[�½ÿ3½��3ÿa03

A�¦uÿ��3åx��Doa�¦£ë�ua�Jº�r

>¦ÿa�aº3Ux3

Ux3Ux3

Ux3

Ux3

Ux3

��x[�ÿÑ�

î¦Ô�ÿ¦ Ô�½ëü�Jº�x

î¦Ô�ÿ¦ Ô�Î¦¦�ÔaJ3�a J

î¦Ô�ÿ¦ Ô�½�3��3

ù��axa J º¦�3Ô3

ù��aÔ�½��º¦Ô¦ë½[x3�

�a�J�3x¦�a3Ô¦

Figura 2: Modelo de inteligencia de MASINA

En la fase de diseno de MASINA se obtienen lossiguientes modelos como paso previo a la imple-mentacion del SMA:

Diseno del SMA: Se toman en consideracionlos agentes resultantes de los modelos gen-erados en la fase de analisis para generarla arquitectura final del SMA. Se plasmaranlos niveles de abstraccion, es decir, la visionholıstica del SMA.

Diseno de red: Se describen los aspectos rel-evantes a la plataforma del SMA como lasbases de conocimiento, la arquitectura dered, etc.

Diseno de la plataforma: Se determina laplataforma de desarrollo del SMA, es decir,se escogen las tecnologıas (hardware y soft-ware) para implantar la plataforma.

En la fase de codificacion y pruebas de MASINAse codifica y prueba cada agente utilizando lasherramientas escogidas para tal fin. Las dos ten-dencias principales son el uso de lenguajes deproposito general o de lenguajes orientados aagentes. Cada agente se prueba para asegurar queno tenga fallas, es decir que funcionen de acuerdocon las especificaciones definidas para el SMA enlas fases de conceptualizacion y analisis.

En la fase de integracion se realiza el acoplamien-to entre los agentes del SMA y de este con laplataforma real donde funcionara.

La fase de operacion y mantenimiento consiste enel funcionamiento del sistema propiamente dicho,

y en la cual se realizan tareas de actualizacion(mantenimiento) de los componentes del sistemapara adaptarlos a la evolucion del entorno o anuevos requisitos.

Figura 3: Actos de habla en MASINA

La metodologıa MASINA ha sido usada para es-pecificar modelos de referencia basados en SMA[3, 4, 7, 9, 10, 11, 18, 14, 19, 55] que permiten im-plementar tareas propias de ambientes distribui-dos. En particular, el desarrollo de modelos dereferencia basado en sistemas multi-agentes quepermitan implementar tareas de automatizaciony control de procesos, ha sido de especial interes.


×î��3Ja x3�¦¦½xÔëa�Ô0ë

G^u3��Ô£¦ aºî3Ñ�Ô½èÔÿ¦º�axaÿ�a�Ô£¦-ºD½3x3[ÔëÔx¦rD½¦�3xÔJÔ3ë�¦º�3ëº�aî¦�3ºî3½ºaxaÿ�a�Ô£¦rD¦½º¦JÔîÔ0ëº�D aëÔ[Ô�a�Ô0ëDa½aº3 º�aî¦ºÿ½3x3[ÔëÔx¦r

·3�aëÔîJ¦ x3º�¦J�ëÔ�a�Ô0ëÎëxÔ½3��a

×î�½a�3ÑÔaºx3ºa��a Ôåa�Ô¦ë x3×î��J� ¦î×î�½a�3ÑÔaºx3ºa��a Ôåa�Ô0ëº*J^½a ºx3º½3îÿ�3î�a

·3�a aëÑ�aÑ3

A¦J^½3·3xÔ¦º�D½¦�¦�¦ ¦ºx3º½3x-ºJ3J¦½Ôar

D aëÔ[Ô�a�Ô0ë

èÔÿ¦º�×J3½Ñ3ë�3-ºD½3x3[ÔëÔxa-�3ë�½a ÔåaxarèX�ëÔ�a

·3�aëÔîJ¦ x3º�¦J�ëÔ�a�Ô0ë�Ô½3��a

oÔ^ Ô¦�3�a

Gë�¦ ¦Ñ�a

A¦J^½3�3ÿ½3î3ë�a�Ô0ë�Ñ3ë�3îº��3º aº�¦ë¦�3ë´¦�a^� a½Ô¦º�� aî3îºË�3 a�Ô¦ë3îº3ë�½3º� aî3îr�3î�½Ôÿ�Ô0ë

×î�½a�3ÑÔa x3º½3î¦ ��Ô0ë�3º�¦ë[ Ô��¦î

èÔÿ¦èX�ëÔ�a

×î��J� ¦â�3îÿ�3î�a

�Ñ3ë�3îºù �aÿa�Ôxax3îèÔÿ¦ºx3º½3îÿ�3î�a�aÿa�Ôxax3îºâ èa½3aî

·¦x3 ¦ x3º�Ñ3ë�3î ·¦x3 ¦ x3ºèa½3a

×î�½a�3ÑÔa x3·3J¦½Ôa�¦Jÿa½�Ôxa

*îa

*îa

*îa

D�3x3º�îa½

D�3x3º�îa½

�3��Ô3½3

�3��Ô3½3

oaîax¦º3ë

�3î�½Ô^3�aÿa�Ôxax3î

�3�Ôx3

Figura 4: Modelo de coordinacion de MASINA

2.2. Tecnica de Desarrollo de Ob-jetos

Existen diversas formas tradicionales de expre-sar la resolucion programada de problemas ante-riores al uso de la orientacion por objetos. En-tre ellas se tienen el refinamiento paso a paso,el diseno modular y estructurado, los algoritmosestructurados, el metodo deductivo, entre otros,que pueden ser utilizados independientemente un-os de otros, aunque ellos normalmente se usan enconjunto, para analizar, disenar y documentar sis-temas programados.

Con el advenimiento de la orientacion por obje-tos aparece la metodologıa OMT (Object- orient-ed modeling technique) [39], que describe todo elproceso de modelado de clases de objetos en elmodelo de objetos, y que ademas incluye el so-porte de las relaciones dinamicas y funcionalesentre las clases a traves de los modelos dinamicoy funcional. La Tecnica de Desarrollo de Sistemasde Objetos (TDSO) esta basada en el metodo de-ductivo y en la metodologıa OMT [13]. Ademas,OMT fue utilizada como base para el desarrollode UML [40]. Del primero contiene todas las fases,incluyendo ademas las de especificacion formal.De la segunda se toman algunos de los diagramasque fueron transformados y adaptados para TD-SO, que soportan todos los constructos de la ori-entacion por objetos. La extension de tales meto-dos se hace con la inclusion de una guıa para eldesarrollo de las pruebas de tales sistemas, uti-lizando el paradigma de la programacion orienta-da por objetos.

TDSO permite:

Definir el universo de clases y tipos de datosabstractos (TDA).

Definir formalmente cada clase en terminosde sus atributos, la especificacion sintacticade sus metodos y/o operaciones, la especi-ficacion semantica que presenta el escenariode como se deben utilizar los metodos u op-eraciones ası como su comportamiento, y lasdeclaraciones de las instancias de la clase,TDAs, atributos y/o variables que seran uti-lizadas en el escenario de pruebas de la es-pecificacion semantica.

Especificar formalmente cada metodo u op-eracion de una clase.

Una de las principales ventajas de TDSO es quepermite documentar las clases y TDAs, los atrib-utos y metodos de cada clase, las declaracionesde las instancias de una clase y/o TDAs, lasvariables y los casos de prueba de cada metodo,constituyendo una herramienta apropiada para eldiseno de software.

3. Metodologıa para el Mod-elado de Sistemas Orienta-do a Agentes

MASINA ha sido usada para el desarrollo de mod-elos de referencia basados en SMA en ambientesde automatizacion y control de procesos, lo cualha permitido su depuracion y validacion, llegan-do a desarrollarse una metodologıa general para


ser usada en el modelado de sistemas de inge-nierıa orientado a agentes. Como producto de es-ta depuracion y validacion, se han incorporadonuevas herramientas de modelado UML version2.0 [44], en las fases de conceptualizacion, anali-sis y diseno, se han desarrollado plantillas biendetalladas para especificar cada modelo en la fasede analisis, se ha incorporado el uso de las plan-tillas de TDSO en la fase de diseno y se han de-sarrollado plantillas para el diseno de los casos depruebas.

En las siguientes secciones se describen detal-ladamente las fases de conceptualizacion, analisis,diseno y codificacion y pruebas de la metodologıapara el modelado de sistemas orientado a agentespropuesta en este trabajo, usando el formato pre-sentado en [36], el cual permite para cada fase:

Definir el(los) objetivo(s).

Definir el producto principal.

Describir el flujo de trabajo mediante un di-agrama de actividades.

Describir los pasos, actividades, tecnicas ynotaciones y productos.

3.1. Fase 1: Conceptualizacion

La fase de conceptualizacion consiste en la extrac-cion y adquisicion del conocimiento para obteneruna primera descripcion del SMA. Se identificanlos elementos que componen el SMA, los proce-sos que realizan estos componentes del SMA y lasrelaciones que se establecen para cumplir los ob-jetivos globales. La tabla 1 muestra la plantillausada para describir los casos de uso.

Tabla 1: Plantilla de descripcion de casos de uso

Caso de uso Nombre del caso de usoDescripcion Descripcion detallada del

caso de usoPre-condicion Condicion necesaria para

que exista el caso de usoActores Componentes del sistema

que participan en el casode uso

Condicion de fracaso Elementos/eventos queimpiden la culminacionexitosa del caso de uso

Condicion de exito Elementos/eventos queindican el cumplimientoexitoso del caso de uso

3.1.1. Objetivo

Identificar cada componente del sistema, su con-formacion, las funcionalidades que provee, las ac-tividades que realiza y las interacciones que seproducen entre ellos.

3.1.2. Producto principal

El producto de esta fase es un documento deconceptualizacion, el cual contiene el analisis delproblema, la descripcion de los componentes delsistema, la especificacion de los servicios y de lasactividades para prestar los servicios ofrecidos porcada componente del sistema considerado comoun agente y la descripcion general de las rela-ciones entre los componentes del sistema.

3.1.3. Flujo de trabajo

En la figura 5 se presenta el diagrama de activi-dades que muestra los pasos que se desarrollan enesta fase. La tabla 2 contiene la descripcion de-tallada de esas actividades, las tecnicas a utilizary los productos obtenidos en cada paso.

Figura 5: Flujo de trabajo en Conceptualizacion

3.2. Fase 2: Analisis

En esta fase se lleva a cabo la especificacion de-tallada de todos los elementos propuestos en lafase de conceptualizacion, ası como la especifi-cacion de las comunicaciones y coordinacion en-tre el SMA. Esta fase se conoce, en muchasmetodologıas, como analisis de requisitos, ya quesu objetivo o producto es la lista de requisitosformales para la construccion del SMA, y per-mite construir lo que se denomina el modelo deespecificacion.


Tabla 2: Especificacion del flujo de trabajo de la fase de ConceptualizacionPasos Actividades Tecnicas y Notaciones ProductosAnalisis del proble-ma

.- Definir el problema

.- Caracterizar el problema (descrip-cion detallada)

.- Revision bibliografica

.- Levantamiento de infor-macion.- Entrevistas.- Reuniones

.- Documento de analisis delproblema

Descripcion decomponentes

.- Describir los componentes del SMA(identificacion del componente y su rolen el SMA)

.- Modelado de casos de usoen UML.- Uso de plantillas para ladescripcion de casos de uso(ver tabla 1)

.- Diagramas de casos de uso

.- Descripcion de los casosde uso

Descripcion de ser-vicios

.- Definir los servicios por cada compo-nente del SMA y las actividades paraprestar dichos servicios

.- Modelado de diagramasde actividades en UML

.- Diagramas de actividades

Descripcion derelaciones entrecomponentes

.- Describir las relaciones entre loscomponentes del SMA, determinadapor los servicios que requiere un com-ponente y los servicios que este presta

.- Modelado de diagramasde secuencia en UML

.- Diagramas de secuencia

Tabla 3: Especificacion del flujo de trabajo de la fase de AnalisisPasos Actividades Tecnicas y Notaciones ProductosModelado deagentes

.- Especificar las caracterısticas gen-erales de cada uno de los agentes delSMA

.- Revision del diagramade actividades para cadaagente.- Uso de plantillas parala especificacion del agente(ver tabla 4)

.- Tabla de especificacion deagentes

Modelado de tar-eas

.- Definir las tareas necesarias para elcumplimiento del servicio ofrecido.- Especificar las tareas definidas

.- Revision de los serviciosdefinidos para el agente.- Uso de plantillas para laespecificacion de tareas delagente (ver tabla 6)

.- Tabla de relacionesServicios-Tareas..- Tabla de especificacion detareas

Modelado de in-telegencia

.- Identificar y analizar los compor-tamientos reactivos e inteligentes decada agente.- Determinar el conocimiento es-trategico, del dominio y de tareas.- Definir los mecanismos para la rep-resentacion y acumulacion de experi-encias.- Definir los mecanismos de razon-amiento.- Definir los mecanismos de apren-dizaje y adaptacion.

.- Revision de las carac-terısticas generales delagente

.- Revision de las tar-eas definidas en el modelode tareas.- Entrevistas con los exper-tos.- Uso de tecnicas deIngenierıa de Conocimiento

.- Diagrama del modelo deintelegencia (ver figura 2)

Modelado de coor-dinacion

.- Definir las conversaciones necesariasentre agentes.- Identificar los actos de habla.- Especificar las conversacionesdefinidas.- Especificar los mecanismos decoordinacion y de comunicacion

.- Revision de los objetivosy servicios definidos en elmodelo de agente.- Revision de las tareasdefinidas en el modelo detareas.- Diagramas de secuenciaen UML (ver figura 3).- Uso de plantillas para laespecificacion de las conver-saciones (ver tabla 7)

.- Modelado de diagramasde secuencia para cada con-versacion.- Tablas de especificacionde conversaciones.- Diagrama de Coordi-nacion (ver figura 4)

Modelado de la co-municacion

.- Especificar los actos de habla de lasconversaciones

.- Revision de los actos dehabla definidos.- Uso de plantillas para laespecificacion de los actosde habla (ver tabla 8)

.- Tablas de especificacionde actos de habla


Tabla 4: Plantilla del Modelo de AgenteAgenteNombre Nombre unico para el agentePosicion Ubicacion del agente dentro del sistema multiagenteComponentes Agentes que lo componen (si es un SMA)Marco de referencia Marco de referencia para el modelado de agentesDescripcion del agente Lo que hace el agenteObjetivos del AgenteNombre Nombre del objetivoDescripcion Detalles del objetivoParametro de entrada Parametros necesarios para el cumplimiento del objetivoParametro de salida Parametros que se esperan obtener una vez cumplido el objetivoCondicion de activacion Condiciones que activan las tareas asociadas al cumplimiento del objetivoCondicion de finalizacion Condiciones que indican la terminacion de las tareas asociadas al cumplimiento

del objetivoCondicion de exito Condiciones que indican el cumplimiento del objetivoCondicion de fracaso Condiciones que indican el no cumplimiento del objetivoOntologıa Descripcion de la ontologıaServicios del AgenteNombre Nombre del servicio ofrecido por el agenteDescripcion del Servicio Detalles del servicioTipo de Servicio Clasificacion (Interno, Externo o ambos: servicio dual)Parametros de entrada Parametros necesarios para el cumplimiento del servicioParametros de salida Parametros obtenidos al finalizar el servicioPropiedades del ServicioNombre Valor DescripcionCalidad Valor de la calidad del servicioAuditable Valor del nivel de auditabilidad del servicioGarantıa Valor del nivel de garantıa de recibir la solicitud del servicioCapacidad Valor de la capacidad del agente de cumplir con el servicio (capacidad de re-

spuesta)Confiabilidad Valor de confiabilidad del servicioCapacidad del AgenteHabilidades del agente Descripcion de las habilidades generales del agenteRepresentacion del Conocimiento Lenguaje de representacion del conocimientoLenguaje de Comunicacion Lenguaje de comunicacion que usa el agenteRestriccion del AgenteNormas Descripcion de las normas del agente para el cumplimiento del servicioPreferencias Preferencias del agente en el momento de atender las solicitudes de servicioPermisos Accesos a informacion permitidos para el agente para el cumplimiento de su

objetivo

3.2.1. Objetivo de la fase

Especificar los modelos de agente, tareas, in-teligencia, coordinacion y comunicacion del sis-tema multiagente propuesto.


El producto principal de esta fase es un docu-mento de analisis contentivo de los modelos deagentes, tareas, inteligencia, coordinacion y co-municacion del SMA.


En la figura 6 se presenta el diagrama de activi-dades que muestra los pasos que se desarrollan enesta fase. De la misma manera que se presento enla fase de conceptualizacion, la tabla 3 contienela descripcion detallada de las actividades para lafase de analisis, las tecnicas a utilizar y los pro-ductos obtenidos en cada paso.

La tabla 4 muestra la plantilla que se usa pararealizar la descripcion del modelo de agente. Enesta descripcion se incluyen: Objetivos, Servicios,Capacidad y Restricciones del agente.

La tabla 5 muestra la plantilla que se usa paradescribir la relacion entre los servicios que pres-ta el agente y las tareas que debe ejecutar paracumplir con esos servicios. Para cada tarea del


agente, se construye una plantilla que sirve paraespecificar la tarea (ver tabla 6).

Figura 6: Flujo de trabajo de la fase de Analisis

Tabla 5: Relacion Servicios-Tareas del AgenteServicios TareasNombre Servicio 1 Nombre Tarea S1 − T1

...NombreTarea S1 − Tn

Nombre Servicio L Nombre Tarea SL − T1

...NombreTarea SL − Tk

Tabla 6: Plantilla del Modelo de Tareas

Nombre de la TareaNombre Nombre de la tareaObjetivo Objetivo de la tareaDescripcion Detalles del objetivo de la tareaServiciosasociados

Servicios asociado al objetivo

Precondicion Condiciones necesarias para la activacionSub-tareas Macro-procedimiento para hacer la tareaIngredientes-Nombre de la TareaNombre In-grediente 1

Descripcion del parametro 1

......

Nombre In-grediente n

Descripcion del parametro n

Por otro lado, es necesario especificar las interac-ciones que se dan en el SMA. Para ello se utilizanlos modelos de coordinacion y comunicacion, endonde se describen, entre otras cosas, las conver-saciones y los actos de habla. Las tablas 7 y 8muestran las plantillas para la especificacion delas conversaciones y de los actos de habla, respec-tivamente.

Tabla 7: Plantilla del Modelo de ConversacionNombre de la conversacionObjetivo Objetivo de la conversacionAgentes par-ticipantes

Agentes que participan en la con-versacion

Iniciador Agente que inicia la conversacionActos de habla Actos de habla que se dan en la

conversacionPrecondicion Condiciones necesarias para que se

inicie la conversacionCondicion determinacion

Condiciones que se cumplen paradar por finalizada la conversacion

Descripcion Descripcion detallada de la conver-sacion

Tabla 8: Plantilla del Modelo de ComunicacionNombre del Acto de HablaNombre Nombre del acto de hablaTipo Indica la caracterıstica de la so-

licitud (requerimiento de infor-macion, de procesamiento, entreotros)

Objetivo Objetivo de la interaccionAgentes partici-pantes

Agente que participan en el actode habla (emisor-receptor)

Iniciador Agente inicia la interaccionDatos intercam-biados

Indica cuales son los datos que seintercambian

Precondicion Especifica las condiciones que ini-cian el acto de habla

Condicion determinacion

Especifica las condiciones que de-terminan la finalizacion de la in-teraccion

Conversaciones Indica en cuales conversacionesesta presente el acto de habla de-scrito

Descripcion Detalla el fın del acto de habla es-pecıfico

3.3. Fase 3: Diseno

En esta fase se obtiene el modelo de diseno bajoel paradigma de SMA, a partir de los modelos delSMA generados en la fase de analisis.

3.3.1. Objetivo de la fase

Elaborar un diseno detallado de los componentesy de la plataforma del SMA.


El producto principal de esta fase consiste en undocumento de diseno que describe la estructuradel SMA, la especificacion detallada de los com-ponentes de dicha estructura y de la plataforma


del SMA.


En la figura 7 se presenta el diagrama de activi-dades que muestra los pasos que se desarrollan enesta fase; estos pasos se detallan en la tabla 9.

Figura 7: Flujo de trabajo de la fase de Diseno

Ademas, en la fase de diseno se generan las clasesrequeridas para la implantacion del SMA. Pararealizar la espcificacion del sistemas se usa TDSO.En este caso se genera el universo de clases delsistema, especificado mediante la plantilla que semuestra en la tabla 10.

Para cada una de las clases descritas en el uni-verso de clases se realiza la especificacion formal,para lo cual se usa la plantilla que se muestra enla tabla 11. Ası mismo, cada uno de los metodosque componen la clase son especificados mediantela plantilla mostrada en la tabla 12.

3.4. Fase 4: Codificacion y Pruebas

Esta fase consiste en la implementacion del SMA,para lo cual se escribe el codigo de los diferentesagentes que lo conforman y en la realizacion delas pruebas de software, lo que hara posible queel SMA implementado cumpla con los requisitosestablecidos en la fase de analisis y correspondaal diseno del SMA producto de la fase anterior.

3.4.1. Objetivos de la fase

Esta fase contempla los siguientes objetivos:

Implementar el SMA a partir del modelo dediseno generado en la fase de diseno.

Disenar y ejecutar el plan de pruebas a obje-to de verificar que el comportamiento exter-no del SMA satisface los requisitos estableci-dos en la fase de analisis.


El producto principal de esta fase consiste en unsistema de ingenierıa orientado a agentes.


En la figura 8 se presenta el diagrama de activi-dades que muestra los pasos que se desarrollan enesta fase; estos pasos se detallan en la tabla 13.

Figura 8: Flujo de trabajo de la fase de Codifi-cacion y Pruebas

4. Caso de Estudio

En aplicaciones de control y automatizacion, lavisualizacion o despliegue de datos referentes alos procesos es de vital importancia para la ob-tencion de informacion que permita una toma dedecisiones adecuada. Ahora bien, el poder usarAgentes de Visualizacion que se puedan adaptardinamicamente al perfil de los usuarios, seria deun gran aporte en los procesos de automatizacion,para darle mayor versatilidad a los mismos (en [2]hay una comparacion entre un sistema de autom-atizacion convencional y otro basado en agentes).


Tabla 9: Especificacion del flujo de trabajo de la fase de DisenoPasos Actividades Tecnicas y Notaciones ProductosModelado dediseno del SMA

.- Definir las clases que representan alos agentes.- Definir la interaccion entre agentes.- Definir los componentes del SMA.- Distribuir los componentes en unaarquitectura.- Especificar detalladamente cadacomponente

.-Revision del(los) diagra-ma(s) caso(s) de uso paracada agente.- Revision de los modelospara cada agente.- Modelado de clases con eldiagramas de clase en UML.- Estilos arquitectonicos.- Modelado de compo-nentes con el diagramas decomponentes en UML.- Uso de plantillas de TD-SO para la especificacion de-tallada de los agentes (vertablas 10, 11 y 12)

.- Diagrama de clases

.- Diagrama de compo-nentes.- Descripcion de la arqui-tectura del SMA.- Tabla de definicion deluniverso de clases y TDAsde cada agente.- Tabla de definicion formalde la clase que representa acada agente.- Tablas de especificacionformal de los metodos de ca-da clase

Modelado dediseno de laplataforma delSMA

.- Describir los elementos de laplataforma.- Describir como se integran los ele-mentos.- Realizar el modelo de despliegue

.- Uso de diagramas de de-spliegue

.- Diagrama de despliegue

Tabla 10: Definicion del universo de clases <nombreSistema><fecha> <Version #>

Universo de clases y/o TDAs <nombreSistema>{Comentario sobre el universo de clases y/o TDAs}

# Clase o TDA <nombreClase> ([<tipo parametros>])[: <claseBase> ]<nombreTDA>

Documentacion de lasclases o TDA

Tabla 11: Definicion formal de la clase <nombreClase o nombreTDA><fecha> <Version #>

# clase o TDA <nombreClase ([tipo parametros]) o nombreTDA> [: nombreClaseBase]{Comentarios sobre la clase}

# metodo uoperacion

Especificacion de atributos: Comprende los elementos de datos re-queridos para conformar la estructura de datos interna de la clase o delTDA.Especificacion sintactica: Esta constituida por los metodos (de unaclase) u operaciones primitivas (de un TDA).Declaraciones: Comprende las declaraciones de las instancias de la claseo TDA y de los atributos o variables que seran utilizadas en el escenariode pruebas de la especificacion semantica.

.- Documentacion de lasdeclaraciones..- Documentacion de losatributos de la clase..- Documentacion de losmetodos u operacionesdefinidas en la especifi-cacion sintactica.

Especificacion semantica: Presenta el escenario de como se deben uti-lizar los metodos u operaciones ası como su comportamiento.

Tabla 12: Especificacion formal del <nombreMetodo> o de la operacion <nombreOperacion><fecha> <Version #>

# clase o TDA, # del metodo u operacion (tipo del metodo u operacion, tipo de acceso)nombreMetodo o nombreOperacion (Tipo:parametro,?)[:tipoResultado]

{Comentario sobre el metodo}{pre: <precondiciones>} {pos: <poscondiciones>}# Paso Algoritmo Documentacion de las vari-

ables utilizadas# Caso deprueba

Casos de prueba Documentacion de los ca-sos de prueba


Tabla 13: Especificacion del flujo de trabajo de la fase de Codificacion y PruebasPasos Actividades Tecnicas y Notaciones ProductosImplementaciondel SMA

.- Seleccionar la plataforma de desar-rollo (hardware y software).- Realizar el modelo de imple-mentacion (diagrama de componentesy diagrama de despliegue).- Seleccionar componentes de softwarereutilizables, si aplica.- Adaptar componentes de softwarereutilizables, si aplica.- Desarrollar componentes.- Documentar el codigo fuente.- Listar los componentes implementa-dos: reutilizados, adaptados y desar-rollados

.- Estandares de codifi-cacion y estilos de progra-macion.- Modelado de imple-mentacion.- Busqueda de compo-nentes reutilizables.- Busqueda de compo-nentes adaptables

.- Codigo fuente documenta-do de los componentes delSMA (reutilizados, adapta-dos, desarrollados).- Documento de imple-mentacion

Elaboracion delplan de pruebas

.- Definir los objetivos de las pruebas

.- Definir los tipos de pruebas a re-alizar y las tecnicas a utilizar.- Construir los formatos de los casosde prueba.- Disenar el plan de pruebas

.- Estandares de docu-mentacion de pruebas

.- Documento del plan depruebas

Realizacion depruebas unitariaspor clase (unidadde prueba)

.- Disenar los casos de prueba para losmetodos de cada clase.- Ejecutar los casos de prueba para losmetodos de cada clase.- Disenar los casos de prueba de in-stanciacion: herencia, polimorfismo yencadenamiento dinamico.- Ejecutar los casos de prueba de in-stanciacion.- Registrar los resultados de ejecucionde los casos de pruebas.- Elaborar el resumen de incidentes depruebas

.- Herramientas o ambientesde pruebas.- Estrategias de pruebasunitarias

.- Clases del SMA verifi-cadas y validadas.- Documento de pruebasunitarias

Realizacion depruebas horizon-tales de integracion(por niveles declases y agentes)y pruebas del sis-tema (funcionalesy no funcionales)

.- Disenar los casos de prueba

.- Construir emuladores (salidas) paraejecutar pruebas internas (pruebashorizontales o a un mismo nivel) anteeventos externos.- Documentar el codigo fuente de ca-da emulador.- Ejecutar los casos de prueba.- Registrar los resultados de ejecucion.- Elaborar el resumen de incidentes depruebas

.- Herramientas o ambientesde pruebas

.- Documento de pruebashorizontales y pruebas delsistema.- Documento de los emu-ladores para pruebas hori-zontales

Realizacion depruebas verticalesde integracion (porniveles del SMA)


.- Construir un emulador que generelos datos de los diferentes niveles delSMA.- Documentar el codigo fuente del em-ulador.- Ejecutar los casos de prueba.- Registrar los resultados de ejecucion.- Elaborar el resumen de incidentes depruebas


.- Documento de pruebas deintegracion.- Documento de los emu-ladores para pruebas verti-cales

Realizacion depruebas de insta-lacion


.- Ejecutar los casos de prueba en elambiente real.- Registrar los resultados.- Elaborar el resumen de incidentes


.- Documento de Pruebas deinstalacion.- Manual de instalacion

Realizacionde pruebas deaceptacion


.- Ejecutar los casos de prueba en elambiente real.- Registrar los resultados.- Elaborar el resumen de incidentes


.- Documento de pruebas deaceptacion


Figura 9: Ejemplo de un SMA para la automatizacion industrial

Para ilustrar el uso de la metodologıa propues-ta, en sus fases de conceptualizacion, analisis ydiseno, se presenta como ejemplo el desarrollo deun agente de visualizacion, el cual permite el de-spliegue de datos en diferentes dispositivos de sal-ida, a solicitud de cualquier otro agente de unSMA del cual este agente forma parte (ver figura9).

Este agente tiene la capacidad de configurar lainterfaz de usuario de un SMA en funcion de losdiferentes roles y perfiles de usuario o de aquellosagentes que soliciten su servicio, entendiendosepor configuracion la capacidad del agente de de-splegar los datos segun algun formato especifıco,por lo que la interfaz de usuario generada porel agente de visualizacion se dice que es config-urable.

En este ejemplo se presentaran los productos gen-erados en cada una de las fases de la metodologıapara caracterizar a los agentes y sus interacciones,omitiendo la fase de codificacion y pruebas, lacual no presenta caracterısticas muy diferentesa las de cualquier metodologıa de Ingenierıa deSoftware para realizar esas tareas. Se prefieremostrar el uso de nuestra metodologıa en la partedel modelado del sistema de ingenierıa orientadoa agentes para este caso de estudio, que es la partemas innovadora de ella.

4.1. Fase I. Conceptualizacion

El Agente de visualizacion (AV) procesa solici-tudes para el despliegue de valores de variables a

peticion de otros agentes del sistema. La gestionde visualizacion permite manejar perfiles y con-figuracines de usuarios en funcion de sus roles ydesplegar los datos.

La figura 10 muestra el diagrama del unico ca-so de uso para el AV. Los actores en este casode uso son los agentes de aplicaciones, que solic-itan una visualizacion especıfica, los agentes degestion de datos que permiten ubicar los datosy los agente especializados (repositorios, tablas,bases de datos) que almacenan los datos a desple-gar. Ademas, los usuarios que interactuan con elAV, para configurar sus formatos de visualizacion,tambien son considerados como actores. Este casode uso es especificado en la tabla 14.

Figura 10: Diagrama de caso de uso para el AV

Para este agente se define un unico servicio llama-do Desplegar Datos y para ello realizan las sigu-ientes actividades: consultar configuracion, actu-alizar configuracion, consultar perfil de usuario,


actualizar perfil de usuario y desplegar datos. Lafigura 11 muestra el diagrama de actividades delAV.

Tabla 14: Descripcion del caso de uso para el AV

Caso de uso Gestionar visualizacionDescripcion Procesa solicitudes para el despliegue

de valores de variables a peticion deotros agentes del sistema.

Pre-condicion

Existencia de solicitudes de de-spliegue de datos, de actualizacion deconfiguracion y perfiles de usuarios.

Actores Usuario, Agentes de Aplicacion,Agente Especializado y AgenteGestor de datos.

Condicionde fracaso

Error de comunicacion, en la recep-cion de la solicitud o en el despliegue.

Condicionde exito

Datos presentados o actualizacion deperfiles y configuracion de usuarios re-alizadas con exito.

Figura 11: Diagrama de actividades para el AV

4.2. Fase II. Analisis

En esta fase se presenta el modelo de especifi-cacion de las comunicaciones y coordinacion delSMA.

4.2.1. Modelo de Agente

La tabla 15 muestra un resumen del modelo deagente para el Agente de Visualizacion. Por ra-zones de espacio, esta tabla no contiene la descrip-cion de cada objetivo y cada uno de los serviciosdel agente.

4.2.2. Modelo de tareas

En este caso, las tareas que ejecuta el AV, vertabla 16, se asocian al unico servicio definido.

Una vez definidas las tareas, estas se especificansegun la tabla indicada en la descripcion de la fasede analisis. La tabla 17 muestra la especificacionde la tarea Realizar Consulta de Datos.

Cabe destacar que los ingredientes especificadosen la tabla 17, no son unicos y dependeran de lasfuncionalidades que se le especifiquen al agente.Pueden aparecer ingredientes asociados a la con-figuracion de usuario, en caso de cambiar la con-figuracion conocida por el agente.

Tabla 16: Relacion Servicio-Tareas para el AV

SERVICIOS-TAREASS1. Desple-gar datos

T1. Recibir solicitud y datosT2. Realizar consulta de perfil del usuarioT3. Realizar insercion de perfil del usuarioT4. Realizar modificacion del perfil delusuarioT5. Realizar eliminacion del perfil delusuarioT6. Realizar consulta de datosT7. Realizar consulta de configuracion delperfil del usuarioT8. Realizar insercion de configuraciondel perfil del usuarioT9. Realizar modificacion de configu-racion del perfil del usuarioT10. Realizar eliminacion de configu-racion del perfil del usuarioT11. Realizar despliegue de datos

4.2.3. Modelo de Coordinacion

En funcion del objetivo y servicios del AV, se de-fine una conversacion que permite todas las in-teracciones necesarias para el cumplimiento de losmismos. En la tabla 18 se presenta la conversaciondefinida para el AV y en la figura 12 se presentael diagrama de interaccion con los actos de hablade la conversacion definida.

4.2.4. Modelo de Comunicacion

A fin de ilustrar la especificacion de los actos dehabla, en la tabla 19 se caracteriza uno de losactos de habla usado en la conversacion definidaen el modelo de coordinacion.


Tabla 15: Modelo de Agente para el AVAGENTENombre Agente de VisualizacionPosicion SMAComponentes No aplicaMarco de referencia No aplicaDescripcion del agente Se encarga del despliegue o visualizacion de datos solicitados por cualquier agente autor-

izado del sistema. Estos datos deben ser visualizados en un formato preestablecido en laconfiguracion de la interfaz de usuario, de acuerdo a las necesidades de cada usuario. Lasactividades principales de este agente son: recibir solicitudes de visualizacion de datos, ac-tualizar los perfiles y configuracion de los usuarios de acuerdo al rol dentro del sistema yadministrar las distintas formas de interfaz de usuario que puede soportar el agente (Web,sistemas de ventanas con menu, comandos, etc.)

Objetivos del AgenteNombre Gestionar visualizacion de datosDescripcion Recibe la solicitud de visualizacion de datos identifica el formato de despliegue del o los

datos de acuerdo al perfil y configuracion del usuario y genera la visualizacion solicitadaParametro de entrada Solicitud y datos relativos a la solicitud (identificador del solicitante, punto de despliegue,

identificador de los datos a visualizar, entre otros.)Parametro de salida Notificacion de Visualizacion del o los datos solicitadosCondicion de activacion Recepcion de solicitud de visualizacion de datosCondicion de finalizacion Datos visualizadosCondicion de exito Se visualizaron los datos en el formato especificadoCondicion de fracaso No se visualizaron los datos solicitados o el formato es incorrecto o se produjo un error en

la comunicacion entre los actores, o los datos no existenOntologıa Ontologıa de visualizacion de datosServicios del AgenteNombre Desplegar datosDescripcion del Servicio Recibe la solicitud de visualizacion y los datos relativos a la solicitud (identificador de las

variable, rangos de valores a desplegar, entre otros). El agente verifica el perfil de usuario(permisos, entre otros), consulta (los) repositorio(s) donde se encuentran los datos, consultala configuracion del usuario y envia los datos al dispositivo o punto de despliegue. Esteservicio puede ser ejecutado bajo la modalidad de peticiones o se inicia una vez y luegosiempre se estara ejecutando cuando la aplicacion ası lo requiera.

Tipo de Servicio DualParametros de entrada Solicitud con datos relativos a la solicitud (variables o rangos a desplegar, identificador del

usuario, localizacion del repositorio donde se encuentra el (los) valor(es) de la(s) variable(s),dato(s) o rango(s) a desplegar, punto de despliegue).

Parametros de salida Notificacion de visualizacion de los datosPropiedades del ServicioNombre Valor DescripcionCalidad 0-

100Porcentaje de la calidad del servicio en funcion del tiempo de respuesta

Auditable 1 Capacidad de diagnosticar la calidad del servicioConfiabilidad 0-

100Certificacion de respuesta

Capacidad GeneralHabilidades del agente Gestionar los medios de almacenamiento, Gestionar Dispositivos de desplieguesRepresentacion del No aplicaConocimientoLenguaje de ACLComunicacionRestriccionNormas El acceso a los medios de almacenamiento estara supeditada a la existencia de conexion

entre el agente gestor de datos y los medios de almacenamiento. La gestion de dispositivosde despliegues remotos estara sujeta a la conectividad entre el agente solicitante y el puntode despliegue de los resultados.

Preferencias Gestion de las solicitudes por orden de llegadaPermisos Los medios de almacenamiento son accedidos a traves del Agente Gestor de Datos


Tabla 17: Modelo de Tareas

REALIZAR CONSULTA DE DATOSNombre Realizar consulta de datosObjetivo Realizar una consulta a un medio de al-

macenamiento de datosDescripcion Realiza la consulta de datos al medio

de almacenamiento de datos correspondi-ente, a traves del agente Gestor de Datos.

Serviciosasociados

Desplegar datos

Precondicion El perfil de usuario del agente solicitantepermite la cosulta solicitada.

Sub-tareas Verificar permisologıa del usuarioVerificar existencia de comunicacionSolicitar consulta al Agente Gestor deDatos.Manejar respuestaManejar errores

INGREDIENTES-NOMBRE DE LA TAREADatoId Identificador de los datos asociados a la

consultaUsuarioId Identificador del usuarioRango Rango de visualizacion de los datos, si son

numericos

Tabla 18: Modelo de Conversacion

CONVERSACION:Solicitud de servicio al AVObjetivo Enviar al Agente de Visualizacion el lis-

tado de los datos, variables operacionaleso rangos a desplegar, de manera perma-nente o puntual a solicitud de un agenteautorizado del sistema

Agentespartici-pantes

Agente de Aplicaciones, Agente especial-izado, Agente Gestor de Datos, Agentede Visualizacion

Iniciador Cualquiera de los agentes autorizados delsistema

Actos dehabla

Solicitar visualizacionConsultar datosVisualizar datosRespuesta

Precondicion Existir una solicitud de visualizacion dedatos, variables operacionales o rangos,existir la comunicacion entre los agentesinvolucrados, existir dispositivo de de-spliegue habilitado

Condicionde termi-nacion

Notificacion al agente solicitante sobrela respuesta de visualizacion o actual-izacion de los datos en el dispositivo so-licitado

Descripcion Mediante esta conversacion, el agente so-licitante inicia la conversacion que per-mite al Agente Visualizacion interactuarcon los actores involucrados en en servi-cio, para lograr el despliegue de los datos,en el dispositivo de salida indicado por elagente solicitante del servicio.

Figura 12: Diagrama de interaccion del AV

Tabla 19: Modelo de Comunicacion

ACTO DE HABLA:Visualizar DatosNombre ResultadosTipo Requerimiento de informacionObjetivo Enviar los datos solicitados en los

puntos de despliegue indicadosAgentes par-ticipantes

Agente especializado, Agente de apli-cacion y Agente de visualizacion

Iniciador Agente de aplicacionDatos inter-cambiados

Datos de entrada: Datos a ser visual-izador en el formato especificadoDatos de salida: Datos visualizados enel punto de despliegue o error

Precondicion Existencia de comunicacion entre losagentes involucrados

Condicion determinacion

Mensaje de error o de exito del servi-cio

Conversacio-nes

Solicitud de Servicio al Agente Visu-alizacion

Descripcion El agente visualizacion envıa los datosal punto de despliegue indicado en elformato indicado

4.3. Fase III. Diseno

En esta seccion se muestran algunas de las tablasobtenidas en la fase de diseno usando TDSO. Es-tas tablas representan la especificacion detalladade dicha fase para la implantacion del Agente Vi-sualizacion.

Las tablas 20 y 21 muestran la especificacionbasica y la especificacion formal, respectivamente,para el universo de clases y tipos de datos abstrac-tos de la clase AgenteVisualizacion.

Para cada uno de estos metodos se genera unaespecificacion formal. Para ilustrar dicha especi-ficacion, la tabla 22 muestra la descripcion detal-lada del metodo desplegarDatosSuministrados.


Tabla 20: Universo de clases del AVAgenteVisualizacion

ArchivoHash<Perfil>:perfilAgenteArchivoHash<Configuracion>:confDesplieguePerfil:perfilActualConfiguracion:confActualIdAgente: idAgenteIdConf:idConfig+contruirAgenteVisualizacion(): AgenteVisualiza-cion+desplegarDatosSuministrados(): Logico+desplegardatosConsultados(): Logico+insertarPerfilAgente(): Logico+consultarPerfilAgente(): Perfil+modificarPerfilAgente():Logico+eliminarPerfilAgente(): Logico+insertarConfiguracionAgente(): Logico+consultarConfiguracionAgente():Lista<Configuracion>+modificarConfiguracionAgente(): Logico+eliminarConfiguracionAgente(): Logico+destruirAgenteVisualizacion()

5. Conclusiones

En este artıculo se presenta una metodologıa paraespecificar SMA en ambientes computacionales.La metodologıa permite el modelado de un sis-tema de ingenierıa orientado a agentes. Para esto,usa el Lenguaje de Modelado Unificado (UML),ampliamente usado para modelar sistemas desoftware, y la Tecnica de Desarrollo de Sistemasde Objetos (TDSO) la cual es una herramientapara la especificacion formal de modelos orien-tados a objetos. La metodologıa abarca los lin-eamientos fundamentales para la especificacionde sistemas de ingenierıa, iniciando con la fasede conceptualizacion hasta la fase de codificaciony pruebas. La fase de conceptualizacion permiteidentificar los actores del sistema y sus casos deuso, lo cual sirve de base para proponer la arqui-tectura del SMA y definir sus servicios. La fase deanalisis permite describir todo el modelo multia-gente, desde sus objetivos y tareas, capacidadesinteligentes, hasta sus interacciones con el restodel sistema. La fase de diseno permite establecerlas bases para la futura implantacion del SMAcomo un objeto de software. Para ello se usanlas plantillas descriptivas de desarrollos de obje-tos planteadas en TDSO. En esta fase se llega aldiseno de clases y a la definicion y especificacionformal de dichas clases. Finalmente, en la fase decodificacion y prueba se definen claramente loselementos que permiten verificar la codificacionhecha a partir de la fase de diseno, teniendo es-pecial importancia las pruebas de integracion delsistema.

El caso de estudio presentado muestra las bon-dades de la metodologıa para llevar a cabo eldiseno de un agente que cumple un servicio es-pecıfico dentro de un SMA.

Agradecimientos

Este trabajo ha sido financiado por el FONAC-IT bajo el proyecto No. 2005000170, y por elCDCHT-ULA a traves del proyecto No. I-820-05-02-AA, instituciones a quienes los autores expre-san sus agradecimientos.

Referencias

[1] D. Tegarden A. Dennis, B. H. Wixom. Sys-tems analysis and design with UML version2.0: an object-oriented approach. John Wiley& Sons, 2005.

[2] J. Aguilar, I. Besembel, O. Teran, F. Nar-ciso, M. Cerrada, F. Hidrobo, A. Rıos, andL. Leon. Descripcion del Marco Referencial:Desarrollo de Ingenierıa Conceptual de Soft-ware para la definicion de una ArquitecturaSistemica que permita implementar las fun-cionalidades y tecnologıas identificadas enlas mesas corporativas de Arquitectura y deAplicaciones sobre la Plataforma Net-DAS2.0. Informe Tecnico, FUNDACITE-ULA,Venezuela, Noviembre 2004.

[3] J. Aguilar, C. Bravo, E. Colina, and F. Ri-vas. Sistema Multiagentes para Tratamientode Situaciones Anormales en Procesos Indus-triales. In V Congreso Nacional de la Aso-ciacion Colombiana de Automatica, pages24–28, Medellın-Colombia, Julio 2003.

[4] J. Aguilar, C. Bravo, and F. Rivas. Diseno deuna Arquitectura de Automatizacion Indus-trial basada en Sistemas Multiagentes. Re-vista Ciencia e Ingenierıa, Facultad de Inge-nierıa, 25(2):75–88, Julio 2004.

[5] J. Aguilar, V. Bravo, M. Cerrada,F. Hidrobo, G. Mousalli, and F. Rivas.Especificacion detallada de los agentesdel SCDIA. Informe Tecnico del 3er ano,Proyecto Agenda Petroleo, ULA-FONACIT,Venezuela, Diciembre 2003.


Tabla 21: Definicion Formal de la clase AgenteVisualizacion10 de Mayo de 2007 Version 1.0

AgenteVisualizacion{Coleccion de clases y TDAs requerida para implantar el AV}

Especificacion de atributos:1 ArchivoHash<Perfil>:perfilAgente Perfil : TDA que permite almacenar los elementos es-

tructurales del perfil del Agente solicitante. Posee loscampos: IdAgente y DescripcionPerfilperfilAgente: Archivo hash donde se almacenan losperfiles de los distintos agentes conocidos por AV

2 ArchivoHash<Configuracion>:confDespliegue Configuracion: TDA que permite almacenar los ele-mentos estructurales de la configuracion del Agentesolicitante. Esta estructura posee los campos: IdPer-fil,IdConf, ConfiguracionDespliegue, Salida. DondeConfiguracionDespliegue es una estructura que de-scribe la informacion referente al despliegueconfDespliegue: Archivo hash donde se almacenan lasdistintas configuraciones relacionadas con un perfil

3 Perfil:perfilActual perfilActual : Variable interna que se usa para cargarun registro del archivo perfilAgente en memoria

4 Configuracion:confActual confActual : Variable interna que se usa para cargarun registro del archivo confDespliegue en memoria

5 IdAgente: idAgente ideAgente: Identificacion del agente6 IdConf:idConfig idConf : Identificacion de la configuracion

Especificacion sintactica:1 construirAgenteVisualizacion(ArchSec< Perfil > : per-

filInicial, ArchivoSec< Configuracion > : confInicial)construirAgenteVisualizacion(): Crea un agente deltipo AgenteVisualizacion

2 desplegarDatosSuministrados(IdAgente : idA, IdConf :conf, Lista<InformacionVar> : listaValores) : Logico

desplegarDatosSuministrados(): Metodo que per-mite el despliegue de los datos suministrado comoparametro siguiendo la configuracion de despliegue.

3 desplegarDatosConsultados(IdAgente : idA, IdConf :conf, Lista<InformacionVar> : listaVar) : Logico

desplegarDatosConsultados(): Metodo que permite eldespliegue de los datos asociados a la configuracion devisualizacion del agente. Este metodo permite generargraficos de tendencias, hacer consultas automaticas alos repositorios de datos y hacer despliegues

4 insertarPerfilAgente(IdAgente : idA, Perfil : perfiAgente): Logico

insertarPerfilAgente(): Inserta un nuevo perfil delagente para que sea conocido por el AV.

5 consultarPerfilAgente(IdAgente : idA) : Perfil consultarPerfilAgente(): Devuelve el perfil del agente.6 modificarPerfilAgente(IdAgente : idA, Perfil : nuevoperfi-

Agente, Configuracion: nuevaConfiguracion) : LogicomodificarPerfilAgente() : Modifica el perfil actual delagente que invoca agente de visualizacion.

7 eliminarPerfilAgente(IdAgente : idA) : Logico eliminarPerfilAgente(): Elimina el perfil actual delagente que invoca agente de visualizacion.

8 insertarConfiguracionAgente(IdAgente : idA, Configura-cion : nuevaConfiguracion) : Logico

insertarConfiguracionAgente() : Inserta una nuevaconfiguracion asociada al agente cliente. Un agentepuede tener varias configuraciones de despliegue.

9 consultarConfiguracionAgente(IdAgente : idA) :Lista<Configuracion >

consultarConfiguracionAgente(): Devuelve la config-uracion que esta activa del agente cliente.

10 modificarConfiguracionAgente(IdAgente : idA, IdConf:idc, Configuracion : nuevaConfiAgente) : Logico

modificarConfiguracionAgente(): Modifica la configu-racion de despliegue de un agente cliente

11 eliminarConfiguracionAgente(IdAgente : idA, IdConf:idc) : Logico

eliminarConfiguracionAgente(): Elimina una configu-racion del agente cliente.

12 destruirAgenteVisualizacion() destruirAgenteVisualizacion(): Elimina un agente deltipo AgenteVisualizacion.

DeclaracionesAgenteVisualizacion x x : Instancia (objeto) de la clase AgenteVisualizacion.Logico ban ban : cierto si hay exito, falso si no.Especificacacion SemanticaAgenteVisualizacion() → AgenteVisualizacionx.desplegarDatosSuminstrados() → banx.desplegarDatosConsultados → banx.destruirAgenteVisualizacion()


Tabla 22: Especificacion formal del metodo desplegarDatosSuministrados28 de junio de 2008 Version 1.0

1,2 (Observador, Publico)desplegarDatosSuministrados(IdAgente: idA, IdConf: conf, Lista<InformacionVar>: listaValores): Logico{Despliega los valores suministrados como parametros siguiendo la configuracion asociada al agente que solicitante}

{Pre: Debe existir Archivo hash de perfil y de configuraciones} {Pos: <Plista 6= nulo ∨ Plista = Nulo>}1 Si (Existe perfilAgente y confDespliegue) entonces

perfilActual=perfilAgente.busca(idA) busca(): Funcion del archivo hash que busca elparametro.

confActual=confDespliegue(idA, conf)desplegar(perfilActual,confActual,listaValores) desplegar(): Metodo del dispositivo de de-

spliegue.Devolver(cierto)

sinoDevolver(falso)

fin si2 crearAgenteVisualizacion x3 x.desplegarDatosSuministrados() → Cierto o Falso Despliega los datos segun un perfil y una con-

figuracion.

[6] J. Aguilar, M. Cerrada, F. Hidrobo,G. Mousalli, and F. Rivas. Aplicacion de Sis-temas Multiagentes en Problemas del MundoReal. In XXVII Conferencia Latinoameri-cana de Informatica (CLEI), Sep 2001.

[7] J. Aguilar, Ferrer E, N. Perozo, and J. Viz-carrondo. Arquitectura de un Sistema Oper-ativo Web. Revista Gerencia en TecnologıaInformatica, 2(1):16–29, 2003.

[8] J. Aguilar, F. Hidrobo, and M. Cerrada.A Methodology to Specify Multiagent Sys-tems. Lecture Notes in Artificial Intelligence,4496:92–101, 2007.

[9] J. Aguilar, G. Mousalli, V. Bravo, andH. Dıaz. Agentes de control y de gestion deservicio para el modelo de referencia SCDIA.In II Simposio Internacional de Automati-zacion y Nuevas Tecnologıas, TECNO2002,pages 45–50, Merida, Venezuela, Noviembre2002.

[10] J. Aguilar, N. Perozo, and J. Vizcarrondo.Definition of a Verification Method for theMASINA Methodology. International Jour-nal of Information Technology, 12(3):121–131, 2006.

[11] J. Aguilar and J. Vizcarrondo. Descripciondel Subsistema Manejador de Objetos Web.In XXX Conferencia Latinoamericana de In-formatica, pages 440–450, Arequipa, Peru,Octubre 2004.

[12] F. Alonso, S. Frutos, L. Martinez, andC. Montes. SONIA: A Methodology for Nat-ural Agent Development. In Fifth Inter-national Workshop Engineering Societies in

the Agents World, Toulouse, France, October2004.

[13] I. Besembel. Tecnica de Desarrollo de Sis-temas de Objetos (TDSO). Guıa Tecni-ca, Grupo de Investigacion en Ingenierıa deDatos y Conocimiento. Universidad de LosAndes, Merida, Venezuela, 2003.

[14] C. Bravo, J. Aguilar, M. Cerrada, and F. Ri-vas. Design of an industrial automation ar-chitecture based on multi-agents systems. InProceedings of 16th IFAC World Congress,Prague, Czech Republic, July 2004.

[15] V. Bravo, J. Aguilar, F. Rivas, and M. Cer-rada. Diseno de un Medio de Gestion deServicios para Sistemas Multiagentes. InXXX Conferencia Latinoamericana de In-formatica, pages 431–439, Arequipa, Peru,Octubre 2004.

[16] P. Bresciani, A.Perini, P. Giorgini,F. Giunchiglia, and J. Mylopoulos. Tropos:An Agent-Oriented Software DevelopmentMethodology. Autonomous Agents andMulti-Agent Systems, 8(3):203–236, 2004.

[17] B. Burmeister. Models and methodolo-gy for agent-oriented analysis and design.In K. Fisher, editor, Working Notes of theKI’96 Workshop on Agent-Oriented Pro-gramming and Distributed Systems, Eind-hoven, The Netherlands, 1996.

[18] M. Cerrada, J. Cardillo, J. Aguilar, andR. Faneite. Agent-Based MaintenanceManagement System For the DistributedFault Tolerance. In Proceedings of the


IFAC SAFEPROCESS 2006, pages 997–1002, Beijing-China, Agosto 2006.

[19] M. Cerrada, J. Cardillo, J. Aguilar, andR. Faneite. Agents-based reference design forfault management systems in industrial pro-cesses. Computers in Industry, 58(4):313–328, 2007.

[20] A. Collinot, P. Carle, and K. Zeghal. Cas-siopeia: A Method for Designing Computa-tional Organizations. In The First Interna-tional Workshop: Decentralized Multi-AgentSystems DIMAS’95, pages 124–131, Crakow,Poland, Nov 1995.

[21] S. A. DeLoach. Modeling OrganizationalRules in the Multi-agent Systems Engineer-ing Methodology. In Canadian Conferenceon AI, pages 1–15, 2002.

[22] J. DiLeo, T. Jacobs, and S. A. DeLoach.Integrating Ontologies into Multiagent Sys-tems Engineering. In AOIS@CAiSE, 2002.

[23] M. Elammari and W. Lalonde. An Agent-Oriented Methodology: High-level and in-termediate models. In G. Wagner andE. Yu, editors, The First International Bi-Conference Workshop on Agent-Oriented In-formation Systems, Seattle, USA and Heidel-berg, Germany, May, June 1999.

[24] M. Fowler and K. Scott. UML distilled: abrief guide to the standard object modelinglanguage. Addison-Wesley, 2000.

[25] A. Giret and V. Botti. Holons andagents. Journal of Intelligent Manufactur-ing, 15:645–659, 2004.

[26] N. Glaser. The CoMoMAS Methodology andEnvironment for Multi-Agent System Devel-opment. In C. Zhang and D. Lukose, editors,Multi-Agent Systems - Methodology and Ap-plications, pages 1–16. Springer, LNAI 1286,1997.

[27] J. Gomez and J. Pavon. Methodologiesfor developing multi-agent systems. Jour-nal of Universal Computational Science,10(4):359–374, 2004.

[28] B. Henderson-Sellers and P. Giorgini (eds.).Agent-Oriented Methodologies. Idea GroupPublishing, 2005.

[29] C. A. Iglesias, M. Garijo, and J. Centeno-Gonzalez. A Survey of Agent-OrientedMethodologies. In ATAL ’98: Proceedings

of the 5th International Workshop on Intel-ligent Agents V, Agent Theories, Architec-tures, and Languages, pages 317–330, Lon-don, UK, 1999. Springer-Verlag.

[30] C.A. Iglesias. Definicion de Metodologıapara el Desarrollo de Sistemas Multiagentes.Master’s thesis, Universidad Politecnica deMadrid, Departamento de Igenierıa de Sis-temas Telematicos, Madrid, Espana, Enero1998.

[31] C.A. Iglesias, M. Garijo, J:C Gonzalez, andJ.R. Velazco. Analysis and Design of Multi-Agent Systems using MAS-CommonKADS.In M.P. Singh, A.S. Rao, and M. Wooldridge,editors, Intelligent Agents IV. Agents Theo-ries, Architectures and Language, pages 1–16. Springer, LNAI 1365, 1999.

[32] Aguilar J., Cerrada M., Mousalli G., RivasF., and Hidrobo F. A Multiagent Mod-el for Intelligent Distributed Control Sys-tems. Lecture Notes in Artificial Intelligence,3681:191–197, 2005.

[33] N. Jennings and S. Bussmann. Agent-basedControl Systems. IEEE Control SystemsMagazine, pages 61–73, 2003.

[34] D. Kinny, M. Georgeff, and A. Rao. AMethodology and Modelling Technique forSystems of BDI Agents. In Rudy van Hoe,editor, Seventh European Workshop on Mod-elling Autonomous Agents in a Multi-AgentWorld, Eindhoven, The Netherlands, 1996.

[35] V. Marik and D. McFarlane. Industri-al Adoption of Agent-Based Technologies.IEEE Intelligent Systms, pages 27–35, 2005.

[36] J. Montilva. Desarrollo de AplicacionesEmpresariales. El Metodo Watch. InformeTecnico, Grupo de Investigacion en Inge-nierıa de Datos y Conocimiento. Universidadde Los Andes, Merida, Venezuela, 2004.

[37] Y-E. Nahm and H. Ishikawa. A hybridmulti-agent system architecture for enter-prise integration using computer networks.Robotics and Computer-Integrated Manufac-turing, 21:217–234, 2005.

[38] F. Narciso and I. Besembel. Tecnicas deDesarrollo de Sistemas de Objetos (TDSO).In XXII Seminario Interuniversitario de In-vestigacion en Ciencias Matematicas, pages440–450, Ponce, Puerto Rico, Febrero 2007.


[39] OMG. Object Management Group.http://www.omg.org.

[40] OMG. Unified Modeling Language Speci-fication, 2003. Version 2.0, June 2003 viahttp://www.uml.org.

[41] A. Omicini. SODA: Societies and Infrastruc-tures in the Analysis and Design of Agent-Based Systems. In P. Ciancarini and M.J.Wooldridge, editors, Agent-Oriented Soft-ware Engineering, pages 185–194. Springer,LNCS 1957, 2001.

[42] D. Ouelhadj, S. Petrovic, P.I. Cowling, andA. Meisels. Inter-agent cooperation and com-munication for agent-based robust dynamicscheduling in steel production. Advanced En-gineering Informatics, 18:161–172, 2004.

[43] L. Padgham and M. Wimikoff. Prometheus:A Methodology for Developing IntelligentAgents. In P. Giunchiglia, J. Odell, andG. Weiss, editors, Agent-Oriented SoftwareEngineering III, pages 174–185. Springer,LNCS 2585, 2003.

[44] D. Pilone and N. Pitman. UML 2.0 in aNutshell. O’REALLY, 2005.

[45] A. Rıos, F. Hidrobo, J. Aguilar, andM. Cerrada. Control and SupervisionSytem Development with Intelligent Agents.WSEAS Transactions on Systems, 6(1):141–148, 2007.

[46] M. Russ. Learning UML 2.0. SebastopolO’Reilly Media, 2006.

[47] G. Schreiber, B. Wielinga, R. de Hoog,H. Akkermans, and W. Van de Velde. Com-monKADS: A Comprehensive Methodolo-gy for KBS Development. IEEE Expert:Intelligent Systems and Their Applications,9(6):28–37, 1994.

[48] A. L. Self and S. A. DeLoach. Designingand Specifying mobility within the multia-gent systems engineering methodology. InSAC ’03: Proceedings of the 2003 ACM sym-posium on Applied computing, pages 50–55,New York, NY, USA, 2003. ACM Press.

[49] S.W. Ambler. The object primer: the appli-cation developer’s guide to object orientationand the UML. Cambridge University Press,New York, 2nd ed. edition, 2001.

[50] S. Vafadar, A. Barfouroush, and M. Reza A.Shirazi. Towards a More Expressive and

Refinable Multiagent System EngineeringMethodology. In AOIS, pages 126–141, 2003.

[51] T. Wagner. Applying Agents for Engineer-ing of Industrial Automation Systems. InM. Schillo et al., editor, Lecture Notes inArtificial Intelligence. MATES 2003, volume2831, pages 62–73. Springer Verlag, Berlin,2003.

[52] M. F. Wood and S. A. DeLoach. Anoverview of the multiagent systems engi-neering methodology. In First internation-al workshop, AOSE 2000 on Agent-orientedsoftware engineering, pages 207–221, Secau-cus, NJ, USA, 2001. Springer-Verlag NewYork, Inc.

[53] M. Wooldridge, N. R. Jennings, and D. Kin-ny. The Gaia methodology for agent-orientedanalysis and design. Autonomous Agents andMulti-Agent Systems, 3(3):285–312, 2000.Times Cited: 3 Article English Cited Refer-ences Count: 34 412fd.

[54] F. Zambonelli, N. R. Jennings, andM. Wooldridge. Developing multiagentsystems: The gaia methodology. ACMTrans. Softw. Eng. Methodol., 12(3):317–370, 2003.

[55] W. Zayas, J. Aguilar, M. Cerrada,F. Hidrobo, and F. Rivas. Develop-ment of a Code Generation System forControl Agents. WSEA Transactions onComputers, 5(10):2406–2411, 2006.

aguilar, j., bessembel, i., cerrada, m., hidrobo, f

Documents