Aplicación de patrones MVC y PAC en

aplicaciones móviles
Introducción
La construcción de sistemas software interactivos con múltiples tipos de interfaces de
usuario es cara y sujeta a errores, cuando la interfaz de usuario está íntimamente
entrelazada con el núcleo funcional. En este caso, una aplicación separada es hecha cada
tipo de interfaz de usuario y el código específico de la interfaz se duplica en cada aplicación.
Esto resulta en esfuerzos duplicados en la implementación, que de acuerdo a [1]
generalmente resulta en estilo "copiar y pegar". Por supuesto, la mayor complejidad de
implementación se transfiere a la creciente complejidad de las pruebas y el mantenimiento,
y también es sabido que la actualización de las copias es inevitablemente imperfecta.
"Lentamente, pero seguramente, aplicaciones que proporcionan el mismo núcleo funcional
se está desarrollando en varios sistemas" [1]. El resultado es la expansión de futuros
cambios en muchos módulos.
Sin embargo, los problemas mencionados anteriormente pueden evitarse. separando las
tareas de la interfaz de usuario de las del núcleo funcional. Al resolver este problema, dos
patrones de software pueden ser utilizados y están relacionados con la forma de construir el
Interfaz de usuario de la aplicaciones. Estos son el patrón Modelos-Vista-Controlador
(MVC) y Presentación-Abstracción-Control (PAC). La siguiente sección de este documento
definirá el problema. de elección entre el patrón de software MVC y PAC cuando diseñamos
aplicaciones móviles. La tercera y cuarta sección mostrarán información de la literatura
sobre estos patrones de software. La quinta sección establecerá la conexión. entre las
condiciones que enfrenta la aplicación móvil y la selección de un patrón de software
particular para la arquitectura de la interfaz de usuario.
Al definir el conjunto de requisitos antes de las aplicaciones móviles, empezamos desde una
visión de computación generalizada que le permite a los usuarios acceder a las aplicaciones
y datos relevantes desde cualquier dispositivo, de una forma que es adaptada al usuario y a
la tarea que actualmente realiza. Las características fundamentales de las aplicaciones
generalizadas (pervasive) son la movilidad y el conocimiento del contexto. Una
consecuencia de la movilidad es que las aplicaciones deben funcionar en varios tipos de
dispositivos, incluyendo dispositivos instalados en diferentes entornos y dispositivos que los
usuarios llevan con ellos [3]. La necesidad de tener en cuenta el contexto surge desde el
requerimiento de utilizar la aplicación en contextos que son diferentes en comparación con
la estación de trabajo informática con teclado, mouse y pantalla. Los usuarios de
aplicaciones de computación generalizada están típicamente enfocados en otra tarea, y no
en el uso del dispositivo de computación móvil, e incluso puede que no sepan que usan un
dispositivo informático. Las aplicaciones deben adaptarse para interactuar con el usuario de
una manera que sea apropiada para el contexto del usuario actual y las actividades, deben
sacar ventaja del equipo disponible localmente, sin molestar al usuario en la realización de
su tarea actual [4].
Consideremos un ejemplo de una aplicación de calendario generalizado (pervasive) que
debe tener las siguientes propiedades. Primero la aplicación podrá ejecutarse en múltiples
plataformas, desde un teléfono en red (con interfaz de usuario limitada, pero aún así
conectado) hasta el asistente digital personal, PDA con una interfaz de usuario más rica y
más grande y un ancho de banda mayor, pero no siempre vinculado, al ordenador interior
(con una interfaz de usuario rica y un un gran ancho de banda y que siempre está
conectado). Además, el usuario podrá interactuar con la aplicación usando múltiples
modalidades de interfaz, como la interfaz gráfica de usuario. (GUI), interfaz de voz o una
combinación de estos dos. Segundo, La aplicación será sensible al entorno en el que se
encuentre. por ejemplo, en casa, la aplicación muestra el calendario familiar por defecto. si
la aplicación se utiliza en la oficina y si el usuario es retrasado para la próxima reunión, la
aplicación puede mostrar el calendario de negocios con información sobre su próxima
reunión, incluso haciendo énfasis en esta información.
Las capacidades de la interfaz de usuario incluyen capacidades de salida (por ejemplo,
tamaño y color); capacidades de entrada, tales como el número de botones, scrollers y otros
controles, así como accesorios software disponibles para manipular las capacidades de
entrada y salida. Es necesario reescribir el componente de vista para cada dispositivo
debido a las diferencias en estas capacidades de un dispositivo a otro. En algunos casos, la
estructura de Vistas también influirá en la estructura del Controlador.

