trabajo fin de grado fg-h app para...

Esc

uela

Pol

itécn

ica

Sup

erio

r de

Jaén

UNIVERSIDAD DE JAÉN Escuela Politécnica Superior (Jaén)

Trabajo Fin de Grado

FG-HUM: APP PARA LA GESTIÓN DEL PROCESO DE

SELECCIÓN DE TFG DE LOS ALUMNOS DE LA FAC. DE

HUMANIDADES Y CIENCIAS DE LA EDUCACIÓN

Alumno: Manuel González Amate

Tutor: Prof. D. Víctor Manuel Rivas Santos

Dpto: Informática

Junio, 2016

Manuel González Amate FG-Hum: App para la gestión del proceso de selección de TFG

2 Escuela Politécnica Superior de Jaén

Universidad de Jaén

Escuela Politécnica Superior de Jaén Departamento de Informática

Don VICTOR MANUEL RIVAS SANTOS, tutor del Proyecto Fin de Carrera titulado: FG-HUM: APP PARA LA GESTIÓN DEL PROCESO DE SELECCIÓN DE TFG DE LOS ALUMNOS DE LA FAC. DE HUMANIDADES Y CIENCIAS DE LA EDUCACION, que presenta MANUEL GONZÁLEZ AMATE, autoriza su presentación para defensa y evaluación en la Escuela Politécnica Superior de Jaén.

Jaén, Junio de 2016

El alumno: Los tutores:

MANUEL GONZÁLEZ AMATE VICTOR MANUEL RIVAS SANTOS



Índice 1. INTRODUCCIÓN ..................................................................................................................... 8

1.1 Objetivos ............................................................................................................................. 9

1.2 Motivación del proyecto ................................................................................................... 11

1.3 Ciclo de vida del desarrollo software del sistema ............................................................. 12

1.3.1 El ciclo de vida ............................................................................................................ 12

1.3.2 Modelo en cascada..................................................................................................... 12

2. CONTEXTO DEL PROYECTO ...................................................................................................... 14

2.1 Desarrollo de aplicaciones móviles ................................................................................... 14

2.2 Estudio de mercado de dispositivos móviles .................................................................... 14

2.2.1 El móvil en España ...................................................................................................... 14

2.2.2 Introducción de Tablets.............................................................................................. 14

2.3 Desarrollo .......................................................................................................................... 16

2.3.1 IOS .............................................................................................................................. 16

2.3.2 Android ....................................................................................................................... 16

2.4 Decisión tecnología usada para la aplicación .................................................................... 16

2.5 Aplicación para el servidor ................................................................................................ 17

2.5.1 Gestores de Bases de Datos externas ........................................................................ 17

2.5.2 CouchDB ..................................................................................................................... 17

2.5.3 FireBird ....................................................................................................................... 18

2.5.4 PostgreSQL ................................................................................................................. 18

2.5.5 MySQL ........................................................................................................................ 19

2.6 Decisión tecnología usada para la aplicación de servidor ................................................. 19

3. PLANIFICACIÓN DEL PROYECTO .............................................................................................. 20

3.2 Listado de tareas ............................................................................................................... 20

3.3 Diagrama de Gantt ............................................................................................................ 20

4. ANÁLISIS .................................................................................................................................. 23

4.2 Personas ............................................................................................................................ 23

4.3 ESCENARIOS ...................................................................................................................... 27

4.3.1 Escenario 1: Cómo se matriculan los alumnos del TFG .............................................. 27

4.3.2 Escenario 2: Cómo se enteran los alumnos de cuándo hay que empezar a inscribirse en el TFG .............................................................................................................................. 28



4.3.3 Escenario 3: Cómo se enteran los alumnos de las ofertas de los TFG y plazas que hay ............................................................................................................................................. 28

4.3.4 Escenario 4: Cómo seleccionan los alumnos los TFG propuestos .............................. 28

4.3.5 Escenario 5: Cómo se entera el alumno de que posición de su lista de TFG les ha sido asignado .............................................................................................................................. 29

4.3.6 Escenario 6: Cómo asignan los miembros del comité de TFG de la facultad a los alumnos dichos TFG ............................................................................................................ 29

4.4 Requisitos .......................................................................................................................... 30

4.4.1 Requisitos funcionales:............................................................................................... 30

4.4.2 Requisitos no funcionales: ......................................................................................... 30

4.4.3 Requisitos funcionales lado servidor.......................................................................... 31

4.4.4 Requisitos funcionales lado aplicación móvil ............................................................. 32

4.4.5 Requisitos NO funcionales que usaremos: ................................................................. 32

4.5 Diagrama frontera ............................................................................................................. 33

4.5.1 Paquete del servidor .................................................................................................. 33

4.5.2 Paquete de la aplicación ............................................................................................ 34

4.6 Narrativa de casos de uso servidor ................................................................................... 36

4.7 Narrativas de caso de uso de la aplicación ....................................................................... 44

4.8 Modelo del dominio .......................................................................................................... 50

4.8.1 Transición del Análisis al Diseño ................................................................................ 50

5. DISEÑO .................................................................................................................................... 52

5.1 Diseño arquitectónico ....................................................................................................... 52

5.1.2 DescripciónMVC: ........................................................................................................ 52

5.2 Diseño de casos de uso ..................................................................................................... 54

5.2.1 Visual paradigm .......................................................................................................... 54

5.3 Diagrama de clases de diseño ........................................................................................... 54

5.3.1 Asynctask (Tareas asincronas) .................................................................................... 56

5.3.2 Activities y fragments ................................................................................................. 57

5.4 Diagramas de secuencia de interacción ............................................................................ 60

5.4.1 Caso de Uso Login ...................................................................................................... 61

5.4.2 Caso de Uso Gestión tutor (Añadir tutor, Eliminar tutor) .......................................... 62

5.4.3 Caso de Uso Lista de Tutores Y TFGs .......................................................................... 63

5.4.4 Caso de uso Información ............................................................................................ 64



5.5 Diseño de la base de datos ................................................................................................ 64

5.5.1 Base de datos Relacional ............................................................................................ 64

5.6 Diseño de la interfaz inicial ............................................................................................... 70

5.6.1 STORYBOARD.............................................................................................................. 71

6. IMPLEMENTACIÓN .................................................................................................................. 80

6.1 Herramientas ..................................................................................................................... 87

6.1.1 Herramientas y lenguajes lado del servidor ............................................................... 87

6.1.2 Caracteristicas Hostinger............................................................................................ 87

6.1.3 JSON ........................................................................................................................... 88

6.1.4 MySQL ........................................................................................................................ 89

6.1.5 SQL (StructuredQueryLanguage) ................................................................................ 89

6.1.6 PHP ............................................................................................................................. 91

6.1.7 Decisión de alojar la base de datos en dicho servidor ............................................... 94

6.2 Herramientas y lenguajes para la aplicación android ....................................................... 95

6.2.1 Git y GitHub ................................................................................................................ 95

6.2.2 Android Studio ........................................................................................................... 98

6.2.3 Java ............................................................................................................................. 98

6.3 Construcción de la interfaz y menús de la aplicación ....................................................... 99

6.3.1 Estilo de la interfaz ..................................................................................................... 99

6.3.2 Action bar superior ................................................................................................... 100

6.3.3 Menú lateral ............................................................................................................. 101

7. MANUAL DE USUARIO ........................................................................................................... 102

8. MANUAL DE INSTALACIÓN .................................................................................................... 108

9. PRUEBAS ................................................................................................................................ 110

9.1 Pruebas genéricas para todo producto Software ........................................................... 110

9.1.1 Técnicas de caja negra o de comportamiento ......................................................... 110

9.2 Pruebas específicas para android .................................................................................... 119

9.2.1 Interfaz de usuario ................................................................................................... 119

9.2.2 Usabilidad ................................................................................................................. 119

9.2.3 Rendimiento / tiempo de respuesta cortos: ............................................................ 120

9.2.4 Seguridad:................................................................................................................. 120

10 CONCLUSIONES .................................................................................................................... 121

10.1 Valoración personal ...................................................................................................... 121



10.2 Mejoras futuras ............................................................................................................. 122

11. PRESUPUESTO ..................................................................................................................... 123

ANEXO A: ENTREVISTAS ............................................................................................................ 125



1. INTRODUCCIÓN Este trabajo fin de grado consiste en desarrollar un proceso de

ingeniería del software, el resultado que obtendrá es el prototipo de una

aplicación en el sistema operativo Android con el apoyo de un servidor que le

soporte datos.

La aplicación permitirá a los alumnos de la Facultad de Humanidades y

Ciencias de la Educación (FHCCE) conocer y seleccionar que TFG sean

ofertados en su facultad, Con esta App se pretende facilitar el proceso de

selección de TFG por parte de los alumnos.

Para que la App funcione, se debe generar también software en el lado

del servidor que permita recoger los datos introducidos por los alumnos, pero

también, que facilite la introducción de las propuestas de TFG por parte de la

FHCCE



1.1 Objetivos Los objetivos del trabajo serán:

x Describir los procesos y datos que permiten la gestión para el

correcto funcionamiento del sistema de selección y asignación de

TFG en la FHCEE, concretamente los relacionados con:

o Gestión del listado de alumnos matriculados para realizar el

TFG en cada curso académico

o Gestión del listado de TFG sin alumno pre asignado ofertado.

o Gestión del proceso de selección priorizada de TFG por parte

de los alumnos

o Gestión del proceso de asignación de TFG a cada alumno en

función de su selección y de su posición en el baremo que

determina el orden de la selección.

x Crear un prototipo de la aplicación capaz de dar solución a las

necesidades detectadas relacionadas con, al menos, los 3 primeros

apartados descritos en el primer punto de esta sección de objetivos

Según como se acordó con el tutor de mi proyecto esta aplicación es un

prototipo, por lo tanto he implementado estos 3 objetivos:

o Gestión del listado de alumnos matriculados para realizar el

TFG en cada curso académico

o Gestión del listado de TFG sin alumno pre asignado ofertado.

o Gestión del proceso de selección priorizada de TFG por parte

de los alumnos

Para un futuro y final proyecto de la aplicación se hará el objetivo

siguiente, ya que es un trabajo de más envergadura, requerirá un esfuerzo

mayor dentro de lo que es el ámbito de un trabajo fin de carrera.



o Gestión del proceso de asignación de TFG a cada alumno en

función de su selección y de su posición en el baremo que

determina el orden de la selección.

Además

x Definir las necesidades y roles de los distintos usuarios de la aplicación

a crear.

x Realizar un estudio de posibles tecnologías susceptibles de ser

utilizadas para la realizar una aplicación móvil y elegir de forma

justificada la que mejor se adapte a la propuesta.

x Realizar un estudio de posibles tecnologías susceptibles de ser

utilizadas para la realizar la aplicación del servidor y elegir de forma

justificada la que mejor se adapte a la propuesta.

x Emplear una metodología basada en técnicas de Ingeniería del software

para el establecimiento y documentación del análisis de requisitos,

diseño, implementación y pruebas del sistema a construir.

x Redactar la memoria que recoja todo el trabajo desarrollado así como

los manuales de instalación y usuario.



1.2 Motivación del proyecto Dado que la facultad de humanidades y ciencias de la educación

dispone de 9 titulaciones, con gran cantidad de alumnos, resulta engorroso el

tema de la selección de TFG para el alumnado de último año.

Como bien se explica en el anexo de las entrevistas en la pregunta:

1º ¿Por qué queréis cambiar vuestro sistema actual de la elección de

TFG para el alumnado?

Para la comisión de trabajo fin de grado resulta muy trabajoso, el hecho

de recoger a papel las 30 prioridades de cada alumno de cada titulación y

asignando en orden de nota de expediente de cada alumno.

Esto es un proceso largo y puede inducir a errores, es por eso que ha

surgido la idea de este proyecto.

Informatizar este proceso en una simple aplicación en la que cada

alumno pueda ver la oferta de TFG disponible de su titulación y poder elegir su

preferencia y que este se le mande a la comisión de TFG es una gran ventaja,

y como dijimos anteriormente este es un prototipo, en una versión futura, podrá

actualizarse la versión de que se asignen el TFG final para cada alumno

jugando con las prioridades de cada y sus notas de expediente.

Por lo que aparte de ahorrar trabajo a la comisión, será más cómodo

para el usuario la selección de su TFG.

En mi caso como alumno una de mis grandes motivaciones es aprender

tecnologías y lenguajes, estas son las que he elegido: android, PHP, java, sql,

