Control de paràmetres del generador d'informació dels estudis de la UIB

T reba ll F ina l de G rau

GRAU D’ENGINYERIA INFORMÀTICA

Control de paràmetres del generador d’informació dels estudis de la UIB

FERNANDO TORRADO NAVARRO

Tutor

Pedro Antonio Palmer Rodríguez

Supervisor Oficina Web

Escola Politècnica Superior

Universitat de les Illes Balears

A l’OficinaWeb per tota l’ajuda i confiança que m’han donat per al desenvolupament d’aquest projecte.

Al meu tutor Pedro Antonio Palmer Rodríguez per guiar-me en la realització d’aquest projecte.

S ^UMARI

Sumari iii

Índex de figures v

Acrònims vii

Resum ix

1 Introducció 1

1.1 Motivació . . . 1

1.2 Objectius . . . 2

1.3 Estructura del document . . . 2

2 Plantejament del problema 3 2.1 Estat actual . . . 3

2.2 Solució proposada. . . 5

2.3 Marc tecnològic . . . 5

3 Anàlisi 9 3.1 Anàlisi de requisits . . . 9

3.1.1 Requisits d’usuari . . . 9

3.1.2 Requisits de sistema . . . 10

3.2 Planificació . . . 11

4 Desenvolupament de l’aplicació 13 4.1 Model client-servidor . . . 14

4.2 Disseny del client . . . 14

4.2.1 Disseny de la interfície . . . 14

4.2.2 Disseny de la implementació. . . 16

4.3 Disseny del servidor. . . 17

4.3.1 Disseny de l’estructura . . . 18

4.3.2 Model de les dades . . . 20

5 Proves i validació 23 5.1 Comprovació dels requisits . . . 23

6 Conclusions 31 6.1 Conclusions . . . 31

iv SUMARI

6.2 Visió de futur . . . 32

Bibliografia 33

Í NDEX DE FIGURES

2.1 Plana web dels estudis de la UIB. . . 3

2.2 Fitxer estàtic XML d’una generació . . . 4

2.3 Plana web d’un dels estudis de la UIB. . . 5

4.1 Model client-servidor . . . 13

4.2 Finestra d’inici . . . 14

4.3 Afegir una nova generació . . . 15

4.4 Generació . . . 15

4.5 Exemple d’esborrar flag . . . 16

4.6 Forma general d’un Rest webservice . . . 18

4.7 Control de la concurrencia de forma optimista . . . 19

4.8 Model de les dades. . . 20

5.1 Plana principal de l’aplicació. . . 23

5.2 Plana d’una generació. . . 24

5.3 Resposta XML d’una generació . . . 24

5.4 Validació de formularis . . . 24

5.5 Feedback a l’usuari . . . 25

5.6 Sistema de seguretat Single Sign-On (SSO) de la institució . . . 25

5.7 Visualització de l’aplicació a un iPad . . . 26

5.8 Actualitzacions dels paràmetres de forma separada . . . 27

5.9 Actualització del camp any.. . . 27

5.10 Error a l’hora d’actualitzar el camp mode . . . 27

5.11 Error 400. . . 28

5.12 Crear la generació de doctorat . . . 28

5.13 Crear la generació de doctorat . . . 29

5.14 Crear la generació de doctorat . . . 29

A ^CRÒNIMS

HTML HyperText Markup Language CSS Cascading Style Sheets

AJAX Asynchronous JavaScript And XML

JQUERY Biblioteca multiplataforma de JavaScript JS JavaScript

API Application Programming Interface REST REpresentational State Transfer XML eXtensible Markup Language JSP JavaServer Pages

JPA Java Persistence API

ORM Object Relational Mapping DOM Document Object Model

HTTP Protocol de transferència d’hipertext SSO Single Sign-On

TFG Traball Final de Grau

UIB Universitat de les Illes Balears OW Oficina Web

CMS Content Management System URL Uniform Resource Locator W3C World Wide Web Consortium id Identificador

eTag Entity tag

IDE Integrated Development Environment POJO Plain Old Java Object

R ^ESUM

El propòsit del present Traball Final de Grau (TFG) és la realització d’una aplicació per a l’Oficina Web (OW) de la Universitat de les Illes Balears (UIB) per al control de paràmetres del generador d’informació dels estudis de laUIB. L’aplicació facilitarà la feina a l’hora d’actualitzar dits paràmetres.

Abans de desenvolupar l’aplicació, el procés per actualitzar aquests paràmetres pas- sava per definir un arxiu estàtic definit en format eXtensible Markup Language (XML), que era pujat al servidor. Aquest procés s’havia de repetir sempre que hi havia algun canvi en els paràmetres.

Per a la realització d’aquest treball, s’han emprat les tecnologies web amb les quals l’OWdesenvolupa les seves aplicacions, tals com HyperText Markup Language (HTML), Cascading Style Sheets (CSS), JavaScript i Java.

C

1

I ^NTRODUCCIÓ

Aquest primer capítol està dedicat a la descripció dels motius que justifiquen la rea- lització d’aquest projecte. També es desglossen els diferents capítols en els quals està dividit el present treball.

1.1 Motivació

Avui en dia, cada vegada tenim més tipus diferents de dispositius com són els ordi- nadors, mòbils, tauletes tàctils, etc. Tots aquests dispositius disposen de connexions a Internet i de navegadors web. Gràcies a aquests navegadors webs podem executar aplicacions web, independentment del dispositiu i del sistema operatiu.

Les aplicacions web tenen l’avantatge que no necessiten ser instal·lades en els dispositius, només es necessita un navegador web i les dades estan emmagatzemades al núvol. Cada vegada tenim més aplicacions web com són els paquets ofimàtics, cerca- dors webs, cercadors de viatges, etc. A Mallorca tenim una gran quantitat d’empreses que desenvolupen aplicacions web per al turisme i altres sectors.

Vist que cada vegada es desenvolupen més aplicacions web i que a Mallorca s’està fent molta feina en aquest sentit, trobo que l’aprenentatge de les tecnologies web és bàsic per a qualsevol enginyer informàtic que tengui interés en desenvolupar la seva activitat professional en aquest lloc.

