Printer Friendly

Enfoque para la validacion sintactica de modelos organizacionales de Sistemas Multiagentes.

I. Introduccion

Durante las ultimas decadas la tecnologia orientada a agentes se ha convertido en una de las herramientas mas importante para el modelado de sistemas complejos, distribuidos y abiertos. En este sentido los sistemas basados en agentes han demostrado exitosamente su potencial abordando una amplia variedad de problemas que van desde la robotica, resolucion de problemas distribuidos, modelado y simulacion, solo por mencionar algunas areas (Wooldridge & Jennings, 1995; Wooldridge, 2009). El creciente interes se debe, entre otros, al concepto de agente como entidad autonoma. Un agente es una entidad fisica o virtual con un alto grado de autonomia, independiente, capaz de cooperar, competir, comunicarse, actuar flexiblemente y ejercer control sobre su comportamiento dentro del marco de sus objetivos. Un sistema multiagentes esta compuesto por multiples agentes inteligentes que interactuan entre si para alcanzar objetivos que pueden ser compartidos o no entre los agentes (Weiss, 2013).

Entre los sistemas multiagentes (SMA de ahora en mas) el enfoque organizational promueve una nueva forma de abordar problemas complejos. Este enfoque consiste en descomponer los problemas en partes mas pequenas ademas de proveer el contexto de interaccion entre los agentes de cada una de estas unidades. (J. Ferber & Gutknecht, 1998) define que dos niveles son posibles, nivel "organizational" y nivel "agente". El nivel organizational o social (tambien llamado "que") es donde se puede observar los aspectos dinamicos y estructurales de una organizacion SMA. Este nivel describe la relacion esperada y los patrones de actividad que deberian ocurrir en el nivel de agentes. Tambien, es comun encontrar conceptos tales como role, grupos, comunidades, tareas e interaccion. En el nivel de agentes (denominado "como") describe el comportamiento del agente. En otras palabras, detalla la arquitectura interna del agente, sus estados mentales, creencias, deseos, intenciones y metas, y si es reactivo o intencional.

Ademas, adoptar el enfoque organizacional permite al disenador tratar a los problemas a traves de dos estrategias posibles: la descomposicion vertical y la horizontal. La descomposicion vertical permite que el comportamiento que representa a la organizacion sea fragmentado en un conjunto de sub-organizaciones de menor abstraccion. En cambio, la descomposicion horizontal, modela las interacciones existentes entre las entidades presentes en el mismo nivel de abstraccion el cual es necesario para alcanzar los objetivos requeridos (Cossentino, 2010).

En la Ingenieria de Software Orientada a Agentes (ISOA o AOSE por sus siglas en ingles), requiere para el analisis, diseno e implementacion de cuatro elementos fundamentales: el metamodelo y los lenguajes que se utilizaran para describir los modelos; la metodologia que define la secuencia de pasos a seguir y los actores involucrados para la obtencion de un diseno del producto; la plataforma de implementacion sobre la cual se ejecutaran estos modelos; y por ultimo la herramienta CASE (Computer Aided Software Engineering) utilizada para asistir al disenador en el proceso de desarrollo.

En este articulo presentamos los avances realizados en la herramienta CASE denominada Janeiro Studio (Araujo, 2013) para el metamodelo CRIO (Rodriguez, 2007) y la validacion sintactica de modelos.

El trabajo esta estructurado de la siguiente manera: la seccion 2 se realiza un breve resumen de los trabajos que existen en la literatura sobre herramientas que permiten el modelado de sistemas multiagentes. Seccion 3 se presenta la adaptacion del metamodelo CRIO y los diferentes diagramas asociados al mismo. Seccion 4, introduce a la validacion sintactica de modelos. Seccion 5, se presenta un conjunto de reglas de validacion sintacticas que actualmente se estan utilizando en la herramienta Janeiro Studio. Seccion 6 es presentado un caso de estudio. Y por ultimo, en la Seccion 7, son realizadas las conclusiones.

II. Trabajos relacionados

Una CASE es un conjunto de herramientas informaticas que asisten al disenador en algunas de las actividades relacionadas con el desarrollo de un sistema (requerimientos, analisis, diseno, codificacion y pruebas). Estas herramientas permiten transmitir lo mas rapido posible las intenciones de los desarrolladores mediante una combinacion de notaciones graficas y textuales que representan algun lenguaje especifico compartido por el equipo de desarrollo. Ademas, incrementan la productividad de los equipos de desarrollo reduciendo tiempo y costos a su vez que mejora la calidad del software entregado (Sommerville, 2010). Existen diferentes herramientas presentes en la literatura para el modelado de sistemas multiagentes, muchas de estas cuentan con modulos de validacion que permiten asegurar que los modelos sean conceptualmente validos. En este trabajo nos enfocamos en aquellas que se encuentran centradas en los conceptos organizacionales (Organization-Centred MultiAgent System). Muchas de estas herramientas son para metamodelos especificos y brindan soporte visual para algunos o la mayoria de sus diagramas mas relevantes. La tabla 1 ofrece un resumen de las principales herramientas CASE para el modelado de SMA.

