Informática Administrativa Unidad de Aprendizaje: Programación Estructurada Autor: M. en C. Ed. Patricia Delgadillo Gómez Agosto-2015 Universidad Autónoma.

Presentación del tema: "Informática Administrativa Unidad de Aprendizaje: Programación Estructurada Autor: M. en C. Ed. Patricia Delgadillo Gómez Agosto-2015 Universidad Autónoma."— Transcripción de la presentación:

1 Informática Administrativa Unidad de Aprendizaje: Programación Estructurada Autor: M. en C. Ed. Patricia Delgadillo Gómez Agosto-2015 Universidad Autónoma del Estado de México Centro Universitario UAEM Ecatepec

2 Guion Explicativo  El presente material didáctico esta diseñado como a poyo a la asignatura de Programación Estructurada, para que los alumnos de Informática Administrativa conozcan la metodología de la programación estructurada para desarrollar la solución de un problema utilizando el método de ciclo de vida.

3 Objetivo de Asignatura  Proporcionar a los alumnos los conocimientos y herramientas para que puedan resolver problemas reales y ejecutarlos en lenguaje de programación c.

4 Secuencia Didáctica 1. Metodología de la Programación Estructurada 2. Componentes del lenguaje para la codificación 3. Formas de control básico mediante estructuras 4. Aplicar arreglos y apuntadores 5. Aplicar de uso de archivos y memoria dinámica

5 Contenido temático  Metodología de programación estructurada para desarrollar la solución.

6 Objetivo de la unidad I  Identificar la metodología de la programación Estructurada para desarrollar la solución de un problema utilizando el métodos en un enfoque modero usando RUP o XP, Objetos y Eclipse.

7  Técnica de construcción de programas que utilizan al máximo los recursos del lenguaje, limita el conjunto de estructuras aplicables a leer y presenta una serie de reglas que coordinan adecuadamente el desarrollo de las diferentes fases de la programación. Estructuras básicas de control. Recursos abstractos Diseño descendente

8  Los programas son más fáciles de entender  Reducción del esfuerzo en las pruebas.  Reducción de los costos de mantenimiento.  Programas más sencillos y más rápidos  Aumento de la productividad del programador  Los programas quedan mejor documentados internamente.

9  Metodología: Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.  Estructura: Es la descomposición ordenada de las partes de un todo. Conjunto de elementos interrelacionados que forman un todo.  Programación estructurada: Consiste en el diseño, escritura y prueba de un programa, construido con estructura.

10  Es la técnica que permite que la programación sea lo más eficaz posible en cuanto al desarrollo y mantenimiento.  Conjunto de principios generales que un programador ha de seguir para desarrollar un programa

11  Esta constituido por una o varias instrucciones físicamente contiguas lógicamente encadenadas, las cuales se pueden referenciar mediante un nombre y pueden ser llamadas desde diferentes puntos de un programa.  Un modulo puede ser un programa, una función, una subrutina(procedimiento).

12  Descomponer un programa en un número pequeño de abstracciones coherentes que pertenecen al dominio del problema y enmascaran la complejidad interna.  Método de diseño que tiende a dividir el problema, de forma lógica, en partes perfectamente diferenciadas que pueden ser analizadas, programadas y puesta a punto independientemente.

13  Es más fácil de escribir y depurar.  Fácil mantener y modificar.  Fácil control de la programación.  Posibilita el uso repetitivo de las rutinas en el mismo o en diferentes programas.

14  Consiste en establecer una serie de niveles de menor o mayor complejidad que den solución al problema.  Un programa estructurado tiene una representación en forma de árbol.  El diseño se basa en la realización de diferentes niveles.

15

16  El software nace, crece y muere. Es su ciclo de vida. Nace con sus requerimientos y diseño. Crece con su desarrollo y mantenimiento Muere cuando se reemplaza por otro.

17  Razones  Crecimiento de la empresa  Cambio de los requerimientos originales.  Número de usuarios  Número de transacciones  Distribución del software  Cambio de operaciones  Ampliación  Integración con otros sistemas

18 Análisis Diseño Codificación Integración Mantenimiento

19  Inconveniencias  Rígido, difícil de rectificar  Documentación inicial se vuelve obsoleta  Desarrollo evolutivo  Ciclo de vida en espiral  Uso de prototipos (de diversa fidelidad)  Cambia el proceso pero no las actividades

20 Análisis Diseño Construcción Evaluación A D C E A D C E A D E A D C E C Prototipado Iterativo o Diseño Espiral Solución

21

22 ANÁLISIS  Entrada  Conocimiento del dominio de la aplicación, actividades de los usuarios, mercado, etc.  Actividades  Identificar las necesidades del usuario  Análisis de viabilidad  Determinar los requerimientos de la aplicación  Salida  Documento de requerimientos del software

23  Entrada  Documento de requerimientos del software  Actividades  Establecer estrategia de solución  Análisis de alternativas. Formalizar la solución  Descomponer y organizar la aplicación  Fijar descripciones de cada módulo  Salida  Documento de diseño del software  UML (Universal Modeling Language)

24  Entrada  Documento de diseño del software  Actividades  Creación del código fuente  Pruebas de unidades  Salida  Código de módulos, probado

25  Entrada  Código de módulos, probado  Documento de requerimientos del software (validación)  Actividades  Pruebas de integración  Pruebas de validación  Salida  Aplicación completa, lista para usar

26  Entrada  Software listo para usar  Actividades  Instalación  Uso en paralelo  Implementación  Nuevos requerimientos, correcciones y modificaciones  Soporte de usuarios  Salida  Aplicación respondiendo a las necesidades actuales

