SlideShare una empresa de Scribd logo

Unidad 3 paradigmas de la ingeniería del software

Fundamentos de ing del software Andrea Heredia

1 de 6
Unidad 2 Paradigmas de la ingeniería del software 
El Enfoque Estructurado 
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. DFD es un diagrama en 
el que participan procesos (métodos), flujo de datos (argumentos) y archivos (Base de datos). Hay 
de diferentes niveles dependiendo la complejidad del sistema que se analiza, hablando de lenguajes 
tiene muchas diferencia con la orientada a objetos, un mínimo cambio en el código puede llegar 
alterar al resto del programa cosa que en la orientada a objetos eso no sucede lo cual es una ventaja 
porque así no se pierde tiempo en arreglar cosas ya hechas. Una desventaja es que una porción de 
código en lenguaje estructurado es difícil que pueda servir en otros proyectos, esto si es habitual en 
lenguaje orientada a objetos, con solo importar clases ya hechas se escribe menos código y se ahorra 
tiempo. 
Diagrama de Flujo de Datos 
Un diagrama de flujo de datos (DFD) es una representación gráfica de los procesos que se realizan 
con los datos en su organización, con el uso de tan solo cuatro símbolos, se puede crear una 
descripción grafica de los procesos que, con el tiempo, contribuirán a desarrollar una sólida 
documentación del sistema. 
En seguida mencionan las ventajas sobre las explicaciones descriptivas en relación con la forma en 
que los datos se mueven a través del sistema: 
 Libertad para emprender la implementación técnica del sistema en las primeras etapas. 
 Comprensión más profunda de la interrelación entre sistemas y subsistemas. 
 Comunicación con los usuarios sobre el conocimiento del sistema actual mediante 
diagramas de flujos de datos. 
 Análisis de un sistema propuesto para determinar si se han definido los datos y procesos 
necesarios. 
La ventaja más grande es la libertad conceptual para utilizar los cuatro símbolos, los DFD’s hacen 
énfasis en el procesamiento o la transformación conforme estos pasan por una variedad de procesos. 
En los DFD’s lógicos no hay distinción entre procesos manuales o automatizados. Los procesos 
tampoco se representan gráficamente en orden cronológico. En vez de ello, se agrupan solo si el 
análisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los procesos 
automatizados también se pueden agrupar. 
Diccionario de Datos
El diccionario de datos surge de la necesidad de catalogar los procesos, flujos almacenes estructuras 
y elementos de datos. Los nombres que se usan son muy importantes. Cuando se tiene la oportunidad 
de asignar nombre a los componentes de los sistemas orientados a datos, es necesario trabajar en la 
creación de un nombre significativo pero diferente al de otros componentes de datos existentes. 
El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes 
para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del 
sistema tenga una misma comprensión de las entradas, salidas, de los componentes de los almacenes 
y también los cálculos intermedios. 
A pesar de la existencia de los diccionarios de datos automatizados, entender qué datos conforman 
un diccionario de datos, las convenciones usadas en estos últimos y cómo se desarrolla un 
diccionario de datos, son problemas que el analista de sistemas debe tener siempre presentes durante 
el esfuerzo de sistemas. Entender el proceso de compilar un diccionario de datos puede ayudar al 
analista de sistemas a visualizar el sistema y su funcionamiento. Además de proporcionar 
documentación y eliminar la redundancia, el diccionario datos se podría usar para: 
 Validar la integridad y exactitud del diagrama de flujo de datos. 
 Proporcionar un punto de partida para desarrollar pantallas e informes. 
 Determinar el contenido de los datos almacenados en archivos. 
 Desarrollar la lógica para los procesos del diagrama de flujo de datos. 
Diseño de Módulo 
Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un Modelo 
de Datos permite describir: 
1. Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma 
en que se relacionan. 
2. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los 
datos para reflejar correctamente la realidad deseada. 
3. Operaciones de manipulación de los datos: Operaciones de agregado, borrado, 
modificación y recuperación de los datos de la base. 
4. 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í. 
El Enfoque Orientado a Objetos
El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una 
entidad que encapsula datos (atributos) y acciones o funciones que los manejan (métodos). También 
para el EOO un objeto se define como una instancia o particularización de una clase. 
Los objetos de interés durante el desarrollo de software no sólo son tomados de la vida real (objetos 
visibles o tangibles), también pueden ser abstractos. En general son entidades que juegan un rol bien 
definido en el dominio del problema. Un libro, una persona, un carro, un polígono, son apenas 
algunos ejemplos de objeto. 
Cada objeto puede ser considerado como un proveedor de servicios utilizados por otros objetos que 
son sus clientes. Cada objeto puede ser a la vez proveedor y cliente. De allí que un programa pueda 
ser visto como un conjunto de relaciones entre proveedores clientes. Los servicios ofrecidos por los 
objetos son de dos tipos: 
 Los datos, que llamamos atributos. 
 Las acciones o funciones, que llamamos métodos. 
 Fundamentos del Enfoque Orientado a Objeto 
 El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo 
