1. CONSTRUCCION DE MODELOS DE SIMULACION ORIENTADOS A
ALENTAR LA PARTICIPACION DE USUARIOS FINALES UTILIZANDO
UML
Área temática: Avances Teóricos
ING. GUSTAVO TRIPODI - gtripodi@exa.unicen.edu.ar
ING. GUSTAVO ILLESCAS - illescas@exa.unicen.edu.ar
Facultad de Ciencias Exactas - Universidad Nacional del Centro de la Provincia de Buenos Aires. Grupo de
Investigación en Informática de Gestión - Teléfono: +54 2293 432466. Dirección postal: Campus Universitario,
Paraje Arroyo Seco, (7000) Tandil, ARGENTINA
RESUMEN
El presente trabajo es una ampliación y actualización de una presentación
realizada en Mayo de 1999 en Santa Rosa, La Pampa, durante la X EPIO
(Escuela de Perfeccionamiento en Investigación Operativa) denominado: “Una
metodología para implementar simulaciones en una PyME orientada a alentar
la participación de Usuarios Finales” cuyos autores fueron el Dr. Hugo P.
Moruzzi y el Ing. Gustavo D. Tripodi.
La metodología propuesta para desarrollar e implementar proyectos de
Simulación comienza con una etapa de Modelización de la realidad que se
quiere analizar en la cual deben estar involucrados, tan activamente como sea
posible, los Usuarios Finales (UF). Esta actividad debería servir además, para
capacitarlos en el entendimiento de ciertos formalismos y estructuras basados
en herramientas de Investigación Operativa (IO).
La propuesta es, entonces, realizar la planificación e implementación de
mejoras en un proceso trabajando en forma grupal con una metodología
específica
Esta concepción de abordar las Simulaciones nos orienta hacia la
elaboración de Modelos que contengan el Ciclo de vida del Proyecto en
cuestión
La propuesta es trabajar sobre un ambiente para la construcción de
simulaciones, basado en una metodología que permite integrar al usuario de
una manera activa en el proceso de implementación a través de UML (Unified
Modeling Language), lenguaje que nos aporta el marco necesario para
construir e integrar modelos desde el Relevamiento al Software.
PALABRAS CLAVE
UML – MODELO NATURAL – MODELO DEL USUARIO – MODELO DEL
PROGRAMADOR – HERRAMIENTAS CONCEPTUALES - HERRAMIENTAS
DOCUMENTALES
INTRODUCCION
La metodología propuesta para desarrollar e implementar proyectos de
Simulación comienza con una etapa de Modelización de la realidad que se
quiere analizar en la cual deben estar involucrados, tan activamente como sea
1

2. posible, los Usuarios Finales (UF). Esta actividad debería servir además, para
capacitarlos en el entendimiento de ciertos formalismos y estructuras, basados
en herramientas de Investigación Operativa (IO). Cabe destacar que cuando
hablamos de UF, estamos haciendo referencia a las personas a quienes
resultaría de utilidad los resultados que se obtengan al correr programas
elaborados sobre la base de los modelos que representaran la operación que
se desea simular.
Es fundamental la formación de Grupos homogéneos para poder
realizar este tipo de capacitación y entrenamiento. El perfil del UF en la
simulación de operaciones empresarias resulta ser el de las personas
encargadas de la operación y que conforman lo que denominaremos Grupo
Operativo (GO). El problema consiste en encontrar una forma de motivar a este
Grupo Operativo para que realice esta labor en forma conjunta.
La propuesta es efectuar la planificación e implementación de mejoras
en el proceso trabajando en forma grupal con una metodología específica.
Esta concepción de abordar las Simulaciones nos orienta hacia la
elaboración de Modelos que contengan el Ciclo de vida del Proyecto.
El ambiente propuesto proponemos para la construcción de
simulaciones, esta basado en una metodología que permite integrar al usuario
de una manera activa en el proceso de implementación. El objetivo es que a
partir del Modelo Real se cimiente el Modelo Natural (MN), informal, (que posee
mentalmente el UF de la operación), se construya un modelo completo,
pasando por un Modelo del Usuario (MU) hasta llegar a un Modelo para el
programador (MP) y como consecuencia el software. El lenguaje UML (Unified
Modeling Language) nos aporta el marco necesario para construir e integrar
modelos de Simulación desde el modelo real al Software. Esta es una
herramienta de cohesión que permite la evolución y refinamiento de los
modelos descriptos. Es un ambiente que permite un desarrollo iterativo e
incremental de Ciclo de Vida de la Simulación.
LOS MODELOS
Partiendo del MN, el MU facilitará la generación de modelos mucho más
formales y detallados para el Programador (MP), que contendrá todo lo
necesario para elaborar el pseudocódigo de la simulación. [BEC91]. El MN y el
MU no incluyen conceptos asociados en general con ningún lenguaje ni
paradigma de elaboración de programas. Su objetivo es rescatar de la realidad,
con una activa participación del UF, un cierto número de objetos y de los
estados que resulten de interés para el objetivo de la Simulación.
El MU nos deja en los umbrales del diseño del software de simulación,
es una herramienta de comunicación que nos permite la interacción con los UF
y Programadores. El MP esta formado por los modelos para programar, que
formalizan aún más el MU, agregando una especificación completa y precisa
de la operación de tal manera que a partir de ellos se pueda elaborar un
programa que implemente dicha simulación. Es decir, los modelos extremos
son: el modelo real y el código de la simulación.
2

