Você está na página 1de 173

ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL

NUMERO 00922681 DE FECHA 23 DE JUNIO DE 1992

SVES. DESARROLLO DE APLICACIONES PARA


DISPOSITIVOS MÓVILES

TESIS

QUE PARA OBTENER EL TÍTULO DE

INGENIERO EN COMPUTACIÓN

PRESENTA:

IVÁN CARLOS RIVERA GONZÁLEZ

ASESOR: EUGENIO JACOBO HERNÁNDEZ VALDELAMAR

MÉXICO, D.F. MARZO DE 2003


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

INTRODUCCIÓN..................................................................................................... 1
CAPITULO I DESARROLLO DE SISTEMAS .......................................................... 4
I.1 Conceptos del Software .................................................................................. 5
I.2 Lenguajes de Programación ........................................................................... 6
I.2.1 Qué es un lenguaje de programación ................................................... 6
I.2.2 Evolución de los Lenguajes de Programación ...................................... 9
I.2.3 Clasificación de los Lenguajes de Programación................................ 12
I.2.4 El proceso de la programación............................................................ 14
I.3 Tipos de Sistemas de Cómputo .................................................................... 15
I.3.1 Aplicaciones Monolíticas ..................................................................... 16
I.3.2 Modelo Cliente / Servidor .................................................................... 16
I.3.3 Sistemas Distribuidos.......................................................................... 21
I.3.4 Cómputo Móvil .................................................................................... 22
I.3.5 Comentarios Finales ........................................................................... 25
CAPITULO II DESARROLLO DE APLICACIONES PARA ASISTENTES
PERSONALES DIGITALIZADOS .......................................................................... 26
II.1 Introducción a las PDAs ............................................................................... 27
II.2 Arquitectura de Hardware de la plataforma Palm......................................... 28
II.3 Arquitectura del Sistema Operativo Palm..................................................... 32
II.4 Tipos de aplicaciones................................................................................... 35
II.4.1 Aplicaciones Web reducidas .............................................................. 35
II.4.2 Aplicaciones estándar de Palm .......................................................... 37
II.4.3 Conduits ............................................................................................. 38
II.5 Estructura de una aplicación Palm. .............................................................. 39
II.5.1 Como se genera un ejecutable .......................................................... 41
II.5.2 Common Object File Format .............................................................. 43
II.5.2.1 Archivo Objeto ...................................................................... 43
II.5.2.2 COFF.................................................................................... 44
II.5.2.3 COFF y Palm ........................................................................ 46

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

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

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

V
LISTA DE FIGURAS

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


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

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

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

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

Sin embargo, hoy en día, Internet, la televisión, las telecomunicaciones, etc.


permiten que se tenga acceso a la tecnología de forma mas o menos simultanea
en todo el mundo.

Un ejemplo de esta afirmación es la plataforma de asistentes personales


digitalizados desarrollados por la Firma Palm Inc. cuyo último dispositivo: el Palm
Tungnsten T, se presentó en México antes que en el resto del mundo.

Los asistentes personales digitalizados son una plataforma de un gran potencial,


ya que poseen una capacidad de procesamiento poderosa a un precio
relativamente bajo.

Pero además, en el área de desarrollo de aplicaciones para estos dispositivos se


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

Con todo, la programación de aplicaciones para dispositivos móviles es un área de


incipiente crecimiento en México. Incluso en el mundo (según cifras de Palm Inc.)
el número de desarrolladores registrados es de apenas varios cientos.

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

Sin pretender convertirse en la piedra angular de la programación para


dispositivos móviles en México este trabajo busca, precisamente: proponer, dar
ideas, pasar de ser usuarios a ser desarrolladores de nueva tecnología.

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

En nuestros días el software tiene un doble papel: es un producto que permite


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

Figura 1.1 Tipos de software

5
Dentro del gran conjunto de programas representados por el termino "software",
se pueden hacer dos grandes divisiones, de acuerdo a la función que
desempeñan. Una formada por el llamado Software de Sistema, encargado de
apoyar al usuario en la administración de su hardware, y la otra conformada por el
Software de Aplicación, subconjunto que agrupa a todos los programas que
resuelven necesidades y problemas específicos de los usuarios. Así, cuando un
usuario desea capturar un texto y darle formato, utilizar distintos tipos y tamaños
de letra y revisarlo ortográficamente, tiene que recurrir a un software de aplicación.
Igual debe hacerlo si desea capturar y manipular grandes volúmenes de datos, o
hacer muchos cálculos o si lo que quiere es construir imágenes y darles
animación. Mientras que si respalda archivos o administra impresoras, estará
usando software de sistema. Aunque el término "Sistema" se usa también como
sinónimo de software, y en especial en el presente documento, específicamente
del software de aplicación.

Pero, para que la computadora pueda ejecutar cualquier tarea, se le debe


programar para que la haga, colocando en su memoria principal un algoritmo
apropiado, expresado en algún lenguaje de programación.

I.2 Lenguajes de Programación


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

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

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

La Enciclopedia de Términos de Microcomputación define Lenguaje de


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

También para [Joyanes, 1988] un lenguaje de programación es un conjunto de


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

La sintaxis es el conjunto de reglas que gobiernan la construcción o formación de


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

El vocabulario de un lenguaje es un conjunto de símbolos. Los símbolos usuales


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

Según menciona [Brookshear, op. cit.], la implantación de los lenguajes de


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

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

Anál i s i s Gener aci ón


Anál i s i s
l éx i c o s i n t ác t i c o de c ódi go

Pr ogr ama Pr ogr ama


Fuent e ob j et o

Figura 1.2 Construcción de un ejecutable

El análisis léxico es el proceso de reconocer qué cadenas de símbolos del


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

La segunda actividad del proceso de traducción, el análisis sintáctico, es el


proceso de analizar la estructura gramatical de un enunciado y reconocer el papel
de sus componentes.

A fin de simplificar la tarea del análisis sintáctico, la colección de estructuras de


enunciados que tiene un lenguaje de programación es menos variada que la de un

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

La actividad final en la traducción de un programa es la generación de código, es


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

I.2.2 Evolución de los Lenguajes de Programación


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

Los primeros lenguajes de programación -lenguajes de maquina y 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

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

Figura 1.3 Ensamblador, Compilador e Interprete

Los lenguajes ensambladores representaron un gran avance en la búsqueda de


mejores ambientes de programación. Por ello, se les denominó lenguajes de
segunda generación, siendo la primera generación la de los propios lenguajes de
máquina.

Aunque los lenguajes de segunda generación tenían muchas ventajas respecto a


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

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

Otra desventaja de los lenguajes ensambladores es que el programador, aunque


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

Las primitivas elementales en que se debe expresar finalmente un producto no


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

De acuerdo con esta filosofía se empezaron a crear lenguajes de programación


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

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

En general, la estrategia para crear lenguajes de programación de tercera


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

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


programa llamado traductor, que traducía a lenguaje de máquina los programas
expresados en dichas primitivas de alto nivel. Todo lo que tenía que hacer el
traductor era reconocer las primitivas y convertirlas en sus equivalentes en
lenguaje de máquina.

I.2.3 Clasificación de los Lenguajes de Programación


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

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

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

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

Figura 1.4 Niveles de los lenguajes de programación

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

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

Los lenguajes de muy alto nivel presentan algunas desventajas graves: carecen
de flexibilidad; generalmente, cada uno está diseñado para un tipo específico de
tarea. No se puede, por ejemplo, procesar una nómina con un lenguaje de
procesamiento de palabras. Debido a que se enfocan a aplicaciones específicas,
los lenguajes de muy alto nivel a veces se conocen como lenguajes dependientes
del problema. Una segunda desventaja principal es que hay muchas aplicaciones
importantes que no son cubiertas por estos lenguajes. No obstante, en las áreas
para las cuales se encuentran disponibles, ofrecen obvias ventajas, tanto a los
programadores como a los usuarios.

I.2.4 El proceso de la programación


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

14
Se podría considerar la programación como el conjunto de actividades y
operaciones tendientes a indicar a la computadora como debe realizar las
funciones previstas en el algoritmo.

El proceso completo se enlista a continuación.

1. Detectar o definir un problema

2. Diseñar un Algoritmo de Solución

3. Escribir un programa

4. Ejecutar el programa

5. Validar resultados

6. Depurar el programa

Volver a (4)
Figura 1.5 Proceso de programación

Este proceso no ha cambiado a lo largo del tiempo ni con la evolución de los


lenguajes de programación. En todo caso, cada nueva generación (lenguaje) ha
ido haciendo más fácil y / o eficiente, una o mas etapas de este proceso.

I.3 Tipos de Sistemas de Cómputo


Un sistema es una colección de elementos y procedimientos que interactúan para
cumplir una meta. Un partido de fútbol, por ejemplo, se juega conforme a un
sistema. Consta de una colección de elementos -dos equipos, un campo de
juego, árbitros- y procedimientos -las reglas del juego- que interactúan para
determinar qué equipo es el ganador. Un sistema de tránsito es una colección de
personas, máquinas, reglas de trabajo, tarifas y programas que llevan a las
personas de un lugar a otro. Y un sistema computacional es una colección de
personas, hardware, software, datos y procedimientos que interactúan con el
objeto de realizar tareas de procesamiento de datos.

La función de un sistema, ya sea manual o computarizado, es mantener a la


organización bien administrada y funcionando sin altibajos. Los sistemas se crean

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

I.3.1 Aplicaciones Monolíticas


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

Una limitación de esta arquitectura es que rara vez soporta interfaces gráficas, o
puede acceder a múltiples bases de datos.

I.3.2 Modelo Cliente / Servidor


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

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

La arquitectura "peer to peer" se refiere a un tipo de red en la que cada estación


de trabajo tiene capacidades y responsabilidades equivalentes, por lo que es
económica y fácil de implementar, aunque cuando esta sometida a grandes cargas
de trabajo no ofrece el desempeño de otras arquitecturas.

El termino cliente / servidor fue usado por vez primera en la década de los 80
para referirse a las computadoras personales (PC) conectadas a una red. El
modelo Cliente / Servidor como se concibe actualmente empezó a ganar
aceptación a finales de esa misma década.

En este modelo, un cliente es un ente que solicita servicios o recursos, mientras


que el servidor es el ente que los ofrece. Estos entes pueden ser computadoras o
procesos en una red. Los servicios ofrecidos pueden ser archivos, dispositivos e
incluso procesamiento de instrucciones.

Figura 1.6 Comunicación Cliente / Servidor

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

Desde el punto de vista de la programación, se considera a la arquitectura cliente /


servidor como la extensión lógica de la programación modular.

La programación modular se basa en el hecho de que al separar una pieza de


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

18
Figura 1.7 Clientes y servidores en Internet

En el modelo cliente / servidor, el procesamiento de la computadora se divide


entre los "clientes" de una red y los "servidores", con cada función asignada a la
máquina con más capacidad para llevarla a cabo (la parte del cliente en una
aplicación corre en el sistema de los clientes, y la parte de la aplicación
correspondiente al servidor, en la o las computadoras servidores). El usuario
generalmente interactúa solo con la porción del cliente de la aplicación, que en
general consiste en la interfaz de usuario, el proceso de captura de datos, la
consulta a la base de datos y la obtención de informes. El servidor realiza las
funciones de fondo, no visibles por los usuarios, como la administración de los
dispositivos periféricos o el control del acceso a las bases de datos compartidas.

La división exacta de las tareas depende de los requerimientos de las


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

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

• La combinación de un cliente o front-end que interactúa con el usuario, y un


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

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


diferentes (espacio en disco, velocidad del procesador, dispositivos de
entrada / salida, etc.). El sistema operativo también puede ser diferente.

• Típicamente se trata de ambientes heterogéneos, conformados por


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

• Una característica muy importante de estos sistemas es su escalabilidad.


Ya que pueden ser escalados tanto horizontalmente (añadiendo o quitando
clientes), como verticalmente (migrando los servicios a equipos más
potentes) con un impacto mínimo en su desempeño general.

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


escritos como dos componentes separados de software que corren en distintas
máquinas pero que operan como una sola aplicación.

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

Figura 1.8 Sistemas Distribuidos

El funcionamiento de Internet esta basado en este concepto, ya que básicamente,


se puede considerar al Web como un sistema distribuido de hipermedia [Wilde,
1999] en el que la información se encuentra almacenada en forma de páginas
Web, que se encuentran entrelazadas unas con otras mediante ligas URL.

Existen programas cliente, llamados navegadores, y programas servidores


localizados en diferentes lugares geográficos. El programa servidor se ejecuta en
un host de Internet, y responde a las solicitudes de información que le hacen los
clientes. Cuando recibe una solicitud, el servidor debe responderla en forma
simple, dejando al cliente o navegador, la responsabilidad de determinar la forma
apropiada en que esta información debe ser mostrada al usuario. Este mecanismo
de trabajo facilita que en los servidores se pueda mantener almacenada
información en formatos muy diferentes.

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

I.3.4 Cómputo Móvil


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

La tecnología de intercambio de datos a través de comunicación móvil se a


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

22
Figura 1.9 Cómputo Móvil

El cómputo móvil permite sincronizar y controlar procesos y eventos donde el


acceso a datos e información es prácticamente imposible por otros medios.
Algunos ejemplos de aplicación del cómputo móvil son:

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

• Envío de fotografías de siniestros desde el lugar del accidente para su


análisis, interpretación y devolución (ajustadores de seguros).

• Monitoreo y diagnóstico especializado de máquinas para su mantenimiento


y reparación en el campo (por ejemplo bombas de agua, de gas, de aceite).

• Acceso a planos y datos para la administración de servicios públicos


(drenajes, energía eléctrica).

• Monitoreo de descargas de aguas residuales.

El cómputo móvil facilita los servicios de venta, facturación, cobranza y calidad en


el servicio obteniendo y proporcionando datos e información en el lugar y en el
momento donde se realiza la operación. Por ejemplo, proporcionando información

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

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

En otros países, el cómputo móvil ha resultado de mucha utilidad en eventos


especiales de conteo o levantamiento de encuestas: Aplicando encuestas sobre
preferencias o evaluando algún producto o servicio, contando periódicamente
artículos de venta en estantes especializados y enviando esta información a
centros de logística (periódicos, revistas).

A través del uso de circuitos integrados (microlocalizadores) y ayuda satelital es


posible rastrear productos, unidades móviles o bien personas, permitiendo
replantear rutas de servicio o transporte en casos de emergencia (accidentes,
robos), proponer mejores rutas de acceso, localizar unidades para el control de
paradas y consumo de combustible, dar seguimiento a unidades de transporte
bancario.

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

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

25
CAPITULO II
DESARROLLO DE APLICACIONES PARA
ASISTENTES PERSONALES DIGITALIZADOS
II.1 Introducción a las PDAs
Antes de hablar sobre el desarrollo de aplicaciones para Asistentes Personales
Digitalizados (PDAs) por sus siglas en ingles, se mencionarán algunas
características de estos.

Se hará una mención especial de las características de las aplicaciones de la


marca Palm, que actualmente, según su fabricante, son las más ampliamente
difundidas.

Figura 2.1 Palm m505

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

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

27
Figura 2.2 Palm IIIe

Además de los usos descritos, se han desarrollado muchas aplicaciones para


PDAs y recientemente, se les empieza a combinar con teléfonos y sistemas de
radio localización.".

La compañía pionera en el desarrollo de PDAs fue Apple, quien introdujo al


mercado su computadora Newton en 1993.

Según la página oficial de Palm (www.palm.com): "los modelos de esta compañía


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

II.2 Arquitectura de Hardware de la plataforma Palm


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

28
Figura 2.3 El procesador Dragonball

El Dragonball fue ideado como una versión de bajo consumo de Motorola


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

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

En estos dispositivos, que a diferencia de las computadoras de escritorio, no


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

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

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

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

También existen tarjetas de memoria que permiten aumentar la capacidad de


almacenamiento de los dispositivos. Por ejemplo, hay tarjetas CompactFlash para
dispositivos como el TRGpro de HandEra que permiten almacenar 40MB
adicionales.

Sony por su parte comercializa otro dispositivo de expansión de memoria conocido


como MemoryStick que permite almacenar hasta 128MB de información. Sin
embargo este tipo de memoria es más lento que la memoria RAM incluida en los
dispositivos.

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

•a través del digitalizador de escritura y

•a través de la pantalla.

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

Comúnmente la pantalla de cristal líquido tiene unas dimensiones de 160 x 160


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

En todos los modelos la pantalla es táctil, para permitir la interacción con el


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

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

El Palm tiene 2 formas de interconectarse con otros dispositivos; mediante


comunicaciones por infrarrojo (IrDA), o mediante comunicaciones serie.

El sistema IrDA permite comunicarse y compartir información con cualquier


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

31
El puerto serie permite conectarse tanto con la PC como con otros dispositivos. La
comunicación serie esta completamente basada en interrupciones para la
transmisión de datos. Se utilizan cinco señales externas para soportar esta
comunicación:

SG (signal ground)

TxD (transmit data)

RxD (receive data)

CTS (clear to send)

RTS (request to send)

La PDA se comunica con la PC a través de la base (cradle). La base es una


interfaz entre el PC y el Palm. Se trata de un soporte de plástico cuyas funciones
son: recargar las baterías del Palm (cuando el modelo lo permite) y sincronizar los
datos del Palm con la PC mediante la pulsación de un botón.

La sincronización a través de la base se realiza usando el puerto serie, pero los


modelos recientes de Palm incluyen un puerto de infrarrojos y soporte para el
protocolo de comunicaciones TCP/IP (empleado por ejemplo por los navegadores
web) .

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


dispositivos.

II.3 Arquitectura del Sistema Operativo Palm


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

32
Figura 2.4 Arquitectura del PalmOS

Como se muestra en la figura anterior (Figura 2.4) el sistema operativo da soporte,


desde los servicios y librerías del sistema hasta la capa de abstracción del
hardware.

A continuación se describen los elementos mas relevantes del sistema operativo,


desde el punto de vista del programador.

Eventos: Los eventos informan a la aplicación de qué es lo qué está ocurriendo en


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

La memoria y sus limitaciones: La memoria en los Palm es un recurso muy


escaso. La RAM está dividida en dos áreas, la memoria de almacenamiento

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

La memoria dinámica se utiliza, tanto para las variables globales y variables


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

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

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

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

Los controles se almacenan como recursos de la aplicación, estos son necesarios


cuando se necesita crear un elemento de interfaz de la aplicación, ya que un
recurso define cual es la apariencia del elemento y donde está colocado dentro del
formulario.

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


en tiempo de compilación, aunque estos menús pueden cambiarse
dinámicamente. Los menús se componen de barras de menú y de opciones dentro
de estos. Estas opciones del menú podrán tener asociados atajos (shortcuts). Los

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

Comunicaciones: Palm OS da soporte a tres protocolos de comunicaciones IrDA,


serie y TCP/IP. El sistema operativo proveerá de una serie de funciones para
trabajar con estos protocolos. TCP/IP esta disponible sólo sobre el puerto serie o
sobre una conexión con MODEM. Para utilizar TCP/IP se utiliza el Palm Software
Development Kit (Herramientas de Desarrollo de Software, distribuidas
gratuitamente por Palm), esta Interfaz de desarrollo de aplicaciones tiene una
librería de sockets y esta diseñada de forma muy similar al API de sockets de
Berkley.

II.4 Tipos de aplicaciones


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

II.4.1 Aplicaciones Web reducidas


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

Estas paginas HTML comprimidas deben ser compactas y pequeñas,


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

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

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

La ejecución de estas páginas web se realiza mediante el visor de aplicaciones


web. Cuando el usuario pulsa el icono de una aplicación web, se lanzará primero
el visor y este mostrará el contenido de la pagina web.

36
Figura 2.6 Otra vista de una aplicación web reducida

II.4.2 Aplicaciones estándar de Palm


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

Figura 2.7 Calculadora

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

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

Figura 2.8 Juego pBill para Palm

Las aplicaciones Palm OS se compilan en archivos PRC (Palm Resource File). Un


mismo fichero PRC correrá en todos los dispositivos Palm OS.

Figura 2.9 Reloj

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

Este tipo de aplicaciones sólo se desarrolla cuando se debe realizar una


traducción del formato de los datos. Existe un kit de desarrollo especial para estas
aplicaciones: Palm Conduit Development Kit (CDK), además de las soluciones
ofrecidas por terceros.

38
Figura 2.10 Conduit de sincronización diaria de Palm

II.5 Estructura de una aplicación Palm.


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

Es responsabilidad del programador decidir para que eventos se programará una


respuesta específica, dejando el control del resto al Sistema Operativo.

Cuando el sistema operativo lanza una aplicación, invoca a la función PilotMain y


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

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

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

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

Si se realizó un arranque normal, la función PilotMain invoca a StartApplication (en


esta función se recomienda inicializar las bases de datos y obtener del sistema
operativo las preferencias del usuario), enseguida, llama a la función
FrmGotoForm, quien se encarga de cargar y mostrar la forma indicada.

Después la ejecución pasa a la función EventLoop, quien es la responsable de


procesar todos los eventos recibidos por la aplicación.

Cada nuevo evento se acomoda al final de la cola de eventos, de donde la función


EventLoop los va tomando y procesando, en el siguiente orden:

Eventos del sistema

Eventos de la barra de menú.

Eventos que carguen en memoria una nueva forma

Eventos específicos de la forma que se encuentra activa.

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


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

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

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


funciones de cualquier aplicación Palm:

Figura 2.11 Secuencia de llamadas de Funciones

La función denominada en el diagrama como PersonalHandleEvent es la


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

II.5.1 Como se genera un ejecutable


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

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

En el caso específico de la programación para dispositivos Palm, se deben


generar archivos de "recursos" que describen la interfaz con el usuario y su
funcionamiento. Normalmente, estos archivos se obtienen usando un programa
independiente del compilador o del ambiente de desarrollo integrado.

Los archivos de recursos contienen la jerarquía de objetos de la interfaz gráfica,


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

El resto del proceso de desarrollo consiste en codificar la respuesta a los eventos


que le pueden ocurrir a los diferentes objetos de la forma.

Una vez que se ha generado un programa, se procede a compilarlo, depurarlo,


corrigiendo los eventuales errores y repitiendo esta ultima parte del proceso hasta
que se obtiene un programa libre de errores.

En esta etapa, es poco conveniente probar los programas en dispositivos reales,


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

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

0
Codigo 1 Loader
Maquina 0
1
1

Mnemonicos Ligador
Ensamblador
Ensamblador mov AX,0
llda BX
Memoria
Compilador

Lenguaje Lenguajes
de de
Alto Programación
(P.E. Interprete
Nivel
Pascal)

Figura 2.12 Niveles de programación

II.5.2 Common Object File Format


II.5.2.1 Archivo Objeto
Como se explica en [PCWebopaedia, 2003] cuando se programa, se escribe
código en forma de código fuente: instrucciones de algún lenguaje particular, como
C o Fortran. Sin embargo las computadoras sólo pueden ejecutar instrucciones
escritas en lenguaje de máquina.

Para pasar de código fuente a lenguaje de máquina, los programas deben ser
transformados por un compilador. El compilador genera un archivo intermedio con
código llamado objeto. Este archivo sirve de entrada al encadenador (linker) que
resuelve las llamadas que el archivo objeto hace a las librerías propias del

43
lenguaje. El termino "archivo objeto" no necesariamente implica alguna conexión
con la programación orientada a objetos.

Como se ha señalado, cuando un compilador procesa el código fuente (en nuestro


caso, en C o C++), genera un archivo objeto, que posee un formato específico. En
Windows, los compiladores generan archivos en formato PE COFF. En Linux,
GCC puede generar archivo en formato ELF (u otro, dependiendo de la necesidad
del programador y la configuración del ambiente de desarrollo).

Figura 2.14 Generación de un ejecutable.

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

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

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

La mayor dificultad que se presenta cuando se desarrollan ejecutables en código


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

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


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

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

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

II.5.2.3 COFF y Palm


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

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

46
Las PRC-Tools producen código en formato m68k-coff, es decir, código para
procesadores de la arquitectura M68000 de Motora, usando el formato binario
COFF.

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


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

 
 



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


65728 9:;3 <.=)5.283 '4 $>5./289:2?3 <*@)
)A#3



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


C)C C3 <=C C)C3 'D=FE3 8
B $GC C)C3 <.=)CCC3 'H;I)
A43

/E3B)= </ $GJ-'"<


KL # ,!#


(MN)O.P)AB(2P/   P/Q) $ (R
BA))S(*A6!#
BA"!# '(*GTU&VI3


 ' <,
WKG))  $ (*
A,G * A.(*
AB)X(*AW!#
AB4!  '(*&Q3


)8"Y+P/' $GZ[(G8
\ *ABA (0 ,G(0MN)OP  A(0DP#  P#)8 Y"P#'43


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

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


6%& AA3 '  $-eYD "!#"8A1 '15XA( 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

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

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

50
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

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

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

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

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

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

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

57
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 Archivo de Funciones que controla


Abstracción encabezado
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

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

// miString.h

#ifndef _MI_STRING_H_

#define _MI_STRING_H_.

#include <StrMgr.h>

class String{

char cTexto[100];

public:

miString(char *cadena);

59
}

#endif

Enseguida, se crea un archivo String.cpp, con la implementación de los métodos


de la clase:
// miString.cpp

miString miString(char *cadena){

StrPrintF(cTexto,"%s",cadena);

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


#include "miString.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.

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

61
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

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

63
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

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

65
CAPITULO III
OMT PARA EL ANÁLISIS Y DISEÑO DE
APLICACIONES EN ASISTENTES PERSONALES
DIGITALIZADOS
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

67
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

68
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

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

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

71
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
diccionario de datos.

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

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

74
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

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

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

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

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

79
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

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

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

82
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

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

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

85
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

86
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

87
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 Sony Clie PEG-SJ30
Pocket PC
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

88
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 11.2 x 7.4 x 1.6 11,4 x 7,9 x 12,7 4.66" x 3.12" x 4.66" x 3.12" x 4.66" x 3.12" x 4.66" x 3.12" x
cm cm cm. 0.72" 0.72" 0.72" 0.72"

Vibrador si no si no no no no

Memoria Flash si no si no no no no

Pantalla Alta resolución. Monocroma 65.000 colores 65.000 colores escala de grises escala de grises escala de grises

65.536 colores.

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 Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks,
agregar datos y mucho datos y mucho datos y mucho datos y mucho datos y mucho datos y mucho datos y mucho
aplicaciones más... más... más... más... más... más... más...

Tipo Recargable litio- Recargable litio- Recargable litio- Recargable litio- AAA AAA AAA
ion ion ion ion

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

Comunicación vía si. Tiene Slot si si. Tiene Slot si. Tiene Slot si. Tiene Slot si si
puerto serial para tarjetas de para tarjetas de para tarjetas de para tarjetas de
expansión. expansión. expansión. expansión.

Infrarrojo si si si si si si si

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

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

Fabricante Modelo Precio Memoria Capacidad Procesador Velocidad Tipo de Versión del Capacidad Tipo de Resolución Area útil Profundida
estimado RAM para Pantalla d
de del Método de Sistema Sistema de la de la
Máximo Instalada Operativo Operativo actualizar pantalla de
Expansión Procesador sincronizaci Pantalla
(U$) el
ón (pulgadas color
Sistema cuadradas)
Operativo

Blackberry H1100 $499 5M No Intel 386 N/D Serial, BlackBerry N/D N/D Monocrom 160 x 160 7 N/D
Infrarrojo o

Casio Cassiopeia $479 32M Compact NEC 131 MHz Infrarrojo, Pocket PC Windows N/D Color 240 x 320 3.9 16 bits
E-105 Flash Serial CE 2.1

Compaq iPaq $604 64MB Secure Intel 206 MHz Infrarrojo, Pocket PC Pocket PC Si Color 240 x 320 3.77 16 bits
H3850 Digital StrongARM USB 2002

Diamond Mako $149 16MB No ARM 710 T 36 MHz Infrarrojo, EPOC EPOC R5 Si Monocrom 240 x 320 7.4 N/D
RISC Serial o

Handspring Treo 180 $499 16MB No Motorola 33 MHz USB Palm OS 3.5.2 o Si Monocrom 160 x 160 3 N/D
Dragonball superior o
VZ

Visor $92 2MB Springboar Motorola 16 MHz Infrarrojo, Palm OS 3.1 Si Monocrom 160 x 160 3.1 N/D
d Dragonball USB o
EZ

Visor $109 8MB Springboar Motorola 16 MHz Infrarrojo, Palm OS 3.1 Si Monocrom 160 x 160 3.1 N/D
Deluxe d Dragonball USB o
EZ
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)

Fabricante Modelo Precio Memoria Capacidad Procesador Velocidad Tipo de Versión del Capacidad Tipo de Resolución Area útil Profundida
estimado RAM para Pantalla d
de del Método de Sistema Sistema de la de la
Máximo Instalada Operativo Operativo actualizar pantalla De
Expansión Procesador sincronizaci Pantalla
(U$) el
ón (pulgadas color
Sistema cuadradas)
Operativo

HP Jornada $833 32MB Tarjeta PC, StrongARM 206 MHz Infrarrojo, Pocket PC Windows Si Color 640 x 240 6.5 16 bits
720 Compact RISC serial, USB para
Flash Handheld
PC 2000

Palm Tungsten T $499 16MB MultiMedia Texas N/D Infrarrojo, Palm OS 5 Si Color 320 x 320 N/D 16 bits
Card, Instruments USB
SmartMedi OMAP
a 1510

m100 $93 2MB No Motorola 16 MHz Infrarrojo, Palm OS 3.5 Si Monocrom 160 x 160 3.3 N/D
Dragonball serial o
EZ

Palm IIIc $88 8MB No Motorola 20MHz Infrarrojo, Palm OS 3.5 Si Color 160 x 160 4.1 8 bits
Dragonball serial
EZ

Sony CLIE PEG- $150 8MB Memory N/D N/D USB Palm OS 4.1 Si Monocrom 160 x 160 4.1 N/D
SL10 Stick o

PC

ACER Aspire A partir de hasta 3 GB Si Intel 2.4 a 2.8 N/A Opcional Si Color 1600 x 350 x 262
G600 p $800 GHz (Windows) 1200 mm
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)

Fabricante Modelo Tipo de Duración Soporte a Tamaño Peso Características Adicionales

Baterías (1) estimada tecnología (Alto, Largo, Ancho) (onzas)

(hrs) Bluetooth en pulgadas

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

Casio Cassiopeia E- Recargable (2) 6 No 5 x 3.3 x 0.7 9 Entrada para audífonos, microfono, entrada para tarjeta
105 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- AAA N/D No 4.6 x 2.8 x 0.6 3.6 Software multimedia
SL10
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)

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 disponible
N/A No aplica
CAPITULO IV
CASO DE ESTUDIO: SVES
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

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

97
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

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

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

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

101
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:Padecimiento probable: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

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

103
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

104
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

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

106
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

107
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

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

109
La plantilla de diagnóstico considera 24 padecimientos, integrados en 11 grupos:

Infecciones intestinales parasitarias Enfermedades por picadura de


Diarrea y deshidratación mosco
Paludismo
Amibiasis
Dengue
Diarrea infecciosa

Parasitosis intestinal Enfermedades crónicas


Diabetes mellitus
Enfermedades respiratorias
Presión alta
Catarro o influenza

Neumonía Problemas de la nutrición


Bronquitis Desnutrición

Tuberculosis
Intoxicación por ponzoña
Anginas
Picadura de alacrán
Otitis
Otras enfermedades
Enfermedades del sistema nervioso Enfermedades de la piel
Parálisis
Infecciones vaginales
Ataques

Agresión por animal Accidentes y violencias


Atención de accidentes
Enfermedades Infecciosas
Enfermedad exantemática 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.

110
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

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

112
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

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

114
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

115
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

116
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 Adicionales
Botón Botón gráfico Checkboxes
Campo Campo texto como botón Campo texto para desplegar
datos
Flecha 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.

117
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 Button
Checkboxes Feedback Slider Control Field
Graffiti Shift Indicator Label List
Popup Trigger Selector Trigger Slider Control
Gadget Scroll bar

De este modo, se conforma la lista completa de objetos:

Forma Flecha de desplazamiento Combo


Barra de desplazamiento Menús Formas Adicionales
Botón Botón gráfico Checkboxes
Campo Campo texto como botón Campo texto para desplegar
datos
Flecha que indica mayúsculas Etiqueta Lista
Tabla Button Graphic Button
Push Button Repeating Button Graphic Push Button
Graphic Repeating Button Checkboxes Feedback Slider Control
Field Graffiti Shift Indicator Label
List Popup Trigger Selector Trigger
Slider Control Gadget Scroll bar

118
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: formas
desplegables que presentan información al usuario, Formas
de 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

119
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 comoCampo que cumple con la misma funcionalidad que un
botón botón.
Campo texto paraSinónimo de Campo
desplegar datos
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 indicaSinónimo de Graffiti Shift Indicator
mayúsculas
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 deElemento de la interfaz gráfica que facilita el desplazamiento
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

120
de la barra de desplazamiento. Es parte de la Barra de
desplazamiento
Flecha de Sinónimo de Slider Control
desplazamiento
Feedback SliderElemento de la interfaz gráfica que muestra la posición
Control 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

121
PopupTrigger
SelectorTrigger

IV.6.1.4 Diccionario de Datos


Al finalizar esta actividad, ya han sido indicadas las primeras definiciones en el
diccionario de datos.

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

122
(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 x
información que quedará oculta por la forma
Bandera que define la forma en que se debe desplegar el texto x
(Anchor Left)
Bandera que indica si el objeto tiene borde x
Bandera que indica si el texto del objeto se desplegara en x
Negritas
Bandera que indica si el objeto se dibuja seleccionado la x
primera vez
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 x
(independientemente de su tamaño)
Bandera que indica si el tamaño del campo puede cambiar x
Bandera que indica si el texto del campo se desplegará x
justificado a la izquierda
Bandera que indica si el primer carácter del campo se escribe x
en mayúscula
Bandera que indica si el campo tiene Barra de desplazamiento x
Bandera que indica si el campo recibirá solo caracteres x
numéricos.
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

123
Identificador del grupo al que pertenece el objeto x
Número máximo de caracteres que se pueden escribir en el x
Campo
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

124
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

125
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

126
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
Termina el Caso de Uso

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
Termina el Caso de Uso

El caso de uso genera el diagrama de flujo de eventos de la Figura 4.14.

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

128
#ifndef CIGCHECKBOX_H

#define CIGCHECKBOX_H

#include "clabeledobject.h"

#include "cstring.h"

class cIGcheckBox: public cLabeledObject {

// Associations

// Attributes

private:

Boolean selected;

UInt8 groupID;

// Operations

public:

cIGcheckBox ( FormPtr frmP, UInt16 objectID );

cIGcheckBox ( FormPtr frmP, UInt16 objectID, cString laCadena );

cIGcheckBox ( FormPtr frmP, UInt16 objectID, char * laCadena );

void select ( Boolean valor );

Boolean isSelected ( );

void setGroup ( UInt8 elGrupo );

UInt8 getGroup ( );

};

#endif

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:

129
void cIGcheckBox::select ( Boolean valor ){

selected = valor;

CtlSetValue ((ControlPtr) anObjectPtr, valor);

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.

Boolean cIGcheckBox::isSelected ( ){

selected = CtlGetValue ((ControlPtr) anObjectPtr);

return selected;

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 Modelo de Objetos


IV.6.2.2.1 Identificación de Objetos y Clases
Una vez más, al extraer el sujeto del enunciado del problema (EP):

130
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

131
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

132
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

133
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

134
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

IV.6.2.5 Modelo Dinámico


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

135
cModelo aplica algoritmo para encontrar posibles padecimientos
cModelo muestra lista de posibles padecimientos encontrados.

Flujo Alterno MD01B: Usuario termina el programa


Termina el Caso de Uso

Flujo Alterno MD02B: Usuario termina el programa


Termina el Caso de Uso

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

IV.6.2.6 Modelo Funcional


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 para
proponer su implementación, una vez más se debe recurrir a algunos de los
pá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. Preguntar al paciente que molestias tiene.


1.1 Para cada molestia:
1. Localizar la molestia en las listas de molestias, a partir de su

136
inicial
1.1.2 Señalar en la caja correspondiente, la molestia referida
2. Almacenar en arregloSintomas, la clave del síntoma, la bandera
“presente”
1.1.4 Si no hay mas molestias, ir al paso 2
1.1.5 Volver a 1.1.1
2. Para cada elemento de arregloSintomas:
2.1 Almacenar el numero de síntoma en la variable claveSintoma
2.2 Recorrer la matriz plantillaDiagnostico
2.2.1 En el n-simo renglón
2.2.1.1 Si la columna con número claveSintoma tiene almacenado un valor
mayor que 0.
(El síntoma esta presente en el padecimiento)
2.1.1.1.1 Recorrer el renglón. Si la columna tiene almacenado un 1
2.1.1.1.1.1 Almacenar en arregloSintomas la clave del síntoma,
bandera “desconocido”
2.3 Almacenar en bandera el valor “agotado”
3. Para cada elemento de arregloSintomas:
3.1 Si la bandera es “desconocido”
3.1.1 Mostrar la pantalla que corresponde al Síntoma
3.1.2 Almacenar la respuesta (en bandera) como “presente” o “ausente”,
según la respuesta del paciente
4. Recorrer la matriz plantillaDiagnostico
4.1 En el n-simo renglón
4.1.1 Recorrer el renglón. Si la columna tiene almacenado un numero mayor
que 0
4.1.1.1 Localizar el Síntoma cuya clave corresponda al numero de columna
de plantillaDiagnostico
4.1.1.2 Si la bandera del síntoma es “ausente” y en plantillaDiagnostico
el valor es 1 (obligatorio), entonces el padecimiento no existe.
Regresa a 4.1
4.2.1 Si se llegó al fin del renglón, el padecimiento si existe. Almacenar
en arregloPadecimientos
4.2.2 Regresa a 4.1
5. Desplegar pantalla resultados.
6. Para cada elemento en arregloPadecimientos. Desplegar el nombre del
padecimiento.

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 parece
mejor crear una clase cDescripcion, a partir de la que se forman los vectores
respectivos de la clase cPlantillaDiagnostico.

Sin embargo, almacenar un nuevo síntoma no es tan trivial como simplemente


añadirlo a un vector.

137
Se requiere de una clase cArregloSintomas, cuyo método almacenarSintoma, se
describe a continuación:
1. Recorrer arregloSintomas, buscando la clave del síntoma

2. Si no existe, la almacena y regresa la posición en que quedo almacenada

3. Si existe y la bandera tiene el valor de agotado, regresa (0)

4. Si existe y la bandera tiene el valor de presente, regresa (-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).

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

static Err RomVersionCompatible(UInt32 requiredVersion, UInt16 launchFlags)


Esta función verifica que la versión del ROM cumpla los requisitos mínimos de la
aplicación.

static void * GetObjectPtr(UInt16 objectID)


El objetivo de esta función es regresar el apuntador a un objeto de la forma en
uso.

static Boolean MainFormDoCommand(UInt16 command)


Esta función ejecuta el comando de menú especificado.

static Boolean AppHandleEvent(EventPtr eventP)


Esta función carga los recursos y establece cual será la rutina encargada de
manejar los eventos de la forma que se esta poniendo en uso en un momento
dado.

static void AppEventLoop(void)


En esta función se implementa el ciclo de eventos de toda la aplicación.

static Err AppStart(void)


Las preferencias de la aplicación actual se establecen en esta función.

static void AppStop(void)


En esta función se guarda el estado actual de la aplicación, para recuperarlo
cuando la aplicación reinicie.

static UInt32 StarterPalmMain(UInt16 cmd, MemPtr /*cmdPBP*/, UInt16 launchFlags)


Esta función constituye el punto de entrada principal de la aplicación.

UInt32 PilotMain( UInt16 cmd, MemPtr cmdPBP, UInt16 launchFlags)


Esta función es invocada por el PalmOS para arrancar la aplicación. A su vez,
llama a StarterPalmMain.

139
static void MainFormInit(FormPtr /*frmP*/)
Esta función inicializa la forma MainForm

static Boolean MainFormHandleEvent(EventPtr eventP)


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.

IV.7.1.1 Modelo de Objetos


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

140
Figura 4.21 Modelo de objetos del Controlador

IV.7.1.2 Modelo Dinámico


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)

141
Flujo alterno MC01B. Usuario termina la aplicación.
Ocurre el Caso de Uso MV1B. Usuario o el PalmOS finalizan la
aplicación

IV.7.1.3 Modelo Funcional


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.

142
Figura 4.23 Diagrama de clases de la Vista.
CONCLUSIONES
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.

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

146
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

147
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? |Cabeceras.c 351 136? |cDataBase.cpp
638 274? |Canalizacion.c 41 24 |cDataBase.h
441 158? |Diagnostico.c 40 12 |cetiqueta.cpp
2210 856? |Formas.c 24 10 |cetiqueta.h
106 35? |IdPalm.c 51 13 |cigboton.cpp
1130 519? |MenuSintomaInicial.c 31 15 |cigboton.h
40 29? |Prototipos.h 36 9 |cigcheckbox.cpp
355 149? |Regreso.c 25 11 |cigcheckbox.h
246 44? |Seguimiento.c 298 65 |cigfield.cpp
585 222? |Starter.c 78 48 |cigfield.h
---------------- 11 0 |ciglabel.cpp
5889 2300? total lines/statements 60 19 |ciglabeledobject.cpp
30 14 |ciglabeledobject.h
884 lines had comments 15.0 % 18 5 |ciglabel.h
392 comments are inline -6.7 % 147 39 |ciglist.cpp
1020 lines were blank 17.3 % 50 26 |ciglist.h
21 lines for preprocessor 0.4 % 63 20 |cigscrollbar.cpp
4356 lines containing code 74.0 % 28 14 |cigscrollbar.h
5889 total lines 100.0 % 79 28 |cobjetominimo.cpp
35 18 |cobjetominimo.h
20479 comment-chars 12.6 % 82 30 |controlobject.cpp
16651 nontext-comment-chars 10.3 % 33 19 |controlobject.h
37461 whitespace-chars 23.1 % 62 16 |crectangletype.cpp
495 preprocessor-chars 0.3 % 30 15 |crectangletype.h
87298 statement-chars 53.8 % 491 103 |cstring.cpp
162384 total characters 100.0 % 138 46 |cstring.h
18 4 |cusableobject.cpp

148
7952 tokens, average length 8.66 21 6 |cusableobject.h
215 63 |precord.cpp
0.23 ratio of comment:code 67 39 |precord.h
756 ?:illegal characters found 655 121? |starter.cpp
----------------
3308 988? total lines/statements

743 lines had comments 22.5 %


241 comments are inline -7.3 %
671 lines were blank 20.3 %
129 lines for preprocessor 3.9 %
2006 lines containing code 60.6 %
3308 total lines 100.0 %

11138 comment-chars 14.4 %


8726 nontext-comment-chars 11.3 %
17599 whitespace-chars 22.7 %
2482 preprocessor-chars 3.2 %
37544 statement-chars 48.5 %
77489 total characters 100.0 %

4848 tokens, average length 6.84

0.28 ratio of comment:code


4 ?:illegal characters found

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.

149
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

150
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

151
BIBLIOGRAFÍA
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.

153
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
PROGRAMADORES. Madrid, España. (83 - 10 – 2001). 52-56.

CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (y III)”. En: SOLO
PROGRAMADORES. Madrid, España. (84 - 11 – 2001). 26-31.

154
É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/

155
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

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

157
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

158
ANEXOS

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

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

161
162
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ódigo


abierto aparecido en el boletín InterFAR Año 1, Número 5.

• Ponencia sobre el mismo tema, presentada en el Congreso Nacional de


Software 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, versiones


para Windows y Linux.

El contenido detallado se encuentra listado en el archivo CONTENIDO.TXT, en el


directorio raíz del mismo CD.

163