El Knowledge Based Software Assistant (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 del diseño e implementación de software informático . El software se describiría mediante modelos en lenguajes de muy alto nivel (esencialmente equivalentes 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 comando 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 beneficios significativos para el ejército, así como para la tecnología de la información en otras industrias importantes de los EE. UU.
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 especializados , como el diagnóstico de fallas en aeronaves. La Fuerza Aérea encargó a un grupo de investigadores de las comunidades de inteligencia artificial y métodos formales que elaboraran 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 describía una visión para un nuevo enfoque del 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 utilizar reglas de transformación para refinar gradualmente la especificación y convertirla en código eficiente en plataformas heterogéneas.
Cada paso del diseño y el 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 forma que pudieran analizarse y reproducirse más tarde según fuera necesario. La idea era que cada paso fuera una transformación que tuviera en cuenta diversos requisitos no funcionales para el sistema implementado. Por ejemplo, los requisitos para utilizar lenguajes de programación específicos como Ada o para reforzar el código para la tolerancia a fallos críticos en tiempo real. [1]
La fuerza aérea decidió financiar más investigaciones sobre esta visión a través de su laboratorio Rome Air Development Center en la base aérea Griffiss de 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. El ISI se centró principalmente en la parte inicial del proceso de definición de especificaciones que pudieran corresponderse con formalismos lógicos pero que estuvieran en formatos que fueran 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 Programmer's Apprentice 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 escala media a grande. Además, en estas últimas etapas, 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 orientada a objetos. Por ejemplo, los conceptos e investigadores de KBSA desempeñaron un papel importante en los programas de ingeniería de software centrados en el usuario y de megaprogramación 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 para crear una herramienta totalmente nueva y que abarcara todo el ciclo de vida del software, sino para trabajar 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 aquel momento proveedor de su propia herramienta CASE) desempeñaron un papel importante en el programa en estas etapas posteriores.
Las reglas de transformación que KBSA utilizó eran diferentes a las reglas tradicionales para sistemas expertos. Las reglas de transformación se comparaban con lenguajes de especificación e implementación en lugar de con hechos del mundo. Era posible especificar transformaciones utilizando patrones, comodines y recursión 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 para buscar. La expresión de la derecha podría especificar un nuevo patrón para transformar el lado izquierdo. Por ejemplo, transformar un tipo de datos de teoría de conjuntos 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 el trabajo inicial sobre demostración de teoremas y 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 tenía como objetivo automatizar varios cambios estereotípicos a nivel de especificación, por ejemplo, desarrollar una nueva superclase extrayendo varias capacidades de una clase existente que se pueden 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 eran 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 el 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 respaldar todo el ciclo de vida : requisitos, especificaciones y código, así como el proceso de software en sí. La representación central de la base de conocimiento estaba destinada a utilizar el mismo marco, aunque se podían agregar varias capas para respaldar presentaciones e implementaciones específicas.
Estos primeros marcos de trabajo de base de conocimientos fueron desarrollados principalmente por ISI y Kestrel sobre la base de entornos de máquinas Lisp y Lisp . El entorno Kestrel se convirtió finalmente en un producto comercial llamado Refine, que fue desarrollado y mantenido 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 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 Y2K, la ingeniería inversa se convirtió en 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 de KBSA y las comunidades de lenguaje Frame y 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 Andersen Consulting Concept Demo, 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 en lo que respecta a la forma de resolver problemas y trabajar con los usuarios. En el enfoque tradicional de los sistemas expertos, el usuario responde a una serie de preguntas interactivas y el sistema proporciona una solución. El enfoque de KBSA dejaba al usuario en control. Mientras que un sistema experto intentaba, en cierta medida, reemplazar y eliminar la necesidad del experto, el enfoque del asistente inteligente en KBSA buscaba reinventar el proceso con tecnología. Esto condujo a una serie de innovaciones a nivel de la 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 de KBSA utilizaban una interfaz de usuario modelo-vista-controlador (MVC). Esta era una idea incorporada de los entornos Smalltalk. [9] La arquitectura MVC era especialmente adecuada para la interfaz de usuario de KBSA. Los entornos de KBSA presentaban múltiples vistas heterogéneas de la base de conocimientos. Podría ser ú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 metamodelo de los lenguajes de especificación e implementación. Cuando un analista realizaba algún cambio a través de un diagrama particular (por ejemplo, añadía una clase a la jerarquía de clases), ese cambio se realizaba en el nivel del modelo subyacente y las diversas vistas del modelo se actualizaban automáticamente. [10]
Una de las ventajas de utilizar una transformación era que se podían modificar a la vez muchos aspectos de la especificación y la implementación. En el caso de los prototipos a pequeña escala, los diagramas resultantes eran lo suficientemente simples como para que fuera suficiente combinar algoritmos de diseño básicos con la dependencia de los usuarios para limpiar los diagramas. 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 la teoría de grafos para actualizar automáticamente las distintas vistas asociadas con la base de conocimientos y generar grafos que tengan una intersección mínima de enlaces y que también tengan en cuenta las restricciones de diseño específicas del dominio y del usuario.
Otro concepto utilizado para proporcionar asistencia inteligente fue la generación automática de texto. Las primeras investigaciones en el 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, la generación de lenguaje natural se consideró viable 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 generar varios informes que describieran el sistema desde diferentes puntos de vista. Los investigadores del 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 de la fuerza aérea. [11]
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 de conceptos de KBSA.