Desarrollo de un sistema de videoconferencia en HTML 5.0

Trabajo Fin de Grado Escuela de Ingeniería Informática Universidad de Las Palmas de Gran Canaria Desarrollo de un sistema de videoconferencia en HTML 5.0 Autor: José Alberto Jinoria Fernández Tutor: Javier Sánchez Pérez Las Palmas de Gran Canaria Diciembre 2013 Trabajo Fin de Grado realizado en la Escuela de Ingeniería Informática de la Universidad de Las Palmas de Gran Canaria, para la consecución del título de Ingeniero Informático. Título: Desarrollo de un sistema de videoconferencia en HTML 5.0 Alumno: José Alberto Jinoria Fernández Tutor: Javier Sánchez Pérez Fecha: Diciembre, 2013 Este un proyecto sin ánimo de lucro basado en la plataforma de software libre WebRTC y HTML5.0. Agradecimientos A mi familia, por saberme guiar en la vida por el camino correcto y haberse sacrificado mucho, siempre pensando en mi porvenir. A mis profesores, en especial a José Juan Hernández y a mi tutor Javier Sánchez por su ayuda en muestra de formación como profesional. A mis amigos, en especial a Dariel Rodríguez y Daniel Ocaña. A la Universidad de Las Palmas, por haberme acogido como estudiante y formado hasta la culminación de mis estudios. Índice general Prefacio ......................................................................................................................................... 8 1 Introducción .......................................................................................................................... 9 1.1 Motivación y objetivos .................................................................................................. 9 1.2 Objeto de estudio .......................................................................................................... 9 1.3 Campo de acción ........................................................................................................... 9 1.4 Hipótesis ...................................................................................................................... 10 1.5 Aportaciones ............................................................................................................... 10 1.6 Organización del documento ...................................................................................... 10 2 Estado actual del arte .......................................................................................................... 12 2.1 WebRTC ....................................................................................................................... 12 2.1.1 Historia ................................................................................................................ 12 2.1.2 Definición ............................................................................................................ 12 2.1.3 Diseño .................................................................................................................. 12 2.2 Sistemas de videoconferencias más usados a nivel mundial ...................................... 13 2.2.1 Skype ................................................................................................................... 13 2.2.2 Google Hangouts ................................................................................................. 14 3 Recursos utilizados .............................................................................................................. 15 3.1 Recursos software ....................................................................................................... 15 3.1.1 Herramientas ....................................................................................................... 15 3.1.2 Lenguajes de programación ................................................................................ 16 3.2 Recursos hardware ...................................................................................................... 16 3.2.1 Hardware de los clientes ..................................................................................... 17 3.2.2 Hardware de los servidores ................................................................................. 17 4 Planificación del trabajo ...................................................................................................... 18 4.1 Metodología de desarrollo .......................................................................................... 18 4.2 Planificación y temporización ..................................................................................... 20 4.3 Presupuesto ................................................................................................................ 21 4.3.1 Coste del hardware ............................................................................................. 21 4.3.2 Coste del software............................................................................................... 21 4.3.3 Coste del personal ............................................................................................... 22 4.3.4 Presupuesto total del proyecto ........................................................................... 22 5 Desarrollo del trabajo.......................................................................................................... 23 5.1 Modelo del dominio .................................................................................................... 23 5.2 Lista de características ................................................................................................ 24 5.3 Requisitos del software ............................................................................................... 28 5.3.1 Actores ................................................................................................................ 28 5.3.2 Modelo de casos de uso ...................................................................................... 28 5.3.3 Especificación de casos de uso ............................................................................ 31 5.3.4 Prototipos de interfaz de usuario ........................................................................ 35 5.4 Modelo de análisis ...................................................................................................... 41 5.4.1 Diagrama de clases .............................................................................................. 41 5.4.2 Diagramas de colaboración ................................................................................. 47 5.5 Modelo de diseño........................................................................................................ 53 5.5.1 Arquitectura del sistema ..................................................................................... 53 5.5.2 Diagramas de clases ............................................................................................ 54 5.5.3 Diagramas de secuencia ...................................................................................... 62 5.6 Implementación .......................................................................................................... 70 5.6.1 Primeros pasos con CMS Elgg.............................................................................. 70 5.6.2 Lo más importante está por llegar. WebRTC y HTML5 ....................................... 71 5.6.3 Integrar las dos aplicaciones para que parezcan una ......................................... 71 5.7 Pruebas ........................................................................................................................ 72 6 Conclusiones y trabajo futuro ............................................................................................. 74 Anexo I: Competencias ................................................................................................................ 75 Anexo II: Legislación vigente ....................................................................................................... 77 Anexo III: Manual de usuario ...................................................................................................... 79 Anexo IV: Entorno de Desarrollo ................................................................................................. 84 Bibliografía .................................................................................................................................. 91 8 Prefacio El documento expone un trabajo de fin grado de la carrera Grado en Ingeniería Informática, el cual tiene como objetivo desarrollar un sistema de videoconferencias a través de HTML5.0. Con este trabajo se pretende ampliar el uso de la web 2.0, la democratización de las comunicaciones, y lograr que los usuarios puedan comunicarse de una forma completamente libre, sin necesidad de instalación o actualización de software de terceros. Basado en la metodología expuesta en el Proceso Unificado de Desarrollo de Software (PUD), se siguen todos sus procesos y flujos de trabajo, generando los productos y utilizando las técnicas y herramientas que proporciona la misma. Se escoge el CMS1 Elgg con el objetivo de lograr el comportamiento de una red social donde los usuarios puedan interactuar entre sí, libremente y con mayor usabilidad. También se muestra la configuración del servidor web Node.js y de uno de sus módulos, socket.io, como herramienta de ayuda al navegador para lograr la señalización. Además se hace uso de las APIs2 de webRTC y de los elementos que brinda HTML5 para desarrollar el sistema de videollamadas. 1 Sistema de gestión de contenidos. 2 Interfaz de programación de aplicaciones. 9 1 Introducción Una videoconferencia es una conexión multimedia entre dos o más personas que pueden verse, oírse e intercambiar recursos aunque estén separadas geográficamente. Su uso posibilita la realización de reuniones con grupos de personas situadas en lugares alejados entre sí, permitiendo el intercambio de información gráfica, transferencias de archivos, de vídeo, de voz, hacer presentaciones, servicio de atención al cliente, etc. Las videoconferencias basan su eje tecnológico en la compresión digital de los flujos de audio y video en tiempo real. Su uso ofrece una solución accesible a la necesidad de comunicación. Los sistemas actuales permiten enviar y recibir información visual y sonora entre dos puntos que se encuentran en zonas diferentes, evitando así los gastos y pérdida de tiempo que implica el traslado físico de la persona. (1) Estas ventajas hacen a la videoconferencia el segmento de mayor crecimiento en el área de las telecomunicaciones. 1.1 Motivación y objetivos En la actualidad, las limitaciones técnicas tales como el sonido deficiente, la mala calidad de las imágenes, la poca fiabilidad, la complejidad y el coste han quedado atrás, dando lugar a videoconferencias con alta calidad de audio, video, transferencia de archivos y con un coste accesible a la mayoría de los interesados. (2) Con HTML5.0, aparece la posibilidad de realizar videoconferencias sin la necesidad de instalación de software. Este lenguaje introduce soporte integrado para el contenido multimedia gracias a los elementos de audio y video, ofreciendo la posibilidad de incrustar este tipo de contenido en páginas HTML. El objetivo principal del trabajo es: desarrollar una aplicación multiplataforma de videoconferencias en HTML5.0. Partiendo del mismo se trazaron los siguientes objetivos secundarios:  Utilizar las tecnologías disponibles para el desarrollo de un sistema de comunicación en entorno web.  Lograr una comunicación P2P privada entre dos personas.  Crear una aplicación web que centralice la gestión de las comunicaciones entre los usuarios. 1.2 Objeto de estudio Para la realización de este trabajo se plantea como objeto de estudio:  La utilización de las APIs de WebRTC para el desarrollo de sistemas de comunicación en tiempo real. 1.3 Campo de acción Dentro del objeto de estudio se define como campo de acción:  El desarrollo de sistemas de comunicación con audio y video mediante la integración de las APIs de WebRTC y HTML5. 16 3.1.2 Lenguajes de programación  Javascript Javascript (a veces abreviado como JS) es un lenguaje ligero, interpretado y orientado a objetos, más conocido como el lenguaje script para páginas web. El estándar de JavaScript es ECMAScript. A partir de 2012, todos los navegadores modernos soportan completamente ECMAScript 5.1. Los navegadores más antiguos soportan al menos ECMAScript 3. Una sexta revisión del estándar está en proceso. (12)  HTML5 El lenguaje de marcado de la World Wide Web ha sido siempre HTML. Fue diseñado principalmente para describir semánticamente documentos científicos, sin embargo, su diseño general y adaptaciones en los últimos años han permitido que sea utilizado para representar otros tipos de documentos. En 2006, el W3C manifestó su interés de participar en el desarrollo de HTML5 y en 2007 formó un grupo de trabajo para desarrollar la especificación HTML5.0. Apple, Mozilla y Opera permitieron que W3C publicara la especificación bajo el copyright W3C, manteniendo una versión con licencia menos restrictiva en el sitio WHATWG. Esta nueva especificación incorpora interesantes capacidades Javascript, que aumentan la capacidad de almacenamiento frente a las cookies que dejaban recopilar algunos kilobytes. Ahora se puede conseguir un almacenamiento entre 5 y 10 megas, dependiendo de la plataforma. Además, HTML5 permite múltiples Javascripts ejecutándose en paralelo en la misma página, hace posible la inserción de audio y video de forma directa y la geolocalización del usuario. (13)  CSS Hojas de Estilo en Cascada (Cascading Style Sheets), es un mecanismo simple que describe cómo se va a mostrar un documento en la pantalla y la forma en que se va a imprimir. Esta forma de descripción, ofrece a los desarrolladores el control total sobre estilo y formato de sus documentos. CSS se utiliza para dar estilo a documentos HTML y XML, separando el contenido de la presentación. Permite a los desarrolladores controlar el estilo y el formato de múltiples páginas web simultáneamente. Cualquier cambio en el estilo marcado para un elemento en la CSS, afectará a todas las páginas vinculadas a esa CSS en las que aparezca ese elemento. (14)  PHP PHP (Hypertext Preprocessor) es un lenguaje de código abierto muy popular, especialmente adecuado para el desarrollo web y que puede ser incrustado en HTML. Las páginas web que usan PHP se tratan igual que páginas HTML comunes y corrientes, se pueden crear y editar de la misma manera que normalmente se crean páginas HTML. PHP está enfocado principalmente a la programación de scripts del lado del servidor, por lo pueden realizarse funcionalidades incluidas en otros lenguajes de programación, como recopilar datos de formularios, generar páginas con contenidos dinámicos, enviar y recibir cookies; aunque PHP puede hacer mucho más. (15) 3.2 Recursos hardware El proyecto fue desarrollado desde un ordenador personal marca HP G62 con las siguientes características:  Procesador Intel Core i5.  Memoria RAM 4 GB DDR2.  Pantalla de 15,4 pulgadas.  Sistema Operativo: Windows 7 Home Edition. 17 3.2.1 Hardware de los clientes  Ordenador portátil con webcam y micrófono incluido.  Ordenador de sobre mesa con cámara web y micrófono incorporado.  Tarjeta Wifi o Placa de Red Ethernet compatible.  Conexión a internet a través de ADSL o 3G.  Dispositivo móvil con Androide 2.4 o versiones posteriores y cámara frontal. 3.2.2 Hardware de los servidores  Procesador: Pentium 4 o superior.  Memoria RAM: 2 Gb.  Disco Duro: 5GB disponibles.  Placa de Red: Ethernet compatible.  Velocidad de subida y bajada de datos superior a 5mb.  Red LAN que soporte TCP/IP (en general, Internet). 18 4 Planificación del trabajo En este capítulo se aborda la planificación y temporización del trabajo. Se explica la metodología utilizada para realizar el sistema de videoconferencias, la estimación del tiempo de ejecución de las tareas, así como un aproximado del coste para el desarrollo de la aplicación. 4.1 Metodología de desarrollo  Proceso Unificado de Desarrollo (PUD) Es una metodología de desarrollo de software basada en componentes e interfaces bien definidas, que unida al Lenguaje Unificado de Modelado (UML), constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. Es un proceso que puede especializarse para una gran variedad de sistemas de software en diferentes áreas de aplicación, distintos tipos de organizaciones, variados niveles de aptitud y tamaños de proyecto. RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. Es el resultado de varios años de desarrollo y uso práctico, en el que se han unificado técnicas de desarrollo a través de UML y trabajo de muchas metodologías utilizadas por los clientes. La versión que se ha estandarizado vio la luz en 1998 y se conoció en sus inicios como Proceso Unificado de Rational 5.0 (RUP), de ahí las siglas con las que se identifica a este proceso de desarrollo. (16)  Dirigido por Casos de Uso Un caso de uso es un fragmento de funcionalidad del sistema que proporciona un resultado de valor para el usuario. Los casos de uso modelan los requerimientos funcionales del sistema. Todos los casos de uso juntos constituyen el modelo de casos de uso. Los casos de uso también guían el proceso de desarrollo (diseño, implementación y prueba). Basándose en los casos de uso, los desarrolladores crean una serie de modelos de diseño e implementación que llevan a cabo los casos de uso. De este modo, los casos de uso no solo inician el proceso de desarrollo, sino que le proporcionan un hilo conductor que avanza a través de una serie de flujos de trabajo que parten de los casos de uso. (17)  Centrado en la Arquitectura La arquitectura de un sistema software se describe mediante diferentes vistas del sistema en construcción. El concepto de arquitectura software incluye los aspectos estáticos y dinámicos más significativos del sistema. La arquitectura es una vista del diseño completo con las características más importantes resaltadas, dejando los detalles a un lado. Los casos de uso y la arquitectura están profundamente relacionados. Los casos de uso deben encajar en la arquitectura y a su vez la arquitectura debe permitir el desarrollo de todos los casos de uso requeridos, actualmente y en el futuro (17).  Iterativo e Incremental Es práctico dividir el esfuerzo de desarrollo de un proyecto de software en partes más pequeñas o mini proyectos. Cada mini proyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo y los incrementos a crecimientos en el producto. Las iteraciones deben estar controladas, esto significa que deben seleccionarse y ejecutarse de una forma planificada. Los desarrolladores basan la selección de 19 lo que implementarán en cada iteración en dos cosas: el conjunto de casos de uso que amplían la funcionalidad y los riesgos más importantes que deben mitigarse. En cada iteración los desarrolladores identifican y especifican los casos de uso relevantes, crean un diseño utilizando la arquitectura seleccionada como guía para implementar dichos casos de uso. Si la iteración cumple sus objetivos, se continúa con la próxima, si no deben revisarse las decisiones previas y probar un nuevo enfoque. (17)  Ciclo de Vida El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo constituye una versión del sistema.  Fases Cada ciclo constas de cuatro fases: Inicio, Elaboración, Construcción y Transición. Cada fase se subdivide en iteraciones. En cada iteración se desarrolla en secuencia un conjunto de disciplinas o flujos de trabajos.  Disciplinas Cada disciplina es un conjunto de actividades relacionadas (flujos de trabajo) vinculadas a un área específica dentro del proyecto total. Las más importantes son: Requerimientos, Análisis, Diseño, Codificación y Prueba. El agrupamiento de actividades en disciplinas es principalmente una ayuda para comprender el proyecto desde la visión tradicional en cascada (17)(ver Ilustración 6). Ilustración 6: Fases, iteraciones y disciplinas. Cada disciplina está asociada con un conjunto de modelos que se desarrollan. Estos modelos están compuestos por artefactos. Los artefactos más importantes son los modelos que cada disciplina realiza: Modelo de Casos de Uso, Modelo de Diseño, Modelo de Implementación y Modelo de Prueba (17) (ver Ilustración 7). 20 Ilustración 7: Modelos por disciplinas. 4.2 Planificación y temporización En este apartado se detallan las horas empleadas para la realización del trabajo, siguiendo las cuatro fases que plantea el Proceso Unificado de Desarrollo de Software, así como las horas específicas para cada flujo de trabajo en cada fase(ver Tabla 1). FASES HORAS INICIO 60H Requerimientos 10H Análisis y Diseño 50H Codificación 0H Pruebas 0H ELABORACIÓN 85H Requerimientos 10H Análisis y Diseño 45H Codificación 30H Pruebas 5H CONSTRUCCIÓN 140H Requerimientos 0H Análisis y Diseño 25H Codificación 105H 21 Pruebas 10H TRANSICIÓN 45H Requerimientos 5H Análisis y Diseño 10H Codificación 25H Pruebas 5H Total 335H Tabla 1: Planificación por fases y flujos. 4.3 Presupuesto A continuación se detalla el presupuesto para efectuar el proyecto. Se destacan los elementos necesarios para la realización del mismo, así como el coste estimado para cada uno de ellos.  Coste del hardware Es el coste correspondiente a los equipos utilizados.  Coste del software Gastos derivados de la utilización de las herramientas empleadas para la realización del proyecto.  Coste del personal Gastos correspondientes a la remuneración de las personas que desarrollan el proyecto. 4.3.1 Coste del hardware Para este proyecto se tienen en cuenta los siguientes elementos de hardware para su desarrollo (ver Tabla 2). Elemento Coste Ordenador Portátil HP G62 450€ Servicio de Internet ADSL 160€ Servidores de hosting Gratuito Total Hardware 610€ Tabla 2: Desglose de los costes de hardware. 4.3.2 Coste del software El coste de los siguientes elementos es el correspondiente a la licencia de los mismos (ver Tabla 3). 22 Elemento Coste Windows 7 Professional 160€ Microsoft Office 2007 130€ Total Software 290€ Tabla 3: Desglose de los costes de software. 4.3.3 Coste del personal En la siguiente tabla se enumeran los trabajadores que intervienen en el desarrollo del proyecto, así como el número de horas estimadas para cada uno de ellos, el coste por hora y el coste total (ver Tabla 4). Personal Nº Horas Coste / H Coste Jefe de proyecto 20H 40€ 800€ Arquitecto 65H 35€ 2275€ Analista 50H 20€ 1000€ Programador 150H 20€ 3000€ Ingeniero de pruebas 15H 20€ 300€ Total 300H - 7375€ Tabla 4: Desglose de los costes del personal. 4.3.4 Presupuesto total del proyecto La siguiente tabla muestra un desglose de los costes calculados anteriormente y el coste total que representa el desarrollo del proyecto (ver Tabla 5). Elemento Coste Coste del hardware 610€ Coste del software 290€ Coste del personal 7375€ Total 8275€ Tabla 5: Desglose de los costes. 23 5 Desarrollo del trabajo 5.1 Modelo del dominio Un modelo del dominio se utiliza como fuente para el diseño de los objetos software y corresponde a una entrada necesaria para varios artefactos. El modelo del dominio muestra (a los modeladores) clases conceptuales significativas en un dominio del problema, es el artefacto más importante que se crea durante el análisis orientado a objetos. Un modelo del dominio es una representación de las clases conceptuales del mundo real, no de componentes software. No se trata de un conjunto de diagramas que describen clases u objetos software con responsabilidades. (18)  Webcam App Webcam App es una aplicación que tiene como principal objetivo social que las personas puedan realizar videoconferencias a través de la web de una forma gratuita y sencilla. Cuando un usuario se registra en Webcam App facilita su nombre, correo electrónico, entre otros datos. También, el usuario puede añadir una foto de perfil para que sus amigos puedan identificarlo fácilmente entre los miembros de la aplicación. Una vez registrado, el usuario puede proporcionar otra información relacionada, por ejemplo su ciudad de residencia, redes, actividades, intereses y lugares. También puede buscar a sus amigos sólo con introducir su nombre y agregarlos como amigos en Webcam App, con el fin de poder comunicarse y compartir sus datos con ellos. Otras de las finalidades principales del uso de Webcam App es compartir contenido con los demás, por ejemplo cargar o hacer una foto, cargar o grabar un video, compartir un enlace, crear un grupo, hacer un comentario, escribir una nota o enviar un mensaje. Parte del contenido que se comparte y de las acciones que se llevan a cabo se muestran en la página de actividades. Además, se puede limitar las personas que pueden ver los datos personales desde la configuración de privacidad (ver Ilustración 8). Ilustración 8: Modelo del dominio. Videocall -caller -callee User -username -profile_photo -e-mail -city -skills -interests Video -duration Message -content -sender -recipient Group -members make 1 1..* send 1..* 1 contain * * send 1..* 1 Publications Photo Comments is a type of is a type of publish 1..* 1 friendship 1 1..* 24 5.2 Lista de características En esta sección se detalla la lista de características asociada a la aplicación Webcam App. La misma es un artefacto que se obtiene después de aplicar la tarea de “Enumerar los requisitos candidatos”, que se propone en la metodología del PUD (Proceso Unificado de Desarrollo), para la captura de requisitos. Esta lista contiene las ideas de clientes, usuarios, analistas y desarrolladores sobre posibles aspectos a incluir en la aplicación, que posteriormente se pueden traducir en requisitos del software. Estas ideas se consideran requisitos candidatos a desarrollar en la versión actual del sistema o se pueden postergar a versiones futuras.  Tipos de Usuarios La clasificación de los usuarios es una primera aproximación para identificar y asociar a cada uno de los posibles usuarios, los tipos identificados no necesariamente tienen que ser los usuarios definitivos.  Anónimo: Es el usuario que no está registrado y va a utilizar las funcionalidades básicas de navegación, como por ejemplo registrarse, sin opción a modificar el entorno.  Registrado: Es el usuario más común, además de las funciones del usuario anterior puede acceder a la mayoría de las funcionalidades de la aplicación, añadir amigo, enviar mensajes, hacer videollamadas, eliminar amigo, agregar contenido, gestionar perfil, configurar privacidad, etc.  Administrador: Este usuario puede acceder a todas las funcionalidades de la aplicación, entre las suyas propias están: bloquear cuentas de usuarios, eliminar cuentas de usuario, hacer a un usuario administrador, restablecer el password a los usuarios. Para describir las características, se utiliza una tabla con los siguientes campos (ver Tabla6):  Código: Es el identificador de la característica. Se especifica como LC + identificador del usuario + número de la característica.  Identificadores para cada tipo de usuario de la aplicación  R. Usuario Registrado.  A. Usuario Anónimo.  AD. Usuario Administrador.  Nombre: Nombre de la característica.  Descripción: Breve descripción de lo que comprende la característica.  Prioridad: Se asigna una prioridad a cada característica con el fin de determinar el orden en que se van a ir desarrollando. Las prioridades que se usan están definidas por un valor numérico, que representa el nivel de prioridad, donde 0 es la más baja y 100 la más alta, luego están los rangos que se muestran a continuación:  80-100 (Muy alta)  60-80 (Alta)  40-60 (Media)  20-40 (Baja)  0-20 (Muy baja)  Estado: Cada característica tiene un estado asociado que va variando a medida que progresa el sistema. Los posibles estados son:  Aceptado: La característica se desarrollará en esta versión del producto.  Planificada: La característica ya ha sido planificada y se empezará a desarrollar en un plazo de tiempo corto.  En desarrollo: Ya se está desarrollando.  Finalizada: Se ha terminado de desarrollar. 25  Postergada: No se desarrollará hasta una versión futura.  Rechazada: Probablemente no se desarrollará en ninguna versión. Código Nombre Descripción Prioridad Estado LC-A.1 Registrar Usuario La aplicación permitirá al usuario introducir sus datos personales para registrarse. 99 Finalizada LC-R.1 Buscar Amigo La aplicación permitirá a cualquier usuario introducir el nombre de una persona y mostrará los resultados de la búsqueda. 97 Finalizada LC-R.2 Crear Perfil Un usuario que se ha registrado puede introducir otros datos personales específicos que pueden variar como: (dirección de correo electrónico, localidad, etc.) 96 Finalizada LC-R.3 Gestionar Perfil Un usuario registrado puede modificar los datos personales introducidos en la información del perfil. 96 Finalizada LC-R.4 Hacer Login Se permitirá al usuario ya registrado introducir su dirección de correo o nombre de usuario y contraseña para identificarse en la aplicación. 99 Finalizada LC-R.5 Añadir Amigo Se permitirá al usuario registrado agregar una persona que esté registrada como amigo. 90 Finalizada LC-R.6 Eliminar Amigo Se permitirá al usuario registrado eliminar una persona de su lista de amigos. 90 Finalizada LC-R.7 Enviar Mensajes Un usuario registrado podrá enviar mensajes a cualquier persona que está registrada en la aplicación. 85 Finalizada LC-R.8 Reportar Un usuario registrado podrá reportar cualquier 75 Finalizada 32 con el nombre introducido. Flujo normal 1. El usuario introduce el nombre de la persona que desea encontrar. 2. La aplicación muestra un listado de los contactos que están dados de alta en Webcam App con ese nombre. 3. Webcam App ofrece la posibilidad de agregarlos como “Amigos”. Flujo alternativo 3.1. El usuario puede omitir la opción de enviar una invitación de amistad a los usuarios encontrados. Caso de Uso Eliminar Cuenta de Usuario Actor Usuario Administrador Precondición 1. Tiene que existir una o varias denuncias previas en contra del usuario y que se haya comprobado por los administradores de Webcam App que infringe las normas de uso de la aplicación. Post condición 1. Quedará eliminada permanentemente la cuenta de usuario. 2. Se elimina el usuario del listado de amigos y los grupos a los que la cuenta estaba asociada. Flujo normal 1. Si existen varias denuncias sobre un mismo perfil de usuario de la aplicación, el administrador puede decidir si el mismo es un posible usuario a eliminar, señalizando el nombre del usuario y la dirección de su perfil. 2. El administrador revisa los motivos de la denuncia. 3. El administrador pasa a eliminar la cuenta de usuario permanentemente. Flujo alternativo 3.1. El administrador considera que las causas de las denuncias no proceden para eliminar la cuenta de usuario y de esta forma puede retirar la alerta generada. Caso de Uso Compartir Contenido Actor Usuario Registrado Precondición 1. El usuario debe estar identificado en el sistema. Post condición 1. El contenido queda almacenado y asociado al perfil del usuario. 2. El perfil del usuario queda actualizado. Flujo normal 1. El sistema muestra el formulario asociado para subir el contenido. 2. El usuario introduce el contenido, así como un título o una descripción si así lo desea, además de elegir el nivel de seguridad que desea para su contenido. 33 3. El usuario decide las personas con las que desea compartir el contenido. 4. El contenido queda publicado en la sección de archivos. 5. El sistema valida y reconoce el tipo de contenido. La información se almacena en el servidor. Flujo alternativo 5.1. El sistema detecta que la cuota límite del usuario está completa y rechaza la petición de publicar el contenido. Caso de Uso Eliminar Contenido Actor Usuario Registrado Precondición 1. El usuario debe estar identificado en el sistema. Post condición 1. El contenido queda eliminado y desvinculado al perfil del usuario. 2. El perfil del usuario queda actualizado. Flujo normal 1. El usuario selecciona el contenido a eliminar. 2. El sistema verifica que el contenido se quiere eliminar realmente. 3. El contenido se elimina del servidor. Flujo alternativo 2.1. El usuario no confirma la eliminación del contenido. 3.1. El contenido se mantiene alojado en el servidor. Caso de Uso Gestionar Perfil Actor Usuario Registrado Precondición 1. El usuario debe estar identificado en el sistema Post condición 1. Los datos del perfil del usuario de Webcam App quedan modificados. 2. El perfil del usuario de Webcam App queda actualizado. Flujo normal 1. El sistema muestra toda la información relacionada con el perfil del usuario. 2. El usuario selecciona la opción de modificar los datos personales. 3. El sistema muestra un formulario asociado a la información de perfil que se desea editar. 4. El usuario edita los campos de la información que desea modificar. 5. El sistema valida que la nueva información es correcta. 6. El sistema almacena la nueva información en el servidor. Flujo alternativo 5.1 En el caso que algún campo obligatorio no sea rellenado, el sistema mostrará un error y mantendrá el campo con el valor 34 anterior. 6.1 El sistema no actualizará la información de dicho campo en el servidor. Caso de Uso Realizar Videollamada Actor Usuario Registrado Precondición 1. El usuario debe estar identificado en el sistema. Post condición 1. La videollamada quedará realizada. Flujo normal 1. El usuario selecciona el amigo al cual desea hacerle una videollamada. 2. El usuario envía la solicitud a su amigo para ambos realizar una videollamada. 3. El sistema muestra un cuadro de diálogo para que el usuario que esté siendo llamado acepte la videollamada. 4. El usuario acepta la solicitud de videollamada. 5. La videollamada queda establecida entre los dos usuarios. Flujo alternativo 4.1. El usuario amigo rechaza la solicitud de videollamda que le están realizando. 5.1. La solicitud queda eliminada. Caso de Uso Login Actor Usuario Registrado Precondición 1. El usuario debe haberse registrado con anterioridad. Post condición 1. El usuario quedará identificado en el sistema. Flujo normal 1. El sistema muestra los campos para hacer el Login en la aplicación. 2. El usuario rellena los campos con los datos que proporcionó en el registro. 3. El sistema valida los datos y muestra la página del perfil. Flujo alternativo 3.1. La aplicación pedirá al usuario que intente introducir sus datos nuevamente si no fueron introducidos correctamente. 35 5.3.4 Prototipos de interfaz de usuario  Caso de Uso Registrarse Para Registrarse el usuario debe introducir información básica con los campos que aparecen a continuación, luego podrá ampliar la información si lo desea (ver Ilustración 15). Ilustración 15: Interfaz para registrarse.  Caso de Uso Buscar Amigo Para el caso de uso Buscar Amigo el usuario podrá localizar a sus amigos registrados en la aplicación a través de su nombre (ver Ilustración 16). Ilustración 16: Interfaz de búsqueda de amigo. Una vez introducido el nombre del amigo que se desea encontrar, la aplicación mostrará un listado con las personas las cuales su nombre coincide con el criterio de búsqueda, además la aplicación dará la opción de agregarlo como amigo en Webcam App (ver Ilustración 17). 36 Ilustración 17: Interfaz para agregar un amigo.  Caso de uso Eliminar Cuenta de Usuario Cuando el administrador recibe una denuncia sobre el perfil de algún usuario, revisa los motivos del reporte. Si verdaderamente el usuario denunciado incumple las normas de uso del sitio, el administrador puede eliminar permanentemente su cuenta, de otro modo si es un reporte incorrecto, puede eliminar el reporte o simplemente archivarlo (ver Ilustración 18 y 19). Ilustración 18: Interfaz de reporte de infracción. Ilustración 19: Interfaz de eliminar usuario. 37  Caso de Uso Agregar Contenido Cuando el usuario decide compartir algún tipo de contenido, se muestra el siguiente formulario (ver Ilustración 20). Ilustración 20: Interfaz para agregar contenido. Una vez seleccionado el contenido a publicar, queda almacenado y asociado al perfil del usuario que lo agregó (ver Ilustración 21). Ilustración 21: Interfaz del contenido ya agregado. 38  Caso de Uso Eliminar Contenido Ilustración 22: Interfaz para eliminar contenido. Cuando el usuario decide eliminar el contenido el sistema muestra un mensaje de confirmación (ver Ilustración 23 y 24). Ilustración 23: Interfaz de mensaje de confirmación de eliminación de contenido. Una vez confirmado, el contenido queda eliminado permanentemente. Ilustración 24: Interfaz que muestra el contenido ya eliminado.  Caso de Uso Gestionar Perfil Cuando el usuario decide gestionar su perfil, se muestra un formulario con todos los campos que tiene acceso a modificar, tales como su Nombre, Localidad, Número de Teléfono, etc. (ver Ilustración 25 y 26). 39 Ilustración 25: Interfaz del perfil del usuario creado. Ilustración 26: Interfaz para editar el perfil del usuario.  Caso de Uso Login Al visitar el sitio, el sistema muestra un formulario para que el usuario pueda identificarse en el mismo y de esta forma acceder a las principales funcionalidades de la aplicación (ver Ilustración 27). Ilustración 27: Interfaz de formulario de Login. 40  Caso de Uso Realizar Videollamada. Para el caso de uso realizar videollamada, se han definido dos prototipos de interfaz para realizar la misma acción, el primer prototipo sería desde el perfil del usuario que desea realizar la videollamada, desplegar el menú de opciones que tiene para cada amigo de su listado (ver Ilustración 28). Ilustración 28: Interfaz para realizar videollamada. El segundo prototipo sería visitando el perfil del usuario que se le desea realizar la videollamada y seleccionar esta opción en el menú que aparece debajo de su foto de perfil (ver Ilustración 29). Ilustración 29: Interfaz para realizar videollamada. Posteriormente de haber enviado la solicitud al usuario con el que se desea comunicar, en su aplicación aparecerá un cuadro de diálogo para que confirme o rechace la solicitud de videollamada (ver Ilustración 30). Ilustración 30: Cuadro de diálogo de notificación de videollamada. 41 5.4 Modelo de análisis El modelo de análisis se utiliza como ayuda para refinar los requisitos. Analizar los requisitos en la forma de un modelo de análisis es importante por varios motivos:  Un modelo de análisis ofrece una especificación más precisa de los requisitos que se obtienen como resultado de la captura de requisitos, incluyendo al modelo de casos de uso.  Un modelo de análisis se describe utilizando el lenguaje de los desarrolladores, se puede por tanto introducir un mayor formalismo y ser utilizado para razonar sobre los funcionamientos internos del sistema.  Un modelo de análisis estructura los requisitos de un modo que facilita su comprensión, su preparación, su modificación y en general su mantenimiento. Un modelo de análisis puede considerarse como una primera aproximación al modelo de diseño (aunque es un modelo por sí mismo) y es por tanto una entrada fundamental para darle forma al sistema en el diseño y en la implementación. (17) 5.4.1 Diagrama de clases  Caso de Uso Registrarse Relación de trazabilidad entre el caso de uso Registrarse del modelo de casos de uso y la realización del caso de uso Registrarse en el modelo de análisis (ver Ilustración 31). Ilustración 31: Relación de trazabilidad del caso de uso Registrarse. Para el diagrama de clases del modelo de análisis se tienen las clases: Control_Registro, la cual se encarga de invocar a la clase Interfaz_Registro. La clase Interfaz_Registro, muestra un formulario para que el usuario pueda introducir sus datos personales y estos pasan a ser validados por la clase Validar_Registro. La clase Validar_Registro es una clase que tiene la función de comprobar que los datos insertados en el registro son correctos. Se identifica también Control_Usuario, la cual es una clase de control que recibe todos los datos del registro y se encarga de crear el usuario correspondiente. Por último, la clase Cuenta_Usuario, la cual es una entidad y representa al usuario en cuestión (ver Ilustración 32). Registrarse Registrarse <<trace>> 48 Ilustración 50: Diagrama de colaboración para el flujo alternativo del caso de uso Buscar Amigo.  Caso de Uso Compartir Contenido Ilustración 51: Diagrama de colaboración para el flujo normal del caso de uso Compartir Contenido. Ilustración 52: Diagrama de colaboración para el flujo alternativo del caso de uso Publicar Contenido. : Panel_Busqueda <<boundary>> : Listado_Resultados <<boundary>> : Control_Busqueda <<control>> : Amigo <<entity>> : Lista_Resultados <<entity>> : Control_Amigos <<control>> : Usuario Registrado 1 : mostrar() 2 : introducirNombre() 3 : generar() 4 : mostrar() : Contenido_Publicado <<boundary>> : Agregar_Contenido <<boundary>> : Publicar_Contenido <<control>> : Validar_Contenido <<control>> : Cuenta_Usuario <<entity>> : Usuario Registrado 1 : mostrar() 2 : cargarContenido() 3 : validar() 4 : actualizar() 5 : mostrar() : Contenido_Publicado <<boundary>> : Agregar_Contenido <<boundary>> : Publicar_Contenido <<control>> : Validar_Contenido <<control>> : Cuenta_Usuario <<entity>> : Usuario Registrado 1 : mostrar() 2 : cargarContenido() 3 : validar() 4 : errorCuotaLimiteSuperada() 5 : mostrar() 6 : cargarError() 49  Caso de Uso Eliminar Contenido Ilustración 53: Diagrama de colaboración para el flujo normal del caso de uso Eliminar Contenido. Ilustración 54: Diagrama de colaboración para el flujo alternativo del caso de uso Eliminar Contenido.  Caso de Uso Eliminar Cuenta Usuario Ilustración 55: Diagrama de colaboración para el flujo normal del caso de uso Eliminar Cuenta Usuario. : Cuenta_Usuario <<entity>> : Contenido_Eliminado <<boundary>> : Confirmacion_Eliminacion <<boundary>> : Eliminador_Contenido_Control <<control>> : Usuario Registrado 1 : mostrar() 2 : confirmaEliminacion() 3 : actualizar() 4 : mostrar() : Cuenta_Usuario <<entity>> : Contenido_Eliminado <<boundary>> : Confirmacion_Eliminacion <<boundary>> : Eliminador_Contenido_Control <<control>> : Usuario Registrado 1 : mostrar() 2 : noConfirmaEliminacion() : Usuario Administrador : Lista_Alertas <<boundary>> : Gestor_Alertas <<control>> : Gestor Usuarios <<control>> : Listado_Alertas <<entity>> : Cuenta_ Usuario <<entity>> 1 : generar() 2 : enviar() 3 : mostrar() 4 : eliminar() 50 Ilustración 56: Diagrama de colaboración para el flujo alternativo del caso de uso Eliminar Cuenta Usuario.  Caso de Uso Login Ilustración 57: Diagrama de colaboración para el flujo normal del caso de uso Login. Ilustración 58: Diagrama de colaboración para el flujo alternativo del caso de uso Login. : Usuario Administrador : Lista_Alertas <<boundary>> : Gestor_Alertas <<control>> : Gestor Usuarios <<control>> : Listado_Alertas <<entity>> : Cuenta_ Usuario <<entity>> 1 : generar() 2 : enviar() 3 : mostrar() 4 : eliminarAlertas() : Usuario Registrado : Gestor_Login <<control>> : Formulario_Login <<boundary>> : Cuenta_ Usuario <<entity>> : Validador_Login <<control>> 1 : mostrar() 2 : introducirDatos() 3 : validarDatos() 4 : enviarDatos() 5 : accederCuenta() : Usuario Registrado : Gestor_Login <<control>> : Formulario_Login <<boundary>> : Cuenta_ Usuario <<entity>> : Validador_Login <<control>> 1 : mostrar() 2 : introducirDatos() 3 : validarDatos() 4 : devuelveErrorDatos() 5 : informarErrorDatos() 51  Caso de Uso Realizar Videollamada Ilustración 59: Diagrama de colaboración para el flujo normal del caso de uso Realizar Videollamada. Ilustración 60: Diagrama de colaboración para el flujo alternativo del caso de uso Realizar Videollamada. : Servidor_Heroku : Usuario Registrado : Usuario Registrado : Ventana_Videollamada <<boundary>> : Panel_Videollamada <<boundary>> : Gestion_Videollamada <<control>> : Ventana_Dialogo <<boundary>> : Cuenta_ Usuario <<entity>> 1 : mostrar() 2 : enviarSolicitudVideollamada() 3 : generar() 4 : iniciarConexion() 5 : mostrarVideo() 6 : consultar() 7 : muestraSolicitudConexion() 8 : conectarse() : Servidor_Heroku : Usuario Registrado : Usuario Registrado : Ventana_Videollamada <<boundary>> : Panel_Videollamada <<boundary>> : Gestion_Videollamada <<control>> : Ventana_Dialogo <<boundary>> : Cuenta_ Usuario <<entity>> 1 : mostrar() 2 : enviarSolicitudVideollamada() 3 : generar() 4 : iniciarConexion() 5 : mostrarVideo() 6 : consultar() 7 : muestraSolicitudConexion() 8 : rechazar() 52  Caso de Gestionar Perfil Ilustración 61: Diagrama de colaboración para el flujo normal del caso de uso Gestionar Perfil. Ilustración 62: Diagrama de colaboración para el flujo alternativo del caso de uso Gestionar Perfil. : Usuario Registrado : Gestion_Usuario <<control>> : Formulario_Datos_Perfil <<boundary>> : Cuenta_ Usuario <<entity>> : Validar_Datos <<control>> 1 : obtenerDatos() 2 : mostrar() 3 : introducirDatos() 4 : validarDatos() 5 : actualziar() : Usuario Registrado : Gestion_Usuario <<control>> : Formulario_Datos_Perfil <<boundary>> : Cuenta_ Usuario <<entity>> : Validar_Datos <<control>> 1 : obtenerDatos() 2 : mostrar() 3 : introducirDatos() 4 : validarDatos() 5 : devolverErrorDatos() 6 : informarError() 53 5.5 Modelo de diseño El diseño tiene el propósito de formular los modelos que se centran en los requisitos no funcionales y en el dominio de la solución. Prepara para la implementación y las pruebas del sistema. Pretende crear un plano del modelo de implementación, por lo que el grueso del esfuerzo está en las últimas iteraciones de elaboración y las primeras de construcción. El modelo de diseño está muy cercano al de implementación, lo que es natural para guardar y mantener el modelo de diseño a través del ciclo de vida completo del software. En el diseño se modela el sistema y se encuentra su forma (incluida la arquitectura) para que soporte todos los requisitos, incluyendo los no funcionales y las restricciones. Una entrada esencial en el diseño es el resultado del análisis, o sea el modelo de análisis, que proporciona una comprensión detallada de los requisitos. La Disciplina de Diseño tiene entre sus propósitos:  Adquirir una comprensión de los aspectos relacionados con los requisitos no funcionales y restricciones relacionadas con los lenguajes de programación, componentes reutilizables, sistemas operativos, tecnologías de distribución y concurrencia y de interfaz de usuario.  Crear una entrada apropiada y un punto de partida para actividades de implementación, capturando los requisitos o subsistemas individuales, interfaces y clases.  Descomponer los trabajos de implementación en partes más manejables que puedan ser llevadas a cabo por diferentes equipos de desarrollo.  Capturar las interfaces entre los subsistemas antes en el ciclo de vida del software, lo cual es muy útil cuando se utilizan interfaces como elementos de sincronización entre diferentes equipos de desarrollo. 5.5.1 Arquitectura del sistema Para soportar el modelo de despliegue del sistema se definen los siguientes elementos:  Dos balanceadores de carga con Apache Web Server 2 Las peticiones a los mismos se hará de forma alternada a través del Servidor DNS, que distribuirá las peticiones a cada balanceador. Cada balanceador distribuirá las conexiones a cada uno de los clústeres de Apache Tomcat y así estos se conectan a los servidores de DB. El objetivo de los dos balanceadores es no sobrecargar un solo Apache y en caso que deje de prestar servicio uno de ellos, los servicios no dejarán de funcionar. Los Apache Tomcat clústeres se conectarán a los sistemas externos, servidores de aplicaciones que soportan la tecnología de Node.js (ver Ilustración 63). 54 Ilustración 63: Modelo de despliegue. 5.5.2 Diagramas de clases  Caso de Uso Registrarse Una realización de caso de uso del diseño Registrarse proporciona una traza directa a una realización de caso de uso de análisis Registrarse en el modelo de análisis (ver Ilustración 64). Ilustración 64: Relación de trazabilidad del caso de uso Registrarse. En el diagrama de clases del modelo de diseño se identifican las siguientes clases: Formulario, clase genérica la cual puede representar cualquier formulario, en este caso con el atributo Datos y el método enviarDatos (), para enviar al control los datos rellenados por el usuario. También encontramos la clase UIFormulario_Registro que hereda de la clase formulario. La clase Controladora_Usuarios se encarga de crear la cuenta de usuario correspondiente y almacenarla en la base de datos del sistema mediante el método crear (). Cuenta_Usuario es una clase entidad para representar a un usuario concreto, con un atributo datos que representa información acerca del usuario en cuestión. Además, la clase Controladora_Registro se encarga de mostrar el formulario de registro y recibir los datos del mismo. La clase Validador comprueba los datos recibidos de la clase UIFormulario_Registro, para verificar que efectivamente los datos introducidos son correctos (ver Ilustración 65). cliente DNS Balancer Apache2 Load Balancer Apache2 Load Balancer Apache Tomcat cluster 4 Apache Tomcat cluster 4 Apache Tomcat cluster 4 Apache Tomcat cluster 4 DB Balancer MySQL cluster 3 MySQL cluster 3 MySQL cluster 3 Servidor Node.js Servidor Node.js Usuario RegistrarseRegistrarse <<trace>> 55 Ilustración 65: Diagrama de clases del diseño para caso de uso Registrarse.  Caso de Uso Buscar Amigos Una realización de caso de uso del diseño Buscar Amigo proporciona una traza directa a una realización de caso de uso de análisis Buscar Amigo en el modelo de análisis (ver Ilustración 66). Ilustración 66: Relación de trazabilidad para el caso de uso Buscar Amigo. En el modelo de clases de diseño del caso de uso Buscar Amigo, se identifica la clase Control_Amigos en la cual se encuentra el método buscarAmigo (), dicho método localiza a los usuarios con el nombre introducido en el formulario de búsqueda. Se identifica la clase Lista_Amigos a la cual se le añaden los amigos que el usuario haya querido agregar, de ahí se genera la clase Amigo con sus datos, por ejemplo Nombre. Se tiene la clase Lista_Resultados, la cual contiene un listado con los contactos dados de alta en Webcam App que poseen el nombre del usuario que se desea encontrar. También por último la clase UIBuscador_Amigos que es la clase vista que se utiliza para mostrar los datos al usuario (ver Ilustración 67). Formulario -Datos +enviarDatos() UIFormulario_Registro Controladora_Registro +generar() +recibir() Controladora_Usuarios +crear() Validador +validar() Cuenta_Usuario -Datos Buscar AmigoBuscar Amigo <<trace>> 56 Ilustración 67: Diagrama de clases del diseño para el caso de uso Buscar Amigo.  Caso de Uso Compartir Contenido Una realización de caso de uso del diseño Compartir Contenido proporciona una traza directa a una realización de caso de uso de análisis Compartir Contenido en el modelo de análisis (ver Ilustración 68). Ilustración 68: Relación de trazabilidad para caso de uso Compartir Contenido. En el modelo de diseño está presente la clase Gestor_Contenido, que contiene los métodos almacenar (), con el cual se almacena el contenido en la cuenta de usuario y el método actualizar (), que actualiza los archivos del usuario después de agregar el contenido. La clase Gestor_Contenido tiene relación con las clases Cuenta_Usuario y Validador. La clase Cuenta_Usuario contiene los datos personales de la cuenta del usuario y sus archivos. La clase Validador contiene el método de validar (), que comprueba que el usuario puede compartir el contenido. La clase UIFormulario_Contenido contiene el método cargarContenido (), dicha clase envía los datos a la clase Validador (ver Ilustración 69). UIBuscador_Amigos Lista_Amigos +añadir() Amigo -Nombre Control_Amigos +buscarAmigo() Lista_Resultados Compartir Contenido Compartir Contenido <<trace>> 57 Ilustración 69: Diagrama de clases del diseño para el caso de uso Compartir Contenido.  Caso de Uso Eliminar Contenido Una realización de caso de uso del diseño Eliminar Contenido proporciona una traza directa a una realización de caso de uso de análisis Eliminar Contenido en el modelo de análisis (ver Ilustración 70). Ilustración 70: Relación de trazabilidad para el caso de uso Eliminar Amigo. En el modelo de diseño del caso de uso Eliminar Contenido está la clase Gestor_Contenido que contiene el método eliminar (), dicho método suprime el contenido de la cuenta de usuario y el método actualizar () que actualiza los archivos del usuario después de eliminar el contenido. La clase Gestor_Contenido tiene relación con las clases Cuenta_Usuario y Mensaje_Confirmación. La clase Cuenta_Usuario contiene los datos personales de la cuenta del usuario y sus archivos. La clase Mensaje_Confirmación contiene el método notificar (), dicha clase le muestra al usuario un mensaje para que el usuario confirme la eliminación (ver Ilustración 71). Validador +validar() Gestor_Contenido +almacenar() +actualizar() Cuenta_Usuario -Datos +Archivos UIFormulario_Contenido +cargarContenido() Eliminar ContenidoEliminar Contenido <<trace>> 64  Caso de Uso Compartir Contenido Ilustración 84: Diagrama de secuencia para el flujo normal del caso de uso Compartir Contenido. Ilustración 85: Diagrama de secuencia para el flujo alternativo del caso de uso Compartir Contenido. : Gestor_Contenido : UIFormulario_Contenido : Validador : Usuario Registrado : Cuenta_Usuario 1 : muestra() 2 : carga() 3 : envia() 4 : devuelve() 5 : almacena() : Gestor_Contenido : UIFormulario_Contenido : Validador : Usuario Registrado : Cuenta_Usuario 1 : muestra() 2 : carga() 3 : envia() 4 : devuelve() 5 : cargaError() 65  Caso de Uso Eliminar Contenido Ilustración 86: Diagrama de secuencia para el flujo normal del caso de uso Eliminar Contenido. Ilustración 87: Diagrama de secuencia para el flujo alternativo del caso de uso Eliminar Contenido. : Mensaje_Confirmacion : UIFormulario_Contenido : Gestor_Contenido : Cuenta_Usuario : Usuario Registrado 1 : mostrar() 2 : sleccionar() 3 : mostrar() 4 : aceptaEliminacion() 5 : eliminaContenido() : Mensaje_Confirmacion : UIFormulario_Contenido : Gestor_Contenido : Cuenta_Usuario : Usuario Registrado 1 : mostrar() 2 : sleccionar() 3 : mostrar() 4 : cancelaEliminacion() 66  Caso de Uso Eliminar Cuenta Usuario Ilustración 88: Diagrama de secuencia para el flujo normal del caso de uso Eliminar Cuenta Usuario. Ilustración 89: Diagrama de secuencia para el flujo alternativo del caso de uso Eliminar Cuenta Usuario. : Gestor_Alertas : Lista_Alertas_Usuarios : UIReporte_Alertas : Gestor_Usuarios : Cuenta_Usuario : Usuario Administrador 1 : genera() 2 : envia() 3 : muestra() 4 : seleccionaEliminarUsuario() 5 : eliminaCuentaUsuario() : Gestor_Alertas : Lista_Alertas_Usuarios : UIReporte_Alertas : Gestor_Usuarios : Cuenta_Usuario : Usuario Administrador 1 : genera() 2 : envia() 3 : muestra() 4 : seleccionaEliminarAlerta() 5 : eliminaAlerta() 67  Caso de Uso Login Ilustración 90: Diagrama de secuencia para el flujo normal del caso de uso Login. Ilustración 91: Diagrama de secuencia para el flujo normal del caso de uso Login. : UIFormulario_Login : Gestor_Login : Cuenta_Usuario : Validador : Usuario Registrado 1 : muestra() 2 : introduceDatos() 3 : envia() 4 : devuelve() 5 : accede() : UIFormulario_Login : Gestor_Login : Cuenta_Usuario : Validador : Usuario Registrado 1 : muestra() 2 : introduceDatos() 3 : envia() 4 : cargaError() 68  Caso de Uso Realizar Videollamada Ilustración 92: Diagrama de secuencia para el flujo normal del caso de uso Realizar Videollamadas. Ilustración 93: Diagrama de secuencia para el flujo alternativo del caso de uso Realizar Videollamada. : Gestion_Videollamada : Ventana_Videollamada : Panel_Videollamada : Ventana_Dialogo : Cuenta_Usuario : Usuario Registrado : Usuario Registrado subsistema : Servidor_Aplicaciones_Heroku 1 : generar() 2 : enviaSolicitud() 3 : genera() 4 : crearConexion() 5 : mostrarVideo() 6 : consultar() 7 : genear() 8 : notifica() 9 : aceptaSolicitud() 10 : redirecciona() : Gestion_Videollamada : Ventana_Videollamada : Panel_Videollamada : Ventana_Dialogo : Cuenta_Usuario : Usuario Registrado : Usuario Registrado subsistema : Servidor_Aplicaciones_Heroku 1 : generar() 2 : enviaSolicitud() 3 : genera() 4 : crearConexion() 5 : mostrarVideo() 6 : consultar() 7 : genear() 8 : notifica() 9 : cancelaSolicitud() 69  Caso de Uso Gestionar Perfil Ilustración 94: Diagrama de secuencia para el flujo normal del caso de uso Gestionar Perfil. Ilustración 95: Diagrama de secuencia para el flujo alternativo del caso de uso Gestionar Perfil. : UIFormulario_Datos_Perfil : Gestor_Usuario : Validador : Cuenta_Usuario : Usuario Registrado 1 : recibe() 2 : muestra() 3 : selecciona() 4 : envia() 5 : devuelve() 6 : actualiza() : UIFormulario_Datos_Perfil : Gestor_Usuario : Validador : Cuenta_Usuario : Usuario Registrado 1 : recibe() 2 : muestra() 3 : selecciona() 4 : envia() 5 : cargaError() 70 5.6 Implementación 5.6.1 Primeros pasos con CMS Elgg Con el objetivo de desarrollar una aplicación que además de realizar videollamadas, fuera potente en funcionalidades como la gestión de usuarios, gestión de contenidos, gestión de amigos, entre otras, se eligió Elgg, que provee funcionalidades específicas para estos requerimientos.  ¿Por qué elegirlo? Elgg es un manejador de contenidos de código abierto, con plugins de gran utilidad, los cuales de manera muy potente permiten crear una red social. Se pueden desarrollar plugins que cumplan con los requerimientos de los usuarios del sitio web e incorporarlos de forma muy sencilla. Es una herramienta bastante segura ya que todos los objetos contenidos en el sitio de Elgg tienen un nivel de control de acceso configurable.  Modificaciones en el CMS Elgg Una vez cubiertas estas funcionalidades, se necesita desarrollar un plugin para que el usuario desde Elgg pueda realizar videollamadas a sus amigos. Para el desarrollo de esta funcionalidad se modificó el CMS Elgg. Utilizando funciones de jQuery, creando una nueva base de datos y a través de uso de Ajax, se desarrolla un plugin que permite:  En el momento en que un usuario decide realizar una videollamada a alguno de sus amigos online, se escribe la petición en la base de datos.  Después de escrita la petición en la base de datos, con una función que se ejecuta cada 5 segundos y desde el cliente de los usuarios que se encuentran conectados, lee la base de datos y detecta si algún usuario ha hecho alguna petición de videollamada.  Una vez que lo anterior es detectado, el sistema visualiza un cuadro de diálogo desarrollado con jQuery, que simula al que muestran otros sistemas de videollamadas, para que el usuario que está siendo llamado conteste o rechace la solicitud de videollamada. Elgg como otros manejadores de contenido, tras su instalación activa algunos plugins que vienen en el núcleo del CMS. Para lograr una mejor apariencia y mejorar algunas funcionalidades, se requirió la instalación de algunos plugins descargados del sitio web oficial de Elgg, los cuales se nombran a continuación:  Invite Friends Plugin que permite que las solicitudes de amistad se manejen tipo Facebook, es decir, que un usuario envíe una solicitud a otro y para que puedan ser amigos en la aplicación el otro debe aceptar dicha invitación. De otro modo no tendrán una relación de amistad y solo se podrá acceder a los datos que los usuarios compartan como público y a las funcionalidades generales entre usuarios.  GalliStatus El CMS a pesar de informarnos cuales son los usuarios que están en línea, no lo hace como otras redes sociales, por lo que el plugin GalliStatus permite saber el estado en el que se encuentra el usuario en la aplicación, en línea o desconectado, mostrando un icono verde sobre las fotos de perfil de los usuarios. 71  Pearl Premium Theme Plugin que permite modificar la apariencia del sitio. Tema que hace más agradable la presentación de los datos con el buen diseño que plantea y con características de las aplicaciones tradicionales. 5.6.2 Lo más importante está por llegar. WebRTC y HTML5 Es necesario desarrollar un sistema que pueda conectar a dos usuarios a través de sus respectivas webcams. Para esto se necesita implementar una pequeña aplicación en JavaScript y HTML5, que permita utilizar los elementos que brinda HTML5 para dar soporte al audio y el video. Además, es necesario utilizar las librerías de webRTC: MediaStream y RTCPeerConnection, que son fundamentales para la creación de un sistema de videoconferencias. Ahora bien, un sistema de videoconferencias necesita un servidor como proveedor de comunicación en tiempo real, lo cual es muy limitado si se usa Apache, esta parte de la aplicación se ha desarrollado enfocada a otro servidor, Node.js.  ¿Por qué Node.js? Apache crea un nuevo hilo por cada conexión cliente-servidor. Esto funciona bien para pocas conexiones, pero crear nuevos hilos es algo costoso, así como los cambios de contexto. Apache funciona bien pero no es el mejor servidor para lograr máxima concurrencia. Uno de los puntos fuertes de Node.js es su capacidad de mantener muchas conexiones abiertas y esperando, por lo que su uso es ideal para que miles de usuarios estén enviando peticiones de videollamadas. Además de lo explicado anteriormente, para un sistema de videollamadas sobre HTML5 se necesita un servidor de señalización, el cual se puede construir con el módulo Sockets.io de Node.js porque las APIs de webRTC no proveen de este mecanismo. 5.6.3 Integrar las dos aplicaciones para que parezcan una Tanto el usuario que realiza la solicitud de videollamada como el usuario que acepta la videollamada, son redirigidos al servidor de aplicaciones Heroku, es decir, los usuarios no deben usar las dos aplicaciones por separado, cada usuario puede usar los potenciales que ofrece Elgg y en el momento que desee realizar una videollamada el mismo CMS lo ayudará a conectarse al servidor Heroku de forma transparente. 72 5.7 Pruebas Es necesario realizar pruebas para con los resultados obtenidos de las mismas poder verificar si el sistema cumple o no con los requerimientos planteados en el inicio del desarrollo. Las pruebas realizadas se basan en el funcionamiento de las APIs de WebRTC, HTML5 y Node.js. También, son ejecutadas con el objetivo de comprobar que la señalización se lleva a cabo correctamente y que dos usuarios con este servidor pueden intercambiar entre sí audio y video en tiempo real. Luego de descargar el Node.js del sitio web oficial www.nodejs.org, el próximo paso es realizar la instalación. Una vez instalado, debe configurarse el archivo server.js o app.js. Posteriormente, se introducen los ficheros Javascript, HTML y CSS que contienen el código de la aplicación desarrollada, dentro de la carpeta del servidor Node.js. Una vez realizada toda la configuración pertinente, se inicia el servidor, lo cual se realiza de la siguiente manera (ver Ilustración 96). Ilustración 96: CMD de Windows para activar servidor de Node.js. Ya activado el servidor Node.js, solo resta abrir el navegador. Se introduce la dirección, el puerto y los parámetros requeridos (ver Ilustración 97). Ilustración 97: Capturando video desde la webcam a través de las APIs de WebRTC y HTML5 con Node.js como servidor de aplicaciones. Una vez llegado a este punto y para comprobar que dos usuarios pueden intercambiar información, resta escribir exactamente la misma URL que se colocó anteriormente en otra ventana del navegador, lo cual simula que es otro usuario que está intentado conectarse con el primer usuario que creó la conexión. 73 Como se ha podido comprobar, el servidor funciona correctamente ya que ambos usuarios intercambian sus videos a través de las APIs de webRTC, usando los elementos de HTML5 para el manejo de multimedia, todo esto utilizando el servidor Node.js (ver Ilustración 98). Ilustración 98: Realizando videollamada en el servidor local satisfactoriamente. 80  Email Address: es la dirección de correo electrónico con la cual se desea registrarse en el sitio y donde se enviarán las notificaciones del mismo.  Password: en este campo se debe introducir la contraseña con la cual se accederá a la cuenta que se creará tras haber finalizado el registro.  Password (again for verification): este es un campo de verificación, para comprobar que se ha introducido correctamente la contraseña que se desea (ver Ilustración 101). Ilustración 101: Página de registro. Cuando el registro esté finalizado, se puede empezar a hacer uso de todas las funcionalidades que brinda Webcam App, entre las cuales está la de localizar a los amigos que están registrados en el sitio. Para ello, se accede a la opción del menú Members, donde se muestra un listado con los miembros que están dados de alta en el sitio (ver Ilustración 102 y 103). 81 Ilustración 102: Listado de usuarios registrados. Ilustración 103: Panel de búsqueda. Es necesario introducir el nombre del amigo que se desea buscar en el campo de texto y presionar el botón Search. La aplicación mostrará un listado con las usuarios encontrados con el nombre introducido, dando la opción de añadirlo como amigo en Webcam App a través del botón Add Friend (ver Ilustración 104). Ilustración 104: Resultados de la búsqueda de usuarios Mientras la persona que desea llamar no acepte su solicitud de amistad, no se podrá realizar videollamadas con dicha persona (ver Ilustración 105). 82 Ilustración 105: Perfil de un usuario que no ha aceptado la solicitud de amistad. Una vez que el usuario acepte su solicitud de amistad, se tendrá disponible todas las funcionalidades incluida la de enviarle una solicitud de videollamada (ver Ilustración 106). Ilustración 106: Perfil de un usuario que aceptó la solicitud de amistad Por último, queda enviar la solicitud de videollamada y esperar que el usuario la acepte para poder comunicarse e intercambiar los videos obtenidos desde la webcam (ver Ilustración 107). Ilustración 107: Ventana de diálogo que se muestra a los usuarios cuando reciben una solicitud de videollamadas. 83 Una vez que el usuario amigo acepte la solicitud la videollamada queda establecida (ver Ilustración108). Ilustración 108: Videollamada establecida entre dos usuarios a través de la aplicación Webcam App. 84 Anexo IV: Entorno de Desarrollo  Instalación de Elgg Para la instalación de Elgg es necesario dos componentes esenciales, el primero es el CMS Elgg en sí, el cual se puede descargar del sitio web oficial www.elgg.org y como cualquier otro CMS necesita un entorno de desarrollo web, entre los más utilizados para Windows se tiene el Wamp y para Linux el Xamp. En este caso se utiliza Wamp.  ¿Qué facilidades brinda Wamp? Wamp provee de los cuatro elementos esenciales a la hora de construir un sitio web: un sistema operativo (Windows), un manejador de base de datos (MySQL), un software para servidor web (Apache) y el soporte a un lenguaje de programación del lado del servidor (eje PHP). Luego de tener instalado el Wamp en el ordenador, se continúa con la instalación del Elgg. Lo primero que se debe hacer es copiar la carpeta de Elgg para el servidor Wamp, dentro de la carpeta /www y tratar de acceder al servidor a través del navegador con la dirección http://localhost:puerto, en este caso el servidor web está configurado para que escuche en el puerto 88 (ver Ilustración 109 y 110). Ilustración 109: Página de inicio del servidor Wamp. Ilustración 110: Página de instalación de Elgg. 85 Como los demás CMS, Elgg necesita la creación de una base de datos, la cual se crea con el gestor de base datos MySQL, que brinda Wamp. La base de datos se crea de la siguiente manera: se accede al servidor a través del navegador y se selecciona la opción phpmyadmin, ubicada en la parte inferior de la página de inicio del Wamp (ver Ilustración 111). Ilustración 111: Acceso a phpmyadmin a través de la página de inicio de Wamp. De esta manera se accede a phpMyAdmin, que no es más que una página en php para gestionar la base de datos a través del navegador (ver ilustración 112). Ilustración 112: Creación de base de datos en phpMyAdmin. De esta manera se crea la base de datos, ahora solo resta crear un usuario con todos los privilegios sobre ella. Durante el proceso de instalación de Elgg, solicita proporcionar el nombre de la base de datos y el nombre de usuario con todos los privilegios, para que al completar la instalación se puedan generar todas las tablas y datos que trae consigo Elgg. Para darle las funcionalidades adecuadas a la aplicación Webcam App, se utilizan algunos plugins específicos. Estos plugins ayudan a que el usuario alcance un alto nivel de usabilidad, pues aportan funciones similares a las que tienen otras redes sociales conocidas a escala mundial, la más destacada entre ellas es Facebook. Para instalar un plugin en la aplicación, debe copiarse el plugin dentro de la carpeta /mod del directorio raíz del CMS y luego acceder al panel de administración del sitio web en el apartado Plugins y seleccionar la opción Activate (Ver Ilustración 113 y 114). 86 Ilustración 113: Acceso al panel de administración de plugins Ilustración 114: Proceso de activación de un plugin.  Publicación de la aplicación en un servidor de hosting en Internet Luego de haber instalado el CMS correctamente, activados y configurados los plugins necesarios, se procede a la publicación del sitio web en un servidor de hosting en internet. Para esto se escoge 000webhost, el cual es un servidor de hosting gratuito y fácil de usar. Lo primero es crearse una cuenta en la página web www.000webhost.com, luego acceder al panel de control del sitio web. Una vez allí, se crea una base datos de igual manera que se hizo para el sitio que se crea en local, se exporta la base de datos que se encuentra en el ordenador y se importa a la base de datos del servidor de hosting. Una vez hecho esto, queda indicarle al sitio web los datos de la nueva base datos, puesto que ya no estará local, ahora debe encontrarse en el servidor 000webhost, como en todos los CMS, se localiza el archivo settings.php, que es el que contiene entre otras cosas los datos para la conexión a la base de datos y se modifican los valores por los nuevos parámetros. Para finalizar la publicación del sitio, se copia a través de un cliente ftp o a través del que brinda 000webhost en su página web todos los archivos del sitio local a la carpeta public_html en el servidor de hosting. Ahora bien, el sitio web está publicado en un servidor de hosting en internet pero aún no se puede navegar por él, pues es necesario un nombre de dominio. Para esto el usuario debe dirigirse al sitio www.dot.tk, en el cual se registra y puede obtener un nombre de dominio de forma gratuita si está disponible (ejemplo: www.webcamapp.tk). Luego de haber obtenido el nombre de dominio, solo resta entrar al panel de configuración e indicarle la dirección de Host Name que brinda 000webhost (ver Ilustración 115). 87 Ilustración 115: Panel de administración del dominio en dot.TK Llegado a este punto, el sitio web se encuentra publicado en un servidor de hosting y con un nombre de dominio a través del cual se puede acceder a él. Se coloca el nombre de dominio creado en el navegador y se puede entrar fácilmente (ver Ilustración 116). Ilustración 116: Webcam App desplegado en el servidor de hosting  Configuración de Node.js del lado del servidor Node.js no es como otros servidores web, necesita una configuración manual del fichero JavaScript que se ejecuta en el servidor llamado app.js ó server.js. Algo llamativo puede ser que si existe otro servidor web, por ejemplo el Apache escuchando en el puerto 88, se debe introducir un puerto diferente para que escuche el Node.js (ejemplo 8888) (ver Ilustración 117). 88 Ilustración 117: Configuración del fichero server.js en el servidor. En este caso se va a trabajar con el módulo Sockets.io por lo que es necesaria la configuración del mismo. Con las salas (rooms) de Sockets.io, se puede enviar mensajes a un grupo de usuarios determinados, que serían los clientes que están conectados a ellas. Con el siguiente fragmento de código, se define con quien será el intercambio de mensajes. Con la función broadcast, se puede especificar quien se desea que reciba los mensajes que el cliente envíe, para este caso los mensajes se envían y se reciben por los usuarios que estén conectados a la misma sala (room), aunque bien podría configurarse para todas las salas de la aplicación. Si se quisiera mandar un mensaje de multidifusión a todos los usuarios, para eso se utiliza socket.broadcast.emit (‘message’, message) (ver Ilustración 118). Ilustración 118: Definición de destinatario de los mensajes.  Configuración del lado del cliente Una vez configurado el servidor, es necesaria una configuración en el cliente para que pueda comunicarse con el mismo y poder intercambiar los mensajes, una sencilla configuración podría ser esta (ver Ilustración 119). Ilustración 119: Configuración en el cliente. Una vez que ambos usuarios estén conectados a la misma sala (room), es donde entra la API de webRTC, RTCPeerConnection. Para lograr que ambos logren intercambiar el video que obtienen desde su webcam, hay que vincular estas funciones con socket.io, el cual se encarga del envío de mensajes. Con la siguiente función, dos usuarios pueden establecer sus remoteDescription con la description que reciban del otro usuario y así posteriormente poder intercambiar sus videos obtenidos desde la webcam. Con la API MediaStream, a través de la función que está actualmente disponible en Google Chrome, Mozilla Firefox y Opera, definida como getUserMedia(), de una forma muy sencilla se puede obtener multimedia e incrustarla en el elemento video de HTML5. 89 Para aplicaciones publicadas en internet o para la comunicación con usuarios que estén fuera de una red local, es necesario añadir servidores que permiten que un host final pueda descubrir la dirección IP pública si se encuentra detrás de un NAT, durante la implementación del API RTCPeerConnection (ver Ilustración 120 y 121). Ilustración 120: Añadiendo servidores. Ilustración 121: Creación de una PeerConnection.  APIs de webRTC utilizadas en la aplicación.  MediaStream (getUserMedia): La cual se utiliza para acceder a los datos de los usuarios (ejemplo: el video o el audio obtenidos desde la webcam).  RTCPeerConnection: Esta API permite que a dos personas comunicarse directamente a través del navegador, usando un canal de señalización, el cual no está especificado en esta API.  Potencialidades de HTML5 En la actualidad, la mayoría de los navegadores muestran videos a través de un plugin (ejemplo flash), claramente no es una solución que resuelva todos los problemas, ya que los navegadores pueden tener diferentes plugins, lo cual conlleva a que los videos incrustados en la web no estén siempre disponibles para todos los usuarios. Con la aparición de HTML5, se define un nuevo elemento que especifica un método estándar para incrustar un vídeo / película en una página web: el elemento <video>. A continuación se muestran los navegadores que soportan HTML5 (ver Ilustración 122). Ilustración 122: Navegadores que soportan HTML5