desarrollo orientado a objetos. 
 Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia. 
 Otros elementos a destacar (aunque no fundamentales) en el EOO son: Polimorfismo, Enlace 
dinámico (o binding), 
Concurrencia y Persistencia. 
El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO) constituyen un enfoque 
distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos de la programación 
orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelación), un 
lenguaje estandarizado de modulación en el cual los objetos generados no solo incluyen código 
referente a los datos sino también instrucciones acerca de las operaciones que se realizaran sobre 
los datos.
El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que comienza con la 
comunicación con el usuario. Es en esta parte donde se define el dominio del problema y se 
identifican las clases básicas del problema. La planificación y el análisis de riesgos establecen una 
base para el plan de proyecto OO. El trabajo técnico asociado con la ingeniería del software OO 
sigue las siguientes tareas: 
1. Identificar clases candidatas 
2. Buscar clases en biblioteca 
3. Extraer nuevas clases si existen 
4. Desarrollar las clases sino existen 
5. Añadir las nuevas clases a la biblioteca 
6. Construir n-esima iteración del sistema 
Las principales características del Enfoque Orientado a Objetos son: 
1. Objeto: Los datos están cuantificados en entidades discretas y distinguibles llamadas 
objetos. 
2. Clase: Significa que los objetos con la misma estructura de datos (atributos) y 
comportamiento (operaciones) se agrupa para formar una clase. 
3. Atributo: Describen la clase o el objeto de alguna manera 
4. Mensajes: Medio por el cual interactúan los objetos 
5. Polimorfismo: Significa que una misma operación puede comportarse de modos 
distintos en distintas clases. 
6. Herencia: Compartir atributos y operaciones entre clases tomando como base una 
relación jerárquica. 
• Identidad: Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos. 
Estos pueden ser tangibles o intangibles. 
• Clasificación: Los objetos con la misma estructura de datos (atributos) y comportamiento 
(operaciones) se agrupan para formar una misma clase, se dice que cada objeto es una instancia de 
su propia clase, y una clase es una abstracción que describe propiedades importantes para una 
aplicación y se olvida del resto. 
• Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en 
distintas clases, una operación es una acción o transformación que se aplica a un objeto.
• Herencia: Comparte atributos y operaciones entre clases tomando como base una relación 
jerárquica, es decir que se puede definir una clase que después producirá subclases, sabiendo que 
todas las subclases adquirirán todas y cada una de las propiedades de su super-clase y le agrega 
además sus propiedades exclusivas. 
Fase de Diseño 
Para los sistemas orientados a objetos es posible definir un diseño en pirámide con las siguientes 
cuatro capas: 
 Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al 
software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica 
que los soporta. 
 Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando 
generalizaciones y especializaciones mejor definidas incrementalmente. También contiene 
representaciones de diseño para cada objeto. 
 Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus 
colaboradores. Establece las interfaces externas e internas para el sistema. 
 Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los 
atributos y operaciones de cada objeto. 
Conclusion: 
Bueno de este tema aprendí que las diferencias entre un enfoque estructurado y uno orientado a
objetos, aprendí que un enfoque estructurado utiliza los Diagrama de Flujo de Datoscomo principal 
herramienta para entender al sistema antes de plasmarlo a código fuente, que un DFD es un 
diagrama en el que participan métodos, argumentos y archivos .

Recomendados

Objeto relacional bases datos 2
Objeto relacional bases datos 2Objeto relacional bases datos 2
Objeto relacional bases datos 2Velmuz Buzz
 
Analisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A ObjetosAnalisis Y DiseñO Orientado A Objetos
Analisis Y DiseñO Orientado A Objetosyoiner santiago
 
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOSFUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOS
FUNDAMENTOS Y MÉTODOS DE ANÁLISIS DE REQUERIMIENTOSRichard J. Nuñez
 
Base de datos-objeto-relacional
Base de datos-objeto-relacionalBase de datos-objeto-relacional
Base de datos-objeto-relacionalEduar Alfons Leon
 
Modelo de datos
Modelo de datosModelo de datos
Modelo de datoslauraluiso
 

