Pregunta

Tengo una lista bastante decente de las ventajas de utilizar un motor de reglas, así como algunas de las razones para utilizarlos, lo que necesito es una lista de las razones por las que no debe usar un motor de reglas

Lo mejor que tengo hasta ahora es la siguiente:

  

Los motores de reglas no están realmente preparadas para soportar el flujo de trabajo o proceso   ejecuciones ni son motores de flujo de trabajo o herramientas de gestión de procesos   diseñado para hacer reglas.

Las demás grandes razones por las que no debe usarlos?

¿Fue útil?

Solución

Me pongo muy nerviosa cuando veo personas que utilizan conjuntos de reglas muy grandes (por ejemplo, del orden de miles de reglas en un solo conjunto de reglas). Esto sucede a menudo cuando el motor de reglas es un producto único que se sienta en el centro de la empresa con la esperanza de que el mantenimiento de normas secas tendrán que sean accesibles a muchas de las aplicaciones que lo requieran. Yo desafío a cualquiera a decirme que un motor de reglas Rete con que muchas normas se entiende bien. No estoy al tanto de cualquier herramienta que puede seguir para asegurarse de que no existen conflictos.

Creo que la partición de reglas establece para mantenerlos pequeños es una mejor opción. Aspectos pueden ser una manera de compartir una regla común establecido entre muchos objetos.

Yo prefiero un enfoque más simple, más datos conducidos siempre que sea posible.

Otros consejos

daré 2 ejemplos de la experiencia personal en el uso de un motor de reglas fue una mala idea, tal vez eso le ayudará a: -

  1. En un proyecto pasado, me di cuenta de que los archivos de reglas (el proyecto utilizó Drools) contenían una gran cantidad de código Java, incluidos los bucles, funciones, etc. Ellos eran esencialmente los archivos java se hacen pasar por archivo de reglas. Cuando le pregunté al arquitecto en su razonamiento para el diseño me dijeron que las "reglas no estaban destinados a ser mantenida por los usuarios de negocios".

lección . Se les llama "reglas de negocio" por una razón, no use reglas cuando no se puede diseñar un sistema que se puede mantener fácilmente / entendido por los usuarios del negocio

  1. Otro caso; El proyecto utiliza reglas porque los requisitos estaban mal definidos / entendidas y cambian a menudo. La solución del equipo de desarrollo era utilizar normas ampliamente para evitar despliega código frecuentes.

lección : Requisitos tienden a cambiar mucho durante los cambios iniciales de liberación y no justifican el uso de reglas. Utilizar las reglas cuando su negocio cambia a menudo (no requisitos). Por ejemplo: - Un software que hace sus impuestos va a cambiar todos los años como las leyes fiscales cambian y el uso de reglas es una excelente idea. Versión 1.0 de una aplicación web va a cambiar a menudo como los usuarios a identificar nuevos requisitos, pero se van a estabilizar en el tiempo. No utilice las reglas como una alternativa para desplegar código.

Soy un gran fan de los motores de reglas de negocio, ya que puede ayudarle a hacer su vida mucho más fácil como programador. Una de las primeras experiencias que he tenido mientras se trabaja en un proyecto de almacenamiento de datos fue encontrar procedimientos almacenados que contienen estructuras complicado caso de una extensión de páginas enteras. Fue una pesadilla de depurar, ya que era muy difícil de entender la lógica aplicada en tales estructuras largo caso, y para determinar si usted tiene un solapamiento entre una regla en la página 1 del código y otro de la página 5. En general, tuvimos más de 300 tales reglas incrustados en el código.

Cuando hemos recibido un nuevo requisito de desarrollo, por algo que se llama contabilidad de destino, que fue involucrando el tratamiento de más de 3000 normas, sabía que algo tenía que cambiar. En aquel entonces yo he estado trabajando en un prototipo que más tarde se convierten en los padres de lo que ahora es un motor de reglas de negocio con clientes, capaz de manejar todos los operadores estándar SQL. Inicialmente hemos estado usando Excel como una herramienta de creación y, más tarde, hemos creado una aplicación ASP.net que permitirá a los usuarios de negocio para definir sus propias reglas de negocio, sin la necesidad de escribir código. Ahora el sistema funciona bien, con muy pocos errores, y contiene más de 7000 normas para el cálculo de este Contabilidad Destino. No creo que este escenario habría sido posible sólo por la codificación dura. Y los usuarios son bastante contento de que pueden definir sus propias reglas sin que se convierta en su cuello de botella.

Sin embargo, hay límites a este enfoque:

  • Es necesario tener los usuarios de negocios capaces que tienen una excelente comprensión del negocio de la compañía.
  • Hay una carga de trabajo importante en la búsqueda de todo el sistema (en nuestro caso un almacén de datos), con el fin de determinar todos modificable condiciones que tengan sentido para traducirse en reglas para ser manejados por un motor de reglas de negocios. También hemos tenido que tener buen cuidado de que éstos plantillas iniciales sean totalmente comprensible para los usuarios comerciales.
  • Es necesario tener una aplicación utilizada para las reglas de creación, en el cual algoritmos para la detección de las reglas de negocio se solapan se implementa. De lo contrario va a terminar con un gran lío, donde nadie entiende más los resultados que obtienen. Cuando se tiene un fallo en un componente genérico como una regla de visita de encargo del motor, que puede ser muy difícil de depurar y hacer participar a extensas pruebas para asegurarse de que las cosas que funcionaban antes también trabajan ahora.

Más detalles sobre este tema se pueden encontrar en un post que he escrito: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

