Sie sind auf Seite 1von 10

PARADIGMAS DE LA INGENIERIA DE SOFTWARE

GARCIA LARA NAYELI YANIRA

BALDERAS MACIAS RICARDO YOSIMAR


SANCHEZ AGUILAR JORGE ALBERTO 361-M

INDICE

3. INTRODUCCION 3.1 EL ENFOQUE ESTRUCTURADO 3.1.1 Diagrama de flujo de datos 3.1.2 Diccionario de datos 3.1.3 Diseo de mdulos 3.1.4 Descomposicin en procesos. 3.2 EL ENFOQUE ORIENTADO A OBJETOS 3.2.1 Anlisis 3.2.2 Diseo 3.3 CONCLUSIONES 3.4 BIBLIOGRAFIA 3.5 GLOSARIO

INTRODUCCION
La ingeniera de software surge de la ingeniera de sistemas y de hardware. Abarca un conjunto de tres elementos que facilitan el control sobre el proceso de desarrollo de software y suministran las bases para construir software de calidad de una forma productiva: Mtodos Herramientas Procedimientos Mtodos que indican cmo construir el software tcnicamente e incluyen un amplio espectro de mtodos para la planificacin, la estimacin, el anlisis, el diseo, codificacin, prueba y mantenimiento. Herramientas automticas y semiautomticas que apoyan a la aplicacin de los mtodos. Cuando se integran las herramientas de forma que la informacin creada por una herramienta puede ser usada por otra, se establece un sistema para el soporte del desarrollo de software, llamado Ingeniera de Software Asistida por Computadora ( CASE ). Procedimientos que definen la secuencia en la que se aplican los mtodos, las entregas, los controles de calidad y guas para evaluacin del progreso. La Ingeniera de Software est compuesta por una serie de pasos que abarcan los mtodos, herramientas y procedimientos mencionados, a los que se denominan Paradigmas de la Ingeniera de Software.

PARADIGMAS DE LA INGENIERIA DE SOFTWARE


Paradigmas de programacin: a) Los que soportan tcnicas de programacin de bajo nivel (copia de ficheros frente estructuras De datos compartidos) b) Los que soportan mtodos de diseo de algoritmos (programacin dinmica) c) Los que soportan soluciones de programacin de alto nivel.

La ingeniera de software est compuesta por una serie de pasos de abarcan los mtodos, las herramientas y los procedimientos antes mencionados. Estos pasos se denominan frecuentemente paradigmas de la ingeniera de software. La eleccin de un paradigma para la ingeniera de software se lleva a cabo de acuerdo con la naturaleza del proyecto y de la aplicacin, los mtodos, herramientas a usar, los controles y entregas requeridos.

3.1 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 cdigo fuente. DFD es un diagrama en el q participan procesos (mtodos), flujo de datos (argumentos) y archivos (base de datos). Hay de

diferentes niveles dependiendo la complejidad del sistema q analiza. Otra desventaja es que una porcin de cdigo en lenguaje estructurado es difcil que pueda servir en otros proyectos.

3.1.1 Diagrama de flujos de datos


Un diagrama de flujo de datos (DFD) es un modelo lgico-grfico para representar el funcionamiento de un sistema en un proyecto software. ELEMENTOS GRFICOS Crculos; Los crculos significan procesos Flechas; las flechas flujos de datos desde, o hacia, un proceso. Rectngulos cerrados o abiertos; Los cerrados representan entidades externas mientras que los abiertos describen almacenes o archivos.

En un DFD tambin se utiliza la escritura. Los flujos, entidades externas y los almacenes se etiquetan con un nombre. Un diagrama de flujo de datos puede ser profundizado expandiendo algunos de sus procesos en subprocesos, en este caso la etiqueta tendr un nmero adicional. No hay un lmite para el nmero de procesos.

3.1.2 Diccionario de datos DEFINICION:


Un diccionario de datos es un conjunto de mtodos que contiene las caractersticas lgicas de los datos que se van a utilizar en el sistema que se programa, incluyendo nombre, descripcin, alias, contenido y organizacin. El diccionario de datos es un listado organizado de todos los datos que pertenecen a un sistema.

OBJETIVOS
Un diccionario de datos es dar precisin sobre los datos que se manejan en un sistema, evitando as malas interpretaciones o ambigedades. Define con precisin los datos de entrada, salida, componentes de almacenes, flujos, detalles de las relaciones entre almacenes, etc. Los diccionarios de datos son buenos complementos a los diagramas de flujo de datos, los diagramas de entidad-relacin, etc.

3.1.3 DISEO DE MODULOS


Un modelo de datos es un lenguaje orientado a describir una Base de Datos. Tpicamente un Modelo de Datos permite describir: Las estructuras de datos de la base: El tipo de los datos que hay en la base y la forma en que se relacionan. Las restricciones de integridad: Un conjunto de condiciones que deben cumplir los datos para reflejar correctamente la realidad deseada. Operaciones de manipulacin de los datos: tpicamente, operaciones de agregado, borrado, modificacin y recuperacin de los datos de la base.

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. Modelos de Datos Lgicos: Son orientados a las operaciones ms que a la descripcin de una realidad. Usualmente estn implementados en algn Manejador de Base de Datos. El ejemplo ms tpico es el Modelo Relacional, que cuenta con la particularidad de contar tambin con buenas caractersticas conceptuales (Normalizacin de bases de datos). Modelos de Datos Fsicos: Son estructuras de datos a bajo nivel implementadas dentro del propio manejador. Ejemplos tpicos de estas estructuras son los rboles B+, las estructuras de Hash, etc.

3.1.4 DESCOMPOSICION EN PROCESOS 3.1.4.1 DESCOMPOSICIN FUNCIONAL


Cada proceso se puede explotar, refinar o descomponer en un DFD ms detallado. El DFD de un sistema es realmente un conjunto de DFDs dispuestos jerrquicamente. Los niveles de la jerarqua estn determinados por la descomposicin funcional de los procesos. La raz de la jerarqua es el diagrama de contexto, que es el ms general de todos. 3.2 EL ENFOQUE ORIENTADO A OBJETOS Actualmente una de las reas ms candentes en la industria y en el mbito acadmico es la orientacin a objetos. La orientacin a objetos promete mejoras de amplio alcance en la forma de diseo, desarrollo y mantenimiento

del software ofreciendo una solucin a largo plazo a los problemas y preocupaciones que han existido desde el comienzo en el desarrollo de software: la falta de portabilidad del cdigo y reusabilidad, cdigo que es difcil de modificar, ciclos de desarrollo largos y tcnicas de codificacin no intuitivas. Un lenguaje orientado a objetos ataca estos problemas. Tiene tres caractersticas bsicas: debe estar basado en objetos, basado en clases y capaz de tener herencia de clases. 3.2.1 ANALISIS El modelo de anlisis se extiende luego para describir la manera en que interactan los actores y el sistema para manipular el modelo del dominio de aplicacin. Los desarrolladores usan el modelo de anlisis, junto con los requerimientos no funcionales, para preparar la arquitectura del sistema que se desarrolla durante el diseo de alto nivel. Las actividades del anlisis: la identificacin de objetos, su comportamiento, sus relaciones, su clasificacin y su organizacin. El modelo de anlisis est compuesto por tres modelos individuales: el modelo funcional, representado por casos de uso y escenarios, el modelo de objetos de anlisis, representado por diagramas de clase y objeto, y el modelo dinmico, representado por grficas de estado y diagramas de secuencia.

3.2.2 DISEO
Durante el diseo de objetos cerramos el hueco entre los objetos de aplicacin y los componentes hechos, identificando objetos de solucin adicionales y refinando los objetos existentes. El diseo de objetos incluye: Especificacin de servicios, durante la cual describimos con precisin cada interfaz de clase. Seleccin de componentes, durante la cual identificamos componentes hechos y objetos de solucin adicionales.

Reestructuracin del modelo de objetos, durante la cual transformamos el modelo de diseo de objetos para mejorar su comprensibilidad y extensibilidad. Optimizacin del modelo de objetos, durante la cual transformamos el modelo de diseo de objetos para tratar criterios de desempeo, como el tiempo de respuesta o la utilizacin de la memoria. El diseo de objetos, al igual que el diseo del sistema, no es algortmico.

Das könnte Ihnen auch gefallen