JSON.

Por lo que es de gran interés para mí el formarme con el desarrollo de

las aplicaciones móviles que están ahora en pleno auge.



1.3 Ciclo de vida del desarrollo software del sistema 1.3.1 El ciclo de vida

El ciclo de vida son las distintas fases por las que pasa el desarrollo de

un sistema desde que se crean las ideas principales hasta que el software es

finalizado

1.3.2 Modelo en cascada

Es el enfoque metodológico que ordena rigurosamente las etapas del

ciclo de vida del software, de forma que el inicio de cada etapa debe esperar a

la finalización de la inmediatamente anterior.

El modelo en cascada es un proceso de desarrollo secuencial, en el que

el desarrollo se ve fluyendo hacia abajo (como una cascada) sobre las fases

que componen el ciclo de vida1

1Información obtenida de :https://www.incibe.es/file/N85W1ZWFHifRgUc_oY8_Xg

Ilustración 1.1 Modelo de ciclo de vida en cascada

https://www.incibe.es/file/N85W1ZWFHifRgUc_oY8_Xg



El modelo en cascada puede ser convenientes para proyectos estables

donde los requisitos del proyecto no sean cambiantes y cuando es probable

que los diseñadores predigan totalmente áreas de problema del sistema y

produzcan un diseño correcto antes de que empiece la implementación.

Funciona bien para proyectos pequeños donde los requisitos están bien

entendidos.

Es un modelo en el que todo está bien organizado y no se mezclan las

fases. Es fácil de mantener ya que cada fase tiene entregables específicos y un

proceso de revisión. Las fases son procesadas y completadas de una vez.

Para proyectos complejos, largos resulta un modelo pobre y por

supuesto en aquellos en los que los requisitos tengan un alto riesgo de ser

cambiados.

En el caso de mi proyecto como es un prototipo y los requisitos están

bien definidos desde el principio, no es un proyecto excesivamente largo y

siguiendo secuencialmente los pasos de análisis, diseño implementación y

pruebas, creo que la mejor opción es usar el modelo en cascada



2. CONTEXTO DEL PROYECTO En esta sección se va a tratar el ámbito del desarrollo de las

aplicaciones móviles, trataré las distintas tecnologías y metodologías usadas

dentro del dominio de las aplicaciones móviles, y las más usadas y conocidas.

También haré un estudio sobre las aplicaciones de servidor y bases de

datos externas, que pueden servir de apoyo a la aplicación y dentro de estas

las más comunes y porque me he decantado a usarlas.

2.1 Desarrollo de aplicaciones móviles Cada vez más usuarios dejan de lado su ordenador portátil para cederle

el monopolio al móvil y a la Tablet. Las aplicaciones móviles ya se ven como la

tendencia de la programación de cara al futuro próximo.

Estas aplicaciones cada vez más ganan terreno, consiguiendo en las

empresas o en profesionales gran cantidad potencial de clientes.

2.2 Estudio de mercado de dispositivos móviles2 2.2.1 El móvil en España

Nadie usa más el Smartphone que nosotros: España consolidó su

liderazgo en el mercado de teléfonos inteligentes en Europa.

De todas las líneas de móviles activas de España el 87% son

Smartphone.

Todos los españoles que se conectan a Internet lo hacen también desde

su Smartphone y el 90% de los usuarios se conecta todos o casi todos los días.

2.2.2 Introducción de Tablets

El acceso a Internet desde la Tablet aumentó un 14% durante 2014.

2 Información obtenida de: http://www.ditrendia.es/wp-content/uploads/2015/07/Ditrendia-

Informe-Mobile-en-Espa%C3%B1a-y-en-el-Mundo-2015.pdf

http://www.ditrendia.es/wp-content/uploads/2015/07/Ditrendia-Informe-Mobile-en-Espa%C3%B1a-y-en-el-Mundo-2015.pdf

http://www.ditrendia.es/wp-content/uploads/2015/07/Ditrendia-Informe-Mobile-en-Espa%C3%B1a-y-en-el-Mundo-2015.pdf



Un 54,7% de las personas que tiene Smartphone también se conecta a

Internet a través de la Tablet.

Los españoles pasan casi dos horas al día en Internet desde su Tablet.

2.2.4 Uso de las Apps

El uso de las aplicaciones móviles es la manera preferida de los usuarios

de conectarse con el móvil: casi el 90% del tiempo de conexión se destina al

uso de aplicaciones.

Cada mes se lanzan 40.000 nuevas aplicaciones al mercado del móvil.

Google Play Store y Apple Storeobtuvieron en 2014 más de 2 millones

de Apps a los usuarios3.

Viendo que los dos grandes sistemas operativos más usados con

respecto a los demás son IOS y Android.

Por lo tanto, haré un estudio y comparativa de ambos

3 Gráfica obtenida de : http://www.netmarketshare.com/

Ilustración 2.1Gráfica sobre el porcentaje de uso de los sistemas operativos para móviles en España.

http://www.netmarketshare.com/



2.3 Desarrollo 2.3.1 IOS

Las aplicaciones para IOS son desarrolladas en Objective-C y

actualmente se usa Swift que se acaba de desarrollar para IOS.

Los usuarios de IOS tienden más a gastar su dinero comprando

aplicaciones. Es más lucrativo para los desarrolladores.

Uso de protocolos de seguridad sólidos. Es complicado que las

aplicaciones se corrompan o sean copiadas por desarrolladores maliciosos.

2.3.2 Android Volverse un desarrollador de Google es simple y requiere una tarifa

única de $25 (USD) para poder enviar aplicaciones de forma ilimitada.

Las aplicaciones de Android pueden ser desarrolladas utilizando

sistemas operativos modernos como Windows, Mac o Linux.

Un kit de desarrollo está disponible para descargar del repositorio de

Google. El lenguaje de programación de Android es un set de APIs de Java.

2.4 Decisión tecnología usada para la aplicación Para concluir con este apartado antes de entrar en la fase de análisis se

va a explicar cuál de las anteriores tecnologías se va a escoger para el

desarrollo de mi aplicación móvil.

Mi elección ha sido usar Android ya que es el sistema operativo para

móviles más usado con respecto al que le viene por detrás IOS, además el

lenguaje de programación es un set de Apis de Java, lo cual va a resultar muy

familiar de desarrollar, ya que a lo largo de mi trayectoria como estudiante en la

universidad he utilizado en varias practicas el lenguaje de programación de

Java.

Y como plataforma de desarrollo elijo androidstudio ya que dispone

soporte por parte de google.



2.5 Aplicación para el servidor4 Y para el servidor vamos hacer un estudio de tecnologías posibles para

apoyar nuestra aplicación de android a una base de datos externa

2.5.1 Gestores de Bases de Datos externas

La conexión directa a un Gestor de Base de Datos Externo desde

Android es una posibilidad completamente factible.

Es verdad que el sistema operativo Android trabaja con SQLite sin un

servidor que funcione como capa intermedia entre el S.O. y el Gestor de Base

de Datos

Android no te permite la creación de un servidor dentro de nuestro

dispositivo, pero si queremos podemos darle permisos de internet en la

aplicación para que pueda conectarse a una base de datos externa.

Los siguientes SGBD que describo a continuación permiten una

conexion de una base de datos con una aplicación Android.

2.5.2 CouchDB

Gestor de base de datos de código abierto, da servicio a aplicaciones

web (licencia Apache License), se trata de una base de datos NoSQL, es

decir, no usan el lenguaje de consultas estructurado o SQL como principal

lenguaje de consultas.

x Almacenamiento de datoscomodocumentos, utilizando los pares

campo/valorqueproporciona JSON

x Permitereplicar los datosparaposiblespérdidas de conexión,

muyútil en dispositivosmóviles, actualizando los datos al volver a

unestadoOnLine.

4Información obtenida de: http://academiaandroid.com/conexion-base-datos-externa-android-sgbd/

http://academiaandroid.com/conexion-base-datos-externa-android-sgbd/

http://academiaandroid.com/conexion-base-datos-externa-android-sgbd/



x Características de transacción ACID: Atomicity, Consistency,

Isolation and Durability (Atomicidad, Consistencia, Aislamiento y

Durabilidad).

2.5.3 FireBird

Sistema de administración de base de datos relacional de código abierto,

que utiliza el lenguaje de consultas SQL. Posibilita modelos sencillos

monousuario hasta desarrollos empresariales con varias bases de datos de

más de 500 GB y con numerosos clientes de manera simultánea.

x Arquitecturamultigeneracional, quepermite el desarrollo y soporte

de aplicacioneshíbridas OLTP y OLAP.

x Soportaprocedimientosalmacenados, disparadores, eventos y

funcionesdefinidaspor el usuario.

x Recomendableparadesarrollaraplicacionesinteroperables en

ambienteshomogéneos e híbridos.

x Alto rendimiento, instalaciónsencilla,

pequeñotamañoquefacilitasudistribución y buenaescalabilidad

(capacidad de crecimiento y adaptación a

nuevasimplementaciones sin perdereficiencia).

x ArquitecturaCliente/Servidorsobre el protocolo TCP/IP.

x Seguridadbasada en usuarios/roles.

x Posibilita el almacenamiento de elementos BLOB (Binary Large

Objects).

2.5.4 PostgreSQL

SGBD objeto-relacional, distribuido bajo licencia BSD y con disponibilidad

completa sobre el código fuente. Utiliza el modelo cliente/servidor, y usa

multiprocesos en lugar de multihilos, para garantizar que el fallo en un proceso

no afecte al resto de procesos en ejecución.

Características principales:

x Base de Datos ACID.



x Funciones y procedimientos almacenados en varios lenguajes de

programación, como PL/pgSQL, PL/Perl, PL/Python y PL/Tcl.

x Acceso encriptado vía SSL.

x Integridad referencial

x Permite copias de seguridad en caliente.

x Gigante tamaño de la estructura de Base de Datos: 2.5.5 MySQL

Sistema de gestión de base de datos relacional multiusuario y multihilo.

Software libre,está considerada como la base datos open source más popular

del mundo

x Sistemas de almacenamientotransaccional y no transaccional.

x Servidordisponiblecomo software externopara un

entornocliente/servidor.

x Registros de longitudfija y longitud variable.

x SoportanumerososSistemasOperativos:

x Reserva de memoriabasada en threads.

2.6 Decisión tecnología usada para la aplicación de servidor He decidido usar MySql como soporte de base de datos externa a mi

aplicación porque es un sistema de gestión de base de datos relacional, que

usa Sql, para mí es un lenguaje familiar usado durante toda mi trayectoria

académica en el Universidad de Jaén.

Además usa una instalación rápida y sencilla en el equipo del servidor.

También buscando en internet, vi la opción de un hosting gratuito, que te

permite crear hasta 2 bases de datos mysql llamado hostinger.

Hostinger provee almacenamiento y hosting web gratis con PHP y

MySQL.

Por lo que además de tener almacenada mi base de datos, puedo tener

mis archivos PHP que cooperen con la base de datos y la aplicación y me

devuelvan



La información necesaria y recogerla en Json.

Más adelante en el capítulo de implementación explico cómo aplicación

y servidor funcionan correctamente.

3. PLANIFICACIÓN DEL PROYECTO 3.2 Listado de tareas

Como se puede ver en el proyecto hubo un parón intermedio entre el

diseño y la implementación, porque tenía en un principio entregarlo para el

primer cuatrimestre, y al final se complicó el proyecto y lo reenganche el 1 de

abril con la implementación.

3.3 Diagrama de Gantt

Ilustración 3.2 Gantt parte 1

Ilustración 3.1 Listado de tareas



4. ANÁLISIS Con el objetivo de tener un proyecto software que cumpla las

expectativas propuestas, deberemos de conocer los requisitos software del

sistema y tener una completa comprensión de estos.

El análisis de requisitos es un proceso encargado de descubrir, modelar

y especificar.

Se buscan soluciones alternativas. El análisis da la capacidad al

desarrollador del rendimiento del proyecto software, permite establecer la

interfaz del software y implanta en nuestro software las restricciones que debe

cumplir.

4.2 Personas Con la herramienta de personas, creamos unos personajes ficticios que

asemejen los usuarios en la situación real que vayan a utilizar la aplicación.

La gran ventaja de esta herramienta es poner al desarrollador de la

aplicación en la situación lo más parecida de los usuarios finales.

Esta técnica la basaré a personas implicadas en la utilización de la

aplicación para la selección de TFG.