En general, la mayor ventaja de utilizar un motor de reglas de negocios es que permite a los usuarios tomar el control sobre las definiciones de reglas de negocios y de autoría, sin la necesidad de ir al departamento de TI cada vez que necesitan para modificar algo. También el reduce la carga sobre los equipos de desarrollo de TI, que ahora puede centrarse en la construcción cosas con mayor valor agregado.

Saludos,

Nicolae

El Poit me he dado cuenta de que es "la espada de doble filo" es:

  

colocación de la lógica en manos de personal no técnico

He visto esta obra grande, cuando usted tiene uno o dos genios multidisciplinares en el lado no técnico, pero también he visto la falta de tecnicidad que conduce a la hinchazón, más errores y, en general, el desarrollo de 4x / mantenimiento costo.

Por lo tanto es necesario considerar su base de usuarios en serio.

pensé artículo de Alex Papadimoulis era bastante perspicaz: http://thedailywtf.com/articles/soft_coding.aspx

No es exhaustiva, pero tiene algunos puntos buenos.

gran artículo sobre cuándo no usar un motor de reglas ... (así como cuándo utilizar uno) ....

http://www.jessrules.com/guidelines.shtml

Otra opción es si usted tiene un conjunto lineal de reglas que sólo se aplican una vez en cualquier orden para obtener un resultado es la creación de una interfaz maravilloso y tienen los desarrolladores a escribir y desplegar estas nuevas reglas. La ventaja es que es perversamente rápido porque normalmente le pasaría la sesión de hibernación o sesión de JDBC, así como los parámetros para que tenga acceso a todos los datos de aplicaciones, pero de una manera eficiente. Con una lista de hecho, no puede haber un montón de bucle / juego que realmente puede ralentizar el sistema abajo ..... Es otra manera de evitar un motor de reglas y ser capaz de ser desplegado de forma dinámica (sí, nuestras reglas maravilloso se desplegaron en una base de datos y que no tenían recursividad .... tampoco cumple la regla o no lo tuvo). Es sólo otra opción ..... ah y un beneficio más es no aprender la sintaxis de reglas para los desarrolladores entrantes. Tienen que aprender algo maravilloso, pero que está muy cerca de java por lo que la curva de aprendizaje es mucho mejor.

En realidad depende de su contexto. Reglas del motor tienen su lugar y lo anterior es sólo otra opción si tiene reglas en un proyecto que es posible que desee desplegar de forma dinámica para situaciones muy simplificados que no requieren de un motor de reglas.

en el fondo no utilizar un motor de reglas si usted tiene un conjunto de reglas simples y pueden tener una interfaz maravilloso lugar ..... al igual que los desarrolladores desplegables dinámicamente y nuevas se unen a tu equipo pueden aprender más rápido que el lenguaje babea. (Pero eso es mi opinión)

En mi experiencia, los motores de reglas funcionan mejor cuando se cumple lo siguiente:

  1. doctrina bien definida para su dominio del problema
  2. de alta calidad (preferiblemente automatizado) de datos para ayudar a impulsar la mayor parte de sus entradas
  3. El acceso a expertos en la materia
  4. Los desarrolladores de software con sistemas de creación de la experiencia de expertos

Si cualquiera de estos cuatro rasgos se echa en falta, todavía se puede encontrar un motor de reglas que funciona para usted, pero cada vez que lo he probado con hasta 1 falta, me he encontrado con problemas.

Eso es ciertamente un buen comienzo. La otra cosa con motores de reglas es que algunas cosas son bien entendida, determinista, y directo. retención de nómina es (o uso de ser) así. Usted podría expresarla como reglas que ser resueltas por un motor de reglas, pero se podía expresar las mismas reglas que una mesa bastante sencilla de valores.

Por lo tanto, los motores de flujo de trabajo son buenas cuando se está expresando un proceso a largo plazo que tendrán los datos persistentes. motores de reglas pueden hacer una cosa similar, pero hay que hacer un montón de complejidad añadida.

Los motores de reglas son buenas cuando se han complicado las bases de conocimiento y la necesidad de buscar. motores de reglas pueden resolver problemas complicados, y pueden adaptarse rápidamente a las cambiantes situaciones, sino que imponen una gran complejidad en la implementación base.

Muchos algoritmos de decisión son lo suficientemente simple para expresar como un simple programa basada en tablas sin la complejidad que implica un motor de reglas real.

Yo recomendaría fuertemente motores de reglas de negocio como Drools como código abierto o Normas Comerciales motor como LiveRules

  • Cuando se tiene una gran cantidad de políticas de negocio que son volátiles por naturaleza, es muy difícil mantener esa parte del código de la tecnología de núcleo.
  • El motor de reglas proporciona una gran flexibilidad del marco y fácil de cambiar y desplegar.
  • motores de reglas no son para ser utilizados por todas partes pero tienen que utilizar cuando se presente gran cantidad de políticas donde los cambios son inevitables en una base regular.

Realmente no entiendo algunos puntos tales como:
a) la gente de negocios necesita para entender el negocio muy bien, o;
b) el desacuerdo sobre la gente de negocios no es necesario conocer la regla.

Para mí, como un pueblo simplemente tocando BRE, el beneficio de BRE se llama así a dejar que el sistema se adapta a los cambios del negocio, por lo tanto, se centró en la adaptación del cambio.
Qué importa si el conjunto de reglas a la hora del x es diferente de la regla establecido en el momento y debido a:
a) la gente de negocios no entienden de negocios, o;
b) la gente de negocios no entienden las reglas?

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top