1.

descomposicin modular

2. Modularidad
3. El aporte ms importante que hizo el diseo estructurado fue la idea de que, para resolver un problema complejo de desarrollo de software, conviene separarlo en partes ms pequeas, que se puedan disear, desarrollar, probar y modificar, de manera sencilla y lo ms independientemente posible del resto de la aplicacin. Esas partes, cuando se quiere usar un nombre genrico, habitualmente se denominan mdulos. De all que otro nombre para la programacin estructurada, luego cado en desuso, fue programacin modular. El diseo estructurado, al plantear la separacin del sistema en mdulos, se bas en las propias funciones del sistema. Esto es, los mdulos de la programacin estructurada seran los procedimientos y funciones. Por lo tanto, al modularizar, lo que hacamos era tomar nuestra solucin del problema, y separarla en partes. Detngase aqu y asegrese de que entiende lo que le digo: en programacin estructurada modularizamos la solucin, el cmo del desarrollo. En el diseo orientado a objetos, en cambio, la modularizacin esencial se da a nivel de clases, que no son funciones del sistema, sino (al menos en una primera aproximacin) entidades del dominio del problema. Por lo tanto (y asegrese de entender tambin esto), en el anlisis y diseo orientados a objetos, no modularizamos la solucin, sino primero el problema (en el anlisis) y luego, partiendo de esas clases conceptuales, del dominio del problema, modularizamos la solucin (diseo). Bertrand Meyer tiene una frase bastante acertada al hablar de cmo obtener los mdulos de la orientacin a objetos: no pregunte qu hace el sistema, sino a quin se lo hace. Por supuesto, la orientacin a objetos tambin tiene mdulos funcionales, que seran los mtodos u operaciones de las clases, pero estos tienen una importancia menor respecto del mdulo por excelencia, que es la clase. Finalmente, en el diseo orientado a objetos, suele aparecer otro tipo de mdulo ms, el paquete, de escasa relevancia semntica, pero importante para agrupar clases en el diseo de aplicaciones medianas.

Los pasos a seguir son: 1. Identificar los mdulos. 2. Describir cada mdulo. 3. Describir las relaciones entre mdulos. Una descomposicin modular debe poseer ciertas cualidades mnimas para que se pueda considerar suficiente validad. ( tarea : investigar de que se trata cada una de las siguientes cualidades) 1. Independencia funcional 2. Acoplamiento 3. Cohesin 4. Comprensibilidad 5. Adaptabilidad 4. Que es cohesin?

Cohesin
La cohesin tiene que ver con que cada mdulo del sistema se refiera a un nico proceso o entidad. A mayor cohesin, mejor: el mdulo en cuestin ser ms sencillo de disear, programar, probar y mantener. En el diseo estructurado, se logra alta cohesin cuando cada mdulo (funcin o procedimiento) realiza una nica tarea trabajando sobre una sola estructura de datos. Un test que se suele hacer a los mdulos funcionales para ver si son cohesivos es analizar que puedan describirse con una oracin simple, con un solo verbo activo. Si hay ms de un verbo activo en la descripcin del procedimiento o funcin, deberamos analizar su particin en ms de un mdulo, y volver a hacer el test. En el diseo orientado a objetos las cosas son ms complejas. Como dijimos, hay tres tipos de mdulos: clases, mtodos y paquetes. Con los mtodos, podemos adoptar las mismas definiciones y recetas que para los procedimientos y funciones del diseo estructurado. Qu ocurrira con los otros dos? Las clases tendrn alta cohesin cuando se refieran a una nica entidad. Podemos garantizar una fuerte cohesin disminuyendo al mnimo las responsabilidades de una clase: si una clase tiene muchas responsabilidades probablemente haya que dividirla en dos o ms. Y el test a aplicar sera ver si podemos describir a la clase con una

oracin simple que tenga un nico sustantivo en el sujeto. Si la clase estuviera representando alguna operacin (por la aplicacin de algn patrn de diseo, por ejemplo), tambin habra que tratar de sustantivarla y aplicarle la prueba para ver si es cohesiva. Una clase con alta cohesin suele cumplir el principio de nica responsabilidad. En los paquetes no es usual analizar cohesin. Sin embargo, nadie nos impide aplicarle los mismos tests que a las clases. Sin embargo, lo crucial en los paquetes es el acoplamiento.

5. Que es acoplamiento?

Acoplamiento
El acoplamiento mide el grado de relacionamiento de un mdulo con los dems. A menor acoplamiento, mejor: el mdulo en cuestin ser ms sencillo de disear, programar, probar y mantener. En el diseo estructurado, se logra bajo acoplamiento reduciendo las interacciones entre procedimientos y funciones, reduciendo la cantidad y complejidad de los parmetros y disminuyendo al mnimo los parmetros por referencia y los efectos colaterales. De nuevo, el diseo orientado a objetos nos complica las cosas con sus tres tipos de mdulos. A los mtodos, como pas con la cohesin, podemos analizarlos con los mismos criterios que a los mdulos del diseo estructurado. Una clase, en cambio, tendr bajo acoplamiento cuando tenga la menor dependencia posible de otras clases. Esta dependencia significa que si bien puede haber muchas clases que dependen de una debera haber pocas dependencias hacia otras clases desde una sola. Las dependencias que importan son, de mayor a menor: generalizacin/herencia, composicin, asociacin y dependencia dbil. Para visualizar estas cuestiones, los diagramas de clases son herramientas fundamentales. Y los paquetes? Un paquete debe cumplir con estos mismos requisitos, en el sentido de que debe tener vinculaciones mnimas con otros paquetes. Decimos que hay dependencia entre paquetes

cuando hay clases de un paquete que dependen de clases de otro paquete, sea por herencia, asociacin o simple dependencia dbil. En este caso, podemos ayudarnos con un diagrama de paquetes, que debido a que nos muestra dependencias entre conjuntos de clases, nos sirve para eliminar problemas de acoplamiento.

6. Que es independencia funcional? 7. Ejemplo de un diagrama de flujos de datos de procesos? 8. Ejemplos de descomposicin modular? 9. Que es comprensibilidad y adaptabilidad?