1. 1

2. En la actualidad la web ha impactado de manera significativa la forma en la que las personas
acceden y distribuyen la información. A su vez, la web ha repercutido en los paradigmas de
diversas áreas de la ciencia, y en particular de las ciencias de la computación. La simulación
por computadora no pudo escapar al impacto de la red de redes y vislumbrar posibles
extensiones de ella a través de la web. De esta forma nace la simulación web, como necesidad
de la simulación por darse un nuevo aire y expandirse. Este trabajo se enfoca en el desarrollo
de una aplicación web que está relacionada con la simulación de modelos dinámicos de
nutrición animal mediante métodos numéricos, los cuales son producidos a través de un
proceso de preprocesamiento de archivos generados por un software de simulación local (en
PC). De esta forma, el propósito general de este trabajo es la comentar el proceso de desarrollo
de una aplicación web, en particular esta de simulación que ha sido denominada SymWeb por
“Simulación y Modelado vía Web”. En la primera sección, los preliminares, están comentarios
breves sobre los tipos de modelos matemáticos usados en la simulación y su relación con el
área bovina; además está una pequeña explicación de cómo realizar modelos matemáticos con
Stella, el software de modelado matemático del que se extrae los archivos fuente para
utilizarse en la aplicación web. En la revisión de la literatura, es presentada la información
explicativa de lo que la simulación web, sus principios e impactos, y aspectos críticos que
deben considerarse durante la creación de un proyecto de simulación en general. Después, en
la sección de métodos, se encuentra narrado el proceso de ingeniería de hipermedia utilizado
para el desarrollo de ésta aplicación. Posteriormente se hace una pequeña discusión sobre el
contenido del marco teórico presentado en la sección de revisión de la literatura para enfatizar
aspectos personales del realizador de este trabajo y señalar la diferencia entre la teoría ideal y
vivir un proyecto de simulación web. Para concluir, conclusiones y recomendaciones sobre el
trabajo realizado, en los que se señalan puntos importantes que afectaron el desarrollo de la
aplicación y se presentan comparaciones sobre los resultados de simulación efectuados con la
aplicación web y el software de simulación para PC. Como anexo, son presentados los listados
del código fuente de las páginas más importantes que componen SymWeb como referencia a
futuras modificaciones o extensiones.
2

3. 3

4. “Las funciones biológicas en los seres vivos pueden cuantificarse y representarse mediante el
proceso denominado ‘simulación de modelos’. El modelado en la producción animal permite
reproducir los diferentes procesos digestivos y metabólicos que se llevan a cabo dentro del
animal para así estudiarlos con una base cuantitativa y dinámica a más bajo costo que en la
investigación pecuaria convencional” (Ku, 2000).
La cita anterior resume en sí la importancia del modelado matemático y la simulación
por computadora en las ciencias veterinarias. De esta idea surge el proyecto de la creación de
un simulador de modelos matemáticos veterinarios disponible para todos que se presenta en
este documento intitulado “Desarrollo de un Programa Web para la Simulación de Modelos
Dinámicos Ligados a Base de Datos”.
2.1 Modelado Matemático y Simulación por Computadora
Comencemos explicando lo que es el modelado matemático. La manera en la que Ku (2000)
explica el concepto de modelo matemático y simulación sin duda se adapta muy bien a nuestro
contexto y es clara:
“Debido a que las funciones biológicas están determinadas por dinámicas cuantitativas que
son factibles de representarse matemáticamente, es posible mediante un procedimiento
llamado simulación, describir matemáticamente este proceso. A la representación matemática
y esquemática de este proceso se le llama modelo”. En sí, el modelo consiste en especificar un
problema, desarrollar las relaciones conceptuales entre sus entidades y representarlas
cuantitativamente (Taffe, 1991).
En palabras un poco más coloquiales, podemos decir simplemente que un modelo matemático
es una representación aproximada de la realidad. La realidad, tal y como la vivimos, es muy
compleja y llena de detalles por lo que no podemos modelarla en su totalidad. No es que
existan modelos malos, sino que existen modelos con diferentes “enfoques”. Entenderemos lo
anterior en un sentido subjetivo, por lo que interpretaremos la palabra “enfoque” como lo útil
que es el modelo según lo que se quiera simular. De lo anterior encontramos que existe una
relación entre la palabra modelado y la palabra simulación. Según Taffe (1991), la simulación
puede ser explicada como la acción que “resuelve” la matemática de varias entradas y para
una variedad de parámetros. De manera simple podemos entender que un modelo tiene un
conjunto de entradas que al ser “procesadas” por el modelo nos otorgará una o varias salidas.
Entonces podemos decir simular que es “hacer trabajar al modelo para que de salidas con base
a sus entradas”. Aquellos valores de modelo que al ser cambiados influyen en lo que
obtengamos por salidas, son llamados parámetros.
Es fácil que nos imaginemos los modelos como un conjunto de ecuaciones extrañas con
muchas entradas y parámetros. Es importante que sepamos que no siempre es así, a veces
existen modelos de una sola ecuación y de un solo parámetro. Lo que sí podemos afirmar es
que en muchos de los casos es un poco “engorroso” hacer las simulaciones de forma “manual”
porque es posible que las operaciones sean muy complicadas de resolver de esta forma. Ahora
4

5. con el avance tecnológico, y en particular el de la computación, es fácil que consideremos la
forma de “resolver los modelos en la computadora”. De forma un poco más propia: “Simular
los modelos en la computadora”. Esto es el área de las ciencias de la computación que se
conoce como Simulación por Computadora, que en palabras de Fishwick (1995) nos define la
simulación por computadora como “la disciplina de diseñar un modelo de un sistema físico
actual, ejecutando el modelo en una computadora digital, y analizando la salida de la
ejecución”.
Los modelos pueden ser clasificados (Box, et al. 1999, Heylighen, 2000 y Chí, 2000) según
sus características, los cuales pueden ser:
• Formales: Tales como lo son las expresiones matemáticas, los diagramas, las tablas,
etc.
• De juicio: Formados por una serie de deducciones y afirmaciones contenidas en la
mente de un experto.
• Causales: Reflejan relaciones de causa y efecto.
• Correlacionales: Los cuales no siempre revelan cuando un fenómeno observado es
causado por otros.
• Determinísticos: Aquellos que generan la respuesta de una entrada dada por una ley
fija.
• Estocásticos: Aquellos que seleccionan la respuesta del conjunto de las posibles
respuestas de acuerdo a una distribución de probabilidad fija.
• Dinámicos: Describen fenómenos que suceden en el tiempo, los proceso dinámicos.
• Estáticos: Describen el sistema en un instante del tiempo y en un estado asumido de
equilibrio.
• Analíticos: Son los modelos matemáticos cuyas salidas se expresan en términos de
ecuaciones y variables.
• Numéricos: Son los modelos matemáticos cuyas salidas se obtienen a partir de aplicar
en ellos métodos numéricos para resolverlo.
• Mecanísticos: Están basados en una apreciación de la teoría física o mecanicista que
gobierna el proceso.
• Empíricos: Son modelos propuestos con base en el conocimiento del área, que se van
ajustando según resultados experimentales.
2.2 Modelos y bovinos
Los modelos que están relacionados con la producción bovina de carne extensiva en el trópico
son de carácter dinámico y mecanístico (Ku, 2000). Entre los modelos más completos y
conocidos encontramos el de Baldwin (1995) y el de Dijkstra (1992), siendo este último el
más usado en el trópico. Estos son modelos dinámicos para el estudio de la digestión ruminal.
Según Ku (2000), otros aspectos a considerar en el desarrollo de modelos de digestión y
metabolismo en el trópico son el consumo voluntario, potencial de animal, aspectos
hormonales y balance de calor que influyen directamente sobre la dinámica de crecimiento en
ambientes tropicales. También nos comenta en la justificación del desarrollo de modelos
matemáticos que la “ausencia de un sistema de alimentación para bovinos en pastoreo en el
5

6. trópico en nuestro país es una de las grandes dificultades a las que se enfrenta el productor
pecuario. Con un sistema de alimentación mexicano se podría mejorar la exactitud de los
proyectos de inversión en el campo y por ende el interés de los inversionistas en éste. Por otro
lado, los modelos en rumiantes han sido elaborados principalmente para zonas templadas, sin
embargo son factibles de ser transformados para adaptarlos a la situación particular de México
y el trópico”. De ahí que en la Facultad de Veterinaria y Zootecnia de la Universidad
Autónoma de Yucatán (UADY) encontremos personas trabajando con los modelos actuales
para estudiarlos, conocerlos y adaptarlos a las características de la región. El proyecto del
estudio y simulación de modelos en la UADY nos adentra como universidad en esta línea de
investigación.
La importancia del estudio y simulación de modelos según Ku (2000) está en que:
• Nos permiten obtener resultados de procesos biológicos, experimentar con pequeños
cambios en ellos y obtener nuevos resultados.
• Tienen un mayor impacto en los procesos productivos en México debido a que no
requieren de gastar muchos recursos para la investigación.
• Es más fácil estudiar las consecuencias biológicas de las conclusiones usando modelos
que cuando realizamos trabajos experimentales ya que estamos trabajando con seres
vivos.
• Nos permite explotar con mucha mayor claridad las nuevas teorías mucho antes de
llevarlas a la práctica a un costo muy bajo.
• Es muy difícil en México, y en general en los países subdesarrollados, tener la
infraestructura, los recursos humanos y económicos y la participación de los
productores pecuarios para realizar predicciones de ésta.
• Nos otorga la posibilidad como investigadores pecuarios en concentrarnos en otras
áreas de investigación de no tan bajo costo.
En conclusión: “los modelos dinámicos son importantes en el estudio de nutrición y
especialmente en la dinámica de la digestión y metabolismo para simular el aumento de peso
de la producción en rumiantes del trópico... Con pocos recursos el modelado es capaz de
demostrar cambios en el comportamiento productivo de los animales y de formar en los
alumnos el concepto cuantitativo de eficiencia”. Añadimos también: “Lo anterior es una
necesidad urgente en la preparación de los estudiantes de nutrición de rumiantes en México
debido, principalmente, a que la producción está basada en el pastoreo, lo cual dificulta más el
estudio de la dinámica digestiva ya que no se conoce el consumo animal. Además, debido a las
condiciones típicas del trópico existen factores que modifican las curvas de crecimiento, las
cuales sin lugar a dudas podrían ser mejor estudiadas con una herramienta como es el
modelado” (Ku, 2000).
2.3 Software para Modelado y Simulación
6

