1. Definen una arquitectura adaptada a las particularidades de un determinado dominio de aplicación, definiendo de forma abstracta una serie de componentes y sus interfaces y estableciendo las reglas y mecanismos de interacción entre ellos.
2. Básicamente se presentan como un diseño reutilizable de todo o parte de un sistema, representado por un conjunto de componentes abstractos y la forma en que los componentes interactuan.
3. Presentan dos niveles:
3.1. Especificación de la arquitectura marco
3.2. Implementación del marco de trabajo (normalmente un lenguaje orientado a objetos).
4. Dependiendo de la extensión tenemos:
4.1. Marcos de trabajo de caja blanca
4.2. Marcos de trabajo de caja negra
4.3. Marcos de trabajo de caja de cristal
4.4. Marcos de trabajo de caja gris
5. A favor de:
5.1. A favor de la caja negra: Se evitan las dependencias entre la implementación del marco y sus clientes.
5.2. A favor de la caja gris: Más flexible que el anterior y similares ventajas.
5.3. Problema de los anteriores: Clarividencia. Obliga a que todos los interfaces se definan de antemano contemplando todos los usos futuros del marco. – Es posible redefinir componentes y métodos implementados. – Exige estar familiarizado con la implementación.
6. Referencia: http://babel.ls.fi.upm.es/~fred/sbc/arquitecturas_sw.pdf
7. Dependiendo de su aplicabilidad tenemos:
7.1. Marcos de trabajo horizontales
7.1.1. Válidos para todos los dominios de aplicación concretados en un aspecto del sistema.
7.1.2. Infraestucturas de comunicación, interfaces de usuario, entornos visuales, etc.
7.1.3. Marcos de trabajo distribuidos (Middelware Application Frameworks) o Plataforma de Componentes Distribuidos para integrar componentes distribuidas.
8. Marcos de trabajo verticales
8.1. Desarrollados específicamente para un dominio de aplicación.
8.2. Telecomunicaciones, fabricación, servicios telemáticos y multimedia, etc.
9. Marcos de trabajo para Componentes (Component Frameworks)
9.1. Verticales u horizontales, pero exclusivamente realizados para el desarrollo de sistemas basados en componentes reutilizables.
9.1.1. Image Slider
9.1.2. Content
9.2. Características especiales para tratar problemas propios de los SBC: Composición tardía, extensibilidad, ...)
9.2.1. 20 blog posts
9.2.1.1. Content
9.2.1.2. 1 image per post
9.2.2. listing with thumbnail then summary of 10 latest posts
10. El problema de la composición de marcos de trabajo.
10.1. Usualmente se necesitan utilizar varios y cada uno resuelve un problema concreto (p.ej. un MT vertical y dos horizontales).
10.1.1. Yes (add details)
10.1.2. No
10.2. Gestión del control de la aplicación, ya que los MT suelen tomar el control de la aplicación.
10.2.1. Yes (add details)
10.2.2. No
10.3. Adaptación de los servicios ofrecidos por cada uno de los MTs: los servicios ofrecidos por dos MT pueden no ser compatibles.
10.3.1. Yes (add details)
10.3.1.1. Search box
10.3.1.2. Google ads
10.3.1.3. New node
10.3.2. No
11. Ventajas de la utilización de marcos de trabajo:
11.1. Son composicionales. Son el grado más alto de reutilización dentro del desarrollo de software. El diseño arquitectónico se reutiliza. Reducción de costes/Mejora de la calidad. Están intrínsecamente unidos a los componentes ya que además de proporcionar funcionalidad de los componentes permiten la composición entre ellos de forma consistente.
12. Patrones de Diseño Un patrón es una solución probada que se puede aplicar con éxito a un determinado tipo de problemas que aparecen repetidamente en algún campo.
12.1. Ventajas:
12.1.1. Son soluciones simples y técnicas. – Muy prácticos (deslumbran) y útiles.
12.2. Desventajas:
12.2.1. Son soluciones concretas a problemas concretos. Libro de recetas, lo que hace difícil averiguar el patrón adecuado ante un problema concreto. (LePlus) No dejan huella: En una implementación es difícil saber que patrón se utilizó. (Ingeniería inversa). Facilitan la reutilización del diseño pero no tanto la de la implementación. No están formalizados (al menos no de forma simple).
12.3. Son útiles en cualquier fase del diseño:
13. Lenguajes de descripción de arquitecturas
13.1. Sirven para expresar la estructura de las aplicaciones. • Proporcionan los modelos, notaciones y herramientas que permiten describir los componentes y sus enlaces específicos.
13.2. Misiones:
13.2.1. Gestionar los diseños de alto nivel, adaptarlos a implementaciones específicas y permitir la selección de patrones o paradigmas de arquitecturas especificados previamente. Representar nuevos patrones de arquitecturas y nuevas formas de interacción entre los componentes, de forma que puedan ser reutilizados en diseños futuros. Aportar un conjunto de herramientas formales para demostrar propiedades sobre los sistemas diseñados (seguridad, viveza, ...) Aportar