III. Vision General del Enfoque

Durante los ultimos 30 anos la tecnologia agentes representa una alternativa para abordar problemas complejos. Dentro de los SMA, el enfoque organizational ha ganado especial importancia. Este esta inspirado en la metafora social y es usado tanto en metodologias (GAIA (Wooldridge, 2000), MESSAGE (Caire, 2002), ASPECS (Cossentino, 2010)) como en metamodelos (AGR (Ferber, 2004), MOCA (M. Amiguet, 2003), CRIO (Rodriguez, 2007)). Conceptos como "Organizacion", "Grupo", "Comunidad", "Roles", "Protocolos" son terminos comunes en este tipo de enfoque. En el presente articulo nos centraremos en el metamodelo CRIO el cual extiende de RIO (Hilaire, 2000).

CRIO es un metamodelo basado en los conceptos organizacionales. Su nombre resulta del acronimo formado por sus cuatros conceptos principales:

Una Capacidad es la descripcion de un know-how/servicio. En otras palabras es la especificacion de una transformacion de una parte de un sistema o de su ambiente. Es una abstraccion de alto nivel que promueve la reusabilidad y modularidad y en este sentido puede ser considerado como un componente basico de diseno. Ademas, el concepto de capacidad permite la definicion de un rol sin hacer ninguna suposicion de la arquitectura interna de este.

Un Role es definido como un comportamiento esperado (un conjunto de tareas del rol ordenados por un plan) y un conjunto de derechos y obligaciones dentro del contexto de la organizacion. El objetivo de cada rol es contribuir en alcanzar los requerimientos de la organizacion dentro del cual esta definido.

Una Interaccion es una secuencia de eventos dinamica intercambiada entre roles (una especificacion de alguna ocurrencia que puede potencialmente disparar efectos en el sistema) o entre roles y entidades fuera del sistema.

Por ultimo, una Organizacion se define como una coleccion de roles y sus interacciones dentro de un determinado contexto. La figura 1 muestra el diagrama UML del metamodelo.

[FIGURA 1 OMITIR]

El metamodelo descripto en la seccion anterior no es facilmente manipulable por herramientas informaticas. Por este motivo es necesario adaptarlo para su manipulacion y validacion. En este contexto se ha seleccionado el Eclipse Modeling Framework (EMF) (2) para esta representacion.

EMF es parte importante de una gran familia de proyectos llamado Eclipse Modeling Project (EMP) (3). Es una libreria que permite a los expertos construir sus propias aplicaciones basadas en un metamodelo de datos estructurados denominado Ecore. Un Ecore simplifica la definicion de un metamodelo facilitando la programacion requerida para la implementacion de un modelo especifico del dominio. Por otra parte, el uso de EMF permite el modelado de jerarquias donde un modelo es el metamodelo de otro.

Los conceptos utilizados en este framework son mas simples que aquellos definidos por la OMG (4). Esto se debe a que la intencion es obtener rapidamente un codigo ejecutable. Los conceptos principales son EPackage (paquete), EClass (clase), EDataType (tipo de datos), EEnum (enumeracion) y EObject (objeto) ademas de la posibilidad de representar a traves del concepto de EReference las relaciones de asociacion y agregacion. El metamodelo CRIO fue desarrollado completamente usando este framework y ademas es el nucleo principal de nuestro enfoque.

Para el soporte de la modelizacion basado en CRIO y ASPECS, se ha desarrollado la CASE Janeiro Studio. Para Janeiro Studio se utilizo Eclipse Rich Client Platform (RCP) (McAffer, 2010) como base dada las ventajas que ofrece dicha plataforma para el desarrollo de herramientas integradas. Provee un entorno rico en opciones y debido a su popularidad posee una comunidad importante que le da soporte. Tambien destacamos su desarrollo basado en el concepto de plugins que permite una alta modularizacion del sistema. Un plugin es definido como una unidad de modularidad en Eclipse, de hecho todo en Eclipse es desarrollado bajo este concepto. Basicamente, un plugin es autodescriptivo y explicita una lista de los otros plugins a los cuales depende para un funcionamiento adecuado. RCP nos permite una manera clara y sencilla de gestionar los plugins para construir aplicaciones complejas y funcionales. Otro de los framework involucrados es Graphical Modeling Framework (GMF) util para establecer como los conceptos seran representados graficamente en el entorno de desarrollo propuesto.

