SlideShare una empresa de Scribd logo
REPÚBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR
                 UNIVERSIDAD FERMIN TORO




      DISEÑO ESTRUCTURADO Y SUS TÉCNICAS




                                          Alumno: Cleiver Manzanilla
                                                  C.I. 17.304.303

                  Cabudare, Noviembre 2.012
DISEÑO ESTRUCTURADO

         En programación y diseño de algoritmos, el diseño
estructurado persigue elaborar algoritmos que cumplan la propiedad
de modularidad, para ello, dado un problema que se pretende resolver
mediante la elaboración de un programa de ordenador, se busca dividir
dicho   programa    en   módulos    siguiendo   los   principios   de
diseño de Descomposición por refinamientos sucesivos, creación de
una Jerarquía modular y elaboración de módulos Independientes.
DIAGRAMA DE ESTRUCTURA




ESTRUCTURA
MÓDULO

•Según la Asociación Española para el Control de Calidad [AECC, 1986], un módulo es
                       la parte lógica separable de un programa.


  • Según Yourdon [YOURDON y CONSTANTINE, 1979], un módulo es una secuencia
     contigua de sentencias de programa, limitada por delimitadores y que tiene un
                                 identificador global.


• Según Fenton [FENTON, 1991], un módulo puede ser cualquier objeto que, en un nivel
         de abstracción dado, queramos considerar como un concepto simple.


• En la teoría del diseño estructurado [PAGE-JONES, 1988], un módulo es aquella parte
                            de código que se puede llamar.
CONEXION ENTRE MODULOS

            Un sistema está compuesto por módulos organizados
  jerárquicamente, cooperando y comunicándose entre sí para realizar
  una tarea. La llamada de un módulo se representa con una flecha.


               COMUNICACION ENTRE MODULOS
          La comunicación intermodular se realiza a través de los datos y los
flags. Los datos se procesan; por el contrario, los flags sólo sirven como valores
de condición para comunicar condiciones entre los módulos. Otra diferencia
es que los datos están relacionados con el problema y son importantes para el
mundo exterior, mientras que los flags sólo importan para la comunicación de
información.
TABLA DE INTERFAZ
        1.- El módulo llamado
      2.- Cada parámetro formal
   3.- Si el parámetro es de entrada
(marcando la columna correspondiente)
    4.- Si el parámetro es de salida
(marcando la columna correspondiente)
     5.- El uso de cada parámetro
 6.- El significado de cada parámetro
ESTRATEGIAS DE DISEÑO
Diseño por Transformación: Los datos entran en el sistema mediante caminos
que se denominan flujos de entrada. En el núcleo se produce una transformación
de los datos, y finalmente, los datos se mueven por caminos que conducen a la
salida.




Diseño por transacción: Existe un centro de transacción que es el centro de
flujo, desde el que emanan muchos caminos alternativos de forma exclusiva.
ANALISIS DE TRANSFORMACION

1.   Revisión del modelo fundamental del sistema .
2. Determinar si el DFD tiene características de transformación o de transacción.
3. Aislar el centro de transformación, especificando los límites del flujo de llegada y de salida.
4. Realizar el primer corte del diagrama de estructura.
5. Ejecución del segundo nivel de factorización.
6. Refinar la estructura del sistema utilizando medidas y guías de diseño.
7. Asegurarse del trabajo realizado por el diseño obtenido.
ANALISIS DE TRANSACCION
• Revisión del modelo fundamental del sistema.
•Determinar si el DFD tiene características de transformación o de transacción.
• Identificar el centro de transacción y las características del flujo de cada camino de acción.
             La posición del centro de transacción puede descubrirse inmediatamente a
partir del DFD. El centro de transacción está ligado al origen de varios caminos de información que fluyen de él.
La exclusividad no se suele reflejar en el DFD, por lo que hay que conocer los requisitos.
             Se identifica el camino de llegada, el centro de transacción y los caminos de acción.
