54
Programación por Capas Parte I Daniel Correa Botero

Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Embed Size (px)

Citation preview

Page 1: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Programación por CapasParte I

Daniel Correa Botero

Page 2: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Arquitectura GLas capas en azul representan módulos prediseñados que no se deben programar.

Page 3: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Es la capa que permite la conexión entre el controlador y la vista.

Es la encarga de pasar variables a la capa vista (mediante la función assign).

Es la encarga de decidir que templates mostrar por pantalla (mediante la función display).

Todos los controladores, poseen una variable llamada $this->engine (que es toda la capa motor de templates), esta variable es realmente un objeto de la clase Smarty, y esta variable contiene todas las funciones de Smarty para php.

Capa Motor de Templates

Page 4: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Función Display (example3.php)

Page 5: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Función Display (example3.tpl)

- Creamos el controlador example3.php en la ruta: glight/example3.php

- Creamos el template example3.tpl en la ruta: glight/templates/example3.tpl

Page 6: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Función Assign (example4.php)

Page 7: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Función Assign (example4.tpl)

- Creamos el controlador example4.php en la ruta: glight/example4.php

- Creamos el template example4.tpl en la ruta: glight/templates/example4.tpl

Page 8: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

La capa vista se caracteriza por manejar toda la parte visual de la aplicación (imágenes, textos, vídeos, fondos, etc). Esta capa solo puede contener lenguaje html y sintaxis de smarty para html (un pseudolenguaje propio de este motor de plantillas). (Todos los archivos de esta capa se encuentran en la ruta glight/templates/)

Capa Vista

Page 9: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

