Universidad de cartagena

Teoría general de sistemas

Diseño e implementación de Laboratorio virtual para
el estudio de dinámicas de sistemas

Cipa Los ilusionistas

Bregolen Yeison Ávila Rivera
Juan Carlos Machuca
Leandro Marrugo Tijera
Jamer Marino
Ingeniería de software
II semestre

1
 Dedicatoria
A Dios todopoderoso

y la virgen Regalarme la sabiduría necesaria

Para culminar con éxito esta etapa de mí mida,

A mis padres por su amor y esfuerzo,

A mis familiares y amigos por su apoyo incondicional.

A mis tutores que con su ayuda han contribuido

incondicionalmente en esta etapa de mi vida.

2
Agradecimientos
Primero y antes que nada, dar gracias a Dios, por estar en cada
paso que damos, por fortalecer nuestros corazones e iluminar
nuestras mentes y por haber puesto en nuestro camino a aquellas
personas que han sido nuestro soporte y compañía durante todo el
periodo de estudio. A nuestras familias, que desde el primer
momento nos brindaron y nos brindan todo el apoyo, colaboración
y cariño sin ningún interés, son las personas por las cuales hoy por
hoy podemos afirmar que, jamás nos hemos sentido solos, porque
ellos han estado a nuestro lado cada día durante este proceso.
Gracias por haber compartido el mayor tiempo a nuestro lado,
porque en su compañía las cosas malas se convierten en buenas, la
tristeza se transforma en alegría y la soledad no existe.
A los profesores del programa de Ingeniería de Software de la
universidad de Cartagena quienes en el transcurso de la carrera nos
aportaron sus conocimientos y dieron las herramientas para el
devenir de nuestra profesión.

3
Abstract
The main objective of this research is the design and
implementation of a virtual laboratory at the University of
Cartagena for the study of general systems theory, which can show
the different models of diagram systems such as, prose model and
causal diagram.
In more technical and less poetic words, what these
verses tell us is that the world we live in is itself a dynamic system.
The difficulty in understanding it lies in our limited understanding of
the laws that govern it.
 
Dynamic systems are a "young" area of mathematics, although they
date back to Newton with his studies of celestial mechanics, and to
H. Poincaré, who initiated the qualitative study of differential
equations. However, it was only about 30 years ago that dynamic
systems established themselves as an area proper, thanks to the
work of prominent mathematicians such as S. Smale, Sinai,
Lyapunov, A. Douady, M. Herman, D. Sullivan, VI Arnold and many
more.

4
Table de contenido.
Prefacio ……………………………………………………………………………………. 6
Introducción ……………………………………………………………………………… 8
Educación virtual………………………………………………………………………… 10
Sistemas propuestos…………………………………………………………………… 11
Modelos de sistemas…………………………………………………………………. 12
Requisitos funcionales ………………………………………………………………. 13
Requisitos No funcionales …………………………………………………………..
14
Modelado por caso de uso ………………………………………………………….
15
Diagrama de clase ……………………………………………………………………….18
Modelado de objetos ………………………………………………………………….19
Diagrama de secuencia por caso de uso ………………………………………20
¿Qué es un problema?................................................................... 21
Tabla 1 ………………………………………………………………………………………. 22
Diagrama causal………………………………………………………………………….
23
Diagrama causal de población ejemplo………………………………………. 25
Referentes …………………………………………………………………………………. 26
Referentes citados……………………………………………………………………… 27

