Diseño de Arquitectura de Software: Componentes, Pasos y Prototipado

TERCER PASO: Especificación de los Componentes de la Arquitectura

El Controlador

El controlador hace posible la implementación de un control dirigido por eventos en un único subsistema. Se puede considerar que el controlador es la implementación del modelo de comunicación. En el diseño de este elemento hay que tomar las siguientes decisiones:

  1. La forma de las interfaces para los gestores de eventos, tanto para los eventos externos como para los internos.
  2. Si se va a permitir un control de tipo demonio.
  3. ¿Vamos a permitir interrupciones?
  4. ¿Es necesaria la ejecución concurrente de funciones?

La complejidad del modelo de comunicación es la que va a indicar si se requiere una funcionalidad compleja. Normalmente se requiere que estén implementados los siguientes gestores de eventos:

  • Gestores de eventos para la activación de las funciones del modelo de la aplicación a petición de agentes externos.
  • Gestores de eventos que implementan la función de transferencia Receive.
  • Gestores de eventos para atender a los eventos internos, sobre todo para los eventos generados por la función de transferencia obtain.
  • Esta función de transferencia también requerirá la implementación de un mecanismo de suspensión/reanudación en las funciones del modelo de aplicación.
  • Gestores de eventos para proporcionar información sobre el propio proceso de razonamiento.
  • Gestores de eventos para abortar la ejecución de las funciones.

El controlador puede definir sus propias vistas de sus objetos para, de esta forma, mostrar información referente al propio razonamiento.

Modelo de la Aplicación: Las Tareas

Cada objeto tarea necesita implementar dos operaciones. Una de ellas es inicializar, que se encarga de establecer los valores de las entradas de las tareas, y la otra es ejecutar, para invocar al método de tarea correspondiente. Para esta última operación, tenemos que decidir si se va a devolver un valor booleano.

Los Métodos de las Tareas

A la hora de abordar el diseño de los métodos de las tareas hay que tomar dos decisiones.

  1. Hay que decidir sobre el lenguaje que vamos a utilizar para especificar la estructura de control de una tarea. En el modelo de conocimiento, el control de una tarea se suele especificar en forma imperativa. Para poder implementarla, debemos especificar el conjunto de construcciones que nos van a permitir implementar dicha estructura de control.
  2. La segunda decisión que debemos tomar respecto a las tareas se refiere al lugar en el que vamos a definir la estructura de control. Si seguimos con un diseño orientado a objetos, lo más lógico sería colocar la implementación de la estructura de control dentro de un método ejecutar, pero esta opción va en contra de la naturaleza declarativa del conocimiento.

Las Inferencias

El diseño de una inferencia está basado en la información contenida en el modelo de conocimiento. Desde el punto de vista del diseño, tenemos que asumir que cada inferencia debe tener una memoria interna en la que se almacenan las soluciones encontradas. Esta memoria se debe inicializar cada vez que la tarea en la que la inferencia está definida, finaliza. Las decisiones de diseño que debemos tomar respecto a las inferencias están relacionadas con la definición de las operaciones que hacen posible la ejecución de la inferencia.

Los Métodos de las Inferencias

Cuando especificamos una inferencia en el modelo de conocimiento solo definimos qué es lo que hace y no indicamos cómo lo hace. La descripción del método de la inferencia, que especifica cómo una inferencia desarrolla su trabajo, es el típico elemento que se tiene que añadir durante el diseño. En el análisis, el ingeniero del conocimiento ve las inferencias desde un punto de vista de deducción automática.

Roles Dinámicos

Cuando abordamos el diseño de los roles dinámicos, debemos responder a estas dos preguntas:

  • ¿Qué tipos de datos se van a usar para encapsular los roles dinámicos? Podemos decidir utilizar tipos de datos como conjuntos, bolsas, listas, o elementos simples.
  • ¿Qué funciones de acceso y modificación se van a implementar? Si el modelo de conocimiento está especificado en CML y tenemos un rol dinámico implementado como un conjunto, necesitaremos las siguientes operaciones: select, add, subtract, y empty.

Roles Estáticos

Los roles estáticos contienen las expresiones que se pueden definir en el dominio como instancias de relaciones y conceptos, además de los tipos de reglas que permiten los procesos de razonamiento de las inferencias y constituyen las bases de conocimiento. Normalmente se utilizan las funciones de acceso que proporcionan los sistemas de almacenamiento utilizados para mantener las instancias que constituyen los distintos roles estáticos.

Bases de Conocimiento

Las bases de conocimiento contienen las instancias de los tipos de reglas que definen distintas parcelas del conocimiento del dominio y que permiten a las inferencias derivar nuevo conocimiento. En el diseño de las bases de conocimiento hay que tener en cuenta los siguientes aspectos:

  1. Hay que decidir sobre la forma de representar las instancias de los tipos de reglas.
  2. Determinar qué funciones de acceso, si se requieren, se diseñarán. En caso de que se necesiten, serán de la misma naturaleza que la de los roles estáticos.
  3. En algunos casos puede ser necesario definir funciones de modificación y análisis de las bases de conocimiento. Estas funciones estarán relacionadas con la edición, actualización, depuración y refinamiento.

Construcción del Dominio

Bajo la denominación de construcción del dominio incluimos todos aquellos elementos definidos en el modelo de conocimiento que no han sido tratados en el resto de los apartados, como son las definiciones de conceptos, relaciones y tipos de reglas. Este tipo de construcciones solo se incluyen en el modelo de diseño a efectos de documentación.

Vistas

Las vistas nos permiten mostrar el contenido de los procesos de razonamiento que se están ejecutando a agentes externos. En el diseño de la arquitectura deberemos tener en cuenta los siguientes aspectos:

  1. El número de tipos de vistas que vamos a utilizar, tales como las ventanas, menús, etc.
  2. Elementos que permitan asociar un objeto del modelo de la aplicación a una o más vistas, garantizando la integridad de las vistas.
  3. En la mayoría de los casos, quedan determinados por los métodos predefinidos por entornos de implementación.

Normalmente deberemos abordar el diseño de dos tipos de interfaces. Una de estas será la interfaz para usuarios finales. Los usuarios finales no son los expertos del dominio implicados en el desarrollo del SBC. El objetivo de esta interfaz de usuario es que el conocimiento experto esté disponible para los no expertos. El otro tipo de interfaz se refiere a las diseñadas para los expertos. En este caso se necesitarán funciones adicionales en la interfaz para que los expertos puedan interactuar con el sistema.

CUARTO PASO: Especificación de la Aplicación sobre la Arquitectura

Este proceso se realiza en dos pasos, consistentes en lo siguiente:

  1. Proyectar la información obtenida en el análisis sobre la arquitectura especificada en el tercer paso. Es recomendable, para evitar la introducción de errores, que este proceso se realice de forma automática.
  2. Añadir los detalles necesarios para el diseño de la aplicación.

Controlador

El diseñador deberá realizar algún trabajo adicional para poder transformar el modelo de comunicación en una especificación de controlador.

Modelo de Tarea

Debemos formalizar la estructura de control con el lenguaje de control proporcionado por la herramienta seleccionada.

Inferencia

Tenemos que especificar la forma de invocar al método de la inferencia. En la invocación del método debe quedar claro cómo los roles se asocian con los argumentos del método de la inferencia.

Método de la Inferencia

Para cada inferencia debemos especificar o seleccionar el método correspondiente.

Roles Dinámicos

Hay que seleccionar un tipo de datos para cada rol. Esta elección está condicionada por el conjunto de tipos de datos proporcionados por la arquitectura o la herramienta seleccionada.

Vistas

La elección del tipo de vistas que vamos a utilizar está dirigida por los principios generales de interfaces de usuario, ampliamente recogidos en la bibliografía específica de la IS.

Diseño de Prototipos

En la mayoría de los casos, el término prototipado rápido tiene connotaciones negativas, ya que se asocia a implementaciones poco fiables que nunca llegan a evolucionar. Las tendencias actuales en gestión de proyectos consideran que prototipado rápido es una técnica bien articulada, que se puede utilizar para aquellas partes del sistema cuyos requisitos no están bien especificados y que pueden ser fuente de riesgos importantes. Además, el prototipado rápido se adapta perfectamente a la naturaleza evolutiva de los SBC.

Prototipo del Proceso de Razonamiento

A la hora del desarrollo de un SBC, existen dos situaciones en las que es recomendable el desarrollo de un prototipo del proceso de razonamiento. La primera de estas situaciones es cuando el modelo de conocimiento no está basado en algunas de las tareas de librería y, por tanto, hay que desarrollarla desde cero. La segunda situación se da cuando el conocimiento del dominio no está completo y no tengamos claro qué partes están incompletas.

Prototipo de la Interfaz de Usuario

A menudo resulta muy útil construir, en las primeras etapas de un proyecto, un prototipo de la interfaz de usuario, en la que se incluyan vistas tanto de los objetos del controlador como del modelo de la aplicación. Concretamente, si la representación de la información que requieren las vistas es compleja, el prototipo de la interfaz será muy útil a la hora de concretarlas.

Arquitecturas Distribuidas

Actualmente, existe una fuerte tendencia a desarrollar sistemas basados en arquitecturas distribuidas, en las que los distintos subsistemas o módulos de la arquitectura se ejecutan en ubicaciones físicas diferentes.