PDF de programación - Programación Modular

Departamento de Informática | Universidad de Valladolid

Programación II (I.T.I. Gestión)

Programación Modular

Félix Prieto
Esperanza Manso

Curso 2009/10

Programación II (I.T.I. Gestión)

Definiciones (y II)

Programación II (I.T.I. Gestión)

Definiciones

Modularidad 1

Modularidad es el atributo individual del software que
permite a un programa ser intelectualmente
manejable. Myers
Llamaremos módulo a un conjunto de sentencias de
un programa que:

Están físicamente unidas
Están físicamente delimitadas con respecto al resto
del programa
Tienen estructura o función bien delimitada
Son referenciables mediante un nombre
Respetan el principio de ocultación de información

Principio de ocultación de información

Modularidad 2

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Bibliotecas

Departamento de Informática

FÉLiX 
Modularidad 3

Ventajas del uso de módulos

Facilidad de construcción
Facilidad de prueba y
corrección
Facilidad de comprensión
Facilidad de modificación
Diagrama de estructura modu-
lar

Sin orden de ejecución
Sin código
Con cierta especificación

Permiten:

Compilar por separado
Evitar repeticiones de código
Aumentar la fiabilidad

Pero:

Las modificaciones pueden ser complejas
La fiabilidad puede bajar
Es dificil medir el ahorro conseguido

Debemos establecer criterios de calidad:

Tamaño razonable
Máxima cohesión
Mínimo acoplamiento
Guías adicionales de diseño

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Cohesión

Departamento de Informática

FÉLiX 
Modularidad 4

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 5

Cohesión funcional

Llamamos cohesión de un módulo al tipo de relación
que se establece entre las actividades del mismo
El nivel de cohesión del sistema es el del peor de sus
módulos
Debemos aumentarlo para mejorar...

comprensión
mantenimiento
reutilización

Pero no es razonable aspirar a que un sistema tenga
un grado de cohesión máxima.

Una única actividad simple y
bien especificada

Simple no quiere decir fácil
La simplicidad tiene que ver
con el punto de vista del
programador
La función matemática es el
paradigma de actividad
bien especificada
Ojo con las
especificaciones
demasiado generales:
Actividades iniciales del
programa

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 6

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 7

Cohesión secuencial

Cohesión comunicacional

Varias actividades, la salida
de una es entrada de la
siguiente

Menor probabilidad de
reutilizar el módulo
Peligro de compartir código
entre las tareas que lo
forman

Factorizar cuando las tareas
sean «suficientemente
grandes»

Varias actividades que
comparten la misma entrada
y/o la misma salida

La probabilidad de reutilizar
el módulo es ya mínima
Las actividades tienen muy
poca relación entre si
Compartir código entre las
tareas dificultará su
posterior mantenimiento

Empieza a ser muy
recomendable factorizar el
módulo

Universidad de Valladolid

Departamento de Informática

FÉLiX 

Universidad de Valladolid

Departamento de Informática

FÉLiX 

Módulo AMódulo DMódulo BMódulo CdatobanderaxyzCalculaSueldoNetodescuentosueldo_brutosueldo_netoreg_validoreg_formobtener_reg_validoregistrovalidarregistroleerniareg_notasniaobtener_regs_alumnoobtenermatrículareg_matrículaobtenernotas Programación II (I.T.I. Gestión)

Cohesión procedural

Modularidad 8

Programación II (I.T.I. Gestión)

Modularidad 9

Cohesión temporal

Actividades diversas que
ocurren en determinada
secuencia

Las actividades tienen
menos relación entre ellas
Pero es posible compartir
código
El mantenimiento será más
difícil

Nivel de cohesión malo. El
módulo debe ser factorizado

Actividades diversas que
ocurren al tiempo

Surge de la «necesidad» de
modularizar
Dificulta el mantenimiento
No facilita la comprensión
del sistema

Nivel de cohesión muy malo.
El módulo debe ser
factorizado

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Cohesión logica

Departamento de Informática

FÉLiX 
Modularidad 10

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 11

Cohesión coincidente

Actividades de la misma
categoría

Puede parecer buena idea,
pero. . .
Dificulta el mantenimiento y
la comprensión
Aumenta el acoplamiento
Nivel de cohesión pésimo. El
módulo debe ser factorizado

No se nos ocurre porqué
estas actividades están el el
mismo módulo

Universidad de Valladolid
Programación II (I.T.I. Gestión)

¿Cómo clasificar?

Departamento de Informática

FÉLiX 
Modularidad 12

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 13

¿Cómo clasificar? (y II)

A partir de la información disponible sobre el módulo

Nombre, especificación,. . .
¿Qué hará «razonablemente» el módulo?
¿Tiene código?

Cuando todas las actividades se relacionan por los
mismos criterios elegimos el mejor
Cuando las actividades se relacionan por diferentes
criterios elegimos el peor

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Acoplamiento

Departamento de Informática

FÉLiX 
Modularidad 14

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 15

Bases para reducir el acoplamiento

Llamamos acoplamiento entre dos módulos al grado
de dependencia que existe entre ellos
El nivel de acoplamiento del sistema es el peor entre
los existentes entre sus módulos
Debemos reducirlo para facilitar...

comprensión
mantenimiento
reutilización

Pero no podemos aspirar a que un sistema tenga
grado de acoplamiento cero.

Podemos reducir el acoplamiento si:
Eliminamos relaciones innecesarias
Reducimos el número de relaciones necesarias
Reducimos la «firmeza» de las relaciones necesarias

Preferimos conexiones. . .

estrechas (con pocos argumentos)
directas (comprensibles sin información adicional)
locales (información presente en la llamada)
obvias («forma» que esperan otros programadores)
flexibles (aplicando «indirección»)

El acoplamiento se mide desde una perspectiva
humana.

Universidad de Valladolid

Departamento de Informática

FÉLiX 

Universidad de Valladolid

Departamento de Informática

FÉLiX 

escribirregistroleerregistroeof?asignarregistromáximoregistroregistroescribir_leer_reginicializar ficherosarchivo1banderaarchivo2archivo1archivo2abrir ficherossubprograma1984Relacionadaspor...UnafunciónImporta lasecuenciaImporta lasecuencianosinosinosicontroldatosNingunanosiMismotipoCoincidenteLógicaTemporalProceduralComunicacionalSecuencialFuncional Programación II (I.T.I. Gestión)

Tipos de acoplamiento

Modularidad 16

Programación II (I.T.I. Gestión)

Modularidad 17

Acoplamiento minimal de datos

Minimal o normal Llamada «normal» a una función o
procedimiento.

de datos Todos los argumentos son datos

simples Todos los datos son simples
por estructura Alguno de los datos es estructurado

de control Alguna bandera de control entre los
argumentos
Híbrido Algún dato actúa como bandera de control

Global Utiliza zonas comunes de memoria
Patológico Acceso directo entre bloques de código

Evitar datos innecesarios
Evitar estructuras
innecesarias
Evitar información
innecesaria
Evitar datos errantes

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

Acoplamiento minimal de control

FÉLiX 
Modularidad 18

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 19

Acoplamiento híbrido

Mejor descripciones que
órdenes
Evitar órdenes
ascencentes
Ciertas banderas son
imprescindibles
No son banderas si
procesamos datos binarios

Una «buena» idea: Si el NIA es par para hombres e
impar para mujeres me ahorro un campo del registro

¿Para qué sirve ahorrar un campo en un registro?

Una idea «mejor»: Los NIA del 1 al 10000 para alumnos
de Ciencias, del 10001 al 20000 para Medicina,. . .

¿Qué pasa con el alumno 10001 matriculado en
Ciencias?
¿Qué ocurrió el 1 de enero de 2000?
¿Qué ocurrirá el 19 de enero de 2038?

El acoplamiento híbrido sólo es justificable cuando
supone un ahorro esencial de recursos escasos
Aún en ese caso resulta peligroso y debe ser
convenientemente documentado

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

Acoplamiento Global y Patológico

FÉLiX 
Modularidad 20

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 21

Criterios adicionales

Dos módulos se acoplan globalmente si utilizan zonas
de datos comunes

El nivel de acoplamiento crece porque la
dependencia entre módulos no es explícita
Los sistemas se vuelven más propensos a errores
Los sistemas se vuelven más difíciles de comprender,
mantener y reutilizar

Dos módulos se acoplan de modo patológico si uno
de ellos accede de algún modo a los datos internos
o el código del otro

Conduce a sistemas inmanejables

Abanico de entrada
Abanico de salida
Ámbito de aplicación
División de las decisiones
Tratamiento de errores
Balanceado del sistema
Tamaño de los módulos
Duplicación de código
. . .

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 22

Universidad de Valladolid
Programación II (I.T.I. Gestión)

Departamento de Informática

FÉLiX 
Modularidad 23

Un problema frecuente

¿Porqué no reutilizamos software?

«Dado un elemento ‘x’ de algún tipo, y un
conjunto ‘t’ de elementos del mismo tipo, se trata
de construir un programa buscar que determine
si ‘x’ está o no en ‘t’»

¿Cuántas veces hemos resuelto este problema?

No conocemos los elementos reutilizables
Es demasiado caro
Es inaccesible
Reservas psicológicas
Herramientas inadecuadas
Noción inadecuada de módulo

Universidad de Valladolid

Departamento de Informática

FÉLiX 

Univ