[Jde-dev] interfaces

[David Lobato]

Hola,
Estoy terminando el asunto que tenía entre manos relacionado con los
interfaces.
Tras varias versiones preliminares y algunas dudas sobre el nombrado y
demás, creo que ahora ha quedado perfecto. Además todo es compatible hacia
atrás, por lo que no hay que cambiar nada en los esquemas que ya tenemos.
A mi parecer, las nuevas entidades que aparecen son intuitivas y creo que
facilitan el uso de jderobot (principal
objetivo). En el diagrama adjuntos "clases
análisis" se puede ver las "clases" o tipos que se relacionan con los
interfaces: JDESchema, JDEInterface, JDEInterfacePrx.

JDESchema ya lo conoceis todos, representa una instancia de un esquema
en el sistema. Los esquemas se relacionan entre sí, bien produciendo
datos o consumiéndolos,
o dicho de otro modo siministrando (supplies) y usando (uses),
respectivamente.

JDEInterface es la generalización de las estructuras de datos que usan los
esquemas para comunicarse (varcolor, motors,...). Dicha entidad es
suministrada por un esquema (supplier) y es accedida por 0 o mas esquemas
(referrals).

JDEInterfacePrx es la generalización de la asociación de uso entre un
esquema (user) y un interfaz (refers_to), y en un mero intermediario (proxy)
en dicha relación, ocultando al esquema la complejidad de acceder al
interfaz (punteros, myimport,...).

Las especializaciones Encoders y EncodersPrx serían ejemplos de interfaces.
El primero lo encontraríamos en el esquema que accede a los encoders
(player,...) y que los hace visibles al resto del sistema, y el segundo lo
encontraríamos en aquellos esquemas que usan los encoders como percepción
(folloball,teleoperador,...) o tambien en el esquema proveedor para
simplificar el acceso a la estructura de datos (los proxies tienen asociadas
una batería de funciones de acceso para cada atributo del interfaz).

Para referirnos a los interfaces usamos nombres. Hasta ahora es el que
usamos como primer parámetro de myimport/myexport, acompañado de un o varios
nombre mas que representan los atributos y funciones run/stop del interfaz.
Por ejemplo "motors" y "v", "w", "encoders" y "robot",.... Esto se mantiene
igual, aunque existe la posibilidad de registrar un interfaz del mismo tipo
mas de una vez usando diferentes nombres, por ejemplo "motorsA" y "motorsB"
en el supuesto de que tuviésemos mas de un motor en el sistema.

En este punto, surge la cuestión de varcolor, que actualmente se registra
como "varcolorA", "varcolorB",... (bien) pero que registra atributos
diferentes para cada instancia del interfaz en vez de seguir el mismo
criterio de nombrado. (para varcolorA->varcolorA, varcolorB->varcolorB, en
vez de varcolorA->varcolor, varcolorB->varcolor). Esto habrá que apañarlo de
alguna manera. La mas simple que se me ocurre y que mantiene compatibilidad
hacia atrás en que los esquemas que suministran varcolor exporten la
estructura Varcolor con el nombre "varcolor" además del de "varcolorX".

Todo lo que he comentado aquí está implementado y subido al svn. Se puede
ver en el directorio interfaces. Puesto que es C y no tenemos clases :( he
implementado las clases como structs y las relaciones de herencia se han
implementado como relaciones normales y corrientes (punteros) de la clase
especializada a la base (el diagrama clases_c muestra las asociaciones).
Además introrob2 es un ejemplo de uso de los interfaces, en cuanto tenga un
ejemplo de suministro de interfaz lo subiré.

Y hasta aquí las explicaciones... espero no haber liado mucho el asunto...

¿Preguntas? ¿Sugerencias? ¿Se entendió algo?

Un saludete,
David.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20090701/710a4d9c/attachment-0001.htm 
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : clases analisis.png
Tipo       : image/png
Tamaño     : 21795 bytes
Descripción: no disponible
Url        : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20090701/710a4d9c/attachment-0002.png 
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : clases_c.png
Tipo       : image/png
Tamaño     : 19685 bytes
Descripción: no disponible
Url        : http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20090701/710a4d9c/attachment-0003.png