clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado diseño estructurado

1

TEMA No. 1INTRODUCCION AL

DISEÑO ESTRUCTURADO

2

CONTENIDO

1.1. El proceso de diseño.El proceso de diseño.

2.2. Diseño estructurado.Diseño estructurado.2.1 Diagramas de estructura.2.1 Diagramas de estructura.

2.2. Estrategias de diseño:2.2. Estrategias de diseño:2.2.1. Análisis de transformaciones.2.2.1. Análisis de transformaciones.

2.2.2 Análisis de transacciones.2.2.2 Análisis de transacciones.

El proceso de diseño y el Diseño EstructuradoEl proceso de diseño y el Diseño Estructurado

1. El proceso de diseñoEl proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realización física.Proceso iterativo a través del cual se traducen los requisitos en una representación del software.

2. El diseño estructurado es un enfoque disciplinado

de la transformación de qué es necesario para el desarrollo de un sistema, a cómo deberá ser la implementación..

6

Definiciones de la BD

Diccionariode Datos

Diagrama de flujo de datos

PROC

B

Z

Y

X

W

V

APROC

PROC

PROCPROC

FUENTE

DESTINO

D ALMACÉN DE DATOS

Diagrama E-R (o DED)

Diagrama de estructuras

Paso al diseño

Descripcióndel proceso

Definición del FD

Definiciones de los módulos

Descrip.E. E.

7

El Procesode Diseño.

8

Diseño de datosTransforma el modelo del dominio de la información del análisis en las estructuras de datos necesarias para la implementación.Esquema Lógico de Datos ó Modelo Relacional.

Diseño arquitectónicoEstructura modular del programa/aplicaciónDiagramas de Estructura de Cuadros de Constantine

Diseño de interfazInterfaces del sistema con otros sistemas y con los usuarios.

Diseño procedimentalDescripción procedimental de los componentes del sistema

1. El Proceso de DiseñoEl Proceso de Diseño

9

El Diseño Estructurado

10

Objetivos del diseño estructuradoMáxima inteligibilidad del sistema.

Facilitar la comprensión de la aplicación redunda en la disminución del coste (tiempo/medios) asociado al aprendizaje del mismo desde el punto de vista técnico, y redunda en una mejora en los plazos y garantías de éxito en el mantenimiento del sistema.

Minimizar el coste asociado al mantenimiento.La dificultad de mantenimiento, tanto correctivo como preventivo, debe reducirse para

garantizar una correcta explotación del sistema. Ello incluye, por ejemplo, la reutilización en la medida de lo posible de código ya existente y probado.


11

Objetivos del diseño estructurado Facilitar la prueba.

A medida que aumenta la complejidad del sistema se produce un incremento significativo en la complejidad de la prueba. Una adecuada estructuración modular persigue la simplificación de este proceso. Este objetivo se materializaen el desarrollo de procedimientos de prueba durante el diseño.

Integración del sistema.Ello supone garantizar el correcto encaje del sistema como parte de un Sistema de Información Gerencial global, es decir, obtener una aplicación plenamente integrada con el resto de subsistemas de información de la organización.


12

Principios generales del diseño estructurado

a) Modularización.

Se persigue que la Arquitectura técnica del sistema se fundamente en módulos de pequeño tamaño.

b) Independencia modular.

Cada uno de los módulos del sistema debe orientarse hacia la cumplimentación de una función bien definida e independiente, lo cual permita “aislar” el origen de un problema o el área del sistema a modificar en caso preciso.


13

Principios generales del diseño estructuradoc) Modelización conceptual.

La estructuración del sistema en módulos no debe atender a un criterio exclusivamente técnico en sentido reducido, sino que debe reflejar conceptualmente la estructura de la organización a la que sirve, de modo que se facilite su comprensión.

d) Principio de “caja negra”. Una correcta definición de las interfaces tanto internas (entre módulo y módulo) como externas (hacia otros subsistemas del Sistema de Información Gerencial de la organización) permitirá ignorar la estructura interna del módulo tratado (es decir, considerarlo como una “caja negra”) y centrar la atención exclusivamente en los resultados de la función que realiza.


14

Conceptos fundamentales de diseño estructuradoa)Cohesión

Se define como la medida de fuerza o relación funcional existente entre las sentencias o grupos de sentencias de un mismo módulo. Un módulo coherente ejecutará una única tarea sencilla interactuando muy poco o nada con el resto de módulos del programa. Se persigue que los módulos tengan una alta cohesión.La cohesión es la medida cualitativa de cuan estrechamente relacionados están los elementos internos de un módulo.“cantidad de funciones realizadas por un módulo.”