Patrón de Software "MODELO-VISTA-

CONTROLADOR” - MVC
De acuerdo con el patrón de software MVC, la aplicación debe tener al menos tres
componentes. El componente del modelo Incluye el núcleo de datos de la aplicación y la
funcionalidad del dominio lógico. La Vista obtiene datos del Modelo y se los muestra al
usuario. El controlador recibe y interpreta la entrada dentro de los requisitos para el Modelo
o la Vista.
Uno de los primeros usos del patrón de software MVC en aplicaciones de software
orientado a objetos, se dío en el lenguaje de programación SmallTalk. La descripción de las
tareas de los componentes específicos en esta implementación y la forma de coordinación
mutua se da en [2].
El modelo representa los datos del dominio del problema para la que la aplicación está
destinada y las reglas de negocio que rigen el acceso y actualización de los datos. Dado
que el modelo debe ser independiente, no puede tener una referencia ni a la Vista ni a
cualquier parte del Controlador de la aplicación.
El componente Vista es responsable de presentar Información al usuario. Diferentes vistas
representan información del modelo de diferentes maneras. Cada Vista define el
procedimiento de actualización de la visualización de la información al usuario, que se
activa por el mecanismo de propagación del cambio. Cuando tal procedimiento es invocado,
la vista busca el valor actual de los datos que mostrará desde el Modelo y los pone en la
pantalla. Durante la inicialización, todas las vistas se unen/suscriben al modelo y son
registradas por el mecanismo de propagación del cambio. Cada Vista crea un Controlador
apropiado y un Controlador coincide una Vista. Las vistas a menudo proporcionan una
funcionalidad que permite a los Controladores manipular la pantalla. Es utilizable para las
operaciones iniciadas por el usuario que no afecten al Modelo, como el desplazamiento
(scrolling), por ejemplo.
La consistencia de las Vistas con el Modelo se proporciona de una forma que las clases del
Modelo definen el mecanismo de notificación del cambio, usualmente utilizando el patrón
Observer que se aplica. muy bien en Smalltalk. Esto le permite a la vista y al controlador ser
informados sobre los cambios en el Modelo. Ya que estos componentes se registran con el
Modelo y el Modelo no tiene conocimiento de ninguna Vista particular o Controlador, no
viola la independencia del Modelo. El mecanismo de notificación es el que permite la
inmediata. actualización, que es característica de la aplicación MVC en la interfaz gráfica de
usuario. La Vista obtiene datos del Modelo y los muestra al usuario. La vista representa la
salida de la aplicación y refleja el contenido del modelo. La vista accede a los datos de la
aplicación a través del Modelo y especifica la manera en el que deben mostrarse los datos.
La responsabilidad del Modelo es mantener la consistencia de la presentación con los
cambios del Modelo. El controlador transfiere interacciones con el usuario en las acciones a
realizar por el Modelo. En el Cliente GUI independiente, las interacciones del usuario
pueden ser un clic de un botón o una opción de menú, mientras que en la aplicación Web
aparecen como peticiones GET y POST. Acciones realizadas por el Modelo incluyen la
activación de procesos de negocio o cambios. del estado del modelo. El Controlador
responde eligiendo la Vista apropiada basada en las interacciones del usuario y salidas de
la acciones realizadas por el Modelo.
La Vista generalmente tiene acceso libre al Modelo, pero debe puede cambiar el estado del
Modelo. La Vista lee los datos del Modelo utilizando un método de consulta cuya ejecución
es proporcionada por el Modelo.
El componente Controlador acepta la entrada del usuario como eventos. La forma de
entrega de eventos hacia el Controlador depende de la plataforma de interfaz de usuario.
Por simplicidad, permítame asumir que cada controlador implementa un procedimiento para
manejo de eventos que se llaman para cualquier evento relevante. Los eventos se traducen
en peticiones en el Modelo o en las Vistas asociadas. Si el comportamiento del controlador
depende del estado del Modelo, el controlador se registrará con el mecanismo de
propagación de cambios e implementará el procedimiento de actualización. Por ejemplo,
esto es necesario cuando el cambio al Modelo permite o impide un elemento en el menú. El
diagrama de clases de la Figura 1 y el diagrama de secuencia de la Figura 2 muestran la
aplicación de los patrones arquitectónicos MVC en una Aplicación implementada en Java 2
Mobile Edition. La aplicación consta de un MIDlet representado por el controlador [5], la
clase Vista y la clase Modelo. Sobre el inicio de la aplicación, el controlador crea instancias
de Modelos y Vistas. Las Vistas luego se registran con el Modelo. La clase Controlador
acepta comandos de usuario y llama a las operaciones para actualizar datos. en el Modelo.
Luego, usando el patrón Observer, el Modelo llama. el método update() de todas las Vistas
registradas para reflejar en las Vistas todos los cambios que se hicieron en el Modelo.
En el patrón MVC, el controlador no es un intermediario entre vistas y modelos, y no se
sitúa entre Modelos y vistas. La separación de las tareas de los Modelos. y las Vistas se
pueden lograr usando el patrón Observer, no a través del Controlador [6].
La separación de los aspectos de control de las vistas, permite la combinación de varios
controladores diferentes con una sola vista. Esta flexibilidad puede ser utilizada para
implementar diferentes modos de operación. como, por ejemplo, "usuario principiante" frente
a "usuario experto", o para diseñar una vista de solo lectura utilizando un Controlador que
ignora cualquier entrada.

