DESARROLLO DE UNA APLICACIÓN DE CONTROL Y MONITOREO DE NIÑOS VÍA WEB, PARA EL CENTRO DE CUIDADOS MATERNO INFANTIL POPEYE S DE LA CIUDAD DE QUITO

Transcripción

1

2 DESARROLLO DE UNA APLICACIÓN DE CONTROL Y MONITOREO DE NIÑOS VÍA WEB, PARA EL CENTRO DE CUIDADOS MATERNO INFANTIL POPEYE S DE LA CIUDAD DE QUITO Proyecto de fin de carrera previa a la obtención del título de Ingeniería en Sistemas Informáticos y Computación. AUTOR: Max Geovanny Morillo Aguilar DIRECTOR: Ing. Guido Riofrío Calderón LOJA - ECUADOR 2011

3 CERTIFICACIÓN Ing. Guido Riofrío Calderón C E R T I F I C A : Que el presente trabajo de investigación, previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, ha sido dirigido, supervisado y revisado en todas sus partes, por lo mismo, cumple con los requisitos legales exigidos por la Universidad Técnica Particular de Loja, quedando autorizada su presentación. Loja, 01 de julio de 2011 Ing. Guido Riofrío Calderón

4 CERTIFICACIÓN Ing. Alexander López C E R T I F I C A : Que el presente trabajo de investigación, previo a la obtención del título de INGENIERO EN SISTEMAS INFORMÁTICOS Y COMPUTACIÓN, ha sido dirigido, supervisado y revisado en todas sus partes, por lo mismo, cumple con los requisitos legales exigidos por la Universidad Técnica Particular de Loja, quedando autorizada su presentación. Loja, 01 de julio de 2011 Ing. Alexander López

5 AUTORÍA El presente proyecto de tesis con cada una de sus observaciones, análisis, evaluaciones, conclusiones y recomendaciones emitidas, es de absoluta responsabilidad del autor. Además, es necesario indicar que la información de otros autores empleada en el presente trabajo, está debidamente especificada en fuentes de referencia y apartados bibliográficos.... Max Geovanny Morillo Aguilar

6 CESIÓN DE DERECHOS Yo, MAX GEOVANNY MORILLO AGUILAR, declaro ser autor del presente trabajo y eximo expresamente a la Universidad Técnica Particular de Loja y a sus representantes legales de posibles reclamos o acciones legales. Adicionalmente declaro conocer y aceptar la disposición del Art. 67 del Estatuto Orgánico de la Universidad Técnica Particular de Loja, que en su parte pertinente textualmente dice: Forman parte del patrimonio de la Universidad la propiedad intelectual de investigaciones, trabajos científicos o técnicos y tesis de grado que se realicen a través, o con el apoyo financiero, académico o institucional (operativo) de la Universidad.... AUTOR

7 AGRADECIMIENTOS Expreso mi sincero agradecimiento, a la Universidad Técnica Particular de Loja, principalmente a la Escuela de Informática, a sus directivos, personal administrativo y docentes, quienes supieron con paciencia entregarnos sus mejores conocimientos y experiencias para nuestro crecimiento académico y vivencial. Un especial agradecimiento al Ing. Guido Riofrío, que sin su guía y ayuda, hubiera sido difícil la terminación del presente tema de tesis. El Autor

8 DEDICATORIA Este trabajo está dedicado en primer lugar a Dios, quien ha dado luz a mi camino. A mi esposa Alexandra y mi hija Wendy, quienes con su amor, apoyo incondicional y paciencia, me dieron un enorme impulso e inspiración. A mis padres Kleber y Angelita, una especial dedicatoria, ya que son ellos quienes han luchado y esforzado para darme el estudio y con ello ver al fin la terminación de una etapa de mi vida, de la cual se puedan sentir orgullosos del deber cumplido. A mis queridos hermanos Kleberito y Rubita, ejemplo para mí a seguir. A Gerson, Paúl y todos mis amigos y excompañeros, que con sus consejos y aliento desinteresados, me ayudaron e incentivaron. Max Geovanny Morillo Aguilar

9 Tabla de Contenidos Contenido Pág. Introducción 11 FASE 1. Investigación Preliminar e Identificación de características que deberá tener el aplicativo en 13 el centro infantil Datos generales del Centro Infantil Popeye s Hallazgos del estudio preliminar Requerimientos de ubicación de Cámara IP Características que tendrá el aplicativo para el Centro Infantil Ubicación física del centro infantil en la ciudad de Quito-Ecuador Investigación de funcionamiento de tecnología IP vía Web (manejo de cámaras IP) Componentes de las cámaras IP Requerimientos de conexión para una cámara IP en internet o LAN Seguridad de Acceso a las cámaras IP Características de audio y video emitido por las cámaras IP Selección de Cámara IP para el desarrollo de tesis Descripción General de la cámara IP DLINK DCS Características físicas indicadas por el fabricante Investigación y selección de metodología de desarrollo y herramientas tecnológicas para crear el 26 aplicativo web Scrum, como metodología de implementación Proceso de aplicación de metodología SCRUM Liferay, como portal Esquema de funcionamiento de la solución con Liferay Portlets (Aplicativos) Eclipse, como Framework para desarrollo de Portlets 36 FASE 2. Modelamiento y desarrollo del aplicativo Perfil del Centro Infantil Planificación del proyecto utilizando la metodología SCRUM Análisis y Desarrollo del requerimiento: Elaborar un portal para el Centro Infantil Análisis del Portal Diseño del modelo conceptual del Portal Diseño de pantallas del portal Diseño de Pantalla Inicio Diseño de Pantalla Quienes Somos Diseño de Pantalla Noticias Diseño de Pantalla Sugerencias para Padres Diseño de Pantalla Contáctenos Diseño de Pantalla Monitoreo Web Cam Diseño de Pantalla Administración Salones Desarrollo del portal utilizando Liferay Portal Documentación de implantación de Liferay Instalación de Java en CentOs Instalación de Mysql en CentOs Instalación de Liferay con JBoss en CentOs Crear la página Web principal y opciones públicas con Liferay Consideraciones previas a la creación de un sitio web con Liferay Administración de Liferay Agregación de páginas web Agregación de Portlets (aplicativos) a las páginas Web Disposición de Página Web 56

10 Edición de un portlet de contenido Selección de Tema (Template) Inserción de un Logo en el sitio Web Creación de usuarios en liferay Creación de grupos de usuarios en liferay Creación de roles para asignación a grupos de usuarios en Liferay Instalación de Cámara IP con conexión a Router inalámbrico Dlink DIR Análisis y Desarrollo del requerimiento: Crear un aplicativo de monitoreo de niños, para el 70 portal del Centro Infantil Análisis del portlet de Monitoreo de niños Modelo conceptual del portlet de Monitoreo de niños Diseño de la tabla de datos Modelo de Casos de Uso Detalle de casos de Uso identificados Desglose de los Casos de Uso encontrados Diagramas de Clases Configuración de Eclipse para la iteracción con Liferay Carga y configuración de Plug-in de Liferay para eclipse Creación del proyecto CamaraIPPortlet tipo Portlet en eclipse Investigación para la generación de portlets utilizando la infraestructura de 83 Liferay Desarrollo del aplicativo utilizando la infraestructura Liferay Generación de portlet mediante Service Builder de Liferay Definición de entorno de variables previo al desarrollo del portlet en Liferay Programación de métodos para almacenamiento y recuperación de datos Programación de archivos Vista (View.jsp) para presentación de imágenes de 92 cámara y de administración de salones Programación de permisos para los portlets creados Despliegue del proyecto en ambiente de desarrollo para pruebas de conexión Despliegue del proyecto en ambiente de producción Pruebas de funcionamiento de los portlets desplegados en producción 102 FASE 3. Resultados del impacto de la solución en los padres de familia Utilización de credenciales de acceso a Padres de Familia y análisis de resultados 104 Conclusiones 108 Recomendaciones 109 Bibliografía 110 Anexos 111 Anexo 1. Encuestas preliminares de aceptación del proyecto a padres de familia 112 Anexo 2. Descripción de la metodología de desarrollo SCRUM 128 A2.1. Conceptos manejados en SCRUM 128 A2.2. Estructuración de la metodología 129 A2.3. Aplicación de la metodología para la implementación de la solución 132 Anexo 3. Revisión general de liferay como portal 146 Anexo 4. ECLIPSE, como framework para desarrollo de portlets 151 Anexo 5. Hosting 155 Anexo 6. Recursos a utilizar en el desarrollo de la solución 156 Anexo 7. Encuestas de satisfacción de uso de monitoreo web 158 Anexo 8. Código Fuente del Aplicativo 168 Anexo 9. Paper 183

11 11 INTRODUCCIÓN Con el auge de las TICs (llamadas así a las Tecnologías de la Información y Comunicación), en la actualidad se han desarrollado aplicativos informáticos que generan una mejor calidad de vida a las personas. El desarrollo e inversión en las telecomunicaciones en nuestro país, ha provocado la mejora sustancial en el rendimiento de las mismas, lo que ha generado un uso más generalizado del Internet en nuestro medio. Al momento tanto las telecomunicaciones y el Internet, especialmente en las ciudades como Quito, Guayaquil y Cuenca, han sido beneficiadas con la mejora de velocidades y cobertura, lo que ha permitido la rápida expansión de nuevos servicios relacionados con las telecomunicaciones y tecnología. Aprovechando esta coyuntura en la ciudad de Quito, y ante una necesidad específica, nacida por experiencia propia (que no es ajena a la mayoría de parejas o matrimonios), propongo el tema: Desarrollo de una aplicación de control y monitoreo de niños vía Web, para el centro de cuidados materno infantil Popeye s de la ciudad de Quito.

12 12 RESUMEN Con este tema se pretende crear un aplicativo Web, utilizando herramientas OpenSource, que permita monitorear, de alguna manera, el día a día de los niños en un centro de cuidados materno infantil, y que a su vez, se pueda medir cualitativamente el bienestar que puede aportar el uso de una herramienta de ese tipo tanto en padres de familia como en los niños. Esto implicará el desarrollo de un aplicativo (aplicación Web) con herramientas Open Source (con el objetivo de abaratar costos de licencias), así como la investigación y manejo de cámaras IP y toda su tecnología detrás de las mismas, para poder acoplarlas con el aplicativo. En la primera Fase del presente tema, se describe los hallazgos de la investigación preliminar de las necesidades del Centro de desarrollo Infantil, así como de un breve estudio de aceptación de la propuesta de monitoreo por parte de los padres. También se hace una identificación de las características que tendrá el aplicativo de acuerdo a los requerimientos del Centro Infantil. Posteriormente se muestra una revisión general de las diferentes tecnologías a aplicar para el desarrollo del presente tema. En la segunda Fase, se describe tanto el marco conceptual del cómo funcionará la solución, utilizando las tecnologías revisadas en la primera Fase, así como el detalle del proceso de desarrollo en sí, profundizando en cada una de las tecnologías a utilizar (modo de instalación, uso, etc.), y describiendo los resultados que se van obteniendo durante el proceso de desarrollo. También se puede ir observando los resultados de la utilización de la metodología de desarrollo. En la tercera Fase, se exponen los resultados de los estudios de impacto de la solución en los padres de familia que utilizarán el aplicativo. Finalmente se exponen en el apartado de Anexos, todos los documentos (encuestas, cuadros, resultados obtenidos, etc.), que sirvieron para la implementación de la solución.

13 13 FASE 1 INVESTIGACIÓN PRELIMINAR E IDENTIFICACIÓN DE CARACTERÍSTICAS QUE DEBERÁ TENER EL APLICATIVO EN EL CENTRO INFANTIL Datos generales del Centro Infantil Popeye s: El centro de desarrollo infantil Popeye s (CI), tiene como objetivo: Contribuir técnica y profesionalmente para que los niños y niñas alcancen un desarrollo bio-psico-socio cultural espiritual adecuado, dentro de un marco afectivo y de valores respetando su ecosistema y su ideología. Tiene a cargo el cuidado, control y enseñanza de destrezas en niños desde 1 hasta 5 años de edad. Su estructura de estudios para los niños está conformada de la siguiente manera: Inicial 1: Para niños de 1-2 años. Inicial 2: Para niños de 2-3 años. Inicial 3: Para niños de 3-4 años. Pre-Básica : Para niños de 4-5 años. En su infraestructura física, el centro infantil dispone de los siguientes espacios físicos: Área total: 285 m 2 Área de construcción: 142,25 m 2 Área exterior total: 142,25 m 2 Las dependencias de las que consta el centro infantil son (Ver Figura 1.1. Plano de dependencias del CI): Juegos y módulos exteriores Espacios verdes Lavabos

14 14 Dependencias Generales del Centro Dirección Psicopedagógica Dormitorio. Figura 1.1. Plano de dependencias del CI (Tomado del CDI) Hallazgos del estudio preliminar Luego de haber realizado las respectivas investigaciones con la directora del Centro Infantil (Lic. Tatiana González), se pudo constatar que la falta de control o monitoreo de los niños, especialmente de edades comprendidas entre 1 3 años (aunque no menos en niños de edades superiores a estas), crea niveles anormales de ansiedad en los padres. Esta ansiedad o estress, se incrementa más aún cuando los niños están con algún tipo de enfermedad que deba ser controlada con medicamentos (generalmente procesos gripales o respiratorios). También se puede notar que el impacto es mayor en mujeres (madres de esos niños), que en varones (padres).

15 15 Por experiencia propia, he podido determinar que ante este escenario se produce un incremento importante en las llamadas hacia el Centro Infantil para el seguimiento correspondiente, así como disminución en el rendimiento laboral, especialmente en áreas que requieren especial atención en temas de concentración (ej. Desarrollo de sistemas informáticos bancarios, financieros, etc.). De acuerdo a un estudio hecho por Forbes Woman ( de una encuesta realizada en una muestra de 2200 mujeres en los Estados Unidos, Forbes concluye que: 62% de las mujeres encuestadas manifestó que tener hijos puede tener un impacto negativo en sus carreras. En contraste, sólo el 30% de las madres que trabajan dijo que haber tenido niños, había afectado su vida laboral. Tomando en cuenta esas estadísticas, decidí hacer una encuesta de aceptación al proyecto (Ver Anexo A1. Encuestas preliminares de aceptación del proyecto a Padres de familia), para determinar las preferencias de monitoreo entre los padres de familia que inscriben a sus niños en el Centro Infantil, por lo que a continuación se muestran los resultados tabulados (los valores están expresados en porcentajes): 1.) Ud. Confía en los cuidados del centro infantil donde está su hijo(a): % Si 14 87,50 No 0 - No contesta 2 12,50 TOTAL ,00 Tabla 1.1. Confianza en cuidados del CI. 2.) Cuando Ud. deja a su niño(a) pequeño(a) al cuidado de un centro infantil, considera que su rendimiento laboral se ha visto: Disminuido 0 - Aumentado 11 68,75 %

16 16 Sigue igual 3 18,75 No se da cuenta 1 6,25 No contesta 1 6,25 TOTAL ,00 Tabla 1.2. Rendimiento Laboral 3.) Considera que un sistema de monitoreo (con cámaras), donde Ud. pueda observar a su niño vía Internet, ayudaría: Mucho 12 75,00 Poco 4 25,00 Nada 0 - TOTAL ,00 Tabla 1.3. Monitoreo vía Web % 4.) El monitoreo vía internet, mejoraría su desempeño laboral: Mucho 4 25,00 Poco 8 50,00 Nada 4 25,00 TOTAL ,00 Tabla 1.4. Monitoreo vs. Desempeño laboral % 5.) Ud. labora bajo relación de dependencia en una empresa o institución?: Si 10 62,50 No 6 37,50 TOTAL ,00 Tabla 1.5. Relación de dependencia laboral % 6.) El lugar donde trabaja, permite a sus empleados el uso de internet?: Todo el tiempo 12 75,00 Por horas 3 18,75 No permite 0 - No posee Internet 1 6,25 TOTAL ,00 Tabla 1.6. Uso de Internet en trabajo %

17 17 7.) Desearía que el centro infantil disponga de un servicio de monitoreo infantil vía web (internet)?: Si 14 87,50 No 1 6,25 No contesta 1 6,25 TOTAL ,00 Tabla 1.7. Consulta sobre Monitoreo en CI % De lo observado en los resultados de las encuestas, se puede deducir que la mayoría de padres de familia: Relaciona el aumento de rendimiento laboral al cuidado de niños (68.75%) Cree que ayudaría mucho o poco el monitoreo (100% entre los 2 aspectos) Cree que mejoraría el rendimiento con el monitoreo con cámaras (75% entre los dos) Tienen acceso a internet (75%). Se inclina por un servicio de monitoreo vía web (87,50%). Tomando en cuenta los resultados anteriores, es altamente factible la implantación de una solución, como la propuesta en el presente tema Requerimientos de ubicación de Cámara IP De acuerdo a lo citado anteriormente, y en base a lo conversado con la directora del centro infantil, se determina que la cámara IP (para fines demostrativos y costos se instalará solo una cámara), se ubicará en el área de niños comprendidos entre 1-3 años (Ver Figura 1.2 Ubicación de cámara IP), que son los niños con más requerimiento de monitoreo por parte de los padres, tal como lo muestra el gráfico adjunto.

18 18 Cámara IP. Requerida para monitoreo de niños de 1-3 años. Figura 1.2. Ubicación de cámara IP 1.4. Características que tendrá el aplicativo para el Centro Infantil: Tomando en cuenta la naturaleza del centro infantil, la solución integral para cubrir con los objetivos del presente tema deberá constar de lo siguiente: Del Aplicativo Web: - Portal Web del centro infantil que contendrá la siguiente información: o Información General del Centro Infantil. o Menú de Opciones (Inicio, Acerca del centro, Horario de atención, Contáctenos) o Link para ingreso de usuarios registrados. o Link para acceso a ver video mediante cámara IP, para el cual deberá ser validado el usuario que ingresa.

