El Desarrollo del Framework Orientado al Objeto - El Coste del Analisis del Dominio y la Experiencia

Como se mostró anteriormente, los frameworks se crearon para generarar aplicaciones para un dominio específico. Para este propósito, una de las fases del desarrollo del frameworks es el análisis del dominio. A diferencia de la fase del requisito de los sistemas de software, el análisis del dominio cubre una clase entera de problemas El análisis del dominio intenta caracterizar el tamaño y la complejidad de un dominio elegido. Si el dominio es demasiado grande,éste desperdicia tiempo en recolectar y evaluar la información y sus recursos. Además, el tiempo que se demora en desarrollar el framework y el costo del mismo serían excesivos; es más, será necesario tener individuos familiarizados con el dominio, con los prototipos o los sistemas de software similares. Pero encontrar la experiencia que cubra un dominio grande es bastante difícil.

---

Por otra parte, si uno elige un dominio demasiado estrecho, se reduce la aplicabilidad del framework y las aplicaciones generadas serán demasiado similares para justificar el esfuerzo de construir un framework. Es importante tener en cuenta qué puntos calientes son necesarios,cuales son los que realmente se necesitan en los requerimientos y los que son innecesarios o superfluos.

---

Con el tiempo y un framework llega a ser más maduro, cambia y se desarrolla por consiguiente. Este proceso puede representar la alteraciónde su arquitectura de configuración, pues aparecen nuevos requerimientos que no tenían soporte, y muchas otras nuevas causales. Mientras tanto, las aplicaciones generadas usando el framework también evolucionan y cambian.

---

Cómo es posible compatibilizar ambas aspectos, el de las aplicaciones y el de la evolución del framework? Las aplicaciones basadas en frameworks pudieron ser dejadas de lado si se cambia o discontinúa un framework. Sin embargo no hay una solución clara, y ciertamente la mayoría de la gente sufrirá con la inestabilidad diciendo que "aquí no pasaria nada," al rechazar utilizar cualquier framework no construido por sí mismos. El único consejo posible para esta situación es estudiar cuidadosamente el framework que se utilizará; un framework bien diseñado e implementado no será tan volátil como mal concebido. Cuando hablamos que un framework está "bien diseñado" significa que los frameworks deben tener documentación sólida y resolver los requerimientos del dominio. Un framework que mantiene el concepto de encapsulación orientado al objeto y contiene un interfaz público bien definido es probable siga siendo compatible en el nivel de interfaz a través de actualizaciones y revisiones. La evaluación del diseño del framework y/o su implementación no es siempre directa; uno debe considerar la experiencia del diseñador, la complejidad del proceso del instantiación, los requisitos resueltos y no resueltos, y tambien la actualización del mapa de la ruta de trabajo, que contiene los planes para poner al día el framework, si es que representará un rediseño completo en cada nueva versión o simplemente una subsiguiente actualización compatible.