Com a motivacions personals, el present projecte m’ha permés consolidar els co- neixements assolits durant la carrera. Una altra motivació ha estat, la de realitzar una aplicació que s’emprarà a l’OW, ja que ells, em varen donar la possibilitat de tornar a ser alumne col·laborador a laUIBdesprés d’haver estat un any d’intercanvi.

1. INTRODUCCIÓ

1.2 Objectius

La plana web de laUIBté una pàgina on estan publicats tots els estudis oferits a la universitat, s’hi poden trobar els estudis de Grau, Màster i Doctorat. La informació corresponent a cada un dels estudis està disposada en diferents planes que estan enlla- çades entre si per mitjà d’un menú de pestanyes.

L’objectiu principal del present projecte és la realització d’una aplicació web per a l’OW. Que s’emprarà per a controlar la informació mostrada tant a les planes com a les pestanyes mencionades anteriorment, mitjançant la modificació dels paràmetres del generador d’informació dels estudis de laUIB.

1.3 Estructura del document

El presentTFGestà dividit en els següents capítols:

1. Introducció: es descriu la motivació, els objectius i els capítols en què està dividida la memòria.

2. Plantejament del problema: després de descriure l’estat actual, es mostra un resum de la solució proposada i finalment s’expliquen les tecnologies implicades en el desenvolupament de l’aplicació.

3. Anàlisi: es defineixen els requisits i es mostra la planificació del projecte.

4. Desenvolupament de l’aplicació: es descriu el disseny de la interfície, de l’arqui- tectura i també la implementació de l’aplicació.

5. Proves: es detallen les proves que s’han realitzat per a validar l’aplicació.

6. Conclusions: s’exposen les conclusions obtingudes, com a resultat del desenvolu- pament del projecte i delTFG.

2

C

2

P L ANTEJAMENT DEL PROBLEMA

En aquest apartat es defineix la solució adoptada per resoldre el problema plantejat per l’Oficina Web de la Universitat. Primerament es parlarà de l’estat actual en el qual es troba, després es parlarà de la solució proposada i finalment es mostraran les tecnologies emprades al marc tecnològic.

2.1 Estat actual

A la plana web de la Universitat està publicada tota la informació dels diferents estudis de Grau, Màster i de Doctorat, com es mostra a la Fig.2.1. Per mostrar la informació dels estudis, l’OWde laUIBté una aplicació que genera la informació que es mostra a la plana web de laUIB, l’aplicació d’Estudis rep el nom de WebDynaDump.

Figura 2.1: Plana web dels estudis de la UIB

La informació que l’aplicació WebDynaDump de l’OWagafa per a generar la infor- mació de cada un dels estudis de laUIB, les bases de dades d’on agafa la informació

2. PLANTEJAMENT DEL PROBLEMA

per a després mostrar a la plana web de laUIB, són les bases de dades dels Serveis Administratius de cada uns dels estudis, del LIFERAY de la Universitat i del Content Management System (CMS) INFOGLUE, amb el qual està feta la plana web de laUIB.

Per a mostrar la informació d’estudis, l’OWgenera les pàgines d’informació dels estudis. Aquestes pàgines que es generen estan parametritzades. Aquests paràmetres es controlen de forma manual mitjançant un arxiu estàticXML, com es mostra a la Fig.2.2, per a cada una de les generacions. Quan es parla de generacions, s’està parlant que són les generacions que realitza de forma automatitzada l’aplicació WebDynaDump de l’OWper a cada un dels estudis de Grau, Màster i de Doctorat de laUIB.

Figura 2.2: Fitxer estàtic XML d’una generació

L’arxiu estàticXMLestà format perflags, que són etiquetes personalitzades per a la descripció i organització de les dades, que contenen la següent informació: el nom delflagque té associada la informació que es vol representar, un valor booleà que dirà a l’aplicació d’Estudis si ha de mostrar la informació a l’hora de generar les planes d’estudi i finalment tenim com a comentari altra informació, normalment és la data quan han estat canviats els booleans.

A la Fig.2.3, es pot veure la informació del curs 2018-19, que es representa gràcies a un dels paràmetres, elsflagsque s’han mencionat abans, de l’arxiu estàticXMLque utilitza l’aplicació d’Estudis per generar les diferents planes d’estudis.

El principal problema, d’aquest sistema sorgueix quan s’han de fer canvis en la informació que genera l’aplicació d’Estudis, com per exemple el canvi d’assignatures per any acadèmic. Aquests canvis provoquen que s’hagi de modificar l’arxiuXMLdels paràmetres manualment. Això fa que no es puguin realitzar els canvis en els booleans de cada un dels paràmetres fins a la data que s’ha d’actualitzar la informació de la plana web d’estudis. Una altra problemàtica està relaciónada amb el fet que els arxiusXMLs estan al servidor de laUIB, aleshores, si es dóna el cas que dos programadors hagin modificat paràmetres diferents del mateix arxiu, a l’hora de pujar-ho, se sobreescrigui i es perdi la informació modificada per un dels programadors.

4

2.2. Solució proposada

Figura 2.3: Plana web d’un dels estudis de la UIB

2.2 Solució proposada

Per a poder gestionar d’una manera més fàcil per part del personal de l’OWels paràme- tres del generador d’informació dels estudis de laUIB. S’ha creat una aplicació web, per a gestionar els paràmetres de forma automatitzada.

L’aplicació es gestiona mitjançant unbackend, el qual mostra la informació dels pa- ràmetres de les generacions, si estan actius o no. Després hi ha una plana per a cada una de les generacions, on es gestionen els noms, dates d’inici i de fi i un camp de text pels diferents paràmetres. També es poden crear nous paràmetres i esborrar-ne els existents.

L’aplicació està desenvolupada sota una arquitectura client-servidor. El servidor està fet en Java, amb el Framework Spring Boot i serà un RESTful, on els clients, nave- gadors web, faran peticions Asynchronous JavaScript And XML (AJAX), adreçades al servidor. Els clients estan fets ambHTML,CSSi JavaScript. Totes aquestes tecnologies es descriuen a l’apartat següent.