5
Prefacio
En un sentido amplio, la Teoría General de Sistemas (TGS) se
presenta como una forma sistemática y científica de aproximación y
representación de la realidad y, al mismo tiempo, como una
orientación hacia una práctica estimulante para formas de trabajo
transdisciplinarias. En tanto paradigma científico, la TGS se
caracteriza por su perspectiva holística e integradora, en donde lo
importante son las relaciones y los conjuntos que a partir de ellas
emergen.
En tanto práctica, la TGS ofrece un ambiente adecuado para la
interrelación y comunicación fecunda entre especialistas y
especialidades. Bajo las consideraciones anteriores, la TGS es un
ejemplo de perspectiva científica (Arnold & Rodríguez, 1990a). En
sus distinciones conceptuales no hay explicaciones o relaciones con
contenidos preestablecidos, pero sí con arreglo a ellas podemos
dirigir nuestra observación, haciéndola operar en contextos
reconocibles. Los objetivos originales de la Teoría General de
Sistemas son los siguientes:
a. Impulsar el desarrollo de una terminología general que permita
describir las características, funciones y comportamientos
sistémicos.
b. Desarrollar un conjunto de leyes aplicables a todos estos
comportamientos y, por último,
c. Promover una formalización (matemática) de estas leyes. La
primera formulación en tal sentido es atribuible al biólogo Ludwig
von Bertalanffy (1901-1972), quien acuñó la denominación "Teoría
General de Sistemas". Para él, la TGS debería constituirse en un
6
mecanismo de integración entre las ciencias naturales y sociales y
ser al mismo tiempo un instrumento básico para la formación y
preparación de científicos. Sobre estas bases se constituyó en 1954
la Society for General Systems Research, cuyos objetivos fueron los
siguientes: a. Investigar el isomorfismo de conceptos, leyes y
modelos en varios campos y facilitar las transferencias entre
aquellos. b. Promoción y desarrollo de modelos teóricos en campos
que carecen de ellos. c. Reducir la duplicación de los esfuerzos
teóricos d. Promover la unidad de la ciencia a través de principios
conceptuales y metodológicos unificadores.

7
Introducción
La influencia de los cambios tecnológicos se puede palpar en todos
los aspectos que conciernen a la sociedad, entre ellos la educación,
ya que a medida que surgen nuevos desarrollos científicos éstos
tienen gran acogida en las herramientas didácticas pues permiten
enriquecer el proceso educativo. En este artículo se muestra la
propuesta metodológica para el diseño de un laboratorio virtual
para el estudio de teoría general de sistemas que impactarán en la
estrategia de enseñanza, ayudando a desarrollar habilidades y
actitudes en los estudiantes, reforzando el proceso de
autoformación, manejo de tiempos, autoevaluación, entre otros.
Este instrumento se basa en las bondades de la educación virtual,
pues se presentan laboratorios a los cuales se acceden por medio
de dispositivos de interacción que adicionalmente permiten
interactuar con el laboratorio y sus elementos. La propuesta de
este desarrollo se realiza al interior del grupo de investigación de la
Universidad de Cartagena Colombia.
Debido al desarrollo de nuevas tecnologías, nuevos softwares de
programación, nuevos componentes electrónicos y nuevos servicios
de telecomunicaciones, ahora es posible desarrollar herramientas
didácticas que soporten el proceso de enseñanza-aprendizaje en el
entorno educativo, pues se requiere material educativo que
capture la atención de los estudiantes y los estimule al aprendizaje,
a través de escenarios interactivos e innovativos.
Uno de esos escenarios son los laboratorios virtuales, cuyo objetivo
principal es introducir a los estudiantes en la experimentación,
8
resolución de problemas, deducción de resultados e interpretación
científica a través de sistemas de aulas virtuales y software
especializados en la interacción de teorías general de sistemas con
componentes que conforman un laboratorio virtual visualizado en
la pantalla de un computador y un dispositivo de captura que le
permita al estudiante interactuar con el laboratorio virtual.

9
Educación Virtual
La educación virtual es, sin duda, uno de los espacios donde se
presentan los más grandes cambios haciendo uso de los desarrollos
tecnológicos. Un modelo de educación virtual toma ventaja de un
modelo estándar, pues la implementación de tecnologías de
comunicación generan servicios de valor agregado para soportar los
múltiples procesos y actividades presentes en los ambientes de la
educación, especialmente proveyendo servicios especializados de
soporte en, primero, asuntos administrativos, tales como
inscripción de asignaturas, pago de matrícula, entre otros, es decir
utilizando los denominados Programas Aplicados a la Educación;
segundo, en procesos académicos, como cursos virtuales,
documentos de referencia, laboratorios interactivos de simulación,
etc, con programas diseñados con fines directamente educativos y
conocidos como “software educativo”.

