Modularity:

Modularidad, se introdujo para cubrir la combinacin de dos factores de calidad (extensibilidad y

reusabilidad).
Se debe garantizar que cada pieza del programa;cada mdulo (subrutina) sea independiente y
organizadas en arquitecturas estables.
Un mtodo de construccin de software es modular si ayuda a los diseadores a producir software
de elementos autnomos, conectados por una coherente estructura simple.
Este captulo, introduce un juego de propiedades complementarias: cinco criterios, cinco reglas y
cinco principios de modularidad que, tomadas en conjunto, cubren las exigencias sobre un mtodo de
diseo modular.
Modularidad: unidad bsica de la descomposicin de nuestros sistemas.
CINCO CRITERIOS:
Un mtodo de diseo digno de haber llamado modular deberan satisfacer cinco exigencias
fundamentales:

Descomponibilidad

Componibilidad

Comprensibilidad

Continuidad

Proteccin
-Descomponibilidad modular:
Un mtodo de construccin de software modular satisface la descomponibilidad si sirve de ayuda
en la tarea de la descomposicin de un problema de software en un nmero de subproblemas menos
complejos, conectados por una estructura simple y lo suficientemente independientes para permitir que
prosiguiera sus trabajo por separado.
El proceso se repetir, ya que cada subproblema a menudo ser complejo y exigir ms
descomposicin.

Un corolario de la descomponibilidad es la divisin del trabajo: una vez que usted haya
descompuesto un sistema en subproblemas debe ser capaz de distribuir el trabajo de estos subsistemas
entre diferentes personas o grupos. Este es un objetivo difcil ya que limita las dependencias que pueden
existir entre los subsistemas:

Usted debe mantener dichas dependencias en mnimo; de lo contrario, el desarrollo de

cada uno de los subsistemas se vera limitado por el ritmo de los trabajos sobre los otros
subsistemas.

Deben conocerse las dependencias: si fracasas en listar todos las relaciones de los
subsistemas, al final del proyecto puede obtener un conjunto elementos que parecen
trabajar individualmente pero no se puede poner juntos para producir un sistema
completo que cumpla con las necesidades globales del problema original.
El ejemplo ms claro de un mtodo objetivo de satisfacer el criterio descomponibilidad es topdown. Este mtodo enva los diseadores para empezar con una descripcin ms abstracta de la funcin
del sistema y, a continuacin, para perfeccionar este punto de vista a travs de los sucesivos pasos, la
descomposicin de cada subsistema en cada paso en un pequeo nmero de subsistemas ms simples,
hasta que todos los dems elementos son de un nivel lo suficientemente bajo de abstraccin para
permitir ejecucin directa . El proceso puede ser modelado como un rbol.

Un contraejemplo tpico es cualquier mtodo que le anima a incluir, en cada sistema de software
que usted produce, un mdulo de inicializacin global. Muchos mdulos en un sistema necesitarn una
especie de inicializacin - acciones como la apertura de ciertos archivos o la inicializacin de ciertas
variables, que el mdulo debe ejecutar antes de que esto realice su primero tareas directamente tiles.
Esto puede parecer una idea buena de concentrar todas tales acciones, para todos los mdulos del
sistema, en un mdulo que inicializa todo para cada uno. Tal mdulo expondr bueno " la cohesin
temporal " en esto todas sus acciones son ejecutadas en la misma etapa de la ejecucin del sistema. Pero
obtener esta cohesin temporal el mtodo pondra en peligro la autonoma de mdulos: usted tendr que
conceder la autorizacin de mdulo de inicializacin de tener acceso a muchas estructuras de datos
separadas, perteneciendo a varios mdulos del sistema y requiriendo acciones de inicializacin
especficas. Esto quiere decir que el autor del mdulo de inicializacin constantemente tendr que echar
una ojeada en las estructuras de datos internas de otros mdulos, y actuar recprocamente con sus
autores. Esto es incompatible con el criterio descomponibilidad.
-Componibilidad modular:
Un mtodo cumple componibilidad modular si se favorece la produccin de elementos de software
que se pueden combinar libremente unos con otros para producir nuevos sistemas, posiblemente en un
medio ambiente muy distinto de aquel en el que fueron desarrolladas inicialmente.
Donde descomponibilidad se refiere a la derivacin de los subsistemas de sistemas globales ,
componibilidad aborda el proceso inverso: la extraccin de elementos de software desde el contexto para
el que fueron concebidos, para volver a utilizar en diferentes contextos.

Un diseo modular debera facilitar el proceso de producir elementos de software que ser lo
suficientemente autnomas - lo suficientemente independiente de la meta inmediata que dieron lugar a
su existencia, como para que la extraccin sea posible. Componibilidad est directamente conectado con
el objetivo de reutilizacin: el objetivo es encontrar formas de disear elementos de software que
realizan tareas bien definidas y utilizables en contextos muy distintos.
Ejemplo 1: subprograma bibliotecas. Subprograma bibliotecas estn diseados como conjuntos de
elementos componibles. Una de las reas en las que han sido exitosas es clculos numricos , que
normalmente se basa en las bibliotecas de subrutinas cuidadosamente diseados para resolver
problemas de lgebra lineal, elementos finitos, ecuaciones diferenciales, etc.
Ejemplo 2: Shell de Unix convenios. Comandos bsicos de Unix operan en una entrada como un carcter
secuencial, y produce una salida con la misma estructura estndar.
Componibilidad es independiente de descomponibilidad. De hecho, estos criterios son a menudo
enfrentados. Diseo top-down, por ejemplo, que vimos como una tcnica que favorece
descomponibilidad, tiende a producir mdulos que no son fciles de combinar con mdulos procedentes
de otras fuentes. Esto es debido a que el mtodo sugiere desarrollar cada uno de los mdulos para
cumplir con un requisito especfico, correspondiente a un subproblema obtenido en algn momento del
proceso de refinamiento.

-Comprensibilidad modular:
Un mtodo modular favorece entender si ayuda a producir software en el cual el lector humano
puede comprender cada uno de los mdulos sin necesidad de conocer la otros, o, en el peor de los casos,
por tener que examinar slo algunos de los otros.
La importancia de este criterio se desprende de su influencia en el proceso de mantenimiento. La
mayora de las actividades de mantenimiento, ya sea de los nobles o no-tan-noble categora, implican
tener que excavar en los elementos de software. Un mtodo no puede llamarse modular si un lector de el
software es incapaz de entender sus elementos por separado.

Este criterio, al igual que los otros, se aplica a los mdulos de una descripcin del sistema a
cualquier nivel: anlisis, diseo, implementacin.
Contra-ejemplo: secuencial de las dependencias. Asumir algunos mdulos han sido diseados de
manera que slo funciona correctamente si se ha activado en un cierto orden ; por ejemplo, B slo puede
funcionar correctamente si se ejecuta antes y despus de una C, quizs porque estn destinados para su
uso en "hilo" como en la notacin Unix anteriores: A | B | C entonces es probablemente difcil de
comprender sin conocer A B y C.
El criterio sugiere que la informacin sobre un componente, til para la documentacin o para la
recuperacin, siempre que sea posible debe aparecer en el texto del propio componente; herramientas de
documentacin, indizacin o proceso, a continuacin, puede recuperar el componente para extraer la
informacin necesaria . Disponer de la informacin incluida en cada uno de los componentes es preferible
a almacenar en cualquier otro lugar, por ejemplo, en una base de datos de informacin acerca de los
componentes.
-Continuidad modular:
Un mtodo favorece la continuidad modular si un pequeo cambio en la especificacin de un
problema, va a desencadenar un cambio de un solo mdulo, o un nmero reducido de mdulos.

Este criterio est directamente conectado a la consecucin del objetivo general de ampliacin.
Como se subraya en un captulo anterior , el cambio es una parte integral de la construccin del software.
Los requisitos , casi inevitablemente, a medida que avanza el proyecto.
Ejemplo 1: constantes simblicas. Una buena regla de estilo bares las instrucciones de un
programa de constante numrica o textual directamente; en su lugar, ellos se basan en nombres
simblicos , y los valores reales slo aparecen en una constante definicin (constante en Pascal o Ada,
macros de preprocesador en C, Fortran 77 PARMETRO de atributos constantes, en la notacin de este
libro). Si el valor cambia, lo nico que es la constante actualizacin definicin

-Proteccin modular:
Un mtodo Modular cumple proteccin si se produce arquitecturas en las que el efecto de una
condicin anormal que ocurre en tiempo de ejecucin en un mdulo se limitar a ese mdulo, o en el peor
de los casos,slo se propague a unos cuantos mdulos vecinos.