7. Para realizar los modelos matemáticos, es posible que nos auxiliemos de un software de
modelado matemático. Existe gran variedad de software de este tipo como lo es el Mathlab
(Mathworks, 2002) u otros especializados en sistemas dinámicos como el Dynamo
(Rirchardson, 1981) o el Stella (HPS, 2000). Este último es el que encontramos disponible en
la universidad y sirve muy bien para el modelado biomatemático, además presenta una interfaz
gráfica para realizarlo y que además ayuda al aprendizaje de este concepto. El software Stella
nos introduce el concepto de simulación a través del diseño de modelos mediante iconos,
además de que es un lenguaje no procedural de tal forma que el modelador describe el sistema
con base en éstos (Taffe, 1991 y Steed, 1996).
Figura 1. Entorno de aplicación de Stella
La manera en la que hacemos modelado en Stella es utilizando sus cuatro descriptores
básicos para modelar que son representados, como ya mencionamos, de manera iconográfica:
• Stock. Repositorio. Sirve para atribuir las cantidades que existen de las entidades (e.g.
número de venados).
• Flow. Flujo. Representa el cambio en el tiempo del contenido del stock. Los flujos
pueden ser de entrada (aumento de cantidad) o de salida (pérdida de cantidad).
• Converter. Convertidor. Permite atribuirle cálculos relacionados con las entidades con
lo que se realizan cambios de los valores de entrada para devolver una salida.
• Connector. Conector. Hace la conexión entre los repositorios y los flujos. Esto es
equivalente a decir que establece la relación entre la entidad y su cambio con respecto
al tiempo.
Figura 2. Barra principal de botones para modelado de Stella. Los
cuatro primeros iconos corresponden a los descriptores básicos.
7

8. Según comenta Steed (1996), una de las funciones únicas de este software es la opción de
graficar (séptimo icono de la figura anterior de izquierda a derecha). Así, podemos dibujar
gráficas en Stella donde veamos el comportamiento de una entidad con respecto al tiempo o la
relación entre dos entidades. La forma en la que hace esto el software es usando ecuaciones
diferenciales, les aplica un método numérico y corre la simulación. También se pueden
presentar los resultados en forma tabulada.
Para resolver las ecuaciones diferenciales, Stella usa por defecto el método de Euler, aunque
también puede utilizar el método Runge-Kutta de segundo y cuarto orden (Sánchez et al.,
1983).
Cómo nos menciona Taffe (1991), la mejor manera de explicar cómo funciona Stella es a
través de un sencillo ejemplo. Tomaremos entonces su ejemplo propuesto (el de crecimiento
poblacional) para ir mostrando como usar de este software. Este modelo se describe fácilmente
como el estado de la población con el flujo de entrada por parte de los nacimientos (aumento
de población) y el flujo de salida debido a las muertes (disminución de la población).
Figura 3. Modelo de crecimiento poblacional realizado en Stella en
modo mapa.
En la figura anterior tenemos el modelo de crecimiento poblacional ya realizado en Stella.
Debido a su naturaleza de interfaz gráfica, básicamente lo que hacemos es hacer clic en el
botón que tiene el icono que deseamos utilizar, posicionamos el mouse en el lugar deseado del
área de trabajo y hacemos clic para que el elemento se cree. En casos como el del flujo y el de
los conectadores, tenemos que arrastrar desde el elemento inicial (e.g. el stock de la
población) hacia el elemento final (e.g. el flow de muertes).
8

9. Figura 4. Cambio de modo mapa a modo modelo.
Pasamos al modo modelo, el cual nos presenta lo mismo que el modo mapa (cuyo propósito es
únicamente la visualización del modelo), en donde se nos obliga a asignar los valores
correspondientes a las entidades o definir los cálculos u operaciones que se van a realizar entre
ellas. Cuando existan elementos en el modelo en los que no se ha trabajado (no tienen ninguna
asignación), el software nos presentará un signo de interrogación dentro del mismo elemento
(véase la siguiente figura). Para modificar los elementos entonces hacemos doble clic en ellos.
Figura 5. Modelo de crecimiento poblacional en modo ecuación sin
asignaciones.
A continuación queremos indicarle al Stella que los nacimientos representan el 3% de la
población. Por lo explicado anteriormente, hacemos doble clic en nacimientos y procedemos a
definir el cálculo. Como población está conectada a nacimientos, será necesario hacer uso de
la entidad población; por eso decimos que los conectadores establecen relaciones.
9

10. Figura 6. Asignación para el flujo de nacimientos del modelo de
crecimiento poblacional
De manera similar, hacemos doble clic en el stock de población para asignarle el valor de 500
que será considerado de esta manera como el valor inicial.
Figura 7. Asignación del valor inicial en el modelo de crecimiento
poblacional
Supongamos que los fallecimientos son el 1% de la población. Procedemos a realizar esta
asignación de manera similar a como lo hicimos en el flujo de nacimientos. Luego, mediante
la opción Time Specs... del menú Model, especificamos los valores del tiempo inicial y final,
así como la diferencial del tiempo que representa la cantidad que cambia conforme el tiempo
avanza (i.e. que tanto flujo sale o que tanto flujo entra). También seleccionamos en esta opción
la unidad de tiempo que usaremos y el método de integración para resolver el modelo (e.g.
método de Euler), etc.
10

11. Figura 8. Especificaciones de tiempo para el modelo de crecimiento
poblacional
Ahora usaremos la función de graficación de Stella para ver los resultados. De nuevo,
hacemos clic en el icono que corresponde al graficador. Luego hacemos clic en cualquier lugar
del área de trabajo para crear el elemento gráfica y un doble clic para abrir la gráfica. Doble
clic en cualquier parte de ella para obtener la lista de elementos disponibles para graficación.
Figura 9. Opciones de graficación.
Por último seleccionamos los elementos a graficar, aceptamos y al regresar seleccionamos la
opción Run del menú Run.
11

12. Figura 10. Gráfica de la población, nacimientos y muertes del modelo
de crecimiento poblacional
Aunque Stella es un software de interfaz gráfica, también nos permite ver y trabajar con las
ecuaciones de manera textual.
Figura 11. Cambio del nivel de ecuaciones al nivel de modos mapa y
modelo
Así, tenemos que en el nivel de ecuaciones se nos muestra:
12

13. Figura 12. Ecuaciones del modelo de crecimiento poblacional
De donde vemos claramente la ecuación que se resuelve (al menos con el método de Euler)
que en sencillas palabras la interpretamos como el número de individuos de la población en un
tiempo determinado es igual al numero de individuos de la población en el tiempo anterior
más el incremento de nacimientos menos el decremento de muertes. Después pasamos a
realizar la asignación inicial (i.e. INIT) de la población con el valor de 500. Inmediatamente
encontramos la determinación de los flujos con nacimiento igual al 3% de la población y
muertes igual al 1% de la población respectivamente.
Por otra parte, podemos distribuir en la ventana las ecuaciones del modelo según la manera en
la que se van a ir resolviendo. Para lograr esto, una vez que estamos en el modo de ecuaciones
seleccionamos la opción Equation Prefs.... del menú Equation. Una vez estando en las
preferencias de las ecuaciones, le indicamos que nos muestre las ecuaciones en orden de
ejecución (order of execution) y aceptamos.
Figura 13. Instrucciones para mostrar las ecuaciones en orden de ejecución
Ahora las ecuaciones se nos presentan de la siguiente manera:
13

14. Figura 14. Ecuaciones del modelo de crecimiento poblacional
presentadas en orden de ejecución
En este caso, el listado de ecuaciones comienza ahora con la iniciación del stock de la
población para pasar a la definición de los flujos de nacimientos y muertes. En el siguiente
bloque están entonces las ecuaciones como se irán resolviendo en tiempo de ejecución.
Primero se define la cantidad de individuos de la población para un instante en el tiempo,
después vuelven a definirse los flujos. El segundo bloque se encuentra así porque la
simulación comienza a correr para el tiempo cero t0 (sea cual sea su valor) y los valores
iniciales (tanto del stock como de los flujos) se definen para este tiempo en el primer bloque.
A partir de este momento las iteraciones hasta el tiempo final tn se realizan en el segundo
bloque. Al final se tendrá todos los valores que tomaron la población, los nacimientos y las
muertes desde el tiempo t0 a tn en incrementos de dt. Estos son los resultados que se grafican.
Los modelos en Stella tienen la ventaja de que se pueden exportar sus ecuaciones a archivos
de texto ASCII. Para realizar esa exportación debemos estar en el nivel de ecuaciones y
entonces seleccionar la opción Save as Text... del menú File. Luego, una ventana típica de
guardado de archivos de Windows se nos presenta, procedemos a seleccionar la ubicación de
almacenamiento y darle nombre al archivo de texto que contendrá las ecuaciones. Aceptamos.
14

15. Figura 15. Almacenamiento de las ecuaciones de un modelo de Stella
en un archivo de texto
La manera en la que nuestro modelo de crecimiento poblacional fue almacenado en el archivo
de texto es la siguiente:
Figura 16. Ecuaciones del modelo de crecimiento poblacional en un
archivo de texto ASCII
Como el paquete de software nos brinda entonces las ecuaciones en un medio de fácil acceso
como lo es un archivo de texto, es posible que hagamos uso de éstas para poder llevar a cabo
la simulación en otro ambiente, tal como lo es la Web.
15

16. 16

