Desarrollo de una arquitectura reutilizable basada en componentes para la implementación de aplicaciones en la plataforma windows mobile

Texto completo

(1)DESARROLLO DE UNA ARQUITECTURA REUTILIZABLE BASADA EN COMPONENTES PARA LA IMPLEMENTACIÓN DE APLICACIONES EN LA PLATAFORMA WINDOWS MOBILE. LAURA CRISTINA MANZUR VILLALOBOS CARLOS ANDRES TORO BOLAÑOS. REPORTE DE PROYECTO DE GRADO El presente documento consiste en un reporte de proyecto de grado en el campo de la construcción de software y específicamente de aplicaciones móviles orientadas a componentes genéricos, flexibles y reutilizables. Presenta la descripción general del proyecto Qualdev Móvil Windows Mobile, su diseño, arquitectura y los resultados del semestre. Además presenta unas conclusiones y trabajo futuro, dentro del marco del proyecto Qualdev Móvil Windows Mobile..

(2) DESARROLLO DE UNA ARQUITECTURA REUTILIZABLE BASADA EN COMPONENTES PARA LA IMPLEMENTACIÓN DE APLICACIONES EN LA PLATAFORMA WINDOWS MOBILE. LAURA CRISTINA MANZUR VILLALOBOS CARLOS ANDRES TORO BOLAÑOS. Proyecto de Grado. Director Rafael Gustavo Meneses Ramírez Con la participación de Tatiana Paola Hernández Martínez Camilo Andrés Varela León. UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA DE SISTEMAS BOGOTÁ D. C., 2010.

(3) Tabla de Contenido I.. LISTA DE FIGURAS ............................................................................................... 6. II.. LISTA DE TABLAS ................................................................................................. 8. RESUMEN ...................................................................................................................... 9 1.. INTRODUCCIÓN................................................................................................... 10 1.1. OBJETIVOS .................................................................................................. 10 1.1.1. OBJETIVO GENERAL ........................................................................... 10 1.1.2. OBJETIVOS ESPECÍFICOS .................................................................. 11. 2.. CONTEXTO .......................................................................................................... 12. 3.. DISEÑO DE LA SOLUCIÓN ................................................................................. 14 3.1. ATRIBUTOS DE CALIDAD ............................................................................ 14 3.1.1. FLEXIBILIDAD ....................................................................................... 14 3.1.2. REUSABILIDAD ..................................................................................... 14 3.1.3. MANTENIBILIDAD ................................................................................. 15 3.1.4. EXTENSIBILIDAD .................................................................................. 15 3.2. DISEÑO DE ALTO NIVEL .............................................................................. 16 3.2.1. ARQUITECTURA GENERAL ................................................................. 16 3.2.2. ARQUITECTURA ESPECIFICA DE QUALDEV WINDOWS MOBILE .... 19 3.2.2.1. ARQUITECTURA DEL COMPONENTE MULTIMEDIA .......................... 20 3.2.2.2. ARQUITECTURA DEL COMPONENTE PERSISTENCIA ...................... 20 3.2.2.3. ARQUITECTURA DEL COMPONENTE COMUNICACIONES ............... 21 3.2.2.4. ARQUITECTURA DEL COMPONENTE CONVERSION DE DATOS ..... 22 3.2.2.5. ARQUITECTURA DEL COMPONENTE DE ADAPTACIÓN ................... 23 3.3. DISEÑO DETALLADO ................................................................................... 24 3.3.1. DIAGRAMAS DE CLASE QUALDEV WINDOWS MOBILE .................... 24 3.3.2. DIAGRAMAS DE CLASE DOCTOR CHAT ............................................ 29. 4.. CONSTRUCCIÓN DE LA SOLUCIÓN .................................................................. 32 4.1. PLATAFORMA DE DESARROLLO ................................................................ 32 4.2. DOCTOR CHAT EN FUNCIONAMIENTO ...................................................... 32 4.3. METRICAS .................................................................................................... 35. 5.. VALIDACIÓN ........................................................................................................ 37 5.1. PRUEBAS DE SISTEMA ............................................................................... 37 5.2. PRUEBAS DE INTEGRACIÓN ...................................................................... 37 5.3. PRUEBAS UNITARIAS .................................................................................. 37 5.4. RESULTADOS DE LA APLICACIÓN ............................................................. 37. 6.. CONCLUSIONES.................................................................................................. 40 6.1. DISCUSIÓN ................................................................................................... 40 6.2. TRABAJO PENDIENTE ................................................................................. 40 6.3. TRABAJO FUTURO....................................................................................... 41. 7.. BIBLIOGRAFÍA..................................................................................................... 43. 8.. GLOSARIO ........................................................................................................... 45. 9.. ANEXOS ............................................................................................................... 46 A. DR. CHAT ........................................................................................................... 46. 3.

(4) Introducción ........................................................................................................... 46 Descripción de la Aplicación .................................................................................. 46 Funcionalidades de la Aplicación ........................................................................... 46 Diseño de la Aplicación ......................................................................................... 47 B. DOCTORCH@T MÓVIL Y DOCTORCH@T MÓVIL GEOREFERENCIA ......................... 50 C. COMPONENTE DE ADAPTACIÓN ............................................................................ 50 Descripción Componente ...................................................................................... 50 Descripción Detallada ............................................................................................ 51 Referencias ........................................................................................................... 52 D. COMPONENTE DE COMUNICACIONES .................................................................... 53 Descripción Componente ...................................................................................... 53 Descripción Communication Facade ..................................................................... 54 Descripción SMS Component ................................................................................ 55 Descripción HTTP Component .............................................................................. 56 E. COMPONENTE DE CONVERSIÓN DE DATOS............................................................ 57 Descripción Componente ...................................................................................... 57 Descripción Detallada ............................................................................................ 58 F. COMPONENTE DE MANEJO DE MULTIMEDIA ........................................................... 59 Introducción ........................................................................................................... 59 G. COMPONENTE DE PERSISTENCIA .......................................................................... 62 Introducción ........................................................................................................... 62 H. PRUEBAS DE SISTEMA DR. CHAT W INDOWS MOBILE ............................................. 65 Introducción ........................................................................................................... 65 Escenarios de Pruebas.......................................................................................... 65 Resultados de las Pruebas .................................................................................... 71 I. PRUEBAS INTEGRACIÓN COMPONENTE ADAPTACIÓN ............................................. 75 Introducción ........................................................................................................... 75 Escenarios de Pruebas.......................................................................................... 75 Resultados de las Pruebas .................................................................................... 76 J. PRUEBAS INTEGRACIÓN COMPONENTE COMUNICACIONES Y CONVERSIÓN DE DATOS 77 Introducción ........................................................................................................... 77 Escenarios de Pruebas.......................................................................................... 77 Resultados de las Pruebas .................................................................................... 80 K. PRUEBAS DE INTEGRACIÓN COMPONENTE MULTIMEDIA ......................................... 81 Introducción ........................................................................................................... 81 Escenarios de Pruebas.......................................................................................... 81 L. PRUEBAS DE INTEGRACIÓN COMPONENTE PERSISTENCIA ...................................... 83 Introducción ........................................................................................................... 83 Escenarios de Pruebas.......................................................................................... 83 M. PRUEBAS UNITARIAS COMPONENTE COMUNICACIONES ......................................... 86 Introducción ........................................................................................................... 86 Escenarios de Pruebas.......................................................................................... 86 Escenario de Prueba 2 .......................................................................................... 87 Resultados de las Pruebas .................................................................................... 89 N. PRUEBAS UNITARIAS COMPONENTE CONVERSIÓN DE DATOS ................................. 90 Introducción ........................................................................................................... 90 Escenarios de Pruebas.......................................................................................... 90 Resultados de las Pruebas .................................................................................... 91 O. PRUEBAS UNITARIAS COMPONENTE MULTIMEDIA .................................................. 92 Introducción ........................................................................................................... 92. 4.

