• No se han encontrado resultados

Capítulo II Estado de la Cuestión 

II. 2.2 ¿Qué es un SGRN? 

II.2.2.2. Características de un SGRN 

Existe  una  gran  variedad  de  productos,  tanto  comerciales  como  de  código  abierto,  que  implementan SGRN. Entre ellos cabría destacar ILOG JRules (ILOG,2006), JBoss Rules (Proctor  et  al.,2007)  y  Blaze  Advisor  (FairIsaac,2007).  Todos  estos  motores  de  reglas  comparten  un  conjunto de características, como son: 

 

Figura II- 4. Fases en el proceso de operación de un motor de reglas

• Implementan  un  algoritmo  de  ejecución  de  reglas  eficiente.  Como  se  indicaba  anteriormente,  la  mayoría  de  los  motores  de  reglas  actuales  incluyen  una  implementación  del  algoritmo  RETE,  el  más  eficiente  conocido  actualmente  para  la  verificación de antecedentes y consecuentes de las reglas de negocio. A este respecto  existen  múltiples  estudios,  como  (Owen,2006)(Nogueras,2008),  en  los  que  se  han  efectuado  comparaciones  entre  diversos  motores,  en  cuanto  a  eficiencia  se  refiere  y  que  permiten  concluir  que  la  eficiencia  de  ejecución  no  marca  la  diferencia  para  seleccionar un SGRN. 

• Incorporan  gestión  de  la  configuración.  Un  factor  importante  a  tener  en  cuenta  a  la  hora de trabajar con reglas de negocio es la necesidad de disponer de información de  versiones  existentes  de  una  misma  regla,  además  de  conocer  los  usuarios  que  modificaron  las  distintas  versiones  y  que  elaboraron  aquellas  que,  en  un  instante  determinado,  se  encuentran  en  un  entorno  de  producción.  Todos  los  SGRN  comerciales incorporan esta característica. 

• Distinguen roles de usuarios. La principal ventaja de los SGRN radica en la posibilidad  de modificar la lógica de negocio sin necesidad de recompilar y reconstruir el código  de la aplicación que da soporte a dicha lógica de negocio. Esto conduce a la posibilidad  de  que  los  analistas  de  negocio  o  expertos  en  el  dominio  puedan,  sin  conocimientos  técnicos  profundos,  modificar  el  comportamiento  de  una  aplicación  por  sí  mismos.  Esto  supone  que  todos  los  SGRN  disponibles  distinguen  al  menos  dos  roles  de            Reglas de  Negocio  Memoria de  Trabajo  (Agenda)  Evaluación 

Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio

   

usuarios:  los  desarrolladores,  conocedores  de  la  tecnología,  aunque  desconocedores  del negocio, capaces de implementar reglas de negocio a bajo nivel, y los expertos o  analistas  de  negocio,  que  disponen  de  una  herramienta  específica  que  trata  de  aislarles de los aspectos tecnológicos de las reglas de negocio.  

• Incluyen herramientas de despliegue. Aparte de permitir la creación y definición de las  reglas negocio, es deseable disponer de facilidades para el despliegue de las reglas de  negocio.  Este  componente  de  despliegue  estaría  encargado  de  situar  los  artefactos  que conforman una regla de negocio (ficheros con definición de las reglas, ficheros con  código objeto, etc.) en el entorno de ejecución adecuado. También estaría al tanto de  las  dependencias  existentes  entre  el  motor  de  reglas  y  el  resto  de  componentes  software disponibles en la organización, asegurando que se encuentra en ejecución la  versión adecuada para la regla y manteniendo registro del proceso de ejecución.  • Incluyen herramientas de validación. Como parte del entorno de edición de las reglas 

de negocio, la mayoría de los sistemas incluyen la posibilidad de depurar y validar la  ejecución  de  las  reglas  de  negocio  creadas.  Estas  facilidades  de  depuración  suelen  integrarse en los entornos de edición para los desarrolladores de las reglas de negocio.  Disponer  de  estas  facilidades  para  los  analistas  de  negocio  es  algo  raramente  contemplado en las herramientas. 

• Interfaz  de  usuario  en  lenguaje  natural.  Es  raro  que  los  SGRN  actuales  tengan  en  cuenta  la  posibilidad  de  definir  reglas  de  negocio  en  lenguaje  natural.  Sólo  el  SGRN  Haley  Expert  Rules5  (Haley,2007)  considera  esta  característica  como  clave  para  su  producto.  El  resto  de  SGRN  suele  incorporar  un  lenguaje  intermedio  que  permite  asignar  algunos  sobrenombres  a  los  elementos  de  las  reglas  de  negocio.  Los  mencionados  lenguajes  suelen  denominarse  Lenguajes  Específicos  del  Dominio  (Domain  Specific  Language,  DSL)  y  facilitan  la  expresión  de  las  reglas  de  negocio  en  lenguajes  próximos  al  natural.  Normalmente,  estas  funcionalidades  se  diseñan  tomando el inglés como idioma para la expresión de las reglas. 

