capitulo04

Fundamentos de

Ingeniera del Software

Captulo 4. Diseo

Hay dos formas de realizar un diseo: una es hacerlo tan simple que obviamente no haya deficiencias; la otra es hacerlo tan complicado que no haya deficiencias complicado que no haya deficiencias obvias

C.A.R. Hoare

Diseo. Estructura

1. El proceso de diseo.2. Modelos de diseo.3. Diseo estructurado.

Diagramas de estructura. Diagramas de estructura. Estrategias de diseo:

Anlisis de transformaciones. Anlisis de transacciones.

4. Mtricas de calidad estructural. Acoplamiento. Cohesin.

5. Heursticas de diseo estructural.

Diseo. Bibliografa

(Piattini et al. 96) (Piattini et al. 04) Captulo 8. Apartado 8.1. (Molina et al. 97) A. Molina, P. Letelier, P.Snchez, J. Snchez.

Metodologa y Tecnologa de la Programacin. Servicio de Publicaciones. UPV. 1997.

(Pressman 06) Captulo 9 (resumido) y aptdo. 10.6. (Pressman 06) Captulo 9 (resumido) y aptdo. 10.6.

(Pressman 02) Captulo 13 y aptdos. 14.5 a 14.8.

(MAP 95) Ministerio de Administraciones Pblicas. Gua de Tcnicas de Mtrica v.2.1. 1995.

(MAP 01) Gua de tcnicas y prcticas de Mtrica v.3. http://www.csi.map.es/

(Page-Jones 88) M. Page-Jones. The Practical Guide to Structured Systems Design. Yourdon Press. 1988.

1. El proceso de diseo

El proceso de aplicar distintas tcnicas y principios con el propsito de definir un dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realizacin fsica.suficiente detalle como para permitir su realizacin fsica.

Proceso iterativo a travs del cual se traducen los requisitos en una representacin del software.

La calidad slo se puede conseguir a travs de un proceso de diseo.

E-R

ERS

DFD

Anlisis (Qu)Lenguaje comprensible por el usuario

Diseo de alto nivel (arquitectnico)

Organizacin lgicaEnfoque de

datos

Enfoque funcional

El proceso de diseo (II)

Modelo lgico de datos

Modelo fsico de datos

Arquitectura de procesos

Estructura detallada: programas y mdulos

Esquema de BD y ficheros

Cuadernos de carga

Codificacin y pruebas

Diseo de bajo nivel (detallado)

Diseo (Cmo)

Decisiones concretas: organizacin y rendimiento

ImplementacinLenguaje comprensible por la mquina(Piattini et al. 04)

datos

El proceso de diseo (III)

Cada modelo se asienta en el anterior:Diseo de datos. Transforma el modelo del dominio de la informacin del anlisis en las estructuras de datos necesarias para la implementacin.

Diseo arquitectnico. Diseo arquitectnico. Estructura modular del programa/aplicacin.

Diseo de interfaz. Interfaces del sw. con otros sistemas y con los usuarios.

Diseo procedimental. Descripcin procedimental de los componentes del sw.

2. Modelos de diseo (Yourdon 93)MODELO ESENCIAL

(LGICO)

Se le asignan algunos procesos

En la ltima etapa del anlisis se ha establecido el lmite de automatizacin del

Anlisis

Comunicacin entre tareas (a travs del S.O.)

Se le asignan algunos almacenes

MODELO DE PROGRAMA

MAINFRAME

CPU REMOTA

TAREA 1 TAREA 2 TAREA 3

Mdulo A

Mdulo B Mdulo C Mdulo D

MODELO DE PROCESADORES

MODELO DE TAREAS

Lnea de telecomunicaciones

procesos lgicos

de automatizacin del sistema

Diseo

Asignacin de procesos y

almacenes a procesadores (Yourdon 93)

Asignado al procesador 1

Asignado al procesador 2

Ntese cmo este almacn podr estar replicado en cada procesador

3. Diseo estructurado

Objetivos: Desarrollar la estructura modular del programaDefinir las relaciones entre mdulos