2.3 Marc tecnològic

En aquest apartat es donarà una petita descripció de les eines i tecnologies que s’han emprat per al desenvolupament de l’aplicació. Totes elles s’empren actualment en el desenvolupament d’aplicacionsweben el món professional.

El motiu de l’elecció d’aquestes eines i tecnologies és perquè vénen imposades des de l’OW, ja que serà l’OWl’encarregada de mantenir l’aplicació una vegada lliurada.

Java

Java va aparèixer com un llenguatge de programació de propòsit general, concurrent, orientat a objectes, que va ser dissenyat específicament per tenir tan poques depen-

2. PLANTEJAMENT DEL PROBLEMA

dències d’implementació com fos possible [1]. La seva intenció és permetre que els desenvolupadors d’aplicacions escriguin el programa una vegada i ho executin en qualsevol dispositiu. S’emprarà Java per al desenvolupament de l’aplicació perquè és un llenguatge de programació que ens permet desenvolupar aplicacions web amb l’esquema client-servidor REST.

Spring Framework

Spring Framework [2] ens proporciona un entorn per fer comprensible la programació i la configuració per a Java en qualsevol classe de plataforma de desplegament. Un element clau de Spring és el suport a la infraestructura en l’àmbit d’aplicació: Spring enfoca tots els esforços dels equips de desenvolupament de l’aplicació en l’àmbit de la lògica de negoci, sense estar lligats als diferents entorns.

Spring Boot

Spring Boot [3] facilita la creació d’aplicacions amb Spring. Spring Boot ens ajuda amb la configuració i ens permet enfocar els esforços en el desenvolupament de les aplicacions. Amb Spring Boot s’ha creat la part de la lògica de negoci, el model de les dades que estan a la part del servidor.

Apache Tomcat

Apache Tomcat [4] és una implementació de codi lliure de Java Servlets, JavaServer Pages (JSP) i tecnologies Java WebSocket.

Atès que Tomcat va ser escrit en Java, funciona en qualsevol sistema operatiu que disposi de la màquina virtual Java.

JPA

Java Persistence API (JPA) [5] proporciona un model de persistència basat en Plain Old Java Object (POJO) per establir una correspondència entre les dades emmagatzemades a sistemes gestors de bases de dades relacionals i un models d’objectes definit en Java.

JPAs’utilitzarà amb elframeworkHibernate.

Hibernate

Hibernate és una eina de Object Relational Mapping (ORM) per a Java i que facilita la correspndència dels atributs entre la base de dades relacional i el model de dades de l’aplicació Spring Boot.

HTML

HTML, que significa Llenguatge de Marcat per a Hipertexts (HyperText Markup Lan- guage) [6] és l’element de construcció més bàsic d’una pàgina web i s’usa per crear i representar visualment una pàgina web. Determina el contingut de la pàgina web, però no la seva funcionalitat. A l’aplicació s’utilitzarà per a presentar a l’usuari l’estructura de l’aplicació.

6

2.3. Marc tecnològic

CSS

Fulles d’Estil en Cascada (CSS) [7] és el llenguatge utilitzat per descriure l’estil dels elementsHTML, és a dir, defineix com es mostra un document per pantalla. S’utilitzarà CSSper donar estil als diferents elements l’aplicació.

JQuery

jQuery és una biblioteca multiplataforma de Javascript [8], que permetrà simplificar la manera d’interactuar amb els documentsHTML, ja que ofereix una sèrie de funcionali- tats basades en Javascript i permet manipular l’arbre Document Object Model (DOM), manejar esdeveniments, desenvolupar animacions i agregar interacció amb la tècnica AJAXa pàgines web.

jQuery s’utilitzarà per manipular l’arbreDOM, per fer les peticionsAJAX, per canviar estils d’elements i per controlar els esdeveniments de l’aplicació.

XML

XML[9] és un llenguatge marcat similar aHTML.XMLsignifica Extensible Markup Language i és una especificació recomanada per la World Wide Web Consortium (W3C) com a llenguatge marcat de propòsit general. Això significa, que a diferència d’altres llenguatges marcats,XMLno està predefinit així que permet definir llenguatges d’acord a les necessitats. El propòsit primari del llenguatge és compartir les dades a través de sistemes diferents, com la Internet.

L’aplicació utilitzaràXMLper a transferir els paràmetres al generador d’informació dels estudis.

Bootstrap

Bootstrap [10] és unframeworkweb, un conjunt d’eines de codi obert per a disseny de llocs i aplicacions web. Conté plantilles de disseny amb tipografia, formularis, botons, quadres, menús de navegació i altres elements de disseny basats enHTMLiCSS, així com extensions de Javascript opcionals addicionals.

L’aplicació utilitzarà untemplateBootstrap.

Eclipse

Eclipse és un entorn de desenvolupament extensible creat per una comunitat de codi obert, on els projectes estan enfocats en la construcció d’una plataforma de desenvolu- pament extensible per crear, implementar i administrar programari durant tot el cicle de vida delsoftware[11].

L’aplicació estarà desenvolupada amb l’ajuda de l’Integrated Development Envi- ronment (IDE) Eclipse.

2. PLANTEJAMENT DEL PROBLEMA

GitLab

GitLab és un servei web de control de versions i desenvolupament de programari col·laboratiu basat en Git. El GitLab està publicat sota una Llicència de codi obert [12].

L’aplicació utilitzarà com a control de versions GitLab, en el qual estan tots els desenvolupaments de l’OW.

Sourcetree

Sourcetree és un client de Git per a Windows i Mac, que simplifica la forma d’interectuar amb els repositoris Git [13].

S’utilitzarà Sourcetree com a client de Git per a GitLab, que és el que utilitzen a l’OW.

8

C

3

A ^NÀLISI

La fase d’anàlisis és fonamental per a extreure els requisits de l’aplicació. En els següents apartats s’identifiquen els requisits d’usuari, que es descriuen de forma abstracta a alt nivell, i de sistema, que són una descripció detallada del que el sistema hauria de fer.

