[Jde-dev] interfaces

[David Lobato]

El nombre de los adjuntos está mal, perdonad, es justo al revés.
David.

2009/7/1 David Lobato <dav.lobato en gmail.com>

> 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/d597f959/attachment.htm