19 19 - Administración de usuarios (ingreso de padres de familia). Esta administración de Usuarios, correrá como parte del Portal seleccionado (Liferay), que en este caso se encargará del manejo de las seguridades. - Creación del Portlet, para el monitoreo de las imágenes que emita la cámara IP. De los recursos necesarios para dicha implementación: - Adquisición de Hosting para albergar el sitio Web del Centro Infantil.- Para esto se utilizará el proveedor de hosting sever4you ( el cual es un proveedor con equipos aptos para implementar la solución, así como el soporte de las diferentes tecnologías (Liferay, Mysql, Java, etc.) a usar en el desarrollo del presente tema. - Cámara IP, que soporte Java (La selección de la cámara se detalla en el apartado Investigación de funcionamiento de tecnología IP ). - Conexión a Internet tipo ADSL 1 (proveedor TV-Cable), con velocidad superior a 1Mbit de transmisión. La fidelidad y resolución de las imágenes, dependerán de las pruebas de video en la etapa de desarrollo Ubicación física del centro infantil en la ciudad de Quito - Ecuador. A continuación se presentan las imágenes de la ubicación física del Centro de Desarrollo Infantil en la ciudad de Quito (Ver Figura 1.3.). Dirección: Calle Lugo E y Pasaje 3. Ciudad: Quito Sector: La Floresta 1 ADSL.- siglas en inglés Asymmetric Digital Suscriber Digital.Transmisión analógica de datos digitales.

20 20 Figura Ubicación física del Centro (Imagen tomada de GoogleMaps) 1.6. Investigación de funcionamiento de tecnología IP vía web (manejo de cámaras IP) Las Cámaras IP (también conocidas como cámaras Web o de Red), son cámaras de video especialmente diseñadas para enviar las señales de video, y en algunos casos audio, a través de Internet desde un navegador de internet (ej, Internet Explorer, Firefox, Crome, etc), o a través de concentrador (un HUB o un SWITCH) en una Red de Datos Local (LAN por sus siglas en inglés). Este tipo de cámaras (IP), puede integrarse aplicaciones para: detección de presencia o movimiento (inclusive se puede enviar correos automáticamente, si detectan presencia), grabación de imágenes o secuencias en equipos informáticos para almacenamiento (tanto en una red local o en una red externa (WAN), de tal forma que al analizar el movimiento se pueda grabar las imágenes correspondientes. A continuación se muestra un gráfico de la estructura física (Figura 1.4. Gráfico de la Estructura física de conexión IP), de la conexión de una cámara IP tanto en un entorno de Red de área local, como para internet, así:

21 21... switch / Internet Usuarios Figura Gráfico de la Estructura física de conexión IP En la actualidad, las cámaras IP están siendo utilizadas en un sinnúmero de entornos para la vigilancia o promoción (utilizando cualquier conexión a internet y un navegador), entre los cuales están: Hogar: " para vigilar " la casa, negocio, empresa, a personas mayores, a niños o bebés. Trabajo: puede utilizarse para controlar puntos del negocio a los cuales no hay acceso visual tanto dentro de la empresa como los locales externos, estacionamientos, entradas, puntos de venta, etc. Hosterías, restaurantes, centros deportivos, museos, control de animales, etc. En el caso concreto del desarrollo del presente tema de tesis, se la usará para vigilancia y monitoreo de los niños del centro de desarrollo infantil Popeye s, de la ciudad de Quito Componentes de las cámaras IP Como se dijo anteriormente, las cámaras IP son cámaras de video, que a diferencia de una video cámara tradicional, dispone adicionalmente de: Componentes de una cámara de video tradicional (lentes, sensores, procesador digital de imagen, etc.) Un sistema de compresión de imagen (para poder comprimir las imágenes captadas por la cámara a formatos adecuados como MPEG4), de tal manera

22 22 que se disminuya el tiempo y el impacto en la utilización de ancho de banda de internet o LAN. Un sistema de procesamiento (CPU, FLASH, DRAM y un módulo Wireless ETHERNET/WIFI). Este sistema de procesamiento se encarga de: Gestión de las imágenes que incluye el envío de las mismas al módem, del movimiento de la cámara (si dispone de motor), de la detección de movimiento, etc Requerimientos de conexión para una cámara IP en internet o LAN. Debido a que uno de los objetivos de las cámaras IP es el envío de imágenes vía web, no cabe duda que es importante disponer de una conexión a Internet. Para ello se conecta la cámara IP a un Router 2 ADSL, XDSL, o Cablemodem (o a un HUB) u otros sistemas de banda ancha. No es necesario IP fija, ya que en el caso de IP dinámica se puede acudir a sitios como o (algunas cámaras vienen con sitios de resolución dinámica de IP s especiales ) para la resolución DNS. Una vez se disponga de lo anteriormente citado, únicamente se necesita conectar la cámara al Router ADSL y a la alimentación eléctrica, esto para el caso del acceso vía internet, caso contrario si el objetivo es usar la cámara en una red local, debemos conectar la misma a un HUB/SWITCH con lo que pasa a ser un equipo más que se comunica con el resto de nuestra LAN (si la LAN dispone de conexión a Internet, se podrá acceder desde el exterior a la red) Seguridades de acceso a las cámaras IP. Un tema que ha llevado a preguntarse si es seguro utilizar cámaras IP, es justamente su accesibilidad, debido a que da la impresión de que una vez conectada a internet, un usuario con conocimientos específicos sobre tecnología, podría acceder a las imágenes que se están capturando. Bueno, esta duda cabe indicar que tiene una respuesta contundente, y es que, las cámaras IP, de la misma manera que los servidores de Vídeo (que hacen Streaming 3 de video), dispone de un software interno 2 Router.- Término inglés para Enrutador. Dispositivo para interconexión de red de computadores, que opera en la capa 3 del modelo OSI. 3 Streaming.- Término inglés que indica la emisión de audio o video por la red.

23 23 para manejar el tema de seguridad, lo que permite establecer varios niveles de seguridad sobre el acceso a las mismas, y entre los cuales están: Nivel de Administrador: que sirve para poder configurar diferentes parámetros de la cámara, como lo es: manejo de direcciones IP, claves de acceso, etc. En este nivel se solicita nombre de usuario y una clave para accesar al mismo. Nivel de Usuario: que sirve para que el usuario pueda ver las imágenes que se están capturando, manejar la cámara así como el relé de salida. Igual que en el anterior nivel, se solicita un nombre y clave de usuario. Nivel Demo: este nivel está pensado para permitir un libre acceso a lo que emita la cámara por tiempos delimitados, por lo tanto no es necesario ningún tipo de identificación. Tomando en cuenta los accesos, se puede decir que la cantidad de accesos de usuarios de cualquier nivel que podría cubrir cada cámara IP, por lo general, es de aproximadamente entre 10 a 20 usuarios Características de audio y video emitido por las cámaras IP. Con respecto al audio, la mayoría de cámaras IP incorporan micrófonos de alta sensibilidad, con la finalidad de transmitir audio mediante el protocolo de conexión UDP 4. En la parte de video, las cámaras IP poseen un sistema de compresión de imagen, el cual sirve para hacer que la información obtenida de la cámara (que es mucha información y de gran tamaño) ocupe la menor cantidad de tamaño, ajustando a los anchos de banda de los sistemas de transmisión, por lo que si no se comprime adecuadamente es imposible enviar la misma a través de una red Local (LAN) o de las líneas telefónicas. Al comprimir las imágenes enviadas, se evita adicionalmente que sufran pérdidas en la calidad o en la visualización. 4 UDP.- Siglas en inglés de User Datagram Protocol. Protocolo del nivel de transporte para envío de datagramas.

24 24 Los estándares de compresión actuales son el JPEG(Joint Picture Experts Group) y MPEG4 (Moving Picture Experts Group), este último es el más reciente y potente (Optmizado para videoteléfonos y PDA, maneja un bajo ancho de banda.) Selección de Cámara IP para el desarrollo de tesis Para lograr realizar la captura de imágenes en el centro de desarrollo infantil Popeye s, se seleccionó la cámara IP Dlink DCS-2102 (Ver Figura 1.5.), la cual tiene un soporte para JAVA, que permitirá realizar la implementación de la interfaz correspondiente para adaptarla al portal. A continuación se hace una breve descripción y características de la cámara: Descripción General de la cámara IP DLINK DCS-2102 La cámara de vigilancia IP DCS-2102 de D-Link (Ver Figura 1.5. Imagen de cámara Dlink - DCS-2102) proporciona una solución de vigilancia versátil y única tanto para la pequeña oficina como el hogar. A diferencia de una cámara conectada a Internet estándar, la cámara IP DCS-2102 es un sistema completo de seguridad y vigilancia ya que incorpora una CPU interna y un servidor web que transmite imágenes de vídeo de alta calidad entregando en sus manos la posibilidad de mantener ambientes totalmente vigilados durante las 24 horas del día. La cámara de vigilancia IP DCS-2102 permite acceder a las imágenes en cualquier momento y controlar todas las funciones operativas de la cámara en forma remota desde cualquier PC o computador portátil, ya sea desde la red local como través de Internet utilizando de manera fácil rápida y sencilla su propio navegador web. Figura Imagen de cámara Dlink - DCS-2102 (tomada de la página web del fabricante)

25 Características físicas indicadas por el fabricante Entre las principales características que tiene la cámara IP Dlink a utilizar en el presente proyecto, están: Interfaces - 1 Puerto RJ-45 10/100 BASE-TX - Auto-negociación MDI/MDIX Hardware Video - Sensor: 1/4"color CMOS sensor, 1.3 Mega pixel. - SDRAM 64 MB - Memoria Flash 8 MB - Soporte Disparador Electrónico Automático - Disparador Electrónico 1/60 1/15000 segundos. - Modos de salida de sensor - VGA (640x480), XGA (1024x768) y SXGA (1280 x 1024). - Flip & mirror - Zoom digital hasta 4X - Soporta ActiveX, Java - Soporta compresión MPEG-4/MJPEG y JPEG para imágenes sin movimiento. Protocolos Soportados - IPV4, ARP, TCP, UDP, SMTP, ICMP,DHCP Cliente, NTP Cliente (D-Link), DNS Cliente, DDNS Cliente (D-Link), SMTP Cliente, FTP Cliente, HTTP Server, Samba Cliente, PPPoE, RTP, RTSP, RTCP, 3GPP, LLTD, SSL, SIP, UPnP-x, UPnP AV, 3GPP Administración y Upgrade - Configuración vía Web browser, notificación de alertas vía FTP e . - Firmware upgrade vía TCP/IP

26 26 Sistema operativos soportados - Windows 2000, XP, Vista, 3GPP (3rd Generation Partnership Project) 1.7. Investigación y selección de metodología de desarrollo y herramientas tecnológicas para crear el aplicativo web. De las distintas metodologías de desarrollo, así como de tecnologías orientadas a internet que adicionalmente dan una versatilidad en la implementación de aplicaciones Web, se determinó que tanto la metodología de desarrollo así como las herramientas más útiles para poder realizar la implementación del proyecto planteado (tomando en cuenta las mejores herramientas de código abierto), son las siguientes: Scrum, como metodología de desarrollo. Liferay, como portal. Eclipse, como Framework para desarrollo de Portlets (Aplicativos web). A continuación se hará una breve descripción de cada una de las tecnologías seleccionadas, para las cuales también se ha elaborado un análisis comparativo de sus pares en cada una de ellas, para posteriormente en el capítulo de desarrollo ir indicando el uso específico de las mismas SCRUM, como metodología de desarrollo. Antes que nada, SCRUM (melé en inglés) como metodología de desarrollo ágil (ahora implementado para otras áreas), proviene de un término usado en el Rugby que se traduciría como colaboración entre partes para alcanzar un objetivo, por lo que a diferencia de otras herramientas no proviene de un término reducido por siglas como es costumbre en tecnología. Actualmente existen algunas metodologías de desarrollo de software, sin embargo, entre las metodologías que mejores resultados han generado, están las metodologías ágiles, las mismas que han logrado ajustarse a la dinámica del mercado, el cual obliga a la obtención de resultados rápidos, buenos y baratos. En la Tabla 1.8. (Cuadro comparativo de metodologías ágiles) se puede apreciar las características de 2

27 27 de las principales metodologías ágiles que destacan en la actualidad (Xtreme Programing XP y SCRUM). SCRUM como metodología, justamente ha sido la más adoptada por su facilidad de uso e implementación, por lo que al ser este proyecto de tesis, de tipo rápido en lo que se refiere a desarrollo, se optó por seleccionar esta metodología. Esto implica que, de acuerdo a la metodología, se pueden ir obteniendo resultados rápidamente, especialmente al utilizar otras tecnologías (como Liferay), que hacen que el desarrollo y obtención de resultados sea ágil y no tan costoso en cuestión de tiempos y recursos tanto humanos como materiales. Características Fortalezas Debilidades XP Desarrollo iterativo e incremental Pruebas unitarias contínuas Programación en parejas Frecuente integración del equipo con el cliente Corrección de todos los errores antes de continuar con nuevos requerimientos Refactorización del código Simplicidad del código Propiedad del código Trabaja en función de la previsión Retroalimentación Disminución al máximo de errores Simplicidad Usado generalmente para proyectos pequeños Dificultad para determinar costo del proyecto Posibles retrasos para la entrega de proyecto Se debe pensar el proyecto anticipadamente, lo que dificulta la adaptabilidad a cambios SCRUM Desarrollo iterativo e incremental Se basa en ciclos (iteraciones, sprints) Pruebas por cada sprint Desarrollo en grupos de hasta máximo 8 personas Interacción contínua con el cliente Adaptabilidad a los cambios frecuentes Equipos auto-organizados e incentivados Entrega de resultados de alta calidad en tiempos cortos Tabla 1.8. Cuadro comparativo de metodologías ágiles Orientado más a procesos que a desarrollo de software Pueden haber errores no detectados a tiempo En el Anexo 2. (Descripción de la metodología SCRUM), se detalla la historia del cómo se creó esta metodología, así como los conceptos manejados por la misma.

28 28 Por lo tanto, y tomando en cuenta lo que indica la teoría de la metodología en cuestión, tenemos que, los elementos que componen a la estructura de la metodología SCRUM de acuerdo al proyecto planteado, son (ver Tabla 1.9. Integrantes para aplicación de metodología SCRUM): ELEMENTO SCRUM Definición de cada Elemento Persona(s) involucrada(s) Scrum Master Director del Proyecto de tesis Ing. Guido Riofrío Product Owner Dueño del producto. Directora del Lic. Tatiana González CI. Team Grupo de desarrollo. Para este Max Morillo caso, solo una persona. Product Backlog Pila de requisitos a implementar. Max Morillo Ver Tabla 1.9. Sprint Backlog Pila de requisitos por cada Max Morillo elemento del product backlog. Ver Tabla Sprint Tiempo definido para el Product Backlog Tabla 1.9. Integrantes para aplicación de metodología SCRUM Proceso de aplicación de metodología SCRUM. Con los datos de la investigación preliminar, se puede hacer un acercamiento detallado de cómo funcionará la metodología SCRUM para el presente tema. Cabe indicar que esta metodología está pensada en la colaboración entre miembros de desarrollo para lograr obtener un resultado óptimo en el menor tiempo, por lo que al ser este tema de implementación unipersonal, se tratará de enfocar los puntos que señala la metodología haciendo énfasis en la colaboración de todas las personas involucradas. A continuación se detallan como ejemplo, algunos de los requerimientos observados de acuerdo al estudio preliminar (Ver cuadro Tabla Pila de requerimientos priorizados (Product Backlog) ):

29 29 Requerimientos Prioridad Estimación del Valor (Rango 1-7) Estimación del Esfuerzo Inicial (Rango 1-25) Elaborar un portal para el Centro Infantil Crear un aplicativo de monitoreo de niños embebido en el portal del Centro infantil Tabla Pila de requerimientos priorizados (Product Backlog) De acuerdo al cuadro anterior (Tabla 1.10.), se desprenden los Sprint Backlogs, que no son otra cosa que tareas agrupadas y asignadas al desarrollador (a mi persona, en este caso por ser un tema unipersonal) con una estimación del valor, para la evacuación de los mismos (Ver Anexo 2. Apartado A2.3.), así se tiene el siguiente cuadro ejemplo (Tabla Sprint Backlog.): Product Backlog (pila de requerimientos) Sprint Task (Tareas por Sprint) Desarrollador Tiempo de duración estimado Elaborar un portal para el Centro Infantil - Crear página Web principal con Liferay Portal. Max Morillo 2 semanas. - Manejar roles de usuarios, etc.. 1 día... Tabla Sprint Backlog. En el Anexo 2. (Descripción de la metodología SCRUM), se mostrará la aplicación de la metodología completa y su aplicabilidad al desarrollo del aplicativo del tema en cuestión LIFERAY, como portal. Una definición aproximada de Portal, de acuerdo a la experiencia personal en la utilización de Portales es: Sitio WEB que proporciona a las personas el acceso a información, aplicaciones y procesos de negocios. Todo esto, desde un único punto de entrada. En la actualidad existen un sinnúmero de empresas o marcas, que han desarrollado Portales o manejadores de portales, tendientes a dar facilidad en la implementación de este tipo de soluciones. Tal es así, que empresas de renombre como: IBM, Oracle, Jboss, etc, han desarrollado sus propios aplicativos orientados a este tipo de

30 30 soluciones, entre los cuales tenemos: Websphere Portal, Oracle Portal, Jboss Portal, etc, respectivamente. La mayoría de estas empresas, por sus características, desarrollan aplicaciones o herramientas propietarias, sin embargo, las herramientas Open Source, han ido ganando terreno, por lo que han proliferado un sinnúmero de ellas por sus ventajas económicas y técnicas. Tomando en cuenta las diferentes opciones que se tienen en el mundo de los portales OpenSource, y al ser uno de los objetivos del desarrollo del presente tema el hecho de utilizar este tipo de herramientas, se ha seleccionado a Liferay (Ver Anexo.3. Revisión General de Liferay como Portal) por las siguientes razones: - Está basado100% en Java, por lo tanto, se puede adaptar cualquier aditamento hecho o por desarrollar en el mismo lenguaje. - Se puede instalar sobre cualquier plataforma o SO, por lo que se hace fácil su mantenimiento e instalación. - Es OpenSource (en su versión Community), lo que facilita la personalización e incorporación de cualquier cambio que se requiera, sin la necesidad de estar atados a las especificaciones del fabricante. - Facilita a cualquier usuario, ya sea este principiante o experto, el manejo y administración del portal. En el caso del presente tema, el portal debe permitir el fácil manejo de la administración al grupo de usuarios Administrador, que en este caso será la directora del Centro Infantil o a quien delegue tal acción. - Se puede manejar un motor de base de datos independiente al que viene por defecto (HSQL), por lo que es posible conectar a la base de datos seleccionada para este caso (MYSQL). Con esto se posibilita el almacenamiento de la información relacionada a por ejemplo: Usuarios, Grupos de usuarios, etc. - Se pueden construir aplicaciones (Portlets), para adaptarlas al portal, sin ningún tipo de modificación a la estructura de Liferay. En el caso específico del presente tema, se deberá crear una aplicación o portlet para el manejo de las imágenes que genere la cámara IP conectada en el Centro Infantil. - Posee potentes formas de dar seguridad al acceso de usuarios, lo que hace fácil el manejo de la autenticación de usuarios. - También es factible realizar enlaces con otras aplicaciones (servidores LDAP), otros CMS como Alfresco, etc.

31 31 A continuación se muestra un cuadro general comparativo de las fortalezas y debilidades (Tabla Fortalezas y debilidades de los portales) entre 3 proveedores de Portales (JbossPortal, exo y LIFERAY), de los cuales sin duda, se destaca además de las razones anteriormente expuestas, por lo siguiente: Fortalezas Licencia Open Source JBOSS exo LIFERAY Variedad herramientas colaborativas de Distribuido junto a un elevado número de portlets funcionales Variedad en las opciones de mantenimiento ofrecidas por la empresa Debilidades Sólo utiliza el servidor de aplicación Jboss Licencia Open Source Abierto a distintos servidores de aplicación Complejidad del desarrollo de componentes para el portal Temas y plantillas de aspecto desarrollados por la comunidad Licencia Open Source Necesarios conocimientos avanzados de J2EE (JEE), para el desarrollo de componentes del portal Tabla Fortalezas y debilidades de los portales Una de las funcionalidades interesantes que tiene liferay entre otras y que sin duda es uno de los dolores de cabeza de cualquier desarrollador de sistemas, es lo referente al manejo de seguridades. Para este punto, Liferay opera con diferentes tipos de manejo de seguridades como: General LDAP (Lightweight Directory Access Protocol) CAS (Central Authentication Service) NTLM (NT Lan Manager) OPEN SSO (Single Sign On) Para el desarrollo del presente tema se seleccionará el manejo de seguridades General, que es el que contemplan la mayoría de Portales, incluído Liferay.

32 32 Además de las seguridades, Liferay al ser un producto de código abierto, se puede explotar una característica importante y que refiere a la implementación y puesta en marcha de Portlets (aplicaciones pequeñas) en caliente, es decir, se puede aplicar un portlet determinado y el o los usuarios del portal lo verán inmediatamente desplegado (siempre que tengan acceso para su visualización, claro está). En la Figura 1.8. se puede apreciar el modelo de funcionamiento de Liferay, donde podemos observar lo referente al manejo, tanto de usuarios como de su salida (layout), donde se incluyen los portlets mencionados.

33 Figura Modelo de funcionamiento de Liferay 33

34 Esquema de funcionamiento de la solución con Liferay Tomando en cuenta las características indicadas tanto en la Figura 1.8 (Modelo de funcionamiento de liferay), así como las fortalezas del mismo, para el presente tema de desarrollo se tiene que funcionaría bajo el siguiente esquema (Ver Figura 1.9. Esquema general de funcionamiento de solución con Liferay): LIFERAY PORTAL Manejo de Seguridades General Usuario autenticado Roles y Permisos BDD Administración de Portlets Figura Esquema general de funcionamiento de la solución con Liferay En la fase 2 de diseño del modelo, se especificará a profundidad toda la estructura del modelo a seguir para la implementación de la solución. Sin embargo, como veremos en el siguiente apartado de Portlets, éstos al ser aplicaciones que se las puede desarrollar y personalizar de acuerdo a las necesidades de los usuarios, se podrá observar cómo se facilita el desarrollo de un portlet utilizando Eclipse como framework de desarrollo del portlet del manejo de video de la cámara IP.

35 Portlets (Aplicativos) Como se había mencionado anteriormente, Portlet hace referencia a un pequeño programa web que corre en un portal. Liferay (al igual que otros Portales) al trabajar con Portlets, hace que cada uno de ellos se comporte como una aplicación. Para la implementación de Portlets, se debe tomar en cuenta el estándar JSR-286 5, que es un modelo de programación conveniente para los desarrolladores de portlets en Java. Este nuevo modelo JSR-286 que se creó posterior al modelo JSR-168 es una versión mejorada, y es la versión 2.0 de Java Portlet Specification, desarrollada según el JCP(Java Community Process) y creada en alineación con la versión 2.0 de Servicios Web para Portlets Remotos (en inglés Web Services for Remote Portlets WSRP). Entre las características principales de este estándar están: Comunicación entre Portlets a través de eventos y renderización de parámetros públicos. Entregar recursos generados dinámicamente de forma directa mediante los portlets. Entregar datos de AJAX 6 o JSON 7 de forma directa mediante los portlets. Introducción de filtros y escuchas de portlets. Tomando en cuenta la Fig 1.9 (Esquema general de funcionamiento de solución con Liferay), se puede observar el proceso Administración de Portlets, el cual es manejado enteramente por el portal en sí (LIFERAY), como se pudo observar en la figura 1.8. (Modelo de funcionamiento de Liferay). Por lo tanto, fácilmente se puede deducir la gran facilidad de administración de portlets, tanto los propios o nativos del portal, como de los portlets definidos por el usuario. 5 JSR Del inglés Java Specification Request. Estándar para la implementación de portlets, desarrollado para mejorar las deficiencias de la versión 1.0 de la especificación JSR AJAX.- Siglas del inglés Asynchronous Javascript And Xml. Técnicas de desarrollo para crear aplicaciones interactivas. 7 JSON.- Acrónimo de JavaScript Object Notation. Formato ligero para intercambio de datos.

36 36 El siguiente gráfico (Figura Esquema de administración de Portlets), ilustra el funcionamiento macro de cómo tanto la utilización del código abierto de Liferay (SDK de Liferay), como del framework correspondiente (Eclipse en este caso), se puede obtener una aplicación o portlet que sea fácilmente ser insertado dentro del portal. Cabe anotar que esta facilidad de desarrollo se da por la ya anotada característica de Liferay que es 100% basada en java. LIFERAY Navegador Aplicación Web del Portal Centro Infantil Popeyes Contenedor de PORTLETS Portlet A Portlet B. Portlet Monitoreo Web Cam Otros Portales Productor WSRP Figura Esquema de administración de Portlets ECLIPSE, como Framework para desarrollo de Portlets. En la actualidad existen muchas herramientas para desarrollo e implementación de código, entre las cuales y las más destacadas por su utilización a nivel mundial están: Eclipse (Fundación Eclipse) y Netbeans (patrocinado por Sun Microsystems). En la tabla 1.13 (Características de los dos principales entornos de trabajo), se hace una explicación resumida de las bondades de los dos frameworks antes mencionados. Cabe señalar que no existe una característica especial que haga la gran diferencia entre los dos entornos de desarrollo, por lo que generalmente se aplica la familiaridad y

37 37 adaptabilidad para trabajar, por parte de un desarrollador, como factores que hagan inclinarse hacia una u otro entorno de trabajo. NETBEANS Basado en asistentes (wizards) Dispone de editor de texto con revisión de sintaxis. Se puede administrar las interfases y configuraciones de usuario Basado en sistema de proyectos de ANT ECLIPSE Compilación en tiempo real Dispone de editor de texto con resaltado de Sintaxis Integración con ANT Se pueden realizar pruebas unitarias con Junit Control de versiones Control de versiones con CVS 8 Refactoring Maneja varios lenguajes, JAVA incluido. Soporta Plug-ins Integración con Hibernate Dispone de asistentes (wizards), para creación de proyectos, clases, etc. Refactoring Soporta agregación de Plug-ins Maneja varios lenguajes, entre los cuales está JAVA Tabla Características de los dos principales entornos de trabajo Para el caso específico del presente proyecto de tesis, se seleccionó Eclipse como entorno de trabajo, debido a que Liferay (Portal) ya dispone de un Plug-in para este framework, y adicionalmente por la familiaridad con este framework (entorno de trabajo). Finalmente Eclipse al igual que Netbeans, también maneja muy bien Java como lenguaje de programación, por lo que es un punto importante a tomar, en la selección del framework antes mencionado. En la figura 1.10 (Esquema de administración de Portlets), se puede observar cómo Eclipse se adapta para el desarrollo de los portlets, y en el caso de este tema de tesis, para la implementación del portlet Monitoreo de Web Cam. Por lo tanto Eclipse (Ver ANEXO 4. ECLIPSE, como Framework para desarrollo de Portlets), será la herramienta a utilizar para el desarrollo del portlet correspondiente al manejo del video que emitirá la cámara Web, el mismo que dará la funcionalidad requerida por el Centro de Desarrollo Infantil Popeye s, además, que se puede aprovechar el código fuente de Liferay para su debida implementación. 8 CVS.- del inglés Concurrent Versioning System. Aplicación que permite controlar las versiones del código o software desarrollado

38 38 A continuación se muestra el diagrama de representación de cómo eclipse interactuará con liferay (SDK 9 de liferay), para la implementación del portlet correspondiente. (Ver Figura Esquema de trabajo con Eclipse) LIFERAY Aplicación Web del Portal Centro Infantil Popeyes Portlet Monitoreo Web Cam Plug-In A Plug-In B. API Web Cam Plug-In LIFERAY SDK Internet Web Cam Figura Esquema de trabajo con Eclipse 9 SDK.- Siglas del ingés Software Developement Kit. Conjunto de herramientas de desarrollo que ayudan a un programador a crear aplicaciones.

39 39 FASE 2 MODELAMIENTO Y DESARROLLO DEL APLICATIVO Una vez se ha realizado tanto la investigación preliminar, como la selección de las herramientas adecuadas para el desarrollo del presente proyecto, en esta fase se determinará el modelo a seguir y su inmediata implementación, tomando en cuenta toda la información recopilada, la cual se ha consolidado para modelar la solución. A continuación se muestra un resumen de lo que es el Centro Infantil, para seguir con el proceso de análisis y desarrollo del presente tema Perfil del Centro Infantil. El Centro Infantil, se dedica al cuidado, educación y atención de niños en edades comprendidas entre el 1 año hasta los 6 años de edad. Tiene como objetivo: Contribuir técnica y profesionalmente para que los niños y niñas alcancen un desarrollo bio-psicosocio cultural-espiritual adecuado, dentro de un marco afectivo y de valores respetando su ecosistema y su ideología 10. Tomando en cuenta lo expuesto en la primera fase (Ver apartado 1.1. Datos generales del Centro Infantil Popeye s), el Centro Infantil (CI) requiere de una solución web para facilitar a sus clientes (padres de familia) obtener información de lo que el Centro Infantil hace, así como facilitar un acceso seguro para el monitoreo sus niños vía internet. De lo indicado anteriormente, se puede concluir que específicamente el CI necesita: 1. Un Portal Web para el CI, en el que los usuarios puedan acceder a la información del mismo, y que contendrá lo siguiente: 10 Objetivo tomado del documento de creación del CDI Popeyes.

40 40 o Información General del Centro Infantil. o Administración de usuarios o Creación de un aplicativo de captura de imágenes digitales, para posterior monitoreo de niños a usuarios autenticados. Para la creación del Portal, así como la administración de usuarios, se utilizará LIFERAY, del cual se reutilizará toda la lógica interna para el manejo tanto de la administración del portal, como la administración de usuarios Planificación del proyecto utilizando la metodología SCRUM Como primer punto de partida en esta fase, se tiene la especificación del Product Backlog ( pila de requerimientos ) completo (Ver. Tabla Product Backlog inicial), esto tomando en cuenta la metodología SCRUM. En esta pila de requerimientos, se ha detallado los requerimientos fundamentales implicados en el presente proyecto. Requerimientos Prioridad Estimación del Valor Rango (1-7) Estimación del Esfuerzo Inicial Rango (1-25) Elaborar un portal para el Centro Infantil Crear un aplicativo de monitoreo de niños embebido en el portal del Centro infantil Tabla 2.1. Product Backlog inicial De acuerdo a la tabla anterior, se puede observar que se tiene únicamente dos requerimientos que englobarán las diferentes tareas o actividades, las cuales se las detalla en la tabla de Sprint BackLog (Ver. Tabla 2.2.). De acuerdo a la metodología, la tabla de Sprint Backlog, contiene todas las tareas a realizar y las cuales tienen un peso así como un tiempo estimado de desarrollo. En el proceso de desarrollo de cada una de las tareas, el miembro del equipo de desarrollo se encarga de cada una de las tareas. El término Sprint comúnmente utilizado en las carreras de autos, se debe justamente a su derivación de velocidad, donde cada tarea se la realiza en el menor tiempo posible. A continuación se detalla la lista de tareas (Sprint Backlog) a realizar en el presente proyecto (ver Tabla 2.2. Sprint Backlog):

41 41 Elemento de la Pila del Producto Tareas por Sprint Voluntario Sprint Estimación del Esfuerzo Inicial Rango (1-7) Analizar y obtener requerimientos del cliente para el portal del CI 1 4 Diseñar el modelo conceptual del portal 1 5 Diseñar pantallas de portal de acuerdo al modelo conceptual del mismo 1 4 Consultar en diferentes fuentes la documentación sobre instalación de Liferay Portal. (Adquirir bibliografía de autores experimentados en la herramienta). 2 7 Instalar y configurar java jdk en servidor Linux CentOs Instalar y configurar Mysql en servidor CentOs 5. Incluye creación de instancia de BDD para interacción con Liferay. 2 3 Elaborar un portal para el Centro Infantil Descargar la versión libre de Liferay Versión Community + Jboss AS 2 1 Configurar el servidor de aplicaciones Jboss embebido en Liferay Portal. 2 6 Definir plantilla de temas (Template) para el portal, y disposiciones (Layouts) de cada página. Max Morillo 3 3 Crear página Web principal y opciones públicas, con Liferay Portal. 3 5 Crear usuarios en liferay, de acuerdo a listado entregado por la Directora del CI. 4 4 Crear grupos de usuarios en liferay, para asignación de usuarios. 4 4 Crear roles para asignación a grupos de usuarios y sus permisos correspondientes. 4 4 Definir restricciones de acceso a opción de "Monitoreo Web Cam." 4 3 Instalar Cámara con conexión a Router Inalámbrico Dlink DIR Crear un DNS dinámico para conexión remota de cámara IP Dlink. (ver alojamiento Dinámico gratis 5 5 DYNDNS.ORG) Investigar la forma de emisión de video de la cámara, para captura de imágenes desde el portlet a crear. 5 7 Realizar pruebas de funcionamiento del portal 5 5

42 42 Analizar y obtener requerimientos del modelo del aplicativo de monitoreo de niños 6 4 Diseñar el modelo conceptual del portlet para el monitoreo de niños 6 5 Diseñar el modelo de Casos de Uso del aplicativo de monitoreo 6 5 Descargar plug-in de Liferay con Tomcat, para Eclipse. 7 1 Cargar y configurar Plug-in de Liferay SDK para Eclipse en ambiente de desarrollo. 7 5 Crear un nuevo proyecto Plug-in Portlet llamado CamaraIPPortlet 7 6 Investigar la forma de generación de portlets con framework de Liferay. 7 7 Crear un aplicativo de monitoreo de niños, embebido en el portal del Centro Infantil Crear archivo "service.xml", con definiciones de tabla de datos para la generación vía ServiceBuilder de 8 3 Liferay, del modelo, servicio y persistencia de datos. Definir entorno de variables para desarrollo de portlet de acuerdo a especificaciones de Liferay. 8 2 Programar métodos para almacenamiento y recuperación de datos 8 3 Programar View.jsp de presentación de imagen de cámara IP 8 5 Programar View.jsp de administración de Salones 8 5 Programar métodos de administración de Permisos para los portlets creados 8 5 Desplegar proyecto en ambiente de desarrollo para pruebas de conexión. 8 3 Desplegar proyecto en ambiente de producción. 9 5 Realizar pruebas de funcionamiento de los portlets desplegados en producción 9 4 Observación de impacto de la solución en Padres de familia con acceso a portal 9 4 Documentar y digitar marco teórico de tesis 10 7 Tabla 2.2. Sprint Backlog.

43 43 Para el desarrollo del presente proyecto, se irá especificando cada tarea del Sprint Backlog de su correspondiente requerimiento, así como toda la documentación de implantación o desarrollo de la misma, se la puede observar en el Anexo 2 (Descripción de metodología de desarrollo SCRUM) Análisis y Desarrollo del requerimiento: Elaborar un portal para el Centro Infantil. Una vez que se han definido los 2 requerimientos globales que conforman la documentación del Product Backlog (Pila de requerimientos) para el presente tema de tesis, se empezará con el desarrollo del requerimiento de la elaboración del portal para el Centro Infantil. Para el desarrollo de este requerimiento, se realizará una especificación detallada de cada una de las tareas que se definieron en la tabla 2.2. (Sprint Backlog), cuya documentación completa de la aplicación de la metodología se podrá observar en el Anexo 2. (Descripción de metodología de desarrollo SCRUM) Análisis del Portal El portal del CI debe permitir lo siguiente: 1. Mostrar la información general del Centro Infantil. 2. Realizar encuestas a Padres de Familia. 3. Ingresar usuarios con roles de Padres de Familia al sistema. 4. Ingresar y Mostrar noticias de interés. 5. Ocultar opciones de monitoreo de niños a usuarios Invitados. Una vez que se ha definido el alcance del portal, se puede especificar el esquema general que tendrá el mismo.

44 Diseño del modelo conceptual del Portal Como se podrá observar en la figura 2.2. (Estructura del portal del CI), existirán 7 opciones principales dentro del portal del CI. En cada una de las opciones se puede apreciar cada uno de los tipos de usuarios que podrán tener acceso a dicha información. El monitoreo de niños, por lo tanto, debe ser únicamente para los Padres de Familia y Administrador del Portal, por cuestiones obvias de seguridad. Home Accesos Inicio Quienes Somos (Guest) (Guest) Noticias (Guest) Sugerencias para padres (Guest) Contáctenos (Guest) Monitoreo Web Cam (Padre de Familia) Administración Salones (Administrador) Figura Estructura del portal del CI Diseño de pantallas del portal Para la construcción del portal, y tomando en cuenta el modelo de la figura 2.2. (Estructura del portal del CI), se tendrán los siguientes diseños de pantallas.

45 Diseño de Pantalla Inicio LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones Publicidad o Fotos del CI PORTLET DE NOTICIAS DEL CI PORTLET DE INFORMACIÓN GENERAL DEL CI Navegación Link de Horarios Link de Instalaciones Link de Fotografías. Figura Diseño de Página Inicio del CI Diseño de Pantalla Quienes Somos LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones Misión: Objetivo del Centro Infantil Visión: Visión: Figura 2.4. Diseño de Página Quiénes Somos

46 Diseño de Pantalla Noticias LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones NOTICIAS Entradas Figura 2.5. Diseño de Página Noticias Diseño de Pantalla Sugerencias para Padres LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones NOTICIAS Entradas Figura 2.6. Diseño de Página Sugerencias para Padres

47 Diseño de Pantalla Contáctenos LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones Mapa del centro Datos de teléfono, Dirección, del Centro Infantil Figura 2.7. Diseño de Página Contáctenos Diseño de Pantalla Monitoreo Web Cam LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones Salón: Menores de 2 años de 2 Fecha Emisión: V Hora Emisión: IMAGEN NO DISPONIBLE Figura 2.8. Diseño de Página Monitoreo Web Cam

48 Diseño de Pantalla Administración Salones LOGO Login: * Inicio Quiénes Somos Noticias Sugerencias para Padres Contáctenos Monitoreo Web Cam Administración Salones Id: Nombre: Ip. Cámara: Puerto: URL: Menores de 2 años /video/mpeg.cgi Guardar Id. Nombre Salón Ip. Cámara Puerto URL Acciones Editar/Borrar/ Figura 2.9. Diseño de Página Administración Salones Desarrollo del portal utilizando Liferay Portal La primera etapa del desarrollo del portal implica una serie de acciones que se describen en los apartados siguientes y que permitirán tener el entorno de Liferay operativo para desarrollar el contendio del portal e iniciar el desarrollo del aplicativo propuesto. Liferay al ser una herramienta de código abierto, tanto el servicio técnico, así como el soporte y documentación están en cierta medida restringidos al público en general, por lo que la mayoría de desarrolladores que utilizan esta herramienta debe revisar un sinnúmero de foros y documentación de comunidades para dicha implantación. Obviamente existe un servicio pagado que permite una instalación sin complicaciones, esta versión se la denomina Enterprise, pero para este caso, se utilizará la información y documentación del grupo COMMUNITY. Avanzando en el proceso de instalación de Liferay para la implementación del portal, se tiene que para dicho proceso es necesario contar con los siguientes pre-requisitos:

49 49 1. Servidor de Hosting con mínimo 2GB de Memoria y 250GB de disco, con Sistema Operativo CentOs Instalación de JDK de java 5.0 o superior. (De preferencia v ). 3. Instalación de base de datos MySql en CentOs. 4. Acceso vía Putty al servidor como administrador o root. 5. Paquete de Liferay 6.0 para su instalación. En el sitio oficial de Liferay ( existe un link que deriva a los foros (ej. de discusión tanto de la instalación como de los diferentes problemas que se presentan en la instalación de Liferay, especialmente con los bundles o servidores de aplicaciones embebidos o que vienen con alguna distribución. Para este caso se tomará la distribución: Liferay Portal Community Edition bundled with JBoss, es decir la versión de Liferay con Jboss como servidor de aplicaciones. Los recursos a utilizarse con sus correspondientes valoraciones, se las puede observar en el Anexo 6. (Recursos a utilizar en el desarrollo de la solución) Documentación de implantación de Liferay Tomando en cuenta los pre-requisitos, así como la información recopilada tanto del sitio oficial como de la documentación existente en otros foros y libros editados por expertos en Liferay, a continuación se detalla la documentación del proceso de implantación de Liferay Portal Instalación de Java en CentOs 5.0 Una vez que se ha contratado el hosting (Ver Anexo 5. Hosting), se deberá realizar la instalación en primer lugar del JDK de java. Para esto se deberán realizar los siguientes pasos: 1. Bajar la versión de JDK (disponible en el sitio oficial Para la versión de CentOs 5.0, se deberá obtener el JDK mediante el comando: $ wget c jdkadescargar 2. Una vez realizado el download o descarga del JDK, se deberá realizar la instalación del mismo. Ej. $ sudo./ jdk.rmp.bin

50 50 3. Luego de la instalación se deber realizar la declaración de las variables de ambiente. En el caso de CentOs, se deberá definir la variable JAVA_HOME, así: $ export JAVA_HOME=/home/jdk $ export PATH=/home/jdk/bin:$PATH $ echo $JAVA_HOME --> para verificar la instalación de la variable Instalación de Mysql en CentOs Para la instalación de Liferay es necesario disponer de una base de datos, aunque no es indispensable, debido a que trae internamente preinstalada una base Hsql. Para este caso, se utilizará Mysql, por lo que a continuación se detalla los pasos para dicha instalación: 1. Obtener la versión de Mysql (del sitio oficial 2. Instalar la versión descargada de mysql. 3. Una vez instalada la versión de Mysql, se debe ingresar y crear la instancia correspondiente para Liferay, así: $ mysql unombreusuario ppassword Si las credenciales son correctas, mostrará un mensaje como el que sigue: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 119 Server version: ubuntu5 (Ubuntu) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. 4. Crear la instancia para liferay una vez se esté dentro de mysql, así: mysql> create database lportal character set utf8; Una vez que se ha configurado la instancia de Liferay (en este caso lportal ), se tiene listo el ambiente previo a la instalación y configuración del Portal. En el siguiente apartado, se muestra la implantación de Liferay en el servidor en cuestión.

51 Instalación de Liferay con JBoss en CentOs 5.0 La versión de Liferay a instalar será la que viene con el bundle Jboss como servidor de aplicaciones. Para dicha instalación, se deberán realizar los siguientes pasos: 1. Obtener la versión de Liferay con bundle Jboss (en el sitio oficial de Liferay 2. Desempaquetar en un directorio, de preferencia del /home. Posteriormente se deberá configurar el archivo /liferay/jboss /bin/run.conf, donde se deberá determinar la cantidad de memoria que utilizará el servidor de aplicaciones. 3. Crear el archivo portal-ext.properties en el directorio raíz de liferay (esto para la versión 6.0.5), donde constará la conexión a la base de datos Mysql, así: # MySQL # jdbc.default.driverclassname=com.mysql.jdbc.driver jdbc.default.url=jdbc:mysql://localhost/lportal?useunicode=true&characterencodin g=utf-8&usefastdateparsing=false jdbc.default.username=admin jdbc.default.password=cholismoquis portal.ctx=/ 4. Borrar los accesos a la base de datos original hsql y el directorio sevencogs*, ya que si no se realiza este paso, Liferay tomará como inicio la base hsql, la cual no es recomendada en ambientes de implantación reales, según indicación del mismo fabricante. 5. Configurar el archivo httpd.conf, donde se configurará el puerto, así: 6. Configurar el archivo /liferay/jboss../server/default/desplegar/jboss.sar/web- INF/server.xml, donde se pondrá el puerto 80 en vez del 8080, para que el portal responda al nombre de dominio contratado. 7. Arrancar el servidor de aplicaciones jboss, con el comando: sudo nohup./run.sh b & El servidor mostrará el siguiente mensaje de carga completada: 01:57:34,487 INFO [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_ 5_1_0_GA date= )] Started in 39s:811ms 8. En un browser o navegador, colocar la dirección del dominio contratado, para la verificación del correcto funcionamiento de liferay con Jboss. La Figura 2.10 (Pantalla inicio Liferay), muestra la página inicial de Liferay cuando el proceso de instalación es correcto.

52 52 Figura Pantalla de Inicio de Liferay Crear la página Web principal y opciones públicas con Liferay. Una vez que se ha realizado el diseño tanto de la estructura del portlet, así como el diseño de las pantallas que integrarán la página web del CI, a continuación se muestra el funcionamiento de Liferay para el desarrollo del sitio Web propuesto Consideraciones previas a la creación de un sitio web con Liferay En la Figura (Pantalla inicio Liferay) anterior, se mostró la inicialización de Liferay, una vez que se han instalado todos los pre-requisitos mencionados en los puntos anteriores. Por lo tanto, a continuación se muestran algunas de las opciones que se deben tener en cuenta, antes de iniciar con el desarrollo de la página como tal para el CI. Para ingresar al ambiente de Liferay es necesario autenticarse. Por defecto (una vez que se ha instalado correctamente) el usuario de ingreso es test con su clave de igual manera test, tal como lo muestra la figura Figura (Autenticación inicial en Liferay).

53 53 Figura Autenticación inicial en Liferay Una vez autenticado correctamente, el usuario administrador, posteriormente podrá acceder a las diferentes opciones para administración del sitio correspondiente. En la figura Figura (Opciones de administración para usuario autenticado), se muestran las diferentes opciones que visualiza un usuario con roles de administrador. En los siguientes apartados, se detallará de mejor manera el funcionamiento de la autenticación en Liferay, con su respectivo manejo de usuarios.

54 54 Figura Opciones de administración para usuario autenticado Administración de Liferay En la siguiente figura Figura (Opciones de administración de Liferay Portal), se puede observar el detalle de las distintas opciones que dispone Liferay.

55 55 Figura Opciones de administración de Liferay Portal Específicamente para el desarrollo de un sitio web, es necesario tomar en cuenta algunos conceptos que Liferay maneja para desarrollar un sitio Web: a. Liferay, dispone de Páginas ( Pages en inglés), lugar donde se podrán colocar o poner los diferentes contenidos, b. Liferay, maneja portlets (aplicativos), que pueden tener contenido dinámico o estático. Estos portlets pueden ser administrados (insertados, borrados, modificados) por usuario(s) autenticados, y se pueden colocar en una o varias páginas del portal. Lo indicado anteriormente es particularmente interesante, desde el punto de vista del desarrollador o administrador del sitio, ya que se tiene la gran ventaja de poder crear o agregar un aplicativo (portlet), sin tener que modificar la codificación de la página (a nivel html, etc.). Claro está, que el portal deberá manejar el protocolo WSRP 11, sin el cual no se puede lograr el comportamiento plug and play de los portlets Agregación de páginas web Con los conceptos anteriormente anotados, se puede ver en el primer bloque de la figura Figura (Opciones de administración de Liferay Portal), la opción Página (Page), que hace referencia, a que con ella se podrá agregar páginas al sitio Web, tal como lo muestra la Figura (Agregar Páginas): 11 WSRP. (Web Services for Remote Portlets por sus siglas en inglés), Protocolo que suministra un estándar de servicios web, para permitir el "plug-and-play" de portlets en ejecución remotos desde fuentes dispares.

56 56 Figura Agregar Páginas Indistintamente del Template (Plantilla) que se verá luego, como se puede observar, la creación de páginas es amigable y sencilla, de tal manera que no se codifica absolutamente nada Agregación de Portlets (aplicativos) a las páginas Web Una vez que se ha creado la página (Inicio en este caso), se puede agregar distintos elementos, aplicativos o portlets, tal como se puede observar en la siguiente figura (Figura Agregar portlets): Figura Agregar portlets En la figura (Figura Incorporación de portlets a página), se puede observar que con solo arrastrar la aplicación correspondiente, se puede incorporar al contenido de la página, para posteriormente realizar las adecuaciones o modificaciones, de acuerdo a lo que requiera el portal o página.

57 57 Figura Incorporación de portlets a página Disposición de Página Web Algo que es importante mencionar, es el tema de la Disposición de la página, para el caso de la ubicación de los aplicativos o portlets dentro de la página web creada. Es así que, en las opciones de Liferay para administración (Ver segundo bloque de Figura Opciones de Liferay), existe una opción referente a Disposición de Página (Layout), donde se puede observar que es factible seleccionar cualquier formato de página, de tal manera que lo que se vaya agregando como portlets, tomen el formato escogido (ver Figura Disposición de Página).

58 58 Figura Disposición de Página Una vez definidos la disposición de la página y los portlets o aplicaciones que irán en la misma, se debe personalizar cada uno de los portlets, para colocar la información que se requiera Edición de un portlet de contenido Cada una de las aplicaciones que tiene disponibles Liferay, tiene un objetivo distinto, por lo que se hablará de uno de los portlets más comunes y utilizados en esta herramienta. Se trata del portlet Visor de Contenido Web ( Web Content Display por su correspondiente en inglés), en el cual se puede colocar contenido ya sea texto, imágenes, animaciones flash, links, e incluso se puede editar el contenido en html. En la figura siguiente, se puede mostrar dicha personalización (ver Figura2.18. Personalización de un Web Content Display):

59 59 Figura2.18. Personalización de un Web Content Display Como complemento a la explicación de la incorporación tanto de páginas como de aplicaciones o portlets, es necesario conocer dos aspectos si bien no esenciales, pero si importantes para la presentación de una página. Estos dos puntos son los relacionados a la ubicación de un logo (imagen) y un template (tema) o tema para la página Web Selección de Tema (Template) Respecto al template (tema), es necesario hacer referencia a la opción Página del segundo bloque (Administración) de la figura Figura (Opciones de administración de Liferay Portal), mediante la cual se puede realizar la incorporación de templates (temas o plantillas) propios de liferay. Es factible sin embargo, crear un tema personalizado, aunque ese punto podrá ser revisado en la documentación de liferay (link de comunidad de liferay).

60 60 Como se puede apreciar en la figura 2.19 (Administración de página web), es factible realizar diferentes adecuaciones a cada página o a un conjunto de páginas. La opción a la que estamos haciendo referencia en la Figura 2.19, es la correspondiente a Look and Feel o Apariencia, la cual permite (como se muestra en la figura Selección de Tema ) realizar la selección del tema (Theme en inglés) que por defecto trae Liferay. Es posible así mismo, agregar otros temas que están a la disposición de la comunidad, a través de la importación de los mismos. Figura Administración de Página Web Figura Selección de Tema

61 Inserción de un Logo en el sitio Web. La inserción de un logo 12 en la página web, va de la mano con respecto a la apariencia de la página, ya que dependiendo del diseño de la página (ya sea personalizado o importado desde liferay), será la ubicación de un logo personalizado dentro de la página web. Tomando en cuenta esto, entonces, para poder ingresar un logo, se puede hacerlo mediante la opción Configuración del segundo bloque de la Figura 2.13 (Opciones de administración de Liferay Portal), donde se puede ingresar un logo mediante la importación de un archivo gráfico (jpg, gif, png, etc.), tal como lo muestra la figura (Agregación de un logo). Figura Agregación de un logo Tomando en cuenta todos los temas expuestos anteriormente, referentes a la creación de una página, por lo tanto, se podrá ya dar un bosquejo general de lo que será el sitio web para el Centro Infantil. Es necesario entonces, retomar la estructura del portal (Ver Figura 2.2. Estructura del portal), para poder crear el sitio con las páginas correspondientes, y adicionalmente tomar en cuenta el diseño de cada una de las páginas establecido en las figuras (2.3. a 2.9. ). Por lo tanto la página diseñada quedaría como lo muestra la figura 2.22 (Figura Sitio Web creado para el CI). 12 Logo.- Contracción de Logotipo. Elemento gráfico que identifica a una persona, empresa, institución o producto.

62 62 Figura Sitio Web creado para el CI Creación de usuarios en liferay Debido a que el tema central es el monitoreo de los niños del centro infantil, por lo tanto es imprescindible un buen manejo de usuarios por parte de la herramienta correspondiente, que en este caso es Liferay. Como se había mencionado en la justificación del uso de este portal de portales, uno de los puntos importantes es el manejo de usuarios, de tal manera que la autenticación sea segura.

63 63 Para la creación de usuarios, por lo tanto, es necesario empezar con la opción correspondiente para el ingreso de usuarios, la cual es Panel de Control (Control Panel), que se muestra en el segundo bloque (Administración) de la figura (Opciones de Liferay). En la figura 2.23 (Opciones del Panel de Control de Liferay), se muestra cada una de las opciones para la administración del Portal. Lo que interesa de estas opciones es la correspondiente a Usuarios (Users). Figura Opciones del Panel de Control de Liferay El ingreso de usuarios no tiene ninguna complicación en Liferay, tal como lo muestra la figura (Pantalla de manejo de usuarios), de tal manera que únicamente se deberá tener en cuenta los nombres de usuarios y sus correspondientes claves de acceso.

64 64 Figura Pantalla de manejo de usuarios Como se puede observar en la figura anterior, la administración de usuarios parte de un listado de usuarios que pueden accesar a los recursos del portal. Cada uno de los usuarios puede ser así mismo modificado, eliminado, etc., de tal manera que ese manejo queda a discreción del administrador del portal o dueño del portal. En la figura 2.25 (Ingreso de usuarios), se puede observar los campos necesarios para el ingreso de datos de los usuarios. Figura Ingreso de usuarios

65 65 Una vez que se han ingresado los diferentes usuarios al sistema, éstos pueden ser agrupados para un mejor control de sus accesos y de qué lugares del sitio pueden accesar Creación de grupos de usuarios en liferay La creación de grupos, al igual que de los usuarios es bastante sencilla en Liferay, tal como lo ilustra la figura 2.26 (Creación de grupos de usuarios). Es necesario hacer énfasis, en que tanto la creación de usuarios, roles, grupos, etc., se basa en el esquema de organización de recursos que Liferay maneja, tal como se lo puede observar en la figura A3.2 (Gráfico Organización de Recursos de Liferay) del Anexo 3. Figura Creación de grupos de usuarios Una vez que el grupo ha sido creado, se puede posteriormente realizar varias acciones como la asignación de permisos, usuarios y páginas. Es en este lugar donde se pueden poner las restricciones de acceso a los diferentes usuarios que se creen. En las figura (Opciones de administración de grupos) y 2.28 (Permisos por grupo), se pueden observar las diferentes acciones que el administrador del portal puede realizar con el grupo creado.

66 66 Figura Opciones de administración de grupos En la siguiente pantalla, se puede distinguir la asignación de permisos a un grupo creado. En este caso y para el presente tema de tesis, se tendrá 2 grupos de usuarios para el monitoreo y administración de imágenes a través de cámaras Web: Administradores y Padres de Familia. Figura Permisos por grupo

67 Creación de roles para asignación a grupos de usuarios en Liferay Los roles en Liferay, sirven para delimitar la acción de un grupo de usuarios o también de usuarios individuales. Como en este caso ya se ha fijado que los grupos de usuarios serán dos (Administrador y Padres de Familia), por lo tanto, se delimitará el acceso de acuerdo al siguiente criterio: 1. Administrador: persona encargada de la gestión del portal, y quien manejará el ingreso, modificación o eliminación de los datos de la o las cámaras IP que estarán instaladas en el Centro Infantil. 2. Padre de Familia: quien podrá únicamente observar las imágenes transmitidas desde la cámara seleccionada, de acuerdo al listado de cámaras que pueda ingresar el administrador del portal. Con estas puntualizaciones, en las figuras 2.29 (Ingreso de Roles) y 2.30 (Asignación de permisos al rol), se puede observar la simplicidad de creación de roles, para su posterior utilización en la asignación de permisos a cada grupo de usuarios creados. Figura Ingreso de Roles

68 68 Figura Asignación de permisos al rol Instalación de Cámara IP con conexión a Router inalámbrico Dlink DIR-600. Una de las partes principales y motivo del presente tema de tesis, es la interacción con las imágenes emitidas desde una cámara Ip a través del internet, todo esto mediante la incorporación de ese video en vivo en el portal o sitio del centro infantil. Ya se ha visto en los puntos anteriores, cómo se pueden crear páginas, agregar portlets o aplicativos a cada una de las páginas, así mismo la asignación de permisos mediante roles para la visualización de cierta información a los diferentes usuarios y grupos creados para el efecto. En este punto se indicará la forma de instalación de la cámara IP Dlink DCS-2102 seleccionada, y se hará referencia a la forma de interacción con el router inalámbrico DLink DIR-600, como paso previo al desarrollo en sí del aplicativo que nos permitirá interactuar entre la cámara IP y el sitio o portal del Centro Infantil. A continuación se puntualizan cada uno de los pasos para dicha instalación:

69 69 1. La cámara IP Dlink, deberá ser conectada físicamente a un puerto del router (en este caso el router DIR-600). Este dispositivo será el puente entre la conexión a internet de un proveedor de internet (ISP 13 ). 2. Una vez conectada la cámara, se deberá dar una dirección IP fija con su respectivo puerto de acceso. Esto permitirá dar seguridad a la conexión y emisión del video vía internet. Para este caso, se ha definido el puerto 800 para la cámara. 3. Respecto a la autenticación del usuario administrador de la cámara, se la puede realizar a través del software que viene con la misma cámara. Debido a que la restricción de acceso se dará mediante Liferay, no es necesario dicha autenticación a nivel de cámara. 4. Una vez que se han parametrizado las direcciones ip, puertos y conexiones, tanto de router como de cámara, es necesario publicar en un dominio de direcciones IP dinámico. Para esto, se ha utilizado el sitio de direcciones dinámicas gratis correspondiente a DynDns 14 (Ver figura Sitio DynDns). Este registro de nuestra dirección dinámica, permitirá a la cámara IP, emitir las imágenes sin importar qué dirección IP provea el ISP, debido a que pueden existir cambios de dichas direcciones, lo que provocaría que las imágenes no puedan ser vistas por los Padres de Familia. El registro creará un nombre de dominio para nuestra cámara. 5. Con el dominio de nuestra cámara registrado en Dyndns, se puede configurar a nivel del software del router, mediante la opción de Dynamic DNS del setup del equipo (Ver figura 2.32 Asignación de dominio para DDNS del router). 6. Finalmente se deberá configurar en el router, lo referente al port forwarding (Ver figura 2.33 Redireccionamiento de puerto para la cámara), para que la cámara pueda ser vista por el aplicativo que se desarrollará para la captura de imágenes y su posterior monitoreo en el portal. Figura Sitio DynDns 13 ISP (Internet Service Provider) por sus siglas en Ingles Sitio para registro de direcciones dinámicas públicas.

70 70 Figura Asignación de dominio para DDNS del router Figura Redireccionamiento de puerto para la cámara

71 Análisis y Desarrollo del requerimiento: Crear un aplicativo de monitoreo de niños, para el portal del Centro Infantil. Una vez que se ha realizado la parte gráfica del sitio web del Centro Infantil, en este punto se analizará el desarrollo del portlet para el monitoreo, motivo del presente tema de tesis Análisis del portlet de Monitoreo de niños. El sistema o el aplicativo debe estar en capacidad de: 1. Registrar nuevos salones de monitoreo, para el centro infantil. 2. Eliminar salones del centro infantil. 3. Editar los salones del centro infantil. 4. Monitorear un salón seleccionado del centro infantil Modelo conceptual del portlet de Monitoreo de niños. Tomando en cuenta el análisis de lo que debe realizar el portlet, se desprende que se tiene el concepto Salón, que sobresale de todos los requerimientos. Para identificar dicho concepto y establecer una estandarización para este tema de tesis, al concepto Salón, se lo denominará WCPSalon (siglas de Web Cam Portlet Salon). De este concepto se desprende el modelo siguiente (Figura2.34 Modelo Conceptual del aplicativo): class impl WCPSalon - ipcamara: char - nombresalon: char - puertocamara: int - salonid: int - urlstreaming: char Figura Modelo Conceptual del aplicativo.

72 Diseño de la tabla de datos A partir del modelo definido para el aplicativo, se puede obtener un diseño de la tabla de datos (ver Tabla 2.3) que intervendrá para el registro de datos de salones en los cuales estará la cámara IP instalada. Nombre de Tabla: WCPSalon (Nombre derivado de Web Cam Portlet Salon) Campo Tipo Longitud Descripción salonid Integer 10 Campo de identificación único. nombresalon Varchar 75 Nombre del salón a monitorear ipcamara Varchar 15 Dirección IP de cámara Web, situada en el salón. puertocamara Integer 4 Puerto de la cámara Web. urlstreaming Varchar 75 Dirección del streaming de video Tabla 2.3. Descripción de Tabla para almacenamiento de datos de Salones Modelo de Casos de Uso. Para el desarrollo del presente tema de tesis, se identificaron los siguientes casos de uso que parten del análisis de los requerimientos descubiertos inicialmente (Ver Figura Diagrama de casos de uso): uc Casos de uso principales Límite del sistema Administrador Administrar Salones Monitorear Salones Padres de Familia Figura Diagrama de casos de uso

73 73 Como se puede observar en la Figura 2.35 (Diagrama de casos de uso), se han identificado dos actores (Administrador y Padre de Familia), que son quienes interactuarán con el sistema. El actor Administrador, es quien se encargará de la gestión de los datos de Salones, es decir incluye todas las tareas de: Ingreso, Modificación y Eliminación de los datos correspondientes a Salones y los respectivos datos de la cámara instalada. Por su parte, el actor Padre de Familia, es quien realizará el monitoreo vía cámara IP al salón, previo a una autenticación en el portal (una vez ingresados los datos del salón a monitorear) y a la selección del Salón que desea observar Detalle de casos de Uso identificados Con la finalidad de obtener un detalle más preciso del modelo a implementar, a continuación se desglosan los casos de uso identificados, así: Código Caso de Uso Nombre del Caso de Uso Actor involucrado CS0100 Administrar Salón Administrador CS0200 Monitorear Salón Padre de Familia Tabla 2.4. Listado de casos de uso identificados Desglose de los Casos de Uso encontrados Código CU: Nombre: Actores: CS0100 Administrar Salón Administrador

74 74 Descripción: Precondición: Postcondición: Flujo Normal de Eventos Flujo alterno de eventos: No se ingresaron datos para los campos del Salón Flujo alterno de eventos: Se desea eliminar un salón Flujo alterno de eventos: Se desea editar un salón Permite realizar el ingreso, modificación o eliminación de salones a visualizar en el monitoreo de cámaras instaladas. Autenticarse con código de usuario y contraseña válidos en el Portal. Los datos almacenados mostrarán la imagen de la cámara IP en el Portlet de Web Cam a visualizar. 1. El administrador selecciona la página de Administración de salones. 1. El sistema crea un nuevo salón y muestra la pantalla de ingreso de salones. 2. El administrador ingresa la información del salón y presiona el botón de grabar de la pantalla de ingreso de salones 3. El sistema valida que se han ingresado todos los campos del salón y guarda el salón. 5. El caso de uso finaliza 1. El sistema muestra el mensaje La información del salón está incompleta y el caso de uso continúa en el paso 3 2. El administrador presiona el botón acciones de fila de lista de salones, del portlet o pantalla de administración de salones. 3. El administrador selecciona la opción eliminar salón, de la lista de salones, en el portlet de administración de salones. 4. El sistema solicita la confirmación de la acción Borrar salón. 5. El administrador presiona el botón de Ok para confirmar el borrado. 3. El sistema elimina el salón del listado de salones y muestra un mensaje de acción realizada satisfactoriamente y el caso de uso finaliza El administrador presiona el botón acciones de fila de lista de salones, del portlet o pantalla de administración de salones. 2. El sistema despliega las opciones del menú disponibles 3. El administrador selecciona la opción Editar. 2. El sistema muestra los datos del salón seleccionado en la sección Salón de la pantalla Administrar Salones 6. El caso de uso continúa en el paso 3 del curso básico. Tabla 2.5. Caso de uso Agregar Salon El diagrama de la Figura (Diagrama representativo del caso de uso Administrar Salon ), muestra la representación gráfica del flujo de eventos del caso de uso Administrar Salón.

75 75 Figura Diagrama representativo del caso de uso Administar Salon Código CU: Nombre: Actores: Descripción: Precondición: Postcondición: Flujo Normal de Eventos CS0200 Monitorear Salón Padres de Familia Permite realizar el monitoreo de imágenes de salones donde se encuentra una cámara ip instalada. Autenticarse con código de usuario y contraseña válidos en el Portal. Ninguna 1. El Padre de familia ingresa a la pantalla web Monitoreo Web Cam del portal del CI. 2. El sistema muestra el portlet de Visualizar imágenes de Cámara. 3. El Padre de familia, selecciona el salón a monitorear imágenes. 4. El sistema realiza la conexión con los datos de la cámara asociada al salón y muestra las imágenes que están emitiendo ese momento. 5. El padre de familia sale de la pantalla web Monitoreo Web Cam del portal del CI. Flujo alterno de 3. En caso de que el sistema no pueda conectarse con la cámara asociada al salón,

76 76 eventos el sistema presentará un mensaje de No se puede obtener imagen. Tabla 2.8. Caso de uso Monitorear Salon El diagrama de la Figura (Diagrama representativo del caso de uso Monitorear Salon ), muestra la representación gráfica del flujo de eventos del caso de uso Agregar Salón. Salón: de 2 Salón patio posterior V No se puede obtener imagen Salón: Seleccionar Salón V Salón: de 2 Menores de 2 años V Fecha Emisión: Hora Emisión: EMISION DE IMAGEN Figura Diagrama representativo del caso de uso Monitorear Salon Diagramas de Clases

77 77 Una vez definidos los casos de uso que intervienen en el proceso del desarrollo del portlet de visualización de imágenes y su derivado de administración de salones, se tiene los siguientes diagramas de clases que conforman el diseño. Cabe indicar que debido a que el desarrollo se lo hará utilizando la infaestructura de liferay, la implementación del código correspondiente está ligada a lo que el entorno liferay tiene especificado por defecto. La definición de clases con la implementación adicional que efectúa Liferay, quedaría de la siguiente manera (para fines de estandarización, se ha definido la implementación de métodos en idioma Inglés), ver Figura 2.38 (Definición de clases para el modelo): class Modelo de clases «interface» WCPSalon WCPSalonImpl + WCPSalonImpl() WCPSalonModelImpl BaseModelImpl - _companyid: long - _expandobridge: ExpandoBridge - _groupid: long BaseModelImpl -_wcpsalon - _ipcamara: String - _nombresalon: String - _puertocamara: long WCPSalonClp - _companyid: long - _salonid: long - _urlstreaming: String - _groupid: long - _ipcamara: String - _nombresalon: String - _puertocamara: long - _salonid: long - _urlstreaming: String + clone() : Object + compareto(wcpsalon) : int + equals(object) : boolean + getcompanyid() : long + getexpandobridge() : ExpandoBridge + getgroupid() : long + clone() : Object + compareto(wcpsalon) : int + equals(object) : boolean + getcompanyid() : long + getgroupid() : long + getipcamara() : String + getnombresalon() : String + getprimarykey() : long + getprimarykeyobj() : Serializable + getpuertocamara() : long + getsalonid() : long + geturlstreaming() : String + hashcode() : int + setcompanyid(long) : void + setgroupid(long) : void + setipcamara(string) : void + setnombresalon(string) : void + setprimarykey(long) : void + setpuertocamara(long) : void + setsalonid(long) : void + seturlstreaming(string) : void + toescapedmodel() : WCPSalon + tostring() : String + toxmlstring() : String + WCPSalonClp() BaseModel «interface» WCPSalonModel + clone() : Object + compareto(wcpsalon) : int + getcompanyid() : long + getexpandobridge() : ExpandoBridge + getgroupid() : long + getipcamara() : String + getnombresalon() : String + getprimarykey() : long + getprimarykeyobj() : Serializable + getpuertocamara() : long + getsalonid() : long + geturlstreaming() : String + hashcode() : int + iscachedmodel() : boolean + isescapedmodel() : boolean + getipcamara() : String + getnombresalon() : String + getprimarykey() : long + getprimarykeyobj() : Serializable + getpuertocamara() : long + getsalonid() : long + geturlstreaming() : String + hashcode() : int + setcompanyid(long) : void + setexpandobridgeattributes(servicecontext) : void + setgroupid(long) : void + setipcamara(string) : void + setnombresalon(string) : void + setprimarykey(long) : void + setpuertocamara(long) : void + setsalonid(long) : void + seturlstreaming(string) : void + toescapedmodel() : WCPSalon + tostring() : String + toxmlstring() : String + WCPSalonModelImpl() + isnew() : boolean + setcachedmodel(boolean) : void + setcompanyid(long) : void + setescapedmodel(boolean) : void WCPSalonWrapper + setexpandobridgeattributes(servicecontext) : void - _wcpsalon: WCPSalon + setgroupid(long) : void + setipcamara(string) : void + clone() : java.lang.object + compareto(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon) : int + getcompanyid() : long + getexpandobridge() : com.liferay.portlet.expando.model.expandobridge + getgroupid() : long + getipcamara() : java.lang.string + getnombresalon() : java.lang.string + getprimarykey() : long + getprimarykeyobj() : java.io.serializable + setnew(boolean) : void + setnombresalon(string) : void + setprimarykey(long) : void + setpuertocamara(long) : void + setsalonid(long) : void + seturlstreaming(string) : void + toescapedmodel() : WCPSalon + tostring() : String + toxmlstring() : String + getpuertocamara() : long + getsalonid() : long + geturlstreaming() : java.lang.string + getwrappedwcpsalon() : WCPSalon + hashcode() : int + iscachedmodel() : boolean + isescapedmodel() : boolean + isnew() : boolean + setcachedmodel(boolean) : void + setcompanyid(long) : void + setescapedmodel(boolean) : void + setexpandobridgeattributes(com.liferay.portal.service.servicecontext) : void + setgroupid(long) : void + setipcamara(java.lang.string) : void + setnew(boolean) : void + setnombresalon(java.lang.string) : void + setprimarykey(long) : void + setpuertocamara(long) : void + setsalonid(long) : void + seturlstreaming(java.lang.string) : void + toescapedmodel() : com.centroinfantilpopeyes.webcamportlet.model.wcpsalon + tostring() : java.lang.string + toxmlstring() : java.lang.string + WCPSalonWrapper(WCPSalon) Figura Definición de clases para el Modelo

78 78 Debido a que Liferay genera sus propias clases para la creación de portlets, las implementaciones de los métodos que contienen la lógica para realizar las tareas correspondientes deben realizarse en uno de los archivos generado, que se especifican de acuerdo a la generación del Service Builder de Liferay. A continuación se muestra la forma cómo se realizará la implementación de clases basado en el framework manejado por liferay (Ver Figura Definición de clases para la implementación personalizada): class impl Generación de Service Builder de Liferay «interface» serv ice::wcpsalonlocalserv ice #wcpsalonlocalservice base::wcpsalonlocalservicebaseimpl Implementación personalizada WCPSalonLocalServ iceimpl + addsalon(wcpsalon, long) : WCPSalon + deletesalon(long) : void + deletesalon(wcpsalon, long) : void + getsalones(long) : List<WCPSalon> Figura Definición de clases para la implementación personalizada Liferay a través de su generador ServiceBuilder para portlets y en base a la definición de la tabla de datos (Ver Tabla 2.3. Descripción de Tabla para almacenamiento de datos de Salones), generará sus respectivas interfaces y clases propias, por lo que es necesario realizar la construcción clases y métodos personalizados, para la administración de los datos del portlet a construir. Como se observa en la Figura (Definición de clases para la implementación personalizada), la implementación de métodos se la realizará en la clase WCPSalonLocalServiceImpl (que deberá autogenerar Service Builder de Liferay), que a su vez extiende la clase WCPSalonLocalServiceBaseImpl, para esta última implementar la interfaz WCPSalonLocalService.

79 79 A continuación se muestra la definición de clases que se obtendrán con la generación del Service Builder de Liferay (Figura Clases que implementará Service Builder de Liferay), donde se muestra la clase WCPSalonLocalServiceImpl con sus respectivos métodos a personalizar, además de las extensiones e implementaciones a las clases mostradas en la Figura (Definición de clases para la implementación personalizada): class service impl::wcpsalonlocalserv iceimpl + addsalon(wcpsalon, long) : WCPSalon + deletesalon(long) : void + deletesalon(wcpsalon, long) : void + getsalones(long) : List<WCPSalon> «interface» WCPSalonLocalServ ice + addsalon(com.centroinfantilpopeyes.webcamportlet.mo... + addwcpsalon(com.centroinfantilpopeyes.webcamportlet... + createwcpsalon(long) : com.centroinfantilpopeyes.webc... + deletesalon(long) : void #wcpsalonlocalservice + deletesalon(com.centroinfantilpopeyes.webcamportlet... + deletewcpsalon(long) : void + deletewcpsalon(com.centroinfantilpopeyes.webcamport... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynami... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynami... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynami... + dynamicquerycount(com.liferay.portal.kernel.dao.orm.dy... -_service + getsalones(long) : java.util.list<com.centroinfantilpopey... + getwcpsalon(long) : com.centroinfantilpopeyes.webcam... + getwcpsalons(int, int) : java.util.list<com.centroinfantil... + getwcpsalonscount() : int + updatewcpsalon(com.centroinfantilpopeyes.webcampor... + updatewcpsalon(com.centroinfantilpopeyes.webcampor... -_wcpsalonlocalservice base::wcpsalonlocalservicebaseimpl + addwcpsalon(wcpsalon) : WCPSalon + createwcpsalon(long) : WCPSalon + deletewcpsalon(long) : void + deletewcpsalon(wcpsalon) : void + dynamicquery(dynamicquery) : List + dynamicquery(dynamicquery, int, int) : List + dynamicquery(dynamicquery, int, int, Ord... + dynamicquerycount(dynamicquery) : long + getcounterlocalservice() : CounterLocalS... + getresourcelocalservice() : ResourceLoca... + getresourcepersistence() : ResourcePersist... + getresourceservice() : ResourceService + getuserlocalservice() : UserLocalService + getuserpersistence() : UserPersistence + getuserservice() : UserService + getwcpsalon(long) : WCPSalon + getwcpsalonlocalservice() : WCPSalonL... + getwcpsalonpersistence() : WCPSalonPer... + getwcpsalons(int, int) : List<WCPSalon> + getwcpsalonscount() : int # runsql(string) : void + setcounterlocalservice(counterlocalservi... + setresourcelocalservice(resourcelocalse... + setresourcepersistence(resourcepersistenc... + setresourceservice(resourceservice) : void + setuserlocalservice(userlocalservice) : void + setuserpersistence(userpersistence) : void + setuserservice(userservice) : void + setwcpsalonlocalservice(wcpsalonloca... + setwcpsalonpersistence(wcpsalonpersist... + updatewcpsalon(wcpsalon) : WCPSalon + updatewcpsalon(wcpsalon, boolean) :... WCPSalonLocalServ iceutil WCPSalonLocalServ icewrapper + addsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon, long) : com.ce... + addwcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon) : com.cent... + createwcpsalon(long) : com.centroinfantilpopeyes.webcamportlet.model.wcpsalon + deletesalon(long) : void + deletesalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon, long) : void + deletewcpsalon(long) : void + deletewcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon) : void + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamicquery) : java.util.list + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamicquery, int, int) : java.util.list + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamicquery, int, int, com.liferay.port... + dynamicquerycount(com.liferay.portal.kernel.dao.orm.dynamicquery) : long + getsalones(long) : java.util.list<com.centroinfantilpopeyes.webcamportlet.model.wcp... + getwcpsalon(long) : com.centroinfantilpopeyes.webcamportlet.model.wcpsalon + getwcpsalons(int, int) : java.util.list<com.centroinfantilpopeyes.webcamportlet.model... + getwcpsalonscount() : int + getwrappedwcpsalonlocalservice() : WCPSalonLocalService + updatewcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon) : com.c... + updatewcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon, boolea... + WCPSalonLocalServiceWrapper(WCPSalonLocalService) WCPSalonLocalServ iceclp + addsalon(com.centroinfantilpopeyes.webcamportlet.mod... + addwcpsalon(com.centroinfantilpopeyes.webcamportlet... + createwcpsalon(long) : com.centroinfantilpopeyes.webc... + deletesalon(long) : void + deletesalon(com.centroinfantilpopeyes.webcamportlet.m... + deletewcpsalon(long) : void + deletewcpsalon(com.centroinfantilpopeyes.webcamportl... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamic... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamic... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamic... + dynamicquerycount(com.liferay.portal.kernel.dao.orm.dy... + getclassloaderproxy() : ClassLoaderProxy + getsalones(long) : java.util.list<com.centroinfantilpopey... + getwcpsalon(long) : com.centroinfantilpopeyes.webcam... + getwcpsalons(int, int) : java.util.list<com.centroinfantilp... + getwcpsalonscount() : int + updatewcpsalon(com.centroinfantilpopeyes.webcamport... + updatewcpsalon(com.centroinfantilpopeyes.webcamport... + WCPSalonLocalServiceClp(ClassLoaderProxy) + addsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalon, l... + addwcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsa... + clearservice() : void + createwcpsalon(long) : com.centroinfantilpopeyes.webcamportlet.mod... + deletesalon(long) : void + deletesalon(com.centroinfantilpopeyes.webcamportlet.model.wcpsalo... + deletewcpsalon(long) : void + deletewcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wcp... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamicquery) : java.ut... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamicquery, int, int) :... + dynamicquery(com.liferay.portal.kernel.dao.orm.dynamicquery, int, int,... + dynamicquerycount(com.liferay.portal.kernel.dao.orm.dynamicquery) : l... + getsalones(long) : java.util.list<com.centroinfantilpopeyes.webcamportl... + getservice() : WCPSalonLocalService + getwcpsalon(long) : com.centroinfantilpopeyes.webcamportlet.model... + getwcpsalons(int, int) : java.util.list<com.centroinfantilpopeyes.webca... + getwcpsalonscount() : int + setservice(wcpsalonlocalservice) : void + updatewcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wc... + updatewcpsalon(com.centroinfantilpopeyes.webcamportlet.model.wc... Figura Clases que implementará Service Builder de Liferay Configuración de Eclipse para la iteracción con Liferay

80 80 Para el desarrollo, se hará uso de Eclipse como framework de desarrollo, tomando en cuenta que para ello es necesario utilizar la lógica que maneja Liferay. Por lo tanto se deberá utilizar el plug-in de Liferay para Eclipse (versión Helios), con la finalidad de proceder con el desarrollo del portlet propuesto Carga y configuración de Plug-in de Liferay para eclipse. Liferay como portal, ha creado un plug-in para Eclipse, mediante el cual es posible la creación de portlets, temas, hooks, etc. La versión disponible al momento del plug-in, es el que viene con Tomcat como servidor de aplicaciones y para la versión Helios de Eclipse. Dicho plug-in se lo puede descargar de la página principal del fabricante ( sección comunidad). Una vez que ha sido descargado, deberá abrirse el framework Eclipse, para realizar las adecuaciones y configuraciones que se detallan a continuación: 1. Para instalar, se debe abrir una instancia de Eclipse Helios e ir a Help Eclipse Marketplace y buscar por la palabra clave "Liferay". Figura Instalación de Plug-in 2. Para la carga del Plug-In, se debe seleccionar la opción (Window / Preferences) y se deberá filtrar por la palabra Liferay, como lo que muestra la siguiente pantalla (Figura 2.42):

81 81 Figura Carga de Plug-in 3. Tomando en cuenta que ya se realizó el download del plug-in, se lo deberá cargar a la configuración pulsando en Add. (Ver. Figura 2.43): Figura Carga manual de Plug-in 4. Una vez cargado el plug-in, se deberá configurar el servidor de aplicaciones para poder ejecutar y depurar los proyectos de Liferay. Para esto se debe seleccionar la opción (Window / Preferences), luego escoger (Server / Runtime Environment), pulsar Add y se deberá seleccionar ( Liferay, Inc. / Liferay v6.0 (Tomcat 6.0)), tal como se muestra en la figura 2.44.

82 82 Figura Configuración de Servidor de aplicaciones para LiferayPlug-in 5. Finalmente, se deberá registrar el servidor en Eclipse, por lo que se debe abrir la ventana Servers (Window / Show View / Other / Server / Servers). Con el botón derecho dentro de esa ventana se selecciona (New / Server ), que muestra la pantalla donde se deberá escoger el tipo de servidor a agregar (en este caso será el de Liferay), se dará un nombre del host (localhost), nombre a la instancia de servidor (Liferay + Tomcat 6.0) y por último se seleccionará la instancia del servidor que se ha creado en el apartado anterior. (ver figura Registro del servidor Liferay en Eclipse) Figura Registro del Servidor Liferay en Eclipse Para comprobar el correcto funcionamiento de la instalación del plug-in, se deberá en Eclipse seleccionar la ejecución del servidor Liferay instalado, comprobando la conexión a la dirección de un navegador cualquiera.

83 Creación del proyecto CamaraIPPortlet tipo Portlet en eclipse. Luego de la instalación del plug-in de liferay en eclipse, y una vez que se ha probado el correcto funcionamiento del mismo, se puede empezar a crear diversos tipos de aplicaciones, las que pueden ser desde portlets hasta hooks y temas. En este apartado se verá la forma de cómo crear un aplicativo tipo portlet, utilizando las herramientas descritas. A continuación se detallan cada uno de los pasos para la creación de un portlet: 1. En el ambiente del framework (Eclipse), seleccionar la opción (File / New / Project / Liferay / Liferay Plug-in Project) y presionar Next. A continuación se deberá poner un nombre del proyecto y un nombre que se utilizará para mostrarse. En la sección Configuration tenemos que seleccionar el SDK que vamos a utilizar y la instancia de Liferay donde lo vamos a ejecutar (Ver Figura 2.46 y Figura 2.47). De igual manera, se deberá seleccionar el tipo de aplicación que el plugin deberá crear (portlet, hook, ext, layout y theme). Figura Creación de un nuevo Proyecto

84 84 Figura Creación de un nuevo Portlet 2. Una vez que se ha creado el proyecto, se podrá crear el aplicativo, lo cual se verá en el siguiente apartado. En la figura 2.48, se puede observar cómo queda la estructura general de la creación de un portlet, mediante el plug-in instalado en eclipse. Figura Estructura de un proyecto Portlet mediante Plug-in Liferay en Eclipse Investigación para la generación de portlets utilizando la infraestructura de Liferay.

85 85 Además de la creación del proyecto del portlet, Liferay tiene un framework específico para la creación de portlets que trabaja de la mano con Eclipse. Por lo tanto a continuación se hará una breve revisión de la forma de cómo opera dicho framework, y cómo ayuda la creación de portlets para ser desplegados en el entorno de liferay. 1.- Entorno de trabajo para desarrollo de liferay Liferay posee una potente herramienta de desarrollo de diferentes tipos de aplicativos (portlets, hooks, etc.), que se denomina SERVICE BUILDER. Esta herramienta hace que el desarrollador ahorre tiempo, en la creación de aplicaciones, mediante la creación en un solo paso de: Configuración de Hibernate 15 con la cual trabaja para la persistencia de datos, Configuración de Spring 16 para la Inyección de instancias, Creación de métodos de búsqueda Capa de Modelo Creación de clases con sentencias SQL de todas las tablas que se requieren en el proyecto Creación completa de la capa DAO 17 (Data Access Object) Así mismo, esta herramienta realiza la generación de código, permitiendo de esta manera manipular fácilmente las tablas mediante operaciones de administración de datos (Inserciones, Actualizaciones, Borrado), incluso la persistencia interna que tiene Liferay, es generada mediante Service Builder. En la figura 2.49, se puede observar gráficamente la interacción de esta herramienta con las tecnologías indicadas. CÓDIGO DE PORTLET SERVICE BUILDER SPRING HIBERNATE 15 Hibernate.- Herramienta de mapeo Objeto Relacional (ORM) para la plataforma Java 16 Spring.- Alternativa y sustituto del modelo de Enterprise JavaBean 17 DAO.- Data Access Object. Objeto que provee una interfaz abstracta para algún tipo de base de datos o mecanismo de persistencia BDD

86 86 Figura Operación de herramienta de creación de Liferay Para la generación de código mediante la utilización del Service Builder de Liferay, es necesaria la creación de un archivo XML, donde conste la información correspondiente de las tablas que se crearán en el proyecto. Este archivo xml se denominará service.xml, y deberá ser creado en la raíz del directorio /docroot/web-inf/, del proyecto del portlet creado en Eclipse, y que se mencionó en el apartado anterior Creación del proyecto CamaraIPPortlet. La generación del código a partir del archivo mencionado, simplemente se la realiza utilizando la construcción vía ANT 18 que dispone Eclipse. Una vez que el Service Builder genera el código, crea dos capas (layers) de código: la capa de Interfase (interface layer), y la capa de Implementación (implementation layer). En la capa de Interfase, estará todo el código que el Service Builder genere automáticamente, por lo que el desarrollador no deberá utilizar el código allí creado. Con lo que el programador podrá interactuar y personalizar código, será en la capa de implementación, la cual se crea así mismo vía Service Builder, pero únicamente contiene un esqueleto de codificación, lo que permite al desarrollador implementar cualquier personalización que requiera el proyecto Desarrollo del aplicativo utilizando la infraestructura Liferay Luego de conocer la forma de cómo opera Liferay con su framework Service Builder en la generación de código, en este apartado se realizará la generación del portlet a partir de la tabla definida para el aplicativo de monitoreo de niños así como la personalización de clases necesarias para lograr el objetivo planteado. 18 ANT.- Software para automatización de procesos de compilación y construcción de aplicaciones. Proyecto Open Source creado por Apache Software Foundation.

87 87 Antes de iniciar con la generación del portlet como tal, es necesario considerar algunos puntos, como lo son: generación de portlet mediante Service Builder y la definición de las variables iniciales, de acuerdo a lo que Liferay necesita Generación de portlet mediante Service Builder de Liferay De acuerdo a lo indicado en el apartado anterior, el framework de Liferay, para la generación del código correspondiente a la aplicación, es necesario crear un archivo xml, el cual contendrá la información referente a la tabla de datos y los métodos finder que se deseen implementar. La definición de los datos que contendrá el archivo, se derivan de la especificación de la tabla hecha en el apartado ( Diseño de la tabla de datos), por lo tanto el archivo deberá contener la siguiente declaración (Ver Listado 2.1. Archivo service.xml): <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE service-builder PUBLIC "-//Liferay//DTD Service Builder 6.0.0//EN" " <service-builder package-path="com.centroinfantilpopeyes.webcamportlet"> 1 <author>max Morillo</author> <namespace>wcp</namespace> <entity name="wcpsalon" local-service="true" remote-service="false"> 2 <column name="salonid" type="long" primary="true" /> 3 <column name="nombresalon" type="string" /> <column name="ipcamara" type="string" /> <column name="puertocamara" type="long" /> <column name="urlstreaming" type="string" /> <column name="companyid" type="long" /> <column name="groupid" type="long" /> <order by="asc"> <order-column name="nombresalon" /> </order> <finder name="ns" return-type="collection"> 4 <finder-column name="groupid" /> <finder-column name="nombresalon" /> </finder> <finder name="ip" return-type="collection"> <finder-column name="groupid" /> <finder-column name="ipcamara" /> </finder> <finder name="groupid" return-type="collection"> <finder-column name="groupid" /> </finder>

88 88 <finder name="companyid" return-type="collection"> <finder-column name="companyid" /> </finder> </entity> </service-builder> Listado 2.1. Archivo service.xml Del listado anterior se tiene que: #1 Identifica el paquete en el cual Service Builder generará el código #2 Define la Entidad de Base de datos #3 Define la(s) columna(s) de la entidad #4 Define los métodos de búsqueda de datos Una vez que se ha definido el archivo service.xml, se podrá generar el código mediante la construcción vía ANT del mismo archivo, presionando el botón service builder, tal como lo muestra la figura 2.50 (Construcción del código). Figura Construcción del código Luego de la generación del código, la estructura del portlet queda como muestra la figura 2.51., donde adicional a la estructura que crea el plugin de liferay (indicado en la figura Estructura de un proyecto Portlet mediante Plug-in Liferay en Eclipse), se tiene todo lo generado por el Service Builder de Liferay.

89 89 Figura Generación del código mediante Service Builder Definición de entorno de variables previo al desarrollo del portlet en Liferay. Para continuar con las configuraciones previas a la generación de código mediante Service Builder de Liferay, es necesario tomar en cuenta la definición de ciertos archivos iniciales, los cuales contendrán una serie de configuraciones iniciales. A continuación se describe lo requerido: portlet.xml.- Este archivo contiene la información y configuración del portlet. Se deberá por lo tanto especificar que el portlet implementará los modos edit y view (de acuerdo al estándar JSR ), tal como lo indica la porción de código siguiente de la etiqueta <supports>: <supports> <mime-type>text/html</mime-type> <portlet-mode>view</portlet-mode> <portlet-mode>edit</portlet-mode> </supports> 19 JSR Java Specification Request. Estándar 2.0 para creación de Portlets.

90 90 También se debe especificar en la etiqueta <init-param> del mismo archivo, la definición del parámetro de inicialización, así: <init-param> <name>edit-jsp</name> <value>/edit.jsp</value> </init-param> Debido a que para el desarrollo del presente tema, se necesitarán 2 portlets (uno de administración, y otro de monitoreo de cámaras), por lo tanto quedará especificado de la siguiente manera, dentro del portlet.xml como sus respectivos parámetros (<init-param>) para cada uno de los portlets, así (ver Listado 2.2.): <?xml version="1.0"?> <portlet-app version="2.0" xmlns=" xmlns:xsi=" xsi:schemalocation=" > <portlet> <portlet-name>camaraipportlet</portlet-name> <display-name>visualizar Imagenes de Camara</display-name> <portlet-class> com.centroinfantilpopeyes.webcamportlet.registrosalon.salonadminportlet </portlet-class> <init-param> <name>view-jsp</name> <value>/view.jsp</value> </init-param> <init-param> <name>edit-jsp</name> <value>/edit.jsp</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> <portlet-mode>view</portlet-mode> <portlet-mode>edit</portlet-mode> </supports> <resource-bundle>content.language</resource-bundle> <portlet-info> <title>visualizar Imagenes de Camara</title> <short-title>camaraipportlet</short-title> <keywords>camaraipportlet</keywords> </portlet-info> <security-role-ref> <role-name>administrator</role-name> </security-role-ref> <security-role-ref> <role-name>guest</role-name> </security-role-ref> <security-role-ref> <role-name>power-user</role-name> </security-role-ref> <security-role-ref>

91 91 <role-name>user</role-name> </security-role-ref> <supported-public-render-parameter> supported-public-render-parameter </supported-public-render-parameter> </portlet> <portlet> <portlet-name>salon-admin</portlet-name> <display-name>administrar Salones</display-name> <portlet-class> com.centroinfantilpopeyes.webcamportlet.registrosalon.salonadminportlet </portlet-class> <init-param> <name>view-jsp</name> <value>/admin/view.jsp</value> </init-param> <init-param> <name>add-process-action-success-action</name> <value>false</value> </init-param> <expiration-cache>0</expiration-cache> <supports> <mime-type>text/html</mime-type> </supports> <resource-bundle>content.language</resource-bundle> <portlet-info> <title>adminsalones</title> <short-title>adminsalones</short-title> <keywords>adminsalones</keywords> </portlet-info> <security-role-ref> <role-name>administrator</role-name> </security-role-ref> <security-role-ref> <role-name>guest</role-name> </security-role-ref> <security-role-ref> <role-name>power-user</role-name> </security-role-ref> <security-role-ref> <role-name>user</role-name> </security-role-ref> </portlet> </portlet-app> Listado 2.2. Definición de variables en Portlet.xml Como se puede observar en el listado anterior, han sido creadas dos definiciones de portlets, uno con nombre CamaraIPPortlet y otro Salon-admin, cada uno de los cuales así mismo tiene el parámetro (<init-param>) con dos modos de implementación (edit, y view) con una diferencia, la cual es que en el segundo portlet dichos modos están en otra ubicación, tal como lo muestra el listado Programación de métodos para almacenamiento y recuperación de datos.

92 92 Luego de las configuraciones iniciales de los archivos vistos en los apartados anteriores, corresponde ahora programar los métodos para almacenamiento y recuperación de datos. Para ello, se debe tomar en cuenta la clase WCPSalonLocalService, la cual fue generada mediante la utilización del Service Builder de Java. En dicha clase, como se había mencionado, se harán las adecuaciones de personalización de lo que se requiere tanto para el ingreso de datos como para la recuperación de los mismos. Es así que, de acuerdo al diseño de clases visto anteriormente, se tiene que existirán 4 métodos creados para el efecto (el código completo de dicha clase se lo puede ver en el Anexo 8. Código Fuente.): 1. addsalon.- Método creado para el almacenamiento de la información de la cámara Ip por salón ingresado. 2. deletesalon.- Método que permite el borrado de información de salón. 3. getsalones.- Método para recuperación de datos de un determinado salón. Es necesario recalcar, que Liferay maneja el concepto de MVC 20 para portlets, o lo que se denomina MVCPortlet. Esto hace que Liferay otorgue una fácil forma de desarrollar al programador mediante la utilización de clases de portlet, haciendo que los enlaces (links) o cuando se utilice URLs 21, puedan manejar fácilmente métodos para realizar cualquier tarea que se desee personalizar. Para lograr este objetivo, es necesario crear los archivos correspondientes que manejen la parte frontal del aplicativo (front-end) y los métodos personalizados, entre los cuales están: Archivo Inicio (Init.jsp).- que maneja todas las importaciones (imports), declaraciones de librerías e inicializaciones de variables. Archivos Vista (View.jsp).- manejan la parte frontal de la visualización web (frontend web). Clase de manejo de Utilidades (ActionUtil).- que contiene métodos para recuperar objetos tipo Salon. Clase de manejo de datos(salonadminportlet).- que contiene los métodos para administración de datos de salones para el portlet. Clase de control de errores (SalonRegValidator).- que contiene métodos para validación de datos a ingresar en el registro de salones. 20 MVC.- Sigla de Modelo Vista Controlador. 21 URL.- Sigla en inglés de Uniform Resource Locator

93 93 Por lo tanto, adicional a la clase WCPSalonLocalService, que maneja la administración de datos, se tendrá las clases anteriormente puntualizadas (la codificación de cada uno de ellas se detalla en el Anexo 8. Código Fuente). A continuación se indicarán los métodos que cada una de las clases contiene para el manejo de información y su almacenamiento: Clase ActionUtil : getsalones.- Obtiene un objeto salones. salonfromrequest.- Obtiene un objeto salón de acuerdo a un parámetro de solicitud. Clase SalonAdminPortlet : addsalon.- Agrega un salón editsalon.- Crea un objeto salón para pasar a un parámetro, con la finalidad de poder modificar datos. updatesalon.- Actualiza los datos modificados en el objeto salón. deletesalon.- Borra un salón. viewsalon.- Método para visualización de datos. Clase SalonRegValidator : validatesalon.- Valida datos para el ingreso de salones Programación de archivos Vista (View.jsp) para presentación de imágenes de cámara y de administración de salones. Para la implementación de los archivos Vista (View) necesarios en Liferay para la interacción con el usuario, es necesario en primer lugar tomar en cuenta el API 22 de etiquetas AlloyUI que Liferay ha creado. Estas etiquetas tienen como finalidad, evitar al 22 API.- siglas en inglés Application Programming Interface. Conjunto de funciones, procedimientos/métodos que ofrece una biblioteca para el uso de otro software.

94 94 desarrollador la tarea de tener que especificar componentes HTML, CSS 23 y JavaScript por separado, permitiendo en una sola API combinar lo mejor de esas tres tecnologías. Por lo tanto en la creación de los archivos Vista, y que son los que muestran información con un formato amigable al usuario, se utilizará el API mencionada. Las etiquetas (o markups ) se diferencian del resto de etiquetas ya conocidas con la definición inicial de aui:. En el siguiente listado (ver listado 2.4) se muestra una porción de código del archivo Vista (view) con la implementación de dichas marcas: <aui:form name="fm" action="<%= addsalonurl.tostring() %> "method="post"> <aui:fieldset> <aui:input name="nombresalon" size="45" /> <aui:input name="ipcamara" size="45" /> <aui:input name="puertocamara" size="4" /> <aui:input name="urlstreaming" size="45" /> <aui:button-row> <aui:button type="submit" /> </aui:button-row> </aui:fieldset> </aui:form> Listado 2.3. Código donde se utiliza API AlloyUI de Liferay Con lo indicado previamente, se debe indicar que existen dos archivos Vista que se deben crear, uno para la visualización de las imágenes de la cámara IP, y el otro para la administración de salones donde constarán los datos de la o las cámaras que se vayan a instalar. En el listado 2.2. del apartado (Definición de entorno de variables previo al desarrollo del portlet en Liferay.), se mencionó que existirán 2 portlets en la definición del archivo portlet.xml, y se hacía referencia a que cada uno de ellos tendría sus propias variables de inicio. Pues, esas variables de inicio, indican que cada uno de los portlets tiene 23 CSS.- siglas en inglés de Cascade Style Sheets. Lenguaje para definir la presentación de un documento estructurado escrito en HTML o XML.

95 sus propios archivos Vista (view), y que serán los que muestren la parte frontal del portlet (fron-end web). Dicho esto, en el listado 2.4 se puede observar la implementación del archivo view para la administración de salones, donde se muestra la utilización del archivo init.jsp como recipiente de las librerías a utilizar por las vistas, y adicionalmente la utilización de etiquetas AlloyUI y la interacción con los métodos implementados en las clases señaladas en el apartado anterior, así: 95

96 96 <% /** * Copyright (c) Liferay, Inc. All rights reserved. * * This library is free software; you can redistribute it and/or modify it under * the terms of the GNU Lesser General Public License as published by the Free * Software Foundation; either version 2.1 of the License, or (at your option) * any later version. * * This library is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS * FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more * details. */ %> <%@include file="/init.jsp" %> <liferay-ui:success key="salonsaved" message="salon-saved-successfully" /> <liferay-ui:success key="salondeleted" message="salondeleted" /> <liferay-ui:success key="salonupdated" message="salonupdated" /> <liferay-ui:error key="fields-required" message="fields-required" /> <liferay-ui:error key="error-deleting" message="error-deleting" /> <liferay-ui:error key="error-updating" message="error-updating" /> <portlet:actionurl name="addsalon" var="addsalonurl"/> <aui:form name="fm" action="<%= addsalonurl.tostring() %>" method="post"> <aui:fieldset> <aui:input name="nombresalon" size="45" /> <aui:input name="ipcamara" size="45" /> <aui:input name="puertocamara" size="4" /> <aui:input name="urlstreaming" size="45" /> <aui:button-row> <aui:button type="submit" /> </aui:button-row> </aui:fieldset> </aui:form> <liferay-ui:search-container emptyresultsmessage="there-are-no-salons" delta="5"> <liferay-ui:search-container-results> <% List<WCPSalon> tempresults = ActionUtil.getSalones(renderRequest); results = ListUtil.subList(tempResults, searchcontainer.getstart(), searchcontainer.getend()); total = tempresults.size(); pagecontext.setattribute("results", results); pagecontext.setattribute("total", total); %> </liferay-ui:search-container-results> Listado 2.4. Implementación del archivo view.jsp para la administración de salones

97 97 El archivo view.jsp anterior, es el que manejará la parte administrativa de los salones, y deberá estar ubicado en la ruta /docroot/admin/view.jsp, tal como lo indica la parametrización del archivo portal.xml, con la finalidad de poder distribuir mejor la implementación Programación de permisos para los portlets creados. Una vez que se tenga lista la implementación de la visualización de los portlets, corresponde ahora implementar la forma en la que cada portlet se pueda asignar los permisos de acceso correspondiente. Esto es importante, en la medida en que se puede programar la forma de controlar permisos en la misma manera que lo hace Liferay, dentro de su manejo de permisos, teniendo de esta manera, un manejo uniforme y estandarizado de realizar esta tarea. En liferay para realizar esto, se debe tomar la generación de dos archivos necesarios para este manejo: Archivo portlet.properties.- Archivo leído por Liferay automáticamente, y que contiene las indicaciones con las cuales opera el portlet. Archivo default.xml.- Indicaciones o directivas que proporcionan el listado de permisos que se otorgarán al portlet. En el archivo porltet.properties, deberá constar el archivo con las definiciones de permisos (default.xml) y la ruta donde estará localizado, así para este caso estaría en: resource.actions.configs=resource-actions/default.xml La línea anterior indica que el archivo estará ubicado en la carpeta resource-actions, por lo que se deberá crear dicha carpeta y agregar el archivo default.xml, el cual contendrá lo mostrado en el listado 2.5., así:

98 98 <?xml version="1.0" encoding="utf-8"?> <resource-action-mapping> <portlet-resource> <portlet-name>camaraipportlet</portlet-name> <permissions> <supports> <action-key>add_salon</action-key> <action-key>view</action-key> </supports> <community-defaults> <action-key>view</action-key> </community-defaults> <guest-defaults> <action-key>view</action-key> </guest-defaults> <guest-unsupported> <action-key>add_salon</action-key> </guest-unsupported> </permissions> </portlet-resource> <model-resource> <modelname>com.centroinfantilpopeyes.webcamportlet.model.wcpsalon </model-name> <portlet-ref> <portlet-name>salon-admin</portlet-name> </portlet-ref> <permissions> <supports> <action-key>delete</action-key> <action-key>permissions</action-key> <action-key>update</action-key> <action-key>view</action-key> </supports> <community-defaults> <action-key>view</action-key> </community-defaults> <guest-defaults> <action-key>view</action-key> Listado 2.5. Definición de permisos de portlets en archivo default.xml Como se puede observar en el listado anterior, existen 2 bloques explícitamente delimitados como: portlet-resource y model-resource. El portlet-resource, hace referencia a la definición de qué usuarios pueden realizar la acción de agregar salones (add-salon), mientras que la opción vista (view), se ha fijado para los usuarios guest (invitados) y el grupo comunidad (community).

99 99 Mientras que el segundo bloque model-resource, indica qué tipo de permisos manejará Liferay para el portlet indicado. En este caso se ha puesto que podrá manejarse las opciones: DELETE, PERMISSIONS, UPDATE y VIEW Despliegue del proyecto en ambiente de desarrollo para pruebas de conexión Luego de todas las codificaciones y configuraciones necesarias para la construcción del portlet, materia del presente tema de tesis, finalmente se debe realizar el despliegue (deploy) del proyecto. Para realizar esta tarea, es necesario indicarle a Eclipse, qué proyecto o en este caso, qué portlet se desplegará. Figura Configuración en eclipse para despliegue de aplicación En la figura 2.52., se muestra la pantalla, en donde, en el servidor Liferay se debe pulsar el botón derecho del ratón, con lo que se obtiene un listado de opciones, de las cuales se deberá escoger Add and Remove (Agregar y Quitar), para poder finalmente colocar el proyecto o aplicación que se desee desplegar (Ver Figura 2.53.):

100 100 Figura Opción para agregar proyecto o aplicación a desplegar en Eclipse. Finalmente una vez que se hace la compilación y construcción (Build) con ANT, se tendrá listo el aplicativo o proyecto y listo para su prueba de funcionamiento. Con el servidor Liferay de eclipse en ejecución, y luego de que se ha ingresado a un navegador (Mozilla para este caso), se deberá ingresar localmente a la url donde liferay estará corriendo y con lo cual se mostrará la pantalla de inicio de liferay. Para poder probar los portlts implementados, se ha creado dos páginas de prueba, la una para el monitoreo de la emisión de imágenes de la cámara IP, y la otra página para pruebas de la administración de datos de salones. Tal como se lo mencionó en los apartados de creación de una página en liferay, se deberá ingresar como un usuario con privilegios de administrador, con la finalidad de poder realizar las operaciones de creación de páginas y agregación de portlets. En la figura (Despligue de Portlets creados en listado de aplicaciones de Liferay), se puede observar que en el despliegue de las aplicaciones (portlets) que dispone Liferay, ya se encuentra la categoría CI Popeyes Admin, con la cual se identificó para este proyecto. Así mismo se pueden observar las dos aplicaciones ( Visualizar Imágenes de Camara y Administrar Salones ), lo cual nos indica que las mismas ya pueden ser utilizadas en las páginas de pruebas creadas para el efecto.

101 101 Figura Despligue de Portlets creados en listado de aplicaciones de Liferay En la figura (Pantalla de administración de salones creado), se puede observar la administración de datos para salones, con los datos respectivos de la cámara IP, con la que se trabajará para la emisión de imágenes. Como se puede notar, cada uno de los registros ingresados, tienen las mismas características que cualquier otro aplicativo (portlet) de liferay. Figura Pantalla de administración de salones creado

102 102 En la figura 2.56.( Edición de datos del portlet creado), se puede observar la edición de campos para el ingreso de salones, de acuerdo al diseño esbozado en el desarrollo del primer requerimiento del presente tema. Así mismo se puede observar las características heredadas a Liferay para la presentación de un portlet. Figura Edición de datos del portlet creado Para el monitoreo de las imágenes de la cámara, con los datos ingresado en la administración de salones, la figura (Visualización de imágenes en portlet de monitoreo creado) muestra la emisión de imágenes del salón seleccionado. Figura Visualización de imágenes en portlet de monitoreo creado

103 Despliegue del proyecto en ambiente de producción Una vez que se ha comprobado la funcionalidad del proyecto en ambiente de desarrollo, se puede realizar el despliegue en el ambiente de producción, en el servidor contratado para el efecto (ver Anexo 5. Hosting.). Para la instalación del proyecto en el ambiente de producción es necesario ingresar al servidor contratado, vía conexión FTP 24 (en este caso se ha utilizado CoreFTP 25 ), para de esta manera poder transferir el proyecto generado en Eclipse. Al proyecto generado deberá ser colocado en el directorio del servidor /liferay../ jboss /server/default/deploy. De esta manera se desplegará el proyecto en el servidor Liferay-jboss ya configurado anteriormente. En la figura 2.58 (Portlets creados y desplegados en ambiente de producción) se puede observar que ya los portlets creados, se encuentran en el listado de aplicaciones disponibles en Liferay instalado en ambiente de producción. Figura Portlets creados y desplegados en ambiente de producción 24 FTP.- Siglas en inglés de File Transfer Protocol. Protocolo de red para transferencia de archivos. 25 CoreFTP.- Programa libre para conexión segura vía FTP para Sistema Operativo Windows.

104 Pruebas de funcionamiento de los portlets desplegados en producción Una vez que se ha comprobado el despliegue de las aplicaciones (portlets) en ambiente de producción, es necesario realizar las pruebas de funcionamiento correspondientes en dicho ambiente, por lo que a partir del diseño de pantallas, se crearán las páginas correspondientes, con sus respectivos permisos, etc. En la figura (Portlet de administración de salones en producción), se puede observar el funcionamiento del portlet para la administración de salones, donde se deberá ingresar los datos correspondientes al salón a monitorear. Figura Portlet de administración de salones en producción Es necesario indicar que para que las imágenes de la cámara IP puedan ser vistas en el portal de producción, es necesario utilizar como URL la definición hecha en la creación de una dirección dinámica (ver Figura 2.31). En la figura 2.60 (Ingreso de datos de cámara IP en producción), se puede observar la definición indicada, y con lo cual se debería tener señal de las imágenes emitidas por la cámara IP.

105 105 Figura Ingreso de datos de cámara IP en producción Finalmente, para comprobar la emisión de imágenes con la configuración vista en la figura anterior, se deberá observar el funcionamiento del portlet para monitoreo o visualización de imágenes en la página web creada para el caso (ver Figura Emisión de imágenes en ambiente de producción). Figura Emisión de imágenes en ambiente de producción

106 106 FASE 3 RESULTADOS DEL IMPACTO DE LA SOLUCIÓN EN LOS PADRES DE FAMILIA Una vez concluido el proceso de desarrollo e implantación de la solución al tema propuesto, es necesario hacer la evaluación del cómo afectó o qué incidencia tiene el mismo en los padres de familia que harán uso del portal y el correspondiente monitoreo de sus niños Utilización de credenciales de acceso a Padres de Familia y análisis de resultados En el apartado ( Creación de usuarios en liferay), se indicó el proceso de ingreso de usuarios para la utilización del portal Liferay, por lo que se han ingresado un total de diez padres de familia, con los permisos correspondientes para accesar a la página de monitoreo de niños, tal como se ha diseñado en el portal. Con la finalidad de ir recogiendo información, respecto al grado de satisfacción de padres de familia al usar el portal del CI y su correspondiente monitoreo de niños vía internet, se ha realizado una encuesta a cada uno de ellos (Ver Anexo 7. Encuestas de satisfacción de uso del monitoreo Web). Estas encuestas han sido tabuladas, por lo que los resultados de las mismas son los siguientes: 1.) Considera que el monitoreo vía internet de su hijo(a), le ha proporcionado más confianza en el CDI?: % Si ,00 No 0 - No contesta 0 - TOTAL ,00 Tabla 3.1. Nivel de confianza al CDI con Monitoreo

107 107 2.) Con el monitoreo de su hijo(a) vía cámaras web en línea, cree que su rendimiento laboral ha mejorado?: % Si ,00 No 0 - No contesta 0 - TOTAL ,00 Tabla 3.2. Rendimiento laboral de Padres vs. Monitoreo de niños 3.) Cree que el uso del monitoreo vía web de su hijo(a), interfiere o quita tiempo en su trabajo o labores diarias?: % Si 0 - No ,00 No contesta 0 - TOTAL ,00 Tabla 3.3. Incidencia de tiempo vs. Monitoreo de niños 4.) Cree Ud. que el ingreso a monitorear a su niño(a) a través del portal del Centro Infantil, es ágil y ayuda para el cuidado de su hijo? : % Si ,00 No 0 - No contesta 0 - TOTAL ,00 Tabla 3.4. Cualificación de portal por padres de familia 5.) Ha tenido inconvenientes laborales cuando ha ingresado al portal del CDI para monitorear a su hijo(a)?: % Si 1 10,00 No 9 90,00 No contesta 0 - TOTAL ,00 Tabla 3.5. Problemas de acceso a monitoreo via internet

108 108 6.) Desearía que el CDI continúe con el servicio de monitoreo vía cámaras web a su niño(a)?: % Si ,00 No 0 - No contesta 0 - TOTAL ,00 Tabla 3.6. Seguimiento de Monitoreo 7.) Estaría dispuesto(a) a pagar un valor adicional por el servicio de monitoreo por internet? % Si ,00 No 0 - No contesta 0 - TOTAL ,00 Tabla 3.7. Aceptación de cargos por monitoreo De acuerdo a los resultados tabulados anteriormente por cada pregunta realizada a cada uno de los padres de familia, en resumen se puede concluir que: El 100% de los padres de familia encuestados confirman una mejora sustancial, respecto a la confianza en el cuidado de sus hijos por parte del CDI, una vez instalada la solución. En promedio, de acuerdo a lo indicado por los padres de familia, existe un 59,5% de mejora en el rendimiento laboral de los padres. Esto debido a que se disminuyen o eliminan sensaciones como: Angustia, Preocupación, Intranquilidad, falta de control. Ningún padre de familia indica problemas de pérdida de tiempo o interferencia en las labores normales. Se observa una clara tendencia a ocupar los tiempos muertos en las labores, para el monitoreo de sus niños.

109 109 Se observa que hay desconocimiento de los padres de familia, respecto a los tiempos de respuesta del aplicativo. Únicamente ven beneficio respecto al monitoreo. La mayoría concuerda que no existe problema al utilizar el aplicativo desde sus trabajos, ya que ingresan por períodos muy cortos de tiempo. El 100% de los encuestados desearía que el CDI cuente en forma contínua con el servicio de monitoreo de sus niños vía Internet. En promedio, los padres de familia podrían destinar para el pago del monitoreo un valor de $17.5USD.

110 110 CONCLUSIONES El aplicativo para el monitoreo de niños vía Web, instalado en el Centro de Desarrollo Infantil (CDI) Popeye s, de la ciudad de Quito, cubre las expectativas de control y vigilancia que tienen los padres de familia con respecto a sus hijos que asisten a dicho centro. La solución instalada ha solventado la necesidad de control y monitoreo de niños, y ha generado una mayor tranquilidad en los padres de familia que tienen a sus niños en el Centro Infantil, incidiendo positivamente y de una manera directa, en el rendimiento laboral de los padres de familia que trabajan en sectores apartados del CDI. Debido a que el monitoreo de niños en el CDI, podría descubrir ciertas falencias en el cuidado, éste puede provocar cierto rechazo de utilización en los diferentes centros de cuidado infantil. Liferay es una poderosa herramienta para crear portales web, aunque la utilización de la versión community (comunidad), no presta las facilidades para una rápida instalación y explotación, al no existir mucha documentación disponible para tal fin. La creación de portlets, utilizando el API de Liferay, es rápida y se evidencia una gran ventaja de poder interactuar con otras herramientas OpenSource (ej. Alfresco), así como también permite trabajar con diferentes tipos de Bases de datos. El desarrollo de aplicaciones que utilicen imágenes emitidas por cámaras IP, se ve restringida por la marca de las cámaras, ya que la mayoría de fabricantes no dispone de versiones de equipos que manejen Java. El ancho de banda destinado para el uso de emisión de video por internet, es un factor determinante para disponer de una imagen clara para monitoreo remoto. La utilización de SCRUM como metodología de desarrollo ágil, facilita la elaboración de proyectos de software en los cuales se deben ir obteniendo resultados rápidos, aunque no es muy útil en proyectos unipersonales.

111 111 RECOMENDACIONES Para evitar rechazo en la utilización de sistemas de monitoreo vía cámaras IP, en los centros de desarrollo infantil, es conveniente que se realice un previo estudio previo a la instalación del aplicativo. Al utilizar tecnologías Open Source, se debe tomar en cuenta el tiempo de aprendizaje de las mismas, debido a la poca documentación, especialmente en herramientas con versiones tipo Community. Para obtener mejores resultados en la emisión de imágenes de cámaras IP vía internet, es preferible tener como mínimo 512 kbps de velocidad en los modelos de cámaras Dlink. Se recomienda utilizar metodologías ágiles de desarrollo de proyectos, tipo SCRUM, especialmente en proyectos orientados a la obtención rápida de resultados o que tengan una gran cantidad de cambios en el transcurso del desarrollo.

112 112 BIBLIOGRAFÍA Sezov, Richard Jr. Liferay in Action. Manning Publications. Falkner, James. Liferay Essentials Ref Card. LIFERAY. Sezov, Richard Jr. Inter-portlet communication using Portlet 2.0. Manning Publications. Sarin, Ashish. Portlets in Action. Manning Publications. SÁNCHEZ, María A., Metodologías De Desarrollo De Software, WIRWIN, Metodología SCRUM para la dirección de proyectos informáticos,

113 113 ANEXOS

114 114 ANEXO 1. ENCUESTAS PRELIMINARES DE ACEPTACIÓN DEL PROYECTO A PADRES DE FAMILIA. A continuación se adjuntan las encuestas realizadas a los padres de familia, previo al inicio del desarrollo del proyecto de tesis.

115 115

116 116

117 117

118 118

119 119

120 120

121 121

122 122

123 123

124 124

125 125

126 126

127 127

128 128

129 129

130 130 ANEXO 2. DESCRIPCIÓN DE LA METODOLOGÍA DE DESARROLLO SCRUM. Históricamente, SCRUM nació en 1986 con Hirotaka Takeuchi e Ikujiro Nonaka, como un proyecto para mejorar la flexibilidad y rapidez en el desarrollo de productos comerciales. Posteriormente en 1991 Peter DeGrace y Leslie Stahl, utilizaron por primera vez el término Scrum, para luego en 1995 por intermedio de Schwaber y Sutherland utilizar públicamente el término conjuntamente con las mejores prácticas de la industria. Finalmente en 2001, Schwaber y Mike Beedle describieron la metodología completa en el libro Agile Software Development with Scrum (Desarrollo Ágil de Software con SCRUM). Por lo tanto, Scrum al ser una metodología ágil de desarrollo tipo transversal, se entiende que es apropiado para equipos de trabajo o de desarrollo (como recomendación hasta máximo grupos de 8 personas). No es 100% apropiado para todo tipo de proyecto, así como no lo es ninguna otra metodología. Scrum también se lo puede catalogar como un modelo de referencia que define un conjunto de prácticas y roles, y que puede tomarse como punto de partida para definir el proceso de desarrollo que se ejecutará durante un proyecto. A2.1. Conceptos manejados en SCRUM La metodología utiliza una serie de tecnicismos para referirse a determinados artefactos, roles y actividades (desde el punto de vista de la terminología RUP Rational Unified Process ), stakeholders y demás: Product Backlog: documento en el cual se detallan, de forma priorizada, los requisitos del sistema. Sprint: cada una de las iteraciones de que se compone el desarrollo con Scrum. Si existe razón de suficiente peso, puede abortarse el sprint y comenzar uno nuevo. Sprint Backlog: trozo de backlog que nos comprometemos a implementar de forma satisfactoria en el sprint (iteración) actual. ScrumMaster: que mantiene los procesos y trabaja de forma similar al director de proyecto. ProductOwner (Dueño del producto): que representa a los stakeholders (clientes externos o internos).

131 131 Team (Grupo): que incluye a los desarrolladores. Burn down Chart.- Es una gráfica que muestra las funcionalidades pendientes del proyecto al comienzo de cada Sprint y demuestra el avance en función del tiempo para así poder manejar el proyecto. Este modelo se lo usa en lugar de un diagrama de PERT 26. Cabe señalar que en esta metodología existen dos roles peculiares, y que dan forma a Scrum, los cuales son: cerdos (pigs) y gallinas (chicken). Esta graciosa denominación de roles, está dada por un popular chiste el cual se describe a continuación: Un cerdo y una gallina se encuentran en la calle. La gallina mira al cerdo y dice: Cerdo, por qué no abrimos un restaurante? El cerdo mira a la gallina y le dice: Buena idea, cómo se llamaría el restaurante? La gallina piensa un poco y contesta: Por qué no lo llamamos Huevos con jamón? Lo siento pero no, dice el cerdo, Yo estaría comprometido pero tú solamente estarías involucrada. En Scrum, el rol de los cerdos (aquellos que están comprometidos de forma seria con el proyecto), son desempeñados por los subroles: Team, ScrumMaster y ProductOwner. El rol gallina está constituido por otros clientes y stakeholders (ejecutivos, etc.). Al final, todos los roles cerdo son gestores (managers), desde el momento en el que se dice que están comprometidos con el proyecto. A2.2. Estructuración de la metodología La metodología Scrum tiene tres fases fundamentales, así: - Fase de planificación.- Donde se realizan labores básicas de planificación que incluye: visión general del proyecto (estimación muy general, y la viabilidad del sistema) y construcción del Backlog, por un lado y por otro el desarrollo de la arquitectura al detalle. 26 PERT.- del inglés Program Evaluation and Review Technique. Modelo para administración y gestión de proyectos.

132 132 - Fase de desarrollo.- En la cual se utilizan los llamados Sprints (Sinónimo de carrera de velocidad en inglés), que es la fase más importante en términos de interés para el proyecto. - Fase Final de entrega y balance de los éxitos y fracasos logrados. Como se mencionó, la fase de Sprint es la más importante ya que las otras dos no difieren mucho de las fases de Planificación y Entrega de otras metodologías. El desarrollo en la fase Sprint es iterativo en uno o más Sprints, hasta que el proyecto se da por finalizado por el ProductOwner. La cantidad de Sprints dependerá de la necesidad del proyecto y del desarrollo en sí (Ver Figura A2.1. Proceso SCRUM) Con la revisión periódica y la generación de Sprints, se cubre el problema de la variabilidad de los requisitos, ya que al no haber una estimación prematura fiable donde los requisitos probablemente cambiarán, la metodología se ajusta a la perfección para cubrir ese inconveniente. Además de las fases que manejan la estructura de la metodología como tal, también se deben tomar en cuenta las reuniones, para la toma de decisiones. Existen cuatro tipos de reuniones que se realizan durante el desarrollo de un proyecto con Scrum, por lo que a continuación se hará una breve descripción de los mismos con sus tiempos estimados de duración, así: Reunión de Planificación (tiempo de duración, aprox. 4 horas): Al inicio de un Sprint, se decide qué parte del Backlog global del proyecto se implementará en este Sprint. Una vez decididas las funcionalidades a implementar, en base a estimaciones de tamaño, tiempo, esfuerzo, etc., el Sprint Backlog no se toca durante todo el Sprint, bajo ninguna circunstancia. En caso de que algo fallara, el ScrumMaster podrá cancelar el Sprint y empezar otro. Reunión Diaria (tiempo de duración, aprox. 15 minutos): Consiste en una rápida reunión diaria del equipo de unos 15 minutos, para responder individualmente a 3 preguntas básicas que son: o qué hiciste ayer? o qué vas a hacer hoy?

133 133 o qué te está impidiendo alcanzar tus objetivos? De esta manera se realiza el control del proyecto, así como el seguimiento de los posibles riesgos. Reunión de Revisión (tiempo de duración, aprox. 4 horas): Consiste en la reunión del final del Sprint, con el ProductOwner y otros clientes (gallinas), con la finalidad de exponer la funcionalidad desarrollada junto con las posibles preguntas y ampliaciones del Backlog, que se les pueda ocurrir a los diferentes stakeholders (clientes+ejecutivo). Con esto logramos un feedback (Retroalimentación) con el cliente, que ve cómo el producto progresa. Reunión de Retrospección (tiempo de duración, aprox. 4 horas): Es una reunión entre el ScrumMaster con el Team (Grupo), para revisar cómo se desarrolló el Sprint, es decir descubrir, qué se consiguió realizar bien y cómo se podría mejorar. En resumen, esta reunión no es más, que una revisión de lecciones aprendidas y una forma de recabar información histórica del propio proyecto (Software Estimation, Steve McConnell), útil para futuras estimaciones y Sprints. Figura A2.1. Proceso SCRUM

134 134 A2.3. Aplicación de la metodología para la implementación de la solución. Tomando en cuenta que la metodología SCRUM hace referencia a toda las actividades que el Team (grupo) realizará para alcanzar la solución a los requerimientos obtenidos, por lo tanto, adicionalmente a los requerimientos del centro infantil, se deberán incluir los requerimientos que implican la utilización de las herramientas seleccionadas. En este punto se abordará cada uno de los elementos del Product Backlog (Pila de Requerimientos) con sus respectivos Sprint Backlogs (Pila de actividades), y documentación del proceso de desarrollo inmerso en cada actividad del Sprint. Se iniciará el proceso con la pila de requerimientos priorizados (Product Backlog), detallados en la tabla 2.1.(Product Backlog) del apartado 2.2. (Planificación del proyecto utilizando la metodología SCRUM) de la segunda fase del presente proyecto. De acuerdo a la metodología, por cada uno de estos elementos del product backlog, se debe tener una estimación del valor y del esfuerzo inicial. De la estimación del valor deberá encargarse el Dueño del Producto (Product Owner), quien a su vez coloca una valoración a cada uno de dichos elementos de acuerdo al peso que observa dentro del proyecto. Por otro lado, para la estimación del esfuerzo inicial, se debe encargar el Scrum Manager, de acuerdo a las reuniones con el Team, para delimitar el esfuerzo requerido. Así mismo en la tabla 2.1. de la Fase 2, se puede apreciar la asignación del esfuerzo incial requerido para cada uno de los 2 requerimientos señalados. Esto es especialmente importante, para poder tener una idea clara de cuáles actividades serán las que más recursos humanos demandarán. La metodología señala que éstas estimaciones se las cuantifica de acuerdo a un criterio del SCRUM Master, por lo que para la presente tesis se tiene que las escalas para dichas estimaciones son:

135 135 Estimación de Valor: Escala de 1 7. Estimación del Esfuerzo inicial: Escala de Una vez definida la Pila de Requerimientos (Product Backlog) con sus respectivas valoraciones, se debe especificar por cada uno de los elementos (requerimientos), las correspondientes acciones o tareas a realizar o lo que en Scrum se denomina Sprint Backlog. En el apartado 2.2. (Planificación del proyecto utilizando la metodología SCRUM), de la Fase 2, se presentó la tabla completa del Sprint Backlog, que contiene todas las tareas a realizar en el presente proyecto. Definidas la pila de requerimientos y las tareas a realizar, se procederá a realizar la documentación referente a la aplicación de la metodología, por cada uno de los sprints.

136 136 A SPRINT 1. Elemento del Product Backlog Tareas Voluntario Analizar y obtener requerimientos del cliente para el portal del CI Elaborar un portal para el Centro Infantil Diseñar el modelo conceptual del portal Diseñar pantallas de portal de acuerdo al modelo conceptual del mismo Max Morillo Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) Total Tabla A2.1. Desarrollo de Sprint 1. A BURNDOWN CHART Figura A2.2. Burndown Chart de Sprint 1

137 137 A SPRINT 2. Elemento del Product Backlog Tareas Voluntario Consultar en diferentes fuentes la documentación sobre instalación de Liferay Portal. (Adquirir bibliografía de autores experimentados en la herramienta). Instalar y configurar java jdk en Elaborar un portal para el Centro Infantil Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) servidor Linux CentOs 5. Max Morillo Instalar y configurar Mysql en servidor CentOs 5. Incluye creación de instancia de BDD para interacción con Liferay Descargar la versión libre de Liferay Versión Community + Jboss AS Configurar el servidor de aplicaciones Jboss embebido en Liferay Portal A BURNDOWN CHART Total Tabla A2.2. Desarrollo de Sprint Figura A2.3. Burndown Chart de Sprint 2