Finalment es veurà la planificació del projecte.

3.1 Anàlisi de requisits

En aquest apartat es defineix el comportament de l’aplicació. Es classificaran els requi- sits en dos nivells, d’usuari i de sistema.

3.1.1 Requisits d’usuari

Els requisits d’usuari són declaracions en llenguatge natural de les funcionalitats o ser- veis que ha de proporcionar l’aplicació als usuaris. Seguidament es llisten els requisits.

RU01

L’usuari ha de poder conèixer de forma ràpida els paràmetres que estan actius i quins no, mitjançant una taula i icones.

RU02

Un usuari ha de poder crear noves generacions, introduint el nom i pitjant a un botó de creació de nova generació.

RU03

Un usuari ha de poder eliminar generacions des de la plana principal.

RU04

Un usuari ha de poder afegir nous paràmetres per a cada grup de generació amb les dades de nom, dates d’inici i fi.

3. ANÀLISI

RU05

Un usuari ha de poder actualitzar les dades de nom, dates d’inici i fi dels paràme- tres per a cada grup de generació de forma separada.

RU06

Un usuari ha de poder esborrar cada un dels paràmetres per a cada grup de generació.

RU07

Un usuari ha de poder elegir l’any i si està en mode normal o en transició, per a cada grup de generació.

RU08

Un usuari ha de poder esborrar una generació quan està a la plana de la mateixa generació.

RU09

Un usuari ha de poder anar a una altra generació, quan està dins d’una generació, des del menú.

3.1.2 Requisits de sistema

Els requisits de sistema són especificacions detallades dels requisits d’usuari, que des- criuen les funcions, serveis i restriccions de funcionament del sistema. Aquests requisits es troben escrits des del punt de vista tècnic i per això poden contenir vocabulari propi de l’àmbit.

RS01

El sistema ha d’obtenir les dades de la base de dades i representar la informació en taules per a l’usuari.

RS02

El sistema ha de mostrar mitjançant unbooleanels paràmetres que estan actius i el que no ho estan.

RS03

El sistema ha de donar resposta en formatXMLper als paràmetres del generador d’informació.

RS04

El sistema ha de validar els formularis per a inserir dades a l’aplicació.

RS05

El sistema ha de donarfeedbacka l’usuari quan es fa un canvi en els paràmetres.

RS06

El sistema ha d’estar baix el sistema de seguretatSSOde la institució.

RS07

L’aplicació ha de serresponsive, s’ha d’ajustar a diferents mides de pantalla.

10

3.2. Planificació

RS08

El sistema ha de recarregar la informació dinàmicament.

RS09

El sistema ha de controlar la concurrència a l’hora d’actualitzar els paràmetres, perquè dos usuaris no canviïn la informació al mateix moment.

RS10

El sistema ha de transmetre a l’usuari el tipus d’error que es pugui produir al servidor.

RS11

El sistema ha de permetre actualitzar i/o esborrar els paràmetres de les generaci- ons.

RS12

El sistema ha de poder crear noves generacions, introduint el nom i pitjant a un botó de creació de nova generació.

3.2 Planificació

En aquest apartat parlarem de la planificació del projecte. La planificació ens per- met la programació i estimació del temps de desenvolupament de l’aplicació. Per al desenvolupament no s’ha emprat una metodologia concreta, però té la influència de la metodologia àgilScrum[14].Scrumes basa en un desenvolupament incremental, on cada un d’aquests increments s’anomena Sprint, on es desenvolupen parts del softwarepotencialment a entregar, que dura d’una a quatre setmanes. En finalitzar cada un delsSprintses fa una reunió amb els responsables del projecte, per a presentar el desenvolupament realitzat i planificar el següentSprint.

El desenvolupament de l’aplicació es va fer de forma incremental, per fases, on primerament es té la fase d’anàlisi de requisits i després les fases de disseny, d’imple- mentació i la fase de proves.

La primera fase que es va realitzar va ser la fase d’anàlisi dels requisits, on l’OWme va presentar l’oportunitat de desenvolupar una aplicació per a controlar els paràmetres del generador d’informació dels estudis, que es va realitzar per al present projecte. Es va fer una primera reunió, on varen explicar les necessitats que s’havien de satisfer amb aquesta aplicació i es varen extreure els diferents requisits, que s’han presentat en l’apartat delsrequisits.

Durant el desenvolupament de l’aplicació, es varen realitzar reunions setmanals i/o quinzenals amb els encarregats de la supervisió del projecte, per anar supervisant el desenvolupament de l’aplicació. D’aquesta manera es va poder reaccionar als canvis d’una manera àgil, afegint nous requisits de tant en tant, fins que s’aconseguí tancar la llista.

3. ANÀLISI

Finalment les fases de disseny, d’implementació i de proves es varen realitzar con- juntament, ja que durant la fase de disseny es va començar a fer la fase d’implementació i a mesura que s’anava implementant l’aplicació, s’anava testant. A continuació es des- glossen les fases en les quals es va realitzar les fases de disseny, d’implementació del projecte:

Fase 1.Disseny de la interfície gràfica. A la primera fase es va crear la interfície gràfica, per a veure quines dades necessitaríem per a crear les taules de la base de dades i com els usuaris podrien interactuar amb l’aplicació, això darrer es va fer amb JavaScript, sense tenir la part del servidor.

Fase 2.Disseny del servidor. A la segona fase, es varen implementar les funci- onalitats bàsiques de la interfície REpresentational State Transfer (REST), que són la petició de totes les generacions, d’una generació i la inserció d’una nova generació. Les dades es varen crear de forma estàtica.

Fase 3.Comunicació amb el servidor. Es varen implementar les cridadesAJAX, a la part del client per a la interacció amb el servidor.

Fase 4.Creació dels mètodes per a la recuperació i inserció dels flags al servidor i les cridades corresponents a la part del client ambAJAX, per mostrar les taules amb la informació i inserció de nous flags.

Fase 5.Creació dels mètodes per a l’actualització i esborrat dels flags, tant al servidor com al client.

Fase 6.Creació de l’estructura de les taules per a la base de dades i configuració del frameworkJPA.

Fase 7.Afegir la concurrència a l’hora d’afegir/actualitzar les dades. Així evitem que dues persones actualitzin la mateixa dada alhora al servidor i això provoqui una inconsistència en les dades.

12

C

4

D ESENVOLUPAMENT DE L ’ ^APLICACIÓ

Una vegada plantejat el problema i fet l’anàlisi dels requisits de l’aplicació, es va dur a terme el desenvolupament de l’aplicació. En aquest capítol s’explica com s’ha dut a terme aquest desenvolupament i les solucions que s’han adoptat, i també quins proble- mes s’han trobat a l’hora de desenvolupar-la.

Seguidament es mostra la interpretació que s’ha fet al projecte del model client- servidor, del disseny del client i del disseny del servidor.

Figura 4.1: Model client-servidor

4. DESENVOLUPAMENT DE L’APLICACIÓ

4.1 Model client-servidor

En aquest apartat es parla de l’arquitectura client-servidor, que es mostra a la fig.4.1.

Aquest és el model en el qual es basen les aplicacions web. En aquest model es repartei- xen les tasques entre els proveïdors, els servidors, i els consumidors, els clients.

El servidor està desenvolupat amb elFrameworkSpring Boot i el client ambHTML i la Biblioteca multiplataforma de JavaScript (JQUERY). Per fer la comunicació entre ells, s’han emprat peticionsAJAX, on el client fa les peticions al servidor per a consultar, crear, actualitzar i/o esborrar les diferents generacions i paràmetres. El client fa les peticionsAJAXal servidorREST, el qual accedeix a les dades, que estan a la base de dades, amb l’Application Programming Interface (API)JPAi el servidorRESTretorna la informació en formatXMLmitjançant les accionsGET,POSTiDELETEdel Protocol de transferència d’hipertext (HTTP).

4.2 Disseny del client

Quan es va realitzar la primera reunió amb els responsables de l’OWper a començar el desenvolupament de l’aplicació, la recomanació que varen fer va ser la d’utilitzar untemplateBootstrap debackend, eltemplateque es va elegir va ser SB Admin [15].

En el següent apartat veurem com és la plantilla i les modificacions en el disseny del template que es varen realitzar.

4.2.1 Disseny de la interfície

Com s’ha parlat abans, es va usar untemplatede Bootstrap per a simplificar la tasca de realització delbackend. Es va elegir aquesta solució, per la gran quantitat detemplates que hi ha disponibles al mercat. Eltemplateelegit va ser SB Admin, el qual el es va modificar per ajustar-lo a les necessitats de l’aplicació.

Figura 4.2: Finestra d’inici

L’aplicació bàsicament té dues finestres, una és la plana d’inici i l’altra és la de les ge- neracions. És a aquesta on modificarem els diferents valors delsflagsde les generacions.

14

4.2. Disseny del client

Primerament es parlarà de la plana d’inici. Com es pot veure a la fig.4.2, a la part superior està la capçalera, on es veu el nom de l’aplicació, a l’esquerra està el menú amb les diferents generacions, al centre de la finestra se situen les generacions, mitjançant taules es veuen elsflagsi si aquests estan o no actius. Per a crear una nova generació, es disposa d’un botó, que està situat en la part de dalt de la finestra, per a crear una nova generació només s’ha d’introduir el nom de la nova generació dins elpop-upmodal de Bootstrap, com es veu a la fig.4.3.

Figura 4.3: Afegir una nova generació

Per a poder actualitzar/consultar la informació de les generacions es pot arribar a elles mitjançant el menú o pitjant en el nom que estan situats damunt de les taules. Per esborrar les generacions es poden fer directament des de la icona de paperera que està al costat del nom de cada generació.

Figura 4.4: Generació

La plana de les generacions és la mateixa per a totes les generacions, ja que s’ha de mostrar el mateix tipus d’informació. El contingut de cada generació es canvia de

4. DESENVOLUPAMENT DE L’APLICACIÓ

forma dinàmica mitjançant JavaScript, com s’explica al següent apartat. Seguidament es descriurà la plana de les generacions que es mostra a la fig.4.4. La plana de generacions comparteix amb la plana d’inici la capçalera i, per tant, tant el nom de l’aplicació i com el menú tenen el mateix format. A la part central de la finestra tenim la informació de les generacions, primerament es té el nom de la generació a la part de dalt a l’esquerra, a la mateixa alçada, però a la part de la dreta hi ha un botó per a esborrar la generació de la base de dades. Sota del nom, hi ha dues llistes desplegables on estan l’any i el mode, que són dos paràmetres de les generacions i després es té una taula amb els flags, on es pot modificar els camps de nom, data d’inici i fi i camp de valor, a la part de la dreta de la taula hi ha els botons per a actualitzar i esborrar cada un delsflagsper separat, ja que és el requisitRS11de l’aplicació, a la fig.4.5es pot veure un exemple d’esborrar unflag. I finalment a la darrera filera de la taula, hi ha l’opció per a afegir un nouflag.

Figura 4.5: Exemple d’esborrar flag

4.2.2 Disseny de la implementació

Una vegada vist el disseny de la interfície a l’apartat anterior, ara es parlarà del disseny de la implementació de la part del client. Com la part del disseny de la interfície, la part de la implementació està divididat en dos grans blocs: la part de la maquetació, que està feta ambHTML,CSSi elframeworkBootstrap i, seguidament, la part dinàmica de l’aplicació que està feta amb elframeworkJQUERYde JavaScript.

La part de la maquetació, com s’ha parlat en altres apartats, està basada en un templatede Bootstrap, el qual s’ha modificat per a cobrir els requisits de l’aplicació.

Ara es veurà la part dinàmica del client. Aquesta part s’ha fet amb elframework JQUERYde JavaScript. El JavaScript (JS) que controla la plana web, s’explicarà a conti- nuació.

16

4.3. Disseny del servidor

Com s’ha dit anteriorment, hi ha dos tipus de pantalles diferents, la d’inici i la de les generacions. Aquestes pantalles comparteixen diferents funcionalitats, per això a l’hora de dissenyar la implementació, es va decidir que es crearia un únic fitxerJS, per a facilitar les modificacions en les funcionalitats en comú. Primerament es parlarà de les funcionalitats que comparteixen les dues pantalles i seguidament es parlarà de les funcionalitats separades per les pantalles.

Per totes dues pantalles, es fan cridadesAJAXal servidor per a demanar les dades que estan a la base de dades. Amb les dades que s’han demanat es podran represen- tar els elements de la plana com són el menú i les taules, tal com es pot veure a la fig.4.2.

A la plana d’inici es podrà crear una nova generació. Pitjant al botó de nova ge- neració s’obrirà unpopupmodal de Bootstrap, on es demanarà a l’usuari el nom de la nova generació mitjançant un formulariHTML, com es veu a la fig.4.3, s’enviarà el formulari amb una peticióPOST d’AJAX. També es podrà entrar en cada una de les generacions pitjant damunt del nom de cada generació, tant del menú com de les taules, per a construir la Uniform Resource Locator (URL), al servidor es té el fitxer estàticHTMLi ambJQUERYs’afegeix el paràmetre Identificador (id) de la generació.

A més es podrà esborrar una generació des de la icona de paperera que està situada al costat del nom de les generacions, de nou es fa una peticióAJAXde tipusDELETE.

Després de cada una de les modificacions, es fan noves peticions per a recuperar la informació actualitzada que està al servidor.

Fins ara s’ha parlat de les funcions de la pantalla d’inici de l’aplicació i immediata- ment es parlarà de les funcions a la plana de generacions. Ara a més de les funcions que s’han dit que té en comú amb la pantalla d’inici, hi ha dos tipus de formularis, un pels camps d’any i mode i un altre pelsflags. La funció que controla el formulari de l’any i mode, fa una peticióGETd’AJAX, després es posen les dades a untag selectdeHTML de manera dinàmica, i finalment, s’enviarà la informació seleccionada amb unPOST AJAXcap al servidor. Després es té el formulari deflags, on cada un delsflagsés una filera de la taula delflags, com es pot veure a la fig.4.4. Cada una de les columnes de la taula, són els camps d’informació delsflags. Els camps de nom i valor sóntags input tipus text i els camps de les dates sóninputsde tipusdatedeHTML, posteriorment es podrà actualitzar cada un delsflagspitjant el botóupdate, que farà una peticióPOST AJAXcap al servidor, també es podrà esborrar cada un delsflagsindividualment pitjant al botódelete, que fa una altra cridadaAJAXal servidor. Finalment, es té la darrera filera de la taula, que permetrà afegir nousflags.

4.3 Disseny del servidor

Una vegada que s’ha vist com ha estat dissenyat el client, a continuació es veurà com ha estat dissenyat el servidor. Es parlarà del disseny de l’estructura, que és unRESTi després, de com s’han estructurat les dades, és a dir: del model de les dades.

4. DESENVOLUPAMENT DE L’APLICACIÓ

4.3.1 Disseny de l’estructura

En aquest apartat es parlarà de l’estructura del servidor. L’estructura elegida és una estructuraREST, com es pot veure a la fig.4.6. L’estructuraRESTve imposada des de l’OW, ja que és una aplicació que ve com a proposta de l’OWi també seran els qui mantindran l’aplicació.

Figura 4.6: Forma general d’un Rest webservice

El servidor rebrà peticionsAJAXdes del client i respondrà a aquestes peticions amb les dades sol·licitades, que estan a la base de dades. Les peticionsHTTPque re- brà/respondrà el servidor seranGET,POST iDELETE. L’especificacióGET serà per llegir i consultar informació, l’especificacióPOSTserà per crear i actualitzar les dades i finalment l’especificacióDELETEserà per eliminar dades.

Les accions que es podran dur a terme seran les de demanar totes les generacions a la vegada o una en especial, també es podran crear, modificar i esborrar les generacions.

També es podran crear, modificar i esborrar elsflagsde manera individual, ja que és un dels requisits de l’aplicació i, a més, es podran actualitzar els paràmetres d’any i mode de les generacions.

Totes les modificacions de la base de dades es faran amb l’API JPA, que facilitarà la interacció amb la base de dades. Gràcies aJPAi a l’etiqueta Entity tag (eTag) de la capçaleraHTTP[16] s’ha pogut controlar l’accés concurrent a les dades, mitjançant el control concurrent de forma optimista [17].

El control concurrent de forma optimista funciona de la següent forma, a la base de dades tenim una columna de versió, que es va actualitzant automàticament, que s’envia mitjançant a l’etiquetaeTagcap al client i quan el client vol fer una modificació a les dades, retorna aquesta etiquetaeTagi llavors al servidor es comprova si és la mateixa que ell ha enviat, llavors respon amb codi d’estat 200, es pot veure el diagrama de les accions en la fig.4.7.

18

4.3. Disseny del servidor

Figura 4.7: Control de la concurrencia de forma optimista

A cada una de les peticionsHTTP, el servidor respondrà amb diferents codis d’estat HTTP. S’ha decidit que la nostra aplicació contengui els codisHTMLde l’estàndard HTTP, que tenim a la taula4.1, ja que amb aquests codis es cobreixen les necessitats de resposta al serveiRESTen cas que vagi bé la petició o en cas que es produeixi un problema o un error al servidor.

200 OK

400 BAD REQUEST 404 NOT FOUND 409 CONFLICT

412 PRECONDITION FAILED 500 INTERNAL SERVER ERROR

Taula 4.1: Codis d’estat HTML de l’estàndard HTTP

4. DESENVOLUPAMENT DE L’APLICACIÓ

4.3.2 Model de les dades

Una vegada que s’ha vist com va ser dissenyat el servidor, seguidament es veurà com es varen modelitzar les dades. El nostre model es pot veure a la fig.4.8, on hi ha dues taules, una per a les generacions (Generation) i l’altra per alsflags(GenerationFlag).

