Diseño por ContratoTecnología de Objetos

Raúl Herrera A.

Diseño por contrato El diseño por contrato ve las relaciones entre las clases y sus

clientes como un acuerdo formal, que expresa los derechos y obligaciones de cada parte.

La correctitud de un programa es algo relativo, y depende en gran parte de la especificación. Una fórmula de corrección (o tripleta de Hoare) es una expresión de la forma:

(1) {P} A {Q} La fórmula de corrección anterior se lee: una ejecución de A que comience

en un estado en el que se cumpla P terminará en un estado en el que se cumple Q. Aquí A denota una operación. P y Q se denominan aserciones, de las cuales P será la pre-condición y Q será la post-condición .

Ejemplo:{x >= 9} x := x + 5 {x >= 13}

En este caso, una post-condición más fuerte sería {x >= 14}. En este mismo caso, una pre-condición más débil sería {x >= 8}.

Pre y Post condiciones La pre-condición establece las propiedades que se tienen que cumplir cada

vez que se llame a la rutina. La post-condición establece las propiedades que debe garantizar la rutina cuando retorne.

La propiedad de que un programa satisfaga su especificación, si termina, se conoce como corrección parcial. Si un programa satisface su especificación y termina, se dice que es totalmente correcto (total corrección implica además terminación).

Las aserciones permiten, a quienes desarrollan software, construir programas correctos, y documentar por qué son correctos.

En las definiciones de TAD's, la sección requiere denota las pre-condiciones, y la sección ensure denota las post-condiciones.

Contratos y Pre-Post condiciones Definir una pre-condición y una post-condición

para una rutina es una forma de definir un contrato que liga la rutina con quienes la llaman.

En {P} A {Q} la rutina A le está diciendo a sus clientes: "si usted me promete que al llamarme se satisface P, entonces yo le prometo entregar un estado final en el que se satisface Q".

Contratos y Clases Para los contratos entre clases:

La pre-condición compromete al cliente: define las condiciones bajo las cuales es legítima la llamada a una rutina. Es una obligación para el cliente y un beneficio para el proveedor.

La post-condición compromete a la clase (el proveedor): define las condiciones que debe asegurar la rutina al retornar. Esto es un beneficio para el cliente y una obligación para el proveedor.

Ejemplo: TAD PILA

(De la pre-condición)Procesamiento más simple, ya que supone que la pila no está llena.

(Satisfacer post-condición)Actualiza la representación de la pila, de modo que tenga a x en la cima (item devolverá x), count se incrementa en 1, la pila queda no vacía.

Proveedor

(De la post-condición)Obtiene una pila actualizada: no está vacía, tiene a x en la cima (si se aplica item se obtiene x) y count se ha incrementado en 1.

(Satisfacer pre-condición)Sólo puede llamar a put(x) en una pila que no esté llena.

Cliente

BENEFICIOSOBLIGACIONESput

Ejemplo: TAD PILA (2) Note que el cuadro inferior derecho obliga al cliente a llamar

a la rutina con una pila que no está llena. En caso de que el cliente no cumpla esta pre-condición, el proveedor puede retornar cualquier cosa, podría quedarse en un ciclo infinito, o podría terminar abruptamente el programa, sin que esto sea considerado un error.

El uso de contratos simplifica la programación, pues el programador puede dar por supuesto que las pre-condiciones se cumplen, sin tener que verificarlas.

Principio de Redundancia Bajo ninguna circunstancia debe, el cuerpo de la rutina, verificar el

cumplimiento de la pre-condición de la rutina.

Esto último es contrario a lo que proponen la mayoría de libros de texto en ingeniería de software: es mejor comprobar demasiado, que demasiado poco (este último principio es comúnmente llamado programación defensiva).

El diseño por contrato invita a identificar las condiciones de consistencia que son necesarias para el funcionamiento correcto de cada cooperación cliente-proveedor (cada contrato) y a especificar, para cada una de estas condiciones, de quién es la responsabilidad de asegurar la misma: del cliente o del proveedor.

Contratos y Software Los contratos ocurren entre dos rutinas de software (cliente y proveedor).

Es una comunicación software-software, y no software-humano ni software-mundo_externo.

Desde este punto de vista, una pre-condición no se puede ocupar de corregir la entrada del usuario. Por ejemplo, una rutina que lee un número entero positivo del teclado del usuario, no puede incluir una pre-condición de la forma:

require entrada > 0

Para resolver la entrada de datos desde el usuario o desde el mundo exterior, por lo general se definen rutinas de tipo filtro, que leen los datos, los validan y luego interactuan con otras rutinas donde, ahora sí, se pueden aplicar los contratos.

Contratos y Software (2) Las aserciones no son estructuras de control (no son técnicas para manejar casos

especiales). Las aserciones no reemplazan instrucciones condicionales (if ... then ... else ...) ni

de casos (case ... of ...).

Estas instrucciones pueden ser usadas en las rutinas.

Se quiera o no, y a pesar de todas las precauciones, algún suceso inesperado o no deseado ocurrirá tarde o temprano durante la ejecución de un programa. Esto se conoce con el nombre de excepción

Una llamada a una rutina tiene éxito si termina su ejecución en un estado en el que satisface el contrato de la rutina. Fracasa o falla si no tiene éxito.

Una excepción es un suceso en tiempo de ejecución que puede causar que una rutina fracase.

Tratamiento de Excepciones Disciplinado Hay sólo dos respuestas legítimas a una excepción que

ocurre durante la ejecución de una rutina: Reintento: intentar cambiar las condiciones que condujeron a

la excepción, y ejecutar de nuevo la rutina desde el inicio.

Fracaso: limpiar el entorno, terminar la llamada e informar del fallo a quien hace la llamada. Se debe quedar en un estado consistente.

En Java, cuando ocurre una excepción, se crea un objeto

Exception, que se envía al método que provocó la excepción.