Actualmente, y para cubrir las etapas tempranas de requerimientos, Janeiro cuenta con tres Ecore. (i) DRDMetamodel, (ii) PODMetamodel, (iii) ProblemMetamodel. Los dos primeros metamodelos son las bases de los Diagramas de Requerimientos del Dominio y de Ontologia. El tercer metamodelo, ProblemMetamodel, surgen los Diagramas de Organizacion, Interaccion y Comportamiento. Estos diagramas pueden considerarse como vistas del metamodelo y es la forma en que sera manipulado el metamodelo. En la tabla 2, presentada mas adelante, se puede ver en detalle los Ecore y sus diagramas asociados. En este articulo, y por cuestiones de espacio, nos centraremos en el Ecore principal de la herramienta, ProblemMetamodel.

En la figura 2 se muestra la adaptacion de CRIO en EMF. En el mismo se distingue claramente los conceptos centrales que conforman dicho metamodelo tales como capacidad, organizacion, rol, protocolo, entre otros. Para que esta representacion sea posible fue necesaria la realizacion de algunas adaptaciones especificas que sirven para cumplir con las especificaciones inherentes del metamodelo CRIO. El Diagrama Organizacional tiene como elementos principales a los conceptos de organizacion, compuesta por rol, protocolo y capacidad. Del concepto de rol se desprende behaviour que es el elemento raiz para el Diagrama de Comportamiento y en donde se describe los estados y las transiciones posibles que pueden darse en un rol. El concepto de Participant nos permite enlazar el rol con protocolo. Por ultimo, protocol es el elemento principal del Diagrama de Interaccion, el mismo esta compuesto de interacciones, RoleSet, callCapacity y onSignal. El primero, interaccion, es el intercambio de informacion entre roles. El concepto de RoleSet es el que nos permite representar al rol en el Diagrama de Interaccion dado que el framework utilizado no es posible la utilizacion de un mismo concepto en dos diagramas diferentes. Y por ultimo, tanto callCapacity como onSignal son dos tipos de operaciones especiales que puede realizar un rol y que indica el llamado a una capacidad o el evento disparado por un agente indicando la finalizacion de alguna actividad, respectivamente.

[FIGURA 2 OMITIR]

b. Manipulacion del Modelo

A medida que un proyecto itera a traves de los ciclos de desarrollo y pasado un determinado tiempo, los disenadores pueden comenzar a validar y verificar que los modelos respeten determinadas reglas. El paradigma orientado a objetos cuenta con un gran numero de herramientas de validacion y verificacion, en cambio en la tecnologia agente no podemos decir lo mismo; dado que en la actualidad existen muy pocas herramientas que permitan la validacion de modelos. Es mas, ese trabajo en muchos casos es realizado por personas y de forma manual con las desventajas que trae aparejado (Fagan, 1976).

En la figura 3 se muestra una vista general de los conceptos utilizados para la validacion sintactica. Utilizando la definicion del metamodelo en EMF podemos construir editores que brindaran a los usuarios de una metafora grafica de los conceptos ademas de hacer respetar ciertas restricciones que estan presentes en el metamodelo (Manipulacion del modelo). Basandonos en estos diagramas podemos generar un modelo del sistema real. Las vistas principales del metamodelo estan detalladas en la Tabla 2. Si bien determinados elementos pueden estar validados a traves del metamodelo de forma automatica por las herramientas, existen un conjunto de caracteristicas sintacticas que no pueden ser validadas o la necesidad de validarlas hacen impractica la utilizacion de la herramienta. Es por ello que seria interesante contar con una herramienta que nos permita definir nuestras propias reglas de validacion ademas de hacerlo de forma automatizada.

[FIGURA 3 OMITIR]

IV. Validacion Sintactica

Es posible realizar validaciones de diferentes maneras y abordando diferentes aspectos de un modelo. El objetivo de la definicion de reglas de validacion es la de detectar, de manera temprana, los defectos del modelos para que puedan ser tratadas de manera inmediata.

Detectar un error en etapas tempranas y de forma automatica trae aparejado un importante numero de ventajas, entre ellas permitira reducir drasticamente los costos de desarrollo del sistema al mismo tiempo que el producto se acerca a los estandares de calidad deseada por la organizacion. Es por ello que contar con un mecanismo de validacion automatizada nos permitira responder rapidamente a los errores detectados (Unhelkar, 2005).

El lenguaje seleccionado para la validacion de los modelos es Epsilon Validation Language (EVL) (5). Utilizamos EVL en vez de Object Constraint Language (OCL) (6) que es el lenguaje mas utilizado), dado que posee multiples ventajas que permiten mayor especificidad de las propiedades de los modelos. La combinacion de los modelos y EVL provee una alta expresividad que habilita a los desarrolladores a formular propiedades adicionales que no pueden ser expresados en la notacion grafica. Algunas de las ventajas que ofrece EVL son: (i) la posibilidad de definir restricciones que son independientes de otras, (ii) modularizar o descomponer las consultas complejas en otras mas sencillas, (iii) permite especificar mensajes personalizados cuando no se satisface un invariante, (iv) permite solucionar dinamicamente las inconsistencias encontradas, (v) soporta operaciones de entrada y salida del usuario, entre otras caracteristicas.

V. Reglas de Validacion Sintactica de modelos

En esta seccion se detallan algunas de las reglas de validacion para modelos basados en CRIO. Las reglas presentadas en este articulo representan una parte del conjunto de restricciones obligatorias que son definidas por el metamodelo CRIO. Por limitaciones de espacio, solo se presentaran las algunas reglas por cada concepto a forma de ilustracion del enfoque.

Reglas asociadas a Rol

(1) Es obligatorio que los roles posean un nombre.
    Role {

   constraint HasName {

      check : sefmame.isDefinedO
      message : 'Role must have a name'

   }

}


Como hemos mencionado anteriormente el rol representa una parte del comportamiento de la organizacion. La restriccion HasName definida en el contexto del rol permite validar a traves de su funcion isDefined() que todos los roles definidos en la organizacion posean un nombre.

(2) El nombre de un rol debe ser unico dentro de la organizacion.
context Role {
  constraint DuplicatedName {
     guard : sef.satisfies("HasName")
     check {
        var roleList : Set( Role );
        roleList.addAll( sefeContainerO.roles );
        roleList.remove( self );
        return not roleList->exists( c | c.name = sefmame );
     }
     message : 'Duplicated role name: ' + selfname
  }

}


Ademas de la validacion presentada en el punto anterior, tambien resulta importante que en un modelo no existan duplicaciones de nombres dado que puede crear confusion para aquellos que utilizan el modelo. Esta regla posee una restriccion DuplicatedName que permite detectar dos nombre iguales de roles en la organizacion. Antes de ejecutar check, la restriccion verifica primero que a los roles se les haya asignado un nombre. En el cuerpo de la funcion se declara una lista donde se recuperan todos los roles presentes en la organizacion (menos el rol sobre el cual esta situado la regla) y se verifica, con la funcion exists(), si hay coincidencia de nombre. Si existe una coincidencia la funcion devolvera verdadero por lo que se antepone una negacion para que la condicion retorne falso y sea violada la restriccion.

Reglas asociadas a Capacidad

(3) Una capacidad debe estar referenciada al menos una vez.
context Capacity {
   constraint InsolatedCapacity {
      check {
         var capacityList : Set( Capacity );
         for ( r in Role.allInstances ) {
             capacityList.addAll( r.require );
         }
         return capacityList.includes( self);
      }
      message : 'All capacities must be referenced'

   }
}


Una capacidad es definir el comportamiento generico del rol identificado cuales son las competencias necesarias que debe tener el agente para poder tomar el rol. Un enlace entre el rol y la capacidad indica que la capacidad es requerida por el rol. La regla de validacion permite detectar aquellas capacidades que no son enlazadas con ningun roles. Usando como contexto la capacidad, primero se define un conjunto capacityList del tipo Capacity. A su vez, el lazo for permite recorrer todas las instancias que existen de Rol en el modelo y agregarla a las lista recien definida. Una vez fuera del lazo, el algoritmo verifica si la capacidad sobre la que estoy situado esta presente en la lista capacityList. En caso de que la funcion includes() retorne false, se violaria la restriccion informando al usuario que la capacidad no es referenciada o requerida por ningun rol.

(4) Las capacidades deben contener al menos una senal.
context Capacity {
   constraint HasALeastOneSignal {
      check : sefisignals.sizeO > 0
      message : 'The Capacity ' + self..name + ' must have at
      least one signal'
   }
}


En el contexto agente, los estimulos de un rol estan definidos como un conjunto de senales a los cuales el rol reacciona. Los agentes pueden disparar senales que son eventos definidos en la capacidad y que permiten comunicar resultados o el estado de la ejecucion de las tareas realizadas por la capacidad. Usando Capacidad como contexto, la restriccion HasALeastOneSignal recupera a traves de la funcion size() el numero de senales asociados a la capacidad. Si el numero es igual que cero la restriccion es falsa por lo que el usuario es notificado del error.

Reglas asociadas a Organizacion