Tcnica ppal.: Diagrama de Estructura Pseudocdigo Pseudocdigo rboles de decisin

Documentacin de partida: DFDs Estrategias de diseo:

Anlisis de transformaciones Anlisis de transacciones

Diseo estructurado

Se dispone de:Las entradas que suministran al sistema las entidades externas.

Las salidas aportadas por el sistema a dichas entidades externas.

Las funciones descompuestas que se han de realizar en ese sistema.

El esquema lgico de datos del sistema.

Diseo estructurado (II)

Tareas a realizar:Determinar qu mdulos implantarn los procesos terminales (primitivos) obtenidos en el anlisis.

Organizar la estructura de estos mdulos y definir las conexiones entre los mismos.

Organizar la estructura de estos mdulos y definir las conexiones entre los mismos.

Describir el pseudocdigo para cada mdulo. Se basa en:

abstraccin modularidad encapsulamiento y ocultamiento de informacin

Aade un nivel de abstraccin a la programacin estructurada.

Diagrama de estructura (Diagrama de estructura de cuadros de Constantine)

Diseo arquitectnico del sistema: diagrama de mdulos funcionalesIdentifica qu mdulos se necesitan, as como sus inputs/outputs (caja negra)sus inputs/outputs (caja negra)

Refleja la comunicacin de datos y control y la jerarqua entre mdulos

Diagrama de estructura:MdulosConexionesComunicaciones

Diagrama de estructura.

Mdulo

Aquella parte de cdigo que se puede llamar (Page-Jones 88).

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

El diseo estructurado NO impone la restriccin de que un mdulo tenga que ser compilado independientemente.

Admite parmetros de llamada y retorna algn valor, si es preciso.

Tamao ideal: 40-50 lneas pero hay muchas opiniones!

Se representa en el diagrama mediante un rectngulo.

DE. Representacin de

mdulos

OBTENER DATOS

CLIENTES

MDULO

MDULO

Mdulo normal.

IMPRIMIR CHEQUE DE

PAGO

MDULO PREDEFINIDO

1

CONECTOR

Un mdulo predefinido est disponible en la biblioteca del sistema o de la propia aplicacin (a veces, puede ser tambin un mdulo de un sistema operativo o de un SGBD), y por tanto, no es necesario codificarlo.

Para no perder la referencia, el diagrama de estructura debe dibujarse en una hoja tamao A4. Si no cabe (bien), se deben explosionar los elementos (como en System Architect) o poner conectores.

DE. Representacin de

mdulos (II)

En la notacin de Mtrica tpica tambin se dispone de:

Almacenes de datosAlmacenes de datos

Dispositivos fsicos

NOMBRE

DISPOSITIVO

mdulos que representan dnde van a estar fsicamente los datos (tablas, ficheros)

dispositivos (de cualquier tipo) por donde se puede recibir o enviar informacin que necesite el sistema.


Conexin entre mdulos

La conexin entre mdulos se representa mediante una lnea.

En la figura: A llama a B. B hace su funcin. B retorna a A, inmediatamente

despus del lugar donde se CONEXIN

MDULO QUE LLAMAA

B retorna a A, inmediatamente despus del lugar donde se produjo la llamada de A a B.

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

El diagrama no dice cuntas veces puede A invocar a B. Slo se dice que A es capaz de invocar a B. Tal vez no realice ninguna invocacin.

CONEXIN

MDULO LLAMADOB

Tampoco muestra detalles internos de los mdulos como cdigo, algoritmos o datos.


Conexin entre mdulos (II)

AEstructura repetitiva

Estructura alternativa

CB

Orden de ejecucin de los mdulos: de izquierda a derecha y de arriba abajo (Piattini et al. 04)

Segn (Molina et al. 97) el orden no importa:El diagrama de estructura no representa aspectos procedurales del

sistema como las secuencias, alternativas o bucles


Conexin entre mdulos (III)

Men login

Ejemplo tpico de aplicacin interactiva: un conjunto de opciones de men que se escogen

