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 top-down. 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 reglas anteriores, e indirectamente de los criterios, cinco principios de construccin del software : El principio modular de las unidades lingsticas.

El principio de auto-documentacion.

El principio de acceso uniforme.

El principio de abierto-cerrado.

El principio 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: 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.

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.

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.

Modularidad: cmo podemos combinar cualquier otra cosa que los mdulos con ambigedades sintcticas las fronteras?

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: 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.

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.

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.

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.