Motor de reglas

que ´este realice. Es deseable poder definir listas “din´amicas” de clientes dadas ciertas condiciones, por ejemplo: la terminaci´on del n´umero de la c´edula del individuo.

Abstrayendo el problema de su contexto se pudo notar un patr´on de comporta- miento en cada uno de estos casos que este “sistema” debe soportar:

1. Recibir datos, y saber consultarlos en tiempo de ejecuci´on.

2. Tomar decisiones sobre los datos ingresados, generalmente estos toman la for- ma de un predicado.

3. Realizar una acci´on en caso de que la condici´on establecida en el punto anterior se cumpla.

Este patr´on de trabajo no es nuevo y ha sido documentado extensamente. Tra- duciendo las palabras de Martin Fowler:

“Un motor de reglas se basa en proveer un modelo computacional alter- nativo. En vez de utilizar un modelo imperativo, el cual consiste en una secuencia de comandos con condicionales e iteraciones, un motor de re- glas se base en un sistema de reglas de producci´on. Esto es un conjunto de reglas, cada una con una condici´on y una acci´on.”[42]

El equipo entonces se interioriz´o con el concepto de “motor de reglas” y busc´o referencias de proyectos ya existentes que pudieran ser utilizados con este prop´osito.

El equipo entonces evalu´o los siguientes productos:

json-rules-engine[43].

archetypes-rules[44].

js-rules-engine[45].

Uno de los aspectos que el equipo utiliz´o para guiarse en la decisi´on sobre si es recomendable utilizar una biblioteca de terceros, adem´as de que la licencia lo permita, es conocer que tan seguido es mantenida la misma y si es utilizada por otros usuarios de forma productiva.

En el ecosistema GitHub hay distintas m´etricas que pueden asistir a de alguna manera evaluar un proyecto:

Proyectos populares reciben estrellas(stars) de la comunidad. Por lo tanto, si un proyecto las recibe, se puede inferir que hay usuarios de la plataforma interesados en el mismo.

Figura 5.4: Estrellas en el repositorio del proyecto “jsonpath-plus”

El equipo considera que un proyecto activo y saludable deber´ıa tener en su his- torial tareas y/o defectos abiertos, teniendo en cuenta que la fecha de creaci´on de los mismos no exceda el a˜no sin respuesta. De la misma manera el equipo consider´o la cantidad de tareas cerradas como algo positivo tomando tambi´en en cuenta que hubieran sido cerradas en el a˜no en curso.

Proyectos que forman una comunidad, suelen tener varios contribuyentes y esto resulta en mayor actividad en las discusiones, reporte de bugs, pedido de funcionalidades y actualizaciones de dependencias que puedan tener vulnera- bilidades abiertas.

Con estas m´etricas se realiz´o un estudio de las alternativas y se encontr´o que la biblioteca archetypes-rules lleva tres a˜nos sin ser actualizada, y no parece ser muy popular. Similarmente,js-rules-engine lleva dos a˜nos sin ser actualizada al momento de escribir este documento y no cuenta con el concepto de una “acci´on”. Por su parte json-rules-engine tambi´en lleva a˜nos sin ser actualizada, pero tiene 2000stars y 397 forks. ´Esto ´ultimo, puede significar que la comunidad haya mostrado inter´es en el proyecto pero este haya sido abandonado.

Figura 5.5:Issues en el repositorio del proyecto “jsonpath-plus”

Lamentablemente, ´esta ´ultima, si bien parece cumplir con varios de los requeri- mientos del equipo est´a escrita en JavaScript, lo que el equipo cree, dificultar´ıa el desarrollo en caso de necesitar ser modificada.

Debido a lo anterior y que se identific´o a este componente de software como primoridal para el desarrollo de las funcionalidades venideras, se decidi´o escribir un motor de reglasm´ınimo, tomando conceptos e ideas de estas tres implementaciones sumadas a las necesidades particulares del proyecto.

Por esto es que el equipo comenz´o el desarrollo de un motor de reglas propio. En el anexo A.4 Motor de Reglas se describe con mayor detalle t´ecnico las definiciones

Figura 5.6: Contribuyentes al repositorio del proyecto “jsonpath-plus”

realizadas sobre el motor. De la investigaci´on realizada, la bibliotecaarchetype-rules inspir´o los conceptos de contextos, variables y operadores, mientras que json-rules- engine la sintaxis de las reglas en formato JSON.

Es importante recalcar que el motor de reglas es un paquete separado de la soluci´on en general y no es un componente en tiempo de ejecuci´on. Por el momento su funcionalidad se ofrece como una biblioteca, que deber´a ser consumida por el componente interesado.

5.2.1.1 Resultado

La complejidad t´ecnica de realizar un motor de reglas gen´erico (es decir, no atado a ninguno de los dominios) no fue bien dimensionada por parte del equipo. Aunque el componente finalizado fue exitoso, este desarrollo se extendi´o bastante m´as en el tiempo de lo que el equipo anticip´o al embarcarse en esta soluci´on.

Sin embargo esto no quita que para el equipo la decisi´on fue crucial y acertada.

Con este componente logramos el objetivo 2 del producto sobre adaptabilidad y extensibilidad, al poder describir cualquier contexto con la misma biblioteca.

Por ejemplo, ¿Quiero hacer una promoci´on durante un tiempo determinado? No es necesario que exista el concepto de “Promoci´on por fecha”. Mientras la regla tenga en su contexto la fecha actual y exista un operador para comparar fechas,

ese “disparador” de una promoci´on es posible. Como tambi´en es posible utilizar el mismo operador para definir el segmento de usuarios que nacieron entre dos fechas.

La misma generalidad aplica para las acciones de una regla.

Esto mueve el objetivo de los futuros desarrollos en la plataforma; en lugar de buscar desarrollar cierto tipo de promoci´on, descuento, etc. y las ramificaciones que tiene con lo ya existente, ahora se debe pensar en “qu´e operadores y acciones necesito para tener determinado efecto”. A medida que la base de operadores, acciones y contextos a los que puede acceder la regla crece, las combinaciones y por tanto posibilidades se multiplican.