PDF de programación - TEMA 4 Corrección y Robustez

Programación Orientada a Objetos

TEMA 4

Corrección y Robustez

Facultad de Informática
Universidad de Murcia

Contenido

1. Introducción

• Fiabilidad = Corrección y Robustez

2. Asertos y Técnica de diseño por contrato

3. Abordando los casos excepcionales

Corrección y Robustez

2

•1

Introducción

• “La reutilización y la extensibilidad no se deben lograr a expensas

de la fiabilidad (corrección y robustez)”.

• Corrección:

– Capacidad de los sistemas software de ajustarse a la especificación.
– Asegura que el programa hace lo correcto durante la ejecución normal del

programa.

– Los asertos permiten especificar la semántica de una clase, establecen las

condiciones que se deben cumplir.

• Robustez:

– Capacidad de los sistemas software de reaccionar ante circunstancias

inesperadas.

– El mecanismo de excepciones proporciona un mecanismo para
manejar estas situaciones excepcionales durante la ejecución de un programa.

Corrección y Robustez

3

Corrección. Asertos

(A) Especificar la semántica de las rutinas mediante:

– PRECONDICIONES:

Condiciones para que una rutina funcione adecuadamente.

– POSTCONDICIONES:

Describen el efecto de una rutina, definiendo el estado final.

(B) Especificar las propiedades globales de una
clase mediante el INVARIANTE:

Aserción que expresa restricciones de integridad que deben
ser satisfechas por cada instancia de la clase si se encuentra en una
situación estable.

Corrección y Robustez

4

•2

Momentos “estables”

• Los “momentos estables” son aquellos en los que una

instancia está en un estado observable (e1, e2, …):
– Después de la creación
– Antes y después de la invocación remota de una rutina de la

clase

5

6

•3

a = new A(…);

En etapas intermedias el INV no se cumplirá

¿Cuál es el papel de las rutinas de creación?

Corrección y Robustez

e1

a.f(...)

e2

a.g(...)

e3

a.f(...)

e4

Ejemplo: Pre y Postcondiciones

/**

* Inserta en el mapa un elemento con
* clave key
* @pre count< capacity mapa no lleno
*
key != “” Clave significativa
* @post count <= capacity;
*
*
*/

item (key) = elemento;
count= oldCount + 1;

public void put (T elemento, String key){

...

}

Corrección y Robustez

Ejemplo invariante

/**

}

* Clase que representa figuras
* geométricas 2D
* @inv numVertices > 3
*/
public class Poligono{
…

• Todas las instancias de polígono tienen que cumplir que

el número de vértices sea mayor de tres.

Corrección y Robustez

7

Utilidad de los asertos

• Escribir software correcto:

describir requisitos exactos de cada rutina y las propiedades
globales de las clases ayuda a producir software que es correcto
desde el principio.

• Ayuda para la documentación:

pre, post- condiciones e invariante proporcionan información
precisa a los clientes de los módulos.

• Apoyo para la prueba y depuración:

el programador establece como opción del compilador el efecto
de las aserciones en tiempo de ejecución.

Corrección y Robustez

8

•4

Asertos en Java

• El mecanismo de aserciones permite insertar pruebas durante la

• A partir del JDK1.4 el lenguaje incluye la palabra reservada

depuración y luego eliminarlas automáticamente.
assert

• Expresión booleana que un desarrollador indica explícitamente
que se debe cumplir en un punto del programa en tiempo de
ejecución.

assert expresion_boolean;
assert expresion_boolean : expresion;

• El sistema evalúa la expresión booleana e informa del error en el

caso de que el valor sea false.
– Lanza AssertionError

Corrección y Robustez

9

Ejemplos
assert ref != null;
assert saldo == (oldSaldo + cantidad);
assert ref.m1(parametro);
assert valor>0 : “argumento negativo”;
assert x>0 : x;
• La expresion_booleana no debe tener efectos

laterales

• La expresión se pasa como argumento al constructor de

la excepción en el caso de que el aserto sea false.

Corrección y Robustez

10

•5

Activación de asertos en Java

• Los asertos los soporta sólo a partir de la versión 1.4. Se debe
indicar explícitamente al compilador para que reconozca la palabra
clave assertion
javac –source 1.4 MiAplicacion.java

• La comprobación de los asertos se puede desactivar en tiempo

de ejecución para incrementar el rendimiento.
– Normalmente se activa durante la fase de depuración y pruebas

java [–ea|-da] MiAplicacion
java –ea:UnaClase –ea:java.modelo –da:OtraClase App

• A partir de la versión JDK 5.0 el soporte para aserciones está

activado por defecto.

Corrección y Robustez

11

Usos de los asertos

• Invariantes internos:
if (i%3 == 0){
…}else if (i%3 == 1){
…} else {
assert (i%3 ==2);
…
}

• Invariantes de flujo de control:

void met(){

if(…) return;

for (…){
}
//nunca deberíamos llegar a este punto
assert false;

}

• Precondiciones, postcondiciones e invariantes:

Corrección y Robustez

12

•6

Pre y postcondicones en Java
private void setIntervalo(int intervalo){
//precondición
assert intervalo>0 && intervalo<=MAXIMO;
...//establecer el intervalo

}
//devuelve this-1 mod m
public BigInteger modInverso (BigInteger m){

//comprobaciones de la precondición
...
//hacer el cálculo
//postcondición
assert this.multiply(result).mod(m).equals(UNO);
return result;

}

Corrección y Robustez

13

Invariante en Java

public class Pila{

//método que comprueba el invariante
private boolean invariante(){

return ((count>=0) && (count <=capacity) &&

(capacity == representation.length));

}
• Se debe cumplir antes y después de la terminación de cada

}
...

método.

• Todo método y constructor debe contener la línea

assert invariante();

antes de empezar e inmediatamente antes de que termine.

Corrección y Robustez

14

•7

¿Cuándo utilizar assert?

• Localizar errores internos irrecuperables durante la

fase de pruebas y depuración.

• No utilizar para evaluar condiciones externas al
programa (existencia de un fichero, conexión de red,
…)

• Puesto que se pueden desactivar, la corrección de un

programa no puede depender de los asertos.

Corrección y Robustez

15

Técnica del Diseño por Contrato

Definir una pre y una postcondición para
una rutina es una forma de definir un
contrato que liga a la rutina con quien la
llama.

Obligaciones

Al invocar a put
debe asegurar que
la tabla no está llena

Beneficios

Obtiene una tabla en la que
elemento está asociado con clave

put
Cliente

Servidor

Insertar elemento
en la tabla asociándolo de tabla llena antes de la inserción
a clave

No necesita tratar la situación

Corrección y Robustez

16

•8

Técnica del Diseño por Contrato

Definir una pre y una postcondición para
una rutina es una forma de definir un
contrato que liga a la rutina con quien la
llama.

Obligaciones

Beneficios

Satisfacer
Al invocar a put
debe asegurar que
la tabla no está llena
precondición

Obtiene una tabla en la que
De la postcondición
elemento está asociado con clave

put
Cliente

Servidor

Satisfacer
Insertar elemento
No necesita tratar la situación
De la precondición
en la tabla asociándolo de tabla llena antes de la inserción
postcondición
a clave

Corrección y Robustez

17

Contrato Software

“Si usted me promete llamar a rcon
pre satisfecho
le
prometo entregar un estado final en
el que post es satisfecho”

entonces

yo

Lo que es una obligación para
uno es un beneficio para el

otro

CLIENTE

CLASE

Corrección y Robustez

18

•9

Rechazo a la “programación defensiva”

sqrt(x: REAL): REAL is do

if x<0 then “Manejar error”
else “Calcular raíz”

end;

No hay que comprobar la precondición en la rutina

sqrt(x: REAL): REAL is

require

x >= 0;

CLIENTE:
if (x>=0)

Math.sqrt(x);

do

end;

“Calcular raíz”

El cuerpo de la rutina no comprueba el cumplimiento

de la precondición

Corrección y Robustez

19

Rechazo a la “programación defensiva”

• Redundancia es perjudicial: software más complejo.

¡¡La complejidad es el mayor enemigo de la calidad!!

• Mejor identificar condiciones y establecer responsabilidades.

• Tedioso eliminar o ignorar los controles cuando no se necesiten

• Paradoja: “La fiabilidad se mejora chequeando menos”

¡¡Garantizar mas comprobando menos!!

“El código cliente debe comprobar la precondición”

Corrección y Robustez

20

•10

Diseño por Contrato y assert

/** Insertar en la tabla elemento con clave key */
public void put (Object elemento, String key) {

assert count < capacity: “fallo en la pre”;

int oldCount = count;

... "algoritmo de inserción"

assert count <= capacity &&

item (key).equals(elemento) &&
count == oldCount + 1: “fallo en la post”;

}

El control de las precondiciones no se debe dejar
en manos de los assert (excepciones Runtime)

Corrección y Robustez

21

3.- Abordando los casos excepcionales

Técnicas de diseño

• Esquema a priori:

• Esquema a priori
• Esquema a posteriori
• Mecanismo de excepciones

– Se pide al cliente que tome medidas por adelantado para evitar

posibles errores

– Los errores en ejecución implican un error del cliente.

if pre(y) then
operacion(y)

else

end

--acción alternativa

do

operacion(x:...) is

require

pre(x)

…acción si pre= true

end

Corrección y Robustez

22

•11

Problemas del esquema a priori
• Problemas de eficiencia:

– No siempre es posible comprobar primero la precondición.
– Ejemplo: calcular si una matriz es o no singular antes de

calcular su inversa.

• Limitaciones de los lenguajes de asertos:

– Algunas aserciones no se pueden expresar.
– Cuando la precondición es una propiedad global de una

estructura de datos y necesita cuantificadores.

– Ejemplo: comprobar que un grafo no tiene ciclos.

• El éxito depende de eventos externos:

– Es imposible comprobar la aplicabilidad sin ejecutarla.
– Ejemplo: una línea de comunicaciones

Corrección y Robustez

23

Esquema a posteriori

• Probar después de la ejecución de la operación.
• Sólo es posible en algunas ocasiones.

obj:A
x:INTEGER
obj.operacion(y)
if obj.exito then
else
end

x:= obj.resultado

...manejar el