Construccin de Software Correcto:

Diseo por Contrato

Agenda

Introduccin
Calidad de software, atributos de calidad, tcnicas O-O,

Conceptos Fundamentales
Correccin relativa, frmulas de correccin, pre y poscondiciones,

Establecimiento de Contratos
Significado de un contrato, no redundancia, trabajo con aserciones,

Agenda

Clases Correctas
Invariantes de clases, la vida de un objeto, validez del invariante,

Diseo por Contrato y Herencia

Herencia, reglas bsicas, pre y poscondiciones + herencia,

Ingeniera y calidad de software

El software como los edificios, automviles y telfonos celulares es un producto de ingeniera Ingeniera de software es la produccin de software de calidad

Introduccin

Ingeniera y calidad de software

Introduccin

conjunto de tcnicas que tiene el potencial para mejorar significativamente la calidad de los productos de software Rpido, confiable, fcil de usar, legible, modular, estructu-rado, etc., describen dos tipos diferentes de cualidades

Orientacin a objetos (O-O) es un

Atributos de calidad externos e internos del software

Atributos externos
p.ej., rapidez, facilidad de uso su presencia o ausencia en un producto de software puede ser detectada por los usuarios del producto

Atributos de calidad externos e internos del software

Atributos internos
p.ej., modularidad, legibilidad son percibidos slo por profe-sionales de la computacin con acceso al texto del software Al final, slo importan los atributos externos Pero la clave para lograrlos est en los atributos internos

Para que los usuarios disfruten de los atributos visibles, los desarrolladores debemos aplicar tcnicas internas que aseguren los atributos escondidos

Los atributos de calidad externos

Correccin
Hace lo que tiene que hacer

Robustez
Acta bien en condiciones anormales

Extensibilidad
Acepta cambios de especificacin

Reusabilidad
til para muchos productos

Compatibilidad
Combinable con otros productos

Los atributos de calidad externos

Eficiencia
Exige lo mnimo al hardware

Transportabilidad
til en diversos entornos

Facilidad de uso
Para diversos tipos de usuarios

Funcionalidad
Posibilidades ofrecidas

Oportunidad
Entregable a tiempo

La O-O proporciona tcnicas para alcanzar calidad

Los conceptos bsicos de la O-Oclase, objeto, tipos parametrizadoshacen posible la extensibilidad, reusabi-lidad, y compatibilidad (no son nuestro tema hoy) El concepto de diseo por contrato y las tcnicas de aser-ciones y manejo de excepciones hacen posible la correccin y robustez, es decir, la confiabilidad

La O-O proporciona tcnicas para alcanzar calidad

El concepto clave es diseo por contrato:

la relacin entre una clase y sus clientes es un acuerdo formal que expresa los derechos y obligaciones de cada parte

El manejo de excepciones tampoco es nuestro tema hoy

La correccin de software es relativa

Conceptos Fundamentales
Una pieza de software no es correcta o incorrecta per se

Correccin de software es la consistencia

entre la imple-mentacin del software y su

especificacinuna descripcin precisa de lo

que se supone que el software hace

La correccin de software es relativa

Nos proponemos incluir la especificacin junto con la implementacin en el texto del software:
Producimos software correcto desde el principio

Conceptos Fundamentales

porque est diseado para ser correcto

Entendemos mejor el problema y sus posibles soluciones Facilitamos la tarea de documentacin del software Proporcionamos una base para el testing y debugging sistemticos

Expresin de especificaciones: Frmulas de correccin

Una frmula de correccin es una expresin matemtica de la forma {P} A {Q}:
A es una operacin (p.ej., una instruccin o el cuerpo de una rutina) P y Q son aserciones propiedades de las entidades involucradas P es llamada la precondicin Q es llamada la poscondicin

Expresin de especificaciones: Frmulas de correccin

