TEMA: Presentación de la tercera unidad en powerpoint . NOMBRE: Jesús Manuel Juárez Fragozo.

1. TEMA: Presentación de la tercera unidad en powerpoint. NOMBRE: Jesús Manuel Juárez Fragozo. MATERIA: Fundamentos de Programación. SEMESTRE Y GRUPO: Primer semestre, I-e1 CARRERA: ING. TECNOLOGIAS DE INFORMACION Y COMUNICACIONES. SALINA CRUZ, OAXACA A 12DE OCTUBRE DEL 2012.

2. UNIDAD 3. HERRAMIENTAS DE PROGRAMACIÓN.

3. UML Y DIAGRAMAS DE FLUJO A medida que se acercaban los años 80, la metodología orientada a objetos comenzaba a madurar como un enfoque de desarrollo de software. Empezamos a crear diseños de aplicaciones de todo tipo utilizando la forma de pensar orientada a los objetos e implementamos (codificamos) programas utilizando lenguajes y técnicas orientadas a los objetos.

4. DIAGRAMAS DE FLUJO Es una herramienta gráfica que se emplea para describir y analizar el movimiento de los datos a través de un sistema, ya sea este manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Los DFD, como se les conoce popularmente son la herramienta más importante y la base sobre la cual se desarrollan otros componentes.

5. ELEMENTOS QUE CONFORMAN UN ALGORITMO.

6. SIMBOLOS UTILIZADOS PARA EL DIAGRAMA DE FLUJO.

7. REGLAS PARA LA CREACION DE DIAGRAMAS. • Los Diagramas de flujo deben escribirse de arriba hacia abajo, y/o de izquierda a derecha. • Los símbolos se unen con líneas, las cuales tienen en la punta una flecha que indica la dirección que fluye la información procesos, se deben de utilizar solamente líneas de flujo horizontal o verticales (nunca diagonales). • Se debe evitar el cruce de líneas, para lo cual se quisiera separar el flujo del diagrama a un sitio distinto, se pudiera realizar utilizando los conectores. Se debe tener en cuenta que solo se vana utilizar conectores cuando sea estrictamente necesario. • No deben quedar líneas de flujo sin conectar • Todo texto escrito dentro de un símbolo debe ser legible, preciso, evitando el uso de muchas palabras. • Todos los símbolos pueden tener más de una línea de entrada, a excepción del símbolo final. • Solo los símbolos de decisión pueden y deben tener mas de una línea de flujo de salida.

8. COMO SE CONSTRUYE UN DIAGRAMA DE FLUJO. • Debe de indicar claramente dónde inicia y dónde termina el diagrama. • Cualquier camino del diagrama debe de llevarte siempre a la terminal de fin. • Organizar los símbolos de tal forma que siga visualmente el flujo de arriba hacia abajo y de izquierda a derecha. • No usar lenguaje de programación dentro de los símbolos. • Centrar el diagrama en la página. • Las líneas deben ser verticales u horizontales, nunca diagonales. • No cruzar las líneas de flujo empleando los conectores adecuados sin hacer uso excesivo de ellos. • No fraccionar el diagrama con el uso excesivo de conectores. • Solo debe llegar una sola línea de flujo a un símbolo. Pero pueden llegar muchas líneas de flujo a otras líneas.

9. EJEMPLO DE DIAGRAMA DE FLUJO. Calcular la suma de los cuadrados de los primeros 100 números enteros y escribir el resultado. 

10. PSEUDOCODIGO. El pseudocódigo es un lenguaje de programación algorítmico; es un lenguaje intermedio entre el lenguaje natural y cualquier lenguaje de programación específico, como son: C, FORTRAN, Pascal, etc. No existe una notación formal o estándar de pseudocódigo, sino que, cada programador puede utilizar la suya propia.

11. OBJETIVO DEL PSEUDOCODIGO. El principal objetivo del pseudocódigo es el de representar la solución a un algoritmo de la forma más detallada posible, y a su vez lo más parecida posible al lenguaje que posteriormente se utilizara para la codificación del mismo. 

12. CARACTERISTICAS DEL PSEUDOCODIGO. • Se puede ejecutar en un ordenador • Es una forma de representación sencilla de utilizar y de manipular. • Facilita el paso del programa al lenguaje de programación. • Es independiente del lenguaje de programación que se vaya a utilizar. • Es un método que facilita la programación y solución al algoritmo del programa.

13. ESTRUCTURA DEL PSEUDOCODIGO. Cabecera:  • Programa: • Modulo: • Tipos de datos: • Constantes: • Variables: Cuerpo:  • Inicio • Instrucciones • Fin

14. EJEMPLO DE PSEUDOCODIGO. Ejemplo: Realizar el pseudocódigo de un programa que permita saber si un número es mayor, menor o igual a cero. •     Programa: ComparaNúmeros •        Entorno: NUMERO es un número entero • Algoritmo: • Escribir “Introduzca un número “ • leer NUMERO • SI NUMERO>0  ENTONCES •           escribir “El número introducido es positivo” • SI NO •           SI NUMERO<0 ENTONCES •                  escribir “El número introducido es negativo” •           SI NO •                  escribir “El número es cero” •           FINSI • FINSI • Finprograma

15. UML. El Lenguaje de Modelado Unificado es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos a un sistema de software bajo desarrollo, así como para modelado de negocios y otros sistemas no software. Puede ser utilizado con cualquier metodología, a lo largo del proceso de desarrollo de software, en cualquier plataforma tecnológica de implementación (Unix, Windows etc.). Los principales factores que motivaron la definición de UML fueron: la necesidad de modelar sistemas, las tendencias en la industria del software, unificar los distintos lenguajes y métodos existentes e innovar los modelos para adaptarse a la arquitectura distribuida.

16. BENEFICIOS DE UML. • Mejores tiempos totales de desarrollo (de 50 % o más). • Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos. • Establecer conceptos y artefactos ejecutables. • Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica. • Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas. • Mejor soporte a la planeación y al control de proyectos. • Alta reutilización y minimización de costos.

17. FASES DEL DESARROLLO DE UN SISTEMA UML. Análisis de Requerimientos UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de uso son descritos en un diagrama use-case. Cada use-case es descrito en texto y especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin considerar la funcionalidad que se implementará. Un análisis de requerimientos puede ser realizado también para procesos de negocios, no solamente para sistemas de software.

18. FASES DEL DESARROLLO DE UN SISTEMA UML. Análisis La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML. Es importante notar que sólo se consideran clases que están en el dominio del problema (conceptos del mundo real) y todavía no se consideran clases que definen detalles y soluciones en el sistema de software, tales como clases para interfaces de usuario, bases de datos, comunicaciones, concurrencia, etc.

19. FASES DEL DESARROLLO DE UN SISTEMA UML. Diseño En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc. Las clases de dominio del problema del análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas para la fase de programación.

20. FASES DEL DESARROLLO DE UN SISTEMA UML. Programación En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

21. FASES DEL DESARROLLO DE UN SISTEMA UML. Pruebas Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final que le usuario final espera.