cclicamente por el usuario

Procesos para departamentos

Procesos para agentes externos

Procesos Generales


Comunicacin entre mdulos

Los signos para llevar a cabo la comunicacin entre mdulos son:

Obtener datos clientes

EORcampo alfabtico correcto

mdulos son:

Flags o controles

DatosValidar campo

alfabticoObtener campo

siguiente

campo

campo correcto

EOR

campo

Flags o controles

Mediante los flags o controles, se puede representar: Paso de control entre mdulos: un mdulo comunica a otro mdulo que ha terminado su proceso y a otro mdulo que ha terminado su proceso y traspasa al mdulo llamado el control del sistema.

Comunicacin de que se ha producido un error en el proceso.

Comunicacin de que se puede proceder a una operacin concreta.

Diferencias entre datos y flags

Los datos se procesan.

Los datos son la informacin compartida por los mdulos.

La posicin de la flecha (hacia arriba o hacia abajo) indica el sentido de la comunicacin.

Los controles slo sirven para comunicar condiciones entre los mdulos.

Los controles indican al mdulo que llama la terminacin EOF, o un error del mdulo llamado, y deben ir siempre en sentido ascendente.

En sentido descendente dan lugar a sentido de la comunicacin. Los datos tienen importancia

para el mundo exterior, estn relacionados con el problema.

En sentido descendente dan lugar a un acoplamiento de control no deseable y la cohesin se ve comprometida.

Se pretende que los mdulos de arriba coordinen, los de abajo realicen el trabajo especfico y sealen condiciones anormales o de terminacin.

Los flags tienen importancia en la comunicacin de informacin en el interior; son los que sincronizan la operativa de los mdulos.

Los flags no se suelen mostrar en los diagramas (Piattini et al. 04)

Representacin de

parmetros

Se pueden representar mediante tablas de interfaz (Piattini et al. 04)

Mdulo Parmetro formal

Entrada Salida Uso Significado

F(x,y) x S No P Fecha nacimientoF(x,y) x S No P Fecha nacimiento

y No S M Edad

...donde Uso es denotado por:P Procesado: a = b + 2M Modificado: a = 3 + b T Transferido por el mdulo llamado a otro mdulo que ste llama, sin modificar su valor

C Es usado como una variable de ControlI El parmetro es transferido a otro mdulo y es modificado en este segundo mdulo


Ejemplo (Piattini et al. 96)


Ejemplo (II) (Molina et al. 97)

CONSEGUIR ENTERO VLIDO

ENTERO

ENTERO VLIDO FIN DE FICHERO

EL ENTERO ES VLIDO CONSEGUIR ENTERO VLIDO:

FIN DE FICHERO

LEER ENTERO DE FICHERO

VALIDAR ENTERO

ENTERO

ES VLIDO CONSEGUIR ENTERO VLIDO:...

LEER_ENTERO( fin_fichero, entero ) ;...

if VALIDAR_ENTERO( entero ) then ...

...


Ejemplo (III) (Molina et al. 97)

EMISIN CHEQUESDE PAGO

IMPORTE PAGO

NOMBRE EMPLEADO

NMERO EMPLEADO

REGISTRO PAGO JORNALEROFIN REGISTROSPAGO NETO EMPLEADO

PAGO NETO JORNALEROREGISTRO PAGO

CALCULAR PAGOBRUTO JORNALEROS

CALCULARDEDUCCIONES

NORMALES

CALCULAR PAGOBRUTO EMPLEADOS

IMPRIMIRCHEQUE PAGO

OBTENERREGISTRO PAGO

CALCULAR PAGONETO EMPLEADOS

CALCULAR PAGONETO JORNALEROS

JORNADAS TRABAJADAS

RETRIBUCIN DIARIA

IRPFIRPF

COMPLEMENTOS

SUELDO BASE

REGISTRO PAGO EMPLEADO

PAGO BRUTO EMPLEADO

DEDUCCIONES NORMALES

PAGO BRUTO JORNALERO