Voy a crear 3 tipos de usuarios. Que van a ser los alumnos de 2 distintos

grados dentro de la facultad de humanidades y ciencias de la educación que

será a la que le haremos la aplicación. Y un usuario administrador que será

miembro del comité del TFG.



Descripción Persona 1

Nombre Elena González Pérez

Información personal 24 años, Mujer, estudiante de la Facultad de

humanidades y ciencias de la educación,

cursando 4º de magisterio de educación

infantil.

Nivel de habilidad con los dispositivos ordenador/Smartphone

Novata, y un poco pasota de las tecnologías,

le cuesta adaptarse al cambio de una nueva y

moderna plataforma software.

Uso con los dispositivos ordenador/Smartphone

Uso diario de las redes sociales, uso del

navegador en ambos dispositivos.

Utiliza el PowerPoint, PDF, y Word para los

trabajos que les mandan de la universidad.

En ocasiones Juega con algunas aplicaciones

de su Smartphone.

Suele mirar el correo cuando se acuerda.

Uso que hará en la aplicación

Podrá elegir que temática o tutor de TFG le

interesa y elegirlo a través de una aplicación

software.

Como le ayudará la aplicación a alcanzar sus objetivos

Tendrá la posibilidad de tener su TFG elegido

a través de una aplicación software, de una

manera informática sencilla y centralizada sin

tener que recurrir a ningún otro tipo de

proceso más engorroso manualmente en

Ilustración 4.1



papel.


Nombre Laura Rodríguez Estévez

Información personal 22 años, mujer, estudiante de la Facultad de

humanidades y ciencias de la educación,

cursando 4º de Grado en Psicología.


Nivel usuario avanzado, desde siempre a

Laura le han gustado las tecnologías, además

hizo un curso avanzado del paquete office.

Muy avispada y le gusta investigar los temas

multimedia y hacer buenas presentaciones en

sus trabajos universitarios.


Usa ambos dispositivos diariamente para

hacer trabajos de clase, compra online de ropa

y de dispositivos electrónicos, también suele

leer por internet artículos, y utiliza varias

aplicaciones de móviles de diferente ámbito.

Diariamente mira el correo para ver cualquier

novedad.

Uso que hará en la aplicación

Podrá elegir que temática o tutor de TFG le

interesa y elegirlo a través de una aplicación

Ilustración 4.2



software.


Tendrá la posibilidad de tener su TFG elegido

a través de una aplicación software, de una

manera informática sencilla y centralizada sin

tener que recurrir a ningún otro tipo de proceso

más engorroso manualmente en papel.


Nombre José López Castro

Información personal 42 años, Varón, miembro del comité de TFG

de la facultad de humanidades y ciencias de la

educación


Nivel avanzado de usuario buen manejo de

bases de datos Access y paquete office y

habilidad con otras herramientas software


José le gusta usar varias herramientas

software, usa una aplicación software para la

gestión de contabilidad de sus cuentas

bancarias, usa el Excel, Access y

continuamente revisa el correo desde su

Smartphone por si tiene alguna novedad

Uso que hará en la Recoger el informe de la selección de los

Ilustracion 4.3



aplicación TFGde alumnos cada titulación de la Facultad

y asignación de los TFG


Le ahorrará un esfuerzo y un trabajo enorme,

ya que a través de la aplicación los alumnos

podrán seleccionar su TFG y esta los

gestionará de manera automática sin tener

que intervenir el comité, únicamente en el

informe final.

4.3 ESCENARIOS Es una técnica de la ingeniería del software que nos permite visualizar

de una manera real, la forma en la que los actores se desenvuelven en un

determinado escenario de nuestro sistema. Con esta información recogida

podremos formular los auténticos Requisitos del sistema.

Componentes de un escenario:

1. Como se desenvuelve el personaje en las tareas actuales de nuestro

sistema

2. Actores o Personajes, que tienen alguna finalidad.

3. Procesos usados, mostrando si han sido eficaces o no.

4. Conclusión realizadas por los actores de lo ocurrido.

Vamos a especificar los siguientes escenarios de nuestro sistema siguiendo

una narrativa en la que represente la historia completa que interaccionan los

actores en el escenario concreto con respecto a la forma que trabajan

actualmente.

4.3.1 Escenario 1: Cómo se matriculan los alumnos del TFG

Narrativa del escenario:

Laura recibe un correo de que ya está disponible la matricula del TFG,

entonces, se va a docencia virtual, busca la asignatura TFG

dentro de su titulación, y le da a matricularse.



Una vez subscrita a la asignatura pasará a estar matriculada en el

proceso de selección de TFG.

4.3.2 Escenario 2: Cómo se enteran los alumnos de cuándo hay que empezar a inscribirse en el TFG


Elena, para ver la información de todo el proceso para inscribirse al TFG se va

a la página de la universidad dentro del apartado de su facultad y TFG y miran

el documento “CALENDARIO DE ACTUACIONES PARA LA PRESENTACIÓN

Y DEFENSA DE LOS TRABAJOS DE FIN DE GRADO (TFG) EN EL CURSO

2015/2016”5

Aunque esta sección le desglose toda la información para solicitar su TFG tiene

que estar pendiente de todos los tiempos y procesos de manera manual y que

no se le olvide ninguno para poder inscribirse de manera correcta.

4.3.3 Escenario 3: Cómo se enteran los alumnos de las ofertas de los TFG y plazas que hay


Laura, para ver la toda la información de su TFG referente a Temáticas de

proyectos tutores que los imparten y número de plazas, se va a la página de la

universidad en el apartado de su facultad, y mira el documento de su grado

“LISTA DE LINEAS DE TRABAJO”6 y va apuntando en un papel o escribiendo

en un documento cuales son los que más le interesan para cuando tenga que

elegirlos tenga claro cuáles serán.

4.3.4 Escenario 4: Cómo seleccionan los alumnos los TFG propuestos


5Anexo Calendario de actuaciones 6Anexo Oferta de TFG



Elena, para seleccionar los TFG se va a la página de la universidad en el

apartado de su facultad, y se descarga el documento de “SOLICITUD DE

ASIGNACIÓN DE TRABAJO DE FIN DE GRADO (TFG)”7

Va rellenando a bolígrafo uno a uno el TFG con una prioridad hasta 30

Trabajos para no quedarse sin ninguno. Una vez escritos todos y firmado,

escanea el documento y lo manda a la actividad que tiene abierta en docencia

virtual dentro de la asignatura TFG.

El problema de esto es que María puede equivocarse y volver a escribir

un TFG que ya haya puesto anteriormente, es decir escribir un TFG en su lista

más de una vez, esto permitiría que perdiera una plaza de otro proyecto que

quisiera.

4.3.5 Escenario 5: Cómo se entera el alumno de que posición de su lista de TFG les ha sido asignado Narrativa del escenario:

Juana es una alumna de la facultad de humanidades y ciencias de la

educación, en realidad no se entera en qué posición según su lista de

prioridades es su TFG asignado.

La única manera que tiene de comprobarlo, es mirando una copia de la

lista que se guardo y observa en que puesto esta el que le han asignado.

A Juana le gustaría que le mandaran un mensaje diciéndole en qué

posición es la que le han dado sin tener que comprobar dicha copia

4.3.6 Escenario 6: Cómo asignan los miembros del comité de TFG de la facultad a los alumnos dichos TFG


José para ir seleccionando TFG a cada alumno según sus prioridades,

como va en orden de expediente, se va al primer alumno de cada titulación y va

7Solicitud de asignación de TFG general en : http://www10.ujaen.es/conocenos/centros/fachum/docencia/tfg

http://www10.ujaen.es/sites/default/files/users/fachum/tfg/Anexo%20IIb%20%282015-16%29.doc

http://www10.ujaen.es/conocenos/centros/fachum/docencia/tfg



pasando a posteriori el siguiente alumno con menos nota asignándole según la

prioridad de estos, y rellenando las plazas como ocupadas en los TFG

seleccionados para que los siguientes alumnos no puedan escoger los

ocupados.

José cree que es un proceso agotador, ya que cada titulación tiene

muchos alumnos y cada alumno muchos TFG elegidos unos 30 por cada

alumno, Manuel ve mucho mejor informatizar este proceso, no solo por la

reducción de trabajo que supondría, sino también porque minimizaría la

posibilidad de cometer errores.

4.4 Requisitos Los Requisitos de nuestro sistema software son las definiciones, de lo

que nuestro sistema debe realizar, el servicio que nos proporciona, y las

restricciones de comportamiento que tiene.

Dado que en nuestro sistema va coexistir una aplicación de usuario y un

servidor en la que ambos interactuaran para petición y transmisión de datos,

tendremos que tener en cuenta Requisitos para ambos.

4.4.1 Requisitos funcionales:

Los Requisitos funcionales del sistema definen cómo debería rebelarse

el sistema a entradas específicas, de cómo debería actuar en situaciones

concretas y lo que el sistema no debe hacer.

Para hacer una buena especificación de Requisitos funcionales del

sistema, deben de definirse todos los servicios necesarios por el usuario, y de

una manera correcta sin ambigüedad y no permitir definiciones de Requisitos

que se contradigan.

4.4.2 Requisitos no funcionales:

Los Requisitos no funcionales especifican las limitaciones de los

servicios o las funciones que proporciona el sistema.

El rendimiento de nuestro sistema, si el sistema es seguro o la

disponibilidad, especifican características del sistema como un todo.



4.4.3 Requisitos funcionales lado servidor

x Los administradores deberán dar de alta los alumnos en la base de

datos del servidor con la siguiente información:

o Nick: será el de cada alumno, con el que tienen acceso a la

universidad de Jaén. El formato de este sería

[email protected]

o Apellidos

o Nombre

o Titulación: la que pertenece el usuario dentro de la propia

facultad, para poder asignarle TFG de su propia titulación

o Expediente académico sobre 4 y sobre 10

o DNI

x Los administradores pueden gestionar TFG o tutores disponibles

x Los administradores podrán dar inicio al proceso automático de TFG y

gestionar la asignación de los TFG

x Proporcionar un servicio de autenticación:

o El sistema debe obligar al usuario meter el Nick y Contraseña de

este.

o El sistema debe comprobar que ese usuario y ese Nick están

registrados y pueden acceder.

x Servidor guarda los datos procedentes de la aplicación

o Dentro del servidor en la base de datos guardaremos los datos

actualizados del alumno

x El servidor no debe permitir hacer login a alumnos distintos de la

facultad de humanidades y ciencias de la educación, no puede dejar

permiso a alumnos de otras facultades o personal que no sea de la

universidad.

x El servidor transmite la información a la aplicación a través de las

peticiones que manda al servidor.

x Valida los datos guardados del usuario.

x Exportar Informes de los TFG elegidos de cada grado.

mailto:[email protected]



4.4.4 Requisitos funcionales lado aplicación móvil

x Mostrar listado temática de TFG y tutores

o El usuario visualizará las temáticas de TFG y tutores disponibles

x Selección de TFG a la lista del usuario permitiéndole al usuario añadir

nuevos.

x Opción de borrado a la lista del usuario permitiéndole al usuario borrar

TFG ya seleccionados

x Salir sin guardar ningún valor

o Una vez elegida esta opción, la aplicación no le envía ningún

cambio nuevo al servidor

x Enviar datos al servidor

o Una vez rellenados los TFG se traspasan los datos al servidor

x Modificar TFG

o El alumno podrá ir cambiando las prioridades de sus TFG las

veces que quiera dentro del periodo establecido.

x El proceso de selección estará abierto durante los días establecidos de

la elección de TFG, una vez pasados estos días, o antes del tiempo

establecido ningún alumno podrá elegir TFG.

x La aplicación no debe permitir hacer login a alumnos distintos de la

facultad de humanidades y ciencias de la educación, no puede dejar

permiso a alumnos de otras facultades o personal que no sea de la

universidad.

x La aplicación no debe permitir a alumnos pertenecientes a un grado

concreto seleccionar la oferta TFG de otros grados.

x La aplicación envía peticiones al servidor, para recibir la información que

esta solicita o para actualizar la información nueva de la aplicación al

servidor.

x Valida los datos enviados por el usuario.

4.4.5 Requisitos NO funcionales que usaremos:

x La aplicación tiene que poder visualizarse y utilizarse en cualquier

plataforma android.



x La aplicación y el servidor tiene que ofrecer tiempos de respuesta

cortos

x Interfaz de usuario fácil de usar

x Si el usuario dispone de internet, la aplicación debe funcionar al

completo