La frmula {P} A {Q} denota la siguiente propiedad,
que puede o no ser verdadera:
Cualquier ejecucin de A, a partir de un estado en que P es verdadera, terminar en un estado en que Q es verdadera P.ej., {x 9} x = x + 5 {x 13} La reflexin sobre correccin de software ser ahora sobre una pieza de software A, una precondicin P, y una poscondicin Q

Inclusin de aserciones en el texto del software

Tradicionalmente, un programa define slo las operaciones que le ordenamos ejecutar a un computador (el cmo)

Nosotros consideraremos la descripcin del

propsito del programa (el qu) tambin como

parte del programa

Inclusin de aserciones en el texto del software

Para expresar aserciones:

la especificacin usaremos

Definiremos una pre y una poscondicin para cada rutina de una clase (a continuacin) Definiremos un invariante para cada clase (tarea) Nuestro lenguaje de aserciones tiene slo parte del poder del clculo de predicados (la nocin matemtica ms cercana) Nuestras aserciones sern simplemente expresiones de Boole

Especificacin de rutinas usando pre y poscondiciones

Una rutina de una clase debe realizar una tarea til

que es necesario expresar en forma precisa usando aserciones:
La precondicin establece la propiedad que debe ser verdadera cada vez que llamamos a la rutina, antes de su ejecucin La poscondicin establece la propiedad del estado resultante que la rutina garantiza cuando retorna,

suponiendo que fue llamada con la precondicin satisfecha

Especificacin de rutinas usando pre y poscondiciones

P.ej., las rutinas push, pop, e item de la clase STACK: pop e item son aplicables slo si el nmero de elementos en el stack es mayor que 0 precondicin

push aumenta el nmero de elementos en 1, y pop

lo disminuye en 1 poscondiciones

Significado de un contrato
Al definir una precondicin pre y una poscondicin pos para una rutina r

Establecimiento de Contratos

Se establece un contrato que vincula a r proveedor de un serviciocon los que llaman a rclientes de ese servicio La clase de r le dice a sus clientes: Si ustedes prometen llamar a r con pre verdadera, yo prometo producir un estado final en que pos sea verdadera

Significado de un contrato
El contrato trae obligaciones y beneficios para ambos: pre es una obligacin para el cliente y un beneficio para el proveedorla condicin para que una llamada sea legtima

Establecimiento de Contratos

pos es un beneficio para el cliente y una obligacin

para el proveedorla condicin garantizada por r al retornar

Ejemplo: Beneficios y obligaciones frente a la llamada s.push(x)

Perspectiva del cliente
Beneficios (derivados de la poscondicin): recibe s actualizado s no est vaco, x est en el tope, count aument en 1 Obligacin (derivada de la

Perspectiva del proveedor

Beneficio (derivado de la precondicin): procesamiento ms simple gracias a la suposicin de que s no est lleno Obligaciones (derivadas de la poscondicin): debe actualizar s aumentar count en 1, poner a x en el tope, establecer que s no est vaco

pre-condicin): la llamada
puede hacerse slo si s no est lleno

Garantizar ms verificando menos: El principio de no redundancia

La precondicin es un beneficio para el proveedor
Si la precondicin (la obliga-cin del cliente) no se cumple, la clase (en particular, la rutina) no est obligada por la poscondicin El autor de la clase, cuando escribe el cuerpo de la rutina, puede suponer que las restricciones representadas por la precondicin se cumplen

Garantizar ms verificando menos: El principio de no redundancia

Principio de no redundancia
El cuerpo de una rutina no debe verificar la precondicin de sta Las verificaciones redundantes son dainas, mirando un sistema de muchas clases con muchas rutinas en que el criterio crucial es la simplicidad Para cada condicin en un contrato, hay que especificar quin es responsable de que se cumpla: el cliente o el proveedor

Lo que las aserciones no son

Las aserciones no son un me-canismo verificador de inputs
Los contratos son entre rutinas

Las aserciones no son estructuras de controlo tcnicas para manejar casos especiales
La violacin de una asercin (precondicin / poscondicin) en tiempo de ejecucin es la manifestacin de un bug en el software (cliente / proveedor)

