Professional Documents
Culture Documents
TESIS
INGENIERO EN COMPUTACIÓN
PRESENTA:
INTRODUCCIÓN..................................................................................................... 1
CAPITULO I DESARROLLO DE SISTEMAS .......................................................... 4
I.1 Conceptos del Software .................................................................................. 5
I.2 Lenguajes de Programación ........................................................................... 6
I.2.1 Qué es un lenguaje de programación ................................................... 6
I.2.2 Evolución de los Lenguajes de Programación ...................................... 9
I.2.3 Clasificación de los Lenguajes de Programación................................ 12
I.2.4 El proceso de la programación............................................................ 14
I.3 Tipos de Sistemas de Cómputo .................................................................... 15
I.3.1 Aplicaciones Monolíticas ..................................................................... 16
I.3.2 Modelo Cliente / Servidor .................................................................... 16
I.3.3 Sistemas Distribuidos.......................................................................... 21
I.3.4 Cómputo Móvil .................................................................................... 22
I.3.5 Comentarios Finales ........................................................................... 25
CAPITULO II DESARROLLO DE APLICACIONES PARA ASISTENTES
PERSONALES DIGITALIZADOS .......................................................................... 26
II.1 Introducción a las PDAs ............................................................................... 27
II.2 Arquitectura de Hardware de la plataforma Palm......................................... 28
II.3 Arquitectura del Sistema Operativo Palm..................................................... 32
II.4 Tipos de aplicaciones................................................................................... 35
II.4.1 Aplicaciones Web reducidas .............................................................. 35
II.4.2 Aplicaciones estándar de Palm .......................................................... 37
II.4.3 Conduits ............................................................................................. 38
II.5 Estructura de una aplicación Palm. .............................................................. 39
II.5.1 Como se genera un ejecutable .......................................................... 41
II.5.2 Common Object File Format .............................................................. 43
II.5.2.1 Archivo Objeto ...................................................................... 43
II.5.2.2 COFF.................................................................................... 44
II.5.2.3 COFF y Palm ........................................................................ 46
II
II.5.2.4 PRC-Tools ............................................................................ 46
II.5.2.5 CodeWarrior ......................................................................... 48
II.5.2.6 Otros..................................................................................... 48
II.6 Integración de un ambiente de desarrollo Palm ........................................... 49
II.6.1 Herramientas de desarrollo disponibles................................................. 49
II.6.1.1 Herramientas Orientadas a formularios .......................................... 50
II.6.1.2 Herramientas Orientadas a la programación tradicional ................. 52
II.6.2 El PalmOs Emulator (POSE) ................................................................. 54
II.7 Características del API de Palm................................................................... 56
II.7.1 APIs Definidas por el usuario ............................................................. 59
II.7.2 El ambiente de desarrollo para este trabajo....................................... 60
II.7.3 CodeWarrior....................................................................................... 60
II.7.4 Eligiendo entre C y C++ ..................................................................... 61
CAPITULO III OMT PARA EL ANÁLISIS Y DISEÑO DE APLICACIONES EN
ASISTENTES PERSONALES DIGITALIZADOS ................................................... 66
III.1 Elementos de OMT ..................................................................................... 67
III.1.1 Modelo de Objetos ............................................................................ 67
III.1.2 Modelo Dinámico .............................................................................. 68
III.1.3 Modelo Funcional.............................................................................. 68
III.1.4 Relación entre los Modelos ............................................................... 69
III.2 Proceso de Análisis y Diseño en OMT ........................................................ 70
III.2.1 Análisis.............................................................................................. 71
III.2.1.1 Casos de Uso ............................................................................. 74
III.2.2 Diseño ............................................................................................... 75
III.2.2.1 Diseño de sistemas. ................................................................... 75
III.2.2.2 Diseño de objetos. ...................................................................... 77
III.3 Patrones de Diseño..................................................................................... 79
III.3.1 Qué son los patrones ........................................................................ 79
III.3.1.1 Ventajas de los patrones de diseño............................................ 81
III.3.2 Patrón Modelo Vista Controlador ...................................................... 82
III.3.2.1 Modelo Vista Controlador y desarrollo para Palm....................... 87
III
III.4 Restricciones dadas por la plataforma ........................................................ 87
III.4.1 Los distintos modelos de Palm.......................................................... 89
III.4.2 Características generales de las computadoras de mano,
independientemente de la marca. ............................................................... 90
III.4.3 Comentarios Finales ......................................................................... 90
CAPITULO IV CASO DE ESTUDIO: SVES ........................................................... 95
IV.1 Sistemas de Apoyo en la toma de decisiones ........................................... 96
IV.1.1 Proceso general de toma de decisiones ........................................... 97
IV.1.2 Sistemas de diagnóstico médico. ..................................................... 98
IV.1.2.1 Perspectiva Histórica.................................................................. 99
IV.1.2.2 Sistemas Expertos ................................................................... 100
IV.1.2.3 Funcionamiento de los sistemas de diagnóstico medico.......... 101
IV.1.2.4 Ejemplo .................................................................................... 101
IV.2 Antecedentes del Sistema de Vigilancia Epidemiológica.......................... 102
IV.3 Sistema de vigilancia epidemiológica ....................................................... 105
IV.3.1 Sistemas no convencionales de Información.................................. 106
IV.3.2 Aspectos epidemiológicos .............................................................. 107
IV.4 Sistema de Vigilancia Epidemiológica Simplificada .................................. 107
IV.4.1 Componentes del SVES ................................................................. 108
IV.4.2 Padecimientos Incluidos ................................................................. 109
IV.5 Formatos e instructivos de registro y notificación ..................................... 111
IV.5.1 Plantilla para el Diagnóstico Individual de Enfermedades .............. 111
IV.6 Análisis y Diseño del Sistema ................................................................... 113
IV.6.1 Análisis de la Vista.......................................................................... 113
IV.6.1.1 Enunciado del problema........................................................... 113
IV.6.1.2 Modelo de Objetos ................................................................... 113
IV.6.1.3 Identificación de Objetos y Clases ........................................... 113
IV.6.1.4 Diccionario de Datos ................................................................ 122
IV.6.1.5 Identificar Asociaciones entre clases ....................................... 122
IV.6.1.6 Identificar Atributos................................................................... 122
IV.6.1.7 Refinamiento del modelo usando herencia .............................. 125
IV
IV.6.1.8 Modelo Dinámico...................................................................... 126
IV.6.1.9 Modelo Funcional ..................................................................... 128
IV.6.1.10 Iterar....................................................................................... 130
IV.6.2 Análisis del Modelo ......................................................................... 130
IV.6.2.1 Enunciado del problema (EP)................................................... 130
IV.6.2.2 Modelo de Objetos ................................................................... 130
IV.6.2.2.1 Identificación de Objetos y Clases ................................. 130
IV.6.2.2.2 Buscar sujetos en el EP ................................................. 132
IV.6.2.3 Identificar Asociaciones entre clases ....................................... 134
IV.6.2.4 Identificar Atributos................................................................... 134
IV.6.2.5 Modelo Dinámico...................................................................... 135
IV.6.2.6 Modelo Funcional ..................................................................... 136
IV.6.2.7 Iterar el proceso ....................................................................... 137
IV.7 Análisis del Controlador ............................................................................ 138
IV.7.1 Enunciado del problema (EP) ......................................................... 140
IV.7.1.1Modelo de Objetos .................................................................... 140
IV.7.1.2Modelo Dinámico....................................................................... 141
IV.7.1.3Modelo Funcional ...................................................................... 142
CONCLUSIONES ................................................................................................ 144
BIBLIOGRAFÍA.................................................................................................... 152
ANEXOS.............................................................................................................. 159
V
LISTA DE FIGURAS
VI
Figura 3.2 El Proceso de desarrollo de OMT......................................................... 70
Figura 3.3 Casos de Uso ....................................................................................... 75
Figura 3.4 Modelo Vista Controlador ..................................................................... 83
Figura 3.5 Un solo Modelo puede tener varias vistas y controladores................... 83
Figura 3.6 Arquitectura de Modelo Vista Controlador ............................................ 86
Figura 4.1 Proceso de toma de decisiones............................................................ 97
Figura 4.3 Agenda ............................................................................................... 114
Figura 4.4 Agregar una cita ................................................................................. 115
Figura 4.5 Detalles de la cita ............................................................................... 115
Figura 4.6 Nota ligada a una cita ......................................................................... 116
Figura 4.7 Agregar una Dirección ........................................................................ 116
Figura 4.8 Forma Acerca de ................................................................................ 117
Figura 4.9 Catalogo del Constructor .................................................................... 118
Figura 4.11 Diagrama de clases de la Vista ........................................................ 125
Figura 4.12. Caso de Uso MV1A. El PalmOS inicia una aplicación:.................... 126
Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicación:
............................................................................................................................. 127
Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalización
de una aplicación................................................................................................. 128
Figura 4.15 Primera versión del diagrama de clases del Modelo ........................ 135
Figura 4.16. Caso de Uso MD01. Usuario diagnóstica un padecimiento............. 135
Figura 4.17 Diagrama de Flujo de Eventos de Elaboración de un diagnóstico.... 136
Figura 4.18 Algoritmo para obtener un diagnóstico ............................................. 137
Figura 4.19 Diagrama de Clases del Modelo....................................................... 138
Figura 4.20 Funciones creadas por Codewarrior................................................. 140
Figura 4.21 Modelo de objetos del Controlador ................................................... 141
Figura 4.22. El Usuario diagnostica padecimiento............................................... 141
Figura 4.23 Diagrama de clases de la Vista. ....................................................... 143
Figura C2. Patrón Modelo Vista Controlador Adaptador...................................... 151
VII
LISTA DE TABLAS
Tabla 2.1. Archivos importantes de la Interfaz de Programación de Aplicaciones de
Palm....................................................................................................................... 59
Tabla 3.1 Lista de Modelos de PDAs por Fabricante............................................. 87
Tabla 3.1 (cont.) Lista de Modelos de PDAs por Fabricante ................................. 88
Tabla 3.2. Comparación entre los modelos de Palm Inc. ...................................... 89
Tabla 3.3 Comparación de modelos de Handhelds contra una PC ....................... 91
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) ............. 92
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) ............. 93
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont) ............. 94
Tabla 4.2 Conocimiento del experto médico, resumido en una tabla. ................. 102
Tabla 4.10 Propiedades de los objetos de la interfaz gráfica .............................. 124
Tabla C1. Comparación de código entre versiones del SVES............................. 149
VIII
INTRODUCCIÓN
Hasta hace relativamente poco tiempo, en los países en vías de desarrollo como
México, los avances tecnológicos llegaban con un importante retraso respecto a
su aparición en los países desarrollados.
2
Esto ofrece a los programadores de los países en vías de desarrollo la
oportunidad de experimentar, de ser propositivos y no solo simples usuarios de la
tecnología importada.
3
CAPITULO I
DESARROLLO DE SISTEMAS
I.1 Conceptos del Software
A principios de los 80 no estaba claro cuán importante sería el desarrollo de
software. Hoy en día, se ha convertido en el eje de evolución de la industria de la
computación, y es el motor que conduce la toma de decisiones comerciales. Esto
ha provocado que cambie la percepción que el público tenia del software: de ser
un aditamento adicional a la computadora, a ser una plataforma de trabajo que
corre sobre un hardware no específico.
5
Dentro del gran conjunto de programas representados por el termino "software",
se pueden hacer dos grandes divisiones, de acuerdo a la función que
desempeñan. Una formada por el llamado Software de Sistema, encargado de
apoyar al usuario en la administración de su hardware, y la otra conformada por el
Software de Aplicación, subconjunto que agrupa a todos los programas que
resuelven necesidades y problemas específicos de los usuarios. Así, cuando un
usuario desea capturar un texto y darle formato, utilizar distintos tipos y tamaños
de letra y revisarlo ortográficamente, tiene que recurrir a un software de aplicación.
Igual debe hacerlo si desea capturar y manipular grandes volúmenes de datos, o
hacer muchos cálculos o si lo que quiere es construir imágenes y darles
animación. Mientras que si respalda archivos o administra impresoras, estará
usando software de sistema. Aunque el término "Sistema" se usa también como
sinónimo de software, y en especial en el presente documento, específicamente
del software de aplicación.
Tenemos entonces, que para representar algoritmos se debe contar con una
colección suficientemente rica de primitivas que, junto con las reglas de
6
combinación para representar estructuras más complejas, constituyen un lenguaje
de programación.
7
La traducción de un programa consiste en tres actividades: análisis léxico, análisis
sintáctico y generación de código
8
lenguaje natural, y está limitada a unas cuantas formas cuidadosamente
escogidas.
9
para que la propia computadora lo pueda llevar a cabo, lo que dio lugar a que el
uso de nombres mnemónicos se formalizara para dar origen a un lenguaje de
programación denominado "lenguaje ensamblador", y a un programa, también
llamado "ensamblador" que traducía otros programas escritos en lenguaje
ensamblador a lenguaje de máquina.
10
Una consecuencia importante de esta íntima asociación entre los lenguajes
ensamblador y de máquina es que cualquier programa escrito en lenguaje
ensamblador depende inherentemente de la máquina; esto es, las instrucciones
del programa se expresan en términos de los atributos de una máquina específica.
Por tanto, un programa escrito en lenguaje ensamblador no se puede transportar
fácilmente a otra máquina porque se tiene que reescribir de modo que se ajuste a
la configuración de registros y al conjunto de instrucciones de la nueva máquina,
ya que cada tipo de microprocesador tiene su propio lenguaje ensamblador
asociado (entendiendo que el lenguaje Ensamblador es simplemente una
representación simbólica del lenguaje máquina). Por tanto, es necesario un
profundo conocimiento de la arquitectura de la computadora para poder realizar
una programación efectiva.
11
primitivas eran de alto nivel y además independientes de las máquinas.
Los lenguajes de "alto nivel" son los más utilizados como lenguajes de
programación. Aunque no son fundamentalmente declarativos, estos lenguajes
permiten que los algoritmos se expresen en un nivel y estilo de escritura
fácilmente legible y comprensible por otros programadores. Además, los lenguajes
de alto nivel tienen normalmente la característica de "transportabilidad". Es decir,
12
están implementados sobre varias máquinas, de forma que un programa puede
ser fácilmente "transportado" o transferido de una maquina a otra sin ninguna
revisión sustancial. Es este sentido, se les denomina "independientes de la
máquina".
Ejemplos de estos lenguajes de alto nivel son Pascal, APL, FORTRAN, (para
aplicaciones científicas), COBOL (usado en aplicaciones de procesamiento de
datos), LISP y PROLOG (para aplicaciones de inteligencia artificial) C y Ada (para
aplicaciones de programación de sistemas). Aunque existen actualmente en uso
mas de 100 lenguajes de este tipo y muchos de ellos se encuentran en varias
versiones.
Los lenguajes de muy alto nivel, que aparecieron por primera vez en la década de
1960, se crearon para cubrir necesidades especializadas del usuario. Con ellos,
solo se necesita prescribir lo que la computadora hará en vez de como hacerlo.
Este tipo de recurso facilita mucho la programación. De este modo, los lenguajes
13
de alto y bajo nivel a veces se conocen como lenguajes procedurales, debido a
que requieren que las personas escriban procedimientos detallados que indiquen
a la computadora como realizar tareas individuales. Los lenguajes de muy alto
nivel, en contraste reciben el nombre de lenguajes no procedurales.
Los lenguajes de muy alto nivel presentan algunas desventajas graves: carecen
de flexibilidad; generalmente, cada uno está diseñado para un tipo específico de
tarea. No se puede, por ejemplo, procesar una nómina con un lenguaje de
procesamiento de palabras. Debido a que se enfocan a aplicaciones específicas,
los lenguajes de muy alto nivel a veces se conocen como lenguajes dependientes
del problema. Una segunda desventaja principal es que hay muchas aplicaciones
importantes que no son cubiertas por estos lenguajes. No obstante, en las áreas
para las cuales se encuentran disponibles, ofrecen obvias ventajas, tanto a los
programadores como a los usuarios.
14
Se podría considerar la programación como el conjunto de actividades y
operaciones tendientes a indicar a la computadora como debe realizar las
funciones previstas en el algoritmo.
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
15
y modifican en respuesta a las necesidades cambiantes de una organización y a
las condiciones en transformación del medio que la rodea. Cuando surgen
conflictos en un sistema existente o se necesita un nuevo sistema, el desarrollo de
sistemas entra en acción. El desarrollo de sistemas es un proceso que en forma
muy general consta del análisis de un sistema, el diseño de uno nuevo o las
modificaciones a uno ya existente, la adquisición del hardware y software
necesarios y hacer que un sistema nuevo o modificado trabaje.
Una limitación de esta arquitectura es que rara vez soporta interfaces gráficas, o
puede acceder a múltiples bases de datos.
16
Las reglas y convenciones que se siguen en estas conversaciones se conocen
como protocolos de comunicación entre capas. Y el conjunto de capas y
protocolos se conoce como arquitectura de red.
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.
17
El rol del proceso servidor puede ser asumido por el mismo sistema operativo, por
un equipo despachando archivos en una red e incluso por otra computadora de las
mismas características físicas que el cliente pero con la habilidad de ofrecer un
servicio del que aquel carece. [Sadoski, 1997]
18
Figura 1.7 Clientes y servidores en Internet
19
En resumen, las características básicas de la arquitectura son:
20
I.3.3 Sistemas Distribuidos
Los sistemas distribuidos surgen en 1993, y se basan en el uso de modelos de
negocio compartidos y reusables. El negocio se define entonces como un sistema
compuesto a su vez de otros subsistemas de negocio. Una vez más, se trata de
una extensión del modelo cliente / servidor en donde los equipos que ofrecen
servicios se pueden encontrar separados unos de otros.
21
El navegador es entonces un programa que se usa para tener acceso a los
servidores de Web y que despliega los documentos recuperados de esos
servidores. Desde el punto de vista de la tecnología cliente-servidor, un navegador
es el cliente del servidor de Web.
22
Figura 1.9 Cómputo Móvil
23
sobre productos almacenados o en producción, informando sobre el status o
localización de un pedido ya realizado o informando sobre el estado crediticio de
un cliente, confirmando cantidades y materiales recibidos por el cliente y
optimizando transacciones de venta y producción, capturando los datos del cliente
y llevándolos directamente a los almacenes de envío o áreas de producción.
24
I.3.5 Comentarios Finales
Como se mencionó al principio del capítulo, una aplicación puede constituir en si
misma un sistema, pero también puede ser que la aplicación móvil sea parte de un
sistema de información más grande. Esto se aplica también para las aplicaciones
en cómputo móvil: los datos almacenados en el dispositivo móvil pueden ser
procesados por este mismo, o ser enviados a otro (normalmente un equipo fijo,
mas grande) para su procesamiento.
Este trabajo pretende explorar las capacidades que tienen los dispositivos PDA
para recopilar y procesar información, además de delinear una metodología que
facilite el desarrollo de aplicaciones para estos.
25
CAPITULO II
DESARROLLO DE APLICACIONES PARA
ASISTENTES PERSONALES DIGITALIZADOS
II.1 Introducción a las PDAs
Antes de hablar sobre el desarrollo de aplicaciones para Asistentes Personales
Digitalizados (PDAs) por sus siglas en ingles, se mencionarán algunas
características de estos.
El término PDA define a "cualquier dispositivo móvil, que pueda ser operado con
una mano, y que tenga la capacidad de almacenar y procesar información para
uso personal o de negocio, así como administrar la agenda y el directorio
telefónico”. El término handheld se usa como sinónimo de PDA.
Algunas PDAs tienen un pequeño teclado, otras más tienen una área de la
pantalla capaz de detectar trazos y reconocer escritura; algunas incluso poseen la
capacidad de reconocer voz.
27
Figura 2.2 Palm IIIe
28
Figura 2.3 El procesador Dragonball
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.
29
La memoria RAM empleada en estos dispositivos es rápida y no volátil, gracias a
una alimentación continua de corriente, incluso cuando el dispositivo está
apagado.
Los modelos de Palm incluyen dos tipos de memoria, la memoria ROM donde se
aloja el sistema operativo y la memoria RAM donde residen los programas de
usuario y sus datos. El tamaño de las ROM habitualmente es de 2 MB, mientras
que el tamaño de RAM es variable, pudiendo oscilar entre los 128 KB (del modelo
Pilot 1000) hasta los 16 MB de los modelos más recientes. Desde el punto de vista
del programador, la memoria que se puede solicitar al sistema (Dynamic Heap) es
mucho menor, varia entre 32 KB y 256 KB.
A partir de los modelos Palm III y Palm IIIe, los dispositivos están equipados con
memoria flash ROM que permite actualizar el sistema operativo.
Las dos formas que tiene un usuario de interactuar con el Palm son:
•a través de la pantalla.
30
El digitalizador de escritura no es como tal una parte del hardware. En esencia, es
un software que, haciendo uso de redes neuronales reconoce los caracteres que
escribimos sobre la pantalla táctil.
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.
31
El puerto serie permite conectarse tanto con la PC como con otros dispositivos. La
comunicación serie esta completamente basada en interrupciones para la
transmisión de datos. Se utilizan cinco señales externas para soportar esta
comunicación:
SG (signal ground)
32
Figura 2.4 Arquitectura del PalmOS
33
(sistema de archivos) y memoria dinámica (la que emplea la aplicación durante la
ejecución). Cada una de estas es gestionada por una parte distinta del sistema
operativo, en el primer caso el Database Manager y en el segundo por el Memory
Manager.
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).
34
shortcuts son letras del alfabeto que permitirán acceder rápidamente a las
opciones sin desplegar el menú.
35
hay que tener en cuenta que se descargan a través de una conexión relativamente
lenta.
36
Figura 2.6 Otra vista de una aplicación web reducida
Por otro lado, aunque las aplicaciones Palm están dirigidas a eventos, también
pueden realizar funciones fuera del ciclo de eventos, como respuesta a otras
peticiones del sistema operativo. Por ejemplo, si se realiza la búsqueda de una
37
palabra, se intentará encontrar en todos los registros de todas las aplicaciones esa
palabra. Esto implica que se lanzará cada una de las aplicaciones y se le pedirá
que verifique sus registros para ver si contiene esa palabra.
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.
38
Figura 2.10 Conduit de sincronización diaria de Palm
Pero este código puede indicar a la aplicación que debe arrancar, realizar alguna
tarea pequeña y luego terminar (como cuando se usa la función global de
"encontrar", que busca una cadena de caracteres en las bases de datos de todas
las aplicaciones). Existen códigos de arranque para muchos propósitos, como
39
abrir una base de datos en un registro predeterminado, notificar a la aplicación que
se acaba de realizar una sincronización exitosa, etc.
Además, existe una estructura de datos que describe el tipo de evento que esta
ocurriendo en un momento dado [Ibid.]. En esta estructura se almacena el tipo de
evento que esta ocurriendo (por ejemplo, presionar con el lápiz algún botón) así
como la información relativa a ese evento (por ejemplo, las coordenadas en las
que el lápiz tocó la pantalla).
40
Finalmente, la función StopApplication cierra las bases de datos, indica al sistema
operativo que almacene las preferencias del usuario y realiza todas las tareas
necesarias para que la aplicación termine en forma correcta.
41
anteriormente, una aplicación para Palm es simplemente una base de datos que
contiene por una parte el código ejecutable y por otra los elementos gráficos y
demás datos.
42
Cuando se han eliminado todos los errores, y el programa se ejecuta sin
problemas en el emulador, esta listo para instalarse en un dispositivo real.
0
Codigo 1 Loader
Maquina 0
1
1
Mnemonicos Ligador
Ensamblador
Ensamblador mov AX,0
llda BX
Memoria
Compilador
Lenguaje Lenguajes
de de
Alto Programación
(P.E. Interprete
Nivel
Pascal)
Para pasar de código fuente a lenguaje de máquina, los programas deben ser
transformados por un compilador. El compilador genera un archivo intermedio con
código llamado objeto. Este archivo sirve de entrada al encadenador (linker) que
resuelve las llamadas que el archivo objeto hace a las librerías propias del
43
lenguaje. El termino "archivo objeto" no necesariamente implica alguna conexión
con la programación orientada a objetos.
II.5.2.2 COFF
Debido a que un microprocesador solo ejecuta sus propias instrucciones nativas,
una solución eficiente para desarrollar programas que se ejecuten en una
plataforma diferente a aquella en la que se programa, consiste en crear código
binario para la plataforma destino, a partir de programas fuentes (usualmente en C
o C++).
44
Pero para explotar al máximo las características físicas del dispositivo destino, se
requieren hacer optimizaciones adicionales. En la literatura existen técnicas de
optimización de código para diferentes arquitecturas de hardware. Algunos
procesadores de la familia Intel, por ejemplo, incluyen su propio coprocesador de
punto flotante, mientras que en los procesadores Motorola de la familia 68000, la
aritmética de punto flotante se debe hacer a través de librerías de software.
Por otro lado, como el mismo sistema operativo esta escrito (al menos en parte)
con instrucciones de código nativo, es más eficiente que los programas
interactúen directamente con este, y no a través de interfaces o maquinas virtuales
como la maquina virtual de Java.
Los formatos ELF y COFF son muy similares, y permiten prácticamente la misma
funcionalidad. Ambos pueden usarse para especificar código objeto (de archivos
generados por el compilador), y código ejecutable (archivos producidos por la
herramienta de encadenado). Estos formatos contienen secciones. Las secciones
45
que se encuentran tanto en archivos objeto como ejecutables son: .text, que
contiene el código binario ejecutable; .data, que contiene datos inicializados en el
programa (como en una declaración "int a=7;" donde se declara un entero y se
inicializa con un valor de 7); y .bss (blow stack segment), sección que almacena
datos no inicializados (como cuando se declara "int arreglo[100000];". En este
último caso, no se reserva espacio para la variable sino hasta cuando se el archivo
esta en ejecución).
II.5.2.4 PRC-Tools
Las PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc".
Esta herramienta tiene un doble propósito: convertir recursos de código y datos al
formato que el PalmOS espera; y en general, construir programas para Palm
(PRCs) a partir de colecciones de archivos de recursos separados.
Las PRC-Tools incluyen una herramienta de post-encadenado llamada "build-prc".
Esta herramienta tiene un doble propósito: convertir recursos de código y datos al
formato que el PalmOS espera; y en general, construir programas para Palm
(PRCs) a partir de colecciones de archivos de recursos separados.
46
Las PRC-Tools producen código en formato m68k-coff, es decir, código para
procesadores de la arquitectura M68000 de Motora, usando el formato binario
COFF.
↓
!"!# $&%& '
)(*
+,!#-- .!/
01'"2'43
↓
65728 9:;3 <.=)5.283 '4 $>5./289:2?3 <*@)
)A#3
↓
AB' $&%& ' (0
",!&- (*
BA)
0,1' "2;"3
↓
C)C C3 <=C C)C3 'D=FE3 8
B $GC C)C3 <.=)CCC3 'H;I)
A43
↓
(MN)O.P)AB(2P/ P/Q) $ (R
BA))S(*A6!#
BA"!#
'(*GTU&VI3
↓
' <,
WKG))
$ (*
A,G * A.(*
AB)X(*AW!#
AB4!
'(*&Q3
↓
)8"Y+P/' $GZ[(G8
\ *ABA (0 ,G(0MN)OP A(0DP#P#)8 Y"P#'43
↓
/E3 Q'=E3 8
$G '"<
WK13 Q':]'Q' (0)= '"<
WK13 8
^]_J-'"<
WK@-A&
B!#"
)C:Q'
,3
47
8,
AP' $`%a
' (
",!&,H!
P# )")=)'? - ' <,
WK cb-d.d 3
↓
6%& AA3 ' $-eYD "!#"8A1 '15XA( b*f 3
II.5.2.5 CodeWarrior
Según se indica en el documento CodeWarrior Assembler Reference, esta
herramienta soporta diferentes formatos de archivos objetos, como el Executable
and Linkeable Format (ELF) o el Common Object File Format (COFF)
II.5.2.6 Otros
Microsoft también da soporte, en Windows NT, a los archivos objeto en formato
COFF. La versión 3.1 de Windows NT introdujo un nuevo tipo de formato de
archivo ejecutable llamado PE (Portable Executable).
Este formato se inspiró en el formato COFF (Common Object File Format) de los
sistemas operativos UNIX. Pero para mantener su compatibilidad con las
versiones del MS-DOS y los sistemas operativos Windows, el formato PE
48
mantiene el encabezado MZ del MS-DOS. Se le nombró portable, por que según
Microsoft el archivo ejecutable tiene el mismo formato sin importar si el procesador
en que se va a ejecutar tiene un tamaño de palabra de 16, 32 o 64 bits. Asimismo
este mismo formato es usado en micro procesadores diferentes a los Intel, tales
como MIPS, Alpha y Power PC, entre otros. Los archivos DLL de 32 bits y los
controladores de dispositivos (device drivers) también emplean el formato PE.
49
Existe una gran variedad de lenguajes de programación entre los que se puede
elegir, desde programación a bajo nivel con ensamblador hasta programación
orientada a objetos
Por ejemplo, existe una herramienta llamada Pila que permite programar en el
lenguaje del microprocesador DragonBall 68328. Pila ensambla, compila recursos
y enlaza librerías, permitiendo obtener un ejecutable de Palm.
50
Las acciones de la aplicación se pueden controlar de dos formas: Especificar
acciones "prefabricadas" que suceden en respuesta a las acciones del
usuario. Por ejemplo, cuando se pulsa un botón, se podrá elegir de entre las
opciones disponibles la que más convenga, como volver a la anterior pantalla
o crear una nueva.
51
Sin embargo, tiene la desventaja de que el entorno solo funciona en
Windows, y que las aplicaciones que crea obligan a instalar en el Palm una
librería de tiempo de ejecución. Por lo que esta aplicación no da la flexibilidad
que se puede obtener programando en C / C++ directamente.
52
La opción mas difundida para programar en Palm es el lenguaje C. Y existen dos
opciones principales entre las que se puede elegir: por una parte la solución
comercial con el software de desarrollo CodeWarrior de Metrowerks, y por otra las
llamadas PRC-Tools, el conjunto de herramientas Open Source desarrolladas por
la “Free Software Foundation”.
53
También existen interpretes de BASIC (como CbasPad) o LISP y varias máquinas
virtuales para Java, entre las que destacan la máquina virtual KVM de SUN y la
máquina virtual J9 de IBM, esta última integrada dentro del entorno de desarrollo
VisualAge Micro Edition.
54
Pero, a pesar de la bondad del emulador, algunas veces se hace necesario
emplear un dispositivo real para realizar las pruebas. Esto ocurre por ejemplo
cuando en la aplicación se emplea la comunicación TCP/IP mediante sockets.
55
II.7 Características del API de Palm
Para facilitar el desarrollo de aplicaciones para sus dispositivos, Palm Inc. ofrece
un conjunto de Interfaces de Programación de Aplicaciones (APIs, por sus siglas
en Inglés) en lenguaje C.
Estas APIs están conformadas por archivos de encabezado (.h) en los que se
definen funciones y declaraciones que son fundamentales para el desarrollo de
aplicaciones en Palm.
Sin embargo, Palm no establece ningún tipo de organización de sus APIs, por lo
que, a continuación se sugiere un esquema de organización de las mismas.
56
Figura 2.19 Organización de la API de Palm.
Sobre este conjunto inicial se construyen otras funciones, encargadas entre otras
cosas, de manejar los errores y las facilidades de depuración de código, la
aritmética de punto flotante, encriptamiento de datos, etc. Estas funciones se
clasificaron como funciones de Administración del Sistema.
57
La siguiente tabla muestra los archivos de encabezado más importantes de la API
nativa del PalmOS SDK, agrupados en el orden sugerido por el esquema.
ErrorBase Errores
Comunicaciones
Archivos
FileStream Archivos
Interfaz de Usuario
Form Formas
Window Ventanas
58
Table Tablas
Field Campos
Por ejemplo, para añadir una clase miString (de manejo de cadenas de
caracteres), se crea un archivo miString.h, con la definición de la clase:
// miString.h
#ifndef _MI_STRING_H_
#define _MI_STRING_H_.
#include <StrMgr.h>
class String{
char cTexto[100];
public:
miString(char *cadena);
59
}
#endif
StrPrintF(cTexto,"%s",cadena);
Una vez hecho esto, todas las rutinas del proyecto podrán tener acceso a la clase
miString.
II.7.3 CodeWarrior
El CodeWarrior (de MetroWerks) es una herramienta comercial, pero se puede
descargar una versión de evaluación con toda la funcionalidad, excepto el tamaño
de los ejecutables que se pueden crear y depurar.
60
CodeWarrior combina diferentes herramientas de desarrollo (un editor de código,
un compilador, una utilería de encadenamiento (linker) y otra de depuración
(debugger) en una sola aplicación, controlada por una interfaz gráfica.
Por una parte, en sitios que distribuyen programas para Palm junto con código
fuente (como www.palmopensource.com ) se puede observar que hasta un 95%
de los desarrollos están hechos en C.
Una de las excepciones que se puede desatacar es el programa pBill que es una
versión para Palm del juego para Linux del juego Xbill (www.xbill.org) y que esta
desarrollado completamente en C++.
61
También existen algunas librerías en C++: hay productos de código abierto como
Teenie (solo se puede obtener en www.palmopensource.com, ya que desapareció
como producto gratuito y se convirtió en ZenPlus, un producto comercial), y otros
productos en etapas iniciales del desarrollo.
Por ejemplo, para las PRC-Tools existe un producto llamado Palm C++
Framework (www.bradygirl.com/PalmFW), las Palm SDK Foundation Classes
(sourceforge.net/projets/pfcpp/), o el "Razor! Game Engine" (www.tilo-
christ.de/razor) que es una librería para desarrollo de juegos.
Pero también hay disponibles productos comerciales, como Object Library for
PalmOS (www.aqpoint.com/pol/), el Palm Application Framework
(brearriver.com/developer/palm) o el mencionado ZenPlus.
Por otro lado, C permite simular objetos usando estructuras. [Young, 1992]
muestra un ejemplo completo de como implementar una aplicación orientada a
objetos en C manejando estructuras; en resumen, el autor propone el manejo de
los atributos del objeto a través de estructuras en C, y para simular el
encapsulamiento, todas las funciones que manipulen datos del objeto deben
recibir como primer parámetro un apuntador al mismo. De esta forma, si al
programador por accidente llamara a la función con otros objeto, ocurriría un error
en tiempo de compilación.
62
"Languajes and Environment Types"
(http://www.palmos.com/dev/start/environments.html) dice:
63
del código ejecutable se vuelva tan grande que sea imposible de manipular en un
dispositivo Palm.
Para prevenir esos errores, sugieren, entre otras cosas: evitar el uso de
Templates, usar algunas opciones de compilación que ayudan a obtener código
ejecutable compacto, y tener cuidado con la implementación del polimorfismo.
Sin embargo C tiene una serie de desventajas frente a C++. Enumerarlas todas no
es el fin de este trabajo, baste decir que el manejo mas eficiente que C++ hace de
la memoria, de entrada lo convierte en una mejor opción para programar en un
ambiente donde, como se ha explicado, el manejo adecuado de la memoria es
primordial.
Por esta razón, uno de los planteamientos que hace el presente trabajo, es el
desarrollo de una librería de objetos para CodeWarrior, bajo el esquema
OpenSource.
Esta librería es, en realidad, un conjunto de clases que enmascaran todas las
funciones ofrecidas por las APIs de Palm. Además, ofrece clases para manipular
todos los elementos de la interfaz de usuario.
También se plantea un esqueleto de todos los objetos que controlen las reglas del
negocio. Así como un esquema de control de memoria:
64
sola instancia en toda la aplicación de las clases de Cadenas (de Caracteres),
Bases de datos, de todas las clases que ayuden en la manipulación de objetos de
la Interfaz de Usuario y de otras clases relacionadas más con las reglas de
negocio, como podría ser la clase Numero Flotante.
65
CAPITULO III
OMT PARA EL ANÁLISIS Y DISEÑO DE
APLICACIONES EN ASISTENTES PERSONALES
DIGITALIZADOS
III.1 Elementos de OMT
Una metodología es un algoritmo que encuentra la solución de un problema dado
a través de un proceso bien definido. Como nos dice [Pressmann, 1988], la
popularidad de las tecnologías de objetos ha generado docenas de métodos de
análisis y diseño. Cada uno de ellos introduce un proceso para el análisis del
sistema, un conjunto de modelos que evoluciona fuera del proceso y una notación
que posibilita crear cada modelo de una manera consistente. Entre otras
metodologías se pueden mencionar la de Booch, Coad y Yourdon, de Jacobson y
el OMT de Rubaugh y sus colaboradores. Recientemente fue desarrollado el
Rational Unified Process por un equipo formado por Booch, Rumbaugh y
Jacobson.
67
identidad y son distinguibles. Una clase de objetos describe un grupo de objetos
con atributos, operaciones y semántica comunes. Un atributo es una propiedad de
los objetos de una clase. Una operación es una acción que puede ser aplicada a
(o realizada por) los objetos de una clase.
El Modelo de objetos esta compuesto por los diagramas del modelo de objetos y
diccionario de datos.
El modelo dinámico describe los aspectos del sistema que cambian conforme
pasa el tiempo. Se usa para especificar e implantar los aspectos de control del
sistema. Contiene diagramas de estados, los cuales son grafos cuyos nodos son
estados y cuyos arcos son transiciones entre los estados, las cuales son causadas
por los eventos. Sus elementos son: estados, transiciones y eventos. El estado de
un objeto se determina por los valores de sus atributos y sus ligas en un momento
específico. Las transiciones denotan los cambios en el estado de un objeto. Los
eventos son los que disparan las transiciones de un estado a otro.
68
diagrama de flujo de datos es un grafo cuyos nodos son procesos y cuyos arcos
son flujos de datos. El principal elemento del modelo funcional es el proceso.
69
valores del objeto y que provocan acciones que a su vez modifican estos valores e
invocan a otras funciones.
El modelo funcional describe las funciones invocadas por las operaciones del
modelo de objetos y las acciones del modelo dinámico, así como restricciones en
los valores de los objetos.
70
Cada fase del proceso transforma algunas entradas en salidas, empezando en el
nivel de abstracción mas alto y continuando en niveles mas detallados hasta el
que finalmente represente la solución del problema.
Una vez que esta versión inicial del sistema es totalmente operacional, se le
puede añadir funcionalidad al sistema, en forma incremental.
III.2.1 Análisis
Según explica Rumbaugh [Ibid.] durante esta etapa se busca obtener un modelo
"preciso, conciso, comprensible y correcto del mundo real". El objetivo del análisis
es desarrollar un modelo del funcionamiento de un sistema del mundo real.
71
El análisis comienza con la definición de un problema generada por el cliente y
que puede ser incompleta e informal. A partir de esta, se escribe una definición
inicial del problema, describiendo lo que se va a hacer, y no como hay que
implementarlo.
• Probar las rutas de acceso usando escenarios e iterar los pasos anteriores
según sea necesario.
El modelo de objetos esta compuesto por los diagramas del modelo de objetos y el
diccionario de datos.
72
El siguiente paso consiste en elaborar el modelo dinámico, en donde se
representa el comportamiento del sistema y la secuencia de interacciones. Para
esto, se preparan escenarios de secuencias de eventos entre los objetos del
sistema, ya sean típicas o excepcionales; también se identifican los sucesos
externos a los que el sistema debe responder. Para cada objeto activo se
construye un diagrama de estados que mostrará los mensajes que el objeto
recibe, las acciones que lleva a cabo y las respuestas que genere.
73
• Identificar valores de entrada y salida.
• Identificar restricciones.
Las partes que conforman el Modelo funcional son: Los diagramas de flujo de
datos y el listado de restricciones.
Este proceso se itera tantas veces como sea necesario, tratando de:
Una forma de describir los requisitos iniciales del usuario, durante la fase de
conceptualización, es construir casos de uso del sistema, descritos inicialmente
74
por Jacobson en 1987 y actualmente incorporados a la mayor parte de las
metodologías de Análisis Orientado a Objetos.
Un caso de uso está formado por una serie de interacciones entre el sistema y un
actor (una entidad externa, ejerciendo un rol determinado), que muestran una
determinada forma de utilizar el sistema. Cada interacción comienza con un
evento inicial que el actor envía al sistema y continua con una serie de eventos
entre el actor, el sistema y posiblemente otros actores involucrados.
III.2.2 Diseño
III.2.2.1 Diseño de sistemas.
Al realizar el diseño del sistema se deben tomar decisiones de alto nivel acerca de
la arquitectura total. Durante el diseño del sistema, el sistema objetivo es
organizado en subsistemas basados tanto en la estructura del análisis como en la
arquitectura propuesta. El diseñador del sistema debe decidir que características
de desempeño optimizar, escoger una estrategia para atacar el problema y hacer
asignaciones de recursos tentativas. Por ejemplo, el diseñador del sistema debe
75
decidir que cambios a la pantalla de la estación de trabajo deben ser rápidos y
suaves aún cuando las ventanas sean movidas o borradas, y seleccionar un
protocolo de comunicaciones apropiado y una estrategia de intercambio de
bloques de memoria.
76
El producto de esta etapa es el documento de diseño de sistema, compuesto por
la descripción de la estructura de la arquitectura básica del sistema y las
decisiones de estrategias de alto nivel.
77
2. Diseñar los algoritmos para implantar las operaciones:
78
6. Diseñar la implantación de las asociaciones:
79
Como señala [Tidwell, 2002] "los patrones pueden considerarse descripciones de
'las mejores prácticas' de un cierto dominio de diseño. Registran soluciones
comunes a las dificultades de diseño,.. aunque cada implementación de un patrón
es diferente de las otras." Además, los patrones "permiten a los programas (y a los
programadores) compartir su conocimiento sobre diseño" [Korgaonkar, 2002].
•Solución propuesta
80
•Contexto de la solución
•Autor y fecha
81
III.3.2 Patrón Modelo Vista Controlador
El patrón Modelo Vista Controlador (MVC) es un patrón de diseño clásico,
comúnmente usado por aplicaciones que necesitan mantener diferentes vistas de
los mismos datos. Permite separar el objeto de la aplicación (modelo) de la forma
en que se le presenta al usuario (vista) y de la forma en que el usuario lo controla
(controlador).
Gracias a esto, el Modelo Vista Controlador facilita una clara separación de los
objetos en alguna de las tres categorías: modelos que mantienen datos, vistas que
los despliegan y controladores que manipulan los eventos que afectan el modelo o
la(s) vista(s). Gracias a esta separación, diferentes vistas y controladores pueden
interactuar con el mismo modelo. Incluso se pueden crear nuevas vistas o
controladores que interactúen con el modelo sin que se deba cambiar el diseño de
este.
82
Figura 3.4 Modelo Vista Controlador
83
•Una Interfaz de Programación de Aplicaciones muy bien definida.
La vista toma las entradas del usuario y pasa la información al modelo. El modelo
envía información a la vista, para que se la muestre al usuario.
Para evitar un acoplamiento muy estrecho entre vista y modelo, este debe operar
en forma totalmente independiente de la forma en que la vista interactúe con el
usuario, y esta debe satisfacer las necesidades del usuario, independientemente
de aquel.
84
4. En general, para que un modelo y una vista se puedan comunicar, se requiere
un objeto "adaptador" que traduzca la salida de uno en la entrada del otro.
5. Ni el modelo ni la vista son capaces de crear el adaptador que los conecte, por
que son entes totalmente independientes.
El Modelo es el objeto que representa los datos del programa. Maneja los datos y
controla todas sus transformaciones. El Modelo no tiene conocimiento específico
de los Controladores o de las Vistas, ni siquiera contiene referencias a ellos. Es el
propio sistema el que tiene encomendada la responsabilidad de mantener enlaces
entre el Modelo y sus Vistas, y notificar a las Vistas cuando cambia el Modelo.
85
El Controlador es el objeto que proporciona significado a las ordenes del usuario,
actuando sobre los datos representados por el Modelo. Cuando se realiza algún
cambio, entra en acción, bien sea por cambios en la información del Modelo o por
alteraciones de la Vista. Interactúa con el Modelo a través de una referencia al
propio Modelo.
86
III.3.2.1 Modelo Vista Controlador y desarrollo para Palm.
Se espera que los programas desarrollados para la plataforma Palm funcionen,
independientemente de las características físicas del dispositivo (tamaño de la
pantalla, presencia de color, método de entrada de datos). Esto implica que el
Modelo (la parte del programa encargada de realizar cálculos, obtener datos de
archivos, etc.) debe ser totalmente independiente de la interfaz de usuario (la
Vista)
87
Fabricante Modelo Fabricante Modelo
Dell Axim X5 Standard 300MHz Palm Inc. Palm m500
Ericsson MC218 Palm M505
Treo Handera 330 Palm m515
Handspring Treo 270 Psion Psion Revo
Handspring Visor Psion Series 3a
Handspring Visor Edge Psion Series 5
Hitachi Eplate 600 et Psion Psion Series 5mx
HP 200lx Psion Series 7
Jornada 525 pocket pc Sagem WA 3050
Jornada 545 Sony Sony Clie PEG N770C
Jornada 545/548 Sony Clie PEG S300
Jornada 568 64MB Sony Clie PEG-SJ30
Pocket PC
Jornada 720 PDA Sony Clie PEG-T425
IBM WORKPAD Z50 Sony Clie PEG-T625C
Sony NR70VG
Sony T625c
Toshiba Pocket PC e570
Tabla 3.1 (cont.) Lista de Modelos de PDAs por Fabricante
88
III.4.1 Los distintos modelos de Palm
Dentro de la gama de dispositivos fabricados por Palm Inc. hay diferencias mas o
menos importantes, en cuanto a capacidad, tamaño físico del dispositivo, etc.
Peso 157 gr. 109 gr. 139 gr. 124 gr. 124 Gr. 124 Gr. 124 Gr.
Memoria 16 Mb 2 Mb 16 Mb 8 Mb 8 Mb 2 Mb 8 Mb
Tamaño 10.2 x 7.5 x 1.5 11.2 x 7.4 x 1.6 11,4 x 7,9 x 12,7 4.66" x 3.12" x 4.66" x 3.12" x 4.66" x 3.12" x 4.66" x 3.12" x
cm cm cm. 0.72" 0.72" 0.72" 0.72"
Vibrador si no si no no no no
Memoria Flash si no si no no no no
Pantalla Alta resolución. Monocroma 65.000 colores 65.000 colores escala de grises escala de grises escala de grises
65.536 colores.
Capacidad para Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks, Juegos, ebooks,
agregar datos y mucho datos y mucho datos y mucho datos y mucho datos y mucho datos y mucho datos y mucho
aplicaciones más... más... más... más... más... más... más...
Tipo Recargable litio- Recargable litio- Recargable litio- Recargable litio- AAA AAA AAA
ion ion ion ion
Vida (uso normal) 1 semana 1 mes 1 mes 1 mes 2 meses 2 meses 2 meses
Comunicación vía si. Tiene Slot si si. Tiene Slot si. Tiene Slot si. Tiene Slot si si
puerto serial para tarjetas de para tarjetas de para tarjetas de para tarjetas de
expansión. expansión. expansión. expansión.
Infrarrojo si si si si si si si
89
III.4.2 Características generales de las computadoras de mano,
independientemente de la marca.
No todos los dispositivos mencionados usan el PalmOS como su sistema
operativo nativo. Al final del capítulo, la tabla 3.2 compara las características de
algunos de los equipos que manejan PalmOS (modelos del Palm Inc. y otros),
contra computadoras de mano (handhelds) que usan otros sistemas operativos y
contra un equipo PC de escritorio Típico.
90
Tabla 3.3 Comparación de modelos de Handhelds contra una PC
Fabricante Modelo Precio Memoria Capacidad Procesador Velocidad Tipo de Versión del Capacidad Tipo de Resolución Area útil Profundida
estimado RAM para Pantalla d
de del Método de Sistema Sistema de la de la
Máximo Instalada Operativo Operativo actualizar pantalla de
Expansión Procesador sincronizaci Pantalla
(U$) el
ón (pulgadas color
Sistema cuadradas)
Operativo
Blackberry H1100 $499 5M No Intel 386 N/D Serial, BlackBerry N/D N/D Monocrom 160 x 160 7 N/D
Infrarrojo o
Casio Cassiopeia $479 32M Compact NEC 131 MHz Infrarrojo, Pocket PC Windows N/D Color 240 x 320 3.9 16 bits
E-105 Flash Serial CE 2.1
Compaq iPaq $604 64MB Secure Intel 206 MHz Infrarrojo, Pocket PC Pocket PC Si Color 240 x 320 3.77 16 bits
H3850 Digital StrongARM USB 2002
Diamond Mako $149 16MB No ARM 710 T 36 MHz Infrarrojo, EPOC EPOC R5 Si Monocrom 240 x 320 7.4 N/D
RISC Serial o
Handspring Treo 180 $499 16MB No Motorola 33 MHz USB Palm OS 3.5.2 o Si Monocrom 160 x 160 3 N/D
Dragonball superior o
VZ
Visor $92 2MB Springboar Motorola 16 MHz Infrarrojo, Palm OS 3.1 Si Monocrom 160 x 160 3.1 N/D
d Dragonball USB o
EZ
Visor $109 8MB Springboar Motorola 16 MHz Infrarrojo, Palm OS 3.1 Si Monocrom 160 x 160 3.1 N/D
Deluxe d Dragonball USB o
EZ
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
Fabricante Modelo Precio Memoria Capacidad Procesador Velocidad Tipo de Versión del Capacidad Tipo de Resolución Area útil Profundida
estimado RAM para Pantalla d
de del Método de Sistema Sistema de la de la
Máximo Instalada Operativo Operativo actualizar pantalla De
Expansión Procesador sincronizaci Pantalla
(U$) el
ón (pulgadas color
Sistema cuadradas)
Operativo
HP Jornada $833 32MB Tarjeta PC, StrongARM 206 MHz Infrarrojo, Pocket PC Windows Si Color 640 x 240 6.5 16 bits
720 Compact RISC serial, USB para
Flash Handheld
PC 2000
Palm Tungsten T $499 16MB MultiMedia Texas N/D Infrarrojo, Palm OS 5 Si Color 320 x 320 N/D 16 bits
Card, Instruments USB
SmartMedi OMAP
a 1510
m100 $93 2MB No Motorola 16 MHz Infrarrojo, Palm OS 3.5 Si Monocrom 160 x 160 3.3 N/D
Dragonball serial o
EZ
Palm IIIc $88 8MB No Motorola 20MHz Infrarrojo, Palm OS 3.5 Si Color 160 x 160 4.1 8 bits
Dragonball serial
EZ
Sony CLIE PEG- $150 8MB Memory N/D N/D USB Palm OS 4.1 Si Monocrom 160 x 160 4.1 N/D
SL10 Stick o
PC
ACER Aspire A partir de hasta 3 GB Si Intel 2.4 a 2.8 N/A Opcional Si Color 1600 x 350 x 262
G600 p $800 GHz (Windows) 1200 mm
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
Casio Cassiopeia E- Recargable (2) 6 No 5 x 3.3 x 0.7 9 Entrada para audífonos, microfono, entrada para tarjeta
105 multimedia, batería de respaldo
Compaq IPaq H3850 Recargable 10 No 5.1 x 3.3 x 0.6 6.3 Entrada para audífonos, mícrofono, software multimedia
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
Sony CLIE PEG- AAA N/D No 4.6 x 2.8 x 0.6 3.6 Software multimedia
SL10
Tabla 3.3 Comparación de modelos de Handhelds contra una PC (cont)
PC
ACER Aspire G600 p N/A N/A N/D 452mm x 180mm x 417mm N/D CD-Lectura/Escritura, DVD, puertos serie, paralelo, USB, entrada
para audífonos, micrófono
(1) A menos que se indique otra cosa, todos los modelos vienen con batería de ion litio
(2) La batería recargable se puede remover y reemplazar.
(3) Niquel-metal hidruro.
(4) Requiere dos baterías AAA.
N/D Dato no disponible
N/A No aplica
CAPITULO IV
CASO DE ESTUDIO: SVES
IV.1 Sistemas de Apoyo en la toma de decisiones
Los sistemas de apoyo para la toma de decisiones tienen muchas características
que los hacen diferentes a otros sistemas tradicionales.
[ 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.
96
analítico aprende a analizar situaciones particulares. Existen procedimientos
definidos paso a paso para efectuar la decisión, y se hace uso de las matemáticas
para modelar los problemas. Adicionalmente, puede involucrar el uso de una base
de datos para almacenar información estadística o histórica.
[Landsberg, op. cit.] indica también que una mala definición del problema suele ser
la causa de que no se llegue a solucionar totalmente el mismo, por lo que, en caso
de que el problema no se encuentre bien definido, se deben considerar los
objetivos que se espera cumplir y los eventuales obstáculos que se puedan
presentar.
97
Para obtener información se debe acudir en primer lugar, a los individuos, grupos
u organizaciones afectadas por el problema o su solución. Enseguida, se deben
buscar resultados de investigaciones, estudios y experimentos ya existentes,
además de entrevistar a los expertos en el área de estudio y demás fuentes
confiables de información. Así mismo, se deben determinar las restricciones y
tomar en cuenta las opiniones de aquellos individuos que influirán en la solución
del problema.
98
importante en el cuidado de la salud, mejorando la calidad y eficiencia del proceso
de diagnóstico.
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.
99
"Cuando usted se prepare para examinar a un hombre enfermo..."
100
Otro ejemplo notable es PUFF, un sistema experto que diagnostica la presencia
de enfermedades severas en el hígado. El Brain Tumors Diagnostic System
(BTDS) es otro sistema experto que ayuda a los médicos a diagnosticar tumores
cerebrales. BTSD esta conformado por un sistema experto y un sistema de
aprendizaje.
IV.1.2.4 Ejemplo
Considérese, el siguiente escenario:
101
Una pequeña fracción del conocimiento de los expertos, se ha resumido en la
siguiente tabla:
102
manera importante a grandes grupos de población, especialmente a quienes no
tienen acceso a servicios de salud.
103
Es muy frecuente encontrar situaciones en donde es prácticamente imposible
obtener una cobertura universal de la información. Por esta razón y para reducir
estas inconveniencias, fueron ideadas y propuestas modernas y efectivas técnicas
por muestreo, además de formas de investigación complementaria, que sin
embargo, resultan insuficientes para generar el conocimiento básico sobre
situaciones especiales de interés epidemiológico, demográfico y de servicios de
salud.
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.
104
enfermedades transmisibles y la desnutrición, así como al registro de hechos
vitales y de servicios básicos de salud. De igual manera, han sido utilizados en las
tareas de monitoreo y evaluación de las condiciones de saneamiento básico y del
ambiente en general.
a) simple en su estructura
105
IV.3.1 Sistemas no convencionales de Información
Desde finales de la década de los 70, varios países han experimentado con la
recolección de información por personal no médico (lego); este tipo de recolección
(lay reporting) ha sido subsecuentemente extendido a un concepto amplio
denominado "métodos no convencionales de información". En diferentes países,
estos métodos, que cubren una variedad de enfoques, han evolucionado como
medios de obtener información acerca del estado de salud de la población donde
los métodos convencionales (censos, encuestas, estadísticas vitales y estadísticas
de morbilidad) han resultado inadecuados o no existen.
106
Los propósitos de la información de salud colectada son: alertar a las autoridades
de salud para la emergencia de un problema de salud y facilitar el manejo de
cuidados de salud primarios. Los datos colectados deben ser analizados y
reportados hacia el siguiente eslabón administrativo.
107
atención de sus necesidades básicas o problemas prioritarios de salud. El
establecimiento de métodos alternativos de solución a los problemas de salud
requiere de información oportuna y completa sobre los daños y riesgos a la
población, ya que de otro modo se corre el riesgo de tener escaso o nulo impacto
en su prevención y control. Ante esto, la Secretaría de Salud decidió desarrollar
diversas acciones de trabajo comunitario, con la participación de personal
comunitario voluntario previamente capacitado, para utilizar instrumentos de
registro y técnicas de diagnóstico de fácil manejo que faciliten la identificación de
ciertos padecimientos y riesgos a la salud, que permitan dar solución a los
problemas de mayor importancia local y regional.
108
salud y situaciones de importancia epidemiológica de las comunidades sin acceso
a los servicios de salud.
4. Informe Mensual
109
La plantilla de diagnóstico considera 24 padecimientos, integrados en 11 grupos:
Tuberculosis
Intoxicación por ponzoña
Anginas
Picadura de alacrán
Otitis
Otras enfermedades
Enfermedades del sistema nervioso Enfermedades de la piel
Parálisis
Infecciones vaginales
Ataques
110
IV.5 Formatos e instructivos de registro y notificación
IV.5.1 Plantilla para el Diagnóstico Individual de Enfermedades
Este documento es usado por el auxiliar de salud. Representa un método práctico
y útil para hacer de manera simplificada el diagnostico probable de algunas
enfermedades de importancia epidemiológica, mediante la combinación de
algunos signos y síntomas, que aparecen en su parte superior (y que no
representan el total de la sintomatología de los padecimientos incluidos, sino la
más frecuente y fácil de identificar por el auxiliar de salud). Del lado derecho
aparecen los 24 padecimientos o diagnósticos que la plantilla permite detectar.
111
el pequeño tiene diarrea o está suelto, se deberá cruzar todos los orificios
que estén por debajo de la palabra "diarrea".
112
6. En caso de que no se integre ningún diagnóstico, se deberá considerar
como un problema mal definido.
113
Como sugiere [ Rumbaugh , op. Cit.], del enunciado del problema (1.1) se extraen
los sujetos; en este caso: elementos(s) de la interfaz gráfica.
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.
Botones gráficos, como el que indica si una cita es repetitiva, si tiene alarma o si
tiene una nota anexa.
114
Botones, como el de añadir una cita (Nuevo - ) o el que permite ver los
detalles de alguna cita existente.
Flechas de desplazamiento ( ), para cambiar de día de la semana, o para
desplazarse a lo largo de las citas de un día.
El botón “Nuevo” remite al usuario a otra pantalla (una nueva forma) que se
muestra en la Figura 4.4, donde aparece un nuevo objeto: la lista de las horas y
minutos en los que puede ocurrir la cita.
115
Por último, el botón “Nota” despliega la forma de la Figura 4.6, en donde se puede
escribir texto en forma libre. Si la pantalla se llena (como en el ejemplo), se habilita
la barra de desplazamiento que aparece a la derecha de la imagen.
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.
116
Todas las formas tienen un menú, y al menos una forma adicional asociada, en
donde se muestran datos como la leyenda de derechos reservados y el logo de
Palm, así como la versión de la aplicación (Figura 4.8)
117
Figura 4.9 Catalogo del Constructor
118
El siguiente paso consiste en descartar clases redundantes, irrelevantes o vagas.
Para llevarlo a cabo, es necesario definir claramente lo que cada objeto
representa. Este paso implica también, iniciar otra de las actividades
recomendadas por Rumbaugh [op. cit.]: la construcción del Diccionario de datos.
Objeto Definición
Forma Contenedor visual de elementos de la interfaz gráfica.
Normalmente una forma representa una sola pantalla de la
aplicación.
Formas Adicionales Variantes de forma, pueden ser Alertas: formas
desplegables que presentan información al usuario, Formas
de información del producto (Acerca de), etc.
Form Sinónimo de Forma
Menú Elemento de la interfaz de usuario que permite al usuario
ejecutar comandos seleccionándolos de una lista que se
despliega en la parte superior de la pantalla.
Botón Objeto de la interfaz gráfica usado para ejecutar comandos
frecuentes o pasar de una forma a otra, dentro de la
aplicación
Botón gráfico Botón que se representa en la pantalla mediante una imagen
asociada
Button Sinónimo de Botón
Graphic Button Sinónimo de Botón gráfico
Push Button Objeto usado junto con otros similares, formando un grupo
para permitir la selección de uno y solo uno de ellos.
Similar en su funcionamiento a los botones de selección de
estaciones de un radio.
Repeating Button Objeto que envía señales continuas mientras el usuario lo
mantiene presionado.
Graphic Push Button Objeto cuya funcionalidad es resultado de la combinación de
los botones push y gráfico
Graphic RepeatingObjeto cuya funcionalidad es resultado de la combinación de
119
Button los botones repeating y gráfico
Check box Elemento de la interfaz de usuario que despliega una caja
que puede estar seleccionada (x) o no ( ) y que tiene
asociada una cadena de texto.
Campo Elemento de la interfaz de usuario que sirve para desplegar
y editar texto
Campo texto comoCampo que cumple con la misma funcionalidad que un
botón botón.
Campo texto paraSinónimo de Campo
desplegar datos
Field Sinónimo de Campo
Graffiti Shift Indicator Pequeño icono, normalmente localizado en la esquina
inferior izquierda de la pantalla y que indica el estado del
mecanismo de entrada de datos (mayúsculas, puntuación,
etc.)
Flecha que indicaSinónimo de Graffiti Shift Indicator
mayúsculas
Etiqueta Elemento de la interfaz gráfica que contiene texto estático.
Label Sinónimo de etiqueta.
Lista Elemento de la interfaz gráfica que muestra varios renglones
de datos en una sola columna y de la que el usuario puede
hacer una selección
List Sinónimo de Lista
Tabla Elemento de la interfaz gráfica formado por renglones y
columnas que pueden, a su vez, contener otros objetos y
que permite al usuario trabajar con estos.
Barra deElemento de la interfaz gráfica que facilita el desplazamiento
desplazamiento sobre campos de texto y tablas, informando la posición
aproximada del cursor dentro de aquel objeto
Scroll Bar Sinónimo de barra de desplazamiento
Slider Control Elemento de la interfaz gráfica que permite mover el cursor
120
de la barra de desplazamiento. Es parte de la Barra de
desplazamiento
Flecha de Sinónimo de Slider Control
desplazamiento
Feedback SliderElemento de la interfaz gráfica que muestra la posición
Control aproximada del cursor de la barra de desplazamiento dentro
del campo o lista asociado a esta.
Combo No se puede encontrar una definición exacta para este
objeto.
Popup Trigger Elemento de la interfaz gráfica que despliega la selección
actual de una lista (normalmente oculta) y la propia lista
cuando es seleccionado
Selector Trigger Elemento de la interfaz gráfica que consiste en una caja
dentro de la que se despliega (y permite editar) texto
Gadget Elemento de la interfaz gráfica cuyas características y
comportamiento son totalmente modificables por el
programador.
No es un objeto que este bien definido.
Finalmente, los objetos con los que se empezará a realizar el modelo se reducen a
la siguiente lista:
Forma
Menú
Botón
Checkbox
Campo
Graffiti Shift Indicator
Etiqueta
Lista
Tabla
Barra de desplazamiento
121
PopupTrigger
SelectorTrigger
La frase: “... cada forma es una colección de otros objetos” indica que el objeto
forma CONTIENE otros objetos.
122
(Left Origin), Coordenada Superior de Origen (Top Origin), Ancho, Alto,
Identificador de la Forma (Form ID), Identificador de la barra de Menú (Menú Bar
ID) y Titulo de la Forma (Form Title). La siguiente tabla muestra los atributos de
cada objeto, obtenidos del Constructor.
Propiedades Objetos
1 2 3 4 5 6 7 8 9 10 11 12
Identificador de la Forma x
Identificador de la Barra de Menú x
Identificador del Botón por defecto x
Titulo de la forma x
Nombre del Objeto x x x x x x x x x x
Identificador del Objeto x x x x x x x x x x
Coordenada de origen (Izquierda) x x x x x x x x x x x
Coordenada de origen (Superior) x x x x x x x x x x x
Ancho x x x x x x x x x x
Alto x x x x x x x x x x
Bandera que indica si el objeto se usa o no. x x x x x x x x x x
Bandera que indica si todos los eventos afectan a la forma x
Bandera que indica si se debe almacenar temporalmente la x
información que quedará oculta por la forma
Bandera que define la forma en que se debe desplegar el texto x
(Anchor Left)
Bandera que indica si el objeto tiene borde x
Bandera que indica si el texto del objeto se desplegara en x
Negritas
Bandera que indica si el objeto se dibuja seleccionado la x
primera vez
Bandera que indica si el campo es editable x
Bandera que indica si el campo esta subrayado x
Bandera que indica si el campo se desplegará en un sola línea x
(independientemente de su tamaño)
Bandera que indica si el tamaño del campo puede cambiar x
Bandera que indica si el texto del campo se desplegará x
justificado a la izquierda
Bandera que indica si el primer carácter del campo se escribe x
en mayúscula
Bandera que indica si el campo tiene Barra de desplazamiento x
Bandera que indica si el campo recibirá solo caracteres x
numéricos.
Propiedades Objetos
1 2 3 4 5 6 7 8 9 10 11 12
Nombre de la Fuente que se usará para desplegar Texto x x x x x x
Etiqueta que se dibujará en el objeto x x x x x
123
Identificador del grupo al que pertenece el objeto x
Número máximo de caracteres que se pueden escribir en el x
Campo
Nombre de la Fuente que se usará para desplegar Texto x
Número de renglones que serán desplegados x
Lista de textos a desplegar x
Número de Filas x
Lista de anchos de columna x
Valor actual x
Valor mínimo x
Valor máximo x
Tamaño de página x
Bandera que indica si el tamaño del campo puede cambiar x x
Identificador de la lista a la que esta asociado el objeto x
Etiqueta del Menú x
Lista de elementos del Menú x
(1) Forma
(2) Botón
(3) Checkbox
(4) Campo
(5) Graffiti Shift Indicator
(6) Etiqueta
(7) Lista
(8) Tabla
(9) Barra de desplazamiento
(10) PopupTrigger
(11) SelectorTrigger
(12) Menu
124
IV.6.1.7 Refinamiento del modelo usando herencia
Como se puede observar, la mayoría de los objetos comparten los siguientes
atributos:
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.
Como se indicó, prácticamente todos las clases descienden de una clase base
(cComponenteVisual). Además, la clase cLista contiene una instancia de la clase
125
cPopupTrigger (que sirve para desplegar la lista). Las clases cCampo y cTabla
contienen ambas una instancia de la clase cBarraDeDesplazamiento.
126
Figura 4.13. Caso de Uso MV1B. El Usuario o el PalmOS finalizan la aplicación:
127
Figura 4.14 Diagrama de flujo de eventos del caso de uso Arranque y finalización de una
aplicación.
128
#ifndef CIGCHECKBOX_H
#define CIGCHECKBOX_H
#include "clabeledobject.h"
#include "cstring.h"
// Associations
// Attributes
private:
Boolean selected;
UInt8 groupID;
// Operations
public:
Boolean isSelected ( );
UInt8 getGroup ( );
};
#endif
129
void cIGcheckBox::select ( Boolean valor ){
selected = valor;
Boolean cIGcheckBox::isSelected ( ){
return selected;
Ambos métodos hacen uso del atributo selected que es de tipo boléalo, por lo que
solo pude tener dos estados: verdadero o falso.
IV.6.1.10 Iterar
Otra recomendación de Rumbaugh [Ibíd.] es iterar el proceso a fin de refinar el
diagrama. Después de varias iteraciones, se obtiene el diagrama de la Figura 4.23
que contiene prácticamente todos los elementos que se van a usar en el proyecto.
130
Plantilla para el Diagnóstico Individual de Enfermedades
...
...
131
síntomas, que el paciente presente y que no haya referido. Se deberá preguntar
solo por aquellos que se encuentren a los lados de los orificios que ya fueron
tachados con X, y no estén marcados. Se empezará siempre con el primer renglón
de arriba hacia abajo y de izquierda a derecha.
...
Padecimientos
132
Signos
Síntomas
Diagnósticos
Molestias
Plantilla
1
Definiciones obtenidas del Diccionario Terminológico de Ciencias Médicas
133
Padecimiento se manejan como
sinónimos.
Molestia Sinónimo de Signo
Plantilla Tabla bidimensional.
En el caso de estudio, se trata de una
matriz de 43 columnas (Síntomas) y 24
líneas (Padecimientos probables)
Para definir la forma en que se compone la plantilla, se usa una frase más:
134
almacenar el nombre del dato. Por otro lado, la clase que modele a la plantilla
debe incluir objetos diagnóstico y síntoma.
Con todos estos elementos, se puede construir una primera versión del diagrama
de clases del Modelo (Figura 4.15).
135
cModelo aplica algoritmo para encontrar posibles padecimientos
cModelo muestra lista de posibles padecimientos encontrados.
136
inicial
1.1.2 Señalar en la caja correspondiente, la molestia referida
2. Almacenar en arregloSintomas, la clave del síntoma, la bandera
“presente”
1.1.4 Si no hay mas molestias, ir al paso 2
1.1.5 Volver a 1.1.1
2. Para cada elemento de arregloSintomas:
2.1 Almacenar el numero de síntoma en la variable claveSintoma
2.2 Recorrer la matriz plantillaDiagnostico
2.2.1 En el n-simo renglón
2.2.1.1 Si la columna con número claveSintoma tiene almacenado un valor
mayor que 0.
(El síntoma esta presente en el padecimiento)
2.1.1.1.1 Recorrer el renglón. Si la columna tiene almacenado un 1
2.1.1.1.1.1 Almacenar en arregloSintomas la clave del síntoma,
bandera “desconocido”
2.3 Almacenar en bandera el valor “agotado”
3. Para cada elemento de arregloSintomas:
3.1 Si la bandera es “desconocido”
3.1.1 Mostrar la pantalla que corresponde al Síntoma
3.1.2 Almacenar la respuesta (en bandera) como “presente” o “ausente”,
según la respuesta del paciente
4. Recorrer la matriz plantillaDiagnostico
4.1 En el n-simo renglón
4.1.1 Recorrer el renglón. Si la columna tiene almacenado un numero mayor
que 0
4.1.1.1 Localizar el Síntoma cuya clave corresponda al numero de columna
de plantillaDiagnostico
4.1.1.2 Si la bandera del síntoma es “ausente” y en plantillaDiagnostico
el valor es 1 (obligatorio), entonces el padecimiento no existe.
Regresa a 4.1
4.2.1 Si se llegó al fin del renglón, el padecimiento si existe. Almacenar
en arregloPadecimientos
4.2.2 Regresa a 4.1
5. Desplegar pantalla resultados.
6. Para cada elemento en arregloPadecimientos. Desplegar el nombre del
padecimiento.
137
Se requiere de una clase cArregloSintomas, cuyo método almacenarSintoma, se
describe a continuación:
1. Recorrer arregloSintomas, buscando la clave del síntoma
138
No hay disponible, hasta esta versión de Codewarrior, un mecanismo similar
orientado a objetos. Pero, como se mencionó en el Capítulo 1, es posible modelar
objetos con C a través del uso de estructuras.
139
static void MainFormInit(FormPtr /*frmP*/)
Esta función inicializa la forma MainForm
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.
140
Figura 4.21 Modelo de objetos del Controlador
141
Flujo alterno MC01B. Usuario termina la aplicación.
Ocurre el Caso de Uso MV1B. Usuario o el PalmOS finalizan la
aplicación
2. Obtiene del objeto de cForma el identificador del campo de texto etiquetado como “Pregunta”
4. Cambia el contenido del objeto cCIGcampoTexto, para que muestre la pregunta actual.
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.
142
Figura 4.23 Diagrama de clases de la Vista.
CONCLUSIONES
La pregunta central planteada al inicio del presente trabajo fue si es posible aplicar
una metodología de Análisis y Diseño de Sistemas que considere las limitaciones
de una plataforma como las PDAs para desarrollar aplicaciones de Cómputo
Móvil.
145
Aplicar la metodología resultó útil porque facilitó enormemente el proceso de
desarrollo de una aplicación Palm, permitiendo separar la implementación del
modelo de la interfaz gráfica, de la del dominio del problema. Además de otras
ventajas que saltan a la vista: se puede reutilizar todo el diseño (y el código) de la
vista, y una buena parte del controlador.
El patrón de diseño Modelo Vista Controlador resultó también una buena elección,
por que las aplicaciones en Palm se implementan en forma muy aproximada al
mismo, ya que dependen completamente de la interacción con el usuario. Como
se pudo observar, el desarrollo de las aplicaciones para Palm inicia con el diseño
del componente visual (la vista) de las mismas, y basandose en los resultados
obtenidos, es factible pensar que diferentes dominios de aplicación se pueden
acoplar de forma relativamente sencilla diseñando nuevos modelos.
146
Esto demuestra las bondades de seguir una metodología de objetos. Pasar de un
área de conocimiento como la Medicina a otra totalmente diferente, de tipo
económico, no afecta en ningún modo a modelo de la Vista. El desarrollador de
aplicaciones Palm simplemente debe crear instancias nuevas, enfocadas al nuevo
dominio de aplicación.
a. Regresar al inciso a)
Otro factor que puede influir en la forma en que una aplicación se ejecuta, es la
cantidad de memoria libre con la que cuente el dispositivo; mientras mas memoria
147
libre exista, las operaciones de administración del PalmOS se realizan mas
fácilmente, y las aplicaciones se ejecutan más rápido.
Por tanto, se ha optado por utilizar otras métricas, como el número de líneas de
código, el porcentaje de instrucciones del lenguaje contra el total del código, etc.
Aprovechando el hecho de que existe una versión del SVES que fue desarrollada
sin usar una metodología específica, se aplico a ambas versiones el programa
c_count (http://invisible-island.net/c_count/) obteniéndose, entre otros, los
siguientes resultados:
148
7952 tokens, average length 8.66 21 6 |cusableobject.h
215 63 |precord.cpp
0.23 ratio of comment:code 67 39 |precord.h
756 ?:illegal characters found 655 121? |starter.cpp
----------------
3308 988? total lines/statements
149
Otras ventajas del esquema propuesto tienen que ver con la facilidad de
adaptación a cambios. Permitir que las aplicaciones desplieguen video, por
ejemplo, requiere solamente añadir la clase correspondiente a la Vista.
Nuevamente, este hecho implica que un cambio mayor, como podría ser migrar de
plataforma (generar una versión de la aplicación para una plataforma que no
maneje el PalmOS como su sistema operativo), requiere recodificar solo las clases
de la Vista y algunas partes del controlador, sin tener que tocar ninguna clase del
Modelo.
Trabajo futuro.
Se 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.
150
conocimiento del experto se podría crear una aplicación administradora de
modelos.
151
BIBLIOGRAFÍA
RUMBAUGH, James, et. al. MODELADO Y DISEÑO ORIENTADO A OBJETOS.
Metodología OMT. México: Prentice Hall, 1996.
153
DICCIONARIO DE INFORMÁTICA. 2ª edición. México: Diaz de Santos, 2000.
CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (I)”. En: SOLO
PROGRAMADORES. Madrid, España. (82 - 09 – 2001). 7-10.
CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (II)”. En: SOLO
PROGRAMADORES. Madrid, España. (83 - 10 – 2001). 52-56.
CONCEIRO IGUERRI, Alex, et. al. “Programación Palm (y III)”. En: SOLO
PROGRAMADORES. Madrid, España. (84 - 11 – 2001). 26-31.
154
ÉRDI Gergõ. GUIKACHU. feshmeat.net, 02/03/2001
http://cactus.rulez.org/projects/guikachu/
155
KORGAONKAR, Sachin. DESIGN PATTERNS. 04/09/2002.
http://www.developersdiary.com/patterns.asp
FRYE, Jason. PATTERNS HOME PAGE. The Refactory, Inc., The Hillside Group.
Junio, 2002
http://hillside.net/patterns/
156
WHEELER, Sarah. THE MODEL-VIEW-CONTROLLER ARCHITECTURE. CERN.
Organización Eruopea para la Invetigación Nuclear, 30/08/1996.
http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
BAKKER, Gerbrand, et. al. OMT OBJECT MODEL. Université Paris, 09/02/1996.
http://panoramix.univ-paris1.fr/CRINFO/dmrg/MEE/misop007/index.html
157
LIBRARY OF THE NATIONAL MEDICAL SOCIETY. The National Medical
Society, Diciembre, 2002.
http://www.medical-library.org/index.htm
158
ANEXOS
159
A.1 Plantilla del SVES
Como se mencionó, la información sobre el Sistema de Vigilancia Epidemiológica
Simplificada (SVES) utilizada en el presente trabajo se obtuvo del documento
llamado Manual para la vigilancia epidemiológica simplificada.
Según menciona el sitio web de la Secretaría de Salud este documento puede ser
consultado en su Centro de Documentación Institucional, localizado en la Calle de
Lieja No. 7 Primer Piso, Col. Juárez. Del. Cuauhtémoc. Tel. 5553-7184
Au: Alvarez Lucas, Carlos; Ferreira Guerrero, Elizabeth; Et al. Au: México.
Secretaría de Salud. Dirección General de Epidemiología.
Ti: Manual para la vigilancia epidemiológica simplificada/Manual for simplified
epidemiologic surveillance.
Fu: México, D.F; México. Secretaría de Salud; s.f. <42>p.
Re: Este manual tiene como propósito el de servir de apoyo al médico responsable
del sistema de vigilancia epidemiológica en el ejercicio de sus funciones en lo
concerniente al registro y notificación de los problemas de salud que afecten a su
comunidad, para referir a los diferentes centros de salud a las personas que
requieran de atención médica. Contenido: Introducción. 1)Antecedentes. 2)Marco
teórico: factores condicionantes; sistemas de vigilancia epidemiológica,
información convencional y no convencional; aspectos epidemiológicos.
3)Justificación. 4)Objetivos. 5)Límites. 6)Sistema de vigilancia epidemiológica
simplificada: padecimientos incluidos, componentes, organización estructural,
160
asignación de responsables y funciones, flujo de información, bases legales y
normativas. 7) Capacitación, supervisión y evaluación. Anexos.
Ub: MX10.1/6097.
161
162
A.2 Contenido del CDROM
El CD que acompaña este documento contiene, entre otras cosas:
163