Beneficios de MVC
La aplicación de patrones MVC permite múltiples vistas sobre un modelo único. MVC
separa estrictamente el Modelo de los componentes de interfaz de usuario y por lo tanto
múltiples Vistas pueden ser Implementadas y usar un único Modelo. Durante la ejecución,
se pueden abrir varias vistas al mismo tiempo, y las vistas también se puede abrir y cerrar
dinámicamente. Segundo, MVC Permite la sincronización de la Vista. Los mecanismo de
propagación del cambio en el Modelo disponen que todas las vistas registradas con el
objeto "observador" son notificadas sobre los cambios de datos de la aplicación,
exactamente a tiempo Esto permite la sincronización de todos las Vistas y Controladores
dependientes. MVC también permite la creación de Vistas y Controladores "conectables". La
separación conceptual de MVC permite encontrar un reemplazo para un objeto Vista y
Controlador. Los objetos de Interfaz de Usuario pueden incluso ser reemplazados durante el
tiempo de ejecución. El cuarto beneficio se relaciona con la posibilidad del cambio del "look
and feel" de las características de la interfaz de usuario. Ya que el modelo es independiente
del código de la interfaz de usuario, la transferencia de la La aplicación MVC a una nueva
plataforma no afecta el núcleo funcional de la aplicación. Sólo se requieren
implementaciones apropiadas. de las vistas y controladores.

Desventajas del patrón MVC

El monitoreo estricto de la estructura MVC no siempre es la mejor manera para construir
una aplicación interactiva debido a que el uso separado de Modelos, Vistas y Controladores
para los menús. y los elementos de texto simples aumentan la complejidad sin obtener
mucha flexibilidad El uso de este patrón también crea el potencial de un número excesivo
de actualizaciones. Si las acciones de un usuario resultan en muchas actualizaciones, el
Modelo debe omitir el Notificación innecesaria de cambios. El caso puede ser que todas las
vistas no están interesadas en la propagación de todos los cambios en el Modelo. Por
ejemplo, la vista con la ventana y los iconos. puede no necesitar ser actualizada siempre
que su ventana no sea restituida a su tamaño normal. La falta de cercanía entre vistas. y los
controladores es también una desventaja porque previene su uso específico No es probable
que la vista se use sin su controlador, o viceversa, con la excepción de Vistas de "solo
lectura" que comparten un controlador común que ignora todas las entradas en el evento de
operación con Vistas de "solo lectura". Además, hay una estrecha conexión entre la vista y
el controlador con el modelo. Tanto la vista como el controlador hacen llamadas directas al
modelo. Esto implica que los cambios en la interfaz del modelo probablemente rompan el
código de la vista y el controlador. Este problema se incrementa si el sistema utiliza un gran
número de vistas y controladores. La inevitabilidad de los cambios. en los componentes
Vista y Controlador también aparece como Ventaja, en su traslado a otra plataforma. Toda
dependencia de la plataforma de interfaz de usuario está encapsulada. dentro de los
componentes Vista y Controller. Sin embargo, ambos componentes también contienen el
código que es independiente de plataformas específicas. La transferencia del sistema MVC
requiere la separación de código dependiente de la plataforma antes de volver a reescribir,
para encapsular dependencias de la plataforma.

Patrón de Software "Presentación - Abstracción -

