PARADIGMAS DE LA INGENIERIA DE SOFTWARE

1. PARADIGMAS DE LA INGENIERIA DE SOFTWARE * FRAUSTO JIMENEZ GABRIELA * * HERNANDEZ TORRES ANA LAURA * * MANDUJANO JUAN CARLOS * * NOVA MARIN YARELI PAULINA * * ZAVALA CORTE JOCELYN ARELI *

2. DIAGRAMA DE FLUJO • Es la representación gráfica del algoritmo o proceso dentro de un problema especifico según sea el caso.

4. DIAGRAMA DE FLUJO DE DATOS • Es una representación gráfica para la maceta del "flujo" de datos a través de un sistema de información. • También se puede utilizar para la visualización de procesamiento de datos (diseño estructurado).

5. Entidad Externa Persona, grupo de personas o unidad de negocio que entrega yo recibe información. • Flujo Conjunto de actividades de negocio que explican que se hace y como se llevan a cabo. • Datos Señala el flujo de datos de una entidad externa a un proceso y viceversa, de un proceso a otro, y de un proceso a un almacén de datos y viceversa. • Proceso Lugar físico donde se almacenan los datos procesados o desde donde se recuperan para apoyar un proceso.

6. DICCIONARIO DE DATOS (DD) • Guarda y organiza los detalles del Diagrama de Flujo de Datos (DFD). • Notación para representar la estructura de ítems de datos, necesaria para expresar : – composición (secuencia ?) – cómo un ítem esta compuesto de unidades planas (sus atributos). – Repetición – ítems que son repetidos en (e.g.) listas, arreglos (arrays), etc. – selección – valores para ítems a seleccionar desde alternativas. – opcionalidad - ítems que no siempre están presentes.

7. Símbolos usados en la notación del DD Asigne un nombre significativo a cada ítem de datos básico o compuesto. • = significa ‘es definido como', o ‘esta hecho de' • + significa ‘ y ' • { } significa cero o mas de cualquier cosa que este • dentro de las llaves, i.e. repetición • n{ }m significa entre n y m (inclusive) • [ | | ] significa que uno de los atributos entre las barras • esta presente. • ( ) significa que el ítem entre paréntesis es opcional • " " incluye literales (valor a utilizar) • * * incluye comentarios

8. DIAGRAMA UML • UML es un lenguaje gráfico para modelado de programas de computadoras. • Proporciona un medio de visualizar la organización de alto nivel de los programas sin fijarse con detenimiento en los detalles del código real.

9. DIAGRAMA DE CLASES • Sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. • esta compuesto por los siguientes elementos: * Clase: atributos, métodos y visibilidad. * Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

10. DIAGRAMA DE PAQUETES • Se usan para reflejar la organización de paquetes y sus elementos. Con ello poder organizar diagramas de casos de uso y diagramas de clase.

11. DIAGRAMA DE DESPLIEGUE • Se utiliza para modelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes. • Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes (representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.

12. DIAGRAMA DE COMPONENTES • Representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, bibliotecas compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.

13. DIAGRAMA DE OBJETOS • Se puede considerar un caso especial de un diagrama de clases en el que se muestran instancias específicas de clases (objetos) en un momento particular del sistema. Los diagramas de objetos utilizan un subconjunto de los elementos de un diagrama de clase. Los diagramas de objetos no muestran la multiplicidad ni los roles, aunque su notación es similar a los diagramas de clase.

14. DIAGRAMA DE ESTADO • muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación en respuesta a eventos (por ejemplo, mensajes recibidos, tiempo rebasado o errores), junto con sus respuestas y acciones. También ilustran qué eventos pueden cambiar el estado de los objetos de la clase. Normalmente contienen: estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. • Al igual que otros diagramas, en los diagramas de estado pueden aparecer notas explicativas y restricciones.

15. DIAGRAMA DE CASO DE USOS • son importantes para visualizar, especificar, y documentar el comportamiento de un elemento. Ellos hacen sistemas, subsistemas, y clases entendibles para presentar una vista exterior de cómo estos elementos pueden ser usados dentro del contexto. Los diagramas de caso de uso son también importantes para probar sistemas ejecutables a través de ingeniería hacia adelante y para comprender sistemas ejecutables a través de ingeniería inversa.

16. DIAGRAMA DE ACTIVIDAD • representa los flujos de trabajo paso a paso de negocio y operacionales de los componentes en un sistema. Un Diagrama de Actividades muestra el flujo de control general

17. DIAGRAMA DE SECUENCIA • muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso