u234363

Vista previa del material en texto

DESARROLLO DE SOFTWARE SOBRE DISPOSITIVOS MÓVILES 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
FELIPE GRAJALES FONNEGRA 
 
 
 
UNIVERS
FACULT
DEPARTA
 
 
 
 
 
 
 
IDAD DE LOS ANDES 
AD DE INGENIERIA 
MENTO DE SISTEMAS 
PREGRADO 
BOGOTA, 
2002 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
 
DESARROLLO DE SOFTWARE SOBRE DISPOSITIVOS MÓVILES 
 
 
 
 
 
 
FELIPE GRAJALES FONNEGRA 
 
 
 
 
 
 
Tesis de grado 
 
 
 
 
 
 
María del Pilar Villamil 
 
 
 
 
 
 
UNIVERSIDAD DE LOS ANDES 
FACULTAD DE INGENIERIA, DEPARTAMENTO DE SISTEMAS 
PREGRADO 
BOGOTA 
2002 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
 
 
Dedico este proyecto a: 
 
 
 
 
 
 
 
 
 
Mi mamá por su constante preocupación 
 
 
 
 
 
 
 
 
 
Richard Deeb por creer en mi 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
I
CONTENIDO 
 
 
 
Capítulo 1 PROBLEMÁTICA .............................................................. 1 
 
Capítulo 2 OBJETIVOS ...................................................................... 3 
 
2.1 Generales ...................................................................... 3 
2.2 Específicos ...................................................................... 4 
 
Capítulo 3 EVOLUCIÓN DE LOS 
DISPOSITIVOS MÓVILES (HANDHELDS) ........................... 5 
 
3.1 Relato breve de la aparición de los 
dispositivos móviles más utilizados actualmente ................... 5 
3.2 Ejemplos de la actualidad que revelen 
el potencial de los dispositivos móviles ............................... 7 
3.3 Comparación de la visión antigua con la reciente. 
Una mirada al futuro de los dispositivos móviles ................... 8 
 
Capítulo 4 PLANTEAR UN PROBLEMA QUE REQUIERA 
TECNOLOGÍA MÓVIL PARA SU SOLUCIÓN ....................... 10 
 
4.1 Enunciado del problema que se quiere resolver ................... 10 
4.2 Elegir un dispositivo móvil 
Específico y describir sus características ............................... 11 
 
Capítulo 5 PRIMER ENFOQUE DE DESARROLLO DE SOFTWARE ....... 13 
 
5.1 Identificar requerimientos funcionales de la aplicación ........... 13 
5.2 Desarrollo #1 .................................................................. 14 
5.3 Llevar un registro de problemas 
presentados durante el desarrollo #1 ................................... 17 
 
Capítulo 6 ANÁLISIS DE PROBLEMAS PRESENTADOS 
DURANTE EL DESARROLLO #1 ........................................... 18 
 
6.1 Escoger un conjunto concreto de problemas ....................... 18 
6.2 Profundizar en los problemas escogidos ............................... 18 
 
Capítulo 7 MODELAR EL PROBLEMA ................................................... 21 
 
7.1 Aplicar alguna herramienta de modelaje. 
Plantear los pasos a seguir en el modelaje y realizarlos ........ 21 
 
Capítulo 8 MODELAR POR CAPAS ....................................................... 25 
 
8.1 Separar la aplicación en capas bien definidas ....................... 25 
8.2 Especificar la responsabilidad de 
cada capa y las relaciones entre capas ............................... 38 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
II
 
Capítulo 9 SOPORTE A LA PERSISTENCIA DE LA APLICACIÓN ........... 50 
 
9.1 Describir dos manejadores de 
bases de datos para dispositivos móviles ........................... 50 
9.2 Escoger uno de los manejadores 
descritos con base en criterios específicos ........................... 53 
9.3 Aprender a utilizarlo e 
identificar las facilidades que ofrece 
para el problema que se está solucionando ........................... 54 
 
Capítulo 10 SEGUNDO ENFOQUE DE 
DESARROLLO DE SOFTWARE ....................................... 57 
 
10.1 Realizar diseño de la persistencia: 
Modelo entidad-relación. Elegir las estructuras 
de datos que almacenan la información más relevante ........... 57 
10.2 Desarrollo #2 .................................................................. 58 
 
Capítulo 11 APOYO EN EL DESARROLLO DE SW MÓVIL .................. 69 
 
11.1 Ventajas y desventajas 
de dos formas de desarrollar SW ...................................... 69 
11.2 Recomendaciones en el desarrollo 
de aplicaciones sobre dispositivos móviles ........................... 70 
 
Capítulo 12 CONCLUSIONES Y TRABAJO FUTURO .......................... 74 
 
Capítulo 13 GLOSARIO .................................................................. 76 
 
Capítulo 14 BIBLIOGRAFÍA .......................................................... 78 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
III
INDICE DE TABLAS Y FIFURAS 
 
FIGURA 3.1 – PSION 1 ORGANIZER .................................................................................................................... 5 
FIGURA 3.2 – EVOLUCIÓN DE LOS DISPOSITIVOS PALM......................................................................................7 
FIGURA 4.1 – EJEMPLO ESTRUCTURA MAPA .......................................................................................................10 
FIGURA 4.2 – CONEXIÓN PALM / PC ..................................................................................................................12 
FIGURA 5.1 – ESQUEMA MENTAL DEL DESARROLLADOR ....................................................................................15 
FIGURA 5.2 – SECUENCIA DE PLANTILLAS PARA CREAR UN NUEVO CLIENTE ....................................................15 
TABLA 5.1 – DESCRIPCIÓN DE ARCHIVOS DEL DESARROLLO #1........................................................................16 
FIGURA 7.1 – CASOS DE USO USUARIO ADMINISTRADOR .................................................................................21 
FIGURA 7.2 – CASOS DE USO USUARIO VENDEDOR ...........................................................................................22 
FIGURA 7.3 – MÓDULOS DE LA APLICACIÓN ......................................................................................................23 
FIGURA 7.4 – DETALLE MÓDULO CLIENTES ........................................................................................................24 
FIGURA 7.5 – DETALLE MÓDULO USUARIOS.......................................................................................................24 
FIGURA 7.6 – DETALLE MÓDULO MAPAS ............................................................................................................24 
FIGURA 8.1 – ARQUITECTURA DE LA APLICACIÓN .............................................................................................25 
FIGURA 8.2 - INTERACCIÓN REQUERIMIENTO R1.1 ...........................................................................................26 
FIGURA 8.3 - INTERACCIÓN REQUERIMIENTO R1.2 ...........................................................................................27 
FIGURA 8.4 - INTERACCIÓN REQUERIMIENTO R1.3 ...........................................................................................28 
FIGURA 8.5 - INTERACCIÓN REQUERIMIENTO R2.1 ...........................................................................................29 
FIGURA 8.6 - INTERACCIÓN REQUERIMIENTO R2.2 ...........................................................................................30 
FIGURA 8.7 - INTERACCIÓN REQUERIMIENTO R3.1, R3.2 ..................................................................................31 
FIGURA 8.8 - INTERACCIÓN REQUERIMIENTO R4 ..............................................................................................32 
FIGURA 8.9 - INTERACCIÓN REQUERIMIENTO R5 ..............................................................................................33 
FIGURA 8.10 - INTERACCIÓN REQUERIMIENTO R6.1 .........................................................................................34FIGURA 8.11 - INTERACCIÓN REQUERIMIENTO R6.2 .........................................................................................35 
FIGURA 8.12 - INTERACCIÓN REQUERIMIENTO R7.1 .........................................................................................36 
FIGURA 8.13 - INTERACCIÓN REQUERIMIENTO R7.2 .........................................................................................37 
FIGURA 8.14 – GENERAR ARCHIVOS DE MAPAS .................................................................................................38 
FIGURA 8.15 – DISEÑO POR CAPAS ...................................................................................................................39 
FIGURA 8.16 – CONTROL CAPA DE FUNCIONALIDAD AL INICIAR ......................................................................40 
FIGURA 8.17 – DIAGRAMA DE SECUENCIA R1.2 .................................................................................................43 
FIGURA 8.18 – DIAGRAMA DE SECUENCIA R1.3 .................................................................................................44 
FIGURA 8.19 – DIAGRAMA DE SECUENCIA R2.1 .................................................................................................44 
FIGURA 8.20 – DIAGRAMA DE SECUENCIA R2.2 .................................................................................................45 
FIGURA 8.21 – DIAGRAMA DE SECUENCIA R3.1/R3.2 ........................................................................................45 
FIGURA 8.22 – DIAGRAMA DE SECUENCIA R4 ....................................................................................................45 
FIGURA 8.23 – DIAGRAMA DE SECUENCIA R5 ....................................................................................................46 
FIGURA 8.24 – DIAGRAMA DE SECUENCIA R6.1 .................................................................................................46 
FIGURA 8.25 – DIAGRAMA DE SECUENCIA R6.2 .................................................................................................47 
FIGURA 8.26 – DIAGRAMA DE SECUENCIA R7.1 .................................................................................................47 
FIGURA 8.27 – DIAGRAMA DE SECUENCIA R7.2 .................................................................................................48 
TABLA 8.1 – SOLUCIÓN DE LOS PROBLEMAS DEL CAPÍTULO 6 ...........................................................................49 
FIGURA 9.1 – ARQUITECTURA ORACLE9I LITE ...................................................................................................51 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
IV
FIGURA 9.2 – ESQUEMA CLIENTE / SERVIDOR SYBASE......................................................................................52 
TABLA 9.1 - ORACLE9I LITE VS. SQL ANYWHERE 8 ............................................................................................54 
FIGURA 10.1 – MODELO ENTIDAD-RELACIÓN ....................................................................................................57 
FIGURA 10.2 – PROYECTO EJEMPLO DE CODEWARRIOR ....................................................................................63 
TABLA 11.1 – VENTAJAS Y DESVENTAJAS DE LA PRIMERA IMPLEMENTACIÓN ...................................................69 
TABLA 11.2 – VENTAJAS Y DESVENTAJAS DE LA SEGUNDA IMPLEMENTACIÓN ..................................................70 
FIGURA 11.1 – RESTRICCIONES DE HW Y SO EN LAS CAPAS DE ARQUITECTURA (DISP. PALM) ........................71 
 
 
 
 
 
 
 
 
 
 
 
CAPÍTULO 1 PROBLEMÁTICA 
 
Desde hace varios años las empresas colombianas se han familiarizado con el uso de 
dispositivos electrónicos portátiles (DEPs). Estos dispositivos han sido útiles para 
optimizar el desarrollo de una amplia gama de tareas, entre las que podemos 
mencionar: ubicación de empleados, control de ventas, rastreo de vehículos, 
recolección de información, etc. 
 
Según la demanda del mercado, los DEPs han ido incrementando la complejidad de 
los servicios que ofrecen. Al principio se presentaban servicios muy genéricos que 
buscaban cubrir necesidades básicas de cualquier empresa, tal es el caso de las 
agendas o los directorios electrónicos. 
 
Concretamente los dispositivos conocidos como handhelds o PDAs (Personal Digital 
Assistants) han tenido una gran acogida entre las empresas, debido a que han 
reducido el tiempo y aumentado la precisión en el transporte y recolección de 
información. Actualmente, los más conocidos dentro de este grupo de dispositivos 
son posiblemente Palm y Pocket Pc. Estos dispositivos prestan servicios genéricos 
como agendas, memos o directorios, y además permiten la construcción de 
aplicaciones hechas a la medida y la interacción de estas aplicaciones con 
dispositivos externos como localizadores geográficos, impresoras portátiles o lectores 
de códigos de barras. 
 
Lo que se busca es convertir dichos dispositivos en puntos de acceso a información 
remota ubicada en bases de datos centralizadas, lo anterior es el esquema básico 
cliente-servidor pero sumándole las ventajas de la comunicación inalámbrica y 
la facilidad de uso de los dispositivos móviles. Para lograr este objetivo es necesario 
aumentar recursos de hardware (HW) y software (SW), que soporten los nuevos 
requerimientos de este tipo de tecnología. 
 
Respecto al HW, ya existen aparatos inalámbricos que ofrecen comunicación vía 
microondas o por CDPD (Cellular Digital Packet Data), entre otros. Sin embargo, en 
Colombia los costos de este tipo de comunicación son muy elevados, ya que las 
empresas que están en capacidad de prestar el servicio son las mismas que 
comunican los teléfonos celulares y por tanto las tarifas ofrecidas son semejantes. 
 
En cuanto al SW, encontramos tres dificultades en la etapa de desarrollo: 
 
! La complejidad en la representación de la información, en términos de las 
estructuras de datos. 
! La necesidad de manipular grandes cantidades de información de manera 
sencilla y eficiente. 
! La mezcla de tres niveles de desarrollo en un mismo sitio: 
i. Persistencia. 
ii. Funcionalidad. 
iii. Interfaz Gráfica. 
 
Estos problemas son los primeros que se deberían atacar antes de realizar SW a gran 
escala. Por ejemplo, solucionando el tercer problema, es posible diseñar una 
arquitectura que comunique los tres niveles mencionados, y luego realizar un análisis 
por separado de cada nivel. Así se logra un proceso de SW más claro y posiblemente 
mayor grado de mantenibilidad. 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
2
Los otros dos problemas también llevan a un mejoramiento en la calidad del SW que 
se quiere producir. Por ejemplo, en el segundo de los problemas, diseñando un 
mecanismo para manipular grandes cantidades de información, que optimice la 
utilización del espacio, sé está combatiendo una de las limitaciones más delicadas de 
los dispositivos portátiles: La capacidad de almacenamiento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
3
CAPÍTULO 2 OBJETIVOS 
 
Sección 1 – GENERALES 
 
" Conocer a grandes rasgos la evolución de los handhelds con la intención de 
entender cuales son sus características: ventajas y desventajas. Así mismo 
proyectar el futuro de este tipo de tecnología, e identificar las empresas 
más importantes involucradas en el desarrollo de estos dispositivos. 
 
" Comparar dos enfoques al desarrollar un SW específico para un dispositivo 
portátil. El primero de los enfoques busca terminar el producto en el menor 
tiempo posible, obteniendo resultados parciales rápidamente y sin tener en 
cuenta errores minúsculos. El segundo de los enfoques está dirigido a 
desarrollar un SW flexible, mantenible, libre de errores y que posea unsoporte teórico de las principales decisiones de implementación. 
Luego se quiere resumir ventajas y desventajas de cada uno de los 
enfoques, para argumentar bajo condiciones empresariales (definidas por 
características específicas) y que relacionan la aplicación con las 
restricciones de un dispositivo móvil cual de los dos es mejor. 
 
" Generar un proceso organizado y un conjunto de recomendaciones de 
desarrollo de SW para cualquier tipo de aplicación, un dispositivo portátil 
predefinido y un paquete de desarrollo específico. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
4
Sección 2 – ESPECÍFICOS 
 
1. Recolectar información acerca de cuando y porque aparecieron los 
dispositivos móviles (handhelds), con el fin de entender que problema se 
buscaba solucionar y contrastar este supuesto con la utilidad de dichos 
dispositivos en la actualidad. 
 
2. Formular un problema específico que requiera el uso de dispositivos 
móviles (palm, pocket pc, hewlett-packard, etc.). 
 
3. Solucionar el problema directamente sobre algún paquete de desarrollo 
(SDK) sin realizar modelaje ni seguir ningún proceso formal de desarrollo 
(implementación #1). 
 
4. Utilizar el SW desarrollado (#1) para concretar problemas tanto en el 
proceso de SW como en la implementación, y relacionarlos con las 
restricciones presentes en los dispositivos móviles. 
 
5. Volver a empezar el desarrollo del SW desde un modelaje riguroso que 
contemple todos los requerimientos de la aplicación. 
 
6. Diseñar algún tipo de arquitectura para separar el problema que se quiere 
solucionar en varios niveles. 
 
7. Buscar algún manejador de BD (disponible en el mercado) especial para 
dispositivos móviles. 
 
8. Implementar de nuevo el SW siguiendo paso a paso la arquitectura y el 
modelaje (implementación #2). 
 
9. Una vez las implementaciones #1 y #2 estén listas recopilar ventajas y 
desventajas de cada solución. 
 
10. Utilizar criterios de evaluación para comparar las dos soluciones. 
 
11. Ofrecer un conjunto de recomendaciones generales para desarrollar 
software en dispositivos móviles. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
CAPÍTULO 3 EVOLUCIÓN DE LOS DISPOSITIVOS 
MÓVILES (HANDHELDS) 
 
Previo al inicio de un análisis acerca de dos enfoques distintos para desarrollar SW 
sobre dispositivos móviles, se debe conocer un poco de historia sobre la tecnología 
móvil. Datos acerca de las industrias que han hecho posible la aparición y evolución 
de los dispositivos móviles, así como los usos que se les ha dado desde sus orígenes, 
resultan fundamentales para visualizar hacia donde se dirige la tecnología móvil, y de 
ahí entender la importancia de crear un proceso organizado de desarrollo de SW 
sobre algún dispositivo que tenga gran acogida en el mercado móvil. 
 
El principal objetivo cuando se creo el primer dispositivo móvil, era materializar un 
aparato electrónico que realizara las mismas funciones de aparatos con conexión 
eléctrica fija, pero que pudiera ser transportado con facilidad y usara una fuente de 
energía propia independiente del tendido eléctrico, apelando al uso de pilas 
desechables, baterías recargables o incluso celdas solares. 
 
Sección 1 – RELATO BREVE DE LA APARICIÓN DE LOS 
DISPOSITIVOS MÓVILES MÁS UTILIZADOS ACTUALMENTE. [1] 
 
Un gran número de dispositivos podrían encajar en la categoría de dispositivo móvil. 
Portátiles, celulares, reproductores de MP3 y minidiscs son algunos ejemplos del 
amplio espectro que comprende la palabra dispositivo móvil. En el contexto de este 
proyecto con dispositivo móvil se hace referencia a un grupo más pequeño llamado 
handhelds, más específicamente las PDAs. Un handheld se define como: 
 
Todo aparato electrónico que permite acceder información visual por medio de 
almacenamiento o comunicación, y que además es suficientemente pequeño y liviano 
para que una sola persona pueda transportarlo en un bolsillo (de suficiente tamaño) y 
usarlo mientras lo sostiene en la mano. [2] 
 
El género PDA fue establecido por una compañía del Reino Unido de nombre Psion 
después de lanzar al mercado su primer organizador digital llamado Psion 
Organizer, en 1984. Entre las características más destacadas de Psion Organizer 
estaban: 
 
# D
# P
# M
# B
b
# B
# P
# R
# P
imensiones: 
142mm x 78mm x 29.3mm 
eso: 
225 gr. 
emoria no volátil: 
10K 
ase de datos con función de 
úsqueda. 
asado en tecnología de 8 bits. 
aquete de funciones matemáticas. 
eloj / Calendario. 
antalla LCD de 16 caracteres. 
5
Figura 3.1 – Psion 1 Organizer
Sin embargo, Psion 1 no se convirtió en un computador genuino hasta la aparición 
del paquete Science Pack, el cual permitió la creación de programas más versátiles 
bajo un lenguaje de programación muy similar al BASIC del momento. Este paquete 
de programación junto con nuevas bondades en el HW incrementó notablemente la 
comercialización de la Psion II, el cual alcanzó 500,000 unidades producidas entre 
mediados de los 80’s y principios de los 90’s. Hacia 1993 la compañía Psion saca al 
mercado su serie 3a de PDAs con microprocesador de 16 bits, una pantalla mono LCD 
de 40 caracteres por 8 líneas y la característica que revolucionó el mercado de las 
PDAs: la capacidad de compartir archivos con computadores de escritorio mediante 
un proceso de sincronización. Por unos cuantos años Psion dominó el mercado de las 
PDAs, solo hasta 1997 el éxito de su serie 5 de PDAs (que contaba con una pantalla 
de 640x240 píxeles y 16 colores en escala de grises) motivó el surgimiento del 
competidor 3COM que con su gama de dispositivos PalmPilot ganó el liderazgo del 
mercado. 
 
El éxito de las PDAs impuesto por Psion impulsó a muchas otras compañías a 
principios de los 90’s a sacar al mercado sus propios handhelds. Apple Computer, 
Hewlett-Packard Co., Motorola Inc., Sharp Electronics Corp. y Sony Electronics Inc. 
fueron algunas de las empresas que por esta época invirtieron en diseño y 
producción de dispositivos portátiles. Especial reconocimiento tuvo la compañía 
Apple Computer quien con su tecnología Newton introdujo el uso de pantallas 
sensibles al tacto y software de reconocimiento de escritura a mano. A pesar de los 
esfuerzos de Apple y de sus novedosas ideas, nunca lograron un sistema 
aceptablemente rápido ni autosuficiente. Fue entonces hacia 1998 cuando Apple 
anunció el fin del proyecto Newton. 
 
Palm Computing ha sido la compañía que ha logrado un éxito rotundo desde la caída 
de Psion, primero al ser adquirida por US Robotics (1995) desarrolló el concepto de 
touchscreen con un lápiz como herramienta de interacción, además produjo su 
famoso sistema de reconocimiento de escritura a mano Graffiti, el cual demostró ser 
una herramienta eficiente para trabajar con PDAs. Dos años más tarde en 1997, 
3COM adquiere US Robotics y junto con esta Palm Computing. Es por esta época 
cuando la compañía se posiciona en el mercado con sus PDAs, y logra reconocer 
distintos tipos de necesidades y segmentos en el mercado de los handhelds. 
 
Los dispositivos Pilot 1000 y Pilot 5000 fueron unos de los primeros desarrollados por 
Palm Computing. Estas PDAs estaban orientadas a mejorar la realización de las 
tareas de ejecutivos y empresarios, ofrecían de manera móvil servicios de agenda, 
lista de contactos e información financiera, entre otros. 
Durante los últimos años la compañía ha buscado desarrollar una gama de 
dispositivos de distintos presupuestos y necesidades, pero sobre todo ha tratado de 
incentivar el desarrollo de nuevas aplicaciones en todo el mundo, que le den un valor 
agregado a sus dispositivos, como herramientas de soluciones genéricas y a la 
medida. 
 
La siguiente figura ilustra la evolución de los dispositivos desarrollados por Palm 
Computing. 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
7
 Pilot 1000M100 Palm VIIx M515 
 
 
Figura 3.2 – Evolución de los dispositivos Palm 
 
 
Sección 2 - EJEMPLOS DE LA ACTUALIDAD QUE REVELEN EL 
POTENCIAL DE LOS DISPOSITIVOS MÓVILES. 
 
Un handheld además de prestar servicios de uso generalizado como agendas, hojas 
de cálculo, calculadoras científicas, etc., ofrece la posibilidad de crear SW a la medida 
acorde con las necesidades de un negocio particular. 
Muchas son las empresas que hoy en día hacen uso eficiente de la tecnología móvil, 
los siguientes son algunos ejemplos de tipos de aplicaciones que funcionan con esta 
tecnología. 
 
Entrega y Recibo de Artículos 
Varias empresas dedicadas a entregar y recoger artículos, necesitan de un método 
eficiente y seguro que les permita registrar su trabajo diario. Estas empresas pueden 
ahora recurrir a los dispositivos móviles para mejorar el rendimiento y precisión de 
su trabajo. Gracias a la tecnología móvil es posible contar con una aplicación 
instalada en un handheld que contiene todas las entregas y recibos que un empleado 
debe realizar durante un día. 
Al iniciar el día los empleados conectan su PDA a un computador que contiene todas 
las entregas y recibos a realizar, y al finalizar el día se sincroniza de nuevo el 
dispositivo para registrar cuales de las tareas asignadas fueron realizadas. 
Cada artículo que se entrega está etiquetado con un código de barras que lo 
identifica de manera única dentro de un lapso de tiempo determinado. El handheld 
cuenta con un lector de código de barras que sirve para aumentar la precisión en la 
entrega de la mercancía. Cuando el empleado lee el código de barras de un articulo, 
el dispositivo le informa el nombre y dirección de la persona a la que se le debe 
entregar el artículo. 
En el momento de entregar o recoger un artículo el cliente debe escribir su firma 
sobre la pantalla touchscreen de la PDA, esto como una forma de comprobar que la 
mercancía fue entregada o recibida dependiendo del caso. 
 
Aplicaciones de este estilo son utilizadas por empresas que trabajan entregando 
paquetes. Canada Post Corporation o Purolator Courier Ltd. son algunas de las 
empresas que han incrementado la velocidad y control de su trabajo mediante el uso 
de aplicaciones móviles sobre dispositivos Symbol (palms con lector de código de 
barras). [3] 
 
Sistema de Encuestas 
Las empresas frecuentemente realizan encuestas para obtener información acerca 
del mercado al que se enfrentan, estimar la acogida que tendrá el lanzamiento de un 
nuevo producto o darse una idea del posicionamiento frente a la competencia. 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
8
Como reemplazo al papel y lápiz con que hasta hace unos años se realizaban las 
encuestas, aparece un sistema de creación y realización de encuestas que funciona 
mediante la interacción de un PC (Personal Computer) con un dispositivo handheld. 
Las encuestas se crean en el PC con el número y tipo de preguntas que se prefiera, 
luego son transferidas a los dispositivos móviles donde se encuentra otro programa 
que es capaz de recibirlas y mostrarlas. La persona que realiza la encuesta puede con 
rapidez y precisión almacenar las respuestas de los encuestados. Al final del proceso 
se transfieren las respuestas de los encuestados de nuevo a la aplicación del PC, allí 
se consolida la información con agilidad y precisión. 
 
Mientras muchas empresas utilizan aplicaciones de este tipo para obtener 
información del mercado, algunas organizaciones humanitarias las utilizan para 
recolectar información acerca de la salud de personas necesitadas en países pobres. 
Por ejemplo, la organización Center of Excellence in Disaster Management and 
Humanitarian Assistance luego de implantar un sistema de encuestas soportado por 
handhelds, redujo considerablemente los tiempos de suministro de medicinas a 
personas enfermas de bajos recursos en países pobres. [4] 
 
Geo-Referenciación de Postes de Luz 
Una de las principales ventajas con que cuentan las PDAs es el acceso a cualquier 
tipo de información de manera móvil. Últimamente ciertas aplicaciones para 
dispositivos móviles ofrecen al usuario la posibilidad de navegar por un mapa de una 
ciudad. Es posible integrar estas aplicaciones con un dispositivo GPS (Global 
Positioning System) que transfiera a la PDA información geográfica de latitud y 
longitud. Con esta información la aplicación muestra en el mapa un punto que indica 
la posición del dispositivo [5]. Esta aplicación puede ser utilizada para recolectar 
información sobre el estado de los postes de luz en una ciudad; se captura la 
posición del poste y a esta se le asocia algún tipo de información relevante para 
realizar mantenimiento. A medida que se van registrando postes en la base de datos 
(BD) del dispositivo móvil, esta información puede ser transferida a una aplicación de 
PC que permita tomar decisiones de mantenimiento y mejoramiento de la red 
eléctrica. 
 
Sección 3 - COMPARACIÓN DE LA VISIÓN ANTIGUA CON LA 
RECIENTE. UNA MIRADA AL FUTURO DE LOS DISPOSITIVOS 
MÓVILES. 
 
Las primeras PDAs que aparecieron en el mercado de la tecnología móvil (1980s), 
contaban con utilidades que almacenaban información indispensable de cualquier 
ejecutivo u hombre de negocios. Utilidades que semejaban un libro de direcciones, 
una lista de teléfonos, una agenda de citas, entre otras, hicieron que las PDAs en sus 
orígenes estuvieran enfocadas primordialmente a solucionar la vida del individuo. 
Una de las características que más influyo en el progreso del mercado de dispositivos 
móviles fue la posibilidad de compartir archivos con el PC. Esta característica hizo 
que muchos empresarios y ejecutivos, motivados por incrementar su productividad 
en el trabajo, decidieran adquirir una PDA. 
 
Hasta hace unos cuantos años fue que los dispositivos móviles empezaron a 
funcionar no solo en pro del individuo, sino también como una opción para las 
empresas en la sistematización de su trabajo. La producción de dispositivos móviles 
con procesadores más poderosos y con posibilidades de comunicarse de manera 
inalámbrica, fomentó la creación de aplicaciones diseñadas para recolectar o 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
9
transportar información de manera masiva, eficiente y precisa. En la actualidad estas 
aplicaciones ubicadas en las PDAs, funcionan con otra aplicación central localizada en 
un PC que se encarga de suministrar y recibir toda la información hacia y desde los 
dispositivos. Ejemplos de este tipo de aplicación se encuentran descritos en la 
sección anterior. 
 
El futuro de los dispositivos móviles parece ser mucho más amplio del propuesto por 
aplicaciones que sistematizan procesos en las empresas. Con las PDAs se pretende 
integrar varios dispositivos en uno solo, de tal forma que se ofrezca a las personas 
un dispositivo más versátil capaz de atender varias necesidades. 
Según Jeff Hawkins CPO (Chief Product Officer) de Handspring (una compañía que 
produce handhelds), en el futuro próximo habrá de diseñarse un dispositivo que sirva 
para conectarse a Internet, como teléfono celular y que cuente con la funcionalidad 
de una PDA. Un dispositivo con estas características, si bien puede suplir muchas de 
las necesidades de cierto segmento del mercado de la tecnología móvil, necesita 
encontrar un equilibrio entre la funcionalidad que ofrece y el precio al que puede ser 
vendido para que no genere pérdidas. 
 
Las empresas que producen dispositivos móviles ven el avance en el desarrollo de los 
handhelds como uno de los principales factores que determinará el rumbo de esta 
tecnología. No obstante, para indagar acerca del comportamiento del mercado móvil 
durante los próximos años, se deben considerar factores que van desde los costos en 
los servicios de Internet móvil, hasta el grado de familiaridad que las personas 
pueden alcanzar con los handhelds. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----2020202010
CAPÍTULO 4 PLANTEAR UN PROBLEMA QUE 
REQUIERA TECNOLOGÍA MÓVIL PARA 
SU SOLUCIÓN 
 
La creación de un proceso organizado de desarrollo de software sobre un dispositivo 
móvil específico, sugiere conocer las características del dispositivo en cuestión y la 
manera en que se desarrollan aplicaciones para ese dispositivo en un paquete SDK 
determinado. 
 
En el presente capítulo se propone un problema de desarrollo de software que 
requiere el uso de dispositivos móviles. Este problema se soluciona en un primer 
desarrollo realizado sin utilizar ninguna arquitectura ni técnica de programación, 
simplemente se busca terminar un producto en el menor tiempo posible. Esta 
manera particular de desarrollar, va a permitir no solo detectar ventajas y 
desventajas en el proceso, si no también entender con mayor profundidad el 
problema que se quiere solucionar. 
 
Así, será posible aplicar en capítulos posteriores un método inductivo que permita 
concretar, para cualquier aplicación, una serie de pasos esenciales y una arquitectura 
favorable para el desarrollo de software mantenible, flexible y con una base teórica 
de las principales decisiones de implementación. 
 
Sección 1 - ENUNCIADO DEL PROBLEMA QUE SE QUIERE 
RESOLVER. 
 
Una empresa dedicada a crear mapas en formato digital de municipios y ciudades de 
su país, desea aprovechar el producto de su trabajo creando una aplicación móvil 
capaz de cargar sus mapas y que cuente con un sistema de navegación. 
 
Cada mapa tiene tres niveles de acercamiento, cada nivel de acercamiento se 
compone de un conjunto de imágenes (que parten una vista general del mapa 
formando una cuadricula) y cada imagen (tipo bitmap) tiene asociados sus cuatro 
extremos con coordenadas de latitud y longitud en un archivo de formato CSV 
(Valores Separados por Comas). El primer nivel es la vista más alejada del mapa, 
que se representa con una sola imagen. El nivel dos está representado por un 
conjunto de imágenes que parten el primer nivel en pedazos rectangulares. A su vez 
en el tercer nivel se tienen imágenes que parten cada imagen del segundo nivel de 
nuevo en pedazos rectangulares (ver figura 4.1). La navegación debe realizarse 
relacionado las coordenadas de longitud y latitud de un nivel con las de los demás 
niveles y mediante movimientos verticales u horizontales dentro de un mismo nivel. 
 
 
 Cliente 
 
 
 Nivel 1 Nivel 2 Nivel 3 
 
 Figura 4.1 – Ejemplo estructura mapa 
 
La aplicación debe manejar dos tipos de usuario: Un usuario administrador y un 
usuario vendedor. Ambos tipos de usuario deben acceder de manera segura a la 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
11
aplicación; el usuario administrador con una contraseña, y cada usuario vendedor 
con login y password. 
El usuario administrador debe contar con una opción para cambiar su contraseña y 
otra opción para crear, eliminar y consultar los usuarios vendedores, los cuales se 
componen de la siguiente información: Nombre, Login, Password y Teléfono. 
Adicionalmente el administrador debe poder elegir de una lista de mapas cual desea 
cargar. La aplicación debe cargar el mapa que el administrador eligió en alguna 
estructura de almacenamiento que ofrezca acceso rápido para facilitar el proceso de 
navegación dentro del mapa. 
 
En el nivel 3 del mapa el usuario vendedor debe poder crear, eliminar y ver 
información asociada de clientes. En los tres niveles de acercamiento el vendedor 
podrá ver la posición de los clientes representada por puntos. 
Los datos de cada cliente son: Identificación (NIT o Cédula), Código (Id único), 
Nombre, Dirección, Contacto (Nombre de una persona), Email y Teléfono. 
 
Sección 2 - ELEGIR UN DISPOSITIVO MÓVIL ESPECÍFICO Y 
DESCRIBIR SUS CARACTERÍSTICAS. 
 
Antes de tomar una decisión acerca del dispositivo que será utilizado para 
implementar una solución al problema, se debe hacer un análisis de acuerdo a los 
siguientes criterios importantes para la empresa que solicita la aplicación: 
 
# Costos. 
# Número de usuarios en el mercado. 
# Experiencia de la empresa. 
# Soporte en el desarrollo de aplicaciones. 
 
Los anteriores criterios se evaluaron para varios handhelds producidos por distintas 
compañías, a continuación se justifica el haber escogido los dispositivos Palm como la 
mejor opción: 
 
# En cuanto a los costos, Palm Computing cuenta con una variedad de modelos 
que comparten el mismo sistema operativo, pero varían de acuerdo a 
presupuesto y necesidades de distintos segmentos del mercado. 
# Palm actualmente es la compañía líder en el mercado de los handhelds, con 
aproximadamente un 32.4% de participación en ventas a nivel mundial. [6] 
# La empresa que solicita la aplicación afirmó haber tenido buena experiencia 
con aplicaciones desarrolladas para dispositivos Palm. 
# Al comprar una palm no se adquiere únicamente la funcionalidad básica de 
cualquier PDA, también se tiene acceso a más de 13.000 aplicaciones de 
distinta funcionalidad que se encuentran disponibles en Internet. [7] 
 
Las anteriores eran algunas características positivas del entorno en donde se 
encuentran los dispositivos Palm, las siguientes son características fundamentales de 
hardware con que cuenta una palm: 
 
# Sistema operativo Palm OS con una interfaz gráfica soportada por íconos, 
mediante la cual es posible acceder aplicaciones, configurar el dispositivo y 
administrar las bases de datos que las aplicaciones utilizan. 
# Dos puertos de comunicaciones, uno infrarrojo y otro serial, diseñados para 
compartir información con PCs y con otros dispositivos Palm. El puerto serial es 
utilizado primordialmente para realizar sincronización de archivos con el PC 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
12
mediante el uso de la aplicación HotSync. El infrarrojo en cambio se puede 
usar para transferir bases de datos y software de una palm a otra. 
# Pantalla sensible al tacto para interactuar directamente con la visualización y 
sistema de reconocimiento de escritura a mano que evita el uso de un teclado. 
Es posible iluminar esta pantalla en la oscuridad con una luz de fondo o 
cambiar el contraste de definición. 
# Unidad de memoria donde las aplicaciones almacenan las bases de datos que 
necesitan para funcionar. La capacidad de esta memoria varía entre 2MB y 
16MB dependiendo del modelo. 
# La mayoría de dispositivos utilizan pilas desechables como fuentes de energía. 
Otros más sofisticados usan baterías recargables. 
 
 
 
 
 Figura 4.2 – Conexión palm / pc 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
13
CAPÍTULO 5 PRIMER ENFOQUE DE DESARROLLO DE 
SOFTWARE 
 
El capítulo anterior formula un problema de tecnología móvil y propone un dispositivo 
para solucionarlo. En este capítulo se identifican los requerimientos de la aplicación y 
con base en estos se realiza un primer desarrollo que tiene como objetivos 
primordiales terminar un producto en el menor tiempo posible sin seguir ningún 
método organizado de desarrollo y extraer un conjunto de problemas producto de 
esta forma particular de desarrollar. 
 
La herramienta de desarrollo bajo la cual se va a trabajar tanto en el desarrollo #1 
como en el #2 se llama CodeWarrior. Este es un paquete de desarrollo de la 
compañía Metrowerks especial para programar dispositivos Palm. 
 
Sección 1 - IDENTIFICAR REQUERIMIENTOS FUNCIONALES DE 
LA APLICACIÓN. 
 
El documento de requerimientos es una herramienta fundamental para cualquier 
desarrollador, como se ilustra en la siguiente sección de una buena definición de 
requerimientos se desprende un mejor proceso de desarrollo. 
Con base en el enunciado propuesto en la sección 1 del capítulo 4 se presentan a 
continuación en dos pasos los requerimientos funcionales que la aplicación debe 
cumplir. El primer paso expresa la idea general de cada requerimiento, elsegundo 
paso de manera más específica detalla cada requerimiento dividiéndolo posiblemente 
en sub-requeremientos. 
 
Paso 1 : Requerimientos de manera general 
R1: Cargar mapas en un dispositivo móvil y ofrecer navegación por dichos mapas 
garantizando latencia baja en el proceso de consulta. 
R2: Autenticar dos tipos de usuario: Administrador y Vendedor. 
R3: Crear y eliminar usuarios vendedores. 
R4: Consultar información básica de todos los usuarios vendedores. 
R5: Cambiar contraseña por parte del usuario administrador. 
R6: Cada usuario vendedor puede consultar la información de los clientes que le 
pertenecen. 
R7: Crear y eliminar clientes por parte del usuario vendedor con interacción 
directa en el nivel 3 del mapa. 
 
Paso 2 : Requerimientos detallados 
R1.1: Almacenar, en un dispositivo móvil, cualquier mapa con sus tres niveles de 
acercamiento y las coordenadas de longitud y latitud asociadas a cada 
imagen. Cada imagen es un archivo tipo BMP que tiene asociadas sus 
coordenadas en un archivo tipo CSV. 
R1.2: Mostrar al usuario administrador una lista de los mapas que se encuentran 
almacenados en el dispositivo móvil. El usuario administrador podrá elegir el 
mapa que la aplicación debe cargar. 
R1.3: Según el mapa que el administrador halla decidido cargar, permitir a cada 
usuario vendedor navegar entre los tres niveles de acercamiento y dentro de 
cada nivel con movimientos horizontales y verticales. 
R2.1: Para realizar funciones de administración de la aplicación, el usuario 
administrador debe autenticarse con una contraseña. 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
14
R2.2: Cada usuario vendedor se autentica en la aplicación mediante login y 
password asignados por el usuario administrador. 
R3.1: El usuario administrador puede crear y eliminar usuarios vendedores. 
R3.2: En el momento de crear un usuario vendedor la información que se debe tener 
en cuenta es: Nombre, Login, Password y Teléfono. 
R4: El usuario administrador puede consultar la información (R3.2) de cualquier 
usuario vendedor creado previamente. 
R5: El usuario administrador puede cambiar su contraseña. 
R6.1: El usuario vendedor puede elegir visualizar, en cualquier nivel de 
acercamiento, la posición de los clientes que le pertenecen (representada por 
puntos). 
R6.2: En el nivel 3 del mapa el usuario vendedor puede consultar la información de 
sus clientes (usa R6.1). 
R7.1: En el nivel 3 del mapa el usuario vendedor puede crear clientes indicando una 
posición específica. La información de un cliente es: Identificación (NIT o 
Cédula), Código (Id único), Nombre, Dirección, Contacto (Nombre de una 
persona), Email y Teléfono. 
R7.2: En el nivel 3 del mapa el usuario vendedor puede eliminar cualquiera de sus 
clientes (usa R6.1). 
 
Sección 2 – DESARROLLO #1. 
 
Todo desarrollador de SW ha tenido que enfrentar los problemas que trae una mala 
definición de requerimientos. Para evitar esto, antes de iniciar el desarrollo de una 
aplicación, por pequeña que sea, se recomienda realizar un proceso de definición de 
requerimientos que involucre a cliente y desarrollador. Este proceso debe iniciar con 
una reunión en donde el cliente exprese en términos generales la funcionalidad que 
debe tener la aplicación, y debe finalizar con un documento redactado por el 
desarrollador, en donde se exprese detalladamente mediante numerales conocidos 
como requerimientos la funcionalidad que va a tener la aplicación. Cuando cliente y 
desarrollador estén de acuerdo en lo que expresa este documento de requerimientos, 
se deben realizar los tramites respectivos que le dan legitimidad al documento. 
 
En el caso particular de la aplicación que nos ocupa, nunca se llego a un documento 
detallado de requerimientos, solo se hizo una reunión en donde el cliente expreso sus 
necesidades y de ahí en adelante el desarrollador interpretó las cosas a su modo. Los 
requerimientos que se presentan al final de la sección anterior fueron redactados al 
terminar el desarrollo. Los problemas vinieron en el momento de las entregas cuando 
el cliente comunicó al desarrollador funciones adicionales que la aplicación debía 
realizar, y como es bien sabido por los desarrolladores modificar un software puede 
ser mucho más costoso que crear uno nuevo. Por esto el proceso de definición de 
requerimientos es tan importante. En este proceso es donde el cliente debe tratar de 
expresar de la mejor manera las características de la aplicación, y el desarrollador 
debe tratar de entender como es el medio en donde se mueve el cliente, a fin de 
crear un SW coherente con las necesidades del cliente. 
 
Al iniciar este primer desarrollo se tenían unos requerimientos vagamente definidos, 
consignados esencialmente en la mente del desarrollador, por lo que era posible 
proyectar un proceso de desarrollo ineficiente y con discrepancias respecto al 
esquema de aplicación que el cliente tenía pensado. 
 
Bajo estas condiciones se implementó el software a partir de tres partes en las que el 
desarrollador logro dividir la aplicación: control de acceso a los usuarios, opciones del 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
15
En caso de que la funcionalidad 
del objeto involucre persistencia 
en una base de datos. 
Objeto 
Gráfico 
Inicio: 
Creación de objetos gráficos
Funcionalidad ante un evento 
sobre el objeto grafico (si es que 
se necesita manejar). 
usuario administrador y opciones del usuario vendedor. Para implementar estas tres 
partes en las que fue dividida la aplicación, se inicio por la creación de los objetos 
gráficos que iban a permitir la interacción con los usuarios, luego por cada objeto 
gráfico, siguiendo el paradigma de programación por eventos bajo el cual funciona el 
SO de la palm, se programó la funcionalidad de la aplicación y a medida que se iba 
necesitando se fueron definiendo bases de datos1 que almacenaran los items (v.gr. 
usuarios, clientes, coordenadas) importantes que la aplicación debía manejar. Esta 
forma de desarrollar mezclaba tres niveles de desarrollo en un mismo sitio (gráfico, 
funcional y persistente), sin embargo para el desarrollador fue útil tener un esquema 
mental que separaba estos tres niveles (ver figura 5.1). Con base en este esquema 
mental, en el capítulo 8 se intenta separar la aplicación en capas, como parte del 
modelaje de un segundo desarrollo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Figura 5.1 – Esquema mental del desarrollador 
 
Cuando se programa en palm, para poder mostrar un objeto o conjunto de objetos 
gráficos es necesario definir una plantilla (form) sobre la cual se puedan pintar los 
objetos. Debido al poco espacio con que cuenta la pantalla de una palm (160x160 
píxeles), durante el desarrollo muchas veces fue necesario definir una secuencia de 
plantillas para que los usuarios pudieran realizar una operación, por ejemplo crear un 
nuevo cliente involucra tres plantillas (figura 5.2), la primera contiene un botón para 
ingresar al mapa, en la segunda se dibuja el mapa y el usuario indica la posición en 
donde desea crear el cliente, y la tercera se utiliza para llenar la información asociada 
al cliente. 
 
 
 
Figura 5.2 – Secuencia de plantillas para crear un nuevo cliente 
 
 
1 Estas bases de datos corresponden a las ofrecidas por el API de la palm; archivos con extensión PDB o PRC 
en los que es posible almacenar o consultar registros. En el capítulo 9 se presentan otras alternativas para 
manejar la persistencia de una aplicación palm. 
F(t1 a, t2 b)
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
16
Un dispositivo palm a diferencia de un PC no puede leer archivos de diversos 
formatos. Por ejemplo archivos tipo BMP o CSV contienen una estructura que no 
puede ser reconocida por el sistema operativo de la palm, ni por ninguna aplicacióndiseñada para palm. Una palm trabaja con un conjunto muy limitado de tipos de 
archivo. Los archivos palm más utilizados son probablemente PRC (Palm Resource), 
PDB (Palm Database) y PQA (Palm Query Application). Cada archivo palm se 
compone de un conjunto ordenado de registros y de un encabezado que contiene 
datos importantes del archivo, como por ejemplo nombre, identificador, tamaño, 
número de registros, etc. 
Esta limitación en los tipos de archivo palm obligó a crear, durante el proceso de 
desarrollo, otra aplicación que almacena en un archivo de recursos (PRC) las 
imágenes BMP de los mapas y los registros que a cada BMP le hacen corresponder 
coordenadas de longitud y latitud. Este generador de bases de datos palm, que 
contienen mapas, hizo posible que cada mapa se presentara como un archivo 
independiente que la aplicación era capaz de leer. 
 
El proceso de interacción con el cliente consistía de reuniones quincenales en donde 
se mostraba el estado en que se encontraba la aplicación, allí el cliente indicaba que 
cambios necesitaba la aplicación y se negociaba un plazo para entregar dichas 
modificaciones. Para comprobar que la aplicación no tuviera errores, después de 
realizar los cambios que el cliente solicitaba, el desarrollador (siempre que hubiera 
tiempo) ideaba una lista de puntos críticos en donde podría fallar la aplicación e iba 
probando uno a uno. 
 
Una vez el desarrollo contempló todos los aspectos funcionales que el desarrollador 
creía necesarios, la aplicación se fue modificando según el cliente iba indicando que 
cosas nuevas debían ser agregadas. Solo hasta que el cliente estuvo satisfecho se 
hizo una entrega oficial de la aplicación con un manual en donde se explica con 
detalle como interactuar con la aplicación [8]. 
 
El siguiente es un inventario de resultados del desarrollo #1: 
 
# # Desarrolladores: 1 
# Horas de trabajo aprox.: 150 
# Lenguaje: Metrowerks Standard Libraries (MSL) para C y C++, Librerías de 
recursos para la plataforma PALM OS. 
# SDK: CodeWarrior 
# Tamaño aplicación: 64.1 KB 
# Archivos fuente: 
 
Nombre Líneas Tamaño 
Starter.c 5510 170 KB 
FuncionesGlobales.c 811 22.2 KB 
Clientes.c 160 4.5 KB 
Usuarios.c 164 4.92 KB 
OpcionesAdmin.c 78 2.59 KB 
TOTAL 6723 204.21 KB 
 
 Tabla 5.1 – Descripción de archivos del desarrollo #1 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
17
Sección 3 – LLEVAR UN REGISTRO DE PROBLEMAS 
PRESENTADOS DURANTE EL DESARROLLO #1. 
 
El proceso de desarrollo que se relata en la sección anterior sirve para detectar 
problemas que no solo se pueden eliminar o disminuir en la segunda implementación, 
también es posible encontrar las implicaciones que estos tienen sobre las 
restricciones propias de los dispositivos móviles. Algunos de los siguientes problemas 
se utilizan como guía para el desarrollo #2. 
 
3.1 Empezar a desarrollar desde la interfaz es ineficiente porque el desarrollador 
consume mucho tiempo en los detalles gráficos y pierde la idea de la 
funcionalidad que en un principio quería implementar. 
3.2 Cuando se utiliza un esquema de desarrollo que inicia en la interfaz, la 
funcionalidad y la persistencia quedan ligadas a los componentes. Esto por lo 
general produce código ineficiente, por ejemplo se desaprovecha la reutilización 
de funciones. 
3.3 La mala definición de requerimientos resulta en interpretaciones equivocadas 
acerca de la funcionalidad que debe tener la aplicación. Lo anterior tiene como 
consecuencia insatisfacción del cliente, que por lo general resulta en pérdidas 
de tiempo y dinero. 
3.4 La mezcla de interfaz, funcionalidad y persistencia tiene como resultado SW 
poco flexible y difícil de mantener. 
3.5 En aplicaciones donde se requiere de un proceso extenso de interacción entre 
cliente y desarrollador, es recomendable definir un modelaje que permita 
identificar claramente la funcionalidad de la aplicación antes de empezar a 
implementar. 
3.6 Un desarrollo de SW sin un modelo conceptual, difícilmente puede tener una 
implementación modular, ni una documentación clara. Cuando se desarrolla SW 
en equipo, existe mayor posibilidad de éxito cuando la aplicación tiene una 
división modular y los participantes son organizados para documentar su 
trabajo. 
3.7 Un proceso de SW que no posee una etapa de modelaje, generalmente no 
permite detenerse a idear maneras sencillas y amigables para la interacción con 
los usuarios. 
3.8 Desarrollar sujeto a un cronograma muy apretado, muchas veces resulta en 
implementaciones con código ineficiente y documentación pobre. 
3.9 Cada vez que se realiza un cambio o una adición de funcionalidad a una 
aplicación, se afecta su entropía. La entropía determina el nivel de desorden al 
interior de un programa, cuando una aplicación alcanza su nivel de entropía 
crítico es preferible comenzar un nuevo desarrollo. 
3.10 Cuando los servicios de persistencia con que cuenta una aplicación son 
limitados, la funcionalidad se ve recargada con algoritmos complejos y se utiliza 
más memoria temporal en ejecución. 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
18
CAPÍTULO 6 ANÁLISIS DE PROBLEMAS 
PRESENTADOS DURANTE EL 
DESARROLLO #1 
 
El capítulo anterior finalizo con problemas encontrados en el primer desarrollo. En 
este capítulo se eligen cinco de estos problemas, se explican de manera detallada y 
se muestra su impacto sobre algunas de las restricciones de los dispositivos móviles. 
 
Sección 1 - ESCOGER UN CONJUNTO CONCRETO DE PROBLEMAS. 
 
De los diez problemas presentados en el capítulo anterior, los siguientes se 
escogieron, porque se relacionan con restricciones presentes en los dispositivos 
móviles, o porque es posible restringirlos mediante un proceso de modelaje: 
 
1. Cuando se utiliza un esquema de desarrollo que inicia en la interfaz, la 
funcionalidad y la persistencia quedan ligadas a los componentes gráficos. 
Esto por lo general produce código ineficiente, por ejemplo se desaprovecha la 
reutilización de funciones. (3.2) 
2. La mezcla de interfaz, funcionalidad y persistencia tiene como resultado SW 
poco flexible y difícil de mantener. (3.4) 
3. Un desarrollo de SW sin un modelo conceptual, difícilmente puede tener una 
implementación modular, ni una documentación clara. Cuando se desarrolla 
SW en equipo, existe mayor posibilidad de éxito cuando la aplicación tiene 
una división modular y los participantes son organizados para documentar su 
trabajo. (3.6) 
4. Un proceso de SW que no posee una etapa de modelaje, generalmente no 
permite detenerse a idear maneras sencillas y amigables para la interacción 
con los usuarios. (3.7) 
5. Cuando los servicios de persistencia con que cuenta una aplicación son 
limitados, la funcionalidad se ve recargada con algoritmos complejos y se 
utiliza más memoria temporal en ejecución. (3.10) 
 
Sección 2 – PROFUNDIZAR EN LOS PROBLEMAS ESCOGIDOS. 
 
Las limitaciones que tienen los dispositivos móviles, obligan al desarrollador de SW a 
tener en cuenta dentro de la lógica de sus programas, nuevos requerimientos no 
funcionales como la cantidad de memoria disponible o el tamaño de la pantalla. Con 
los problemas de la sección anterior es posible visualizar de que manera enfoques de 
desarrollo similares al presentado en el capítulo 5, resultan en procesos de desarrollo 
ineficientes y aplicaciones que van en contra de las limitaciones presentes en los 
dispositivos móviles. 
 
Problema #1: 
Algunos programadores tienen la costumbre de separar las aplicaciones que se 
disponen a crear en dos componentes llamados: núcleo e interfaz gráfica. El 
núcleo es la parte funcional o lógica del programa que cumple con todos los 
requerimientos propuestos, pero que carece o utiliza una forma muy pobre para 
comunicarse con los usuarios. La interfaz gráfica es un componente intermediario 
entre los usuarios y el núcleo, que debe ofrecer manipulación sencilla y amable. 
En el proceso de desarrollode la aplicación, comenzar por el núcleo y terminar por 
la interfaz parece ser una buena practica de programación. Esto se debe a que el 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
19
programador puede concentrase primero en que la aplicación ‘funcione’, y no 
desperdiciar tiempo en una visualización que probablemente más tarde cambie por 
sugerencia misma de los usuarios. Adicionalmente esta manera de proceder en el 
desarrollo permite independizar el núcleo de la interfaz gráfica, garantizando que 
cambios futuros en un componente no afecten al otro. 
 
En un dispositivo móvil una restricción importante es el tamaño de la pantalla. El 
programador debe trabajar con este tamaño para ofrecer una aplicación 
balanceada que no inunde la pantalla con información y opciones, pero que 
contenga información suficiente para una interacción sencilla. 
Si el desarrollador inicia el proceso por la interfaz está sujeto a dos problemas 
fundamentales: 
 
# En su afán por hacer uso eficiente del tiempo y pasar a la parte funcional 
no es cuidadoso en el diseño de la interfaz. 
# Al inicio del desarrollo no se tiene un entendimiento profundo del problema 
que se va a solucionar (incluso si se realizan exhaustivos procesos de 
modelaje), de esta forma el programador desperdicia tiempo pensando en 
como va ser el funcionamiento interno del programa con respecto a la 
interfaz que está diseñando. 
 
Estas dos dificultades pueden producir una interfaz inconsistente, redundante, 
incompleta, poco amigable con el usuario, etc. 
Si primero se implementa la parte funcional, se asegura que el programa funcione 
de manera correcta internamente. Luego para crear una buena interfaz, se puede 
acudir a un diseñador gráfico o consultar las técnicas que proponen los expertos 
en el manejo del dispositivo. Por ejemplo, la compañía Palm ofrece en un 
documento llamado Palm OS Companion una guía para crear interfaces acordes 
con los dispositivos Palm y con lo que los usuarios esperan [9]. Aunque este 
documento parece estar limitado a los productos Palm, las similitudes entre los 
dispositivos móviles y las expectativas que los usuarios tienen de ellos, lo 
convierten en una excelente guía para el desarrollo de aplicaciones móviles. 
 
Problema #2: 
Un patrón común en implementaciones que no cuentan con un modelaje previo, 
como la relatada en el capítulo anterior, es la mezcla de persistencia (P), 
funcionalidad (F) e interfaz gráfica (IG). Esto se da porque el desarrollador, con la 
intención de cumplir con los requerimientos del cliente, realiza lo que podría 
llamarse programación vertical. Con programación vertical se hace referencia a 
tomar un requerimiento y asegurarse que funcione completamente pasando por 
los estratos P, F e IG. Bajo este concepto se tiene código ineficiente porque se 
diseñan rutinas en los tres estratos, específicas para cada requerimiento. Si en 
cambio se hubiera hecho un modelaje sería posible capturar los servicios de P, F e 
IG por separado para realizar programación horizontal, y posiblemente encontrar 
que para distintos requerimientos se puede compartir código. 
 
Al compartir código se reduce considerablemente el tamaño de la aplicación, 
evitando la sobrecarga sobre recursos limitados de los dispositivos móviles como 
el procesador o el tamaño de la memoria. Además se prevén complicaciones 
futuras respecto a mantenimiento o extensión de la funcionalidad, ya que es en 
este punto donde un programa poco flexible requiere de medidas extremas como 
volver a empezar el desarrollo o agregar ‘parches’ de código por cada cambio. 
Estos ‘parches’, como se les conoce, aumentan el tamaño del código hasta tal 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
20
punto que el compilador no es capaz de direccionarlo, como ocurre en algunos 
paquetes de desarrollo para dispositivos Palm (máximo 64K). 
 
Problema #3: 
En el problema anterior se hablaba de los estratos P, F e IG, que semejan la 
estructura vertical de la aplicación. Sin embargo, cuando se realiza modelaje, es 
posible partir dichos estratos en módulos que conforman la estructura horizontal 
de la aplicación. Esto es particularmente útil cuando se realiza software en equipo, 
porque ayuda a definir las responsabilidades de cada módulo y la interacción entre 
distintos módulos, así es posible dividir el trabajo y que los participantes entiendan 
el funcionamiento global de la aplicación. 
 
La falta de un esquema modular en desarrollo de grupo, recae en trabajo 
redundante y conflictos en la definición de responsabilidades. Si bien, los módulos 
son útiles para dividir la aplicación y construirla por partes, muchas veces pueden 
incrementar el número de líneas de código. 
 
Problema #4: 
Las técnicas de modelaje no solo son útiles para diseñar la lógica de la aplicación, 
también pueden ser utilizadas para crear la visualización de la misma. 
En los dispositivos móviles la interfaz gráfica es un elemento crítico para el 
resultado final de la aplicación. Debido a que los usuarios de handhelds, PDAs, 
Celulares, etc., cuando entran en contacto con el dispositivo móvil muchas veces 
se encuentran en movimiento, o en busca de una solución rápida, no tienen la 
paciencia de un usuario de PC. Por este motivo los desarrolladores de aplicaciones 
móviles deben pensar en interfaces prácticas y que continúen con ciertos patrones 
presentes en aplicaciones móviles conocidas, como las que vienen por defecto con 
el dispositivo móvil. 
 
Problema #5: 
En los dispositivos móviles no se cuenta con el mismo poder de almacenamiento y 
manipulación de datos de un PC. Por ejemplo, el sistema operativo Palm OS 
cuenta con un mecanismo de almacenamiento muy limitado para manipular y 
correlacionar la información. 
Estas limitaciones sobre la persistencia de un dispositivo móvil, obligan a cargar la 
información en estructuras dinámicas que facilitan las búsquedas, pero consumen 
memoria temporal extra y alargan el tiempo de ejecución del programa. 
Un sistema de persistencia de más alto nivel, semejante al de un SMBD, tendría 
ventajas como: 
# El almacenamiento podría realizarse en archivos con formato compatible 
con bases de datos usadas en un PC. De tal forma que en el momento de 
sincronizar la información entre el handheld y el PC no se requiera de 
ninguna interpretación. 
# Mayor poder en el nivel de persistencia sugiere que en el modelaje el 
estrato P pueda prestar servicios que facilitan las operaciones que debe 
realizar el estrato F. Por ejemplo, si la persistencia cuenta con lenguaje 
SQL se simplifican las búsquedas en F. 
 
Como comentario importante, no en todas las aplicaciones móviles es bueno 
contar con un sistema de persistencia poderoso. En algunas aplicaciones sencillas, 
puede ser más eficiente y económico utilizar el sistema de persistencia por defecto 
del dispositivo móvil. 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
21
CAPÍTULO 7 MODELAR EL PROBLEMA 
 
A lo largo de este estudio de desarrollo de SW sobre dispositivos móviles, se ha 
presentado un problema específico de tecnología móvil junto con una solución 
ausente de modelaje que busca obtener resultados parciales con agilidad. Esta 
primera solución, fue útil para encontrar varios problemas presentes en una forma 
particular de desarrollar. 
En este y el siguiente capítulo se intenta realizar un modelaje riguroso del problema 
planteado en el capítulo 4, que tenga en cuenta los problemas ya identificados y las 
restricciones de los dispositivos móviles. 
 
Sección 1 - APLICAR ALGUNA HERRAMIENTA DE MODELAJE. 
PLANTEAR LOS PASOS A SEGUIR EN EL MODELAJE Y 
REALIZARLOS. 
 
El modelaje del segundo desarrollo será realizado con base en ciertos conceptos 
propios de la metodología UML (Unified Modeling Language). Aunque UML fue 
diseñado para lenguajes orientados a objetos, existen diagramas que pueden ser 
útiles para crear un diseño modular en una aplicación quese realiza sobre lenguaje 
C. El siguiente modelaje es un pequeño análisis del problema planteado, que utiliza 
diagramas de casos de uso y diseño de módulos para producir, junto con el modelo 
de arquitectura del siguiente capítulo una guía de implementación. 
 
1. Diagramas de casos de uso: Estos diagramas ayudan a identificar los roles de 
usuario y las acciones asociadas a cada rol. Son útiles para verificar que la 
implementación ofrezca un conjunto específico de servicios a cada tipo de 
usuario. 
 
 
 
Figura 7.1 – Casos de uso usuario administrador 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
22
 
 
Figura 7.2 – Casos de uso usuario vendedor 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
2. Diagrama de módulos: Permite dividir la aplicación en módulos que encierran 
funcionalidad asociada a objetos fundamentales detectados en el problema que se 
está solucionando. En el siguiente diagrama se presentan cuatro módulos, los tres 
primeros contienen funcionalidad de clientes, usuarios y mapas, y el cuarto utiliza 
los demás módulos para ofrecer todos los servicios que debe prestar la aplicación. 
Los parámetros de las funciones de cada módulo se especifican en el siguiente 
capítulo. Al lado de cada módulo se explican únicamente las funciones para las 
que el nombre no expresa un significado claro. 
 
 
 
 
 
 
 
Figura 7.3 – Módulos de la aplicació
 
 
 
 
 
 
 
 
 
-
-
-
-Po
Posicion
Este se
las pos
que se
imagen
-ZoomIn( ) 
-ZoomOut( ) 
-MovimientosHorVer( ) 
-ObtenerMapas( ) 
sicionesClientesActuales( )
-EliminarUsuario( ) 
-NuevoUsuario( ) 
-CambiarContrasenaAdmin( ) 
-ConsultarInfoUsuario( ) 
-AutenticarUsuario( )
NuevoCliente( ) 
ConsultarInformacionCliente( ) 
EliminarCliente( ) 
n
e
r
ici
 
 d
ObtenerMapas: 
Devuelve la información de todos 
los mapas que se encuentran 
disponibles en el sistema.
23
 
 
sClientesActuales: 
vicio debe retornar 
ones de los clientes 
encuentran en la 
e mapa actual. 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
24
3. Detallar los campos básicos de la estructura de datos asociada a cada módulo. 
 
 
Figura 7.4 – Detalle módulo clientes 
 
 
Figura 7.5 – Detalle módulo usuarios 
 
 
 Figura 7.6 – Detalle módulo mapas 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
25
CAPÍTULO 8 MODELAR POR CAPAS 
 
El diseño modular del capítulo pasado es importante porque resuelve algunos de los 
problemas expuestos en el capítulo 6, sin embargo no es suficiente para 
contrarrestar la mezcla de los niveles gráfico, funcional y persistente, detectada en el 
primer desarrollo. 
Aunque la primera implementación no separa en el código los tres niveles 
mencionados, en la ejecución del programa si se logra apreciar la interacción entre 
estas capas. Observar esta interacción es útil para generar desde el modelaje del 
segundo desarrollo una separación en capas y una asignación de responsabilidades 
para cada capa. 
En este capítulo concluimos el modelaje separando la aplicación en capas. Luego se 
verifica que se cumple con los requerimientos planteados y que se solucionan los 
problemas del capítulo 6. 
 
Sección 1 - SEPARAR LA APLICACIÓN EN CAPAS BIEN 
DEFINIDAS. 
 
El siguiente es el diagrama de arquitectura de la aplicación, que separa funcionalidad, 
persistencia e interfaz gráfica. Al interior de cada nivel se asume la división modular 
de la figura 7.3. 
 
 
Figura 8.1 – Arquitectura de la aplicación 
 
Los siguientes diagramas ilustran para cada requerimiento la interacción derivada del 
desarrollo #1 entre los niveles IG, F y P. 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
26
R1.1: Almacenar, en un dispositivo móvil, cualquier mapa con sus tres niveles de acercamiento y las coordenadas de longitud y latitud asociadas a 
cada imagen. Cada imagen es un archivo tipo BMP que tiene asociadas sus coordenadas en un archivo tipo CSV. 
 
Figura 8.2 - Interacción requerimiento R1.1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
No existe representación en este nivel. No existe representación en este nivel. Mapas almacenados en la memoria persistente de la 
palm. 
 
Mapa_1.prc 
. . . 
Mapa_i.prc 
. . . 
 salida 
 
GRAFICO FUNCIONAL PERSISTENTE
Generador de archivos 
PRC que contienen 
información suficiente 
ARCHIVO
CSV
BMPs Zoom 1 
BMPs Zoom 2 
BMPs Zoom 3 
entrada 1 entrada 2 
 
 
 
R1.2: Mostrar al usuario administrador una lista de los
podrá elegir el mapa que la aplicación debe carga
 
F
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO 
click
ISCISCISCISC----2002200220022002----2222----20202020 
27
 mapas que se encuentran almacenados en el dispositivo móvil. El usuario administrador 
r. 
igura 8.3 - Interacción requerimiento R1.2 
 
 
 
 
 
 
 BASE DE DATOS DEL 
MAPA 
 
 
 
 
FUNCIONAL PERSISTENTE
Recibe: posNomMapa (La posición del 
nombre de mapa seleccionado). 
Acción: Abrir la base de datos que contiene 
el mapa que corresponde a posNomMapa. 
Recibe: Petición de abrir una base de datos 
que contiene un mapa ( archivo PRC). 
Acción: Devolver una referencia a la base 
de datos. 
Recibe: Referencia a la BD del mapa. 
Acción: Cargar el mapa que se encuentra 
en la base de datos en memoria principal 
para tener acceso rápido: 
 
1. Cargar las dimensiones de los tres 
niveles de zoom. 
 
2. Cargar cada imagen de cada nivel de 
zoom con sus coordenadas de latitud y 
longitud asociadas 
 
Estructura de almacenamiento de cada 
imagen del mapa: 
Acceso a imagen Img 
Longitud Izquierda LonIzq 
Latitud Izquierda LatIzq 
Longitud Derecha LonDer 
Latitud Derecha LatDer 
Fila en la matriz Fila 
Columna en la matriz Columna 
Dimensiones Niveles de Zoom
. . . 
Imagen; Longitudes; Latitudes
. . . 
 ISCISCISCISC----20202020
 
 
R1.3: Según el mapa que el administrador haya decidido cargar, permitir a cada u
y dentro de cada nivel con movimientos horizontales y verticales. 
 
Figura 8.4 - Interacción requerim
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
 
click 
Recibe: Longitud y Latitud del clic
Acción: Buscar en el siguiente niv
zoom la imagen que contiene las 
coordenadas y establecerla como 
imagen actual, luego indicarle a la
que la muestre. 
 
click 
Recibe: Longitud y Latitud del clic
Acción: Buscar en el anterior nive
la imagen que contiene las coorde
establecerla como la nueva image
luego indicarle a la interfaz que la 
 
click 
Recibe: Comando de movimiento 
abajo, izquierda o derecha). 
Acción: Buscar en el mismo nivel
en la dirección del comando de mo
la imagen adyacente y cargarla co
nueva imagen actual, luego indica
interfaz que la muestre. 
02020202----2222----20202020 
28
suario vendedor navegar entre los tres niveles de acercamiento 
iento R1.3 
No existe representación en este nivel.
 
 
 
 
 
 
 
 
 
 
PERSISTENTE
k.
el de 
la nueva 
 interfaz 
k.
l de zoom 
nadas y 
n actual, 
muestre. 
(arriba, 
 de zoom, 
vimiento, 
mo la 
rle a la 
 ISCISCISCISC----2002200220022002
 
 
R2.1: Para poder realizar funciones de administración de la aplicación, el usuario admini
 
Figura 8.5 - Interacción requerimie
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
Recibe: Contraseña digitada.
Acción: Obtener de la base de datos la
contraseña real del usuario administrad
Recibe: Contraseña del usuario 
administrador. 
Acción: Comparar la contraseña obten
de la base de datos con la digitada, si s
iguales solicitar a la interfaz mostrar las
opciones del usuario administrador. 
----2222----20202020 
29
strador debe autenticarse con una contraseña. 
nto R2.1 
 
 
 
 
 
 
 
 
 
PERSISTENTE
 
or. 
Recibe:Petición de la contraseña del 
usuario administrador. 
Acción: Retornar una cadena con la 
contraseña del usuario administrador. 
ida 
on 
 
 ISCISCISCISC----200200200200
 
 
R2.2: Cada usuario vendedor se autentica en la aplicación mediante login y password a
 
Figura 8.6 - Interacción requerimi
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
Recibe: Login y password digitados.
Acción: Buscar en la base de datos 
password que corresponde al login re
de la interfaz: 
 i = 0 
mientras(hayMasUsrs) { 
 ! Obtener login y passwo
usuario i 
 " Comparar los de la bas
datos con 
los digitados. Si son iguales in
interfaz que muestre las opcio
usuario vendedor 
# i = i+1;
2222----2222----20202020 
30
signados por el usuario administrador. 
ento R2.2 
 
 
 
 
 
 
 
 
 
PERSISTENTE
el 
cibido 
rd del 
e de 
dicar a la 
nes del 
Recibe: Login y password digitados.
Acción: Buscar en la base de datos el 
password que corresponde al login recibido 
de la interfaz. 
Recibe: Un numero entero mayor o igual a 
cero. 
Acción: Retorna los campos login y 
password del record i de la base de datos de 
usuarios vendedores.
 ISCISCISCISC----20202020
 
 
R3.1: El usuario administrador puede crear y eliminar usuarios vendedores. 
R3.2: En el momento de crear un usuario vendedor la información que se debe tener
 
Figura 8.7 - Interacción requerimie
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
Recibe: Datos de un nuevo usuario
vendedor. 
Acción: Almacenar los datos del n
usuario vendedor en la base de da
asegurándose que el campo login s
identificador único de cada vended
Recibe: La posición ( posElimVend
un vendedor en la base de datos d
vendedores. 
Acción: Solicitar a la base de dato
vendedores que elimine el registro 
encuentra en la posición posElimV
02020202----2222----20202020 
31
 en cuenta es: Nombre, Login, Password y Teléfono. 
nto R3.1, R3.2 
BASE DE DATOS DE USUARIOS VENDEDORES
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Usuario_1 
... 
Usuario_posElimVendedor 
... 
 
PERSISTENTE
 
uevo 
tos, 
ea un 
or. 
. . . 
Nombre; Telefono; Login; Password
. . . 
edor ) de 
e 
s de 
que se 
endedor. 
ELIM 
 ISCISCISCISC----2002200220022002
 
 
R4: El usuario administrador puede consultar la información (R3.2) de cualquier usuar
 
Figura 8.8 - Interacción requerimie
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
Recibe: La posición ( posVerVended
un vendedor en la base de datos de
vendedores. 
Acción: Solicitar a la base de datos 
vendedores la información del vende
la posición posVerVendedor. 
Recibe: Datos de un vendedor.
Acción: Enviar a la interfaz los dato
vendedor y le indica que los muestre
----2222----20202020 
32
io vendedor creado previamente. 
nto R4 
 
 
 
 
 
 
 
 
 
PERSISTENTE
or ) de 
 
de 
dor en 
Recibe: posVerVendedor.
Acción: Retorna los datos del vendedor en 
la posición posVerVendedor. 
s del 
. 
 ISCISCISCISC----2002200220022002
 
 
R5: El usuario administrador puede cambiar su contraseña. 
 
Figura 8.9 - Interacción requerimie
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
Recibe: Tres cadenas ( s1, s2, s3 ).
Acción: Comparar s2 con s3, si son ig
consultar a la base de datos la contras
del usuario administrador. 
Recibe: Una cadena ( pwdAdmin ).
Acción: Comparar s1 con pwdAdmin, 
iguales solicitar a la base de datos que
cambie la contraseña del usuario 
administrador por s1.
----2222----20202020 
33
nto R5 
 
 
 
 
 
 
 
 
 
PERSISTENTE
uales 
eña 
Recibe: Petición de la contraseña del 
usuario administrador. 
Acción: Retornar una cadena con la 
contraseña del usuario administrador. 
si son 
 
Recibe: s1.
Acción: Reemplazar la contraseña del 
usuario administrador por s1. 
 
 
 
R6.1: El usuario vendedor puede elegir visualizar, en cualqu
puntos). 
 
Figura 8
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO 
 
 
 
Rec
clie
enc
( lo
Acc
coo
de 
log
Rec
bas
Acc
lista
den
visu
dich
la in
ISCISCISCISC----20202020
ier nivel de acercamiento
.10 - Interacción requeri
FUNCIONAL
ibe: Petición de mostrar en el m
ntes del usuario vendedor que s
uentra autenticado en la aplicac
gin_usr ). 
ión: Generar una lista (listaCoo
rdenadas, a partir de peticiones
datos, de los clientes asociados
in_usr. 
ibe: Indicación de fin del recorr
e de datos de clientes. 
ión: Tomar cada elemento de l
Coord y revisar si las coordena
tro de la imagen del mapa que 
alizando, en caso de ser así co
as coordenadas a píxeles y en
terfaz para que pinte un punto.
02020202----2222----20202020 
34
, la posición de los clientes que le pertenecen (representada por 
miento R6.1 
 
 
 
 
 
 
 
 
 
PERSISTENTE
apa los 
e 
ión 
rd) de 
 a la base 
 a 
Recibe: login_usr, un entero i que indica una 
posición en la base de datos de clientes . 
Acción: Si el cliente en la posición i de la 
base de datos de clientes esta asociado con 
login_usr entonces retorna las coordenadas 
del cliente en la posición i. 
ido de la 
a lista 
das están 
se esta 
nvertir 
viarlos a 
 
 ISCISCISCISC----20202020
 
 
R6.2: En el nivel 3 del mapa el usuario vendedor puede consultar la información de s
 
Figura 8.11 - Interacción requeri
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
GRAFICO FUNCIONAL
Recibe: La posición de un client
pixelY ) y el login de un usuario v
( login_usr ). 
Acción: Convertir la posición da
pixelX, pixelY a coordenadas de
latitud ( lon, lat ). Buscar en la ba
de clientes el cliente que le perte
login_usr y que se encuentra ma
<lon, lat>: 
i = 0 
mientras(hayMasClientes) { 
! Consultar a la base de da
clientes si el registro en l
corresponde a lon, lat y lo
tal caso pedir la informac
al cliente. 
" i = i+1; 
 } 
Recibe: Información de un client
Acción: Enviar la información de
interfaz para que la muestre. 
02020202----2222----20202020 
35
us clientes (Usa R6.1). 
miento R6.2 
 
 
 
 
 
 
 
 
 
PERSISTENTE
e ( pixelX, 
endedor 
da por 
 longitud y 
se de datos 
nece a 
s cerca de 
tos de 
a posición i 
gin_usr, en 
ión asociada 
Recibe: lon, lat, i, login_usr.
Acción: Verificar si los datos del cliente en la 
posición i corresponden a lon, lat y login_usr. 
Si corresponden retornar la información 
asociada al cliente.
e cli. 
 cli a la 
 ISCISCISCISC----2002200220022002----2222----20202020 
 
 
36
R7.1: En el nivel 3 del mapa el usuario vendedor puede crear clientes indicando una posición específica. La información de un cliente es: 
Identificación (NIT o Cédula), Código (Id único), Nombre, Dirección, Contacto (Nombre de una persona), Email y Teléfono. 
 
Figura 8.12 - Interacción requerimiento R7.1 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Cliente_1 
... 
Cliente_i 
... 
Cliente_Nuevo 
 
GRAFICO FUNCIONAL PERSISTENTE
Recibe: Requerimiento de crear nuevo 
cliente. 
Acción: Indicar a la interfaz que muestre el 
formulario de datos del clientes. 
Recibe: El login de un usuario. La posición, 
la cédula, el código, el nombre, el contacto, 
la dirección, el teléfono y el email de un 
cliente. 
Acción: Con la información recibida dirigirse 
a la base de datos a crear un nuevo cliente. 
CREAR 
 ISCISCISCISC----200200200200
 
 
R7.2: En el nivel 3 del mapa el usuario vendedor puede eliminar cualquiera de sus clie
 
Figura 8.13 - Interacción requerim
 
 
 
 
GRAFICO FUNCIONAL
Recibe: La posición de un cliente ( pix
pixelY ) y el login de un usuario vende
( login_usr ). 
Acción: Convertir la posición dada po
pixelX, pixelY a coordenadas de longi
latitud ( lon, lat ). Buscar en la base de
de clientes el cliente que le pertenece
login_usr y que se encuentra mas cer
<lon, lat>: 
i = 0 
mientras(hayMasClientes) { 
! Consultar