138 138 A SPRINT 3. Elemento del Product Backlog Tareas Voluntario Elaborar un portal para el Centro Infantil Definir plantilla de temas (Template) para el portal, y disposiciones (Layouts) de cada página. 3 2 Estimación de Esfuerzo Inicial Max Morillo Nuevo Esfuerzo Estimado (al final del día) Crear página Web principal y opciones públicas, con Liferay Portal Total Tabla A2.3. Desarrollo de Sprint 3. A BURNDOWN CHART Figura A2.4. Burndown Chart de Sprint 3

139 139 A SPRINT 4. Elemento del Product Backlog Tareas Voluntario Crear usuarios en liferay, de acuerdo a listado entregado por la Directora del CI. Elaborar un portal para el Centro Infantil Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) Crear grupos de usuarios en liferay, para asignación de usuarios Crear roles para asignación a grupos de usuarios y sus permisos correspondientes Definir restricciones de acceso a opción de "Monitoreo Web Cam." Max Morillo Total Tabla A2.4. Desarrollo de Sprint 4. A BURNDOWN CHART Figura A2.5. Burndown Chart de Sprint 4

140 140 A SPRINT 5. Elemento del Product Backlog Tareas Voluntario Instalar Cámara con conexión a Router Elaborar un portal para el Centro Infantil Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) Inalámbrico Dlink DIR Crear un DNS dinámico para conexión remota de cámara IP Dlink. (ver alojamiento Dinámico gratis DYNDNS.ORG) Investigar la forma de emisión de video de la cámara, para captura de imágenes desde el portlet a crear Realizar pruebas de funcionamiento del portal Max Morillo A BURNDOWN CHART Total Tabla A2.5. Desarrollo de Sprint Figura A2.6. Burndown Chart de Sprint 5

