5 ESPECIFICACIÓN DE LOS MODELOS PROPUESTOS
5.7 Modelo de Presentación
Hasta el momento los modelos que se venían presentando no involucraban ninguna relación con la forma de implementarlos. Sin embargo el Modelo de Presentación está ligado íntegramente con la implementación final que tenga la aplicación. Por esta razón, pueden existir varios Modelos de Presentación asociados a un mismo Modelo Navegacional. En rasgos generales este modelo representa la visualización que tiene cada nodo del Modelo Navegacional.
Para esta tesis se presenta un Modelo de Presentación particular a fin de mostrar el enfoque en forma completa. Se necesita representar el concepto de concerns (digitales y físico) los cuales contengan presentaciones de nodos. Para esto se debe tener un estereotipo particular indicando si se agrupan presentaciones de nodos digitales o físicos. Por lo tanto, creamos dos estereotipos de Package [UML Superstructure] uno denominado <<digitalLayout>> y otro <<physicalLayout>> como se puede visualizar en la Figura 5.9.
Figura 5.9: Estereotipos para los concerns del Modelo de Presentación.
Con estos dos estereotipos (<<digitalLayout>>y <<physicalLayout>>) se pueden representar los concerns necesarios para la visualización. Cada nodo va a tener definido una presentación particular: para poder representar está semántica se crearon dos estereotipos de clases, un estereotipo <<navigationClassLayout>> para representar la presentación de los nodos digitales, y otro estereotipo
<<physicalNodeLayout>> para representar la presentación de los nodos físicos,
como se puede visualizar en la Figura 5.10.
Figura 5.10: Estereotipos para las clases del Modelo de Presentación.
Estos dos estereotipos (<<navigationClassLayout>> y <<physicalNodeLayout>>) tienen definidos dos valores etiquetados. Uno de los valores etiquetados se denomina node
,
el cual se utiliza para definir el nodo al que se le está definiendo la presentación.El otro valor etiquetado asociado a estos estereotipos, se denomina hasStyleheet, el cual representa un valor boolean indicando si se definió o no un estilo de presentación asociado al nodo. Inicialmente, cuando se define la presentación asociada al nodo el valor etiquetado (hasStyleheet) es falso y cuando se define una presentación determinada este valor pasa a ser verdadero.
En la Figura 5.11 se puede ver un Modelo de Presentación donde sólo se detalló la clase de presentación que se corresponde a cada nodo navegacional (presentado en la Figura 5.5). Se puede ver que el valor etiquetado node de todas las clases tiene un valor definido, mientras que el valor etiquetado hasStyleheet tiene para todas las clases valor falso, ya que las clases todavía no tienen un estilo definido. También se puede observar en este Modelo de Presentación, el uso de los estereotipos definidos tanto a nivel de concerns (paquetes) como a nivel de presentación de nodo (clases). Se puede apreciar en la Figura 5.11 que cada nodo tiene su presentación asociada, esto permite que, si un Punto de Interés está representado en más de un concern digital, para cada concern pueda tener una visualización diferente del mismo. De esta manera si un nodo tiene propiedades particulares en el Modelo de Presentación, se expresa cómo se debe visualizar cada una.
Figura 5.11: Modelo de Presentación.
Es muy probable que en la mayoría de las aplicaciones, la visualización de los nodos digitales vaya a diferir de los nodos físicos. Hay que tener en cuenta que todas las instancias de un mismo nodo se van a mostrar de la misma manera, ya que la presentación está asociada al nodo. Si se quieren lograr presentaciones distintas de un mismo nodo, se debe definir distintos Modelos de Presentación.
Para el Modelo de Presentación particular especificado en esta tesis se eligió definir la presentación asociada a cada nodo mediante un archivo XSLT32 (Extensible
Stylesheet Language Transformation) que define cómo se muestran los datos. Es decir, a cada clase de presentación se le asocia un archivo XSLT33 que define cómo
se muestra el nodo.
32 Página de la W3C que define XSLT: http://www.w3.org/TR/xslt.
33 Asociada a cada archivo XSLT se tiene un archivo DTD (Document Type Definition), el cual define la estructura que tienen los elementos que toma el template como parámetro.
XSLT es un estándar definido por la W3C (World Wide Web Consortium)34 que se
puede ver como una hoja de estilo. Tiene parámetros que se deben de ingresar para luego derivar la salida (presentación de los datos ingresados como parámetros). En nuestro caso, al XSLT se le pasan como parámetro los datos del nodo para generar como salida la visualización de los mismos, según como esté definida la estructura interna del archivo XSLT.
La clase de presentación debe indicar para cada uno de los parámetros del XSLT, con qué valor del nodo se debe completar. De esta manera utilizando esta especificación del Modelo de Presentación se puede mostrar cada nodo según cómo se haya especificado el archivo XSLT correspondiente.
A modo de ejemplificar la presentación de un nodo usando XSLT nos focalizamos en un nodo particular del modelo navegación, por ejemplo, el nodo Church del concern arquitectural.
Supongamos que se define un archivo XSLT que tiene tres parámetros nombrados como nameNode, descriptionNode y link. Estos tres parámetros deben de ser definidos como propiedades de la clase de presentación del nodo como se muestra en la Figura 5.12. Para cada una de estas propiedades, se debe especificar un String que representa el nombre de la propiedad del nodo de donde se toman el dato para “enviar” como parámetro.
En la figura se puede ver cómo el parámetro nameNode se completa con el valor que tenga definido el nodo en la propiedad name; por otro lado descriptionNode se especifica con el valor que tenga el nodo en la propiedad description. El último parámetro es link, el cual toma como valor todas las relaciones definidas con el estereotipo <<navigationLink>>
.
Las definiciones de las clases de presentación se realizan todas de esta manera.Figura 5.12: Relación entre la presentación y el nodo Church del concern arquitectural.
Si un nodo tiene más propiedades que otros nodos, esto está contemplado por la clase de presentación, la cual tendrá un archivo XSLT con la cantidad de parámetros adecuados. Lo mismo pasa a nivel de nombre de propiedades, como la clase de presentación define para cada parámetro con qué propiedad del nodo se debe completar, esto permite dinamismo a nivel de la presentación asociada a cada nodo. Permitiendo variar y adecuar la presentación a las características de cada nodo. En la Figura 5.13 se puede apreciar la clase de presentación asociada al nodo Church
del concern histórico. Comparando las Figuras 5.12 y 5.13 se puede distinguir que la clase de presentación de la Figura 5.13 tiene que definir un parámetro más respecto del nodo Church del concern arquitectural, ya que el mismo contiene más información. También se puede apreciar que cambia el XSLT asociado a la clase de presentación.
Figura 5.13: Relación entre la presentación y el nodo Church del concern histórico.
El archivo XSLT va a definir cómo se va a mostrar la información asociada al nodo ya sea a nivel de propiedades como de links. El XSLT asociado puede ser tan complejo como sea necesario según la aplicación que se este modelando. Para los nodos físicos, el diseñador debe especificar un XSLT que considere, por ejemplo, la visualización de los links caminables predefinidos como así también los links caminables derivados (siempre que el nodo tenga definida la operación que los calcula).
Los estereotipos definidos para este modelo son agregados a un nuevo perfil denominado Layout (ver Figura 5.14), de esta manera este perfil puede extenderse de manera independiente del resto de los perfiles que se presentaron en la Sección 4.2.
Figura 5.14: Perfil Layout y los estereotipos que contiene.
El nuevo perfil Layout es importado por el perfil Mobile Hypermedia para lograr un único perfil, que contenga los elementos necesarios para poder crear todos los modelos del enfoque. Con esta importación el perfil Mobile Hypermedia queda conformado como se muestra en la Figura 5.15.
Figura 5.15: Perfil Mobile Hypermedia con la importación del perfil Layout.
El Modelo de Presentación detallado en esta sección es una posible implementación, pueden surgir otros tipos de presentación en futuras evoluciones de nuestro enfoque. Es decir, el perfil de Layout puede variar o volverse más complejo, tanto como sea
necesario. Mientras el nombre del perfil (Layout) se mantenga, esta evolución no afecta la importación realizada por el perfil MobileHypermedia.