17. 3.1 La Hipermedia y la World Wide Web
La hipermedia se define como el conjunto de aplicaciones (software para uso específico) que
son producto de la combinación del hipertexto (el texto que posee ligas) y multimedia (la
generación de sonidos y gráficos en la computadora).
Las páginas web en la actualidad son una combinación del hipertexto con el que originalmente
fueron concebidas y a su vez elementos multimedia. Así, las presentaciones, discos compactos
interactivos (como las enciclopedias en CD) y las páginas web pueden ser consideradas como
hipermedia.
A principios de la “era web”, las páginas transmitidas mediante el protocolo HTTP (W3C,
2002b) eran prácticamente “estáticas”. Por “estáticas” debemos entender que éstas son
desplegadas por los visores web o browsers tal y como se encuentran estructuradas dentro de
su código HTML (W3C, 2002a) sin modificación alguna; no existen en ellas funciones de
personalización o despliegue de menús secundarios tal como vemos hoy en la mayoría. No
tiene que ver con el hecho de que podamos encontrar animaciones o sonido en el contenido de
las páginas, eso está más relacionado con el diseño de interfaz de usuario y no con su
estructura interna. Cuando tenemos una colección de páginas con una interfaz consistente y
relacionadas a través de ligas o links entonces hablamos de un sitio. Como usuarios es muy
natural el navegar dentro de un sitio si estamos acostumbrados a surfear la Web, ya que
aprendemos de forma “inconsciente” el poder distinguir entre dos sitios o bien, el cómo ir
navegando dentro de uno y también identificar elementos clave del contenido que sabemos
que no están disponibles para otros usuarios, como en el caso del correo electrónico. Cuando
páginas web poseen características como las antes mencionadas, éstas reciben el nombre de
páginas “dinámicas”. Existen varias formas para poder desarrollar este tipo de páginas; estas
formas reciben el nombre de tecnologías. Las tecnologías para la creación de páginas se
pueden dar de dos formas:
• Tecnologías para el cliente
• Tecnologías para el servidor
Como sabemos, nuestra máquina es el cliente que pide servicios a otra capacitada para
ofrecerlos (el servidor). Podemos hacer todas las combinaciones de estas dos formas para dar
paso a varios maneras de implementación con lo cual se puede desarrollar un sitio de páginas
“dinámicas”. Éstas son conocidas como arquitecturas (Fraternali, 1999). Las arquitecturas
pueden ser simples o múltiples. Usamos una arquitectura simple cuando tenemos el caso en
que un cliente pide información a una máquina que funciona de servidor. Pero podemos
encontrar los casos en el que el cliente pida la información a un servidor que a su vez
interactúe con otros, este es el caso de las arquitecturas múltiples. El término para expresar el
tipo de arquitectura que usamos es atadura y la palabra 1-atadura para llamar a una
arquitectura simple, y multi-atadura en el caso de las múltiples, en particular 1-atadura, 2-
atadura, etc.
17

18. Una aplicación de hipermedia puede describirse como software para uso específico que posee
hipertexto y multimedia. Describiremos entonces a las aplicaciones web como un software de
uso específico que es parte de la Web y que puede desplegarse a través de un visor web.
3.2 Simulación Web
Todo lo anterior ha crecido el interés de las personas en usar la Web como una nueva
plataforma para aplicaciones. La presión impuesta por la proliferación de la Web ha forzado a
la comunidad que se dedica a la simulación a migrar a la Web para mantenerse viva (Kuljis et
al., 2000). La historia de la simulación web comienza como un área de trabajo académico que
fue presentada en una sesión de tres artículos en el Congreso de Simulación de Invierno (WSC
por sus siglas en inglés) y según nos comenta Page (1998), fue la sesión con más concurrencia
junto con el bloque correspondiente a metodologías para modelado. El primer congreso
dedicado a esta nueva área fue en el año 1998, llamado WEBSIM ’98, y fue parte de la
Multiconferencia Anual del Oeste de la Sociedad de Simulación por Computadora (SCS,
2002).
La simulación web es el término que introdujo Paul A. Fishwick (Fishwick, 1996) para
representar la conexión entre la Web y el campo de la simulación. Young et al. (1998) añaden
a la definición que el propósito de la simulación web es ejecutar más simulaciones eficientes.
La simulación web es un área que está emergiendo y de sumo interés tanto para los
investigadores en simulación como para los practicantes de ésta (Arsham, 2002). Básicamente
la simulación web es la consecuencia de que la simulación no haya podido escapar del auge
que tiene ahora la Internet. Es por eso que muchas personas, como Ernest Page (Page et al.,
2000), han afirmado que este enfoque en ver todo vía web es nada más que una fascinación
por la tecnología. De hecho, Fishwick (1996) comenta que por presentarse tal situación, los
artículos en simulación web están enfocados en la tecnología (en el sentido que leímos
anteriormente), señalando que los investigadores en esta área requieren de un conocimiento
substancial de la tecnología si desean aplicar la Web. A esto le añadimos el hecho de que las
aplicaciones web cambian tan rápido que la información del área tiene que cambiar tan rápido
como ésta. Tomemos en cuenta que con el auge de la World Wide Web (WWW) y el nuevo
ambiente de trabajo que presenta, son muchas disciplinas las que están reevaluando sus
enfoques, técnicas y filosofías (Page, 1998). La plataforma más popular para las aplicaciones
web es la computadora personal (PC) debido al gran número de PC’s que existen en el mundo,
las plataformas Apple de Macintosh y Unix quedan en segundo lugar. Por otra parte, la
mayoría del software para Web está disponible para Windows 95, luego para Windows NT y
Windows 3.1 y por último para las diferentes versiones de Unix (Fishwick, 1996).
En el caso de la simulación web, la Web puede servir como sistema operativo y como el canal
de distribución para sus aplicaciones. Además, la simulación web puede tomar las
características de la Web (Kakakota y Whinston citados por Kuljis et al., 2000) a su favor:
• Facilidad de navegación
• Facilidad de publicación
18

19. • Nueva distribución de los modelos
• Habilitación de un nuevo paradigma centrado en la red
• Habilitación de nuevas aplicaciones de negocios internas (i.e. intranets)
Entonces la problemática de la simulación web es definirse de manera autónoma dejando la
definición de simulación clásica debido a que a que la Web per se redefine las características
de la simulación web:
Características de la Web Simulación Web Simulación Clásica
Estándares comunes Sí No
Independencia de
Sí No
plataforma
Generalmente no
Interoperabilidad No soportada
soportada
Facilidad de Navegación Varía Varía
No requiere de
Conocimiento Conocimiento
conocimiento
especializado requerido especializado requerido
especializado
No afectada por el cambio Afectada por el cambio Afectada por el cambio
Sin estructura Estructurada Estructurada
Tabla 1. Tabla comparativa entre las características de la Web y la
Simulación
Nos referimos a la interoperabilidad como la capacidad que tiene un software de estar en
diferentes máquinas y compartir datos (INT, 2002).
Fishwick (1996) describe los impactos potenciales de la Web en la simulación, enfocándose en
tres áreas:
1. Educación y Entrenamiento
2. Publicaciones
3. Programas de Simulación
Nos comenta que las tres áreas están interrelacionadas entre sí. Pero que el interés de la
persona que trabaja en un área en particular de la simulación le da mayor importancia a una de
éstas.
En la actualidad la pregunta de la simulación web con respecto a la educación y entrenamiento
es si podrá la primera establecer un nuevo paradigma de esta área. Los cimientos para
establecerlo parten del simple hecho de que la mayoría de los paquetes de simulación son de
interfaz gráfica (i.e. front-end gráfico). Esto permite al estudiante aprender a través de la
exploración de un mundo virtual. La manera en la que la Web afecta esto es debido a que no
existen las limitaciones usuales de las computadoras personales como el espacio de
almacenamiento ya que la Web, al ser una red de computadoras, presenta un esquema
distribuido. Por ejemplo, una forma de utilizar este recurso es almacenar de manera local
19

20. información básica del modelo pero que sus elementos estén en la Web. En general, incide a
enfocarnos en reusar la información y el conocimiento.
Muy interesante es el planteamiento de Fishwick (1996) sobre este enfoque: Mientras los
académicos se revelarán para usar este tipo de conocimiento reusable, la industria tendrá que
pensar de nuevo los términos de propiedad. Esto es porque además de producir software de
simulación de buena calidad, necesitarán lucrar y desde luego, deberán permitir el uso de su
información para otros sitios. Lo anterior, causado por el fenómeno web, produce
incertidumbre de cómo se manejarían las autorías, derechos de autor, registros, etc.
Otra forma en la que puede establecerse la educación y entrenamiento mediante la simulación
web es simplemente colocar el software requerido en el web.
Más que el hecho de cómo presentar el software de simulación a los usuarios, en la educación
es el hecho de cómo enseñar simulación. La Web al ser hipermedia, tiene la posibilidad de
contener elementos multimedia que marcan una ventaja en el aprendizaje a distancia por
encima de la manera típica basada en libros de texto. La Web sumerge al estudiante en un
ambiente de aprendizaje sintético que congenia más la formación del estudiante de simulación
que leyendo un libro o viendo una cinta de video. Por otra parte, prácticamente todo elemento
de hipermedia puede ser visualizado en el browser y si no es así, existe la posibilidad de
encontrar un plug-in (agregados para el browser para usar dicho elemento) de forma gratuita
en la Web.
Con respecto a las publicaciones, la Web está cambiando la manera de publicar y el cambio es
tan rápido que las personas han reestablecido la manera de realizarla y distribuirla. Publicar,
como sabemos, es el medio que utilizamos para difundir la información de los nuevos
conocimientos. Ese es el motivo de la gente que publica en simulación: dar a conocer los
avances de sus investigaciones y sus aplicaciones.
Para la gente de simulación que hace publicaciones, la Web viene a cambiar la manera en la
que se lleva a cabo el proceso de informar a los demás. Aspectos como referenciar el
contenido del artículo, revisiones, aceptación del editor en jefe, estar en cola para la
publicación y la forma de archivación en papel han quedado atrás. De hecho la postura que
han adoptado las personas relacionadas con el modelado y la simulación para publicar en las
revistas más conocidas, es hacerlo de forma electrónica (Fishwick, 1996). El nuevo proceso
adoptado orienta más a realizar búsquedas en la Internet, tener el documento y las referencias
en algún estándar para documentos de la Web (e.g. PDF), permitir que el autor haga
comentarios sobre el documento, pagar por servicios digitales y almacenamiento en vez de
impresión en papel y, crear la cultura de definir el contenido del documento en palabras claves
exactas que faciliten encontrar dicho documento por un usuario a través de los robots de
búsqueda.
Por último tenemos que el impacto de la Web en los programas de simulación, es lo
emocionante que es realizar las simulaciones en la Web. Anteriormente hablamos de
20

21. tecnologías para el cliente y tecnologías para el servidor para el desarrollo de páginas. En
general, podemos pensar en las diferentes opciones que tenemos para lograr la simulación en
el web. La simulación requiere que exista un modelo y el modelo a su vez requiere de software
para ejecutarse. De esta forma pensemos que algunas partes del modelo pueden ejecutarse en
nuestras máquinas y el resto en otras. También es posible no llevar a cabo la simulación en
nuestra máquina pero acceder a información general o a los resultados a través de la Web.
Incluso nos distribuiríamos partes del modelo de tal forma que la simulación sea simultanea y
no tan pesada para un solo equipo. Claramente el continuo avance y sofisticación de la Web
nos brinda nuevas formas de expandir y utilizar el modelado y la simulación.
Posteriormente Page (1998) después de una revisión de la literatura presenta una revisión de lo
comentado por Fishwick (1996), estableciendo ahora cinco áreas de impacto:
1. La simulación como hipermedia
2. La simulación como metodología de investigación
3. Acceso vía web para los programas de simulación
4. Modelado y simulación distribuida
5. Simulación de la Web
La hipermedia por su naturaleza característica puede ser explotada para presentar la
simulación mediante elementos de multimedia e hipertexto. Entre las ventajas de ver la
simulación como hipermedia está el hecho de que podemos acceder cómodamente a ella desde
nuestro navegador o como un acceso directo colocado en nuestro escritorio. Similar a como
hemos visto anteriormente, esta forma de realizar aplicaciones de modelado y simulación con
este enfoque, nos abren la posibilidad a nuevas formas de educación y entrenamiento, en
particular el establecimiento de nuevos paradigmas enfocados en aprendizaje a distancia e
interactivo.
La Web es un medio de alcance tan extenso que los nuevos modelos pueden ser diseminados
muy rápidamente, así como sus resultados. Ya hemos visto un poco del cambio debido a la
Web sobre la forma de publicar. Lo anterior estimula a establecer una nueva metodología de la
investigación en simulación e investigación científica en general.
Una de las ideas más comunes con la que el término simulación web es asociado, es la
ejecución remota de la simulación proveniente de programas que son ejecutados en el servidor
y enviando los datos (a través de formularios HTML por ejemplo). A las simulaciones que se
hacen de este tipo las conocemos con el nombre de simulaciones legadas. La otra idea más
común es desarrollar simulaciones basadas en código móvil que corran en el cliente. Es decir,
acceder a pequeños programas ya realizados que se descargan en nuestra máquina para ser
utilizado (e.g. applets).
21

22. El modelado y simulación distribuida es el área en el que están considerados todas las
tecnologías orientadas a la Web y que son utilizadas para realizar ambas. Volvemos a tomar la
palabra tecnología en el sentido presentado al principio. Son un conjunto de normas que en
este caso le indican a la gente que quiere trabajar en aplicaciones web como desarrollarlas y
concierne al manejo de los datos, transmisión, autentificación, entre otras cosas. Entre las
comunes que se utilizan en la simulación distribuida están el Método de Invocación Remota
(Java, 2002), la Arquitectura de Alto Nivel (DoD, 1998) y la Arquitectura de Controlador de
Solicitud de Objetos Comunes (OMG, 2002). Las arquitecturas son más conocidas por sus
siglas en inglés RMI, HLA y CORBA respectivamente.
Por último es importante que tengamos en cuenta la simulación de la Web. Podemos hacer
modelado y simulación para caracterizar la manera en la que se desenvuelve la Web y
optimizarla.
Por otra parte, Arnold Buss (en Page et al., 2000a) explica que el impacto de la explosión de
las redes de computadoras en los últimos años ha causado un efecto revolucionario en la
simulación, por lo que indica que para explotar los recursos actuales la naturaleza de la
simulación obviamente debe cambiar. Explica que los modelos de simulación han sido
diseñados de manera monolítica y que el advenimiento de la Programación Orientada a
Objetos (Rumbaugh, 1991) lo que hace es presentarnos tan solo monolitos más elegantes. La
simulación, ya sea de aplicación militar o industrial, han sido diseñadas para la ejecución de
modelos en una sola máquina. Nos dice que para tales modelos la red ofrece poco. Piensa que
usar el poder completo de las redes beneficia a la simulación y al modelado solo si se diseñan
de manera diferente. El uso de datos al día que interactúan con base de datos a través de la red,
aceleran el ciclo de modelado y toma de decisiones en gran magnitud. Él piensa que los
modelos por computadora tienen gran potencial para el análisis y entrenamiento militar. En sí,
considera que la simulación debe hacer uso de aplicaciones que reciban datos a través de una
red de una base de datos dinámicamente generada, que creen los elementos y datos que usarían
en el momento que se ejecuten los datos y que los componentes de software que las
conformarían sean fáciles de integrar en otras aplicaciones.
3.3 Filosofía de la Simulación Web
Page (en Page et al., 2000b) comenta que la piedra angular de la filosofía de la computación
por mucho en los pasados 30 años, es el principio de Edsger Dijkstra de la “separación de
preocupaciones” (Dijkstra, 1976). Este principio discute que el objetivo fundamental de un
sistema de software es su corrección y que está dada por las consideraciones de diseño (del
software) sin tomar en cuenta la infraestructura computacional que servirá para su ejecución.
Esto nos induce a una separación de la especificación y la implementación. La fuerza de esta
filosofía hace que sea tomada como la temática de muchos de los campos de las ciencias de la
computación.
22

23. De manera informal, podemos definir la especificación como el conjunto de normas o
estándares que seleccionamos con el que describimos el funcionamiento del software a
desarrollar. Mientras que la implementación está enfocada a la manera en la que hacemos el
desarrollo: lenguaje de programación, arquitectura seleccionada, etc.
Page (1998) también menciona que esta filosofía ha sido cuestionada bajo observaciones
pragmáticas. Menciona como ejemplo la conclusión de Swartout y Balzer (citados en Page et
al., 2000a) de que esta separación no siempre es alcanzada en su totalidad, afirmando que
cualquier especificación puede ser vista como la implementación de una especificación de
orden mayor.
Dentro de la comunidad de simulación existe el punto de vista de que la especificación del
modelo es el dominio del modelador y que la implementación del modelo es el dominio de la
automatización. Tal punto de vista va en contra del principio de Dijkstra, afirmando que la
implementación no debe ser atrasada hasta que la especificación se termine y que el
modelador debe permanecer aislado de los detalles de implementación en el mayor grado
posible.
Kevin J. Heavly (en Page et al., 2000a) comenta que la evolución de los lenguajes de
especificación de modelos de alto nivel y sus formalismos han motivado a desarrollar más
simulación, sobre todo por evitar la parte de programación. Indica que sin embargo, tales
sistemas son frecuentemente difíciles de modificar o extender debido a una separación
impuesta de la especificación y de su implementación. Lo anterior lleva a los modelos a
reflejar un comportamiento pobre del sistema y no presentar potencial para distribución y
reuso en otras empresas.
Los comentarios de Page et al. (2000a) son bastante claros: “Si la World Wide Web está por
efectuar grandes cambios en la metodología del modelado, entonces debemos alterar o abolir
los principios existentes o introducir nuevos principios”. Lo anterior hace que analicemos el
hecho de la Web influye en la tecnología de construcción de modelos, su ejecución y la
manera de compartirlo, pero dicha influencia es poco palpable respecto a los principios.
Sin embargo, Ray J. Paul (Page et al., 2000a) piensa que además de las ideas de impacto de la
Web mencionadas anteriormente, una muy importante es el cambio de la naturaleza humana
ante la Web. La generación actual está acostumbrada con la Web, juegos de video,
aplicaciones de software para trabajos escolares, interfaces multimedia, correo electrónico, etc.
También los Natural Born Webbers¸ como los llama Paul, están acostumbrados a un constante
y rápido acceso a la información. Comenta que por lo anterior, estas personas de la era web
poseen rápida retroalimentación y se enfocan en un punto de vista para el análisis y solución
de problemas, tal y como sucede en juegos con múltiples jugadores por la Internet. Afirma que
por la naturaleza de estas personas, en la medida que hagan uso de la simulación, necesitarán y
23

24. desearán desarrollar herramientas que permitan la rápida construcción de modelos y
experimentación. Interesante es la afirmación de Paul sobre el hecho de que la generación de
la era web tomará la simulación como un enfoque para el entendimiento de problemas.
Es importante que tengamos en cuenta que la simulación web debe enfocarse siempre en el
usuario. El usuario es una parte crucial para la simulación web independientemente de su
desempeño. Cuando una aplicación no fue dirigida a los usuarios, rara vez progresa o tienen
impacto social y la situación actual de la simulación web es esta (Kuljis et al., 2000).
3.4 Principios de la Simulación Web
Para Page y Opper (en Page et al., 2000b) los principios de la simulación web son:
1. Proliferación de objetos digitales
2. Proliferación de estándares de software
3. Construcción de modelos por composición
4. Incremento del uso de los enfoques de “prueba y error”
5. Proliferación de la simulación por usuarios no expertos
6. Arquitecturas de múltiple atadura y sistemas multilenguajes
Según Fishwick (1996), en el futuro cercano de la simulación web haremos uso de lo que él
denomina objetos digitales en casi todo nuestro día a día. Estos objetos digitales son
representaciones en la computadora de objetos físicos que encontramos en nuestro alrededor.
Esta propuesta es la que generaliza su idea sobre el documento del futuro. Para él, pensar en
documentos de hipermedia, es pensar en la posibilidad de documentos de simulación, por lo
que el concepto de documento cambiará. Aun más, piensa que la idea de presentar la
simulación usando símiles de documento (e.g. una página web) será reemplazada con el uso de
símiles de objetos (los objetos digitales). Por ejemplo, en el caso de las manufactureras,
llevarían a cabo el modelado con objetos digitales para efectuar simulaciones durante el
proceso de desarrollo de los objetos físicos que modelarían. Los modelos de objetos digitales
serían entonces equivalencias de los objetos físicos con la ventaja de ponerlos disponibles para
muchos a través de la Web. Page et al. (2000b) comentan que Fishwick nos señala las
preguntas que son planteadas por tal hecho como lo son el mantenimiento de los objetos
digitales, los derechos de sus autores y cómo protegerlos y, los derechos de sus usuarios y
cómo protegerlos. Fishwick piensa que una analogía de cómo controlamos, distribuimos e
incluso alcanzamos el lucro con los objetos físicos, puede ser usada con los objetos digitales;
aunque admite que todavía no está claro que tanto se podría lucrar.
Obviamente tal proliferación de los objetos digitales no puede hacerse sin establecer
estándares. Como la mayoría de las cosas que suceden en la Web, los estándares son de facto.
Pero como la simulación es prácticamente nueva, el grupo de personas que trabajan en ella
desde sus inicios no ha crecido mucho. Es común entonces que utilicen herramientas de
desarrollo y tecnologías similares.
24