141 141 A SPRINT 6. Elemento del Product Backlog Tareas Voluntario Elaborar un portal para el Centro Infantil Analizar y obtener requerimientos del modelo del aplicativo de monitoreo de niños Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) Diseñar el modelo conceptual del Max Morillo portlet para el monitoreo de niños Diseñar el modelo de Casos de Uso del aplicativo de monitoreo Total Tabla A2.6. Desarrollo de Sprint 6. A BURNDOWN CHART Figura A2.7. Burndown Chart de Sprint 6

142 142 A SPRINT 7. Elemento del Product Backlog Tareas Voluntario Descargar plug-in de Liferay Elaborar un portal para el Centro Infantil Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) con Tomcat, para Eclipse Cargar y configurar Plug-in de Liferay SDK para Eclipse en ambiente de desarrollo. Max Morillo Crear un nuevo proyecto Plug-in Portlet llamado CamaraIPPortlet Investigar la forma de generación de portlets con framework de Liferay Total Tabla A2.7. Desarrollo de Sprint 7. A BURNDOWN CHART Figura A2.8. Burndown Chart de Sprint 7

143 143 A SPRINT 8. Elemento del Product Backlog Tareas Voluntario Crear archivo "service.xml", con definiciones de tabla de datos para la generación vía ServiceBuilder de Liferay, Elaborar un portal para el Centro Infantil Estimació n de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) del modelo, servicio y persistencia de datos Definir entorno de variables para desarrollo de portlet de acuerdo a especificaciones de Liferay Programar métodos para almacenamiento y recuperación de datos Max Morillo Programar View.jsp de presentación de imagen de cámara IP Programar View.jsp de administración de Salones Programar métodos de administración de Permisos para los portlets creados Desplegar proyecto en ambiente de desarrollo para pruebas de conexión Total Tabla A2.8. Desarrollo de Sprint 8