3. Se establecieron herramientas que permiten representar en forma
abstracta el modelo real. Estas herramientas son básicamente: conceptuales,
documentales o un mix de ambas.
En esta metodología se consideran herramientas documentales a las
que solo "pasan en limpio" las ideas que el usuario ya tiene sobre la operación.
Generalmente se usan para comunicar una idea y no para construirla, el
Isomorfismo en esta abstracción no pasa por la construcción del modelo sino
por su representación.
Por otro lado Herramientas conceptuales son aquellas que tienen
comúnmente una serie de reglas estrictas en cuanto a su definición y validez
por lo que su elaboración es de alguna forma isomórfica con la construcción de
la idea que se quiere representar. Esto hace que sean herramientas que
ayudan al diseño del modelo y establecen una retroalimentación con el usuario
sobre las ideas que quiere representar.
Las herramientas de UML utilizadas son:
• Narrativa e infografía documental
• Diagrama general de actividades documental
• Casos de Uso documental/conceptual
• Grafo de transición de estados documental/conceptual
• Objetos. Diagramas de Clases conceptual
• Diagramas de Colaboración. conceptual
• Diagramas de Secuencia conceptual
Objetivos de los Modelos
En primer lugar no se debe perder de vista el objetivo del proyecto:
hacer una simulación. Por lo tanto los modelos deberán contener toda la
información referente al problema que hay que ayudar a resolver.
Cuando se mencionan problemas, son los asociados con la toma de
decisiones por parte de los UF, con respecto a posibles alternativas de
operación o de infraestructura. Es decir, se trata de ver cual es la forma más
eficiente de introducir cambios, tratando de mejorar la operación y/o proceso
encontrando la mejor relación costo / beneficio.
Profundizando los conceptos de la metodología y teniendo presente la
función de control que ejerce el UF de una operación no se puede obviar un
hecho muy importante: un programa que simula la operación ayuda a
implementar un control en tiempo real y a conocer mejor la operación. Puede
decirse que un proyecto de Simulación introduce el método científico en la
operación empresaria.
Características de los Modelos
Para cumplir con los objetivos fijados el MU deberá tener las siguientes
características:
• Completos: es decir, describir la realidad que se desea simular con el
grado de abstracción que se haya considerado apropiado para encarar el
problema que se quiere resolver mediante la simulación que se va a
implementar.
• Precisos: Verbalmente, debe alejarse del lenguaje natural y usar símbolos
para representar los objetoss y relaciones que lo integren. Gráficos y
3

4. esquemas deben incluirse toda vez que sea conveniente; Numéricamente,
debe ser coherente respecto de la precisión con la que se expresen los
valores de los atributos cuantitativos.
• No crípticos: el simbolismo introducido debe ser representativo para llegar
a distintos tipos de Usuarios con distinta expertise. Dentro de un GO debe
esperarse heterogeneidad en las capacidades de aprendizaje, en
consecuencia el analista deberá tener en cuenta esta situación y actuar de
acuerdo con el nivel del grupo.
• No introducir el menor vestigio de la jerga computacional en el MU :
este punto esta asociado con el anterior. Términos como "arreglos",
"registros", "tipos de datos", "conjuntos", etc. que usan palabras comunes
del lenguaje natural pero con diferentes sentidos. deben ser
cuidadosamente evitadas cuando se introducen descripciones en el MU.
Si en Análisis de Sistemas se recomienda no mezclar los "qué" con los
"cómo" esto es doblemente cierto cuando se pretende insertar al UF en la
elaboración del MU.
• Por lo expuesto, y salvo el hecho de usar una notación entendible por el UF
no habría hasta ahora diferencias sustanciales entre un Modelo para
realizar Simulaciones y un Modelo conceptual del tipo preconizado en
Análisis de Sistemas pero con un agregado: con ligeras variantes la
estructuras propuestas sirven para encarar el control de la operación que se
va a simular, y esto es muy importante para el UF.
Ubicación de los modelos en un proyecto de simulación
Al tratar el tema de hacer Modelos para ser usados en un Proyecto de
Simulación es conveniente reconocer la existencia de más de un modelo entre
las siguientes dos realidades: i) la operación a simular, en un extremo, y ii) el
software a utilizar para llevar a cabo la simulación, por el otro. Esto implica la
aparición de las correspondientes interfases entre estos modelos
Como se dijo anteriormente existen dos realidades isomorfas: una, el
proceso a simular; la otra: su representación en un equipo de computación, que
corresponden a programas que simularan el proceso en cuestión.
Para pasar de una realidad a otra hay una serie de intelectualidades que
llamamos modelos, que pueden o no plasmarse en material escrito,
iconográfico o impreso. Hemos establecido su número y contenido, cada uno
de ellos es elaborado y/o usado por uno o más usuarios. Para cada uno de los
modelos se especifica la nomenclatura en la tabla I
NOMBRE CODIGO HUESPED FORMAL´D DETALLE ORIENTA´N
Usuario/
natural MN Informal mucho A la operación
Analista
del usuario MU Analista Formal poco al proceso
Analista/
del programador MP Muy Formal mediano al software
Programador
Tabla I - Modelos
4

5. Para estos Modelos existen transiciones, secuenciadas en dos
interfases: MN/MU y MU/MP. Si se quisiera establecer el lugar físico en donde
se encuentran estas interfases, se pueden situar en la interrelación de distintos
huéspedes. Esto es importante ya que equivale a reconocer que el Analista -
que cumplen los distintos roles allí descriptos- debe ser consciente que tiene en
su mente tres modelos: MN, MU y MP, cada uno de ellos adecuados a un tipo
de situación en la que deben actuar y tomar decisiones.
(Natural: N . Del Usuario: U . Del Programador: P) Modelo
• Narrativa, Infografía N
• Diagrama General de Actividades N/U
• Casos de Uso N/U
• Grafo de Transición de Estados U
• Objetos. Diagrama de Clases U/P
• Diagramas de Colaboración U/P
• Diagramas de Secuencia P
Estos dos tipos de interfases presentan dos problemas: i) la necesidad
que el Analista se concientice de la existencia de tres visiones de una misma
realidad; ii) el problema de comunicación entre dos equipos: GO y
programadores. Cabe destacar que estas dificultades persisten aunque analista
y programador sean la misma persona, por la exigencia de discriminar los
momentos en que debe asumirse un rol u otro.
UML: Unified Modeling Language
El UML ofrece una notación sintáctica y semántica estándar para
describir estructuras y comportamiento de Objetos [QUA00].
Durante los años noventa diferentes metodologías con sus notaciones
fueron introducidas al mercado. Tres de los métodos mas populares fueron:
OMT (Rumbaugh), Booch y OOSE (Jacobson). Cada una de ellas aportaba
valor en distintas áreas. OMT en análisis, Booch en diseño y Jacobson en
análisis de comportamiento. Luego de publicaciones en las cuales participaban
en forma conjunta los métodos comenzaron a converger pero la notación
seguía siendo divergente. Hasta que lograron consensuar una notación: UML.
“Es un lenguaje utilizado para especificar, visualizar y documentar los
artefactos de un sistema orientado a objetos bajo desarrollo”. Aunque los
métodos anteriormente citados fueron la base para la fundación de UML
también participaron otros autores con sus metodologías: Meyer (pre and post
conditions), Harel (state charts), Wirfs-Brock (responsabilities), Fusion,
(Operations descriptions, message numbering), Embly (Singleton classes),
Gamma (frameworks, patterns, notes), Shlaer-Mellor (Objects Life Cycles) y
Odell (classification)
Modelación Visual
Es una forma de tratar los problemas usando modelos iconográficos e
interactivos organizados alrededor de las ideas del mundo real. Este tipo de
5