Cadascuna de les taules de la base de dades, és una classe de Java que té el mateix nom de la taula. També hi ha una altra classe, que és la classe YearMode, on es tenen de forma estàtica els anys i modes. Seguidament, es parlarà de cada una de les taules de la base de dades.

Figura 4.8: Model de les dades

La primera taula de la qual es parlarà, és de la taula Generation, a continuació es mostren els seus atributs.

Generation

• id:identificador únic de la taula. Ens servirà per fer referència a les generacions.

• name:nom de la generació. Per exemple: Grau.

• year:any al qual fa referència la generació.

• mode:mode al qual fa referència la generació. Només pot tenir els valorsNormal iTransicio.

• idFlags:identificador de la taula de GenerationFlag.

• version:nombre de versió. Ens servirà per fer el control de la concurrència.

La segona taula de la qual es parlarà, és de la taula GenerationFlag, a continuació es veurà els atributs de la taula.

GenerationFlag

• id:identificador únic de la taula. Ens servirà per fer referència alsflags.

• name:nom delflag. Per exemple: MostrarTasas.

20

4.3. Disseny del servidor

• value:camp per a afegir una descripció alflag.

• initDate:data d’inici. Ens servirà per saber quan estarà actiu elflag.

• endDate:data de fi. Ens servirà per saber fins quan estarà actiu elflag.

• idGen:identificador de la taula de Generation.

• version:nombre de versió. Ens servirà per fer el control de la concurrència.

C

5

P ROVES I VALIDACIÓ

En aquest capítol comprovarem si hem assolit o no, els diferents requisits que té l’actual projecte.

5.1 Comprovació dels requisits

En aquest apartat comprovarem si hem assolit els requisits de l’aplicació. Per avaluar- los, el que s’ha fet és anar requisit per requisit i veure si es compleix o no. Seguidament podrem veure els resultats.

Figura 5.1: Plana principal de l’aplicació

RS01

El sistema ha d’obtenir les dades de la base de dades i representar la informació en taules per a l’usuari.

Per avaluar aquest requisit, es pot comprovar en les fig.5.1i fig.5.2, de la pla- na d’inici i de la plana de generacions respectivament, que està disponible la informació de les bases de dades en taules per a mostrar a l’usuari.

5. PROVES I VALIDACIÓ

Figura 5.2: Plana d’una generació

RS02

El sistema ha de mostrar mitjançant unbooleanels paràmetres que estan actius i els que no ho estan.

Per avaluar aquest requisit, es pot comprovar en la fig.5.1de la plana d’inici que els paràmetres estan en taules i es pot veure si estan actius o no mitjançant la columna de valor.

Figura 5.3: Resposta XML d’una generació

Figura 5.4: Validació de formularis

RS03

El sistema ha de donar resposta en formatXMLper als paràmetres del generador 24

5.1. Comprovació dels requisits

d’informació.

Per avaluar aquest requisit, el que s’ha fet ha sigut demanar al servidor la respos- ta a la petició perquè ens retorni les dades del servidor i d’aquesta manera es comprova a la fig.5.3, que té el formatXMLdemanat.

RS04

El sistema ha de validar els formularis per a inserir dades a l’aplicació.

Per avaluar aquest requisit, es comprova inserint dades en el formulari per a crear un nou paràmetre i es veu que dóna un missatge si les dades inserides no són acceptades per a l’aplicació, com es pot comprovar a la fig.5.4.

Figura 5.5: Feedback a l’usuari

RS05

El sistema ha de donarfeedbacka l’usuari quan es fa un canvi en els paràmetres.

Per avaluar aquest requisit, es comprova que una vegada s’ha produït un canvi a la plana, l’aplicació mostra un quadre verd on es pot veure el missatgeCanvi realitzat, com es pot comprovar a la fig.5.5.

Figura 5.6: Sistema de seguretatSSOde la institució

5. PROVES I VALIDACIÓ

RS06

El sistema ha d’estar baix el sistema de seguretatSSOde la institució.

Per avaluar aquest requisit, com es pot veure a la fig.5.6, que l’aplicació està baix el sistema de seguretatSSOde la institució.

Figura 5.7: Visualització de l’aplicació a un iPad

RS07

L’aplicació ha de ser responsive, s’ha d’ajustar a diferents mides de pantalla.

Per avaluar aquest requisit, es comprova que en modificar la mida de la finestra del navegador, s’ha modificat l’aspecte de la pantalla, com es pot comprovar a la fig.5.7.

RS08

El sistema ha de recarregar la informació dinàmicament.

Per avaluar aquest requisit, es pot actualitzar qualsevol part de la plana i es pot comprovar que no es carrega la plana sencera.

RS09

El sistema ha de controlar la concurrència a l’hora d’actualitzar els paràmetres, perquè dos usuaris no canviïn la informació al mateix moment.

Per avaluar aquest requisit, s’ha obert a dos navegadors una mateixa generació, primerament s’ha actualitzat el valor de l’any, com es pot veure a la fig.5.9, i després s’ha anat a l’altre navegador i s’ha intentat modificar el valor de mode i 26

5.1. Comprovació dels requisits

Figura 5.8: Actualitzacions dels paràmetres de forma separada

Figura 5.9: Actualització del camp any.

com es pot comprovar a la fig.5.10ha retornat un missatge d’error indicant que un altre usuari ha modificat les dades abans.

Figura 5.10: Error a l’hora d’actualitzar el camp mode

RS10

El sistema ha de transmetre a l’usuari el tipus d’error que es pugui produir al servidor.

Per avaluar aquest requisit, s’ha generat una petició invàlida al servidor a l’hora

5. PROVES I VALIDACIÓ

d’inserir un nou paràmetre i com es pot veure a la fig.5.11, el servidor ha respost amb un missatge d’error 400.

Figura 5.11: Error 400.

RS11

El sistema ha de permetre actualitzar i/o esborrar els paràmetres de les generaci- ons.

Per avaluar aquest requisit, es pot comprovar a la fig.5.8que existeixen dos botons a cada un dels paràmetres, un per actualitzar i l’altra per esborrar els paràmetres de forma separada.

RS12