Más contenido relacionado

La actualidad más candente

Modelo de Objeto Semantico
Modelo de Objeto SemanticoModelo de Objeto Semantico
Modelo de Objeto SemanticoF
 
Paradigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwareeParadigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwareeAndhy H Palma
 
Analisis y diseño orientado a objetos exposicion
Analisis y diseño orientado a objetos exposicionAnalisis y diseño orientado a objetos exposicion
Analisis y diseño orientado a objetos exposicionalumnosguacara
 
Modelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado ConceptualModelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado ConceptualAnabel
 
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A ObjetosQué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetosmaria8003
 
Unidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualUnidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualSergio Sanchez
 
Unidad 2 Modelo De Datos
Unidad 2 Modelo De DatosUnidad 2 Modelo De Datos
Unidad 2 Modelo De DatosSergio Sanchez
 
Modelo de datos y Modelo de Identidad
Modelo de datos y Modelo de Identidad Modelo de datos y Modelo de Identidad
Modelo de datos y Modelo de Identidad karina maita
 
Introduccion a los Modelos De Datos
Introduccion a los Modelos De DatosIntroduccion a los Modelos De Datos
Introduccion a los Modelos De Datosesacre
 
Modelos de bases_de_datos
Modelos de bases_de_datosModelos de bases_de_datos
Modelos de bases_de_datos22carlos
 
Presentación Modelo de Datos
Presentación Modelo de DatosPresentación Modelo de Datos
Presentación Modelo de DatosEnrique Cabello
 

La actualidad más candente (20)

Tc2 301403 21
Tc2 301403 21Tc2 301403 21
Tc2 301403 21
 
Modelo de Objeto Semantico
Modelo de Objeto SemanticoModelo de Objeto Semantico
Modelo de Objeto Semantico
 
Tecnologia orientado a objetos
Tecnologia orientado a objetosTecnologia orientado a objetos
Tecnologia orientado a objetos
 
modelo de datos
modelo de datos modelo de datos
modelo de datos
 
Paradigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwareeParadigmas de la ingeniería de softwaree
Paradigmas de la ingeniería de softwaree
 
Analisis y diseño orientado a objetos exposicion
Analisis y diseño orientado a objetos exposicionAnalisis y diseño orientado a objetos exposicion
Analisis y diseño orientado a objetos exposicion
 
Paradigmas
ParadigmasParadigmas
Paradigmas
 
Gbd tarea1
Gbd tarea1Gbd tarea1
Gbd tarea1
 
Modelado De Datos
Modelado De  DatosModelado De  Datos
Modelado De Datos
 
Modelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado ConceptualModelos de Datos y Modelado Conceptual
Modelos de Datos y Modelado Conceptual
 
Modelos de datos
Modelos de datosModelos de datos
Modelos de datos
 
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A ObjetosQué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
Qué Es El AnáLisis Y DiseñO De Software Orientado A Objetos
 
Unidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos ConceptualUnidad 3 Modelamiento De Datos Conceptual
Unidad 3 Modelamiento De Datos Conceptual
 
Unidad 2 Modelo De Datos
Unidad 2 Modelo De DatosUnidad 2 Modelo De Datos
Unidad 2 Modelo De Datos
 
Modelo de datos
Modelo de datosModelo de datos
Modelo de datos
 
Modelo de datos y Modelo de Identidad
Modelo de datos y Modelo de Identidad Modelo de datos y Modelo de Identidad
Modelo de datos y Modelo de Identidad
 
Introduccion a los Modelos De Datos
Introduccion a los Modelos De DatosIntroduccion a los Modelos De Datos
Introduccion a los Modelos De Datos
 
Modelos de bases_de_datos
Modelos de bases_de_datosModelos de bases_de_datos
Modelos de bases_de_datos
 
Modelo de datos
Modelo de datosModelo de datos
Modelo de datos
 
Presentación Modelo de Datos
Presentación Modelo de DatosPresentación Modelo de Datos
Presentación Modelo de Datos
 

Destacado

Unified Process: Resumen y Conclusiones
Unified Process: Resumen y ConclusionesUnified Process: Resumen y Conclusiones
Unified Process: Resumen y ConclusionesKudos S.A.S
 
Ingeniería de requisitos - Introducción
Ingeniería de requisitos - IntroducciónIngeniería de requisitos - Introducción
Ingeniería de requisitos - IntroducciónJose Diaz Silva
 
