29-9-2012

Jonatán Sánchez Cruz N° 09161287 Catedrático: Castañón Olguín Eduardo

Materia: Ing. software

INSTITUTO

TECNOLÓGICO

DE OAXACA

ARQUITECTURAS DE SOFTWARE - CAPACIDAD

MODULAR

Ing. Sistemas Computacionales

1

CAPACIDAD MODULAR

Capacidad de descomposición modular

Si un método de diseño proporciona un mecanismo sistemático para descomponer el

problema en subproblemas, reducirá la complejidad de todo el problema, consiguiendo de

esta manera una solución modular efectiva.

Capacidad de empleo de componentes modulares

Si un método de diseño permite ensamblar los componentes de diseño (reusables)

existentes en un sistema nuevo, producirá una solución modular que no inventa nada ya

inventado.

Capacidad de comprensión modular

Si un módulo se puede comprender como una unidad autónoma (sin referencias a

otros módulos) será más fácil de construir y de cambiar.

Continuidad modular

Si pequeños cambios en los requisitos del sistema provocan cambios en los módulos

individuales, en vez de cambios generalizados en el sistema, se minimizará el impacto de

los efectos secundarios de los cambios.

Protección modular

Si dentro de un módulo se produce una condición aberrante y sus efectos se limitan

a ese módulo, se minimizará el impacto de los efectos secundarios inducidos por los

errores.

Finalmente, es importante destacar que un sistema se puede diseñar modularmente,

incluso aunque su implementación deba ser «monolítica». Existen situaciones (por ejemplo,

software en tiempo real, software empotrado) en donde no es admisible que los

2

subprogramas introduzcan sobrecargas de memoria y de velocidad por mínimos que sean

(por ejemplo, subrutinas, procedimientos). En tales situaciones el software podrá y deberá

diseñarse con modularidad como filosofía predominante.

El código se puede desarrollar «en línea». Aunque el código fuente del programa

puede no tener un aspecto modular a primera vista, se ha mantenido la filosofía y el

programa proporcionará los beneficios de un sistema modular.

DESCOMPOSICION MODULAR

El diseño modular propone dividir el sistema en partes diferenciadas y definir sus

interfaces. Sus ventajas: claridad, reducción de costos y reutilización

Los pasos a seguir son:

1. Identificar los módulos

2. Describir cada módulo

3. Describir las relaciones entre módulos

Una descomposición modular debe poseer ciertas cualidades mínimas para que se pueda

considerar suficiente validad.

1. Independencia funcional

2. Acoplamiento

3. Cohesión

4. Comprensibilidad

5. Adaptabilidad

3

Descomposición Modular: Independiente Funcional

Al final de los documentos ADD y DDD debe haber una matriz

REQUISITOS/COMPONNETES. En principio, cada función será realizada en un

módulo distinto. Si las funciones son independientes los módulos tendrán

independencia funcional.

Cada módulo debe realizar una función concreta o un conjunto de funciones afines.

Es recomendable reducir las relaciones entre módulos al mínimo.

Para medir la independencia funcional hay dos criterios: acoplamiento y cohesión.

Descomposición Modular: Acoplamiento

El grado de acoplamiento mide la interrelación entre dos módulos, según el tipo de

conexión y la complejidad de la interface:

FUERTE

o POR CONTENIDO, cuando desde un módulo se pueden cambiar datos

locales de otro

o COMÚN, se emplea una zona común de datos a la que tienen acceso varios

módulos

o 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 afecta a todos estos módulos

POR ETIQUETA, en intercambio de datos se realiza mediante una

referencia a la estructura completa de datos (vector, pila, árbol,

grafo)

DÉBIL

o DE DATOS, viene dado por los datos que intercambian los módulos. Es el

mejor posible

o SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

4

Descomposición Modular: Cohesión

Es necesario lograr que el contenido de cada módulo tenga la máxima coherencia. Para que

el nº de módulos no sea demasiado elevado y complique el diseño se tratan de agrupar

elementos afines y relacionados en un mismo módulo.

ALTA

o COHESIÓN ABSTRACCIONAL, se logra cuando se diseña el módulo

como tipo abstracto de datos o como una clase de objetos

o COHESIÓN FUNCIONAL, el módulo realiza una función concreta y

específica

MEDIA

o COHESIÓN SECUENCIAL, los elementos del módulo trabajan de forma

secuencial

o COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo

conjunto de datos de entrada o de salida

o COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el

mismo momento. Ej. Arrancar o parar dispositivos

BAJA

o COHESIÓN LÓGICA, se agrupan elementos que realizan funciones

similares. Ej.: módulos de E/S o de tratamiento de errores

o COHESIÓN COINCIDENTAL, es la peor y se produce cuando los

elementos de un módulo no guardan relación alguna

La descripción del comportamiento de un módulo permite establecer el grado de cohesión:

Si es una frase compuesta y contiene más de un verbo la cohesión será MEDIA

Si contiene expresiones secuenciales (primero, entonces, cuando…), será temporal o

secuencial

5

Si la descripción no se refiere a algo específico (Ej. Todos los errores), cohesión

lógica

Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.

Descomposición Modular: 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

SIMPLICIDAD, las soluciones sencillas son siempre las mejores

Descomposición Modular: 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 posible

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

6

Opinión personal

Es un método que ofrece muchas posibilidades en el desarrollo de software reduce la

complejidad de todo el problema y así una solución, así como también divide el problema

en módulos, la descomposición modular se vale principalmente de diagramas para hacer

mas sencillo el desarrollo del proyecto es una buena arquitectura ya que entre sus ventajas

tiene la reutilización y la reducción de costos para emplearlo en nuestra carrera (Ing.

Sistemas Computacionales) es factible ya que lleva una serie de pasos que llevan un orden

así como posee ciertas cualidades para que se pueda considerar su validez .

(Pressman, 2002; Luis Manuel Menacho Ramirez, 2010)

Bibliografía

Luis Manuel Menacho Ramirez, I. d. (30 de 05 de 2010). Radyel's Blog. Recuperado el 30 de 09 de

2012, de Radyel's Blog: http://radyel.wordpress.com/3/

Pressman, R. (2002). Ingenieria del software un enfoque practico 5ta edicion. españa: McGraw-Hill.