ATRIBUTOS DE LA CALIDAD DE UN DISEÑO

 Acoplamiento
            Es el grado de interdependencia entre los módulos. Un buen
 diseño se caracteriza por un acoplamiento mínimo, es decir, unos
 módulos tan independientes los unos de los otros como sea posible.


Cohesión
           Indica la relación que existe entre los elementos de un mismo
módulo. Es la medida de la relación funcional de los elementos de un
módulo.
           El objetivo es organizar estos elementos de manera que los que
tengan una mayor relación a la hora de realizar una tarea pertenezcan al
mismo módulo, y los elementos no relacionados, se encuentren en
módulos separados.
METODOLOGIAS DE DISEÑO DE PROGRAMAS
MODELO JACKSON
• Se basa en el principio de que la base inicial del diseño del programa son los datos del problema
y no los requisitos funcionales exigidos.
• Permite una mayor objetividad.
• Partir de una buena especificación del problema que queremos resolver: datos de
entrada, datos de salida y algoritmos aplicables.
            Una vez obtenida una estructura objetiva del problema, que constituye un reflejo del
mundo real con el que trata el programa, resulta más fácil asignar las distintas funciones a
realizar.


METODOLOGIA WARNIER
Se basa en la aplicación de dos principios:
1. El principio de la ordenación jerárquica de los conjuntos de información (salida, entrada y
programa).
2. El principio de correspondencia en la organización de los conjuntos de información .
TECNICA DE DISEÑO ESTRUCTURADO


                       OBJETIVOS DE LA TECNICA
• Obtener la estructura modular y los detalles de proceso del sistema, partiendo
solamente de los productos obtenidos en la fase de Análisis del Sistema.
• Cambiar la atención del QUE al COMO.
• Obtener un diseño que no sólo «funcione», sino que también sea mantenible, mejore
la reutilización y se pueda probar y entender fácilmente.
• Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros) para
representar la estructura modular del sistema.
CARACTERISTICAS DE LA TECNICA DE DISEÑO

• Módulos de pequeño tamaño
           El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamaño de los
módulos es reducido, una determinada modificación afectará a un número mayor de módulos, sin
embargo, la cantidad de código a considerar será menor.
• Independencia modular
           Cuanto mayor es la independencia de un módulo es más sencillo trabajar con él, por
tanto, el diseño debe reducir la compartición de ficheros, de datos, la de dispositivos, las interfases
comunes con el Sistema Operativo y las llamadas, desde o hacia otros módulos.


• Características de Caja Negra
           La característica de Caja Negra se aplica a cualquier sistema, programa o módulo, para
dar una visión exclusiva de sus entradas y salidas, sin tener en cuenta los detalles de cómo se realiza
el proceso. El uso de la Caja Negra permite una visión más fácil del conjunto, posponiendo la
consideración de los detalles para una etapa posterior.
• Modelización conceptual.
          Un sistema será más fácil de mantener si el modelo utilizado en su diseño se ha
basado en los conceptos lógicos de la organización, los cuales serán más familiares y
comprensibles para el personal de mantenimiento que las descripciones físicas
(equipo, organización de la unidad, cómo se realiza el trabajo en la actualidad.


• Aislamiento de los detalles.
          En un sistema existen partes que reflejan la filosofía y otras partes que reflejan
los detalles. Debido a que los detalles son más susceptibles de cambiar, ambas partes
deben diseñarse por separado para evitar que una variación en los detalles afecte a la
filosofía del sistema.
FIN

Más contenido relacionado

La actualidad más candente

Disponibilidad de datos
Disponibilidad de datosDisponibilidad de datos
Disponibilidad de datosUTN
 
Procesos de software Unidad 2 - Software Enginnering - Ian sommerville
Procesos de software  Unidad 2 - Software Enginnering - Ian sommervilleProcesos de software  Unidad 2 - Software Enginnering - Ian sommerville
Procesos de software Unidad 2 - Software Enginnering - Ian sommervilleMatias Gonzalo Acosta
 
Modelo componentes
Modelo componentesModelo componentes
Modelo componentesmartin
 
2 1 vistas arquitectonicas
2 1 vistas arquitectonicas2 1 vistas arquitectonicas
2 1 vistas arquitectonicaslandeta_p
 
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING) METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING) Germán Sánchez
 