Control" - PAC
El patrón de diseño PAC se basa en el concepto de agentes que cooperan, los cuales se
organizan en una estructura jerárquica. Cada agente es un aspecto unitario del sistema, que
funciona como un nodo. en la jerarquía de agentes y consiste de los componentes de
presentación, abstracción y control. Según este patrón, los sistemas interactivos se
componen de agentes cooperativos. Un tipo de agente especializado en la interacción
hombre-computadora acepta la entrada del usuario y muestra los datos. Otros agentes
mantienen el modelo de datos del sistema y proporcionan la funcionalidad basada en dichos
datos. Agentes adicionales son responsables de diferentes tareas como la gestión de
errores o la comunicación con otros sistemas de software.
Este patrón de diseño ha surgido bajo la influencia de la siguientes circunstancias [2]:
● Los agentes a menudo tienen la necesidad de mantener su propio estado. y datos.
Para garantizar la ejecución de todo la tarea de la aplicación, los agentes deben
cooperar efectivamente, lo cual requiere un intercambio de datos, mensajes y
eventos.
● Los agentes interactivos proporcionan su propia interfaz de usuario, ya que su
interacción humano-computadora a menudo difiere mucho.
● Los sistemas se desarrollan contra el tiempo. Su aspecto de presentación es
particularmente sujeta a cambios. Además, los cambios a agentes individuales o la
expansión del sistema con nuevos agentes, no debe afectar a todo el sistema.
La solución está en la estructuración de aplicaciones interactivas. en la forma de un árbol
cuyos nodos son agentes PAC. Debe existir un agente superior, algunos agentes de nivel
medio y algunos más agentes en la parte inferior de la jerarquía. Cada agente es
responsable de cierto aspecto de la funcionalidad de la aplicación y consta de tres
componentes: presentación, abstracción y control. La jerarquía entera refleja dependencias
transitivas entre agentes. Cada agente depende de los agentes de nivel superior en la
jerarquía, hasta el agente superior.
El componente de presentación proporciona un Comportamiento visible del agente PAC. El
componente de abstracción mantiene el modelo de datos que está por debajo del agente y
proporciona la funcionalidad que trabaja con dichos datos. El componente de Control enlaza
los componentes de Presentación y Abstracción. y proporciona una funcionalidad que le
permite al agente comunicarse con otros agentes PAC [7].
El agente superior PAC proporciona el núcleo funcional de la sistema. La mayoría de los
otros agentes de PAC dependen u operan con tal núcleo. Los agentes PAC de nivel más
bajo son conceptos semánticos con los cuales los usuarios del sistema pueden operar.
Además, ellos soportan todas las operaciones que los usuarios pueden realizar con tales
conceptos. Los agentes PAC de nivel medio son combinaciones o conexiones entre agentes
de nivel inferior. Por ejemplo, el agente de nivel medio puede mantener varias vistas con los
mismo datos.

