ENGINYERIA DEL SOFTWARE II - UdGima.udg.edu/~sellares/EINF-ES2/Present1112/FinalPhoto... · 2012....
105
1 ENGINYERIA DEL SOFTWARE II Memòria del projecte Photo Trip Jordi Cazorla Riera Eduard Rando Segura Ivan Rando Segura Pau Xiberta i Armengol 18/05/2012
Transcript of ENGINYERIA DEL SOFTWARE II - UdGima.udg.edu/~sellares/EINF-ES2/Present1112/FinalPhoto... · 2012....
1
ENGINYERIA DEL SOFTWARE II
Memòria del projecte
Photo Trip
Jordi Cazorla Riera
Eduard Rando Segura
Ivan Rando Segura
Pau Xiberta i Armengol
18/05/2012
2
Í ndex
1. Pla de projecte ............................................................................ 6 1.1. Introducció, motivació i objectius .......................................................... 6
1.2. Tasques ............................................................................................................. 7 1.2.1. Pla de projecte ............................................................................................................ 7
1.2.2. Requeriments ............................................................................................................. 7
1.2.3. Anàlisi ............................................................................................................................ 7
1.2.4. Disseny .......................................................................................................................... 7
1.2.5. Prototipatge ................................................................................................................ 7
1.2.6. Documentació ............................................................................................................. 8
1.3. Metodologia .................................................................................................... 8
1.4. Recursos humans .......................................................................................... 8
1.5. Software ............................................................................................................ 9 1.5.1. Dropbox ........................................................................................................................ 9
1.5.2. Microsoft Office ....................................................................................................... 10
1.5.3. Visual Paradigm for UML .................................................................................... 10
1.6. Temporització ............................................................................................. 10
1.7. Viabilitat ........................................................................................................ 13 1.7.1. Costos .......................................................................................................................... 13
1.7.2. Ingressos ................................................................................................................... 13
2. Revisió del pla de projecte .................................................. 15 2.1. Temporització ............................................................................................. 15
3. Requeriments del sistema ................................................... 17 3.1. Introducció ................................................................................................... 17
3.1.1. Conceptes .................................................................................................................. 17
3.1.2. Països, regions, sub-regions i indrets ............................................................ 17
3.1.3. Fotografies dels indrets ....................................................................................... 18
3.1.4. Tipus d’usuari .......................................................................................................... 18
3.2. Requeriments funcionals ........................................................................ 19 3.2.1. Usuari principiant .................................................................................................. 19
3.2.1.1. Registrar-se.................................................................................................................. 19
3.2.1.2. Mostrar regió .............................................................................................................. 19
3.2.1.3. Obtenció dels Indrets ............................................................................................... 19
3.2.1.4. Mostrar Indret ............................................................................................................ 20
3.2.1.5. Cercar Indret ............................................................................................................... 20
3.2.1.6. Obtenir itinerari ......................................................................................................... 20
3.2.1.7. Validació de la fotografia ........................................................................................ 20
3.2.1.8. Puntuació ...................................................................................................................... 20
3.2.1.9. Classificació d’usuaris .............................................................................................. 21
3
3.2.1.10. Incidències ................................................................................................................... 21
3.2.1.11. Informació de fotografies ....................................................................................... 21
3.2.1.12. Àlbum de fotografies ................................................................................................ 21
3.2.1.13. Llista d’amistats ......................................................................................................... 21
3.2.1.14. Publicar fotografia al Facebook ............................................................................ 21
3.2.2. Usuari expert ........................................................................................................... 22
3.2.2.1. Crear itinerari ............................................................................................................. 22
3.2.2.2. Suggeriments .............................................................................................................. 22
3.2.3. Administrador ......................................................................................................... 23
3.2.3.1. Gestió d’usuaris .......................................................................................................... 23
3.2.3.2. Gestió d’indrets .......................................................................................................... 23
3.2.3.3. Gestió de suggeriments ........................................................................................... 23
3.2.3.4. Gestió d’incidències .................................................................................................. 23
3.2.3.5. Estadístiques ............................................................................................................... 23
3.3. Requeriments no funcionals ................................................................. 24
4. Anàlisi ......................................................................................... 27 4.1. Diagrama de casos d’ús general ........................................................... 28
4.2. Diagrama de casos d’ús: Part Administrador ................................. 29
4.3. Diagrama de casos d’ús: Part Amics Usuari .................................... 30
4.4. Diagrama de casos d’ús: Part Classificació ...................................... 31
4.5. Fitxes de cas d’ús ....................................................................................... 32 4.5.1. Registrar-se .............................................................................................................. 33
4.5.2. Mostrar indret ......................................................................................................... 34
4.5.3. Cercar indret ............................................................................................................ 35
4.5.4. Enviar incidència .................................................................................................... 35
4.5.5. Fer fotografia ........................................................................................................... 36
4.5.6. Veure informació indret ...................................................................................... 36
4.5.7. Veure incidència ..................................................................................................... 37
4.5.8. Veure estadístiques ............................................................................................... 38
4.5.9. Afegir amic ................................................................................................................ 38
4.5.10. Eliminar amic ........................................................................................................... 39
4.5.11. Validar fotografia ................................................................................................... 40
4.5.12. Crear itinerari .......................................................................................................... 41
4.5.13. Generació automàtica d’itinerari ..................................................................... 41
4.5.14. Veure classificació global i tots......................................................................... 42
4.5.15. Veure classificació global i amics..................................................................... 42
4.5.16. Veure classificació països i tots ........................................................................ 43
4.5.17. Veure classificació països i amics .................................................................... 44
4.5.18. Suggerir indret ........................................................................................................ 45
4.5.19. Mostrar itinerari ..................................................................................................... 45
4.5.20. Mostrar llista d’amics ........................................................................................... 46
4.5.21. Afegir usuari ............................................................................................................. 46
4.5.22. Inhabilitar usuari ................................................................................................... 47
4
4.5.23. Afegir indret ............................................................................................................. 47
4.5.24. Eliminar indret ........................................................................................................ 48
4.6. Diagrama d’activitat ................................................................................. 49 4.6.1. Mostrar itinerari ..................................................................................................... 49
4.7. Diagrames de seqüència ......................................................................... 50 4.7.1. Afegir amic ................................................................................................................ 51
4.7.2. Crear indret .............................................................................................................. 52
4.7.3. Mostrar indret ......................................................................................................... 53
4.7.4. Validar fotografia ................................................................................................... 54
4.7.5. Veure classificació global i tots......................................................................... 55
4.7.6. Veure incidència ..................................................................................................... 56
4.7.7. Veure estadístiques ............................................................................................... 57
4.8. Diagrama de classes inicial .................................................................... 59
5. Disseny ....................................................................................... 60 5.1. Patrons ........................................................................................................... 61
5.1.1. Patró Composite ...................................................................................................... 61
5.1.2. Patró Strategy .......................................................................................................... 62
5.1.3. Patró Singleton ........................................................................................................ 64
5.1.4. Altres patrons .......................................................................................................... 65
5.2. Diagrama de classes amb patrons ...................................................... 66
5.3. Restriccions OCL ........................................................................................ 67
5.4. Diagrama de classes final ....................................................................... 69
5.5. Model relacional ......................................................................................... 71 5.5.1. Taules .......................................................................................................................... 71
5.5.2. Diagrama entitat-relació ..................................................................................... 72
6. Prototipatge .............................................................................. 73 6.1. Icona ................................................................................................................ 73
6.2. Pantalla inicial ............................................................................................. 73
6.3. Seleccionar indret ...................................................................................... 74 6.3.1. Llista d’indrets ........................................................................................................ 75
6.3.2. Seleccionar indret concret ................................................................................. 76
6.4. Validar fotografia ....................................................................................... 76
6.5. Classificació .................................................................................................. 77 6.5.1. Classificació global i tots ..................................................................................... 77
6.5.2. Classificació global i amics ................................................................................. 78
6.5.3. Classificació països i tots ..................................................................................... 79
6.5.4. Classificació països i amics ................................................................................. 80
6.6. Gestió d’amics ............................................................................................. 80
6.7. Àlbum de fotografies ................................................................................ 81
6.8. Itineraris ........................................................................................................ 83
5
6.9. Suggeriments ............................................................................................... 85
Annex I: Reunions realitzades ................................................. 86
Annex II: Generació automàtica d’itineraris ....................... 88 A2.1. Introducció ................................................................................................. 88
A2.2. Circular Range Searching ..................................................................... 88
A2.3. Disk/ball Range Searching Queries ................................................... 90 A2.3.1. Range counting ..................................................................................................... 91
A2.3.2. Range reporting ................................................................................................... 91
A2.3.3. Anàlisi de complexitat ....................................................................................... 92
A2.4. Conclusions ................................................................................................ 92
Annex III: Manual d’usuari ........................................................ 93 A3.1. Ínici de l’aplicació .................................................................................... 93
A3.2. Funcionalitats bàsiques de l’aplicació ............................................ 93
A3.3. Mapamundi ................................................................................................ 94 A3.3.1. Seleccionar país ................................................................................................... 94
A3.3.2. Seleccionar indret ............................................................................................... 95
A3.3.3. Fotografiar indret ............................................................................................... 95
A3.4. Classificació ............................................................................................... 96
A3.5. Amistats ...................................................................................................... 98
A3.6. Àlbum de fotografies ........................................................................... 100
A3.7. Itineraris .................................................................................................. 101
A3.8. Suggeriments ......................................................................................... 104
Annex IV: Control d’hores ........................................................ 105
6
1. Pla de projecte
En aquest document es recull el disseny d’un projecte sobre una aplicació mòbil
que ens permetrà saber quin percentatge de països d’arreu del món hem visitat.
L’aplicació està pensada com un joc per competir amb altres usuaris.
1.1. Introducció, motivació i objectius
Aquest projecte neix de la idea de crear una aplicació per a mòbils o smartphones.
Seguint aquesta idea, els membres del grup vam iniciar una pluja d’idees donant com a
resultat diferents propostes encarades en aquest àmbit, el de les aplicacions per a
dispositius mòbils.
Un cop obtingudes les diferents propostes, vam comentar-les i debatre-les fins que,
amb el consentiment de cadascú, vam arribar a reduir-les a dues. La primera d’aquestes
era quelcom força semblant al que avui coneixem com a la “cronologia” de la xarxa social
Facebook. Precisament aquest motiu, el fet de mantenir aquesta semblança, ens va acabar
de convèncer per descartar-la, de manera que vam aconseguir quedar-nos amb una única
proposta.
Aquesta proposta final consisteix en una aplicació que pretén motivar els seus
usuaris a recórrer el món. La manera escollida per moure’s i viatjar a tots els indrets es
caracteritza per intentar fotografiar certs llocs emblemàtics escampats arreu del planeta
que estaran inclosos a l’aplicació, obtenint al mateix temps una determinada puntuació per
a cada indret. Així, un usuari de l’aplicació podrà consultar els punts que ha obtingut i el
percentatge d’indrets visitats per fer-se una idea de la seva virtut de viatjant.
A més a més, aquesta aplicació no abandona del tot la connotació de xarxa social
que tenia la primera proposta, i podrà permetre als usuaris buscar i afegir altres usuaris
amics a la seva aplicació per saber-ne la seva puntuació o percentatge, reforçant així
l’esperit competitiu.
És per això que el nostre objectiu serà proporcionar als usuaris de les aplicacions
mòbils una eina d’entreteniment que els permetrà poder veure diferents llocs del món, a la
vegada que podran crear diferents rutes d’indrets i compartir-les, tal com si organitzessin
un pla de viatge.
En aquest document però, tot i que el nostre projecte es focalitzarà en poder
assolir l’objectiu que hem descrit, també ens dedicarem a crear una planificació adequada
tot dividint les tasques a realitzar. A més, el seguiment d’una determinada metodologia,
entendre bé els rols de cadascú, encara que en determinats moments no se segueixin al
peu de la lletra, saber quin software emprar, i la realització d’un correcte i alhora profund
anàlisi i disseny, seran part imprescindible en el nostre projecte.
7
1.2. Tasques
Dividirem el pla de projecte en diferents parts. Aquestes parts, que anomenarem
fases, es troben explicades a continuació.
1.2.1. Pla de projecte
Consisteix en l’elaboració d'un full de ruta a seguir durant el projecte. Es tracta
d’una guia, de manera que el seu seguiment no serà estricte i es podrà veure modificat al
llarg de l’elaboració de la nostra aplicació.
1.2.2. Requeriments
Tot i que la primera fase real de l'aplicació és l'elaboració del pla de projecte, en
tractar-se d’un full de ruta, podem considerar que la fase de requeriments és la inicial.
Així doncs, en aquesta primera fase es treballarà en la definició dels requeriments,
els quals ens indicaran quines seran les tasques que haurà de realitzar la nostra aplicació,
és a dir, cadascuna de les seves funcionalitats, ja siguin funcionals o no funcionals.
1.2.3. Anàlisi
La següent tasca que durem a terme serà la part del projecte que ens permetrà
poder comprendre d'una manera més clara i precisa cadascuna de les necessitats del
nostre sistema. Per tant, la feina que caldrà realitzar en aquest sentit serà especificar més
clarament els requeriments anteriors alhora que comencem a definir quines seran les
classes que intervindran a la nostra aplicació, de la mateixa manera que haurem
d’especificar els diagrames d'interacció amb l'usuari. Tots aquests diagrames estaran
modelats amb UML.
1.2.4. Disseny
En aquesta tercera fase, la de disseny, ens centrarem en l'especificació del
programari mirant d'adaptar la documentació creada a la fase d'anàlisi per poder-la
encarar a la implementació final del sistema.
1.2.5. Prototipatge
El projecte que desenvolupem en aquest document es basa únicament en
l’elaboració correcta de les fases anteriors, deixant de banda així la part de programació.
És per aquest motiu que, en comptes d’implementar la nostra aplicació, intentarem
substituir aquesta part amb la creació d’un conjunt d'imatges o prototipus representatius
per poder fer-nos una idea a simple vista de com estarà estructurada, a nivell d'interfície,
la nostra aplicació.
8
1.2.6. Documentació
Aquesta darrera part ens serà útil per detallar cadascuna de les parts del projecte
en què haurem treballat durant la seva elaboració. Tot i tractar-se d’una feina feixuga i que
pot reservar-se fàcilment pel final, intentarem anar-la duent a terme a mesura que anem
avançant entre les fases del projecte, aprofitant que tindrem els conceptes més clars i
aconseguint una reducció important en l’acumulació de feina al tram final.
1.3. Metodologia
En aquest apartat comentarem quina metodologia hem emprat durant la
realització del nostre projecte. Per escollir-ne una, després de saber com s’estructuraria el
projecte, ens vam reunir per pensar quins serien els millors mètodes a seguir per poder
optimitzar recursos i temps.
D’aquesta manera, un cop definits els requeriments del sistema, vam creure que la
metodologia que millor s’adequava a l’elaboració del nostre projecte era el seguiment d’un
procés iteratiu incremental. Això significa que, a mesura que anàvem evolucionant la
nostra aplicació, també avançàvem a través de l’anàlisi i el disseny, i en el cas que topéssim
amb alguns errors o aspectes a modificar, retornàvem a punts anteriors per tornar a
construir amb les peces ben col·locades.
El següent esquema il·lustra i resumeix el procés iteratiu incremental que s’ha
utilitzat com a metodologia.
1.4. Recursos humans
Per avançar en un projecte i elaborar una aplicació, qualsevol equip de
desenvolupament requereix de recursos humans. Aquí explicarem com hem estructurat
aquests recursos per intentar repartir-nos la feina equitativament.
El nostre equip de treball està compost per quatre persones. Cadascuna d’elles
assumirà un rol per garantir que el projecte s’acabi realitzant amb èxit. D’entre els
possibles rols, hem escollit el cap de projecte, l'analista, el creatiu i el finalitzador. Cal dir
però, que aquests rols són orientatius i un membre del grup no serà mai l’únic responsable
d’una tasca del projecte, perquè la virtut d'aquest grup de treball és que existeix la
Diagrama 1. Esquema representatiu de la metodologia emprada
9
possibilitat d'adaptar-se al rol que més s’adeqüi en un moment concret. Tot i així, a
continuació llistem els diferents membres de l’equip juntament amb el rol que han
assumit:
Cap de projecte: Jordi Cazorla Riera
Analista: Ivan Rando Segura
Creatiu: Eduard Rando Segura
Finalitzador: Pau Xiberta i Armengol
El diagrama següent intenta il·lustrar de forma gràfica la distribució i l’estructura
d’aquests rols.
1.5. Software
Tot i que en aquest projecte no s’ha dut a terme la implementació de l’aplicació,
també hem hagut de fer ús d’algun software per a l’elaboració de la documentació i dels
diagrames, així com d’algun sistema de control de versions per a compartir els documents
amb tots els membres del grup.
En aquest apartat farem una descripció de cadascuna de les eines software que
hem necessitat.
1.5.1. Dropbox
Es tracta d’un sistema de control de versions que ens ha permès compartir entre
tots els membres del grup diferents documents referents a les parts del projecte
elaborades per cadascú.
Diagrama 2. Esquema dels rols assumits pels membres de l’equip.
10
S’han descartat altres sistemes de control de versions, com ara el Subversion o el
Git, perquè, en tractar-se d’un projecte mancant d’implementació, aquestes eines ens
afegien funcionalitats innecessàries que feien una mica més difícil la gestió dels documents
durant l’elaboració de la nostra aplicació.
En tractar-se d’una eina gratuïta, no hi ha hagut problemes per cap membre del
grup a l’hora d’obtenir-la.
1.5.2. Microsoft Office
Microsoft Office fa referència a un conjunt d’eines software d’oficina que ens han
permès elaborar tota la documentació.
Entre aquestes eines hi trobem el Microsoft Word , que és un editor de textos que
ens ha servit per redactar cadascuna de les parts de la documentació; el Microsoft Excel,
una fulla de càlcul que hem utilitzat per a la creació de taules i gràfics; i el Microsoft
PowerPoint, un software per elaborar presentacions que també permet l’elaboració
d’esquemes i d’altres figures que ajuden a il·lustrar millor alguns aspectes de la
documentació.
No és una eina gratuïta, però com que tots els membres del grup en tenim llicència,
s’ha optat per utilitzar-la.
1.5.3. Visual Paradigm for UML
Es tracta d’una eina de modelatge UML que ens ha servit per a poder realitzar tots
els diagrames corresponents a la fase d’anàlisi i disseny del nostre projecte, descrivint els
conceptes de manera ràpida i eficaç.
Tampoc és una eina gratuïta, però tots els membres del grup disposem d’una
llicència de la Universitat de Girona que ens permet utilitzar-la.
1.6. Temporització
Aquest apartat ens servirà per a definir una temporització, és a dir, un data inicial i
una data final, per a cadascuna de les diferents tasques del projecte.
La temporització, o sigui, la quantitat de temps destinat a cada tasca, s’ha realitzat
en funció de la importància i la prioritat de la tasca. Per tant, tot seguit mostrem la data
inicial i final del nostre projecte, i la distribució de temps per a cada tasca:
Data d’inici: 21 de febrer del 2012.
Data de fi: 18 de maig del 2012.
11
FASE HORES % DE TEMPS DESTINAT
Pla projecte 15 5% Requeriments 30 10%
Anàlisi 75 25% Disseny 120 40%
Prototipatge 45 15% Documentació 15 5%
Total 300 100%
Taula 1. Temporització per tasques.
Si ens fixem en la taula anterior, podem observar que hem estimat una durada total
del projecte d’unes 300 hores, a repartir en 13 setmanes. Per tant, això significa que cada
membre del grup haurà de treballar de 5 a 6 hores a la setmana si es vol complir aquesta
planificació.
No obstant, el ritme de treball en el projecte pot fluctuar, i hi poden haver
setmanes que hi dediquem més o menys temps. Per aquest motiu prenem la dada de les
hores a dedicar com a orientativa. A més a més, seguint amb el que hem comentat abans,
cada membre del grup té assignat un rol, fet que significa que en determinades fases del
projecte haurà d’assumir més o menys responsabilitat, i podrà comportar-li un augment o
una reducció de les hores de dedicació.
La taula següent estima el nombre d’hores que haurà de dedicar a cada fase del
projecte cadascun dels membre del grup, representats pel rol que assumeixen.
Pla Proj. Requer. Anàlisi Disseny Prototip. Docum. Total
Cap proj. 6 7 18 30 10 5 76
Analista 3 7 20 30 10 2 72
Creatiu 3 9 19 30 10 2 73
Finalitz. 3 7 18 30 15 6 79
Total 15 30 75 120 45 15 300
Taula 2. Temporització per rols i tasques.
A més a més, periòdicament es realitzaran una sèrie de reunions per avaluar com
avança el projecte i cadascuna de les seves parts [Annex I]. També es mantindrà un control
de les hores que cada membre hagi dedicat a cadascuna de les parts del projecte [Annex
IV].
12
21/02/2012 12/03/2012 01/04/2012 21/04/2012 11/05/2012
Pla projecte
Requeriments
Anàlisi
Disseny
Prototipatge
Documentació
Cal tenir present que un dels elements que han condicionat el nostre estudi de
planificació han estat les dates d’entrega de cadascuna de les parts del projecte. Les dates
són les següents:
Requeriments i pla de projecte: 27 de març.
Anàlisi: 20 d’abril.
Disseny: 11 de maig.
Prototipatge, documentació i manual d’usuari: 18 de maig.
Presentació final del projecte: 7 de juny.
Finalment, també hem elaborat un diagrama de Gantt per resumir el nostre estudi
de planificació. Al diagrama hi podem apreciar clarament com ha estat repartida la feina,
encara que algunes de les tasques en què es divideix el projecte s’aniran revisant a mesura
que aquest avanci.
També volem destacar que, tot i que les dates d’entrega de cada part del projecte
estiguin fixades, tal com hem vist abans, això no implica que després d’aquestes dates no
es continuï avançant i millorant cadascuna d’aquestes parts. És per aquest motiu que les
dates finals que apareixen al diagrama poden ser diferents de les dates d’entrega.
Diagrama 3. Diagrama de Gantt de la planificació inicial.
13
1.7. Viabilitat
Per saber si un projecte es pot dur a terme o no, cal fer un estudi de viabilitat. Això
significa que cal saber quins costos representaria la seva implementació i d’on trauríem el
finançament per cobrir aquests costos en el cas que el projecte anés endavant.
1.7.1. Costos
Si el projecte que expliquem en aquest document es volgués portar a la pràctica, hi
hauria un conjunt de factors relacionats que suposarien unes despeses i que caldria tenir
en compte abans de continuar.
Entre aquests factors hi podríem trobar els salaris dels treballadors que
s’encarregarien d’implementar l’aplicació. En aquest sentit, caldria estudiar el nombre
d’hores necessàries per fer la implementació i decidir quin seria el preu per cada hora
treballada.
D’altra banda, cal comptar amb tots els recursos necessaris per a desenvolupar
l’aplicació. En serien un exemple el lloguer del local, si calgués, o les llicències de software
específic per a la implementació.
A més a més, dins dels recursos necessaris també hi podríem incloure els elements
hardware imprescindibles per garantir el bon desenvolupament de l’aplicació.
En tractar-se d’una aplicació mòbil, també haurem de pensar, un cop acabada
l’aplicació, o almenys una primera versió, en el cost de publicació d’una aplicació a
l’Android Market, en el cas de la versió per Android, o a l’Apple Store, en el cas de la versió
per iPhone.
Per acabar, haurem de tenir en compte un element específic de la nostra aplicació.
Es tracta del conjunt de fotografies dels indrets que mostrarem. Podem obtenir-les de
diverses maneres, però la majoria podrien representar-nos un cost més. Per exemple, si
les prenguéssim de la xarxa hauríem de vigilar amb els drets d’autor.
1.7.2. Ingressos
Per fer front a tots els costos que hem exposat a l’apartat anterior s’hauran de
buscar vies de finançament que pal·liïn aquestes despeses.
La primera idea per obtenir ingressos és intentar treure profit dels dos tipus de
versions de la nostra aplicació. Per un costat hi haurà la versió gratuïta que s’oferirà a tots
als usuaris. Els ingressos d’aquesta versió es poden aconseguir mitjançant la publicitat que
es mostrarà en algunes funcionalitats de l’aplicació. Per l’altre costat, també es disposarà
d’una versió de pagament per aquells usuaris que no vulguin publicitat a l’aplicació. Així,
els ingressos d’aquesta versió s’obtindrien directament dels usuaris, que passarien a ser
usuaris premium.
14
L’altra idea que plantegem per disposar de finançament es basa en les
funcionalitats de la mateixa aplicació. Es pot aprofitar el fet que s’hagin de fotografiar certs
indrets per comunicar a empreses propietàries de llocs emblemàtics que tenen l’opció
d’aparèixer a la nostra aplicació com a indret a fotografiar si aporten una part del
finançament. De la mateixa manera, també es pot demanar finançament a ajuntaments o a
d’altres entitats públiques que vulguin que el seu territori tingui un pes més important a
l’aplicació pel que fa al nombre d’indrets a fotografiar.
De fet, és per aquest motiu que existeix el tipus d’usuari “corporatiu”, per oferir a
aquestes entitats públiques l’opció de promocionar el seu territori a través de la nostra
aplicació.
15
2. Revisio del pla de projecte
Poques vegades la planificació final d’un projecte coincideix exactament amb la
planificació inicial que s’havia previst. El nostre cas no ha estat una excepció i ens hem
endarrerit en la segona entrega del desenvolupament del projecte, la que fa referència a la
part d’anàlisi. En aquest apartat redefinirem el pla de projecte tenint en compte aquesta
modificació.
De fet, les tasques que cal realitzar no han canviat respecte les que teníem al pla de
projecte inicial, de la mateixa manera que tampoc han canviat els recursos humans i el
software. Per tant, l’únic punt que s’ha vist afectat i que cal tornar a definir és l’apartat de
temporització.
2.1. Temporització
Abans d’entrar en detall, cal tenir en compte que l’objectiu de la temporització
continua sent el mateix: tenir el projecte acabat per la data d’entrega final. Per tant, caldrà
revisar les hores dedicades al projecte per cada membre del grup fins al moment, i
comprovar si s’havia fet una mala planificació inicial o si cal més implicació per part de
tots els membres del grup.
De moment, recordem les dates inicials i finals del projecte:
Data d’inici: 21 de febrer del 2012.
Data de fi: 18 de maig del 2012.
Hem de destacar que tots aquests imprevistos i aquestes modificacions han estat a
l’ordre del dia de les reunions que mantenim periòdicament els membres del grup.
Pel que fa a les hores que s’havien previst, hem comprovat que es va fer una
estimació massa optimista de la fase d’anàlisi, assignant-li menys hores de les que li
haurien pertocat. De fet, el nombre d’hores que s’han dedicat a aquesta fase actualment ja
és superior al nombre d’hores previstes al principi, fet que també pot afectar a la fase de
disseny. Per tant, tot això ens ha fet replantejar les dates previstes per la resta de tasques
del projecte i ens ha fet modificar el diagrama de Gantt inicial.
A continuació tornem a llistar les dates d’entrega de les diferents tasques del
projecte amb les modificacions pertinents des de la fase d’anàlisi. Com que la data
d’entrega d’aquesta part s’ha allargat, també s’ha vist afectada la data d’entrega de la part
de disseny, encara que hem volgut mantenir la mateixa data d’entrega final.
Requeriments i pla de projecte: 27 de març.
Anàlisi: 26 d’abril.
Disseny: 13 de maig.
16
21/02/2012 12/03/2012 01/04/2012 21/04/2012 11/05/2012
Pla projecte
Requeriments
Anàlisi
Disseny
Prototipatge
Documentació
Prototipatge, documentació i manual d’usuari: 18 de maig.
Presentació final del projecte: 7 de juny.
Podem observar com la primera data d’entrega s’ha mantingut, però la d’anàlisi
s’ha endarrerit sis dies i, com a conseqüència, la de disseny ho ha fet dos dies més. Com
que hem d’intentar mantenir el client content, hem procurat no modificar les dues
darreres dates d’entrega perquè la documentació, juntament amb el prototipatge i el
manual d’usuari, són tasques del projecte que és important entregar el dia proposat al pla
de projecte inicial.
Així, si duem a terme les modificacions al diagrama de Gantt, obtenim un nou
diagrama que reflecteix la nova planificació del projecte.
Diagrama 4. Diagrama de Gantt de la planificació inicial revisat.
17
3. Requeriments del sistema
Es tracta d’una aplicació mòbil que ens permet mantenir un registre dels diferents
llocs del món que hem visitat. Ho farà seguint la idea d’un joc, de manera que a més llocs
visitats, més puntuació. L’aplicació proposarà una sèrie d’imatges dels diferents indrets, i
l’usuari haurà de fotografiar-los amb el mòbil per demostrar que hi ha viatjat.
3.1. Introducció
3.1.1. Conceptes
Indret (o punt d’interès): Un indret serà un punt d’interès geogràfic de la nostra
aplicació al qual tindrem l’opció de fer una fotografia.
Regió: Agrupació d’indrets o d’altres regions.
Itinerari: Un itinerari estarà format per una seqüència ordenada d’indrets a
visitar.
3.1.2. Països, regions, sub-regions i indrets
La nostra aplicació no ha de permetre només la separació d’indrets per països. En
algunes situacions, pot ser que un país concret tingui algunes regions on hi ha molts més
indrets destacats que no pas d’altres, i també pot passar que alguns països tinguin molt
pocs indrets a visitar.
Per aquest motiu, hem de poder permetre agrupar els indrets en regions. Així, un
país podrà tenir una col·lecció d’indrets i una col·lecció de regions. Es farà ús de les
regions quan en una zona molt petita hi hagi molts indrets a visitar.
Una regió, per la seva banda, també podrà tenir una col·lecció d’indrets i una
col·lecció de regions (sub-regions). D’aqueta manera, per més indrets que afegim (sempre
pensant en el creixement de l’aplicació), tindrem l’opció d’agrupar-los en una regió per
poder gestionar-los millor.
Quan l’usuari seleccioni un país, podrà veure la col·lecció d’indrets i la de regions, i
en qualsevol moment podrà seleccionar una regió per veure’n les seves col·leccions
(d’indrets o bé de sub-regions).
Per posar un exemple, si seleccionéssim Catalunya com a país, podríem veure una
determinada col·lecció d’indrets escampats arreu del país. Però si pensem en Barcelona,
en tenir tants indrets destacats per visitar, hi hauria una concentració d’indrets massa
densa en un punt prou petit. Per tant, Barcelona passaria a ser una regió (o el Barcelonès)
que contindria una col·lecció de tots els indrets d’aquesta regió. Si, tot i així, hi continués
havent massa concentració, es podrien crear més regions dins d’una regió (per exemple,
que cada barri fos una sub-regió).
18
Amb aquesta tècnica permetem el creixement de la nostra aplicació pel que fa al
nombre d’indrets sense afectar a la visualització d’aquests.
3.1.3. Fotografies dels indrets
Un indret podrà tenir associades més d’una imatge per poder permetre a l’usuari
diferents perspectives (els punts des d’on farà la fotografia) de l’indret. Per exemple, si
l’indret fos la Muralla xinesa, seria poc seriós que només es pogués fer la fotografia des
d’una sola perspectiva; per tant, la idea seria incloure diferents fotografies de la Muralla
xinesa (al llarg del seu recorregut), i que l’usuari pogués escollir aquella que li fos més
convenient per intentar imitar-la.
3.1.4. Tipus d’usuari
L’aplicació contindrà diferents tipus d’usuaris:
Usuari principiant
Usuari expert
Usuari premium
Usuari corporatiu
Considerarem usuaris principiants a aquells que acaben de descarregar-se
l’aplicació o que tenen menys d’uns determinats punts (n punts). Aquest usuaris només
podran utilitzar les funcionalitats bàsiques de l’aplicació.
Considerarem usuaris experts aquells usuaris que han obtingut més de n punts.
Aquests usuaris podran realitzar tot el que feia l’usuari principiant i, a més a més, podran
suggerir indrets o crear itineraris.
Els usuaris
premium, en no
tenir influència
directa sobre les
funcionalitats, no
es contemplaran
com a actors.
Diagrama 5. Tipus d’usuari.
19
Considerarem usuari premium els usuaris que han pagat perquè no els aparegui
publicitat a l’aplicació. Depenent dels punts que hagin aconseguit podran realitzar les
mateixes funcionalitats que els usuaris principiants o els usuaris experts.
Considerarem usuari corporatiu a entitats o empreses que vulguin fer publicitat a
través de la nostra aplicació. Aquests usuaris, de la mateixa manera que els usuaris
experts, podran suggerir indrets o crear itineraris. Serà un tipus d’usuari força diferent de
la resta, perquè el seu objectiu no serà avançar en el joc, sinó proporcionar eines per
complementar-lo des del seu propi benefici.
3.2. Requeriments funcionals
3.2.1. Usuari principiant
En aquest apartat explicarem les funcionalitats de l’aplicació que podran dur a
terme els usuaris principiants.
3.2.1.1. Registrar-se
L’usuari ha de poder introduir la seva informació bàsica per poder ser reconegut
pel sistema.
La informació que necessitarem guardar serà el nom d’usuari, que haurà de ser
únic en el sistema. Un cop registrat, no es tornarà a preguntar el nom d’usuari.
3.2.1.2. Mostrar Regió
Una regió serà una agrupació d’indrets (punts d’interès) o d’altres regions (sub-
regions). L’aplicació haurà de mostrar el perfil geogràfic de la regió i indicar els seus
components (les seves col·leccions), ja siguin punts d’interès o sub-regions.
3.2.1.3. Obtenció dels Indrets
L’usuari podrà obtenir les fotografies i la informació bàsica dels diferents indrets
disponibles a la nostra aplicació.
Si es disposa d’Ínternet, qualsevol indret podrà ser descarregat al moment. D’altra
banda, també tindrem l’opció de poder-nos descarregar els indrets d’un itinerari concret
en un moment determinat, si sabem que la nostra connexió a Internet estarà limitada.
Finalment, si es dóna el cas que no tenim Internet i no hem fet la previsió de descarregar-
nos la informació dels indrets amb antelació, aleshores no serà possible la seva
visualització.
20
3.2.1.4. Mostrar Indret
Caldrà mostrar la imatge (o imatges) a reproduir de l’indret. D’aquesta manera,
l’usuari podrà saber com ha de ser la fotografia que ha de realitzar. Per ajudar-lo, també es
mostrarà la posició de l’indret (coordenades) i una indicació per tal que l’usuari pugui
assegurar-se que està al lloc correcte.
Si l’indret encara no ha estat validat, s’haurà de permetre a l’usuari realitzar una
fotografia per fer-ho; si, per altra banda, ja ha estat validat, es mostrarà l’última fotografia
realitzada per l’usuari d’aquell indret. En el cas que un usuari esborri una fotografia seva
d’un indret correctament validat, aleshores l’aplicació haurà de mantenir l’estat de la
validació encara que no es mostri cap imatge.
3.2.1.5. Cercar Indret
Tenint en compte que un país o regió pot tenir un nombre considerable d’indrets
(tot i que sempre que sigui possible s’intentaran agrupar en regions), es podran mostrar
en forma de llistat paginat (amb uns deu indrets per pàgina) i ordenat.
A més a més, caldrà permetre a l’usuari fer una cerca sobre un indret concret per
fer-li més còmode la seva obtenció si ja sap des d’un bon principi allò que està buscant.
3.2.1.6. Obtenir itinerari
Per cercar itineraris només farà falta indicar el país del qual es vol un itinerari i
l’aplicació haurà de mostrar un llistat de tots els itineraris disponibles.
El usuaris podran visualitzar l’itinerari desitjat des del seu dispositiu sempre que
disposin de connexió. Però també hi ha la possibilitat de visualitzar itineraris offline (fora
de línia, sense connexió). En aquest cas, l’itinerari es descarregarà en el dispositiu de
l’usuari i podrà consultar-lo de forma local sense necessitat de cap connexió.
3.2.1.7. Validació de la fotografia
Per validar que una fotografia s’ha realitzat des del lloc correcte i que correspon
realment a l’indret indicat, se seguiran dos processos bàsics: es calcularan les coordenades
GPS del mòbil en fer la fotografia i es comprovarà que corresponguin a les de l’indret
indicat, i es farà una comprovació mitjançant els píxels de la fotografia per comprovar si
les imatges són semblants.
Tot aquest procés es durà a terme en el propi dispositiu mòbil.
3.2.1.8. Puntuació
La puntuació de cada usuari vindrà relacionada amb el nombre de fotografies
validades correctament que hagi fet. Cada fotografia validada correspondrà a un punt (es
podrà contemplar la possibilitat de fotografies amb puntuació extra, ja sigui per dificultat
o per publicitat del lloc a fotografiar).
21
3.2.1.9. Classificació d’usuaris
Es podrà visualitzar la classificació dins del joc dels diferents usuaris. Es podrà fer
per puntuació o per percentatge de llocs visitats.
A la llista de la classificació es mostraran els deu millors usuaris i el nostre
percentatge o puntuació.
A més a més, també es podrà escollir si es vol veure la classificació global (qui ha
visitat més indrets d’arreu del món), o la classificació per països (qui ha visitat més indrets
d’un país concret). Per la segona opció, l’aplicació ens demanarà que seleccionem un dels
països on hi ha llocs per visitar.
Es podrà fer un filtrat dels usuaris per veure la classificació de tots els usuaris que
utilitzen l’aplicació o bé només de la nostra llista d’amics.
3.2.1.10. Incidències
Si algun usuari detecta que algun indret que forma part de l’aplicació ja no existeix,
podrà comunicar-nos-ho mitjançant l’enviament d’una incidència, afegint-hi els
comentaris pertinents si ho creu convenient.
3.2.1.11. Informació de fotografies
Quan l’usuari hagi seleccionat un indret, haurà de poder obtenir informació
d’aquell indret com a complement cultural.
En aquesta informació hi podran constar els horaris (si es tracta d’algun indret
visitable, com un museu), una descripció històrica, un mapa per accedir-hi...
3.2.1.12. Àlbum de fotografies
Hi haurà la possibilitat de veure totes les fotografies que s’han anat fent per a
poder-les gestionar. Per exemple, hi haurà l’opció d’eliminar-les si així ho creu convenient
l’usuari.
3.2.1.13. Llista d’amistats
Un usuari podrà fer una cerca a l’aplicació per buscar altres usuaris. Podrà enviar
peticions d’amistat a aquells usuaris que vulgui, i quan rebi l’acceptació per part d’aquests
passaran a formar part de la seva llista d’amistats. Evidentment, també hi haurà la
possibilitat d’eliminar usuaris de la llista d’amistats.
3.2.1.14. Publicar fotografia al Facebook
L’usuari ha de poder decidir si vol publicar una de les seves fotografies al seu
compte de Facebook. Per fer-ho, s’utilitzarà un applet de Facebook per facilitar el procés i
poder proporcionar a l’usuari totes les funcionalitats que permet Facebook, com ara afegir
comentaris.
22
3.2.2. Usuari expert
En aquest apartat explicarem les funcionalitats de l’aplicació que podran dur a
terme només els usuaris experts. Per tant, cal deixar clar que aquests usuaris també
podran fer ús de les funcionalitats dels usuaris principiants.
3.2.2.1. Crear itinerari
L’aplicació haurà de permetre la creació i visualització d’itineraris. L’usuari haurà
de poder crear els seus propis itineraris o utilitzar itineraris d’altres usuaris.
Un itinerari es podrà crear de forma automàtica o de forma manual. Si es fa de
forma automàtica, només caldrà seleccionar un indret central i un radi màxim, i l’aplicació
s’haurà d’encarregar de crear una seqüència d’indrets dins d’aquest radi; si es fa de forma
manual, l’usuari haurà d’anar introduint per ordre cadascun dels indrets de l’itinerari.
En tot moment es podrà modificar l’itinerari afegint o eliminant indrets, o alterant
l’ordre de la seqüència.
Com que la generació d’itineraris és una feina complexa, els usuaris podran
compartir els seus itineraris amb la resta des de la mateixa aplicació.
Aquesta és una funcionalitat molt útil pels usuaris corporatius, perquè tindran
l’opció de fer publicitat d’una determinada regió mitjançant la creació d’itineraris.
3.2.2.2. Suggeriments
Els usuaris hauran de poder suggerir indrets que es puguin incloure a la següent
actualització de l’aplicació.
De la mateixa manera que realitzen les fotografies per avançar en el joc, també en
podran fer d’altres indrets dels quals no disposa l’aplicació per suggerir-los als
administradors (incloent els comentaris corresponents).
Per evitar l’allau de suggeriments, es podrà limitar el nombre de suggeriments que
pot enviar cada usuari. Per exemple, es podrà establir que cada usuari pugui enviar un
màxim de cinc suggeriments al mes, o que el nombre de suggeriments vingui relacionat
amb la seva puntuació (un suggeriment cada deu punts, per exemple).
23
3.2.3. Administrador
L’administrador podrà gestionar el funcionament de l’aplicació, especialment
aquelles parts que afectin als usuaris. Les parts essencials que ha de poder controlar es
descriuen a continuació.
3.2.3.1. Gestió d'usuaris
Podrà gestionar els diferents usuaris, eliminant o bloquejant aquells que tinguin
una conducta incorrecta, o bé modificant, si fos el cas, les puntuacions d’algun d’ells per
imatges fraudulentes o per algun error concret.
3.2.3.2. Gestió d'indrets
Podrà gestionar els diferents punts d’interès, afegint-ne de nous (consensuats per
l’equip administratiu o bé atenent els suggeriments enviats pels usuaris), eliminant-ne
d’existents (perquè ja no existeixen o per decisió de l’equip administratiu), o bé
modificant-los (per canviar, per exemple, la informació o les imatges que tenen
associades).
3.2.3.3. Gestió de suggeriments
Haurà d’atendre els suggeriments enviats pels usuaris experts. L’aplicació haurà de
permetre mantenir un control d’aquests suggeriments i avisar a l’administrador si algun
d’ells es repeteix molt sovint, tot indicant que és adequat per ser inclòs a l’aplicació.
L’administrador també ha de poder veure en tot moment quins són els suggeriments
enviats i poder-los revisar; si algun d’ells és prou original, també pot tenir opcions de ser
inclòs en pròximes versions de l’aplicació.
3.2.3.4. Gestió d’incidències
Haurà d’atendre les incidències enviades pels usuaris. L’aplicació haurà de
permetre mantenir un control d’aquestes incidències i avisar a l’administrador si alguna
d’elles es repeteix massa sovint, fet que podria provocar l’eliminació d’aquell indret de
l’aplicació. L’administrador també ha de poder veure en tot moment quines són les
incidències enviades i el nombre d’incidències relacionades amb cada indret.
3.2.3.5. Estadístiques
Haurà de poder veure les estadístiques de l’aplicació, que poden incloure
informacions com els països més visitats pels usuaris, el correcte funcionament general de
l’aplicació, el control del creixement dels usuaris, l’ús de les diferents funcionalitats de
l’aplicació, les plataformes i versions més utilitzades, etc. L’aplicació haurà de controlar
tots aquests aspectes i oferir els resultats de forma ordenada a l’administrador.
Així, els punts més importants que haurà de tenir en compte aquest apartat,
mostrats en forma de llista, són els següents:
24
Freqüència de visites de cada país.
Nombre de fallades de les aplicacions en els mòbils.
Nombre d’usuaris nous per dia.
Plataformes més utilitzades per descarregar-se l’aplicació.
Tots aquests aspectes es mostraran en forma de llista, ordenats de la mateixa
manera, visualitzant-se només aquells que l’administrador hagi seleccionat.
3.3. Requeriments no funcionals
L’aplicació serà suportada pels sistemes operatius Android 2.2 i superiors, i per IOS
4 i superiors.
La raó per la qual s’ha escollit Android i IOS és perquè ocupen la major part del
mercat, tal com mostra el següent gràfic:
Gràfic 1. Ús dels sistemes operatius per a mòbils. Font: http://blog.nielsen.com/nielsenwire/, corresponents al tercer
quadrimestre del 2011.
25
Pel que fa a les versions dels dos sistemes operatius, els següents gràfics ens
mostren quines són les versions més utilitzades actualment, i quines ja no utilitza gairebé
ningú. A partir d’aquí, hem escollit el segment que inclou més gent.
Gràfic 2. Versions del sistema operatiu Android. Font: http://developer.android.com/resources/dashboard/platform-versions.html,
corresponents al primer quadrimestre del 2012.
Gràfic 3. Versions del sistema operatiu IOS. Font: http://insights.chitika.com/, corresponents al darrer quadrimestre del 2011.
26
L’aplicació acceptarà, al principi, un màxim de 100.000 usuaris. Com que la
informació a guardar per cada usuari no és molt gran (només necessitarem guardar el
nom i la puntuació), la capacitat del servidor no serà cap problema. Es calcula que amb
200 Gb n’hi hauria d’haver prou per emmagatzemar tota la informació.
Pel que fa a les fotografies que faci l’usuari, es guardaran en una carpeta pròpia de
l’aplicació i inaccessible per l’usuari, és a dir, de manera local. Quan l’aplicació mostri les
imatges fetes per l’usuari (mitjançant l’àlbum), les anirà a buscar a aquesta carpeta, i
l’usuari tindrà l’opció d’esborrar-les des d’allà.
27
4. Ana lisi
En aquest apartat durem a terme la fase d’anàlisi de la nostra aplicació. Això
significa que s’ha fet un estudi de les diferents funcionalitats, corresponents als nostres
requeriments, de les que hauria de disposar el nostre sistema. Així doncs, veurem la
documentació necessària i més rellevant per a poder implementar l’aplicació si així es
decidís.
Aquesta fase comprendrà la realització de diferents diagrames de casos d’ús amb
els corresponents conjunts de funcionalitats. A més a més, tindrem diferents fitxes de
casos d’ús a nivell de programador per poder entendre millor algunes de les funcionalitats
més importants. Com veurem, alguns diagrames diferencien les parts que tenen a veure
amb el sistema de les parts que tenen a veure amb el dispositiu mòbil. Aquesta indicació
ens servirà per saber on es realitzen les funcionalitats que inclouen.
El conjunt de tots aquests diagrames ens ajudaran a elaborar una primera versió
del diagrama de classes.
28
4.1. Diagrama de casos d’ús general
El següent diagrama representa la relació entre els diferents actors del sistema i el
conjunt de casos d’ús. Es tracta d’un diagrama a alt nivell, i alguna de les seves parts
s’explica en detall en els següents apartats. Ho hem fet així per poder entendre millor el
funcionament general.
Diagrama 6. Diagrama de casos d’ús general.
29
4.2. Diagrama de casos d’ús: Part Administrador
Aquí detallarem d’una forma més concreta els casos d’ús corresponents a la part
d’administrador. Al diagrama de casos d’ús general hem englobat aquesta part sota el nom
de “Part Administrador”.
Diagrama 7. Diagrama de casos d’ús: Part Administrador.
30
4.3. Diagrama de casos d’ús: Part Amics Usuari
Aquí detallarem d’una forma més concreta els casos d’ús corresponents a la part
d’amics de l’usuari. Al diagrama de casos d’ús general hem englobat aquesta part sota el
nom de “Part Amics Usuari”.
Diagrama 8. Diagrama de casos d’ús: Part Amics Usuari.
31
4.4. Diagrama de casos d’ús: Part Classificació
Aquí detallarem d’una forma més concreta els casos d’ús corresponents a la part de
la classificació. Al diagrama de casos d’ús general hem englobat aquesta part sota el nom
de “Part Classificació”.
Diagrama 9. Diagrama de casos d’ús: Part Classificació.
32
4.5. Fitxes de cas d’ús
Per explicar de forma més detallada el funcionament d’alguns casos d’ús
utilitzarem les fitxes de cas d’ús. Hem creat fitxes d’aquells casos d’ús que hem cregut més
rellevants o més complicats d’entendre, i ho hem fet amb fitxes a nivell de programador,
de manera que quan vulguem crear determinats diagrames per especificar millor el cas
d’ús, com ara els diferents diagrames de seqüència o el diagrama de classes, ja tinguem
una base i ens sigui més còmode.
Pel que fa al cas d’ús “Generació Automàtica d’Ítinerari”, com que tracta un
problema geomètricament més complex, s’explicarà detalladament el seu procediment a
l’annex [Annex II].
La llista de casos d’ús que hem detallat és la següent:
Registrar-se
Mostrar indret
Cercar indret
Enviar incidència
Fer fotografia
Veure informació indret
Veure incidència
Veure estadístiques
Afegir amic
Eliminar amic
Validar fotografia
Crear itinerari
Generació automàtica d’itinerari
Veure classificació global i tots
Veure classificació global i amics
Veure classificació països i tots
Veure classificació països i amics
Suggerir indret
Mostrar itinerari
Mostrar llista d’amics
Afegir usuari
Inhabilitar usuari
Afegir indret
Eliminar indret
33
4.5.1. Registrar-se
Nom: Registrar-se Autor: Membres del grup Data 17/04/12 Descripció: Procés inicial que s’executa en iniciar l’aplicació Actors: Usuari Pre-condicions:
L’usuari ha iniciat l’aplicació
Flux principal:
1. SÍ és la primera vegada que s’inicia l’aplicació LLAVORS 1.1. Demanar nom d’usuari 1.2. Demanar contrasenya 1.3. Repetir contrasenya 1.4. Demanar correu electrònic 1.5. Comprovar disponibilitat del nom 1.6. Enviar les dades de creació de l’usuari al servidor 1.7. Mostrar missatge de benvinguda
2. ALTRAMENT 2.1. Comprovar que l’usuari no estigui inhabilitat per l’administrador. 2.2. Mostrar pantalla inicial de l’aplicació de l’usuari del dispositiu.
Flux alternatiu:
1.2. Si el nom ja existeix (està ocupat per un altre usuari), aleshores cal retornar al punt 1.1. 1.4. Si les dades no s’envien correctament o són invàlides, mostrar un missatge d’error. 2.1. Si l’usuari està inhabilitat no se li permetrà accedir a l’aplicació.
Post-Condició: L’usuari ha accedit a l’aplicació (registrant-se en el cas que sigui nou) Comentaris: ---
34
4.5.2. Mostrar indret
Nom: Mostrar indret Autor: Membres del grup Data 17/04/12 Descripció: Permet veure un indret concret de l’aplicació Actors: Usuari Pre-condicions:
-
Flux principal:
1. Obtenir llista de països. 2. Mostrar llista de països. 3. Seleccionar país. 4. Obtenir llista de regions. 5. Mostrar llista de regions. 6. Seleccionar regió. 7. SI la regió té més regions i l’usuari vol veure-les LLAVORS
7.1. Obtenir llista de regions de la regió. 7.2. Mostrar llista de regions de la regió. 7.3. Seleccionar regió. 7.4. Tornar al punt 7.
8. ALTRAMENT SÍ la regió no té més regions o si l’usuari vol veure els indrets LLAVORS 8.1. Obtenir llista d’indrets de la regió. 8.2. Mostrar llista d’indrets de la regió. 8.3. Seleccionar indret
9. Mostrar l’indret seleccionat
Flux alternatiu:
6. L’usuari pot tornar enrere per seleccionar un altre país. 7.3. L’usuari pot tornar enrere per seleccionar una altra regió. 8.3. L’usuari pot tornar enrere per seleccionar una altra regió. 9. L’usuari pot tornar enrere per seleccionar un altre indret.
Post-Condició: Es mostra l’indret seleccionat per l’usuari. Comentaris: ---
35
4.5.3. Cercar indret
Nom: Cercar indret Autor: Membres del grup Data 17/04/12 Descripció: Permet cercar un indret de l’aplicació pel seu nom Actors: Usuari Pre-condicions:
-
Flux principal:
1. Escriure nom de l’indret. 2. Obtenir nom de l’indret escrit per l’usuari. 3. Obtenir llista d’indrets de l’aplicació. 4. Ordenar alfabèticament la llista d’indrets obtinguda. 5. Fer una cerca dicotòmica a la llista per trobar el nom de l’indret
escrit per l’usuari. 6. Un cop trobat, mostrar l’indret corresponent.
Flux alternatiu:
6. Si el nom de l’indret escrit per l’usuari no es troba a la llista ordenada d’indrets, aleshores cal mirar en quin punt de la llista s’ha quedat la cerca dicotòmica i mostrar el nom dels cinc indrets anteriors i dels cinc indrets posteriors (proposant altres noms a l’usuari suposant que s’ha equivocat).
Post-Condició: Es mostra l’indret cercat per l’usuari (si hi és) o els noms dels indrets més propers alfabèticament (si no hi és).
Comentaris: ---
4.5.4. Enviar incidència
Nom: Enviar incidència Autor: Membres del grup Data 17/04/12
Descripció: Permet avisar als administradors de l’existència d’alguna incidència amb algun indret
Actors: Usuari Pre-condicions:
Cal que l’usuari hagi seleccionat un indret
Flux principal:
1. Escriure descripció de la incidència. 2. Establir connexió amb el servidor. 3. Empaquetar les dades a enviar (s’empaquetarà en una cadena de
caràcters on la primera part farà referència a l’identificador de l’indret, i la segona part correspondrà a la descripció de la incidència, separant les dues parts pel caràcter ‘#’).
4. Enviar paquet. 5. Finalitzar connexió.
Flux alternatiu:
Post-Condició: S’envia una incidència al servidor indicant de quin indret es tracta i amb una descripció adjunta.
Comentaris: Només tindrem un punt d’accés al servidor.
36
4.5.5. Fer fotografia
Nom: Fer fotografia Autor: Membres del grup Data 17/04/12 Descripció: Permet fer una fotografia d’un indret Actors: Usuari Pre-condicions:
L’usuari ha seleccionat un indret o bé vol enviar un suggeriment.
Flux principal:
1. Mitjançant la interfície pròpia de la càmera del dispositiu, fer una fotografia de l’indret que interessa.
2. Obtenir la fotografia. 3. Mostrar la fotografia. 4. SÍ l’usuari havia seleccionat un indret de l’aplicació LLAVORS
4.1. Validador = Crear validador() 4.2. Validador.validar(fotografia) 4.3. Guardar la fotografia a l’àlbum de fotografies de l’aplicació.
Flux alternatiu:
4.2. Si la fotografia no es valida correctament, aleshores no es guarda la fotografia a l’àlbum de fotografies de l’aplicació.
Post-Condició: Es mostra la fotografia (i es guarda a l’àlbum de fotografies de l’aplicació en el cas que l’usuari hagi seleccionat un indret i la fotografia hagi estat validada) que l’usuari ha fet d’un indret.
Comentaris: ---
4.5.6. Veure informació indret
Nom: Veure informació indret Autor: Membres del grup Data 17/04/12 Descripció: Permet veure la informació associada a un indret Actors: Usuari Pre-condicions:
L’usuari ha seleccionat un indret.
Flux principal:
1. Obtenir la informació associada a l’indret seleccionat per l’usuari. 2. Mostrar nom de l’indret. 3. PER cada atribut de la informació FER
3.1. Mostrar atribut en una secció diferent. Flux alternatiu:
Post-Condició: Es mostra la informació associada a l’indret seleccionat per l’usuari.
Comentaris:
Com que la informació pot variar segons l’indret (un museu, a diferència d’un monument, pot tenir horari), es mostrarà cada atribut de la informació en un bloc diferent, permetent mostrar la informació sota una mateixa interfície.
37
4.5.7. Veure incidència
Nom: Veure incidència Autor: Membres del grup Data 17/04/12
Descripció: Permet veure als administradors les diferents incidències sobre els indrets que han enviat els usuaris.
Actors: Administrador Pre-condicions:
-
Flux principal:
1. Obtenir la llista d’indrets de l’aplicació. 2. Crear una estructura de dades funcional (EDF) que tingui indrets
per clau i col·leccions d’incidències per valors. 3. PER cada indret de la llista FER
3.1. Obtenir les incidències associades a l’indret 3.2. Afegir una nova entrada a l’EDF que tingui l’indret per clau i la col·lecció d’incidències per valor.
4. PER cada entrada de l’EDF FER 4.1. Mostrar el nom de l’indret que té per clau 4.2. Mostrar el nombre d’incidències de la col·lecció que té per valor
5. Seleccionar un dels noms d’indrets 6. PER cada incidència de la col·lecció de l’indret seleccionat FER
6.1. Obtenir l’usuari que ha enviat la incidència 6.2. Obtenir el nom de l’usuari 6.3. Mostrar el nom de l’usuari
7. Seleccionar una incidència 8. Mostrar nom de l’indret associat a la incidència 9. Mostrar nom de l’usuari associat a la incidència 10. Mostrar descripció associada a la incidència
Flux alternatiu:
Post-Condició: Es visualitza la informació d’una de les incidències enviades pels usuaris de l’aplicació.
Comentaris: En tot moment l’administrador pot tornar enrere per seleccionar una nova incidència.
38
4.5.8. Veure estadístiques
Nom: Veure estadístiques Autor: Membres del grup Data 17/04/12 Descripció: Permet veure als administradors les estadístiques de l’aplicació Actors: Administrador Pre-condicions:
-
Flux principal:
1. Obtenir la llista d’atributs de les estadístiques. 2. PER cada atribut de la llista FER
2.1. Mostrar el nom de l’atribut 2.2. Mostrar el valor de l’atribut
Flux alternatiu:
Post-Condició: Es visualitzen les estadístiques de l’aplicació. Comentaris: ---
Més endavant, quan mostrem el diagrama de seqüència corresponent, s’explicarà
en detall tot el que fa referència a les estadístiques.
4.5.9. Afegir amic
Nom: Afegir amic Autor: Membres del grup Data 17/04/12 Descripció: Permet afegir un usuari a la llista d’amistats d’un usuari Actors: Usuari Pre-condicions:
-
Flux principal:
1. Escriure el nom de l’usuari que es vol afegir al cercador d’usuaris. 2. Comprovar que l’usuari existeix i que utilitza l’aplicació. 3. Enviar una petició d’amistat a l’usuari que es vol afegir. 4. Verificar que l’usuari que es vol afegir ha acceptat la petició
d’amistat. 5. Obtenir la llista d’amistats de l’usuari sol·licitant. 6. Afegir el nou usuari a la llista. 7. Obtenir la llista d’amistats de l’usuari que es vol afegir. 8. Afegir l’usuari sol·licitant a la llista.
Flux alternatiu:
2. Si l’usuari no existeix es mostrarà un error indicant-ho. 4. Si l’usuari que es vol afegir no accepta la petició d’amistat, aleshores no s’afegeix cap nou usuari a cap de les dues llistes d’amistats (la de l’usuari sol·licitant i la de l’usuari que es vol afegir).
Post-Condició:
S’ha afegit un nou usuari (l’usuari que s’ha escrit al cercador) a la llista d’amistats de l’usuari sol·licitant (si existeix), i un nou usuari (l’usuari sol·licitant) a la llista d’amistats de l’usuari que s’ha escrit al cercador (si existeix).
Comentaris: ---
39
4.5.10. Eliminar amic
Nom: Eliminar amic Autor: Membres del grup Data 17/04/12 Descripció: Permet eliminar un usuari de la llista d’amistats d’un usuari Actors: Usuari Pre-condicions:
-
Flux principal:
1. Obtenir la llista d’amistats de l’usuari sol·licitant. 2. Mostrar la llista. 3. Seleccionar un usuari de la llista. 4. Eliminar l’usuari de la llista. 5. Obtenir la llista d’amistats de l’usuari que s’ha eliminat de la llista. 6. Eliminar l’usuari sol·licitant d’aquesta llista.
Flux alternatiu:
Post-Condició: S’ha eliminat un nou usuari (l’usuari seleccionat) de la llista d’amistats de l’usuari sol·licitant.
Comentaris: ---
40
4.5.11. Validar fotografia
Nom: Validar Fotografia Autor: Membres del grup Data 17/04/12
Descripció: Procés que comprovarà si una fotografia feta per l’usuari és acceptada o no.
Actors: Sistema Pre-condicions:
L’usuari ha d’haver seleccionat un indret i ha d’haver fet una fotografia a d’aquest indret.
Flux principal:
1. Obtenir la localització GPS del dispositiu. 2. Calcular la distància entre les coordenades de l’indret i les
coordenades obtingudes del dispositiu. 3. Obtenir la distància màxima vàlida de l’indret. 4. Validar la distància.
4.1. SI distància calculada < distància màxima LLAVORS acceptem 5. Obtenir fotografia. 6. Executar algorisme de validació per píxels. 7. Establir connexió amb el servidor. 8. Empaquetar les dades a enviar (s’empaquetarà en una cadena de
caràcters on la primera part farà referència a l’usuari, i la segona part correspondrà a l’indret, separant les dues parts pel caràcter ‘#’).
9. Enviar paquet. 10. Finalitzar connexió. 11. Mostrar a l’usuari el missatge: “Validació correcte”.
Flux alternatiu:
4.1. Si la distància calculada és més gran que la distància màxima, es mostra el missatge de “Validació incorrecte: estàs massa allunyat de l’indret”. 6. Si es dóna el cas que la foto no ha estat validada llavors es mostra el missatge de “Validació incorrecte”. 9. Si no s’ha pogut enviar la validació, no es comptarà l’indret com a visitat.
Post-Condició: L’usuari ha visitat l’indret. A més, la seva puntuació s’ha actualitzat. Comentaris: ---
41
4.5.12. Crear itinerari
Nom: Crear itinerari Autor: Membres del grup Data 17/04/12 Descripció: Procés que crearà un itinerari manualment Actors: Usuari expert i usuari corporatiu Pre-condicions:
---
Flux principal:
1. Crear itinerari. 2. MENTRE no final FER
2.1. Buscar regió. 2.2. Mostrar indrets de la regió. 2.3. Seleccionar indret a afegir. 2.4. Afegir indret a l’itinerari. 2.5. Obtenir regió de l’indret. 2.6. Afegir a l’itinerari la regió obtinguda.
3. Íntroduir nom de l’itinerari. 4. Guardar nom. 5. Desar itinerari. 6. Mostrar missatge: “Ítinerari creat”
Flux alternatiu:
En qualsevol moment, l’usuari pot decidir cancel·lar l’operació. En aquest cas, es destruirà l’itinerari creat.
Post-Condició: Itinerari creat amb els seus indrets, les corresponents regions i amb un nom assignat.
Comentaris: En el punt 2.1, el fet de buscar regió és opcional perquè d’una mateixa regió ens pot interessar seleccionar més d’un indret sense haver de tornar a realitzar aquesta cerca.
4.5.13. Generació automàtica d’itinerari
Nom: Generació automàtica d’itinerari Autor: Membres del grup Data 17/04/12 Descripció: Procés que crearà un itinerari de forma automàtica Actors: Sistema Pre-condicions:
L’usuari ha d’indicar un indret inicial i una distància concreta que servirà de radi.
Flux principal: Veure annex [Annex II] Flux alternatiu:
Post-Condició: Itinerari creat amb els seus indrets, les corresponents regions i amb un nom assignat.
Comentaris: ---
42
4.5.14. Veure classificació global i tots
Nom: Veure classificació global i tots Autor: Membres del grup Data 22/04/12
Descripció: Procés que calcularà la classificació actual de tots els usuaris de tots els països
Actors: Usuari Pre-condicions:
-
Flux principal:
1. Obtenir llista d’usuaris de l’aplicació. 2. Ordenar de forma decreixent els usuaris per puntuació. 3. Obtenir els 10 primers usuaris de l’ordenació. 4. Obtenir puntuació de l’usuari sol·licitant. 5. Crear un llistat a partir dels 10 usuaris seleccionats que contingui
només el nom de l’usuari i la seva puntuació. 6. Enviar aquest llistat i la puntuació de l’usuari sol·licitant.
Flux alternatiu:
-
Post-Condició: S’enviarà el llistat dels 10 primers usuaris millors classificats de tota l’aplicació i de tots els països, i la puntuació de l’usuari sol·licitant.
Comentaris: - Si hi ha empat a la classificació, s’ordenarà de forma alfabètica - Si no hi ha més de 10 usuaris, es mostraran tots.
4.5.15. Veure classificació global i amics
Nom: Veure classificació global i amics Autor: Membres del grup Data 22/04/12
Descripció: Procés que calcularà la classificació actual dels usuaris amics de l’usuari sol·licitant de tots els països
Actors: Usuari Pre-condicions:
-
Flux principal:
1. Obtenir usuari sol·licitant. 2. Obtenir llista d’amics de l’aplicació de l’usuari sol·licitant. 3. Afegir l’usuari sol·licitant a la llista obtinguda al punt anterior. 4. Ordenar de forma decreixent els usuaris de la llista per puntuació. 5. Obtenir els 10 primers usuaris de l’ordenació. 6. Obtenir puntuació de l’usuari sol·licitant. 7. Crear un llistat a partir dels 10 usuaris seleccionats que contingui
només el nom de l’usuari i la seva puntuació. 8. Enviar aquest llistat i la puntuació de l’usuari sol·licitant.
Flux alternatiu:
-
Post-Condició: S’enviarà el llistat dels 10 primers usuaris millors classificats de la llista d’amics de l’usuari sol·licitant i de tots els països, i la puntuació de l’usuari sol·licitant.
Comentaris: - Si hi ha empat a la classificació, s’ordenarà de forma alfabètica - Si no hi ha més de 10 usuaris, es mostraran tots.
43
4.5.16. Veure classificació països i tots
Nom: Veure classificació països i tots Autor: Membres del grup Data 22/04/12
Descripció: Procés que calcularà la classificació actual de tots els usuaris d’un país concret.
Actors: Usuari Pre-condicions:
L’usuari haurà d’haver seleccionat un país de la llista de països on hi ha indrets a visitar.
Flux principal:
1. Obtenir país seleccionat. 2. Obtenir llista de regions del país. 3. PER cada regió de la llista FER
3.1. SI la regió té altres regions LLAVORS afegir-les a la llista de regions 3.2. SI la regió té indrets LLAVORS afegir-los a la llista d’indrets FPER
4. PER cada indret de la llista FER 4.1. Obtenir els Índrets Visitats de l’indret. 4.2. Afegir-los a la llista d’Índrets Visitats. FPER
5. Crear una estructura de dades funcional (EDF) que tingui el nom de l’usuari per clau i la puntuació per valor.
6. PER cada Indret Visitat FER 6.1. Obtenir usuari de l’Índret Visitat. 6.2. Obtenir indret de l’Índret Visitat. 6.3. Obtenir nom de l’usuari. 6.4. Obtenir puntuació de l’indret. 6.5. Actualitzar l’EDF amb el nom de l’usuari i la puntuació de l’indret FPER
7. Ordenar de forma decreixent els usuaris de l’EDF per puntuació. 8. Obtenir els 10 primers usuaris de l’ordenació. 9. SÍ l’usuari sol·licitant existeix a l’EDF LLAVORS
9.1. Obtenir la seva puntuació ALTRAMENT 9.2. Puntuació de l’usuari = 0 FSI
10. Crear un llistat a partir dels 10 usuaris seleccionats que contingui només el nom de l’usuari i la seva puntuació.
11. Enviar aquest llistat i la puntuació de l’usuari sol·licitant. Flux alternatiu:
-
Post-Condició: S’enviarà el llistat dels 10 primers usuaris millors classificats de tota l’aplicació i d’un país concret, i la puntuació de l’usuari sol·licitant d’aquest país concret.
Comentaris: - Si hi ha empat a la classificació, s’ordenarà de forma alfabètica - Si no hi ha més de 10 usuaris, es mostraran tots.
44
4.5.17. Veure classificació països i amics
Nom: Veure classificació països i amics Autor: Membres del grup Data 22/04/12
Descripció: Procés que calcularà la classificació actual dels usuaris amics de l’usuari sol·licitant d’un país concret.
Actors: Usuari Pre-condicions:
L’usuari haurà d’haver seleccionat un país de la llista de països on hi ha indrets a visitar.
Flux principal:
1. Obtenir usuari sol·licitant. 2. Obtenir llista d’amics de l’aplicació de l’usuari sol·licitant. 3. Afegir l’usuari sol·licitant a la llista obtinguda al punt anterior. 4. Obtenir país seleccionat. 5. PER cada usuari de la llista FER
5.1. Obtenir els Índrets Visitats de l’usuari 5.2. Afegir-los a la llista d’Índrets Visitats FPER
6. Crear una estructura de dades funcional (EDF) que tingui el nom de l’usuari per clau i la puntuació per valor.
7. PER cada Indret Visitat de la llista FER 7.1. Obtenir l’indret de l’Índret Visitat 7.2. Obtenir la regió de l’Índret 7.3. Obtenir el país de la regió 7.4. SI el país de la regió és igual al país seleccionat al principi LLAVORS 7.4.1. Obtenir usuari de l’Índret Visitat 7.4.2. Obtenir nom de l’usuari 7.4.3. Obtenir puntuació de l’indret 7.4.4. Actualitzar l’EDF amb el nom de l’usuari i la puntuació de l’indret FPER
8. Ordenar de forma decreixent els usuaris de l’EDF per puntuació. 9. Obtenir els 10 primers usuaris de l’ordenació. 10. Obtenir la puntuació de l’usuari sol·licitant a partir de l’EDF 11. Crear un llistat a partir dels 10 usuaris seleccionats que contingui
només el nom de l’usuari i la seva puntuació. 12. Enviar aquest llistat i la puntuació de l’usuari sol·licitant.
Flux alternatiu:
-
Post-Condició: S’enviarà el llistat dels 10 primers usuaris millors classificats de la llista d’amics de l’usuari sol·licitant i d’un país concret, i la puntuació de l’usuari sol·licitant d’aquest país concret.
Comentaris:
- Si hi ha empat a la classificació, s’ordenarà de forma alfabètica. - Si no hi ha més de 10 usuaris, es mostraran tots. - Si algun usuari de la llista d’amics no ha visitat cap indret del país seleccionat, aleshores la puntuació d’aquest usuari en el país és de 0.
45
4.5.18. Suggerir indret
Nom: Suggerir indret Autor: Membres del grup Data 24/04/12
Descripció: Procés que suggerirà als administradors un nou indret per incloure’l a la següent versió de l’aplicació.
Actors: Usuari expert i usuari corporatiu Pre-condicions:
La fotografia ha de tenir associades unes coordenades GPS.
Flux principal:
1. Íntroduir nom de l’indret. 2. Adjuntar fotografia amb coordenades GPS. 3. Breu descripció del lloc. 4. Obtenir nom d’usuari. 5. Enviar suggeriment.
Flux alternatiu:
En tot moment es pot cancel·lar l’operació. Si és així, s’esborraran les dades introduïdes fins al moment.
Post-Condició: Suggeriment enviat als administradors.
Comentaris: L’obtenció del nom de l’usuari és important perquè un cop l’administrador rebi el suggeriment, buscarà quin tipus d’usuari l’ha realitzat per saber si és prioritari o no.
4.5.19. Mostrar itinerari
Nom: Mostrar itinerari Autor: Membres del grup Data 24/04/12 Descripció: Procés que mostrarà per pantalla un itinerari. Actors: Usuari Pre-condicions:
L’usuari ha d’haver seleccionat un itinerari concret i se l’ha d’haver descarregat prèviament.
Flux principal:
1. Obtenir regions. 2. Obtenir la seqüència d’indrets de l’itinerari seleccionat. 3. Mostrar les regions. 4. PER i DE 0 FINS nombre d’indrets FER
4.1. Mostrar l’indret de la posició i 4.2. Unir l’indret de la posició i-1 amb l’indret de la posició i FPER
Flux alternatiu:
En el punt 4.2, el primer indret no tindrà cap altre indret amb qui unir-se.
Post-Condició: Es mostrarà per pantalla un itinerari concret, amb les seves respectives regions i els seus indrets units entre ells.
Comentaris: ---
46
4.5.20. Mostrar llista d’amics
Nom: Mostrar llista d’amics Autor: Membres del grup Data 24/04/12 Descripció: Procés que mostrarà la llista d’amics d’un usuari concret. Actors: Usuari Pre-condicions:
-
Flux principal:
1. Obtenir del servidor els amics de l’usuari 2. indexInici = Calcular índex d’inici segons paginació 3. MENTRE i < 10 I (i + indexInici) < nombre d’amics FER
3.1. Mostrar l’amic de la posició (i + indexInici) 3.2. i = i + 1
4. Mostrar paginació Flux alternatiu:
Post-Condició: Es mostrarà per pantalla la llista d’amics de deu en deu. Comentaris: La paginació inicial serà de zero fins que l’usuari no indiqui el contrari.
4.5.21. Afegir usuari
Nom: Afegir usuari Autor: Membres del grup Data 24/04/12 Descripció: Procés que afegirà un nou usuari al sistema. Actors: Sistema Pre-condicions:
L’usuari ha omplert el formulari per donar-se d’alta
Flux principal: 1. Comprovar que el nom d’usuari no existeix al sistema 2. Crear usuari 3. Assignar nom
Flux alternatiu:
En el cas que el nom ja existeixi, no es permetrà l’alta de l’usuari i es mostrarà el missatge: “Usuari ja existent”.
Post-Condició: Es donarà d’alta a l’usuari a la nostra base de dades Comentaris: S’han de tenir en compte tots els elements d’inicialització
47
4.5.22. Inhabilitar usuari
Nom: Inhabilitar usuari Autor: Membres del grup Data 24/04/12 Descripció: Procés que inhabilitarà l’usuari. Actors: Administrador Pre-condicions:
L’usuari ha d’existir
Flux principal: 1. Marcar l’usuari com a usuari inhabilitat Flux alternatiu:
Post-Condició: L’usuari ha estat inhabilitat de l’aplicació
Comentaris: L’usuari inhabilitat no s’esborra de la base de dades, ni tampoc els continguts que hi fan referència.
4.5.23. Afegir indret
Nom: Afegir indret Autor: Membres del grup Data 24/04/12 Descripció: Procés que afegirà un indret a la nostra aplicació. Actors: Administrador Pre-condicions:
Si es vol afegir un indret a partir de suggeriments, un usuari ha d’haver fet un suggeriment
Flux principal:
1. SI validar suggeriment LLAVORS 1.1. Crear indret a partir de la informació del suggeriment 1.2. Obtenir nom de la regió del suggeriment 1.3. Buscar regió a partir del nom
2. ALTRAMENT 2.1. Inserir imatge de l’indret 2.2. Introduir coordenades de l’indret 2.3. Afegir nom de l’indret 2.4. Afegir descripció bàsica 2.5. Crear indret 2.6. Seleccionar regió
3. Afegir regió a l’indret 4. Afegir l’indret a la col·lecció d’indrets de la regió 5. Guardar a l’indret a la base de dades
Flux alternatiu:
1.3 Si no existeix el nom de la regió a la nostra base de dades no és podrà crear l’indret. L’administrador pot decidir en qualsevol moment no continuar amb el procés. Si és així, s’haurà d’eliminar tota la informació introduïda.
Post-Condició: S’ha afegit un nou indret a la base de dades del sistema Comentaris: ---
48
4.5.24. Eliminar indret
Nom: Eliminar indret Autor: Membres del grup Data 24/04/12 Descripció: Procés que eliminarà un indret de la nostra aplicació. Actors: Administrador Pre-condicions:
Flux principal:
1. Obtenir llistat d’indrets 2. Seleccionar indret a eliminar 3. Confirmació per part de l’administrador del procés d’eliminació 4. Obtenir regió de l’indret seleccionat 5. Obtenir la llista d’Índrets Visitats de l’indret seleccionat 6. Obtenir puntuació de l’indret 7. PER cada Indret Visitat FER
6.1. Obtenir usuari de l’Índret Visitat 6.2. Modificar puntuació de l’usuari segons la puntuació de l’indret 6.3. Eliminar Índret Visitat de la llista d’Índrets Visitats de l’usuari 6.4. Eliminar Índret Visitat de la llista d’Índrets Visitats de l’indret 6.5. Eliminar Indret Visitat FPER
8. Eliminar indret de la col·lecció d’indrets de la regió 9. Eliminar l’indret de la base de dades
Flux alternatiu:
3. L’administrador pot decidir no continuar amb el procés d’eliminació
Post-Condició: S’ha eliminat un indret de la base de dades del sistema Comentaris: ---
49
4.6. Diagrama d’activitat
En aquest apartat veurem un exemple de diagrama d’activitat per fer-nos una idea
del flux d’informació entre l’usuari, el sistema del mòbil i el sistema del servidor. El cas
d’ús escollit per representar el diagrama d’activitat ha estat el de “Mostrar itinerari”.
4.6.1. Mostrar itinerari
Diagrama 10. Diagrama d’activitat del cas d’ús “Mostrar itinerari”.
50
4.7. Diagrames de seqüència
Per acabar de complementar la definició d’algunes de les funcionalitats que hem
detallat a les fitxes de cas d’ús, veurem els seus corresponents diagrames de seqüència. A
partir dels mètodes i entitats que creem per a cada funcionalitat podrem aconseguir una
primera versió del diagrama de classes.
Així, els diagrames de seqüència que hem realitzat corresponen als següents casos
d’ús:
Afegir amic
Crear indret
Mostrar indret
Validar fotografia
Veure classificació global i tots
Veure incidència
Veure estadístiques
51
4.7.1. Afegir amic
Dia
gra
ma
11. D
iagram
a de seqüèn
cia del cas d’ús “A
fegir am
ic”.
52
4.7.2. Crear indret
Diagrama 12. Diagrama de seqüència del cas d’ús “Crear indret”.
53
4.7.3. Mostrar indret
Diagrama 13. Diagrama de seqüència del cas d’ús “Mostrar indret”.
54
4.7.4. Validar fotografia
Diagrama 14. Diagrama de seqüència del cas d’ús “Validar fotografia”.
55
4.7.5. Veure classificació global i tots
Diagrama 15. Diagrama de seqüència del cas d’ús “Veure classificació global i tots”.
56
4.7.6. Veure incidència
Dia
gra
ma
16. D
iagram
a de seqüèn
cia del cas d’ús “Veu
re incidèn
cia”.
57
4.7.7. Veure estadístiques
A més del diagrama de seqüència, en aquest apartat també veurem quin
tractament fem de les estadístiques a la nostra aplicació.
El problema principal que tenim a l’hora de mantenir unes estadístiques és que
tenen un elevat cost de càlcul en aplicacions grans, i sempre es desitja obtenir la
informació de forma immediata. Partint d’aquest problema intentarem definir la solució
que hem proposat i amb la que es treballarà.
La idea bàsica d’aquesta solució és mantenir un fitxer estructurat amb els resultats
de les estadístiques. Aquest fitxer es modificarà periòdicament mitjançant un procés
batch, que tornarà a calcular els valors de les estadístiques i actualitzarà la informació ja
existent al fitxer. L’avantatge de fer-ho d’aquesta manera és que, en tenir els valors ja
calculats, la consulta de les estadístiques serà ràpida i eficient, amb l’únic inconvenient que
els resultats no seran exactament els actuals.
El sistema de funcionament de les subrutines del procés batch encarregat
d’actualitzar la informació és el següent:
1. Obrir el fitxer d’estadístiques per defecte. El sistema disposarà d’un path (camí) del
fitxer i serà el fitxer amb el qual treballarem. En el cas que es volgués restablir la
informació, o començar un nou document d’estadístiques (imaginem, per exemple,
que volem guardar diferents fitxers per cada any), només hauríem de canviar el
path guardat i no hauríem de modificar el codi de l’aplicació.
2. Calcular els resultats de les estadístiques.
3. Modificar les marques necessàries del fitxer. Per exemple, si calculem el nombre
d’usuaris nous, aleshores modificarem l’apartat d’usuaris.
4. Tancar el fitxer.
Tal com hem comentat anteriorment, el principal defecte d’aquesta solució és el fet
que, en el moment de consultar els resultats de les estadístiques, probablement obtinguem
dades no actualitzades. Per aquest motiu, el procés batch s’hauria d’executar diàriament. A
més a més, aquesta decisió també la recolza el fet que alguns valors de les estadístiques
necessiten calcular-se diàriament.
Els diferents valors de les estadístiques que calcularem inicialment són:
Freqüència de visita de cada país. Per calcular aquest valor haurem de conèixer
el nombre total d’indrets visitats i el nombre d’indrets visitats per país; aleshores
només caldrà fer el càlcul de la freqüència a partir d’aquests dos valors.
Nombre de fallades de les aplicacions en els mòbils. Per calcular aquest valor
haurem de sumar el total de notificacions d’error que hàgim rebut dels usuaris. Per
tant, cada cop que hi hagi una fallada a l’aplicació, l’usuari haurà de tenir la
possibilitat de notificar-ho.
58
Nombre d’usuaris nous per dia. Per calcular aquest valor haurem d’obtenir el
nombre total d’usuaris del dia anterior (valor que tindrem guardat al mateix fitxer
d’estadístiques) i el nombre total d’usuaris actuals. Aleshores només caldrà fer la
diferència.
Plataformes més utilitzades per descarregar-se l’aplicació. Per calcular aquest
valor haurem de comptar el nombre de descàrregues que s’ha fet de la nostra
aplicació per cadascuna de les plataformes disponibles.
A continuació mostrem el diagrama de seqüència que explica els passos que se
segueixen per veure les estadístiques.
Diagrama 17. Diagrama de seqüència del cas d’ús “Veure estadístiques”.
59
4.8. Diagrama de classes inicial
Després d’estudiar els diferents casos d’ús, ja podem elaborar una primera versió
del diagrama de classes. És una primera versió perquè encara no s’ha entrat a la fase de
disseny i, conseqüentment, encara no s’hi ha aplicat cap patró.
Dia
gra
ma
18
. Pri
mer
a v
ersi
ó d
el d
iagr
ama
de
clas
ses.
60
5. Disseny
La fase de disseny ens servirà per millorar tots els resultats obtinguts a la fase
d’anàlisi.
En aquest sentit, buscarem la manera d’aplicar patrons de disseny a la versió
actual del diagrama de classes per fer-lo tan modular com sigui possible, de manera que
resisteixi a qualsevol canvi sense haver de modificar altres aspectes.
A més a més, com que ja tenim una idea dels mètodes i atributs de les classes,
també podrem definir algunes restriccions OCL que concretaran més el nostre diagrama
de classes. A partir d’aquí, també elaborarem una versió final del diagrama de classes amb
tots els mètodes i atributs rellevants.
Per acabar, dedicarem un apartat al disseny de la base de dades i del model
relacional, i ho il·lustrarem amb un diagrama entitat-relació.
61
5.1. Patrons
5.1.1. Patró Composite
A la versió inicial del diagrama de classes podem observar que la relació entre
països, regions i indrets està descrita amb associacions entre les diferents classes, i el
gruix principal recau sobre la classe Regió, que pot contenir altres regions o bé un llistat
d’indrets (o ambdues coses).
La imatge següent mostra aquesta part en el diagrama de classes inicial:
Tot i això, també podem pensar aquestes relacions com un arbre, de manera que
una regió pot tenir altres regions (sub-regions que correspondrien a les branques de
l’arbre) o bé indrets (que correspondrien a les fulles dels arbres).
En aquest cas existeix un patró estructural que resol exactament aquest tipus de
problema; es tracta del patró Composite. Aquest patró és especialment adequat quan un
programa necessita manipular estructures de dades en forma d’arbre i es vol tractar
uniformement tant les branques com les fulles.
En el nostre exemple, un objecte Regió sovint conté alguns indrets o altres objectes
Regió, de manera que és un objecte complex, a la vegada que un objecte Indret és un
objecte simple. Cal destacar també que, com que els objectes Regió i Indret tenen varis
atributs en comú, és molt més senzill i convenient tractar els dos objectes definint una
interfície.
La imatge següent mostra aquesta part en el diagrama de classes actual:
Diagrama 19. Part de la primera versió del diagrama de classes referent a la relació entre països, regions i indrets.
Diagrama 20. Part de la segona versió del diagrama de classes referent a la relació entre països, regions i indrets, amb l’aplicació del patró Composite.
62
El patró Composite està dividit en quatre parts:
El component (interfície Regió). El component és l’abstracció per les fulles i pels
compostos. Defineix una interfície que ha de ser implementada pels objectes de la
composició.
La fulla (classe Indret). Les fulles són objectes que no tenen fills. Implementen
serveis descrits per la interfície del component.
El compost (classe Sub-regió). Un compost desa els components fills a més a més
d’implementar mètodes definits per la interfície del component. Els compostos
implementen mètodes definits a la interfície del component delegant
responsabilitats als components fills. A més a més, els compostos ofereixen
mètodes addicionals per afegir, eliminar, o obtenir components.
El client (classe País). El client manipula els objectes de la jerarquia utilitzant la
interfície del component.
Un client té una referència a una estructura de dades en forma d’arbre i necessita
dur a terme operacions a tots els nodes independentment de si es tracta d’una branca o
una fulla. El client simplement obté la referència del node concret utilitzant la interfície del
component, i negocia amb el node utilitzant aquesta interfície; no és important si el nodes
és un compost o una fulla.
5.1.2. Patró Strategy
Quan l’usuari selecciona un indret i realitza la fotografia corresponent a aquest
indret, aleshores l’aplicació ha de poder determinar d’alguna manera si la fotografia es
correspon o no a l’indret. Per fer-ho, necessita validar-la a través d’algun algorisme de
validació. Per exemple, es pot determinar que una fotografia és vàlida si la posició (GPS)
de l’usuari en el moment de fer la fotografia és prou a prop de la posició fixada de l’indret, i
si algun algorisme de comprovació de píxels determina que les imatges són prou
semblants.
Per tant, com que l’algorisme pot canviar, en el diagrama de classes inicial havíem
plasmat aquesta idea afegint una classe per cada algorisme (classes Validador1,
Validador2...) que implementaven una mateixa interfície (interfície Validador).
La imatge següent mostra aquesta part en el diagrama de classes inicial:
Diagrama 21. Part de la primera versió del diagrama de classes referent a
la validació.
63
Però precisament aquest problema és el que soluciona el patró de comportament
Strategy. Hi ha situacions habituals on les classes només es diferencien pel seu
comportament. En aquests casos és una bona idea aïllar els algorismes en classes
separades per a poder seleccionar diferents algorismes en temps d’execució.
La idea és definir una família d’algorismes, cadascun d’ells encapsulat, i fer-los
intercanviables. La interfície Strategy permet variar l’algorisme independentment de la
classe client que la utilitzi.
La imatge següent mostra aquesta part en el diagrama de classes actual:
El patró Strategy està dividit en tres parts:
L’estratègia (interfície Validador). Defineix una interfície comuna a tots els
algorismes suportats. El context utilitza aquesta interfície per cridar l’algorisme
definit per l’estratègia concreta.
L’estratègia concreta (classes Validador1, Validador2...). Cada estratègia concreta
implementa un algorisme.
El context. Els objectes de context contenen una referència a l’estratègia concreta
que cal utilitzar. Quan es demana una operació, aleshores s’executa l’algorisme des
de l’objecte estratègia. El context no coneix la implementació de l’estratègia. Si fos
necessari, es podrien definir objectes addicionals per passar dades de l’objecte
context a l’objecte estratègia.
L’objecte context rep peticions del client i les delega a l’objecte estratègia. Sovint
l’estratègia concreta és creada pel client i passada al context. Des d’aquest punt els clients
interactuen només amb el context.
Diagrama 22. Part de la segona versió del diagrama de classes referent a la validació, amb l’aplicació del patró Strategy.
64
5.1.3. Patró Singleton
A la primera versió del diagrama de classes vam definir una classe especialitzada
en les estadístiques de l’aplicació. Aquesta classe ha de mantenir aspectes com ara els
països més visitats pels usuaris, índexs de creixement dels usuaris, les funcionalitats més
usades de l’aplicació, o les plataformes i versions dels dispositius des d’on s’han
descarregat l’aplicació els usuaris, entre d’altres.
Com que és una classe que s’ha d’actualitzar constantment i que afecta o està
relacionada amb gairebé tota la resta de classes, es va decidir aïllar-la del diagrama
representant així que era una classe global.
La següent imatge mostra aquesta part en el diagrama de classes inicial:
El cert, però, és que també necessitem que cada actualització de la informació que
desa aquesta classe sigui única en el temps, és a dir, que no hi pot haver més d’una
actualització simultània per qüestions de garantia de les dades. Si permetéssim
actualitzacions simultànies, es podria donar el cas que, mentre una actualització pren de
referència la informació antiga de la classe, l’altra actualització prengui de referència la
mateixa informació antiga, i no s’esperi a obtenir els resultats de la primera actualització.
D’aquesta manera estaríem perdent la informació d’una o més actualitzacions.
Aquest problema es pot resoldre utilitzant el patró de creació Singleton. A vegades
és important tenir només una instància d’una classe. Sovint els singletons s’utilitzen per
gestió centralitzada de recursos interns o externs i ofereixen un punt d’accés global a ells
mateixos.
El patró Singleton és un dels patrons de disseny més simples: involucra només una
classe que és responsable d’instanciar-se a si mateixa, per assegurar-se que no crea més
d’una instància. Al mateix temps ofereix un punt d’accés global a aquesta instància. En
aquest cas, la mateixa instància pot ser utilitzada des de qualsevol lloc, sent impossible
cridar directament el constructor cada vegada.
La implementació inclou un atribut estàtic a la classe Estadístiques (que fa de
Singleton), un constructor privat i un mètode públic estàtic que retorna una referència a
l’atribut estàtic.
Diagrama 23. Part de la primera versió del diagrama de classes referent a les estadístiques.
65
La següent imatge mostra aquesta part en el diagrama de classes actual:
5.1.4. Altres patrons
Deixant de banda els patrons de disseny aplicats que hem vist als apartats
anteriors, cal tenir clar que durant tota la fase d’anàlisi i disseny s’ha intentat tenir en
compte tots els consells que ens proposen els patrons GRASP.
Així, mentre decidíem els atributs i mètodes de les classes, fèiem ús del patró
Expert per assignar les responsabilitats a la classe adequada, a la classe experta en la
informació.
A més a més, també hem intentat mantenir en tot moment un equilibri entre una
alta cohesió i un baix acoblament, creant classes especialitzades per a dur a terme
funcionalitats més concretes, però agrupant aquelles tasques que tenien parts comunes.
Diagrama 24. Part de la segona versió del diagrama de classes referent a les estadístiques, amb l’aplicació del patró Singleton.
66
5.2. Diagrama de classes amb patrons
En aquest apartat veurem com ens queda el diagrama després d’haver-hi aplicat
els patrons esmentats en els punts anteriors.
Dia
gra
ma
25
. Seg
on
a ve
rsió
del
dia
gram
a d
e cl
asse
s, a
pli
can
t p
atro
ns.
67
5.3. Restriccions OCL
Hi ha restriccions als requeriments del nostre projecte que no es poden reflectir
mitjançant els diagrames que hem elaborat fins ara i, en general, amb qualsevol diagrama
de modelatge UML.
L’OCL (Object Constaint Language) ens permet descriure formalment aquestes
expressions en els models UML.
Així, l’objectiu principal d’afegir aquest tipus de restriccions és aconseguir un
model UML final que no tingui cap ambigüitat.
Les restriccions OCL que hem cregut necessàries al nostre model UML són les
següents:
Un usuari pertany a la llista d’amics de cadascun dels seus amics
context Usuari
inv: self.Usuari->forAll(u | u.Usuari->exists(self))
Els usuaris principiants no poden crear itineraris
context Usuari
inv: self.tipus = “principiant”
implies self.Itinerari->isEmpty()
Un usuari serà expert si ha visitat 100 o més indrets
context Usuari
inv: self.IndretVisitat->size() >= 100
implies self.tipus = “expert”
Els usuaris corporatius no poden visitar indrets
context Usuari
inv: self.tipus = “corporatiu”
implies self.IndretVisitat->isEmpty()
Els usuaris principiants no poden fer suggeriments
context Usuari
inv: self.tipus = “principiant”
implies self.Suggeriment->isEmpty()
68
Els usuaris experts podran fer tants suggeriments com indiqui la divisió entera
entre la seva puntuació i 10 (per exemple, 23 punts permeten 2 suggeriments)
context Usuari
inv: self.tipus = “expert”
implies self.Suggeriment->size() <=
self.puntuacio->div(10)
La latitud d’un indret no pot ser inferior a -90 (negatiu indica el sud)
context Indret
inv: self.posicio_latitud >= -90
La latitud d’un indret no pot ser superior a 90 (positiu indica el nord)
context Indret
inv: self.posicio_latitud <= 90
La longitud d’un indret no pot ser inferior a -180 (negatiu indica l’oest)
context Indret
inv: self.posicio_longitud >= -180
La longitud d’un indret no pot ser superior a 180 (positiu indica l’est)
context Indret
inv: self.posicio_longitud <= 180
Un itinerari ha de tenir com a mínim un indret
context Itinerari
inv: self.Indret->size() >= 1
69
5.4. Diagrama de classes final
Un cop descrites les restriccions OCL, ja estem en disposició d’elaborar la versió
final del nostre diagrama de classes. D’aquesta manera podem unir el diagrama modelat
amb UML amb el conjunt de restriccions per no deixar cap dubte sobre la relació entre les
classes. Hem esperat fins al final per expressar les restriccions perquè necessitàvem saber
els atributs i mètodes de les classes. A la versió final del diagrama de classes ja podem
observar-ne els més rellevants.
La nostra aplicació treballa conjuntament amb una base de dades que detallarem al
següent apartat quan definim el model relacional. Per aquest motiu necessita un conjunt
d’operacions específiques per fer accessos a la base de dades des de la majoria de les
classes del nostre diagrama, ja sigui per consultar-ne informació o per emmagatzemar-ne
de nova.
Per evitar un acoblament massa elevat, no podem fer que cadascuna de les classes
que necessita accedir a la base de dades implementi separadament les seves operacions,
perquè si en algun moment hi hagués la intenció de canviar la base de dades o la seva
definició, també hauríem de modificar el codi de totes aquestes classes. Així, la solució
passa per crear una nova classe especialitzada que s’encarregui de fer aquestes operacions
contra la base de dades, de manera que seria l’única classe afectada en el cas de fer
qualsevol modificació en el model relacional.
Com que aquest problema no és nou i sol aparèixer a la majoria de projectes on hi
intervé la base de dades, veurem que a la versió final del diagrama de classes aquesta
classe especialitzada no hi apareix. Ho hem decidit així per fer el diagrama més entenedor
i evitar moltes relacions cap a una mateixa classe que no només embrutiria el diagrama,
sinó que considerem que s’entén molt millor si ho expliquem textualment. Tot i això, hem
de tenir en compte que aquesta classe existeix i que és part imprescindible pel bon
manteniment i funcionament de la nostra aplicació.
70
Dia
gra
ma
26
. Ter
cera
ver
sió
del
dia
gram
a d
e cl
asse
s; v
ersi
ó f
inal
am
b m
èto
des
i a
trib
uts
.
71
5.5. Model relacional
Tal com hem anat avançant en apartats anteriors, la nostra aplicació necessitarà
treballar amb una base de dades. Per aquest motiu hem dedicat un apartat per a definir-la.
Explicarem el model relacional mostrant les taules que hauria de tenir la base de
dades i el model entitat-relació que la defineix.
Pel que fa al model entitat-relació, també es mostraran quins dels atributs de cada
entitat poden ser nuls (marcats amb una N de color blanc) i quins han de ser únics
(marcats amb una U de color vermell). Les relacions
5.5.1. Taules
Les taules del model relacional vindran estretament lligades amb les classes
persistents del nostre model.
A continuació mostrem aquestes taules, on les claus primàries estan ressaltades en
negreta, i les claus foranes en cursiva.
Usuari(usuari_id, nom, contrasenya, correu, tipus, estat,
data_registre, puntuacio)
UsuarisAmics(usuari_id1, usuari_id2)
Indret(indret_id, pais_id, subregio_id, fotografia_id, nom,
posicio_latitud, posicio_longitud)
IndretVisitat(usuari_id, indret_id, puntuacio)
Incidencia(usuari_id, indret_id, descripcio)
Subregio(subregio_id, pais_id, regio_id, nom)
Pais(pais_id, nom)
Itinerari(itinerari_id)
IndretItinerari(indret_id, itinerari_id)
PaisItinerari(pais_id, itinerari_id)
Informacio(informacio_id, indret_id, informacio_monument_id,
informacio_museu_id, descripcio)
InformacioMonument(informacio_monument_id, mapa)
InformacioMuseu(informacio_museu_id, mapa, horari)
Suggeriment(suggeriment_id, usuari_id, fotografia_id, descripcio)
Fotografia(fotografia_id, imatge)
72
5.5.2. Diagrama entitat-relació
Dia
gra
ma
27
. Dia
gram
a en
tita
t-re
laci
ó d
el m
od
el r
elac
ion
al.
73
6. Prototipatge
Com que el desenvolupament d’aquest projecte no comprèn la part
d’implementació de l’aplicació, la part de prototipatge cobra una mica més d’importància,
perquè serà l’única referència visual que podrà tenir el client de la nostra aplicació.
Els següents apartats intentaran reflectir com hauria de ser la interfície gràfica de
les funcionalitats més rellevants de l’aplicació en el cas que s’acabés implementant.
6.1. Icona
Per a representar la nostra aplicació si s’acabés publicant als diferents mercats
d’aplicacions de smartphones, hem elaborat una icona pròpia.
Consta de la part frontal d’una càmera de fotografiar, on s’ha substituït l’objectiu
per una bola del món. En definitiva, un resum de la idea del nostre projecte.
6.2. Pantalla inicial
La primera pantalla que visualitzem en entrar a l’aplicació hauria de tenir un
aspecte semblant a la següent imatge.
Figura 1. Ícona de l’aplicació.
Figura 2. Prototipus de la pantalla inicial.
74
6.3. Seleccionar indret
Si escollim l’opció de “Mapamundi” de la pantalla inicial, accedirem al mapa de tot
el món on podrem seleccionar el país d’on volem fotografiar algun indret.
A la part inferior dreta ens hi apareixerà el percentatge d’indrets visitats d’arreu
del món.
Quan haguem visitat algun país (algun dels seus indrets), aquest país quedarà
ressaltat. La tonalitat del color utilitzada per ressaltar el país significa el percentatge
d’indrets visitats d’aquell país (a més indrets visitats, més fosc).
Figura 3. Prototipus de l’opció “Mapamundi”.
Figura 4. Prototipus de l’opció “Mapamundi” amb països ressaltats.
75
Com que alguns països són molt petits i la superfície de la pantalla d’un dispositiu
mòbil és força reduïda, per fer més còmode a l’usuari la selecció d’un país es podrà fer
zoom d’aquelles zones que més interessin.
En aquest cas, mostrem un exemple on s’ha fet zoom a la part dels països
ressaltats.
6.3.1. Llista d’indrets
Un cop seleccionat el país, accedirem a una pantalla amb un mapa específic del país
i el conjunt d’indrets a visitar.
Figura 5. Prototipus de l’opció “Mapamundi” amb zoom als països ressaltats.
Figura 6. Prototipus de selecció d’un país.
76
6.3.2. Seleccionar indret concret
Quan seleccionem un dels indrets del conjunt, ja sigui des del mapa o des de la
llista, aquest indret quedarà ressaltat.
6.4. Validar fotografia
Un cop haguem seleccionat un indret concret, se’ns mostrarà la pantalla específica
d’aquell indret. Hi apareixerà el nom, les coordenades, la fotografia de l’aplicació, un espai
per a la fotografia de l’usuari, un botó d’incidències, un botó d’informació i una indicació
de validació de la fotografia.
En aquest primer prototipus podem observar un indret que encara no s’ha
fotografiat i que, per tant, no està validat (indicador de color vermell).
Figura 7. Prototipus de selecció d’un indret concret.
Figura 8. Prototipus de validació incorrecta d’un indret.
77
Un cop hem fet la fotografia i l’aplicació ens l’ha validat, l’indicador passa a color
verd i l’indret es marca com a visitat.
6.5. Classificació
Una altra opció que tenim a la pantalla inicial és la de “Classificació”. Podem
separar la classificació en diferents modes: per puntuació o per percentatge, global o per
països, i tots els usuaris o només la llista d’amistats.
6.5.1. Classificació global i tots
Classificació de tots els usuaris de l’aplicació i tots els països, per puntuació.
Figura 9. Prototipus de validació correcta d’un indret.
Figura 10. Prototipus de classificació global i de tots els usuaris, per puntuació.
78
Classificació de tots els usuaris de l’aplicació i tots els països, per percentatge.
6.5.2. Classificació global i amics
L’única diferència amb l’apartat anterior és que la llista d’usuaris seran els nostres
amics. Per això només mostrem el desplegable que deixa escollir entre les diferents
opcions de classificació, entre elles la de classificació per amics.
Figura 11. Prototipus de classificació global i de tots els usuaris, per percentatge.
Figura 12. Prototipus de selecció entre opcions de classificació.
79
6.5.3. Classificació països i tots
Classificació de tots els usuaris de l’aplicació i d’un país concret. Per seleccionar el
país, l’aplicació mostrarà un llistat de països.
Un cop hem seleccionat el país, es mostra la classificació de tots els usuaris per
aquell país concret.
Figura 13. Prototipus del llistat de països a seleccionar per obtenir la classificació per països.
Figura 14. Prototipus de classificació per països i de tots els usuaris.
80
6.5.4. Classificació països i amics
Classificació dels usuaris amics per un país concret.
6.6. Gestió d’amics
La tercer opció que ens permet la pantalla inicial és la d’“Amistats”. Quan hi
accedim veurem la llista dels nostres usuaris amics. Podem seleccionar-ne un per veure’n
la informació o buscar-lo mitjançant el cercador. Un cop seleccionat, també el podem
eliminar.
Figura 15. Prototipus de classificació per països i dels usuaris amics.
Figura 16. Prototipus de gestió d’amistats; veure informació d’un usuari amic.
81
També podem utilitzar el cercador per buscar nous usuaris. Si l’usuari que
escrivim existeix, se’ns mostrarà la seva informació i tindrem l’opció d’enviar-li una petició
d’amistat.
6.7. Àlbum de fotografies
La següent opció de la pantalla inicial és la d’“Àlbum”. Aquí podem gestionar totes
les fotografies que haguem fet dels indrets.
Figura 17. Prototipus de gestió d’amistats; buscar un nou usuari amic.
Figura 18. Prototipus de visualització de l’àlbum de fotografies.
82
Si es prem sobre una de les fotografies s’obtenen algunes característiques, com ara
la data de realització de la fotografia. Mentre visualitzem els detalls, podem prémer el botó
d’“Ínformació” per accedir al mapa, horaris o altres aspectes de l’indret, o també podem
eliminar la fotografia prement sobre el botó d’“eliminar”.
Si a l’inici de visualització de l’àlbum premem el botó d’“eliminar” en comptes de
prémer sobre una fotografia, aleshores tenim l’opció d’eliminar més d’una imatge de cop.
Seleccionem les que vulguem eliminar i premem el botó d’“OK!”.
Figura 19. Prototipus de visualització de l’àlbum de fotografies; detall de fotografia.
Figura 20. Prototipus de visualització de l’àlbum de fotografies; eliminar més d’una fotografia.
83
6.8. Itineraris
La penúltima opció de la pantalla inicial fa referència als “Ítineraris”. Si l’escollim
accedirem a una pantalla on podrem seleccionar un itinerari de la llista, que conté el nom
de l’itinerari, el nombre d’indrets que comprèn i els països que engloba.
Un cop seleccionat l’itinerari, se’ns mostra un mapa amb els indrets que comprèn
amb l’ordre especificat, on ens indica quins indrets ens falten per visitar (de color vermell)
si volem completar l’itinerari. També disposem d’una llista amb tots els indrets de
l’itinerari per seleccionar-los més còmodament.
Figura 21. Prototipus de selecció d’itineraris.
Figura 22. Prototipus de seguiment d’itinerari.
84
A més a més, els usuaris experts i els usuaris corporatius disposaran d’un botó a la
part superior dreta per crear nous itineraris. Si el premen, l’aplicació els demanarà si
volen fer la creació manual o automàtica.
Si se selecciona l’opció de creació manual, accedirem a una pantalla on podrem
indicar el nom del nou itinerari i anar afegint indrets segons l’ordre que desitgem. El botó
d’“afegir indret” ens transporta a la mateixa pantalla que utilitzàvem per seleccionar un
indret per fotografiar. L’aplicació ens anirà dient quins països estem englobant i quins
indrets tenim de moment, juntament amb el nombre total. Quan es vulgui acabar es prem
el botó de “Guardar” i l’itinerari es desarà.
Figura 23. Prototipus d’opcions de creació d’itinerari.
Figura 24. Prototipus de creació manual d’itinerari.
85
Si, d’altra banda, se selecciona l’opció de generació automàtica, aleshores
accedirem a una altra pantalla molt semblant on, a part del nom, també se’ns demanarà
que seleccionem un indret inicial i que indiquem un radi. Aleshores, podem prémer el botó
de “Generar” per crear l’itinerari automàticament i veure’n informació associada com els
països que engloba, el conjunt d’indrets (ressaltant l’indret inicial) i el nombre total
d’aquests. Si ens agrada el resultat, podem prémer el botó de “Guardar”.
6.9. Suggeriments
L’última opció de la pantalla inicial ens permet enviar suggeriments de nous
indrets. Hi haurà un espai per a fer la fotografia de l’indret i dues caixes de text per indicar
el nom i comentaris.
Figura 25. Prototipus de generació automàtica d’itinerari.
Figura 26. Prototipus d’enviament de suggeriments.
86
Annex Í: Reunions realitzades
DATA TEMA DE LA REUNIÓ
14 de febrer Primera idea del projecte a realitzar. Perfil bastant definit; sembla clar
que s’acabarà realitzant una aplicació per a telèfons mòbils.
21 de febrer Decisió final del tema del projecte.
28 de febrer
Acabar de perfilar alguns aspectes dels requeriments i començar a parlar
del contingut de les diapositives de la presentació del projecte. Decidir si
els primers prototipus creats són els que tothom s’esperava. Confirmació
dels rols de cada membre.
29 de febrer
Detallar el contingut de les diapositives. Decisió del nom del projecte,
encara que pugui patir algun canvi durant el seu desenvolupament.
Addició d’un nou requeriment.
13 de març Definir les properes tasques a realitzar: el pla de projecte i la primera
versió del diagrama de classes.
22 de març
Decidir com es redactaran els requeriments del nostre projecte i repartir
les tasques de redacció. Parlar sobre la primera idea i intentar ampliar els
requeriments. Comentar les qüestions necessàries sobre la primera
versió del diagrama de classes. Debatre alguns elements a tenir en
compte per a l’elaboració del pla de projecte.
6 d’abril
Insistir en els compliments de termini del pla de projecte. Realització dels
diagrames de casos d’ús per ensenyar-los al client a la reunió del dia 10
d’abril.
10 d’abril
Comentar alguns aspectes a modificar dels requeriments, sobretot pel
que fa a fer-los més entenedors. Posar en comú els diagrames fets fins ara
i aportar valoracions sobre possibles canvis. Deixar clar que el següent
punt és tenir el diagrama de classes més avançat. Proposar fer una llista
dels diferents casos d’ús per decidir quins necessiten fitxes de cas d’ús.
Aquestes fitxes es faran directament a nivell de programador. Anar
avançant la documentació.
17 d’abril
Parlar del diagrama de classes i de possibles millores que s’hi puguin
aplicar. Decidir les fitxes que s’han d’acabar de refinar. Proposar com a
següent pas l’elaboració del diagrama de seqüència de l’obtenció de
puntuació per part de l’usuari per observar el flux que segueix l’aplicació.
24 d’abril
Explicar els motius pels quals no s’ha complert amb la data d’entrega de
la fase d’anàlisi. S’han llistat els diagrames des seqüència necessaris per
afegir a la fase d’anàlisi, i s’ha parlat sobre l’estat de les noves dates
d’entrega. S’han establert els següents passos a dur a terme:
Fer els diagrames de seqüència a partir de les fitxes de cas d’ús.
Si a l’hora de realitzar els diagrames de seqüència cal modificar les fitxes, fer-ho i comentar-ho.
Revisió del pla de projecte.
87
Comentar possibles patrons a dur a terme: idea molt general.
Primeres opcions de restriccions OCL, tot i que no s’implementaran fins que el diagrama de classes no sigui definitiu i tingui tots els atributs i mètodes.
Cerca de possibles algorismes per a la generació automàtica d’itineraris.
1 de maig
Determinar en quin punt es troba el projecte i quin camí cal seguir.
L’objectiu més proper és perfilar el diagrama de classes afegint-hi els
patrons que es trobin adequats. Comentar si cal fer algun diagrama de
seqüència més per assegurar-nos que el diagrama de classes és correcte.
Proposar un estudi per esbrinar com calcular els punts dels itineraris en
la generació automàtica.
8 de maig
Concretar les fitxes. Omplir el diagrama de classes amb els atributs i
mètodes utilitzats als diagrames de seqüència. Assegurar-se que no es
pot aplicar cap més patró. Avançar les restriccions OCL i definir el model
relacional (taules i model entitat-relació).
15 de maig
Mantenir la data de divendres 18 de maig com a data d’entrega del
projecte final, tot i que s’entregarà físicament (en paper) el següent
dilluns. Complementar la documentació amb l’addició d’algun exemple
d’obtenció d’estadístiques i acabar el diagrama de classes.
88
Annex ÍÍ: Gen. automa tica d’itineraris
A2.1. Introducció
La generació automàtica d’itineraris no és un problema senzill. Per tant, caldrà
investigar quina estructura de dades serà la millor per emmagatzemar la informació per
agilitzar la feina a l’hora de generar els itineraris. De fet, el problema és saber com hem de
fer la cerca dels indrets per arribar a construir l’itinerari.
Però aquest problema ja és conegut com a Range Searching, que busca la manera
de fer un pre-procés per poder determinar si un conjunt concret P d’objectes, que en el
nostre cas correspondria a un conjunt d’indrets, forma part d’un determinat rang, que en
el nostre cas seria circular. Aquest problema és un dels principals temes en els quals
treballa la geometria computacional, entre molts altres.
Hem decidit que el nostre rang seria circular perquè és la millor manera
d’assegurar que la distància màxima al centre sigui la mateixa. Tot i això, el Range
Searching pot tenir diferents variants depenent, precisament, del tipus de rang. D’aquesta
manera podem tenir l’Orthogonal Range Searching per a rectangles, el Simplex Range
Searching per a figures simples, el Halfspace Range Searching per a figures dividides en
dues parts, o el Circular Range Searching per a cercles, que serà el que nosaltres
utilitzarem.
A2.2. Circular Range Searching
El principal objectiu que tindrem consistirà en realitzar una query respecte els
punts del nostre conjunt P tals que estiguin dins l’esfera de centre q i de radi r.
La idea és que tenim una triangulació T dels punts del nostre conjunt P, i un
triangle . El problema, tal com hem comentat anteriorment, consisteix en computar
tots els punts de P que estiguin dins de la circumferència de t. Aquest problema sovint
sorgeix en el conegut Higher Order Delaunay Triangulations.
En el nostre cas, el que ens preocupa és , que és el temps de resposta de la
query, , la grandària de l’estructura de dades, i , el temps de pre-procés de
l’algorisme. De fet, el nostre objectiu és que el temps de resposta no sigui més gran que la
grandària del conjunt de sortida, sense tenir en compte cap pre-procés. Així doncs,
analitzarem una tècnica eficient a la pràctica, que no utilitza cap mena de pre-
processament ni emmagatzematge addicional, que es basa en el recorregut del graf dual de
triangulació.
La tècnica proposada comença amb t, tot recorrent els seus veïns, i seguint de veí a
veí utilitzant la cerca en amplada. D’aquesta manera, anotem els punts que estan dins de la
circumferència de t. De fet, aquest mètode és útil per a qualsevol sistema de
triangulacions, però en el nostre cas ens interessa la triangulació de Delaunay.
89
Suposem que mitjançant el centre i el radi obtenim el triangle t dins d’un conjunt
de figures triangulars T, tal com es pot apreciar a la figura següent. A més, determinem el
cercle C amb radi r (descrit abans) que té el centre situat a q, concretant així la
circumferència circumscrita del triangle t.
El procediment de cerca, que comença a partir del triangle t, visita t i els seus tres
vèrtexs, representats al triangle gris de l’apartat (a) de la figura. Tot seguit, es visiten els
triangles adjacents a t, en el sentit de les agulles del rellotge o, en aquest cas, per ordre
alfabètic. Així doncs, segons l’apartat (b) de la figura anterior, es visiten els triangles a, b i
c. El següent pas consistirà en realitzar el mateix procés pels nous triangles trobats.
D’aquest nou procés, haurem de tenir en compte els vèrtexs que es trobin dins de la
circumferència. A l’apartat (c) de la figura estan representats de color negre. Per tant,
podem concloure ràpidament que l’algorisme pretén envoltar els triangles visitats tot fent
un polígon frontera, traçat amb línies discontínues a l’apartat (d) de la figura.
Cal tenir en compte que a cada iteració l’algorisme visita els triangles no visitats
adjacents a la frontera. Així, en la següent iteració es visiten els sis nous triangles adjacents
a la frontera a la vegada que s’actualitza, tal com ens mostra l’apartat (c) de la figura.
Finalment, l’algorisme acaba quan visitem algun triangle que està fora de la
circumferència C, és a dir, si tenim un conjunt de triangles visitats TV, haurem de tenir
. Així doncs, la frontera s’estén fins que envolta C, tal com es veu a l’apartat (d)
de la figura.
Figura 27. Ídea principal de l’algorisme.
90
La frontera és un polígon triangular simple de mida f, que té k punts addicionals a
l’interior. Podem afirmar que el nombre de triangles ja visitats a l’interior de la frontera és
de . Per tant, podem denotar la mida màxima de la frontera com a
, i el nombre total de triangles visitats com a T. Dit d’una altra manera, T ens
indica el nombre de triangles t’ de manera que no es buit, o sigui, |{ |
}|. Així, el temps necessari per respondre una consulta és .
El mètode proposat utilitza la triangulació com a clau amb arestes i visitant
totes aquelles arestes que tenen com a mínim un punt no més llunyà del centre q amb una
distància r. Per tant, tenim un temps esperat de funcionament de , on ( )
indica el grau esperat per cada vèrtex k dins de C. Dwyer va mostrar que pels
punts que es trien de manera uniforme a l’atzar en una bola d-dimensional. Per tant, és
raonable suposar que en la triangulació de Delaunay podem argumentar que
donat un temps esperat de funcionament de . La majoria d’aplicacions de Higher
Order Delaunay Triangulations (HODT) utilitzen Higher Order Voronoi Diagrams (HOVD)
per a determinar l’ordre d’un triangle donat. Aquest darrer mètode és emprat per a la
majoria de solucions òptimes per a problemes de rang circular de dues dimensions.
A continuació mostrem una taula de temps comparatius amb HOVD i el sistema
que hem descrit (CCRS), tenint en compte que no es comptabilitza cap temps de pre-
processament.
Algorisme Q(n) S(n) P(n)
HOVD
CCRS
Taula 3. Comparació entre HOVD i CCRS.
Ara bé, tot i ser més eficient, aquest mètode és més complex d’implementar. Aquest
és el motiu pel qual ens dedicarem a buscar un altre mètode on, tot i perdre eficiència,
guanyem en simplicitat.
A2.3. Disk/ball Range Searching Queries
Abans de res, hem d’aclarir que el que comentarem en aquest apartat és a nivell
molt general, i que l’objectiu és quedar-nos amb la idea per poder decidir quin dels dos
algorismes utilitzar si en un futur s’implementés l’aplicació.
Suposem que disposem d’un conjunt { }, on m és el número de rangs
de disk i el rang està definit pel centre i pel radi , que ens permet realitzar diferents
rangs de cerca de manera paral·lela. Així, distingim entre el rang de recomptes i el rang de
consultes que realitzem.
91
Els centres del rang i el radi es transfereixen a les matrius d’una dimensió de la
GPU, tot rebent el nom de q i r respectivament. Les consultes de Range Searching es
resolen íntegrament a la GPU utilitzant la quadrícula que conté S, que ha estat
emmagatzemada i construïda dins la GPU, i les matrius q i r.
A2.3.1. Range counting
La solució del Range counting s’emmagatzema en un matriu d’una dimensió de
mida m, on guarda el nombre de punts que conté S en el rang . Executarem un fil
d’execució per a cada rang, tenint així fins a m fils d’execució. El fil d’execució de
l’identificador global i llegeix de la memòria global q(i) i r(i), i explora una àrea que
contingui el rang. Aquesta àrea és un quadrat/cub centrat a q(i) i de cel·les de
costat. Cal tenir en compte que el nombre de cel·les de la quadrícula que són intersecades
pel quadrat/cub depenen de les dimensions de la bounding box de la quadrícula. Cada fil
d’execució travessa la seva corresponent regió en un ordre de fila/(fila, columna).
Mitjançant un comptador local, s’obté el nombre de punts continguts a
Una vegada totes les cel·les s’han travessat, el nombre de punts obtinguts
s’emmagatzema a la memòria global a . Finalment, quan tots els fils d’execució han
acabat, conté la resposta del Range counting.
A2.3.2. Range reporting
El problema del Range reporting no es pot resoldre en un únic pas perquè la mida
de la seva resposta no es pot conèixer amb anterioritat i no és possible assignar memòria
dinàmicament a la GPU. La resposta ve donada per dues matrius unidimensionals i , on
els punts continguts en el rang són emmagatzemats en posicions consecutives de
començant a la posició .
Comencem resolent el problema de Range counting definit anteriorment. A
continuació, s’executa una exploració exclusiva de prefix sum sobre la resposta del Range
counting per obtenir . L’exploració exclusiva també s’empra per emmagatzemar el
nombre total de punts obtinguts M. Aquest valor és llegit per la CPU i després s’assigna
memòria a la GPU per emmagatzemar la matriu que conté els M punts. Finalment, el
problema del Range reporting es resol utilitzant les matrius de centres q, radis r, posicions
i la quadrícula . Un cop més, s’executa un fil d’execució per cada punt de consulta. El fil
d’execució de l’identificador global i llegeix q(i) de la memòria global i calcula la posició
linealitzada j de la cel·la de la quadrícula on és continguda. La regió quadrada/cúbica es
torna a visitar i els índexs de dels punts continguts a són emmagatzemats en
posicions consecutives de , començant per .
Observem que si estem interessats en obtenir les solucions del Range Searching a
la CPU, les matrius i han de ser llegides de la GPU a la CPU. La matriu pot contenir
els punts de coordenades o els seus índexs en el vector de la quadrícula. S’ha de tenir en
compte que els índexs esmentats no coincideixen amb els índexs d’origen a S i,
conseqüentment, quan s’utilitzen els índexs, el vector de la quadrícula ha de ser llegit
cap a la CPU.
92
A2.3.3. Anàlisi de complexitat
Anomenarem I el nombre de punts continguts a les cel·les que poden intersecar-se
amb els rangs de R, i M la mida de la sortida del Range Searching. Sent n el nombre de
punts a S, en el pitjor cas i . Segons aquests valors, la complexitat de treball
del Range counting és ; de fet, cada fil d’execució visita tots els punts de les cel·les que
s’intersequen amb el seu corresponent rang. Per respondre el problema del Range
reporting, la complexitat de l’algorisme d’exploració és , on m es el nombre de
consultes de rang processades. Després, el Range reporting representa un temps
addicional de perquè tots els punts són reconsiderats, però només
s’emmagatzemen aquells que estan continguts al rang. Així, la complexitat de treball del
Range reporting és i, fent referència al nombre total de lectures i escriptures a
la memòria global, tenim un total de
accessos.
En el cas d’un conjunt S de punts uniformement distribuïts emmagatzemat en una
quadrícula amb una densitat de cel·les equivalent a , es podria fer un estudi molt més
detallat. Anomenem el nombre màxim de punts continguts a les cel·les que
s’intersequen amb un cercle/esfera de radi , on ⌈ ⌉ ⌈ ⌉ en el cas
bidimensional, i pel cas tridimensional cal afegir el terme multiplicatiu ⌈ ⌉. Utilitzant
aquesta notació, el nombre de cel·les visitades quan estem resolent un Range Searching
amb radi r és . Conseqüentment, el nombre total de punts visitats és ∑ , i la
grandària esperada de la sortida és , on V és la suma de les m àrees o volums del
rang, i B és l’àrea o volum de la bounding box que conté S. La resta de l’anàlisi no canvia.
A2.4. Conclusions
Tot i que el segon algorisme presentat sembla que només se centri en la part de la
CPU i la GPU, la idea és que podem obtenir un bon algorisme si tenim una estructura de
dades ben construïda.
En aquest punt hauríem de decidir quin dels dos algorismes seria preferible
implementar, però creiem que és un tema que, tot i que l’hem analitzat aquí, cobra més
importància si l’aplicació s’ha d’implementar. A més a més, veiem com, a nivell de
complexitat, els dos algorismes són força semblants.
93
Annex ÍÍÍ: Manual d’usuari
El manual d’usuari pretén ser una eina d’ajuda per saber com navegar per
l’aplicació si volem fer ús d’alguna funcionalitat. Així, s’explicaran les diverses opcions que
ofereix cada pantalla, començant pel registre i continuant amb les funcionalitats que
apareixen a la pantalla inicial.
A3.1. Inici de l’aplicació
El primer pas per utilitzar l’aplicació és descarregar-nos-la des del mercat
d’aplicacions del nostre dispositiu. Per exemple, si s’utilitza un sistema operatiu Android
caldrà accedir a l’Android Market (o Play Store), i si s’utilitza un sistema operatiu ÍOS
caldrà accedir a l’Apple Store. Després de buscar la nostra aplicació, podrem descarregar-
nos la versió gratuïta o la de pagament. Tant el procés de descàrrega com el d’instal·lació
es farà de forma automàtica.
Un cop descarregada i instal·lada l’aplicació, veurem que apareix la nostra icona al
conjunt d’aplicacions del nostre dispositiu. Si la premem, accedirem a l’aplicació.
Quan accedim per primera vegada a l’aplicació haurem de registrar-nos. Se’ns
mostrarà un formulari on haurem d’omplir els següents camps:
Nom d’usuari
Contrasenya
Repetició de la contrasenya
Correu electrònic
Si ja existeix un usuari a la nostra aplicació amb el mateix nom d’usuari, aleshores
es mostrarà un missatge indicant-ho i es demanarà un altre nom d’usuari. Quan tot sigui
correcte, es mostrarà la pantalla inicial de l’aplicació.
Un cop registrats ja no tornarà a aparèixer el formulari de registre les pròximes
vegades que accedim a l’aplicació.
A3.2. Funcionalitats bàsiques de l’aplicació
Quan accedim a la pantalla inicial de l’aplicació podem observar un conjunt
d’opcions a escollir de la nostra aplicació. Cadascuna d’elles està considerada com una
funcionalitat bàsica, i són les que anirem explicant en els següents apartats.
En aquest manual no s’especificarà la manera de tornar enrere en la navegació per
pantalles, perquè sol ser una característica específica del dispositiu o del sistema operatiu.
En Android, per exemple, el propi dispositiu ja la incorpora.
94
Les funcionalitats són les següents:
Mapamundi (selecció d’indrets)
Classificació
Amistats
Àlbum de fotografies
Itineraris
Suggeriments
A3.3. Mapamundi
Aquesta funcionalitat serà la més important de la nostra aplicació. Ens permetrà
seleccionar nous indrets per a fotografiar, així com informació sobre el percentatge
d’indrets visitats.
A3.3.1. Seleccionar país
A l’inici veurem la imatge d’un mapamundi sobre el qual ens podrem desplaçar. A
més a més, un país estarà pintat d’un color més fosc a mesura que es visitin més indrets
d’aquell país. Com que la superfície de la pantalla és petita i hi ha molts països per a poder
seleccionar, l’aplicació també permetrà fer zoom del mapamundi en qualsevol moment per
fer més còmode la selecció d’un país. Per fer zoom només caldrà desplaçar els dits en
direccions contràries cap enfora (per augmentar) o cap endins (per reduir).
A la part inferior dreta podrem observar en tot moment el percentatge d’indrets
visitats que tenim de tots els països.
Figura 28. Exemple de selecció de país fent zoom (augmentant).
95
A3.3.2. Seleccionar indret
Un cop haguem seleccionat un país del mapamundi, se’ns mostrarà el mapa
d’aquell país juntament amb els possibles indrets que podem visitar. Els indrets se
situaran al mapa amb un punt verd si ja els hem visitat i validat correctament, o amb un
punt vermell si encara ens falta validar-los. Si premem sobre algun d’aquests punts
accedirem a l’indret corresponent.
Com que algun país pot tenir una concentració elevada d’indrets en determinades
zones i pot ser complicat seleccionar-ne algun, també disposarem del llistat d’indrets a la
part esquerra. Si premem sobre un indret d’aquest llistat veurem com es ressalta el punt
del mapa corresponent. Per accedir a l’indret haurem de prémer la fletxa posicionada al
costat del nom.
A la part inferior dreta podrem observar en tot moment el percentatge d’indrets
visitats que tenim d’aquest país.
A3.3.3. Fotografiar indret
Després de seleccionar un indret del mapa del país accedirem a una pantalla
específica per aquell indret.
A la part superior d’aquesta pantalla hi veurem el nom de l’indret i les seves
coordenades. A la part esquerra hi haurà la imatge que ens proposa l’aplicació i a la part
dreta hi tindrem un espai per proposar la nostra fotografia. Per fer la fotografia haurem de
prémer sobre la icona de la càmera.
A part de tota aquesta informació, tenim un botó per obtenir informació de l’indret
i un altre botó per enviar una incidència en el cas que l’usuari ho cregui necessari. A més a
més, hi haurà un indicador de validació que serà de color vermell si l’indret no està validat
o de color verd si l’indret està validat.
Quan l’indret estigui validat, a la part dreta hi apareixerà la nostra fotografia.
Figura 29. Exemple de selecció d’indret.
96
A3.4. Classificació
L’usuari pot consultar la classificació de la resta d’usuaris mitjançant aquesta
funcionalitat. Podrem classificar els usuaris per la seva puntuació obtinguda en fotografiar
els indrets o bé pel percentatge d’indrets visitats que tinguin. També tindrem l’opció
d’escollir entre la classificació de tots els països o d’un país concret, i entre la classificació
de tots els usuaris de l’aplicació o només els de la nostra llista d’amistats.
L’opció per defecte serà la classificació global, de tots els usuaris i ordenada per
puntuació. Es mostraran els deu primers usuaris classificats, i si el nostre nom es troba en
aquesta llista quedarà ressaltat, destacant-se de la resta.
A més a més, a la part dreta de la pantalla hi trobarem sempre el tipus de
classificació i les nostres dades (posició, puntuació i percentatge).
Figura 30. Exemple de fotografia d’indret; indret no validat.
Figura 31. Exemple de fotografia d’indret; indret validat.
97
A la part superior dreta hi trobarem una llengüeta per seleccionar el tipus de
classificació. Si la premem se’ns desplegaran les opcions que tenim: global o per països, i
tots els usuaris o només les amistats.
Si escollim l’opció de classificació per països, aleshores l’aplicació ens proposarà un
llistat dels països on hi ha indrets per visitar.
Figura 32. Exemple de classificació global i de tots els usuaris.
Figura 33. Exemple del desplegament d’opcions de classificació.
98
Un cop seleccionat un país, veurem la classificació segons aquest i observarem el
seu nom sobre les dades de l’usuari.
A3.5. Amistats
L’aplicació també permet que cada usuari tingui una llista d’amistats (altres
usuaris que també utilitzin l’aplicació). D’aquesta manera pot saber quina puntuació o
percentatge tenen i veure’n la classificació entre ells.
A la part esquerra de la pantalla hi haurà la llista dels nostres amics, i a la part
dreta s’hi trobarà un cercador, per buscar usuaris nous o de la mateixa llista, i les dades
d’algun usuari que haguem seleccionat o buscat. De la mateixa manera que a la
funcionalitat de classificació, les dades que es mostraran dels usuaris seran la posició, la
puntuació i el percentatge global.
Figura 34. Exemple de la proposta de països per seleccionar.
Figura 35. Exemple de classificació per un país concret i de la nostra llista d’amistats.
99
Així, per saber les dades d’un usuari de la nostra llista d’amistats, l’haurem de
buscar a la llista i seleccionar-lo. Si la llista és molt extensa, podem utilitzar el cercador per
trobar-lo. Un cop seleccionat, se’ns mostraran les seves dades i s’habilitarà el botó de la
part superior dreta que permetrà eliminar l’usuari de la nostra llista d’amistats, si així ho
desitja l’usuari.
Si, per altra banda, es desitja afegir un usuari nou a la nostra llista d’amistats,
aleshores caldrà buscar el nom de l’usuari mitjançant el cercador. Si l’usuari existeix,
apareixerà la seva informació sota del cercador i s’habilitarà el botó de la part superior
dreta que permetrà enviar una petició d’amistat a l’usuari cercat.
Figura 36. Exemple de selecció d’un usuari amic.
Figura 37. Exemple de cerca d’un usuari nou.
100
A3.6. Àlbum de fotografies
Una de les altres funcionalitats de l’aplicació és la gestió de les imatges que fa
l’usuari de cada indret.
L’aplicació ofereix un àlbum de les fotografies realitzades, i l’usuari té l’opció de
prémer sobre qualsevol d’elles per veure’n els detalls. També té l’opció d’esborrar un
conjunt de fotografies prement el botó de la part superior dreta.
Si l’usuari decideix prémer sobre una de les fotografies per veure’n els detalls,
aleshores accedirem a una nova pantalla on veurem la fotografia ampliada, a la part
esquerra, i les seves característiques, a la part dreta. Pel que fa a aquestes característiques,
es mostrarà el nom de l’indret fotografiat, les seves coordenades, i la data i l’hora de la
captura.
A més a més, hi haurà un parell de botons a la part superior dreta que ens
permetran obtenir més informació sobre l’indret fotografiat (mapes, horaris...), o bé
eliminar la fotografia de l’àlbum i del dispositiu.
Figura 38. Exemple de visualització de l’àlbum de fotografies.
Figura 39. Exemple de visualització dels detalls d’una fotografia.
101
D’altra banda, si l’usuari decideix eliminar un conjunt de fotografies quan es troba
a la pantalla de visualització de l’àlbum, prement el botó corresponent, aleshores haurà de
seleccionar aquelles imatges que vol esborrar. L’aplicació enfosquirà les fotografies
seleccionades, i quan l’usuari premi el botó de confirmació, que es trobarà situat a la part
superior dreta, al mateix lloc on es trobava el botó d’eliminar, s’eliminaran aquestes
fotografies de l’àlbum i del dispositiu.
A3.7. Itineraris
A banda de la totalitat d’indrets existents, l’aplicació ofereix l’opció de fer grups
més reduïts d’indrets, que s’anomenen itineraris, per plantejar als usuaris nous reptes més
assequibles a curt termini.
Quan accedeixi a aquesta funcionalitat, l’usuari veurà a la pantalla el llistat
d’itineraris creats. Es mostrarà el nom de l’itinerari, el nombre d’indrets que comprèn i els
països que engloba. Per accedir a la informació d’un itinerari, només caldrà seleccionar-lo
a la llista. Pels usuaris experts i els usuaris corporatius, a la part superior dreta s’habilitarà
un botó que permetrà crear nous itineraris.
Figura 40. Exemple d’eliminació d’un conjunt de fotografies de l’àlbum.
Figura 41. Exemple de visualització del llistat d’itineraris de l’aplicació.
102
Una vegada haguem seleccionat un itinerari de la llista accedirem a una nova
pantalla on apareixerà, a la part dreta, un mapa amb tots els indrets indicats amb punts
(de color verd si estan validats i de color vermell si encara no ho estan) i amb la seqüència
d’ordre indicada mitjançant la línia que els uneix, i a la part esquerra, un conjunt de
característiques de l’itinerari. Entre aquestes característiques hi haurà el nom de
l’itinerari, els països que engloba, el nombre d’indrets completats i el nombre d’indrets
totals, i un llistat de tots els indrets de l’itinerari.
Per seleccionar un indret es farà de la mateixa manera que ho fèiem a la pantalla
de selecció d’indrets; prement sobre l’indret del mapa o sobre el nom de l’indret al llistat.
Si es decideix prémer el botó de creació d’itineraris, aleshores l’aplicació ens
preguntarà si volem crear l’itinerari manualment o automàticament.
Figura 42. Exemple de visualització d’un itinerari.
Figura 43. Exemple d’elecció entre creació d’itinerari manual o automàtica.
103
Si s’escull l’opció de creació manual accedirem a una nova pantalla on haurem
d’indicar el nom de l’itinerari i anar afegint nous indrets mitjançant el botó destinat a
aquesta tasca. Per afegir un nou indret després de prémer el botó, se seguiran els mateixos
passos que hem explicat a l’apartat de selecció d’indrets, partint del mapamundi.
A mesura que anem afegint indrets anirem veient, a la part dreta de la pantalla, un
llistat amb tots els indrets de l’itinerari, i a la part esquerra, el nombre total d’indrets i els
països que s’han englobat fins al moment. Quan haguem acabat d’afegir indrets, haurem de
prémer el botó de guardar per incorporar l’itinerari al conjunt d’itineraris de l’aplicació.
Si, d’altra banda, s’escull l’opció de creació automàtica d’itineraris, aleshores
accedirem a una altra pantalla on ens deixarà escollir el nom de l’itinerari, l’indret inicial i
el radi màxim entre l’indret inicial i la resta d’indrets. Per seleccionar l’indret inicial,
després de prémer el botó corresponent, seguirem els mateixos passos que hem explicat a
l’apartat de selecció d’indrets, partint del mapamundi.
A més a més, també se’ns informarà dels països que engloba l’itinerari i del
nombre total d’indrets, a la part inferior esquerra, i del nom dels indrets afegits, a la part
dreta. De tots els noms dels indrets, el nom de l’indret inicial quedarà ressaltat, destacant-
se de la resta.
Un cop haguem omplert totes les dades que ens demanen, podrem dir-li a
l’aplicació que ens creï l’itinerari automàticament mitjançant el botó de generar. Si ens
sembla correcte, podrem incorporar-lo a la llista d’itineraris de l’aplicació prement el botó
de guardar.
Figura 44. Exemple de creació manual d’itineraris.
104
A3.8. Suggeriments
Com a última funcionalitat de l’aplicació, els usuaris experts i els usuaris
corporatius tindran l’opció d’enviar suggeriments de nous indrets per incorporar-los a la
següent versió de l’aplicació.
Per fer-ho, accedirem a una pantalla que ens demanarà, a la part dreta, el nom de
l’indret i els comentaris que creiem oportuns per justificar l’addició de l’indret a la
pròxima versió. També ens exigirà, a la part esquerra, que fem una fotografia de l’indret
seguint els mateixos passos que fèiem quan fotografiàvem un indret de l’aplicació.
Finalment, si premem el botó d’enviar, el suggeriment arribarà als administradors
perquè el puguin considerar.
Figura 45. Exemple de generació automàtica d’itineraris.
Figura 46. Exemple de formulari de suggeriment.
105
Annex ÍV: Control d’hores
Per comprovar si havíem fet una bona planificació inicial i per aprendre d’aquests
possibles errors de planificació, s’ha mantingut un control de les hores destinades a cada
tasca del projecte per cada membre del grup. Així, si sumem les hores de cada membre
podem observar si les hores que havíem planificat al principi són realment les que hem
acabat fent.
Pla Proj. Requer. Anàlisi Disseny Prototip. Document.
Total hores 15 44 70 106 26 23
Taula 4. Nombre d’hores realitzades per cada tasca del projecte.
Evidentment, veiem que no coincideixen amb les hores previstes inicialment, i
podem admetre que hem sigut massa optimistes a l’hora d’estimar el temps necessari de
realització d’alguna de les tasques.
Pel que fa al nombre d’hores destinades al projecte per cada membre del grup, la
taula següent en mostra els resultats.
Total hores
Pau Xiberta i Armengol 83
Jordi Cazorla Riera 69
Ivan Rando Segura 68
Eduard Rando Segura 64
TOTAL 284
Taula 5. Nombre d’hores realitzades per cada membre del grup.
Per acabar, mostrem una taula significativa de la dedicació de cada membre del
grup a cada tasca del projecte. No és difícil adonar-se que aquesta dedicació coincideix
bastant amb el rol assumit per cada membre del grup.
Pla Proj. Requer. Anàlisi Disseny Prototip. Document.
Pau Xiberta i Armengol 2 11 23 25 14 8
Jordi Cazorla Riera 6 12 11 22 6 12
Ivan Rando Segura 2 13 22 27 3 1
Eduard Rando Segura 5 8 14 32 3 2
Taula 6. Nombre d’hores dedicades per cada membre del grup a cada tasca del projecte.
