Diseño por contratos: construyendo software confiable

Los invariantes de clase sirven para expresar propiedades globales de las instancias de una clase, mientras que las pre y poscondiciones describen las propiedades de rutinas particulares. Desde el punto de vista de la metáfora de los contratos, los invariantes de clase establecen regulaciones generales aplicables a todos los contratos. Los invariantes de clase provienen del concepto de invariante de datos de Hoare (Hoare, 1972).
Por ejemplo la clase ARRAY en Eiffel cuenta (entre otros) con el siguiente invariante de clase:

Este invariante establece que un ARRAY no puede tener una cantidad de elementos menor que cero. Similarmente si se tiene una clase PERSONA se puede establecer como invariante que la edad debe ser mayor que cero y además que si es casada entonces el cónyuge tiene como cónyuge a sí mismo. En Eiffel se vería de la siguiente forma:

En el invariante con etiqueta matrimonio _ correcto se establece que, o bien se es soltero o sino el cónyuge tiene como cónyuge a Current (o sea a sí mismo) .
Los invariantes de clase deben satisfacerse en dos momentos: luego de la creación del objeto y luego de la llamada a una rutina por un cliente.

Ahora se pueden establecer las condiciones de corrección de una clase. Para ello se usará la notación de la tripleta de Hoare. Una clase es correcta con respecto a sus aserciones sí y sólo si se cumplen las siguientes condiciones (Meyer,1997):

Para toda rutina de creación rc: {prerc } dorc { postrc and INV}
Para toda rutina exportada r: {INV and prer } dor { postr and INV}

Donde prea y posta representan la pre y poscondición respectivamente de una rutina a, INV es el invariante de la clase donde se implementa a y doa representa la ejecución de a.

De aquí se deduce que el rol principal del procedimiento de creación (algunas veces llamado constructor) es establecer el invariante de clase

¿Qué significa la violación de un contrato?. La violación de un contrato representa un defecto en el software. Dependiendo del tipo de aserción es la ubicación del defecto. Si se viola una precondición, entonces existe un defecto en el cliente. Si se viola la poscondición o el invariante de clase, existe un defecto en el proveedor. Es importante que se puedan monitorear las aserciones en tiempo de ejecución con propósitos de testeo, afirmación de calidad (las actividades de QA se basan en lo previsto por los contratos) y depuración. Es decir, no son solamente un mecanismo de especificación y documentación (en Eiffel existe una forma de visualizar una clase llamada contract form que muestra la clase con sus rutinas publicadas con pre y poscondiciones y el invariante de clase), sino que además cumplen un rol importante durante todas las etapas del desarrollo de software.

Es importante que el desarrollador tenga la opción de elegir en tiempo de compilación que aserciones monitorear. Luego de la depuración y el testeo, es posible generar el sistema de producción con las aserciones sin habilitar (evitando el chequeo en tiempo de ejecución). En general es recomendable mantener habilitado el chequeo de las precondiciones. Meyer hace una detallada explicación de esto (Meyer,1997). La violación de una aserción en tiempo de ejecución produce un excepción que puede ser posteriormente manejada.

Los contratos de software sirven como vehículo de comunicación entre desarrolladores, entre gerentes y desarrolladores, para realizar manuales, etc. Pero además son una de las herramientas más importantes para realizar reuso de software. El contrato permite conocer qué se está reusando y bajo qué condiciones. Un interesantísimo artículo de Jézéquel y Meyer dan cuenta de como la utilización de contratos podría haber evitado pérdidas millonarias en un proyecto de software (Jézéquel, 1997).