DESARROLLO DE UNA ARQUITECTURA REUTILIZABLE BASADA …
136
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.
Transcript of DESARROLLO DE UNA ARQUITECTURA REUTILIZABLE BASADA …
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.
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
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 WINDOWS 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
5
Escenarios de Pruebas.......................................................................................... 92 P. PRUEBAS UNITARIAS COMPONENTE PERSISTENCIA ............................................... 95
Introducción ........................................................................................................... 95 Escenarios de Pruebas.......................................................................................... 96
Q. DESPLIEGUE DE UNA APLICACIÓN EN UN DISPOSITIVO BASADO EN WINDOWS 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 WINDOWS 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
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
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
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
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.
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.
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.
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.
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 Responsabilidad
Rafael Meneses Asesor Coordina el progreso del proyecto y las
funcionalidades con las que debe cumplir.
Camilo Varela Líder Coordina las tareas a realizar semanalmente y
el progreso del sistema como un todo.
Laura Manzur Planeación,
Desarrollador
Velar por el cumplimiento de las tareas de la
semana. Desarrollar componentes del
sistema.
Carlos Toro Pruebas,
Desarrollador
Desarrollar componentes del sistema.
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
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
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
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
31
Figura 15 - Diagrama de clases controlador Dr. Chat
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.
33
Figura 16 - Ver noticias y realizar una consulta nueva
34
Figura 17 - Ver consultas realizadas e información del paciente
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.
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.
Dr. Chat51%
Qualdev Móvil Windows Mobile
7%
Componente Multimedia
9%
Componente Persistencia
14%
Componente Adaptación
5%
Componente Comunicación
13%
Componente Conversión Datos
1%
LOC
36
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.
Dr. Chat21%
Qualev Movil Windows
Mobile1%
Comp. Multimedia
21%Comp.
Persistencia17%
Comp. Adaptacion
13%
Comp. Comunicación
26%
Comp. Conversion de
Datos1%
Horas
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
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.
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.
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.
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
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.
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/es-
es/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/es-
co/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/en-
us/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/en-
us/library/bb286907.aspx
44
10. Wilson, Jim. (2006) "The State and Notifications Broker Part III"
Consultado el 3 abril de 2010 de: http://msdn.microsoft.com/en-
us/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]
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.
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.
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
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.
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
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
51
Descripción Detallada
Descripción
El componente se basa en tener instaladas propiedades en la cual cada una
será capaz de cambiar el comportamiento de la aplicación cuando se generen
cambios en la misma. Por defecto podrán ser instanciadas dos propiedades que
se encargaran de detener ó iniciar componentes de la arquitectura monitoreando
el estado de la batería del celular.
Para hacer posible la extensibilidad del componente se deberá extender la
funcionalidad de la clase abstracta la cual encapsula los llamados a los métodos
de la arquitectura y a su vez de los servicios básicos de cada propiedad el cual
es su correcta inicialización y el manejo de los eventos referentes a los cambios
de la propiedad monitoreada.
Cada propiedad cuenta con dos modos de operación, el modo persistente y el
modo no persistente. El primero básicamente usará la propiedad del identificador
de la aplicación suministrado al componente (Ver Contrato de Configuración)
para registrar la propiedad en el registro del dispositivo móvil para que en
cualquier momento que esta propiedad cambie se le notifique a la aplicación así
no se encuentre corriendo; el modo no persistente simplemente significa que la
propiedad solo estará en servicio cuando la aplicación se esté corriendo.
Contrato de Configuración
Para poder usar el componente se debe cumplir el contrato el cual es definir el id
de la aplicación el cual se insertara en el registro del sistema operativo del
dispositivo móvil para poder notificar a la aplicación del cambio de cada
propiedad monitoreada así no esté inicializada.
Este debe ser un cadena de caracteres la cual cada propiedad le agregara un
sufijo. Por ejemplo la que recibirá el componente será: "QMaplicacionMovil" y
cada propiedad le agregara un sufijo de tipo: ".BatteryLevel" que será inherente
a cada propiedad.
52
Diagrama de Clases
Figura 27 - Diagrama de clases del componente de adaptación
Referencias
The State and Notifications Broker API Part 1
http://msdn.microsoft.com/en-us/library/aa456240.aspx
The State and Notifications Broker API Part 2
http://msdn.microsoft.com/en-us/library/aa456240.aspx
The State and Notifications Broker API Part 3
http://msdn.microsoft.com/en-us/library/bb499669.aspx
53
Microsoft Mobile Development Handbook 2007
D. Componente de Comunicaciones
Descripción Componente
Se encarga de la comunicación de la aplicación con su exterior por distintos
protocolos. Estos protocolos se implementaron de tal forma que se vuelva
transparente el uso de la tecnología específica proveyendo servicios simples de
usar.
Funciones del Componente
Encargado del envío y recepción de flujos de datos necesarios para el correcto
funcionamiento de la aplicación con su entorno
Diseño del Componente
Figura 28 - Estructura del componente de comunicaciones
54
Definición de Interfaces
Figura 29 - Interfaces del componente de comuniaciones
Descripción Communication Facade
Descripción
Es la fachada del componente, encargado de exponer los servicios expuestos
por la implementación de cada protocolo en particular. Los posibles mensajes
que lleguen por medio de un protocolo Asíncrono serán notificados a este
componente el cual llamara al Sujeto del Patrón Observador para que notifique a
todos los observadores. Todos los Observadores que quieran recibir los
mensajes que lleguen por un protocolo Asíncrono deberán inscribirse como
observadores con la Fachada y por ende implementar la Interfaz
ICommunicationObserver.
55
Diagrama de Clases
Figura 30 - Diagrama de clases de CommunicationFacade
Descripción SMS Component
Descripción
Componente encargado de enviar y recibir mensajes por medio del protocolo
SMS. Al iniciar el componente la aplicación es capaz de filtrar los mensajes SMS
recibidos en el dispositivo para determinar si le pertenece o no.
Dada la restricción de caracteres del protocolo SMS (70 Caracteres en Unicode
o 160 en ASCII) se implemento una estrategia para generar los mensajes SMS
multiparte necesarios para enviar la información necesaria. Para ello se definió
un header en el mensaje que aparte del formato contiene la información
necesaria para que los mensajes en la recepción puedan ser unidos sin ningún
inconveniente.
Para la recepción de mensajes se implemento por medio del patrón estrategia
una forma de poder tener diferentes estrategias de recepción de mensajes
multiparte, para que en ejecución pueda ser seleccionada la estrategia más
adecuada en términos de desempeño, confiabilidad, y uso de recursos.
Actualmente solo se implemento una estrategia simple que como propósito es
muy similar al UDP el cual es entregar solo los mensajes que lleguen
56
correctamente. Para esto se almacena en un buffer cada parte del mensaje
multiparte, si llegase la parte de un mensaje no correspondiente a los guardados
en el buffer, el nuevo mensaje es almacenado y los demás son descartados.
Adicionalmente se definió un TTL(Time to Live) en el cual si el mensaje no se
completa el buffer será limpiado para no recargar la memoria del dispositivo
móvil.
Contrato de Configuración
Para poder usar el componente se debe cumplir el contrato el cual es definir el
Número Celular del Servidor y un Formato de mínimo 3 caracteres y máximo 6
caracteres que será el header de los mensajes generados para su correcta
identificación a la hora de enviar y recibirlos.
Diagrama de Clases
Figura 31 - Diagrama de clases del SMS component
Descripción HTTP Component
Descripción
Este componente provee el servicio para enviar mensajes de manera asíncrona
y síncrona a la URL especificada abstrayendo la implementación de la
tecnología volviendo transparente el envío de información a través del protocolo
HTTP.
57
Diagrama de Clases
Figura 32 - Diagrama de clases del HTTP component
E. Componente de Conversión de Datos
Descripción 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 se implemento la transformación a JSON por
medio de una librería externa que nos ayudo a la implementación del mismo.
Funciones del Componente
Encargado de la transformación de objetos de negocio a un formato de
intercambio y viceversa.
Diseño del Componente
Figura 33 - Estructura del componente de conversión de datos
58
Definición de Interfaces
Figura 34 - Interfaces del componente de conversión de datos
Descripción Detallada
Descripción
Al ser un componente tan sencillo, no se ve la necesidad de implementar
métodos para la inicialización o destrucción del mismo durante la ejecución para
el ahorro de recursos. Entonces los únicos servicios que expone el Componente
es la de serializar o de serializar un objeto del negocio de la aplicación en
formatos de intercambio. En este caso solo se implemento la transformación a
JSON ya que resulta más adecuado para el flujo de datos en aplicaciones
móviles por su tamaño más compacto con respecto a XML.
El Contrato del componente es enviar el objeto con sus propiedades definidas e
inicializadas para que al momento de serializar por medio de mecanismos de
reflexión se pueda generar el resultado esperado con mucha facilidad para el
que use el componente. De la misma manera para la de serialización del mismo
se debe enviar una referencia al objeto que debería construirse con la
información del JSON, XML o propietario en cuestión y el resultado será el
objeto con la información adecuada.
Diagrama de Clases
Figura 35 - Diagrama de clases del componente de conversión de datos
59
F. Componente de Manejo de Multimedia
Introducción
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.
A continuación se presenta la estructura del componente de multimedia así
como el contrato de configuración del mismo.
Estructura del Componente de Multimedia
El componente de multimedia posee una estructura sencilla para la
comunicación con demás componentes que se van a utilizar en la aplicación. 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 36 - Estructura del componente de multimedia
Definición de Interfaces
Las interfaces son las que exponen los servicios de cada componente. A
continuación se definen los mismos para el consumo interno y externo del
componente.
60
Figura 37 - Interfaces del componente
Componente MediaManipulator
El componente MediaManipulator se encarga de exponer los servicios generales
de obtención de archivos multimedia. La estructura de este componente es la
siguiente.
Figura 38 - Diagrama de clases del componente MediaManipulator
61
Componente InputMedia
El componente InputMedia expone los servicios de captura de archivos ya sea
mediante los dispositivos del equipo o los archivos existentes. La estructura del
componente es la siguiente.
Figura 39 - Diagrama de clases del componente InputMedia
Contrato de Configuración
Para la correcta utilización del componente de multimedia, es necesario respetar
las restricciones que impone el componente. Para la comunicación con el
componente, se utiliza la interfaz IMediaManipulator, la cual posee un método
attachMedia, el cual recibe como parámetro un IDictionary.
Un IDictionary funciona como un mapa de hash el cual permite asociar un valor
a una llave para la fácil localización de la información necesaria. La Tabla 2
muestra la información requerida a ser pasada en el IDictionary al componente
para su correcto funcionamiento.
62
Tabla 2 - Información requerida en IDictionary
Llave Valor
tipo imagen, audio, video
obtención dispositivo, directorio
anchoImagen Numérico
altoImagen Numérico
maxDuracion Numérico
G. Componente de Persistencia
Introducción
La persistencia es un factor muy importante en cualquier tipo de aplicaciones ya
que permite guardar 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.
A continuación se presenta la estructura del componente de persistencia con sus
correspondientes diagramas.
Estructura del Componente de Persistencia
El componente de persistencia posee una estructura sencilla, 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
comunica con las interfaces de los servicios de persistencia por archivos y de
persistencia por base de datos. La base de datos se soporta sobre la librería de
SQLite y los archivos se soportan sobre el framework de Windows Mobile.
Figura 40 - Estructura del componente de persistencia
63
Definición de Interfaces
Las interfaces son las que exponen los servicios de cada componente. A
continuación se definen los mismos para el consumo interno y externo del
componente.
Figura 41 - Interfaces del componente
Componente PersistenceManager
El componente PersistenceManager se encarga de exponer los diferentes
servicios de persistencia y controlar el modo en que se persiste la información,
ya sea por archivos o por base de datos. La estructura de este componente es la
siguiente.
Figura 42 - Diagrama de clases del componente PersistenceManager
64
Componente FilePersistence
El componente FilePersistence expone los servicios de persistencia en archivos.
La estructura del componente es la siguiente.
Figura 43 - Diagrama de clases del componente FilePersistence
Manejo de Retornos
Los métodos GetObject y GetAllObjects retornan un objeto de tipo TempObject.
Este objeto posee una colección de objetos de tipo TempAttribute. Los
TempAttribute tienen un nombre y un valor. Luego de invocar un método que
retorne este objeto, es necesario iterar sobre los TempAttribute y buscar los que
tiene el atributo nombre con valor del nombre de los atributos de la clase
resultado.
Componente DbPersistence
El componente DbPersistence expone los servicios de persistencia en archivos.
La estructura del componente es la siguiente.
65
Figura 44 - Diagrama de clases del componente DbPersistence
Es necesario recalcar que para el correcto funcionamiento de los métodos de
persistencia, todas las clases que se persisten deben tener un atributo id para
efectos de identificación de los mismos al momento de buscarlos.
H. Pruebas de Sistema Dr. Chat Windows Mobile
Introducción
Para lograr ver el efectivo funcionamiento de Dr. Chat, se realizaron pruebas de
caja negra o de sistema contra los requerimientos especificados, simplemente
es la documentación de los resultados esperados interactuando con la aplicación
final.
Escenarios de Pruebas
Para los escenarios de pruebas se probó sobre el proyecto real de Dr. Chat sin
generar una implementación real para las mismas.
Escenario de Prueba 1
Nombre: Registrar Datos de Paciente
Objetivo: Probar que se registren exitosamente los datos de un paciente en el
formulario destinado para ello. Por debajo se probará el componente de
Persistencia que es el único que interviene en este requerimiento.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia
no Válidas aliasPaciente String Letras Nulo
66
edad Short Número Letras, Nulo genero Short Número Letras, Nulo estadoCivil Short Número Letras, Nulo profesionOcupacion String Letras Nulo pais Short Número Letras, Nulo ciudad Short Número Letras, Nulo email String Letras Nulo emailConfirmacion String Letras Nulo formadecontestacion Short Número Letras, Nulo
Casos de Prueba
Caso de Prueba: CP1 – Hay campos sin diligenciar en el formulario
a. Condiciones de Entrada
Condición de Entrada
Valor
aliasPaciente edad 55 genero 1 estadoCivil profesionOcupacion Tester pais ciudad 1 email [email protected] emailConfirmacion formadecontestacion 2
b. Resultado Esperado
i. Response:
Debe escribir un nombre o alias
Debe seleccionar un estado civil
Debe seleccionar un país
Debe ingresar un email válido y la confirmación debe ser el mismo
email.
Caso de Prueba: CP2 – La edad no puede ser expresada en caracteres
a. Condiciones de Entrada
Condición de Entrada
Valor
aliasPaciente Registrar Paciente edad cin genero 1 estadoCivil 1 profesionOcupacion Tester
67
pais 57 ciudad 1 email [email protected] emailConfirmacion [email protected] formadecontestacion 2
b. Resultado Esperado
i. Response: La edad debe ser numérica.
Caso de Prueba: CP3 – Paciente Guardado Exitosamente.
a. Condiciones de Entrada
Condición de Entrada
Valor
aliasPaciente Registrar Paciente edad 55 genero 1 estadoCivil 1 profesionOcupacion Tester pais 57 ciudad 1 email [email protected] emailConfirmacion [email protected] formadecontestacion 2
b. Resultado Esperado
i. Response: Se guardo la información del Paciente Correctamente.
Escenario de Prueba 2
Nombre: Editar Datos de Paciente
Objetivo: Probar que se editen exitosamente los datos de un paciente en el
formulario destinado para ello. Por debajo se probará el componente de
Persistencia que es el único que interviene en este requerimiento.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia
no Válidas aliasPaciente String Letras Nulo edad Short Número Letras, Nulo genero Short Número Letras, Nulo estadoCivil Short Número Letras, Nulo profesionOcupacion String Letras Nulo pais Short Número Letras, Nulo
68
ciudad Short Número Letras, Nulo email String Letras Nulo emailConfirmacion String Letras Nulo formadecontestacion Short Número Letras, Nulo
Casos de Prueba
Caso de Prueba: CP1 – Hay campos sin diligenciar en el formulario
a. Condiciones de Entrada
Condición de Entrada
Valor
aliasPaciente Editar Paciente edad genero 1 estadoCivil 1 profesionOcupacion pais 57 ciudad 1 email [email protected] emailConfirmacion [email protected] formadecontestacion 2
b. Resultado Esperado
i. Response:
La edad debe ser numérica
Debe escribir una profesión u ocupación
Caso de Prueba: CP2 – El paciente se edito satisfactoriamente
a. Condiciones de Entrada
Condición de Entrada
Valor
aliasPaciente Editar Paciente edad 55 genero 1 estadoCivil 1 profesionOcupacion Tester pais 57 ciudad 1 email [email protected] emailConfirmacion [email protected] formadecontestacion 2
b. Resultado Esperado
i. Response: Se guardo la información del Paciente Correctamente.
69
Caso de Prueba: CP3 – Al recargar el panel con la información del paciente se
muestran los datos de la última edición.
a. Condiciones de Entrada
Se sale e ingresa nuevamente al Panel con la información del paciente
para validar que los datos son los correctos.
b. Resultado Esperado
Condición de Salida Valor aliasPaciente Editar Paciente edad 55 genero 1 estadoCivil 1 profesionOcupacion Tester pais 57 ciudad 1 email [email protected] emailConfirmacion [email protected] formadecontestacion 2
Escenario de Prueba 3
Nombre: Registrar consulta
Objetivo: Probar que registre exitosamente una consulta de un paciente en el
formulario destinado para ello. Por debajo se probará el componente de
Persistencia, Multimedia y Comunicación.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia
no Válidas consulta String Letras Nulo adjuntos List<String> Letras
Casos de Prueba
Caso de Prueba: CP1 – No se ingresa una consulta pero si adjuntos
a. Condiciones de Entrada
Condición de Entrada
Valor
consulta adjuntos \\My Documents\My Pictures\Flower.jpg
\\My Documents\Notes\rec63404256121000.wav
70
b. Resultado Esperado
i. Response: Ingrese una Consulta
Caso de Prueba: CP2 – No se ingresan adjuntos pero si una consulta
a. Condiciones de Entrada
Condición de Entrada
Valor
consulta Registrar consulta adjuntos
b. Resultado Esperado
i. Response: Se envió la consulta satisfactoriamente.
Caso de Prueba: CP3 – Se ingresa tanto una consulta como adjuntos
a. Condiciones de Entrada
Condición de Entrada
Valor
consulta Registrar consulta adjuntos \\My Documents\My Pictures\Flower.jpg
\\My Documents\Notes\rec63404256121000.wav
b. Resultado Esperado
i. Response: Se envió la consulta satisfactoriamente.
Escenario de Prueba 4
Nombre: Ver consultas realizadas
Objetivo: Probar que se visualicen exitosamente las consultas realizadas por un
paciente en el formulario destinado para ello. Por debajo se probará el
componente de Persistencia y Comunicación.
Clases de Equivalencia
No hay.
Casos de Prueba
Caso de Prueba: CP1 – Ver consultas realizadas
a. Condiciones de Entrada
No hay.
b. Resultado Esperado
71
i. Response: Listado de consultas realizadas.
Escenario de Prueba 5
Nombre: Editar consultas realizadas
Objetivo: Probar que se editen (borren) exitosamente las consultas realizadas
por un paciente en el formulario destinado para ello. Por debajo se probará el
componente de Persistencia.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia
no Válidas idConsulta Int64 Número Letras, Nulo
Casos de Prueba
Caso de Prueba: CP1 – Borrar consulta realizada
a. Condiciones de Entrada
Condición de Entrada
Valor
idConsulta 20100518004849000
b. Resultado Esperado
i. Response: La consulta fue borrada exitosamente.
Resultados de las Pruebas La ejecución de las pruebas se muestra en el siguiente formato.
Escenario de Prueba 1
Caso de Prueba: CP1 – Hay campos sin diligenciar en el formulario
Primer Intento Exitoso
Caso de Prueba: CP2 – La edad no puede ser expresada en caracteres
Primer Intento Exitoso
72
Caso de Prueba: CP3 – Paciente Guardado Exitosamente.
Primer Intento Exitoso
Escenario de Prueba 2
Caso de Prueba: CP1 – Hay campos sin diligenciar en el formulario.
Primer Intento Exitoso
Caso de Prueba: CP2 – El paciente se edito satisfactoriamente.
Primer Intento Exitoso
73
Caso de Prueba: CP3 – Al recargar el panel con la información del
paciente se muestran los datos de la última edición.
Primer Intento Exitoso
Escenario de Prueba 3
Caso de Prueba: CP1 – No se ingresa una consulta pero si adjuntos
Caso de Prueba: CP2 – No se ingresan adjuntos pero si una consulta
74
Caso de Prueba: CP3 – Se ingresa tanto una consulta como adjuntos
Escenario de Prueba 4
Caso de Prueba: CP1 – Ver consultas realizadas
Escenario de Prueba 5
Caso de Prueba: CP1 – Borrar consulta realizada
75
I. Pruebas Integración Componente Adaptación
Introducción
Para lograr ver la funcionalidad del componente de Adaptación se creara un
cliente que muestre el estado de los componentes de la arquitectura de Qualdev
Windows Mobile y de como el cambio en el estado de la batería generará
cambios en el estado de los componentes de la Arquitectura.
Escenarios de Pruebas
Para los escenarios de pruebas se decidió crear un cliente móvil que en pantalla
muestre el estado de los componentes.
Escenario de Prueba 1
Nombre: Correcta funcionalidad del componente con la propiedad del nivel de la
batería
Objetivo: Probar el correcto funcionamiento de los componentes generando
cambios en el nivel de la batería y certificar el cambio de los mismos.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia Válidas
Clases de Equivalencia no
Válidas
baterryLevel BatteryLevel
BatteryLevel
Nulo
Casos de Prueba
Caso de Prueba: CP1 – Los componentes de la arquitectura se detengan
cuando la batería este muy baja.
a. Condiciones de Entrada
Condición de Entrada
Valor
76
baterryLevel VeryLow
b. Resultado Esperado
i. Response:
HttpComponent : Stopped
PersistenceComponent : Stopped
MultimediaComponent : Stopped
Caso de Prueba: CP2 – Los componentes de la arquitectura se arrancan
cuando la batería pase a un estado con alta disponibilidad.
a. Condiciones de Entrada
Condición de Entrada
Valor
baterryLevel High
b. Resultado Esperado
i. Response:
HttpComponent : Started
PersistenceComponent : Started
MultimediaComponent : Started
Resultados de las Pruebas
La ejecución de las pruebas se muestra en el siguiente formato.
Escenario de Prueba 1
Caso de Prueba: CP1 – Los componentes de la arquitectura se detengan
cuando la batería este muy baja.
Resultado Exitoso
Caso de Prueba: CP2 – Los componentes de la arquitectura se arrancan
cuando la batería pase a un estado con alta disponibilidad.
Resultado Exitoso
77
J. Pruebas Integración Componente Comunicaciones y Conversión de Datos
Introducción
Para lograr ver la interacción entre los componentes de Comunicaciones y
Conversión de datos se realizaron pruebas de Caja Negra en donde se quería
probar el comportamiento de los Componentes en un contexto real.
Adicionalmente se encontrara el proyecto base en el cual se realizaron estas
pruebas.
Escenarios de Pruebas
Para los escenarios de pruebas se decidió interactuar con el Intermediario del
caso de estudio de DR. Chat el cual será probado con los requerimientos de
registrar un paciente y enviar una consulta. Adicionalmente se probara el
Componente de SMS con datos precisos.
Escenario de Prueba 1
Nombre: Envíos exitosos para registrar y enviar una consulta
Objetivo: Probar que se registre un paciente exitosamente y que se envié una
consulta exitosamente. Comprobando que la respuesta del servidor sea la
adecuada. En los métodos Síncrono y Asíncrono.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
consulta Consulta Consulta
{id, IMEI, texto,
consecutivo,
latitud, longitud,
conCoordenadas,
sector }
Nulo
78
paciente Paciente Paciente
{id, IMEI, aliasPaciente,
edad, genero,
estadoCivil,
profesionOcupacion,
pais,ciudad, email,
formadecontestacion}
Nulo
url String Letras Nulo
Casos de Prueba
Caso de Prueba: CP1 – Registro del Paciente exitoso por medio del protocolo
HTTP Síncrono
a. Condiciones de Entrada
Condición de
Entrada
Valor
consulta c.id=123;
c.IMEI="123";
c.texto="Texto!!";
c.consecutivo=123456;
c.latitud=0.0;
c.longitud=0.0;
c.conCoordenadas=false;
c.sector=3;
URL http://157.253.204.33:8080/DrChatWebAdapter/Pregunta
b. Resultado Esperado
i. Response: Json con el Exitoso!
Caso de Prueba: CP2 – Envío de Consulta exitoso por medio del protocolo
HTTP Asíncrono
a. Condiciones de Entrada
Condición de
Entrada
Valor
paciente p.id = 1;
p.ciudad = 1;
p.genero = 1;
p.pais = 57;
p.IMEI = "127";
p.email = "[email protected]";
p.estadoCivil = 1;
p.formadecontestacion = 0;
p.edad = 21;
p.aliasPaciente = "Pepo";
p.profesionOcupacion = "Estudiante";
URL http://157.253.204.33:8080/DrChatWebAdapter/Paciente
b. Resultado Esperado
79
i. Ninguno
ii. Los Observadores sean notificados con el response del servidor: Json
con el Exitoso!
Escenario de Prueba 2
Nombre: Envió Exitoso del Mensaje Por Medio del Protocolo SMS
Objetivo: Probar que los métodos del Componente SMS Funcionen
Adecuadamente.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
smsComponent ISMSComponent SMSComponent Nulo
Format String Letras Menor a 3 Caracteres Mayor a 6 caracteres
ServerNumber String Letras Nulo
Casos de Prueba
Caso de Prueba: CP1 – Número requerido de Mensajes es Adecuado con ASCII
y se envía el Mensaje
a. Condiciones de Entrada
Condición de Entrada Valor
Message "Mensaje a Enviar por SMS con 180 caracteres. Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno"
b. Resultado Esperado
i. Se Necesitan 2 SMS para enviar el Mensaje
ii. El Mensaje fue Enviado Exitosamente en 2 Mensajes Distintos
Caso de Prueba: CP2 – Número requerido de Mensajes es Adecuado con
UNICODE y se envía el mensaje
a. Condiciones de Entrada
Condición de Entrada Valor
Message "Mensaje a Enviar por SMS con 210 caracteres algunos especiales como la
80
ñ. Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno!"
b. Resultado Esperado
i. Se Necesitan 4 SMS para enviar el Mensaje
ii. El Mensaje fue Enviado Exitosamente en 4 Mensajes Distintos
Resultados de las Pruebas
La ejecución de las pruebas se muestra en el siguiente formato.
Escenario de Prueba 1
Caso de Prueba: CP1 – Registro del Paciente exitoso por medio del
protocolo HTTP Síncrono
Se registra el paciente exitosamente codificando los parámetros en un
mensaje de salida JSON correcto, sin embargo el mensaje JSON de
respuesta hace referencia a un error que se sale del contexto puesto que
es relevante al servidor y no a la aplicación móvil que en este caso es el
Cliente.
Caso de Prueba: CP2 – Envío de Consulta exitoso por medio del
protocolo HTTP Asíncrono
Se hace la consulta exitosamente codificando los parámetros en un
mensaje de salida JSON correcto, sin embargo el mensaje JSON de
respuesta hace referencia a un error que se sale del contexto puesto que
es relevante al servidor y no a la aplicación móvil que en este caso es el
Cliente. La respuesta se muestra en interfaz en el momento en que llega
al ser un pedido asíncrono. Sin embargo al ejecutar otra prueba hubo
problema de conexión GPRS y en el componente no se hace un correcto
tratamiento con las excepciones por lo que la aplicación se interrumpe, lo
que incurre a hacer unos cambios en este aspecto al Componente de
Comunicaciones HTTP
Escenario de Prueba 2
Caso de Prueba: CP1 – Número requerido de Mensajes es Adecuado con
ASCII y se envía el Mensaje
Se esperaba que con el header y el mensaje a Enviar se necesitaran dos
mensajes y los mismos fueran enviados. Al ejecutar la prueba el resultado
fue exitoso y por medio del Cellular Emulator se certifico el contenido de
los mensajes salientes.
81
Caso de Prueba: Caso de Prueba: CP2 – Número requerido de Mensajes
es Adecuado con UNICODE y se envía el mensaje
Se esperaba que con el header y el mensaje a Enviar se necesitaran
cuatro mensajes y los mismos fueran enviados. Al ejecutar la prueba el
resultado fue exitoso y por medio del Cellular Emulator se certifico el
contenido de los mensajes salientes.
K. Pruebas de Integración Componente Multimedia
Introducción
Para lograr ver la interacción entre el componente de multimedia y la aplicación
componente que lo consuma, se realizaron pruebas de Caja Negra en donde se
quería probar el comportamiento del componente en un contexto real.
Escenarios de Pruebas
Nombre: Captura exitosa de elementos multimedia.
Objetivo: Probar que se capturan exitosamente los diferentes tipos de
multimedia.
Clases de Equivalencia
82
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
tipo String imagen, audio, video
Vacío Valores diferentes
obtención String dispositivo, directorio
Vacío Valor diferentes
Casos de Prueba
Caso de Prueba: CP1 – Captura de imagen desde cámara
a. Condiciones de Entrada
Condición de Entrada Valor
tipo imagen
obtención dispositivo
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP2 – Captura de imagen desde sistema de archivos
a. Condiciones de Entrada
Condición de Entrada Valor
tipo imagen
obtención directorio
b. Resultado Esperado i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP3 – Captura de audio desde grabadora
a. Condiciones de Entrada
Condición de Entrada Valor
tipo audio
obtención dispositivo
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP4 – Captura de audio desde sistema de archivos
a. Condiciones de Entrada
Condición de Entrada Valor
tipo audio
obtención directorio
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
83
Caso de Prueba: CP5 – Captura de video desde cámara
a. Condiciones de Entrada
Condición de Entrada Valor
tipo video
obtención dispositivo
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP6 – Captura de video desde sistema de archivos
a. Condiciones de Entrada
Condición de Entrada Valor
tipo video
obtención directorio
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
L. Pruebas de Integración Componente Persistencia
Introducción
Para lograr ver la interacción entre el componente de persistencia y la aplicación
o componente que lo consuma, se realizaron pruebas de Caja Negra en donde
se quería probar el comportamiento del componente en un contexto real.
Escenarios de Pruebas
Nombre: Retorno y persistencia exitosa de los elementos especificados.
Objetivo: Probar que se retornan y persisten exitosamente los elementos que se
solicitan.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
Mode String file, database, file_database
Vacío Valores diferentes
objName String Letras Caracteres especiales
object Object dispositivo, directorio
Vacío Valor diferentes
Casos de Prueba
Caso de Prueba: CP1 – Guardar los datos de un objeto
84
a. Condiciones de Entrada
Condición de Entrada Valor
object Persona ( id = 1, nombre = “Laura”, edad = 21, genero = “Femenino”, estadoCivil = “Soltera”, pais = “Colombia”, ciudad = “Bogota”, email = “[email protected]”, formaContestacion = “Email” )
b. Resultado Esperado
i. Ninguno.
Caso de Prueba: CP2 – Eliminar un objeto
a. Condiciones de Entrada
Condición de Entrada Valor
object Persona ( id = 1, nombre = “Laura”, edad = 21, genero = “Femenino”, estadoCivil = “Soltera”, pais = “Colombia”, ciudad = “Bogota”, email = “[email protected]”, formaContestacion = “Email” )
b. Resultado Esperado
i. Ninguno.
Caso de Prueba: CP3 – Retornar un objeto de acuerdo a un tipo e id
a. Condiciones de Entrada
Condición de Entrada Valor
objName Persona
id 1
b. Resultado Esperado
85
i. El objeto de tipo Persona con el 1.
Persona (
id = 1,
nombre = “Laura”,
edad = 21,
genero = “Femenino”,
estadoCivil = “Soltera”,
pais = “Colombia”,
ciudad = “Bogota”,
email = “[email protected]”,
formaContestacion = “Email”
)
Caso de Prueba: CP4 – Retornar un conjunto de objetos de acuerdo a un tipo
a. Condiciones de Entrada
Condición de Entrada Valor
objName Persona
b. Resultado Esperado
i. El conjunto de objetos de tipo Persona.
Persona (
id = 1,
nombre = “Laura”,
edad = 21,
genero = “Femenino”,
estadoCivil = “Soltera”,
pais = “Colombia”,
ciudad = “Bogota”,
email = “[email protected]”,
formaContestacion = “Email”
),
Persona (
id = 2,
nombre = “Daniel”,
edad = 21,
genero = “Masculino”,
estadoCivil = “Soltero”,
pais = “Colombia”,
ciudad = “Bogota”,
86
email = “[email protected]”,
formaContestacion = “Email”
)
M. Pruebas Unitarias Componente Comunicaciones
Introducción
Al desarrollar un nuevo software, la primera etapa de pruebas a considerar es la
etapa de pruebas unitarias o también llamada pruebas de caja blanca. El
objetivo fundamental de las pruebas unitarias es asegurar el correcto
funcionamiento de las interfaces, o flujo de datos entre componentes. Las
pruebas unitarias son más exhaustivas que otros tipos de pruebas, implican
hacer pruebas por clase, función y otras unidades mínimas que se hayan
considerado. Las pruebas se realizan sobre las entradas y salidas y se
comprueban que los resultados sean los esperados.
A continuación se presentan los escenarios de pruebas y sus correspondientes
casos de prueba para ejecutar en el componente de comunicaciones.
Escenarios de Pruebas
Para los escenarios de pruebas de HTTP se monto un Handler en ASP.NET el
cual retornara el mensaje entrante precedido de un "Hello World!"
Escenario de Prueba 1
Nombre: Envió exitoso del mensaje por medio del protocolo HTTP
Objetivo: Probar que se envié exitosamente el mensaje comprobando que la
respuesta del servidor sea la adecuada. En los métodos Síncrono y Asíncrono.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
url String Letras Nulo
message String Letras Nulo
httpComponent IHTTPComponent HTTPComponent Nulo
Casos de Prueba
Caso de Prueba: CP1 – Envió exitoso del mensaje por medio del protocolo
HTTP Síncrono
a. Condiciones de Entrada
Condición de
Valor
87
Entrada
Message Mensaje Enviado que será un JSON o XML Sincrono
URL http://192.168.174.129/TestCommunication/handler.ashx
b. Resultado Esperado
i. Response: Hello World! Mensaje Enviado que será un JSON o XML
Sincrono
Caso de Prueba: CP2 – Envió exitoso del mensaje por medio del protocolo
HTTP Asíncrono
a. Condiciones de Entrada
Condición de
Entrada
Valor
Message Mensaje Enviado que será un JSON o XML Asincrono
URL http://192.168.174.129/TestCommunication/handler.ashx
b. Resultado Esperado
i. Ninguno
ii. Los Observadores sean notificado con el response del servidor: Hello
World! Mensaje Enviado que será un JSON o XML Asincrono
Caso de Prueba: CP3 – Envió erróneo del mensaje por medio del protocolo
HTTP Asíncrono
a. Condiciones de Entrada
Condición de Entrada
Valor
Message Mensaje Enviado que será un JSON o XML Asincrono
URL http://192.168.174.129/TestCommunication/handler.ashx
httpComponent Nulo, por no ser inicializado
b. Resultado Esperado
i. Se lanza una Excepción por intentar mandar un mensaje con el
Componente HTTP Parado.
Escenario de Prueba 2
Nombre: Envió Exitoso del Mensaje Por Medio del Protocolo SMS
Objetivo: Probar que los métodos del Componente SMS Funcionen
Adecuadamente.
Clases de Equivalencia
88
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
smsComponent ISMSComponent SMSComponent Nulo
Format String Letras Menor a 3 Caracteres Mayor a 6 caracteres
ServerNumber String Letras Nulo
Casos de Prueba
Caso de Prueba: CP1 – Envió exitoso SMS
a. Condiciones de Entrada
Condición de Entrada Valor
Message "Mensaje a Enviar por SMS"
b. Resultado Esperado
i. No se lanza ninguna excepción enviando el Mensaje.
Caso de Prueba: CP3 – Número requerido de Mensajes es Adecuado con ASCII
a. Condiciones de Entrada
Condición de Entrada Valor
Message "Mensaje a Enviar por SMS con 180 caracteres. Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno"
b. Resultado Esperado
i. Se Necesitan 2 SMS para enviar el Mensaje.
Caso de Prueba: CP3 – Número requerido de Mensajes es Adecuado con
UNICODE
a. Condiciones de Entrada
Condición de Entrada Valor
Message "Mensaje a Enviar por SMS con 210 caracteres algunos especiales como la ñ. Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno Relleno!"
89
b. Resultado Esperado
i. Se Necesitan 3 SMS para enviar el Mensaje.
Caso de Prueba: CP5 – Componente SMS Inicializado Erróneamente
a. Condiciones de Entrada
Condición de Entrada Valor
formato AB
serverNumber 3001234567
b. Resultado Esperado
i. Se lanza una excepción indicando que el formato debe ser mayor a 3
caracteres y menor a 6 caracteres.
Resultados de las Pruebas
La ejecución de las pruebas se muestra en el siguiente formato.
Escenario de Prueba 1
Caso de Prueba: CP1 – Envió exitoso del mensaje por medio del
protocolo HTTP Síncrono
Primer Intento Exitoso
Caso de Prueba: CP2 – Envió exitoso del mensaje por medio del
protocolo HTTP Asíncrono
Primer Intento Fallido, porque la implementación inicial del protocolo
Asíncrono se había pensado con un mecanismo de notificación
controlado por un componente mediador dentro de la arquitectura, sin
embargo al hacer el detalle de la misma este componente se obvio. Por lo
tanto el mecanismo de entrada de mensajes estaba por implementar. Se
implemento el mecanismo de entrada con una estrategia de Patrón
Observador en donde la clase que quiera recibir los mensajes por
protocolos asíncronos como HTTP Async y SMS sirviera para esto.
En el primer intento luego de esta implementación en resultado de la
prueba fue exitoso.
Caso de Prueba: CP3 – Envió erróneo del mensaje por medio del
protocolo HTTP Asíncrono
Primer Intento Exitoso
90
Escenario de Prueba 2
Este escenario no fue probado porque se necesitaba probar sobre el emulador y
la imagen del dispositivo por lo que la mejor alternativa era hacer pruebas de
caja negra.
N. Pruebas Unitarias Componente Conversión de Datos
Introducción
Al desarrollar un nuevo software, la primera etapa de pruebas a considerar es la
etapa de pruebas unitarias o también llamada pruebas de caja blanca. El
objetivo fundamental de las pruebas unitarias es asegurar el correcto
funcionamiento de las interfaces, o flujo de datos entre componentes. Las
pruebas unitarias son más exhaustivas que otros tipos de pruebas, implican
hacer pruebas por clase, función y otras unidades mínimas que se hayan
considerado. Las pruebas se realizan sobre las entradas y salidas y se
comprueban que los resultados sean los esperados.
A continuación se presentan los escenarios de pruebas y sus correspondientes
casos de prueba para ejecutar en el componente de conversión de datos.
Escenarios de Pruebas
Escenario de Prueba 1
Nombre: Serialización y Deserialización de un Objeto a formato JSON
Objetivo: Probar que se haga la conversión de un objeto de prueba
exitosamente a su similar en Json.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
obj Object Paciente
{id, nombre, ciudad,
genero,pais,
email}
Nulo
json String Letras Nulo
Casos de Prueba
Caso de Prueba: CP1 – Serialización exitoso del objeto Paciente por medio
componente Converter en su implementación JSON.
a. Condiciones de Entrada
91
Condición de Entrada
Valor
pacienteTestObj pacienteTestObj.ciudad = "Bogotá";
pacienteTestObj.email = "[email protected]";
pacienteTestObj.genero = "Femenino";
pacienteTestObj.id ="1";
pacienteTestObj.nombre="Niña de Prueba";
pacienteTestObj.pais = "Colombia";
b. Resultado Esperado
i. ExpectedJSON: {"id":"1","nombre":"Niña de
Prueba","ciudad":"Bogotá","genero":"Femenino","pais":"Colombia","ema
il":"[email protected]"}
Caso de Prueba: CP2 – Deserialización exitosa del JSON al objeto Paciente.
a. Condiciones de Entrada
Condición de
Entrada
Valor
jsonEntry {"id":"1","nombre":"Niña de Prueba","ciudad":"Bogotá","genero":"Femenino","pais":"Colombia","email":"[email protected]"}
objCast New Paciente()
b. Resultado Esperado
i. response.ciudad = "Bogotá";
ii. response.email = "[email protected]";
iii. response.genero = "Femenino";
iv. response.id ="1";
v. response.nombre="Niña de Prueba";
vi. response.pais = "Colombia";
Resultados de las Pruebas
La ejecución de las pruebas se muestra en el siguiente formato.
Escenario de Prueba 1
Caso de Prueba: CP1 – Serialización exitoso del objeto Paciente por
medio componente Converter en su implementación JSON
Primer Intento Exitoso
Caso de Prueba: CP2 – – Deserialización exitosa del JSON al objeto
Paciente
Primer Intento Exitoso
92
O. Pruebas Unitarias Componente Multimedia
Introducción
Al desarrollar un nuevo software, la primera etapa de pruebas a considerar es la
etapa de pruebas unitarias o también llamada pruebas de caja blanca. El
objetivo fundamental de las pruebas unitarias es asegurar el correcto
funcionamiento de las interfaces, o flujo de datos entre componentes. Las
pruebas unitarias son más exhaustivas que otros tipos de pruebas, implican
hacer pruebas por clase, función y otras unidades mínimas que se hayan
considerado. Las pruebas se realizan sobre las entradas y salidas y se
comprueban que los resultados sean los esperados.
A continuación se presentan los escenarios de pruebas y sus correspondientes
casos de prueba para ejecutar en el componente de multimedia.
Escenarios de Pruebas
Escenario de Prueba 1
Nombre: Captura exitosa de elementos multimedia.
Objetivo: Probar que se capturan exitosamente los diferentes tipos de
multimedia.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
Tipo String imagen, audio, video
Vacío Valores diferentes
obtención String dispositivo, directorio
Vacío Valor diferentes
Casos de Prueba
Caso de Prueba: CP1 – Captura de imagen desde cámara
a. Condiciones de Entrada
Condición de Entrada Valor
tipo imagen
obtención dispositivo
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP2 – Captura de imagen desde sistema de archivos
93
a. Condiciones de Entrada
Condición de Entrada Valor
tipo imagen
obtención directorio
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP3 – Captura de audio desde grabadora
a. Condiciones de Entrada
Condición de Entrada Valor
tipo audio
obtención dispositivo
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP4 – Captura de audio desde sistema de archivos
a. Condiciones de Entrada
Condición de Entrada Valor
tipo audio
obtención directorio
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP5 – Captura de video desde cámara
a. Condiciones de Entrada
Condición de Entrada Valor
tipo video
obtención dispositivo
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP6 – Captura de video desde sistema de archivos
a. Condiciones de Entrada
Condición de Entrada Valor
tipo video
obtención directorio
94
b. Resultado Esperado
i. Elemento de tipo Media: diferente de null
Caso de Prueba: CP7 – Iniciar el componente de multimedia
a. Condiciones de Entrada: No hay
b. Resultado Esperado
i. Atributo input: diferente de null.
Caso de Prueba: CP8 – Detener el componente de multimedia
a. Condiciones de Entrada: No hay
b. Resultado Esperado
i. Atributo input: igual a null.
Escenario de Prueba 2
Nombre: Manejo de excepciones de captura de multimedia exitoso.
Objetivo: Probar que se manejan las excepciones lanzadas por la captura de
multimedia de forma exitosa.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
tipo String imagen, audio, video
Vacío Valores diferentes
obtención String dispositivo, directorio
Vacío Valor diferentes
Casos de Prueba
Caso de Prueba: CP1 – Captura de imagen desde cámara
a. Condiciones de Entrada
Condición de Entrada Valor
tipo imagen
obtención dispositivo
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo adjuntar la imagen.
Caso de Prueba: CP3 – Captura de audio desde grabadora
a. Condiciones de Entrada
Condición de Entrada Valor
tipo audio
95
obtención dispositivo
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo adjuntar el audio.
Caso de Prueba: CP5 – Captura de video desde cámara
a. Condiciones de Entrada
Condición de Entrada Valor
tipo video
obtención dispositivo
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo adjuntar el video.
Caso de Prueba: CP6 – Captura de multimedia desde sistema de archivos
a. Condiciones de Entrada
Condición de Entrada Valor
tipo imagen, audio, video
obtención directorio
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo adjuntar el elemento
multimedia desde el sistema de archivos.
Caso de Prueba: CP7 – Adjuntar elemento multimedia
a. Condiciones de Entrada:
Condición de Entrada Valor
tipo imagen, audio, video
obtención dispositivo, directorio
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo adjuntar el elemento
multimedia solicitado.
P. Pruebas Unitarias Componente Persistencia
Introducción
Para lograr ver la interacción entre el componente de persistencia y la aplicación
o componente que lo consuma, se realizaron pruebas de Caja Negra en donde
se quería probar el comportamiento del componente en un contexto real.
96
Escenarios de Pruebas
Escenario de Prueba 1
Nombre: Retorno y persistencia exitosa de los elementos especificados.
Objetivo: Probar que se retornan y persisten exitosamente los elementos que se
solicitan.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
Mode String file, database, file_database
Vacío Valores diferentes
objName String Letras Caracteres especiales
object Object dispositivo, directorio
Vacío Valor diferentes
Casos de Prueba
Caso de Prueba: CP1 – Iniciar el componente de persistencia
a. Condiciones de Entrada
Condición de Entrada Valor
Mode file, database, file_database
b. Resultado Esperado
i. Atributo filePersistence: diferente de null ó
ii. Atributo dbPersistence: diferente de null
Caso de Prueba: CP2 – Detener el componente de persistencia
a. Condiciones de Entrada
Condición de Entrada Valor
Mode file, database, file_database
b. Resultado Esperado
i. Atributo filePersistence: igual a null ó
ii. Atributo dbPersistence: igual a null
Caso de Prueba: CP3 – Persistir un objeto
a. Condiciones de Entrada
Condición de Entrada Valor
object Un objeto cualquiera con atributos con valor.
97
b. Resultado Esperado
i. Se persistió el objeto correctamente.
Caso de Prueba: CP4 – Eliminar un objeto
a. Condiciones de Entrada
Condición de Entrada Valor
object Un objeto cualquiera con atributos con valor.
b. Resultado Esperado
i. Se eliminó el objeto correctamente
Caso de Prueba: CP5 – Retornar un objeto
a. Condiciones de Entrada
Condición de Entrada Valor
objName El tipo del objeto buscado. El nombre de la clase.
id El identificador de la clase.
b. Resultado Esperado
i. Se retorna un objeto con las características buscadas.
Caso de Prueba: CP6 – Retornar todos los objetos de un mismo tipo
a. Condiciones de Entrada
Condición de Entrada Valor
objName El tipo del objeto buscado. El nombre de la clase.
b. Resultado Esperado
i. Se retorna el conjunto de objetos del tipo especificado.
Escenario de Prueba 2
Nombre: Manejo de excepciones de obtención de elementos por parte del
componente de persistencia.
Objetivo: Probar que se manejan las excepciones lanzadas el retorno de
objetos.
Clases de Equivalencia
Condición de Entrada
Tipo Clases de Equivalencia
Válidas
Clases de Equivalencia no
Válidas
98
Mode String file, database, file_database
Vacío Valores diferentes
objName String Letras Caracteres especiales
object Object dispositivo, directorio
Vacío Valor diferentes
Casos de Prueba
Caso de Prueba: CP1 – Retornar un objeto
a. Condiciones de Entrada
Condición de Entrada Valor
objName El tipo del objeto buscado. El nombre de la clase.
id El identificador de la clase.
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo retornar el objeto
deseado.
Caso de Prueba: CP3 – Retornar todos los objetos de un tipo
a. Condiciones de Entrada
Condición de Entrada Valor
objName El tipo del objeto buscado. El nombre de la clase.
b. Resultado Esperado
i. Se lanza una excepción indicando que no se pudo retornar el conjunto
de objetos deseados.
Q. Despliegue de una aplicación en un dispositivo basado en Windows Mobile
Introducción
En este tutorial se mostrarán los pasos necesarios para lograr desplegar una
aplicación en un dispositivo basado en Windows Mobile.
Los pasos a realizar son:
Tener una versión estable de la aplicación desarrollada en Visual Studio
2008
Empaquetar la aplicación en un contenedor CAB
Copiar el contenedor CAB en el dispositivo e instalar la aplicación desde
el mismo.
99
Instrucciones
Empaquetar la aplicación en un contenedor CAB
1. En la solución de nuestra aplicación agregaremos un nuevo proyecto.
Para esto haremos clic derecho sobre la solución y agregaremos un
proyecto "Smart Device CAB Project" ubicado en Other Project Types >
Setup and Deployment.
2. Haga clic sobre Application Folder dentro de la vista File System Editor. Si
no puede esta vista, haga clic derecho sobre el proyecto CAB, después
clic en View y finalmente en File System.
3. Haga clic sobre Action en la Barra de Herramientas de Visual Studio y
luego Project Output.
4. En el proyecto seleccionar nuestra aplicación asegurarnos de seleccionar
Primary Output y seleccionar OK.
5. Como último paso debemos hacer clic derecho sobre el proyecto CAB y
seleccionar Build, esto nos generara el archivo CAB en el lugar donde se
encuentra ubicado el proyecto en el computador dentro de una carpeta
Debug.
100
Despliegue de la aplicación en el Dispositivo Móvil.
1. Este paso puede ser el más fácil e intuitivo ya que se debe conectar el
dispositivo al computador y por medio de Windows Active Sync para
Windows XP o Windows Mobile Device Center para Windows Vista/7 se
copia el CAB al Dispositivo.
2. Finalmente desde el dispositivo se debe ejecutar el contenedor .CAB que
se encargara de instalar nuestra aplicación en el dispositivo.
R. Instalación de las herramientas del proyecto
Introducción
A continuación se presenta la instalación de las herramientas mínimas para
ejecutar aplicaciones que en Windows Mobile para dispositivos móviles
Motorola.
Las herramientas necesarias son:
Visual Studio 2008
SDK de Windows Mobile
Plugin de Motorola Q11
Microsoft ActiveSync ó Windows Mobile Device Center
Por último se va a presentar un ejemplo de una aplicación sencilla de “Hello
World!”.
Instalación de Visual Studio 2008
Visual Studio 2008 es una herramienta licenciada. Es necesario que lo obtenga
directamente con Microsoft a través de la página o en su tienda más cercana.
1. Una vez haya obtenido Visual Studio 2008, ejecute el instalador y acepte
la configuración que por defecto trae el instalador.
2. En la ventana de inicio, seleccionar Install Visual Studio 2008.
101
3. Esperar a que el instalador cargue todos los archivos y presionar Next.
4. Leer y aceptar los términos de la licencia y presionar Next.
5. Seleccionar la configuración por defecto y presionar Install.
102
6. Esperar a que se termine de instalar todos los componentes necesarios y
presionar Finish.
Instalación Windows Mobile 6.0 Standard SDK Refresh
La instalación del SDK agrega encabezados, librerías, imágenes de emulación,
documentación y herramientas para Visual Studio para la construcción de
aplicaciones para la plataforma Windows Mobile 6.0.
Se usa la versión estándar que es la que en nuestro caso es la que aplicaría
para la construcción de aplicaciones para dispositivos Smartphone. La versión
clásica aplicaría en el caso de dispositivos PocketPC y la profesional para
teléfonos PocketPC.
1. Descargar el SDK de Windows Mobile 6.0 Standard.
2. Ejecutar el instalador descargado del link anterior.
3. Se muestra una pantalla de bienvenida al instalador, en la cual
presionamos el botón “Next”.
103
4. A continuación se muestran la licencia y términos de uso, seleccionamos
la opción “Accept” y luego damos clic en “Next”.
5. Luego se solicitan algunos datos de usuario, los llenamos y damos clic en
“Next”.
104
6. Luego seleccionamos la ruta de instalación y damos clic en “Next”.
7. Si estamos seguros de que los datos ingresados son correctos, hacemos
clic en “Install”, de lo contrario hacemos clic en “Back” y modificamos la
información necesaria.
105
8. La instalación se lleva a cabo durante varios minutos, al finalizar se
muestra la siguiente pantalla en la que damos clic en “Finish” para
finalizar.
Instalación Windows Mobile 6.0 Standard Image
La instalación de la imagen es necesaria para el despliegue de las aplicaciones
y la ejecución de estas dentro de un ambiente Windows Mobile.
106
Se usa la versión estándar que es la que aplica para nuestro caso, Windows
Mobile para Smartphones. La versión profesional se usa para dispositivos
PocketPC.
Para la instalación de la imagen, se siguen los mismos pasos que se realizaron
en la instalación del SDK para Windows Mobile.
Instalación del plugin de Motorola Q11
El plugin proporcionado por Motorola nos permite que nuestro emulador tenga la
apariencia del modelo en el cual vamos a probar el despliegue de la aplicación y
de esta forma tener un correcto funcionamiento del equipo con esta.
1. Descargar el plugin para Windows Mobile proporcionado por Motorola
desde su sitio para desarrolladores MOTODEV.
2. Instalar el plugin siguiendo los pasos del wizard, teniendo en cuenta que
el SDK debió ser instalado previamente.
3. Ahora hay que relacionar el plugin de Motorola con el emulador
previamente instalado con el SDK, para poder usarlo en nuestro ambiente
de desarrollo. Para esto tenemos que abrir Visual Studio 2008 e ir a Tools
> Options
107
4. En la ventana que aparece debemos ir a Device Tools > Form Factors
5. Debemos seleccionar Windows Mobile 6 SDK Standard en el combo box
y hacer clic sobre Windows Mobile 6 Standard QVGA seguido por Save
As...
6. El nombre a escoger será Motorola Q11 y al crearse se debe seleccionar
y hacer clic sobre Properties...
7. En Skin debemos buscar la ubicación en donde quedo instalado el plugin
de Motorola y hacer referencia al XML que se encuentra ahí.
8. En el campo Skin Defaults se debe ajustar los tamaños a como se ven en
la imagen.
108
9. Ahora debemos ir a Device Tools > Devices para realizar unos pasos muy
parecidos a los realizados anteriormente.
10. Debemos seleccionar Windows Mobile 6 SDK Standard en el combo box
y hacer clic sobre Windows Mobile 6 Standard Emulator seguido por Save
As... y el nombre a escoger es Motorola Q11.
11. Debemos hacer clic sobre Properties... > Emulator Options y en ese punto
se mostrara una nueva pantalla donde debemos volver a relacionar el
Skin del plugin con el emulador.
12. En la pestaña Display debemos volver a configurar el campo Skin y el
tamaño del video para que concuerden con nuestro equipo.
13. En este punto ya podremos inicializar nuestro emulador con la apariencia
del Motorola Q11, para esto debemos ir a Tools > Device Emulator
Manager.
109
14. Finalmente haremos clic derecho sobre Motorola Q11 y daremos clic
sobre Connect. De este modo arranca el emulador con la apariencia
deseada.
110
Hacer uso de la utilidad Cellular Emulator Con la instalación del SDK 6.0 de Windows Mobile obtenemos una utilidad
llamada Cellular Emulator que nos permite simular ciertos eventos al celular
como llamadas, mensajes de texto, conectividad 3G, GPRS o simplemente
conectividad en general para poder manipularlo como si realmente tuviéramos el
equipo móvil físico conectado al computador. Para tareas de despliegue de
aplicaciones saberlo usar correctamente será clave. Debemos tener claro que
esta utilidad no funciona sobre sistemas operativos de 64 bits.
1. Correr la utilidad ubicada dentro de la carpeta de instalación del SDK 6.0
de Windows Mobile, usualmente ubicada dentro de una subcarpeta
"Tools"
2. Correr el emulador del Motorola Q11 e ir a File>Configure... y ahí dentro a
la pestaña Peripherals.
3. En el campo Serial Port 0 configurar el puerto COM del mismo número en
el que aparece en la esquina inferior izquierda de la utilidad Cellular
Emulator, si la opción no aparece en el ComboBox, seleccionar el puerto
COM mediante teclado y finalmente dar OK.
4. Después debemos reiniciar el emulador del Motorola Q11 haciendo clic en
File>Reset>Soft.
111
5. En este punto desde la utilidad podremos simular los eventos de los
cuales habíamos hablado en la introducción, como envío de llamadas,
mensajes de texto, conectividad 3G, etc.
6. Ahora debemos instalar la utilidad que provee Microsoft para la
interacción con nuestros dispositivos móviles basados en Windows
Mobile. Microsoft ActiveSync (Windows XP) ó Windows Mobile Device
Center (Windows 7/Vista). Pueden encontrar links de descarga al final del
tutorial.
7. Para hacer la conexión efectiva debemos configurar la nueva aplicación
de la siguiente manera dependiendo de cual aplique:
Figura 45 - Microsoft ActuveSync 4.5 (Windows XP)
Figura 46 - Windows Mobile Device Center (Windows Vista/7)
112
8. Finalmente desde el Device Emulator Manager debemos hacer clic
derecho sobre la imagen del emulador que estemos corriendo (En este
caso Motorola Q11) y seleccionar la opción Cradle. Esto simulara que
conectáramos el dispositivo móvil mediante un cable al computador.
9. Ahora mediante Microsoft ActiveSync o Windows Mobile Device Center
podremos interactuar con los archivos del celular.
Desarrollo de una aplicación “Hola Mundo” en VS 2008 Se desarrollará una aplicación sencilla en la que se mostrará es uso de cuadro
de texto, un botón y evento al hacer clic. También se mostrara su despliegue en
el emulador de Windows Mobile para Motorola Q11.
1. En Visual Studio 2008 seleccionamos ArchivoNuevoProyecto. En
caso de que se nos muestre una selección de lenguaje, elegimos C#.
2. En la ventana de proyecto nuevo seleccionamos en tipo de proyecto
Visual C# Smart Devices, y seleccionamos la plantilla Smart Device
Project. En la parte superior derecha hay un menú desplegable, aquí
seleccionamos la opción .NET Framework 2.0. En la parte inferior
escribimos el nombre del proyecto, en este caso “HolaMundo”, y
seleccionamos la ubicación en la que lo vamos a crear.
113
3. Ahora seleccionamos la plataforma, para nuestro caso elegimos Windows
Mobile 6 Standard SDK; la versión del framework que seria ,NET
Compact Framework Versión 2.0; y seleccionamos la plantilla Device
Application.
114
4. Aquí se nos muestra una forma vacía, le cambiamos el titula a “Hola
Mundo” en la sección de propiedades. Le agregamos una etiqueta que
diga “Escriba un texto” y por último agregamos un cuadro de texto.
Hacemos clic en la parte inferior de la forma, en esta parte se encuentran
ubicados los botones del dispositivo, escribimos “Mostrar Texto” y
hacemos doble clic sobre este para que nos cree la acción de hacer clic y
nos cambie a la vista de código. Escribimos lo siguiente:
private void menuItem1_Click(object sender, EventArgs e)
{
if (textBox1.Text.Trim().Equals(""))
MessageBox.Show("No ha escrito nada");
else
MessageBox.Show(textBox1.Text);
}
115
5. Acá ya podemos ejecutar la aplicación. Elegimos el menú DebugStart
Debugging. Acá aparece un ventana en donde elegimos donde se va a
hacer el despliegue, elegimos la opción para Motorola Q11 que definimos
en la instalación, y desplegamos.
6. Al desplegar se ejecuta el emulador, este se demora un poco mientras
carga la imagen del sistema operativo y luego muestra nuestra aplicación.
Acá ya podemos interactuar con ella escribiendo en el cuadro de texto y el
botón al cual le definimos función.
116
Referencias
Windows Mobile 6.0 Standard SDK Refresh:
http://www.microsoft.com/downloads/details.aspx?FamilyID=06111A3A-
A651-4745-88EF-3D48091A390B&displaylang=en
Windows Mobile 6.0 Standard Image:
http://www.microsoft.com/downloads/details.aspx?familyid=38c46aa8-
1dd7-426f-a913-4f370a65a582&displaylang=en
Página de Desarrolladores Motorola:
http://developer.motorola.com/
Ruta de descarga:
http://developer.motorola.com/docstools/windows-mobile-
plugins/MOTO_Q11_plug-in.msi
Ruta de descarga Windows Mobile Device Center:
http://www.microsoft.com/windowsmobile/en-
us/downloads/microsoft/device-center-download.mspx
117
Ruta de descarga Microsoft ActiveSync 4.5:
http://www.microsoft.com/downloads/details.aspx?familyid=9e641c34-6f7f-
404d-a04b-dc09f8141141
S. Interfaz DoctorChat < Móvil Windows Mobile >
Introducción
En este tutorial se mostrarán los pasos necesarios para crear la estructura de los
formularios base para la aplicación DoctorChat.
Los pasos a seguir son:
Crear un proyecto base para un Smartphone (Plantilla para Motorola Q).
Desarrollar el formulario inicial.
Desarrollar un formulario hijo.
Ejecutar las pruebas.
NOTA: Este documento hace referencia al proyecto de Visual Studio 2008,
DrChatWM.
Instrucciones
Creación proyecto base
1. Crearemos un proyecto nuevo para un Smart Device basado en el SDK
6.0 Standard para Smartphones.
2. Se agregan los componentes visuales para interactuar con los formularios
hijo, puede ser un LinkLabel.
3. A este LinkLabel le agregamos la funcionalidad para el evento Clic.
118
4. En la funcionalidad adjuntar multimedia, en cada uno de los métodos para
adjuntar los archivos, haremos la conexión a cada funcionalidad.
Desarrollar el formulario inicial
1. El formulario inicial es una única instancia, por lo que podemos dejar la
implementación con un patrón Singleton.
private static readonly FormDoctorChat instance = new FormDoctorChat();
private FormDoctorChat()
{
InitializeComponent();
}
public static FormDoctorChat Instance
{
get
{
return instance;
}
}
2. En la funcionalidad del LinkLabel para el evento Clic, ingresaremos el
código necesario para crear un formulario hijo y mostrarlo.
private void linkLabelNuevaConsulta_Click(object sender, EventArgs e)
{
Form nuevaConsulta = new FormNuevaConsulta(this);
nuevaConsulta.Show();
this.Hide();
}
3. Ya con esto podemos lanzar un formulario hijo desde la pantalla principal.
Desarrollar un formulario hijo
1. Agregamos un formulario nuevo a la solución.
2. A este le agregamos los componentes visuales requeridos.
3. Para poderlo relacionar con el padre, creamos un constructor adicional
para poder hacerle referencia.
public FormNuevaConsulta(Form padre)
119
{
InitializeComponent();
this.padre = padre;
…
}
4. Y para poder volver al padre la agregamos un método que cierre el
formulario hijo y nos vuelva a mostrar el padre.
private void menuItemVolver_Click(object sender, EventArgs e)
{
if (padre != null)
padre.Show();
this.Close();
}
Este código lo podemos adicionar a la funcionalidad de un menú para el
evento Clic.
Ejecutar las pruebas
Una vez conectados todos los elementos a sus correspondientes
funcionalidades, es posible ejecutar la aplicación para ver sus resultados.
T. Manipulación del comportamiento de la aplicación por los estados del Móvil
Introducción
En este tutorial se mostrarán los pasos necesarios para manejar la aplicación
mediante el monitoreo de distintas propiedades del Celular en Windows Mobile
mediante el uso de la librería Microsoft.WindowsMobile.Status, específicamente
monitorearemos la batería del dispositivo.. Adicionalmente se registrara la
aplicación en el registro del sistema operativo para que lance la aplicación
cuando cambie algún estado del teléfono móvil.
Los pasos a realizar son:
Crear un proyecto base para un Smarthphone
Desarrollar el monitoreo de la Batería
Desarrollar el registro de la aplicación en el registro del dispositivo.
Ejecutar las pruebas
120
Instrucciones
Creación proyecto base
1. Crearemos un proyecto nuevo para un Smart Device basado en el SDK
6.0 Standard para Smartphones.
2. Agregaremos algunos componentes visuales a la aplicación,
específicamente para que sean modificados con el cambio de la batería
del celular. Será simplemente un Label que notifique el estado de la
batería al usuario.
3. Adicionalmente le agregaremos funcionalidad a la tecla de función
izquierda para salir de la aplicación. Para esto haremos un clic sobre la
misma en el diseño para cambiarles el nombre seguido de un doble clic
para entrar a la implementación de las funciones.
4. En la funcionalidad de Exit pondremos: Application.Exit().
5. Adicionalmente crearemos un método que cambie el texto del Label que
informa el estado de la batería.
Desarrollar el monitoreo de la Batería
1. Windows Mobile nos provee una librería (Status) la cual es capaz de consultar distintas propiedades del dispositivo en el registro del sistema operativo, tales propiedades referentes a la conectividad, hardware,
121
telefonía, etc. A su vez provee una forma para monitorear estas propiedades y notificarnos de los cambios que apliquen sobre ellas.
2. Para agregar la funcionalidad del monitoreo del estado de la batería en el dispositivo primero debemos agregar una referencia a la librería de .NET CF para poder usar las clases relacionadas con esto. Para esto haremos clic derecho sobre el proyecto y seleccionaremos "Add Reference". Las librerías a selecciona será: Microsoft.WindowsMobile.Status la cual podemos encontrar en la carpeta Managed Libraries dentro de la instalación del SDK 6.0.
3. Ahora crearemos una nueva clase donde realizaremos todo el manejo del estado de la Aplicación y la agregaremos a la solución. La llamaremos 'BatteryStatusSample'.
4. Debemos importar en la clase el paquete antes referenciado mediante: using Microsoft.WindowsMobile.Status;.
5. Para obtener el estado de la batería debemos hacer referencia al objeto
SystemState que encapsula la información del dispositivo reflejada en el registro del mismo, para posteriormente obtener la propiedad que nos
interesa, en este caso PowerBatteryStrength.
6. Desarrollaremos un método que cambiara el texto del estado de la batería en la interfaz dependiendo del estado real de la batería.
122
7. Ahora monitorearemos cada vez que la batería del dispositivo cambie su
valor en el registro, acción que es controlada por el sistema operativo
para que el estado de nuestra aplicación cambie de la misma manera.
Para esto debemos crear un objeto SystemState que controlara solo una
propiedad que queramos monitorear.
8. A su vez debemos informarle cual será el handler que recibirá las
notificaciones en los cambios presentados en esa propiedad y donde
nosotros finalmente volveremos a llamar a nuestro método notifyBatteryLevel.
9. El handler es muy sencillo de implementar y básicamente se encargara de
llamar nuestro método ya creado como se dijo anteriormente. Cabe
destacar que args.NewValue obtiene el valor entrante de la propiedad que
se está monitoreando, el cual debe hacérsele un cast para determinar el
tipo correcto que en este caso es BatteryLevel.
123
Desarrollar el registro de la aplicación en el registro
1. Las Notificaciones que recibe nuestra aplicación por medio del objeto
SystemState también se pueden hacer persistentes y de este modo el
dispositivo será capaz de ejecutar nuestra aplicación si está cerrada
cuando un evento se genere por el cambio del estado del celular en la
propiedad que queramos monitorear.
2. Para implementar este tipo de notificaciones persistentes debemos tener
un appId el cual identificara nuestra aplicación en el registro del Sistema
Operativo.
3. Ahora se tiene que usar una función que revisa si en el registro ya está la
propiedad que queríamos monitorear y la sacara de ahí, sino estuviese la
creara.
4. Este método initialize lo debemos llamar en el constructor de nuestra
clase de ejemplo para que se evalué al comienzo de la aplicación.
5. Cuando llegue un evento del cambio del estado de la batería al Celular si
ya está la propiedad en el registro y nuestra aplicación no está en
ejecución el SO se encargara de arrancarla por nosotros y nosotros en la
mayor brevedad deberemos llamar a nuestro método.
124
Ejecutar las pruebas
1. Simplemente debemos correr nuestra aplicación por primera vez para que
la propiedad que queramos monitorear se instale en el registro y a su vez
ya podamos ver en funcionamiento la misma.
2. Para que la batería del dispositivo cambie efectivamente en el emulador
debemos ir a File>Configure>Peripherals en este punto podremos colocar
el estado de la batería en un punto que consideremos pertinente para
realizar las pruebas.
125
3. Certificar que se genero el cambio en nuestra aplicación con lo que
habíamos puesto en nuestro código.
4. Ahora cerraremos la aplicación y volveremos a cambiar el estado de la
batería (60%) para certificar que la aplicación se ejecute y se muestre el
estado real.
Referencias
The State and Notifications Broker API Part 1
http://msdn.microsoft.com/en-us/library/aa456240.aspx
The State and Notifications Broker API Part 2
http://msdn.microsoft.com/en-us/library/aa456240.aspx
126
The State and Notifications Broker API Part 3
http://msdn.microsoft.com/en-us/library/bb499669.aspx
Microsoft Mobile Development Handbook 2007
U. Adjunto de archivos multimedia
Introducción
En este tutorial se mostrarán los pasos necesarios para seleccionar y/o capturar
archivos multimedia para adjuntar a un formulario en Windows Mobile.
Los pasos a seguir son:
Crear un proyecto base para un Smartphone.
Desarrollar el adjunto de un archivo multimedia.
Ejecutar las pruebas.
NOTA: Este documento hace referencia al proyecto de Visual Studio 2008,
PruebasConceptosMultimedia.
Instrucciones
Creación proyecto base
1. Crearemos un proyecto nuevo para un Smart Device basado en el SDK
6.0 Standard para Smartphones.
2. Agregaremos algunos componentes visuales a la aplicación, un Label que
diga "Archivos seleccionados" y un List View para desplegar los archivos
que se han adjuntado.
3. Adicionalmente le agregaremos funcionalidad a la tecla izquierda para
adjuntar los archivos. Esta tendrá 3 submenús, uno para cada tipo de
multimedia: imagen, audio y video. De la misma manera, cada uno tendrá
un submenú dando la opción de adjuntar desde archivos o capturar el
multimedia que se desea. Para esto haremos un clic sobre la misma en el
diseño para cambiarles el nombre seguido de un doble clic para entrar a
la implementación de las funciones.
127
4. En la funcionalidad adjuntar multimedia, en cada uno de los métodos para
adjuntar los archivos, haremos la conexión a cada funcionalidad.
Desarrollar el adjunto de un archivo multimedia
1. Primero, debemos agregar la referencia al archivo multimedia.dll que nos
permitirá las funcionalidades de adjuntar archivos multimedia. Para esto
haremos click derecho sobre el proyecto y seleccionaremos “Add
Reference”.
2. Debemos importar el paquete antes referenciado mediante la instrucción using mobile.wm.lib.multimedia;
3. Para implementar el adjunto de multimedia, simplemente haremos el
llamado a la función
public Media AttachMedia(IDictionary<string, string> tabla)
de la interface ImediaManipulator. Esta función retorna un objeto de tipo
Media, al cual se le puede pedir información para desplegar como el
nombre del archivo.
Un ejemplo de un método para adjuntar una imagen desde archivo sería:
128
NOTA: Para ver el contrato de llamados al método
AttachMedia(IDictionary<string, string> tabla), referirse al documento del
componente de multimedia.
Ejecutar las pruebas
Una vez conectados todos los submenús a sus correspondientes
funcionalidades, es posible ejecutar la aplicación para ver sus resultados.
V. Envío de datos mediante HTTP y SMS
Introducción
En este tutorial se mostrarán los pasos necesarios para enviar información
mediante el uso del protocolo HTTP y SMS en Windows Mobile. Adicionalmente
se creara un servicio en un servidor web(IIS) que escuche las peticiones
enviadas por el móvil.
Los pasos a realizar son:
Crear un proyecto base para un Smarthphone
Desarrollar el envío mediante SMS
Desarrollar el envío mediante HTTP
Desarrollar un handler web y desplegarlo en ISS
Configurar el emulador para conexiones GPRS
Ejecutar las pruebas
Instrucciones
Creación proyecto base
1. Crearemos un proyecto nuevo para un Smart Device basado en el SDK
6.0 Standard para Smartphones.
129
2. Agregaremos algunos componentes visuales a la aplicación, un Label que
diga "Mensaje a Enviar" y un Text Box para el mensaje que deseemos
enviar por los distintos protocolos.
3. Adicionalmente le agregaremos funcionalidad a las dos teclas de función
una para salir de la aplicación y la otra para enviar el mensaje. Para esto
haremos un clic sobre la misma en el diseño para cambiarles el nombre
seguido de un doble clic para entrar a la implementación de las funciones.
4. En la funcionalidad de Exit pondremos: Application.Exit(); y en el otro
después se harán los llamados a los métodos de enviar por SMS y enviar
por HTTP.
Desarrollar el envío mediante SMS
1. Primero debemos agregar dos referencias a algunas librerías de .NET
para poder usar las clases relacionadas con SMS. Para esto haremos clic
derecho sobre el proyecto y seleccionaremos "Add Reference". Las
librerías a seleccionar serán:
Microsoft.WindowsMobile y
Microsoft.WindowsMobile.PocketOutlook, las cuales las podemos
130
encontrar en la carpeta Managed Libraries dentro de la instalación del
SDK 6.0.
2. Debemos importar en la clase el paquete antes referenciado mediante: using Microsoft.WindowsMobile.PocketOutlook;
3. Para implementar el envió de SMS simplemente haremos referencia a la
clase SMSMessage a la cual le diremos cual será el numero al cual
enviaremos la información y la información como tal. Adicionalmente
pondremos una especie de alerta en el dispositivo cuando el mensaje se
haya enviado satisfactoriamente o la traza del error si hay.
Desarrollar un servicio Web y desplegarlo
1. Debemos importar en la clase los paquetes: using System.Net;
using System.IO;
2. Para implementar el envió de HTTP simplemente debemos crear un
request mediante el uso de la clase HttpWebRequest la cual le diremos
cual será el URL del servicio que nos estará escuchando. Adicionalmente
pondremos una especie de alerta en el dispositivo cuando el mensaje se
haya enviado satisfactoriamente o la traza del error si hay.
131
3. Adicionalmente hay q reconstruir la respuesta mediante el uso de clases
de IO.
Desarrollar un handler web y desplegarlo en IIS
1. Como requisito hay que tener instalado el servidor Web de Microsoft
Information Internet Services(ISS) como ese no es el objetivo del tutorial
no explicaremos aquí como se instala y configura.
2. Debemos crear un nuevo proyecto web vacio al cual le agregaremos
nuestro handler que es una especie de Servlet en su equivalente en
JAVA. Para esto debemos ir a File>New>Web Site>Empty Web Site
Seleccionar HTTP como Location y una dirección de este tipo:
http://localhost/WebSite.
3. Ahora agregaremos un handler sencillo creado por Visual Studio, para
esto haremos clic derecho sobre el proyecto y seleccionaremos AddItem>
Generic Handler.
132
4. Este Handler implementa de la Interfaz IHttpHandler la cual posee un
método llamado ProcessRequest que procesa el request y genera el
response que en este caso es muy simple.
5. Al haber creado el proyecto en Location HTTP por debajo se crea un
Directorio Virtual en IIS que se sincroniza con los archivos que trabajemos
en Visual Studio, por esta razón el handler ya se encuentra arriba en la
dirección especificada mas el nombre del Handler.
Configurar el emulador para conexiones GPRS
1. Debemos crear un nuevo perfil de las conexiones GPRS dentro del
emulador al cual hagamos el despliegue. Para esto dentro del SO de
Windows Mobile debemos navegar por el menú a:
Menu>Settings>Connections>GPRS y haremos clic sobre New.
2. En este punto en Description le daremos un nombre al perfil y le diremos
que se conecte a la red WAP. Adicionalmente tendremos que poner
cualquier nombre en Acces point, los demás campos pueden quedar
vacios.
133
3. Ahora debemos abrir ir a: Menu>Settings>Connections>Proxy y haremos
clic sobre New.
4. Pondremos un nombre en Description y haremos un mapeo entre WAP
Network y The Internet. Los otros campos pueden permanecer como
vienen.
5. Ahora debemos ir a: Menu>Settings>Connections>Menu> Advanced.
Escoger para WAP Network y The Internet el primer perfil creado, los
otros dejarlos en Automatic.
6. Ahora debemos abrir el browser Internet Explorer e iremos a: Menu>
Tools> Options> Connections y escogeremos Internet como la red a
escoger.
134
Ejecutar las pruebas
1. En este punto debemos ejecutar la aplicación provista por el SDK 6.0
Cellular Emulator, si hay dudas sobre la configuración del mismo remitirse
al tutorial "Instalación de Herramientas".
2. Este aplicativo nos permite monitorear la conectividad SMS y GPRS por
distintas pestañas.
3. A nuestro proyecto debemos llamar en el método enviar a las funciones
http y SMS y definir una URL correcta que apunte al Handler (el servidor
será la ip del lugar donde se está ejecutando el IIS).
4. Ahora debemos correr el aplicativo sobre el emulador y enviar un
mensaje.
Si llegan a haber problemas de conectividad GPRS se debe reiniciar el
emulador y hacer clic sobre el botón reset en la pestaña Configuration del
Cellular Emulator.
W. Creación de pruebas unitarias en C#
Introducción
A continuación se mostraran los pasos a seguir para crear y ejecutar una prueba
unitaria.
Creación de pruebas unitarias
1. Se abre el archivo al cual se le quiere crear una prueba unitaria.
135
2. Se hace clic derecho sobre código fuente del archivo y se elige la opción
“Create Unit Tests…”
3. Ahora aparece una pantalla como la que se muestra a continuación. Acá
seleccionamos los métodos a los que se le quieren hacer pruebas.
Se revisa que el combo “Output Project” especifique que se van a crear
las pruebas en C# y hacemos clic en OK.
4. A continuación damos nombre a nuestro proyecto de pruebas.
5. Después de esto ya se crea la plantilla de pruebas con las pruebas para
los métodos seleccionados. Con la configuración por defecto, todas las
pruebas quedan con Assert.Inconclusive por lo que por defecto todas las
pruebas fallan, al modificar la prueba hay que revisar que esta línea no
quede.
Por defecto hay una sección en el código #region Additional test
attributes, en la que se encuentran métodos de inicio y limpieza para
antes y después de ejecutar las pruebas.
136
6. Para correr las pruebas solo es necesario ejecutar el código (F5). En caso
de que se presente un error de seguridad, la forma más fácil de
solucionarlo es desactivar la seguridad en el emulador, para esto con el
emulador en ejecución, vamos a Tools Device Security Manager.
Acá seleccionamos el dispositivo, la configuración “Security Off” y damos
clic en “Deploy to Device”. Si se realizó correctamente, ya se puede volver
a ejecutar las pruebas sin problema.
![[9] TALLER - ARQUITECTURA DE LA COMUNICACION DE DATOS BASADA EN CAPAS](https://static.fdocuments.ec/doc/165x107/559132621a28abb8628b45f8/9-taller-arquitectura-de-la-comunicacion-de-datos-basada-en-capas.jpg)
