fundamentos de programacion

Get Started. It's Free
or sign up with your email address
Rocket clouds
fundamentos de programacion by Mind Map: fundamentos de programacion

1. fases en la resolucion del problema

1.1. analisis del problema

1.1.1. la primera fase de la resolucion de un problema con computadoras es el analisis del problema

1.1.2. esta fase requiere una clara definicion, donde se contemple exactamente lo que debe hacer el programa y el resultado o solucion deseada

1.1.3. para poder definir bien un problema es conveniente responder a las siguientes preguntas: 1.- que entradas se requieren? 2.- cual es la salida deseada? 3.- que método produce la salida deseada?

1.2. diseno del algoritmo

1.2.1. en la tapa de diseno se determina como hace el programa la tarea solicitada

1.2.2. cada subprograma es resuelto mediante un modulo

1.2.2.1. los modulos pueden ser planeado, codificados, comprobados y depurados independientemente

1.2.2.2. el proceso implica la ejecucion de los siguientes pasos hasta que el programa se termina: 1.-programa un modulo, 2.-comprobar el modulo,3.-si es necesario, depurar el modulo, 4.-combinar con los modulos anteriores

1.3. herramientas de programacion

1.3.1. las dos herramientas mas utilizadas comunmente para disenar algoritmos son:

1.3.1.1. diagrama de flujo: es una representacion grafica de un algoritmo

1.3.1.2. pseudocodigo: es una herramienta de programacion en la que las instrucciones se escriben en palabras similares al ingles o espanol, que facilitan tanto la escritura como la lectura de programas

1.4. codificacion de un programa

1.4.1. es la escritura en un lenguaje de programacion de la representacion del algoritmo deasarrollada en las etapas precendentes

1.4.2. para realizar la conversión del algoritmo en programa se deben sustituir las palabras reservadas en español por sus homónimos en ingles y las operación /instrucciones indicadas en lenguaje natural expresarlas en el lenguaje de programación correspondiente

1.5. compilacion y ejecucion de un programa

1.5.1. cuando se haya convertido en un programa fuente, es preciso introducirlo en memoria mediante el teclado y almacenarlo posteriormente en un disco

1.5.2. el programa fuente debe ser traducido al lenguaje maquina, este proceso se realiza con el compilador y el sistema operativo que se encarga prácticamente de la compilación

1.6. verificacion y depuracion de un programa

1.6.1. la verificación y depuracion de un programa es el proceso de ejecucion del programa con una amplia variedad de datos de entrada

1.6.2. la depuración es el proceso de encontrar los errores del programa y corregir o eliminar dichos errores. Existen tres tipos de errores:

1.6.2.1. errores de compilación: se producen normalmente por un uso incorrecto de las reglas de lenguaje de programación y suelen se errores de sintaxis.

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 diseno del algoritmo.

1.7. documentacion y mantenimiento

1.7.1. la documentación de un programa puede ser interna y externa. la documentación interna es la contenida en lineas de comentarios.

1.7.2. la documentación es vital cuando se desea corregir posibles errores futuros o bien cambiar el programa

2. programacion modular

2.1. la programación modular es uno de los métodos de diseno mas flexible y potentes par mejorar la productividad de un programa.

2.2. cada programa contiene un modulo denominado programa principal que controla todo lo que sucede se transifiere el control a submodulos de modo que ellos puedan ejecutar sus funciones

2.2.1. los módulos son independientes en el sentido en que ningún modulo puede tener acceso directo a cualquier otro modulo excepto el modulo al que llama y sus propios sub módulos.

3. programacion estructurada

3.1. recursos abstractos

3.1.1. la programación estructurada se auxilia de los recursos abstractos en lugar de los recursos concretos de  que dispone un determinado lenguaje de programación.

3.2. diseno descendente (top-down)

3.2.1. es el proceso el cual un problema se descompone en una serie de niveles o pasos secesivos de refinamiento.

3.2.2. la metodologia descendente consiste en efectuar una relacion entre las sucesivasetapas de estructuracion de modo que se relacionasen unas con otras mediante entradas y salida de informacion

3.3. estructuras de control

3.3.1. las estructuras de un lenguaje de programación son métodos de especificar el orden en que las instrucciones de un algoritmo se ejecutaran.

