Capítulo 5. El modelo de hechos (el modelo de objetos)


Se necesita un modelo de hechos para dirigir las reglas de una aplicación basada en reglas. El modelo de hechos usualmente coincide con el modelo de dominio de la aplicación pero en general se debe separar de este. Esto hace más fácil el administrar las reglas con el pasar del tiempo.
Hay dos maneras de definir un modelo de hechos:
  • Cargue un archivo JAR que contenga las clases Java que la aplicación y las reglas utilicen.
  • Declare un modelo dentro de BRMS que se pueda exportar como una KnowledgeBase y se utilice dentro de su código Java.

5.1. El área global

Cuando se crean modelos de hechos se pueden importar en el paquete específico con el que se utilizarán o se pueden importar en el Global Area. Es importante observar que los activos que se encuentran en el Global Area no están disponibles globalmente se tienen que importar en los paquetes que los utilizarán. El Global Area se debe utilizar como un lugar de almacenamiento para los activos que todavía no se están utilizando o como punto central para los activos utilizados en múltiples paquetes.

Nota

Tenga cuidado al modificar los activos que se encuentren en ambos paquetes y en el Global Area. Será necesario importar de nuevo los activos modificados en el Global Area en los paquetes que los utilizan y borrar los activos importados anteriormente.

5.2. Modelo JAR

Procedimiento 5.1. Creación de un modelo Jar

  1. Abra el menú New model archive (jar)

    Del menú Knowledge Bases seleccione Create New y luego seleccione Upload POJO Model JAR.
  2. Creación de un activo modelo Jar

    Introduzca el nombre del modelo Jar, la categoría y una descripción. Seleccione en que paquete crear el modelo o especifique que se debe agregar al Global Area. Haga clic en OK cuando todos los detalles se han introducido.
  3. Cargue la JAR en el activo

    Cargue la JAR que contiene el modelo definido como paquetes y clases Java y en un archivo Java JAR normal.

5.3. Modelo declarativo

El utilizar un modelo declarativo tiene los siguientes beneficios:
  • Refuerza que el modelo pertenece a la base de conocimiento, note la aplicación.
  • El modelo puede tener un ciclo de vida separado de las aplicaciones.
  • Los tipos Java se pueden enriquecer con anotaciones especificas de reglas.
  • Los archivos JAR se deben mantener sincronizados entre las reglas y las aplicaciones que las utilizan, sin embargo, no es necesario mantener sincronizado un modelo declarativo.
Los modelos declarativos pueden ser:
  • Una definición autónoma de todo el modelo de hechos que se utiliza dentro de sus reglas.
  • Una definición de hechos complementaria para soportar un modelo Java POJO.

Procedimiento 5.2. Creación de un modelo declarativo

  1. Abra el menú New Declarative Model

    Del menú Knowledge Bases seleccione Create New y luego seleccione New Declarative Model.
  2. Creación de un nuevo modelo declarativo

    Introduzca un nombre para el nuevo modelo. Seleccione el paquete en donde crear el modelo o especifique que se debe agregar al Global Area. Haga clic en OK cuando se hayan introducido todos los detalles.
  3. Defina el modelo

    Haga clic en Add new fact type e introduzca el nombre del hecho en el campo name del menú emergente.
  4. Agregar campos de hechos

    Cree campos de hechos seleccionando el botón Add field e introduciendo la información en el menú emergente.
  5. Agregar anotaciones

    Cree anotaciones de hechos seleccionando el botón Add annotation. Los campos Name y Value de las anotaciones son obligatorios pero el campo Key es opcional. Si no se especifica un valor Key entonces se asigna un valor predeterminado value.

5.3.1. Consumo de un modelo declarativo de Java

Los tipos declarados se generan en el momento de la compilación de la base de conocimiento y como tal la aplicación sólo tendrá acceso a estos en tiempo de ejecución de la aplicación. Por lo tanto, estas clases no están disponibles para referencia directa de la aplicación.
Los tipos declarativos se pueden usar como objetos de hechos normales pero la manera de crearlos es diferente (ya que no se encuentran en la ruta de clase de las aplicaciones). Para crear estos objetos están disponibles de la instancia KnowledgeBase.

Ejemplo 5.1. Manejo de tipos de hechos declarados por medio de la API

// obtienen una referencia a una base de conocimiento con un tipo declarado:
KnowledgeBase kbase = ...

// obtiene el FactType declarado
FactType personType = kbase.getFactType( "org.drools.examples",
                                         "Person" );

// maneja el tipo como sea necesario:
// create instances:
Object bob = personType.newInstance();

// establece los valores de los atributoss
personType.set( bob,
                "name",
                "Bob" );
personType.set( bob,
                "age",
                42 );

// introduce el hecho en una session
StatefulKnowledgeSession ksession = ...
ksession.insert( bob );
ksession.fireAllRules();

// lee los atributos
String name = personType.get( bob, "name" );
int age = personType.get( bob, "age" );
Copy to Clipboard Toggle word wrap

Nota

El espacio de nombre del tipo declarado es el espacio de nombre del paquete en donde se declaró (es decir org.drools.examples en el ejemplo anterior).
Volver arriba
Red Hat logoGithubredditYoutubeTwitter

Aprender

Pruebe, compre y venda

Comunidades

Acerca de la documentación de Red Hat

Ayudamos a los usuarios de Red Hat a innovar y alcanzar sus objetivos con nuestros productos y servicios con contenido en el que pueden confiar. Explore nuestras recientes actualizaciones.

Hacer que el código abierto sea más inclusivo

Red Hat se compromete a reemplazar el lenguaje problemático en nuestro código, documentación y propiedades web. Para más detalles, consulte el Blog de Red Hat.

Acerca de Red Hat

Ofrecemos soluciones reforzadas que facilitan a las empresas trabajar en plataformas y entornos, desde el centro de datos central hasta el perímetro de la red.

Theme

© 2025 Red Hat