DESARROLLO DE APLICACIÓN DE NOTIFICACIONES A TRAVÉS DE...

Equation Chapter 1 Section 1

Trabajo Fin de Grado

Grado Ingeniería de las Tecnologías de

Telecomunicaciones

Desarrollo de Aplicación de Notificaciones

a través de WAINE

Autor: Alberto Fuentes Muñoz

Tutor: Antonio José Estepa Alonso

Dep. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

3

Trabajo Fin de Grado

Grado en Ingeniería de las Tecnologías de Telecomunicaciones

DESARROLLO DE APLICACIÓN DE

NOTIFICACIONES A TRAVÉS DE WAINE

Autor:

Alberto Fuentes Muñoz

Tutor:

Antonio José Estepa Alonso

Profesor titular

Dep. Ingeniería Telemática

Escuela Técnica Superior de Ingeniería

Universidad de Sevilla

Sevilla, 2017

5

Trabajo Fin de Grado: Desarrollo de Aplicación de Notificaciones a través de

WAINE

Autor: Alberto Fuentes Muñoz

Tutor: Antonio José Estepa Alonso

El tribunal nombrado para juzgar el Proyecto arriba indicado, compuesto por los siguientes miembros:

Presidente:

Vocales:

Secretario:

Acuerdan otorgarle la calificación de:

Sevilla, 2017

6

El Secretario del Tribunal

7

A mi familia

A mis maestros

A mis compañeros y amigos

9

Agradecimientos

Dicen que las despedidas son tristes, pero estoy seguro que esta será todo lo contrario. Se acaba una etapa de mi vida, una etapa dura, una etapa llena de altibajos, una etapa llena de sorpresas y sobre todo, una etapa llena de gente, de buena gente. Intentaré agradeceros todos estos años juntos, porque entre todos me habéis ayudado a conseguir mis objetivos, sin vosotros no hubiera sido posible.

No voy a decir que haya sido fácil, mentiría, pero si hay dos personas que me han ayudado para que estos años hayan sido menos difícil han sido mis padres: José Antonio y Mari Carmen. ¡Muchas gracias! Tanto por el apoyo como por aguantarme, quizá incluso más por esto segundo, porque ni yo mismo me aguantaba en época de exámenes. Gracias por invertir durante años, no sólo en mi etapa universitaria, en mi educación, por priorizar mis estudios y los de mi hermano a muchas cosas necesarias para nosotros, por todos esos sacrificios para que no faltase nada en casa. Gracias a ti también enano, porque aunque a veces seas un dolor de cabeza, no me imagino un mejor compañero de vida.

Gracias a mis compañeros telecos. Gracias por todos esos apuntes, por las conversaciones interminables antes de los exámenes, por haber siempre pensado en el compañero antes que en vosotros mismos. Me quedo con todos esos momentos de risa, las comidas en el césped, las escapadas de noche, las cenas de Navidad... Hemos sido una familia y he aprendido mucho de vosotros. Gracias a Alex, Bece, Fran D, Sara, Ángela, Fran M, Javi, Fonti, Manu, Claudia, Alfonso, Ismael, Joaquín, Luis… y perdón a todos los que me dejo por el camino, sería imposible nombrarlos a todos.

Por último, y no menos importante, gracias a mis profesores. A algunos más que a otros, para que vamos a negarlo. Me gustaría mencionar al Departamento de Telemática y en especial a mi tutor Antonio Estepa, el cual me ha ayudado muchísimo en estos últimos meses de mi estancia universitaria. Siempre ha tenido la puerta de su despacho abierta para mis dudas y ha estado siempre pendiente de la evolución del trabajo.

¡Nos vemos pronto!

Alberto Fuentes Muñoz

Sevilla, 2017

11

Resumen

Las aplicaciones web están al alza. Internet ha evolucionado en pocos años de limitarse a dar información a interactuar con sus usuarios para multitud de tareas; desde buscar información en una enciclopedia hasta gestionar las cuentas bancarias cómodamente desde casa.

Actualmente existen múltiples tecnologías para poder desarrollar una de estas aplicaciones. En este proyecto vamos a abordar WAINE, un Entorno de Desarrollo de Interfaces de Usuarios basado en Modelos, que nos permitirá construir aplicaciones web de una forma fácil, rápida y dirigida a programadores novatos. Además, gracias a la metodología que WAINE nos ofrece, nos allanará el camino para nuestro propósito.

La aplicación que queremos construir es la siguiente: TUTORIAPP. Una serie de formularios, accesibles bajo previa auntenticación de un alumno, con la que el pupilo podrá pedir una cita o tutoría al profesor que corresponda para tratar diversas dudas académicas. Además, tanto el alumno como el docente podrán gestionar sus citas para controlar y organizar mejor su tiempo. En definitiva, una aplicación para evitar el método tradicional de tutoría que consiste en llamar a la puerta del despacho del profesor y esperar una respuesta.

Hablaremos de modelos, base de datos, usuarios, lenguajes de programación, etc. ¡Llegó el momento de construir nuestra primera aplicación web!

13

Índice

Agradecimientos .................................................................................................................................................. 9

Resumen ............................................................................................................................................................ 11

Índice .................................................................................................................................................................. 13

Índice de Tablas ................................................................................................................................................. 15

Índice de Figuras ................................................................................................................................................ 17

1 Introducción ............................................................................................................................................... 20 1.1 Historia de las Aplicaciones Web [1] ................................................................................................... 21 1.2 Motivación y Objetivos ........................................................................................................................ 22

2 Introducción a WAINE ................................................................................................................................ 25 2.1 MB-UIDs .............................................................................................................................................. 25

2.1.1 El Marco de Referencia Camaleón [4] ......................................................................................... 26 2.2 Web Application INterface Engine [3] ................................................................................................. 27

2.2.1 El Modelo de Presentación.......................................................................................................... 27 2.2.2 El Modelo de Usuario .................................................................................................................. 27 2.2.3 El Modelo de Diálogo .................................................................................................................. 28 2.2.4 Arquitectura ................................................................................................................................ 28

3 Proceso de desarrollo de una aplicación en WAINE ................................................................................. 31 3.1 Proceso de Análisis .............................................................................................................................. 31 3.2 Modelado de Conceptos ..................................................................................................................... 31 3.3 Definir el Modelo de Presentación ...................................................................................................... 32 3.4 Descripción de todos los modelos en lenguaje ASL ............................................................................. 33 3.5 Generación de Repositorios ................................................................................................................ 33

4 TUTORIAPP ................................................................................................................................................. 36 4.1 Motivación .......................................................................................................................................... 36 4.2 Explicación de la Propuesta ................................................................................................................. 37 4.3 Diagramas de Caso de Uso ................................................................................................................. 37

4.3.1 Diagramas de Caso de Uso para Alumno .................................................................................... 38 4.3.2 Diagramas de Caso de Uso para Profesor ................................................................................... 39

5 Desarrollo de la aplicación según la metodología de WAINE .................................................................. 41 5.1 Análisis ................................................................................................................................................ 41 5.2 Modelo Entidad-Relación .................................................................................................................... 44 5.3 Modelo Entidad-Relación Anotado ..................................................................................................... 48 5.4 Descripción de los Modelos en Lenguaje ASL ...................................................................................... 49 5.5 Construcción de repositorios ............................................................................................................... 50 5.6 Formulario de autenticación externo .................................................................................................. 52

14

6 Resultado .................................................................................................................................................... 56 6.1 Pantalla de Acceso al Sistema ............................................................................................................. 56 6.2 Menús .................................................................................................................................................. 57 6.3 Pedir nueva tutoría .............................................................................................................................. 57 6.4 Versión para móvil ............................................................................................................................... 61

7 Restricciones y complicaciones .................................................................................................................. 63 7.1 Claves primarias en las entidades de la base de datos........................................................................ 63 7.2 ¿Usuarios como parte del modelo de usuarios o de datos? ................................................................ 64

8 Líneas futuras ............................................................................................................................................. 67 8.1 Desarrollo de la aplicación web ........................................................................................................... 67

8.1.1 Gestión de Tutorias del Profesor ................................................................................................. 67 8.1.2 Gestión de Tutorías del Alumno .................................................................................................. 67 8.1.3 Modificación de Horarios del Profesor ........................................................................................ 68

8.2 Usuario Admin ..................................................................................................................................... 68 8.3 El futuro de las Aplicaciones Web........................................................................................................ 69

9 Conclusiones ............................................................................................................................................... 71

Bibliografía ......................................................................................................................................................... 73

Glosario .............................................................................................................................................................. 75

Anexo 1: Archivos ASL ....................................................................................................................................... 78

Anexo 2: Archivos PHP ....................................................................................................................................... 83

Anexo 3: Archivos SQL ....................................................................................................................................... 87

Anexo 4: Archivos CSS........................................................................................................................................ 91

Anexo 5: Modelo Entidad-Relación ................................................................................................................... 95

Anexo 6: Diagrama de Gantt ............................................................................................................................. 96

15

ÍNDICE DE TABLAS

Tabla 3.1. Ejemplo de tabla de roles/funcionalidad 32

Tabla 4.1. Tabla Casos de Uso para el usuario Alumno 38

Tabla 4.2. Casos de Uso del usuario Profesor 39

Tabla 5.1: Atributos de la entidad alumno 45

Tabla 5.2: Atributos de la entidad profesor 45

Tabla 5.3: Atributos de la entidad asignatura 45

Tabla 5.4: Atributos de la entidad profesor_has_asignatura 46

Tabla 5.5: Atributos de la entidad timeslot 46

Tabla 5.6: Atributos de la entidad profesor_has_timeslot 46

Tabla 5.7: Atributos de la entidad cita 47

Tabla 5.8: Tabla roles/funcionalidad 48

17

ÍNDICE DE FIGURAS

Figura 1.1. Arquitectura Cliente-Servidor Tradicional 20

Figura 1.2. Arquitectura Aplicaciones Web 21

Figura 1.3. Evolución del Desarrollo Web [2] 22

Figura 2.1. El marco de referencia camaleón (simplificado) 26

Figura 2.2. Logo WAINE 27

Figura 2.3. Arquitectura de WAINE [3] 28

Figura 3.1. Ejemplo de Diagrama Entidad-Relación Anotado 32

Figura 4.1. Diagrama de Casos de Uso para el usuario Alumno 38

Figura 4.2. Diagrama de Caso de Uso del usuario Profesor 39

Figura 5.1. Interfaz de Usuario Alumno – Pedir Nueva Tutoría 42

Figura 5.2. Interfaz de Usuario Alumno – Confirmar Cita 42

Figura 5.3. : Gestión de Citas Alumno 43

Figura 5.4. : Gestión de Citas Profesor 43

Figura 5.5. Interfaz de Usuario Profesor – Modificar Horarios 43

Figura 5.6. Modelo Entidad-Relación de Tutoriapp 44

Figura 5.7. Extracto de la tabla Timeslot 47

Figura 5.8. Extracto de la Tabla Profesor_has_timeslot 47

Figura 5.9. Modelo Entidad-Relación Anotado 48

Figura 5.10. Código SQL de la vista View_profasig 49

Figura 5.11. Parte del Modelo Entidad-Relación para la unidad de Interacción c_tutoria 49

Figura 5.12. Construcción del repositorio de datos 50

Figura 5.13. Insercción de datos en el repositorio de datos 50

Figura 5.14. Construcción del repositorio de modelos 51

Figura 5.15. Comandos para proporcionar un estilo 51

Figura 5.16. Código ASL para la inserción de un botón 52

Figura 5.17. Código PHP para el manejo de la base de datos 53

Figura 5.18. Boceto de mensaje para cita correcta 53

Figura 5.19. Boceto de mensaje para cita incorrecta 53

18

Figura 5.20. Parte del Modelo Entidad-Relación para la parte PHP del proyecto. 54

Figura 6.1. Pantalla de Acceso al Sistema de Tutoriapp 56

Figura 6.2. Menú del Profesor 57