144 144 A BURNDOWN CHART Figura A2.9. Burndown Chart de Sprint 8

145 145 A SPRINT 9. Elemento del Product Backlog Tareas Voluntario Desplegar proyecto en ambiente de producción. Elaborar un Realizar pruebas de funcionamiento de los portal para el portlets desplegados en producción Centro Infantil Observación de impacto de la solución en Max Morillo Padres de familia con acceso a portal Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) Total Tabla A2.9. Desarrollo de Sprint 9. A BURNDOWN CHART

146 Figura A2.10. Burndown Chart de Sprint 9 A SPRINT 10. Elemento del Product Backlog Tareas Voluntario Estimación de Esfuerzo Inicial Nuevo Esfuerzo Estimado (al final del día) Elaborar un portal para el Centro Infantil Documentar y digitar marco teórico de tesis Max Morillo Total Tabla A2.10. Desarrollo de Sprint 10. A BURNDOWN CHART

147 Figura A2.11. Burndown Chart de Sprint 10

148 148 ANEXO 3. REVISIÓN GENERAL DE LIFERAY COMO PORTAL Una definición aproximada de lo que es un Portal, en el mundo del desarrollo de software, es la que hace referencia a: sitio web que proporciona a las personas el acceso a información, aplicaciones y procesos de negocios. Todo ello desde un único punto de entrada. Un portal provee de mecanismos de integración, inicio único de sesión SSO (Single Sign On), seguridad, contenido personalizado, preferencias a medida de los usuarios, gestión de contenidos, opciones de colaboración entre personas, acceso desde múltiples dispositivos, opciones de búsqueda y navegación entre aplicaciones. Los portales trabajan con una serie de Portlets, los cuales son pequeñas aplicaciones web que se ejecutan en una parte de una página, sin importar el manejo de seguridades u otros detalles, de los cuales se hace cargo el portal como tal. Los ejemplos más conocidos de lo que es un portal, serían los sitios web: Yahoo!, MSN, o Terra, los cuales, desde una misma pantalla de inicio, ofrecen noticias, enlaces a servicios, acceso a correo electrónico, etc. La diferencia entre un portal y una simple página Web, es que a más de las características ya anotadas anteriormente (seguridad, preferencias a medida de los usuarios, etc.), los portales se vuelven una necesidad tomando en cuenta lo siguiente: Cuando existe la necesidad de personalizar servicios: es decir, cuando se quiere brindar conjuntos distintos de aplicaciones a los usuarios, de acuerdo al área y/o al rol que cumplen en la organización. En el caso del presente tema de desarrollo, existirán varios roles de los Usuarios, por lo que esta tecnología se puede aplicar y adaptar fácilmente. Cuando existe multitud de aplicaciones aisladas entre sí: que es el escenario clásico de una empresa que cuenta con aplicaciones para cada una de sus actividades, y entre las cuales no hay intercambio de datos. En este caso, un portal es una opción a considerar cuando se requiere integrar múltiples aplicaciones.

