Diseo por Contratos

http://designbycontract.com Bertrand Meyer (Object Oriented Software Construction)

cias no detectadas en Tiempo de Com

Si tenemos :
Cuenta c; Stopwatch crono;

un sistema con control esttico de tipos permite hacer

c.Extrae(500); crono.Start();

PERO NO HACER :
c.Stop(); crono.Extrae(500);

Intento e aplicar operacin no existente segn el tipo esttico de la variable

 QU PASA SI HACEMOS ?
Cuenta c = new Cuenta(); c.Deposita(100) c.Extrae(500) Stack<int> s = new Stack<int>(); Console.WriteLine(s.Top);

Dnde est dicho que no podemos extraer si no hay saldo o que no podemos preguntar por el tope si no hay nada en la pila?

La signatura de la clase no dice sobre las condiciones en que se pueden aplicar los mtodos Condiciones que deben cumplirse para que se ejecute el mtodo. Est metido dentro del cdigo. Divorciado de la documentacin.

Requerimiento. Tiene que cumplirse para que el resto del cdigo se ejecute

Los constructores tambin

Eiffel

Metfora del Contrato (compromiso

entre dos partes)

class Cuenta ... feature saldo : INTEGER Extrae(cuanto : INTEGER) is require (saldo cuanto) >= SaldoMinimo do saldo := saldo - cuanto end

Eiffel
class Cuenta ... feature saldo : INTEGER PRECONDICION Clausula lgica sintcticamente separada de la implementacin del mtodo. Debe ser true para que se ejecute el Extrae(cuanto : INTEGER) is mtodo require (saldo cuanto) >= SaldoMinimo do POSTCONDICION Debe ser true saldo := saldo - cuanto despus que se evalue el mtodo ensure saldo = old saldo - cuanto end

Eiffel
Metfora del Contrato
Compromiso entre el cdigo que llama y el cdigo del mtodo

require (saldo cuanto) >= SaldoMinimo Obligacin que debe cumplir el cdigo que llama al mtodo ensure saldo = old saldo - cuanto Garanta que debe darle el mtodo al que llama al mtodo

Aserciones
Clusulas lgicas integradas a toda clase para diseo y especificacin e integradas en ejecucin a cada objeto para control
Se dividen en:

4 precondiciones 4 postcondiciones 4 invariantes

Menos impedancia entre diseo e implementacin Favorece el principio de AUTODOCUMENTACION Sirven para depuracin (si se evalan en ejecucin)

econdiciones
Tienen que cumplirse como requisito para ejecutar la rutina a la que est asociada
Push( i: INTEGER) is require not Full do ... end

ostcondiciones
Tienen que cumplirse como garanta de que el mtodo ha ejecutado bien
Push( i : INTEGER) is do ... ensure not Empty; Top = i; total = old total + 1 end

Valor antes de ejecutar el mtodo

ostcondiciones
Cmo referirse al valor de retorno de un mtodo en una postcondicin?
class List<T>{ ... Contains(x:T):BOOLEAN do ... Objeto receptor en Eiffel (this en C#) ensure result = exist y in current : x = y end Identificador especial para referirse al valor retornado por una funcin

Invariantes
Tienen que cumplirse despus de una creacin y antes y despus de trabajar con cada rutina exportable (visible) del objeto GARANTIA DE INTEGRIDAD DEL OBJETO

class Cuenta ... feature saldo : REAL ... invariant saldo > saldoMinimo end Y por qu hay que verificar si se cumplen antes de ejecutar cada mtodo si se cumplen despus de ejecutar cada mtodo?

nvariantes . . .
class Mujer class Hombre feature conyugue: Mujer ... invariant

feature conyugue: Hombre ... invariant

Cmo expresar que no haya poligamia y cmo implementar hacer los casamientos? end end

CodeContrat en .NET Delphi Prism (aserciones a Delphi like) Varias propuestas de poner aserciones a Java Implementarlas con decoradores en Python

ode Contract

Expresin lgica (Precondicin)

Texto de la excepcin que se dispara si no cumple Precondiciones. Pueden haber varias, todas tienen que cumplirse

DEM O Valor de Saldo antes de ejecutar el

mtodo

tratos a Interfaces

En la interface indica quin es la clase que pone los contratos. Esto se pone como un atributo en C# (metainformacin que se le pone en este caso a la interface)

tratos a Interfaces

Hay que indicar a qu interface se le implementan los contratos

Se pone una implementacin de cada mtodo solo con el objetivo de colocar las aserciones

tratos a Interfaces
Se refiere al valor devuelto por el mtodo o propiedad. En este caso tiene que estar contenido en la Lista

Excepticismo?
Lo mismo no se puede lograr colocando los if adecuados y disparando excepciones? Tendramos menos claridad en el cdigo. Y menos posibilidad para que las herramientas (Intellisense) nos ayuden No habra forma simple de inhibir su control sin tocar el cdigo Cmo ponrselo a una clase para que lo cumplan sus herederos o a una interface para que lo cumplan sus implementaciones

ntratos a LINQ

sa cuando no se cumple una asercin

Las aserciones sirven como especificacin (documentacin). Pueden ser monitoreadas en ejecucin. Son un balance adecuado entre especificacin e implementacin
No interpretarlo como que significa costo en eficiencia. Se debe poder decidir si esto se controla o no (por ejemplo con alguna opcin de compilacin) Quin debe tratar la excepcin? El que llama en caso de precondicin El mtodo en caso de postcondicin

Se produce una excepcin

o se trata una excepcin?

Clausula de rescate
class C ... feature F() is do ... rescue ... end ... end

Qu se puede hacer en una clausula de rescate? (Comparar con el catch de C#, C++, Java) Cdigo para solucionar el problema o reponerse de la excepcin dejando el objeto en el estado mas consistente posible. Se sale por retry (en tal caso se vuelve a ejecutar el mtodo) o porque se llega al final de la clausula sin hacer retry (en tal caso se caer en la clausula de rescate de quien llam) (Comparar con el catch de C#, C++,

a la Clase Prctica

Ponerle contratos a la interface IList Ponerle contratos a mtodos extensores de IEnumerable para LINQ

Ver ms en DotNetMana 65, Dic 2009