Machine Translated by Google

yo

Aplicando “Diseño por

contrato ”
Bertrand Meyer
Ingeniería de software interactivo

Las técnicas orientadas a objetos ganan cada vez más terreno en el mundo del desarrollo de
software . Los usuarios y posibles usuarios de estas técnicas están clamando cada vez más
por una “metodología” de construcción de software orientada a objetos , o al menos por
algunas pautas metodológicas. Este artículo presenta dichos lineamientos, cuyo objetivo principal es
ayudar a mejorar la confiabilidad de los sistemas de software. La confiabilidad se define aquí como la
combinación de corrección y robustez o. más prosaicamente, como la ausencia de errores.

Todos los que desarrollan sistemas de software. o simplemente usándolos, sabe cuán apremiante es
esta cuestión de confiabilidad en el estado actual de la ingeniería de software. Sin embargo, la literatura
en rápido crecimiento sobre el análisis orientado a objetos. diseño. y la programación incluye muy pocas
contribuciones sobre cómo hacer que el software orientado a objetos sea más confiable. Esto es
sorprendente y lamentable, ya que al menos tres razones justifican dedicar especial atención a la
confiabilidad en el contexto del desarrollo orientado a objetos:

La piedra angular de la tecnología orientada a objetos es la reutilización. Para los componentes

reutilizables, que pueden usarse en miles de aplicaciones diferentes, las posibles consecuencias de
un comportamiento incorrecto son incluso más graves que para los desarrollos específicos de
aplicaciones.
Los defensores de los métodos orientados a objetos hacen fuertes afirmaciones sobre sus beneficios.

..
El enfoque orientado a objetos, basado en la teoría de tipos de datos abstractos, proporciona un
La confiabilidad es aún más marco particularmente apropiado para discutir y hacer cumplir la confiabilidad.

importante en la
programación orientada a Las técnicas pragmáticas presentadas en este artículo, si bien ciertamente no brindan formas infalibles
para garantizar la confiabilidad, pueden ayudar considerablemente a lograr este objetivo.
objetos que en cualquier
Se basan en la teoría del diseño por construcción. que subyace al diseño del lenguaje de análisis, diseño
otra parte* Este artículo y programación de Eiffel y de las bibliotecas de apoyo, de las que se extraerán una serie de ejemplos.

muestra cómo reducir los Las contribuciones del trabajo informado a continuación incluyen

errores mediante la creación un conjunto coherente de principios nrrthocfológicos que ayuden a producir software correcto y