Metodología de Diseño Estructurado.pptx
Metodología de Diseño Estructurado.pptx Metodología de Diseño Estructurado.pptx
Metodología de Diseño Estructurado.pptx AlvareL
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareKelvin Abdiel Alvarado
 
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.raquel yendez avila
 
Tema N° 14 Especificación de Requisitos del Software
Tema N° 14 Especificación de Requisitos del SoftwareTema N° 14 Especificación de Requisitos del Software
Tema N° 14 Especificación de Requisitos del SoftwareSaraEAlcntaraR
 
Modelamiento de software
Modelamiento de softwareModelamiento de software
Modelamiento de softwaresairarcf
 
Diseno de la arquitectura
Diseno de la arquitecturaDiseno de la arquitectura
Diseno de la arquitecturaFatima Cham
 
Examen de analisis de sistemas ii nro2 sin
Examen de analisis de sistemas ii nro2 sinExamen de analisis de sistemas ii nro2 sin
Examen de analisis de sistemas ii nro2 sinjesus122012
 
Diseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanDiseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanArianna Peralta
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionalesAngel Minga
 

La actualidad más candente (20)

Disponibilidad de datos
Disponibilidad de datosDisponibilidad de datos
Disponibilidad de datos
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Procesos de software Unidad 2 - Software Enginnering - Ian sommerville
Procesos de software  Unidad 2 - Software Enginnering - Ian sommervilleProcesos de software  Unidad 2 - Software Enginnering - Ian sommerville
Procesos de software Unidad 2 - Software Enginnering - Ian sommerville
 
Modelo componentes
Modelo componentesModelo componentes
Modelo componentes
 
2 1 vistas arquitectonicas
2 1 vistas arquitectonicas2 1 vistas arquitectonicas
2 1 vistas arquitectonicas
 
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING) METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
METODOLOGÍA UWE (UML-BASED WEB ENGINEERING)
 
Metodología de Diseño Estructurado.pptx
Metodología de Diseño Estructurado.pptx Metodología de Diseño Estructurado.pptx
Metodología de Diseño Estructurado.pptx
 
Requerimientos en Ingenieria de Software
Requerimientos en Ingenieria de SoftwareRequerimientos en Ingenieria de Software
Requerimientos en Ingenieria de Software
 
13.diseño de web apps
13.diseño de web apps13.diseño de web apps
13.diseño de web apps
 
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.
 
Tema N° 14 Especificación de Requisitos del Software
Tema N° 14 Especificación de Requisitos del SoftwareTema N° 14 Especificación de Requisitos del Software
Tema N° 14 Especificación de Requisitos del Software
 
Modelamiento de software
Modelamiento de softwareModelamiento de software
Modelamiento de software
 
Diseno de la arquitectura
Diseno de la arquitecturaDiseno de la arquitectura
Diseno de la arquitectura
 
Ingenieria de Requisitos
Ingenieria de RequisitosIngenieria de Requisitos
Ingenieria de Requisitos
 
Estilos arquitectónicos
Estilos arquitectónicosEstilos arquitectónicos
Estilos arquitectónicos
 
Modelo 4+1
Modelo 4+1Modelo 4+1
Modelo 4+1
 
Examen de analisis de sistemas ii nro2 sin
Examen de analisis de sistemas ii nro2 sinExamen de analisis de sistemas ii nro2 sin
Examen de analisis de sistemas ii nro2 sin
 
Diseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanDiseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizan
 
Requerimientos no funcionales
Requerimientos no funcionalesRequerimientos no funcionales
Requerimientos no funcionales
 

Destacado

Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoDascorp
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoOswaldo Perez
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoangelan00
 
DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)
DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)
DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)marialej90
 
ANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOS
ANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOSANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOS
ANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOSanalisiscurricular
 
Análisis y diseño estructurado
Análisis y diseño estructuradoAnálisis y diseño estructurado
Análisis y diseño estructuradoIsbel Alfonzo
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoadrianjosv
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradomateraactivo
 
Proyecto de cableado estructurado y diseño de red
Proyecto de cableado estructurado y diseño de redProyecto de cableado estructurado y diseño de red
Proyecto de cableado estructurado y diseño de redlio_wil
 

Destacado (10)

Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)
DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)
DISEÑO ESTRUCTURADO(MAPA CONCEPTUAL)
 
ANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOS
ANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOSANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOS
ANALISIS Y EVALUACION DE DISENO ESTRUCTURADO DE ALGORITMOS
 
Análisis y diseño estructurado
Análisis y diseño estructuradoAnálisis y diseño estructurado
Análisis y diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Proyecto de cableado estructurado y diseño de red
Proyecto de cableado estructurado y diseño de redProyecto de cableado estructurado y diseño de red
Proyecto de cableado estructurado y diseño de red
 

Similar a Diseño estructurado

Diseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanDiseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanJonathan Bastidas
 
Diseño de software
Diseño de softwareDiseño de software
Diseño de softwareandrestorr3
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructuradoYamnibel
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...negroues
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...negroues
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIJimmyWilfredMassVerd
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteCAMILO
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del softwaremrquaife
 
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTEPRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTECAMILO
 
Presentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de CostePresentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de CosteCAMILO
 
Proyecto de Software y Coste
Proyecto de Software y CosteProyecto de Software y Coste
Proyecto de Software y CosteCAMILO
 
presentacion de software y estimacion de doste
presentacion de software y estimacion de dostepresentacion de software y estimacion de doste
presentacion de software y estimacion de dosteCAMILO
 
PROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOSPROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOSCAMILO
 
Proyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de CostoProyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de CostoCAMILO
 
desarrollo de software
desarrollo de softwaredesarrollo de software
desarrollo de softwareJean Davila
 
Comunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertidoComunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertidoJamil Cajamarca
 

Similar a Diseño estructurado (20)

Diseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizanDiseño estructurado y las técnicas que lo caracterizan
Diseño estructurado y las técnicas que lo caracterizan
 
Diseño de software
Diseño de softwareDiseño de software
Diseño de software
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Diseño estructurado
Diseño estructuradoDiseño estructurado
Diseño estructurado
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
 
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...Clase no. 1 unidad no. iii  introduccion al analisis y diseño estructurado  d...
Clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado d...
 
Diseno
DisenoDiseno
Diseno
 
Fundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas IIFundamentos Básicos para el Diseño del Software - Sistemas II
Fundamentos Básicos para el Diseño del Software - Sistemas II
 
Proyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de CosteProyecto de Software y Estimacion de Coste
Proyecto de Software y Estimacion de Coste
 
Fundamentos del software
Fundamentos del softwareFundamentos del software
Fundamentos del software
 
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTEPRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
PRESENTACION: PROYECTO DE SOFTWARE & ESTIMACION DE COSTE
 
Desarrollo de software
Desarrollo de softwareDesarrollo de software
Desarrollo de software
 
Presentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de CostePresentacion de Software y Estimacion de Coste
Presentacion de Software y Estimacion de Coste
 
Proyecto de Software y Coste
Proyecto de Software y CosteProyecto de Software y Coste
Proyecto de Software y Coste
 
presentacion de software y estimacion de doste
presentacion de software y estimacion de dostepresentacion de software y estimacion de doste
presentacion de software y estimacion de doste
 
PROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOSPROYECTOS DE SOFTWARE Y COSTOS
PROYECTOS DE SOFTWARE Y COSTOS
 
Proyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de CostoProyecto de Software y Estimacion de Costo
Proyecto de Software y Estimacion de Costo
 
Deber analisis
Deber analisisDeber analisis
Deber analisis
 
desarrollo de software
desarrollo de softwaredesarrollo de software
desarrollo de software
 
Comunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertidoComunidad emagister 63082_63082-convertido
Comunidad emagister 63082_63082-convertido
 

Diseño estructurado

  • 1. REPÚBLICA BOLIVARIANA DE VENEZUELA MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR UNIVERSIDAD FERMIN TORO DISEÑO ESTRUCTURADO Y SUS TÉCNICAS Alumno: Cleiver Manzanilla C.I. 17.304.303 Cabudare, Noviembre 2.012
  • 2. DISEÑO ESTRUCTURADO En programación y diseño de algoritmos, el diseño estructurado persigue elaborar algoritmos que cumplan la propiedad de modularidad, para ello, dado un problema que se pretende resolver mediante la elaboración de un programa de ordenador, se busca dividir dicho programa en módulos siguiendo los principios de diseño de Descomposición por refinamientos sucesivos, creación de una Jerarquía modular y elaboración de módulos Independientes.
  • 4. MÓDULO •Según la Asociación Española para el Control de Calidad [AECC, 1986], un módulo es la parte lógica separable de un programa. • Según Yourdon [YOURDON y CONSTANTINE, 1979], un módulo es una secuencia contigua de sentencias de programa, limitada por delimitadores y que tiene un identificador global. • Según Fenton [FENTON, 1991], un módulo puede ser cualquier objeto que, en un nivel de abstracción dado, queramos considerar como un concepto simple. • En la teoría del diseño estructurado [PAGE-JONES, 1988], un módulo es aquella parte de código que se puede llamar.
  • 5. CONEXION ENTRE MODULOS Un sistema está compuesto por módulos organizados jerárquicamente, cooperando y comunicándose entre sí para realizar una tarea. La llamada de un módulo se representa con una flecha. COMUNICACION ENTRE MODULOS La comunicación intermodular se realiza a través de los datos y los flags. Los datos se procesan; por el contrario, los flags sólo sirven como valores de condición para comunicar condiciones entre los módulos. Otra diferencia es que los datos están relacionados con el problema y son importantes para el mundo exterior, mientras que los flags sólo importan para la comunicación de información.
  • 6. TABLA DE INTERFAZ 1.- El módulo llamado 2.- Cada parámetro formal 3.- Si el parámetro es de entrada (marcando la columna correspondiente) 4.- Si el parámetro es de salida (marcando la columna correspondiente) 5.- El uso de cada parámetro 6.- El significado de cada parámetro
  • 7. ESTRATEGIAS DE DISEÑO Diseño por Transformación: Los datos entran en el sistema mediante caminos que se denominan flujos de entrada. En el núcleo se produce una transformación de los datos, y finalmente, los datos se mueven por caminos que conducen a la salida. Diseño por transacción: Existe un centro de transacción que es el centro de flujo, desde el que emanan muchos caminos alternativos de forma exclusiva.
  • 8. ANALISIS DE TRANSFORMACION 1. Revisión del modelo fundamental del sistema . 2. Determinar si el DFD tiene características de transformación o de transacción. 3. Aislar el centro de transformación, especificando los límites del flujo de llegada y de salida. 4. Realizar el primer corte del diagrama de estructura. 5. Ejecución del segundo nivel de factorización. 6. Refinar la estructura del sistema utilizando medidas y guías de diseño. 7. Asegurarse del trabajo realizado por el diseño obtenido.
  • 9. ANALISIS DE TRANSACCION • Revisión del modelo fundamental del sistema. •Determinar si el DFD tiene características de transformación o de transacción. • Identificar el centro de transacción y las características del flujo de cada camino de acción. La posición del centro de transacción puede descubrirse inmediatamente a partir del DFD. El centro de transacción está ligado al origen de varios caminos de información que fluyen de él. La exclusividad no se suele reflejar en el DFD, por lo que hay que conocer los requisitos. Se identifica el camino de llegada, el centro de transacción y los caminos de acción.
  • 10. ATRIBUTOS DE LA CALIDAD DE UN DISEÑO Acoplamiento Es el grado de interdependencia entre los módulos. Un buen diseño se caracteriza por un acoplamiento mínimo, es decir, unos módulos tan independientes los unos de los otros como sea posible. Cohesión Indica la relación que existe entre los elementos de un mismo módulo. Es la medida de la relación funcional de los elementos de un módulo. El objetivo es organizar estos elementos de manera que los que tengan una mayor relación a la hora de realizar una tarea pertenezcan al mismo módulo, y los elementos no relacionados, se encuentren en módulos separados.
  • 11. METODOLOGIAS DE DISEÑO DE PROGRAMAS MODELO JACKSON • Se basa en el principio de que la base inicial del diseño del programa son los datos del problema y no los requisitos funcionales exigidos. • Permite una mayor objetividad. • Partir de una buena especificación del problema que queremos resolver: datos de entrada, datos de salida y algoritmos aplicables. Una vez obtenida una estructura objetiva del problema, que constituye un reflejo del mundo real con el que trata el programa, resulta más fácil asignar las distintas funciones a realizar. METODOLOGIA WARNIER Se basa en la aplicación de dos principios: 1. El principio de la ordenación jerárquica de los conjuntos de información (salida, entrada y programa). 2. El principio de correspondencia en la organización de los conjuntos de información .
  • 12. TECNICA DE DISEÑO ESTRUCTURADO OBJETIVOS DE LA TECNICA • Obtener la estructura modular y los detalles de proceso del sistema, partiendo solamente de los productos obtenidos en la fase de Análisis del Sistema. • Cambiar la atención del QUE al COMO. • Obtener un diseño que no sólo «funcione», sino que también sea mantenible, mejore la reutilización y se pueda probar y entender fácilmente. • Utilizar herramientas gráficas (Diagramas de Estructura de Cuadros) para representar la estructura modular del sistema.
  • 13. CARACTERISTICAS DE LA TECNICA DE DISEÑO • Módulos de pequeño tamaño El impacto de un cambio a realizar puede ser perfectamente aislado. Si el tamaño de los módulos es reducido, una determinada modificación afectará a un número mayor de módulos, sin embargo, la cantidad de código a considerar será menor. • Independencia modular Cuanto mayor es la independencia de un módulo es más sencillo trabajar con él, por tanto, el diseño debe reducir la compartición de ficheros, de datos, la de dispositivos, las interfases comunes con el Sistema Operativo y las llamadas, desde o hacia otros módulos. • Características de Caja Negra La característica de Caja Negra se aplica a cualquier sistema, programa o módulo, para dar una visión exclusiva de sus entradas y salidas, sin tener en cuenta los detalles de cómo se realiza el proceso. El uso de la Caja Negra permite una visión más fácil del conjunto, posponiendo la consideración de los detalles para una etapa posterior.
  • 14. • Modelización conceptual. Un sistema será más fácil de mantener si el modelo utilizado en su diseño se ha basado en los conceptos lógicos de la organización, los cuales serán más familiares y comprensibles para el personal de mantenimiento que las descripciones físicas (equipo, organización de la unidad, cómo se realiza el trabajo en la actualidad. • Aislamiento de los detalles. En un sistema existen partes que reflejan la filosofía y otras partes que reflejan los detalles. Debido a que los detalles son más susceptibles de cambiar, ambas partes deben diseñarse por separado para evitar que una variación en los detalles afecte a la filosofía del sistema.
  • 15. FIN