En la programación estructurada los datos y las funciones que los manejan se
definen
separados.
La programación estructurada no ofrece garantías para abordar proyectos de gran
tamaño, en cuyo caso es más recomendable emplear programación orientada a objetos.
1.3.2.
Programación modular
La programación estructurada establece unas directrices base para realizar un
código de calidad
y facilitar el mantenimiento.Aun así, no tiene en cuenta que el código puede crecer
hasta llegar
a complicar mucho el desarrollo.
La programaáón modular propone como solución la descomposición del problema en sub-
problemas de menor tamaño, los cuales serán descompuestos sucesivamente en otros de
menor
tamaño hasta que el resultado de dichas descomposiciones permita obtener problemas
fáciles
de resolver. A esta técnica de resolución de problemas se le denomina divide y
vencerás y permite
poner en práctica un proceso de desarrollo software top-down.
Figura 1.2
Top-down.
Cada bloque de código que se ocupará de resolver un problema de menor tamaño se de-
nomina módulo o subprograma, y estará compuesto por un conjunto de sentencias
físicamente
unidas y delimitadas. Dicho módulo será referenciado por un nombre y podrá hacer
uso de
otros módulos. La comunicación entre módulos se realizará a través de interfaces de
comuni-
cación claramente definidas.
Los elementos empleados para llevar a cabo la modularización pueden ser muy
distintos
dependiendo del nivel de abstracción:
CAPÍTULO 1
INTRODUCCIÓN A LA PROGRAMACIÓN
1.
2.
A un alto nivel serán las unidades, en diseños estructurados, y los paquetes y
librerías, en
diseños orientados a objetos.
A más bajo nivel serán los procedimientos y las funciones, en diseños
estructurados, y las
clases con sus correspondientes métodos, en diseños orientados a objetos.
Para llevar a cabo una correcta modularización del programa, es necesario realizar
un diseño
de calidad que tenga en cuenta los siguientes criterios:
• El módulo debe tener un único punto de entrada y un único punto de salida.
• Cada módulo debe realizar una única función bien definida.
• Cada módulo debe comportarse como una caja negra, de manera que dependa única-
mente de las entradas.
• Módulos trazables en una pantalla (tamaño ideal 30-50 líneas de código por
módulo).
• Máxima cohesión y mínimo acoplamiento. Ambos criterios están relacionados entre
sí de
manera que, a mayor cohesión en los módulos, menor será el acoplamiento entre
ellos.
A) Cohesión
Se denomina cohesión de un módulo al nivel de relación existente entre los
elementos soft-
ware contenidos en él, entendiéndose como elementos software las instrucciones,
definiciones
de datos o las llamadas a otros módulos.
Existen diferentes tipos de cohesión:
1.
2.
3.
Cohesión funcional: los elementos del módulo contribuyen a la realización de una
única
tarea. Dicho de otra manera, cada elemento es una parte integral de la estructura
del
módulo. El módulo se representa mediante un identificador simple. Por ejemplo: mó-
dulos matemáticos suma, seno, potencia ...
Cohesión secuencial: se da cuando el módulo realiza varias tareas según una
secuencia
que establece que la salida de una actividad es la entrada necesaria de la
siguiente.
Por ejemplo:
Progresivamente el módulo se ocupará de buscar información a
partir de un dato de entrada y, con ella, generar un informe formateado
que devolverá como dato de salida. Podrían encadenarse más acciones.
Figura 1.3
Cohesión secuencial.
Buscar datos
Generar informe
Cohesion comunicacional: contiene actividades paralelas (sin orden) que comparten
los
mismos datos (de entrada o salida). Se recomienda su descomposición en módulos in-
dependientes de cohesión funcional. Por ejemplo:
El módulo se ocupará de buscar información a partir de un dato
de entrada y retornará como salida información de diverso tipo. El
orden de las actividades no es relevante.
Figura 1.4
Cohesión comunicacional.
Obtener datos
CAPÍTULO 1
PROGRAMACIÓN
4.
5.
Cohesión procedural: los elementos realizan diferentes actividades posiblemente no
rela-
cionadas entre sí. También es posible que no exista relación alguna entre los datos
de
entrada y de la salida de los módulos. El control fluye de una actividad a la
siguiente.
Por ejemplo:
e
·c;
:B
¡¡ 5: 1
o
" -~
'º
u
Eliminar libro
Obtener listado socios
El módulo eliminará del sistema los datos relativos al libro
cuyo código recibe como dato de entrada; posteriormente retor-
nará como datos de salida un listado de los socios de la biblioteca.
Figura 1.5
Cohesión procedural.
Cohesión temporal: los elementos están implicados en la realización de actividades
rela-
cionadas por el momento en el cual se llevan a cabo. Ejemplos típicos son los
módulos
de inicialización y finalización de sistema (arrancar sistema, apagar sistema,
resetear sis-
tema, inicializar sistema ... ). Es posible que no manejen ningún dato de entrada o
salida.
6.
7.
Cohesión lógica: los elementos están destinados a que realicen actividades de una
misma
categoría general, pero la selección de la actividad concreta tiene lugar desde
fuera del
módulo. Por ejemplo:
2
e
..o
"'
u
11
Realizar pago
El módulo se encargará de efectuar un pago que podrá reali-
zarse en efectivo o por transferencia ( el medio de pago se selec-
cionará desde fuera del módulo).
Figura 1.6
Cohesión lógica.
Cohesión casual: los elementos no guardan ninguna relación observable y son fruto
de
una organización caótica. Por ejemplo:
Dentro del módulo se realizarán tareas de diverso tipo pero
sin relación alguna. La selección de la tarea en cuestión se realiza
mediante un flag creado para tal efecto. Algunas tareas pueden
devolver datos mientras que otras no.
Cajón de sastre
Figura 1.7
Cohesión casual.
Aunque siempre se tiende a pensar que, a mayor cohesión, mejor será el diseño de un
programa, hay que tener en cuenta que no todos los tipos de cohesión son deseables.
En la
siguiente escala se pueden apreciar los diferentes tipos de cohesión y cómo estos
afectan al
mantenimiento.
(APfTULO 1
INTRODUCCIÓN A LA PROGRAMACIÓN
Cohesión fuerte
(favorece el mantenimiento)
t
Cohesión débil
(complica el mantenimiento)
• Cohesión funcional
• Cohesión secuencial
• Cohesión comunicacional
• Cohesión procedural
• Cohesión temporal
• Cohesión lógica
• Cohesión casual
}
l
Deseable
No deseable
Figura 1.8
Escala de cohesión por Stevens, Myers, Constantine y Yourdon.
Mediante el siguiente árbol de cohesión se podrá identificar el tipo de cohesión
ante el que
un programador puede encontrarse.