Ejemplo (III) (Molina et al. 97)

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 ;

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 ) ;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.

importe : real ) ;

Mtodos para la

especificacin de mdulos

Interfaz-funcin (mdulo, entradas, salidas, funcin).

Pseudo-cdigo. Ms preciso que el usado en anlisis Ms preciso que el usado en anlisis Deja cierto grado de libertad al programador No trata aspectos de eficiencia, a menos que estn directamente relacionados con requisitos

Permite verificar la calidad del diseo

Herramientas complementarias: Diagramas de flujo Nassi-Schneiderman Tablas y rboles de decisin

Estrategias de diseo

Pasos generales a seguir para obtener un buen diseo a partir de un DFD de procesos primitivos

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

Anlisis de transformaciones Anlisis de transacciones

Importante: disear el DE de forma que: Los mdulos de nivel superior toman las decisiones de ejecucin (coordinan)

Los de nivel inferior realizan la mayor parte del trabajo de entrada, de clculo y de salida

Estrategias de diseo.

Pasos a seguir

Revisar el modelo fundamental del sistema DFD procesos primitivos no hace falta crear el DFD de procesos no hace falta crear el DFD de procesos primitivos se aaden procesos, si hace falta recomendado, como mnimo, tener 3 niveles de profundidad

Determinar si el DFD tiene caractersticas de transformacin o de transaccinindica expresamente la caracterstica del DFD!


Pasos a seguir (II)

Segn sea de transformacin o transaccin:a) Aislar el centro de la transformacin,

especificando los lmites del flujo de llegada especificando los lmites del flujo de llegada y de salida...o bien...

b) Identificar el centro de la transaccin y las caractersticas del flujo de cada camino de accin.

Consejo: indica expresamente los elementos anteriores!


Pasos a seguir (III)

Realizar el primer corte del diagrama de estructuras.

Realizar el segundo nivel de factorizacin.Realizar el segundo nivel de factorizacin.Refinar la estructura del programa.Asegurarse del trabajo realizado por el diseo obtenido.

Anlisis de transformacin(Piattini et al. 04)

Anlisis de transformacin.

Primer corte del DE (Piattini et al. 04)

Anlisis de transformacin. Segundo nivel de factorizacin

Finalmente, es preciso optimizar!(Piattini et al. 04)

Anlisis de transaccin(Piattini et al. 04)

Son transacciones (caminos) independientes.

Anlisis de transaccin. Primer nivel de factorizacin

(Piattini et al. 04)

Anlisis de transaccin. Segundo nivel de factorizacin

Finalmente, es preciso optimizar!(Piattini et al. 04)


Ejemplo (Gua de tcnicas de Mtrica 2.1, MAP 95, p.144)


Ejemplo (II) (MAP 95)

Un planteamiento para discutir:

Anlisis de transacciones.

Ejemplo (Gua de tcnicas de Mtrica 2.1, p.148)

Anlisis de transacciones.

Ejemplo (II) (MAP 95)

de cara a la reutilizacin, es bueno que Actualizar archivo R (S, T) haga uso de imprimir modificaciones?

Un planteamiento para discutir:

Centros de transaccin

implcitos

Normalmente el esquema de transaccin no es tan claro:

el proceso de transaccin no aparece el proceso de transaccin no aparece explcitamente en el DFD

Solucin: examinar el diagrama de contexto y la lista de eventos para

determinar los tipos de transacciones en el sistema

Centros de transaccin

implcitos (II)

PRealizar devolucin

PRealizar venta

DPTO. SERVICIO ACLIENTES

datos-devolucin

datos-venta (Molina et al. 97) p.172

...

PAdmitir pagodatos-pago

Seleccione la opcin deseada:Seleccione la opcin deseada:

1.1. Realizar ventaRealizar venta

2.2. Realizar devolucinRealizar devolucin

3.3. Admitir pagoAdmitir pago

Estrategia de diseo.

Pasos a seguir (IV) (Molina et al. 97) p.169

Anlisis de transacciones Encontrar las transacciones en el DFD