25. Perakath (2000) dice que el desarrollo se puede categorizar en dos grupos:
• Desarrollo de software basado en componentes
• Agentes de Software
El desarrollo de software por componentes es un paradigma de la tecnología de información
que se basa en ensamblar aplicaciones completas a partir de pequeñas partes denominadas
componentes de tal forma que poseen la característica de que pueden usarse de nuevo en otras
aplicaciones. Los componentes pueden distribuirse por red para dar paso a las aplicaciones
distribuidas. Arquitecturas como RMI y CORBA son arquitecturas diseñadas para dar paso a
este tipo de aplicaciones. En adición a éstas tenemos otros como el Modelo de Objeto
Componente o COM de Microsoft y su versión distribuida llamada DCOM, y muy ligada a
ellas (por tratarse de la misma compañía), está la tecnología para el desarrollo de componentes
llamada ActiveX (Microsoft, 2002a y 2002b). Así, los componentes de software y el enfoque
de desarrollo basado en componentes pueden ser utilizados para facilitar la simulación
distribuida y la aplicación de la simulación de modelos en la Internet.
Los agentes de software, por otro lado, son un área emergente que según Jennings, en palabras
de Perakath (2000), en apariencia ofrecen una ventaja significativa a la comunidad de
simulación. El concepto de agente fue introducido por Carl Hewitt y según Shoham (en
Perakath, 2000) un agente de software es “una entidad de software la cual funciona
continuamente y autónomamente en un ambiente particular, frecuentemente habitado por
otros agentes y procesos”. Un ejemplo trivial, es nuestro agente de revisión ortográfica que va
verificando las palabras conforme las vamos tecleando en un procesador de texto (e.g. Word).
También nos comenta Shoham que un agente puede poseer las siguientes características:
1. Autonomía: El agente tiene sus estados y metas definidas de manera interna, y se comportan
según su proximidad con sus metas o dependiendo del comportamiento del usuario.
2. Cooperación: El agente debe ser capaz de cooperar con otros agentes y con usuarios humanos.
3. Aprendizaje: El agente debe mejorar su desempeño con el tiempo. A este tipo de agentes que
demuestran aprendizaje se les conoce con el nombre de agentes inteligentes.
Los agentes entonces pueden ser adaptados y usados para beneficiar la simulación web, tanto
en su desarrollo como en su aplicación.
De esta manera el tercer principio, el de construcción del modelo por composición, establece
que como consecuencia directa de la proliferación de objetos digitales y el establecimiento de
estándares, haremos el modelado a partir de todos los objetos digitales a nuestro alcance. Este
principio marca la filosofía de programar como ultimo recurso.
Hemos visto que Paul comenta comportamientos típicos de los hijos de la era web: los natural
born webbers. Pues bien, es claro que el principio de prueba y error está cimentado en el
hecho de que la rapidez con la que acceden y retroalimentan la información las nuevas
generaciones, y su necesidad de obtener algo que les funcione adecuadamente hace que
25

26. enriquezcan su proceso de análisis. Por lo que al usar los objetos digitales, ellos serán capaces
de hacer búsquedas de manera masiva y rápida sobre cómo combinar los objetos digitales de
manera que funcionen, lo cual se contrapone a la manera actual de hacer las cosas de realizar
estas búsquedas en un espacio muy reducido.
Debido a que la simulación podría volverse algo de uso común para los que usamos
computadoras, entonces es importante que la educación avance como lo hace la tecnología.
Claramente la proliferación de usuarios de simulación no expertos es algo que puede tomarse
en dos vías. Una es la ventaja que muchas personas puedan acceder a procesos de simulación
de manera tan cómoda y natural al usar su computadora, que no necesiten de mucho
conocimiento previo sobre la técnica de modelado involucrada. Por otra parte, lo último es lo
que marca el otro sentido. Presentar al usuario simulaciones de tipo lo que ves es lo que tienes
(WYSIWYG, por sus siglas en inglés), puede tener por consecuencia que éste no sepa aplicar
la técnica o lo haga de manera errónea. De ahí que la educación, y a esto se añade la
metodología de modelado, tengan que avanzar juntos. Page et al. (2000b) de una vez proponen
el uso de dar soporte a los usuarios a través de agentes de decisión inteligentes para establecer
mecanismos seguros.
Además, Page et al. (2000b) están seguros de que el mercado de objetos digitales en el futuro
causará entonces una heterogeneidad de lenguajes de programación por lo que el proceso de
composición naturalmente producirá sistemas multilenguajes. Por otro lado, señalan que las
arquitecturas de multi-atadura son el enfoque que domina en la actualidad, lo cual es obvio en
cierto punto. Acceder a información distribuida motiva a implementar formas de realizarla de
manera más eficiente. Así, creen que esta tendencia de las arquitecturas múltiples durará
bastante, y que en el contexto de la simulación podría usarse para ejecuciones repetibles con
fines de análisis y en otros casos para ejecuciones en tiempo real con fines de entrenamiento.
3.5 Simulación web distribuida y paralela
Como hemos visto anteriormente, la simulación web puede implementarse de manera
distribuida (los elementos del modelo son ejecutados de manera ajena en equipos de posible
diferente plataforma) o paralela (el modelo es resuelto de manera simultanea en equipos
diferentes cuya plataforma puede ser la misma). También sabemos que RMI, CORBA y HLA
y el uso de componentes (e.g. ActiveX) establecen los medios para realizarlas.
“El propósito de la simulación distribuida y paralela es reducir el tiempo de simulación
mediante la distribución del trabajo de simulación en múltiples procesos y habilitar la
interoperabilidad en tiempo real con cada máquina de simulación” (Young et al., 1998).
Así, Young et al. (1998) nos comentan que es posible alcanzar tal meta esencialmente usando
paralelismo el cual implementa el proceso distribuido en una Simulación de Evento Discreto
(DES, por sus siglas en inglés) asíncrona de una manera síncrona. Es ahí donde entran en
juego las arquitecturas y tecnologías existentes.
26

27. En otras palabras, Young et al. realizan una combinación del paralelismo y los procesos
distribuidos. El proceso distribuido es asíncrono, es decir, se da en intervalos no constantes en
el tiempo; pero el paralelismo es un proceso síncrono, se realiza en intervalos de tiempo
constantes. Aparentemente las simulaciones son llevadas a cabo de manera síncrona bajo un
esquema de paralelismo, aunque en realidad los procesos se están dando de manera distribuida
de forma intrínseca y por ende, asíncronos.
De esta forma, Young et al (1998) muestran los tres tipos en los que se pueden implementar
las herramientas desarrolladas para una DES en la web o una simulación distribuida en
general:
1. Simulación alojada en el servidor
2. Simulación ejecutada en el cliente
3. Simulación híbrida cliente / servidor
A su vez, caracterizan a la simulación web distribuida en dos:
1. Las que corren la simulación en un sistema de soporte para DES paralelas (PDES)
estructuradas de forma aislada
2. Las que corren la simulación de forma distribuida en la Web
En otras palabras. La primera categoría equivale a realizar las simulaciones en plataformas
paralelas pero que sean consecuencia de la petición de un solo cliente. Es decir, por cada
petición hay una simulación paralela trabajando y por último, los resultados son devueltos. En
el segundo caso, es para cada petición, existe un servidor de simulación distribuida que se
encarga de repartir el trabajo entre varios clientes para su ejecución.
27

28. Figura 17. Tipos de implementación de DES. a) La simulación alojada
en el cliente. b) La simulación cliente / servidor distribuida en la Web.
Claramente vemos que la primera categoría pertenece a las simulaciones de tipo alojadas en el
cliente. Notemos que no es necesario una ejecución en paralelo de la simulación. Podría usarse
un servidor que realice la simulación de forma secuencial siempre y cuando sea recomendable
y no afecte mucho el desempeño. La categoría dos a su vez representa el tipo cliente / servidor
de las simulaciones. Entonces, el tipo de simulación trivial corresponde a la simulación en el
cliente.
Young et al. (1998) se concentran en la implementación de la primera categoría afirmando que
es la más seguida y que tienen los siguientes méritos:
• Proporciona una forma fácil de construir el ambiente de simulación. Tan solo es
necesario conectarnos al sistema local el cual soporta PDES y que tiene motores de
simulación para las peticiones de los clientes.
• El desempeño de la simulación está certificado y seguro.
• No es necesario que el cliente se preocupe por la implementación de los procesos de
simulación.
• No es un problema que la velocidad actual de la Internet sea físicamente lenta e
inestable.
Con respecto a la segunda categoría, Young et al. (1998) presentan sus afirmaciones
basándose en los experimentos realizados por Yücesan y su grupo. Piensan que estar haciendo
simulaciones que se ejecutan en los clientes y en los servidores conducen a aspectos críticos
para esta categoría como son la congestión y seguridad de la red, así como la eficiencia en la
comunicación. A esto se añaden cuestiones sobre el desempeño de la simulación distribuida en
función de su velocidad y el desarrollo de algoritmos eficientes para la distribución que sean
inteligentes.
3.6 Aspectos Críticos del Proceso de Simulación que afectan a la Simulación
Web
“La simulación como una herramienta para el análisis, diseño, experimentación, prueba,
entrenamiento y logística se ha vuelto viable con el advenimiento de la tecnología
computacional práctica” (Amico et al., 1997).
Entre los años 40 y 60 las computadoras análogas dominaban la época y servían para hacer
simulaciones en tiempo real. Después vino el surgimiento de las computadoras digitales a
finales de los 50 y a principios de los 60, remplazando a las anteriores en el campo de la
simulación por computadora. Lo curioso del asunto, según nos comentan Amico et al. (1997),
28