3.3.2. las tres estructuras de control básico son:

3.3.2.1. secuencia

3.3.2.2. seleccion

3.3.2.3. repeticion

3.4. teorema de la programacion estructurada: estructuras basicas

3.4.1. un programa se define como propio si cumple las siguientes características:

3.4.1.1. posee un solo punto de entrada y uno de salida o fin para control del programa

3.4.1.2. existen caminos desde la entrada hasta la salida que se pueden seguir y que pasan por todas las partes del programa

3.4.1.3. todas las instrucciones son ejecutables y no existen lazos o bucles infinitos

3.4.2. la programación estructurada significa:

3.4.2.1. el programa completo tiene un diseno modular

3.4.2.2. los módulos se disenas con metodología descendente

3.4.2.3. cada modulo se codifica utilizando las tres estructuras de control básicas:

3.4.2.3.1. secuenciales

3.4.2.3.2. selectivas

3.4.2.3.3. repetitivas (ausencia total de sentencias)

3.4.2.4. estructuración y modularidad son conceptos complementarios

4. representacion grafica de los algoritmos

4.1. diagramas de flujo

4.1.1. es una técnicas de algoritmos mas antigua y a la vez mas utilizada, aunque su empleo ha disimulado considerablemente, sobre todo,desde la aparición de lenguajes de programación estructurados.

4.1.2. los simbolos estandar normalizados por ANSI son muy variados.

5. diagramas de Nassi-Schneiderman

5.1. es como un diagrama de flujo en el quese omiten las flechas de uniion y las cajas son contigua.

6. ciclo de vida del software

6.1. analisis

6.1.1. la primera etapa en la produccion de un sistema de software es decidir exactamente que se supone ha de hacer el sistema

6.1.2. en esta etapa se debe de responder a preguntas tales como:

6.1.2.1. cuales son los datos de entrada ?

6.1.2.2. que datos son validos y que datos no son validos?

6.1.2.3. quien utilizara el sistema: especialista cualificados o usuarios caluesquiera?

6.1.2.4. que interfaces de usuario se utilizaran?

6.1.2.5. cuales son los mensajes de error y de deteccion de errores deseables? como debe actuar el sistema cuando el usuario cometa un error en la entrada?

6.1.2.6. que hipótesis son posibles?

6.1.2.7. existen caos especiales?

6.1.2.8. cual es el formato de la salida?

6.1.2.9. que documentacion es necesaria?

6.1.2.10. que mejoras se introducirán probablemente al programa en el futuro?

6.1.2.11. como debe ser de rapido el sistema?

6.1.2.12. cada cuanto tiempo ha de cambiarse el sistema despues que se haya entregado?

6.2. diseno

6.2.1. la especificación de un sistema indica lo que el sistema debe hacer.

6.2.2. es preciso determinar si se pueden utilizar programas o subprogramas que ya existen o es preciso construidos totalmente

6.2.3. se debe especificar claramente no solo el proposito de cada modulo, si no tambien el flujo de datos entre modulos y se deben responder las siguientes preguntas:

6.2.3.1. que datos están disponibles al modulo antes de su ejecución?

6.2.3.2. que supone el modulo?

6.2.3.3. que hacen los datos después de que se ejecuta el modulo?

6.3. implementacion (codificación)

6.3.1. traduce los algoritmos del diseno en un programa escrito en un lenguaje de programación.

6.3.2. los algoritmos de datos realizadas en pseudocodigo han de traducirse codificados en un lenguaje que entiende la computadora:

6.3.2.1. PASCAL

6.3.2.2. FORTRAN

6.3.2.3. COBOL

6.3.2.4. C,C++

6.3.2.5. C#

6.3.2.6. java

6.4. pruebas e integracion

6.4.1. sirve para mostrar que un programa es correcto.

6.4.2. la fase de pruebas es una parte esencial de un proyecto de programación. durante la fase de prueba se necesita eliminar tantos errores lógicos como pueda

6.5. verificacion

6.5.1. se ha desarrolado un segundo metodo para demostrar la correcion o exactitud de un programa.

6.5.1.1. este  metodo, denominado verificacionformal implica la construccion de pruebas matematicas que ayudan a determinar si los programas hacen lo que se supone han dehacer.

