frameworks y componentes - · pdf file¿frameworks y arquitectura de software? es decir,...

1

Frameworks y Componentes(... ¡¡¡reutilizar, reutilizar, reutilizar!!! ...)

Universidad de los AndesDemián Gutierrez

Abril 2010

Frameworks

Diseño Arquitectónico


Arquitectura del Software

Bibliotecas /Componentes

Patrones de Diseño

Clases / Funciones

Frameworks(Marcos)

EstilosArquitectónicos

4

¿Qué es un Framework?

¿A quienes les gusta la TV?

¿Telenovelas?¿Series de TV?

¿Qué tiene que ver esto con el uso de frameworks o componentes?

5


El término framework 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

6


¿Telenovelas?¿Series de TV?

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.

7


¡La Búsqueda de la Generalidad y la Reusabilidad!

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

8

¿Cómo ayuda un framework al desarrollo de software?

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

9

¿Cómo ayuda un framework al desarrollo de software?

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

10

Un framework es una forma de reutilizar una arquitectura de

software

¿Qué relación tiene un framework con los estilos arquitectónicos?

¿Qué relación tienen un framework con otros aspectos del diseño y

Arquitectura de Software?

¿Frameworks y Arquitectura de Software?



Patrones de Diseño

Clases / Funciones

Frameworks(Marcos)


Visión estructural y/o dinámica de cómo debería ser un sistema, no

utilizable o ejecutable directamente (“out of the box”)

Visión estructural y/o dinámica de cómo se pueden resolver ciertos

problemas comunes de diseño, no utilizable o ejecutable directamente

(“out of the box”)

Implementación y funcionalidad concreta, utilizable directamente desde el código de la

aplicación implementada

Aplicación

Men

or n

ivel de ab

stracción

definen

implementan

ImplementanSe diseñan usando (entre otras cosas)

UtilizanDefinen laArquitectura

12

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 especifica de su propio

proyecto

Pree, W (1994), "Meta Patterns-A Means For Capturing the Essentials of Reusable Object-Oriented Design", Proceedings of the 8th European Conference on Object-Oriented

Programming (Springer-Verlag): 150–162

¿Frameworks, y la teoría de las zonas fr ías y las zonas calientes?

13


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.

14

¿Frameworks, y la teoría de las zonas fr ías y las zonas calientes?

Instanciación 1 Instanciación 2

frozen spots

Framework

hot spots(hooks)

funcionalidadañadida (Cliente)

comportamientopor defecto

Inve

rsió

n de

Con

trol

(Io

C)

15

¿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

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)

En el medio están todos los matices posibles...(Caja Blanca y Caja Negra al mismo tiempo -> Caja Gris)

Más fácil d

e usar

Más d

ifícil de p

rog

ramar (E

n g

eneral)

¡El ideal, el sueño de todo desarrollador es hacer un framework completamente caja negra!

16

EJEMPLO:¡Implementemos un

Solitario!

Frameworks: Caja Blanca, Caja Negray Ejemplos.. .

17

Un solitario es un juegoen el que hay:


Cartas: Unidades básicas que se

mueven de un lado a otro, bien sea de

forma separada o en grupos

Bases: Lugares donde poner cartas, aplican reglas sobre

que cartas se pueden poner /

quitar

Pilas: Grupos de cartas, generalmente sobre una base (o en movimiento, a modo

de un grupo de cartas). Aplican

reglas sobre que cartas se pueden

quitar o añadir de/a una pila

18

El objetivo del juego es acomodar las cartas de cierta forma o

eliminar todas las cartas de las mesa, siguiendo una serie de

reglas predefinidas que dicen que cartas se pueden mover de una pila

a otra...


19

Prácticamente, se pueden definir un conjunto infinito de posibles reglas y

juegos distintos usando el mismo principio


Sólo acepta una “A” de cualquier color

NO

OK

20


Una pila que sólo acepta cartas con valor

descendiente y color alterno

NO

NO

SI

21


Una pila de la que sólo se puede sacar la carta del tope o

grupos de cartas que lleguen alternando su

color con valor descendente al tope

NO

SI

SI

22

Si vamos a programar un juego de solitario hay dos opciones:

1) Programar un sólo juego en especifico, con reglas especificas

2) Programar una serie de clases (framework) que permitan luego “configurar” las reglas

fácilmente para así poder crear cualquier solitario que se requiera

Para la opción 2, a continuación una posible implementación:


23


MainFrame representan la IU del

solitarioEs la clase encargada de cargar las cartas

del disco

Utilitarios y clases base de Swing

Utilitarios en general

Objetos del Solitario, Cartas, Pilas, “Dibujables”, etc

Panel en el que se dibujan las cartas (o que “contiene”

el solitario)

El código de este ejemplo va adjunto a lastransparencias, son los proyectosCardGames01 y CardGames02

24


GamePanel se encarga de dibujar las pilas de cartas (que a

su vez dibujan las cartas individuales) así como de manejar los

eventos del ratón

Los eventos del ratón se manejan de forma genérica por parte de GamePanel, es decir, las reglas de que cartas se pueden quitar de una pila o poner en otra no están implementadas en

esta clase

Las reglas de las pilas están implementadas en

cada una de las pilas. Por ejemplo borrowCards es invocado para ver si es

posible quitar un grupo de cartas de una pila,

acceptCards es invocado para ver si es posible

poner un grupo de cartas en una pila particular. Toda la lógica y la verificación se implementa en estos dós métodos de las distintas

pilas

Ver diagramas de secuenciade las siguientes láminaspara entender el proceso completo de tomar de una pila y poner en otra

25


Lo que sucede cuando el usuario aprieta el ratón (sobre una pila)

Si el puntero no está sobre una pila

srcStack es nulo

Si no se permite (por reglas) mover las

cartas selecionadas, tmpStack es nulo

26


Lo que sucede cuando el usuario libera el ratón (sobre una pila)

Si el ratón no se libera sobre una pila tgtStack

será nulo

Si acceptCards retorna falso, quiere decir que la pila por sus “reglas” no aceptó las cartas, y

que deben ser devueltas a la pila de

origen

27


Es decir, desde el punto de vista de GamePanel (ver diagramas anteriores) toda la lógica de si es posible

sacar una o más cartas de una pila o poner una o más cartas en una pila está implementada en la clase Stack,

específicamente en los métodos borrowCards y acceptCards (respectivamente)

¿Como podríamos tener pilas que tengan distintos comportamientos? Por ejemplo, ¿una pila que acepte

sólo cartas del mismo color y otra que acepte cartas de colores intercalados?

28


Que tal si se especializa Stack en distintos tipos de pilas, donde cada una de ellas sobrescribe (overrides) el método

acceptCards() y define reglas particulares para cada tipo de pila que se necesite

¿Desventajas? ¿Inconvenientes?

Acepta cartas sólo del mismo color

Acepta cartas de colores intercalados

Acepta cartas sólo de valores descendentes

Acepta cartas sólo de valores ascendentes

29


El problema es que esta estrategia puede terminar en una situación poco deseable, en la que se produzca una

explosión de clases especializadas con funcionalidad redundante, tal como ocurre en el diagrama anterior...

... y eso que no se ha considerado la necesidad de especializar el comportamiento de borrowCards

Acepta cartas sólo de valores descendentes y del

mismo color

Acepta cartas sólo de valores descendentes y del mismo color (¿¿¿Opps, no

esta esto repetido???)

Acepta cartas sólo de valores ascendentes y

decolores intercalados, etc, etc, etc...

30


Es importante notar, que esta estrategia es de tipo “caja blanca”, es decir, usa herencia. Los “Hot Spots” son los

métodos acceptCards y borrowCards, que son necesarios sobrescribir para modificar el comportamiento de la pila (o del

framework)

¿Alguna solución al problema de la explosión de clases especializadas?

31


En este caso, una pila está compuesta de una serie de “Estrategias” de “prestamo” (BorrowRule) y de “aceptación”

(AcceptRule) de cartas que se pueden combinar independientemente unas de otras

Define la interfaz de una “pequeña” clase

que establece un comportamiento de

“prestamo” de cartas

Define la interfaz de una “pequeña” clase

que establece un comportamiento de

“aceptación” de cartas

La clase pila está compuesta por una serie de reglas de “prestamo” y ”aceptación” de cartas

32


Cada una de las clases de este color

definen una regla para poder “prestar” una carta o un grupo de

cartas de la pila

Las clases verdes definen una regla de aceptación, por ejemplo DescendantAcceptRule que sólo acepta cartas con valores consecutivos descendientes, que se pueden encadenar con otras reglas,

como SameColorAcceptRule, para obtener una pila que solo acepta cartas descendientes consecutivas en valor del mismo color

El método addAcceptRule recibe una instancia de

una regla y la añade a la lista de reglas a verificar al momento de solicitarle a la pila que “acepte” una carta

o un grupo de cartas.El método acceptCards

funciona de la forma tradicional, sólo que ejecuta la cadena de

reglas añadidas y si todas pasan, entonces acepta la carta o el grupo de cartas

33


En general, esta es una estrategia completamente caja negra, porque no es necesario conocer como funciona una

clase particular del framework (Stack en este caso) para poder heredar y sobrescribir métodos, simplemente basta con

implementar una serie de interfaces y componer la pila de estas “reglas” que son las que hacen el trabajo

34


En este ejemplo (y en los que vimos de patrones de diseño) se ve la importancia de programar en función de interfaces

bien definidas, que pueden ser implementadas posteriormente a gusto de los programadores y según las

necesidades que se tengan

35

TODO:Los ejemplos del Juego de Cartas Caja Negra aún no están disponibles (para el

jueves los tengo)

Diagramas de secuencia del Juego de Cartas Caja Negra


36

¿Cómo funciona? ¿Qué brinda un framework?(¿Recuerda el ejemplo de la TV?)

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

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)

37

¿Cómo funciona? ¿Qué brinda un framework?(¿Recuerda el ejemplo de la TV?)

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)

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

38

To framework or not to framework? (use)

Si tienen que desarrollar una aplicación WEB...

(O un compilador, o una aplicación de escritorio, o un

editor gráfico o ...)...tienen dos opciones

39


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

40


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?

41


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)

42


Sin Framework

Con Framework

¡Tiempo Ganado al usar el Frameworkvs

Curva de Aprendizaje!

43

Generalmente, si hay un buen framework que cumple con

las expectativas no hay excusa para no utilizarlo...


44

To framework or not to framework? (development)

¿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

45


YAGNI: You Ain't Gonna Need It

46

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


47

¿Cómo se “aprende” a desarrol lar frameworks?

¿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

Componentes



Arquitectura del Software


Patrones de Diseño

Clases / Funciones

Frameworks(Marcos)


TODO: Lectura :-(

(Sommerville 14)(Diseño con

Reutilización)

51

¿Componentes?

Sería fantástico poder desarrollar software de la misma forma en que se desarrolla el hardware: basándose (en la mayoría de los casos) en un conjunto específico y finito de componentes

52

¿Componentes?

Sin embargo...

¿Recuerda usted las siguientes

transparencias?

Desarrol lo Basado en Reuti l ización(Componentes)

Fuente; Sommerville / Ingeniería del Software (Excepto lo rojo)

Bosquejar losRequerimientos

delSistema

BuscarComponentesReutilizables

(COTS)(Ej. Aplicaciones

Listas o CasiListas)

DiseñoArquitectónico

BuscarComponentesReutilizables

(COTS)(Ej. Librerías,Frameworks u

otros)

ModificarRequerimientos

Acorde a losComponentesEncontrados

ModificarComponentesEncontrados

+

Diseñar elSistema

Utilizando losComponentesReutilizados

ModificarComponentesEncontrados

+

COTS: Commercial Off the Shelf

“Almacén/Catálogo de Componentes Reutilizables

Desarrol lo Basado en Reuti l ización(Componentes)

El sistema se construye “uniendo” componentes existentes

El costo del sistema se puede reducir notablemente debido a la reutilización

***Se está limitado a los componentes existentes, es necesario negociar los requerimientos en base a estos, o modificar los componentes (lo que no siempre es fácil)

para lograr satisfacerlos (o ambas cosas)***

Se necesita todo un “armazón” o un “lenguaje” para poder unir los componentes

55

¿Componentes?

Los componentes de software reutilizables son artefactos auto-contenidos, claramente

identificables que describen y/o ejecutan funciones específicas y tienen interfaces claras, una

documentación apropiada y un estado de reuso definido

Sametinger, 1997

Un módulo de bajo acoplamiento y alta cohesión que denota una abstracción simple

Booch, 1987

56

¿Componentes?

Cualquier tipo de recurso [elemento] de software que pueda ser reutilizado (por ejemplo, módulos o

código, diseños, especificaciones de requerimientos, conocimiento de un dominio, experiencia de

desarrollo o documentación, etcétera)

Hooper and Chester, 1991

Los componentes de software son definidos como módulos de software reutilizables,

auto-contenidos, pre-probados, pre-fabricados que ejecutan funciones específicas y enpaquetan

datos y procedimierntos

57

¿Componentes?

En general, un componente debe tener las siguientes características:

Debe ser autocontenido:

Un componente no debe requierir la reutilización de otros componentes para cumplir su función, debe

tener todo lo necesario para poder funcionar.

Sin embargo, es posible que un componente pueda depender de otros componentes para poder

funcionar.

58

¿Componentes?


Deben ser identificables:

Deben estar contenidos en un archivo (.jar, .zip, .dll, .so, .exe, etcétera) que facilite su indización y

recuperación.

¿Por qué indización y recuperación?

59

¿Componentes?


Describen o ejecutan (cumplen) una función:

Ejecutan una función específica o describen la funcionalidad de un programa

(¿Describen? Ver Interfaces / API)

60

¿Componentes?


Deben tener interfaces claras y deben ocultar los detalles de su diseño interno:

...el título lo dice todo...

61

¿Componentes?


Deben ser mantenidos para facilitar una reutilización sistemática:

Es necesario saber quién es el propietario del componente, quién lo mantiene (¿Lo mantienen?),

quién brinda soporte (¿Hay soporte? ¿De qué tipo?), cuál es la calidad del componente, etcétera.

No vale la pena utilizar un componente con defectos o que no tenga mucha actividad o que no se le haga

mantenimiento de forma adecuada (mantener componentes es costoso, al igual que los

frameworks)

62

¿Componentes?

Deben una documentación adecuada que facilite:

La recuperación del componente desde el repositorio, la evaluación del componente, su

adaptación al nuevo ambiente y su integración con otros componentes del sistema en que se reutiliza


63

La importancia de las interfaces

64

Bien...

Pero en este punto,¿Cuál es la diferencia entre

un framework y un componente?

¿Cómo elegir un framework o un componente?

65

¿Cómo saber si vale al pena utilizar un framework o

componente específico?(Algunos tips para evaluar

frameworks y componentes)


66

Primero:

Tenga bien claro el contexto y el para qué necesita el

framework...

...y luego considere lo siguiente...


67

¿Qué es un Patrón de Diseño?

Asegúrese que el framework/componente está siendo mantenido activamente, revise los registros de bugs y los tiempos entre las correcciones. Revise los tiempos entre

releases, el tiempo desde que se liberó la última versión, la actividad del repositorio de código, etcétera*

Verifique que el framework/componente está siendo utilizado por otros desarrolladores, busque que opinan otros equipos

de desarrollo, que problemas han enfrentado, etcétera

¿Qué otros frameworks/componentes similares existen? ¿Cómo se comparan entre si frameworks/componentes

similares? ¿Qué opciones hay?

*Si el último release fue hace más de un año – año y medio probablemente no hay mucha actividad (aplican sus excepciones)

68


Determine la calidad del soporte, ¿Hay soporte oficial (de los desarrolladores)? ¿De qué tipo? ¿Pago o gratuito? ¿Precios?

¿Hay una comunidad sólida alrededor del framework? ¿Es posible obtener soporte de la comunidad? ¿Hay foros? ¿Wiki? ¿Qué tanta actividad hay en los foros? ¿Cuál es el trato y la

calidad de la comunidad y de los desarrolladores del framework? *

*Esto varía de proyecto en proyecto, mientras más grande sea el framework/componente mayor la comunidad y mayor la frecuencia de los posts. Lo importante es asegurarse de que el proyecto no

esta “muerto”

69


¿Cuál es la dificultad de aprendizaje del framework? ¿Cuál es la curva de aprendizaje? ¿El costo de aprende a usar el

framework vale los beneficios?

¿Cuánta documentación existe? ¿Cuál es la calidad de la documentación? ¿Manuales? ¿Ejemplos de uso? ¿Tutoriales?

¿Cuál es la calidad del framework? ¿Cómo está organizado el equipo que lo desarrolla? ¿Cuál es el proceso de desarrollo? ¿Los releases se planifican? ¿Los planes se cumplen? ¿Se

desarrollan pruebas? ¿Hay suites de pruebas? ¿Certificaciones? etcétera

70


¿El framework/componente es open source / free software (son dos cosas diferentes) o es propietario? ¿Cuáles son las ventajas / desventajas de cualesquiera de las tres opciones

en el contexto de uso del framework? (Esto también va asociado al punto de la documentación)*

¿Es adecuado el framework/componente para el contexto/aplicación en el que se necesita utilizar?

(Quizá esto es lo primero que se debería considerar)

*Esto es importante porque puede ser la diferencia entre poder “parchar” y “extender internamente” el framework en caso de ser

necesario (o no, si no es al menos código abierto)

¿Cuánto cuesta? ¿Cuál es la forma de pago? ¿El cliente puede correr con los costos? ¿El equipo de desarrollo puede correr con los costos (libre para desarrollo / pago para uso)?

71

...y seguramente hay muchas otras variables adicionales a

tomar en cuenta según el caso, de modo que mantenga

los ojos bien abiertos...


72

Gracias

¡Gracias!

frameworks y componentes - · pdf file¿frameworks y arquitectura de software? es decir,...

Documents