Figura 6.3. Menú del Alumno 57

Figura 6.4. Interfaz de Usuario - Pedir Nueva Tutoría 57

Figura 6.5. Elección de Asignatura 58

Figura 6.6. Elección de Profesor 58

Figura 6.7. Elección Hora 59

Figura 6.8. Interfaz de confirmación de cita por parte del Alumno 60

Figura 6.9. Cita reservada correctamente 60

Figura 6.10. Cita incorrecta 61

Figura 6.11. Comprobación Timeslot 61

Figuras 6.12. Tutoriapp versión móvil 61

Figura 7.1 Código SQL de la creación de la tabla profesor_has_asignatura 64

Figura 8.1. Descripción en ASL del modelo de usuario para el posible ususario Admin 68

Figura 8.2. Descripción en ASL del modelo de diálogo para el posible ususario Admin 69

Figura A6.1. Diagrama de Gantt (Parte 1/2) 96

Figura A6.2. Diagrama de Gantt (Parte 2/2) 97

Introducción

20

1 INTRODUCCIÓN

mpieza el verano. Has estado todo el año currando y por fin llegan las vacaciones. Harto de ver todos los días las caras a las mismas personas resulta obvio que quieras irte de viaje. Abres tu ordenador, entras en Google y buscas un buscador de vuelos, valga la redundancia. El primer

resultado te convence y llegas a eDreams. Rellenas un formulario con los datos acerca del viaje que deseas, y tras un rato pensando, decides que tu destino perfecto está en Tenerife. ¡Hora del pago! Te redirigen a la web de Iberia e introduces tus datos personales y tu tarjeta de crédito en el TPV virtual de La Caixa. ¡Reserva realizada!

Para todas estas anteriores tareas nos hemos servido de Aplicaciones Web. Si buscamos en la RAE qué significa ‘aplicación’ nos dice en su cuarta acepción que “En informática: Programa preparado para una utilización específica”. Por lo tanto, una aplicación web será la forma de realizar una tarea específica en la web (buscar un vuelo, realizar un pago, etc), a diferencia de un sitio web, que es más bien una herramienta enfocada a la comunicación. Es decir, una app web interactúa directamente con el usuario y sus datos.

En pocos años hemos sufrido una increíble evolución en el desarrollo de la web. Primeramente se diseñaron las páginas estáticas, en las que el cliente realizaba una petición y el servidor le respondía con la información que este quería visualizar.

Figura 1.1. Arquitectura Cliente-Servidor Tradicional

E

La programación es una carrera entre los desarrolladores,

intentando construir mayores y mejores programas a prueba

de idiotas, y el Universo, intentando producir mayores y mejores idiotas. Por ahora va ganando el Universo.

- Rich Cook -

21

DESARROLLO DE APLICACIÓN DE NOTIFICACIONES A TRAVÉS DE WAINE

Tras esto, hemos pasado a otra arquitectura en la que el servidor, tras recibir la petición del cliente, además tendrá que ejecutar disintas partes de código, manejar algunas bases de datos, para darle al cliente una respuesta personalizada: Las aplicaciones web.

Figura 1.2. Arquitectura Aplicaciones Web

Pero, ¿cómo se ha realizado esta rápida evolución en las últimas décadas?

1.1 Historia de las Aplicaciones Web [1]

Las aplicaciones web interactivas han ido progresivamente revolucionando el mundo virtual, enriqueciendo el contenido de las típicas páginas con texto estático. Fue con el ‘boom’ en 1995, en el que Rasmus Lerdorf trajo al mundo el lenguaje PHP, cuando las app web realmente despegaron. Pero este concepto existía de antes. De hecho, antes que el internet fuese accesible por el público en general, en 1987, el programador Larry Wall inventó el lenguaje ‘Perl’, uno de los primeros lenguajes de programación de aplicaciones web.

Netscape, el navegador web más antiguo y popular de la época, no podía quedarse atrás. Tan sólo tardó unos meses tras la llegada de PHP, en anunciar lo que sería, hasta el día de hoy, una de las tecnologías más importante de la historia de las páginas web: Javascript; un lenguaje que permitió un nuevo enfoque en el desarrollo de aplicaciones web, que serían mucho más interactivas para los usuarios. Por ejemplo, permitiría a los programadores cambiar de forma dinámica el contenido de una página web, que hasta el momento era estático.

Continuando con la historia, en 1996 Sabeer Bhatia y Jack Smith lanzaron Hotmail, el primer servicio de correo en línea. En 1997 llegó la plataforma Flash lanzó Shockwave Flash usada para añadir contenido interactivo a los sitios web. Posteriormente, Flash se convertiría en una gran herramienta para el desarrollo de aplicaciones web tras ser comprada por Macromedia y Adobe.

Fue también en 1997 cuando nació Google. Un buscador en línea creado por Larry Page y Sergey Brin presentado como un proyecto universitario. Google, gracias a su nueva forma de indexar páginas web y gracias a la explosión de internet del año 2001, se convirtió en lo que es a día de hoy: la empresa más grande y pionera del sector. Sus aplicaciones web, como Google Maps, Google Docs, Gmail, Calendar, entre otras, son usadas por millones de usuarios al día en todo el mundo.

No pasaron muchos años desde que internet fuese evolucionando a lo social. Empezó a ser una necesidad estar conectados entre amigos, conocidos y el mundo que nos rodea. Por ello, desde 2003, con la creación de MySpace, no han parado de proliferar aplicaciones web con el objetivo de socializar y conectar al mundo.

Introducción

22

Hoy en día las conocemos como redes sociales.

En 2004 Mark Zuckerberg creó Facebook; YouTube nació oficialmente en 2005. Por su parte, Twitter, se puso en marcha en 2006. Y esto ha sido tan sólo el comienzo.

Pero, retrocedamos a un punto importante que marcaría el resto de la historia de las aplicaciones web. En 2004, John Battelle y Tim O’Reilly introdujeron en nuestra vida el concepto de ‘Web como plataforma’ en una conferencia sobre la Web 2.0. Es decir, un software que aprovechan las ventajas que ofrecen internet y desvían el uso tradicional del escritorio.

Tanto JavaScript, como Shockwave Flash y muchos lenguajes más, se utilizan principalmente en su forma del lado del cliente (client-side), implementado como parte de un navegador web permitiendo mejoras en la interfaz de usuario. Es decir, no es necesario el proceso en el que el usuario instala un software en su PC para la realización de una tarea específica. Sólo necesita instalar un navegador web (actualmente todos los navegadores web modernos soportan la mayoría de lenguajes de programación web dinámica) para acceder a las millones de aplicaciones web que nos ofrece internet. Tan sólo un navegador para interactuar con miles de servidores y tecnologías diferentes.

1.2 Motivación y Objetivos

Como hemos podido observar, se han nombrado múltiples tecnologías diferentes, y tan sólo las más importantes. Actualmente, el número de tecnologías, metodologías y entornos que existen sería imposible de nombrar. Nos podemos hacer una idea mirando la siguiente gráfica:

Figura 1.3. Evolución del Desarrollo Web [2]

El desarrollo actual de cualquier aplicación web se ha convertido en una odisea. Además de un diseño muy preciso, será necesario que ésta se adapte a las exigencias del contexto actual que viva la web, puesto que una aplicación realizada hace 3 años, puede que ya esté obsoleta. Estos problemas se derivan en una elaboración más compleja, y por consiguiente, en el gasto de más tiempo y dinero.

23


Imaginemos que finalmente el desarrollador ha elegido realizar su aplicación basándose en modelos para crear las interfaces de usuario. Aún tendrá el problema de elegir qué entorno usar. Como vemos no es una decisión fácil. Tenemos que escoger un entorno entre todos los que existen, y además intentar minimizar el tiempo y el dinero invertidos en la medida de lo posible.

Es aquí donde entra en juego este trabajo: nuestro objetivo principal será dar cabida a estas respuestas y poder crear una aplicación web de una manera que no resulte demasiado costosa para un programador que sea la primera vez que deasarrolla su propia app. Además, intenaremos ahondar en una metodología que simplifique este proceso y enriquecer nuestro conocimiento acerca de las bases de datos. También, al ser un proceso de desarrollo basado en modelos, necesitaremos apoyarnos en distintos diagramas y bocetos que nos sacarán nuestro lado más creativo.

Introducción

24

25

2 INTRODUCCIÓN A WAINE

ese a lo vistoso de estas aplicaciones y su, a veces, aparente simplicidad, actualmente siguen siendo bastante complejas de implementar. Muchos de los sistemas y entornos de trabajo actuales para la creación de aplicaciones web son raramente empleados por desarrolladores nóveles, principal objetivo

de este trabajo. Por ello, el esfuerzo ha ido encaminado a Entornos de Desarrollo de Interfaces de Usuario Basado en Modelos (en inglés, MB-UIDE) de propósito general, que permitan generar Interfaces de Usuario (en inglés, UI) para distintos dispositivos y para aplicaciones de cualquier dominio.

Pero antes detengámonos un poco en qué es el Desarrollo de Interfaces de Usuario Basado en Modelos (En inglés, MB-UID).

2.1 MB-UIDs

El MB-UID ofrece a los desarrolladores la posibilidad de diseñar e implementar UIs de una manera sistemática y profesional. MB-UID está basado en la idea de que una UI puede ser completamente modelada por un conjunto de modelos los cuales componen diferentes facetas de la UI como el modelo de usuarios o el modelo de presentación, entre otros. La especificación de estos modelos consiste en una descripción abstracta basada en un lenguaje de descripción de UIs. Y aunque cada entorno MD-UIDE tienen definidos sus propios modelos y lenguajes, existen algunos que suelen ser bastante recurrentes: [3]

El Modelo de Usuarios, el cual define una distribución jerárquica de usuarios agrupándolos según el

rol que realizan.

El Modelo de Dominio, que describe los objetos que son accesibles por los usuarios a través de la UI.

El Modelo de Tareas, el cual especifica un conjunto de tareas que son capaces de cumplimentar un

grupo de usuarios, así como sus condiciones y relaciones temporales.

El Modelo de Presentación, usado para definir cómo se presentan los aspectos de la UI a los

usuarios.

El Modelo de Diálogo, que define un conjunto de acciones que el usuario puede llevar a cabo dentro

de varios estados del sistema. Se considera un puente entre los modelos de presentación y de

tareas.

Schlungbaum (Schlungbaum, 1996) define dos criterios necesarios para que una herramienta de Interfaces

de Usuario sea considerada un MB-UIDE [4].

1. Los MB-UIDEs deben incluir un modelo de alto nivel, abstracto y explícito que represente el

sistema interactivo a ser desarrollado.

2. Los MB-UIDEs deben explotar una clara relación entre la UI diseñada y la UI en ejecución. Esto

significa que existe algún tipo de transformación automática para implementar la UI final.

P

¡No me importa si no funciona en tu máquina, no

estamos vendiendo tu máquina!

- Vidiu Platon -

Introducción a WAINE

26

2.1.1 El Marco de Referencia Camaleón [4]

Han sido muchos los marcos de referencia que se han desarrollado a lo largo de los años para capturer conceptualmente las partes más importantes del proceso MB-UID. No es hasta 2002 cuando se crea el Marco de Referencia Camaleón (CRF) como resultado del proyecto EU-funded FP 5 Camaleon.

Se describe un marco de referencia que sirve para clasificar UIs que soporta múltiples objetivos o múltiples contextos de usos. Abarca desde las fases de diseño hasta las de ejecución. Además, el CRF provee un conocimiento unificado del contexto de la UI, que va más allá de unos simples pasos o métodos para la fase de desarrollo.

Figura 2.1. El marco de referencia camaleón (simplificado)

Como se observa en la Figura 2.2 el CRF describe diferentes capas de abstracción, las cuales son importantes para los MB-UIDs, y la relación entre ellas.

La capa de tareas y conceptos (Task & Concepts) hace referencia a la jerarquía de tareas que necesitan formar parte de la aplicación y que necesitan ser ejecutadas en cierto orden temporal para completar los objetivos de los usuarios (durante la interacción con una UI).