1) Todos los archivos de esta capa se deben encontrar en la ruta glight/templates/*

2) El nombre de cada archivo o template se debe escribir en minúscula, y en caso de que contenga 2 o más palabras se debe usar el guion bajo y finalmente deben terminar con la extensión .tpl (ejemplo: contact.tpl - my_docs.tpl - index.tpl)

3) Los templates únicamente deben contener código html y smarty, no deben contener ni una sola línea de código php.

4) No se recomienda hacer cálculos dentro de los templates (como multiplicaciones, divisiones, manejo de strings, entre otros). Todas estas operaciones se deben hacer previamente en los controladores y luego asignar los resultados a los templates.

Reglas de la capa vista:

Page 10: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Primero debemos tener en cuenta que todo lo que vaya dentro de un template y contenga llaves {} es sintaxis smarty.

Todo lo que vaya dentro de llaves con un signo peso {$example} es una variable.

Todo lo que vaya dentro de {literal}{/literal} es código javascript o css que se puede insertar normalmente, si no se inserta dentro de estas etiquetas de "literal" no podrá ser cargado normalmente esto debido a que tanto javascript como css usan las llaves con otro fin diferente al de smarty.

Sintaxis de Smarty

Page 11: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Sintaxis de Smarty{$foo} -- displaying a simple variable (non array/object){$foo[4]} -- display the 5th element of a zero-indexed array{$foo.bar} -- display the "bar" key value of an array, similar to PHP $foo['bar']{$foo.$bar} -- display variable key value of an array, similar to PHP $foo[$bar]{$foo->bar} -- display the object property "bar"{$foo->bar()} -- display the return value of object method "bar"{$foo[bar]} -- syntax only valid in a section loop, see {section}{assign var=foo value="baa"}{$foo} -- displays "baa", see {assign}

Otras Combinaciones{$foo.bar.baz}{$foo.$bar.$baz}{$foo[4].baz}{$foo[4].$baz}{$foo.bar.baz[4]}{$foo->bar($baz,2,$bar)} -- passing parameters

{"foo"} -- static values are allowed

Page 12: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Sirve para incluir templates dentro de otros templates.

<html><head></head><body>{include file='promotion_one.tpl'}

Text HERE

{include file='promotion_two.tpl'}</body></html>

Función Include

Page 13: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

{if $name eq 'Fred'}    Welcome Sir.{elseif $name eq 'Wilma'}    Welcome Ma'am.{else}    Welcome, whatever you are.{/if}

Nota: se puede usar tanto ==, !=, o como eq, o neq.

Sintaxis If

Page 14: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

{for $foo=1 to 3}Number: {$foo},{/for}

Los fors no son casi usados, se recomienda usar el foreach o section

Sintaxis for

Page 15: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Sintaxis Foreach (example1.php)

Page 16: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Sintaxis Foreach (example1.tpl)

Page 17: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Sintaxis Section (example2.php)

Page 18: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Sintaxis Section (example2.tpl)

Page 19: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

{assign var="name" value="Bob"}The name is {$name}.

{$name='Bob'}The name is {$name}.

Sintaxis para asignar variables dentro de un mismo template

Page 20: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Esta capa contiene todo el control de la lógica del sistema, modifica la información para entregarla correctamente a las capas adyacentes, es como una especie de intermediario del sistema. Esta capa solo contiene código php.

El éxito de los controladores y cuantas funciones agregar o no en cada uno, es cosa de practica y de realizar ejemplos, generalmente cada controlador es asociado con una tarea u objetivo especifico, en muchos casos se asocia con un proceso del diagrama de procesos, o con un caso de uso.

Capa Controlador

Page 21: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Reglas de los controladores:1) Todos los controladores deben extender (o heredar) de la clase 'super_controller' (clase que se definirá mas adelante)

2) Todos los nombres de los archivos php de los controladores deben ir en minúscula y en caso de que contenga 2 o más palabras se debe usar el guion bajo y finalmente deben terminar con la extensión .php (ejemplo: contact.php - my_docs.php - index.php)

3) El nombre de la clase controladora debe ser igual a "c_" más el nombre de la ruta global y del archivo php que la contiene, por ejemplo en el controlador glight/index.php, la clase interna se debe llamar c_index

Page 22: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Reglas de los controladores:4) No se debe colocar ni una sola línea de código html en los controladores. Solo deben contener código php.

5) Todos los controladores deben contar con una función de 'run', una función de 'display' y fuera de la clase deben tener una variable $call que sea del mismo tipo del controlador y que ejecute la función $call->run()

Page 23: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

$engine: como vimos anteriormente, esta variable es un objeto de la clase Smarty y representa la capa motor de templates

$gvar: es un variable que contiene toda la información del archivo glight/configs/links.php contiene todas los enlaces y nombres de los archivos de la aplicación (mas adelante se detallará mejor)

$img_warning: contiene una imagen de alerta, por defecto es una x que significa error, pero también puede ser un chulo que significa que todo salió bien.

$msg_warning: contiene un mensaje de alerta, por defecto es vacio.

$error: por defecto es un 0 que significa que no se han encontrado errores, en caso de que se encuentra un error se le debe asignar a 1 (mas adelante se detallaran ejemplos) - Junto con las otras 2 variables anteriores, estas 3 se usan para mostrar mensajes de alerta en el template message.tpl

Super Controlador (Variables)

Page 24: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

$get: contiene todo los datos en forma objetual que se envíen por el método $_GET desde los templates.

$post: contiene todo los datos en forma objetual que se envíen por el método $_POST desde los templates.

$files: contiene todo los datos $_FILES en forma objetual que se envíen desde los templates

$session: contiene todas las variables de $_SESSION pero en forma de array (no se transforma a forma objetual debido a que no es recomendable guardar objetos en SESSION).

$temp_aux es un template auxiliar que se usa para mostrar datos dependiendo de condicionales, por defecto hace referencia al template empty.tpl que es un template vació. (Mas adelante

se explicara su uso con ejemplos).

Super Controlador (Variables)

Page 25: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Seccionesde un

Controlador

Esta capa se basa en 4 secciones principales:

- Zona de inclusiones (Fondo amarillo)- Zona de funciones propias (Fondo rojo)- Zona de display (Fondo verde)- Zona de run (Fondo Azul)

Page 26: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Zona de InclusiónEn esta zona se deben incluir los archivos que se necesiten para el funcionamiento del controlador; siempre se debe incluir el glight/configs/include.php (debido a que ese archivo carga toda la información importante del framework), y en caso de utilizar módulos entonces también se deberán incluir los archivos respectivos a cada módulo.

Por ejemplo si un controlador desea mostrar un calendario, y ese calendario es un módulo que se encuentra en la carpeta glight/modules/m_calendar/calendar.php, entonces se deberá hacer su respectiva inclusión en esta zona.

Nota: no se necesitan incluir los módulos o capas de db.php, orm.php, object_standard.php, ni super_controller.php ya que estos están incluidos directamente desde el archivo glight/configs/include.php

Page 27: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

En esta zona el programador define las funciones que considere necesarias, en el caso de que el programador solo desee mostrar un template por pantalla y no desee hacer nada mas, entonces no necesitara crear funciones propias para ese controlador, solo le bastara con la función de display.

En el caso por ejemplo de agregar, editar y/o borrar datos de la base de datos, o realizar operaciones con cálculos o llamar otros módulos para exportar la información a pdf o excel, entre otros) en ese caso se recomienda definir funciones propias para el controlador, para tener el mismo bien organizado.

Nota: Si un proceso requiere de una operación a una base de datos (diferente a select) o una verificación de datos debe

ir en una función propia y no en el display.

Zona de Funciones propias

Page 28: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Zona de display

Esta zona es la encargada de manejar la comunicación con la capa vista, desde allí se realizan todos los display de templates que se necesiten mostrar, es importante resaltar que se recomienda que sea desde la única parte del controlador que se llame la función display del motor de templates ($this->engine->display) esto con la intensión de hacer un fácil seguimiento de que templates se van mostrando y en que orden.

Nota: Todos los controladores deben contar con esta zona, no siempre se debe hacer un display de un template, también se pueden generar salidas de archivos para descargas, o mostrar datos en forma de pdf, entre otros.

Page 29: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Zona de Run

Esta zona de run (o zona de ejecución) se caracteriza por llamar a las funciones del controlador anteriormente creadas y por último llamar la función display (esto debido a que una vez desarrollados todos los procesos o cálculos, lo que normalmente se espera es un aviso por pantalla que puede ser un llamado a la capa vista).

También se definen templates auxiliares e igualmente en muchos casos se define el TRY y CATCH, funciones exclusivas de php para el tratamiento de las excepciones (mas adelante miraremos un ejemplo del uso de Try y catch).

Page 30: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

NotaComo podemos ver los controladores son clases, igual que el motor de templates, igual que el gestor de base de datos, igual que el mapeo objeto-relacional, e igual que los módulos, todos son clases, pero los controladores son los únicos de todos los anteriores que crean un objeto de si mismos y se llaman a si mismos (usando la variable $call al final de cada controlador) y que poseen una zona de ejecución.

Page 31: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Ejemplo Controlador (example4.php)

Page 32: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Ejemplo Controlador (example4.tpl)

Page 33: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

G varsLas G vars o variables globales, son variables que usa tanto el controlador como la capa vista, para acceder a una serie de rutas, mensajes y nombres globales para toda la aplicación.

Las G var se encuentran en el archivo glight/configs/gvar.php y para acceder a ellas existen 2 métodos:

1) Desde un controlador: $this->gvar['nombre_de_la_var_especifica'] - por ejemplo si queremos acceder a la ruta global de la aplicación usamos $this->gvar['l_global'];

2) Desde un template: {$gvar.nombre_de_la_var_especifica} ó {$gvar['nombre_de_la_var_especifica']} - por ejemplo si queremos acceder a la ruta global de la aplicación usamos {$gvar.l_global}

Page 34: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Tipos de G vars- messages: son mensajes que saca la aplicación cuando se hace una operación lógica o una consulta a la base de datos o mensajes de alerta se caracterizan por empezar con la letra m seguida de un guión bajo - por ejemplo $this->gvar['m_correct_login']; podría ser usado en glight/index.php cuando un usuario se loguea satisfactoriamente.

- links: son rutas de la aplicación, se caracterizan por empezar con la letra l seguida de un guión bajo - por ejemplo la ruta global de la aplicación 'http://localhost/work/index.php' se encuentra en la gvar $this->gvar['l_global'];

- names: son los nombres de las rutas, se caracterizan por empezar con la letra n seguida de un guión bajo - por ejemplo el nombre de la sección de contacto es 'Contact' y se encuentra en la gvar $this->gvar['n_contact'];

NOTA: volver al ejemplo anterior y usar G vars.

Page 35: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Las gvar nos permiten tener todos estos textos en un solo punto, lo que nos permite que si queremos cambiar los textos a otro idioma solo debamos modificar este archivo y no debamos buscar y modificar cada archivo de la aplicación; además si cambiamos el nombre de un archivo por ejemplo contact.php a contacto.php solo debemos editar la gvar correspondiente a ese link y toda la aplicación seguirá funcionando normalmente.

Ventajas de las G Vars

Page 36: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Resumen CapasEl triangulo rojo superior es lo visto hasta el momento, ahora continuaremos con la capa de clases.

Page 37: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Agregar lo siguiente al archivo glight/configs/functions.php

//check if a var is emptyfunction is_empty($data){

if(!isset($data) || ($data == NULL)){return TRUE;}else{return FALSE;}

}

Correción a Glight

Page 38: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Esta capa contiene el equivalente a la base de datos pero en forma objetual, guarda y recoge la información de los objetos, sus atributos, sus funciones, sus métodos, entre otros.

Muchos desarrollos se basan en el diagrama de clases, y la programación orientada a objetos (POO) permite codificar fácilmente toda la información de ese diagrama.

Capa Clases

Page 39: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Reglas de la Capa de Clases1) Todas las clases se deben encontrar en la carpeta glight/classes/*

2) El nombre de las clases debe ser en minúscula, singular y en caso de que contenga 2 o más palabras se debe usar el guion bajo y finalmente deben terminar con la extensión .php (ejemplo: user.php - person.php - doc.php).

3) Si una clase hace referencia a una tabla, entonces ambas deben llamarse igual. Por ejemplo si se creo la tabla user, entonces la clase que referencia esta tabla también se debe llamar user.

4) Todos las clases deben extender (o heredar) de la clase 'object_standart' (clase que se definirá mas adelante).

5) Todos las variables o attributos principales de cada clase deben ser protegidos, y solo se podrá acceder a ellos mediante las funciones get y set definidas en el objeto estándar.

Page 40: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Recoge las funciones en común (get – set – assign components - construct).

Se encuentra en la ruta glight/modules/object_standart.php

Esta archivo no debe ser modificado.

Objeto Estandar

Page 41: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Caso de Estudio

Page 42: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

<?phpclass boss extends object_standard{    //attribute variables    protected $document;    protected $name;    protected $charge;        //components    var $components = array();        //auxiliars for primary key and for files    var $auxiliars = array();        //attribute information    public function attributes()    {        return array("document“ => array(), "name“ => array(), "charge“ => array() );     }

  

public function primary_key()    {        return array("document");    }        public function relational_keys($option)    {        switch($option)        {                    default:            break;        }    }}

?>

classes/boss.php

Page 43: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

classes/person.php<?php

class person extends object_standard{ //attribute variables protected $document; protected $name; protected $lastname; protected $age; protected $boss; //components var $components = array(); //auxiliars for primary key and for files var $auxiliars = array(); //attribute information public function attributes() { return array("document“ => array(), "name“=> array(), "lastname“ => array(), "age“ => array(), "boss" => array("foreign_name" => "b_p“, "foreign" => "boss", "foreign_attribute" => "document")); }

public function primary_key() { return array("document"); } public function relational_keys($option) { switch($option) { case "b_p": return array("boss"); break; default: break; } }}

?>

Page 44: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Constructor de las Clases

El constructor es llamado automáticamente una vez se hace una creación de un objeto de una clase: $person = new person();

El constructor recibe 4 parámetros TODOS OPCIONALES:

- $data: es un objeto (no puede ser un array debe ser un objeto) que contiene la información de los atributos que se deseen establecer por primera vez.- $components: es una lista opcional de las relacionales de la clase (será profundizado mas adelante).- $orm: es un objeto de clase ORM con información importante que se utiliza cuando se quiere asignar un componente (será profundizado mas adelante).- $auxiliars: esta variable se usa cuando se quiere establecer atributos adicionales a los propios de la clase (mas adelante se profundiza)

Page 45: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

EjemploConstructor(example5.php)

Nota: las clases no necesitan ser incluidas en la zona de inclusión, en functions.php existe una función autoload que carga estos archivos automáticamente.

Page 46: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

GET: Permite obtener el valor de alguno de los atributos del objeto (se recomienda usar solo con atributos y no con componentes o con auxiliares)

- recibe un solo parámetro que es el atributo que queremos obtener.

SET: Permite modificar el valor de alguno de los atributos del objeto

- recibe 2 parámetros el atributo que se desea modificar, y el valor que se le desea asignar.

Get y Set

Page 47: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Ejemplo Get y Set (example6.php)

Page 48: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Attribute variables: son los atributos de cada clase (en caso de tener base de datos: cada atributo debe representar una columna de la base de datos)

Primary key: Esta función retorna el nombre de el o los atributos los cuales representan la clave primaria de cada clase (los cuales identifican un solo objeto en el mundo).

Secciones de una clase

Page 49: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Attribute Info: Nos permite obtener información acerca de los atributos de cada clase, su nombre y si representa una clave foranea o no.

- "foreign name": (solo usado cuando el atributo representa una clave foránea) representa el nombre de la relación a la cual hace referencia, en el ejemplo anterior el nombre de la relación seria "b_p" (mas adelante se detallara información sobre los nombres de las relaciones).

- "foreign": (solo usado cuando el atributo representa una clave foránea) representa el nombre de la clase con la cual se relaciona "b_p" en este caso “boss”

- "foreign attribute": (solo usado cuando el atributo representa una clave foránea) representa el nombre del atributo de la clase "boss" (en este caso) con el cual se relaciona y con el cual se debe comparar para verificar que si pertenezca a la relación.

Secciones de una clase

Page 50: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Relational Keys: Las claves relacionales, representan relaciones entre las diferentes clases, se usan para saber en base a que atributos se dan estas relaciones.

Secciones de una Clase

Page 51: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Nombres de relaciones (little Faces - Caritas)Cuando 2 clases se relacionan o una clase se relaciona con si misma, se debe colocar un nombre a esta relación, G recomienda un método para colocar estos nombres llamado ('caritas' o en ingles 'little faces'), el proceso es simple:1) se cogen las letras iniciales de cada clase (en el ejemplo anterior serian las letras b de boss y p de person)2) se ordenan alfabéticamente (en el ejemplo anterior ya están ordenadas alfabéticamente b, p)3) se separan por un guion bajo, dando como resultado: b_p

El método anterior es muy útil ya que cuando necesitemos usar una relación, recordaremos fácilmente el nombre de la relación sin necesidad de buscar en los archivos el nombre de la relación.

Nota: en el caso de que exista mas de 1 relación entre las mismas 2 clases, se recomienda crear el primer nombre de relación normal, el segundo igual que el primero solo que adicionándole una palabra que nos haga recordar la relación. Por ejemplo: b_p, b_p_principal_boss, b_p_secundary_boss...

Page 52: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Class functions and methods: Esta zona esta destinada para métodos y funciones propias de cada clase, cada desarrollador podrá programar en esta zona las funciones que considere necesarias para su software o que se encuentren en el diagrama de clases.

Secciones de una Clase

Agregar la función calculate_future_age a la clase person

Page 53: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Ejemplo función de una clase(example8.php)

Se puede adicionar antes de $data->document = “1001”;

La linea:settype($data,’object’);

Para evitar unas alertas que a veces aparecen.

Page 54: Daniel Correa Botero. Las capas en azul representan módulos prediseñados que no se deben programar

Actividad 1A) Crear 5 personas en memoria (usando nombres de familiares y/o amigos).B) Crear una función de la clase persona que permita encontrar la persona con menor edad.C) Crear una función de la clase persona que permita encontrar el promedio de las edades de las personas.D) Mostrar la información de las 5 personas, el promedio de edades y la edad de la persona con menor edad en un template.

Envió de la actividad:1) comprimido en .rar el controlador, la clase y el template.2) poner la cédula al archivo .rar (ej: 1036632970.rar).3) enviar un correo a [email protected] con asunto: DCPS Actividad 1 – [aquí va numero de cédula] (ej: DCPS Actividad 1 – 1036632970).4) Adjuntar el .rar y colocar en el cuerpo del mensaje el nombre completo y enviarlo.

Notas: para esta actividad no se resuelven dudas, en caso de que no les funcione el paquete G Light deben preguntarle a un compañero para que les ayude y/o seguir las indicaciones de las diapositivas. Tienen plazo de enviarlo hasta el martes a las 12 pm.