La cuestin de fondo, la de fallas y errores, es un elemento central en ingeniera de software. Los

errores son errores en tiempo de ejecucin, como consecuencia de fallas en el hardware, entrada errnea
o el agotamiento de los recursos necesarios (por ejemplo almacenamiento en memoria). El criterio no se
aborda la prevencin o correccin de los errores, pero el aspecto que es directamente relevante a la
modularidad : su propagacin.
1-Ejemplo: validacin de la entrada en la fuente. Un mtodo que requiere que todos los mdulos entrada
de datos tambin responsable de comprobar su validez es bueno para proteccin modular.
CINCO REGLAS :
De los criterios anteriores, cinco reglas que debemos observar para garantizar modularidad:
Asignacin directa.
Pocas Interfaces.
Pequeas interfaces (acoplamiento dbil).
Interfaces explcitas.
Ocultar Informacin.
El primer artculo aborda la relacin entre un sistema de software y los sistemas externos con los
que se est conectado, el prximo capitulo de un tema comn: los mdulos . Obtener buenos
arquitecturas modulares requiere que la comunicacin se produce de forma controlada y la disciplina.
-Asignacin directa:
Cualquier sistema de software se trata de abordar las necesidades de algn dominio del
problema. Si usted tiene un buen modelo para describir ese dominio, usted encontrar que es
conveniente mantener una clara correspondencia (mapping) entre la estructura de la solucin, como
siempre por el software, y la estructura del problema, como se describe en el modelo.
Por lo tanto, la primera regla:.
La estructura modular elaborada en el proceso de construccin de un sistema de software debe seguir
siendo compatible con cualquier estructura modular elaborada en el proceso de modelado del dominio del
problema
Este asesoramiento se deduce de dos criterios de la modularidad:
Continuidad: mantener un seguimiento del problema de la estructura modular de la solucin la
estructura har que sea ms fcil de evaluar y limitar el impacto de los cambios.
Decomponibilidad: si ya se han realizado algunos trabajos para analizar la estructura modular
del dominio del problema, que puede proporcionar un buen punto de partida para la descomposicin
modular del software.
-Pocas interfaces :
Las regla pocas interfaces restringe el nmero total de canales de comunicacin entre los
mdulos en una arquitectura de software:
Cada mdulo debe comunicarse con algunos otros como sea posible.
Comunicacin puede ocurrir entre los mdulos en una variedad de maneras. Los mdulos pueden
llamarse unos a otros (si es que son los procedimientos), compartir estructuras de datos etc.
Esta regla limita el nmero de ese tipo de conexiones.

Ms precisamente, si un sistema est compuesto por mdulos n, entonces el nmero de

conexiones intermodulos debe permanecer mucho ms cerca de los mnimos, n-1, como se muestra en
(A) en la figura , que a la mxima, n (n - 1) /2, en la que aparecen como (B). Esta regla se deduce de los
criterios de continuidad y proteccin: si hay muchas relaciones entre los mdulos, el efecto de un cambio
o de un error se puede propagar a un gran nmero de mdulos.
(A) en el caso de la ltima figura, se muestra la forma de llegar a el nmero mnimo de enlaces, n-1, a
travs de una gran estructura centralizada: un mdulo maestro; todo el mundo habla de ella y slo ella.
Pero tambin hay mucho ms "igualitario" las estructuras, tales como (C), la cual tiene casi el mismo
nmero de eslabones. En este esquema, cada mdulo slo habla de sus dos vecinos inmediatos, pero no
hay una autoridad central.
-Pequeas Interfaces :
Las pequeas Interfaces o "acoplamiento dbil" se refiere a las dimensiones de las conexiones
entre mdulos en lugar de su nmero:
Si los dos mdulos se comunican, se deben intercambiar informacin como sea posible.