(5) Escenarios de Pruebas.......................................................................................... 92 PRUEBAS UNITARIAS COMPONENTE PERSISTENCIA ............................................... 95 Introducción ........................................................................................................... 95 Escenarios de Pruebas.......................................................................................... 96 Q. DESPLIEGUE DE UNA APLICACIÓN EN UN DISPOSITIVO BASADO EN W INDOWS MOBILE 98 Introducción ........................................................................................................... 98 Instrucciones ......................................................................................................... 99 R. INSTALACIÓN DE LAS HERRAMIENTAS DEL PROYECTO........................................... 100 Introducción ......................................................................................................... 100 Instalación de Visual Studio 2008 ........................................................................ 100 Instalación Windows Mobile 6.0 Standard SDK Refresh ...................................... 102 Instalación Windows Mobile 6.0 Standard Image................................................. 105 Instalación del plugin de Motorola Q11 ................................................................ 106 Hacer uso de la utilidad Cellular Emulator ........................................................... 110 Desarrollo de una aplicación “Hola Mundo” en VS 2008 ...................................... 112 Referencias ......................................................................................................... 116 S. INTERFAZ DOCTORCHAT < MÓVIL W INDOWS MOBILE >........................................ 117 Introducción ......................................................................................................... 117 Instrucciones ....................................................................................................... 117 Ejecutar las pruebas ............................................................................................ 119 T. MANIPULACIÓN DEL COMPORTAMIENTO DE LA APLICACIÓN POR LOS ESTADOS DEL MÓVIL ...................................................................................................................... 119 INTRODUCCIÓN ......................................................................................................... 119 Instrucciones ....................................................................................................... 120 Referencias ......................................................................................................... 125 U. ADJUNTO DE ARCHIVOS MULTIMEDIA ................................................................... 126 Introducción ......................................................................................................... 126 Instrucciones ....................................................................................................... 126 V. ENVÍO DE DATOS MEDIANTE HTTP Y SMS .......................................................... 128 Introducción ......................................................................................................... 128 Instrucciones ....................................................................................................... 128 W. CREACIÓN DE PRUEBAS UNITARIAS EN C# ........................................................... 134 Introducción ......................................................................................................... 134 Creación de pruebas unitarias ............................................................................. 134 P.. 5.

(6) I.. LISTA DE FIGURAS. Figura 1 – Diagrama de Despliegue Dr. Chat Windows Mobile .......................... 16 Figura 2 - Arquitectura específica Qualdev Windows Mobile .............................. 18 Figura 3 - Arquitectura específica Doctor Chat ................................................... 19 Figura 4 - Estructura del componente de multimedia.......................................... 20 Figura 5 - Estructura del componente de persistencia ........................................ 21 Figura 6 - Estructura del componente de comunicación ..................................... 22 Figura 7 - Estructura del componente de conversión de datos ........................... 23 Figura 8 - Arquitectura del componente de adaptación ...................................... 24 Figura 9 - Diagrama de clases componente multimedia ..................................... 25 Figura 10 - Diagrama de clases componente persistencia ................................. 26 Figura 11 - Diagrama de clases componente comunicación .............................. 27 Figura 12 - Diagrama de clases componente conversión de datos .................... 28 Figura 13 - Diagrama de clases componente de adaptación .............................. 29 Figura 14 - Diagrama de clases interfaz de usuario Dr. Chat ............................. 30 Figura 15 - Diagrama de clases controlador Dr. Chat ......................................... 31 Figura 16 - Ver noticias y realizar una consulta nueva ....................................... 33 Figura 17 - Ver consultas realizadas e información del paciente ........................ 34 Figura 18 - LOC de Dr. Chat y sus componentes ............................................... 35 Figura 19 - Esfuerzo requerido por Dr. Chat y sus componentes ....................... 36 Figura 20 - Estructura de funcionalidades principales ........................................ 47 Figura 21 - Estructura del suministro de noticias ................................................ 47 Figura 22 - Diseño general de la aplicación ........................................................ 48 Figura 23 - Diseño específico del user interface ................................................. 49 Figura 24 - Diseño específico del controlador ..................................................... 49 Figura 25 - Estructura del componente de adaptación ....................................... 50 Figura 26 - Interfaces del componente de adaptación ........................................ 50 Figura 27 - Diagrama de clases del componente de adaptación ........................ 52 Figura 28 - Estructura del componente de comunicaciones ............................... 53 Figura 29 - Interfaces del componente de comuniaciones.................................. 54 Figura 30 - Diagrama de clases de CommunicationFacade ............................... 55 Figura 31 - Diagrama de clases del SMS component ......................................... 56 Figura 32 - Diagrama de clases del HTTP component ....................................... 57 Figura 33 - Estructura del componente de conversión de datos ......................... 57 Figura 34 - Interfaces del componente de conversión de datos ......................... 58 Figura 35 - Diagrama de clases del componente de conversión de datos.......... 58 Figura 36 - Estructura del componente de multimedia........................................ 59 6.

(7) Figura 37 - Interfaces del componente ............................................................... 60 Figura 38 - Diagrama de clases del componente MediaManipulator .................. 60 Figura 39 - Diagrama de clases del componente InputMedia ............................ 61 Figura 40 - Estructura del componente de persistencia ...................................... 62 Figura 41 - Interfaces del componente ............................................................... 63 Figura 42 - Diagrama de clases del componente PersistenceManager .............. 63 Figura 43 - Diagrama de clases del componente FilePersistence ..................... 64 Figura 44 - Diagrama de clases del componente DbPersistence ...................... 65 Figura 45 - Microsoft ActuveSync 4.5 (Windows XP)........................................ 111 Figura 46 - Windows Mobile Device Center (Windows Vista/7) ........................ 111. 7.

(8) II.. LISTA DE TABLAS. Tabla 1 - Integrantes del grupo de trabajo Qualdeb Móvil Windows Mobile ....... 13 Tabla 2 - Información requerida en IDictionary ................................................... 62. 8.

(9) RESUMEN El presente documento consiste en un reporte de proyecto de grado en el campo de la construcción de software y específicamente de aplicaciones móviles orientadas a componentes genéricos, flexibles y reutilizables. Presenta la descripción general del proyecto Qualdev Móvil Windows Mobile, su diseño, arquitectura y los resultados del semestre. Además presenta unas conclusiones y trabajo futuro, dentro del marco del proyecto Qualdev Móvil Windows Mobile.. 9.

(10) 1. INTRODUCCIÓN A partir del 2002 los teléfonos móviles de gama alta, o smartphones, se han ido difundiendo cada vez más generando una nueva corriente de dispositivos móviles. De ahí nace la necesidad de desarrollar aplicaciones que permitan a los usuarios de los smartphones interactuar con los servicios más comunes en la computación a través de sus teléfonos celulares. Por otro lado, la navegación en internet ha permitido abrir las puertas a nuevos servicios y medios de comunicación que han logrado ser integrados a los smartphones difundiendo aún más su uso. Teniendo todo esto en cuenta, el sector de la salud se ha visto beneficiado ofreciendo ciertos servicios a través de este medio. Así nace la posibilidad de concretar citas médicas u otros por medio de los portales de las EPS, entre otros. Tomando esta oportunidad, nace una idea innovadora. Una aplicación que permita a las personas la realización de consultas médicas a través de internet, sin necesidad de concretar citas innecesarias. Este es el objetivo de Doctor Chat (Ver Anexo B). Dentro de este contexto, se busca ofrecer este servicio a los usuarios de dispositivos móviles como los celulares de gama alta o PDAs. Teniendo esto en cuenta, se busca desarrollar esta aplicación para dispositivos con el sistema operativo Windows Mobile, particularmente la versión 6. Teniendo en mente una implementación de arquitectura basada en componentes, se busca la creación de unidades funcionales que provean servicios útiles para Doctor Chat y de carácter genérico, para que puedan ser empleados en otros contextos.. 1.1.. OBJETIVOS. 1.1.1. OBJETIVO GENERAL Construir una aplicación móvil basada en la plataforma Windows Mobile 6 que permita realizar consultas médicas con envío de adjuntos multimedia, tomando como base una versión existente sobre la plataforma J2ME, haciendo énfasis en que éste será un caso de estudio para una arquitectura extensible y reutilizable para disminuir el trabajo y realizar aplicaciones móviles sobre este framework de desarrollo.. 10.

(11) 1.1.2. OBJETIVOS ESPECÍFICOS  Diseñar e implementar una arquitectura extensible y sencilla para el desarrollo de aplicaciones sobre la plataforma Windows Mobile.  Hacer una adaptación de la aplicación J2ME Doctor Chat que use la arquitectura implementada integrando sus funcionalidades particulares. o Registrar un paciente a la aplicación. o Realizar y enviar una consulta médica. o Consultar y editar las consultas realizadas con anterioridad.  Incluir funcionalidades adicionales a las existentes en la aplicación Doctor Chat. o Diseñar una funcionalidad que permita la recepción de noticias de la Fundación Santa Fe de Bogotá en la página inicial de la aplicación. o Permitir la adaptación de la aplicación a cambios en el dispositivo como lo es el estado cambiante de la batería. o Integrar la manipulación y transmisión de multimedia en la aplicación. En la siguiente sección definiremos el contexto de la aplicación. Posteriormente, en la tercera sección, expondremos el diseño de la solución planteada para nuestra arquitectura reutilizable con los atributos de calidad identificados. La cuarta sección presenta la construcción de la solución, describiendo la plataforma de desarrollo empleada y mostrando la aplicación resultado que en este caso será Doctor Chat. En la quinta sección presentamos las pruebas realizadas sobre el sistema para garantizar su correcto funcionamiento y el cumplimiento de los atributos de calidad identificados. Por último, se presentan las conclusiones donde expondremos la experiencia vivida con la plataforma de desarrollo, así como el trabajo futuro sobre este proyecto.. 11.

(12) 2.. CONTEXTO. El desarrollo de software basado en componentes tiene como objetivo la reutilización de piezas de código pre-elaborado que permiten realizar diversas tareas, conllevando a diversos beneficios como las mejoras a la calidad, la reducción del ciclo de desarrollo y el mayor retorno sobre la inversión [1]. Las piezas de código previamente mencionadas son denominadas componentes. Los componente de software son todo aquel recurso desarrollado para un fin concreto y que puede formar solo o junto con otro/s, un entorno funcional requerido por cualquier proceso predefinido. Los componentes son independientes entre ellos, y tienen su propia estructura e implementación. El paradigma de ensamblar componentes y escribir código para hacer que estos componentes funcionen se conoce como Desarrollo de Software Basado en Componentes. El uso de este paradigma posee algunas ventajas [1]: 1. Reutilización del software. Nos lleva a alcanzar un mayor nivel de reutilización de software. 2. Simplifica las pruebas. Permite que las pruebas sean ejecutadas probando cada uno de los componentes antes de probar el conjunto completo de componentes ensamblados. 3. Simplifica el mantenimiento del sistema. Cuando existe un débil acoplamiento entre componentes, el desarrollador es libre de actualizar y/o agregar componentes según sea necesario, sin afectar otras partes del sistema. 4. Mayor calidad. Dado que un componente puede ser construido y luego mejorado continuamente por un experto u organización, la calidad de una aplicación basada en componentes mejorará con el paso del tiempo. De la misma manera, la decisión de utilizar componentes de terceros en lugar de desarrollarlos, posee algunas ventajas [1]: 1. Ciclos de desarrollo más cortos. La adición de una pieza dada de funcionalidad tomará días en lugar de meses ó años. 2. Mejor ROI1. Usando correctamente esta estrategia, el retorno sobre la inversión puede ser más favorable que desarrollando los componentes uno mismo. 1. Retorno de la inversión, Return On Investment en inglés, hace referencia a un porcentaje que se calcula en función de la inversión y los beneficios obtenidos para cuantificar la viabilidad de un proyecto.. 12.

(13) 3. Funcionalidad mejorada. Para usar un componente que contenga una pieza de funcionalidad, solo se necesita entender su naturaleza, más no sus detalles internos. Así, una funcionalidad que sería impráctica de implementar en la empresa, se vuelve ahora completamente asequible. Dentro del contexto de desarrollo basado en componentes, se realizó la división de responsabilidades para el desarrollo definiendo los siguientes roles dentro del grupo: Tabla 1 - Integrantes del grupo de trabajo Qualdeb Móvil Windows Mobile. Persona Rol Rafael Meneses Asesor Camilo Varela. Líder. Laura Manzur. Planeación, Desarrollador. Carlos Toro. Pruebas, Desarrollador. Responsabilidad Coordina el progreso del proyecto y las funcionalidades con las que debe cumplir. Coordina las tareas a realizar semanalmente y el progreso del sistema como un todo. Velar por el cumplimiento de las tareas de la semana. Desarrollar componentes del sistema. Desarrollar componentes del sistema.. 13.

(14) 3.. DISEÑO DE LA SOLUCIÓN. 3.1.. ATRIBUTOS DE CALIDAD. 3.1.1. FLEXIBILIDAD El atributo de calidad de flexibilidad hace referencia a la capacidad del sistema de permitir cambios de configuración como respuesta al contexto de ejecución [13]. En la implementación del sistema planteada, se evidencia la flexibilidad de los componentes en cuanto a cambios en la configuración de los mismos ya que son genéricos, permitiendo paramétrizar las características de ellos. Dentro de este contexto, es necesario definir una métrica que permita evaluar el éxito de este atributo de calidad dentro de la implementación final de la aplicación. Métrica: NUMERO ERRORES POSTERIOR CAMBIOS - NUMERO ERRORES PREVIO CAMBIOS = 0 Esta métrica hace referencia a que el componente no debe cambiar cuando se incluyen nuevos cambios dentro de los componentes. Dentro de ese contexto, no se deben generar errores en la implementación de la aplicación final. 3.1.2. REUSABILIDAD El atributo de calidad de reusabilidad hace referencia al esfuerzo ganado al poder utilizar componentes existentes [13]. Teniendo en cuenta que el sistema está orientado al desarrollo por componentes, la reutilización de los mismos en términos de otros usos o aplicaciones que los requieran no implica esfuerzo alguno ya que son fáciles de conectar. Dentro de este contexto, es necesario definir una métrica que permita evaluar el éxito de este atributo de calidad dentro de la implementación final de la aplicación. Métrica: (LOC COMPONENTES / LOC DR. CHAT) * 100 > 70% Esta métrica hace referencia a la cantidad de líneas de código (LOC) correspondientes a los componentes en relación a la aplicación final. Dentro de 14.

(15) ese contexto, las líneas de código correspondientes a los componentes deben ser mayores al 70% de las líneas de código de la aplicación. Esto quiere decir que una implementación de una nueva aplicación no implica gran esfuerzo en términos de tiempos de desarrollo. 3.1.3. MANTENIBILIDAD El atributo de calidad de mantenibilidad hace referencia al esfuerzo ahorrado para corregir errores del sistema [13]. En un sistema basado en componentes, la corrección de errores del sistema se facilita ya que es fácil identificar el componente que generó los errores a corregir. Dentro de este contexto, es necesario definir una métrica que permita evaluar el éxito de este atributo de calidad dentro de la implementación final de la aplicación. Métrica: TIEMPO DE CORRECION DE ERRORES < 30 MIN Esta métrica hace referencia al esfuerzo por persona, en términos de tiempo, que se requiere para la corrección de errores dentro del código de cada componente. Dentro de ese contexto, dado que las funcionalidades están enfocadas a componentes, es posible localizar de forma rápida y fácil donde se encuentra el error. Esto agiliza el proceso de mantenimiento del código disminuyendo los costos que ello implica. 3.1.4. EXTENSIBILIDAD El atributo de calidad de extensibilidad hace referencia a la capacidad de los componentes de extender sus funcionalidades particulares de forma rápida y efectiva sin generar cambios en la arquitectura propuesta [13]. Dentro de este contexto, es necesario definir una métrica que permita evaluar el éxito de este atributo de calidad dentro de la implementación final de la aplicación. Métrica: ESFUERZO PARA EXTENDER FUNCIONALIDADES ≤ 3 H Esta métrica hace referencia al esfuerzo requerido por persona, en términos de tiempo, para implementar nuevas funcionalidades dentro de cada componente. Dentro de ese contexto, al tener las funcionalidades fraccionadas en 15.