b)AcoplamientoSe define como el grado de interdependencia que hay entre los distintos módulos de un programa; lo deseable es que esta interdependencia sea lo menor posible, es decir, un bajo acoplamiento.


15

CONT…. Conceptos fundamentales de diseño estructurado:

a)Cohesión b)Acoplamiento

Sin embargo, y a la hora de afrontar el diseño de una aplicación informática, las restricciones impuestas tanto por el entorno tecnológico como por la necesidad de perseguir otros objetivos pueden llevar a aceptar soluciones que, en todo caso, garanticen un nivel alto de cohesión en todos los módulos de la aplicación.

Los criterios para definir el nivel de cohesión existente aparecen ordenados de menor a mayor en la siguiente secuencia:


16


Tipos de cohesión (orden. De peor a mejor)

1.Cohesión coincidental. Este es el caso en el que el mismo módulo realiza varias tareas, las cuales tienen entre ellas una relación débil, ya sea funcional o de otro tipo.Ejemplo: “Buscar Cliente y Calcular Factura”.

2. Cohesión lógica. El módulo realizará tareas diversas entre las cuales exista una conexión lógica.“Se ejecutan distintas tareas pero semejantes”Ejemplo: “Calcular saldos de Cta. Cte. y Caja de ahorro”, son todos cálculos de distintas cosas.


17

3. Cohesión temporal. Las tareas que realiza el módulo deben ser realizadas al mismo tiempo.

“Las tareas se relacionan por el tiempo en que deben ejecutarse.”Ejemplo “Abrir archivo e inicializar vectores”, ambas se ejecutan al inicio del programa.

4. Cohesión procedimental o secuencial. El módulo realiza un procedimiento completo o una secuencia de tareas del mismo tales que deben realizarse en un orden preciso y el resultado de una tarea se utiliza para el comienzo de la siguiente.

Las tareas se relacionan por señales de control. Importa la secuencia.Ejemplo: “Abrir archivo y buscar alumno”, para buscar un alumno debo abrir antes el archivo que contiene sus datos.


18

5. Cohesión de comunicación o cumunicacional. Este caso se presenta cuando todas las tareas efectuadas por el módulo se alimentan de una estructura de datos común, es decir, todas ellas utilizan la misma “materia prima”.

“Todas las tareas requieren la misma señal de datos. No importa la secuencia”

Ejemplo: “Grabar e imprimir Factura”. Ambas requieren los datos de la factura para ejecutarse, pero son independientes.

6. Cohesión funcional. “Hacer una y solo una tarea”

Ejemplo: “Abrir Archivo”, solo abre el archivo.


19

b) Acoplamiento El acoplamiento presenta una gradación que, de menor a mayor, se recoge en los siguientes puntos:

1.Sin acoplamiento directo.2.Acoplamiento de datos simple. En este caso la comunicación entre dos

módulos viene dada por una lista simple de parámetros que el primero pasa al segundo, y que éste último utiliza para la realización de su función.

3. Acoplamiento por estampado o de Marca. Las unidades de software se pasan datos con estructura de registro. No es muy deseable si la unidad receptora sólo requiere parte de los datos que se le pasan.

4. Acoplamiento de control. los datos que se intercambian entre las

unidades de software son controles. Debido a que en este subtipo una unidad controla la ejecución de otra, no es un buen acoplamiento, ya que impide que sean totalmente independientes.


20


5)Acoplamiento externo. Es el que se presenta entre un módulo de la aplicación e información o dispositivos externos a la misma.

Las unidades de software están ligadas a componentes externos, como por ejemplo:

Dispositivos de entrada/salida Protocolos de comunicaciones, etc.


21


6)Acoplamiento común. Se presenta cuando todos o una gran parte de los módulos de la aplicación acceden a un área de datos común. (generalmente memoria compartida, una variable global o un fichero.) Por ejemplo, supongamos que se tiene un sistema de gestión de inventarios instalado en una compañía. El nombre de la compañía está almacenado en una tabla de parámetros del sistema, la cual es accedida por todos los módulos que presentan pantallas o que elaboran informes (para que aparezca en cabeceras en ambos casos).

7. Acoplamiento por contenido. ocurre cuando una unidad de software necesita acceder a una parte de otra unidad de software


22

Fan-In y Fan-Out Además del acoplamiento y la cohesión, se deben tener en cuenta el

grado de absorción (fan-in) y la diseminación del control (fan-out) de los módulos para garantizar la calidad del diseño.

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.


23

Factores que influencian el AcoplamientoLos cuatro factores principales que influyen en el acoplamiento entre

módulos son:1.Tipo de conexión entre módulos: los sistemas normalmente

conectados, tienen menor acoplamiento que aquellos que tienen conexiones patológicas.(Si un sistema no está mínima o normalmente conectados, entonces algunos de sus módulos presentarán conexiones patológicas. Esto significa que al menos un módulo tendrá referencias explícitas a identificadores definidos dentro de los límites de otro módulo.)