El capa de Interfaz de Usuario Abstracta (Abstract UI) expresa la UI como un conjunto de Objetos de Interacción Abstractos (en inglés, AIOs). Estos AIOs son independientes de cualquier plataforma o modalidad. Además, estos AIOs pueden ser agrupados lógicamente.

La capa de Interfaz de Usuario Concreta (Concrete UI) describe la UI como un conjunto de Objetos de Interacción Concretos (en inglés, CIOs). Estos CIOs dependen de la modalidad pero no del lenguaje de implementación. La CUI define más concretamente cómo la UI es percibida por los usuarios.

La capa de Interfaz de Usuario Final (Final UI) detalla la UI en términos del código fuente de implementación. Una FUI puede ser representada en cualquier lenguaje de programación de UIs. Además, una FUI puede ser interpretada o compilada.

El CRF no se tiene por qué seguir al pie de la letra, uno puede empezar en el nivel de abstracción que desee y seguir el orden lógico, dependiendo del Proyecto.

27


2.2 Web Application INterface Engine [3]

WAINE (Web Application INterface Engine) es un motor de desarrollo de aplicaciones web basado en modelos (MB-UIDE) que permite crear dichas aplicaciones cumpliendo unos objetivos básicos tales como la independencia, personalización, reutilización de UIs o minimización de la programación y el tiempo entre otros.

Figura 2.2. Logo WAINE

WAINE fue diseñado para facilitar el desarrollo de aplicaciones web a estudiantes de ingeniería que no estaban todavía completamente familiarizados con las actuales tecnologías web. El objetivo principal es que el estudiante pueda desarrollar una aplicación rápidamente evitando definir ciertos aspectos de la Interfaz de Usuario.

El Modelo de Dominio de WAINE describe los datos que el usuario va a manejar a través de la UI y se define gracias al Diagrama Entidad-Relación (ERD). En un nivel de abstracción más bajo, los siguientes modelos determinan más directamente el contenido y la apariencia de la UI:

2.2.1 El Modelo de Presentación

Especifica los elementos que se le presentarán al usuario. Se compone principalmente de dos elementos:

contenedores y formularios. Un formulario agrega AIOs tales como campos o botones de acción que

permiten al usuario realizar ciertas acciones (verificar, modificar o eliminar datos, por ejemplo). Por su parte,

los contenedores definen la estructura de la interfaz y el comportamiento básico de una unidad de

interacción. Los contenedores pueden ser de tres tipos: [5]

Form: Define una unidad de interacción compuesta por un único formulario.

Split: Crea una división espacial de la interfaz en varias áreas.

Relation: Especifica una división espacial en dos áreas que manejan datos cruzados.

Los contenedores usan parámetros para especificar el contenido de cada zona a través de una referencia a un formulario u otro contenedor.

2.2.2 El Modelo de Usuario

Los usuarios son agrupados en categorías dependiendo del rol que realicen. Un grupo puede tener uno o

varios usuarios, pero cada usuario sólo puede pertenecer a un grupo. Cada grupo tiene vistas específicas del

modelo de diálogo y opciones de seguridad.


28

2.2.3 El Modelo de Diálogo

Incluye un conjunto de menú de opciones accesibles por el usuario dependiendo del grupo en el que este se

encuentre. Cada opción del menú hace referencia a una unidad de interacción o puede ejecutar una acción

concreta.

2.2.4 Arquitectura

Hay varios eventos asociados a los Modelos de Usuario y Presentación que se ocurrirán al activar una acción específica. Por ejemplo, los eventos de Login y Logout son definidos en el modelo de Usuario, o los eventos FormLoad o FormUpdate en el de Presentación.

La UI se genera automáticamente siguiendo una arquitectura run-time. Este motor run-time construirá la UI final tras la típica petición del usuario (user request), estará formada por HTML, CSS y JavaScript y se mandará finalmente al navegador. El motor run-time usará tres repositorios para este proceso:

Modelos UI: Donde se guardan las instancias de los modelos ya descritos.

Datos de la UI: Donde se manejan los datos referenciados por la UI.

Personalización: Compuesto por un conjunto de archivos que pueden modificar ciertos aspectos de

la UI tales como fuentes, colores, estilos, etc

Figura 2.3. Arquitectura de WAINE [3]

Finalmente, el proceso desde que un usuario inicia la aplicación hasta que finaliza su experiencia, se podría resumir de la siguiente forma:

29


Cuando la aplicación se inicia, el motor run-time genera automáticamente un formulario de autenticación (login). Una vez que el usuario escribe su usuario y contraseña correctamente, el motor busca los objetos pertenecientes al Modelo de Diálogo que corresponden al usuario, o a su grupo, y muestra el menú de opciones. Tras la elección del usuario en el menú de opciones, el motor run-time podrá tanto ejecutar una acción específica o generar el código de una Unidad de Interacción. En este último caso, los repositorios de modelos y datos se utilizan para conseguir los AIOs que se precisen y los datos adjuntos. Es aquí cuando se genera la presentación concreta del usuario con las especificaciones descritas en el repositorio de personalización. Finalmente, el motor run-time genera la UI final. Este proceso se repetirá hasta que el usuario cierre la sesión.


30

31

3 PROCESO DE DESARROLLO DE UNA

APLICACIÓN EN WAINE

AINE ha definido un proceso sistemático para que los desarrolladores nóveles puedan generar sus aplicaciones acompañados por una metodología formal. Este proceso consta de cinco pasos. [6]

Al ser un proceso con unos pasos claramente marcados, podemos proyectarlos en el tiempo y realizar nuestro diagrama de Gantt, que se podrá ver en el ANEXO 6.

3.1 Proceso de Análisis

Realmente, este primer punto no es nada nuevo, es el primer paso a seguir a la hora de realizar cualquier

proyecto. Se necesita un pequeño documento de análisis que agrupe todos los requisitos y especificaciones

que el cliente quiere en la aplicación a desarrollar. En este documento también se añadirá las

funcionalidades, roles de usuarios e incluso algún boceto de las principales interfaces de usuarios.

3.2 Modelado de Conceptos

Dos nuevos documentos nacen a partir del documento de análisis inicial. Por una parte se elaborará el

Diagrama Entidad-Relación que modelará conceptualmente la base de datos, es decir, los datos que

manejará la aplicación. Este documento es la base de nuestro proyecto, quizá el documento más importante.

Un ERD erróneo o incompleto no hará más que poner trabas y aumentar el tiempo de realización del

proyecto. Además, este diagrama se empleará para generar de forma automática el modelo físico de datos y

el código SQL correspondiente a la base de datos de la aplicación.

Por otra parte se generará la tabla de roles/funcionalidades, una pequeña tabla que indique las acciones e interfaces de usuario necesarias para cada rol.

W

Los buenos programadores usan su cerebro, pero unas

buenas directrices nos ahorran tener que hacerlo en cada caso.

- Francis Glassborow-

Proceso de desarrollo de una aplicación en WAINE

32

Funcionalidad Func 1 Func 2 Func 3 Func 4 Func 5

Actor 1 ✓ ✓ ✓ ✓ ✓

Actor 2 ✓ ✓ ✓ ✓ ✓

Tabla 3.1. Ejemplo de tabla de roles/funcionalidad

3.3 Definir el Modelo de Presentación

En esta tercera fase se especificará cada espacio de trabajo de la interfaz de usuario a partir de anotaciones y

un refinamiento del ERD del apartado anterior. Para ello, se toma una porción del ERD que afecta a una

unidad de interacción que se va a definir y se anota sobre él las partes que lo forman, es decir, contenedores

y formularios, así como sus tipos. El producto resultante de esta fase es una colección de diagramas entidad-

relación anotados (ERD-IU).

Figura 3.1. Ejemplo de Diagrama Entidad-Relación Anotado

33


3.4 Descripción de todos los modelos en lenguaje ASL

A partir de los documentos elaborados (ERD-IU y Tabla Roles/Funcionalidad) se genera la especificación de

todos los modelos en lenguaje ASL. ASL, el Lenguaje de Especificación de Aplicaciones, es un lenguaje basado

en XML que usaremos para la definición de todos los modelos que usaremos en WAINE. Este lenguaje

presenta las siguientes ventajas:

Al ser XML una tecnología muy asentada hoy en día, los desarrolladores están muy familiarizados

con las tecnologías XML. Esto se resume en un fácil y rápido aprendizaje y multitud de información

en internet y otros medios.

Otra de las ventajas que ofrece este lenguaje es que existen multitud de herramientas para el

análisis de archivos XML e incluso para la conversión de estos archivos en otros formatos de

documentos.

Los archivos XML son archivos de texto. Esto permite a los desarrolladores reutilizar y compartir

código de otras aplicaciones, una característica fundamental en el desarrollo de aplicaciones.

ASL permite que el sistema sea independiente de las herramientas utilizadas para especificar el modelo de aplicación, así que podremos construir distintas herramientas de especificación para generar el código ASL e incluso podremos experimentar con diferentes métodos de especificación

3.5 Generación de Repositorios

Son 3 los repositorios que se generan en WAINE: Repositorios de Interfaz de Usuario, de Base de Datos y de

Configuraciones): En primer lugar, crearemos una instancia de la aplicación. Para ello nos serviremos de la

herramienta automática mkapp que generará dicha instancia enlazada a una versión del motor. Esta

herramienta también generará un repositorio de personalización/configuraciones con valores por defecto

para un funcionamiento básico de la aplicación y que posteriormente pueda ser modificado.

Para generar el repositorio de base de datos utilizaremos el código SQL obtenido a partir del diagrama entidad-relación. Con la sentencia

sqlite DB < [ruta.sql]

generaremos un repositorio sqlite, de nombre DB, a partir del archivo SQL especificado.

Proceso de desarrollo de una aplicación en WAINE

34

Finalmente, para construir el repositorio de la interfaz de usuario necesitaremos el archivo ASL. Usaremos la herramienta asl2mdb, un shellscript que utiliza un toolkit XML que funciona sobre la línea de comandos y permite generar el repositorio de interfaz de usuario sobre distintos tipos de soportes: varias bases de datos

relacionales (sqlite, MariaDB, PostgreSQL) e incluso ficheros CSV o DBF. ASL es el lenguaje común para poblar todos estos repositorios. Con la sentencia

asl2mdb –create –sqlite [ruta.asl]

crearemos el repositorio de interfaz de usuario en lenguaje sqlite a partir del archivo ASL especificado. El nombre por defecto será MDB.

35


36

4 TUTORIAPP

utoriapp es el nombre que se ha adoptado para la aplicación que se va a exponer a continuación. Consiste en la unión de las palabras tutoría y App (diminutivo de aplicación en inglés).

4.1 Motivación

Desde el Departamento de Telemática de la Universidad de Sevilla se pensó que sería una buena idea poner este tipo de tecnología en marcha para demostrar que, efectivamente, un alumno novel, sin experiencia en la programación de aplicaciones web, podría realizar su propia app de una manera sencilla, rápida y sistemática.

También se pensó que está aplicación no fuese tan sólo una práctica más, sino que se pudiera usar en un futuro dentro del propio departamento. Por ello, sólo faltaba pensar que tipo de aplicación, aún sin implementar dentro de la Escuela, se debería realizar.

Primeramente, se pensó en actualizar el sistema de adjudicación de Trabajos de Fin de Grado y Master de la Escuela de Ingenieros, pero se rechazó debido a su alta complejidad. Posteriormente, se observó la problemática existente a la hora de asistir a las tutorías entre alumnos y profesores. Y es que, pese a que los docentes tienen un horario estándar de tutorías predefinido durante todo el curso, muchas veces no se encuentran en su despacho para atender las dudas de los alumnos por múltiples motivos; por lo este debe esperar un tiempo indeterminado, aún sin saber si el profesor se encuentra disponible ese día, o volver a intentarlo en otro momento. Es por lo se optó por la creación de una aplicación web donde los alumnos pudieran reservar y gestionar sus tutorías con los profesores, y a su vez, que los docentes también pudieran llevar el control de su calendario y su tiempo. De esta forma, tanto pupilos como maestros gestionarían mejor su tiempo y llevarían un mejor control sobre su trabajo.

