ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL
NUMERO 00922681 DE FECHA 23 DE JUNIO DE 1992
SVES. DESARROLLO DE APLICACIONES PARA
DISPOSITIVOS MÓVILES
TESIS
QUE PARA OBTENER EL TÍTULO DE
INGENIERO EN COMPUTACIÓN
PRESENTA:
IVÁN CARLOS RIVERA GONZÁLEZ
ASESOR: EUGENIO JACOBO HERNÁNDEZ VALDELAMAR
MÉXICO, D.F. MARZO DE 2003
RESUMEN
El interés por crear aplicaciones para Dispositivos Móviles ha aumentado en la
misma medida que estos han demostrado su funcionalidad. Además, con el
aumento en las capacidades de procesamiento de estos dispositivos se ha abierto
todo un abanico de posibilidades de aplicación de los mismos.
Sin embargo, cuando se considera elaborar aplicaciones para dispositos móviles,
la principal dificultad que se debe enfrentar es la elección de una plataforma de
desarrollo, entendida ésta como una combinación de metodología de análisis y
diseño de sistemas, lenguaje de programación, sistema operativo sobre el que se
trabaja, etc.
Para enfrentar un problema como este, se debe plantear la elección de una
Metodología de Análisis y Diseño de Sistemas adecuada, muy probablemente
Orientada a Objetos. Se debe hacer un Análisis y Diseño adecuados,
considerando las limitaciones de la plataforma.
A partir de un Análisis cuidadoso y diseñando las aplicaciones considerando las
restricciones propias de un dispositivo móvil, la correcta aplicación de la
plataforma elegida redundará en un proceso de desarrollo más eficiente, rápido,
económico y con aplicaciones mas robustas.
Como un ejemplo de aplicación de este trabajo, se estudia el “Sistema de
Vigilancia Epidemiológica Simplificada” (SVES) de la Secretaría de Salubridad y
Asistencia.
Los asistentes personales digitalizados son dispositivos con una gran capacidad
de procesamiento a un costo relativamente bajo que ponen al alcance de las
masas la posibilidad de realizar actividades que antes solo se podían realizar con
una computadora personal.
Considerando esto, al desarrollar un sistema para PDAs que aplique la
metodología del SVES, una franja mas grande de la población tendrá acceso a
este mecanismo de atención.
El presente trabajo demostrará que es posible aplicar una metodología de Análisis
y Diseño de Sistemas que considere las limitaciones de una plataforma como las
PDAs para desarrollar aplicaciones de Cómputo Móvil.
II
INDICE
INTRODUCCIÓN.....................................................................................................1
CAPITULO I DESARROLLO DE SISTEMAS ..........................................................4
I.1 Conceptos del Software ..................................................................................5
I.2 Lenguajes de Programación ...........................................................................6
I.2.1 Qué es un lenguaje de programación ...................................................6
I.2.2 Evolución de los Lenguajes de Programación ......................................9
I.2.3 Clasificación de los Lenguajes de Programación................................12
I.2.4 El proceso de la programación............................................................14
I.3 Tipos de Sistemas de Cómputo ....................................................................15
I.3.1 Aplicaciones Monolíticas.....................................................................16
I.3.2 Modelo Cliente / Servidor ....................................................................16
I.3.3 Sistemas Distribuidos..........................................................................21
I.3.4 Cómputo Móvil ....................................................................................22
I.3.5 Comentarios Finales ...........................................................................25
CAPITULO II DESARROLLO DE APLICACIONES PARA ASISTENTES
PERSONALES DIGITALIZADOS ..........................................................................26
II.1 Introducción a las PDAs...............................................................................27
II.2 Arquitectura de Hardware de la plataforma Palm.........................................28
II.3 Arquitectura del Sistema Operativo Palm.....................................................32
II.4 Tipos de aplicaciones...................................................................................35
II.4.1 Aplicaciones Web reducidas ..............................................................35
II.4.2 Aplicaciones estándar de Palm..........................................................37
II.4.3 Conduits .............................................................................................38
II.5 Estructura de una aplicación Palm. ..............................................................39
II.5.1 Como se genera un ejecutable ..........................................................41
II.5.2 Common Object File Format ..............................................................43
II.5.2.1 Archivo Objeto ......................................................................43
II.5.2.2 COFF....................................................................................44
II.5.2.3 COFF y Palm........................................................................46
III
II.5.2.4 PRC-Tools ............................................................................46
II.5.2.5 CodeWarrior .........................................................................48
II.5.2.6 Otros.....................................................................................48
II.6 Integración de un ambiente de desarrollo Palm...........................................49
II.6.1 Herramientas de desarrollo disponibles.................................................49
II.6.1.1 Herramientas Orientadas a formularios ..........................................50
II.6.1.2 Herramientas Orientadas a la programación tradicional .................52
II.6.2 El PalmOs Emulator (POSE) .................................................................54
II.7 Características del API de Palm...................................................................56
II.7.1 APIs Definidas por el usuario .............................................................59
II.7.2 El ambiente de desarrollo para este trabajo.......................................60
II.7.3 CodeWarrior.......................................................................................60
II.7.4 Eligiendo entre C y C++ .....................................................................61
CAPITULO III OMT PARA EL ANÁLISIS Y DISEÑO DE APLICACIONES EN
ASISTENTES PERSONALES DIGITALIZADOS...................................................66
III.1 Elementos de OMT .....................................................................................67
III.1.1 Modelo de Objetos ............................................................................67
III.1.2 Modelo Dinámico ..............................................................................68
III.1.3 Modelo Funcional..............................................................................68
III.1.4 Relación entre los Modelos ...............................................................69
III.2 Proceso de Análisis y Diseño en OMT........................................................70
III.2.1 Análisis..............................................................................................71
III.2.1.1 Casos de Uso .............................................................................74
III.2.2 Diseño...............................................................................................75
III.2.2.1 Diseño de sistemas. ...................................................................75
III.2.2.2 Diseño de objetos. ......................................................................77
III.3 Patrones de Diseño.....................................................................................79
III.3.1 Qué son los patrones ........................................................................79
III.3.1.1 Ventajas de los patrones de diseño............................................81
III.3.2 Patrón Modelo Vista Controlador ......................................................82
III.3.2.1 Modelo Vista Controlador y desarrollo para Palm.......................87
IV
III.4 Restricciones dadas por la plataforma ........................................................87
III.4.1 Los distintos modelos de Palm..........................................................89
III.4.2 Características generales de las computadoras de mano,
independientemente de la marca. ...............................................................90
III.4.3 Comentarios Finales .........................................................................90
CAPITULO IV CASO DE ESTUDIO: SVES...........................................................95
IV.1 Sistemas de Apoyo en la toma de decisiones ...........................................96
IV.1.1 Proceso general de toma de decisiones...........................................97
IV.1.2 Sistemas de diagnóstico médico. .....................................................98
IV.1.2.1 Perspectiva Histórica..................................................................99
IV.1.2.2 Sistemas Expertos ...................................................................100
IV.1.2.3 Funcionamiento de los sistemas de diagnóstico medico..........101
IV.1.2.4 Ejemplo ....................................................................................101
IV.2 Antecedentes del Sistema de Vigilancia Epidemiológica..........................102
IV.3 Sistema de vigilancia epidemiológica .......................................................105
IV.3.1 Sistemas no convencionales de Información..................................106
IV.3.2 Aspectos epidemiológicos ..............................................................107
IV.4 Sistema de Vigilancia Epidemiológica Simplificada ..................................107
IV.4.1 Componentes del SVES .................................................................108
IV.4.2 Padecimientos Incluidos .................................................................109
IV.5 Formatos e instructivos de registro y notificación .....................................111
IV.5.1 Plantilla para el Diagnóstico Individual de Enfermedades ..............111
IV.6 Análisis y Diseño del Sistema...................................................................113
IV.6.1 Análisis de la Vista..........................................................................113
IV.6.1.1 Enunciado del problema...........................................................113
IV.6.1.2 Modelo de Objetos ...................................................................113
IV.6.1.3 Identificación de Objetos y Clases ...........................................113
IV.6.1.4 Diccionario de Datos ................................................................122
IV.6.1.5 Identificar Asociaciones entre clases .......................................122
IV.6.1.6 Identificar Atributos...................................................................122
IV.6.1.7 Refinamiento del modelo usando herencia ..............................125
V
IV.6.1.8 Modelo Dinámico......................................................................126
IV.6.1.9 Modelo Funcional .....................................................................128
IV.6.1.10 Iterar.......................................................................................130
IV.6.2 Análisis del Modelo.........................................................................130
IV.6.2.1 Enunciado del problema (EP)...................................................130
IV.6.2.2 Modelo de Objetos ...................................................................130
IV.6.2.2.1 Identificación de Objetos y Clases .................................130
IV.6.2.2.2 Buscar sujetos en el EP .................................................132
IV.6.2.3 Identificar Asociaciones entre clases .......................................134
IV.6.2.4 Identificar Atributos...................................................................134
IV.6.2.5 Modelo Dinámico......................................................................135
IV.6.2.6 Modelo Funcional .....................................................................136
IV.6.2.7 Iterar el proceso .......................................................................137
IV.7 Análisis del Controlador ............................................................................138
IV.7.1 Enunciado del problema (EP) .........................................................140
IV.7.1.1Modelo de Objetos ....................................................................140
IV.7.1.2Modelo Dinámico.......................................................................141
IV.7.1.3Modelo Funcional ......................................................................142
CONCLUSIONES ................................................................................................144
BIBLIOGRAFÍA....................................................................................................152
ANEXOS..............................................................................................................159
VI
LISTA DE FIGURAS
Figura 1.1 Tipos de software ...................................................................................5
Figura 1.2 Construcción de un ejecutable ...............................................................8
Figura 1.3 Ensamblador, Compilador e Interprete.................................................10
Figura 1.4 Niveles de los lenguajes de programación ...........................................13
Figura 1.5 Proceso de programación.....................................................................15
Figura 1.6 Comunicación Cliente / Servidor ..........................................................17
Figura 1.7 Clientes y servidores en Internet ..........................................................19
Figura 1.8 Sistemas Distribuidos ...........................................................................21
Figura 1.9 Cómputo Móvil......................................................................................23
Figura 1.10 Flujos de Información en cómputo móvil. ...........................................24
Figura 2.1 Palm m505............................................................................................27
Figura 2.2 Palm IIIe ...............................................................................................28
Figura 2.3 El procesador Dragonball .....................................................................29
Figura 2.4 Arquitectura del PalmOS ......................................................................33
Figura 2.5 Ejecución de una aplicación web reducida. ..........................................36
Figura 2.6 Otra vista de una aplicación web reducida ...........................................37
Figura 2.7 Calculadora ..........................................................................................37
Figura 2.8 Juego pBill para Palm...........................................................................38
Figura 2.9 Reloj .....................................................................................................38
Figura 2.10 Conduit de sincronización diaria de Palm...........................................39
Figura 2.11 Secuencia de llamadas de Funciones ................................................41
Figura 2.12 Niveles de programación ....................................................................43
Figura 2.14 Generación de un ejecutable..............................................................44
Figura 2.15 Generación de un ejecutable con PRC-Tools.....................................48
Figura 2.16 PE-Coff de Microsoft...........................................................................49
Figura 2.17 Satellite Forms....................................................................................51
Figura 2.18 Pendragon Forms ...............................................................................52
Figura 2.19 Organización de la API de Palm. ........................................................57
Figura 3.1 Relación entre los modelos de OMT.....................................................69
VII
Figura 3.2 El Proceso de desarrollo de OMT.........................................................70
Figura 3.3 Casos de Uso .......................................................................................75
Figura 3.4 Modelo Vista Controlador .....................................................................83
Figura 3.5 Un solo Modelo puede tener varias vistas y controladores...................83
Figura 3.6 Arquitectura de Modelo Vista Controlador ............................................86
Figura 4.1 Proceso de toma de decisiones............................................................97
Figura 4.3 Agenda ...............................................................................................114
Figura 4.4 Agregar una cita .................................................................................115
Figura 4.5 Detalles de la cita ...............................................................................115
Figura 4.6 Nota ligada a una cita.........................................................................116
Figura 4.7 Agregar una Dirección ........................................................................116
Figura 4.8 Forma Acerca de ................................................................................117
Figura 4.9 Catalogo del Constructor ....................................................................118
Figura 4.11 Diagrama de clases de la Vista ........................................................125
Figura 4.12. Caso de Uso MV1A. El PalmOS inicia una aplicación:....................126
Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicación:
.............................................................................................................................127
Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalización
de una aplicación.................................................................................................128
Figura 4.15 Primera versión del diagrama de clases del Modelo ........................135
Figura 4.16. Caso de Uso MD01. Usuario diagnóstica un padecimiento.............135
Figura 4.17 Diagrama de Flujo de Eventos de Elaboración de un diagnóstico....136
Figura 4.18 Algoritmo para obtener un diagnóstico .............................................137
Figura 4.19 Diagrama de Clases del Modelo.......................................................138
Figura 4.20 Funciones creadas por Codewarrior.................................................140
Figura 4.21 Modelo de objetos del Controlador ...................................................141
Figura 4.22. El Usuario diagnostica padecimiento...............................................141
Figura 4.23 Diagrama de clases de la Vista. .......................................................143
Figura C2. Patrón Modelo Vista Controlador Adaptador......................................151
VIII
LISTA DE TABLAS
Tabla 2.1. Archivos importantes de la Interfaz de Programación de Aplicaciones de
Palm.......................................................................................................................59
Tabla 3.1 Lista de Modelos de PDAs por Fabricante.............................................87
Tabla 3.1 (cont.) Lista de Modelos de PDAs por Fabricante .................................88
Tabla 3.2. Comparación entre los modelos de Palm Inc. ......................................89
Tabla 3.3 Comparación de modelos de Handhelds contra una PC .......................91
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) .............92
Tabla 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
INTRODUCCIÓN
2
Hasta hace relativamente poco tiempo, en los países en vías de desarrollo como
México, los avances tecnológicos llegaban con un importante retraso respecto a
su aparición en los países desarrollados.
Sin embargo, hoy en día, Internet, la televisión, las telecomunicaciones, etc.
permiten que se tenga acceso a la tecnología de forma mas o menos simultanea
en todo el mundo.
Un ejemplo de esta afirmación es la plataforma de asistentes personales
digitalizados desarrollados por la Firma Palm Inc. cuyo último dispositivo: el Palm
Tungnsten T, se presentó en México antes que en el resto del mundo.
Los asistentes personales digitalizados son una plataforma de un gran potencial,
ya que poseen una capacidad de procesamiento poderosa a un precio
relativamente bajo.
Pero además, en el área de desarrollo de aplicaciones para estos dispositivos se
ha presentado un fenómeno particular: los desarrolladores de programas para
Palm están dispersos por el mundo, y no solo en los países más industrializados o
económicamente más poderosos. Este fenómeno esta ligado al hecho de que los
detalles de la plataforma, la documentación y las herramientas de desarrollo están
disponibles para todo el público, en forma totalmente gratuita.
Con todo, la programación de aplicaciones para dispositivos móviles es un área de
incipiente crecimiento en México. Incluso en el mundo (según cifras de Palm Inc.)
el número de desarrolladores registrados es de apenas varios cientos.
3
Esto ofrece a los programadores de los países en vías de desarrollo la
oportunidad de experimentar, de ser propositivos y no solo simples usuarios de la
tecnología importada.
Sin pretender convertirse en la piedra angular de la programación para
dispositivos móviles en México este trabajo busca, precisamente: proponer, dar
ideas, pasar de ser usuarios a ser desarrolladores de nueva tecnología.
CAPITULO I
DESARROLLO DE SISTEMAS
5
I.1 Conceptos del Software
A principios de los 80 no estaba claro cuán importante sería el desarrollo de
software. Hoy en día, se ha convertido en el eje de evolución de la industria de la
computación, y es el motor que conduce la toma de decisiones comerciales. Esto
ha provocado que cambie la percepción que el público tenia del software: de ser
un aditamento adicional a la computadora, a ser una plataforma de trabajo que
corre sobre un hardware no específico.
En nuestros días el software tiene un doble papel: es un producto que permite
explotar toda la potencia del hardware informático; ya sea almacenado dentro de
un teléfono celular o dentro de una computadora bancaria, el software transforma
información, produciendo, gestionando, modificando, mostrando o transmitiendo
información, pero el software también sirve como vehículo para hacer entrega de
un producto, ya que actúa como la base de control de la computadora, la
comunicación de información, y la creación y control de otros programas.
Figura 1.1 Tipos de software
6
Dentro del gran conjunto de programas representados por el termino "software",
se pueden hacer dos grandes divisiones, de acuerdo a la función que
desempeñan. Una formada por el llamado Software de Sistema, encargado de
apoyar al usuario en la administración de su hardware, y la otra conformada por el
Software de Aplicación, subconjunto que agrupa a todos los programas que
resuelven necesidades y problemas específicos de los usuarios. Así, cuando un
usuario desea capturar un texto y darle formato, utilizar distintos tipos y tamaños
de letra y revisarlo ortográficamente, tiene que recurrir a un software de aplicación.
Igual debe hacerlo si desea capturar y manipular grandes volúmenes de datos, o
hacer muchos cálculos o si lo que quiere es construir imágenes y darles
animación. Mientras que si respalda archivos o administra impresoras, estará
usando software de sistema. Aunque el término "Sistema" se usa también como
sinónimo de software, y en especial en el presente documento, específicamente
del software de aplicación.
Pero, para que la computadora pueda ejecutar cualquier tarea, se le debe
programar para que la haga, colocando en su memoria principal un algoritmo
apropiado, expresado en algún lenguaje de programación.
I.2 Lenguajes de Programación
I.2.1 Qué es un lenguaje de programación
Como se menciona en el capítulo anterior, se presenta la necesidad de expresar
los algoritmos en una sintaxis no ambigua y a un nivel de detalle bien establecido.
Estos dos requisitos se resuelven mediante el uso de primitivas. [Brookshear,
1995] explica que una primitiva consiste en una estructura semántica bien definida
junto con una sintaxis no ambigua para representarla.
Tenemos entonces, que para representar algoritmos se debe contar con una
colección suficientemente rica de primitivas que, junto con las reglas de
7
combinación para representar estructuras más complejas, constituyen un lenguaje
de programación.
La Enciclopedia de Términos de Microcomputación define Lenguaje de
programación como los conjuntos de símbolos y de reglas que se pueden
combinar en forma sistemática para comunicar pensamientos e ideas, y
específicamente aquellos que sirven para escribir instrucciones de computadora.
El lenguaje Incluye vocabulario, y reglas o convenciones que rigen la forma y
secuencia en que se escriben las instrucciones para su ejecución en la
computadora.
También para [Joyanes, 1988] un lenguaje de programación es un conjunto de
reglas, símbolos y palabras que permiten construir un programa. Al igual que los
lenguajes humanos tales como el inglés o el español, los lenguajes de
programación poseen una estructura (gramática o sintaxis) y un significado
(semántica).
La sintaxis es el conjunto de reglas que gobiernan la construcción o formación de
sentencias (instrucciones) válidas en el lenguaje. La semántica es el conjunto de
reglas que proporcionan el significado de una sentencia o instrucción del lenguaje.
El vocabulario de un lenguaje es un conjunto de símbolos. Los símbolos usuales
son: letras, dígitos, símbolos especiales (,;:/&+-*, etc.) y palabras reservadas o
claves, y las reglas sintácticas son los métodos de producción de sentencias o
instrucciones válidas que permitirán formar un programa.
Según menciona [Brookshear, op. cit.], la implantación de los lenguajes de
programación de alto nivel se basa en el proceso de convertir programas escritos
en esos lenguajes en programas escritos en lenguaje de máquina.
8
La traducción de un programa consiste en tres actividades: análisis léxico, análisis
sintáctico y generación de código
Figura 1.2 Construcción de un ejecutable
El análisis léxico es el proceso de reconocer qué cadenas de símbolos del
programa que se ha de traducir (llamado programa fuente) representan en
realidad un solo objeto elemental. Por ejemplo, la cadena de símbolos 153 no
debe representarse como un 1 seguido de un 5 seguido de un 3, sino que debe
reconocerse como la representación de un solo valor numérico. De manera
similar, aunque los identificadores que aparecen en un programa están formados
por varios caracteres, se deben interpretar colectivamente como un nombre, no
como caracteres individuales.
La segunda actividad del proceso de traducción, el análisis sintáctico, es el
proceso de analizar la estructura gramatical de un enunciado y reconocer el papel
de sus componentes.
A fin de simplificar la tarea del análisis sintáctico, la colección de estructuras de
enunciados que tiene un lenguaje de programación es menos variada que la de un
A n á l i s i s
l é x i c o
A n á l i s i s
s i n t á c t i c o
G e n e r a c i ó n
d e c ó d i g o
P r o g r a m aF u e n t e
P r o g r a m ao b j e t o
9
lenguaje natural, y está limitada a unas cuantas formas cuidadosamente
escogidas.
La actividad final en la traducción de un programa es la generación de código, es
el proceso de construir secuencias de instrucciones en lenguaje de máquina que
simulen a los enunciados reconocidos por el analizador sintáctico, y es el que
genera el producto final del proceso de traducción: el programa objeto.
I.2.2 Evolución de los Lenguajes de Programación
Al igual que el software, hay varias formas desde las que pueden verse o
clasificarse los lenguajes de programación: por su nivel, por sus principales
aplicaciones, etc. Además, estas visiones están condicionadas por la evolución
histórica por la que ha transcurrido el lenguaje.
Los primeros lenguajes de programación -lenguajes de maquina y ensamblador-
reciben el nombre de lenguajes de bajo nivel, debido a que los programadores que
codifican en estos lenguajes deben escribir instrucciones con el nivel más fino de
detalle. Cada línea de código corresponde a una sola acción del sistema
computacional. El lenguaje de maquina, el cual consta de cadenas de bits 0 y 1 es
la "lengua parlante" de la computadora.
El mecanismo de escoger nombres descriptivos para las celdas de memoria y usar
nombres mnemónicos para representar códigos de operación, aumentó
considerablemente la comprensibilidad de las secuencias de instrucciones de
máquina.
Cuando se introdujeron estas técnicas, los programadores usaban esta notación al
diseñar los programas en papel, y luego la traducían a una forma que pudiera
entender la máquina. Este proceso de traducción es suficientemente sencillo como
10
para que la propia computadora lo pueda llevar a cabo, lo que dio lugar a que el
uso de nombres mnemónicos se formalizara para dar origen a un lenguaje de
programación denominado "lenguaje ensamblador", y a un programa, también
llamado "ensamblador" que traducía otros programas escritos en lenguaje
ensamblador a lenguaje de máquina.
Figura 1.3 Ensamblador, Compilador e Interprete
Los lenguajes ensambladores representaron un gran avance en la búsqueda de
mejores ambientes de programación. Por ello, se les denominó lenguajes de
segunda generación, siendo la primera generación la de los propios lenguajes de
máquina.
Aunque los lenguajes de segunda generación tenían muchas ventajas respecto a
su contrapartida de lenguajes de máquina, todavía dejaban mucho que desear en
cuanto a ofrecer el entorno de programación definitivo. Después de todo, las
primitivas empleadas en los lenguajes ensambladores eran esencialmente las
mismas que las del lenguaje de máquina correspondiente; la única diferencia era
la sintaxis de su representación.
11
Una consecuencia importante de esta íntima asociación entre los lenguajes
ensamblador y de máquina es que cualquier programa escrito en lenguaje
ensamblador depende inherentemente de la máquina; esto es, las instrucciones
del programa se expresan en términos de los atributos de una máquina específica.
Por tanto, un programa escrito en lenguaje ensamblador no se puede transportar
fácilmente a otra máquina porque se tiene que reescribir de modo que se ajuste a
la configuración de registros y al conjunto de instrucciones de la nueva máquina,
ya que cada tipo de microprocesador tiene su propio lenguaje ensamblador
asociado (entendiendo que el lenguaje Ensamblador es simplemente una
representación simbólica del lenguaje máquina). Por tanto, es necesario un
profundo conocimiento de la arquitectura de la computadora para poder realizar
una programación efectiva.
Otra desventaja de los lenguajes ensambladores es que el programador, aunque
no tiene que codificar las instrucciones en forma de patrones de bits, sí está
obligado a pensar en términos de los pequeños pasos incrementales del lenguaje
de la máquina, y no puede concentrarse en la solución global de la tarea por
realizar.
Las primitivas elementales en que se debe expresar finalmente un producto no
son necesariamente las primitivas que deben usarse al diseñarlo. El proceso de
diseño se presta mejor al empleo de primitivas de alto nivel, cada una de las
cuales representa un concepto asociado a una característica importante del
producto. Una vez terminado el diseño, se podrán traducir esas primitivas a
conceptos de más bajo nivel relacionados con los detalles de la implantación.
De acuerdo con esta filosofía se empezaron a crear lenguajes de programación
que fueran más propicios para la elaboración de software que los lenguajes
ensambladores de bajo nivel. El resultado fue la aparición de una tercera
generación de lenguajes de programación que difería de las anteriores en que sus
12
primitivas eran de alto nivel y además independientes de las máquinas.
En general, la estrategia para crear lenguajes de programación de tercera
generación fue identificar una colección de primitivas de alto nivel con las que se
podía crear software. Todas estas primitivas se diseñaron de modo que se
pudieran implantar como una secuencia de las primitivas de bajo nivel disponibles
en los lenguajes de máquina.
Una vez identificado este conjunto de primitivas de alto nivel, se escribió un
programa llamado traductor, que traducía a lenguaje de máquina los programas
expresados en dichas primitivas de alto nivel. Todo lo que tenía que hacer el
traductor era reconocer las primitivas y convertirlas en sus equivalentes en
lenguaje de máquina.
I.2.3 Clasificación de los Lenguajes de Programación
Surgen así, los "lenguajes declarativos" que son más parecidos al inglés en la
forma en que se expresan y en su funcionalidad, y están al nivel más alto respecto
a los otros. Son fundamentalmente lenguajes de órdenes, dominados por
sentencias que expresan "lo que hay que hacer" en vez de "como hacerlo". Un
ejemplo de estos lenguajes es el lenguaje estadístico SPSS, y el lenguaje de
consulta estructurada en bases de datos (SQL). Estos lenguajes se desarrollaron
con la idea de que los profesionistas pudieran asimilar más rápidamente el
lenguaje y usarlo en su trabajo, sin necesidad de conocimientos prácticos de
programación.
Los lenguajes de "alto nivel" son los más utilizados como lenguajes de
programación. Aunque no son fundamentalmente declarativos, estos lenguajes
permiten que los algoritmos se expresen en un nivel y estilo de escritura
fácilmente legible y comprensible por otros programadores. Además, los lenguajes
de alto nivel tienen normalmente la característica de "transportabilidad". Es decir,
13
están implementados sobre varias máquinas, de forma que un programa puede
ser fácilmente "transportado" o transferido de una maquina a otra sin ninguna
revisión sustancial. Es este sentido, se les denomina "independientes de la
máquina".
Ejemplos de estos lenguajes de alto nivel son Pascal, APL, FORTRAN, (para
aplicaciones científicas), COBOL (usado en aplicaciones de procesamiento de
datos), LISP y PROLOG (para aplicaciones de inteligencia artificial) C y Ada (para
aplicaciones de programación de sistemas). Aunque existen actualmente en uso
mas de 100 lenguajes de este tipo y muchos de ellos se encuentran en varias
versiones.
Figura 1.4 Niveles de los lenguajes de programación
Los lenguajes de muy alto nivel, que aparecieron por primera vez en la década de
1960, se crearon para cubrir necesidades especializadas del usuario. Con ellos,
solo se necesita prescribir lo que la computadora hará en vez de como hacerlo.
Este tipo de recurso facilita mucho la programación. De este modo, los lenguajes
14
de alto y bajo nivel a veces se conocen como lenguajes procedurales, debido a
que requieren que las personas escriban procedimientos detallados que indiquen
a la computadora como realizar tareas individuales. Los lenguajes de muy alto
nivel, en contraste reciben el nombre de lenguajes no procedurales.
Los lenguajes de muy alto nivel presentan algunas desventajas graves: carecen
de flexibilidad; generalmente, cada uno está diseñado para un tipo específico de
tarea. No se puede, por ejemplo, procesar una nómina con un lenguaje de
procesamiento de palabras. Debido a que se enfocan a aplicaciones específicas,
los lenguajes de muy alto nivel a veces se conocen como lenguajes dependientes
del problema. Una segunda desventaja principal es que hay muchas aplicaciones
importantes que no son cubiertas por estos lenguajes. No obstante, en las áreas
para las cuales se encuentran disponibles, ofrecen obvias ventajas, tanto a los
programadores como a los usuarios.
I.2.4 El proceso de la programación
Originalmente, el proceso de programación se realizaba por el laborioso método
de expresar todos los algoritmos en el lenguaje de máquina. El primer paso dado
para eliminar estas complejidades fue acabar con el empleo de dígitos numéricos
para representar códigos de operación y operandos del lenguaje de máquina. Así
se extendió la costumbre de asignar nombres mnemónicos a los diversos códigos
de operación y usarlos en vez de la representación hexadecimal durante el
proceso de diseño. Por ejemplo, en vez del código de operación para cargar un
registro, el programador usaría el nombre LDA (Cargar valor en el registro
acumulador). En el caso de los operandos, se diseñaron reglas para que el
programador pudiera asignar nombres (llamados identificadores) a posiciones de
memoria y usar tales nombres en una instrucción en vez de las direcciones de
memoria.
15
Se podría considerar la programación como el conjunto de actividades y
operaciones tendientes a indicar a la computadora como debe realizar las
funciones previstas en el algoritmo.
El proceso completo se enlista a continuación.
1. Detectar o definir un problema
2. Diseñar un Algoritmo de Solución
3. Escribir un programa
4. Ejecutar el programa
5. Validar resultados
6. Depurar el programa
Volver a (4)
Figura 1.5 Proceso de programación
Este proceso no ha cambiado a lo largo del tiempo ni con la evolución de los
lenguajes de programación. En todo caso, cada nueva generación (lenguaje) ha
ido haciendo más fácil y / o eficiente, una o mas etapas de este proceso.
I.3 Tipos de Sistemas de Cómputo
Un sistema es una colección de elementos y procedimientos que interactúan para
cumplir una meta. Un partido de fútbol, por ejemplo, se juega conforme a un
sistema. Consta de una colección de elementos -dos equipos, un campo de
juego, árbitros- y procedimientos -las reglas del juego- que interactúan para
determinar qué equipo es el ganador. Un sistema de tránsito es una colección de
personas, máquinas, reglas de trabajo, tarifas y programas que llevan a las
personas de un lugar a otro. Y un sistema computacional es una colección de
personas, hardware, software, datos y procedimientos que interactúan con el
objeto de realizar tareas de procesamiento de datos.
La función de un sistema, ya sea manual o computarizado, es mantener a la
organización bien administrada y funcionando sin altibajos. Los sistemas se crean
16
y modifican en respuesta a las necesidades cambiantes de una organización y a
las condiciones en transformación del medio que la rodea. Cuando surgen
conflictos en un sistema existente o se necesita un nuevo sistema, el desarrollo de
sistemas entra en acción. El desarrollo de sistemas es un proceso que en forma
muy general consta del análisis de un sistema, el diseño de uno nuevo o las
modificaciones a uno ya existente, la adquisición del hardware y software
necesarios y hacer que un sistema nuevo o modificado trabaje.
I.3.1 Aplicaciones Monolíticas
Los procesos contables sirvieron de punto de entrada a los primeros proyectos
informáticos. Paulatinamente los sistemas asimilaron una mayor cantidad de
responsabilidades convirtiéndose así en grandes aplicaciones monolíticas,
bloques de software cimentados sobre otros bloques. En esta arquitectura, toda la
"inteligencia" del sistema esta concentrada en una computadora central (host) y
los usuarios interactúan con ella a través de terminales que reciben las
instrucciones por medio de un teclado y las envían al host. Esta interacción no
esta limitada a cierto hardware, ya que los usuarios pueden conectarse usando
PCs o terminales de trabajo de Unix, etc.
Una limitación de esta arquitectura es que rara vez soporta interfaces gráficas, o
puede acceder a múltiples bases de datos.
I.3.2 Modelo Cliente / Servidor
Debido a la complejidad que pueden alcanzar las redes de computadoras, estas
se organizan en una serie de capas o niveles, cada una construida sobre la inferior
[Tanembaum, 1997]. La Arquitectura de la red indica el número de capas, su
nombre, contenido y función, sin embargo, en todas las arquitecturas el propósito
de cada capa es ofrecer servicios a las capas superiores, estableciendo una
conversación con las capas similares de otros equipos.
17
Las reglas y convenciones que se siguen en estas conversaciones se conocen
como protocolos de comunicación entre capas. Y el conjunto de capas y
protocolos se conoce como arquitectura de red.
La arquitectura "peer to peer" se refiere a un tipo de red en la que cada estación
de trabajo tiene capacidades y responsabilidades equivalentes, por lo que es
económica y fácil de implementar, aunque cuando esta sometida a grandes cargas
de trabajo no ofrece el desempeño de otras arquitecturas.
El termino cliente / servidor fue usado por vez primera en la década de los 80
para referirse a las computadoras personales (PC) conectadas a una red. El
modelo Cliente / Servidor como se concibe actualmente empezó a ganar
aceptación a finales de esa misma década.
En este modelo, un cliente es un ente que solicita servicios o recursos, mientras
que el servidor es el ente que los ofrece. Estos entes pueden ser computadoras o
procesos en una red. Los servicios ofrecidos pueden ser archivos, dispositivos e
incluso procesamiento de instrucciones.
Figura 1.6 Comunicación Cliente / Servidor
18
El rol del proceso servidor puede ser asumido por el mismo sistema operativo, por
un equipo despachando archivos en una red e incluso por otra computadora de las
mismas características físicas que el cliente pero con la habilidad de ofrecer un
servicio del que aquel carece. [Sadoski, 1997]
Desde el punto de vista de la programación, se considera a la arquitectura cliente /
servidor como la extensión lógica de la programación modular.
La programación modular se basa en el hecho de que al separar una pieza de
software grande en partes más simples, crea la posibilidad de que se faciliten el
desarrollo y mantenimiento del todo. La arquitectura cliente / servidor va mas
adelante reconociendo que estos módulos no requieren ejecutarse dentro del
mismo espacio de memoria. La continuación de este concepto es que los clientes
y servidores se ejecuten en las plataformas de hardware y software que resulten
más apropiadas para el desempeño de sus funciones. Los programas servidores
normalmente reciben las solicitudes de los programas clientes, ejecutan algún tipo
de manipulación con los datos (recuperar datos de una Base de Datos, efectuar
algún cálculo, implementar alguna regla de negocio, etc.), y envían la respuesta
apropiada al cliente.
19
Figura 1.7 Clientes y servidores en Internet
En el modelo cliente / servidor, el procesamiento de la computadora se divide
entre los "clientes" de una red y los "servidores", con cada función asignada a la
máquina con más capacidad para llevarla a cabo (la parte del cliente en una
aplicación corre en el sistema de los clientes, y la parte de la aplicación
correspondiente al servidor, en la o las computadoras servidores). El usuario
generalmente interactúa solo con la porción del cliente de la aplicación, que en
general consiste en la interfaz de usuario, el proceso de captura de datos, la
consulta a la base de datos y la obtención de informes. El servidor realiza las
funciones de fondo, no visibles por los usuarios, como la administración de los
dispositivos periféricos o el control del acceso a las bases de datos compartidas.
La división exacta de las tareas depende de los requerimientos de las
aplicaciones, requerimientos de procesamiento, número de usuarios y recursos
disponibles. Entre las tareas del cliente pueden incluirse la obtención de las
entradas del usuario, hacer solicitudes de datos a los servidores, realizar cálculos
en datos locales y desplegar resultados. La parte del servidor capturará o
procesará los datos.
20
En resumen, las características básicas de la arquitectura son:
• La combinación de un cliente o front-end que interactúa con el usuario, y un
servidor o back-end que interactúa con un recurso compartido. El proceso
cliente contiene la lógica específica de la solución y ofrece una interfaz
entre el usuario y el resto del sistema, mientras que el proceso servidor
actúa como el motor de software que administra los recursos compartidos
(bases da datos, impresoras, módems, etc.).
• Los procesos front-end y back-end ocupan recursos fundamentalmente
diferentes (espacio en disco, velocidad del procesador, dispositivos de
entrada / salida, etc.). El sistema operativo también puede ser diferente.
• Típicamente se trata de ambientes heterogéneos, conformados por
computadoras de diferentes marcas. El cliente y el servidor se comunican a
través de una conjunto bien definido de interfaces de programas -
aplicación (APIs, por sus siglas en ingles) o de llamadas a Procedimientos
Remotos (RPCs).
• Una característica muy importante de estos sistemas es su escalabilidad.
Ya que pueden ser escalados tanto horizontalmente (añadiendo o quitando
clientes), como verticalmente (migrando los servicios a equipos más
potentes) con un impacto mínimo en su desempeño general.
El modelo cliente / servidor requiere que los programas de aplicaciones sean
escritos como dos componentes separados de software que corren en distintas
máquinas pero que operan como una sola aplicación.
21
I.3.3 Sistemas Distribuidos
Los sistemas distribuidos surgen en 1993, y se basan en el uso de modelos de
negocio compartidos y reusables. El negocio se define entonces como un sistema
compuesto a su vez de otros subsistemas de negocio. Una vez más, se trata de
una extensión del modelo cliente / servidor en donde los equipos que ofrecen
servicios se pueden encontrar separados unos de otros.
Figura 1.8 Sistemas Distribuidos
El funcionamiento de Internet esta basado en este concepto, ya que básicamente,
se puede considerar al Web como un sistema distribuido de hipermedia [Wilde,
1999] en el que la información se encuentra almacenada en forma de páginas
Web, que se encuentran entrelazadas unas con otras mediante ligas URL.
Existen programas cliente, llamados navegadores, y programas servidores
localizados en diferentes lugares geográficos. El programa servidor se ejecuta en
un host de Internet, y responde a las solicitudes de información que le hacen los
clientes. Cuando recibe una solicitud, el servidor debe responderla en forma
simple, dejando al cliente o navegador, la responsabilidad de determinar la forma
apropiada en que esta información debe ser mostrada al usuario. Este mecanismo
de trabajo facilita que en los servidores se pueda mantener almacenada
información en formatos muy diferentes.
22
El navegador es entonces un programa que se usa para tener acceso a los
servidores de Web y que despliega los documentos recuperados de esos
servidores. Desde el punto de vista de la tecnología cliente-servidor, un navegador
es el cliente del servidor de Web.
I.3.4 Cómputo Móvil
Actualmente, la comunicación de datos, esto es, el intercambio de información
(archivos, faxes, correo electrónico, acceso a Internet) se realiza usando redes de
telecomunicación ya existentes. Los sistemas de comunicación móvil con voz
(teléfonos celulares, radios de onda corta, etc.) están ampliamente establecidos en
todo el mundo y en los últimos años ha habido un rápido crecimiento en el número
de suscriptores de las diferentes redes de telefonía celular. Una extensión de esta
tecnología es la habilidad de enviar y recibir datos a través de estas redes
celulares, siendo este el principio básico del Cómputo Móvil.
La tecnología de intercambio de datos a través de comunicación móvil se a
convertido en una rama importante de la industria, evolucionando rápidamente y
permitiendo hoy en día que sus usuarios puedan transmitir y recibir datos desde
lugares remotos, a través de dispositivos como teléfonos celulares y módems
conectados a laptops y agendas electrónicas.
23
Figura 1.9 Cómputo Móvil
El cómputo móvil permite sincronizar y controlar procesos y eventos donde el
acceso a datos e información es prácticamente imposible por otros medios.
Algunos ejemplos de aplicación del cómputo móvil son:
• Acceso a expedientes clínicos en línea en casos de emergencia.
• Envío de fotografías de siniestros desde el lugar del accidente para su
análisis, interpretación y devolución (ajustadores de seguros).
• Monitoreo y diagnóstico especializado de máquinas para su mantenimiento
y reparación en el campo (por ejemplo bombas de agua, de gas, de aceite).
• Acceso a planos y datos para la administración de servicios públicos
(drenajes, energía eléctrica).
• Monitoreo de descargas de aguas residuales.
El cómputo móvil facilita los servicios de venta, facturación, cobranza y calidad en
el servicio obteniendo y proporcionando datos e información en el lugar y en el
momento donde se realiza la operación. Por ejemplo, proporcionando información
24
sobre productos almacenados o en producción, informando sobre el status o
localización de un pedido ya realizado o informando sobre el estado crediticio de
un cliente, confirmando cantidades y materiales recibidos por el cliente y
optimizando transacciones de venta y producción, capturando los datos del cliente
y llevándolos directamente a los almacenes de envío o áreas de producción.
Figura 1.10 Flujos de Información en cómputo móvil.
En otros países, el cómputo móvil ha resultado de mucha utilidad en eventos
especiales de conteo o levantamiento de encuestas: Aplicando encuestas sobre
preferencias o evaluando algún producto o servicio, contando periódicamente
artículos de venta en estantes especializados y enviando esta información a
centros de logística (periódicos, revistas).
A través del uso de circuitos integrados (microlocalizadores) y ayuda satelital es
posible rastrear productos, unidades móviles o bien personas, permitiendo
replantear rutas de servicio o transporte en casos de emergencia (accidentes,
robos), proponer mejores rutas de acceso, localizar unidades para el control de
paradas y consumo de combustible, dar seguimiento a unidades de transporte
bancario.
25
I.3.5 Comentarios Finales
Como se mencionó al principio del capítulo, una aplicación puede constituir en si
misma un sistema, pero también puede ser que la aplicación móvil sea parte de un
sistema de información más grande. Esto se aplica también para las aplicaciones
en cómputo móvil: los datos almacenados en el dispositivo móvil pueden ser
procesados por este mismo, o ser enviados a otro (normalmente un equipo fijo,
mas grande) para su procesamiento.
Este trabajo pretende explorar las capacidades que tienen los dispositivos PDA
para recopilar y procesar información, además de delinear una metodología que
facilite el desarrollo de aplicaciones para estos.
CAPITULO II
DESARROLLO DE APLICACIONES PARA
ASISTENTES PERSONALES DIGITALIZADOS
27
II.1 Introducción a las PDAs
Antes de hablar sobre el desarrollo de aplicaciones para Asistentes PersonalesDigitalizados (PDAs) por sus siglas en ingles, se mencionarán algunascaracterísticas de estos.
Se hará una mención especial de las características de las aplicaciones de lamarca Palm, que actualmente, según su fabricante, son las más ampliamentedifundidas.
Figura 2.1 Palm m505
El término PDA define a "cualquier dispositivo móvil, que pueda ser operado con
una mano, y que tenga la capacidad de almacenar y procesar información para
uso personal o de negocio, así como administrar la agenda y el directorio
telefónico”. El término handheld se usa como sinónimo de PDA.
Algunas PDAs tienen un pequeño teclado, otras más tienen una área de la
pantalla capaz de detectar trazos y reconocer escritura; algunas incluso poseen la
capacidad de reconocer voz.
28
Figura 2.2 Palm IIIe
Además de los usos descritos, se han desarrollado muchas aplicaciones para
PDAs y recientemente, se les empieza a combinar con teléfonos y sistemas de
radio localización.".
La compañía pionera en el desarrollo de PDAs fue Apple, quien introdujo al
mercado su computadora Newton en 1993.
Según la página oficial de Palm (www.palm.com): "los modelos de esta compañía
constituyen el 78% del mercado actual de PDAs, y su éxito se basa en el hecho de
que, mas que tratar de hacer que sus dispositivos se comporten como
Computadoras Personales, han tratado de hacer algo mejor, basados en cuatro
preceptos básicos: sus dispositivos son simples, expandibles , de alta usabilidad y
movilidad". Esta filosofía de diseño, esta siendo apoyada por más de 145,000
desarrolladores alrededor del mundo.
II.2 Arquitectura de Hardware de la plataforma Palm
Hasta los modelos de la serie M50X, absolutamente todos los modelos de Palm,
usan un procesador de Motorola llamado Dragonball, y específicamente algunos
modelos emplean variantes del Dragonball como son el EZ o el VZ.
29
Figura 2.3 El procesador Dragonball
El Dragonball fue ideado como una versión de bajo consumo de Motorola
MC68000, que ya usaban a finales de los 80s computadoras como la Amiga o el
Atari. Existen tres variantes de este procesador: el modelo base, denominado DB
(Dragonball), el EZ que se caracteriza por tener un diseño más simple, menor
tamaño, menor costo y nuevas características como son un controlador de LCD
mejorado, nuevo hardware de control de sonido y diferentes puertos de E / S.
Por último, el modelo VZ, que aporta una mayor velocidad de proceso (hasta 33
MHz) y menor consumo de energía, entre otras características.
En estos dispositivos, que a diferencia de las computadoras de escritorio, no
cuentan con un medio de almacenamiento secundario (discos flexibles o discos
duros, etc.), la memoria cobra un papel importante, por que todos los programas y
datos están almacenados en memoria y se requiere un rápido acceso a estos.
30
La memoria RAM empleada en estos dispositivos es rápida y no volátil, gracias a
una alimentación continua de corriente, incluso cuando el dispositivo está
apagado.
Los modelos de Palm incluyen dos tipos de memoria, la memoria ROM donde se
aloja el sistema operativo y la memoria RAM donde residen los programas de
usuario y sus datos. El tamaño de las ROM habitualmente es de 2 MB, mientras
que el tamaño de RAM es variable, pudiendo oscilar entre los 128 KB (del modelo
Pilot 1000) hasta los 16 MB de los modelos más recientes. Desde el punto de vista
del programador, la memoria que se puede solicitar al sistema (Dynamic Heap) es
mucho menor, varia entre 32 KB y 256 KB.
A partir de los modelos Palm III y Palm IIIe, los dispositivos están equipados con
memoria flash ROM que permite actualizar el sistema operativo.
También existen tarjetas de memoria que permiten aumentar la capacidad de
almacenamiento de los dispositivos. Por ejemplo, hay tarjetas CompactFlash para
dispositivos como el TRGpro de HandEra que permiten almacenar 40MB
adicionales.
Sony por su parte comercializa otro dispositivo de expansión de memoria conocido
como MemoryStick que permite almacenar hasta 128MB de información. Sin
embargo este tipo de memoria es más lento que la memoria RAM incluida en los
dispositivos.
Las dos formas que tiene un usuario de interactuar con el Palm son:
• a través del digitalizador de escritura y
• a través de la pantalla.
31
El digitalizador de escritura no es como tal una parte del hardware. En esencia, es
un software que, haciendo uso de redes neuronales reconoce los caracteres que
escribimos sobre la pantalla táctil.
Comúnmente la pantalla de cristal líquido tiene unas dimensiones de 160 x 160
píxeles (los modelos recientes ofrecen resoluciones mayores). La frecuencia de
actualización de la pantalla es, en la mayoría de los casos, de 85 Hz. Las pantallas
pueden manipular colores desde cuatro tonos de gris (en los equipos que emplean
el Palm OS 3.0 o superior), hasta 65536 colores, usando 16 bits de profundidad de
color.
En todos los modelos la pantalla es táctil, para permitir la interacción con el
usuario, y además, algunos de ellos permiten iluminar la pantalla para trabajar en
lugares con poca luz. Cabe destacar que, aunque el método principal de
introducción de datos es el digitalizador de escritura, también es posible hacerlo a
través de un teclado en pantalla.
Las posibilidades de conexión ya sea entre Palms o con otros dispositivos, es una
parte muy importante de estos, ya que permitirán compartir información, de modo
que no se conviertan en una plataforma aislada.
El Palm tiene 2 formas de interconectarse con otros dispositivos; mediante
comunicaciones por infrarrojo (IrDA), o mediante comunicaciones serie.
El sistema IrDA permite comunicarse y compartir información con cualquier
dispositivo que soporte este protocolo, como por ejemplo, un teléfono móvil, una
impresora u otros dispositivos Palm. Para realizar una comunicación mediante
IrDA, los dispositivos que se van a comunicar deben estar situados a una distancia
máxima de un metro y sin obstáculos en medio.
32
El puerto serie permite conectarse tanto con la PC como con otros dispositivos. La
comunicación serie esta completamente basada en interrupciones para la
transmisión de datos. Se utilizan cinco señales externas para soportar esta
comunicación:
SG (signal ground)
TxD (transmit data)
RxD (receive data)
CTS (clear to send)
RTS (request to send)
La PDA se comunica con la PC a través de la base (cradle). La base es una
interfaz entre el PC y el Palm. Se trata de un soporte de plástico cuyas funciones
son: recargar las baterías del Palm (cuando el modelo lo permite) y sincronizar los
datos del Palm con la PC mediante la pulsación de un botón.
La sincronización a través de la base se realiza usando el puerto serie, pero los
modelos recientes de Palm incluyen un puerto de infrarrojos y soporte para el
protocolo de comunicaciones TCP/IP (empleado por ejemplo por los navegadores
web) .
Recientemente, Palm a incorporado el estándar Bluetooth en todos sus
dispositivos.
II.3 Arquitectura del Sistema Operativo Palm
Palm OS es un sistema operativo diseñado específicamente para su utilización en
PDAs, comercializado por la empresa Palm Computing. Este sistema operativo
presenta características específicas debido a las restricciones de los dispositivos
que lo emplean. Estas restricciones son esencialmente tres: tamaño del
dispositivo, memoria y capacidad de procesamiento de datos.
33
Figura 2.4 Arquitectura del PalmOS
Como se muestra en la figura anterior (Figura 2.4) el sistema operativo da soporte,
desde los servicios y librerías del sistema hasta la capa de abstracción del
hardware.
A continuación se describen los elementos mas relevantes del sistema operativo,
desde el punto de vista del programador.
Eventos: Los eventos informan a la aplicación de qué es lo qué está ocurriendo en
el sistema, desde una pulsación de un botón de un teclado externo, hasta el inicio
de una operación de sincronización. Se pueden distinguir eventos de alto nivel y
de bajo nivel. Los de alto nivel son los relacionados con la aplicación en si, por
ejemplo, si se selecciona un ítem del menú. Los de bajo nivel son aquellos
relacionados con el sistema operativo.
La memoria y sus limitaciones: La memoria en los Palm es un recurso muy
escaso. La RAM está dividida en dos áreas, la memoria de almacenamiento
34
(sistema de archivos) y memoria dinámica (la que emplea la aplicación durante la
ejecución). Cada una de estas es gestionada por una parte distinta del sistema
operativo, en el primer caso el Database Manager y en el segundo por el Memory
Manager.
La memoria dinámica se utiliza, tanto para las variables globales y variables
reservadas por el Palm OS, como para las variables globales, espacio de stack y
reservas dinámicas de la aplicación. La memoria esta dividida en tres bloques
(Heap) que son el dinámico, de almacenamiento y de ROM.
Los Heaps son bloques de memoria reservados en forma contigua, estos bloques
pueden estar en tres estados distintos: libres, móviles y fijos.
Controles y formularios: Un formulario es, en general, una pantalla para cada vista
de la aplicación.
Los formularios contienen controles. Un control puede ser: un botón, una etiqueta,
una lista, una tabla, un bitmap, un campo de texto o cualquier otro objeto definido
por el usuario (Gadgets).
Los controles se almacenan como recursos de la aplicación, estos son necesarios
cuando se necesita crear un elemento de interfaz de la aplicación, ya que un
recurso define cual es la apariencia del elemento y donde está colocado dentro del
formulario.
Menús: Los menús están asociados con un formulario, generalmente se definen
en tiempo de compilación, aunque estos menús pueden cambiarse
dinámicamente. Los menús se componen de barras de menú y de opciones dentro
de estos. Estas opciones del menú podrán tener asociados atajos (shortcuts). Los
35
shortcuts son letras del alfabeto que permitirán acceder rápidamente a las
opciones sin desplegar el menú.
Comunicaciones: Palm OS da soporte a tres protocolos de comunicaciones IrDA,
serie y TCP/IP. El sistema operativo proveerá de una serie de funciones para
trabajar con estos protocolos. TCP/IP esta disponible sólo sobre el puerto serie o
sobre una conexión con MODEM. Para utilizar TCP/IP se utiliza el Palm Software
Development Kit (Herramientas de Desarrollo de Software, distribuidas
gratuitamente por Palm), esta Interfaz de desarrollo de aplicaciones tiene una
librería de sockets y esta diseñada de forma muy similar al API de sockets de
Berkley.
II.4 Tipos de aplicaciones
El PalmOS almacena tanto datos como programas en forma de bases de datos.
En general, se pueden desarrollar tres tipos de aplicaciones para la plataforma
Palm.
II.4.1 Aplicaciones Web reducidas
Una aplicación Web en un Palm es un conjunto de paginas HTML comprimidas en
un formato especial (PQA). El funcionamiento de una aplicación de Web reducida
es el siguiente: las páginas Web comprimidas residen el Palm y los usuarios
rellenan los formularios HTML suministrados por estas paginas. Cuando el usuario
pulsa el botón enviar, la aplicación Web envía la petición a un servidor proxy. Este
servidor la traduce en una petición HTTP, y la reenvía al servidor Web adecuado.
Por norma general este servidor Web ejecuta un script CGI que genera la pagina
de respuesta. Esta pagina es reenviada de nuevo al proxy que la comprime y la
descarga al dispositivo para que pueda presentarse.
Estas paginas HTML comprimidas deben ser compactas y pequeñas,
considerando que se van a mostrar en la pequeña pantalla de la Palm. También
36
hay que tener en cuenta que se descargan a través de una conexión relativamente
lenta.
Figura 2.5 Ejecución de una aplicación web reducida.
La ejecución de estas páginas web se realiza mediante el visor de aplicaciones
web. Cuando el usuario pulsa el icono de una aplicación web, se lanzará primero
el visor y este mostrará el contenido de la pagina web.
37
Figura 2.6 Otra vista de una aplicación web reducida
II.4.2 Aplicaciones estándar de Palm
Se definen como aplicaciones con un sólo hilo de control, dirigidas a eventos y
mono-tarea. Esto implica que sólo habrá una aplicación en ejecución en un
instante de tiempo dado. En general, los usuarios "navegan" entre las diferentes
aplicaciones, en lugar de salir o terminar aplicaciones como en una PC.
Figura 2.7 Calculadora
Por otro lado, aunque las aplicaciones Palm están dirigidas a eventos, también
pueden realizar funciones fuera del ciclo de eventos, como respuesta a otras
peticiones del sistema operativo. Por ejemplo, si se realiza la búsqueda de una
38
palabra, se intentará encontrar en todos los registros de todas las aplicaciones esa
palabra. Esto implica que se lanzará cada una de las aplicaciones y se le pedirá
que verifique sus registros para ver si contiene esa palabra.
Figura 2.8 Juego pBill para Palm
Las aplicaciones Palm OS se compilan en archivos PRC (Palm Resource File). Un
mismo fichero PRC correrá en todos los dispositivos Palm OS.
Figura 2.9 Reloj
II.4.3 Conduits
Un conduit es un programa que se ejecuta en la PC, cuando se presiona el botón
de sincronización en la base (cradle) de la Palm. Su función es la de realizar la
sincronización de los datos entre aplicaciones de la PC y aplicaciones en la Palm.
Este tipo de aplicaciones sólo se desarrolla cuando se debe realizar unatraducción del formato de los datos. Existe un kit de desarrollo especial para estasaplicaciones: Palm Conduit Development Kit (CDK), además de las solucionesofrecidas por terceros.
39
Figura 2.10 Conduit de sincronización diaria de Palm
II.5 Estructura de una aplicación Palm.
Como menciona [Forester, 2000] la programación de aplicaciones para Palm OS
está orientada a eventos. Estos eventos pueden ser producidos por el usuario (por
ejemplo al escribir sobre la pantalla) por el sistema operativo o por la aplicación
misma, y son almacenados en la cola de eventos del sistema operativo. Estos son
procesados según el método FIFO (First In First Out: el primer evento que entra es
el primero que se procesa).
Es responsabilidad del programador decidir para que eventos se programará una
respuesta específica, dejando el control del resto al Sistema Operativo.
Cuando el sistema operativo lanza una aplicación, invoca a la función PilotMain y
le pasa como parámetro un código que indica a la aplicación la forma en que debe
arrancar; si señala que la aplicación debe arrancar y mostrar su interfaz de
usuario, se denomina un arranque normal.
Pero este código puede indicar a la aplicación que debe arrancar, realizar alguna
tarea pequeña y luego terminar (como cuando se usa la función global de
"encontrar", que busca una cadena de caracteres en las bases de datos de todas
las aplicaciones). Existen códigos de arranque para muchos propósitos, como
40
abrir una base de datos en un registro predeterminado, notificar a la aplicación que
se acaba de realizar una sincronización exitosa, etc.
Además, existe una estructura de datos que describe el tipo de evento que esta
ocurriendo en un momento dado [Ibid.]. En esta estructura se almacena el tipo de
evento que esta ocurriendo (por ejemplo, presionar con el lápiz algún botón) así
como la información relativa a ese evento (por ejemplo, las coordenadas en las
que el lápiz tocó la pantalla).
Si se realizó un arranque normal, la función PilotMain invoca a StartApplication (en
esta función se recomienda inicializar las bases de datos y obtener del sistema
operativo las preferencias del usuario), enseguida, llama a la función
FrmGotoForm, quien se encarga de cargar y mostrar la forma indicada.
Después la ejecución pasa a la función EventLoop, quien es la responsable de
procesar todos los eventos recibidos por la aplicación.
Cada nuevo evento se acomoda al final de la cola de eventos, de donde la función
EventLoop los va tomando y procesando, en el siguiente orden:
Eventos del sistema
Eventos de la barra de menú.
Eventos que carguen en memoria una nueva forma
Eventos específicos de la forma que se encuentra activa.
Este proceso se repite mientras existan eventos pendientes en la cola. Y la
función termina cuando recibe un appStopEvent. En este momento, regresa la
ejecución a PilotMain.
41
Finalmente, la función StopApplication cierra las bases de datos, indica al sistema
operativo que almacene las preferencias del usuario y realiza todas las tareas
necesarias para que la aplicación termine en forma correcta.
El siguiente diagrama muestra el orden en que son llamadas las principales
funciones de cualquier aplicación Palm:
Figura 2.11 Secuencia de llamadas de Funciones
La función denominada en el diagrama como PersonalHandleEvent es la
encargada de procesar los eventos generados por el usuario en la forma activa.
Así, si el usuario posiciona el apuntador sobre un campo de texto, o si presiona un
botón, o mueve la barra de desplazamiento de una tabla, en esta función se debe
codificar la respuesta a esos eventos.
II.5.1 Como se genera un ejecutable
Desarrollar aplicaciones para los Asistentes Personales Digitalizados,
independientemente de la marca que los construya, conlleva tomar en cuenta
algunas cuestiones, empezando por que la programación puede desarrollarse en
C o C++ (o varios otros lenguajes para los que existen compiladores que generan
código que se puede ejecutar en PDAs), sin olvidar que, como se ha citado
42
anteriormente, una aplicación para Palm es simplemente una base de datos que
contiene por una parte el código ejecutable y por otra los elementos gráficos y
demás datos.
En el caso específico de la programación para dispositivos Palm, se deben
generar archivos de "recursos" que describen la interfaz con el usuario y su
funcionamiento. Normalmente, estos archivos se obtienen usando un programa
independiente del compilador o del ambiente de desarrollo integrado.
Los archivos de recursos contienen la jerarquía de objetos de la interfaz gráfica,
empezando por la 'forma' (similar a la 'ventana' cuando se desarrolla para
Windows) a la que se le van añadiendo otros objetos como barras de menú (a las
que a su vez se les añaden menús), botones, campos de texto, tablas, etc. En
este archivo se deben inducir también los mapas de bits (bitmaps) que se van a
usar en la aplicación.
El resto del proceso de desarrollo consiste en codificar la respuesta a los eventos
que le pueden ocurrir a los diferentes objetos de la forma.
Una vez que se ha generado un programa, se procede a compilarlo, depurarlo,
corrigiendo los eventuales errores y repitiendo esta ultima parte del proceso hasta
que se obtiene un programa libre de errores.
En esta etapa, es poco conveniente probar los programas en dispositivos reales,
por que existen errores que pueden incluso, provocar la pérdida total de la
información almacenada en la Palm. Por esto último, se recomienda probar la
aplicación en un programa, llamado PalmOS Emulator, que se ejecuta en la PC y
simula totalmente la funcionalidad de una Palm (1).
43
Cuando se han eliminado todos los errores, y el programa se ejecuta sin
problemas en el emulador, esta listo para instalarse en un dispositivo real.
Codigo
Maquina
011101
Loader
Memoria
Ensamblador
Mnemonicos
mov AX,0
llda BX
Ensamblador Ligador
Lenguaje
de
Alto
Nivel
Lenguajes
de
Programación
(P.E.Pascal)
Compilador
Interprete
Figura 2.12 Niveles de programación
II.5.2 Common Object File Format
II.5.2.1 Archivo Objeto
Como se explica en [PCWebopaedia, 2003] cuando se programa, se escribe
código en forma de código fuente: instrucciones de algún lenguaje particular, como
C o Fortran. Sin embargo las computadoras sólo pueden ejecutar instrucciones
escritas en lenguaje de máquina.
Para pasar de código fuente a lenguaje de máquina, los programas deben ser
transformados por un compilador. El compilador genera un archivo intermedio con
código llamado objeto. Este archivo sirve de entrada al encadenador (linker) que
resuelve las llamadas que el archivo objeto hace a las librerías propias del
44
lenguaje. El termino "archivo objeto" no necesariamente implica alguna conexión
con la programación orientada a objetos.
Como se ha señalado, cuando un compilador procesa el código fuente (en nuestro
caso, en C o C++), genera un archivo objeto, que posee un formato específico. En
Windows, los compiladores generan archivos en formato PE COFF. En Linux,
GCC puede generar archivo en formato ELF (u otro, dependiendo de la necesidad
del programador y la configuración del ambiente de desarrollo).
Figura 2.14 Generación de un ejecutable.
II.5.2.2 COFF
Debido a que un microprocesador solo ejecuta sus propias instrucciones nativas,
una solución eficiente para desarrollar programas que se ejecuten en una
plataforma diferente a aquella en la que se programa, consiste en crear código
binario para la plataforma destino, a partir de programas fuentes (usualmente en C
o C++).
45
Pero para explotar al máximo las características físicas del dispositivo destino, se
requieren hacer optimizaciones adicionales. En la literatura existen técnicas de
optimización de código para diferentes arquitecturas de hardware. Algunos
procesadores de la familia Intel, por ejemplo, incluyen su propio coprocesador de
punto flotante, mientras que en los procesadores Motorola de la familia 68000, la
aritmética de punto flotante se debe hacer a través de librerías de software.
Por otro lado, como el mismo sistema operativo esta escrito (al menos en parte)
con instrucciones de código nativo, es más eficiente que los programas
interactúen directamente con este, y no a través de interfaces o maquinas virtuales
como la maquina virtual de Java.
La mayor dificultad que se presenta cuando se desarrollan ejecutables en código
nativo es, como puede observarse, que normalmente el código nativo no funciona
en dos plataformas de hardware diferentes. Y aún cuando el hardware sea el
mismo, pequeñas inconsistencias en la plataforma pueden ser suficientes para
causar problemas.
Algunos sistemas operativos, como el PalmOS, ofrecen acceso a rutinas internas
a través de las llamadas system traps. Estas son instrucciones que hacen
llamadas directas a servicios del sistema operativo. Pero para tener acceso a
estos servicios, la aplicación debe ligarse contra librerías de sistema ofrecidas
normalmente por el desarrollador del hardware. Estas librerías tienen un formato
binario particular al que el compilador le debe dar soporte. Un ejemplo de este tipo
de formatos es el Common Object File Format (COFF)
Los formatos ELF y COFF son muy similares, y permiten prácticamente la misma
funcionalidad. Ambos pueden usarse para especificar código objeto (de archivos
generados por el compilador), y código ejecutable (archivos producidos por la
herramienta de encadenado). Estos formatos contienen secciones. Las secciones
46
que se encuentran tanto en archivos objeto como ejecutables son: .text, que
contiene el código binario ejecutable; .data, que contiene datos inicializados en el
programa (como en una declaración "int a=7;" donde se declara un entero y se
inicializa con un valor de 7); y .bss (blow stack segment), sección que almacena
datos no inicializados (como cuando se declara "int arreglo[ 100000] ; ". En este
último caso, no se reserva espacio para la variable sino hasta cuando se el archivo
esta en ejecución).
II.5.2.3 COFF y Palm
En Unix, según explica la pagina del Manual de COFF, la salida de las
herramientas de encadenamiento (linker) y el ensamblador (llamadas a.out por
omisión) están codificadas en formato Common Object File. Un archivo de objeto
común (common object file) consiste de un encabezado de archivo, un
encabezado de sistema (en el caso de los archivos producidos por el linker), una
tabla de encabezados de sección, una sección de datos, información de
relocalización, números de línea opcionales, una tabla de símbolos y una tabla de
cadenas.
II.5.2.4 PRC-Tools
Las PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc".
Esta herramienta tiene un doble propósito: convertir recursos de código y datos al
formato que el PalmOS espera; y en general, construir programas para Palm
(PRCs) a partir de colecciones de archivos de recursos separados.
Las PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc".
Esta herramienta tiene un doble propósito: convertir recursos de código y datos al
formato que el PalmOS espera; y en general, construir programas para Palm
(PRCs) a partir de colecciones de archivos de recursos separados.
47
Las PRC-Tools producen código en formato m68k-coff, es decir, código para
procesadores de la arquitectura M68000 de Motora, usando el formato binario
COFF.
Se debe señalar que en situaciones de desarrollo como la descrita, en donde se
cuenta con una herramienta de post-encadenamiento, la elección de un formato
binario no es significativa (mas allá de los requerimientos y restricciones de la
herramienta de post-encadenamiento). La plataforma de destino nunca trabaja con
el formato binario producido por el encadenador, sino que, como se muestra en la
figura siguiente, el proceso de post-encadenamiento "traduce" la salida del
encadenador, en un archivo ejecutable para la plataforma destino.������������ ����������������������������
↓ ������!������"!#��� $&%&��'� �)(*��+�,!#�-���-����.��!��/���������0���1�'���"���2�'���43
↓�657�����28��9:�;��3 <.=)5.�����28���3 �'�4��� $>5.�/���28���9:�2�?3 <*���@�)���������)A#3
↓���AB�'� $&%&��'���(0��"�,!��&���-���(*��BA��)�����0�,�1�'��"���2�;���"3
↓��C)CC�3 <�=�CC)C�3 �'���D=FE�3 8�B��� $GCC)C�3 <.=)C�C�C�3 �'���H�;���I�)����������A����43
�/E�3��B�)= <��/� $GJ-�'�"<� K����L�#����,!#�
↓(�M�N)O.P����)AB(����2P/�������P/Q��)� $ ��(R��BA��)���)�S(*��A6!#B��A��"!#��� ���'(*�GT�U&VI3
↓����'�<,WK��G�)�)� � � $ ��(*���A����,�G����*�A.����(*���AB�)�����X(*��AW!#���AB�4!���� ���'(*�&Q�����3
↓�)8"Y+P/�'��� $GZ[��(G8��\�*ABA��(0��,�G(0M�N)O�P����A�(0���DP#��������P#�)8Y"P#�'���43
↓�/E�3 Q��'��=�E�3 8����� $G��'�"<�WK����13 Q��'�:]����'��Q��'�(0�)=���'�"<�WK����13 8���^]_J-�'�"<�WK����@���-A��&B��!#�"��� �)C:Q��'��� ���,3
↓
48
8,���A���P����'� $`%a��� �'�(���"�,!��&�,�H������! P#�����)���"���)����=)���'���?����-��'�<,WK���� cb-d.d 3
↓�6%&�A�A���3 ���'�� $-e�YD��"��!#�"8�A��1����'�15X��A�( b*f 3
Figura 2.15 Generación de un ejecutable con PRC-Tools
Otra de las herramientas disponibles en las PRC-Tools es "multigen". Esta
herramienta permite especificar varios archivos de recursos. multigen toma como
entrada un archivo de definición que especifica los archivos de recursos que se
van a usar, y produce como salida un par de archivos en los que se señalan las
secciones del código objeto que contendrán recursos. Uno de estos archivos
contiene comandos de encadenamiento, y es a su vez usado por la herramienta
ld.
II.5.2.5 CodeWarrior
Según se indica en el documento CodeWarrior Assembler Reference, esta
herramienta soporta diferentes formatos de archivos objetos, como el Executable
and Linkeable Format (ELF) o el Common Object File Format (COFF)
La herramienta de encadenamiento (linker) de CodeWarrior es una herramienta
que permite la adición de módulos que le permiten manipular diferentes archivos
objeto y librerías, permitiéndole así generar ejecutables para diferentes
plataformas
II.5.2.6 Otros
Microsoft también da soporte, en Windows NT, a los archivos objeto en formato
COFF. La versión 3.1 de Windows NT introdujo un nuevo tipo de formato de
archivo ejecutable llamado PE (Portable Executable).
Este formato se inspiró en el formato COFF (Common Object File Format) de los
sistemas operativos UNIX. Pero para mantener su compatibilidad con las
versiones del MS-DOS y los sistemas operativos Windows, el formato PE
49
mantiene el encabezado MZ del MS-DOS. Se le nombró portable, por que según
Microsoft el archivo ejecutable tiene el mismo formato sin importar si el procesador
en que se va a ejecutar tiene un tamaño de palabra de 16, 32 o 64 bits. Asimismo
este mismo formato es usado en micro procesadores diferentes a los Intel, tales
como MIPS, Alpha y Power PC, entre otros. Los archivos DLL de 32 bits y los
controladores de dispositivos (device drivers) también emplean el formato PE.
Figura 2.16 PE-Coff de Microsoft
[Ardri, 2002] reporta que utilizando las PRC-Tools, ya es posible generar
programas para el procesador ARM con el que vienen equipados los nuevos
modelos Palm Tungsten T.
II.6 Integración de un ambiente de desarrollo Palm
II.6.1 Herramientas de desarrollo disponibles
Una vez que se tiene claro cuales son los tipos de aplicaciones que se pueden
desarrollar, se deberá elegir una herramienta de programación. Para esto, se
enlistan enseguida algunas de las herramientas disponibles en este momento,
para desarrollar aplicaciones para Palm.
50
Existe una gran variedad de lenguajes de programación entre los que se puede
elegir, desde programación a bajo nivel con ensamblador hasta programación
orientada a objetos
Por ejemplo, existe una herramienta llamada Pila que permite programar en el
lenguaje del microprocesador DragonBall 68328. Pila ensambla, compila recursos
y enlaza librerías, permitiendo obtener un ejecutable de Palm.
Se ha establecido como criterio de clasificación el estilo de desarrollo,
diferenciando entre entornos de desarrollo rápido (RAD - Rapid Application
Development) y los entornos de desarrollo más tradicionales: compilador,
depurador y editor de recursos.
Como un caso especial de estas últimas herramientas, se mencionan las
disponibles bajo el esquema OpenSource, esto es, aquellas herramientas cuyo
código fuente esta disponible para ser modificado o mejorado por cualquier
persona.
II.6.1.1 Herramientas Orientadas a formularios
Herramientas Orientadas a formularios: Esta es una de las formas más rápidas y
directas de realizar aplicaciones Palm. Debido a la amplia difusión de la plataforma
Palm, existen múltiples entornos dedicados a crear aplicaciones basadas en
formularios. Los dos entornos mas extendidos son Satellite Forms y Pendragon
Forms
Satellite Forms: Cuando se emplee Satellite Forms, las aplicaciones
consistirán en tablas de bases de datos y formularios. Cada formulario estará
asociado a una tabla concreta y podrá mostrar los datos de esta.
51
Las acciones de la aplicación se pueden controlar de dos formas: Especificar
acciones "prefabricadas" que suceden en respuesta a las acciones del
usuario. Por ejemplo, cuando se pulsa un botón, se podrá elegir de entre las
opciones disponibles la que más convenga, como volver a la anterior pantalla
o crear una nueva.
Mediante código escrito por el programador. Para escribir este código se
utiliza un lenguaje de script muy similar al Visual Basic.
Satellite Forms incluye un buen numero de controles prefabricados y una
librería de rutinas. Además, tiene un mecanismo de extensión que nos
permitirá construir nuevos componentes y librerías utilizando código C.
Figura 2.17 Satellite Forms
52
Sin embargo, tiene la desventaja de que el entorno solo funciona en
Windows, y que las aplicaciones que crea obligan a instalar en el Palm una
librería de tiempo de ejecución. Por lo que esta aplicación no da la flexibilidad
que se puede obtener programando en C / C++ directamente.
Pendragon Forms: Utilizando esta herramienta, se pueden desarrollar
aplicaciones que permiten adquirir datos desde la Palm, para luego actualizar
las bases de datos corporativas.
Figura 2.18 Pendragon Forms
II.6.1.2 Herramientas Orientadas a la programación tradicional
Bajo esta categoría caen todas aquellas herramientas que permiten un mayor
control del entorno. Generalmente, incluyen un compilador, un depurador y en
algunos casos, un entorno integrado de desarrollo. Existen herramientas de este
tipo para diversos sistemas operativos como Windows, Unix y Mac OS.
53
La opción mas difundida para programar en Palm es el lenguaje C. Y existen dos
opciones principales entre las que se puede elegir: por una parte la solución
comercial con el software de desarrollo CodeWarrior de Metrowerks, y por otra las
llamadas PRC-Tools, el conjunto de herramientas Open Source desarrolladas por
la “Free Software Foundation”.
CodeWarrior es una herramienta comercial, bastante completa, que incluye el
generador de recursos “Constructor” y un depurador simbólico entre otros.
Según la compañía Palm, CodeWarrior es el entorno de desarrollo más utilizado
entre los desarrolladores para Palm. Permite crear software desde Windows o
Mac, y que se ejecuta directamente en cualquier dispositivo Palm OS y entre las
ventajas de este entorno, destacan su ambiente integrado de desarrollo (IDE), la
integración entre el compilador de C / C++ y el depurador. Además, la unión con el
emulador de Palm OS que permite probar y depurar aplicaciones más
rápidamente. También cuenta con una buena documentación sobre la plataforma
Palm OS con manuales y ejemplos.
La solución más económica, las PRC-Tools, esta compuesta por diferentes
herramientas GNU, de libre distribución como son, gcc, binutils, gdb y varias
herramientas de enlazado para producir el código ejecutable para Palm OS. Existe
una versión de las PRC-Tools para Windows, que se distribuye como parte del
ambiente de desarrollo Cygwin, y otra versión que trabaja en modo de línea de
comandos.
Las PRC-Tools ofrecen versiones de los paquetes de desarrollo GNU como el
GCC (es el compilador de C GNU), binutils (utilidades varias), GDB (depurador),
PilRC (compilador de recursos), PilrcUI (previsualizador de recursos).
54
También existen interpretes de BASIC (como CbasPad) o LISP y varias máquinas
virtuales para Java, entre las que destacan la máquina virtual KVM de SUN y la
máquina virtual J9 de IBM, esta última integrada dentro del entorno de desarrollo
VisualAge Micro Edition.
Otras herramientas que se pueden mencionar son:
Assembler SDK: Este conjunto de herramientas permite el desarrollo de
aplicaciones escritas en el ensamblador del Motorola 68000. Assembler SDK es
totalmente gratuito.
Jump: Permite desarrollar aplicaciones en Java usando una librería de clases para
Palm a través de cualquier editor de textos. El proceso que realiza Jump es
traducir los archivos .class de Java a código ensamblador del Motorola 68000. Al
igual que la anterior esta también es gratuita además de suministrar el código
fuente.
II.6.2 El PalmOs Emulator (POSE)
El emulador de Palm OS, normalmente conocido como POSE, es un emulador del
hardware de Palm que permite probar y depurar aplicaciones para Palm OS.
Se trata de un programa muy útil puesto que reproduce fielmente el
comportamiento e incluso la apariencia de los dispositivos reales y permite probar
los programas sin necesidad de usar un dispositivo real. Está disponible para los
sistemas operativos Macintosh, Unix y Windows.
Cuando se ejecuta una aplicación Palm OS en el emulador, éste captura las
instrucciones, trabaja con registros y refresca la pantalla del dispositivo trabajando
de la misma manera que lo haría el procesador utilizado dentro de los dispositivos
Palm, la diferencia reside en que las instrucciones se ejecutan mediante software.
55
Pero, a pesar de la bondad del emulador, algunas veces se hace necesario
emplear un dispositivo real para realizar las pruebas. Esto ocurre por ejemplo
cuando en la aplicación se emplea la comunicación TCP/IP mediante sockets.
Debido a que POSE emula el hardware de un dispositivo Palm es necesario
obtener un archivo con la imagen ROM del dispositivo Palm para el que se va a
programar. Este archivo no se distribuye junto con el emulador pero se puede
obtener de dos maneras, ya sea descargándolo de un dispositivo o descargándolo
de la sección ‘Palm Resource Pavillion’ de la página de Palm OS (proceso que
requiere estar registrado dentro de la base de datos de desarrolladores de Palm)
Para transferir la imagen ROM desde el dispositivo al emulador se deben seguir
los pasos indicados en la opción ‘Transfer ROM’ del emulador.
El Emulador de Palm fue desarrollado originalmente en Unix, dentro del esquema
OpenSource bajo el nombre de CoPilot, para posteriormente ser renombrado
POSE (abreviatura de PalmOs Emulator).
POSE es un programa gratuito con versiones para Windows, Macintosh y Unix /
Linux, y es importante señalar que, cuando el programador original vendió una
versión del código a Palm, esta compañía tomó la decisión de seguir
desarrollándolo, manteniéndolo (al menos en Unix) como un programa
OpenSource. Pero, además, aprovechando las posibilidades que el esquema
OpenSource ofrece, a partir de la última versión del código fuente disponible se ha
desarrollado otra versión del emulador, llamada QPilot, que es totalmente
independiente de la de Palm.
56
II.7 Características del API de Palm
Para facilitar el desarrollo de aplicaciones para sus dispositivos, Palm Inc. ofrece
un conjunto de Interfaces de Programación de Aplicaciones (APIs, por sus siglas
en Inglés) en lenguaje C.
Estas APIs están conformadas por archivos de encabezado (.h) en los que se
definen funciones y declaraciones que son fundamentales para el desarrollo de
aplicaciones en Palm.
Palm organizó estas funciones en administradores: grupos de funciones que
trabajan en forma conjunta para controlar una faceta importante del dispositivo.
Los administradores básicos controlan la interfaz de usuario, la memoria y las
comunicaciones.
Sin embargo, Palm no establece ningún tipo de organización de sus APIs, por lo
que, a continuación se sugiere un esquema de organización de las mismas.
Este esquema se elaboró estudiando el código fuente (los archivos de
encabezado) para determinar la funcionalidad que ofrece cada conjunto de rutinas,
tanto para el programador, como entre ellas.
Como se puede observar, existen un conjunto de funciones que sirven de soporte
a todo el esquema. Estas funciones hacen llamadas directas a rutinas de bajo
nivel del PalmOS (como administración de memoria y control de eventos del
sistema), por lo que se agruparon como funciones del Núcleo.
57
Figura 2.19 Organización de la API de Palm.
Sobre este conjunto inicial se construyen otras funciones, encargadas entre otras
cosas, de manejar los errores y las facilidades de depuración de código, la
aritmética de punto flotante, encriptamiento de datos, etc. Estas funciones se
clasificaron como funciones de Administración del Sistema.
También sobre las funciones del Núcleo se construyen otros conjuntos
encargados de manipular tablas de datos y otros programas (Funciones de
manejo de Archivos), eventos a los que el programa debe responder, control de
errores, control de dispositivos de comunicación (puerto, lápiz, pantalla) y
funciones de manejo de la Interfaz con el usuario.
En esta última clasificación se agrupan todas las funciones que permiten
manipular formas (abrir y cerrar, crear, etc.) y los elementos de cada forma
(mapas de bits, botones, cajas de texto, barras de desplazamiento, tablas, etc.).
58
La siguiente tabla muestra los archivos de encabezado más importantes de la API
nativa del PalmOS SDK, agrupados en el orden sugerido por el esquema.
Nivel de
Abstracción
Archivo de
encabezado
Funciones que controla
Sistema
SysEvent Eventos
MemoryMgr Memoria
PalmTypes Tipos de datos elementales
M68Khw Hardware
BuildDefines Definición de Variables
ErrorBase Errores
DebugMgr Funciones de depuración
Chars Caracteres de control
Encypt Rutinas de Encriptamiento
Event Control de Eventos
FloatMgr Números de punto flotante
Comunicaciones
ConnectionMgr Interfaz de conexión. Permite a otras aplicaciones
acceder al puerto de comunicación
Ctp Comunicación a través de Servidor Proxi
Archivos
DataMgr Tablas de datos
FileStream Archivos
Find Rutinas de control de búsquedas
Interfaz de Usuario
Form Formas
Window Ventanas
Control Rutinas generales para manipular Controles
59
Table Tablas
Field Campos
Font Fuente con el que se despliegan las cadenas de
caracteres
Rect Estructura de rectángulo. Base para el desplegado de
objetos de la Interfaz gráfica
ScrollBar Barra de desplazamiento
Bitmap Imágenes de Mapas de Bits
Tabla 2.1. Archivos importantes de la Interfaz de Programación de Aplicaciones de Palm
II.7.1 APIs Definidas por el usuario
Para integrar una nueva Interfaz de desarrollo de aplicaciones a un proyecto
desarrollado con CodeWarrior, es suficiente con crear un archivo de definiciones
de las nuevas funciones (.h), el archivo de código correspondiente (.cpp) e incluir
en el programa principal del proyecto (normalmente Starter.c o Starter.cpp), una
llamada al archivo de definiciones.
Por ejemplo, para añadir una clase miString (de manejo de cadenas de
caracteres), se crea un archivo miString.h, con la definición de la clase:
/ / mi St r i ng. h
#i f ndef _MI _STRI NG_H_
#def i ne _MI _STRI NG_H_.
#i ncl ude <St r Mgr . h>
cl ass St r i ng{
char cText o[ 100] ;
publ i c:
mi St r i ng( char * cadena) ;
60
}
#endi f
Enseguida, se crea un archivo String.cpp, con la implementación de los métodosde la clase:/ / mi St r i ng. cpp
mi St r i ng mi St r i ng( char * cadena) {
St r Pr i nt F( cText o, " %s" , cadena) ;
}
Por último, en el archivo Starter.cpp, se añade la línea:
#i ncl ude " mi St r i ng. h"
Una vez hecho esto, todas las rutinas del proyecto podrán tener acceso a la clase
miString.
II.7.2 El ambiente de desarrollo para este trabajo
Para desarrollar el presente proyecto ha decidido usar el CodeWarrior, por que
ofrece un entorno amigable, da soporte al lenguaje C o C++ y evita dar especial
relevancia a los detalles de configuración del entorno, como ocurre con PRC-
Tools.
II.7.3 CodeWarrior
El CodeWarrior (de MetroWerks) es una herramienta comercial, pero se puede
descargar una versión de evaluación con toda la funcionalidad, excepto el tamaño
de los ejecutables que se pueden crear y depurar.
61
CodeWarrior combina diferentes herramientas de desarrollo (un editor de código,
un compilador, una utilería de encadenamiento (linker) y otra de depuración
(debugger) en una sola aplicación, controlada por una interfaz gráfica.
Además, es una herramienta que se ejecuta en diferentes plataformas: existen
versiones operativas para Windows, MacOS y Solaris, y versiones en desarrollo
para otras, como Linux. Todas ellas ofrecen la misma interfaz de usuario,
independientemente del sistema operativo sobre el que se este ejecutando.
Existen versiones de CodeWarrior para C, C++, Object Pascal y Java
Para los fines perseguidos en el presente trabajo, la característica más importante
es que CodeWarrior puede generar código ejecutable para procesadores de la
serie Motorola 68000, a partir de equipos ejecutando Windows (típicamente, con
procesadores Intel x86)
II.7.4 Eligiendo entre C y C++
Para decidir si el presente proyecto se desarrollaría en C o C++, se han tomado en
cuenta distintos factores.
Por una parte, en sitios que distribuyen programas para Palm junto con código
fuente (como www.palmopensource.com ) se puede observar que hasta un 95%
de los desarrollos están hechos en C.
Una de las excepciones que se puede desatacar es el programa pBill que es una
versión para Palm del juego para Linux del juego Xbill (www.xbill.org) y que esta
desarrollado completamente en C++.
62
También existen algunas librerías en C++: hay productos de código abierto como
Teenie (solo se puede obtener en www.palmopensource.com, ya que desapareció
como producto gratuito y se convirtió en ZenPlus, un producto comercial), y otros
productos en etapas iniciales del desarrollo.
Por ejemplo, para las PRC-Tools existe un producto llamado Palm C++
Framework (www.bradygirl.com/PalmFW), las Palm SDK Foundation Classes
(sourceforge.net/projets/pfcpp/), o el "Razor! Game Engine" (www.tilo-
christ.de/razor) que es una librería para desarrollo de juegos.
Pero también hay disponibles productos comerciales, como Object Library for
PalmOS (www.aqpoint.com/pol/), el Palm Application Framework
(brearriver.com/developer/palm) o el mencionado ZenPlus.
Por otro lado, C permite simular objetos usando estructuras. [Young, 1992]
muestra un ejemplo completo de como implementar una aplicación orientada a
objetos en C manejando estructuras; en resumen, el autor propone el manejo de
los atributos del objeto a través de estructuras en C, y para simular el
encapsulamiento, todas las funciones que manipulen datos del objeto deben
recibir como primer parámetro un apuntador al mismo. De esta forma, si al
programador por accidente llamara a la función con otros objeto, ocurriría un error
en tiempo de compilación.
En su página para desarrolladores, Palm Inc. plantea una solución similar a la
comentada: estructuras en c.
Esto, por que hasta la versión 5, el conjunto de herramientas de desarrollo de
software ofrecido por Palm (PalmOS SDK), esta desarrollado en C, con un manejo
exhaustivo de estructuras, y aunque la página de PalmSource, en la sección
63
"Languajes and Environment Types"
(http://www.palmos.com/dev/start/environments.html) dice:
“Existen... librerías de C++ desarrolladas por terceros para facilitar el
desarrollo de aplicaciones Palm. Actualmente, ninguna de ellas esta
soportada oficialmente por Palm, pero detrás de cada una de ellas hay una
comunidad de desarrolladores que pueden dar soporte.
Ninguna de las librerías ofrece herramientas de desarrollo adicionales, por los
que se debe elegir un ambiente de desarrollo, obtener el último Kit de
desarrollo de Software y añadir entonces las librerías de C++ ”.
Las “recetas” de desarrollo (http://www.palmos.com/dev/support/doc/recipes/)
siguen siendo en C.
La mayor parte de la bibliografía sobre desarrollo de aplicaciones Palm disponible
en el mercado, cubre, también, solo los aspectos relativos al desarrollo con C. Así,
las primeras ediciones de libros como PalmOs Programming Bible, PalmOS
Programming, the developers guide o Instant PalmOS Applications se ocupan solo
de programación en C. Y en la comunidad mundial de desarrolladores, las
opiniones también se inclinan hacia desarrollar en C.
En páginas web como: Palm OS Programmer's FAQ
(http://tangentsoft.net/palmfaq/) publicada por Wade Hatler y Warren Young se
menciona que al desarrollar aplicaciones para Palm en C++, la principal cuestión
que se debe tener en cuenta son las limitaciones de espacio disponible en la
memoria de los dispositivos. Según la opinión de los citados autores, es muy
sencillo caer en errores de programación en C++ que provoquen que el tamaño
64
del código ejecutable se vuelva tan grande que sea imposible de manipular en un
dispositivo Palm.
Para prevenir esos errores, sugieren, entre otras cosas: evitar el uso de
Templates, usar algunas opciones de compilación que ayudan a obtener código
ejecutable compacto, y tener cuidado con la implementación del polimorfismo.
Sin embargo C tiene una serie de desventajas frente a C++. Enumerarlas todas no
es el fin de este trabajo, baste decir que el manejo mas eficiente que C++ hace de
la memoria, de entrada lo convierte en una mejor opción para programar en un
ambiente donde, como se ha explicado, el manejo adecuado de la memoria es
primordial.
Por esta razón, uno de los planteamientos que hace el presente trabajo, es el
desarrollo de una librería de objetos para CodeWarrior, bajo el esquema
OpenSource.
Esta librería es, en realidad, un conjunto de clases que enmascaran todas las
funciones ofrecidas por las APIs de Palm. Además, ofrece clases para manipular
todos los elementos de la interfaz de usuario.
También se plantea un esqueleto de todos los objetos que controlen las reglas del
negocio. Así como un esquema de control de memoria:
Considerando que en C (y C++) la mayor cantidad de memoria la consumen las
cadenas de caracteres, recordando que en C es responsabilidad del programador
liberar la memoria reservada para cadenas y que C++ no posee un esquema
"recolector de basura" que libere la memoria que ya no se esta utilizando, tan
eficiente como puede ser (por ejemplo) el de Java, se plantea la creación de una
65
sola instancia en toda la aplicación de las clases de Cadenas (de Caracteres),
Bases de datos, de todas las clases que ayuden en la manipulación de objetos de
la Interfaz de Usuario y de otras clases relacionadas más con las reglas de
negocio, como podría ser la clase Numero Flotante.
CAPITULO III
OMT PARA EL ANÁLISIS Y DISEÑO DE
APLICACIONES EN ASISTENTES PERSONALES
DIGITALIZADOS
67
III.1 Elementos de OMT
Una metodología es un algoritmo que encuentra la solución de un problema dado
a través de un proceso bien definido. Como nos dice [Pressmann, 1988], la
popularidad de las tecnologías de objetos ha generado docenas de métodos de
análisis y diseño. Cada uno de ellos introduce un proceso para el análisis del
sistema, un conjunto de modelos que evoluciona fuera del proceso y una notación
que posibilita crear cada modelo de una manera consistente. Entre otras
metodologías se pueden mencionar la de Booch, Coad y Yourdon, de Jacobson y
el OMT de Rubaugh y sus colaboradores. Recientemente fue desarrollado el
Rational Unified Process por un equipo formado por Booch, Rumbaugh y
Jacobson.
OMT es una metodología de análisis y diseño de Sistemas que según [Rumbaugh.
1991], se basa en la construcción de tres proyecciones visuales del sistema
llamadas modelo de objetos, modelo dinámico y modelo funcional. Cada uno de
ellos representa una abstracción de cierto punto de vista esencial del sistema
suprimiendo detalles que son irrelevantes para esa vista.
III.1.1 Modelo de Objetos
El modelo de objetos es el más importante de los tres. Define las clases de objetos
en el sistema y sus relaciones, atributos y operaciones (métodos). Describe la
estructura estática de los objetos en un sistema y sus relaciones; utiliza el
diagrama de objetos, el cual es un grafo cuyos nodos son clases de objetos y
cuyos arcos son las relaciones entre las clases. Sus elementos son: objetos,
clases, atributos y operaciones. Un objeto es un concepto, abstracción o cosa con
límites bien marcados y significativo para la aplicación. Todos los objetos tienen
68
identidad y son distinguibles. Una clase de objetos describe un grupo de objetos
con atributos, operaciones y semántica comunes. Un atributo es una propiedad de
los objetos de una clase. Una operación es una acción que puede ser aplicada a
(o realizada por) los objetos de una clase.
El Modelo de objetos esta compuesto por los diagramas del modelo de objetos y
diccionario de datos.
III.1.2 Modelo Dinámico
El modelo dinámico representa la información de control, incluyendo secuencias
de eventos, estados y operaciones que ocurren dentro del sistema. Indica la
interacción entre objetos y sus cambios de estado. Captura el comportamiento
esencial del sistema en diagramas de estado, y hace de uso de diagramas de flujo
de eventos para mostrar escenarios.
El modelo dinámico describe los aspectos del sistema que cambian conforme
pasa el tiempo. Se usa para especificar e implantar los aspectos de control del
sistema. Contiene diagramas de estados, los cuales son grafos cuyos nodos son
estados y cuyos arcos son transiciones entre los estados, las cuales son causadas
por los eventos. Sus elementos son: estados, transiciones y eventos. El estado de
un objeto se determina por los valores de sus atributos y sus ligas en un momento
específico. Las transiciones denotan los cambios en el estado de un objeto. Los
eventos son los que disparan las transiciones de un estado a otro.
III.1.3 Modelo Funcional
El modelo funcional captura la forma en que se calculan los valores y las
relaciones entre valores en un cálculo. Es un diagrama de flujo de datos del
sistema que describe lo que hace el sistema (no como lo hace). Describe las
transformaciones de los valores de los datos dentro de un sistema. Contiene
diagramas de flujo de datos, los cuales representan cálculos o procesamientos. Un
69
diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos
son flujos de datos. El principal elemento del modelo funcional es el proceso.
Un proceso representa una transformación de los valores de los datos. Un
diagrama de flujo de datos completo representa un proceso de alto nivel, el cual
ha sido expandido. Los procesos en este diagrama de flujo pueden ser expandidos
a su vez en procesos de bajo nivel. Eventualmente, esta recursión termina al llegar
a procesos atómicos, los cuales son procesos triviales, tales como el acceso
simple a una variable.
III.1.4 Relación entre los Modelos
Cada uno de los modelos mencionados describen un aspecto de sistema y
contienen referencias a los otros modelos. El modelo de objetos describe la
estructura de datos que es operada por los modelos dinámico y funcional.
Figura 3.1 Relación entre los modelos de OMT
Las operaciones en el modelo objetos corresponden a eventos en el modelo
dinámico y funciones en el modelo funcional. El modelo dinámico describe las
estructuras de control de los objetos. Muestra decisiones que dependen de los
70
valores del objeto y que provocan acciones que a su vez modifican estos valores e
invocan a otras funciones.
El modelo funcional describe las funciones invocadas por las operaciones del
modelo de objetos y las acciones del modelo dinámico, así como restricciones en
los valores de los objetos.
III.2 Proceso de Análisis y Diseño en OMT
OMT es una metodología desarrollada por James Rumbaugh [op. cit] en el
departamento de Investigación y Desarrollo de General Electric, en Nueva York.
Originalmente Rumbaugh desarrolló un lenguaje orientado a objetos llamado DSM
para el cual elaboró también, una notación original que más adelante daría lugar a
OMT.
El proceso de desarrollo orientado a objetos definido por Rumbaugh [Ibid.] se
muestra a continuación:
Figura 3.2 El Proceso de desarrollo de OMT
En la etapa de análisis se debe entender y modelar la aplicación y su dominio. En
la de diseño del sistema se debe determinar la estructura general del sistema en
términos de subsistemas, tareas concurrentes y elementos de almacenamiento de
datos. La etapa de diseño de objetos permite refinar y optimizar el modelo. La
etapa de codificación implica implementar las clases en el lenguaje de
programación seleccionado.
71
Cada fase del proceso transforma algunas entradas en salidas, empezando en el
nivel de abstracción mas alto y continuando en niveles mas detallados hasta el
que finalmente represente la solución del problema.
Así, la etapa de análisis recibe como entradas el conocimiento del dominio de la
aplicación y el enunciado del problema, y produce una primera versión de los
modelos de objetos, dinámico y funcional.
Estos sirven a su vez de entradas a la etapa de diseño, que produce la descripción
de la arquitectura del sistema. Con esta segunda versión de los modelos, la etapa
de diseño de objetos produce versiones detalladas que se usan en la etapa de
codificación.
Rumbaugh sugiere que esta estrategia de desarrollo iterativo empiece con la
implementación de un "esqueleto" mínimo del sistema con la infraestructura
necesaria para implementar un solo caso de uso.
Una vez que esta versión inicial del sistema es totalmente operacional, se le
puede añadir funcionalidad al sistema, en forma incremental.
III.2.1 Análisis
Según explica Rumbaugh [Ibid.] durante esta etapa se busca obtener un modelo
"preciso, conciso, comprensible y correcto del mundo real". El objetivo del análisis
es desarrollar un modelo del funcionamiento de un sistema del mundo real.
El modelo se expresa en términos de objetos y relaciones, el control dinámico de
flujo y las transformaciones funcionales. Para lograrlo, se deben examinar los
requerimientos, abstrayendo primero las características importantes del mundo
real, dejando para etapas posteriores los detalles.
72
El análisis comienza con la definición de un problema generada por el cliente y
que puede ser incompleta e informal. A partir de esta, se escribe una definición
inicial del problema, describiendo lo que se va a hacer, y no como hay que
implementarlo.
Enseguida se construye el modelo de objetos, identificando clases de objetos,
asociaciones entre objetos y atributos de unos y de otras. Usando herencia se
organiza y simplifica la estructura de clases y se agrupan las clases en módulos.
El diagrama de clases se complementa con descripciones textuales, que incluyan
el propósito y el ámbito de la entidad.
El proceso de capturar los requerimientos y consultar con el solicitante debe ser
continuo a través del análisis. A partir de la descripción inicial del problema
(enunciado del problema), se sugiere el siguiente proceso para construir un
modelo de objetos:
• Identificar las clases de objetos.
• Iniciar un diccionario de datos que contenga descripciones de clases, atributos
y asociaciones.
• Agregar asociaciones entre clases.
• Agregar atributos a objetos y ligas.
• Organizar y simplificar las clases de objetos usando herencia.
• Probar las rutas de acceso usando escenarios e iterar los pasos anteriores
según sea necesario.
• Agrupar las clases en módulos, basándose en “acoplamiento cercano” y
función relacionada.
El modelo de objetos esta compuesto por los diagramas del modelo de objetos y el
diccionario de datos.
73
El siguiente paso consiste en elaborar el modelo dinámico, en donde se
representa el comportamiento del sistema y la secuencia de interacciones. Para
esto, se preparan escenarios de secuencias de eventos entre los objetos del
sistema, ya sean típicas o excepcionales; también se identifican los sucesos
externos a los que el sistema debe responder. Para cada objeto activo se
construye un diagrama de estados que mostrará los mensajes que el objeto
recibe, las acciones que lleva a cabo y las respuestas que genere.
El proceso para desarrollar un modelo dinámico comprende:
• Preparar escenarios para las secuencias de interacción típicas.
• Identificar eventos entre objetos y preparar trazos de eventos para cada
escenario.
• Preparar un diagrama de flujo de eventos para el sistema.
• Desarrollar un diagrama de estados para cada clase que tenga un
comportamiento dinámico importante.
• Verificar que los eventos compartidos entre diagramas de estado sean
consistentes y correctos.
El modelo dinámico esta conformado por el diagrama de estado y un diagrama
global de flujo de eventos.
Para construir el modelo funcional, se identifican los valores de entrada y de salida
del sistema como parámetros de sucesos externos. Después se construyen
diagramas de flujo de datos para mostrar como se obtiene cada valor de salida a
partir de los valores de entrada.
El proceso para construir un modelo funcional, incluye:
74
• Identificar valores de entrada y salida.
• Usar diagramas de flujo de datos para mostrar dependencias funcionales.
• Describir las funciones.
• Identificar restricciones.
• Especificar criterios de optimización.
Las partes que conforman el Modelo funcional son: Los diagramas de flujo de
datos y el listado de restricciones.
Este proceso se itera tantas veces como sea necesario, tratando de:
• Agregar al modelo de objetos operaciones clave que sean descubiertas
durante la preparación del modelo funcional. No deben mostrarse todas las
operaciones durante el análisis, sólo las más importantes.
• Verificar que las clases, asociaciones, atributos y operaciones sean
consistentes y completos al nivel seleccionado de abstracción. Comparar los
tres modelos con el enunciado del problema y el conocimiento relevante al
dominio y probar los modelos usando varios escenarios.
• Desarrollar escenarios más detallados (incluyendo condiciones de error) como
variaciones de los escenarios básicos, para verificar aún más los tres modelos.
Como producto final de las etapas de análisis y diseño, se obtienen: el enunciado
del problema, y los diagramas de los modelos de objetos, dinámico y funcional.
III.2.1.1 Casos de Uso
Una forma de describir los requisitos iniciales del usuario, durante la fase de
conceptualización, es construir casos de uso del sistema, descritos inicialmente
75
por Jacobson en 1987 y actualmente incorporados a la mayor parte de las
metodologías de Análisis Orientado a Objetos.
Un caso de uso está formado por una serie de interacciones entre el sistema y un
actor (una entidad externa, ejerciendo un rol determinado), que muestran una
determinada forma de utilizar el sistema. Cada interacción comienza con un
evento inicial que el actor envía al sistema y continua con una serie de eventos
entre el actor, el sistema y posiblemente otros actores involucrados.
Figura 3.3 Casos de Uso
Un caso de uso puede ser descrito en lenguaje natural, mediante trazas de
eventos o mediante diagramas de interacción de objetos.
III.2.2 Diseño
III.2.2.1 Diseño de sistemas.
Al realizar el diseño del sistema se deben tomar decisiones de alto nivel acerca de
la arquitectura total. Durante el diseño del sistema, el sistema objetivo es
organizado en subsistemas basados tanto en la estructura del análisis como en la
arquitectura propuesta. El diseñador del sistema debe decidir que características
de desempeño optimizar, escoger una estrategia para atacar el problema y hacer
asignaciones de recursos tentativas. Por ejemplo, el diseñador del sistema debe
76
decidir que cambios a la pantalla de la estación de trabajo deben ser rápidos y
suaves aún cuando las ventanas sean movidas o borradas, y seleccionar un
protocolo de comunicaciones apropiado y una estrategia de intercambio de
bloques de memoria.
En la etapa de diseño de sistemas, se selecciona la estructura de alto nivel del
sistema. Existen varias arquitecturas canónicas que pueden servir como un punto
de inicio adecuado. El paradigma orientado a objetos no introduce vistas
especiales en el diseño del sistema, pero se incluye para tener una cobertura
completa del proceso de desarrollo de software. Los pasos sugeridos para
concretar esta etapa son:
1. Organizar el sistema en subsistemas.
2. Identificar la concurrencia inherente al problema.
3. Asignar subsistemas a procesadores y tareas.
4. Escoger la estrategia básica para implantar los almacenamientos de datos
en términos de estructuras de datos, archivos y bases de datos.
5. Identificar recursos globales y determinar los mecanismos para controlar su
acceso.
6. Seleccionar un esquema para implantar el control del software:
• Usar la ubicación dentro del programa para mantener el estado,
• implantar directamente una máquina de estado,
• usar tareas concurrentes.
7. Considerar las condiciones de frontera.
8. Establecer prioridades de decisión sobre características deseables del
producto de software.
77
El producto de esta etapa es el documento de diseño de sistema, compuesto por
la descripción de la estructura de la arquitectura básica del sistema y las
decisiones de estrategias de alto nivel.
III.2.2.2 Diseño de objetos.
En esta etapa se construye un modelo de diseño basado en el modelo de análisis
pero conteniendo detalles de implantación. El diseñador agrega detalles al modelo
de diseño de acuerdo con la estrategia establecida durante el diseño del sistema.
El enfoque del diseño de objetos es completar las estructuras de datos y los
algoritmos necesarios para implantar cada clase. Las clases de objetos del
análisis siguen siendo útiles, pero son aumentadas con estructuras de datos y
algoritmos del dominio computacional seleccionadas para optimizar importantes
medidas de desempeño. Tanto los objetos del dominio de la aplicación como los
del dominio computacional, son descritos usando los mismo conceptos y notación
orientados a objetos, aunque existan en diferentes planos conceptuales. Por
ejemplo, las operaciones de la clase Ventana se especifican ahora en términos del
sistema operativo y del hardware subyacente.
Durante esta etapa se elabora el modelo de análisis y se proporciona una base
detallada para la implantación. Se toman las decisiones necesarias para realizar
un sistema sin entrar en los detalles particulares de un lenguaje o base de datos
particular. El diseño de objetos inicia un corrimiento en el enfoque de la orientación
del mundo real del modelo de análisis hacia la orientación en la computadora
requerida para una implantación práctica. Los pasos para concretar esta etapa
son:
1. Obtener las operaciones para el modelo de objetos a partir de los otros
modelos:
• Encontrar una operación para cada proceso en el modelo funcional.
• Definir una operación para cada evento en el modelo dinámico,
dependiendo de la implantación del control.
78
2. Diseñar los algoritmos para implantar las operaciones:
• Escoger los algoritmos que minimicen el costo de implementación
de las operaciones.
• Seleccionar las estructuras de datos apropiadas para los
algoritmos.
• Definir clases internas y operaciones nuevas según sea
necesario.
• Asignar las responsabilidades para las operaciones que no están
asociadas claramente con una sola clase.
3. Optimizar las rutas de acceso a los datos:
• Agregar asociaciones redundantes para minimizar los costos de acceso y
maximizar la conveniencia.
• Reacomodar los cálculos para una mayor eficiencia.
• Guardar los valores derivados para evitar recalcular expresiones complicadas.
4. Implantar el control del software introduciendo el esquema seleccionado
durante el diseño de sistemas.
5. Ajustar la estructura de clases para incrementar la herencia:
• Reacomodar y ajustar las clases y las operaciones para
incrementar la herencia.
• Abstraer el comportamiento común de los grupos de clases.
• Usar delegación para compartir comportamiento donde la
herencia sea semánticamente inválida.
79
6. Diseñar la implantación de las asociaciones:
• Analizar las travesías de las asociaciones.
• Implantar cada asociación como un objeto distinto o agregando atributos
objeto-valor a una o ambas clases en la asociación.
7. Determinar la representación de los atributos de los objetos.
8. Empaquetar las clases y las asociaciones en módulos.
Al finalizar esta etapa se obtienen modelos de objetos, dinámico y funcional,
detallados.
III.3 Patrones de Diseño
La idea detrás de los patrones de diseño es extraer las interacciones de alto nivel
entre objetos y reutilizar sus comportamientos en diferentes aplicaciones. Cada
patrón describe un problema que ocurre una y otra vez en el ambiente de estudio
y la solución a los aspectos fundamentales del problema. De esta forma, se puede
aplicar esta solución una y otra vez al mismo tipo de problema, a pesar de que los
detalles de estos sean diferentes entre sí.
III.3.1 Qué son los patrones
En el desarrollo de software, el término patrón se refiere (según la definición que
aparece en www.whatis.com) a "un documento escrito que describe una solución
general a un problema de diseño que se presenta en forma recurrente en
diferentes proyectos". Los patrones describen el problema de diseño, la solución
propuesta y cualquier factor que pueda afectar al problema o su solución.
80
Como señala [Tidwell, 2002] "los patrones pueden considerarse descripciones de
'las mejores prácticas' de un cierto dominio de diseño. Registran soluciones
comunes a las dificultades de diseño,.. aunque cada implementación de un patrón
es diferente de las otras." Además, los patrones "permiten a los programas (y a los
programadores) compartir su conocimiento sobre diseño" [Korgaonkar, 2002].
Una característica importante de los patrones es que pueden estar anidados: Un
patrón solución puede tener cualquier tamaño; las soluciones a las diferentes
partes del problema serían en este caso, patrones más específicos.
El propósito de usar patrones es codificar el conocimiento de diseño existente, "a
fin de que los desarrolladores no estén constantemente reinventando la rueda"
[Strunk, 1999]; dar nombre a los patrones facilita la comunicación entre los
desarrolladores.
Se dice que el concepto de usar patrones comunes para resolver problemas
similares se originó en el campo de la arquitectura, con el trabajo del Arquitecto
Christopher Alexander, "A pattern Language: Towns, Buildings, Construction", en
1977 [Tidwell, 2002].
El uso de patrones permite a los diseñadores de software adaptar la solución
indicada en el patrón a su proyecto específico.
Los patrones de diseño incluyen los siguientes tipos de información:
• Un nombre, que describe al patrón
• La descripción del problema que se resuelve
• El contexto en el que ocurre el problema
• Solución propuesta
81
• Contexto de la solución
• Ejemplos y descripciones de casos de éxito y fracaso del modelo
• Usos que se le puede dar y patrones relacionados
• Autor y fecha
• Referencias y palabras clave sobre el contenido
• Código ejemplo de alguna solución, si fuera necesario.
El patrón no puede estar definido en términos de una implementación particular, ni
de un algoritmo o una estructura de datos, y se le debe considerar como una
parte del análisis y el diseño del sistema.
III.3.1.1 Ventajas de los patrones de diseño.
En la programación orientada a objetos un patrón puede contener la descripción
de ciertos objetos y clases de objetos que van a ser usadas, así como sus
atributos y dependencias y una descripción aproximada y general de la forma en
que se debe resolver el problema.
Existen una infinidad de posibilidades en las que se puede implementar la solución
a un determinado problema, y aunque los modelos de objetos bien planeados
deben ser lógicos, robustos, fáciles de mantener y reusables, difícilmente pueden
adaptarse a los cambios en complejidad o tamaño del sistema. Es responsabilidad
del desarrollador tomar decisiones que aseguren la calidad del software, y los
patrones sirven para formalizar estos principios.
En el presente trabajo se va a usar un patrón de diseño, por que, como comenta
[Coplien, 2002], muestra la forma en que se puede solucionar un problema (no
principios abstractos, sino una solución concreta, un concepto que ya ha sido
probado) .
82
III.3.2 Patrón Modelo Vista Controlador
El patrón Modelo Vista Controlador (MVC) es un patrón de diseño clásico,
comúnmente usado por aplicaciones que necesitan mantener diferentes vistas de
los mismos datos. Permite separar el objeto de la aplicación (modelo) de la forma
en que se le presenta al usuario (vista) y de la forma en que el usuario lo controla
(controlador).
Gracias a esto, el Modelo Vista Controlador facilita una clara separación de los
objetos en alguna de las tres categorías: modelos que mantienen datos, vistas que
los despliegan y controladores que manipulan los eventos que afectan el modelo o
la(s) vista(s). Gracias a esta separación, diferentes vistas y controladores pueden
interactuar con el mismo modelo. Incluso se pueden crear nuevas vistas o
controladores que interactúen con el modelo sin que se deba cambiar el diseño de
este.
La arquitectura Modelo Vista Controlador (Model/View/Controller) fue introducida
como parte de la versión Smalltalk-80 del lenguaje de programación Smalltalk. Fue
diseñada para reducir el esfuerzo de programación necesario en la
implementación de sistemas múltiples y sincronizados de los mismos datos. Sus
características principales son que el Modelo, las Vistas y los Controladores se
tratan como entidades separadas; esto hace que cualquier cambio producido en el
Modelo se refleje automáticamente en cada una de las Vistas.
83
Figura 3.4 Modelo Vista Controlador
En la figura siguiente, vemos la arquitectura Modelo Vista Controlador en su forma
más general. Hay un Modelo, múltiples Controladores que manipulan ese Modelo,
y hay varias Vistas de los datos del Modelo, que cambian cuando cambia el
estado de ese Modelo.
Figura 3.5 Un solo Modelo puede tener varias vistas y controladores
Este modelo de arquitectura presenta varias ventajas:
• Una clara separación entre los componentes de un programa; lo cual
permite implementarlos por separado
84
• Una Interfaz de Programación de Aplicaciones muy bien definida.
• La conexión entre el Modelo y sus Vistas es dinámica; se produce en
tiempo de ejecución, no en tiempo de compilación.
Al incorporar el Patrón Modelo Vista Controlador a un diseño, las piezas de un
programa se pueden construir por separado y luego unirlas en tiempo de
ejecución. Si más adelante se determina que alguno de los Componentes funciona
mal, puede reemplazarse sin que las otras piezas se vean afectadas.
Bajo este concepto, un programa puede dividirse en dos partes:
1. El Modelo: es la parte interna del programa, en donde ocurre el procesamiento
de los datos.
2. La Vista: constituye la parte del programa que se encarga de la interacción con
el usuario
La vista toma las entradas del usuario y pasa la información al modelo. El modelo
envía información a la vista, para que se la muestre al usuario.
Para evitar un acoplamiento muy estrecho entre vista y modelo, este debe operar
en forma totalmente independiente de la forma en que la vista interactúe con el
usuario, y esta debe satisfacer las necesidades del usuario, independientemente
de aquel.
Las implicaciones de estas afirmaciones son:
1. La interfaz de entrada / salida del modelo no necesariamente equivale a la
interfaz de entrada / salida de la vista.
2. Un modelo puede trabajar con diferentes vistas.
3. Una vista puede trabajar con diferentes modelos.
85
4. En general, para que un modelo y una vista se puedan comunicar, se requiere
un objeto "adaptador" que traduzca la salida de uno en la entrada del otro.
5. Ni el modelo ni la vista son capaces de crear el adaptador que los conecte, por
que son entes totalmente independientes.
Por tanto, se hace necesario un componente adicional: el Controlador. Este
controlador conoce el modelo y la vista específicos que se usan para resolver el
problema, y su función es:
1. Crear las instancias de la vista y el modelo
2. Crear la(s) instancia(s) del(de los) adaptador(es) usados para comunicar al
modelo con la vista.
3. Establecer la comunicación del adaptador con la vista, y del adaptador con el
modelo.
En resumen: en el Patrón de Diseño Modelo Vista Controlador las entradas del
usuario, el modelo de problema y la retroalimentación visual al usuario están
separadas y son manipuladas por tres tipos de objetos cada uno altamente
especializado en su tarea:
El Modelo es el objeto que representa los datos del programa. Maneja los datos y
controla todas sus transformaciones. El Modelo no tiene conocimiento específico
de los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el
propio sistema el que tiene encomendada la responsabilidad de mantener enlaces
entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo.
La Vista es el objeto que maneja la presentación visual de los datos representados
por el Modelo. Genera una representación visual del Modelo y muestra los datos al
usuario. Interactúa con el Modelo a través de una referencia al propio Modelo.
86
El Controlador es el objeto que proporciona significado a las ordenes del usuario,
actuando sobre los datos representados por el Modelo. Cuando se realiza algún
cambio, entra en acción, bien sea por cambios en la información del Modelo o por
alteraciones de la Vista. Interactúa con el Modelo a través de una referencia al
propio Modelo.
La arquitectura resultante se muestra en el siguiente diagrama. Las
implementaciones tradicionales del Patrón Modelo Vista Controlador separan el
modelo en capas con una cierta dependencia entre sí. Mientras las vistas y
controladores son genéricos, la capa del modelo de la aplicación (llamada "de
herramientas" en el diagrama) es específica del negocio.
Figura 3.6 Arquitectura de Modelo Vista Controlador
87
III.3.2.1 Modelo Vista Controlador y desarrollo para Palm.
Se espera que los programas desarrollados para la plataforma Palm funcionen,
independientemente de las características físicas del dispositivo (tamaño de la
pantalla, presencia de color, método de entrada de datos). Esto implica que el
Modelo (la parte del programa encargada de realizar cálculos, obtener datos de
archivos, etc.) debe ser totalmente independiente de la interfaz de usuario (la
Vista)
Al tratarse de aplicaciones orientadas a eventos (generados por el usuario, por el
sistema operativo, etc.) se hace necesario el Controlador, quien será el encargado
de procesar los eventos, ordenar el procesamiento de los datos al Modelo e
indicar a la vista que muestre o lea información.
III.4 Restricciones dadas por la plataforma
Como se muestra a continuación, existen una gran variedad de PDAs, de
diferentes marcas. La lista que se presenta no pretende ser una referencia
completa, sino dar una idea de la gran cantidad de dispositivos disponibles en el
mercado.
Fabricante Modelo Fabricante Modelo
Cassio Cassiopeia EM-500G Palm Inc. Palm III
Cassiopeia EM-505S Palm IIIc
Cassiopeia e-125 Pocket PC Palm IIIe
Compaq iPAQ 3660 Palm IIIx
iPAQ 3760 Palm IIIxe
iPAQ 3830 Palm V
iPAQ 3850 Palm Vx
iPAQ 3870 Palm VII
iPAQ 3950 Palm M 100
iPAQ 3970 Pocket PC Palm M105
iPAQ H3630 Pocket PC Palm m125
iPAQ - H3850 Pocket PC Palm m130
Tabla 3.1 Lista de Modelos de PDAs por Fabricante
88
Fabricante Modelo Fabricante Modelo
Dell Axim X5 Standard 300MHz Palm Inc. Palm m500
Ericsson MC218 Palm M505
Treo Handera 330 Palm m515
Handspring Treo 270 Psion Psion Revo
Handspring Visor Psion Series 3a
Handspring Visor Edge Psion Series 5
Hitachi Eplate 600 et Psion Psion Series 5mx
HP 200lx Psion Series 7
Jornada 525 pocket pc Sagem WA 3050
Jornada 545 Sony Sony Clie PEG N770C
Jornada 545/548 Sony Clie PEG S300
Jornada 568 64MB
Pocket PC
Sony Clie PEG-SJ30
Jornada 720 PDA Sony Clie PEG-T425
IBM WORKPAD Z50 Sony Clie PEG-T625C
Sony NR70VG
Sony T625c
Toshiba Pocket PC e570
Tabla 3.1 (cont.) Lista de Modelos de PDAs por Fabricante
89
III.4.1 Los distintos modelos de Palm
Dentro de la gama de dispositivos fabricados por Palm Inc. hay diferencias mas o
menos importantes, en cuanto a capacidad, tamaño físico del dispositivo, etc.
Algunas de estas características se enlistan en la siguiente tabla.
Tabla 3.2. Comparación entre los modelos de Palm Inc.
Tungsten T Zire m515 m130 m125 m100 m105
Peso 157 gr. 109 gr. 139 gr. 124 gr. 124 Gr. 124 Gr. 124 Gr.
Memoria 16 Mb 2 Mb 16 Mb 8 Mb 8 Mb 2 Mb 8 Mb
Palm OS 5 4.1 4.1 4.1 4 3.5 3.5
Tamaño 10.2 x 7.5 x 1.5
cm
11.2 x 7.4 x 1.6
cm
11,4 x 7,9 x 12,7
cm.
4.66" x 3.12" x
0.72"
4.66" x 3.12" x
0.72"
4.66" x 3.12" x
0.72"
4.66" x 3.12" x
0.72"
Vibrador si no si no no no no
Memoria Flash si no si no no no no
Pantalla Alta resolución.
65.536 colores.
Monocroma 65.000 colores 65.000 colores escala de grises escala de grises escala de grises
Direcciones 20,000 6,000 20,000 10,000 10,000 6,000 10,000
Citas 10 años 5 años 10 años 5 años 5 años 5 años 5 años
Agenda 6,000 1,500 6,000 3,000 3,000 1,500 3,000
Memos 6,000 1,500 6,000 3,000 3,000 1,500 3,000
E-mail 800 200 800 400 400 200 400
Capacidad para
agregar
aplicaciones
Juegos, ebooks,
datos y mucho
más...
Juegos, ebooks,
datos y mucho
más...
Juegos, ebooks,
datos y mucho
más...
Juegos, ebooks,
datos y mucho
más...
Juegos, ebooks,
datos y mucho
más...
Juegos, ebooks,
datos y mucho
más...
Juegos, ebooks,
datos y mucho
más...
Tipo Recargable litio-
ion
Recargable litio-
ion
Recargable litio-
ion
Recargable litio-
ion
AAA AAA AAA
Vida (uso normal) 1 semana 1 mes 1 mes 1 mes 2 meses 2 meses 2 meses
Comunicación vía
puerto serial
si. Tiene Slot
para tarjetas de
expansión.
si si. Tiene Slot
para tarjetas de
expansión.
si. Tiene Slot
para tarjetas de
expansión.
si. Tiene Slot
para tarjetas de
expansión.
si si
Infrarrojo si si si si si si si
90
III.4.2 Características generales de las computadoras de mano,
independientemente de la marca.
No todos los dispositivos mencionados usan el PalmOS como su sistema
operativo nativo. Al final del capítulo, la tabla 3.2 compara las características de
algunos de los equipos que manejan PalmOS (modelos del Palm Inc. y otros),
contra computadoras de mano (handhelds) que usan otros sistemas operativos y
contra un equipo PC de escritorio Típico.
III.4.3 Comentarios Finales
Los programas para dispositivos Palm basan su funcionamiento en el uso de
formas. El usuario interactúa con estas formas para alimentar datos y recibir
mensajes de la aplicación; por otro lado, la aplicación recibe las entradas del
usuario, las procesa y genera distintos tipos de mensajes de salida. De acuerdo a
lo explicado previamente en este capítulo, este esquema corresponde al del
Patrón de diseño Modelo Vista Controlador.
Sin embargo, tomando en cuenta también las características del hardware y el
sistema operativo, se puede establecer que las clases que se desarrollen para
manipular la interfaz con el usuario, serán exactamente las mismas
independientemente del sistema que se este desarrollando. El sistema operativo
de la Palm ofrece un conjunto finito de controles a partir de los que se construyen
las diferentes pantallas que el sistema pueda necesitar. Como este conjunto de
controles no puede cambiarse, no es aventurado afirmar que el análisis y diseño
de la Interfaz con el usuario se pueden hacer una sola vez, y aplicarse siempre, en
cualquier desarrollo posterior.
Tabla 3.3 Comparación de modelos de Handhelds contra una PC
Fabricante Modelo Precio
estimado
Máximo
(U$)
Memoria
RAM
Instalada
Capacidad
de
Expansión
Procesador Velocidad
del
Procesador
Método de
sincronizaci
ón
Tipo de
Sistema
Operativo
Versión del
Sistema
Operativo
Capacidad
para
actualizar
el
Sistema
Operativo
Tipo de
Pantalla
Resolución
de la
Pantalla
Area útil
de la
pantalla
(pulgadas
cuadradas)
Profundida
d
de
color
Blackberry H1100 $499 5M No Intel 386 N/D Serial,
Infrarrojo
BlackBerry N/D N/D Monocrom
o
160 x 160 7 N/D
Casio Cassiopeia
E-105
$479 32M Compact
Flash
NEC 131 MHz Infrarrojo,
Serial
Pocket PC Windows
CE 2.1
N/D Color 240 x 320 3.9 16 bits
Compaq iPaq
H3850
$604 64MB Secure
Digital
Intel
StrongARM
206 MHz Infrarrojo,
USB
Pocket PC Pocket PC
2002
Si Color 240 x 320 3.77 16 bits
Diamond Mako $149 16MB No ARM 710 T
RISC
36 MHz Infrarrojo,
Serial
EPOC EPOC R5 Si Monocrom
o
240 x 320 7.4 N/D
Handspring Treo 180 $499 16MB No Motorola
Dragonball
VZ
33 MHz USB Palm OS 3.5.2 o
superior
Si Monocrom
o
160 x 160 3 N/D
Visor $92 2MB Springboar
d
Motorola
Dragonball
EZ
16 MHz Infrarrojo,
USB
Palm OS 3.1 Si Monocrom
o
160 x 160 3.1 N/D
Visor
Deluxe
$109 8MB Springboar
d
Motorola
Dragonball
EZ
16 MHz Infrarrojo,
USB
Palm OS 3.1 Si Monocrom
o
160 x 160 3.1 N/D
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
Fabricante Modelo Precio
estimado
Máximo
(U$)
Memoria
RAM
Instalada
Capacidad
de
Expansión
Procesador Velocidad
del
Procesador
Método de
sincronizaci
ón
Tipo de
Sistema
Operativo
Versión del
Sistema
Operativo
Capacidad
para
actualizar
el
Sistema
Operativo
Tipo de
Pantalla
Resolución
de la
Pantalla
Area útil
de la
pantalla
(pulgadas
cuadradas)
Profundida
d
De
color
HP Jornada
720
$833 32MB Tarjeta PC,
Compact
Flash
StrongARM
RISC
206 MHz Infrarrojo,
serial, USB
Pocket PC Windows
para
Handheld
PC 2000
Si Color 640 x 240 6.5 16 bits
Palm Tungsten T $499 16MB MultiMedia
Card,
SmartMedi
a
Texas
Instruments
OMAP
1510
N/D Infrarrojo,
USB
Palm OS 5 Si Color 320 x 320 N/D 16 bits
m100 $93 2MB No Motorola
Dragonball
EZ
16 MHz Infrarrojo,
serial
Palm OS 3.5 Si Monocrom
o
160 x 160 3.3 N/D
Palm IIIc $88 8MB No Motorola
Dragonball
EZ
20MHz Infrarrojo,
serial
Palm OS 3.5 Si Color 160 x 160 4.1 8 bits
Sony CLIE PEG-
SL10
$150 8MB Memory
Stick
N/D N/D USB Palm OS 4.1 Si Monocrom
o
160 x 160 4.1 N/D
PC
ACER Aspire
G600 p
A partir de
$800
hasta 3 GB Si Intel 2.4 a 2.8
GHz
N/A Opcional
(Windows)
Si Color 1600 x
1200
350 x 262
mm
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
Fabricante Modelo Tipo de
Baterías (1)
Duración
estimada
(hrs)
Soporte a
tecnología
Bluetooth
Tamaño
(Alto, Largo, Ancho)
en pulgadas
Peso
(onzas)
Características Adicionales
Blackberry H1100 Recargable 7 No 4.6 x 3.1 x 0.7 5.3 Bocina
Casio Cassiopeia E-
105
Recargable (2) 6 No 5 x 3.3 x 0.7 9 Entrada para audífonos, microfono, entrada para tarjeta
multimedia, batería de respaldo
Compaq IPaq H3850 Recargable 10 No 5.1 x 3.3 x 0.6 6.3 Entrada para audífonos, mícrofono, software multimedia
Diamond Mako Recargable (3) 12 No 3.1 x 6.2 x 0.7 7 Bocina
Handspring Treo 180 Recargable 60 No 2.7 x 4.3 x 0.7 5.2 Microfono
Visor AAA (4) 60 No 4.8 x 3.0 x 0.7 5.4 Bocina
Visor Deluxe AAA (4) 60 No 4.8 x 3.0 x 0.7 5.4 Bocina
HP Jornada 720 Recargable 9 No 7.4 x 3.7 x 1.3 17 Entrada para audífonos, micrófono.
Palm Tungsten T Recargable N/D Si 4.0 x 3.0 x 0.6 5.6 Bocina estéreo
m100 AAA (4) 60 No 4.7 x 3.1 x 0.7 4.4 Bocina
IIIc Recargable 30 No 5.1 x 3.2 x 0.7 6.8 Bocina
Sony CLIE PEG-
SL10
AAA N/D No 4.6 x 2.8 x 0.6 3.6 Software multimedia
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
PC
ACER Aspire G600 p N/A N/A N/D 452mm x 180mm x 417mm N/D CD-Lectura/Escritura, DVD, puertos serie, paralelo, USB, entrada
para audífonos, micrófono
(1) A menos que se indique otra cosa, todos los modelos vienen con batería de ion litio(2) La batería recargable se puede remover y reemplazar.(3) Niquel-metal hidruro.(4) Requiere dos baterías AAA.N/D Dato no disponibleN/A No aplica
CAPITULO IV
CASO DE ESTUDIO: SVES
96
IV.1 Sistemas de Apoyo en la toma de decisiones
Los sistemas de apoyo para la toma de decisiones tienen muchas características
que los hacen diferentes a otros sistemas tradicionales.
Un sistema de apoyo para la toma de decisiones es un instrumento que sirve para
organizar información que será usada en algún proceso de toma de decisiones.
Presenta la información requerida por el usuario y eventualmente sugiere la mejor
solución, de acuerdo a los parámetros con los que fue programado.
[ Kendall, 1991] dice: "Un sistema de apoyo para la toma de decisiones permite
que el tomador de decisiones se relacione de una manera natural con la
información por medio de un diseño cuidadoso de la interfaz con el usuario...
Puede construirse para apoyar decisiones que se toman una sola vez, o aquellas
que son poco frecuentes, o bien aquellas que ocurren de manera rutinaria.
Un sistema de apoyo para la toma de decisiones se puede diseñar para una
persona en particular, o bien para un grupo de tomadores de decisiones. Esto
permite que el diseñador del sistema estandarice características básicas del
sistema para adaptarlo al tipo de representaciones (gráficas, tablas, diagramas,
etc.) e interfaces que el usuario comprenda mejor.
La forma de recopilar, procesar y utilizar la información define los parámetros del
estilo de toma de decisiones. La toma de decisiones analítica se basa en
información que se adquiere y evalúa de manera sistemática para reducir las
alternativas y elegir con base en tal información. El tomador de decisiones
97
analítico aprende a analizar situaciones particulares. Existen procedimientos
definidos paso a paso para efectuar la decisión, y se hace uso de las matemáticas
para modelar los problemas. Adicionalmente, puede involucrar el uso de una base
de datos para almacenar información estadística o histórica.
IV.1.1 Proceso general de toma de decisiones
El diagrama de la Figura 4.1 sugiere un procedimiento para la toma de decisiones.
Como señala [Landsberger, 2002 ], los pasos difícilmente se pueden seguir en
forma secuencial, ya que normalmente se traslapan, y eventualmente habrá que
retomar pasos previos, o trabajar simultáneamente en varios de ellos hasta
encontrar la mejor solución al problema.
Figura 4.1 Proceso de toma de decisiones.
[Landsberg, op. cit.] indica también que una mala definición del problema suele ser
la causa de que no se llegue a solucionar totalmente el mismo, por lo que, en caso
de que el problema no se encuentre bien definido, se deben considerar los
objetivos que se espera cumplir y los eventuales obstáculos que se puedan
presentar.
98
Para obtener información se debe acudir en primer lugar, a los individuos, grupos
u organizaciones afectadas por el problema o su solución. Enseguida, se deben
buscar resultados de investigaciones, estudios y experimentos ya existentes,
además de entrevistar a los expertos en el área de estudio y demás fuentes
confiables de información. Así mismo, se deben determinar las restricciones y
tomar en cuenta las opiniones de aquellos individuos que influirán en la solución
del problema.
El siguiente paso consiste en tratar de estudiar el problema desde diferentes
perspectivas, tratando de encontrar posibles soluciones alternativas. Todas las
alternativas encontradas deben ser evaluadas. Por otro lado, se debe considerar si
la alternativa es ética y/o práctica, si se cuenta con los recursos necesarios para
llevarla a cabo, cual es su probabilidad estimada de éxito, etc. Para seleccionar la
mejor, se deben evitar las "soluciones perfectas" ya que este tipo de soluciones
implican que en realidad no existía un problema.
Landsberg [Ibid.] afirma que, mientras no se implementa, cualquier solución es
solo una buena intención. Para llevar a cabo la implementación de cualquier
solución, se debe desarrollar un plan que considere cada paso o acción que se
debe efectuar, las estrategias de comunicación que se establecerán con los
expertos, la distribución de los recursos identificados y el tiempo del que se
dispone. Pero la implementación será exitosa solo si se realiza un monitoreo
constante del progreso de la solución y sus efectos . Si no se esta alcanzando el
objetivo esperado, se deben reconsiderar las opciones y la alternativa elegida.
IV.1.2 Sistemas de diagnóstico médico.
El diagnóstico es y será el problema mas importante en la medicina y los sistemas
de soporte de decisiones para diagnóstico médico jugarán un papel cada vez mas
99
importante en el cuidado de la salud, mejorando la calidad y eficiencia del proceso
de diagnóstico.
Para elaborar un sistema experto de diagnóstico médico, se parte de los
exámenes médicos (examinación física, pruebas de laboratorio, etc.) de pacientes
de los centros de diagnóstico modernos. Con ellos se recaba una gran cantidad de
información inicial.
Si cada uno de estos datos se mide usando solo las escalas mas simples (“si-no”,
“mas-menos”) se obtendrían cantidades de información muy difíciles de manipular.
Debido a la imposibilidad de manipular tal cantidad de información, se han
desarrollado sistemas expertos (programas de computadora que imitan el
pensamiento del experto en algún campo del conocimiento) que incorporan el
conocimiento formal de los médicos y son capaces de tomar decisiones en la
misma forma en la que un ser humano lo haría.
La eficiencia en la operación de un sistema experto depende en primer lugar de la
cantidad y calidad de la información disponible en la base de datos de
conocimientos. Esto es un punto débil de los sistemas expertos porque la base de
conocimientos esta basada en ideas subjetivas de expertos cuyo conocimiento es
limitado y quienes en ocasiones no son capaces de formalizar su experiencia
presentándola como reglas claras.
IV.1.2.1 Perspectiva Histórica
El interés de la humanidad en dar soporte a las decisiones medicas y establecer
guías de apoyo a los médicos se puede rastrear hasta el año 650 a.C. en
Babilonia. Existen escritos cuneiformes de esa época que sugieren exámenes
médicos, diagnósticos y prognosis de enfermedades:
100
"Cuando usted se prepare para examinar a un hombre enfermo..."
"Si después de un día de enfermedad, él empieza a sufrir dolor de cabeza..."
En la época moderna, se reconoce que las computadoras pueden apoyar al
médico en los procesos de diagnóstico y terapéutico.
A finales de la década de los 50s, aparecen artículos que exploran esta
probabilidad: “Ledley y Lusted publican su artículo clásico ‘Reasoning Foundations
of Medical Diagnosis’ al que siguió la primera generación de sistemas que trataban
de apoyar al médico en la toma de decisiones" [Federhofer, 2002].
IV.1.2.2 Sistemas Expertos
Un sistema experto es un programa que trata de imitar la experiencia de un
humano aplicando métodos de inferencia a un campo específico del conocimiento
llamado dominio. Al principio de la década de los 70s, con el desarrollo del área de
la Inteligencia Artificial, fue posible desarrollar sistemas expertos que podían
manejar conocimiento médico incierto o incompleto.
Las herramientas de software médico emergen durante la década de los 80's. En
los últimos tiempos se ha observado un enorme desarrollo en los Sistemas
Expertos Médicos, y los sistemas disponibles actualmente son suficientemente
maduros como para permitir su adopción en la práctica médica [Ibid.]
El caso mejor conocido es MYCIN, un sistema experto que fue desarrollado en la
Universidad de Stanford en 1976 con el fin de ayudar a los médicos en el
diagnóstico y tratamiento de pacientes con enfermedades infecciosas en la
sangre, mismas que pueden ser fatales si no reconocen y tratan a tiempo.
101
Otro ejemplo notable es PUFF, un sistema experto que diagnostica la presencia
de enfermedades severas en el hígado. El Brain Tumors Diagnostic System
(BTDS) es otro sistema experto que ayuda a los médicos a diagnosticar tumores
cerebrales. BTSD esta conformado por un sistema experto y un sistema de
aprendizaje.
IV.1.2.3 Funcionamiento de los sistemas de diagnóstico medico
Los sistemas de diagnóstico ofrecen al médico preguntas y respuestas
estructuradas dentro de un dominio de conocimiento especializado. La estructura
es programada con la supervisión de uno o más expertos médicos, quienes
también sugieren las mejores preguntas y ofrecen las mejores conclusiones que
se pueden obtener a partir de las respuestas obtenidas. En términos de
programación, estas secuencias de decisión se representan con cláusulas "If...,
Then..., Else..." ("Si..., entonces..., si no...")
En general un sistema experto de diagnóstico medico funcionaría como se explica
a continuación:
Una combinación de signos, síntomas y resultados de laboratorio, se compara
contra una base de datos de condiciones médicas bien conocidas. Esta
comparación se hace usando inteligencia artificial, reconocimiento de patrones y
otras técnicas matemáticas. Además, se aplican reglas derivadas del conocimiento
de los expertos a fin de depurar los resultados y llegar a un diagnóstico probable.
IV.1.2.4 Ejemplo
Considérese, el siguiente escenario:
Un paciente X se presenta ante un medico, o un auxiliar quejándose de un fuerte
dolor de cabeza, fiebre y dolor muscular.
102
Una pequeña fracción del conocimiento de los expertos, se ha resumido en la
siguiente tabla:
Síntoma Síntoma Síntoma
Dolor de cabeza Dolor de cabeza Dolor de cabeza
Calentura Calentura Mareo
Dolor Muscular Dolor Muscular
Tos
Dolor de garganta
Padecimiento probable:
Catarro
Padecimiento probable:
Dengue
Padecimiento probable:
Presión Alta
Tabla 4.2 Conocimiento del experto médico, resumido en una tabla.
Consultando la tabla se puede ver que la sintomatología indicada por el paciente
no corresponde a la de un probable catarro (ya que no menciona tener tos ni dolor
de garganta); sin embargo, si se podría sospechar un posible caso de Dengue, o
de Presión Alta.
IV.2 Antecedentes del Sistema de Vigilancia Epidemiológica
La información que aparece a continuación fue tomada del documento: Manual
para la Vigilancia Epidemiológica Simplificada, editado por la Secretaría de Salud.
El ejercicio de la salud pública como elemento indispensable para alcanzar el
desarrollo integral de los individuos, la familia y la comunidad representa una
preocupación constante de especial prioridad y sin lugar a dudas requiere de un
mayor impulso dentro de la sociedad. En la actualidad aun persisten graves
desigualdades y problemas epidemiológicos fundamentales, los cuales afectan de
103
manera importante a grandes grupos de población, especialmente a quienes no
tienen acceso a servicios de salud.
Es necesario establecer un orden prioridades principalmente en donde se trabaje
con escasos recursos: humanos, materiales, financieros y tecnológicos; es preciso
seleccionar métodos de intervención mas adecuados, aplicar tecnologías y
modelos de atención apropiados que respondan a las necesidades presentes y
futuras de la población.
Es aquí donde adquieren su verdadera dimensión los mecanismos de información
en salud, ya que para establecer prioridades y tomar decisiones adecuadas en
tono a la prestación de los servicios, es indispensable contar con los elementos de
diagnostico que permitan conocer y evaluar los daños a la salud, así como los
diversos factores de riesgo que intervienen en su distribución y frecuencia. Los
sistemas de información se constituyen así en un componente esencial de alto
valor técnico e importancia estratégica en el campo de la salud y la administración
de los servicios de esta, especialmente por su utilidad para conformar el
diagnóstico de salud de la comunidad e identificar los problemas epidemiológicos
de mayor prioridad, los grupos y situaciones de alto riesgo, además por su
contribución a la evaluación y monitoreo de los servicios y programas de salud.
Desafortunadamente, la información en salud no siempre se encuentra disponible
y, aunque parece relativamente abundante en algunos sectores, es escasa,
inoportuna y de muy baja calidad en otros, como algunas áreas ampliativas en las
jurisdicciones; en el propio nivel comunitario, dado su menor adelanto, llegan a
tenerse serias limitaciones para contar con el personal intermedio debidamente
capacitado para organizar, de manera oportuna y ágil, la producción, análisis y
utilización de los datos y, en general, para cumplir con las funciones específicas
en materia de información y vigilancia epidemiológica.
104
Es muy frecuente encontrar situaciones en donde es prácticamente imposible
obtener una cobertura universal de la información. Por esta razón y para reducir
estas inconveniencias, fueron ideadas y propuestas modernas y efectivas técnicas
por muestreo, además de formas de investigación complementaria, que sin
embargo, resultan insuficientes para generar el conocimiento básico sobre
situaciones especiales de interés epidemiológico, demográfico y de servicios de
salud.
De este modo, los métodos no convencionales de información para la salud
representan una alternativa de corto plazo en situaciones en las que existe una
importante carencia de información y en donde el conocimiento de los problemas
epidemiológicos no siempre es un insumo para el desarrollo de la salud
comunitaria.
Por ello, desde 1954 y en especial en los últimos años, diversos países y
organizaciones se han dado a la tarea de enseñar e impulsar el uso alternativo de
métodos no convencionales de información, dentro de ellos las técnicas de
registro y notificación epidemiológica basadas en la comunidad, que permiten
llenar los vacíos de información al interior de los sistemas de estadísticas vitales
y de salud, en particular en áreas geográficas donde existen restricciones o
rezagos considerables.
Destacan a este respecto las experiencias de algunos países latinoamericanos,
entre ellos México, que han utilizado entre otras alternativas de tipo no
convencionales las técnicas de Lay Reporting o Informes de Salud de Legos, que
en general son aplicadas al reforzamiento de los sistemas de estadísticas vitales y
de vigilancia epidemiológica, a la determinación complementaria del estado de
salud de la población y a la identificación de necesidades a nivel de la comunidad.
En términos más específicos, han sido aplicados al registro de la mortalidad
general, la mortalidad materno-infantil, la vigilancia epidemiológica de algunas
105
enfermedades transmisibles y la desnutrición, así como al registro de hechos
vitales y de servicios básicos de salud. De igual manera, han sido utilizados en las
tareas de monitoreo y evaluación de las condiciones de saneamiento básico y del
ambiente en general.
Los métodos de información comunitaria han recibido a últimas fechas más
atención de la Organización Mundial de la Salud, quien ha elaborado y difundido
un sistema de información de salud, con participación de personal no médico, que
incluye la utilización de una lista mínima detallada de causas tanto de morbilidad
como de mortalidad.
IV.3 Sistema de vigilancia epidemiológica
La vigilancia epidemiológica enfoca sus esfuerzos a la recolección sistemática de
la información, su análisis y diseminación; para guiar los programas de prevención
y control de las enfermedades con mayor impacto sobre la salud de la población.
La vigilancia epidemiológica permite estimar la magnitud de un problema de salud
pública, documentar su distribución y propagación, describir su historia natural e
identificar la aplicación de los fenómenos epidemiológicos que afectan a la
población.
Los atributos más importantes de un sistema de vigilancia epidemiológica son:
a) simple en su estructura
b) representativo de la población a la que sirve
c) aceptado por los usuarios
d) flexible para la incorporación de nuevos datos cuando sea necesario
e) oportuno en la captación y diseminación de la información
106
IV.3.1 Sistemas no convencionales de Información
Desde finales de la década de los 70, varios países han experimentado con la
recolección de información por personal no médico (lego); este tipo de recolección
(lay reporting) ha sido subsecuentemente extendido a un concepto amplio
denominado "métodos no convencionales de información". En diferentes países,
estos métodos, que cubren una variedad de enfoques, han evolucionado como
medios de obtener información acerca del estado de salud de la población donde
los métodos convencionales (censos, encuestas, estadísticas vitales y estadísticas
de morbilidad) han resultado inadecuados o no existen.
Uno de estos enfoques, denominado "información basada en la comunidad"
implica la participación de la comunidad en la definición, recolección y utilización
de la información relacionada con la salud. El grado de participación de la
comunidad va desde el trabajo de recolección de los datos solamente, hasta el
diseño, análisis y la utilización de la información.
Los métodos no convencionales de información en salud pueden ser definidos
como un conjunto de técnicas y procedimientos de carácter complementario y que
permiten analizar la información básica sobre los problemas de salud, problemas
para los cuales no se cuenta con la infraestructura ni tecnología apropiadas que
satisfagan las necesidades de información de los sistemas formales de salud.
En 1976, la OMS detalló una lista de asociación de síntomas, susceptibles de
reconocer por personal de servicios de salud primarios (esto es, quienes no están
médicamente calificados por los estándares comúnmente aceptados) e indicativos
de condiciones que son importantes problemas de salud en varias partes del
mundo. De esta lista detallada derivaron dos listas, una para causas de muerte y
otra de razones para contacto con servicios de salud.
107
Los propósitos de la información de salud colectada son: alertar a las autoridades
de salud para la emergencia de un problema de salud y facilitar el manejo de
cuidados de salud primarios. Los datos colectados deben ser analizados y
reportados hacia el siguiente eslabón administrativo.
IV.3.2 Aspectos epidemiológicos
El panorama epidemiológico en México está constituido por tres configuraciones:
1. La primera, por el predominio de las enfermedades cardiovasculares,
de las crónico-degenerativas, los accidentes, además de problemas
sociales de violencia, alcoholismo y drogadicción.
2. La segunda, dominada por enfermedades infecciosas ligadas a la
pobreza, la desnutrición y la deficiente higiene ambiental y laboral, y
3. La tercera, por problemas de salud derivados de insuficiente
saneamiento básico
IV.4 Sistema de Vigilancia Epidemiológica Simplificada
La vigilancia epidemiológica simplificada consiste en un sistema de nivel
comunitario; su establecimiento responde a la necesidad de contar con los
mecanismos necesarios para reconocer la problemática del área rural marginada,
para fortalecer al Sistema de Información Nacional y al Sistema de Nacional de
Vigilancia Epidemiológica; se aplica en las comunidades rurales de menos de
2,500 habitantes (aproximadamente 154 016), de las cuales el 96.7% tiene menos
de 500 habitantes.
Diez millones de mexicanos no tienen acceso a los servicios de salud, viven en
condiciones geográficas de difícil acceso, de alta marginalidad y dispersión, en
donde no es posible contar con personal médico y paramédico necesario para la
108
atención de sus necesidades básicas o problemas prioritarios de salud. El
establecimiento de métodos alternativos de solución a los problemas de salud
requiere de información oportuna y completa sobre los daños y riesgos a la
población, ya que de otro modo se corre el riesgo de tener escaso o nulo impacto
en su prevención y control. Ante esto, la Secretaría de Salud decidió desarrollar
diversas acciones de trabajo comunitario, con la participación de personal
comunitario voluntario previamente capacitado, para utilizar instrumentos de
registro y técnicas de diagnóstico de fácil manejo que faciliten la identificación de
ciertos padecimientos y riesgos a la salud, que permitan dar solución a los
problemas de mayor importancia local y regional.
Uno de estos esfuerzos es el Sistema de Vigilancia Epidemiológica Simplificada
(SVES). Los objetivos generales del SVES son identificar el perfil de los problemas
de salud en áreas rurales carentes de servicios de salud, sistematizar el uso de la
información para identificar grupos de riesgo, generar información básica para
apoyar las actividades de programación local y fortalecer el sistema de vigilancia
epidemiológica y el sistema de información nacional.
El SVES considera a la comunidad como elemento central de las actividades
básicas y crea una red de vigilancia simplificada a cuyo cargo están los auxiliares
de Salud, estrechamente vinculados con los servicios, a través de las unidades de
Salud. Existen responsables de la unidad por región o a nivel jurisdiccional, y se
encargan de fomentar y asegurar la participación de los auxiliares, para alertar a
los servicios de salud sobre la presencia de problemas epidemiológicos.
IV.4.1 Componentes del SVES
El SVES esta definido como un conjunto de técnicas y procedimientos sencillos,
con participación activa de la comunidad como elemento del sistema, a través del
cual se registra, notifica, procesa y analiza la información básica sobre daños a la
109
salud y situaciones de importancia epidemiológica de las comunidades sin acceso
a los servicios de salud.
El SVES permite entonces, mediante técnicas sencillas, identificar signos y
síntomas para conformar mediante la metodología del interrogatorio, diagnósticos
probables de enfermedad. Además registra diagnósticos de primera vez (casos
nuevos) y permite el autocuidado de la salud individual con la participación del
personal comunitario con mínima escolaridad.
En la actualidad, los instrumentos que maneja el SVES son:
1. Plantilla para el Diagnóstico Individual de Enfermedades
2. Registro Individual de Enfermedades
3. Volante de Canalización de Pacientes
4. Informe Mensual
El instrumento básico de este sistema es la Plantilla para el Diagnóstico Individual
de Enfermedades; ésta incluye padecimientos de interés epidemiológico,
causantes de tasas elevadas de morbilidad y mortalidad. Considera signos y
síntomas que pueden ser identificados con facilidad por personal no médico para
conformar, mediante la metodología del interrogatorio, diagnósticos probables de
enfermedad,
IV.4.2 Padecimientos Incluidos
El SVES no intenta identificar todas las causas de morbilidad. La identificación se
ha limitado a condiciones que son importantes por su frecuencia, su gravedad y su
costo para la comunidad.
110
La plantilla de diagnóstico considera 24 padecimientos, integrados en 11 grupos:
Infecciones intestinales parasitariasDiarrea y deshidratación
Amibiasis
Diarrea infecciosa
Parasitosis intestinal
Enfermedades respiratoriasCatarro o influenza
Neumonía
Bronquitis
Tuberculosis
Anginas
Otitis
Enfermedades del sistema nerviosoParálisis
Ataques
Agresión por animal
Enfermedades InfecciosasEnfermedad exantemática
Enfermedades por picadura demosco
Paludismo
Dengue
Enfermedades crónicasDiabetes mellitus
Presión alta
Problemas de la nutriciónDesnutrición
Intoxicación por ponzoñaPicadura de alacrán
Otras enfermedadesEnfermedades de la piel
Infecciones vaginales
Accidentes y violenciasAtención de accidentes
Problemas mal definidos
Para integrar un diagnóstico probable, se combinan algunos signos y síntomas
que forman definiciones operacionales sencillas. Será identificado el diagnóstico
probable en el paciente que presente todos los signos y síntomas considerados
necesarios para cada padecimiento, con presencia o no de los signos y síntomas
opcionales. Los signos o síntomas necesarios son las molestias que deben estar
presentes para poder integrar un diagnóstico; los opcionales, las molestias que
pueden o no estar presentes para poder integrar un diagnóstico.
111
IV.5 Formatos e instructivos de registro y notificación
IV.5.1 Plantilla para el Diagnóstico Individual de Enfermedades
Este documento es usado por el auxiliar de salud. Representa un método práctico
y útil para hacer de manera simplificada el diagnostico probable de algunas
enfermedades de importancia epidemiológica, mediante la combinación de
algunos signos y síntomas, que aparecen en su parte superior (y que no
representan el total de la sintomatología de los padecimientos incluidos, sino la
más frecuente y fácil de identificar por el auxiliar de salud). Del lado derecho
aparecen los 24 padecimientos o diagnósticos que la plantilla permite detectar.
La utilización de este instrumento permite identificar la problemática de salud de
mayor importancia local e iniciar medidas inmediatas de carácter individual y
colectivo para su prevención y control. Esta plantilla es usada en los diagnósticos
de primera vez.
Para su uso correcto, se deben seguir las siguientes instrucciones:
1. Colocar una hoja de papel por detrás de la plantilla perforada, de manera
que todos los orificios se encuentren por encima de la hoja de papel. La
hoja debe estar bien fija con un clip, para que no se deslice.
2. Pedir al paciente que mencione sus molestias. En caso de que se trate
de un menor de edad se deberá preguntar a la madre del pequeño o a un
familiar adulto.
3. Buscar en la plantilla el signo o síntoma que más se parezca a la
molestia que refiere el paciente y cruzar con una X todos los orificios que se
encuentren por debajo de la molestia referida. Ejemplo: si la madre dice que
112
el pequeño tiene diarrea o está suelto, se deberá cruzar todos los orificios
que estén por debajo de la palabra "diarrea".
4. Después de que el paciente termine de mencionar todas sus molestias y
que hayan sido registradas sobre la plantilla, se iniciará la búsqueda de
otros signos y síntomas, que el paciente presente y que no haya referido.
Se deberá preguntar solo por aquellos que se encuentren a la izquierda de
los orificios que ya fueron tachados con X, y no estén marcados. Se
empezará siempre con el primer renglón de arriba hacia abajo y de
izquierda a derecha.
Ejemplo: Si el primer orificio marcado está en el primer renglón, por debajo
de la frase "piel y labios secos / llanto sin lágrimas", se preguntará al
paciente por cada uno de los signos y síntomas que se encuentran a los
lados y no hayan sido marcados con X (diarrea, mollera hundida y vómitos
o náuseas). Si el paciente en ese momento refiere que tiene diarrea,
entonces se marcará sólo ese orificio con una X.
Al terminar de marcar el primer renglón, se continuará con el siguiente
renglón que presente algún orificio marcado, siguiendo el mismo
procedimiento.
5. A continuación, se deberá identificar el o los diagnósticos que se
formaron. Para integrar un diagnóstico es necesario que todos los orificios
de los cuadros negros del renglón estén marcados con una X; por otra
parte, los orificios de los cuadros azules son opcionales, es decir, pueden o
no estar presentes en el paciente y, por tanto, no es necesario que se
encuentren marcados para poder integrar un diagnóstico probable.
113
6. En caso de que no se integre ningún diagnóstico, se deberá considerar
como un problema mal definido.
7. Cuando se forma un diagnóstico probable remarcado en color rojo, el
auxiliar de Salud deberá canalizar inmediatamente a la unidad de salud y
así notificarlo. Los casos captados de diarrea y deshidratación,
catarro/influenza, parálisis (parálisis flácida de miembros), ataques
(meningitis), agresión por animal (rabia), enfermedades exantemáticas,
dengue y picadura de alacrán deben ser notificados inmediatamente a la
unidad de salud correspondiente.
IV.6 Análisis y Diseño del Sistema
IV.6.1 Análisis de la Vista
Si se considera que las aplicaciones para dispositivos Palm dependen
enteramente de la interacción con el usuario y dado que en el esquema de
solución propuesto, la Vista y los otros subsistemas se modelan por separado, se
plantea el siguiente problema:
IV.6.1.1 Enunciado del problema
Definir las clases que especifiquen el comportamiento de cada uno de los
diferentes elementos de la interfaz gráfica de la Palm.
IV.6.1.2 Modelo de Objetos
El modelo de objetos se integra con el diagrama de modelo de objetos y las
entradas correspondientes del diccionario de datos
IV.6.1.3 Identificación de Objetos y Clases
114
Como sugiere [ Rumbaugh , op. Cit.], del enunciado del problema (1.1) se extraen
los sujetos; en este caso: elementos(s) de la interfaz gráfica.
Este término se refiere a elementos que no se encuentran bien delimitados en
dicha frase. Sin embargo, a partir del estudio de aplicaciones desarrolladas por
terceros, es posible identificar algunos objetos de la interfaz gráfica de Palm.
En primer lugar, se puede observar que todos los programas de Palm trabajan a
base de formas, y cada forma es una colección de otros objetos. Las operaciones
básicas que se pueden aplicar a estos objetos son mostrar y ocultar.
Figura 4.3 Agenda
Así, en la pantalla principal de la Agenda que se distribuye como parte del
software preinstalado de la Palm (Figura 4.3) distinguimos algunos objetos:
La propia forma (form) en la que se presentan los datos.
Etiquetas (labels - ) , en donde se despliega la hora de cada cita.
Campos (fields- ), en los que se muestra el texto asociado a la
cita.
Botones gráficos, como el que indica si una cita es repetitiva, si tiene alarma o si
tiene una nota anexa.
115
Botones, como el de añadir una cita (Nuevo - ) o el que permite ver los
detalles de alguna cita existente.
Flechas de desplazamiento ( ), para cambiar de día de la semana, o para
desplazarse a lo largo de las citas de un día.
El botón “Nuevo” remite al usuario a otra pantalla (una nueva forma) que se
muestra en la Figura 4.4, donde aparece un nuevo objeto: la lista de las horas y
minutos en los que puede ocurrir la cita.
Figura 4.4 Agregar una cita
El botón “Detalles” ( ) también despliega una nueva pantalla. Los elementos
nuevos que se pueden observar son: checkboxes, un combo que despliegan otro
tipo de listas, y campos de texto que hacen la función de botones: Si se presiona
el campo que dice “Diariamente”, se muestra la forma de la Figura 4.5. En esta
también se puede detectar un elemento nuevo: Una caja de texto en la que
aparecen mensajes.
Figura 4.5 Detalles de la cita
116
Por último, el botón “Nota” despliega la forma de la Figura 4.6, en donde se puede
escribir texto en forma libre. Si la pantalla se llena (como en el ejemplo), se habilita
la barra de desplazamiento que aparece a la derecha de la imagen.
Figura 4.6 Nota ligada a una cita
Repitiendo el mismo proceso en las otras aplicaciones distribuidas por Palm
(Libreta de direcciones, Block de notas, Lista de tareas y calculadora), se pueden
encontrar nuevos objetos.
Por ejemplo, en la forma que sirve para añadir nuevos registros en la libreta de
direcciones (Figura 4.7) cuando se escribe en cada campo, la primera letra es
siempre mayúscula. Esto se indica con una flecha apuntando hacia arriba, cerca
de la esquina inferior derecha de la forma.
Figura 4.7 Agregar una Dirección
117
Todas las formas tienen un menú, y al menos una forma adicional asociada, en
donde se muestran datos como la leyenda de derechos reservados y el logo de
Palm, así como la versión de la aplicación (Figura 4.8)
Figura 4.8 Forma Acerca de
De todos los programas mencionados, se extrae la siguiente lista de objetos:
Forma Flecha de desplazamiento Combo
Barra de desplazamiento Menús Formas AdicionalesBotón Botón gráfico CheckboxesCampo Campo texto como botón Campo texto para desplegar
datosFlecha que indica mayúsculas Etiqueta Lista
Tabla
Además, como se señaló en el capítulo 2, en Codewarrior se cuenta con una
herramienta especial para diseñar las interfaces que se usarán en la aplicación (el
Constructor).
Cuando se trabaja con el Constructor, se puede invocar un “menú de objetos”
(Figura 4.9) de donde se arrastra el objeto deseado hasta la forma.
118
Figura 4.9 Catalogo del Constructor
El estudio de esta herramienta permite detectar nuevos objetos:
Button Graphic Button Push Button
Repeating Button Graphic Push Button Graphic Repeating ButtonCheckboxes Feedback Slider Control FieldGraffiti Shift Indicator Label ListPopup Trigger Selector Trigger Slider ControlGadget Scroll bar
De este modo, se conforma la lista completa de objetos:
Forma Flecha de desplazamiento Combo
Barra de desplazamiento Menús Formas AdicionalesBotón Botón gráfico CheckboxesCampo Campo texto como botón Campo texto para desplegar
datosFlecha que indica mayúsculas Etiqueta Lista
Tabla Button Graphic Button
Push Button Repeating Button Graphic Push Button
Graphic Repeating Button Checkboxes Feedback Slider ControlField Graffiti Shift Indicator LabelList Popup Trigger Selector TriggerSlider Control Gadget Scroll bar
119
El siguiente paso consiste en descartar clases redundantes, irrelevantes o vagas.
Para llevarlo a cabo, es necesario definir claramente lo que cada objeto
representa. Este paso implica también, iniciar otra de las actividades
recomendadas por Rumbaugh [op. cit.]: la construcción del Diccionario de datos.
Objeto Definición
Forma Contenedor visual de elementos de la interfaz gráfica.
Normalmente una forma representa una sola pantalla de la
aplicación.
Formas Adicionales Variantes de forma, pueden ser Alertas: formasdesplegables que presentan información al usuario, Formasde información del producto (Acerca de), etc.
Form Sinónimo de Forma
Menú Elemento de la interfaz de usuario que permite al usuario
ejecutar comandos seleccionándolos de una lista que se
despliega en la parte superior de la pantalla.
Botón Objeto de la interfaz gráfica usado para ejecutar comandos
frecuentes o pasar de una forma a otra, dentro de la
aplicación
Botón gráfico Botón que se representa en la pantalla mediante una imagen
asociada
Button Sinónimo de Botón
Graphic Button Sinónimo de Botón gráfico
Push Button Objeto usado junto con otros similares, formando un grupo
para permitir la selección de uno y solo uno de ellos.
Similar en su funcionamiento a los botones de selección de
estaciones de un radio.
Repeating Button Objeto que envía señales continuas mientras el usuario lo
mantiene presionado.
Graphic Push Button Objeto cuya funcionalidad es resultado de la combinación de
los botones push y gráfico
Graphic RepeatingObjeto cuya funcionalidad es resultado de la combinación de
120
Button los botones repeating y gráfico
Check box Elemento de la interfaz de usuario que despliega una caja
que puede estar seleccionada (x) o no ( ) y que tiene
asociada una cadena de texto.
Campo Elemento de la interfaz de usuario que sirve para desplegar
y editar texto
Campo texto como
botón
Campo que cumple con la misma funcionalidad que un
botón.
Campo texto para
desplegar datos
Sinónimo de Campo
Field Sinónimo de Campo
Graffiti Shift Indicator Pequeño icono, normalmente localizado en la esquina
inferior izquierda de la pantalla y que indica el estado del
mecanismo de entrada de datos (mayúsculas, puntuación,
etc.)
Flecha que indica
mayúsculas
Sinónimo de Graffiti Shift Indicator
Etiqueta Elemento de la interfaz gráfica que contiene texto estático.
Label Sinónimo de etiqueta.
Lista Elemento de la interfaz gráfica que muestra varios renglones
de datos en una sola columna y de la que el usuario puede
hacer una selección
List Sinónimo de Lista
Tabla Elemento de la interfaz gráfica formado por renglones y
columnas que pueden, a su vez, contener otros objetos y
que permite al usuario trabajar con estos.
Barra de
desplazamiento
Elemento de la interfaz gráfica que facilita el desplazamiento
sobre campos de texto y tablas, informando la posición
aproximada del cursor dentro de aquel objeto
Scroll Bar Sinónimo de barra de desplazamiento
Slider Control Elemento de la interfaz gráfica que permite mover el cursor
121
de la barra de desplazamiento. Es parte de la Barra de
desplazamiento
Flecha dedesplazamiento
Sinónimo de Slider Control
Feedback Slider
Control
Elemento de la interfaz gráfica que muestra la posición
aproximada del cursor de la barra de desplazamiento dentro
del campo o lista asociado a esta.
Combo No se puede encontrar una definición exacta para este
objeto.
Popup Trigger Elemento de la interfaz gráfica que despliega la selección
actual de una lista (normalmente oculta) y la propia lista
cuando es seleccionado
Selector Trigger Elemento de la interfaz gráfica que consiste en una caja
dentro de la que se despliega (y permite editar) texto
Gadget Elemento de la interfaz gráfica cuyas características y
comportamiento son totalmente modificables por el
programador.
No es un objeto que este bien definido.
Finalmente, los objetos con los que se empezará a realizar el modelo se reducen a
la siguiente lista:
Forma
Menú
Botón
Checkbox
Campo
Graffiti Shift Indicator
Etiqueta
Lista
Tabla
Barra de desplazamiento
122
PopupTrigger
SelectorTrigger
IV.6.1.4 Diccionario de Datos
Al finalizar esta actividad, ya han sido indicadas las primeras definiciones en el
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
123
(Left Origin), Coordenada Superior de Origen (Top Origin), Ancho, Alto,
Identificador de la Forma (Form ID), Identificador de la barra de Menú (Menú Bar
ID) y Titulo de la Forma (Form Title). La siguiente tabla muestra los atributos de
cada objeto, obtenidos del Constructor.
Propiedades Objetos
1 2 3 4 5 6 7 8 9 10 11 12
Identificador de la Forma x
Identificador de la Barra de Menú x
Identificador del Botón por defecto x
Titulo de la forma x
Nombre del Objeto x x x x x x x x x x
Identificador del Objeto x x x x x x x x x x
Coordenada de origen (Izquierda) x x x x x x x x x x x
Coordenada de origen (Superior) x x x x x x x x x x x
Ancho x x x x x x x x x x
Alto x x x x x x x x x x
Bandera que indica si el objeto se usa o no. x x x x x x x x x x
Bandera que indica si todos los eventos afectan a la forma x
Bandera que indica si se debe almacenar temporalmente la
información que quedará oculta por la forma
x
Bandera que define la forma en que se debe desplegar el texto
(Anchor Left)
x
Bandera que indica si el objeto tiene borde x
Bandera que indica si el texto del objeto se desplegara en
Negritas
x
Bandera que indica si el objeto se dibuja seleccionado la
primera vez
x
Bandera que indica si el campo es editable x
Bandera que indica si el campo esta subrayado x
Bandera que indica si el campo se desplegará en un sola línea
(independientemente de su tamaño)
x
Bandera que indica si el tamaño del campo puede cambiar x
Bandera que indica si el texto del campo se desplegará
justificado a la izquierda
x
Bandera que indica si el primer carácter del campo se escribe
en mayúscula
x
Bandera que indica si el campo tiene Barra de desplazamiento x
Bandera que indica si el campo recibirá solo caracteres
numéricos.
x
Propiedades Objetos
1 2 3 4 5 6 7 8 9 10 11 12
Nombre de la Fuente que se usará para desplegar Texto x x x x x x
Etiqueta que se dibujará en el objeto x x x x x
124
Identificador del grupo al que pertenece el objeto x
Número máximo de caracteres que se pueden escribir en el
Campo
x
Nombre de la Fuente que se usará para desplegar Texto x
Número de renglones que serán desplegados x
Lista de textos a desplegar x
Número de Filas x
Lista de anchos de columna x
Valor actual x
Valor mínimo x
Valor máximo x
Tamaño de página x
Bandera que indica si el tamaño del campo puede cambiar x x
Identificador de la lista a la que esta asociado el objeto x
Etiqueta del Menú x
Lista de elementos del Menú x
(1) Forma
(2) Botón
(3) Checkbox
(4) Campo
(5) Graffiti Shift Indicator
(6) Etiqueta
(7) Lista
(8) Tabla
(9) Barra de desplazamiento
(10) PopupTrigger
(11) SelectorTrigger
(12) Menu
Tabla 4.10 Propiedades de los objetos de la interfaz gráfica
125
IV.6.1.7 Refinamiento del modelo usando herencia
Como se puede observar, la mayoría de los objetos comparten los siguientes
atributos:
Nombre del Objeto
Identificador del Objeto
Coordenada de origen (Izquierda)
Coordenada de origen (Superior)
Ancho
Alto
Bandera que indica si el objeto se usa o no.
Esto sugiere que se puede crear una clase base, que incluya}e estos atributos, y a
partir de la cual se crean los demás.
Todo lo anterior se ha tomado en cuenta para crear la primera versión del
diagrama de clases (Figura 4.11):
Figura 4.11 Diagrama de clases de la Vista
Como se indicó, prácticamente todos las clases descienden de una clase base
(cComponenteVisual). Además, la clase cLista contiene una instancia de la clase
126
cPopupTrigger (que sirve para desplegar la lista). Las clases cCampo y cTabla
contienen ambas una instancia de la clase cBarraDeDesplazamiento.
IV.6.1.8 Modelo Dinámico
Para preparar los escenarios típicos, se ha considerado al PalmOS como un actor
(además del propio usuario) ya que es capaz de generar eventos que afectan a
una aplicación,
El caso de uso a considerar es el arranque y finalización de una aplicación; que se
puede separar en a) arranque de la aplicación, y b) finalización de la aplicación.
Figura 4.12. Caso de Uso MV1A. El PalmOS inicia una aplicación:
1. PalmOS invoca a la forma principal de la aplicación.
2. Para cada objeto, Forma dibuja el objeto n
3. Regresa al paso 2, hasta que no haya mas objetos por dibujar
Flujo alterno 1.A: Usuario presiona el botón de salir
4.1 Para cada objeto, Forma elimina el objeto n
4.2 Regresa al paso 4.1, hasta que no haya mas objetos por eliminar
4.3 Forma termina. Regresa el control a PalmOS
Termina el Caso de Uso
127
Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicación:
1. Usuario presiona el botón de salir
1.1 Para cada objeto, Forma elimina el objeto n
1.2 Regresa al paso 1.1, hasta que no hay mas objetos por eliminar
1.3 Forma termina. Regresa el control a PalmOS
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.
128
Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalización de una
aplicación.
IV.6.1.9 Modelo Funcional
En el caso de la Vista, la funcionalidad esperada de los objetos consiste en
enmascarar en métodos las funciones ofrecidas por el PalmOS SDK.
Considérese, por ejemplo, la clase cCIGcheckbox, que modela el comportamiento
de los elementos de la interfaz gráfica denominados checkboxes. La definición de
dicha clase es:
129
#i f ndef CI GCHECKBOX_H
#def i ne CI GCHECKBOX_H
#i ncl ude " cl abel edobj ect . h"
#i ncl ude " cst r i ng. h"
cl ass cI GcheckBox: publ i c cLabel edObj ect {
/ / Associ at i ons
/ / At t r i but es
pr i vat e:
Bool ean sel ect ed;
UI nt 8 gr oupI D;
/ / Oper at i ons
publ i c:
cI GcheckBox ( For mPt r f r mP, UI nt 16 obj ect I D ) ;
cI GcheckBox ( For mPt r f r mP, UI nt 16 obj ect I D, cSt r i ng l aCadena ) ;
cI GcheckBox ( For mPt r f r mP, UI nt 16 obj ect I D, char * l aCadena ) ;
voi d sel ect ( Bool ean val or ) ;
Bool ean i sSel ect ed ( ) ;
voi d set Gr oup ( UI nt 8 el Gr upo ) ;
UI nt 8 get Gr oup ( ) ;
} ;
#endi f
Como se ha señalado, la implementación de la clase, consiste en llamadas a las
funciones de la interfaz de programación de aplicaciones de Palm; por ejemplo,
para cambiar el valor de el objeto gráfico, se usa la función CtlSetValue. El método
select, que cambia el estado del objeto gráfico, llama simplemente a esa función:
130
voi d cI GcheckBox: : sel ect ( Bool ean val or ) {
sel ect ed = val or ;
Ct l Set Val ue ( ( Cont r ol Pt r ) anObj ect Pt r , val or ) ;
}
De igual modo, el método isSelected, informa si el objeto esta seleccionado o no.
Para ello, hace uso de la función CtlGetValue que devuelve el estado del objeto.
Bool ean cI GcheckBox: : i sSel ect ed ( ) {
sel ect ed = Ct l Get Val ue ( ( Cont r ol Pt r ) anObj ect Pt r ) ;
r et ur n sel ect ed;
}
Ambos métodos hacen uso del atributo selected que es de tipo boléalo, por lo que
solo pude tener dos estados: verdadero o falso.
IV.6.1.10 Iterar
Otra recomendación de Rumbaugh [Ibíd.] es iterar el proceso a fin de refinar el
diagrama. Después de varias iteraciones, se obtiene el diagrama de la Figura 4.23
que contiene prácticamente todos los elementos que se van a usar en el proyecto.
IV.6.2 Análisis del Modelo
IV.6.2.1 Enunciado del problema (EP)
Definir las clases que especifiquen el comportamiento de Plantilla para el
Diagnóstico Individual de Enfermedades.
IV.6.2.2 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):
131
Plantilla para el Diagnóstico Individual de Enfermedades
Se puede observar que se trata de un término muy general. Pero la definición de
dicho termino se encuentra al inició de este capítulo, “El instrumento básico de
este sistema es la Plantilla para el Diagnóstico Individual de Enfermedades”...
“incluye padecimientos de interés epidemiológico, causantes de tasas elevadas de
morbilidad y mortalidad. Considera signos y síntomas que pueden ser identificados
con facilidad por personal no médico...”
El uso de la plantilla esta descrito en los párrafos siguientes:
“Del lado derecho aparecen los 24 padecimientos o diagnósticos que la plantilla
permite detectar.”
“Para su uso correcto, se deben seguir las siguientes instrucciones:
...
2. Pedir al paciente que mencione sus molestias. En caso de que se trate de un
menor de edad, se deberá preguntar a la madre del pequeño o a un familiar
adulto.
3. Buscar en la plantilla el signo o síntoma que más se parezca a la molestia que
refiere el paciente y cruzar con una X todos los orificios que se encuentren por
debajo de la molestia referida.
...
4. Después de que el paciente termine de mencionar todas sus molestias y que
hayan sido registradas sobre la plantilla, se iniciará la búsqueda de otros signos y
132
síntomas, que el paciente presente y que no haya referido. Se deberá preguntar
solo por aquellos que se encuentren a los lados de los orificios que ya fueron
tachados con X, y no estén marcados. Se empezará siempre con el primer renglón
de arriba hacia abajo y de izquierda a derecha.
...
Al terminar de marcar el primer renglón, se continuará con el siguiente renglón que
presente algún orificio marcado, siguiendo el mismo procedimiento.
5. A continuación, se deberá identificar el o los diagnósticos que se formaron. Para
integrar un diagnóstico es necesario que todos los orificios de los cuadros negros
del renglón estén marcados con una X; por otra parte, los orificios de los cuadros
azules son opcionales, es decir, pueden o no estar presentes en el paciente y, por
tanto, no es necesario que se encuentren marcados para poder integrar un
diagnóstico probable.
6. En caso de que no se integre ningún diagnóstico, se deberá considerar como un
problema mal definido.
7. Cuando se forma un diagnóstico probable remarcado en color rojo, el auxiliar de
Salud deberá canalizar inmediatamente a la unidad de salud y así notificarlo.”
IV.6.2.2.2 Buscar sujetos en el EP
Una vez más, se sigue la recomendación de Rumbaugh [Ibíd.] y se localizan los
sujetos en los párrafos anteriores.
De esta búsqueda, se obtiene la siguiente lista de objetos:
Padecimientos
133
Signos
Síntomas
Diagnósticos
Molestias
Plantilla
Siguiendo el proceso aplicado en la sección IV.6.1 (Análisis de la Vista), se
procede a definir1 cada uno de los términos de la lista:
Padecimiento Cualquier causa de enfermedad.
Síntoma Manifestación de una alteración
orgánica o funcional apreciable por el
médico o por el enfermo. Característica
que permite reconocer una enfermedad,
trastorno funcional o una lesión.
Signo Cualquier evidencia de falta de salud en
el paciente.
Para efectos del sistema, sinónimo de
Síntoma
Diagnóstico Parte de la medicina que tiene por
objeto la identificación de una
enfermedad fundándose en los síntomas
de esta.
En el caso de estudio, son todos
aquellas probables enfermedades para
los que se cumple la condición de que el
paciente presente TODOS los signos y
síntomas considerados necesarios.
En el caso de estudio, Diagnóstico y
1 Definiciones obtenidas del Diccionario Terminológico de Ciencias Médicas
134
Padecimiento se manejan como
sinónimos.
Molestia Sinónimo de Signo
Plantilla Tabla bidimensional.
En el caso de estudio, se trata de una
matriz de 43 columnas (Síntomas) y 24
líneas (Padecimientos probables)
Después de descartar clases redundantes, irrelevantes y vagas, la lista se reduce
a:
Síntoma
Diagnóstico
Plantilla
IV.6.2.3 Identificar Asociaciones entre clases
Aplicando el método citado con anterioridad, se obtienen las siguientes
descripciones:
La plantilla INCLUYE padecimientos.
La plantilla CONSIDERA signos y síntomas.
El usuario MARCA (en la plantilla) la columna del síntoma referido.
Para definir la forma en que se compone la plantilla, se usa una frase más:
“Del lado derecho aparecen los 24 padecimientos o diagnósticos que la plantilla
permite detectar.”
IV.6.2.4 Identificar Atributos
Los atributos son relativamente sencillos de encontrar: Las clases que modelen el
diagnóstico y el síntoma, poseen una cadena de caracteres que se usa para
135
almacenar el nombre del dato. Por otro lado, la clase que modele a la plantilla
debe incluir objetos diagnóstico y síntoma.
Con todos estos elementos, se puede construir una primera versión del diagrama
de clases del Modelo (Figura 4.15).
Figura 4.15 Primera versión del diagrama de clases del Modelo
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
136
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 paraproponer su implementación, una vez más se debe recurrir a algunos de lospárrafos mencionados al inicio de esta sección.
De acuerdo a la información indicada, se sugiere el siguiente procedimiento
(Figura 4.18 Algoritmo para obtener un diagnóstico):
1. Pr egunt ar al paci ent e que mol est i as t i ene. 1. 1 Par a cada mol est i a:1. Local i zar l a mol est i a en l as l i s t as de mol est i as, a par t i r de su
137
i ni ci al 1. 1. 2 Señal ar en l a caj a cor r espondi ent e, l a mol est i a r ef er i da2. Al macenar en ar r egl oSi nt omas, l a c l ave del s í nt oma, l a bander a
“ pr esent e” 1. 1. 4 Si no hay mas mol est i as, i r al paso 2 1. 1. 5 Vol ver a 1. 1. 12. Par a cada el ement o de ar r egl oSi nt omas: 2. 1 Al macenar el numer o de sí nt oma en l a var i abl e c l aveSi nt oma 2. 2 Recor r er l a mat r i z pl ant i l l aDi agnost i co 2. 2. 1 En el n- si mo r engl ón 2. 2. 1. 1 Si l a col umna con númer o cl aveSi nt oma t i ene al macenado un val or mayor que 0. ( El s í nt oma est a pr esent e en el padeci mi ent o) 2. 1. 1. 1. 1 Recor r er el r engl ón. Si l a col umna t i ene al macenado un 1 2. 1. 1. 1. 1. 1 Al macenar en ar r egl oSi nt omas l a c l ave del s í nt oma, bander a “ desconoci do” 2. 3 Al macenar en bander a el val or “ agot ado”3. Par a cada el ement o de ar r egl oSi nt omas: 3. 1 Si l a bander a es “ desconoci do” 3. 1. 1 Most r ar l a pant al l a que cor r esponde al Sí nt oma 3. 1. 2 Al macenar l a r espuest a ( en bander a) como “ pr esent e” o “ ausent e” , según l a r espuest a del paci ent e4. Recor r er l a mat r i z pl ant i l l aDi agnost i co
4. 1 En el n- s i mo r engl ón
4. 1. 1 Recor r er el r engl ón. Si l a col umna t i ene al macenado un numer o mayor
que 0
4. 1. 1. 1 Local i zar el Sí nt oma cuya c l ave cor r esponda al numer o de col umna
de pl ant i l l aDi agnost i co
4. 1. 1. 2 Si l a bander a del s í nt oma es “ ausent e” y en pl ant i l l aDi agnost i co
el val or es 1 ( obl i gat or i o) , ent onces el padeci mi ent o no exi st e.
Regr esa a 4. 1
4. 2. 1 Si se l l egó al f i n del r engl ón, el padeci mi ent o si exi st e. Al macenar
en ar r egl oPadeci mi ent os
4. 2. 2 Regr esa a 4. 1
5. Despl egar pant al l a r esul t ados.
6. Par a cada el ement o en ar r egl oPadeci mi ent os. Despl egar el nombr e del
padeci mi ent o.
Figura 4.18 Algoritmo para obtener un diagnóstico
IV.6.2.7 Iterar el proceso
Los objetos cDiagnostico y cSintoma son prácticamente iguales, por lo que parecemejor crear una clase cDescripcion, a partir de la que se forman los vectoresrespectivos de la clase cPlantillaDiagnostico.
Sin embargo, almacenar un nuevo síntoma no es tan trivial como simplemente
añadirlo a un vector.
138
Se requiere de una clase cArregloSintomas, cuyo método almacenarSintoma, se
describe a continuación:
1. Recor r er ar r egl oSi nt omas, buscando l a c l ave del s í nt oma
2. Si no exi st e, l a al macena y r egr esa l a posi ci ón en que quedo al macenada
3. Si ex i s t e y l a bander a t i ene el val or de agot ado, r egr esa ( 0)
4. Si ex i s t e y l a bander a t i ene el val or de pr esent e, r egr esa ( - 1)
Después de esta iteración, se obtiene un nuevo diagrama de clases (Figura 4.19):
Figura 4.19 Diagrama de Clases del Modelo.
IV.7 Análisis del Controlador
Antes de modelar el Controlador se debe tomar en cuenta una restricción
importante: Hasta la versión 7.0 de Codewarrior, no es posible usar objetos en la
rutina principal. Esto se debe a que Codewarrior crea un esqueleto de funciones
que se completan con el código necesario para la aplicación (Figura 4.20).
139
No hay disponible, hasta esta versión de Codewarrior, un mecanismo similar
orientado a objetos. Pero, como se mencionó en el Capítulo 1, es posible modelar
objetos con C a través del uso de estructuras.
Así, se puede pensar en la estructura de funciones ofrecidas por Codewarrior
como una clase cControlador genérico, donde cada una de estas funciones es un
método.
Enseguida se listan todas estas funciones:
st at i c Er r RomVer si onCompat i bl e( UI nt 32 r equi r edVer si on, UI nt 16 l aunchFl ags)
Esta función verifica que la versión del ROM cumpla los requisitos mínimos de laaplicación.
st at i c voi d * Get Obj ect Pt r ( UI nt 16 obj ect I D)
El objetivo de esta función es regresar el apuntador a un objeto de la forma enuso.
st at i c Bool ean Mai nFor mDoCommand( UI nt 16 command)
Esta función ejecuta el comando de menú especificado.
st at i c Bool ean AppHandl eEvent ( Event Pt r event P)
Esta función carga los recursos y establece cual será la rutina encargada demanejar los eventos de la forma que se esta poniendo en uso en un momentodado.
st at i c voi d AppEvent Loop( voi d)
En esta función se implementa el ciclo de eventos de toda la aplicación.
st at i c Er r AppSt ar t ( voi d)
Las preferencias de la aplicación actual se establecen en esta función.
st at i c voi d AppSt op( voi d)
En esta función se guarda el estado actual de la aplicación, para recuperarlocuando la aplicación reinicie.
st at i c UI nt 32 St ar t er Pal mMai n( UI nt 16 cmd, MemPt r / * cmdPBP* / , UI nt 16 l aunchFl ags)
Esta función constituye el punto de entrada principal de la aplicación.
UI nt 32 Pi l ot Mai n( UI nt 16 cmd, MemPt r cmdPBP, UI nt 16 l aunchFl ags)
Esta función es invocada por el PalmOS para arrancar la aplicación. A su vez,llama a StarterPalmMain.
140
st at i c voi d Mai nFor mI ni t ( For mPt r / * f r mP* / )
Esta función inicializa la forma MainForm
st at i c Bool ean Mai nFor mHandl eEvent ( Event Pt r event P)
Esta rutina implementa el manejador de eventos de la forma MainForm
Figura 4.20 Funciones creadas por Codewarrior.
Como se puede observar, hay funciones que reciben como parámetro un
apuntador a una forma, simulando encapsulamiento según el mecanismo descrito
en el Capítulo 1.
En el capítulo 2 se señaló que es necesario que exista una versión de las
funciones FormInit y FormHandleEvent por cada forma del sistema.
Todo esto hace que Modelar el Controlador sea en realidad, la actividad mas
sencilla de la etapa de análisis, sin perder de vista que una parte de la
implementación esta hecha, definida por Codewarrior, y no se puede cambiar.
IV.7.1 Enunciado del problema (EP)
Definir la(s) clase(s) que especifiquen el comportamiento de una aplicación Palm.
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).
141
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)
142
Flujo alterno MC01B. Usuario termina la aplicación.
Ocurre el Caso de Uso MV1B. Usuario o el PalmOS finalizan laaplicació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.
Figura 4.23 Diagrama de clases de la Vista.
CONCLUSIONES
145
La pregunta central planteada al inicio del presente trabajo fue si es posible aplicar
una metodología de Análisis y Diseño de Sistemas que considere las limitaciones
de una plataforma como las PDAs para desarrollar aplicaciones de Cómputo
Móvil.
La solución propuesta consiste en aplicar una versión acotada de la técnica de
modelado de objetos (OMT) de Rumbaugh sobre el patrón de Modelo Vista
Controlador, todo ello adaptado a las restricciones propias de los Asistentes
Personales Digitalizados, que comprenden desde el hardware limitado hasta el
hecho de que el modelado del sistema de soporte (conformado por la interfaz
gráfica de la Palm -la Vista- y el Controlador) se realiza una sola vez, y se puede
utilizar en cualquier proyecto posterior.
A continuación se enlistan las conclusiones a las que se ha podido llegar a lo largo
del desarrollo del presente proyecto y se plantea el trabajo futuro que se puede
desarrollar a partir de las bases establecidas hasta este momento.
Los principales productos resultantes de este trabajo, son una metodología de
análisis y diseño de sistemas enfocada al desarrollo de aplicaciones para PDAs, y
en forma más específica, una librería de clases que controla los elementos de la
interfaz gráfica de los dispositivos basados en el PalmOS.
Sobre la Metodología, se ha desarrollado el modelo de la Vista, el principio de lo
que puede llegar a ser un Controlador genérico, y se han sugerido ideas que
faciliten el desarrollo de Modelos de aplicación.
146
Aplicar la metodología resultó útil porque facilitó enormemente el proceso de
desarrollo de una aplicación Palm, permitiendo separar la implementación del
modelo de la interfaz gráfica, de la del dominio del problema. Además de otras
ventajas que saltan a la vista: se puede reutilizar todo el diseño (y el código) de la
vista, y una buena parte del controlador.
El patrón de diseño Modelo Vista Controlador resultó también una buena elección,
por que las aplicaciones en Palm se implementan en forma muy aproximada al
mismo, ya que dependen completamente de la interacción con el usuario. Como
se pudo observar, el desarrollo de las aplicaciones para Palm inicia con el diseño
del componente visual (la vista) de las mismas, y basandose en los resultados
obtenidos, es factible pensar que diferentes dominios de aplicación se pueden
acoplar de forma relativamente sencilla diseñando nuevos modelos.
La integración entre el modelo y la interfaz fue una tarea relativamente sencilla,
encapsulando las funciones propias del PalmOS en una clase cControlador. Esto
hace pensar que, como un trabajo futuro, sea posible generalizar esta clase, e
integrarla en una librería de controladores.
La separación del dominio del problema de las dificultades de implementación de
la interfaz de usuario resulta ser una gran ventaja: se puede reutilizar completo el
diseño de la interfaz gráfica, prácticamente en cualquier nuevo proyecto Palm. La
librería de clases de la interfaz Gráfica de Palm obtenida también como producto
de este proyecto resulta ser muy importante, ya que facilita enormemente la
manipulación de los objetos de la vista.
De hecho, esta librería se esta usando ya en otros dominios de aplicación. Debido
a contratos comerciales preexistentes no es posible dar detalles muy específicos,
pero se han desarrollado productos totalmente operacionales en este momento
para la rama de Seguros.
147
Esto demuestra las bondades de seguir una metodología de objetos. Pasar de un
área de conocimiento como la Medicina a otra totalmente diferente, de tipo
económico, no afecta en ningún modo a modelo de la Vista. El desarrollador de
aplicaciones Palm simplemente debe crear instancias nuevas, enfocadas al nuevo
dominio de aplicación.
Existen potenciales áreas de aplicación de tipo comercial en donde se pueden
utilizar tanto la librería de clases como la metodología ya comentada. Aplicaciones
para evaluar la aprobación de créditos, o selección de planes de seguros de vida
son candidatas ideales para este esquema.
Surge entonces el cuestionamiento de cuán eficiente es usar el nuevo esquema
de trabajo (la metodología), contra el método tradicional de trabajo, muy parecido
a un esquema de prototipado evolutivo:
a) Obtener el requerimiento del usuario
b) Diseñar la(s) pantalla(s) requeridas
c) Codificar la funcionalidad necesaria
d) Entregar una versión preliminar el producto
a. Regresar al inciso a)
No se puede medir la eficiencia usando como parámetro el tiempo que tarda la
aplicación en ejecutarse totalmente, por que el desempeño de la aplicación se ve
afectado por la presencia (o ausencia) de otros programas: programas que sirven
para acelerar el reloj interno de la Palm (overclocking), por ejemplo.
Otro factor que puede influir en la forma en que una aplicación se ejecuta, es la
cantidad de memoria libre con la que cuente el dispositivo; mientras mas memoria
148
libre exista, las operaciones de administración del PalmOS se realizan mas
fácilmente, y las aplicaciones se ejecutan más rápido.
Por tanto, se ha optado por utilizar otras métricas, como el número de líneas de
código, el porcentaje de instrucciones del lenguaje contra el total del código, etc.
Aprovechando el hecho de que existe una versión del SVES que fue desarrollada
sin usar una metodología específica, se aplico a ambas versiones el programa
c_count (http://invisible-island.net/c_count/) obteniéndose, entre otros, los
siguientes resultados:
SVES Evolutivo SVES MVC
138 14? | Cabecer as. c
638 274? | Canal i zaci on. c
441 158? | Di agnost i co. c
2210 856? | For mas. c
106 35? | I dPal m. c
1130 519? | MenuSi nt omaI ni c i al . c
40 29? | Pr ot ot i pos. h
355 149? | Regr eso. c
246 44? | Segui mi ent o. c
585 222? | St ar t er . c
- - - - - - - - - - - - - - - -
5889 2300? t ot al l i nes/ st at ement s
884 l i nes had comment s 15. 0 %
392 comment s ar e i nl i ne - 6. 7 %
1020 l i nes wer e bl ank 17. 3 %
21 l i nes f or pr epr ocessor 0. 4 %
4356 l i nes cont ai ni ng code 74. 0 %
5889 t ot al l i nes 100. 0 %
20479 comment - char s 12. 6 %
16651 nont ext - comment - char s 10. 3 %
37461 whi t espace- char s 23. 1 %
495 pr epr ocessor - char s 0. 3 %
87298 st at ement - char s 53. 8 %
162384 t ot al char act er s 100. 0 %
351 136? | cDat aBase. cpp
41 24 | cDat aBase. h
40 12 | cet i quet a. cpp
24 10 | cet i quet a. h
51 13 | c i gbot on. cpp
31 15 | c i gbot on. h
36 9 | c i gcheckbox. cpp
25 11 | c i gcheckbox. h
298 65 | c i gf i el d. cpp
78 48 | c i gf i el d. h
11 0 | c i gl abel . cpp
60 19 | c i gl abel edobj ect . cpp
30 14 | c i gl abel edobj ect . h
18 5 | c i gl abel . h
147 39 | c i gl i s t . cpp
50 26 | c i gl i s t . h
63 20 | c i gscr ol l bar . cpp
28 14 | c i gscr ol l bar . h
79 28 | cobj et omi ni mo. cpp
35 18 | cobj et omi ni mo. h
82 30 | cont r ol obj ect . cpp
33 19 | cont r ol obj ect . h
62 16 | cr ect angl et ype. cpp
30 15 | cr ect angl et ype. h
491 103 | cst r i ng. cpp
138 46 | cst r i ng. h
18 4 | cusabl eobj ect . cpp
149
7952 t okens, aver age l engt h 8. 66
0. 23 r at i o of comment : code
756 ?: i l l egal char act er s f ound
21 6 | cusabl eobj ect . h
215 63 | pr ecor d. cpp
67 39 | pr ecor d. h
655 121? | s t ar t er . cpp
- - - - - - - - - - - - - - - -
3308 988? t ot al l i nes/ st at ement s
743 l i nes had comment s 22. 5 %
241 comment s ar e i nl i ne - 7. 3 %
671 l i nes wer e bl ank 20. 3 %
129 l i nes f or pr epr ocessor 3. 9 %
2006 l i nes cont ai ni ng code 60. 6 %
3308 t ot al l i nes 100. 0 %
11138 comment - char s 14. 4 %
8726 nont ext - comment - char s 11. 3 %
17599 whi t espace- char s 22. 7 %
2482 pr epr ocessor - char s 3. 2 %
37544 st at ement - char s 48. 5 %
77489 t ot al char act er s 100. 0 %
4848 t okens, aver age l engt h 6. 84
0. 28 r at i o of comment : code
4 ?: i l l egal char act er s f ound
Tabla C1. Comparación de código entre versiones del SVES.
Como puede observarse el código generado usando objetos es aproximadamente
40% menos que el obtenido usando programación tradicional.
Pero esta no es la única ventaja. Considérese, por ejemplo, la necesidad de
añadir un nuevo padecimiento al autómata que da soporte al producto.
Con la metodología evolutiva, sería necesario modificar prácticamente todos los
programas mostrados (10), mientras que usando el Patrón Modelo Vista
Controlador, solo sería necesario modificar la clase cModelo, codificada en dos
archivos (cModelo.cpp y cModelo.h) que no son parte de la Vista, sino del Modelo.
150
Otras ventajas del esquema propuesto tienen que ver con la facilidad de
adaptación a cambios. Permitir que las aplicaciones desplieguen video, por
ejemplo, requiere solamente añadir la clase correspondiente a la Vista.
Nuevamente, este hecho implica que un cambio mayor, como podría ser migrar de
plataforma (generar una versión de la aplicación para una plataforma que no
maneje el PalmOS como su sistema operativo), requiere recodificar solo las clases
de la Vista y algunas partes del controlador, sin tener que tocar ninguna clase del
Modelo.
Trabajo futuro.
Se dejan planteadas muchas áreas por explorar, por ejemplo:
Se puede añadir persistencia a las clases, de forma que guarden su estado una
vez que se apaga el dispositivo. Esta propuesta se puede extender hasta el hacer
que el algoritmo tuviera la capacidad de aprender: si un conjunto de síntomas dan
como resultado un problema mal definido, los datos almacenados se pueden
mostrar a un Médico que indique el nombre del padecimiento y retroalimente el
sistema.
El Modelo se puede generalizar para que se le pueda aplicar a otros problemas
que usen autómatas (muy fácilmente se puede extender a otros problemas de
toma de decisiones).
También se podría hacer configurable si el autómata se pudiera leer de una tabla
en lugar de estar codificado en la clase correspondiente. Separando la matriz de
151
conocimiento del experto se podría crear una aplicación administradora de
modelos.
Finalmente, añadiendo un nuevo elemento al Patrón se puede facilitar la conexión
con otro tipo de dispositivos (de comunicación, bases de datos, etc.)
El nuevo Patrón sería algo parecido al que se muestra en la Figura C2.
Figura C2. Patrón Modelo Vista Controlador Adaptador
BIBLIOGRAFÍA
153
RUMBAUGH, James, et. al. MODELADO Y DISEÑO ORIENTADO A OBJETOS.
Metodología OMT. México: Prentice Hall, 1996.
FORESTER, Lonon R. PALMOS PROGRAMMING BIBLE. Nueva York: Hungry
Minds, 2000.
TUCKER, Allen B. LENGUAJES DE PROGRAMACIÓN. 2ª. edición. México:
McGraw-Hill, 1988.
KELLEY, Dean. TEORÍA DE AUTÓMATAS Y LENGUAJES FORMALES.
España: Prentice Hall, 1995.
TANENBAUM, Andew S. REDES DE COMPUTADORAS. Prentice Hall, 3ª.
Edición 1997
WIDLE, Erick. WILDE'S W.W.W. Berlin: Ed. Springer, 1999
COPLIEN, James et. al. PATTERN LANGUAGES OF PROGRAM DESIGN.
Addison-Wesley 1995.
BROOKSHEAR, J. Glenn. INTRODUCCIÓN A LAS CIENCIAS DE LA
COMPUTACIÓN. 4ª edición. México: Addison Wesley Iberoamericana, 1995.
JOYANES AGUILAR, Luis. METODOLOGÍA DE LA PROGRAMACIÓN. México:
Mc Graw Hill, 1988
KENDALL, Kenneth. et. al. ANÁLISIS Y DISEÑO DE SISTEMAS. México:
Prentice Hall Hispanoamericana, 1991.
GAIL CHRISTIE, Linda, et. al. ENCICLOPEDIA DE TÉRMINOS DE
MICROCOMPUTACIÓN. México: Prentice Hall, 1985.
154
DICCIONARIO DE INFORMÁTICA. 2ª edición. México: Diaz de Santos, 2000.
PARKER, Charles S. INTRODUCCIÓN A LA INFORMÁTICA. México: Editorial
Interamericana, 1987.
YOURDON, Eduard. ANÁLISIS ESTRUCTURADO MODERNO. México: Prentice
Hall, 1993.
YOUNG, A. Douglas. NETSCAPE DEVELOPER’S GUIDE TO PLUG-INS.
Prentice Hall, 1992.
PRESSMAN, Roger S. INGENIERIA DE SOFTWARE. UN ENFOQUE
PRACTICO. 4ª. Ed. Madrid: Mc Graw Hill Interamericana, 1998
BREEDLOVE Rob, et al. WEB PROGRAMMING UNLEASHED. 1a. Ed. Sams
Publishing, 1996
CARDENAL, L. DICCIONARIO TERMINOLÓGICO DE CIENCIAS MÉDICAS. 7ª
edición. México: Salvat Editores, 1960.
ALVAREZ LUCAS, et. al. MANUAL PARA LA VIGILANCIA EPIDEMIOLÓGICA
SIMPLIFICADA. Epidemiología, No. 24. Secretaría de Salud.
CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (I)”. En: SOLO
PROGRAMADORES. Madrid, España. (82 - 09 – 2001). 7-10.
CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (II)”. En: SOLO
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.
155
ÉRDI Gergõ. GUIKACHU. feshmeat.net, 02/03/2001
http://cactus.rulez.org/projects/guikachu/
D. JEFF Dionne. PRC-TOLLS. sourceforge.net, 20/08/2002
http://PRC-Tools.sourceforge.net/
STRUNK Darren. PATTERNS IN OBJECT-ORIENTED DEVELOPMENT.
Universidad de Texas. 12/05/1999
http://www.cs.utexas.edu/users/almstrum/cs370/strunk/part3.htm
SADOSKI, Darleen. CLIENT/SERVER SOFTWARE ARCHITECTURES, AN
OVERVIEW. Software Engineering Institute. Carnegie Mellon University. 1997
http.// w w w.sei.cmu.edu/activities/str/descriptions/clientserver.html
ARDIRI, Aaron. PILRC v2.9. www.ardiri.com.Enero, 2003
http://www.ardiri.com
webopaedia. ONLINE DICTIONARY FOR COMPUTER AND INTERNET TERMS.
Enero, 2003
http://www.pcwebopaedia.com/
LANDSBERG, Joe. PROBLEM SOLVING AND DECISION MAKING. University of
St. Thomas. 04/09/2002
http://www.iss.stthomas.edu/studyguides/problem/problemsolvingV.htm
DENNIS, Payne. XWPE-ALPHA PROJECT. Identicalsoftware, 15/10/2002
http://www.identicalsoftware.com/xwpe/
KH. NABA, Kumar Singh. ANJUNTA [DEV STUDIO]. sourceforge.net, 15/10/2002
http://anjuta.sourceforge.net/
156
KORGAONKAR, Sachin. DESIGN PATTERNS. 04/09/2002.
http://www.developersdiary.com/patterns.asp
APPLETON, Brad. PATTERNS AND SOFTWARE: ESSENTIAL CONCEPTS
AND TERMINOLOGY. 02/14/2000
http://www.enteract.com/%7Ebradapp/docs/patterns-intro.html
APPLETON, Brad. PATTERNS IN A NUTSHELL. THE “ BARE ESSENTIALS” OF
SOFTWARE PATTERNS. 02/14/2000
http://www.enteract.com/%7Ebradapp/docs/patterns-nutshell.html
FRYE, Jason. PATTERNS HOME PAGE. The Refactory, Inc., The Hillside Group.
Junio, 2002
http://hillside.net/patterns/
TIDWELL, Jenifer. UI PATTERNS AND TECHNIQUES. MIT. Mayo, 2002
http://time-tripper.com/uipatterns/index.html
STRUNK, Darren. PATTERNS IN OBJECT-ORIENTED DEVELOPMENT.
Universidad de Texas. 12/05/1999
http://www.cs.utexas.edu/users/almstrum/cs370/strunk/part3.htm
BARAY, Cristobal. THE MODEL-VIEW-CONTROLLER (MVC) DESIGN
PATTERN. Universidad de Indiana, Enero, 2003.
http://www.cs.indiana.edu/~cbaray/projects/mvc5.html
MODEL VIEW CONTROLLER. OBJECT ARTS. PURE OBJECT ORIENTED
SOFTWARE. Enero, 2003.
http://www.object-arts.com/EducationCentre/Overviews/MVC.htm
157
WHEELER, Sarah. THE MODEL-VIEW-CONTROLLER ARCHITECTURE. CERN.
Organización Eruopea para la Invetigación Nuclear, 30/08/1996.
http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
MODEL-VIEW-CONTROLLER PATTERN. eNode, Inc, 2002.
http://www.enode.com/x/markup/tutorial/mvc.html
MODEL-VIEW-CONTROLLER. java.sun.com. Enero, 2003.
http://java.sun.com/blueprints/patterns/MVC.html
BAKKER, Gerbrand, et. al. OMT OBJECT MODEL. Université Paris, 09/02/1996.
http://panoramix.univ-paris1.fr/CRINFO/dmrg/MEE/misop007/index.html
FEDERHOFER, Judith. MEDICAL EXPERT SYSTEMS. Enero, 2003
http://www.computer.privateweb.at/judith/historical3.htm
DARLINGTON, Keith MSc, MBCS. BASIC EXPERT SYSTEMS. BRITISH
COMPUTER SOCIETY NURSING SPECIALIST GROUP, Junio, 1996.
http://www.bcsnsg.org.uk/itin08/darling.htm
ROSENTHAL Helen T. , MD et. al. ONLINE MEDICAL DIAGNOSIS. The National
Medical Society, Diciembre, 2002.
http://www.medical-library.org/mddx_index.htm
MEDLINEplus. INFORMACIÓN DE SALUD. Biblioteca Nacianal de Medicina de
EU, 14/02/2003.
http://www.nlm.nih.gov/medlineplus/spanish/tutorial.html
CHANG, Shi-Kuo. MEDICAL DIAGNOSIS SUPPORT SYSTEM MAIN FORM.
University of Pittsburgh, Pittsburgh, PA 15260 USA, Diciembre 2002.
http://www.cs.pitt.edu/~jung/AMIS2/
158
LIBRARY OF THE NATIONAL MEDICAL SOCIETY. The National Medical
Society, Diciembre, 2002.
http://www.medical-library.org/index.htm
EasyDiagnosis. MatheMEDics. Expert online health software, Enero 2003.
http://easydiagnosis.com/
KAPPEN, H.J. Dr. A DECISION SUPPORT SYSTEM FOR MEDICAL DIAGNOSIS
USING A LARGE PROBABILISTIC NETWORK. Katholieke Universiteit Nijmegen
Medische Fysica en Biofysica, 18/10/2000.
http://www.stw.nl/projecten/N/nnn5322.html
Aetna IntelHealth. Hardvard Medical School's, 15/02/2003.
http://www.intelihealth.com
159
ANEXOS
160
A.1 Plantilla del SVES
Como se mencionó, la información sobre el Sistema de Vigilancia Epidemiológica
Simplificada (SVES) utilizada en el presente trabajo se obtuvo del documento
llamado Manual para la vigilancia epidemiológica simplificada.
Según menciona el sitio web de la Secretaría de Salud este documento puede ser
consultado en su Centro de Documentación Institucional, localizado en la Calle de
Lieja No. 7 Primer Piso, Col. Juárez. Del. Cuauhtémoc. Tel. 5553-7184
El personal de atención a usuarios de ese centro proporcionó la ubicación del
documento:
Au: Alvarez Lucas, Carlos; Ferreira Guerrero, Elizabeth; Et al. Au: México.
Secretaría de Salud. Dirección General de Epidemiología.
Ti: Manual para la vigilancia epidemiológica simplificada/Manual for simplified
epidemiologic surveillance.
Fu: México, D.F; México. Secretaría de Salud; s.f. <42>p.
Re: Este manual tiene como propósito el de servir de apoyo al médico responsable
del sistema de vigilancia epidemiológica en el ejercicio de sus funciones en lo
concerniente al registro y notificación de los problemas de salud que afecten a su
comunidad, para referir a los diferentes centros de salud a las personas que
requieran de atención médica. Contenido: Introducción. 1)Antecedentes. 2)Marco
teórico: factores condicionantes; sistemas de vigilancia epidemiológica,
información convencional y no convencional; aspectos epidemiológicos.
3)Justificación. 4)Objetivos. 5)Límites. 6)Sistema de vigilancia epidemiológica
simplificada: padecimientos incluidos, componentes, organización estructural,
161
asignación de responsables y funciones, flujo de información, bases legales y
normativas. 7) Capacitación, supervisión y evaluación. Anexos.
Ub: MX10.1/6097.
De dicho documento se obtuvo la copia de la Plantilla para el Diagnóstico
Individual de Enfermedades que se muestra en la siguiente página.
162
163
A.2 Contenido del CDROM
El CD que acompaña este documento contiene, entre otras cosas:
• Copias de este documento, en versiones electrónicas (formatos PDF y PS).
• Código fuente del sistema desarrollado.
• Artículo sobre desarrollo de aplicaciones para Palm con Software de códigoabierto aparecido en el boletín InterFAR Año 1, Número 5.
• Ponencia sobre el mismo tema, presentada en el Congreso Nacional deSoftware Libre, edición 2003.
• Descripción del Formato Coff.
• Descripción de los elementos gráficos de OMT.
• Software opensource para desarrollo de aplicaciones para Palm, versionespara Windows y Linux.
El contenido detallado se encuentra listado en el archivo CONTENIDO.TXT, en el
directorio raíz del mismo CD.