• Integración con el proceso de desarrollo. La mayoría de los SGRN suelen incorporar una  interfaz basada en un navegador para los expertos de negocio y otra interfaz propia de  desarrolladores integrada en algún entorno de desarrollo como puede ser Eclipse6 en  el  caso  de  considerar  Java  como  lenguaje  de  programación.  Por  otra  parte,  el  desarrollo de reglas de negocio debe apoyarse en los modelos de objetos existentes en  la  organización,  los  cuales,  por  norma  general,  deben  importarse  en  el  entorno  de  desarrollo de reglas de negocio. Esta importación se efectúa normalmente a nivel de  implementación, es decir, a partir, por ejemplo, de las clases Java que se emplearán en  el  desarrollo  de  una  aplicación  determinada.  Esto  obliga  a  mantener  modelos  de  objetos  separados  para  las  aplicaciones  que  se  apoyan  en  SGRN  para  su  implementación. 

      

5 Haley Systems Inc. ha sido recientemente adquirida por Oracle 6www.eclipse.org

Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio

   

Atendiendo  a  estas  características,  la  Tabla  II‐  3  muestra  una  categorización  para  los  tres  productos mencionados al principio de este apartado. Como puede verse, todos esos sistemas  son muy similares entre sí. 

Existen  muchos  otros  productos  en  el  mercado  de  los  SGRN  y  que  interesa  mencionar  (Rymer,2008): 

• PegaRules  es  una  compañía  estadounidense  que  comercializa  su  propio  SGRN,  utilizado  en  más  de  300  aplicaciones  en  producción.  La  compañía  tiene  más  de  200  clientes, de los que 54 han comprado o actualizado PegaRules en 2007. Los planes de  mejora  del  sistema  incluyen  facilitar  la  captura  directa  de  objetivos  de  negocio  mediante  metadatos,  una  nueva  plataforma  para  la  evaluación  automática  de  las  reglas  y  dar  soporte  a  la  toma  de  decisiones  basada  en  múltiples  variantes  y  circunstancias.  Característica /  Producto  ILOG JRules Blaze Advisor (Fair  Isaac)  JBoss Rules  Algoritmo de ejecución  de reglas 

RETE RETE RETE 

Gestión de la  Configuración  SI SI Externa (a partir de la  versión 4.0)  Roles de usuarios  SI SI SI  Despliegue  SI SI NO  Validación  SI SI SI  Interfaz en Lenguaje  Natural 

A través de DSL A través de DSL A través de DSL 

Integración en el  proceso de desarrollo  Costosa, adaptación  específica  Costosa, adaptación  específica  Costosa, adaptación  específica  Lenguaje para  definición de reglas  Propio, ILOG Rules  Language (IRL)  Propio Propio, Drools Rules  Language, (DRL) 

Tabla II- 3. Resumen de características principales de los SGRN

• Oracle ha adquirido recientemente la compañía Haley Systems Inc., desarrolladora de  HaleyAuthority,  un  SGRN  que  hace  hincapié  en  la  aplicación  de  técnicas  de  procesamiento  de  lenguaje  natural  para  la  identificación  y  expresión  de  reglas  de  negocio. 

• Corticon es otra de las compañías conocidas en el ámbito de la gestión de reglas de  negocio. Sus productos han sido instalados en más de 250 clientes, lo que ha supuesto  a  la  compañía  un  incremento  de  beneficios  de  más  de  un  50%  en  los  últimos  cuatro  años.  Los  planes  de  mejora  de  los  productos  de  Corticon  incluyen  la  inclusión  de  análisis  predictivo,  correlación  de  eventos  y  de  facilidades  para  la  optimización  de 

Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio

   

reglas,  así  como  la  integración  de  sus  herramientas  de  modelado  sobre  motores  de  reglas de terceros. 

• SAP  adquirió  en  2007  a  la  compañía  YASU  Technologies,  desarrolladora  del  SGRN  QuickRules, entrando también a formar parte de los competidores en esta área. Así, el  motor de reglas ha sido integrado en el entorno de composición NetWeaver, uno de  los productos de la compañía. 

• En el ámbito del mercado español es posible encontrar, aparte de a las anteriores, a la  empresa  Delta‐r7,  desarrolladora  de  onRules,  un  SGRN  especialmente  pensado  para  favorecer la cooperación entre las áreas de Tecnologías de la Información y de Negocio  de  las  organizaciones.  Este  producto  combina  las  reglas  de  producción  tradicionales  con componentes que incorporan métodos estadísticos y redes neuronales. 

En (Rymer,2008) se encuentra la evaluación hecha por esta compañía sobre el mercado de los  motores de reglas, incluyendo a los ya mencionados hasta un total de 13. El estudio se basa en  el  análisis  de  175  características,  no  sólo  tecnológicas  sino  también  de  mercado.  Además,  considera  cinco  vistas  diferentes  a  la  hora  evaluar:  plataformas  de  propósito  general,  plataformas  especializadas,  plataformas  para  desarrolladores  de  aplicaciones  en  Java,  plataformas  para  desarrolladores  en  .NET  y  plataformas  para  analistas  de  negocio  que  desarrollan y mantienen aplicaciones. Según este informe, los líderes del mercado en el primer  cuatrimestre  de  2008  serían:  ILOG,  Fair  Isaac,  Corticon  Technologies,  Pegasystems,  Haley  Limited (el estudio se llevó a cabo justo antes de la adquisición de esta compañía por parte de  Oracle)  e  Innovations  Software  Technology.  Es  interesante  mencionar  que  este  estudio  no  incluye ninguna de las plataformas de código libre existentes, como son JBoss Rules o Jess. 