Estructura
La principal responsabilidad del agente PAC de nivel superior es proporcionar un modelo de
datos global para el software. Esta tarea es realizada por el componente de abstracción en
el agente superior. La interfaz del componente de abstracción proporciona funciones para
manipulación con el modelo de datos y para búsqueda de información. La representación de
datos dentro del componente Abstracción debe ser independiente del medio que soporta la
adaptación del agente PAC para diferentes entornos sin cambios mayores en su
componente de abstracción.
El componente de presentación de un agente de alto nivel a menudo tiene varias
responsabilidades Puede incluir elementos de la interfaz de usuario que son comunes a
toda la aplicación. En algunos sistemas, la el componente de presentación no existe.
El componente de control del agente superior de PAC tiene tres responsabilidades:
● Permite a los agentes de nivel inferior utilizar los servicios del Agente de alto nivel,
principalmente para el acceso y manipulación del modelo de datos global. Requisitos
de servicio de entrada de los agentes de nivel inferior son pasados a cualquier
componente de Abstracción o Presentación.
● Coordina la jerarquía de agentes PAC. Mantiene Información sobre las relaciones
entre los agentes superiores y agentes de nivel inferior. El componente de control
utiliza esta información para proporcionar la cooperación correcta e intercambio de
datos entre los agentes de alto nivel y los agentes de nivel inferior.
● Mantiene información sobre la interacción del usuario con el sistema. Por ejemplo,
puede comprobar si una operación determinada se puede realizar con el modelo de
datos cuando es iniciado por el usuario. También puede realizar un seguimiento de
las funciones. que se llaman para provisionar historia y el servicio de
deshacer/rehacer para operaciones con el núcleo funcional.
Los agentes PAC de bajo nivel son conceptos semánticos específicos del dominio de la
aplicación, que puede ser tan bajos como un simple objeto gráfico, por ejemplo un círculo, o
tan complejo como un gráfico de barras que dan una vista de resumen de todos los datos
en el sistema.
El componente de presentación del agente PAC más bajo es una Vista especial del
concepto semántico correspondiente y proporciona acceso a todas las funciones que los
usuarios pueden aplicar. Internamente, el componente de presentación también mantiene
información sobre la vista, como la posición en la pantalla.
El componente de Abstracción del agente PAC nivel más bajo tiene una responsabilidad
similar a la del componente de Abstracción en el agente PAC de más alto nivel,
manteniendo información que es específica para el agente. Contrariamente al agente de
Abstracción de nivel superior, otros agentes PAC no dependen de dichos datos.
El componente de Control del agente PAC de bajo nivel mantiene la consistencia entre la
Abstracción y la Presentación, evitando así una dependencia directa entre ellos. Sirve como
el adaptador y ejecuta la adaptación tanto de la interfaz. y los datos. Este componente de
los agentes PAC de nivel más bajo se comunica con agentes de nivel superior para
intercambiar. eventos y datos. Eventos entrantes, como las solicitud de "cerrar ventana" - se
envían al componente de presentación del agente de nivel bajo, mientras que los datos
entrantes se envían a su componente de abstracción. Los eventos salientes e información
de error. se envían a un agente asociado de nivel superior [8].
Los agentes PAC de nivel superior no se limitan sólo a proporcionar conceptos semánticos
del dominio de la aplicación. Los agentes también se pueden especificar para implementar
servicios del sistema por ejemplo, el agente de nivel superior puede ser el agente de
comunicación lo cual le permite al sistema cooperar con otras aplicaciones. y supervisar la
cooperación.
Los agentes PAC de nivel medio pueden cumplir dos funciones diferentes: La composición y
coordinación. Cuando, por ejemplo, cada objeto en una aplicación gráfica compleja es
presentado por un agente PAC separado, los grupos de agentes de nivel medio agrupan
tales objetos para formar un objeto gráfico compuesto. Otro papel del agente de nivel medio
es mantener la coherencia entre los agentes de nivel inferior, por ejemplo, al llevar a cabo la
coordinación de múltiples vistas sobre los mismos datos.
Las interfaces de los agentes PAC se diseñan utilizando el patrón "Componer mensaje”.
Todas las solicitudes del servicio de entrada, eventos y datos son procesados ​por una
función llamada receiveMsg(). La cual interpreta los mensajes y los encamina a su
destinatario, el cual puede ser un agente de abstracción o componente de presentación u
otro agente. Del mismo modo, la función sendMsg () se utiliza para el empaquetado y
entrega de eventos, datos y solicitudes de servicios a otros agentes El patrón de diseño
PAC se puede utilizar en el diseño de Aplicaciones móviles sensibles al contexto en el
dominio de PIM (Gestión de Información Personal), que además de la entrada de usuario
que viene a través del teclado del teléfono, es necesario aceptar llamada entrantes como un
evento de entrada. A través del controlador, cada evento de entrada provoca la realización
de las acciones en el modelo y la consiguiente actualización de la Vista. La plataforma
J2ME no ofrece APIs para controlar la comunicación por voz y si queremos acceder a estas
funciones del teléfono en términos de programación, es necesario utilizar aplicaciones
nativas. Por lo tanto, es necesario lograr la comunicación entre el código de Java 2. ME y el
código de programación nativo.
En el sistema operativo Symbian para teléfonos móviles podemos usar los sockets como
mecanismo de comunicación. Usando el Patrón de diseño PAC, se utilizará este mecanismo
de comunicación para la comunicación entre agentes, a saber, sus componentes de
Control. La interfaz de aplicación de usuario es un agente de nivel Superior cuya función es
coordinar agentes subordinados y el acceso al modelo de datos común y el comportamiento
del sistema. Uno de los agentes subordinados acepta entrada de usuario desde el teclado y
otro agente acepta llamadas entrantes. Cada uno de los agentes subordinados participan en
la actualización de las vistas. Dada la estructura del agente PAC, los controladores de
comunicación pueden actuar como clientes y como servidores. por lo tanto el controlador
debe tener dos hilos, uno para aceptar Comunicaciones de otros controladores y una para
iniciar. Comunicación con otros controladores. El diagrama de clase en La figura 3 y el
diagrama de secuencia de la figura 4 muestran la solución propuesta.

