4.3 Data Validation Process
4.3.2 Peer debriefing by experts
Este editor está especialmente diseñado para cubrir las necesidades de los desarrolladores de reglas de negocio. Se ha implementado como una extensión (plugin en inglés) de Rational Software Architect20 (RSA), una herramienta de IBM específicamente diseñada para procesos de desarrollo orientados por modelos. Este editor permitirá la definición de reglas de acuerdo a un modelo UML disponible en el proyecto con el que se está trabajando. Las reglas en cuestión se representan a través de una clase UML con un estereotipo específico, que distingue a los servicios de decisión que se incluyen en una aplicación. Entre las funcionalidades que proporciona se encuentran:
• Especificación de los términos que representan a cada elemento UML. Al conjunto de términos o palabras que pueden emplearse para representar a cada elemento del modelo en el que se desenvolverán las reglas de negocio se le denomina verbalización. Desde el editor es posible modificar las palabras que designan a un elemento que inicialmente se toman de las palabras clave que acompañan a los estereotipos o, en su defecto, de los nombres asignados a los elementos. Estas palabras son la clave para la expresión de una regla en un lenguaje próximo al natural.
• Definición del flujo de trabajo para la regla de negocio o servicio de decisión. Las reglas de negocio pueden agruparse en conjuntos de reglas o rulesets que, a su vez, pueden enlazarse en secuencias atendiendo a elementos condicionales formando un diagrama de flujo. Es importante destacar que las reglas incluidas en un mismo ruleset no tienen ninguna precedencia en cuanto a su orden de ejecución, es decir, si varias de las reglas se validan en un momento dado, no es posible determinar cuál de ellas se ejecutará antes de las demás. En cambio los rulesets se ejecutarán según el flujo definido en el diagrama.
• Creación de reglas mediante un lenguaje próximo al natural. El editor permite definir las reglas en lenguaje natural, pero empleando un mecanismo de guiado. Es decir, el usuario no puede escribir libremente la expresión de la regla, si no que se le ofrecen distintas alternativas disponibles de expresiones que puede emplear tanto para definir los antecedentes como los consecuentes de la regla. La Figura IV‐ 4 ofrece una vista de este editor. Una regla tiene la siguiente estructura:
o DEFINICIONES: Donde se incluyen referencias a objetos específicos que se encuentran en la memoria de trabajo del sistema. Por ejemplo, a un cliente específico con el que se desea trabajar se le puede denominar 'Cliente Modelo'. o FÓRMULAS: Es posible definir funciones matemáticas que utilizar posteriormente en
la regla de negocio. Para ello se incorpora un conjunto de funciones predefinidas comunes, como pueden ser: seno, coseno, máximo, logaritmo, raíz cuadrada, etc.
19 http://java.sun.com/webservices/reference/tutorials/jaxp/html/sax.html 20 http://www-01.ibm.com/software/awdtools/architect/swarchitect/
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
Esta funcionalidad sirve de soporte en dominios financieros donde los expertos emplean estas funciones matemáticas en su trabajo diario.
o SI: Agrupa las condiciones que forman el antecedente de la regla de negocio.
o ENTONCES: Incluye el consecuente de la regla de negocio o, lo que es igual, las acciones que se llevarán a cabo en caso de que se cumplan las restricciones definidas en el antecedente.
o SI NO: En este apartado se engloban las acciones a llevar a cabo si no se cumplen las condiciones definidas en el elemento 'SI'.
• Construcción de reglas mediante tablas de decisión. Otro método para definir una regla de negocio que puede resultar útil en muchas situaciones es la utilización de una tabla de decisión. En esta representación, las columnas de la tabla hacen referencia a propiedades de conceptos (es decir, atributos de objetos) y en las celdas correspondientes se incluyen los valores que restringen dicha propiedad. Las columnas situadas al final de la tabla representan los consecuentes de las reglas, es decir, las acciones que deben llevarse a cabo en caso de que se cumplan las condiciones impuestas en las columnas anteriores. La Figura IV‐ 5 incluye un ejemplo de tabla de decisión en K‐Site Rules.
Figura IV- 4. Vista del editor de reglas de negocio en un lenguaje próximo al natural
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
Figura IV- 5. Vista del editor de columnas de las tablas de decisión en el editor del desarrollador en K-Site Rules
• Especificación de reglas mediante árboles de decisión. La tercera herramienta que proporciona K‐Site Rules para la creación de reglas permite definir un árbol de decisión. Estos árboles se componen de cinco elementos: un nodo inicial, que marca el comienzo del árbol; uno o varios nodos finales, que cierran las distintas ramas; nodos de decisión, que contienen comparaciones lógicas cuyo resultado de evaluación marca el siguiente nodo a visitar y nodos de acción, es decir, las operaciones a llevar a cabo antes de alcanzar el nodo final que cierra el árbol. En definitiva, los nodos de decisión contendrán las condiciones de la regla en lenguaje natural (parte SI) mientras que los nodos de acción contendrán las instrucciones del consecuente de la regla en lenguaje natural (parte ENTONCES). La Figura IV‐ 6 muestra un árbol de decisión representado con K‐Site Rules.
• Generación automática y visualización de reglas en formato RIF, DRL y/o IRL. El editor del desarrollador tiene integrado el traductor de reglas de negocio de RIF a DRL y/o IRL, pasando por OMG PRR. Esta transformación es automática y su resultado quedará almacenado en el gestor de la configuración, de manera que pueda estar disponible si el servicio de decisión que está en desarrollo se reutiliza en otro proyecto.
• Validación del comportamiento del servicio de decisión. Es posible comprobar si el funcionamiento del servicio de decisión que se ha definido es el adecuado mediante la función de validación. Las pruebas a realizar necesitan información de entrada, es decir, un conjunto de datos sobre los que poder ejecutar las reglas de negocio. El desarrollador tiene varias alternativas para suministrar estos datos, entre ellas, utilizar la interfaz proporcionada
Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio
para suministrar los datos por teclado, cargar un fichero con un conjunto de objetos serializados o importar un fichero con datos en Excel cuya estructura sea acorde con las tablas incluidas en la interfaz de la aplicación para indicar los valores a través del teclado. Se generarán implementaciones básicas para los objetos involucrados, en los que únicamente se almacenarán los datos suministrados, y que se emplearán para activar la memoria de trabajo del motor de reglas seleccionado. Como se deduce de lo anterior, las pruebas que pueden llevarse a cabo son de tipo unitario, las pruebas de integración quedan fuera de los objetivos de la herramienta, puesto que dependen de la política de pruebas implantada en la organización.
Figura IV- 6. Vista de un árbol de decisión editado con el editor del desarrollador de K-Site Rules
• Control de versiones de las reglas de negocio de un servicio de decisión. Por último, la herramienta permite gestionar las diferentes versiones que se hayan podido crear para las reglas de negocio. Esta funcionalidad permite realizar un seguimiento de la evolución de la regla de negocio, siendo posible volver a versiones antiguas en un momento dado.
IV.2.2.1.
Caso de ejemplo con el editor del desarrollador de KSite Rules
No resultaría de utilidad incluir en esta memoria de tesis un manual de usuario detallado del editor del desarrollador de K‐Site Rules, pero puede ser interesante desarrollar un caso de uso con la herramienta, es decir, describir la secuencia de pasos que se seguirían en un proyecto típico de desarrollo de reglas de negocio. Este caso de uso se incluye en el presente apartado. El dominio de negocio en el que se desenvuelve el caso no es relevante ya que, lógicamente, el proceso de desarrollo es independiente de la aplicación.Introduciendo Semántica en un Proceso de Desarrollo Software a través de Reglas de Negocio