Programación Defensiva

INTRODUCCIÓN

Los programadores tenemos (o deberíamos tener) como objetivo la construcción de programas de calidad. Hay muchísimos aspectos que influyen en la calidad de los programas:

que funcione correctamente, que tenga buena documentación, que sea eficiente, que sea compatible con otros programas, que tenga una buena interfaz de usuario, etc.

Este documento discute un conjunto de problemas y metodologías/técnicas para resolverlos. Las técnicas se conocen como Programación Defensiva, y apuntan a resolver problemas asociados con dos aspectos importantes de la calidad del software:

 

Corrección Un programa es correcto cuando cumple su función correctamente, es decir, cuando hace todo lo que se supone que debe hacer.

Robustez Un programa es robusto cuando es capaz de manejar razonablemente situaciones inesperadas (que falten archivos, que se acabe la memoria, que haya un error interno en el mismo programa), y minimiza el daño producido por estas situaciones.

 

CONCEPTOS CLAVES

ERRORES, DEFECTOS Y FALLOS

 

Un error es una decisión incorrecta tomada durante el desarrollo de un sistema de software (usualmente una suposición incorrecta).

Un defecto es una propiedad del software que puede hacer que se comporte de una manera no deseada.

Un fallo es la situación en la cual un software en ejecución efectivamente se comporta de una manera no deseada.

 

Claramente, la relación de causa efecto es: los fallos son producidos por defectos, que son el resultado de errores. Los fallos existen en la ejecución del programa, los defectos en el software, y los errores en las personas. Lo que intentamos es no tener errores ni defectos. Aunque en general la forma que tenemos para hacer esto, es testear, y obtener fallos. A partir del fallo viene un trabajo detectivesco en el que (con suerte) aparece el defecto culpable, y el error que produjo el defecto.

 

PROGRAMACIÓN DEFENSIVA

La programación defensiva es una forma de diseñar software que busca garantizar el comportamiento de todo elemento de una aplicación ante cualquier situación de uso por incorrecta o imprevisible que ésta pueda parecer. En general, esto supone multiplicar las comprobaciones que se realizan en todos los módulos programados, con la consiguiente penalización en carga de procesador, tiempo y aumento en la complejidad del código. Las técnicas de programación defensiva se utilizan especialmente en componentes críticos cuyo mal funcionamiento, ya sea por descuido o por ataque malicioso, podría acarrear consecuencias graves o daños catastróficos.

La programación defensiva es un enfoque que busca mejorar el software y el código fuente, en términos de:

·         Calidad General – reduciendo el número de fallos de software y problemas.

·         Haciendo el código fuente comprensible – el código fuente debe ser legible y entendible, a prueba de una auditoría de código.

·         Hacer que el software se comporte de una manera predecible pese a entradas o acciones de usuario inesperadas.

TÉCNICAS DE PROGRAMACIÓN DEFENSIVA

Aquí están algunas técnicas de programación defensiva sugeridas por algunos de los científicos líderes de computación para evitar crear problemas de seguridad y errores de software. Estos científicos afirman que aunque este proceso pueda mejorar la calidad el código, no es suficiente para asegurar la seguridad. Mirar artículos sobre inseguridad computacional o programación segura para más información.

Los principios de programación para crear Software Defensivo son:

Reducir complejidad del código

Nunca hacer el código más complejo que lo necesario. La complejidad genera bugs, incluyendo problemas de seguridad. Esta meta pude tener conflicto con el objetivo de escribir programas que puedan recuperarse de cualquier error y manejar cualquier entrada de datos. Manejar todas las ocurrencias inesperadas en un programa requiere que el programador adicione código extra, el cual pudiera también tener bugs.

Revisiones del código fuente

Una revisión de código es donde alguien diferente al autor original realiza una auditoría de código. Una auditoría de código hecha por el mismo creador es insuficiente. La auditoría la debe hacer alguien que no sea el autor, como cuando se escribe un libro, debe ser revisado por alguien que no sea el autor.

Simplemente haciendo el código disponible para que otros lo lean (Ver Software Libre, o Open Source Definition) es insuficiente: no hay garantía que el código sea visto, no dejando que sea rigurosamente revisado.

Las pruebas de software deberán ser para tanto que el software trabaje como debe, como cuando se supone que pase si se realice deliberadamente malas entradas.

Las herramientas de prueba pueden capturar entradas de teclado asociadas con operaciones normales. Luego las cadenas de texto de estas entradas capturadas pueden ser copiadas y editadas para ensayar todas las permutaciones y combinaciones, luego ampliarlas para tests posteriores después de cualquier modificación-. Los defensores de la clave de registro afirman que los programadores que usan este método deberán asegurar que las personas a las cuales se les están capturando las entradas estén al tanto de esto, y con que propósito?, para evitar acusaciones de violación de privacidad .

Reutilización inteligente del código fuente

Si es posible, reutilizar código. La idea es capturar beneficios de un bien escrito y bien probado código fuente, en vez de crear bugs innecesarios.

Sin embargo, reutilizar código no siempre es la mejor manera de progresar, particularmente cuando la lógica del negocio esta involucrada. Reutilizar en este caso puede causar serios bugs en los procesos de negocio.

Los problemas de legado

Antes de reusar viejo código fuente, librerías, API’s, configuración y demás, debe ser considerado si el trabajo anterior es válido para reusar, o si es propenso a problemas de legado.

Los problemas de legado son problemas inherentes cuando se espera que viejos diseños trabajen con los requerimientos actuales, especialmente cuando estos viejos diseños no fueron desarrollados o probados con estos requerimientos en mente.

Muchos productos de software han experimentado problemas con viejos códigos fuente legados, por ejemplo:

·         El código legado puede no haber sido diseñado bajo iniciativa de Programación Defensiva, y puede por consiguiente estar con mucha menor calidad que un diseño más nuevo de código fuente

·         El código legado puede haber sido escrito y probado bajo condiciones que ya no aplican más. Los viejos test de aseguramiento de calidad pueden no ser válidos ahora. Ejemplo 1: El código legado puede haber sido diseñado para entradas ASCII pero ahora la entrada es UTF-8. Ejemplo 2: El código legado puede haber sido compilado y probado sobre arquitecturas de 32 bits, pero cuando es compilado sobre arquitecturas de 64 bits pueden ocurrir nuevos problemas aritméticos. Ejemplo 3: Un código legado puede haberse enfocado hacia máquinas fuera de línea, pero se vuelve vulnerable una vez la conectividad de red es adicionada.

CONCLUCIONES

·         Todos los datos son importantes hasta que se demuestre lo contrario.

·         Todo código es inseguro hasta que se demuestre lo contrario.

·         El diseño por contrato usa precondiciones, poscondiciones e invariantes para asegurar que los datos provistos (y el estado del programa como un todo) esta saneado. Esto permite al código documentar todas las hipótesis y hacerlo así seguro.

 

BIBLIOGRAFÍA

http://es.wikipedia.org/wiki/Programaci%C3%B3n_Defensiva

 

http://www.cs.famaf.unc.edu.ar/so2004/ProgramacionDefensiva.html

 

 

 

About omaracostacasas

ING SOFTWARE
This entry was posted in Ingenieria de Software. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s