Frameworks y Componentes (... reutilizar, reutilizar, reutilizar!!! - - PowerPoint PPT Presentation

1

Frameworks y Componentes

(... ¡¡¡reutilizar, reutilizar, reutilizar!!! ...)

Universidad de los Andes

Demián Gutierrez Abril 2010

Frameworks

Diseño Arquitectónico

Diseño Arquitectónico Arquitectura del Software Bibliotecas / Componentes Patrones de Diseño Clases / Funciones Frameworks (Marcos) Estilos

Arquitectó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

• peraciones 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) Estilos Arquitectó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 Menor nivel de abstracción definen implementan Implementan Se diseñan usando (entre otras cosas) Utilizan Definen la Arquitectura

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) funcionalidad añadida (Cliente) comportamiento por defecto Inversión de Control (IoC)

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

• bjetos (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 de usar Más difícil de programar (En general) ¡El ideal, el sueño de todo desarrollador es hacer un framework completamente caja negra!

16

EJEMPLO: ¡Implementemos un Solitario!

Frameworks: Caja Blanca, Caja Negra y Ejemplos...

17

Un solitario es un juego en el que hay:

¿Frameworks y Arquitectura de Software?

Cartas: Unidades básicas que se mueven de un lado a

• tro, 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 O K

20

¿Frameworks y Arquitectura de Software?

Una pila que sólo acepta cartas con valor descendiente y color alterno N O N O 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 N O 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 solitario Es 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 las transparencias, son los proyectos CardGames01 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 secuencia de las siguientes láminas para 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

• rigen

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

• 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 Framework vs 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

45

To framework or not to framework? (development) 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

To framework or not to framework? (development)

47

¿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

Componentes

Diseño Arquitectónico

Diseño Arquitectónico Arquitectura del Software

Bibliotecas / Componentes

Patrones de Diseño Clases / Funciones Frameworks (Marcos) Estilos

Arquitectónicos

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?

Desarrollo Basado en Reutilización (Componentes)

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

Bosquejar los Requerimientos del Sistema

Buscar Componentes Reutilizables (COTS) (Ej. Aplicaciones Listas o Casi Listas)

Diseño Arquitectónico

Buscar Componentes Reutilizables (COTS) (Ej. Librerías, Frameworks u

• tros)

Modificar Requerimientos Acorde a los Componentes Encontrados

Modificar Componentes Encontrados

+

Diseñar el Sistema Utilizando los Componentes Reutilizados

Modificar Componentes Encontrados

+

COTS: Commercial Off the Shelf

“Almacén/Catálogo de Componentes Reutilizables

Desarrollo Basado en Reutilizació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

• tros 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

• 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

• tros componentes del sistema en que se reutiliza

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

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)

¿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

• tras 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?

72

Gracias

¡Gracias!