Paradigmas

11.031 visualizaciones

Publicado el

Trata del paradigma de la Ing de Software

Publicado en: Educación, Tecnología
0 comentarios
3 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

Sin descargas
Visualizaciones
Visualizaciones totales
11.031
En SlideShare
0
De insertados
0
Número de insertados
455
Acciones
Compartido
0
Descargas
411
Comentarios
0
Recomendaciones
3
Insertados 0
No insertados

No hay notas en la diapositiva.

Paradigmas

  1. 1. Isabel Trujillo Rodríguez 07480009 Verónica Lizeth Alanís Muñiz 07480040 Isidro Bazaldua Gracia 07480023
  2. 2. <ul><li>Paradigmas de programación: </li></ul><ul><li>a) Los que soportan técnicas de programación de bajo nivel (copia de ficheros frente estructuras de datos compartidos) </li></ul><ul><li>b) Los que soportan métodos de diseño de algoritmos (programación dinámica) </li></ul><ul><li>c) Los que soportan soluciones de programación de alto nivel. </li></ul><ul><li>La ingeniería de software está compuesta por una serie de pasos de abarcan los métodos, las herramientas y los procedimientos antes mencionados. </li></ul><ul><li>Estos pasos se denominan frecuentemente paradigmas de la ingeniería de software. </li></ul><ul><li>La elección de un paradigma para la ingeniería de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicación, los métodos, herramientas a usar, los controles y entregas requeridos. </li></ul>
  3. 3. <ul><li>En el Enfoque Estructurado se usan los DFD (Diagrama de Flujo de Datos) como principal herramienta para entender al sistema antes de plasmarlo a código fuente. </li></ul><ul><li>DFD es un diagrama en el q participan procesos (métodos), flujo de datos (argumentos) y archivos (base de datos). </li></ul><ul><li>Hay de diferentes niveles dependiendo la complejidad del sistema q analiza. </li></ul><ul><li>Otra desventaja es que una porción de código en lenguaje estructurado es difícil que pueda servir en otros proyectos. </li></ul>
  4. 4. <ul><li>Un diagrama de flujo de datos (DFD) es un modelo lógico-gráfico para representar el funcionamiento de un sistema en un proyecto software. </li></ul><ul><li>ELEMENTOS GRÁFICOS </li></ul><ul><li>Círculos; Los círculos significan procesos </li></ul><ul><li>Flechas; las flechas flujos de datos desde, o hacia, un proceso. </li></ul><ul><li>Rectángulos cerrados o abiertos; Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos. </li></ul><ul><li>En un DFD también se utiliza la escritura. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. </li></ul><ul><li>Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos, en este caso la etiqueta tendrá un número adicional. No hay un límite para el número de procesos. </li></ul>
  5. 5. <ul><li>DEFINICION: </li></ul><ul><li>Un diccionario de datos es un conjunto de métodos que contiene las características lógicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripción, alias, contenido y organización. </li></ul><ul><li>  </li></ul><ul><li>El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema. </li></ul><ul><li>OBJETIVOS </li></ul><ul><li>Un diccionario de datos es dar precisión sobre los datos que se manejan en un sistema, evitando así malas interpretaciones o ambigüedades. </li></ul><ul><li>Define con precisión los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etc. </li></ul><ul><li>Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos, los diagramas de entidad-relación, etc. </li></ul>
  6. 6. <ul><li>Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un Modelo de Datos permite describir: </li></ul><ul><li>Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. </li></ul><ul><li>Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. </li></ul><ul><li>Operaciones de manipulación de los datos: típicamente, operaciones de agregado, borrado, modificación y recuperación de los datos de la base. </li></ul><ul><li>Otro enfoque es pensar que un modelo de datos permite describir los elementos de la realidad que intervienen en un problema dado y la forma en que se relacionan esos elementos entre sí. </li></ul>
  7. 7. <ul><li>Modelos de Datos Lógicos: </li></ul><ul><li>Son orientados a las operaciones más que a la descripción de una realidad. Usualmente están implementados en algún Manejador de Base de Datos. El ejemplo más típico es el Modelo Relacional, que cuenta con la particularidad de contar también con buenas características conceptuales (Normalización de bases de datos). </li></ul><ul><li>Modelos de Datos Físicos: </li></ul><ul><li>Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos típicos de estas estructuras son los Árboles B+, las estructuras de Hash, etc. </li></ul>
  8. 8. <ul><li>DESCOMPOSICIÓN FUNCIONAL </li></ul><ul><li>Cada proceso se puede explotar, refinar o descomponer en un DFD más detallado. </li></ul><ul><li>El DFD de un sistema es realmente un conjunto de DFD’s dispuestos jerárquicamente. </li></ul><ul><li>Los niveles de la jerarquía están determinados por la descomposición funcional de los procesos. </li></ul><ul><li>La raíz de la jerarquía es el “diagrama de contexto”, que es el más general de todos. </li></ul>
  9. 9. <ul><li>Actualmente una de las áreas más candentes en la industria y en el ámbito académico es la orientación a objetos. La orientación a objetos promete mejoras de amplio alcance en la forma de diseño , desarrollo y mantenimiento del software ofreciendo una solución a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software : la falta de portabilidad del código y reusabilidad, código que es difícil de modificar, ciclos de desarrollo largos y técnicas de codificación no intuitivas. </li></ul><ul><li>Un lenguaje orientado a objetos ataca estos problemas . Tiene tres caracter ísticas básicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. </li></ul>
  10. 10. <ul><li>El modelo de análisis se extiende luego para describir la manera en que interactúan los actores y el sistema para manipular el modelo del dominio de aplicación. Los desarrolladores usan el modelo de análisis, junto con los requerimientos no funcionales, para preparar la arquitectura del sistema que se desarrolla durante el diseño de alto nivel. </li></ul><ul><li>Las actividades del análisis: la identificación de objetos, su comportamiento, sus relaciones, su clasificación y su organización. </li></ul><ul><li>El modelo de análisis está compuesto por tres modelos individuales: el modelo funcional, representado por casos de uso y escenarios, el modelo de objetos de análisis, representado por diagramas de clase y objeto, y el modelo dinámico, representado por gráficas de estado y diagramas de secuencia. </li></ul>
  11. 11. <ul><li>Objetos de entidad, frontera y control : Los objetos de entidad representan la información persistente rastreada por el sistema. Los objetos de frontera representan la interacción entre los actores y el sistema. Los objetos de control representan las tareas realizadas por el usuario y soportadas por el sistema. </li></ul><ul><li>Multiplicidad de asociación: el extremo de una asociación puede etiquetarse como un conjunto de enteros llamados multiplicidad. La multiplicidad indica la cantidad de vínculos que pueden originarse legítimamente desde una instancia de la clase conectada al extremo de la asociación. </li></ul>
  12. 12. <ul><li>Durante el diseño de objetos cerramos el hueco entre los objetos de aplicación y los componentes hechos, identificando objetos de solución adicionales y refinando los objetos existentes. </li></ul><ul><li>El diseño de objetos incluye: </li></ul><ul><li>Especificación de servicios, durante la cual describimos con precisión cada interfaz de clase. </li></ul><ul><li>Selección de componentes, durante la cual identificamos componentes hechos y objetos de solución adicionales. </li></ul>
  13. 13. <ul><li>Reestructuración del modelo de objetos, durante la cual transformamos el modelo de diseño de objetos para mejorar su comprensibilidad y extensibilidad. </li></ul><ul><li>Optimización del modelo de objetos, durante la cual transformamos el modelo de diseño de objetos para tratar criterios de desempeño, como el tiempo de respuesta o la utilización de la memoria. </li></ul><ul><li>El diseño de objetos, al igual que el diseño del sistema, no es algorítmico.   </li></ul>

×