de componentes de software robusto ; un enfoque sistemático del delicado problema de cómo tratar los casos anormales. que
conduce a un mecanismo de manejo de excepciones simple y poderoso ; y
sobre la base de contratos cuidadosamente diseñados.

Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google
una mejor comprensión de la herencia y de
las técnicas asociadas (redeclaración,
polimorfismo y enlace dinámico) a través de
la noción de subcontrato, lo que permite un
enfoque sistemático para usar estos
mecanismos poderosos pero a veces
peligrosos.
La mayoría de los conceptos presentados aquí
han aparecido en otros lugares. Fueron presentados
en el libro Construcción de software orientada a
objetos'; y se presentó una exposición más
completa en un capítulo de libro reciente, del cual
se ha adaptado este artículo. Más profundamente,
este trabajo encuentra su raíz en trabajos anteriores
sobre programas sistemáticos y tipos de datos
abstractos. hX Este artículo se enfoca en las ideas
centrales, presentándolas de manera concisa para
que los desarrolladores las apliquen directamente.
Revisión de la programación
defensiva
Los libros de texto de ingeniería de software y
metodología de programación que analizan la
confiabilidad a menudo enfatizan la técnica
conocida como programación defensiva, que dirige
a los desarrolladores a proteger cada módulo de
software contra las hondas y flechas de la fortuna
escandalosa. En particular, esto alienta a los
programadores a incluir tantas comprobaciones
como sea posible, incluso si son redundantes con
las comprobaciones realizadas por las personas
que llaman. Inclúyalos de todos modos, dice el
consejo; si no ayudan. al menos no harán daño.
Este enfoque sugiere que las rutinas deben ser
lo más generales posible. Una rutina parcial (una
que funciona solo si la persona que llama garantiza
ciertas condiciones restrictivas en el momento de
la llamada) se considera peligrosa porque puede
producir consecuencias no deseadas si la persona
que llama no cumple con las reglas.
Esta técnica, sin embargo, a menudo frustra
sus propios propósitos. Agregar código
posiblemente redundante "por si acaso" solo
contribuye a la complejidad del software, el peor
obstáculo para la calidad del software en general.
y a la fiabilidad en particular. El resultado de esta
verificación a ciegas es simplemente introducir más
software. por lo tanto, más fuentes de cosas que
podrían salir mal en el momento de la ejecución,
por lo tanto, la necesidad de más comprobaciones,
y así hasta el infinito. Tan ciego y a menudo redun
la verificación de dant causa gran parte de la com
octubre de 1992
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
complejidad y dificultad de manejo que a menudo
caracteriza al software.
Obtener y garantizar la confiabilidad requiere
un enfoque más sistemático.
En particular, los elementos de software deben
considerarse implementaciones destinadas a
satisfacer especificaciones bien entendidas, no
como textos ejecutables arbitrarios. Aquí es donde
entra la teoría del contrato.
La noción de contrato
Suponga que está escribiendo una unidad de
programa que implementa una tarea que se
realizará en tiempo de ejecución. A menos que la
tarea sea trivial, implica una serie de subtareas.
Por ejemplo, podría aparecer como
mi tarea es
hacer
subtarea, ;
subtarea2 ;
...
subtarea,, ;
final
una forma que es suficiente para esta discusión.
aunque en muchos casos la estructura de control
que vincula las diversas subtareas es menos
simple que la mera secuencia que se muestra aquí.
Para cada una de estas subtareas, puede
escribir la solución correspondiente en línea como
parte del cuerpo de my-task o depender de una
llamada a otra unidad. La decisión es una
compensación típica del diseño: demasiadas
llamadas provocan la fragmentación del texto del
software: muy pocas dan como resultado unidades
individuales demasiado complejas.
Suponga que decide utilizar una llamada de
rutina para una de las subtareas. Esto es similar a
la situación encontrada en ev
vida cotidiana cuando decide subcontratar para
una determinada tarea (humana) en lugar de
hacerlo usted mismo. Por ejemplo. si estás en
París y quieres un urgente
Tabla 1. Ejemplo de contrato.
Fiesta Obligaciones
Cliente Entregar carta o paquete de no más de
5 kgs. cada dimensión no más de 2 metros.
Paga 100 francos.
Proveedor Entrega el paquete al destinatario en
cuatro horas o menos.
carta o paquete entregado en otra dirección de
París, puede optar por entregarlo usted mismo o
contratar un servicio de mensajería.
Dos propiedades principales caracterizan los
contratos humanos que involucran a dos partes:
Cada parte espera algunos beneficios del
contrato y está dispuesta a incurrir en algunas
obligaciones para obtenerlos.
Estos beneficios y obligaciones son
documentado en un documento de contrato.
La Tabla 1 muestra un cuadro imaginario de
obligaciones y beneficios para el servicio de
mensajería del ejemplo.
Un documento de contrato protege a ambas
partes:
Protege al cliente especificando cuánto se
debe hacer: El cliente tiene derecho a recibir un
determinado resultado.
Protege al contratista al especificar qué tan
poco es aceptable: El contratista no debe ser
responsable por no realizar tareas fuera del
alcance especificado.
Como lo demuestra este ejemplo, lo que es una
obligación para una parte suele ser un beneficio
para la otra.
Este ejemplo también sugiere una observación
algo más sutil, que es importante en la siguiente
discusión (y en el estudio de la aplicación de estas
ideas a la computación concurrente). Si el contrato
es exhaustivo, cada entrada de "obligación"
también describe en cierto sentido un "beneficio"
al establecer que las restricciones dadas son las
únicas relevantes. Por ejemplo, la entrada de
obligación para el cliente indica que un cliente que
satisface todas las restricciones enumeradas tiene
derecho a los beneficios que se muestran en la
siguiente entrada. Esta es la regla de No hay
cláusulas ocultas: con un contrato completamente
detallado entre partes honestas, no hay requisitos
Beneficios
Obtenga el paquete entregado
al destinatario en cuatro horas o
menos.
No hay necesidad de tratar con
entregas demasiado grandes,
demasiado pesadas o sin pagar.
41
Machine Translated by Google
yo
distintas de las obligaciones oficiales
del contrato pueden ser impuestas al nombre-rutina (declaraciones de argumento) es
cliente como condición para obtener
los beneficios oficiales del contrato.
El principio de Cláusulas No Ocultas
no nos impide incluir referencias.
implícito o explícito, a reglas que no
forman parte físicamente del contrato.
Por ejemplo, las reglas generales,
como las leyes pertinentes y las Figura 1. Una rutina equipada con afirmaciones.
prácticas comerciales comunes, se
consideran implícitamente como parte
de todo contrato de cierto tipo. aunque put-child (nuevo: NODO) es
no se repita explícitamente en el texto
de cada contrato. Se aplican tanto al
cliente como al proveedor y conducirán
más adelante a la noción de invariante
de clase.
Afirmaciones:
Figura 2. Aserciones para la rutina de inserción del niño.
Contratación de
software
No es difícil ver cómo se aplican las ideas
anteriores a la construcción de software. Si la
ejecución de una determinada tarea se basa en una
llamada de rutina para manejar uno de
sus subtareas, es necesario especificar la relación
entre el cliente (el llamador) y el proveedor (la rutina
llamada) con la mayor precisión posible. Los
mecanismos para expresar tales condiciones se
denominan aserciones. Algunas afirmaciones.
llamadas condiciones previas y condiciones
posteriores. aplicar a rutinas individuales. Otros, los
invariantes de clase, restringen todas las rutinas de
una clase dada y se discutirán más adelante.
Es importante incluir las condiciones previas y
posteriores como parte de las declaraciones de rutina
(ver Figura 1 ).
En esta notación de Eiffel, las cláusulas Requerir
y Asegurar (así como el comentario del encabezado)
son opcionales. Introducen afirmaciones ,
respectivamente la precondición y la poscondición.
Cada
Tabla 2. El contrato put-child .
~~~~~~~
Fiesta Obligaciones
Cliente Use como argumento una referencia, digamos nuevo. a un
objeto de nodo existente.
Proveedor Inserte un nuevo nodo según sea necesario.
42
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
-- Comentario de cabecera
requerir
Condición previa
hacer
Cuerpo de rutina , Le. instrucciones
ensoltado
poscondición
final
-- Agregar nuevo a los elementos secundarios del nodo
actual requiere nuevo / = Void
hacer
... Algoritmo de inserción ...
asegurar
nuevo.padre = actual;
recuento de niños = recuento de niños anterior + 1
fin - poner-niño
afirmación es una lista de expresiones booleanas,
separadas por punto y coma; aquí, un punto y coma
es equivalente a un booleano “y”, pero permite la
identificación individual de las cláusulas de aserción.
La precondición expresa requisitos que toda
llamada debe satisfacer para que sea correcta; la
condición posterior expresa propiedades que se
garantizan a cambio mediante la ejecución de la
llamada.
Una cláusula de condición previa faltante es
equivalente a la cláusula Require True, y una
condición posterior faltante a la cláusula En sure
True. La afirmación Verdadera es la menos
comprometedora de todas las afirmaciones posibles.
Cualquier estado posible de la computación lo
satisfará .
Considere, por ejemplo. en una clase ÁRBOL que
describe los nodos del árbol. una rutinaput-child para
agregar un nuevo hijo a un nodo de árbol Currmr.
Se puede acceder al hijo a través de una referencia,
que debe adjuntarse a un objeto de nodo existente.
La Tabla 2 expresa informalmente el contrato.
Beneficios
Obtenga un árbol actualizado donde el nodo actual tiene un
hijo más que antes; new ahora tiene Current como padre.
No es necesario hacer nada si el argumento no está adjunto a
un objeto.
Este es el contrato impuesto por
put-child a cualquier posible llamante.
Contiene la información más importante
que se puede dar sobre la rutina: lo
que cada una de las partes en el
contrato debe garantizar para una
correcta llamada, ya qué tiene derecho
cada parte a cambio. Debido a que
esta información es tan crucial para la
construcción de sistemas confiables
usando tales rutinas, debería ser una
parte formal del texto de la rutina (vea
la Figura 2).
Unos pocos detalles más sobre las
reglas de la programación orientada a
objetos tal como se incorporan en
Eiffel debería ayudar a dejar este
ejemplo completamente claro:
Una referencia como nueva es
nula (no adjunta a ningún objeto) o
adjunta a un objeto. En el primer caso,
es igual al valor Void. Aquí la condición
previa expresa que la referencia nueva
no debe ser nula, como se establece
informalmente por la entrada correspondiente en la
Tabla 2.
De acuerdo con los principios orientados a
objetos de Eiffel, la rutina aparecerá en el texto de
una clase que describa árboles o nodos de árboles.
Es por eso que no necesita un argumento que
represente el nodo al que la rutina agregará la
referencia new como hijo; todas las rutinas de la
clase son relativas a un nodo de árbol típico, la
"instancia actual" de la clase.
En una llamada específica como some -nodeput-
child (x), el valor anterior al punto, aquí some-node,
sirve como instancia actual.
*En el texto de la clase, el nombre predefinido
Actual sirve, si es necesario, para referirse a la
instancia actual.
Aquí se usa en la poscondición.
La notación Old child-count, que aparece en
la poscondición de put-child, denota el valor de child-
count capturado en la entrada a una llamada en
particular. En
COMPUTADORA
Machine Translated by Google
yo
En otras palabras, la segunda cláusula de
si nuevo = Vacío
la poscondición expresa que la rutina debe
aumentar el número de niños en uno. La entonces ... Encárguese del caso especial ...
más
construcción Old puede aparecer solo en ... Cuide el caso estándar ...
una condición posterior de rutina.
final
Figura 3. Manejo de un caso especial.
El papel de
las afirmaciones las aserciones son monitoreadas en tiempo de
ejecución, dependiendo de los deseos del
programador. Pero esta no es una pregunta crucial en este punto.
Es posible que se esté preguntando qué sucede si una de estas condiciones falla . El objetivo principal
de esta discusión es encontrar formas de escribir software confiable
Estos ~ que
sistemas quesefuncionan.
satisfaga durante la ejecución.
pregunta será respondida por si sucede cuando no funcionan. Alabama
Otras fuentes
Una de las dos principales fuentes de inspiración para este trabajo es la
investigación sobre la demostración de programas y la construcción
sistemática de programas iniciada por Floyd,' Hoare,2 y Dijk~tra.~ Otro
trabajo bien conocido sobre la aplicación de métodos de prueba a la
construcción de software incluye contribuciones de Gries4 y Milk5 La otra
gran influencia es la teoría de los tipos de datos abstractos (ver referencias
en el cuerpo del artículo).
El uso de afirmaciones en un lenguaje orientado a objetos y el enfoque
de la herencia presentado aquí (basado en la noción de subcontratación)
parecen originales de Eiffel. El modelo de manejo de excepciones y su
implementación también se encuentran entre las contribuciones de Eiffel.
Estos mecanismos, y el razonamiento que los condujo a ellos, se discuten
en detalle en las referencias 1 y 2 de la bibliografía principal al final del
artículo.
La noción de invariante de clase proviene directamente del invariante de
datos de Hoare.6 Los invariantes, así como otras afirmaciones, también
juegan un papel importante en el método de especificación de software
VDM, como lo describe Jones.7 La transposición de invariantes de datos al
desarrollo de software orientado a objetos, en la forma de invariantes de
clase, parece ser nueva con Eiffel.
Los lenguajes de investigación no orientados a objetos que admiten
aserciones han incluido Euclids y Alphards; ver también el lenguaje de
especificación basado en Ada Anna.lo CLU, citado en el texto, incluye
afirmaciones no formales.
La visión de los programas como mecanismos para computar
funciones es central en el método VDM mencionado.
Otra visión de las excepciones se puede encontrar en Cristian.”
La noción de Eiffel de una cláusula de rescate tiene cierta semejanza con
los bloques de recuperación de Randell,12 pero el espíritu y los objetivos
son diferentes. Los bloques de recuperación, tal como los define Randell,
son implementaciones alternativas del objetivo original de una rutina, que
se utilizarán cuando la implementación inicial no logre este objetivo. Por el
contrario, una cláusula de rescate no intenta continuar con los asuntos
oficiales de la rutina; simplemente arregla las cosas llevando el objeto a un
estado estable. Cualquier reintento utiliza la implementación original
nuevamente. Además, los bloques de recuperación requieren que se
restablezca el estado inicial del sistema antes de intentar una implementación
alternativa después de una falla. Esto parece imposible de implementar en
cualquier entorno práctico para el cual la eficiencia es de alguna preocupación.
Las cláusulas de rescate de Eiffel no requieren tal preservación del estado;
la única regla es que la cláusula de rescate debe restaurar la invariante de
clase y, si se intenta la reanudación, la condición previa de rutina.
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
aunque significativa en la práctica, llega
sólo después de lograr ese objetivo más
fundamental.
Otra forma de expresar esta observación
es notar que las aserciones no describen
casos especiales sino esperados que
requieren un tratamiento especial. En otras
palabras, las afirmaciones anteriores no
son una
manera de describir (por ejemplo) el manejo de
argumentos void para put-child. Si quisiéramos
tratar los argumentos nulos como un caso aceptable
(aunque especial), no lo manejaríamos a través de
La pregunta de qué afirmaciones sino a través de estructuras de control
condicional estándar (ver Figura 3).
La noción de cláusula de rescate en realidad se derivó de una noción
formal correspondiente de función sustituta, también llamada doppelgiinger,
que apareció en el método de especificación y el lenguaje M, es un sucesor
directo del 2 1ang ~age original de Abrial . Eiffel, M era un lenguaje de
especificación formal, no un lenguaje ejecutable. Las funciones en una
especificación M pueden ser parciales. Un sustituto está asociado con una
función parcial y sirve como respaldo para los argumentos que no pertenecen
al dominio de esa función.
Referencias
1. RW Floyd, “Asignación de significados a los programas”, Pm. Soy. Matemáticas.
Soc. Síntoma en Matemáticas Aplicadas, vol. 19, JT Schwartz, ed..
Sociedad Matemática Americana, Providence, RI, 1967, pp. 19-31.
2. CAR Hoare, "Una base axiomática para la programación de computadoras",
Com. ACM, vol. 12, No. 10, octubre de 1969, págs. 576-580, 583.
3. EW Dijkstra, Una disciplina de programación, Prentice Hall, Englewood
Cliffs, NJ, 1976.
4. D. Gries. The Science of Programming, Springer-Verlag, Berlín y
Nueva York, 1981.
5. HD Mills et al., Principios de programación informática: un enfoque
matemático, Allyn y Bacon, Boston, 1987.
6. CAR Hoare, 'Prueba de corrección de representaciones de datos'
Acta Informática, vol. 1, núm. 4, 1972, págs. 271-281.
7. CB Jones, Desarrollo sistemático de software mediante VDM, Prentice
Hall, Englewood Clis, NJ, 1986.
8. BW Lampson et al., 'Informe sobre el lenguaje de programación
Euclid', SlGPlan Notices, vol. 12, No. 2, febrero de 1977, págs. 1-79.
9. Mary Shaw et al., Alphard: form and Content, Springer-Verlag, Berlín
y Nueva York, 1981.
10 D. Luckham y FW von Henke, 'An Overview of Anna, a Specification
Language for Ada', /E€ Software, vol. 2, No. 2, marzo de 1985, págs.
9-22.
11 F. Cristian, Y)n Excepciones, fallas y errores”, Tecnología y ciencia de la
informática, vol. 4, No. 4, julio-agosto. 1985.
12 B. Randell, “Estructura del sistema para tolerancia a fallas de software”, /
E€ € Trans. Ing. de software, vol. SE-I, No. 2, junio de 1975, pp. 220-232.
13 B. Meyer, 'M: Un método de descripción del sistema ”, Tech. Informe
TRCS85-15. Departamento de Ciencias de la Computación, Univ. de
California, Santa Bárbara, 1986.
14 J.4. Abrial, SA Schuman y B. Meyer, “A Specification Language”, en
On the Construction of Programs, R. McNaughten y RC McKeag, eds.,
Cambridge University Press, Inglaterra, 1980.
Machine Translated by Google
Las afirmaciones (aquí la
condición previa) son otra cosa:
formas de describir las condiciones
en las que funcionarán los elementos
del software y las condiciones.
devolver. Poniendo la condición new /
= Void en la condición previa, la
hacemos parte de la especificación de la rutina; la
última forma mostrada (con el If) significaría que hemos
cambiado esa especificación, ampliándola para incluir
el caso especial new = Void como aceptable.
Como consecuencia. cualquier violación en
tiempo de ejecución de una aserción no es un caso
especial sino siempre la manifestación de un error
de software. Para ser precisos:
Una violación de condición previa indica un
error en el cliente (persona que llama). La persona
que llama no observó las condiciones impuestas a
las llamadas correctas.
Una violación de la condición posterior es un
error en el proveedor (rutina). La rutina no cumplió
sus promesas.
Observaciones
sobre contratos de software
En la Tabla 2, la entrada de abajo a la derecha
es particularmente notable. Si la condición previa
no se cumple, la rutina no está obligada a hacer
nada, como una empresa de entrega de correo
que recibe un paquete que no cumple con las
especificaciones. Esto significa que el cuerpo de la
rutina no debe tener la forma mencionada
anteriormente:
si nuevo = Vacío entonces
...
más
...
final
Usar tal construcción anularía el propósito de
tener una condición previa (cláusula Requerir).
Esta es una regla absoluta: O tiene la condición
en Require, o la tiene en una instrucción If en el
cuerpo de la rutina, pero nunca en ambos.
Este principio es exactamente lo contrario de la
idea de programación defensiva, ya que dirige a
los programadores a evitar pruebas redundantes.
Tal enfoque es posible y fructífero porque el uso
de aserciones anima a escribir software para
explicar las condiciones de consistencia que
podrían salir mal en el tiempo de ejecución.
Entonces en lugar de
44
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
Izquierda I = ierpliss vacío (izqarent =
actual); right I = Void intp8ies (right.parent = Current)
Verificando a ciegas, como con la programación
defensiva, puede usar contratos claramente
definidos que asignan la responsabilidad de cada
condición de consistencia a una de las partes. Si
el contrato es preciso y explícito, no hay necesidad
de comprobaciones redundantes.
Cuanto más fuerte sea la condición previa,
mayor será la carga para el cliente y más fácil para
el proveedor. La cuestión de quién debe tratar con
valores anormales es esencialmente una decisión
pragmática sobre la división del trabajo: la mejor
solución
ción es la que logra la arquitectura más simple. Si
todas las rutinas y las personas que llaman
verificaran todos los posibles errores de llamada,
las rutinas nunca realizarían ningún trabajo útil.
En muchos programas existentes, es difícil
encontrar islas de procesamiento útil en océanos
de código de verificación de errores.
En ausencia de afirmaciones, la programación
defensiva puede ser el único enfoque razonable.
Pero con técnicas para definir con precisión la
responsabilidad de cada parte, tal como lo
proporcionan las afirmaciones, tal redundancia (tan
dañina para la consistencia y simplicidad de la
estructura) no es necesaria.
¿Quién debe verificar?
El rechazo de la programación defensiva
significa que el cliente y el proveedor no son ambos
responsables de una condición de consistencia. O
la condición es parte de la condición previa y debe
ser garantizada por el cliente, o no se establece en
la condición previa y debe ser manejada por el
proveedor.
¿Cuál de estas dos soluciones se debe elegir?
No existe una regla absoluta; Son posibles varios
estilos de rutinas de escritura, que van desde las
"exigentes" donde la condición previa es fuerte
(poner la responsabilidad sobre los clientes) a las
"tolerantes" donde es débil ( aumentando la carga
de la rutina). Elegir entre ellos es, hasta cierto
punto, una cuestión de preferencia personal;
nuevamente, el criterio clave es maximizar la
simplicidad general de la arquitectura.
La experiencia con Eiffel, en par-
ular el diseño de las bibliotecas,
sugiere que el uso sistemático de
un estilo exigente puede ser bastante
exitoso. En este enfoque, cada rutina
se concentra en hacer un trabajo
__
bien definido para hacerlo bien, en
lugar de tratar de manejar todos los
casos imaginables. Los programadores
de clientes no esperan milagros.
Mientras las condiciones sobre el uso de una rutina
tengan sentido, y la documentación de la rutina
establezca estas condiciones (el contrato)
explícitamente, los programadores podrán usar la
rutina
correctamente observando su parte del trato.
Una objeción a este estilo es que parece obligar
a cada cliente a hacer las mismas verificaciones,
correspondientes a la condición previa, y por lo
tanto da como resultado repeticiones innecesarias
y dañinas. Pero este argumento no está justificado:
La presencia de una precondición p en una
rutina r no significa necesariamente que cada
llamada deba probar p, como en
si x entonces
xr
más
... Trato Especial ...
final
Lo que significa la condición previa es que el
cliente debe garantizar la propiedadp; esto no es
lo mismo que probar esta condición antes de cada
llamada. Si el contexto de la llamada implica p,
entonces no hay necesidad de tal prueba. Un
esquema típico es
xs; xr
donde la poscondición de s implica p.
* Suponga que muchos clientes de hecho
necesitarán verificar la condición previa. Entonces
lo que importa es el “Trato Especial”. Es el mismo
para todas las llamadas o específico para cada
llamada. Si es el mismo, causando una repetición
indebida en varios clientes, esto es simplemente la
señal de un diseño de interfaz de clase pobre,
utilizando un contrato demasiado exigente para r.
El contrato debe ser renegociado y ampliado (más
tolerante) para incluir el Trato Especial estándar
como parte de la especificación de la rutina.
Si. sin embargo, el Tratamiento Especial es
diferente para varios clientes, entonces la necesidad
de que cada cliente realice su propia prueba
individual para p es intrínseca y no
COMPUTADORA
Machine Translated by Google
yo

