ArchiTecnologia

Aprendizaje abierto. Conocimiento libre.

ArchiTecnologia
ProgramaciónTutorial

Programación: etapas de la programación

Me gustaría, antes de seguir con el artículo, dar las gracias a OpenEXPO por la oportunidad de participar y llegar como finalista a los Open Awards 2019, por supuesto dar la enhorabuena al ganador en la categoría que competía (@atareao) y especial agradecimiento también a Alejandro, de Slimbook, que me hizo el favor de asistir a la gala en representación mía. Igualmente gracias a todos los que votaron por ArchiTecnología.

Dicho eso, vamos manos a la obra. Tras la introducción del artículo anterior de esta serie, ahora pasamos a describir los pasos o etapas que hay que seguir para programar. Quizás te parezca algo absurdo, pero igual que comentaba en el primer artículo, no aprender bien esto puede ser un gran error. Algunos se limitan a modificar códigos o snippets ya existentes o a leer un libro de programación para conocer los tipos de variables, datos, constantes, expresiones, etc., y creen que ya saben programar.

Veo fenomenal que uses códigos fuente para modificarlos. Es una buena forma de aprender. Pero no simplemente limitarse a eso. Si lo haces serás un gran modificador de código, pero jamás un programador o desarrollador. Te falta la parte más esencial, saber cómo crear un programa desde cero. Y créeme, si has intentado aprender algún lenguaje de programación así y te has frustrado al intentar crear un programa desde cero.. ¡Es lo más normal!

Más aún si eres como yo, que detesto los lenguajes orientados a objetos. No porque considere que tienen carencias o problemas técnicos de base, es simplemente porque los considero complicados para mi. Llámame limitado, pero es así… me gusta lo simple. Aplicar el principio KISS (Keep It Simple, Stupid) a todo en mi vida, y quizás por eso me llama tanto la atención el mundo UNIX o la esencia de Hispano Suiza de Marc Birkigt…

Así que si buscas tutoriales sobre POO u OOP, hay compañeros que tienen blogs mucho mejores que este para eso. Pero si eres un dinosaurio, como yo, y te gusta especialmente el lenguaje base de UNIX/Linux, aquí tienes tu rinconcito…

Etapas o fases de la creación de un programa:

Las 7 etapas para crear un programa son:

¿Recuerdas el ejemplo de receta que puse en el primero artículo de programación? Lo usaré como ejemplo para seguir con estos pasos… Creo que es bastante intuitivo.

1-Buscar el objetivo

Es la fase donde se enuncia el problema u objetivo que se quiere cumplir. Es decir, qué quieres que haga tu programa. Por lo general no debes ser ambiguo en la definición, debe quedar todo bien explicado. Por ejemplo, si retomo el ejemplo del primer artículo de la serie Programación… no bastaría con decir: «Tengo hambre, quiero comer«. Eso sería la necesidad. Tampoco «Voy a cocinar«, sería ambiguo. ¿Qué vas a cocinar? Podrías hacer multitud de recetas.

Lo correcto sería algo así como: «Voy a cocinar un huevo frito«. Ahora ya queda claro el objetivo, ya no es tan ambiguo. En el caso de un programa, deberías describir qué es exactamente lo que quieres que el ordenador haga: capture y edite texto introduciéndole desde la entrada estándar… (editor de texto), des/comprima un archivo (herramienta de compresión), etc.

2-Analizar el problema

Ya tienes claro qué tienes que hacer. Ya sabes que vas a freír un huevo. Pero necesitas analizar qué ingredientes necesitas. Eso es básicamente lo que debes definir en esta etapa, qué necesitas para tu programa. En el caso culinario que sigo para hacerlo más intuitivo, se corresponde con los ingredientes necesarios (datos de entrada = aceite, sal, huevo), el resultado que quieres conseguir (datos de salida = huevo frito), el procedimiento o método necesario (la fritura), y conocer el hardware (sartén, placa,…), puesto que puede que haya alguna limitación que no te permita hacer lo que quieres. Por ejemplo, que la sartén sea demasiado pequeña para el tamaño del huevo (jajaja esto se resolvería en HPC escalando los recursos, pero no creo que con dos, cuatro u ocho sartenes pequeñas se solucione el problema, a no ser que dividas el huevo…).

