\chapter{Análisis de las aplicaciones Web y Android}
-A lo largo de esta primera sección se intentará explicar de forma detallada todos los requisitos y los casos de uso de las dos aplicaciones de las que se compone este proyecto fin de carrera: la aplicación web y la aplicación basada en Android.
+A lo largo de esta primera sección se intentará explicar de forma detallada todos los requisitos y los casos de uso de las dos aplicaciones de las que se compone este proyecto fin de carrera: la aplicación web y la aplicación basada en Android. Pero antes de seguir adelante pasaremos a describir el sistema que se desea implementar.
+
+\section{Descripción del sistema}
+
+Como fue explicado previamente en el capítulo de introducción, el sistema a desarrollar consta de dos aplicaciones:
+
+\begin{enumerate}
+ \item Aplicación Web: que permite a usuarios con privilegios suficientes (los llamaremos ``usuarios empresa'') crear y administrar sus anuncios, localizarlos geográficamente, asociarlos a una determinada categoría, etc. Por otro lado, a esta misma aplicación Web accederán usuarios con menos permisos (los llamaremos ``usuarios normales'') y que únicamente pueden asociarse a categorías existentes en el sistema y no pueden crear ni editar anuncios creados previamente por un ``usuario empresa''.
+ \item Aplicación Android: usada por aquellos ``usuarios normales'' que se asociaron previamente a categorías a través de la aplicación Web citada previamente. Esta aplicación permitirá la recepción de anuncios relacionados con las categorías que el usuario eligió vía interfaz Web y que se encuentran geográficamente en la posición actual del mismo usuario. Para lograrlo, la aplicación Android deberá comunicar su posición actual a la aplicación Web y en función de dicha posición la aplicación Web responderá o no con unos determinados resultados (un listado de anuncios)
+\end{enumerate}
+
+Desde la aplicación Web podrán llevarse a cabo las siguientes tareas:
+
+\begin{itemize}
+ \item Registro automático de nuevos usuarios vía Web.
+ \item Un usuario con el rol ``usuario empresa'' puede editar sus propios datos así como los datos de la empresa que gestiona o administra en el sistema Web.
+ \item El ``usuario empresa'' podrá crear nuevas sucursales u oficinas pertenecientes a la empresa que él o ella administran en el sistema. Se debe por tanto facilitar la edición y creación de nuevas sucursales/oficinas así como el listado de las que actualmente existan en el sistema y pertenezcan a un determinado usuario.
+ \item Las oficinas/sucursales pueden tener anuncios asociados, es decir, si en una oficina o sucursal se vende un determinado producto y existe un anuncio en el sistema para ese producto, el ``usuario empresa'' si lo desea puede asociar dicho anuncio con la oficina/sucursal y así con tantos anuncios y sucursales como se quiera. La única restricción es que tanto las sucursales como los anuncios deben pertenecer al ``usuario empresa'' que los está administrando.
+ \item Las oficinas/sucursales pueden encontrarse localizadas geográficamente (si el ``usuario empresa'' lo desea), por tanto es necesario añadir una funcionalidad al interfaz de administración Web que permita introducir como dato las coordenadas GPS para una oficina o sucursal.
+ \item Existirá un listado con todos los anuncios que un determinado ``usuario empresa'' ha creado y gestiona. Desde este listado, como ocurría con el interfaz para oficinas/sucursales se deberá poder editar, borrar y crear nuevos anuncios. Es importante recalcar que todo anuncio puede tener una posición geográfica asociada a él (como ocurría con las oficinas/sucursales) También los anuncios pueden ser asociados con categorías previamente creadas por el mismo ``usuario empresa''. De forma obligatoria, un anuncio deberá tener una imagen asociada con él; esta imagen se usará posteriormente en la aplicación Android y por tanto desde la aplicación Web se restringirá el tamaño máximo de las imágenes relacionadas con los anuncios que el ``usuario normal'' finalmente recibirá.
+ \item Se deber permitir introducir la información relacionada con anuncio en diferentes idiomas, de esta forma el mismo anuncio puede ser visto por público que entiende diferentes lenguajes.
+ \item Por último el ``usuario empresa'' deberá poder editar o introducir nuevas categorías propias que se ordenarán jerárquicamente según los gustos del ``usuario empresa''. Estas categorías se asocian con categorías genéricas que existen previamente en el sistema y que todos los ``usuario empresa'' y ``usuarios normales'' pueden ver. El interfaz Web proporcionará (al igual que se hizo con los anuncios y las oficinas/sucursales) un listado jerárquico (la jerarquía es creada por el ``usuario empresa'') con todas las categorías que pertenecen a un determinado ``usuario empresa''.
+ \item Los ``usuarios normales'' únicamente podrán editar sus datos y asociarse a categorías genéricas. De este modo, cuando el usuario envíe su posición geográfica actual desde su dispositivo móvil, recibirá anuncios relacionados con esas categorías de interés para él o ella. Se proporcionará un interfaz que liste jerárquicamente las categorías genéricas que existan por defecto en el sistema. Se puede ver por tanto que aunque para el ``usuario empresa'' era opcional tanto asociar un anuncio con una categoría propia como asociar esta categoría propia con una categoría genérica del sistema; si no lleva a cabo estas asociaciones, el usuario con el rol ``normal'' nunca podrá recibir los anuncios creados por ese ``usuario empresa''.
+\end{itemize}
+
+La aplicación Android tendrá las siguientes funcionalidades:
+
+\begin{itemize}
+ \item Deberá permitir que el ``usuario normal'' haga ``log in'' en la aplicación Web a través del interfaz Andorid. Para ello pueden usarse por ejemplo servicios Web. Es necesarios que el usuario haga previamente ``log in'' en el servidor remoto para poder recibir nuevos anuncios desde este servidor basados en su posición geográfica.
+ \item Se facilitará al usuario un listado con los anuncios descargados previamente y que se encuentran almacenados en la memoria permanente del dispositivo móvil. Desde este listado el usuario puede leer los anuncios descargados y borrarlos si lo desea.
+ \item Existirá un menú de \emph{settings}, donde el usuario podrá seleccionar diferentes opciones relacionadas con la aplicación Android (tasa de actualización de la posición geográfica actual, consumo de batería, activación desactivación de la recepción de nuevos anuncios, etc)
+ \item La aplicación deberá recibir los anuncios en segundo plano, de tal forma que incluso cuando el usuario ha salido de la aplicación la recepción de anuncios continuará activa mientras el usuario lo quiera (se activa y desactiva mediante el menú \emph{settings} descrito en el punto anterior)
+ \item Notificación de la recepción de nuevos anuncios en la barra de tareas de Android. Al pulsar sobre la notificación el usuario podrá (si lo desea) abrir una ventana emergente o \emph{pop up} que le permitirá ver los nuevos anuncios recibidos así como borrarlos si lo desea.
+\end{itemize}
\section{Análisis de requisitos}
\subsubsection{Definir el formato de mensajes para las operaciones}
-Como primer paso para desarrollar un servicio Web, se debe definir el formato de los mensajes XML de cada operación. Se necesita describir las estructuras específicas de los mensajes para que los clientes puedan saber qué mensaje enviar al servicio y qué mensaje esperar desde el servicio. En nuestro caso, el servicio Web\footnote{Por simplicidad se decidió un diseño con un solo servicio Web, si bien hubiera sido más adecuado crear dos servicios Web REST. El primer servicio retornaría una lista con URLs a anuncios concretos (por ejemplo en función de su ID) donde a su vez un segundo servicio Web REST que estuviera escuchando retornaría los datos de cada uno de esos anuncios.} tendrá un único mensaje de salida (\emph{output}).
+Como primer paso para desarrollar un servicio Web, se debe definir el formato de los mensajes XML de cada operación. Se necesita describir las estructuras específicas de los mensajes para que los clientes puedan saber qué mensaje enviar al servicio y qué mensaje esperar desde el servicio. En nuestro caso, el servicio Web\footnote{Por simplicidad se decidió un diseño con un solo servicio Web, si bien hubiera sido más adecuado crear dos servicios Web REST. El primer servicio usando las coordenadas GPS retornaría una lista con URLs a anuncios concretos (por ejemplo en función de su ID) donde a su vez un segundo servicio Web REST que estuviera escuchando retornaría los datos de cada uno de esos anuncios.} tendrá un único mensaje de salida (\emph{output}).
WSDL 2.0 soporta múltiples tipos de sistemas para la descripción del contenido de los mensajes, pero el esquema XML es el único que se usa. Para el caso particular de este proyecto, se debe crear el siguiente mensaje de salida:
projects / PFCLatex / .git / commitdiff