10
SISTEMA PROPUESTO
La producción de la clase de herramientas didácticas descritas
anteriormente, requiere del diseño y desarrollo de tres
componentes básicos: un dispositivo de interacción, un dispositivo
de transmisión de información y un software de aplicación [9,12]. ƒ
El dispositivo de interacción permite capturar los movimientos del
usuario, puede ser un guante, un traje u otro dispositivo; para
cumplir con su función, se dispone de una serie de sensores que
detectan los movimientos, estas señales se filtran y acondicionan
para su posterior transmisión. ƒ El dispositivo de transmisión de
información, recibe las señales del dispositivo de interacción, las
organiza en forma de tramas y las envía al computador. ƒ El
software de aplicación es un mundo virtual en 3D donde se tienen
los elementos a ser manipulados por el dispositivo de interacción,
además en esta etapa se recuperan los datos transmitidos, se
descifran y se adaptan para ser interpretados por el mundo virtual.
Además, la herramienta debe contar con un componente didáctico
basado en la resolución de problemas, pues debe facilitar al
estudiante su proceso de enseñanza-aprendizaje.

11
Modelado de sistemas dinámicos
La asignatura Modelado de Sistemas Dinámicos aborda la
construcción de modelos matemáticos para simulación por
ordenador útiles en el ámbito del control de procesos. Los modelos
son formulados aplicando los principios básicos de la física. Se
discute el modelado de sistemas eléctricos, mecánicos, térmicos,
hidráulicos, químicos y termodinámicos, resaltando las analogías
existentes entre las leyes físicas en los diferentes dominios. Los
modelos están descritos mediante ecuaciones diferenciales,
algebraicas y eventos discretos, es decir, se trata de modelos DAE
híbridos. El diseño de los modelos se realiza aplicando la
metodología del modelado orientado a objetos. Esta metodología
facilita la creación de librerías de modelos que resulten fácilmente
reutilizables en diferentes contextos. Asimismo, se describen
aquellos aspectos de su simulación que deben ser tenidos en
cuenta al diseñar los modelos, incluyendo las manipulaciones
simbólicas previas a la resolución numérica (partición, reducción de
índice, tearing de lazos algebraicos, etc.), así como el algoritmo
para la simulación de modelos híbridos. Finalmente, se explican
procedimientos para la estimación y validación de los modelos
empleando datos obtenidos del sistema real.

12
Requisitos funcionales

Los requerimientos funcionales son declaraciones de los servicios

que proveerá el sistema, de la manera en que éste reaccionará a
entradas particulares. En algunos casos, los requerimientos
funcionales de los sistemas también declaran explícitamente lo que
el sistema no debe hacer.

Muchos de los problemas de la ingeniería de software provienen de

la imprecisión en la especificación de requerimientos. Para un
desarrollador de sistemas es natural dar interpretaciones de un
requerimiento ambiguo con el fin de simplificar su implementación.
Sin embargo, a menudo no es lo que el cliente desea. Se tienen que
estipular nuevos requerimientos y se deben hacer cambios al
sistema, retrasando la entrega de éste e incrementando el costo.

En principio, la especificación de requerimientos funcionales de un

sistema debe estar completa y ser consistente. La compleción
significa que todos los servicios solicitados por el usuario están
definidos. La consistencia significa que los requerimientos no tienen
definiciones contradictorias.

En la práctica, para sistemas grandes y complejos, es imposible

cumplir los requerimientos de consistencia y compleción. La razón
de esto se debe parcialmente a la complejidad inherente del
sistema y parcialmente a que los diferentes puntos de vista tienen
necesidades inconsistentes. Estas inconsistencias son obvias
cuando los requerimientos se especifican por primera vez. Los
problemas emergen después de un análisis profundo. Una vez que
éstos se hayan descubierto en las diferentes revisiones o en las
fases posteriores del ciclo de vida, se deben corregir en el
documento de requerimientos.

13
Requisitos no funcionales

Son aquellos requerimientos que no se refieren directamente a las

funciones específicas que entrega el sistema, sino a las propiedades
emergentes de éste como la fiabilidad, la respuesta en el tiempo y
la capacidad de almacenamiento. De forma alternativa, definen las
restricciones del sistema como la capacidad de los dispositivos de
entrada/salida y la representación de datos que se utiliza en la
interface del sistema.

Los requerimientos no funcionales surgen de la necesidad del

usuario, debido a las restricciones en el presupuesto, a las políticas
de la organización, a la necesidad de interoperabilidad con otros
sistemas de software o hardware o a factores externos como los
reglamentos de seguridad, las políticas de privacidad, entre otros.

Estos diferentes tipos de requerimientos se clasifican de acuerdo

con sus implicaciones.

• Requerimientos del producto. Especifican el comportamiento del

producto; como los requerimientos de desempeño en la rapidez de
ejecución del sistema y cuánta memoria se requiere; los de
fiabilidad que fijan la tasa de fallas para que el sistema sea
aceptable; los de portabilidad y los de usabilidad.

• Requerimientos organizacionales. Se derivan de las políticas y

procedimientos existentes en la organización del cliente y en la del
desarrollador: estándares en los procesos que deben utilizarse;
requerimientos de implementación como los lenguajes de
programación o el método de diseño a utilizar, y los requerimientos
de entrega que especifican cuándo se entregará el producto y su
documentación.

14
• Requerimientos externos. Se derivan de los factores externos al
sistema y de su proceso de desarrollo. Incluyen los requerimientos
de interoperabilidad que definen la manera en que el sistema
interactúa con los otros sistemas de la organización; los
requerimientos legales que deben seguirse para asegurar que el
sistema opere dentro de la ley, y los requerimientos éticos. Estos
últimos son impuestos al sistema para asegurar que será aceptado
por el usuario.

Modelos de caso de uso

El modelo de casos de uso permite que los desarrolladores del

software y los clientes lleguen a un acuerdo sobre los requisitos, es
decir, sobre las condiciones y posibilidades que debe cumplir el
sistema. El modelo de casos de uso sirve como acuerdo entre
clientes y desarrolladores, y proporciona la entrada fundamental
para el análisis, el diseño y las pruebas.

“Un modelo de casos de uso es un modelo del sistema que

contiene actores, casos de uso y sus relaciones.”

“El modelo de casos de uso describe lo que hace el sistema para

cada tipo de usuario.”

1. Actores del sistema.

Un actor no es más que un conjunto de roles que los usuarios de

Casos de Uso desempeñan cuando interaccionan con estos Casos
de Uso. Los actores representan a terceros fuera del sistema que
colaboran con el mismo. Una vez identificado los actores del
sistema, queda identificado el entorno externo del sistema.

15
Actor Justificación

Usuario General Persona que puede registrarse en el sistema,

puede ser: profesor o administrador.

Profesor Es la persona interesada en conocer el comportamiento de

un Estudiante en un Software Educativo.

Administrador Es quien crea las cuentas de acceso al sistema, le

asigna a cada usuario sus permisos en dependencia al rol a
desarrollar y cambia la contraseña.

Tabla 1 Actores del Sistema

2. Casos de Uso del Sistema.

La forma en que los actores usan el sistema se representa con un

caso de uso. Los casos de uso son “fragmentos” de funcionalidad
que el sistema ofrece para aportar un resultado de valor para sus
actores. De manera más precisa, un caso de uso especifica una
secuencia de acciones que el sistema puede llevar a cabo
interactuando con sus actores, incluyendo alternativas dentro de la
secuencia.

Por el número de casos de uso se introducen paquetes al modelo

de casos de uso del sistema con el objetivo de disminuir la
complejidad y así aumentar en comprensión.

3. Diagramas de casos de uso del sistema.

El Paquete Administrativo contiene los casos de usos referentes a la

administración del sistema:

1. Autenticar usuario.

2. Buscar usuario.
16
3. Editar permisos usuarios.

4. Habilitar/Inhabilitar usuario.

5. Asignar SE a asignatura.

6. Editar datos de SE.

7. Eliminar SE del sistema.

El Paquete Reportes contiene los casos de usos referentes a la

información que podrá obtener el profesor a través del sistema,
teniendo en cuenta el comportamiento de los estudiantes en cada
SE:

1. Consultar ayuda.

2. Visualizar listado de estudiantes que visitaron un SE por grupo.

3. Visualizar el contenido visitado por un estudiante en el SE.

4. Visualizar fecha de entrada y salida de un estudiante en un

contenido de un SE.

5. Visualizar cantidad de visitas al SE.

6. Visualizar cantidad de visitas del estudiante al SE.

7. Visualizar el tiempo que estuvo un estudiante en un SE en un

rango de fecha.

8. Visualizar evaluación de un estudiante por contenido de un SE.

9. Visualizar Respuesta de un estudiante por preguntas de un

contenido de un SE.

10. Visualizar SSEE de una asignatura.

17
Diagrama de clases

El objetivo principal de este modelo es la representación de los

aspectos estáticos del sistema, utilizando diversos mecanismos de
abstracción (clasificación, generalización, agregación).
Descripción
El diagrama de clases recoge las clases de objetos y sus
asociaciones. En este diagrama se representa la estructura y el
comportamiento de cada uno de los objetos del sistema y sus
relaciones con los demás objetos, pero no muestra información
temporal.
Con el fin de facilitar la comprensión del diagrama, se pueden
incluir paquetes como elementos del mismo, donde cada uno de
ellos agrupa un conjunto de clases.

18
Modelado de objetos
La técnica de Modelado de Objetos (Object Modeling Technique
OMT) se basa en un conjunto de conceptos que definen que es
Orientación a Objetos y una notación gráfica independiente. La
tecnología orientada a objetos propone una forma de pensar de
modo abstracto acerca de problemas a resolver empleando
conceptos del mundo real y no conceptos de computadoras. La
notación gráfica propuesta ayuda al desarrollo de software
visualizando el problema sin recurrir en forma prematura a la
implementación.
La práctica ha demostrado que con el objeto de mantener la
flexibilidad una buena técnica de diseño retrasa los detalles de la
implementación hasta las ultimas etapas del mismo. El Modelado y
Diseño Orientado a Objetos se funda en pensar acerca de
problemas a resolver empleando modelos que se han organizado
tomando como base conceptos del mundo real. La unidad básica es
el objeto que combina las estructuras de datos con los
comportamientos en una entidad única.

19
Diagrama de secuencia por caso de uso

El diagrama de casos de uso muestra cada una de funcionalidades

del sistema modelado en una visión de caja negra de las mismas.
Representa al sistema como un rectángulo que contiene tantas
elipses como casos de uso diferentes junto con el actor o actores
con los que interactuará.

1 1
Universidad Lab. Virtual

1… 1…

1 1

1… 1
Programa Estudiantes

20
¿Qué es un problema?

Sin entrar en profundidades conceptuales, se realizará una

aproximación general a este complejo tema de los problemas. ¿Qué
se hace en Ingeniería? La disciplina de Ingeniería
fundamentalmente se dedica a resolver problemas para mejorar la
calidad de vida de las personas, mejorar el mundo, favorecer la
vida. Obviamente que ésta no es la definición más exacta de la
Ingeniería, pero puede aclarar el planteamiento ético que está de
base en el concepto. Ciertamente, puede hacerse Ingeniería cuando
se diseña un arma de destrucción masiva; pero si bien a tal clase de
cosas se puede dedicar la Ingeniería parece prudente resaltar que
la investigación en esta disciplina no está exenta de aspectos éticos.
La decisión de investigar o, bien, de resolver determinado problema
transita también por una reflexión moral: en cualquier etapa del
proceso, el investigador puede estar confrontado con la decisión de
usar su conocimiento y sus habilidades para mejorar el mundo o
simplemente para contribuir a su destrucción.

Considerando las aportaciones más clásicas de Newell & Simon

(1972) y Hayes (1978), en términos generales, puede entenderse un
problema como una situación ante la cual se exige una respuesta,
una acción, un procedimiento, para reducir una diferencia; tal
diferencia puede verse como un asunto de “lugares”: la situación
coloca al “solucionador” en un lado y debe encontrar la manera de
llegar a otro lado deseado. “Estoy aquí; mi problema es cómo
puedo llegar hasta allá”.

21
22
Diagrama Causal

El conjunto de los elementos que tienen relación con nuestro