De esta propuesta nace TUTORIAPP: una aplicación web, creada en el MB-UIDE WAINE, donde los alumnos podrán pedir una cita para una tutoría tal y como se ha explicado anteriormente.

T

Podría parecer que hemos llegado a los límites

alcanzables por la tecnología informática, aunque uno

debe ser producente con estas afirmaciones, pues tienden a sonar bastante tontas en cinco años.

- John Von Neumann, 1949-

37


4.2 Explicación de la Propuesta

El alumno, tras ingresar en la aplicación y, por tanto, mostrarse el menú de alumno, podrá elegir entre las opciones ‘Pedir nueva tutoría’ o ‘Gestionar tutorías’. Haciendo click en la primera opción, podrá pedir una nueva cita con el profesor de la asignatura que elija y en la hora y fecha que desee, dentro de la lista de horas y fechas que el docente tenga activadas para esa semana. Se podrá pedir una cita con una antelación de 8 días. Tras esta solicitud, la aplicación solicitará las credenciales UVUS-DNI para confirmar la operación, además de una breve descripción, si el alumno lo desea. Cabe señalar, que esta última acción no formará parte de la estructura de WAINE, sino que corresponderá con una serie de páginas PHP que explicaremos más adelante. Dentro de la opción ‘Gestionar tutorías’ el alumno podrá ver que tutorías tiene pendientes, realizar modificaciones sobre la misma, e incluso eliminarla si no pudiera asistir.

Si nos trasladamos ahora al menú de profesor se podrán realizar también dos acciones: ‘Gestión de tutorías’ y ‘Gestión de horarios’. La primera será muy parecida a la de los alumnos. El docente podrá ver una lista de las citas propuestas, y realizar modificaciones, tales como aceptarla o no, e incluso tomar los datos para enviar un correo al alumno en caso de que fuera necesario.

Para explicar la segunda parte del menú docente partiremos de la base de que los profesores tienen 2 tipos de horarios: El primero será el horario estándar predefinido para todo el curso. El segundo corresponderá al horario para las próximas dos semanas, el cual será el que se muestre al alumno a la hora de elegir fecha para su tutoría. Este último será siempre exactamente igual al predefinido para todo el curso a no ser que el profesor lo modifique expresamente en el apartado ‘Gestion de Horarios’. En este apartado, el docente podrá modificar tanto su horario estándar para todo el curso, como el de las próximas 2 semanas. Resumiendo, si el profesor no realiza ningún cambio en ningún horario, siempre se mostrará como ‘Horario de las próximas 2 semanas’ el ‘Horario estándar’.

4.3 Diagramas de Caso de Uso

Para resumir un poco mejor lo que se ha explicado con anterioridad, en este punto se proponen los distintos diagramas de uso para mostrar las acciones que pueden realizar tanto el usuario alumno como el usuario profesor.

Básicamente dispondremos de dos actores: usuario y profesor; y de las acciones que pueden realizar sobre las 4 unidades de interacción anteriormente explicadas. No se presenta los casos de uso del actor ‘Usuario no Autenticado’ pues que solo podría autenticarse en el sistema.

TUTORIAPP

38

4.3.1 Diagramas de Caso de Uso para Alumno

CASO DE USO Operaciones disponibles para un alumno

OBJETIVO Realizar operaciones sobre TUTORIAPP

ACTORES Alumno

DISPARADOR Alumno ingresa en el menú principal de

TUTORIAPP

PRECONDICIONES Estar autenticado como alumno en el sistema

CURSO NORMAL DE LOS EVENTOS

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMA

Alumno pide nueva tutoría Tutoriapp redirige a la página de confirmación y

le muestra los datos de la misma.

Alumno hace click en Gestionar Tutorías Tutoriapp le da las opciones de ver, modificar y/o

eliminar sus citas.

Tabla 4.1. Tabla Casos de Uso para el usuario Alumno

Figura 4.1. Diagrama de Casos de Uso para el usuario Alumno

39


4.3.2 Diagramas de Caso de Uso para Profesor

Figura 4.2. Diagrama de Caso de Uso del usuario Profesor

CASO DE USO Operaciones disponibles para un profesor

OBJETIVO Realizar operaciones sobre TUTORIAPP

ACTORES Profesor

DISPARADOR Profesor ingresa en el menú principal de

TUTORIAPP

PRECONDICIONES Estar autenticado como un profesor en el sistema

CURSO NORMAL DE LOS EVENTOS

ACCIÓN DE LOS ACTORES RESPUESTA DEL SISTEMA

Profesor hace click en Gestionar Horarios Tutoriapp le da las opciones de modificar su

horario general, y su horario próximo.

Profesor hace click en Gestionar Tutorías Tutoriapp le da las opciones de ver, aceptar o

rechazar sus citas.

Tabla 4.2. Casos de Uso del usuario Profesor

TUTORIAPP

40

41


5 DESARROLLO DE LA APLICACIÓN SEGÚN LA

METODOLOGÍA DE WAINE

iguiendo con el proceso explicado en el punto ‘Proceso de desarrollo de una aplicación en WAINE’, procedemos a empezar a construir nuestra aplicación web TUTORIAPP.

5.1 Análisis

Ya se ha explicado cómo queremos que sea la aplicación en el punto anterior, cómo debe ser su funcionamiento. Ahora, realizaremos un esbozo de cómo serán las principales interfaces de usuarios.

En este sistema sólo aparecen dos roles: alumno y profesor. En cada uno de ellos podrá existir entre 1 y múltiples usuarios. Explicaremos el criterio de usuarios del sistema más adelante.

En la aplicación se identifican 4 unidades de interacción: 2 para alumnos y otras 2 distintas para profesor. El alumno podrá reservar una tutoría (Unidad de Interacción c_tutoria) o gestionar las ya existentes (c_gestion_alum); mientras que el profesor podrá gestionar sus tutorías (c_gestion_prof) o modificar sus horarios (c_horarios).

Una vez conocidas las interfaces, se proponen varios bocetos de las unidades de interacción de la aplicación:

S

Hay dos formas de escribir programas sin errores; sólo

la tercera funciona.

- Alan J. Perlis-

Desarrollo de la aplicación según la metodología de WAINE

42

Figura 5.2. Interfaz de Usuario Alumno – Confirmar Cita

Figura 5.1. Interfaz de Usuario Alumno – Pedir Nueva Tutoría

43


Figura 5.3. : Gestión de Citas Alumno Figura 5.4. : Gestión de Citas Profesor

Figura 5.5. Interfaz de Usuario Profesor – Modificar Horarios


44

5.2 Modelo Entidad-Relación

El Modelo Entidad-Relación es la base de cualquier proyecto que se precie; tanto si es creado con WAINE como si es creado con cualquier otra tecnología. Es la piedra sobra la que edificaremos nuestra aplicación web. Con un buen Modelo E-R se simplificará sobremanera la programación de la app y será todo fácil y sencillo, según lo planeado. De la misma forma, con un mal diseño del Modelo E-R surgirán problemas imprevistos y aumentará, por tanto, el tiempo de programación y plazos de entrega. Por ello, podemos decir que este es el punto más importante de todos los que se compone la metodología de construcción de aplicaciones de WAINE.

Hacemos mucho hincapié en el buen diseño de este Modelo porque WAINE añade además algunas restricciones propias a este apartado, por lo que hace mucho más complejo el perfecto diseño del Modelo. Probablemente, no será a la primera cuando un programador novel encuentre el diseño final del Modelo E-R para su aplicación web en WAINE, por ello, puede que este punto se convierta en iterativo, necesitando retroalimentación de los problemas que surjan a la hora de programar. Explicaremos estas restricciones y la evolución que ha sufrido el Modelo E-R en este proyecto más adelante en el apartado de Restricciones y Complicaciones.

El Modelo E-R o Diagrama E-R es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema así como sus interrelaciones y propiedades. Se compone de:

Entidad: Representa un concepto del mundo real con existencia independiente.

Atributos: Son las características que definen o identifican a una entidad.

Relación: Dan información acerca de cómo interactúan dos entidades.

En este caso, nos ayudará a modelar el Repositorio de Datos de la UI: la base de datos. Para verlo con más detalle, puede acceder al ANEXO 5.

Figura 5.6. Modelo Entidad-Relación de Tutoriapp

45


Primeramente nos encontramos en la parte superior izquierda con la entidad alumno. Esta representará a un alumno real y sus atributos son:

ALUMNO

UVUS Usuario Virtual de la Universidad de Sevilla que es único para cada alumno. Por

tanto, será clave primaria.

NOMBRE_ALUM Nombre del Alumno

PROFESOR Apellidos del Alumno

DNI Documento Nacional de Identidad. Este atributo, junto con el Uvus, se usará como

credenciales para que el alumno se autentique y confirme una tutoría.

EMAIL Correo electrónico del alumno

Tabla 5.1: Atributos de la entidad alumno

Siguiendo por la parte superior derecha encontramos a la entidad profesor, con sus atributos nombre, despacho, email y teléfono. La clave primaria en esta entidad será idprofesor correspondiente a un identificador unívoco de cada docente.

PROFESOR

IDPROFESOR Identificador unívoco de cada docente.

NOMBRE_PROF Nombre del Profesor

DESPACHO Numero de despacho dentro del Departamento

TELEFONO Numero de teléfono del despacho del Profesor

EMAIL Email del Profesor

Tabla 5.2: Atributos de la entidad profesor

En la esquina inferior derecha se presenta la entidad asignatura, con sus atributos nombre y curso. En este caso, la clave primaria corresponderá con idasignatura, un identificador único para cada asignatura.

ASIGNATURA

IDASIGNATURA Identificador único de cada asignatura.

CURSO Entero equivalente al curso donde se imparte la asignatura.

Tabla 5.3: Atributos de la entidad asignatura

Un profesor podrá estar asociado a varias asignaturas, y una asignatura podrá ser impartida por varios profesores (Relación M:N), por lo que se crea una nueva tabla de relación 1:N con cada una de las entidades anteriores, denominada profesor_has_asignatura; donde encontraremos un listado de todos los profesores y las asignaturas que imparten. Cada entrada de esta tabla corresponderá con una dupla asignatura-profesor única. La clave primaria será pk, un identificador único de cada entrada de la tabla, y los atributos idprofesor e idasignatura corresponderán con claves externas a las entidades anteriores.


46

PROFESOR_HAS_ASIGNATURA

PK Identicador único de cada entrada

IDASIGNATURA Identificador único de cada asignatura (clave externa)

IDPROFESOR Identificador único de cada profesor (clave externa)

Tabla 5.4: Atributos de la entidad profesor_has_asignatura

Parece redundante que si en esta tabla la dupla profesor-asignatura ya es única y cuya pareja pudiera ser clave primaria, se añada además una clave primaria tal y como PK, esto es así debido a una de las principales restricciones del modelado de datos de WAINE. Se explicara más adelante en el apartado de Restricciones y Complicaciones.

Ahora llega el momento de introducir el concepto de TimeSlot. El TimeSlot, o ranura de tiempo, corresponde a un espacio de tiempo de 15 minutos en el cual se va a dividir el calendario lectivo, que es el tiempo que dura una tutoría promedia. El TimeSlot se compone de fecha y hora. En una hora, por tanto, existirán 4 TimeSlots. El alumno, tras elegir la asignatura y el profesor, añadirá también un TimeSlot correspondiente a la fecha y hora a la que asistir a la tutoría. Todos los TimeSlots existentes de un calendario lectivo se agruparán en la Tabla de su mismo nombre, cuyos atributos son:

TIMESLOT


FECHA Día del año al que pertenece el TimeSlot en el formato AAAA-MM-DD

HORA Hora del día (periodo de 15 minutos) en el formato HH:MM