Beneficios
El primer beneficio es la separación de tareas. Los diferentes conceptos semánticos en el
dominio de aplicación son presentados por agentes separados. Cada agente mantiene su
propio estado y datos, coordinado con, pero independientemente de los otros agentes PAC.
Los agentes individuales PAC también ofrecen su propia interacción humano-computadora
Esto permite el desarrollo de modelos de datos dedicados para concepto semántico o tarea
dentro de la aplicación independientemente de otros conceptos semánticos o tareas.
Segundo, el patrón PAC proporciona soporte para el cambio y la expansión. Los cambios en
los componentes de Presentación o Abstracción del agente PAC no afectan a otros agentes
en el sistema. Esto permite modificaciones del modelo de datos en la base del agente PAC
o la modificación de su interfaz de usuario, por ejemplo, desde el Shell de Comandos en los
menús y diálogos. Además, nuevos agentes se integran fácilmente en la arquitectura PAC
existente sin grandes cambios de los agentes PAC existentes. Todos los agentes PAC se
comunican entre ellos a través de interfaces predefinidas. Además, los agentes existentes
pueden registrar dinámicamente el nuevo Agentes PAC para proporcionar comunicación y
cooperación.
Funcionalidad para administrar el nuevo agente PAC, como un mecanismo de coordinación
de vistas y cambios y propagación de eventos. ya existen. El modo de coordinación de los
agentes en el patrón PAC proporciona una buena base para la multitarea. Los agentes PAC
pueden ser fácilmente distribuidos a diferentes hilos, procesos o máquinas. Extensión de
agentes PAC con la funcionalidad apropiada para la cooperación entre procesos solo afecta
su componente de control.

Desventajas
Las desventajas del patrón PAC se reflejan en la Mayor complejidad del sistema. La
implementación de cada concepto semántico en su propio agente PAC puede resultar en
una estructura complejo del sistema. Si algún objeto gráfico, como círculo y rectángulo, se
implementa como un agente PAC separado, el sistema se ahogará en un mar de agentes.
Los agentes también deben ser coordinados. y controlados, lo que requiere de agentes
coordinadores adicionales. El nivel de granulación de diseño debe ser considerado
cuidadosamente y también el punto donde detenerse con la disolución de agentes en un
número creciente de agentes de nivel más bajo.
En el sistema PAC, los componentes de control son mediadores de la comunicación. Entre
los componentes de abstracción y presentación del agente y entre diferentes agentes PAC.
La calidad de implementación del componente de control es por lo tanto crítico tanto para la
cooperación efectiva entre los agentes y la calidad de la arquitectura del sistema entero. Los
roles individuales del componente de control deben ser estrictamente separados unos de
otros. La implementación de estos roles. no debe depender de los detalles específicos de
otros agentes, tales como sus nombres específicos o ubicaciones físicas en el Sistema
distribuido. La interfaz del componente de control debe ser independiente de los detalles
internos con el fin de asegurar que los agentes asociados no dependan de las interfaces
específicas de sus componentes de presentación o abstracción. La Responsabilidad del
componente de control es realizar cualquier adaptación de interfaces. o los datos.
Tareas adicionales relacionadas con la comunicación entre los agentes PAC pueden afectar
la eficiencia del sistema. Por ejemplo, si el agente más bajo lee los datos del agente
superior, todos los agentes que están en el camino de la más baja a la más alta en la
jerarquía del PAC se incluye en este intercambio de datos. Si los agentes están distribuidos,
la transferencia de datos también requiere cooperación entre procesos, que incluye una
serie de acciones que cargan el sistema de comunicación.

Técnicas para cumplir con las Nacientes

