Sistemas Computacionales
29-9-2012
INSTITUTO
TECNOLGICO
DE OAXACA
Jonatn Snchez Cruz N 09161287 Catedrtico: Castan Olgun Eduardo Materia: Ing. software
CAPACIDAD MODULAR
Capacidad de descomposicin modular Si un mtodo de diseo proporciona un mecanismo sistemtico para descomponer el problema en subproblemas, reducir la complejidad de todo el problema, consiguiendo de esta manera una solucin modular efectiva. Capacidad de empleo de componentes modulares Si un mtodo de diseo permite ensamblar los componentes de diseo (reusables) existentes en un sistema nuevo, producir una solucin modular que no inventa nada ya inventado. Capacidad de comprensin modular Si un mdulo se puede comprender como una unidad autnoma (sin referencias a otros mdulos) ser ms fcil de construir y de cambiar. Continuidad modular Si pequeos cambios en los requisitos del sistema provocan cambios en los mdulos individuales, en vez de cambios generalizados en el sistema, se minimizar el impacto de los efectos secundarios de los cambios. Proteccin modular Si dentro de un mdulo se produce una condicin aberrante y sus efectos se limitan a ese mdulo, se minimizar el impacto de los efectos secundarios inducidos por los errores. Finalmente, es importante destacar que un sistema se puede disear modularmente, incluso aunque su implementacin deba ser monoltica. Existen situaciones (por ejemplo, software en tiempo real, software empotrado) en donde no es admisible que los
1
subprogramas introduzcan sobrecargas de memoria y de velocidad por mnimos que sean (por ejemplo, subrutinas, procedimientos). En tales situaciones el software podr y deber disearse con modularidad como filosofa predominante. El cdigo se puede desarrollar en lnea. Aunque el cdigo fuente del programa puede no tener un aspecto modular a primera vista, se ha mantenido la filosofa y el programa proporcionar los beneficios de un sistema modular.
DESCOMPOSICION MODULAR
El diseo modular propone dividir el sistema en partes diferenciadas y definir sus interfaces. Sus ventajas: claridad, reduccin de costos y reutilizacin 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. 1. Independencia funcional 2. Acoplamiento 3. Cohesin 4. Comprensibilidad 5. Adaptabilidad
2
Al
final
de
los
documentos
ADD
y DDD
debe
haber
una
matriz
REQUISITOS/COMPONNETES. En principio, cada funcin ser realizada en un mdulo distinto. Si las funciones son independientes los mdulos tendrn independencia funcional.
Cada mdulo debe realizar una funcin concreta o un conjunto de funciones afines. Es recomendable reducir las relaciones entre mdulos al mnimo.
Descomposicin Modular: Acoplamiento El grado de acoplamiento mide la interrelacin entre dos mdulos, segn el tipo de conexin y la complejidad de la interface:
FUERTE
o
POR CONTENIDO, cuando desde un mdulo se pueden cambiar datos locales de otro
COMN, se emplea una zona comn de datos a la que tienen acceso varios mdulos
MODERADO
DE CONTROL, la zona comn es un dispositivo externo al que estn ligados los mdulos, esto implica que un cambio en el formato de datos afecta a todos estos mdulos
POR ETIQUETA, en intercambio de datos se realiza mediante una referencia a la estructura completa de datos (vector, pila, rbol, grafo)
DBIL
o
DE DATOS, viene dado por los datos que intercambian los mdulos. Es el mejor posible
Descomposicin Modular: Cohesin Es necesario lograr que el contenido de cada mdulo tenga la mxima coherencia. Para que el n de mdulos no sea demasiado elevado y complique el diseo se tratan de agrupar elementos afines y relacionados en un mismo mdulo.
ALTA
o
COHESIN ABSTRACCIONAL, se logra cuando se disea el mdulo como tipo abstracto de datos o como una clase de objetos
MEDIA
o
COHESIN DE COMUNICACIN, elementos que operan con le mismo conjunto de datos de entrada o de salida
COHESIN TEMPORAL, se agrupan elementos que se ejecutan en el mismo momento. Ej. Arrancar o parar dispositivos
BAJA
o
COHESIN LGICA, se agrupan elementos que realizan funciones similares. Ej.: mdulos de E/S o de tratamiento de errores
COHESIN COINCIDENTAL, es la peor y se produce cuando los elementos de un mdulo no guardan relacin alguna
Si es una frase compuesta y contiene ms de un verbo la cohesin ser MEDIA Si contiene expresiones secuenciales (primero, entonces, cuando), ser temporal o secuencial
Si la descripcin no se refiere a algo especfico (Ej. Todos los errores), cohesin lgica Si aparece inicializar, preparar, configurar, probablemente sea temporal.
Descomposicin Modular: Comprensibilidad Para facilitar los cambios, el mantenimiento y la reutilizacin de mdulos es necesario que cada uno sea comprensible de forma aislada. Para ello es bueno que posea independencia funcional, pero adems es deseable:
IDENTIFICACIN, el nombre debe ser adecuado y descriptivo DOCUMENTACIN, debe aclarar todos los detalles de diseo e implementacin que no queden de manifiesto en el propio cdigo
Descomposicin Modular: Adaptabilidad La adaptacin de un sistema resulta ms difcil cuando no hay independencia funcional, es decir, con alto acoplamiento y baja cohesin, y cuando el diseo es poco comprensible. Otros factores para facilitar la adaptabilidad:
PREVISIN, es necesario prever que aspectos del sistema pueden ser susceptibles de cambios en el futuro, y poner estos elementos en mdulos independientes, de manera que su modificacin afecte al menor nmero de mdulos posible
ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de especificacin, diseo, e implementacin para obtener un conocimiento suficiente del sistema antes de proceder a su adaptacin
CONSISTENCIA, despus de cualquier adaptacin se debe mantener la consistencia del sistema, incluidos los documentos afectados
Opinin personal Es un mtodo que ofrece muchas posibilidades en el desarrollo de software reduce la complejidad de todo el problema y as una solucin, as como tambin divide el problema en mdulos, la descomposicin 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 reutilizacin y la reduccin 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)
Bibliografa
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. espaa: McGraw-Hill.