Tabla 5.5: Atributos de la entidad timeslot

Como hemos comentado, en esta tabla estarán todos los TimeSlots existentes de un año lectivo, por lo que estaremos ante una tabla de más de 40.000 entradas.

Debido a que un profesor va a tener varios (muchos) TimeSlots y a su vez un mismo TimeSlot (p.e 2017-10-25 10:15) puede corresponder a varios profesores, estamos ante una relación M:N en la que se crea una nueva entidad que denominaremos profesor_has_timeslot donde se crearán los horarios de los docentes. En esta tabla cada entrada corresponderá con el identificador de un profesor y el identificador de un TimeSlots, además de un booleano que denominaremos ‘ocupado’, el cual definirá si el TimeSlot de un profesor está ya siendo usado en alguna cita y por lo tanto que no se muestre como opción para el alumno.

PROFESOR_HAS_TIMESLOT


IDPROFESOR Identificador único de cada profesor (clave externa)

TIMESLOT_PK Identificador único de cada timeslot (clave externa)

OCUPADO Booleano para identificar si el timeslot de un profesor está ya ocupado.

0 = libre - 1 = ocupado

Tabla 5.6: Atributos de la entidad profesor_has_timeslot

47


Pongamos un ejemplo, si el profesor con id = 0 tiene horario de tutorías todos los lunes de 10:00 a 11:30, sus entradas en la tabla profesor_has_timeslot serán las siguientes:

Figura 5.7. Extracto de la tabla Timeslot Figura 5.8. Extracto de la Tabla Profesor_has_timeslot

Como se puede observar, entre las 10 y las 11:30 existen 6 periodos de 15 minutos, por lo que existirán 6 TimeSlots por cada Lunes para el profesor de id = 0. Vemos que timeslot_pk es la clave externa que referencia la fecha y hora de la tabla timeslot. Además, podemos comprobar que ninguno de los timeslots expuestos del profesor con id = 0 está ocupado, ya que todos los booleanos son 0.

Finalmente, la tabla central cita se crea de la unión de las entidades anteriores. Representa a una tutoría propiamente, y sus atributos son:

CITA

PK Identicador único de cada cita

UVUS Identificador del alumno que reservó la cita (Clave externa a la tabla

Alumno)

PROFESOR_HAS_TIMESLOT_PK Clave externa a la tabla Profesor_has_timeslot que hace referencia al

profesor, hora y fecha de la cita

DESCRIPCION (Opcional) Se usará para que el alumno pueda escribir una breve

explicación acerca del tema del que desea hablar.

CONFIRMADA Booleano para que el docente confirme la cita.

0 = sin confirmar – 1 = confirmada

Tabla 5.7: Atributos de la entidad cita

Se han incluido los archivos SQL que se han usado para la creación de esta base de datos, así como algunos ejemplos de sentencias INSERT en el ANEXO 3: Archivos SQL.


48

5.3 Modelo Entidad-Relación Anotado

Una vez definido los roles y las interfaces de usuario, podemos definir la tabla de roles/funcionalidad para clasificar que espacios de trabajo puede manejar cada usuario. Ademas de las ya mencionadas interfaces de usuario, se ha añadido meta.container.appinfo que es una unidad de interacción empleada para mostrar diversa meta-información de esta aplicación.

Funcionalidad c_tutoria c_gestion_alum c_gestion_prof c_horarios meta.container.appinfo

Alumno ✓ ✓

✓

Profesor

✓ ✓ ✓

Tabla 5.8: Tabla roles/funcionalidad

Además, hemos podido definir más detalladamente la unidad de interacción c_tutoria que es la que se va a desarrollar en este proyecto. Partiendo del anterior Modelo Entidad-Relacion podemos crear los diagramas anotados para dicha entidad

Figura 5.9. Modelo Entidad-Relación Anotado

49


Se puede observar además que se ha creado una vista de nombre view_profasig que será la fuente del formulario f_profesor_aux. Esto es así a causa de las restricciones de WAINE, y lo usaremos para mostrar la información de los profesores ya que de otra forma era imposible. El código de dicha vista es el siguiente:

Finalmente, como resumen, podemos mostrar que para esta unidad de interacción se usará la siguiente parte de la base de datos:

Figura 5.11. Parte del Modelo Entidad-Relación para la unidad de Interacción c_tutoria

5.4 Descripción de los Modelos en Lenguaje ASL

Una vez tenemos la tabla roles/funcionalidad y el Modelo Entidad-Relación anotado, se genera la especificación de los modelos en lenguaje ASL. Para evitar incomodidad al lector, se han incluido estos archivos en el ANEXO 1: Archivos ASL.

Figura 5.10. Código SQL de la vista View_profasig


50

5.5 Construcción de repositorios

Primeramente, generaremos la base de datos de la aplicación, utilizando para ello el código SQL obtenido del diagrama Entidad-Relación. Obtendremos una base de datos Sqlite de nombre DB.

Seguidamente rellenaremos las distintas tablas de la BBDD que necesiten datos previos con los distintos archivos INSERTs que nos hemos creado.

A continuación, se crea el repositorio de la interfaz de usuario a partir del archivo ASL que hemos creado. Utilizaremos la utilidad as2mdb que hemos explicado con anterioridad. Obtendremos la base de datos de la UI con el nombre MDB.

Figura 5.12. Construcción del repositorio de datos

Figura 5.13. Insercción de datos en el repositorio de datos

51


Para completer el repositorio de configuraciones hemos elegido usar un paquete predefinido con el que proporcionaremos a nuestra aplicación un estilo parecido al que se usa en la ETSI. La secuencia de comandos que hemos usado para ello es la siguiente:

A modo de dato cabe comentar que se ha usado el protocolo SCP para el traspaso de archivos entre mi ordenador y el servidor de WAINE, y viceversa.

Figura 5.15. Comandos para proporcionar un estilo

Figura 5.14. Construcción del repositorio de modelos


52

5.6 Formulario de autenticación externo

Para completar el proceso de reserva de una tutoría, se ha hablitado una página en PHP donde el alumno podrá escribir sus credenciales (UVUS-DNI) y el sistema comprobar que es un usuario válido. Además de eso, podrá escribir su email (para incluirlo si no existiera en la BBDD o modificarlo) y una descripción opcional acerca de la cita para que el profesor pueda estar preparado.

Esta unidad de interacción, pese a que hace uso de la base de datos que ya hemos presentado, no forma parte de ninguno de los modelos del sistema. Compone una unidad de interacción individual y apartada de los diagramas a la que se llegará a través de un botón que se ha habilitado en el formulario f_hora unidad de interaccion c_tutoria. Esto se ha hecho así porque era la forma más cómoda de realizar un formulario de autenticación que recorriera las tablas de nuestra BBDD. El botón, de nombre ‘Solicitar’, se usará tras elegir todos los datos de la cita. El extracto de código es el siguiente:

Este botón nos redirige a otra página en PHP que necesitaremos para realizar el formulario UVUS-DNI de confirmación de la cita por parte del alumno. En este código, puro PHP, se realizará un amplio manejo de la base de datos, correspondiente a las siguientes acciones:

1. Búsqueda en la tabla alumno del emparejamiento UVUS-DNI correcto que valide la acción de un

usuario.

2. Si la anterior búsqueda es satisfactoria, se realizará un nuevo INSERT en la tabla Cita incluyendo los

datos de la misma. (Los identificadores de timeslot y profesor se enviarán a la página PHP mediante

el método POST, el identificador de alumno se introducirá cuando el alumno escriba su UVUS).

3. Una vez recibido el identificador del Timeslot, este se marcará como ocupado en la tabla

profesor_has_timeslot, (acción UPDATE) para que no pueda ser escogido por otro usuario.

El código completo de la parte PHP se puede encontrar en el ANEXO 2: Archivos PHP, y a continuación, se muestra la parte relacionada con la gestión de la base de datos que acabamos de explicar:

Figura 5.16. Código ASL para la inserción de un botón

53


El boceto de esta página ya se presentó en la figura 5.2 pero ahora, además, podemos añadir los mensajes que podrían aparecer al reservar, correcta o incorrectamente, una cita.

Figura 5.18. Boceto de mensaje para cita correcta

Figura 5.19. Boceto de mensaje para cita incorrecta

Figura 5.17. Código PHP para el manejo de la base de datos


54

Para esta parte del proyecto, la parte de la Base de Datos a utilizar será la siguiente:

Figura 5.20. Parte del Modelo Entidad-Relación para la parte PHP del proyecto.

55


Resultado

56

6 RESULTADO

Si hemos seguido los pasos descritos, ahora debemos tener nuestra flamante aplicación web puesta en marcha. Entonces, comencemos a verla desde el comienzo

6.1 Pantalla de Acceso al Sistema

La pantalla de acceso al sistema es la primera pantalla que se le muestra al usuario al introducir la URL de la aplicación. Se crea automáticamente al utilizar la herramienta mkapp de WAINE. En nuestro caso, nuestra interfaz de autenticación será la siguiente:

Figura 6.1. Pantalla de Acceso al Sistema de Tutoriapp

Nuestra recompensa se encuentra en el esfuerzo y no en

el restulado. Un esfuerzo total es una victoria completa.

- Mahatma Gandhi-

57


6.2 Menús

Como ya hemos explicado durante todo el proceso, los usuarios alumno y profesor tendrán distintos menús, pues así se ha definido en el modelo de diálogo. Así se ven los menús de ambos usuarios:

6.3 Pedir nueva tutoría

Figura 6.4. Interfaz de Usuario - Pedir Nueva Tutoría

Figura 6.2. Menú del Profesor Figura 6.3. Menú del Alumno

Resultado

58

Cuando el alumno hace click en ‘Pedir Nueva Tutoría’ se le muestra la interfaz de usuario que se puede observar en la figura 6.4. Ahora llegó el momento de reservar la cita.

1. Primeramente, elegimos la asignatura para la que necesitamos ayuda, de la lista desplegable del primer formulario.

Figura 6.5. Elección de Asignatura

2. Seguidamente se actualizará el navegador con todos los profesores que imparten dicha asignatura, para que podamos elegir uno.

Figura 6.6. Elección de Profesor

59


3. Tras elegir el profesor para el que queremos la cita, se actualizará un formulario con los datos del mismo, por si fuesen de necesidad, además del ultimo formulario, de tipo table, con las fechas y horas de tutorías disponible y que el alumno puede escoger. Cabe señalar que sólo se muestran 8 días en adelante desde la fecha actual en el momento de la reserva, por lo que será imposible realizar una cita para más de 8 días.

Figura 6.7. Elección Hora

4. Por ejemplo, elegimos que el día 10 de Septiembre a las 10:15 es la cita que queremos reservar, y hacemos click en el botón solicitar. En este momento, somos redigirido a la página Reserva.php donde confirmaremos nuestro uvus y dni gracias al siguiente formulario.

Resultado

60

Figura 6.8. Interfaz de confirmación de cita por parte del Alumno

5. Si hemos introducido los datos correctos, nos aparecerá el siguiente mensaje de confirmación:

Figura 6.9. Cita reservada correctamente

61


6. Por el contrario, nos aparecerá el siguiente mensaje con la opción de volver atrás y modificar los datos incorrectos.

Figura 6.10. Cita incorrecta

7. Finalmente, tras reservar una cita correctamente, podemos volver a la interfaz principal y comprobar cómo para el profesor de la reserva, ya no existe el timeslot referente al 10 de Septiembre y las 10:15

Figura 6.11. Comprobación Timeslot

6.4 Versión para móvil

Las páginas PHP de este proyecto, se han optimizado para su buena visualización en la version móvil.

Figuras 6.12. Tutoriapp versión móvil

Resultado

62

63


7 RESTRICCIONES Y COMPLICACIONES

n este punto vamos a intentar relatar las diferentes restricciones que nos ha ido poniendo WAINE a lo largo del desarrollo de nuestra aplicación web, además de algunas complicaciones que nos han surgido de la construcción de la misma.