(5) Las organizaciones deben estar compuestas por al menos un rol.
context Organization {
  constraint HasALeastOneRole {
   check : self.roles.size() > 0
    message : 'The Organization ' + sel/!eClass().name + '
    must have at least
one role'
     }
}


Una vez definido el comportamiento global y representado a traves de una organizacion, el siguiente paso es descomponer ese comportamiento es unidades mas pequenas. Cado uno de estos fragmentos identificados seran los comportamientos exhibidos por el rol. Esta regla valida que en la organizacion existe al menos un rol. Utilizando Organizacion como contexto de la regla, la restriccion HasALeastOneRole recupera, a traves de la funcion size() el numero de roles existentes en la organizacion. Si la funcion es mayor que cero la organizacion cumple con la restriccion, ahora, si el numero es igual a cero la restricciones es violada y por tanto se notifica al usuario.

(6) Las organizaciones deben contener al menos un protocolo.
context Organization {
  constraint HasALeastOneProtocol {
   check : se//.protocols.size() > 0
    message : 'The Organization ' + se/.eClass().name + '
    must have at least
one protocol'
     }
   }


El concepto del protocolo permite al disenador definir como es la interaccion entre los agentes. En otras palabras permitira detallar la secuencia de paso de informacion entre los roles participantes. La regla definida permite validar que en la organizacion exista al menos un protocolo. Usando la organizacion como contexto la regla navega a traves del atributo protocols para recuperar el numero de instancias presente en dicha organizacion. Si el numero devuelto por la funcion s/'ze() es mayor que cero la restriccion evalua a verdadero, en cambio si es igual a cero la restriccion es falso por lo tanto notifica al usuario sobre la necesidad de corregir este error.

Reglas asociadas a Interaccion

(7) Debe existir al menos una interaccion en los protocolos.
context Protocol {
  constraint HasALeastOneInteraction {
    check : sel/unteractions.size() > 0
    message : 'This protocol must have a least one
    interaction'
  }
}


Una interaccion en un Diagrama de Interaccion representa un intercambio de informacion entre dos roles. Esta informacion puede ser o un mensaje o un acto de lenguaje, entre otras posibilidades. La regla presentada en este inciso verifica que en el protocolo exista al menos una interaccion. La restriccion HasALeastOneInteraction recupera a traves de la funcion size() el numero de instancias de interacciones. Si el numero de instancias es igual a cero el usuario es notificado de que en el protocolo no existen interacciones.

(8) En una senal el origen y el destino deben ser el mismo rol.
context OnSignal {
  constraint IsTheSameRole {
    check {
  var band : Boolean = false;
  if (self orig = sef.dest) {
    band = true;
  }
  return band;
   }
   message: 'Origin a destination role must be the same'
  }
}


Tanto las senales como los llamados a capacidad son tipos especiales de operaciones que puede realizar un rol. Estos son representados como auto-mensajes que pueden o no llevar parametros de entrada o salida sea o un llamado a capacidad o una senal, respectivamente. En la condicion if la restriccion IsTheSameRole se compara que el origen como el destino sea la misma instancia del rol.

VI. Aplicacion practica

El ejemplo utilizado para mostrar la efectividad de las reglas de validacion semanticas fue presentado en (Basso, 2011). A continuacion introduciremos brevemente algunos conceptos para un mejor entendimiento del ejemplo.

En el contexto actual de la demanda electrica, las actuales redes electricas tradicionales se vieron superadas debido al incremento del consumo electrico ademas del surgimiento de conceptos y tendencias tales como generacion distribuida, aplicacion y uso de energias renovables, almacenamiento de energia, y gestion eficiente del consumo. Todo esto trajo aparejado la necesidad de administrar de manera mas eficiente la red, dando la introduccion al concepto de Smart-Grid (Cirrincione, 2009; Fang, 2012). Las Smart-Grid son, en pocas palabras, un sistema electrico funcionando en paralelo con uno sistema informatico. Estos sistemas deben ser capaces de monitorear y controlar el estado de la red a traves de diferentes dispositivos, monitores y actuadores con el objetivo de lograr una administracion mas eficiente el uso de la energia.

Otro concepto asociado a las Smart-Grid son las denominadas MicroGrid, las cuales hacen referencia a una porcion o parte de una red que puede separarse de la red de abastecimiento principal de energia. Una Microgrid esta conformada por un sistema informatico que debe ser capaz de gestionarla, un sistema de generacion de energia distribuida, un sistema de almacenamiento y por supuesto el sistema electrico que interconecte los consumidores (viviendas, negocios, edificios publicos, etc) que conforman la MicroGrid. Las Microgrid tienen la capacidad de autoabastecerse y gestionar el consumo, de tal manera que puedan funcionar independientemente de la red principal, aunque de ser necesario, pueden llegar a conectarse a esta ultima para satisfacer su demanda o tambien para proveer de energia.

Teniendo en cuenta que la tecnologia de sistemas multiagentes es utilizada mayormente para el modelado de sistemas complejos es habitual que los diagramas cuenten con un alto numero de conceptos definidos en los mismos. Por cuestiones de espacio, en la Figura 4 se presenta la organizacion MicroGrid que esta constituida por cuatro roles, tres de los cuales se encuentran asociados a la simulacion del funcionamiento de una MicroGrid (EnergyDevice, Regulator, Transmiter), mientras que el restante (TimeManager) se utiliza para administrar el tiempo de la simulacion. En mas detalle, el rol EnergyDevice representa un dispositivo que consume energia, genera o consume/genera energia en un determinado momento, tal como sucede con los sistemas de almacenamiento de energia, dado que estos consumen al momento de la carga y proveen energia en la descarga, segun la red los necesite. Por otro lado, el Transmiter cumple la funcion de simular el conductor o red a la cual se encuentra conectados los diferentes dispositivos o EnergyDevices. El Regulator tiene la funcion de regular y estabilizar la energia que se encuentra "fluyendo" por el Transmiter. Es un dispositivo del tipo monitor y regulador. Por ultimo, el TimeManager cumple con el role de ser el encargado del manejar el tiempo o velocidad actual de la simulacion que se desee ejecutar.

Las reglas de validacion sintacticas, presentadas en el apartado anterior, pueden ejecutarse en cualquier momento que el disenador crea conveniente. Para nuestro ejemplo, que es un refinamiento del modelo presentado en (Basso, 2011), se detectaron en las etapa inicial de diseno un serie de errores en las distintas organizaciones que conforman el modelo general. Los errores capturados por el modulo de validacion son presentados con el formato que muestra la Figura 4, en la misma se puede ver un circulo a las esquina superior derecha de cada concepto vertido en el diagrama (para mayor claridad se introdujeron en la figura letras por cada error), ademas de una ventana que los muestra en formato de lista.

[FIGURA 4 OMITIR]

[FIGURA 5 OMITIR]

Una vez aplicadas las reglas de validaciones sintacticas y llevado a cabo las correcciones pertinentes la organizacion MicroGrid queda tal como se muestra en la Figura 5.

VII. Conclusiones

La finalidad de este articulo es presentar un mecanismo para la validacion sintactica de modelos de sistemas multiagentes basados en el enfoque organizacional utilizando Janeiro Studio. Detectar un error en etapas tempranas y de forma automatica permitira reducir drasticamente los costos de desarrollo del sistema al mismo tiempo que se incrementa la calidad del software entregado. Este mecanismo esta compuesto por un conjunto de reglas de validacion sintactica que pueden ser definidas por el disenador. Ademas, estas reglas seran ejecutadas sobre los diferentes diagramas de manera automatizada por la herramienta de validacion.

Trabajos futuros buscaran ampliar las validaciones realizadas sobre los modelos, contribuyendo mas aun a la asistencia del disenador en el analisis, conceptualizacion e implementacion de SMA.

Referencias

Al-Hashel, E., Balachandran, B. M., & Sharma, D. (2007). A Comparison of Three Agent-Oriented Software Development Methodologies: ROADMAP, Prometheus, and MaSE. In B. Apolloni, R. J. Howlett, & L. Jain (Eds.), Knowledge-Based Intelligent Information and Engineering Systems (pp. 909-916). Springer Berlin Heidelberg.

Basso, G., Hilaire, V., Lauri, F., ROCHE, R., & Cossentino, M. (2011). A MAS-based simulator for the prototyping of Smart Grids. In 9th European Workshop on Multiagent Systems (EUMAS11).

Caire, G., Coulier, W., Garijo, F. J., Gomez, J., Pavon Mestras, J., Leal, F., ... Massonet, P. (2002). Agent Oriented Analysis Using Message/UML. In M. Wooldridge, G. Wei\s s, & P. Ciancarini (Eds.), Agent-Oriented Software Engineering II, Second International Workshop, AOSE 2001, Montreal, Canada, May 29, 2001, Revised Papers and Invited Contributions (Vol. 2222, pp. 119-135). Springer.

Cernuzzi, L., & Zambonelli, F. (2009). Gaia4E: A Tool Supporting the Design of MAS using Gaia. In ICEIS (4) (pp. 82-88). Citeseer.

Cirrincione, M., Cossentino, M., Gaglio, S., Hilaire, V., Koukam, A., Pucci, M., ... Vitale, G. (2009). Intelligent Energy Management System. In Proceedings of the IEEE indin conference.

