TEMA 6: Diseño por Contrato

Un método en Java que devuelve un valor booleano debe: Tener un modificador accesible para los clientes de las rutina si se incluye como postcondición. Tener un modificador privado para los clientes de las rutina si se incluye como precondición. Tener un modificador accesible para los clientes de las rutina si se incluye como precondición.

En Java los asertos: Son macros igual que en C. Son una palabra reservada del lenguaje. Se implementan con if/else.

Para un método que permite extraer un elemento de una cola, la predicción más adecuada sería: La cola está llena. La cola no está vacía. La cola tiene 3 elementos.

Las precondiciones implican a: Clientes. Proveedores. Clientes y proveedores.

En una tripleta de Hoare como la siguiente, sería correcta la postcondición: {x > 1}. {x = 1}. {x < 1}.

El diseño por contrato parte de la idea de que: Comprobaciones redundante son de obligada inclusión. Comprobaciones redundante pueden incluir nuevos errores. Comprobaciones redundante nunca hacen daño.

En lenguajes de programación que no incluyen variantes, se deberían añadir manualmente en: En las precondiciones a los métodos. Pre y postcondiciones de los métodos. En las postcondiciones a los métodos.

El diseño por contrato prefiere: Realizar las comprobaciones mínimas necesarias. No realizar comprobaciones delegando fiabilidad de los lenguajes estáticamente tipados. Realizar todas las comprobaciones necesarias excepto las redundantes.

Para la comunicación entre rutinas por diseño de contrato: Usamos programación defensiva en los clientes y postcondiciones en proveedores. Usamos pre y postcondiciones en clientes y proveedores. Usamos programación defensiva en clientes y proveedores.

Una aserción implica: Entidades que cumplen una condición en ejecución. Entidades que cumplen una condición en compilación. Entidades que cumplen una condición en documentación.

En la metáfora del contrato, el empleado busca: Precondiciones débiles y postcondiciones débiles. Precondiciones fuertes y postcondiciones débiles. Precondiciones débiles y postcondiciones fuertes.

La documentación sugiere que: Se use programación defensiva en todas las entradas de los métodos. Se use programación defensiva en todas las entradas de los métodos públicos y asertos en métodos no públicos. Se use programación defensiva en la finalización de los métodos.

El diseño por contrato se basa en: Incluir en el software mecanismos para probar la especificación. Incluir en el software código adicional que comprueve todo. Incluir en el software documentación para probar la especificación.

La documentación sugiere: Se use programación defensiva en todas las salidas de los métodos. Se usen asertos en la salida de los métodos. No se incluyan asertos.

Los invariantes se deben verificar: Durante todos los momentos observables en la vida de un objeto. Durante algunos momentos observables en la vida de un objeto. Durante toda la vida del objeto.

En el diseño por contrato, una precondición en una rutina: Se incluye aunque no esté documentada ni sea parte de la especificación. Debe ser justificable si se debe implementar en el lenguaje de programación utilizado. Debe ser justificable porqué está documentada y es parte de la especificación.

En los constructores, los invariantes se deben verificar: A la finalización. Al inicio. Al inicio y final.

Dado el siguiente código int x = 10; assert x < 10: "Aserción no verificada con valor:" + x;. Se interrumpe la ejecución si activamos los asertos. Se interrumpe la ejecución. Nunca se interrumpe la ejecución porque se verifica el aserto.

Las postcondiciones implican al: Cliente y proveedor. Proveedor. Cliente.

En la metáfora del contrato, el empresario busca: Precondiciones débiles y postcondiciones fuertes. Precondiciones fuertes y postcondiciones fuertes. Precondiciones fuertes y postcondiciones débiles.