Frameworks y Componentes
Transcripción
Frameworks y Componentes
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 ¿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 5 ¿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. 6 ¿Qué es un Framework? 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 ¿Frameworks y Arquitectura de Software? 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 ¿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. 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 ¿Frameworks y Arquitectura de Software? 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 ¿Frameworks y Arquitectura de Software? 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 ¿Frameworks y Arquitectura de Software? 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 ¿Frameworks y Arquitectura de Software? Una pila que sólo acepta cartas con valor descendiente y color alterno NO SI O N 20 ¿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 21 ¿Frameworks y Arquitectura de Software? 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 ¿Frameworks y Arquitectura de Software? 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 ¿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 24 ¿Frameworks y Arquitectura de Software? 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 ¿Frameworks y Arquitectura de Software? 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 ¿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? 27 ¿Frameworks y Arquitectura de Software? Acepta cartas sólo del mismo color Acepta cartas de colores intercalados Acepta cartas sólo de valores ascendentes Acepta cartas sólo de 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 ¿Frameworks y Arquitectura de Software? 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... 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 ¿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? 30 ¿Frameworks y Arquitectura de Software? 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 ¿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 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 ¿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 33 ¿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 34 ¿Frameworks y Arquitectura de Software? 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 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 39 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? 40 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) 41 To framework or not to framework? (use) Sin Framework Con Framework ¡Tiempo Ganado al usar el Framework vs Curva de Aprendizaje! 42 To framework or not to framework? (use) 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 To framework or not to framework? (development) YAGNI: You Ain't Gonna Need It 45 To framework or not to framework? (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? 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? 58 ¿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) 59 ¿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... 60 ¿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) 61 ¿Componentes? En general, un componente debe tener las siguientes 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 elegir un framework o un componente? ¿Cómo saber si vale al pena utilizar un framework o componente específico? (Algunos tips para evaluar frameworks y componentes) 65 ¿Cómo elegir un framework o un componente? 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 ¿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” 68 ¿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 69 ¿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)* ¿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 ¿Cómo elegir un framework o un componente? ...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