7.1 Claves primarias en las entidades de la base de datos

Como ya hemos comentado anteriormente, una de las principales dificultades que nos encontramos a la hora de desarrollar una aplicación web en WAINE es la peculiar forma que debe adoptar el Modelo Entidad-Relación, y es que cada entidad del modelo sólo puede poseer un único campo como clave primaria (este puede ser un entero, texto, etc). Esto es así debido a que sólo puede ser usado un campo de un formulario para filtrar el resultado del siguiente, dentro de una misma estructura. Por ejemplo, dentro de la estructura c_tutoria_aux para filtrar el horario y fecha disponible de un profesor, usaremos el idprofesor del docente que el alumno escoja en el navegador. Para ello usaremos la sentencia:

<param ord="2" name="source_filter_field" value="idprofesor"/>

Y entonces, ¿qué hacemos con las tablas del modelo de las cuales necesitamos más de un campo como clave primaria? Sabemos, por la teoría de las base de datos, que cuando una nueva tabla nace de una relación M:N entre dos entidades, dicha tabla posee como clave primaria el conjunto de campos que son clave primaria en las entidades que componen la relación, y a su vez, estos campos serán claves externas a los campos que referencian. Cuando este caso ocurre, o cuando por diseño necesitamos más de un campo como clave primaria, WAINE lo arregla de la siguiente forma:

1. Crearemos un nuevo campo que será nuestra clave primara. Por defecto, un entero auto numérico

que llamaremos PK (Primary Key).

2. Usaremos la sentencia SQL ‘UNIQUE’ para el conjunto de campos que deberían ser clave primaria de

la forma tradicional. De esta forma, conseguimos que ese conjunto de campos sea único, es decir, el

mismo efecto que la clave primaria.

3. Añadimos el resto de atributos de la nueva entidad.

Por ejemplo, de la relación M:N entre Asignatura y Profesor, nace la tabla Profesor_has_asignatura la cual debería tener como clave primaria el conjunto (idprofesor, idasignatura), sin embargo, se creará de la siguiente forma:

E

La función de un buen software es hacer que lo complejo apaerente ser simple.

- Grady Booch-

Restricciones y complicaciones

64

Figura 7.1 Código SQL de la creación de la tabla profesor_has_asignatura

Observamos cómo, siguiendo los puntos anteriores, hemos creado el campo pk que usaremos como clave primaria y que el conjunto (idprofesor, idasignatura) será único.

7.2 ¿Usuarios como parte del modelo de usuarios o de datos?

Otra de las dificultades que nos encontramos a la hora de diseñar nuestra aplicación es la duda de si el alumno y/o profesor se considerará parte del modelo de usuarios o no, es decir, si en la pantalla de Login del comienzo cada usuario introducirá sus credenciales personales o, si por el contrario, formará parte del sistema como una entidad de la base de datos.

Por la parte de alumno se pensó que considerarlos parte del modelo de usuarios era inviable, puesto que el desarrollador debería crear en ASL (o un usuario como administrador desde algún formulario habilitado en WAINE) usuario por usuario como parte del sistema. Cada año deberían darse de alta en torno a 200 nuevos usuarios y cualquier alta o baja que hubiera durante el año correspondería a una nueva modificación del código. Un método costoso y poco escalable.

La solución que se ha adoptado es que cualquier alumno pueda entrar en la aplicación utilizando unas credenciales comunes, como podrían ser:

Usuario: alum

Contraseña: alum

Y que sea a la hora de confirmar la cita cuando el sistema le pida su UVUS y DNI como forma de comprobación de que es un usuario válido. Cada año se pediría a la secretaría de la facultad el listado de todos los alumnos con sus respectivos UVUS y DNI, al que tienen acceso todos los profesores. Posteriormente, estos datos se introducirían en la tabla alumno de la base de datos. De esta forma conseguimos en poco tiempo actualizar todos los alumnos y evitando crear una contraseña para cada uno, puesto que se usaría el UVUS como nombre de usuario y DNI como contraseña.

Por la parte del profesor se puede utilizar cualquiera de los dos métodos. Usando el procedimiento anterior, el docente entraría en la aplicación usando las credenciales:

Usuario: prof

Contraseña: prof

65


Y se le solicitarían sus credenciales (usuario y contraseña) a la hora de realizar alguna gestión de sus horarios o para ver sus tutorías pendientes.

Por otra parte, podríamos introducirlos como usuarios del sistema, ya que los docentes se suelen mantener invariantes durante años, y los cambios que pudieran producirse en el departamento suelen ser mínimos. Usando este método enlazaríamos la tabla profesor con el repositorio de datos donde se encuentran la información de los usuarios de la aplicación y los docentes ingresarían en la aplicación usando un usuario y contraseña propios.

Actualmente no está desarrollado ninguno de los dos métodos debido a que aún no se ha construido la parte del menú del profesor. Esto se realizará en un futuro.

Restricciones y complicaciones

66

67


8 LÍNEAS FUTURAS

En este punto vamos a intentar esbozar un poco cuáles podrían ser los siguientes pasos a desarrollar en nuestra aplicación, así como una reflexión sobre el futuro de las aplicaciones web. Para esta aplicación, son dos las principales líneas de avance futuras.

8.1 Desarrollo de la aplicación web

Como ya hemos comentado, la aplicación está incompleta. Pese a que el grueso de la misma está desarrollada (bocetos, diagramas, modelos, unidad de interacción principal, etc), aún faltan tres unidades de interacción por construir: las dos de gestión de tutorías, por parte de alumno y profesor, y la de modificación de horarios del docente.

8.1.1 Gestión de Tutorias del Profesor

Esta sería la unidad de interacción más fácil de desarrollar. Tan sólo constaría de un formulario, del tipo table en la que, ayudándonos de un scroll, el docente pueda visualizar las citas más próximas.

Además, incluiríamos varios botones, como Aceptar/Rechazar cita o Enviar Correo al Alumno en caso de que queramos comunicarle algún tema previo al pupilo.

8.1.2 Gestión de Tutorías del Alumno

Esta unidad de interacción podría perfectamente ser cómo la del punto anterior, de hecho, podríamos copiar el mismo bloque y poner un formulario del tipo table para que el alumno pueda observar sus tutorías. Los botones serían los de Eliminar o Modificar Cita.

Pero bien, ahora nos encontramos con un problema. Como hemos comentado con anterioridad, los alumnos no son usuarios del modelo de usuarios de la app. Por consiguiente, para que un alumno pueda ver sus citas dentro de esta unidad de interacción, deberá haberse autenticado previamente en algún formulario.

Podríamos, de nuevo, usar una página PHP aislada tal y como hemos hecho con la unidad de interacción c_tutoria y que esta página sea la que nos muestre las citas, pero entonces no se construiría nada en WAINE y la unidad c_gestion_alum quedaría obsoleta, no tendría sentido. Se compondría únicamente de un botón que redirigiría a esta página PHP externa. Por ello, tendremos que ver cómo construir un formulario de autenticación en WAINE y que, tras ello, pueda actualizar el formulario de tipo table donde se mostrarán todas las citas.

No pienso nunca en el futuro porque llega muy pronto.

- Albert Einstein -

Líneas futuras

68

8.1.3 Modificación de Horarios del Profesor

Estamos ante, probablemente, la unidad de interacción más difícil de desarrollar. Va a requerir un amplio manejo de las bases de datos, así como un script que pueda jugar y dividir el tiempo.

Como ya hemos comentado, el profesor dispone de dos horarios: Uno para las próximas dos semanas, y uno general. El horario más próximo será el que se muestre, y además será igual que el general siempre y cuando yo haya cambios expresos del profesor.

Pese a que hablamos de “dos horarios”, tan sólo existe una tabla: profesor_has_timeslot. La diferencia reside en que si el docente realiza una modificación en el horario próximo, tan sólo se realizará un UPDATE de la tabla en las próximas 2 semanas; si por el contrario realiza una modificación en su horario general, se ejecutará un UPDATE en toda la tabla.

Pues bien, todos estos detalles deberán controlarlos un script, en PHP, en un evento después de que el profesor acepte los cambios. Además, el mismo u otro script, deberá controlar la partición de tiempos y timeslots. Si el profesor decide que durante las próximas dos semanas tan sólo va a tener tutoría los martes de 9:30 a 11:00, el script deberá conocer que es 1 hora y media, lo que equivalen a 6 timeslots; posteriormente, buscar los 12 timeslots correspondientes a los 2 martes más próximos en la tabla timeslots y finalmente realizar el UPDATE en la tabla profesor_has_timeslots. Una tarea harto difícil.

8.2 Usuario Admin

Tras el desarrollo completo de la app, la otra línea de avance de esta aplicación podría ir dirigida hacia el usuario administrador. Un usuario, que forme parte del modelo de usuarios y que tenga un menú y unas interfaces de usuarios distintas a las de alumno y profesor. Este nuevo usuario, será un nuevo actor del sistema, y su modelo de diálogo y presentación se compondrán de nuevas unidades de interacción aún no esbozadas.

Figura 8.1. Descripción en ASL del modelo de usuario para el posible ususario Admin

Por ejemplo, este usuario podrá gestionar los usuarios del sistema; incluir o quitar profesores, y actualizar la tabla de alumnos cada año. También podría manejar el número de asignaturas, y asignarlas a profesores y viceversa. Se encargará de actualizar la tabla de timeslots con todas las ranuras de tiempo de un horario lectivo, e incluir los horarios de los profesores a principio de curso.

Además, podría encargarse de otras acciones de gestión, como lo son la modificación del Mensaje del Día (MOT), que se encuentran todos los usuarios antes de entrar en la app.

En la especificación ASL, se ha incluido, entre comentarios, una posible recreación de cómo sería el modelo de usuario para este actor administrador.

69


Figura 8.2. Descripción en ASL del modelo de diálogo para el posible ususario Admin

8.3 El futuro de las Aplicaciones Web

La Web está en constante evolución, algo que nos parece novedoso hoy en día puede estar obsoleto en 5 años. Nos cuesta imaginar cómo será el internet del futuro.

Expertos [7] piensan que los usuarios cada vez resultarán menos proactivos, los usuarios se han acomodado tanto que los desarrolladores pondrán su empeño en construir una web que se adelante a las necesidades de los usuarios. Una web futura “que nos encuentre” a nosotros en lugar de “nosotros a ella”. Esto podría dejar a las aplicaciones un tanto al margen, ya que estas se centralizan para ofrecer sólo lo que el usuario quiere recibir. Por ejemplo, Facebook ya filtra la información que interesa al usuario sin tener que obtenerla de diferentes fuentes.

Pero aún teniendo una posible idea de cómo será la web del futuro, seguimos a ciegas. En un futuro donde predominará el internet de las cosas, los coches autónomos o el cloud computing entre otros, tecnologías que no sabemos cómo afectarán a la sociedad, es imposible dar una respuesta clara al futuro de la web y sus aplicaciones. Quizá desaparezcan o quizá se hagan más fuertes que nunca.

Líneas futuras

70

71


9 CONCLUSIONES

odemos iniciar la conclusión de este proyecto resumiendo un poco el ámbito del mismo y su finalidad:

En el rol de alumno, este inicia sesión con unas credenciales comunes al resto de alumnos, y tiene las opciones de pedir una nueva tutoría o de gestionar las que ya tuviera asignadas. La primera opción se ha desarrollado en WAINE, y además, la validación de alumno existente a la hora de pedir una tutoría se ha realizado en PHP.

Por parte del profesor (aún en desarrollo), tras iniciar sesión con unas credenciales comunes o privadas, este podrá ver las tutorías que los alumnos le hayan solicitado y gestionar también sus próximos horarios.

Por lo que podemos concluir que se ha desarrollado una aplicación sencilla de usar y entender, destinada a cualquier usuario del sistema educativo de la Universidad de Sevilla que la precise, y con cierta proyección de futuro más concretamente en el Departamento de Telemática de la Escuela Técnica Superior de Ingenieros. Su diseño, atractivo y sencillo, hacen que cualquier alumno o profesor se decidan a usar esta aplicación, en lugar del método tradicional de llamar a la puerta y esperar una respuesta.