29. es que a pesar de que la tecnología ha mejorado considerablemente, los problemas típicos de la
simulación siguen siendo lo mismos.
El proceso de simulación comienza básicamente con la identificación de los requerimientos tal
y como lo hacemos en el desarrollo de cualquier software. Cuando hemos escuchado tales
requerimientos o tenemos un documento de éstos, entonces procedemos a hacer un modelo
conceptual de lo que vamos a simular. De aquí lo que hacemos a continuación es ir
desarrollando las cuatro fases básicas para la simulación (Amico et al., 1997) que son:
1. Desarrollo del modelo o modelos matemáticos
2. Obtención de datos válidos y los datos basados en conocimiento previo
3. Seleccionar el hardware y desarrollar el software para llevar a cabo la simulación
4. Validación de la simulación
De esta manera, los aspectos críticos relacionados con el proceso general de la simulación son:
1. Modelado
2. Datos
3. Implementación
4. Validación
Además, tenemos que Amico et al (1997) ha encontrado tres aspectos muy significativos y
que no están relacionados directamente con las fases que ya hemos visto:
Limitaciones del Presupuesto de Planeación. Claramente el presupuesto nos limita al acceso
de los recursos. Como estamos limitados en cuanto a presupuesto, debemos verificar que el
tiempo de desarrollo y el costo de la simulación no lo exceda.
El Tiempo del Ciclo de Desarrollo. Son muchos los factores que pueden afectar el ciclo de
desarrollo del proyecto de simulación. Puede ser que conforme se vaya desarrollando el
proyecto nos topemos con problemas inesperados que requieren de una replantación del
proyecto y que no estaba considerado en el presupuesto, tal vez el sistema haya cambiado con
el tiempo o que la gente involucrada con el proyecto al pasar el tiempo ya no sea la misma.
La Comunicación durante el Ciclo de Desarrollo. La falta de comunicación o la mala
presentación de ésta puede comenzar desde el proceso de pasar de las explicaciones verbales o
del documento de requerimientos a la creación del modelo. Cuando no tenemos una
comunicación clara dentro de los miembros del proyecto de simulación, claramente podemos
hacer muchas malas interpretaciones de la meta del proyecto, de cómo implementarlo o bien
de los resultados.
29

30. 3.6.1 Aspectos Críticos del Modelado
Regresemos a los problemas que enfrentamos según Amico et al. (1997) en el proceso del
desarrollo de la simulación. Primero tenemos el modelado. Los aspectos relacionados con ella
podemos particionarlos en:
• Clasificación de los modelos
• Actualización del modelo para los cambios
• Aplicación del modelo
• Confianza del modelo
• Reusabilidad del modelo
Los modelos podemos clasificarlos según Amico et al. (1997) en:
Modelos de Componentes: Son el tipo de modelos que están constituidos de pequeñas partes
denominadas componentes. Lo que hacemos es dividir el modelo de un sistema complejo en
sus partes mínimas. Además, esta forma de hacer modelado se adapta muy bien a los nuevos
paradigmas de programación.
Modelos de subsistemas: A diferencia de los modelos de componentes, los modelos de
subsistemas ya son una conformación de éstos, de tal forma que se enfocan más en las
entradas y en las salidas y en cómo funcionan.
Modelos de sistemas: Estos modelos son en esencia una colección de subsistemas y de
componentes. Obviamente esta es una vista del sistema a un nivel más alto.
Modelos de Multisistema: Aquí ya vemos los modelos relacionados con simulaciones que
manejan grandes cantidades de plataformas utilizadas. Este tipo de modelos, por su
dimensión, está involucrado con logística, comunicaciones y otros sistemas que pueden
influenciar la salida de un escenario dado (i.e. nos indican como se comportarían sistemas muy
grandes).
Por otra parte, es claro que los modelos deben estar preparados para las actualizaciones. Es
posible que cuando estemos realizando el diseño detallado del modelo, su fabricación o
prueba, se nos presenten cambios. El éxito de nuestro modelo radica en parte si este se puede
adaptar adecuadamente a los cambios sin sufrir grandes alteraciones o de plano ser desechado.
Las aplicaciones del modelo van desde la fase conceptual pasando por la de diseño,
producción y logística. Cuando estamos en la fase conceptual, los modelos deben ser
teóricamente correctos y representar los objetivos de la simulación de manera precisa; por esto
no debemos hacer simplificaciones en esta fase. Es importante que la integridad del modelo la
mantengamos desde su formación por componentes hasta ir agrupándolos en subsistemas y
luego en sistemas.
Es importante que nuestro modelo sea exacto en detalles. Cuando tratamos de detallar mucho
un modelo podemos atrasar el proyecto o excedernos en costos. La confianza del modelo se
30

31. basa en el hecho de que podemos usar los recursos y datos disponibles y no alejarnos de los
objetivos del proyecto de simulación.
El enfoque de reusabilidad en el desarrollo de software ha tomado mucho auge debido a que
podemos usar una y otra vez fragmentos de software ya realizados en situaciones diferentes
pero que tienen los mismos requerimientos. La reusabilidad de los modelos busca el mismo
fin; la posibilidad de tomar modelos ya validados y poder utilizarlos en proyectos diferentes de
los que nacieron.
3.6.2 Aspectos Críticos de los Datos
Después de tener bien definido el modelo con el que vamos a trabajar, nuestro siguiente paso
según Amico et al. (1997) es la recolección de los datos de tal forma que sean adecuados en el
uso del modelo. Debemos incluir en este aspecto las características de los sistemas físicos
involucrados, el ambiente, el conocimiento del sistema e incluso conocer el comportamiento
de los datos. Todo lo anterior es una parte esencial de la simulación de modelos y tales
aspectos podemos clasificarlos como sigue:
• Obtención de los datos
• Datos de sistema
• Datos ambientales
• Datos de conocimiento
• Datos del comportamiento humano
En la obtención de los datos la precisión juega un papel crucial en la simulación del modelo,
aunque podemos encontrarnos en algunos casos datos incompletos e incluso imprecisos. Una
vez que tengamos los datos, debemos evaluarlos y tomaremos decisiones de cómo
representarlos matemáticamente. Es posible que cuando no tengamos los datos disponibles
podamos crearlos, aunque es importante que seamos muy suspicaces al hacerlo por el motivo
de que podemos obtener resultados no deseados o frustrantes. Obviamente, apenas tengamos
los datos disponibles para ejecutar la simulación del modelo, debemos sustituir los datos
asumidos que utilizamos previamente.
Podemos obtener los datos de una gran variedad de fuentes. De aquí tenemos que los datos del
sistema válidos serán más fáciles de obtener cuando tengamos un modelo más maduro (i.e.
bien diseñado) y un sistema actualizado (i.e. replanteado a lo que observamos actualmente).
Los datos ambientales son considerados para aquellos sistemas que están relacionados con el
modelado de la naturaleza como en el caso de modelar el océano, sistemas sensoriales o de
visión. Manejar este tipo de datos puede ser algo complicado debido a que provienen de
sistemas complejos que nos presentan gran variabilidad en los datos que podemos usar para
ellos.
Obtener el comportamiento real de un sistema para un proyecto de simulación puede ser una
tarea muy compleja. Los datos de conocimiento son aquellos que manejamos en situaciones
31

32. donde están involucrados expertos del sistema real junto con las personas encargadas de la
simulación. Su conocimiento sobre el sistema ayuda a realizar el proyecto.
Por último, los datos de comportamiento humano están relacionados con los modelos en los
que la computadora toma roles de individuos o de grupos de personas provenientes de
sistemas tales como los militares o de interacción.
3.6.3 Aspectos de la Implementación
El aspecto crítico relacionado con la implementación según Amico et al. (1997) es todo lo
relacionado con el sistema computacional que usamos para poder llevar a cabo la simulación:
el hardware y el software. El hardware debe ser lo suficientemente rápido y con la suficiente
memoria para realizar la simulación de los modelos ya sea en tiempo real o tiempo no real.
Con respecto al software, éste debe estar bien elaborado de tal forma que podamos
implementar el modelo adecuadamente.
Los aspectos particulares relacionados con el hardware podemos clasificarlos en:
• Sistemas en tiempo no real
• Sistemas en tiempo real
Sabemos que los sistemas de tiempo real son aquellos cuyas salidas las obtenemos
prácticamente al instante de que se ejecuta una parte o tarea particular del sistema, mientras
que en los sistemas de tiempo no real debemos esperar a que se completen todas para obtener
las salidas (INT, 2002).
Los sistemas en tiempo no real los tenemos básicamente en las computadoras digitales de
propósito general (e.g. computadoras personales). Las salidas pueden presentarse a través
interfaces gráficas o impresas, tal vez ambas. Algo que debemos tener en cuenta es que si el
tiempo de corrida de las simulaciones en este tipo de equipos es muy excesivo, éste puede
fallar antes de que la corrida sea completada.
Con respecto a los modelos que requieren resolverse en tiempo real es importante que
consideremos computadoras con una velocidad y capacidad de memoria adecuadas para este
tipo de trabajos. Esto lo hacemos con base a la implementación del modelo en software que
hemos de resolver y los índices de iteración que son necesarios para poder hacerlo. Estos
índices están determinados por la dinámica del sistema.
En adición a lo presentado anteriormente, tenemos los aspectos relacionados con el software.
El software nos provee las herramientas para convertir los modelos desarrollados en una forma
que la computadora pueda ejecutar. Por esto, los programas de computadora que usemos
debemos considerarlos respecto a las características del sistema para asegurar que los cálculos
que realice la computadora sean estables y provean la precisión requerida.
A su vez, Amico et al. (1997) comentan que los aspectos críticos que se presentan con
respecto al software son:
32

33. • Errores de software
• Dinámica de vehículo
• Algoritmos de integración
• Bases de datos ambientales
Primero es claro que el desarrollo de modelos de simulación de gran escala está involucrado
con el uso de muchísimas instrucciones con lo cual es inherente encontrar errores. Así,
debemos establecer rangos aceptables de errores en el software según la forma en la que
evaluemos nuestro software y de tal forma que no se nos presenten casos extremos como la
caída del equipo.
La dinámica de vehículo se refiere a los índices de iteración requeridos para una computación
estable. Sin duda esta estabilidad es uno de los factores de mayor influencia en los
requerimientos de software, por lo que prácticamente es un elemento clave en diseño de éste
así como en la selección del hardware.
Otro aspecto importante es la selección de los algoritmos de integración eficientes. Estos
algoritmos son los métodos que conllevan a la solución del modelo por lo que es importante
una buena selección con conocimiento previo de la precisión que ofrece cada uno.
Las bases de datos ambientales están relacionadas directamente con los modelos involucrados
con el modelado del ambiente (explicados anteriormente). Obviamente, el tamaño y
resolución (i.e. la cantidad de campos) de este tipo de datos dependen del detalle de modelo
desarrollado.
Además de los aspectos ya mencionados, Amico et al (1997) proponen como quinto aspecto
crucial en el software las Simulaciones de Interacción Distribuidas (DIS) y la Arquitectura de
Alto Nivel (HLA). Ambas, son estándares para el desarrollo de simulación distribuida y en el
web (DMSO, 2002).
3.6.4 Aspectos de Validación
La validación es el proceso de probar una simulación para determinar si se ajusta a los
objetivos establecidos. Así, la validación nos indica si se ha conservado la integridad de los
requerimientos iniciales se ha mantenido de tal forma que después de pasar por todas las fases
obtenemos un producto útil. La validación puede tomarse en cuenta desde la fase conceptual,
no únicamente al final de todo el proceso. El usuario de la simulación (como producto final)
tiene que estar involucrado en el proceso de validación por obvias razones. Confiar en los
resultados es crucial para las personas que toman decisiones sobre la base de los resultados de
la simulación o bien, para el usuario final; en tal caso, personas especializadas en técnicas de
análisis estadístico pueden ser muy útiles.
Para Amico et al. (1997), los aspectos críticos de la validación son:
• Validación del modelo y datos
33

34. • Validación de la implementación
• Prueba de la simulación
• Validación de la simulación
El modelo es desarrollado en la fase de diseño con los datos presentes. Por tanto, la validación
del modelo y datos se refiere a revisarlos en comparación con los requerimientos establecidos.
Conforme la simulación avanza hacia la prueba nos encontramos con dos fases distintas. La
primera tiene por objetivo determinar si la ejecución de la simulación se lleva a cabo como fue
diseñada y básicamente confiere internamente al desarrollador de la simulación. La siguiente
fase está involucrada con la persona o el grupo de personas por los que la simulación es
desarrollada y sirven para determinar si los requerimientos primarios fueron satisfechos.
Al final, la validación de la simulación es verificar si ésta cumple en su totalidad con la
versión final de requerimientos (después de pasar por todas las fases). Aquí es donde el
usuario cumple con los requerimientos y si cumplió con su propósito. Es importante que
notemos que algunas veces no son necesariamente lo mismos.
Aunque el proceso de simulación podemos determinarlo en las fases mencionadas
anteriormente, es claro que el factor humano es muy influyente en cada uno de éstas. El éxito
del proyecto puede radicar en las personas encargadas en realizarlo, los simulacionistas.
Rogers (1997) clasifica los elementos del simulacionista ideal en
1. Atributos
2. Don de gentes
3. Habilidades básicas
4. Modelado
5. Enfoque de sistemas
6. Factores humanos
7. Conocimiento del dominio
8. Métodos de simulación
La categoría de atributos se refiere según Rogers (1997), a aspectos que el simulacionista
debería tener. El simulacionista debe ser una persona creativa en la solución de problemas.
Como el simulacionista convive con personas de disciplinas ajenas, debe tener habilidades de
liderazgo que facilite un esfuerzo colaborativo multidisciplinario. La tecnología involucrada
con el proyecto podría cambiar, entonces el simulacionista debe reconocer tales cambios y
adaptarse a ellos. Entre los atributos del simulacionista se encuentra la experiencia. Sin
embargo, podemos decir que el factor de experiencia real de un simulacionista es su
experiencia adquirida durante su vida. Diferentes situaciones han remanecido en el
simulacionista en una serie de conocimientos basados en lo vivido, tal habilidad puede ser
muy significativa como desarrollador de un proyecto de simulación para facilitar todo el
proceso. Básicamente tenemos en el simulacionista dos tipos de experiencia:
34

35. • La experiencia pragmática sobre cómo alcanzar la meta de un proyecto, ya sea de
simulación o no.
• La experiencia multidisciplinaria que le permite trabajar en los distintos cánones de
varias disciplinas.
Como persona un simulacionista debe poseer en su personalidad los atributos de ser creativo,
resolvedor de problemas, líder, adaptable, visionario, abierto de mente y, tolerante.
El don de gentes de un simulacionista según Rogers (1997) sirve para poder interactuar
adecuadamente con los otros miembros involucrados en el desarrollo; de ahí que para
empezar, un simulacionista deba tener muy buena escritura y facilidad de expresión. Debe ser
capaz de aceptar y tolerar las ideas de otras personas y establecerse un compromiso de
aprender todo el tiempo de su vida.
Sin embargo como habilidades básicas, Rogers (1997) propone que un simulacionista debe
poseer una buena capacidad para el análisis, conocimientos y habilidad en probabilidad y
estadística (recordemos lo relacionado con la validación de datos mencionado anteriormente),
así como de diseños experimentales y métodos estocásticos ya que muchas veces el modelado
puede requerir este tipo de conocimientos un poco más profundos para su elaboración. Por la
relación computación-simulación, el simulacionista también debe saber de computación e
incluso es preferente que pueda competir en ésta rama; interpretamos el verbo anterior como
un desempeño óptimo por parte del simulacionista ante la computadora como su herramienta.
Además de lo relacionado a probabilidad o estadística, algunos modelos pueden involucrar
otras ramas de matemáticas o investigación de operaciones (e.g. simulación para colas de un
banco); entonces es importante que el simulacionista tenga conocimientos para tener al menos
una idea de la rama de matemáticas que podría ser más útil para modelar. Además como los
proyectos de simulación pueden tardar mucho y ser costosos, el simulacionista entonces debe
tener entre sus habilidades básicas la administración de proyectos, para ver como se va
desarrollando, y el modelado del costo que se refiere a planificar bien la forma en la que se
darán los costos involucrados.
El siguiente elemento que posee un simulacionista ideal es el modelado (Rogers, 1997). Como
imaginamos, el modelado es el más importante. Muchos aspectos están involucrados con este
elemento tales como la habilidad de la persona para la construcción de modelos, ser empíricos,
apreciar las capacidades y limitaciones de los métodos experimentales, mirar el sistema desde
diferentes perspectivas y ajustar la abstracción obtenida para alcanzar un buen grado de
fidelidad (i.e. representativo del sistema), saber hacer trueques entre los costos y el nivel de
detalle querido, usar varios paradigmas para la construcción de los modelos, tener en cuenta el
costo-beneficio del modelado y hacer su análisis de riesgo y por último, tener conocimientos
de ingeniería (i.e. desarrollo metódico de un producto útil).
En adición a lo anterior, Rogers (1997) menciona que un enfoque de sistemas es un elemento
útil como persona dedicada a realizar proyectos de simulación. Las ventajas de tener este
enfoque es la forma en la que se va desarrollando todo el proceso. Obviamente el primero paso
es la definición del problema para luego identificar los elementos claves del sistema que es lo
35

36. incluido en el modelo. También desde este enfoque podemos establecer un método para
encontrar el nivel adecuado de abstracción, realizar un análisis bien planeado. También
gracias a este enfoque, está la familiaridad de trabajar con heurísticas o bien, implementar
evaluaciones.
Los factores humanos del simulacionista están divididos según Rogers (1997) en dos
consideraciones. La primera es cuando el simulacionista está modelando comportamientos de
individuos o grupos, en estos debe entender las dificultades que se presentan al realizar este
tipo de tarea; o sea, conocer más el problema que estar pensando únicamente en cómo
resolverlo. La segunda consideración tiene más que ver con la interacción humano-
computadora; es decir, con la manera en que la simulación es presentada (e.g. un simulador de
vuelo) y si ésta se adapta al usuario de manera confortable (i.e. ergonomía).
El simulacionista debe tener conocimiento del dominio en el cual está trabajando. Sin
embargo, el simulacionista es parte de un equipo, así que el experto en el dominio debe hacer
uso de su juicio sobre cualquier supuesto asumido del dominio, similar a como mencionamos
en el aspecto de validación anteriormente.
Los métodos de simulación son técnicas para diseñar, desarrollar, producir e implementar,
operar y evaluar las simulaciones (Rogers, 1997). Debido a que proyectos de simulación
participan muchas personas, la metodología a seguir puede ser difícil de establecer. El
simulacionista debe entonces tener la capacidad de conocer los métodos de simulación y
proponer cual o cuales serán usados dentro de la metodología que se llegara a establecer.
En general, podemos decir en primera instancia que ¡un simulacionista es una persona que lo
sabe y hace todo! Sin que lleguemos a la exageración, debemos estar concientes que el hecho
de trabajar en un grupo multidisciplinario donde todos hablan un lenguaje (técnico) diferente,
el plasmar una representación de la realidad a través de un modelo matemático, saber cuales
son las herramientas que nos permitan construir tal modelo, confiar en los resultados a través
de una buena validación y que al final la simulación se vea como un producto útil en el que el
usuario se sienta cómodo o satisfecho, sin duda ¡es una tarea muy laboriosa! Los
simulacionistas entonces, deben ser personas preparadas tanto en conocimientos de la técnica
como del trato con las personas y estar siempre dispuestos a acumular experiencias a través de
la vivencia de cada uno de los proyectos en los que participan.
36

37. 37

38. 4.1 Qué es la Ingeniería de Hipermedia
Como usuarios, es probable que por curiosidad nos preguntemos cómo los creadores lograron
los sitios web, ya sean de tipo dinámico o estático. Como desarrolladores nuestras dudas
radican en saber si existe una forma apropiada de poder desarrollarlas.
Las personas que desarrollan aplicaciones informáticas siguen un proceso de ingeniería que se
conoce como ingeniería de software. Existen diferentes metodologías para hacer ingeniería de
software y la hipermedia no puede ser la excepción. Claramente, las aplicaciones web, y en
general las aplicaciones de hipermedia, deben desarrollarse a través de un proceso de
ingeniería de software. También, es importante que sepamos que la ingeniería de software es
una de las ramas de las ciencias de la computación que toma base del principio de
preocupaciones de Dijkstra.
El proceso de ingeniería de software tal como el proceso de ingeniería civil (e.g. la
construcción de una casa) se debe ir dando por etapas, con cierto número de pasos en cada
etapa. A todas estas etapas y la forma en la que se relacionan (en su precedencia y resultados)
le llamamos ciclo de vida de desarrollo del sistema o CVDS. Según Fraternali (1999) en el
caso de una aplicación web los elementos que componen su CVDS son:
1. Análisis de Requerimientos
2. Conceptualización
3. Prototipos y verificación
4. Diseño
5. Implementación
6. Mantenimiento y Evolución.
El Análisis de Requerimientos proporciona básicamente el perfil de nuestro usuario prospecto
y explica la interacción de éste con la aplicación. Por otra parte, la Conceptualización es
representar la aplicación mediante modelos abstractos que explican nuestra visión de la
aplicación lo más general posible. Después podemos dar paso a crear Prototipos y hacer
Verificaciones debido a que suele ser más fácil de identificar los detalles que se pasaron por
alto previamente. Independientemente si realizamos prototipos o no, tomamos los esquemas
conceptuales para derivarlos en otros de un nivel más bajo (más cercanos a la aplicación y su
funcionamiento), entonces decimos que estamos en la etapa de Diseño. Posteriormente en la
Implementación transformamos el diseño en interfaces usables para el usuario escogiendo el
lenguaje en el que la aplicación será entregada, definiendo la arquitectura, entre otras cosas.
Una vez liberada la aplicación, nos encontramos en la Evolución y Mantenimiento porque
obviamente debemos ser capaces de reparar cualquier error o detalle encontrado por los
usuarios, etc.
El CVDS para el desarrollo de una aplicación de hipermedia, y por ende de web, es similar al
de cualquier aplicación de software. Aunque podríamos decir que el parecido es prácticamente
en el nombre de las etapas de la ingeniería. No en todos los casos se nombran de igual manera.
38

39. En vez de que hablemos en metodologías de ingeniería, usamos el término modelo o método.
Un modelo en este caso nos referirá a ese conjunto de productos, formalismos y mecanismos
que iremos usando durante todo el CVDS. Los nombres de las etapas entre los diferentes
modelos pueden cambiar, pero prácticamente son una variante del esquema básico del CVDS
y que se arraigan a un tipo de conceptualización en particular (o metodología previa) dando su
propia versión de éste (en nuestro caso, para el desarrollo de aplicaciones de hipermedia).
Independientemente del Modelo que escojamos para ir desarrollando nuestra aplicación web
existe algo en lo que se enfocan las más usadas y principales: La navegación de la aplicación
diseñada para el usuario prospecto de tal forma que le sea usable. Esto quiere decir que si
trabajamos en aplicaciones web o de hipermedia, siempre debemos estar concientes que el
éxito de la aplicación radica en un buen diseño de navegación. Básicamente porque un buen
diseño navegacional facilita el uso y aprendizaje de la aplicación. Esto es lo que interpreta
Nanard (1995) como el factor humano en el desarrollo de una aplicación de hipermedia.
4.2 OOHDM
El nombre de nuestra aplicación será SymWeb por Simulación y Modelado vía Web.
Empezaremos nuestra metodología haciendo el desarrollo de la aplicación mediante la
ingeniería de hipermedia. También encontraremos detalles relativos a la forma en la que
adaptamos a esta aplicación los 6 pasos de CVDS.
Para el desarrollo de SymWeb escogimos el Modelo de Diseño de Hipermedia Orientado a
Objetos (OOHDM) desarrollado por Daniel Schwabe y Gustavo Rossi (Schwabe et al., 2002).
Los motivos de su selección son que cubre las dimensiones que caracterizan toda aplicación
web según Fraternali (1999) las cuales son:
1. Estructura
2. Navegación
3. Presentación
Además de que su enfoque nos extiende las posibilidades a poder hacer las aplicaciones
reusables y personalizadas (Schwabe et al. 2001a, 2001b).
El OOHDM, como presenta Schwabe (2002), está constituido de las siguientes fases:
1. Análisis de Requerimientos
2. Modelo Conceptual
3. Esquema de Navegación
4. Modelo de Navegación
5. Diseño Abstracto de Navegación
6. Implementación
39

40. Como podemos notar, el OOHDM se “adapta” a las diferentes etapas de CVDS mencionado
anteriormente aunque a simple vista todo parece radicar en tener la conceptualización de la
aplicación basada en el enfoque Orientado a Objetos, que en realidad es la Object Modeling
Technology propuesta por Rumbaugh (1991), pero que presenta la noción de los objetos de
navegación como vistas de los objetos conceptuales en el sentido de base de datos, organiza el
espacio de navegación con la introducción de contextos de navegación, determina la
separación de los aspectos relacionados con la interfaz de usuario con aquellos de la
navegación y nos da explícitamente una identificación de que existen decisiones de diseño que
necesitan ser hechas solo al momento de la implementación.
4.3 Análisis de Requerimientos
El Análisis de Requerimientos del OOHDM está conformado por tres elementos básicos:
1. Escenarios de Usuarios
2. Casos de Uso
3. Diagramas de Interacción de Usuarios
Los últimos son particulares de este modelo, que en síntesis nos presentan el papel de los
“actores” de la aplicación (Schwabe et al. 2000a).
Para completar la fase de Análisis debemos proceder con los siguientes pasos como se indica a
continuación:
4.3.1 Identificación de Roles y Tareas
Un rol o actor es el término que usamos en OOHDM para describir a las entidades que
intervienen en el uso de la aplicación. Como entidad, un actor, puede ejecutar múltiples roles
también. Como SymWeb está enfocado a la simulación de modelos matemáticos veterinarios
por parte de personas interesadas en el tema, entonces definiremos los roles dependiendo de
las características particulares que puede poseer un usuario. El listado de los roles nos queda
como sigue:
Rol Descripción Tareas del Rol
Usuario No Usuario común; es decir, a Conseguir información acerca de lo
aquel que entra a navegar la que es SymWeb.
Registrado
aplicación con meros Registrarse para poder acceder a las
propósitos informativos, por posibilidades de la aplicación.
curiosidad o por accidente
(navegación).
Usuario Registrado Usuario que ha pasado por el Acceder a los diferentes modelos
40

41. proceso de registro en SymWeb publicados.
Simular modelos publicados y
exportar resultados para otros
usuarios.
Graficar los resultados de la
simulación del modelo en uso.
Candidato a ser Usuario Publicador
Usuario Publicador Usuario registrado que tiene la Acceder a los diferentes modelos
capacidad de publicar modelos publicados.
matemáticos para otros Simular modelos publicados y
usuarios registrados exportar resultados para otros
usuarios.
Graficar los resultados de la
simulación del modelo en uso.
Publicar Modelos Matemáticos para
la simulación por parte de otros
usuarios.
Administrador Usuario registrado único que Acceder a los diferentes modelos
tiene la capacidad de publicar publicados.
modelos matemáticos en Simular modelos publicados y
SymWeb pero también tiene la exportar resultados para otros
capacidad de administrar a los usuarios.
usuarios registrados. Graficar los resultados de la
simulación del modelo en uso.
Publicar Modelos Matemáticos para
la simulación por parte de otros
usuarios.
Dar permiso a los usuarios
registrados para publicar.
Dar de baja a los usuarios registrados
y modelos publicados según criterios
del Administrador.
4.3.2 Especificaciones de Escenario
Los Escenarios son descripciones narrativas de cómo la aplicación puede ser usada. (Carroll
citado por Schwabe, 2000). Por lo tanto, una vez que hayamos definido a los diferentes actores
de la aplicación, procederemos a definir si alguno de los actores posee más de un rol; posterior
a esto, pasaremos a hacer las Especificaciones de Escenario tomando las descripciones
narrativas o textuales mencionadas anteriormente. Las especificaciones las podemos hacer
nosotros si somos diseñadores de la aplicación o dejar que los usuarios nos la proporcionen.
Siempre es recomendable la segunda opción. Pero de no ser posible lo anterior, debemos
redactar las especificaciones tal y como procedimos en SymWeb:
41

42. UNR1. Navegar SymWeb
El usuario no registrado o regular accede a la página principal de SymWeb y ve las opciones de
búsqueda, selección de modelos, simulación y graficación de resultados pero no puede acceder
a ellos por lo que tendrá que registrarse. La opción de búsqueda está deshabilitada. El usuario
hace clic al enlace que corresponde a la selección de modelos pero en el contenido de la nueva
página solo encuentra una descripción de la información acerca de la disposición de modelos
para usuarios registrados y se enlistan para que el usuario tenga una idea de los modelos que
podrá usar. En el caso de la sección del simulador y del graficador se encuentra con una
pequeña explicación de su funcionamiento únicamente. El usuario también nota en su acceso
ligas a las entidades participantes como la UADY, Fmat, Facultad de Veterinaria, CONACYT,
entre otras.
UR1. Comenzar la navegación en SymWeb
El usuario registrado accede a SymWeb por medio de su URL entonces accede a la página que
un usuario no registrado encuentra. El usuario procede a introducir su login y su password
para poder tener acceso a las utilidades de la aplicación.
UR2. El usuario simula un modelo matemático y grafica resultados de simulación
El usuario selecciona un modelo de la sección donde se encuentra la lista de modelos. Se
actualiza la aplicación mostrando la información del modelo junto con las variables de estado
o parámetros y sus respectivos valores por defecto, entonces puede cambiar los valores si
desea. Procede a ejecutar la simulación. La aplicación se actualiza proporcionando de forma
tabulada los resultados de las variables de estado o parámetros graficables. Entonces el usuario
puede ir a la sección del graficador y seleccionar de las variables de estado o parámetros
graficables una o más para que el graficador presente su curva correspondiente. Si el usuario
va a la sección del graficador sin haber efectuado simulación alguna, ninguna gráfica podrá
estar disponible.
UR3. Cambiar o actualizar el perfil de usuario
Después de pasar por UR1, el usuario accede a la sección del perfil de usuarios. La aplicación
se actualiza y entonces despliega los datos de los usuarios que fueron proporcionados
previamente en su registro. El usuario puede cambiar los valores y entonces proceder a
actualizarlos. También en esta sección se encuentra la opción de darse de baja como usuario
registrado con lo que el rol cambia a un escenario UNR1.
UR4. Enterarse de que eres publicador
Según criterios del Administrador, el usuario registrado es ahora un publicador de modelos. El
usuario no necesariamente está navegando SymWeb pero si está verificando su correo vía web
o tiene su cliente de correo electrónico activo, entonces ve que tiene un nuevo correo por parte
del administrador de SymWeb donde le indica que se ha vuelto publicador y cómo ha de
proceder para la publicación de modelos.
UP1. Publicación de un modelo matemático en SymWeb
El usuario es un usuario registrado que ha accedido a la aplicación como todos los demás,
además ha recibido una notificación vía correo electrónico en la que se le indica que es
42