demandas de la Movilidad
El principal problema que surge con el creciente número de plataformas y modalidades de
interacción es la necesidad de crear más componentes de presentación de aplicaciones. Un
enfoque para evitar un aumento en los componentes de presentación que deben ser
desarrollados por los programadores es la transcodificación de presentaciones. [3]. La idea
básica en la transcodificación es la reutilización de la Vista para otro dispositivo mediante el
uso de un Transcodificador automatizado que realiza su transformación durante la
ejecución. La técnica de transcodificación se centra en la separación de la información
desde la vista para crear un formato indirecto que pueda ser utilizado para la producción de
otras vistas. El proceso de creación de este formato interino se llama transcodificación. Sin
embargo, transcodificación no es ampliamente adoptado porque fundamentalmente no
controla las estructuras más profundas y la semántica de la aplicación.
La transformación es otra técnica para limitar el crecimiento de la vista. Consiste en
describir la intención detrás de la interacción del usuario dentro del componente de vista, en
lugar de dar una representación física real de la gestión de la interfaz de usuario [3]. Por
ejemplo, el hecho de que la aplicación requiera de los usuarios ingresar su edad es
presentado por un elemento genérico de ENTRADA con un límite general en el intervalo de
datos. Entonces, basados en las características del dispositivo final, usabilidad.
consideraciones o preferencias del usuario, la máquina de adaptación. determina si el
elemento ENTRADA debe ser implementado como un campo de texto, lista o incluso como
una entrada por voz. Algunas presentaciones independientes del dispositivo han sido
desarrolladas a lo largo de los años, incluido el User Interface Markup Language (UIML),
Abstract User Interface Markup Language (AUIML), XForms y los Controles Móviles de
Microsoft ASP.NET [9]. Sin importar las técnicas de adaptación usadas, los sistemas que
soportan vistas independientes del dispositivo también proporcionan un número de entornos
de desarrollo integrado para dispositivos de de escritura contenido independiente
Las dos técnicas mencionadas anteriormente se pueden utilizar independientemente de si la
aplicación está diseñada con el patrón MVC o PAC. Cbe señalar que el sistema de
transcodificación y transformación solo resuelve el problema de publicación de múltiples
tipos de interfaces de usuario para el usuario. También ignora el hecho de que la entrada
del usuario puede provenir de una variedad de canales heterogéneos como HTTP, WAP,
VoIP o GSM.
La limitación del aumento en el número de controladores se controla de tal manera que un
controlador de componentes en aplicaciones diseñadas por el patrón MVC se implementa
como un Controlador de aplicaciones. Contiene el flujo de control, incluyendo validación de
datos y gestión de errores, generalmente en el procedimiento de manejo de eventos. Hay
varias razones por las que el controlador de la aplicación es requierido en casos de
múltiples dispositivos de destino:
● Los diferentes dispositivos tienen diferentes hardware de entrada, desde El teclado,
dispositivo de indicación, el micrófono en el PC, a un par de botones y rollers para
desplazarse por la reloj
● El flujo de aplicación puede ser diferente en diferentes dispositivos Por ejemplo, una
aplicación que contiene transacciones seguras pueden no completar una transacción
en el dispositivo que no tiene nivel correspondiente de infraestructura. Del mismo
modo, una aplicación que soporta contenido rico puede optar por omitir los
dispositivos. que no son capaces de presentar contenido rico
● Durante la restauración y apertura de la página que es Independientemente del
dispositivo, la página se puede dividir en múltiples páginas dependientes del
dispositivo que es demasiado pequeño para contener toda la página.
Como resultado, una solución completa para múltiples dispositivos destinos debe incluir la
introducción de controladores de aplicación. La gestión de la aplicación y el mantenimiento
se vuelve más difícil con el aumento en el número de vistas y controladores, que, de
acuerdo con [10] es especialmente cierto en la aplicación del patrón MVC, debido a la
estrecha conexión entre vistas y controladores y dada la naturaleza asimétrica de este
modelo. En contraste con el patrón MVC, los componentes del patrón PAC están muy
desconectados y por lo tanto PAC escalas muy bien. Se pueden enlazar diferentes
componentes de una forma muy separada, ya que es bastante legal para los controladores
comunicarse y cooperar entre sí. Por consiguiente la fabricación de interfaces de usuario
complicadas basadas en más sencillas es mucho más natural para PAC que para MVC,
porque la composición de los agentes se puede realizar. sin violar la encapsulación. En este
patrón las diferentes piezas pueden ser procesos completamente separados. Estas
propiedades son lo que hace que el PAC sea más adecuado para el desarrollo de
Aplicaciones móviles con múltiples modalidades de entrada y salida. [10]. El patrón PAC
proporciona un lugar bien definido para agregar un variedad de componentes de
infraestructura que tienen en cuenta la dimensiones de la movilidad, que es el componente
de control. Esto significa que el componente de control puede comunicarse con sistemas de
sensibilidad a la ubicación, el motor de reconocimiento de voz, el motor de síntesis de voz y
todos los demás subsistemas que deben ser utilizados Para el control y la producción de
nuestra interfaz de usuario sin comprometer la separación de tareas entre la abstracción. y
la presentación y de este modo protegiendo la lógica empresarial.
Dadas las condiciones que llevaron a la formación del patrón PAC, se puede concluir que
los requisitos de los dispositivos móviles justo crearon tales condiciones que son mejor
resueltas mediante utilizando el patrón PAC. La variedad de interfaces de usuario, la
existencia. de múltiples interfaces, así como la necesidad de relativa facilidad para añadir
una nueva interfaz de usuario al sistema en el futuro, son todos reconocido como los
requisitos de las aplicaciones móviles y la condiciones que llevaron al reconocimiento del
patrón PAC como solución. El primer enfoque con este patrón es asegurar un mecanismo
uniforme de comunicación entre clases, así como mecanismos para la estructuración de la
coordinación. Esto permite manejabilidad de gran número de componentes. El patrón MVC
debe ser utilizado en caso de que la aplicación no disponga de una gran cantidad de tipos
de interfaces de usuario con diferentes modalidades de entrada-salida. En la elección de un
patrón apropiado para el diseño de aplicaciones con múltiples tipos de interfaces de usuario,
nos guiamos por evitar la duplicación de partes del código y la reducción del número de
clases y relaciones. entre ellos a un número tan pequeño como sea posible.