Los Pequeos Interfaces requisito sigue en particular de los criterios de continuidad y proteccin .
Un ejemplo que demuestra lo contrario es un Fortran prctica que algunos lectores reconocen: el bloque
comn "basura". UN bloque comn en Fortran es una directiva de la forma comn /nombre_comn/
variable1, no hay mas espacio para las variables que indican que las variables enumeradas son
accesibles no slo al mdulo, pero tambin a cualquier otro mdulo que incluye una directiva comn con
el mismo nombre_comn.
El problema, por supuesto, es que todos los mdulos tambin pueden abusar los datos comunes,
y, por consiguiente, que los mdulos estn estrechamente relacionados entre s; los problemas de
continuidad modular (propagacin de cambios) y la proteccin (propagacin de errores) son
especialmente desagradable. Esta tradicional tcnica ha seguido siendo uno de los favoritos, sin duda
para muchos una tarde-noche sesin de depuracin
Los desarrolladores que utilizan lenguajes con estructuras anidadas pueden sufrir de problemas
similares. Con estructura de bloque que ha presentado el Algol y se conservan en una forma ms
restringida de Pascal , es posible incluir bloques, delimitado por comenzar end pares, dentro de otros
bloques. Adems cada bloque puede introducir su propia variables, que slo tienen sentido en el mbito
sintctico de la cuadra .
-Interfaces explcitas:
Con la cuarta regla, avanzamos un paso ms en la exigencia de un rgimen totalitario a la
sociedad de los mdulos: no slo exigimos que cualquier conversacin se limitan a unos pocos
participantes y consisten en una pocas palabras; tambin es necesario que estas conversaciones deben
ser pblicos y en voz alta.
Siempre que dos mdulos A y B se relacionen, sta relacin debe ser evidente en el texto de A o B o
ambos.

Detrs de esta regla soportan los criterios de decomposability y composability (si usted tenga
que descomponer un mdulo en varios submdulos o componerlo con otros mdulos, cualquier conexin
exterior debera ser claramente visible), la continuidad (debera ser fcil averiguar qu elementos un
cambio potencial puede afectar) y understandability (como puede usted entender un por s mismo si la B
puede influir en su comportamiento de algn modo desviado?).
-Ocultacin de informacin:
El diseador de cada mdulo debe seleccionar un subconjunto de las propiedades del mdulo
como la informacin oficial sobre el mdulo, que se ponen a disposicin de los autores de mdulos del
cliente.
En la aplicacin de esta regla se asume que cada mdulo es conocido en el resto del mundo ( es
decir, a los diseadores de otros mdulos) a travs de algunas descripcin oficial, o las propiedades.
Por supuesto, todo el texto del propio mdulo (programa texto, texto de diseo) podran servir
como la descripcin: proporciona una visin correcta del mdulo ya que es el mdulo. La ocultacin de
informacin norma establece que esto no debe ser el caso: la descripcin debe incluir slo algunas de las
propiedades del mdulo. El resto debe permanecer no-pblico, o secreto. En lugar de las propiedades
pblicas y secretas, tambin se puede hablar de exportacin y las propiedades privada
La razn fundamental de la regla de la Informacin oculta es la continuidad criterio. Asumir un
mdulo los cambios, pero los cambios slo se aplican a sus elementos secretos, dejando intactos los
pblicos; a continuacin, otros mdulos, llamados sus clientes, no se vern afectados. Cuanto ms
pequea es la parte pblica, mayor ser la posibilidad que los cambios en el mdulo estar efectivamente
en la parte secreta.

No se trata de desarrollar los mdulos de un sistema por separado, combinar varios mdulos ya
existentes, o entender los mdulos individuales, a menos que se sepa exactamente lo que cada uno de
ellos pueden y no pueden esperar de los dems.
Como regla general, la parte pblica deben incluir la especificacin de la funcionalidad del
mdulo; cualquier cosa que se relaciona con la aplicacin de esa funcionalidad debe mantenerse en
secreto, con el fin de preservar otros mdulos de reversiones de las decisiones relativas a su aplicacin.
A pesar de su nombre, ocultacin de informacin no implica proteccin en el sentido de las
restricciones en materia de seguridad fsica prohibir los autores de mdulos del cliente de acceso al texto
interno de un proveedor. Cliente autores puede ser permitida para leer todos los detalles que desee: les

