1. Fases en la resolución de problemas
1.1. Análisis del problema
1.1.1. La primera fase de la resolución de un problema con computadora es el análisis del problema. Esta fase requiere una clara definición, donde se contemple exactamente lo que debe hacer el programa y el resultado o solución deseada.
1.2. Diseño del algoritmo
1.2.1. En la etapa de análisis del proceso de programación se determina qué hace el programa.
1.3. Herramientas de la programacion
1.3.1. Las dos herramientas más utilizadas comúnmente para diseñar algoritmos son: diagramas de pujo ,y pseudocódigos.
1.3.1.1. Un diagrama de flujo íJowchart) es una representación gráfica de un algoritmo.
1.3.1.2. El pseudocódigo es una herramienta de programación en la que las instrucciones se escriben en palabras similares al inglés o español, que facilitan tanto la escritura como la lectura de programas.
1.4. Codificación de un programa
1.4.1. Codificación es la escritura en un lenguaje de programación de la representación del algoritmo desarrollada en las etapas precedentes. Dado que el diseño de un algoritmo es independiente del lenguaje de programación utilizado para su implementación, el código puede ser escrito con igual facilidad en un lenguaje o en otro.
1.5. Compilación y ejecucion de un programa
1.5.1. Una vez que el algoritmo se ha convertido en un programa fuente, es preciso introducirlo en memoria mediante el teclado y almacenarlo posteriormente en un disco. Esta operación se realiza con un pro- grama editor, posteriormente el programa fuente se convierte en un archivo de programa que se guar- da (graba) en disco.
1.5.1.1. El programa fuente debe ser traducido a lenguaje máquina, este proceso se realiza con el compilador y el sistema operativo que se encarga prácticamente de la compilación.
1.6. Verificación de un programa
1.6.1. El programa fuente debe ser traducido a lenguaje máquina, este proceso se realiza con el compilador y el sistema operativo que se encarga prácticamente de la compilación.
1.6.2. La depuración es el proceso de encontrar los errores del programa y corregir o eliminar dichos errores.
1.6.2.1. Errores de compilación. Se producen normalmente por un uso incorrecto de las reglas del lenguaje de programación y suelen ser errores de sintusis.
1.6.2.2. Errores de ejecución. Estos errores se producen por instrucciones que la computadora puede comprender pero no ejecutar.
1.6.2.3. Errores lógicos. Se producen en la lógica del programa y la fuente del error suele ser el diseño del algoritmo. Estos errores son los más difíciles de detectar, ya que el programa puede funcionar y no producir errores de compilación ni de ejecución, y sólo puede advertir el error por la obtención de resultados incorrectos.
1.7. Ducumentación y mantenimiento
1.7.1. La documentación de un problema consta de las descripciones de los pasos a dar en el proceso de resolución de un problema. La importancia de la documentación debe ser destacada por su decisiva influencia en el producto final. Programas pobremente documentados son difíciles de leer, más difíciles de depurar y casi imposibles de mantener y modificar.
2. Programación modular
2.1. La programación modular es uno de los métodos de diseño más flexible y potentes para mejorar la productividad de un programa. En programación modular el programa se divide en módulos (partes independientes), cada una de las cuales ejecuta una Única actividad o tarea y se codifican independientemente de otros módulos. Cada uno de estos módulos se analizan, codifican y ponen a punto por separado.
2.1.1. Cada programa contiene un módulo denominado progruma principal que controla todo lo que sucede; se transfiere el control a submódulos (posteriormente se denominarán subprogramas), de modo que ellos puedan ejecutar sus funciones; sin embargo, cada submódulo devuelve el control al módulo principal cuando se haya completado su tarea. Si la tarea asignada a cada submódulo es demasiado compleja, éste deberá romperse en otros módulos más pequeños.
3. Programación estructurada
3.1. Los términos programación modular; programación descendente y programación estructurada se introdujeron en la segunda mitad de la década de los sesenta y a menudo sus términos se utilizan como sinónimos aunque no significan lo mismo. La programación modular y descendente ya se ha examinado anteriormente.
3.2. Recursos abstaractos
3.2.1. Según Dijkstras
3.2.1.1. consiste en descomponer una determinada acción compleja en términos de un número de acciones más simples capaces de ejecutarlas o que constituyan instrucciones de computadoras disponibles.
3.3. Diseño descendente (top-down)
3.3.1. En la etapa de diseño se determina como hace el programa la tarea solicitada. Los métodos más eficaces para el proceso de diseño se basan en el conocido por divide y vencerás. Es decir, la resolución de un problema complejo se realiza dividiendo el problema en subproblemas (stepwise) y a continuación dividir estos subproblemas en otros de nivel más bajo, hasta que pueda ser implementada una solución en la computadora.
3.4. Esctructuras de control
3.4.1. Las estructuras de control de un lenguaje de programación son métodos de especificar el orden en que las instrucciones de un algoritmo se ejecutarán. El orden de ejecución de las sentencias (lenguaje) o instrucciones determinan el flujo de control.
3.5. Teorema de la programación estrcuturada: estructura básica
3.5.1. En mayo de 1966, Bohm y Jacopini demostraron que un programa propio puede ser escrito utilizando solamente tres tipos de estructuras de control.
3.5.1.1. ♠secuenciales, ♠selectivas, ♠repetitivas.
3.5.1.2. Un programa se define como propio si cumple las siguientes características:
3.5.1.2.1. Posee un solo punto de entrada y uno de salida ofin para control del programa. Existen caminos desde la entrada hasta la salida que .se pueden seguir y que pasan por todas las partes del programa Todas las instrucciones son ejecutahles y no existen /ai.os CJ bucles infinitos (sin fin).
3.5.1.3. La programación estructurada signijica
3.5.1.3.1. ♣El programa completo tiene un diseño modular. ♣Los módulos se diseñan con metodología descendente (puede hacerse también ascendente). ♣Cada módulo se codifica utilizando las tres estructuras de control básicas: secuenciales, selectivas y repetititvas (ausencia total de sntencias GOTO) ♣Estructuración y modularidad son conceptos complementarios (se solapan).
4. Factores en la calidad del software
4.1. La construcción de software requiere el cumplimiento de numerosas características. Entre ellas se destacan las siguientes:
4.1.1. Eficiencia
4.1.1.1. La eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula.
4.1.2. Transportabilidad (portabilidad)
4.1.2.1. La transportabilidad o portabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos.
4.1.3. Verificabilidad
4.1.3.1. La verificabilidad -facilidad de verificación de un software- es su capacidad para soportar los procedimientos de validación y de aceptar juegos de test o ensayo de programas.
4.1.4. Integridad
4.1.4.1. La integridad es la capacidad de un software a proteger sus propios componentes contra los procesos que no tenga el derecho de acceder.
4.1.5. Facil de utilizar
4.1.5.1. Un software es fácil de utilizar si se puede comunicar consigo de manera cómoda.
4.1.6. Corrección
4.1.6.1. Capacidad de los productos software de realizar exactamente las tareas definidas por su especificación.
4.1.7. Robustez
4.1.7.1. Capacidad de los productos software de funcionar incluso en situaciones anormales.
4.1.8. Extensibilidad
4.1.8.1. Facilidad que tienen los productos de adaptarse a cambios en su especificación. Existen dos principios fundamentales para conseguir esta característica:
4.1.8.1.1. Diseño simple
4.1.8.1.2. Descentralización
4.1.9. Reutuilización
4.1.9.1. Capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones.
4.1.10. Compatibilidad
4.1.10.1. Facilidad de los productos para ser combinados con otros.
5. Representación gráfica de los algoritmos
5.1. Diagramas de flujo
5.1.1. Un diagrama de flujo (fZowchart) es una de las técnicas de representación de algoritmos más antigua y a la vez más utilizada, aunque su empleo ha disminuido considerablemente, sobro todo, desde la aparición de lenguajes de programación estructurados. Un diagrama de flujo es un diagrama que utiliza los símbolos (cajas) y que tiene los pasos de algoritmo escritos en esas cajas unidas por flechas, denominadas líneas deflujo, que indican la secuencia en que se debe ejecutar.
5.1.1.1. l
5.2. Tipos
5.2.1. 1. diagrama de flujo, 2. diagrama N-S (Nassi-Schneiderman), 3. lenguaje de especificación de algoritmos: pLseudoccídigo, 4. lenguaje esparlol, inglés ... 5. fórmulas .
6. Diagramas de Nassi-Schneiderman
6.1. El diagrama N-S de Nassi Schneiderman -también conocido como diagrama de Chapin- es como un diagrama de flujo en el que se omiten las flechas de unión y las cajas son contiguas. Las acciones sucesivas se escriben en cajas sucesivas y, como en los diagramas de flujo, se pueden escribir diferentes acciones en una caja.
6.1.1. l
7. El ciclo de vida del software
7.1. Análisis
7.1.1. La primera etapa en la producción de un sistema de software es decidir exactamente qué se supone ha de hacer el sistema. Esta etapa se conoce también como análisis de requisitos o especificaciones y por esta circunstancia muchos tratadistas suelen subdividir la etapa en otras dos.
7.1.1.1. ♦Análisis y definición del problema. ♦Especificación de requisitos.
7.2. Diseño
7.2.1. La especificación de un sistema indica lo que el sistema debe hacer. La etapa de diseño del sistema indica cómo ha de hacerse. Para un sistema pequeño, la etapa de diseño puede ser tan sencilla como escribir un algoritmo en pseudocódigo. Para un sistema grande, esta etapa incluye también la fase de diseño de algoritmos, pero incluye el diseño e interacción de un número de algoritmos diferentes, con frecuencia sólo bosquejados, así como una estrategia para cumplir todos los detalles y producir el código correspondiente.
7.3. Implementación (codificación)
7.3.1. La etapa de implementución (codificación) traduce los algoritmos del diseño en un programa escrito en un lenguaje de programación. Los algoritmos y las estructuras de datos realizadas en pseudocódigo han de traducirse codificados en un lenguaje que entiende la computadora: PASCAL, FORTRAN, COBOL, C, C++, C# o Java.
7.3.2. Codificacion
7.3.2.1. La codificacion cuando un problema se divide en subproblemas, los algoritmos que resuelven cada subproblema (tarea o módulo) deben ser codificados, depurados y probados independientemente. Es relativamente fácil encontrar un error en un procedimiento pequeño. Es casi imposible encontrar todos los errores de un programa grande, que se codificó y comprobó como una sola unidad en lugar de como una colección de módulos (procedimientos) bien definidos.
7.4. Pruebas e integración
7.4.1. Cuando los diferentes componentes de un programa se han implementado y comprobado individualmente, el sistema completo se ensambla y se integra.
7.4.2. Pruebas
7.4.2.1. La etapa de pruebas sirve para mostrar que un programa es correcto. Las pruebas nunca son fáciles. Edgar Dijkstra ha escrito que mientras que las pruebas realmente muestran lapresencia de errores, nunca puede mostrar su ausencia. Una prueba con «éxito» en la ejecución significa sólo que no se han descubierto errores en esas circunstancias específicas, pero no se dice nada de otras circunstancias.En teoría el Único modo que una prueba puede mostrar que un programa es correcto si todos los casos posibles se han intentado y comprobado (es lo que se conoce como prueba exhaustiva); es una situación técnicamente imposible incluso para los programas más sencillos. Supongamos, por ejemplo, que se ha escrito un programa que calcule la nota media de un examen.
7.5. Verificación
7.5.1. La etapa de pruebas ha de comenzar tan pronto como sea posible en la fase de diseño y continuará a lo largo de la implementación del sistema. Incluso aunque las pruebas son herramientas extremadamente válidas para proporcionar la evidencia de que un programa es correcto y cumple sus especificaciones, es difícil conocer si las pruebas realizadas son suficientes. Por ejemplo,.¿cómo se puede conocer que son suficientes los diferentes conjuntos de datos de prueba o que se han ejecutado todos los caminos posibles a través del programa?
7.6. Mantenimiento
7.6.1. Cuando el producto software (el programa) se ha terminado, se distribuye entre los posibles usuarios, se instala en las computadoras y se utiliza (producción). Sin embargo, y aunque, a priori, el programa funcione correctamente, el software debe ser mantenido y actualizado. De hecho, el coste típico del mantenimiento excede, con creces, el coste de producción del sistema original.
7.6.1.1. Un sistema de software producirá errores que serán detectados, casi con seguridad, por los usuanos del sistema y que no se descubrieron durante la fase de prueba. La corrección de estos errores es parte del mantenimiento del software. Otro aspecto de la fase de mantenimiento es la mejora del software añadiendo más características o modificando partes existentes que se adapten mejor a los usuarios.
7.7. La obsolescencia: programas obsoletos
7.7.1. La última etapa en el ciclo de vida del software es la evolución del mismo, pasando por su vida útil hasta su ohsolescencia o fase en la que el software se queda anticuado y es preciso actualizarlo o escribir un nuevo programa sustitutorio del antiguo.
7.7.1.1. Un sistema grande representa una inversión enorme de capital que parece, a primera vista, más barato modificar el sistema existente, en vez de construir un sistema totalmente nuevo. Este criterio suele ser, normalmente, correcto y por esta causa los sistemas grandes se diseñan para ser modificados. Un sistema puede ser productivamente revisado muchas veces. Sin embargo, incluso los programas grandes se quedan obsoletos por caducidad de tiempo al pasar una fecha límite determinada. A menos que un programa grande esté bien escrito y adecuado a la tarea a realizar, como en el caso de programas pequeños, suele ser más eficiente escribir un nuevo programa que corregir el programa antiguo.
7.8. Iteración y evolución del software
7.8.1. Las etapas de vida del software suelen formar parte de un ciclo o bucle, como su nombre sugiere y no son simplemente una lista lineal. Es probable, por ejemplo, que durante la fase de mantenimiento tenga que volver a las especificaciones del problema para verificarlas o modificarlas.
7.8.1.1. l
8. Métodos formales de verificación de programas
8.1. Aunque la verificación formal de programas se sale fuera del ámbito de este libro, por su importanciavamos a considerar dos conceptos clave, asernos (afirmaciones) y precondiciones/ postcondiciones invariantes que ayuden a documentar, corregir y clarificar el diseño de módulos y de programas.
8.2. Aserciones
8.2.1. Una parte importante de una verificación formal es la documentación de un programa a través de asertos o afirmaciones -sentencias lógicas acerca del programa que se declaran «verdaderas»-. Un aserto se escribe como un comentario y describe lo que se supone sea verdadero sobre las variables del programa en ese punto.
8.3. Precondicions y postcondiciones
8.3.1. Las precondiciones y postcondiciones son afirmaciones sencillas sobre condiciones al principio y al final de los módulos.
8.3.1.1. Precondición
8.3.1.1.1. Una precondición de un procedimiento es una afirmación lógica sobre sus parámetros de entrada; se supone que es verdadera cuando se llama al procedimiento.
8.3.1.2. Postcondición
8.3.1.2.1. Una postcondición de un procedimiento puede ser una afirmación lógica que describe el cambio en el estado delprograma producido por la ejecución del procedimiento; la postcondición describe el efecto de llamar al procedi- miento. En otras palabras, la postcondición indica que sera verdadera después que se ejecute el procedimiento.
8.4. Reglas para prueba de programas
8.4.1. Un medio útil para probar que un programa P hace lo que realmente ha de hacer es proporcionar aserciones que expresen las condiciones antes y después de que P sea ejecutada. En realidad las aserciones son como sentencias o declaraciones que pueden ser o bien verdaderas o bien falsas.
8.4.1.1. Primera aserción
8.4.1.1.1. La primera aserción, la precondición describe las condiciones que han de ser verdaderas antes de ejecutar P.
8.4.1.2. Segunda aserción
8.4.1.2.1. La segunda aserción, la postcondicición, describe las condiciones que han de ser verdaderas después de que P se ha ejecutado (suponiendo que la precondición fue verdadera antes).
8.5. Invariantes de bucles
8.5.1. Una invariante de bucle es una condición que es verdadera antes y después de la ejecución de un bucle. Las invariantes de bucles se utilizan para demostrar la corrección (exactitud) de algoritmos iterativos. Utilizando invariantes, se pueden detectar errores antes de comenzar la codificación y por esa razón reducir tiempo de depuración y prueba.
8.6. Etapas a establecer la exactitud (corrección) de un programa
8.7. Se pueden utilizar invariantes para establecer la corrección de un algoritmo iterativo.
8.7.1. El invariante debe ser inicialmente verdadero, antes de que comience la ejecución por primera vez del bucle. En el ejemplo anterior, Suma es O y j es O inicialmente. En este caso, el invariante significa que Suma contiene la suma de los elementos A [ O 1 a A [ j - 1 I , que es verdad ya que no hay elementos en este rango.
8.7.2. Una ejecución del bucle debe mantener el invariante. Esto es si el invariante es verdadero antes de cualquier iteración del bucle, entonces se debe demostrar que es verdadero después de la iteración. En el ejemplo, el bucle añade A [ j I a Suma y a continuación incrementa j en I. Por consiguiente, después de una ejecución del bucle, el elemento añadido más recientemente a Suma es A [ j - 1 I ; esto es el invariante que es verdadero después de la iteración.
8.7.3. El invariante debe capturar la exactitud del algoritmo. Esto es, debe demostrar que si el invariante es verdadero cuando termina el bucle, el algoritmo es correcto. Cuando el bucle del ejemplo termina, j contiene n y el invariante es verdadero: Suma contiene la suma de los elementos A [ O I a A [ j -1 I , que es la suma que se trata de calcular.
8.7.4. El bucle debe terminar. Esto es, se debe demostrar que el bucle termina después de un número finito de iteraciones. En el ejemplo, j comienza en O y a continuación se incrementa en 1 en cada ejecución del bucle. Por consiguiente, j eventualmente excederá a n con independencia del valor de n . Este hecho y la característica fundamental de while garantizan que el bucle terminará.
8.8. Programación segura contra fallos
8.8.1. Un programa es seguro contra fallos cuando se ejecuta razonablemente por cualquiera que lo utilice. Para conseguir este objetivo se han de comprobar los errores en datos de entrada y en la lógica del programa. Supongamos un programa que espera leer datos enteros positivos pero lee -25. Un mensaje típico a visualizar ante este error suele ser: Error de rango Sin embargo, es mas Útil un mensaje tal como este: -25 no es un número válido de años Por favor vuelva a introducir el número