1

CONOCIMIENTO TECNOLÓGICO:

EL CASO DE LA INGENIERÍA DEL SOFTWARE1

Rodolfo Fernández GonzálezDpto. 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 algunosintelectuales 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 realidadvirtual no es sino la conversión en espectáculo de una tarea que siempre ha estadoasociada al núcleo de la tecnología de la información, la ingeniería de software. Dicha tareaes requerida para el desarrollo de cualquier sistema informático, hasta tal punto que cabecaracterizar el tipo de conocimiento requerido por la ingeniería del software no como unsaber-cómo (know-how), sino como un saber-que (know-that). Según la opinión máscomún3, el saber tecnológico4 es un saber-cómo. Me interesa explorar aquí la consideraciónde 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 saber-que. Esta consideración ha sido adelantada por Naur5, en el sentido de que la ingeniería desoftware 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á estaperspectiva, 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 delproblema, que, en los últimos años, se tiende a hacer lo más independiente posible delpropó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 enSalamanca, el 18 de Febrero de 19982 Ver, por ejemplo, [Wooley 1994].3 Ver, por ejemplo, Jarvie, l. C. (1983).4 En lo que sigue, supondremos que una "destreza" (skill) es una estrategia de solución de problemasque los individuos aprenden mediante una actividad informal de prueba y error para la ejecución detareas cotidianas. Una "técnica" de resolución de problemas en un dominio dado es una destreza queel individuo adquiere, mediante una actividad formal de enseñanza/aprendizaje, bajo la forma de uncon- junto de reglas obtenidas empíricamente (expertise). En este sentido, una técnica no es sino unaextensión de los sentidos, y de las destrezas, naturales- Shallis, M. (1991), p. 26.-, que en ocasionesse materializa en "artefactos"- Skolimowski, H. (1966), p. 44.-. Una "tecnología" es una técnica queincluye en el conjunto de reglas que la codifican, y en el diseño y desarrollo de los artefactos que lamaterializan, partes relevantes del conocimiento científico disponible. Sobre la naturaleza de latecnologí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).

2

1. Ingeniería de Software como saber-cómo

Bajo la etiqueta de "tecnologías de la información" nos referimos normalmente a tecnologíasde tres tipos distintos:

a) Las tecnologías del hardware, que nos pernliten diseñar y construir dispositivoselectrónicos -computadoras digitales u "ordenadores"- para representarelectrónicamente, almacenar y manipular información.b) Las tecnologías de la comunicación, que nos permiten diseñar y construirsistemas de transmisión de la información entre puntos arbitrariamente separados enel 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 lamanipulación de la información, intentando, a la vez, que dicha manipulación serealice 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 devida". Este no es más que un registro que indica a los analistas y programadores cuáles sonlas tareas que han de llevar a cabo, y en qué orden. Habitualmente, tenemos en un ciclo devida 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 losalgoritmos que han de ejecutar las manipulaciones de datos requeridas, teniendo encuenta, asimismo, algunas de las especificaciones no funcionales. Se definen lasarquitecturas funcionales y de flujo de datos, y se construyen algunos prototipos omaquetas 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 ysoftware elegidas. Asimismo, en esta fase se elabora la arquitectura software delsistema, identificando módulos y programas, y se ponen a punto baterías depruebas.

• Codificación o construcción de programas en el lenguaje de programación elegido - orequerido- para la aplicación.

• Pruebas unitarias, en las que se revisa el funcionamiento de cada programa omó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 puededar 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 cuyopapel en el desarrollo es menos directo:

3

• Planificación del proyecto, incluyendo una especificación de la estrategia de gestióny control del proyecto y, especialmente, de los recursos humanos y de tiempodisponibles.

• 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 reglasheurísticas que tratan de garantizar que el resultado final de cada proyecto se ajuste a losrequerimientos especificados inicialmente. Estas reglas se codifican en distintasmetodologías de análisis, programación y pruebas6.

2. La ingeniería de software como saber-que: Modelización del proceso decomputación