Son muchas las dificultades encontradas durante el desarrollo de la aplicación, que van más allá de las mencionadas en el punto anterior. Pese a que la aplicación no está terminada y, a priori, puede parecer muy sencilla, se ha realizado un esfuerzo descomunal por realizar lo poco que se ha podido desarrollar. Al ser WAINE una tecnología creada exclusivamente en el Departamento de Telemática, es muy escasa la información que existe, tanto en internet como en bibliotecas. Los documentos que poseía se limitaban a una publicación realizada en una revista y un par de aplicaciones de ejemplo, lo que conllevaba a que cuando alguna duda surgía, tenía que desplazarme a la escuela para dialogarla en persona.

Pese a todo, he aprendido multitud de conceptos, nuevas tecnologías, y herramientas. Lo que más he valorado ha sido los nuevos conocimientos que he asimilado acerca de las bases de datos. Cómo un mal diseño del Modelo Entidad-Relación puede condicionar tantísimo el desarrollo de la aplicación. Han sido varios bocetos de este modelo los que se han tenido que rediseñar una y otra vez, siempre que nos encontrábamos un ‘muro’ a la hora de escribir código, hasta llegar al modelo definitivo.

También, como no, han sido muchos los errores cometidos durante el camino, sobre todo en la parte de organización, los que me han hecho aprender y los que me han ayudado a avanzar una vez resueltos.

Finalmente, dar las gracias a Antonio Luis Delgado por poder contar con él siempre que he tenido alguna duda, y, como no, a mi tutor Antonio José Estepa por tener siempre la puerta de su despacho abierta a todo lo que he necesitado, por haber estado siempre pendiente de mí y por haberme dado la oportunidad de seguir aprendiendo. ¡Muchas gracias!

P

640K deberían ser suficientes para todo el mundo.

- Bill Gates, 1981-

Conclusiones

72

73


BIBLIOGRAFÍA

[1] R. Barzanallana, Historia del desarrollo de las aplicaciones web, Universidad de Murcia, 2012

[2] P. Kumar, Evolution of Web Development, LinkedIn, 2014

[3] A. Delgado, A. Estepa, J.A. Troyano, R. Estepa, Reusing UI elements with Model-Based User Interface

Development, ScienceDirect Journal, 2015

[4] G. Meixner, F. Paternò, J. Vanderdonckt, Past, Present and Future of Model-Based User Interface Development, i-com, 2011

[5] A. Delgado, Wiki Waine, Website, 2017

[6] A. Delgado, Introducción a MB-UID y WAINE, 2015

[7] D. Buytaert, El futuro de la Web, Computerhoy.com, 2015

http://www.um.es/docencia/barzana/DIVULGACION/INFORMATICA/Historia-desarrollo-aplicaciones-web.html

https://www.linkedin.com/pulse/20141119114952-62080297-evolution-of-web-development

http://www.sciencedirect.com/science/article/pii/S1071581915001470

http://www.sciencedirect.com/science/article/pii/S1071581915001470

https://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjj6aKfj5HWAhWMSRoKHaLxBaAQFgg0MAM&url=http%3A%2F%2Fmefisto.isti.cnr.it%2Fattachments%2Fpublications%2Ficom%25202011%25200026%2520-%2520model-based.pdf&usg=AFQjCNG0r9sRGk19nTfN9wRNUhOu0Fiyxw

https://www.google.es/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&cad=rja&uact=8&ved=0ahUKEwjj6aKfj5HWAhWMSRoKHaLxBaAQFgg0MAM&url=http%3A%2F%2Fmefisto.isti.cnr.it%2Fattachments%2Fpublications%2Ficom%25202011%25200026%2520-%2520model-based.pdf&usg=AFQjCNG0r9sRGk19nTfN9wRNUhOu0Fiyxw

http://waine.us.es/portal/menu.php

http://waine.us.es/portal/blob/frm_docs-2-iVj1Sc/DOC_mbuid_waine_intro.pdf

http://computerhoy.com/noticias/internet/futuro-web-desapareceran-aplicaciones-25767

Bibliografía

74

75


GLOSARIO

AIO: Abstract Interaction Object

APP: Abreviatura de Aplicación (inglés)

ASL: Applications Specification Language

AUI: Abstract User Interface

BBDD: Base de Datos

Booleano: Variable que sólo puede tomar dos valores que se excluyen mutuamente (0 y 1)

CIO: Concrete Interaction Object

CSS: Cascading Style Sheets

CSV: Comma-Separated Values

CRF: Camaleon Reference Framework

CUI: Concrete User Interface

DB: DataBase

DBF: DataBase File

DNI: Documento Nacional de Identidad

ERD: Entity–Relationship Diagram

ETSI: Escuela Técnica Superior de Ingeniería

FUI: Final User Interface

HTML: HyperText Markup Language

ID: Abreviación de Identificador

MDB: Meta-DataBase

MB-UID: Model-Based User Interface Development

MB-UIDE: Model-Based User Interface Development Environment

PC: Personal Computer

PHP: Acrónimo recursivo de PHP: Hypertext Preprocessor

PK: Primary Key

RAE: Real Academia de la Lengua Española

Relación 1:N: Una entidad en A se relaciona con cero o muchos registros en una entidad B

Relación M:N: Una entidad en A se puede relacionar con 0 o con muchas entidades en B y viceversa

SCP: Secure Copy Protocol o Simple Communication Protocol

SQL: Structured Query Language

Timeslot: Espacio de Tiempo (inglés)

Glosario

76

Toolkit: Conjunto de Herramientas (ingés)

TPV: Terminal Punto de Venta

UI: User Interface

UVUS: Usuario Virtual de la Universidad de Sevilla

WAINE: Web Application Interface Engine

XML: Extensible Markup Language

77


Anexo 1: Archivos ASL

78

ANEXO 1: ARCHIVOS ASL

Tutoriapp.asl

<?xml version='1.0' ?>

<!DOCTYPE asl PUBLIC "-//ITI//DTD XWF 0.6 //EN"

"/usr/local/lib/waine-0.4.6/lib/asl.dtd">

<asl>

<include href="/usr/local/lib/waine-0.4.6/include/meta.asl"/>

<include href="/usr/local/lib/waine-0.4.6/include/useradm.asl"/>

<include href="/usr/local/lib/waine-0.4.6/include/motd.asl"/>

<head>

<meta class="AppInfo" name="appname" value="TutoriApp"/>

<meta class="AppInfo" name="ver" value="0.1"/>

<meta class="AppInfo" name="date" value="30/08/2017"/>

<meta class="AppInfo" name="author" value="Alberto Fuentes"/>

<meta class="AppInfo" name="email" value="[email protected]"/>

</head>



<group gid="1" name="alumno">

<user uid="1" name="alum" passwd="alum"

mainid="main_alumno" descr="A sample student"/>

</group>

<group gid="2" name="profesor">

<user uid="2" name="prof" passwd="prof"

mainid="main_profesor" descr="A sample teacher"/>



</group>

79


<main id="main_alumno"

caption="en=Student menu|es=Menu del alumno">

<menu caption="en=Tutorship|es=Tutorias">

<option caption="en=Ask new tutorship|es=Pedir nueva tutoria"

call="c_tutoria"/>

<option caption="en=Tutorships management|es=Gestion de tutorias"

call="c_gestion"/>

</menu>






</menu>

</main>

<main id="main_profesor"

caption="en=Teacher menu|es=Menu del profesor">

<menu caption="en=Management|es=Gestion">

<option caption="en=Timetable Management|es=Gestion de Horarios"

call="c_horario"/>

<option caption="en=Tutorship Management|es=Gestion de tutorias"

call="c_gestion_prof"/>

</menu>






</menu>

</main>

<form id="f_asignatura" source="asignatura"

caption="en=Subject|es=Asignatura">

<orderby>nombre_asig</orderby>

<fields>

<key source="idasignatura"/>

<string source="nombre_asig" caption="en=Name|es=Nombre" len="40"

maxlen="80"/>

</fields>

</form>

<form id="f_profesor_aux" source="view_profasig"

caption="en=Teacher|es=Profesor">

<orderby>nombre_prof</orderby>

<fields>

<key source="idprofesor"/>

<string source="idasignatura" caption="en=Subject|es=Asignatura"

len="40" maxlen="80">

<search>f_asignatura</search>

<searchfield>nombre_asig</searchfield>

</string>

<string source="nombre_prof" caption="en=Name|es=Nombre" len="40"

maxlen="80"/>

<string source="idprofesor" caption="en=Email|es=Email" len="40"

maxlen="80" canbenull="Y">


80

<search>f_profesor</search>

<searchfield>email</searchfield>

</string>

<string source="idprofesor" caption="en=Room|es=Despacho" len="10"

maxlen="80" canbenull="Y">


<searchfield>despacho</searchfield>

</string>

<int source="idprofesor" caption="en=Phone|es=Telefono" len="13"

canbenull="Y">


<searchfield>telefono</searchfield>

</int>

</fields>

</form>

<form id="f_profesor" source="profesor" caption="en=Teacher|es=Profesor">

<fields>

<key source="idprofesor"/>

<string source="nombre_prof" caption="en=Name|es=Nombre" len="40"

maxlen="80"/>

<string source="email" caption="en=Email|es=Email" len="40"

maxlen="80" canbenull="Y"/>

<string source="despacho" caption="en=Room|es=Despacho" len="10"

maxlen="80" canbenull="Y"/>

<int source="telefono" caption="en=Phone|es=Telefono" len="13"

canbenull="Y"/>

</fields>

</form>

<form id="f_hora" source="profesor_has_timeslot" caption="en=Day and

Hour|es=Dia y Hora">

<fields>

<key source="pk"/>

<int source="idprofesor" caption="en=Teacher|es=Profesor" len="40"

maxlen="80">

<search>f_profesor_aux</search>

<searchfield>nombre_prof</searchfield>

</int>

<string source="fecha" caption="en=Date|es=Fecha" len="12"

maxlen="15"/>

<string source="hora" caption="en=Time|es=Hora" len="12"

maxlen="15"/>

</fields>

<buttons>

<action type="web" caption="Solicitar">

<tooltip>Solicitar una reserva</tooltip>

<code>reserva.php</code>

<msg>Esta seguro de realizar la reserva?</msg>

</action>

</buttons>

</form>

<struct id="c_tutoria" type="relation">

<param name="form_split" value="rows=80,*"/>

81


<param name="formid" value="f_asignatura"/>

<param name="form_type" value="combo"/>

<param ord="2" name="structid" value="c_tutoria_aux"/>

</struct>

<struct id="c_tutoria_aux" type="relation">

<param name="form_split" value="rows=240,*"/>

<param name="formid" value="f_profesor_aux"/>

<param name="form_type" value="form"/>

<param name="button_data" value="0"/>

<param name="fields_hidden" value="1"/>

<param name="source_filter_field" value="idasignatura"/>

<param name="navigator_fields" value="nombre_prof"/>

<param name="navigator_position" value="W"/>



<param name="fields_readonly" value="2:3:4:5"/>

<param name="button_misc" value="0"/>

<param ord="2" name="formid" value="f_hora"/>

<param ord="2" name="form_type" value="table"/>

<param ord="2" name="fields_remove" value="1"/>

<param ord="2" name="button_data" value="0"/>

<param ord="2" name="source_filter_field" value="idprofesor"/>

<param ord="2" name="source_filter_where"

value="fecha>=date('now') AND fecha <= date('now','+8 day') AND ocupado !=

1"/>

<param ord="2" name="fields_readonly" value="2:3"/>

</struct>

</asl>

Se han añadido también, tanto en el modelo de usuarios como en el de diálogo, unas líneas para un posible futuro usuario de la aplicación con el rol de administrador.


82

83


ANEXO 2: ARCHIVOS PHP

Reserva.php