II.2.2.3.

Carencias de los SGRN 

A la vista de las características genéricas mostradas en el apartado anterior, cabe destacar las  siguientes carencias observadas en los SGRN actuales: 

1. Deficiencias  en  estandarización.  Para  interactuar  con  un  SGRN  a  través  de  una  aplicación  es  necesario  determinar  dos  elementos  principales:  la  interfaz  de  programación  que  define  las  operaciones  posibles  a  efectuar  sobre  el  sistema  y  el  lenguaje de representación de reglas que es capaz de Interpretar. En el primer punto  se han realizado esfuerzos de estandarización y, para entornos de desarrollo basados  en el lenguaje de programación Java, existe una interfaz estándar, denominada JSR‐94  (Salma,2002)  respetada  por  todos  los  SGRN.  El  principal  inconveniente  de  este  estándar reside en la imposibilidad de contemplar flujos de reglas, es decir, no permite  considerar  reglas  formadas  por  la  combinación  de  conjuntos  de  reglas  de  negocio  (normalmente  denominados  por  el  término  inglés  ruleset)  en  un  flujo  de  control.  En  cuanto al lenguaje de representación de reglas de negocio, cada SGRN define su propio  lenguaje, sin que exista ningún estándar que permita representar reglas de negocio de  manera independiente del SGRN con el que se trabaja. Aunque empiezan a surgir los  primeros  intentos  de  estandarizar  este  lenguaje,  como  es  el  caso  del  Semantic  Web  Rule Language (SWRL) (Horrocks et al.,2003), del Semantic of Business Vocabulary and        

Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio

   

Rules  (SBVR)  (OMG,2008)  o  del  Rules  Interchange  Format  (RIF)  (Paschke  et  al.,2008),  ninguno  de  los  sistemas  disponibles  es  capaz  de  trabajar  con  estos  lenguajes.  La  imposibilidad  de  escribir  las  reglas  en  un  lenguaje  estándar  y  poder  luego  implementarlas  en  cualquier  SGRN  conlleva  una  fuerte  dependencia  respecto  a  este  SGRN.  

2. Costosa integración en el proceso de desarrollo. Uno de los primeros pasos a dar a la  hora de introducir un SGRN en un proceso de desarrollo consiste en la adaptación de  los  modelos  de  negocio  existentes.  En  las  situaciones  en  las  que  se  desee  emplear  reglas  de  negocio  es  necesario  determinar  qué  procesos  u  objetos  de  negocio  intervienen  y  adaptarlos  al  SGRN  con  el  que  se  esté  trabajando.  Este  hecho  produce  una  dependencia  del  SGRN  con  el  que  se  trabaja,  dificultando  en  gran  medida  la  migración entre diferentes SGRN en caso necesario.  

3. Dificultad  de  reutilización  de  reglas.  Algunos  de  los  SGRN  más  avanzados  ofrecen  alguna  facilidad  para  localizar  reglas  de  negocio  o  conjuntos  de  reglas  previamente  creados con las herramientas de edición proporcionadas en el SGRN. A pesar de esto,  no  es  fácil  reutilizar  las  reglas  ya  creadas  para  otros  proyectos,  sobre  todo  debido  a  que los cambios en los modelos de negocio empleados por las diferentes aplicaciones  suelen  ser  numerosos.  No  hay  que  olvidar  que  las  reglas  de  negocio  únicamente  permiten definir restricciones sobre elementos de negocio conocidos, que, en muchos  casos, sufren variaciones dependiendo de las aplicaciones concretas.  4. Escasas facilidades para la integración de expertos de negocio. Por último, una de las  características más importantes de los SGRN reside en la posibilidad de definir reglas  de negocio comprensibles para los expertos de negocio, quienes habitualmente tienen  escasos conocimientos técnicos. Para ello los entornos suelen ofrecer la posibilidad de  definir  un  DSL,  un  lenguaje  específico  del  dominio  que  permite  asignar  términos  o  expresiones a los elementos del modelo de negocio para poder construir expresiones  de  las  reglas  de  negocio  próximas  al  lenguaje  natural.  Estos  lenguajes  no  están  en  realidad ligados a ninguna especificación concreta, a ningún diccionario predefinido y  deben  construirse  para  cada  modelo  con  el  que  se  desee  trabajar.  De  esta  forma,  la  definición  de  estos  DSL  es  costosa  de  realizar  y,  en  muchas  ocasiones,  es  una  característica poco empleada y, sobre todo, poco publicitada y destacada en los SGRN  disponibles en el mercado, tanto comerciales como de código abierto.