6.5.2. si se descubre un error durante el proceso de verificación, se debe corregir su algoritmo y posiblemente se han de modificar las especificaciones del problema

6.5.2.1. un método es utilizar invariantes lo que probablemente hará que su algoritmo contenga pocos errores antes de que comience la codificación.

6.6. mantenimiento

6.6.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.

6.6.2. aunque el software sea 100% funcional debe ser mantenido y actualizado

6.7. la obsolescencia: programas obsoletos

6.7.1. la ultima etapa en el ciclo del software es la evolución del mismo, pasando por su vida útil hasta su obsolescencia fase en la que e software se queda anticuado

6.8. iteracion y evolucion del software

6.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, por ejemplo:

6.8.1.1. durante la fase de mantenimiento tenga que volver a las especificaciones del problema para verificarlas o modificarlas.

7. metodos formales de verificacion de programas

7.1. aserciones

7.1.1. una parte importante de verificación formal es la documentación de un programa a través de asertos

7.1.1.1. un aserto es una fase sobre una condición especifica en un cierto punto de un algoritmo o programa

7.1.2. la tarea de utilizar verificación formal es probar que un segmento de programa cumple su especificación.

7.2. precondiciones y postcondiciones

7.2.1. son afirmaciones sencillas sobre condiciones al principio y al final de los modulos

7.2.1.1. precondicion

7.2.1.1.1. indica los paramentos de entrada min y max se definen antes de que comience la ejecución del procedimiento

7.2.1.2. precondiciones

7.2.1.2.1. son mas que un método para resumir acciones de un procedimiento

7.3. reglas para prueba de programas

7.3.1. un medio util para probar que un programa p hace lo que realmente ha de hacer es proporcionar aserciones que expresen las condiciones antes y despues de que p sea ajecutada

7.3.2. la primera asercion describe las condiciones que han de ser verdaderas despues de que p se ha ejecutado

7.4. invariantes de bucles

7.4.1. otra aplicación de los invariantes de bucle es la especificación del bucle:

7.4.1.1. iniciacion

7.4.1.2. condicionde repeticion

7.4.1.3. cuerpo de bucle

7.5. etapas a establecer la exactitud (correccion) de un programa

7.5.1. se pueden utilizar invariantes para establecer la corrección de un algoritmo iterativo. supongamos el algoritmo ya estudiado anteriormente

7.5.1.1. el invariante debe ser inicialmente verdadero

7.5.1.2. una ejecución del bucle debe mantener el invariante

7.5.1.3. el invariante debe capturar la exactitud del algoritmo

7.5.1.4. el bucle debe terminar

7.6. programacion segura contra fallos

7.6.1. un programa es seguro contra fallos cuando se ejecuta razonablemente por cualquiera que lo utilice

7.6.2. para conseguir este objetivo se han de comprobar los errores en datos de entrada y en la lógica del programa

8. factores en la calidad del software

8.1. eficiencia

8.1.1. la eficiencia de un software es su capacidad para hacer un buen uso de los recursos que manipula

8.2. transportabilidad (portabilidad)

8.2.1. la transportabilidad oportabilidad es la facilidad con la que un software puede ser transportado sobre diferentes sistemas físicos o lógicos

8.3. verificabilidad

8.3.1. 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

8.4. integridad

8.4.1. es la capacidad de un software a proteger sus propios componentes contra procesos que no tenga derecho de acceder

8.5. facil de utilizar

8.5.1. un software es fácil de utilizar si se pude comunicar consigo de manera cómoda

8.6. correcion

8.6.1. capacidad de los productos sofware de realizar exactamente las tareas definidas por su especificacion

8.7. robustez

8.7.1. capacidad de los productos software de funcionar incluso en situaciones anormales

8.8. extensibilidad

8.8.1. facilidad que tienen los productos de adaptarse a cambios en su especificación.existen dos principios fundamentales para conseguir esta característica:

8.8.1.1. diseno simple

8.8.1.2. descentralizacion

8.9. reutilizacion

8.9.1. capacidad de los productos de ser reutilizados, en su totalidad o en parte, en nuevas aplicaciones

8.10. compatibilidad

8.10.1. facilidad de los productos para ser combinados con otros