CONOCIMIENTO TECNOLÓGICO:

CONOCIMIENTO TECNOLÓGICO:
EL CASO DE LA INGENIERÍA DEL SOFTWARE1
Rodolfo Fernández González
Dpto. Lógica UCM
En los últimos años, el tema de la realidad virtual ha atraído una considerable atención,
tanto por parte del público interesado en las novedades tecnológicas, como de algunos
intelectuales preocupados por el impacto social y cultural que esta tecnología puede tener2.
Pero en todas las discusiones al respecto se ha pasado por alto el hecho de que la realidad
virtual no es sino la conversión en espectáculo de una tarea que siempre ha estado
asociada al núcleo de la tecnología de la información, la ingeniería de software. Dicha tarea
es requerida para el desarrollo de cualquier sistema informático, hasta tal punto que cabe
caracterizar el tipo de conocimiento requerido por la ingeniería del software no como un
saber-cómo (know-how), sino como un saber-que (know-that). Según la opinión más
común3, el saber tecnológico4 es un saber-cómo. Me interesa explorar aquí la consideración
de las tecnologías de la información, y más específicamente de la ingeniería del software,
como una actividad en cuyo núcleo se requiere la explícita construcción ad-hoc de un saberque. Esta consideración ha sido adelantada por Naur5, en el sentido de que la ingeniería de
software parece exigir una modelización -un saber-que- del proceso de computación,
dependiente del objetivo que se pretende alcanzar. En esta nota trato de llevar más allá esta
perspectiva, destacando el hecho de que esta modelización implica también la construcción,
en el uso de la tecnología, de un saber-que relativo a las entidades del dominio del
problema, que, en los últimos años, se tiende a hacer lo más independiente posible del
propósito para el que se desarrolla una aplicación determinada.
1
Esta trabajo se preparó para el Simposio de Filosofía de la Técnica: Mundos Virtuales realizado en
Salamanca, el 18 de Febrero de 1998
2
3
4
Ver, por ejemplo, [Wooley 1994].
Ver, por ejemplo, Jarvie, l. C. (1983).
En lo que sigue, supondremos que una "destreza" (skill) es una estrategia de solución de problemas
que los individuos aprenden mediante una actividad informal de prueba y error para la ejecución de
tareas cotidianas. Una "técnica" de resolución de problemas en un dominio dado es una destreza que
el individuo adquiere, mediante una actividad formal de enseñanza/aprendizaje, bajo la forma de un
con- junto de reglas obtenidas empíricamente (expertise). En este sentido, una técnica no es sino una
extensión de los sentidos, y de las destrezas, naturales- Shallis, M. (1991), p. 26.-, que en ocasiones
se materializa en "artefactos"- Skolimowski, H. (1966), p. 44.-. Una "tecnología" es una técnica que
incluye en el conjunto de reglas que la codifican, y en el diseño y desarrollo de los artefactos que la
materializan, partes relevantes del conocimiento científico disponible. Sobre la naturaleza de la
tecnología y su relación con la teoría científica, ver Feibleman, J. K. (1961), Bunge, M. (1966),
Mosterín, J. (1978), Quintanilla, M. A. (1979).
5
Ver Naur, P. (1985).
1
1. Ingeniería de Software como saber-cómo
Bajo la etiqueta de "tecnologías de la información" nos referimos normalmente a tecnologías
de tres tipos distintos:
a) Las tecnologías del hardware, que nos pernliten diseñar y construir dispositivos
electrónicos -computadoras digitales u "ordenadores"- para representar
electrónicamente, almacenar y manipular información.
b) Las tecnologías de la comunicación, que nos permiten diseñar y construir
sistemas de transmisión de la información entre puntos arbitrariamente separados en
el espacio.
c) La ingeniería del software, que nos permite diseñar y desarrollar algoritmos,
inteligibles para los ordenadores, con el objetivo de facilitar al máximo la
manipulación de la información, intentando, a la vez, que dicha manipulación se
realice de la forma más eficiente posible.
La ingeniería de software, en tanto que saber-cómo, se codifica bajo la forma de un "ciclo de
vida". Este no es más que un registro que indica a los analistas y programadores cuáles son
las tareas que han de llevar a cabo, y en qué orden. Habitualmente, tenemos en un ciclo de
vida las siguientes tareas:
•
•
•
•
•
•
•
Análisis de requerimientos -funcionales y no funcionales-.
Análisis funcional, que constituye una definición o especificación detallada de las
estructuras en las que se organizarán los datos que hay que manipular, así como los
algoritmos que han de ejecutar las manipulaciones de datos requeridas, teniendo en
cuenta, asimismo, algunas de las especificaciones no funcionales. Se definen las
arquitecturas funcionales y de flujo de datos, y se construyen algunos prototipos o
maquetas tanto de los procesos a ejecutar como de los interfaces de usuario.
Diseño técnico, en el que el análisis funcional se ajusta a las plataformas hardware y
software elegidas. Asimismo, en esta fase se elabora la arquitectura software del
sistema, identificando módulos y programas, y se ponen a punto baterías de
pruebas.
Codificación o construcción de programas en el lenguaje de programación elegido - o
requerido- para la aplicación.
Pruebas unitarias, en las que se revisa el funcionamiento de cada programa o
módulo por separado.
Integración y pruebas integradas.
Validación del sistema por parte de los expertos en el dominio del problema y de los
usuarios de la aplicación.
Cada una de estas fases incluye, asimismo, tareas de generación de documentos, y puede
dar lugar a revisiones de fases anteriores, y a repeticiones parciales del ciclo. Además,
normalmente se llevan a cabo otras tareas, también incluidas en el ciclo de vida, pero cuyo
papel en el desarrollo es menos directo:
2
•
•
•
•
•
Planificación del proyecto, incluyendo una especificación de la estrategia de gestión
y control del proyecto y, especialmente, de los recursos humanos y de tiempo
disponibles.
Constitución y entrenamiento del equipo de proyecto.
Determinación de plataformas hardware y herramientas software
Implantación del sistema desarrollado en el entorno de trabajo piloto o final. Esta
fase suele incluir actividades de entrenamiento de los usuarios.
Mantenimiento de la aplicación a lo largo de su vida útil, lo que suele incluir
correcciones, modificaciones, ampliaciones, etc.
Cada una de las actividades y tareas del ciclo de vida está regulada por conjuntos de reglas
heurísticas que tratan de garantizar que el resultado final de cada proyecto se ajuste a los
requerimientos especificados inicialmente. Estas reglas se codifican en distintas
metodologías de análisis, programación y pruebas6.
2. La ingeniería de software como saber-que: Modelización del proceso de
computación
Lo que hace de estas actividades una tecnología, y no simplemente una técnica, en el
sentido especificado anteriormente, es el uso reiterado que en ellas se hace de notacio- nes
simbólicas o lenguajes formales, y de mecanismos computacionales, deductivos y
algoritmicos asociados a dichas notaciones o lenguajes. El complejo formado por estos
lenguajes y mecanismos es objeto de estudio por parte de distintas disciplinas matemáticas
(teoría de autómatas y lenguajes formales, algoritmética, lógica), con el propósito de
establecer las propiedades matemáticas de las correspondientes teorías formales. Dichos
resultados matemáticos ilustran distintos aspectos de las actividades de computación, y
constituyen una reconstrucción formal de las mismas7.
Pero el núcleo crítico de conocimiento requerido para la puesta a punto de métodos
computacionales de resolución de problemas no consiste en la aplicación de las reglas
heurísticas a las que me he referido en la sección anterior, sino en una destreza mucho más
elusiva, y difícilmente codificable, la destreza de modelización, normalmente ligada a las
actividades de análisis funcional y diseño técnico del ciclo de vida. Modelizar consiste en
identificar partes y aspectos relevantes del dominio del problema, del mundo real, que
puedan ser representados simbólicamente, de forma que esta representación pueda ser
organizada en estructuras y procesos manipulables computacionalmente para obtener la
solución requerida por el problema planteado. Aunque tradicionalmente el concepto de
modelo ha estado vinculado a las actividades de simulación computacional8, Naur ha
señalado recientemente que el producto cognitivo que constituye el núcleo de cualquier
actividad de análisis y diseño es, en realidad, un modelo del proceso de computación que
6
Algunas de las más conocidas son, en el ámbito del análisis y la programación
estructurada, [DeMarco, 1979], [Yourdon, 1979], [Jackson, 1983], [Yourdon, 1989], y en el
ámbito del análisis y la programación orientada a objetos, [Cox, 1986], [Coad, 1990],
[Rumbaugh, 1991], [Booch, 1991].
7
8
Ver [Naur, 1990], especialmente las secciones 4 y 5.
Sigue siendo de gran interés el tratamiento teórico de la modelización presentado en el
clásico [Zeigler, 1976].
3
resuelve el problema planteado en la especificación de requerimientos9. Más exactamente,
Naur nos dice que lo que elabora el analista es una teoría acerca del proceso computacional
en cuestión. En este mismo sentido, pero de forma quizás más indirecta, afirmaba Shallis
hace algún tiempo que estas tecnologías de la información pertenecen a una familia de
tecnologías que no se limitan a aumentar la potencia de las facultades humanas, sino que,
además, reflejan ideas o abstracciones. Así como el reloj es un modelo autónomo del
decurso temporal, basado en un modelo previo del movimiento planetario, el ordenador
"modela la noción de racionalidad pura, la visión ideal que el hombre tiene de su propia
inteligencia”10.
El concepto de teoría que Naur trae explícitamente a colación es el de Ryle11 al que me
hemos referido más arriba. Una persona que tiene una teoría en este sentido sabe cómo
hacer determinadas cosas y, además, puede justificar y explicar lo que hace. El analista,
desde esta perspectiva12, construye una hipótesis acerca del proceso computacional que, en
su opinión resolverá el problema especificado. El modelo de análisis será refinado y
completado operacionalmente en la fase de diseño, y transformado en un programa
ejecutable en la fase de codificación. Todo en este proceso, y desde la perspectiva que
considera al programa como una teoría, nos recuerda la clásica postulación de la
contrastación de una hipótesis teórica mediante la comparación de sus consecuencias
observacionales (en este caso, los resultados de la ejecución del programa) con los datos
recogidos en el dominio del problema de forma independiente (especificados en este caso
bajo la forma de un protocolo de pruebas que incluya condiciones límites de resolución del
problema). Es en este sentido en el que podemos afirmar que el núcleo de la ingeniería del
software lo constituye una actividad de teorización o modelización, un saber-que.
Es importante reparar en el hecho de que esta observación de Naur cubre absolutamente
todas las actividades de computación, y no sólo aquéllas que explícitamente se reclaman
como intentos de construcción de modelos computacionales como hipótesis teóricas en un
campo determinado13. Lo que en cada caso se trata, cuando se diseña una aplicación
informática, no es tanto de averiguar cuál es el proceso computacional que resuelve el
problema planteado, sino de encontrar -o construir- uno que lo resuelva con la eficiencia
requerida. Se da por supuesto, en cada caso, que el problema es computacionalmente
soluble y que, dada su complejidad, es un problema tratable. Pero ésta es toda la base
teórica disponible. No obstante, en los últimos años se han llevado a cabo algunos intentos
por incorporar a la tecnología, de forma normalizada, partes de ese conocimiento específico
especialmente relevantes para la modelización computacional, los llamados modelos
genéricos14.
Un modelo genérico es un método computacional de resolución de problemas de una clase
dada, que representa una racionalización del comportamiento de solución de problemas que
exhiben los expertos que solucionan problemas de esa clase. Cada tipo de problema
(diagnóstico, planificación, predicción, diseño, etc.) tiene un modelo distinto. Cada modelo
genérico proporciona al modelizador, conocimiento de tres tipos distintos:
9
Ver [Naur ,1985, 37-39].
Shallis, M. (1991), p. 31.
10
11
12
Ver Ryle, G. (1949).
Que Naur denomina la Theory Building View. ibid., p. 41.
13
Por ejemplo, en el caso de las ciencias cognitivas. Ver [Femández, 1981], [Fernández,
1984].
14
O "modelo de conocimiento experto". Ver [Breuker, 1994]. El concepto guarda una
estrecha relación con el de "tarea genérica" recogido en [Chandrasekaran, 1987].
4
a) Conocimiento de la tarea, que nos dice cómo se descompone recursivamente la tarea en
subtareas, cuáles son los objetivos de cada una de ellas, y cómo se ordenan entre sí
(control).
b) Conocimiento inferencial, que especifica cuáles son los tipos de razonamiento básicos
-entendiendo por tal el repertorio de las operaciones primitivas que se ejecutan sobre los
datos-, cuál es el tipo de conocimiento del dominio utilizado en cada tipo de inferencia
requerido (knowledge role), y cómo se articulan entre sí los distintos tipos de
razonamiento (estructura inferencial).
c) Además, el modelo genérico puede, y debe incluir metaconocimiento, es decir, una
justificación del modelo que incluye una guía para la estructuración de un dominio,
estrategias de ajuste de las soluciones genéricas a las situaciones específicas, y
métodos genéricos de solución de problemas.
Por otro lado, todo modelo genérico incluye una determinada categorización o conceptualización del dominio del problema, a la que se suele dar el nombre de "ontología".
Dado que su papel es relevante para mi argumento en tomo a la naturaleza de la ingeniería
de software como un conocimiento del tipo saber-que, dedicaré la siguiente sección a
examinarla brevemente.
3. Modelización de las entidades del dominio del problema: Ontologías
Aunque, explícitamente, parece como si Naur sólo hablara del aspecto procedural de la
modelización computacional, no se puede entender ésta sin tener en cuenta eso que
tradicionalmente se ha llamado el "modelo de datos". Evidentemente, para resolver
computacionalmente un problema, no sólo se requiere una adecuada implementación del
algoritmo, sino también una adecuada representación de los datos sobre los que el
algoritmo se aplica15. Las dos técnicas de modelización más relevantes de este componente
no-procedural del modelo computacional son el modelo entidad-relación del paradigma
relacional16, y el modelo de objetos del paradigma de la orientación a objetos17. En ambos
casos, los datos se modelizan teniendo en cuenta los procesos que han de ejecutarse sobre
ellos, por lo que resulta determinante el manteniento, durante el diseño de dicho modelo, de
la perspectiva funcional, esto es, qué es lo que el diseñador quiere hacer con el sistema que
está diseñando. De ello se infiere que la conceptualización de un mismo dominio puede
cambiar en función de cuál sea el propósito del sistema que estamos diseñando.
En los últimos años se ha producido un cambio importante en este aspecto, impuesto
también por el requerimiento general de la eficiencia tecnológica, especificado en este caso
como el requerimiento de reusabilidad, que ha encontrado su fuerza en el paradigma de la
orientación a objetos. Al igual que existen librerías de algoritmos que un diseñador puede
utilizar como ladrillos o piezas básicas de su aplicación, puede disponerse de librerías de
15
Así, Wirth ha sintetizado 10 que es la informática diciendo que se trata de "algoritmo s +
datos".
16
17
Ver [Date, 1986].
Ver [Rumbaugh, 1991]
5
categorizaciones de dominios, que podrían utilizarse en muchas aplicaciones distintas. Cada
una de estas librerías recibe el nombre de ontología.
Una ontología es el conjunto de entidades o tipos naturales de un dominio o de una
determinada perspectiva sobre dicho dominio. En el sentido en que aquí empleamos el
término, una ontología es, como dice Gruber18, una especificación explícita de una
conceptualización. A su vez, ésta no es sino una visión abstracta o simplificada del mundo,
que se expresa en una ontología como un vocabulario representacional que podemos
utilizar para referirnos a las entidades de un universo dado (clases, relaciones, funciones,
etc.). Cada término de ese vocabulario va asociado a una definición. Pero a diferencia de lo
que sucede con una entrada de un diccionario de datos o una especificación de una clase
de objetos, cada definición "informal" va acompañada, en el caso de una ontología, de un
conjunto de axiomas que restringen las interpretaciones posibles de los términos. En ese
sentido, dice Gruber que establecer una ontología equivale a "formular una teoría lógica”19.
Lo más llamativo de una ontología, desde el punto de vista de nuestra tarea de
caracterización del tipo de conocimiento tecnológico asociado con la ingeniería del software,
es que, a pesar de que Gruber manifiesta que el criterio fundamental para el diseño de una
ontología es el impuesto por "el propósito del artefacto resultante", esto es, por el objetivo de
la aplicación, y no por ninguna "noción a priori de naturalidad o Verdad", en su posterior
definición de las condiciones que ha de cumplir toda ontología, este criterio básico pierde
fuerza.
Efectivamente, para Gruber, toda ontología de este tipo ha de ser clara, coherente,
monótonamente extendible; y su sesgo representacional, y su compromiso ontológico,
deben ser mínimos. Pero las exigencias de extensibilidad monótona y de minimización del
compromiso ontológico, que han de permitir que una ontología pueda ser utilizada para un
rango dado de aplicaciones potenciales, que extiendan y especialicen la ontología en la
forma en que se requiera en cada aplicación, llevan a Gruber a concluir que esa ontología
ha de ser formulada como la teoría más débil, en el sentido de que sea la teoría que permita
el mayor número de modelos posibles. Inevitablemente, ello debilita el punto de vista
funcional proclamado al principio como fundamental, lo que queda de relieve en la propia
afirmación de Gruber de que lo que distingue básicamente a una ontología de una base de
conocimiento es que esta última "puede incluir el conocimiento necesario para resolver un
problema o para responder preguntas sobre un dominio", mientras que la ontología se limita
a describir un vocabulario útil para hablar acerca de ese dominio. Pero esto supone, de
hecho, defender que esa separación de la perspectiva funcional es efectivamente posible
cuando se describe un dominio o, lo que es lo mismo, que se puede adoptar, en la
descripción de éste, un punto de vista privilegiado, desde el que la aplicación del
conocimiento se pone entre paréntesis. Dicha postura se ha encarnado, efectivamente, en la
elaboración de una ontología "genérica" o "formal", concebida como un corpus de
"distinciones a priori" sancionadas filosófica y lógicamente20.
Sin entrar a considerar la validez del aserto de la independencia funcional -mi impresión es
que en la modelización computacional es imposible proceder así21- , la consecuencia de la
18
19
20
21
Ver [Gruber, 1993], [Gruber, 1993a].
[Gruber, 1993a], p.2
Ver [Guarino, 1993a], [Gruber, 1991] , [Cocchiarella, 1991].
En un reciente proyecto (Ver [CARES, 1997]) hemos podido comprobar que el hecho de
que el modelo de objetos (en este caso, un modelo del lenguaje Ensamblador del IBM 370)
preceda a una adecuada especificación de las funcionalidades del sistema a desarrollar (en
este caso, un sistema de ayuda a la modificación extensiva y al mantenimiento de grandes
6
proliferación cada vez mayor de librerías de clases, y de ontologías, en la ingeniería del
software, es un hecho que pone de relieve, más claramente que en la formulación de Naur,
que, en la naturaleza de esta tecnología se encuentra un tipo de conocimiento que no es un
mero know-how, sino un know-that. Evidentemente, puesto que la aplicación de la
tecnología exige la adopción de determinadas decisiones acerca de qué herramientas
-medios de desarrollo, algoritmos, ontologías, etc.- utilizar, en qué grado, en qué
combinación, etc, el resultado final es, como en el caso de cualquier otra tecnología, un
saber-cómo, aunque en este caso, se requiere la realización de una tarea de modelización
que resulta en un saber-que. Lo que podríamos planteamos a partir de aquí es si este saberque, y cualquier otro -típicamente, el conocimiento científico-, es, o no, funcionalmente
independiente. Pero ésta es otra cuestión.
Referencias
[Allen,1991] Allen, J., Fikes, R., Sandewall, E. (eds.), PrincipIes of Knowledge
Representation and Reasoning, M. Kaufmann, 1991.
[Booch,1991] Booch, G., Object-oriented Design, Benjamin/ Cummings, 1991.
[Breuker, 1994] Breuker, J., Van de Velde, W., CommonKADS Library for Expertise
Modelling, lOS Press, 1994.
[Bunge, 1966] Bunge, M., "Technology as Applied Science", Technology and Culture, 7, 329347, 1966.
[Burkhardt,1991] Burkhardt, H., Smith, B. (eds.), Handbook of Metaphysics and Ontology,
Philosophia V., 1991.
[CARES, 1997] CARES Final Report, Esprit 20344. INDRA/ IBERlA / University of Limerick,
1997.
[Chandrasekaran, 1987] Chandrasekaran, B., "Towards a functional architecture for
intelligence based on generic information processing tasks", en Procs. of the 10th lnt. J Conf.
on Al, Milano, 1183-1192, 1987.
[Cox,1986] Cox, B. J., Object-oriented Programming, Addison-Wesley, 1986.
[Coad,1990] Coad, P., Yourdon, E., Object-oriented Analysis, Yourdon Press, 1990.
[Cochiarella, 1991] Cochiarella, N. B., "Formal Ontology", en [Burkhardt, 1991]. [Date, 1986]
Date, C. J., An Introduction to Database Systems, Addison-Wesley,1986.
[DeMarco, 1979] DeMarco, T., Structured Analysis and System Specification, Prentice Hall,
1979.
[Feibleman, 1961] Feibleman, J. K., "Pure Science, Applied Science, and Technology", en
Technology and Culture, ll, 4, 1961. Incluido en [Mitcham, 1983,33- 41].
[Femández, 1981] Femández, R., "Notas para la discusión en tomo a la consideración de los
programas de ordenador como teorías", en [Jáñez, 1981], 10-24.
[Femández, 1984] Femández, R., "Autómatas como modelos teóricos", en Actas I Simposio
Hispano-Mexicano de Filosofía, Edic. Universidad de Salamanca, Vol. I,334-356, 1984.
aplicaciones programadas en ese lenguaje) dificulta considerablemente la especificación e
implementación de procedimientos de explotación de los datos, aun siendo aparentemente
este dominio –el del análisis estático de programas- un dominio extremadamente neutro
respecto a posibles interpretaciones.
7
[Gruber,1991] Gruber, T. R., "The role of common ontology in achieving shareable, reusable
knowledge bases", en [Allen, 1991],601-602.
[Gruber,1993] Gruber, T. R., "A Translation Approach to Portable Ontology Specification", en
Knowledge Acquisition, 5 (2), 199-220, 1993.
[Gruber,1993a] Gruber, T. R., "Toward Principies for fue Design of Ontologies Used for
Knowledge Sharing", Technical Report KSL 93-04, Knowledge Systems Laboratory,
Standford University, 1993.
[Guarino, 1993] Guarino, N., Poli, R. (eds.), Formal Ontology in Conceptual Analysis and
Knowledge Representation. Workshop Preprints, 17-19 Marzo 1993. LADSEB-CNR Int. Rep.
01/93.
[Guarino, 1993a] Guarino, N., Boldrin, L., "Concepts and Relations", en [Guarino, 1993].
[Jackson, 1983] Jackson, M. A., System Development, Prentice Hall Int., 1983.
[Jáñez, 1981] Jáñez, L. (ed.), Simulación en Psicología, Publ. del Dpto. de Psicología
Matemática, UCM, 1981.
[Jarvie, 1983] Jarvie, l. C., "Technology and fue Structure of Knowledge", en [Mitcham,
1983,54-61]. Revisión de la primera versión de 1967.
[Knuth, 1968, 1973] Knuth, D. E. The Art of Computer Programming, Addison- Wesley, 1968,
1973,
[Mitcham,1983] Mitcham, C, Mackey, R. (eds.), Philosophy and Technology, The Free Press,
1983.
[Mosterín, 1978] Mosterín, J., Racionalidad y Acción Humana, Alianza, 1978.
[Naur, 1985] Naur, P., "Programming as theory building", Microprocessing and
Microprogramming, 15, pp. 253-261, 1985. Recogido en [Naur, 1992,37- 49].
[Naur, 1990] Naur, P., "Computing and the so-called foundations of the so-called sciences",
Informatics Curricula for the 1990s, IFIP Working Group 3.2 Workshop, Providence, Rhode
Island. April 6, 1990. Recogido en [Naur, 1992,49-63].
[Naur, 1992] Naur, P., Computing: A Human Activity, ACM Press, 1992. [Quintanilla, 1979]
Quintanilla, M. A., "El problema de la racionalidad tecnológica", 107-131, (1979).
[Rochlin, 1997] Rochlin, G. l., Trapped in the Net, Princeton U. P., 1997.
[Rumbaugh, 1991] Rumbaugh, J. et al., Object-oriented Modeling and Design, Prentice Hall,
1991
[Ryle,1949] Ryle, G., The Concept of Mind. Reed. Penguin, 1963.
[Shallis, 1991] Shallis, M., "The Silicon Idol", en [Zerzan, 1991].
[Skolimowski, 1966] Skolimowski, H., "The Structure of Thinking in Technology", en
Technology and Culture, VII, 3, 1966. Incluído en [Mitcham, 1983,42-49].
[Wooley, 1994] Wooley, B., El universo virtual, Acento, 1994.
[Yourdon, 1979] Yourdon, E. y Constantine, L. L., Structured Design, Yourdon Press, 1979.
[Yourdon, 1989] Yourdon, E., Modern Structured Analysis, Yourdon Press, 1989.
[Zeigler, 1976] Zeigler, B. P., Theory of Modelling and Simulation, J. Wiley, 1976.
[Zerzan, 1991] Zerzan, J., Carnes, A. (eds.) Questioning Technology: Too/, Toy, or Tyran?,
New Society Publishers, 1991.
8