Descomposición modular
Introducción
La arquitectura del software, en su forma más sencilla, es la estructura de organización de los componentes de un programa (módulos), la forma en la que éstos interactúan y la estructura de datos que utilizan. Sin embargo, en un sentido más amplio, los componentes se generalizan para que representen los elementos de un sistema grande y sus interacciones.
Una meta del diseño del software es obtener una aproximación arquitectónica de un sistema.
Ésta sirve como estructura a partir de la cual se realizan las actividades de diseño más detalladas. Un conjunto de patrones arquitectónicos permite que el ingeniero de software resuelva problemas de diseño comunes.
Modularidad
La modularidad es la manifestación más común de la división de problemas. El software se divide en componentes con nombres distintos y abordables por separado, en ocasiones llamados módulos, que se integran para satisfacer los requerimientos del problema.
El software monolítico (un programa grande compuesto de un solo módulo) no es fácil de entender para un ingeniero de software. El número de trayectorias de control, alcance de referencia, número de variables y complejidad general haría que comprenderlo fuera casi imposible. En función de las circunstancias, el diseño debe descomponerse en muchos módulos con la esperanza de que sea más fácil entenderlos y, en consecuencia, reducir el costo requerido para elaborar el software.
Debe hacerse un diseño (y el programa resultante) con módulos, de manera que el desarrollo pueda planearse con más facilidad, que sea posible definir y desarrollar los incrementos del software, que los cambios se realicen con más facilidad, que las pruebas y la depuración se efectúen con mayor eficiencia y que el mantenimiento a largo plazo se lleve a cabo sin efectos colaterales de importancia.
Descomposición Modular
Es el proceso que consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea representa una actividad completa y se codifica de manera independiente. Facilita el diseño descendente del problema, centrándonos cada vez en la resolución de subproblemas de magnitud inferior.
A la resolución de cada uno de estos subproblemas de complejidad inferior se denomina refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y depurados independientemente, y a continuación se combinan uno a uno con otros módulos.
Pasos o Etapas:
- Identificar los módulos.
- Describir cada módulo.
- Describir las relaciones entre los módulos.
Estrategias para la descomposición modular:
Después de elegir la organización del sistema en su totalidad, debemos decir como descomponer los subsistemas en módulos.
No existe una distinción rígida entre la organización del sistema y la descomposición modular. Sin embargo, los componentes de los módulos son normalmente más pequeños, lo que permite usar estilos alternativos de descomposición.
Los módulos se descomponen normalmente de varios componentes del sistema simples. Hay dos estrategias para descomponer un subsistema en módulos:
- Descomposición orientada a objetos: Donde se descompone un sistema en un conjunto de objetos que se comunican.
- Descomposición orientada a flujos de funciones: Donde se descompone el sistema en módulos funcionales que aceptan datos y los transforman en datos de salida.
Características:
>> Ocultamiento de la información
El principio del ocultamiento de información sugiere que los módulos se “caractericen por decisiones de diseño que se oculten (cada una) de las demás”. En otras palabras, deben especificarse y diseñarse módulos, de forma que la información (algoritmos y datos) contenida en un módulo sea inaccesible para los que no necesiten de ella.
El ocultamiento implica que la modularidad efectiva se logra definiendo un conjunto de módulos independientes que intercambien sólo aquella información necesaria para lograr la función del software. La abstracción ayuda a definir las entidades de procedimiento (o informativas) que constituyen el software. El ocultamiento define y hace cumplir las restricciones de acceso tanto a los detalles de procedimiento como a cualquier estructura de datos local que utilice el módulo.
El uso del ocultamiento de información como criterio de diseño para los sistemas modulares proporciona los máximos beneficios cuando se requiere hacer modificaciones durante las pruebas, y más adelante, al dar mantenimiento al software. Debido a que la mayoría de los datos y detalles del procedimiento quedan ocultos para otras partes del software, es menos probable que los errores inadvertidos introducidos durante la modificación se propaguen a distintos sitios dentro del software.
>> Independencia funcional
La independencia funcional se logra desarrollando módulos con funciones “miopes” que tengan “aversión” a la interacción excesiva con otros módulos. Dicho de otro modo, debe diseñarse software de manera que cada módulo resuelva un subconjunto específico de requerimientos y tenga una interfaz sencilla cuando se vea desde otras partes de la estructura del programa.
Es lógico preguntar por qué es importante la independencia.
El software con modularidad eficaz, es decir, con módulos independientes, es más fácil de desarrollar porque su función se subdivide y las interfaces se simplifican (cuando el desarrollo es efectuado por un equipo hay que considerar las ramificaciones).
Los módulos independientes son más fáciles de mantener (y probar) debido a que los efectos secundarios causados por el diseño o por la modificación del código son limitados, se reduce la propagación del error y es posible obtener módulos reutilizables. En resumen, la independencia funcional es una clave para el buen diseño y éste es la clave de la calidad del software.
La independencia se evalúa con el uso de dos criterios cualitativos: la cohesión y el acoplamiento.
~ Cohesión: Es una extensión natural del concepto de ocultamiento de información. Un módulo cohesivo ejecuta una sola tarea, por lo que requiere interactuar poco con otros componentes en otras partes del programa. En pocas palabras, un módulo cohesivo debe (idealmente) hacer sólo una cosa.
Aunque siempre debe tratarse de lograr mucha cohesión (por ejemplo, una sola tarea), con frecuencia es necesario y aconsejable hacer que un componente de software realice funciones múltiples. Sin embargo, para lograr un buen diseño hay que evitar los componentes “esquizofrénicos” (módulos que llevan a cabo funciones no relacionadas).
~ Acoplamiento: Es una indicación de la interconexión entre módulos en una estructura de software, y depende de la complejidad de la interfaz entre módulos, del grado en el que se entra o se hace referencia a un módulo y de qué datos pasan a través de la interfaz. En el diseño de software, debe buscarse el mínimo acoplamiento posible.
El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de conexión y la complejidad de las interfaces:
Fuerte
- Por contenido, cuando desde un módulo se puede cambiar datos locales de otro.
- Común, se emplea una zona común de datos a la que tienen acceso varios módulos.
Moderado
De control, la zona común es un dispositivo externo al que están ligados los módulos, esto implica que un cambio en el formato de datos los afecta a todos.
Débil
- De datos, viene dado por los datos que intercambian los módulos. Es el mejor.
- Sin acoplamiento directo, es el acoplamiento que no existe.
~ Comprensibilidad: Para facilitar los cambios, el mantenimiento y la reutilización de módulos es necesario que cada uno sea comprensible de forma aislada.
Para ello es bueno que posea independencia funcional, pero además es deseable:
- Identificación, el nombre debe ser adecuado y descriptivo.
- Documentación, debe aclarar todos los detalles de diseño e implementación que no queden de manifiesto en el propio código.
~ Adaptabilidad: La adaptación de un sistema resulta más difícil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesión, y cuando el diseño es poco comprensible.
Otros factores para facilitar la adaptabilidad:
ð Previsión: Es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en módulos independientes, de manera que su modificación afecte al menor número de módulos posibles.
ð Accesibilidad: Debe resultar sencillo el acceso a los documentos de especificación, diseño, e implementación para obtener un conocimiento suficiente del sistema antes de proceder a su adaptación.
ð Consistencia: Después de cualquier adaptación se debe mantener la consistencia del sistema, incluidos los documentos afectados.
No hay comentarios.:
Publicar un comentario