El sistema ha de poder crear noves generacions, introduint el nom i pitjant a un botó de creació de nova generació.

Per avaluar aquest requisit, s’ha creat una nova generació. Primer s’ha pitjat al botó de crear la nova generació, com es veu a la fig.5.12, just després s’ha introduït el nom (Doctorat), com es veu a la fig.5.13, i finalment es veu que la nova generació ha estat creada a la fig.5.14.

Figura 5.12: Crear la generació de doctorat

28

5.1. Comprovació dels requisits

Figura 5.13: Crear la generació de doctorat

Figura 5.14: Crear la generació de doctorat

C

6

C ^ONCLUSIONS

L’objectiu d’aquest projecte ha consistit en el desenvolupament d’una aplicació web per al controlador de paràmetres del generador d’informació dels estudis de laUIB per a l’OW. Aquest projecte sorgeix arran de la necessitat d’implementar una solució automatitzada per a l’actualització dels paràmetres que es troben a un arxiu XML estàtic, per part de l’OW. Una vegada finalitzat el projecte, en aquest capítol parlarem de les conclusions a les que hem arribat i també de la visió de futur, que són les millores que es poden dur terme a l’aplicació.

6.1 Conclusions

El propòsit del desenvolupament d’aquesta aplicaciówebva ser la de cobrir una neces- sitat que tenien a la l’OW, ja que tenien un arxiu estàtic com hem comentat a la secció 2.1i era molt tediós actualitzar els paràmetres. Ara amb la nova aplicació no farà falta anar a actualitzar l’arxiu a mà, es podrà actualitzar de manera automatitzada.

Entre les tasques per desenvolupar un projecte desoftwareestan el fet d’extreure els requisits de l’aplicació, de fer la planificació i de plantejar el projecte. També aquests coneixements, han permès aprendre d’una manera més ràpida les tecnologieswebi així poder emprar-les pel desenvolupament de l’aplicació.

Al tancament del projecte, l’aplicació encara no s’ha posat en producció per part de l’OW, ja que actualment estan realitzant canvis en l’aplicació que emprarà l’apli- cació que s’ha desenvolupat al projecte, i també s’està en el canvi d’any acadèmic i per aquests motius l’aplicació encara no es troba en producció. Una vegada que l’a- plicació estigui en producció, s’avaluarà en quina mesura s’ha millorat el sistema actual.

El desenvolupament d’aquesta aplicació, m’ha permès conèixer com es treballa a l’hora de desenvolupar aplicacionswebper part del sector empresarial i a aprendre les

6. CONCLUSIONS

tecnologieswebque s’empren actualment al sector empresarial. Gràcies als coneixe- ments assolits durant els estudis s’ha pogut plantejar el desenvolupament de l’aplicació com el desenvolupament d’un projecte desoftware.

6.2 Visió de futur

Durant la realització del projecte i veient altres desenvolupaments similars, una possible millora de l’aplicació seria tenir totes les generacions a una sola planawebi fer des d’aquesta totes les tasques de creació, actualització, esborrat de les generacions i dels paràmetres. D’aquesta manera seria més fàcil d’utilitzar per part de l’OW.

32

B IBLIOGRAFIA

[1] Wikipedia, “Java, lenguaje de programación,” darrera consulta 03/06/2018. [Onli- ne]. Available:https://es.wikipedia.org/wiki/Java_(lenguaje_de_programación) 2.3

[2] Spring, “Spring framework,” darrera consulta 08/05/2018. [Online]. Available:

https://projects.spring.io/spring-framework/2.3

[3] ——, “Spring boot,” darrera consulta 08/05/2018. [Online]. Available: https:

//projects.spring.io/spring-boot/2.3

[4] T. A. S. Foundation, “Apache tomcat,” darrera consulta 26/05/2018. [Online].

Available:http://tomcat.apache.org/2.3

[5] TutorialSpoint, “Jpa - introducción,” darrera consulta 03/06/2018. [Online].

Available:https://www.tutorialspoint.com/es/jpa/jpa_introduction.htm2.3 [6] W3C, “Html,” darrera consulta 09/05/2018. [Online]. Available: HTMLhttps:

//www.w3schools.com/html/default.asp2.3

[7] ——, “Css,” darrera consulta 09/05/2018. [Online]. Available: https://www.

w3schools.com/css/default.asp2.3

[8] ——, “Jquery,” darrera consulta 12/05/2018. [Online]. Available:https://www.

w3schools.com/jquery/default.asp2.3

[9] ——, “Extensible markup language (xml),” darrera consulta 03/06/2018. [Online].

Available:https://www.w3.org/XML/2.3

[10] ——, “Bootstrap,” darrera consulta 09/05/2018. [Online]. Available: https:

//www.w3schools.com/bootstrap/default.asp2.3

[11] T. E. Foundation, “Eclipse newcomers faq,” darrera consulta 03/06/2018. [Online].

Available:http://www.eclipse.org/home/newcomers.php2.3

[12] GitLab, “Gitlab,” darrera consulta 03/06/2018. [Online]. Available: https:

//about.gitlab.com/product/2.3

[13] Atlassian, “Sourcetree,” darrera consulta 03/06/2018. [Online]. Available:

https://www.sourcetreeapp.com/2.3

[14] Wikipedia, “Scrum,” darrera consulta 01/07/2018. [Online]. Available: https:

//es.wikipedia.org/wiki/Scrum_(desarrollo_de_software)3.2

BIBLIOGRAFIA

[15] S. Bootstrap, “Sb admin,” darrera consulta 06/05/2018. [Online]. Available:

https://startbootstrap.com/template-overviews/sb-admin/4.2

[16] Wikipedia, “Http etag,” darrera consulta 12/05/2018. [Online]. Available:

https://en.wikipedia.org/wiki/HTTP_ETag4.3.1

[17] C. Schwörer, “Managing concurrency in a distributed restful en- vironment with spring boot and angular 2,” darrera consul- ta 12/05/2018. [Online]. Available: https://blog.novatec-gmbh.de/

managing-concurrency-in-a-distributed-restful-environment-with-spring-boot-and-angular2/

4.3.1

34