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.

II

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

III

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

IV

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

V

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

VI

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

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

VIII

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

INTRODUCCIÓN

2

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.

3

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.

CAPITULO I

DESARROLLO DE SISTEMAS

5

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

6

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

7

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.

8

La traducción de un programa consiste en tres actividades: análisis léxico, análisis

sintáctico y generación de código

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

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

G e n e r a c i ó n

d e c ó d i g o

P r o g r a m aF u e n t e

P r o g r a m ao b j e t o

9

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

10

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.

11

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

12

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,

13

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

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

15

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

16

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.

17

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

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

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

20

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.

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

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

23

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

24

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.

25

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.

CAPITULO II

DESARROLLO DE APLICACIONES PARA

ASISTENTES PERSONALES DIGITALIZADOS

27

II.1 Introducción a las PDAs

Antes de hablar sobre el desarrollo de aplicaciones para Asistentes PersonalesDigitalizados (PDAs) por sus siglas en ingles, se mencionarán algunascaracterísticas de estos.

Se hará una mención especial de las características de las aplicaciones de lamarca Palm, que actualmente, según su fabricante, son las más ampliamentedifundidas.

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.

28

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.

29

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.

30

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.

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

32

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.

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

34

(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

35

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

36

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.

37

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

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 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 unatraducción del formato de los datos. Existe un kit de desarrollo especial para estasaplicaciones: Palm Conduit Development Kit (CDK), además de las solucionesofrecidas por terceros.

39

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

40

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.

41

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

42

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

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

011101

Loader

Memoria

Ensamblador

Mnemonicos

mov AX,0

llda BX

Ensamblador Ligador

Lenguaje

de

Alto

Nivel

Lenguajes

de

Programación

(P.E.Pascal)

Compilador

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

44

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++).

45

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

46

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.

47

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 <.=)5.��28��3 �'�4�� $>5.�/��28��9:�2�?3 <*��@�)��)A#3

↓��AB�'� $&%&��'��(0��"�,!��&��-��(*��BA��)��0�,�1�'��"��2�;��"3

↓��C)CC�3 <�=�CC)C�3 �'��D=FE�3 8�B�� $GCC)C�3 <.=)C�C�C�3 �'��H�;��I�)��A��43

�/E�3��B�)= <��/� $GJ-�'�"<� K��L�#��,!#�

↓(�M�N)O.P��)AB(��2P/��P/Q��)� $ ��(R��BA��)��)�S(*��A6!#B��A��"!#�� '(*�GT�U&VI3

↓��'�<,WK��G�)�)� � � $ ��(*��A��,�G��*�A.��(*��AB�)��X(*��AW!#��AB�4!�� '(*�&Q��3

↓�)8"Y+P/�'�� $GZ[��(G8��\�*ABA��(0��,�G(0M�N)O�P��A�(0��DP#��P#�)8Y"P#�'��43

↓�/E�3 Q��'��=�E�3 8�� $G��'�"<�WK��13 Q��'�:]��'��Q��'�(0�)=��'�"<�WK��13 8��^]_J-�'�"<�WK��@��-A��&B��!#�"�� )C:Q��'�� ,3

↓

48

8,��A��P��'� $`%a�� '�(��"�,!��&�,�H��! P#��)��"��)��=)��'��?��-��'�<,WK�� cb-d.d 3

↓�6%&�A�A��3 ��'�� $-e�YD��"��!#�"8�A��1��'�15X��A�( b*f 3

Figura 2.15 Generación de un ejecutable con PRC-Tools

Otra de las herramientas disponibles en las PRC-Tools es "multigen". Esta

herramienta permite especificar varios archivos de recursos. multigen toma como

entrada un archivo de definición que especifica los archivos de recursos que se

van a usar, y produce como salida un par de archivos en los que se señalan las

secciones del código objeto que contendrán recursos. Uno de estos archivos

contiene comandos de encadenamiento, y es a su vez usado por la herramienta

ld.

II.5.2.5 CodeWarrior

Según se indica en el documento CodeWarrior Assembler Reference, esta

herramienta soporta diferentes formatos de archivos objetos, como el Executable

and Linkeable Format (ELF) o el Common Object File Format (COFF)

La herramienta de encadenamiento (linker) de CodeWarrior es una herramienta

que permite la adición de módulos que le permiten manipular diferentes archivos

objeto y librerías, permitiéndole así generar ejecutables para diferentes

plataformas

II.5.2.6 Otros

Microsoft también da soporte, en Windows NT, a los archivos objeto en formato

COFF. La versión 3.1 de Windows NT introdujo un nuevo tipo de formato de

archivo ejecutable llamado PE (Portable Executable).

Este formato se inspiró en el formato COFF (Common Object File Format) de los

sistemas operativos UNIX. Pero para mantener su compatibilidad con las

versiones del MS-DOS y los sistemas operativos Windows, el formato PE

49

mantiene el encabezado MZ del MS-DOS. Se le nombró portable, por que según

Microsoft el archivo ejecutable tiene el mismo formato sin importar si el procesador

en que se va a ejecutar tiene un tamaño de palabra de 16, 32 o 64 bits. Asimismo

este mismo formato es usado en micro procesadores diferentes a los Intel, tales

como MIPS, Alpha y Power PC, entre otros. Los archivos DLL de 32 bits y los

controladores de dispositivos (device drivers) también emplean el formato PE.

Figura 2.16 PE-Coff de Microsoft

[Ardri, 2002] reporta que utilizando las PRC-Tools, ya es posible generar

programas para el procesador ARM con el que vienen equipados los nuevos

modelos Palm Tungsten T.

II.6 Integración de un ambiente de desarrollo Palm

II.6.1 Herramientas de desarrollo disponibles

Una vez que se tiene claro cuales son los tipos de aplicaciones que se pueden

desarrollar, se deberá elegir una herramienta de programación. Para esto, se

enlistan enseguida algunas de las herramientas disponibles en este momento,

para desarrollar aplicaciones para Palm.

50

Existe una gran variedad de lenguajes de programación entre los que se puede

elegir, desde programación a bajo nivel con ensamblador hasta programación

orientada a objetos

Por ejemplo, existe una herramienta llamada Pila que permite programar en el

lenguaje del microprocesador DragonBall 68328. Pila ensambla, compila recursos

y enlaza librerías, permitiendo obtener un ejecutable de Palm.

Se ha establecido como criterio de clasificación el estilo de desarrollo,

diferenciando entre entornos de desarrollo rápido (RAD - Rapid Application

Development) y los entornos de desarrollo más tradicionales: compilador,

depurador y editor de recursos.

Como un caso especial de estas últimas herramientas, se mencionan las

disponibles bajo el esquema OpenSource, esto es, aquellas herramientas cuyo

código fuente esta disponible para ser modificado o mejorado por cualquier

persona.

II.6.1.1 Herramientas Orientadas a formularios

Herramientas Orientadas a formularios: Esta es una de las formas más rápidas y

directas de realizar aplicaciones Palm. Debido a la amplia difusión de la plataforma

Palm, existen múltiples entornos dedicados a crear aplicaciones basadas en

formularios. Los dos entornos mas extendidos son Satellite Forms y Pendragon

Forms

Satellite Forms: Cuando se emplee Satellite Forms, las aplicaciones

consistirán en tablas de bases de datos y formularios. Cada formulario estará

asociado a una tabla concreta y podrá mostrar los datos de esta.

51

Las acciones de la aplicación se pueden controlar de dos formas: Especificar

acciones "prefabricadas" que suceden en respuesta a las acciones del

usuario. Por ejemplo, cuando se pulsa un botón, se podrá elegir de entre las

opciones disponibles la que más convenga, como volver a la anterior pantalla

o crear una nueva.

Mediante código escrito por el programador. Para escribir este código se

utiliza un lenguaje de script muy similar al Visual Basic.

Satellite Forms incluye un buen numero de controles prefabricados y una

librería de rutinas. Además, tiene un mecanismo de extensión que nos

permitirá construir nuevos componentes y librerías utilizando código C.

Figura 2.17 Satellite Forms

52

Sin embargo, tiene la desventaja de que el entorno solo funciona en

Windows, y que las aplicaciones que crea obligan a instalar en el Palm una

librería de tiempo de ejecución. Por lo que esta aplicación no da la flexibilidad

que se puede obtener programando en C / C++ directamente.

Pendragon Forms: Utilizando esta herramienta, se pueden desarrollar

aplicaciones que permiten adquirir datos desde la Palm, para luego actualizar

las bases de datos corporativas.

Figura 2.18 Pendragon Forms

II.6.1.2 Herramientas Orientadas a la programación tradicional

Bajo esta categoría caen todas aquellas herramientas que permiten un mayor

control del entorno. Generalmente, incluyen un compilador, un depurador y en

algunos casos, un entorno integrado de desarrollo. Existen herramientas de este

tipo para diversos sistemas operativos como Windows, Unix y Mac OS.

53

La opción mas difundida para programar en Palm es el lenguaje C. Y existen dos

opciones principales entre las que se puede elegir: por una parte la solución

comercial con el software de desarrollo CodeWarrior de Metrowerks, y por otra las

llamadas PRC-Tools, el conjunto de herramientas Open Source desarrolladas por

la “Free Software Foundation”.

CodeWarrior es una herramienta comercial, bastante completa, que incluye el

generador de recursos “Constructor” y un depurador simbólico entre otros.

Según la compañía Palm, CodeWarrior es el entorno de desarrollo más utilizado

entre los desarrolladores para Palm. Permite crear software desde Windows o

Mac, y que se ejecuta directamente en cualquier dispositivo Palm OS y entre las

ventajas de este entorno, destacan su ambiente integrado de desarrollo (IDE), la

integración entre el compilador de C / C++ y el depurador. Además, la unión con el

emulador de Palm OS que permite probar y depurar aplicaciones más

rápidamente. También cuenta con una buena documentación sobre la plataforma

Palm OS con manuales y ejemplos.

La solución más económica, las PRC-Tools, esta compuesta por diferentes

herramientas GNU, de libre distribución como son, gcc, binutils, gdb y varias

herramientas de enlazado para producir el código ejecutable para Palm OS. Existe

una versión de las PRC-Tools para Windows, que se distribuye como parte del

ambiente de desarrollo Cygwin, y otra versión que trabaja en modo de línea de

comandos.

Las PRC-Tools ofrecen versiones de los paquetes de desarrollo GNU como el

GCC (es el compilador de C GNU), binutils (utilidades varias), GDB (depurador),

PilRC (compilador de recursos), PilrcUI (previsualizador de recursos).

54

También existen interpretes de BASIC (como CbasPad) o LISP y varias máquinas

virtuales para Java, entre las que destacan la máquina virtual KVM de SUN y la

máquina virtual J9 de IBM, esta última integrada dentro del entorno de desarrollo

VisualAge Micro Edition.

Otras herramientas que se pueden mencionar son:

Assembler SDK: Este conjunto de herramientas permite el desarrollo de

aplicaciones escritas en el ensamblador del Motorola 68000. Assembler SDK es

totalmente gratuito.

Jump: Permite desarrollar aplicaciones en Java usando una librería de clases para

Palm a través de cualquier editor de textos. El proceso que realiza Jump es

traducir los archivos .class de Java a código ensamblador del Motorola 68000. Al

igual que la anterior esta también es gratuita además de suministrar el código

fuente.

II.6.2 El PalmOs Emulator (POSE)

El emulador de Palm OS, normalmente conocido como POSE, es un emulador del

hardware de Palm que permite probar y depurar aplicaciones para Palm OS.

Se trata de un programa muy útil puesto que reproduce fielmente el

comportamiento e incluso la apariencia de los dispositivos reales y permite probar

los programas sin necesidad de usar un dispositivo real. Está disponible para los

sistemas operativos Macintosh, Unix y Windows.

Cuando se ejecuta una aplicación Palm OS en el emulador, éste captura las

instrucciones, trabaja con registros y refresca la pantalla del dispositivo trabajando

de la misma manera que lo haría el procesador utilizado dentro de los dispositivos

Palm, la diferencia reside en que las instrucciones se ejecutan mediante software.

55

Pero, a pesar de la bondad del emulador, algunas veces se hace necesario

emplear un dispositivo real para realizar las pruebas. Esto ocurre por ejemplo

cuando en la aplicación se emplea la comunicación TCP/IP mediante sockets.

Debido a que POSE emula el hardware de un dispositivo Palm es necesario

obtener un archivo con la imagen ROM del dispositivo Palm para el que se va a

programar. Este archivo no se distribuye junto con el emulador pero se puede

obtener de dos maneras, ya sea descargándolo de un dispositivo o descargándolo

de la sección ‘Palm Resource Pavillion’ de la página de Palm OS (proceso que

requiere estar registrado dentro de la base de datos de desarrolladores de Palm)

Para transferir la imagen ROM desde el dispositivo al emulador se deben seguir

los pasos indicados en la opción ‘Transfer ROM’ del emulador.

El Emulador de Palm fue desarrollado originalmente en Unix, dentro del esquema

OpenSource bajo el nombre de CoPilot, para posteriormente ser renombrado

POSE (abreviatura de PalmOs Emulator).

POSE es un programa gratuito con versiones para Windows, Macintosh y Unix /

Linux, y es importante señalar que, cuando el programador original vendió una

versión del código a Palm, esta compañía tomó la decisión de seguir

desarrollándolo, manteniéndolo (al menos en Unix) como un programa

OpenSource. Pero, además, aprovechando las posibilidades que el esquema

OpenSource ofrece, a partir de la última versión del código fuente disponible se ha

desarrollado otra versión del emulador, llamada QPilot, que es totalmente

independiente de la de Palm.

56

II.7 Características del API de Palm

Para facilitar el desarrollo de aplicaciones para sus dispositivos, Palm Inc. ofrece

un conjunto de Interfaces de Programación de Aplicaciones (APIs, por sus siglas

en Inglés) en lenguaje C.

Estas APIs están conformadas por archivos de encabezado (.h) en los que se

definen funciones y declaraciones que son fundamentales para el desarrollo de

aplicaciones en Palm.

Palm organizó estas funciones en administradores: grupos de funciones que

trabajan en forma conjunta para controlar una faceta importante del dispositivo.

Los administradores básicos controlan la interfaz de usuario, la memoria y las

comunicaciones.

Sin embargo, Palm no establece ningún tipo de organización de sus APIs, por lo

que, a continuación se sugiere un esquema de organización de las mismas.

Este esquema se elaboró estudiando el código fuente (los archivos de

encabezado) para determinar la funcionalidad que ofrece cada conjunto de rutinas,

tanto para el programador, como entre ellas.

Como se puede observar, existen un conjunto de funciones que sirven de soporte

a todo el esquema. Estas funciones hacen llamadas directas a rutinas de bajo

nivel del PalmOS (como administración de memoria y control de eventos del

sistema), por lo que se agruparon como funciones del Núcleo.

57

Figura 2.19 Organización de la API de Palm.

Sobre este conjunto inicial se construyen otras funciones, encargadas entre otras

cosas, de manejar los errores y las facilidades de depuración de código, la

aritmética de punto flotante, encriptamiento de datos, etc. Estas funciones se

clasificaron como funciones de Administración del Sistema.

También sobre las funciones del Núcleo se construyen otros conjuntos

encargados de manipular tablas de datos y otros programas (Funciones de

manejo de Archivos), eventos a los que el programa debe responder, control de

errores, control de dispositivos de comunicación (puerto, lápiz, pantalla) y

funciones de manejo de la Interfaz con el usuario.

En esta última clasificación se agrupan todas las funciones que permiten

manipular formas (abrir y cerrar, crear, etc.) y los elementos de cada forma

(mapas de bits, botones, cajas de texto, barras de desplazamiento, tablas, etc.).

58

La siguiente tabla muestra los archivos de encabezado más importantes de la API

nativa del PalmOS SDK, agrupados en el orden sugerido por el esquema.

Nivel de

Abstracción

Archivo de

encabezado

Funciones que controla

Sistema

SysEvent Eventos

MemoryMgr Memoria

PalmTypes Tipos de datos elementales

M68Khw Hardware

BuildDefines Definición de Variables

ErrorBase Errores

DebugMgr Funciones de depuración

Chars Caracteres de control

Encypt Rutinas de Encriptamiento

Event Control de Eventos

FloatMgr Números de punto flotante

Comunicaciones

ConnectionMgr Interfaz de conexión. Permite a otras aplicaciones

acceder al puerto de comunicación

Ctp Comunicación a través de Servidor Proxi

Archivos

DataMgr Tablas de datos

FileStream Archivos

Find Rutinas de control de búsquedas

Interfaz de Usuario

Form Formas

Window Ventanas

Control Rutinas generales para manipular Controles

59

Table Tablas

Field Campos

Font Fuente con el que se despliegan las cadenas de

caracteres

Rect Estructura de rectángulo. Base para el desplegado de

objetos de la Interfaz gráfica

ScrollBar Barra de desplazamiento

Bitmap Imágenes de Mapas de Bits

Tabla 2.1. Archivos importantes de la Interfaz de Programación de Aplicaciones de Palm

II.7.1 APIs Definidas por el usuario

Para integrar una nueva Interfaz de desarrollo de aplicaciones a un proyecto

desarrollado con CodeWarrior, es suficiente con crear un archivo de definiciones

de las nuevas funciones (.h), el archivo de código correspondiente (.cpp) e incluir

en el programa principal del proyecto (normalmente Starter.c o Starter.cpp), una

llamada al archivo de definiciones.

Por ejemplo, para añadir una clase miString (de manejo de cadenas de

caracteres), se crea un archivo miString.h, con la definición de la clase:

/ / mi St r i ng. h

#i f ndef _MI _STRI NG_H_

#def i ne _MI _STRI NG_H_.

#i ncl ude <St r Mgr . h>

cl ass St r i ng{

char cText o[ 100] ;

publ i c:

mi St r i ng( char * cadena) ;

60

}

#endi f

Enseguida, se crea un archivo String.cpp, con la implementación de los métodosde la clase:/ / mi St r i ng. cpp

mi St r i ng mi St r i ng( char * cadena) {

St r Pr i nt F( cText o, " %s" , cadena) ;

}

Por último, en el archivo Starter.cpp, se añade la línea:

#i ncl ude " mi St r i ng. h"

Una vez hecho esto, todas las rutinas del proyecto podrán tener acceso a la clase

miString.

II.7.2 El ambiente de desarrollo para este trabajo

Para desarrollar el presente proyecto ha decidido usar el CodeWarrior, por que

ofrece un entorno amigable, da soporte al lenguaje C o C++ y evita dar especial

relevancia a los detalles de configuración del entorno, como ocurre con PRC-

Tools.

II.7.3 CodeWarrior

El CodeWarrior (de MetroWerks) es una herramienta comercial, pero se puede

descargar una versión de evaluación con toda la funcionalidad, excepto el tamaño

de los ejecutables que se pueden crear y depurar.

61

CodeWarrior combina diferentes herramientas de desarrollo (un editor de código,

un compilador, una utilería de encadenamiento (linker) y otra de depuración

(debugger) en una sola aplicación, controlada por una interfaz gráfica.

Además, es una herramienta que se ejecuta en diferentes plataformas: existen

versiones operativas para Windows, MacOS y Solaris, y versiones en desarrollo

para otras, como Linux. Todas ellas ofrecen la misma interfaz de usuario,

independientemente del sistema operativo sobre el que se este ejecutando.

Existen versiones de CodeWarrior para C, C++, Object Pascal y Java

Para los fines perseguidos en el presente trabajo, la característica más importante

es que CodeWarrior puede generar código ejecutable para procesadores de la

serie Motorola 68000, a partir de equipos ejecutando Windows (típicamente, con

procesadores Intel x86)

II.7.4 Eligiendo entre C y C++

Para decidir si el presente proyecto se desarrollaría en C o C++, se han tomado en

cuenta distintos factores.

Por una parte, en sitios que distribuyen programas para Palm junto con código

fuente (como www.palmopensource.com ) se puede observar que hasta un 95%

de los desarrollos están hechos en C.

Una de las excepciones que se puede desatacar es el programa pBill que es una

versión para Palm del juego para Linux del juego Xbill (www.xbill.org) y que esta

desarrollado completamente en C++.

62

También existen algunas librerías en C++: hay productos de código abierto como

Teenie (solo se puede obtener en www.palmopensource.com, ya que desapareció

como producto gratuito y se convirtió en ZenPlus, un producto comercial), y otros

productos en etapas iniciales del desarrollo.

Por ejemplo, para las PRC-Tools existe un producto llamado Palm C++

Framework (www.bradygirl.com/PalmFW), las Palm SDK Foundation Classes

(sourceforge.net/projets/pfcpp/), o el "Razor! Game Engine" (www.tilo-

christ.de/razor) que es una librería para desarrollo de juegos.

Pero también hay disponibles productos comerciales, como Object Library for

PalmOS (www.aqpoint.com/pol/), el Palm Application Framework

(brearriver.com/developer/palm) o el mencionado ZenPlus.

Por otro lado, C permite simular objetos usando estructuras. [Young, 1992]

muestra un ejemplo completo de como implementar una aplicación orientada a

objetos en C manejando estructuras; en resumen, el autor propone el manejo de

los atributos del objeto a través de estructuras en C, y para simular el

encapsulamiento, todas las funciones que manipulen datos del objeto deben

recibir como primer parámetro un apuntador al mismo. De esta forma, si al

programador por accidente llamara a la función con otros objeto, ocurriría un error

en tiempo de compilación.

En su página para desarrolladores, Palm Inc. plantea una solución similar a la

comentada: estructuras en c.

Esto, por que hasta la versión 5, el conjunto de herramientas de desarrollo de

software ofrecido por Palm (PalmOS SDK), esta desarrollado en C, con un manejo

exhaustivo de estructuras, y aunque la página de PalmSource, en la sección

63

"Languajes and Environment Types"

(http://www.palmos.com/dev/start/environments.html) dice:

“Existen... librerías de C++ desarrolladas por terceros para facilitar el

desarrollo de aplicaciones Palm. Actualmente, ninguna de ellas esta

soportada oficialmente por Palm, pero detrás de cada una de ellas hay una

comunidad de desarrolladores que pueden dar soporte.

Ninguna de las librerías ofrece herramientas de desarrollo adicionales, por los

que se debe elegir un ambiente de desarrollo, obtener el último Kit de

desarrollo de Software y añadir entonces las librerías de C++ ”.

Las “recetas” de desarrollo (http://www.palmos.com/dev/support/doc/recipes/)

siguen siendo en C.

La mayor parte de la bibliografía sobre desarrollo de aplicaciones Palm disponible

en el mercado, cubre, también, solo los aspectos relativos al desarrollo con C. Así,

las primeras ediciones de libros como PalmOs Programming Bible, PalmOS

Programming, the developers guide o Instant PalmOS Applications se ocupan solo

de programación en C. Y en la comunidad mundial de desarrolladores, las

opiniones también se inclinan hacia desarrollar en C.

En páginas web como: Palm OS Programmer's FAQ

(http://tangentsoft.net/palmfaq/) publicada por Wade Hatler y Warren Young se

menciona que al desarrollar aplicaciones para Palm en C++, la principal cuestión

que se debe tener en cuenta son las limitaciones de espacio disponible en la

memoria de los dispositivos. Según la opinión de los citados autores, es muy

sencillo caer en errores de programación en C++ que provoquen que el tamaño

64

del código ejecutable se vuelva tan grande que sea imposible de manipular en un

dispositivo Palm.

Para prevenir esos errores, sugieren, entre otras cosas: evitar el uso de

Templates, usar algunas opciones de compilación que ayudan a obtener código

ejecutable compacto, y tener cuidado con la implementación del polimorfismo.

Sin embargo C tiene una serie de desventajas frente a C++. Enumerarlas todas no

es el fin de este trabajo, baste decir que el manejo mas eficiente que C++ hace de

la memoria, de entrada lo convierte en una mejor opción para programar en un

ambiente donde, como se ha explicado, el manejo adecuado de la memoria es

primordial.

Por esta razón, uno de los planteamientos que hace el presente trabajo, es el

desarrollo de una librería de objetos para CodeWarrior, bajo el esquema

OpenSource.

Esta librería es, en realidad, un conjunto de clases que enmascaran todas las

funciones ofrecidas por las APIs de Palm. Además, ofrece clases para manipular

todos los elementos de la interfaz de usuario.

También se plantea un esqueleto de todos los objetos que controlen las reglas del

negocio. Así como un esquema de control de memoria:

Considerando que en C (y C++) la mayor cantidad de memoria la consumen las

cadenas de caracteres, recordando que en C es responsabilidad del programador

liberar la memoria reservada para cadenas y que C++ no posee un esquema

"recolector de basura" que libere la memoria que ya no se esta utilizando, tan

eficiente como puede ser (por ejemplo) el de Java, se plantea la creación de una

65

sola instancia en toda la aplicación de las clases de Cadenas (de Caracteres),

Bases de datos, de todas las clases que ayuden en la manipulación de objetos de

la Interfaz de Usuario y de otras clases relacionadas más con las reglas de

negocio, como podría ser la clase Numero Flotante.

CAPITULO III

OMT PARA EL ANÁLISIS Y DISEÑO DE

APLICACIONES EN ASISTENTES PERSONALES

DIGITALIZADOS

67

III.1 Elementos de OMT

Una metodología es un algoritmo que encuentra la solución de un problema dado

a través de un proceso bien definido. Como nos dice [Pressmann, 1988], la

popularidad de las tecnologías de objetos ha generado docenas de métodos de

análisis y diseño. Cada uno de ellos introduce un proceso para el análisis del

sistema, un conjunto de modelos que evoluciona fuera del proceso y una notación

que posibilita crear cada modelo de una manera consistente. Entre otras

metodologías se pueden mencionar la de Booch, Coad y Yourdon, de Jacobson y

el OMT de Rubaugh y sus colaboradores. Recientemente fue desarrollado el

Rational Unified Process por un equipo formado por Booch, Rumbaugh y

Jacobson.

OMT es una metodología de análisis y diseño de Sistemas que según [Rumbaugh.

1991], se basa en la construcción de tres proyecciones visuales del sistema

llamadas modelo de objetos, modelo dinámico y modelo funcional. Cada uno de

ellos representa una abstracción de cierto punto de vista esencial del sistema

suprimiendo detalles que son irrelevantes para esa vista.

III.1.1 Modelo de Objetos

El modelo de objetos es el más importante de los tres. Define las clases de objetos

en el sistema y sus relaciones, atributos y operaciones (métodos). Describe la

estructura estática de los objetos en un sistema y sus relaciones; utiliza el

diagrama de objetos, el cual es un grafo cuyos nodos son clases de objetos y

cuyos arcos son las relaciones entre las clases. Sus elementos son: objetos,

clases, atributos y operaciones. Un objeto es un concepto, abstracción o cosa con

límites bien marcados y significativo para la aplicación. Todos los objetos tienen

68

identidad y son distinguibles. Una clase de objetos describe un grupo de objetos

con atributos, operaciones y semántica comunes. Un atributo es una propiedad de

los objetos de una clase. Una operación es una acción que puede ser aplicada a

(o realizada por) los objetos de una clase.

El Modelo de objetos esta compuesto por los diagramas del modelo de objetos y

diccionario de datos.

III.1.2 Modelo Dinámico

El modelo dinámico representa la información de control, incluyendo secuencias

de eventos, estados y operaciones que ocurren dentro del sistema. Indica la

interacción entre objetos y sus cambios de estado. Captura el comportamiento

esencial del sistema en diagramas de estado, y hace de uso de diagramas de flujo

de eventos para mostrar escenarios.

El modelo dinámico describe los aspectos del sistema que cambian conforme

pasa el tiempo. Se usa para especificar e implantar los aspectos de control del

sistema. Contiene diagramas de estados, los cuales son grafos cuyos nodos son

estados y cuyos arcos son transiciones entre los estados, las cuales son causadas

por los eventos. Sus elementos son: estados, transiciones y eventos. El estado de

un objeto se determina por los valores de sus atributos y sus ligas en un momento

específico. Las transiciones denotan los cambios en el estado de un objeto. Los

eventos son los que disparan las transiciones de un estado a otro.

III.1.3 Modelo Funcional

El modelo funcional captura la forma en que se calculan los valores y las

relaciones entre valores en un cálculo. Es un diagrama de flujo de datos del

sistema que describe lo que hace el sistema (no como lo hace). Describe las

transformaciones de los valores de los datos dentro de un sistema. Contiene

diagramas de flujo de datos, los cuales representan cálculos o procesamientos. Un

69

diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos

son flujos de datos. El principal elemento del modelo funcional es el proceso.

Un proceso representa una transformación de los valores de los datos. Un

diagrama de flujo de datos completo representa un proceso de alto nivel, el cual

ha sido expandido. Los procesos en este diagrama de flujo pueden ser expandidos

a su vez en procesos de bajo nivel. Eventualmente, esta recursión termina al llegar

a procesos atómicos, los cuales son procesos triviales, tales como el acceso

simple a una variable.

III.1.4 Relación entre los Modelos

Cada uno de los modelos mencionados describen un aspecto de sistema y

contienen referencias a los otros modelos. El modelo de objetos describe la

estructura de datos que es operada por los modelos dinámico y funcional.

Figura 3.1 Relación entre los modelos de OMT

Las operaciones en el modelo objetos corresponden a eventos en el modelo

dinámico y funciones en el modelo funcional. El modelo dinámico describe las

estructuras de control de los objetos. Muestra decisiones que dependen de los

70

valores del objeto y que provocan acciones que a su vez modifican estos valores e

invocan a otras funciones.

El modelo funcional describe las funciones invocadas por las operaciones del

modelo de objetos y las acciones del modelo dinámico, así como restricciones en

los valores de los objetos.

III.2 Proceso de Análisis y Diseño en OMT

OMT es una metodología desarrollada por James Rumbaugh [op. cit] en el

departamento de Investigación y Desarrollo de General Electric, en Nueva York.

Originalmente Rumbaugh desarrolló un lenguaje orientado a objetos llamado DSM

para el cual elaboró también, una notación original que más adelante daría lugar a

OMT.

El proceso de desarrollo orientado a objetos definido por Rumbaugh [Ibid.] se

muestra a continuación:

Figura 3.2 El Proceso de desarrollo de OMT

En la etapa de análisis se debe entender y modelar la aplicación y su dominio. En

la de diseño del sistema se debe determinar la estructura general del sistema en

términos de subsistemas, tareas concurrentes y elementos de almacenamiento de

datos. La etapa de diseño de objetos permite refinar y optimizar el modelo. La

etapa de codificación implica implementar las clases en el lenguaje de

programación seleccionado.

71

Cada fase del proceso transforma algunas entradas en salidas, empezando en el

nivel de abstracción mas alto y continuando en niveles mas detallados hasta el

que finalmente represente la solución del problema.

Así, la etapa de análisis recibe como entradas el conocimiento del dominio de la

aplicación y el enunciado del problema, y produce una primera versión de los

modelos de objetos, dinámico y funcional.

Estos sirven a su vez de entradas a la etapa de diseño, que produce la descripción

de la arquitectura del sistema. Con esta segunda versión de los modelos, la etapa

de diseño de objetos produce versiones detalladas que se usan en la etapa de

codificación.

Rumbaugh sugiere que esta estrategia de desarrollo iterativo empiece con la

implementación de un "esqueleto" mínimo del sistema con la infraestructura

necesaria para implementar un solo caso de uso.

Una vez que esta versión inicial del sistema es totalmente operacional, se le

puede añadir funcionalidad al sistema, en forma incremental.

III.2.1 Análisis

Según explica Rumbaugh [Ibid.] durante esta etapa se busca obtener un modelo

"preciso, conciso, comprensible y correcto del mundo real". El objetivo del análisis

es desarrollar un modelo del funcionamiento de un sistema del mundo real.

El modelo se expresa en términos de objetos y relaciones, el control dinámico de

flujo y las transformaciones funcionales. Para lograrlo, se deben examinar los

requerimientos, abstrayendo primero las características importantes del mundo

real, dejando para etapas posteriores los detalles.

72

El análisis comienza con la definición de un problema generada por el cliente y

que puede ser incompleta e informal. A partir de esta, se escribe una definición

inicial del problema, describiendo lo que se va a hacer, y no como hay que

implementarlo.

Enseguida se construye el modelo de objetos, identificando clases de objetos,

asociaciones entre objetos y atributos de unos y de otras. Usando herencia se

organiza y simplifica la estructura de clases y se agrupan las clases en módulos.

El diagrama de clases se complementa con descripciones textuales, que incluyan

el propósito y el ámbito de la entidad.

El proceso de capturar los requerimientos y consultar con el solicitante debe ser

continuo a través del análisis. A partir de la descripción inicial del problema

(enunciado del problema), se sugiere el siguiente proceso para construir un

modelo de objetos:

• Identificar las clases de objetos.

• Iniciar un diccionario de datos que contenga descripciones de clases, atributos

y asociaciones.

• Agregar asociaciones entre clases.

• Agregar atributos a objetos y ligas.

• Organizar y simplificar las clases de objetos usando herencia.

• Probar las rutas de acceso usando escenarios e iterar los pasos anteriores

según sea necesario.

• Agrupar las clases en módulos, basándose en “acoplamiento cercano” y

función relacionada.

El modelo de objetos esta compuesto por los diagramas del modelo de objetos y el


73

El siguiente paso consiste en elaborar el modelo dinámico, en donde se

representa el comportamiento del sistema y la secuencia de interacciones. Para

esto, se preparan escenarios de secuencias de eventos entre los objetos del

sistema, ya sean típicas o excepcionales; también se identifican los sucesos

externos a los que el sistema debe responder. Para cada objeto activo se

construye un diagrama de estados que mostrará los mensajes que el objeto

recibe, las acciones que lleva a cabo y las respuestas que genere.

El proceso para desarrollar un modelo dinámico comprende:

• Preparar escenarios para las secuencias de interacción típicas.

• Identificar eventos entre objetos y preparar trazos de eventos para cada

escenario.

• Preparar un diagrama de flujo de eventos para el sistema.

• Desarrollar un diagrama de estados para cada clase que tenga un

comportamiento dinámico importante.

• Verificar que los eventos compartidos entre diagramas de estado sean

consistentes y correctos.

El modelo dinámico esta conformado por el diagrama de estado y un diagrama

global de flujo de eventos.

Para construir el modelo funcional, se identifican los valores de entrada y de salida

del sistema como parámetros de sucesos externos. Después se construyen

diagramas de flujo de datos para mostrar como se obtiene cada valor de salida a

partir de los valores de entrada.

El proceso para construir un modelo funcional, incluye:

74

• Identificar valores de entrada y salida.

• Usar diagramas de flujo de datos para mostrar dependencias funcionales.

• Describir las funciones.

• Identificar restricciones.

• Especificar criterios de optimización.

Las partes que conforman el Modelo funcional son: Los diagramas de flujo de

datos y el listado de restricciones.

Este proceso se itera tantas veces como sea necesario, tratando de:

• Agregar al modelo de objetos operaciones clave que sean descubiertas

durante la preparación del modelo funcional. No deben mostrarse todas las

operaciones durante el análisis, sólo las más importantes.

• Verificar que las clases, asociaciones, atributos y operaciones sean

consistentes y completos al nivel seleccionado de abstracción. Comparar los

tres modelos con el enunciado del problema y el conocimiento relevante al

dominio y probar los modelos usando varios escenarios.

• Desarrollar escenarios más detallados (incluyendo condiciones de error) como

variaciones de los escenarios básicos, para verificar aún más los tres modelos.

Como producto final de las etapas de análisis y diseño, se obtienen: el enunciado

del problema, y los diagramas de los modelos de objetos, dinámico y funcional.

III.2.1.1 Casos de Uso

Una forma de describir los requisitos iniciales del usuario, durante la fase de

conceptualización, es construir casos de uso del sistema, descritos inicialmente

75

por Jacobson en 1987 y actualmente incorporados a la mayor parte de las

metodologías de Análisis Orientado a Objetos.

Un caso de uso está formado por una serie de interacciones entre el sistema y un

actor (una entidad externa, ejerciendo un rol determinado), que muestran una

determinada forma de utilizar el sistema. Cada interacción comienza con un

evento inicial que el actor envía al sistema y continua con una serie de eventos

entre el actor, el sistema y posiblemente otros actores involucrados.

Figura 3.3 Casos de Uso

Un caso de uso puede ser descrito en lenguaje natural, mediante trazas de

eventos o mediante diagramas de interacción de objetos.

III.2.2 Diseño

III.2.2.1 Diseño de sistemas.

Al realizar el diseño del sistema se deben tomar decisiones de alto nivel acerca de

la arquitectura total. Durante el diseño del sistema, el sistema objetivo es

organizado en subsistemas basados tanto en la estructura del análisis como en la

arquitectura propuesta. El diseñador del sistema debe decidir que características

de desempeño optimizar, escoger una estrategia para atacar el problema y hacer

asignaciones de recursos tentativas. Por ejemplo, el diseñador del sistema debe

76

decidir que cambios a la pantalla de la estación de trabajo deben ser rápidos y

suaves aún cuando las ventanas sean movidas o borradas, y seleccionar un

protocolo de comunicaciones apropiado y una estrategia de intercambio de

bloques de memoria.

En la etapa de diseño de sistemas, se selecciona la estructura de alto nivel del

sistema. Existen varias arquitecturas canónicas que pueden servir como un punto

de inicio adecuado. El paradigma orientado a objetos no introduce vistas

especiales en el diseño del sistema, pero se incluye para tener una cobertura

completa del proceso de desarrollo de software. Los pasos sugeridos para

concretar esta etapa son:

1. Organizar el sistema en subsistemas.

2. Identificar la concurrencia inherente al problema.

3. Asignar subsistemas a procesadores y tareas.

4. Escoger la estrategia básica para implantar los almacenamientos de datos

en términos de estructuras de datos, archivos y bases de datos.

5. Identificar recursos globales y determinar los mecanismos para controlar su

acceso.

6. Seleccionar un esquema para implantar el control del software:

• Usar la ubicación dentro del programa para mantener el estado,

• implantar directamente una máquina de estado,

• usar tareas concurrentes.

7. Considerar las condiciones de frontera.

8. Establecer prioridades de decisión sobre características deseables del

producto de software.

77

El producto de esta etapa es el documento de diseño de sistema, compuesto por

la descripción de la estructura de la arquitectura básica del sistema y las

decisiones de estrategias de alto nivel.

III.2.2.2 Diseño de objetos.

En esta etapa se construye un modelo de diseño basado en el modelo de análisis

pero conteniendo detalles de implantación. El diseñador agrega detalles al modelo

de diseño de acuerdo con la estrategia establecida durante el diseño del sistema.

El enfoque del diseño de objetos es completar las estructuras de datos y los

algoritmos necesarios para implantar cada clase. Las clases de objetos del

análisis siguen siendo útiles, pero son aumentadas con estructuras de datos y

algoritmos del dominio computacional seleccionadas para optimizar importantes

medidas de desempeño. Tanto los objetos del dominio de la aplicación como los

del dominio computacional, son descritos usando los mismo conceptos y notación

orientados a objetos, aunque existan en diferentes planos conceptuales. Por

ejemplo, las operaciones de la clase Ventana se especifican ahora en términos del

sistema operativo y del hardware subyacente.

Durante esta etapa se elabora el modelo de análisis y se proporciona una base

detallada para la implantación. Se toman las decisiones necesarias para realizar

un sistema sin entrar en los detalles particulares de un lenguaje o base de datos

particular. El diseño de objetos inicia un corrimiento en el enfoque de la orientación

del mundo real del modelo de análisis hacia la orientación en la computadora

requerida para una implantación práctica. Los pasos para concretar esta etapa

son:

1. Obtener las operaciones para el modelo de objetos a partir de los otros

modelos:

• Encontrar una operación para cada proceso en el modelo funcional.

• Definir una operación para cada evento en el modelo dinámico,

dependiendo de la implantación del control.

78

2. Diseñar los algoritmos para implantar las operaciones:

• Escoger los algoritmos que minimicen el costo de implementación

de las operaciones.

• Seleccionar las estructuras de datos apropiadas para los

algoritmos.

• Definir clases internas y operaciones nuevas según sea

necesario.

• Asignar las responsabilidades para las operaciones que no están

asociadas claramente con una sola clase.

3. Optimizar las rutas de acceso a los datos:

• Agregar asociaciones redundantes para minimizar los costos de acceso y

maximizar la conveniencia.

• Reacomodar los cálculos para una mayor eficiencia.

• Guardar los valores derivados para evitar recalcular expresiones complicadas.

4. Implantar el control del software introduciendo el esquema seleccionado

durante el diseño de sistemas.

5. Ajustar la estructura de clases para incrementar la herencia:

• Reacomodar y ajustar las clases y las operaciones para

incrementar la herencia.

• Abstraer el comportamiento común de los grupos de clases.

• Usar delegación para compartir comportamiento donde la

herencia sea semánticamente inválida.

79

6. Diseñar la implantación de las asociaciones:

• Analizar las travesías de las asociaciones.

• Implantar cada asociación como un objeto distinto o agregando atributos

objeto-valor a una o ambas clases en la asociación.

7. Determinar la representación de los atributos de los objetos.

8. Empaquetar las clases y las asociaciones en módulos.

Al finalizar esta etapa se obtienen modelos de objetos, dinámico y funcional,

detallados.

III.3 Patrones de Diseño

La idea detrás de los patrones de diseño es extraer las interacciones de alto nivel

entre objetos y reutilizar sus comportamientos en diferentes aplicaciones. Cada

patrón describe un problema que ocurre una y otra vez en el ambiente de estudio

y la solución a los aspectos fundamentales del problema. De esta forma, se puede

aplicar esta solución una y otra vez al mismo tipo de problema, a pesar de que los

detalles de estos sean diferentes entre sí.

III.3.1 Qué son los patrones

En el desarrollo de software, el término patrón se refiere (según la definición que

aparece en www.whatis.com) a "un documento escrito que describe una solución

general a un problema de diseño que se presenta en forma recurrente en

diferentes proyectos". Los patrones describen el problema de diseño, la solución

propuesta y cualquier factor que pueda afectar al problema o su solución.

80

Como señala [Tidwell, 2002] "los patrones pueden considerarse descripciones de

'las mejores prácticas' de un cierto dominio de diseño. Registran soluciones

comunes a las dificultades de diseño,.. aunque cada implementación de un patrón

es diferente de las otras." Además, los patrones "permiten a los programas (y a los

programadores) compartir su conocimiento sobre diseño" [Korgaonkar, 2002].

Una característica importante de los patrones es que pueden estar anidados: Un

patrón solución puede tener cualquier tamaño; las soluciones a las diferentes

partes del problema serían en este caso, patrones más específicos.

El propósito de usar patrones es codificar el conocimiento de diseño existente, "a

fin de que los desarrolladores no estén constantemente reinventando la rueda"

[Strunk, 1999]; dar nombre a los patrones facilita la comunicación entre los

desarrolladores.

Se dice que el concepto de usar patrones comunes para resolver problemas

similares se originó en el campo de la arquitectura, con el trabajo del Arquitecto

Christopher Alexander, "A pattern Language: Towns, Buildings, Construction", en

1977 [Tidwell, 2002].

El uso de patrones permite a los diseñadores de software adaptar la solución

indicada en el patrón a su proyecto específico.

Los patrones de diseño incluyen los siguientes tipos de información:

• Un nombre, que describe al patrón

• La descripción del problema que se resuelve

• El contexto en el que ocurre el problema

• Solución propuesta

81

• Contexto de la solución

• Ejemplos y descripciones de casos de éxito y fracaso del modelo

• Usos que se le puede dar y patrones relacionados

• Autor y fecha

• Referencias y palabras clave sobre el contenido

• Código ejemplo de alguna solución, si fuera necesario.

El patrón no puede estar definido en términos de una implementación particular, ni

de un algoritmo o una estructura de datos, y se le debe considerar como una

parte del análisis y el diseño del sistema.

III.3.1.1 Ventajas de los patrones de diseño.

En la programación orientada a objetos un patrón puede contener la descripción

de ciertos objetos y clases de objetos que van a ser usadas, así como sus

atributos y dependencias y una descripción aproximada y general de la forma en

que se debe resolver el problema.

Existen una infinidad de posibilidades en las que se puede implementar la solución

a un determinado problema, y aunque los modelos de objetos bien planeados

deben ser lógicos, robustos, fáciles de mantener y reusables, difícilmente pueden

adaptarse a los cambios en complejidad o tamaño del sistema. Es responsabilidad

del desarrollador tomar decisiones que aseguren la calidad del software, y los

patrones sirven para formalizar estos principios.

En el presente trabajo se va a usar un patrón de diseño, por que, como comenta

[Coplien, 2002], muestra la forma en que se puede solucionar un problema (no

principios abstractos, sino una solución concreta, un concepto que ya ha sido

probado) .

82

III.3.2 Patrón Modelo Vista Controlador

El patrón Modelo Vista Controlador (MVC) es un patrón de diseño clásico,

comúnmente usado por aplicaciones que necesitan mantener diferentes vistas de

los mismos datos. Permite separar el objeto de la aplicación (modelo) de la forma

en que se le presenta al usuario (vista) y de la forma en que el usuario lo controla

(controlador).

Gracias a esto, el Modelo Vista Controlador facilita una clara separación de los

objetos en alguna de las tres categorías: modelos que mantienen datos, vistas que

los despliegan y controladores que manipulan los eventos que afectan el modelo o

la(s) vista(s). Gracias a esta separación, diferentes vistas y controladores pueden

interactuar con el mismo modelo. Incluso se pueden crear nuevas vistas o

controladores que interactúen con el modelo sin que se deba cambiar el diseño de

este.

La arquitectura Modelo Vista Controlador (Model/View/Controller) fue introducida

como parte de la versión Smalltalk-80 del lenguaje de programación Smalltalk. Fue

diseñada para reducir el esfuerzo de programación necesario en la

implementación de sistemas múltiples y sincronizados de los mismos datos. Sus

características principales son que el Modelo, las Vistas y los Controladores se

tratan como entidades separadas; esto hace que cualquier cambio producido en el

Modelo se refleje automáticamente en cada una de las Vistas.

83

Figura 3.4 Modelo Vista Controlador

En la figura siguiente, vemos la arquitectura Modelo Vista Controlador en su forma

más general. Hay un Modelo, múltiples Controladores que manipulan ese Modelo,

y hay varias Vistas de los datos del Modelo, que cambian cuando cambia el

estado de ese Modelo.

Figura 3.5 Un solo Modelo puede tener varias vistas y controladores

Este modelo de arquitectura presenta varias ventajas:

• Una clara separación entre los componentes de un programa; lo cual

permite implementarlos por separado

84

• Una Interfaz de Programación de Aplicaciones muy bien definida.

• La conexión entre el Modelo y sus Vistas es dinámica; se produce en

tiempo de ejecución, no en tiempo de compilación.

Al incorporar el Patrón Modelo Vista Controlador a un diseño, las piezas de un

programa se pueden construir por separado y luego unirlas en tiempo de

ejecución. Si más adelante se determina que alguno de los Componentes funciona

mal, puede reemplazarse sin que las otras piezas se vean afectadas.

Bajo este concepto, un programa puede dividirse en dos partes:

1. El Modelo: es la parte interna del programa, en donde ocurre el procesamiento

de los datos.

2. La Vista: constituye la parte del programa que se encarga de la interacción con

el usuario

La vista toma las entradas del usuario y pasa la información al modelo. El modelo

envía información a la vista, para que se la muestre al usuario.

Para evitar un acoplamiento muy estrecho entre vista y modelo, este debe operar

en forma totalmente independiente de la forma en que la vista interactúe con el

usuario, y esta debe satisfacer las necesidades del usuario, independientemente

de aquel.

Las implicaciones de estas afirmaciones son:

1. La interfaz de entrada / salida del modelo no necesariamente equivale a la

interfaz de entrada / salida de la vista.

2. Un modelo puede trabajar con diferentes vistas.

3. Una vista puede trabajar con diferentes modelos.

85

4. En general, para que un modelo y una vista se puedan comunicar, se requiere

un objeto "adaptador" que traduzca la salida de uno en la entrada del otro.

5. Ni el modelo ni la vista son capaces de crear el adaptador que los conecte, por

que son entes totalmente independientes.

Por tanto, se hace necesario un componente adicional: el Controlador. Este

controlador conoce el modelo y la vista específicos que se usan para resolver el

problema, y su función es:

1. Crear las instancias de la vista y el modelo

2. Crear la(s) instancia(s) del(de los) adaptador(es) usados para comunicar al

modelo con la vista.

3. Establecer la comunicación del adaptador con la vista, y del adaptador con el

modelo.

En resumen: en el Patrón de Diseño Modelo Vista Controlador las entradas del

usuario, el modelo de problema y la retroalimentación visual al usuario están

separadas y son manipuladas por tres tipos de objetos cada uno altamente

especializado en su tarea:

El Modelo es el objeto que representa los datos del programa. Maneja los datos y

controla todas sus transformaciones. El Modelo no tiene conocimiento específico

de los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el

propio sistema el que tiene encomendada la responsabilidad de mantener enlaces

entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo.

La Vista es el objeto que maneja la presentación visual de los datos representados

por el Modelo. Genera una representación visual del Modelo y muestra los datos al

usuario. Interactúa con el Modelo a través de una referencia al propio Modelo.

86

El Controlador es el objeto que proporciona significado a las ordenes del usuario,

actuando sobre los datos representados por el Modelo. Cuando se realiza algún

cambio, entra en acción, bien sea por cambios en la información del Modelo o por

alteraciones de la Vista. Interactúa con el Modelo a través de una referencia al

propio Modelo.

La arquitectura resultante se muestra en el siguiente diagrama. Las

implementaciones tradicionales del Patrón Modelo Vista Controlador separan el

modelo en capas con una cierta dependencia entre sí. Mientras las vistas y

controladores son genéricos, la capa del modelo de la aplicación (llamada "de

herramientas" en el diagrama) es específica del negocio.

Figura 3.6 Arquitectura de Modelo Vista Controlador

87

III.3.2.1 Modelo Vista Controlador y desarrollo para Palm.

Se espera que los programas desarrollados para la plataforma Palm funcionen,

independientemente de las características físicas del dispositivo (tamaño de la

pantalla, presencia de color, método de entrada de datos). Esto implica que el

Modelo (la parte del programa encargada de realizar cálculos, obtener datos de

archivos, etc.) debe ser totalmente independiente de la interfaz de usuario (la

Vista)

Al tratarse de aplicaciones orientadas a eventos (generados por el usuario, por el

sistema operativo, etc.) se hace necesario el Controlador, quien será el encargado

de procesar los eventos, ordenar el procesamiento de los datos al Modelo e

indicar a la vista que muestre o lea información.

III.4 Restricciones dadas por la plataforma

Como se muestra a continuación, existen una gran variedad de PDAs, de

diferentes marcas. La lista que se presenta no pretende ser una referencia

completa, sino dar una idea de la gran cantidad de dispositivos disponibles en el

mercado.

Fabricante Modelo Fabricante Modelo

Cassio Cassiopeia EM-500G Palm Inc. Palm III

Cassiopeia EM-505S Palm IIIc

Cassiopeia e-125 Pocket PC Palm IIIe

Compaq iPAQ 3660 Palm IIIx

iPAQ 3760 Palm IIIxe

iPAQ 3830 Palm V

iPAQ 3850 Palm Vx

iPAQ 3870 Palm VII

iPAQ 3950 Palm M 100

iPAQ 3970 Pocket PC Palm M105

iPAQ H3630 Pocket PC Palm m125

iPAQ - H3850 Pocket PC Palm m130

Tabla 3.1 Lista de Modelos de PDAs por Fabricante

88

Fabricante Modelo Fabricante Modelo

Dell Axim X5 Standard 300MHz Palm Inc. Palm m500

Ericsson MC218 Palm M505

Treo Handera 330 Palm m515

Handspring Treo 270 Psion Psion Revo

Handspring Visor Psion Series 3a

Handspring Visor Edge Psion Series 5

Hitachi Eplate 600 et Psion Psion Series 5mx

HP 200lx Psion Series 7

Jornada 525 pocket pc Sagem WA 3050

Jornada 545 Sony Sony Clie PEG N770C

Jornada 545/548 Sony Clie PEG S300

Jornada 568 64MB

Pocket PC

Sony Clie PEG-SJ30

Jornada 720 PDA Sony Clie PEG-T425

IBM WORKPAD Z50 Sony Clie PEG-T625C

Sony NR70VG

Sony T625c

Toshiba Pocket PC e570

Tabla 3.1 (cont.) Lista de Modelos de PDAs por Fabricante

89

III.4.1 Los distintos modelos de Palm

Dentro de la gama de dispositivos fabricados por Palm Inc. hay diferencias mas o

menos importantes, en cuanto a capacidad, tamaño físico del dispositivo, etc.

Algunas de estas características se enlistan en la siguiente tabla.

Tabla 3.2. Comparación entre los modelos de Palm Inc.

Tungsten T Zire m515 m130 m125 m100 m105

Peso 157 gr. 109 gr. 139 gr. 124 gr. 124 Gr. 124 Gr. 124 Gr.

Memoria 16 Mb 2 Mb 16 Mb 8 Mb 8 Mb 2 Mb 8 Mb

Palm OS 5 4.1 4.1 4.1 4 3.5 3.5

Tamaño 10.2 x 7.5 x 1.5

cm

11.2 x 7.4 x 1.6

cm

11,4 x 7,9 x 12,7

cm.

4.66" x 3.12" x

0.72"

4.66" x 3.12" x

0.72"

4.66" x 3.12" x

0.72"

4.66" x 3.12" x

0.72"

Vibrador si no si no no no no

Memoria Flash si no si no no no no

Pantalla Alta resolución.

65.536 colores.

Monocroma 65.000 colores 65.000 colores escala de grises escala de grises escala de grises

Direcciones 20,000 6,000 20,000 10,000 10,000 6,000 10,000

Citas 10 años 5 años 10 años 5 años 5 años 5 años 5 años

Agenda 6,000 1,500 6,000 3,000 3,000 1,500 3,000

Memos 6,000 1,500 6,000 3,000 3,000 1,500 3,000

E-mail 800 200 800 400 400 200 400

Capacidad para

agregar

aplicaciones

Juegos, ebooks,

datos y mucho

más...

Juegos, ebooks,

datos y mucho

más...

Juegos, ebooks,

datos y mucho

más...

Juegos, ebooks,

datos y mucho

más...

Juegos, ebooks,

datos y mucho

más...

Juegos, ebooks,

datos y mucho

más...

Juegos, ebooks,

datos y mucho

más...

Tipo Recargable litio-

ion

Recargable litio-

ion

Recargable litio-

ion

Recargable litio-

ion

AAA AAA AAA

Vida (uso normal) 1 semana 1 mes 1 mes 1 mes 2 meses 2 meses 2 meses

Comunicación vía

puerto serial

si. Tiene Slot

para tarjetas de

expansión.

si si. Tiene Slot

para tarjetas de

expansión.

si. Tiene Slot

para tarjetas de

expansión.

si. Tiene Slot

para tarjetas de

expansión.

si si

Infrarrojo si si si si si si si

90

III.4.2 Características generales de las computadoras de mano,

independientemente de la marca.

No todos los dispositivos mencionados usan el PalmOS como su sistema

operativo nativo. Al final del capítulo, la tabla 3.2 compara las características de

algunos de los equipos que manejan PalmOS (modelos del Palm Inc. y otros),

contra computadoras de mano (handhelds) que usan otros sistemas operativos y

contra un equipo PC de escritorio Típico.

III.4.3 Comentarios Finales

Los programas para dispositivos Palm basan su funcionamiento en el uso de

formas. El usuario interactúa con estas formas para alimentar datos y recibir

mensajes de la aplicación; por otro lado, la aplicación recibe las entradas del

usuario, las procesa y genera distintos tipos de mensajes de salida. De acuerdo a

lo explicado previamente en este capítulo, este esquema corresponde al del

Patrón de diseño Modelo Vista Controlador.

Sin embargo, tomando en cuenta también las características del hardware y el

sistema operativo, se puede establecer que las clases que se desarrollen para

manipular la interfaz con el usuario, serán exactamente las mismas

independientemente del sistema que se este desarrollando. El sistema operativo

de la Palm ofrece un conjunto finito de controles a partir de los que se construyen

las diferentes pantallas que el sistema pueda necesitar. Como este conjunto de

controles no puede cambiarse, no es aventurado afirmar que el análisis y diseño

de la Interfaz con el usuario se pueden hacer una sola vez, y aplicarse siempre, en

cualquier desarrollo posterior.

Tabla 3.3 Comparación de modelos de Handhelds contra una PC

Fabricante Modelo Precio

estimado

Máximo

(U$)

Memoria

RAM

Instalada

Capacidad

de

Expansión

Procesador Velocidad

del

Procesador

Método de

sincronizaci

ón

Tipo de

Sistema

Operativo

Versión del

Sistema

Operativo

Capacidad

para

actualizar

el

Sistema

Operativo

Tipo de

Pantalla

Resolución

de la

Pantalla

Area útil

de la

pantalla

(pulgadas

cuadradas)

Profundida

d

de

color

Blackberry H1100 $499 5M No Intel 386 N/D Serial,

Infrarrojo

BlackBerry N/D N/D Monocrom

o

160 x 160 7 N/D

Casio Cassiopeia

E-105

$479 32M Compact

Flash

NEC 131 MHz Infrarrojo,

Serial

Pocket PC Windows

CE 2.1

N/D Color 240 x 320 3.9 16 bits

Compaq iPaq

H3850

$604 64MB Secure

Digital

Intel

StrongARM

206 MHz Infrarrojo,

USB

Pocket PC Pocket PC

2002

Si Color 240 x 320 3.77 16 bits

Diamond Mako $149 16MB No ARM 710 T

RISC

36 MHz Infrarrojo,

Serial

EPOC EPOC R5 Si Monocrom

o

240 x 320 7.4 N/D

Handspring Treo 180 $499 16MB No Motorola

Dragonball

VZ

33 MHz USB Palm OS 3.5.2 o

superior

Si Monocrom

o

160 x 160 3 N/D

Visor $92 2MB Springboar

d

Motorola

Dragonball

EZ

16 MHz Infrarrojo,

USB

Palm OS 3.1 Si Monocrom

o

160 x 160 3.1 N/D

Visor

Deluxe

$109 8MB Springboar

d

Motorola

Dragonball

EZ

16 MHz Infrarrojo,

USB


o

160 x 160 3.1 N/D

Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)

Fabricante Modelo Precio

estimado

Máximo

(U$)

Memoria

RAM

Instalada

Capacidad

de

Expansión

Procesador Velocidad

del

Procesador

Método de

sincronizaci

ón

Tipo de

Sistema

Operativo

Versión del

Sistema

Operativo

Capacidad

para

actualizar

el

Sistema

Operativo

Tipo de

Pantalla

Resolución

de la

Pantalla

Area útil

de la

pantalla

(pulgadas

cuadradas)

Profundida

d

De

color

HP Jornada

720

$833 32MB Tarjeta PC,

Compact

Flash

StrongARM

RISC

206 MHz Infrarrojo,

serial, USB

Pocket PC Windows

para

Handheld

PC 2000

Si Color 640 x 240 6.5 16 bits

Palm Tungsten T $499 16MB MultiMedia

Card,

SmartMedi

a

Texas

Instruments

OMAP

1510

N/D Infrarrojo,

USB

Palm OS 5 Si Color 320 x 320 N/D 16 bits

m100 $93 2MB No Motorola

Dragonball

EZ

16 MHz Infrarrojo,

serial


o

160 x 160 3.3 N/D

Palm IIIc $88 8MB No Motorola

Dragonball

EZ

20MHz Infrarrojo,

serial

Palm OS 3.5 Si Color 160 x 160 4.1 8 bits

Sony CLIE PEG-

SL10

$150 8MB Memory

Stick

N/D N/D USB Palm OS 4.1 Si Monocrom

o

160 x 160 4.1 N/D

PC

ACER Aspire

G600 p

A partir de

$800

hasta 3 GB Si Intel 2.4 a 2.8

GHz

N/A Opcional

(Windows)

Si Color 1600 x

1200

350 x 262

mm


Fabricante Modelo Tipo de

Baterías (1)

Duración

estimada

(hrs)

Soporte a

tecnología

Bluetooth

Tamaño

(Alto, Largo, Ancho)

en pulgadas

Peso

(onzas)

Características Adicionales

Blackberry H1100 Recargable 7 No 4.6 x 3.1 x 0.7 5.3 Bocina

Casio Cassiopeia E-

105

Recargable (2) 6 No 5 x 3.3 x 0.7 9 Entrada para audífonos, microfono, entrada para tarjeta

multimedia, batería de respaldo

Compaq IPaq H3850 Recargable 10 No 5.1 x 3.3 x 0.6 6.3 Entrada para audífonos, mícrofono, software multimedia

Diamond Mako Recargable (3) 12 No 3.1 x 6.2 x 0.7 7 Bocina

Handspring Treo 180 Recargable 60 No 2.7 x 4.3 x 0.7 5.2 Microfono

Visor AAA (4) 60 No 4.8 x 3.0 x 0.7 5.4 Bocina

Visor Deluxe AAA (4) 60 No 4.8 x 3.0 x 0.7 5.4 Bocina

HP Jornada 720 Recargable 9 No 7.4 x 3.7 x 1.3 17 Entrada para audífonos, micrófono.

Palm Tungsten T Recargable N/D Si 4.0 x 3.0 x 0.6 5.6 Bocina estéreo

m100 AAA (4) 60 No 4.7 x 3.1 x 0.7 4.4 Bocina

IIIc Recargable 30 No 5.1 x 3.2 x 0.7 6.8 Bocina

Sony CLIE PEG-

SL10

AAA N/D No 4.6 x 2.8 x 0.6 3.6 Software multimedia


PC

ACER Aspire G600 p N/A N/A N/D 452mm x 180mm x 417mm N/D CD-Lectura/Escritura, DVD, puertos serie, paralelo, USB, entrada

para audífonos, micrófono

(1) A menos que se indique otra cosa, todos los modelos vienen con batería de ion litio(2) La batería recargable se puede remover y reemplazar.(3) Niquel-metal hidruro.(4) Requiere dos baterías AAA.N/D Dato no disponibleN/A No aplica

CAPITULO IV

CASO DE ESTUDIO: SVES

96

IV.1 Sistemas de Apoyo en la toma de decisiones

Los sistemas de apoyo para la toma de decisiones tienen muchas características

que los hacen diferentes a otros sistemas tradicionales.

Un sistema de apoyo para la toma de decisiones es un instrumento que sirve para

organizar información que será usada en algún proceso de toma de decisiones.

Presenta la información requerida por el usuario y eventualmente sugiere la mejor

solución, de acuerdo a los parámetros con los que fue programado.

[ Kendall, 1991] dice: "Un sistema de apoyo para la toma de decisiones permite

que el tomador de decisiones se relacione de una manera natural con la

información por medio de un diseño cuidadoso de la interfaz con el usuario...

Puede construirse para apoyar decisiones que se toman una sola vez, o aquellas

que son poco frecuentes, o bien aquellas que ocurren de manera rutinaria.

Un sistema de apoyo para la toma de decisiones se puede diseñar para una

persona en particular, o bien para un grupo de tomadores de decisiones. Esto

permite que el diseñador del sistema estandarice características básicas del

sistema para adaptarlo al tipo de representaciones (gráficas, tablas, diagramas,

etc.) e interfaces que el usuario comprenda mejor.

La forma de recopilar, procesar y utilizar la información define los parámetros del

estilo de toma de decisiones. La toma de decisiones analítica se basa en

información que se adquiere y evalúa de manera sistemática para reducir las

alternativas y elegir con base en tal información. El tomador de decisiones

97

analítico aprende a analizar situaciones particulares. Existen procedimientos

definidos paso a paso para efectuar la decisión, y se hace uso de las matemáticas

para modelar los problemas. Adicionalmente, puede involucrar el uso de una base

de datos para almacenar información estadística o histórica.

IV.1.1 Proceso general de toma de decisiones

El diagrama de la Figura 4.1 sugiere un procedimiento para la toma de decisiones.

Como señala [Landsberger, 2002 ], los pasos difícilmente se pueden seguir en

forma secuencial, ya que normalmente se traslapan, y eventualmente habrá que

retomar pasos previos, o trabajar simultáneamente en varios de ellos hasta

encontrar la mejor solución al problema.

Figura 4.1 Proceso de toma de decisiones.

[Landsberg, op. cit.] indica también que una mala definición del problema suele ser

la causa de que no se llegue a solucionar totalmente el mismo, por lo que, en caso

de que el problema no se encuentre bien definido, se deben considerar los

objetivos que se espera cumplir y los eventuales obstáculos que se puedan

presentar.

98

Para obtener información se debe acudir en primer lugar, a los individuos, grupos

u organizaciones afectadas por el problema o su solución. Enseguida, se deben

buscar resultados de investigaciones, estudios y experimentos ya existentes,

además de entrevistar a los expertos en el área de estudio y demás fuentes

confiables de información. Así mismo, se deben determinar las restricciones y

tomar en cuenta las opiniones de aquellos individuos que influirán en la solución

del problema.

El siguiente paso consiste en tratar de estudiar el problema desde diferentes

perspectivas, tratando de encontrar posibles soluciones alternativas. Todas las

alternativas encontradas deben ser evaluadas. Por otro lado, se debe considerar si

la alternativa es ética y/o práctica, si se cuenta con los recursos necesarios para

llevarla a cabo, cual es su probabilidad estimada de éxito, etc. Para seleccionar la

mejor, se deben evitar las "soluciones perfectas" ya que este tipo de soluciones

implican que en realidad no existía un problema.

Landsberg [Ibid.] afirma que, mientras no se implementa, cualquier solución es

solo una buena intención. Para llevar a cabo la implementación de cualquier

solución, se debe desarrollar un plan que considere cada paso o acción que se

debe efectuar, las estrategias de comunicación que se establecerán con los

expertos, la distribución de los recursos identificados y el tiempo del que se

dispone. Pero la implementación será exitosa solo si se realiza un monitoreo

constante del progreso de la solución y sus efectos . Si no se esta alcanzando el

objetivo esperado, se deben reconsiderar las opciones y la alternativa elegida.

IV.1.2 Sistemas de diagnóstico médico.

El diagnóstico es y será el problema mas importante en la medicina y los sistemas

de soporte de decisiones para diagnóstico médico jugarán un papel cada vez mas

99

importante en el cuidado de la salud, mejorando la calidad y eficiencia del proceso

de diagnóstico.

Para elaborar un sistema experto de diagnóstico médico, se parte de los

exámenes médicos (examinación física, pruebas de laboratorio, etc.) de pacientes

de los centros de diagnóstico modernos. Con ellos se recaba una gran cantidad de

información inicial.

Si cada uno de estos datos se mide usando solo las escalas mas simples (“si-no”,

“mas-menos”) se obtendrían cantidades de información muy difíciles de manipular.

Debido a la imposibilidad de manipular tal cantidad de información, se han

desarrollado sistemas expertos (programas de computadora que imitan el

pensamiento del experto en algún campo del conocimiento) que incorporan el

conocimiento formal de los médicos y son capaces de tomar decisiones en la

misma forma en la que un ser humano lo haría.

La eficiencia en la operación de un sistema experto depende en primer lugar de la

cantidad y calidad de la información disponible en la base de datos de

conocimientos. Esto es un punto débil de los sistemas expertos porque la base de

conocimientos esta basada en ideas subjetivas de expertos cuyo conocimiento es

limitado y quienes en ocasiones no son capaces de formalizar su experiencia

presentándola como reglas claras.

IV.1.2.1 Perspectiva Histórica

El interés de la humanidad en dar soporte a las decisiones medicas y establecer

guías de apoyo a los médicos se puede rastrear hasta el año 650 a.C. en

Babilonia. Existen escritos cuneiformes de esa época que sugieren exámenes

médicos, diagnósticos y prognosis de enfermedades:

100

"Cuando usted se prepare para examinar a un hombre enfermo..."

"Si después de un día de enfermedad, él empieza a sufrir dolor de cabeza..."

En la época moderna, se reconoce que las computadoras pueden apoyar al

médico en los procesos de diagnóstico y terapéutico.

A finales de la década de los 50s, aparecen artículos que exploran esta

probabilidad: “Ledley y Lusted publican su artículo clásico ‘Reasoning Foundations

of Medical Diagnosis’ al que siguió la primera generación de sistemas que trataban

de apoyar al médico en la toma de decisiones" [Federhofer, 2002].

IV.1.2.2 Sistemas Expertos

Un sistema experto es un programa que trata de imitar la experiencia de un

humano aplicando métodos de inferencia a un campo específico del conocimiento

llamado dominio. Al principio de la década de los 70s, con el desarrollo del área de

la Inteligencia Artificial, fue posible desarrollar sistemas expertos que podían

manejar conocimiento médico incierto o incompleto.

Las herramientas de software médico emergen durante la década de los 80's. En

los últimos tiempos se ha observado un enorme desarrollo en los Sistemas

Expertos Médicos, y los sistemas disponibles actualmente son suficientemente

maduros como para permitir su adopción en la práctica médica [Ibid.]

El caso mejor conocido es MYCIN, un sistema experto que fue desarrollado en la

Universidad de Stanford en 1976 con el fin de ayudar a los médicos en el

diagnóstico y tratamiento de pacientes con enfermedades infecciosas en la

sangre, mismas que pueden ser fatales si no reconocen y tratan a tiempo.

101

Otro ejemplo notable es PUFF, un sistema experto que diagnostica la presencia

de enfermedades severas en el hígado. El Brain Tumors Diagnostic System

(BTDS) es otro sistema experto que ayuda a los médicos a diagnosticar tumores

cerebrales. BTSD esta conformado por un sistema experto y un sistema de

aprendizaje.

IV.1.2.3 Funcionamiento de los sistemas de diagnóstico medico

Los sistemas de diagnóstico ofrecen al médico preguntas y respuestas

estructuradas dentro de un dominio de conocimiento especializado. La estructura

es programada con la supervisión de uno o más expertos médicos, quienes

también sugieren las mejores preguntas y ofrecen las mejores conclusiones que

se pueden obtener a partir de las respuestas obtenidas. En términos de

programación, estas secuencias de decisión se representan con cláusulas "If...,

Then..., Else..." ("Si..., entonces..., si no...")

En general un sistema experto de diagnóstico medico funcionaría como se explica

a continuación:

Una combinación de signos, síntomas y resultados de laboratorio, se compara

contra una base de datos de condiciones médicas bien conocidas. Esta

comparación se hace usando inteligencia artificial, reconocimiento de patrones y

otras técnicas matemáticas. Además, se aplican reglas derivadas del conocimiento

de los expertos a fin de depurar los resultados y llegar a un diagnóstico probable.

IV.1.2.4 Ejemplo

Considérese, el siguiente escenario:

Un paciente X se presenta ante un medico, o un auxiliar quejándose de un fuerte

dolor de cabeza, fiebre y dolor muscular.

102

Una pequeña fracción del conocimiento de los expertos, se ha resumido en la

siguiente tabla:

Síntoma Síntoma Síntoma

Dolor de cabeza Dolor de cabeza Dolor de cabeza

Calentura Calentura Mareo

Dolor Muscular Dolor Muscular

Tos

Dolor de garganta

Padecimiento probable:

Catarro


Dengue


Presión Alta

Tabla 4.2 Conocimiento del experto médico, resumido en una tabla.

Consultando la tabla se puede ver que la sintomatología indicada por el paciente

no corresponde a la de un probable catarro (ya que no menciona tener tos ni dolor

de garganta); sin embargo, si se podría sospechar un posible caso de Dengue, o

de Presión Alta.

IV.2 Antecedentes del Sistema de Vigilancia Epidemiológica

La información que aparece a continuación fue tomada del documento: Manual

para la Vigilancia Epidemiológica Simplificada, editado por la Secretaría de Salud.

El ejercicio de la salud pública como elemento indispensable para alcanzar el

desarrollo integral de los individuos, la familia y la comunidad representa una

preocupación constante de especial prioridad y sin lugar a dudas requiere de un

mayor impulso dentro de la sociedad. En la actualidad aun persisten graves

desigualdades y problemas epidemiológicos fundamentales, los cuales afectan de

103

manera importante a grandes grupos de población, especialmente a quienes no

tienen acceso a servicios de salud.

Es necesario establecer un orden prioridades principalmente en donde se trabaje

con escasos recursos: humanos, materiales, financieros y tecnológicos; es preciso

seleccionar métodos de intervención mas adecuados, aplicar tecnologías y

modelos de atención apropiados que respondan a las necesidades presentes y

futuras de la población.

Es aquí donde adquieren su verdadera dimensión los mecanismos de información

en salud, ya que para establecer prioridades y tomar decisiones adecuadas en

tono a la prestación de los servicios, es indispensable contar con los elementos de

diagnostico que permitan conocer y evaluar los daños a la salud, así como los

diversos factores de riesgo que intervienen en su distribución y frecuencia. Los

sistemas de información se constituyen así en un componente esencial de alto

valor técnico e importancia estratégica en el campo de la salud y la administración

de los servicios de esta, especialmente por su utilidad para conformar el

diagnóstico de salud de la comunidad e identificar los problemas epidemiológicos

de mayor prioridad, los grupos y situaciones de alto riesgo, además por su

contribución a la evaluación y monitoreo de los servicios y programas de salud.

Desafortunadamente, la información en salud no siempre se encuentra disponible

y, aunque parece relativamente abundante en algunos sectores, es escasa,

inoportuna y de muy baja calidad en otros, como algunas áreas ampliativas en las

jurisdicciones; en el propio nivel comunitario, dado su menor adelanto, llegan a

tenerse serias limitaciones para contar con el personal intermedio debidamente

capacitado para organizar, de manera oportuna y ágil, la producción, análisis y

utilización de los datos y, en general, para cumplir con las funciones específicas

en materia de información y vigilancia epidemiológica.

104

Es muy frecuente encontrar situaciones en donde es prácticamente imposible

obtener una cobertura universal de la información. Por esta razón y para reducir

estas inconveniencias, fueron ideadas y propuestas modernas y efectivas técnicas

por muestreo, además de formas de investigación complementaria, que sin

embargo, resultan insuficientes para generar el conocimiento básico sobre

situaciones especiales de interés epidemiológico, demográfico y de servicios de

salud.

De este modo, los métodos no convencionales de información para la salud

representan una alternativa de corto plazo en situaciones en las que existe una

importante carencia de información y en donde el conocimiento de los problemas

epidemiológicos no siempre es un insumo para el desarrollo de la salud

comunitaria.

Por ello, desde 1954 y en especial en los últimos años, diversos países y

organizaciones se han dado a la tarea de enseñar e impulsar el uso alternativo de

métodos no convencionales de información, dentro de ellos las técnicas de

registro y notificación epidemiológica basadas en la comunidad, que permiten

llenar los vacíos de información al interior de los sistemas de estadísticas vitales

y de salud, en particular en áreas geográficas donde existen restricciones o

rezagos considerables.

Destacan a este respecto las experiencias de algunos países latinoamericanos,

entre ellos México, que han utilizado entre otras alternativas de tipo no

convencionales las técnicas de Lay Reporting o Informes de Salud de Legos, que

en general son aplicadas al reforzamiento de los sistemas de estadísticas vitales y

de vigilancia epidemiológica, a la determinación complementaria del estado de

salud de la población y a la identificación de necesidades a nivel de la comunidad.

En términos más específicos, han sido aplicados al registro de la mortalidad

general, la mortalidad materno-infantil, la vigilancia epidemiológica de algunas

105

enfermedades transmisibles y la desnutrición, así como al registro de hechos

vitales y de servicios básicos de salud. De igual manera, han sido utilizados en las

tareas de monitoreo y evaluación de las condiciones de saneamiento básico y del

ambiente en general.

Los métodos de información comunitaria han recibido a últimas fechas más

atención de la Organización Mundial de la Salud, quien ha elaborado y difundido

un sistema de información de salud, con participación de personal no médico, que

incluye la utilización de una lista mínima detallada de causas tanto de morbilidad

como de mortalidad.

IV.3 Sistema de vigilancia epidemiológica

La vigilancia epidemiológica enfoca sus esfuerzos a la recolección sistemática de

la información, su análisis y diseminación; para guiar los programas de prevención

y control de las enfermedades con mayor impacto sobre la salud de la población.

La vigilancia epidemiológica permite estimar la magnitud de un problema de salud

pública, documentar su distribución y propagación, describir su historia natural e

identificar la aplicación de los fenómenos epidemiológicos que afectan a la

población.

Los atributos más importantes de un sistema de vigilancia epidemiológica son:

a) simple en su estructura

b) representativo de la población a la que sirve

c) aceptado por los usuarios

d) flexible para la incorporación de nuevos datos cuando sea necesario

e) oportuno en la captación y diseminación de la información

106

IV.3.1 Sistemas no convencionales de Información

Desde finales de la década de los 70, varios países han experimentado con la

recolección de información por personal no médico (lego); este tipo de recolección

(lay reporting) ha sido subsecuentemente extendido a un concepto amplio

denominado "métodos no convencionales de información". En diferentes países,

estos métodos, que cubren una variedad de enfoques, han evolucionado como

medios de obtener información acerca del estado de salud de la población donde

los métodos convencionales (censos, encuestas, estadísticas vitales y estadísticas

de morbilidad) han resultado inadecuados o no existen.

Uno de estos enfoques, denominado "información basada en la comunidad"

implica la participación de la comunidad en la definición, recolección y utilización

de la información relacionada con la salud. El grado de participación de la

comunidad va desde el trabajo de recolección de los datos solamente, hasta el

diseño, análisis y la utilización de la información.

Los métodos no convencionales de información en salud pueden ser definidos

como un conjunto de técnicas y procedimientos de carácter complementario y que

permiten analizar la información básica sobre los problemas de salud, problemas

para los cuales no se cuenta con la infraestructura ni tecnología apropiadas que

satisfagan las necesidades de información de los sistemas formales de salud.

En 1976, la OMS detalló una lista de asociación de síntomas, susceptibles de

reconocer por personal de servicios de salud primarios (esto es, quienes no están

médicamente calificados por los estándares comúnmente aceptados) e indicativos

de condiciones que son importantes problemas de salud en varias partes del

mundo. De esta lista detallada derivaron dos listas, una para causas de muerte y

otra de razones para contacto con servicios de salud.

107

Los propósitos de la información de salud colectada son: alertar a las autoridades

de salud para la emergencia de un problema de salud y facilitar el manejo de

cuidados de salud primarios. Los datos colectados deben ser analizados y

reportados hacia el siguiente eslabón administrativo.

IV.3.2 Aspectos epidemiológicos

El panorama epidemiológico en México está constituido por tres configuraciones:

1. La primera, por el predominio de las enfermedades cardiovasculares,

de las crónico-degenerativas, los accidentes, además de problemas

sociales de violencia, alcoholismo y drogadicción.

2. La segunda, dominada por enfermedades infecciosas ligadas a la

pobreza, la desnutrición y la deficiente higiene ambiental y laboral, y

3. La tercera, por problemas de salud derivados de insuficiente

saneamiento básico

IV.4 Sistema de Vigilancia Epidemiológica Simplificada

La vigilancia epidemiológica simplificada consiste en un sistema de nivel

comunitario; su establecimiento responde a la necesidad de contar con los

mecanismos necesarios para reconocer la problemática del área rural marginada,

para fortalecer al Sistema de Información Nacional y al Sistema de Nacional de

Vigilancia Epidemiológica; se aplica en las comunidades rurales de menos de

2,500 habitantes (aproximadamente 154 016), de las cuales el 96.7% tiene menos

de 500 habitantes.

Diez millones de mexicanos no tienen acceso a los servicios de salud, viven en

condiciones geográficas de difícil acceso, de alta marginalidad y dispersión, en

donde no es posible contar con personal médico y paramédico necesario para la

108

atención de sus necesidades básicas o problemas prioritarios de salud. El

establecimiento de métodos alternativos de solución a los problemas de salud

requiere de información oportuna y completa sobre los daños y riesgos a la

población, ya que de otro modo se corre el riesgo de tener escaso o nulo impacto

en su prevención y control. Ante esto, la Secretaría de Salud decidió desarrollar

diversas acciones de trabajo comunitario, con la participación de personal

comunitario voluntario previamente capacitado, para utilizar instrumentos de

registro y técnicas de diagnóstico de fácil manejo que faciliten la identificación de

ciertos padecimientos y riesgos a la salud, que permitan dar solución a los

problemas de mayor importancia local y regional.

Uno de estos esfuerzos es el Sistema de Vigilancia Epidemiológica Simplificada

(SVES). Los objetivos generales del SVES son identificar el perfil de los problemas

de salud en áreas rurales carentes de servicios de salud, sistematizar el uso de la

información para identificar grupos de riesgo, generar información básica para

apoyar las actividades de programación local y fortalecer el sistema de vigilancia

epidemiológica y el sistema de información nacional.

El SVES considera a la comunidad como elemento central de las actividades

básicas y crea una red de vigilancia simplificada a cuyo cargo están los auxiliares

de Salud, estrechamente vinculados con los servicios, a través de las unidades de

Salud. Existen responsables de la unidad por región o a nivel jurisdiccional, y se

encargan de fomentar y asegurar la participación de los auxiliares, para alertar a

los servicios de salud sobre la presencia de problemas epidemiológicos.

IV.4.1 Componentes del SVES

El SVES esta definido como un conjunto de técnicas y procedimientos sencillos,

con participación activa de la comunidad como elemento del sistema, a través del

cual se registra, notifica, procesa y analiza la información básica sobre daños a la

109

salud y situaciones de importancia epidemiológica de las comunidades sin acceso

a los servicios de salud.

El SVES permite entonces, mediante técnicas sencillas, identificar signos y

síntomas para conformar mediante la metodología del interrogatorio, diagnósticos

probables de enfermedad. Además registra diagnósticos de primera vez (casos

nuevos) y permite el autocuidado de la salud individual con la participación del

personal comunitario con mínima escolaridad.

En la actualidad, los instrumentos que maneja el SVES son:

1. Plantilla para el Diagnóstico Individual de Enfermedades

2. Registro Individual de Enfermedades

3. Volante de Canalización de Pacientes

4. Informe Mensual

El instrumento básico de este sistema es la Plantilla para el Diagnóstico Individual

de Enfermedades; ésta incluye padecimientos de interés epidemiológico,

causantes de tasas elevadas de morbilidad y mortalidad. Considera signos y

síntomas que pueden ser identificados con facilidad por personal no médico para

conformar, mediante la metodología del interrogatorio, diagnósticos probables de

enfermedad,

IV.4.2 Padecimientos Incluidos

El SVES no intenta identificar todas las causas de morbilidad. La identificación se

ha limitado a condiciones que son importantes por su frecuencia, su gravedad y su

costo para la comunidad.

110

La plantilla de diagnóstico considera 24 padecimientos, integrados en 11 grupos:

Infecciones intestinales parasitariasDiarrea y deshidratación

Amibiasis

Diarrea infecciosa

Parasitosis intestinal

Enfermedades respiratoriasCatarro o influenza

Neumonía

Bronquitis

Tuberculosis

Anginas

Otitis

Enfermedades del sistema nerviosoParálisis

Ataques

Agresión por animal

Enfermedades InfecciosasEnfermedad exantemática

Enfermedades por picadura demosco

Paludismo

Dengue

Enfermedades crónicasDiabetes mellitus

Presión alta

Problemas de la nutriciónDesnutrición

Intoxicación por ponzoñaPicadura de alacrán

Otras enfermedadesEnfermedades de la piel

Infecciones vaginales

Accidentes y violenciasAtención de accidentes

Problemas mal definidos

Para integrar un diagnóstico probable, se combinan algunos signos y síntomas

que forman definiciones operacionales sencillas. Será identificado el diagnóstico

probable en el paciente que presente todos los signos y síntomas considerados

necesarios para cada padecimiento, con presencia o no de los signos y síntomas

opcionales. Los signos o síntomas necesarios son las molestias que deben estar

presentes para poder integrar un diagnóstico; los opcionales, las molestias que

pueden o no estar presentes para poder integrar un diagnóstico.

111

IV.5 Formatos e instructivos de registro y notificación

IV.5.1 Plantilla para el Diagnóstico Individual de Enfermedades

Este documento es usado por el auxiliar de salud. Representa un método práctico

y útil para hacer de manera simplificada el diagnostico probable de algunas

enfermedades de importancia epidemiológica, mediante la combinación de

algunos signos y síntomas, que aparecen en su parte superior (y que no

representan el total de la sintomatología de los padecimientos incluidos, sino la

más frecuente y fácil de identificar por el auxiliar de salud). Del lado derecho

aparecen los 24 padecimientos o diagnósticos que la plantilla permite detectar.

La utilización de este instrumento permite identificar la problemática de salud de

mayor importancia local e iniciar medidas inmediatas de carácter individual y

colectivo para su prevención y control. Esta plantilla es usada en los diagnósticos

de primera vez.

Para su uso correcto, se deben seguir las siguientes instrucciones:

1. Colocar una hoja de papel por detrás de la plantilla perforada, de manera

que todos los orificios se encuentren por encima de la hoja de papel. La

hoja debe estar bien fija con un clip, para que no se deslice.

2. Pedir al paciente que mencione sus molestias. En caso de que se trate

de un menor de edad se deberá preguntar a la madre del pequeño o a un

familiar adulto.

3. Buscar en la plantilla el signo o síntoma que más se parezca a la

molestia que refiere el paciente y cruzar con una X todos los orificios que se

encuentren por debajo de la molestia referida. Ejemplo: si la madre dice que

112

el pequeño tiene diarrea o está suelto, se deberá cruzar todos los orificios

que estén por debajo de la palabra "diarrea".

4. Después de que el paciente termine de mencionar todas sus molestias y

que hayan sido registradas sobre la plantilla, se iniciará la búsqueda de

otros signos y síntomas, que el paciente presente y que no haya referido.

Se deberá preguntar solo por aquellos que se encuentren a la izquierda de

los orificios que ya fueron tachados con X, y no estén marcados. Se

empezará siempre con el primer renglón de arriba hacia abajo y de

izquierda a derecha.

Ejemplo: Si el primer orificio marcado está en el primer renglón, por debajo

de la frase "piel y labios secos / llanto sin lágrimas", se preguntará al

paciente por cada uno de los signos y síntomas que se encuentran a los

lados y no hayan sido marcados con X (diarrea, mollera hundida y vómitos

o náuseas). Si el paciente en ese momento refiere que tiene diarrea,

entonces se marcará sólo ese orificio con una X.

Al terminar de marcar el primer renglón, se continuará con el siguiente

renglón que presente algún orificio marcado, siguiendo el mismo

procedimiento.

5. A continuación, se deberá identificar el o los diagnósticos que se

formaron. Para integrar un diagnóstico es necesario que todos los orificios

de los cuadros negros del renglón estén marcados con una X; por otra

parte, los orificios de los cuadros azules son opcionales, es decir, pueden o

no estar presentes en el paciente y, por tanto, no es necesario que se

encuentren marcados para poder integrar un diagnóstico probable.

113

6. En caso de que no se integre ningún diagnóstico, se deberá considerar

como un problema mal definido.

7. Cuando se forma un diagnóstico probable remarcado en color rojo, el

auxiliar de Salud deberá canalizar inmediatamente a la unidad de salud y

así notificarlo. Los casos captados de diarrea y deshidratación,

catarro/influenza, parálisis (parálisis flácida de miembros), ataques

(meningitis), agresión por animal (rabia), enfermedades exantemáticas,

dengue y picadura de alacrán deben ser notificados inmediatamente a la

unidad de salud correspondiente.

IV.6 Análisis y Diseño del Sistema

IV.6.1 Análisis de la Vista

Si se considera que las aplicaciones para dispositivos Palm dependen

enteramente de la interacción con el usuario y dado que en el esquema de

solución propuesto, la Vista y los otros subsistemas se modelan por separado, se

plantea el siguiente problema:

IV.6.1.1 Enunciado del problema

Definir las clases que especifiquen el comportamiento de cada uno de los

diferentes elementos de la interfaz gráfica de la Palm.

IV.6.1.2 Modelo de Objetos

El modelo de objetos se integra con el diagrama de modelo de objetos y las

entradas correspondientes del diccionario de datos

IV.6.1.3 Identificación de Objetos y Clases

114

Como sugiere [ Rumbaugh , op. Cit.], del enunciado del problema (1.1) se extraen

los sujetos; en este caso: elementos(s) de la interfaz gráfica.

Este término se refiere a elementos que no se encuentran bien delimitados en

dicha frase. Sin embargo, a partir del estudio de aplicaciones desarrolladas por

terceros, es posible identificar algunos objetos de la interfaz gráfica de Palm.

En primer lugar, se puede observar que todos los programas de Palm trabajan a

base de formas, y cada forma es una colección de otros objetos. Las operaciones

básicas que se pueden aplicar a estos objetos son mostrar y ocultar.

Figura 4.3 Agenda

Así, en la pantalla principal de la Agenda que se distribuye como parte del

software preinstalado de la Palm (Figura 4.3) distinguimos algunos objetos:

La propia forma (form) en la que se presentan los datos.

Etiquetas (labels - ) , en donde se despliega la hora de cada cita.

Campos (fields- ), en los que se muestra el texto asociado a la

cita.

Botones gráficos, como el que indica si una cita es repetitiva, si tiene alarma o si

tiene una nota anexa.

115

Botones, como el de añadir una cita (Nuevo - ) o el que permite ver los

detalles de alguna cita existente.

Flechas de desplazamiento ( ), para cambiar de día de la semana, o para

desplazarse a lo largo de las citas de un día.

El botón “Nuevo” remite al usuario a otra pantalla (una nueva forma) que se

muestra en la Figura 4.4, donde aparece un nuevo objeto: la lista de las horas y

minutos en los que puede ocurrir la cita.

Figura 4.4 Agregar una cita

El botón “Detalles” ( ) también despliega una nueva pantalla. Los elementos

nuevos que se pueden observar son: checkboxes, un combo que despliegan otro

tipo de listas, y campos de texto que hacen la función de botones: Si se presiona

el campo que dice “Diariamente”, se muestra la forma de la Figura 4.5. En esta

también se puede detectar un elemento nuevo: Una caja de texto en la que

aparecen mensajes.

Figura 4.5 Detalles de la cita

116

Por último, el botón “Nota” despliega la forma de la Figura 4.6, en donde se puede

escribir texto en forma libre. Si la pantalla se llena (como en el ejemplo), se habilita

la barra de desplazamiento que aparece a la derecha de la imagen.

Figura 4.6 Nota ligada a una cita

Repitiendo el mismo proceso en las otras aplicaciones distribuidas por Palm

(Libreta de direcciones, Block de notas, Lista de tareas y calculadora), se pueden

encontrar nuevos objetos.

Por ejemplo, en la forma que sirve para añadir nuevos registros en la libreta de

direcciones (Figura 4.7) cuando se escribe en cada campo, la primera letra es

siempre mayúscula. Esto se indica con una flecha apuntando hacia arriba, cerca

de la esquina inferior derecha de la forma.

Figura 4.7 Agregar una Dirección

117

Todas las formas tienen un menú, y al menos una forma adicional asociada, en

donde se muestran datos como la leyenda de derechos reservados y el logo de

Palm, así como la versión de la aplicación (Figura 4.8)

Figura 4.8 Forma Acerca de

De todos los programas mencionados, se extrae la siguiente lista de objetos:

Forma Flecha de desplazamiento Combo

Barra de desplazamiento Menús Formas AdicionalesBotón Botón gráfico CheckboxesCampo Campo texto como botón Campo texto para desplegar

datosFlecha que indica mayúsculas Etiqueta Lista

Tabla

Además, como se señaló en el capítulo 2, en Codewarrior se cuenta con una

herramienta especial para diseñar las interfaces que se usarán en la aplicación (el

Constructor).

Cuando se trabaja con el Constructor, se puede invocar un “menú de objetos”

(Figura 4.9) de donde se arrastra el objeto deseado hasta la forma.

118

Figura 4.9 Catalogo del Constructor

El estudio de esta herramienta permite detectar nuevos objetos:

Button Graphic Button Push Button

Repeating Button Graphic Push Button Graphic Repeating ButtonCheckboxes Feedback Slider Control FieldGraffiti Shift Indicator Label ListPopup Trigger Selector Trigger Slider ControlGadget Scroll bar

De este modo, se conforma la lista completa de objetos:

Forma Flecha de desplazamiento Combo

Barra de desplazamiento Menús Formas AdicionalesBotón Botón gráfico CheckboxesCampo Campo texto como botón Campo texto para desplegar

datosFlecha que indica mayúsculas Etiqueta Lista

Tabla Button Graphic Button

Push Button Repeating Button Graphic Push Button

Graphic Repeating Button Checkboxes Feedback Slider ControlField Graffiti Shift Indicator LabelList Popup Trigger Selector TriggerSlider Control Gadget Scroll bar

119

El siguiente paso consiste en descartar clases redundantes, irrelevantes o vagas.

Para llevarlo a cabo, es necesario definir claramente lo que cada objeto

representa. Este paso implica también, iniciar otra de las actividades

recomendadas por Rumbaugh [op. cit.]: la construcción del Diccionario de datos.

Objeto Definición

Forma Contenedor visual de elementos de la interfaz gráfica.

Normalmente una forma representa una sola pantalla de la

aplicación.

Formas Adicionales Variantes de forma, pueden ser Alertas: formasdesplegables que presentan información al usuario, Formasde información del producto (Acerca de), etc.

Form Sinónimo de Forma

Menú Elemento de la interfaz de usuario que permite al usuario

ejecutar comandos seleccionándolos de una lista que se

despliega en la parte superior de la pantalla.

Botón Objeto de la interfaz gráfica usado para ejecutar comandos

frecuentes o pasar de una forma a otra, dentro de la

aplicación

Botón gráfico Botón que se representa en la pantalla mediante una imagen

asociada

Button Sinónimo de Botón

Graphic Button Sinónimo de Botón gráfico

Push Button Objeto usado junto con otros similares, formando un grupo

para permitir la selección de uno y solo uno de ellos.

Similar en su funcionamiento a los botones de selección de

estaciones de un radio.

Repeating Button Objeto que envía señales continuas mientras el usuario lo

mantiene presionado.

Graphic Push Button Objeto cuya funcionalidad es resultado de la combinación de

los botones push y gráfico

Graphic RepeatingObjeto cuya funcionalidad es resultado de la combinación de

120

Button los botones repeating y gráfico

Check box Elemento de la interfaz de usuario que despliega una caja

que puede estar seleccionada (x) o no ( ) y que tiene

asociada una cadena de texto.

Campo Elemento de la interfaz de usuario que sirve para desplegar

y editar texto

Campo texto como

botón

Campo que cumple con la misma funcionalidad que un

botón.

Campo texto para

desplegar datos

Sinónimo de Campo

Field Sinónimo de Campo

Graffiti Shift Indicator Pequeño icono, normalmente localizado en la esquina

inferior izquierda de la pantalla y que indica el estado del

mecanismo de entrada de datos (mayúsculas, puntuación,

etc.)

Flecha que indica

mayúsculas

Sinónimo de Graffiti Shift Indicator

Etiqueta Elemento de la interfaz gráfica que contiene texto estático.

Label Sinónimo de etiqueta.

Lista Elemento de la interfaz gráfica que muestra varios renglones

de datos en una sola columna y de la que el usuario puede

hacer una selección

List Sinónimo de Lista

Tabla Elemento de la interfaz gráfica formado por renglones y

columnas que pueden, a su vez, contener otros objetos y

que permite al usuario trabajar con estos.

Barra de

desplazamiento

Elemento de la interfaz gráfica que facilita el desplazamiento

sobre campos de texto y tablas, informando la posición

aproximada del cursor dentro de aquel objeto

Scroll Bar Sinónimo de barra de desplazamiento

Slider Control Elemento de la interfaz gráfica que permite mover el cursor

121

de la barra de desplazamiento. Es parte de la Barra de

desplazamiento

Flecha dedesplazamiento

Sinónimo de Slider Control

Feedback Slider

Control

Elemento de la interfaz gráfica que muestra la posición

aproximada del cursor de la barra de desplazamiento dentro

del campo o lista asociado a esta.

Combo No se puede encontrar una definición exacta para este

objeto.

Popup Trigger Elemento de la interfaz gráfica que despliega la selección

actual de una lista (normalmente oculta) y la propia lista

cuando es seleccionado

Selector Trigger Elemento de la interfaz gráfica que consiste en una caja

dentro de la que se despliega (y permite editar) texto

Gadget Elemento de la interfaz gráfica cuyas características y

comportamiento son totalmente modificables por el

programador.

No es un objeto que este bien definido.

Finalmente, los objetos con los que se empezará a realizar el modelo se reducen a

la siguiente lista:

Forma

Menú

Botón

Checkbox

Campo

Graffiti Shift Indicator

Etiqueta

Lista

Tabla

Barra de desplazamiento

122

PopupTrigger

SelectorTrigger

IV.6.1.4 Diccionario de Datos

Al finalizar esta actividad, ya han sido indicadas las primeras definiciones en el


IV.6.1.5 Identificar Asociaciones entre clases

En los párrafos previos se han descrito ya algunos de los objetos de la interfaz

gráfica de Palm. Estas descripciones incluyen también las relaciones entre ellos:

La frase: “... cada forma es una colección de otros objetos” indica que el objeto

forma CONTIENE otros objetos.

Otras asociaciones detectadas son:

Forma MUESTRA datos (objetos)

Etiqueta DESPLIEGA texto

Campo DESPLIEGA texto

Campo PERMITE EDITAR texto

Campo ENVIA a Forma

Botón Gráfico TIENE imagen

Botón DESPLAZA Barra

Botón ENVIA a Forma

PopupTrigger MUESTRA Lista

SelectorTrigger MUESTRA Lista

IV.6.1.6 Identificar Atributos

Los atributos de los objetos detectados se pueden extraer directamente del

Constructor. Así, la Forma posee, entre otros: Coordenada Izquierda de Origen

123

(Left Origin), Coordenada Superior de Origen (Top Origin), Ancho, Alto,

Identificador de la Forma (Form ID), Identificador de la barra de Menú (Menú Bar

ID) y Titulo de la Forma (Form Title). La siguiente tabla muestra los atributos de

cada objeto, obtenidos del Constructor.

Propiedades Objetos

1 2 3 4 5 6 7 8 9 10 11 12

Identificador de la Forma x

Identificador de la Barra de Menú x

Identificador del Botón por defecto x

Titulo de la forma x

Nombre del Objeto x x x x x x x x x x

Identificador del Objeto x x x x x x x x x x

Coordenada de origen (Izquierda) x x x x x x x x x x x

Coordenada de origen (Superior) x x x x x x x x x x x

Ancho x x x x x x x x x x

Alto x x x x x x x x x x

Bandera que indica si el objeto se usa o no. x x x x x x x x x x

Bandera que indica si todos los eventos afectan a la forma x

Bandera que indica si se debe almacenar temporalmente la

información que quedará oculta por la forma

x

Bandera que define la forma en que se debe desplegar el texto

(Anchor Left)

x

Bandera que indica si el objeto tiene borde x

Bandera que indica si el texto del objeto se desplegara en

Negritas

x

Bandera que indica si el objeto se dibuja seleccionado la

primera vez

x

Bandera que indica si el campo es editable x

Bandera que indica si el campo esta subrayado x

Bandera que indica si el campo se desplegará en un sola línea

(independientemente de su tamaño)

x

Bandera que indica si el tamaño del campo puede cambiar x

Bandera que indica si el texto del campo se desplegará

justificado a la izquierda

x

Bandera que indica si el primer carácter del campo se escribe

en mayúscula

x

Bandera que indica si el campo tiene Barra de desplazamiento x

Bandera que indica si el campo recibirá solo caracteres

numéricos.

x

Propiedades Objetos

1 2 3 4 5 6 7 8 9 10 11 12

Nombre de la Fuente que se usará para desplegar Texto x x x x x x

Etiqueta que se dibujará en el objeto x x x x x

124

Identificador del grupo al que pertenece el objeto x

Número máximo de caracteres que se pueden escribir en el

Campo

x

Nombre de la Fuente que se usará para desplegar Texto x

Número de renglones que serán desplegados x

Lista de textos a desplegar x

Número de Filas x

Lista de anchos de columna x

Valor actual x

Valor mínimo x

Valor máximo x

Tamaño de página x

Bandera que indica si el tamaño del campo puede cambiar x x

Identificador de la lista a la que esta asociado el objeto x

Etiqueta del Menú x

Lista de elementos del Menú x

(1) Forma

(2) Botón

(3) Checkbox

(4) Campo

(5) Graffiti Shift Indicator

(6) Etiqueta

(7) Lista

(8) Tabla

(9) Barra de desplazamiento

(10) PopupTrigger

(11) SelectorTrigger

(12) Menu

Tabla 4.10 Propiedades de los objetos de la interfaz gráfica

125

IV.6.1.7 Refinamiento del modelo usando herencia

Como se puede observar, la mayoría de los objetos comparten los siguientes

atributos:

Nombre del Objeto

Identificador del Objeto

Coordenada de origen (Izquierda)

Coordenada de origen (Superior)

Ancho

Alto

Bandera que indica si el objeto se usa o no.

Esto sugiere que se puede crear una clase base, que incluya}e estos atributos, y a

partir de la cual se crean los demás.

Todo lo anterior se ha tomado en cuenta para crear la primera versión del

diagrama de clases (Figura 4.11):

Figura 4.11 Diagrama de clases de la Vista

Como se indicó, prácticamente todos las clases descienden de una clase base

(cComponenteVisual). Además, la clase cLista contiene una instancia de la clase

126

cPopupTrigger (que sirve para desplegar la lista). Las clases cCampo y cTabla

contienen ambas una instancia de la clase cBarraDeDesplazamiento.

IV.6.1.8 Modelo Dinámico

Para preparar los escenarios típicos, se ha considerado al PalmOS como un actor

(además del propio usuario) ya que es capaz de generar eventos que afectan a

una aplicación,

El caso de uso a considerar es el arranque y finalización de una aplicación; que se

puede separar en a) arranque de la aplicación, y b) finalización de la aplicación.

Figura 4.12. Caso de Uso MV1A. El PalmOS inicia una aplicación:

1. PalmOS invoca a la forma principal de la aplicación.

2. Para cada objeto, Forma dibuja el objeto n

3. Regresa al paso 2, hasta que no haya mas objetos por dibujar

Flujo alterno 1.A: Usuario presiona el botón de salir

4.1 Para cada objeto, Forma elimina el objeto n

4.2 Regresa al paso 4.1, hasta que no haya mas objetos por eliminar

4.3 Forma termina. Regresa el control a PalmOS

Termina el Caso de Uso

127

Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicación:

1. Usuario presiona el botón de salir

1.1 Para cada objeto, Forma elimina el objeto n

1.2 Regresa al paso 1.1, hasta que no hay mas objetos por eliminar

1.3 Forma termina. Regresa el control a PalmOS


Flujo alterno MV1B1: Usuario presiona el icono de “Home”

1. Para cada objeto, Forma elimina el objeto n

2. Regresa al paso 1, hasta que no hay mas objetos por eliminar

3. Forma termina. Regresa el control a PalmOS


El caso de uso genera el diagrama de flujo de eventos de la Figura 4.14.

128

Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalización de una

aplicación.

IV.6.1.9 Modelo Funcional

En el caso de la Vista, la funcionalidad esperada de los objetos consiste en

enmascarar en métodos las funciones ofrecidas por el PalmOS SDK.

Considérese, por ejemplo, la clase cCIGcheckbox, que modela el comportamiento

de los elementos de la interfaz gráfica denominados checkboxes. La definición de

dicha clase es:

129

#i f ndef CI GCHECKBOX_H

#def i ne CI GCHECKBOX_H

#i ncl ude " cl abel edobj ect . h"

#i ncl ude " cst r i ng. h"

cl ass cI GcheckBox: publ i c cLabel edObj ect {

/ / Associ at i ons

/ / At t r i but es

pr i vat e:

Bool ean sel ect ed;

UI nt 8 gr oupI D;

/ / Oper at i ons

publ i c:

cI GcheckBox ( For mPt r f r mP, UI nt 16 obj ect I D ) ;

cI GcheckBox ( For mPt r f r mP, UI nt 16 obj ect I D, cSt r i ng l aCadena ) ;

cI GcheckBox ( For mPt r f r mP, UI nt 16 obj ect I D, char * l aCadena ) ;

voi d sel ect ( Bool ean val or ) ;

Bool ean i sSel ect ed ( ) ;

voi d set Gr oup ( UI nt 8 el Gr upo ) ;

UI nt 8 get Gr oup ( ) ;

} ;

#endi f

Como se ha señalado, la implementación de la clase, consiste en llamadas a las

funciones de la interfaz de programación de aplicaciones de Palm; por ejemplo,

para cambiar el valor de el objeto gráfico, se usa la función CtlSetValue. El método

select, que cambia el estado del objeto gráfico, llama simplemente a esa función:

130

voi d cI GcheckBox: : sel ect ( Bool ean val or ) {

sel ect ed = val or ;

Ct l Set Val ue ( ( Cont r ol Pt r ) anObj ect Pt r , val or ) ;

}

De igual modo, el método isSelected, informa si el objeto esta seleccionado o no.

Para ello, hace uso de la función CtlGetValue que devuelve el estado del objeto.

Bool ean cI GcheckBox: : i sSel ect ed ( ) {

sel ect ed = Ct l Get Val ue ( ( Cont r ol Pt r ) anObj ect Pt r ) ;

r et ur n sel ect ed;

}

Ambos métodos hacen uso del atributo selected que es de tipo boléalo, por lo que

solo pude tener dos estados: verdadero o falso.

IV.6.1.10 Iterar

Otra recomendación de Rumbaugh [Ibíd.] es iterar el proceso a fin de refinar el

diagrama. Después de varias iteraciones, se obtiene el diagrama de la Figura 4.23

que contiene prácticamente todos los elementos que se van a usar en el proyecto.

IV.6.2 Análisis del Modelo

IV.6.2.1 Enunciado del problema (EP)

Definir las clases que especifiquen el comportamiento de Plantilla para el

Diagnóstico Individual de Enfermedades.


IV.6.2.2.1 Identificación de Objetos y Clases

Una vez más, al extraer el sujeto del enunciado del problema (EP):

131

Plantilla para el Diagnóstico Individual de Enfermedades

Se puede observar que se trata de un término muy general. Pero la definición de

dicho termino se encuentra al inició de este capítulo, “El instrumento básico de

este sistema es la Plantilla para el Diagnóstico Individual de Enfermedades”...

“incluye padecimientos de interés epidemiológico, causantes de tasas elevadas de

morbilidad y mortalidad. Considera signos y síntomas que pueden ser identificados

con facilidad por personal no médico...”

El uso de la plantilla esta descrito en los párrafos siguientes:

“Del lado derecho aparecen los 24 padecimientos o diagnósticos que la plantilla

permite detectar.”

“Para su uso correcto, se deben seguir las siguientes instrucciones:

...

2. Pedir al paciente que mencione sus molestias. En caso de que se trate de un

menor de edad, se deberá preguntar a la madre del pequeño o a un familiar

adulto.

3. Buscar en la plantilla el signo o síntoma que más se parezca a la molestia que

refiere el paciente y cruzar con una X todos los orificios que se encuentren por

debajo de la molestia referida.

...

4. Después de que el paciente termine de mencionar todas sus molestias y que

hayan sido registradas sobre la plantilla, se iniciará la búsqueda de otros signos y

132

síntomas, que el paciente presente y que no haya referido. Se deberá preguntar

solo por aquellos que se encuentren a los lados de los orificios que ya fueron

tachados con X, y no estén marcados. Se empezará siempre con el primer renglón

de arriba hacia abajo y de izquierda a derecha.

...

Al terminar de marcar el primer renglón, se continuará con el siguiente renglón que

presente algún orificio marcado, siguiendo el mismo procedimiento.

5. A continuación, se deberá identificar el o los diagnósticos que se formaron. Para

integrar un diagnóstico es necesario que todos los orificios de los cuadros negros

del renglón estén marcados con una X; por otra parte, los orificios de los cuadros

azules son opcionales, es decir, pueden o no estar presentes en el paciente y, por

tanto, no es necesario que se encuentren marcados para poder integrar un

diagnóstico probable.

6. En caso de que no se integre ningún diagnóstico, se deberá considerar como un

problema mal definido.

7. Cuando se forma un diagnóstico probable remarcado en color rojo, el auxiliar de

Salud deberá canalizar inmediatamente a la unidad de salud y así notificarlo.”

IV.6.2.2.2 Buscar sujetos en el EP

Una vez más, se sigue la recomendación de Rumbaugh [Ibíd.] y se localizan los

sujetos en los párrafos anteriores.

De esta búsqueda, se obtiene la siguiente lista de objetos:

Padecimientos

133

Signos

Síntomas

Diagnósticos

Molestias

Plantilla

Siguiendo el proceso aplicado en la sección IV.6.1 (Análisis de la Vista), se

procede a definir1 cada uno de los términos de la lista:

Padecimiento Cualquier causa de enfermedad.

Síntoma Manifestación de una alteración

orgánica o funcional apreciable por el

médico o por el enfermo. Característica

que permite reconocer una enfermedad,

trastorno funcional o una lesión.

Signo Cualquier evidencia de falta de salud en

el paciente.

Para efectos del sistema, sinónimo de

Síntoma

Diagnóstico Parte de la medicina que tiene por

objeto la identificación de una

enfermedad fundándose en los síntomas

de esta.

En el caso de estudio, son todos

aquellas probables enfermedades para

los que se cumple la condición de que el

paciente presente TODOS los signos y

síntomas considerados necesarios.

En el caso de estudio, Diagnóstico y

1 Definiciones obtenidas del Diccionario Terminológico de Ciencias Médicas

134

Padecimiento se manejan como

sinónimos.

Molestia Sinónimo de Signo

Plantilla Tabla bidimensional.

En el caso de estudio, se trata de una

matriz de 43 columnas (Síntomas) y 24

líneas (Padecimientos probables)

Después de descartar clases redundantes, irrelevantes y vagas, la lista se reduce

a:

Síntoma

Diagnóstico

Plantilla

IV.6.2.3 Identificar Asociaciones entre clases

Aplicando el método citado con anterioridad, se obtienen las siguientes

descripciones:

La plantilla INCLUYE padecimientos.

La plantilla CONSIDERA signos y síntomas.

El usuario MARCA (en la plantilla) la columna del síntoma referido.

Para definir la forma en que se compone la plantilla, se usa una frase más:

“Del lado derecho aparecen los 24 padecimientos o diagnósticos que la plantilla

permite detectar.”

IV.6.2.4 Identificar Atributos

Los atributos son relativamente sencillos de encontrar: Las clases que modelen el

diagnóstico y el síntoma, poseen una cadena de caracteres que se usa para

135

almacenar el nombre del dato. Por otro lado, la clase que modele a la plantilla

debe incluir objetos diagnóstico y síntoma.

Con todos estos elementos, se puede construir una primera versión del diagrama

de clases del Modelo (Figura 4.15).

Figura 4.15 Primera versión del diagrama de clases del Modelo


El principal caso de uso es que el usuario haga un diagnóstico (Figura 4.16)

Figura 4.16. Caso de Uso MD01. Usuario diagnóstica un padecimiento.

Caso de Uso MD01: Usuario diagnóstica un padecimiento

cModelo muestra lista de síntomas

Para todos los síntomas iniciales:

Flujo alterno MD01A: Usuario indica síntoma inicial

cModelo determina cuales otros síntomas debe conocer

Para cada síntoma faltante:

cModelo pregunta si se presenta el síntoma

Flujo alterno MD02A: Usuario indica si el síntoma existe o no

136

cModelo aplica algoritmo para encontrar posibles padecimientos

cModelo muestra lista de posibles padecimientos encontrados.

Flujo Alterno MD01B: Usuario termina el programa


Flujo Alterno MD02B: Usuario termina el programa


Esto genera el siguiente diagrama de flujo de eventos (Figura 4.17 Diagrama de

Flujo de Eventos de Elaboración de un diagnóstico)

Figura 4.17 Diagrama de Flujo de Eventos de Elaboración de un diagnóstico


El método más importante de la clase cModelo es, también, el más complicado.Consiste precisamente en obtener todos los diagnósticos probables, y paraproponer su implementación, una vez más se debe recurrir a algunos de lospárrafos mencionados al inicio de esta sección.

De acuerdo a la información indicada, se sugiere el siguiente procedimiento

(Figura 4.18 Algoritmo para obtener un diagnóstico):

1. Pr egunt ar al paci ent e que mol est i as t i ene. 1. 1 Par a cada mol est i a:1. Local i zar l a mol est i a en l as l i s t as de mol est i as, a par t i r de su

137

i ni ci al 1. 1. 2 Señal ar en l a caj a cor r espondi ent e, l a mol est i a r ef er i da2. Al macenar en ar r egl oSi nt omas, l a c l ave del s í nt oma, l a bander a

“ pr esent e” 1. 1. 4 Si no hay mas mol est i as, i r al paso 2 1. 1. 5 Vol ver a 1. 1. 12. Par a cada el ement o de ar r egl oSi nt omas: 2. 1 Al macenar el numer o de sí nt oma en l a var i abl e c l aveSi nt oma 2. 2 Recor r er l a mat r i z pl ant i l l aDi agnost i co 2. 2. 1 En el n- si mo r engl ón 2. 2. 1. 1 Si l a col umna con númer o cl aveSi nt oma t i ene al macenado un val or mayor que 0. ( El s í nt oma est a pr esent e en el padeci mi ent o) 2. 1. 1. 1. 1 Recor r er el r engl ón. Si l a col umna t i ene al macenado un 1 2. 1. 1. 1. 1. 1 Al macenar en ar r egl oSi nt omas l a c l ave del s í nt oma, bander a “ desconoci do” 2. 3 Al macenar en bander a el val or “ agot ado”3. Par a cada el ement o de ar r egl oSi nt omas: 3. 1 Si l a bander a es “ desconoci do” 3. 1. 1 Most r ar l a pant al l a que cor r esponde al Sí nt oma 3. 1. 2 Al macenar l a r espuest a ( en bander a) como “ pr esent e” o “ ausent e” , según l a r espuest a del paci ent e4. Recor r er l a mat r i z pl ant i l l aDi agnost i co

4. 1 En el n- s i mo r engl ón

4. 1. 1 Recor r er el r engl ón. Si l a col umna t i ene al macenado un numer o mayor

que 0

4. 1. 1. 1 Local i zar el Sí nt oma cuya c l ave cor r esponda al numer o de col umna

de pl ant i l l aDi agnost i co

4. 1. 1. 2 Si l a bander a del s í nt oma es “ ausent e” y en pl ant i l l aDi agnost i co

el val or es 1 ( obl i gat or i o) , ent onces el padeci mi ent o no exi st e.

Regr esa a 4. 1

4. 2. 1 Si se l l egó al f i n del r engl ón, el padeci mi ent o si exi st e. Al macenar

en ar r egl oPadeci mi ent os

4. 2. 2 Regr esa a 4. 1

5. Despl egar pant al l a r esul t ados.

6. Par a cada el ement o en ar r egl oPadeci mi ent os. Despl egar el nombr e del

padeci mi ent o.

Figura 4.18 Algoritmo para obtener un diagnóstico

IV.6.2.7 Iterar el proceso

Los objetos cDiagnostico y cSintoma son prácticamente iguales, por lo que parecemejor crear una clase cDescripcion, a partir de la que se forman los vectoresrespectivos de la clase cPlantillaDiagnostico.

Sin embargo, almacenar un nuevo síntoma no es tan trivial como simplemente

añadirlo a un vector.

138

Se requiere de una clase cArregloSintomas, cuyo método almacenarSintoma, se

describe a continuación:

1. Recor r er ar r egl oSi nt omas, buscando l a c l ave del s í nt oma

2. Si no exi st e, l a al macena y r egr esa l a posi ci ón en que quedo al macenada

3. Si ex i s t e y l a bander a t i ene el val or de agot ado, r egr esa ( 0)

4. Si ex i s t e y l a bander a t i ene el val or de pr esent e, r egr esa ( - 1)

Después de esta iteración, se obtiene un nuevo diagrama de clases (Figura 4.19):

Figura 4.19 Diagrama de Clases del Modelo.

IV.7 Análisis del Controlador

Antes de modelar el Controlador se debe tomar en cuenta una restricción

importante: Hasta la versión 7.0 de Codewarrior, no es posible usar objetos en la

rutina principal. Esto se debe a que Codewarrior crea un esqueleto de funciones

que se completan con el código necesario para la aplicación (Figura 4.20).

139

No hay disponible, hasta esta versión de Codewarrior, un mecanismo similar

orientado a objetos. Pero, como se mencionó en el Capítulo 1, es posible modelar

objetos con C a través del uso de estructuras.

Así, se puede pensar en la estructura de funciones ofrecidas por Codewarrior

como una clase cControlador genérico, donde cada una de estas funciones es un

método.

Enseguida se listan todas estas funciones:

st at i c Er r RomVer si onCompat i bl e( UI nt 32 r equi r edVer si on, UI nt 16 l aunchFl ags)

Esta función verifica que la versión del ROM cumpla los requisitos mínimos de laaplicación.

st at i c voi d * Get Obj ect Pt r ( UI nt 16 obj ect I D)

El objetivo de esta función es regresar el apuntador a un objeto de la forma enuso.

st at i c Bool ean Mai nFor mDoCommand( UI nt 16 command)

Esta función ejecuta el comando de menú especificado.

st at i c Bool ean AppHandl eEvent ( Event Pt r event P)

Esta función carga los recursos y establece cual será la rutina encargada demanejar los eventos de la forma que se esta poniendo en uso en un momentodado.

st at i c voi d AppEvent Loop( voi d)

En esta función se implementa el ciclo de eventos de toda la aplicación.

st at i c Er r AppSt ar t ( voi d)

Las preferencias de la aplicación actual se establecen en esta función.

st at i c voi d AppSt op( voi d)

En esta función se guarda el estado actual de la aplicación, para recuperarlocuando la aplicación reinicie.

st at i c UI nt 32 St ar t er Pal mMai n( UI nt 16 cmd, MemPt r / * cmdPBP* / , UI nt 16 l aunchFl ags)

Esta función constituye el punto de entrada principal de la aplicación.

UI nt 32 Pi l ot Mai n( UI nt 16 cmd, MemPt r cmdPBP, UI nt 16 l aunchFl ags)

Esta función es invocada por el PalmOS para arrancar la aplicación. A su vez,llama a StarterPalmMain.

140

st at i c voi d Mai nFor mI ni t ( For mPt r / * f r mP* / )

Esta función inicializa la forma MainForm

st at i c Bool ean Mai nFor mHandl eEvent ( Event Pt r event P)

Esta rutina implementa el manejador de eventos de la forma MainForm

Figura 4.20 Funciones creadas por Codewarrior.

Como se puede observar, hay funciones que reciben como parámetro un

apuntador a una forma, simulando encapsulamiento según el mecanismo descrito

en el Capítulo 1.

En el capítulo 2 se señaló que es necesario que exista una versión de las

funciones FormInit y FormHandleEvent por cada forma del sistema.

Todo esto hace que Modelar el Controlador sea en realidad, la actividad mas

sencilla de la etapa de análisis, sin perder de vista que una parte de la

implementación esta hecha, definida por Codewarrior, y no se puede cambiar.

IV.7.1 Enunciado del problema (EP)

Definir la(s) clase(s) que especifiquen el comportamiento de una aplicación Palm.


Además de considerar las funciones mencionadas, la clase cControlador debe

incluir, por lo menos, instancias de las clases cModelo (Modelo) y cVista (Vista).

Debido a dificultades observadas en el manejo de memoria por parte del PalmOS,

se considera conveniente declarar, en esta misma clase, un apuntador a cString

(Figura 4.21).

141

Figura 4.21 Modelo de objetos del Controlador


Este es el caso más complejo de los 3 modelos, ya que su funcionalidad es

resultado de la combinación de la funcionalidad de los otros.

De este modo, el caso de uso a considerar es el de un usuario que aprovecha la

aplicación para obtener el diagnóstico de un paciente.

Figura 4.22. El Usuario diagnostica padecimiento.

Caso de Uso MC01. El Usuario diagnostica padecimiento:

Usuario invoca a la aplicación.

Controlador crea instancia de la clase cVista llamada forma

Controlador crea instancia de la clase cModelo llamada plantilla

Controlador solicita a forma que despliegue MainForm

Ocurre el Caso de Uso MV1A. El PalmOS inicia una aplicación.

a) Ocurre el Caso de Uso MD01. Usuario diagnóstica un padecimiento.

Flujo alterno MC01A. Usuario decide hacer otro diagnóstico

Se repite el caso de uso, desde a)

142

Flujo alterno MC01B. Usuario termina la aplicación.

Ocurre el Caso de Uso MV1B. Usuario o el PalmOS finalizan laaplicación


El método más importantes de la clase cControlador es manejaEventos(), y está

encargado de manipular los eventos que ocurran en cada forma.

Se muestra a continuación (en pseudo código) este método. Se asume que

existen un objeto de la clase cForma y al menos uno de la clase cCIGcampoTexto,

declarados en la rutina de inicialización de cControlador.

1. Inicializa el objeto de cForma con el identificador de la forma Síntoma.

2. Obtiene del objeto de cForma el identificador del campo de texto etiquetado como “Pregunta”

3. Inicializa el objeto cCIGcampoTexto con el identificador obtenido en el paso 3.

4. Cambia el contenido del objeto cCIGcampoTexto, para que muestre la pregunta actual.

5. Invoca el método draw() del objeto cCIGcampoTexto.

6. Inicia un ciclo que espera a que ocurra un evento en la forma.

6.1 El objeto de la clase cForma informa el identificador del control que

generó el evento y el tipo de evento ocurrido

7. Dependiendo de los valores obtenidos en 6.1, se registra la respuesta a la pregunta, y se

determina cual es el siguiente Síntoma a preguntar, o se inicia el diagnostico.

8. Si se debe seguir preguntando, regresa a 2. Si se debe diagnosticar, continua en 9.

9. Invoca la rutina de diagnóstico.

10. Inicializa el objeto de cForma con el identificador de la forma Resultados.

11. Obtiene del objeto de cForma el identificador del campo de texto etiquetado como “Diagnostico”

12. Cambia el valor del objeto cCIGcampoTexto para que tenga el del identificador obtenido en el

paso 11.

13. Cambia el contenido del objeto cCIGcampoTexto, para que muestre los eventuales

padecimientos.

14. Invoca el método draw() del objeto cCIGcampoTexto.

Figura 4.23 Diagrama de clases de la Vista.

CONCLUSIONES

145

La pregunta central planteada al inicio del presente trabajo fue si 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.

La solución propuesta consiste en aplicar una versión acotada de la técnica de

modelado de objetos (OMT) de Rumbaugh sobre el patrón de Modelo Vista

Controlador, todo ello adaptado a las restricciones propias de los Asistentes

Personales Digitalizados, que comprenden desde el hardware limitado hasta el

hecho de que el modelado del sistema de soporte (conformado por la interfaz

gráfica de la Palm -la Vista- y el Controlador) se realiza una sola vez, y se puede

utilizar en cualquier proyecto posterior.

A continuación se enlistan las conclusiones a las que se ha podido llegar a lo largo

del desarrollo del presente proyecto y se plantea el trabajo futuro que se puede

desarrollar a partir de las bases establecidas hasta este momento.

Los principales productos resultantes de este trabajo, son una metodología de

análisis y diseño de sistemas enfocada al desarrollo de aplicaciones para PDAs, y

en forma más específica, una librería de clases que controla los elementos de la

interfaz gráfica de los dispositivos basados en el PalmOS.

Sobre la Metodología, se ha desarrollado el modelo de la Vista, el principio de lo

que puede llegar a ser un Controlador genérico, y se han sugerido ideas que

faciliten el desarrollo de Modelos de aplicación.

146

Aplicar la metodología resultó útil porque facilitó enormemente el proceso de

desarrollo de una aplicación Palm, permitiendo separar la implementación del

modelo de la interfaz gráfica, de la del dominio del problema. Además de otras

ventajas que saltan a la vista: se puede reutilizar todo el diseño (y el código) de la

vista, y una buena parte del controlador.

El patrón de diseño Modelo Vista Controlador resultó también una buena elección,

por que las aplicaciones en Palm se implementan en forma muy aproximada al

mismo, ya que dependen completamente de la interacción con el usuario. Como

se pudo observar, el desarrollo de las aplicaciones para Palm inicia con el diseño

del componente visual (la vista) de las mismas, y basandose en los resultados

obtenidos, es factible pensar que diferentes dominios de aplicación se pueden

acoplar de forma relativamente sencilla diseñando nuevos modelos.

La integración entre el modelo y la interfaz fue una tarea relativamente sencilla,

encapsulando las funciones propias del PalmOS en una clase cControlador. Esto

hace pensar que, como un trabajo futuro, sea posible generalizar esta clase, e

integrarla en una librería de controladores.

La separación del dominio del problema de las dificultades de implementación de

la interfaz de usuario resulta ser una gran ventaja: se puede reutilizar completo el

diseño de la interfaz gráfica, prácticamente en cualquier nuevo proyecto Palm. La

librería de clases de la interfaz Gráfica de Palm obtenida también como producto

de este proyecto resulta ser muy importante, ya que facilita enormemente la

manipulación de los objetos de la vista.

De hecho, esta librería se esta usando ya en otros dominios de aplicación. Debido

a contratos comerciales preexistentes no es posible dar detalles muy específicos,

pero se han desarrollado productos totalmente operacionales en este momento

para la rama de Seguros.

147

Esto demuestra las bondades de seguir una metodología de objetos. Pasar de un

área de conocimiento como la Medicina a otra totalmente diferente, de tipo

económico, no afecta en ningún modo a modelo de la Vista. El desarrollador de

aplicaciones Palm simplemente debe crear instancias nuevas, enfocadas al nuevo

dominio de aplicación.

Existen potenciales áreas de aplicación de tipo comercial en donde se pueden

utilizar tanto la librería de clases como la metodología ya comentada. Aplicaciones

para evaluar la aprobación de créditos, o selección de planes de seguros de vida

son candidatas ideales para este esquema.

Surge entonces el cuestionamiento de cuán eficiente es usar el nuevo esquema

de trabajo (la metodología), contra el método tradicional de trabajo, muy parecido

a un esquema de prototipado evolutivo:

a) Obtener el requerimiento del usuario

b) Diseñar la(s) pantalla(s) requeridas

c) Codificar la funcionalidad necesaria

d) Entregar una versión preliminar el producto

a. Regresar al inciso a)

No se puede medir la eficiencia usando como parámetro el tiempo que tarda la

aplicación en ejecutarse totalmente, por que el desempeño de la aplicación se ve

afectado por la presencia (o ausencia) de otros programas: programas que sirven

para acelerar el reloj interno de la Palm (overclocking), por ejemplo.

Otro factor que puede influir en la forma en que una aplicación se ejecuta, es la

cantidad de memoria libre con la que cuente el dispositivo; mientras mas memoria

148

libre exista, las operaciones de administración del PalmOS se realizan mas

fácilmente, y las aplicaciones se ejecutan más rápido.

Por tanto, se ha optado por utilizar otras métricas, como el número de líneas de

código, el porcentaje de instrucciones del lenguaje contra el total del código, etc.

Aprovechando el hecho de que existe una versión del SVES que fue desarrollada

sin usar una metodología específica, se aplico a ambas versiones el programa

c_count (http://invisible-island.net/c_count/) obteniéndose, entre otros, los

siguientes resultados:

SVES Evolutivo SVES MVC

138 14? | Cabecer as. c

638 274? | Canal i zaci on. c

441 158? | Di agnost i co. c

2210 856? | For mas. c

106 35? | I dPal m. c

1130 519? | MenuSi nt omaI ni c i al . c

40 29? | Pr ot ot i pos. h

355 149? | Regr eso. c

246 44? | Segui mi ent o. c

585 222? | St ar t er . c

- - - - - - - - - - - - - - - -

5889 2300? t ot al l i nes/ st at ement s

884 l i nes had comment s 15. 0 %

392 comment s ar e i nl i ne - 6. 7 %

1020 l i nes wer e bl ank 17. 3 %

21 l i nes f or pr epr ocessor 0. 4 %

4356 l i nes cont ai ni ng code 74. 0 %

5889 t ot al l i nes 100. 0 %

20479 comment - char s 12. 6 %

16651 nont ext - comment - char s 10. 3 %

37461 whi t espace- char s 23. 1 %

495 pr epr ocessor - char s 0. 3 %

87298 st at ement - char s 53. 8 %

162384 t ot al char act er s 100. 0 %

351 136? | cDat aBase. cpp

41 24 | cDat aBase. h

40 12 | cet i quet a. cpp

24 10 | cet i quet a. h

51 13 | c i gbot on. cpp

31 15 | c i gbot on. h

36 9 | c i gcheckbox. cpp

25 11 | c i gcheckbox. h

298 65 | c i gf i el d. cpp

78 48 | c i gf i el d. h

11 0 | c i gl abel . cpp

60 19 | c i gl abel edobj ect . cpp

30 14 | c i gl abel edobj ect . h

18 5 | c i gl abel . h

147 39 | c i gl i s t . cpp

50 26 | c i gl i s t . h

63 20 | c i gscr ol l bar . cpp

28 14 | c i gscr ol l bar . h

79 28 | cobj et omi ni mo. cpp

35 18 | cobj et omi ni mo. h

82 30 | cont r ol obj ect . cpp

33 19 | cont r ol obj ect . h

62 16 | cr ect angl et ype. cpp

30 15 | cr ect angl et ype. h

491 103 | cst r i ng. cpp

138 46 | cst r i ng. h

18 4 | cusabl eobj ect . cpp

149

7952 t okens, aver age l engt h 8. 66

0. 23 r at i o of comment : code

756 ?: i l l egal char act er s f ound

21 6 | cusabl eobj ect . h

215 63 | pr ecor d. cpp

67 39 | pr ecor d. h

655 121? | s t ar t er . cpp

- - - - - - - - - - - - - - - -

3308 988? t ot al l i nes/ st at ement s

743 l i nes had comment s 22. 5 %

241 comment s ar e i nl i ne - 7. 3 %

671 l i nes wer e bl ank 20. 3 %

129 l i nes f or pr epr ocessor 3. 9 %

2006 l i nes cont ai ni ng code 60. 6 %

3308 t ot al l i nes 100. 0 %

11138 comment - char s 14. 4 %

8726 nont ext - comment - char s 11. 3 %

17599 whi t espace- char s 22. 7 %

2482 pr epr ocessor - char s 3. 2 %

37544 st at ement - char s 48. 5 %

77489 t ot al char act er s 100. 0 %

4848 t okens, aver age l engt h 6. 84

0. 28 r at i o of comment : code

4 ?: i l l egal char act er s f ound

Tabla C1. Comparación de código entre versiones del SVES.

Como puede observarse el código generado usando objetos es aproximadamente

40% menos que el obtenido usando programación tradicional.

Pero esta no es la única ventaja. Considérese, por ejemplo, la necesidad de

añadir un nuevo padecimiento al autómata que da soporte al producto.

Con la metodología evolutiva, sería necesario modificar prácticamente todos los

programas mostrados (10), mientras que usando el Patrón Modelo Vista

Controlador, solo sería necesario modificar la clase cModelo, codificada en dos

archivos (cModelo.cpp y cModelo.h) que no son parte de la Vista, sino del Modelo.

150

Otras ventajas del esquema propuesto tienen que ver con la facilidad de

adaptación a cambios. Permitir que las aplicaciones desplieguen video, por

ejemplo, requiere solamente añadir la clase correspondiente a la Vista.

Nuevamente, este hecho implica que un cambio mayor, como podría ser migrar de

plataforma (generar una versión de la aplicación para una plataforma que no

maneje el PalmOS como su sistema operativo), requiere recodificar solo las clases

de la Vista y algunas partes del controlador, sin tener que tocar ninguna clase del

Modelo.

Trabajo futuro.

Se dejan planteadas muchas áreas por explorar, por ejemplo:

Se puede añadir persistencia a las clases, de forma que guarden su estado una

vez que se apaga el dispositivo. Esta propuesta se puede extender hasta el hacer

que el algoritmo tuviera la capacidad de aprender: si un conjunto de síntomas dan

como resultado un problema mal definido, los datos almacenados se pueden

mostrar a un Médico que indique el nombre del padecimiento y retroalimente el

sistema.

El Modelo se puede generalizar para que se le pueda aplicar a otros problemas

que usen autómatas (muy fácilmente se puede extender a otros problemas de

toma de decisiones).

También se podría hacer configurable si el autómata se pudiera leer de una tabla

en lugar de estar codificado en la clase correspondiente. Separando la matriz de

151

conocimiento del experto se podría crear una aplicación administradora de

modelos.

Finalmente, añadiendo un nuevo elemento al Patrón se puede facilitar la conexión

con otro tipo de dispositivos (de comunicación, bases de datos, etc.)

El nuevo Patrón sería algo parecido al que se muestra en la Figura C2.

Figura C2. Patrón Modelo Vista Controlador Adaptador

BIBLIOGRAFÍA

153

RUMBAUGH, James, et. al. MODELADO Y DISEÑO ORIENTADO A OBJETOS.

Metodología OMT. México: Prentice Hall, 1996.

FORESTER, Lonon R. PALMOS PROGRAMMING BIBLE. Nueva York: Hungry

Minds, 2000.

TUCKER, Allen B. LENGUAJES DE PROGRAMACIÓN. 2ª. edición. México:

McGraw-Hill, 1988.

KELLEY, Dean. TEORÍA DE AUTÓMATAS Y LENGUAJES FORMALES.

España: Prentice Hall, 1995.

TANENBAUM, Andew S. REDES DE COMPUTADORAS. Prentice Hall, 3ª.

Edición 1997

WIDLE, Erick. WILDE'S W.W.W. Berlin: Ed. Springer, 1999

COPLIEN, James et. al. PATTERN LANGUAGES OF PROGRAM DESIGN.

Addison-Wesley 1995.

BROOKSHEAR, J. Glenn. INTRODUCCIÓN A LAS CIENCIAS DE LA

COMPUTACIÓN. 4ª edición. México: Addison Wesley Iberoamericana, 1995.

JOYANES AGUILAR, Luis. METODOLOGÍA DE LA PROGRAMACIÓN. México:

Mc Graw Hill, 1988

KENDALL, Kenneth. et. al. ANÁLISIS Y DISEÑO DE SISTEMAS. México:

Prentice Hall Hispanoamericana, 1991.

GAIL CHRISTIE, Linda, et. al. ENCICLOPEDIA DE TÉRMINOS DE

MICROCOMPUTACIÓN. México: Prentice Hall, 1985.

154

DICCIONARIO DE INFORMÁTICA. 2ª edición. México: Diaz de Santos, 2000.

PARKER, Charles S. INTRODUCCIÓN A LA INFORMÁTICA. México: Editorial

Interamericana, 1987.

YOURDON, Eduard. ANÁLISIS ESTRUCTURADO MODERNO. México: Prentice

Hall, 1993.

YOUNG, A. Douglas. NETSCAPE DEVELOPER’S GUIDE TO PLUG-INS.

Prentice Hall, 1992.

PRESSMAN, Roger S. INGENIERIA DE SOFTWARE. UN ENFOQUE

PRACTICO. 4ª. Ed. Madrid: Mc Graw Hill Interamericana, 1998

BREEDLOVE Rob, et al. WEB PROGRAMMING UNLEASHED. 1a. Ed. Sams

Publishing, 1996

CARDENAL, L. DICCIONARIO TERMINOLÓGICO DE CIENCIAS MÉDICAS. 7ª

edición. México: Salvat Editores, 1960.

ALVAREZ LUCAS, et. al. MANUAL PARA LA VIGILANCIA EPIDEMIOLÓGICA

SIMPLIFICADA. Epidemiología, No. 24. Secretaría de Salud.

CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (I)”. En: SOLO

PROGRAMADORES. Madrid, España. (82 - 09 – 2001). 7-10.

CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (II)”. En: SOLO


CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (y III)”. En: SOLO


155

ÉRDI Gergõ. GUIKACHU. feshmeat.net, 02/03/2001

http://cactus.rulez.org/projects/guikachu/

D. JEFF Dionne. PRC-TOLLS. sourceforge.net, 20/08/2002

http://PRC-Tools.sourceforge.net/

STRUNK Darren. PATTERNS IN OBJECT-ORIENTED DEVELOPMENT.

Universidad de Texas. 12/05/1999

http://www.cs.utexas.edu/users/almstrum/cs370/strunk/part3.htm

SADOSKI, Darleen. CLIENT/SERVER SOFTWARE ARCHITECTURES, AN

OVERVIEW. Software Engineering Institute. Carnegie Mellon University. 1997

http.// w w w.sei.cmu.edu/activities/str/descriptions/clientserver.html

ARDIRI, Aaron. PILRC v2.9. www.ardiri.com.Enero, 2003

http://www.ardiri.com

webopaedia. ONLINE DICTIONARY FOR COMPUTER AND INTERNET TERMS.

Enero, 2003

http://www.pcwebopaedia.com/

LANDSBERG, Joe. PROBLEM SOLVING AND DECISION MAKING. University of

St. Thomas. 04/09/2002

http://www.iss.stthomas.edu/studyguides/problem/problemsolvingV.htm

DENNIS, Payne. XWPE-ALPHA PROJECT. Identicalsoftware, 15/10/2002

http://www.identicalsoftware.com/xwpe/

KH. NABA, Kumar Singh. ANJUNTA [DEV STUDIO]. sourceforge.net, 15/10/2002

http://anjuta.sourceforge.net/

156

KORGAONKAR, Sachin. DESIGN PATTERNS. 04/09/2002.

http://www.developersdiary.com/patterns.asp

APPLETON, Brad. PATTERNS AND SOFTWARE: ESSENTIAL CONCEPTS

AND TERMINOLOGY. 02/14/2000

http://www.enteract.com/%7Ebradapp/docs/patterns-intro.html

APPLETON, Brad. PATTERNS IN A NUTSHELL. THE “ BARE ESSENTIALS” OF

SOFTWARE PATTERNS. 02/14/2000

http://www.enteract.com/%7Ebradapp/docs/patterns-nutshell.html

FRYE, Jason. PATTERNS HOME PAGE. The Refactory, Inc., The Hillside Group.

Junio, 2002

http://hillside.net/patterns/

TIDWELL, Jenifer. UI PATTERNS AND TECHNIQUES. MIT. Mayo, 2002

http://time-tripper.com/uipatterns/index.html

STRUNK, Darren. PATTERNS IN OBJECT-ORIENTED DEVELOPMENT.

Universidad de Texas. 12/05/1999

http://www.cs.utexas.edu/users/almstrum/cs370/strunk/part3.htm

BARAY, Cristobal. THE MODEL-VIEW-CONTROLLER (MVC) DESIGN

PATTERN. Universidad de Indiana, Enero, 2003.

http://www.cs.indiana.edu/~cbaray/projects/mvc5.html

MODEL VIEW CONTROLLER. OBJECT ARTS. PURE OBJECT ORIENTED

SOFTWARE. Enero, 2003.

http://www.object-arts.com/EducationCentre/Overviews/MVC.htm

157

WHEELER, Sarah. THE MODEL-VIEW-CONTROLLER ARCHITECTURE. CERN.

Organización Eruopea para la Invetigación Nuclear, 30/08/1996.

http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html

MODEL-VIEW-CONTROLLER PATTERN. eNode, Inc, 2002.

http://www.enode.com/x/markup/tutorial/mvc.html

MODEL-VIEW-CONTROLLER. java.sun.com. Enero, 2003.

http://java.sun.com/blueprints/patterns/MVC.html

BAKKER, Gerbrand, et. al. OMT OBJECT MODEL. Université Paris, 09/02/1996.

http://panoramix.univ-paris1.fr/CRINFO/dmrg/MEE/misop007/index.html

FEDERHOFER, Judith. MEDICAL EXPERT SYSTEMS. Enero, 2003

http://www.computer.privateweb.at/judith/historical3.htm

DARLINGTON, Keith MSc, MBCS. BASIC EXPERT SYSTEMS. BRITISH

COMPUTER SOCIETY NURSING SPECIALIST GROUP, Junio, 1996.

http://www.bcsnsg.org.uk/itin08/darling.htm

ROSENTHAL Helen T. , MD et. al. ONLINE MEDICAL DIAGNOSIS. The National

Medical Society, Diciembre, 2002.

http://www.medical-library.org/mddx_index.htm

MEDLINEplus. INFORMACIÓN DE SALUD. Biblioteca Nacianal de Medicina de

EU, 14/02/2003.

http://www.nlm.nih.gov/medlineplus/spanish/tutorial.html

CHANG, Shi-Kuo. MEDICAL DIAGNOSIS SUPPORT SYSTEM MAIN FORM.

University of Pittsburgh, Pittsburgh, PA 15260 USA, Diciembre 2002.

http://www.cs.pitt.edu/~jung/AMIS2/

158

LIBRARY OF THE NATIONAL MEDICAL SOCIETY. The National Medical

Society, Diciembre, 2002.

http://www.medical-library.org/index.htm

EasyDiagnosis. MatheMEDics. Expert online health software, Enero 2003.

http://easydiagnosis.com/

KAPPEN, H.J. Dr. A DECISION SUPPORT SYSTEM FOR MEDICAL DIAGNOSIS

USING A LARGE PROBABILISTIC NETWORK. Katholieke Universiteit Nijmegen

Medische Fysica en Biofysica, 18/10/2000.

http://www.stw.nl/projecten/N/nnn5322.html

Aetna IntelHealth. Hardvard Medical School's, 15/02/2003.

http://www.intelihealth.com

159

ANEXOS

160

A.1 Plantilla del SVES

Como se mencionó, la información sobre el Sistema de Vigilancia Epidemiológica

Simplificada (SVES) utilizada en el presente trabajo se obtuvo del documento

llamado Manual para la vigilancia epidemiológica simplificada.

Según menciona el sitio web de la Secretaría de Salud este documento puede ser

consultado en su Centro de Documentación Institucional, localizado en la Calle de

Lieja No. 7 Primer Piso, Col. Juárez. Del. Cuauhtémoc. Tel. 5553-7184

El personal de atención a usuarios de ese centro proporcionó la ubicación del

documento:

Au: Alvarez Lucas, Carlos; Ferreira Guerrero, Elizabeth; Et al. Au: México.

Secretaría de Salud. Dirección General de Epidemiología.

Ti: Manual para la vigilancia epidemiológica simplificada/Manual for simplified

epidemiologic surveillance.

Fu: México, D.F; México. Secretaría de Salud; s.f. <42>p.

Re: Este manual tiene como propósito el de servir de apoyo al médico responsable

del sistema de vigilancia epidemiológica en el ejercicio de sus funciones en lo

concerniente al registro y notificación de los problemas de salud que afecten a su

comunidad, para referir a los diferentes centros de salud a las personas que

requieran de atención médica. Contenido: Introducción. 1)Antecedentes. 2)Marco

teórico: factores condicionantes; sistemas de vigilancia epidemiológica,

información convencional y no convencional; aspectos epidemiológicos.

3)Justificación. 4)Objetivos. 5)Límites. 6)Sistema de vigilancia epidemiológica

simplificada: padecimientos incluidos, componentes, organización estructural,

161

asignación de responsables y funciones, flujo de información, bases legales y

normativas. 7) Capacitación, supervisión y evaluación. Anexos.

Ub: MX10.1/6097.

De dicho documento se obtuvo la copia de la Plantilla para el Diagnóstico

Individual de Enfermedades que se muestra en la siguiente página.

163

A.2 Contenido del CDROM

El CD que acompaña este documento contiene, entre otras cosas:

• Copias de este documento, en versiones electrónicas (formatos PDF y PS).

• Código fuente del sistema desarrollado.

• Artículo sobre desarrollo de aplicaciones para Palm con Software de códigoabierto aparecido en el boletín InterFAR Año 1, Número 5.

• Ponencia sobre el mismo tema, presentada en el Congreso Nacional deSoftware Libre, edición 2003.

• Descripción del Formato Coff.

• Descripción de los elementos gráficos de OMT.

• Software opensource para desarrollo de aplicaciones para Palm, versionespara Windows y Linux.

El contenido detallado se encuentra listado en el archivo CONTENIDO.TXT, en el

directorio raíz del mismo CD.

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

Documents

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