Ingenieria de requisitos - Recolectando la información
Ingenieria de requisitos  - Recolectando la informaciónIngenieria de requisitos  - Recolectando la información
Ingenieria de requisitos - Recolectando la informaciónJose Diaz Silva
 
Ingenieria del Software & Caracteristicas y Mitos del Software.
Ingenieria del Software & Caracteristicas y Mitos del Software.Ingenieria del Software & Caracteristicas y Mitos del Software.
Ingenieria del Software & Caracteristicas y Mitos del Software.claudyabra
 
Diseño de sistemas introduccion
Diseño de sistemas   introduccionDiseño de sistemas   introduccion
Diseño de sistemas introduccionJose Diaz Silva
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacionalclaudyabra
 
Conceptos de diseño de software
Conceptos de diseño de softwareConceptos de diseño de software
Conceptos de diseño de softwareJose Diaz Silva
 
Ingenieria de software. (mitos, leyendas y factores)
Ingenieria de software. (mitos, leyendas y factores)Ingenieria de software. (mitos, leyendas y factores)
Ingenieria de software. (mitos, leyendas y factores)Marcos Omar Cruz Ortrega
 
Introducción a la ingenieria del Software
Introducción a la ingenieria del SoftwareIntroducción a la ingenieria del Software
Introducción a la ingenieria del SoftwareJose Diaz Silva
 
Procesos de desarrollo de software
Procesos de desarrollo de softwareProcesos de desarrollo de software
Procesos de desarrollo de softwareJose Diaz Silva
 
Paradigmas de la ingeniería de software
Paradigmas de la ingeniería de softwareParadigmas de la ingeniería de software
Paradigmas de la ingeniería de softwareAndhy H Palma
 
El proceso unificado introduccion
El proceso unificado   introduccionEl proceso unificado   introduccion
El proceso unificado introduccionJose Diaz Silva
 
Evolucion de la Ingenieria de Software
Evolucion de la Ingenieria de SoftwareEvolucion de la Ingenieria de Software
Evolucion de la Ingenieria de SoftwareMarvin Romero
 
Introducción a la Ingeniería de Software:Qué es un Buen Sistema?
Introducción  a la Ingeniería de Software:Qué es un Buen Sistema?Introducción  a la Ingeniería de Software:Qué es un Buen Sistema?
Introducción a la Ingeniería de Software:Qué es un Buen Sistema?Kudos S.A.S
 
Mantenimiento de sistemas de información - Conceptos Avanzados
Mantenimiento de sistemas de información   - Conceptos AvanzadosMantenimiento de sistemas de información   - Conceptos Avanzados
Mantenimiento de sistemas de información - Conceptos AvanzadosJose Diaz Silva
 
Presentación software libre v2
Presentación software libre v2Presentación software libre v2
Presentación software libre v2Kudos S.A.S
 

Destacado (20)

Unified Process: Resumen y Conclusiones
Unified Process: Resumen y ConclusionesUnified Process: Resumen y Conclusiones
Unified Process: Resumen y Conclusiones
 
Ingeniería de requisitos - Introducción
Ingeniería de requisitos - IntroducciónIngeniería de requisitos - Introducción
Ingeniería de requisitos - Introducción
 
Modelo de procesos
Modelo de procesosModelo de procesos
Modelo de procesos
 
Ingenieria de requisitos - Recolectando la información
Ingenieria de requisitos  - Recolectando la informaciónIngenieria de requisitos  - Recolectando la información
Ingenieria de requisitos - Recolectando la información
 
Ingenieria del Software & Caracteristicas y Mitos del Software.
Ingenieria del Software & Caracteristicas y Mitos del Software.Ingenieria del Software & Caracteristicas y Mitos del Software.
Ingenieria del Software & Caracteristicas y Mitos del Software.
 
Diseño de sistemas introduccion
Diseño de sistemas   introduccionDiseño de sistemas   introduccion
Diseño de sistemas introduccion
 
Algebra relacional
Algebra relacionalAlgebra relacional
Algebra relacional
 
Conceptos de diseño de software
Conceptos de diseño de softwareConceptos de diseño de software
Conceptos de diseño de software
 
Ingenieria de software. (mitos, leyendas y factores)
Ingenieria de software. (mitos, leyendas y factores)Ingenieria de software. (mitos, leyendas y factores)
Ingenieria de software. (mitos, leyendas y factores)
 
Mitos del software
Mitos del softwareMitos del software
Mitos del software
 
Introducción a la ingenieria del Software
Introducción a la ingenieria del SoftwareIntroducción a la ingenieria del Software
Introducción a la ingenieria del Software
 
