Programación estructurada y programación modular

Definición

En programación un módulo es una porción de un programa de ordenador. De las varias tareas que debe realizar un programa para cumplir con su función u objetivos, un módulo realizará, comúnmente, en dichas (tareas o varias en algún caso).

Particularmente, en el caso de la programación, los módulos suelen estar (no necesariamente) organizados jerárquicamente en niveles, de forma que hay un módulo principal que realiza las llamadas oportunas a los módulos de nivel inferior.

Cuando un módulo es convocado, recibe como entrada los datos proporcionados por otro del mismo o superior nivel, el que ha hecho la llamada; luego realiza su tarea. A su vez este módulo convocado puede llamar a otro u otros módulos de nivel inferior si fuera necesario; cuando ellos finalizan sus tareas, devuelven la salida pertinente al módulo inmediato llamador, en secuencia reversa, finalmente se continúa con la ejecución del módulo principal.

Características de los módulos

Cada uno de los módulos de un programa idealmente debería cumplir las siguientes características:

·   Tamaño relativamente pequeño: Esto facilita aislar el impacto que pueda tener la realización de un cambio en el programa, bien para corregir un error, o bien por rediseño del algoritmo correspondiente.

·        Independencia modular: Cuanto más independientes son los módulos entre sí más fácil y flexiblemente se trabajará con ellos, esto implica que para desarrollar un módulo no es necesario conocer detalles internos de otros módulos. Como consecuencia de la independencia modular un módulo cumplirá:

Características de caja negra, es decir abstracción.

Aislamiento de los detalles mediante encapsulamiento.

La independencia modular mejora el rendimiento humano, pudiendo realizarse programación en equipo y desarrollar módulos paralelamente. También contribuye a la reutilización de software.

  

Ventajas y desventajas de la programación modular

Ventajas:

• Al aplicar la programación modular, un problema complejo debe ser dividido en varios subproblemas más simples, y estos a su vez en otros subproblemas más simples.
• En caso de que un módulo necesite de otro, puede comunicarse con éste mediante una interfaz de comunicación que también debe estar bien definida.
• Es fácil de mantener y modificar
• Es más fácil de escribir y depurar
• Facilidad de controlar es decir descompone un problema en estructuras jerárquicas, de modo que se puede considerar cada estructura desde dos puntos de vista.

Desventajas 

• No se dispone de algoritmos formales de modularidad, por lo que a veces los programadores no tienen claras las ideas de los módulos
• La programación modular requiere más memoria y tiempo de ejecución.

Metodología del diseño

En programación y diseño de algoritmos, el diseño estructurado persigue elaborar algoritmos que cumplan la propiedad de modularidad, para ello, dado un problema que se pretende resolver mediante la elaboración de un programa de ordenador, se busca dividir dicho programa en módulos siguiendo los principios de diseño de descomposición por refinamientos sucesivos, creación de una jerarquía modular y elaboración de módulos Independientes.

Etapas del Diseño estructurado

Descomposición

Para ello se requiere un adecuado análisis de dicho problema, siendo necesario definir primeramente el problema, para lo cual deberá de contener una detallada pero concisa descripción del mismo, un problema bien definido es aquel que lleva implícitas tanto una situación inicial como final clara.

Para ello se requiere un adecuado análisis de dicho problema, siendo necesario definir primeramente el problema, para lo cual deberá de contener una detallada pero concisa descripción del mismo, un problema bien definido es aquel que lleva implícitas tanto una situación inicial como final clara

¿Por qué descomponer un problema en partes? Experimentalmente está comprobado que:

• Un problema complejo cuesta más de resolver que otro más sencillo (de Perogrullo).
• La complejidad de un problema global es mayor que el valor de las complejidades de cada una de sus partes por separado.

Según esto, merece la pena el esfuerzo de dividir un problema grande en subproblemas más pequeños. Si el objetivo es elaborar un programa para resolver dicho problema grande, cada subproblema (menos complejo) podrá ser resuelto por un módulo (subalgoritmo) relativamente fácil de implementar (más que el programa global No dividido). Ahora la cuestión es ¿cómo realizar la descomposición?; realizando un estudio descendente Top-Down que nos lleve desde la concepción del problema (programa o algoritmo) global hasta identificar sus partes (módulos). Esta técnica se repite aplicando una estrategia llamada de refinamiento sucesivo propuesta por el experto en Ciencias de la Computación Niklaus Wirth, que consiste precisamente en volver a aplicar el estudio descendente Top-Down a cada subproblema una y otra vez hasta obtener subproblemas suficientemente pequeños, que puedan ser resueltos por módulos que cumplan, en la medida de lo posible, las características deseables en un módulo en el ámbito de la programación. En palabras del propio Niklaus Wirth:

• En cada paso (del refinamiento), una o varias instrucciones del programa dado, se descomponen en instrucciones más detalladas. Esta descomposición sucesiva o refinamiento de especificaciones termina cuanto todas las instrucciones están expresadas en términos de la computadora usada o del lenguaje de programación.

• Conforme se refinan las tareas, también los datos pueden ser refinados, descompuestos o estructurados, siendo lo natural refinar las especificaciones del programa y de los datos en paralelo.

• Cada paso de refinamiento implica algunas decisiones de diseño. Es importante que el programador sea consciente de los criterios subyacentes (en las decisiones de diseño adoptadas) y de la existencia de soluciones alternativas.

Problema del refinamiento sucesivo

¿Cuándo parar el refinamiento? Un refinamiento excesivo podría dar lugar a un número tan grande de módulos que haría poco práctica la descomposición. Se tendrán en cuenta estos criterios para dejar de descomponer:

• Cuando no haya tareas bien definidas.

• Cuando la interfaz de un módulo sea tan complicada como el propio módulo

Jerarquía de módulos

Ésta es una consecuencia directa de la descomposición del problema mediante refinamientos sucesivos, el resultado será un conjunto de módulos estratificados en capas a modo de pirámide donde en la cima habrá un único módulo que representará al programa global y en los niveles inferiores aparecerán los módulos resultantes de las sucesivas divisiones.

Al final, debe obtenerse una estructura piramidal donde los módulos de los niveles superiores se encargan de las tareas de coordinación, lógica de la aplicación y manipulación de los módulos inferiores; estos otros deberán realizar tareas de cálculo, tratamiento y entrada/salida de información.

Evaluando el diseño

Para evaluar o determinar cómo es de bueno un diseño estructurado se utiliza los conceptos de acoplamiento y cohesión; éstos están muy relacionados entre sí, tanto que difícilmente se puede variar uno sin que eso afecte al otro. También cabe decir que estos conceptos no son medidas que se puedan cuantificar numéricamente, son más bien magnitudes cualitativas. También se tienen en consideración los conceptos de fan-in y fan-out.

Acoplamiento

Se define como el grado de interdependencia que hay entre los distintos módulos de un programa; lo deseable es que esta interdependencia sea lo menor posible, es decir, un bajo acoplamiento. Los niveles de acoplamiento, ordenados de menor (más deseable) a mayor (menos deseable) son:

• Acoplamiento normal: Un módulo llama a otro de un nivel inferior y tan solo intercambian datos (parámetros de entrada/salida). Dentro de este tipo de acoplamiento podemos encontrarnos 3 subtipos, dependiendo de los datos que intercambien los módulos:
• Acoplamiento de datos: Los módulos se comunican mediante parámetros.
• Acoplamiento de marca o por estampado: Los módulos se pasan datos con estructura de registro. No es muy deseable si el módulo receptor sólo requiere parte de los datos que se le pasan.
• Acoplamiento de control: Los datos que se intercambian entre los módulos son controles. Debido a que en este subtipo un módulo controla la ejecución del otro, no es un buen acoplamiento, ya que impide que sean totalmente independientes.
• Acoplamiento Común: Dos módulos acceden a un mismo recurso común, típicamente memoria compartida, una variable global o un fichero. Una variante de este tipo de acoplamiento es el acoplamiento externo:
• Acoplamiento externo.- Los módulos están ligados a componentes externos. Por ejemplo, dispositivos de E/S, protocolos de comunicaciones... etc.
• Acoplamiento de contenido: Ocurre cuando un módulo necesita acceder a una parte de otro módulo.

Cohesión

Se define como la medida de fuerza o relación funcional existente entre las sentencias o grupos de sentencias de un mismo módulo. Un módulo cohesionado ejecutará una única tarea sencilla interactuando muy poco o nada con el resto de módulos del programa. Se persigue que los módulos tengan una alta cohesión.

En el diseño estructurado podemos encontrarnos con los siguientes 7 tipos de cohesión (de la mejor o más deseable a la menos recomendable):

• Cohesión funcional: Los elementos del módulo están relacionados en el desarrollo de una única función.
• Cohesión secuencial: Un módulo realiza distintas tareas en secuencia, de forma que las entradas de cada tarea son las salidas de la tarea anterior. No es una mala cohesión si las tareas implicadas no son muy complejas y requieren pocas líneas de código.
• Cohesión comunicacional: El módulo realiza actividades paralelas usando los mismos datos de entrada y salida. Como en el caso anterior, tampoco se trata de un mal tipo de cohesión si las tareas son relativamente sencillas.
• Cohesión procedimental: El módulo tiene una serie de funciones relacionadas por un procedimiento efectuado por el código (a modo de biblioteca). Es similar a la secuencial, pero puede incluir el paso de controles. Será deseable que las funciones estén relacionadas o realicen tareas dentro del mismo ámbito.
• Cohesión temporal: Los elementos del módulo están implicados en actividades relacionadas con el tiempo.
• Cohesión lógica: Las actividades que realiza el módulo tienen la misma categoría. Esto es, es como si se tuvieran partes independientes dentro del mismo módulo.
• Cohesión casual o coincidente: Los elementos del módulo contribuyen a las actividades relacionándose mutuamente de una manera poco significativa. Este tipo de cohesión viola el principio de independencia y de caja negra de los módulos.

Fan-In y Fan-Out

Además de los dos conceptos anteriores, se deben tener en cuenta el grado de absorción (fan-in) y la diseminación del control (fan-out) de los módulos para garantizar la calidad del diseño.

• Fan-In: También llamado grado de absorción. Es el número de superordinados inmediatos que tiene el módulo en cuestión. Es conveniente maximizar el fan-in durante el proceso de diseño, ya que cada instancia de fan-in múltiple indica que se ha evitado la duplicación de código.
• Fan-Out: También llamado diseminación del control. Es el número de subordinados inmediatos que tiene el módulo en cuestión. Conviene no tener un fan-out ni muy alto ni muy bajo, ya que eso es un posible indicador de un diseño pobre. Si no es posible evitarlo, es preferible un fan-out bajo antes que uno alto.

ACTIVIDADES

a. Glosario

1. Abstracción: El término se refiere al énfasis en el "¿qué hace?" más que en el "¿cómo lo hace?" (Característica de caja negra). El común denominador en la evolución de los lenguajes de programación, desde los clásicos o imperativos hasta los orientados a objetos, ha sido el nivel de abstracción del que cada uno de ellos hace uso.

2. Acoplamiento: Grado de interdependencia entre las unidades de software (módulos, funciones, subrutinas, bibliotecas, etc.) de un sistema informático. El acoplamiento da la idea de lo dependiente que son las unidades de software entre sí, es decir, el grado en que una unidad puede funcionar sin recurrir a otras.

3. Cohesión: hace referencia a la forma en que agrupamos unidades de software (módulos, subrutinas...) en una unidad mayor. Por ejemplo: la forma en que se agrupan funciones en una biblioteca de funciones o la forma en que se agrupan métodos en una clase, etc.

4. Cuantificar: Calcular el número de unidades, tamaño o proporción de una cosa, especialmente por medio de números.

5. Depurar: Depurar consiste en eliminar impurezas, pero en jerga informática es un vocablo utilizado en el trabajo de programación, que consiste en revisar y analizar si la sintaxis de un programa creado es correcta y/o genera errores al ejecutarlo.

6. Encapsulamiento: es un mecanismo que consiste en organizar datos y métodos de una estructura, conciliando el modo en que el objeto se implementa, es decir, evitando el acceso a datos por cualquier otro medio distinto a los especificados. Por lo tanto, la encapsulación garantiza la integridad de los datos que contiene un objeto.

7. Estructura Jerárquica: medida que fueron creciendo las necesidades de los usuarios y se perfeccionaron los sistemas, se hizo necesaria una mayor organización del software, del sistema operativo, donde una parte del sistema contenía subpartes y esto organizado en forma de niveles.

Se dividió el sistema operativo en pequeñas partes, de tal forma que cada una de ellas estuviera perfectamente definida y con un claro interface con el resto de elementos.

Se constituyó una estructura jerárquica o de niveles en los sistemas operativos, el primero de los cuales fue denominado THE (Technische Hogeschool, Eindhoven), de Dijkstra, que se utilizó con fines didácticos (Ver Fig. 3). Se puede pensar también en estos sistemas como si fueran `multicapa'. Multics y Unix caen en esa categoría.

8. Estructura piramidal:  se trata de construir un sistema en el que una persona dé algo a otras personas a cambio de la promesa de recibir en el futuro más de lo que ha dado, con lo cual se da la impresión de que se está haciendo una inversión. La palabra "pirámide" hace referencia a que, para que el sistema sea o parezca sostenible, los beneficios que obtiene una persona deben venir de varias personas en un "nivel" inferior.

9. Interfaz: sirve para señalar a la conexión que se da de manera física y a nivel de utilidad entre dispositivos o sistemas.

10. Metodología de programación: es un conjunto o sistema de métodos, principios y reglas que permiten enfrentar de manera sistemática el desarrollo de un programa que resuelve un problema algorítmico.

11. Modularidad: en programación modular y más específicamente en programación orientada a objetos, la propiedad que permite subdividir una aplicación en partes más pequeñas (llamadas módulos), cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes.

12. Modulo: un módulo es una porción de un programa de ordenador. De las varias tareas que debe realizar un programa para cumplir con su función u objetivos, un módulo realizará, comúnmente, una de dichas tareas (o varias, en algún caso).

b. Material multimedia