proyecto!final!decarrera bcnlook$&find

124
Proyecto Final de Carrera BCN Look & Find Tu sitio web de objetos perdidos y encontrados en Barcelona y alrededores Título BCN Look & Find. Sitio web de objetos perdidos y encontrados en Barcelona y alrededores Autor David Santiso Puigarnau Fecha 28 de marzo de 2012 Directora Ana Edelmira Pasarella Sánchez Codirectora Amalia Duch Brown Departamento Lenguajes y Sistemas Informáticos (LSI) Titulación Ingeniería en Informática Técnica de Gestión Centro Facultat d’Informàtica de Barcelona (FIB) Universidad Universitat Politècnica de Catalunya (UPC) Barcelona Tech

Upload: others

Post on 01-Aug-2022

1 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: Proyecto!Final!deCarrera BCNLook$&Find

   

 

 

 

     

Proyecto  Final  de  Carrera  

BCN  Look  &  Find  Tu  sitio  web  de  objetos  perdidos  y  encontrados  en  Barcelona  y  alrededores  

Título   BCN  Look  &  Find.  Sitio  web  de  objetos  perdidos  y  

encontrados  en  Barcelona  y  alrededores  

Autor   David  Santiso  Puigarnau  

Fecha   28  de  marzo  de  2012  

Directora   Ana  Edelmira  Pasarella  Sánchez  

Codirectora   Amalia  Duch  Brown  

Departamento   Lenguajes  y  Sistemas  Informáticos  (LSI)  

Titulación   Ingeniería  en  Informática  Técnica  de  Gestión  

Centro   Facultat  d’Informàtica  de  Barcelona  (FIB)  

Universidad   Universitat  Politècnica  de  Catalunya  (UPC)  Barcelona  Tech  

Page 2: Proyecto!Final!deCarrera BCNLook$&Find

   

1    

Agradecimientos  

Quiero   agradecer   a  RDLab-­‐LSI   la   colaboración   en   el   proyecto,   prestando   un   servidor   donde  alojar   el   sistema  BCN  Look  &  Find   con  acceso  público   y  en  especial   a  Gabriel  Verdejo  por   la  constante   colaboración   y   ayuda   resolviendo   dudas   técnicas   en   el   proceso   de   instalación   del  sistema   en   el   servidor.   También   agradezco   a   todos   los   usuarios   que   han   colaborado   en   el  testeo  del  sitio  web,  proponiendo  funcionalidades,  mejoras  de  diseño,  usabilidad,  etc.  

   

Page 3: Proyecto!Final!deCarrera BCNLook$&Find

   

2    

Motivación  personal  

Tiempo  atrás  el  análisis,  desarrollo  y  diseño  web  comenzó  a  despertar  mi  interés.  Pensé  que  el  proyecto   final   de   carrera   era   una   buena   oportunidad   para   adentrarme   en   este   mundo   y  aprender,  a  la  par  que  plasmar  algo  de  lo  aprendido  en  la  carrera.  

Buscando  entre  propuestas  de  proyectos  relacionados  con  este  campo,  topé  con  la  de  Amalia  Duch   y   Edelmira   Pasarella   que   tenían   una   idea   que   prometía   ser   interesante.   Su   propuesta  consistía  en  crear  BCN  Look  &  Find,  un  sitio  web  que  hiciera  de  intermediario  entre  personas  que   pierden   y/o   encuentran   objetos   en   la   ciudad   de   Barcelona   y   alrededores.   El   sitio   debía  permitir   el   registro   y   búsqueda   de   objetos   y   facilitar   el   contacto   entre   las   personas  involucradas.  

Inicialmente  la  idea  me  gustó,  pero  a  su  vez  me  sentía  escéptico  pensando  que  era  difícil  que  la  gente  que  pierde  y  encuentra  objetos  se  parara  a  utilizar  el  sitio  web.  Mi  escepticismo  duró  poco.  Lo  que  tardé  en  comenzar  a  ver  sitios  web  con  el  mismo  propósito  o  con  funcionalidades  similares,   cuyo   desarrollo,   diseño,   uso,   etc.,   dejaban   mucho   que   desear   y   aun   así   eran  utilizados.  

   

Page 4: Proyecto!Final!deCarrera BCNLook$&Find

   

3    

Índice  

1   Introducción  ..........................................................................................................................  5  

2   Preliminares  ...........................................................................................................................  7  

2.1   Conceptos  básicos  ..........................................................................................................  7  

2.2   Conocimientos  técnicos  ..................................................................................................  7  

2.3   Análisis  de  sistemas  de  gestión  de  contenido  ................................................................  8  

3   Especificación  del  sistema  ...................................................................................................  11  

3.1   Análisis  de  otros  sitios  web  ...........................................................................................  11  

3.2   Usuarios  ........................................................................................................................  23  

3.3   Objetos  .........................................................................................................................  23  

3.4   Casos  de  uso  .................................................................................................................  26  

3.5   Diagramas  de  secuencia  ...............................................................................................  49  

3.6   Flujo  de  objeto  perdido  ................................................................................................  52  

3.7   Flujo  de  objeto  encontrado  ..........................................................................................  53  

3.8   Clases  ............................................................................................................................  54  

3.9   Diseño  de  la  interfaz  .....................................................................................................  58  

4   Desarrollo  del  sistema  .........................................................................................................  75  

4.1   Introducción  al  sistema  eZ  Publish  ...............................................................................  75  

4.2   Instalación  del  sistema  .................................................................................................  84  

4.3   Desarrollo  de  secciones  básicas  ....................................................................................  85  

4.4   Objeto  encontrado  y  objeto  perdido  ............................................................................  86  

4.5   Categorías  de  objeto  .....................................................................................................  89  

4.6   Estados  de  objeto  .........................................................................................................  89  

4.7   Usuarios  ........................................................................................................................  90  

4.8   Desarrollo  de  la  página  principal  ..................................................................................  95  

4.9   Desarrollo  de  la  sección  Comunidad  ............................................................................  97  

4.10   Desarrollo  del  menú,  cabecera  y  pie  de  página  .........................................................  97  

4.11   Extensión  de  diseño  del  sistema  eZ  Publish  ...............................................................  98  

4.12   Extensión  funcional  del  sistema  eZ  Publish  ..............................................................  103  

4.13   Posicionamiento  del  sitio  web  y  otros  desarrollos  ...................................................  108  

5   Experimentación  ................................................................................................................  110  

5.1   Pruebas  de  usuario  .....................................................................................................  110  

5.2   Encuestas  ....................................................................................................................  112  

Page 5: Proyecto!Final!deCarrera BCNLook$&Find

   

4    

6   Gestión  del  proyecto  .........................................................................................................  113  

6.1   Estimación  inicial  ........................................................................................................  113  

6.2   Resultado  final  ............................................................................................................  115  

7   Conclusiones  ......................................................................................................................  117  

8   Propuestas  de  trabajo  futuro  ............................................................................................  118  

Bibliografía  ...............................................................................................................................  120  

   

Page 6: Proyecto!Final!deCarrera BCNLook$&Find

   

5    

1 Introducción  

Según  el  artículo  “La  Oficina  de  Hallazgos  de  Barcelona  devuelve  a  sus  propietarios  el  86%  de  los   objetos   perdidos   que   le   llegan”,   del   día   07   de   Febrero   de   2011,   del   periódico   “La  Vanguardia”  (1),  en  la  ciudad  de  Barcelona  se  pierden  miles  de  objetos  al  año  de  los  cuales,  en  el  año  2010,  llegaron  30.763  a  la  oficina  de  hallazgos  del  Ayuntamiento  de  Barcelona.  De  estos  objetos,  el  86%  logró    ser  devuelto  a  sus  propietarios.  

Un   reto   importante   de   la   susodicha   oficina   es   poder   devolver   el   porcentaje   restante   de  objetos,  además  de  otros  que  no  están  siendo  registrados  en  esta  oficina  del  Ayuntamiento  de  Barcelona.   Para   ello   es   muy   importante   poder   facilitar   a   las   personas   que   pierden   o  encuentran  objetos  en  esta  ciudad  la  posibilidad  de  registrar  esta  información.  

Una  manera  de  llevar  a  cabo  esta  tarea  es  aprovechando  Internet.  De  hecho  ya  existen  varias  plataformas  (que  se  analizan  más  adelante),  con  este  fin.  Sin  embargo,  desde  nuestro  punto  de  vista,   todas   ellas   presentan   serios   inconvenientes.   Por   este   motivo,   en   este   proyecto   se  propone   desarrollar   un   sitio   web   2.0   que   subsane   la  mayoría   de   los   problemas   que   hemos  detectado.   En   particular   incluimos   el   tratamiento   de   centros   de   objetos   perdidos   que  curiosamente  no  se  tienen  en  cuenta  en  ninguna  de  las  plataformas  que  hemos  encontrado.  

El   objetivo   principal   del   proyecto   es   crear   una  plataforma  web   lo  más   segura,   consistente   y  usable   posible,   con   la   finalidad   de   hacer   de   intermediario   entre   personas   que   pierden   y  encuentran  objetos  perdidos  en   la  provincia  de  Barcelona  y  alrededores.  Y   facilitar  a  oficinas  de   objetos   perdidos,   lugares   o   transportes   públicos,   comisarías   de   policía   y   cualquier   otro  centro   donde   se   depositan   objetos   perdidos,   la   labor   de   devolver   estas   pertenencias   a   sus  propietarios.  

El  objetivo  principal  se  puede  desglosar  en  varias  sub-­‐tareas.  

• Analizar  los  déficits  y  los  puntos  fuertes  de  otros  sitios  webs  con  la  misma  finalidad.  • Estudiar  Sistemas  de  Gestión  de  Contenido.  

o Aprender  qué  es  un  Sistema  de  Gestión  de  Contenido.  o Analizar   y   comparar   Sistemas   de   Gestión   de   Contenido   web   de   libre  

distribución,  más  populares.  o Seleccionar   un   Sistema   de   Gestión   de   Contenido   sobre   el   que   desarrollar   el  

sistema  BCN  Look  &  Find.  o Aprender   a   utilizar   y   familiarizarse   con   el   Sistema   de   Gestión   de   Contenido  

seleccionado.  • Especificar  el  sistema  BCN  Look  &  Find.  • Desarrollar  el  sistema  BCN  Look  &  Find.  • Realizar  pruebas  de  funcionalidad  del  sitio  web.  

o Simular  uso  del  sitio  web.  o Obtener  opiniones  de  usuarios  reales.  o Mejorar   el   sitio   web   en   función   de   los   resultados   de   los   casos   de   pruebas  

obtenidos.  

Page 7: Proyecto!Final!deCarrera BCNLook$&Find

   

6    

• Meditar  y  exponer  funcionalidades,  extensiones,  mejoras,  etc.,  para  posibles  trabajos  futuros  del  proyecto  BCN  Look  &  Find.  

A   continuación   se  describe   cómo   se  ha  estructurado   la  memoria   con   la   finalidad  de  guiar   al  lector.  

• En  la  Sección  2,  se  describen  algunos  conceptos  básicos,  tanto  técnicos  como  teóricos,  que  irán  apareciendo  a  lo  largo  de  la  memoria.  Además  se  hará  un  análisis  de  sistemas  de  gestión  de  contenido,  para  escoger  el  más  adecuado  para   la  creación  del   sistema  BCN  Look  &  Find.  

• En  la  Sección  3,  se  describe  la  especificación  del  sistema.  Primero  de  todo  se  hace  un  análisis  de  otros  sitios  web  con  el  mismo  objetivo  que  BCN  Look  &  Find,  para  extraer  ideas   y   así   decidir   que   tipo   de   funcionalidades   y   qué   diseño   tendrá   el   sistema.  Posteriormente  se  especificarán  los  tipos  y  roles  de  usuarios  que  interactuarán  con  él,  casos  de  uso,  clases,  etc.  

• En  la  Sección  4,  se  describe  cómo  se  ha  llevado  a  cabo  el  desarrollo  del  sistema.  • En   la   Sección   5,   se   describe   la   experimentación   que   se   ha   llevado   a   cabo,   para  

comprobar   si   el   sistema   cumple   con   los   objetivos   expuestos   anteriormente.   Y   en   el  caso  de  no  ser  así,  qué  cambios  se  han  tenido  que  llevar  a  cabo  para  solucionarlo.  

• En   la   Sección   6,   se   expone   la   gestión   del   proyecto.   El   tiempo,   recursos   y   costes  estimados   inicialmente  para   llevar   a   cabo  el   proyecto   y   el   tiempo,   recursos   y   costes  reales  que  finalmente  han  sido  necesarios.  

• En   la  penúltima  sección,  se  exponen  las  conclusiones  a   las  que  se  ha   llegado  una  vez  terminado  el  proyecto.  

• Finalmente  se  exponen  algunas  de  las  posibles  extensiones  del  proyecto,  a  desarrollar  en  un  futuro.    

Page 8: Proyecto!Final!deCarrera BCNLook$&Find

   

7    

2 Preliminares  

2.1 Conceptos  básicos  

En   esta   memoria   se   mencionarán   algunos   conceptos   cuyas   definiciones   se   muestran   a  continuación.  

• Web   2.0.   Según  Wikipedia   (2),   un   sitio  web  es   2.0   cuando  permite   que   los   usuarios  interactúen   con   él.   Ya   sea   comunicándose   con   otros   usuarios,   compartiendo  información  o  de  cualquier  otro  modo.  El  sitio  web  que  se  pretende  crear  es  2.0  ya  que  es  necesaria  una  interacción  de  los  usuarios,  registrando  datos  de  objetos  entre  otras  cosas  y  una  comunicación  entre  ellos.  

• URL.   Según   Wikipedia   (3),   una   URL   (Localizador   uniforme   de   conceptos),   es   una  secuencia   de   caracteres,   de   acuerdo   a   un   formato  modélico   y   estándar,   que   se   usa  para  nombrar  recursos  en  Internet  para  su  localización  o  identificación.  

• Formularios   POST   y   GET.   En  el   lenguaje  de  programación  web  HTML,  definido  en   la  siguiente  sección,  se  utilizan  estos  dos  métodos  para  la  creación  de  formularios.  Estos  formularios  según  WebTaller  (4)  son  una  de  las  herramientas  de  las  que  se  dispone  a  la  hora   de   hacer   sitios   web   interactivas,   en   el   sentido   de   que   permite   recopilar  información  del  usuario  que  ve   la  página,  procesarla  y  responder  a  ella,  pudiendo  de  esta  forma  responder  adecuadamente  a  sus  acciones  o  peticiones.  POST  y  GET  son  los  métodos  que  se  utilizan  para  transferir  las  variables  del  formulario.  GET  envía  los  datos  añadiéndolos  al  URL  de  manera  transparente  al  usuario.  El  método  POST  los  envía  de  manera  oculta.  

• SEO.  Según  Wikipedia  (5),  el  posicionamiento  es  el  proceso  de  mejorar  la  visibilidad  de  un   sitio   web   en   los   diferentes   buscadores   como   Google,   Yahoo   o   Bing   de   manera  orgánica,   es   decir   sin   pagarle   dinero   al   buscador   para   tener   acceso   a   una   posición  destacada  en  los  resultados.  

2.2 Conocimientos  técnicos  

A  continuación  se  presentan  algunos  conceptos  necesarios  para  realizar   la  especificación  y  el  desarrollo  del  sistema  BCN  Look  &  Find.  

• Notación  UML  para   la  especificación  de   los   casos  de  uso,  diagramas  de   flujo,   clases,  etc.   La   documentación   de   apoyo   ha   sido   extraída   del   libro   “Enginyeria   del   Software  Especificació”  (6).  

• Arquitectura,  usabilidad  y  diseño  web  para  la  creación  de  un  sitio  web  que  garantice  una   buena   experiencia   de   usuario.   La   documentación   de   apoyo   ha   sido   extraída  del  documento  “Arquitectura  de   la   informació:  Garanteix  una  bona  experiència  d'usuari”  (7).  

Los   conocimientos   técnicos   previos   para   el   desarrollo   del   sistema   dependen   en   parte   del  sistema  de  gestión  de  contenidos  escogido,  pero  generalmente  se  suelen  utilizar  los  siguientes  lenguajes  para  el  desarrollo  web.  

Page 9: Proyecto!Final!deCarrera BCNLook$&Find

   

8    

• Lenguaje  PHP.  Según  Wikipedia  (8),  PHP  es  un  lenguaje  de  programación  interpretado,  diseñado   originalmente   para   la   creación   de   páginas  web   dinámicas.   Su   sitio  web   de  documentación  oficial  es  php.net  (9).  

• Lenguaje  HTML.  Según  Wikipedia  (10),  HTML  es  el  lenguaje  de  marcado  predominante  para   la   elaboración   de   páginas   web.   Es   usado   para   describir   la   estructura   y   el  contenido  en  forma  de  texto.  Su  sitio  web  de  documentación  oficial  es  w3schools.com  (11).  

• Lenguaje  JavaScript.  Según  Wikipedia  (12),  JavaScript  es  un  lenguaje  de  programación  orientado   a   objetos   y   dinámico,   utilizado   principalmente   en   su   forma   del   lado   del  cliente,   implementado   como  parte  de  un  navegador  web  permitiendo  mejoras   en   la  interfaz   de   usuario   y   páginas   web   dinámicas.   La   documentación   de   apoyo   se   ha  extraído  del  sitio  web  w3schools  (13).  

• Hojas  de  estilo  CSS.  Según  Wikipedia  (14),  CSS  es  un  lenguaje  de  usado  para  definir  la  presentación  de  un  documento  creado  en  HTML.  La  documentación  de  apoyo  ha  sido  extraída  del  sitio  web  csszengarden.com  (15).  

• Librerías   JQuery.   Según   Wikipedia   (16),   JQuery   es   una   librería   de   JavaScript,   que  permite   simplificar   la   manera   de   interactuar   con   los   documentos   HTML,   manejar  eventos,  desarrollar  animaciones  y  agregar   interacción  con   la   técnica  AJAX  a  páginas  web.  El  sitio  web  oficial  es  jquery.com  (17).  

• AJAX,  según  Wikipedia  (18),  es  una  técnica  de  desarrollo  web  para  crear  aplicaciones  interactivas.  Estas  aplicaciones  se  ejecutan  en  el  navegador  de  los  usuarios  mientras  se  mantiene  la  comunicación  asíncrona  con  el  servidor  en  segundo  plano.  De  esta  forma  es  posible  realizar  cambios  sobre  las  páginas  sin  necesidad  de  recargarlas.  

• Plantillas   TPL.   TPL  es  un   formato  de  archivo  en  el  que   se  define   la  estructura  de  un  sitio  web,  utilizando  el  lenguaje  HTML  y  a  su  vez  carga  contenido  dinámico  utilizando  instrucciones   definidas   por   un   motor   que   depende   de   la   librería   o   “framework”    utilizado.  

• Ficheros  XML.  Según  Wikipedia  (19),  XML  es  un  metalenguaje  extensible  de  etiquetas  que  permite  definir  la  gramática  de  lenguajes  específicos.  No  es  realmente  un  lenguaje  en  particular,  sino  una  manera  de  definir  lenguajes  para  diferentes  necesidades.  

2.3 Análisis  de  sistemas  de  gestión  de  contenido  

Uno  de  los  requisitos  de  este  proyecto  final  de  carrera  es  el  de  desarrollar  el  sistema  BCN  Look  &   Find   sobre   un   sistema   de   gestión   de   contenido,   para   ello   es   necesario   llevar   a   cabo   un  estudio   comparativo  de   los   sistema  de   libre  distribución  más  populares   y   seleccionar  el  más  apropiado  para  los  propósitos  del  proyecto.  

Según  Wikipedia   (20),   un   Sistema   de  Gestión   de   Contenido   (Content  Management   System,  CMS),   es   una   aplicación   que   permite   crear   una   estructura   de   soporte   para   la   creación   y  administración  de  contenido.  En  este  caso  el  documento  se  centra  en  sistemas  de  gestión  de  contenido  para  sitios  web.  

Consiste  en  una  interfaz  que  controla  una  base  de  datos  donde  se  aloja  el  contenido  del  sitio  web.  Esta  interfaz  permite  añadir  módulos,  editar  el  contenido  y  cambiar  el  diseño  entre  otras  

Page 10: Proyecto!Final!deCarrera BCNLook$&Find

   

9    

cosas,  utilizando  un  entorno  gráfico.   En   todo  momento  permite  acceder  al   código  y  editarlo  manualmente.  

Los   sistemas   de   gestión   de   contenido   de   que   se   han   escogido   para   llevar   a   cabo   el   análisis  están  desarrollados  bajo  licencia  GNU  GPL,  por  lo  tanto  son  de  libre  distribución.  

  Drupal   (21)  

  eZ  Publish   (22)  

  Joomla   (23)  

  WordPress   (24)  

Las   características,   ventajas   y   desventajas   de   cada   uno   de   los   CMS   que   se   exponen   a  continuación,  se  basan  en   información  obtenida  directamente  de  sus  correspondientes  sitios  web  oficiales  referenciados  anteriormente,  de  un  testeo  superficial  y  experiencias  de  terceros.  

La   tabla   que   se  muestra   a   continuación   contiene  una   lista   de   características   y   se   indica   qué  CMS  dispone  de  ella.  

Características        

 

Dispone  de  asistentes,  ayuda,  tutoriales,  etc.   ✔     ✔ ✔

Su  contenido  está  indexado  para  facilitar  su  búsqueda   ✔            

Dispone  de  módulos  oficiales  descargables  para  extender  el  sistema   ✔            

Dispone  de  módulos  no  oficiales  descargables  para  extender  el  sistema   ✔ ✔ ✔    

Utiliza  bases  de  datos  MySQL   ✔ ✔ ✔ ✔

Utiliza  bases  de  datos  PostgreSQL       ✔        

Utiliza  lenguaje  PHP   ✔ ✔ ✔ ✔

Utiliza  lenguaje  PHPTML   ✔     ✔ ✔

Utiliza  lenguaje  CSS   ✔ ✔ ✔ ✔

Utiliza  lenguaje  TPL       ✔        

Utiliza  URL  amigables   ✔ ✔ ✔ ✔

Dispone  de  roles  de  usuario  y  permisos   ✔ ✔        

Dispone  de  sistema  de  control  de  versiones   ✔            

Se  actualiza  automáticamente   ✔            

Es  multilenguaje   ✔ ✔        

Utiliza  sistemas  de  memoria  caché   ✔ ✔ ✔    

Dispone  de  comunidad  de  usuarios   ✔     ✔    

Permite  escoger  que  paquete  instalar       ✔        

Dispone  de  variedad  de  módulos  por  defecto       ✔        

Permite  crear  diferentes  tipos  de  contenido       ✔        

Estructura  el  contenido  basándose  en  directorios       ✔        

Permite  crear  borradores  con  publicación  automática       ✔        

Permite  crear  extensiones       ✔        

Page 11: Proyecto!Final!deCarrera BCNLook$&Find

   

10    

Su  página  pública  está  separada  de  la  de  administración       ✔ ✔    

Su  instalación  es  fácil           ✔ ✔

Dispone  de  diferentes  diseños  oficiales  descargables           ✔ ✔

Su  aprendizaje  es  corto  y  sencillo             ✔

Dispone  de  diferentes  diseños  por  defecto               ✔

Dispone  de  una  herramienta  de  edición  de  contenido  muy  completa               ✔

Tabla  1,  Análisis  de  CMS  

Finalmente  se  ha  optado  por  utilizar  eZ  Publish  para  el  desarrollo  del  sistema  BCN  Look  &  Find.  Las  razones  principales  por  las  que  se  ha  optado  por  este  sistema  son  las  siguientes.  

• Es  un  sistema  muy  amplio  y  completo  en  comparación  con  otros  CMS.  • Dispone  de  un  “framework”  muy  completo  para  desarrollos  propios.  • A  pesar  de  que  su  aprendizaje  es  largo  y  costoso,  parece  más  interesante,  sobre  todo  

teniendo  en  cuenta  que  esto  es  un  proyecto  de  ingeniería.  • Es  un   sistema  poco  conocido  y  utilizado   (al  menos  en  España),  pero  que  parece  que  

pueda   llegar   a   ser   uno   de   los   mejores.   Otras   aplicaciones   de   eZ   Systems   son   muy  conocidas  y  utilizadas  en  todo  el  mundo.  Muchas  empresas  buscan  desarrolladores  en  “framework”  eZ.  

Una  vez  escogido  el  sistema  de  gestión  de  contenido  sobre  el  que  se  va  a  desarrollar  el  sistema  BCN  Look  &  Find,  es  el  momento  de  adentrarse  en  su  funcionamiento.    

Page 12: Proyecto!Final!deCarrera BCNLook$&Find

   

11    

3 Especificación  del  sistema  

En  este  punto  se  especifica  cada  uno  de  los  elementos  que  forman  parte  del  sistema  BCN  Look  &   Find.   En   primer   lugar   es   conveniente   realizar   un   análisis   de   los   puntos   fuertes   y   de   los  problemas  que  puedan  tener  otros  sitios  web  con  el  mismo  objetivo.  

3.1 Análisis  de  otros  sitios  web  

Un  ejemplo  de  sitio  web  de  objetos  perdidos  que  está  bastante  bien  respecto  a  funcionalidad,  diseño   y   usabilidad   es  Finder   Base   (25).   De   aquí   han   surgido  muchas   ideas,   para   el   sistema  BCN  Look  &  Find.  

En  la  página  principal  aparece  un  mapa  centrado  en  la  ubicación  del  usuario  visitante,  donde  se  marcan  todos  los  objetos  registrados  en  el  sistema.  

 

Ilustración  1,  Finder  Base,  Página  principal  

Un  mapa  que   localice   los  objetos  no  es   totalmente   imprescindible,  pero  utilizado  de  manera  correcta  y  usable  es  una  funcionalidad  interesante  a  tener  en  cuenta.  

Page 13: Proyecto!Final!deCarrera BCNLook$&Find

   

12    

Otro   sitio   web   de   objetos   perdidos   que   hace   un   uso   diferente   de   un   mapa   genérico   en   la  página  principal  es  Megalost   (26).  

 

Ilustración  2,  Megalost,  Página  principal  

Megalost   (26)   igual  que  Finder   Base   (25)   es  un   sitio  web  de  objetos  perdidos  que  abarca  el  mundo  al  completo.  En  la  primera  fase  del  proyecto  BCN  Look  &  Find  solo  se  pretende  abarcar  la  zona  de  Barcelona  y  alrededores.  Esto  centra  y  facilita  la  búsqueda  de  objetos  perdidos.  

Megalost  (26)  dispone  de  un  mapa  mundial  en  su  página  principal  con  el  objetivo  de    ubicar  al  usuario   en   un   punto   concreto.   Antes   de   poder   ver   cualquier   objeto   registrado   se   debe  seleccionar  el  país  sobre  el  que  se  quiere  realizar  la  búsqueda.  Posteriormente  una  provincia  y  para   finalizar   una   ciudad.   Una   vez   llegados   a   este   punto   se  muestran   automáticamente   los  

Page 14: Proyecto!Final!deCarrera BCNLook$&Find

   

13    

objetos   registrados,   ubicados   en   la   ciudad   seleccionada,   además   de   la   posibilidad   de   añadir  nuevos.  

Quizás  para  un  sitio  web  que  abarque  todas  las  ciudades  del  mundo  es  una  manera  óptima  de  ubicar  al  usuario,  pero  para  un  sitio  web  centrado  en  un  área  concreta  es  mucho  más  usable  mostrar   datos   de   objetos   registrados   en   el   sistema,   sin   obligar   al   usuario   previamente   a  interactuar  con  el  sitio  web.  

Llegados   a   este   punto   es   el   momento   de   hablar   de   la  manera   de  mostrar   los   datos   de   los  objetos  registrados.  

Algo  curioso  es  que  en  ninguno  de  los  dos  sitios  web  mencionados  requiere  de  la  creación  de  una  cuenta  de  usuario  para  acceder  a   los  datos  completos  de   los  objetos  registrados,  pero  a  pesar  de  ello  no  se  muestran  públicamente  en  primera  instancia.  Por  ejemplo  en  Finder  Base  (25),   se  muestran   los   datos   del   objeto   de  manera  muy   bien   ordenada   en   una   ficha   en   una  sección  aparte.  Para  acceder  a  ella  hay  que  pulsar  sobre  alguno  de  los  marcadores  de  objetos  en  el  mapa.  

 

Ilustración  3,  Finder  Base,  Información  de  objeto  

Page 15: Proyecto!Final!deCarrera BCNLook$&Find

   

14    

Es  necesario  que  el  usuario  esté  casi  seguro  que  se  trata  del  objeto  que  está  buscando,  antes  de   pulsar   ningún   botón   y   por   supuesto   antes   de   hacerlo   cambiar   de   sección.   Para   ello   es  necesario  mostrar  parte  de  los  datos  del  objeto  en  la  página  principal.  

(26)  Megalost  por  el  contrario  muestra  un  resumen  de  los  datos  del  objeto,  antes  de  entrar  en  la  ficha  completa  de  éste.  

 

Ilustración  4,  Megalost,  Información  de  objeto  

A  pesar  de  ello,  como  se  ha  comentado  antes  es  necesario  escoger  diversas  opciones  antes  de  llegar  a  ver  información  como  ésta.  

Una  buena  práctica  para  mostrar  la  información  de  objetos  registrados  en  el  sistema  es  la  del  sitio  web  Wikifinding   (27).  En  este  ejemplo  muestra  al  usuario  los  datos  del  objeto  que  se  han  creído  oportunos  antes  de  acceder  a  su  información  completa.  

 

Ilustración  5,  Wikifinding,  Resumen  de  objeto  

En   la   página   principal   se   muestra   una   lista   de   bloques   como   este,   previamente   de   que   el  usuario  comience  a  interactuar  con  el  sitio  web.  

También   es   importante   qué   información   se   muestra   y   cómo   se   muestra.   Por   ejemplo   la  captura  anterior  es  un  buen  ejemplo  de  diseño  y  estructuración  de  la   información  a  mostrar.  No  se  puede  decir  lo  mismo  de  Objetos  Perdidos   (28).  

Page 16: Proyecto!Final!deCarrera BCNLook$&Find

   

15    

 

Ilustración  6,  Objetos  Perdidos,  Información  de  objeto  

Puede   que   la   información   que   muestra   sea   la   correcta,   incluso   en   el   caso   de   objetos   con  fotografía  se  mostraba,  pero  es  evidente  que  el  diseño  y  estructuración  de  la   información  no  es  la  correcta.  

Otro  ejemplo  de  mal  diseño  y  estructuración  de  la  información  de  los  objetos  registrados  es  la  de  Lost  Objects  Community   (29).  

 

Ilustración  7,  Lost  Objects  Community,  Resumen  de  objeto  

Como   además   se   puede   observar   en   el   ejemplo,   la   información   del   sitio  web   en   general   es  demasiado  extensa  horizontalmente,  de  ahí  a  que  la  imagen  tenga  que  ser  tan  pequeña  para  poderla   adjuntar   en   el   documento.   Esto   provoca   que   el   usuario   deba   desplazarse   no   solo  verticalmente  para  buscar  un  objeto  en   la   lista  de   la  página  principal,  sino  que  además  debe  hacerlo  horizontalmente  para  poder  leer  toda  la  información.  

En   el   caso   de  Oomia   (30)   el   diseño   es   simple,   pero   la   información   se   muestra   ordenada   y  estructurada.  

 

Ilustración  8,  Oomia,  Resumen  de  objeto  

Un  problema  es  que  la  simpleza  con  la  que  se  muestra  la  información  es  tal  que  es  necesario  aclarar  al  usuario  qué  tipo  de  datos  está  viendo,  este  problema  se  resuelve  mirando  el  nombre  de  las  columnas  en  el  inicio  de  la  tabla,  pero  ya  es  necesario  desplazarse.  

Se  debe  tener  en  cuenta  la  cantidad  de  objetos  que  se  pueden  llegar  a  registrar  en  un  sitio  web  de  estas  características.  A  pesar  de  necesitar  mostrar  objetos  al  usuario  en  la  página  principal,  hay  que  controlar  la  cantidad.  Para  ello  hay  varios  recursos.  El  más  simple  es  limitar  el  número  de  objetos  a  mostrar  y  dividirlos  en  páginas,  como  en  Wikifinding  (27).  

Page 17: Proyecto!Final!deCarrera BCNLook$&Find

   

16    

 

Ilustración  9,  Wikifinding,  Lista  de  objetos  

Otra  manera  de  reducir  la  cantidad  de  objetos  a  mostrar  es  estructurarlos  de  diversas  maneras  y   añadir   filtros   de   búsqueda.   Una   división   bastante   común   y   obvia   es   crear   dos   tipos   de  objetos,   objetos   que   los   usuarios   han   perdido   y   registrado   y   objetos   que   los   usuarios   han  encontrado   y   registrado   (perdidos   y   encontrados).   Dentro   de   estos   dos   tipos   de   objetos   se  suelen  dividir  en  categorías  de  objetos,  como  llaves,  carteras,  ropa,  etc.  

 

Ilustración  10,  Oomia,  Tipos  de  objeto  

Page 18: Proyecto!Final!deCarrera BCNLook$&Find

   

17    

Oomia  (30)  por  ejemplo,  divide  los  objetos  en  perdido  y  encontrado  y  en  categorías.  Pulsando  una  opción,  muestra   los  objetos  pertenecientes   al   tipo   y   categoría   seleccionado.  A  pesar  de  ello  no  muestra  ningún  objeto  por  defecto.  

Wikifinding   (27)   divide   los   objetos   por   categorías   y   sub-­‐categorías   de   manera   demasiado  concreta,  pero  no  posee  dos  tipos  de  objetos  diferenciados.  También  incluye  unos  filtros  que  muestran  objetos  recientes,  destacados,  los  más  vistos  y  aleatorios.  Quizás  estos  últimos  filtros  de  objetos  no  son  totalmente  necesarios.  

 

Ilustración  11,  Wikifinding,  Categorías  de  objeto  

Finder   Base   (25)   estructura   los   objetos   por   tipo   (encontrado   y   perdido)   y   por   categorías  generales.   Además   para   mayor   compresión   del   usuario   utiliza   iconos   para   diferenciar   las  categorías.  

Page 19: Proyecto!Final!deCarrera BCNLook$&Find

   

18    

 

Ilustración  12,  Finder  Base,  Categorías  de  objeto  

Incluso  Lost  Objects   Community   (29)  divide   los  objetos  en  perdidos  y  encontrados.  Pero   los  muestra  todos  al  mismo  tiempo.  Así  que,  aunque  se  limite  la  búsqueda  de  objetos  por  tipo,  no  se  gana  nada  en  cuanto  a  cantidad  de  objetos  a  mostrar.  

 

Ilustración  13,  Lost  Objects  Community,  Tipos  de  objeto  

Por   supuesto   cualquier   estructuración,   división   y   categorización   de   objetos   es  mucho  mejor  que  ninguna,  como  es  el  caso  de  Objetos  Perdidos   (28).  

Otra  funcionalidad  cuya  disponibilidad  debe  ser  inmediata  es  el  registro  de  nuevos  objetos  en  el  sistema.  Finder  Base  (25)  es  un  buen  ejemplo  ya  que  dispone  de  dos  opciones  en  el  menú  principal  con  las  que  se  accede  directamente  a  los  formularios  para  añadir  objetos  perdidos  o  encontrados.  

 

Ilustración  14,  Finder  Base,  Registrar  objeto  

Oomia  (30)  también  dispone  de  una  opción  en  el  menú  principal  para  registrar  objetos,  pero  su   nombre   “Añadir   anuncio”   puede   confundir   al   usuario.   El   mismo   caso   ocurre   con   Lost  Objects  Community (29).  Dispone  de  una  opción  en  el  menú  principal,  pero  el  nombre  no  es  

Page 20: Proyecto!Final!deCarrera BCNLook$&Find

   

19    

apropiado   “Publica   tu   anuncio   gratis”.   También   se   puede   mencionar   que   su   localización   y  diseño  hace  que  sea  poco  llamativo.  

Con   el   sitio  web  Megalost   (26)   ocurre   el   caso   contrario.   El   usuario   debe   escoger   diferentes  opciones  para  seleccionar  una  ubicación  antes  de  poder  registrar  un  objeto.  Una  vez  llegado  a  este  punto   se  muestra  un  botón   llamativo   y  bien  diseñado  para   acceder   al   formulario,   pero  éste   no   diferencia   entre   objetos   perdidos   y   encontrados,   hasta   que   no   se   rellena   el   campo  “estado”  del  formulario,  que  por  cierto  tampoco  queda  muy  claro  su  significado.  

Finder   Base   (25)   dispone   de   una   peculiaridad   respecto   al   resto   de   sitios   web.   En   el   menú  principal   puede   seleccionarse   la   opción   “Community”.   Al   entrar   en   esta   sección   se  muestra  una   lista  de   los  diez  usuarios  que  más  objetos  han  encontrado  y  devuelto  a  sus  propietarios.  Este  tipo  de  funcionalidades  ayudan  a  que  el  usuario  confíe  en  el  sitio  web  y  se  sienta  parte  de  él.  

 

Ilustración  15,  Finder  Base,  Top  10  

Page 21: Proyecto!Final!deCarrera BCNLook$&Find

   

20    

Que   el   usuario   reconozca   rápidamente   de   que   trata   el   sitio  web   que   está   visitando   es  muy  importante.   Y   por   supuesto   que   debe   hacer   en   cada   momento   y   que   pasos   seguir   para  conseguir  su  objetivo  es  algo  que  no  debe  pasarse  por  alto.  Por  ejemplo,  cuando  un  usuario  accede  a  Wikifinding  (27)   reconoce  que  está  visitando  un  sitio  web  de  objetos  perdidos  solo  viendo  la  cabecera.  

 

Ilustración  16,  Wikifinding,  Cabecera  

Oomia   (30)  dispone  de  un  mensaje  corto  y  conciso  en   la  cabecera  que   informa  al  usuario  el  objetivo  del  sitio  web.  

 

Ilustración  17,  Oomia,  Información  

Megalost  (26)  provee  al  usuario  de  un  vídeo  en  la  página  principal  donde  se  explica  cómo  debe  usarse  y  un  pequeño  texto  explicativo  que  además  mejora  el  aspecto  del  sitio  web.  

 

Ilustración  18,  Megalost,  Ayuda  

Por   el   contrario   en  Objetos   Perdidos   (28)   es   complicado   adivinar   de   qué   trata   la   página.   El  título  no  tiene  el  tamaño,  fuente  ni  color  adecuado  y  está  mal  ubicado.  Los  objetos  registrados  se  confunden  con  noticias  generales.  La  publicidad  llama  demasiado  la  atención  y  además  no  

Page 22: Proyecto!Final!deCarrera BCNLook$&Find

   

21    

hay  ningún  texto,  imagen  o  vídeo  que  informe  al  usuario  del  objetivo  del  sitio  web  y  mucho  de  menos  de  los  pasos  que  debe  seguir.  

