Introduccin al Diseo de Sistemas de

Informacin
Unidad N III: Diseo Estructurado
Facultad Regional Santa Fe Universidad Tecnolgica Nacional
2
Diseo Estructurado
Como vimos, el Diseo de Software es :
Proceso mediante el que se traducen los requisitos en una representacin del
software (Robert Pressman)
El objetivo ms importante es :
entregar las funciones requeridas por el usuario en una implementacin de software
(satisfaga una especificacin funcional dada).
El diseo es un proceso mediante el cual se traducen los requisitos del sistema en una
representacin de software. A travs de refinamientos sucesivos se genera una representacin
de diseo que se acerca mucho al cdigo fuente.
El diseo se realiza, generalmente, en dos pasos :
Diseo preliminar, el cual se centra en la transformacin de los requisitos en los
datos y la arquitectura del software.
Diseo detallado, el que se ocupa del refinamiento de la representacin
arquitectnica que lleva a una estructura de datos detallada y a las
representaciones algortmicas del software.
El Diseo Estructurado se fundamenta en una descomposicin funcional sistematizada, la que
se lleva a cabo de acuerdo a las siguientes actividades/fases:
1. Representar el sistema como un Diagrama de Flujos de Datos (DFD).
2. Estructurar el sistema como jerarquas de procesos (utilizando Diagramas
Estructurados).
Anlisis transformacional.
Anlisis transaccional.
3. Verificar proyecto y reestructurar.
La verificacin se realiza analizado si estn correctamente aplicados los conceptos de:
Cohesin
Acoplamiento
Alcance de efectos/control
Tamao de la interfaces
Balance del diseo
Etc.
4. Descomposicin de procesos
Refinamiento sucesivo
Factorizacin
5. Preparar para la implementacin.
El Diseo Estructurado (DE) se fundamenta en una descomposicin funcional sistematizada, la
que se lleva a cabo convirtiendo sistemticamente DFDs en Diagramas Estructurados (DE,
Structure Charts)
Para realizar estar transformacin podemos aplicar estrategias ascendentes o descendentes,
siendo sin embargo el diseo estructurado una tcnica estrictamente top-down (en el sentido
de que el diseo se va realizando gradualmente por refinamiento sucesivo).
3
Figura III. 1 Transformacin de un DFD en un DE
Estrategias Ascendente (Bottom-Up) y Descendente (Top-Down)
Diseo ascendente (bottom-up)
El diseo ascendente se refiere a que la identificacin de los procesos que se automatizarn se
realiza partiendo del nivel ms bajo hasta llegar al nivel superior.
Desde el punto de vista de una organizacin, se hace referencia a que los problemas que
requieren una automatizacin inmediata se encuentran en los niveles inferiores, y por otra parte
son los de menor costo de implementacin.
El problema que presenta este enfoque, es que es muy difcil integrar los objetivos de los
distintos subsistemas construidos en pos de un objetivo global. Esto es as debido a que cada
uno fue concebido persiguiendo un objetivo particular, y en consecuencia no se previeron los
mecanismos de interaccin adecuados con otros subsistemas.
El principal problema de este enfoque es que no se consideran los objetivos globales de la
organizacin, y en consecuencia no se satisfacen. Pueden presentarse adems duplicacin de
esfuerzos para introducir y acceder a los datos; y tambin pueden introducirse al sistema datos
carentes de valor.
Figura III. 2 Diseo Ascendente
A
B C D
E F
Coordi
nador
A B C
Proce
so A
Proce
so B
Proce
so C
4
Diseo descendente (top-down)
El enfoque descendente implica observar la gran imagen del sistema y luego, explosionarlo o
desglosarlo en partes ms pequeas o subsistemas.
El diseo descendente obliga a enterarse primero de los objetivos globales de la organizacin,
as como el establecimiento de la mejor manera de satisfacerlos dentro de un sistema integral.
Cuando se aplica un enfoque descendente se emplean las interrelaciones e interdependencias
de los subsistemas, para apegarse lo mejor posible a las necesidades de la organizacin.
En este enfoque se da la importancia debida a las interfaces requeridas entre el sistema y sus
subsistemas, lo cual no existe en el enfoque ascendente.
La aplicacin de este enfoque posibilita contar con distintos grupos de desarrollo trabajando en
forma simultanea en subsistemas independientes.
Un inconveniente que presenta este enfoque es que se divida el sistema en subsistemas
incorrectos. Se debe prestar atencin para que la particin en subsistemas tenga sentido en
el esquema global del sistema, y que se integren en forma correcta al sistema.
Debe tenerse presente que una vez que se realizan las divisiones en subsistemas, sus
interfaces pueden descuidarse o simplemente ignorarse.
Debe tenerse siempre presente la retroalimentacin entre los distintos subsistemas y grupos de
desarrollo para mantener unificados los criterios.
Figura III. 3 Diseo Descendente
Diagramas Estructurados
Los Diagramas Estructurados (DE) describen una arquitectura de programas a travs de una
jerarqua de llamadas a mdulos.
Estos DE son elaborados a partir de la descomposicin funcional pura de los DFDs, y
presentan una estructura de control limitada.
Como desventaja puede decirse que se tornan difciles de leer cuando hay muchos detalles de
los flujos de datos y control entre los distintos mdulos.
Existe un acuerdo general en el sentido de que los sistemas ms fciles de cambiar son
aquellos que estn constituidos por mdulos manejablemente pequeos, cada uno de los
cuales es independiente, hasta donde es posible, de cualquier otro, de manera que pueden
sacarse del sistema, cambiarse, y reponerse sin afectar el resto del sistema.
Un diseo modular reduce la complejidad, facilita los cambios, y produce como resultado una
implementacin ms sencilla, permitiendo el desarrollo paralelo de las diferentes partes de un
sistema.
Mdulo lgico: es una funcin definida con un nombre que expresa el propsito de la funcin.
Los procesos definidos en los Diagramas de Flujos de Datos pueden
considerarse mdulos lgicos.
A
B C D
E F
5
Mdulo fsico: implementacin particular de un mdulo lgico. Generalmente est dado en
trminos de un grupo de sentencias en un lenguaje de programacin, al cual
puede hacerse referencia por un nombre.
Los mdulos a menudo invocan a otra mdulos, los cuales invocan a otros mdulos, etc.. Esto
permite formar una jerarqua jefe-subjefe, hasta alcanzar los mdulos de trabajo finales.
Mdulo manejablemente pequeo: una persona competente ser capaz de tomar un listado
del mdulo, leerlo y hacerse mentalmente un cuadro de su funcin interna
mientras decide cmo cambiarlo.
Independencia: aislar la funcin en la menor cantidad de mdulos posibles.
Idealmente las funciones estn contenidas en cajas negras, donde la funcin producir
siempre resultados predecibles a partir de un conjunto de datos que pasen a travs de la
misma.
Los mdulos que componen un sistema no pueden ser completamente independientes unos de
otros o no existira un sistema sino solamente un montn de mdulos aislados.
Los nombres de los mdulos siguen las mismas normas que para proceso: verbo activo y un
objeto nico.
Comunicacin entre mdulos
La estructura es de llamada o invocacin de mdulos. El mdulo de nivel superior invoca a
uno de nivel inferior (representado por una flecha que une al mdulo llamador y el llamado).
Los mdulos pueden intercambiar:
Datos: representado por una flecha con un crculo vaco en un extremo.
Seales: representado por una flecha con un crculo lleno en un extremo.
La tarea del diseador es formar los mdulos y disear sus interconexiones para minimizar la
posibilidad del efecto onda (un cambio en un mdulo repercute en otros mdulos, y as).
Derivacin del modelo fsico a partir de un DFD
Para realizar la transicin desde el flujo de informacin (DFD) a la estructura (DE) se debe
proceder de la siguiente manera:
1. Establecer el tipo de flujo de informacin;
2. Determinar los lmites del flujo;
3. Convertir el DFD en la estructura del programa;
4. Definir la jerarqua de control mediante factorizacin;
5. Refinar la estructura resultante usando medidas y heursticas de diseo.
Similar a una estructura militar. Cada mdulo tiene su propia tarea, que desempea cuando
recibe rdenes superiores; se comunica slo con su jefe superior y con sus subordinados.
La no comunicacin directa entre los mdulos de trabajo de un mismo nivel o en general no
respetando la jerarqua estipulada, es una forma de simplificar el acoplamiento intermodular, y
facilita la comprensin del comportamiento del sistema.
El tipo de flujo de informacin es lo que determina el mtodo de conversin requerido en el
paso 3, y existen dos tipos: flujos de transformacin y flujos de transaccin.
Sistemas centrados en flujos de transformacin
Si tenemos en mente el diagrama de flujo de datos de nivel 0 de un sistema, la informacin
entra y sale en una forma del mundo exterior. Por ejemplo, algunas formas de informacin del
mundo exterior son las teclas pulsadas sobre un teclado de una terminal, los tonos sobre una
lnea telefnica y los dibujos de un monitor grfico de computadora. Tales datos externos
deben ser convertidos a una forma interna adecuada para el procesamiento. La Figura III.4
6
ilustra la evolucin del flujo de datos a lo largo del tiempo. La informacin entra al sistema
mediante caminos que transforman los datos externos a una forma interna y se identifican
como flujo entrante. En el interior del software se produce una transicin. Los datos entrantes
pasan a travs de un centro de transformacin, movindose a lo largo de caminos que
conducen ahora hacia la salida del software. Los datos que se mueven por estos caminos se
llaman flujo saliente. El flujo de datos global ocurre de forma secuencial y sigue uno o unos
pocos caminos directos. Cuando un segmento de un diagrama de flujo de datos exhibe estas
caractersticas, lo que tenemos es un flujo de transformacin.
Figura III. 4 Flujo de Informacin
Un tramo de entrada maneja todas las funciones de entrada,
Un tramo de transformacin toma una entrada correcta y produce un resultado, y
Un tramo de salida maneja toda la salida correspondiente a ese resultado.
Se derivan comnmente de un DFD donde todas las transacciones siguen caminos iguales o
similares.
Sistemas centrados en flujo de transaccin
El modelo fundamental del sistema implica un flujo de transformacin; por lo tanto, todo flujo de
datos se puede clasificar en esa categora. Sin embargo, a menudo, el flujo de informacin est
caracterizado por un nico elemento de datos, denominado transaccin, que desencadena otro
flujo de datos a travs de uno de entre varios caminos. Cuando un DFD toma la forma que
muestra la Figura III.5, lo que tenemos es un flujo de transaccin.
El flujo de transaccin se caracteriza por el movimiento de datos a travs de un camino de
llegada (tambin denominado camino de recepcin) que convierte la informacin del mundo
exterior en una transaccin. Se evala la transaccin y, de acuerdo con su valor, el flujo sigue
por uno de los muchos caminos de accin. El centro de flujo de informacin desde el que
emanan los caminos de accin se denomina centro de transaccin.
Hay que tener en cuenta que en el DFD de un gran sistema, pueden estar presentes los dos
tipos de flujos, de transformacin y de transaccin. Por ejemplo, dentro de un flujo de
transaccin, el flujo de informacin a travs de un camino de accin puede tener caractersticas
de flujo de transformacin.
Representacin
externa
Representacin
interna
I
n
f
o
r
m
a
c
i