<head>

<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-

scale=1.0">

<title>Reserva tu Cita</title>

<link rel="stylesheet" href="css/stylesheet.css">

<link href='https://fonts.googleapis.com/css?family=Nunito:400,300'

rel='stylesheet' type='text/css'>


</head>

<body>

<form action="reserva2.php" method="post">

<h1>Reserva tu cita</h1>

<fieldset>

<legend><span class="number">1</span>Introduce tus datos</legend>

<label for="uvus">Uvus:</label>

<input type="text" id="uvus" name="uvus">

<?php global $pk;

echo '<input type="hidden" name="pk" value="'.$pk.'"/>'; ?>

<label for="dni">Dni:</label>

<input type="text" id="dni" name="dni">

<label for="mail">Email:</label>

<input type="email" id="mail" name="mail">

</fieldset>

<fieldset>

<legend><span class="number">2</span>Descripcion de la

cita</legend>

<textarea id="descripcion" name="descripcion"></textarea>

</fieldset>

</fieldset>

<button type="submit">Enviar</button>

</form>

</body>

</html>

Anexo 2: Archivos PHP

84

Reserva2.php

<head>

<meta charset="utf-8">

<meta name="viewport" content="width=device-width, initial-

scale=1.0">

<title>Reserva tu Cita</title>


<link href='https://fonts.googleapis.com/css?family=Nunito:400,300'

rel='stylesheet' type='text/css'>


</head>

<body>

<?php

function verificar_uvus($uvus,$dni,&$result) { //Comprueba si el uvus

coincide con el dni

$sql = "SELECT * FROM alumno WHERE uvus = '$uvus' and dni = '$dni'";

$conn = sqlite_open('./DB');

$rec = sqlite_query($conn, $sql);

$count = 0;

while($row = sqlite_fetch_array($rec))

{

$count++;

$result = $row;

}

if($count == 1)

{

return 1;

}

else

{

return 0;

}

}

$IN_pk = $_POST['pk'];

$IN_uvus = $_POST['uvus'];

$IN_dni = $_POST['dni'];

$IN_descripcion = $_POST['descripcion'];

$ERROR = "Algo ha ocurrido. Vuelve a la pagina principal";

if(verificar_uvus($IN_uvus, $IN_dni,$result) == 1) //si uvus y dni correctos

{

$conn = sqlite_open('./DB'); //Abrimos conexion con bbdd

$sql = "INSERT INTO cita (uvus, prk, descripcion) VALUES

('$IN_uvus', $IN_pk, '$IN_descripcion')"; //nueva cita

$sql2 = "UPDATE profesor_has_timeslot SET ocupado = 1 WHERE pk =

$IN_pk"; //actualizamos timeslot como ocupado

$sql3 = "SELECT fecha,hora,idprofesor FROM profesor_has_timeslot

WHERE pk = $IN_pk"; //seleccionamos fecha, hora y profesor para mostralos

85


$query_date = sqlite_query($conn, $sql3);

$entry_date = sqlite_fetch_array($query_date, SQLITE_ASSOC);

$pk_profesor = $entry_date['idprofesor'];

$sql4 = "SELECT nombre_prof,email FROM profesor WHERE idprofesor

= $pk_profesor";

$query_prof = sqlite_query($conn, $sql4);

$entry_prof = sqlite_fetch_array($query_prof, SQLITE_ASSOC);

if ( (sqlite_query($conn, $sql) != FALSE) && (sqlite_query($conn,

$sql2) != FALSE)) {

?>

<form action="menu.php" method="get">

<h1>Cita reservada correctamente</h1>

<legend>Puedes gestionar tus citas en el apartado de gestión</legend>

<?php

echo '<label><b>Profesor: </b>' . $entry_prof['nombre_prof'] . '<br><b>

Fecha: </b>' . $entry_date['fecha'] . '<br><b> Hora: </b>' .

$entry_date['hora'] . '</label><br>';

?>

<button type="submit">Aceptar</button>

</form>

<?php

}

else {

echo "<a href=\"menu.php\">Volver</a>";

}

}

else

{

echo "<b>Uvus o dni incorrecto</b>.<br>";

echo "<a href=\"reserva.php?pk=$IN_pk\">Volver</a>";

}

?>

</body>

</html>

Cuando el alumno hace finalmente escoge fecha y hora y hace click en el botón Solicitar se redirige al archivo Reserva.php que básicamente muestra un formulario en el que introducir diversos datos. El archivo Reserva2.php tratará estos datos del formulario anterior y realizará las diferentes acciones en la Base de Datos. Además mostrará el mensaje correcto, si la cita es correcta, o el mensaje de error, en caso contrario. El estilo que se muestran en estas páginas lo podremos ver en el Anexo 4: Archivos CSS

Anexo 2: Archivos PHP

86

87


ANEXO 3: ARCHIVOS SQL

Create.sql

CREATE TABLE profesor (

idprofesor INTEGER UNSIGNED NOT NULL,

nombre_prof VARCHAR(20) NULL,

apellidos_prof VARCHAR(45) NULL,

email VARCHAR(45) NULL,

despacho INTEGER UNSIGNED NULL,

telefono VARCHAR NULL,

PRIMARY KEY(idprofesor)

);

CREATE TABLE timeslot (

pk INTEGER UNSIGNED NOT NULL,

fecha DATE NOT NULL,

hora DATE NOT NULL,

PRIMARY KEY(pk),

UNIQUE(fecha, hora)

);

CREATE TABLE asignatura (

idasignatura INTEGER UNSIGNED NOT NULL,

nombre_asig VARCHAR(255) NULL,

curso INTEGER UNSIGNED NULL,

PRIMARY KEY(idasignatura)

);

CREATE TABLE alumno (

uvus VARCHAR(20) NOT NULL,

nombre_alum VARCHAR(20) NULL,

apellidos_alum VARCHAR(45) NULL,

dni VARCHAR(20) NOT NULL,

email VARCHAR(45),

PRIMARY KEY(uvus)

);

CREATE TABLE profesor_has_timeslot (



pk_timeslot INTEGER UNSIGNED NOT NULL,

ocupado BOOL NULL DEFAULT 0,

PRIMARY KEY(pk),

UNIQUE(idprofesor, pk_timeslot),

FOREIGN KEY(idprofesor)

REFERENCES profesor(idprofesor),

FOREIGN KEY(pk_timeslot)

REFERENCES timeslot(pk)

);

CREATE TABLE cita (


Anexo 3: Archivos SQL

88


pk_profesor_has_timeslot NOT NULL,

descripcion VARCHAR(255) NULL,

confirmada BOOL NULL DEFAULT 0,

PRIMARY KEY(pk),

UNIQUE(pk_profesor_has_timeslot),

FOREIGN KEY(uvus)

REFERENCES alumno(uvus),

FOREIGN KEY(pk_profesor_has_timeslot)

REFERENCES profesor_has_timeslot(pk)

);

CREATE TABLE cita (



prk NOT NULL,

descripcion VARCHAR(255) NULL,

confirmada BOOL NULL,

PRIMARY KEY(pk),

UNIQUE(uvus, prk),

FOREIGN KEY(uvus)

REFERENCES alumno(uvus),

FOREIGN KEY(prk)

REFERENCES profesor_has_timeslot(pk)

);

CREATE TABLE profesor_has_asignatura (



idasignatura INTEGER UNSIGNED NOT NULL,

PRIMARY KEY(pk),

UNIQUE(idprofesor, idasignatura),

FOREIGN KEY(idprofesor)

REFERENCES profesor(idprofesor),

FOREIGN KEY(idasignatura)

REFERENCES asignatura(idasignatura)

);

CREATE VIEW view_profasig AS

SELECT profesor_has_asignatura.*, profesor.nombre_prof

FROM profesor_has_asignatura,profesor

WHERE profesor_has_asignatura.idprofesor = profesor.idprofesor;

89


Ejemplos de INSERT

INSERT INTO asignatura (idasignatura,nombre_asig,curso) VALUES (2001,

'Fundamentos de Internet', 2);


'Fundamentos de Programación I', 1);


'Estructura de Protocolos y Redes Publicas', 2);

INSERT INTO profesor (idprofesor,nombre_prof,email,telefono) VALUES (1,

'Antonio Estepa', '[email protected]', '954487384');

INSERT INTO profesor (idprofesor,nombre_prof,email,telefono) VALUES (4,

'Antonio Luis Delgado', '[email protected]', '954487384');

INSERT INTO alumno (uvus,nombre_alum,apellidos_alum,dni) VALUES

('albfuemun','Alberto','Fuentes Munoz','77859368');

INSERT INTO timeslot (pk,fecha,hora) VALUES (13689, '2017-09-21', '11:00');



INSERT INTO profesor_has_asignatura (pk,idprofesor,idasignatura) VALUES (26,

17, 4001);

INSERT INTO profesor_has_asignatura (pk,idprofesor,idasignatura) VALUES (27,

1, 2001);

INSERT INTO profesor_has_timeslot (pk,idprofesor,pk_timeslot) VALUES

(1,1,7922);

INSERT INTO profesor_has_timeslot (pk,idprofesor,pk_timeslot) VALUES

(2,1,7923);

Anexo 3: Archivos SQL

90

91


ANEXO 4: ARCHIVOS CSS

Stylesheet.css

*, *:before, *:after {

-moz-box-sizing: border-box;

-webkit-box-sizing: border-box;

box-sizing: border-box;

}

body {

font-family: 'Nunito', sans-serif;

color: #384047;

}

form {

max-width: 300px;

margin: 10px auto;

padding: 10px 20px;

background: #f4f7f8;

border-radius: 8px;

}

h1 {

margin: 0 0 30px 0;

text-align: center;

}

input[type="text"],

input[type="password"],

input[type="date"],

input[type="datetime"],

input[type="email"],

input[type="number"],

input[type="search"],

input[type="tel"],

input[type="time"],

input[type="url"],

textarea,

select {

background: rgba(255,255,255,0.1);

border: none;

font-size: 16px;

height: auto;

margin: 0;

outline: 0;

padding: 15px;

width: 100%;

background-color: #e8eeef;

color: #8a97a0;

Anexo 4: Archivos CSS

92

box-shadow: 0 1px 0 rgba(0,0,0,0.03) inset;

margin-bottom: 30px;

}

input[type="radio"],

input[type="checkbox"] {

margin: 0 4px 8px 0;

}

select {

padding: 6px;

height: 32px;

border-radius: 2px;

}

button {

padding: 19px 39px 18px 39px;

color: #FFF;

background-color: #b22222;

font-size: 18px;

text-align: center;

font-style: normal;

border-radius: 5px;

width: 100%;

border: 1px solid #8b0000;

border-width: 1px 1px 3px;

box-shadow: 0 -1px 0 rgba(255,255,255,0.1) inset;


}

fieldset {


border: none;

}

legend {

font-size: 1.4em;


}

label {

display: block;

margin-bottom: 8px;

}

label.light {

font-weight: 300;

display: inline;

}

.number {

background-color: #b22222;

color: #fff;

height: 30px;

width: 30px;

display: inline-block;

font-size: 0.8em;

margin-right: 4px;

line-height: 30px;

text-align: center;

text-shadow: 0 1px 0 rgba(255,255,255,0.2);

93


border-radius: 100%;

}

@media screen and (min-width: 480px) {

form {

max-width: 480px;

}

}

Archivo de estilo usados en las páginas PHP

Anexo 4: Archivos CSS

94

95

ANEXO 5: MODELO ENTIDAD-RELACIÓN

Anexo 6: Diagrama de Gantt

96

ANEXO 6: DIAGRAMA DE GANTT

Figura A6.1. Diagrama de Gantt (Parte 1/2)

97


Figura A6.2. Diagrama de Gantt (Parte 2/2)

DESARROLLO DE APLICACIÓN DE NOTIFICACIONES A TRAVÉS DE...

Documents

Transcript of DESARROLLO DE APLICACIÓN DE NOTIFICACIONES A TRAVÉS DE...