27269939 Desarrollo de Aplicaciones Para Dispositivos Moviles Tesis de Ivan Carlos Rivera Gonzalez

5/26/2018 27269939 Desarrollo de Aplicaciones Para Dispositivos Moviles Tesis de Ivan Carlos Rivera Gonzalez

1/173

ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL

NUMERO 00922681 DE FECHA 23 DE JUNIO DE 1992

SVES. DESARROLLO DE APLICACIONES PARA

DISPOSITIVOS MVILES

TESIS

QUE PARA OBTENER EL TTULO DE

INGENIERO EN COMPUTACIN

PRESENTA:

IVN CARLOS RIVERA GONZLEZ

ASESOR: EUGENIO JACOBO HERNNDEZ VALDELAMAR

MXICO, D.F. MARZO DE 2003


2/173


3/173

RESUMEN

El inters por crear aplicaciones para Dispositivos Mviles ha aumentado en la

misma medida que estos han demostrado su funcionalidad. Adems, con el

aumento en las capacidades de procesamiento de estos dispositivos se ha abierto

todo un abanico de posibilidades de aplicacin de los mismos.

Sin embargo, cuando se considera elaborar aplicaciones para dispositos mviles,

la principal dificultad que se debe enfrentar es la eleccin de una plataforma de

desarrollo, entendida sta como una combinacin de metodologa de anlisis y

diseo de sistemas, lenguaje de programacin, sistema operativo sobre el que se

trabaja, etc.

Para enfrentar un problema como este, se debe plantear la eleccin de una

Metodologa de Anlisis y Diseo de Sistemas adecuada, muy probablementeOrientada a Objetos. Se debe hacer un Anlisis y Diseo adecuados,

considerando las limitaciones de la plataforma.

A partir de un Anlisis cuidadoso y diseando las aplicaciones considerando las

restricciones propias de un dispositivo mvil, la correcta aplicacin de la

plataforma elegida redundar en un proceso de desarrollo ms eficiente, rpido,

econmico y con aplicaciones mas robustas.

Como un ejemplo de aplicacin de este trabajo, se estudia el Sistema deVigilancia Epidemiolgica Simplificada (SVES) de la Secretara 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 podan realizar con

una computadora personal.

Considerando esto, al desarrollar un sistema para PDAs que aplique la

metodologa del SVES, una franja mas grande de la poblacin tendr acceso a

este mecanismo de atencin.

El presente trabajo demostrar que es posible aplicar una metodologa de Anlisis

y Diseo de Sistemas que considere las limitaciones de una plataforma como las

PDAs para desarrollar aplicaciones de Cmputo Mvil.


4/173

II

INDICE

INTRODUCCIN.....................................................................................................1

CAPITULO I DESARROLLO DE SISTEMAS ..........................................................4

I.1 Conceptos del Software ..................................................................................5

I.2 Lenguajes de Programacin ...........................................................................6

I.2.1 Qu es un lenguaje de programacin ...................................................6

I.2.2 Evolucin de los Lenguajes de Programacin ......................................9

I.2.3 Clasificacin de los Lenguajes de Programacin................................12

I.2.4 El proceso de la programacin............................................................14

I.3 Tipos de Sistemas de Cmputo ....................................................................15

I.3.1 Aplicaciones Monolticas.....................................................................16

I.3.2 Modelo Cliente / Servidor....................................................................16

I.3.3 Sistemas Distribuidos..........................................................................21

I.3.4 Cmputo Mvil ....................................................................................22

I.3.5 Comentarios Finales ...........................................................................25

CAPITULO II DESARROLLO DE APLICACIONES PARA ASISTENTES

PERSONALES DIGITALIZADOS ..........................................................................26

II.1 Introduccin a las PDAs...............................................................................27II.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 estndar de Palm..........................................................37

II.4.3 Conduits .............................................................................................38

II.5 Estructura de una aplicacin 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


5/173

III

II.5.2.4 PRC-Tools ............................................................................46

II.5.2.5 CodeWarrior .........................................................................48

II.5.2.6 Otros .....................................................................................48

II.6 Integracin 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 programacin tradicional .................52

II.6.2 El PalmOs Emulator (POSE).................................................................54

II.7 Caractersticas 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.......................................................................................60II.7.4 Eligiendo entre C y C++.....................................................................61

CAPITULO III OMT PARA EL ANLISIS Y DISEO DE APLICACIONES EN

ASISTENTES PERSONALES DIGITALIZADOS...................................................66

III.1 Elementos de OMT .....................................................................................67

III.1.1 Modelo de Objetos ............................................................................67

III.1.2 Modelo Dinmico ..............................................................................68

III.1.3 Modelo Funcional..............................................................................68III.1.4 Relacin entre los Modelos...............................................................69

III.2 Proceso de Anlisis y Diseo en OMT........................................................70

III.2.1 Anlisis..............................................................................................71

III.2.1.1 Casos de Uso.............................................................................74

III.2.2 Diseo ...............................................................................................75

III.2.2.1 Diseo de sistemas. ...................................................................75

III.2.2.2 Diseo de objetos.......................................................................77

III.3 Patrones de Diseo.....................................................................................79

III.3.1 Qu son los patrones ........................................................................79

III.3.1.1 Ventajas de los patrones de diseo............................................81

III.3.2 Patrn Modelo Vista Controlador ......................................................82

III.3.2.1 Modelo Vista Controlador y desarrollo para Palm.......................87


6/173

IV

III.4 Restricciones dadas por la plataforma........................................................87

III.4.1 Los distintos modelos de Palm..........................................................89

III.4.2 Caractersticas 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 diagnstico mdico. .....................................................98

IV.1.2.1 Perspectiva Histrica..................................................................99

IV.1.2.2 Sistemas Expertos ...................................................................100

IV.1.2.3 Funcionamiento de los sistemas de diagnstico medico..........101IV.1.2.4 Ejemplo ....................................................................................101

IV.2 Antecedentes del Sistema de Vigilancia Epidemiolgica..........................102

IV.3 Sistema de vigilancia epidemiolgica .......................................................105

IV.3.1 Sistemas no convencionales de Informacin..................................106

IV.3.2 Aspectos epidemiolgicos ..............................................................107

IV.4 Sistema de Vigilancia Epidemiolgica Simplificada..................................107

IV.4.1 Componentes del SVES.................................................................108IV.4.2 Padecimientos Incluidos .................................................................109

IV.5 Formatos e instructivos de registro y notificacin .....................................111

IV.5.1 Plantilla para el Diagnstico Individual de Enfermedades ..............111

IV.6 Anlisis y Diseo del Sistema...................................................................113

IV.6.1 Anlisis de la Vista..........................................................................113

IV.6.1.1 Enunciado del problema...........................................................113

IV.6.1.2 Modelo de Objetos ...................................................................113

IV.6.1.3 Identificacin 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


7/173

V

IV.6.1.8 Modelo Dinmico......................................................................126

IV.6.1.9 Modelo Funcional.....................................................................128

IV.6.1.10 Iterar.......................................................................................130

IV.6.2 Anlisis 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 Identificacin 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 Dinmico......................................................................135

IV.6.2.6 Modelo Funcional.....................................................................136IV.6.2.7 Iterar el proceso .......................................................................137

IV.7 Anlisis del Controlador............................................................................138

IV.7.1 Enunciado del problema (EP) .........................................................140

IV.7.1.1Modelo de Objetos ....................................................................140

IV.7.1.2Modelo Dinmico.......................................................................141

IV.7.1.3Modelo Funcional......................................................................142

CONCLUSIONES................................................................................................144BIBLIOGRAFA....................................................................................................152

ANEXOS..............................................................................................................159


8/173

VI

LISTA DE FIGURAS

Figura 1.1 Tipos de software ...................................................................................5

Figura 1.2 Construccin de un ejecutable ...............................................................8

Figura 1.3 Ensamblador, Compilador e Interprete.................................................10

Figura 1.4 Niveles de los lenguajes de programacin ...........................................13

Figura 1.5 Proceso de programacin.....................................................................15

Figura 1.6 Comunicacin Cliente / Servidor ..........................................................17

Figura 1.7 Clientes y servidores en Internet ..........................................................19

Figura 1.8 Sistemas Distribuidos ...........................................................................21

Figura 1.9 Cmputo Mvil......................................................................................23

Figura 1.10 Flujos de Informacin en cmputo mvil. ...........................................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 Ejecucin de una aplicacin web reducida...........................................36

Figura 2.6 Otra vista de una aplicacin web reducida ...........................................37

Figura 2.7 Calculadora ..........................................................................................37Figura 2.8 Juego pBill para Palm...........................................................................38

Figura 2.9 Reloj .....................................................................................................38

Figura 2.10 Conduit de sincronizacin diaria de Palm...........................................39

Figura 2.11 Secuencia de llamadas de Funciones ................................................41

Figura 2.12 Niveles de programacin....................................................................43

Figura 2.14 Generacin de un ejecutable..............................................................44

Figura 2.15 Generacin 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 Organizacin de la API de Palm.........................................................57

Figura 3.1 Relacin entre los modelos de OMT.....................................................69


9/173

VII

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 Direccin........................................................................116

Figura 4.8 Forma Acerca de ................................................................................117Figura 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 aplicacin:....................126

Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicacin:

.............................................................................................................................127

Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalizacin

de una aplicacin.................................................................................................128Figura 4.15 Primera versin del diagrama de clases del Modelo ........................135

Figura 4.16. Caso de Uso MD01. Usuario diagnstica un padecimiento.............135

Figura 4.17 Diagrama de Flujo de Eventos de Elaboracin de un diagnstico....136

Figura 4.18 Algoritmo para obtener un diagnstico .............................................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. Patrn Modelo Vista Controlador Adaptador......................................151


10/173

VIII

LISTA DE TABLAS

Tabla 2.1. Archivos importantes de la Interfaz de Programacin 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. Comparacin entre los modelos de Palm Inc. ......................................89

Tabla 3.3 Comparacin de modelos de Handhelds contra una PC.......................91

Tabla 3.3 Comparacin de modelos de Handhelds contra una PC (cont).............92



Tabla 4.2 Conocimiento del experto mdico, resumido en una tabla. .................102

Tabla 4.10 Propiedades de los objetos de la interfaz grfica ..............................124

Tabla C1. Comparacin de cdigo entre versiones del SVES.............................149


11/173

INTRODUCCIN


12/173

2

Hasta hace relativamente poco tiempo, en los pases en vas de desarrollo comoMxico, los avances tecnolgicos llegaban con un importante retraso respecto a

su aparicin en los pases desarrollados.

Sin embargo, hoy en da, Internet, la televisin, las telecomunicaciones, etc.

permiten que se tenga acceso a la tecnologa de forma mas o menos simultanea

en todo el mundo.

Un ejemplo de esta afirmacin es la plataforma de asistentes personales

digitalizados desarrollados por la Firma Palm Inc. cuyo ltimo dispositivo: el Palm

Tungnsten T, se present en Mxico 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 adems, en el rea de desarrollo de aplicaciones para estos dispositivos se

ha presentado un fenmeno particular: los desarrolladores de programas para

Palm estn dispersos por el mundo, y no solo en los pases ms industrializados o

econmicamente ms poderosos. Este fenmeno esta ligado al hecho de que los

detalles de la plataforma, la documentacin y las herramientas de desarrollo estn

disponibles para todo el pblico, en forma totalmente gratuita.

Con todo, la programacin de aplicaciones para dispositivos mviles es un rea de

incipiente crecimiento en Mxico. Incluso en el mundo (segn cifras de Palm Inc.)

el nmero de desarrolladores registrados es de apenas varios cientos.


13/173

3

Esto ofrece a los programadores de los pases en vas de desarrollo la

oportunidad de experimentar, de ser propositivos y no solo simples usuarios de la

tecnologa importada.

Sin pretender convertirse en la piedra angular de la programacin para

dispositivos mviles en Mxico este trabajo busca, precisamente: proponer, dar

ideas, pasar de ser usuarios a ser desarrolladores de nueva tecnologa.


14/173

CAPITULO I

DESARROLLO DE SISTEMAS


15/173

5

I.1 Conceptos del Software

A principios de los 80 no estaba claro cun importante sera el desarrollo de

software. Hoy en da, se ha convertido en el eje de evolucin de la industria de la

computacin, y es el motor que conduce la toma de decisiones comerciales. Esto

ha provocado que cambie la percepcin que el pblico tenia del software: de ser

un aditamento adicional a la computadora, a ser una plataforma de trabajo que

corre sobre un hardware no especfico.

En nuestros das el software tiene un doble papel: es un producto que permite

explotar toda la potencia del hardware informtico; ya sea almacenado dentro de

un telfono celular o dentro de una computadora bancaria, el software transforma

informacin, produciendo, gestionando, modificando, mostrando o transmitiendo

informacin, pero el software tambin sirve como vehculo para hacer entrega de

un producto, ya que acta como la base de control de la computadora, lacomunicacin de informacin, y la creacin y control de otros programas.

Figura 1.1 Tipos de software


16/173

6

Dentro del gran conjunto de programas representados por el termino "software",

se pueden hacer dos grandes divisiones, de acuerdo a la funcin que

desempean. Una formada por el llamado Software de Sistema, encargado de

apoyar al usuario en la administracin de su hardware, y la otra conformada por el

Software de Aplicacin, subconjunto que agrupa a todos los programas que

resuelven necesidades y problemas especficos de los usuarios. As, cuando un

usuario desea capturar un texto y darle formato, utilizar distintos tipos y tamaos

de letra y revisarlo ortogrficamente, tiene que recurrir a un software de aplicacin.

Igual debe hacerlo si desea capturar y manipular grandes volmenes de datos, o

hacer muchos clculos o si lo que quiere es construir imgenes y darles

animacin. Mientras que si respalda archivos o administra impresoras, estar

usando software de sistema. Aunque el trmino "Sistema" se usa tambin comosinnimo de software, y en especial en el presente documento, especficamente

del software de aplicacin.

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 algn lenguaje de programacin.

I.2 Lenguajes de Programacin

I.2.1 Qu es un lenguaje de programacin

Como se menciona en el captulo 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 semntica bien definida

junto con una sintaxis no ambigua para representarla.

Tenemos entonces, que para representar algoritmos se debe contar con una

coleccin suficientemente rica de primitivas que, junto con las reglas de


17/173

7

combinacin para representar estructuras ms complejas, constituyen un lenguaje

de programacin.

La Enciclopedia de Trminos de Microcomputacin define Lenguaje de

programacin como los conjuntos de smbolos y de reglas que se pueden

combinar en forma sistemtica para comunicar pensamientos e ideas, y

especficamente 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 ejecucin en la

computadora.

Tambin para [Joyanes, 1988] un lenguaje de programacin es un conjunto de

reglas, smbolos y palabras que permiten construir un programa. Al igual que los

lenguajes humanos tales como el ingls o el espaol, los lenguajes de

programacin poseen una estructura (gramtica o sintaxis) y un significado

(semntica).

La sintaxis es el conjunto de reglas que gobiernan la construccin o formacin de

sentencias (instrucciones) vlidas en el lenguaje. La semntica es el conjunto de

reglas que proporcionan el significado de una sentencia o instruccin del lenguaje.

El vocabulario de un lenguaje es un conjunto de smbolos. Los smbolos usuales

son: letras, dgitos, smbolos especiales (,;:/&+-*, etc.) y palabras reservadas o

claves, y las reglas sintcticas son los mtodos de produccin de sentencias o

instrucciones vlidas que permitirn formar un programa.

Segn menciona [Brookshear, op. cit.], la implantacin de los lenguajes de

programacin de alto nivel se basa en el proceso de convertir programas escritos

en esos lenguajes en programas escritos en lenguaje de mquina.


18/173

8

La traduccin de un programa consiste en tres actividades: anlisis lxico, anlisis

sintctico y generacin de cdigo

Figura 1.2 Construccin de un ejecutable

El anlisis lxico es el proceso de reconocer qu cadenas de smbolos del

programa que se ha de traducir (llamado programa fuente) representan en

realidad un solo objeto elemental. Por ejemplo, la cadena de smbolos 153 no

debe representarse como un 1 seguido de un 5 seguido de un 3, sino que debe

reconocerse como la representacin de un solo valor numrico. De manerasimilar, aunque los identificadores que aparecen en un programa estn formados

por varios caracteres, se deben interpretar colectivamente como un nombre, no

como caracteres individuales.

La segunda actividad del proceso de traduccin, el anlisis sintctico, 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 anlisis sintctico, la coleccin de estructuras de

enunciados que tiene un lenguaje de programacin es menos variada que la de un

A n l i s i s

l x i c o

A n l i s i s

s i n t c t i c o

Ge n e r a c i n

d e c d i g o

P r o g r a maF u e n t e

P r o g r a mo b j e t o


19/173

9

lenguaje natural, y est limitada a unas cuantas formas cuidadosamente

escogidas.

La actividad final en la traduccin de un programa es la generacin de cdigo, esel proceso de construir secuencias de instrucciones en lenguaje de mquina que

simulen a los enunciados reconocidos por el analizador sintctico, y es el que

genera el producto final del proceso de traduccin: el programa objeto.

I.2.2 Evolucin de los Lenguajes de Programacin

Al igual que el software, hay varias formas desde las que pueden verse o

clasificarse los lenguajes de programacin: por su nivel, por sus principalesaplicaciones, etc. Adems, estas visiones estn condicionadas por la evolucin

histrica por la que ha transcurrido el lenguaje.

Los primeros lenguajes de programacin -lenguajes de maquina y ensamblador-

reciben el nombre de lenguajes de bajo nivel, debido a que los programadores que

codifican en estos lenguajes deben escribir instrucciones con el nivel ms fino de

detalle. Cada lnea de cdigo corresponde a una sola accin del sistemacomputacional. 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 mnemnicos para representar cdigos de operacin, aument

considerablemente la comprensibilidad de las secuencias de instrucciones de

mquina.

Cuando se introdujeron estas tcnicas, los programadores usaban esta notacin al

disear los programas en papel, y luego la traducan a una forma que pudiera

entender la mquina. Este proceso de traduccin es suficientemente sencillo como


20/173

10

para que la propia computadora lo pueda llevar a cabo, lo que dio lugar a que el

uso de nombres mnemnicos se formalizara para dar origen a un lenguaje de

programacin denominado "lenguaje ensamblador", y a un programa, tambin

llamado "ensamblador" que traduca otros programas escritos en lenguaje

ensamblador a lenguaje de mquina.

Figura 1.3 Ensamblador, Compilador e Interprete

Los lenguajes ensambladores representaron un gran avance en la bsqueda de

mejores ambientes de programacin. Por ello, se les denomin lenguajes de

segunda generacin, siendo la primera generacin la de los propios lenguajes de

mquina.

Aunque los lenguajes de segunda generacin tenan muchas ventajas respecto a

su contrapartida de lenguajes de mquina, todava dejaban mucho que desear en

cuanto a ofrecer el entorno de programacin definitivo. Despus de todo, las

primitivas empleadas en los lenguajes ensambladores eran esencialmente las

mismas que las del lenguaje de mquina correspondiente; la nica diferencia era

la sintaxis de su representacin.


21/173

11

Una consecuencia importante de esta ntima asociacin entre los lenguajes

ensamblador y de mquina es que cualquier programa escrito en lenguaje

ensamblador depende inherentemente de la mquina; esto es, las instrucciones

del programa se expresan en trminos de los atributos de una mquina especfica.

Por tanto, un programa escrito en lenguaje ensamblador no se puede transportar

fcilmente a otra mquina porque se tiene que reescribir de modo que se ajuste a

la configuracin de registros y al conjunto de instrucciones de la nueva mquina,

ya que cada tipo de microprocesador tiene su propio lenguaje ensamblador

asociado (entendiendo que el lenguaje Ensamblador es simplemente una

representacin simblica del lenguaje mquina). Por tanto, es necesario un

profundo conocimiento de la arquitectura de la computadora para poder realizar

una programacin 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 trminos de los pequeos pasos incrementales del lenguaje

de la mquina, y no puede concentrarse en la solucin 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 disearlo. El proceso de

diseo se presta mejor al empleo de primitivas de alto nivel, cada una de las

cuales representa un concepto asociado a una caracterstica importante del

producto. Una vez terminado el diseo, se podrn traducir esas primitivas a

conceptos de ms bajo nivel relacionados con los detalles de la implantacin.

De acuerdo con esta filosofa se empezaron a crear lenguajes de programacin

que fueran ms propicios para la elaboracin de software que los lenguajes

ensambladores de bajo nivel. El resultado fue la aparicin de una tercera

generacin de lenguajes de programacin que difera de las anteriores en que sus


22/173

12

primitivas eran de alto nivel y adems independientes de las mquinas.

En general, la estrategia para crear lenguajes de programacin de tercera

generacin fue identificar una coleccin de primitivas de alto nivel con las que se

poda crear software. Todas estas primitivas se disearon de modo que se

pudieran implantar como una secuencia de las primitivas de bajo nivel disponibles

en los lenguajes de mquina.

Una vez identificado este conjunto de primitivas de alto nivel, se escribi un

programa llamado traductor, que traduca a lenguaje de mquina los programas

expresados en dichas primitivas de alto nivel. Todo lo que tena que hacer el

traductor era reconocer las primitivas y convertirlas en sus equivalentes en

lenguaje de mquina.

I.2.3 Clasificacin de los Lenguajes de Programacin

Surgen as, los "lenguajes declarativos" que son ms parecidos al ingls en la

forma en que se expresan y en su funcionalidad, y estn al nivel ms 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 estadstico 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 ms rpidamente el

lenguaje y usarlo en su trabajo, sin necesidad de conocimientos prcticos de

programacin.

Los lenguajes de "alto nivel" son los ms utilizados como lenguajes deprogramacin. Aunque no son fundamentalmente declarativos, estos lenguajes

permiten que los algoritmos se expresen en un nivel y estilo de escritura

fcilmente legible y comprensible por otros programadores. Adems, los lenguajes

de alto nivel tienen normalmente la caracterstica de "transportabilidad". Es decir,


23/173

13

estn implementados sobre varias mquinas, de forma que un programa puede

ser fcilmente "transportado" o transferido de una maquina a otra sin ninguna

revisin sustancial. Es este sentido, se les denomina "independientes de la

mquina".

Ejemplos de estos lenguajes de alto nivel son Pascal, APL, FORTRAN, (para

aplicaciones cientficas), COBOL (usado en aplicaciones de procesamiento de

datos), LISP y PROLOG (para aplicaciones de inteligencia artificial) C y Ada (para

aplicaciones de programacin 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 programacin

Los lenguajes de muy alto nivel, que aparecieron por primera vez en la dcada 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 programacin. De este modo, los lenguajes


24/173

14

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 diseado para un tipo especfico de

tarea. No se puede, por ejemplo, procesar una nmina con un lenguaje de

procesamiento de palabras. Debido a que se enfocan a aplicaciones especficas,

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 programacin

Originalmente, el proceso de programacin se realizaba por el laborioso mtodo

de expresar todos los algoritmos en el lenguaje de mquina. El primer paso dado

para eliminar estas complejidades fue acabar con el empleo de dgitos numricos

para representar cdigos de operacin y operandos del lenguaje de mquina. As

se extendi la costumbre de asignar nombres mnemnicos a los diversos cdigos

de operacin y usarlos en vez de la representacin hexadecimal durante el

proceso de diseo. Por ejemplo, en vez del cdigo de operacin para cargar un

registro, el programador usara el nombre LDA (Cargar valor en el registro

acumulador). En el caso de los operandos, se disearon reglas para que el

programador pudiera asignar nombres (llamados identificadores) a posiciones dememoria y usar tales nombres en una instruccin en vez de las direcciones de

memoria.


25/173

15

Se podra considerar la programacin 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 continuacin.

1. Detectar o definir un problema

2. Disear un Algoritmo de Solucin

3. Escribir un programa

4. Ejecutar el programa

5. Validar resultados

6. Depurar el programa

Volver a (4)

Figura 1.5 Proceso de programacin

Este proceso no ha cambiado a lo largo del tiempo ni con la evolucin de los

lenguajes de programacin. En todo caso, cada nueva generacin (lenguaje) ha

ido haciendo ms fcil y / o eficiente, una o mas etapas de este proceso.

I.3 Tipos de Sistemas de CmputoUn sistema es una coleccin de elementos y procedimientos que interactan para

cumplir una meta. Un partido de ftbol, por ejemplo, se juega conforme a un

sistema. Consta de una coleccin de elementos -dos equipos, un campo de

juego, rbitros- y procedimientos -las reglas del juego- que interactan para

determinar qu equipo es el ganador. Un sistema de trnsito es una coleccin de

personas, mquinas, reglas de trabajo, tarifas y programas que llevan a las

personas de un lugar a otro. Y un sistema computacional es una coleccin de

personas, hardware, software, datos y procedimientos que interactan con el

objeto de realizar tareas de procesamiento de datos.

La funcin de un sistema, ya sea manual o computarizado, es mantener a la

organizacin bien administrada y funcionando sin altibajos. Los sistemas se crean


26/173

16

y modifican en respuesta a las necesidades cambiantes de una organizacin y a

las condiciones en transformacin del medio que la rodea. Cuando surgen

conflictos en un sistema existente o se necesita un nuevo sistema, el desarrollo de

sistemas entra en accin. El desarrollo de sistemas es un proceso que en forma

muy general consta del anlisis de un sistema, el diseo de uno nuevo o las

modificaciones a uno ya existente, la adquisicin del hardware y software

necesarios y hacer que un sistema nuevo o modificado trabaje.

I.3.1 Aplicaciones Monolticas

Los procesos contables sirvieron de punto de entrada a los primeros proyectos

informticos. Paulatinamente los sistemas asimilaron una mayor cantidad de

responsabilidades convirtindose as en grandes aplicaciones monolticas,

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 interactan con ella a travs de terminales que reciben las

instrucciones por medio de un teclado y las envan al host. Esta interaccin no

esta limitada a cierto hardware, ya que los usuarios pueden conectarse usando

PCs o terminales de trabajo de Unix, etc.

Una limitacin de esta arquitectura es que rara vez soporta interfaces grficas, opuede acceder a mltiples 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 nmero de capas, su

nombre, contenido y funcin, sin embargo, en todas las arquitecturas el propsitode cada capa es ofrecer servicios a las capas superiores, estableciendo una

conversacin con las capas similares de otros equipos.


27/173

17

Las reglas y convenciones que se siguen en estas conversaciones se conocen

como protocolos de comunicacin 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 estacin

de trabajo tiene capacidades y responsabilidades equivalentes, por lo que es

econmica y fcil de implementar, aunque cuando esta sometida a grandes cargas

de trabajo no ofrece el desempeo de otras arquitecturas.

El termino cliente / servidor fue usado por vez primera en la dcada de los 80

para referirse a las computadoras personales (PC) conectadas a una red. Elmodelo Cliente / Servidor como se concibe actualmente empez a ganar

aceptacin a finales de esa misma dcada.

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 Comunicacin Cliente / Servidor


28/173

18

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 caractersticas fsicas que el cliente pero con la habilidad de ofrecer un

servicio del que aquel carece. [Sadoski, 1997]

Desde el punto de vista de la programacin, se considera a la arquitectura cliente /

servidor como la extensin lgica de la programacin modular.

La programacin modular se basa en el hecho de que al separar una pieza de

software grande en partes ms simples, crea la posibilidad de que se faciliten el

desarrollo y mantenimiento del todo. La arquitectura cliente / servidor va masadelante reconociendo que estos mdulos no requieren ejecutarse dentro del

mismo espacio de memoria. La continuacin de este concepto es que los clientes

y servidores se ejecuten en las plataformas de hardware y software que resulten

ms apropiadas para el desempeo de sus funciones. Los programas servidores

normalmente reciben las solicitudes de los programas clientes, ejecutan algn tipo

de manipulacin con los datos (recuperar datos de una Base de Datos, efectuar

algn clculo, implementar alguna regla de negocio, etc.), y envan la respuesta

apropiada al cliente.


29/173

19

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 funcin asignada a la

mquina con ms capacidad para llevarla a cabo (la parte del cliente en una

aplicacin corre en el sistema de los clientes, y la parte de la aplicacin

correspondiente al servidor, en la o las computadoras servidores). El usuario

generalmente interacta solo con la porcin del cliente de la aplicacin, que en

general consiste en la interfaz de usuario, el proceso de captura de datos, la

consulta a la base de datos y la obtencin de informes. El servidor realiza las

funciones de fondo, no visibles por los usuarios, como la administracin de los

dispositivos perifricos o el control del acceso a las bases de datos compartidas.

La divisin exacta de las tareas depende de los requerimientos de las

aplicaciones, requerimientos de procesamiento, nmero de usuarios y recursos

disponibles. Entre las tareas del cliente pueden incluirse la obtencin de las

entradas del usuario, hacer solicitudes de datos a los servidores, realizar clculos

en datos locales y desplegar resultados. La parte del servidor capturar o

procesar los datos.


30/173

20

En resumen, las caractersticas bsicas de la arquitectura son:

La combinacin de un cliente o front-end que interacta con el usuario, y un

servidor o back-end que interacta con un recurso compartido. El procesocliente contiene la lgica especfica de la solucin y ofrece una interfaz

entre el usuario y el resto del sistema, mientras que el proceso servidor

acta como el motor de software que administra los recursos compartidos

(bases da datos, impresoras, mdems, etc.).

Los procesos front-end y back-end ocupan recursos fundamentalmente

diferentes (espacio en disco, velocidad del procesador, dispositivos deentrada / salida, etc.). El sistema operativo tambin puede ser diferente.

Tpicamente se trata de ambientes heterogneos, conformados por

computadoras de diferentes marcas. El cliente y el servidor se comunican a

travs de una conjunto bien definido de interfaces de programas -

aplicacin (APIs, por sus siglas en ingles) o de llamadas a Procedimientos

Remotos (RPCs).

Una caracterstica muy importante de estos sistemas es su escalabilidad.

Ya que pueden ser escalados tanto horizontalmente (aadiendo o quitando

clientes), como verticalmente (migrando los servicios a equipos ms

potentes) con un impacto mnimo en su desempeo general.

El modelo cliente / servidor requiere que los programas de aplicaciones sean

escritos como dos componentes separados de software que corren en distintas

mquinas pero que operan como una sola aplicacin.


31/173

21

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 ms, se trata de

una extensin 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 bsicamente,

se puede considerar al Web como un sistema distribuido de hipermedia [Wilde,

1999] en el que la informacin se encuentra almacenada en forma de pginas

Web, que se encuentran entrelazadas unas con otras mediante ligas URL.

Existen programas cliente, llamados navegadores, y programas servidores

localizados en diferentes lugares geogrficos. El programa servidor se ejecuta en

un host de Internet, y responde a las solicitudes de informacin que le hacen losclientes. 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 informacin debe ser mostrada al usuario. Este mecanismo

de trabajo facilita que en los servidores se pueda mantener almacenada

informacin en formatos muy diferentes.


32/173

22

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 tecnologa cliente-servidor, un navegador

es el cliente del servidor de Web.

I.3.4 Cmputo Mvil

Actualmente, la comunicacin de datos, esto es, el intercambio de informacin

(archivos, faxes, correo electrnico, acceso a Internet) se realiza usando redes de

telecomunicacin ya existentes. Los sistemas de comunicacin mvil con voz

(telfonos celulares, radios de onda corta, etc.) estn ampliamente establecidos en

todo el mundo y en los ltimos aos ha habido un rpido crecimiento en el nmero

de suscriptores de las diferentes redes de telefona celular. Una extensin de esta

tecnologa es la habilidad de enviar y recibir datos a travs de estas redes

celulares, siendo este el principio bsico del Cmputo Mvil.

La tecnologa de intercambio de datos a travs de comunicacin mvil se a

convertido en una rama importante de la industria, evolucionando rpidamente y

permitiendo hoy en da que sus usuarios puedan transmitir y recibir datos desde

lugares remotos, a travs de dispositivos como telfonos celulares y mdems

conectados a laptops y agendas electrnicas.


33/173

23

Figura 1.9 Cmputo Mvil

El cmputo mvil permite sincronizar y controlar procesos y eventos donde el

acceso a datos e informacin es prcticamente imposible por otros medios.

Algunos ejemplos de aplicacin del cmputo mvil son: Acceso a expedientes clnicos en lnea en casos de emergencia.

Envo de fotografas de siniestros desde el lugar del accidente para su

anlisis, interpretacin y devolucin (ajustadores de seguros).

Monitoreo y diagnstico especializado de mquinas para su mantenimiento

y reparacin en el campo (por ejemplo bombas de agua, de gas, de aceite).

Acceso a planos y datos para la administracin de servicios pblicos

(drenajes, energa elctrica).

Monitoreo de descargas de aguas residuales.

El cmputo mvil facilita los servicios de venta, facturacin, cobranza y calidad en

el servicio obteniendo y proporcionando datos e informacin en el lugar y en el

momento donde se realiza la operacin. Por ejemplo, proporcionando informacin


34/173

24

sobre productos almacenados o en produccin, informando sobre el status o

localizacin 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 produccin, capturando los datos del cliente

y llevndolos directamente a los almacenes de envo o reas de produccin.

Figura 1.10 Flujos de Informacin en cmputo mvil.

En otros pases, el cmputo mvil ha resultado de mucha utilidad en eventos

especiales de conteo o levantamiento de encuestas: Aplicando encuestas sobre

preferencias o evaluando algn producto o servicio, contando peridicamenteartculos de venta en estantes especializados y enviando esta informacin a

centros de logstica (peridicos, revistas).

A travs del uso de circuitos integrados (microlocalizadores) y ayuda satelital es

posible rastrear productos, unidades mviles 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 deparadas y consumo de combustible, dar seguimiento a unidades de transporte

bancario.


35/173

25

I.3.5 Comentarios Finales

Como se mencion al principio del captulo, una aplicacin puede constituir en si

misma un sistema, pero tambin puede ser que la aplicacin mvil sea parte de un

sistema de informacin ms grande. Esto se aplica tambin para las aplicaciones

en cmputo mvil: los datos almacenados en el dispositivo mvil 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 informacin, adems de delinear una metodologa que

facilite el desarrollo de aplicaciones para estos.


36/173

CAPITULO II

DESARROLLO DE APLICACIONES PARA

ASISTENTES PERSONALES DIGITALIZADOS


37/173

27

II.1 Introduccin a las PDAs

Antes de hablar sobre el desarrollo de aplicaciones para Asistentes PersonalesDigitalizados (PDAs) por sus siglas en ingles, se mencionarn algunascaractersticas de estos.

Se har una mencin especial de las caractersticas de las aplicaciones de la

marca Palm, que actualmente, segn su fabricante, son las ms ampliamentedifundidas.

Figura 2.1 Palm m505

El trmino PDA define a "cualquier dispositivo mvil, que pueda ser operado con

una mano, y que tenga la capacidad de almacenar y procesar informacin para

uso personal o de negocio, as como administrar la agenda y el directorio

telefnico. El trmino handheld se usa como sinnimo de PDA.

Algunas PDAs tienen un pequeo teclado, otras ms tienen una rea de la

pantalla capaz de detectar trazos y reconocer escritura; algunas incluso poseen la

capacidad de reconocer voz.


38/173

28

Figura 2.2 Palm IIIe

Adems de los usos descritos, se han desarrollado muchas aplicaciones para

PDAs y recientemente, se les empieza a combinar con telfonos y sistemas de

radio localizacin.".

La compaa pionera en el desarrollo de PDAs fue Apple, quien introdujo al

mercado su computadora Newton en 1993.

Segn la pgina oficial de Palm (www.palm.com): "los modelos de esta compaa

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 bsicos: sus dispositivos son simples, expandibles , de alta usabilidad y

movilidad". Esta filosofa de diseo, esta siendo apoyada por ms 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 especficamente algunos

modelos emplean variantes del Dragonball como son el EZ o el VZ.


39/173

29

Figura 2.3 El procesador Dragonball

El Dragonball fue ideado como una versin 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 diseo ms simple, menor

tamao, menor costo y nuevas caractersticas 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 energa, entre otras caractersticas.

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 ydatos estn almacenados en memoria y se requiere un rpido acceso a estos.


40/173

30

La memoria RAM empleada en estos dispositivos es rpida y no voltil, gracias a

una alimentacin 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 tamao de las ROM habitualmente es de 2 MB, mientras

que el tamao de RAM es variable, pudiendo oscilar entre los 128 KB (del modelo

Pilot 1000) hasta los 16 MB de los modelos ms 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 estn equipados con

memoria flash ROM que permite actualizar el sistema operativo.

Tambin 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 40MBadicionales.

Sony por su parte comercializa otro dispositivo de expansin de memoria conocido

como MemoryStick que permite almacenar hasta 128MB de informacin. Sin

embargo este tipo de memoria es ms lento que la memoria RAM incluida en los

dispositivos.

Las dos formas que tiene un usuario de interactuar con el Palm son:

a travs del digitalizador de escritura y

a travs de la pantalla.


41/173

31

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 tctil.

Comnmente la pantalla de cristal lquido tiene unas dimensiones de 160 x 160

pxeles (los modelos recientes ofrecen resoluciones mayores). La frecuencia de

actualizacin de la pantalla es, en la mayora 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 tctil, para permitir la interaccin con el

usuario, y adems, algunos de ellos permiten iluminar la pantalla para trabajar en

lugares con poca luz. Cabe destacar que, aunque el mtodo principal de

introduccin de datos es el digitalizador de escritura, tambin es posible hacerlo a

travs de un teclado en pantalla.

Las posibilidades de conexin ya sea entre Palms o con otros dispositivos, es unaparte muy importante de estos, ya que permitirn compartir informacin, 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 informacin con cualquier

dispositivo que soporte este protocolo, como por ejemplo, un telfono mvil, una

impresora u otros dispositivos Palm. Para realizar una comunicacin mediante

IrDA, los dispositivos que se van a comunicar deben estar situados a una distancia

mxima de un metro y sin obstculos en medio.


42/173

32

El puerto serie permite conectarse tanto con la PC como con otros dispositivos. La

comunicacin serie esta completamente basada en interrupciones para la

transmisin de datos. Se utilizan cinco seales externas para soportar esta

comunicacin:

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 travs de la base (cradle). La base es una

interfaz entre el PC y el Palm. Se trata de un soporte de plstico cuyas funciones

son: recargar las bateras del Palm (cuando el modelo lo permite) y sincronizar los

datos del Palm con la PC mediante la pulsacin de un botn.

La sincronizacin a travs 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 estndar Bluetooth en todos sus

dispositivos.

II.3 Arquitectura del Sistema Operativo PalmPalm OS es un sistema operativo diseado especficamente para su utilizacin en

PDAs, comercializado por la empresa Palm Computing. Este sistema operativo

presenta caractersticas especficas debido a las restricciones de los dispositivos

que lo emplean. Estas restricciones son esencialmente tres: tamao del

dispositivo, memoria y capacidad de procesamiento de datos.


43/173

33

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 libreras del sistema hasta la capa de abstraccin del

hardware.

A continuacin se describen los elementos mas relevantes del sistema operativo,

desde el punto de vista del programador.

Eventos: Los eventos informan a la aplicacin de qu es lo qu est ocurriendo en

el sistema, desde una pulsacin de un botn de un teclado externo, hasta el inicio

de una operacin de sincronizacin. Se pueden distinguir eventos de alto nivel y

de bajo nivel. Los de alto nivel son los relacionados con la aplicacin 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


44/173

34

(sistema de archivos) y memoria dinmica (la que emplea la aplicacin durante la

ejecucin). 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 dinmica se utiliza, tanto para las variables globales y variables

reservadas por el Palm OS, como para las variables globales, espacio de stack y

reservas dinmicas de la aplicacin. La memoria esta dividida en tres bloques

(Heap) que son el dinmico, de almacenamiento y de ROM.

Los Heaps son bloques de memoria reservados en forma contigua, estos bloquespueden estar en tres estados distintos: libres, mviles y fijos.

Controles y formularios: Un formulario es, en general, una pantalla para cada vista

de la aplicacin.

Los formularios contienen controles. Un control puede ser: un botn, 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 aplicacin, estos son necesarios

cuando se necesita crear un elemento de interfaz de la aplicacin, ya que un

recurso define cual es la apariencia del elemento y donde est colocado dentro del

formulario.

Mens: Los mens estn asociados con un formulario, generalmente se definen

en tiempo de compilacin, aunque estos mens pueden cambiarse

dinmicamente. Los mens se componen de barras de men y de opciones dentro

de estos. Estas opciones del men podrn tener asociados atajos (shortcuts). Los


45/173

35

shortcuts son letras del alfabeto que permitirn acceder rpidamente 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 slo sobre el puerto serie o

sobre una conexin 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

librera de sockets y esta diseada 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 aplicacin Web en un Palm es un conjunto de paginas HTML comprimidas en

un formato especial (PQA). El funcionamiento de una aplicacin de Web reducida

es el siguiente: las pginas Web comprimidas residen el Palm y los usuarios

rellenan los formularios HTML suministrados por estas paginas. Cuando el usuario

pulsa el botn enviar, la aplicacin Web enva la peticin a un servidor proxy. Este

servidor la traduce en una peticin HTTP, y la reenva 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 pequeas,

considerando que se van a mostrar en la pequea pantalla de la Palm. Tambin


46/173

36

hay que tener en cuenta que se descargan a travs de una conexin relativamente

lenta.

Figura 2.5 Ejecucin de una aplicacin web reducida.

La ejecucin de estas pginas web se realiza mediante el visor de aplicaciones

web. Cuando el usuario pulsa el icono de una aplicacin web, se lanzar primero

el visor y este mostrar el contenido de la pagina web.


47/173

37

Figura 2.6 Otra vista de una aplicacin web reducida

II.4.2 Aplicaciones estndar de Palm

Se definen como aplicaciones con un slo hilo de control, dirigidas a eventos y

mono-tarea. Esto implica que slo habr una aplicacin en ejecucin en uninstante 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 estn dirigidas a eventos, tambin

pueden realizar funciones fuera del ciclo de eventos, como respuesta a otras

peticiones del sistema operativo. Por ejemplo, si se realiza la bsqueda de una


48/173

38

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 botn

de sincronizacin en la base (cradle) de la Palm. Su funcin es la de realizar la

sincronizacin de los datos entre aplicaciones de la PC y aplicaciones en la Palm.

Este tipo de aplicaciones slo se desarrolla cuando se debe realizar unatraduccin del formato de los datos. Existe un kit de desarrollo especial para estasaplicaciones: Palm Conduit Development Kit (CDK), adems de las solucionesofrecidas por terceros.


49/173

39

Figura 2.10 Conduit de sincronizacin diaria de Palm

II.5 Estructura de una aplicacin Palm.

Como menciona [Forester, 2000] la programacin de aplicaciones para Palm OSest 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 aplicacin

misma, y son almacenados en la cola de eventos del sistema operativo. Estos son

procesados segn el mtodo 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 unarespuesta especfica, dejando el control del resto al Sistema Operativo.

Cuando el sistema operativo lanza una aplicacin, invoca a la funcin PilotMain y

le pasa como parmetro un cdigo que indica a la aplicacin la forma en que debe

arrancar; si seala que la aplicacin debe arrancar y mostrar su interfaz de

usuario, se denomina un arranque normal.

Pero este cdigo puede indicar a la aplicacin que debe arrancar, realizar alguna

tarea pequea y luego terminar (como cuando se usa la funcin global de

"encontrar", que busca una cadena de caracteres en las bases de datos de todas

las aplicaciones). Existen cdigos de arranque para muchos propsitos, como


50/173

40

abrir una base de datos en un registro predeterminado, notificar a la aplicacin que

se acaba de realizar una sincronizacin exitosa, etc.

Adems, existe una estructura de datos que describe el tipo de evento que estaocurriendo en un momento dado [Ibid.]. En esta estructura se almacena el tipo de

evento que esta ocurriendo (por ejemplo, presionar con el lpiz algn botn) as

como la informacin relativa a ese evento (por ejemplo, las coordenadas en las

que el lpiz toc la pantalla).

Si se realiz un arranque normal, la funcin PilotMain invoca a StartApplication (en

esta funcin se recomienda inicializar las bases de datos y obtener del sistemaoperativo las preferencias del usuario), enseguida, llama a la funcin

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

Despus la ejecucin pasa a la funcin EventLoop, quien es la responsable de

procesar todos los eventos recibidos por la aplicacin.

Cada nuevo evento se acomoda al final de la cola de eventos, de donde la funcin

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 especficos de la forma que se encuentra activa.

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

funcin termina cuando recibe un appStopEvent. En este momento, regresa la

ejecucin a PilotMain.


51/173

41

Finalmente, la funcin 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 aplicacin termine en forma correcta.

El siguiente diagrama muestra el orden en que son llamadas las principales

funciones de cualquier aplicacin Palm:

Figura 2.11 Secuencia de llamadas de FuncionesLa funcin 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

botn, o mueve la barra de desplazamiento de una tabla, en esta funcin 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 programacin puede desarrollarse en

C o C++ (o varios otros lenguajes para los que existen compiladores que generan

cdigo que se puede ejecutar en PDAs), sin olvidar que, como se ha citado


52/173

42

anteriormente, una aplicacin para Palm es simplemente una base de datos que

contiene por una parte el cdigo ejecutable y por otra los elementos grficos y

dems datos.

En el caso especfico de la programacin 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 jerarqua de objetos de la interfaz grfica,

empezando por la 'forma' (similar a la 'ventana' cuando se desarrolla paraWindows) a la que se le van aadiendo otros objetos como barras de men (a las

que a su vez se les aaden mens), botones, campos de texto, tablas, etc. En

este archivo se deben inducir tambin los mapas de bits (bitmaps) que se van a

usar en la aplicacin.

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 prdida total de la

informacin almacenada en la Palm. Por esto ltimo, se recomienda probar la

aplicacin en un programa, llamado PalmOS Emulator, que se ejecuta en la PC y

simula totalmente la funcionalidad de una Palm (1).


53/173

43

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

01

0Loader

Memoria

Ensamblador

Mnemonicos

mov AX,0

llda BX

Ensamblador Ligador

Lenguaje

de

Alto

Nivel

Lenguajes

de

Programacin

(P.E.Pascal)

Compilador

Interprete

Figura 2.12 Niveles de programacin

II.5.2 Common Object File Format

II.5.2.1 Archivo Objeto

Como se explica en [PCWebopaedia, 2003] cuando se programa, se escribe

cdigo en forma de cdigo fuente: instrucciones de algn lenguaje particular, como

C o Fortran. Sin embargo las computadoras slo pueden ejecutar instrucciones

escritas en lenguaje de mquina.

Para pasar de cdigo fuente a lenguaje de mquina, los programas deben sertransformados por un compilador. El compilador genera un archivo intermedio con

cdigo llamado objeto. Este archivo sirve de entrada al encadenador (linker) que

resuelve las llamadas que el archivo objeto hace a las libreras propias del


54/173

44

lenguaje. El termino "archivo objeto" no necesariamente implica alguna conexin

con la programacin orientada a objetos.

Como se ha sealado, cuando un compilador procesa el cdigo fuente (en nuestro

caso, en C o C++), genera un archivo objeto, que posee un formato especfico. 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 configuracin del ambiente de desarrollo).

Figura 2.14 Generacin de un ejecutable.

II.5.2.2 COFF

Debido a que un microprocesador solo ejecuta sus propias instrucciones nativas,

una solucin eficiente para desarrollar programas que se ejecuten en una

plataforma diferente a aquella en la que se programa, consiste en crear cdigobinario para la plataforma destino, a partir de programas fuentes (usualmente en C

o C++).


55/173

45

Pero para explotar al mximo las caractersticas fsicas del dispositivo destino, se

requieren hacer optimizaciones adicionales. En la literatura existen tcnicas de

optimizacin de cdigo 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

aritmtica de punto flotante se debe hacer a travs de libreras de software.

Por otro lado, como el mismo sistema operativo esta escrito (al menos en parte)

con instrucciones de cdigo nativo, es ms eficiente que los programas

interacten directamente con este, y no a travs de interfaces o maquinas virtuales

como la maquina virtual de Java.

La mayor dificultad que se presenta cuando se desarrollan ejecutables en cdigo

nativo es, como puede observarse, que normalmente el cdigo nativo no funciona

en dos plataformas de hardware diferentes. Y an cuando el hardware sea el

mismo, pequeas inconsistencias en la plataforma pueden ser suficientes para

causar problemas.

Algunos sistemas operativos, como el PalmOS, ofrecen acceso a rutinas internas

a travs 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 aplicacin debe ligarse contra libreras de sistema ofrecidas

normalmente por el desarrollador del hardware. Estas libreras 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 prcticamente la misma

funcionalidad. Ambos pueden usarse para especificar cdigo objeto (de archivos

generados por el compilador), y cdigo ejecutable (archivos producidos por la

herramienta de encadenado). Estos formatos contienen secciones. Las secciones


56/173

46

que se encuentran tanto en archivos objeto como ejecutables son: .text, que

contiene el cdigo binario ejecutable; .data, que contiene datos inicializados en el

programa (como en una declaracin "int a=7;" donde se declara un entero y se

inicializa con un valor de 7); y .bss (blow stack segment), seccin 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 ejecucin).

II.5.2.3 COFF y Palm

En Unix, segn explica la pagina del Manual de COFF, la salida de las

herramientas de encadenamiento (linker) y el ensamblador (llamadas a.out por

omisin) estn codificadas en formato Common Object File. Un archivo de objeto

comn (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 seccin, una seccin de datos, informacin de

relocalizacin, nmeros de lnea opcionales, una tabla de smbolos y una tabla de

cadenas.

II.5.2.4 PRC-ToolsLas PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc".

Esta herramienta tiene un doble propsito: convertir recursos de cdigo 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 propsito: convertir recursos de cdigo 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.


57/173

47

Las PRC-Tools producen cdigo en formato m68k-coff, es decir, cdigo para

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

COFF.

Se debe sealar que en situaciones de desarrollo como la descrita, en donde se

cuenta con una herramienta de post-encadenamiento, la eleccin 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.


58/173

48

Figura 2.15 Generacin de un ejecutable con PRC-Tools

Otra de las herramie

27269939 Desarrollo de Aplicaciones Para Dispositivos Moviles Tesis de Ivan Carlos Rivera Gonzalez

Documents

Transcript of 27269939 Desarrollo de Aplicaciones Para Dispositivos Moviles Tesis de Ivan Carlos Rivera Gonzalez