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

SVES. DESARROLLO DE APLICACIONES PARA DISPOSITIVOS MÓVILES

TESIS

QUE PARA OBTENER EL TÍTULO DE

INGENIERO EN COMPUTACIÓN

PRESENTA:

IVÁN CARLOS RIVERA GONZÁLEZ

ASESOR: EUGENIO JACOBO HERNÁNDEZ VALDELAMAR

MÉXICO, D.F.

MARZO DE 2003

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

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

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

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

III

III.4 Restricciones dadas por la plataforma ........................................................ 87 III.4.1 Los distintos modelos de Palm.......................................................... 89 III.4.2 Características generales de las computadoras de mano,

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

IV

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

V

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

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

VII

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

VIII

INTRODUCCIÓN

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

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

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

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

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

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

2

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

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

3

CAPITULO I DESARROLLO DE SISTEMAS

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

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

Figura 1.1 Tipos de software

5

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

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

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

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

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

6

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

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

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

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

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

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

implantación de los lenguajes de

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

7

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

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

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

Gener aci ón de c ódi go

Pr ogr ama Fuent e

Pr ogr ama ob j et o

Figura 1.2 Construcción de un ejecutable

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

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

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

8

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

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

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

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

El mecanismo de escoger nombres descriptivos para las celdas de memoria y usar nombres máquina. mnemónicos para representar códigos de operación, aumentó

considerablemente la comprensibilidad de las secuencias de instrucciones de

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

9

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

Figura 1.3 Ensamblador, Compilador e Interprete

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

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

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

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

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

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

11

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

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

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

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

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

12

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

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

Figura 1.4 Niveles de los lenguajes de programación

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

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

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

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

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

14

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

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

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

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

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

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

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

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

16

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

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

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

Figura 1.6 Comunicación Cliente / Servidor

17

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

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

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

18

Figura 1.7 Clientes y servidores en Internet

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

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

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

19

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

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

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

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

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

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

20

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

Figura 1.8 Sistemas Distribuidos

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

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

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

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

22

Figura 1.9 Cómputo Móvil

El cómputo móvil permite sincronizar y controlar procesos y eventos donde el acceso a datos e información es prácticamente imposible por otros medios. Algunos ejemplos de aplicación del cómputo móvil son: • • Acceso a expedientes clínicos en línea en casos de emergencia. Envío de fotografías de siniestros desde el lugar del accidente para su análisis, interpretación y devolución (ajustadores de seguros). • Monitoreo y diagnóstico especializado de máquinas para su mantenimiento y reparación en el campo (por ejemplo bombas de agua, de gas, de aceite). • Acceso a planos y datos para la administración de servicios públicos (drenajes, energía eléctrica). • Monitoreo de descargas de aguas residuales.

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

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

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

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

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

24

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

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

25

CAPITULO II DESARROLLO DE APLICACIONES PARA ASISTENTES PERSONALES DIGITALIZADOS

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

Figura 2.1 Palm m505

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

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

27

Figura 2.2 Palm IIIe

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

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

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

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

28

Figura 2.3 El procesador Dragonball

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

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

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

29

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

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

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

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

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

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

30

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

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

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

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

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

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

31

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

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

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

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

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

Figura 2.4 Arquitectura del PalmOS

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

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

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

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

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

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

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

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

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

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

Menús: Los menús están asociados con un formulario, generalmente se definen en tiempo de compilación, aunque estos menús pueden cambiarse

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

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

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

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

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

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

Estas

paginas

HTML

comprimidas

deben

ser

compactas

y

pequeñas,

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

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

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

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

36

Figura 2.6 Otra vista de una aplicación web reducida

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

Figura 2.7 Calculadora

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

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

Figura 2.8 Juego pBill para Palm

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

Figura 2.9 Reloj

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

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

Figura 2.10 Conduit de sincronización diaria de Palm

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

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

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

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

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

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

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

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

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

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

Este

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

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

40

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

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

Figura 2.11 Secuencia de llamadas de Funciones

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

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

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

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

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

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

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

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

42

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

Codigo Maquina

0 1 0 1 1
Mnemonicos Ensamblador Ligador

Loader

Ensamblador mov AX,0 llda BX

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

Figura 2.12 Niveles de programación

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

43

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

Figura 2.14 Generación de un ejecutable.

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

44

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

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

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

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

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

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

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

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

46

Q  ¨    D©9) XA'453 f8E#d#(‡#49E•”(V I#(‡(49© AH©9)  9#"X9)  I#(‡(49©q6  g   ) ¡    e ¡ ! £ 0 u  ` ¨ ) t “   Q £ 0 u  ` ¨ ) a  @  0 ) ¥ “ ¨ Q £ 0 u  ` ¨ ) 

1   #(V Q (¤9)  #G  i a ¨ Q i

Q £ ¡ ) € ‰ V 0 €  R¤954©A5¦' 5h#H©§§A(HqD©H©fB©(q‘q6 0 ¨ € £ 0 @ e  ¥ € y x w @ 0 !  @  e e  ’  V @  

Q #8B9) Rf§¢5‡(Bˆ) #Af§B@ F©B ©qD¤¢§B@ 0 ¨ ¨   @ 0   3  e ¥  3 e $ @ 0 !  e  ¥ 0 ¨ e ¡ 0 ¨ 0 !  e  ¥ 2

6

1   0 ¨ 0 u  ` ¨ )  AAq(‡D©9©¢ 

Q † … „  @ s8%qB9) 54#f5T§BƒA#Af§‚@ 0 0   3  e ¥  3 e $ @ ) 0 !  e  ¥ 2

6

¨ ¨  €  A#G¦' ©GP#"fA#FA§"@ 0 ¨ € £ 0 @ e  ¥ € y x w

¡ 3  ¡ $  5D©§5v#(u (49Eq6 £ 0  ` ¨ ) t

1 1 a ¨   Q i G§` Af#G 

Q £ ¡ e  R¤¤( ©(As Yr¤9) #¤AF` Q A©q6 0  ¨ ¥ 0 0 £ £ ¡ Q g g g a g g g

1   (f(V Q ph¤9) Q A©g (` #©A¢  i a £ ¡ g g a Q g g g

Q £ 0 £ ) $ ¨ ¡ ) ¡ !    ¨  e  ¥ 4#YP#4©9IDH¤©Af(B@ ©E#8D4H©'9©886 0 ¨ ¡ !  3  ¡  @  ) ) ¡ 7

Q e  5A( ©§Ad¤B` cPX(P§GFb6 0  ¨ ¥ 0 £ ¡ Q ¨ £ W  V ¡ $ ) S

1 ¥ ¨ Q  V ¡ $ ) S a §R9) #(P('FAF` Q YX©(P('UT  ¨ £ W  V ¡ $ ) S

Q £ 0 £ ) $ ¨ ¡ ) ¡ ! R#9P#49I#H ©§G'F ©E#E5DCBA9©886   ¨ ¨ $ ) 3 £ 0 ¨ ¡ !  3  ¡  @  ) ) ¡ 7

) 54('¦& 0 0 3 ¨ $ ) 3 £ 2

1 '©('&%#" ¤©©©§¦¤¢  0  )  $ £ $ ¡ !   ¨  ¨    ¨ ¡ ¥ £ ¡

Las PRC-Tools

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

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

COFF.

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.

↓ ↓
£ ¡ ) € ‰ V ¤9GC4A0

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

47
¨ ) e  9f(¥


Q f B˜ @ e  S  )  ¥ ¡ e V  3 $ ¨ ¡ ‰ e ¢¤ˆI9©(I(45#4©h§E6 1 ¨ ) Q 0 e e ¡ 7 ©9§¥ (©8T 

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

Q

d d ˜ FE™2

£ 0 u  ` ¨ )  ¡ ¨ $ #(‡D©9©E©§c! 9#A##A(4#A©(©5¦#§rD8D4"©9—–6 0 ) ¥ a 0 !   ¡ !  ¨  ¡ € 3 £ 0 ¥ ¡ !  3  ¡  @  ) ) ¡ 7

¨ ) ¥ € ! e  $ 9#((DV

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

de Archivo encabezado

de Funciones que controla

SysEvent MemoryMgr PalmTypes M68Khw BuildDefines ErrorBase DebugMgr Chars Encypt Event FloatMgr Comunicaciones ConnectionMgr

Eventos Memoria Tipos de datos elementales Hardware Definición de Variables Errores Funciones de depuración Caracteres de control Rutinas de Encriptamiento Control de Eventos Números de punto flotante

Interfaz de conexión. Permite a otras aplicaciones acceder al puerto de comunicación

Ctp Archivos DataMgr FileStream Find Interfaz de Usuario Form Window Control

Comunicación a través de Servidor Proxi

Tablas de datos Archivos Rutinas de control de búsquedas

Formas Ventanas Rutinas generales para manipular Controles

58

Table Field Font

Tablas Campos 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 Bitmap

Barra de desplazamiento 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 PRCTools.

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.tilochrist.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 este. pueden crear nuevas vistas o

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

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 Cassio Modelo Cassiopeia EM-500G Cassiopeia EM-505S Cassiopeia e-125 Pocket PC Compaq iPAQ 3660 iPAQ 3760 iPAQ 3830 iPAQ 3850 iPAQ 3870 iPAQ 3950 iPAQ 3970 Pocket PC iPAQ H3630 Pocket PC iPAQ - H3850 Pocket PC Fabricante Palm Inc. Modelo Palm III Palm IIIc Palm IIIe Palm IIIx Palm IIIxe Palm V Palm Vx Palm VII Palm M 100 Palm M105 Palm m125 Palm m130

Tabla 3.1 Lista de Modelos de PDAs por Fabricante

87

Fabricante Dell Ericsson Treo

Modelo Axim X5 Standard 300MHz MC218 Handera 330 Handspring Treo 270 Handspring Visor Handspring Visor Edge

Fabricante Palm Inc.

Modelo Palm m500 Palm M505 Palm m515

Psion

Psion Revo Psion Series 3a Psion Series 5

Hitachi HP

Eplate 600 et 200lx Jornada 525 pocket pc Jornada 545 Jornada 545/548 Jornada 568 64MB Pocket PC Jornada 720 PDA

Psion

Psion Series 5mx Psion Series 7 Sagem WA 3050

Sony

Sony Clie PEG N770C Sony Clie PEG S300 Sony Clie PEG-SJ30

Sony Clie PEG-T425 Sony Clie PEG-T625C Sony NR70VG Sony T625c Toshiba Pocket PC e570

IBM

WORKPAD Z50

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 Memoria Palm OS Tamaño

157 gr. 16 Mb 5 10.2 x 7.5 x 1.5 cm

109 gr. 2 Mb 4.1 11.2 x 7.4 x 1.6 cm no no Monocroma

139 gr. 16 Mb 4.1 11,4 x 7,9 x 12,7 cm. si si 65.000 colores

124 gr. 8 Mb 4.1 4.66" x 3.12" x 0.72" no no 65.000 colores

124 Gr. 8 Mb 4 4.66" x 3.12" x 0.72" no no

124 Gr. 2 Mb 3.5 4.66" x 3.12" x 0.72" no no

124 Gr. 8 Mb 3.5 4.66" x 3.12" x 0.72" no no

Vibrador Memoria Flash Pantalla

si si Alta resolución. 65.536 colores.

escala de grises escala de grises escala de grises

Direcciones Citas Agenda Memos E-mail Capacidad agregar aplicaciones Tipo

20,000 10 años 6,000 6,000 800

6,000 5 años 1,500 1,500 200

20,000 10 años 6,000 6,000 800

10,000 5 años 3,000 3,000 400

10,000 5 años 3,000 3,000 400

6,000 5 años 1,500 1,500 200

10,000 5 años 3,000 3,000 400

para Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, datos y mucho más... datos y mucho más... datos y mucho más... datos y mucho más... datos y mucho más... AAA datos y mucho más... AAA datos y mucho más... AAA

Recargable litio- Recargable litio- Recargable litio- Recargable litioion ion 1 mes si ion 1 mes si. Tiene Slot para tarjetas de expansión. si si ion 1 mes si. Tiene Slot para tarjetas de expansión. si

Vida (uso normal) Comunicación vía puerto serial

1 semana si. Tiene Slot para tarjetas de expansión.

2 meses si. Tiene Slot para tarjetas de expansión. si

2 meses si

2 meses si

Infrarrojo

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 estimado Máximo (U$) Memoria RAM Instalada Capacidad Procesador Velocidad de Expansión del Tipo de Método de Sistema Operativo Versión del Capacidad Tipo Sistema Operativo para actualizar el Sistema Operativo Blackberry H1100 $499 5M No Intel 386 N/D Serial, Infrarrojo Casio Cassiopeia E-105 Compaq iPaq H3850 Diamond Mako $149 16MB $604 64MB $479 32M Compact Flash Secure Digital No Intel StrongARM ARM 710 T RISC Handspring Treo 180 $499 16MB No Motorola Dragonball VZ Visor $92 2MB Springboar d Motorola Dragonball EZ Visor Deluxe $109 8MB Springboar d Motorola Dragonball EZ 16 MHz Infrarrojo, USB Palm OS 3.1 Si Monocrom o 160 x 160 3.1 N/D 16 MHz Infrarrojo, USB Palm OS 3.1 Si Monocrom o 160 x 160 3.1 N/D 33 MHz 36 MHz 206 MHz NEC 131 MHz Infrarrojo, Pocket PC Windows Serial CE 2.1 Si Color 240 x 320 3.77 16 bits N/D BlackBerry N/D N/D Monocrom o Color 240 x 320 3.9 16 bits 160 x 160 7 N/D Pantalla de Resolución Area útil de la Pantalla de pantalla la Profundida d de

Procesador sincronizaci ón

(pulgadas color cuadradas)

Infrarrojo, Pocket PC Pocket PC USB Infrarrojo, Serial USB Palm OS 3.5.2 o superior EPOC 2002 EPOC R5

Si

Monocrom o

240 x 320

7.4

N/D

Si

Monocrom o

160 x 160

3

N/D

Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
Fabricante Modelo Precio estimado Máximo (U$) Memoria RAM Instalada Capacidad Procesador Velocidad de Expansión del Tipo de Método de Sistema Operativo Versión del Capacidad Tipo Sistema Operativo para actualizar el Sistema Operativo HP Jornada 720 $833 32MB Tarjeta PC, StrongARM 206 MHz Compact Flash RISC Infrarrojo, Pocket PC Windows serial, USB para Handheld PC 2000 Palm Tungsten T $499 16MB MultiMedia Card, SmartMedi a m100 $93 2MB No Texas Instruments OMAP 1510 Motorola Dragonball EZ Palm IIIc $88 8MB No Motorola Dragonball EZ Sony CLIE PEGSL10 $150 8MB Memory Stick N/D N/D USB Palm OS 4.1 Si Monocrom o 160 x 160 4.1 N/D 20MHz Infrarrojo, serial Palm OS 3.5 Si Color 160 x 160 4.1 8 bits 16 MHz Infrarrojo, serial Palm OS 3.5 Si Monocrom o 160 x 160 3.3 N/D N/D Infrarrojo, USB Palm OS 5 Si Color 320 x 320 N/D 16 bits Si Color 640 x 240 6.5 16 bits Pantalla de Resolución Area útil de la Pantalla de pantalla la Profundida d De

Procesador sincronizaci ón

(pulgadas color cuadradas)

PC ACER Aspire G600 p A partir de hasta 3 GB $800 Si Intel 2.4 a 2.8 GHz N/A Opcional (Windows) Si Color 1600 x 1200 350 x 262 mm

Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
Fabricante Modelo Tipo de Baterías (1) Duración estimada (hrs) Blackberry Casio H1100 Cassiopeia 105 Compaq Diamond Handspring IPaq H3850 Mako Treo 180 Visor Visor Deluxe HP Palm Jornada 720 Tungsten T m100 IIIc Sony CLIE SL10 PEGRecargable Recargable (3) Recargable AAA (4) AAA (4) Recargable Recargable AAA (4) Recargable AAA 10 12 60 60 60 9 N/D 60 30 N/D No No No No No No Si No No No 5.1 x 3.3 x 0.6 3.1 x 6.2 x 0.7 2.7 x 4.3 x 0.7 4.8 x 3.0 x 0.7 4.8 x 3.0 x 0.7 7.4 x 3.7 x 1.3 4.0 x 3.0 x 0.6 4.7 x 3.1 x 0.7 5.1 x 3.2 x 0.7 4.6 x 2.8 x 0.6 6.3 7 5.2 5.4 5.4 17 5.6 4.4 6.8 3.6 Recargable E- Recargable (2) 7 6 Soporte a Tamaño tecnología (Alto, Largo, Ancho) Bluetooth en pulgadas No No 4.6 x 3.1 x 0.7 5 x 3.3 x 0.7 5.3 9 Bocina Entrada para audífonos, microfono, entrada para tarjeta Peso (onzas) Características Adicionales

multimedia, batería de respaldo Entrada para audífonos, mícrofono, software multimedia Bocina Microfono Bocina Bocina Entrada para audífonos, micrófono. Bocina estéreo Bocina Bocina Software multimedia

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) (2) (3) (4) N/D N/A

A menos que se indique otra cosa, todos los modelos vienen con batería de ion litio La batería recargable se puede remover y reemplazar. Niquel-metal hidruro. Requiere dos baterías AAA. Dato no disponible 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 Dolor de cabeza Calentura Dolor Muscular Tos Dolor de garganta

Síntoma Dolor de cabeza Calentura Dolor Muscular

Síntoma Dolor de cabeza Mareo

Padecimiento Catarro

probable:Padecimiento Dengue

probable:Padecimiento Presión Alta

probable:

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
Diarrea y deshidratación Amibiasis Diarrea infecciosa Parasitosis intestinal

Enfermedades mosco
Paludismo Dengue

por

picadura

de

Enfermedades crónicas
Diabetes mellitus Presión alta

Enfermedades respiratorias
Catarro o influenza Neumonía Bronquitis Tuberculosis Anginas Otitis

Problemas de la nutrición
Desnutrición

Intoxicación por ponzoña
Picadura de alacrán

Otras enfermedades Enfermedades del sistema nervioso
Parálisis Ataques Agresión por animal Enfermedades de la piel Infecciones vaginales

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 de y deshidratación, ataques

catarro/influenza, parálisis (parálisis flácida

miembros),

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

), en los que se muestra el texto asociado a la

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 detalles de alguna cita existente. Flechas de desplazamiento (

) o el que permite ver los

), 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 Barra de desplazamiento Botón Campo Flecha que indica mayúsculas Tabla Flecha de desplazamiento Menús Botón gráfico Campo texto como botón Etiqueta Combo Formas Adicionales Checkboxes Campo texto para desplegar datos Lista

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

De este modo, se conforma la lista completa de objetos:
Forma Barra de desplazamiento Botón Campo Flecha que indica mayúsculas Tabla Push Button Graphic Repeating Button Field List Slider Control Flecha de desplazamiento Menús Botón gráfico Campo texto como botón Etiqueta Button Repeating Button Checkboxes Graffiti Shift Indicator Popup Trigger Gadget Combo Formas Adicionales Checkboxes Campo texto para desplegar datos Lista Graphic Button Graphic Push Button Feedback Slider Control Label Selector Trigger 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 Forma

Definición 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 Graphic Button Push Button Sinónimo de Botón Sinónimo de Botón gráfico 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 Check box

los botones repeating y gráfico 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 Campo texto botón. 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 Label Lista Elemento de la interfaz gráfica que contiene texto estático. Sinónimo de etiqueta. 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 Tabla Sinónimo de Lista 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 desplazamiento deElemento de la interfaz gráfica que facilita el desplazamiento sobre campos de texto y tablas, informando la posición aproximada del cursor dentro de aquel objeto Scroll Bar Slider Control Sinónimo de barra de desplazamiento 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 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: son totalmente modificables por el

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 1 Identificador de la Forma Identificador de la Barra de Menú Identificador del Botón por defecto Titulo de la forma 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. Bandera que indica si todos los eventos afectan a la forma Bandera que indica si se debe almacenar temporalmente la información que quedará oculta por la forma Bandera que define la forma en que se debe desplegar el texto (Anchor Left) Bandera que indica si el objeto tiene borde Bandera que indica si el texto del objeto se desplegara en Negritas Bandera que indica si el objeto se dibuja seleccionado la primera vez Bandera que indica si el campo es editable Bandera que indica si el campo esta subrayado Bandera que indica si el campo se desplegará en un sola línea (independientemente de su tamaño) Bandera que indica si el tamaño del campo puede cambiar Bandera que indica si el texto del campo se desplegará justificado a la izquierda Bandera que indica si el primer carácter del campo se escribe en mayúscula Bandera que indica si el campo tiene Barra de desplazamiento Bandera que indica si el campo recibirá solo caracteres numéricos. Propiedades Objetos 1 Nombre de la Fuente que se usará para desplegar Texto Etiqueta que se dibujará en el objeto 2 x x 3 x x 4 5 6 x x 7 x 8 9 10 x x 11 x x 12 x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x x 2 3 4 5 6 Objetos 7 8 9 10 11 12

123

Identificador del grupo al que pertenece el objeto Número máximo de caracteres que se pueden escribir en el Campo Nombre de la Fuente que se usará para desplegar Texto Número de renglones que serán desplegados Lista de textos a desplegar Número de Filas Lista de anchos de columna Valor actual Valor mínimo Valor máximo Tamaño de página Bandera que indica si el tamaño del campo puede cambiar Identificador de la lista a la que esta asociado el objeto Etiqueta del Menú Lista de elementos del Menú

x x

x x x x x x x x x x x x x 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 Síntoma

Cualquier causa de enfermedad. 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 sinónimos. Molestia Plantilla

se

manejan

como

Sinónimo de Signo 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

2.

2.

3.

4.

inicial 1.1.2 Señalar en la caja correspondiente, la molestia referida 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 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” 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 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
138 638 441 2210 106 1130 40 355 246 585 14? 274? 158? 856? 35? 519? 29? 149? 44? 222? |Cabeceras.c |Canalizacion.c |Diagnostico.c |Formas.c |IdPalm.c |MenuSintomaInicial.c |Prototipos.h |Regreso.c |Seguimiento.c |Starter.c

SVES MVC
351 41 40 24 51 31 36 25 298 78 11 136? 24 12 10 13 15 9 11 65 48 0 19 14 5 39 26 20 14 28 18 30 19 16 15 103 46 4 |cDataBase.cpp |cDataBase.h |cetiqueta.cpp |cetiqueta.h |cigboton.cpp |cigboton.h |cigcheckbox.cpp |cigcheckbox.h |cigfield.cpp |cigfield.h |ciglabel.cpp |ciglabeledobject.cpp |ciglabeledobject.h |ciglabel.h |ciglist.cpp |ciglist.h |cigscrollbar.cpp |cigscrollbar.h |cobjetominimo.cpp |cobjetominimo.h |controlobject.cpp |controlobject.h |crectangletype.cpp |crectangletype.h |cstring.cpp |cstring.h |cusableobject.cpp

---------------5889 2300? total lines/statements

60 30

884 lines had comments 392 comments are inline 1020 lines were blank 21 lines for preprocessor 4356 lines containing code 5889 total lines

15.0 % -6.7 % 17.3 % 0.4 % 74.0 % 100.0 %

18 147 50 63 28 79 35

20479 comment-chars 16651 nontext-comment-chars 37461 whitespace-chars 495 preprocessor-chars 87298 statement-chars 162384 total characters

12.6 % 10.3 % 23.1 % 0.3 % 53.8 % 100.0 %

82 33 62 30 491 138 18

148

7952 tokens, average length 8.66

21 215

6 63 39 121?

|cusableobject.h |precord.cpp |precord.h |starter.cpp

0.23 ratio of comment:code 756 ?:illegal characters found

67 655

---------------3308 988? total lines/statements

743 lines had comments 241 comments are inline 671 lines were blank 129 lines for preprocessor 2006 lines containing code 3308 total lines

22.5 % -7.3 % 20.3 % 3.9 % 60.6 % 100.0 %

11138 comment-chars 8726 nontext-comment-chars 17599 whitespace-chars 2482 preprocessor-chars 37544 statement-chars 77489 total characters

14.4 % 11.3 % 22.7 % 3.2 % 48.5 % 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; y no sistemas de vigilancia aspectos epidemiológica, epidemiológicos.

información

convencional

convencional;

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

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.