2

INSTITUTO TECNOLOGICO HUAQUILLAS

PRIMER NIVEL

ASIGNATURA: INTRODUCCION A LA PROGRAMACION

PROFESOR: ING. ROBIN ZAMBRANO CORREA

ESTUDIANTE: JANNETH ACARO PARDO

QUE ES UN ALGORITMO

Muchas veces se tiende a confundir un algoritmo con algo netamente computacional o tecnológico. En el fondo no es así.

Un algoritmo es básicamente una lista definida, ordenada y finita que nos indica como resolver un problema determinado bien básico y definido para una operación determinada.

Si no quedó muy claro, utilizaremos otro ejemplo que nos ocurrió en la Universidad:

El mismo profesor que nos indicó la estupidez de nuestros queridos computadores, el día que nos quiso enseñar lo que eran los algoritmos, nos pidió el primer día de clases y sin darnos explicación alguna que definiéramos el algoritmo para hacer un huevo frito.

La cara de duda era unánime en los rostros presentes, ya que todos nosotros, sin experiencia previa, relacionábamos los algoritmos con procesos netamente computacionales, entonces no tenía lógica alguna.  Luego nos otorgó la ayuda necesaria diciéndonos: “Lo que necesito es que me definan lo que Uds. harían desde un principio para hacer un huevo frito”.

Fue ahí donde nos dimos cuenta que uno puede definir algoritmos para cualquier tipo de procesos, desde los de la vida misma hasta cosas más evolucionadas y tecnológicas.

Ahora, a diferencia de como uno ve los problemas en la vida real, al realizar un algoritmo sobre cualquier cosa, siempre es bueno plantearse los supuestos de cualquier problema que pudiese ocurrir y que soluciones se pueden establecer al respecto.

¿A qué vamos con esto?, a darnos cuenta de que los algoritmos son la premisa básica de cualquier solución de programación que vayamos a implementar. Con sus operaciones, sus supuestos, su contingencia y su desarrollo estructurado. Mientras más completos sean los algoritmos que nos planteamos, mejor será nuestra programación propiamente tal.

Veamos un ejemplo, ¿les parece?, ya que después de tanta teoría vamos a marearnos un poco. Viendo la misma historia antes mencionada, intentemos hacer un algoritmo (básico) de como haríamos un huevo frito:

Algoritmo para hacer un huevo frito:

1. Voy a la cocina.
2. Saco un huevo del refrigerador.
3. Saco una sartén.
4. Pongo un poco de aceite en la sartén.
5. Hecho el huevo a la sartén.
6. Lo frío.
7. Me lo como.

Si bien tenemos los pasos básicos establecidos de forma correcta, podemos empezar a ver de que nuestro algoritmo tiene ciertas fallas, como por ejemplo: ¿Qué pasa si no hay huevos?, ¿Qué pasa si no hay aceite?, ¿Qué pasa si no hay gas?. Pueden ser preguntas y respuestas algo básicas, pero reflejan lo que decíamos de plantearnos supuestos. Cuando programamos siempre tenemos que cubrir todos los aspectos necesarios, ya que por muy bien que conozcamos nuestro programa, el usuario puede no saberlo todo, y es por esto que debemos estar preparados para cubrir cualquiera de estas situaciones. Una versión mejorada del algoritmo sería:

Algoritmo para hacer un huevo frito 2.0:

1. Voy a la cocina.
2. Veo si hay huevos en el refrigerador.
3. Si hay, saco un huevo y salto al paso 8
4. Si no hay, voy a comprar.
5. Para comprar, voy a buscar plata.
6. Si hay plata, saco y voy al paso 8
7. Si no hay plata, no se hace el huevo frito.
8. Veo si hay gas.
9. Si hay, prendo la cocina y voy al paso 14.
10. Si no hay, busco dinero para pedir gas.
11. Si no hay dinero, no hago el huevo.
12. Si hay, encargo y salto al paso 14.
13. Espero que llegue el gas.
14. Saco una sartén.
15. Si no hay sartén, no hago el huevo.
16. Etc, etc.