149 149 Cuando existe demasiada información en la empresa: donde la información requerida por el personal no es fácil de encontrar o simplemente no está disponible, por lo cual se tiene que gastar tiempo en buscar a la persona o el departamento que puede contar con ella. Un portal busca contar con un control centralizado y configurable de acceso a los servicios o contenido de información. Qué es Liferay Portal? Liferay Portal, o más conocido mundialmente como Liferay, es una plataforma web empresarial para construir aplicaciones de negocios y es Open Source (de código abierto) basado en Java. Fue diseñado para facilitar (a los miembros de una empresa o usuarios externos autorizados), el acceso a las distintas aplicaciones o contenido de información institucional que se desee administrar bajo un Entorno de Trabajo Unificado. El proyecto Liferay Portal se inició en el año 2000, y actualmente se constituye en la principal aplicación para el desarrollo de portales de licencia abierta, teniendo como rivales a Websphere Portal, Oracle Portal, JBoss Portal, Jetspeed, etc. Liferay también es utilizado a nivel mundial, para el desarrollo de sitios web públicos, con funcionalidades de administrador de contenidos (Content Management System, CMS), Intranets, Extranets, plataformas de colaboración y aplicaciones para la Web. Finalmente, Liferay como portal, es una poderosa herramienta que ayuda a organizar los usuarios, dándoles a estos los accesos para el contenido que necesitan. Se puede crear: - Comunidades - Organizaciones - Roles - Grupos de usuarios A todos estos tipos mencionados, se puede hacer que se otorgue los permisos correspondientes, permitiendo de esta manera restringir y proteger el contenido únicamente a los usuarios que pueden acceder a los datos.