Cossentino, M. (2005). From requirements to code with the PASSI methodology. Agent-Oriented Methodologies, 3690, 79-106.

Cossentino, M., Gaud, N., Hilaire, V., Galland, S., & Koukam, A. (2010). ASPECS: an agent-oriented software process for engineering complex systems. Autonomous Agents and Multi-Agent Systems, 20(2), 260-304.

Fagan, M. E. (1976). Design and code inspections to reduce errors in program development. IBM Systems Journal, 15(3), 182-211.

Fang, X., Misra, S., Xue, G., & Yang, D. (2012). Smart Grid--The New and Improved Power Grid: A Survey. Communications Surveys Tutorials, IEEE, 14(4), 944-980.

Ferber, J., & Gutknecht, O. (1998). A meta-model for the analysis and design of organizations in multi-agent systems. In International Conference on Multi Agent Systems, 1998. Proceedings (pp. 128-135).

Ferber, J., Gutknecht, O., & Michel, F. (2004). From Agents to Organizations: An Organizational View of Multi-agent Systems. In P. Giorgini, J. P. Muller, & J. Odell (Eds.), Agent-Oriented Software Engineering IV (pp. 214-230). Springer Berlin Heidelberg.

Gomez-Sanz, J. J., Fuentes, R., Pavon, J., & Garcia-Magarino, I. (2008). INGENIAS Development Kit: A Visual Multi-agent System Development Environment. In Proceedings of the 7th International Joint Conference on Autonomous Agents and Multiagent Systems: Demo Papers (pp. 1675-1676). Richland, SC: International Foundation for Autonomous Agents and Multiagent Systems. Retrieved from

Hilaire, V., Koukam, A., Gruer, P., & Muller, J.-P. (2000). Formal Specification and Prototyping of Multi-agent Systems. In A. Omicini, R. Tolksdorf, & F. Zambonelli (Eds.), Engineering Societies in the Agents World (pp. 114-127). Springer Berlin Heidelberg.

M. Amiguet. (2003). MOCA: un modele componentiel dynamique pour les systemes multi-agents organisationnels. Universite de Neuchatel.

McAffer, J., Lemieux, J.-M., Aniszczyk, C., & more, & 0. (2010). Eclipse Rich Client Platform (2 edition.). Upper Saddle River, NJ: Addison-Wesley Professional.

Padgham, L., Thangarajah, J., & Winikoff, M. (2005). Tool support for agent development using the Prometheus methodology. In Fifth International Conference on Quality Software, 2005. (QSIC 2005) (pp. 383-388).

Pedro Araujo, Sebastian. Rodriguez. (2013). Janeiro Studio. Presented at the CONAIISI, Cordoba, Argentina.

Picard, G., & Gleizes, M.-P. (2004). The ADELFE Methodology. In F. Bergenti, M.P. Gleizes, & F. Zambonelli (Eds.), Methodologies and Software Engineering for Agent Systems (pp. 157-175). Springer US. Retrieved from

Rodriguez, S., Gaud, N., Hilaire, V., Galland, S., & Koukam, A. (2007). An Analysis and Design Concept for Self-organization in Holonic Multi-agent Systems. In S. A. Brueckner, S. Hassas, M. Jelasity, & D. Yamins (Eds.), Engineering Self-Organising Systems (pp. 15-27). Springer Berlin Heidelberg.

Sommerville, I. (2010). Software Engineering (9 edition.). Boston: Addison-Wesley.

Susi, A., Perini, A., Mylopoulos, J., & Giorgini, P. (2005). The Tropos Metamodel and its Use. Informatica (03505596), 29(4).

Unhelkar, B. (2005). Verification and Validation for Quality of UML 2.0 Models (1 edition.). Hoboken, NJ: Wiley-Interscience.

Weiss, G. (2013). Multiagent Systems (second edition edition.). Cambridge, Massachusetts: The MIT Press.

Wooldridge, M. (2009). An Introduction to MultiAgent Systems (2nd edition.). Chichester, U.K: Wiley.

Wooldridge, M., & Jennings, N. R. (1995). Intelligent agents: theory and practice. The Knowledge Engineering Review, 10(02), 115-152.

Wooldridge, M., Jennings, N. R., & Kinny, D. (2000). The Gaia Methodology for Agent-Oriented Analysis and Design. Autonomous Agents and Multi-Agent Systems, 3(3), 285-312.

Pedro Bernabe Araujo (1) y Sebastian Alberto Rodriguez (1)

(1) Universidad Tecnologica Nacional, Facultad Regional Tucuman, Argentina.

(2) Eclipse Modeling Framework, www.eclipse.org/emf/

