Frameworks y Componentes - · PDF file¿Frameworks y Arquitectura de Software? Es decir,...
Transcript of 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
Diseño Arquitectónico
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
¿Qué es un Framework?
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
¿Qué es un Framework?
¿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
¿Qué es un Framework?
¡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?
¿Frameworks y Arquitectura de Software?
Bibliotecas /Componentes
Patrones de Diseño
Clases / Funciones
Frameworks(Marcos)
EstilosArquitectónicos
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
¿Qué es un Framework?
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!
17
Un solitario es un juegoen el que hay:
¿Frameworks y Arquitectura de Software?
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...
¿Frameworks y Arquitectura de Software?
19
Prácticamente, se pueden definir un conjunto infinito de posibles reglas y
juegos distintos usando el mismo principio
¿Frameworks y Arquitectura de Software?
Sólo acepta una “A” de cualquier color
NO
OK
20
¿Frameworks y Arquitectura de Software?
Una pila que sólo acepta cartas con valor
descendiente y color alterno
NO
NO
SI
21
¿Frameworks y Arquitectura de Software?
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:
¿Frameworks y Arquitectura de Software?
23
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
¿Frameworks y Arquitectura de Software?
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
To framework or not to framework? (use)
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
To framework or not to framework? (use)
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
To framework or not to framework? (use)
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
To framework or not to framework? (use)
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...
To framework or not to framework? (use)
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
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
To framework or not to framework? (development)
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
Diseño Arquitectónico
Diseño Arquitectónico
Arquitectura del Software
Bibliotecas /Componentes
Patrones de Diseño
Clases / Funciones
Frameworks(Marcos)
EstilosArquitectónicos
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
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?
En general, un componente debe tener las siguientes 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?
59
¿Componentes?
En general, un componente debe tener las siguientes 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)
60
¿Componentes?
En general, un componente debe tener las siguientes características:
Deben tener interfaces claras y deben ocultar los detalles de su diseño interno:
...el título lo dice todo...
61
¿Componentes?
En general, un componente debe tener las siguientes 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)
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
En general, un componente debe tener las siguientes características:
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)
¿Cómo elegir un framework o un componente?
66
Primero:
Tenga bien claro el contexto y el para qué necesita el
framework...
...y luego considere lo siguiente...
¿Cómo elegir un framework o un componente?
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
¿Qué es un Patrón de Diseño?
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
¿Qué es un Patrón de Diseño?
¿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
¿Qué es un Patrón de Diseño?
¿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...
¿Cómo elegir un framework o un componente?