BPM y Requerimientos no Funcionales

La creciente demanda de arquitecturas basadas en servicios (SOA) ha generado el desarrollo de técnicas para modelar y especificar las reglas de negocio que dirigen el comportamiento del sistema. En este sentido, al introducir una arquitectura SOA, una definición completa y apropiada de los procesos de negocio, pasa a jugar un rol fundamental. En pocas palabras, un proceso de negocio puede ser visto como una secuencia bien definida de actividades para lograr un objetivo de negocio en particular.

BPM (Business Process Management) se ha destacado como técnica para modelar y especificar dichos procesos de negocio. De manera similar, lenguajes y herramientas como BPMN (Business Process Model and Notation) y BPEL (Business Process Execution Language) se han impuesto a la hora de llevar adelante una arquitectura SOA con procesos de negocio bien definidos.

Sin embargo, desde la comunidad inmersa en el desarrollo de software se ha detectado un problema relacionado con la especificación de requerimientos no funcionales. Tales requerimientos como disponibilidad, performance, seguridad o modificabilidad, cuyo comportamiento es clave y define el éxito o fracaso de una arquitectura SOA, no son correctamente especificados en BPM. Esto tiene como consecuencia que no son agregados de manera apropiada en la especificación de los procesos de negocio, con la consecuente amenaza para una arquitectura SOA que esté guiada por dichos procesos.

Diferentes propuestas han surgido para aliviar este problema [1,2]. A continuación se describen los principales aspectos de las mismas, cuyo principal objetivo es la incorporación de requerimientos no funcionales en la descripción de procesos BPM de negocio en una arquitectura SOA.

Agregando requerimientos no funcionales a BPM

La primera de las propuestas los incorpora utilizando los mecanismos usuales de BPM a través de un tipo especial de anotaciones, mientras que la segunda define artefactos nuevos para su modelado. A continuación se describen cada una de las propuestas.

Requerimientos no funcionales a través de anotaciones

La propuesta presentada en [1] consiste en agregar los requerimientos no funcionales como anotaciones a las actividades que describen un proceso de negocio. Tales anotaciones se denominan “Artefactos QoS” (Quality of Service). A través de las mismas se pueden introducir cuestiones de disponibilidad (por ejemplo, una actividad que necesite estar disponible todo el tiempo), de seguridad (por ejemplo, una actividad donde se necesite protección y confidencialidad de datos), de performance (especificar el tiempo máximo que puede llevar una actividad). La siguiente figura esquematiza la propuesta, ilustrando la especificación de un requerimiento de performance.

Figura: Anotando requerimientos no funcionales como anotaciones

Finalmente, estos artefactos QoS son codificados utilizando el estándar WS-Policy [3], que permite introducir restricciones al comportamiento de los servicios en un formato XML. Para el ejemplo de la figura la restricción a introducir sería:

<Performance max_runtime_minutes=”15″/>.

Dado este panorama los requerimientos no funcionales pueden implementarse luego en algunas de las herramientas BPEL disponibles, comoestas, oestas otras. Luego, de esta manera sencilla pueden especificarse requerimientos no funcionales a los diagramas BPM.

Requerimientos no funcionales con nuevos constructores

La propuesta en [2] ataca el problema de manera diferente. En vez de utilizar anotaciones, considera artefactos más complejos para darle más valor al requerimiento no funcional. La desventaja es que se debe conseguir una nueva herramienta que implemente y traslade los conocimientos propuestos para su utilización comercial.

La técnica propone acompañar la descripción de una actividad BPM con dos nuevos términos: Condiciones de Operación, y Control. Las condiciones de control establecen de manera declarativa las condiciones necesarias para desarrollar la actividad, ya sean de seguridad, performance, o cualquier otro requerimiento no funcional. La parte de control captura los riesgos de negocio asociados con la condición de operación, y los controles de negocio a realizar para mitigar el riesgo. Uno de los ejemplos presentados en [2] ataca el requerimiento no funcional de seguridad dentro del contexto de un cajero automático (pero es trasladable fácilmente a otro dominio). La actividad de calcular el saldo de una cuenta opera bajos ciertas condiciones de operación y control. Las condiciones de control simplemente establecen simplemente que deben manejarse datos con confidencialidad e integridad, ya que se tratan de datos sensibles. La parte de control puede detallarse con la siguiente tabla:

Conclusiones

Se han presentado dos técnicas para agregar requerimientos no funcionales a BPM. La primera, no introduce nuevos términos, pero tiene un alcance más limitado. El segundo enfoque es más poderoso, pero requiere de nuevas herramientas que implementen los artefactos correspondientes. Un enfoque razonable consiste de utilizar primero la opción más simple, y en el caso de necesitar mayor poder expresivo volcarse a la segunda opción.

Referencias

[1]Oliver Charles -Bernhard Hollunder ICSEA 2011: The Sixth International Conference on Software Engineering Advances.

[2]Christopher J. Pavlovski and Joe Zou. 2008. Non-functional requirements in business process modeling. In Proceedings of the fifth Asia-Pacific conference on Conceptual Modelling – Volume 79 (APCCM ’08), Annika Hinze and Markus Kirchberg (Eds.), Vol. 79. Australian Computer Society, Inc., Darlinghurst, Australia, Australia, 103-112.

[3]W3C, Web Services Policy 1.5 (09/2007) – Framework, Retrieved April 03, 2011.

Imagen: Alexandra Cavoulacos (Flickr bajo licencia CCommons)