-
SIMULACIN
FINESI 1
CONSTRUCCION DE MODELOS DE SIMULACION ORIENTADOS A ALENTAR LA
PARTICIPACION DE USUARIOS FINALES UTILIZANDO
UML
ING. GUSTAVO TRIPODI - [email protected] ING. GUSTAVO
ILLESCAS - [email protected]
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.
-
SIMULACIN
FINESI 2
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:
-
SIMULACIN
FINESI 3
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
-
SIMULACIN
FINESI 4
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
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 N Diagrama General de Actividades N/U Casos
de Uso N/U Grafo de Transicin de Estados U Objetos. Diagrama de
Clases U/P Diagramas de Colaboracin 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 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.
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
-
SIMULACIN
FINESI 5
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 -
-
SIMULACIN
FINESI 6
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
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
Figura 2
-
SIMULACIN
FINESI 7
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.
-
SIMULACIN
FINESI 8
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
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.
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.
-
SIMULACIN
FINESI 9
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.
PT2 Procesar Tapa en PT2
Procesar cuerpo en PT2
Tapa
Cuerpo
Procesar Tapa en PT1
Procesar Cuerpo en PT1
PT1
Figura 3 -
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 -
-
SIMULACIN
FINESI 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.
qpt1
propt1
qpt2
propt2
llegpie
salpie
Tapa
l legpie
qpt2
propt2
qpt1
propt1
Cuerpo
salpie
Figura 6 -
-
SIMULACIN
FINESI 11
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: 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.
libre
ocupado
PT1
n
n + 1
n - 1
QPT1
Figura 5 -
LP1 pa
pb
Lneas de Produccin
Productos Semielaborados
LP2
LP3
LP4
Qrj
Qrk
Espera por recurso
Lneas de Produccin
rj
Figura 7 -
-
SIMULACIN
FINESI 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
Tapa(f rom Casos de Uso) Cuerpo
(f rom Casos de Uso)
PiezaDTllegada : funcionDTproceso : funcion
Obtener tiempo de Proceso()Obtener Tiempo Llegada()
PT1(f rom Casos de Uso)
PT2(f rom Casos de Uso)
PuestoTrabajoCola
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
-
SIMULACIN
FINESI 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.
: Inicio Proceso en PT1
: QPT1
: PT1
: Pieza
4: Iniciar Proceso( )
1: Elementos en QPT1( )
2: Estado de PT1( )
3: Obtener Pieza( )
Figura 9 -
-
SIMULACIN
FINESI 14
: Inicio Proceso en PT1
: PT1 : QPT1 : Pieza : Fin Proceso en PT1
Estado de PT1( )
Elementos en QPT1( )
Obtener Pieza( )
Fin Proceso en PT1( )
Iniciar Proceso( )
Diagrama de Secuencia. Modelo del Programador
Secuencia de eventos para iniciar, ejecutar y culminar una
actividad con todos los Objetos involucrados.
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
Figura 10 -
-
SIMULACIN
FINESI 15
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
