El diseño por contrato ( DbC ), también conocido como programación por contrato , programación por contrato y programación de diseño por contrato , es un enfoque para diseñar software .
Prescribe que los diseñadores de software deben definir especificaciones de interfaz formales , precisas y verificables para los componentes de software , que amplían la definición ordinaria de tipos de datos abstractos con precondiciones , postcondiciones e invariantes . Estas especificaciones se denominan "contratos", de acuerdo con una metáfora conceptual de las condiciones y obligaciones de los contratos comerciales.
El enfoque DbC supone que todos los componentes del cliente que invocan una operación en un componente del servidor cumplirán las condiciones previas especificadas como requeridas para esa operación.
Cuando esta suposición se considera demasiado arriesgada (como en la informática distribuida o multicanal ), se adopta el enfoque inverso , lo que significa que el componente del servidor prueba que todas las condiciones previas relevantes sean verdaderas (antes o mientras se procesa la solicitud del componente del cliente ). y responde con un mensaje de error adecuado si no.
El término fue acuñado por Bertrand Meyer en relación con su diseño del lenguaje de programación Eiffel y descrito por primera vez en varios artículos a partir de 1986 [1] [2] [3] y las dos ediciones sucesivas (1988, 1997) de su libro Object- Construcción de Software Orientado . Eiffel Software solicitó el registro de marca para Design by Contract en diciembre de 2003 y se le concedió en diciembre de 2004. [4] [5] El propietario actual de esta marca es Eiffel Software. [6] [7]
El diseño por contrato tiene sus raíces en el trabajo sobre verificación formal , especificación formal y lógica de Hoare . Las contribuciones originales incluyen:
La idea central de DbC es una metáfora de cómo los elementos de un sistema de software colaboran entre sí sobre la base de obligaciones y beneficios mutuos . La metáfora proviene de la vida empresarial, donde un "cliente" y un "proveedor" acuerdan un "contrato" que define, por ejemplo, que:
De manera similar, si el método de una clase en programación orientada a objetos proporciona una determinada funcionalidad, puede:
El contrato equivale semánticamente a una tripleta de Hoare que formaliza las obligaciones. Esto se puede resumir en las "tres preguntas" que el diseñador debe responder repetidamente en el contrato:
Muchos lenguajes de programación tienen facilidades para hacer afirmaciones como estas. Sin embargo, DbC considera que estos contratos son tan cruciales para la corrección del software que deberían ser parte del proceso de diseño. De hecho, DbC recomienda escribir primero las afirmaciones . [ cita necesaria ] Los contratos pueden escribirse mediante comentarios de código , aplicarse mediante un conjunto de pruebas o ambos, incluso si no hay soporte de lenguaje especial para los contratos.
La noción de contrato se extiende hasta el nivel del método/procedimiento; El contrato para cada método normalmente contendrá la siguiente información: [ cita necesaria ]
A las subclases en una jerarquía de herencia se les permite debilitar las condiciones previas (pero no fortalecerlas) y fortalecer las condiciones posteriores y las invariantes (pero no debilitarlas). Estas reglas se aproximan a la subtipificación conductual .
Todas las relaciones de clases son entre clases de clientes y clases de proveedores. Una clase de cliente está obligada a realizar llamadas a funciones del proveedor donde la llamada del cliente no viola el estado resultante del proveedor. Posteriormente, el proveedor está obligado a proporcionar un estado de devolución y datos que no violen los requisitos estatales del cliente.
Por ejemplo, un búfer de datos de un proveedor puede requerir que los datos estén presentes en el búfer cuando se llama a una función de eliminación. Posteriormente, el proveedor garantiza al cliente que cuando una función de eliminación finalice su trabajo, el elemento de datos se eliminará del búfer. Otros contratos de diseño son conceptos de invariante de clase . La invariante de clase garantiza (para la clase local) que el estado de la clase se mantendrá dentro de las tolerancias especificadas al final de cada ejecución de característica.
Al utilizar contratos, un proveedor no debe intentar verificar que se cumplan las condiciones del contrato, una práctica conocida como programación ofensiva ; la idea general es que el código debería "fallar gravemente", siendo la verificación del contrato la red de seguridad.
La propiedad de "fallo difícil" de DbC simplifica la depuración del comportamiento del contrato, ya que el comportamiento previsto de cada método se especifica claramente.
Este enfoque difiere sustancialmente del de la programación defensiva , donde el proveedor es responsable de descubrir qué hacer cuando se incumple una condición previa. La mayoría de las veces, el proveedor lanza una excepción para informar al cliente que la condición previa se ha roto y, en ambos casos (tanto en DbC como en programación defensiva), el cliente debe descubrir cómo responder a eso. En tales casos, DbC facilita el trabajo del proveedor.
El diseño por contrato también define criterios de corrección para un módulo de software:
El diseño por contrato también puede facilitar la reutilización del código, ya que el contrato para cada fragmento de código está completamente documentado. Los contratos de un módulo pueden considerarse como una forma de documentación de software sobre el comportamiento de ese módulo.
Las condiciones del contrato nunca deben violarse durante la ejecución de un programa libre de errores. Por lo tanto, los contratos normalmente solo se verifican en modo de depuración durante el desarrollo de software. Más adelante en el lanzamiento, las comprobaciones del contrato se desactivan para maximizar el rendimiento.
En muchos lenguajes de programación, los contratos se implementan con afirmar . Las afirmaciones se compilan de forma predeterminada en el modo de lanzamiento en C/C++, y de manera similar se desactivan en C# [8] y Java.
Iniciar el intérprete de Python con "-O" (para "optimizar") como argumento también hará que el generador de código Python no emita ningún código de bytes para las afirmaciones. [9]
Esto elimina efectivamente los costos de tiempo de ejecución de las afirmaciones en el código de producción, independientemente del número y el gasto computacional de las afirmaciones utilizadas en el desarrollo, ya que el compilador no incluirá dichas instrucciones en la producción.
El diseño por contrato no reemplaza las estrategias de prueba regulares, como las pruebas unitarias , las pruebas de integración y las pruebas de sistemas . Más bien, complementa las pruebas externas con autopruebas internas que pueden activarse tanto para pruebas aisladas como en código de producción durante una fase de prueba.
La ventaja de las autopruebas internas es que pueden detectar errores antes de que se manifiesten como resultados no válidos observados por el cliente. Esto conduce a una detección de errores más temprana y específica.
El uso de afirmaciones puede considerarse como una forma de oráculo de prueba , una forma de probar el diseño mediante la implementación del contrato.
Los lenguajes que implementan la mayoría de las funciones de DbC de forma nativa incluyen:
Además, la combinación de métodos estándar en el Common Lisp Object System tiene los calificadores de método :before, :aftery :aroundque permiten escribir contratos como métodos auxiliares, entre otros usos.
Se han desarrollado varias bibliotecas, preprocesadores y otras herramientas para lenguajes de programación existentes sin diseño nativo mediante soporte por contrato:
{{cite web}}: CS1 maint: archived copy as title (link)pag. 2