FRAMEWORKS

Introducción
En el cine, la TV y la literatura existe un concepto similar, la idea es que es posible tomar una
plantilla particular de una historia y reusarla (repetirla) una y otra vez en diferentes contextos,
con diferentes personajes, en distintas épocas, etc. Eso se puede ver como un “framework”
para escribir historias.

Los frameworks tienen como objetivo principal ofrecer una funcionalidad definida, auto
contenida, siendo construidos usando patrones de diseño, y su característica principal es su alta
cohesión y bajo acoplamiento. Para acceder a esa funcionalidad, se construyen piezas, objetos,
llamados objetos calientes, que vinculan las necesidades del sistema con la funcionalidad que
este presta. Esta funcionalidad, está constituida por objetos llamados fríos, que sufren poco o
ningún cambio en la vida del framework, permitiendo la portabilidad entre distintos sistemas.
Frameworks conocidos que se pueden mencionar por ejemplo son Spring
Framework, Hibernate, donde lo esencial para ser denominados frameworks es estar
constituidos por objetos casi estáticos con funcionalidad definida a nivel grupo de objetos y no
como parte constitutiva de estos, por ejemplo en sus métodos, en cuyo caso se habla de un API
o librería. Algunas características notables que se pueden observar:
 La inversión de control: en un framework, a diferencia de las bibliotecas, el flujo de control
no es dictado por el programa que llama, sino por el mismo.2
 La funcionalidad o comportamiento predeterminado: un marco tiene un comportamiento
predeterminado. Este comportamiento por defecto debe ser un comportamiento útil,
definido e identificable.
 Su extensibilidad: un marco puede ser ampliado para proporcionar una funcionalidad
específica. El frame, en general, no se supone que deba ser modificado, excepto en cuanto
a extensibilidad. Los usuarios pueden ampliar sus características, pero no deben ni
necesitan modificar su código.
DEFINICIÓN:
En el desarrollo de software, un framework o infraestructura digital, es una estructura
conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos
concretos de software, que puede servir de base para la organización y desarrollo de
software, para así ayudar a desarrollar y unir los diferentes componentes de un
proyecto.

Un Framework es un entorno o ambiente de trabajo para desarrollo; dependiendo del

lenguaje normalmente integra componentes que facilitan el desarrollo de aplicaciones
como el soporte de programa, bibliotecas, plantillas y más.

Un framework (armazon), es una abstracción en la que cierto código común provee una
funcionalidad genérica que puede ser sobrescrita o especializada de forma selectiva por medio
de código con funcionalidad específica provisto por los clientes del framework (desarrolladores
de software / programadores)

Un framework es una solución incompleta (no funcional) pero concreta (a diferencia de los
estilos arquitectónicos o los patrones de diseño) a un problema recurrente bien conocido

Los frameworks en si mismos no son usualmente ejecutables (a diferencia de un programa o

una aplicación). La idea es que el framework es utilizado en una aplicación particular, que
rellena los “hot spots” necesarios para satisfacer unos requerimientos particulares dentro de
un contexto de funcionamiento particular. El proceso anterior se llama “instanciación” del
framework.
 ARQUITECTURA DE SW:
 Descomposición Modular. Donde el software se estructura en grupos funcionales muy
acoplados.
 Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes
independientes pero sin reparto claro de funciones.
 Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde
la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa
para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra
modelado el negocio) y otra para el almacenamiento (persistencia). Una capa
solamente tiene relación con la siguiente.
Otras arquitecturas afines menos conocidas son:
 Modelo Vista Controlador.
 En pipeline.
 Entre pares.
 En pizarra.
 Orientada a servicios.
 Dirigida por eventos.
 Máquinas virtuales

MVC:
El patrón Modelo-Vista-Controlador es una guía para el diseño de arquitecturas de
aplicaciones que ofrezcan una fuerte interactividad con usuarios. Este patrón organiza la
aplicación en tres modelos separados, el primero es un modelo que representa los datos de la
aplicación y sus reglas de negocio, el segundo es un conjunto de vistas que representa los
formularios de entrada y salida de información, el tercero es un conjunto de controladores que
procesa las peticiones de los usuarios y controla el flujo de ejecución del sistema.

La arquitectura más utilizada en casi todos los frameworks es conocida como MVC
(Controlador, Modelo, Vista), esta arquitectura divide el desarrollo en tres grandes
partes:
 Modelo: Son los datos de la aplicación y su reglamentación.
 Vista: Es la presentación de los datos.
 Controlador: Procesa las peticiones de los usuarios y controla el flujo de ejecución del
sistema.
 TEORÍA DE HOT SPOTS AND FROZEN SPOTS
Según Pree, los frameworks están conformados por zonas congeladas (frozen spots) and zonas
calientes (hot spots)
Las partes congeladas definen la arquitectura general de un sistema de software, es decir, sus
componentes básicos y las relaciones entre estos. Esas partes permanecen inalteradas
(congeladas) en cualquier instanciación del framework.
Las partes calientes representan los puntos en los que los programadores pueden añadir su
propio código para añadir la funcionalidad específica de su propio proyecto
¿FRAMEWORKS CAJA BLANCA Y CAJA NEGRA?
Un framework caja blanca (white box) requiere que los usuarios tengan conocimiento
de la estructura y código interno del framework, generalmente vienen con el código
fuente y normalmente su comportamiento se extiende por medio del uso de subclases
y herencia
En el medio están todos los matices posibles... (Caja Blanca y Caja Negra al mismo
tiempo -> Caja Gris)
Un framework caja negra (black box) no requiere un entendimiento o conocimiento
profundo del funcionamiento interno (estructura / código) del framework.
Generalmente el framework se extiende componiendo y delegando comportamiento
entre objetos (Muchos de los cuales son las extensiones del usuario)
¡El ideal, el sueño de todo desarrollador es hacer un framework completamente caja
negra!
VENTAJAS
Las que se derivan de utilizar un estándar; entre otras:
 El programador no necesita plantearse una estructura global de la aplicación, sino que
el framework le proporciona un esqueleto que hay que “rellenar”.
 Facilita la colaboración. Cualquiera que haya tenido que “pelearse” con el código fuente de otro
programador (¡o incluso con el propio, pasado algún tiempo!) sabrá lo difícil que es entenderlo y
modificarlo; por tanto, todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los
desarrollos colaborativos.
 Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para
facilitar el desarrollo.
 Compatibilidad de Lenguajes
 Transparencia de proyectos de plataforma a plataforma
 Portabilidad de Arquitectura
 Integración con múltiples dispositivos.
 Desarrollo de aplicaciones de manera más sencilla, ya que cuenta con los
componentes necesarios incluidos.
 Reutilización de Código
 Maneja Política de diseño uniforme y organizado.
 Inversión de Control (Inversion of Control / IoC): El desarrollador ya no mantiene el
flujo de control, es decir, el éste no es manejado por el “invocador” o por “el código
cliente”, sino que es manejado por el framework en si mismo (El ejemplo de MVC /
Struts y PHP que veremos más adelante)
 Comportamiento por defecto: El framework brinda cierto comportamiento por
defecto, de modo que el cliente puede decidir personalizar o añadir funcionalidad en
ciertos puntos o puede simplemente conformarse con el comportamiento por defecto
provisto por el framework
 Extensibilidad: Debe ser posible extender el framework, bien sea sobrescribiendo
cierto código o añadiendo algún tipo de extensión (hook / gancho) o plug-in. Es decir,
 debe ser posible cambiar el comportamiento por defecto pre-definido en el
framework. En general, los puntos de extensión deben estar muy claros
 Código no-modificable del framework: El código del framework en general no debería
de poderse modificar, los usuarios deben de poder extender el framework pero no
deberían de poder modificar su código interno (a menos que deseen de forma explícita
arreglar algún problema o colaborar en el desarrollo del framework)

Un framework facilita el desarrollo de software permitiendo a los diseñadores y

programadores dedicar su tiempo a lograr los requerimientos de software en lugar de lidiar
con los detalles de bajo nivel necesarios para obtener un sistema funcional De esta forma se
puede reducir el tiempo total de desarrollo de la aplicación
Ejm:
Por ejemplo, un equipo que esta desarrollando un sistema WEB bancario al usar un framework
de desarrollo WEB puede enfocarse en el desarrollo de las operaciones de retiro y
transferencias de dinero en lugar de tener que enfocarse en la mecánica del manejo de las
peticiones HTTP o el manejo de las sesiones de los usuarios y el estado de la aplicación
TIPOS

CARÁCTER+ISTICAS:
Casi todos los frameworks comparten las mismas características de acuerdo a su tipo,
entre las que podemos destacar están:
 La Autenticación Incluyen mecanismos para la identificación de usuarios 4 de acceso.
mediante login y password y permiten restringir el acceso a determinas páginas a
determinados usuarios.
 El Acceso a los datos en archivos txt, xml por ejemplo mediante interfaces que
integran la base de datos.
 Abstracción de URLs y Sesiones No es necesario manipular directamente las URLs ni
las sesiones, el framework ya se encarga de hacerlo.
 Internacionalización que permite la inclusión de varios idiomas en el desarrollo.
Separación entre diseño y contenido.
 Controladores. La mayoría de frameworks implementa una serie de controladores
para gestionar eventos, como una introducción de datos mediante un formulario o el
acceso a una página. Estos controladores suelen ser fácilmente adaptables a las
necesidades de un proyecto concreto.

To framework or not to framework?

Opción 1:
Desarrollar desde cero (“from scratch”) y para esto es necesario: Definir la arquitectura del
software (arquitectura general, estilos arquitectónicos, etcétera) Codificar, validar y probar la
arquitectura Codificar la funcionalidad propia del software (aunque esto algunas veces se hace
mezclado con el paso anterior) Encontrar errores y problemas en la arquitectura, refinar la
arquitectura, rehacer parte de la funcionalidad, hacer refactors en el código, etcétera
Opción 2: Tomar una aplicación WEB que ya esté desarrollada (¿un framework?) y adaptarla a
las necesidades actuales de la aplicación requerida Comprender la aplicación (framework)
existente Usar la arquitectura ya definida / refinada y codificar la funcionalidad... Claro, la
opción 2 en realidad no implica un framework en si mismo, pero es una primera buena
aproximación... ¿Que tal si añadimos una opción 3?
Opción 3: Tomar una framework (para desarrollar aplicaciones WEB) Comprender / aprender a
usar el framework Usar la arquitectura ya definida / refinada en el framework y codificar la
funcionalidad... ¡¡¡Aprender a vivir con las limitaciones del framework y resistir la tentación de
desarrollar un framework propio!!! (a menos que... ver un par de láminas mas adelante)
Generalmente, si hay un buen framework que cumple con las expectativas no hay excusa para
no utilizarlo...
Nadie dice que no puede desarrollar un framework, de hecho, las opciones 1 y 2
(especialmente la 2) del ejemplo anterior probablemente terminen en el desarrollo de un
framework (a largo plazo) Simplemente se trata de hacer un cálculo adecuado de la relación
costo beneficio, recuerde que en muchos casos el objetivo principal es RESOLVER el problema
del cliente NO DESARROLLAR un framework
¿Vale la pena desarrollar un framework? ... depende ... Crear un framework es en parte más
arte que ciencia... (lamentablemente) Generalmente no es buena idea crear un framework, es
preferible buscar uno ya existente que resuelva el problema que se trata de abordar
Desarrollar un framework puede ser un proceso muy costoso (o lento), de modo que es
necesario asegurarse que se tendrá el adecuado retorno de inversión
¿Cómo se desarrollan las habilidades para desarrollar frameworks?
1.- Diseñe / desarrolle software (fundamental) 2.- Practique la programación (MUY
IMPORTANTE) 3.- Trabaje con los problemas de diseño, cometa errores, reconozca los errores
cometidos, encuentre soluciones, etcétera 4.- Use patrones de diseño 5.- Use patrones de
diseño (No es error de copy / paste) 6.- USE FRAMEWORKS YA EXISTENTES 7.- Vea el código de
frameworks ya existentes (extienda frameworks) 8.- Atrévase y desarrolle pequeños
frameworks que hagan pequeñas cosas