150 150 Fundamentos de Liferay Figura A3.1. Pantalla de inicio de Liferay Las funcionalidades de Liferay podrían agruparse en dos características principales: - Por un lado, se tiene que la configuración estándar de Liferay, permite administrar las funcionalidades más básicas en cuanto a usuarios, grupos de usuarios, roles, organizaciones y comunidades (Ver Figura A3.2. Gráfico Organización de Recursos de Liferay). Estas funcionalidades, aunque a simple vista aparenten ser simples, hacen posible la personalización del portal de acuerdo al usuario, llegando incluso a considerar roles con privilegios sumamente específicos.

151 151 Figura A3.2. Gráfico Organización de Recursos de Liferay - Por otra parte, Liferay provee un conjunto predefinido de herramientas denominado Liferay Collaboration Suite, que es un juego de aplicaciones que pueden utilizarse para construir comunidades de usuarios que utilicen intensivamente el portal. Esta suite contiene: blogs, calendarios, mensajería instantánea (chat), correo electrónico (para servidores ya existentes y que soporten IMAP), tablero de anuncios (foros) y wikis. Adicionalmente, Liferay cuenta con la posibilidad de incorporar plugins para extender las funcionalidades básicas: Porlets (pequeñas aplicaciones web que se ejecutan en una parte de una página web), temas de diseño, distribución de elementos de páginas, y módulos web en Java EE. Algunos de estos plugins ya vienen incorporados por defecto en la instalación estándar. A continuación se muestra gráficamente el manejo de portales (pueden ser varios) que pueden ejecutarse en una instancia de Liferay (Ver. Figura A3.3. Manejo de instancia). Como se puede observar pueden haber uno o más portales para una instancia, y cada portal puede tener: Grupos de Usuarios, Usuarios, Roles por usuarios, Organizaciones, Comunidades y Web Pages por cada una de estas, etc.

152 152 Figura A3.3. Manejo de instancia Finalmente, la selección de esta herramienta como Portal (Liferay y no las otras mencionadas al inicio), se hace específicamente por la facilidad de manejo de todo el entramado de seguridades, permisos, usuarios, etc., además que es la mejor herramienta Open Source del mercado. Así mismo facilita el manejo y construcción de portlets específicos, que ayudarán a la colocación de la imagen de la captura de la cámara IP.

153 153 ANEXO 4. ECLIPSE, COMO FRAMEWORK PARA DESARROLLO DE PORTLETS. Eclipse es un entorno de desarrollo integrado (IDE por sus siglas en inglés), de código abierto y multiplataforma, para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido", opuesto a las aplicaciones "Cliente-liviano" basadas en navegadores. La definición que da el proyecto Eclipse acerca de su software es: "una especie de herramienta universal - un IDE abierto y extensible para todo y nada en particular". Esta plataforma, típicamente ha sido usada para desarrollar entornos de desarrollo integrados, como el IDE de Java llamado Java Development Toolkit (JDT) y el compilador (ECJ) que se entrega como parte de Eclipse (y que son usados también para desarrollar el mismo Eclipse). Sin embargo, también se puede usar para otros tipos de aplicaciones cliente, como Bit Torrent Azereus. Eclipse es también una comunidad de usuarios, extendiendo constantemente las áreas de aplicación cubiertas. Un ejemplo es el recientemente creado Eclipse Modeling Project, cubriendo casi todas las áreas de Model Driven Engineering. Eclipse fue desarrollado originalmente por IBM como el sucesor de su familia de herramientas para VisualAge. Eclipse es ahora desarrollado por la Fundación Eclipse, una organización independiente sin ánimo de lucro que fomenta una comunidad de código abierto y un conjunto de productos complementarios, capacidades y servicios. A4.1. Arquitectura La base para Eclipse es la Plataforma de cliente enriquecido (del Inglés Rich Client Platform RCP). Los siguientes componentes constituyen la plataforma de cliente enriquecido: Plataforma principal - inicio de Eclipse, ejecución de plugins

154 154 OSGi- una plataforma para bundling estándar. El Standard Widget Toolkit (SWT) Un widget toolkit portable. JFace - manejo de archivos, manejo de texto, editores de texto El Workbench de Eclipse - vistas, editores, perspectivas, asistentes Los widgets (Programas pequeños) de Eclipse están implementados por una herramienta de widget para Java llamada SWT (Standard Widget Toolkit), a diferencia de la mayoría de las aplicaciones Java, que usan las opciones estándar Abstract Window Toolkit (AWT) o Swing. La interfaz de usuario de Eclipse también tiene una capa GUI intermedia llamada JFace, la cual simplifica la construcción de aplicaciones basadas en SWT. El entorno de desarrollo integrado (IDE) de Eclipse emplea módulos (en inglés plugin), para proporcionar toda su funcionalidad al frente de la plataforma de cliente rico, a diferencia de otros entornos monolíticos donde las funcionalidades están todas incluidas, las necesite el usuario o no. Este mecanismo de módulos es una plataforma ligera para componentes de software. Adicionalmente permite a Eclipse extenderse usando otros lenguajes de programación como son C/C++ y Python, también es factible trabajar con lenguajes para procesado de texto como LaTeX, aplicaciones en red como Telnet y Sistema de gestión de base de Datos. La arquitectura utilizando Plugins permite escribir cualquier extensión deseada en el ambiente, como sería Gestión de la configuración. Se provee soporte para Java y CVS en el SDK de Eclipse. Y no tiene por qué ser usado únicamente para soportar otros lenguajes de programación. En cuanto a las aplicaciones clientes, eclipse provee al programador con frameworks muy ricos para el desarrollo de aplicaciones gráficas, definición y manipulación de modelos de software, aplicaciones web, etc. Por ejemplo, GEF (Graphic Editing Framework - Framework para la edición gráfica) es un plugin de Eclipse para el desarrollo de editores visuales que pueden ir desde procesadores de texto wysiwyg hasta editores de diagramas UML, interfaces gráficas para el usuario (GUI), etc. Dado que los editores realizados con GEF "viven" dentro de Eclipse, además de poder ser usados conjuntamente con otros plugins, hacen uso de su interfaz gráfica personalizable y profesional.

155 155 El SDK de Eclipse incluye las herramientas de desarrollo de Java, ofreciendo un IDE con un compilador de Java interno y un modelo completo de los archivos fuente de Java. Esto permite técnicas avanzadas de refactorización y análisis de código. El IDE también hace uso de un espacio de trabajo, en este caso un grupo de metadata en un espacio para archivos plano, permitiendo modificaciones externas a los archivos en tanto se refresque el espacio de trabajo correspondiente. El 28 de junio de 2005 fue liberada la versión 3.1 que incluye mejoras en el rendimiento, el soporte de Java 5.0, mejor integración con Ant (incluido debugger) y CVS. Eclipse dispone de un Editor de texto con resaltado de sintaxis. La compilación es en tiempo real. Tiene pruebas unitarias con JUnit, control de versiones con CVS, integración con Ant, asistentes (wizards) para creación de proyectos, clases, tests, etc., y refactorización. Asimismo, a través de "plugins" libremente disponibles es posible añadir control de versiones con Subversion e integración con Hibernate. Se seleccionó esta herramienta, debido a que se debe realizar la implementación de Portlets, para el monitoreo del video emitido por la cámara Web. Estos portlets, darán la funcionalidad requerida por el Centro de Desarrollo Infantil Popeye s, además, que se puede aprovechar el código fuente de Liferay para su debida implementación.

156 156 ANEXO 5. HOSTING. Para la instalación del portal Liferay en ambiente de producción, se hace necesario la contratación de un servidor Web para albergar toda la herramienta y sus configuraciones. Luego de hacer las revisiones a diferentes sitios de Hosting (Hospedaje de páginas web), se determinó que de acuerdo a las características del portal (Liferay) y el servidor de aplicaciones que se utilizará (JBoss), el más conveniente incluyendo costos de alojamiento, es el que provee el sitio Server4You ( En la figura A5.1. (Datos de dominio contratado), se puede observar los datos referentes al sitio contratado, para albergar la página web, objeto del presente tema de tesis. Figura. A5.1. Datos de dominio contratado

157 157 El servidor contratado es del tipo VirtualServer 27 características las siguientes: (vserver Plus X4), y tiene como Servidor Virtual dedicado. 50 GB de espacio Web 3 GB de memoria RAM, y 6 GB de memoria FlexRam 4 Ghz de velocidad en CPU. Basado en sistema operativo Linux CentOs 5.0 Control total del servidor a nivel de root. Acceso a root vía ftp. 27 Virtual Server.- Servidor virtual, es una partición dentro de un servidor que habilita varias máquinas virtuales por medio de diferentes tecnologías.

158 158 ANEXO 6. RECURSOS A UTILIZAR EN EL DESARROLLO DE LA SOLUCIÓN Para la realización del presente tema de tesis, se utilizarán los siguientes recursos: A6.1. Recursos Intangibles (o lógicos): - Hosting: para alojamiento del Portal (Liferay). Se contrató el proveedor de hosting Server4You ( ), el cual contiene las facilidades correspondientes para instalar Liferay Portal V.6.0, Java, y Mysql. Este Hosting está basado en servidores con sistema operativo CentOs 5. El dominio a utilizarse será - Liferay Portal V.6.0.5: para la implementación del sitio Web del Centro Infantil. Aquí se hará la administración completa del portal, que incluye: o Creación de Usuarios o Creación de Grupos de Usuarios o Definición de políticas de acceso o Definición de las aplicaciones a utilizarse en el Portal (ej. Wiki, blogs, noticias, etc.). - JBOSS: Servidor de aplicaciones que interactuará con Liferay. Actualmente la versión de Liferay 6.0.5, contiene un Jboss A.S. embebido ( Embeded ) con el cual se trabajará en la implementación de la solución. - Java JDK: Para la ejecución de Liferay, ya que éste Portal es Basado en Java. - Eclipse : Framework para el desarrollo del Portlet (aplicación), que se agregará al sitio Web, por intermedio de Liferay. - Mysql: como motor de persistencia, para el almacenamiento de información generada por Liferay. - Conexión a Internet Banda ancha. Para pruebas del sistema se tomará en cuenta la velocidad de 1.2 Mbps.

159 159 A6.2. Recursos Físicos o Tangibles: - Cámara IP Dlink DCS Router (Advantek) - Computador (Para el desarrollo del tema de tesis). A continuación se detalla un presupuesto estimado requerido para cubrir los recursos de los puntos anteriormente citados (Tabla A6.2. Presupuesto aproximado requerido): Nro. Recursos Cant. V. Unit. V. Total 1 Hosting (anual) Liferay Portal V * JBOSS * Java JDK * Eclipse * Mysql * Cámara IP Dlink DCS Router (Advantek) Bibliografía (e-books) TOTAL APROX. PRESUPUESTO Tabla A6.1. Presupuesto aproximado requerido para cubrir recursos * Versiones descargables basadas en licencias GNU/GPL (General Public Licence) de los fabricantes. Como se puede observar, en lo referente a costos, se nota el bajo nivel de inversión para el presente proyecto.

160 160 ANEXO 7. ENCUESTAS DE SATISFACCIÓN DE USO DE MONITOREO WEB A continuación se adjuntan las encuestas realizadas a los padres de familia:

161 161

162 162

163 163

164 164

165 165

166 166

167 167

168 168

169 169

170 170 ANEXO 8. CÓDIGO FUENTE DEL APLICATIVO A continuación se adjunta las principales clases y scripts (.jsp), con las cuales se ha implementado la solución, objeto del presente tema de tesis. package com.centroinfantilpopeyes.webcamportlet.registrosalon; import java.io.ioexception; import java.io.printwriter; import java.util.arraylist; import java.util.collections; import java.util.list; import javax.portlet.actionrequest; import javax.portlet.actionresponse; import javax.portlet.portletexception; import javax.portlet.portletpreferences; import javax.portlet.renderrequest; import javax.portlet.renderresponse; import org.apache.commons.logging.log; import org.apache.commons.logging.logfactory; import com.centroinfantilpopeyes.webcamportlet.model.wcpsalon; import com.centroinfantilpopeyes.webcamportlet.model.impl.wcpsalonimpl; import com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil; import com.liferay.portal.kernel.exception.portalexception; import com.liferay.portal.kernel.exception.systemexception; import com.liferay.portal.kernel.servlet.sessionerrors; import com.liferay.portal.kernel.servlet.sessionmessages; import com.liferay.portal.kernel.util.http.response; import com.liferay.portal.kernel.util.paramutil; import com.liferay.portal.kernel.util.validator; import com.liferay.portal.kernel.util.webkeys; import com.liferay.portal.theme.themedisplay; import com.liferay.util.bridges.mvc.mvcportlet; /** * This portlet is used to maintain the Salones that * Popeyes allows users to register for. * Max Morillo */ public class SalonAdminPortlet extends MVCPortlet { /** * This Action adds a salon to the database. request response java.lang.exception */ public void addsalon(actionrequest request, ActionResponse response) throws Exception { ThemeDisplay themedisplay = (ThemeDisplay)request.getAttribute(WebKeys.THEME_DISPLAY); WCPSalon salon = ActionUtil.salonFromRequest(request); ArrayList<String> errors = new ArrayList<String>(); if (SalonRegValidator.validateSalon(salon, errors)) { WCPSalonLocalServiceUtil.addSalon(salon, themedisplay.getuserid()); SessionMessages.add(request, "salon-saved-successfully"); } else { SessionErrors.add(request, "fields-required");

171 171 } } /** * This Action gets a salon from the database and puts it into the * request. It also sets the "jsppage" parameter to "editsalon" so that * processing is forwarded to edit_salon.jsp. * request response java.lang.exception */ public void editsalon(actionrequest request, ActionResponse response) throws Exception { } long salonkey = ParamUtil.getLong(request, "resourceprimkey"); if (Validator.isNotNull(salonKey)) { WCPSalon salon = WCPSalonLocalServiceUtil.getWCPSalon(salonKey); request.setattribute("salon", salon); response.setrenderparameter("jsppage", editsalonjsp); } /** * This Action updates an existing salon with values that were entered * into the edit_salon.jsp. request response java.lang.exception */ public void updatesalon(actionrequest request, ActionResponse response) throws Exception { long salonkey = ParamUtil.getLong(request, "resourceprimkey"); ArrayList<String> errors = new ArrayList<String>(); if (Validator.isNotNull(salonKey)) { WCPSalon salon = WCPSalonLocalServiceUtil.getWCPSalon(salonKey); WCPSalon requestsalon = ActionUtil.salonFromRequest(request); } if (SalonRegValidator.validateSalon(requestSalon, errors)) { salon.setnombresalon(requestsalon.getnombresalon()); salon.setipcamara(requestsalon.getipcamara()); salon.setpuertocamara(requestsalon.getpuertocamara()); salon.seturlstreaming(requestsalon.geturlstreaming()); WCPSalonLocalServiceUtil.updateWCPSalon(salon); SessionMessages.add(request, "salonupdated"); } else { for (String error : errors) { SessionErrors.add(request, error); } } } else { SessionErrors.add(request, "error-updating"); } /** * This Action deletes a salon from the database.

172 172 request response java.lang.exception */ public void deletesalon(actionrequest request, ActionResponse response) throws Exception { long salonkey = ParamUtil.getLong(request, "resourceprimkey"); } if (Validator.isNotNull(salonKey)) { WCPSalonLocalServiceUtil.deleteSalon(salonKey); SessionMessages.add(request, "salondeleted"); } else { SessionErrors.add(request, "error-deleting"); } /** * This Action shows a salon from the database. request response java.lang.exception */ public void viewsalon(renderrequest request, RenderResponse response) throws IOException, PortletException { String ipcamara = new String(); long puertocamara = 0; String urlstreaming = new String(); } //long salonkey = ParamUtil.getLong(request, "resourceprimkey"); response.setcontenttype("text/html"); PrintWriter writer = response.getwriter(); writer.write("hello World!"); writer.close(); protected String editsalonjsp = "/admin/edit_salon.jsp"; } Listado A8.1. Clase SalonAdminPortlet * Copyright (c) Liferay, Inc. All rights reserved. * * Permission is hereby granted, free of charge, to any person obtaining a copy * of this software and associated documentation files (the "Software"), to deal * in the Software without restriction, including without limitation the rights * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell * copies of the Software, and to permit persons to whom the Software is * furnished to do so, subject to the following conditions: * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. * * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE

173 173 * SOFTWARE. */ package com.centroinfantilpopeyes.webcamportlet.registrosalon; import com.centroinfantilpopeyes.webcamportlet.model.wcpsalon; import com.liferay.portal.kernel.util.validator; import java.util.calendar; import java.util.gregoriancalendar; import java.util.list; /** * This class is responsible for validating salon themselves. * Max Morillo */ public class SalonRegValidator { /** * Validates a Salon object salon errors boolean */ public static boolean validatesalon (WCPSalon salon, List<String> errors) { boolean valid = true; if (Validator.isNull(salon.getNombreSalon())) { errors.add("salon-name-required"); valid = false; } if (Validator.isNull(salon.getIpCamara())) { errors.add("ip-camara-required"); valid = false; } if (Validator.isNull(salon.getUrlStreaming())) { errors.add("url-streaming-required"); valid = false; } if (Validator.isNull(salon.getUrlStreaming())) { errors.add("puerto-camara-required"); valid = false; } if (Validator.isNull(salon.getCompanyId())) { errors.add("missing-company-id"); valid = false; } if (Validator.isNull(salon.getGroupId())) { errors.add("missing-group-id"); valid = false; } return valid; } } Listado A8.2. Clase SalonRegValidator

174 174 package com.centroinfantilpopeyes.webcamportlet.registrosalon; import java.util.collections; //import java.util.date; import java.util.list; import javax.portlet.actionrequest; import javax.portlet.renderrequest; //import org.apache.jasper.tagplugins.jstl.core.param; import com.centroinfantilpopeyes.webcamportlet.model.wcpsalon; import com.centroinfantilpopeyes.webcamportlet.model.impl.wcpsalonimpl; import com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil; //import com.liferay.portal.kernel.exception.portalexception; import com.liferay.portal.kernel.exception.systemexception; import com.liferay.portal.kernel.util.paramutil; import com.liferay.portal.kernel.util.webkeys; import com.liferay.portal.theme.themedisplay; //import com.liferay.portal.util.portalutil; /** * Max Morillo * */ public class ActionUtil { /** * Used by the view.jsp to grab the salones from the database. request */ public static List<WCPSalon> getsalones(renderrequest request) { ThemeDisplay themedisplay = (ThemeDisplay) request.getattribute(webkeys.theme_display); } long groupid = themedisplay.getscopegroupid(); List<WCPSalon> tempresults; try { tempresults = WCPSalonLocalServiceUtil.getSalones(groupId); } catch (SystemException ex) { tempresults = Collections.emptyList(); } return tempresults; /** * Creates a WCSalon object out of values from the request. request */ public static WCPSalon salonfromrequest (ActionRequest request) { ThemeDisplay themedisplay = (ThemeDisplay) request.getattribute(webkeys.theme_display); WCPSalon salon = new WCPSalonImpl(); salon.setcompanyid(themedisplay.getcompanyid());

175 175 salon.setgroupid(themedisplay.getscopegroupid()); salon.setnombresalon(paramutil.getstring(request, "nombresalon")); salon.setipcamara(paramutil.getstring(request, "ipcamara")); salon.setpuertocamara(paramutil.getlong(request, "puertocamara")); salon.seturlstreaming(paramutil.getstring(request, "urlstreaming")); return salon; } } Listado A8.3. Clase ActionUtil /** * Copyright (c) Liferay, Inc. All rights reserved. * * This library is free software; you can redistribute it and/or modify it under * the terms of the GNU Lesser General Public License as published by the Free * Software Foundation; either version 2.1 of the License, or (at your option) * any later version. * * This library is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS * FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more * details. */ package com.centroinfantilpopeyes.webcamportlet.service.impl; import java.util.list; import com.centroinfantilpopeyes.webcamportlet.nosuchsalonexception; import com.centroinfantilpopeyes.webcamportlet.model.wcpsalon; import com.centroinfantilpopeyes.webcamportlet.service.base.wcpsalonlocalservicebaseimpl; import com.liferay.portal.kernel.exception.portalexception; import com.liferay.portal.kernel.exception.systemexception; import com.liferay.portal.model.resourceconstants; import com.liferay.portlet.softwarecatalog.productentryauthorexception; /** * The implementation of the w c p salon local service. * * <p> * All custom service methods should be put in this class. Whenever methods are added, rerun ServiceBuilder to copy their definitions into the {@link com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalservice} interface. * </p> * * <p> * Never reference this interface directly. Always use {@link com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil} to access the w c p salon local service. * </p> * * <p> * This is a local service. Methods of this service will not have security checks based on the propagated JAAS credentials because this service can only be accessed from within the same VM. * </p> * Max Morillo com.centroinfantilpopeyes.webcamportlet.service.base.wcpsalonlocalservicebaseimpl com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil */ public class WCPSalonLocalServiceImpl extends WCPSalonLocalServiceBaseImpl { public WCPSalon addsalon (WCPSalon newsalon, long salonid) throws SystemException, PortalException {

176 176 WCPSalon salon = wcpsalonpersistence.create(counterlocalservice.increment(wcpsalon.class.getname())); resourcelocalservice.addresources(newsalon.getcompanyid(), newsalon.getgroupid(), salonid, WCPSalon.class.getName(), salon.getprimarykey(), false, true, true); salon.setnombresalon(newsalon.getnombresalon()); salon.setipcamara(newsalon.getipcamara()); salon.setpuertocamara(newsalon.getpuertocamara()); salon.seturlstreaming(newsalon.geturlstreaming()); salon.setcompanyid(newsalon.getcompanyid()); salon.setgroupid(newsalon.getgroupid()); return wcpsalonpersistence.update(salon, false); } public void deletesalon(long salonid) throws NoSuchSalonException, SystemException, PortalException { WCPSalon salon = wcpsalonpersistence.findbyprimarykey(salonid); deletesalon(salon, salonid); } public void deletesalon(wcpsalon salon, long salonid) throws NoSuchSalonException, SystemException, PortalException { resourcelocalservice.deleteresource(salonid, WCPSalon.class.getName(), ResourceConstants.SCOPE_INDIVIDUAL, salon.getprimarykey()); wcpsalonpersistence.remove(salon); } } public List<WCPSalon> getsalones(long groupid) throws SystemException { List<WCPSalon> salones = wcpsalonpersistence.findbygroupid(groupid); return salones; } Listado A8.4. Clase WCPSalonLocalServiceImpl /** * Copyright (c) Liferay, Inc. All rights reserved. * * This library is free software; you can redistribute it and/or modify it under * the terms of the GNU Lesser General Public License as published by the Free * Software Foundation; either version 2.1 of the License, or (at your option) * any later version. * * This library is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS * FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more * details. */ package com.centroinfantilpopeyes.webcamportlet.service.impl; import java.util.list; import com.centroinfantilpopeyes.webcamportlet.nosuchsalonexception; import com.centroinfantilpopeyes.webcamportlet.model.wcpsalon; import com.centroinfantilpopeyes.webcamportlet.service.base.wcpsalonlocalservicebaseimpl; import com.liferay.portal.kernel.exception.portalexception; import com.liferay.portal.kernel.exception.systemexception; import com.liferay.portal.model.resourceconstants; import com.liferay.portlet.softwarecatalog.productentryauthorexception; /** * The implementation of the w c p salon local service. *

177 177 * <p> * All custom service methods should be put in this class. Whenever methods are added, rerun ServiceBuilder to copy their definitions into the {@link com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalservice} interface. * </p> * * <p> * Never reference this interface directly. Always use {@link com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil} to access the w c p salon local service. * </p> * * <p> * This is a local service. Methods of this service will not have security checks based on the propagated JAAS credentials because this service can only be accessed from within the same VM. * </p> * Max Morillo com.centroinfantilpopeyes.webcamportlet.service.base.wcpsalonlocalservicebaseimpl com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil */ public class WCPSalonLocalServiceImpl extends WCPSalonLocalServiceBaseImpl { public WCPSalon addsalon (WCPSalon newsalon, long salonid) throws SystemException, PortalException { WCPSalon salon = wcpsalonpersistence.create(counterlocalservice.increment(wcpsalon.class.getname())); resourcelocalservice.addresources(newsalon.getcompanyid(), newsalon.getgroupid(), salonid, WCPSalon.class.getName(), salon.getprimarykey(), false, true, true); salon.setnombresalon(newsalon.getnombresalon()); salon.setipcamara(newsalon.getipcamara()); salon.setpuertocamara(newsalon.getpuertocamara()); salon.seturlstreaming(newsalon.geturlstreaming()); salon.setcompanyid(newsalon.getcompanyid()); salon.setgroupid(newsalon.getgroupid()); return wcpsalonpersistence.update(salon, false); } public void deletesalon(long salonid) throws NoSuchSalonException, SystemException, PortalException { WCPSalon salon = wcpsalonpersistence.findbyprimarykey(salonid); deletesalon(salon, salonid); } public void deletesalon(wcpsalon salon, long salonid) throws NoSuchSalonException, SystemException, PortalException { resourcelocalservice.deleteresource(salonid, WCPSalon.class.getName(), ResourceConstants.SCOPE_INDIVIDUAL, salon.getprimarykey()); wcpsalonpersistence.remove(salon); } public List<WCPSalon> getsalones(long groupid) throws SystemException { List<WCPSalon> salones = wcpsalonpersistence.findbygroupid(groupid); return salones; } } Listado A8.4. Clase WCPSalonLocalService /** * Copyright (c) Liferay, Inc. All rights reserved. * * This library is free software; you can redistribute it and/or modify it under * the terms of the GNU Lesser General Public License as published by the Free * Software Foundation; either version 2.1 of the License, or (at your option) * any later version. *

178 178 * This library is distributed in the hope that it will be useful, but WITHOUT * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS * FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more * details. */ package com.centroinfantilpopeyes.webcamportlet.service.base; import com.centroinfantilpopeyes.webcamportlet.model.wcpsalon; import com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalservice; import com.centroinfantilpopeyes.webcamportlet.service.persistence.wcpsalonpersistence; import com.liferay.counter.service.counterlocalservice; import com.liferay.portal.kernel.annotation.beanreference; import com.liferay.portal.kernel.dao.jdbc.sqlupdate; import com.liferay.portal.kernel.dao.jdbc.sqlupdatefactoryutil; import com.liferay.portal.kernel.dao.orm.dynamicquery; import com.liferay.portal.kernel.exception.portalexception; import com.liferay.portal.kernel.exception.systemexception; import com.liferay.portal.kernel.util.orderbycomparator; import com.liferay.portal.service.resourcelocalservice; import com.liferay.portal.service.resourceservice; import com.liferay.portal.service.userlocalservice; import com.liferay.portal.service.userservice; import com.liferay.portal.service.persistence.resourcepersistence; import com.liferay.portal.service.persistence.userpersistence; import java.util.list; import javax.sql.datasource; /** * The base implementation of the w c p salon local service. * * <p> * This implementation exists only as a container for the default service methods generated by ServiceBuilder. All custom service methods should be put in {@link com.centroinfantilpopeyes.webcamportlet.service.impl.wcpsalonlocalserviceimpl}. * </p> * * <p> * Never modify or reference this class directly. Always use {@link com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil} to access the w c p salon local service. * </p> * Max Morillo com.centroinfantilpopeyes.webcamportlet.service.impl.wcpsalonlocalserviceimpl com.centroinfantilpopeyes.webcamportlet.service.wcpsalonlocalserviceutil */ public abstract class WCPSalonLocalServiceBaseImpl implements WCPSalonLocalService { /** * Adds the w c p salon to the database. Also notifies the appropriate model listeners. * wcpsalon the w c p salon to add the w c p salon that was added SystemException if a system exception occurred */ public WCPSalon addwcpsalon(wcpsalon wcpsalon) throws SystemException { wcpsalon.setnew(true); } return wcpsalonpersistence.update(wcpsalon, false); /** * Creates a new w c p salon with the primary key. Does not add the w c p salon to the database. * salonid the primary key for the new w c p salon

179 179 the new w c p salon */ public WCPSalon createwcpsalon(long salonid) { return wcpsalonpersistence.create(salonid); } /** * Deletes the w c p salon with the primary key from the database. Also notifies the appropriate model listeners. * salonid the primary key of the w c p salon to delete PortalException if a w c p salon with the primary key could not be found SystemException if a system exception occurred */ public void deletewcpsalon(long salonid) throws PortalException, SystemException { wcpsalonpersistence.remove(salonid); } /** * Deletes the w c p salon from the database. Also notifies the appropriate model listeners. * wcpsalon the w c p salon to delete SystemException if a system exception occurred */ public void deletewcpsalon(wcpsalon wcpsalon) throws SystemException { wcpsalonpersistence.remove(wcpsalon); } /** * Performs a dynamic query on the database and returns the matching rows. * dynamicquery the dynamic query to search with the matching rows SystemException if a system exception occurred public List dynamicquery(dynamicquery dynamicquery) throws SystemException { return wcpsalonpersistence.findwithdynamicquery(dynamicquery); } /** * Performs a dynamic query on the database and returns a range of the matching rows. * * <p> * Useful when paginating results. Returns a maximum of <code>end - start</code> instances. <code>start</code> and <code>end</code> are not primary keys, they are indexes in the result set. Thus, <code>0</code> refers to the first result in the set. Setting both <code>start</code> and <code>end</code> to {@link com.liferay.portal.kernel.dao.orm.queryutil#all_pos} will return the full result set. * </p> * dynamicquery the dynamic query to search with start the lower bound of the range of model instances to return end the upper bound of the range of model instances to return (not inclusive) the range of matching rows SystemException if a system exception occurred public List dynamicquery(dynamicquery dynamicquery, int start, int end) throws SystemException { return wcpsalonpersistence.findwithdynamicquery(dynamicquery, start, end); } /** * Performs a dynamic query on the database and returns an ordered range of the matching rows. * * <p> * Useful when paginating results. Returns a maximum of <code>end - start</code> instances. <code>start</code> and <code>end</code> are not primary keys, they are indexes in the result set. Thus, <code>0</code> refers to the first result in the set.

180 180 Setting both <code>start</code> and <code>end</code> to com.liferay.portal.kernel.dao.orm.queryutil#all_pos} will return the full result set. * </p> * dynamicquery the dynamic query to search with start the lower bound of the range of model instances to return end the upper bound of the range of model instances to return (not inclusive) orderbycomparator the comparator to order the results by the ordered range of matching rows SystemException if a system exception occurred public List dynamicquery(dynamicquery dynamicquery, int start, int end, OrderByComparator orderbycomparator) throws SystemException { return wcpsalonpersistence.findwithdynamicquery(dynamicquery, start, end, orderbycomparator); } /** * Counts the number of rows that match the dynamic query. * dynamicquery the dynamic query to search with the number of rows that match the dynamic query SystemException if a system exception occurred */ public long dynamicquerycount(dynamicquery dynamicquery) throws SystemException { return wcpsalonpersistence.countwithdynamicquery(dynamicquery); } /** * Gets the w c p salon with the primary key. * salonid the primary key of the w c p salon to get the w c p salon PortalException if a w c p salon with the primary key could not be found SystemException if a system exception occurred */ public WCPSalon getwcpsalon(long salonid) throws PortalException, SystemException { return wcpsalonpersistence.findbyprimarykey(salonid); } /** * Gets a range of all the w c p salons. * * <p> * Useful when paginating results. Returns a maximum of <code>end - start</code> instances. <code>start</code> and <code>end</code> are not primary keys, they are indexes in the result set. Thus, <code>0</code> refers to the first result in the set. Setting both <code>start</code> and <code>end</code> to {@link com.liferay.portal.kernel.dao.orm.queryutil#all_pos} will return the full result set. * </p> * start the lower bound of the range of w c p salons to return end the upper bound of the range of w c p salons to return (not inclusive) the range of w c p salons SystemException if a system exception occurred */ public List<WCPSalon> getwcpsalons(int start, int end) throws SystemException { return wcpsalonpersistence.findall(start, end); } /** * Gets the number of w c p salons. * the number of w c p salons SystemException if a system exception occurred */

181 181 public int getwcpsalonscount() throws SystemException { return wcpsalonpersistence.countall(); } /** * Updates the w c p salon in the database. Also notifies the appropriate model listeners. * wcpsalon the w c p salon to update the w c p salon that was updated SystemException if a system exception occurred */ public WCPSalon updatewcpsalon(wcpsalon wcpsalon) throws SystemException { wcpsalon.setnew(false); } return wcpsalonpersistence.update(wcpsalon, true); /** * Updates the w c p salon in the database. Also notifies the appropriate model listeners. * wcpsalon the w c p salon to update merge whether to merge the w c p salon with the current session. See {@link com.liferay.portal.service.persistence.batchsession#update(com.liferay.portal.kernel.dao.orm.session, com.liferay.portal.model.basemodel, boolean)} for an explanation. the w c p salon that was updated SystemException if a system exception occurred */ public WCPSalon updatewcpsalon(wcpsalon wcpsalon, boolean merge) throws SystemException { wcpsalon.setnew(false); } return wcpsalonpersistence.update(wcpsalon, merge); /** * Gets the w c p salon local service. * the w c p salon local service */ public WCPSalonLocalService getwcpsalonlocalservice() { return wcpsalonlocalservice; } /** * Sets the w c p salon local service. * wcpsalonlocalservice the w c p salon local service */ public void setwcpsalonlocalservice( WCPSalonLocalService wcpsalonlocalservice) { this.wcpsalonlocalservice = wcpsalonlocalservice; } /** * Gets the w c p salon persistence. * the w c p salon persistence */ public WCPSalonPersistence getwcpsalonpersistence() { return wcpsalonpersistence; } /** * Sets the w c p salon persistence. * wcpsalonpersistence the w c p salon persistence */ public void setwcpsalonpersistence(wcpsalonpersistence wcpsalonpersistence) { this.wcpsalonpersistence = wcpsalonpersistence;

182 182 } /** * Gets the counter local service. * the counter local service */ public CounterLocalService getcounterlocalservice() { return counterlocalservice; } /** * Sets the counter local service. * counterlocalservice the counter local service */ public void setcounterlocalservice(counterlocalservice counterlocalservice) { this.counterlocalservice = counterlocalservice; } /** * Gets the resource local service. * the resource local service */ public ResourceLocalService getresourcelocalservice() { return resourcelocalservice; } /** * Sets the resource local service. * resourcelocalservice the resource local service */ public void setresourcelocalservice( ResourceLocalService resourcelocalservice) { this.resourcelocalservice = resourcelocalservice; } /** * Gets the resource remote service. * the resource remote service */ public ResourceService getresourceservice() { return resourceservice; } /** * Sets the resource remote service. * resourceservice the resource remote service */ public void setresourceservice(resourceservice resourceservice) { this.resourceservice = resourceservice; } /** * Gets the resource persistence. * the resource persistence */ public ResourcePersistence getresourcepersistence() { return resourcepersistence; } /** * Sets the resource persistence. *

183 183 resourcepersistence the resource persistence */ public void setresourcepersistence(resourcepersistence resourcepersistence) { this.resourcepersistence = resourcepersistence; } /** * Gets the user local service. * the user local service */ public UserLocalService getuserlocalservice() { return userlocalservice; } /** * Sets the user local service. * userlocalservice the user local service */ public void setuserlocalservice(userlocalservice userlocalservice) { this.userlocalservice = userlocalservice; } /** * Gets the user remote service. * the user remote service */ public UserService getuserservice() { return userservice; } /** * Sets the user remote service. * userservice the user remote service */ public void setuserservice(userservice userservice) { this.userservice = userservice; } /** * Gets the user persistence. * the user persistence */ public UserPersistence getuserpersistence() { return userpersistence; } /** * Sets the user persistence. * userpersistence the user persistence */ public void setuserpersistence(userpersistence userpersistence) { this.userpersistence = userpersistence; } /** * Performs an SQL query. * sql the sql query to perform */ protected void runsql(string sql) throws SystemException { try { DataSource datasource = wcpsalonpersistence.getdatasource();

184 184 SqlUpdate sqlupdate = SqlUpdateFactoryUtil.getSqlUpdate(dataSource, sql, new int[0]); } sqlupdate.update(); } catch (Exception e) { throw new SystemException(e); } = WCPSalonLocalService.class) protected WCPSalonLocalService = WCPSalonPersistence.class) protected WCPSalonPersistence = CounterLocalService.class) protected CounterLocalService = ResourceLocalService.class) protected ResourceLocalService = ResourceService.class) protected ResourceService = ResourcePersistence.class) protected ResourcePersistence = UserLocalService.class) protected UserLocalService = UserService.class) protected UserService = UserPersistence.class) protected UserPersistence userpersistence; Listado A8.4. Clase WCPSalonLocalServiceBaseImpl