Procesos de desarrollo de software
Procesos de desarrollo de softwareProcesos de desarrollo de software
Procesos de desarrollo de software
 
Paradigmas de la ingeniería de software
Paradigmas de la ingeniería de softwareParadigmas de la ingeniería de software
Paradigmas de la ingeniería de software
 
El proceso unificado introduccion
El proceso unificado   introduccionEl proceso unificado   introduccion
El proceso unificado introduccion
 
Evolucion de la Ingenieria de Software
Evolucion de la Ingenieria de SoftwareEvolucion de la Ingenieria de Software
Evolucion de la Ingenieria de Software
 
Mitos del software
Mitos del softwareMitos del software
Mitos del software
 
Evolucion software - Ing SW
Evolucion software - Ing SWEvolucion software - Ing SW
Evolucion software - Ing SW
 
Introducción a la Ingeniería de Software:Qué es un Buen Sistema?
Introducción  a la Ingeniería de Software:Qué es un Buen Sistema?Introducción  a la Ingeniería de Software:Qué es un Buen Sistema?
Introducción a la Ingeniería de Software:Qué es un Buen Sistema?
 
Mantenimiento de sistemas de información - Conceptos Avanzados
Mantenimiento de sistemas de información   - Conceptos AvanzadosMantenimiento de sistemas de información   - Conceptos Avanzados
Mantenimiento de sistemas de información - Conceptos Avanzados
 
Presentación software libre v2
Presentación software libre v2Presentación software libre v2
Presentación software libre v2
 

Similar a Unidad 3 paradigmas de la ingeniería del software

Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientosFundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientoslexiherrera
 
Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos Mirla Montaño
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortellforwer1223
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandross1
 
Proceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizProceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizwilensanz
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de softwareYORGELIS1608
 
Fundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimientoFundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimientoMonica Naranjo
 
Diseño del Software y el Diseño Orientado a Objetos
Diseño del Software y el Diseño Orientado aObjetosDiseño del Software y el Diseño Orientado aObjetos
Diseño del Software y el Diseño Orientado a ObjetosAlexander J Sanchez A
 
Semanas01y02
Semanas01y02Semanas01y02
Semanas01y02luisortiz
 
Metodología Estructurada
Metodología EstructuradaMetodología Estructurada
Metodología Estructuradarenyv123
 
Jose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemasJose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemasAmerigled Salgado
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDat@center S.A
 

Similar a Unidad 3 paradigmas de la ingeniería del software (20)

Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientosFundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos
 
Instituto universitario politécnico
Instituto universitario politécnicoInstituto universitario politécnico
Instituto universitario politécnico
 
Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos Fundamentos y metodos de analisis de requerimientos
Fundamentos y metodos de analisis de requerimientos
 
Slideshare 2do corte, luismortell
Slideshare 2do corte, luismortellSlideshare 2do corte, luismortell
Slideshare 2do corte, luismortell
 
Alejandro soto ingeneria sistema
Alejandro soto ingeneria sistemaAlejandro soto ingeneria sistema
Alejandro soto ingeneria sistema
 
Proceso de analisis wilmer santeliz
Proceso de analisis wilmer santelizProceso de analisis wilmer santeliz
Proceso de analisis wilmer santeliz
 
Planificacion de proyecto de software
Planificacion de proyecto de softwarePlanificacion de proyecto de software
Planificacion de proyecto de software
 
Trabajo bdoo
Trabajo bdooTrabajo bdoo
Trabajo bdoo
 
Fundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimientoFundamentos y metodos analisis de requerimiento
Fundamentos y metodos analisis de requerimiento
 
Diseño del Software y el Diseño Orientado a Objetos
Diseño del Software y el Diseño Orientado aObjetosDiseño del Software y el Diseño Orientado aObjetos
Diseño del Software y el Diseño Orientado a Objetos
 
Semanas01y02
Semanas01y02Semanas01y02
Semanas01y02
 
Semanas01y02
Semanas01y02Semanas01y02
Semanas01y02
 
Metodología Estructurada
Metodología EstructuradaMetodología Estructurada
Metodología Estructurada
 
0 todo
0 todo0 todo
0 todo
 
Jose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemasJose marcano analisis y diseño de sistemas
Jose marcano analisis y diseño de sistemas
 
Presentación2
Presentación2Presentación2
Presentación2
 
Compu 1
Compu 1Compu 1
Compu 1
 
Lumisaca hector 6_s_ti_1.pdf
Lumisaca hector 6_s_ti_1.pdfLumisaca hector 6_s_ti_1.pdf
Lumisaca hector 6_s_ti_1.pdf
 
Presentación2
Presentación2Presentación2
Presentación2
 
Desarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a ObjetosDesarrollo de Software Orienta a Objetos
Desarrollo de Software Orienta a Objetos
 

Más de Andhy H Palma

Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareAndhy H Palma
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareAndhy H Palma
 
Unidad 5 graficación
Unidad 5 graficaciónUnidad 5 graficación
Unidad 5 graficaciónAndhy H Palma
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficaciónAndhy H Palma
 
Unidad 3 graficacion
Unidad 3 graficacionUnidad 3 graficacion
Unidad 3 graficacionAndhy H Palma
 
generacion de números pseudoaleatorios tecnicas
generacion de números  pseudoaleatorios tecnicasgeneracion de números  pseudoaleatorios tecnicas
generacion de números pseudoaleatorios tecnicasAndhy H Palma
 

Más de Andhy H Palma (6)

Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
 
Unidad 5 graficación
Unidad 5 graficaciónUnidad 5 graficación
Unidad 5 graficación
 
Unidad 4 graficación
Unidad 4 graficaciónUnidad 4 graficación
Unidad 4 graficación
 
Unidad 3 graficacion
Unidad 3 graficacionUnidad 3 graficacion
Unidad 3 graficacion
 
generacion de números pseudoaleatorios tecnicas
generacion de números  pseudoaleatorios tecnicasgeneracion de números  pseudoaleatorios tecnicas
generacion de números pseudoaleatorios tecnicas
 

Último

Ejercicio evaluación epistemologíalllllllllllllllllllllllll.docx
Ejercicio evaluación epistemologíalllllllllllllllllllllllll.docxEjercicio evaluación epistemologíalllllllllllllllllllllllll.docx
Ejercicio evaluación epistemologíalllllllllllllllllllllllll.docxoctavio cortez
 
combinación por correspondencia en Excel
combinación por correspondencia en Excelcombinación por correspondencia en Excel
combinación por correspondencia en ExcelHEDYYULIANARUIZGAVIR
 
VIDEOS DE APOYO.marianasarmiento.blogger
VIDEOS DE APOYO.marianasarmiento.bloggerVIDEOS DE APOYO.marianasarmiento.blogger
VIDEOS DE APOYO.marianasarmiento.bloggerMarianaSarmiento22
 
Presentación de los cultivos de la zanahoria
Presentación de los cultivos de la zanahoriaPresentación de los cultivos de la zanahoria
Presentación de los cultivos de la zanahoriachifadomagu
 
Taller 1 Internet 2 corte (solucionado) Cito
Taller 1 Internet 2 corte (solucionado) CitoTaller 1 Internet 2 corte (solucionado) Cito
Taller 1 Internet 2 corte (solucionado) Citomariangelvillazon3
 
Padlet como herrramienta para el aprendizaje
Padlet como herrramienta para el aprendizajePadlet como herrramienta para el aprendizaje
Padlet como herrramienta para el aprendizajezoecadi
 
marketing RPA 2024 es una coleccion de casos de uso
marketing RPA 2024 es una coleccion de casos de usomarketing RPA 2024 es una coleccion de casos de uso
marketing RPA 2024 es una coleccion de casos de usoncastagno
 

Último (8)

Ejercicio evaluación epistemologíalllllllllllllllllllllllll.docx
Ejercicio evaluación epistemologíalllllllllllllllllllllllll.docxEjercicio evaluación epistemologíalllllllllllllllllllllllll.docx
Ejercicio evaluación epistemologíalllllllllllllllllllllllll.docx
 
cuadro comparativo r
cuadro comparativo                        rcuadro comparativo                        r
cuadro comparativo r
 
combinación por correspondencia en Excel
combinación por correspondencia en Excelcombinación por correspondencia en Excel
combinación por correspondencia en Excel
 
VIDEOS DE APOYO.marianasarmiento.blogger
VIDEOS DE APOYO.marianasarmiento.bloggerVIDEOS DE APOYO.marianasarmiento.blogger
VIDEOS DE APOYO.marianasarmiento.blogger
 
Presentación de los cultivos de la zanahoria
Presentación de los cultivos de la zanahoriaPresentación de los cultivos de la zanahoria
Presentación de los cultivos de la zanahoria
 
Taller 1 Internet 2 corte (solucionado) Cito
Taller 1 Internet 2 corte (solucionado) CitoTaller 1 Internet 2 corte (solucionado) Cito
Taller 1 Internet 2 corte (solucionado) Cito
 