(16) componentes, los cambios necesarios son focalizados en un componente en particular, facilitando la implementación de nuevas funcionalidades que extienden las responsabilidades del componente.. 3.2.. DISEÑO DE ALTO NIVEL. La arquitectura general de la implementación llamada por nosotros Qualdev Windows Mobile está orientada a la reutilización de los componentes y al hecho de que aplicaciones concretas, como Doctor Chat, hagan uso de estos componentes de una manera sencilla y transparente. Por lo tanto, la puerta de entrada a nuestro componente de Windows Mobile será una fachada que expondrá todos los servicios necesarios para que una aplicación pueda apoyarse en ésta para suplir la mayoría de sus requerimientos funcionales. En el diseño de la solución que se plantea se mostrará desde dos frentes: en el primero se mostrará el diseño de la arquitectura general llamada Qualdev Windows Mobile y en segunda instancia, el diseño de la implementación de Doctor Chat adaptado a este contexto. 3.2.1. ARQUITECTURA GENERAL VISTA GENERAL DE LA ARQUITECTURA. Figura 1 – Diagrama de Despliegue Dr. Chat Windows Mobile. En el diagrama de despliegue en el dispositivo móvil (Ver Figura 1) podemos ver cómo es la interacción entre la aplicación de estudio Doctor Chat y el componente reutilizable que se diseño. Doctor Chat es una aplicación cliente. 16.

(17) que se comunicará con un intermediario que hace de Proxy2 contra un servidor que poseerá los datos relevantes de los requerimientos funcionales de la aplicación. La explicación del funcionamiento de la aplicación instalada en el servidor está fuera del alcance de este documento. Qualdev Windows Mobile se puede expresar como un componente que intentará simplificar la interacción de aplicaciones especificas con el core del framework de Windows Mobile; esto, con el fin de que cada aplicación se centre en el desarrollo de sus requerimientos funcionales y no funcionales reduciendo su dependencia con la tecnología. Es por ello que Doctor Chat como tal puede considerarse como una aplicación sencilla porque toda la parte que involucra la interacción con el framework de Windows Mobile está encapsulado en un componente aislado y reutilizable. Este componente consta de más componentes individuales que ofrecerán servicios específicos y comunes para cualquier aplicación móvil como lo son: Comunicación, Persistencia y Multimedia. Adicionalmente, se contará con un componente que ayudará a la conversión de los objetos del negocio en formatos específicos que sean empleados para el flujo de datos que sean coherentes para el intercambio de información entre la aplicación y su entorno. Nuestra arquitectura, además de ser orientada a la reutilización se basó en la posible modificación del comportamiento de la misma en ejecución, para que se pueda adaptar a cambios originados por el estado de determinadas propiedades del dispositivo móvil. Por ello se diseño un componente que orquestará los distintos componentes mediante los eventos generados por el dispositivo móvil, cambiando el comportamiento de la aplicación que use el componente de Qualdev Windows Mobile como lo es Doctor Chat en este caso.. 2. En el contexto de comunicaciones entre aplicaciones, el término Proxy es usado para hacer referencia a que una aplicación realiza una acción en representación de otra, controlando el acceso a esta.. 17.

(18) VISTA ESPECIFICA DE LA ARQUITECTURA QUALDEV WINDOWS MOBILE. Figura 2 - Arquitectura específica Qualdev Windows Mobile. Como ya se describió anteriormente, la arquitectura consta de componentes que se encargan de funcionalidades especificas y un componente más, una fachada que se encargará de exponer los servicios de cada componente en específico. Entonces, la interfaz expuesta por esta fachada será el punto de entrada que usará cualquier aplicación. Adicionalmente el componente de adaptación consume a la fachada porque éste será capaz de cambiar el comportamiento de los mismos en ejecución, entonces para no tener que consumir las interfaces de cada componente como lo hace la fachada, lo más sencillo es delegarle la responsabilidad a la misma fachada.. 18.

(19) VISTA ESPECIFICA DE LA ARQUITECTURA DOCTOR CHAT. Figura 3 - Arquitectura específica Doctor Chat. El diseño de la aplicación Doctor Chat (Ver Figura 3) se basa en un patrón MVC (Ver Glosario), en donde el controlador será el encargado de orquestar el funcionamiento de la misma. En la vista simplemente se manejará la lógica de despliegue en la Interfaz, y en el modelo simplemente encontraremos las entidades relevantes de la aplicación. Al haber abstraído la interacción con la plataforma en el componente de Qualdev Windows Mobile, Doctor Chat se convirtió en una aplicación bastante sencilla que simplemente se adaptará de la mejor manera con este componente y se enfocará en el desarrollo de sus requerimientos funcionales.. 3.2.2. ARQUITECTURA ESPECIFICA DE QUALDEV WINDOWS MOBILE En este apartado se especificará la arquitectura de cada componente perteneciente a Qualdev Windows Mobile. Para tener más detalle sobre cada componente de la arquitectura, en los Anexos C-I, donde se encuentra una descripción detallada de cada uno de estos.. 19.

(20) 3.2.2.1. ARQUITECTURA DEL COMPONENTE MULTIMEDIA La manipulación de elementos multimedia es importante para aplicaciones que requieren de utilización de imágenes, sonido y video entre otros. El objetivo de la creación de un componente que permita la manipulación de multimedia es crítico para el desarrollo de móviles ya que las nuevas gamas altas de equipos poseen cámaras de fotografía y video, además de grabadores de audio para guardar o compartir. El componente de multimedia posee una estructura sencilla que facilita la comunicación con demás componentes que se van a utilizar en la aplicación (Ver Figura 4). El componente posee una interfaz, la cual será instanciada por la aplicación o componente que va utilizar los servicios. Esta interfaz se comunica con varias clases que modelan las diferentes características y servicios de los elementos multimedia, los cuales se comunican con la interfaz del componente de captura de archivos multimedia. Todo el componente se soporta sobre el framework de Windows Mobile.. Figura 4 - Estructura del componente de multimedia. 3.2.2.2. ARQUITECTURA DEL COMPONENTE PERSISTENCIA La persistencia es un factor muy importante en cualquier tipo de aplicaciones ya que permite almacenar la información importante para que la aplicación funcione con normalidad. El objetivo de la creación del componente es independizar todos los componentes que participan de la aplicación del manejo de información. Esto con el propósito de hacer la información más adaptable al contexto en el que se encuentra la aplicación. El componente de persistencia posee una estructura sencilla (Ver Figura 5), donde se expone una única interfaz para la comunicación con éste. Esta interfaz es implementada por una clase que orquesta el funcionamiento del componente. Internamente se comunica con las interfaces de los servicios de persistencia por archivos y de persistencia por base de datos. La base de datos está soportada. 20.

(21) por la librería de SQLite y los archivos están soportados por el framework de Windows Mobile.. Figura 5 - Estructura del componente de persistencia. 3.2.2.3. ARQUITECTURA DEL COMPONENTE COMUNICACIONES Para las aplicaciones móviles la capacidad de interactuar con su entorno en arquitecturas distribuidas, se debe contar con mecanismos para que la información fluya hacia sus destinos adecuadamente. Por lo tanto el objetivo de la creación de un componente que permita la comunicación de la aplicación con su entorno, es simplificar la interacción con el framework de Windows Mobile proporcionando servicios sencillos para la comunicación por medio de distintos protocolos. Estos se implementaron de tal forma que se vuelva transparente el uso de la tecnología específica, proporcionando servicios simples de usar. La estructura del componente (Ver Figura 6) se basa en una fachada que encapsula los distintos servicios que puede proveer el componente así como una forma sencilla para iniciarlos o detenerlos en ejecución. Los protocolos implementados fueron comunicaciones por HTTP en su forma síncrona y asíncrona, adicionalmente se implemento la capacidad de comunicarse por medio de SMS.. 21.

(22) Figura 6 - Estructura del componente de comunicación. 3.2.2.4. ARQUITECTURA DEL COMPONENTE CONVERSION DE DATOS Cuando hay comunicaciones entre distintos nodos se debe concertar cual va a ser el formato del flujo de datos y para ello existen distintas implementaciones estándar que facilitan dicha comunicación, algunas de ellas son XML3 y JSON4. Por lo tanto, se quiso hacer un componente que simplificara la serialización de la información en este tipo de formatos. Este componente se encarga de la transformación de objetos del negocio a formatos para el intercambio de datos. Estos formatos pueden ser JSON, XML o un archivo propietario. Actualmente, solo está implementada la transformación a JSON por medio de una librería externa que nos ayudó en su implementación por medio de reflexión de los objetos. La estructura de esta transformación es bastante simple (Ver Figura 7). Existe una interfaz que expone los servicios para serializar o des-serializar el objeto de negocio en el formato definido.. 3. Es un lenguaje extensible basado en etiquetas que posee una estructura simple para representar cualquier tipo de información. 4 Es un formato ligero para el intercambio de datos que resulta tener una ligera ventaja frente a XML en términos de tamaño para representar la misma información.. 22.

(23) Figura 7 - Estructura del componente de conversión de datos. 3.2.2.5. ARQUITECTURA DEL COMPONENTE DE ADAPTACIÓN En aplicaciones móviles existen muchas restricciones, pero el poder de procesamiento ligado a la vida de la batería del dispositivo genera muchos inconvenientes a las aplicaciones que corren sobre él. Es por ello que distintos eventos como niveles bajos de batería o en otro contexto una llamada entrante al dispositivo mientras se usa la aplicación son eventos deseables de monitorear para que las aplicaciones respondan a ellos de la mejor manera. El funcionamiento básico de este componente es el de adaptar la aplicación a cambios en el dispositivo, para que la aplicación pueda tener un comportamiento adecuado con los recursos disponibles del celular. Inicialmente, solo se monitoreará la batería del dispositivo. Con estas propiedades se podrá economizar el uso de la memoria cuando hay escasez de batería. El diseño del componente es muy simple (Ver Figura 8) y así como el componente de conversión de datos, se basa en una interfaz que expondrá los servicios para que entren en funcionamiento en el momento que una aplicación cualquiera como lo es Doctor Chat haga uso de esta interesante funcionalidad. Este componente debía atacar ampliamente el concepto de extensibilidad ya que son muchos los eventos generados en el dispositivo móvil que podrían ser monitoreados, pero solo aquellos relacionados con el estado de la batería serían genéricos para cualquier aplicación. Por esta razón, el hecho de poder monitorear una nueva propiedad sería algo bastante sencillo si así se requiere.. 23.

(24) Figura 8 - Arquitectura del componente de adaptación. 3.3.. DISEÑO DETALLADO. En esta sección se expondrá el diseño detallado de los componentes pertenecientes a la arquitectura Qualdev Windows Mobile y Doctor Chat. Para entrar más en detalle se debe consultar los Anexos C-I. 3.3.1. DIAGRAMAS DE CLASE QUALDEV WINDOWS MOBILE DIAGRAMA DE CLASES COMPONENTE MULTIMEDIA El componente de multimedia (Ver Figura 9) posee como entrada la interface IMediaManipulator, la cual se encarga de exponer las funcionalidades que el componente presta. A esta interface se conecta la clase principal del componente, MediaManipulator, la cual hace llamados a la interface IInputMedia que presta los servicios de obtención de archivos multimedia, ya sea por medio del hardware del dispositivo o por el sistema de archivos, para multimedia ya existente.. 24.

(25) Figura 9 - Diagrama de clases componente multimedia. DIAGRAMA DE CLASES COMPONENTE PERSISTENCIA El componente de persistencia (Ver Figura 10) posee como entrada la interface IPersistenceManager, la cual se encarga de exponer las funcionalidades que el componente presta. A esta interface se conecta la clase principal del componente, PersitenceManager, la cual hace llamados a las interfaces IFilePersistence y IDbPersistence. Estas interfaces prestan los servicios de persistencia por archivos y por base de datos, respectivamente.. 25.

(26) Figura 10 - Diagrama de clases componente persistencia. DIAGRAMA DE CLASES COMPONENTE COMUNICACIONES Este diagrama (Ver Figura 11) expone simplemente el comportamiento de la fachada del componente de comunicaciones. Cabe resaltar que en este componente reside la funcionalidad para la notificación de respuestas entrantes a la aplicación por medio de protocolos asíncronos como lo es SMS por defecto y el HTTP asíncrono. Es decir, las aplicaciones que quieran hacer uso de estas funcionalidades deberán registrar un observador en el componente de comunicaciones el cual tiene un método con la capacidad de recibir los datos entrantes. El resto de funciones son básicamente dos, la exposición de: (1) las funcionalidades del protocolo HTTP y SMS y (2) la capacidad para detenerse y arrancar en tiempo de ejecución.. 26.

(27) Con respecto a la implementación interna del componente HTTP y SMS lo más relevante es la forma en que se diseñó la recepción de mensajes SMS los cuales pueden venir en multiparte por las restricciones de tamaño del protocolo, entonces por medio de un patrón estrategia se diseño una forma de poder tener diferentes implementaciones, para que en ejecución pueda ser seleccionada la estrategia más adecuada en términos de desempeño, confiabilidad, y uso de recursos.. Figura 11 - Diagrama de clases componente comunicación. DIAGRAMA DE CLASES COMPONENTE CONVERSION DE DATOS Este diagrama (Ver Figura 12) expone simplemente el cómo la implementación de la interfaz IConverter del componente podrá definir a qué formato se desee convertir o des serializar los datos, Como ya hemos anotado, actualmente solo existe la funcionalidad con el formato JSON pero la implementación de un nuevo formato se basa en la extensión de la interfaz para que se cumpla el contrato. 27.

(28) Figura 12 - Diagrama de clases componente conversión de datos. DIAGRAMA DE CLASES COMPONENTE DE ADAPTACIÓN El diagrama de clases del componente de adaptación (Ver Figura 13) muestra cómo se logrará alcanzar el monitoreo de las propiedades del sistema. Se basa en que se tendrá una lista de propiedades a monitorear que podrán ser externas (creadas por alguna aplicación concretamente) ó las por defecto que son el estado de la batería y el nivel de la misma. La interfaz IPropertyStatus identifica a una propiedad para ser monitoreada, la clase abstracta AbstractPropertySatus es una implementación genérica que tiene la responsabilidad de implementar la funcionalidad de iniciar la propiedad y delegarla a las propiedades concretas en dos modos distintos por medio de un patrón plantilla: la persistente y la no persistente; el método que monitorea los eventos como tal deberá ser implementado por cada propiedad especifica. Como se puede ver en el diagrama, las propiedades deben extender el comportamiento de la clase abstracta y definir los métodos necesarios para el correcto funcionamiento. Entonces las propiedades que se quieran crear distintas a las implementadas por defecto, deberán extender esta clase, lo que las hará aptas para ser instaladas en la lista de propiedades monitoreadas del componente.. 28.

(29) Figura 13 - Diagrama de clases componente de adaptación. 3.3.2. DIAGRAMAS DE CLASE DOCTOR CHAT DIAGRAMA DE CLASES INTERFAZ DE USUARIO El diseño específico de la interfaz del usuario se basa en la correspondencia de una clase para cada pantalla, en donde cada pantalla tendrá la responsabilidad de interactuar con el controlador, para los efectos de lógica de negocio que deba realizar para suplir los requerimientos funcionales de la aplicación. La pantalla principal será la contenedora de las demás pantallas y algunas de ellas contendrán a las que dependan de ella, todo esto para la correcta visualización de las mismas, específicamente para la funcionalidad de volver para no tener que llevar un estado de los objetos que hace referencia a las pantallas. El diseño se puede ver en la Figura 14.. 29.

(30) Figura 14 - Diagrama de clases interfaz de usuario Dr. Chat. DIAGRAMA DE CLASES CONTROLADOR El diseño específico del controlador de la aplicación se basa en una interfaz que expone sus servicios y su implementación, que es 'Singleton', interactúa con el componente de Qualdev Windows Mobile a través de su interfaz. Los servicios expuestos por el controlador son exclusivamente los necesarios para cumplir los requerimientos funcionales de la aplicación. Además de la clase controlador existe una clase de utilidades que posee funcionalidades de instanciación de objetos del modelo. El diseño se puede ver en la Figura 15.. 30.

(31) Figura 15 - Diagrama de clases controlador Dr. Chat. 31.

(32) 4. CONSTRUCCIÓN DE LA SOLUCIÓN 4.1.. PLATAFORMA DE DESARROLLO. Doctor Chat se desarrolló sobre las herramientas provistas por el Compact Framework 3.55 de Windows Mobile. Para todas las funcionalidades del negocio se uso el componente de Qualdev Windows Mobile explicado anteriormente, el cual provee los distintos servicios necesarios para cumplir con los requerimientos funcionales de la aplicación. Dentro de las principales características de la plataforma encontramos: (1) la sencillez para crear interfaces de usuario a través del IDE de desarrollo Microsoft Visual Studio 2008, (2) la facilidad para crear aplicaciones en ambientes distribuidos con distintos mecanismos de comunicaciones, entre ellos un cliente de Web Services con soporte para WS-Security6, (3) la capacidad para integrarse con una base de datos relacional local como SQL Mobile. Las grandes debilidades de la plataforma son: (1) ser una subversión del framework por lo que muchas funcionalidades no estarán presentes, sin embargo esto es algo lógico si se desea desarrollar para este tipo de dispositivos, y (2) la inhabilidad de poder tener código del lado servidor, específicamente si se quieren exponer servicios para que otra aplicación lo contacte es algo que hace falta en la plataforma [4].. 4.2.. DOCTOR CHAT EN FUNCIONAMIENTO. En este punto se mostrarán algunos pantallazos del producto realizado que muestran la aplicación en funcionamiento. Para entrar en más detalle de los artefactos generados durante la etapa de análisis y del funcionamiento de la aplicación se debe remitir a los anexos del documento. Particularmente, ver Anexo A. Las Figura 16 y Figura 17 presentan las imágenes correspondientes a la aplicación final Dr. Chat.. 5 Versión compacta del .NET Framework de Microsoft enfocado a funcionar en dispositivos móviles, PDAs, y controladores de algunos periféricos. 6 Es un protocolo que provee una forma simple de seguridad en la invocación de Web Services agregando encabezados al mismo.. 32.

(33) Figura 16 - Ver noticias y realizar una consulta nueva. 33.

(34) Figura 17 - Ver consultas realizadas e información del paciente. 34.

(35) 4.3.. METRICAS. Dentro del contexto del desarrollo de una aplicación se emplean una serie de herramientas de análisis sobre el código generado. Dentro de éstas herramientas existen estrategias que apoyan el análisis. Una de estas estrategias es el conteo de líneas de código o LOC. En la Figura 18 se presentan la cantidad de líneas de código desarrollados tanto en la aplicación final como en cada componente.. Componente Adaptación 5%. Componente Comunicación 13%. LOC. Componente Conversión Datos 1%. Dr. Chat 51%. Componente Persistencia 14%. Componente Multimedia 9%. Qualdev Móvil Windows Mobile 7% Figura 18 - LOC de Dr. Chat y sus componentes. Sin embargo, estos resultados no son concluyentes por sí solos. Esto se debe a que el esfuerzo requerido para la producción del código correspondiente a Dr. Chat es menor al de los componentes en conjunto. A continuación, en la Figura 19, se presenta el esfuerzo requerido para la producción de cada una de las partes de la aplicación.. 35.

(36) Comp. Conversion de Datos 1%. Horas Dr. Chat 21%. Comp. Comunicación 26%. Comp. Adaptacion 13%. Comp. Persistencia 17%. Qualev Movil Windows Mobile 1% Comp. Multimedia 21%. Figura 19 - Esfuerzo requerido por Dr. Chat y sus componentes. Teniendo esto en cuenta, podemos observar como cada componente posee una cantidad de líneas de código considerables respecto a la aplicación final, la cual posee la mayor cantidad de LOC. Sin embargo, al comparar el esfuerzo requerido, podemos observar como el componente de comunicación y de multimedia requirieron mayor esfuerzo siendo que sus LOC son mucho menores. Esto apoya el factor de que la cantidad de LOC de Dr. Chat se debe a la forma en cómo crea los interfaces gráficas el editor del IDE empleado, más que el esfuerzo que implica el desarrollo. De esta forma, el esfuerzo requerido en la creación de una nueva aplicación que consuma estos componentes se reduce en un gran porcentaje respecto al requerido para el desarrollo de Dr. Chat.. 36.

(37) 5. VALIDACIÓN 5.1.. PRUEBAS DE SISTEMA. Las pruebas de sistema son aquellas que permiten ver el funcionamiento final de los requerimientos especificados para la aplicación. Dentro de este contexto, no se tienen en cuenta los componentes que intervienen en cada uno de ellos. Estas pruebas tienen en cuenta tanto los casos exitosos como los casos que deben modelar errores o caminos alternos. Para mayor detalle de las pruebas de sistema, ver Anexo H.. 5.2.. PRUEBAS DE INTEGRACIÓN. Las pruebas de integración permiten ver el comportamiento de los componentes cuando son consumidos por otros componentes o aplicaciones. De esta manera se pueden garantizar las funcionalidades de los mismos y el correcto manejo de las excepciones que se lanzan, así como los contratos de configuración. Para mayor detalle de las pruebas de integración, ver los Anexos I-L.. 5.3.. PRUEBAS UNITARIAS. Se realizaron pruebas unitarias sobre los componentes desarrollados para los cuales no es necesaria una interacción con otros componentes y/o aplicaciones. Estas pruebas fueron exitosas el 100% de las veces garantizando el correcto funcionamiento de las operaciones que ofrecen. Dentro de este contexto, fue posible realizar pruebas unitarias sobre el componente de persistencia y de comunicaciones. Estas pruebas tuvieron como objetivo probar cada una de las responsabilidades del componente de persistir, eliminar y obtener los objetos correspondientes a un tipo recibido como parámetro. El tipo se desconoce para garantizar la genericidad del componente. Para mayor detalle de las pruebas unitarias, ver los Anexos M-P.. 5.4.. RESULTADOS DE LA APLICACIÓN. Para poder asegurar el funcionamiento de la aplicación resultante, fue necesaria la implementación de una serie de pruebas en las cuales se definen unos escenarios de prueba con sus correspondientes casos de prueba. Dentro de las pruebas unitarias del componente de comunicaciones se probó el envió exitoso del mensaje por medio del protocolo HTTP Asíncrono. El primer intento fue fallido porque la implementación inicial del protocolo asíncrono se había pensado utilizando un mecanismo de notificación controlado por un 37.

(38) componente mediador dentro de la arquitectura, sin embargo al hacer el detalle de la misma, éste componente se obvió. Esto causó que el mecanismo de entrada de mensajes estuviera por implementar. Para la implementación se utilizó una estrategia de Patrón Observador (Ver Glosario) en donde la clase que quiera recibir los mensajes por protocolos asíncronos como HTTP Async y SMS sirviera para esto. Luego de esta implementación en resultado de la prueba fue exitoso. Este cambio en la implementación final tuvo un costo de 3 horas por persona hasta su finalización. Dentro de las pruebas de integración y de sistema, se detectaron una serie de errores de codificación en términos de validación de parámetros o condicionales. Estos errores implicaron un esfuerzo de corrección menor a 30 minutos por persona. Adicionalmente, se definieron unas métricas para los atributos de calidad identificados previamente. Estos atributos especifican las características deseadas en la aplicación final como prioridad. Teniendo esto en cuenta, es necesario validar el cumplimiento de éstos atributos por medio de sus métricas. El atributo de flexibilidad define la métrica siguiente: NUMERO ERRORES POSTERIOR CAMBIOS - NUMERO ERRORES PREVIO CAMBIOS = 0. Para garantizar el cumplimiento de esta métrica, se documentó a fondo el funcionamiento de cada componente con sus características y contratos de configuración, evitando así el incumplimiento del atributo de calidad de flexibilidad. El atributo de reusabilidad define la siguiente métrica: (LOC COMPONENTES / LOC DR. CHAT) * 100 > 70%. El cumplimiento de esta métrica se puede evidenciar en la sección 4.3 donde se exponen las LOC de cada componente y de la aplicación final. Tomando los valores que allí se presentan, podemos notar cómo se cumple con ésta métrica siendo que (3225/3386) * 100 = 95.24%. El atributo de mantenibilidad define la siguiente métrica: TIEMPO DE CORRECION DE ERRORES < 30 MIN. El cumplimiento de esta métrica se puede evidenciar en la descripción de las pruebas de sistema aplicadas y sus resultados, planteados previamente en ésta sección. 38.

(39) El atributo de extensibilidad define la siguiente métrica: ESFUERZO PARA EXTENDER FUNCIONALIDADES ≤ 3 H. El cumplimiento de esta métrica se puede evidenciar en la descripción que se realizó previamente de las pruebas unitarias de comunicaciones. Allí se expresa como la implementación de una extensión al componente, teniendo en cuenta este cambio como una funcionalidad nueva, no planeada; requirió un tiempo de desarrollo no mayor a 3 horas. Esto apoya el atributo de calidad planteado y su métrica.. 39.

(40) 6. CONCLUSIONES 6.1.. DISCUSIÓN. Dentro de los resultados obtenidos en el desarrollo del sistema, encontramos que el aprendizaje de la plataforma constituyó un factor importante en los tiempos de desarrollo invertidos. Windows Mobile es una plataforma sobre la que se desarrolla en C#. Esto implica que debimos aprender el lenguaje para el desarrollo del sistema. Aunque C# es un lenguaje orientado a objetos, lo que reduce los tiempos de aprendizaje, se convierte en una limitante en los inicios del proyecto. Por otro lado, Windows Mobile posee una documentación escasa o difícil de encontrar para apoyar el desarrollo, lo que obliga a navegar en internet en distintos recursos como foros en busca de la solución. De igual forma, Windows Mobile es un subconjunto de Windows o de la plataforma de desarrollo más conocida como el Compact Framework 3.5 lo que implica que no todas las funcionalidades disponibles en Windows lo están en Windows Mobile. Esto hace más difícil encontrar algoritmos que se puedan implementar y funcionen. Existen una serie de páginas web donde es posible apoyarse para el desarrollo de funcionalidades que Windows Mobile no provee. Entre ellas podemos encontrar:  http://www.planet-source-code.com/  http://www.sourcecodesworld.com/  http://www.codeproject.com/ Estas páginas presentan un apoyo al desarrollador ya que permiten obtener implementaciones realizadas por otras personas como open-source, las cuales pueden ser utilizadas en la implementación que se está desarrollando, disminuyendo el esfuerzo requerido en el proceso de codificación de la solución.. 6.2.. TRABAJO PENDIENTE. Teniendo en cuenta que el sistema desarrollado tiene un enfoque orientado a componentes, cada componente tiene aproximaciones que se deben tener en cuenta para el correcto funcionamiento del sistema. El componente de comunicaciones plantea a trabajo futuro extender su funcionalidad para permitir la transferencia de archivos multimedia como adjuntos, implementando una estrategia para enviar múltiples adjuntos en una misma trama para ahorro en el flujo de datos.. 40.

(41) El componente de persistencia plantea una implementación de la persistencia por medio de base de datos locales al dispositivo. Esto es posible implementarlo para mantener dos medios de persistencia en la aplicación: por archivos y por base de datos. Para ello, se plantea el uso de colas donde se guarden los objetos a persistir cuando el componente sólo maneja una forma de persistencia. De esta forma, cuando se cambie el modo de persistencia o cuando se apague el componente, es necesario persistir los objetos en la cola para mantener la información sincronizada. Por último, es importante dar correcto manejo a las excepciones que se lanzan desde el componente de adaptación para poder localizar con mayor puntualidad el componente responsable de la funcionalidad correspondiente.. 6.3.. TRABAJO FUTURO. Una vez se han identificado las funcionalidades necesarias para el correcto funcionamiento de la aplicación, es necesario determinar que funcionalidades o comportamientos son deseables modelar en la aplicación y pueden entrar en desarrollo para la producción del mismo. El componente de persistencia debe poder invocar los métodos GetObject recibiendo como parámetro un objeto del tipo deseado. Esto con el objetivo de poder iterar sobre un objeto con atributos constituidos ya que al ser el componente genérico no conoce los tipos a modelar por la aplicación o componente que lo consuma. La iteración sobre un objeto creado se hace con la librería Reflection de Windows Mobile. Una vez recibido el objeto, es posible reconstruirlo con los valores a retornar. Se desea poder hacer esto para evitar el retorno de un objeto tipo TempObject, el cual requiere de algorítmica adicional para obtener el resultado final. Adicionalmente, se desea poder manejar las asociaciones de objetos con otros objetos, así como la posibilidad de tener listas, ya sea de tipos simples u objetos. Por otra parte, el componente de multimedia propone investigar con mayor profundidad la compresión de archivos multimedia, particularmente los archivos de audio. Esta compresión se puede hacer en términos de configuración del bitrate del archivo ó la duración de la grabación. Para archivos multimedia de imagen y video, podría disminuirse la calidad de los archivos para disminuir su tamaño. Para mayor información en la compresión de archivos, revisar el siguiente enlace de MSDN para el framework de .NET 3.5: http://msdn.microsoft.com/es-es/library/system.io.compression%28v=VS.90%29.aspx. 41.

(42) De igual forma, se debe extender el componente de adaptación para considerar un comportamiento distinto al de simplemente apagar o enchufar componentes en ejecución. Para la aplicación de Doctor Chat, es necesario establecer un sistema de noticias que sea ofrecido por la Fundación Santa Fe, para recepción de la aplicación teniendo en cuenta los temas de las consultas realizadas por el usuario. Para ello, es necesario definir a mayor profundidad el protocolo a implementar y la información contenida en las noticias. De igual forma, se desea poder incluir manejo de 3D a la visualización de la aplicación para hacerla más amigable al usuario, así como permitir la representación de la anatomía humana para ser más especifico a la hora de señalar la ubicación del posible dolor al hacer la consulta al médico especializado.. 42.

