Está en la página 1de 14

1.

Introduccin
Estas notas son una Introduccin a la Resolucin Sistemtica de Problemas mediante Algoritmos. El objetivo de las notas es presentar una metodologa que permita obtener soluciones algortmicas correctas de un problema dado. La Programacin de computadoras comen como un arte! " a#n $o" en da muc$a gente aprende a programar slo mirando a otros proceder %ej. &n pro'esor! un amigo! etc.(! " mediante el $bito! sin conocimiento de los principios que $a" detrs de esta actividad. En los #ltimos a)os! sin embargo! la investigacin en el rea $a arrojado teora su'iciente para que estemos en capacidad de comen ar a ense)ar estos principios en los cursos bsicos de ense)an a de la programacin. La metodologa que proponemos toca la ra de los problemas actuales en programacin " provee principios bsicos para superarlos. &no de estos problemas es que los programadores $an tenido poco conocimiento de lo que signi'ica que un programa sea correcto " de cmo probar que un programa es correcto. *uando decimos +probar, no queremos decir necesariamente que tengamos que usar un 'ormalismo o las matemticas! lo que queremos e-presar es +encontrar un argumento que conven a al lector de la veracidad de algo,. .esa'ortunadamente! los programadores no son mu" adeptos a esto! basta observar la cantidad de tiempo que se gasta en +debugging, %proceso de depuracin de programas para eliminar entre otros errores! los errores de lgica(! " esto /por qu01 Porque el m0todo de programacin normalmente usado $a sido +desarrollo por casos de prueba,! es decir! el programa es desarrollado sobre la base de algunos ejemplos de lo que el programa debe $acer. A medida que se encuentran ms casos de prueba! estos son ejecutados " el programa es modi'icado para que tome en cuenta los nuevos casos de prueba. El proceso contin#a con modi'icaciones del programa a cada paso! $asta que se piensa que "a $an sido considerados su'icientes casos de prueba. 2ran parte del problema se $a debido a que no $emos posedo $erramientas adecuadas. El ra onamiento sobre cmo programar se $a basado en cmo los programas son ejecutados! " los argumentos sobre la correccin %diremos de a$ora en adelante +correctitud,! pues el t0rmino correccin se entiende como si quisi0ramos corregir un programa " lo que queremos es probar que un programa es correcto( de un programa se $an basado en slo determinar casos de prueba que son probados corriendo el programa o simulados a mano. La intuicin " el sentido com#n $an sido simplemente insu'icientes. Por otro lado! no siempre $a estado claro lo que signi'ica que un programa sea +correcto,! en parte porque la especi'icacin de programas $a sido tambi0n un tema mu" impreciso. El principio bsico de estas notas ser el desarrollo simultneo de un programa con la demostracin de la correctitud. Es mu" di'cil probar la correctitud de un programa "a $ec$o! por lo que es ms conveniente usar las ideas de prueba de correctitud a medida que se desarrolla el programa. Por otra parte! si sabemos que un programa es correcto! no tendr sentido $acer muc$as pruebas al programa con casos de prueba! slo se $arn las necesarias para corroborar que no cometimos un error! como $umanos que somos! por ejemplo! en la transcripcin del programa3 adems ! as tambi0n reduciremos la cantidad de tiempo