2. Complejidad de la interface: Cuanto más compleja es una conexión, mayor acoplamiento se tiene. Un módulo con una interface de 100 parámetros generará mayor acoplamiento que uno que solo necesite tres parámetros.Esto es aproximadamente igual al número de ítems diferentes pasados (no cantidad de datos). Más ítems, mayor acoplamiento.

3. Tipo de flujo de información en la conexión: los sistemas con acoplamiento de datos tienen menor acoplamiento que los sistemas con acoplamiento de control, y estos a su vez menos que los que tienen acoplamiento híbrido.


24

Factores que influencian el AcoplamientoLos cuatro factores principales que influyen en el acoplamiento entre módulos son:

4. Momento en que se produce el ligado de la Conexión: Conexiones ligadas a referentes fijos en tiempo de ejecución, resultan con menor acoplamiento que cuando el ligado tiene lugar en tiempo de carga, el cual tiene a su vez menor acoplamiento que cuando el ligado se realiza en tiempo de linkage-edición, el cual tiene menos acoplamiento que el que se realiza en tiempo de compilación, todos los que a su vez tiene menos acoplamiento que cuando el ligado se realiza en tiempo de codificación.


25

2.1 DIAGRAMA DE ESTRUCTURA

26

DISEÑO ESTRUCTURADO2.1 DIAGRAMA DE ESTRUCTURA

27

DISEÑO ESTRUCTURADODIAGRAMA DE ESTRUCTURA: EJEMPLO

28

Diseño Estructurado: Diagrama de estructura 2.1.1 (Diagrama de estructura de cuadros de

Constantine).Diseño de la Arquitectura del Sistema:

Diagrama de módulos funcionales.Identifica qué módulos se necesitan, así como sus inputs/outputs (caja negra).Refleja la comunicación de datos y control y la jerarquía entre módulos.

Diagrama de estructura. Elementos constituyentes :

1. Módulos.2. Conexiones.3. Comunicaciones.

29

“Aquella parte de código que se puede llamar”.

(Page-Jones 88).

Representa un programa, subprograma o rutina, dependiendo del lenguaje que se vaya a utilizar.

Admite parámetros de llamada y retorna algún valor, si es preciso.

Tamaño ideal: 40-50 líneas

Se representa en el diagrama mediante un rectángulo.

Diseño Estructurado Diagrama de estructura

1. Módulo

30

OBTENER DATOS

CLIENTES

MODULO

IMPRIMIR CHEQUE DE

PAGO

MODULO PREDEFINIDO

En Métrica también se dispone de:

Almacenes de datos

Dispositivos físicos

NOMBRE

DISPOSITIVO

1

CONECTOR

La conexión entre módulos se representa mediante una línea.

En la figura: A llama a B. B hace su función. B retorna a A, inmediatamente

después del lugar donde se produjo la llamada de A a B.

El diagrama no dice nada sobre el código de A ni sobre el de B, lo único que sabe es que en A existe una sentencia del tipo CALL B.

CONEXION

MODULO QUE LLAMA

MODULO LLAMADOB

A

Diseño EstructuradoDiagrama de estructura

Conexión entre Módulos

32

A

CB

Estructura repetitiva

Estructura alternativa

Orden de ejecución de los módulos: de izquierda a derecha y de arriba abajo (Piattini et al. 96).

33

Menú login

Procesos para departamentos

Procesos para Agentes externos

Procesos Generales

Ejemplo típico de menú:

34

Los signos para llevar a cabo la comunicación entre módulos son:

Flags o controles

DatosValidar campo

alfabéticoObtener campo

siguiente

Obtener datos clientes

campo

campo correcto

EOR

EOR

campo

campo alfabético correcto


Comunicación entre Módulos

35

Mediante los “flags” o controles, se puede representar:Paso de control entre módulos: un módulo

comunica a otro módulo que ha terminado su proceso y traspasa al módulo llamado el control del sistema.

Comunicación de que se ha producido un error en el proceso.

Comunicación de que se puede proceder a una operación concreta.


Flags o controles.

36


Ejemplo

37

FIN DE FICHERO

CONSEGUIR ENTERO VÁLIDO

LEER ENTERO DE FICHERO

VALIDAR ENTERO

ENTERO

ENTERO

ENTERO VÁLIDO

FIN DE FICHERO

EL ENTERO ES VÁLIDO “CONSEGUIR ENTERO VÁLIDO”:

...

LEER_ENTERO( fin_fichero, entero ) ;

...

if VALIDAR_ENTERO( entero ) then ...

...

Jerarquía Iterativa