(43) 7. BIBLIOGRAFÍA 1. Casal Terreros, J "Desarrollo de Software basado en Componentes". Consultado el 25 de marzo de 2010 de: http://msdn.microsoft.com/eses/library/bb972268.aspx 2. Gamma, Erich, & Helm, Richard, & Johnson, Ralph, & Vlissides, John (1994). "Design Patterns. Elements of Reusable Object-Oriented Software". Adisson - Wesley 3. Wigley, Andy, & Moth, Daniel, & Foot, Peter (2007) "Microsoft Mobile Development Handbook". Microsoft 4. Yao, Paul, & Durant, David (2010). ""Programming NET Compact Framework 3.5 Second Edition". Adisson - Wesley 5. Radinger, Andrej (2009). "Getting Started with Building Windows Mobile Solutions with Visual Studio and Windows Mobile 6 SDK". Consultado el 15 de febrero de 2010 de: http://msdn.microsoft.com/esco/library/dd721907%28en-us%29.aspx 6. Leroux Bustamante, Michele, & Landry, Nickolas (2009). ""WCG Guidance for Mobile Developers". Consultado el 20 de marzo de 2010 de: http://wcfguidanceformobile.codeplex.com/ 7. Lee, Wei-Meng (2008) "SMS Messaging Using the .NET Compact Framework". Consultado el 15 de abril de 2010 de: http://www.devx.com/wireless/Article/38571/0/page/1 8. Wilson, Jim. (2006) "The State and Notifications Broker Part I" Consultado el 1 abril de 2010 de: http://msdn.microsoft.com/enus/library/aa456240.aspx 9. Wilson, Jim. (2006) "The State and Notifications Broker Part II" Consultado el 1 abril de 2010 de: http://msdn.microsoft.com/enus/library/bb286907.aspx. 43.

(44) 10. Wilson, Jim. (2006) "The State and Notifications Broker Part III" Consultado el 3 abril de 2010 de: http://msdn.microsoft.com/enus/library/bb499669.aspx 11. Obajanjo, Dare. "A comparison of Microsoft C# Programming Language to Sun Microsystems Java Programming Language". Consultado el 15 de febrero de 2010 de: http://www.25hoursaday.com/CsharpVsJava.html 12. Lhotka, Rockford. (2006) "Expert C# 2005 Business Objects, Second Edition". Apress 13. J. Mylopoulos, L. Chung, B. Nixon, Representing and Using Nonfunctional Requirements: A Process-Oriented Approach, IEEE Transactions on Software Engineering, v.18 n.6, p.483-497, June 1992 [doi>10.1109/32.142871]. 44.

(45) 8. GLOSARIO . Patrón Singleton Es un patrón de diseño que asegura que sólo haya una instancia de la clase dando un punto global de acceso a la misma.. . Patrón Modelo, Vista, Controlador (MVC) Es un estilo arquitectural para cualquier aplicación que separa los datos de la aplicación, con la interfaz de usuario y con la lógica del negocio.. . Patrón Plantilla Es un patrón de comportamiento usado cuando la algorítmica de algún método es cambiante pero alguna parte del mismo se puede reutilizar, entonces se implementa con un método común que llama métodos abstractos que alguien los extiende para lograr la funcionalidad específica.. . Patrón Observador Es un patrón de comportamiento usado cuando un objeto puede registrarse dinámicamente como dependiente de otro, este otro lo notifica cada vez que su estado interno cambia, también conocido como patrón suscriptor publicador.. 45.

(46) 9. ANEXOS A. Dr. Chat Introducción Doctor Chat Móvil hace parte de un proyecto del grupo de investigación Qualdev de la Universidad de los Andes, que pretende colaborar con la División de Educación de la Fundación Santa Fe a través del uso de tecnologías de plataformas móviles para la extensión del servicio Doctor Chat. Esta aplicación es la implementación para la plataforma Windows Mobile. Descripción de la Aplicación Doctor Chat Móvil es una aplicación cliente que debe interactuar con un servidor para suplir las necesidades de enviar consultas y de recibir contestación a las mismas. El servidor es algo común para los distintos clientes móviles desarrollados en otras plataformas por lo que no se hará un énfasis en esta parte. Doctor Chat como aplicación móvil cuenta con una serie de requerimientos muy básicos pero que necesitan la interacción de distintas funcionalidades específicas como comunicaciones, persistencia y multimedia que son comunes para cualquier aplicación celular. Estas funcionalidades son provistas por un componente externo desarrollado por nosotros, que permite aislar la interacción del framework de Windows Mobile con una aplicación concreta como Doctor Chat. Funcionalidades de la Aplicación La aplicación como tal tiene cinco requerimientos los cuales son: registrar los datos de un paciente, registrar una consulta, editar los datos de un paciente, ver las consultas realizadas y editar las consultas realizadas. Las funcionalidades de la aplicación están basadas en los requerimientos de la misma, con algunas inclusiones realizadas que sería interesantes tenerlas en funcionamiento como un suministro de noticias. Para tener una concepción real de que es lo que se quiere realizar, se hizo un análisis de las entidades para las funcionalidades de consultas y suministro de noticias.. 46.

(47) Funcionalidades Principales En Doctor Chat es posible tener registrado un paciente que para cada nueva consulta deberá ser referenciado por la misma. Cada Consulta además de tener un paciente, podrá recibir una respuesta. La estructura de las funcionalidades principales es expresada en la Figura 20.. Figura 20 - Estructura de funcionalidades principales. Suministro de Noticias Es posible la recepción de noticias en la aplicación provenientes de la Fundación Santa Fe. Estas noticias son particulares de cada usuario y se presentan acorde a los intereses y preocupaciones del usuario en cuanto a las consultas realizadas. Las noticias se caracterizan por la manera expresada en la Figura 21.. Figura 21 - Estructura del suministro de noticias. Diseño de la Aplicación Diseño General El diseño general de la aplicación (Ver Figura 22) se basa en un patrón Modelo, Vista, Controlador, en donde el controlador será el encargado de orquestar el 47.

(48) funcionamiento de la misma. En la vista simplemente se manejaran la lógica de despliegue en la Interfaz, y en el modelo simplemente encontraremos las entidades relevantes de la aplicación. Las funcionalidades de comunicaciones, persistencia y multimedia están encapsuladas en el componente de Qualdev Windows Mobile el cual Dr. Chat consumirá a través de una interfaz. Es por ello que Doctor Chat como tal es muy sencillo porque toda la parte que involucra la interacción con el framework de Windows Mobile esta encapsulado en un componente aislado y reutilizable.. Figura 22 - Diseño general de la aplicación. Diseño Especifico UI El diseño específico de la interfaz del usuario se basa en una clase para cada pantalla, en donde cada pantalla tendrá la responsabilidad de interactuar con el controlador. La pantalla principal será la contenedora de las demás pantallas y algunas de ellas contendrán a las que dependan de ella, todo esto para la correcta visualización de las mismas. El diseño se puede ver en la Figura 23.. 48.

(49) Figura 23 - Diseño específico del user interface. Diseño Específico Controlador El diseño específico del controlador de la aplicación se basa en una interfaz que expone los servicios del mismo y su implementación que es un 'Singleton' el cual interactúa con el componente de Qualdev Windows Mobile a través de su interfaz. Además una clase de utilidades que posee funcionalidades de instanciación de objetos del modelo. El diseño se puede ver en la Figura 24.. Figura 24 - Diseño específico del controlador. 49.

(50) B. DoctorCh@t Móvil y DoctorCh@t Móvil GeoReferencia Documento de Grado de Sebastián Rojas donde se detalla la aplicación original de Doctor Chat para la plataforma Java Mobile Edition.. C. Componente de Adaptación Descripción Componente Encargado de proveer el servicio de que la aplicación se adapte a cambios generados por el dispositivo móvil que puedan afectar el correcto funcionamiento de la misma. Funciones del Componente Encargado de adaptar la aplicación a cambios en el dispositivo, para que la aplicación pueda tener un comportamiento adecuado con los recursos disponibles del celular. Inicialmente solo se monitoreara la batería del dispositivo. Con estas propiedades se podrá economizar el uso de la memoria cuando hay escasez de batería. Diseño del Componente. Figura 25 - Estructura del componente de adaptación. Definición de Interfaces. Figura 26 - Interfaces del componente de adaptación. 50.