27 El Diseño top down de Programas  La solución de cualquier problema puede darse en varias formas o niveles de abstracción.  “Nuestra herramienta mental más importantes para competir con la complejidad es la abstracción” (Niklaus Wirth 1974).

28  Un problema complejo no deberá considerarse inmediatamente en términos de instrucciones de un lenguaje, sino de elementos naturales del problema mismo, abstraídos de alguna manera.

29 Programación Estructurada  Esta basada en los siguientes puntos: 1.- Diseño del programa de lo general a lo particular (top down). 2.- Teorema de estructura. Todo programa puede ser diseñado utilizando únicamente las estructuras básicas: Secuencial Alternativa y Repetitiva

30  Un programa, por largo y complejo que sea, se puede diseñar anidando convenientemente estas tres estructuras básicas.  Esto ayudará mucho a que los programas sean fácilmente leídos por cualquier persona, a que el numero de errores en el proceso de programación sea bajo, a que los programas sean autodocumentados y a que puedan mantenerse fácilmente.

31 SEUDOCODIGO  Es una herramienta utilizada para el diseño de programas que permite al programador expresar sus pensamientos de una forma clara, utilizando su lenguaje natural y mostrando el orden de ejecución de las sentencias del programa sin ninguna ambigüedad.

32  El seudocódigo no está diseñado como un lenguaje compilable.  Tiene pocas reglas sintácticas y da al usuario la libertad de expresar sus pensamientos en su lenguaje natural.  Pasar del programa escrito en seudocódigo al programa escrito en un lenguaje cualquiera de programación resulta muy sencillo.

33 Las Estructuras Básicas  Secuencial: Cuando se quiere indicar que unas determinadas acciones se deben realizar en secuencia, se escriben unas a continuación de otras.  Ejemplo: Leer cantidad, precio Importe = cantidad * precio Imprimir importe

34  Alternativa: Esta la utilizamos para indicar si el resultado es cierto o falso de una expresión hay que realizar una acción u otra de las dos especificadas.  if ( numero >= 1 && numero <= 6 ) printf( "En la cara opuesta esta el \"%s\".", letras ); else printf( "ERROR: Numero incorrecto." );

35  Alternativa Anidadas: Dentro de una estructura de tipo alternativo es posible que exista otras del mimo tipo.  Construir una rutina para determinar cual es la menor de tres cantidades dadas a, b y c.

36  #include int main() { int a, b, suma, multiplicación; printf( "Introduzca primer número (entero): " ); scanf( "%d", &a ); printf( "Introduzca segundo número (entero): " ); scanf( "%d", &b ); suma = a + b; multiplicacion = a * b; if ( suma > multiplicación ) printf( "La suma es mayor." ); else /* Inicio del anidamiento */ if ( multiplicación > suma ) printf( "La multiplicación es mayor." ); else printf( "La suma y multiplicación son iguales." ); /* Fin del anidamiento */ return 0; }

37  Repetitiva: Se utiliza cuando se quiere un conjunto de instrucciones se realice un número de veces.  Ejemplo: while ( radio <= 0 ) { printf( "ERROR: El radio debe ser mayor que cero." ); printf( "\nIntroduzca radio: " ); scanf( "%f", &radio ); }

38 Programación XP  La programación extrema es una metodología de desarrollo ágil que tiene como principal objetivo aumentar la productividad a la hora de desarrollar un proyecto software. Da prioridad a los trabajos que dan un resultado directo y en los cuales se reduce la burocracia que pueda existir en el entorno de trabajo.

39 ¿QUÉ ES UNA METODOLOGÍA ÁGIL?  Las metodologías ágiles tienen como punto fuerte la adaptación a cualquier cambio en un proyecto para aumentar sus posibilidades de éxito.  Una metodología ágil tiene varios principios:  Los individuos y sus interacciones son más importantes que los procesos y las herramientas.  El software que funciona es más importante que la documentación.  Colaboración con el cliente en lugar de negociación de contratos.  No hay que seguir un plan cerrado, sino adaptarse al cambio.

40 PROCESO CONTINUO EN LUGAR DE POR BLOQUES  Integración continua : consiste en implementar progresivamente las nuevas características del software. En lugar de crear versiones estables en función de una planificación previamente realizada, los programadores reunen su código y reconstruyen el proyecto varias veces al día si hace falta.

41  Refactorización : mediante la constante eliminación de código duplicado y/o ineficiente los equipos de programación mejoran el diseño del sistema. El código se evalúa continuamente para ofrecer la mayor calidad posible.

42  Entregas pequeñas : el producto es evaluado en un ambiente real mediante la colocación de un sistema sencillo en producción el cual se actualizará rápidamente, es decir, cada 2 semanas (3 como máximo) el software será puesto en producción.

43 Conclusiones  El presente material fue desarrollado para la comprensión, así como la capacidad de abstracción análisis y síntesis de las metodologías de programación estructurada para desarrollar la solución de un problema utilizando los diferentes métodos en un enfoque moderno.

44 Referencias  Aiken y Jones, Aprendiendo C en 21 días, Prentice, México,1994.  Ceballos, Francisco Javier, Lenguaje C, RA- MA Addison, E.U.A. 1991.  Joyanes, Aguilar Luis y Zahonero, Martínez I. Programación en C, metodología, Estructurada de datos y objetos, Mc. Graw Hill, México, 2001.  Joyanes, Aguilar Luis, Fundamentos de Programación Algoritmos y Estructurada de datos, Mc. Graw Hill, México,1999.