problema y permiten en principio explicar el comportamiento
observado, junto con las relaciones entre ellos, en muchos casos de
retroalimentación, forman el Sistema. El Diagrama Causal es un
diagrama que recoge los elementos clave del Sistema y las
relaciones entre ellos.
Como hemos dicho es importante empezar a hacer versiones que
poco a poco nos vayan aproximando a la complejidad del modelo.
La gama mínima de elementos y relaciones que permita reproducir
la Referencia Histórica, será la que forme la estructura básica del
sistema.
Una vez conocidas globalmente las variables del sistema y las
hipotéticas relaciones causales existentes entre ellas, se pasa a la
representación gráfica de las mismas. En este diagrama, las
diferentes relaciones están representadas por flechas entre las
variables afectadas por ellas.
Esas flechas van acompañadas de un signo (+ o -) que indica el tipo
de influencia ejercida por una variable sobre la otra. Un signo "+"
quiere decir que un cambio en la variable origen de la flecha
producirá un cambio del mismo sentido en la variable destino. El
signo "-" simboliza que el efecto producido será en sentido
contrario.
Así cuando un incremento de A, produce un incremento de B, o
bien una disminución de A provoca una disminución de B,
tendremos una relación positiva.
Y cuando un incremento de A, produce una disminución de B, o
bien una disminución de A provoca un aumento de B, tendremos
una relación negativa.
23
Una cadena cerrada de relaciones causales recibe el nombre de
bucle, retroalimentación o feedback. Cuando abrimos el grifo para
llenar un vaso de agua aumentamos la cantidad de agua en el vaso,
pero también la cantidad de agua que va habiendo en el vaso
modifica la velocidad en la que nosotros llenamos el vaso. Lo
llenamos más despacio cuando está casi lleno; y por to tanto existe
un bucle.
El sistema formado por nosotros, el grifo y el vaso de agua es un
bucle negativo porque está dirigido a conseguir un objetivo, llenar
el vaso sin que se exceda. Los bucles negativos actúan como
elementos estabilizadores de los sistemas al dirigirlos hacia un
objetivo determinado, igual que el termostato de la calefacción la
dirige hacia la temperatura seleccionada.
Los bucles se definen como "positivos" cuando el número de
relaciones "negativas" es par, y "negativos" si es impar (igual que al
multiplicar: -a x b = -c).
Los bucles negativos llevan al modelo hacia una situación estable y
los positivos lo hacen inestable, con independencia de la situación
de partida.
En la realidad los sistemas contienen ambos tipos de bucles y el
comportamiento final dependerá de cual es el dominante en un
momento determinado.
Cuando un país adquiere más armamento hace que sus vecinos se
sientan amenazados y les induce a adquirir ellos también más
armamento. Este es un bucle positivo, también llamado un circulo
vicioso que crece sobre sí mismo más y más. Los bucles positivos
causan crecimiento, evolución y también el colapso de los sistemas.
Naturalmente los sistemas socioeconómicos y ecológicos están
formados por cientos de bucles positivos y negativos
interconectados, y su comportamiento final no es evidente.

24
Ejemplo de población en diagrama causal

25
Referentes
[1] L. Rosado y J.R. Herreros, Laboratorios virtuales y remotos en la
enseñanza de la Física y materias afines, Didáctica de la Física y sus
nuevas Tendencias, Madrid, UNED, pp. 415-603, 2002.
• [2] L. Rosado y J.R. Herreros, Internet y Multimedia en Didáctica e
Investigación de la Física. Tratado teórico práctico para profesores y
doctorandos, Madrid, UNED, 2004.
• [3] L. Gil, E. Blanco y J.M. Aulí, Software educativo orientado a la
experimentación, I Congreso Internacional de Docencia
Universitaria e Innovación, Barcelona, Spain, Universidad de
Barcelona, 2000, pp. 118.
• [4] O. Boix, S. Fillet y J. Bergas, Nuevas posibilidades en
laboratorios remotos de enseñanzas técnicas. Congreso Virtual
CIVE 2002, Internet: http://www.cibereduca.com/cive/ponencias.
• [5] Franklin, Gene F.; Powell, J. David; Emani-Naeini, Abbas,
Control de sistemas dinámicos con retroalimentación, Wilmington.
1991. 618 p. LABORATORIO VIRTUAL PARA LA ENSEÑANZA DE
MODELADO Y ANÁLISIS SISTEMAS DINÁMICOS LTI 8 WEEFTM 2013
Cartagena
• [6] Carlos a. Smith, control automático de procesos: teoría y
práctica, limusa-noriega, México, 1997. 717 p.
• [7] Martín, C. Dormido, S. Pastor, R. Sánchez, J. Esquembre, F.
“Sistema de Levitación Magnética: Un Laboratorio Virtual en “Easy
Java Simulation”, XXIV Jornadas de Automática, León, 2003. • [8]
Francisco Esquembre. (2009, Abril). EJS Wiki. Consultado 29 de Abril
de 2013 en http://www.um.es/fem/EjsWiki/Es/Deployment

26
Referentes citados
http://www.tise.cl/2009/tise_2009/pdf/20.pdf

https://comunidadcolombianads.com/wp-content/uploads/2017/07/ECDS2009_Memorias.pdf

http://www.dinamica-de-sistemas.com/libros/diagrama_causal.htm

https://acofipapers.org/index.php/acofipapers/2013/paper/viewFile/55/13

27