Técnicas Formales vs. Técnicas Informales

Un producto de software es creado para solucionar un determinado problema. Sin embargo, es todavía en la actualidad para los desarrolladores de software un verdadero desafío poder capturar con exactitud y precisión el problema a resolver. Los requerimientos son por naturaleza dinámicos y volátiles, y muchos de ellos todavía están sin descubrir al iniciarse cualquier proyecto de software.

La manera más natural de acercarse a los requerimientos como seres humanos es a través del lenguaje natural. Por otra parte, esta opción no es la más adecuada para utilizar herramientas de análisis y modelado de sistemas debido a que el lenguaje natural es muchas veces confuso y ambiguo. Dichas características no se llevan bien con los procesos automáticos involucrados en  las herramientas. En otras palabras, si se desea usar técnicas automáticas se deberá contar con mecanismos formales.

Los mecanismos formales más conocidos se basan en la utilización de lógicas temporales, o en notaciones inspiradas en autómatas finitos. A través de ellos se abre la puerta de técnicas automatizadas de análisis, verificación y validación, como Model Checking. La industria del software ha empleado numerosas y exitosas herramientas de este estilo como ser Java Pathfinder, Bandera, UPPAAL, LTSA, o CHESS, por nombrar algunas.

El principal obstáculo que enfrentan los mecanismos formales para su consolidación definitiva es que requieren usuarios expertos para su correcto funcionamiento. Cualquier desarrollador que no cuente con este nivel en lógicas temporales, por ejemplo, verá seriamente limitada la posibilidad de capturar requerimientos a través de estas técnicas.

Es claro que no es posible prescindir de los mecanismos formales si el objetivo es nutrirse de herramientas automáticas de análisis. Los casos de uso han sido de gran utilidad para la captura de requerimientos, pero los mismos no cuentan con la suficiente rigurosidad formal requerida para automatizar cualquier proceso, dado que están basados en el empleo del lenguaje natural.

El gran objetivo de la comunidad detrás de las técnicas formales es lograr un mecanismo que sea intuitivo, fácil de entender y manipular,  combinado con una fuerte semántica formal.

En SOA la posibilidad de utilizar técnicas formales en la definición de requerimientos permitirá identificar de manera univoca nuevos servicios que implementaran ciertas capacidades funcionales con el fin de lograr la reutilización de los mismos dentro de los diferentes procesos de negocio que existan.

En este sentido, muchas empresas han incorporado esta funcionalidad en sus productos. Por ejemplo, IBM ha implementado en sus principales herramientas de diseño como  Rational Software Architect y Rational Software Modeler el estándar SoaML (Service oriented architecture Modeling Language), basado en UML pero enfocado en el modelado y diseño de servicios para una arquitectura SOA. De esta manera, los desarrolladores pueden valerse de diagramas de componentes y diagramas de secuencia SoaML para formalizar y especificar la interacción de los distintos servicios. También Oracle ha desplegado una variedad de modelos para SOA a través de su herramienta Oracle SOA Suite. Dentro de las soluciones open source se destaca el plug-in SoaML Cartridge  dentro de ModelPro, implementado por la comunidad de ModelDriven (http://portal.modeldriven.org/).