Es común integrar frameworks para satisfacer requerimientos de una aplicación. Sin embargo, Michael Mattson discute que haya por lo menos seis problemas comunes que los desarrolladores de frameworks y aplicaciones encuentran al integrar dos o más frameworks [ 9].Todos estos problemas derivan de un conjunto de cinco causas comunes: comportamiento cohesivo, cobertura del dominio, intención del diseño, carenciadel acceso al código de fuente, y carencia de los estándares para el framework. Estos problemas se detallan detenidamente [ 9],donde se proponen muchas soluciones para cada uno.
Si uno desarrolla un framework y espera que sea utilizado, la integración del framework es una realidad inevitable. El desarrollo de la composición no debe ser tomado tan ligeramente. Los frameworks se abandonan o se abortan a menudo porque no pueden ser fácilmente integrados con otros frameworks. La integración del framework no es una tarea fácil,y la composición debe ser consideradaseriamente durante el desarrollo
Una forma de considerar la composición cuando se desarrollan frameworks es mantener un conjunto de APIs (API, Application Program Interface,Interface de los programas de aplicaciones), que encapsulan los servicios que el framework proporciona. Al componer con un framework, la aplicación solamente necesita saber algunas funciones y parámetros que debenser llamados, ignorando los funcionamientos internos del framework. Otra opción es crear una capa de mediación, para convertir las peticiones del framework. Sin embargo, si se están componiendo implicando a muchos frameworks, esta aproximación comprueba lo costoso que es esto si uno no elige una capa de mediación unificada entre todos los elementos compuestos. En este caso, la capa de mediación actuará como "pegamento" entre estos elementos compuestos.
Un framework se puede también clasificar según su extensibilidad; puede ser utilizado como una caja blanca o caja negra [ 4].En los frameworks de caja blanca también llamados frameworkscon arquitectura de configuración-conducidos, la instantiaciónes solamente posible a través de la creación de nuevas clases.Estas clases y el código se pueden introducir en el marco por herenciao composición. Uno debe programar el framework y entenderlo muy bien para producir un caso.
Los frameworks de caja negra producen instancias usando escrituras o scripts de configuración. Después de la configuración, una herramienta automatica de instantiación crea las clases y el código de fuente (Source Code). Por ejemplo, es posible utilizara un wizard o configurador gráfico que dirija al usuario gradualmente paso por paso, a través del proceso de instantiación delframework. La caja negra del framework no requiere que el usuariosepa los detalles internos del framework. Por lo tanto, estos frameworks también se llaman frameworks dato-conducidos [ 4]y son generalmente más fáciles de usar. El cuadro 5 ilustra conceptualmente los frameworks de caja blanca y los frameworks de caja negra. Los frameworks que contienen características de ambas cajas se llaman los frameworks de caja gris.
La caja blanca , la caja negra y la mezclada caja gris tienen una curva de aprendizaje escarpada. Así, la capacidad de crear sistemas ejecutables desde un framework dependerá de la utilidad de los mecanismos de instantiación y de la documentación del framework. Si unframework está pobremente documentada, pocos personas la utilizarán. Sin embargo, un nuevo tipo de documentación debe estar presentecon los frameworks: Guías de "Cómo ampliarse " y/o herramientas de instantiación.
Muchas guías de consultas y documentación han sido hechos para los framework. Las tarjetas de los puntos calientes [ 13]se enfoca en los puntos flexibles del framework. Otro enfoque es crear libros de recetas o cookbooks que explica cómo el framework debe ser puesto en ejecución y los pasos requeridos para hacerlo [ 813].Éstos cookbooks contienen muchas "recetas" que describen de manera amena e informal cómo solucionar problemas específicos mientras usted está instantiando el framework. Un tercer enfoque es asociarlas soluciones arquitectónicas usadas a través del diseño del framework. Sin embargo, la documentación de la configuración del framework no explica todas las facetas del framework.
Según lo dicho antes, las aplicaciones del desarrollo del framework, con frecuencia, usan modelos de diseño. Aunque estos fragmentosde la arquitectura de la configuración constituyen una vision limitada de un framework, estos patrones o modelos son bien conocidos que pueden ayudar a la comprensión del proceso de instantiacióndel framework. Considere otra vez el ejemplo mostrado en el cuadro 4. En este problema del dominio, uno desea convertir caracteres entre los formatos usando diversos algoritmos (ej: el ISO-8849-1 al algoritmo de conversion MIME). Una solución eficaz puede crear un punto de extension (punto caliente) que
permite que el algoritmo de la conversión seaalterado de tal manera como si fuese un "plug and play". La estrategia de los patrones de diseño satisface a esta aplicación y permite que diversos algoritmos de conversión estén "plugged-in"o enchufados al framework sin alterar el código previamente escrito [5]. Esto el ejemplo se modela en UML en el cuadro 6. Este diagrama utiliza la misma notación usada en el cuadro2, con algunos elementos más. El caja de esquina plegable es un comentario, y la línea discontinua indica qué elemento del diagrama se refiere el comentario. Es importante notar que el cuadro 6 puede también servir como parte de la documentación del diseño del framework.
Aunque hay muchos enfoques posibles y factibles de documentar en unframework, no hay aún un estándar claro. La aproximación más segura es utilizar dos o más enfoques discutidos anteriormente.