Creo que la idea se entiende. Si, es cierto, puede parecer excesivo ponerse en todos los supuestos y quizás estemos cubriendo aspectos sumamente extraños, pero mientras más situaciones que puedan ocurrir consideremos y tengamos soluciones presentes para eso, más completo será nuestro algoritmo y por ende nuestro programa.

En el fondo siempre debemos pensar que existe la “mala intención de los usuarios”, un concepto que más adelante veremos en detalle y que es una de las cosas más importantes a tener en consideración por parte de los programadores.

Es una excelente práctica empezar con el tema de los algoritmos. Empezar a plantearnoslos para resolver distintas situaciones, desde la vida cotidiana, hasta situaciones computacionales, linguísticas, de lógica, matemática, en realidad para todo. Siempre que hay un problema, hay un algoritmo que se pueda realizar para encontrar la solución.

Así que los instamos a practicar un poco este tema, mientras nosotros vamos desarrollando la que será la segunda parte de esta guía para aprender a programar y no morir en el intento.

Por ahora lo dejaremos hasta aquí, ya que hemos cubierto los aspectos más básicos y necesarios y han leído bastante. Es momento de descansar la vista un poco y seguir pensando, que es la mejor práctica posible.

CARACTERÍSTICAS DE LOS ALGORITMOS         

- Finitos: Debe acabar en algún momento.

- Eficientes: Deben ocupar la mínima memoria y minimizar el tiempo de ejecución.

- Legibles: El texto que lo describe debe ser claro, tal que permita entenderlo y leerlo      fácilmente.

- Modificables: Estarán diseñados de modo que sus posteriores modificaciones  sean fáciles de 

realizar, incluso por programadores diferentes a sus propios autores.

- Modulares: La filosofía utilizada para su diseño debe favorecer la división del problema en 

módulos pequeños.

- Único punto de entrada, único punto de salida: A los algoritmos y a los módulos que lo integran 

se entra por un sólo punto, inicio, y se sale por un sólo punto también, fin.

LA ESTRUCTURA GENERAL PARA LA RESOLUCIÓN INFORMÁTICA DE UN PROBLEMA 

SERÁ LA SIGUIENTE:

1.- Análisis del problema.

Haremos un estudio previo de la tarea a realizar. Si nos la dan verbalmente, haremos preguntas hasta  

tener claro lo que se ha de hacer, es decir, hasta obtener la escritura detallada de todas las 

especificaciones. Si la tarea nos la dan por escrito, podemos comenzar subrayando palabras o frases 

decisivas, escribiendo al margen ideas y dudas, o cualquier otra cosa que nos ayude a concretar 

especificaciones, además de realizar verbalmente todas las preguntas  que den respuesta a nuestras dudas.

Algunas preguntas elementales serán las siguientes:

-                 ¿Cuáles serán los datos de entrada?.

- ¿Qué datos se piden de salida?.

- ¿Qué apariencia (formato) tendrán los datos?.

- ¿Cuántas veces se deben repetir los procesos?.

- ¿Hay que hacer suposiciones?. En caso afirmativo se hará un listado de ellas.

- ¿Pueden aparecer condiciones especiales de error?

- ¿Hemos resuelto algún problema parecido o sabemos que existe una solución para una tarea 

análoga?. Si la respuesta es afirmativa usemos esa solución, aunque hubiera que modificarla.

- ¿Hay juegos de ensayo adecuados?. Búsquelos.

2.- Escribir en pseudocódigo el programa principal.

Empezaremos dividiendo el problema en módulos más sencillos, hasta llegar a un nivel de detalle 

razonable utilizando nombres con significado para ellos. Si de momento no sabemos resolver alguno de 

estos módulos, no debemos preocuparnos pensemos que alguien nos lo resolverá o que mañana tendremos 

una idea genial para solucionarlo y sigamos adelante con nuestro diseño, tal vez tengamos la suerte de 

encontrarlo ya hecho. Recordemos que si los problemas son razonablemente pequeños, como ocurrirá en 

los primeros temas no será necesaria esta división en subtareas del problema.

3.- Escribir en pseudocódigo los módulos restantes.

Escribiremos cada uno de los módulos, detallando la secuencia de instrucciones que deben realizar, en el 

caso de que los hubiera. 