Incluir la precondicin input > 0 en una rutina que recibe input interactivamente sera slo una expresin de deseo, no una tcnica de confiabilidad
Hay que validar todo objeto recibido desde el exterior lo ms cercanamente posible a su fuente, p.ej., usando filtros

Trabajando con aserciones

Lo imperativo y lo aplicativo
Las instrucciones son prescripti-vas (el cmo) e imperativas (comandan cambios) Las aserciones son descriptivas (el qu) y aplicativas (aplican derivaciones)

Cumplir la condicin de operacin de una rutina debe ser responsabilidad de slo uno (no redundancia) de
Los clientesdiseo exigente La rutinadiseo tolerante

Exportacin de atributos
Todo atributo que aparece en la precondicin de una rutina debe estar disponible para todos los clientes para los cuales la rutina est disponible

Toda precondicin exigente debe satisfacer dos requisitos

Aparece en la documentacin oficial entregada a los clientes Su necesidad se justifica a base de la especificacin nicamente

Invariantes de clases
Las pre y poscondiciones describen las propiedades de rutinas individuales Cmo expresar propiedades globales de las instancias de una clase que deben ser preservadas por todas las rutinas? El invariante de una clase

Clases Correctas

es un conjunto de aserciones que se incluye en el texto de la clase captura las propiedades semnticas y las restricciones de integridad ms profundas que caracterizan a la clase

La vida de un objeto de una clase T

Al comienzo, el objeto (la instancia) no existe

El objeto es engendrado mediante una instruccin de creacin, que puede o no llamar a una rutina de creacin definida en T, y alcanza su primer estado en la vida:
El objeto es creado inicialmente con valores por defecto para sus atributos Si se llam a una rutina de creacin, sta puede asignar otros valores iniciales a los atributos del objeto

La vida de un objeto de una clase T

Luego, a travs de alguna referencia a, los clientes de T usan el objeto, secuencialmente, aplicando operaciones de la forma af(), en que f es un atributo o una rutina de T

Cundo debe ser verdadero el invariante de una clase?

Toda instancia a de una clase T debe satisfacer el invarian-te de T en todo momento en el cual el estado de a es obser-vable desde el exterior:
El estado que resulta al crearse la instancia a

Los estados inmediatamente antes e inmediatamente despus de una invocacin ar() ejecutada por un cliente, en que r es una rutina de T

Es aceptable que una rutina de T destruya el invariante de T durante su ejecucin, siempre que lo restablezca antes de terminar su ejecucin

Relacin entre el invariante y las pre y poscondiciones de las rutinas

Debemos considerar el invariante I de una clase T como anded implcitamente a la pre y a la poscondicin de cada rutina exportada de T; por qu no explcitamente?
Incluir I explcitamente en las pre y poscondiciones complicara el texto de las rutinas y perderamos el significado ms profundo de I : trasciende a las rutinas individuales se aplica a T como un todo

Relacin entre el invariante y las pre y poscondiciones de las rutinas

I se aplica no slo a las rutinas actuales de T, sino a cualquiera que pudiera agregarse despus: I controla la evolucin futura de T

Los invariantes son propiedades que cambian mucho menos frecuentemente que los atributos y las rutinas de las clases

Hacia una definicin de clase correcta

Efecto del invariante sobre los contratos
El invariante de una clase afecta a todos los contratos entre las rutinas de la clase y un cliente Para una rutina de una clase, sean C el cuerpo de la rutina, pre y pos su pre y su poscondicin, e I el invariante de la clase El requisito de correccin de la rutina es { I and pre} C { I and pos}

El concepto de clase correcta

Una clase es correcta o incorrecta slo con respecto a una especificacin Las pre y poscondiciones de las rutinas y el invariante son una forma de incluir la especificacin en el texto de la clase Una clase es correcta si y slo si su implementacinlos cuerpos de las rutinases consistente con el invariante y con las pre y poscondiciones

Definicin formal de clase correcta