Uno  de  los  objetivos  de  BCN  Look  &  Find  es  proveer  a  oficinas  de  objetos  perdidos,  empresas,  transportes   públicos,   comisarías   y   otros   centros   de   una   plataforma   donde   también   puedan  registrar   objetos   que   usuarios   han   perdido   en   su   área   o   han   depositado   en   ellos.   Algunas  empresas  públicas  ya  disponen  de  sitio  web  propio  para  este  cometido.  

Por  ejemplo,  dispone  de  un  apartado  para  objetos  perdidos  en  su  sitio  web  TMB   (31).  Como  es  obvio  TMB  no  se  dedica  exclusivamente  a  devolver  objetos  perdidos  a  sus  clientes,  por   lo  tanto   la   sección   de   objetos   perdidos   de   su   sitio   web   simplemente   está   compuesta   por   un  formulario   donde   el   usuario   puede   hacer   reclamaciones   y   donde   se   informa   del   proceso   a  seguir.  

Algo  similar,  pero  más  simple  todavía  se  encuentra  en  el  sitio  web  de  Institut  Metropolità  del  Taxi   (32).   Dispone   de   un   apartado   para   objetos   perdidos,   pero   simplemente   informa   del  proceso  que  debe  seguir  el  usuario  cuando  ha  dejada  olvidada  alguna  pertenencia  en  un  taxi  de  Barcelona.  

Lo   mismo   ocurre   con   el   sitio   web   del   AVE   (33).   Esta   sección   informa   al   usuario   del   plazo  máximo  que  disponen  los  clientes  que  han  perdido  pertenencias  en  cualquier  dependencia  de  Renfe,  para  poder  recuperarlas.  

Como  puede  notarse  es  evidente  que  TMB,  Taxis  de  Barcelona,  Renfe  y  otros  centros,  oficinas,  lugares  y  servicios  públicos  necesitan  de  un  sitio  web  donde  depositar  información  de  objetos  perdidos  en  sus  dependencias.  

El  sitio  web  Megalost  (26)  dispone  de  algo  que  parte  del  mismo  problema,  pero  en  bajo  nivel.  

 

Ilustración  19,  Megalost,  Transportes  

Estos   iconos   representan   transportes   públicos   dónde   clientes   suelen   olvidar   su   equipaje   y  otras   pertenencias.   Al   pulsar   cualquiera   de   estos   iconos   y   tras   seleccionar   la   ubicación,  Megalost   (26)   muestra   los   objetos   perdidos   y/o   encontrados   en   las   estaciones   del   tipo   de  transporte  seleccionado  y  en  la  ubicación  seleccionada.  

Una  vez  analizados  los  anteriores  sitios  web,  se  dispone  de  una  serie  de  elementos  funcionales  y  de  diseño,  que  añadir  en  el  sistema  BCN  Look  &  Find,  de  la  misma  manera  que  algunos  problemas  que  se  deben  solucionar  en  esta  nueva  plataforma.  

• El   sitio   web   dispondrá   en   su   página   principal   de   una   lista   con   el   resumen   de   la  información  de  los  objetos  registrados  por  los  usuarios.  Puesto  que  se  pretende  crear  

Page 23: Proyecto!Final!deCarrera BCNLook$&Find

   

22    

un   sitio  web  de  objetos  perdidos,   lo  primero  que  el  usuario  debe  ver  al  entrar  en  el  sitio  web  son  objetos.  

• Los   objetos   se   dividirán   en   dos   tipos   (perdidos   y   encontrados)   y   dispondrán   de   una  categoría   con   el   objetivo   de   mantener   un   orden   para   que   el   usuario   pueda   buscar  objetos  e  identificarlos  lo  más  fácilmente  posible.  

• Para  facilitar  la  búsqueda  de  objetos  y  controlar  la  cantidad  de  contenido  de  la  página  principal,   los  objetos  que   la   lista  mostrará  dependerán  de  unos  filtros  que  el  usuario  podrá  seleccionar.  El  usuario  podrá  seleccionar  el  tipo  de  objeto  que  desea  ver  y/o  la  categoría   a   la   que   pertenecen.   Para  mejorar   el   diseño   y   a   su   vez   la   experiencia   de  usuario   las   categorías   se   representarán   con   imágenes.   Además   por   las   mismas  razones,  la  lista  de  objetos  se  dividirá  en  páginas  de  cinco  objetos.  

• Uno  de  los  atributos  más  importantes  que  los  objetos  registrados  dispondrán  es  el   la  dirección   postal   aproximada   donde   se   ha   perdido   o   encontrado   el   objeto.   Es  más  fácil   para   el   usuario   identificar   un  objeto   si   se   conoce   la   zona   aproximada  donde   se  perdió  o  encontró.  Para  explotar  al  máximo  esta   información  se  añadirá  en  la  página  principal  un  mapa  donde  se  marcarán  los  objetos  que  el  usuario  está  visualizando  en  ese  momento,  teniendo  en  cuenta  los  filtros  seleccionados.  

• Una   de   las   funcionalidades   más   importantes   y   básicas   es   la   de   permitir   que   los  usuarios  registren  objetos  perdidos  y  encontrados  en  el  sistema.  Dada  su  importancia  el   acceso   a   los   respectivos   formularios   de   registro   tiene   que   ser   lo  más   inmediato  posible,  por  ello   se  añadirá  un  enlace  a  ellos  en  el  menú   principal,   accesibles  desde  todas  las  secciones.  

• Para  animar  a  los  usuarios  a  usar  el  sitio  web,  dar  confianza  y  promover  la  creación  de  una  comunidad,  el  sitio  web  dispondrá  de  una  sección  llamada  “Comunidad”.  Aquí  el  usuario   podrá   ver   sus   aportaciones,   las   aportaciones   de   otros   usuarios,   su   perfil   de  usuario  y  una  lista  con  los  diez  usuarios  que  más  objetos  han  encontrado  y  devuelto  a  sus  propietarios.  Esta  última  funcionalidad  también  fomentará  la  participación  de  los  usuarios  convirtiendo  la  búsqueda  de  objetos  perdidos  en  una  especie  de  competición.  

• Como  ya  se  ha  comentado  en  la  Sección  1,  se  va  a  desarrollar  un  sitio  web  2.0  donde  los   usuarios   interactuarán   entre   ellos   y   con   el   sitio   web,   registrando   objetos,  notificando   que   han   encontrado   un   objeto   perdido   registrado   o   que   son   los  propietarios  de  un  objeto  encontrado  registrado,  etc.  Por  ello  es  necesario  mantener  un   control   de   qué   usuarios   han   insertado   o   modificado   contenido   en   el   sistema,  además   de   la   necesidad   de   algunos   de   sus   datos   personales   como   su   dirección   de  correo   electrónico.   Para   ello   se   ha   decidido   que   los   usuarios   tengan   que   crear   una  cuenta  de  usuario  registrado,  para  poder  añadir  o  interactuar  con  objetos.  También  se  requerirá  de  una  cuenta  de  usuario  para  poder  acceder  a  la  sección  “Comunidad”,  reservada   para   miembros,   ver   información   personal   de   usuarios   y   otros   temas   que  requieren  control  por  seguridad  y  privacidad  de  datos.  

• Para   facilitar   el   registro   de   objetos   que   han   sido   depositados   en   alguna   oficina   de  objetos  perdidos,   lugar   o   transporte  público  o   cualquier   otro   tipo  de   centro,   se  ha  decidido  crear  un  tipo  de  cuenta  de  usuario  específica  para  este  tipo  de  centros.  Para  que  el   resto  de  usuarios  puedan  hacer  búsquedas  específicas   sobre  un   centro,   en   la  página  principal   se   incluirá  otro   filtro   en   forma  de   selector,  que  permitirá  al  usuario  

Page 24: Proyecto!Final!deCarrera BCNLook$&Find

   

23    

seleccionar  cualquier  centro  con  cuenta  de  usuario  y  así  poder  visualizar  únicamente  los  objetos  registrados  por  éste.  

• Por  supuesto  para  orientar  al  usuario  se  incluirá  la  sección  FAQ  con  ayuda  y  preguntas  más   frecuentes.   Además   de   un   formulario   para   enviar   cuestiones   concretas   al  administrador  del  sistema.  

Una   vez   analizados   otros   sitios   web   de   objetos   perdidos   y   obtenida   una   idea   de   las  funcionalidades   y   aspectos   de   diseño   y   usabilidad   que   se   pretenden   desarrollar,   es   el  momento  de  comenzar  con  la  especificación  más  concreta  del  sistema  BCN  Look  &  Find.  

3.2 Usuarios  A  continuación  se  definen  los  tipos  de  usuarios  que  van  a   interactuar  con  el  sistema  y  cuáles  serán  sus  posibles  roles.  

• Visitante.  Es  aquel  que  solo  puede  acceder  a  las  secciones  públicas  del  sitio  web.  • Registrado.   Usuario   con   una   cuenta   de   usuario   en   el   sistema   con   permisos   para  

acceder  a  parte  de  las  secciones  privadas  del  sitio  web  y  para  crear  contenido.  Dentro  de  este  tipo  de  usuario,  existe  un  subtipo  con  algunas  peculiaridades.  

• Centro.   Persona   jurídica   registrada   en   el   sistema   en   representación   de   una   unidad  organizacional  que  almacena  objetos  perdidos.  Como  por  ejemplo:  TMB,  aeropuertos,  centros  comerciales,  oficinas  de  objetos  perdidos  en  general,  etc.  

• Administrador.  Usuario  con  cuenta  de  usuario  en  el  sistema  con  todos  los  privilegios.  

Los   roles   que   puede   desempeñar   un   usuario   que   accede   al   sitio   web   se   exponen   a  continuación.  

• “Owner”.  Usuario  registrado  que  ha  perdido  un  objeto  de  su  propiedad.  • “Finder”.  Usuario  registrado  que  ha  encontrado  un  objeto  que  no  es  de  su  propiedad  o  

centro  en  el  que  se  ha  depositado  un  objeto  perdido.  

3.3 Objetos  

Como  antes  se  ha  comentado,  uno  de   los  objetivos  del   sitio  web  es  permitir  que  un  usuario  que   ha   perdido   o   se   ha   encontrado   un   objeto   perdido,   pueda   registrarlo   en   el   sistema   con  facilidad   y   rapidez.   Esto   implica   que   es   necesaria   la   definición   de   dos   tipos   de   objeto  diferentes.  

3.3.1 Tipos  de  objeto  

• Objeto  perdido  es  aquel  objeto  que  un  usuario  con  rol  “owner”    registra  en  el  sistema  cuando  ha  perdido  un  objeto  de  su  propiedad.  

• Objeto   encontrado   es   aquel   objeto   que   un   usuario   con   rol   “finder”   registra   en   el  sistema  cuando  se  ha  encontrado  un  objeto  que  no  es  de  su  propiedad  o  cuando  ha  sido  depositado  un  objeto  perdido  en  el  centro  al  que  representa.  

De  ahora  en  adelante  se  utilizará  estar  terminología  para  referirse  a  cada  uno  de  los  tipos  de  objeto.  

Page 25: Proyecto!Final!deCarrera BCNLook$&Find

   

24    

3.3.2 Estados  de  objeto  

Los  objetos  tienen  un  ciclo  de  vida  dentro  del  sistema  y  puede  encontrarse  en   los  siguientes  estados.  

En  paradero  desconocido.  El  usuario  con  rol  “owner”    ha  perdido  un  objeto  y  lo  registra  en  el  sistema.  El  objeto  está  en  paradero  desconocido.  

Posiblemente  encontrado.  Un  usuario  con  rol  “finder”  ha  encontrado  un  objeto  y  cree  que  se  corresponde  con  algún  objeto  en  paradero  desconocido  registrado  en  el  sistema.  

Tras   un   proceso   expuesto   en   la   siguiente   sección   el   objeto   pasa   a   estar   en   estado  posiblemente  encontrado  y  pendiente  de  devolución.  

Devuelto  a  su  propietario.  El  usuario    con  rol  “owner”  ,  siguiendo  un  proceso  expuesto  en  la  siguiente  sección,  ha  recuperado  el  objeto  perdido  que  ha  registrado  en  el  sistema.  

Se  busca  al  propietario.  El  usuario  con  rol  “finder”  se  ha  encontrado  un  objeto  perdido  y  lo  registra  en  el  sistema.  

Tiene  un  posible  propietario.  Un  usuario  registrado  con  rol  “owner”    cree  que  el  objeto  encontrado,   registrado   en   el   sistema,   del   cual   se   busca   al   propietario,   es   de   su  

propiedad.  Tras  un  proceso  expuesto  en  la  siguiente  sección  el  objeto  pasa  a  tener  un  posible  propietario  y  a  estar  pendiente  de  devolución.  

Devuelto  a  su  propietario.  El  usuario  con  rol  “finder”,  siguiendo  un  proceso  expuesto  en  la   siguiente   sección,   ha   devuelto   a   su   propietario   el   objeto   encontrado   que   había  

registrado  en  el  sistema.  

Una  vez  mencionados   los  estados  en   los  que  se  puede  encontrar  un  objeto  se  define  paso  a  paso  el  proceso  que  siguen  para  cambiar  de  un  estado  a  otro.  

 

Diagrama  1,  Ciclo  de  vida  de  objeto  

En  el  anterior  diagrama  se  muestra  el  ciclo  de  vida  de  los  objetos  pedidos  (izquierda)  y  el  ciclo  de  vida  de  los  objetos  encontrados  (derecha).  

Page 26: Proyecto!Final!deCarrera BCNLook$&Find

   

25    

3.3.3 Ciclo  de  vida  de  objeto  perdido  

Como  se  ha  comentado  anteriormente,  cuando  el  usuario  con  rol  “owner”    pierde  un  objeto  y  lo   registra   en   el   sistema,   el   objeto   se   crea   automáticamente   en   estado    En   paradero  desconocido,  tal  y  como  se  muestra  en  la  parte  izquierda  del  diagrama  1.  

El  usuario  con  rol  “owner”    que  ha  dado  de  alta  el  objeto  perdido  en  el  sistema,  puede  darlo  de  baja  en  cualquier  momento  y  el  objeto  es  eliminado  definitivamente  del  sistema.  

Si  el  usuario  recupera  el  objeto  por  sí  mismo  o  de  manera  externa  al  sitio  web,  puede  cancelar  su   búsqueda   en   vez   de   eliminarlo   del   sistema.   Cuando   el   usuario   pulse   el   botón   “Cancelar  búsqueda”  el  objeto  pasará  directamente  al  estado    Devuelto  a  su  propietario.  

Si  el  usuario  con  rol  “finder”  encuentra  un  objeto  y  cree  que  se  trata  del  objeto  perdido  que  el  usuario  con  rol  “owner”    ha  registrado,  pulsará  el  botón  “Lo  he  encontrado”.  De  esta  manera  el  objeto  pasará  automáticamente  al  siguiente  estado    Posiblemente  encontrado.  

En   este   momento   se   entra   en   el   proceso   de   comprobación   de   la   identidad   del   objeto.  Automáticamente  se  envía  un  mensaje  de  correo  electrónico  al  usuario  con  rol  “owner”    que  ha  registrado  el  objeto  en  el  sistema.  El  mensaje  de  correo  electrónico  incluirá  la  dirección  de  correo  electrónico  del  usuario   con   rol   “finder”,   (previamente   se  habrá  avisado  al   usuario  de  que  dichos  datos  serán  enviados).  De  esta  manera  los  usuarios  podrán  ponerse  en  contacto.  El  objeto  permanecerá  en  este  estado  hasta  que  el  usuario  con  rol  “owner”    que  ha  registrado  el  objeto  en  el  sistema  confirme  o  descarte  la  devolución  del  objeto.  

• El  usuario  con  rol  “owner”    se  ha  puesto  en  contacto  con  el  usuario  con  rol  “finder”  y  ha  llegado  a  la  conclusión  de  que  el  objeto  no  es  de  su  propiedad.  El  usuario  con  rol  “owner”     pulsa   el   botón   “Descartar”   y   el   objeto   vuelve     a   su   estado   inicial    En  paradero  desconocido.  

• El  usuario  con  rol  “owner”    se  ha  puesto  en  contacto  con  el  usuario  con  rol  “finder”  y  ha   llegado   a   la   conclusión   de   que   el   objeto   es   de   su   propiedad.   El   usuario   con   rol  “finder”   devuelve   el   objeto   al   usuario   con   rol   “owner”     y   éste   pulsa   el   botón  Confirmar.  El  objeto  pasa  al  estado  final    Devuelto  a  su  propietario.  

3.3.4 Ciclo  de  vida  de  un  objeto  encontrado  

Como   se   ha   comentado   anteriormente,   cuando   el   usuario   con   rol   “finder”   se   encuentra   un  objeto  o  es  depositado  un  objeto  perdido  en  el  centro  del  que  es  responsable  y  lo  registra  en  el   sistema,   el   objeto   se   crea   automáticamente   en   estado    Se   busca   al   propietario,   tal   y  como  se  muestra  en  la  parte  derecha  del  diagrama  1.  

Cuando  el  usuario  con  rol  “finder”  registra  un  objeto,  tiene  la  opción  de  añadir  una  pregunta  secreta  sobre  el  objeto  que  solo  el  verdadero  propietario  sabe  contestar  correctamente.  Esta  pregunta   secreta   se   muestra   a   todo   usuario   que   quiera   informar   que   es   el   propietario   del  objeto.  La  validación  de  la  respuesta  es  totalmente  manual.  Como  se  mencionará  en  breve,  el  usuario  recibirá  esa  respuesta  por  correo  electrónico  y  dependiendo  de  ésta,  podrá  descartar  al  usuario  que  reclama  el  objeto  sin  necesidad  de  ponerse  en  contacto  con  él.  

Page 27: Proyecto!Final!deCarrera BCNLook$&Find

   

26    

El   usuario   con   rol   “owner”     que  ha  dado  de   alta   el   objeto   encontrado  en   el   sistema,   puede  darlo  de  baja  en  cualquier  momento  y  el  objeto  es  eliminado  definitivamente  del  sistema.  

Si  el  usuario  devuelve  el  objeto  a  su  propietario  por  sí  mismo  o  de  manera  externa  al  sitio  web,  puede   cancelar   la   búsqueda   del   propietario   del   objeto   en   vez   de   eliminarlo   del   sistema.  Cuando   el   usuario   pulse   el   botón   “Cancelar   búsqueda”   el   objeto   pasará   directamente   al  estado      Devuelto  a  su  propietario.  

Si   el   usuario   con   rol   “owner”     reconoce   el   objeto   y   cree  que   es   de   su  propiedad,   pulsará   el  botón  “Es  mío”.    

• Si   el   usuario   con   rol   “finder”   ha   registrado   el   objeto   con   una   pregunta   secreta,   el  usuario   con   rol   “owner”     deberá   responder   a   dicha   pregunta,   (que   la   respuesta   sea  correcta  o  no,  dependerá  del  usuario  con  rol  “finder”  que  la  recibe).  De  lo  contrario  el  objeto  no  cambiará  de  estado.  

• Si  el  usuario  con  rol  encontrado  ha  registrado  el  objeto  sin  pregunta  secreta,  el  objeto  cambiará  automáticamente  de  estado,  ya  que  el  usuario  con  rol  “finder”  ha  decidido  no  añadir  ninguna  validación  previa.  

Si   se   cumple   uno   de   los   dos   casos   anteriormente   mencionados,   el   objeto   pasará  automáticamente  al  siguiente  estado    Tiene  un  posible  propietario.  

En   este  momento   se   entra   en   el   proceso   de   comprobación   de   la   identidad   del   propietario.  Automáticamente   se   envía   un  mensaje   de   correo   electrónico   al   usuario   con   rol   “finder”.   El  mensaje   incluye   la   dirección   de   correo   electrónico   del   usuario   con   rol   “owner”   ,   (previa  confirmación)   y   la   respuesta   a   la   pregunta   secreta   si   la   hay.   De   esta   manera   los   usuarios  pueden  ponerse  en  contacto.  El  objeto  permanece  en  este  estado  hasta  que  el  usuario  con  rol  “finder”  que  ha  registrado  el  objeto  en  el  sistema  confirma  o  descarta  la  devolución  del  objeto.  

• El   usuario   con   rol   “finder”   considera   que   la   respuesta   a   la   pregunta   secreta   no   es  correcta,   (si   la  hay)  o  se  ha  puesto  en  contacto  con  el  usuario   con  rol  “owner”    y  ha  llegado   a   la   conclusión   de   que   el   objeto   no   es   de   su   propiedad.   El   usuario   con   rol  “finder”  pulsa  el  botón  “Descartar”  y  el  objeto  vuelve  a  su  estado  inicial    Se  busca  al  propietario.  

• El  usuario  con  rol  “finder”  considera  que  la  respuesta  a  la  pregunta  secreta  es  correcta,  (si  la  hay)  y  se  ha  puesto  en  contacto  con  el  usuario  con  rol  “owner”    y  ha  llegado  a  la  conclusión  de  que  el  objeto  es  de  su  propiedad.  El  usuario  con  rol  “finder”  devuelve  el  objeto  a  su  propietario  y  pulsa  el  botón  “Confirmar”.  El  objeto    pasa  al  estado  final    Devuelto  a  su  propietario.  

A  continuación  se  exponen  los  casos  de  uso.  

3.4 Casos  de  uso  

Los  siguientes  diagramas  representan  cada  uno  de   los  casos  de  uso  que   los  usuarios  pueden  efectuar  en  el  sistema.  En  primer  lugar  se  muestra  la  jerarquía  de  los  tipos  de  usuario  definidos  

Page 28: Proyecto!Final!deCarrera BCNLook$&Find

   

27    

en   la   Sección   3.2,   utilizando   un   diagrama   de   jerarquía   de   actores   y   utilizando   como  documentación  de  apoyo  el  libro  Enginyeria  del  Software  Especificació  (6).  

• Todos  los  tipos  de  usuario  pueden  acceder  a  los  casos  de  uso  de  un  usuario  visitante,  por  lo  tanto  el  resto  de  usuarios  se  sitúan  por  debajo  jerarquicamente.  

• Los  usuarios  de  tipo  centro  disponen  de  unos  casos  de  uso  específicos,  pero  a  su  vez  son  también  accesibles  por  los  usuarios  de  tipo  registrado.  Es  por  ello  que  éste  últimos  se  sitúa  por  debajo  jerarquicamente.  

• Los  usuarios  de   tipo   registrado  pueden  acceder  a   los   casos  de  uso  de  un  usuario  de  tipo  centro  y  a  su  vez  disponen  de  casos  de  uso  específicos.  

• Por   último   el   usuario   de   tipo   administrador   dispone   de   casos   de   uso   específicos,  accesibles  desde  la  página  de  administración  o  desde  el  propio  sitio  web.  Por  supuesto  también   tiene  acceso  a   los  casos  de  uso  del   resto  de   tipos  de  usuario,  pero  no  se   le  puede  considerar  una  extensión  de  estos,  ya  que   la  utilización  de  estos  casos  de  uso  sería  con  el  fin  de  administración  y  no  con  el  mismo  objetivo  que  el  resto  de  usuarios.  

A  continuación  se  muestra  el  diagrama  teniendo  en  cuenta  estas  características.  

 

Diagrama  2,  Jerarquía  de  usuarios  

   

Page 29: Proyecto!Final!deCarrera BCNLook$&Find

   

28    

3.4.1 Casos  de  uso  de  usuario  visitante  

Los  casos  de  uso  expuestos  a  continuación  pretenden  reflejar  el  uso  que  los  usuarios  de  tipo  visitante    pueden  darle  al  sitio  web.    

 

Diagrama  3,  Casos  de  uso  usuario  visitante  

Buscar  objetos  por  buscador  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  quiere  buscar  un  objeto  utilizando  el  buscador.  • Escenario  principal  de  éxito.  

o El  usuario  escribe  una  palabra  o  palabras  que  pueden  estar  contenidas  en  el  objeto  que  está  buscando  y  pulsa  el  botón  Buscar.  

o El  sistema  muestra  una   lista  con  el  nombre  de   los  objetos  que  contienen  esa  palabra  o  palabras  en  su  nombre  o  el  resto  de  su  información.  

• Extensión  1.    o El  usuario  pulsa  sobre  el  enlace  del  nombre  de  uno  de  los  objetos  de  la  lista.  o Se  accede  al  caso  de  uso  Intentar  ver  información  de  objetos.  

Buscar  objetos  por  etiquetas  

• Actores.  Usuario  visitante.  

Page 30: Proyecto!Final!deCarrera BCNLook$&Find

   

29    

• Descripción.  El  usuario  quiere  buscar  un  objeto  utilizando  la  nube  de  etiquetas.  • Escenario  principal  de  éxito.  

o El   usuario  pulsa   sobre   alguna  de   las   etiquetas   contenidas   en  el   bloque  de   la  nube  de  etiquetas.  

o El  sistema  muestra  una   lista  con  el  nombre  de   los  objetos  que  contienen  esa  etiqueta.  

• Extensión  1.    o El  usuario  pulsa  sobre  el  enlace  del  nombre  de  uno  de  los  objetos  de  la  lista.  o Se  accede  al  caso  de  uso  Intentar  ver  información  de  objetos.  

Ver  información  del  sitio  web  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  quiere  ver  la  información  del  sitio  web.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  enlace  Sobre  nosotros  del  pie  de  página.  o El  sistema  muestra  esta  sección  con  la  información  del  sitio  web.  

Ver  F.A.Q  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  necesita  ayuda  y  quiere  ver  las  preguntas  más  frecuentes.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  enlace  Preguntas  más  frecuentes  del  pie  de  página.  o El  sistema  muestra  esta  sección  con  las  preguntas  más  frecuentes.  

Enviar  consultas  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  tiene  preguntas  y  quiere  transmitirlas  al  administrador  del  sitio  

web.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  enlace  Formulario  de  consulta  del  pie  de  página.  o El  sistema  muestra  el  formulario  de  consulta.  o El  usuario  rellena  el  formulario  de  consulta.  o El  sistema  envía  la  consulta  al  administrador  del  sitio  web.  

Ver  condiciones  de  uso  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  quiere  leer  las  condiciones  de  uso.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  enlace  Condiciones  de  uso  del  pie  de  página.  o El  sistema  muestra  la  sección  con  las  condiciones  de  uso.  

Ver  política  de  privacidad  

• Actores.  Usuario  visitante.  

Page 31: Proyecto!Final!deCarrera BCNLook$&Find

   

30    

• Descripción.  El  usuario  quiere  leer  la  política  de  privacidad.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  enlace  Política  de  privacidad  del  pie  de  página.  o El  sistema  muestra  la  sección  con  la  política  de  privacidad.  

Ver  resumen  de  objetos  

• Actores.  Usuario  visitante.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal.  • Descripción.   El   usuario   quiere   ver   el   resumen   de   la   información   de   los   objetos  

registrados  en  el  sistema.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  una  lista  con  el  resumen  de  la  información  de  los  objetos.  • Extensión  1.  

o El  usuario  pulsa  sobre  el  botón  Objetos  para  localizar.  o El  sistema  muestra  una   lista  con  el  resumen  de   la   información  de   los  objetos  

perdidos.  • Extensión  2.  

o El  usuario  pulsa  sobre  el  botón  Objetos  para  devolver.  o El  sistema  muestra  una   lista  con  el  resumen  de   la   información  de   los  objetos  

encontrados.  • Extensión  3.  

o El  usuario  pulsa  sobre  una  categoría.  o El  sistema  muestra  una   lista  con  el  resumen  de   la   información  de   los  objetos  

de  esa  categoría  y  del  tipo  perdido  o  encontrado,  seleccionado.  • Extensión  4.  

o El  usuario  selecciona  un  centro  de  la  lista  de  selección  Objetos  bajo  custodia.  o El   sistema  muestra   los   objetos   registrados   por   el   centro,   del   tipo   perdido   o  

encontrado  y  categoría,  seleccionada.  • Extensión  5.  

o El   usuario   pulsa   sobre   el   botón  Entrar,   para   ver   la   información   completa   de  algún  objeto  de  la  lista.  

o Se  accede  al  caso  de  uso  Intentar  ver  información  de  objetos.  • Extensión  6.  

o El   usuario   con   rol   “finder”   pulsa   sobre   el   botón   Lo   he   encontrado   de   algún  objeto  de  la  lista,  para  notificar  que  ha  encontrado  el  objeto.  

o Se  accede  al  caso  de  uso  Intentar  marcar  objetos.  • Extensión  7.  

o El  usuario  con  rol  “owner”  pulsa  sobre  el  botón  Es  mio  de  algún  objeto  de  la  lista,  para  notificar  que  es  de  su  propiedad.  

o Se  accede  al  caso  de  uso  Intentar  marcar  objetos.  

Intentar  añadir  objetos  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  quiere  añadir  un  nuevo  objeto  de  tipo  perdido  o  encontrado.  

Page 32: Proyecto!Final!deCarrera BCNLook$&Find

   

31    

• Escenario  principal  de  éxito.  o El  usuario  pulsa  el  botón  Añadir  objeto  y  sobre  una  de  las  dos  opciones  Objeto  

perdido  o  Objeto  encontrado.  o Se  accede  al  caso  de  uso  Registrarse.  

Intentar  ver  la  sección  comunidad  

• Actores.  Usuario  visitante.  • Descripción.  El  usuario  quiere  ver  la  sección  “Comunidad”.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción  del  menú  principal  Comunidad.  o Se  accede  al  caso  de  uso  Registrarse.  

Ver  último  objeto  devuelto  

• Actores.  Usuario  visitante.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal.  • Descripción.  El  usuario  quiere  ver  el  resumen  de  la  información  del  último  objeto  

devuelto  a  su  propietario.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  un  anuncio  con  el  resumen  de  la  información  del  último  objeto  devuelto  a  su  propietario.  

• Extensión  1.  o El  usuario  pulsa  sobre  el  enlace  Ver  más  historias  como  ésta.  o Se  accede  al  caso  de  uso  Intentar  ver  aportaciones  de  la  comunidad.  

Intentar  ver  información  de  objetos  

• Actores.  Usuario  visitante.  • Antecedentes.  El  usuario  está  visualizando  el  resumen  de  la  información  de  un  objeto  

en  la  página  principal,  ha  pulsado  sobre  una  etiqueta  de  la  nube  de  etiquetas  o  ha  efectuado  una  búsqueda  con  el  buscador.  

• Descripción.  El  usuario  quiere  ver  la  información  completa  de  alguno  de  los  objetos  que  está  visualizando.  

• Escenario  principal  de  éxito.  o El  usuario  pulsa  sobre  el  botón  Entrar  o  sobre  el  enlace  del  nombre  del  objeto,  

dependiendo  de  su  ubicación.  o Se  accede  al  caso  de  uso  Registrarse.  

Intentar  marcar  objetos  

Pueden  darse  dos  casos  dependiendo  del  rol  del  usuario.  

• Actores.  Usuario  visitante  con  rol  “owner”.  • Antecedentes.  Puede  darse  una  de  las  siguientes  situaciones.  

o El  usuario  con  rol  “owner”  está  viendo  la  lista  de  objetos  de  la  página  principal.  

Page 33: Proyecto!Final!deCarrera BCNLook$&Find

   

32    

o El   usuario   con   rol   “owner”   está   viendo   la   información   completa   de   algún  objeto.  

• Descripción.   El   usuario   con   rol   “owner”   cree   que   un   objeto   del   sistema   es   de   su  propiedad  y  quiere  recuperarlo.  

• Escenario  principal  de  éxito.  o El  usuario  con  rol  “owner”  pulsa  el  botón  Es  mio.  o Se  accede  al  caso  de  uso  Registrarse.  

Segundo  caso.  

• Actores.  Usuario  visitante  con  rol  “finder”.  • Antecedentes.  Puede  darse  una  de  las  siguientes  situaciones.  

o El  usuario  con  rol  “finder”  está  viendo  la  lista  de  objetos  de  la  página  principal.  o El   usuario   con   rol   “finder”   está   viendo   la   información   completa   de   algún  

objeto.  • Descripción.  El  usuario  con  rol  “finder”  ha  encontrado  un  objeto  del  sistema  y  quiere  

devolverlo  a  su  propietario.  • Escenario  principal  de  éxito.  

o El  usuario  con  rol  “finder”  pulsa  sobre  el  botón  Lo  he  encontrado.  o Se  accede  al  caso  de  uso  Registrarse.  

Intentar  ver  aportaciones  de  la  comunidad  

• Actores.  Usuario  visitante.  • Antecedentes.  El  usuario  está  visualizando  el  anuncio  en  el  que  se  muestra  el  resumen  

de  la  información  del  último  objeto  devuelto  a  su  propietario,  ubicado  en  la  página  principal.  

• Descripción.  El  usuario  quiere  ver  otras  historias  similares.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  el  enlace  Ver  más  historias  como  ésta.  o Se  accede  al  caso  de  uso  Registrarse.  

Registrarse  

• Actores.  Usuario  visitante.  • Antecedentes.  El  usuario  ha  pulsado  sobre  algún  botón,  enlace  o  sección  sobre  la  que  

no  dispone  privilegios.  • Descripción.  El  usuario  quiere  registrarse  en  el  sistema.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  el  enlace  Crear  una  cuenta  de  la  ventana  que  aparece  o  de  la  cabecera  del  sitio  web.  

o El  sistema  muestra  el  formulario  de  registro.  o El  usuario  rellena  el  formulario  y  pulsa  sobre  botón  registrar.  o El  sistema  crea  la  cuenta  y  convierte  al  usuario  en  usuario  de  tipo  registrado.  

Page 34: Proyecto!Final!deCarrera BCNLook$&Find

   

33    

3.4.2 Casos  de  uso  de  usuario  centro  

Los  usuarios  que  disponen  de  cuenta  de  usuario  de  tipo  centro  disponen  de  los  casos  de  uso  de   un   usuario   de   tipo   visitante   hasta   que   se   identifican   con   los   datos   de   su   cuenta.   A  continuación  se  muestran  los  casos  de  uso  de  un  usuario  de  tipo  centro.  

 

Diagrama  4,  Casos  de  uso  usuario  centro  

Identificarse  

• Actores.  Usuario  centro.  • Antecedentes.   El   usuario   (todavía   sin   identificarse),   ha   pulsado   sobre   algún   botón,  

enlace  o  sección  sobre  la  que  no  dispone  privilegios.  • Descripción.   El   usuario   quiere   identificarse   como   usuario   registrado   en   el   sistema,  

para  disponer  de  las  funcionalidades  de  este  tipo  de  usuario.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  el  enlace  Identifícate  de  la  ventana  que  aparece  o  de  la  cabecera  del  sitio  web.  

o El  sistema  muestra  el  formulario  de  identificación.  o El  usuario  rellena  el  formulario  y  pulsa  sobre  botón  entrar.  o El   sistema,   tras   validar   los   datos   del   formulario   dota   al   usuario   de   los  

privilegios   de   un   usuario   de   tipo   centro,   que   le   permite   acceder   a   los  siguientes  casos  de  uso.  

Page 35: Proyecto!Final!deCarrera BCNLook$&Find

   

34    

Recuperar  contraseña  

• Actores.  Usuario  centro.  • Antecedentes.   El   usuario   (todavía   sin   identificarse),   ha   pulsado   sobre   algún   botón,  

enlace  o  sección  sobre  la  que  no  dispone  privilegios.  • Descripción.  El  usuario  ha  olvidado  los  datos  de  su  cuenta.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  el  enlace  ¿Has  olvidado  la  contraseña?.  o El  sistema  muestra  el  formulario  de  recuperación  de  la  contraseña.  o El  usuario  rellena  el  formulario  y  pulsa  sobre  botón  recuperar.  o El   sistema,   tras   validar   los   datos   del   formulario   envía   por   correo   electrónico  

una  nueva  contraseña  para  que  el  usuario  acceda  a  su  cuenta.  

Ver  información  de  objetos  

• Actores.  Usuario  centro.  • Antecedentes.  El  usuario  está  visualizando  el  resumen  de  la  información  de  un  objeto  

en  la  página  principal,  ha  pulsado  sobre  una  etiqueta  de  la  nube  de  etiquetas  o  ha  efectuado  una  búsqueda  con  el  buscador.  

• Descripción.  El  usuario  quiere  ver  la  información  completa  de  alguno  de  los  objetos  que  está  visualizando.  

• Escenario  principal  de  éxito.  o El  usuario  pulsa  sobre  el  botón  Entrar  o  sobre  el  enlace  del  nombre  del  objeto,  

dependiendo  de  su  ubicación.  o El  sistema  muestra  la  información  completa  del  objeto.  

• Extensión   1.   El   objeto   que   se   está   mostrando   es   de   tipo   perdido   y   su   estado   es  perdido.  

o El  sistema  muestra  el  botón  Lo  he  encontrado.  o El  usuario  con  rol  “finder”  pulsa  sobre  el  botón  Lo  he  encontrado.  o Se  accede  al  caso  de  uso  Marcar  objetos.  

• Extensión   2.   El   objeto   que   se   está   mostrando   es   de   tipo   encontrado,   su   estado   es  perdido  y  el  usuario  que  lo  está  visualizando  es  quién  lo  ha  registrado.  

o El  sistema  muestra  el  botón  Cancelar  búsqueda.  o El  usuario  con  rol  “finder”  pulsa  sobre  el  botón  Cancelar  búsqueda.  o Se  accede  al  caso  de  uso  Marcar  objetos.  

• Extensión   3.   El   objeto   que   se   está   mostrando   es   de   tipo   encontrado,   su   estado   es  pendiente  y  el  usuario  que  lo  está  visualizando  es  quién  lo  ha  registrado.  

o El  sistema  muestra  el  botón  Confirmar  devolución  y  Descartar  devolución.  o El  usuario  con  rol  “finder”  pulsa  sobre  alguno  de  dichos  botones.  o Se  accede  al  caso  de  uso  Confirmar  o  descartar  devoluciones.  

• Extensión  4.  o El  usuario  pulsa  sobre  el  botón  Añadir  comentario.  o Se  accede  al  caso  de  uso  Ver  y  añadir  comentarios.  

• Extensión  5.  El  usuario  que  está  visualizando  la  información  del  objeto  es  quién  lo  ha  registrado.  

Page 36: Proyecto!Final!deCarrera BCNLook$&Find

   

35    

o El  sistema  muestra  el  botón  Borrar.  o El  usuario  pulsa  sobre  el  botón  Borrar.  o Se  accede  al  caso  de  uso  Borrar  objetos.  

• Extensión  6.  El  usuario  que  está  visualizando  la  información  del  objeto  es  quién  lo  ha  registrado.  

o El  sistema  muestra  el  botón  Editar.  o El  usuario  pulsa  sobre  el  botón  Editar.  o Se  accede  al  caso  de  uso  Ver  y  editar  objetos  personales.  

• Extensión  7.  o El   usuario   pulsa   sobre   el   enlace   del   nombre   del   usuario   que   ha   añadido   el  