4.- Lectura del pseudocódigo.

Recorrer el algoritmo escrito en pseudocódigo inspeccionando, reordenando, detectando y corrigiendo 

errores, revisando todo lo que sea necesario, incluso será posible que haya que planificar algún cambio. No hay que tener miedo a empezar de nuevo si fuera necesario.

5.- Seguir la traza.

Haremos la prueba del algoritmo siguiendo la traza con los datos elegidos como juego de ensayo. 

Observaremos los resultados minuciosamente, tratando de detectar y corregir los errores si estos 

resultados no son los esperados.

6.- Documentación.

Una vez diseñado y bien estructurado un algoritmo, la siguiente actividad a desarrollar, sumamente 

importante en programación, es producir programas bien documentados, para que se cumplan los 

objetivos básicos, que los programas sean legibles, comprensibles y fácilmente modificables.

La documentación incluye descripciones, comentarios, especificaciones, incluso un breve manual de uso 

si el algoritmo es suficientemente extenso.

Tenemos dos tipos de documentación en el desarrollo de algoritmos bien diseñados:

a)       Documentación externa: Incluye la escritura de información que es exterior al cuerpo del 

algoritmo. Puede incluir, además de todas las especificaciones detalladas, una explicación extensa del 

desarrollo del algoritmo y de las modificaciones sufridas. Deben añadirse igualmente descripciones 

detalladas del problema, de los módulos que lo componen, adjuntando un diagrama jerárquico del diseño 

descendente y por último un manual de usuario donde se explicará al cliente (o al profesor en su defecto) 

como debe usarse el programa. Esta documentación debe adjuntarse sólo en el caso de que los algoritmos 

sean suficientemente grandes, lo que se consideran aplicaciones informáticas de cierta envergadura, 

divididas en varios programas. 

b)       Documentación interna: Incluye la escritura de información que se suministra con el cuerpo del 

algoritmo. Estará formada por comentarios, código autodocumentado e impresión agradable del texto del 

pseudocódigo. 

                                              

CONSTANTES Y VARIABLES

En el mundo de la programación se usan valores que no deben variar durante la ejecución de un programa. A estos valores se les conoce como constantes. También existen valores que deben cambiar a lo largo de la ejecución del programa; estos valores son conocidos como variables.

CONSTANTES:

Una constante es una partida de datos que permanecen sin cambios en el programa (durante el desarrollo y ejecución).

Ejemplos:                     

3.1416 (valor de pi, este valor no debe variar)

2000 (año en que según Nostradamus se acabaría el mundo)

‘a’ (primera letra del alfabeto)

“HUAQUILLAS” (nombre de mi querida universidad)

VARIABLES:

Una variable es una partida de datos cuyo valor puede cambiar en el programa (durante el desarrollo y ejecución).

Los diferentes tipos de variables dependen del lenguaje de programación, por lo general estas suelen ser enteras, reales, carácter, lógicas y de cadena.

Tanto las variables como las constantes tienen un nombre o identificador generalmente conformado por caracteres alfanuméricos (ciertos lenguajes de programación admiten el carácter de subrayado ‘_’ como válido en los identificadores), y el primero de éstos debe ser una letra.

Ejemplos:

variable1

numerador

primer_jugador

Por estética y comodidad durante el desarrollo del algoritmo se suele usar palabras en MAYÚSCULAS para las constantes y en minúsculas para las variables. Si se desea usar varias palabras como nombre para una variable, éstas deben estar unidas, la primera palabra en minúsculas y el primer carácter de la segunda en mayúscula (así se ve más bonito).

Ejemplos:

mi Variable

MI CONSTANTE

primer Jugador

CONTADOR Y ACUMULADOR

CONTADOR:

es una variable que acumula las veces que se pasa por ella. Se suele denominar contador cuando el incremento de la variable es de 1 en 1, pero no tiene por qué ser así obligatoriamente. La sintaxis genérica sería: variable = variable + 1.

ACUMULADOR:

es una variable cuyo valor se incrementa o decrementa en un valor que no tiene por qué ser fijo (en cada iteración de un bucle). Un acumulador suele utilizarse para acumular resultados producidos en las iteraciones de un bucle.