impide hacerlo puede ser razonable en determinadas circunstancias, pero se trata de un proyecto de
decisin que no se sigue necesariamente de la ocultacin de informacin.
Como un requisito tcnico, ocultacin de informacin significa que mdulos del cliente (si o no sus
autores estn autorizados a leer el secreto propiedades de los proveedores) solo debe confiar en los
proveedores de propiedades pblicas. Ms precisamente, debe ser imposible escribir mdulos cliente
cuyo funcionamiento correcto depende de informacin secreta
En un enfoque formal de construccin del software, esta definicin se declar lo siguiente . Para
demostrar la exactitud de un mdulo, tendr que asumir algunas de las propiedades de sus proveedores.
Ocultacin de informacin significa que tales pruebas slo se le permite que dependen de las propiedades
pblicas de los proveedores, nunca en su secreto.
Uno de los malosentendidos es el propio trmino de " ocultacin de informacin", que tiende a
sugerir proteccin fsica. "Encapsulacin", a veces se usa como sinnimo de ocultacin de informacin,
probablemente sea preferible a este respecto , aunque esta discusin va a mantener el trmino ms
comn.
Como un resumen de este debate: la clave para ocultar informacin o de gestin no es como en
las polticas de comercializacin que puede o no puede acceder al texto de la fuente de un mdulo, pero
las estrictas normas del lenguaje para definir cules son los derechos de acceso de un mdulo tiene
propiedades de sus proveedores.
CINCO PRINCIPIOS
De las
software :

reglas anteriores, e indirectamente de los criterios, cinco principios de construccin del

El
El
El
El
El

principio
principio
principio
principio
principio

modular de las unidades lingsticas.

de auto-documentacion.
de acceso uniforme.
de abierto-cerrado.
de opcin nica.

-Principio modular de las unidades lingisticas:

Expresa que el formalismo utilizado para describir el software a diferentes niveles
(especificaciones, diseos, implementaciones) debe apoyar el punto de vista de la modularidad:
Los mdulos deben corresponder a unidades sintcticas en el lenguaje que utiliza.
El idioma puede ser un lenguaje de programacin, un lenguaje de diseo, un lenguaje de
especificacin , etc. En el caso de lenguajes de programacin, mdulos compilables por separado.
Lo que este principio excluye a cualquier nivel: anlisis, diseo, implementacin, es combinar un
mtodo que sugiere un cierto concepto del mdulo y con un lenguaje que no ofrece la correspondiente
estructura modular, lo que obliga a los desarrolladores de software para realizar traduccin manual o
reestructuracin. No es raro ver empresas esperando para aplicar ciertos conceptos metodolgicos (tales
como los mdulos de la Ada, o principios de la programacin orientada a objetos ) pero, a continuacin,
aplicar el resultado en un lenguaje de programacin, como Pascal o C, que no es compatible con ellos. Un
enfoque de este tipo las derrotas de la modularidad posee varios criterios:
1. Continuidad: si las fronteras del mdulo en el texto final no corresponden a la
descomposicin lgica de la especificacin o el diseo, ser difcil o imposible mantener la
consistencia entre varios niveles cuando el sistema se desarrolla. Un cambio de la
especificacin puede ser considerado pequeo si esto afecta slo un pequeo nmero de
mdulos de especificacin; para asegurar la continuidad, debe haber una correspondencia
directa entre la especificacin, el diseo y mdulos de puesta en prctica.
2. Asignacin directa: para mantener una clara correspondencia entre la estructura del
modelo y la estructura de la solucin, se debe tener una clara identificacin de los
sintcticos unidades conceptuales en ambos lados, lo que refleja la divisin sugerida por
su mtodo de desarrollo.
3. Descomponibilidad: para dividir el desarrollo de sistema sobre tareas separadas, usted
tiene que asegurarse que cada tarea causa una unidad bien delimitada sintctica; en la
etapa de puesta en prctica, estas unidades deben ser separadamente compilable.
4. Modularidad: cmo podemos combinar cualquier otra cosa que los mdulos con
ambigedades sintcticas las fronteras?
5. Proteccin: slo puede aspirar a controlar el alcance de los errores si los mdulos son
sintcticamente delimitados.
-Principio de auto-documentacin:
Al igual que el estado de ocultacin de informacin, el principio de auto-documentacin rige el
modo en que deben documentar los mdulos:
El diseador de un mdulo debe procurar que toda la informacin sobre el mdulo
parte del mdulo en s mismo.
La ms evidente justificacin del principio de auto-documentacion es, modular el criterio de

