Diseño de Programas

1. Diseño de Programas

2. Diseño • Diseñar un programa se puede comparar con resolver un problema de la vida cotidiana. • El programador debe tener muy presente el objetivo del programa, es recomendable que siempre se tenga en mente: • Propósito del programa: Qué hace? Qué tan rápido debe ser? En que procesador se va a implementar? • Parámetros de entrada: Cómo se pasan los parámetros (registro, por stack, por memoria, etc)? Cuantos son? Qué tipo de datos? • Salidas esperadas del programa: Cómo debe alterar registros o zonas de memoria? • Hay casos particulares o excepciones: Códigos de error frente a entradas o salidas erróneo

3. Diseño • Es conveniente simplificar el problema original siguiendo los siguientes lineamientos • Paso 1: • Evitar realizar todo de una sola vez • Subdividir el problema en pasos simples o en tareas lógicas independientes • De esta manera uno programa módulos más sencillos. • Probar módulos más simples es más rápido • Integrar módulos lógicamente independientes es más sencillo • Paso 2: • Realizar diagramas de flujo (si aplica) • Un diagrama de flujo debe ser simple de seguir • No debe contener instrucciones específicas de un procesador sino ideas o conceptos generales

4. Diagrama de Flujo • Un diagrama de flujo nos permite realizar un seguimiento conceptual del programa a diseñar

5. Modularización • Si un programa es suficientemente complejo un diagrama de flujo no resuelve todo. • En estos casos es conveniente modularizar el programa.

6. Modularización • Modularizar un problema implica dividir el mismo en problemas más pequeños o módulos. Resolviendo problemas más pequeños se puede resolver el problema más complejo • Para poder modularizar uno debe encontrar los bloques fundamentales que constituyen el problema. • Esta división da origen a lo que se conoce como el paradigma de la programación modular. • En el proceso de modularización se debe: • Dividir el problema en segmentos simples • Buscar que los módulos sean genéricos (que tengan flexibilidad) • En la búsqueda de flexibilidad no debo perder el objetivo del cual partí

7. Modularización • Divido el problema en bloques fundamentales • Resolviendo cada bloque y uniéndolo puedo resolver el problema planteado

8. Modularización • Si diseño segmentos o módulos flexibles puedo reutilizarlos en otro momento Un hombre? Una locomotora?

9. Modularización • Un problema complejo como calcular el coseno de un número podría analizarse como varios bloques simples

10. Modularización • Que bloques empleo? • Función Potencia • Función División • Función Factorial • Con que profundidad?

11. Modularización • Ahora no es tan complicado resolver esto no?

12. Modularización • Ventajas • Un solo modulo es mas simple de escribir y de poner en funcionamiento. • Un modulo puede ser útil en diferentes partes de un programa e inclusive formar parte de otros programas. Esto será cierto siempre y cuando el modulo realice una tarea lo suficientemente general. • Los errores son mas fáciles de aislar y la corrección de los mismos se limita a la modificación de un modulo. • Desventajas • La integración de los módulos puede ser compleja en particular si fueron escritos por diferentes personas. • Los módulos requieren de documentación cuidadosa dado que pueden afectar a otras partes del programa. Se debe prestar mucha atención cuando se utilizan módulos que modifican estructuras de datos compartidas con otros módulos. • La prueba de un modulo puede ser difícil en situaciones en las que se necesitan datos generados por otros módulos.

13. Modularización • Principios de la modularización • Aquellos módulos que hacen referencia a datos comunes deben ser parte de un mismo modulo. • Dos módulos en donde el primero depende o hace uso del segundo deben estar separados. • Un modulo que es usado por varios módulos debe ser separado de los demás. • Dos módulos cuya frecuencia de uso es significativamente diferente deben ser separados • La organización (estructura) de datos relacionados entre si debe estar oculta en un solo modulo