6. modelización posee reglas sintácticas y semánticas para lograr isomorfismo
entre lo que se construye y lo que se quiere representar.
La abstracción es una capacidad humana fundamental que permite tratar la
complejidad. Para construir diseños complejos el Analista debe abstraer
diferentes vistas del Sistema, construir modelos utilizando notación precisa,
verificar que el modelo satisface los requerimientos y gradualmente adicionar
detalles para transformar el modelo en una aplicación.
Se construyen modelos para entender Sistemas complejos porque no es
posible abarcarlos como una integridad y comunicarlos en forma precisa. Hay
límites en la capacidad humana para entender complejidades. Construir un
modelo permite al analista focalizarse en como las grandes partes del Sistema
interactúan sin tener que profundizar en detalles específicos de cada
componente. Los modelos ayudan a organizar, entender y crear cosas
complejas.
El triangulo para asegurar el cumplimiento del Objetivo: Se necesita contar
con tres aspectos para tener éxito en el Ciclo de Vida de un Proyecto:
i) Una notación. Para comunicar el modelo (sintáctica y semántica)
ii) Un proceso. Como usar la notación (interactiva e incrementalmente)
iii) Una herramienta. Sostén de la notación y el proceso
UML brinda estas 3 dimensiones y acompaña la evolución del Proyecto en los
estadíos de desarrollo, integración y comunicación.
Figura 1 -
Desarrollo interactivo e incremental: Se ejecutan cierta cantidad de
iteraciones hasta llegar al sistema final. En cada iteración se agregan
incrementalmente detalles al modelo. El analista asume que todos los
requerimientos y detalles no son conocidos al comenzar el Ciclo de Vida,
entonces cada definición anterior es revisada en la próxima iteración donde se
agregan nuevos objetos y comportamientos. Construir el Sistema de esta forma
mitiga los riesgos asociados con el desarrollo de Proyectos complejos
6

7. Figura 2
ELABORACIÓN DE LOS MODELOS
En la bibliografía [FIS92] se definen dos formas básicas de elaborar
modelos: i) la declarativa y ii) la funcional. En simulación, la primera forma
pone el énfasis en los Objetos, su análisis e interrelación, mientras que la
segunda lo hace en los eventos o actividades.
La mayor parte de los paquetes comerciales para hacer simulación se
basan en metodologías funcionales. Para facilitar la tarea del usuario se le pide
que describa -habitualmente mediante gráficos que tienden a ser icónicos- el
proceso a simular. El modelo resultante consiste en una simple descripción del
proceso visto como una serie de lugares físicos en los que ocurren cosas;
básicamente, se realizan operaciones o se forman colas de espera. A esto se
agregan las condiciones que deben cumplirse para que se lleven a cabo las
operaciones o para sacar algún ítem de la cola.
En nuestro caso hemos preferido adoptar un modelo declarativo. Esta
selección se basa en las siguientes consideraciones:
• Desde el punto de vista del usuario que debe manejar una operación, su
interés está centrado en la utilización eficiente de equipos, personal,
materiales, etc. que entran al proceso. Es decir, objetos -entes materiales-
que tienen ya sea un costo unitario o bien un costo por unidad de tiempo.
Es él -el UF- quién cuidará que esos objetos interactúen correctamente en
las distintas actividades para maximizar la productividad del sistema. El
análisis por objetos tiene mayor poder analítico que el de las actividades en
las que intervienen. La mayor parte de las medidas de performance se
refieren a relaciones entre tiempos productivos y tiempos no productivos de
los objetos que interaccionan en la operación. Un análisis de los estados en
los que pueden hallarse cada objeto lleva a evaluar directamente la
performance de dicho objeto en la operación.
• La estructura que debe tener un modelo conceptual de un sistema dinámico
que se va a simular por algún paradigma de eventos discreto se basa en
señalar en una línea de tiempo los puntos (instantes) que marcarán el
avance "a saltos" de la simulación. Estos instantes corresponden a aquellos
en los que los Objetos cambian de estado. Los objetos elegidos para
integrar el modelo conceptual quedan restrictivamente definidos por el
7

