Exports de Visual Paradigm

[ExarcaFidalgo]

Como se ha visto en #52 , VP ya admite todos los UML que generamos a partir de nuestros ejemplos. No obstante, cuando exportamos en VP estos mismos ejemplos (como UML) no todo funciona como debería al importarlos en Shumlex.

Aquí recopilaré los errores que tienen lugar. Deben ser arreglados, naturalmente.

[ExarcaFidalgo]

• [x] Desaparece el contenido de una ShapeAnd. Por ejemplo:

  :Titanuser @:User AND {
  :titancode xsd:string;
  }

• [x] No reconoce las facetas.

  :age xsd:int MinInclusive 18 ?;

• [x] No reconoce EachOf con cardinalidad.

• [x] En el OneOf, la primera Shape no se construye correctamente.

:User {
:name xsd:string; |
(
:givenName xsd:string +;
:familyName xsd:string; );
}
Sólo se muestra :name.

• [x] No se muestran los CLOSED.

• [x] No reconoce una estructura como:

  :productId xsd:string MinLength 5 AND MaxLength 10;

• [x] Ocurre exactamente lo mismo con los OR.

[ExarcaFidalgo]

Respecto a lo del ShapeAnd: generamos las asociaciones, no a partir de la asociación como elemento independiente, sino a partir del ownedAttribute de dicha clase que referencia a la asociación.

Bien, resulta que VP no genera dicho atributo en todos los casos; sólo cuando se indica un rol en la asociación, lo cual viene a ser la inmensa mayoría de casos.

Pero en AND y OR, hacíamos una asociación AND-OR a un blanco y de ahí una asociación a cada ShapeAnd/ShapeOr... sin roles.

Ergo, puesto que no lee roles, no existe asociación para el transformador.

Dos soluciones:

1. Habilitar la búsqueda y registro de asociaciones. En cada shape, realizar una búsqueda de todas las asociaciones por si existe alguna que emplee ese ID. Realizar búsqueda del subconjunto al que apunta para extraer sus atributos.
2. Poner nombre a estas asociaciones.

La elección es obvia.

[ExarcaFidalgo]

Poner nombre a todas las asociaciones que estaban en blanco soluciona todos los problemas relativos a ShapeAnd, ShapeOr, OneOf, EachOf.

[ExarcaFidalgo]

El resto de problemas son relativos a cómo trata las Constraints Visual Paradigm en el export.

Veréis, en el caso de las facetas, la restricción se genera como:

<ownedRule constrainedElement="Tp2AtU6GAqACHRJj" name="MinLength 3" xmi:id="kbc1eo8p"> <xmi:Extension extender="Visual Paradigm">
<qualityScore value="-1"/>
</xmi:Extension>
</ownedRule>

El problema es que el ID al que apunta el ConstrainedElement, que sería el del OwnedAttribute de turno, no existe. Curiosamente, mantiene para dicho atributo el ID que le asignamos nosotros en la generación de XMI... pero a la hora de resolver esta dependencia, emplea uno propio. Es sumamente estúpido, pero no funciona.

Aún es recuperable, porque en el LowerValue del atributo aparece dicho ID. Pero es, cuanto menos, escasamente ideal.

Situación similar en el CLOSED, que en lugar de apuntar a un atributo, apunta a la clase. Con la salvedad de que en este caso no queda vestigio alguno del ID que hay en constrainedelement.

Conociendo el problema, es cuestión de tiempo que ceda ante mi justa ira.

[ExarcaFidalgo]

Parece que está todo en su sitio. No puedo comprobarlo ahora en profundidad, pero parece prometedor. Creo que hemos acabado con la interoperabilidad. Cuando tenga algunas horas de sueño, lo comprobaré más exhaustivamente. Por ahora, lo cierro.