Anlisis de transformacionesDE para cada transaccin DE para cada transaccin

Anlisis de transacciones Componer los DE en uno solo, usando un

centro de transacciones DE para un men

4. Mtricas de calidad

estructural

Mayor calidad estructural mantenimiento ms fcil

Extensibilidad ++Extensibilidad ++Reutilizacin ++

Dos mtricas:AcoplamientoCohesin

Acoplamiento

Grado de interdependencia entre mdulos.

Depende de la forma de interactuar entre los mdulos: p.ej. n / tipo de parmetros que se intercambian.p.ej. n / tipo de parmetros que se intercambian.

Objetivo: minimizar el acoplamiento (CAJA NEGRA).modificabilidad++, comprensin++, reutilizacin++

Ventajas de un bajo acoplamiento: Menos oportunidades para el efecto onda. El cambio realizado en un mdulo afecta lo menos posible a otros mdulos.

Mientras se est manteniendo un mdulo, es deseable no necesitar preocuparse de los detalles internos de cualquier otro mdulo.

Complejidad de la interfaz

Acoplamiento Complejidad de la interfazP.ej. (Molina et al. 97) 1. CALL LONGITUD( X1, Y1, X2, Y2, D ) 1. CALL LONGITUD( X1, Y1, X2, Y2, D ) 2. CALL LONGITUD( ORIGEN, DESTINO, D ) 3. CALL LONGITUD( PuntosX, PuntosY, D ) 4. CALL LONGITUD( LINEA, D ) 5. CALL LONGITUD( TABLALINEA ) 6. CALL LONGITUD.

Qu interfaz es ms fcil de entender?

Complejidad de la interfaz

(II)

Depende de:Cantidad de informacin que debe comprenderse (como n parmetros)

Accesibilidad a esa informacin Indireccin complejidad++ Informacin local complejidad-- Informacin en forma estndar complejidad-- Si el parmetro intenta controlar la lgica del mdulo que lo recibe complejidad++

Niveles de acoplamientoStevens, Myers y Constantine 74

Acoplamiento NormalDe datos Por estampadoDe control

MEJOR (- Acopl.)

Lmite de De control

Acoplamiento comn Acoplamiento por contenido

PEOR (+ Acopl.)

Lmite de aceptacin

Si dos mdulos presentan varios tipos de acoplamiento, se considera que tienen el peor de los acoplamientos que presentan.

Niveles de acoplamiento (II)

Acoplamiento normal:A y B normalmente acoplados si:

1) A llama a B; 2) B retorna el control a A

De datos:De datos: se establece una comunicacin bsica por medio de elementos de datos

De estampado: se pasan datos con estructura de registro

De control: se comunican con flags de control

Acoplamiento normal de

datos

No genera problemas. Es el acoplamiento deseable en diseo estructurado

Slo debe haber parmetros

Obtener DNI Cliente

Slo debe haber parmetros con sentido

En la medida de lo posible, minimizar el nmero de parmetros

Leer DNI Cliente

DNI cli

Acoplamiento normal por

estampado

Introduce indireccin No es deseable si el mdulo que recibe el registro slo necesita parte de los datos.

Obtener DNI Cliente

parte de los datos. Pasar campos innecesarios oscurece el diseo y reduce la flexibilidad

No crear registros artificiales, empaquetando datos no relacionados

Leer Cliente

cli


control

Deseable slo si los flags de control son descriptivos

EORcampo alfabtico correcto

Validar campoalfabtico

Obtener camposiguiente

Obtener datos clientes

campo

campo correcto

EOR

campo


control (II)

No es deseable si el control tiene sentido descendente:Un mdulo controla a otro y no son realmente independientes

Obtener trans y registro

reg maestroreg transFlag de seleccindependientes El mdulo subordinado tiene poca cohesin

Solucin: sustituir el mdulo subordinado por tantos mdulos como sea necesario, de forma que slo intercambien datos

Control sist E/S

reg maestroreg trans

Flag de selecc:Flag de selecc:

1.1. Obtiene RTObtiene RT

