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