Desarrollo de Aplicaciones para Dispositivos Móviles. Tesis de Ivan Carlos Rivera Gonzalez

ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL NUMERO 00922681 DE FECHA 23 DE JUNIO DE 1992

SVES. DESARROLLO DE APLICACIONES PARA DISPOSITIVOS MÓVILES

TESIS

QUE PARA OBTENER EL TÍTULO DE

INGENIERO EN COMPUTACIÓN

PRESENTA:

IVÁN CARLOS RIVERA GONZÁLEZ

ASESOR: EUGENIO JACOBO HERNÁNDEZ VALDELAMAR

MÉXICO, D.F.

MARZO DE 2003

RESUMEN El interés por crear aplicaciones para Dispositivos Móviles ha aumentado en la misma medida que estos han demostrado su funcionalidad. Además, con el aumento en las capacidades de procesamiento de estos dispositivos se ha abierto todo un abanico de posibilidades de aplicación de los mismos. Sin embargo, cuando se considera elaborar aplicaciones para dispositos móviles, la principal dificultad que se debe enfrentar es la elección de una plataforma de desarrollo, entendida ésta como una combinación de metodología de análisis y diseño de sistemas, lenguaje de programación, sistema operativo sobre el que se trabaja, etc. Para enfrentar un problema como este, se debe plantear la elección de una Metodología de Análisis y Diseño de Sistemas adecuada, muy probablemente Orientada a Objetos. Se debe hacer un Análisis y Diseño adecuados, considerando las limitaciones de la plataforma. A partir de un Análisis cuidadoso y diseñando las aplicaciones considerando las restricciones propias de un dispositivo móvil, la correcta aplicación de la plataforma elegida redundará en un proceso de desarrollo más eficiente, rápido, económico y con aplicaciones mas robustas. Como un ejemplo de aplicación de este trabajo, se estudia el “Sistema de Vigilancia Epidemiológica Simplificada” (SVES) de la Secretaría de Salubridad y Asistencia. Los asistentes personales digitalizados son dispositivos con una gran capacidad de procesamiento a un costo relativamente bajo que ponen al alcance de las masas la posibilidad de realizar actividades que antes solo se podían realizar con una computadora personal. Considerando esto, al desarrollar un sistema para PDAs que aplique la metodología del SVES, una franja mas grande de la población tendrá acceso a este mecanismo de atención. El presente trabajo demostrará que es posible aplicar una metodología de Análisis y Diseño de Sistemas que considere las limitaciones de una plataforma como las PDAs para desarrollar aplicaciones de Cómputo Móvil.

INDICE INTRODUCCIÓN..................................................................................................... 1 CAPITULO I DESARROLLO DE SISTEMAS .......................................................... 4 I.1 Conceptos del Software .................................................................................. 5 I.2 Lenguajes de Programación ........................................................................... 6 I.2.1 Qué es un lenguaje de programación ................................................... 6 I.2.2 Evolución de los Lenguajes de Programación ...................................... 9 I.2.3 Clasificación de los Lenguajes de Programación................................ 12 I.2.4 El proceso de la programación............................................................ 14 I.3 Tipos de Sistemas de Cómputo .................................................................... 15 I.3.1 Aplicaciones Monolíticas ..................................................................... 16 I.3.2 Modelo Cliente / Servidor .................................................................... 16 I.3.3 Sistemas Distribuidos.......................................................................... 21 I.3.4 Cómputo Móvil .................................................................................... 22 I.3.5 Comentarios Finales ........................................................................... 25 CAPITULO

II

DESARROLLO

DE

APLICACIONES

PARA

ASISTENTES

PERSONALES DIGITALIZADOS .......................................................................... 26 II.1 Introducción a las PDAs ............................................................................... 27 II.2 Arquitectura de Hardware de la plataforma Palm......................................... 28 II.3 Arquitectura del Sistema Operativo Palm..................................................... 32 II.4 Tipos de aplicaciones................................................................................... 35 II.4.1 Aplicaciones Web reducidas .............................................................. 35 II.4.2 Aplicaciones estándar de Palm .......................................................... 37 II.4.3 Conduits ............................................................................................. 38 II.5 Estructura de una aplicación Palm. .............................................................. 39 II.5.1 Como se genera un ejecutable .......................................................... 41 II.5.2 Common Object File Format .............................................................. 43 II.5.2.1 Archivo Objeto ...................................................................... 43 II.5.2.2 COFF.................................................................................... 44 II.5.2.3 COFF y Palm ........................................................................ 46 II

II.5.2.4 PRC-Tools ............................................................................ 46 II.5.2.5 CodeWarrior ......................................................................... 48 II.5.2.6 Otros..................................................................................... 48 II.6 Integración de un ambiente de desarrollo Palm ........................................... 49 II.6.1 Herramientas de desarrollo disponibles................................................. 49 II.6.1.1 Herramientas Orientadas a formularios .......................................... 50 II.6.1.2 Herramientas Orientadas a la programación tradicional ................. 52 II.6.2 El PalmOs Emulator (POSE) ................................................................. 54 II.7 Características del API de Palm................................................................... 56 II.7.1 APIs Definidas por el usuario ............................................................. 59 II.7.2 El ambiente de desarrollo para este trabajo....................................... 60 II.7.3 CodeWarrior....................................................................................... 60 II.7.4 Eligiendo entre C y C++ ..................................................................... 61 CAPITULO III OMT PARA EL ANÁLISIS Y DISEÑO DE APLICACIONES EN ASISTENTES PERSONALES DIGITALIZADOS ................................................... 66 III.1 Elementos de OMT ..................................................................................... 67 III.1.1 Modelo de Objetos ............................................................................ 67 III.1.2 Modelo Dinámico .............................................................................. 68 III.1.3 Modelo Funcional.............................................................................. 68 III.1.4 Relación entre los Modelos ............................................................... 69 III.2 Proceso de Análisis y Diseño en OMT ........................................................ 70 III.2.1 Análisis.............................................................................................. 71 III.2.1.1 Casos de Uso ............................................................................. 74 III.2.2 Diseño ............................................................................................... 75 III.2.2.1 Diseño de sistemas. ................................................................... 75 III.2.2.2 Diseño de objetos. ...................................................................... 77 III.3 Patrones de Diseño..................................................................................... 79 III.3.1 Qué son los patrones ........................................................................ 79 III.3.1.1 Ventajas de los patrones de diseño............................................ 81 III.3.2 Patrón Modelo Vista Controlador ...................................................... 82 III.3.2.1 Modelo Vista Controlador y desarrollo para Palm....................... 87

III

III.4 Restricciones dadas por la plataforma ........................................................ 87 III.4.1 Los distintos modelos de Palm.......................................................... 89 III.4.2

Características

generales

de

las

computadoras

de

mano,

independientemente de la marca. ............................................................... 90 III.4.3 Comentarios Finales ......................................................................... 90 CAPITULO IV CASO DE ESTUDIO: SVES ........................................................... 95 IV.1 Sistemas de Apoyo en la toma de decisiones ........................................... 96 IV.1.1 Proceso general de toma de decisiones ........................................... 97 IV.1.2 Sistemas de diagnóstico médico. ..................................................... 98 IV.1.2.1 Perspectiva Histórica.................................................................. 99 IV.1.2.2 Sistemas Expertos ................................................................... 100 IV.1.2.3 Funcionamiento de los sistemas de diagnóstico medico.......... 101 IV.1.2.4 Ejemplo .................................................................................... 101 IV.2 Antecedentes del Sistema de Vigilancia Epidemiológica.......................... 102 IV.3 Sistema de vigilancia epidemiológica ....................................................... 105 IV.3.1 Sistemas no convencionales de Información.................................. 106 IV.3.2 Aspectos epidemiológicos .............................................................. 107 IV.4 Sistema de Vigilancia Epidemiológica Simplificada .................................. 107 IV.4.1 Componentes del SVES ................................................................. 108 IV.4.2 Padecimientos Incluidos ................................................................. 109 IV.5 Formatos e instructivos de registro y notificación ..................................... 111 IV.5.1 Plantilla para el Diagnóstico Individual de Enfermedades .............. 111 IV.6 Análisis y Diseño del Sistema ................................................................... 113 IV.6.1 Análisis de la Vista.......................................................................... 113 IV.6.1.1 Enunciado del problema........................................................... 113 IV.6.1.2 Modelo de Objetos ................................................................... 113 IV.6.1.3 Identificación de Objetos y Clases ........................................... 113 IV.6.1.4 Diccionario de Datos ................................................................ 122 IV.6.1.5 Identificar Asociaciones entre clases ....................................... 122 IV.6.1.6 Identificar Atributos................................................................... 122 IV.6.1.7 Refinamiento del modelo usando herencia .............................. 125

IV

IV.6.1.8 Modelo Dinámico...................................................................... 126 IV.6.1.9 Modelo Funcional ..................................................................... 128 IV.6.1.10 Iterar....................................................................................... 130 IV.6.2 Análisis del Modelo ......................................................................... 130 IV.6.2.1 Enunciado del problema (EP)................................................... 130 IV.6.2.2 Modelo de Objetos ................................................................... 130 IV.6.2.2.1 Identificación de Objetos y Clases ................................. 130 IV.6.2.2.2 Buscar sujetos en el EP ................................................. 132 IV.6.2.3 Identificar Asociaciones entre clases ....................................... 134 IV.6.2.4 Identificar Atributos................................................................... 134 IV.6.2.5 Modelo Dinámico...................................................................... 135 IV.6.2.6 Modelo Funcional ..................................................................... 136 IV.6.2.7 Iterar el proceso ....................................................................... 137 IV.7 Análisis del Controlador ............................................................................ 138 IV.7.1 Enunciado del problema (EP) ......................................................... 140 IV.7.1.1Modelo de Objetos .................................................................... 140 IV.7.1.2Modelo Dinámico....................................................................... 141 IV.7.1.3Modelo Funcional ...................................................................... 142 CONCLUSIONES ................................................................................................ 144 BIBLIOGRAFÍA.................................................................................................... 152 ANEXOS.............................................................................................................. 159

V

LISTA DE FIGURAS Figura 1.1 Tipos de software ................................................................................... 5 Figura 1.2 Construcción de un ejecutable ............................................................... 8 Figura 1.3 Ensamblador, Compilador e Interprete ................................................. 10 Figura 1.4 Niveles de los lenguajes de programación ........................................... 13 Figura 1.5 Proceso de programación..................................................................... 15 Figura 1.6 Comunicación Cliente / Servidor .......................................................... 17 Figura 1.7 Clientes y servidores en Internet .......................................................... 19 Figura 1.8 Sistemas Distribuidos ........................................................................... 21 Figura 1.9 Cómputo Móvil...................................................................................... 23 Figura 1.10 Flujos de Información en cómputo móvil. ........................................... 24 Figura 2.1 Palm m505............................................................................................ 27 Figura 2.2 Palm IIIe ............................................................................................... 28 Figura 2.3 El procesador Dragonball ..................................................................... 29 Figura 2.4 Arquitectura del PalmOS ...................................................................... 33 Figura 2.5 Ejecución de una aplicación web reducida. .......................................... 36 Figura 2.6 Otra vista de una aplicación web reducida ........................................... 37 Figura 2.7 Calculadora .......................................................................................... 37 Figura 2.8 Juego pBill para Palm........................................................................... 38 Figura 2.9 Reloj ..................................................................................................... 38 Figura 2.10 Conduit de sincronización diaria de Palm........................................... 39 Figura 2.11 Secuencia de llamadas de Funciones ................................................ 41 Figura 2.12 Niveles de programación .................................................................... 43 Figura 2.14 Generación de un ejecutable.............................................................. 44 Figura 2.15 Generación de un ejecutable con PRC-Tools..................................... 48 Figura 2.16 PE-Coff de Microsoft........................................................................... 49 Figura 2.17 Satellite Forms.................................................................................... 51 Figura 2.18 Pendragon Forms ............................................................................... 52 Figura 2.19 Organización de la API de Palm. ........................................................ 57 Figura 3.1 Relación entre los modelos de OMT..................................................... 69 VI

Figura 3.2 El Proceso de desarrollo de OMT......................................................... 70 Figura 3.3 Casos de Uso ....................................................................................... 75 Figura 3.4 Modelo Vista Controlador ..................................................................... 83 Figura 3.5 Un solo Modelo puede tener varias vistas y controladores................... 83 Figura 3.6 Arquitectura de Modelo Vista Controlador ............................................ 86 Figura 4.1 Proceso de toma de decisiones............................................................ 97 Figura 4.3 Agenda ............................................................................................... 114 Figura 4.4 Agregar una cita ................................................................................. 115 Figura 4.5 Detalles de la cita ............................................................................... 115 Figura 4.6 Nota ligada a una cita ......................................................................... 116 Figura 4.7 Agregar una Dirección ........................................................................ 116 Figura 4.8 Forma Acerca de ................................................................................ 117 Figura 4.9 Catalogo del Constructor .................................................................... 118 Figura 4.11 Diagrama de clases de la Vista ........................................................ 125 Figura 4.12. Caso de Uso MV1A. El PalmOS inicia una aplicación:.................... 126 Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicación: ............................................................................................................................. 127 Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalización de una aplicación................................................................................................. 128 Figura 4.15 Primera versión del diagrama de clases del Modelo ........................ 135 Figura 4.16. Caso de Uso MD01. Usuario diagnóstica un padecimiento............. 135 Figura 4.17 Diagrama de Flujo de Eventos de Elaboración de un diagnóstico.... 136 Figura 4.18 Algoritmo para obtener un diagnóstico ............................................. 137 Figura 4.19 Diagrama de Clases del Modelo....................................................... 138 Figura 4.20 Funciones creadas por Codewarrior................................................. 140 Figura 4.21 Modelo de objetos del Controlador ................................................... 141 Figura 4.22. El Usuario diagnostica padecimiento............................................... 141 Figura 4.23 Diagrama de clases de la Vista. ....................................................... 143 Figura C2. Patrón Modelo Vista Controlador Adaptador...................................... 151

VII

LISTA DE TABLAS Tabla 2.1. Archivos importantes de la Interfaz de Programación de Aplicaciones de Palm....................................................................................................................... 59 Tabla 3.1 Lista de Modelos de PDAs por Fabricante............................................. 87 Tabla 3.1 (cont.) Lista de Modelos de PDAs por Fabricante ................................. 88 Tabla 3.2. Comparación entre los modelos de Palm Inc. ...................................... 89 Tabla 3.3 Comparación de modelos de Handhelds contra una PC ....................... 91 Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) ............. 92 Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) ............. 93 Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) ............. 94 Tabla 4.2 Conocimiento del experto médico, resumido en una tabla. ................. 102 Tabla 4.10 Propiedades de los objetos de la interfaz gráfica .............................. 124 Tabla C1. Comparación de código entre versiones del SVES............................. 149

VIII

INTRODUCCIÓN

Hasta hace relativamente poco tiempo, en los países en vías de desarrollo como México, los avances tecnológicos llegaban con un importante retraso respecto a su aparición en los países desarrollados.

Sin embargo, hoy en día, Internet, la televisión, las telecomunicaciones, etc. permiten que se tenga acceso a la tecnología de forma mas o menos simultanea en todo el mundo.

Un ejemplo de esta afirmación es la plataforma de asistentes personales digitalizados desarrollados por la Firma Palm Inc. cuyo último dispositivo: el Palm Tungnsten T, se presentó en México antes que en el resto del mundo.

Los asistentes personales digitalizados son una plataforma de un gran potencial, ya que poseen una capacidad de procesamiento poderosa a un precio relativamente bajo.

Pero además, en el área de desarrollo de aplicaciones para estos dispositivos se ha presentado un fenómeno particular: los desarrolladores de programas para Palm están dispersos por el mundo, y no solo en los países más industrializados o económicamente más poderosos. Este fenómeno esta ligado al hecho de que los detalles de la plataforma, la documentación y las herramientas de desarrollo están disponibles para todo el público, en forma totalmente gratuita.

Con todo, la programación de aplicaciones para dispositivos móviles es un área de incipiente crecimiento en México. Incluso en el mundo (según cifras de Palm Inc.) el número de desarrolladores registrados es de apenas varios cientos.

2

Esto ofrece a los programadores de los países en vías de desarrollo la oportunidad de experimentar, de ser propositivos y no solo simples usuarios de la tecnología importada.

Sin pretender convertirse en la piedra angular de la programación para dispositivos móviles en México este trabajo busca, precisamente: proponer, dar ideas, pasar de ser usuarios a ser desarrolladores de nueva tecnología.

3

CAPITULO I DESARROLLO DE SISTEMAS

I.1 Conceptos del Software A principios de los 80 no estaba claro cuán importante sería el desarrollo de software. Hoy en día, se ha convertido en el eje de evolución de la industria de la computación, y es el motor que conduce la toma de decisiones comerciales. Esto ha provocado que cambie la percepción que el público tenia del software: de ser un aditamento adicional a la computadora, a ser una plataforma de trabajo que corre sobre un hardware no específico.

En nuestros días el software tiene un doble papel: es un producto que permite explotar toda la potencia del hardware informático; ya sea almacenado dentro de un teléfono celular o dentro de una computadora bancaria, el software transforma información, produciendo, gestionando, modificando, mostrando o transmitiendo información, pero el software también sirve como vehículo para hacer entrega de un producto, ya que actúa como la base de control de la computadora, la comunicación de información, y la creación y control de otros programas.

Figura 1.1 Tipos de software

5

Dentro del gran conjunto de programas representados por el termino "software", se pueden hacer dos grandes divisiones, de acuerdo a la función que desempeñan. Una formada por el llamado Software de Sistema, encargado de apoyar al usuario en la administración de su hardware, y la otra conformada por el Software de Aplicación, subconjunto

que agrupa a todos los programas que

resuelven necesidades y problemas específicos de los usuarios. Así, cuando un usuario desea capturar un texto y darle formato, utilizar distintos tipos y tamaños de letra y revisarlo ortográficamente, tiene que recurrir a un software de aplicación. Igual debe hacerlo si desea capturar y manipular grandes volúmenes de datos, o hacer muchos cálculos o si lo que quiere es construir imágenes y darles animación. Mientras que si respalda archivos o administra impresoras, estará usando software de sistema. Aunque el término "Sistema" se usa también como sinónimo de software, y en especial en el presente documento, específicamente del software de aplicación.

Pero, para que la computadora pueda ejecutar cualquier tarea, se le debe programar para que la haga, colocando en su memoria principal un algoritmo apropiado, expresado en algún lenguaje de programación.

I.2 Lenguajes de Programación I.2.1 Qué es un lenguaje de programación Como se menciona en el capítulo anterior, se presenta la necesidad de expresar los algoritmos en una sintaxis no ambigua y a un nivel de detalle bien establecido. Estos dos requisitos se resuelven mediante el uso de primitivas. [Brookshear, 1995] explica que una primitiva consiste en una estructura semántica bien definida junto con una sintaxis no ambigua para representarla.

Tenemos entonces, que para representar algoritmos se debe contar con una colección suficientemente rica de primitivas que, junto con las reglas de

6

combinación para representar estructuras más complejas, constituyen un lenguaje de programación.

La Enciclopedia de Términos de Microcomputación define Lenguaje de programación como los conjuntos de símbolos y de reglas que se pueden combinar en forma sistemática para comunicar pensamientos e ideas, y específicamente aquellos que sirven para escribir instrucciones de computadora. El lenguaje Incluye vocabulario, y reglas o convenciones que rigen la forma y secuencia en que se escriben las instrucciones para su ejecución en la computadora.

También para [Joyanes, 1988] un lenguaje de programación es un conjunto de reglas, símbolos y palabras que permiten construir un programa. Al igual que los lenguajes humanos tales como el inglés o el español, los lenguajes de programación poseen una estructura (gramática o sintaxis) y un significado (semántica).

La sintaxis es el conjunto de reglas que gobiernan la construcción o formación de sentencias (instrucciones) válidas en el lenguaje. La semántica es el conjunto de reglas que proporcionan el significado de una sentencia o instrucción del lenguaje.

El vocabulario de un lenguaje es un conjunto de símbolos. Los símbolos usuales son: letras, dígitos, símbolos especiales (,;:/&+-*, etc.) y palabras reservadas o claves, y las reglas sintácticas son los métodos de producción de sentencias o instrucciones válidas que permitirán formar un programa.

Según menciona [Brookshear, op. cit.], la

implantación de los lenguajes de

programación de alto nivel se basa en el proceso de convertir programas escritos en esos lenguajes en programas escritos en lenguaje de máquina.

7

La traducción de un programa consiste en tres actividades: análisis léxico, análisis sintáctico y generación de código

Anál i s i s l éx i c o

Anál i s i s s i n t ác t i c o

Gener aci ón de c ódi go

Pr ogr ama Fuent e

Pr ogr ama ob j et o

Figura 1.2 Construcción de un ejecutable

El análisis léxico es el proceso de reconocer qué cadenas de símbolos del programa que se ha de traducir (llamado programa fuente) representan en realidad un solo objeto elemental. Por ejemplo, la cadena de símbolos 153 no debe representarse como un 1 seguido de un 5 seguido de un 3, sino que debe reconocerse como la representación de un solo valor numérico. De manera similar, aunque los identificadores que aparecen en un programa están formados por varios caracteres, se deben interpretar colectivamente como un nombre, no como caracteres individuales.

La segunda actividad del proceso de traducción, el análisis sintáctico, es el proceso de analizar la estructura gramatical de un enunciado y reconocer el papel de sus componentes.

A fin de simplificar la tarea del análisis sintáctico, la colección de estructuras de enunciados que tiene un lenguaje de programación es menos variada que la de un

8

lenguaje natural, y está limitada a unas cuantas formas cuidadosamente escogidas.

La actividad final en la traducción de un programa es la generación de código, es el proceso de construir secuencias de instrucciones en lenguaje de máquina que simulen a los enunciados reconocidos por el analizador sintáctico, y es el que genera el producto final del proceso de traducción: el programa objeto.

I.2.2 Evolución de los Lenguajes de Programación Al igual que el software, hay varias formas desde las que pueden verse o clasificarse los lenguajes de programación: por su nivel, por sus principales aplicaciones, etc. Además, estas visiones están condicionadas por la evolución histórica por la que ha transcurrido el lenguaje.

Los primeros lenguajes de programación -lenguajes de maquina y ensambladorreciben el nombre de lenguajes de bajo nivel, debido a que los programadores que codifican en estos lenguajes deben escribir instrucciones con el nivel más fino de detalle. Cada línea de código corresponde a una sola acción del sistema computacional. El lenguaje de maquina, el cual consta de cadenas de bits 0 y 1 es la "lengua parlante" de la computadora.

El mecanismo de escoger nombres descriptivos para las celdas de memoria y usar nombres

mnemónicos

para representar

códigos

de

operación,

aumentó

considerablemente la comprensibilidad de las secuencias de instrucciones de máquina.

Cuando se introdujeron estas técnicas, los programadores usaban esta notación al diseñar los programas en papel, y luego la traducían a una forma que pudiera entender la máquina. Este proceso de traducción es suficientemente sencillo como

9

para que la propia computadora lo pueda llevar a cabo, lo que dio lugar a que el uso de nombres mnemónicos se formalizara para dar origen a un lenguaje de programación denominado "lenguaje ensamblador", y a un programa, también llamado "ensamblador" que traducía otros programas escritos en lenguaje ensamblador a lenguaje de máquina.

Figura 1.3 Ensamblador, Compilador e Interprete

Los lenguajes ensambladores representaron un gran avance en la búsqueda de mejores ambientes de programación. Por ello, se les denominó lenguajes de segunda generación, siendo la primera generación la de los propios lenguajes de máquina.

Aunque los lenguajes de segunda generación tenían muchas ventajas respecto a su contrapartida de lenguajes de máquina, todavía dejaban mucho que desear en cuanto a ofrecer el entorno de programación definitivo. Después de todo, las primitivas empleadas en los lenguajes ensambladores eran esencialmente las mismas que las del lenguaje de máquina correspondiente; la única diferencia era la sintaxis de su representación. 10

Una consecuencia importante de esta íntima asociación entre los lenguajes ensamblador y de máquina es que cualquier programa escrito en lenguaje ensamblador depende inherentemente de la máquina; esto es, las instrucciones del programa se expresan en términos de los atributos de una máquina específica. Por tanto, un programa escrito en lenguaje ensamblador no se puede transportar fácilmente a otra máquina porque se tiene que reescribir de modo que se ajuste a la configuración de registros y al conjunto de instrucciones de la nueva máquina, ya que cada tipo de microprocesador tiene su propio lenguaje ensamblador asociado (entendiendo que el lenguaje Ensamblador es simplemente una representación simbólica del lenguaje máquina). Por tanto, es necesario un profundo conocimiento de la arquitectura de la computadora para poder realizar una programación efectiva.

Otra desventaja de los lenguajes ensambladores es que el programador, aunque no tiene que codificar las instrucciones en forma de patrones de bits, sí está obligado a pensar en términos de los pequeños pasos incrementales del lenguaje de la máquina, y no puede concentrarse en la solución global de la tarea por realizar.

Las primitivas elementales en que se debe expresar finalmente un producto no son necesariamente las primitivas que deben usarse al diseñarlo. El proceso de diseño se presta mejor al empleo de primitivas de alto nivel, cada una de las cuales representa un concepto asociado a una característica importante del producto. Una vez terminado el diseño, se podrán traducir esas primitivas a conceptos de más bajo nivel relacionados con los detalles de la implantación.

De acuerdo con esta filosofía se empezaron a crear lenguajes de programación que fueran más propicios para la elaboración de software que los lenguajes ensambladores de bajo nivel. El resultado fue la aparición de una tercera generación de lenguajes de programación que difería de las anteriores en que sus

11

primitivas eran de alto nivel y además independientes de las máquinas.

En general, la estrategia para crear lenguajes de programación de tercera generación fue identificar una colección de primitivas de alto nivel con las que se podía crear software. Todas estas primitivas se diseñaron de modo que se pudieran implantar como una secuencia de las primitivas de bajo nivel disponibles en los lenguajes de máquina.

Una vez identificado este conjunto de primitivas de alto nivel, se escribió un programa llamado traductor, que traducía a lenguaje de máquina los programas expresados en dichas primitivas de alto nivel. Todo lo que tenía que hacer el traductor era reconocer las primitivas y convertirlas en sus equivalentes en lenguaje de máquina.

I.2.3 Clasificación de los Lenguajes de Programación Surgen así, los "lenguajes declarativos" que son más parecidos al inglés en la forma en que se expresan y en su funcionalidad, y están al nivel más alto respecto a los otros. Son fundamentalmente lenguajes de órdenes, dominados por sentencias que expresan "lo que hay que hacer" en vez de "como hacerlo". Un ejemplo de estos lenguajes es el lenguaje estadístico SPSS, y el lenguaje de consulta estructurada en bases de datos (SQL). Estos lenguajes se desarrollaron con la idea de que los profesionistas pudieran asimilar más rápidamente el lenguaje y usarlo en su trabajo, sin necesidad de conocimientos prácticos de programación.

Los lenguajes de "alto nivel" son los más utilizados como lenguajes de programación. Aunque no son fundamentalmente declarativos, estos lenguajes permiten que los algoritmos se expresen en un nivel y estilo de escritura fácilmente legible y comprensible por otros programadores. Además, los lenguajes de alto nivel tienen normalmente la característica de "transportabilidad". Es decir,

12

están implementados sobre varias máquinas, de forma que un programa puede ser fácilmente "transportado" o transferido de una maquina a otra sin ninguna revisión sustancial. Es este sentido, se les denomina "independientes de la máquina".

Ejemplos de estos lenguajes de alto nivel son Pascal, APL, FORTRAN, (para aplicaciones científicas), COBOL (usado en aplicaciones de procesamiento de datos), LISP y PROLOG (para aplicaciones de inteligencia artificial) C y Ada (para aplicaciones de programación de sistemas). Aunque existen actualmente en uso mas de 100 lenguajes de este tipo y muchos de ellos se encuentran en varias versiones.

Figura 1.4 Niveles de los lenguajes de programación

Los lenguajes de muy alto nivel, que aparecieron por primera vez en la década de 1960, se crearon para cubrir necesidades especializadas del usuario. Con ellos, solo se necesita prescribir lo que la computadora hará en vez de como hacerlo. Este tipo de recurso facilita mucho la programación. De este modo, los lenguajes 13

de alto y bajo nivel a veces se conocen como lenguajes procedurales, debido a que requieren que las personas escriban procedimientos detallados que indiquen a la computadora como realizar tareas individuales. Los lenguajes de muy alto nivel, en contraste reciben el nombre de lenguajes no procedurales.

Los lenguajes de muy alto nivel presentan algunas desventajas graves: carecen de flexibilidad; generalmente, cada uno está diseñado para un tipo específico de tarea. No se puede, por ejemplo,

procesar una nómina con un lenguaje de

procesamiento de palabras. Debido a que se enfocan a aplicaciones específicas, los lenguajes de muy alto nivel a veces se conocen como lenguajes dependientes del problema. Una segunda desventaja principal es que hay muchas aplicaciones importantes que no son cubiertas por estos lenguajes. No obstante, en las áreas para las cuales se encuentran disponibles, ofrecen obvias ventajas, tanto a los programadores como a los usuarios.

I.2.4 El proceso de la programación Originalmente, el proceso de programación se realizaba por el laborioso método de expresar todos los algoritmos en el lenguaje de máquina. El primer paso dado para eliminar estas complejidades fue acabar con el empleo de dígitos numéricos para representar códigos de operación y operandos del lenguaje de máquina. Así se extendió la costumbre de asignar nombres mnemónicos a los diversos códigos de operación y usarlos en vez de la representación hexadecimal durante el proceso de diseño. Por ejemplo, en vez del código de operación para cargar un registro, el programador usaría el nombre LDA (Cargar valor en el registro acumulador). En el caso de los operandos, se diseñaron reglas para que el programador pudiera asignar nombres (llamados identificadores) a posiciones de memoria y usar tales nombres en una instrucción en vez de las direcciones de memoria.

14

Se podría considerar la programación como el conjunto de actividades y operaciones tendientes a indicar a la computadora como debe realizar las funciones previstas en el algoritmo. El proceso completo se enlista a continuación. 1. Detectar o definir un problema 2. Diseñar un Algoritmo de Solución 3. Escribir un programa 4. Ejecutar el programa 5. Validar resultados 6. Depurar el programa Volver a (4) Figura 1.5 Proceso de programación

Este proceso no ha cambiado a lo largo del tiempo ni con la evolución de los lenguajes de programación. En todo caso, cada nueva generación (lenguaje) ha ido haciendo más fácil y / o eficiente, una o mas etapas de este proceso.

I.3 Tipos de Sistemas de Cómputo Un sistema es una colección de elementos y procedimientos que interactúan para cumplir una meta. Un partido de fútbol, por ejemplo, se juega conforme a un sistema. Consta de una colección de elementos

-dos equipos, un campo de

juego, árbitros- y procedimientos -las reglas del juego- que interactúan para determinar qué equipo es el ganador. Un sistema de tránsito es una colección de personas, máquinas, reglas de trabajo, tarifas y programas que llevan a las personas de un lugar a otro. Y un sistema computacional es una colección de personas, hardware, software, datos y procedimientos que interactúan con el objeto de realizar tareas de procesamiento de datos.

La función de un sistema, ya sea manual o computarizado, es mantener a la organización bien administrada y funcionando sin altibajos. Los sistemas se crean 15

y modifican en respuesta a las necesidades cambiantes de una organización y a las condiciones en transformación del medio que la rodea. Cuando surgen conflictos en un sistema existente o se necesita un nuevo sistema, el desarrollo de sistemas entra en acción. El desarrollo de sistemas es un proceso que en forma muy general consta del análisis de un sistema, el diseño de uno nuevo o las modificaciones a uno ya existente, la adquisición del hardware y software necesarios y hacer que un sistema nuevo o modificado trabaje.

I.3.1 Aplicaciones Monolíticas Los procesos contables sirvieron de punto de entrada a los primeros proyectos informáticos. Paulatinamente los sistemas asimilaron una mayor cantidad de responsabilidades convirtiéndose así en grandes aplicaciones monolíticas, bloques de software cimentados sobre otros bloques. En esta arquitectura, toda la "inteligencia" del sistema esta concentrada en una computadora central (host) y los usuarios interactúan con ella a través de terminales que reciben las instrucciones por medio de un teclado y las envían al host. Esta interacción no esta limitada a cierto hardware, ya que los usuarios pueden conectarse usando PCs o terminales de trabajo de Unix, etc. Una limitación de esta arquitectura es que rara vez soporta interfaces gráficas, o puede acceder a múltiples bases de datos.

I.3.2 Modelo Cliente / Servidor Debido a la complejidad que pueden alcanzar las redes de computadoras, estas se organizan en una serie de capas o niveles, cada una construida sobre la inferior [Tanembaum, 1997]. La Arquitectura de la red indica el número de capas, su nombre, contenido y función, sin embargo, en todas las arquitecturas el propósito de cada capa es ofrecer servicios a las capas superiores, estableciendo una conversación con las capas similares de otros equipos.

16

Las reglas y convenciones que se siguen en estas conversaciones se conocen como protocolos de comunicación entre capas. Y el conjunto de capas y protocolos se conoce como arquitectura de red.

La arquitectura "peer to peer" se refiere a un tipo de red en la que cada estación de trabajo tiene capacidades y responsabilidades equivalentes, por lo que es económica y fácil de implementar, aunque cuando esta sometida a grandes cargas de trabajo no ofrece el desempeño de otras arquitecturas.

El termino cliente / servidor fue usado por vez primera en la década de los 80 para referirse a las computadoras personales (PC) conectadas a una red. El modelo Cliente / Servidor como se concibe actualmente empezó a ganar aceptación a finales de esa misma década. En este modelo, un cliente es un ente que solicita servicios o recursos, mientras que el servidor es el ente que los ofrece. Estos entes pueden ser computadoras o procesos en una red. Los servicios ofrecidos pueden ser archivos, dispositivos e incluso procesamiento de instrucciones.

Figura 1.6 Comunicación Cliente / Servidor

17

El rol del proceso servidor puede ser asumido por el mismo sistema operativo, por un equipo despachando archivos en una red e incluso por otra computadora de las mismas características físicas que el cliente pero con la habilidad de ofrecer un servicio del que aquel carece. [Sadoski, 1997]

Desde el punto de vista de la programación, se considera a la arquitectura cliente / servidor como la extensión lógica de la programación modular.

La programación modular se basa en el hecho de que al separar una pieza de software grande en partes más simples, crea la posibilidad de que se faciliten el desarrollo y mantenimiento del todo. La arquitectura cliente / servidor va mas adelante reconociendo que estos módulos no requieren ejecutarse dentro del mismo espacio de memoria. La continuación de este concepto es que los clientes y servidores se ejecuten en las plataformas de hardware y software que resulten más apropiadas para el desempeño de sus funciones. Los programas servidores normalmente reciben las solicitudes de los programas clientes, ejecutan algún tipo de manipulación con los datos (recuperar datos de una Base de Datos, efectuar algún cálculo, implementar alguna regla de negocio, etc.), y envían la respuesta apropiada al cliente.

18

Figura 1.7 Clientes y servidores en Internet

En el modelo cliente / servidor, el procesamiento de la computadora se divide entre los "clientes" de una red y los "servidores", con cada función asignada a la máquina con más capacidad para llevarla a cabo (la parte del cliente en una aplicación corre en

el sistema de los clientes, y la parte de la aplicación

correspondiente al servidor, en la o las computadoras servidores). El usuario generalmente interactúa solo con la porción del cliente de la aplicación, que en general consiste en la interfaz de usuario, el proceso de captura de datos, la consulta a la base de datos y la obtención de informes. El servidor realiza las funciones de fondo, no visibles por los usuarios, como la administración de los dispositivos periféricos o el control del acceso a las bases de datos compartidas.

La división exacta de las tareas depende de los requerimientos de las aplicaciones, requerimientos de procesamiento, número de usuarios y recursos disponibles. Entre las tareas del cliente pueden incluirse la obtención de las entradas del usuario, hacer solicitudes de datos a los servidores, realizar cálculos en datos locales y desplegar resultados. La parte del servidor capturará o procesará los datos.

19

En resumen, las características básicas de la arquitectura son:

•

La combinación de un cliente o front-end que interactúa con el usuario, y un servidor o back-end que interactúa con un recurso compartido. El proceso cliente contiene la lógica específica de la solución y ofrece una interfaz entre el usuario y el resto del sistema, mientras que el proceso servidor actúa como el motor de software que administra los recursos compartidos (bases da datos, impresoras, módems, etc.).

•

Los procesos front-end y back-end ocupan recursos fundamentalmente diferentes (espacio en disco, velocidad del procesador, dispositivos de entrada / salida, etc.). El sistema operativo también puede ser diferente.

•

Típicamente se trata de ambientes heterogéneos, conformados por computadoras de diferentes marcas. El cliente y el servidor se comunican a través de una conjunto bien definido de interfaces de programas aplicación (APIs, por sus siglas en ingles) o de llamadas a Procedimientos Remotos (RPCs).

•

Una característica muy importante de estos sistemas es su escalabilidad. Ya que pueden ser escalados tanto horizontalmente (añadiendo o quitando clientes), como verticalmente (migrando los servicios a equipos más potentes) con un impacto mínimo en su desempeño general.

El modelo cliente / servidor requiere que los programas de aplicaciones sean escritos como dos componentes separados de software que corren en distintas máquinas pero que operan como una sola aplicación.

20

I.3.3 Sistemas Distribuidos Los sistemas distribuidos surgen en 1993, y se basan en el uso de modelos de negocio compartidos y reusables. El negocio se define entonces como un sistema compuesto a su vez de otros subsistemas de negocio. Una vez más, se trata de una extensión del modelo cliente / servidor en donde los equipos que ofrecen servicios se pueden encontrar separados unos de otros.

Figura 1.8 Sistemas Distribuidos

El funcionamiento de Internet esta basado en este concepto, ya que básicamente, se puede considerar al Web como un sistema distribuido de hipermedia [Wilde, 1999] en el que la información se encuentra almacenada en forma de páginas Web, que se encuentran entrelazadas unas con otras mediante ligas URL. Existen programas cliente, llamados navegadores, y programas servidores localizados en diferentes lugares geográficos. El programa servidor se ejecuta en un host de Internet, y responde a las solicitudes de información que le hacen los clientes. Cuando recibe una solicitud, el servidor debe responderla en forma simple, dejando al cliente o navegador, la responsabilidad de determinar la forma apropiada en que esta información debe ser mostrada al usuario. Este mecanismo de trabajo facilita que en los servidores se pueda mantener almacenada información en formatos muy diferentes. 21

El navegador es entonces un programa que se usa para tener acceso a los servidores de Web y que despliega los documentos recuperados de esos servidores. Desde el punto de vista de la tecnología cliente-servidor, un navegador es el cliente del servidor de Web.

I.3.4 Cómputo Móvil Actualmente, la comunicación de datos, esto es, el intercambio de información (archivos, faxes, correo electrónico, acceso a Internet) se realiza usando redes de telecomunicación ya existentes. Los sistemas de comunicación móvil con voz (teléfonos celulares, radios de onda corta, etc.) están ampliamente establecidos en todo el mundo y en los últimos años ha habido un rápido crecimiento en el número de suscriptores de las diferentes redes de telefonía celular. Una extensión de esta tecnología es la habilidad de enviar y recibir datos a través de estas redes celulares, siendo este el principio básico del Cómputo Móvil.

La tecnología de intercambio de datos a través de comunicación móvil se a convertido en una rama importante de la industria, evolucionando rápidamente y permitiendo hoy en día que sus usuarios puedan transmitir y recibir datos desde lugares remotos, a través de dispositivos como teléfonos celulares y módems conectados a laptops y agendas electrónicas.

22

Figura 1.9 Cómputo Móvil

El cómputo móvil permite sincronizar y controlar procesos y eventos donde el acceso a datos e información es prácticamente imposible por otros medios. Algunos ejemplos de aplicación del cómputo móvil son: •

Acceso a expedientes clínicos en línea en casos de emergencia.

•

Envío de fotografías de siniestros desde el lugar del accidente para su análisis, interpretación y devolución (ajustadores de seguros).

•

Monitoreo y diagnóstico especializado de máquinas para su mantenimiento y reparación en el campo (por ejemplo bombas de agua, de gas, de aceite).

•

Acceso a planos y datos para la administración de servicios públicos (drenajes, energía eléctrica).

•

Monitoreo de descargas de aguas residuales.

El cómputo móvil facilita los servicios de venta, facturación, cobranza y calidad en el servicio obteniendo y proporcionando datos e información en el lugar y en el momento donde se realiza la operación. Por ejemplo, proporcionando información 23

sobre productos almacenados o en producción, informando sobre el status o localización de un pedido ya realizado o informando sobre el estado crediticio de un cliente, confirmando cantidades y materiales recibidos por el cliente y optimizando transacciones de venta y producción, capturando los datos del cliente y llevándolos directamente a los almacenes de envío o áreas de producción.

Figura 1.10 Flujos de Información en cómputo móvil.

En otros países, el cómputo móvil ha resultado de mucha utilidad en eventos especiales de conteo o levantamiento de encuestas: Aplicando encuestas sobre preferencias o evaluando algún producto o servicio, contando periódicamente artículos de venta en estantes especializados y enviando esta información a centros de logística (periódicos, revistas).

A través del uso de circuitos integrados (microlocalizadores) y ayuda satelital es posible rastrear productos, unidades móviles o bien personas, permitiendo replantear rutas de servicio o transporte en casos de emergencia (accidentes, robos), proponer mejores rutas de acceso, localizar unidades para el control de paradas y consumo de combustible, dar seguimiento a unidades de transporte bancario.

24

I.3.5 Comentarios Finales Como se mencionó al principio del capítulo, una aplicación puede constituir en si misma un sistema, pero también puede ser que la aplicación móvil sea parte de un sistema de información más grande. Esto se aplica también para las aplicaciones en cómputo móvil: los datos almacenados en el dispositivo móvil pueden ser procesados por este mismo, o ser enviados a otro (normalmente un equipo fijo, mas grande) para su procesamiento.

Este trabajo pretende explorar las capacidades que tienen los dispositivos PDA para recopilar y procesar información, además de delinear una metodología que facilite el desarrollo de aplicaciones para estos.

25

CAPITULO II DESARROLLO DE APLICACIONES PARA ASISTENTES PERSONALES DIGITALIZADOS

II.1 Introducción a las PDAs Antes de hablar sobre el desarrollo de aplicaciones para Asistentes Personales Digitalizados (PDAs) por sus siglas en ingles, se mencionarán algunas características de estos. Se hará una mención especial de las características de las aplicaciones de la marca Palm, que actualmente, según su fabricante, son las más ampliamente difundidas.

Figura 2.1 Palm m505

El término PDA define a "cualquier dispositivo móvil, que pueda ser operado con una mano, y que tenga la capacidad de almacenar y procesar información para uso personal o de negocio, así como administrar la agenda y el directorio telefónico”. El término handheld se usa como sinónimo de PDA.

Algunas PDAs tienen un pequeño teclado, otras más tienen una área de la pantalla capaz de detectar trazos y reconocer escritura; algunas incluso poseen la capacidad de reconocer voz.

27

Figura 2.2 Palm IIIe

Además de los usos descritos, se han desarrollado muchas aplicaciones para PDAs y recientemente, se les empieza a combinar con teléfonos y sistemas de radio localización.".

La compañía pionera en el desarrollo de PDAs fue Apple, quien introdujo al mercado su computadora Newton en 1993.

Según la página oficial de Palm (www.palm.com): "los modelos de esta compañía constituyen el 78% del mercado actual de PDAs, y su éxito se basa en el hecho de que, mas que tratar de hacer que sus dispositivos se comporten como Computadoras Personales, han tratado de hacer algo mejor, basados en cuatro preceptos básicos: sus dispositivos son simples, expandibles , de alta usabilidad y movilidad". Esta filosofía de diseño, esta siendo apoyada por más de 145,000 desarrolladores alrededor del mundo.

II.2 Arquitectura de Hardware de la plataforma Palm Hasta los modelos de la serie M50X, absolutamente todos los modelos de Palm, usan un procesador de Motorola llamado Dragonball, y específicamente algunos modelos emplean variantes del Dragonball como son el EZ o el VZ.

28

Figura 2.3 El procesador Dragonball

El Dragonball fue ideado como una versión de bajo consumo de Motorola MC68000, que ya usaban a finales de los 80s computadoras como la Amiga o el Atari. Existen tres variantes de este procesador: el modelo base, denominado DB (Dragonball), el EZ que se caracteriza por tener un diseño más simple, menor tamaño, menor costo y nuevas características como son un controlador de LCD mejorado, nuevo hardware de control de sonido y diferentes puertos de E / S.

Por último, el modelo VZ, que aporta una mayor velocidad de proceso (hasta 33 MHz) y menor consumo de energía, entre otras características.

En estos dispositivos, que a diferencia de las computadoras de escritorio, no cuentan con un medio de almacenamiento secundario (discos flexibles o discos duros, etc.), la memoria cobra un papel importante, por que todos los programas y datos están almacenados en memoria y se requiere un rápido acceso a estos.

29

La memoria RAM empleada en estos dispositivos es rápida y no volátil, gracias a una alimentación continua de corriente, incluso cuando el dispositivo está apagado.

Los modelos de Palm incluyen dos tipos de memoria, la memoria ROM donde se aloja el sistema operativo y la memoria RAM donde residen los programas de usuario y sus datos. El tamaño de las ROM habitualmente es de 2 MB, mientras que el tamaño de RAM es variable, pudiendo oscilar entre los 128 KB (del modelo Pilot 1000) hasta los 16 MB de los modelos más recientes. Desde el punto de vista del programador, la memoria que se puede solicitar al sistema (Dynamic Heap) es mucho menor, varia entre 32 KB y 256 KB.

A partir de los modelos Palm III y Palm IIIe, los dispositivos están equipados con memoria flash ROM que permite actualizar el sistema operativo.

También existen tarjetas de memoria que permiten aumentar la capacidad de almacenamiento de los dispositivos. Por ejemplo, hay tarjetas CompactFlash para dispositivos como el TRGpro de HandEra que permiten almacenar 40MB adicionales.

Sony por su parte comercializa otro dispositivo de expansión de memoria conocido como MemoryStick que permite almacenar hasta 128MB de información. Sin embargo este tipo de memoria es más lento que la memoria RAM incluida en los dispositivos.

Las dos formas que tiene un usuario de interactuar con el Palm son: •a través del digitalizador de escritura y •a través de la pantalla.

30

El digitalizador de escritura no es como tal una parte del hardware. En esencia, es un software que, haciendo uso de redes neuronales reconoce los caracteres que escribimos sobre la pantalla táctil.

Comúnmente la pantalla de cristal líquido tiene unas dimensiones de 160 x 160 píxeles (los modelos recientes ofrecen resoluciones mayores). La frecuencia de actualización de la pantalla es, en la mayoría de los casos, de 85 Hz. Las pantallas pueden manipular colores desde cuatro tonos de gris (en los equipos que emplean el Palm OS 3.0 o superior), hasta 65536 colores, usando 16 bits de profundidad de color.

En todos los modelos la pantalla es táctil, para permitir la interacción con el usuario, y además, algunos de ellos permiten iluminar la pantalla para trabajar en lugares con poca luz. Cabe destacar que, aunque el método principal de introducción de datos es el digitalizador de escritura, también es posible hacerlo a través de un teclado en pantalla.

Las posibilidades de conexión ya sea entre Palms o con otros dispositivos, es una parte muy importante de estos, ya que permitirán compartir información, de modo que no se conviertan en una plataforma aislada.

El Palm tiene 2 formas de interconectarse con otros dispositivos; mediante comunicaciones por infrarrojo (IrDA), o mediante comunicaciones serie.

El sistema IrDA permite comunicarse y compartir información con cualquier dispositivo que soporte este protocolo, como por ejemplo, un teléfono móvil, una impresora u otros dispositivos Palm. Para realizar una comunicación mediante IrDA, los dispositivos que se van a comunicar deben estar situados a una distancia máxima de un metro y sin obstáculos en medio.

31

El puerto serie permite conectarse tanto con la PC como con otros dispositivos. La comunicación serie esta completamente basada en interrupciones para la transmisión de datos. Se utilizan cinco señales externas para soportar esta comunicación: SG (signal ground) TxD (transmit data) RxD (receive data) CTS (clear to send) RTS (request to send)

La PDA se comunica con la PC a través de la base (cradle). La base es una interfaz entre el PC y el Palm. Se trata de un soporte de plástico cuyas funciones son: recargar las baterías del Palm (cuando el modelo lo permite) y sincronizar los datos del Palm con la PC mediante la pulsación de un botón.

La sincronización a través de la base se realiza usando el puerto serie, pero los modelos recientes de Palm incluyen un puerto de infrarrojos y soporte para el protocolo de comunicaciones TCP/IP (empleado por ejemplo por los navegadores web) .

Recientemente, Palm a incorporado el estándar Bluetooth en todos sus dispositivos.

II.3 Arquitectura del Sistema Operativo Palm Palm OS es un sistema operativo diseñado específicamente para su utilización en PDAs, comercializado por la empresa Palm Computing. Este sistema operativo presenta características específicas debido a las restricciones de los dispositivos que lo emplean. Estas restricciones son esencialmente tres: tamaño del dispositivo, memoria y capacidad de procesamiento de datos. 32

Figura 2.4 Arquitectura del PalmOS

Como se muestra en la figura anterior (Figura 2.4) el sistema operativo da soporte, desde los servicios y librerías del sistema hasta la capa de abstracción del hardware.

A continuación se describen los elementos mas relevantes del sistema operativo, desde el punto de vista del programador.

Eventos: Los eventos informan a la aplicación de qué es lo qué está ocurriendo en el sistema, desde una pulsación de un botón de un teclado externo, hasta el inicio de una operación de sincronización. Se pueden distinguir eventos de alto nivel y de bajo nivel. Los de alto nivel son los relacionados con la aplicación en si, por ejemplo, si se selecciona un ítem del menú. Los de bajo nivel son aquellos relacionados con el sistema operativo.

La memoria y sus limitaciones: La memoria en los Palm es un recurso muy escaso. La RAM está dividida en dos áreas, la memoria de almacenamiento 33

(sistema de archivos) y memoria dinámica (la que emplea la aplicación durante la ejecución). Cada una de estas es gestionada por una parte distinta del sistema operativo, en el primer caso el Database Manager y en el segundo por el Memory Manager.

La memoria dinámica se utiliza, tanto para las variables globales y variables reservadas por el Palm OS, como para las variables globales, espacio de stack y reservas dinámicas de la aplicación. La memoria esta dividida en tres bloques (Heap) que son el dinámico, de almacenamiento y de ROM.

Los Heaps son bloques de memoria reservados en forma contigua, estos bloques pueden estar en tres estados distintos: libres, móviles y fijos.

Controles y formularios: Un formulario es, en general, una pantalla para cada vista de la aplicación.

Los formularios contienen controles. Un control puede ser: un botón, una etiqueta, una lista, una tabla, un bitmap, un campo de texto o cualquier otro objeto definido por el usuario (Gadgets).

Los controles se almacenan como recursos de la aplicación, estos son necesarios cuando se necesita crear un elemento de interfaz de la aplicación, ya que un recurso define cual es la apariencia del elemento y donde está colocado dentro del formulario.

Menús: Los menús están asociados con un formulario, generalmente se definen en

tiempo

de

compilación,

aunque

estos

menús

pueden

cambiarse

dinámicamente. Los menús se componen de barras de menú y de opciones dentro de estos. Estas opciones del menú podrán tener asociados atajos (shortcuts). Los 34

shortcuts son letras del alfabeto que permitirán acceder rápidamente a las opciones sin desplegar el menú.

Comunicaciones: Palm OS da soporte a tres protocolos de comunicaciones IrDA, serie y TCP/IP. El sistema operativo proveerá de una serie de funciones para trabajar con estos protocolos. TCP/IP esta disponible sólo sobre el puerto serie o sobre una conexión con MODEM. Para utilizar TCP/IP se utiliza el Palm Software Development

Kit

(Herramientas

de

Desarrollo

de

Software,

distribuidas

gratuitamente por Palm), esta Interfaz de desarrollo de aplicaciones tiene una librería de sockets y esta diseñada de forma muy similar al API de sockets de Berkley.

II.4 Tipos de aplicaciones El PalmOS almacena tanto datos como programas en forma de bases de datos. En general, se pueden desarrollar tres tipos de aplicaciones para la plataforma Palm.

II.4.1 Aplicaciones Web reducidas Una aplicación Web en un Palm es un conjunto de paginas HTML comprimidas en un formato especial (PQA). El funcionamiento de una aplicación de Web reducida es el siguiente: las páginas Web comprimidas residen el Palm y los usuarios rellenan los formularios HTML suministrados por estas paginas. Cuando el usuario pulsa el botón enviar, la aplicación Web envía la petición a un servidor proxy. Este servidor la traduce en una petición HTTP, y la reenvía al servidor Web adecuado. Por norma general este servidor Web ejecuta un script CGI que genera la pagina de respuesta. Esta pagina es reenviada de nuevo al proxy que la comprime y la descarga al dispositivo para que pueda presentarse.

Estas

paginas

HTML

comprimidas

deben

ser

compactas

y

pequeñas,

considerando que se van a mostrar en la pequeña pantalla de la Palm. También 35

hay que tener en cuenta que se descargan a través de una conexión relativamente lenta.

Figura 2.5 Ejecución de una aplicación web reducida.

La ejecución de estas páginas web se realiza mediante el visor de aplicaciones web. Cuando el usuario pulsa el icono de una aplicación web, se lanzará primero el visor y este mostrará el contenido de la pagina web.

36

Figura 2.6 Otra vista de una aplicación web reducida

II.4.2 Aplicaciones estándar de Palm Se definen como aplicaciones con un sólo hilo de control, dirigidas a eventos y mono-tarea. Esto implica que sólo habrá una aplicación en ejecución en un instante de tiempo dado. En general, los usuarios "navegan" entre las diferentes aplicaciones, en lugar de salir o terminar aplicaciones como en una PC.

Figura 2.7 Calculadora

Por otro lado, aunque las aplicaciones Palm están dirigidas a eventos, también pueden realizar funciones fuera del ciclo de eventos, como respuesta a otras peticiones del sistema operativo. Por ejemplo, si se realiza la búsqueda de una 37

palabra, se intentará encontrar en todos los registros de todas las aplicaciones esa palabra. Esto implica que se lanzará cada una de las aplicaciones y se le pedirá que verifique sus registros para ver si contiene esa palabra.

Figura 2.8 Juego pBill para Palm

Las aplicaciones Palm OS se compilan en archivos PRC (Palm Resource File). Un mismo fichero PRC correrá en todos los dispositivos Palm OS.

Figura 2.9 Reloj

II.4.3 Conduits Un conduit es un programa que se ejecuta en la PC, cuando se presiona el botón de sincronización en la base (cradle) de la Palm. Su función es la de realizar la sincronización de los datos entre aplicaciones de la PC y aplicaciones en la Palm.

Este tipo de aplicaciones sólo se desarrolla cuando se debe realizar una traducción del formato de los datos. Existe un kit de desarrollo especial para estas aplicaciones: Palm Conduit Development Kit (CDK), además de las soluciones ofrecidas por terceros. 38

Figura 2.10 Conduit de sincronización diaria de Palm

II.5 Estructura de una aplicación Palm. Como menciona [Forester, 2000] la programación de aplicaciones para Palm OS está orientada a eventos. Estos eventos pueden ser producidos por el usuario (por ejemplo al escribir sobre la pantalla) por el sistema operativo o por la aplicación misma, y son almacenados en la cola de eventos del sistema operativo. Estos son procesados según el método FIFO (First In First Out: el primer evento que entra es el primero que se procesa).

Es responsabilidad del programador decidir para que eventos se programará una respuesta específica, dejando el control del resto al Sistema Operativo.

Cuando el sistema operativo lanza una aplicación, invoca a la función PilotMain y le pasa como parámetro un código que indica a la aplicación la forma en que debe arrancar; si señala que la aplicación debe arrancar y mostrar su interfaz de usuario, se denomina un arranque normal.

Pero este código puede indicar a la aplicación que debe arrancar, realizar alguna tarea pequeña y luego terminar (como cuando se usa la función global de "encontrar", que busca una cadena de caracteres en las bases de datos de todas las aplicaciones). Existen códigos de arranque para muchos propósitos, como 39

abrir una base de datos en un registro predeterminado, notificar a la aplicación que se acaba de realizar una sincronización exitosa, etc.

Además, existe una estructura de datos que describe el tipo de evento que esta ocurriendo en un momento dado [Ibid.]. En esta estructura se almacena el tipo de evento que esta ocurriendo (por ejemplo, presionar con el lápiz algún botón) así como la información relativa a ese evento (por ejemplo, las coordenadas en las que el lápiz tocó la pantalla).

Si se realizó un arranque normal, la función PilotMain invoca a StartApplication (en esta función se recomienda inicializar las bases de datos y obtener del sistema operativo las preferencias del usuario), enseguida, llama

a

la

función

FrmGotoForm, quien se encarga de cargar y mostrar la forma indicada.

Después la ejecución pasa a la función EventLoop, quien es la responsable de procesar todos los eventos recibidos por la aplicación.

Cada nuevo evento se acomoda al final de la cola de eventos, de donde la función EventLoop los va tomando y procesando, en el siguiente orden:

Eventos del sistema Eventos de la barra de menú. Eventos que carguen en memoria una nueva forma Eventos específicos de la forma que se encuentra activa.

Este

proceso se repite mientras existan eventos pendientes en la cola. Y la

función termina cuando recibe un appStopEvent. En este momento, regresa la ejecución a PilotMain.

40

Finalmente, la función StopApplication cierra las bases de datos, indica al sistema operativo que almacene las preferencias del usuario y realiza todas las tareas necesarias para que la aplicación termine en forma correcta.

El siguiente diagrama muestra el orden en que son llamadas las principales funciones de cualquier aplicación Palm:

Figura 2.11 Secuencia de llamadas de Funciones

La función denominada en el diagrama como PersonalHandleEvent es la encargada de procesar los eventos generados por el usuario en la forma activa. Así, si el usuario posiciona el apuntador sobre un campo de texto, o si presiona un botón, o mueve la barra de desplazamiento de una tabla, en esta función se debe codificar la respuesta a esos eventos.

II.5.1 Como se genera un ejecutable Desarrollar

aplicaciones

para

los

Asistentes

Personales

Digitalizados,

independientemente de la marca que los construya, conlleva tomar en cuenta algunas cuestiones, empezando por que la programación puede desarrollarse en C o C++ (o varios otros lenguajes para los que existen compiladores que generan código que se puede ejecutar en PDAs), sin olvidar que, como se ha citado 41

anteriormente, una aplicación para Palm es simplemente una base de datos que contiene por una parte el código ejecutable y por otra los elementos gráficos y demás datos.

En el caso específico de la programación para dispositivos Palm, se deben generar archivos de "recursos" que describen la interfaz con el usuario y su funcionamiento. Normalmente, estos archivos se obtienen usando un programa independiente del compilador o del ambiente de desarrollo integrado.

Los archivos de recursos contienen la jerarquía de objetos de la interfaz gráfica, empezando por la 'forma' (similar a la 'ventana' cuando se desarrolla para Windows) a la que se le van añadiendo otros objetos como barras de menú (a las que a su vez se les añaden menús), botones, campos de texto, tablas, etc. En este archivo se deben inducir también los mapas de bits (bitmaps) que se van a usar en la aplicación.

El resto del proceso de desarrollo consiste en codificar la respuesta a los eventos que le pueden ocurrir a los diferentes objetos de la forma.

Una vez que se ha generado un programa, se procede a compilarlo, depurarlo, corrigiendo los eventuales errores y repitiendo esta ultima parte del proceso hasta que se obtiene un programa libre de errores.

En esta etapa, es poco conveniente probar los programas en dispositivos reales, por que existen errores que pueden incluso, provocar la pérdida total de la información almacenada en la Palm. Por esto último, se recomienda probar la aplicación en un programa, llamado PalmOS Emulator, que se ejecuta en la PC y simula totalmente la funcionalidad de una Palm (1).

42

Cuando se han eliminado todos los errores, y el programa se ejecuta sin problemas en el emulador, esta listo para instalarse en un dispositivo real.

Codigo Maquina

0 1 0 1 1

Loader

Mnemonicos Ensamblador mov AX,0 llda BX

Ensamblador

Ligador

Memoria Compilador Lenguaje de

Lenguajes de

Alto

Programación

Nivel

(P.E. Pascal)

Interprete

Figura 2.12 Niveles de programación

II.5.2 Common Object File Format II.5.2.1 Archivo Objeto Como se explica en [PCWebopaedia, 2003] cuando se programa, se escribe código en forma de código fuente: instrucciones de algún lenguaje particular, como C o Fortran. Sin embargo las computadoras sólo pueden ejecutar instrucciones escritas en lenguaje de máquina. Para pasar de código fuente a lenguaje de máquina, los programas deben ser transformados por un compilador. El compilador genera un archivo intermedio con código llamado objeto. Este archivo sirve de entrada al encadenador (linker) que resuelve las llamadas que el archivo objeto hace a las librerías propias del

43

lenguaje. El termino "archivo objeto" no necesariamente implica alguna conexión con la programación orientada a objetos. Como se ha señalado, cuando un compilador procesa el código fuente (en nuestro caso, en C o C++), genera un archivo objeto, que posee un formato específico. En Windows, los compiladores generan archivos en formato PE COFF. En Linux, GCC puede generar archivo en formato ELF (u otro, dependiendo de la necesidad del programador y la configuración del ambiente de desarrollo).

Figura 2.14 Generación de un ejecutable.

II.5.2.2 COFF Debido a que un microprocesador solo ejecuta sus propias instrucciones nativas, una solución eficiente para desarrollar programas que se ejecuten en una plataforma diferente a aquella en la que se programa, consiste en crear código binario para la plataforma destino, a partir de programas fuentes (usualmente en C o C++).

44

Pero para explotar al máximo las características físicas del dispositivo destino, se requieren hacer optimizaciones adicionales. En la literatura existen técnicas de optimización de código para diferentes arquitecturas de hardware. Algunos procesadores de la familia Intel, por ejemplo, incluyen su propio coprocesador de punto flotante, mientras que en los procesadores Motorola de la familia 68000, la aritmética de punto flotante se debe hacer a través de librerías de software.

Por otro lado, como el mismo sistema operativo esta escrito (al menos en parte) con instrucciones de código nativo, es más eficiente que los programas interactúen directamente con este, y no a través de interfaces o maquinas virtuales como la maquina virtual de Java.

La mayor dificultad que se presenta cuando se desarrollan ejecutables en código nativo es, como puede observarse, que normalmente el código nativo no funciona en dos plataformas de hardware diferentes. Y aún cuando el hardware sea el mismo, pequeñas inconsistencias en la plataforma pueden ser suficientes para causar problemas.

Algunos sistemas operativos, como el PalmOS, ofrecen acceso a rutinas internas a través de las llamadas system traps. Estas son instrucciones que hacen llamadas directas a servicios del sistema operativo. Pero para tener acceso a estos servicios, la aplicación debe ligarse contra librerías de sistema ofrecidas normalmente por el desarrollador del hardware. Estas librerías tienen un formato binario particular al que el compilador le debe dar soporte. Un ejemplo de este tipo de formatos es el Common Object File Format (COFF)

Los formatos ELF y COFF son muy similares, y permiten prácticamente la misma funcionalidad. Ambos pueden usarse para especificar código objeto (de archivos generados por el compilador), y código ejecutable (archivos producidos por la herramienta de encadenado). Estos formatos contienen secciones. Las secciones 45

que se encuentran tanto en archivos objeto como ejecutables son: .text, que contiene el código binario ejecutable; .data, que contiene datos inicializados en el programa (como en una declaración "int a=7;" donde se declara un entero y se inicializa con un valor de 7); y .bss (blow stack segment), sección que almacena datos no inicializados (como cuando se declara "int arreglo[100000];". En este último caso, no se reserva espacio para la variable sino hasta cuando se el archivo esta en ejecución).

II.5.2.3 COFF y Palm En Unix, según explica la pagina del Manual de COFF, la salida de las herramientas de encadenamiento (linker) y el ensamblador (llamadas a.out por omisión) están codificadas en formato Common Object File. Un archivo de objeto común (common object file) consiste de un encabezado de archivo, un encabezado de sistema (en el caso de los archivos producidos por el linker), una tabla de encabezados de sección, una sección de datos, información de relocalización, números de línea opcionales, una tabla de símbolos y una tabla de cadenas.

II.5.2.4 PRC-Tools Las PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc". Esta herramienta tiene un doble propósito: convertir recursos de código y datos al formato que el PalmOS espera; y en general, construir programas para Palm (PRCs) a partir de colecciones de archivos de recursos separados. Las PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc". Esta herramienta tiene un doble propósito: convertir recursos de código y datos al formato que el PalmOS espera; y en general, construir programas para Palm (PRCs) a partir de colecciones de archivos de recursos separados.

46

Las PRC-Tools

producen código en formato m68k-coff, es decir, código para

procesadores de la arquitectura M68000 de Motora, usando el formato binario COFF.

Se debe señalar que en situaciones de desarrollo como la descrita, en donde se cuenta con una herramienta de post-encadenamiento, la elección de un formato binario no es significativa (mas allá de los requerimientos y restricciones de la herramienta de post-encadenamiento). La plataforma de destino nunca trabaja con el formato binario producido por el encadenador, sino que, como se muestra en la figura siguiente, el proceso de post-encadenamiento "traduce" la salida del encadenador, en un archivo ejecutable para la plataforma destino. 

    
  

↓ !"!#

$&%&
' )(* 
+,!#-
- .!/ 0
1'
"2'43

↓ 657
28 9:;3