4.5 Diagrama frontera En este diagrama he representado todos los casos de uso que he tenido

en cuenta en el análisis de Requisitos, una vez mostrados cuales vamos a

utilizar, los desarrollaré con más detalle en los diagramas de caso de uso.

Este va a ser nuestro diagrama frontera general, donde separaremos los

servicios del servidor junto con las base de datos de la aplicación.

Ahora desglosaremos las tareas que tienen el servidor y la aplicación en

paquetes con varios casos de uso

4.5.1 Paquete del servidor

Dentro del paquete del servidor se encuentran los casos de uso de las

principales tareas que va a tener el servidor con el administrador, haciendo uso

Ilustración 4.4 Diagrama frontera



de la base de datos, comunicación con la aplicación, y por último la asignación

de los TFG por parte del administrador al comité de TFG

Ilustración 4.5 Diagrama Frontera lado servidor

4.5.2 Paquete de la aplicación

En el paquete de la aplicación hemos identificado los servicios

principales de la aplicación, y como podernos observar, interactúa con el

servidor, tanto para guardar la nueva información del alumno actualizada, como

para recibir los listados de los TFG disponibles.



Ilustración 4.6 Diagrama Frontera aplicación



4.6 Narrativa de casos de uso servidor

Caso de uso: Login servidor

Actor primario: Administrador Actor secundario: Servidor / Base de datos Precondición: El administrador deberá de estar reconocido en la base de

datos

Post condición: El administrador queda autenticado en el sistema.

Secuencia de actividades: � Escenario principal de éxito:

1. El administrador manda la petición al sistema para entrar en

este

2. El sistema le devuelve el formulario de acceso

3. El administrador rellena el formulario y lo envía al sistema

4. El sistema envía el formulario a la base de datos del sistema y

comprueba que los datos son correctos

5. La base de datos informa de que los datos introducidos son

correctos y el sistema muestra las opciones disponibles para

este usuario

� Escenario alternativo: 4a El usuario o contraseña erróneos

4b El usuario mete los datos de nuevo

5 a.El sistema informa de que ha habido un fallo de la conexión a

internet con la base de datos.

5 b El sistema informa de que el periodo de registro a la aplicación

ha terminado

5c El sistema informa de que ha sido imposible acceder al sistema



Caso de uso: Dar de alta usuarios

Actor primario: Administrador Actor secundario: Servidor / Base de datos Precondición: El administrador deberá de estar conectado al sistema.

Post condición: El administrador registra a nuevos usuarios en el sistema


1. El administrador selecciona la opción de registrar alumnos en

el sistema 2. El sistema le envía el formulario de gestión de alumnado 3. El administrador mete los datos en el formulario 4. El sistema le envía el formulario a la base datos 5. La base de datos comprueba que los datos son correctos y

envía un mensaje de confirmación al sistema. 6. El sistema envía un mensaje al administrador de que los datos

han sido almacenados satisfactoriamente. � Escenario alternativo:

5b. El sistema informa de que ha habido un error en los datos a la

hora de almacenarlos en la base de datos

5c. El administrador mete los datos de nuevo



Caso de uso: Exportar informes de los TFG


Post condición: El administrador recibe un informe de los alumnos y su

respectivo TFG seleccionado


1. El administrador marca la opción en una titulación, a sacar

informe final de los TFG asignados de los alumnos 2. La base de datos le envía al sistema toda la información 3. El administrador recibe toda la información a través del

sistema en formato PDF � Escenario alternativo:

2b. La base de datos muestra un error a la hora de exportar el

informe



Caso de uso: Gestionar Temática TFG y tutores


Post condición: El administrador inserta/borra o modifica TFG y tutores

ofertados


1. El administrador selecciona la opción de Gestionar Temática

TFG y tutores 2. El administrador inserta/borra o modifica un TFG o tutor nuevo

a la base de datos 3. La base de datos informa al sistema de que los cambios se han

realizado correctamente 4. El sistema informa al usuario de que el proceso de gestión se

ha realizado con éxito. � Escenario alternativo:

3b. La base de datos informa al sistema de que los datos no han

sido guardados con éxito

3c. El administrador mete los datos de nuevo



Caso de uso: Envío de información a la aplicación

Actor primario: Servidor / Base de datos Actor secundario: Aplicación

Precondición: La aplicación envía peticiones para la información que

necesita.

Post condición: La base de datos del servidor le envía la información que

esta pide.


1. La aplicación necesita información sobre los listados de

Tutores y TFG disponibles y envía una petición al servidor

2. El servidor gestiona esta petición y pide a la base de datos

información sobre la petición. 3. La base de datos responde con esta información al sistema 4. El sistema envía la información correspondiente a la aplicación

� Escenario alternativo: 3b. La base de datos no está disponible en ese momento

3c. El sistema manda un aviso a la aplicación

3d. La aplicación manda de nuevo una petición de información



Caso de uso: Actualizar datos procedentes de la aplicación

Actor primario: Servidor / Base de datos Actor secundario: Aplicación

Precondición: La aplicación envía peticiones para almacenar información

en la base de datos

Post condición: La base de datos del servidor guarda la información del

alumno procedente de la aplicación


1. La aplicación envía una petición al sistema para guardar

los datos del alumno en el servidor

2. La base de datos informa al sistema de que ya está

disponible para guardar los nuevos datos

3. La aplicación envía los datos del alumno al sistema

4. El sistema guarda los datos en la base de datos e

informa al sistema de que se han enviado correctamente

� Escenario alternativo: 2b La base de datos no está disponible

4b. Los datos no se han enviado correctamente a la base de

datos.

4c. El sistema manda un aviso a la aplicación de que mande de

nuevo los datos

4d. La aplicación manda de nuevo los datos al sistema



Caso de uso: Gestionar asignación TFG

Actor primario: Administrador Actor secundario: Comité TFG

Precondición: El administrador deberá de estar conectado en el sistema

Post condición: Comienzo del proceso automático de TFG encargado de la

gestión de asignación de los TFG al comité


1. El administrador selecciona la opción de Asignación de TFG

según una titulación 2. El sistema le envía la asignación de esa titulación al comité

de TFG � Escenario alternativo:

2b. El sistema tiene un error a la hora de iniciar el proceso de

asignación y no le envía ningún dato al comité



Caso de uso: Salir del sistema

Actor primario: Administrador Actor secundario: Sistema del servidor

Precondición: El administrador deberá de estar conectado en el sistema

Post condición: El administrador se desconecta del sistema


1. El administrador selecciona la opción de desconectarse

del sistema

2. El sistema desconecta al administrador

� Escenario alternativo: 2b. El sistema tiene problemas a la hora de desconectar al

administrador

2c. El administrador intenta salir del sistema de nuevo



4.7 Narrativas de caso de uso de la aplicación

Caso de uso: Login de la aplicación

Actor primario: Alumno Actor secundario: Aplicación y Servidor

Precondición: El alumno deberá de estar reconocido en la base de datos

Post condición: El alumno queda registrado en la aplicación


1. El usuario abre la aplicación y envía sus datos en el

formulario principal

2. La aplicación se conecta con la base de datos para

confirmar si el alumno esta registrado

3. El servidor devuelve a la aplicación que sus datos son

correctos

4. La aplicación deja acceder al alumno a la pantalla

principal

� Escenario alternativo: 3c. El servidor muestra un error: el alumno no pertenece a la

universidad de Jaén

3d. El servidor muestra un error: el alumno pertenece a la

universidad de Jaén, pero no a la facultad de humanidades y

ciencias de la educación

3e. El usuario mete los datos y los envía de nuevo



Caso de uso: Añadir o borrar TFG

Actor primario: Alumno Actor secundario: Aplicación

Precondición: El alumno debe de estar conectado a la aplicación

Post condición: El alumno añade o borra TFG a su lista prioritaria


1. El alumno selecciona la opción de insertar o borrar TFG

en su tabla de prioridades

2. La aplicación inserta o borra TFG de su tabla de

prioridades

� Escenario alternativo: 2b. La aplicación informa de un error a la hora de insertar o borrar

un TFG



Caso de uso: Modificar selección anterior



Post condición: El alumno cambia su tabla de prioridades de TFG

anteriores


1. El alumno se conecta al sistema y elige la opción de

modificar sus prioridades 2. La aplicación permite al alumno cambiar de nuevo sus

prioridades � Escenario alternativo:

2b. La aplicación muestra un error al alumno de que no puede

cambiar sus prioridades



Caso de uso: Guardar datos al servidor

Actor primario: Alumno Actor secundario: Aplicación / servidor


Post condición: La aplicación guarda los datos del alumno en el servidor


1. El alumno selecciona la opción de guardar datos de la

aplicación

2. La aplicación pregunta al servidor si está disponible para

guardar los datos

3. El servidor responde a la aplicación y la aplicación le envía

los datos del alumno

4. El servidor guarda los datos y envía a la aplicación que los

datos han sido guardados de forma correcta

� Escenario alternativo: 2b. El servidor manda a la aplicación un error de que no está

disponible

2c. La aplicación le envía de nuevo los datos

3b. El servidor no responde y la aplicación le indica al alumno que

vuelva a enviar los datos



Caso de uso: Listar TFG por orden de Temática / Tutor

Actor primario: Alumno Actor secundario: Aplicación / servidor


Post condición: El alumno pide mostrar la informacion de TFG por orden

de Temática /Tutor


1. El alumno selecciona la opción de mostrar TFG por orden de

Temática / Tutor 2. La aplicación manda al servidor la petición de la informacion

necesaria 3. El servidor responde a la aplicación la informacion

correspondiente 4. El alumno visualiza las ofertas por orden.

� Escenario alternativo:

3b. El servidor manda un error a la aplicación de que no puede

enviarle los datos.

3c. La aplicación manda de nuevo los datos.



Caso de uso: Salir de la aplicación



Post condición: El alumno se desconecta de la aplicación


1. El alumno selecciona la opción de salir de la aplicación 2. La aplicación desconecta al alumno

� Escenario alternativo: 2b. La aplicación tiene un error para desconectar al alumno del

sistema

2c. El alumno vuelve a seleccionar la opción de desconectar el

sistema



4.8 Modelo del dominio Tenemos un modelo del dominio donde están representadas las

clases conceptuales obtenidas a partir de conceptos o entidades procedentes

de la parte del mundo real que representa el dominio del problema.

Con el modelo del dominio obtenemos una visión de la parte del

problema quees relevante para nuestra aplicación (el dominio del problema)

4.8.1 Transición del Análisis al Diseño

Objetivo

Obtener un conjunto de clases más cercanas a la implementación

donde:

x Los conceptos procedentes del modelo del dominio que se puedan

utilizar en eldominio de la solución (clases software).

x Nuevas clases adicionales que se consideren necesarias para dar una

estructurade clases poco acoplada y cohesiva de nuestra aplicación.

Modelo del dominio

Solo se muestran entidades y atributos desde el punto de vista del análisis



Ilustración 4.8 Modelo del dominio



5. DISEÑO El diseño de software es una actividad creativa donde se identifican los

componentes del software y sus relaciones, con base en los requisitos de un

cliente previamente recogidos en la fase anterior del análisis

5.1 Diseño arquitectónico Es la primera etapa para el proceso de diseño de software, define como

debe ser la organización un sistema y como debe de diseñarse la estructura

global de este.

Es el enlace crítico entre el diseño y la ingeniería de requisitos, identifica

los principales componentes estructurales del sistema y la relación entre ellos.

En el desarrollo de aplicaciones android con la herramienta

androidstudio usamos la arquitectura MVC (Modelo de vista del controlador)

5.1.2 DescripciónMVC: Separa la presentación e interacción de los datos

del sistema. El sistema se estructura en 3 componentes lógicos que interactúan

entre sí.

x Componente modelo: Maneja los datos del sistema y sus operaciones.

x Componente controlador: maneja las interacciones del usuario y pasa

estas a vista y modelo.

x Componente vista: Define y gestiona como se presentan los datos al

usuario. Cuando se usa

Se utiliza cuando existen varias formas de ver e interactuar con los datos.

Ventajas

Permite que los datos cambien independientemente de su representación

Desventajas

Si el modelo de datos y las interacciones no son complicados, puede implicar

código adicional y complejidad de código.



Ilustración 5.1 Modelo Vista -Controlador



5.2 Diseño de casos de uso En las primeras fases del proceso de diseño se considera que existen

modelos que son útiles para añadir detalle a los modelos de caso de uso y

arquitectónico.

