clase no. 1 unidad no. iii introduccion al analisis y diseño estructurado diseño estructurado
Post on 23-Jul-2015
1.061 Views
Preview:
TRANSCRIPT
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 disciplinadode 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.
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
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.
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
14
Conceptos fundamentales de diseño estructuradob)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.”
h)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.
DISEÑO ESTRUCTURADO
15
CONT…. Conceptos fundamentales de diseño estructurado: b)Cohesión c)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:
DISEÑO ESTRUCTURADO
16
CONT…. Conceptos fundamentales de diseño estructurado: Tipos de cohesión (orden. De peor a mejor)
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.
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
19
b) Acoplamiento El acoplamiento presenta una gradación que, de menor a mayor, se recoge en los siguientes puntos:
3. Sin acoplamiento directo. 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.
DISEÑO ESTRUCTURADO
20
CONT…. Conceptos fundamentales de diseño estructurado:
e 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.
DISEÑO ESTRUCTURADO
21
CONT…. Conceptos fundamentales de diseño estructurado:
e 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
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
23
Factores que influencian el AcoplamientoLos cuatro factores principales que influyen en el acoplamiento entre
módulos son: 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.)
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.
DISEÑO ESTRUCTURADO
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.
DISEÑO ESTRUCTURADO
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
Diseño Estructurado Diagrama de estructura
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.
Diseño EstructuradoDiagrama de estructura
Flags o controles.
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 ) ;
Diseño Estructurado Diagrama de estructura
Ejemplo II
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!
Diseño Estructurado Estrategias de Diseño
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.
Diseño Estructurado Estrategias de Diseño
top related