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.arING. 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

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

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 ModelosEn 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 ModelosPara 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

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ónAl 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

natural MNUsuario/Analista

Informal mucho A la operación

del usuario MU Analista Formal poco al proceso

del programador MPAnalista/

ProgramadorMuy Formal mediano al software

Tabla I - Modelos

4

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 VisualEs una forma de tratar los problemas usando modelos iconográficos e

interactivos organizados alrededor de las ideas del mundo real. Este tipo de

5

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.

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

Figura 1 -

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

Figura 2

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

Herramientas de los ModelosEn 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

Casos de Uso. Modelo Natural/Modelo del UsuarioEste 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.

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.

9

Diagrama General de Actividades (DGA). Modelo Natural/Modelo del UsuarioSe utiliza para limitar el ámbito de la simulación. Es la primera versión icónica 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 -

10

Grafos de Transición de Estados (GTE). Modelo del UsuarioSe 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.

qpt1

propt1

qpt2

propt2

l legpie

salpie

Tapa

l legpie

qpt2

propt2

qpt1

propt1

Cuerpo

salpie

Figura 6 -

11

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 modeloEjemplo: 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:

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.

libre

ocupado

PT1

n

n + 1

n - 1

QPT1

Figura 5 -

LP1 pa

pb

Líneas de Producción

Productos Semielaborados

LP2

LP3

LP4

Qrj

Qrk

Espera por recurso

Líneas de Producción

rj

Figura 7 -

12

Objetos. Diagrama de Clases. Modelo del Usuario/ Modelo del ProgramadorSegú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

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 análisis por cada uno de los Objetos 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

13

Diagrama de Colaboración. Modelo del Usuario/ Modelo del ProgramadorCuando 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.

: Inicio Proceso en PT1

: QPT1

: PT1

: Pieza

4: Iniciar Proceso( )

1: Elementos en QPT1( )

2: Estado de PT1( )

3: Obtener Pieza( )

Figura 9 -

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 ProgramadorSecuencia de eventos para iniciar, ejecutar y culminar una actividad con

todos los Objetos involucrados.

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

Figura 10 -

15

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