x Modelos de subsistema, que presentan los agrupamientos lógicos de

objetos en subsistemas coherentes

Se representan mediante una forma de diagrama de clase, son modelos

estáticos (estructurales)

x Modelos de secuencia, que presentan las secuencia de interacciones de

objetos, se ilustran mediante una secuencia UML, son diagramas

dinámicos

5.2.1 Visual paradigm

Visual Paradigmfor UML es una herramienta CASE que soporta el

modelado mediante UML y proporciona asistencia a los analistas, ingenieros de

software y desarrolladores durante todos los pasos del Ciclo de Vida de

desarrollo de un Software.

Esta herramienta ha sido utilizada para el diseño de cada uno de los

diagramas del proyecto.

Decidí usar esta aplicación porque la hemos utilizado a lo largo de la

carrera en prácticas como la asignatura de ingeniería del software.

5.3 Diagrama de clases de diseño Como he comentado en el apartado anterior este diagrama junto con los

diagramas de secuencia de los casos de uso, son fundamentales exponerlos

dentro de la fase del proceso de diseño

Aquí tenemos el diagrama de las clases de diseño de nuestra aplicación

android.



El diagrama de clases de la aplicación incluye cada una de las clases y

sus relaciones existentes del modelo de la aplicación en android

Como se puede ver existen 2 tipos de clases

Ilustración 5.2 Diagrama de clases de diseño



Explico los conceptos de cómo está dividido el diagrama para que sea

más amigable de entender

Azules:

Las clases azules son las clases que vamos a desarrollar en la

implementación de nuestra aplicación.

Moradas:

Son un tipo de clases específicas que permiten extenderse de las clases

de android, para dar a esta una funcionalidad determinada, en algunos casos

pueden actuar como atributos dentro de una clase o ser una propia clase que

extienda o use de otra.

Ejemplo la clase UserLoginTaskse extiende de la clase específica

Asyntaskpara crear un hilo asíncrono dentro del login de la aplicación.

5.3.1 Asynctask (Tareas asincronas)

Esta clase nos va a permitir realizar tareas en segundo plano,

Tendremos que hacerlo siempre que exista la posibilidad de que una tarea

pueda bloquear el hilo del interfaz de usuario. Esto suela ocurrir en cálculos

complejos o en accesos a la red.

Todas las clases asíncronas usan al menos 2 métodos

x doInbackGround(parametros) lo que va a ejecutarse en el hilo

secundario.

x PostExcute(parametros) este método se ejecuta justo después de

terminar el hilo.

Contiene dentro de sus parámetros lo que devuelte el

metododoInbackGround()

Antes de entrar en detalle que clases he creado daré unas nociones básicas de

los distintos tipos de clases en android para entender mejor cada una de ellas.



5.3.2 Activities y fragments

Para desarrollar una clase del diagrama de diseño de clases, en android

se crea una clase de tipo activity o fragment

Un activity es una clase de android que contiene una parte de lógica

donde están todos los atributos y operaciones y la parte gráfica que dan

imagen a estas operaciones

Un fragment es como un mini activity; contiene funcionalidades similares

al activity pero un fragment depende del activity que lo creó.

En el caso de mi aplicación solo he creado activities. Los fragment solo

se usan cuando vas a tener varias pantallas distintas dentro de la misma

actividad, el cual no es mi caso.

Una vez explicadas los dos tipos de clases que existen, empezaré

explicando las clases con más detalle, de más relevancia a menor.

LoginActivity

Es la actividad encargada de hacer el login de los usuarios a la

aplicación, implementa la clase que hereda de appCompactActivity por lo tanto

es una actividad de android.

Usa la funcionalidad HttpURLConnection para la conexión con clase

base de datos datos. Porque nuestros usuarios y contraseña están

almacenados en una base de datos del servidor.

Más adelante en el apartado del diseño de los datos explicamos donde y

a través de que tecnologías funciona la base de datos.

También hace uso de una clase llamada UserLoginTask en la que

implementa una tarea asynctask,

En el método doInBackground(String) : Alumno le pasamos por

argumento el email del alumno y la contraseña para comprobar si existe

En el método onPostExecute(Alumno result) en el parámetro result

tendremos el resultado obtenido de si el usuario ha sido encontrado



MainActivity

Es la actividad principal de la aplicación, es la actividad siguiente que se

carga a continuación del login, hereda de appcompactactivity.

Contiene una ListView que es una lista de android donde irán los TFG.

Dentro de cada lista ira un objeto de la clase ArrayAdapter que

contendrá varios elementos de la información de la clase TFG, con relación de

composición.

También usa la propiedad toolbar de android, que le permite tener una

barra de herramientas.

DrawerLayout es el menú lateral que se despliega desde la barra de

herramientas.

HttpUrlConnection que permite la conexión para recuperar los Tutores

de la base de datos.

Utiliza la clase GsonTFGParser para leer los Json que devuelve el

servidor y transformarlos a objetos de tipo tutor

Usa alertDialog para preguntar en un cuadro de diálogo si un usuario

desea salir de la aplicacion

BDServer

Esta es la única clase del diagrama de clases que no está creada en android

como actividad. La base de datos del servidor está creada y alojada según

explico a continuación en el diseño de los datos.

Aunque no exista una clase como tal, en android, pero tienen que hacer uso de

ella a través de 3 metodos, en distintas clases

¾ QueryLogin(Usuario) : Usuario

Se usa dentro del LoginActivitypara hacer la consulta del login

¾ UpdateTFG(Usuario) : Bool



Se usa dentro de la clase de gestión Activity con las tareas asíncronas elige

tutor o elimina.

¾ QueryTFG(Usuario)

Se usa dentro de la clase de GestionActivitycon la tarea asíncronaJsontask2,

que muestra todos los TFGs de un tutor

GestionActivity

Esta actividad como hemos explicado en la actividad de antes usa los

métodos de elegir o borrar tutor, carga todos los TFGs de un determinado tutor

en una lista que deriva de ArrayAdapter que es un adaptador o contenedor

para el array.

También usa la funcionalidad alertDialog para preguntar antes de borrar o

elegir un determinado Tutor.

UsaGsonTFGParser para pasar los TFGs de los tutores de json a un objeto de

tipo tutor_TFG que son los TFGs de un tutor.

IntroduccionActivity

Es un activity que contiene un textView de las instrucciones y plazos para usar

la aplicacion

Alumno, Tutor_TFG, TFG

Estas clases no son actividades de android, son clases que permiten

instanciar objetos con los que van a interactuar las anteriores actividades de

android.

Alumno: Se utilizará en la actividad login y tendrá datos como email y la

titulación, es importante saber de qué titulación es, porque dependiendo de

cuál sea le aparecerán unos tutores u otros en el mainactivity

TFG: Aunque pueda existir confusión en esta clase, todos los datos de

esta clase son referentes al tutor, recordemos que un alumno no elige TFG,

sino un tutor.



Tutor_TFG: Estos son todos los TFGs que hay ofertados por un tutor.

5.4 Diagramas de secuencia de interacción Antes de todo, como se ve en el análisis, hay casos de uso en la parte

del servidor y en la parte de la aplicación, en el diseño de este proyecto solo

nos vamos a centrar en los casos de uso de la aplicación.

Además como es un prototipo solo vamos a diseñar los diagramas de

secuencia interacción del login, Añadir o borrar tutor (Gestión Tutor), ver listado

de Tutores y TFGs disponibles e Información que son los objetivos con los que

cumple nuestro TFG.



5.4.1 Caso de Uso Login

Ilustración 5.3



5.4.2 Caso de Uso Gestión tutor (Añadir tutor, Eliminar tutor)

Ilustración 5.4



5.4.3 Caso de Uso Lista de Tutores Y TFGs

Ilustración 5.5



5.4.4 Caso de uso Información

5.5 Diseño de la base de datos 5.5.1 Base de datos Relacional

Permite establecer interconexiones o relaciones entre los datos (que

están guardados en tablas), y a través de dichas conexiones relacionar los

datos de ambas tablas, de ahí proviene su nombre: "modelo relacional".

Dado que nuestra base de datos es relacional he tenido en cuenta dos

pasos fundamentales a la hora de crear su diseño:

x Crear el modelo Entidad Relación La primera fase del diseño de la base de datos fue la creacion del modelo

entidad Relacion

Esta es la fase del diseño conceptual en donde se muestran las principales

entidades que van a trabajar y cuales de ellas estan relacionadas

independiente de la tecnologia que vamos a usar

Ilustración 5.6



Según el diagrama de entidad relacion anterior:

Tenemos 5 entidades principales

Titulacion: Esta entidad es la que tiene los datos referentes a la carrera

como código de titulacion y nombre.

Ilustración 5.7 Diagrama entidad relación



Departamento: Esta entidad contiene su codigo nombre, codigo de

titulacion a la que pertenece, es el departamento del que dispone de varios

tutores los cuales presentan un proyecto

Alumno : Esta entidad es el usuario que vamos a registrar en nuestra

base de datos y con el que nos va a permitir dar el juego de la selección de los

tutores que contienen dichos TFG´s, por lo tanto esta entidad guardara datos

importantes como su Usuario de la Uja, contraseña (Para el login de la

aplicacion) y datos relevantes como la titulacion a la que pertenecen y los

tutores que han ido eligiendo. Hasta el campo del TFG que se le asignará .

Guardara toda la informacion referente al usuario, ademas del codigo de

titulacion que pertenece y el TFG final que se le ha asignado

Tutor: La entidad tutor que pertenece a un departamento de una

titulacion, ofertará uno o varios TFG , estos serán elegidos según los alumnos

según una lista de prioridades de los alumnos. Esta entidad tendra información

relevante del tutor ademas al codigo de departamento que pertenece

Interrelaciones

Titulacion – Alumno

Una titulacion tendra varios alumnos y un alumno solo puede pertenecer a una

de esta.

Titulación - TFG

Una titulacion ofertará varios TFG´s y cada uno de los TFG pertenece a

una solo de esta.

Titulación – Departamento

La cardinalidad de esta relacion es de N.M , en el paso al modelo

relacional tendremos que crear una tabla intermedia para ambos.

Es N.M porque un departamento puede pertenecer a varias titulaciones y

una titulación tiene varios departamentos



Alumno – Tutor

La cardinalidad es N.M entre alumno que elige un tutor.

Un alumno puede elegir a varios tutores, hasta 30 en nuestro caso, y un

tutor puede ser elegido por varios alumnos.

Por lo tanto, en el siguiente paso al modelo relacional se creará una

tabla intermedia de eleccion Alumno_Tutor.

Tutor - Departamento

La cardinalidad de esta relacion es de 1.N porque un departamento tiene

varios tutores pero un tutor solo puede pertenecer a un departamento

TFG - Tutor

La cardinalidad de esta relacion es 1.N porque un Tutor puede ofrecer uno o

varios TFG, pero un tutor. Aunque puede tener un cotutor asignado un TFG,

pero este se le añadira otro campo a la entidad TFG.

x Transformar el modelo Entidad Relación al modelo Relacional La etapa del diseño lógico es la primera parte del diseño de la base de

datos y se construye las principales entidades del mundo real, ahora en el

diseño lógico vamos a transformar el modelo conceptual al modelo relacional

que será la version final del diseño de los datos dependiendo de la tecnología

que use

Se acomodará al modelo del SGBD con el que funcionará la base de datos

Cada entidad del modelo ER se transforma en una relación del modelo

relacional.

Los atributos de la entidad serán atributos de la relación y, de forma

análoga, la clave primaria de la entidad será la clave primaria de la relación.



Sin embargo en la transformación al modelo relacional surgen unos nuevos

cambios según el tipo de cardinalidad que exista entre las entidades

Cardinalidades 1.N

Entidades implicadas:

Tutor – TFG

Titulación – TFG

Titulacion – Alumno

En este caso sólo es necesario añadir en la relación correspondiente

A la entidad del lado N, una clave foránea que referencie la otra relación.

Cardinalidades N.M

Entidades implicadas

Titulacion-Departamento

Alumno_Tutor

Una interrelación M:N se transforma en una relación. Su clave primaria

estará formada por los atributos de la clave primaria de las dos entidades

Interrelacionadas. Los atributos de la interrelación serán atributos de la nueva

relación.

Por lo tanto entre las entidades mencionadas con dicha cardinalidad N.M

crearemos una tabla intermedia.

Aquí tenemos el diseño logico final de nuestra base de datos MySql

alojada en hostinger



Ilustración 5.8 Diseño de la base de datos