Sean
T una clase, I su invariante, def la asercin que expresa que los atributos de T tienen sus valores por defecto, r cualquier rutina de T, Cuerpor el cuerpo de r, y prer(xr) y posr(xr) su pre y su poscondicin, en que xr denota los argumentos posibles de r

T es correcta con respecto a sus aserciones si y

slo si
Para cualquier conjunto vlido de argumentos xp de una rutina de creacin p: { def and prep(xp)} Cuerpop { posp(xp) and I}

Definicin formal de clase correcta

Para cualesquiera rutina exportada r y conjunto de argumentos vlidos xr : { prer(xr) and I} Cuerpor { posr(xr) and I}

El concepto de herencia en O-O

La herencia
es creacin por imitacin, refinacin, y combinacin permite lograr los objetivos de reusabilidad y extensibilidad La clase POLIGONO define, entre otros un atributo num_vertices una funcin perimetro La clase RECTANGULO, que hereda de POLIGONO,

Diseo por Contrato y Herencia

Ejemplo

Una clase B puede heredar de otra A (u otras A, C, )

B puede ser una extensin o especializacin de A (o una combinacin de A, C, ) podemos ver cualquier instancia de B tambin como una instancia de A

hereda todos los atributos y funciones de POLIGONO puede redefinir perimetro, establecer en su invariante que num_vertices = 4, definir un nuevo atributo

diagonal

Los conceptos de polimorfismo y asociacin dinmica en O-O

Polimorfismo es la capacidad de tomar varias formas
Una entidad p de clase P puede ser vinculada, en ejecucin, a entidades q, r de clases Q, R ( P) p es una entidad polimrfica Q, R deben ser herederas de P Esta vinculacin (polimrfica) puede hacerse por asignacin (polimrfica) paso de argumentos Podemos tener estructuras de

Asociacin dinmica
Qu pasa cuando una rutina con ms de una versin por herencia es aplicada a una entidad polimrfica? En pperimetro, p puede haber sido declarado de tipo POLIGONO, pero al momento de la llamada estar vinculada a un objeto de tipo RECTANGULO La forma dinmica del objeto vinculado a la entidad polimrfica determina cul versin de la rutina hay que aplicar

datos polimrficas

Reglas fundamentales
Aserciones y herencia
En una clase descendiente, todas las aserciones de los ancestros (pre y poscondiciones de rutinas, e invariantes de clases) son aplicables

Diseo por contrato bsico

Sean A una clase y r una de sus rutinas con precondicin y poscondicin Sea B una clase cliente de A, que incluye la declaracin a: A y la llamada ar Si B asegura el cumplimiento de antes de hacer la llamada ar p.ej., if () ar entonces tiene derecho a esperar al terminar la ejecucin de r

Regla de los invariantes de los padres

Los invariantes de todos los padres de una clase son aplicables a la propia clase, agregndose a travs de un and then

Pre y poscondiciones y asociacin dinmica

Incluyendo herencia, etc.:
Sea A una clase que hereda de A y redeclara r, cambiando en y en En la llamada ar, a podra ahora por polimorfismo ser de tipo A, sin que B lo sepa La asociacin dinmica implica que la llamada a r usar la versin de r redeclarada en A Cliente (B) y proveedor (r en A) tienen ahora visiones distintas del contrato

El proveedor podra engaar al cliente, que garantiza y espera , de dos formas:

Requerir ms que la precondicin original ( ) Asegurar menos que la poscondicin original ( )

Cmo ser honestos: Regla de redeclaracin de aserciones

La redeclaracin de una rutina puede mantener las aserciones originales, y tambin puede reemplazar:
la precondicin por otra ms dbil (aceptar ms casos) la poscondicin por otra ms fuerte (producir ms que lo prometido)

Las aserciones de una rutina especifican:

la semntica esencial de la rutina, aplicable no slo a la propia rutina sino a cualquier redeclaracin en descendientes un rango de comportamientos aceptables para la rutina y sus redeclaraciones