comprensibilidad.
Tal vez ms importante, sin embargo, es el papel de este principio para ayudar a satisfacer la
continuidad. Si el software y su documentacin son tratados como entidades separadas, es difcil
garantizar que no sern compatibles - "en sintona", - cuando empiece a cambiar las cosas. Todo est en
el mismo lugar, aunque no es una garanta, es una buena forma de ayudar a mantener la compatibilidad.
Este principio inocuo como puede parecer en un primer momento, va en contra de lo que la
ingeniera de software por lo general ha sugerido como buenas prcticas de desarrollo de software.La
visin dominante es que los desarrolladores de software, para merecer el ttulo de ingenieros de software,
necesita hacer lo que otros ingenieros se supone que: producir un kilo de papel para cada gramo de
entrega real. El estmulo para guardar un registro del proceso de construccin de software es el consejo
bueno - pero no la implicacin que el software y su documentacin son diferentes productos.
Este enfoque ignora la propiedad especfica de software, que una y otra vez se repite en este
debate: su mutabilidad. Si se tratan los dos productos por separado, se encuentran en riesgo rpidamente
en una situacin en que la documentacin dice una cosa y el software hace algo ms.
Este libro se basar en el principio auto-documentation para definir un mtodo de documentacin
de clases - construccion de mdulos de software orientado a objetos - que incluye la documentacin de
cada mdulo en el propio mdulo. No es que el mdulo es su documentacin: generalmente hay
demasiados detalles en el software texto, de modo que su adecuado como documentacin (este fue el
argumento para ocultar informacin). En su lugar, el mdulo debe contener la documentacin.
En este enfoque el software se convierte en un producto nico que admite varios puntos de vista.
Un punto de vista, adecuado para la compilacin y ejecucin, es mostrar el cdigo fuente completo. Otra
es la documentacin de la interfaz abstracta de cada mdulo, de forma que los desarrolladores de
software para escribir mdulos del cliente sin tener que aprender el funcionamiento interno del propio
mdulo, de acuerdo con la norma de ocultacin de informacin.
-El principio de acceso uniforme:
Aunque a primera vista, puede parecer poco para resolver un problema las anotaciones, el
principio de acceso uniforme es, de hecho, una regla de diseo que influye en muchos aspectos de diseo
orientado a objetos. Se desprende del criterio de continuidad; tambin se puede ver como un caso
especial de ocultacin de informacin.
En su forma general el principio puede expresarse como sigue:
Todos los servicios ofrecidos por un mdulo deberan estar disponibles por una notacin uniforme,
que no traiciona si ellos son puestos en prctica por el almacenaje o por el cmputo.
-El principio de abierto-cerrado:
Los mdulos deben ser tanto abiertos como cerrados.
Un mdulo se dice que es abierto si an est disponible para la extensin. Por ejemplo, debe ser
posible ampliar el conjunto de operaciones o agregar campos a las estructuras de datos.
Un mdulo se dice que es cerrado si est disponible para su uso por otros mdulos. Esto supone
que el mdulo ha sido bien definidas y estables (su interfaz en el sentido de ocultacin de informacin).
En el mbito de la ejecucin, cierre de un mdulo tambin implica que puede compilar, tal vez en una
biblioteca, y hacer que est disponible para otros (sus clientes) que se va a utilizar. En el caso de un
proyecto de diseo o mdulo especificacin, cerrar un mdulo significa simplemente que aprobados por la
administracin, agregarlo al proyecto oficial del repositorio de elementos de software (a menudo llamado
el proyecto de referencia), y publicar su interfaz para el beneficio de otro mdulo autores.
La necesidad de que los modulos se cierren o que pertenezcan abiertas, puede surgir por
diferentes razones. La apertura es la preocupacin natural de los desarrolladores de software, ya que se
sabe que es casi imposible de prever todos los elementos, datos, operaciones, un mdulo, necesitar en
su vida, por lo que se desea conservar la mxima flexibilidad posible para futuros cambios y extensiones.
Pero es igual de necesaria para cerrar los mdulos, especialmente desde un punto de vista del
gerente de proyecto: en un sistema compuesto por varios mdulos, la mayora dependen de otros; un
mdulo de interfaz de usuario puede depender de que el mdulo de anlisis (para el anlisis de textos) y
grficos en un mdulo, el mdulo de anlisis s puede depender de un mdulo de anlisis lxico, y as
sucesivamente. Si nunca hemos cerrado un mdulo hasta que estuvimos seguros que incluye todas las
funciones necesarias, no de varios mdulos software, llegara a completar: cada desarrollador siempre
sera esperar a la conclusin de que alguien ms de trabajo.
-El principio de opcin unica:
El ltimo de los cinco principios modularidad puede considerarse como una consecuencia de la
Open-Closed y ocultacin de informacin.
Antes de examinar el principio de eleccin nica en toda su generalidad, veamos un ejemplo
tpico.
Siempre que un sistema de software debe apoyar un conjunto de alternativas, slo uno de los
mdulos del sistema debe conocer su lista exhaustiva.
Por que requieren que el conocimiento de la lista de opciones se limita a uno de los mdulos, preparamos