5.6 Diseño de la interfaz inicial El diseño de la interfaz de usuario comienza con la identificación de los

requisitos de usuario, la tarea y el entorno.

Una vez identificadas las tareas del usuario, se crean y analizan los

escenarios para éste y se define un conjunto de objetos y acciones de la

interfaz. Esto forma la base para crear una plantilla de la pantalla que ilustra el

diseño gráfico y la colocación de iconos, la definición de los textos descriptivos,

la especificación y títulos de las ventanas, la especificación de aspectos

mayores y menores del menú.

Los usuarios testean un prototipo de la interfaz y los resultados de este

ensayo se utilizan para la posterior modificación iterativa del prototipo.

A través de los Storyboard se empieza a construir el prototipo, y en los

pasos posteriores adaptándome a la interfaz de android se implementa el

modelo de diseño definitivo evaluando la calidad del resultado.



5.6.1 STORYBOARD

El Storyboard nos permite seguir la historia de nuestra futura aplicación y

ver las distintas opciones y posibilidades que tendrá, he elegido hacerlo a

papel, ya que los cambios que se hagan en el momento serán mucho más

rápidos, que en cualquier otro documento digital.

Es una gran ventaja describir nuestro storyboard antes de la realización

de la aplicación, porque así tendremos una visión más clara de cómo va a ser

la interfaz de nuestro producto software y una mejor idea de cómo vamos a

implementarla.

A continuación mostrare 8 distintas pantallazos de mi aplicación, esto es

un prototipo de mi producto final, lo cual no quiere decir que así vaya a quedar,

posiblemente se le añadan nuevas funciones, o el diseño de la interfaz no

quede estrictamente igual definido que en el storyboard.

Como comenté en el apartado anterior estas son las partes de la vista

primera del prototipo de la aplicación, en la versión final habrá ventanas que

sean distintas

Como herramienta he usado papel y lapiz para conseguir hacer una

interfaz rápida de modificar y de adaptarse a los nuevos cambios.



Escena 1:

Página principal de la aplicación, proceso de autenticación del alumno.



Escena 2:

Posible caso de error a partir de la escena 1, si el periodo de asignación está

cerrado o aún no está abierto.



Escena 3:

Posible caso de error a partir de la escena 1, si el usuario que ha intentado

acceder al sistema, no está registrado en la base de datos del servidor.



Escena 4:

Siguiente paso de la Escena 1, entrada de lleno en la aplicación, visualización

del listado de TFG disponibles, ordenados por temática o tutor.

También podremos añadir o borrar TFG a nuestra tabla.



Escena 5:

Dentro de la escena principal hay un botón de ayuda, que si lo pulsas te explica

brevemente el funcionamiento del programa.



Escena 6:

Opción dentro de la escena principal que permite, salir sin guardar



Escena 7:

Opción en la pantalla principal que permite guardar los cambios



Escena 8:

El mensaje de alerta a continuación de la escena 7, de que los datos se han

guardado correctamente.



6. IMPLEMENTACIÓN En los anteriores apartados hemos explicado el problema y su respectiva

solución, por lo tanto ahora vamos a explicar cómo se desarrolla esa solución.

En este apartado describirá como se ha construido cada una de las

etapas de la solución

Descripción de la arquitectura de una aplicación android con PHP.

Esta es la arquitectura de nuestra aplicación con el apoyo de nuestro

servidor usando PHP y base de datos MySql

El funcionamiento es el siguiente: al iniciar la aplicación el usuario hace

login en la aplicación, estos datos serán enviados al servidor a través de un

Post por PHP y este consultara si estos datos existen o no, por lo tanto si

devuelve un Usuario existe en formato Json, entrará en la aplicación, si no

existe no.



Nuestro servidor nos proporciona un servicio apache donde tenemos

guardados los archivos PHP que conectan con la base de datos, y son

llamados a través de una url la aplicación android, y estos nos devolverán

información a través de parámetros Get o Desde la aplicación enviaremos

parámetros Post, que estos parámetros dentro de los archivos PHP harán la

conexión y consulta pertinente a la base de datos MYSql que esta almacenada

en nuestro servidor.

Como hemos explicado en el login toda la información que nos envie

nuestra aplicación estará en el lenguaje Json y este será leído a través de la

aplicación y transformado a un objeto

Después del login y una vez dentro de la aplicación, pediremos a la base

de datos qué tutores hay disponibles para una titulación y elegir o eliminar un

determinado tutor de mi lista de prioridades.



Y por último podremos consultar en la página de inicio distinta

información e instrucciones de la aplicación.

Ejemplo de parámetros GET aplicación y servidor

Dentro del activityGestionActivity estamos pidiendo los TFGs de un

determinado tutor desde la aplicación.

try { ConnectivityManagerconnMgr = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfonetworkInfo = connMgr.getActiveNetworkInfo(); if(networkInfo != null&&networkInfo.isConnected()) { new JsonTask2().execute(new URL("http://manuamate.hol.es/tfgtutor.php?dato="+tfg.getCodigoTutor())); } else{ Toast.makeText(this, "Error de conexion", Toast.LENGTH_LONG).show(); } } catch (MalformedURLException e) { e.printStackTrace(); }

Y en el servidor en el archivo TFGtutor.php devolvemos los datos que nos ha

pedido la aplicación y son devueltos por Json, después la aplicación con un

JsonReaderleera y los creará con la clase que explicamos en el diagrama de

clases de diseño GsonReader



Ejemplo de Post entre aplicación y servidor

Enviamos al servidor los datos del usuario logeado

Stringusername = (String)arg0[0];

Stringpassword = (String)arg0[1];

String link="http://manuamate.hol.es/loginfull2.php";

String data = URLEncoder.encode("username", "UTF-8") + "=" +

URLEncoder.encode(username, "UTF-8");

data += "&" + URLEncoder.encode("password", "UTF-8") + "=" +

URLEncoder.encode(password, "UTF-8");

URL url = new URL(link);

URLConnectionconn = url.openConnection();

conn.setDoOutput(true);

OutputStreamWriterwr = new OutputStreamWriter(conn.getOutputStream());

wr.write( data );

wr.flush();

El servidor recoge los parámetros Post y hace la consulta



Ejemplo de Lectura del Json del servidor en la aplicacion

// Parsear el flujo con formato JSON

InputStream in = new BufferedInputStream(con.getInputStream());

GsonTFGParserparser = new GsonTFGParser();

TFGs = parser.leerFlujoJson(in);

// Gson para la lista de tutores del mainactivity

publicList<TFG>leerFlujoJson(InputStream in) throwsIOException {

// Nueva instancia de la clase Gson

Gsongson = new Gson();

JsonReaderreader = new JsonReader(new InputStreamReader(in, "UTF-8"));

List<TFG>TFGs = new ArrayList<>();

// Iniciar el array

reader.beginArray();

while(reader.hasNext()) {

// Lectura de objetos

TFGTFGg = gson.fromJson(reader, TFG.class);

TFGs.add(TFGg);

}

reader.endArray();

reader.close();

returnTFGs;

}



6.1 Herramientas Como ya se ha indicado, tenemos por un lado la aplicación con las

herramientas propias de ella para su desarrollo, y además, para lograr la

funcionalidad de su servicio también hemos necesitado de otras herramientas

para su servidor.

6.1.1 Herramientas y lenguajes lado del servidor

Mi base de datos se encuentra localizada en un servidor llamado hostinger.

Servidor: http://www.hostinger.es/

Dominio: http://manuamate.hol.es/

6.1.2 Caracteristicas Hostinger

Hostinger es un proveedor de alojamiento web que nos facilita un espacio

donde poder publicar sitios web, además cuentas con la opción de crear bases

de datos MYSQL para poder soportar tus archivos PHP.



6.1.3 JSON8

Es un formato ligero de intercambio de datos, Está basado en un

subconjunto del Lenguaje de Programación JavaScript, JSON está constituido

por dos estructuras:

8 Informacion obtenidad de: http://www.json.org/json-es.html

Página principal Hostinger

http://www.json.org/json-es.html



x Una colección de pares de nombre/valor. En varios lenguajes esto es

conocido como un objeto, registro, estructura, diccionario, tabla hash,

lista de claves o un vector/array asociativo.

x Una lista ordenada de valores. En la mayoría de los lenguajes, esto se

implementa como vectores, listas o secuencias.

Uso de Json en mi proyecto

Lo hemos utilizado para el intercambio de información entre el servidor y

la aplicación.

6.1.4 MySQL9

MySQL es un sistema gestor de bases de datos relacional muy conocido

y ampliamente usado por su simplicidad y notable rendimiento.

Aunque carece de algunas características avanzadas disponibles en

otros SGBD, es una opción atractiva tanto para aplicaciones comerciales, como

de entretenimiento precisamente por su facilidad de uso y tiempo reducido de

puesta en marcha

La base de datos del servidor es Mysql

6.1.5 SQL (StructuredQueryLanguage)10

Es un lenguaje de programación estándar e interactiva para la obtención

de información desde una base de datos y para actualizarla.

Las consultas toman la forma de un lenguaje de comandos que permite

seleccionar, insertar, actualizar, averiguar la ubicación de los datos, y más.

9 Información obtenidad de: http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/bases-de-datos/P06_M2109_02151.pdf 10 Información obtenidad de: http://searchdatacenter.techtarget.com/es/definicion/SQL-o-

lenguaje-de-consultas-estructuradas

http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/bases-de-datos/P06_M2109_02151.pdf

http://ocw.uoc.edu/computer-science-technology-and-multimedia/bases-de-datos/bases-de-datos/P06_M2109_02151.pdf

http://searchdatacenter.techtarget.com/es/definicion/SQL-o-lenguaje-de-consultas-estructuradas

http://searchdatacenter.techtarget.com/es/definicion/SQL-o-lenguaje-de-consultas-estructuradas



Aquí tenemos un ejemplo de consulta SQL que hemos usado dentro de

un archivo .php para devolver todos los tutores de la titulación que pertenece el

usuario logeado, y su respectiva prioridad que tenga el usuario a ese tutor:

$sql = "SELECT DISTINCT CodigoTutor, Prioridad, NombreTutor, ApellidosTutor FROM

(selectCodigoTutor, Prioridad, (SelectNombreTutorfrom tutor

wherealumno_tutor.CodigoTutor=tutor.CodigoTutor) NombreTutor

,(SelectApellidosTutorfrom tutor wherealumno_tutor.CodigoTutor=tutor.CodigoTutor)

ApellidosTutorfromalumno_tutorwhere usuario='$usuario'

UNION

selectCodigoTutor, 0 as Prioridad

,NombreTutor,ApellidosTutorfrom tutor whereCodigoDepartamento in

(selectCodigoDepartamentofromtitulacion_departamento WHERE

CodigoTitulacion='$dato') ) as consulta groupbyCodigoTutor";



6.1.6 PHP

PHP (acrónimo recursivo de PHP: HypertextPreprocessor) es un

lenguaje de código abierto muy popular especialmente adecuado para el

desarrollo web

La extensión Objetos de Datos de PHP (PDO) define una interfaz ligera

para poder acceder a bases de datos en PHP.

A través de los archivos de PHP podemos hacer consultas o

actualizaciones a la base de datos. Desde la aplicación usando la url entraran

con parámetros GET o POST, y estos recibirán los datos deseados de la base

de datos.

Tablas de la base de datos



Archivos php



Archivo TFGs.php del servidor que devuelve los tutores disponibles a un

alumno con su prioridad, vemos como tenemos una conexión a la base de

datos a través de pdo y devolvemos un archivo Json, asimilable para nuestra

app

6.1.7 Decisión de alojar la base de datos en dicho servidor

Pensé en esta opción porque te permite tener la base de datos

actualizada en la nube, sin necesidad de tenerla en un archivo local, lo cual

tienes la ventaja de acceder a ella desde cualquier sitio.

Otra gran ventaja de usar este servicio, es que me permite tener los

archivos PHP que interactúan con la base de datos almacenados también en el

servidor y acceder a ellos desde el servicio FTP de hostinger.

Estos PHP, a través de peticiones REST a con parámetros GET y POST de la

app se comunica con la base de datos y le devuelve o envía al PHP la

información que quiere recibir.

Por último los archivos PHP serán los encargados de hacer las consultas

necesarias a la base de datos y devolver los datos a través del lenguaje JSON

el objeto o los objetos deseados



6.2 Herramientas y lenguajes para la aplicación android 6.2.1 Git y GitHub