objeto  o  sobre  la  fotografía  o  el  enlace  del  nombre  del  usuario  que  ha  añadido  algún  comentario.  

o Se  accede  al  caso  de  uso  Ver  información  y  estadísticas  de  usuarios.  • Extensión  8.  El  usuario  que  está  visualizando  la  información  del  objeto  es  quién  lo  ha  

registrado.  o El  usuario  pulsa  sobre  el  enlace  de  su  nombre  o  sobre  la  fotografía  o  el  enlace  

de  su  nombre  de  algún  comentario  añadido  por  él.  o Se  accede  al  caso  de  uso  Ver  y  editar  perfil  personal.  

Añadir  objetos  

• Actores.  Usuario  centro.  • Descripción.  El  usuario  quiere  añadir  un  nuevo  objeto  de  tipo  encontrado.  • Escenario  principal  de  éxito.  

o El   usuario   pulsa   el   botón   Añadir   objeto   y   sobre   una   de   la   opción   Objeto  encontrado.  

o El  sistema  muestra  el  formulario  correspondiente.  o El  usuario  añade  los  datos  necesarios.  o El  sistema  valida  que  los  datos  sean  correctos  y  registra  el  objeto.  

Ver  sección  Comunidad  

• Actores.  Usuario  centro.  • Descripción.  El  usuario  quiere  ver  la  sección  “Comunidad”.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción  del  menú  principal  Comunidad.  o El  sistema  muestra  el  contenido  de  la  sección  “Comunidad”.  

Ver  último  objeto  devuelto  

• Actores.  Usuario  centro.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal.  • Descripción.  El  usuario  quiere  ver  el  resumen  de  la  información  del  último  objeto  

devuelto  a  su  propietario.  • Escenario  principal  de  éxito.  

Page 37: Proyecto!Final!deCarrera BCNLook$&Find

   

36    

o El  sistema  muestra  un  anuncio  con  el  resumen  de  la  información  del  último  objeto  devuelto  a  su  propietario.  

• Extensión  1.  o El  usuario  pulsa  sobre  el  enlace  Ver  más  historias  como  ésta.  o Se  accede  al  caso  de  uso  Ver  aportaciones  de  la  comunidad.  

Marcar  objetos  

• Actores.  Usuario  centro  con  rol  “finder”.  • Antecedentes.  Puede  darse  una  de  las  siguientes  situaciones.  

o El  usuario  con  rol  “finder”  está  viendo  la  lista  de  objetos  de  la  página  principal.  o El   usuario   con   rol   “finder”   está   viendo   la   información   completa   de   algún  

objeto.  • Descripción.  El  usuario  con  rol  “finder”  dispone  de  un  objeto  del  sistema  en  el  centro  

del  que  es  responsable  y  quiere  devolverlo  a  su  propietario.  • Escenario  principal  de  éxito.  

o El  usuario  con  rol  “finder”  pulsa  sobre  el  botón  Lo  he  encontrado.  o El   sistema  notifica   al   usuario  que  ha   registrado  el   objeto   con   la  dirección  de  

correo  electrónico  del  usuario  con  rol  “finder”  y  actualiza  el  estado  del  objeto  a  pendiente.  

• Extensión   2.   El   usuario   con   rol   “finder”   a   su   vez   es   el   usuario   que   ha   registrado   el  objeto  (encontrado)  y  ha  pulsado  el  botón  Cancelar  búsqueda.  

o El  sistema  cancela  la  búsqueda  del  objeto  y  éste  pasa  a  estado  devuelto.  

Ver  y  añadir  comentarios  

• Actores.  Usuario  centro.  • Antecedentes.   El   usuario   está   visualizando   la   información   completa   de   cualquier  

objeto.  • Descripción.  El  usuario  quiere  ver  o  añadir  comentarios.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  los  comentarios.  o El  usuario  pulsa  el  botón  Nuevo  comentario.  o El  sistema  muestra  el  formulario  correspondiente.  o El  usuario  rellena  los  datos  requeridos  y  pulsa  sobre  el  botón  Publicar.  o El  sistema  registra  y  muestra  el  comentario.  

Borrar  objetos  

• Actores.  Usuario  centro.  • Antecedentes.   El   usuario   está   visualizando   la   información   completa   de   algún   objeto  

que  él  ha  registrado.  • Descripción.  El  usuario  quiere  borrar  un  objeto  anteriormente  registrado  por  él.  • Escenario  principal  de  éxito.  

o El  usuario  identificado  pulsa  el  botón  Borrar.  o El  sistema  borra  definitivamente  el  objeto.  

Page 38: Proyecto!Final!deCarrera BCNLook$&Find

   

37    

Ver  y  editar  objetos  personales  

• Actores.  Usuario  centro.  • Antecedentes.   El   usuario   está   visualizando   la   información   completa   de   algún   objeto  

anteriormente  registrado  por  él.  • Descripción.   El   usuario   quiere   cambiar   alguno   de   los   datos   del   objeto   que   ha  

registrado  anteriormente.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  botón  Editar.  o El   sistema  vuelve   a  mostrar   el   formulario  que   se   rellenó  anteriormente  para  

registrar  el  objeto  con  los  valores  actuales  por  defecto.  o El  usuario  modifica  los  datos  del  objeto  y  pulsa  el  botón  Publicar.  o El  sistema  guarda  la  información  del  objeto  actualizada.  

Ver  información  y  estadísticas  de  usuarios  

• Actores.  Usuario  centro.  • Antecedentes.  Puede  darse  una  de  las  siguientes  situaciones.  

o El  usuario  está  viendo  la  lista  de  objetos  de  la  página  principal.  o El  usuario  está  viendo  la  información  completa  de  algún  objeto.  o El  usuario  está  viendo  las  aportaciones  de  la  comunidad.  o El  usuario  está  viendo  sus  aportaciones  personales.  o El  usuario  está  viendo  el  top  10.  o El   usuario   ha   recibido   un   correo   electrónico   que   incluye   un   enlace   a   la  

información  de  un  usuario.  • Descripción.  El  usuario  quiere  ver  la  información  y  estadísticas  de  algún  usuario.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  fotografía  o  el  enlace  del  nombre  de  algún  usuario.  o El  sistema  muestra  la  información  pública  y  las  estadísticas  del  usuario.  

Ver  y  editar  perfil  personal  

• Actores.  Usuario  centro.  • Antecedentes.  Puede  darse  una  de  las  siguientes  situaciones.  

o El  usuario  ha  accedido  a  la  sección  Comunidad.  o El  usuario  está  viendo  la  lista  de  objetos  de  la  página  principal  y  entre  ellos  hay  

objetos  añadidos  por  él.  o El  usuario  está  viendo  la  información  completa  de  un  objeto  registrado  por  él  

o  que  ha  comentado  o  marcado.  o El  usuario  está  viendo  las  aportaciones  de  la  comunidad.  o El  usuario  está  viendo  sus  aportaciones  personales.  

• Descripción.  El  usuario  quiere  ver  o  editar  los  datos  de  su  cuenta.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción  de  menú  Mi  cuenta  o  pulsa  sobre  su  nombre  de  usuario  o  foto  en  cualquiera  de  las  ubicaciones  antes  mencionadas.  

o El  sistema  muestra  todos  los  datos  de  su  cuenta  y  estadísticas.  

Page 39: Proyecto!Final!deCarrera BCNLook$&Find

   

38    

• Extensión  1.  El  usuario  está  viendo  los  datos  de  su  cuenta  y  estadísticas.  o El  usuario  pulsa  sobre  el  botón  Editar.  o El   sistema   muestra   un   formulario   para   editar,   añadir   o   borrar   datos   de   su  

cuenta.  Además  de  poder  escoger  la  privacidad  de  alguno  de  los  datos.  o El  sistema  guarda  los  datos  y  preferencias  del  usuario.  

Confirmar  o  descartar  devoluciones  

• Actores.  Usuario  centro  con  rol  “finder”.  • Antecedentes.  El  usuario  con  rol  “finder”  está  viendo   la   información  completa  de  un  

objeto   que   ha   sido   depositado   en   el   centro   del   que   es   responsable   y   ha   registrado.  Algún   usuario   con   rol   “owner”   ha   notificado   (marcado)   que   el   objeto   es   de   su  propiedad.  

• Descripción.  El  usuario  con  rol  “finder”  se  ha  puesto  en  contacto  con  el  usuario  con  rol  “owner”  y  le  ha  devuelto  el  objeto.  

• Escenario  principal  de  éxito.  o El   usuario   con   rol   “finder”   ha   devuelto   el   objeto,   así   que   pulsa   el   botón  

Confirmar.  o El  sistema  cambia  el  estado  del  objeto  a  devuelto.  

• Extensión  1.  o El  usuario  con  rol  “finder”  no  ha  devuelto  el  objeto,  no  ha  conseguido  ponerse  

en   contacto   con   el   usuario   con   rol   “owner”   o   simplemente   no   se   trata  realmente  de  su  objeto,  así  que  pulsa  el  botón  Descartar.  

o El  sistema  cambia  el  estado  del  objeto  a  perdido.  

Ver  aportaciones  personales  

• Actores.  Usuario  centro.  • Antecedentes.  El  usuario  ha  accedido  a  la  sección  Comunidad.  • Descripción.  El  usuario  quiere  ver  sus  aportaciones  personales  a  la  comunidad.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  la  opción  de  menú  Aportaciones  personales.  o El  sistema  muestra  la  interacción  del  usuario  con  el  sistema  u  otros  usuarios.  

• Extensión  1.  o El  usuario  pulsa  sobre  su  foto  o  enlace  de  su  nombre.  o Se  accede  al  caso  de  uso  Ver  y  editar  perfil  personal.  

• Extensión  2.  o El  usuario  pulsa  sobre  la  foto  o  enlace  del  nombre  de  algún  otro  usuario  con  el  

que  ha  interactuado.  o Se  accede  al  caso  de  uso  Ver  información  y  estadísticas  de  usuarios.  

• Extensión  3.  o El  usuario  pulsa  sobre  el  enlace  del  nombre  de  algún  objeto  registrado  por  él.  o Se  accede  al  caso  de  uso  Ver  y  editar  objetos  personales.  

• Extensión  4.  o El   usuario   pulsa   sobre   el   enlace   del   nombre   de   algún   objeto   con   el   que   ha  

interactuado,  pero  no  ha  sido  registrado  por  él.  

Page 40: Proyecto!Final!deCarrera BCNLook$&Find

   

39    

o Se  accede  al  caso  de  uso  Ver  información  de  objetos.  

Ver  top  10  

• Actores.  Usuario  centro.  • Antecedentes.  El  usuario  ha  accedido  a  la  sección  Comunidad.  • Descripción.   El   usuario   quiere   ver   la   lista   de   los   diez   usuarios   que  más   objetos   han  

encontrado  y  devuelto  a  sus  propietarios.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  la  opción  de  menú  Top  10.  o El  sistema  muestra  un  resumen  de  la  información  de  los  diez  usuarios  que  más  

objetos  han  encontrado  y  devuelto  a  sus  propietarios.  • Extensión  1.  

o El  usuario  pulsa  sobre  la  fotografía  o  el  enlace  del  nombre  de  algún  usuario  de  la  lista.  

o Se  accede  al  caso  de  uso  Ver  información  y  estadísticas  de  usuarios.  

Ver  aportaciones  de  la  comunidad  

• Actores.  Usuario  centro.  • Antecedentes.  El  usuario  ha  accedido  a  la  sección  Comunidad.  • Descripción.  El  usuario  quiere  ver  las  aportaciones  de  la  comunidad.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  la  opción  de  menú  Aportaciones  de  la  comunidad.  o El   sistema   muestra   la   interacción   de   todos   los   usuarios   del   sistema   con   el  

sistema  u  otros  usuarios.  • Extensión  1.  

o El  usuario  pulsa  sobre  su  foto  o  enlace  de  su  nombre  de  algún  elemento  de  la  lista  en  la  que  aparece.  

o Se  accede  al  caso  de  uso  Ver  y  editar  perfil  personal.  • Extensión  2.  

o El  usuario  pulsa  sobre   la   foto  o  enlace  del  nombre  de  algún  otro  usuario    de  algún  elemento  de  la  lista.  

o Se  accede  al  caso  de  uso  Ver  información  y  estadísticas  de  usuarios.  • Extensión  3.  

o El  usuario  pulsa  sobre  el  enlace  del  nombre  de  algún  objeto  registrado  por  él,  de  algún  elemento  de  la  lista.  

o Se  accede  al  caso  de  uso  Ver  y  editar  objetos  personales.  • Extensión  4.  

o El   usuario   pulsa   sobre   el   enlace   del   nombre   de   algún   objeto   registrado   por  otros  usuarios,  de  algún  elemento  que  aparece  en  la  lista.  

o Se  accede  al  caso  de  uso  Ver  información  de  objetos.  

Page 41: Proyecto!Final!deCarrera BCNLook$&Find

   

40    

3.4.3 Casos  de  uso  de  usuario  registrado  

Los  usuarios  de  tipo  registrado  de  la  misma  manera  que  un  usuario  de  tipo  centro,  dispone  de  los   casos   de   uso   de   un   usuario   de   tipo   visitante   hasta   que   se   identifica   con   los   datos   de   su  cuenta  de  usuario  registrado.  Los  casos  de  uso  de  un  usuario  de  tipo  registrado  son  los  mismos  que   los  de  un  usuario  de  tipo  centro,  a  excepción  de  dos  casos  de  uso  que  disponen  de  más  funcionalidades  para  los  usuarios  de  tipo  registrado.  

 

Diagrama  5,  Casos  de  uso  usuario  registrado  

Marcar  objetos  

Además  de  los  escenarios  y  extensiones  expuestas  anteriormente  en  este  caso  de  uso  para  los  usuarios  de  tipo  centro,  para  los  usuarios  de  tipo  registrado  se  incluyen  estas.  

• Actores.  Usuario  registrado  con  rol  “owner”.  • Antecedentes.  Puede  darse  una  de  las  siguientes  situaciones.  

o El  usuario  con  rol  “owner”  está  viendo  la  lista  de  objetos  de  la  página  principal.  o El   usuario   con   rol   “owner”   está   viendo   la   información   completa   de   algún  

objeto.  • Descripción.   El   usuario   con   rol   “owner”   cree   que   un   objeto   del   sistema   es   de   su  

propiedad  y  quiere  recuperarlo.  • Escenario  principal  de  éxito.  

o El  usuario  con  rol  “owner”  pulsa  el  botón  Es  mio.  o Si  el  objeto  dispone  de  pregunta  secreta,  el  sistema  la  muestra.  o Si  el  objeto  dispone  de  pregunta  secreta,  el  usuario  la  responde.  o El   sistema  notifica   al   usuario  que  ha   registrado  el   objeto   con   la  dirección  de  

correo  electrónico  del  usuario  con  rol  “owner”  y  actualiza  el  estado  del  objeto  a  pendiente.  

• Extensión   1.   El   usuario   con   rol   “owner”   a   su   vez   es   el   usuario   que   ha   registrado   el  objeto  (perdido)  y  ha  pulsado  el  botón  Cancelar  búsqueda.  

o El  sistema  cancela  la  búsqueda  del  objeto  y  éste  pasa  a  estado  devuelto.  

Añadir  objetos  

La  única  diferencia  entre  el  caso  de  uso  para  un  centro  y  para  un  usuario  registrado  es  que  el  usuario  registrado  puede  seleccionar  el  tipo  de  objeto  a  registrar  (perdido  o  encontrado).  

Page 42: Proyecto!Final!deCarrera BCNLook$&Find

   

41    

Ver  top  10  

La  única  diferencia  que  el  caso  de  uso  para  un  centro  y  para  un  usuario  registrado  es  que  el  usuario  registrado  puede  acceder  a  la  extensión  2.  

• El  usuario  pulsa  sobre  su  fotografía  o  el  enlace  a  su  nombre,  si  es  que  éste  aparece.  • Se  accede  al  caso  de  uso  Ver  y  editar  perfil  personal.  

Confirmar  o  descartar  devoluciones  

Además  de  los  escenarios  y  extensiones  expuestas  anteriormente  en  este  caso  de  uso  para  los  usuarios  de  tipo  centro,  para  los  usuarios  de  tipo  registrado  se  incluyen  estas.  

• Actores.  Usuario  registrado  con  rol  “owner”.  • Antecedentes.   El   usuario   con   rol   “owner”   está   viendo   la   información   completa   de  

algún  objeto  que  ha  perdido  y  registrado.  Algún  usuario  con  rol  “finder”  ha  notificado  (marcado)  que  lo  ha  encontrado.  

• Descripción.  El  usuario  con  rol  “owner”  se  ha  puesto  en  contacto  con  el  usuario  con  rol  “finder”  y  se  le  ha  devuelto  el  objeto  de  su  propiedad.  

• Escenario  principal  de  éxito.  o El   usuario   con   rol   “owner”   ha   recuperado   el   objeto,   así   que   pulsa   el   botón  

Confirmar.  o El  sistema  cambia  el  estado  del  objeto  a  devuelto.  

• Extensión  1.  o El   usuario   con   rol   “owner”   no   ha   recuperado   el   objeto,   no   ha   conseguido  

ponerse  en  contacto  con  el  usuario  con  rol  “finder”  o  simplemente  no  se  trata  realmente  de  su  objeto,  así  que  pulsa  el  botón  Descartar.  

o El  sistema  cambia  el  estado  el  objeto  a  perdido.  

   

Page 43: Proyecto!Final!deCarrera BCNLook$&Find

   

42    

3.4.4 Casos  de  uso  de  usuario  administrador  

Teniendo  en  cuenta  que  el  sistema  se  ha  desarrollado  sobre  un  CMS,  la  mayoría  de  los  casos  de  uso  de  un  usuario  administrador  dependen  de  dicho  CMS,  por   lo   tanto  a  continuación  se  exponen  solo  algunos  de   los  más   imprescindibles.  Estos  casos  de  uso  son  accesibles  desde   la  página  de  administración  (“back-­‐end”).  

 

Diagrama  6,  Casos  de  uso  usuario  administrador  

Ver  sección  Contenido  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal  de  la  plataforma  de  

administración  (“back-­‐end”).  • Descripción.  El  usuario  quiere  acceder  a  la  sección  Contenido.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción  del  menú  principal,  Contenido.  o El  sistema  muestra  una  lista  con  sub-­‐secciones  que  agrupan  contenidos.  

Ver  sección  Usuarios  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal  de  la  plataforma  de  

administración  (“back-­‐end”).  • Descripción.  El  usuario  quiere  acceder  a  la  sección  Usuarios.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción  del  menú  principal,  Usuarios.  o El  sistema  muestra  una  lista  con  sub-­‐secciones  que  agrupan  usuarios.  

Page 44: Proyecto!Final!deCarrera BCNLook$&Find

   

43    

Limpiar  cachés  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal  de  la  plataforma  de  

administración  (“back-­‐end”).  • Descripción.  El  usuario  quiere  borrar  algún  tipo  de  contenido  guardado  en  las  

memorias  caché.  • Escenario  principal  de  éxito.  

o El  usuario  selecciona  el  tipo  de  contenido  que  desea  eliminar  y  pulsa  sobre  el  botón  Borrar  caché.  

o El  sistema  elimina  el  tipo  de  contenido  seleccionado  de  las  memorias  caché.  

Actualizar  sistema  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  página  principal  de  la  plataforma  de  

administración  (“back-­‐end”).  • Descripción.  Puesto  que  el  sistema  se  va  a  desarrollar  sobre  un  CMS,  es  posible  que  

con  el  tiempo  sea  necesario  actualizarlo.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  el  botón  Actualizar  sistema.  o El  sistema  actualiza  el  sistema.  

Ver  resumen  de  objetos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  de  sub-­‐secciones  de  la  sección  

Contenido.  • Descripción.  El  usuario  quiere  ver  la  lista  con  el  resumen  de  los  objetos  añadidos  en  el  

sistema.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción,  Objetos.  o El  sistema  muestra  una  lista  con  el  resumen  de  los  objetos  añadidos  en  el  

sistema.  • Extensión  1.  

o El  usuario  pulsa  sobre  el  enlace  del  nombre  del  objeto.  o Se  accede  al  caso  de  uso  Ver  y  editar  objetos.  

• Extensión  2.  o El  usuario  pulsa  sobre  el  botón  de  borrar.  o Se  accede  al  caso  de  uso  Borrar  objetos.  

Ver  resumen  de  otros  contenidos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  de  sub-­‐secciones  de  la  sección  

Contenido.  

Page 45: Proyecto!Final!deCarrera BCNLook$&Find

   

44    

• Descripción.  El  usuario  quiere  ver  la  lista  con  el  resumen  de  algún  otro  tipo  de  contenido.  

• Escenario  principal  de  éxito.  o El  usuario  pulsa  sobre  la  opción  correspondiente  al  tipo  de  contenido  que  

quiere  visualizar.  o El  sistema  muestra  una  lista  con  el  resumen  de  los  contenidos    

correspondientes  a  esa  opción  • Extensión  1.  

o El  usuario  pulsa  sobre  el  enlace  del  nombre  del  contenido.  o Se  accede  al  caso  de  uso  Ver  y  editar  otros  contenidos.  

• Extensión  2.  o El  usuario  pulsa  sobre  el  botón  de  borrar.  o Se  accede  al  caso  de  uso  Borrar  otros  contenidos.  

Ver  resumen  de  personas  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  de  sub-­‐secciones  de  la  sección  

Personas.  • Descripción.  El  usuario  quiere  ver  la  lista  con  el  resumen  de  los  usuarios  de  tipo  

persona,  registrados  en  el  sistema.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción,  Miembros.  o El  sistema  muestra  una  lista  con  el  resumen  de  los  usuarios  de  tipo  persona,  

registrados  en  el  sistema.  • Extensión  1.  

o El  usuario  pulsa  sobre  el  enlace  del  nombre  del  usuario  de  tipo  persona.  o Se  accede  al  caso  de  uso  Ver  y  editar  cuentas  de  personas.  

• Extensión  2.  o El  usuario  pulsa  sobre  el  botón  de  borrar.  o Se  accede  al  caso  de  uso  Borrar  cuentas  de  personas.  

Ver  resumen  de  centros  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  de  sub-­‐secciones  de  la  sección  

Usuarios.  • Descripción.  El  usuario  quiere  ver  la  lista  con  el  resumen  de  los  centros  registrados  en  

el  sistema.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción,  Centros.  o El  sistema  muestra  una  lista  con  el  resumen  de  los  centros  registrados  en  el  

sistema.  • Extensión  1.  

o El  usuario  pulsa  sobre  el  enlace  del  nombre  del  centro.  o Se  accede  al  caso  de  uso  Ver  y  editar  centros.  

Page 46: Proyecto!Final!deCarrera BCNLook$&Find

   

45    

• Extensión  2.  o El  usuario  pulsa  sobre  el  botón  de  borrar.  o Se  accede  al  caso  de  uso  Borrar  centros.  

Administrar  roles  y  permisos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  de  sub-­‐secciones  de  la  sección  

Usuarios.  • Descripción.  El  usuario  quiere  administrar  roles  y  permisos  de  usuario.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  la  opción,  Administrar  roles  y  permisos.  o El  sistema  muestra  una  lista  con  el  resumen  de  los  roles  y  sus  respectivos  

permisos.  

Ver  y  editar  objetos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  ha  pulsado  sobre  el  enlace  del  nombre  de  un  objeto  o  sobre  

el  botón  de  editar.  • Descripción.  El  usuario  quiere  ver  la  información  de  un  objeto  y/o  editarla.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  la  información  del  objeto  con  campos  editables.  o El  usuario  visualiza  la  información  del  objeto  y  la  modifica  si  lo  desea.  o El  usuario  pulsa  sobre  el  botón  de  guardar.  o El  sistema  almacena  los  cambios  efectuados  en  el  objeto.  

• Extensión  1.  o El  usuario  pulsa  sobre  el  botón  de  cancelar.  o El  sistema  cancela  los  cambios  efectuados  por  el  usuario  en  el  objeto.  

Ver  y  editar  otros  contenidos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  ha  pulsado  sobre  el  enlace  del  nombre  de  algún  otro  tipo  de  

contenido    o  sobre  el  botón  de  editar.  • Descripción.  El  usuario  quiere  ver  la  información  de  algún  otro  tipo  de  contenido  y/o  

editarla.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  la  información  del  contenido  con  campos  editables.  o El  usuario  visualiza  la  información  del  contenido  y  la  modifica  si  lo  desea.  o El  usuario  pulsa  sobre  el  botón  de  guardar.  o El  sistema  almacena  los  cambios  efectuados  en  el  contenido.  

• Extensión  1.  o El  usuario  pulsa  sobre  el  botón  de  cancelar.  o El  sistema  cancela  los  cambios  efectuados  por  el  usuario  en  el  contenido.  

Page 47: Proyecto!Final!deCarrera BCNLook$&Find

   

46    

Añadir  otros  contenidos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  otros  contenidos.  • Descripción.  El  usuario  quiere  añadir  algún  otro  tipo  de  contenido.  • Escenario  principal  de  éxito.  

o El  usuario  escoge  el  tipo  de  contenido  que  desea  crear  y  pulsa  el  botón  de  añadir.  

o El  sistema  muestra  un  formulario  con  los  campos  a  rellenar  para  crear  el  contenido.  

o El  usuario  rellena  el  formulario  y  pulsa  el  botón  de  publicar.  o El  sistema  crea  el  contenido  y  lo  muestra  el  sitio  web  público  (front-­‐end).  

• Extensión  1.  o El  usuario  pulsa  el  botón  de  cancelar.  o Se  cancela  la  creación  del  nuevo  contenido.  

Añadir  otros  contenidos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  los  roles  y  

permisos.  • Descripción.  El  usuario  quiere  añadir  un  nuevo  rol  o  permiso.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  sobre  el  botón  Añadir  rol  o  Añadir  permiso.  o El  sistema  muestra  un  formulario  con  los  campos  a  rellenar  para  crear  el  

nuevo  rol  o  el  nuevo  permiso.  o El  usuario  rellena  el  formulario  y  pulsa  el  botón  de  publicar.  o El  sistema  crea  el  nuevo  rol  o  permiso.  

• Extensión  1.  o El  usuario  pulsa  el  botón  de  cancelar.  o Se  cancela  la  creación  del  nuevo  rol  o  permiso.  

Ver  y  editar  cuentas  de  personas  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  ha  pulsado  sobre  el  enlace  del  nombre  de  un  usuario  de  tipo  

persona  o  sobre  el  botón  de  editar.  • Descripción.  El  usuario  quiere  ver  la  información  de  un  usuario  de  tipo  persona  y/o  

editarla.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  la  información  del  usuario  de  tipo  persona  con  campos  editables.  

o El  usuario  visualiza  la  información  del  usuario  de  tipo  persona  y  la  modifica  si  lo  desea.  

o El  usuario  pulsa  sobre  el  botón  de  guardar.  o El  sistema  almacena  los  cambios  efectuados  en  el  usuario  de  tipo  persona.  

Page 48: Proyecto!Final!deCarrera BCNLook$&Find

   

47    

• Extensión  1.  o El  usuario  pulsa  sobre  el  botón  de  cancelar.  o El  sistema  cancela  los  cambios  efectuados  por  el  usuario  en  el  usuario  de  tipo  

persona.  

Ver  y  editar  cuentas  centros  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  ha  pulsado  sobre  el  enlace  del  nombre  de  un  centro  o  sobre  

el  botón  de  editar.  • Descripción.  El  usuario  quiere  ver  la  información  de  un  usuario  de  tipo  centro  y/o  

editarla.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  la  información  del  centro  con  campos  editables.  o El  usuario  visualiza  la  información  del  centro  y  la  modifica  si  lo  desea.  o El  usuario  pulsa  sobre  el  botón  de  guardar.  o El  sistema  almacena  los  cambios  efectuados  en  el  centro.  

• Extensión  1.  o El  usuario  pulsa  sobre  el  botón  de  cancelar.  o El  sistema  cancela  los  cambios  efectuados  por  el  usuario  en  el  centro.  

Ver  y  editar  roles  y  permisos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  ha  pulsado  sobre  el  enlace  del  nombre  de  un  rol  o  permiso  

de  tipo  o  sobre  el  botón  de  editar.  • Descripción.  El  usuario  quiere  ver  la  información  de  un  rol  o  permiso  y/o  editarla.  • Escenario  principal  de  éxito.  

o El  sistema  muestra  la  información  del  rol  o  permiso  con  campos  editables.  o El  usuario  visualiza  la  información  del  rol  o  permiso  y  lo  edita.  o El  usuario  pulsa  sobre  el  botón  de  guardar.  o El  sistema  almacena  los  cambios  efectuados  en  el  rol  o  permiso.  

• Extensión  1.  o El  usuario  pulsa  sobre  el  botón  de  cancelar.  o El  sistema  cancela  los  cambios  efectuados  en  el  rol  o  permiso.  

Borrar  objetos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  los  objetos  

añadidos  en  el  sistema.  • Descripción.  El  usuario  quiere  borrar  un  objeto.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  botón  de  borrar  de  alguno  de  los  objetos.  o El  sistema  elimina  el  objeto.  

Page 49: Proyecto!Final!deCarrera BCNLook$&Find

   

48    

Borrar  otros  contenidos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  algún  otro  tipo  

de  contenido.  • Descripción.  El  usuario  quiere  borrar  algún  otro  tipo  de  contenido.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  botón  de  borrar  de  alguno  de  los  contenidos.  o El  sistema  elimina  el  contenido.  

Borrar  cuentas  de  personas  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  los  usuarios  de  

tipo  persona,  registrados  en  el  sistema.  • Descripción.  El  usuario  quiere  borrar  la  cuenta  de  un  usuario  de  tipo  persona.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  botón  de  borrar  de  alguno  de  los  usuarios  de  tipo  persona.  o El  sistema  elimina  el  usuario  de  tipo  persona.  

Borrar  cuentas  de  centros  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  las  cuentas  de  los  

usuarios  de  tipo  centro,  registrados  en  el  sistema.  • Descripción.  El  usuario  quiere  borrar  la  cuenta  de  un  centro.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  botón  de  borrar  de  la  cuenta  de  alguno  de  los  centros.  o El  sistema  elimina  la  cuenta  del  centro.  

Borrar  roles  o  permisos  

• Actores.  Usuario  administrador.  • Antecedentes.  El  usuario  está  visualizando  la  lista  con  el  resumen  de  los  roles  y  

permisos.  • Descripción.  El  usuario  quiere  borrar  un  rol  o  un  permiso.  • Escenario  principal  de  éxito.  

o El  usuario  pulsa  el  botón  de  borrar  de  alguno  de  los  roles  o  permisos.  o El  sistema  elimina  el  rol  o  el  permiso.  

Para   poder   entender   de  manera  más   clara   los   procesos   que   provocan   algunos   casos   de  uso,  se  han  utilizado  diagramas  de  secuencia.  

Page 50: Proyecto!Final!deCarrera BCNLook$&Find

   

49    

3.5 Diagramas  de  secuencia  

En   esta   sección   se   muestran   diagramas   de   secuencia   de   los   diferentes   procesos   que   se  desarrollan   en   los   casos   de   uso   genéricos   “Marcar   objetos”   y   “Confirmar   o   descartar  devoluciones”.  

3.5.1 Secuencia  marcar  objeto  “lo  he  encontrado”  

La  situación  que  se  muestra  en  el  siguiente  diagrama  de  secuencia  describe  como  un  usuario  con  rol  “finder”  encuentra  algún  objeto  registrado  en  el  sistema  como  perdido,  por  un  usuario  con  rol  “owner”.  El  usuario  con  rol  “finder”  quiere  devolver  el  objeto  a  su  propietario  y  pulsa  el  botón  “Lo  he  encontrado”.  

 

Diagrama  7,  Secuencia  marcar  objeto  “lo  he  encontrado”  

3.5.2 Secuencia  confirmar  devolución  de  objeto  perdido  

El  siguiente  diagrama  de  secuencia  muestra  el  proceso  que  se  desarrolla  una  vez  el  usuario  con  rol   “owner”   recibe   un  mensaje   de   correo   electrónico,   informándole   que   un   usuario   con   rol  “finder”   ha   encontrado   su   objeto   perdido   registrado.   En   este   momento   se   supone   que   el  usuario  con  rol  “owner”,  que  ha  recibido  el  correo  electrónico,  se  ha  puesto  en  contacto  con  el  usuario  con  rol  “finder”  y  éste  le  ha  devuelto  el  objeto,  por  lo  tanto,  el  usuario  con  rol  “finder”  quiere  confirmar  la  devolución.  

 

Diagrama  8,  Secuencia  confirmar  devolución  de  objeto  perdido  

Page 51: Proyecto!Final!deCarrera BCNLook$&Find

   

50    

3.5.3 Secuencia  descartar  devolución  de  objeto  perdido  

El  diagrama  que  se  muestra  a  continuación   representa   la  alternativa  a   la   secuencia  anterior.  Por  alguna  razón,  el  usuario  con  rol  “owner”  que  ha  recibido  el  mensaje  de  correo  electrónico,  ha  decidido  descartar  la  devolución  del  objeto.  

 

Diagrama  9,  Secuencia  descartar  devolución  de  objeto  perdido  

3.5.4 Secuencia  marcar  objeto  “Es  mio”  

A  continuación  se  muestra  el  diagrama  de  secuencia  que  representa  el  proceso  que  se  lleva  a  cabo   cuando   un   usuario   con   rol   “owner”,   que   ha   perdido   un   objeto,   cree   que   algún   objeto  encontrado   registrado   en   el   sistema,   es   de   su   propiedad.   El   usuario   con   rol   “owner”   quiere  recuperar  su  objeto  y  pulsa  el  botón  “Es  mio”.  

 

Diagrama  10,  Secuencia  marcar  objeto  "Es  mio"  

   

Page 52: Proyecto!Final!deCarrera BCNLook$&Find

   

51    

3.5.5 Secuencia  confirmar  devolución  de  objeto  encontrado  

El   siguiente   diagrama   representa   el   proceso   que   se   lleva   a   cabo   cuando   un   usuario   con   rol  “finder”,   que   ha   registrado   un   objeto   encontrado,   recibe   un  mensaje   de   correo   electrónico,  informándole   que   hay   un   posible   propietario   para   uno   de   los   objetos   que   ha   registrado.   Se  supone  que  el  usuario  con  rol  “finder”,  que  ha  recibido  el  correo  electrónico,  se  ha  puesto  en  contacto  con  el  usuario  con  rol  “owner”  y  le  ha  devuelto  el  objeto  de  su  propiedad.  

 

Diagrama  11,  Secuencia  confirmar  devolución  objeto  encontrado  

3.5.6 Secuencia  descartar  devolución  de  objeto  perdido  

Por  último,  el  diagrama  que  se  muestra  a  continuación  representa  la  alternativa  a  la  secuencia  expuesta   anteriormente.   Por   alguna   razón,   el   usuario   con   rol   “finder”,   que   ha   recibido   el  correo  electrónico,  ha  decidido  descartar  la  devolución  del  objeto  al  usuario  con  rol  “owner”.  

 

Diagrama  12,  Secuencia  descartar  devolución  de  objeto  perdido  

Ahora  que  ya  se  han  expuesto   los  diferentes  casos  de  uso,   los   tipos  de  objetos,   los  ciclos  de  vida  de  los  objetos,  secuencias,  etc.,  se  exponen,  utilizando  diagramas  de  flujo,  cómo  los  tres  roles  de  usuario  interactúan  con  el  sistema.    

Page 53: Proyecto!Final!deCarrera BCNLook$&Find

   

52    

3.6 Flujo  de  objeto  perdido  

El  diagrama  de   flujo  que   se  muestra  a   continuación  pretende  mostrar  el   ciclo  de  vida  de  un  objeto  perdido.  Desde  que  un  usuario  con  rol  “owner”  lo  pierde  y  registra  en  el  sistema,  hasta  que  un  usuario  con  rol  “finder”  lo  encuentra  y  se  lo  devuelve.  

 

Diagrama  13,  Flujo  de  objeto  perdido  

Page 54: Proyecto!Final!deCarrera BCNLook$&Find

   

53    

3.7 Flujo  de  objeto  encontrado  

El  diagrama  de  flujo  que  se  muestra  a  continuación  pretende  mostrar  el  ciclo  de  vida  de  un  objeto  encontrado.  Desde  que  un  usuario  con  rol  “finder”  lo  encuentra  y  lo  registra  o  desde  que  es  depositado  en  un  centro  cuyo  representante  con  rol  “finder”  lo  registra,  hasta  que  un  usuario  con  rol  “owner”  lo  reconoce  se  le  devuelve.  

 

Diagrama  14,  Flujo  de  objeto  encontrado  

Page 55: Proyecto!Final!deCarrera BCNLook$&Find

   

54    

Una   vez   definidos   los   elementos   que   forman   el   sistema   del   sitio   web,   objetos   perdidos,  usuarios,  etc.,  es  el  momento  de  exponer  de  manera  más  concreta  la  forma  de  estos  objetos  y  cómo  interactúan  entre  sí.  

3.8 Clases  

El  siguiente  diagrama  de  clases  muestra  la  estructura  de  cada  uno  de  los  objetos  que  forman  el  sistema.  

 

3.8.1 Category  

• Descripción.  Representa  cada  una  de  las  categorías  en  las  que  se  agrupan  los  objetos.  • Atributos.  

o id.  Valor  entero  que  identifica  la  categoría  en  el  sistema.  o name.  Nombre  de  la  categoría.  Identifica  la  categoría  en  el  sitio  web.  o description.  Descripción  de  la  categoría  o  ejemplos  de  tipos  de  objeto  que  

puede  agrupar.  o image.  Imagen  que  representa  la  categoría.  Identifica  la  categoría  en  el  sitio  

web  de  manera  visual.  • Asociaciones.  

o Grouped  –  Object.  Una  categoría  puede  agrupar  diversos  objetos.  

3.8.2 LostStatus  

• Descripción.  Representa  cada  uno  de  los  estados  que  puede  poseer  un  objeto  perdido.  • Atributos.  

o id.  Valor  entero  que  identifica  el  estado  en  el  sistema.  o name.  Nombre  del  estado.  Identifica  el  estado  en  el  sistema.  o message.  Mensaje  que  se  muestra  en  el  sitio  web  para  representar  el  estado.  

Identifica  el  estado  en  el  sitio  web.  o image.  Imagen  que  representa  el  estado.  Identifica  el  estado  en  el  sitio  web  de  

manera  visual.  • Asociaciones.  

Page 56: Proyecto!Final!deCarrera BCNLook$&Find

   

55    

o Has  –  Lost.  En  un  estado  de  objeto  extraviado  pueden  encontrarse  diversos  objetos  extraviados.  

3.8.3 FoundStatus  

Esta  clase,  de  la  misma  manera  que  la  “LostStatus”,  representa  cada  uno  de  los  estados  que  puede  poseer  un  objeto  encontrado.  