n
Tiempo
Flujo de Transformacin
Flujo
entrante
Flujo
saliente
7
Figura III. 5 Flujo de transaccin
Pasaje de DFD a un Diagrama de Estructura (DE) jerrquica
centrada en transformacin
Se determina la forma ms bruta de entrada, y se rastrea a travs del flujo de datos hasta
alcanzar un punto donde no se puede decir que es una entrada. (Entrada)
Se toma la salida final y se rastrea hacia atrs dentro del sistema hasta donde no se pueda
concebir ms como una salida. (Salida)
La porcin del DFD que se encuentra entre el lmite de la entrada y el lmite de la salida es
el centro de transformacin. (Transformacin)
T
Transaccin
Centro de
transaccin
...
Caminos de
accin
...
...
...
...
...
Controlador
principal
Controlador del
flujo de entrada
Controlador del flujo
de transformacin
Controlador del
flujo de salida
8
Figura III. 6 DFD a DE centrado en transformacin
Pasaje de DFD a un Diagrama de Estructura (DE) jerrquica
centrada en transaccin
Se rastrea la forma ms bruta de entrada y se rastrea a travs del flujo de datos hasta
alcanzar un punto donde ingresa a un analizador de la entrada.
Se identifican los diversos caminos (transacciones) que puede tomar la entrada analizada.
Se identifica el proceso unificador de las transacciones
Se crean los mdulos analizador (determina qu tipo de entrada), despachador (determina
el camino a seguir por cada entrada), y unificador (realiza el proceso comn para las
transacciones).
Figura III. 7 DFD a DE centrado en transaccin
La mayora de los sistemas implican combinaciones de las dos estructuras.
DISEO MODULAR EFECTIVO
Los fundamentos de diseo descriptos anteriormente sirven todos para incentivar los diseos
modulares. De hecho, la modularidad se ha convertido en un enfoque aceptado en todas las
disciplinas de ingeniera. Un diseo modular reduce la complejidad, facilita los cambios (un
aspecto crtico de la facilidad de mantenimiento del software) y produce como resultado una
implementacin ms sencilla, permitiendo el desarrollo paralelo de las diferentes partes de un
sistema.
a
b
d
s
p
q
r
Flujo 1
Control de
Transaccin
Camino de
recepcin
b
a
d Distribuidor
C1
q r s
p
9
Tipos de mdulos
Para definir mdulos en una arquitectura de software, se utiliza la abstraccin y el ocultamiento
de informacin. Ambos atributos deben ser traducidos a caractersticas operativas del mdulo,
caracterizadas por el historial de incorporacin, el mecanismo de activacin y el camino de
control.
El historial de incorporacin se refiere al momento en el que se incluye el mdulo en la
descripcin del software en lenguaje fuente. Por ejemplo, un mdulo definido como macro de
tiempo de compilacin es incluido por el compilador, mediante la insercin de su cdigo, al
encontrar una referencia en el cdigo creada por el desarrollador. Un subprograma
convencional (p. ej.: una subrutina o un procedimiento) es incluido mediante la generacin un
cdigo de bifurcacin y enlace.
Existen dos mecanismos de activacin. Convencionalmente, un mdulo es invocado mediante
referencia (p. ej.: una sentencia "de llamada", CALL, RUN). Sin embargo, en las aplicaciones
de tiempo real, un mdulo puede ser invocado mediante una interrupcin; esto es, un suceso
exterior produce una discontinuidad en el procesamiento, que da como resultado el paso del
control a otro mdulo. Los mecanismos de activacin son importantes porque pueden afectar a
la estructura del programa.
El camino de control de un mdulo describe la forma en la que se ejecuta internamente. Los
mdulos convencionales tienen una nica entrada y una nica salida y ejecutan
secuencialmente una tarea. Algunas veces se necesitan caminos de control ms sofisticados.
Por ejemplo, un mdulo puede ser reentrante. Esto es, un mdulo se disea de forma que de
ninguna manera pueda modificarse a s mismo o a las direcciones que referencia localmente.
As, el mdulo puede ser usado para ms de una tarea concurrentemente.
Dentro de una estructura de programa, un mdulo puede ser clasificado como
Un mdulo secuencial que se referencia y se ejecuta sin interrupcin aparente por parte
del software de la aplicacin.
Un mdulo incremental que puede ser interrumpido, antes de que termine, por el
software de la aplicacin y, posteriormente, restablecida su ejecucin en el punto en que
se interrumpi.
Un mdulo paralelo que se ejecuta a la vez que otro mdulo, en entornos de
multiprocesadores concurrentes.
Los mdulos secuenciales son los que se encuentran ms frecuentemente y estn
caracterizados como macros en tiempo de compilacin y como subprogramas convencionales -
subrutinas, funciones o procedimientos. Los mdulos incrementales, denominados
frecuentemente corrutinas, mantienen un puntero de entrada que permite volver a ejecutar el
mdulo desde el punto de interrupcin. Dichos mdulos son extremadamente tiles en
sistemas conducidos por interrupciones. Los mdulos paralelos, denominados algunas veces
conrutinas, se encuentran aplicaciones de clculo de alta velocidad (p. ej.: procesamiento
distribuido) que necesitan dos o ms CPUs trabajando en paralelo. Cuando se utilizan
corrutinas o conrutinas, puede que la jerarqua de control no sea tpica. Las estructuras no
jerrquicas u homlogas requieren unos mtodos de diseo especiales.
Independencia funcional
El concepto de independencia funcional es una derivacin directa del de modularidad y de los
conceptos de abstraccin y ocultamiento de informacin. En conocidos artculos sobre diseo
de software, Parnas y Wirth aluden a las tcnicas de refinamiento que aumentan la
independencia modular. Posteriores artculos de Stevens, Myers y Constantine asentaron el
concepto. La independencia funcional se adquiere desarrollando mdulos con "una clara"
funcin y una "aversin" a una excesiva interaccin con otros mdulos.
Dicho de otra forma, se trata de disear software de forma que cada mdulo se centre en una
subfuncin especfica de los requisitos y tenga una interfaz sencilla, cuando se ve desde otras
partes de la estructura del software.
Es justo preguntar por qu es importante la independencia. El software con modularidad
efectiva, es decir, con mdulos independientes, es fcil de desarrollar porque su funcin puede
ser partida y se simplifican las interfaces (considrense las aplicaciones cuando el desarrollo es
realizado por un equipo). Los mdulos independientes son ms fciles de mantener (y de
probar) debido a que se limitan los efectos secundarios producidos por las modificaciones en el
10
diseo del cdigo, se reduce la propagacin de errores y se fomenta la reutilizacin de los
mdulos. Resumiendo,
la independencia funcional es la clave de un buen diseo y el diseo es la clave de la calidad
del software.
La independencia se mide con dos criterios cualitativos: la cohesin y el acoplamiento.
La cohesin es una medida de la fortaleza funcional relativa de un mdulo.
El acoplamiento es una medida de la interdependencia relativa entre los mdulos.
Cohesin
La cohesin es una extensin del concepto de ocultamiento de informacin. Un mdulo
cohesivo ejecuta una tarea sencilla de un procedimiento de software y requiere poca
interaccin con procedimientos que ejecutan otras partes de un programa. Dicho de forma
sencilla, un mdulo cohesivo slo hace (idealmente) una cosa. La cohesin es la medida en la
cual todas las partes de un mdulo se corresponden entre s.
La cohesin puede presentarse como un "espectro":
Figura III. 8 Espectro de cohesin
Lo deseable siempre es conseguir una gran cohesin, aunque un punto medio del espectro
normalmente es aceptable. La escala de cohesin no es lineal. Es decir, una cohesin baja es
mucho "peor" que una de la mitad del espectro, que, a su vez, es casi tan "buena" como una
gran cohesin.
En la prctica, un diseador no tiene que preocuparse por el grado preciso de cohesin de un
mdulo especfico. En vez de ello, debe comprender el concepto general y evitar los niveles
bajos de cohesin en el diseo de los mdulos.
Cohesin coincidente
Un mdulo que realice un conjunto de tareas que estn dbilmente relacionadas entre s, si es
que lo estn, es coincidentalmente cohesivo.
No puede apreciarse que los elementos del mdulo lleven a cabo ninguna funcin definible. En
general se trata de un conjunto de tareas dbilmente relacionadas entre s.
Ejemplos: cdigo divido en base a una medida de cantidad de lneas.
Cohesin lgica
Un mdulo que realiza tareas que estn relacionadas de forma lgica es lgicamente cohesivo.
En este caso, varias funciones semejantes, pero ligeramente diferentes, estn combinadas
juntas. A menudo requiere una seal de control para indicarle cmo debe ejecutarse. Estos
mdulos son difciles de modificar, debido a que los circuitos lgicos son complejos.
Para resolver esta situacin, los mdulos deben ser remplazados por mdulos de propsitos
especiales a razn de uno por funcin.
Ejemplos: Mdulo que valida todos los tipos de transacciones empleando secciones comunes
de cdigo cuando corresponde, y salteando otras partes cuando no son requeridas; Un mdulo
que produzca toda la salida independientemente de su tipo.
Cohesin temporal
Cuando un mdulo contiene tareas que estn relacionadas por el hecho de que se ejecutan en
el mismo momento, se dice que exhibe cohesin temporal.
Bajo Espectro de cohesin Alto
Coincidental
Lgica
Temporal
Procedimental
Comunicativa Funcional
Secuencial
11
El mdulo presenta varias funciones cuyo nico elemento comn es el de ser ejecutados al
mismo tiempo.
La cambiabilidad mejora aislando cada funcin en su propio mdulo.
Ejemplos: Mdulos de inicializacin, preparacin previa, reiniciacin automtica.
Como ejemplo de baja cohesin, consideremos un mdulo que realice el procesamiento de
errores de un paquete de anlisis de ingeniera. El mdulo se invoca cuando los datos
calculados exceden unos lmites previamente especificados. Realiza las siguientes tareas:
(1) clculo de datos suplementarios basndose en los datos calculados originalmente;
(2) produccin de un informe sobre los errores (con contenido grfico) en la estacin de
trabajo del usuario;
(3) realizacin de todos los clculos que siga solicitando el usuario;
(4) actualizacin de una base de datos;
(5) ayuda en la seleccin de un men para el siguiente procesamiento.
Aunque las tareas anteriores estn un poco relacionadas, cada una es una entidad funcional
independiente que puede ser realizada mejor por un mdulo aparte. La combinacin de
funciones en un nico mdulo slo sirve para que aumente la posibilidad de propagacin de
errores, cuando se hace una modificacin en una de las tareas mencionadas anteriormente.
Los niveles moderados de cohesin estn relativamente cercanos unos a otros en su grado de
independencia modular.
Cohesin de procedimiento
Cuando los elementos de procesamiento de un mdulo estn relacionados y deben ejecutarse
en un orden especfico, existe cohesin procedimental.
Los mdulos han sido derivados de un diagrama de flujo y cada procedimiento del diagrama ha
sido armado en un mdulo.
Dentro del mdulo se ejecutan varias funciones, pero al menos estn relacionadas a travs del
flujo de control entre ellas.
Cohesin de comunicacin
Cuando todos los elementos de procesamiento se concentran sobre un rea de una estructura
de datos, se presenta una cohesin de comunicacin.
Las funciones del mdulo operan todas sobre la misma corriente de datos adems de ser
cohesivas de procedimiento.
Ejemplos: Representar el resultado y grabar registro del diario, Leer sentencia fuente y
eliminar blancos, Calcular solucin e imprimir resultado.
Cohesin funcional
Realiza una y solo una funcin identificable. Los mdulos cohesivos funcionalmente pueden
comnmente describirse a travs de una sola frase, con un verbo activo y un objeto nico.
Una alta cohesin se caracteriza por que el mdulo realiza una tarea procedimental
determinada.
Ejemplos: Calcular la mejor solucin, Validar consulta, Representar Respuesta.
El siguiente extracto proporciona un conjunto de criterios sencillos para establecer el grado de
cohesin (denominada "vinculacin" en esta referencia):
Una tcnica til para determinar si un mdulo est acotado funcionalmente es escribir una frase que
describa la funcin (propsito) del mdulo y luego examinar dicha frase. Puede hacerse la siguiente
prueba:
1. Si la frase resulta ser una sentencia compuesta, contiene una coma o contiene ms de un
verbo, probablemente el mdulo realiza ms de una funcin; por tanto, probablemente tiene
vinculacin secuencial o de comunicacin.
2. Si la frase contiene palabras relativas al tiempo, tales como "primero", "a continuacin",
"entonces", "despus", "cundo, "al comienzo", etc., entonces probablemente el mdulo
tiene una vinculacin secuencial o temporal.
12
3. Si el predicado de la frase no contiene un objeto especfico sencillo a continuacin del
verbo, probablemente el mdulo est acotado lgicamente. Por ejemplo, editar todos los
datos tiene una vinculacin lgica; editar sentencia fuente puede tener vinculacin funcional.
4. Palabras tales como "inicializar", "limpiar", etc., implican vinculacin temporal.
Los mdulos acotados funcionalmente siempre se pueden 'describir en funcin de sus elementos
usando una sentencia compuesta. Pero si no se puede evitar el lenguaje anterior, siendo an una
descripcin completa de la funcin del mdulo, entonces probablemente el mdulo no est acotado
funcionalmente.
Una alternativa, para el mismo fin puede ser:
Escribir una sola oracin comenzando con El propsito total de este mdulo es , y luego
examinar la oracin.
Si la misma no puede ser completada cohesivo coincidentemente.
Si tiene un objetivo plural e incluye la palabra todas cohesivo lgicamente. (Validar todas las
transacciones)
Si emplea palabras que guardan relacin con el tiempo o secuencia (primero, prximo, luego,
despus, de otra manera, comienzo) cohesivo temporal, de procedimiento o de comunicacin.
Si consiste de un solo verbo activo con un objeto no plural cohesivo funcionalmente.
Como ya hemos dicho, no es necesario determinar el nivel preciso de cohesin. En su lugar, lo
importante es intentar conseguir una cohesin alta y saber reconocer la cohesin baja, de
forma que se pueda modificar el diseo del software para que disponga de una mayor
independencia funcional.
Acoplamiento
El acoplamiento es una medida de la interconexin entre los mdulos de una estructura de
programa. Al igual que la cohesin, el acoplamiento puede representarse mediante un
espectro:
Figura III. 9 Espectro de acoplamiento
El acoplamiento depende de la complejidad de las interfaces entre los mdulos, del punto en el
que se hace una entrada o referencia a un mdulo y de los datos que pasan a travs de la
interfaz.
En el diseo de software buscamos el ms bajo acoplamiento posible. La conectividad sencilla
entre mdulos da como resultado un software que es ms fcil de comprender y menos
propenso al "efecto onda" producido cuando los errores aparecen en una posicin y se
propagan a lo largo del sistema.
La Figura III.11 muestra ejemplos de mdulos pertenecientes a una estructura con poco
acoplamiento. Los mdulos 1 y 2 estn subordinados a diferentes mdulos. No estn
relacionados y, por tanto, no existe acoplamiento directo. El mdulo 3 es subordinado del
mdulo 2 y est accesible mediante una lista de argumentos convencionales, a travs de la
cual pasan los datos.
Acoplamiento de datos
Mientras exista una lista de argumentos sencilla (es decir, se pasan datos simples; existe una
correspondencia uno a uno entre elementos), se exhibe un bajo acoplamiento (acoplamiento de
datos en el espectro) en esta porcin de la estructura.
Bajo Espectro de acoplamiento Alto
Sin acoplamiento directo
Acoplamiento de datos
Acoplamiento por estampado
Acoplamiento de control
Externo
Acoplamiento comn
Acoplamiento del contenido
13
Un mdulo le transfiere datos a otro como parte de la invocacin o respuesta. Esta es la forma
ms deseada, ya que representa un acoplamiento mnimo. Se debe buscar la menor
transferencia de datos.
El acoplamiento por pasaje de parmetros es mejor que datos globales.
Figura III. 10 Acoplamiento de datos
Una variacin del acoplamiento de datos, denominado acoplamiento por estampado, se
presenta cuando se pasa una porcin de una estructura de datos (en vez de argumentos
simples) a travs de una interfaz de mdulo.
Figura III. 11 Mdulos con bajo acoplamiento
En niveles moderados, el acoplamiento se caracteriza por el paso de control entre mdulos.
Acoplamiento de control
El acoplamiento de control es muy frecuente en la mayora de los diseos de software y se
ilustra en la Figura III.13. En su forma ms sencilla, el control se pasa mediante un "indicador"
sobre el que se toman las decisiones en un mdulo subordinado o superior; se realiza el pasaje
de seales o variables de control entre mdulos.
Dar Salida a la
Solucin
Dar Formato
a la Solucin
Solucin
Salida con
formato
Obtener
entrada
correcta
Editor
Entrada
bruta
Seal de editar
Sin
Acoplamiento
directo
Mdulo 2
Mdulo 1
Mdulo 4
Mdulo 3
Paso de una estructura
de datos a travs de
una lista de
argumentos
(acoplamiento por
estampado)
Paso de datos a travs
de una lista de
argumentos
(acoplamiento por
estampado)
14
Figura III. 12 Acoplamiento de Control
Se debe mantener al mnimo absoluto necesario el acoplamiento de control. A mayor cantidad
de seales se hace ms complejo el mantenimiento.
Las seales de control transferidas hacia abajo, en el momento de la invocacin, son
indicaciones de que el mdulo invocado no es caja negra; ser ejecutado en forma diferente
dependiendo de la seal de control, esta es una situacin no deseable.
Figura III. 13 Acoplamiento de Control entre mdulos
Los niveles relativamente altos de acoplamiento se producen cuando los mdulos estn ligados
a un entorno externo al software.
Acoplamiento patolgico/externo/interno
Se presenta cuando un mdulo apunta al interior de otro, ya sea para extraer datos, para
transferir el control, o modificar la forma de ejecutar del otro mdulo.
Este tipo de acoplamiento no es visible en los diagramas, y en consecuencia es difcil de
detectar.
Debe evitarse a toda costa.
Por ejemplo, un mdulo que se acopla con dispositivos, formatos y protocolos de comunicacin
especficos.
El acoplamiento externo muchas veces es necesario, pero debe limitarse a un pequeo nmero
de mdulos dentro de una estructura. Tambin se presenta un alto acoplamiento cuando varios
mdulos referencian un rea de datos global. Este tipo de acoplamiento tambin se denomina
acoplamiento comn y se muestra en la Figura III.14.
Mdulo 2
Indicador
Mdulo 1
Mdulo 2
Indicador
Indicador
El acoplamiento de control se
produce cuando el mdulo 1 pasa
datos de control al mdulo 2
15
Los mdulos C, E y N acceden todos a un elemento de datos de un rea de datos global (p. ej.:
un archivo de disco, el COMMON de FORTRAN o un tipo de datos externos en el lenguaje de
programacin C). El mdulo C lee el elemento e invoca a E, quien recalcula y actualiza el
elemento. Supongamos que se produce un error y E actualiza incorrectamente el elemento.
Mucho ms adelante en el procesamiento, el mdulo N lee el elemento, intenta procesarlo y
falla, haciendo que se interrumpa la ejecucin del programa. La causa aparente de la
terminacin es el mdulo N; la causa real, el mdulo E.
El diagnstico de los problemas que aparecen en estructuras con considerable acoplamiento
comn consume mucho tiempo y es difcil. Sin embargo, esto no significa que el uso de datos
globales sea necesariamente malo. Significa que un diseador de software deber ser
consciente de las posibles consecuencias del acoplamiento comn y tener cuidado para
protegerse de ellas.
Figura III. 14 Acoplamiento patolgico
El mayor grado de acoplamiento, el acoplamiento por contenido o patolgico, se produce
cuando un mdulo utiliza informacin de datos o de control contenida dentro de los lmites de
otro mdulo. Secundariamente, el acoplamiento por contenido se produce cuando se realiza
una bifurcacin hacia la mitad de un mdulo. Este modo de acoplamiento puede y debe
evitarse.
Figura III. 15 Acoplamiento patolgico
Los modos de acoplamiento anteriores surgen por decisiones de diseo que se toman en el
desarrollo de la estructura. Sin embargo, durante la codificacin se pueden introducir variantes
A
B C
E D F
Acoplamiento
de contenido
M L
E D F
rea de datos
global
Los mdulos C, E y N exhiben
acoplamiento comn
Entrada Salida
Leer
Contador de
transacciones
TCONT
IF TCONT GT
10000 THEN ...
16
de acoplamiento externo. Por ejemplo, el acoplamiento con el compilador viene dado por su
vinculacin del cdigo fuente con atributos especficos (y frecuentemente no estndar) del
compilador; el acoplamiento con el sistema operativo se produce por la vinculacin del diseo y
del cdigo resultantes con servicios del sistema operativo (SO), lo que puede causar estragos
cuando cambia el SO.
El acoplamiento y cohesin de mdulos estn relacionados.
Un mdulo altamente cohesivo, cuyas partes contribuyan todas a una sola funcin,
probablemente ser dbilmente acoplado a otros mdulos.
Un mdulo pobremente cohesivo, combinacin de partes no relacionadas, probablemente
necesite un alto acoplamiento con otros mdulos.
Resumen
Dado entonces, los modelos de procesos DFD realizados durante el anlisis, aplicando los
criterios (transformacin y transaccin) para transformar estos en Diagramas Estructurados
(DE) se comienza una de las actividades de Diseo, y se comienza a pensar el problema en
una solucin de software.
Por otra parte, en esta transformacin es crucial, tener permanentemente presente los
conceptos de acoplamiento y cohesin, los que ayudan a lograr un buen diseo de software.
Recordando que
el objetivo es lograr el menor nivel de acoplamiento posible y el mayor grado de cohesin
posible.
Bibliografa:
(a) Ingeniera del Software Un Enfoque Prctico Roger S. Pressman - Ed. McGraw-Hill
(1993)
(b) Structured Techniques - The Basis for CASE - James Martin Carma McClure Ed.
Prentice Hall (1985)
(c) Anlisis y Diseo de Sistemas Kenneth E. Kendall y Julie E. Kendall Ed. Prentice-Hall
Hispanoamericana (1991)
(d) Anlisis Estructurado de Sistemas Chris Gane Trish Sarson Ed. El Ateneo (1988)
17