Lo que hace de estas actividades una tecnología, y no simplemente una técnica, en elsentido especificado anteriormente, es el uso reiterado que en ellas se hace de notacio- nessimbólicas o lenguajes formales, y de mecanismos computacionales, deductivos yalgoritmicos asociados a dichas notaciones o lenguajes. El complejo formado por estoslenguajes 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 deestablecer las propiedades matemáticas de las correspondientes teorías formales. Dichosresultados matemáticos ilustran distintos aspectos de las actividades de computación, yconstituyen una reconstrucción formal de las mismas7.Pero el núcleo crítico de conocimiento requerido para la puesta a punto de métodoscomputacionales de resolución de problemas no consiste en la aplicación de las reglasheurísticas a las que me he referido en la sección anterior, sino en una destreza mucho máselusiva, y difícilmente codificable, la destreza de modelización, normalmente ligada a lasactividades de análisis funcional y diseño técnico del ciclo de vida. Modelizar consiste enidentificar partes y aspectos relevantes del dominio del problema, del mundo real, quepuedan ser representados simbólicamente, de forma que esta representación pueda serorganizada en estructuras y procesos manipulables computacionalmente para obtener lasolución requerida por el problema planteado. Aunque tradicionalmente el concepto demodelo ha estado vinculado a las actividades de simulación computacional8, Naur haseñalado recientemente que el producto cognitivo que constituye el núcleo de cualquieractividad 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ónestructurada, [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 Ver [Naur, 1990], especialmente las secciones 4 y 5.8 Sigue siendo de gran interés el tratamiento teórico de la modelización presentado en elclásico [Zeigler, 1976].

4

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 computacionalen cuestión. En este mismo sentido, pero de forma quizás más indirecta, afirmaba Shallishace algún tiempo que estas tecnologías de la información pertenecen a una familia detecnologí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 deldecurso 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 propiainteligencia”10.El concepto de teoría que Naur trae explícitamente a colación es el de Ryle11 al que mehemos referido más arriba. Una persona que tiene una teoría en este sentido sabe cómohacer 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, ensu opinión resolverá el problema especificado. El modelo de análisis será refinado ycompletado operacionalmente en la fase de diseño, y transformado en un programaejecutable en la fase de codificación. Todo en este proceso, y desde la perspectiva queconsidera al programa como una teoría, nos recuerda la clásica postulación de lacontrastación de una hipótesis teórica mediante la comparación de sus consecuenciasobservacionales (en este caso, los resultados de la ejecución del programa) con los datosrecogidos en el dominio del problema de forma independiente (especificados en este casobajo la forma de un protocolo de pruebas que incluya condiciones límites de resolución delproblema). Es en este sentido en el que podemos afirmar que el núcleo de la ingeniería delsoftware 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 absolutamentetodas las actividades de computación, y no sólo aquéllas que explícitamente se reclamancomo intentos de construcción de modelos computacionales como hipótesis teóricas en uncampo determinado13. Lo que en cada caso se trata, cuando se diseña una aplicacióninformática, no es tanto de averiguar cuál es el proceso computacional que resuelve elproblema planteado, sino de encontrar -o construir- uno que lo resuelva con la eficienciarequerida. Se da por supuesto, en cada caso, que el problema es computacionalmentesoluble y que, dada su complejidad, es un problema tratable. Pero ésta es toda la baseteórica disponible. No obstante, en los últimos años se han llevado a cabo algunos intentospor incorporar a la tecnología, de forma normalizada, partes de ese conocimiento específicoespecialmente relevantes para la modelización computacional, los llamados modelosgenéricos14.Un modelo genérico es un método computacional de resolución de problemas de una clasedada, que representa una racionalización del comportamiento de solución de problemas queexhiben 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 modelogenérico proporciona al modelizador, conocimiento de tres tipos distintos: 9 Ver [Naur ,1985, 37-39].10 Shallis, M. (1991), p. 31.11 Ver Ryle, G. (1949).12 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 unaestrecha relación con el de "tarea genérica" recogido en [Chandrasekaran, 1987].

5

a) Conocimiento de la tarea, que nos dice cómo se descompone recursivamente la tarea ensubtareas, 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 losdatos-, cuál es el tipo de conocimiento del dominio utilizado en cada tipo de inferenciarequerido (knowledge role), y cómo se articulan entre sí los distintos tipos derazonamiento (estructura inferencial).

c) Además, el modelo genérico puede, y debe incluir metaconocimiento, es decir, unajustificació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, ymétodos genéricos de solución de problemas.

Por otro lado, todo modelo genérico incluye una determinada categorización o con-ceptualizació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íade software como un conocimiento del tipo saber-que, dedicaré la siguiente sección aexaminarla 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 lamodelización computacional, no se puede entender ésta sin tener en cuenta eso quetradicionalmente se ha llamado el "modelo de datos". Evidentemente, para resolvercomputacionalmente un problema, no sólo se requiere una adecuada implementación delalgoritmo, sino también una adecuada representación de los datos sobre los que elalgoritmo se aplica15. Las dos técnicas de modelización más relevantes de este componenteno-procedural del modelo computacional son el modelo entidad-relación del paradigmarelacional16, y el modelo de objetos del paradigma de la orientación a objetos17. En amboscasos, los datos se modelizan teniendo en cuenta los procesos que han de ejecutarse sobreellos, por lo que resulta determinante el manteniento, durante el diseño de dicho modelo, dela perspectiva funcional, esto es, qué es lo que el diseñador quiere hacer con el sistema queestá diseñando. De ello se infiere que la conceptualización de un mismo dominio puedecambiar 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, impuestotambién por el requerimiento general de la eficiencia tecnológica, especificado en este casocomo el requerimiento de reusabilidad, que ha encontrado su fuerza en el paradigma de laorientación a objetos. Al igual que existen librerías de algoritmos que un diseñador puedeutilizar 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 Ver [Date, 1986].17 Ver [Rumbaugh, 1991]