a la escena para cambios posteriores: si las variantes se aaden, slo tendr que actualizar el mdulo
que tiene la informacin, el punto de eleccin nica. Todos los dems, y en particular sus clientes, ser
capaz de continuar sus negocios como de costumbre. t.
Una vez ms, como las publicaciones ejemplo muestra, los mtodos tradicionales no ofrecen una solucin
; una vez ms, tecnologa de objetos muestran el camino, aqu gracias a dos tcnicas relacionadas con la
herencia, polimorfismo y enlace dinmico. No hay avance en este caso, sin embargo , estas tcnicas debe
ser entendido en el contexto del completo del mtodo
El nico principio de eleccin le pide unos comentarios ms:
1. El nmero de mdulos que sabemos que la lista de opciones se debe, de acuerdo con el principio ,
exactamente uno. La modularidad objetivos indican que queremos ms de un mdulo que este
conocimiento; pero tambin es claro que al menos uno de los mdulos debe poseer. No se puede
escribir un editor que por lo menos uno de los componentes del sistema no tiene la lista de todos
los comandos, o un sistema de grficos que por lo menos uno de los componentes tiene la lista de
todos los tipos, figura o un compilador de Pascal que por lo menos uno de los componentes
"sabe" la lista de Pascal construye.
2. Al igual que muchas de las otras normas y principios estudiados en este captulo, el principio es
acerca de la distribucin del conocimiento en un sistema de software. Esta pregunta es crucial
para la bsqueda de extensible, software reutilizable .Para obtener slidos, duraderos las
arquitecturas de sistema debe tomar estrictas medidas para limitar la cantidad de informacin
disponible para cada mdulo. .Por analoga con los mtodos empleados por determinados
colectivos humanos , podemos llamar a esto una necesidad de conocer: salvo cada mdulo de
acceso a cualquier informacin que no sea estrictamente necesario para su correcto
funcionamiento.
3. Tambin se puede entender el principio de una gran forma de ocultacin de informacin. El
diseador de mdulos tales como proveedor A y A' trata de ocultar la informacin (en cuanto a la
lista precisa de las variantes disponibles para una determinada nocin) de los clientes.
4. Usted puede ver el principio de eleccin como consecuencia directa del principio de apertura y
cierre .Examinar las publicaciones ejemplo a la luz de la figura en la que se ilustra la necesidad de
abrir-cerrar mdulos: un mdulo en el que se incluye el original de la declaracin de tipo
PUBLICACIN; los clientes B, C, son los mdulos que se basaban en la lista inicial de variantes;
una es la versin actualizada de una variante que ofrece un extra (informes tcnicos).
CONCEPTOS CLAVE EN ESTE CAPTULO

La eleccin de una buena estructura del mdulo es la clave para el logro de los objetivos
de reutilizacin y ampliacin.

Mdulos sirven tanto para software descomposicin (la vista desde arriba) y software
composicin (de abajo hacia arriba).

Modular conceptos se aplican a las especificaciones y el diseo, as como su ejecucin.

Una amplia definicin de modularidad deben combinar varios puntos de vista, las
diversas exigencias pueden parecer a veces en contradiccin con los otros, como con
decomposability (que anima a mtodos "top-down) y modularidad (que favorece un
enfoque de abajo hacia arriba).

Controlar la cantidad y la forma de comunicacin entre los mdulos es un paso

fundamental en la elaboracin de una buena arquitectura modular.

La integridad a largo plazo de las estructuras del sistema modular requiere ocultacin de
informacin, que aplica una rigurosa separacin de interfaz e implementacin.

Acceso Uniforme libera los clientes opciones de representacin interna de sus

proveedores.

Un mdulo cerrado es uno que puede utilizarse, a travs de su interfaz, por mdulos del
cliente.

Un mdulo abierto es uno que an est sujeta a la extensin.

Gestin eficaz del proyecto requiere soporte para mdulos que son abiertas y cerradas .
Sin embargo, los enfoques tradicionales de diseo y programacin no se lo permite.

El principio de una sola opcin nos orienta para limitar la difusin de conocimiento
exhaustivo de las distintas variantes de un determinado concepto.