14. Modularización • Si un problema es difícil de modularizar hay que intentar redefinir las tareas involucradas en el problema. • Demasiados casos especiales o demasiadas variables que requieren un tratamiento especial son signos de que la definición del problema es inadecuado

15. Modularización • Los módulos (también llamados subrutinas o funciones) pueden recibir valores llamados parámetros y/o devolver resultados (valor de retorno) Parámetro Modulo o Subrutina Valor de Retorno

16. Modulo o Subrutina Modularización • Una subrutina puede ser invocada desde distintos lugares del programa

17. Modularización • Ejemplo: Temporizador • Supongamos que tenemos que escribir un programa que controle el tiempo de encendido de una lámparita. • Se pide que un usuario presione un pulsador, que se encienda la luz y un minuto después se apague automáticamente. • El procesador controlará todas las entradas y salidas del proceso • Procedamos a plantear el diagrama de flujo…

18. Ejemplo: Temporizador Terminótiempo? Inicio/Espero NO Se presiónó el pulsador? SI NO Apago la luz SI Fin Enciendo Luz InicioTemporizador

19. Utilizando los conceptos de progamación modular podríamos pensar en dos módulos principales para este programa: MODULO 1: Espera que se cierre el interruptor y enciende la luz como respuesta MODULO 2: Provee el reatrdo de un minuto y luego apaga la luz Si bien temos modularizado el progama no lo hemos hecho de la mejor manera: En ambos módulos se opera con datos que no están relacionados entre sí: el tiempo y el estado de la luz (on/off). Modularizando de esta manera perdemos flexbilidad y por ende portabilidad del código. Ejemplo: Temporizador

20. Recuerden que los criterios para modularizar nos recomiendan mantener los datos (entradas o salidas) que estén relacionados entre sí en el mismo módulo. Podríamos entonces redefinir los módulos de la siguiente manera MODULO1: Espera que se cierre el interruptor MODULO 2: Enciende la luz MODULO 3: Apaga la luz MODULO 4: Retardo de 1 minuto Ejemplo: Temporizador Estosmóduloscomparten los mismosdatos. Los podríamosconvertir en un únicomódulo

21. Ejemplo: Temporizador Podríamos mejorar el diseño aun más. El primer módulo comprende una etapa de decisión (cuando se cierra el interruptor?) con una etapa de lectura del estado del interruptor (abierto o cerrado) Separemos dejando la decisión afuera de uno de los módulos. El proceso de decisión estará en el programa principal. Redefiniendo esta condición el esquema del programa estará dado de la siguiente manera: MODULO 1: Indicar estado del interruptor (on/off) MODULO 2: Endender o apagar la luz (on/off) MODULO 3: Retardo de 1 minuto

22. Ejemplo: Temporizador Documentemos cada módulo: MODULO 1: Indica si el interruptor está abierto o cerrado. Este módulo no recibe ningún parámetro de entrada. Como salida ofrece dos valores posibles: 0 = Abierto; 1 = Cerrado MODULO 2: Enciende o apaga la luz. El módulo recibe un parámetro que le indica si debe encender o apagar la luz: 0 = Off ; 1 = On. No devuelve ningún parámetro. MODULO 3: Establece la constante de tiempo de 1 minuto. No recibe o devuelve ningún parámetro. La ejecución de este módulo debería extenderse durante 1 minuto.

23. Ejemplo: Temporizador Cada modulo es independiente de los demás lo que los convierte en genéricos y por lo tanto pueden ser usados en cualquier programa. Debe notarse que los dos primeros módulos tienen subyacente la estructura del hardware y por lo tanto toda modificación realizada sobre dicha estructura se vera reflejada únicamente en estos módulos y no en el resto del programa.

24. Ejemplo: Temporizador Terminótiempo? Estado Interruptor NO Se presiónó el pulsador? SI OFF NO LUZ SI Fin ON LUZ Modulos: Verde Parámetros: Negro Programa: Celeste Temporizador