3.8.4 User  

• Descripción.  Representa  cada  uno  de  los  usuarios  que  interactúan  en  el  sistema.  • Asociaciones.  

o View  -­‐  Object.  Un  usuario  puede  ver  parte  de  la  información  de  cualquier  objeto.  

3.8.5 Anonymous  

• Descripción.  Representa  cada  uno  de  los  usuarios  de  tipo  visitante  que  interactúan  en  el  sistema.  La  clase  hereda  de  User.  

3.8.6 Member  

• Descripción.  Representa  cada  uno  de  los  usuarios  de  tipo  registrado  que  interactúan  en  el  sistema.  La  clase  hereda  de  User.  

• Atributos.  o id.  Valor  entero  que  identifica  el  usuario  en  el  sistema.  o username.  Nombre  que  identifica  al  usuario  en  el  sitio  web.  o password.  Contraseña  para  validar  la  cuenta  de  usuario.  o email.  Dirección  de  correo  electrónico  del  usuario.  o public_email.  Campo  booleano  que  indica  si  el  usuario  ha  decidido  que  su  

dirección  de  correo  electrónico  se  muestre  al  resto  de  usuarios.  o photografy.  Fotografía  del  usuario.  Identifica  al  usuario  en  el  sitio  web  de  

manera  visual.  o address.  Dirección  postal  de  la  ubicación  o  residencia  del  usuario.  o public_address.  Campo  booleano  que  indica  si  el  usuario  ha  decidido  que  su  

dirección  postal  se  muestre  al  resto  de  usuarios.  o objects_returned.  Campo  entero  que  acumula  el  número  de  objetos  que  el  

usuario  ha  encontrado  y  devuelto  a  su  propietario.  • Asociaciones.  

o Comment  -­‐  Object.  Un  usuario  registrado  puede  añadir  comentarios  en  cualquier  objeto.  

o Add  -­‐  Object.  Un  usuario  registrado  puede  añadir  diversos  objetos.  o Is  owner  –  Found.  Un  usuario  registrado  puede  ser  propietario  de  cualquier  

objeto  de  tipo  encontrado.  o Find  –  Lost.  Un  usuario  registrado  puede  encontrar  cualquier  objeto  de  tipo  

extraviado.  

Page 57: Proyecto!Final!deCarrera BCNLook$&Find

   

56    

3.8.7 Person  

• Descripción.  Representa  cada  uno  de  los  usuarios  de  tipo  registrado,  tras  los  cuales  hay  una  persona  física.  

• Atributos.  o id.  Valor  entero  que  identifica  la  persona  en  el  sistema.  o firstname.  Nombre  de  pila  de  la  persona.  o lastname.  Apellido  de  la  persona.  o public_name.  Campo  booleano  que  indica  si  la  persona  ha  decidido  que  su  

nombre  y  apellido  se  muestre  al  resto  de  usuarios.  o birth.  Fecha  de  nacimiento  de  la  persona.  o public_birth.  Campo  booleano  que  indica  si  el  usuario  ha  decidido  que  su  

fecha  de  nacimiento  se  muestre  al  resto  de  usuarios.  

3.8.8 Center  

• Descripción.  Representa  cada  uno  de  los  usuarios  de  tipo  registrado,  tras  los  cuales  hay  un  centro.  

• Atributos.  o id.  Valor  entero  que  identifica  el  centro  en  el  sistema.  o center_name.  Nombre  del  centro.  Identifica  el  centro  en  el  sitio  web.  o responsible_firstname.  Nombre  de  pila  de  la  persona  responsable  del  centro.  o responsable_lastname.  Apellido  de  la  persona  responsable  del  centro.  o information.  Información  del  centro.  Da  más  datos  sobre  la  labor  del  centro.  o url.  Dirección  del  sitio  web  del  centro.  o telephone.  Número  de  teléfono  de  contacto  con  el  centro.  o public_telephone.  Campo  booleano  que  indica  si  el  responsable  ha  decidido  

que  el  número  de  teléfono  del  centro  se  muestre  al  resto  de  usuarios.  

3.8.9 Object  

• Descripción.  Representa  cada  uno  de  los  objetos  añadidos  en  el  sistema.  • Atributos.  

o id.  Valor  entero  que  identifica  el  objeto  en  el  sistema.  o name.  Nombre  del  objeto.  Identifica  el  objeto  en  el  sitio  web.  o description.  Descripción  u  otros  comentarios  relacionados  con  el  objeto.  o address.  Dirección  postal  aproximada  en  la  que  se  ha  extraviado  o  encontrado  

el  objeto.  o date.  Fecha  aproximada  en  la  que  se  ha  extraviado  o  encontrado  el  objeto.  o photografy.  Fotografía  del  objeto.  Identifica  el  objeto  en  el  sitio  web  de  

manera  visual.  o tags.  Conjunto  de  etiquetas  que  identifican  el  objeto  en  el  sitio  web.  

• Asociaciones.  o Grouped  –  Category.  Diferentes  objetos  pueden  agruparse  en  una  misma  

categoría.  

Page 58: Proyecto!Final!deCarrera BCNLook$&Find

   

57    

3.8.10 Lost  

• Descripción.  Representa  cada  uno  de  los  objetos  extraviados  añadidos  en  el  sistema.  La  clase  hereda  de  Object.  

• Atributos.  o id.  Valor  entero  que  identifica  el  objeto  extraviado  en  el  sistema.  o reward.  Valor  decimal  que  representa  la  recompensa  que  el  usuario  que  ha  

añadido  el  objeto  ofrece  al  usuario  que  lo  encuentre.  o temp_finder.  Valor  entero  que  identifica  el  usuario  que  posiblemente  ha  

encontrado  el  objeto.  o finder.  Valor  entero  que  identifica  el  usuario  que  ha  encontrado  el  objeto.  

• Asociaciones.  o Has  -­‐  LostStatus.  Un  objeto  extraviado,  en  un  mismo  instante,  solo  puede  

tener  un  estado  de  objeto  extraviado.  o Finder  –  Member.  Un  objeto  extraviado,  solo  puede  ser  encontrado  por  un  

usuario  registrado.  

3.8.11 Found  

• Descripción.  Representa  cada  uno  de  los  objetos  encontrados  añadidos  en  el  sistema.  La  clase  hereda  de  Object.  

• Atributos.  o id.  Valor  entero  que  identifica  el  objeto  encontrado  en  el  sistema.  o question.  Pregunta  secreta  que  el  usuario  con  rol  “owner”    deberá  responder  

en  el  momento  que  indique  que  el  objeto  es  de  su  propiedad.  o temp_owner.  Valor  entero  que  identifica  el  usuario  que  posiblemente  es  el  

propietario  del  objeto.  o owner.  Valor  entero  que  identifica  el  usuario  propietario  del  objeto.  

• Asociaciones.  o Is  in  –  Location.  Un  objeto  encontrado,  solo  puede  estar  en  un  lugar.  o Has  -­‐  FoundStatus.  Un  objeto  encontrado,  en  un  mismo  instante,  solo  puede  

tener  un  estado  de  objeto  encontrado.  o Owner  –  Member.  Un  objeto  encontrado,  solo  puede  ser  propiedad  de  un  

usuario  registrado.  

Llegados  a  este  punto  se  ha  definido  cada  uno  de  los  elementos  que  componen  el  sistema  eZ  Publish,  desde  nivel  significado  a  nivel  representación.  Se  han  concreado  cada  uno  de  los  tipos  de  usuario  que  van  a  interactuar  con  el  sistema,  cómo  lo  van  a  hacer  y  que  roles  poseerán.  Se  han  expuesto  los  procesos  y  la  utilización  que  se  le  dará  al  sistema.  Es  el  momento  de  pasar  a  un  nivel  más  superficial  y  cercano  al  usuario.  

   

Page 59: Proyecto!Final!deCarrera BCNLook$&Find

   

58    

3.9 Diseño  de  la  interfaz  

En   esta   sección   se   concreta   la   ubicación  de   los   diferentes   elementos   que   componen  el   sitio  web,  para  ello  se  utilizan  plantillas  o  modelos  que  esquematizan  cada  una  de  las  pantallas.  

3.9.1 Pantalla  principal  

 

Plantilla  1,  Página  principal  

Como   puede   verse   en   la   plantilla   anterior,   la   página   principal   se   compone   de   dos   zonas,  además  de  la  cabecera  y  el  menú  principal.  

Cabecera  

La  cabecera  está  compuesta  por  el  título  o  logo  del  sitio  web  a   la   izquierda  y  un  conjunto  de  enlaces  en  la  parte  derecha.  Estos  enlaces  son  los  siguientes.  

Page 60: Proyecto!Final!deCarrera BCNLook$&Find

   

59    

• Identifícate.   Se  muestra  al  usuario  un   formulario  para  que  pueda   identificarse   como  usuario  registrado.  

• Regístrate.  Se  muestra  al  usuario  un  explicación  sobre  los  tipos  de  cuenta  que  puede  crear   (persona  o  centro)  y  dos  enlaces  a   las   respectivas  opciones.  Cuando  el  usuario  pulsa   sobre   una   de   las   dos   opciones,   accede   a   la   sección   Crear   cuenta,   expuesta   a  continuación.  

• Idiomas.   Se  muestran   todos   los   idiomas   en   los   que   se   encuentra   disponible   el   sitio  web.  Se  ha  decidido  que  por  el  momento  sean  español  ya  que  es  el  idioma  principal  y  catalán   ya   que   el   sitio   web   se   centra   en   usuarios   que   residen   en   Barcelona   y  alrededores.   Al   pulsar   sobre   un   idioma   se   accederá   al   sitio   web   en   el   idioma  seleccionado.  

Menú  principal  

En  el  menú  principal  se  muestran  las  siguientes  opciones.  

• BCN  y  alrededores.  Además  del  logo  o  título  de  la  cabecera  del  sitio  web,  no  está  de  más   añadir   una   opción   en   el   menú   que   además   de   redirigir   a   la   página   principal  informe  al  usuario  sobre  qué  contenido  está  visualizando.  En  este  caso  por  defecto  el  usuario  está  viendo  los  objetos  que  los  usuarios  han  registrado  en  el  sistema  y  todavía  no   han   sido   devueltos   a   sus   propietarios.   Una   muy   probable   futura   extensión   del  proyecto,  sea  la  de  extender  el  sistema  a  otras  ciudades,  esta  es  otra  razón  por  la  que  se  ha  seleccionado  este  nombre.  

• Comunidad.   Como   se   ha   comentado   anteriormente,   esta   sección   solo   estará  disponible   para   usuarios   con   cuenta   que   estén   identificados.   A   pesar   de   ello   se   ha  decidido   que   esta   opción   sea   siempre   visible   en   el   menú   principal,   para   que   los  usuarios   anónimos   sepan   de   su   existencia.   Lógicamente   cuando   un   usuario   no  identificado  pulse   sobre   ella,   se   le   notificará   que   primero   debe   crear   una   cuenta   de  usuario  o  identificarse  si  ya  la  posee.  

• Añadir  objeto.  De  la  misma  manera  que  la  sección  comunidad  se  ha  decidido  que  los  enlaces  a  los  formularios  para  añadir  objetos  sean  siempre  visibles  para  todos  los  tipos  de  usuario.  Evidentemente  cuando  un  usuario  anónimo  pulse  sobre  cualquiera  de  las  opciones   del   sub-­‐menú   de   añadir   objeto,   se   le   informará   que   primero   debe  identificarse   como  usuario   registrado.   Se   ha   creído   conveniente   que   este   botón   con  opciones   desplegables   sea   lo   más   llamativo   posible,   ya   que   al   fin   y   al   cabo   será   la  funcionalidad   utilizada   más   frecuentemente.   Inicialmente   se   decidió   utilizar   una  opción  que  re-­‐direccionará  a  una  sección  donde  se  expusieran  al  usuario   los  tipos  de  objetos   que   podía   registrar,   acompañados   de   dos   enlaces   a   los   respectivos  formularios.   Definitivamente   esta   idea   no   era   lo   suficiente   usable,   ya   que   es  imprescindible  que  el   usuario  pueda  acceder   al   formulario  para   añadir  objetos  de   la  forma  más  rápida  posible.  

• Buscador.   A   pesar   de   que   el   buscador   no   sea   una   opción   del  menú   principal   se   ha  escogido  esta  ubicación.  Por  espacio,  diseño  y  usabilidad.  Esta  funcionalidad,  como  se  ha   comentado   anteriormente,   permite   al   usuario   buscar   objetos   registrados   en   el  

Page 61: Proyecto!Final!deCarrera BCNLook$&Find

   

60    

sistema,  por  nombre,  descripción  u  otras  cadenas  de  caracteres  que  se  incluyan  en  su  información.  

Área  central  

Como  ya  se  intuye,  el  área  principal  muestra  una  lista  con  el  resumen  de  la  información  de  los  objetos  registrados  en  el  sistema  que  todavía  no  han  sido  devueltos  a  sus  propietarios.  En   la  parte   superior   de   esta   lista   se  muestran   tres   opciones   que   permiten   concretar   los   tipos   de  objetos  a  mostrar.  

• Objetos  para  localizar.  Cuando  el  usuario  selecciona  esta  opción,  se  muestran  solo  los  objetos  que  sus  propietarios  han  perdido  y  registrado.  (Objetos  de  tipo  perdido)  

• Objetos  para  devolver.  Cuando  el  usuario  selecciona  esta  opción,  se  muestran  solo  los  objetos  que  usuarios  han  encontrado  y  quieren  devolver  a  sus  propietarios.   (Objetos  de  tipo  encontrado).  

• Objetos  bajo   custodia.  El  usuario  podrá  seleccionar  cualquier  centro  registrado  en  el  sitio  web,  del  selector  y  automáticamente  se  mostrarán  solo  los  objetos  ubicados  en  el  centro   seleccionado.   Cuando   se   seleccione   está   opción   las   otras   dos   opciones  desaparecerán,  ya  que  un  centro  no  puede  registrar  objetos  que  ha  perdido  y  el  hecho  de  mostrar  estas  opciones  podrían  confundir  al  usuario.  Para  volver  a  ver   los  objetos  registrados  por  todos  los  tipos  de  usuario,  simplemente  se  tendrá  que  pulsar  sobre  la  opción  “BCN  y  alrededores”.  

Ha  sido  una  tarea  laboriosa  escoger  el  nombre  de  estas  opciones,  ya  que  parecía  que  cualquier  opción   era   confusa   para   el   usuario.   Han   sido   valoradas   diversas   alternativas   y   al   final   se   ha  recurrido  a  hacer  una  encuesta  a  usuarios  reales  y  la  opción  escogida  ha  sido  la  que  se  muestra  en  la  plantilla  y  en  el  sitio.  

En   una   versión   anterior   del   sitio   web,   se   había   ubicado   el   selector   de   centros   en   el   menú  principal,  pero  se  llegó  a  la  conclusión  que  su  tamaño  quitaba  protagonismo  a  otras  opciones.  La   ubicación   actual,   da   protagonismo   a   la   funcionalidad   de   buscar   objetos   depositados   en  centros,  pero  no  lo  quita  a  otras  más  importantes.  

Como  puede  verse  en  la  parte  posterior  de  la  lista  de  objetos  hay  un  mapa.  Esta  funcionalidad  permite   al   usuario   visualizar   de   manera   rápida   la   ubicación   de   los   objetos   que   se   están  mostrando  actualmente  en  la  lista.  La  lista  de  objetos  puedes  ser  larga  y  hacer  interminable  la  página   principal,   por   ese   motivo   se   ha   decidido   incluir   un   “paginador”,   de   esta   manera   se  pueden  dividir  los  objetos  a  mostrar  en  grupos  de  cinco  y  avanzar  o  retroceder  de  página.  Los  objetos  mostrados  en  el  mapa  también  varían  dependiendo  de  la  página  seleccionada.  A  pesar  de  haberse   tomado  esta  medida,   la   inclusión  del  mapa  en   la  página  principal  hacía  que  ésta  fuera   demasiado   larga.   Esto   provoca   que   el   usuario   tenga   que   desplazarse   demasiado  horizontalmente  para  ver  todo  el  contenido.  Para  solucionar  este  problema  sin  excluir  ninguna  funcionalidad,  se  ha  decidido  esconder  la  información  de  los  objetos.  Por  defecto  se  mostrará  la  cabecera  del  objeto  con  el  nombre  y  el  estado  en  el  que  se  encuentra,  pero  al  pulsar  sobre  cualquiera  de  ellos  se  desplegará  el  resto  de  la  información.  

Page 62: Proyecto!Final!deCarrera BCNLook$&Find

   

61    

Área  derecha  

En  el  área  derecha  del  sitio  web  se  mostrará  la  lista  de  categorías  de  objeto.  Cuando  el  usuario  pulse  sobre  cualquiera  de  estas  categorías  se  mostrará  en   la   lista  de  objetos  del  área  centra,  los   objetos   del   tipo   y   categoría   seleccionada.   Este   filtro   también   estará   disponible   para   los  objetos  registrados  por  un  centro.  

Justo  después  de  la  lista  de  categorías  se  ubica  la  nube  de  etiquetas.  Esta  nueve  de  etiquetas  muestra   las  etiquetas  más  utilizadas  por   los  usuarios  al   registrar   los  objetos.  Como  ya   se  ha  comentado   anteriormente   y   como   se  mostrará  más   adelante   en   los   formularios   para   añadir  objetos,   se   permite   a   los   usuarios   introducir   etiquetas   que   identifiquen   los   objetos   en   el  sistema.  

Esta   área   además   de   estos   bloques,   puede   incluir   otros   que   vayan   apareciendo   durante   el  desarrollo  del  sitio  web.  

3.9.2 Crear  cuenta  

Cuando  un  usuario  de  tipo  visitante  pulsa  sobre  cualquiera  de  los  enlaces  crear  cuenta  del  sitio  web,   se  muestra   una   sección   donde   se   explica   la   diferencia   entre   registrar   un  usuario   y   un  centro   y   se   le   hace   escoger.   Una   vez   el   usuario   pulsa   la   opción   de   registro   que   desea   se   le  muestran  los  siguientes  formularios.  

Crear  cuenta  de  usuario  persona  

 

Plantilla  2,  Crear  cuenta  de  usuario  persona  

   

Page 63: Proyecto!Final!deCarrera BCNLook$&Find

   

62    

Para  crear  una  cuenta  de  usuario  se  requieren  estos  datos:  

• Nombre  de  pila  del  usuario  que  va  a  crear  la  cuenta.  • Apellido  del  usuario  que  va  a  crear  la  cuenta.  • Nombre   de   usuario   que   le   identifica  en  el   sistema  y   se  muestra  públicamente  en  el  

sitio  web.  Se  le  pide  en  el  formulario  de  identificación.  • Contraseña   para   validar   la   cuenta   de   usuario.   Se   le   pide   en   el   formulario   de  

identificación.  • Confirmar   la   contraseña.   Se   utiliza   para   comprobar   que   el   usuario   no   ha   errado   al  

escribir  la  contraseña  escogida  y  para  evitar  registros  automáticos.  • Correo  electrónico  personal  del  usuario.  También  será  único  en  el  sistema.  Se  utiliza  

para  ponerse  en  contacto  con  el  usuario  si  fuera  necesario.  • Por  último  el  usuario  deberá  leer  y  aceptar  las  condiciones  de  uso  del  sitio  web.  Para  

ello  se  añadirá  un  enlace  para  acceder  al  documento.  

Crear  cuenta  de  usuario  centro  

 

Plantilla  3,  Crear  cuenta  de  usuario  centro  

Para  crear  una  cuenta  de  usuario  para  representar  a  un  centro  se  requieren  estos  datos:  

• Nombre  del  centro  para  el  que  se  va  a  crear  la  cuenta.  • Nombre  del  responsable  que  va  a  registrar  el  centro.  • Apellido  del  responsable  que  va  a  registrar  el  centro.  • Nombre  de  usuario  que  identifica  el  centro  en  el  sistema  y  se  muestra  públicamente  

en  el  sitio  web.  Se  le  pide  al  responsable  en  el  formulario  de  identificación.  

Page 64: Proyecto!Final!deCarrera BCNLook$&Find

   

63    

• Contraseña  para  validar  la  cuenta  del  centro.  Se  le  pide  al  responsable  en  el  formulario  de  identificación.  

• Confirmar  la  contraseña.  Se  utiliza  para  comprobar  que  el  responsable  no  ha  errado  al  escribir  la  contraseña  escogida  y  para  evitar  registros  automáticos.  

• Correo   electrónico   del   centro.   También   será   único   en   el   sistema.   Se   utiliza   para  ponerse  en  contacto  con  el  responsable  o  responsables  del  centro,  si  fuera  necesario.  

• Por  último  el  responsable  deberá  leer  y  aceptar  las  condiciones  de  uso  del  sitio  web.  Para  ello  se  añadirá  un  enlace  para  acceder  al  documento.  

Page 65: Proyecto!Final!deCarrera BCNLook$&Find

   

64    

3.9.3 Añadir  objeto  perdido  

 

Plantilla  4,  Añadir  objeto  perdido  

Si  el  usuario  pierde  un  objeto  y  no  lo  encuentra  entre  los  registrados  en  el  sistema,  es  lógico  pensar  que  querrá  añadirlo.  Para  ello  pulsará  sobre  la  opción  Añadir  objeto  y  después  sobre  la  

Page 66: Proyecto!Final!deCarrera BCNLook$&Find

   

65    

sub-­‐opción  Objeto   perdido.   Si   el   usuario   es   de   tipo   registrado   se   le  mostrará   el   formulario  representado   por   esta   plantilla.   Para   añadir   un   objeto   perdido   se   requerirán   los   siguientes  datos:  

• Como   ya   se   ha   comentado   en   puntos   anteriores   los   objetos   se   agruparán   por  categorías  para  facilitar  su  búsqueda.  

• El  nombre  del  objeto  lo  identificará  en  el  sistema.  • Opcionalmente   el   usuario   podrá   añadir   una  descripción   del   objeto   o   cualquier   otro  

comentario  que  crea  conveniente.  • El  usuario  tendrá  que  introducir  la  dirección  postal  aproximada  donde  cree  que  perdió  

el  objeto.  Teniendo  en  cuenta  que  probablemente  un  usuario  no  recuerde  la  dirección  postal  exacta  donde  perdió  un  objeto,  se  le  facilita  un  mapa.  

• Por   la   razón   antes   mencionada   se   dará   la   opción   al   usuario   de   introducir   una  descripción  del  lugar  donde  ha  perdido  el  objeto.  

• Debe  introducir  la  fecha  aproximada  en  la  que  cree  que  ha  perdido  el  objeto,  para  ello  se  le  facilita  un  calendario.  

• Opcionalmente  podrá  añadir  una  fotografía  del  objeto.  • El  usuario  podrá  ofrecer  una  recompensa  al  usuario  que  encuentre  su  objeto.  • Por  último  el  usuario  podrá  introducir  una  o  varias  etiquetas  separadas  por  comas  que  

identifiquen  su  objeto  en  el  sistema.  

Page 67: Proyecto!Final!deCarrera BCNLook$&Find

   

66    

3.9.4 Añadir  objeto  encontrado  

 

Page 68: Proyecto!Final!deCarrera BCNLook$&Find

   

67    

Plantilla  5,  Añadir  objeto  encontrado  

Si  el  usuario  se  encuentra  un  objeto  y  quiere  devolverlo  a  su  propietario,  pero  no  lo  encuentra  entre   los   registrados   en   el   sistema,   es   lógico   pensar   que   querrá   añadirlo.   Para   ello   pulsará  sobre  la  opción  Añadir  objeto  y  después  sobre  la  sub-­‐opción  Objeto  encontrado.  Si  el  usuario  es  de  tipo  registrado  se  le  mostrará  el  formulario  representado  por  esta  plantilla.  Para  añadir  un  objeto  encontrado  se  requerirán  los  siguientes  datos:  

• Como   ya   se   ha   comentado   en   puntos   anteriores   los   objetos   se   agruparán   por  categorías  para  facilitar  su  búsqueda.  

• El  nombre  del  objeto  lo  identificará  en  el  sistema.  • Opcionalmente   el   usuario   podrá   añadir   una  descripción   del   objeto   o   cualquier   otro  

comentario  que  crea  conveniente.  • El  usuario  tiene  que  introducir  la  dirección  postal  aproximada  donde  se  ha  encontrado  

el  objeto.  Teniendo  en  cuenta  que  probablemente  un  usuario  no  recuerde  la  dirección  postal  exacta  donde  ha  encontrado  un  objeto,  se  le  facilita  un  mapa.  

• Por   la   razón   antes   mencionada   se   dará   la   opción   al   usuario   de   introducir   una  descripción  del  lugar  donde  ha  encontrado  el  objeto.  

• Debe  introducir  la  fecha  aproximada  en  la  que  ha  encontrado  el  objeto,  para  ello  se  le  facilita  un  calendario.  

• Opcionalmente  podrá  añadir  una  fotografía  del  objeto.  • El  usuario  deberá  seleccionar  donde  se  encuentra  el  objeto  actualmente,  de  una  lista  

de  opciones.  Por  ejemplo,  el  usuario  ha  depositado  el  objeto  en  una  oficina  de  objetos  perdidos  o  lo  ha  entregado  a  la  policía  o  simplemente  lo  está  guardando  él.  

• Como   ya   se   ha   comentado   en   el   proceso   de   devolución   de   un   objeto,   una   vez   el  usuario   haya   publicado   el   objeto   recibirá   un   mensaje   de   correo   electrónico   en   el  momento  que  el  usuario  con  rol  “owner”    pulse  sobre  el  botón  Es  mío  del  objeto.  Para  que  el  usuario  pueda  ahorrarse  comunicarse  con  el  propietario  vía  correo  electrónico  para   asegurarse   que   el   objeto   es   suyo   realmente,   puede   introducir   una   pregunta  secreta   que   solo   el   verdadero  propietario   podrá   responder.   El   usuario   recibirá   en   el  mensaje  la  respuesta  a  la  pregunta  y  así  podrá  descartar  la  devolución  directamente  si  fuera  necesario.  

• Por  último  el  usuario  podrá  introducir  una  o  varias  etiquetas  separadas  por  comas  que  identifiquen  su  objeto  en  el  sistema.  

Page 69: Proyecto!Final!deCarrera BCNLook$&Find

   

68    

3.9.5 Información  completa  del  objeto  

 

Plantilla  6,  Información  completa  del  objeto  

Cuando  un  usuario  de  tipo  registrado  pulse  sobre  el  título  o  la  foto  de  un  objeto  de  la  lista  de  la  página  principal,  accederá  la  información  completa  de  éste.  En  esta  plantilla  se  expone  como  se  mostrará  la  información  del  objeto.  

En   la   parte   superior   se   mostrará   el   título   del   objeto,   el   tipo   del   objeto   (extraviado   o  encontrado)   y   si   se   trata   de   un   objeto   que   ha   añadido   el   usuario   que   lo   está   viendo,   se  mostrará  un  botón  para  editar  la  información  del  objeto.  

Page 70: Proyecto!Final!deCarrera BCNLook$&Find

   

69    

A   continuación   se  mostrará   la   categoría   a   la   que  pertenece  el   objeto,   acompañada  del   logo  que  representa  la  categoría.  En  el  extremo  derecho  se  mostrará  el  nombre  del  usuario  que  ha  registrado   el   objeto,   este   nombre   será   un   enlace   a   la   información   completa   del   usuario.  También  se  mostrará  una  fotografía  del  usuario.  

Como   se  puede   ver   en   la  plantilla   se  mostrará  el  mapa   con   la  dirección   postal   donde   se  ha  perdido  o  encontrado  el  objeto,  su  fotografía  y  una  tabla  con  el  resto  de  datos.  Las  filas  de  la  tabla  que  aparecen  en  rojo  simbolizan  datos  que  dependerán  del  tipo  el  objeto,  por  supuesto  si  el  objeto  es  de  tipo  perdido  se  mostrará  la  recompensa,  si  por  el  contrario  es  encontrado,  se  mostrará  la  localización  actual  y  la  pregunta  secreta  si  la  tuviera.  

Debajo  de   los  datos  del  objeto  aparecerá  el  botón  Lo  he  encontrado  o  Es  mío,  dependiendo  del  tipo  de  objeto.  La  funcionalidad  de  este  botón  es  la  misma  que  la  mencionada  en  la  lista  de  objetos  de  la  página  principal.  

Por   último,   en   la   parte   inferior   de   la   sección   se  mostrará   una   lista   de   comentarios   que   los  usuarios  han  hecho,  además  de  un  botón  que  posibilitará  añadir  nuevos.  

Page 71: Proyecto!Final!deCarrera BCNLook$&Find

   

70    

3.9.6 Comunidad  

 

Plantilla  7,  Comunidad  

Como  ya   se  ha  comentado  anteriormente,   solo   los  usuarios  de   tipo   registrado  podrán  ver   la  opción  Comunidad  en  el  menú  y  por  supuesto  acceder  a  la  sección.  

Esta  sección  servirá  para  que  el  usuario  pueda  ver  un  resumen  de  todo  lo  que  ha  ocurrido  en  el  sitio  web.  Se  ha  escogido  el  nombre  Comunidad  para  que  el  usuario  sienta  que  en  el  momento  de   crearse   una   cuenta   pasa   a   formar   parte   de   una   comunidad   y   no   solo   de   un   sitio   web  corriente.  

En   la   sección   se   divide   en   dos   zonas.   La   zona   primaria   se   sitúa   a   la   derecha   y   es   donde   se  muestre   el   contenido  más   importante.   La   zona   secundaria   se   sitúa   a   la   izquierda   y  muestra  sub-­‐secciones  y  otro  contenido  menos  importante.  

En   la  parte  superior  de   la  zona  derecha  se  muestra  un  resumen  de   los  datos  personales  del  usuario   que   está   en   este  momento   haciendo   uso   del   sitio.   Solo   se  muestran   el   nombre   de  usuario,  su  nombre  y  apellidos,  la  dirección  de  correo  electrónico  y  su  fotografía.  

Page 72: Proyecto!Final!deCarrera BCNLook$&Find

   

71    

El  siguiente  bloque  de  la  zona  de  la  derecha  muestra  una  pequeña  lista  con  las  cinco  últimas  aportaciones  que  el  usuario  ha  hecho  en  el   sitio.  Concretamente  mostrará  si  se  ha  añadido  algún  objeto,  si  se  ha  comentado  algún  o  si  ha  devuelto  o  le  han  devuelto  algún  objeto.  Cada  una   de   estas   aportaciones   contendrá   un   enlace   al   objeto   que   se   está   tratando   y   si   hay  implicado  algún  otro  usuario  también  habrá  un  enlace  a  sus  datos.  

El   último   bloque   de   la   zona   derecha  muestra   una   lista   de   las   últimas   diez   aportaciones   de  todos   los   usuarios   del   sistema.   Las   aportaciones   seguirán   el   mismo   criterio   que   las  aportaciones  personales.  

Por  supuesto,  cada  bloque  tiene  un  enlace  que  re-­‐direcciona    a  la  sub-­‐sección  correspondiente  donde   se   muestra   la   información   completa   correspondiente   a   la   sección.   La   sección  Mis  aportaciones  muestra  todas  las  aportaciones  personales  del  usuario  y  la  sección  Aportaciones  de   la   comunidad   muestra   todas   las   aportaciones   de   todos   los   usuarios   del   sistema.   Por  supuesto   cada   una   de   estas   secciones   dispone   de   un   “paginador”   que   ordenará   las  aportaciones  según  la  fecha  en  la  que  se  han  efectuado.  

Como  ya  se  ha  comentado,  el  primer  bloque  de  la  zona  de  la  izquierda  muestra  los  enlaces  a  las  sub-­‐secciones.  

A  continuación  se  mostrará  un  anuncio  agradeciendo   la   colaboración  al  último  usuario  que  ha  devuelto  algún  objeto.  Evidentemente  contendrá  enlaces  a  la  información  del  usuario  y  al  objeto  devuelto.  Este  bloque  es   importante  para  que   los  usuarios  que  consiguen  encontrar  y  devolver  objetos  a  sus  propietarios,  sientan  que  realmente  se  valora  su  colaboración.  Además  puede  generar  motivación  a  otros  usuarios.  

Por  último  se  muestra  otra  nube  de  etiquetas  como  la  de  la  página  principal.  

Page 73: Proyecto!Final!deCarrera BCNLook$&Find

   

72    

3.9.7 Mi  cuenta  

 

Plantilla  8,  Mi  cuenta  

Como  se  ha  expuesto  en  la  sección  anterior,  cuando  un  usuario  pulsa  sobre  el  enlace  Ver  todo  del  bloque  de  los  datos  del  usuario  o  sobre  la  opción  Mi  cuenta  del  sub-­‐menú,  accederá  a  la  información   personal   completa   del   usuario.   Esta   plantilla   representa   como   se  muestran   los  datos  de  la  cuenta  del  usuario  o  centro.  Cuando  un  usuario  acceda  a  la  información  completa  de  otro  usuario,   los  datos   se  mostrarán  de   la  misma  manera  con   la  diferencia  que   los  datos  que  el  usuario  haya  seleccionado  como  privados,  no  se  mostrarán.  

Para  editar  los  datos  de  la  cuenta  o  para  escoger  que  campos  serán  públicos  para  el  resto  de  usuarios,   se  debe  pulsar   sobre   el   botón  Editar   de   la   parte   superior   de   la   sección.   El   usuario  podrá  añadir  nuevos  datos  que  no  se  pidieron  en  el  formulario  de  registro.  

Page 74: Proyecto!Final!deCarrera BCNLook$&Find

   

73    

• Fecha  de  nacimiento.  El  usuario  podrá  escoger  si  se  muestra  al  resto  de  usuarios.  • Dirección  postal.  El  usuario  podrá  añadir  la  dirección  postal  de  su  residencia  y  escoger  

si  se  muestra  al  resto  de  usuarios.  

Si  se  trata  de  un  centro,  también  se  podrán  añadir  nuevos  datos  personales.  

• Dirección  postal.  El  responsable  podrá  añadir  la  dirección  postal  del  centro  registrado  y  escoger  si  muestra  al  resto  de  usuarios.  

• El  responsable  podrá  añadir  una  descripción  del  centro  registrado,  qué  tipo  de  centro  es,  a  qué  se  dedica,  si  es  público  o  privado,  etc.  

• Se  puede  añadir  la  dirección  del  sitio  web  del  centro.  • También   se   permite   añadir   un   número   de   teléfono   de   contacto   con   el   centro   y  

escoger  si  el  resto  de  usuarios  lo  podrán  ver.  De  esta  manera  se  facilita  que  cualquier  usuario  se  pueda  poner  en  contacto  con  el  centro.  

Justo  debajo  de   la   información  del  usuario  o  centro,   se  muestran   las  estadísticas  de  objetos  añadidos  y  devueltos  por  el  usuario.  Como  se  puede  ver  en  el  modelo  se  muestran  dos  tablas.  Una   corresponde   a   los   objetos   añadidos   por   el   usuario   diferenciados   entre   objetos   que   ha  extraviado  o  se  ha  encontrado  y  sobre  esa  cantidad  cuantos  ha  devuelto  o  le  han  devuelto.  La  segunda  tabla  corresponde  a  los  objetos  añadidos  por  otro  usuario  que  han  sido  devueltos  al  usuario  o  ha  devuelto  a  su  propietario.  

Page 75: Proyecto!Final!deCarrera BCNLook$&Find

   

74    

3.9.8 Top  10  

 

Plantilla  9,  Top  10  

Este  modelo  representa  la  sección  Top  10.  En  esta  sección  se  muestran  los  diez  usuarios  que  más   objetos   han   encontrado   y   devuelto   a   sus   propietarios.   Para   que   la   página   no   sea  demasiado   larga   y   el   usuario   no   tenga   que   hacer   uso   excesivo   de   la   barra   lateral   para  desplazarse,   se  muestra   la   información   en   pequeñas   barras   verticales,   exceptuando   las   tres  primeras   que   serán   un   poco   más   grandes.   De   esta   manera   también   se   les   otorga   más  importancia   a   los   usuarios   en   las   tres   primeras   posiciones.   En   cada   una   de   las   barras   se  mostrará  la  información  siguiente:  

• Posición   en   el   ranking   según   el   número   de   objetos   encontrados   y   devueltos   a   sus  propietarios.  

• Número  de  objetos  encontrados  y  devueltos  a  sus  propietarios.  • Nombre  del  usuario  con  enlace  a  su  información  completa.  • Fotografía  del  usuario  con  enlace  a  su  información  completa.  

Llegado  este  punto  se  ha  finalizado  la  especificación  del  sistema  BCN  Look  &  Find.  

   

Page 76: Proyecto!Final!deCarrera BCNLook$&Find

   

75    

4 Desarrollo  del  sistema  

En  esta  sección  se  exponen  los  pasos  que  se  han  seguido  para  desarrollar  el  sistema  BCN  Look  &   Find   sobre   el   sistema   de   gestión   de   contenido   eZ   Publish.   Para   ello   se   ha   utilizado   una  metodología  ágil,  en  el  sentido  de  que  se  han  llevado  a  cabo  constantes  iteraciones  con  puntos  de   control   y   retroalimentación.   Concretamente   se   han   hecho   pequeños   desarrollos   de  aproximadamente  unas  dos  semanas  de  duración,  con  una  posterior  reunión  con  las  directoras  del   proyecto,   para   revisar   el   resultado   y   compararlo   con   los   requerimientos,   sacar  conclusiones   y   planificar   mejoras,   modificar   la   especificación,   documentación,   diseño,  funcionalidades,  etc.  

4.1 Introducción  al  sistema  eZ  Publish  

En   primer   lugar   se   expone   una   breve   introducción   al   sistema   eZ   Publish.   En   general   la  información  ha  sido  obtenida  del  sitio  web  de  documentación  de  eZ  Publish  (34)  y  de  su  sitio  web   oficial   ez.no   (22).   Para   los   detalles   técnicos   del   sistema   y   para   la   utilización   de   su  “framework”,  han  sido  de  gran  ayuda  estos  sitios  web,  pero  algunos  detalles  más  teóricos  y  de  utilización  de  la  plataforma,  ha  sido  necesario  obtener  información  de  los  siguientes  libros,  eZ  Publish  Content  Management  (35),  eZ  Publish  Basics  (36)  y  eZ  Publish  Enterprise  Tour  (37).  

Como  la  mayoría  de  sistemas  de  gestión  de  contenidos,  eZ  Publish  consiste  en  una  aplicación  compuesta  de  diferentes  módulos,  conectada  a  una  base  de  datos,  donde  se  almacenan  todos  los   elementos,   contenidos   y   características   que   lo   componen.   Esta   aplicación   permite   al  usuario  elaborar  su  sitio  web.  

Este   sistema   se   ha   desarrollado   siguiendo   el   patrón   de   arquitectura   “Modelo   Vista  Controlador”  (MVC).  Este  patrón  consiste  en  mantener  una  separación  entre  los  componentes  que   forman   la   capa   de   presentación,   más   cercana   al   usuario   (Vista),   los   componentes   que  forman  la  capa  sobre  la  que  se  manejan  los  datos,  procesado,  almacenamiento,  etc.  (Modelo)  y  los  elementos  que  se  utilizan  de  intermediarios  entre  las  otras  dos  capas  (Controlador).  

En   el   caso   de   eZ   Publish,   la   capa   vista   está   formada   por   plantillas   TPL,   hojas   de   estilo   CSS,  JavaScript,   imágenes,  etc.  Las  plantillas  TPL  se  codifican  mezclando  código  HTML   y  el  código  propio  del  motor  que   intercambia  datos  entre  el  controlador  y   la  vista.  La  capa  modelo  está  formada  por  una  base  de  datos  MySQL   y   clases  PHP   que   interactúan  directamente  con  esta  base  de  datos.  Por  último  la  capa  controlador  está  formada  por  clases,  módulos  y  “scripts”  PHP  que  intercambian  datos  del  modelo  a  la  vista  y  viceversa.  

El  conjunto  de  estas  tres  capas  forman  un  sitio  web  personalizable.  El  sitio  web  se  compone  de  dos   páginas,   el   frontal   (“front-­‐end”)   donde   pueden   verse   los   resultados   que   finalmente  visualizará  el  usuario  y  el  “back-­‐end”  sobre  el  que  el  administrador,  desarrollador,  etc.,  puede  administrar,  crear,  borrar  y  editar  el  contenido.  

Antes   de   exponer   el   funcionamiento   del   sistema   eZ   Publish   es   necesario   definir   algunos  conceptos  y  elementos.  

Page 77: Proyecto!Final!deCarrera BCNLook$&Find

   

76    

4.1.1 Conceptos  básicos  sobre  eZ  Publish  

El  sistema  eZ  Publish  denomina  “object”  (objeto)  a  cada  uno  de  los  elementos  que  forman  el  contenido  del  sistema.  El  concepto  objeto  es  similar  al  conocido  de  lenguajes  de  programación  orientados  a  objetos  ya  que  al  fin  y  al  cabo  los  contenidos  del  sistema  son  instancias  de  clases  que   definen   su   estructura.   Puesto   que   este   proyecto   trabaja   con   objetos   perdidos,  encontrados,   etc.,   a   partir   de   ahora   se   utilizará   la   palabra   “contenido”   para   referirse   a   este  elemento  y  omitir  posibles  confusiones.  Un  ejemplo  de  contenido  es  un  usuario.  

Como   se   ha   comentado   los   contenidos   del   sistema   son   instancias   de   clases   que   definen   su  estructura.   eZ   Publish   utiliza   el   elemento   “class”   (clase),   para   definir   la   estructura   de   los  contenidos  que  se  crean  en  el  sistema.  Un  ejemplo  de  clase  es  la  que  define  la  estructura  de  un  usuario.  

Las  clases  que  definen  la  estructura  de  los  contenidos  están  formadas  por  “datatypes”  (tipos  de  datos).  Estos  tipos  de  datos  pueden  ser  desde  lo  más  simple  como  una  línea  de  texto,  a  más  complejos  como  un  mapa  de  Google.  

Los   objetos   creados   a   partir   de   las   clases   están   compuestos   de   “attributes”   (atributos).   Un  atributo  no  es  más  que  el  contenido  asignado  a  un  tipo  de  dato  de  la  clase  sobre  la  que  se  ha  creado  el  objeto.  

Un  “node”   (nodo),  es  otro  elemento  abstracto  que  el   sistema  utiliza  para  denominar  a   cada  una  de  las  ubicaciones  de  los  contenidos.  Un  contenido  puede  ser  accesible  desde  diferentes  puntos  del  sitio  web  y  mostrarse  de  diferentes  maneras.  Por  ejemplo  un  mismo  usuario  puede  mostrarse  accediendo  desde  la  página  principal  o  desde  la  sección  “Comunidad”.  El  acceso  al  usuario   también   es   diferente,   puede   ser   un   enlace   con   su   nombre,   una   fotografía,   etc.   Y  también   pueden  mostrarse   los   datos   del   usuario   de  manera   diferente,   en   ocasiones   puede  mostrarse   solo   su   nombre   o   en   otras   toda   su   información,   etc.   Cada   una   de   estas  “exposiciones”  de  un  contenido  se  denomina  nodo.  

Para   completar   la   definición   de   estos   conceptos   básicos   a   continuación   se   muestra   un  diagrama   utilizando   como   ejemplo   un   objeto   perdido   registrado   en   el   sistema   por   algún  usuario.  

Page 78: Proyecto!Final!deCarrera BCNLook$&Find

   

77    

 

Diagrama  15,  Estructura  del  contenido  eZ  Publish  

4.1.2 Estructura  de  la  base  de  datos  

A  diferencia  de  un  sitio  web  desarrollado  desde  cero  o  sobre  un  “framework”,  un  sistema  de  gestión  de  contenido  dispone  de  una  estructura  de  base  de  datos  muy  genérica,  ya  que  tiene  que  adaptarse  a   los  requerimientos  de  cualquier  sitio  web.  Por  ejemplo,  si  se  hubiera  tenido  que   desarrollar   la   estructura   de   base   de   datos   para   el   sistema   BCN   Look   &   Find,   ésta  dispondría  de  tablas  como  “lost_objects”  y  “found_objects”  que  almacenarían  la   información  de  los  objetos  registrados  por  los  usuarios,  pero  la  estructura  sobre  la  que  se  ha  trabajado  es  más  compleja.    

A   continuación   se  expone  parte  de   la  estructura  de   la  base  de  datos  del   sistema  eZ  Publish.  Puesto  que  es  un  sistema  amplio,  sólo  se  muestran   los  elementos  que  afectan  e   interactúan  más  directamente  el  sistema  BCN  Look  &  Find.  

Page 79: Proyecto!Final!deCarrera BCNLook$&Find

   

78    

A   continuación   se  describe   la   función  de   cada  una  de  estas   tablas   y   se  define   su  estructura,  columnas,  claves  primarias,  asociaciones,  etc.  

Ezcontentclass  Como   se   ha   comentado   anteriormente,   el   sistema   eZ   Publish   utiliza   un   elemento   llamado  clase,  para  representar  la  estructura  de  cada  uno  de  los  contenidos,  define  qué  atributos  tiene,  de  que  tipo  son,  etc.  Esta  tabla  es  la  encargada  de  almacenar  esta  información.  

• Clave  primaria.  (id,  version).  • Atributos.  

o id.  Valor  entero  que  identifica  la  clase  en  el  sistema.  o version.  Valor  entero  que  representa  la  versión  de  la  clase.  o created.  Fecha  de  creación  de  la  clase.  o modified.  Fecha  de  la  última  modificación  de  la  clase.  o identifier.  Nombre  único  que  identifica  la  clase  en  el  sistema.  o contentobject_name.  Este  campo  especifica  el  atributo  de  la  clase  encargado  

de  identificar  cada  uno  objetos  instanciados  de  ella.  o url_alias_name.  Atributo  utilizado  como  alias  de  URL  para  acceder  a  las  

secciones/contenidos  creados  a  partir  de  esta  clase.  o creator_id.  Valor  entero  que  identifica  al  usuario  que  ha  creado  la  clase.  o modifier_id.  Valor  entero  que  identifica  al  último  usuario  que  ha  modificado  la  

clase.  • Asociaciones.  

o ezcontentclass_name.  Una  clase  puede  tener  diferentes  nombres  dependiendo  de  su  versión.  

o ezcontentclass_attribute.  Una  clase  está  formada  por  diversos  atributos.  o ezcontentobject.  Una  clase  puede  tener  diferentes  objetos  (instancias)  que  

forman  el  contenido  del  sitio  web.  

Diagrama  16,  Base  de  datos  

Page 80: Proyecto!Final!deCarrera BCNLook$&Find

   

79    

ezcontentclass_name  Esta  tabla  se  encarga  de  almacenar  en  base  de  datos  cada  uno  de  los  nombres  que  tenido  una  clase   en   el   sistema.   Cuando   un   usuario   administrador   puede   editar   las   clases,   se   hace  necesario  mantener  un  control  de  versiones.  

ezcontentclass_attribute  Como  se  ha  comentado  anteriormente  las  clases  definen  la  estructura  del  contenido,  en  esta  tabla  de  base  de  datos  se  almacena  la  estructura  y  el  tipo  de  cada  uno  de  los  atributos  de  una  clase.  

• Clave  primaria.  (id,  version).  • Atributos.  

o id.  Valor  entero  que  identifica  el  atributo  de  clase  en  el  sistema.  o version.  Valor  entero  que  representa  la  versión  del  atributo  de  clase.  o identifier.  Nombre  único  del  atributo  que  lo  identifica  en  el  sistema.  o data_float.  Si  el  atributo  contiene  información  de  tipo  decimal  se  almacena  en  

este  campo.  o data_int.   Si   el   atributo   contiene   información   de   tipo   entero   se   almacena   en  

este  campo.  o data_text.  Si  el  atributo  contiene  información  de  tipo  texto  se  almacena  en  

este  campo.  o data_type_string.   Si   el   atributo   contiene   información   de   tipo   cadena   de  

caracteres,  aquí  se  especifica  el  tipo  de  cadena  de  caracteres  usado.  o is_required.  Valor  entero  que  especifica  si  el  atributo  es  requerido.  o contentclass_id.   Valor   entero   que   identifica   la   clase   a   la   que   pertenece   el  

atributo.  • Asociaciones.  

o ezcontentclass.   Un   atributo   de   clase   en   una   versión   específica   pertenece  únicamente  a  una  clase.  

o ezcontentclass_attribute.   Un   atributo   de   clase   en   una   versión   específica  contiene  varios  atributos  de  clase.  

ezcontentobject  Esta  tabla  es  la  encargada  de  almacenar  la  información  de  cada  uno  de  los  objetos  (instancias)  creados   a   partir   de   las   clases.   Estos   elementos   representan   el   contenido   del   sitio   web.   Su  estructura  es  muy  similar  a  la  de  las  clases.  

• Clave  primaria.  id.  • Atributos.  

o id.  Valor  entero  que  identifica  el  atributo  de  clase  en  el  sistema.  o published.  Fecha  de  publicación  del  contenido.  o modified.  Fecha  de  la  última  modificación  del  contenido.  o current_version.  Valor  entero  que  representa  la  versión  que  actualmente  está  

en  curso.  o owner_id.  Valor  entero  que  identifica  al  usuario  propietario  del  contenido  

(creador).  

Page 81: Proyecto!Final!deCarrera BCNLook$&Find

   

80    

o status.  Valor  entero  que  representa  el  estado  en  el  que  se  encuentra  el  contenido.  

o name.  Nombre  del  contenido.  o contentclass_id.  Valor  entero  que  representa  la  clase  a  la  que  pertenece  el  

contenido.  • Asociaciones.  

o ezcontentclass.  Un  contenido  pertenece  únicamente  a  una  clase.  o ezcontentobject_name.  Un  contenido  puede  disponer  de  diferentes  nombres  

según  su  versión.  o ezcontentobject_version.  Un  contenido  puede  disponer  de  diferentes  

versiones.  o ezcontentobject_attribute.  Un  contenido  está  formado  por  varios  atributos  de  

objeto.  o ezuser.  Un  contenido  puede  representar  varios  usuarios.  

ezcontentobject_name  De  la  misma  manera  que  para  las  clases,  esta  tabla  se  encarga  de  almacenar  cada  uno  de  los  nombres  que  ha  tenido  un  objeto  según  su  versión.  

ezcontentobject_version  Junto   con   los   datos   almacenados   en   la   tabla   anterior,   esta   tabla   mantiene   un   control   de  versiones  de  cada  uno  de  los  contenidos  creados  en  el  sistema.  

• Clave  primaria.  id.  • Atributos.  

o id.  Valor  entero  que  identifica  la  versión  del  contenido  en  el  sistema.  o created.  Fecha  de  creación  de  la  versión  del  contenido.  o version.  Valor  entero  que  representa  la  versión  del  contenido.  o status.  Valor  entero  que  representa  el  estado  en  el  que  se  encuentra  la  

versión  del  contenido.  o creator_id.  Valor  entero  que  identifica  el  usuario  creador  de  la  versión  del  

contenido.  o user_id.  Valor  entero  que  identifica  al  usuario  al  que  representa  la  versión  del  

contenido,  si  es  que  representa  a  algún  usuario.  o contentobject_id.    Valor  entero  que  identifica  el  contenido  al  que  pertenece  la  

versión.  • Asociaciones.  

o ezcontentobject.  Una  versión  de  contenido  pertenece  únicamente  a  un  contenido.  

ezcontentobject_attribute  

De  la  misma  manera  que  para  las  clases,  esta  tabla  de  base  de  datos  almacena  la  información  de   cada   uno   de   los   atributos   de   los   contenidos.   Puesto   que   su   estructura   es   similar   a  “ezcontentclass_attribute”,  no  se  entra  en  detalle.  

Page 82: Proyecto!Final!deCarrera BCNLook$&Find

   

81    

ezuser  

Esta  tabla  de  base  de  datos  almacena  la  información  de  cada  una  de  las  cuentas  de  usuario  del  sistema.  El  sistema  eZ  Publish,  como  el  resto  de  elementos,  representa  cada  cuenta  de  usuario  como  un  contenido  con  algunas  peculiaridades,  que  se  exponen  a  continuación.  

• Clave  primaria.  (contentobject_id).  • Atributos.  

o contentobject_id.  Valor  entero  que   identifica  el   contenido  que   representa  al  usuario  en  el  sistema.  

o email.  Dirección  de  correo  electrónico  única  del  usuario.  o login.  Nombre  de  usuario  único  que  identifica  al  usuario  en  el  sistema.  o password_hash.  Contraseña  para  que  el  usuario  pueda  acceder  a  su  cuenta.  

• Asociaciones.  o ezcontentobject.  Un  usuario  es  representado  por  un  único  contenido.  o ezuser_role.  Un  usuario  puede  disponer  varios  roles  de  usuario.  

ezrole  

Esta  tabla  de  base  de  datos  almacena  la  información  de  cada  uno  de  los  roles  de  usuario.  

• Clave  primaria.  id.  • Atributos.  

o id.  Valor  entero  que  identifica  el  rol  de  usuario  en  el  sistema.  o version_id.  Valor  entero  que  representa  la  versión  del  rol  de  usuario.  o name.  Nombre  del  rol  de  usuario.  

• Asociaciones.  o ezuser_role.  Un   rol  de  usuario  puede   tener  varias   relaciones  entre  usuario  y  

rol.  o ezpolicy.  Un  rol  de  usuario  puede  poseer  varias  políticas.  

ezuser_role  

Esta   tabla   de   base   de   datos   almacena   la   información   de   cada   una   de   las   relaciones   entre  usuarios  y  roles  de  usuario.  

ezpolicy  

Esta  tabla  de  base  de  datos  almacena  la  información  de  cada  una  de  las  políticas  que  definen  los  permisos  de  usuario.  

• Clave  primaria.  id.  • Atributos.  

o id.  Valor  entero  que  identifica  la  política  en  el  sistema.  o function_name.   Nombre   único   que   de   la   función   sobre   la   que   se   define   la  

política  de  permisos.  o module_name.  Nombre  único  del  módulo  de  eZ  Publish  sobre  el  que  se  está  

definiendo  la  política  de  permisos.  

Page 83: Proyecto!Final!deCarrera BCNLook$&Find

   

82    

o role_id.  Valor  entero  que  identifica  el  rol  al  que  pertenece  la  política.  • Asociaciones.  

o ezrole.  Una  política  de  permisos  pertenece  únicamente  a  un  rol  de  usuario.  o ezpolicy_limitation.   Una   política   de   permisos   puede   disponer   varias  

limitaciones.  

ezpolicy_limitation  

Esta   tabla   de   base   de   datos   almacena   la   información   de   cada   una   de   las   limitaciones   de  permisos  del  sistema.  

• Clave  primaria.  id.  • Atributos.  

o id.  Valor  entero  que  identifica  la  limitación  de  permisos  en  el  sistema.  o identifier.  Nombre  único  que  identifica  la  limitación  de  permisos  en  el  sistema.  o policy_id.   Valor   entero   que   identifica   la   política   sobre   la   que   se   aplica   la  

limitación  de  permisos.  • Asociaciones.  

o ezpolicy.   Una   limitación   de   permisos,   limita   únicamente   una   política   de  permisos.  

o ezpolicy_limitation_value.  Una  limitación  puede  disponer  de  varios  valores.  

ezpolicy_limitation_value  

Esta  tabla  de  base  de  datos  almacena  la  información  de  cada  uno  de  los  valores  de  limitaciones  de  permisos.  

• Clave  primaria.  id.  • Atributos.  

o id.  Valor  entero  que  identifica  el  valor  de  limitación  de  permisos  en  el  sistema.  o value.   Valor   alfabético,   cuyo   significado   representa   una   limitación   de  

permisos.  o limitation_id.  Valor  entero  que  identifica  la  limitación  de  permisos  a  la  que  se  

le  aplica  este  valor.  • Asociaciones.  

o ezpolicy_limitation.   Un   valor   se   aplica   a   una   única   limitación   de   política   de  permisos.  

4.1.3 Estructura  de  directorios  

Después  de  analizar  la  estructura  de  base  de  datos,  es  el  momento  de  analizar  la  estructura  de  directorios  que  forman  el  código  del  sistema  eZ  Publish.  

Page 84: Proyecto!Final!deCarrera BCNLook$&Find

   

83    

 

Imagen  1,  Estructura  de  directorios  del  sistema  

El   sistema   eZ   Publish   se   compone   de   los   directorios   mostrados   en   la   imagen   anterior.   A  continuación  se  van  a  mencionar  los  más  importantes  y  sobre  los  que  se  ha  trabajado.  

• El   directorio   “bin”   contiene   “scripts”   PHP   ejecutables   necesarios,   entre   otras   cosas,  para   el  mantenimiento   del   sistema.  Un   “script”   que   normalmente   se   ha   utilizado   es  “ezcache.php”.   El   código   de   este   ejecutable   parametrizable,   elimina   los   datos  almacenados  en  la  memoria  cache  del  sistema.  Muy  útil  cuando  se  efectúan  cambios  de  código  o  de  diseño.  

• El  directorio  “design”  contiene  todos  los  elementos  que  componen  el  diseño  del  sitio  web,  plantillas  TPL,  archivos  CSS,   imágenes,   ficheros   JavaScript,  etc.  Cada  uno  de   los  diseños   del   sistema   se   encuentran   dentro   de   diferentes   directorios   que   tienen   la  misma   estructura.   Por   ejemplo   podemos   directorios   de   diseño   como   “standard”,  “ezflow”,  ezwebin”,  etc.  La  estructura  interna  de  estos  elementos  se  compone  de  un  directorio   para   imágenes,   otro   para   “JavaScript”,   otro   para   estilos   CSS,   otro   que  contiene   las  plantillas   TPL   y  por  último  otro   llamado   “override”.   El   último   fichero   se  utiliza   para   sobrescribir   cualquier   tipo   de   elemento   de   diseño   utilizando   la   misma  estructura  de  directorios.  Por  ejemplo  si  se  decide  sobrescribir  la  plantilla  que  muestra  el   formulario   de   registro   de   usuarios,   esta   se   creará   dentro   del   directorio  “override/templates”  con  el  nuevo  nombre  especificado  y  el  sistema  creará  una  regla  de   sobrescritura   que   obligará   a  mostrar   esta   plantilla   en   vez   de   la   original.   El   tema  diseño  será  expondrá  más  profundamente  en  secciones  posteriores.  

• El  directorio  “extension”  es  indiscutiblemente  el  más  utilizado.  Aquí  se  guardan  todas  las  extensiones  del  sistema  eZ  Publish.  Una  extensión,  como  su  propio  nombre  indica  es   cualquier   módulo   de   código   que   extiende   las   funcionalidades   o   el   diseño   del  sistema  por  defecto.  Por  supuesto  el  sistema  eZ  Publish  contiene  por  defecto  algunas  extensiones,  estas  extensiones  pueden  activarse  o  desactivarse  en  cualquier  momento  desde   la   página   de   administración.   Estas   extensiones   también   pueden   contener  directorios   de   diseño,   el   sistema   eZ   Publish   busca   inicialmente   elementos   de   diseño  dentro  de   las  extensiones,  si   los  encuentra,   los  utiliza,   sino   los  busca  en  el  directorio  

Page 85: Proyecto!Final!deCarrera BCNLook$&Find

   

84    

por   defecto   “design”.   El   tema   extensiones   funcionales   y   de   diseño   se   tratará   más  profundamente  en  secciones  posteriores.  

• El   directorio   “kernel”   es   el   más   importante   del   sistema,   ya   que   contiene   todos   los  módulos  y  código  PHP  por  defecto  que  permite  el  funcionamiento  básico  del  sistema  eZ  Publish.  No  es  conveniente  modificar  los  archivos  de  este  directorio,  se  recomienda  utilizar   extensiones,   ya   que   en   todo   momento   se   puede   volver   al   sistema   original  eliminando   la   extensión   creada.   Además   al   instalar   una   actualización   del   sistema,  podrían   substituirse   ficheros   del   directorio   “kernel”   y   perder   todo   lo   que   se   haya  modificado  en  su  interior.  En  ocasiones  no  hay  más  remedio.  

• El   directorio   “settings”   guarda   todos   los   archivos   que   definen   la   configuración   del  sistema.  Estos   ficheros  se  crean  automáticamente  con   la   instalación  de   la  aplicación,  con  los  datos  que  se  le  han  introducido.  En  estos  ficheros  se  encuentra  datos  como  los  de  conexión  a  base  de  datos,  título  del  sitio  web,  idiomas  disponibles,  etc.  

• El   directorio   “share”   contiene   todos   los   ficheros  de   traducción  del   sitio  web.   El   sitio  web  de  BCN  Look  &  Find  está  disponible  en  castellano  y  catalán,  por   lo   tanto  se  han  tenido  que  insertar  y  modificar  traducciones  en  los  dos  ficheros  correspondientes.  

• El  directorio  “var”  contiene  entre  otras  cosas,  datos  almacenados  en  memoria  cache,  imágenes  insertadas  por  usuarios,  etc.  

Una   vez   introducidos   los   aspectos   básicos   del   sistema   de   gestión   de   contenido   que   se   ha  utilizado  para  el  desarrollo  del  sitio  web,  se  procede  a  exponer  los  pasos  que  se  han  llevado  a  cabo  para  desarrollar  el  sistema  BCN  Look  &  Find.  

4.2 Instalación  del  sistema  

El  primer  paso  ha  sido   instalar  el  sistema  eZ  Publish.   Inicialmente  se   instaló   la  última  versión  en  curso  4.3,  pero  conforme  fue  avanzando  el  proyecto  fue  publicada  una  nueva  versión  4.4,  puesto   el   desarrollo   del   proyecto   todavía   no   estaba   muy   avanzado   se   decidió   actualizar   el  sistema  con  dicha  versión.  El  sistema  se  ha  descargado  de  share.ez.no  (38).  

Según  la  documentación  doc.ez.no  (34),  los  requisitos  recomendados  para  un  funcionamiento  óptimo  del  sistema  eZ  Publish  4.4  son  los  siguientes.  

• Sistema  operativo  Debian  2.0  o  Linux  2.6  • Servidor  web  Apache  2.2.16.  • Base  de  datos  MySQL  5.0.51a.  • PHP  5.2.14.  • Aplicación  para  administración  de  imágenes  ImageMagick  6.4.9.  

Los  requisitos  mínimos  para  el  funcionamiento  del  sistema  eZ  Publish  4.4  son  los  siguientes.  

• Sistema   operativo  Windows   2008   o   posterior,   Solaris   10   Intel   with   Sun   Webstack,  Opensolaris  2009.06  Intel.  

• Servidor  web  Apache  2.2.x,  MS  IIS  7  con  Microsoft  URL  Rewrite  Module  1.1.  • Base  de  datos  MySQL  5.0.x,  5.1.x,  PostgreSQL  8,  Oracle  11g.  • PHP  5.2.1  o  posterior  y  PHP  5.3.x.  

Page 86: Proyecto!Final!deCarrera BCNLook$&Find

   

85    

• Aplicación  para  administración  de  imágenes  ImageMagick  6.4.x  o  PHP  extensión  GD2.  

4.3 Desarrollo  de  secciones  básicas  

Como   se   ha   comentado   anteriormente,   para   el   aprendizaje   del   sistema   ha   sido   necesario  utilizar   la  documentación   y   algún   libro   indicados   anteriormente,   pero  para   algunos   aspectos  del  desarrollo  no  ha  sido  suficiente  y  se  ha  tenido  que  recurrir  al  foro  oficial  share.ez.no  (39).  Gran  parte  de  la  información  obtenida  por  otros  usuarios  ha  sido  de  gran  ayuda  y  una  manera  de  avanzar  un  poco  más  rápido  en  el  aprendizaje  del  sistema.  

Como  se  ha  comentado  anteriormente  eZ  Publish  utiliza  una  tabla  genérica  en  base  de  datos  para  guardar  todo  el  contenido  creado  en  el  sistema.  La  estructura,  campos  y  datos  de  estos  elementos  llamados  objetos  vienen  definidos  por   los  registros   llamados  clases  contenidos  en  otra  tabla  genérica.  La  página  de  administración  del  sistema  eZ  Publish  permite  crear  objetos  utilizando  clases  por  defecto  o  crear  nuevas  clases  con  la  estructura  que  el  usuario  desee.  

Lo  primero  que  se  ha  llevado  a  cabo  en  el  desarrollo  del  sistema  es  la  creación  de  las  secciones  básicas  del  sitio  web.  

Las   secciones   “¿Qué   es   BCN   Look   &   Find?”,   “Preguntas   más   frecuentes”,   “Condiciones   de  uso”   y   “Política   de   privacidad”   se   han   creado   utilizando   la   clase   por   defecto   de   eZ   Publish  “Documentation   page”.  Esta  clase  permite   introducir  un   título  que   identifica   la   sección  y  un  área  de  texto.  

El   sistema   crea   automáticamente   un   nodo   principal   para   cada   objeto   creado.   Este   nodo  representa  la  visualización  en  el  sitio  web  del  objeto  creado.  Cada  uno  de  los  nodos  dispone  de  plantillas  TPL  en  la  capa  “vista”  del  sistema.  La  plantilla  que  utilizan  por  defecto  los  objetos  de  la  clase  “Documentation  page”  pertenecen  a  la  extensión  de  eZ  Publish  “ezwebin”.  

Esta  plantilla  muestra  el  contenido  del  objeto.  Además  construye  un  índice  si  el  texto  adjunto  incluye  títulos  y  sub-­‐títulos  y  añade  un  pie  con  la  fecha  de  actualización  de  la  información.  

Por  defecto,  si  el  usuario  dispone  de  los  permisos  adecuados,  el  sistema  crea  una  opción  en  el  menú  principal  para  acceder  a  las  secciones.  En  un  inicio  se  pensó  el  diseño  del  sitio  web  para  que  las  secciones  “¿Qué  es  BCN  Look  &  Find?”  y  “Preguntas  más  frecuentes”,  fueran  accesibles  desde   el   menú   principal,   pero   por   razones   ya   comentadas   en   el   punto   “Especificación   del  sistema”,   se  ha  decidido   situarlas  en  el  pie  de  página.  Para  excluir  estas   secciones  del  menú  principal  es  necesario  modificar  la  plantilla  TPL  correspondiente.  

Para   modificar   el   pie   de   página   se   debe   editar   la   plantilla   TPL   de   la   extensión   “ezflow”  correspondiente.  

Para  intentar  no  modificar  en  lo  posible  el  código  estándar  del  sistema  eZ  Publish  se  ha  creado  una  extensión  de  diseño  que  se  expondrá  en  puntos  posteriores.  Separando  el  nuevo  diseño  del   resto   del   código   utilizando   un   extensión,   se   consigue   que   sea   más   sencillo   incorporar  nuevos  diseños,  editar  el  existente  o   incluso  desactivarlo  y  recuperar  el  diseño  de  eZ  Publish  por  defecto.  

Page 87: Proyecto!Final!deCarrera BCNLook$&Find

   

86    

El  siguiente  paso  ha  sido  el  de  crear  los  dos  elementos  más  importantes  del  sistema  BCN  Look  &  Find,  objeto  encontrado  y  objeto  perdido.  

4.4 Objeto  encontrado  y  objeto  perdido  

El   sistema   eZ   Publish   no   dispone   de   ninguna   clase   por   defecto   que   cumpla   los   requisitos  necesarios  para  crear  objetos  encontrados  y  objetos  perdidos,  por  lo  tanto  se  han  creado  dos  clases  nuevas,  “Lost  object”  y  “Found  object”,  con  los  atributos  necesarios,  utilizando  los  tipos  de  datos  que  el  sistema  suministra.  

La   clase   que   representa   la   estructura   de   objetos   encontrados   se   llama   “Found   object”   y  contiene  los  siguientes  atributos.  

• Categoría.  Para  crear  este  atributo  se  ha  utilizado  el  tipo  de  dato  “Relación  de  objeto”.  Este  tipo  de  dato  permite  crear  una  relación  con  un  conjunto  de  objetos  y  mostrarlos  utilizando   un   selector   desplegable.   Este   atributo   se   ha   definido   como   obligatorio   ya  que  en  la  especificación  del  sistema  se  ha  decidido  asignar  cada  objeto  a  una  categoría  para  facilitar  su  búsqueda.  

• Nombre.  Tipo  de  dato  “Línea  de  texto”.  Desarrollado  sobre  el  “input”  básico  de  HTML  “text”.  Este  atributo  se  ha  definido  como  obligatorio,  ya  que  en   la  especificación  del  sistema   se   ha   decidido   que   los   objetos   posean   un   título   para   su   identificación   en   el  sitio  web.  

• Descripción.   Tipo   de   dato   “Área   de   texto”.   Desarrollado   sobre   el   “input”   básico   de  HTML  “textarea”.  

• ¿Dónde   lo  has  encontrado?  Tipo  de  dato  “Dirección  GMap”.  Utiliza  la  API  de  Google  para  mostrar   un  mapa   sobre   el   que   se   puede   seleccionar   una   dirección   postal.   Este  atributo  se  ha  definido  como  obligatorio,  ya  que  en  la  especificación  del  sistema  se  ha  decidido  que  es  necesario  que  los  usuarios  añadan  una  dirección  aproximada  del  lugar  dónde   se   ha   encontrado   el   objeto,   para   que   su   propietario   pueda   identificarlo  más  fácilmente.    

• Descripción  de  la  dirección.  Tipo  de  dato  “Área  de  texto”.  • ¿Cuándo  lo  has  encontrado?  Tipo  de  dato  “Fecha”.  Muestra  tres  líneas  de  texto  sobre  

las   que   introducir   el   día,   mes   y   año.   Además   de   un   calendario   desarrollado   en  “javascript”  sobre  el  que  se  puede  seleccionar  una  fecha.  Se  ha  tenido  que  modificar  el  código  de  este  tipo  de  dato  para  establecer  un  límite  en  las  fechas  a  seleccionar  del  calendario,  ya  que  no  tiene  ningún  sentido  que  un  objeto  haya  sido  encontrado  en  una  fecha   futura.   El   atributo   “¿Cuándo   lo   has   encontrado?”   se   ha   definido   como  obligatorio,   ya   que   en   la   especificación   del   sistema   se   ha   decidido   que   es   necesario  que  el  usuario  añada  esta  fecha  de  manera  aproximada,  para  que  su  propietario  pueda  identificar  el  objeto  con  mayor  facilidad.  

• Fotografía.  Tipo  de  dato  “Imagen”.  Muestra  un  “input”  HTML  sobre  el  que  subir  una  imagen  con  unas  restricciones  definidas  en  la  configuración  del  sistema.  

• Pregunta  secreta.  Tipo  de  dato  “Área  de  texto”.  • Etiquetas.  Tipo  de  dato  “Palabras  clave”.  Muestra  una  línea  de  texto  sobre  la  que  se  

debe  introducir  palabras  separadas  por  comas.  

Page 88: Proyecto!Final!deCarrera BCNLook$&Find

   

87    

• Estado.   Tipo   de   dato   “Relación   de   objeto”.   Este   atributo   se   ha   definido   como  obligatorio,  con  la  relación  por  defecto  al  estado  “Perdido”  del  conjunto  de  estados  de  un  objeto  encontrado  de  los  que  se  hablará  en  puntos  posteriores.  Este  campo  no  es  seleccionable   por   el   usuario,   por   lo   tanto   es   necesario   modificar   la   plantilla   que  permite  crear  objetos  encontrados.  

• Identificador   el   posible   propietario.   Tipo   de   dato   “Número   entero”.   Implementado  sobre  el  “input”  básico  de  HTML  “text”,  con  algunas  restricciones.  Este  atributo  se  ha  creado  con   la   finalidad  de  almacenar  temporalmente  el   identificador  del  usuario  que  ha  marcado   el   objeto   como   de   su   propiedad.   Como   es   lógico   este   atributo   no   será  visible   ni   editable   por   los   usuarios,   por   lo   tanto   se   ha   modificado   la   plantilla   que  muestra   la   información   del   objeto   registrado   y   la   plantilla   que   permite   registrar  objetos  encontrados.  

• Identificador   del   propietario.   Tipo   de   dato   “Número   entero”.   Este   atributo   se   ha  incluido  con   la   finalidad  de  guardar  el   identificador  del  usuario  propietario  definitivo  del  objeto  encontrado.  Este  atributo  no  será  visible  ni  editable  por  los  usuarios,  por  lo  tanto  se  ha  modificado  la  plantilla  que  muestra  la  información  del  objeto  registrado  y  la  plantilla  que  permite  registrar  objetos  encontrados.  

La   clase   que   representa   la   estructura   de   cada   uno   de   los   objetos   perdidos   se   llama   “Lost  object”  y  está  formada  por  los  siguientes  atributos.  

• Categoría.  Igualmente  que  el  atributo  de  la  clase  que  representa  objetos  encontrados,  está   representado   por   el   tipo   de   dato   “Relación   de   objeto”   y   se   ha   definido   como  obligatorio.  

• Nombre.  Tipo  de  dato  “Línea  de  texto”.  • Descripción.  Tipo  de  dato  “Área  de  texto”.  • ¿Dónde  lo  has  visto  por  última  vez?  Representa  el  lugar  donde  el  usuario  ha  perdido  

el   objeto,   utilizando   el   tipo   de   dato   “Dirección   GMap”.   Este   atributo   se   ha   definido  como  obligatorio.  

• Descripción  de  la  dirección.  Tipo  de  dato  “Área  de  texto”.  • ¿Cuándo   lo   has   visto   por   última   vez?   Representa   la   fecha   en   la   que   el   usuario   ha  

perdido  el  objeto,  utilizando  el  tipo  de  dato  “Fecha”.  Este  atributo  se  ha  definido  como  obligatorio.  

• Recompensa.   Utiliza   el   tipo   de   dato   “Decimal”   que   está   implementado   sobre   el  “input”   básico  HTML   “text”,   con   las   restricciones   correspondientes   que  debe  poseer  un  número  decimal.  

• Fotografía.  Tipo  de  dato  “Imagen”.  • Etiquetas.  Tipo  de  dato  “Línea  de  texto”.  • Estado.   Del  mismo  modo   que   el   atributo   estado   de   la   clase   que   representa   objetos  

encontrados,  este  campo  utiliza  el  tipo  de  dato  “Relación  de  objeto”  y  está  relacionado  por  defecto   con  el   estado   “Perdido”  del   conjunto  de  estados  de  objeto  perdido.   Los  usuarios   no   editar   este   atributo,   por   lo   tanto   se   ha   editado   la   plantilla  correspondiente.  

Page 89: Proyecto!Final!deCarrera BCNLook$&Find

   

88    

• Identificador  del  posible  “finder”.  Este  atributo  definido  con  el  tipo  de  dato  “Número  entero”   se  utiliza  para  almacenar   temporalmente  el   identificador  del  usuario  que  ha  marcado  el  objeto  como  encontrado.  

• Identificador  del  “finder”.  Este  atributo  definido  con  el  tipo  de  dato  “Número  entero”  se   utiliza   para   guardar   el   identificador   del   usuario   que   finalmente   ha   encontrado   el  objeto.  

El  sistema  BCN  Look  &  Find  ya  dispone  de  dos  nuevas  clases  que  definen  la  estructura  de  los  objetos   encontrados   y   perdidos   que   los   usuarios   registran.   El   siguiente   paso   es   crear   una  ubicación  donde  almacenarlos.  Inicialmente  se  había  pensado  la  estructura  del  sitio  web  para  que   existieran   dos   secciones   diferenciadas,   para   visualizar,   añadir   y   almacenar   objetos  encontrados  y  perdidos,  accesibles  desde  el  menú  principal.  En  su  momento  se  habían  creado  estas   dos   secciones   utilizando   la   clase   “Front   page”.   Esta   clase,   (utilizando   para   la   página  principal   por   defecto),   dispone   de   diferentes   opciones   para   estructurar   el   contenido   de   la  sección.  La  idea  inicial  era  mostrar  en  una  parte  central  grande  una  lista  de  objetos  registrados  y  en  el  pequeño  lateral  derecho  la  lista  de  categorías  de  objetos,  por  esta  razón  la  clase  “Front  page”  era   ideal  para  crear  esta  sección.  Más  tarde  se  decidió  prescindir  de  estas  secciones  y  que  los  objetos  registrados  se  mostraran  en  su  totalidad  en  la  página  principal,  para  no  rehacer  los   contenedores   de   objetos   se   decidió   conservar   estas   secciones   exclusivamente   como  almacén  de  objetos.  

Una   vez   decidida   la   ubicación   de   los   objetos   encontrados   y   perdidos,   hay   que   permitir   y  facilitar  crear  estos  tipos  de  contenido  a  los  usuarios  registrados,  (“Members”  en  el  sistema  eZ  Publish).  

Para   ello   se   han   editado   los   permisos   de   usuario   desde   la   página   de   administración   del  sistema.  El  usuario  visitante  (“Anonymous”  en  eZ  Publish),  deberá  poder  visualizar  los  objetos  registrados  en  el   sistema  y  el  usuario   registrado  deberá  poder   crear  este   tipo  de   contenido.  Funcionalidades  como  editar  y  borrar   son   tienen  un   tratamiento  especial,   ya  que  un  usuario  registrado  solo  puede  editar  y  borrar  contenidos  que  ha  creado  personalmente,  exceptuando  los  casos  de  cambio  de  estado  provocados  por  los  botones  “Es  mío”  y  “Lo  he  encontrado”.  

Agregar  permisos  a   los  usuarios  no  sirve  de  nada  si  no  se   implementa  una   interfaz  para  que  puedan  acceder  al  formulario  de  creación  de  contenido.  Así  que  se  ha  editado  la  plantilla  TPL  que  muestra  el  menú  principal,    anteriormente  mencionada,  para  incorporar  un  botón  “Añadir  objeto”  que  despliegue  dos  botones  más  “Objeto  perdido”  y  “Objeto  encontrado”.  

Estos   dos   botones   llaman   a   la   acción   que   muestra   los   formularios   para   añadir   el   tipo   de  contenido   correspondiente.   Como   se   ha   comentado   anteriormente,   para   no  modificar   en   lo  posible  el  código  estándar  del  sistema  eZ  Publish  se  ha  creado  una  extensión  de  diseño.  

La  plantilla  que  muestra  el  formulario  para  registrar  o  editar  objetos  encontrados  y  perdidos  es  una  plantilla  genérica  para  añadir  contenido  de  la  extensión  “ezwebin”.  

Puesto  que  los  formularios  para  añadir  objetos  tienen  peculiaridades  específicas  no  se  puede  utilizar  una  plantilla  genérica,  así  que  se  ha  creado  una  plantilla  específica  para  cada  tipo  de  

Page 90: Proyecto!Final!deCarrera BCNLook$&Find

   

89    

objeto,   sobrescribiendo   la   genérica.   Esta   acción   crea   plantillas   el   directorio   “override”   del  directorio  de  diseño  especificado.  En  este  caso  se  ha  utilizado  el  directorio  de  diseño  “ezflow”  ya  que  es  el  que  figuraba  por  defecto.  

Estas   nuevas   plantillas   se   han   creado   con   el   código   de   la   plantilla   original   por   defecto,  posteriormente  se  editarán  utilizando  la  nueva  extensión  de  diseño.  

Lo  mismo  ocurre  con  las  plantillas  que  muestran  la  información  de  los  objetos  encontrados  y  perdidos  registrados.  Se  ha  sobrescrito  del  mismo  modo  creando  dos  nuevas  específicas  para  cada  tipo  de  objeto.  

4.5 Categorías  de  objeto  

Como  se  ha  especificado  anteriormente  en  la  Sección  3,   los  objetos  se  dividen  en  categorías.  Estas  categorías  se  utilizarán  en  diferentes  partes  del  sistema  y  de  diferentes  maneras,  en   la  página  principal  para  filtrar  los  objetos  a  mostrar,  en  la  información  de  objetos  que  se  muestra  en   diferentes   lugares   del   sitio   web,   etc.   Como   se   ha   expuesto   anteriormente,   la   clase   que  define  a  su  vez  la  estructura  de  objetos  encontrados  y  perdidos,  contiene  un  atributo  de  tipo  “Relación  de  objeto”,  que  relaciona   los  objetos  creados  con  el  objeto  categoría  seleccionado  por  el  usuario.  

Puesto   que   las   categorías   son   elementos   complejos   que   disponen   de   varios   atributos   y   son  utilizadas  en  diferentes  procesos  y  mostradas  en  diferentes  ubicaciones,  se  ha  decidido  crear  una   clase   específica   para   ellas.   La   clase   que   define   la   estructura   de   una   categoría   se   llama  “Object  category”  y  se  compone  de  los  siguientes  atributos.  

• Nombre.  Nombre  que  identifica  la  categoría.  Tipo  de  dato  “Línea  de  texto”.  • Descripción.  Descripción  de  la  categoría.  Tipo  de  dato  “Área  de  texto”.  • Imagen.  Imagen  representativa  de  la  categoría.  Tipo  de  dato  “Imagen”.  

Para  ubicar  las  categorías  se  ha  creado  una  sección  “Administración”  a  la  que  solo  el  usuario  con   rol   administrador   acceder.   Dentro   de   esta   sección   encontramos   dos   sub-­‐secciones  “Categorías”  y  “Estados  de  objeto”.  De  esta  manera  se  mantiene  un  orden  para  ubicar  todos  los  elementos  no  públicos,  necesarios  para  el  desarrollo  del  sistema  BCN  Look  &  Find.  

A   partir   del   momento   en   el   que   se   crean   las   categorías,   sus   datos   pueden   ser   consultados  desde  cualquier  plantilla  y  pueden  ser  relacionadas  desde  cualquier  otro  tipo  de  contenido.  

4.6 Estados  de  objeto  

Del  mismo  modo  que  las  categorías  de  objeto,  se  han  creado  los  estados  de  objeto  encontrado  y  perdido,  especificados  en  la  Sección  3.  Teniendo  en  cuenta  que  estos  estados  tienen  que  ser  relacionados   con   objetos   encontrados   y   perdidos   registrados   en   el   sistema   y   que   su  información   será   consultada  en  diferentes  puntos  del   sistema,   se  ha  decidido   crearlos   como  objetos.  Para  ello  es  necesario  crear  una  nueva  clase  que  defina  la  estructura  de  estos  estados.  Esta  clase  se  llama  “Object  status”  y  está  formada  por  los  siguientes  atributos.  

Page 91: Proyecto!Final!deCarrera BCNLook$&Find

   

90    

• Nombre.   Nombre   que   identifica   el   estado.   Se   han   utilizado   nombres   cortos  representativos   “Perdido”,   “Pendiente”   y   “Devuelto”.   Se   utilizan   tanto   para   los   dos  tipos  de  objetos.  Tipo  de  dato  “Línea  de  texto”.  Este  atributo  es  obligatorio.  

• Mensaje.  Mensaje  que   se  muestra  al  usuario  en  el   sitio  web.  Tipo  de  dato   “Área  de  texto”.  Este  atributo  es  obligatorio.  

• Descripción.  Descripción  extra  del  estado.  Está   información  no  se  muestra  en  ningún  lugar  público.  Tipo  de  dato  “Área  de  texto”.  

Puesto  que  los  estados  de  objeto  también  son  contenidos  creados  de  la  clase  “Object  status”,  es  necesario  ubicarlos  en  algún  lugar  del  sistema.  De  la  misma  manera  que  las  categorías  se  ha  decidido   almacenarlos   en   la   sección   “Administración”,   a   la   que   solo   los   usuarios  administradores  puede  acceder.   Para  utilizar  o  mostrar   estos   estados,   serán   cargados  desde  esta  ubicación.  Los  estados  de  objeto  se  almacenarán  en  la  sub-­‐sección  “Estados  de  objeto”,  de   la   sección   “Administración”   y   dentro   de   ésta   se   dividirán   entre   otras   dos   sub-­‐secciones  “Estados   de   objeto   encontrado”   y   “Estados   de   objeto   perdido”,   de   esta   manera   es   más  sencillo  obtener  la  información  de  los  estados,  según  el  tipo  de  objeto.  

Por   último   se   han   creado   tres   estados   de   objeto   dentro   de   la   sección   “Estados   de   objeto  encontrado”  y  tres  más  dentro  de  la  sección  “Estados  de  objeto  perdido”.  Tanto  los  estados  de   objeto   perdido   como   los   de   objeto   encontrado   se   identifican   con   el   mismo   nombre,  “Perdido”,  “Pendiente”,  “Devuelto”,  de  esta  manera  su  uso  interno  es  más  genérico  y  solo  es  necesario   especificar   el   directorio   donde   se   encuentra,   para   saber   a   que   tipo   de   objeto   se  refieren.   Por   supuesto   la   información   que   se  muestra   a   los   usuarios   varía   según   el   tipo   de  objeto  y  el  estado  siguiendo  las  especificaciones  de  la  Sección  3.3.2.  

A  partir   de  este  momento   los  datos  de   los   estados  de  objeto  podrán   ser   consultados  desde  cualquier  parte  del  sistema  y  podrán  ser  relacionados  con  cualquier  otro  objeto.  

4.7 Usuarios  

Una  vez  comentado  como  se  ha  construido  la  estructura  de  las  secciones  básicas  del  sitio  web,  los  objetos  encontrados  y  perdidos,  las  categorías  y  los  estados  de  objeto,  es  el  momento  de  definir  la  estructura  de  otro  elemento  muy  importante  del  sistema,  los  usuarios.  

Como  se  ha  especificado  anteriormente  en  la  Sección  3.2,  el  sistema  BCN  Look  &  Find  requiere  de   cuatro   tipos   de   usuario,   visitante,   registrado,   centro   y   administrador.   Como   ya   se   ha  comentado  anteriormente,  eZ  Publish  considera  un  usuario  como  un  tipo  de  contenido  con  la  peculiaridad   que   este   tipo   de   contenido   de   la   clase   “User”,   dispone   de   un   atributo   llamado  “cuenta   de   usuario”.   Este   atributo   se   compone   del   identificador   numérico   del   usuario,   el  nombre,   la   dirección   de   correo   electrónico   y   la   contraseña.   Por   defecto   eZ   Publish   dispone  únicamente  de  una  clase  llamada  “User”  que  representa  todos  los  tipos  de  usuario  del  sistema  (incluso  el  usuario   visitante).   Para  diferenciar  el   tipo  de  usuario  utiliza  un  elemento   llamado  “User  group”.  Todos  los  usuarios  creados  como  contenido  de  la  clase  “User”,  hacen  referencia  a  un  “User  group”  y  de  esta  manera  reciben  un  trato  y  unas  características  específicas  del  tipo  de  usuario.  Los  grupos  de  usuario  del  sistema  eZ  Publish  son  los  siguientes.  

Page 92: Proyecto!Final!deCarrera BCNLook$&Find

   

91    

• Anonymous.   Los   usuarios   pertenecientes   a   este   grupo   representan   los   usuarios  visitantes  (anónimos)  del  sistema.  

• Members.   Los   usuarios   pertenecientes   a   este   grupo   representan   los   usuarios  registrados  (miembros)  del  sistema.  

• Administrators.   Los   usuarios   pertenecientes   a   este   grupo   representan   los   usuarios  administradores  del  sistema.  

A   continuación   se   explica   como   se   ha   adaptado   el   sistema   de   usuarios   de   eZ   Publish   a   las  necesidades  del  sistema  BCN  Look  &  Find.  

Para  representar  el  usuario  visitante  y  administrador,  se  ha  utilizado  la  estructura  por  defecto  de  eZ  Publish.  

Para   representar   el   usuario   de   tipo   registrado,   también   se   ha   utilizado   la   estructura   por  defecto  de  eZ  Publish,  por  lo  tanto  el  usuario  registrado,  de  manera  interna  será  representado  por  el  grupo  de  usuarios  “Members”.  

Como   es   evidente   no   hay   manera   de   representar   el   usuario   centro   con   la   estructura   por  defecto   de   eZ   Publish,   por   lo   tanto   ha   sido   necesario   ampliarla.   Para   ello   se   ha   creado   un  nuevo  grupo  de  usuarios  llamado  “Centers”  donde  se  ubicarán  los  usuarios  de  tipo  centro.  Las  diferencias   entre   casos   de   uso   especificados   en   la   Sección   3.4,   de   usuarios   registrados   y  usuarios  de   tipo   centro  quedan   resueltas     con   la   creación  de  este  nuevo  grupo  de  usuarios,  puesto  que  los  roles  y   los  permisos  se  aplican  sobre  los  grupos  de  usuarios.  El  problema  que  no  queda  resuelto  es  el  de  las  diferencias  en  cuanto  a  datos  personales  del  usuario.  Un  usuario  de   tipo   centro   tiene   un   perfil   distinto   que   el   de   un   usuario   registrado,   por   lo   tanto   la   clase  “User”   que  utiliza   el   sistema  eZ  Publish  por   defecto  para   representar   todos   los   usuarios,   no  satisface  las  necesidades  del  sistema  BCN  Look  &  Find.  Para  resolver  este  inconveniente  se  ha  decidido   crear   una   nueva   clase   independiente   para   representar   los   usuarios   de   tipo   centro.  Esta  nueva  clase  se  llama  “Center”  y  dispone  de  los  siguientes  atributos.  

• Nombre   del   centro.   Tipo  de  dato   línea  de   texto.  Este  nombre   representa  el  nombre  del  centro  como  TMB,  Biblioteca  Rector  Gabriel  Ferraté,  etc.  Se  ha  limitado  el  número  de  caracteres  a  cuarenta  ya  que  este  nombre  se  muestra  en  el  selector  de  centros  de  la   página   principal.   Si   se   permite   añadir   nombres   demasiado   largos   podrían  desestructurar  el  diseño  de  la  página.  Este  campo  se  ha  definido  como  obligatorio,  ya  que   tal   y   como   se   ha   especificado   anteriormente   los   centros   necesitan  de  un   título,  para  que  el  resto  de  usuarios  sepan  a  qué  centro  se  refiere.  

• Nombre  del  responsable.  Tipo  de  dato  línea  de  texto.  Representa  el  nombre  de  pila  de  la  persona  física  que  registra  el  centro.  Este  campo  se  ha  definido  como  obligatorio,  ya  que  tal  y  como  se  ha  especificado  anteriormente  los  centros  deben  tener  una  persona  a  su  cargo  que  se  responsabilice  del  registro.  

• Apellido   del   responsable.   Tipo   de   dato   línea   de   texto.   Representa   el   apellido   de   la  persona  física  que  registra  el  centro.  

• Cuenta  de  usuario.  Como  ya  se  ha  comentando  la  diferencia  principal  entre  un  tipo  de  contenido  que  representa  un  usuario  y  el   resto  de  contenidos,  es  que  éste  posee  un  tipo  de  dato  cuenta  de  usuario.  Este  tipo  de  dato  se  compone  de  nombre  de  usuario,  

Page 93: Proyecto!Final!deCarrera BCNLook$&Find

   

92    

contraseña,   “repetir   contraseña”   y   dirección   de   correo   electrónico.   Evidentemente  este  atributo  se  ha  definido  como  obligatorio,  ya  que  a  parte  de  ser  un  requerimiento  del  sistema  eZ  Publish,  es   la  forma  de   identificar  al  usuario  centro  en  el  sistema  BCN  Look  &  Find.  

• He   leído  y  acepto   las   condiciones  de  uso.  Tipo  de  dato  “Checkbox”.  El  usuario  debe  aceptar   las   condiciones   de   uso   para   poder   finalizar   el   registro.   Este   atributo   solo  incluye  un  marcador,  pero  en  la  plantilla  que  muestra  el  formulario  se  ha  añadido  un  enlace  que  muestra  una  ventana  modal  con  las  condiciones  de  uso.  

Estos  son  los  atributos  que  se  muestran  para  crear  una  cuenta  de  usuario  de  tipo  centro,  pero  dispone   de   otros   campos   opcionales   que   el   usuario   puede   añadir   o   editar   en   cualquier  momento.  A  continuación  se  muestran  los  atributos  extra  de  la  clase  “Centro”.  

• ¿Quieres   que   la   dirección   de   correo   electrónico   sea   pública?   Tipo   de   dato  “Checkbox”.  Por  defecto  nunca  se  mostrará  en  el  perfil  público  del  usuario  la  dirección  de   correo   electrónico   de   éste,   pero   puede   modificarse   en   cualquier   momento  marcando   esta   casilla.   Esta   dirección   de   correo   electrónico   solo   será   desvelada   sin  tener  en  cuenta  esta  casilla  en  el  momento  en  que  el  usuario  marca  un  objeto  pulsado  “Lo  he  encontrado”,  ya  que  se  envía  un  correo  electrónico  al  usuario  que  ha  registrado  el  objeto,  con  dicha  información.  A  pesar  de  ello  el  usuario  será  informado  justo  antes  de  enviar  el  mensaje  de  correo  electrónico.  

• Información  del  centro.  Tipo  de  dato  “Área  de  texto”.  Este  atributo  permite  al  usuario  introducir  una  descripción  del  centro,  de  cara  al  resto  de  usuarios.  

• Fotografía.  Tipo  de  dato  “Imagen”.  El  centro  podrá  añadir  una  fotografía,  para  que  el  resto  de  usuarios  la  vean.  

• Dirección  postal.  Tipo  de  dato  “Dirección  GMap”.  El  usuario  podrá  indicar  la  dirección  postal  en  la  que  se  encuentra  el  centro  al  que  representa.  

• ¿Quieres  que  la  dirección  postal  del  centro  sea  pública?  Tipo  de  dato  “Checkbox”.  Por  defecto  no  se  muestra  la  dirección  postal  del  centro  al  resto  de  usuarios,  pero  puede  editarse  marcando  este  campo.  

• Dirección  web.  Tipo  de  dato  “URL”.  El  usuario  responsable  del  centro  registrado  podrá  añadir  una  dirección  al  sitio  web  del  centro  que  se  mostrará  al  resto  de  usuarios.  

• Teléfono   de   contacto.   Tipo  de  dato   “Línea  de   texto”.   Podrá   añadirse  un  número  de  teléfono  para  contactar  con  el  centro  registrado.  

• ¿Quieres   que   el   teléfono   de   contacto   sea   público?   Tipo   de   dato   “Checkbox”.   Este  campo  define  si  el  usuario  quiere  que  el  teléfono  de  contacto  del  centro  sea  visible  al  resto  de  usuarios.  

• Objetos   devueltos.  Tipo  de  dato  “Número  entero”.  Como  se  ha  comentado  en  otras  secciones,   se   ha   creado   una   sección   en   la   que   se   muestra   una   lista   con   los   diez  usuarios  que  más  objetos  han  devuelto  a  sus  propietarios,  para  facilitar  este  recuento  se  ha  añadido  este  campo  que  incrementa  cada  que  el  usuario  devuelve  un  objeto.  Los  centros  están  excluidos  de  este  “top  ten”,  ya  que  se  supone  que  van  a  ser  los  usuarios  que  más   objetos   devuelvan,   pero   no   está   de  más   incluir   el   campo   por   si   necesitara  para  otros  usos.  

Page 94: Proyecto!Final!deCarrera BCNLook$&Find

   

93    

Como   ya   se   ha   comentado   la   clase   “User”   estándar   del   sistema  eZ   Publish   se   utiliza   para   el  resto  de  tipos  de  usuario  (visitante,  registrado  y  administrador).  En  el  caso  de  los  usuarios  de  tipo  visitante,  los  datos  que  se  exponen  a  continuación  son  valores  por  defecto  o  nulos  que  el  sistema  eZ  Publish  introduce  automáticamente.  

• Nombre.  Tipo  de  dato  “Línea  de  texto”.  Este  atributo  representa  el  nombre  de  pila  del  usuario.  

• Apellido.  Tipo  de  dato  “Línea  de  texto”.  Representa  el  apellido  del  usuario.  • Cuenta   de   usuario.   Como   ya   se   ha   comentado   anteriormente   este   tipo   de   dato  

contiene  “nombre  de  usuario”,   “contraseña”,   “repetir   la   contraseña”  y   “dirección  de  correo  electrónico”.  Es  imprescindible  para  identificar  esta  clase  como  usuario.  

• Fotografía.  Tipo  de  dato  “Imagen”.  Permite  al  usuario  añadir  una  fotografía.  • He   leído   y   acepto   las   condiciones   de   uso.   Tipo   de   dato   “Checkbox”.   Como   en   el  

usuario   centro,   es   necesario   marcar   esta   casilla   para   poder   finalizar   el   registro   del  usuario.  

Para   cumplir   con   los   requerimientos   del   sistema  BCN   Look  &   Find,   ha   sido   necesario   añadir  algunos  atributos,  de  la  misma  manera  que  para  el  usuario  centro.  

• ¿Quieres   que   tu   nombre   y   apellido   sean   públicos?   Tipo   de   dato   “Checkbox”.   Por  defecto  el  nombre  y  el  apellido  del  usuario  no  se  mostrarán  en  el  perfil  público  al  resto  de  usuarios,  esto  es  del  todo  configurable  marcando  está  opción.  

• ¿Quieres   que   la   dirección   de   correo   electrónico   sea   pública?   Tipo   de   dato  “Checkbox”.   De   la   misma   manera   que   el   nombre   y   el   apellido   del   usuario,   si   esta  casilla  no  se  marca,  la  dirección  de  correo  electrónico  del  usuario  no  se  mostrará  en  su  perfil   público.   Únicamente   se   desvelará   vía   mensaje   de   correo   electrónico   a   otro  usuario,  a  pesar  del  contenido  de  este  campo,  en  el  momento  que  el  usuario  marque  un  objeto  pulsando  los  botones  “Es  mio”  o  “Lo  he  encontrado”,  por  las  razones  antes  mencionadas  en  el  usuario  de  tipo  centro.  

• Dirección  postal.  Tipo  de  dato  “Dirección  GMap”.  El  usuario  podrá  indicar  la  dirección  postal  de  su  domicilio  personal.  

• ¿Quieres  que  la  dirección  postal  del  centro  sea  pública?  Tipo  de  dato  “Checkbox”.  Por  defecto  no  se  muestra  la  dirección  postal  del  domicilio  del  usuario  al  resto  de  usuarios,  pero  puede  editarse  marcando  este  campo.  

• Fecha  de  nacimiento.  Tipo  de  dato  “Fecha”.  El  usuario  podrá  optar  por  añadir  su  fecha  de  nacimiento.  

• ¿Quieres   que   tu   fecha   de   nacimiento   sea   pública?   Tipo   de   dato   “Checkbox”.   Este  campo  define  si  el  usuario  quiere  que  su  fecha  de  nacimiento  sea  pública.  

• Objetos   devueltos.  Tipo  de  dato  “Número  entero”.  Como  se  ha  comentado  en  otras  secciones,   se   ha   creado   una   sección   en   la   que   se   muestra   una   lista   con   los   diez  usuarios  que  más  objetos  han  devuelto  a  sus  propietarios,  para  facilitar  este  recuento  se   ha   añadido   este   campo   que   se   incrementa   cada   vez   que   el   usuario   devuelve   un  objeto.  

Page 95: Proyecto!Final!deCarrera BCNLook$&Find

   

94    

En   el  momento   que   un   usuario   de   tipo   visitante   pulsa   el   enlace   para   registrarse,   eZ   Publish  muestra   por   defecto   el   formulario   de   registro   para   usuarios   de   tipo   registrado.   Esto   es   un  problema  teniendo  en  cuenta  que  ahora  también  se  dispone  del  tipo  de  usuario  centro.  Para  que  el  sistema  muestre  los  formularios  correspondientes  dependiendo  del  tipo  de  cuenta  que  el  usuario  visitante  desea  registrar  ha  sido  necesario  editar  el  código  PHP  que  registra  usuarios  y  las  plantillas  TPL  relacionadas  con  el  registro,  identificación,  perfil  de  usuario,  etc.  

El   enlace   de   la   cabecera   del   sitio   web   “crear   cuenta”,   por   defecto   re-­‐direccionaba  directamente  al  formulario  de  registro.  Puesto  que  se  debe  seleccionar  previamente  el  tipo  de  usuario  a  registrar,  se  ha  modificado  este  enlace  para  que  muestre  una  pantalla  previa  donde  se  expone  la  información  necesaria  y  un  enlace  a  los  dos  tipos  de  formulario  posibles.  

Para   ello   se   ha   creado   un   nuevo   contenido   titulado   “Regístrate”.   Una   vez   creado   se   ha  sobrescrito  la  plantilla  por  defecto.  

A  continuación  se  ha  editado   la  plantilla  que  muestra  el   formulario  para  registrar  un  usuario  estándar.  

A  parte  de  modificar  el  diseño  de  esta  plantilla  se  hace  un  control  previo  del  tipo  de  usuario  seleccionado   para   mostrar   el   formulario   correspondiente.   Como   se   ha   comentado  anteriormente   en   el   formulario   de   registro   no   se   muestran   todos   los   campos   del   perfil   de  usuario,  únicamente  el  nombre,  apellido,  nombre  de  usuario,  dirección  de  correo  electrónico,  contraseña  y  el  “checkbox”  para  aceptar  las  condiciones  de  uso.  

Para   que   el   sistema   permita   registrar   el   nuevo   tipo   de   usuario   centro   ha   sido   necesario  modificar  el  código  PHP  por  defecto.  

“…/kernel/user/register.php”.  

Este  “script”,  entre  otras  cosas,  selecciona  el   identificador  del  grupo  de  usuarios,  “Members”  por   defecto   y   el   identificador   de   la   clase   que   define   la   estructura   del   usuario,   “User”   por  defecto,  del  fichero  de  configuración  y  a  continuación  muestra  la  plantilla  con  el  formulario  de  registro  correspondiente.  Lo  que  se  ha  hecho  ha  sido  añadir  el   identificador  del  nuevo  grupo  de   usuarios   “Centers”   y   de   la   nueva   clase   “Center”   en   el   fichero   de   configuración.   Ahora  cuando   se   hace   la   llamada   a   este   “script”   se   le   pasa   por   parámetro   el   tipo   de   usuario   a  registrar,  se  comprueba  qué  tipo  de  usuario  es  y  se  muestra  el  formulario  correspondiente,  de  la   clase   correspondiente,   finalmente   se   añade   el   contenido   al   grupo   de   usuarios  correspondiente.  

Una  vez  registrado  el  usuario  se  le  debe  permitir  editar  su  perfil.  El  sistema  eZ  Publish  muestra  un  enlace  en  la  cabecera  del  sitio  web  “my  profile”  que  redirecciona  al  perfil  de  usuario.  

En   el   caso   del   sistema   BCN   Look   &   Find,   a   parte   de   modificar   el   nombre   del   enlace   a   “Mi  perfil”,   se   ha   decidido   también   ubicar   el   acceso   a   la   cuenta   de   usuario   en   la   sección  “Comunidad”  de  la  que  se  hablará  más  adelante.  

Page 96: Proyecto!Final!deCarrera BCNLook$&Find

   

95    

4.8 Desarrollo  de  la  página  principal  

Por  defecto  eZ  Publish  dispone  de  un  tipo  de  contenido    llamado  “Front  page”  sobre  el  que  se  ha   creado   la   página   principal.   Esta   página   principal   no   se   puede   eliminar,   pero   pueden   ser  modificados  algunos  de  sus  elementos.  

El  paquete  instalado  de  eZ  Publish  llamado  eZ  Flow,  dispone  de  la  posibilidad  de  modificar  la  estructura  y  áreas  de  los  contenidos  creados  sobre  la  estructura  de  la  clase  “Front  page”.  Por  ejemplo  en  el  caso  de  la  página  principal  de  BCN  Look  &  Find  se  ha  decidido  que  se  disponga  de   un   área   en   la   parte   izquierda  mayor   y   un   área  menor   en   la   parte   derecha.   Este   tipo   de  disposición  es  denominado  “2  zones  layout  1”.  Refiriéndose  a  que  se  compone  de  dos  zonas  la  primera   de   las   cuales   es   la   principal   y   por   lo   tanto   la   mayor.   Es   importante   entender   este  sistema  para  poder  encontrar  con  facilidad   la  plantilla  que  se  está  utilizando  para  mostrar  el  contenido  de  las  secciones  que  utilizan  la  clase  “Front  page”.  

El  sistema  permite  añadir  bloques  por  defecto  ya  desarrollados.  Como  por  ejemplo  la  nube  de  etiquetas  que  se  ha  añadido  en   la  zona  de   la  derecha  de   la  página  principal.  Para  mostrar   la  lista  de  objetos  de  la  zona  izquierda  en  un  inicio  se  intentó  utilizar  el  bloque  que  muestra  todo  el  contenido  de  un  tipo  concreto.  Su  funcionamiento  no  era  el  esperado  y  requería  de  editar  mucho  código,  así  que  se  ha  decidido  crearlo  desde  cero  editando  la  plantilla  correspondiente  y  creando  nuevas.  En  el  caso  de  la  lista  de  categorías  y  otros  elementos  se  ha  seguido  el  mismo  proceso.  

Otro  elemento  que  puede  generarse  automáticamente  es  el  mapa  que  muestra  la  ubicación  de  los  objetos  registrados.  El  sistema  eZ  Publish  permite  añadir  este  tipo  de  bloque,  simplemente  seleccionando  la  clase  o  las  clases  a  las  que  pertenecen  los  tipos  de  contenido  que  se  quieren  mostrar   y   cuál   es   su   ubicación.   A   pesar   de   ello   su   funcionalidad   no   se   ajusta   a   los  requerimientos  del  sistema  BCN  Look  &  Find,  ya  que,  entre  otros  motivos  no  permite  mostrar  ubicaciones  de  diferentes  tipos  de  objeto  de  manera  independiente,  el  diseño  no  se  adecua  al  requerido  en  esta  sección  y  se  hace  casi  imposible  referenciar  las  marcas  en  el  mapa,  con  los  objetos   mostrados   en   la   lista.   Finalmente   ha   sido   más   sencillo   buscar   su   código   en   las  extensiones   de   eZ   Publish,   copiarlo   en   la   nueva   extensión   de   diseño   y   editarlo   para   que  complemente  la  lista  de  objetos  y  se  adapte  a  las  necesidades  requeridas.  

A   continuación   se   explica   como   se   ha   llevado   a   cabo   este   desarrollo,   incluyendo   partes   de  código.  

Cuando   se   incluye   el   bloque   por   defecto,   éste   utiliza   la   plantilla   ubicada   en   la   extensión  “ezmaplocation”.  

Lo  primero  que  se  hace  en  esta  plantilla  es  cargar  la  librería  de  JavaScript  de  Google  necesaria.  

Page 97: Proyecto!Final!deCarrera BCNLook$&Find

   

96    

 

En   el   nuevo   bloque   se   ha   desarrollado,   se   incluye   en   la   plantilla   “objects_list.tpl”,   donde   se  construye  la  lista  de  objetos  de  la  página  principal.  

El  siguiente  paso  es  inicializar  cada  uno  de  los  marcadores  que  contendrá  el  mapa.  Para  ello  se  ha  reaprovechado  la  carga  de  los  objetos  de  la  lista,  de  esta  manera  también  se  fuerza  que  los  objetos  mostrados   en   el  mapa   sean   los  mismos   que   los  mostrados   en   la   lista,   teniendo   en  cuenta  los  filtros  de  búsqueda  seleccionados.  

 

Como  puede  verse  se  utilizan  los  valores  del  atributo  “address”  de  cada  uno  de  los  objetos.  

Cabe  recordar  que  una  vez  obtenida  la  información  de  cada  uno  de  los  objetos,  se  manda  a  la  plantilla  “object.tpl”  que  tiene  como  objetivo  construir  el  objeto.  Para  que  el  mapa  reconozca  a  qué  objeto  pertenece  cada  marcador,  es  necesario  incluir  el  valor  de  $o_Gmap.id.  Este  valor  servirá  para  construir  el  identificador  de  cada  uno  de  los  objetos.  

El  último  paso  es  el  de  dibujar  el  mapa.  Para  ello  simplemente  se  debe  incluirse  una  etiqueta  <div>   con   el   identificador   del   mapa   inicializado.   La   librería   de   Google   ya   se   encarga   de   lo  demás.  

<script  

src=http://maps.google.com/maps?file=api&amp;key={ezini(‘SiteSettings’,  ‘GMapsKey’)}  

type=”text/javascript”>  

</script>  

<script  type=”text/javascript”>  

{foreach  $st_objects  as  $o_Object}  

data{$o_Gmap.id}.push(  

{ldelim}  

point:  new  GLatLng({$o_Object.data_map[‘address’].content.latitude},  {$o_Object.data_map[‘address’].content.logitude}),  

address:  ‘  

<br>{$o_Object.data_map[‘address’].content.address}  

<br><b>{$o_Object.data_map.name.content}</b>’  

{rdelim});  

{/foreach}  

eZFLGMapAddListener(window,  ‘load’,  function()  

{ldelim}  eZFLGMapView(‘{$o_Gmap.id}’,  data{$o_Gmap.id})  

{rdelim},  false);  

</script>  

Page 98: Proyecto!Final!deCarrera BCNLook$&Find

   

97    

 

4.9 Desarrollo  de  la  sección  Comunidad  

Como   se   ha   comentado   anteriormente   en   la   Sección   3.9.6,   entre   otras,   comunidad   es   una  sección   donde   el   usuario   podrá   acceder   a   un   resumen   de   sus   aportaciones   (objetos  registrados,  objetos  devueltos,  comentarios,  etc.)  y  un  resumen  de  aportaciones  del  resto  de  usuarios.  Además  cabe  recordar  que  está  sección  disponía  de  subsecciones  para  acceder  a   la  información  completa  de  estos  tipos,  al  perfil  del  usuario  y  a  un  “top  10”  con  una  lista  de  los  diez  usuarios  que  más  objetos  han  encontrado  y  devuelto  a  sus  propietarios.  

Dada  la  estructura  y  posicionamiento  de  los  elementos  de  la  sección  “Comunidad”  se  ha  escogido  la  clase  “Front  page”  para  crear  este  tipo  de  contenido  y  sus  sub-­‐secciones.  

El  primer  paso  ha  sido  crear  un  nuevo  contenido  de  tipo  “Front  page”  con  título  “Comunidad”  y  añadiéndole   la  descripción  correspondiente.  Tal  y  como  se  muestra  en   la  especificación  de  las  plantillas,   esta   sección  y   sus   sub-­‐secciones   se   componen  de  dos  áreas,  una  pequeña  a   la  izquierda   y   otra   grande,   la   central,   a   la   derecha.   El   sistema  eZ   Publish   permite   escoger   esta  disposición,  que  denomina  “2  zones  layout  2”.  Pretende  indicar  que  se  compone  de  dos  zonas  y  que  la  segunda  es  la  principal  y  por  lo  tanto  la  mayor.  

De  la  misma  manera  que  en  la  página  principal  se  ha  añadido  el  elemento  automático  nube  de  etiquetas   en   el   bloque   de   la   izquierda.   El   resto   de   componentes   se   han   tenido   que   incluir  modificando  la  correspondiente  plantilla  y  creando  nuevas.  

Una  vez  creada  la  sección  comunidad  se  ha  creado  un  contenido  de  tipo  “Front  page”  por  cada  sub-­‐sección:   “Mi   cuenta”,   “Mis   aportaciones”,   “Aportaciones   de   la   comunidad”   y   “Top   10”.  Cada  una  con  su   título  y  descripción  correspondiente.  El   resto  de  elementos  se  han  añadido  creando  nuevas  plantillas,  que  se  expondrán  más  adelante.  

4.10 Desarrollo  del  menú,  cabecera  y  pie  de  página  

Como   ya   se   ha   comentado   anteriormente,   el   sistema   eZ   Publish  muestra   automáticamente  una  opción   en   el  menú  principal   por   cada   sección   creada,   dependiendo  de   los   permisos   del  usuario  que  está  actualmente  en  curso.  Si  por  ejemplo,  se  desea  que  un  usuario  visitante  no  pueda  visualizar  la  sección  “Comunidad”,  hay  que  omitir  este  permiso  del  rol  “Anonymous”  del  sistema  eZ  Publish  y  así  no  se  mostrará  tampoco  la  opción  en  el  menú.  

En  el  caso  del  sistema  que  se  ha  creado,  el  menú  principal  es  peculiar  y  rompe  con  esta  regla  estándar,   por   lo   tanto   se   han   tenido   que   hacer   ajustes.   A   pesar   de   que   solo   los   usuarios  identificados  con  una  cuenta,  puedan  visualizar  la  sección  “Comunidad”,  se  desea  que  también  los  usuarios  visitantes  puedan  ver   la  opción  en  el  menú  principal,  para  que  sepan  que  existe  esta   sección.   La   solución   que   se   ha   llevado   a   cabo   ha   sido   la   de   otorgar   permisos   de  visualización  de  esta  sección,  a  todos  los  roles  de  usuarios,  de  esta  manera  la  opción  de  menú  se   hace   visible   a   su   vez.   Para   conservar   la   restricción   en   la   que   los   usuarios   visitantes   no  pueden  acceder  a  la  sección,  se  ha  editado  el  código  añadiendo  un  control  al  pulsar  el  enlace.  

<div  id=”ezflb-­‐map-­‐{$o_Gmap.id}”></div>  

 

Page 99: Proyecto!Final!deCarrera BCNLook$&Find

   

98    

Teniendo   en   cuenta   el   funcionamiento   automático   de   generación   de   opciones   de  menú   del  sistema   eZ   Publish,   es   lógico   pensar   que   automáticamente   deben   haber   aparecido   varias  opciones  más  por  cada  contenido  que  se  ha  creado  “¿Qué  es  BCN  Look  &  Find?”,  “Preguntas  más  frecuentes”,  “Regístrate”  e   incluso   los  contenedores  de  objetos  perdidos  y  encontrados.  Para  excluir  estos  nodos  se  ha  modificado  la  plantilla  que  construye  el  menú  principal.  

Hay  que  recordar  que  el  enlace  a   la  sección  “Regístrate”  se  ha  añadido  en  el  encabezado  de  página.  Para  ello  se  ha  modificado  la  plantilla  correspondiente.  

El   resto   de   enlaces   no   tan   importantes   como   para   incluirse   en   el   menú   principal,   pero  obligadas  a  ser  accesibles,  han  sido  situados  en  el  pie  de  página.  Las  secciones  cuyos  enlaces  corresponden  son:  

• ¿Qué  es  BCN  Look  &  Find?  Enlazada  por  Sobre  nosotros.  • Preguntas  más  frecuentes.  Enlazada  por  FAQ.  • Contacta  con  nosotros.  • Condiciones  de  uso.  • Política  de  privacidad.  

Para  ello  se  ha  modificado  la  plantilla  correspondiente.  

Además  se  ha  añadido  un  enlace  al  mapa  del  sitio  que  el  sistema  construye  automáticamente  según  la  ubicación  y  los  permisos  de  las  secciones  creadas.  De  la  misma  manera  que  el  menú  principal  ha  sido  necesario  excluir  algunas  opciones  e  incluir  otras.  

Como  puede  observarse  en  los  modelos  de  plantillas  especificados  en  la  Sección  3.9.1,  el  menú  principal  contiene  dos  opciones  más,  “BCN  y  alrededores”  y  “Añadir  objeto”,  que  realmente  no   corresponden   a   secciones,   por   lo   tanto   el   sistema   eZ   Publish   no   puede   crear  automáticamente.   Así   que   se   han   añadido   editando   el   código   de   la   plantilla   que  muestra   el  menú.   El   desplegable   que   muestra   los   tipos   de   objeto   a   registrar   que   aparece   al   situar   el  cursor  sobre  la  opción  “Añadir  objeto”  se  ha  desarrollando  utilizando  “JavaScript”  (13)  y  una  librería   JQuery   (17)   cargada   directamente   desde   su   sitio   web,   en   vez   de   descargarlas   e  incluirlas  en  el  código.  Se  ha  enlazado  la  siguiente  librería  

http://cdn.jquerytools.org/1.2.5/full/jquery.tools.min.js  

desde  la  plantilla  que  construye  la  estructura  del  sitio  web,  ha  sido  suficiente  para  obtener  todos  los  recursos  necesarios  para  desarrollar  los  elementos  del  sitio  web.  

4.11 Extensión  de  diseño  del  sistema  eZ  Publish  

El   amplio   sistema   eZ   Publish   permite   crear   una   estructura   de   contenido   estándar,   pero   no  dispone  de  algunas  funcionalidades,  aspectos  de  diseño,  etc.,  muy  concretas  del  sistema  BCN  Look   &   Find.   Por   lo   tanto,   es   necesario   extenderlo.   Para   ello   se   ha   seguido   el   estándar   del  “framework”   eZ   Publish   y   se   ha   desarrollado   un   módulo   conocido   como   “extension”.   Para  desarrollar   las  extensiones  se  ha  utilizado  el  tutorial  Tutorial   Introducción  en  el  desarrollo  de  extensiones  en  eZ  Publish  (40).  

Page 100: Proyecto!Final!deCarrera BCNLook$&Find

   

99    

4.11.1 Estructura  de  directorios  

El  primer  paso  para  desarrollado  una  nueva  extensión  es  crear  la  siguiente  estructura  de  directorios  dentro  del  directorio  “extensión”.  

 

Ilustración  20,  Estructura  de  directorios  extensión  de  diseño  

Como   el   resto   de   extensiones   por   defecto,   se   ha   creado   un   directorio   con   el   nombre   de   la  extensión   “bcnlfdesign”.   Dentro   de   este   directorio   se   crean   los   directorios   “design”   que  contendrá  las  plantillas,  archivos  CSS,  JS,  etc.  y  “settings”  donde  se  establece  la  configuración.  

4.11.2 Configuración  

Dentro   del   directorio   “settings”   se   han   añadido   dos   ficheros   de   configuración  “design.ini.append.php”  y  “module.ini.append.php”.  

El  fichero  “design.ini.append.php”  indica  al  sistema  que  dentro  de  esta  extensión  hay  ficheros  de   diseño.   De   esta   manera   además   de   crear   nuevas   plantillas,   estilos,   etc.,   se   puede  sobrescribir  cualquier  otro  fichero  de  diseño  (CSS,  TPL,  JS,  etc.),  que  tenga  el  mismo  nombre.  

El  fichero  “module.ini.append.php”  indica  al  sistema  que  en  este  directorio  se  encuentra  una  extensión.  

4.11.3 Diseño  de  la  extensión  

Como  ya  se  ha  comentado  anteriormente  el  sistema  eZ  Publish  comenzará  a  buscar  elementos  de  diseño  en  los  directorios  con  el  nombre  “design”  de  cada  una  de  las  extensiones  activadas.  Si  no  encuentra  el  elemento   lo  busca  en  el  directorio  “design”  por  defecto.  Por  supuesto,  en  un  nivel  más  prioritario  están  las  reglas  de  sobrescritura.  Cada  vez  que  se  decide  sobrescribir  una   plantilla,   el   sistema   crea   una   regla   de   sobrescritura   en   el   directorio   de   configuración  correspondiente.   En   el   caso   del   sistema   BCN   Look   &   Find,   este   fichero   está   ubicado   en   el  siguiente  directorio.  

“…/settings/siteaccess/plain_site/override.ini.append.php”.  

Page 101: Proyecto!Final!deCarrera BCNLook$&Find

   

100    

El  sistema  eZ  Publish  ubica  la  configuración  general  en  el  directorio  con  el  nombre  “plain_site”  por  defecto.  Este  nombre  puede  modificarse  en  el  momento  de   la   instalación.  A  su  vez,  si  al  instalar   el   sistema   se   han   seleccionado   diversos   paquetes   de   idiomas   para   construir   el   sitio  web,  aparecerá  un  directorio  por   cada   idioma.  En  el   caso  de  BCN  Look  &  Find,  aparecen   los  directorios  “esl”  y  “cat”.  Si  se  desea  crear  una  regla  de  sobrescritura  o  modificar  cualquier  otra  configuración  de  manera  específica  para  un  solo  idioma,  se  deberán  modificar  los  ficheros  de  configuración  contenidos  en  el  directorio  del  idioma  correspondiente.  

En  algunos  casos  ya  comentados  anteriormente  se  ha  decidido  utilizar  reglas  de  sobrescritura  para  modificar   plantillas   por   defecto,   pero   en   la   mayoría   de   casos   se   ha   utilizado   la   nueva  extensión  de  diseño.  

Para   utilizar   la   nueva   extensión   de   diseño   es   tan   simple   como   replicar   la   estructura   de  directorios   donde   se   ubica   la   plantilla   que   se   quiere   sobrescribir   y   crear   la   plantilla   con   el  mismo   nombre.   Por   ejemplo   una   de   las   plantillas   modificadas   ha   sido   la   que   muestra   la  cabecera  del  sitio  web.  

En   la   mayoría   de   casos   en   que   los   cambios   en   la   plantilla   son   mínimos,   se   ha   copiado   la  plantilla  por  defecto  y  posteriormente  se  ha  modificado  el  código.  

El  caso  es  el  mismo  para  imágenes,  ficheros  de  diseño  CSS,  JavaScript,  etc.  

Por   supuesto   no   se   van   a   explicar   todas   las   modificaciones   que   se   han   efectuado   en   las  plantillas  para  obtener  el  resultado  actual  del  sitio  web,  pero  si  se  comentarán  algunas,  para  que  sea  posible  hacerse  una  idea  del  trabajo  llevado  a  cabo.  Un  buen  ejemplo  es  el  desarrollo  de  la  página  principal.  

Diseño  de  la  página  principal  

Como  ya  se  comentado  anteriormente  en  la  Sección  4,  la  página  principal  ya  está  creada  por  defecto  utilizando  el  tipo  de  contenido  “Front  page”.  Este  tipo  de  contenido  acaba  cargando  la  plantilla  de  la  extensión  “ezflow”  correspondiente.  

Esta  plantilla  se  divide  en  dos  zonas  cuyas  reglas  de  diseño  CSS  definen  su  posición,  de  manera  que  el  resultado  es  una  zona  central  y  una  pequeña  zona  en  la  parte  derecha.  El  código  de  la  plantilla  simplemente  carga  los  bloques  que  han  sido  incluidos  en  ambas  zonas  a  partir  de  unas  variables  genéricas  que  han  sido  asignadas  a  la  plantilla.  

 

 Como  puede  verse  en  este  fragmento  de  código,  se  crea  un  bucle  que  obtiene  cada  uno  de  los  bloques  $block  de  la  zona  correspondiente  dentro  del  conjunto  $zones[].  

Se   han   incluido   nuevas   plantillas.   En   la   zona   central   se   ha   cargado   la   nueva   plantilla  “objects_list.tpl”   y   en   la   zona   de   la   derecha   se   han   cargado   las   nuevas   plantillas  “total_returned.tpl”,   “category_list.tpl”   y   “last_returned.tpl”,   utilizando   la   siguiente  instrucción.  

{foreach  $zones[$i].blocks  as  $block}  

Page 102: Proyecto!Final!deCarrera BCNLook$&Find

   

101    

 

En  la  posición  donde  se  encuentra  parameter  pueden  incluirse  varias  variables  que  se  cargarán  en  la  plantilla.  

La  plantilla  “objects_list.tpl”  es  la  encargada  de  mostrar  la  lista  de  objetos,  el  mapa,  los  filtros  de  búsqueda  y  el  “paginador”.  En  la  parte  superior  se  han  añadido  los  botones  de  filtros  que  no   son   más   que   referencias   a   la   misma   sección   pero   incluyendo   unos   parámetros   que   se  utilizarán  para  saber  qué  tipo  de  objetos  se  deben  mostrar.  

 

Ilustración  21,  Filtros  de  búsqueda  de  objetos  

Las  URL  tienen  este  aspecto.  

“…/(center_filter)/458/(object_filter)/167/(category_filter)/269/(oldpage)/1/(newpage)/1”.  

• El  parámetro  “center_filter”  indica  el  identificador  del  centro  del  que  se  van  a  mostrar  los  objetos.  

• El   parámetro   “object_filter”   indica   el   identificador   del   tipo   de   objeto   que   se   va   a  mostrar  (perdido  o  encontrado).  

• El   parámetro   “category_filter”   indica   el   identificador   de   la   categoría   a   la   que  pertenecen  los  objetos  que  se  van  a  mostrar.  

• El  parámetro  “oldpage”  indica  cuál  era  la  página  anteriormente  mostrada.  • El  parámetro  “newpage”  indica  la  página  que  se  está  mostrando.  

Para  la  creación  del  selector  de  centros  se  ha  incluido  una  nueva  plantilla  donde  se  hace  una  consulta   de   los   centros   registrados   en   el   sistema   y   se   construye   posteriormente   el   selector  mostrado  en  la  imagen  anterior.  

Cada   vez   que   el   usuario   selecciona   un   centro   del   selector   y   teniendo   en   cuenta   el   resto   de  filtros,  el  sitio  web  hace  una  llamada  a  una  URL  como  la  anteriormente  mostrada.  El  valor  de  los   parámetros   de   la   llamada   es   recogido   para   hacer   una   posterior   consulta   de   los  correspondientes  objetos  a  mostrar.  

Para   hacer   una   consulta   desde   plantillas   TPL   de   información   guardada   en   base   de   datos   se  utiliza  la  instrucción  del  motor  de  eZ  Publish,  “fetch”.  A  continuación  se  adjunta  el  fragmento  de  código  TPL  que  obtiene  la  información  de  los  objetos  teniendo  en  cuenta  los  filtros  que  el  usuario  ha  escogido.  

{include  uri  =  ’design:category_list.tpl’  parameter  =  ‘value’}  

Page 103: Proyecto!Final!deCarrera BCNLook$&Find

   

102    

 

Esta   consulta   fetch   devuelve   todos   los   contenidos   ‘content’,   ‘list’,   cuyo   nodo   padre  ‘parent_node_id’   es   el   contendor   de   objetos   perdidos   o   encontrados   array($i_lost,  $i_found),  ordenados  por  fecha  de  publicación  ‘sort_by’,  array(‘published’,  false()),  que  han  sido  registrados  por  el  centro  indicado  $i_center  que  pertenecen  a   la  categoría   indicada  $i_category,  con  límite  $i_limit,  comenzando  por  la  posición  $i_offset.  

Esta   consulta   elaborada   utilizando   código   TPL   del  motor   eZ   Publish,   será   convertida   por   las  correspondientes  librerías  PHP  a  una  consulta  directamente  a  base  de  datos.  Obteniendo  así  el  conjunto  de  objetos  especificados  en  la  variable  $st_objects.  

Por  cada  objeto  guardado  dentro  de  dicha  variable  se  hará  una  llamada  a  una  nueva  plantilla  “object.tpl”   que   es   la   encargada   de   ordenar   y   mostrar   los   datos   obtenidos   del   objeto.  Dependiendo  de  las  características  del  objeto  y  del  usuario  se  mostrarán  unos  datos  u  otros  y  de  una  manera  u  otra.  Por  ejemplo  si  el  objeto  es  de  tipo  encontrado,  se  encuentra  en  estado  perdido  y  el  usuario  que  lo  está  visualizando  no  es  quién  lo  ha  añadido,  se  mostrará  el  botón  “Es  mío”.  En  la  imagen  que  hay  a  continuación  puede  verse  un  ejemplo  del  resultado.  

 

Ilustración  22,  Resumen  de  objeto  

Por  supuesto  se  han  tenido  que  modificar  y  añadir  reglas  de  diseño  en  las  hojas  de  estilo  CSS.  Los   ficheros   CSS   que   está   utilizando   el   sistema   de   manera   prioritaria   son   los   del   diseño  “ezflow”.  Estos  ficheros  son  “core.css”,  “ezflow.css”  y  “pagelayout.css”  y  se  han  copiado  en  el  directorio  de  la  nueva  extensión  de  diseño,  para  así  modificarlos  conservando  los  originales.  

También   se   han   añadido  nuevas   imágenes   como   las   de   los   estados   de  objeto,   bocadillos   de  ayuda,  etc.  