una consecuencia del método de diseño sugerido la creación de cada instancia de la clase (cada
aquí. Estas pruebas tendrían que incluirse de árbol binario en este ejemplo). Esto significa que
todos modos. cada procedimiento de creación de la clase debe
producir un objeto que satisfaga el invariante.
El último caso corresponde a la situación (Una clase puede tener uno o más procedimientos
frecuente en la que un proveedor simplemente de creación, que sirven para inicializar objetos.
carece del contexto adecuado para manejar casos
anormales. Por ejemplo, es imposible que un El procedimiento de creación que se llamará en
módulo STACK de uso general sepa qué hacer cualquier caso dado se especifica en la instrucción
cuando se le solicita extraer un elemento de una de creación.)
pila vacía. Solo el cliente , un módulo de un El invariante debe ser preservado por cada
compilador u otro sistema que usa pilas , tiene la rutina exportada de la clase (es decir, cada rutina
información necesaria. disponible para los clientes). Cualquier rutina de
este tipo debe garantizar que el invariante se
satisfaga a la salida si se cumplió a la entrada.

invariantes de clase Figura 5. La invariante en el ciclo de vida

Las condiciones previas y posteriores de
rutina pueden usarse en enfoques no orientados
a objetos, aunque encajan particularmente bien
con el método orientado a objetos. Los invariantes,
el siguiente uso principal de las aserciones, son
inconcebibles fuera del enfoque orientado a
objetos.
Una invariante de clase es una propiedad que
se aplica a todas las instancias de la clase,
trascendiendo rutinas particulares. Por ejemplo,
el invariante de una clase que describe los nodos
de un árbol binario podría tener la forma que se
muestra en la Figura 4, indicando que el padre de
los hijos izquierdo y derecho de un nodo, si estos
hijos existen, es el nodo mismo. . (El operador
Implica denota implicación. Las reglas de
precedencia del operador Eiffel hacen que los
paréntesis sean
de un objeto.
en efecto luego, el invariante se agrega a la
condición previa y posterior de cada rutina
necesario aquí; se han añadido para mayor exportada de la clase.
claridad.) Pero el invariante caracteriza a la clase como un
La cláusula invariable de clase opcional todo más que a sus rutinas individuales.
aparece al final de un texto de clase:
La figura 5 ilustra estos requisitos al representar
clase ÁRBOL-BINARIO [ característica q el ciclo de vida de cualquier objeto como una
secuencia de transiciones entre estados
,.. Atributo y rutina
"observables". Los estados observables, que se
declaraciones ...
muestran como rectángulos sombreados, son los
invariante estados que siguen inmediatamente a la creación
... Como se muestra arriba ... del objeto y cualquier estado alcanzado
final - TABLA de clase posteriormente después de la ejecución de una
rutina exportada de la clase generadora del objeto.
Dos propiedades caracterizan un invariante de El invariante es la restricción de consistencia en
clase: los estados observables. (No se satisface
necesariamente entre estos estados).
El invariante debe satisfacerse después de El invariante corresponde a lo que

Sobre el lenguaje de aseveraciones

Este artículo incluye muchos ejemplos de afirmaciones típicas.
Pero, ¿qué es exactamente permisible en una afirmación?
Las afirmaciones de Eiffel son expresiones booleanas, con algunas
extensiones, como la antigua notación. Dado que todo el poder de las
expresiones booleanas está disponible, pueden incluir llamadas a
funciones. Debido a que se dispone de todo el poder del lenguaje para
escribir estas funciones, las condiciones que expresan pueden ser
bastante sofisticadas. Por ejemplo, el invariante de una clase ACYCLIC-
GRAPH puede contener una cláusula de la forma
no cíclico
donde cyck es una función con valores booleanos que determina si un
gráfico contiene ciclos mediante el uso del algoritmo de gráficos adecuado.
En algunos casos, uno podría querer usar expresiones cuantificadas
de la forma "Para todo x de tipo T, se cumple p (x) " o "Existe x de tipo 7,
tal que se cumple p (x) ", donde p es cierta propiedad booleana. Tales
expresiones no están disponibles en Eiffel. Sin embargo, es posible
expresar las propiedades correspondientes utilizando la misma técnica:
llamadas a funciones que se basan en bucles para emular los
cuantificadores.
Aunque se ha pensado en ampliar el lenguaje para incluir un
lenguaje de especificación formal completo
con el cálculo de predicados de primer orden, la necesidad de tal
extensión no parece crucial. En Eiffel, pensado como un vehículo para
el desarrollo de software industrial en lugar de solo para la investigación,
el uso de llamadas a funciones en aserciones parece proporcionar un
compromiso aceptable entre diferentes objetivos de diseño: confiabilidad,
la capacidad de generar código eficiente y simplicidad general del
lenguaje.
De hecho, el cálculo de predicados de primer orden no sería
necesariamente suficiente. Muchas propiedades importantes en la
práctica, como el requisito de que un gráfico no sea cíclico, requerirían
un cálculo de orden superior.
El uso de funciones , es decir, cálculos , no está exento de peligros.
En software, una función es un caso de una rutina: prescribe ciertas
acciones. Esto hace imperativas las funciones de software , mientras que
se dice que las funciones matemáticas son aplicativas . La principal
diferencia es que las funciones del software pueden producir efectos
secundarios (cambiar el estado de la computación). La introducción de
funciones en las afirmaciones permite que el zorro imperativo regrese al
gallinero aplicativo.
En la práctica, esto significa que cualquier función utilizada en asser
Las prestaciones deben ser de una calidad intachable, evitando
cualquier alteración del estado actual y cualquier operación que pueda
dar lugar a situaciones anómalas.

Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
Machine Translated by Google
put-child (nuevo: NODO)
-- Agregar nuevo a los hijos del nodo actual
Requerir
nuevo I = Vacío
más
newgarent = actual;
recuento de niños = recuento de niños anterior + 1
L Figura 6. La forma abreviada de una rutina.
Se denominó “condiciones generales” en la
discusión inicial de los contratos: leyes o
reglamentos que se aplican a todos los contratos
de una determinada categoría. a menudo a través
de una cláusula de la forma "todas las disposiciones
del código XX se aplicarán a este contrato".
Documentación de
un contrato de software
Para que la teoría del contrato funcione
correctamente y conduzca a sistemas correctos.
los programadores de clientes deben contar con
una descripción adecuada de las propiedades de
la interfaz de una clase y sus rutinas : la
contratos
Aquí las afirmaciones pueden jugar un papel
clave. ya que ayudan a expresar el propósito de
un elemento de software como una rutina sin
referencia a su implementación.
El comando breve del entorno Eiffel sirve para
documentar una clase extrayendo información de
la interfaz. En este enfoque. La documentación
del software no se trata como un producto que
debe desarrollarse y mantenerse por separado
del código real: en cambio, es la parte más
abstracta de ese código y puede extraerse con
herramientas informáticas.
El comando corto conserva solo las
características exportadas de una clase y. para
una rutina exportada, descarta el cuerpo de la
rutina y cualquier otro detalle relacionado con la
implementación. Sin embargo. se mantienen las
condiciones previas y posteriores . (También lo
es el comentario del encabezado, si está presente).
Por ejemplo, la Figura 6 muestra lo que produce
el comando short para la rutina piit . Expresa de
manera simple y concisa el propósito de la rutina.
sin referencia a una implementación particular.
Toda la documentación sobre los detalles de
las clases de Eiffel (por ejemplo, las
especificaciones de clase en el libro sobre las
bibliotecas básicasY) se produce automáticamente
de esta manera. Para las clases que heredan de
otras, el comando short debe combinarse con otro
tool.flat. que aplana la jerarquía de clases al incluir
46
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
yo
rasgos heredados al mismo nivel que los
”inmediatos” (aquellos declarados en la propia
clase).
Supervisión de afirmaciones
Qué pasa si. durante la ejecución. un sistema
viola una de sus propias afirmaciones?
En el entorno de desarrollo. la respuesta
depende de una opción de compilación . Para
cada clase. puede elegir entre varios niveles de
supervisión de aserciones: sin comprobación de
aserciones. solo condiciones previas
(predeterminado). condiciones previas y
condiciones posteriores. todo lo anterior más
invariantes de clase. o todas las afirmaciones. (La
diferencia entre las dos últimas se deriva de la
existencia de otras afirmaciones, como bucles
in\ariantes, que no se cubren en la presente
discusión).
Para una clase compilada bajo la opción "sin
monitoreo de aserción". aserciones no tienen
ningún efecto sobre la ejecución del sistema. Las
opciones subsiguientes provocan la evaluación
de aserciones en varias etapas: entrada de rutina
para condiciones previas, salida de rutina para
condiciones posteriores. y ambos pasos para en
variantes.
Bajo las opciones de monitoreo, el efecto de
una violación de aserción es generar una
excepción. Las posibles respuestas a una
excepción se analizan más adelante.
¿Por qué monitorear?
Como se señaló, las violaciones de aserción
no son casos especiales (pero esperados); son el
resultado de errores. La principal aplicación de
monitoreo de aserciones en tiempo de ejecución.
entonces, es de errores. Activar la verificación de
aserciones (en cualquiera de los niveles
cambiar su especificación. su implementación, o
enumerados anteriormente) hace posible detectar errores.
Al escribir software. los desarrolladores hacen
muchas suposiciones acerca de las propiedades
que se mantendrán en varias etapas de la
ejecución del software, especialmente la entrada
y el retorno de rutina. En los enfoques usuales
para la construcción de software, estos
las suposiciones siguen siendo informales e
implícitas. Aquí, el mecanismo de aserción permite
a los desarrolladores expresarlas explícitamente.
El monitoreo de afirmaciones, entonces, es una
forma de llamar la atención del desarrollador
comparando lo que hace el software con lo que
su autor cree que hace. Esto produce un enfoque
productivo para la depuración y prueba. y el
aseguramiento de la calidad, en el que la
búsqueda de errores no es ciega sino que se
basa en condiciones de coherencia proporcionadas
por los propios desarrolladores.
Particularmente interesante aquí es el uso de
precorzditioiis en las clases de biblioteca. En el
enfoque general para la construcción de software
sugerido por el método Eiffel, los desarrolladores
construyen "grupos" sucesivos de clases en un
orden de abajo hacia arriba. de más general
(reutilizable) a más específico (dependiente de la
aplicación). Este es el "modelo de clúster" del
ciclo de vida del software".' Decidir lanzar un
clúster de biblioteca 1 para uso general
normalmente implica un grado razonable de
confianza en su calidad : la creencia de que no
quedan errores en 1. Por lo tanto, puede ser no
es necesario monitorear las condiciones
posteriores de las rutinas en las clases de 1. Pero
las clases de un clúster de aplicaciones que es
un cliente de I (consulte la Figura 7) aún pueden
ser "jóvenes" y contener errores: dichos errores
pueden aparecer como argumentos erróneos en
llamadas a las rutinas de las clases de 1. El
seguimiento de las condiciones previas de las
clases de 1 ayudó a encontrarlas. Esta es una de
las razones por las que la verificación de
condiciones previas es la opción de compilación
predeterminada.
Introducción a la herencia
Una de las consecuencias de la teoría del
contrato es una mejor comprensión y control de
la noción fundamental de herencia orientada a
objetos y de las técnicas clave asociadas:
redeclaración, polimorfismo y vinculación dinámica .
A través de la herencia. puede definir nuevas
clases combinando las anteriores.
Una clase que hereda de otra tiene todas las
características (rutinas y atributos) definidas en
esa clase, más las propias. Pero no es necesario
conservar la forma exacta de las características
heredadas: puede volver a declararlas para
ambas. Esta flexibilidad del mecanismo de
herencia es fundamental para el poder del método
orientado a objetos.
Por ejemplo. una clase de árbol binario podría
proporcionar una representación predeterminada y
COMPUTADORA
Machine Translated by Google
yo
las implementaciones correspondientes para las
operaciones de búsqueda e inserción. Un
descendiente de esa clase puede proporcionar
una representación que se adapte específicamente
a ciertos casos (como árboles binarios casi
completos) y redeclarar las rutinas en consecuencia.
yo
Tal forma de redeclaración se llama redefinición . Figura 7. Grupo de bibliotecas y grupo
Supone que la rutina heredada ya tenía una
implementación. La otra forma de redeclaración,
llamada efecto, se aplica a funciones para las
cuales la versión heredada, conocida como función
diferida (o abstracta), no tenía implementación.
pero sólo una especificación. El efecto proporciona
entonces una implementación (haciendo que el
rasgo sea efectivo, lo contrario de diferido). La
discusión subsiguiente se aplica a ambas formas
de redeclaración, aunque por simplicidad se
concentra en la redefinición.
La redeclaración toma todo su poder gracias al
polimorfismo y al enlace dinámico. El polimorfismo
es una adaptación de tipos controlada por la
herencia. Más concretamente, esto significa que
si tiene b de tipo BINARY-TREE y sb de tipo
SPECIAL-BINAR Y-TREE, la última clase es
descendiente de la primera, entonces la asignación
h := sh
está permitido, lo que permite que h se adjunte
en tiempo de ejecución a instancias de SPECIAL-
BINARY-TREE, de una forma más especializada
que la que especifica la declaración de b . Por
supuesto, esto sólo es posible si la relación de
herencia se mantiene entre las dos clases como
se indica.
¿Qué sucede entonces para una llamada de la
forma
t.insrrt (v)
que aplica el procedimiento de inserción, con el
argumento v, al objeto adjunto a t?
La vinculación dinámica significa que dicha
llamada siempre utiliza la versión adecuada del
procedimiento : la original si el objeto al que se
adjunta t es una instancia de BINARY-TREE, la
versión redefinida si es una instancia de SPECIAL-
BINARY- ÁRBOL. La política inversa, el enlace
estático (usar la declaración de h para hacer la
elección), sería un absurdo: elegir deliberadamente
la versión incorrecta de una operación.
La combinación de herencia, redeclaración,
polimorfismo y vinculación dinámica produce gran
parte del poder y
octubre de 1992
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
por supuesto. Ninguna técnica de diseño es
inmune al mal uso. Pero al menos es posible
ayudar a los diseñadores serios a utilizar la técnica
correctamente; aquí la teoría del contrato
proporciona la perspectiva adecuada.
Lo que significan la redeclaración y el enlace
dinámico es la capacidad de subcontratar una
tarea; prevenir el uso indebido significa entonces
de aplicaciones. garantizar que los subcontratistas cumplan las
promesas del contratista principal en el contrato
original.
flexibilidad que resulta del uso del enfoque Considere la situación descrita en la Figura 8.
orientado a objetos.: Sin embargo, estas técnicas A exporta una rutina r a sus clientes. (Para
también pueden plantear preocupaciones de simplificar, ignoramos los argumentos de r). Un
posible uso indebido: ¿Qué es evitar que una cliente X ejecuta una llamada
nueva declaración produzca un efecto incompatible
con la semántica de la versión original?
particularmente mala manera, especialmente en tu
el contexto de enlace dinámico? Norte
donde U se declara de tipo A. Ahora B, un
El problema de la concurrencia
La teoría del diseño por contrato plantea cuestiones importantes con respecto a la aplicación
de ideas orientadas a objetos a la computación concurrente. Al discutir los contratos, este artículo
menciona que los clientes pueden ver la condición previa de una rutina no solo como una
obligación sino también en parte como un beneficio, ya que el contrato indica implícitamente que
una llamada que satisfaga la condición previa será atendida correctamente. Esta es la regla de
la Cláusula No Oculta. Por ejemplo, si la rutina de inserción puesta para una clase BOUNDED-
QUEUE tiene la condición previa
no lleno
para indicar que una operación de inserción requiere una cola que no está llena, entonces
una llamada protegida de la forma
q: COLA LIMITADA [ TJ;
XT;
...
si no q.full entonces
4. Poner (4
final
tendrá éxito, ya que el cliente que ejecuta esta llamada se ha tomado la molestia de
verificar la condición previa explícitamente.
En computación paralela, sin embargo, las cosas no son tan agradables. La cola limitada
en este ejemplo puede usarse como un búfer limitado, accesible para varios procesadores. El
encargado del cliente, que llevará a cabo las instrucciones anteriores, y el encargado de q, que
llevará a cabo la ejecución de put, podrán ser encargados diferentes. Entonces, incluso si la
prueba para q.full arroja falso, entre el momento en que el cliente ejecuta esta prueba y el
momento en que ejecuta la llamada q.put (x), pueden haber ocurrido bastantes eventos. Por
ejemplo, otro cliente puede haber llenado la cola al ejecutar su propia llamada para poner.
En otras palabras, puede ser necesaria una interpretación semántica diferente para las
condiciones previas en el contexto del cálculo paralelo. Esta observación sirve como punto de
partida para algunos de los trabajos actuales sobre modelos para sistemas orientados a objetos
concurrentes.
Referencias
1. B. Meyer, “Programación orientada a objetos secuencial y concurrente”, en
TOOLS 2 (Tecnología de lenguajes y sistemas orientados a objetos), Angkor/SOL,
París, junio de 1990, págs. 17-28.
2. J. Potter y G. Jalloul. 'Modelos para Eiffel concurrente', en TOOLS 6 (Tecnología de
lenguajes y sistemas orientados a objetos), Prentice Hall, Englewood Cliffs, NJ, 1991,
pp. 183-1 92.
Machine Translated by Google
descendiente de A, redeclara r. A través del
polimorfismo, u bien puede vincularse a una instancia
de B en lugar de A. Tenga en cuenta que a menudo
no hay forma de saber esto solo del texto de X : por
ejemplo, la llamada que se acaba de mostrar podría
estar en una rutina de X que comienza con
alguna-rutina (U: A) es ...
donde el polimorfismo solo resulta de una llamada
de la forma
z.alguna-rutina (v)
por lo que el argumento real v es de tipo B. Si esta
última llamada está en una clase distinta de X, el
autor de X ni siquiera sabe que u puede vincularse
a una instancia de B. De hecho, es posible que ni
siquiera sepa sobre la existencia de una clase B.
Pero entonces el peligro es claro. Para
determinar las propiedades de la llamada ur, el autor
de X solo puede mirar el contrato para r en A. Sin
embargo, debido a la vinculación dinámica, A puede
subcontratar la ejecución de r a B, y es el contrato
de B el que sera aplicado.
¿Cómo evitas “engañar” a X en el proceso? Hay
dos formas en que B podría violar las promesas de
su contratista principal:
B podría hacer que las condiciones previas
sean más estrictas, aumentando el riesgo de que
algunas llamadas que son correctas desde el punto
de vista de X (que satisfacen las obligaciones
originales del cliente) no se manejen correctamente.
B podría debilitar la poscondición, dando un
resultado menos favorable que el prometido a X.
Nada de esto, entonces, está permitido. Pero los
cambios inversos son, por supuesto, legítimos. Una
nueva declaración puede debilitar la condición previa
del original o puede fortalecer la condición posterior.
Los cambios de cualquier tipo significan que el
subcontratista hace un mejor trabajo que el
contratista original , lo cual no hay motivo para
prohibirlo.
Estas reglas iluminan algunas de las propiedades
fundamentales de la herencia, la redeclaración, el
polimorfismo y el enlace dinámico. Redeclaración.
por todo el poder que aporta al desarrollo de
software. no es una manera de convertir una rutina
en algo completamente diferente. La nueva versión
debe seguir siendo compatible con la especificación
original. aunque puede mejorarlo. Las reglas
anotadas expresan esto con precisión.
Estas reglas deben ser aplicadas por el
48
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
4 que describe los nodos del árbol, incluye la cláusula
Figura 8. Redefinición de una rutina bajo
contrato.
idioma. Eiffel usa una convención simple. En una
redeclaración, no se permite utilizar las formas
requieren ... y aseguran ... La ausencia de una
cláusula de precondición o poscondición significa
que la versión redeclarada conserva la aserción de
la versión original. Dado que esta es la situación
más frecuente, el autor de la clase no está obligado
a escribir nada especial en este caso. Un autor de
clase que quiera adaptar la aserción usará una o
ambas formas
requerir más
nuevo
asegurate entonces
nuevogost
que producen lo siguiente como nueva condición
previa y condición posterior:
newgre o bien originalgrecondition
newgost y luego
originalgost condition
donde Or Else y And Then son las versiones no
conmutativas de los operadores "o" y "y" (evaluando
su segundo argumento solo si es necesario). De
este modo. se garantiza que la nueva condición
previa será más débil o igual que las originales, y se
garantiza que la nueva condición posterior será más
fuerte o igual que las originales.
Invariantes y
enlace dinámico
Además de las reglas sobre precondiciones y
poscondiciones, otra restricción vincula las
afirmaciones con la herencia: las invariantes siempre
se transmiten a los descendientes.
Este es un resultado directo de la opinión de que
la herencia es (entre otras cosas) clasificación. Si
queremos considerar cada instancia de una clase B
como una instancia de los ancestros de R , debemos
ac
excepto que las restricciones de consistencia en un
padre A también se aplican a las instancias de B.
Por ejemplo, si la invariante de una clase ÁRBOL,
child.parent = Actual
expresando que el padre del hijo actualmente activo
de un nodo es el propio nodo, esta cláusula se
aplicará automáticamente a las instancias de una
clase BINARY-TREE, que hereda de TREE. Como
resultado, la especificación del lenguaje define “la
invariante de una clase” como la afirmación obtenida
al concatenar la afirmación en la cláusula invariante
de la clase con las invariantes de todos los padres
(obtenida recursivamente bajo esta definición).
Como resultado, la invariante de una clase
siempre es más fuerte o igual que las invariantes de
cada uno de sus padres.
Estas reglas conducen a una mejor comprensión
de por qué el enlace estático sería, como se dijo
anteriormente, un desastre.
Asumir de nuevo la declaración y llamar
tu: un:
,..
tu
donde un descendiente B de A redefine r.
Llame a rA y rB las dos implementaciones.
Entonces r, debe conservar INV,, la invariante de
A, y r, debe conservar INV,, la invariante de B, que
es más fuerte o igual que INV,.
Por supuesto, no hay ningún requisito de que r4
conserve INV,. De hecho, la clase A puede haber
sido escrita mucho antes que la B, y el autor de A
no necesita saber nada acerca de los descendientes
eventuales de esta clase.
Si LL se adjunta dinámicamente a una instancia
de B, el enlace dinámico requiere la ejecución de rH
para esta llamada.
La unión estática desencadenaría r,. Dado que esta
versión de la rutina no se requiere para preservar
INV, el resultado produciría una situación catastrófica:
un objeto de tipo B que no satisface la restricción de
consistencia -el invariante- de su propia clase. En
tales casos, cualquier intento de comprender los
textos del software o razonar sobre su comportamiento
en tiempo de ejecución se vuelve inútil.
Un ejemplo sencillo hará que la situación sea
más concreta. Supongamos una CUENTA de clase
que describa cuentas bancarias, con los atributos
que se muestran en la Figura Ya y un procedimiento
para registrar un nuevo depósito que se muestra en
la Figura 9b.
COMPUTADORA
Machine Translated by Google
Con esta versión de la clase, obtener
el saldo actual de una cuenta requiere un
cálculo expresado por una función. La
figura 10 muestra cómo podría aparecer
la función de saldo , asumiendo la
función apropiada en la clase TRANSA
CTION-LIST.
En una clase descendiente AC
COUNTI, puede ser una mejor
compensación de espacio-tiempo
almacenar el saldo actual con cada objeto Figura 9. Características de una clase de Cuenta Bancaria.
de cuenta. Esto se puede lograr
redefiniendo la función balance en un
atributo (un proceso que de hecho es
compatible con el lenguaje). Naturalmente,
este atributo debe ser consistente con los
demás; esto se expresa mediante el
invariante de CUENTA1, que se muestra
en la Figura 11.
Sin embargo, para que esto funcione,
B debe redefinir cualquier rutina de A que
modifique depósitos o retiros; la versión Me imagino. Cálculo del saldo.
redefinida también debe modificar el
campo de saldo del objeto en
consecuencia, para mantener el invariante.
Es el caso, por ejemplo, del procedimiento
registro-depósito.
Ahora supongamos que tenemos el
declaración y convocatoria
a: CUENTA
...
a.registro-depósito (1 -000-000)
Si en una determinada ejecución, se adjunta a
un objeto de tipo AC COUNT1 en el momento de
la llamada, el enlace estático significaría aplicar la
versión original de ACCOUNT de record -deposit,
que no actualiza el campo de saldo . El resultado
sería un objeto ACCOUNT1 inconsistente y un
desastre seguro.
Lidiando con
situaciones anormales
La teoría del Diseño por Contrato tiene una
aplicación más inmediata a la práctica del desarrollo
de software confiable: el manejo de excepciones.
Las excepciones -casos anormales- han sido
objeto de mucho estudio: y varios lenguajes de
programación, en particular Ada, PLII y CLU,
ofrecen mecanismos de manejo de excepciones.
Gran parte de este trabajo es decepcionante, sin
embargo, porque
octubre de 1992
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
depósito de registro ~
Figura 11. Invariante de la clase Cuenta.
no logra definir con precisión qué es un caso
anormal. Entonces, el manejo de excepciones a
menudo se convierte en una especie de mecanismo
generalizado de "ir a" entre rutinas, sin pautas
claras para el uso adecuado.
Para comprender mejor el problema, realicé un
estudio (reportado en otro lugar) de los libros de
texto de Ada y CLU , en busca de ejemplos de
manejo de excepciones y principios metodológicos.
Los resultados fueron decepcionantes, ya que los
libros mostraban muchos ejemplos de activación
de excepciones pero pocos de cómo manejarlas .
Además, algunos de estos últimos eran
espeluznantes. Por ejemplo, un libro de texto
propuso un ejemplo de una rutina de raíz cuadrada
que, cuando se confronta con un argumento
negativo, desencadena una excepción. El
controlador de excepciones imprime un mensaje y
luego simplemente regresa a la persona que llama
sin notificarle que ha ocurrido algo incorrecto ,
engañando a la persona que llama, por así decirlo,
haciéndole creer que todo va según lo planeado.
Dado que un uso típico de las raíces cuadradas en
un programa típico de Ada es el cálculo de la
trayectoria de un misil, es fácil ver las consecuencias
probables.
Más allá del mal gusto de tal individuo
En algunos ejemplos, uno puede criticar
el diseño del mecanismo de excepción
en sí mismo por no alentar, o incluso
definir , una disciplina adecuada para
manejar las anomalías.
casos malos.
La teoría del contrato proporciona un
buen punto de partida para una solución
más racional. Si una rutina se ve no solo
como una "pieza de código" sino como la
implementación de una determinada
especificación , el contrato , es posible
definir una noción de falla. La falla ocurre
cuando la ejecución de una rutina no
puede cumplir con el contrato de la rutina.
Las posibles razones de una falla incluyen
un mal funcionamiento del hardware, un
error en la implementación o algún evento
externo inesperado.
“Fracaso” es aquí el concepto básico.
i “Excepción” es una noción derivada. Una
excepción ocurre cuando cierta estrategia
para cumplir con el contrato de una rutina
no ha tenido éxito. Esto no es un fracaso,
al menos no todavía, porque la rutina
puede tener una estrategia alternativa.
El ejemplo más obvio de excepción es
el fallo de una rutina llamada: la estrategia
de r para cumplir -_ suacontrato una
implicaba
llamada
s; la llamada
falló; claramente, esta es una excepción para r.
Otro ejemplo, mencionado anteriormente, es una
violación de aserción en tiempo de ejecución, si se
supervisan las aserciones. También es conveniente
tratar como excepciones las señales enviadas por
el sistema operativo o el hardware: desbordamiento
aritmético, agotamiento de memoria, etc. De hecho,
corresponden a fallas en las llamadas a las
instalaciones básicas (operaciones aritméticas,
asignación de memoria).
Equipados con esta noción de falla y excepción,
podemos definir una respuesta coherente a una
excepción. La excepción ocurre porque la estrategia
utilizada para lograr el contrato de la rutina no
funcionó. Solo tres respuestas posibles tienen
sentido:
(1) Quizás haya una estrategia alternativa
disponible. Hemos perdido una batalla, pero no
hemos perdido la guerra. En este caso, la rutina
debería devolver los objetos a un estado coherente
y hacer otro intento, utilizando la nueva estrategia.
Esto se llama reanudación.
(2) Quizás, sin embargo, hemos perdido la
guerra por completo. No hay nueva estrategia
49
Machine Translated by Google
get-integerfrom-user: INTEGER es
-- Leer un número entero (permitir al usuario hasta cinco intentos)
fallas
locales : ENTERO
hacer
Resultado := getint
movimiento rápido del ojo
fallas :=fallas + 1;
si fallas < 5 entonces
mensaje ("La entrada debe ser un número entero. Ingrese de
nuevo: "); rever
final
end -- getintegerfrom-user
Figura 12. Lectura de un entero con una primitiva insegura.
disponible. Luego, la rutina debería volver a poner
los objetos en un estado consistente, renunciar al
contrato e informar la falla a la persona que llama.
Esto se llama pánico organizado.
(3) Un tercer caso raro pero posible es la falsa
alarma. Esto puede ocurrir solo para el sistema
operativo o las señales de hardware.
En algunos sistemas de ventanas múltiples, por
ejemplo, un proceso recibe una señal (que el tiempo
de ejecución transforma en una excepción) cuando
se cambia el tamaño de su ventana.
En la mayoría de los casos, el proceso debería poder
continuar con su ejecución, posiblemente después
de realizar algunas acciones correctivas (como
registrar las nuevas dimensiones de la ventana para
que las utilicen los editores y otras herramientas).
La descripción tanto de la reanudación como del
pánico organizado menciona volver a colocar los
objetos “en un estado consistente”.
Esto es esencial si las ejecuciones posteriores
(después de una eventual reanudación) volverán a
utilizar los objetos. La noción de estado consistente
debe quedar clara a partir de la discusión anterior:
cualquier manejo de excepción, ya sea para la
reanudación o para el pánico organizado, debe
restaurar la invariante.
Un mecanismo
disciplinado de manejo
de excepciones
No es difícil idear un mecanismo de excepción
que apoye directamente el método anterior para
manejar casos anormales.
50
Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.
Para especificar cómo debe ser una rutina
después de una excepción, el autor de una rutina
Eiffel puede incluir una cláusula de "rescate", que
expresa el comportamiento alternativo de la rutina (y
es similar a las cláusulas que ocurren en los contratos
humanos, para permitir por circunstancias
excepcionales no planificadas). Cuando una rutina
incluye una cláusula de rescate, cualquier excepción
que ocurra durante la ejecución de la rutina interrumpe
la ejecución del cuerpo (la cláusula Do ) y comienza
la ejecución de la cláusula de rescate.
La cláusula contiene cero o más instrucciones, una
de las cuales puede ser un Reintento.
La ejecución termina en cualquiera de
dos caminos:
Si la cláusula de rescate finaliza sin ejecutar
un Reintento, la rutina falla.
Informa de la falla a la persona que llama activando
una nueva excepción. Este es el caso del pánico
organizado.
Si la cláusula de rescate ejecuta un Re
try, el cuerpo de la rutina ( cláusula Do) se ejecuta
de nuevo.
Como ejemplo, aquí hay una solución a un
problema que se encuentra en muchos libros de texto
de Ada: usando una función getint, que lee un número
entero, solicita al usuario que ingrese un valor entero;
si la entrada no es un número entero, vuelva a
preguntar, a menos que el usuario no pueda
proporcionar un número entero después de cinco
intentos, en cuyo caso se produce un error. Se
supone que getint es una rutina externa, tal vez
escrita en C o en lenguaje ensamblador, y no tenemos
control sobre ella. Activa una excepción cuando se
aplica a una entrada que no es un número entero; la
rutina debe detectar esa excepción y solicitar
el usuario de nuevo. La figura 12 muestra una solución
ción
Las primeras cinco veces el interactivo
el usuario ingresa una entrada incorrecta, la rutina
comienza de nuevo, gracias al Reintento. Esta es la
implementación directa de la reanudación.
Los fallos de entidad local sirven para registrar el
número de llamadas fallidas a getint. Como cualquier
entidad local entera, se inicializa automáticamente a
cero en una llamada de rutina . (La definición del
lenguaje Eiffel especifica valores de inicialización
simples para cada tipo posible).
En este ejemplo, solo es posible un tipo de
excepción. En algunos casos, la cláusula de rescate
podría necesitar discriminar entre posibles tipos de
excepciones y manejarlas de manera diferente. Esto
es posible gracias a las características simples de la
clase EX CEPTIONS de la biblioteca del núcleo,
aunque no es necesario mirar los detalles (sencillos)
aquí. Esta clase también proporciona mecanismos
para manejar el caso de falsa alarma al especificar
que para ciertas señales se puede permitir que se
reanude la ejecución.
¿Qué sucede después de cinco fallas sucesivas
de getint? La cláusula de rescate finaliza sin ejecutar
un Reintento y la ejecución de la rutina falla (pánico
organizado). La regla clave en este caso es que la
persona que llama a get-integer obtendrá una
excepción, que tendrá que manejar usando la misma
política, eligiendo entre pánico organizado,
reanudación y falsa alarma.
En un sistema típico, solo un puñado de rutinas
tiene una cláusula de rescate explícita.
¿Qué pasa si ocurre una excepción durante la
ejecución de una rutina que no tiene tal
¿cláusula? La regla es simple: una cláusula ausente
se considera equivalente a una cláusula implícita de
la forma
rescate
rescate por defecto
donde default-rescue es un procedimiento de
propósito general que, en su forma básica, no hace
nada. Luego, una excepción simplemente inicia la
cláusula de rescate, que, al ejecutar el rescate
predeterminado vacío , provoca el fallo de la rutina;
esto desencadena la cláusula de rescate, explícita o
implícita. Si las excepciones se pasan de esta manera
hasta el "objeto raíz" que inició la ejecución, esa
ejecución se detiene después de imprimir una tabla
de historial de excepciones que documenta claramente
la secuencia de eventos anormales registrados.
Pero claro, alguna rutina en la llamada
COMPUTADORA
Machine Translated by Google
yo

4. Coche Hoare. "Una base axiomática para la

cadena puede tener una cláusula de rescate.
incluso uno que contenga un reintento que
intentará una reanudación.
¿Por qué definir el comportamiento
predeterminado como una llamada a rlefuulr-
rescite en lugar de simplemente como una
cláusula de rescate vacía? La razón proviene de
la discusión metodológica. En el caso de pánico
organizado. es esencial restaurar la invariante
antes de reconocer la derrota y rendirse. Una
acción nula no lograría esto para una clase con
un invariante no trivial.
La solución la proporcionan una vez más las
fuerzas fusionadas de la herencia y las
afirmaciones. Procedimiento predeterminado
-rescue . en su forma nula predeterminada .
aparece como un procedimiento de la clase de
propósito general ANY. Esta clase de biblioteca,
tal como la definen las reglas del lenguaje, es
automáticamente un ancestro de todas las
posibles clases definidas por el desarrollador.
Por lo tanto, es responsabilidad de los
diseñadores de una clase C si están preocupados
por las posibles excepciones que ocurren en las
rutinas que no tienen cláusulas de rescate
específicas. para redefinir defuiill-rescue para
que asegure la clase invariante de C.
A menudo, uno de los procedimientos de
creación puede servir como una redefinición de t/
efirirltp resew. ya que también se requieren
procedimientos de creación para asegurar la invariante.
Esto ilumina la diferencia entre el cuerpo (la
cláusula Do ) y la cláusula de rescate:
Estado de Eiffel
La definición de la lan Eiffel
El lenguaje, utilizado como
vehículo para este artículo, es
de dominio público. La evolución
del lenguaje está bajo el control
de una organización de usuarios
y desarrolladores de la tecnología
Eiffel: el Nonprofit International
Consortium for Eiffel (NICE). La
membresía en NICE está abierta a
cualquier organización interesada.
La dirección es PO BOX 6884, Santa Bárbara, CA 93160.
la poscondición). También es parte del contrato
del cocinero. aunque quizás uno implícito. para
evitar prender fuego al restaurante en el proceso
(para mantener lo invariable).
Cuando se pide ayuda al bombero, por el
contrario. no se garantiza el estado del
restaurante. Puede estar ardiendo o (en el caso
de una alerta incorrecta) no ardiendo. Pero
entonces, el único deber del bombero es devolver
el restaurante a un estado que no se queme .
Servir comidas a los clientes reunidos no es
parte de la descripción del trabajo del bombero.
W (referencia de escena 3).
programación de computadoras", Comm. ACM, vol.
12. NO. 10 de octubre de 1969, págs. 576-580. 583.
5. EW Dijkstra. Una disciplina de programación.
Prcnticc Hall, Englewood Cliffs, Nueva Jersey. 1976.
6. JA Cogüen. JW Thatcher y EG
Wagner. “Un enfoque de álgebra inicial para la
especificación, corrección. and Im plementation of
Abstract Data Types”, en Cirrrenr Trends in
Programming Meth OdO/ Og?;. vol. 3. RT Sí. ed..
Prentice Hall. Englewood Cliffs, NJ, 1978. págs.
80-149.
7. JV Cuttag. "Tipos de datos abstractos y el desarrollo
de estructuras de datos".
Com. AC'M, vol. 20. No. 6. Junio de 1977, págs.
396-404.
8. B. Meyer. “La Description des Struc
tures de DonnCes,” Bulletin de la Direc
tion des Etudes et Recherches
d'Electricite de France. SCrie C
(Informática). N° 2, París, 1976.
9. B. Meyer. Eifjelc Las Bibliotecas. Prentice Hall.
Englewood Cliffs, NJ, (aparecerá en 1993).
IO. B. Meycr. "La nueva cultura del desarrollo de
software". HERRAMIENTAS I (Tecnología de
Lenguajes y Sistemas Orientados a Objetos). SOL.
París, noviembre de 1989, págs. 13-23.
Versión ligeramente revisada en Avances en
ingeniería de software orientada a objetos

El órgano debe ejecutar el contrato, o

garantizar la poscondición. Por consistencia,
también debe cumplir con la ley general del país :
preservar lo invariable. Su trabajo se facilita un
poco por la suposición de que el invariante se
mantendrá inicialmente, lo que garantiza que la
rutina encontrará el objeto en un estado
Expresiones de gratitud
He sido muy influenciado por los creadores del
trabajo clásico sobre el desarrollo sistemático de
software, mencionado en la barra lateral "Otras fuentes".
Con su minuciosidad habitual . Kim Walden leyó el texto

consistente. y señaló errores y posibles mejoras. Los árbitros

Por el contrario, la cláusula de salvamento
no puede hacer tal supuesto: no tiene condición
previa, ya que una excepción puede ocurrir en
cualquier momento. Su recompensa es una tarea
menos exigente. Todo lo que se requiere hacer
al salir es restaurar el invariante.
Asegurar la poscondición -el contrato- no es su
trabajo.
anónimos hicieron varios comentarios útiles.
Eiffel i, una marca comercial del Nonprofit
International Consortium for Eiffel.
Referencias
IB Meyer, Erffel : The Lattgziagc .. Prentice Hall.
Acantilados de Englewood. NUEVA JERSEY. 1991.
Bertrand Meyer es presidente de Interactive Software
Engineering Inc. y Societe des Outils du Logiciel, París.
Sus áreas de interés incluyen especificación formal,
métodos de diseño, lenguajes de programación, sistemas
interactivos , entornos de desarrollo de software y
diversos aspectos de la tecnología orientada a objetos.
Meyer tiene una licenciatura en ingeniería de la Ecole
Polytechnique, una maestría de la Universidad de
Stanford y un doctorado de la Universidad de Nancy. Es

A
Una analogía útil es el contraste entre autor de varios libros y artículos técnicos, editor de la
la grandeza y la servidumbre de dos Serie Orientada a Objetos de Prentice Hall y presidente
2. B. Meyer. Ohjrcl-OrietitrtlSoiftware Con stnicrioti.
profesiones igualmente respetables : de la serie de conferencias TOOLS (Tecnología de
Prentice Hall. Acantilados de Englewood.
Lenguajes y Sistemas Orientados a Objetos).
cocinero y bombero. Un cocinero puede suponer NUEVA JERSEY. 1988.

que el restaurante no se está quemando

(satisface el invariante) cuando comienza la
jornada laboral. Si el restaurante es de hecho
nonburning. el cocinero debe preparar las
comidas (asegúrese
3. B. Meycr. “Diseño por Contrato.“ en Avances en
Ingeniería de Software Orientada a Objetos , D.
Se puede contactar al autor en Interactive Software
Mandrioli y B. Meyer. eds.. Prentice Hall,
EnglewoodCliffs, Nueva Jersey. 1991 , págs. 1-50, Engineering, 270 Storke Rd., Suite 7. Goleta, CA 93117.

octubre de 1992 51

Uso con licencia autorizado limitado a: Universidad Tecnológica de Michigan. Descargado el 21 de febrero de 2010 a las 19:03:00 EST desde IEEE Xplore. Se aplican restricciones.