Desevolupament d'una app de gestió d'esdeveniments

DESENVOLUPAMENT D’UN SISTEMA DE GESTIÓ D’ESDEVENIMENTS Treball de Final de Grau Ferran Ramírez Navajón Data de la defensa: 25 d’Abril de 2019 Director del projecte: Enric Mayol Sarroca, Enginyeria de Serveis i Sistemes d’Informació Grau en Enginyeria Informàtica Especialitat en Enginyeria del Software Resum Quants cops has sentit que el poc temps lliure de què disposes, ha estat mal invertit? En el món en el qual vivim avui en dia, la rutina ens manté molt ocupats, impossibilitant-nos ampliar el nostre cercle d’amics més enllà de totes aquelles persones amb qui coincidim al nostre dia a dia, habitualment a la universitat o a la feina. Pot ser que, en arribar el cap de setmana, tinguem temps per a les nostres aficions, o potser per a descobrir-ne de noves, però no trobem amb qui compartir-les, ja que el nostre cercle social és molt limitat. Avui en dia hi ha molta gent que disposa d’un dispositiu mòbil a l’abast, el mal ús del qual molts cops dificulta les interaccions socials reals, ja que ens aïlla de la realitat. Això no vol dir que, fent un bon ús d’aquest, no es pugui arribar a connectar amb moltíssimes altres persones, les quals tenen inquietuds similars o simplement poden enriquir la nostra vida social, de manera que podríem compartir molt més que una simple conversació a través de la pantalla. És aquest el punt d’inflexió que fa que la idea d’aquest projecte sorgeixi: connectar persones de diferents entorns, les quals poden no tenir res a veure, de manera que conèixer-se personalment no hagués sigut tan fàcil en una altra situació, encara que el fet de compartir aficions les pugui portar a gaudir-les juntes durant el seu temps lliure mitjançant un sistema que els ofereixi aquest avantatge. Aquest projecte presenta una solució de software la qual, aprofitant certs sistemes d’esdeveniments ja existents, aconsegueix unificar-los per així poder oferir moltes més opcions als seus usuaris. D’aquesta manera es volen promoure totes les activitats de lleure possibles i així posar a l’abast de tothom, sense gastar un cèntim, el millor recurs per no tenir cap excusa per poder gaudir, de la millor manera, del temps de lleure. 2 Resumen ¿Cuántas veces has sentido que el poco tiempo libre del que dispones, no ha sido invertido de la mejor manera? En el mundo en el que vivimos hoy en día, la rutina nos mantiene muy ocupados, imposibilitándolos ampliar nuestro círculo de amigos más allá de todas esas personas con quienes coincidimos en nuestro día a día, habitualmente en la universidad o en el trabajo. Puede ser que, al llegar el fin de semana, tengamos tiempo para nuestras aficiones, o quizá para descubrir alguna nueva, pero no encontramos con quien compartirlas, debido a que nuestro círculo social está muy limitado. Hoy en día hay mucha gente que dispone de un dispositivo móvil al alcance, el mal uso del cual muchas veces dificulta las interacciones sociales reales, ya que nos aísla de la realidad. Esto no quiere decir que, con el buen uso de este, no se puede llegar a conectar con muchas otras personas, quienes tienen inquietudes similares a las nuestras, o simplemente pueden enriquecer nuestra vida social, por lo que podríamos compartir mucho más que una simple conversación a través de la pantalla. Es este el punto de inflexión que hace que surja la idea de este proyecto: conectar personas de distintos entornos, las cuales no tienen porqué tener nada que ver, de modo que conocerse personalmente no habría sido tan fácil en otra situación, todo i que el hecho de compartir aficiones les pueda llevar a disfrutarlas juntas durante su tiempo libre mediante un sistema que les ofrezca esta ventaja. Este proyecto presenta una solución de software la cual, aprovechando ciertos sistemas de eventos ya existentes, consigue unificarlos para así poder ofrecer muchas más opciones a sus usuarios. De esta manera se quieren promover todas las actividades de ocio posibles y así poner al alcance de todo el mundo, sin coste alguno, el mejor recurso para no tener ninguna excusa ante poder disfrutar, de la mejor manera, de nuestro tiempo libre. 3 Abstract How many times did you feel like you did not make the most out of your free time? Nowadays, our routines keep us too busy, making it almost impossible to grow our social circles beyond those people who are present in our daily routine, usually either at university or at work. Maybe on the weekend we have free time to spend on our hobbies, or to find new ones, but we may not have people to share them with, because our social circles are really limited. The increasingly widespread use of smartphones today makes social interactions even more difficult by isolating users from reality. Nevertheless, we can use our phones to connect with people with whom we share common likes and interests, and even those who can just enrich our lives. We could be able to share more than a simple conversation through the screen. This is the inspiration behind my idea - connecting people from different environments, allowing them to share their hobbies with those they could not get to meet during their daily routine. This project offers a software solution which unifies many already existing systems in order to offer many more options to its users. In this way, with my system I want to promote as much leisure activities as possible by offering to everyone, without spending a penny, the best way to avoid excuses, and to make the most out of their free time. 4 Índex de continguts 1 Preàmbul 8 1.1 Introducció 8 1.1.1 Context 8 1.1.2 Stakeholders 9 1.2 Estat de l’art 10 1.3 Formulació del problema 12 1.3.1 Abast 12 1.4 Objectius 14 1.5 Metodologia i rigor 15 1.5.1 Eines de desenvolupament 16 1.5.1.1 Control de versions del codi 16 1.5.1.2 Postman 18 2 Gestió del projecte 19 2.1 Planificació temporal 19 2.1.1 Tasques 19 2.1.2 Organització de les tasques 22 2.1.2.1 Diagrama de GANTT 22 2.1.2.2 Taula de dependències 23 2.1.3 Recursos 24 2.1.3.1 Recursos humans 24 2.1.3.2 Recursos software i hardware 24 2.1.4 Valoració d’alternatives i pla d’acció 25 2.2 Planificació econòmica 27 2.2.1 Identificació i estimació de costos 27 2.2.1.1 Costos directes 27 2.2.1.2 Costos indirectes 27 2.2.1.3 Resum de costos totals 29 2.2.1.4 Imprevistos 29 2.2.2 Control de gestió 30 2.3 Sostenibilitat 32 2.3.2 Dimensions de sostenibilitat 34 2.3.2.1 Econòmica 34 2.3.2.2 Ambiental 35 5 2.3.2.3 Social 35 2.3.2.4 Matriu de sostenibilitat 36 3 Especificació 37 3.1 Model conceptual 37 3.2 Requisits funcionals 39 3.2.1 Casos d’ús 39 3.3 Requisits no funcionals 45 4 Disseny 47 4.1 Arquitectura del sistema 47 4.1.1 Context del sistema 47 4.1.2 Components i tecnologies usades 48 4.2 Servei web 49 4.2.1 API REST 49 4.2.2 Base de dades 51 4.2.3 Control de versions 51 4.2.4 Autofac 53 4.2.5 Automapper 54 4.3 Aplicació web 56 4.3.1 Interfície 56 4.3.1.1 Mockups 56 4.3.1.2 Usabilitat 58 4.3.2 Tecnologies 59 4.3.2.1 Unistore 59 4.3.2.1 Material-UI 60 4.3.2.1 ReactJS 60 5 Implementació 61 5.1 Creació del servei web 61 5.1.1 Arquitectura Domain Driven Design 61 Capes i nivells 62 Capa de presentació 63 Capa de Serveis Distribuïts 64 Capa d’Aplicació 65 Capa de Domini 65 Capa d’infraestructura per a la persistència de dades 66 6 Capa d’infraestructura transversal 67 5.1.2 Principis SOLID 68 5.1.3 Patrons i principis aplicats 71 5.2 Creació de l’aplicació web 74 5.2.1 Eines de suport 75 5.2.2 Arquitectura jeràrquica 78 5.2.3 Compatibilitat 79 5.2.4 Flux de dades 79 5.3 Temps dedicat 81 6 Validació 82 6.1 Testing 83 6.1.1 Tests unitaris 83 6.1.2 Integration Tests 84 7 Integració de coneixement 87 7.1 Coneixements aplicats 87 7.2 Assoliment de competències 87 8 Conclusions 89 8.1 Assoliment d’objectius 89 8.2 Valoració personal 90 8.3 Contribucions 90 8.4 Treball futur 90 9 Referències 92 10 Glossari 95 7 1 Preàmbul 1.1 Introducció 1.1.1 Context Són molts els cops que volem sortir de la nostra rutina o realitzar certes activitats lúdiques específiques, però tant el ritme de vida tan elevat en el que molts ens trobem, com el simple fet de no conèixer la gent adequada per realitzar-les, ens impedeix poder sortir de la nostra zona de confort per així poder ampliar el nostre rang de hobbies a realitzar en el nostre temps lliure. El problema però, no és tan sols aquest, sinó que també hi ha moltes activitats que deixem de fer i d'aprendre per falta de recursos. És per això que actualment ja hi ha més d’un lloc web i algunes aplicacions mòbils les quals faciliten la cerca d'esdeveniments organitzats, permetent realitzar activitats de tota mena mitjançant la publicació d’esdeveniments sense restricció pel que fa a l'experiència i separant aquests depenent del lloc en el qual es realitzen. Aquestes aplicacions ofereixen un gran nombre de possibilitats, cadascuna d’aquestes orientades a diverses menes de públic. Alguns cops inclús, trobem que la selecció del públic, donada pel tipus de funcionalitats oferides a cadascun dels diferents sistemes, és tan estricta que sorgeixen certes limitacions per a l’usuari estàndard que no vol limitar tant el tipus d’esdeveniments als quals es vol subscriure. És per això que, un cop trobades aquestes limitacions en els sistemes esmentats, sorgeix la idea de realitzar una nova plataforma que unifiqui tots els esdeveniments presentats en els sistemes existents. El nou sistema a desenvolupar, anomenat HitMeApp  , tindrà com a finalitat trencar les barreres que aquests sistemes existents presenten individualment, perquè en presentar-los tots agrupats, estaríem facilitant la participació en aquests per part dels usuaris i permetent-los disposar de manera rapida del coneixement de totes les activitats lúdiques d'interès realitzades al seu entorn d’una manera més compacta i amb gran varietat a escollir. Llavors no estaríem limitant a l’usuari a l'únic ús d’una de les plataformes, augmentant així el seu ventall de possibles esdeveniments als quals unir-se i no forçant-lo a només moure's al voltant d’un únic entorn social. 8 1.1.2 Stakeholders Els stakeholders són tots aquells actors implicats en el projecte, els quals tenen un cert interès en aquest. En aquest projecte, els podem classificar en els següents grups: 1. Usuaris. Els quals faran ús de les funcionalitats ofertes en el sistema desenvolupat i per tant són els primers beneficiaris en la creació d’aquest, ja que gaudiran de tots els avantatges que es presentaran, així com seran els qui interactuaran amb les funcionalitats ofertes. 2. Organitzadors. Es tracta de totes aquelles persones que s’han encarregat de publicar nous esdeveniments, ja que gràcies al nou sistema augmentaran l’abast de persones que veuran les activitats que ofereixen i per tant podran aspirar a aconseguir molts més participants en aquests. 3. Plataformes ja existents. Aquests actors són els quals proporcionen les APIs que el sistema consumirà, de manera que l’ús d’aquestes els beneficiarà pel fet que les funcionalitats que s’oferiran a l’usuari habitualment requeriran interacció amb els serveis oferts per aquestes plataformes i per tant es promourà l’ús d’aquestes. 4. Desenvolupador. També jo, com a desenvolupador, seré un actor implicat, ja que sóc la persona encarregada de la implementació de l’aplicació dins de les dates marcades, així com de realitzar tota la recerca i aprenentatge de les tecnologies a integrar al sistema per tal que aquest funcioni de manera correcta. 9 1.5.1 Eines de desenvolupament Hi ha hagut certes eines que han sigut molt importants durant tot el procés de desenvolupament. 1.5.1.1 Control de versions del codi Git ens proporciona un control de versions sobre el nostre codi font durant el desenvolupament de software. Gràcies a això, he pogut tenir en tot moment una versió actualitzada del meu codi en línia. D’entre les opcions que es poden afegir als repositoris creats a GitHub, he fet servir els Kanban Boards que proporciona per poder visualitzar les tasques que s’han de realitzar, les que estan en procés i les realitzades. Aquestes permeten tenir una millor visió del flux de treball seguit i de la feina a fer. Figura 1.1: Taulell de tasques ofert per GitHub 16 El procés a seguir ha sigut, primerament, crear un Basic Kanban  , que feia referència al repositori sobre el qual anava a treballar. Després, a l’apartat Issues  ,  definir totes les tasques que pretenia realitzar abans de començar a escriure cap mena de codi. Un cop definides, anant al taulell, podia arrossegar-les i assignar-les a la primera columna to do  . En aquesta columna és on s’han de posar totes les tasques assignades al projecte i que, en algun moment o altre, es volen acabar realitzant. Ha sigut a partir d’aquí quan he afegit les issues  en les que estaria treballant a la columna doing  , de manera que consultant aquesta columna podia consultar en tot moment la feina sobre la qual s’estava treballant en aquell moment. Això em va permetre poder treballar d’una manera molt més organitzada i no perdre la línia de treball en cap moment. Una última característica molt interessant, a més, va ser el fet que amb una certa sintaxi emprada en la redacció del missatge del commit podia vincular aquest sobre aquestes issues  i encara més, realitzar certes operacions sobre aquestes com tancar-les. Això es pot veure a la següent imatge, on mitjançant el símbol #  , indico sobre quina tasca es fa referència en el commit pujat. Figura 1.2: Conjunt de commits  realitzats durant el projecte. 17 Un cop finalitzades aquestes tasques han sigut mogudes a la columna Done  . 1.5.1.2 Postman Un cop acabada la configuració del servei web, gràcies a l’ús de Postman, s’han pogut provar tots els endpoints, per així, abans de desenvolupar l’aplicació mòbil es podia realitzar un testeig manual d’integració, amb el que podíem veure si s’obtenia la resposta esperada. Figura 1.3: Crida a un dels endpoints del servei web. A més Postman permet la creació de col·leccions, amb les crides ja configurades per estalviar temps a l’hora de realitzar les proves. 18 2 Gestió del projecte 2.1 Planificació temporal 2.1.1 Tasques Per tal de poder realitzar correctament el projecte, caldrà portar a terme la següent llista de tasques i subtasques, les quals permetran aconseguir que el sistema es pugui desenvolupar de la manera establerta en la seqüència mostrada: T1 - Gestió inicial del projecte Per començar amb la realització d’aquest projecte ens fa falta una planificació de tota la feina que es realitzarà posteriorment per tal d’aconseguir el resultat esperat. És per això que es defineixen tots els límits d’aquests així com l’objectiu al qual es vol arribar incloent tots els mètodes i eines per aconseguir-ho. Es calcula que el ritme de treball diari serà de 2,4 hores durant 21 dies. Temps estimat: 50 hores. T2 - Documentació Amb la planificació inicial ja es disposarà d’una documentació inicial, la qual seguirà en curs durant tota la realització del projecte per tal de poder completar tots els apartats aconseguint informació més precisa. Aquesta a més, començarà abans que la gestió inicial del projecte acabi, ja que la gestió principal d’aquest també cal incloure-la dins la documentació final. No es pot establir un ritme de treball constant per a aquesta, ja que al final de cadascuna de les pròximes tasques caldrà ampliar aquesta documentació. Temps estimat: 50 hores. T3 - Investigació i familiarització amb les APIs Ja que en aquest projecte es faran servir les APIs proporcionades per diverses plataformes diferents, primer caldrà investigar quines seran les que s’utilitzaran, atenint-se a l’objectiu principal i les funcionalitats ofertes per cadascuna de les APIs. Un cop s’hagi superat aquesta primera fase caldrà estudiar el funcionament de les APIs escollides per així saber com poder 19 aprofitar totes les funcionalitats que aquestes ofereixen i realitzar certes proves sobre aquests per poder veure quantes de les funcionalitats són compatibles entre elles i així poder realitzar una estimació de quina serà la càrrega de treball que suposarà fer un ús d’aquestes en un mateix sistema. El ritme de treball serà de 2,35 hores diàries durant 17 dies. Temps estimat: 40 hores. T4 - Creació de servei web Les APIs necessitaran connectar-se a un servei web des del qual es controlarà l’inici de sessió d’usuaris els quals les faran servir. És per això que una de les tasques imprescindibles consistirà en la creació d’un servei web el qual actuarà com a intermediari entre les funcionalitats ofertes per les aplicacions d’esdeveniments i l'aplicació resultant del projecte, la qual els usuaris faran servir per poder gaudir del nou sistema. El ritme de treball per a aquesta tasca serà de 6.15 hores diàries durant 13 dies. Temps estimat: 80 hores. T5 - Creació de l’aplicació web funcional Un cop complets els punts anteriors, ja es disposarà del coneixement i les eines suficients per poder desenvolupar l’aplicació mòbil que brindarà als usuaris la possibilitat de fer servir el nou sistema, per això caldrà realitzar diverses subtasques: T5.1 - Crear part gràfica Caldrà planificar quines són les diverses vistes que es volen tenir a l’aplicació i dissenyar-les per poder crear els layouts corresponents. Temps estimat: 40 hores. T5.2 - Connexió amb servei web Un cop ja disposem de cadascun dels layouts pertinents podem realitzar les connexions al servei web que pertanyin a cadascun d’aquests. Temps estimat: 20 hores. T5.3 - Connectar amb APIs d’esdeveniments 20 Caldrà que es realitzin les connexions a les APIs ja analitzades anteriorment, de les quals s’obtindrà certa informació per així poder realitzar les següents subtasques: T5.3.1 - Afegir funcionalitats bàsiques Primerament s’inclouran a l’aplicació totes aquelles funcionalitats més essencials, com ho pot ser el fet de llistar les aplicacions mostrant tota la informació important d’aquestes. Temps estimat: 50 hores. T5.3.2 - Afegir funcionalitats extra Un cop el sistema ja estigui complet i es disposi d’una versió funcional d’aquest, es plantejarà la incorporació de noves funcionalitats les quals suposin una millora sobre les funcionalitats que les APIs proporcionen al nostre sistema. Temps estimat: 40 hores. En total es treballaran 38 dies a un ritme de 4 hores diàries. T6 - Proves finals Encara que l'aplicació ja sigui funcional, s’hauran d’haver realitzat proves al llarg del projecte, i s’haurà de verificar que aquestes permeten garantir el correcte funcionament de totes les funcionalitats del sistema. El ritme de treball serà més elevat, de manera que augmentarà a 5 hores diàries durant 9 dies. Temps estimat: 50 hores. T7 - Preparació de la defensa Un cop ja tot funciona caldrà rellegir la documentació i unificar-la de manera correcta. Un cop aconseguit, caldrà preparar la defensa del treball. Finalment es treballaran 3.75 hores diàries durant 8 dies. Temps estimat: 30 hores. Temps final: 450 hores. 21 2.1.2 Organització de les tasques 2.1.2.1 Diagrama de GANTT Amb el següent diagrama de Gantt, el qual és una eina de control de producció que ens permet veure de manera gràfica l’activitat a realitzar en un projecte, s’exposa el temps de dedicació previst per a les diverses tasques al llarg del desenvolupament del projecte. Aquest, però, no indica cap mena de correlació entre les tasques, de manera que podem veure com en alguns casos aquestes poden superposar-se. Figura 2.1 Diagrama de Gantt 22 2.1.2.2 Taula de dependències Gràcies a l’ús de la següent taula de dependències es pot veure el temps estimar per a l'execució de cadascuna d’aquestes d’una manera molt més clara que en el diagrama anterior, així com la precedència entre aquestes, perquè així sigui més clar l’ordre que se seguirà a l’hora de portar-les a terme. Codi Tasca Temps estimat Data inici Data fi Dependent de T1 Gestió inicial 50 h 17/09/2018 15/10/2018 - T2 Documentació 50 h 01/10/2018 04/01/2019 - T3 Investigació APIs 40 h 01/10/2018 23/10/2018 - T4 Creació servei web 80 h 24/10/2018 09/11/2018 T3 T5 Creació APP - 12/11/2018 02/01/2019 T4 T5.1 Creació part gràfica 40 h 12/11/2018 23/11/2018 T5.2 Connexió servei web 20 h 26/11/2018 30/11/2018 T5.3 Connexió APIs - 03/12/2018 02/01/2019 T5.3.1 Funcionalitats bàsiques 50 h 03/12/2018 19/12/2018 T5.3.2 Funcionalitats extra 40 h 19/12/2018 02/01/2019 T6 Proves finals 50 h 03/01/2019 15/01/2019 T5 T7 Preparació de la defensa 30 h 16/01/2019 25/01/2019 T6 TOTAL 450 h Figura 2.2 Taula de dependències entre les tasques a realitzar durant el projecte 23 2.1.3 Recursos 2.1.3.1 Recursos humans Com a recursos humans en aquest projecte podem identificar-me a mi, l’autor d’aquest, adquirint diversos rols, com ho són tant el de project manager  , desenvolupador i tester  . El primer recurs humà llavors afectaria a totes les tasques del projecte, a causa del fet que no hi ha cap altra persona per a la redacció de la documentació. A més també cal incloure al tutor del projecte, qui s’encarrega de les feines de tutorització que inclouen la revisió de la documentació a mesura que aquesta es completa. El rol de project manager intervé especialment a la T1, T4 i T5, el de desenvolupador i tester a les tasques T3, T4 i T5 en detall, tot i que el de tester té gran importància a la T6 i finalment, el tutor del projecte intervé a les tasques T1, T2 i T7. 2.1.3.2 Recursos software i hardware Per a les tasques que impliquen relació amb la programació de l’aplicació web, la connexió amb les APIs i la creació i connexió del servei web, a més de les proves finals, fan ús de certs recursos tant software com hardware. Totes aquestes tenen en comú l’ús d’un ordinador portàtil ASUS A55A i en els casos que cal realitzar tasques que impliquen programació mòbil també es farà servir un terminal mòbil, en concret un Xiaomi Mi A1  . A més caldrà l’ús del programari Visual Studio Code per a tota la programació de l’aplicació web i l’ús de Visual Studio 2017  per a la programació del servei web. Aquests recursos han intervingut a les tasques T3, T4, T5 i T6, tot i que l’ordinador també s’ha fet servir per a les tasques de redacció, de manera que ha influït en tota la resta també. 24 2.1.4 Valoració d’alternatives i pla d’acció En aquest projecte hi ha certs factors que poden posar en perill el compliment de les dates estimades per a la realització del projecte, és per això que cal estudiar els problemes que poden sorgir per així tenir en compte el retràs que aquests poden suposar. Els problemes que s’espera que poden sorgir són els següents. Error en la planificació temporal Pot ser que la planificació temporal establerta anteriorment no sigui tan ajustada a la realitat de manera que això variaria en gran mesura l’esquema horari general. Falta d’experiència La falta d’experiència és el problema més gran presentat a l’hora de crear aquest projecte, en especial en els següents punts: Dificultat en l’ús de les APIs Que pot suposar un afegir respecte al temps estimat en la tasca d’estudi i selecció de les APIs a consumir en el sistema. Dificultat en la creació del servei web La qual podria també afegir un temps extra un cop es comencin a realitzar les primeres tasques del projecte. No disponibilitat de les APIs previstes Podria donar-se que les APIs que s’han consultat fins al moment no funcionessin o no estiguessin disponibles després de ja haver-les seleccionat. 25 2.3 Sostenibilitat A partir de l’enquesta realitzada es poden extreure moltes conclusions, ja que avui en dia en tenir tant present la tecnologia, el desconeixement en termes de sostenibilitat sobre aquesta pot arribar a suposar un gran impacte negatiu en diverses àrees del nostre entorn. Cal prendre consciència sobre els efectes que suposa el gran avanç tecnològic, que molts cops deriva en una necessitat social de renovar prematurament molts dispositius electrònics sense haver-los amortitzat fins a la vida útil esperada i convertir-los en residus en comptes d’intentar reaprofitar-los per així evitar crear una gran petjada ecològica, ja que aquests contenen components que són molt tòxics per al medi ambient. A més el no tractar de reutilitzar els components electrònics fa que els recursos naturals s’esgotin d’una manera insostenible per tal de produir-los de nou. És per això que cal que la societat sigui responsable pel que fa al consum i reciclatge d’aquests. Especialment tots els que ens plantegem portar a terme un nou projecte, ja que cal valorar si aquest serà sostenible tant en els aspectes econòmic, social i ambiental per tal d’aconseguir que l’avanç tecnològic vagi directament relacionat amb la sostenibilitat. Per aconseguir-ho cal conèixer l’impacte ambiental de l’ús de les tecnologies de la informació i de la comunicació, fer ús dels indicadors adequats, estudiar els recursos a utilitzar i el cicle de vida d’aquests per així, un cop el projecte ja estigui definit, es pugui tractar de trobar noves idees i solucions que permetin convertir cadascun dels nostres projectes tecnològics en una versió millorada i més sostenible. Tot això pot aconseguir-se aplicant diversos mètodes i tecnologies, els quals permetran que disminuïm els valors dels indicadors d’impacte ambiental existents. Això sempre es fa sota el pretext d’aconseguir un planeta més sostenible, de manera que cal introduir als nostres projectes idees com justícia social, reutilització de recursos i economia circular. És només així com, amb la col·laboració de tothom, es podran millorar tots aquells desavantatges que les noves tecnologies han provocat al nostre entorn. Per últim, per assolir un bon nivell de sostenibilitat en els equips de treball cal establir de manera clara les pautes del projecte i que per part de tots els membres es pugui oferir compromís per complir l’objectiu comú que tots els membres de l’equip han de compartir. 32 Caldrà tenir cura de la feina feta per tal que no obstaculitzi la feina de la resta de membres de grup, així com evitar deixar aspectes del projecte pendents a tractar els quals poden suposar obstacles futurs en el bon desenvolupament i enteniment del grup. 33 2.3.2 Dimensions de sostenibilitat A l’hora d’avaluar si un projecte és sostenible, són diversos els aspectes que ens cal analitzar per a poder determinar la viabilitat d’aquest. Podem classificar els aspectes a estudiar en les dimensions següents. 2.3.2.1 Econòmica Per analitzar la viabilitat econòmica cal estudiar tots els costos que aquest implica. Tal com hem vist a l’apartat anterior trobem que el preu del producte no serà gaire elevat pel fet que no requereix cap cost extra a part dels recursos bàsics per al desenvolupament del projecte, com ho són l’ordinador i el telèfon mòbil propis del desenvolupador, de manera que s’estan aprofitant els recursos dels quals ja es disposava i els quals no es podria evitar pagar de cap altra manera, ja que aquests són els elements bàsics per al desenvolupament de qualsevol software mòbil. Respecte a l’ús de recursos humans, no s’espera cap variació important, ja que amb un únic desenvolupador es pot mantenir el sistema en cas que aquest es volgués anar millorant. L’únic fet que podria incrementar el preu en un futur serà el canvi de servidor en el qual es desplega tot el sistema, el qual, a mesura que es requereixin majors prestacions, podrà incrementar el seu cost. Cal dir que, com les APIs de les quals es consumiran recursos des del nou sistema no són de pagament (l’ús de recursos en si, tot i que alguns esdeveniments poden requerir un preu d’inscripció) el nostre sistema no està millorant econòmicament respecte als sistemes ja existents, ja que no és l’objectiu principal d’aquest. Podrien aparèixer certs riscos durant la realització del projecte que perjudicarien la viabilitat d’aquest, tot i que aquests problemes serien solucionables. Aquest ja s’han vist però anteriorment a l’apartat del pressupost. Veiem que el cost del projecte és el mínim a esperar, de manera que és molt competitiu perquè els costos inicials a cobrir serien despeses mínimes i no hi hauria manera que un projecte similar es desenvolupés amb molts menys recursos o en un temps molt inferior si no fos augmentant els recursos humans, fet que encariria el producte. A més sobre les despeses 34 causades no es cobririen amb diners dels usuaris, ja que els sistemes d’aquest caire no tenen cap ànim de lucre. 2.3.2.2 Ambiental En quants als recursos usats per al desenvolupament del projecte, trobem que l’impacte ambiental que aquest tindrà serà mínim pel fet que només es farà ús d’un telèfon mòbil i d’un ordinador portàtil amb una antiguitat de 4 anys, de manera que el cost d’aquest ja està amortitzat. Aquests recursos s’estan reutilitzant, ja que no estan únicament destinats a la realització del projecte, de manera que podem considerar que el cost de l'electricitat que aquests comporten per les hores destinades a la realització del projecte no suposa un increment significatiu. A més, en tractar-se d’un programari software, no es requerirà afegir cap cost a causa de la fabricació del producte, ja que serà inexistent. No es troba cap millora quant a la dimensió ambiental com que respecte a les plataformes introduïdes a l’estat de l’art també es presenten solucions amb els mateixos avantatges, traient el fet que probablement aquestes sí que han tingut més d'un recurs únicament destinat al desenvolupament d’aquestes, amb tot l’impacte que això comporta. 2.3.2.3 Social Trobem que en aquest projecte la part social té una importància significativa perquè l’objectiu d’aquest és facilitar una tasca que implica una gran interacció per part diferents persones i que alhora sense aquesta, els sistemes implicats no tindrien cap mena de sentit i mancarien de contingut a oferir. Durant la posada en producció, donat que aquest projecte posa en marxa una idea que requereix certs coneixements en una àrea del meu interès i a més fa ús d’un conjunt de sistemes els quals personalment m’han resultat molt útils, considero que el nivell aportació personal en aquest projecte és bastant alt. 35 El projecte resoldrà en gran mesura un problema social, facilitant a un gran nombre de persones el coneixement d’activitats donades al seu voltant, però totes aquestes d’una manera unificada, fet que no trobàvem a cap de les plataformes presentades a l’estat de l’art. Això és a causa del fet que totes aquestes plataformes estaven enfocades a un objectiu i un usuari molt concret, però no es contemplava el fet de poder arribar a moltes més persones per tal de no dividir-les tant i així afavorir la diversificació dels usuaris, que comportaria una major diversificació dels assistents a tota mena d’esdeveniments. Cal tenir en compte que el nou sistema a desenvolupar té com a objectiu principal facilitar la gestió d’una funcionalitat bàsica ja existent, de manera que tot i tenir expectatives d’una llarga vida útil pel gran valor social i la intencionalitat d’aquest. Pel que fa als riscs, no hi ha cap que pugui suposar fets negatius respecte a la dimensió social. Únicament es podria donar el cas que apareguessin sistemes similars que fessin que aquest no es fes servir. 2.3.2.4 Matriu de sostenibilitat Finalment, obtenim la següent matriu de sostenibilitat, la qual mostra els valors en les unitats corresponents dels apartats PPP i vida útil, o la puntuació de 0 a 10 en el cas de la dimensió social. PPP Vida útil Riscs Econòmica 198,46 € 13,46 € Pocs Ambiental 110 kWh 165 kWh/any Pocs Social 9 8 Cap (Tots els valors de la taula estan explicats amb detall als apartats anteriors) Figura 2.3 Matriu de sostenibilitat 36 3 Especificació 3.1 Model conceptual Per començar amb l'especificació del projecte, és indispensable representar de manera gràfica tot el sistema. Cal fer una composició amb tots els elements que intervenen en la resolució de l’objectiu del projecte per tal d’establir certs conceptes d’una manera clara. Gràcies al següent model conceptual, puc fer una abstracció de tots els conceptes reals de manera que es poden representar totes les relacions entre els diferents elements que participen en el sistema. Claus foranes: (Categoria, Nom); (Esdeveniment, Id); (Localització, Latitud, Longitud); (Horari; dataInici, dataFi) Figura 3.1: Model conceptual del sistema 37 Com es pot observar en el diagrama anterior, hi ha quatre entitats diferents, de les quals Categoria  i Esdeveniment  que són les principals que es tractaran al sistema. Si parem atenció sobre les relacions entre entitats, veiem que dins del sistema HitMeApp  , cadascun dels esdeveniments únicament pertanyerà a una categoria pròpia d’aquest, al marge de la categoria en què es trobés al sistema que ofereix aquest esdeveniment. A més, els esdeveniments es poden relacionar amb altres entitats les quals donen més informació sobre aquests. Aquestes fan referència a la localització en la qual l’esdeveniment té lloc i l’horari en què aquest es realitzarà. Aquest esdeveniment serà únic, tal com la clau forana id indica, ja que si es pogués donar el cas que un esdeveniment amb un cert nom succeeix periòdicament, aquest es tractarà com a una nova entitat sense cap mena de relació amb cap altra pel seu nom  . Per aquest motiu veiem que cada esdeveniment només podrà tenir una única Data  i Localització  . En definitiva, es pot veure com l’esdeveniment és l’entitat de la qual totes les altres depenen, i per tant sobre el voltant de la qual s’establirà el projecte. 38 3.2 Requisits funcionals Per poder concretar les funcionalitats d’un sistema, abans d’implementar-lo, és necessari definir quins seran els requisits funcionals d’aquest[8]. Els requisits funcionals no són ni més ni menys que una característica requerida del sistema que expressa una capacitat d’acció d’aquest mateix. Per a la meva especificació de requisits funcionals faré servir un diagrama UML de casos d’ús[9]. 3.2.1 Casos d’ús Un cop descrites les entitats que intervindran en el software a desenvolupar, a un alt nivell d’abstracció, es requereix establir quines són les funcionalitats que el sistema serà capaç de realitzar. Aquestes funcionalitats queden clares amb l’especificació dels requisits funcionals els quals, bàsicament, descriuen el que el sistema ha de fer. Aquests es poden veure al diagrama de casos d’ús que es troba a continuació[10]. 39 Figura 3.2: Diagrama de casos d’ús A part de l’esmentat, mitjançant els escenaris d’ús, es poden descriure amb més detall els diferents casos d’ús que es poden trobar en el nostre sistema HitMeApp, permetent donar més informació respecte a totes les situacions que es poden donar. És per això que, a continuació, es mostra l’escenari principal dels diferents casos d’ús que han sigut usats per representar els requisits funcionals del sistema: 40 Nom del cas d’ús Mostrar esdeveniments propers Actor principal Usuari Precondicions - L’usuari disposa de servei de localització al seu dispositiu mòbil. - L’usuari disposa de connexió a internet. Escenari principal 1L’usuari envia una petició al sistema HitMeApp incloent les coordenades de la seva localització. 2 El sistema HitMeApp processa la petició de l’usuari. 3El sistema HitMeApp consulta els serveis d’esdeveniments amb les coordenades obtingudes. 4Els serveis d’esdeveniments retornen els esdeveniments que coincideixen amb les condicions establertes 5El sistema HitMeApp retorna tots els esdeveniments propers a l'àrea de l’usuari. 41 Com es pot observar a la figura 4.1, el servei web disposa d’una base de dades on es guardarà certa informació rellevant. A més, com es veu a la part dreta de la imatge, aquest servei web aprofita diferents serveis externs per satisfer les necessitats del sistema. El servei web està construït en forma d’API REST, que és el servei web mostrat a la imatge. Aquest servei web és l’encarregat de comunicar-se amb les APIs externes al sistema, les quals ofereixen informació rellevant que conté els esdeveniments dels quals disposen així com les seves categories. Un cop es rep aquesta informació, en format json  , és tractada i retornada com a una nova resposta json  cap al client. Així i tot, no totes les casuístiques requeriran fer una petició a les APIs externes d’esdeveniments al sistema, ja que alguna de les peticions podrà requerir únicament accedir a la base de dades. Cal destacar els beneficis que aquesta arquitectura ens proporciona, en separar el client del servidor. El principal benefici és el fet que, com s’espera un gran creixement del sistema HitMeApp, el fet de poder actualitzar-lo en cap moment dependrà de l’usuari. A més amb aquesta arquitectura s’aconsegueix una lògica més ben encapsulada dins de cada component, de manera que les responsabilitats del sistema queden molt clarament separades. El servei web tindrà com a funcionalitat processar les dades, i l’aplicació web per, únicament, consumir-les i presentar-les a l’usuari. Gràcies a aquesta arquitectura es podran afegir molts més casos d’ús en un futur, ja que el sistema és molt més escalable que si es trobés tot en un únic component. 4.1.2 Components i tecnologies usades Un cop queda clara la distribució física de tots els elements que conformaran el sistema desenvolupat, és hora de definir com serà l’estructura lògica que permetrà aconseguir que tota aquesta estructura física descrita pugui realment funcionar correctament. Per definir l’arquitectura lògica cal esmentar les tecnologies usades per tal de fer possible totes les funcionalitats del sistema. 48 4.2 Servei web Per al desenvolupament d’aquest servei web s’ha fet ús de la plataforma .NET Core del llenguatge C#  [13]  . Aquest és un llenguatge simple, fortament tipat i de propòsit general. A més, una característica bàsica per al desenvolupament d’aquest projecte és el fet que treballa amb el paradigma de programació orientada a objectes. Al marge del llenguatge, les principals tecnologies usades al servei web són: 4.2.1 API REST Aquest servei web és un sistema RESTful  , és a dir, una API REST  . Una API  no és més que una forma de descriure com els programes intercanvien dades, i en aquest cas el format d’intercanvi és json  . Algunes de les característiques principals que podem trobar en un sistema RESTful són: - La comunicació amb aquestes es realitza mitjançant d’un endpoint  . Aquest endpoint  es basa en una URI amb un format determinat, que estableix quina és la ruta del recurs de l'API Rest al qual es vol accedir. El format seria el següent: {protocol}://{nom del host}:{port}/{ruta del recurs}?{paràmetres de filtratge (opcional)} -Ús dels mètodes HTTP. Perquè sigui possible interactuar amb una API REST ens cal fer servir els mètodes HTTP: -POST: Per poder crear un nou recurs. -PUT: Per poder actualitzar un recurs ja existent. -GET: Obtenir la informació sobre un recurs. -DELETE: Eliminar un recurs -PATCH: Modificar un únic atribut d’un recurs. 49 -Resposta de les peticions. Després de manipular un recurs del servidor, aquest sempre haurà de retornar una resposta per tal d’indicar si l'operació que el client ha intentat realitzar s’ha efectuat de manera correcta o si s’ha produït alguna mena d’error. D’entre les respostes més comunes trobem que hi ha: -200 OK. La petició s’ha completat correctament -201 Created. La petició s’ha completat amb la creació d’un nou recurs. -400 Bad Request. La sol·licitud del recurs no té la sintaxi correcta. -403 Forbidden: La sol·licitud era correcta, però qui l’ha realitzat no disposa dels permisos adequats per a aquesta. -404 Not Found. No s’ha trobat el recurs sol·licitat. -500 Internal Server Error. Hi ha hagut un error intern en el servei per alguna excepció no controlada o un error de programació. Considerant el model de maduresa de Richardson REST, es pot concretar que aquest servei web es tracta d’una API Rest de nivell 2. Això és perquè fa ús d'HTTP per a les interaccions remotes (nivell 0), els recursos s’identifiquen a través d’una URI la qual no especifica l’acció a executar sobre el mateix recurs (nivell 1) i, com a últim aspecte, s’ha fet servir un ús correcte dels verbs i les seves respostes (nivell 2). El control de les respostes s’ha aconseguit gràcies a l’ús de filtres a la capa de serveis distribuïts, els quals capturen les excepcions llençades a la capa d’aplicació per així redirigir-les i tractar-les com a errors HTTP. 50 Pel que fa als endpoints  , que es poden cridar al servei web per poder consumir els seus recursos, són els següents: GET /api/categories -> Retorna totes les categories emmagatzemades al sistema. GET /api/events -> - Paràmetres de la consulta: categoryId  ->  Retorna els esdeveniments pertanyents a la categoria categoryId  . latitude  , longitude  -> Retorna els esdeveniments propers a les coordenades introduïdes. 4.2.2 Base de dades Trobem que, tal com s’ha vist a la imatge amb l’arquitectura física del sistema, el servei web connecta directament amb una base de dades pròpia. Aquesta emmagatzema les categories pròpies del sistema, aconseguides a partir de totes les categories extretes dels diferents sistemes d’esdeveniments, i agrupant-les quan fos possible. La base de dades ha sigut tractada amb SQL Server  , el qual realitza operacions sobre les dades mitjançant el llenguatge Transact SQL i l’accés a aquesta s’ha fet mitjançant entity framework  , el qual ofereix un accés a les dades molt simple i neta a nivell de codi. La base de dades es pot veure a la figura 4.2. 4.2.3 Control de versions Per poder disposar de les diferents versions de la base de dades a mesura que aquesta pogués anar augmentant, s’ha fet servir un control de versions mitjançant l’eina flyway  . Gràcies a aquesta es poden incloure nous fitxers, els quals representen una nova versió de la base de dades, i anar afegint noves versions sobre aquesta a mesura que cal modificar-la. 51 L’ús de flyway facilita molt la creació de la base de dades un cop s’ha de desplegar sobre el servidor, permetent a més poder recuperar una versió anterior funcional en cas que sorgeixi qualsevol problema amb l’actual. L’estructura de la base de dades del servei web té llavors la següent estructura en què es troba, a més de les taules normals del sistema, amb una taula que emmagatzema el versionat amb flyway. Figura 4.2: Base de dades del servei web En cas que vulguem actualitzar la base de dades a la versió més actual de la que es disposa, caldrà executar la comanda flyway migrate. Per comprovar que les migracions s’han realitzat correctament serà tan fàcil com introduir la comanda flyway info. Per poder veure com flyway funciona realment, a la següent imatge podem apreciar com la base de dades canvia en afegir una nova versió (continguda dins d’un fitxer .sql com es veu), i aquesta s’implementa amb la comanda migrate  anteriorment esmentada. 52 Figura 4.3: Representació de les versions amb flyway Imatge extreta de https://flywaydb.org/assets/balsamiq/command-migrate.png 4.2.4 Autofac Una de les característiques que han permès millorar el codi, amb l’aplicació dels principis explicats amb més detall a l’apartat d’implementació, ha sigut la injecció de dependències. Per aconseguir-la, i així desacoblar les diferents parts del codi, s’ha fet servir Autofac  , una eina amb la qual, mitjançant uns mòduls d’injecció, permet que totes les dependències del codi s’injectin en temps d’execució, és a dir, que en comptes d’instanciar cadascuna de les classes mitjançant les seves constructores, en comptes de fer ús de la instanciació tradicional mitjançant new  i el nom de la classe, només serà necessari afegir la classe al mòdul corresponent, i les seves constructores es cridaran automàticament un cop el programa s’executi. Figura 4.4: Exemple amb codi de com registrar un nou tipus dins d’un contenidor d’Autofac A la figura 4.4 es veu com l’atribut builder  , que es tracta d’un constructor de “contenidors”, està registrant el tipus CategoryServiceBl  , i ho fa mitjançant la seva interfície IRequestServiceBL<CategoryBl>  . 53 És d’aquesta manera com, sense cap mena d’instanciació abans de l’execució, serà possible que la classe de la següent imatge, la qual necessita l’objecte de la classe que es troba registrada al mòdul mostrat anteriorment, podrà obtenir aquest objecte. Figura 4.5: Exemple amb codi de la constructora de la classe CategoryController Això permet un gran aïllament de les dependències del codi (reduint l’acoblament a gran escala) així com la possibilitat de modificar el codi injectat en temps d’execució. 4.2.5 Automapper L’arquitectura utilitzada treballa amb diferents entitats a les diverses capes, les quals no són més que el model amb què es tracta a cada nivell de l’aplicació. Aquests models representaran un mateix concepte, tot i que aquest pot tenir certes diferències als diversos nivells. Perquè aquestes es puguin comunicar entre les diverses capes, és necessari que hi hagi un procés de mapeig, el qual consisteix a convertir i/o adaptar les dades d’una entitat a les pertanyents a la nova entitat amb la que es tracta al nivell actual, de manera que la informació sigui coherent i la corresponent per al determinat objecte. Per aquest motiu l’eina Automapper és de gran ajuda, ja que és l’encarregada de realitzar aquest procés. Primerament, és necessari crear un mapa que defineixi quins seran els models origen i destí d’aquest mapeig. En el cas de la següent imatge, veiem que un objecte Category serà mapejat a un de tipus CategoryBl  . 54 Figura 4.6: Codi d’exemple de la creació d’un mapa entre dues entitats amb AutoMapper Un cop establerta la configuració del mapeig, serà necessari crear un nou mapper, el qual permetrà realitzar aquesta operació de conversió d’una entitat a una altra, de la següent manera: Figura 4.7: Codi d’exemple del mapeig d’una entitat a una altra amb AutoMapper Com es pot veure, l’objecte categoryList  , el qual és del tipus List<Category>  , és mapejat amb la funció Map  , de manera que s’aconsegueixen portar aquestes dades cap a un objecte de tipus List<CategoryBl>  , que és la conversió que havíem preestablert en la primera imatge mitjançant la creació del mapa. D’aquesta manera veiem com s’aconsegueix la interacció de les diverses entitats dins de les capes del sistema. 55 4.3 Aplicació web El sistema, com a client del servei web, disposa d’una aplicació web, la qual s’encarrega de realitzar totes les peticions web al servei web implementat, de manera que sigui capaç de crear un contingut entenedor per a l’usuari i que a més, el treball realitzat amb aquest sigui capaç d’assolir els requisits especificats anteriorment. 4.3.1 Interfície La interfície de l’aplicació constarà d’una estructura simple i clara per tal de no convertir la interacció de l’usuari amb aquesta en una feina tediosa i que no li proporcioni de cap manera una bona experiència d’usuari. 4.3.1.1 Mockups D’aquesta manera la interfície presenta principalment quatre pantalles amb les quals s’aconseguirà realitzar de la millor manera les funcionalitats disponibles. Figura 4.8: Mockup de la pestanya Categories  de l’aplicació mòbil Figura 4.9: Mockup de la pestanya Events  de l’aplicació mòbil 56 L’aplicació consta de tres pestanyes, les quals són Categories  ,Events iRadar  . Aquestes queden molt més clarament definides amb l'anterior representació del disseny de l’app amb mockups  , a les figures 4.8 i 4.9. La figura 4.8 representa la pestanya Categories.  Tal com es pot veure, en aquesta pantalla mostra un llistat amb totes les categories disponibles actualment dins del sistema. A més cadascun dels elements d’aquesta llista, en fer clic, canvia la pestanya actual cap a Events  , on es mostraran els esdeveniments corresponents a la categoria en qüestió. Si observem a la figura 4.9, podem veure com és la pestanya Events  . En aquesta es mostren tots els esdeveniments que tindran lloc al voltant de l’àrea de l’usuari. Això ho fa mitjançant una petició al servei web, afegint les coordenades com a paràmetres, les quals són obtingudes mitjançant els sensors del telèfon mòbil. En aquesta l’usuari pot veure el títol, una imatge (si la té) i el principi de la descripció de l’esdeveniment concret. A més, si l’usuari clica sobre aquest, sobre una nova finestra sobreposada amb la qual s’afegeix funcionalitat de més respecte a l’esdeveniment. Aquesta és la imatge mostrada a la figura 4.10. En aquesta pantalla, directament es mostra l’esdeveniment original a l'usuari, amb tota la informació completa, i amb totes les funcionalitats que el mateix sistema que ha ofert l’esdeveniment ofereix. Finalment es disposa de la pestanya Radar  . Com es pot veure a la figura 4.11, aquesta mostra un seguit d’esdeveniments que estan succeint al voltant de l’usuari, però en comptes de mostrar-los en un llistat els mostra amb petits marcadors situats sobre un mapa, de manera que l’usuari pot clicar-lo per consultar de quin esdeveniment es tracta. 57 a la part de frontend  s’ha fet servir un llenguatge de programació i unes tecnologies completament diferents, tal com s’explica al capítol corresponent d’aplicació web. De tota manera, aquest client serà qui tingui la responsabilitat de la capa de presentació. Per entendre-ho millor, la capa de presentació és la responsable de mostrar tota la informació a l’usuari i, alhora, d’interpretar les accions d’aquest. Els components de la capa de presentació implementen la funcionalitat requerida per tal que els usuaris puguin interactuar amb el conjunt de capes inferiors que defineixen el comportament del sistema. Capa de Serveis Distribuïts En aquesta és on es contenen els controladors de categories i esdeveniments que reben les peticions, les quals seran tractades a altres capes per així poder retornar una resposta cap al client. Tant si una aplicació actua com a proveïdor de serveis per a altres aplicacions remotes, com seria el cas actual, com si la capa de presentació es troba físicament dins de la mateixa localització remota on s’ubica la part del backend del servei web, normalment es publica la lògica de negoci (referent a totes les capes de negoci, també considerades d’aplicació) mitjançant una capa de serveis distribuïts. Aquesta capa de serveis distribuïts és la que actua com a pont per poder accedir a les capes que defineixen la lògica de negoci. És important destacar que aquesta capa ha de ser el més lleugera possible i és per això que no inclou cap mena de lògica de negoci, sinó que simplement actua com a intermediària en la comunicació entre l’aplicació mòbil (que seria la part frontend  ) que vol consumir els serveis oferts, amb tota la lògica del backend  que es troba implementada a les capes de negoci. D’aquesta manera evitarem moltes de les males pràctiques que ens guien cap a una incorrecta assignació de responsabilitats dins de l’arquitectura, les quals acabarien derivant a incloure certs propòsits que no li pertanyen a aquesta capa. 64 Capa d’Aplicació Un nivell per sota de la capa de serveis distribuïts, trobem una connexió directa amb la capa d’aplicació. En aquesta es defineixen totes les tasques que l’aplicació com a tal ha de realitzar, de manera que s’encarrega de la redirecció de les entitats de les capes de domini i dels models de dades de la capa d’infraestructura per a la persistència de dades, ja que aquestes són directament les que s’encarreguen de resoldre totes les funcionalitats, al nivell més baix, de tota l’estructura. Això és degut al fet que aquesta la capa d’aplicació permet la comunicació entre les diferents capes que s’encarreguen de les operacions de persistència i accés a dades. És per això que podem considerar aquesta capa com l'encarregada de la coordinació entre les operacions de les capes de domini així com les de la capa d’infraestructura. Aquesta tasca de coordinació entre capes és la que explica que, la capa d'aplicació com a tal, no ha de disposar de cap mena de coneixement de les regles del domini, ni tan sols de la lògica del negoci, sinó que simplement s’ha d’encarregar de la realització de tasques de coordinació entre els diversos aspectes tecnològics de l’aplicació els quals seran d’un nivell de detall els quals no tindrien cap rellevància per a un expert del domini o usuari del negoci. Un aspecte interessant a incloure en aquesta capa és el workflow de negoci  . Aquest implicaria l’execució d’una sèrie de passos de manera que es produeixin certs esdeveniments al sistema d’una manera ordenada i sincronitzada, en la que aquests tenen una dependència entre ells, formant així fluxos de treball ordenats. Capa de Domini La capa de domini, també coneguda com a capa de negoci, és la que s’encarrega d’implementar les regles del domini. En aquesta es troba tota la comunicació amb els serveis a les aplicacions externes, així com el tractament d’aquestes, seguint les regles de negoci. Aquesta capa es troba aïllada completament de tots els detalls relacionats amb la persistència de dades. Els elements principals que podem trobar dins d’aquesta capa seran: 65 -Entitats del domini. Són els models els quals s’encarreguen de representar la informació que s’envia a través de les diferents capes. Però a més, seguint les normes que l’arquitectura imposa sobre aquesta capa, en aquesta es realitzaran certes operacions que tenen a veure amb la lògica pròpia del programa. Un cop s’han realitzat aquestes operacions, l'entitat resultant serà enviada a la capa d’aplicació perquè aquesta el tracti com es degui segons la funcionalitat del sistema. -Serveis del domini. A les capes del domini trobaríem els serveis, els quals s’encarreguen de recollir certs comportaments que tenen a veure amb la lògica de negoci directament, però que no tenen cap mena d’estat. És a dir que realitzen una funcionalitat al marge de la principal de negoci, però aquesta ha de ser tractada en aquest. Trobaríem que en el nostre sistema, els serveis seran aquests que permeten una interacció amb aplicacions d'esdeveniments externes. -Contractes dels repositoris. Tot i que aquesta classe no interactua directament amb els repositoris, pel fet que la persistència de dades no es tractarà en aquesta capa, els repositoris sí que accediran a aquesta per tal de poder consultar les interfícies a utilitzar. L’objectiu d'això és que el negoci sigui qui especifiqui tot el que es vol que els repositoris ofereixin, ja que d’una manera indirecta, aquesta capa els necessitarà. Capa d’infraestructura per a la persistència de dades Un cop arribat a aquesta capa és quan, tot i que no s’estableix cap de les regles del negoci ni del funcionament del sistema, s’aconsegueix realment interactuar amb les dades emmagatzemades per sistemes externs i que així tots els mètodes dels nivells superiors tinguin sentit. El principal és que aquesta connexió amb els sistemes de dades externs es realitzi d’una manera desacoblada a la resta de l’aplicació. En aquesta capa es troben totes les connexions directes a la base de dades, de manera que es puguin tant llegir com escriure les categories contingudes a la base de dades. A més, també es troben aquí tots els recursos que Entity Framework necessita per interactuar amb la base de dades, com el context de la base de dades i els models que fan relació a les taules d’aquesta. 66 Trobarem, com a classes principals, els Repositoris, que són classes encarregades de realitzar totes les operacions de persistència i accés a les dades, fent servir tant un ORM  , com directament ADO.NET per a interactuar amb el gestor de bases de dades en concret. A més l'accés a aquestes dades es realitzarà mitjançant una interfície la qual es troba definida als contractes de la capa de domini, la qual no es veurà afectada de cap manera per l'accés dels repositoris a aquesta, ja que no accedirien a res més que als contractes preestablerts. Aquest fet té molt de sentit tenint en compte que els repositoris no han de disposar de les regles de negoci dins la seva capa, encara que realment les funcionalitats a realitzar amb les dades depenguin d’aquestes. Dins d’aquesta capa trobem: -Els models de dades. Són explícitament una representació dels objectes continguts dins la base de dades, ja que serà amb aquests amb els que es farà un mapping  de la informació extreta d’aquesta i permetrà, en cas de fer servir un ORM, que les operacions de persistència de dades es realitzin de manera senzilla i quasi automàtica. -Agent de serveis externs. Tot i que no és obligatori que hi hagi cap. Aquests serveis externs a utilitzar són fàcilment confusibles amb els serveis de domini, però realment representen un concepte molt diferent dins del sistema. És decisió de l’arquitecte escollir com considerar un servei, i aquesta es basarà en la manera de tractar la informació d’aquest dins del sistema. Si les dades obtingudes no han de ser tractades i coincideixen amb el model de dates, llavors es podran considerar com a serveis externs del repositori. Altrament, hauran de ser tractades segons lògica del negoci a la capa de domini, com ha sigut en el cas d’aquest sistema. Capa d’infraestructura transversal Com el nom d’aquesta capa dóna a entendre, aquesta capa és accedida per totes les capes (exceptuant la de presentació, quan aquesta no es troba inclosa dins de la solució de l'aplicació backend, com és el cas actual). 67 En aquesta és on el nostre servei web disposa de tots els helpers  , els quals proporcionen certes funcionalitats comunes que resulten molt útils a tots els nivells del projecte, com facilitar llegir els fitxers de configuració, i que no tenen associada una lògica concreta de cap dels nivells. 5.1.2 Principis SOLID Un cop s’ha clarificat l’estructura, resulta molt més fàcil entendre com els principis SOLID s’han aplicat en les diferents parts del sistema. SOLID és un acrònim que fa referència a cinc principis bàsics de disseny de software que tenen com a objectiu que el codi produït sigui molt més comprensible, flexible i mantenible[21]. -Principi de responsabilitat única (Single responsability principle)  . Especifica que cadascun dels elements del codi ha de realitzar una única funcionalitat, evitant que hi hagi classes que realitzin tantes tasques que no es pugui entendre la intencionalitat d’aquesta. Aquest patró s’ha fet servir d’una manera clara amb la creació de diferents classes les quals, tot i complementar-se, tenien funcionalitats diferents i d’aquesta manera quedava molt clar l’objectiu de cadascuna. Aquest principi està aplicat molt clarament amb la creació d’un projecte encarregat de consumir els serveis dels sistemes d’esdeveniments, mentre que a través de la capa d’aplicació, hi ha una connexió amb la capa d’infraestructura per poder inserir les dades adequades a la base de dades. Com es pot veure, per un mateix procés com ho era l’emmagatzemament de les dades d’un servei extern a la base de dades s’han fet servir tres capes diferents, amb les seves classes i funcionalitats corresponents. -Principi d’obert/tancat (Open/closed principle)  . Les entitats han d’estar obertes a extensió, però tancades a modificació. És a dir, que el codi que ja està fet no s’hauria de modificar mai, i si es volguessin afegir noves característiques, mai sobreescriurien el codi prèviament existent. Aquest principi queda molt clar quan, mitjançant l’ús de la interfície de repositori, la qual és genèrica (permet funcionar amb el tipus d’objecte definit en la declaració de la 68 classe), és molt fàcil poder afegir nous repositoris per a nous elements que poguessin tractar-se, sense haver de modificar el codi dels repositoris ja existents. Figura 5.3: Codi d’exemple de la implementació d’un repository usant genèrics. Com es veu a la declaració de la classe, és de tipus IRepository amb el tipus de la classe a tractar. D'aquesta manera si es volgués implementar alguna nova funcionalitat sobre un nou tipus d’objecte, en comptes de modificar la classe CategoryRepository només caldrà crear un nou repositori al qual li definirem el tipus a tractar a la interfície. El codi es pot estendre llavors, sense necessitat de canviar el que ja està creat. -Principi de substitució de Liskov (Liskov substitution principle)  . Aquest principi diu que les classes que hereten d’una altra mai haurien de trencar les definicions de la classe pare. D’aquesta manera una classe sempre haurà de ser substituïble per la classe pare. En el cas d’aquest sistema no ha sigut necessari que cap classe hereti d’una altra, però es dóna el cas que una interfície deriva d’una altra, de manera que un objecte que la implementa serà completament substituïble per un que només implementa la interfície para. Tot i això, es mostrarà un exemple més concret amb l’explicació del següent principi, el qual té molta més relació amb aquest. -Principi de segregació d’interfícies (Interface segregation principle)  .Aquest principi estableix que cap client ha de ser forçat a dependre de mètodes que no utilitza. És per aquest motiu que, per evitar que un client implementi d’una interfície molt general i amb molts mètodes, els quals quedaran buits en molts dels casos, és molt millor separar aquests mètodes en diverses interfícies, per això només implementar les que s’adeqüin a les funcionalitats requerides. 69 A més, com a punt afegit, per aconseguir que cada classe només implementi una interfície, però alhora es pugui complir aquest principi, la interfície que aquesta classe implementa no té cap mètode propi, sinó que és un conjunt d’interfícies que defineixen exactament les funcionalitats requerides per a aquest cas concret, com es pot veure a la imatge següent: Figura 5.4: Codi d’exemple de la implementació de diverses interfícies en una altra. Les classes que heretin de IRepository<T> llavors, disposaran de les funcionalitats de les interfícies que aquesta implementa. D’aquesta manera, si es donés el cas que una classe no les requereix totes, podria crear una interfície a mesura, únicament implementant les funcions que realment li caldrà definir. -Principi d’inversió de dependències (Dependency inversion principle)  . Com a últim dels principis SOLID i un dels més rellevants, es troba la inversió de dependències. Aquest principi té com a objectiu principal aconseguir desacoblar tots els mòduls de software, de manera que els fa molt més independents entre si[22]. Per què els mòduls d’alts nivells puguin comunicar-se amb els mòduls de nivells més baixos sense dependre d’aquests, ambdós hauran de dependre d'abstraccions. Una abstracció consisteix a aïllar un element del seu context o de la resta d'elements que l’acompanyen. Això, en aquest sistema, s’ha aconseguit amb l’ús d’Autofac  , com s’ha esmentat a l’apartat de disseny, amb el que s’ha realitzat una injecció de les dependències. El fort acoblament s’ha eliminat, ja que mai es realitza una nova instància de cap dels objectes, sinó que a la capa de distributed services s’ha realitzat la injecció de mòduls que s’ha realitzat només iniciar el servei web. 70 Figura 5.5: Codi d’exemple de la configuració de diversos mòduls amb AutoFac 5.1.3 Patrons i principis aplicats -Separació d’interessos (Separation of concerns, SoC)  . Aquest principi ens diu que per tenir cohesió  , caldrà que tot el codi que és similar o totes les funcions fortament relacionades hauran de ser agrupades conjuntament[23]. En el de cas de la programació en .NET, tal com s’ha fet per a aquest sistema, aquests termes similar s’han d’agrupar en diferents projectes. -Baix acoblament. Continuant amb el principi anterior, cada projecte ha de ser el més autònom possible. Cada peça de codi ha de tenir una interfície clara i un abast de treball que molt difícilment canviarà, sempre que les altres classes relacionades no canviïn la funcionalitat que realitzen. -Patró repositori. Per a l'accés de dades, a l'haver-se fet mitjançant Entity Framework  , es poden utilitzar els recursos que aquest ofereix[24]. Aquest bàsicament tracta de, tal com marca l’arquitectura DDD[25], crear una capa per als repositoris, de manera que aquesta només s’encarregui de la comunicació del codi c# amb el transact SQL de la 71 nostra base de dades. Per aconseguir passar fàcilment la informació de la base de dades en objectes de la nostra aplicació, el que s’ha fet és bàsicament crear uns objectes els quals mapejaran la informació de la base de dades de manera simple, així al sistema serà molt fàcil tractar amb aquestes dades un cop han estat mapejades. Figura 5.6: Codi d’exemple de l’ús de LINQ  sobre la lectura de categories de la base de dades amb Entity Framework  . - A més com es pot veure a la imatge anterior, als repositoris es pot aplicar aquest patró mitjançant LINQ (Language INtegrated Query)  , es permeten realitzar moltes funcionalitats similars a les de l’sql, pero dins d’entorns de programació .NET sobre qualsevol objecte que implementi la interfície IEnumerable (així com ho són les col·leccions i arrays). Figura 5.7: Codi d’exemple de la capa d’Aplicació realitzant una crida sobre la capa d’infraestructura amb persistència de dades 72 - Patró Active Records. Aquest és un patró implícit directament amb l’ús de l’arquitectura DDD usada, pel simple fet d’emmagatzemar certes dades de l’aplicació en una base de dades relacional[26]. Aquest patró s’usa per a la persistència d’objectes de manera que un objecte està vinculat a una taula de la base de dades, així que aquest dos estan vinculats i si hi ha cap canvi sobre l’objecte, aquest canvi s’haurà de veure reflectit a la base de dades. 73 Figura 5.12. Connexió d’un component al contenidor d’estat Un cop carregades les categories en memòria, les quals ja es podran veure en un llistat sobre l’aplicació, es podrà fer clic sobre aquestes, de manera que això realitzarà una altra crida sobre el servei web, obtenint esdeveniments pertanyents a la categoria seleccionada. Aquests esdeveniments obtinguts del nostre servidor, a més, també es guardaran dins la memòria del navegador, en el contenidor d’estat global. Si ens desplacem a la pestanya del mapa, es realitza una altra crida al servei web, amb el mateix funcionament que amb la mostra d’esdeveniments ja explicada anteriorment, amb la diferència que aquest cop es mostren tan sols els esdeveniments propers a la nostra localització del dispositiu mòbil. 80 5.3 Temps dedicat A la següent taula es pot veure quin ha sigut el temps final dedicat a cadascuna de les tasques indicades a l’informe inicial de GEP, excloent l'última tasca de preparació de la defensa. Codi Tasca Temps dedicat T1 Gestió inicial 50 T2 Documentació 90 T3 Investigació APIs 50 T4 Creació servei web 150 T5 Creació APP 100 T6 Proves finals 70 T7 Preparació de la defensa 30 h TOTAL 540 h Figura 2.2 Taula amb les hores dedicades a cada una de les tasques Com es pot observar, el temps final dedicat ha sigut molt superior, en especial en els apartats de documentació, investigació de les APIs externes i la creació del servei web. Això ha sigut degut al fet que l’enfocament del projecte va ser modificat, de manera que es va donar una major importància al servei web en comptes de la funcionalitat oferta a l’aplicació web com a tal, de manera que tota la nova informació adquirida per a poder aplicar l’arquitectura esmentada, així com el compliment dels principis de disseny software han comportat un augment de temps molt significatiu. Aquest canvi ha comportat que, a més d’un replantejament complet respecte a la manera de programar el servei web, tant pel que fa a l’arquitectura d’aquest com al llenguatge escollit en un principi per tal de poder aconseguir un resultat molt més satisfactori. La documentació també ha comportat més temps, ja que en haver-se anat realitzant a mesura que s’anava avançant amb el projecte, el qual va patir certs canvis de rumb, els quals van comportar que aquesta documentació anés variant constantment durant el període de creació de servei web. 81 6 Validació Per a la validació dels requisits no funcionals, s’han usat els criteris de satisfacció especificats a l’apartat de requisits no funcionals. Les proves realitzades han sigut amb potencials usuaris, que han provat l’aplicació per tal de verificar que complien els requisits establerts prèviament. Més concretament han valorat l’aspecte final de l’aplicació mòbil, que és el que es pot veure a les següents imatges: Figura 6.1: Captura de pantalla de la pestanya Categories  de l’aplicació mòbil Figura 6.2: Captura de pantalla de la informació d’un dels esdeveniments l’aplicació mòbil Figura 6.2: Captura de pantalla de la pestanya Radar  de l’aplicació mòbil Un cop els usuaris han usat l’aplicació han aconseguit entendre-la quasi immediatament, a causa del fet que l’aspecte d’aquesta els ha resultat molt fàcil i intuïtiu. 82 6.1 Testing Pel que fa a la validació dels requisits funcionals, s’ha realitzat mitjançant testing  . El tipus de testing realitzat han sigut proves automatitzades mitjançant el framework MSUnit  . Aquest només s’ha realitzat sobre les classes del nivell d’infraestructura. He escollit realitzar aquest tipus de testing, ja que el fet d’usar-los ofereix un resultat confiable, de manera que el resultat serà segur de manera independent a qualsevol condició externa al sistema. Figura 6.4: Diferents tests realitzats sobre el servei web. El testing realitzat ha sigut tan sobre connexió amb els serveis d’esdeveniments, comprovant que la informació obtinguda, un cop mapejada, era la correcta, així com sobre l’accés a les dades, tant la lectura com l’escriptura d’aquestes. S’ha de tenir en compte que per als tests, com en el codi de producció, s’ha fet ús d’injecció de dependències, de manera que tampoc tenen cap mena de dependència externa i així imiten de la millor manera el comportament del programa en funcionament. 6.1.1 Tests unitaris Els tests unitaris tenen com a objectiu provar el comportament d’una classe únicament, sense importar si la resta de classes de les quals aquesta pot dependre funcionen o no. Per a aconseguir-ho, ha calgut fer ús de mocking per simular el comportament de les seves dependències amb la base de dades o els serveis externs. El paquet utilitzat per a fer el moqueig s’anomena Moq  . 83 El mocking es realitza automàticament, de manera que amb la factoria Automock es crea el mock en temps d’execució, emulant exactament el comportament de les dependències injectades. La primera regla dels tests unitaris fets és la creació de l’objecte x  , el qual és l'encarregat de fer servir el repositori adequat per al model concret que s’està testejant. Després d'aquest pas, el moqueig es realitza normalment, com qualsevol altre que no fa ús de la injecció de dependències, en el que s’hauria d’aconseguir el valor preestablert en la definició d’aquest. Figura 6.5: Codi d’exemple d’un test unitari amb injecció de dependències fent servir un Mock  . Finalment, com s’observa a la imatge anterior, només caldrà comparar el resultat obtingut amb l’esperat. Com es pot veure, la principal diferència amb un moqueig normal és la funció AutoMock.GetLoose()  la qual retorna l’objecte mock injectat, en comptes de ser instanciat. 6.1.2 Integration Tests Amb els tests d’integració he pogut provar que el comportament d’una classe, juntament amb el de les seves dependències, era l’esperat. A la següent imatge es pot veure la funció SetUp  , la qual prepara l’entorn per als tests, buidant la base de dades i creant objectes per a ser inserits. El test mostrat prova que la inserció dels elements es realitza correctament. 84 A l'executar-se abans de cada mètode de test, és una bona manera d’aprofitar codi, que a més és molt fàcilment llegible. Figura 6.6: Codi d’exemple amb la preparació dels tests i un test d’integració. Per a la realització dels tests d’integració, per no trencar amb els principis Open-Closed ni Dependence inversion  , comentats anteriorment, s’ha hagut de crear una nova classe, de la qual cadascun dels tests d’integració ha hagut d’heretar. Figura 6.7: Codi d’exemple amb la capçalera d’un test que fa ús de la injecció de dependencies. Aquesta classe és la que podem veure a la imatge anterior, anomenada IoCSupportedTest  , la qual té com a característica el fet de ser genèrica. És per això que podem indicar-li el seu tipus, 85 el qual correspon al mòdul corresponent a tractar, de manera que no cal modificar-la a raó del mòdul a fer servir. A la imatge següent es mostra com, gràcies a la classe esmentada, es realitzaria la injecció de la classe desitjada, per així no haver-la d’instanciar. Figura 6.8: Codi d’exemple amb la crida de la funció que instancia una classe en temps d’execució als tests d’integració. Per crear una independència completa sobre la resta de components de les diferents capes, el mòdul usat per a cadascun dels tests és bàsicament un nou mòdul contingut dins del projecte de test. D’aquesta manera els tests funcionen sense dependre de cap altre nivell dins del codi. L'estructura seguida és la mostrada en la següent imatge. Figura 6.9: Codi d’exemple amb la estructura dels mòduls dins dels projectes de test. 86 7 Integració de coneixement 7.1 Coneixements aplicats Al llarg de la realització del meu treball he aplicat els següents coneixements obtinguts de les matèries d’especialitat: -Arquitectura del Software (AS). M’ha servit per poder entendre i aplicar l’arquitectura en capes DDD, ser capaç d’identificar i fer ús de certs patrons de disseny i poder conèixer el funcionament de TDD. -Aplicacions i Serveis Web (ASW). Per treballar amb el paradigma client-servidor, així com el desenvolupament d’una API REST. -Disseny de Bases de Dades (DBD). Per dissenyar i desenvolupar la base de dades del sistema. -Enginyeria de Requisits (ER). Aplicat en l'especificació dels requisits funcionals i no funcionals, així com en la planificació i utilització de la informació analitzada al principi d’aquest treball. -Gestió de Projectes de Software (GPS). Ús de les diverses metodologies àgils així com de certes eines de desenvolupament per millorar la qualitat del treball realitzat. -Projecte d’Enginyeria del Software (PES): Pel que fa al desenvolupament d’un projecte de software en un entorn professional, fent ús de diverses tecnologies. 7.2 Assoliment de competències CES1.2: Donar solució a problemes d'integració en funció de les estratègies, dels estàndards i de les tecnologies disponibles. Aquesta competència suposa una de les principals, pel fet que s’han hagut d’avaluar molt aspectes referents a les solucions software disponibles, així com dels recursos de programació 87 ja existents a l’hora d’avaluar si era possible realitzar un sistema que pogués complir els objectius desitjats. CES1.3: Identificar, avaluar i gestionar els riscos potencials associats a la construcció de software que es poguessin presentar. Ha calgut tenir en compte els diversos problemes que podien sorgir des d’un primer moment, tot i que la majoria anaven a suposar una inversió superior pel que fa al temps d’aprenentatge, però així i tot cap suposava un impediment a l’hora de finalitzar el projecte. CES1.4: Desenvolupar, mantenir i avaluar serveis i aplicacions distribuïdes amb suport de xarxa. Aquest coneixement suposa la base del sistema, ja que és el punt principal del software creat, el qual es basa en l’ús d’aplicacions distribuïdes en xarxa, que derivarien en la creació d’una pròpia. CES1.7: Controlar la qualitat i dissenyar proves en la producció de software. El control de la qualitat del software s’ha portat a terme gràcies a certes eines que han permès el versionatge i les proves end-to-end manuals. Així i tot el punt principal de control de qualitat han sigut els tests tant unitaris com d’integració que s’han implementat arreu del projecte. CES2.1: Definir i gestionar els requisits d'un sistema software. Ha sigut necessari tenir una visió clara del sistema que es volia a crear, per així poder, utilitzant les millor pràctiques, definir els seus requisits i la manera d’implementar-los complint els requisits de qualitat establerts. CES2.2: Dissenyar solucions apropiades en un o més dominis d'aplicació, utilitzant mètodes d'enginyeria del software que integrin aspectes ètics, socials, legals i econòmics. El sistema en si tracta un aspecte molt social, de manera que, al marge del servei web, el fet d’haver creat una aplicació mòbil permet als usuaris accedir a les funcionalitats ofertes, les quals poden suposar un canvi en el seu entorn social. 88 8 Conclusions En aquest treball de final de grau he proposat la creació d’un sistema per a facilitar la interacció dels usuaris entre ells promovent certs sistemes d’esdeveniments. Els objectius han estat aconseguits gràcies a la creació d’un servei web, el qual s’ha pogut provar amb una aplicació mòbil per a Android com a client. 8.1 Assoliment d’objectius A continuació es mostren resumits els objectius establerts al capítol 1.4, per tal de determinar com s’han complert. ● Crear una aplicació web orientada a l’ús des d’un dispositiu mòbil. Objectiu complert gràcies a la creació del servei web i de l’aplicació web, per així aconseguir un sistema funcional. El tipus de disseny a l’aplicació web és el que mostra com, òbviament, aquesta ha estat dissenyada per a ser usada en dispositius mòbils. ● Permetre que els usuaris puguin interactuar amb d’aquests esdeveniments. L’aplicació web és la interfície entre l’usuari i el servei web, i aquest servei web interacciona directament amb les aplicacions d’esdeveniments externs, de manera que el sistema HitMeApp permet aquesta interacció. ● Filtrar esdeveniments. Com s’ha vist anteriorment, els usuaris poden filtrar els esdeveniments tant a partir de la categoria d’aquests, com la localització segons un mapa. ● Qualitat en el codi. Un cop analitzat el sistema creat hem vist com, especialment al servei web, s’ha fet servir una arquitectura robusta, amb diversos mètodes que han afavorit l’aplicació dels principis SOLID, els quals garanteixen una bona qualitat en el codi desenvolupat. 89 Mockups: Un model del disseny gràfic d’un sistema, imitant o orientant l’esperat finalment. ORM: Acrònim del terme anglès Object-relational mapping, el qual és una tècnica per aconseguit convertir dades entre tipus de sistemes incompatibles, mitjançant la programació orientada a objectes. Project manager: Persona encarregada de dirigir el projecte per així garantir el compliment de les dates en la realització d’un projecte. REST: Acrònim del terme anglès Representational State Transfer, el qual fa referència a un estil d’arquitectura software que defineix una sèrie de condicions a usar a l’hora de crear serveis web. RESTful: Propietat dels sistemes REST. Single Page Application: Terme que fa referència a totes aquelles pàgines web que interactuen amb l’usuari amb el simple fet de recarregar la mateixa pàgina actual en comptes de portar-ne una nova cada cop des del servidor. Stakeholders: Grups de persones que poden afectar o que són afectats per les activitats d’una empresa. Tester: Persona encarregada de realitzar el testing d’un programa. Testing: Acte de realitzar diverses proves sobre el codi per així poder verificar el correcte funcionament d’aquest. Transpilar: Procés de conversió d’un codi a un altre del seu mateix nivell d’abstracció perquè així pugui ser interpretat per altres sistemes. URI: Acrònim del terme anglès Uniform Resource Identifier, el qual fa referència a una cadena de caràcters que identifica un recurs en particular. JavaScript: Un llenguatge de programació utilitzat habitualment per a crear efectes interactius als navegadors web. JSX: És una sintaxi usada per React, la qual estén de ECMAScript, de manera que es pot usar la sintaxi HTML juntament amb la sintaxi JavaScript. 96 97