Volviendo al ejemplo del programa, el análisis pasa por analizar qué información necesitas obtener el resultado (datos de entrada), la información que se desea producir (datos de salida) y el método para procesar los datos. En el caso de un editor de texto, quieres introducir caracteres desde la entrada estándar o teclado, presentarla en la salida estándar o pantalla (o guardarlo en un fichero), y hacerlo en un determinado formato.

3-Diseño del algoritmo

Es la etapa más creativa, en la que diseñas el algoritmo. Se puede hacer mediante un diagrama de flujo (gráfico) o mediante pseudocódigo (o ambos). Yo intentaré poner los próximos ejemplos de código C con su diagrama y pseudocódigo para que puedas ver la equivalencia.

Ya conoces el objetivo, conoces lo que necesitas, ahora debes trazar el plan: la receta. Los pasos que debes seguir para conseguir el resultado buscado. En el caso del huevo frito, sería algo así como:

  1. Inicio.
  2. Coge una sartén.
  3. Pon la sartén sobre la placa.
  4. Añade aceite a la sartén.
  5. Enciende el fuego.
  6. Espera a que se caliente el aceite.
  7. Parte un huevo.
  8. Agrega el contenido al aceite.
  9. Espera a que esté frito.
  10. Retira la sartén del fuego.
  11. Apaga el fuego.
  12. Retira el huevo del aceite.
  13. Ponlo en un plato.
  14. Fin.

Esa es la receta, los pasos. Pero, esto es un ejemplo muy simple, no hay complicaciones. Para casos más complejos, un diagrama de flujo y el pseudocódigo aclararía mucho. Este paso es vital, de ello dependerá si vas a poder implementar el programa escribiendo código fuente o no. Aquí es donde flaquean los que simplemente aprenden leyendo libros de programación o modificando códigos.

Diagrama de flujo:

partes diagrama flujo

Es la forma gráfica de representar un algoritmo. Se usan varios símbolos que definen los procesos en la computación. Los símbolos se relacionan con los otros siguiendo un orden mediante unas líneas de flujo. El primer bloque será siempre el inicio y lo último será el final u objetivo. Aunque puedes usar los símbolos que quieras, lo mejor es respetar los reglamentados por la ANSI.

  • Inicio y final: se representan con una elipse.
  • Entrada y salida de datos: se representa por un romboide. La entrada es la lectura de datos y la salida la impresión. En cambio, las fuentes de los datos o los destinos pueden ser diversos. Algunos autores suelen usar un símbolo de impresión…
  • Decisión: es un rombo que indica comparación de valores.
  • Proceso: es un recuadro, indicará asignación de un valor en la memoria y/o la ejecución de una operación aritmética/lógica.
  • Conector: es un círculo con algún símbolo en su interior que indica la forma de conexión que se usa.
  • Líneas de flujo: son flechas que indican la dirección del flujo que sigue la ejecución del programa. Entrelazan la secuencia de pasos u operaciones que se deben hacer desde el inicio hasta el final.

Eso en cuanto a los símbolos más básicos. Pero también debes respetar unas reglas:

  • Todo diagrama debe tener inicio y fin.
  • Los símbolos de decisión deben tener más de una línea de salida.
  • El dibujo o diagrama se lee de arriba a abajo y de izquierda a derecha, por tanto, debes posicionar los bloques en consecuencia.
  • No se especifican la declaración de variables.
  • No se suelen usar líneas de flujo que no sean horizontales o verticales, y se debe evitar el cruce de líneas usando conectores. Esto es algo más estético y para evitar confusiones. A veces, cuando diseñas el diagrama lo tienes todo claro, pero cuando vuelves a él pasado un tiempo, puede que el cruce de líneas pueda llevar a errores o confusiones…
  • No debería haber líneas de flujo sin conectar. No es lógico.
  • Puedes usar un símbolo específico para comentarios o anotarlos al margen.
  • Si el diagrama es muy grande y ocupa varias páginas, debes numerarlas para saber el orden. Lo contrario sería un completo desastre.

Estas son algunas de las reglas, pero ahora vamos a ver un ejemplo del diagrama para nuestra receta (aunque no sea del todo adaptable al diagrama de flujo, pero para que te hagas una idea):

Diagrama de flujo del algoritmo para la receta del huevo frito

Pseudocódigo:

Como su propio nombre indica, no es un código o lenguaje natural o de programación. Es más bien una combinación entre lenguaje natural (español, sueco,…) y palabras reservadas usadas en lenguajes de programación. Es decir, sería como una especie de borrador del programa. El paso previo a escribir el código fuente. Pero, por supuesto, el pseudocódigo no es entendible por el compilador, solo por nosotros.

Con él vamos a describir el algoritmo o diagrama anterior de una forma más sencilla, y más fácil de modificar que el diagrama (en caso de querer rediseñarlo, habría que dibujarlo desde cero prácticamente). El problema es que no tiene normas, y se suelen usar palabras que nos recuerdan al lenguaje de programación, y eso varía de un programador a otro.

Por tanto, así como un diagrama de flujo o un código es algo universal y debería ser comprensible por cualquier desarrollador, el pseudocódigo es muy personal. Por ejemplo, con nuestra receta, sería algo como:

ingrediente: huevo, aceite, sal
fritura
finalizar --> huevo frito

Quizás el caso del huevo frito no sea el mejor, pero, por ejemplo, un Hola mundo en pseudocódigo sería:

principal()
inicio
          imprimir "Hola mundo"
fin

El equivalente en lenguaje C del Hola mundo es:

#include <stdio.h>

int main()
{
        printf("Hola mundo");
        return 0;
}

4-Codificación

Siguiente paso es el de la codificación, es decir, transcribir el pseudocódigo o pasar el diagrama a código fuente. Para saber escribirlo, debes conocer a fondo el lenguaje de programación que estés usando. En este caso, sí que es un código comprensible por el compilador o el IDE que estemos usando. Un ejemplo de código ya codificado sería el ejemplo Hola mundo en C que hay sobre este mismo párrafo…

5-Prueba y depuración

Una vez el programa ya está creado, deberíamos compilarlo para pasarlo a un formato comprensible por la máquina, es decir, a binario. Una vez tenemos el ejecutable, puedes probarlo para ver si funciona adecuadamente. Puedes usar un proceso de debugging o depuración para localizar posibles errores o vulnerabilidades de tu programa. En futuros artículos pondré ejemplos con GNU gdb.

Cuando compilas, es el propio compilador el que suele mostrate mensajes de advertencia o errores que detienen el proceso de compilación. Normalmente son cosas no declaradas, que has olvidado algún símbolo como los ; en alguna función, errores sintácticos de cualquier tipo, etc. Cuando el código está correcto y compila, eso no quiere decir que el programa esté libre de errores.

Puede haber bugs que sucedan solo en determinadas circunstancias, vulnerabilidades que afecten a la seguridad, desbordamientos, etc. Para eso se emplea la depuración, para detectar este tipo de problemas lógicos que son complicados de detectar y que el compilador no es capaz de detectar. Por ejemplo, puede que hayas declarado una variable o constante de una forma no adecuada, etc.

6-Documentación

No es imprescindible, especialmente si se trata de un programa simple. Pero es una buena práctica escribir una guía o manual para el usuario o para futuros desarrolladores que quieran modificar tu código. Por cierto, no lo he dicho, pero también es bueno comentar el código fuente par aque otro programador, cuando lea el código fuente, sepa identificar para qué sirve cada parte…

Por lo general, a los comentarios del código se le llama como documentación interna. Los manuales e información adicional sobre el uso del programa es la externa. Además, sería bueno que facilites herramientas o la posibilidad para que otros colaboren en tu código, por ejemplo, traduciéndolo a otros idiomas, etc.

7-Mantenimiento

Aunque parezca que el programa ya está terminado, se podrían detectar fallos que hay que parchear, se pueden hacer ajustes, agregar nuevas funciones, etc. En definitiva, ir actualizando las versiones del software. Recuerda, que todo cambio debería ir también documentado.

Incluso si ha pasado la compilación y la depuración, es posible que siga con problemas. Ten en cuenta que durante la depuración no se pueden simular todas las posibilidades…

En el próximo artículo de la serie programación ya comenzaremos a ver C como tal, es decir, identificadores, tipos de datos, variables, constantes, operadores, etc. Conforme vayas conociendo el lenguaje, también iremos poniendo ejemplos prácticos de cada una de las etapas descritas.

Isaac

Apasionado de la computación y la tecnología en general. Siempre intentando desaprender para apreHender.

4 thoughts on “Programación: etapas de la programación

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar