Asistente de software basado en el conocimiento

Las reglas de transformación que utilizaba KBSA eran diferentes de las reglas tradicionales para sistemas expertos. Estas reglas se comparaban con los lenguajes de especificación e implementación, en lugar de con los hechos del mundo. Era posible especificar transformaciones mediante patrones, comodines y recursión tanto en el lado derecho como en el izquierdo de una regla. La expresión del lado izquierdo especificaba los patrones de la base de conocimiento existente que se debían buscar. La expresión del lado derecho podía especificar un nuevo patrón para transformar el del lado izquierdo. Por ejemplo, transformar un tipo de datos de teoría 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 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, 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 diversas capacidades de una clase existente que se pueden compartir de forma más general. Las transformaciones evolutivas se desarrollaron aproximadamente al mismo tiempo que el surgimiento de la comunidad de patrones de software, y ambos 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 orientados 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 denominó un lenguaje de amplio espectro. El requisito era un marco de representación del conocimiento que pudiera dar soporte a todo el ciclo de vida : requisitos, especificaciones y código, así como al propio proceso de desarrollo de software. La representación central de la base de conocimiento debía utilizar el mismo marco, aunque se podían añadir diversas capas para dar soporte a presentaciones e implementaciones específicas.

Estos primeros marcos de conocimiento fueron desarrollados principalmente por ISI y Kestrel, basándose en Lisp y entornos de máquina Lisp . El entorno Kestrel se convirtió finalmente en un producto comercial llamado Refine, desarrollado y respaldado por Reasoning Systems Incorporated, una empresa derivada de Kestrel.

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 mantenible. Con la creciente preocupación por el problema del año 2000, la ingeniería inversa se convirtió en una preocupación empresarial 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 de lenguajes Frame y programación orientada a objetos . Las primeras bases de conocimiento de KBSA se implementaron en lenguajes orientados a objetos, en lugar de lenguajes orientados a objetos . Los objetos se representaban como clases y subclases, pero no era posible definir métodos sobre ellos. En versiones posteriores de KBSA, como la demostración conceptual de Andersen Consulting, el lenguaje de especificación se amplió para admitir también el paso de mensajes.

KBSA adoptó un enfoque distinto al de los sistemas expertos tradicionales en cuanto a la resolución de problemas y la interacción con los usuarios. En los sistemas expertos tradicionales, el usuario responde a una serie de preguntas interactivas y el sistema proporciona una solución. El enfoque de KBSA, en cambio, dejaba el control en manos del usuario. Mientras que un sistema experto intentaba, en cierta medida, reemplazar y eliminar la necesidad del experto, el enfoque de asistente inteligente de KBSA buscaba reinventar el proceso mediante la tecnología. Esto dio lugar a diversas innovaciones en 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 KBSA empleaban una interfaz de usuario modelo-vista-controlador (MVC). Esta idea se incorporó de los entornos Smalltalk. ^{[ 9 ]} La arquitectura MVC se adaptaba especialmente bien a la interfaz de usuario de KBSA. Los entornos KBSA presentaban múltiples vistas heterogéneas de la base de conocimiento. Podía ser útil observar un modelo emergente desde el punto de vista de las entidades y relaciones, las interacciones de objetos, las jerarquías de clases, el flujo de datos y muchas otras vistas posibles. La arquitectura MVC facilitaba esto. Con la arquitectura MVC, el modelo subyacente siempre era la base de conocimiento, que era una descripción del metamodelo de los lenguajes de especificación e implementación. Cuando un analista realizaba algún cambio a través de un diagrama en particular (por ejemplo, agregaba una clase a la jerarquía de clases), ese cambio se realizaba a nivel del modelo subyacente y las diversas vistas del modelo se actualizaban automáticamente. ^{[ 10 ]}

Una de las ventajas de usar una transformación era que muchos aspectos de la especificación e implementación podían modificarse simultáneamente. Para prototipos a pequeña escala, los diagramas resultantes eran lo suficientemente simples como para que los algoritmos básicos de diseño, combinados con la colaboración de los usuarios para su limpieza, 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 compleja. Investigadores de Andersen Consulting incorporaron trabajos de la Universidad de Illinois sobre teoría de grafos para actualizar automáticamente las distintas vistas asociadas a la base de conocimiento y generar grafos con una mínima intersección de enlaces, teniendo en cuenta además las restricciones de diseño específicas del dominio y del usuario.

Otro concepto utilizado para brindar asistencia inteligente fue la generación automática de texto. Las primeras investigaciones en ISI estudiaron 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ó que la generación de lenguaje natural era factible como una forma de generar descripciones textuales que pudieran ser leídas por gerentes y personal no técnico. Esto resultó especialmente atractivo para la fuerza aérea, ya que, por ley, exigían a todos los contratistas que generaran diversos informes que describieran el sistema desde diferentes puntos de vista. Investigadores de ISI y, posteriormente, 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 ]}