Ingeniería de Software

Clase 6:
Frameworks

Hugo R. Cordero S.
Clase 1
 Objetivos
2

 Comprender la utilización de los frameworks en el

desarrollo de las aplicaciones actuales
 Conocer los diferentes conceptos relacionados a los
frameworks
 Conocer las implicancias y requerimientos para el
desarrollo de frameworks
 Comprender los framework de persistencia
 Temas
3

1. Introducción
2. Definición de Framework
3. ¿Desarrollar o utilizar un framework?
4. Clasificación de los frameworks
5. Persistencia y frameworks de persistencia
 Introducción
4

Patrones
 Son estructuras reutilizables en la construcción de
aplicaciones, puede ser del tipo: arquitectónicos, de diseño,
dialectos o de código, entre otros.
Patrón de Diseño
 Es una solución abstracta a un problema de diseño que
aparece muy frecuentemente, expresada mediante un
conjunto de relaciones e interacciones entre sus
componentes.
 Introducción
5

Arquitectura de Software
 Se define como la estructura o estructuras del sistema, la
cual comprende elementos de software, las propiedades
externas visibles de estos elementos, y las relaciones entre
ellos
 La arquitectura define la estructura a través de
descomposición del sistema en componentes / módulos /
subsistemas
 La comunicación de componentes involucra:
 Mecanismos de traspaso de datos
 Control del flujo dentro del sistema
 Introducción
6

Diseño arquitectónico
 Tiene como objetivo principal desarrollar una estructura del
sistema modular representando las relaciones de control
entre los módulos
 Trata de no centrarse en los detalles y código de los

procedimientos, sino centrarse en el software como un todo

 Incluye las actividades básicas de:

 Estructuración del sistema

 Modelado del control
 Descomposición modular
 Introducción
7

Estilos arquitectónicos
 Expresan esquemas de organización estructural esencial
para un sistema de software, que consta de sub-sistemas,
sus responsabilidades e interrelaciones
 Son una transformación que se impone al diseño de todo el

sistema
 Algunos estilos:

 De flujo de datos: Tuberías y filtros

 De llamada y retorno: basado en componentes, modelo de capas
 Centrados en datos: repositorios
 Entre pares: orientado a servicios
 Introducción
8

¿Y framework?
 En el cine, la TV y la literatura existe un concepto similar:

La idea consiste en tomar una plantilla 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.
 Introducción
9

Framework
 El término se podría traducir al español como armazón o
andamio, que viene a ser una estructura genérica que se
utiliza para colocar diversos elementos según sean
necesarios
 ¿Qué es un Framework?
10

 Un framework (armazón / marco), es una abstracción en la

que cierto código común provee una funcionalidad
genérica, que puede ser sobrescrita o especializada
deforma selectiva por medio de código provisto por los
clientes del framework (desarrolladores de software)
 Un framework es una solución incompleta (no funcional)
pero a diferencia de los estilos arquitectónicos o los
patrones de diseño, es una solución concreta
(implementada) a un problema recurrente (dominio) bien
conocido
 Framework
11

Relación con los patrones de diseño

 Se complementan con los frameworks

 Los patrones de diseño tienen una granularidad más fina

que los frameworks

 Un framework suele estar compuesto por una colección de

patrones de diseño
 Framework
12

Relación con la Arquitectura

 Framework
13

Relación con la Arquitectura

 Framework
14

Relación con la Arquitectura

 Los frameworks son las herramientas, mientras que la

Arquitectura es el diseño resultante:

 Framework
15

Ventajas
 Permite a los arquitectos y desarrolladores concentrar su
tiempo en lograr los requerimientos de la aplicación, en
lugar de tener que hacerlo en los detalles (infraestructura)
de bajo nivel necesarios para obtener un sistema funcional
 Todo esto reduce el tiempo total de desarrollo de la

aplicación y aumenta la productividad de los

desarrolladores.
 Framework
16

Ventajas
 Un framework facilita el desarrollo de aplicaciones porque
generalmente este ya ha sido usado y probado en otros
sistemas, lo que reduce la probabilidad de introducir
errores accidentales en el sistema a desarrollar
 Ejemplo:

 Un equipo está desarrollando un sistema WEB para un banco: Al

usar un framework, el equipo puede enfocarse en implementar las
operaciones de retiro y transferencia de dinero, en lugar de tener
que enfocarse en la mecánica del manejo de las peticiones HTTP, el
manejo de las sesiones de los usuarios, el estado de la aplicación,
etc.
 Framework
17

 Los frameworks están conformados por zonas frías (frozen

spots) y zonas calientes (hot spots)

