Please enable JavaScript.

Coggle requires JavaScript to display documents.

diseño estructurado (Etapas del diseño estructurado (Descomposición (Para…

- - - - ¿Por qué descomponer un problema en partes? Experimentalmente, está comprobado que:
        
        En cada paso (del refinamiento), una o varias instrucciones del programa dado se descomponen en instrucciones más detalladas.
        
        La complejidad de un problema global es mayor que el valor de las complejidades de cada una de sus partes por separado.
        
        Cada paso de refinamiento implica algunas decisiones de diseño.
        
        Un problema complejo cuesta más de resolver que otro más sencillo (de Perogrullo).
  - - - Cuando la interfaz de un módulo sea tan complicada como el propio módulo.
      - Cuando no haya tareas bien definidas.
- - - - fan-in
      - fan-out.
  - - - Acoplamiento normal
        
        Un módulo llama a otro de un nivel inferior y tan solo intercambian datos (parámetros de entrada/salida).
      - Acoplamiento externo
        
        Los módulos están ligados a componentes externos.
      - Acoplamiento Común
        
        Dos módulos acceden a un mismo recurso común, típicamente memoria compartida, una variable global o un fichero.
      - Acoplamiento de contenido
        
        Ocurre cuando un módulo necesita acceder a una parte de otro módulo.
      - Acoplamiento de datos
        
        Los módulos se comunican mediante parámetros.
      - Acoplamiento de marca o por estampado
        
        Los módulos se pasan datos con estructura de registro.
      - Acoplamiento de control
        
        Los datos que se intercambian entre los módulos son controles.
  - - - En el diseño estructurado podemos encontrarnos con los siguientes siete tipos de cohesión (de la mejor o más deseable a la menos recomendable):
        
        Cohesión secuencial
        
        Cohesión comunicacional
        
        Cohesión procedimental
        
        Cohesión funcional
        
        Cohesión temporal
        
        Cohesión lógica
        
        Cohesión casual o coincidente
  - - - Fan-In:
        
        También llamado grado de absorción, es el número de superordinados inmediatos que tiene el módulo en cuestión. Es conveniente maximizar el fan-in durante el proceso de diseño, ya que cada instancia de fan-in múltiple indica que se ha evitado la duplicación de código.
      - Fan-Out:
        
        También llamado diseminación del control, es el número de subordinados inmediatos que tiene el módulo en cuestión. Conviene no tener un fan-out ni muy alto ni muy bajo, ya que eso es un posible indicador de un diseño pobre. Si no es posible evitarlo, es preferible un fan-out bajo antes que uno alto.