(3) Eclipse Modeling Project, www.eclipse.org/modeling/

(4) Object Management Group, www.omg.org

(5) Epsilon Validation Language, www.eclipse.org/epsilon/doc/evl

(6) Object Constraint Language, www.omg.org/spec/OCL/
Tabla 1--Herramientas y sus caracteristicas

                       Metodologia   Diagramas     Validacion
                                      Cubiertos        de
                                                     modelos

AgentTool III             OMASE         Todos         Todos
(Garcia-Ojeda, 2009)
GAIA4E                    GAIA          Todos          N/E
(Cernuzzi, 2009)
IDK                     Ingenias     Principales       No
(Gomez-Sanz, 2008)
PDT                    Prometheus        N/E           Si
(Padgham, 2005)
Metameth/PTK              PASSI         Todos          Si
(Cossentino, 2005)
OpenTool                 Adelfe      Principales       Si
(Picard, 2004)
Rebel                    ROADMAP     Principales       No
(Al-Hashel, 2007)
T-Tool                   Tropos      Principales       Si
(Susi, 2005)

                       Validacion    Generacion    Activo
                         entre           de
                         modelos       codigo

AgentTool III              Si            Si          Si
(Garcia-Ojeda, 2009)
GAIA4E                     N/E           No         N/E
(Cernuzzi, 2009)
IDK                        No            Si          Si
(Gomez-Sanz, 2008)
PDT                        Si            Si         N/E
(Padgham, 2005)
Metameth/PTK               Si            Si        No/Si
(Cossentino, 2005)
OpenTool                   No            N/E         No
(Picard, 2004)
Rebel                      No            No          No
(Al-Hashel, 2007)
T-Tool                     No            No          No
(Susi, 2005)

N/E--No
especifica.

Tabla 2--Ecore y sus diferentes diagramas

Ecore            Diagramas                   Descripcion

DRDMetamodel    Diagrama de     Con diagramas similares a los usados
               Requerimientos      en los CASOS de Usos de UML, es
                                 posible documentar las expectativas
                                  y necesidades de los interesados.
                                  Estos diagramas permiten capturar
                                 los requerimientos funcionales y no
                                 funcionales utilizando un lenguaje
                                 especifico del dominio provisto por
                                            los usuarios.

PODMetamodel    Diagrama de      Permite identificar, modelado como
                 Ontologias     un diagrama de clases, los conceptos,
                                predicados, y acciones relevantes del
                                    dominio. La idea principal es
                                  conceptualizar los requerimientos
                                 descriptos en el DRD o en cualquier
                                 documento que describa el sistema a
                                            desarrollarse.

Problem          Diagrama        Permite representar graficamente la
               Organizacional    estructura organizacional. La idea
                                detras de este diagrama es modelar la
                                   organizacion que represente el
                                     comportamiento global. Esta
                                representacion es realizada a traves
                                de un conjunto de roles presentes en
                                 la organizacion y de la interaccion
                                 entre ellos. La capacidad define el
                                 comportamiento que es requerido por
                                el agente para que pueda tomar el rol.
                                Los conceptos usados en este diagrama
                                 son : organizacion, rol, capacidad,
                                        protocolo entre otros.

Metamodel       Diagrama de      Describe la secuencia de intercambio
                Interaccion       de informacion entre los roles que
                                  tienen lugar en un protocolo. Los
                                  conceptos mas relevantes en este
                                    diagrama son: protocolo, rol,
                                 interaccion, callCapacity, senales,
                                            atributos, etc.

                Diagrama de      Describe el comportamiento de un rol
               Comportamiento     (la dinamica de la instancia). En
                                 otras palabras, permite representa
                                     los estados posibles y las
                                transiciones de un rol. Este diagrama
                                 es un perfil del diagrama de estados
                                                de UML.

Tabla 3--Errores detectados en la Organizacion MicroGrid

    Error detectado

A   Se detecto una duplicacion de nombres en los roles (EnergyDevice)
B   Falta nombre en un rol de la organizacion (Deberia ser Transmitter)
C   Parametros de entrada duplicado en nombre y tipo en la capacidad
    Conversion
D   Debe existir al menos un parametro de entrada en la capacidad
    Regulation
E   La capacidad Stability no es requerida por ningun rol.
COPYRIGHT 2014 Universidad de Palermo
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2014 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Bernabe Araujo, Pedro; Alberto Rodriguez, Sebastian
Publication:Ciencia y Tecnologia
Article Type:Ensayo
Date:Jan 1, 2014
Words:5731
Previous Article:Modelado y simulacion de conversion de energia eolica PMSG para sistema aislado.
Next Article:El Rol del Product Owner en la definicion y validacion de las user stories.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters