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
173
Embed
Desarrollo de Aplicaciones para Dispositivos Móviles. Tesis de Ivan Carlos Rivera Gonzalez
Desarrollo de Aplicaciones para Dispositivos Móviles. Tesis de Iván Carlos Rivera González para obtener el Titulo de Ingeniero en Computación, en la Fundación Arturo Rosenblueth.
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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.
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.������������ ����������������������������
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:
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 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ª.