|
3.1 Dise¤o estructurado
3.1.1 Objetivo :
Esta t‚cnica tiene consigo los siguientes objetivos :
* Obtener la estructura modular y los detalles de procesos
del sistema partiendo solamente de los "productos" obteni-
dos de la fase de An lisis de Sistemas.
* Cambiar la atenci¢n del QUE al COMO.
* Obtener un dise¤o que no s¢lo "funcione" sino que tambien
sea mantenible, mejore la reutilizaci¢n y se pueda probar
y entender facilmente.
* Utilizar herramientas gr ficas (Diagrama de estructura de
cuadros) para representar la estructura modular del sistema.
Se trata por tanto de conseguir que cada m¢dulo de la
estructura en rbol que se obtenga cumpla las siguientes
caracter¡sticas :
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 dete-
rminada modificaci¢n afectar a un n£mero mayor de m¢dulos,
sin embargo la cantidad de c¢digo a considerar ser menor.
Independencia modular.
Cuando mayor es la independencia de un m¢dulo es m s senci-
llo 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¡stica de caja negra.
La caracter¡stica de caja negra se aplica a cualquier
sistema, programa o m¢dulo para dar visi¢n exclusiva de sus
entradas y salidas, sin tener en cuenta los detalles de
c¢mo se realiza el proceso.
Modelizaci¢n conceptual.
Un sistema sera m s f cil de mantener si el modelo utili-
zado en su dise¤o se ha basado en los conceptos l¢gicos de
la organizaci¢n, los cuales ser n m s familiares y compren-
sibles para el personal de mantenimiento que las descripci-
ones f¡sicas.
3.1.2 Utilidad
Esta t‚cnica nos permitir desarrollar un MODELO de un
sistema computarizado para solucionar un problema, que
tienen los mismos componentes, y las mismas interrelaciones
entre ellos, como el problema original.
Para construir este m¢dulo necesitamos:
UNA HERRAMIENTA PARA MODELAR
Para ayudarnos a planear y dise¤ar nuestro sistema, esta
herramienta tiene las siguientes caracter¡sticas :
* Gr fica.
* Uso de Top-Down.
* Rigurosa.
* Capaz de predecir el comportamiento del sistema.
* Una salida natural del an lisis.
* Una entrada natural a la implantaci¢n.
* Documentaci¢n del sistema
* Una ayuda para el mantenimiento.
UNA MANERA DE CONTROLAR LA COMPLEJIDAD
De sistemas no triviales.
3.1.3 Descripci¢n
El paso de la fase de An lisis del Sistema al Dise¤o ser
m s f cil si se ha llegado a un nivel de detalle muy bajo
en los diagramas de flujo de datos.
Una vez finalizada la fase de An lisis del Sistema, se
dispondr a iniciar la Fase de Dise¤o, de un conjunto de
especificaciones que describan, con t‚rminos precisos:
* Las entradas que suministran al sistema.
* Las salidas aportadas por el sistema a dichas entidades
externas.
* Las funciones descompuestas que se han de realizar por
ese sistema.
* El modelo de datos l¢gico del sistema.
Toda esta informaci¢n estar almacenada en el diccionario
del proyecto mediante la descripci¢n de diagramas de
flujo de datos, procesos, flujo de datos, diagrama de
estructura de datos, entidades y atributos.
Para pasar a construir el nuevo sistema es necesario
convertir toda esta informaci¢n en especificaciones de
programas.
Las tareas a realizar son:
* Determinar qu‚ m¢dulos implantar n los procesos termin-
ales obtenidos en la Fase de An lisis del Sistema.
* Organizar la estructura de estos m¢dulos y definir las
conexiones entre los mismos.
* Describir el pseudoc¢digo para cada m¢dulo.
Para ello se seguir el m‚todo propuesto por CONSTANTINE:
El Diagrama de Estructura de Cuadros, que permite definir
cu ndo bajo que condiciones y cuantas veces se tienen que
realizar los tratamientos identificados en los Procesos.
Los datos se contemplan como la interfases entre tratami-
entos sucesivos.
Por lo tanto, la Estructura Constantine nos da una visi¢n
de arquitectura del sistema. con la cual, se trata de no
tener ninguna restricci¢n en cuanto al n£mero de objetos,
siempre y cuando el dibujo pueda realizarse en una hoja,
para no perder la referencia, y en cualquier caso poder
explosionar aquella funci¢n que se descomponga..
El dise¤o f¡sico que debe de elaborar un dise¤ador debe
ser el ¢ptimo, por lo tanto, debemos de considerar los
siguientes aspetos para optimizar el dise¤o.
a) Principios del dise¤o estructurado.
b) Estrategias de dise¤o.
c) Evaluaci¢n y refinamiento del dise¤o.
d) Heur¡stica del Dise¤o.
e) Definici¢n de los Programas.
Se describir n en detalle cada aspecto, logrando un
mayor entendimiento de los mismos:
a) Principios del dise¤o estructurado.
Los principios de dise¤o estructurado que debemos de cons-
iderar son los siguientes:
* Descomposici¢n.
* Jerarqu¡a.
* Independencia.
Estos principios se describir n a continuaci¢n :
* Descomposici¢n :
Es la separaci¢n de una funci¢n en otras que estuvieran
contenidas en la primera.
La descomposici¢n con sigue los siguientes objetivos :
* Reducir el tama¤o del m¢dulo.
* Hacer el sistema m s f cil de entender y modificar.
En el dise¤o ®top-down¯, de arriba a bajo permite
descomponer paso a paso, seg£n se vaya observando que
los m¢dulos realizan m£ltiples funciones, acerc ndonos
cada vez m s a la soluci¢n ¢ptima.
A continuaci¢n veremos un ejemplo donde se emplea la
t‚cnica top-down; donde descompondremos la funci¢n:
obtener el sueldo del trabajador por horas que se
muestra en la Figura N§ 6: Funci¢n: Emitir Cheques a
empleados; a su vez, el resultado de este ejemplo se
muestra en la Figura N§ 7: Descomposici¢n de la funci¢n:
obtener el sueldo del trabajador por horas.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ÚÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ EMITIR ³ º
º þ ÚÄÄÄÄÄÄÄÄÄÄÄ´ CHEQUES ÃÄÄÄÄÄÄÄÄÄÄÄ¿ º
º Final de fichero ³ ³ ³ EMPLE DOS ³ ³ Nombre º
º ³ ³ ÀÄÄÄÄÂÄÂÄÄÄÄÙ ³ ³ Empleado º
º ³ ³ ÚÙ À¿ ³ ³ º
º þ ³ ÚÙ À¿ ³ þ º
º ³ ÚÄÄÄÄÄÄÄÄÄÙ ÚÙ À¿ ÀÄÄÄÄÄÄÄÄÄÄ¿ º
ºegistro ³ ³ ÚÙ þ À¿ ³ ³ Numero º
ºago empleado³ ³ ÚÙ ³ ³ À¿ Pago ³ ³ ³ empleado º
º ³ ÚÙ ³ ³ À¿ Empleado ³ ³ ³ º
º ³ þ ÚÙ þ À¿ þ ³ þ º
º ÚÄÄÄÄÄÄÄÙ Pago ³ ÚÙ À¿ ÀÄÄÄÄÄÄ¿ º
º ³ Neto ³ ÚÙ Registro Pago À¿ ³ º
º ³ Horas ³ ÚÙ Pago Sueldo À¿ Registro ³ º
º ³ ÚÙ Horas Neto À¿ ³ Pago de saldo ³ º
º ³ ÚÙ À¿ ³ ³ º
º ³ ÚÙ À¿ þ ³ º
º ³ ÚÙ À¿ ³ º
º ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÄÁÄ¿ º
º ³OBTENER ³ ³OBTENER NETO³ ³CALCULAR NETO³ ³IMPRIMIR³ º
º ³REG. PAGO³ ³ TRABAJADOR ³ ³ TRABAJADOR ³ ³ CHEQUE ³ º
º ³EMPLEADOS³ ³ PRO HORAS ³ ³ CONTRATO ³ ³ PAGO ³ º
º ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 6: Funci¢n: Emitir Cheques a empleados
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ³ º
º ÚÄÄÄÄÄÄÄÄÄÄÄ¿ ³ º
º ÚÄÄÄÄ´ EMITIR ÃÄÄÄÄÄ¿ þ Nombre º
º ³ ³ CHEQUE DE ³ ³ Empleado º
º ÚÄÄÄÄÄÙ ³ EMPLEADOS ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º Registro Pago þ ³ ÀÄÄÄÂÄÄÄÄÄÄÄ´ ³ ³ º
º Empleado ³ ³ ³ ³ ³ Reg. ³ ³ º
º ³ ³ ³ ³ þ Pago ³ ³ Numero º
º ³ þ ³ ³ Empleado ³ þ empleado º
º ³ ³ ³ ÀÄÄÄÄÄÄÄ¿ ³ º
º ÚÄÄÄÄÄÄÄÄÄÙ ³ þ ÚÄÙ þ ³ ÀÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ Pago ³ ³ Registro ³ ³ ³ º
º ³ Neto ³ ³ Pago ³ ³ Pago ³ º
º ³ horas ³ Horas ÀÄÄÄÄÄÄ¿ Empleado ³ ³ º
º ÚÄÄÄÄÄÄÙ ÚÄÙ ³ ³ ÀÄÄ¿ º
º ³ ³ ³ ³ þ ÀÄÄ¿ º
º ³ ³ ³ ³ ³ º
º ÚÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÁÄÄ¿ þ ÚÄÄÄÄÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÁ¿ º
º ³OBTENER ³ ³CALCULAR NETO³ ³CALCULAR NETO³ ³SUPRIMIR³ º
º ³REG. PAGO³ ³ TRABAJADOR ³ ³ TRABAJADOR ³ ³ CHEQUE ³ º
º ³EMPLEADOS³ ³ POR HORAS ³ ³ CONTRATO ³ ³ PAGO ³ º
º ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÂÄÄÄÄÄÄÄÄÂÄÙ ÀÄÄÄÄÄÄÂÄÂÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ º
º Tarifa ³ ³ Reducciones ³ ³ º
º por ³ ³ þ Normales ³ ³ º
º moras ÚÄÙ ÀÄÄ¿ ³ ³ ÚÄÄÄÙ ÀÄÄÄÄÄ¿ º
º ³ Retenci¢n ³ ³ Pago þ ³ ³ º
º Horas ³ Impuestos ³ Bruto ³ ³ ³ Pago º
º Trabajadas ÚÄÄÄÙ ³ ÀÄ¿ ContratoÚÄÄÙ þ ÀÄÄ¿ º
º ³ þ ³ ³ ³ þ Tarifa ³ þ º
º ³ ³ Pago þ ³ Retenc. ³ ³ Normal ³ ³ Pago º
º ³ ³ ³ Bruto Pago ³ imp. ³ ³ ³ ³ Bruto por º
º ³ ³ Por Bruto ³ ³ Deducciones ³ ³ Contrato º
º þ ³ Horas Por ³ ³ ³ Normales þ ³ º
º ÚÄÄÄÄÄÙ Moras þ ÀÄÄÄÄ¿ ÚÄÄÄÄÙ ÀÄÄÄÄ¿ º
º ³ ³ ³ ³ º
º ³ ³ ³ ³ º
º ³ ³ ³ ³ º
º ÚÄÁÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÁÄ´ ÚÄÄÄÄÄÄÄÁÄÄÄ¿ º
º ³ CALCULAR ³ ³ CALCULAR ³ ³ CALCULAR ³ º
º ³BRUTO TRAB.³ ³REDUCCIONES³ ³BRUTO TRAB.³ º
º ³ POR MORAS ³ ³ NORMALES ³ ³ CONTRATO ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÙ º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 7: Descomposici¢n de la funci¢n: obtener el sueldo del
trabajador por horas
* Minimizar la duplicidad del C¢digo.
Se evita tener que realizar una funci¢n en m s de un m¢dulo.
* Crear M¢dulos £tiles.
Consiste en crear m¢dulos que puedan ser empleados en cual-
quier parte del sistema.
As¡, en el Ejemplo 3: vemos que el m¢dulo VALIDAR CAMPO
ALFABETICO puede utilizarse en cualquier otra parte del
sistema (o en otros sitemas que se desarrollen). Por ejemplo,
para hacer un chequeo en provincias o ciudades). Este ejemplo
se muestra graficamente en la Figura N§ 8: M¢dulo Validar
Campo Alfabetico.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍþÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ³ þ º
º ³ ³ º
º ÚÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÁÄÄÄÄÄÄ¿ Campo Alfabetico º
º ³ Obtener campo ³ Completo º
º ³ alfabetico siguiente ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÙ º
º ³ º
º ³ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ º
º ³ ³ º
º þ ³ ³ þ º
º ³ ÚÄÄÄÄÄÙ ÀÄÄÄÄÄÄ¿ ³ º
º ³ ÚÄÄÄÄÙ ÀÄÄÄÄ¿ ³ º
º ³ ³ ³ º
º Campo ³ Campo ³ ³ º
º ÚÄÄÄÄÄÙ ³ ÀÄÄÄÄÄ¿ º
º ³ ³ ³ º
º ÚÄÄÄÄÄÙ þ ÀÄÄÄÄÄÄÄÄÄÄ¿ º
º ÚÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ º
º ³ Obtener ³ ³ Validar ³ º
º ³ Campo siguiente ³ ³Campo alfabetico³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 8: M¢dulo Validar Campo Alfab‚tico
Puede surgir un problema cuando el dise¤ador se pregunte en
qu‚ momento debe dejar de descomponer m¢dulos.
- Se debe dejar de descomponer cuando no se encuentren func-
iones bien definidas.
- Se puede parar la descomposici¢n cuando la interfase con
un m¢dulo sea tan complicada como el m¢dulo en s¡ mismo.
Un m¢dulo de mil l¡neas es malo, ya que trata demasiados
m¢dulos en su interior, pero mil m¢dulos de una linea son
peores.
* Jerarqu¡a :
Al dividir los m¢dulos jer rquicamente, es posible contro-
lar el n£mero de ellos que interact£an directamente con
cualquiera de los otros.
El objetivo de aplicar una jerarqu¡a de m¢dulos que reali-
zan tareas de c lculo y edici¢n de aquellos que toman
decisiones y llaman a otros m¢dulos
Se debe lograr un tipo de organizaci¢n en donde los
m¢dulos de niveles medios y altos del diagrama ejerzan el
trabajo de coordinaci¢n y manipulaci¢n de los m¢dulos de
niveles m s bajos, que son los que deben realizar tareas
de c lculo y edici¢n.
* Independencia :
Si los m¢dulos individuales son completamente independi-
entes unos de otros, entonces el esfuerzo total
implicado en el desarrollo del sistema es una funci¢n
lineal del n£mero del m¢dulos del sistema.
La definici¢n de m¢dulos est cerca de la idea de CAJA
NEGRA: un m¢dulo no tiene que preocuparse por los detal-
les de la construcci¢n interna del resto de los m¢dulos.
Hay que ver a los m¢dulos solamente por su funci¢n y por
su apariencia externa.
b) Estrategias de Dise¤o.
El paso de los Diagramas de Flujo de Datos (DFD), obtenidos
en la Fase de An lisis del Sistema, a los Diagramas de Estr-
uctura de Cuadros (DEC), se puede hacer utilizando una serie
de estrategias que ayuden a conseguir una r pida derivaci¢n
hacia buen dise¤o.
Habr que estudiar la forma del DFD sobre el que se vaya a
realizar el dise¤o y dependiendo de su estructura, utilizar
una de las estrategias que se describen a continuaci¢n. El
uso de una de las dos estrategias no supone que la otra no
pueda ser utilizada. Depender £nicamente de la forma del
DFD y del peso de la actividad de los procesos.
A partir de esa primera estructura se realizar la evalua-
ci¢n y refinamiento del dise¤o hecho, consigui‚ndose, de esa
forma, un dise¤o con una alta calidad.
Estas estrategias son :
* An lisis de Transformaci¢n.
* An lisis de Transacci¢n.
El objeto de estas estrategias es desarrollar una represent-
aci¢n global de la arquitectura del Sistema. Una vez que se
define la estructura, podemos evaluar y refinar esta arquit-
ectura, vi‚ndola como un todo.
La descripci¢n de estas estrategias las veremos a continuac-
i¢n :
* An lisis de Transformaci¢n
El ®An lisis de Transformaci¢n¯ es una estrategia, no un
algoritmo. Si siguen los pasos de un algoritmo los result-
ados est n asegurados y son correctos, una estrategia
consigue resultados buenos, pero no perfectos en una
primera aproximaci¢n.
El an lisis de transformaci¢n es un conjunto de pasos que
permiten obtener, a partir de un DFD con caracter¡sticas
de transformaci¢n, la estructura del sistema.
El DFD con caracter¡sticas de transformaci¢n es aqu‚l en
el que se pueden distinguir tres zonas :
* Flujo de llegada o entrada.
* Flujo de Transformaci¢n o centro de transformaci¢n.
* Flujo de salida.
Esta divisi¢n en tres partes va a facilitar que los
datos que necesite el sistema se recojan por los m¢ dulos
que se encuentren en la/s rama/s de la izquierda, los
datos que se intercambian en esa rama ser n ascendentes:
informaci¢n de entrada al sistema.
En las ramas centrales habr movimiento de informaci¢n
compartido tanto ascendente como descendente porque aqu¡
los m¢dulos elaboran nuevos datos.
En las ramas de la derecha, la informacion ya ser la def-
initiva y el sentido de los datos debe ser descendente.
En alg£n caso particular puede suceder que alguna de las
partes sea vac¡a, esto es, no exista.
Los pasos necesarios para realizar el An lisis de Transfo-
rmaci¢n son los siguientes:
1. Aislar el centro de transformaci¢n.
2. Realizar ®el primer nivel de factorizaci¢n¯ del
Diagrama de Estructura de Cuadros.
3. Elaborar el ®segundo nivel de factorizaci¢n¯.
4. Refinar la estructura del sistema utilizando medidas
y guias de dise¤o.
A continuaci¢n se ver en detalle cada uno de estos pasos.
1. Aislar el Centro de Transformaci¢n.
El centro de transformaci¢n es la parte del DFD que cont-
iene las funciones esenciales del sistema y es independi-
ente de las caracter¡sticas particulares de la entrada y
de la salida.
Para aislar el centro de transformaci¢n habr que especi-
ficar los l¡mites del flujo de llegada y de salida.
Los l¡mites de flujo de llegada y salida est n abiertos a
interpretaci¢n de cada uno y se pueden derivar soluciones
de dise¤o alternativas variando la colocaci¢n de los
l¡mites de flujo, aunque una peque¤a variaci¢n tendr
poco impacto sobre la estructura final.
En el ejemplo siguiente, se ha aislado uno de los posib-
les Centros de Transformaci¢n, este ejemplo se muestra en
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º
º º º º
º ÚÄÄÄÂÄÄÄÄÄÄ¿ ÚÄÄÄÂÄÄÄÄÄ¿ º ÚÄÄÄÂÄÄÄÄÄ¿ ÚÄÄÄÂÄÄÄÄÄ¿ º º
º a ³ B ³ ³ b ³ C ³ ³ c º ³ F ³ ³ ³ H ³ ³ º º
º ÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄÄÅÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄÅÄÄÄÄþþÃÄÄÄÁÄÄÄÄÄÅÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄ´ º º
º ³ ³ ³ ³ º ³ ³ ³ ³ º º
º ÀÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÙ º ÀÄÄÄÂÄÂÄÄÄÙ ÀÄÄÄÂÄÄÄÄÄÙ º º
º º ³ ³ ³ º º
º º ³ ³ ³ º º
º þÄÄÄÄÄÙ ³ ³ º º
º º ³ ³ º º
º º ³ ³ º º
º e º ÀÄÄ¿ ³ º º
º ÚÄÄÄÄÄÄÄþ ³ ³ º º
º ³ º ³ ³ º º
º ³ º ³ ³ º º
º ³ º ³ þ º º
º d ÚÄÄÄÄÂÄÄÄÄÄÄÄ¿ ³ º ³ ÚÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ º º
º ÄÄÄÄÄÄÄþ³ E ³ ÃÄÄÄÄÄÙ º ÀÄÄþ³ I ³ ³ º º
º ÃÄÄÄÄÁÄÄÄÄÄÄÄ´ º ÃÄÄÄÄÁÄÄÄÄÄÄÄÄ´ º º
º ³ ³ º ³ ³ º º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄþº ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º º
º ³ º º º
º ³ ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ º
º ³ º
º ÚÄÄÄÄÄÄÄÄÙ º
º ³ ÚÄÄÄÄÂÄÄÄÄÄÄÄÄ¿ º
º ÚÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄ¿ ³ J ³ ³ º
º ³ CENTRO DE ³ ÃÄÄÄÄÁÄÄÄÄÄÄÄÄ´ º
º ³ TRANSFORMACION ³ ³ ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÄÄÄÄÙ º
º ³ º
º ³ º
º þ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 9: Aislar el Centro de Transformaci¢n.
2. Realizar el primer nivel de factorizaci¢n en Diagrama
de Estructura de Cuadros.
La estructura del programa debe representar una distribuci¢n
descendente del control.
El resultado del paso de DFD (Diagrama de Flujo de Datos) a
DEC (Diagrama de Estructura) debe ser una estructura en la que
los m¢dulos de nivel superior toman decisiones de ejecuci¢n y
los m¢dulos de nivel inferior ejecutan la mayor¡a del trabajo
de entrada, de c lculo y de salida.
En el primer nivel de factorizaci¢n aparecer n subordinados a
un m¢dulo de control del sistema, tres m¢dulos:
- M¢dulo controlador de proceso de la informaci¢n de llegada.
- M¢dulo controlador del centro de transformaci¢n.
- M¢dulo controlador del proceso de la informaci¢n de salida.
Esto se representa en la Figura N§ 10: Primer Nivel de Facto-
rizaci¢n.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º
º º º º º º
º º ÚÄÄÄÂÄÄÄÄ¿ ÚÄÄÄÂÄÄÄÄ¿ º º ÚÄÄÄÂÄÄÄÄ¿ ÚÄÄÄÂÄÄÄÄ¿ º º
º a º ³ B ³ ³ ³ C ³ ³ º c º ³ F ³ ³ ³ H ³ ³ º º
º ÄÄÄþþÃÄÄÄÁÄÄÄÄÅÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÅÄþÄÄÄÄþÄþÃÄÄÄÁÄÄÄÄÅÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄ´ º º
º º ³ ³ ³ ³ º º ³ ³ ³ ³ º º
º º ÀÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ º º ÀÄÄÄÂÄÄÄÄÙ ÀÄÄÄÂÄÄÄÄÙ º º
º º º º þ ³ ³ º º
º º º ÚþÄÄÄÙ ³ þ º º
º º ÚÄÄÄÂÄÄÄÄ¿ º ³º À¿ ÚÄÄÄÂÄÄÄÄ¿ º º
º º ³ E ³ ³ º ³º ³ ³ I ³ ³ º º
º ÄÄþÄÄÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÅÄÄÄÄÄÄÄÄÄþÄÄÄÙº ÀÄÄÄÄÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄ´ º º
º º ³ ³ º º ³ ³ º º
º º ÀÄÄÄÄÄÄÄÄÙ º º ÀÄÂÄÄÄÄÄÄÙ º º
º ÈÍÍÍþÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍþÍÍÍÍÍÍÍÍͼ º
º ³ ³ º
º ³ ³ º
º ³ ÀÄÄÄÄ¿ º
º ³ ³ º
º ³ þ º
º ³ ÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜÜ º
º ³ Ü Ü º
º ³ Ü ÚÄÄÄÂÄÄÄÄÄÄ¿ Ü º
º ³ Ü ³ ³ ³ Ü º
º ³ Ü ÃÄÄÄÁÄÄÄÄÄÄ´ Ü º
º ³ Ü ³ ³ Ü º
º ³ ÚÄÄÄÄþÜ ÀÄÄÄÄÂÄÄÄÄÄÙ Ü º
º ³ ³ ÜÜÜÜ ÜÜܳÜÜÜÜÜÜÜÜÜ º
º ³ ³ ³ ³ º
º ³ ³ ³ þ º
º ³ ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» ³ ³ º
º ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ º EL SIST MA º ÅÄÄÄÄÄÄÄÄÄÅÄÄ¿ º
º ³ ³ ÈÍÍÍÍÍÍÍÍÍÍÍÍÍͼ ³ ³ ³ º
º ³ ³ ³ ³ ³ ³ º
º ³ ³ ³ ³ ³ ³ º
º ³ ³ ³ ³ ³ ³ º
º þ þ þ ³ þ þ º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ Contener datos de ³ ³ Transformar ³ ³ ³ Producir datos de ³ º
º ³ entrada ³ ³ datos ³þÄÙ ³ salida ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 10: Primer Nivel de Factorizaci¢n.
3. Elaborar el Segundo nivel de factorizaci¢n.
El segundo nivel de factorizaci¢n se realiza mediante la con-
versi¢n de las transformaciones de cada proceso de un DFD
en los m¢dulos correspondientes del diagrama de estructura.
Para ello se comienza en el l¡mite del centro de transforma-
ci¢n y se va hacia afuera a lo largo de los caminos de llegada
y salida..
Un ejemplo del segundo nivel de transformaci¢n se muestra en
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ÉÍÍÍÍÍÍÍÍÍÍÍÍ» º
º º EL SISTEMA º º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄþÍÍÍÍþÍÍþþÍÍÍþÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ³ ³ ³ º
º ³ ÚÄÄÙ ÀÄ¿ ³ º
º ³ ³ ³ ³ º
º þ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ þ ÀÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ³ ÚÄÄÄÄÙ ÀÄÄÄ¿ ³ ³ º
º c³ ³ ³ þ ³ ³i ³ º
º ³ ³ ³e e³ ³ ³ ³ º
º ³ ÚÄÄÙ þ ÀÄ¿ ³ ³i º
º ³ ³ ³ ³ þ º
º ÚÄÄÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄ¿ º
º ³ OBTENER ³ ³ OBTENER ³ ³ CENTRO DE ³ ³ PRODUCIR ³ º
º ÀÄÄÄÄÂÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÙ ³ TRANSFORMACION ³ ÀÄÄÄÄÄÂÄÄÄÄÙ º
º ³ þ ³ ÀÄÄÄÄÄÂÄÄÄÄÄÂÄÄÄÄÙ ³ º
º ³ ³b ³ ³þ ³ ³ º
º ³ ³ þ e³ ³³ ³ ³ º
º ³ ³ ³ þ ³ ³ ³ º
º ÚÄÄÄÁÄÄÄÄÄ¿ ³ ³d ÚÄÄÄÄÙ ÀÄÄÄÄ¿ ³ º
º ³ OBTENER ³ ³ ³ ³ ³ ³ º
º ÀÄÄÄÂÄÄÄÄÄÙ ³ ³ ³ ³ þ ³ ³ º
º ³ ³ c³ ³ þ ³ ³h ³ ³i º
º ³ þ ³ ³ ³ ³ ³ ³ ³ þ ³ º
º ³ ³a ³ þ ³ ³f g³ ³ ³ ³ º
º ³ ³ ³ þ ³ ³ º
º ³ ³ ³ ³ ³ º
º ÚÄÄÁÄÄÄ¿ ÚÄÄÄÁÄÄ¿ ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄ¿ º
º ³ LEER ³ ³ LEER ³ ³ MODULO F³ ³ MODULO G ³ ³ ESCRIBIR ³ º
º ÀÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 11: Segundo Nivel de Transformaci¢n
4. Refinar la estructura del programa utilizando medidas y
gu¡a de dise¤o.
Una estructura de programa puede siempre refinarse siguiendo
los criterios que se ver n m s adelante en el apartado 3.
Dos o m s m¢dulos asignados por los correspondientes procesos
creados en la Fase de An lisis del Sistema se pueden continuar
en uno s¢lo y un m¢dulo puede que se detalle (explote) en dos
o m s m¢dulos.
* An lisis de Transacci¢n.
El an lisis de transacci¢n se aplica cuando un DFD toma una
forma en la que un dato determina la elecci¢n de uno o m s
flujos de informaci¢n.
La transacci¢n es evaluada y, bas ndose en su valor, el flujo
se inicia por uno de los muchos caminos de acci¢n.
El centro de flujo de informaci¢n desde el que emanan varios
caminos de acci¢n, se llama centro de transacci¢n.
Un ejemplo del an lisis de transacci¢n se muestra en la Figura
N§ 12: An lisis de Transacci¢n.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ÚÄÂÄÄÄÄÄÄ¿ ÚÄÂÄÄÄÄÄÄ¿ º
º ÚÄÄÄÄÄÄÄÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄ¿ º
º ³ ÀÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ ³ º
º ³ ³ º
º ³ Trasacci¢n A þ º
º ÚÄÂÄÁÄÄÄÄ¿ ÚÄÂÄÄÄÄÄÄ¿ ÚÄÂÄÄÄÄÄÄ¿ ÚÄÂÄÄÄÄÄÄ¿ º
º ÄÄÄÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÂÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÄþ º
º ÀÄÄÄÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÙ º
º þ ³ þ º
º ³ ³ Trasacci¢n B ³ º
º ³ ³ ÚÄÂÄÄÄÄÄÄ¿ ÚÄÂÄÄÄÄÄÄ¿ ³ º
º ³ ÀÄÄÄþÃÄÁÄÄÄÄÄÄÅÄÂÄþÃÄÁÄÄÄÄÄÄÅÄÄÄÄÄÄÄÄÄÙ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ÀÄÄÄÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÙ º
º ³ CENTRO DE ³ ³ º
º ³ TRANSACCION ³ Trasacci¢n C ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ º
º ³ º
º ³ Estrategias de An lisis de Trasacciones º
º ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍþÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º
º º ³ º º
º º þ º º
º º ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ º º
º º ÚÄÄÄÄÄÄ´ EL SISTEMA ÃÄÄÄÄÄÄÄ¿ º º
º º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ º º
º º ³ ³ º º
º º þ þ º º
º º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º º
º º ³ ANALIZAR ³ ³ CONTROLADOR ³ º º
º º ³ TRASACCIONE ³ ³ PROCESO ³ º º
º º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÚÄÄÄÄÄÄÄÄ´ TRASACCION ÃÄÄÄÄÄÄÄÄÄÄ¿ º º
º º ³ ÀÄÄÄÄÄÄÂÄÄÄÄÄÄÙ ³ º º
º º ³ ³ ³ º º
º º ³ ³ ³ º º
º º ³ ³ ³ º º
º º ³ ³ ³ º º
º º ÚÄÄÄÄÄÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ º º
º º ³ Proceso de ³ ³Proceso de ³ ³Proceso de ³ º º
º º ³Trasacci¢n B³ ³Trasacci¢n A³ ³Trasacci¢n C³ º º
º º ÀÄÄÄÄÄÄÄÄÂÄÄÄÙ ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ º º
º º ³ ³ ³ º º
º º ³ ³ ³ º º
º º ³ ³ ³ º º
º º ÚÄÄÄÄÄÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄÄ¿ º º
º º ³ Detalle ³ ³ Detalle ³ ³ Detalle ³ º º
º º ³ Proceso A ³ ³ Proceso B ³ ³ Proceso C ³ º º
º º ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÙ º º
º º º º
º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 12: An lisis de Transacci¢n
Los pasos del an lisis de transacci¢n son los siguientes:
1. Identificar el centro de transacci¢n
2. Tranformar el DFD en la estructura adecuada al proceso
de transacciones.
3. Factorizar la estructura de cada camino de acci¢n.
4. Refinar la estructura del sistema utilizando medidas y
gu¡as de dise¤o.
A continuaci¢n se detallan cada uno de los pasos.
1. Identificar el centro de transacciones.
La posici¢n del centro de transacci¢n puede descubrirse
inmediatamente a partir del DFD, viendo cu l es el origen de
una serie de caminos de informaci¢n que fluyen radialmente.
Cada camino de llegada y todos los caminos de acci¢n deben
tambi‚n aislarse. Cada camino de acci¢n debe evaluarse en
funci¢n de sus caracter¡sticas individuales de flujo.
En la Figura N§ 13: Identificaci¢n del Centro de Trans-
acci¢n, es un ejemplo claro de este caso.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÚÄÄÄÂÄÄÄÄÄÄÄÄ¿ Trans ÚÄÄÄÂÄÄÄÄÄÄÄÄ¿ º
º ³ 1 ³ ³ Valida ³ 2 ³ ³ º
º ÃÄÄÄÁÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄÄÄÄ´ º
º ÚÄÄÄÄÄþ³ Validar ³ A ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ³Trasacci¢n A³ ³ ³ ³ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ º
º ³ ³ º
º ³ ³ º
º ³ ³ Modificaciones º
º ³ TRASACCION A ³ diarias º
º ³ ³ º
º ³ ³ º
º ³ ³ º
º ³ þ º
º ÚÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ÚÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄ¿ Trans.ÚÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ 3 ³ ÃÄÄÄÙ ³ 4 ³ ³ Valida³ 5 ³ ³ ³ 6 ³ ³ º
º ÃÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄÄþÃÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄþ º
º ³Determinar tipo³ ³ Validar ³ B ³ Actualizar ³Modifi.³ Imprimir ³ º
º ³ transacci¢n ³ ³ Transacci¢n B ³ ³ archivo C ³diaria.³modifi. diarias³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º þ þ º
º ³ ³ º
º ³ ³ º
º ³ TRANSACCION B ³ Modificaciones º
º ³ ³ diarias º
º ³ ³ º
º ³ ³ º
º ³ ÚÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄ¿ Trans.ÚÄÄÄÂÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ º
º ÀÄÄÄÄÄÄÄÄÄ´ 7 ³ ³ Valida³ 8 ³ ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º ÉÍÍÍÍÍÍÍÍÍÍÍÍ» ÃÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÅÄÄÄÄÄþ ÃÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄ´ º
º º CENTRO DE º ³ Validar ³ C ³ Actualizar ³ º
º º TRASACCION º ³ Trasacci¢n ³ ³ archivo ³ º
º ÈÍÍÍÍÍÍÍÍÍÍÍͼ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º TRANSACCION C º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 13: Identificaci¢n del Centro de Transacci¢n
2. Transformar el DFD en la estructura adecuada al proceso
de transacciones.
El flujo de transacciones se convierte en una estructura de
programa formada por una bifurcaci¢n de entrada y una bifur-
caci¢n de salida.
3. Factorizar la estructura de cada camino de acci¢n.
La estructura de bifurcaci¢n de entrada se desarrolla de la
misma forma que el an lisis de transformaci¢n, comenzando en
el centro de transacci¢n y continuando desde el l¡mite hacia
afuera a lo largo del camino de llegada.
Cada camino de flujo de acci¢n del DFD se convierte en una
estructura que se corresponde con las caracter¡sticas espec-
¡ficas del flujo (flujo de transformaci¢n o transacci¢n).
Cada camino de acci¢n estudiado se desarrolla usando los
pasos de dise¤o discutidos anteriormente.
4. Refinar la estructura del programa utilizando medidas y
gu¡as de dise¤o.
En la Figura N§ 14: Paso de un DFD a DEC, se ilustra el
resultado de la aplicaci¢n sucesiva de estos pasos al DFD
anterior.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ PROCESAR ³ º
º ÚÄÄÄÄÄÄÄÄÄ´ TRANSACCION ÃÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ º
º ³ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÁÄÄÄÄÄ¿ º
º ³ ANALIZAR ³ ³ PROCESAR ³ º
º ³ TRANSACCION ³ ³ TRASACCION ³ º
º ÀÄÄÄÄÄÄÂÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÂÄÄÄÄÄÙ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ º
º ³ ³ ³ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÁÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄ¿ º
º ³ PROCESO A ³ ³ PROCESO B ³ ³ PROCESO C ³ º
º ÀÄÄÄÂÄÄÂÄÄÄÄÙ ÀÄÄÄÄÂÄÄÂÄÄÄÙ ÀÄÄÄÄÂÄÄÂÄÄÄÙ º
º ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÙ ÀÄ¿ º
º ÚÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄ¿ ÚÄÄÙ ÀÄÄÄÄÄÄÄÄ¿ ³ ³ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ÚÄÄÄÁÄÄÄÁÄ¿ ÚÄÄÄÄÄÄÄÄÄÁÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄ¿ º
º ³ Validar ³ ³ Validar ³ ³ Validar ³ ³Validar ³ ³ Validar ³ ³Validar ³ º
º ³Trasacci¢n A³ ³Archivo A³ ³Transacci¢n B³ ³Archivo B³ ³Transacci¢n B³ ³Archivo C³ º
º ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÙ ÀÄÄÄÄÄÄÂÄÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÙ º
º ³ ³ ³ ³ ³ ³ º
º ³ ³ ÀÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ º
º ³ ³ ³ ³ ÚÄÄÄÄÄÄÄÄÙ ³ º
º ³ ³ ÚÄÄÄÄÄÄÁÄÄÄÄÄÁÄÄÄÄÁÄ¿ ³ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ Imprimir ³ ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ Modificaciiones ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 14: Paso de un DFD a un DEC.
c) Evaluaci¢n y Refinamiento de Dise¤o
Un buen dise¤o debe organizar la complejidad del problema de
manera que el esfuerzo asociado con su desarrollo, prueba,
entendimiento y mantenimiento pueda ser controlado y mini-
mizado.
Para evaluar y mejorar el dise¤o obtenido con las estrategias
mencionadas se utilizan dos unidades de medida :
* ACOPLAMIENTO
* COHESION
Para mejorar la calidad del dise¤o tambi‚n se pueden utilizar
una serie de gu¡as o consejos pr cticos¯ que ayuden a conse-
guir este objetivo.
Estas gu¡as o consejos pr cticos se encuentran descritos a
continuaci¢n, de acuerdo a las dos unidades de medida.
* Acoplamiento
Se puede definir acoplamiento como el grado de interdepen-
dencias entre los m¢dulos; dependiendo del n£mero de par -
metros que se intercambian para su comunicaci¢n.
El objetivo que se debe conseguir es MINIMIZAR el acoplami-
ento, o lo que es lo mismo, hacer que los m¢dulos sean tan
independientes como sea posible, aunque esto no siempre se
consiga. Un bajo acoplamiento entre los m¢dulos indica que se
ha hecho una buena descomposici¢n del sistema, aunque esto no
ocurre siempre.
Uno de los puntos cruciales que hay que asegurar para conse-
guir un acoplamiento m¡nimo es que el m¢dulo no tenga que
preocuparse de los detalles de la construcci¢n interna del
resto de los m¢dulos (concepto CAJA NEGRA), ya que se trata de
conseguir m¢dulos lo m s independientes posibles.
Un bajo acoplamiento es deseable por las razones siguientes :
* Cuantas menos conexiones existan entre dos m¢dulos, menos
oportunidad habr de que aparezca el ®efecto onda¯ (un defe-
cto de un m¢dulo, puede aparecer afectando a otro).
* Se debe tener posibilidad de cambiar un m¢dulo con el m¡nimo
riesgo de tener que cambiar otro, se trata de que cada
cambio realizado afecte lo menos posible a otros m¢dulos.
* Mientras se est‚ manteniendo un m¢dulo, es deseable no nece-
sitar preocuparse en los detalles internos (c¢digo) de
cualquier otro m¢dulo.
Existen diversos niveles de acoplamiento seg£n el siguiente
espectro :
1. Acoplamiento Normal
* De Datos
* Por Estampado
* De control
2. Acoplamiento Com£n
3. Acoplamiento por contenido
1. Acoplamiento Normal
Ocurre cuando dos m¢dulos intercambian datos pero ‚stos no
interfieren en la operativa normal de la funci¢n que realiza
el m¢dulo de nivel inferior.
* Acoplamiento de Datos
Entre dos m¢dulos el que llama y el llamado, ha de estable-
cerse al menos una comunicaci¢n b sica por medio de
elementos.
Un ejemplo de este acoplamiento se muestra en la Figura N§
15: Acoplamiento de Datos.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÚÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ OBTENER ³ º
º ³ DATOS ³ º
º ³ CLIENTES ³ º
º ÀÄÄÄÄÂÄÄÄÄÄÙ º
º Nombre þ ³ º
º cliente ³ ³ º
º ³ ³ N£mero de º
º N£mero þ ³ ³ cuenta cliente º
º cuenta OK ³ ³ þ º
º ³ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ º
º ³ ENCONTRAR ³ º
º ³ NOMBRES DE ³ º
º ³ CLIENTES ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 15: Acoplamiento de Datos.
Este acoplamiento no da ning£n tipo de problemas, pero hay que cont-
rolar que los datos se generen lo m s cerca posible del m¢dulo que
los vaya a utilizar.
* Acoplamiento de Estampado
Ocurre si en la comunicaci¢n entre m¢dulos se pasan datos con estru-
ctura de registro. Este acoplamiento no es deseable si el m¢dulo que
recibe ese registro necesita s¢lo parte de los elementos que se le
pasan.
Un ejemplo de este acoplamiento se muestra en la Figura N§ 16: Acop-
lamiento de Estampado.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÚÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ OBTENER ³ º
º ³ NOMBRES ³ º
º ³ CLIENTES ³ º
º ÀÄÄÄÄÂÄÄÄÄÄÙ º
º ³ º
º Registro þ ³ º
º cliente ³ ³ ³ Registro º
º valido ³ ³ ³ Cliente º
º ³ þ º
º ³ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ º
º ³ VALIDAR ³ º
º ³ NOMBRES DE ³ º
º ³ CLIENTES ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 16: Acoplamiento de Estampa.
* Acoplamiento de Control
Ocurre si los datos de comunicaci¢n n controles. Ya se sabe que
los m¢dulos superiores coordinan y los de nivel inferior realizan el
trabajo, ‚stos deber n comunicar su estado. Este tipo de acopla-
miento no ser nocivo si el control (flag) tiene sentido ascendente
ya que informar de la situaci¢n en la que se encuentra el m¢dulo
inferior.
Sin embargo en el caso de la figura, el control tiene sentido desce-
ndente, lo que implica una ruptura del principio de ®caja negra¯: el
m¢dulo superior conoce detalles de la estructura del m¢dulo
inferior. Esto podr¡a implicar problemas de mantenimiento, si se
cambiase el m¢dulo inferior.
Un ejemplo de acoplamiento de control se muestra en la Figura N§ 17:
Acoplamiento de Control.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÚÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ IGUALAR ³ º
º ³ REGISTRO ³ º
º ³ CLIENTES ³ º
º ÀÄÄÄÄÂÄÄÄÄÄÙ º
º ³ þ Registro º
º Control ³ ³ Maestro º
º trabajo del ³ º
º modulo ³ þ Registro º
º inferior ³ ³ Transacciones º
º ³ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ º
º ³ CONTROLAR ³ º
º ³ENTRADA/SALIDA³ º
º ³ SISTEMA ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 17: Acoplamiento de Control.
2. Acoplamiento Com£n.
Se produce cuando un n£mero indeterminado de m¢dulos (m s de
dos) hacen referencia a un rea com£n de datos.
Algunos lenguajes de programaci¢n lo permiten, pero no es ope-
rativo puesto que en alg£n momento esos datos pueden ser cambiados
y al acceder otro m¢dulo puede no encontrar la informaci¢n cor-
recta. Habr¡a que ser muy estrictos en cuanto al acceso, y la
protecci¢n de esa rea.
3. Acoplamiento de Contenido
Ocurre cuando un m¢dulo cualquiera, necesita o accede a una parte
de otro, rompiendo la jerarqu¡a de funcionalidad de la estructura.
Un ejemplo de ‚ste acoplamiento se muestra en la Figura N§ 18:
Acoplamiento de Contenido.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º ÚÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ³ º
º ³ ³ º
º ³ ³ º
º ÀÄÄÄÄÂÄÄÄÄÄÙ º
º ³ º
º ³ º
º ³ º
º ³ º
º ³ º
º ³ º
º ÚÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ º
º ³ þÄÄÄÄÄÄÄÄÄÄþ ³ º
º ³ þÄÄÄÄÄÄÄÄÄÄþ ³ º
º ³ þÄÄÄÄÄÄÄÄÄÄþ ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 18: Acoplamiento de Contenido.
Si ocurre esto, habr que evitarlo descomponiendo el m¢dulo al que
se accede o duplicando esa parte de c¢digo en el m¢dulo que llama..
Existen diversos factores que afectan el acoplamiento, entre ellos
tenemos :
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Tipo de ºSemsible al º Modifica- º Compren- º Utilizable en º
º Acoplamiento ºefecto Onda º lidad- º si¢n º otro Sistema º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º Acoplamiento sist.º º º º º
º De datos º Variable º Buena º Buena º Bueno º
º Por Estampado º Variable º Media º Media º Medio º
º De control º Medio º Pobre º Pobre º Pobre º
º Comun º Medio º Media º Mala º Pobre º
º Por contenido º Medio º Media º Media º Malo º
º º º º º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
* Cohesi¢n
La cohesi¢n se puede definir como la medida de la fuerza o
relaci¢n funcional de los elementos de un m¢dulo, entendiendo por
elementos a la sentencia o grupo de sentencias que lo componen, a
las definiciones de datos o a las llamadas a otros m¢dulos.
Un m¢dulo coherente ejecuta una tarea sencilla en un programa o
procedimiento y requiere poca interacci¢n con otros procedimientos
que se ejecuten en otras partes del programa.
Un m¢dulo coherente s¢lo debe hacer (idealmente) una cosa.
El objetivo que se intenta conseguir es obtener m¢dulos con una alta
cohesi¢n.
Asegurar que los m¢dulos tienen una buena cohesi¢n es la mejor
manera de minimizar el acoplamiento.
La escala de cohesi¢n no es lineal. Esto significa que una cohesi¢n
baja es mucho ®peor¯ que la de rango medio, la cual es casi tan
®buena¯ como una gran cohesi¢n.
Los distintos niveles de cohesi¢n son los siguientes :
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Funcional º Mejor Mantenibilidad º Caja Negra º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º º º º
º Secuencial º : º No Demasiadaº
º Comunicacional º : º Caja Negra º
º Procedual º : º Caja Gris º
º Temporal º : º º
º L¢gica º : º Caja Blanca º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º º Peor Mantenibilidad º º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
º º º º
º Coincidental º º Transparente º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
1. Cohesi¢n Funcional
Un m¢dulo con cohesi¢n funcional contiene elementos que contribuyen
a la realizaci¢n de una, y s¢lo una, tarea funcional.
Ejemplos de m¢dulos funcionalmente coherentes son los que realizan
el c lculo de coseno de un ngulo, leen un registro, etc.
Los sistemas construidos principalmente con acoplamiento normal
y con m¢dulos coherentes funcionalmente con los m s faciles de
mantener.
2. Cohesi¢n Secuencial
Un m¢dulo realiza distintas tareas dentro de ‚l en secuencia, de
forma que las entradas de cada tarea son las salidas de la anterior.
3. Cohesi¢n Comunicacional
Un m¢dulo realiza actividades paralelas usando los mismos datos de
entrada y de salida.
4. Cohesi¢n Procedural
Igual que la secuencial, pero con paso de controles.
5. Cohesi¢n Temporal
Las actividades que realizan tienen una matriz temporal.
6. Cohesi¢n L¢gica
Si las actividades que realiza un m¢dulo tienen la misma categor¡a,
es algo as¡ como tener partes independientes dentro de ese m¢dulo.
7. Cohesi¢n Coincidental
Un m¢dulo con cohesi¢n coincidental es aquel cuyos elementos contr-
ibuyen a las actividades relacion ndose mutuamente de una manera
poco significativa.
Los m¢dulos con cohesi¢n coincidental violan el principio de indep-
endencia y de caja negra de los m¢dulos, ya que es necesario que el
®padre¯ tenga conocimientos de la estructura interna de los m¢dulos
®hijos¯.
Entre los factores que afectan la cohesi¢n tenemos los siguientes :
FACTORES A LOS QUE AFECTA LA COHESION
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍËÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º Nivel de º Acopia- ºFacilidad ºCompren- º Modifica- º Mantenimiento º
º cohesi¢n º miento ºImplantaci¢n ºsibilidad º lida º de Sistemas º
ÌÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÎÍÍÍÍÍÍÍÍÍÍÍÍÍÍ͹
ºFuncional º Bueno º Buena º Buena º Buena º Buena º
ºSecuencial Buenoº Bueno º Buena º Buena º Buena º Bast. º
ºComunicacional º Medio º Media º Media º Media º Medio º
ºProcedural º Variable º Pobre º Variable º Variable º Malo º
ºTemporal º Pobre º Media º Media º Media º Medio º
ºL¢gica º Malo º mala º Mala º Pobre º Malo º
ºCoincidente º Malo º Pobre º Mala º Media º Malo º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÊÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
El dise¤o tambien puede ser mejorado al aplicarse las siguientes
ideas :
* Hay que reducir el n£mero de par metros que intercambian los
m¢dulos tanto como sea posible, es mejor que los datos de comuni-
caci¢n que se pasen sean elementos de registros.
* Hay que evitar pasar par metros de un m¢dulo a otro, a menos que
tengan una utilidad pr ctica.
Tome la decisi¢n de que hacer con esa informaci¢n.
Otro de los consejos que se recomienda utilizar son los
siguientes :
* Se recomienda no utilizar variables globales por CINCO razones:
1. Un defecto (o mala pr ctica al programar) de cualquier m¢dulo que
utiliza un rea global, puede transmitirse a cualquier otro
m¢dulo que utilice esa rea global.
2. Los m¢dulos que se refieren a datos globales siempre los utilizan
con el mismo nombre disminuyendo la flexibilidad de los m¢dulos.
3. Se introduce un tipo de distanciamiento en el sistema en el
tiempo. Puede ser dif¡cil entender c¢mo lleg¢ a tomar un valor
determinado una variable.
4. Son m s dif¡ciles de entender al tener que saber que datos se
utilizan en cada m¢dulo particular.
* Es dif¡cil encontrar que m¢dulos se deben cambiar cuando una
parte de los datos cambia.
* No se debe compartir c¢digo entre las actividades que est n
incluidas en un m¢dulo. Esto hace dif¡cil modificar una
actividad sin cambiar la otra.
* Se debe preparar la descomposici¢n cuando no se encuentren
funciones bien definidas. No se debe crear un m¢dulo con una
serie de l¡neas de c¢digo agrupadas aleatoriamente.
* Se puede parar la descomposici¢n cuando la interfase con un
m¢dulo sea tan complicada como el m¢dulo en s¡ mismo.
* Se deber n conseguir dise¤os lo m s equilibrados que sea posib-
le. Puede decidirse que un dise¤o est equilibrado si y s¢lo
si, trata con datos l¢gicos en su parte alta y con datos
f¡sicos en su parte baja.
Un ejemplo de un sistema bien equilibrado se muestra en la
Figura N§ 19: Sistema Bien Equilibrado.
Un m¢dulo realiza una funci¢n y debe ser llamado por todos los
m¢dulos que requieran esa funci¢n.
Un m¢dulo de nivel inferior puede llamar a otro m¢dulo de nivel
superior de otra rama del diagrama.
Es desaconsejable que un m¢dulo de nivel inferior llame a otro
de nivel superior de la misma rama ya que esto puede dar lugar
a bucles sin salida.
EJEMPLO DE SISTEMA BIEN EQUILIBRADO
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ACTUALIZAR ³ º
º ³ REGISTRO ³ º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ MAESTRO ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ÀÄÂÄÄÄÄÄÄÄÂÄÄÙ ³ º
ºTrasacciones ³ ³ ³ þ ³ º
º ³ ³ ³ ³ ³ ³ ³ º
º ³ ³ ³ ³ ³ ³ ³ º
º þ ³ þ ³ þ ³ ³ þ º
º ³ ³ ³ ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ º
º ³ ³ ³ ³ ³ Registro ³ Registro º
º ³ ³ ³ ³ Registro ³ maestro ³ maestro º
º ³ ³ maestro ³ ³ actualizado ³ actualizado º
º ³ ³ antiguo ³ ³ ³ º
º ³ ³ þ ³ ³ º
º ³ ³ ³ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ÚÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄ¿ º
º ³ OBTENER ³ ³ OBTENER ³ ³ ACTUALIZAR ³ ³ INSERTAR ³ º
º ³ TRANSACCION ³ ³ MAESTRO ³ ³ MAESTRO ³ ³ MAESTRA ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÂÄÄÄÙ ³ ANTIGUO ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÂÄÄÄÄÄÙ º
º þ ³ ÀÄÄÄÄÄÄÄÄÄÙ Registro ³ º
º ³ ³ maestro ³ º
º ³ ³ actualizado ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ º
º ³ ³ þ þ ³ ³ º
ºTrasaccion ³ ³ ³Trasacci¢n ³ ³ Registro ³ ³ º
º ³ ³ ³ ³Validas ³ ³ ³ maestro ³ ³ º
º ³ ³ ³ ³ ³ formateado ³ þ º
º ³ þ ³ ³ þ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÁÄÄ¿ º
º ³ OBTENER ³ ³ VALIDAR ³ ³ FORMATEAR ³ ³ FORMATEAR ³ º
º ³ TRANSACCION ³ ³ CRUZADA DE ³ ³ REGISTRO ³ ³ REGISTRO ³ º
º ÀÄÄÄÄÄÄÂÄÄÄÄÄÄÙ ³ CAMPOS ³ ³ MAESTRO ³ ³ MAESTRO ³ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ NUEVO ³ º
º þ ³ ÀÄÄÄÄÄÄÂÄÄÄÄÙ º
º ³ ³ Transacci¢n ³ º
º ³ ³ valida ³ º
º ³ ÚÄÄÄÄÄÙ º
º ³ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ³ º
º ³ OBTENER ³ þ º
º ³ CAMPO ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ TRANSACIONES ³ ³ CARACTERISTICAS FISICAS ³ º
º ÀÄÄÄÄÄÄÂÄÄÄÂÄÄÄÙ ³ DE ENTRADA / SALUD ³ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º þ³ ³ þ º
º ³³ ³ ³ º
º ³³ ³ þ ³ º
ºCampo ³ ³ ³ ³ ³ º
ºTransacci¢n³ ³ ³ ³ Campo transacci¢n ³ º
º ³ þ ³ ³ º
º ³ ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º ³ ³ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÁÄÄÄÄÄÄÄ¿ ³ º
º ³ OBTENER ³ ³ EO. TRANS. ³ ³ º
º ³ CAMPO ³ ³ CA PO ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º ³ TRANSACCION ³ ³ TRANSACCION ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
d) Heur¡sticas de Dise¤o
Las heur¡sticas de dise¤o son un conjunto de recomendaciones que
ayudan a mejorar la estructura del sistema, optimizando la modu-
laridad. La aplicaci¢n de estas recomendaciones depende en gran
medida del dise¤o espec¡fico, as¡ como de las caracter¡sticas
del equipo f¡sico donde se desarrolla el sistema.
* Tama¤o de un m¢dulo
El desarrollo del sistema de una estructura modular define la
funcionabilidad propia de cada m¢dulo; sin embargo es recomenda-
ble revisar independientemente cada m¢dulo a efectos de
optimizar su tama¤o en n£mero de sentencias, para facilitar el
desarrollo t‚cnico del programa y su posterior mantenimiento.
En general, podemos resumir diferentes versiones sobre el tama¤o
¢ptimo de cada m¢dulo definiendo que el coste en el desarrollo y
mantenimiento de un sistema ser ¢ptimo cuando su estructura
est‚ compuesta por m¢dulos con un tama¤o comprendido entre 10 y
100 sentencias (CONSTANTINE).
* Ambito de control
Se llama mbito de control de un m¢dulo a todos los m¢dulos
llamados por ‚l y a los llamados por ‚stos, es decir, a todos
los m¢dulos que hay por debajo de ‚l en esa rama del diagrama de
descomposici¢n funcional.
Un m¢dulo que llama a muchos otros puede ser dif¡cil de entender,
y en el otro extremo, si los m¢dulos forman una larga secuencia
lineal, es posible que pueda suprimirse alguno de ellos. Deben
evitarse ambos extremos:
* Ambito de Control Alto:
Normalmente se produce cuando no se tienen en cuenta los niveles
intermedios. El estudio de los grupos de m¢dulos subordinados
que permitan combinar sus funciones en una sola, puede soluci-
onar el problema..
Un ejemplo del mbito de control alto se muestra en la Figura
N§ 20: Ambito de Control Alto.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ²²²²²²²²²² º
º ²²²²²²²²²² º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄþ²²²²²²²²²² þÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ þ þ þ ³ º
º ³ ³ ³ ³ ³ º
º ³ ³ ³ ³ ³ º
º ³ ÚÄÄÄÄÄÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÄÄÄ¿ ³ º
º ³ ³ ³ ³ ³ º
º ³ ³ ³ ³ ³ º
º ³ ³ ³ ³ ³ º
º þ þ þ þ þ º
º ²²²²²²²²² ²²²²²²²²² ²²²²²²²²²² ²²²²²²²²²² ²²²²²²²²²² º
º ²²²²²²²²² ²²²²²²²²² ²²²²²²²²²² ²²²²²²²²²² ²²²²²²²²²² º
º ²²²²²²²²² ²²²²²²²²² ²²²²²²²²²² ²²²²²²²²²² ²²²²²²²²²² º
º º
º º
º ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» º
º º AMBITO DE CONTROL º º
º º ALTO º º
º ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 20: Ambito de Control Alto.
* Ambito de Control bajo:
Para optimizar una estructura de ese tipo se deben revisar las
posibilidades de descomponer las funciones en subfunciones con
entidad propia, para formar nuevos m¢dulos, o por el contrario,
comprimir m¢dulos subordinados en el m¢dulo de nivel superior.
Un ejemplo de este mbito se muestra en la Figura N§ 21: Ambito
de Control Bajo.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ²²²²²²²² ³ AMBITO DE CONTROL ³ º
º ²²²²²²²² ³ BAJO ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º ²²²²²²²² º
º ²²²²²²²² ÚÄÄÄÄÄþ²²²²²²²²þÄÄÄÄÄÄ¿ º
º ³ ²²²²²²²² ³ º
º ²²²²²²²² þ þ º
º ²²²²²²²² ²²²²²²²² ²²²²²²²² º
º ÚÄÄÄÄÄþ²²²²²²²²þÄÄÄÄÄ¿ ²²²²²²²² º
º ²²²²²²²² ³ þ ³ þ º
º ²²²²²²²² þ þ þ þ º
º ²²²²²²²² ²²²²²²²² ²²²²²²²²² ²²²²²²²² º
º ²²²²²²²² ²²²²²²²² ²²²²²²²² ²²²²²²²²² ²²²²²²²² º
º ²²²²²²²² º
ºÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º³ AMBITO DE CONTROL ³ º
º³ CORRECTO ³ º
ºÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
Figura N§ 21: Ambito de Control Bajo.
* Ambito de efecto
Este t‚rmino se aplica a los m¢dulos en los que interviene
alguna decisi¢n e identifica a los m¢dulos afectados por esa
decisi¢n.
El mbito de efecto debe estar contenido en el mbito de control
del m¢dulo que toma la decisi¢n.
Si no se da ninguna norma, es decir, si hay m¢dulos en otras
ramas del diagrama de descomposici¢n funcional que dependa de
esa decisi¢n, habr un flujo de control hacia arriba y hacia
abajo por el acoplamiento, o incluso se puede dar que la misma
decisi¢n se tome de nuevo en otra rama del diagrama.
Generalmente, existen tres soluciones a este problema :
1. Integrar el m¢dulo de nivel bajo en su m¢dulo superior, de
manera que la decisi¢n quede situada en un nivel alto de estru-
ctura.
2. Trasladar dentro de la estructura del mbito de efecto el m¢dulo
afectado por la decisi¢n.
3. Extraer la decisi¢n del m¢dulo de nivel bajo y ponerla en el
m¢dulo de nivel alto.
La relaci¢n existente entre el mbito de control y el mbito de
efecto se muestra en la Figura N§ 22: Relaci¢n entre Ambito de
Control / Ambito de Efecto.
Figura N§ 22: Relaci¢n entre Ambito de Control / Ambito de
Efecto.
ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ»
º º
º º
º ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³AMBITO CONTROL³ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ´ PRINCIPAL ³ º
º ³AMBITO EFECTO ³ ³ ÀÄÄÄÄÄÄÂÄÄÄÄÙ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ³ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ³ º
º ³ ³ º
º ³ ³ º
º ³ ³ º
º ÚÄÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄ¿ º
º ³ PROCESAR ³ ³ PROCESAR ³ º
º ÚÄÄÄÄÄÄÄÄÄÄÄ´ X ÃÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ TIPO II ³ º
º ³ ÀÄÄÄÄÄÂÄÄÄÄÙ ³ ÀÄÄÄÄÄÄÄÄÄÄÙ º
º ³ ³ ³ º
º ³ ³ ³ º
º ³ ³ ³ º
º ³ ³ ³ º
º ³ ³ ³ º
º ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ LEER X ³ ³ VALIDAR ³ ³ PROCESAR ³ ³ PRINCIPAL ³ º
º ÀÄÄÄÄÄÄÄÄÄÙ ³ TIPO X ³ ³ TIPO 1 ³ ÀÄÄÄÄÄÂÄÄÄÄÄÄÙ º
º ÀÄÄÄÄÂÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÄÙ ³ º
º ³ ³ º
º ³ ³ º
º ³ ³ º
º ÚÄÄÄÁÄÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄÄ¿ º
º ³ TIPO DE ³ ÚÄÄÄÄÄÄÄÄÄÄÄÄ´ PROCESAR ÃÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ERROR ³ ³ ÀÄÂÄÄÄÄÄÄÄÄÄÂÙ ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÙ ³ ³ ³ ³ º
º ³ ³ ³ ³ º
º ³ ³ ³ ³ º
º ÚÄÄÄÄÁÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄ¿ ÚÄÄÁÄÄÄÄÄÄÄ¿ ÚÄÄÄÄÁÄÄÄÄ¿ º
º ³ OBTENER ³ ³ TIPO X ³ ³ PROCESAR ³ ³ ROCESAR ³ º
º ³ VALIDAR ³ ÀÄÄÄÄÄÄÄÄÙ ³ TIPO I ³ ³ TIPO II ³ º
º ÀÄÄÄÂÄÄÄÂÄÙ ÀÄÄÄÄÄÄÄÄÄÄÙ ÀÄÄÄÄÄÄÄÄÄÙ º
º ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ ³ º
º ³ ³ º
º ÚÄÄÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÁÄÄÄÄÄ¿ ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ º
º ³ LEER X ³ ³ TIPO DE ³ ³ AMBITO EFECTO ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÙ ³ ERROR ³ ³ FUERA DEL AMBITO ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÙ ³ CONTROL ³ º
º ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ º
º º
ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ
e) Definici¢n de los Programas.
Por £ltimo, el dise¤ador debe agrupar todos los m¢dulos que ha
definido en distintos programas.
Existen en este sentido dos posturas muy contrastadas:
* Construir un programa por cada m¢dulo.
Se garantiza que los campos de trabajo de un m¢dulo no sean acc-
esibles para otro para asegurar por tanto, que no se den acopla-
miento patol¢gicos.
Como contrapartida el funcionamiento se hace m s lento, puesto
que los programas realizan continuas llamadas ®CALL¯ a peque¤os
programas. Adem s, un programa que sea llamado por otros estar
cargado en memoria tantas veces como programas lo llamen.
* Agrupar todos los m¢dulos en un programa, asociado cada uno de
ellos a un p rrafo.
Funcionamiento m s r pido, sin necesidad de realizar ®CALL¯.
Las desventajas son evidentes: desbordamientos de memoria,
encarecimiento de las modificaciones, rigidez, etc.
Existen diversos criteros para definir programa, donde se debe
clasificar los m¢dulos en programas teniendo en cuenta las rest-
ricciones de equipo f¡sico y sistema operativo, de modo que el
resultado sea lo m s eficiente posible, con programas peque¤os y
manejables. Los factores a tener en cuenta son:
* Iteraci¢n: Si un m¢dulo llama a otro iterativamente, se
pueden evitar muchos CALL poniendo ambos m¢dulos en el mismo
programa.
* Volumen: Si se conoce el n£mero de veces que un m¢dulo llama
a otro, se deben poner en el mismo programa.
* Intervalo: Aquellos m¢dulos que en un peque¤o intervalo tenga
una alta frecuencia de llamada deben ir en el mismo programa.
* Funci¢n Opcional: Los m¢dulos que realicen funciones secundar-
ias u opcionales pueden ir en programas independientes.
* Ejecuci¢n £nica: Los m¢dulos que se ejecutan una £nica vez en
el sistema deben ser programas independientes.
* Clasificaci¢n: Los m¢dulos que sean entradas o salidas de un
proceso de clasificaci¢n deben ser programas independientes.
As¡ mismo, cada programa de una aplicaci¢n debe documentarse
exhaustivamente con el fin de facilitar su futuro mantenimi-
ento por cualquier persona del departamento de desarrollo.
Para ello se deber disponer de la siguiente informaci¢n:
* Estructuras de datos de los distintos ficheros de entrada y
salida que utiliza el programa.
* Diagrama de correspondencias entre ficheros de entrada y
salida.
* Estructura del programa una vez integradas las estructuras de
entrada y salida.
* Comentarios sobre el programa, indicando:
- Colisiones detectadas y forma de resolverlas.
- Normas especiales de ejecuci¢n.
- Limitaciones.
- Tablas de decisi¢n.
- Lista detallada de operaciones.
* Estructura del programa conteniendo la asignaci¢n de operaciones.
* L¢gica esquem tica (pseudoc¢digo).
* Listado del programa fuente, compilado y sin errores.
* Listado de referencias cruzadas para facilitar la b£squeda de
variables y entidades a lo largo del programa, cuando sea necesa-
rio efectuar su mantenimiento.
* Listado de ocupaci¢n de memoria.
* Cualquier otro listado que proporcione el compilador o sistema
operativo.
* Documentaci¢n de la prueba definita que se realiz¢ para obtener
la aceptaci¢n del programa, adjuntando juegos de ensayo, condici-
ones de prueba, tiempo invertido y resultados obtenidos.
|
