El Asistente de software basado en el conocimiento (KBSA) fue un programa de investigación financiado por la Fuerza Aérea de los Estados Unidos . El objetivo del programa era aplicar conceptos de inteligencia artificial al problema de diseño e implementación de programas informáticos . El software sería descrito por modelos en lenguajes de muy alto nivel (esencialmente equivalente a la lógica de primer orden ) y luego las reglas de transformación transformarían la especificación en código eficiente. La fuerza aérea esperaba poder generar el software para controlar los sistemas de armas y otros comandos y control.sistemas que utilizan este método. A medida que el software se estaba volviendo cada vez más crítico para los sistemas de armas de la USAF, se comprendió que mejorar la calidad y la productividad del proceso de desarrollo de software podría tener beneficios significativos para el ejército, así como para la tecnología de la información en otras industrias importantes de EE. UU.
Historia
A principios de la década de 1980, la Fuerza Aérea de los Estados Unidos se dio cuenta de que había recibido importantes beneficios de la aplicación de tecnologías de inteligencia artificial para resolver problemas de expertos como el diagnóstico de fallas en aeronaves. La fuerza aérea comisionó a un grupo de investigadores de las comunidades de inteligencia artificial y métodos formales para desarrollar un informe sobre cómo estas tecnologías podrían usarse para ayudar en el problema más general del desarrollo de software.
El informe describió una visión para un nuevo enfoque para el desarrollo de software. En lugar de definir especificaciones con diagramas y transformarlas manualmente en código como era el proceso actual, la visión de Knowledge Based Software Assistant (KBSA) era definir especificaciones en lenguajes de muy alto nivel y luego usar reglas de transformación para refinar gradualmente la especificación en código eficiente. en plataformas heterogéneas.
Cada paso en el diseño y perfeccionamiento del sistema se registraría como parte de un repositorio integrado. Además de los artefactos del desarrollo de software, los procesos, las diversas definiciones y transformaciones, también se registrarían de manera que pudieran analizarse y reproducirse posteriormente según sea necesario. La idea era que cada paso fuera una transformación que tuviera en cuenta varios requisitos no funcionales para el sistema implementado. Por ejemplo, los requisitos para usar lenguajes de programación específicos como Ada o para reforzar el código para la tolerancia a fallas críticas en tiempo real. [1]
La fuerza aérea decidió financiar más investigaciones sobre esta visión a través de su laboratorio del Centro de Desarrollo Aéreo de Roma en la base de la fuerza aérea de Griffiss en Nueva York. La mayoría de las primeras investigaciones se llevaron a cabo en el Instituto Kestrel en el norte de California (con la Universidad de Stanford ) y en el Instituto de Ciencias de la Información (ISI) en el sur de California (con USC y UCLA ). El Instituto Kestrel se centró principalmente en la transformación demostrablemente correcta de modelos lógicos en código eficiente. ISI se centró principalmente en la parte inicial del proceso para definir especificaciones que pudieran correlacionarse con formalismos lógicos, pero que estaban en formatos intuitivos y familiares para los analistas de sistemas. Además, Raytheon realizó un proyecto para investigar la recopilación de requisitos informales y Honeywell y la Universidad de Harvard trabajaron en los marcos subyacentes, la integración y la coordinación de actividades.
Aunque no fue financiado principalmente por el programa KBSA, el proyecto MIT Programmer's Apprentice también tenía muchos de los mismos objetivos y utilizaba las mismas técnicas que KBSA. [2]
En las últimas etapas del programa KBSA (a partir de 1991) los investigadores desarrollaron prototipos que se utilizaron en problemas de desarrollo de software de mediana a gran escala. Además, en estas etapas posteriores, el énfasis pasó de un enfoque KBSA puro a cuestiones más generales sobre cómo utilizar la tecnología basada en el conocimiento para complementar y aumentar las herramientas de ingeniería de software asistida por computadora (CASE) existentes y futuras . En estas últimas etapas hubo una interacción significativa entre la comunidad KBSA y las comunidades de ingeniería de software y orientadas a objetos. Por ejemplo, los conceptos e investigadores de KBSA desempeñaron un papel importante en los programas de ingeniería de software de megaprogramación y centrados en el usuario patrocinados por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA). [3] En estas etapas posteriores, el programa cambió su nombre a Ingeniería de software basada en el conocimiento (KBSE). El cambio de nombre reflejó el objetivo de investigación diferente, ya no crear una herramienta totalmente nueva que abarque todo el ciclo de vida del software, sino trabajar gradualmente la tecnología basada en el conocimiento en las herramientas existentes. Empresas como Andersen Consulting (uno de los integradores de sistemas más grandes y en ese momento proveedor de su propia herramienta CASE) desempeñaron un papel importante en el programa en estas etapas posteriores.
Conceptos clave
Reglas de transformación
Las reglas de transformación que utilizó KBSA eran diferentes a las reglas tradicionales para sistemas expertos. Las reglas de transformación se compararon con los lenguajes de especificación e implementación en lugar de con los hechos del mundo. Era posible especificar transformaciones usando patrones, comodines y recursividad en los lados derecho e izquierdo de una regla. La expresión de la mano izquierda especificaría patrones en la base de conocimiento existente para buscar. La expresión de la mano derecha podría especificar un nuevo patrón en el que transformar el lado izquierdo. Por ejemplo, transforme un tipo de datos teórico de conjuntos en código utilizando una biblioteca de conjuntos de Ada. [4]
El propósito inicial de las reglas de transformación era refinar una especificación lógica de alto nivel en un código bien diseñado para una plataforma de hardware y software específica. Esto se inspiró en los primeros trabajos sobre la demostración de teoremas y la programación automática. Sin embargo, los investigadores del Instituto de Ciencias de la Información (ISI) desarrollaron el concepto de transformaciones evolutivas . [5] En lugar de transformar una especificación en código, una transformación evolutiva estaba destinada a automatizar varios cambios estereotipados en el nivel de especificación, por ejemplo, desarrollar una nueva superclase extrayendo varias capacidades de una clase existente que se puede compartir de manera más general. Las transformaciones evolutivas se desarrollaron aproximadamente al mismo tiempo que el surgimiento de la comunidad de patrones de software y los dos grupos compartieron conceptos y tecnología. Las transformaciones evolutivas fueron esencialmente lo que se conoce como refactorización en la comunidad de patrones de software orientados a objetos. [6]
Repositorio basado en conocimientos
Un concepto clave de KBSA era que todos los artefactos: requisitos, especificaciones, transformaciones, diseños, código, modelos de proceso, etc. se representaban como objetos en un repositorio basado en el conocimiento . El informe KBSA original describe lo que se llamó un lenguaje de amplio espectro. El requisito era un marco de representación del conocimiento que pudiera soportar todo el ciclo de vida : requisitos, especificación y código, así como el proceso de software en sí. La representación central de la base de conocimientos estaba destinada a utilizar el mismo marco, aunque se podrían agregar varias capas para admitir presentaciones e implementaciones específicas.
Estos primeros marcos de base de conocimientos fueron desarrollados principalmente por ISI y Kestrel basándose en entornos de máquina Lisp y Lisp . El entorno de Kestrel finalmente se convirtió en un producto comercial llamado Refine que fue desarrollado y respaldado por una empresa derivada de Kestrel llamada Reasoning Systems Incorporated.
El lenguaje y el entorno de Refine también demostraron ser aplicables al problema de la ingeniería inversa del software: tomar código heredado que es crítico para el negocio pero que carece de la documentación adecuada y usar herramientas para analizarlo y transformarlo en una forma más fácil de mantener. Con la creciente preocupación por el problema del año 2000, la ingeniería inversa fue una preocupación comercial importante para muchas grandes corporaciones estadounidenses y fue un área de enfoque para la investigación de KBSA en la década de 1990. [7] [8]
Hubo una interacción significativa entre las comunidades KBSA y el lenguaje Frame y las comunidades orientadas a objetos . Las primeras bases de conocimiento de KBSA se implementaron en lenguajes basados en objetos en lugar de orientados a objetos . Los objetos se representaron como clases y subclases, pero no fue posible definir métodos en los objetos. En versiones posteriores de KBSA, como Andersen Consulting Concept Demo, el lenguaje de especificación se amplió para admitir el paso de mensajes también.
Asistente inteligente
KBSA adoptó un enfoque diferente al de los sistemas expertos tradicionales cuando se trataba de cómo resolver problemas y trabajar con los usuarios. En el enfoque tradicional del sistema experto, el usuario responde a una serie de preguntas interactivas y el sistema proporciona una solución. El enfoque de KBSA dejó al usuario en control. Mientras que un sistema experto intentó, hasta cierto punto reemplazar y eliminar la necesidad del experto, el enfoque del asistente inteligente en KBSA buscó reinventar el proceso con tecnología. Esto condujo a una serie de innovaciones a nivel de interfaz de usuario.
Un ejemplo de la colaboración entre la comunidad orientada a objetos y KBSA fue la arquitectura utilizada para las interfaces de usuario de KBSA. Los sistemas KBSA utilizaron una interfaz de usuario modelo-vista-controlador (MVC). Esta fue una idea incorporada de los entornos Smalltalk. [9] La arquitectura MVC se adaptó especialmente bien a la interfaz de usuario de KBSA. Los entornos de KBSA presentaban múltiples vistas heterogéneas de la base de conocimientos. Puede resultar útil observar un modelo emergente desde el punto de vista de entidades y relaciones, interacciones de objetos, jerarquías de clases, flujo de datos y muchas otras posibles vistas. La arquitectura MVC facilitó esto. Con la arquitectura MVC el modelo subyacente era siempre la base de conocimientos que era un meta-modelo de descripción de los lenguajes de especificación e implementación. Cuando un analista hizo algún cambio a través de un diagrama en particular (por ejemplo, agregó una clase a la jerarquía de clases), ese cambio se realizó en el nivel del modelo subyacente y las diversas vistas del modelo se actualizaron automáticamente. [10]
Uno de los beneficios de utilizar una transformación era que muchos aspectos de la especificación y la implementación se podían modificar a la vez. Para los prototipos a pequeña escala, los diagramas resultantes eran lo suficientemente simples como para que los algoritmos de diseño básicos combinados con la dependencia de los usuarios para limpiar los diagramas fueran suficientes. Sin embargo, cuando una transformación puede redibujar radicalmente modelos con decenas o incluso cientos de nodos y enlaces, la actualización constante de las distintas vistas se convierte en una tarea en sí misma. Los investigadores de Andersen Consulting incorporaron el trabajo de la Universidad de Illinois sobre teoría de grafos para actualizar automáticamente las diversas vistas asociadas con la base de conocimientos y generar gráficos que tienen una intersección mínima de enlaces y también tienen en cuenta las restricciones de diseño específicas del usuario y del dominio.
Otro concepto utilizado para brindar asistencia inteligente fue la generación automática de texto. Las primeras investigaciones en ISI investigaron la viabilidad de extraer especificaciones formales de documentos de texto informales en lenguaje natural. Determinaron que el enfoque no era viable. El lenguaje natural es por naturaleza demasiado ambiguo para servir como un buen formato para definir un sistema. Sin embargo, se consideró factible la generación de lenguaje natural como una forma de generar descripciones textuales que pudieran ser leídas por gerentes y personal no técnico. Esto fue especialmente atractivo para la fuerza aérea ya que por ley exigían a todos los contratistas que generaran varios informes que describieran el sistema desde diferentes puntos de vista. Los investigadores de ISI y luego Cogentext y Andersen Consulting demostraron la viabilidad del enfoque utilizando su propia tecnología para generar la documentación requerida por sus contratos de la fuerza aérea. [11]
Referencias
- ^ Verde, Cordell; D. Luckham; R. Balzer; T. Cheatham; C. Rich (agosto de 1983). "Informe sobre un asistente de software basado en el conocimiento" (PDF) . Instituto Kestrel . A996431: 78 . Consultado el 4 de enero de 2014 .
- ^ Rich, Charles; Richard C. Waters (noviembre de 1988). "El proyecto de aprendiz de programador: una visión general de la investigación" (PDF) . Computadora . 21 (11): 10-25. doi : 10.1109 / 2.86782 . hdl : 1721,1 / 6054 . Consultado el 26 de diciembre de 2013 .
- ^ DeBellis, Michael; Christine Haapala (febrero de 1995). "Ingeniería de software centrada en el usuario". Experto IEEE . 10 (1): 34–41. doi : 10.1109 / 64.391959 .
- ^ Smith, Doug (1991). "KIDS - Un sistema de desarrollo de software basado en el conocimiento". En Michael Lowry, Robert McCartney (ed.). Automatización del diseño de software . AAAI / MIT Presione. págs. 483–514. CiteSeerX 10.1.1.54.6955 . ISBN 978-0262620802.
- ^ Johnson, Lewis; MS Feather (1991). "Uso de transformaciones evolutivas para construir especificaciones". Automatización del diseño de software . AAAI Press: 65–92.
- ^ Fowler, Martin (1999). Refactorización: mejora del diseño del código existente . Addison Wesley. ISBN 0201485672.
- ^ Boehm, Barry; Prasanta Bose (15 de agosto de 1998). "Evaluación del ciclo de vida de KBSA: Informe técnico final" (PDF) . Contrato No: F30602-96-C-0274 . Centro de Ingeniería de Software de la USC. Yo . Consultado el 4 de enero de 2014 .
A medida que el programa ha avanzado hacia sus objetivos finales, ha generado una serie de productos derivados que mejoran la productividad, como las herramientas de prueba y reingeniería de software basadas en Refine.
- ^ Welty, Chris. "Resumen de KBSE-93: la octava conferencia anual de ingeniería de software basada en el conocimiento" . ase-conferences.org . Consultado el 4 de enero de 2014 .
REFINE / COBOL Object Modeling Workbench proporciona un conjunto de herramientas de reingeniería. Refine es el lenguaje de la demostración del concepto de KBSA.
- ^ Harris, Dave; A. Czuchry (1988). "El asistente de requisitos basados en el conocimiento". Experto IEEE . 3 (4).
- ^ Johnson, Lewis; David R. Harris; Kevin M. Benner; Martin S. Feather (octubre de 1992). "Aries: la faceta de requisitos / especificación para KBSA". Informe técnico final del laboratorio de Roma . RL-TR-92-248.
- ^ DeBellis, Michael; Kanth Miriyala; Sudin Bhat; William C. Sasso; Owen Rambo (abril de 1993). "Demostración del concepto de KBSA: Informe técnico final" . Informe técnico del laboratorio de la USAF en Roma . RL-TR-93-38 . Consultado el 4 de enero de 2014 .