Frameworks y Componentes

Transcripción

Frameworks y Componentes
(... ¡¡¡reutilizar, reutilizar, reutilizar!!! ...)
Universidad de los Andes
Demián Gutierrez
Abril 2010
1
Frameworks
Diseño Arquitectónico
Arquitectura
del Software
Diseño
Arquitectónico
Estilos
Arquitectónicos
Frameworks
(Marcos)
Patrones de
Diseño
Bibliotecas /
Componentes
Clases /
Funciones
¿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?
4
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
5
¿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.
6
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
¡La Búsqueda de la Generalidad y la Reusabilidad!
7
¿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
8
¿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
9
¿Frameworks y Arquitectura de Software?
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?
10
Estilos
Arquitectónicos
Menor nivel de abstracción
Patrones de
Diseño
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”)
Se diseñan usando (entre otras cosas)
Frameworks
(Marcos)
Bibliotecas /
Componentes
Definen la
Arquitectura
definen
Clases /
Funciones
Implementan
Implementación y
funcionalidad concreta,
utilizable directamente
desde el código de la
aplicación implementada
Utilizan
Aplicación
implementan
¿Frameworks, y la teoría de las zonas frías y
las zonas calientes?
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 ObjectOriented Design", Proceedings of the 8th European Conference on Object-Oriented 12
Programming (Springer-Verlag): 150–162
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.
13
¿Frameworks, y la teoría de las zonas frías y
las zonas calientes?
Framework
frozen spots
Inversión de Control (IoC)
comportamiento
por defecto
hot spots
(hooks)
Instanciación 1
funcionalidad
añadida (Cliente)
Instanciación 2
14
¿Frameworks caja blanca y caja negra?
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!
Más fácil de usar
Más difícil de programar (En general)
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
15
Frameworks: Caja Blanca, Caja Negra
y Ejemplos...
EJEMPLO:
¡Implementemos un
Solitario!
16
Un solitario es un juego
en 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
17
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...
18
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
O
K
19
Una pila que sólo acepta
cartas con valor
descendiente y color alterno
NO
SI
O
N
20
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
N
O
SI
SI
21
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:
22
MainFrame
representan la IU del
solitario
Panel en el que se dibujan
las cartas (o que “contiene”
el solitario)
Utilitarios y clases
base de Swing
Es la clase encargada
de cargar las cartas
del disco
Utilitarios en general
Objetos del Solitario, Cartas,
Pilas, “Dibujables”, etc
El código de este ejemplo va adjunto a las
transparencias, son los proyectos
CardGames01 y CardGames02
23
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 secuencia
de las siguientes láminas
para entender el proceso completo de tomar de una pila y poner en otra
24
Si el puntero no está
sobre una pila
srcStack es nulo
Si no se permite (por
reglas) mover las
cartas selecionadas,
tmpStack es nulo
Lo que sucede cuando el usuario
aprieta el ratón (sobre una pila)
25
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
Lo que sucede cuando el usuario libera el ratón (sobre una pila)
26
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?
27
Acepta cartas sólo del
mismo color
Acepta cartas de
colores intercalados
Acepta cartas sólo de
valores ascendentes
valores descendentes
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?
28
valores descendentes y del
mismo color
valores descendentes y del
mismo color (¿¿¿Opps, no
esta esto repetido???)
valores ascendentes y
decolores intercalados, etc,
etc, etc...
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
29
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?
30
Define la interfaz de
una “pequeña” clase
que establece un
comportamiento de
“prestamo” de cartas
La clase pila está
compuesta por una serie
de reglas de “prestamo”
y ”aceptación” de cartas
Define la interfaz de
una “pequeña” clase
que establece un
comportamiento de
“aceptación” de cartas
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
31
Cada una de las
clases de este color
definen una regla para
poder “prestar” una
carta o un grupo de
cartas de la pila
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
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
32
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
33
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
34
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
35
¿Cómo funciona? ¿Qué brinda un framework?
(¿Recuerda el ejemplo de la TV?)
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
36
¿Cómo funciona? ¿Qué brinda un framework?
(¿Recuerda el ejemplo de la TV?)
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)
37
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
38
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
39
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?
40
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) 41
Sin Framework
Con Framework
¡Tiempo Ganado al usar el Framework
vs
Curva de Aprendizaje!
42
Generalmente, si hay un buen
framework que cumple con
las expectativas no hay
excusa para no utilizarlo...
43
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
44
(development)
YAGNI: You Ain't Gonna Need It
45
(development)
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
46
¿Cómo se “aprende” a desarrollar 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
47
Componentes
Diseño Arquitectónico
Arquitectura
del Software
Diseño
Arquitectónico
Estilos
Arquitectónicos
Frameworks
(Marcos)
Patrones de
Diseño
Bibliotecas /
Componentes
Clases /
Funciones
TODO: Lectura :-(
(Sommerville 14)
(Diseño con
Reutilización)
¿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 componentes51
¿Componentes?
Sin embargo...
¿Recuerda usted las
siguientes
transparencias?
52
Desarrollo Basado en Reutilización
(Componentes)
“Almacén/Catálogo de
Componentes Reutilizables
Bosquejar los
Requerimientos
del
Sistema
Buscar
Componentes
Reutilizables
(COTS)
(Ej. Aplicaciones
Listas o Casi
Listas)
Modificar
Requerimientos
Acorde a los
Componentes
Encontrados
Diseño
Arquitectónico
Buscar
Componentes
Reutilizables
(COTS)
(Ej. Librerías,
Frameworks u
otros)
Diseñar el
Sistema
Utilizando los
Componentes
Reutilizados
+
Modificar
Componentes
Encontrados
+
Modificar
Componentes
Encontrados
COTS: Commercial Off the Shelf
Fuente; Sommerville / Ingeniería del Software (Excepto lo rojo)
Desarrollo Basado en Reutilización
(Componentes)
El costo del sistema se puede reducir notablemente debido a
la reutilización
El sistema se construye “uniendo” componentes existentes
***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
¿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
55
¿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
56
¿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.
57
¿Componentes?
características:
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?
58
¿Componentes?
características:
Describen o ejecutan (cumplen) una función:
Ejecutan una función específica o describen la
funcionalidad de un programa
(¿Describen? Ver Interfaces / API)
59
¿Componentes?
características:
Deben tener interfaces claras y deben ocultar los
detalles de su diseño interno:
...el título lo dice todo...
60
¿Componentes?
características:
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)
61
¿Componentes?
características:
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
62
La importancia de las interfaces
63
¿Cómo elegir un framework o un componente?
Bien...
Pero en este punto,
¿Cuál es la diferencia entre
un framework y un
componente?
64
¿Cómo saber si vale al pena
utilizar un framework o
componente específico?
(Algunos tips para evaluar
frameworks y componentes)
65
Primero:
Tenga bien claro el contexto y
el para qué necesita el
framework...
...y luego considere lo
siguiente...
66
¿Qué es un Patrón de Diseño?
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?
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*
*Si el último release fue hace más de un año – año y medio
probablemente no hay mucha actividad (aplican sus excepciones) 67
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”
68
¿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
69
¿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)*
¿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)?
¿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)
70
...y seguramente hay muchas
otras variables adicionales a
tomar en cuenta según el
caso, de modo que mantenga
los ojos bien abiertos...
71
Gracias
¡Gracias!
72

Frameworks y Componentes

Transcripción

Documentos relacionados

Cómo instalar Autocad 2015 en Windows 10

Ranking de Manos