dedicada a la tediosa tarea del +debugging,. Para ello trataremos el tema de especi'icacin de programas %o problemas( " el concepto de prueba 'ormal de programas a partir del signi'icado 'ormal %la semntica( de los constructores bsicos %es decir! las instrucciones del lenguaje de programacin( que utili aremos para $acer los programas. *onscientes de que estas notas van dirigidas a un primer curso sobre ense)an a de la programacin! el en'oque que llevaremos a cabo trata de balancear el uso de la intuicin " el sentido com#n! con t0cnicas ms 'ormales de desarrollo de programas.

1.1.

Problemas, algoritmos y programas

&n problema es una situacin donde se desea algo sin poder ver inmediatamente la serie de acciones a e'ectuar para obtener ese algo. Resolver un problema consiste primero que nada en comprender de qu0 trata " especificarlo lo ms 'ormalmente posible con el propsito de eliminar la ambigedad! la inconsistencia " la incompletitud! con miras a obtener un enunciado claro! preciso! conciso " que capture todos los requerimientos. 5ormalmente la especi'icacin en lenguaje natural lleva consigo problemas de inconsistencia! ambig6edad e incompletitud3 es por esto que nos valemos de lenguajes ms 'ormales como las matemticas %lgica! teora de conjuntos! lgebra! etc.( para evitar estos problemas. Ejemplo de ambig6edad7 la 'rase +8ira al $ombre en el patio con un telescopio, se presta a ambig6edad. /&tili amos un telescopio para mirar al $ombre en el patio o el $ombre que miramos tiene un telescopio1 Ejemplo de inconsistencia7 Por inconsistencia entendemos que en el enunciado podamos incurrir en contradicciones. Ejemplo sobre el procesador de palabras7 - 9odas las lneas de te-to tienen la misma longitud! indicada por el usuario. - &n cambio de lnea debe ocurrir solo despu0s de una palabra! a menos que el usuario pida e-plcitamente la divisin por slabas. La inconsistencia resulta al preguntarse /Si la palabra es ms larga que la lnea1 Entonces si el usuario no pide e-plcitamente la divisin por slabas! esta lnea tendr ma"or longitud. Ejemplo de incompletitud7 Por incompletitud entendemos que no todos los t0rminos est0n bien de'inidos o que no est0n capturados todos los requerimientos del problema. En un manual de un procesador de palabras encontramos la 'rase +Seleccionar es el proceso de designar las reas de su documento sobre las cuales desea trabajar, /qu0 signi'ica designar! colocar el +ratn, dnde1 /qu0 signi'ica rea1 /cmo deben ser las reas1 /es una sola rea1 En otras palabras! se trata de encontrar una representacin del problema donde todo est0 dic$o! sea mediante gr'icos! o utili ando otro lenguaje distinto al natural %ej. las matemticas(. En esta etapa interviene el proceso de abstraccin! que permite simpli'icar el problema! buscando modelos abstractos equivalentes " eliminando in'ormaciones super'luas.

&n problema no estar del todo bien comprendido si no $emos encontrado una representacin en la cual todos los elementos que intervienen sean representados sin redundancia! sin ambig6edad " sin inconsistencias. El universo de b#squeda de la solucin estar en ese momento bien delimitado " con 'recuencia surgir en 'orma ms clara la di'icultad principal del problema. El problema se convierte en ms abstracto " ms puro. ;ablamos entonces de un enunciado cerrado. Por ejemplo! si queremos determinar la ruta ms corta para ir de *aracas a <arquisimeto en automvil! podemos tomar el mapa vial de =ene uela " modelarlo a trav0s de un gra'o como en la 'igura 4! donde los nodos o v0rtices seran las ciudades " los arcos las vas de comunicacin e-istentes entre las ciudades. A cada arco asociamos el n#mero de >ilmetros de la va que representa " luego intentamos buscar la solucin en el gra'o.
=a de comunicacin ciudad

?igura 4 En matemticas la 'orma ms general de enunciado de un problema se puede escribir como7 +Encontrar en un conjunto @ dado! los elementos - que satis'acen un conjunto dado de restricciones A%-(,. Por ejemplo7 encontrar en el conjunto de los n#meros naturales los n#meros - tales que -: B CD E DF-. Gbservacin7 *uando damos el espacio @! generalmente damos implcitamente la estructura de @ " las operaciones lcitas sobre @. El conocimiento de @ es un condensado crucial de in'ormacin.

&na ve que obtenemos una especi'icacin del problema que corresponda a un enunciado cerrado! en la prctica lo que $acemos es precisar a#n ms la especi'icacin mediante la descomposicin del problema en subproblemas ms concretos %$acemos un diseo descendente del problema(! $asta llegar a un punto del re'inamiento del enunciado en donde sabemos llevar a cabo las acciones en 0l descritas. En ese momento tenemos la solucin del problema! "a sea porque encontramos los resultados buscados o porque obtenemos un algoritmo que resuelve el problema! es decir! una descripcin de cmo llevar a cabo un conjunto de acciones! que sabemos reali ar a priori! sobre los datos del problema! para obtener los resultados buscados3 en este #ltimo caso decimos que tenemos una solucin algortmica del problema. Por ejemplo7 +.eterminar - en los n#meros enteros tal que - B D E :,

Este enunciado es equivalente a +.eterminar - en los n#meros enteros tal que - B D H D E : H D, porque conocemos las propiedades del conjunto de los n#meros enteros. Pero este enunciado nos lleva! por aplicacin de las propiedades de n#meros enteros %son estas propiedades las que consideramos cruciales conocer para resolver el problema(! al siguiente enunciado que es la solucin del problema7 +.eterminar - en los n#meros enteros tal que - E I4 ,. En este caso obtenemos directamente el n#mero buscado. 5uestro inter0s ser buscar la solucin de un problema como una descripcin de una accin que manipula los datos $asta llegar al resultado! a esta descripcin la llamamos algoritmo. Una accin es un evento producido por un actor! que llamamos el ejecutante3 por ejemplo! una calculadora puede llevar a cabo la accin de sumar dos n#meros! la calculadora sera el ejecutante de esa accin. &na accin toma lugar durante un perodo de tiempo 'inito " produce un resultado bien definido y previsto. La accin requiere de la e-istencia de datos sobre los cuales se ejecuta para producir nuevos datos que re'lejan el e'ecto esperado. Los datos que nos da el enunciado del problema poseen normalmente una estructura que los caracteri a %ej.! son n#meros! conjuntos! secuencias! etc.( " que llamaremos el tipo del dato o la clase del dato. Una clase o tipo de dato viene dado por un conjunto de valores " su comportamiento! es decir! un conjunto de operaciones que podemos reali ar con estos valores %por ejemplo! sobre los n#meros naturales podemos sumar dos n#meros! restar! multiplicar! etc.(. Un objeto lo podemos caracteri ar por su identificacin! su clase tipo " su valor. .ecimos que un objeto es un ejemplar (o instancia) de su clase. Podemos decir que un algoritmo! en ve de manipular datos! manipular objetos. Por ejemplo7 en el problema de la b#squeda del camino ms corto entre dos ciudades de =ene uela dado antes! el gra'o es la clase de datos involucrada en la especi'icacin 'inal. &n gra'o tiene operaciones bien de'inidas que podemos reali ar sobre 0l! como por ejemplo7 agregar un nodo! eliminar un arco! etc. El mapa de =ene uela " las distancias entre ciudades son los datos del problema " si vemos el mapa como un gra'o! este mapa particular ser un objeto de la clase grafo. El conjunto de valores de los objetos manipulados por una accin! observados a un instante de tiempo dado t del desarrollo de 0sta! es llamado el estado de los objetos manipulados por la accin en el instante t. Los valores de los objetos al comien o de la accin los llamamos los datos de entrada de la accin " de'inen el estado inicial. Los valores de los objetos al concluir la accin los llamamos datos de salida o resultados " de'inen el estado 'inal. Si una accin puede ser descompuesta en un conjunto de acciones a reali ar de manera secuencial! entonces diremos que la accin es un proceso secuencial. &n proceso secuencial no es ms que una secuencia de acciones %o eventos(. Retomando la de'inicin del t0rmino algoritmo! podemos decir que un algoritmo es una descripcin de un esquema o patrn de reali acin de un proceso o conjunto de procesos similares mediante un repertorio 'inito " no ambiguo de acciones elementales que se supone reali ables a priori. E-tenderemos el t0rmino accin a la descripcin misma del evento " diremos que el algoritmo es la accin que $a" que llevar a cabo para resolver el problema. *uando un

algoritmo est e-presado en t0rminos de acciones de un lenguaje de programacin! diremos que es un programa. Por ejemplo7 $acer una torta es una accin! esa accin se descompone en varias acciones ms simples %agregar los ingredientes! me clarlos! etc.( que seran el proceso que se lleva a cabo. La receta de la torta es el algoritmo o la descripcin del proceso a seguir para $acer la torta. *uando decimos +conjunto de procesos similares, queremos decir que un algoritmo normalmente describe un proceso no slo para un conjunto de datos de entrada espec'icos! sino para todos los posibles valores que puedan tener los objetos involucrados. Por ejemplo! cuando describimos el algoritmo de la multiplicacin de dos n#meros naturales no lo $acemos para dos n#meros espec'icos %por ejemplo! J " :K( sino de una manera ms general! de 'orma que describa la multiplicacin de cualesquiera dos n#meros naturales. Ejemplo7 Enunciado del problema7 &n ve$culo que se despla a a una velocidad constante v! consume l litros de gasolina cuando recorre > >ilmetros. .eterminar la cantidad r de gasolina que consumira el ve$culo a la velocidad v si recorre - >ilmetros. 5ote que el problema tiene un enunciado ms general que el problema que consiste en buscar la ruta mnima entre dos ciudades espec'icas de =ene uela! en el sentido que independientemente de los valores de v! >! l " - %implcitamente cada una de las cantidades deben ser no negativas(! queremos determinar un algoritmo que resuelva el problema %que calcule la cantidad r(. Por lo tanto un mismo algoritmo deber resolver el problema para valores particulares de v! >! l " -. Podemos ver a v! >! l! -! r como variables %al igual que en matemticas( que pueden contener valores de un determinado tipo o clase de datos. En este caso el tipo de dato de todas estas variables es +n#mero real,. .e igual 'orma! podemos 'ormular un problema ms general que el dado sobre la ruta mnima entre dos ciudades de =ene uela! de la siguiente 'orma7 Lueremos buscar la ruta mnima para ir de una ciudad @ a una ciudad M en un pas N. En este caso tendremos tres variables que representan los objetos involucrados en el problema! a saber! dos ciudades " un pas. 5ormalmente los problemas se presentan de esta 'orma. Es ms #til encontrar un algoritmo para multiplicar dos n#meros cualesquiera! que un algoritmo que sirva para multiplicar : por D solamenteO Ejemplos sobre correctitud versus anlisis de casos de prueba Primer ejemplo7 Ejemplo que muestra que la intuicin no basta para desarrollar un algoritmo que resuelve un problema7

Se quiere pelar un n#mero +su'iciente, de papas que estn en un cesto. El cesto de papas puede vaciarse en cualquier momento " podemos reponer el cesto con papas una ve 0ste se vace. Solucin7 =ersin 47 8ientras el n#mero de papas peladas sea insu'iciente $acer lo siguiente7 Si el cesto no est vaco entonces pelar una papa Este algoritmo 'unciona cuando el n#mero de papas a pelar es menor o igual al n#mero de papas en el cesto. Si el cesto posee menos papas que las requeridas entonces caemos en un ciclo in'inito %proceso sin 'in( una ve que se vace el cesto =ersin :7 8ientras el cesto no est0 vaci $aga lo siguiente7 Pelar una papa Pelar una papa Se pelan tantas papas como $a" en el cesto si el n#mero de papas originalmente es par. Si el n#mero inicial de papas es impar entonces $a" una accin en el proceso que no puede ser ejecutada. Slo cuando el cesto tiene el n#mero de papas requerido el algoritmo resuelve el problema. =ersin D7 8ientras el cesto no est0 vaco " el n#mero de papas peladas sea insu'iciente $aga lo siguiente7 Pelar una papa Este algoritmo no cae en ciclo in'inito ni tratar de ejecutar una accin que es imposible de reali ar. Sin embargo! solo cuando el cesto contiene el n#mero de papas requerido el algoritmo resuelve el problema. =ersin J7 8ientras el cesto no est0 vaco $acer lo siguiente7 8ientras el n#mero de papas peladas sea insu'iciente $acer lo siguiente7 Pelar una papa ;agamos un diagrama de estados a medida que se ejecuta el proceso partiendo de todos los posibles estados iniciales. Este diagrama tambi0n se conoce como +corrida en 'ro, o +simulacin del algoritmo,.

%=A! I5S( accin de observacin del cesto %=A! I5S( el proceso termina sin $aber resuelto el problema

%5=A! I5S( accin de observacin del cesto %5=A! I5S( observacin n#mero papas peladas %5=A! I5S( pelar una papa

%=A! I5S( Gbs. nR papas peladas %=A! I5S( Pelar papa Imposible

%=A! S&?( Gbs. nR papas peladas %=A! S&?( Gbs. del cesto %=A! S&?(

%5=A! S&?( Gbs. nR papas peladas %5=A! S&?( Gbs. del cesto %5=A! S&?( Gbs. nR papas peladas %5=A! S&?(

%5=A! I5S(

*iclo in'inito

9ermina " resuelve el problema

?igura : .escripcin de los estados7 =A E cesto vaco! I5S E 5#mero insu'iciente de papas peladas 5=A E cesto no vaco S&? E n#mero su'iciente de papas peladas

Estados iniciales posibles7 %=A! I5S( " %5=A! I5S( En las 'igura : vemos el proceso que genera el algoritmo partiendo respectivamente de los estados iniciales %=A! I5S( " %5=A! I5S( =ersin P7 8ientras el n#mero de papas no sea su'iciente $acer lo siguiente7 Si el cesto no est vaco entonces pelar una papa en caso contrario llenar el cesto con papas

%=A! I5S( Gbs. nR papas peladas %=A! I5S( Gbs. del ceston n#mero %=A! I5S( papas Llenar cesto %5=A! I5S(

%5=A! I5S( Gbs. nR papas peladas %5=A! I5S( Gbservacin del cesto %5=A! I5S( pelar una papa

%=A! S&?( Gbs. nR papas peladas 9ermina " Resuelve el problema

%5=A! I5S( %=A! I5S( %5=A! S&?( Gbs. nR papas Gbs. nR papas peladas peladas %5=A! S&?( %=A! I5S( Gbs. del cesto %=A! I5S( Llenar cesto %5=A! I5S(

9ermina " resuelve el problema

?igura D Esta versin es correcta! es decir! es un algoritmo que resuelve el problema! no e-isten acciones imposibles de reali ar en la ejecucin! ni cae en ciclo in'inito " cuando termina se $abrn pelado el n#mero de papas requerido. El diagrama de estados de la 'igura D con'irma este $ec$o. .emostrar la correctitud del algoritmo anterior signi'ica demostrar que partiendo de cualquier estado! al ejecutar el algoritmo! 0ste termina en un tiempo 'inito " cuando termina! este resuelve el problema %el estado 'inal ser S&? para el n#mero de papas peladas(. Para este problema en particular! el diagrama de estados nos permite veri'icar la correctitud de nuestro problema " esto se debe a que el n#mero posible de estados es mu" reducido " podemos $acer una corrida completa para todos los estados iniciales posibles. Este no ser el caso general! " no podremos utili ar el diagrama de estados %o corrida en 'ro( para veri'icar la correctitud del algoritmo pues el espacio de estados ser! en general! in'inito. Parte de la veri'icacin de la correctitud debe ser +el algoritmo termina,! o sea! que el algoritmo no debe caer en ciclos in'initos. =emos que el diagrama de estados! en este caso!

nos permite comprobar esto! "a que todo ciclo pasa por la accin +pelar papa, " como el n#mero de papas que se quiere pelar es 'inito! estos ciclos sern 'initos. M cuando el algoritmo termina! se v0 que termina en un estado que resuelve el problema. =ersin Q7 En la vesin anterior $a" un problema de estilo7 la accin que se repite no siempre es +pelar papa,! pero lo lgico es pelar una papa cada ve que se observa que $a" un n#mero insu'iciente de papas. &na versin +mejor,7 8ientras el n#mero de papas peladas sea insu'iciente $acer lo siguiente7 Si el cesto est vaco entonces llenar el cesto con papas Pelar una papa Las acciones que se repiten %el cuerpo del mientras( tienen un resultado previsible cada ve que se ejecutan7 independientemente del estado inicial de la accin! al concluir 0sta! se $a pelado una papa. En la versin %P( al concluir la accin que se repite no sabremos si se $a pelado una papa o no. Ejercicio7 .ibuje el diagrama de estados de la versin %Q( " veri'ique que el algoritmo es correcto. Estudie de la misma manera las siguientes versiones7 a( 8ientras el n#mero de papas peladas sea insu'iciente $acer lo siguiente7 8ientras el cesto no est0 vaco $acer7 Pelar una papa b( 8ientras el n#mero de papas peladas sea insu'iciente o el cesto no est0 vaco $acer7 Pelar una papa c( Si el cesto est vaco entonces llenarlo Pelar una papa 8ientras el n#mero de papas peladas sea insu'iciente $acer7 Si el cesto no est vaco entonces pelar una papa Si el cesto est vaco entonces llenar el cesto " pelar una papa /En esta versin las acciones que se repiten tienen siempre como estado 'inal $aber pelado e-actamente una papa1. /*ree usted que esta versin es poco elegante1 /Por qu01. Segundo ejemplo %importancia de las especi'icaciones " del ra onamiento sobre programas(7

Supongamos que $emos escrito un programa mu" largo que! entre otras cosas! calcula! como resultados intermedios! el cociente q " el resto r de dividir un entero no negativo x entre un entero positivo y. Por ejemplo! para xEF e yE:! el programa calcula qED " rE4. El tro o de programa que calcula el cociente " el resto es mu" simple! pues consiste en el proceso de sustraer tantas veces y a una copia de x, guardando el n#mero de sustracciones que se $a"an e'ectuado! $asta que una sustraccin ms resulte en un n#mero negativo. El tro o de programa! tal " como aparece en el programa completo es el siguiente %los puntos +..., son para indicar que el tro o de programa est inserto en otro programa ms grande(7 ... r 7E -3 q7ES3 mientras rT" hacer comienzo r7ErI"3 q7E qB4 fin; ... *omencemos a depurar el programa. Respecto al clculo del cociente " el resto! sabemos claramente que inicialmente el divisor no debe ser negativo " que despu0s de concluir la ejecucin del tro o de programa! las variables deberan satis'acer7 - E "Uq B r .e acuerdo a lo anterior! agregamos algunas instrucciones para imprimir algunas variables con la 'inalidad de revisar los clculos7 ... escribir %Vdividendo - EW! -! Vdivisor " EW! "(3 r 7E -3 q7ES3 mientras rT" hacer comienzo r7ErI"3 q7E qB4 fin; escribir % V "Uq B r E W! "Uq B r(3 ... .esa'ortunadamente! como este tro o de programa se ejecuta muc$as veces en una corrida del programa! la salida es mu" voluminosa. En realidad queremos conocer los valores de las variables slo si ocurre un error. Supongamos que nuestro lenguaje de programacin permite evaluar e-presiones lgicas cuando estas aparecen entre llaves! " si la evaluacin de la e-presin lgica resulta 'alsa entonces el programa se detiene e imprime el estado de las variables en ese momento3 si la evaluacin de la e-presin es verdadera! entonces el programa contin#a su ejecucin normalmente. Estas e-presiones lgicas son llamadas aserciones, debido a que estamos a'irmando que ellas sern verdaderas en el instante justo despu0s de la ejecucin de la instruccin anterior a ella.

4S

A pesar de la ine'iciencia que signi'ica insertar aserciones! pues aumenta el n#mero de clculos que debe $acer el programa! decidimos incorporarlas pues es pre'erible que el programa detecte un error cuando sea utili ado por otros a que arroje resultados errneos. Por lo tanto incorporamos las aserciones al programa! " eliminamos las instrucciones de escritura7 ... X"TSY r 7E -3 q7ES3 mientras r T " hacer comienzo r 7E rI"3 q 7E qB4 fin; X - E "Uq B r Y ... .e esta 'orma! nos a$orramos largos listados %papel impreso( en el proceso de depuracin. En una corrida de prueba! el c$equeo de aserciones detecta un error debido a que y es S justo antes del clculo del cociente " el resto. 5os lleva J $oras encontrar " corregir el error en el clculo de y. Luego! ms adelante! tardamos un da en seguirle la pista a un error que no 'ue detectado en las aserciones! " determinamos que el clculo del cociente " el resto 'ue7 - E Q! " E D! q E 4! r E D *omo vemos! las aserciones son verdaderas para estos valores. El problema se debe a que el resto $a debido ser menor estricto que el divisor " no lo es. .etectamos que la condicin de continuacin del proceso iterativo % el mientras( $a debido ser %r "( en lugar de %r T "(. Si $ubi0semos sido lo su'icientemente cuidadosos en colocar en la asercin del resultado otras propiedades que debe cumplir el cociente " el resto! es decir! si $ubi0semos utili ado la asercin ms fuerte %- E "Uq B r(%r Z "(! nos $abramos a$orrado un da de trabajo. *orregimos el error insertando la asercin ms 'uerte7 ... X"TSY r 7E -3 q7ES3 mientras r " hacer comienzo r 7E r I "3 q 7E qB4 fin; X %- E "Uq B r(%r Z "( Y ... Las cosas marc$an bien por un tiempo! pero un da obtenemos una salida incomprensible. Resulta que el algoritmo del cociente " resto produjo un resto negativo r E I:. M nos damos cuenta que r es negativo debido a que inicialmente - era H:. ;ubo otro error en el clculo de los datos de entrada del algoritmo de cociente " resto! pues se supone que - no puede ser negativo. ;emos podido a$orrar tiempo en detectar este error si nuevamente $ubi0semos

44

sido cuidadosos en 'ortalecer su'icientemente las aserciones. &na ve ms ! arreglamos el error " re'or amos las aserciones7 ... X % - S( %" T S( Y r 7E -3 q7ES3 mientras r " hacer comienzo r7ErI"3 q7E qB4 fin; X %- E "Uq B r(% S r Z "( Y ... Parte del problema que $emos con'rontado se debe a que no $emos sido lo su'icientemente cuidadosos en especi'icar lo que el tro o de programa debe $acer. ;emos debido comen ar por escribir la asercin inicial % - S( %" T S( " la asercin 'inal %- E "Uq B r( % S r Z "( antes de escribir el tro o de programa! "a que son estas aserciones las que con'orman la de'inicin de cociente " de resto. Pero! /qu0 podemos decir del error que cometimos en la condicin del proceso iterativo1. /Lo $emos podido prevenir desde un comien o1. /E-iste alguna manera de probar! a partir del programa " las aserciones! que las aserciones son verdaderas en cada punto de la ejecucin del programa donde ellas aparecen1. =eamos lo que podemos $acer. *omo antes del mientras se cumple - E r " q E S! vemos que tambi0n se cumple parte del resultado antes del mientras7 %4( - E "Uq B r

Adems ! por las asignaciones que se $acen en el cuerpo del mientras! podemos concluir que si %4( es verdad antes de la ejecucin del cuerpo del mientras entonces es verdad despu0s de su ejecucin. As %4( ser verdad antes " despu0s de la ejecucin de cada iteracin del mientras. Insertemos %4( en los lugares que corresponde " $agamos las aserciones tan 'uertes como sea posible7 ... X % - S( %" T S( Y r 7E -3 q7ES3 X %S r( %S Z "( %- E "Uq B r( Y mientras r " hacer comienzo X %S r( %S Z " r( %- E "Uq B r( Y r 7E rI"3 q 7E qB4 X %S r( %S Z "( %- E "Uq B r( Y fin; X %- E "Uq B r( %S r Z "( Y ...

4:

/*mo podemos probar que la condicin es correcta1. *uando el mientras termina la condicin debe ser 'alsa " queremos que r Z "! por lo que el complemento! r " debe ser la condicin correcta del mientras. .el ejemplo anterior se desprende que si supi0ramos encontrar las aserciones ms 'uertes posibles " aprendi0ramos a ra onar cuidadosamente sobre aserciones " programas! no cometeramos tantos errores! sabramos que nuestro programa es correcto " no necesitaramos depurar programas %slo correramos casos de prueba para aumentar la con'ian a en un programa que sabemos est correcto3 encontrar un error sera la e-cepcin " no la regla(. Por lo que los das gastados en correr casos de prueba! e-aminar listados " buscar errores! podran ser invertidos en otras actividades. 9ercer ejemplo %ra onar en t0rminos de propiedades del problema " no por casos de prueba(7 Para mostrar lo e'ectivo que puede ser adoptar una metodologa como la que proponemos! ilustremos el siguiente ejemplo7 Supongamos que tenemos un recipiente de ca'0 que contiene algunos granos negros " otros blancos " que el siguiente proceso se repite tantas veces como sea posible7 Se toma al a ar dos granos del recipiente. Si tienen el mismo color se botan 'uera " colocamos otro grano negro en el recipiente %$a" su'icientes granos negros disponibles para $acer esto(. Si tienen color di'erente! se coloca el grano blanco de vuelta en el recipiente " se bota el grano negro. La ejecucin de este proceso reduce en uno el n#mero de granos en el recipiente. La repeticin de este proceso terminar con un grano en el recipiente "a que no podremos tomar dos granos para continuar el proceso. La pregunta es7 /qu0 puede decirse del color del grano 'inal en 'uncin del n#mero de granos blancos " negros inicialmente en el recipiente1 Piense un poco.... *omo vemos! no a"uda muc$o intentar con casos de prueba. 5o a"uda muc$o ver qu0 pasa cuando $a" dos granos de color distinto! o dos blancos " uno negro! etc.3 aunque e-aminar casos peque)os permite obtener una mejor comprensin del problema. En lugar de esto! proceda como sigue7 qui s e-ista una propiedad sencilla de los granos en el recipiente que permanece cierta una vez que tomamos dos granos y colocamos el grano que corresponde en el recipiente, " que junto con el $ec$o de que slo quedar un grano! pueda dar la respuesta. *omo la propiedad siempre permanecer cierta! nosotros la llamamos un invariante. 9ratemos de buscar tal propiedad. Suponga que cuando terminamos tenemos un grano negro. /Lu0 propiedad es verdad cuando terminamos que podramos generali ar! qui s! para que sea nuestro invariante1 &na sera +e-iste un n#mero impar de granos negros en el

4D

recipiente,! as! qui s la propiedad de permanecer impar el n#mero de granos negros sea cierta. Sin embargo! este no es el caso! pues el n#mero de granos negros cambia de par a impar o de impar a par con cada ejecucin de un paso del proceso. Pero tambi0n $abra cero granos blancos cuando terminamos3 es posible que la propiedad de permanecer par el n#mero de granos blancos sea cierta. M! en e'ecto! cada ejecucin del proceso termina con dos granos blancos de menos en el recipiente o con la misma cantidad de granos blancos. Por lo tanto! el #ltimo grano es negro si inicialmente $a" un n#mero par de granos blancos3 de otra 'orma! el #ltimo grano ser blanco. La solucin al problema anterior es sumamente simple! pero e-tremadamente di'cil de encontrar viendo slo casos de prueba. El problema es ms 'cil de resolver si buscamos propiedades que permanecen ciertas. &na ve encontradas! estas propiedades nos permiten ver de una manera sencilla que $emos encontrado una solucin. Este problema nos permite ver tambi0n el siguiente principio7 $a" que conocer " entender en detalle el enunciado del problema " las propiedades de los objetos que van a ser manipulados por el programa que resuelve el problema.

4J