185 185 ANEXO 9. PAPER Uso de metodologías de desarrollo ágil Universidad Técnica Particular de Loja, Ingeniería en Sistemas Informáticos y Computación Ing. Guido Riofrío Calderón Correo-e: geriofrio@utpl.edu.ec Max Geovanny Morillo Aguilar Correo-e: mgmorillo@hotmail.com Resumen.- El desarrollo de software es una tarea compleja, para la cual se han creado un sinnúmero de normas y metodologías para su seguimiento y control, estableciendo en algunos casos verdaderas camisas de fuerza donde el resultado final no necesariamente es el satisfactorio para el cliente. Sin embargo, el mercado actual requiere de soluciones tecnológicas eficientes y rápidas, que se adapten a nuevas propuestas de cambio. Ante este requerimiento de cambio en el mercado, surgen las nuevas metodologías ágiles de desarrollo de software donde se valora más al individuo, a la colaboración con el cliente y al desarrollo incremental de aplicaciones en iteraciones muy pequeñas. Las metodologías ágiles han revolucionado la forma de ver el desarrollo de software, y han sido adaptadas por un sinnúmero de empresas que han logrado grandes desarrollos con aplicaciones que están siendo utilizadas a nivel mundial. En el presente trabajo, se exponen estas metodologías, la comparación con sus pares tradicionales, y se hace un especial énfasis en SCRUM como metodología adoptada por el autor, en el desarrollo de un aplicativo web para monitoreo de niños utilizando un cámara IP en un Centro de Desarrollo Infantil de la ciudad de Quito Ecuador. PALABRAS CLAVE. Procesos de Software, Metodologías Ágiles, SCRUM. I. Introducción En las dos últimas décadas se desarrollaron un sinnúmero de notaciones de modelado así como herramientas que prometían el éxito para el desarrollo del software, pero desafortunadamente para los amantes del desarrollo, esto quedó en nada más que promesas. Conforme han pasado los años, las empresas han requerido cada vez más, la elaboración de software que se adapte al cambiante mundo de los requerimientos. Tal es así que aplicaciones como Facebook, Twitter, Google, etc., empezaron como pequeños proyectos, y en un muy corto tiempo han logrado crear unos verdaderos gigantes de la industria del software, y esto se debió al crecimiento de nuevas tendencias en lo que a metodología de desarrollo se refiere. Estas tendencias llamadas Ágiles, no son nada más que metodologías que se adaptan a los cambios cada vez más exigentes del mercado, y explotan de manera rápida el resultado de un producto. En la actualidad, existen algunas metodologías ágiles, las cuales han logrado ajustarse a la dinámica del mercado, el cual obliga a la obtención de resultados rápidos, buenos y baratos, a diferencia de las metodologías tradicionales, que han sido consideradas como burocráticas y pesadas (ej. CMMI 28, SPICE 29, etc.). Entre las metodologías ágiles más relevantes está SCRUM [1], la cual no solo ha sido adoptada para el desarrollo de proyectos de software, sino también como parte de elaboración y seguimiento de proyectos, para empresas de todo tipo. Este artículo está organizado de la siguiente manera. En la sección 2, se indican las principales características de las metodologías ágiles, las cuales son recopiladas en el CMMI..- siglas de Capability Maturity Model Integration. SPICE.- de sus siglas en inglés Software Process Improvement Capability Determination. Estándar ISO/IEC

186 186 manifiesto ágil. También se establecerá las diferencias con las metodologías tradicionales de desarrollo de software, y una descripción de SCRUM como metodología adoptada. II. Estado del Arte A. METODOLOGÍAS ÁGILES DE DESARROLLO DE SOFTWARE. En marzo de 2001 en Estados Unidos, se reúnen 17 expertos de los modelos de mejora del desarrollo de software, con la finalidad de tratar sobre nuevas técnicas y procesos para el desarrollo de software. Aquí nace por primera vez el término Agil, el cual se contrapone al sistema rígido de elaboración tradicional de programas. El objetivo principal de este grupo fue esbozar los valores y principios que deberían permitir a los equipos desarrollar software rápidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto. Es así que se creó la Agile Alliance 30, organización sin fines de lucro, cuyo objetivo fue la ayuda a las organizaciones para que adopten la nueva filosofía ágil, definida en un compendio llamado Manifiesto Ágil 31. B. MANIFIESTO ÁGIL. El manifiesto ágil muestra una serie de valores, los cuales se recopilaron en cuatro grupos y que hacen énfasis en lo siguiente: A los individuos y su interacción, por encima de los procesos y las herramientas. Donde, las personas son el principal factor de éxito de un proyecto. Esto implica que es más importante armar un buen equipo que construir el entorno, donde la mayoría de veces se comete el error de construir primero el entorno y luego se espera que el equipo se adapte sin ningún tipo de consideración de las repercusiones. El software que funciona, por encima de la documentación exhaustiva. La mayoría de veces se pretende seguir estrictamente documentaciones, por lo que este valor objeta esa rigidez y pondera la no elaboración de documentos a menos que sean necesarios de forma inmediata para tomar una decisión importante agilemanifesto.org La colaboración con el cliente, por encima de la negociación contractual. Esto implica una interacción constante entre el cliente y el equipo de desarrollo. Esta colaboración es sumamente importante para la marcha del proyecto y su éxito. La respuesta al cambio, por encima del seguimiento de un plan. Se refiera a la respuesta a los cambios que puedan surgir a en un proyecto (ej. los requisitos, tecnología, equipo, etc.), que incidirá en el éxito o fracaso del mismo. En este caso la planificación no debe ser estricta sino flexible y abierta. De los valores anteriormente citados, se desprenden doce principios que caracterizan a una metodología ágil de una tradicional. Estos principios[8] son: I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software que le aporte un valor. II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una ventaja competitiva. III. Entregar frecuentemente software que funcione desde un par de semanas a un par de meses, con el menor intervalo de tiempo posible entre entregas. IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto. V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que necesitan y confiar en ellos para conseguir finalizar el trabajo. VI. El diálogo cara a cara es el método más eficiente y efectivo para comunicar información dentro de un equipo de desarrollo. VII. El software que funciona es la medida principal de progreso. VIII. Los procesos ágiles promueven un desarrollo sostenible. Los promotores, desarrolladores y usuarios deberían ser capaces de mantener una paz constante. IX. La atención continua a la calidad técnica y al buen diseño mejora la agilidad. X. La simplicidad es esencial. XI. Las mejores arquitecturas, requisitos y diseños surgen de los equipos organizados por sí mismos. XII. En intervalos regulares, el equipo reflexiona respecto a cómo llegar a ser más efectivo, y según esto ajusta su comportamiento. COMPARACIÓN DE METODOLOGÍAS TRADICIONALES Y ÁGILES. En el siguiente cuadro (Tabla 1. Cuadro comparativo de metodologías [8]), se establece una diferenciación entre las metodologías ágiles y tradicionales, no solo desde el punto

187 187 de vista del proceso, sino también respecto al capital humano que está involucrado. Metodologías Metodologías Ágiles Tradicionales Basadas en heurísticas provenientes Basadas en normas provenientes de de prácticas de producción de estándares seguidos por el entorno código de desarrollo La metodología SCRUM, maneja un proceso iterativo e incremental para el desarrollo de proyectos, productos y aplicaciones que no solo se enfoca en productos de software. Está compuesto de ciclos de trabajo llamados Sprints que son iteraciones de 1 a 4 semanas, que se van ejecutando una tras otra. Los Sprints tienen una duración fija (terminan en una fecha específica aunque no se haya terminado el trabajo), y nunca se alargan, es decir hay una limitante en tiempo. Especialmente preparados para cambios durante el proyecto Impuestas internamente (por el equipo) Proceso menos controlado, con pocos principios No existe contrato tradicional o al menos es bastante flexible El cliente es parte del equipo de desarrollo Grupos pequeños (<10 integrantes) y trabajando en el mismo sitio Pocos artefactos Pocos roles Menos énfasis en la arquitectura del software Cierta resistencia a los cambios Impuestas externamente Proceso mucho más controlado, con numerosas políticas/normas Existe un contrato prefijado El cliente interactúa con el equipo de desarrollo mediante reuniones Grupos grandes y posiblemente distribuidos Más artefactos Más roles La arquitectura del software es esencial y se expresa mediante modelos Al comienzo de cada sprint, un equipo multi-funcional selecciona los elementos (requisitos del cliente) de una lista priorizada. Se comprometen a terminar los elementos al final del Sprint. Durante el Sprint no se pueden cambiar los elementos elegidos. Todos los días el equipo se reúne brevemente para informar del progreso, y actualizan unas gráficas sencillas que les orientan sobre el trabajo restante. Al final del Sprint, el equipo revisa el Sprint con los interesados en el proyecto, y les enseña lo que han construido. La gente obtiene comentarios y observaciones que se puede incorporar al siguiente Sprint. Scrum pone el énfasis en productos que funcionen al final del Sprint que realmente estén hechos ; en el caso del software significa que el código esté integrado, completamente probado y potencialmente para entregar. Tabla 1. Cuadro comparativo de metodologías C. SCRUM COMO METODOLOGÍA DE DESARROLLO ÁGIL. SCRUM nació en 1986 con Hirotaka Takeuchi e Ikujiro Nonaka, como un proyecto para mejorar la flexibilidad y rapidez en el desarrollo de productos comerciales. Posteriormente en 1991 Peter DeGrace y Leslie Stahl, utilizaron por primera vez el término Scrum, para luego en 1995 por intermedio de Schwaber y Sutherland utilizar públicamente el término conjuntamente con las mejores prácticas de la industria. Finalmente en 2001, Schwaber y Mike Beedle describieron la metodología completa en el libro Agile Software Development with Scrum (Desarrollo Ágil de Software con SCRUM). SCRUM al ser una metodología ágil de desarrollo, tipo transversal, se entiende que es apropiado para equipos de trabajo o de desarrollo (como recomendación hasta máximo grupos de 8 personas). I. Proceso y conceptos manejados en SCRUM Tomando en cuenta el proceso descrito anteriormente, a continuación se detallan los diferentes elementos que contempla la metodología, así: Product Backlog (Pila de producto): documento en el cual se detallan, de forma priorizada, los requisitos del sistema. Sprint (Iteración): cada una de las iteraciones de que se compone el desarrollo con Scrum. Si existe razón de suficiente peso, puede abortarse el sprint y comenzar uno nuevo. Sprint Backlog: trozo de backlog que nos comprometemos a implementar de forma satisfactoria en el sprint (iteración) actual. ScrumMaster: que mantiene los procesos y trabaja de forma similar al director de proyecto. ProductOwner (Dueño del producto): que representa a los stakeholders (clientes externos o internos). Team (Grupo): que incluye a los desarrolladores. Burndown Chart: Es una gráfica que muestra las funcionalidades pendientes del proyecto al comienzo de cada Sprint y demuestra el avance en función del tiempo para así poder manejar el

188 188 proyecto. Este modelo se lo usa en lugar de un diagrama de PERT. Los diferentes roles, artefactos y eventos principales se muestran en la Figura 1 (Proceso SCRUM). Figura 1. Proceso SCRUM [7] D. OTRAS METODOLOGÍAS ÁGILES. Si bien es cierto que los principios y valores propuestos en el manifiesto ágiles son universales, eso no implica que todas las metodologías ágiles creadas tengan iguales componentes, por lo que cada una de ellas tiene sus propias características. A continuación se detalla las otras metodologías y sus propias particularidades: Xtreme Programming (XP) [2], metodología desarrollada por Kent Beck, que es quien hizo la primera diferenciación con las metodologías tradicionales, principalmente porque pone más énfasis en la adaptabilidad que en la previsibilidad. Crystal Methodologies [3]. Conjunto de metodologías para el desarrollo de software creadas por Alistair Cockburn. Se centra en las personas que componen el equipo y la máxima reducción del número de artefactos producidos. El equipo de desarrollo es un factor clave, por lo que se deben invertir esfuerzos en mejorar sus habilidades y destrezas, así como tener políticas de trabajo en equipo claramente definidas. Dynamic Systems Development Method (DSDM) [4]. Creada en 1994 con el objetivo de crear una metodología RAD 32 unificada. Sus principales características son: proceso iterativo e incremental y trabajo conjunto del equipo de desarrollo y el usuario. Contiene cinco fases: estudio viabilidad, 32 RAD. del inglés Rapid Application Development. estudio del negocio, modelado funcional, diseño y construcción, e implementación. Las tres últimas son iterativas, además de existir retroalimentación a todas las fases. Adaptive Software Development (ASD) [5]. (Jim Highsmith). Metodología que tiene como características: ser iterativo, orientado a los componentes software más que a las tareas y tolerante a los cambios. El ciclo de vida consta de tres fases: especulación, colaboración y aprendizaje. En la primera se inicia el proyecto y se planifican las características del software; en la segunda se desarrollan las características y finalmente en la tercera se revisa su calidad, y se entrega al cliente. La revisión de los componentes sirve para aprender de los errores y volver a iniciar el ciclo de desarrollo. Feature Driven Development (FDD) [6]. (Jeff De Luca y Peter Coad). Proceso iterativo que consta de 5 pasos, con ciclos cortos (hasta 2 semanas). Se centra en las fases de diseño e implementación del sistema, partiendo de una lista de características del software a crear. Lean Development (LD). Creada por Bob Charettes, a partir de su experiencia en proyectos con la industria automotriz japonesa (años 80) y utilizada en numerosos proyectos de telecomunicaciones en Europa. En esta metodología los cambios que se consideran riesgos, pueden traducirse en oportunidades, con un manejo adecuado, que mejoren la productividad del cliente. Su principal característica es introducir un mecanismo para implementar dichos cambios. III. APLICACIÓN DE LA METODOLOGÍA EN DESARROLLO DE TESIS. Tomando en cuenta las diferentes metodologías ágiles de desarrollo de software, se adoptó SCRUM porque posee características más flexibles cuando existen cambios o incorporación de nuevas funcionalidades a un proyecto. Adicionalmente, se adapta fácilmente al curso normal del desarrollo de aplicaciones en la actualidad, especialmente a tecnologías orientadas a la Web, donde metodologías tradicionales no arrojan resultados esperados.