6

categorizaciones de dominios, que podrían utilizarse en muchas aplicaciones distintas. Cadauna 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 unadeterminada perspectiva sobre dicho dominio. En el sentido en que aquí empleamos eltérmino, una ontología es, como dice Gruber18, una especificación explícita de unaconceptualizació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 podemosutilizar 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 loque sucede con una entrada de un diccionario de datos o una especificación de una clasede objetos, cada definición "informal" va acompañada, en el caso de una ontología, de unconjunto de axiomas que restringen las interpretaciones posibles de los términos. En esesentido, 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 decaracterizació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 unaontología es el impuesto por "el propósito del artefacto resultante", esto es, por el objetivo dela aplicación, y no por ninguna "noción a priori de naturalidad o Verdad", en su posteriordefinición de las condiciones que ha de cumplir toda ontología, este criterio básico pierdefuerza.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 delcompromiso ontológico, que han de permitir que una ontología pueda ser utilizada para unrango dado de aplicaciones potenciales, que extiendan y especialicen la ontología en laforma en que se requiera en cada aplicación, llevan a Gruber a concluir que esa ontologíaha de ser formulada como la teoría más débil, en el sentido de que sea la teoría que permitael mayor número de modelos posibles. Inevitablemente, ello debilita el punto de vistafuncional proclamado al principio como fundamental, lo que queda de relieve en la propiaafirmación de Gruber de que lo que distingue básicamente a una ontología de una base deconocimiento es que esta última "puede incluir el conocimiento necesario para resolver unproblema o para responder preguntas sobre un dominio", mientras que la ontología se limitaa describir un vocabulario útil para hablar acerca de ese dominio. Pero esto supone, dehecho, defender que esa separación de la perspectiva funcional es efectivamente posiblecuando se describe un dominio o, lo que es lo mismo, que se puede adoptar, en ladescripción de éste, un punto de vista privilegiado, desde el que la aplicación delconocimiento se pone entre paréntesis. Dicha postura se ha encarnado, efectivamente, en laelaboració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 esque en la modelización computacional es imposible proceder así21- , la consecuencia de la 18 Ver [Gruber, 1993], [Gruber, 1993a].19 [Gruber, 1993a], p.220 Ver [Guarino, 1993a], [Gruber, 1991] , [Cocchiarella, 1991].21 En un reciente proyecto (Ver [CARES, 1997]) hemos podido comprobar que el hecho deque 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 (eneste caso, un sistema de ayuda a la modificación extensiva y al mantenimiento de grandes

7

proliferación cada vez mayor de librerías de clases, y de ontologías, en la ingeniería delsoftware, 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 unmero know-how, sino un know-that. Evidentemente, puesto que la aplicación de latecnologí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, unsaber-cómo, aunque en este caso, se requiere la realización de una tarea de modelizaciónque resulta en un saber-que. Lo que podríamos planteamos a partir de aquí es si este saber-que, y cualquier otro -típicamente, el conocimiento científico-, es, o no, funcionalmenteindependiente. Pero ésta es otra cuestión.

Referencias

[Allen,1991] Allen, J., Fikes, R., Sandewall, E. (eds.), PrincipIes of KnowledgeRepresentation 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 ExpertiseModelling, lOS Press, 1994.[Bunge, 1966] Bunge, M., "Technology as Applied Science", Technology and Culture, 7, 329-347, 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 forintelligence 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", enTechnology 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 losprogramas 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 SimposioHispano-Mexicano de Filosofía, Edic. Universidad de Salamanca, Vol. I,334-356, 1984.

aplicaciones programadas en ese lenguaje) dificulta considerablemente la especificación eimplementación de procedimientos de explotación de los datos, aun siendo aparentementeeste dominio –el del análisis estático de programas- un dominio extremadamente neutrorespecto a posibles interpretaciones.

8

[Gruber,1991] Gruber, T. R., "The role of common ontology in achieving shareable, reusableknowledge bases", en [Allen, 1991],601-602.[Gruber,1993] Gruber, T. R., "A Translation Approach to Portable Ontology Specification", enKnowledge Acquisition, 5 (2), 199-220, 1993.[Gruber,1993a] Gruber, T. R., "Toward Principies for fue Design of Ontologies Used forKnowledge Sharing", Technical Report KSL 93-04, Knowledge Systems Laboratory,Standford University, 1993.[Guarino, 1993] Guarino, N., Poli, R. (eds.), Formal Ontology in Conceptual Analysis andKnowledge 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íaMatemá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 andMicroprogramming, 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, RhodeIsland. 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", enTechnology 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.