Padlet como herrramienta para el aprendizaje
Padlet como herrramienta para el aprendizajePadlet como herrramienta para el aprendizaje
Padlet como herrramienta para el aprendizaje
 
marketing RPA 2024 es una coleccion de casos de uso
marketing RPA 2024 es una coleccion de casos de usomarketing RPA 2024 es una coleccion de casos de uso
marketing RPA 2024 es una coleccion de casos de uso
 

Unidad 3 paradigmas de la ingeniería del software

  • 1. Unidad 2 Paradigmas de la ingeniería del software El Enfoque Estructurado 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. DFD es un diagrama en el que participan procesos (métodos), flujo de datos (argumentos) y archivos (Base de datos). Hay de diferentes niveles dependiendo la complejidad del sistema que se analiza, hablando de lenguajes tiene muchas diferencia con la orientada a objetos, un mínimo cambio en el código puede llegar alterar al resto del programa cosa que en la orientada a objetos eso no sucede lo cual es una ventaja porque así no se pierde tiempo en arreglar cosas ya hechas. Una desventaja es que una porción de código en lenguaje estructurado es difícil que pueda servir en otros proyectos, esto si es habitual en lenguaje orientada a objetos, con solo importar clases ya hechas se escribe menos código y se ahorra tiempo. Diagrama de Flujo de Datos Un diagrama de flujo de datos (DFD) es una representación gráfica de los procesos que se realizan con los datos en su organización, con el uso de tan solo cuatro símbolos, se puede crear una descripción grafica de los procesos que, con el tiempo, contribuirán a desarrollar una sólida documentación del sistema. En seguida mencionan las ventajas sobre las explicaciones descriptivas en relación con la forma en que los datos se mueven a través del sistema:  Libertad para emprender la implementación técnica del sistema en las primeras etapas.  Comprensión más profunda de la interrelación entre sistemas y subsistemas.  Comunicación con los usuarios sobre el conocimiento del sistema actual mediante diagramas de flujos de datos.  Análisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios. La ventaja más grande es la libertad conceptual para utilizar los cuatro símbolos, los DFD’s hacen énfasis en el procesamiento o la transformación conforme estos pasan por una variedad de procesos. En los DFD’s lógicos no hay distinción entre procesos manuales o automatizados. Los procesos tampoco se representan gráficamente en orden cronológico. En vez de ello, se agrupan solo si el análisis detallado dicta que tiene sentido hacerlo. Los procesos manuales se agrupan, y los procesos automatizados también se pueden agrupar. Diccionario de Datos
  • 2. El diccionario de datos surge de la necesidad de catalogar los procesos, flujos almacenes estructuras y elementos de datos. Los nombres que se usan son muy importantes. Cuando se tiene la oportunidad de asignar nombre a los componentes de los sistemas orientados a datos, es necesario trabajar en la creación de un nombre significativo pero diferente al de otros componentes de datos existentes. El diccionario de datos es un listado organizado de todos los elementos de datos que son pertinentes para el sistema, con definiciones precisas y rigurosas que permiten que el usuario y el analista del sistema tenga una misma comprensión de las entradas, salidas, de los componentes de los almacenes y también los cálculos intermedios. A pesar de la existencia de los diccionarios de datos automatizados, entender qué datos conforman un diccionario de datos, las convenciones usadas en estos últimos y cómo se desarrolla un diccionario de datos, son problemas que el analista de sistemas debe tener siempre presentes durante el esfuerzo de sistemas. Entender el proceso de compilar un diccionario de datos puede ayudar al analista de sistemas a visualizar el sistema y su funcionamiento. Además de proporcionar documentación y eliminar la redundancia, el diccionario datos se podría usar para:  Validar la integridad y exactitud del diagrama de flujo de datos.  Proporcionar un punto de partida para desarrollar pantallas e informes.  Determinar el contenido de los datos almacenados en archivos.  Desarrollar la lógica para los procesos del diagrama de flujo de datos. Diseño de Módulo Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Típicamente un Modelo de Datos permite describir: 1. Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. 2. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. 3. Operaciones de manipulación de los datos: Operaciones de agregado, borrado, modificación y recuperación de los datos de la base. 4. 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í. El Enfoque Orientado a Objetos
  • 3. El contexto del Enfoque Orientado a Objetos (EOO) un objeto es una entidad que encapsula datos (atributos) y acciones o funciones que los manejan (métodos). También para el EOO un objeto se define como una instancia o particularización de una clase. Los objetos de interés durante el desarrollo de software no sólo son tomados de la vida real (objetos visibles o tangibles), también pueden ser abstractos. En general son entidades que juegan un rol bien definido en el dominio del problema. Un libro, una persona, un carro, un polígono, son apenas algunos ejemplos de objeto. Cada objeto puede ser considerado como un proveedor de servicios utilizados por otros objetos que son sus clientes. Cada objeto puede ser a la vez proveedor y cliente. De allí que un programa pueda ser visto como un conjunto de relaciones entre proveedores clientes. Los servicios ofrecidos por los objetos son de dos tipos:  Los datos, que llamamos atributos.  Las acciones o funciones, que llamamos métodos.  Fundamentos del Enfoque Orientado a Objeto  El Enfoque Orientado a Objeto se basa en cuatro principios que constituyen la base de todo desarrollo orientado a objetos.  Estos principios son: la Abstracción, el Encapsulamiento, la Modularidad y la Herencia.  Otros elementos a destacar (aunque no fundamentales) en el EOO son: Polimorfismo, Enlace dinámico (o binding), Concurrencia y Persistencia. El análisis orientado a objetos (AOO) y el diseño orientado a objetos (DOO) constituyen un enfoque distinto de desarrollo de sistemas. Estas técnicas se basan en los conceptos de la programación orientada a objetos, que han sido codificados en UML (Lenguaje Unificado de Modelación), un lenguaje estandarizado de modulación en el cual los objetos generados no solo incluyen código referente a los datos sino también instrucciones acerca de las operaciones que se realizaran sobre los datos.
  • 4. El proceso Orientado a Objetos se mueve a través de una espiral evolutiva que comienza con la comunicación con el usuario. Es en esta parte donde se define el dominio del problema y se identifican las clases básicas del problema. La planificación y el análisis de riesgos establecen una base para el plan de proyecto OO. El trabajo técnico asociado con la ingeniería del software OO sigue las siguientes tareas: 1. Identificar clases candidatas 2. Buscar clases en biblioteca 3. Extraer nuevas clases si existen 4. Desarrollar las clases sino existen 5. Añadir las nuevas clases a la biblioteca 6. Construir n-esima iteración del sistema Las principales características del Enfoque Orientado a Objetos son: 1. Objeto: Los datos están cuantificados en entidades discretas y distinguibles llamadas objetos. 2. Clase: Significa que los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupa para formar una clase. 3. Atributo: Describen la clase o el objeto de alguna manera 4. Mensajes: Medio por el cual interactúan los objetos 5. Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases. 6. Herencia: Compartir atributos y operaciones entre clases tomando como base una relación jerárquica. • Identidad: Los datos están cuantificados en entidades discretas y distinguibles denominadas objetos. Estos pueden ser tangibles o intangibles. • Clasificación: Los objetos con la misma estructura de datos (atributos) y comportamiento (operaciones) se agrupan para formar una misma clase, se dice que cada objeto es una instancia de su propia clase, y una clase es una abstracción que describe propiedades importantes para una aplicación y se olvida del resto. • Polimorfismo: Significa que una misma operación puede comportarse de modos distintos en distintas clases, una operación es una acción o transformación que se aplica a un objeto.
  • 5. • Herencia: Comparte atributos y operaciones entre clases tomando como base una relación jerárquica, es decir que se puede definir una clase que después producirá subclases, sabiendo que todas las subclases adquirirán todas y cada una de las propiedades de su super-clase y le agrega además sus propiedades exclusivas. Fase de Diseño Para los sistemas orientados a objetos es posible definir un diseño en pirámide con las siguientes cuatro capas:  Subsistema. Contiene una representación de cada uno de los subsistemas que le permiten al software conseguir los requisitos definidos por el cliente e implementar la infraestructura técnica que los soporta.  Clases y Objetos. Contiene las jerarquías de clases que permiten crear el sistema utilizando generalizaciones y especializaciones mejor definidas incrementalmente. También contiene representaciones de diseño para cada objeto.  Mensajes. Contiene los detalles que permiten a cada objeto comunicarse con sus colaboradores. Establece las interfaces externas e internas para el sistema.  Responsabilidades. Contiene las estructuras de datos y el diseño algorítmico para todos los atributos y operaciones de cada objeto. Conclusion: Bueno de este tema aprendí que las diferencias entre un enfoque estructurado y uno orientado a
  • 6. objetos, aprendí que un enfoque estructurado utiliza los Diagrama de Flujo de Datoscomo principal herramienta para entender al sistema antes de plasmarlo a código fuente, que un DFD es un diagrama en el que participan métodos, argumentos y archivos .