2.2. Obtiene RMObtiene RM

3.3. Obtiene RT y RMObtiene RT y RM


control (III)

Peor es si hay inversin de autoridad (Molina et al. 97) p.66

el mdulo subordinado intenta controlar al mdulo padre

Encontrar palabras

Formar palabras

otro regreg

...

Niveles de acoplamiento (III)

Acoplamiento comn. Ms de dos mdulos hacen referencia a un rea comn de datos. Dos mdulos pueden estar acoplados globalmente y no estar conectados mediante una llamada.

En general, es desaconsejable, dado que (Molina et al. 97): En general, es desaconsejable, dado que (Molina et al. 97): Un error de programacin en un mdulo que usa puede aparecer en otros mdulos que compartan esa misma rea global.

Reutilizacin-- Puede ser difcil averiguar de dnde procede informacin depositada en el rea global.

Se pueden incluso usar para depositar informacin de distinta naturaleza.

Aplicaciones difciles de mantener: es difcil saber qu datos son usados por un mdulo.

Niveles de acoplamiento (IV)

Acoplamiento de contenido. Ocurre cuando un mdulo necesita o accede a una parte de otro, rompiendo la jerarqua de funcionalidad de la estructura.

En la mayora de los casos slo se puede dar en En la mayora de los casos slo se puede dar en ensamblador

Hay que evitarlo descomponiendo el mdulo al que se accede o duplicando esa parte de cdigo en el mdulo que llama

A

B

Datos vagabundos (Molina et al. 97) p.62

Deben evitarse tambin los datos vagabundos(que a veces estn asociados al acoplamiento normal)

Posibles soluciones:a) Reorganizar el

diagramab) Introducir variables

globales

Datos vagabundos (II)

Solucin (a) El dato vagabundo registro maestro se ha maestro se ha eliminado reorganizando el DE

Cohesin

Medida de la relacin funcional entre los elementos de un mdulo.

Un mdulo coherente slo debe hacer una cosa. Un mdulo coherente ejecuta una tarea bien definida en Un mdulo coherente ejecuta una tarea bien definida en un programa y requiere poca interaccin con otros procedimientos que se ejecutan en otras partes del programa.

Objetivo: mdulos con alta cohesin. La escala de cohesin no es lineal:

una cohesin baja es mucho peor que una de grado medio,

una de grado medio es casi tan buena como una alta.

Cohesin y acoplamiento

Son criterios inversamente relacionados: (Molina et al. 97)

AULAS APARCAMIENTO

COCINAS COMEDOR

AULASCOCINAS

APARCAMIENTOCOMEDOR

Niveles de cohesinStevens, Myers y Constantine 74

Funcional Secuencial Comunicacional

Mayor cohesin (CAJA NEGRA)

Procedural Temporal Lgica Coincidental Peor cohesin

(CAJA GRIS)

(CAJA TRANSPA-RENTE)

Lmite de aceptacin

Niveles de cohesin (II)

Funcional: se realiza una sola funcin. Secuencial: la salida de una tarea sirve como entrada a la siguiente:

varios mdulos con cohesin funcional que se pasan un dato

