SIMULACIN

CONSTRUCCION DE MODELOS DE SIMULACION ORIENTADOS A

ALENTAR LA PARTICIPACION DE USUARIOS FINALES UTILIZANDO
UML
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
Investigacin en Informtica de Gestin - Telfono: +54 2293 432466. Direccin postal: Campus Universitario,
Paraje Arroyo Seco, (7000) Tandil, ARGENTINA

RESUMEN
El presente trabajo es una ampliacin y actualizacin de una presentacin realizada en
Mayo de 1999 en Santa Rosa, La Pampa, durante la X EPIO (Escuela de
Perfeccionamiento en Investigacin Operativa) denominado: Una metodologa para
implementar simulaciones en una PyME orientada a alentar la participacin de
Usuarios Finales cuyos autores fueron el Dr. Hugo P. Moruzzi y el Ing. Gustavo D.
Tripodi.
La metodologa propuesta para desarrollar e implementar proyectos de
Simulacin comienza con una etapa de Modelizacin de la realidad que se quiere
analizar en la cual deben estar involucrados, tan activamente como sea posible, los
Usuarios Finales (UF). Esta actividad debera servir adems, para capacitarlos en el
entendimiento de ciertos formalismos y estructuras basados en herramientas de
Investigacin Operativa (IO).
La propuesta es, entonces, realizar la planificacin e implementacin de
mejoras en un proceso trabajando en forma grupal con una metodologa especfica
Esta concepcin de abordar las Simulaciones nos orienta hacia la elaboracin
de Modelos que contengan el Ciclo de vida del Proyecto en cuestin
La propuesta es trabajar sobre un ambiente para la construccin de
simulaciones, basado en una metodologa que permite integrar al usuario de una
manera activa en el proceso de implementacin a travs 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 metodologa propuesta para desarrollar e implementar proyectos de
Simulacin comienza con una etapa de Modelizacin de la realidad que se quiere
analizar en la cual deben estar involucrados, tan activamente como sea posible, los
Usuarios Finales (UF). Esta actividad debera servir adems, para capacitarlos en el
entendimiento de ciertos formalismos y estructuras, basados en herramientas de
Investigacin Operativa (IO). Cabe destacar que cuando hablamos de UF, estamos
haciendo referencia a las personas a quienes resultara de utilidad los resultados que
se obtengan al correr programas elaborados sobre la base de los modelos que
representaran la operacin que se desea simular.

FINESI

SIMULACIN
Es fundamental la formacin de Grupos homogneos para poder realizar este
tipo de capacitacin y entrenamiento. El perfil del UF en la simulacin de operaciones
empresarias resulta ser el de las personas encargadas de la operacin 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 planificacin e implementacin de mejoras en el
proceso trabajando en forma grupal con una metodologa especfica.
Esta concepcin de abordar las Simulaciones nos orienta hacia la elaboracin
de Modelos que contengan el Ciclo de vida del Proyecto.
El ambiente propuesto proponemos para la construccin de simulaciones, esta
basado en una metodologa que permite integrar al usuario de una manera activa en el
proceso de implementacin. El objetivo es que a partir del Modelo Real se cimiente el
Modelo Natural (MN), informal, (que posee mentalmente el UF de la operacin), 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 Simulacin desde el modelo real al Software. Esta es una
herramienta de cohesin que permite la evolucin y refinamiento de los modelos
descriptos. Es un ambiente que permite un desarrollo iterativo e incremental de Ciclo
de Vida de la Simulacin.
LOS MODELOS
Partiendo del MN, el MU facilitar la generacin de modelos mucho ms
formales y detallados para el Programador (MP), que contendr todo lo necesario para
elaborar el pseudocdigo de la simulacin. [BEC91]. El MN y el MU no incluyen
conceptos asociados en general con ningn lenguaje ni paradigma de elaboracin de
programas. Su objetivo es rescatar de la realidad, con una activa participacin del UF,
un cierto nmero de objetos y de los estados que resulten de inters para el objetivo
de la Simulacin.
El MU nos deja en los umbrales del diseo del software de simulacin, es una
herramienta de comunicacin que nos permite la interaccin con los UF y
Programadores. El MP esta formado por los modelos para programar, que formalizan
an ms el MU, agregando una especificacin completa y precisa de la operacin de
tal manera que a partir de ellos se pueda elaborar un programa que implemente dicha
simulacin. Es decir, los modelos extremos son: el modelo real y el cdigo de la
simulacin.
Se establecieron herramientas que permiten representar en forma abstracta el
modelo real. Estas herramientas son bsicamente: conceptuales, documentales o
un mix de ambas.
En esta metodologa se consideran herramientas documentales a las que solo
"pasan en limpio" las ideas que el usuario ya tiene sobre la operacin. Generalmente
se usan para comunicar una idea y no para construirla, el Isomorfismo en esta
abstraccin no pasa por la construccin del modelo sino por su representacin.
Por otro lado Herramientas conceptuales son aquellas que tienen comnmente
una serie de reglas estrictas en cuanto a su definicin y validez por lo que su
elaboracin es de alguna forma isomrfica con la construccin de la idea que se quiere
representar. Esto hace que sean herramientas que ayudan al diseo del modelo y
establecen una retroalimentacin con el usuario sobre las ideas que quiere
representar.
Las herramientas de UML utilizadas son:

FINESI

SIMULACIN

Narrativa e infografa
Diagrama general de actividades
Casos de Uso
Grafo de transicin de estados
Objetos. Diagramas de Clases
Diagramas de Colaboracin.
Diagramas de Secuencia

documental
documental
documental/conceptual
documental/conceptual
conceptual
conceptual
conceptual

Objetivos de los Modelos

En primer lugar no se debe perder de vista el objetivo del proyecto: hacer una
simulacin. Por lo tanto los modelos debern contener toda la informacin 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 operacin o de
infraestructura. Es decir, se trata de ver cual es la forma ms eficiente de introducir
cambios, tratando de mejorar la operacin y/o proceso encontrando la mejor relacin
costo / beneficio.
Profundizando los conceptos de la metodologa y teniendo presente la funcin
de control que ejerce el UF de una operacin no se puede obviar un hecho muy
importante: un programa que simula la operacin ayuda a implementar un control en
tiempo real y a conocer mejor la operacin. Puede decirse que un proyecto de
Simulacin introduce el mtodo cientfico en la operacin empresaria.
Caractersticas de los Modelos
Para cumplir con los objetivos fijados el MU deber tener las siguientes
caractersticas:
Completos: es decir, describir la realidad que se desea simular con el grado de
abstraccin que se haya considerado apropiado para encarar el problema que se
quiere resolver mediante la simulacin que se va a implementar.
Precisos: Verbalmente, debe alejarse del lenguaje natural y usar smbolos para
representar los objetoss y relaciones que lo integren. Grficos y esquemas deben
incluirse toda vez que sea conveniente; Numricamente, debe ser coherente
respecto de la precisin con la que se expresen los valores de los atributos
cuantitativos.
No crpticos: 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 situacin 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. Trminos 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 Anlisis de Sistemas se recomienda no mezclar los "qu" con los "cmo"
esto es doblemente cierto cuando se pretende insertar al UF en la elaboracin del
MU.
Por lo expuesto, y salvo el hecho de usar una notacin entendible por el UF no
habra hasta ahora diferencias sustanciales entre un Modelo para realizar
Simulaciones y un Modelo conceptual del tipo preconizado en Anlisis de Sistemas
pero con un agregado: con ligeras variantes la estructuras propuestas sirven para

FINESI

SIMULACIN
encarar el control de la operacin que se va a simular, y esto es muy importante
para el UF.
Ubicacin de los modelos en un proyecto de simulacin
Al tratar el tema de hacer Modelos para ser usados en un Proyecto de
Simulacin es conveniente reconocer la existencia de ms de un modelo entre las
siguientes dos realidades: i) la operacin a simular, en un extremo, y ii) el software a
utilizar para llevar a cabo la simulacin, por el otro. Esto implica la aparicin de las
correspondientes interfases entre estos modelos
Como se dijo anteriormente existen dos realidades isomorfas: una, el proceso a
simular; la otra: su representacin en un equipo de computacin, que corresponden a
programas que simularan el proceso en cuestin.
Para pasar de una realidad a otra hay una serie de intelectualidades que
llamamos modelos, que pueden o no plasmarse en material escrito, iconogrfico o
impreso. Hemos establecido su nmero y contenido, cada uno de ellos es elaborado
y/o usado por uno o ms usuarios. Para cada uno de los modelos se especifica la
nomenclatura en la tabla I
NOMBRE

CODIGO

HUESPED

FORMALD

DETALLE

ORIENTAN

natural

MN

Usuario/
Analista

Informal

mucho

A la
operacin

del usuario

MU

Analista

Formal

poco

al proceso

del
programador

MP

Analista/
Programador

Muy Formal

mediano

al software

Tabla I - Modelos
Para estos Modelos existen transiciones, secuenciadas en dos interfases:
MN/MU y MU/MP. Si se quisiera establecer el lugar fsico en donde se encuentran
estas interfases, se pueden situar en la interrelacin de distintos huspedes. 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 situacin en la que deben actuar y
tomar decisiones.
(Natural: N . Del Usuario: U . Del Programador: P) Modelo

Narrativa, Infografa
Diagrama General de Actividades
Casos de Uso
Grafo de Transicin de Estados
Objetos. Diagrama de Clases
Diagramas de Colaboracin
Diagramas de Secuencia

N
N/U
N/U
U
U/P
U/P
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 comunicacin 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.

FINESI

SIMULACIN
UML: Unified Modeling Language
El UML ofrece una notacin sintctica y semntica estndar para describir
estructuras y comportamiento de Objetos [QUA00].
Durante los aos noventa diferentes metodologas con sus notaciones fueron
introducidas al mercado. Tres de los mtodos mas populares fueron: OMT
(Rumbaugh), Booch y OOSE (Jacobson). Cada una de ellas aportaba valor en
distintas reas. OMT en anlisis, Booch en diseo y Jacobson en anlisis de
comportamiento. Luego de publicaciones en las cuales participaban en forma conjunta
los mtodos comenzaron a converger pero la notacin segua siendo divergente.
Hasta que lograron consensuar una notacin: UML. Es un lenguaje utilizado para
especificar, visualizar y documentar los artefactos de un sistema orientado a objetos
bajo desarrollo. Aunque los mtodos anteriormente citados fueron la base para la
fundacin de UML tambin participaron otros autores con sus metodologas: 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)
Modelacin Visual
Es una forma de tratar los problemas usando modelos iconogrficos e
interactivos organizados alrededor de las ideas del mundo real. Este tipo de
modelizacin posee reglas sintcticas y semnticas para lograr isomorfismo entre lo
que se construye y lo que se quiere representar.
La abstraccin es una capacidad humana fundamental que permite tratar la
complejidad. Para construir diseos complejos el Analista debe abstraer diferentes
vistas del Sistema, construir modelos utilizando notacin precisa, verificar que el
modelo satisface los requerimientos y gradualmente adicionar detalles para
transformar el modelo en una aplicacin.
Se construyen modelos para entender Sistemas complejos porque no es posible
abarcarlos como una integridad y comunicarlos en forma precisa. Hay lmites en la
capacidad humana para entender complejidades. Construir un modelo permite al
analista focalizarse en como las grandes partes del Sistema interactan sin tener que
profundizar en detalles especficos 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 notacin. Para comunicar el modelo (sintctica y semntica)
ii) Un proceso. Como usar la notacin (interactiva e incrementalmente)
iii) Una herramienta. Sostn de la notacin y el proceso
UML brinda estas 3 dimensiones y acompaa la evolucin del Proyecto en los
estados de desarrollo, integracin y comunicacin.

FINESI

5
Figura 1 -

SIMULACIN

Desarrollo interactivo e incremental: Se ejecutan cierta cantidad de iteraciones

hasta llegar al sistema final. En cada iteracin 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 definicin anterior es revisada en la prxima
iteracin donde se agregan nuevos objetos y comportamientos. Construir el Sistema
de esta forma mitiga los riesgos asociados con el desarrollo de Proyectos complejos

Figura 2

ELABORACIN DE LOS MODELOS