Android studio te permite interactuar con ambas herramientas.

El control de versiones es una de las tareas fundamentales para la

administración de un proyecto de desarrollo de software. Surge de la necesidad

de mantener y llevar control del código que vamos desarrollando, conservando

sus distintos estados.

Estas herramientas me aportan están ventajas:

x Comparar el código de un archivo, para ver las diferencias entre las

distintas versiones

x Posibilidad de restaurar versiones anteriores

x Fusionar cambios entre distintas versiones

x Trabajar con distintas ramas de un proyecto

El uso de esta herramienta en mi aplicación surgió de mi propia necesidad

de volver a cambios anteriores, si lo que estaba desarrollando no iba por buen

cauce siempre podría volver atrás.

En proyectos de mucho código es siempre conveniente, porque puedes

tocar bastantes cosas de las que te puedes arrepentir, y sea imposible volver a

una versión anterior del código sin estas grandes herramientas.

Gites un sistema de control de versiones distribuido

Githubes un servicio para alojamiento de repositorios de software

gestionados por el sistema de control de versiones Git.

Además al usar Github me permite tener mi proyecto en internet. Y

podré transportarlo a cualquier ordenador rápidamente desde el punto en que

me quede desarrollando la última vez.



Ilustración de Gitextensions, es un programita con una interfaz visual que te

permite gestionar un repositorio más fácil que con otras versiones git



6.2.2 Android Studio11

Android Studio es un nuevo entorno de desarrollo integrado para el

sistema operativo Android lanzado por Google, diseñado para ofrecer nuevas

herramientas para el desarrollo de aplicaciones y alternativa al entorno Eclipse,

hasta ahora el IDE más utilizado.

Además permite ver los cambios que realizamos en nuestra aplicación

en tiempo real, pudiendo además comprobar cómo se visualiza en diferentes

dispositivos Android con distintas configuraciones y resoluciones de forma

simultánea.

Que nos ofrece

- Un entorno de desarrollo claro y robusto.

- Facilidad para testear el funcionamiento en otros tipos de dispositivos.

- Asistentes y plantillas para los elementos comunes de programación en

Android.

- Un completo editor con muchas herramientas extra para agilizar el desarrollo

de nuestras aplicaciones.

Toda la parte

de la

aplicación se

ha

desarrollado

en este

entorno.

6.2.3 Java

11 Informacion obtenidad de: http://android-studio.uptodown.com/windows

http://android-studio.uptodown.com/windows



El Desarrollo de Programas para Android se hace habitualmente con el

lenguaje de programación similar a Java.

Java es un lenguaje orientado a objetos de propósito general. Se puede

utilizar para construir cualquier tipo de proyecto.

Su sintaxis es muy parecida a la de C y C++

6.3 Construcción de la interfaz y menús de la aplicación La implementación de la interfaz de nuestra aplicación va a ser uno de

los pasos del desarrollo más importantes de la aplicación.

Hasta ahora hemos estado presentando el problema y la solución de

este, pero sin embargo para el usuario la parte más importante es la visual, con

la que va a interactuar y con la que beneficiará los servicios del sistema, de

nada sirve tener una gran solución para un problema, pero que no sea intuitivo

ni tenga usabilidad para el usuario final.

La interfaz determinará si un usuario disfrutará de la aplicación o, sin

embargo, este la rechace en menos de un minuto, por ese motivo decidí

centrarme por empezar con la construcción de la interfaz.

Podremos tener un sistema muy eficiente y con la última tecnología pero si el

usuario no es capaz de utilizarlo o poco amigable el sistema acaba siendo inútil

para el usuario.

Es por eso que debería de ser más importante, de lo que es, para los

ingenieros del software.

6.3.1 Estilo de la interfaz

Material Design es un concepto, una filosofía, unas pautas enfocadas al

diseño utilizado en Android,

Esta basado en objetos materiales. Piezas colocadas en un espacio

(lugar) y con un tiempo (movimiento) determinado.

Es un diseño donde la profundidad, las superficies, los bordes, las

sombras y los colores juegan un papel principal.



Material Design quiere guiarse por las leyes de la física, donde las

animaciones sean lógicas, los objetos se superpongan pero no puedan

atravesarse el uno al otro y demás.

Un ejemplo de la aplicación de Gmail.

6.3.2 Action bar superior

Siguiendo las pautas de material design he creado un action bar superior

donde en cada pantalla indique el nombre de la acción de la pantalla, y además

en la pantalla principal pueda seleccionar el menú principal. Este menú solo

esta implementado en el mainactivity la actividad principal

ActionBar superior de gmail

NavigationDrawerGmail



6.3.3 Menú lateral

Es un componente llamado DrawerLayout ,en el que te llevará a cada

una de las secciones de la aplicación, este estará asociado a la actionbar

anterior y se podrá desplegar pulsando el botón de la esquina izquierda, o

simplemente deslizando el dedo de la zona izquieda de la pantalla del

mainactivity



7. MANUAL DE USUARIO Este manual de usuario permitirá conocer al usuario cada una de las distintas

pantallas y su funcionalidad. Para así hacer un buen uso de la aplicación.

Esta es la lista completa de todos los usuarios disponibles para acceder a la

aplicación:

La contraseñapor defecto de todos es: contrasena

Con estos datos podemos hacer un uso correcto del login de la aplicación, si

ponemos un usuario o contraseña distintos de los mencionados, la aplicación

no será iniciada.

Usuarios de magisterio Usuarios de Psicología



Login

Página principal de la aplicación, el usuario

tendrá a su disposición los campos de email y

contraseña para introducirlos y acceder a la

aplicación mediante el login.

Como he mencionado en el principio del apartado,

podremos hacer login con cualquiera de las cuentas

mencionadas.

Página principal, donde el Usuario según la

titulación que pertenezca tendrá a su disposición la

lista de sus tutores disponibles, para ver su oferta de

TFGs y poder elegirlo o eliminarlo

Pulsamos el tutor sobre él, para ver su oferta de TFG

Página MainActivity

Página Principal Login



Una vez que elegimos un tutor de la

lista de la pantalla anterior, se nos abrirá su

oferta, y aquí podremos, Elegir un tutor o

Borrarlo

Además se abrirá un cuadro de diálogo,

al pulsar en los botones de elegir o eliminar

tutor, por si estás seguro que deseas eliminar

o elegir el tutor

Pantalla cuadro de diálogo Elección tutor Pantalla cuadro de diálogo

borrado

Pantalla GestionActivity



Una vez que elegimos a un tutor vuelve

automáticamente a la pantalla anterior y te pone el

número de prioridad, en este caso es el primer tutor

que hemos elegido, el próximo será 2 y asi

sucesivamente.

Además mostrará un mensajito de que has

elegido al tutor

Pantalla Toast tutor elegido



Sin embargo si el tutor ha sido eliminado

ya no aparecerá la prioridad anterior, y mostrará

un mensaje de que el tutor se ha eliminado de tu

prioridad.

Este es el menú principal que permite ir a

las siguientes secciones de la aplicación.

Se podrá desplegar desde la pantalla

principal .A esta pantalla se accede desde el menú

en la sección Inicio

MenuDrawerLayout

Pantalla Toast prioridad tutor eliminado



Esta es la pantalla de explicativa de

para qué es y para qué sirve la aplicación.

Se podrá ampliar con información como

plazos

En la pantalla principal al pulsar al

botón hacia atrás mostrará un cuadro de

confirmación si deseas salir de la aplicación

Pantalla explicativa del funcionamiento

Pantalla confirmación salir de la aplicación



8. MANUAL DE INSTALACIÓN

Voy a dar los pasos básicos para la instalación de mi aplicación en

vuestros dispositivos móviles o Tablet.

Tengo una cuenta creada en Google Play Developer, y he publicado la

primera versión de mi App en el playstore, por lo que ya podréis descargárosla

desde cualquier dispositivo móvil o Tablet compatible con android.

El título de la aplicación es:UjaFachumTFG

Como expliquéen el apartado de manual de usuario existen dos tipos de

usuarios para hacer login, uno de la titulación de Magisterio y otro con la

titulación de Psicología.

Play StoreUjaFachumTFG



Play StoreUjaFachumTFG



9. PRUEBAS

El objetivo de este apartado es demostrar que el software cumple con

los requisitos a través de pruebas de software y encontrar situaciones donde el

comportamiento del software sea incorrecto, indeseable o no esté de acuerdo

con su especificación.

Deberá de haber una prueba por cada requisito, esto significa que tiene

que haber pruebas para todas las características del sistema.

9.1 Pruebas genéricas para todo producto Software 9.1.1 Técnicas de caja negra o de comportamiento12

Estas pruebas permiten obtener un conjunto de condiciones de entrada

que ejerciten completamente todos los requisitos funcionales de un programa.

Concentrándose en los requisitos funcionales del sistema y ejercitándolos.

Existen varias técnicas de pruebas, pero hemos considerado esta una

buena alternativa, ya que podremos comprobar todos los requisitos del

sistema.

Para ver que los requisitos se comprueban de una forma organizada

vamos a crear una tabla que nos muestre todas las pruebas.

Número Descripción Resultado

Login Usuario

Prueba 1

El

sistemadebecomprobarque

el

usuariologeadoescorrecto

y esta en la base de datos

OK

Gestión de los tutores

12 Información obtenida de: http://www.ecured.cu/Pruebas_de_caja_negra

http://www.ecured.cu/Pruebas_de_caja_negra



Prueba 2

El usuariopuedepulsar

cualquier tutor de los que

se encuentra en

sulistaseleccionada

OK

Prueba 3

El usuariono puedeelegir

un tutor

queyaestuvieraelegido

OK

Prueba 4

El usuario no puedeborrar

a la prioridad de un tutor,

quetodavia no estaelegido

OK

Prueba 5 Elegir un tutor con

mensaje de confirmacion OK

Prueba 6

Borrar un tutor de tulista de

prioridades con mensaje

de confirmacion

OK

Menu y Salir

Prueba 7

Si le

damosaccidentalmente al

boton de atrás en la

pantalla principal,

preguntasideseassalir, si

solo pulsasquesi, saldrá

OK

Prueba 8

Entrar en la pantalla de

instrucciones o de

información

OK

Tabla

Casos de prueba



Prueba 1El sistema debe comprobar que el usuario logeado es correcto y está

en la base de datos.

Caso de prueba: Accedemos a la pantalla inicial de la aplicación, y en el

usuario y contraseña ponemos cualquier dato y contraseña que no sea de un

usuario existente.

Por Ejemplo:

Usuario: [email protected]

Contrasena: contrasena

Resultado esperado:

El sistema no deja acceder a usuarios que no pertenezca a los

mencionados anteriormente de la base de datos.

Evidencia:

Prueba 2El usuario puede pulsar cualquier

tutor de los que se encuentra en su lista

seleccionada

Resultado esperado: se puede pulsar cualquier tutor de los disponibles para

ver su oferta de TFG.

Evidencia:

mailto:[email protected]



Prueba 3El usuario no puede elegir un tutor que ya estuviera elegido.

Resultado esperado:

El usuario no deja elegir un tutor que este previamente elegido,

directamente no sale el botón para elegirlo. Y si no está elegido se pueden

elegir

cualquiera.

Evidencia:



En este claro ejemplo la tutora Ana García León ya estaba elegida y el

botón para elegir está oculto porque esta elección ya existe.

Prueba 4

El usuario no puede borrar a la prioridad de un tutor, que todavía no está

elegido.

Resultado esperado:

El usuario no puede borrar un tutor si todavía no está elegido, pero si

está elegido se puede borrar cualquier tutor.

Evidencia:



Como veis es imposible borrar un tutor como Nieves que no tiene ninguna

prioridad.

Prueba 5Elegir un tutor con mensaje de confirmación

Resultado esperado:

Antes de borrar el tutor de tu lista de prioridades preguntar que si estás seguro.

Y solo si dices que si este desaparecerá.

Evidencia:



Prueba 6 Borrar un tutor de tu lista de prioridades con mensaje de

confirmación.

Resultado esperado: Antes de elegir el tutor, que muestre un mensaje de

confirmación y solo si hemos aceptado se elegirá el tutor.

Evidencia:



Prueba 7Si le damos accidentalmente al botón de atrás en la pantalla principal,

pregunta si deseas salir, si solo pulsas que sí, saldrá

Resultado esperado:

La aplicación no podrá salir del programa si le damos al boton de atrás

accidentalmente.

Evidencia:



Prueba 8Entrar en la pantalla de instrucciones o de información

Resultado esperado:

Vamos al menú principal de la pantalla principal, pulsando el botón de la barra

de herramientas superior y pulsamos la pantalla inicio y se abre la pantalla

informativa.

Evidencia:



9.2 Pruebas específicas para android Aparte de las pruebas descritas en el apartado anterior, existen otro tipo

de pruebas a tener en cuenta a la hora de desarrollar una aplicación android.

Varios de los explicados a continuación coinciden con los requisitos no

funcionales descritos en el capítulo de análisis

Puntos que hay que probar en la aplicación:

9.2.1 Interfaz de usuario

La interfaz es uno de los detalles más importantes a la hora de

desarrollar la aplicación, como ya explicamos anteriormente.

Se ha tenido en cuenta que todos los elementos como botones y listas tengan

un comportamiento adecuado cuando se les pulsa, el menú lateral se abra

cuando desplazamos el dedo por el lateral izquierdo o pulsamos el botón de la

barra de herramientas superior.

Al girar la pantalla, todo siga en su sitio y no se desplieguen

desordenados los objetos.

La navegación entre las distintas pantallas es adecuada.

También se ha comprobado el scrolling de algunas pantallas como las

de las listas.

Por lo tanto la interfaz de esta aplicación está en consonancia, en orden

y vistosa en intuitiva para el usuario.

9.2.2 Usabilidad

Para comprobar la usabilidad de la aplicación, la mejor manera es dejar

que la gente la pruebe, como mis amigos o incluso mi tutor, todos ellos me han

ayudado a ir haciendo modificaciones, como por ejemplo, en vez de como

pensé al principio de ir eligiendo tutores de una tabla, que en una lista

desplegable salieran todos los tutores y una vez mostrados, se le pulse y se

vea su oferta de TFG.



Finalmente he desarrollado una aplicación muy usable para cualquier

persona ajena a la informática y a la facultad de humanidades y ciencias de la

educación podría usarla sin ninguna dificultad.

9.2.3 Rendimiento / tiempo de respuesta cortos:

Con respecto a la rapidez de la aplicación va a un ritmo considerable, las

conexiones a internet, como el login se hacen en un tiempo razonable, y la

carga de Datos como TFG o tutores, van bastante bien y con tiempos de

respuesta cortos

9.2.4 Seguridad:

Como medida de seguridad en la contraseña de los usuarios al hacer

login, se están guardando en la base de datos el campo contraseña en el

formato MD5, esto se utiliza como medida para los intrusos que quieran captar

contraseñas de la base de datos.



10 CONCLUSIONES 10.1 Valoración personal

Llegado a este punto concluyo con todas las fases del proceso de

ingeniería del software del proyecto, ya que se han cumplido con todos

los objetivos que mi tutor D. Víctor Manuel Rivas Santos me propuso

para realizar este TFG.

Ha sido mi primera experiencia como desarrollador de aplicaciones

móviles, he aprendido bastante, tanto con el desarrollo de la aplicación, y

del servidor, por lo que creo que ha sido un TFG muy enriquecedor para

mi aprendizaje y me ha aportado ser más autónomo a la hora de resolver

ciertos problemas de programación, depurando la aplicación paso a

paso, en busca de los errores, leerlos, comprenderlos, investigar en foros

de internet, o cualquier sitio web, incluso preguntando amigos con cierta

experiencia en este tipo de aplicaciones.Así que aunque haya sido mi

primera experiencia en proyectos de este ámbito, creo que al final estoy

muy contento y ha llegado a resultar como una experiencia más que

satisfactoria.

Para mi punto de vista es un proyecto completo ya que se usan

bastantes herramientas y tecnologías. Algunas de estas

herramientas/tecnologías se han usado en las asignaturas de la carrera,

pero en mi opinión es que bajo este tipo de proyectos verdaderamente es

cuando te das cuenta que ventajas te puede aportar una

herramienta/tecnología u otra.

Me motivo bastante que fuera una aplicación en la que se le

pudiera dar uso en la realidad, ya que como comentamos anteriormente,

esto es solo un prototipo, pero a raíz de esta base, se puede crecer y

completar hasta que sea realmente una aplicación en la que estos



alumnos de la FHCCE puedan darle uso facilitándole su proceso de

gestión de selección de TFG.

10.2 Mejoras futuras Como posible mejora en la aplicación sería añadir una base de datos en

local, para que esta hiciera de almacenamiento previo y después se carguen

estos datos a la base de datos externa.

Ventajas de la mejora futura:

Actualmente cada vez que cargamos la página de los tutores, o la de sus

TFGs y elegimos o borramos un tutor, estamos haciendo peticiones

continuamente al servidor, por lo que si tenemos una base de datos en local

desde la aplicación y se baja de una vez toda la información nos evitaremos

esa carga excesiva de datos con el servidor, por lo tanto el rendimiento y el

tiempo de respuesta será más eficiente.

Además si el usuario se queda sin conexión en algún momento, no

podrá ver nada, si tenemos esta base de datos intermedia los datos estarán

disponibles, y cuando modifiquemos algo, se preparará cuando haya una

próxima conexión.



11. PRESUPUESTO El trabajo lo van a realizar un analista y un programador.

Tareas como Entrevistas, comprensión del dominio del problema,

análisis y diseño serán llevadas a cabo por el analista, obviamente la parte que

queda que es la de codificación será el programador que la lleve.

Suponiendo que cada día de trabajo son 8 horas de lunes a viernes.

Vamos a calcular las horas estándar que cobra un analista y un programador y

las multiplicaremos por sus horas totales que han trabajado.

Trabajador Actividad Horas

Analista

Entrevistas 2 X 8 = 16

Comprensión del dominio del problema 4 X 8 = 32

Análisis 20 X 8 = 160

Diseño 20 X 8 =160

Pruebas y evaluación 6 X 8 = 48

416 horas

totales del

analista

Las 16 horas de las entrevistas es el total de tiempo que le vamos a

dedicar incluyendo la extracción de información a los entrevistados más la

documentación de la información del entrevistador que saca este de la

entrevista.

La comprensión del dominio del problema ayudará al analista a dar una

clara visión de las necesidades para el correcto funcionamiento y a organizar

todo lo necesario para comenzar con el análisis.

Según el sueldo de un analista y precio hora le sale por unos 20 euros la

hora dedicada

Con lo cual 416 horas totales X 20 Euros precio/hora = 8320 euros



Trabajador Actividad Horas

Programador Implementación 40 X 8 = 320

320 horas totales del programador

Según el sueldo de un programador y precio hora la media sale por unos

15 euros la hora dedicada

Con lo cual 320 horas totales X 15 Euros precio/hora = 4800 Euros

Con lo cual el precio final de este proyecto será

Trabajador Total Analista 8320 Euros

Programador 4800 Euros

8320+4800 =13120

Pero como estamos trabajando a cargo de una empresa la cual deberá

de sacar un beneficio del 30 % de los costes en cada proyecto.

13120 + 30 % = 13120 + 3936= 17056 Euros.

Por lo tanto, el coste total del proyecto sería 17056 euros



ANEXO A: ENTREVISTAS



ENTREVISTAS

Entrevista con la comisión de Trabajo Fin de Grado

1º ¿Por qué queréis cambiar vuestro sistema actual de la elección de TFG para

el alumnado?

Nuestro sistema actual de asignación de TFG resulta muy tedioso a la

hora de asignarlo al alumno, ya que el alumno tendrá que rellenar una solicitud

con unos 30 huecos, en los que tendrá que elegir tutores encargados de unas

temáticas, según una prioridad.

Hemos decidido poner 30 huecos porque anteriormente poníamos menos, y se

han dado casos en los que ha habido alumnos sin TFG asignado.

Tenemos que trabajar con dos variables importantes, primero el

expediente académico, es decir alumnos que tengan nota media más alta

tienen prioridad para elegir, y por último la segunda variable es la prioridad que

el alumno ha barajado sus opciones.

Dado a la gran cantidad de alumnos en cada grado, y los 9 grados

actuales que tiene la facultad de humanidades y ciencias de la educación, es

un trabajo excesivo trabajar con estas dos variables.

Por esta razón nos gustaría que se llevara a cabo un proceso de

informatización de este método, a través de una aplicación, más a mano del

alumnado en el que pudiera elegir en un periquete sus opciones y el sistema

enviarnos a nosotros la solución final de cuál ha sido asignado a este.

2º ¿Cuál es vuestro trabajo actual como comité de trabajo de Fin de Grado en

este proceso?

Una vez que los alumnos han sido matriculados en la asignatura de

docencia virtual llamada TFG, vemos la cantidad de alumnos que hay inscritos

en la oferta.



1º Después de esto comunicamos a los departamentos

- El número final de matriculados/as de TFG, indicando el número de

líneas que han de enviar en cada Grado

- Los TFG específicos entregados por el alumnado por docencia virtual

2º Los departamentos remiten a la Comisión de trabajo fin de grado (CTFG) la

lista de líneas de TFG ofertados (incluidos los TFG específicos)

3º La CTFG publica el listado de líneas de TFG definitivas

4º Los/Las estudiantes solicitan los TFG generales por orden de prioridad, a

través de DOCENCIA VIRTUAL

5º La CTFG publica la adjudicación provisional



Entrevista con alumna de la Facultad de Humanidades y CC. Educación

Elena Torres Castro alumna de Grado en Educación Infantil

1º ¿Dónde puedes localizar la información referente al TFG de tu facultad?

Desde la página web de la universidad de Jaén Æ CONÓCENOS Æ

CENTROS Æ FACULTAD DE HUMANIDADES Y CC. EDUCACION Æ TFG

Página principal Facultad de humanidades



Página TFG facultad de humanidades y ciencias de la educación



2º ¿Cuáles son los procesos que hay que tener en cuenta como alumno para

adquirir un TFG?

MATRICULA EN DOCENCIA VIRTUAL DE LA ASIGNATURAÆ TFG

1º Primero y lo más importante ver en el calendario las próximas convocatorias

y centrarnos en una de ellas.

2º Una vez sabido en nuestro calendario en qué momento lo queremos

presentar, tendremos que matricularnos en una asignatura específica dentro de

docencia virtual, en nuestro perfil y buscar una asignatura llamada TFG.

3º Una vez matriculados pasamos a rellenar la solicitud en el anexo IIb que

aparece en nuestro desglose de información de TFG

Importante no se Elige TFG como es lo más rápido o lógico que

podamos pensar,

Esta facultad sube un listado de profesores y con su respectiva línea o

temática de la que se encargue dicho profesor. Para eso nos vamos al listado

de oferta de TFG de nuestro curso correspondiente



Listado de líneas de trabajo

Ejemplo de Oferta de TFG´s

Los alumnos podrán elegir con prioridad en vista del tutor o temática

favorita de su TFG.



Una vez decididas sus prioridades el alumno, rellenara la siguiente

solicitud, la escaneará y enviará por docencia virtual.

Solicitud de asignación de trabajo de fin de grado

4º Una vez ya seleccionados el alumno solo queda esperar, que salga la

publicación de la adjudicación provisional de los tutores, y una vez adjudicados,

con el tutor que nos ha tocado hablaremos del tema en concreto que tengamos

que hacer.

3º ¿Crees que sería un interesante proyecto la creación de una aplicación para

informatizar el proceso de elección de TFG?

Si porque agilizaría mucho más el proceso, y desde la misma aplicación

podemos ver las distintas líneas / temáticas disponible y tutor, y poner

directamente nuestra elección prioritaria y que quedasen mandadas a la

facultad.



Esta aplicación concentraría todo lo necesario para este proceso, y

estaría mucho más claro para el alumnado elegir el TFG.



BIBLIOGRAFÍA

SOMMERVILLE, I. (2011). INGENIERÍA DEL SOFTWARE. MÉXICO: PEARSON.

Foro de resolución de problemas: http://stackoverflow.com/

Curso de programación Android: https://www.udacity.com/course/developing-android-apps--ud853

Tutorial de programación en Android: http://www.sgoliver.net/blog/curso-de-programacion-android/indice-de-contenidos/

http://stackoverflow.com/

https://www.udacity.com/course/developing-android-apps--ud853

https://www.udacity.com/course/developing-android-apps--ud853

http://www.sgoliver.net/blog/curso-de-programacion-android/indice-de-contenidos/

http://www.sgoliver.net/blog/curso-de-programacion-android/indice-de-contenidos/

trabajo fin de grado fg-h app para...

Documents