CONSTRUCCION DE MODELOS DE SIMULACION ORIENTADOS A

ALENTAR LA PARTICIPACION DE USUARIOS FINALES UTILIZANDO

UML
rea temtica: Avances Tericos
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
1

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.
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:
Narrativa e infografa
documental
Diagrama general de actividades
documental
Casos de Uso
documental/conceptual
Grafo de transicin de estados
documental/conceptual
Objetos. Diagramas de Clases
conceptual
Diagramas de Colaboracin.
conceptual
Diagramas de Secuencia
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 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.
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.

Figura 1 -

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
6

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 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 materialesque 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
7

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.

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.

Tapa

PT2

Procesar Tapa en PT2

Procesar cuerpo en PT2

Procesar Tapa en PT1

PT1

Procesar Cuerpo en PT1

Cuerpo

Figura 3 -

Diagrama General de Actividades (DGA). Modelo Natural/Modelo

del Usuario
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 Pieza

Figura 4 -

10

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

llegpie

llegpi e

qpt1

qpt2

propt1

propt2

qpt2

qpt1

propt2

propt1

salpie

sal pie

Figura 6 -

11

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.

12

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
DTll egada : funcion
DTproceso : funcion
Obtener tiempo de Proceso()
Obtener T iempo 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

13

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 -

14

Diagrama de Secuencia. Modelo del Programador

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

: Inici o Proceso
en PT1

: QPT1

: Pieza

: Fin Proceso
en PT1

Estado de PT1( )

Elementos en QPT1( )

Inici ar 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
BIBLIOGRAFIA
15

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, SpringVerlag, 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. PrePress Co., Inc. EEUU, 2000. ISBN 0201699613

16