Tabla 1: Comparación de patrones MVC y PAC

Aspectos MVC vs PAC

Complejidad Mayor complejidad de PAC debido a

múltiples componentes y debido a la forma
de implementación que también puede
incluir cooperación entre procesos

Separación de tareas entre los El modelo MVC puede incluir entrelazado

componentes de presentación, control y de tareas, mientras que PAC separa más
patrón. estrictamente la Tareas entre la
componentes

Eficiencia Puede ser baja con PAC debido al gran

número de componentes y conexiones

Soporte para cambios y extensión Debido a tareas entrelazadas en el patrón

MVC la ventaja está del lado del patrón
PAC que tiene una estructura uniforme.

La existencia de más subestructuras en el Mucha complejidad en el patrón PAC,

patrón, las cuales requieren formas debido a la necesidad por comunicación
específicas de interacción. con otros componentes de control.

Para tener una correcta interpretación de las comparaciones. que figuran en la Tabla 1,
cabe señalar que la necesidad de comunicación con otros componentes de control, hace
significativamente complejo el uso del patrón de diseño PAC. Debido a esto, rara vez se
utiliza en aplicaciones móviles.
Aunque el patrón de diseño MVC es ampliamente utilizado durante el diseño de interfaces
de usuario en aplicaciones móviles, no es universal. En ciertas circunstancias se hace
necesario el patrón de diseño PAC, como en el caso de requerimientos por la existencia de
interfaces de usuario heterogéneas multimodales. Tales solicitudes requieren el uso de
diferentes tecnologías para la aplicación de determinadas partes del requerimiento, que
pueden integrarse entre sí solo por medio de comunicación entre procesos. En tales casos
es imposible utilizar el patrón MVC.
En [2] se dice que el patrón de diseño PAC tiene la Ventaja que permite realizar múltiples
tareas. Sin embargo, la plataforma J2ME permite una aplicación con múltiples hilos, por lo
que esta plataforma le permite al controlador aceptar la entrada del usuario durante su
ejecución, por ejemplo, la comunicación HTTP. Por lo tanto, el PAC no tiene exclusividad
sobre la multitarea

CONCLUSIÓN
La necesidad de la existencia de múltiples modalidades de entrada y salida. en aplicaciones
móviles nos llevan a interfaces de usuario más complejos. Por lo tanto, deberíamos
considerar los patrones de software disponibles para la construcción de interfaces de
usuario con el fin de utilizar una estructura más eficiente para los requisitos dados. El
artículo revisa los patrones de software MVC y PAC y hace conexión entre los requisitos de
las aplicaciones móviles y las características de dichos patrones de software. Las ventajas y
desventajas de estos patrones de software son consideradas durante su uso en
determinadas circunstancias. Esto facilita la elección de los diseñadores de software del
patrón de software apropiado para la construcción de interfaces de usuario de aplicaciones
móviles..

REFERENCIAS
[1] Java Blue Prints Model-View-Controller,
http://java.sun.com/blueprints/patterns/MVC-detailed.html
[2] F. Buschmann, A system of patterns, Chichester: Wiley, 1996
[3] G. Banavar, N. Cohen and D. Soroker, “Pervasive Application Development: Approaches
and Pitfalls”, Mobile Computing Handbook, M. Ilyas, I. Mahggoub, eds., Boca Raton: CRC
Press, 2005
[4] G. Banavar, “An Authoring Technology for Multidevice Web Application”, Pervasive
Computing, 2004
[5] M. Yuan, Enterprise J2ME: Developing Mobile Java Applications, New Jersey: Prentice
Hall PTR, 2003
[6] D. Greer, “Interactive Application Architecture Patterns”, ​www.ctrl-
shift-b.com/2007/08/interactive-application-architecture.html.2007
[7] „Presentation Abstraction Control“,
http://www.phpwact.org/pattern/presentation_abstraction_control
[8] “IntrosPAC”, ​http://iihm.imag.fr/demos/IntrosPAC/
[9] H. Witt, User interfaces for Wearable Computers, Wiesbaden: Vieweg+Teubner Verlag,
2008
[10] B. Reza, Designing and developing mobile applications with UML and XML, Cambridge
University Press, 2004