{set  $st_objects  =  fetch(‘content’,  ‘list’,  hash(  

‘parent_node_id’,  array($i_lost,  $i_found),  

‘sort_by’,  array(‘published’,  false()),  

‘attribute_filter’,  array(array(‘owner’,  ‘=’,  $i_center)),  

‘attribute_filter’,  array(array(  

array(‘found_object/category’,  ‘=’,  $i_category)),  

‘attribute_filter’  array(array(  

array(‘lost_object/category’,  ‘=’,  $i_category)),  

‘offset’,  $i_offset,  

‘limit’,  $i_limit))}  

 

Page 104: Proyecto!Final!deCarrera BCNLook$&Find

   

103    

De  la  misma  manera  que  la  lista  de  objetos  del  área  central  de  la  página  principal  se  ha  creado  la   plantilla   con   la   lista   de   categorías   del   área   derecha.   Como   ya   se   ha   comentado  anteriormente   en   la   Sección   4.5,   las   categorías   son   contenidos   del   sistema   ubicados   en   un  apartado  de   la   sección  de  administración,  por   lo   tanto  para  obtener  su   información  hay  que  hacer  una  consulta  de  los  elementos  contenidos  en  esa  sección  utilizando  el  método  “fetch”,  tal   y   como   se   ha   hecho   para   los   objetos.   Cada   una   de   las   categorías   está   formada   por   una  etiqueta   “<a>”   de   HTML   con   una   referencia   a   la   URL   antes   mencionada,   modificando   el  parámetro  “category_filter”  por  el  identificador  de  la  categoría.  

El  código  de   las  plantillas  TPL,  como  ya  se  ha  dicho,  está   formado  por  HTML  y  el   leguaje  del  motor  de  plantillas  definido  por  el  “framework”  de  eZ  Publish.  Un  ejemplo  de  la  combinación  de  ambos  es  la  construcción  de  cada  una  de  las  categorías.  

 

En  el  fragmento  de  código  anterior  se  diferencia  el  código  HTML  por  su  color  azul  y  el  código  TPL  por  su  color  negro.  Como  puede  verse,  la  URL  se  construye  concatenando  el  nombre  de  las  variables,   con   el   contenido   de   las   variables   que   definen   los   parámetros,   como   $i_category.  href={concat(‘…/(category_filter)/’,  $i_category,  ‘/…’)|ezurl()}.  Para   que   eZ   Publish  construya  la  URL  en  el  formato  correcto  se  añade  al  final  la  instrucción  ezurl().  

Como  se  ha  comentado,  este  fragmento  de  código  construye  cada  una  de  las  categorías  tal  y  como  se  muestra  en  la  siguiente  imagen.  

 

Ilustración  23,  Categoría  de  objeto  

4.12 Extensión  funcional  del  sistema  eZ  Publish  

Como   ya   se   ha   comentado   en   la   sección   anterior,   el   sistema   eZ   Publish   dispone   de   unas  funcionalidades   estándar   que   no   satisfacen   totalmente   los   requerimientos   del   sistema   BCN  Look  &  Find.  Añadir  botones  como  “Es  mío”,  “Lo  he  encontrado”,  “Cancelar  búsqueda”,  etc.,  es  sencillo  de  desarrollar   sobre   las   correspondientes  plantillas  TPL,  pero   los  procesos  que  estos  botones   conllevan   son   muy   específicos   (cambios   de   estado,   envío   de   mensajes   de   correo  electrónico,   etc.).   Así   que   de   la   misma   manera   que   la   extensión   de   diseño   ya   expuesta  

<a  class=”category”    

href={concat(‘…/(category_filter)/’,  $i_category,  ‘/…’)|ezurl()}>  

<h3>  

<span  class=”image”>{$o_image}</span>  

<span  class=”title”>{$s_title}</span>  

<span  class=”description”>{$s_description}</span>  

</h3>  

</a>  

Page 105: Proyecto!Final!deCarrera BCNLook$&Find

   

104    

anteriormente,   se  ha   creado  una  extensión   funcional   siguiendo  el  estándar  del   “framework”  de  eZ  Publish.  

4.12.1 Estructura  de  directorios  

El   primer   paso   para   desarrollar   una   nueva   extensión   es   crear   la   siguiente   estructura   de  directorios  dentro  del  directorio  “extension”.  

 

Ilustración  24,  Estructura  de  directorios  de  extensión  funcional  

Como  el  resto  de  extensiones  por  defecto  y  como  en  la  extensión  de  diseño  ya  expuesta,  se  ha  creado   un   directorio   con   el   nombre   de   la   extensión   “bcnlfextension”,   con   sus   respectivos  subdirectorios,  ficheros  de  configuración,  etc.  

4.12.2 Módulos  

En   el   directorio   “modules”   es   donde   se   deben   desarrollar   las   funcionalidades.   Para   cada  módulo   se   debe   crear   un   directorio   con   un   archivo   “module.php”   y   otro   archivo   con   un  “script”  PHP  por  cada  funcionalidad  a  desarrollar.  

El   archivo   “module.php”   define   la   estructura   del  módulo.   Qué   acciones   posee,   qué   “script”  debe  ejecutar  para  cada  una  de  ellas,  qué  parámetros  reciben,  etc.  

Los  “scripts”  PHP  contienen  el  código  que  se  desea  ejecutar  en  cada  acción.  Para  ejecutar  una  acción  se  debe  hacer  mediante  una  llamada  POST  o  GET  directamente  introduciendo  la  URL  o  desde   una   plantilla   de   diseño   TPL.   Por   ejemplo,   si   se   quiere   acceder   a   la   funcionalidad   de  registro   de   usuarios,   hay   que   ejecutar   la   acción   (“script”)   “register”   del  módulo   “user”,   con  unos  parámetros  enviados  por  POST,  por   lo   tanto  sobre   la  plantilla  donde  se  quiere  ejecutar  esta  acción  habrá  que  crear  un  formulario  que  envié  la  petición  a  la  siguiente  URL.  

“…/user/register/”.  

Page 106: Proyecto!Final!deCarrera BCNLook$&Find

   

105    

Si  en  el  archivo  “module.php”  está  definida  correctamente  la  estructura  del  módulo  se  acabará  ejecutando  el  “script”  “register.php”  con  los  parámetros  enviados.  

Se  han  desarrollado  tres  módulos.  “bcnlfuser”,  “finder”  y  “owner”.  

Módulo  bcnlfuser  

Este  módulo   pretender   ampliar   las   acciones   definidas   en   el  módulo   “user”   por   defecto.   Las  funcionalidades  que  se  han  desarrollado  son  las  siguientes.  

• Auto-­‐identificación  del   usuario   en  el   sistema   cuando  pulsa   cualquier  URL   adjunta  en  los  mensajes  de  correo  electrónico  personales  que  se  le  envían.  Acción  “autologin”.  

• Redirección   del   usuario   después   de   su   identificación   a   otras   acciones   que   requieren  parámetros  mediante  POST.  El  sistema  por  defecto  permite  indicar  la  URL  a  la  que  será  redirigido   el   usuario   cuando   se   identifica,   pero   no   permite   ejecutar   acciones   con  parámetros   POST.   En   el   caso   del   sistema  BCN   Look  &   Find   es   necesario   si   se   quiere  redireccionar   al   usuario   a   los   formularios   de   registro   de   objetos,   después   de  identificarse,  tras  haber  intentado  acceder  sin  estarlo.  Acción  “redirect”.  

Primero   se  ha   creado  el   fichero   “module.php”  definiendo   las  dos   acciones   y   los  parámetros  que  reciben  cada  una  de  ellas.  

La  llamada  a  la  acción  de  auto-­‐identificación  se  realizará  de  la  siguiente  manera.  

“…/bcnlfuser/autologin/[parámetro1]/[parámetro2]/[parámetro3]”.  

El   primer  parámetro   contiene  el   nombre  que   identifica   en  el   sistema  al   usuario  que   se   va   a  auto-­‐identificar.   El   segundo   parámetro   contiene   el   identificador   “hash”   del   objeto   que  representa  el  usuario  en  el  sistema  y  el  tercer  parámetro  será  el  identificador  del  nodo  que  se  quiere  mostrar  al  usuario  después  de  la  identificación.  

La  llamada  a  la  acción  de  redirección  se  realizará  de  la  siguiente  manera.  

“…/bcnlfuser/redirect/[parámetro1]/[parámetro2]/[parámetro3]”.  

El  primer  parámetro  contiene  el  tipo  de  contenido  que  el  usuario  pretendía  crear  antes  de  que  el  sistema  pidiera  su  identificación.  En  el  caso  del  sistema  BCN  Look  &  Find  es  objeto  perdido  (lost_object)  o  objeto  encontrado  (found_object).  El  segundo  parámetro  es  el  identificador  del  nodo   que   contendrá   el   contenido   creado.   Y   por   último,   el   tercer   parámetro   contendrá   el  código  del  idioma  en  el  que  se  va  a  crear  el  contenido.  Estos  tres  parámetros  son  los  que  utiliza  la  acción  para  crear  contenido  por  defecto  de  eZ  Publish  (“action/content”).  

El   archivo   “autologin.php”   es   sencillo.   Buscará   el   usuario   con   el   nombre   de   identificación  contenido   en   el   primer   parámetro.   Comprobará   si   el   identificador   hash   del   objeto   que   lo  representa   corresponde   con   el   del   segundo   parámetro.   Si   es   así,   lo   identificará   y   lo  redireccionará  a  la  acción  por  defecto  que  muestra  el  contenido  del  nodo  correspondiente  con  el   identificador  del  parámetro   tres.  En  el   caso  del   sistema  BCN  Look  &  Find  normalmente  se  estará  redireccionando  a  la  información  de  algún  objeto  o  usuario.  

Page 107: Proyecto!Final!deCarrera BCNLook$&Find

   

106    

El   archivo   “redirect.php”   también   es   sencillo.   Simplemente   ejecutará   la   acción   para   crear  contenido  de  eZ  Publish.  

“.../content/edit/[parámetro4]/[parámetro5]”.  

El  cuarto  parámetro  es  el  identificador  numérico  del  tipo  de  contenido  a  crear,  se  obtendrá  a  partir  del  nombre  del  contenido.  El  quinto  parámetro  es  la  versión  del  contenido.  Es  este  caso  1.  Podría  llamarse  directamente  a  esta  acción  desde  la  plantilla,  pero  el  sistema  eZ  Publish  está  creado   para   que   previamente   se   cree   un   objeto   (contenido)   vacío   y   después   se   complete  mediante  un   formulario.   Por   lo   tanto  es  necesario  un  paso   intermedio  que   cree  este  objeto  vacío.  

Módulos  finder  y  owner  

El  módulo   “finder”   se   ha   creado   para   albergar   todas   las   funcionalidades   involucradas   en   el  proceso   de   devolución   de   un   objeto   de   tipo   perdido   registrado   en   el   sistema.   Se   han  desarrollado  las  siguientes  funcionalidades.  

• Cancelar  la  búsqueda  de  un  objeto  perdido  registrado  en  el  sistema.  Esta  funcionalidad  solo  está  disponible,  a  nivel  de  plantilla,  para  el  usuario  que  ha  registrado  el  objeto  y  siempre  y  cuando  el  objeto  esté  en  estado  perdido.  Acción  “cancel”.  

• Marcar  objeto  como  encontrado.  Estando  el  objeto  también  en  estado  perdido,  para  el  resto  de  usuarios  está  disponible  la  funcionalidad  a  nivel  de  plantilla.  Acción  “find”.  

• Confirmar   devolución   del   objeto.   Esta   funcionalidad   solo   está   disponible,   a   nivel   de  plantilla,  para  el  usuario  que  ha  registrado  el  objeto  y  siempre  y  cuando  el  objeto  esté  en  estado  pendiente.  Acción  “confirm”.  

• Descartar   devolución   del   objeto.   Esta   funcionalidad   está   disponible   en   las   mismas  circunstancias  que  la  de  confirmar  devolución.  Acción  “discard”.  

• Mostrar  una  plantilla  de  confirmación   tras  añadir  o  editar  un  objeto  perdido.  Acción  “lost”.  

Como  ya  se  ha  hecho  en  otros  módulos,  primero  se  ha  creado  el  fichero  “module.php”.  

Las   llamadas   a   las   acciones   correspondientes   a   este   módulo   se   harán   tal   y   como   se   ha  comentado  anteriormente  con  la  diferencia  que  en  este  caso  se  les  pasarán  como  parámetros  únicamente  el  identificador  numérico  del  objeto  y  la  versión.  

El   archivo   “cancel.php”   busca   el   objeto   perdido   con   el   identificador   del   parámetro   uno   y   la  versión  del  parámetro  dos  y  actualiza  su  estado  a  devuelto.  

El   archivo   “find.php”   busca   el   objeto   perdido   con   el   identificador   del   parámetro   uno   y   la  versión  del  parámetro  dos  y  actualiza  su  estado  a  pendiente.  Para  poder  tener  presente  qué  usuario   ha   marcado   el   objeto,   se   enviará   el   identificador   el   usuario   en   curso   por   POST.   El  “script”  recogerá  esta  variable  y  la  guardará  en  el  campo  “finder_id_temp”  del  objeto  perdido.  Por  el  momento  no  es  seguro  que  este  usuario  haya  encontrado  realmente  el  objeto  así  que  se  guarda   en   “finder_id”   hasta   que   el   propietario   confirme   la   devolución.   Por   último   carga   la  plantilla  correspondiente.  

Page 108: Proyecto!Final!deCarrera BCNLook$&Find

   

107    

El  siguiente  paso  del  proceso  es  la  confirmación  o  descarte  de  la  devolución  del  objeto.  

En  el  caso  que  el  propietario  del  objeto  decida  confirmar  la  devolución  se  hará  una  llamada  a  la   acción   “confirm.php”   que   buscará   el   objeto   correspondiente   y   actualizará   su   estado   a  devuelto.  Además  moverá  el  identificador  del  usuario  que  ha  encontrado  el  objeto  del  campo  “finder_id_temp”  a  “finder_id”  ya  que   la  devolución  ha  sido  confirmada.  Por  último  carga   la  plantilla  correspondiente.  

En   el   caso   contrario,   el   usuario   hará   una   llamada   a   la   acción   descartar   devolución  “discard.php”  de  la  misma  manera  que  la  de  confirmación.  

La   última   funcionalidad   del   módulo   se   carga   cada   vez   que   el   usuario   modifica   o   añade   un  objeto   perdido.   El   “script”   “lost.php”   busca   el   objeto   con   el   identificador   del   primer  parámetro.  Si  la  versión  contenida  en  el  segundo  parámetro  es  uno  carga  la  plantilla  en  la  que  se   informa   al   usuario   que   el   objeto   ha   sido   registrado   correctamente.   Si   por   el   contrario   la  versión  es  mayor  que  uno,  entonces  carga   la  plantilla  en   la  que  se   informa  al  usuario  que  el  objeto  ha  sido  editado  correctamente.  

El   módulo   “owner”   es   similar   al   módulo   “finder”,   pero   en   este   caso   alberga   todas   las  funcionalidades   del   proceso   por   el   que   pasa   un   objeto   de   tipo   encontrado   desde   que   es  registrado  hasta  que  se  confirma  la  entrega  a  su  propietario.  Puesto  que  sus  funcionalidades,  acciones  y  “scripts”  son  prácticamente  iguales  no  es  necesario  describir  el  funcionamiento  de  este  módulo.  

4.12.3 Diseño  de  la  extensión  

Como   ya   se   ha   comentado   antes   el   sistema   sobrescribe   cualquier   fichero   de   diseño   que  encuentre  con  el  mismo  nombre  que  el  fichero  que  se  añada  en  este  directorio.  Por  ejemplo  si  se  quiere  sobrescribir  la  plantilla  que  se  muestra  al  registrar  un  usuario  

Hay   que   crear   la   misma   estructura   de   directorios   dentro   del   directorio   de   diseño   de   la  extensión  y  después  modificar  la  plantilla  TPL  como  se  desee.  

En  este  caso  no  interesa  sobrescribir  ninguna  plantilla  sino  crear  nuevas.  

En   el   directorio   “design”   de   la   extensión   se   ha   creado   el   subdirectorio   “standard”.   Se   ha  escogido  este  nombre  para  respetar  la  nomenclatura  por  defecto  de  eZ  Publish.  Dentro  se  ha  creado  el  directorio  “templates”.  Para  diferenciar  las  plantillas  de  cada  módulo  se  han  creado  subdirectorios  con  el  nombre  de  los  módulos.  

El  directorio  “finder”  contiene  las  plantillas  TPL  del  módulo  “finder”.  

• La  plantilla  “cancel.tpl”  se  muestra  tras  ejecutar  el  código  de  “cancel.php”.  Informa  al  usuario  que  la  búsqueda  de  su  objeto  perdido  ha  sido  cancelada  y  su  objeto  ha  pasado  a  estado  devuelto.  

Page 109: Proyecto!Final!deCarrera BCNLook$&Find

   

108    

• La   plantilla   “find.tpl”   se   muestra   tras   ejecutar   el   código   de   “find.php”.   Informa   al  usuario   que   se   ha   marcado   el   objeto   como   posiblemente   encontrado   y   que   se   ha  enviado  un  mensaje  de  correo  electrónico  al  usuario  que  ha  registrado  el  objeto.  

• La   plantilla   “finderinfo_email.tpl”   codifica   el   mensaje   de   correo   electrónico   que   se  envía   tras   ejecutar   el   código   de   “find.php”.   Éste   le   envía   los   datos   necesarios   para  construir  enlaces,  nombres  de  usuarios,  objetos,  etc.  

• La  plantilla  “confirm.tpl”  se  muestra  tras  ejecutar  el  código  de  “confirm.php”.  Informa  al  usuario  que  la  devolución  del  objeto  perdido  que  ha  registrado  ha  sido  confirmada  y  por  lo  tanto  el  objeto  ha  pasado  a  estado  devuelto.  

• La  plantilla  “discard.tpl”  se  muestra  tras  ejecutar  el  código  de  “discard.php”.  Informa  al  usuario  que  la  devolución  del  objeto  perdido  que  ha  registrado  ha  sido  descartada  y  por  lo  tanto  ha  vuelto  a  estado  perdido.  

El  directorio  “owner”  contiene  las  plantillas  TPL  del  módulo  “owner”.  Éstas  son  similares  a  las  del  directorio  “finder”.  

4.13 Posicionamiento  del  sitio  web  y  otros  desarrollos  

En  esta  sección  se  pretende  describir  muy  brevemente  qué  se  ha  llevado  a  cabo  para  mejorar  el  posicionamiento  SEO  en  el   sitio  web  y  otros  desarrollos,   como   la   inclusión  del  módulo  de  Facebook  (41).  

Durante  el  desarrollo  del   sistema   se  han   tenido  en   cuenta  algunos  aspectos  para  mejorar  el  posicionamiento   SEO   del   sitio   web   en   buscadores,   sobretodo   en  Google.   A   continuación   se  describen  algunos  de  ellos.  

Etiquetación  del  contenido  siguiendo  una   jerarquía  según  su   importancia.  En  el  lenguaje  de  programación  (11)  HTML  existen  unas  etiquetas  para  definir  cabeceras  <h1>,  <h2>,  <h3>,  etc.  A  parte  de  modificar  el  tamaño  y  el  grosor  del  texto  que  se  encuentra  dentro  de  estas  etiquetas,  los   algoritmos   de   búsqueda   de   los   buscadores     las   utilizan   para   indexar   el   contenido   y  asignarles  una  importancia.  Para  los  títulos  de  las  secciones  se  ha  utilizado  la  etiqueta  <h1>  de  mayor  importancia.  Cuando  el  usuario  accede  a  la  información  completa  del  objeto,  la  sección  se   titula   con   el   nombre   del   objeto   dentro   de   la   etiqueta   <h1>   también.   De   esta  manera   los  buscadores   indexarán   cada   uno   de   los   objetos   registrados   en   el   sistema.   En   el   caso   de   las  categorías   se   ha   utilizado   la   etiqueta   <h2>,   ya   que   no   tienen   la  misma   importancia   que   los  objetos  y  las  secciones,  pero  igualmente  es  una  ventaja  que  los  buscadores  las  indexen.  

Modificar  el  código  de  la  cabecera  para  que  disponga  de  un  título  distinto  según  la  sección  que  se  está  visualizando.  Las  páginas  HTML  se  dividen  en  cabecera  <header>  y  cuerpo  <body>.  Dentro  de   la  etiqueta  <header>   se  pueden  añadir  distintas  etiquetas  que  almacenan  algunos  datos  del  sitio  web.  Una  de  las  etiquetas  más  importantes  y  que  los  algoritmos  de  búsqueda  de  los  buscadores   tienen  en  cuenta  es   la  etiqueta  <title>.  El   sistema  eZ  Publish  construye  esta  etiqueta  dinámicamente  con  el   título  de   la  sección  que  se  está  visualizando,  de  esta  manera  favorece  que  los  buscadores  indexen  las  diferentes  secciones  del  sitio  web.  

Page 110: Proyecto!Final!deCarrera BCNLook$&Find

   

109    

Agregar   etiquetas   “meta”   en   cabecera   con   descripciones   y   palabras   clave   del   sitio   web.  Como  se  ha  comentado  anteriormente  en  la  cabecera  de  una  página  HTML  se  pueden  incluir  diferentes   etiquetas   con   datos   del   sitio   web.   Para   añadir   descripciones   se   ha   añadido   la  etiqueta   <meta   content=”…”   name=”description”>,   que   añade   descripciones   al   sitio   web  situadas   en   el   atributo   “content”.   Los   buscadores   indexarán   cualquier   descripción   de   esta  etiqueta  y  la  mostrará  en  los  resultados  de  búsqueda  como  descripciones  del  sitio  web.  De  la  misma   manera   se   han   añadido   palabras   clave,   añadiendo   la   etiqueta   <meta  content=”…”  name=”keywords”>.  Las  palabras  que  se  introduzcan  aquí  serán  indexadas  por  los  buscadores  de  manera  que  si  por  ejemplo  un  usuario  busca  la  palabra  “objeto”  en  Google  y  esta  palabra  está  contenida   en   la   etiqueta,   el   sitio   web   tendrá   más   posibilidades   de   ser   mostrado   en   los  resultados.  

Para   que   Google   comience   a   recopilar   información   del   sitio   web   y   así   mejorar   su  posicionamiento,   se   ha   utilizado   una   aplicación   web   que   Google   suministra   llamada  Webmasters   (42).   Para   poder   utilizar   las   herramientas   de   esta   aplicación   primero   ha   sido  necesario  crear  una  cuenta  de  Google  para  el  sitio  web.  El  siguiente  paso  ha  sido  el  de  registrar  la  URL  del   sitio  web  y  su  ubicación  geográfica   (país).  Una  vez  hecho  esto  Google  comienza  a  recopilar   información   del   sitio   web   y   a  mejorar   su   posicionamiento   de  manera   automática.  Además  se  disponen  de  datos  estadísticos  y  otras  herramientas,  como  por  ejemplo  se  le  puede  indicar   la   ubicación   de   un  mapa   del   sitio   que   Google   analizará   y   realizará   sus   posteriores  búsquedas  según  las  indicaciones  de  este  fichero.  

Un  mapa  de  un  sitio  web  es  un  documento  XML  compuesto  por  etiquetas  que  definen  las  URL  de   las  diferentes  secciones  del  sitio,  que  se  quiere  que   los  buscadores   indexen.  Para  crear  el  mapa  del  sitio  (sitemap.xml)  se  ha  utilizado  la  documentación  seowebconsultor.com  (43).  

Para   mejorar   la   experiencia   de   usuario   en   el   sitio   web,   fomentar   su   uso   y   también   para  mejorar  su  posicionamiento  web,  se  ha  decidido  crear  una  página  en  Facebook  (44).  Facebook  proporciona   diferentes   módulos   para   incorporar   en   el   sitio   web,   entre   ellos   uno   muy  interesante   que   se   ha   decidido   incorporar.   Este  módulo  muestra,   si   el   usuario   tiene   sesión  abierta   en   Facebook,   algunos   de   los   amigos   que   tiene   agregados   en   su   cuenta   y   que   han  marcado   la  opción  “me  gusta”  en   la  página  de  Facebook  del   sitio  web,  si  el  usuario  no  tiene  sesión  abierta  muestra  de  manera  aleatoria  algunos  de  los  usuarios  que  les  gusta  el  sitio  web.  Además  pueden  acceder  directamente  a  su  cuenta  o  a  dicha  página  y  por  supuesto  marcar  el  sitio  web  con  “me  gusta”.  Esta  funcionalidad  es  interesante  ya  que  crea  una  vinculación  entre  una  poderosa  red  social  como  es  Facebook  y  el  sitio  web  BCN  Look  &  Find.  Además  de  captar  nuevos  usuarios,  mejora  su  posicionamiento.  Su  desarrollo  ha  sido  sencillo,  ya  que  Facebook  proporciona  el  código  exacto  que  hay  que  copiar  y  pegar  en  BCN  Look  &  Find,  simplemente  ha  sido  necesario  ajustar  su  tamaño  para  incorporarlo  en  la  estructura  del  sitio  web.  

   

Page 111: Proyecto!Final!deCarrera BCNLook$&Find

   

110    

5 Experimentación  

Durante  el   desarrollo   del   sistema   se  han   ido  efectuado  pruebas   funcionales   y  de  usabilidad.  Algunas  de  las  pruebas  se  han  efectuado  con  usuarios  reales  ya  que  al  fin  y  al  cabo  son  quienes  finalmente   van   a   utilizar   el   producto   final.   Para   ello   se   ha   intentado  hacer   una   selección   de  diferentes  tipos  de  usuario,  usuarios  más  técnicos  e  integrados  en  el  mundo  de  la  informática,  usuarios  más  genéricos  e  incluso  usuarios  cuya  experiencia  con  Internet  es  limitada.  

Ha  sido  necesario  dar  pasos  atrás  constantemente  en  el  desarrollo  y  parte  de  la  especificación  del  proyecto  teniendo  en  cuenta  dichas  pruebas,  comentarios  y  opiniones  de  usuarios,   tanto  para   reparar   errores,   como   para   mejorar   aspectos   funcionales,   de   diseño   y   usabilidad.   Por  ejemplo  la  localización  de  los  filtros  de  búsqueda  y  las  opciones  del  menú  principal  han  sido  un  punto  crítico  en  la  usabilidad  del  sitio  web.  

5.1 Pruebas  de  usuario  

En   esta   sección   se   describen   los   perfiles   de   algunos   de   los   usuarios   que   han   llevado   a   cabo  pruebas   del   producto.   Cuáles   han   sido   algunas   de   sus   conclusiones   y   qué   soluciones   se   han  llevado  a  cabo  o  se  proponen  para  solucionar  los  problemas  encontrados.  

 

Las  opiniones  de  este  tipo  de  usuario,  en  parte,  son  de  las  más  valiosas,  ya  que  al  fin  y  al  cabo,  abarcan  la  mayoría  de  usuarios  que  utilizarán  el  sitio  web.  A  continuación  se  muestran  algunas  de  las  aportaciones  de  usuarios  con  este  perfil.  

✖  El  usuario  reporta  que  no  hay  ninguna  manera  de  recuperar   la  contraseña  cuando  ésta  es  olvidada.  

✔  Para  solucionar  este  problema  eZ  Publish  ya  dispone  de  dicha  funcionalidad.  Simplemente  se   ha   añadido   el   enlace   con   el   nombre   “¿Has   olvidado   la   contraseña?”   en   el   bloque   de  identificación  de  usuario.  

✖  El  usuario  reporta  que  el  acceso  al  perfil  personal  está  demasiado  escondido.  

✔ Para  solucionar  este  problema  se  ha  añadido  un  enlace  al  perfil  del  usuario  en  la  parte  superior  derecha  de  la  cabecera,  junto  al  enlace  para  cerrar  la  sesión  de  usuario.  

Page 112: Proyecto!Final!deCarrera BCNLook$&Find

   

111    

 

Estos  usuarios  aportan  un  punto  de  vista  más  técnico  a  las  pruebas  del  desarrollo.  

✖ El  usuario  reporta  que  el  botón  para  cambiar  la  contraseña,  ubicado  en  el  perfil  del  usuario,  está  demasiado  escondido.  

✔ Para  solucionar  este  problema  se  ha  movido  el  botón  a  la  cabecera,  junto  con  el  botón  de  editar  datos  del  perfil.  También  se  ha  añadido  un  icono  representativo.  

✖ El  usuario  reporta  que  el  nombre  para  acceder  a  los  datos  de  la  cuenta  personal  del  usuario  “Mi  cuenta”,  no  es  el  mas  indicado.  

✔ Teniendo  en  cuenta  otros  sitios  web,  sobre  todo  redes  sociales,  se  ha  decidido  cambiar  el  nombre  de  “Mi  cuenta”  a  “Mi  perfil”.  

 

Este  perfil  de  usuario  es  el  más   indicado  para  opinar   sobre  el   tema  de   la  gestión  de  objetos  perdidos   registrados  por  usuarios  de   tipo  centro.  A  continuación  se  describen  algunas  de   las  aportaciones  de  usuarios  con  este  perfil.  

✖ El   usuario   reporta   que   normalmente   los   usuarios   no   registran   objetos   perdidos   de   la  categoría  documentación.  Es  mucho  más  factible  entregarlos  personalmente  o  depositarlas  en  centros   como   comisarías   de   policía   u   oficinas   de   administración   pública.   Aunque   el   usuario  decidiera   registrar   un   objeto   de   tipo   documentación   se   desconoce   hasta   que   punto   sería  seguro  revelar  información  personal  del  usuario  propietario  de  la  documentación.  

A   priori   es   lógico   que   cuando   un   usuario   encuentre   documentación   del   tipo   DNI,   carnet   de  conducir,  tarjetas  de  crédito,  prefiera  entregarlos  en  persona  en  el  domicilio  especificado  en  la  

Page 113: Proyecto!Final!deCarrera BCNLook$&Find

   

112    

documentación,   si   la   hubiera,   o   en   una   comisaría   de   policía.   A   pesar   de   ello   y   teniendo   en  cuenta   que   suele   ser   un   tipo   de   objeto   que   suele   perderse   frecuentemente,   es   necesario  incorporar  esta  categoría.  Hay  que  tener  en  cuenta  que  esta  categoría  puede  englobar  muchos  tipos  de  documentos  que  no  necesariamente  tienen  que  contener  datos  personales.    

✔ Una  medida  que  se  ha   tomado  es   la  de  añadir  mensajes  de  aviso  que   indiquen  al  usuario  que  él  es  el  único  responsable  del  registro  de  datos  personales.    

✔ Otra  manera  de  evitar  que   los  usuarios  registren  datos  personales  de  otros  al   registrar  un  objeto  de   la  categoría  documentación,  sería  el  de  crear  nuevos  campos  en  el   formulario  que  aparecieran  solo  en  el   caso  de  que  el  usuario   seleccionara   la  categoría  documentación.  Para  controlar   los   datos   a   introducir,   primero   se   le   obligaría   a   seleccionar   qué   tipo   de  documentación   va   a   registrar   y   posteriormente   permitirle   añadir   algún   tipo   de   dato  relacionado   que   no   rompiera   la   privacidad   del   propietario.   Dado   el   coste   de   esta   posible  solución  no  se  ha  desarrollado,  pero  se  ha  planteado  como  posible  extensión  futura.  

5.2 Encuestas  

En   otros   casos   se   ha   recurrido   a   encuestas   previas   a   los   usuarios   para   que   ellos   mismos  decidieran  el  resultado.  Uno  de  los  casos  ha  sido  el  de  la  elección  del  nombre  de  los  filtros  de  búsqueda  de  objetos  por  tipo  (“Objetos  para  localizar”  y  “Objetos  para  devolver”).  Puesto  que  ambos   tipos   de   objeto   son   al   fin   y   al   cabo   objetos   perdidos   los   nombres   seleccionados  inicialmente   (“Objetos  perdidos”  y  “Objetos  encontrados”),  podían  provocar  confusiones,   así  que  se  han  propuesto  varias  opciones  más  la  posibilidad  de  proponer  nuevas  alternativas.  Tras  la   votación   de   unos   siete   usuarios,   a   los   cuales   se   les   agradece   su   colaboración,   se   han  escogido   los   nombres   actualmente   en   el   sitio   web.   Estos   han   sido   las   propuestas   y   los  resultados.  

Tipo  perdido   Tipo  encontrado   Votos  

Han  perdido   Se  han  encontrado   0  

Objetos  para  localizar   Objetos  para  devolver   3  

Propietarios  buscan  objetos   Objetos  buscan  propietarios   0  

Encontré   Perdí   1  

Se  buscan  objetos   Se  buscan  propietarios   0  

Encontré  objeto   Busco  objeto   2  

Objetos  que  han  sido  perdidos   Objetos  que  han  sido  encontrados   1  

Tabla  2,  Encuesta    

Page 114: Proyecto!Final!deCarrera BCNLook$&Find

   

113    

6 Gestión  del  proyecto  

En   esta   sección   se   expone   el   seguimiento   y   gestión   del   proyecto,   tiempo   empleado,   costes,  etc.  

6.1 Estimación  inicial  

En  primer  lugar  se  expone  la  estimación  inicial  de  la  duración  del  proyecto,  representada  en  el  diagrama  Diagrama  17,  Gantt  estimado,  que  se  muestra  a  continuación.  

 

Diagrama  17,  Gantt  estimado  

Como   puede   verse   en   este   diagrama   se   ha   desglosado   la   elaboración   del   proyecto   tareas  genéricas.  Para  cada  una  de  estas  tareas  se   indica   la  duración  en  semanas,  representada  por  una  franja  de  color  azul.  Cada  columna  denominada  por  una  “S”  y  un  valor  numérico  indica  la  semana  en  la  estima  llevar  a  cabo  esa  tarea.  A  continuación  se  muestran  las  tareas  en  las  que  se  ha  dividido  el  proyecto  y  cuanto  tiempo  (semanas)  se  estima  que  durarán.  Algunas  tareas  se  han  desarrollado  paralelamente,  esto  se  representa  solapando  las  franjas  de  color  azul.  

• Análisis   de   otros   sitios   web   2   semanas.   Teniendo   en   cuenta   la   documentación  correspondiente,  se  estiman  1,5  semanas.  

• Estudio  de  sistemas  de  gestión  de  contenido  2  semanas.  • Especificación  del  sistema  5  semanas.  • Estudio  del  sistema  de  gestión  de  contenido  escogido  4  semanas.  Teniendo  en  cuenta  

que   al   mismo   tiempo   se   lleva   a   cabo   la   tarea   de   especificación   y   se   comienza   el  desarrollo  con  su  correspondiente  documentación,  se  estima  1  semana.  

• Desarrollo   del   sistema   9   semanas.   Teniendo   en   cuenta   los   solapamientos   de   otras  tareas  se  contabilizan  realmente  8  semanas.  

o Creación  de  contenido  3  semanas.  o Edición  y  creación  de  plantillas  3  semanas.  o Desarrollo  de  extensiones  2  semanas.  

• Implantación  del   sistema  en  un   servidor  público.   Esta   tarea   se   realizará  en  3  puntos  diferentes  del  desarrollo  y  se  estima  que  en  total  implicará  5  horas.  

• Experimentación  1  semana.  • Documentación  9  semanas.  Teniendo  en  cuenta  que,  en  la  práctica,  esta  tarea  se  lleva  

a  cabo  de  manera  parcial  durante  el  transcurso  del  resto  de  las  tareas,  se  estima  que  realmente   requerirá   2   semanas   de   dedicación   neta   para   depurar   y   completar   la  memoria.  

Page 115: Proyecto!Final!deCarrera BCNLook$&Find

   

114    

Cada  una  de  las  semanas  del  diagrama,  están  compuestas  por  20  horas   laborables.  Teniendo  en   cuenta   la   normativa   de   PFC   de   la   FIB,   un   proyecto   de   ingeniería   técnica   en   informática  como  éste,  está  valorado  en  22,5  créditos,  con  una  carga  de  trabajo  de  20  horas  por  crédito.  La  duración  inicial  estimada  del  proyecto  es  de  460  horas.  Estas  horas  son  cubiertas  a  tiempo  parcial,  por  lo  tanto  se  prevé  una  duración  de  4  meses.  

A  continuación  se  describe  el  tipo  y  la  cantidad  de  recursos  asignados  a  cada  tarea,  utilizando  la  tabla  Tabla  3,  Recursos  estimados.  Para  las  tareas  que  van  a  llevar  a  cabo  más  de  un  recurso,  se   dividen   las   horas   asignadas   a   esa   tarea   entre   los   diferentes   recursos.   Se   debe   tener   en  cuenta   que   el   proyecto   es   llevado   a   cabo   por   una   sola   persona   que   adopta   todos   los   roles  necesarios.  Estos  roles  y  sus  costes  por  recurso  son  los  siguientes.  

• Analista  40  €  por  hora.  • Diseñador  35  €  por  hora.  • Desarrollador  25  €  por  hora.  

Puesto  que  no  ha  sido  posible  encontrar  una  fuente   fiable  en   Internet  que   indique  el  sueldo  medio   de   cada   tipo   de   recurso,   se   ha   optado   por   tomar   como   fuente   de   información   un  profesional   del   campo.   Estos   sueldos   han   sido   aconsejados   por   el   CTO   (Chief   Technology  Officer)  del  área  de  IT,  de  la  empresa  Privalia.  

• En   cada   una   de   las   tareas   participa   uno   o   varios   recursos   indicados   en   la   columna  “Recurso”.  

• La  cantidad  de  este  recurso  por  unidad  (personas),  se  indica  en  la  columna  “Cantidad”.  • El  número  de  semanas  que  cada  recurso  empleará  en  la  tarea  se  indica  en  la  columna  

“Semanas”.  • El  número  de  horas  que  cada   recurso  empleará  en   la   tarea,   teniendo  en  cuenta  que  

cada  semana  dispone  de  20  horas  laborables,  se  indica  en  la  columna  “Horas”.  • El  precio  por  hora  en  euros  €  que  cuesta  cada  recurso  asignado  en  la  tarea  se  indica  en  

la  columna  “Precio  por  hora”.  • Por   último   se   indica   en   la   columna   “Coste”   el   coste   total   del   recurso   en   esa   tarea  

(Coste  =  Cantidad  *  Precio  por  hora  *  Horas).  

 

Tabla  3,  Recursos  estimados  

Page 116: Proyecto!Final!deCarrera BCNLook$&Find

   

115    

El  coste  total  estimado  para  el  proyecto  se  calcula  sumando  los  costes  totales  de  cada  tarea  y  asciende  a  15.025,00  €,  como  puede  verse  al  final  de  la  columna  “Coste”.  

6.2 Resultado  final  

La   estimación   se   ha   visto   afectada   por   la   duración   real   de   cada   una   de   las   tareas,   recursos  reales   asignados,   etc.   El   diagrama   Diagrama   18,   Gantt   real,   que   se  muestra   a   continuación  muestra  la  duración  real  del  proyecto  y  las  horas  empleadas  en  cada  una  de  las  tareas.  

 

Diagrama  18,  Gantt  real  

Como  puede  verse,  la  duración  real  del  proyecto  ha  sido  más  larga  de  la  estimada  inicialmente.  Los  4  meses  laborables  estimados  han  pasado  a  ser  8  meses.  Esto  provoca  un  aumento  de  las  horas   asignadas   a   cada   uno   de   los   recursos   y   por   lo   tanto   un   aumento   del   coste   total   del  proyecto.  

El  tiempo  final  empleado  para  cada  una  de  las  tareas  es  el  siguiente.  

• Análisis  de  otros  sitios  web  2  semanas.  • Estudio  de  sistemas  de  gestión  de  contenido  2,5  semanas.  • Especificación  del  sistema  8  semanas.  • Estudio   del   CMS   eZ   Publish   12   semanas.   Teniendo   en   cuenta   que   esta   tarea   se   ha  

llevado  a  cabo  a  la  par  con  el  desarrollo  del  sistema,  solo  se  contabilizan  3  semanas.  • Desarrollo   del   sistema   17   semanas.   Teniendo   en   cuenta   el   solapamiento   con   otras  

tareas  finalmente  se  contabilizan  10  semanas,  que  se  desglosan  en  las  siguientes  sub-­‐tareas.  

o Creación  de  contenido  2  semanas.  o Edición  y  creación  de  plantillas  4  semanas.  o Desarrollo  de  extensiones  3  semanas.  

• Implantación  del  sistema  en  un  servidor  público  6  horas.  • Experimentación  8  semanas.  Realmente  se  han  contabilizado  2  semanas.  • Documentación   25   semanas.   Como   se   ha   comentado   anteriormente,   parte   de   la  

documentación  ha   estado   sumergida   en   la   realización  del   resto  de   las   tareas.   Por   lo  tanto,  realmente,  ha  requerido  un  total  de  4  semanas  de  dedicación  completa.  

La  causa  de  la  desviación  de  respecto  a  la  estimación  se  centra  en  las  tareas  de  especificación  del   sistema,  estudio   del   CMS   eZ   Publish   y  desarrollo   del   sistema.   Como   se   ha   comentado  anteriormente   el   CMS   seccionado,   por   razones   expuestas   en   la   Sección   2.3,   requería   un  aprendizaje  más  costoso.  Es  por  esta  razón  que  su  estudio  a  requerido  de  más  tiempo  y  por  lo  tanto  también  ha  implicado  un  incremento  de  horas  de  desarrollo.  

Page 117: Proyecto!Final!deCarrera BCNLook$&Find

   

116    

La   metodología   ágil   que   se   ha   seguido   para   el   desarrollo   del   sistema   y   sus   consecutivas  iteraciones,  además  de  un  incremento  en  el  desarrollo,  también  han  provocado  un  incremento  de  horas  en  la  especificación  del  sistema.  

Por  supuesto  un   incremento  del  tiempo  dedicado  a  estas  tareas   implica  un   incremento  en   la  documentación.  

Otras   tareas   como   la  experimentación   también  han  contribuido  en   la  desviación  del   tiempo  estimado,  pero  en  menor  medida.  En  el  caso  de  la  experimentación  se  han  llevado  a  cabo  un  mayor   número   de   pruebas   de   usuario   y   esto   también   ha   provocado   iteraciones,  incrementando  el  desarrollo.  

La   tarea   de   implantación   finalmente   se   llevó   a   cabo   en   más   puntos   del   desarrollo   de   los  estimados,  además  su  desempeño  fue  más  costoso  del  esperado  y  por   lo   tanto  requirió  más  tiempo.  Otro  factor  que  afectó  a  esta  tarea  fue   la  migración  del  sistema  del  servidor  privado  de   la   FIB   al   servidor   público   del   LSI   para   llevar   a   cabo   una   fase   de   experimentación   más  completa.  A  pesar  de  ello,  solo  se  ha  contabilizado  1  hora  más  respecto  a  la  estimación,  ya  que  estas  tareas  de  implantación  se  ha  realizado  durante  el  desarrollo  del  sistema.  

En  la  tabla  Tabla  4,  Recursos  reales,  expuesta  a  continuación,  se  muestran  las  horas  reales  que  ha  costado  cada  recurso  en  cada  una  de  las  tareas.  El  formato  de  la  tabla  es  el  mismo  que  el  antes  expuesto.  

 

Tabla  4,  Recursos  reales  

De  la  misma  manera  que  se  ha  calculado  el  coste  total  estimado  de  cada  una  de  las  tareas,  se  ha  obtenido  el  coste  total  real  de  cada  una  de  las  tareas  (Coste   real  =  Cantidad  *  Precio  por  hora  *  Horas   reales).  Teniendo  en  cuenta  el   incremento  de  horas  por  tarea  estos  costes  han  ascendido  de  los  reales.  

Una  vez  obtenidos  los  costes  reales  de  cada  una  de  las  tareas,  se  han  sumado  y  obtenido  así,  el  coste  total  real  del  proyecto  que  asciende  a  19.750,00  €.  

   

Page 118: Proyecto!Final!deCarrera BCNLook$&Find

   

117    

7 Conclusiones  

Una  vez  desarrollado  el  sistema  BCN  Look  &  Find,  después  de  haber  experimentado  con  él  y  de  haber  llevado  a  cabo  mejoras,  arreglos,  cambios  y  de  evaluar  los  resultados  obtenidos,  pueden  extraerse  las  siguientes  conclusiones.  

El  propósito  general  del  proyecto  consistía  en  desarrollar  una  plataforma  web  con  la  finalidad  de   hacer   de   intermediario   entre   personas   que   pierden   y   encuentran   objetos   perdidos   en   la  provincia  de  Barcelona  y  alrededores  y  facilitar  a  centros  donde  se  depositan  objetos  perdidos,  la  labor  de  devolverlos  a  sus  propietarios.  Si  se  analiza  el  sitio  web,  actualmente  en  versión  alfa  ubicado  en  http://look-­‐and-­‐find.lsi.ucp.edu/,  se  puede  afirmar  que  se  ha  cumplido  el  objetivo  principal   en   su   totalidad.   El   sistema   contiene   funcionalidades   que   permiten   llevar   a   cabo   el  objetivo  de  permitir  a  usuarios   interactuar  con  el   sistema  y  ponerse  en  contacto  entre  ellos.  Por   supuesto   también   se  han   tenido  muy  en   cuenta   los  defectos  extraídos  de   los   sitios  web  analizados   y   como   puede   verse   no   se   dan   en   este   sistema.   Una   de   las   aportaciones   más  importantes  de  este  proyecto  ha  sido  la  incorporación  de  usuarios  de  tipo  centro  en  este  tipo  de   plataforma   web,   con   el   objetivo   de   facilitar   a   dichos   centros   que   custodian   objetos  perdidos,  devolverlos  a  sus  propietarios.  Puede  verse  que  se  han  incluido  funcionalidades  que  facilitan   esta   labor,   a   pesar   de   que   no   ha   sido   posible   que   pasen   por   una   fase   de  experimentación  profunda,  tal  y  como  se  planificó  inicialmente.  

Respecto  a  conclusiones  técnicas,  el  desarrollo  del  sistema  BCN  Look  &  Find  sobre  un  gestor  de  contenidos  ha  sido  mas  complicado  de  lo  esperado.  El  sistema  eZ  Publish  seleccionado,  aporta  grandes   ventajas   respecto  a  otros  CMS,   como   la   libertad  a   la  hora  de   crear  nuevos   tipos  de  contenido,  con  una  gran  diversidad  de  atributos.  Por  otra  parte  también  conlleva  desventajas  como  la  gran  complejidad  del  sistema  y  la  necesidad  de  editar  constantemente  el  código,  entre  otros.  En  conclusión  eZ  Publish  es  muy  recomendable  para  usuarios  avanzados,  con  el  objetivo  de  construir  una  plataforma  web  con  funcionalidades  complejas  que  se  salen  de  lo  habitual  en  un  sitio  web  implementado  sobre  un  gestor  de  contenidos.  Por  otra  parte  la  utilización  de  un  gestor  de  contenidos  en  general,  facilita  la  creación  de  la  estructura  de  un  sitio  web  de  manera  rápida,   al  menos   cuando   ya   se   conoce   el   funcionamiento   del   CMS.   Y   sobretodo   facilita   que  otros   usuarios   puedan   administrar   el   sitio   web   de   manera   fácil   una   vez   terminado   el  desarrollo.  

Como  ya   se  ha   comentado,   se  han   cumplido   los  objetivos  previstos   inicialmente,   a  pesar  de  ello   hay   varios   aspectos   funcionales   y   de   diseño,   que   ha   sido   necesario   excluir   de   los  requerimientos   del   proyecto   por   falta   de   tiempo,   pero   que   podrían   mejorar   el   sistema   y  reforzar   el   cumplimiento   de   dichos   objetivos   a   la   par   de   llegar   a   otros.   Algunos   de   estos  aspectos  se  describen  como  posibles  extensiones  futuras  en  la  siguiente  sección.  

   

Page 119: Proyecto!Final!deCarrera BCNLook$&Find

   

118    

8 Propuestas  de  trabajo  futuro  

Cuando   se   inició   el   desarrollo   del   proyecto   se   planteó   tratar   los   temas   de   personas  desaparecidas   y   mascotas   perdidas,   pero   en   seguida   nos   dimos   cuenta   que   eran   temas  demasiado   delicados,   que   podían   herir   la   sensibilidad   de   algunos   usuarios   y   que   por   tanto  merecían  un  tratamiento  especial.  El  proponer  soluciones  para  el  tratamiento  de  estos  temas  es  una  posible  e  interesante  extensión  del  sistema  BCN  Look  &  Find.  

En  discusiones   iniciales  y  después  de  analizar  otros  sitios  web,   se  observó  que  para  que  una  plataforma  como  ésta   fuera  útil,  debía  abarcar  un  área  geográfica  bien  delimitada,   ya  que  a  nivel  mundial  es  un  servicio  que  no  tiene  sentido.  Sin  embargo,  es  una  extensión  interesante  que  requiere  de  un  análisis  en  el  que  se  deben  tener  en  cuenta  varios  aspectos  funcionales  y  de  usabilidad.  

Es   muy   importante   que   a   pesar   de   expandir   el   área   a   un   país   entero,   las   estadísticas,   los  usuarios,  objetos,  top  ten  y  otros  recursos  del  sitio  web,  continúen  siendo  útiles.  Por  ejemplo  un   top   ten   de   usuarios   de   toda   España   no   sería   demasiado   representativo,   lo   lógico   sería  aplicar   la   zona     seleccionada   por   el   usuario   a   todos   los   elementos   del   sitio   a   sobre   los   que  pueda  hacer  uso.  El  sitio  web  Finder  Base  (25)  expuesto  anteriormente  es  un  claro  ejemplo  de  lo   que   no   se   debe   hacer.   Finder   Base   (25)   generaliza   todo   el   contenido   del   sitio   web,   de  manera  que  muchas  funcionalidades  interesantes  dejan  de  ser  útiles  para  el  usuario,  como  el  top  ten  (mundial),  el  mapa  del  mundo  de  la  página  principal  que  marca  la  ubicación  de  todos  los  objetos  registrados  en  el  sito,  etc.  

Una  buena  manera  de  ubicar  al  usuario  en  una  zona  geográfica  es   la  que  utiliza  el   sitio  web  Megalost   (26),   también  expuesto   al   inicio  del   documento.   Inicialmente   se  muestra  un  mapa  mundial   al   usuario   sobre   el   que   puede   seleccionar   un   país,   después   una   comunidad   y   por  último  una  ciudad.  Estos  datos  se  guardan  y  la  próxima  vez  que  el  usuario  acceda  al  sitio  web,  se   le  ubicará  en   la   zona  anteriormente   seleccionada.  Una  aplicación  web  que  puede   ser  útil  investigar   es   el   conocido   Google   Maps   (46).   Google   Maps   detecta   automáticamente   la  ubicación   del   usuario   y   siempre   la  muestra   por   defecto,   pero   en   todo  momento   el   usuario  tiene  la  posibilidad  de  modificarla  e  incluso  tener  un  registro  de  ubicaciones  favoritas.  

Este  tipo  de  extensión  lleva  a  pensar  en  una  extensión  mayor.  

En  mi  opinión,  no  es  recomendable  expandir  el  área  de  actuación  del  sitio  web  a  objetos  de  todo   el   mundo.   Es   posible   que   al   intentar   abarcar   tanto   territorio   se   pierda   precisión   y  utilidad.   Finder   Base   (25)   es   un   ejemplo   de   ello,   muchos   de   los   objetos   registrados   llevan  mucho  tiempo  y  se  ve  poca  interacción  con  el  sitio  web.  

A   pesar   de   ello   si   se   tienen   en   cuenta   algunos   aspectos   podría   funcionar.   Como   ya   se   ha  comentado   en   la   extensión   a   otras   ciudades,   es   necesario   concretar   en   todo  momento   una  ubicación  tanto  cuando  el  usuario  busca  o  registra  un  objeto,  como  cuando  está  visualizando  otros  datos,  siempre  deben  estar  relacionados  con  una  ubicación  concreta.  

Page 120: Proyecto!Final!deCarrera BCNLook$&Find

   

119    

Ya  son  muchos  los  sitios  web  de  contactos  que  incluyen  mensajería  privada,  como  por  ejemplo  el  conocido  Facebook   (41).  Esta  aplicación   incluye   la  posibilidad  de  enviar  mensajes  privados  sin  necesidad  de  utilizar  ningún  tipo  correo  electrónico  externo.  Incluyendo  esta  funcionalidad  en   BCN   Look   &   Find,   facilitaría   el   contacto   entre   usuarios.   Es   lógico   pensar   que   algunos  usuarios  pudieran  llegar  a  escoger  no  utilizar  el  sitio  web,  por  la  necesidad  de  dar  su  dirección  de  correo  electrónico  y  de  que   la   forma  de  contactar  con  otros   sea  mediante  esta   forma  de  correo.  Esta  es  una  razón  importante  porque  sería  muy  conveniente  incluir  esta  extensión  en  un  futuro.  

Este  tipo  de  extensión  puede  ir  acompañada  de  otra  no  tan  necesaria,  pero  interesante.  

De   la  misma  manera  que   la  mensajería   interna  privada,   se  podría  disponer  de  un   chat.   Esta  extensión  también  facilitaría  a  los  usuarios  el  contacto  entre  ellos  y  por  lo  tanto  la  devolución  de  un  mayor  número  de  objetos  a  sus  propietarios.  

A  pesar  de  ser  un  complemento  interesante,  se  deben  tener  en  cuenta  algunos  aspectos.  Para  empezar   no   estamos   hablando   de   un   sitio  web   de   amistades,   contactos,   etc.,   lo   que   quiere  decir   que   se   debe   limitar   la   libertad   de   chatear   con   cualquier   usuario.   Cuando   un   usuario  desee   entablar   conversación   con   otro   usuario,   éste   segundo   debe   tener   la   libertad   de   no  permitir   el   contacto.   Lo   siguiente   a   tener   en   cuenta   es   cómo  mostrar   los   usuarios   al   resto,  cómo  entablar  conversación  y  cómo  se  sabe  si  un  usuario  está  en  ese  momento  visitando  el  sitio  web.  Existen  dos  posibles  opciones  a  priori.  

• En   todo   rincón   del   sitio  web  donde   se  muestran   nombres   y   fotografías   de   usuarios,  incluir  un  icono  que  indique  si  el  usuario  está  en  línea  o  no.  Al  entrar  en  su  perfil  dar  la  posibilidad   al   usuario   de   crear   una   conversación   mediante   chat.   Esta   funcionalidad  permitiría  al  usuario  en  curso  entablar  conversación   inmediata  con  el  usuario  que  ha  registrado  cualquier  objeto  que  le  llame  la  atención.  

• Otra   opción   sería   similar   a   la   funcionalidad   de   chats   de   otros   sitios  webs   como   por  ejemplo  Facebook   (41).  Se  permitiría  al  usuario  agregar  a  otros  usuarios  utilizando  el  concepto   “amigo”   o   “favorito”.   Cuando   el   usuario   se   identificara   en   el   sitio  web,   en  algún  apartado  siempre  visible  se  mostraría  su   lista  de  “favoritos”  y   la  posibilidad  de  entablar   conversación   con   ellos.   Por   supuesto   los   usuarios   tendrían   la   libertad   de  rechazar  las  peticiones  de  inclusión  en  listas  de  “favoritos”  que  se  les  hiciera.  

Como  se  ha  podido  ver  a  lo  largo  del  proyecto,  el  sistema  BCN  Look  &  Find  está  pensado  para  facilitar   la   interacción   entre   usuarios   o   centros,   para   que   posteriormente   ellos   mismos  contacten   y   se   recuperen   sus   pertenencias   personalmente.   Es   posible   que  muchos   usuarios  prefieran  preservar  su  anonimato  e  incluso  esto  provoque  que  no  utilicen  el  sitio  web.  

Un  modo  de  solucionar  este  problema  y  captar  más  usuarios  sería  el  de  facilitar  a  los  usuarios,  desde  el  sitio  web,  el  envío  de  los  objetos  a  sus  propietarios,  utilizando  algún  tipo  de  empresa  de  mensajería  o  transporte,  como  Correos,  MRW,  SEUR,  etc.  

Una   extensión   que   también   podría   ser   interesante   es   la   incorporación   nuevas   estadísticas,  obtenidas  a  partir  de  la  información  de  los  objetos  registrados.  Un  ejemplo  de  información  que  

Page 121: Proyecto!Final!deCarrera BCNLook$&Find

   

120    

se   podría   obtener   a   partir   de   estas   estadísticas   es   las   zonas   donde   se   suelen   perder   una  cantidad  mayor  de  objetos.  

Para  terminar  cabe  mencionar  uno  de   los  aspectos  más   importantes  del  sistema  BCN  Look  &  Find,   la   gestión   de   objetos   perdidos   depositados   en   centros.   Como   se   ha   comentado  anteriormente  en   la  Sección  5,  no  ha  sido  posible   llevar  a  cabo  una  fase  de  experimentación  con  centros  como  la  que  se  hubiera  deseado.  A  pesar  de  ello  se  ha  recibido  algún  comentario  en  el  que  se  expresaba  la  preocupación  a  la  hora  de  registrar  objetos  de  tipo  documentación  que  contienen  datos  personales  del  propietario  del  objeto.  Sería  interesante  implantar  alguna  mejora  en  este  aspecto,  para  tener  controlada  dentro  de  lo  posible,  la  privacidad  del  usuario.  Una  posibilidad  sería  la  de  modificar  automáticamente  el  formulario  de  registro  de  objetos  en  el  momento  que   se   selecciona   la   categoría  documentación  e   incluir  nuevos  campos  como  el  tipo  de  documentación  a  registrar  y  otros  dependiendo  de  éste,  así  guiar  al  usuario  e  intentar  evitar  el  registro  de  datos  privados.  

Por  supuesto,  puesto  que   las  plataformas  web  están  en  constante  cambio  y  mejora,  siempre  es  posible  mejorar  su  usabilidad,  accesibilidad,  diseño,  seguridad,  posicionamiento  SEO,  etc.  

Bibliografía  

1.  Vila,  Iván.  La  Oficina  de  Hallazgos  de  Barcelona  devuelve  a  sus  propietarios  el  86%  de  los  objetos  perdidos  que  le  llegan.  La  Vanguardia.  [En  línea]  7  de  Febrero  de  2011.  http://www.lavanguardia.com/vida/20110207/54110648163/la-­‐oficina-­‐de-­‐hallazgos-­‐de-­‐barcelona-­‐devuelve-­‐a-­‐sus-­‐propietarios-­‐el-­‐86-­‐de-­‐los-­‐objetos-­‐perdidos-­‐que.html#.Tnb9S8WGCzg.email/.  

2.  Wikipedia.  Web  2.0.  Wikipedia.  [En  línea]  13  de  Diciembre  de  2010.  http://es.wikipedia.org/wiki/Web_2.0.  

3.  —.  URL.  Wikipedia.  [En  línea]  12  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/Localizador_uniforme_de_recursos.  

4.  Factoría  de  Internet  S.L.  WebTaller  Formularios  HTML.  WebTaller.  [En  línea]  2011.  http://www.webtaller.com/construccion/lenguajes/html/lecciones/formularios_html.php.  

5.  Wikipedia.  Posicionamiento  en  buscadores.  Wikipedia.  [En  línea]  23  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/Posicionamiento_en_buscadores.  

6.  Costal,  Dolors,  y  otros,  y  otros.  Enginyeria  del  Software  Especificació.  Edicions  UPC.  Barcelona  :  s.n.,  2005.  84-­‐8301-­‐799-­‐7.  

7.  Barcelona  Activa  Cibernàrium.  Arquitectura  de  la  informació:  Granteix  una  bona  experiència  d'usuari.  Cibernàrium.  [En  línea]  2011.  http://www.cibernarium.cat/cibernarium/cat/index.jsp.  

8.  Wikipedia.  PHP.  Wikipedia.  [En  línea]  28  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/PHP.  

Page 122: Proyecto!Final!deCarrera BCNLook$&Find

   

121    

9.  PHP  Group.  PHP.  PHP.  [En  línea]  30  de  Diciembre  de  2011.  http://www.php.net/.  

10.  Wikipedia.  HTML.  Wikipedia.  [En  línea]  16  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/HTML.  

11.  W3Schools.  HTML  Tutorial.  W3Schools.  [En  línea]  2011.  http://www.w3schools.com/html/.  

12.  Wikipedia.  JavaScript.  Wikipedia.  [En  línea]  13  de  Noviembre  de  2011.  http://es.wikipedia.org/wiki/JavaScript.  

13.  W3Schools.  JavaScript  Tutorial.  W3Schools.  [En  línea]  2011.  http://www.w3schools.com/js/.  

14.  Wikipedia.  Hojas  de  Estilo  en  Cascada.  Wikipedia.  [En  línea]  23  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/Hojas_de_estilo_en_cascada.  

15.  Shea,  Dave.  Zend  Garden.  Zend  Garden.  [En  línea]  2012.  http://www.csszengarden.com/.  

16.  Wikipedia.  JQuery.  Wikipedia.  [En  línea]  16  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/JQuery.  

17.  The  JQuery  Project.  JQuery.  JQuery.  [En  línea]  2010.  http://jquery.com/.  

18.  Wikipedia.  AJAX.  Wikipedia.  [En  línea]  30  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/AJAX.  

19.  —.  Extensible  Markup  Language.  Wikipedia.  [En  línea]  18  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/Extensible_Markup_Language.  

20.  —.  Sistema  de  Gestión  de  Contenidos.  Wikipedia.  [En  línea]  13  de  Diciembre  de  2011.  http://es.wikipedia.org/wiki/Sistema_de_gestión_de_contenidos.  

21.  Drupal.  Drupal.  Drupal.  [En  línea]  http://drupal.org/.  

22.  eZ  Systems  AS.  eZ  Publish.  eZ  Publish.  [En  línea]  2011.  http://ez.no.  

23.  Open  Source  Matters,  Inc.  Joomla.  Joomla.  [En  línea]  2012.  http://www.joomla.org.  

24.  WordPress.  WordPress.  WordPress.  [En  línea]  http://wordpress.org/.  

25.  Finder  Base.  Finder  Base.  Finder  Base.  [En  línea]  http://www.finderbase.com/.  

26.  Grupo  Enobras  Networks,  S.L.  Megalost.  Megalost.  [En  línea]  2012.  http://megalost.com/.  

27.  Wikifinding  -­‐  Community  Search.  Wikifinding.  Wikifinding.  [En  línea]  2012.  http://www.wikifinding.com/.  

28.  Objetos  Perdidos.  Objetos  Perdidos.  Objetos  Perdidos.  [En  línea]  http://objetosperdidos.org/.  

29.  Lost  Objects  Community.  Lost  Objects  Community.  Lost  Objects  Community.  [En  línea]  http://www.lostobjectscommunity.com/.  

Page 123: Proyecto!Final!deCarrera BCNLook$&Find

   

122    

30.  Oomia.  Oomia.  Oomia.  [En  línea]  2007.  http://www.oomia.com/.  

31.  Transports  Metropilitans  de  Barcelona,  TMB.  Objectes  Perduts.  Transports  Metropilitans  de  Barcelona,  TMB.  [En  línea]  2011.  http://www.tmb.cat/es/objectes-­‐perduts/.  

32.  Institut  Metropolità  del  Taxi.  Institut  Metropolità  del  Taxi.  Institut  Metropolità  del  Taxi.  [En  línea]  2006.  http://www.taxibarcelona.cat/tabid/904/Default.aspx/.  

33.  AVE.  AVE.  AVE.  [En  línea]  http://ave-­‐renfe.edreams.es/general/objetos-­‐perdidos-­‐en-­‐el-­‐ave/..  

34.  eZ  Systems  AS.  eZ  Publish  Documentation.  eZ  Publish.  [En  línea]  2011.  http://doc.ez.no/.  

35.  Marie  Skaara,  Bergfrid.  eZ  Publish  Advanced  Content  Management.  [ed.]  Peter  Keung.  United  States  :  Zickerman,  Jennifer,  2008.  978-­‐82-­‐92792-­‐05-­‐1.  

36.  Halasy,  Balazs.  eZ  Publish  Basics.  [ed.]  Jennifer  Zickerman.  Norway  :  s.n.,  2006.  978-­‐82-­‐92797-­‐00-­‐9.  

37.  eZ  Systems  AS.  eZ  Publish  Enterprise  Tour.  2010.  

38.  eZ  Systems.  Share  eZ  Publish  Downloads.  Share  eZ  Publish.  [En  línea]  2010.  http://share.ez.no/download-­‐develop/downloads/ez-­‐publish-­‐4.3/.  

39.  —.  Share  eZ  Publish  Forum.  Share  eZ  Publish.  [En  línea]  2010.  http://share.ez.no/forums/developer/.  

40.  JACSYSTEME.  Ez  publish  3.*  Tutorial  Introducción  en  el  desarrollo  de  extensiones  en  eZ  Publish.  Ez  publish  3.*  Tutorial  Introducción  en  el  desarrollo  de  extensiones  en  eZ  Publish.  [En  línea]  2007.  www.jac-­‐systeme.de.  

41.  Facebook.  Facebook.  Facebook.  [En  línea]  2012.  https://www.facebook.com/.  

42.  Google.  Webmasters.  Google.  [En  línea]  2011.  http://www.google.es/webmasters/.  

43.  SeoWeb.  Tutorial  Completo  Sitemap.  Consultor  SEO  Freelance|  Experto  posicionamiento  web.  [En  línea]  31  de  Mayo  de  2011.  http://seowebconsultor.com/2011/05/31/tutorial-­‐completo-­‐sitemap-­‐xm/.  

44.  Duch,  Amalia,  Pasarella,  Edelmira  y  Santiso,  David.  BCN  Look  &  Find.  Facebook.  [En  línea]  2012.  https://www.facebook.com/pages/BCN-­‐Look-­‐Find/125525917548242.  

45.  Google.  Google  Maps.  Google  Maps.  [En  línea]  2011.  http://maps.google.es/.  

   

Page 124: Proyecto!Final!deCarrera BCNLook$&Find

   

123