Zonas Calientes (hot spots)

 Las zonas calientes representan los puntos en los que es

posible añadir funcionalidad especifica de la aplicación.

Los programadores modifican/personalizan el
comportamiento del framework añadiendo código en las
zonas calientes
 Framework
18

Zonas Calientes
 Los frameworks en si mismos no son usualmente ejecutables.
La idea es rellenar 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.

La instanciación si es ejecutable
 Framework
19

Zonas Frías (frozen spots)

 Las zonas frías definen la arquitectura general de un
sistema de software: sus componentes básicos y las
relaciones entre estos. Esas partes permanecen inalteradas
(congeladas) en cualquier instanciación del framework
 Framework
20

Zonas frías y zonas calientes

 ¿Qué brinda un Framework?
21

Inversión de Control (Inversion of Control / IoC)

 El desarrollador ya no mantiene el flujo de control, es decir,
éste no es manejado por el “invocador” o por “el código
cliente”, sino que es manejado por el framework en si mismo
 Basada en el llamado “Principio de Hollywood”:

 No nos llame, nosotros lo llamaremos

 ¿Qué brinda un Framework?
22

Inversión de Control
 ¿Qué brinda un Framework?
23

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
 ¿Qué brinda un Framework?
24

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
 Hook = Hotspot = Plug-point

 Puntos donde el framework puede

ser personalizado.
 ¿Qué brinda un Framework?
25

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)
 Frameworks de caja blanca y de
26
caja negra
Caja Blanca
 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
 Frameworks de caja blanca y de
27
caja negra
Caja Blanca
 Frameworks de caja blanca y de
28
caja negra
Caja Negra
 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 por composición y delegación de
comportamiento entre objetos.
 El ideal, el sueño de todo
desarrollador es hacer un
framework completamente caja
negra!
 Frameworks de caja blanca y de
29
caja negra
Caja Negra
 Utilización de Frameworks
30

 Por ejemplo si se tiene que desarrollar una aplicación WEB

(o un compilador, o una aplicación de escritorio, o un editor
gráfico o ...) tenemos las siguientes opciones:
 Desarrollar desde cero
 Tomar una aplicación que ya esté desarrollada y adaptarla a
las necesidades actuales de la aplicación requerida
 Utilizar un framework
 Utilización de Frameworks
31

Opción 1
 Desarrollar desde cero (“from scratch”) y para esto es
necesario:
 Definir la arquitectura del software
(arquitectura general, estilos arquitectónicos, etc.)
 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.
 Utilización de Frameworks
32

Opción 2
 Tomar una aplicación WEB que ya esté desarrollada 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...
 Esta opción en realidad no implica un framework en si mismo,
pero es una primera buena aproximación…
 Utilización de Frameworks
33

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
 Utilización de Frameworks
34

Tiempo ganado por el uso de frameworks

 ¿Desarrollar un framework?
35

 ¿Vale la pena desarrollar un framework?

 ... depende ...
 Crear un framework es en parte más arte que ciencia...
 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
 ¿Desarrollar un framework?
36

 De las opciones 1 y 2 anteriormente explicadas,

probablemente la 2 termine 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
 ¿Desarrollar un framework?
37

Habilidades para desarrollarlos

 Fundamental conocimientos en diseño y programación de
software
 Que practique la programación

 Trabaje en problemas de diseño: cometa errores, reconozca

los errores cometidos y encuentre soluciones.

 Conozca y use patrones de diseño

 Use frameworks ya existentes

 Vea el código de frameworks ya existentes (extienda

frameworks)
 Clasificación de Frameworks
38

 Frameworks de presentación
 Struts, JSF, ADF, ICEFaces, Richfaces
 Frameworks de componentes/servicios
 Spring, Symfony, Zend, OSGi
 Frameworks de persistencia
 Hibernate, TopLink, iBatis, ADO.NET
 Frameworks Web
 Play, Ruby on Rails, CodeIgniter, Laravel, Silverlight, JavaFX
 Frameworks JavaScript para aplicaciones web
 Backbone.JS, AngularJS, Ember, NodeJS
 Contenedores
39

 Contenedores o “containers” describe cualquier componente

que puede contener otros componentes dentro de sí mismo.
 Algunos autores definen a los contenedores como
frameworks dentro de los cuales se ejecuta objetos y código
de aplicación
 Se puede decir que son frameworks para el ensamblado de
componentes de diversos orígenes
 Contenedores
40

Contenedores pesados y livianos

 A los contenedores del estilo EJB 2.1 (tecnología Java de
componentes) se les denominó pesados por todo el trabajo
adicional necesario para poder hacer uso de ellos y
además porque requieren de una gran maquinaria para
funcionar.
 Esta maquinaria extra hace que el tiempo de arranque de
la aplicación sea extenso y aumenta el requerimiento de
memoria.
 Contenedores
41

Contenedores pesados y livianos

 También influyen en el nombre de liviano o pesado lo
complejo que es aprender a usar la tecnología y qué tan
fáciles probar los componentes desarrollados con ella.
 En consecuencia, se les llama livianos a los que requieren

pocos recursos para funcionar, son simples de aprender,

rápidos y fáciles de probar.
 Ejemplos:

 Spring
 Pico
 NFactory
 Persistencia
42

 Es la capacidad que tiene un objeto de perdurar fuera del

proceso que lo creó. El estado de un objeto puede ser
almacenado en disco y recuperado en un futuro.
 Una capa de persistencia encapsula el comportamiento
necesario para mantener los objetos. O sea: leer, escribir y
borrar objetos en el almacenamiento persistente.
 Framework de persistencia
43

 Guardar y recuperar objetos en / desde un almacenamiento

persistente.
 Manejar transacciones del tipo commit y rollback.
 Diseño que de soporte a:
 Extensión para permitir múltiples soportes de almacenamiento:
 BD Relacionales.
 Ficheros, etc.
 Facilidad de uso
 Ser muy transparente
 Reutilización y Extensibilidad
 Framework de persistencia
44

 JDO
 TopLink
 Hibernate
 iBATIS / MyBatis
 EJB 2.1 al 3.0
 JPA
 Doctrine
 ADO.NET Entity
 JDO (Java Data Objects)
45

 API que proporciona una forma estándar y sencilla de

conseguir la persistencia de objetos. Intenta solventar los
problemas de persistencia y mapeo objeto-a-datos y datos-
a-objeto
 Permite trabajar con objetos POJOs (plain old Java objetcs)
en lugar de con APIs propietarios
 Fue desarrollado con la JSR-12
 JPA (Java Persistence API)
46

 Es la API de persistencia desarrollada para la plataforma

Enterprise de Java, e incluida en el estándar EJB 3
 JPA es un estándar ORM
 Actualmente disponible para JSE y JEE
 Definida dentro del paquete javax.persistence
 Definido según el estándar JSR 220 y JSR 317
 Es la materialización de experiencias de distintas soluciones
de ORM para java
 JPA
47

Conceptos
 Entidad: objeto con las anotaciones adecuadas para realizar
la persistencia en la BD
 POJO: Plain Old Java Object

 Anotación: Añadir metadatos (datos descriptivos al código

fuente)
 JPQL: Java Persistence Query Language

 NamedQuery: Consultas JPQL

 NativeQuery: Consultas SQL que se traducen a objetos de

entidad
 JPA
48

2 objetos principales
 Los cuales se encargan de realizar la manipulación y
búsqueda de las entidades:
 EntityManagerFactory
 EntityManager
 JPA
49

Ciclo de vida

 En estado “Managed” ya representa a un objeto de la base

de datos. Es gestionado por el EntityManager.
 En estado “Detached” ya no está asociado, puede ser porque
se cerró la conexión o se liberó al objeto.
 Resumen
50

 Un framework es una abstracción en la que cierto código

común provee una funcionalidad genérica, que puede ser
sobrescrita o especializada deforma selectiva por medio
de código provisto por los clientes del framework
(desarrolladores de software)
 Los frameworks tienen zonas frías y zonas calientes.

 El ideal, el sueño de todo desarrollador es hacer un

framework completamente caja negra!
 Un framework de persistencia es un conjunto cohesivo de
clases que colaboran para prestar servicios a la parte
fundamental e invariable de un sistema lógico
 JPA es la API de persistencia desarrollada para la
plataforma Enterprise de Java
 ¿Preguntas?
51

 ¿Cuáles son las fortalezas y debilidades que

ve en un framework?
 Referencias
52

 Ingeniería de Software: Un enfoque práctico (7ma edición) Roger S.

Pressman
 Capítulo 12: Diseño basado en Patrones
 Ingeniería del Software (9na edición) Ian Sommerville
 Capítulo 16: Reutilización de Software
 Links:
 http://foro.codecompiling.net/printthread.php?tid=1062
 http://www.slideshare.net/piojosnos/clase-09a-frameworks
 http://stackoverflow.com/questions/2190625/what-is-the-difference-
between-framework-and-architecture
 http://www.slideshare.net/JWBurget/what-is-an-architectural-framework
 http://pubs.opengroup.org/architecture/togaf8-doc/arch/chap02.html
 http://en.wikipedia.org/wiki/Enterprise_architecture_framework