sábado
ene132007
Diseño Por Contrato
sábado, enero 13, 2007 at 3:13PM
Buenos días.
El tema de esta noticia y reflexión es el Diseño Por Contrato (abreviado DPC), aprovechando la noticia de SpringContracts recientemente publicada por un compañero nuestro.
Recuerdo haber pasado casi un año en la facultad estudiando la verificación y derivación de algoritmos recursivos e iterativos sobre el papel, amén de la especificación algebraica de tipos abstractos de datos. Cierto es que me permitió adquirir un conocimiento más profundo de qué es y cómo funciona realmente un algoritmo, pero siempre me planteé, al igual que mis compañeros, dónde se encontraba la utilidad práctica de esos conocimientos cuando en ningún proyecto de laboratorio se hacía uso de ellos. Hasta que leyendo por mi cuenta me topé con el libro Construcción de Software Orientado a Objetos, escrito por Bertrand Meyer. Este caballero es el padre del lenguaje Eiffel, el cual lleva incorporado nativamente el DPC -en inglés Design By Contract, abreviado DBC-.
El DPC es una herramienta que ayuda a producir software libre de errores determinando para cada módulo de la aplicación cuál es el contrato que debe cumplir. Se entiende por contrato qué estado debe verificar el sistema para poder ejecutar ese módulo, lo que se llama precondición, y qué estado, llamado postcondición, debe alcanzar el sistema cuando se termina de ejecutar correctamente el módulo habiéndose cumplido previamente la precondición. Si no se cumple la precondición, como es lógico, no se puede garantizar que el módulo satisfaga la postcondición. Además de precondiciones y postcondiciones, existen otros tipos de asercioens: invariantes de clase, invariantes de bucle y variantes de bucle.
El DPC es complementario a las pruebas, en ningún caso son incompatibles ni excluyentes. Es una herramienta que aprovecha todos esos conocimientos teóricos que se estudian en los libros de corrección de algoritmos para lograr por fin darles un enfoque útil. Obviamente no es fácil. Supone, utilizando un lenguaje de programación, escribir aserciones en lógica de primer orden, lo que no es sencillo. También requiere un esfuerzo para tratar de entender de forma precisa qué hace realmente nuestro módulo, para ello acotando y delimitando responsabilidades que han de ser descritas de forma lógica.
La comprobación de las aserciones supone un coste en tiempo de ejecución, como es lógico, por lo que en desarrollo se suelen dejar activos todos los controles, y una vez que se está en producción se suelen quitar los controles o, lo que es más seguro y supone un compromiso razonable, se deja activa sólo la comprobación de que se verifican las precondiciones.
Un libro muy interesante es Design by Contract, by Example, de Richard Mitchell y Jim McKim, en el que se explica con detalle esta herramienta, empleando Eiffel en todos los capítulos, excepto en el último, donde muestra cómo usarla con Java utilizando un preprocesador llamado iContract. Desde que apareció el DPC han surgido varias herramientas que pretenden soportar el DPC en Java, algunas no actualizadas y otras con gran actividad.
Como realmente no las he probado, no puede decir mucho sobre ellas salvo breves indicaciones.
JMSAssert (http://www.mmsindia.com/JMSAssert.html) lleva algún tiempo parado. JContract (http://www.parasoft.com/jsp/products/home.jsp?product=Jcontract) es de pago. JContractor también lleva tiempo parado. A Barter (http://barter.sourceforge.net/) le pasa algo parecido.
La herramienta iContract estuvo algún tiempo abandonada, pero hace poco ha sido resucitada en iContract2 (http://www.icontract2.org/) y parece estar activa. Jass (http://csd.informatik.uni-oldenburg.de/~jass/index.html) sigue un proceso lento pero parece que sin detenerse. En la próxima versión utilizará para las aserciones el JML -o Java Modeling Language- (http://www.cs.iastate.edu/~leavens/JML/), que es un lenguaje de especificación formal de interfaces que mezcla conceptos del DPC, de la familia de lenguajes formales Larch y elementos del cálculo de refinamiento. Se puede emplear el JML de forma aislada para DPC, pero la curva de aprendizaje es demasiado grande debido a que su área de aplicación va más allá del Diseño Por Contrato, por lo que es mucho más práctico utilizar una herramienta aparte.
Otra herramienta interesante es contract4j (http://www.contract4j.org/contract4j) que usa aspectos y anotaciones. Todavía no trata correctamente la herencia al implementar el DPC, aunque parece que pronto estará solucionado. Es compatible con Java SE 5 y 6. El último proyecto que voy a indicar es C4J (http://c4j.sourceforge.net/), también compatible con Java SE 5 y 6. Tiene bastante actividad y parece estar avanzado.
Y ahora las preguntas de rigor... ¿os parece factible usar el DPC en aplicaciones reales? ¿Creeis que la curva de aprendiza es demasiado grande? ¿Lo veis difícil o poco útil? ¿Habéis tenido alguna experiencia al respecto?
Un saludo,
José María
El tema de esta noticia y reflexión es el Diseño Por Contrato (abreviado DPC), aprovechando la noticia de SpringContracts recientemente publicada por un compañero nuestro.
Recuerdo haber pasado casi un año en la facultad estudiando la verificación y derivación de algoritmos recursivos e iterativos sobre el papel, amén de la especificación algebraica de tipos abstractos de datos. Cierto es que me permitió adquirir un conocimiento más profundo de qué es y cómo funciona realmente un algoritmo, pero siempre me planteé, al igual que mis compañeros, dónde se encontraba la utilidad práctica de esos conocimientos cuando en ningún proyecto de laboratorio se hacía uso de ellos. Hasta que leyendo por mi cuenta me topé con el libro Construcción de Software Orientado a Objetos, escrito por Bertrand Meyer. Este caballero es el padre del lenguaje Eiffel, el cual lleva incorporado nativamente el DPC -en inglés Design By Contract, abreviado DBC-.
El DPC es una herramienta que ayuda a producir software libre de errores determinando para cada módulo de la aplicación cuál es el contrato que debe cumplir. Se entiende por contrato qué estado debe verificar el sistema para poder ejecutar ese módulo, lo que se llama precondición, y qué estado, llamado postcondición, debe alcanzar el sistema cuando se termina de ejecutar correctamente el módulo habiéndose cumplido previamente la precondición. Si no se cumple la precondición, como es lógico, no se puede garantizar que el módulo satisfaga la postcondición. Además de precondiciones y postcondiciones, existen otros tipos de asercioens: invariantes de clase, invariantes de bucle y variantes de bucle.
El DPC es complementario a las pruebas, en ningún caso son incompatibles ni excluyentes. Es una herramienta que aprovecha todos esos conocimientos teóricos que se estudian en los libros de corrección de algoritmos para lograr por fin darles un enfoque útil. Obviamente no es fácil. Supone, utilizando un lenguaje de programación, escribir aserciones en lógica de primer orden, lo que no es sencillo. También requiere un esfuerzo para tratar de entender de forma precisa qué hace realmente nuestro módulo, para ello acotando y delimitando responsabilidades que han de ser descritas de forma lógica.
La comprobación de las aserciones supone un coste en tiempo de ejecución, como es lógico, por lo que en desarrollo se suelen dejar activos todos los controles, y una vez que se está en producción se suelen quitar los controles o, lo que es más seguro y supone un compromiso razonable, se deja activa sólo la comprobación de que se verifican las precondiciones.
Un libro muy interesante es Design by Contract, by Example, de Richard Mitchell y Jim McKim, en el que se explica con detalle esta herramienta, empleando Eiffel en todos los capítulos, excepto en el último, donde muestra cómo usarla con Java utilizando un preprocesador llamado iContract. Desde que apareció el DPC han surgido varias herramientas que pretenden soportar el DPC en Java, algunas no actualizadas y otras con gran actividad.
Como realmente no las he probado, no puede decir mucho sobre ellas salvo breves indicaciones.
JMSAssert (http://www.mmsindia.com/JMSAssert.html) lleva algún tiempo parado. JContract (http://www.parasoft.com/jsp/products/home.jsp?product=Jcontract) es de pago. JContractor también lleva tiempo parado. A Barter (http://barter.sourceforge.net/) le pasa algo parecido.
La herramienta iContract estuvo algún tiempo abandonada, pero hace poco ha sido resucitada en iContract2 (http://www.icontract2.org/) y parece estar activa. Jass (http://csd.informatik.uni-oldenburg.de/~jass/index.html) sigue un proceso lento pero parece que sin detenerse. En la próxima versión utilizará para las aserciones el JML -o Java Modeling Language- (http://www.cs.iastate.edu/~leavens/JML/), que es un lenguaje de especificación formal de interfaces que mezcla conceptos del DPC, de la familia de lenguajes formales Larch y elementos del cálculo de refinamiento. Se puede emplear el JML de forma aislada para DPC, pero la curva de aprendizaje es demasiado grande debido a que su área de aplicación va más allá del Diseño Por Contrato, por lo que es mucho más práctico utilizar una herramienta aparte.
Otra herramienta interesante es contract4j (http://www.contract4j.org/contract4j) que usa aspectos y anotaciones. Todavía no trata correctamente la herencia al implementar el DPC, aunque parece que pronto estará solucionado. Es compatible con Java SE 5 y 6. El último proyecto que voy a indicar es C4J (http://c4j.sourceforge.net/), también compatible con Java SE 5 y 6. Tiene bastante actividad y parece estar avanzado.
Y ahora las preguntas de rigor... ¿os parece factible usar el DPC en aplicaciones reales? ¿Creeis que la curva de aprendiza es demasiado grande? ¿Lo veis difícil o poco útil? ¿Habéis tenido alguna experiencia al respecto?
Un saludo,
José María
Reader Comments