Cuerpo del Bucle

38

CALCULAR PAGOBRUTO JORNALEROS

CALCULARDEDUCCIONES

NORMALES

CALCULAR PAGOBRUTO EMPLEADOS

IMPRIMIRCHEQUE PAGO

OBTENERREGISTRO PAGO

CALCULAR PAGONETO EMPLEADOS

CALCULAR PAGONETO JORNALEROS

EMISIÓN CHEQUESDE PAGO

JORNADAS TRABAJADAS

RETRIBUCIÓN DIARIA

IRPFIRPF

COMPLEMENTOS

SUELDO BASE

IMPORTE PAGO

NOMBRE EMPLEADO

NÚMERO EMPLEADO

REGISTRO PAGO EMPLEADO

REGISTRO PAGO JORNALEROFIN REGISTROS

PAGO BRUTO EMPLEADO

DEDUCCIONES NORMALES

PAGO BRUTO JORNALERO

PAGO NETO EMPLEADO

PAGO NETO JORNALERO

REGISTRO PAGO

39

program EMISION_CHEQUES ;type

treg_pago : RECORD...END ;treg_jornalero : RECORD...END ;treg_empleado : RECORD...END ;

varimporte : real ;importe_pago_jorn, importe_pago_empl : real ;registro_pago : treg_pago ;registro_empleado : treg_empleado ;registro_jornalero : treg_jornalero ;fin_registros : boolean ;numero_empleado : integer ;nombre_empleado : string ;

beginOBTENER_REGISTRO_PAGO (registro_pago, fin_registros) ;...importe_pago_jorn := CALCULAR_NETO_JORN (registro_jornalero) ;... importe_pago_empl := CALCULAR_NETO_EMPL (registro_empleado) ;...IMPRIMIR_CHEQUE_PAGO( numero_empleado, nombre_empleado, importe) ;...

end.

procedure OBTENER_REG_PAGO ( var rp : treg_pago; var fin_reg : boolean ) ;

function CALCULAR_NETO_JORN ( rj : treg_jornalero ) : real ;

function CALCULAR_NETO_EMPL ( re : treg_empleado ) : real ;

function CALCULAR_BRUTO_JORN ( ret_diaria, jorn_trab : real ) : real ;

function CALCULAR_BRUTO_EMPL ( sueldo_base, complem : real ) : real ;

function CALCULAR_DEDUCCIONES ( pago_bruto, irpf : real ) : real ;

procedure IMPRIMIR_CHEQUE_PAGO( num_emp : integer ; nom_emp : string; importe : real ) ;


Ejemplo II

40

2.2 ESTRATEGIAS DE DISEÑO

41

Pasos generales a seguir para obtener un buen diseño a partir de un DFD de procesos primitivos

A veces hay que refinar el DFD de partida.Dos estrategias:

2.2.1 Análisis de transformaciones.2.2.2 Análisis de transacciones.

Importante: diseñar el DE de forma que: Los módulos de nivel superior toman las decisiones de

ejecución (coordinan). Los de nivel inferior realizan la mayor parte del trabajo de

entrada, de cálculo y de salida.

Diseño Estructurado Estrategias de Diseño.

42

Revisar el modelo fundamental del sistema DFD procesos primitivos

no hace falta “crear” el DFD de procesos primitivos se añaden procesos, si hace falta recomendado, como mínimo, tener 3 niveles de

profundidad

Determinar si el DFD tiene características de transformación o de transacción.indica expresamente la característica del DFD!

Diseño Estructurado Estrategias de Diseño

43

Según sea de transformación o transacción:a) Aislar el centro de la transformación,

especificando los límites del flujo de llegada y de salida...o bien...

b) Identificar el centro de la transacción y las características del flujo de cada camino de acción.indica expresamente los elementos anteriores!


44

1. Realizar el primer corte del diagrama de estructuras.

2. Realizar el segundo nivel de factorización.3. Refinar la estructura del programa.4. Asegurarse del trabajo realizado por el

diseño obtenido.


45

Diseño Estructurado2.2.1 Análisis de Transformación.

47

Diseño Estructurado Análisis de Transformación

Ejemplo

48

Diseño EstructuradoAnálisis de Transformación

Ejemplo

49

Diseño Estructurado Análisis de Transacción

Ejemplo

50

Diseño Estructurado Análisis de Transacción Ejemplo

51

P

Admitir pago

P

Realizar devolución

P

Realizar venta

DPTO. SERVICIO ACLIENTES

datos-pago

datos-devolución

datos-venta

Seleccione la opción deseada:

1. Realizar venta

2. Realizar devolución

3. Admitir pago

...

Diseño EstructuradoAnálisis de Transacción

Ejemplo

clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado diseño estructurado

Documents