Hola,<div><br></div><div>Estoy terminando el asunto que tenía entre manos relacionado con los interfaces.</div><div>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.</div>
<div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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).</div>
<div><br></div><div>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,...).</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>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".</div>
<div><br></div><div>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é.</div>
<div><br></div><div>Y hasta aquí las explicaciones... espero no haber liado mucho el asunto...</div><div><br></div><div>¿Preguntas? ¿Sugerencias? ¿Se entendió algo?</div><div><br></div><div>Un saludete,</div><div>David.</div>
<div><br></div>