El modelo básico de la aplicación para ambas derivaciones cuenta con la representación de todos los conceptos del Modelo Navegacional y del Modelo del Usuario del enfoque. En la Figura 8.1 se puede apreciar las clases que representan los conceptos del Modelo Navegacional, este modelo se instancia (a nivel de código Java) luego con la información de un Modelo de Instancias Navegacional creado con
MagicMobileUWE.
Figura 8.1: Modelo Navegacional implementado en las aplicaciones que deriva la herramienta.
Se puede observar que el Modelo Navegacional (Figura 8.1) tiene una clase
NavigationModel que lo representa, este modelo está compuesto de concerns digitales (DigitalNavigationConcern) y un concern físico (PhysicalNavigationConcern). Cada uno de los concerns está compuesto por nodos, ya sean digitales (DigitalNode) o físicos (PhyscialNode) respectivamente. A su vez cada nodo cuenta con sus correspondientes links digitales (DigitalLink) o caminables (WalkingLink).
instanciando la clase Property (que tiene definido un nombre y un valor). Esto permite tener representado nodos que tengan propiedades con diferentes nombres.
El nodo físico tiene definido la ubicación y la operación de links caminables derivados. Por ahora están definidas dos operaciones concretas, las cuales se corresponden con los dos estereotipos provistos por la herramienta.
Para tener representado el concepto de rol, se optó por definir, a nivel del nodo digital si este es Core o no. Además, se definió la relación digitalNodeInOtherConcerns en los nodos digitales para relacionar a todos aquellos nodos que tienen un Core
común. A su vez, cada nodo digital tiene su contraparte física, como así también cada nodo físico conoce su Core (un nodo digital). Estas relaciones no solamente permiten tener representado el concepto de rol, sino que además facilitan cambiar de concern digital y pasar a ver la contraparte digital o la contraparte física de un Punto de Interés según corresponda.
La Figura 8.2 muestra el Modelo del Usuario (el cual es parte del modelo básico de la aplicación). Se puede observar que se representa con una clase al usuario, el cual cuenta con un nombre, una ubicación y la lista de aplicaciones asociadas (una de las cuales es la aplicación actual que está usando el usuario).
Cada aplicación del usuario (UserApplicationInformation) conoce una aplicación de HM concreta (MobileHypermediaApplication) junto a los historiales de navegación digital (DigitalNavigationHistory) y de navegación en el mundo real (PhsycialNavigationHistory) que se realizaron para esa aplicación. La clase
MobileHypermediaApplication conoce un Modelo Navegacional (definido en la Figura 8.1), el cual contiene toda la información que puede visualizar el usuario cuando utiliza la aplicación. Los historiales registran tanto los nodos digitales como físicos y además registran cuáles son los nodos, digital y físico, actuales que está visualizando el usuario.
Figura 8.2: Modelo del Usuario implementado en las aplicaciones que deriva la herramienta.
Además del Modelo Navegacional y el Modelo del Usuario, el modelo básico de la aplicación tiene la capa de manejo de mapas. Por ahora, esta capa está definida para proveer sólo mapas de Google Static Maps61. En el caso de querer representar
aplicaciones con otro tipo de mapa el diseñador debe modificar las aplicaciones derivadas.
En la Figura 8.3 se pueden observar las clases definidas para la capa de manejo de mapas. La clase GoogleStaticMap contiene el ubicación central que debe tener el mapa, tiene el marker (GoogleStaticMapMarker) que representa la ubicación del
61 Página de la Google Static Map API:
usuario, los markers que representan los Puntos de Interés y los caminos (GoogleStaticMapPath) a mostrar en el mapa (si es que existieran).
Además, se tienen dos clases GoogleStaticMapsAPI y GoogleDirectionsAPI que representan el principal comportamiento de la API de Google Static Map y la API de
Google Directions62 respectivamente.
Figura 8.3: Modelo para el manejo de mapas implementado en las aplicaciones que se deriva la herramienta.
Para obtener la imagen que representa la información de un mapa se debe invocar de la clase GoogleStaticMapsAPI el método getMapUrl(). Este método toma los datos del mapa (GoogleStaticMap) que le llega como parámetro y genera un String que representa la URL (Uniform Resource Locator) con la información que debe mostrar el mapa.
Luego se debe invocar (de la clase GoogleStaticMapsAPI) el método
downloadStaticMapImage()pasándole como parámetro la URL generada. Este
método realiza un requerimiento HTTP (Hypertext Transfer Protocol) con la URL (que recibe como parámetro) y obtiene como resultado la imagen63 que representa al mapa
con todos sus datos. Esta imagen es la que visualiza el usuario en la aplicación de HM.
Para la búsqueda de caminos se invoca primero el método getURL() de la clase
GoogleDirectionsAPI. Este método arma una URL que respeta la especificación de la
API para búsqueda de caminos entre dos puntos. Esta URL indica que se quiere obtener un camino entre un punto origen y un punto destino. Luego, esta URL se utiliza como parámetro del método getDirections(), el cual envía un requerimiento
HTTP con la URL y obtiene como resultado un path (GoogleStaticMapPath) con la información del camino. Para que este camino sea mostrado al usuario, se debe crear un mapa (GoogleStaticMap) y agregar este path. Luego, usando la API de Google Static Map se obtiene la imagen del mapa (el cual contiene el camino). Para esto se debe invocar el método getMapUrl()enviándole como parámetro el mapa generado (el cual contiene el camino), como resultado se obtiene una URL. A continuación se
debe invocar el método downloadStaticMapImage() de la clase
GoogleDirectionsAPI, enviándole como parámetro la URL obtenida y como resultado se obtiene la imagen del mapa. Esta imagen contiene toda la información del mapa, y además tiene dibujado el camino que debe realizar el usuario.
El modelo básico de la aplicación presentado (Figuras 8.1, 8.2 y 8.3) es utilizado por los dos tipos de aplicaciones (J2ME y Web Móvil) que deriva la herramienta.
62 Página de Google Directions API:
http://code.google.com/intl/es-ES/apis/maps/documentation/directions/ 63 Esta imagen se genera por barrido de arriba hacia abajo, en el caso de haber elementos posicionados en el mismo lugar puede que uno se superponga al otro y sólo se visualice en la imagen resultante uno de ellos.