En la bibliografa [FIS92] se definen dos formas bsicas de elaborar modelos: i)
la declarativa y ii) la funcional. En simulacin, la primera forma pone el nfasis en los
Objetos, su anlisis e interrelacin, mientras que la segunda lo hace en los eventos o
actividades.
La mayor parte de los paquetes comerciales para hacer simulacin se basan
en metodologas funcionales. Para facilitar la tarea del usuario se le pide que describa
-habitualmente mediante grficos que tienden a ser icnicos- el proceso a simular. El
modelo resultante consiste en una simple descripcin del proceso visto como una serie
de lugares fsicos en los que ocurren cosas; bsicamente, se realizan operaciones o

FINESI

SIMULACIN
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 algn tem de la cola.
En nuestro caso hemos preferido adoptar un modelo declarativo. Esta
seleccin se basa en las siguientes consideraciones:
Desde el punto de vista del usuario que debe manejar una operacin, su inters
est centrado en la utilizacin 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- quin cuidar que esos
objetos interacten correctamente en las distintas actividades para maximizar la
productividad del sistema. El anlisis por objetos tiene mayor poder analtico 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 operacin. Un anlisis de los
estados en los que pueden hallarse cada objeto lleva a evaluar directamente la
performance de dicho objeto en la operacin.
La estructura que debe tener un modelo conceptual de un sistema dinmico que se
va a simular por algn paradigma de eventos discreto se basa en sealar en una
lnea de tiempo los puntos (instantes) que marcarn el avance "a saltos" de la
simulacin. 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 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 relacin entre
realidad y modelo se torna as transparente. El usuario debe comprender que a
travs de la seleccin de objetos, atributos y estados se constituye en el controlador
del modelo que se va a usar para simular.

FINESI

SIMULACIN
Herramientas de los Modelos
En lo que sigue se describe someramente las herramientas que conforman la
metodologa para elaborar los modelos:
Narrativa, Infografa. Modelo Natural
La narrativa es una descripcin de las actividades que el sistema va a incluir para
la simulacin. Debe ser clara, precisa y consensuada con el Usuario.
Elementos: Documentos e Infografa.
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 duracin 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 desviacin
estndar 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 lmite para la cola.
Se desea simular la operacin para analizar las siguientes alternativas
de trabajo:
i) Cambio en las proporciones relativas de los dos tipos de piezas.
ii) Prioridad en atencin de piezas.
iii) Incorporar mayor cantidad de puestos de trabajo.
Casos de Uso. Modelo Natural/Modelo del Usuario
Este Modelo brinda una aproximacin de las actividades involucradas. Los casos
de uso no poseen secuencia, permiten establecer el lmite de la Simulacin a
realizar, comenzar a identificar objetos relevantes y una interrelacin bsica entre
actividades y Objetos.

FINESI

SIMULACIN
Tapa

PT2

Procesar Tapa en PT2

Procesar cuerpo en PT2

Procesar Tapa en PT1

PT1

Procesar Cuerpo en PT1

Cuerpo

Figura
3 -Usuario
Diagrama General de Actividades (DGA). Modelo Natural/Modelo
del
Se utiliza para limitar el mbito de la simulacin. Es la primera versin icnica que
da una idea del proceso a resolver.
Llegada Pieza

Espera de
Pieza por PT1

Espera de
Pieza por PT2

Proceso de
Pieza en PT1

Proceso de
Pieza en PT2

Salida de Pi eza

Figura 4 -

FINESI

SIMULACIN

Grafos de Transicin 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 sern
consideradas en el modelo.
Se deber incluir en este modelo:
Instancias del ATRIBUTO Estado para cada uno de los Objetos.
Definicin Operacional de Cada uno de los Estados.

Tapa

Cuerpo

llegpi e

llegpi e

qpt1

qpt2

propt1

propt2

qpt2

qpt1

propt2

propt1

sal pie

salpie

Figura 6 -

FINESI

10

SIMULACIN

PT1

QPT1

libre

n+1
ocupado

n-1

Figura 5 -

Cabe destacar que es muy importante la definicin operacional de cada uno de

los estados para introducir precisin en el Modelo
Definiciones Operacionales: son documentos que permiten comunicar
procedimientos para dar precisin y completitud al modelo
Ejemplo: ante la situacin que se muestra en el siguiente grfico se puede cometer un
grave error si no se da una definicin precisa de procedimiento:

Lneas de
Produccin

Productos
Semielaborados

Espera por
recurso

LP1

pa

Qrj

LP2

pb

Qrk

Lneas de
Produccin

rj

LP3

LP4

Figura 7 -

Para comenzar a procesar productos semielaborados pb en la lnea de produccin

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 lnea de produccin
en condiciones.

FINESI

11

SIMULACIN

Objetos. Diagrama de Clases. Modelo del Usuario/ Modelo del Programador

Segn la narrativa, los casos de uso, el D.G.A. y los GTE continuamos definiendo
los Objetos de la simulacin. Comienza el refinamiento de los Objetos

Pieza
DTllegada : funcion
DTproceso : funcion
Obtener tiempo de Proceso()
Obtener Tiempo Llegada()

Tapa

Cuerpo

(f rom Casos de Uso)

(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 anlisis por cada uno de los Objetos
que intervienen en la simulacin. Con la aplicacin de los
Diagramas que siguen, de Colaboracin y Secuencia, se
recupera el sentido de las actividades del proceso a Simular

FINESI

12

SIMULACIN

Diagrama de Colaboracin. 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 sern incluidos en la Simulacin. Los Eventos Condicionales
como la expresin 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 condicin para que se dispare es que el
tiempo asignado a ese evento sea igual al tiempo de la Simulacin
Ejemplo: Para procesar un Lote en un Puesto de Trabajo tendremos que tener
como mnimo 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 finalizacin al proceso segn una funcin predeterminada. Esto lleva a
registrar que en un cierto instante se va a producir la finalizacin del Proceso, con
lo que tenemos la ejecucin del Evento fijo. Es decir que el motor de la simulacin
trabaja de la siguiente manera: ejecuta los eventos Fijos que se Produzcan en
cierto instante de tiempo seteando en reloj interno de la simulacin en este instante
y luego evala todos los Eventos Condicionales para ver si alguno puede ser
ejecutado.
1: Elementos en QPT1( )

: QPT1
4: Iniciar Proceso( )

2: Estado de PT1( )
: Inicio Proceso en
PT1

: PT1

3: Obtener Pieza( )

: Pieza

Figura 9 -

FINESI

13

SIMULACIN

Diagrama de Secuencia. Modelo del Programador

Secuencia de eventos para iniciar, ejecutar y culminar una actividad con todos los
Objetos involucrados.
: PT1

: Inicio Proceso
en PT1

: QPT1

: Pieza

: Fin Proceso
en PT1

Estado de PT1( )

Elementos en QPT1( )

Ini ciar Proceso( )

Obtener Pieza( )

Fin Proceso en PT1( )

Figura 10 -

CONCLUSIONES
Si se acta sagazmente es posible lograr como objetivo final de la elaboracin
de los Modelos la participacin 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 insercin del Usuario Final, se trata de cumplir
una funcin didctica especial ya que no se estar haciendo modelos para un sistema
dado, se estar enseando 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
comunicacin, la elaboracin de documentacin y el diseo de programas. Este tipo
de modelizacin promueve un mejor entendimiento de los requerimientos, diseos
limpios y sistemas ms fciles de mantener.
UML es un lenguaje estndar y Universal que nos permite interactuar con distintos
actores de diferentes mbitos y regiones para la consecucin de un Proyecto de
Simulacin

FINESI

14

SIMULACIN
BIBLIOGRAFIA

ALO96 Alonso Daniel. Morfologa de las herramientas de diseo. Diseo de

Sistemas (Fascculo 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; Teora 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 implementacin de un proyecto de simulacin. ISITAN, Tandil, 1996.
Moruzzi Hugo P. y Tripodi Gustavo D.: Una metodologa para implementar
simulaciones en una PYME orientada a alentar la participacin de Usuarios
Finales. Trabajo presentado en la X EPIO (Escuela de Perfeccionamiento en
Investigacin 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

FINESI

15