Comunicacional: actividades que comparten datos (bien los Comunicacional: actividades que comparten datos (bien los mismos datos de entrada o de salida).

Procedural: actividades diferentes, en las cuales el flujo de ejecucin fluye de una a la siguiente.

Temporal: actividades diferentes relacionadas por el tiempo. Lgica: actividades con la misma categora lgica general, que se

seleccionan fuera del mdulo.

Coincidental o casual: actividades diferentes sin relaciones significativas entre ellas.

Niveles de cohesin (III)

Ejemplos:Funcional:

funciones matemticas como cos(alpha); escribir registro (fichero, registro)

Secuencial: Formatear registro = Leer registro + Aplicar formato registro

Comunicacional: Comunicacional: Obtener detalles cliente (num_cta, nombre_cli, saldo_prestamo)

Procedural:Mdulo Detectar error, corregirlo y reanudar la ejecucin

Por qu no es cohesin secuencial?Temporal:

mdulos de inicializacin y terminacinLgica:

rutina general de E/S

ms ejemplos en (Piattini et al. 04) o (Molina et al. 97) p.78.

Determinacin de la

cohesin de un mdulo (Molina et al. 97)

Realiza el mdulo una sola funcin?

Cmo estn relacionadas las

Es importante la secuencia?

1. FUNCIONAL.

2. SECUENCIAL.

3. COMUNICACIONAL

S

S

NO

NO POR DATOS

POR FLUJO DE relacionadas las actividades dentro

del mdulo? Es importante la secuencia?

Son las actividades de la misma categora

general?

4. PROCEDURAL.

5. TEMPORAL.

6. LGICA.

7. CASUAL.

S

S

NO

NO

POR FLUJO DE CONTROL

NINGUNA DE LAS DOS

5. Heursticas de diseo

estructural

IMPORTANTE: Los mdulos superiores deben coordinar, y los inferiores realizar las tareas.

Reducir el n de parmetros que intercambian los mdulos tanto como sea posible.

Nunca pasar registros que contengan muchos campos Nunca pasar registros que contengan muchos campos cuando en realidad el mdulo slo necesita algunos.

No agrupar parmetros sin relacin en un registro. Evitar que un mdulo hijo d rdenes al padre. En la medida de lo posible, no usar variables globales. Se puede parar la descomposicin cuando la interfaz con un mdulo sea tan complicada como el mdulo mismo.

Heursticas de diseo

estructural

Debe evitarse la situacin en que un mdulo llama a muchos otros (puede ser difcil de entender).Normalmente sucede cuando no se tiene en cuenta los niveles intermedios

Solucin: combinar funciones subordinadas en una sola Solucin: combinar funciones subordinadas en una solaExcepcin: cuando el mdulo es un centro de transacciones

Deben evitarse largas secuencias lineales. Soluciones:(a) revisar las posibilidades de descomponer las funciones en subfunciones con entidad propia.(b) comprimir mdulos subordinados en un mdulo de nivel superior.

Heursticas de diseo

estructural (Molina et al. 97) cap. 6

Factorizar funciones cuando sea posible. Inicializar las variables lo ms tarde posible en el diagrama, cerca de las funciones a realizar.

Evitar la disgregacin de decisiones: Evitar la disgregacin de decisiones:

La parte de reconocimiento de la condicin se separa de la parte de ejecucin

Cul puede ser un sntoma?

Heursticas de diseo

estructural (II) (Molina et al. 97) cap. 6

Evitar sistemas dirigidos por la entrada fsica (sistemas que no procesan suficientemente la entrada).

LgicoLo deseable es:

FSICO

LGICO ...

Heursticas de diseo

estructural (III) (Molina et al. 97) cap. 6

Ejemplo de sistema dirigido por la entrada fsica

El acoplamiento suele ser alto.

Ya que los mdulos Ya que los mdulos superiores en la jerarqua tratan con la entrada fsica, cualquier cambio en la especificacin de sta afectar a gran parte del sistema.

Heursticas de diseo

estructural (IV) (Molina et al. 97) cap. 6

Edicin de los datos de entradaValidar sintaxis antes que semnticaValidar lo sencillo antes que lo cruzadoValidar lo sencillo antes que lo cruzadoEjemplo: nombre-ciudad y cod-postalValidar: 1 sintaxisnombre-ciudad caracteres alfabticoscod-postal numrico

2 Verificar que ambos datos existen3 Validacin cruzada: cod-postal nombre-ciudad

Heursticas de diseo

estructural (V) (Molina et al. 97) cap. 6

Informacin de los errores: Qu mdulo llama al mdulo que escribe

Dos soluciones no vlidas:

que escribe mensajes de error?

Heursticas de diseo

estructural (VI) (Molina et al. 97) cap. 6

Dnde se pone el texto de los mensajes de error?Diseminados por el

Solucin vlida:

Diseminados por el sistema

Dentro de un nico mdulo

capitulo04

Documents