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 software informático . El software se describiría mediante 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 sistemas de mando y control utilizando este método. A medida que el software se volvía 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 importantes beneficios para el ejército, así como para la tecnología de la información en otras industrias importantes de Estados Unidos.
A principios de la década de 1980, la Fuerza Aérea de los Estados Unidos se dio cuenta de que había obtenido importantes beneficios al aplicar tecnologías de inteligencia artificial para resolver problemas expertos como el diagnóstico de fallas en las aeronaves. La fuerza aérea encargó a un grupo de investigadores de las comunidades de inteligencia artificial y métodos formales que desarrollaran un informe sobre cómo se podrían utilizar dichas tecnologías para ayudar en el problema más general del desarrollo de software.
El informe describe una visión de 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 del Asistente de software basado en el conocimiento (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 más adelante según fuera necesario. La idea era que cada paso fuera una transformación que tomara en cuenta varios requisitos no funcionales para el sistema implementado. Por ejemplo, requisitos para utilizar lenguajes de programación específicos como Ada o reforzar el código para lograr 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 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 el Instituto de Ciencias de la Información (ISI) en el sur de California (con la USC y la 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, en la definición de especificaciones que pudieran corresponderse con formalismos lógicos pero que estuvieran en formatos intuitivos y familiares para los analistas de sistemas. Además, Raytheon realizó un proyecto para investigar la recopilación informal de requisitos y Honeywell y la Universidad de Harvard trabajaron en marcos subyacentes, integración y coordinación de actividades.
Aunque no fue financiado principalmente por el programa KBSA, el proyecto Aprendiz de Programador del MIT 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 (que comenzó en 1991), los investigadores desarrollaron prototipos que se utilizaron en problemas de desarrollo de software de mediana y gran escala. Además, en estas últimas etapas el énfasis pasó de un enfoque puro de KBSA a preguntas 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 orientada a objetos. Por ejemplo, los conceptos e investigadores de KBSA desempeñaron un papel importante en los programas de megaprogramación y de ingeniería de software centrados en el usuario patrocinados por la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA). [3] En estas últimas etapas, el programa cambió su nombre a Ingeniería de software basada en el conocimiento (KBSE). El cambio de nombre reflejó el objetivo diferente de la investigación: ya no crear una herramienta totalmente nueva que cubra todo el ciclo de vida del software, sino incorporar gradualmente la tecnología basada en el conocimiento en las herramientas existentes. Empresas como Andersen Consulting (uno de los mayores integradores de sistemas y en ese momento proveedor de su propia herramienta CASE) desempeñaron un papel importante en el programa en estas últimas etapas.
Las reglas de transformación que utilizó KBSA eran diferentes a las reglas tradicionales para sistemas expertos. Las reglas de transformación se comparan con los lenguajes de especificación e implementación en lugar de con los hechos del mundo. Era posible especificar transformaciones utilizando patrones, comodines y recursividad tanto en el lado derecho como en el izquierdo de una regla. La expresión de la izquierda especificaría patrones en la base de conocimiento existente a buscar. La expresión de la derecha podría especificar un nuevo patrón para transformar el lado izquierdo. Por ejemplo, transforme un tipo de datos teórico establecido en código utilizando una biblioteca de conjuntos 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 demostración de teoremas y programación automática. Sin embargo, 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 tenía como objetivo automatizar varios cambios estereotipados a 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 de la evolución fueron esencialmente lo que se conoce como refactorización en la comunidad de patrones de software orientado a objetos. [6]
Un concepto clave de KBSA era que todos los artefactos: requisitos, especificaciones, transformaciones, diseños, código, modelos de procesos, etc. se representaban como objetos en un repositorio basado en conocimiento . El informe original de KBSA 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, especificaciones y código, así como el proceso del software en sí. La representación central de la base de conocimientos debía utilizar el mismo marco, aunque se podrían agregar varias capas para respaldar presentaciones e implementaciones específicas.
Estos primeros marcos de base de conocimientos fueron desarrollados principalmente por ISI y Kestrel sobre los entornos de máquinas 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 Refine también demostraron ser aplicables al problema de la ingeniería inversa de software: tomar código heredado que es fundamental para el negocio pero que carece de la documentación adecuada y utilizar herramientas para analizarlo y transformarlo a una forma más fácil de mantener. Con la creciente preocupación por el problema del año 2000, la ingeniería inversa se convirtió en una importante preocupación comercial 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 representaban como clases y subclases pero no era posible definir métodos en los objetos. En versiones posteriores de KBSA, como la demostración del concepto de Andersen Consulting, el lenguaje de especificación se amplió para admitir también el paso de mensajes.
KBSA adoptó un enfoque diferente al de los sistemas expertos tradicionales cuando se trataba de resolver problemas y trabajar con los usuarios. En el enfoque tradicional del sistema experto, el usuario responde una serie de preguntas interactivas y el sistema proporciona una solución. El enfoque de KBSA dejó el control al usuario. Mientras que un sistema experto intentaba, hasta cierto punto, reemplazar y eliminar la necesidad del experto, el enfoque de asistente inteligente en KBSA buscaba reinventar el proceso con tecnología. Esto condujo a una serie de innovaciones a nivel de interfaz de usuario.
Un ejemplo de 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 adaptaba especialmente bien a la interfaz de usuario KBSA. Los entornos KBSA presentaban múltiples vistas heterogéneas de la base de conocimientos. Podría 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 vistas posibles. La arquitectura MVC facilitó esto. Con la arquitectura MVC, el modelo subyacente siempre fue la base de conocimientos, que era una descripción del metamodelo de los lenguajes de especificación e implementación. Cuando un analista realizó algún cambio a través de un diagrama 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 podían modificarse a la vez. Para prototipos de pequeña escala, los diagramas resultantes fueron lo suficientemente simples como para que los algoritmos de diseño básicos combinados con la confianza en 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 trabajos 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 tengan una mínima intersección de enlaces y que también tengan en cuenta las limitaciones de diseño específicas del dominio y del usuario.
Otro concepto utilizado para brindar asistencia inteligente fue la generación automática de textos. 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 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 que todos los contratistas generaran varios informes que describieran el sistema desde diferentes puntos de vista. Los investigadores de ISI y más tarde de Cogentext y Andersen Consulting demostraron la viabilidad del enfoque utilizando su propia tecnología para generar la documentación requerida por sus contratos con la fuerza aérea. [11]
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.
REFINE/COBOL Object Modeling Workbench proporciona un conjunto de herramientas de reingeniería; Refine es el lenguaje de la demostración del concepto KBSA.