Académique Documents
Professionnel Documents
Culture Documents
1
Agradecimientos
2
Índice
1. Descripción de la empresa ..................................................................... 4
2. Ubicación del proyectante dentro de la empresa ................................... 5
3. Descripción del trabajo realizado ........................................................... 7
3.1. Objetivos del proyecto ..................................................................... 7
3.2. Especificaciones del proyecto .......................................................... 7
3.3. Diseño .............................................................................................. 8
3.4. Desarrollo ........................................................................................ 9
3.5. Evaluación ...................................................................................... 17
3.6. Recursos utilizados ......................................................................... 19
4. Aportaciones del proyecto a los conocimientos del alumno................. 20
5. Aportaciones de los estudios realizados al proyecto ............................ 21
6. Conclusiones ........................................................................................ 22
3
1. Descripción de la empresa
4
2. Ubicación del proyectante dentro de la empresa
Después de una entrevista inicial por teléfono con Jordi Compte, jefe de proyecto y
cofundador de “SmartOxide”, decidí que su empresa podía ser un buen lugar para
acabar el proyecto de final de carrera dado que mi intención era la de hacer una
aplicación web con PHP y era lo que ellos estaban buscando.
El primer día en la oficina conocí a Eusebi que sería mi compañero de trabajo durante
los próximos meses y a los demás colaboradores que estaban trabajando en el otro
proyecto de la empresa.
El proyecto que ambos teníamos que realizar conjuntamente se puede dividir en dos
partes bien diferenciadas. Por un lado una aplicación web con base de datos colgada
en el servidor capaz de generar códigos Quick Response (Q.R.) y por el otro, una
aplicación para terminales móviles que utilizaría un “framework” llamado “Phonegap”,
el cual permite realizar aplicaciones multiplataforma sin tener que trabajar con los
lenguajes nativos del terminal como pueden ser “Java” para “Android” u “Objective C”
para “iOs”.
Fue en este momento en el que ambos nos pusimos de acuerdo que Eusebi realizaría
la aplicación móvil y yo me encargaría de la aplicación web y de gestionar la base de
datos.
Lo primero que hice el primer día de trabajo fue formatear el ordenador e instalar todo
el entorno de trabajo que en un principio iba a necesitar (“NetBeans IDE 7.1.1”,”
Xampp Version 2.5”, “Mozilla Firefox”, “Google Chrome”).
A partir del segundo día fui completando las tareas que se me iban asignando
mediante “google docs” y que básicamente consistían en búsqueda de las mejores y
5
más perdurables librerías que podíamos necesitar para evitar los odiosos
“deprecateds” como sucedió en su día con la versión 2.0 de “google maps”.
Los coordinadores de los proyectos iban realizando controles periódicos del estado de
la aplicación de igual modo que iban aportando nuevas tareas las cuáles se nos
notificaban a base de reuniones internas, motivo que permitió una rápida integración
en la empresa.
6
3. Descripción del trabajo realizado
Hacer una aplicación web con base de datos para comercios y usuarios mediante PHP
que sea capaz de generar códigos Quick Response (QR) y geo localizarlos.
7
3.3 Diseño
Una vez comprendidas las especificaciones del proyecto quedó patente que tendría
total libertad para estructurar el mismo siguiendo mis propios criterios. En este
momento decidí que lo ideal sería seguir el patrón Modelo Vista Controlador siguiendo
la arquitectura del modelo Cliente/Servidor.
El primer paso fue plasmar un diseño de clases en papel que reflejaría a su vez las
tablas a generar en la base de datos y el conjunto de clases a generar en PHP.
Todas las clases han sido identificadas siempre con identificadores únicos y con fechas
de inicialización ya que resulta mucho más seguro y eficiente trabajar con
identificadores de tipo “BigInt” y no con cualquier tipo de datos.
De igual modo, fui implementando los atributos específicos de cada una de ellas, el
correspondiente constructor y el conjunto de “getter’s” y “setter’s” básico para poder
modificar y consultar los atributos de los objetos una vez instanciados.
Dada que se necesitaba un conjunto básico de funcionalidades por clase que pudieran
acceder a la base de datos (“insert”, “select”, “update”, “delete”), fui implementando
nuevos métodos que incorporasen sentencias en SQL y que de manera genérica
accediesen a la misma separando por un lado, la información que se inserta o consulta
de la información básica de acceso a la misma.
8
3.4 Desarrollo
Modelo Cliente/Servidor:
Cliente:
Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:
• Administrar la interfaz de usuario.
• Interactuar con el usuario.
• Procesar la lógica de la aplicación y hacer validaciones locales.
• Generar requerimientos de bases de datos.
• Recibir resultados del servidor.
• Formatear resultados
9
Servidor:
Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes
puntos:
• Aceptar los requerimientos de bases de datos que hacen los clientes.
• Procesar requerimientos de bases de datos.
• Formatear datos para trasmitirlos a los clientes.
• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de
datos.
Durante este proceso tuve que crear una base de datos con su nombre de usuario y
contraseña de manera que se consulta su información cada vez que se ejecuta una
consulta a la misma.
Dado el grado de repetitividad de algunas de las consultas opte por generar clases en
las que determinadas consultas se llaman a medio de métodos. De esta forma, la
aplicación es más genérica y no se repite el mismo código de una anterior consulta.
Así, poco a poco, fui generando una pequeña API de clases con sus métodos
particulares de cada una, siguiendo el patrón Modelo Vista Controlador, el cuál
explicaré ahora:
El Patrón MVC, es una arquitectura de Software que define la separación de los datos
que conforman la vista de la lógica de una aplicación.
Esto se hace con la finalidad de que cada una de las partes de una aplicación solo
realice lo que está en su responsabilidad, además de que le da mayor entendimiento a
nuestros desarrollos y los hace más fácil de mantener, ya que la parte del diseño solo
tiene la cantidad de código de programación que necesita al igual que en la parte que
10
conforma nuestro código del negocio solo se va a encontrar lógica de programación en
el lenguaje que estemos trabajando (PHP en nuestro caso).
De este modo, lo que este patrón desea evitar es que el un código de inserción de un
registro se encuentre junto con la vista en un mismo archivo, algo nada recomendable,
ya que puede provocar fallos de seguridad.
Veamos ahora más específicamente cuál es el rol de cada uno de los elementos del
patrón:
Vista:
La vista como su nombre lo indica es la parte visual, lo que el usuario final visualizara
en su aplicación. Es la que comunica al usuario lo que quiere ver, esta tiene acceso
directo al modelo y es esta la que transmite los datos a la aplicación para hacer el
proceso que necesitemos.
Modelo:
Controlador:
11
Una vez definido el método de trabajo, ahora explicaré las características básicas de la
base de datos:
Está formada por más de una treintena de relaciones, el tipo de motor de la misma es
“InnoDB” y el cotejamiento, tanto para las tablas como para sus conexiones “MySQL”
es “utf8_unicode_ci”.
Al generar la base de datos, basándome en una de las premisas que tendría que
soportar nuestro sistema en algunos de sus registros, la concurrencia, decidí que era
mejor utilizar el motor “InnoDB” y no el “MyISAM” por los siguientes motivos:
Al contrario de “MyISAM”, “InnoDB” tiene capacidad de ejecutar transacciones
de tipo ACID cuyas siglas en ingles significan Atomicity, Consistency, Isolation
and Durability, es decir, Atomicidad (es la propiedad que asegura que la
operación se ha realizado o no, y por lo tanto ante un fallo del sistema no
puede quedar a medias), Consistencia (es la propiedad que asegura que sólo se
empieza aquello que se puede acabar. Por lo tanto se ejecutan aquellas
operaciones que no van a romper las reglas y directrices de integridad de la
base de datos), Aislamiento (es la propiedad que asegura que una operación no
puede afectar a otras. Esto asegura que la realización de dos transacciones
sobre la misma información sean independientes y no generen ningún tipo de
error) y Durabilidad (es la propiedad que asegura que una vez realizada la
operación, ésta persistirá y no se podrá deshacer aunque falle el sistema).
“InnoDB” permite mantener la integridad referencial, de esta manera se
pueden definir llaves foráneas entre tablas “InnoDB” relacionadas para
asegurarse de que un registro no puede ser eliminado de una tabla si aún está
siendo referenciado por otra.
A su vez, “InnoDB” permite el bloqueo de registros a nivel de filas. Con
“MyISAM”, al tener que ejecutar consultas muy grandes que requieren de
mucho tiempo, simplemente no se podían ejecutar más consultas hasta que
terminaran las consultas que estaban en ejecución. En cambio, las tablas
“InnoDB” usan bloqueo a nivel de filas. Con esto consiguen mejorar el
rendimiento en casos como que una lectura esté siendo bloqueada por otra
consulta que está haciendo cambios en la misma tabla, facilitando de este
modo la concurrencia.
12
Pese a la menor velocidad de codificación del cotejamiento “utf8_unicode_ci” frente al
“utf8_general_ci”, decidí utilizar el primero dado su mayor grado de precisión ya que,
en un futuro, iba a ser necesario almacenar información en otros idiomas como el
alemán que requieren del cotejamiento “utf8_unicode_ci” para evitar errores durante
el proceso de codificación/decodificación.
Decidí utilizar sesiones las cuáles, al igual que son creadas, son destruidas llegado el
momento oportuno.
13
En lo que a la interficie gráfica se refiere, he trabajado conjuntamente tanto con los
jefes de empresa y de proyecto, como con el equipo de diseño gráfico (Gerard y Jose).
He tenido la oportunidad de compartir opinión con ellos a modo de “brainstorming” y
he sido el encargado de estructurar tanto la información que aparecería en los
“header’s” como los “bodies” como los enlaces que comportan.
He de decir que el diseño de los iconos y en general, el diseño gráfico puro
(“PhotoShop”, “FreeHand”, etc) ha sido trabajo de los diseñadores gráficos pero sin
embargo, si ha sido competencia mía, generar los ficheros correspondientes de estilo
en los que quedan definidos los patrones con los que se muestran los diferentes
elementos que aparecen en pantalla y la manera en la que se interactúa con ellos.
Para ello, utilizo “html” como lenguaje de navegador, junto con “css” para definir el
estilo de las vistas.
Para el acceso de los comercios, decidí que lo más innovador era integrar un
“fancybox” el cuál se abre sobre un fondo más oscuro al clicar sobre el icono de
registro y que, a su vez, tiene un formulario de acceso implementado internamente.
Para ello, tuve que decidir cómo se generarían los QR’s y el modelo a seguir para
identificarlos generando de este modo el sistema con la información que contendrían
en sí, al escanearlos con nuestra aplicación.
14
Dado que una gran parte de la aplicación debe ir sincronizada también con la “app”
para terminales móviles, ya que debe poder hacer peticiones al servidor para enviar y
recibir información de la base de datos y al hecho, que la conexión ha de hacerse a
través de un servidor que este en Internet y no en local, se hizo patente la necesidad
de coger un dominio gratuito capaz de soportar “PHP” para los ficheros y “MySQL”
para la base de datos.
Por política de empresa los detalles más internos en lo que a código fuente,
funcionalidad o casos de uso se refiere no pueden ser desvelados públicamente,
motivo por el cuál continuaré a modo de memoria este apartado.
De este modo conseguí evitar el tener que estar subiendo archivos al servidor cada vez
que modificaba información en local y a la inversa.
Con esta herramienta se puede crear un proyecto (con su repositorio asociado), añadir
y modificar permisos a nuevos miembros del proyecto, añadir tareas y asignarlas a
determinados miembros, o generar puntos de control a modo de “milestones” para
seguir una evolución y un porcentaje del total del trabajo que queda para finalizar el
mismo.
15
Esto me permite seguir en tiempo real el transcurso de los acontecimientos al igual
que de los “commits” realizados a través de la asociación que tengo creada entre el
mismo “codebase” y mi cuenta de correo electrónico del trabajo.
El modelo con el que trabajo es un “Samsung Galaxy Young GT-S5360” con la versión
de sistema operativo 2.3.6 de “Android” versión depurada de la 2.3.3 “Gingerbread” y
pese a tener unas dimensiones más pequeñas que las de sus hermanos mayores, es
francamente un lujo poder utilizarlo para el desarrollo de aplicaciones móviles.
16
3.5 Evaluación
Suponiendo el caso de un campo de una tabla de la base de datos cuyo tipo sea
un “varchar” de 50 caracteres y al cuál no queramos que entren valores igual a
7, por un lado, el número máximo de caracteres que se asociarán a su input
será de 50 y a su vez, dado que puede ser cualquier tipo de carácter menos el 7,
se le aplicarán dos restricciones a modo de condicionantes diciendo que, la
longitud del valor asociado al input ha de ser menor o igual que 50 y diferente
de 7.
Suponiendo el caso de un campo de una tabla de la base de datos cuyo tipo sea
un “int” de 4 caracteres y al cuál no queramos que entren valores menores que
5000, por un lado, el número máximo de caracteres que se asociarán a su input
será de 4 y a su vez, se le aplicarán dos restricciones a modo de condicionantes
diciendo que, la longitud del valor asociado al input ha de ser menor o igual
que 4 y que, el valor tratado ha de estar en un rango de entre 5000 y 9999.
17
Por este motivo los mensajes que se envían son siempre del tipo “ERROR: Su email o
su contraseña no son válidos”.
Por otro lado, los botones se bloquean tras su primera pulsación. De este modo dejan
de estar funcionales, como mínimo hasta que reciben la información de la petición y se
reflejan sus resultados para, de este modo, no permitir que se puedan seguir enviando
nuevas peticiones clicando repetidas veces en el tiempo que tarda en producirse la
transferencia lo cual podría provocar una sobrecarga del servidor de hacerse desde
“malas manos”.
He hecho pruebas periódicas con las últimas versiones de “Mozilla Firefox” y “Safari”.
18
Estos son algunos ejemplos de tiempos de carga al realizar peticiones al servidor:
Sending 1 ms 0 0 0 0 0
Como se puede ver, en ambas peticiones, los tiempos de espera se mantienen estables
y dentro de la media siendo el tiempo de recepción (ver petición 1), el cual depende de
otros parámetros relacionados con la conexión a Internet, el principal causante de
aumentar el tiempo total, principalmente en el primer caso,
19
4. Aportaciones del proyecto a los conocimientos del alumno
A parte de ello, he adquirido mayor experiencia a la hora de gestionar las tareas y los
tiempos de entrega coordinando estos últimos tres meses los recursos como “Project
Manager”.
Durante este tiempo he debatido y aportado ideas, algunas de las cuales siguen aún en
proceso de desarrollo.
He de decir que día a día estoy aprendiendo en campos no tan sólo relacionados con la
técnica sino más relacionados con la buena comunicación con los miembros de la
empresa, mirando de hacerles participe de lo que están haciendo, valorando sus ideas
y motivándoles para seguir en la dirección correcta.
20
5. Aportaciones de los estudios realizados al proyecto
He de decir que pese a que del total de los lenguajes utilizados tan sólo había
trabajado con SQL en la carrera, asignaturas como Lenguajes de Programación (L.P.) y
Sistemas Abiertos (S.O.) han sido claves para entender los principios seguidos durante
el desarrollo del proyecto.
Sin los conocimientos aprendidos en L.P. no hubiera sido capaz de generar todo el
sistema de clases a modo de API accediendo e implementando en ellas nuevas
funcionalidades conforme los requisitos del proyecto lo iban necesitando.
De igual modo, al cursar S.O. pude apreciar la diferencia entre los lenguajes
mostrativos de navegador como “html” y los lenguajes de programación de servidores
como es el caso de PHP, así pude aprender el Modelo Cliente/servidor o el Patrón
Modelo Vista Controlador en el que se separa la vista de la información y se accede a
ella por medio de un conjunto de funcionalidades. De hecho conceptos tan básicos
como el de formulario (form) o el de paso de parámetros entre navegador y servidor
son otros ejemplos de conceptos que aprendí cursando la misma.
A su vez, tanto Introducción a las Bases de Datos (I.B.D.) como Base de Datos (B.D.),
me han servido a la hora de visualizar y generar las relaciones de información que sería
necesarias implementar en la propia base de datos de modo que permitiesen generar
todo tipo de consultas y de control de la información con la que trabajo.
Para acabar, conceptos como los de escalabilidad y “overhead” han resultado a su vez
muy útiles los cuáles comprendí cursando Redes P2P y a su vez tanto Proyectos
Informáticos (P.I.) a la hora de gestionar y asignar los recursos del proyecto como
Ingeniería del Software (E.S.) con los conceptos de intuitivo y los diagramas
estructurales me han ayudado a posicionarme a la hora de programar pensando
siempre desde el punto de vista del usuario, simplificando así al máximo los casos de
uso de modo que la mecánica interna de funcionamiento resulte transparente para el
mismo.
21
6. Conclusiones
22
23