8. conjunto de atributos -propiedades-. El conjunto de valores que toman estos
atributos en un instante dado definen el estado del objeto. Los cambios de
valores de las propiedades de los Objetos establecen un nuevo estado
particular y por ende del sistema. La relación entre realidad y modelo se
torna así transparente. El usuario debe comprender que a través de la
selección de objetos, atributos y estados se constituye en el controlador del
modelo que se va a usar para simular.
8

9. Herramientas de los Modelos
En lo que sigue se describe someramente las herramientas que
conforman la metodología para elaborar los modelos:
• Narrativa, Infografía. Modelo Natural
La narrativa es una descripción de las actividades que el sistema va a incluir
para la simulación. Debe ser clara, precisa y consensuada con el Usuario.
Elementos: Documentos e Infografía.
Ejemplo de narrativa
En un taller se procesan dos tipos de piezas: las Tapas (T) y los
Cuerpos (C). Las Tapas reciben primero un maquinado que se lleva a
cabo en Puestos de Trabajo del tipo 1 (PT1) y luego deben recibir otro
maquinado que se lleva a cabo en Puestos de Trabajo de tipo 2 (PT 2).
Los Cuerpos, en cambio, reciben primero el maquinado en los PT 2 y
luego en los PT 1. La duración de estos procesos es la siguiente En los
PT 1, el procesamiento de las Tapas toma 3 minutos y el de los
Cuerpos, 5 minutos. En los PT 2, en cambio, el proceso de las Tapas
toma 5 minutos y el de los Cuerpos, 3 minutos.
En promedio, cada 4.3 minutos llega una pieza; los porcentajes de T y
de C son iguales y el orden de las llegadas es aleatorio.
Los tiempos entre llegadas se distribuyen en forma exponencial y los
tiempos de procesamiento lo hacen en forma log normal con desviación
estándar de dos minutos,
Cuando un PT está ocupado la pieza que llega para ser procesada hace
cola en un área situada al lado del PT y que nunca se agota; es decir,
no hay límite para la cola.
Se desea simular la operación para analizar las siguientes alternativas
de trabajo:
i) Cambio en las proporciones relativas de los dos tipos de
piezas.
ii) Prioridad en atención de piezas.
iii) Incorporar mayor cantidad de puestos de trabajo.
• Casos de Uso. Modelo Natural/Modelo del Usuario
Este Modelo brinda una aproximación de las actividades involucradas. Los
casos de uso no poseen secuencia, permiten establecer el límite de la
Simulación a realizar, comenzar a identificar objetos relevantes y una
interrelación básica entre actividades y Objetos.
9

10. Tapa
Procesar T apa en PT 2 Procesar T apa en PT 1 PT1
PT2
Procesar Cuerpo en PT 1
Procesar cuerpo en PT 2
Cuerpo
Figura 3 -
• Diagrama General de Actividades (DGA). Modelo Natural/Modelo del
Usuario
Se utiliza para limitar el ámbito de la simulación. Es la primera versión
icónica que da una idea del proceso a resolver.
Llegada Pieza
Espera de Espera de
Pieza por PT1 Pieza por PT2
Proceso de Proceso de
Pieza en PT1 Pieza en PT2
Salida de Pieza
Figura 4 -
10

11. • Grafos de Transición de Estados (GTE). Modelo del Usuario
Se realiza un GTE por Objeto. Los nodos representan los estados
reconocidos de un objeto. Las flechas que conectan los nodos indican las
transiciones que serán consideradas en el modelo.
Se deberá incluir en este modelo:
 Instancias del ATRIBUTO Estado para cada uno de los Objetos.
 Definición Operacional de Cada uno de los Estados.
Tapa Cuerpo
llegpie llegpie
qpt1 qpt2
propt1 propt2
qpt2 qpt1
propt2 propt1
salpie salpie
Figura 6 -
11

12. PT1 QPT1
libre
n
n+1
ocupado
n-1
Figura 5 -
Cabe destacar que es muy importante la definición operacional de cada
uno de los estados para introducir precisión en el Modelo
Definiciones Operacionales: son documentos que permiten comunicar
procedimientos para dar precisión y completitud al modelo
Ejemplo: ante la situación que se muestra en el siguiente gráfico se puede
cometer un grave error si no se da una definición precisa de procedimiento:
Líneas de Productos Espera por Líneas de
Producción Semielaborados recurso Producción
LP1 pa Qrj rj LP3
LP2 pb Qrk LP4
Figura 7 -
Para comenzar a procesar productos semielaborados pb en la línea de
producción LP3 se necesita un ajuste (setup) sobre esta. Se puede cometer el
error de cargar tiempos de espera por el recurso rj y realmente se espera por
la línea de producción en condiciones.
12

13. • Objetos. Diagrama de Clases. Modelo del Usuario/ Modelo del
Programador
Según la narrativa, los casos de uso, el D.G.A. y los GTE continuamos
definiendo los Objetos de la simulación. Comienza el refinamiento de los
Objetos
Pieza
DT ll egada : funcion
DT proceso : funcion
Obtener tiempo de Proceso()
Obtener T iempo Llegada()
Tapa
(f rom Casos de Uso) Cuerpo
(f rom Casos de Uso)
PuestoTrabajo
Cola
PT1 PT2
(f rom Casos de Uso) (f rom Casos de Uso) QPT1 QPT2
Figura 8 -
Con las herramientas utilizadas hasta aquí se realizo un
profundo y exhaustivo análisis por cada uno de los Objetos 13
que intervienen en la simulación. Con la aplicación de los
Diagramas que siguen, de Colaboración y Secuencia, se
recupera el sentido de las actividades del proceso a Simular

14. • Diagrama de Colaboración. Modelo del Usuario/ Modelo del
Programador
Cuando ocurre un evento se producen cambio de Estados en los Objetos.
Las Transiciones de Estados de los Objetos en forma concurrente se
individualizan en consenso con el UF y por el conocimiento adquirido en las
distintas etapas del relevamiento.
Esta instancia es clave ya que estamos definiendo los Eventos fijos y
Condicionales que serán incluidos en la Simulación. Los Eventos
Condicionales como la expresión lo indica son aquellos que tienen lugar
cuando ciertas condiciones se cumplen. Los Eventos Fijos son aquellos
cuyo tiempo de ocurrencia es predecible, es decir que la condición para que
se dispare es que el tiempo asignado a ese evento sea igual al tiempo de la
Simulación
Ejemplo: Para procesar un Lote en un Puesto de Trabajo tendremos que
tener como mínimo un Lote esperando a ser procesado y un Puesto de
Trabajo disponible para llevar adelante esta actividad, con lo que se
conforman las dos condiciones del Evento, como consecuencia estos dos
objetos colaboran para comenzar la actividad de procesar un Lote en un
Puesto de Trabajo y asignar un tiempo de finalización al proceso según una
función predeterminada. Esto lleva a registrar que en un cierto instante se
va a producir la finalización del Proceso, con lo que tenemos la ejecución
del Evento fijo. Es decir que el motor de la simulación trabaja de la siguiente
manera: ejecuta los eventos Fijos que se Produzcan en cierto instante de
tiempo seteando en reloj interno de la simulación en este instante y luego
evalúa todos los Eventos Condicionales para ver si alguno puede ser
ejecutado.
1: Elementos en QPT1( )
: QPT1
4: Iniciar Proceso( )
2: Estado de PT1( )
: PT1 : Inicio Proceso en
PT1
3: Obtener Pieza( )
: Pieza
Figura 9 -
14

15. • Diagrama de Secuencia. Modelo del Programador
Secuencia de eventos para iniciar, ejecutar y culminar una actividad con
todos los Objetos involucrados.
: Inici o Proceso : PT1 : QPT1 : Pieza : Fin Proceso
en PT1 en PT1
Estado de PT1( )
Elementos en QPT1( )
Iniciar Proceso( )
Obtener Pieza( )
Fin Proceso en PT1( )
Figura 10 -
CONCLUSIONES
Si se actúa sagazmente es posible lograr como objetivo final de la
elaboración de los Modelos la participación activa del Usuario Final. Por eso
una de las etapas del modelo se denomina Modelo del Usuario y no para el
Usuario.
Dada la forma de encarar esta inserción del Usuario Final, se trata de
cumplir una función didáctica especial ya que no se estará haciendo modelos
para un sistema dado, se estará enseñando a hacer Modelos con una
determinada estructura. Se estará creando nuevas estructuras para ver una
realidad.
Los modelos visuales mejoran el entendimiento de los problemas, la
comunicación, la elaboración de documentación y el diseño de programas. Este
tipo de modelización promueve un mejor entendimiento de los requerimientos,
diseños limpios y sistemas más fáciles de mantener.
UML es un lenguaje estándar y Universal que nos permite interactuar con
distintos actores de diferentes ámbitos y regiones para la consecución de un
Proyecto de Simulación
BIBLIOGRAFIA
15

16. • ALO96 Alonso Daniel. Morfología de las herramientas de diseño. Diseño de
Sistemas (Fascículo 57), Buenos Aires, 1996.
• AUS91 Austin Wanda M. y Behrokh Khoshnevis. Qualitative modelin using
natural languages: an application in system dynamics. Qualitative simulation
modeling and analysis. Spring-Verlag, New York, 1991.
• BEC91 Beck, Howard W. y Paul A. Fishwick. Natural Language, cognitive
models and simulation. Qualitive simulation modeling and analysis, Spring-
Verlag, New York, 1991.
• BUN72 Bunge Mario; Teoría y Realidad; Editorial Ariel; 1972.CAR86Card
David N., Victor E. Church & William W. Agresti, "An Empirical Study of
Software Design Practices", IEEE Trans on Soft. Eng. Vol 12 Nº 2, Feb
1986.
• CHA90 Chang Shi-kuo (Editor), "Visual programming systems" Prentice
Hall; 372 PA.1990
• DAV93 Davies Alan M. Software requeriments: Objets, functions and states.
Prentice Hall, New Jersey, 1993
• DIJ82 Dijkstra E.W. Selected Writings on Computing: A Personal
Perspective. New York: Springer Verlag, 1982.EIS47Eisenhart, Churchill.
"The Assumptions Underlying the Analysis of Variance", Biometrics, III, Nro.
1, 1947.
• FIS92 Fishwick Paul A. An Integrated Approach to System Modeling Using a
Synthesis of Artificial Intelligence, Software Engineering and Simulation
methodologies. Transactions of Model and Computer Simulation, Vol 2, No.
4, Oct. 1992; pp 307-330.
• GOL93 Goldsmith Sylvia. A practical guide to real time systems
development. Prentice Hall International, London, 1993.
• KLI69 Klir George J. An approach to general system theory. Van Nostrand
Reinhold, New York, 1969.
• MOR95 Moruzzi Hugo P. Hacer Modelos. Notas de Clase I, Tandil, 1995.
• MOR96 Moruzzi Hugo P. Elaborando el modelo del usuario, una forma
eficaz de iniciar la implementación de un proyecto de simulación. ISITAN,
Tandil, 1996.
• Moruzzi Hugo P. y Tripodi Gustavo D.: Una metodología para implementar
simulaciones en una PYME orientada a alentar la participación de Usuarios
Finales. Trabajo presentado en la X EPIO (Escuela de Perfeccionamiento
en Investigación Operativa)
Mayo de 1999 – Santa Rosa, La Pampa.- Argentina
• NAN81 Nance Richard, The Time and States Relationship in Simulation
Modeling. Comm. of ACM, April 1981, Vol 24, Nro.4 pp173-179.
• PIR75 Pirsing Robert. Zen and the art of motorcycle maintenance. Bantam
New Age Books. 1975.
• QUA00 Quatrani, Terry. Visual Modeling with Rose 2000 and UML. Pre-
Press Co., Inc. EEUU, 2000. ISBN 0201699613
16