DISEÑO, PROGRAMACIÓN E IMPLEMENTACIÓN DE LA APLICACIÓN WEB REUTILIZA.ME

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA DISEÑO, PROGRAMACIÓN E IMPLEMENTACIÓN DE LA APLICACIÓN WEB REUTILIZA.ME AUTOR: MIGUEL PRADEL MONDEDEU MADRID, febrero de 2010

2 Autorizada la entrega del proyecto del alumno: Miguel Pradel Mondedeu DIRECTOR DEL PROYECTO PROF. José Luis Gahete Díaz Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos PROF. Eduardo Alcalde Lancharro Fdo.: Fecha: / /

3 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA DISEÑO, PROGRAMACIÓN E IMPLEMENTACIÓN DE LA APLICACIÓN WEB REUTILIZA.ME AUTOR: MIGUEL PRADEL MONDEDEU MADRID, febrero de 2010

4 Agradecimientos A mi familia. A Antonio, Rocío, Jacobo, Nacho y a todos aquellos que me han ayudado tanto durante todos estos años. I

5 Resumen del proyecto Internet ha llegado a alcanzar cotas de difusión e internacionalización como nunca lo había hecho antes ningún invento en la historia, de tal manera que en menos de 50 años ha pasado de ser un proyecto en estudio a ser una herramienta de máxima importancia tanto en el mundo empresarial como en el ocio y las relaciones sociales. Este crecimiento técnico, que se ha producido de forma gradual, lleva inherente un crecimiento de la aportación de los usuarios. De esta forma, no sólo cambia la funcionalidad de Internet, sino que también el papel del usuario va cambiando. Actualmente la situación está en lo que se conoce como Web 2.0, es decir, que tanto la tecnología como el usuario han dado un paso adelante en el funcionamiento de Internet. Sin embargo, parece que la inmensa capacidad de Internet no es suficiente para cubrir todos los ámbitos del usuario, es decir, está enfocado de una manera global, sin que haya aplicaciones que ofrezcan soluciones más localizadas. Este proyecto lo que busca es aprovechar el potencial de Internet enfocado de una manera mucho más local para ofrecer un servicio en el que se puedan publicar, reservar y buscar artículos de segunda mano. En este mercado el ámbito localizado para favorecer el servicio es importante dada la diversidad de los artículos. De esta manera la aplicación asocia información de posición geográfica para ubicar las publicaciones en un mapa en el que se muestran los artículos visibles dentro del área geográfica del usuario. El sistema cuenta con el desarrollo necesario para comunicarse con los usuarios y también con la lógica suficiente para determinar el protocolo a seguir según la información y la actuación de los usuarios. Éste es un apartado importante para ofrecer un servicio fiable y seguro. La aplicación también ofrece un pequeño buscador para poder facilitar la búsqueda dentro del área del usuario. Como el abanico de artículos en este mercado es muy extenso, la lógica del buscador incluye un sistema de agrupaciones y de clasificación posible gracias a las etiquetas definidas en cada artículo en su publicación. El sistema, II

6 integrando servicios de terceros, también ofrece la posibilidad de calcular la ruta más óptima para poder recoger varios artículos. El sistema ha sido diseñado y desarrollado en previsión a ofrecer un mejor servicio a un mayor número de clientes, por lo que en el diseño, en el desarrollo y en la implementación se han incorporado los componentes necesarios para soportar ese crecimiento de manera que los cambios a realizar sean los menos posibles. La plataforma Back-end se ha desarrollado en el lenguaje Python con el framework para web Django y servidor de bases de datos PostgreSQL. Python es un lenguaje robusto utilizado entre otros por la NASA. Django ha demostrado un rendimiento espectacular en entornos web y en la actualidad es utilizado entre otros por Google, The New York Times, VMWare, etc. Para lograr una mayor escalabilidad se ha utilizado Memcached como sistema de caché entre servidores de forma que escalar la aplicación sea tan sencillo como añadir nuevo hardware sin requerir prácticamente modificaciones en el código fuente. Se han integrado servicios de terceros como la GoogleMaps API, la Google AJAX API o la Freebase API. La aplicación se ha desplegado sobre un servidor web Apache con Ubuntu Server Hardy. Así mismo se ha creado un sistema Back-end de almacenamiento que integra el sistema de archivos de Amazon S3 (Simple Storage Service) para almacenar y servir todos los archivos media de la aplicación web (imágenes, vídeos, estilos CSS, scripts externos, etc.). De esta forma se ha liberado al servidor de la aplicación de la carga de servir contenidos media, permitiendo que logre un mayor rendimiento con los mismos recursos. También con vistas a escalar la aplicación se ha dispuesto el sistema de bases de datos de tal forma que pueda ser separado a otro servidor sin necesidad de modificar el código de la aplicación. También se ha integrado la red de distribución de contenidos (CDN) Amazon CloudFront para situar en cache los contenidos más accedidos en servidores situados en distintos lugares geográficos y poder servir los contenidos desde nodos más cercanos al usuario logrando una mayor velocidad de carga del sitio web. III

7 Para el Front-end de la aplicación se han utilizado nuevas tecnologías como AJAX e intercambio de datos mediante JSON/XML. Se ha utilizado el framework de JavaScript jquery para gestionar eventos y efectos de interfaz, y el framework de hojas de estilo CSS 960.gs para crear la estructura grid de las páginas HTML. Se ha puesto especial énfasis en lograr un sitio web que cumpla con los criterios de accesibilidad de nivel AAA del W3C. También se ha asegurado que tanto el código XHTML como las hojas de estilo CSS de la aplicación cumplan con los criterios de estandarización del W3C y pasen los test de validez que así lo garantizan. Por último se ha tenido muy en cuenta la usabilidad del sitio web, así como el funcionamiento correcto de la aplicación en los diferentes navegadores principales: Firefox, Internet Explorer, Safari, Opera y Chrome. IV

8 Abstract Internet has reached levels of diffusion and internationalization as no other invention has ever done in history, in such a way that in less than 50 years it has gone from being a project under study to a tool of crucial importance both in the business world and in leisure and social relationships. This technical growth, which has developed gradually, means also growth in the users inputs. Thus, not only Internet s functionalities change, but also the role of the user does. Nowadays, we re in what s come to be known as Web 2.0, that is, both technology and user have gone one step forward in the way Internet works. However, it seems like Internet s immense capacity is not enough to cover all aspects of the user, that is, it s focused on a global view, without applications that will offer more personalized solutions. This project looks forward to finding a better usage of Internet s potential focused on a much more local view to offer a service in which already used articles can be publicized, reserved and searched. In this market, the localized area for favouring the service is important, given the diversity of articles. In this way, the application associates information about the geographical position to find the publications in a map in which all visible articles inside the geographical area of the user are shown. The system has the necessary development to communicate with users and also enough logic to determine the protocol to be followed given information and actions taken by users. This is an important aspect if a safe and trustful service is to be given. The application offers also a small search engine to facilitate the search within the user s area. Because the range of articles in this market is quite wide, the logic of the search engine includes a system of grouping and classification that s possible thanks to defined tags in each article when publicized. The system, integrating services for third parties, also offers the possibility to calculate the best route to pick up a series of articles. The system has been designed and developed in prevision of offering a better service to a larger number of clients, and for that, the design, development and implementation have incorporated the necessary components to support that growth in such a way that the amount of changes to be made be the lowest possible. V

9 The Back-end platform has been developed in Python language with the web framework Django and the data base server PostgreSQL. Phyton is a robust language used, among others, by NASA. Django has showed a spectacular performance in web environments and in these days it s used, among others, by Google, The New York Times, VMWare, etc. To achieve a higher scalability Memcached has been used as a cache system among servers in a way that scaling the application be as easy as adding new hardware without requiring practically any modifications in the source code. Third party services as GoogleMaps API, the Google AJAX API or Freebase API have been integrated. The application has been developed sustained on an Apache web server with Ubuntu Server Hardy. Also a Back-end system of storage has been created. It integrates the files system of Amazon S3 (Simple Storage Service) to store and serve all media files of the web application (images, videos, CSS styles, external scripts, etc.). With this, the application s server has been freed from the load of serving media contents, allowing for a higher performance with the same resources. Also looking forward to scaling the application a data base system has been set so that it can be taken apart from other server without the need of modifying the application s code. Also the contents distribution net (CDN) Amazon CloudFront has been integrated to keep in cache the contents most accessed in servers located in different geographical places and to serve the contents from nodes closer to the user, achieving higher speed in the load of the web site. For the Front-end of the application, we have used new technologies such as AJAX and data exchange through JSON/XML. JavaScript s jquery framework has been used to manage events and interface effects and the framework of style sheets CSS 960.gs to create the grid structure of HTML pages. We have placed a special effort in achieving a website that will satisfy the AAA level of accessibility of W3C criteria. Also we ve ensured that both the XHTML as well as the CSS style sheets of the application satisfy the standardizing criteria of the W3C and pass the validity tests that so guarantee it. Lastly, we ve taken into great account the usability of the website, as well as the correct functioning of the application in the main navigators: Firefox, Internet Explorer, Safari, Opera and Chrome. VI

10 Índice 1. Introducción Motivación Objetivos del Sistema Nuevas tecnologías Programación Orientada a Objetos Python Framework Framework Django Localización geográfica Geocodificación Estado del arte Introducción Web Introducción Origen del término Tecnología Software del servidor Comparación con la Web Semántica Aplicaciones Educativas Redes Sociales Historia Tecnologías actuales Diseminación de información Software para el análisis de redes sociales Redes sociales en Internet Antecedente: chatarra.me Chatarra.me Estudios de APIS y servicios de terceros Introducción GoogleMaps API Google AJAX API VII

11 4.4. Freebase Maxmind GeoLite City Geonames Instituto Nacional de Estadística World Gazetteer Amazon S Amazon CloudFront Estudio de la arquitectura Introducción Especificación y evaluación de alternativas Elección de lenguaje de programación Elección de Framework de desarrollo de la aplicación Elección del sistema gestor de bases de datos Elección de Framework de JavaScript Elección de Framework CSS Elección del sistema de distribución de contenidos Configuración de la solución final Análisis conceptual de la aplicación Necesidades y requisitos del sistema Introducción Reconocimiento del problema y alcance Tipología de usuarios finales Especificación de necesidades y requisitos Análisis de la penalización Metodología utilizada Metodología tradicional metodología ágil Programación Extrema Modelo de dominio Introducción Diagrama de clases de la aplicación de autenticación de Django Diagrama de clases de la aplicación publicaciones Diagrama de clases de la aplicación de administrador Diagrama de clases de la aplicación de sesión VIII

12 Diagrama de clases de la aplicación de sitios Diagrama de clases de la aplicación de metainformación Glosario de clases Diagrama de casos de uso Caso de uso del usuario Caso de uso del administrador Diseño y desarrollo del sistema Programación Introducción Lenguajes de programación Optimización de la aplicación web Implantación y pruebas Pruebas del Sistema Introducción Pruebas de integración Pruebas de explotación del sistema Pruebas de escalabilidad Pruebas de recuperación Pruebas de usabilidad Conclusión Implantación Introducción Configuración Hardware y Software Pruebas de implantación Conclusión Estudio económico Introducción Costes de tecnología Costes de implantación Costes de operación Costes Totales Planificación del proyecto Planificación IX

13 11. Conclusiones y trabajos futuros Bibliografía Libros Referencias web Anexo A. Django.es X

14 1. Introducción 1

15 1.1. Motivación Con el paso del tiempo Internet ha aumentado su relevancia, pasando en la actualidad a ser una herramienta importantísima tanto para el mundo empresarial y comercial como para actividades de ocio y entretenimiento. No sólo ha tenido un incremento en la utilidad, también han aumentado el número de usuarios y la distancia cubierta por la red, alcanzando prácticamente cualquier parte del mundo actualmente. Sin embargo, a pesar de este crecimiento, parece que sigue existiendo un espacio sin cubrir para el usuario, y es que no hay muchas aplicaciones que ofrezcan soluciones para el usuario de una manera más local. También cabe destacar el aumento de la implicación del usuario con la red, puesto que no sólo se limita a usar Internet para obtener información, sino que también la produce y la comparte. Es en este contexto donde nace el siguiente proyecto, con el propósito de servir como herramienta de comunicación para el usuario y que funcione en un ámbito más localizado. Por lo tanto, este proyecto surge como una idea nueva, apoyada en la alta interacción de los usuarios y que sea capaz de ofrecer algo nuevo y mejor que lo que actualmente se ofrece en el mercado. Por otra parte, a modo personal, lo más interesante resulta diseñar y desarrollar un programa en un lenguaje no estudiado durante la carrera, para poder comprobar la capacidad de conocimiento y aprendizaje de un lenguaje nuevo. También es interesante trabajar en un proyecto real con el que hacerse un hueco no sólo en Internet sino también en el mercado. 2

16 1.2. Objetivos del Sistema El objetivo del sistema es ofrecer un servicio en Internet que permita a los usuarios publicar cualquier objeto que posean para ofrecerlo como artículo de segunda mano sin compensación económica para el usuario. Cada publicación estará asociada a la dirección que indique el usuario, para que el sistema muestre todas las publicaciones en un mapa. Los usuarios podrán realizar la reserva, por un módico precio, de cualquier artículo publicado visible dentro de su área geográfica. La aplicación realizará automáticamente toda la gestión para la reserva de un artículo, la cuál tiene un tiempo de plazo de una semana, desde el instante en que se realiza la reserva, para hacer efectiva la recogida del artículo. Durante el tiempo en el que un artículo está reservado, el sistema lo ocultará al resto de usuarios. También realizará toda la comunicación vía con ambos usuarios implicados, imprescindible para conocer el estado de la recogida. Fruto de esta comunicación, la aplicación evaluará automáticamente el protocolo a seguir para el correcto funcionamiento del sistema de publicaciones. Otro objetivo es que el servicio que ofrece sea lo más robusto y seguro posible, por lo que la aplicación cuenta con toda la lógica necesaria y estudiada para poder llevar a cabo las penalizaciones pertinentes a los usuarios a los que el sistema detecte que no actúen conforme a las reglas. Por último, otro objetivo que se busca es que el interfaz gráfico y la usabilidad de la aplicación resulten cómodos, fáciles y atractivos para el usuario, para que quede satisfecho e incitar a su uso. 3

17 1.3. Nuevas tecnologías Programación Orientada a Objetos Los objetos son entidades que combinan estado, comportamiento e identidad: El estado está compuesto de datos, será uno o varios atributos a los que se habrán asignado unos valores concretos o datos. El comportamiento está definido por los procedimientos o métodos con que puede operar dicho objeto, es decir, qué operaciones se pueden realizar con él. La identidad es una propiedad de un objeto que lo diferencia del resto, es decir, es su identificador. La programación orientada a objetos expresa un programa como un conjunto de estos objetos, que colaboran entre ellos para realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener, y reutilizar. De esta forma, un objeto contiene toda la información que permite definirlo e identificarlo frente a otros objetos pertenecientes a otras clases e incluso frente a objetos de una misma clase, al poder tener valores bien diferenciados en sus atributos. A su vez, los objetos disponen de mecanismos de interacción llamados métodos que favorecen la comunicación entre ellos. Esta comunicación favorece a su vez el cambio de estado en los propios objetos. Esta característica lleva a tratarlos como unidades indivisibles, en las que no se separan ni deben separarse el estado y el comportamiento. Los métodos y atributos están estrechamente relacionados por la propiedad de conjunto. Esta propiedad destaca que una clase requiere de métodos para poder tratar los atributos con los que cuenta. El programador debe pensar indistintamente en ambos conceptos, sin separar ni darle mayor importancia a ninguno de ellos. Hacerlo podría producir el hábito erróneo de crear clases contenedoras de información por un lado y clases con 4

18 métodos que manejen a las primeras por el otro. De esta manera se estaría realizando una programación estructurada camuflada en un lenguaje de programación orientado a objetos. Esto difiere de la programación estructurada tradicional, en la que los datos y los procedimientos están separados y sin relación, ya que lo único que se busca es el procesamiento de unos datos de entrada para obtener otros de salida. La programación estructurada anima al programador a pensar sobre todo en términos de procedimientos o funciones, y en segundo lugar en las estructuras de datos que esos procedimientos manejan. En la programación estructurada sólo se escriben funciones que procesan datos. Los programadores que emplean este nuevo paradigma, en cambio, primero definen objetos para luego enviarles mensajes solicitándoles que realicen sus métodos por sí mismos. Origen Los conceptos de la programación orientada a objetos tienen origen en Simula 67, un lenguaje diseñado para hacer simulaciones, creado por Ole-Johan Dahl y Kristen Nygaard del Centro de Cómputo Noruego en Oslo. Al parecer, en este centro, trabajaban en simulaciones de naves, y fueron confundidos por la explosión combinatoria de cómo las diversas cualidades de diversas naves podían afectar unas a las otras. La idea ocurrió para agrupar los diversos tipos de naves en diversas clases de objetos, siendo responsable cada clase de objetos de definir sus propios datos y comportamiento. Fueron refinados más tarde en Smalltalk, que fue desarrollado en Simula en Xerox PARC (y cuya primera versión fue escrita sobre Basic) pero diseñado para ser un sistema completamente dinámico en el cual los objetos se podrían crear y modificar "en marcha" en lugar de tener un sistema basado en programas estáticos. La programación orientada a objetos tomó posición como el estilo de programación dominante a mediados de los años ochenta, en gran parte debido a la influencia de C++, una extensión del lenguaje de programación C. Su dominación fue consolidada gracias al auge de las Interfaces gráficas de usuario, para las cuales la programación orientada a objetos está particularmente bien adaptada. En este caso, se habla también de programación dirigida por eventos. 5

19 Las características de orientación a objetos fueron agregadas a muchos lenguajes existentes durante ese tiempo, incluyendo Ada, BASIC, Lisp, Pascal, entre otros. La adición de estas características a los lenguajes que no fueron diseñados inicialmente para ellas condujo a menudo a problemas de compatibilidad y en la capacidad de mantenimiento del código. Los lenguajes orientados a objetos "puros", por otra parte, carecían de las características de las cuales muchos programadores habían venido a depender. Para saltar este obstáculo, se hicieron muchas tentativas para crear nuevos lenguajes basados en métodos orientados a objetos, pero permitiendo algunas características imperativas de maneras "seguras". El Eiffel de Bertrand Meyer fue un temprano y moderadamente acertado lenguaje con esos objetivos pero ahora ha sido esencialmente reemplazado por Java, en gran parte debido a la aparición de Internet, y a la implementación de la máquina virtual de Java en la mayoría de navegadores. PHP en su versión 5 se ha ido modificando y soporta una orientación completa a objetos, cumpliendo todas las características propias de la orientación a objetos. Conceptos fundamentales La programación orientada a objetos es una forma de programar que trata de encontrar una solución a estos problemas. Introduce nuevos conceptos, que superan y amplían conceptos antiguos ya conocidos. Entre ellos destacan los siguientes: Clase: definiciones de las propiedades y comportamiento de un tipo de objeto concreto. La instanciación es la lectura de estas definiciones y la creación de un objeto a partir de ellas. Herencia: (por ejemplo, herencia de la clase D a la clase C) es la facilidad mediante la cual la clase D hereda en ella cada uno de los atributos y operaciones de C, como si esos atributos y operaciones hubiesen sido definidos por la misma D. Por lo tanto, puede usar los mismos métodos y variables públicas declaradas en C. Los componentes registrados como privados también se heredan, pero como no pertenecen a la clase, se mantienen escondidos al programador y sólo pueden ser accedidos a través 6

20 de otros métodos públicos. Esto es así para mantener hegemónico el ideal de la Programación Orientada a Objetos. Objeto: entidad provista de un conjunto de propiedades o atributos y de comportamiento o funcionalidad que consecuentemente reaccionan a eventos. Se corresponde con los objetos reales del mundo real, o a objetos internos del sistema del programa. Es una instancia a una clase. Método: algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la recepción de un mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer. Un método puede producir un cambio en las propiedades del objeto, o la generación de un "evento" con un nuevo mensaje para otro objeto del sistema. Evento: es un suceso en el sistema, tal como una interacción del usuario con la máquina, o un mensaje enviado por un objeto. El sistema maneja el evento enviando el mensaje adecuado al objeto pertinente. También se puede definir como evento, a la reacción que puede desencadenar un objeto, es decir la acción que genera. Mensaje: una comunicación dirigida a un objeto, que le ordena que ejecute uno de sus métodos con ciertos parámetros asociados al evento que lo generó. Propiedad o atributo: contenedor de un tipo de datos asociados a un objeto (o a una clase de objetos), que hace los datos visibles desde fuera del objeto y esto se define como sus características predeterminadas, y cuyo valor puede ser alterado por la ejecución de algún método. Estado interno: es una variable que se declara privada, que puede ser únicamente accedida y alterada por un método del objeto, y que se utiliza 7

21 para indicar distintas situaciones posibles para el objeto (o clase de objetos). No es visible al programador que maneja una instancia de la clase. Componentes de un objeto: atributos, identidad, relaciones y métodos. Representación de un objeto: un objeto se representa por medio de una tabla o entidad que esté compuesta por sus atributos y funciones correspondientes. En comparación con un lenguaje imperativo, una variable, no es más que un contenedor interno del atributo del objeto o de un estado interno, así como la función es un procedimiento interno del método del objeto. Características de la Orientación a Objetos Hay un cierto acuerdo sobre exactamente qué características de un método de programación o lenguaje le definen como "orientado a objetos", pero hay un consenso general en que las características siguientes son las más importantes: Abstracción: denota las características esenciales de un objeto, donde se capturan sus comportamientos. Cada objeto en el sistema sirve como modelo de un agente abstracto que puede realizar trabajo, informar y cambiar su estado, y "comunicarse" con otros objetos en el sistema sin revelar cómo se implementan estas características. Los procesos, las funciones o los métodos pueden también ser abstraídos y cuando lo están, una variedad de técnicas son requeridas para ampliar una abstracción. Encapsulamiento: significa reunir a todos los elementos que pueden considerarse pertenecientes a una misma entidad, al mismo nivel de abstracción. Esto permite aumentar la cohesión de los componentes del sistema. Algunos autores confunden este concepto con el principio de ocultación, principalmente porque se suelen emplear conjuntamente. 8

22 Principio de ocultación: cada objeto está aislado del exterior, es un módulo natural, y cada tipo de objeto expone una interfaz a otros objetos que especifica cómo pueden interactuar con los objetos de la clase. El aislamiento protege a las propiedades de un objeto contra su modificación por quien no tenga derecho a acceder a ellas, solamente los propios métodos internos del objeto pueden acceder a su estado. Esto asegura que otros objetos no pueden cambiar el estado interno de un objeto de maneras inesperadas, eliminando efectos secundarios e interacciones inesperadas. Algunos lenguajes relajan esto, permitiendo un acceso directo a los datos internos del objeto de una manera controlada y limitando el grado de abstracción. La aplicación entera se reduce a un agregado o rompecabezas de objetos. Polimorfismo: comportamientos diferentes, asociados a objetos distintos, pueden compartir el mismo nombre, al llamarlos por ese nombre se utilizará el comportamiento correspondiente al objeto que se esté usando. O dicho de otro modo, las referencias y las colecciones de objetos pueden contener objetos de diferentes tipos, y la invocación de un comportamiento en una referencia producirá el comportamiento correcto para el tipo real del objeto referenciado. Cuando esto ocurre en "tiempo de ejecución", esta última característica se llama asignación tardía o asignación dinámica. Algunos lenguajes proporcionan medios más estáticos (en "tiempo de compilación") de polimorfismo, tales como las plantillas y la sobrecarga de operadores de C++. Herencia: las clases no están aisladas, sino que se relacionan entre sí, formando una jerarquía de clasificación. Los objetos heredan las propiedades y el comportamiento de todas las clases a las que pertenecen. La herencia organiza y facilita el polimorfismo y el encapsulamiento permitiendo a los objetos ser definidos y creados como tipos especializados de objetos preexistentes. Estos pueden compartir y extender su comportamiento sin tener que volver a implementarlo. Esto suele hacerse habitualmente 9

23 agrupando los objetos en clases y éstas en árboles o enrejados que reflejan un comportamiento común. Cuando un objeto hereda de más de una clase se dice que hay herencia múltiple. Recolección de basura: la Recolección de basura o Garbage Collection es la técnica por la cual el ambiente de Objetos se encarga de destruir automáticamente, y por tanto desasignar de la memoria, los Objetos que hayan quedado sin ninguna referencia a ellos. Esto significa que el programador no debe preocuparse por la asignación o liberación de memoria, ya que el entorno la asignará al crear un nuevo Objeto y la liberará cuando nadie lo esté usando. En la mayoría de los lenguajes híbridos que se extendieron para soportar el Paradigma de Programación Orientada a Objetos como C++ u Object Pascal, esta característica no existe y la memoria debe desasignarse manualmente Python Python es un lenguaje de programación interpretado creado por Guido van Rossum en el año Comparado habitualmente con Tcl, Perl, Scheme, Java y Ruby, en la actualidad se desarrolla como un proyecto de código abierto, administrado por la Python Software Foundation. La última versión estable del lenguaje es la Python es considerado como la "oposición leal" a Perl, lenguaje con el cual mantiene una rivalidad amistosa. Los usuarios de Python consideran a éste mucho más limpio y elegante para programar. Python permite dividir el programa en módulos reutilizables desde otros programas Python. Viene con una gran colección de módulos estándar que se pueden utilizar como base de los programas (o como ejemplos para empezar a aprender Python). También hay módulos incluidos que proporcionan E/S de ficheros, llamadas al sistema, sockets y hasta interfaces a GUI (interfaz gráfica con el usuario) como Tk, GTK, Qt entre otros. 10

24 Python se utiliza como lenguaje de programación interpretado, lo que ahorra un tiempo considerable en el desarrollo del programa, pues no es necesario compilar ni enlazar. El intérprete se puede utilizar de modo interactivo, lo que facilita experimentar con características del lenguaje, escribir programas desechables o probar funciones durante el desarrollo del programa. El principal objetivo que persigue este lenguaje es la facilidad, tanto de lectura, como de diseño. Historia Python fue creado a finales de los ochenta por Guido van Rossum en CWI en los Países Bajos como un sucesor del lenguaje de programación ABC, capaz de manejar excepciones e interactuar con el sistema operativo Amoeba. En 1991, Van Rossum publicó el código (versión 0.9.0) en alt.sources. En esta etapa del desarrollo ya estaban presentes clases con herencia, manejo de excepciones, funciones, y los tipos modulares: list, dict, str y así sucesivamente. Además en este lanzamiento inicial aparecía un sistema de módulos adoptado de Modula-3. Van Rossum describe el módulo como "uno de las mayores unidades de programación de Python". El modelo de excepciones en Python es parecido al de Modula-3, con la adición de una cláusula else. En el año 1994 se formó comp.lang.python, el foro de discusión principal de Python, marcando un hito en el crecimiento del grupo de usuarios de este lenguaje. Python alcanzó la versión 1.0 en enero de Una característica de este lanzamiento fueron las herramientas de la programación funcional: lambda, map, filter y reduce. Van Rossum explicó que "Hace 12 años, Python adquirió lambda, reduce(), filter() and map(), cortesía de un hacker de Lisp que las extrañaba y que envió parches.". 11

25 La última versión liberada proveniente de CWI fue Python 1.2. En 1995, Van Rossum continuó su trabajo en Python en la Corporation for National Research Initiatives (CNRI) en Reston, Virginia, donde lanzó varias versiones del software. Durante su estancia en CNRI, Van Rossum lanzó la iniciativa Computer Programming for Everybody (CP4E), con el fin de hacer la programación más accesible a más gente, con un nivel de 'alfabetización' básico en lenguajes de programación, similar a la alfabetización básica en inglés y habilidades matemáticas necesarias por muchos trabajadores. Python tuvo un papel crucial en este proceso: debido a su orientación hacia una sintaxis limpia, ya era idóneo, y las metas de CP4E presentaban similitudes con su predecesor, ABC. El proyecto fue patrocinado por DARPA. Desde el año 2007, el proyecto CP4E está inactivo, y mientras Python intenta ser fácil de aprender y no muy arcano en su sintaxis y semántica, alcanzando a los no-programadores, no es una preocupación activa. En el año 2000, el principal equipo de desarrolladores de Python se cambió a BeOpen.com para formar el equipo BeOpen PythonLabs. CNRI pidió que la versión 1.6 fuera pública, continuando su desarrollo hasta que el equipo de desarrollo abandonó CNRI; su programa de lanzamiento y el de la versión 2.0 tenían una significativa cantidad de traslapo. Python 2.0 fue el primer y único lanzamiento de BeOpen.com. Después que Python 2.0 fuera publicado por BeOpen.com, Guido van Rossum y los otros desarrolladores PythonLabs se unieron en Digital Creations. Python 2.0 tomó una característica mayor del lenguaje de programación funcional Haskell: list comprehensions. La sintaxis de Python para esta construcción es muy similar a la de Haskell, salvo por la preferencia de los caracteres de puntuación en Haskell, y la preferencia de Python por palabras claves alfabéticas. Python 2.0 introdujo además un sistema de recolección de basura capaz de recolectar referencias cíclicas. 12

26 Posterior a este doble lanzamiento, y después que van Rossum dejó CNRI para trabajar con desarrolladores de software comercial, quedó claro que la opción de usar Python con software disponible bajo GPL era muy deseable. La licencia usada entonces, la Python License, incluía una cláusula estipulando que la licencia estaba gobernada por el estado de Virginia, por lo que, bajo la óptica de los abogados de Free Software Foundation (FSF), se hacía incompatible con GNU GPL. CNRI y FSF se relacionaron para cambiar la licencia de software libre de Python para hacerla compatible con GPL. En el año 2001, Van Rossum fue premiado con FSF Award for the Advancement of Free Software. Python 2.1 fue un trabajo derivado de Python 1.6.1, así como también de Python 2.0. Su licencia fue renombrada: Python Software Foundation License. Todo el código, documentación y especificaciones añadidas, desde la fecha del lanzamiento de la versión alfa de Python 2.1, tiene como dueño a Python Software Foundation (PSF), una organización sin ánimo de lucro fundada en el año 2001, tomando como modelo la Apache Software Foundation. Incluido en este lanzamiento fue una implementación del scoping más parecida a las reglas de static scoping (del cual Scheme es el originador). Una innovación mayor en Python 2.2 fue la unificación de los tipos en Python (tipos escritos en C), y clases (tipos escritos en Python) dentro de una jerarquía. Esa unificación logró un modelo de objetos de Python puro y consistente. También fueron agregados los generadores que fueron inspirados por el lenguaje Icon. Las adiciones a la biblioteca estándar de Python y las decisiones sintácticas fueron influenciadas fuertemente por Java en algunos casos: el package logging, introducido en la versión 2.3, el parser SAX, introducido en 2.0, y la sintaxis del patrón decorator que usa agregado en la versión

27 Características y paradigmas Python es un lenguaje de programación multiparadigma. Esto significa que más que forzar a los programadores a adoptar un estilo particular de programación, permite varios estilos: programación orientada a objetos, programación estructurada y programación funcional. Otros muchos paradigmas más están soportados mediante el uso de extensiones. Python usa tipo de dato dinámico y reference counting para el manejo de memoria. Una característica importante de Python es la resolución dinámica de nombres, lo que enlaza un método y un nombre de variable durante la ejecución del programa (también llamado ligadura dinámica de métodos). Otro objetivo del diseño del lenguaje era la facilidad de extensión. Nuevos módulos se pueden escribir fácilmente en C o C++. Python puede utilizarse como un lenguaje de extensión para módulos y aplicaciones que necesitan de una interfaz programable. Aunque el diseño de Python es de alguna manera hostil a la programación funcional tradicional del Lisp, existen bastantes analogías entre Python y los lenguajes minimalistas de la familia Lisp como puede ser Scheme. Filosofía Los usuarios de Python se refieren a menudo a la Filosofía Python que es bastante análoga a la filosofía de Unix. El código que sigue los principios de Python de legibilidad y transparencia se dice que es "pythonico". Contrariamente, el código opaco u ofuscado es bautizado como "no pythonico" ("unpythonic" en inglés). Estos principios fueron famosamente descritos por el desarrollador de Python Tim Peters en El Zen de Pytho : Bello es mejor que feo. Explícito es mejor que implícito. Simple es mejor que complejo. Complejo es mejor que complicado. Plano es mejor que anidado. Disperso es mejor que denso. 14

28 La legibilidad cuenta. Los casos especiales no son tan especiales como para quebrantar las reglas. Aunque lo práctico gana a la pureza. Los errores nunca deberían dejarse pasar silenciosamente. A menos que hayan sido silenciados explícitamente. Frente a la ambigüedad, rechaza la tentación de adivinar. Debería haber una -y preferiblemente sólo una- manera obvia de hacerlo. Ahora es mejor que nunca. Aunque nunca es a menudo mejor que ya mismo. Si la implementación es difícil de explicar, es una mala idea. Si la implementación es fácil de explicar, puede que sea una buena idea. Los espacios de nombres (namespaces) son una gran idea Hagamos más de esas cosas! Tim Peters, El Zen de Python Desde la versión 2.1.2, Python incluye estos puntos (en su versión original en inglés) como un huevo de pascua que se muestra al ejecutar import this. Modo interactivo El intérprete de Python estándar incluye un modo interactivo, en el cual se escriben las instrucciones en una especie de shell: las expresiones pueden ser introducidas una a una, pudiendo verse el resultado de su evaluación inmediatamente. Esto resulta útil tanto para las personas que se están familiarizando con el lenguaje como también para los programadores más avanzados: se pueden probar porciones de código en el modo interactivo antes de integrarlo como parte de un programa. Existen otros programas, tales como IDLE e IPython, que añaden funcionalidades extra al modo interactivo, como el auto-completar código y el coloreado de la sintaxis del lenguaje. 15

29 Elementos del lenguaje Python fue diseñado para ser leído con facilidad. Entre otras cosas se utilizan palabras en inglés donde otros lenguajes utilizarían símbolos (por ejemplo, los operadores lógicos y && en Python se escriben or y and, respectivamente). En vez de delimitar los bloques de código mediante el uso de llaves ({}), Python utiliza el sangrado. Esto hace que el mismo sea obligatorio, ayudando a la claridad y consistencia del código escrito (incluso entre varios desarrolladores). Comentarios Los comentarios se inician con el símbolo #, y se extienden hasta el final de la línea. Variables Las variables se definen de forma dinámica. El signo igual (=) se usa para asignar valores a las variables. 16

30 Tipos de datos Tipo Clase Notas Ejemplo Str String Inmutable Integrador unicode String Version Unicode u Integrador de str List Secuencia Mutable, puede [4.0, string, True] contener diversos tipos tuple Secuencia Inmutable (4.0, string, True) set Conjunto Mutale, sin orden, Set([4.0, string, no contiene True]) duplicados frozenset Conjunto Inmutale, sin frozenset([4.0, string, orden, no contiene True]) duplicados dict Mapping Grupo de pares { key1 :1.0, clave-valor key2 :False} int Numero entero Precisión fija, 42 promovido a long en caso de overflow long Número entero Precisión arbitraria 42L ó L float Número Coma flotante de doble precisión bool Booleano Valor booleano True o False Mutable: si su contenido (o dicho valor) puede cambiarse en tiempo de ejecución. Inmutable: si su contenido no puede cambiarse en tiempo de ejecución. 17

31 Tuplas y listas Para declarar una lista, basta usar los corchetes [ ], mientras que para declarar una tupla es recomendable usar los paréntesis (). En ambas los elementos se separan por comas. Tanto las listas como las tuplas pueden contener elementos de diferentes tipos. No obstante las listas suelen usarse para elementos del mismo tipo en cantidad variable mientras que las tuplas se reservan para elementos distintos en cantidad fija. Para acceder a los elementos de una lista o tupla, se utiliza un índice entero. Se pueden utilizar índices negativos para acceder elementos a partir del final. Las listas se caracterizan por ser mutables, es decir, se puede cambiar su contenido, mientras que no es posible modificar el contenido de una tupla ya creada, puesto que es inmutable. Diccionarios Los diccionarios se declaran entre llaves ({}), y contienen elementos separados por comas, donde cada elemento está formado por un par clave: valor (el símbolo : separa la clave de su valor correspondiente). Los diccionarios son mutables. El valor de un diccionario puede ser de cualquier tipo. Un string ("casa"), un int (2), una lista ([1, 2, 3]), o incluso un diccionario. En cambio, la clave en los diccionarios debe ser inmutable. Esto quiere decir, por ejemplo, que no pueden usarse ni listas ni diccionarios como claves. Cabe señalar, que los diccionarios al igual que las listas, al ser mutables, compartirán los cambios realizados, independientemente del nombre de la variable que se usen para referirse a ellos. Cuando este comportamiento no sea el deseado, se puede hacer una copia del diccionario usando su método copy. 18

32 Conjuntos Los conjuntos se construyen mediante set(items) donde ítems es cualquier objeto iterable. Los conjuntos no mantienen el orden ni contienen elementos duplicados. Funciones Las funciones se definen con la palabra clave def, seguida del nombre de la función y sus parámetros. Otra forma de escribir funciones, aunque menos utilizada, es con la palabra clave lambda (que aparece en lenguajes funcionales como Lisp). Módulos Existen muchas propiedades que se pueden agregar al lenguaje importando módulos, que son minicódigos (la mayoría escritos también en Python) que llaman a los recursos del sistema. Un ejemplo es el módulo Tkinter, que permite crear interfaces gráficas que incluyan botones, cajas de texto, y muchas cosas que se ven habitualmente en el sistema operativo. Otro ejemplo es el módulo que permite manejar el sistema operativo desde el lenguaje. Los módulos se agregan a los códigos escribiendo import seguida del nombre del módulo que se quisiera usar. Sistema de objetos En Python, todo es un objeto (incluso las clases). Las clases, al ser objetos, son instancias de una meta-clase. Python además soporta herencia múltiple y polimorfismo. Biblioteca estándar Python tiene una gran biblioteca estándar, usada para una diversidad de tareas. Esto viene de la filosofía "pilas incluidas" ("batteries included") en referencia a los módulos de Python. Los módulos de la biblioteca estándar pueden mejorarse por módulos personalizados escritos tanto en C como en Python. Debido a la gran variedad de herramientas incluidas en la biblioteca estándar combinada con la habilidad de usar 19

33 lenguajes de bajo nivel como C y C++, los cuales son capaces de interactuar con otras bibliotecas, Python es un lenguaje que combina su clara sintaxis con el inmenso poder de lenguajes menos elegantes Framework Es una estructura de soporte definida mediante la cual otro proyecto de software puede ser organizado y desarrollado. Normalmente incluye soporte de programas, bibliotecas y un lenguaje interpretado entre otros software para ayudar a desarrollar y unir los diferentes componentes de un proyecto. Representa una arquitectura de software que modela las relaciones generales de las entidades del dominio. Provee una estructura y una metodología de trabajo la cual extiende o utiliza las aplicaciones del dominio. Su principal cometido es facilitar el desarrollo de software posibilitando a diseñadores y programadores concentrar más tiempo y esfuerzo identificando requerimientos que tratando con los aburridos detalles de bajo nivel. Hay quejas comunes acerca de que el uso de frameworks añade código innecesario y que la preponderancia de frameworks competitivos y complementarios significa que el tiempo que se pasaba programando y diseñando ahora se gasta en aprender a usar frameworks. Un framework no debe ser consciente de todos estos requerimientos sin tener que ser intrusivo con las aplicaciones que permite dentro de sí mismo, es decir, que actúa como armazón que sostiene los distintos objetos que se integran para alcanzar una solución. A esto se le añade la capacidad de extenderse sin prejuicios para diversificar la expresión del programa mismo. 20

34 Arquitectura de un framework framework - MVC La arquitectura que sigue, para fragmentar la programación, es una arquitectura Modelo Vista Controlador. Esta arquitectura es un patrón que separa en tres componentes distintos los datos de una aplicación, la interfaz de usuario y la lógica de control. Ampliamente utilizado en aplicaciones web, en donde la vista es la página HTML y el código que provee de datos dinámicos a la página; el modelo es el sistema de gestión de la base de datos y la lógica de negocio y, finalmente, el controlador es responsable de recibir los eventos de entrada desde la vista. La descripción del modelo es la siguiente: - Modelo: es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos. Aquí está incluida la gestión realizada por el sistema de gestión de la base de datos. - Vista: presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. - Controlador: responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y en la vista. 21

35 La unión entre capa de presentación y capa de negocio conocido en el paradigma de la programación por capas representaría la integración entre Vista y su correspondiente Controlador de eventos y acceso a datos. MVC no pretende discriminar entre capa de negocio de capa de presentación pero si pretende separar la capa visual gráfica de su correspondiente programación y acceso a datos, algo que mejora el desarrollo y mantenimiento de la Vista y el Controlador en paralelo, ya que ambos cumplen ciclos de vida muy distintos entre sí. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.) 2. El controlador recibe la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos. 3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario. Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo. El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador puede ser utilizado para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. 5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. 22

36 Framework Django La meta fundamental de Django es facilitar la creación de sitios web complejos. Django pone énfasis en el re-uso, la conectividad y extensibilidad de componentes, del desarrollo rápido y del principio de DRY (del inglés Don't Repeat Yourself). Python es usado en todas las partes del framework, incluso en configuraciones, archivos, y en los modelos de datos. Los orígenes de Django en la administración de páginas de noticias son evidentes en su diseño, ya que proporciona una serie de características que facilitan el desarrollo rápido de páginas orientadas a contenidos. La aplicación administrativa permite la creación, actualización y eliminación de objetos de contenido, llevando un registro de todas las acciones realizadas sobre cada uno, y proporciona una interfaz para administrar los usuarios y los grupos de usuarios incluyendo una asignación detallada de permisos. Características: - Un mapeador objeto-relacional. - Aplicaciones con conectividad, es decir, que pueden instalarse en cualquier página gestionada con Django. - Una API de base de datos robusta. - Un sistema incorporado de vistas genéricas que ahorra tener que escribir la lógica de ciertas tares comunes. - Un sistema extensible de plantillas basado en etiquetas, con herencia de plantillas. - Un despachador de URLs basado en expresiones regulares. Esto permite diseñar las URLs lo que sirve para posicionar en buscadores. - Un sistema middleware para desarrollar características adicionales. Por ejemplo, la distribución principal de Django incluye componentes middleware que proporcionan cacheo, compresión de la salida, normalización de URLs, protección CSRF y soporte de sesiones. 23

37 - Soporte de internacionalización, incluyendo traducciones incorporadas de la interfaz de administración. - Documentación incorporada accesible a través de la aplicación administrativa incluyendo documentación generada automáticamente los modelos y las bibliotecas de plantillas añadidas por las aplicaciones. - Mapea peticiones web a vistas. - Ofrece gran capacidad de escalabilidad. Arquitectura Django aparenta implementar el patrón MVC, pero el Controlador es llamado Vista y la Vista Template. Esto se debe a que, al diseñar Django, no se buscó apegarse a nada en particular, si no desarrollar una herramienta que funcione lo mejor posible. Por lo tanto, puede decirse que éste es un framework MTV: Modelo, Template, Vista. Si bien es cierto que se asemeja mucho a la implementación del patrón MVC, para Django la Vista describe qué datos serán presentados y no cómo se verán los mismos. Aquí es donde entran en juego los Templates, que describen cómo los datos son presentados. Se dice que el Controlador de un MVC clásico está representado por el propio framework. Es decir, el sistema que envía una petición a la Vista correspondiente, de acuerdo a la configuración de URL de Django (archivo de configuración). Procesamiento de una petición Teniendo en cuenta la arquitectura, cuando Django recibe una petición, lo primero que hace es crear un objeto HttpRequest que la representa y servirá como abstracción para trabajar sobre diferentes servidores. Luego se realiza la resolución de la URL. Esto consiste en seleccionar la función de la Vista (a partir de la URL especificada en la petición) que participará en la creación de la respuesta. 24

38 Una vez que se ha resuelto qué función resolverá la URL especificada, se invoca a la función de la Vista con el objeto petición como primer parámetro. Aquí se realiza el trabajo pesado como: consultas a la base de datos, carga de Templates y generación de HTML. Se devuelve un objeto HTTP response o una excepción. Middleware Django provee tres puntos diferentes en los que permite ejecutar clases middleware, previamente definidas en el archivo de configuración. Una misma clase puede ejecutarse en más de un punto, estas son las opciones: - Request middleware: se ejecuta después de crear el objeto HttpRequest, pero antes de resolver la URL, permitiendo modificar el objeto request o devolver una respuesta propia antes de que el resto de la aplicación ejecute. - View middleware: es ejecutado después de la resolución de la URL, pero antes de ejecutar la Vista correspondiente. Permite ejecutar operaciones antes y después de la ejecución de la Vista. La Vista podría llegar a no ejecutarse en absoluto. Response middleware: se ejecuta al final, después de que el objeto response haya sido creado y antes de entregarlo al cliente. Utilizado para realizar las modificaciones finales Localización geográfica La localización geográfica es el proceso de detección de la posición geográfica de un objeto en el que, a partir de cierta información, es posible definir la localización espacial (latitud y longitud) del mismo. Este proceso es utilizado con mucha frecuencia en los sistemas de información geográfica. Actualmente existen cuatro métodos principales utilizados para la localización geográfica: 25

39 Por IP: es la más utilizada actualmente en entornos web. Se basa en utilizar información de los rangos de IP asignados a distintas áreas geográficas por los Proveedores de Servicio de Internet. Sin embargo su precisión no es muy buena ya que los rangos de IPs que asignan las operadoras a diferentes áreas geográficas varían a menudo y no existe ninguna obligación de comunicar su modificación. Por triangulación de antenas WIFI: es realizada por un dispositivo usando los valores de nivel de señal de las antenas WIFI cercanas como dato de entrada. Generalmente el dispositivo consulta alguna base de datos que contiene la posición geográfica de las antenas WIFI y en función de esto, unido a la fuerza de la señal recibida por cada antena WIFI, calcula su propia posición geográfica. Su flaqueza es que requiere conocer la posición de las antenas WIFI, de lo contrario no es posible calcular la posición geográfica del dispositivo. Por triangulación de antenas de telefonía: funciona de forma similar a la localización por triangulación de antenas WIFI, con la diferencia de que se triangula utilizando los valores de señal que recibe un dispositivo móvil de las antenas de telefonía. Generalmente es usada por las operadoras, que disponen de todos los datos geográficos de sus antenas. De este modo no existe el problema de no conocer la posición geográfica de las antenas. Sin embargo, puede no ser fiable si el dispositivo está muy alejado de cualquier antena de telefonía. Por GPS: es realizada por un dispositivo móvil que cuenta con un recibidor de señal GPS (Global Position System). El sistema GPS funciona mediante una red de 27 satélites (24 operativos y 3 de respaldo) en órbita sobre la Tierra. El GPS permite determinar en todo momento la posición geográfica del dispositivo y de esta manera el dispositivo puede ofrecer información sobre su localización geográfica a terceros. 26

40 Geocodificación Es el proceso de asignar coordenadas geográficas a puntos del mapa (direcciones, puntos de interés, etc.). Las coordenadas geográficas producidas pueden luego ser usadas para localizar el punto del mapa en un Sistema de Información Geográfica. La principal ventaja de este método es que es barato. Además, se pueden usar conjuntos de marcas (los puntos a partir de los cuales se interpolan los demás) con diferente granularidad (mayor, si se dispone de de ellas, o menor, si el coste es importante). Este método presenta diferentes problemas: En general, las calles suelen llevar los números pares e impares en lados opuestos, pero esto no es siempre así. Muchas calles, sobre todo en ciudades antiguas, no son rectas. En algunas ciudades, el mismo nombre es usado para una calle principal y sus perpendiculares. La interpolación asume que los números de la calle están equidistantes, lo que típicamente es inexacto. La precisión de los sistemas de geocodificación suele referirse al porcentaje de respuestas, no al de respuestas válidas. Por ejemplo, un "99% match" significa que, de cada 100 llamadas a la función de geocodificación, 99 dan una respuesta. Esta respuesta puede ser completamente falsa. 27

41 2. Estado del arte 28

42 2.1. Introducción El proyecto es una aplicación web en la que los usuarios publican objetos, que posean y que ya no utilicen, pero que no quieran tirarlos todavía porque piensen que pueden seguir usándose. Es cierto que este concepto no tiene nada de novedoso, ya que la adquisición de objetos de segunda mano ha existido siempre, incluido Internet. Los objetos de segunda mano son aquellos que ya han sido utilizados o bien han sido poseídos por otra u otras personas. En torno a este uso, se han generado diferentes tipos de mercado, referentes sobre todo a una serie de productos y artículos determinados. Los objetos de segunda mano se suelen devaluar por su antigüedad, estado y en muchas ocasiones solamente por el hecho de no ser nuevo y haber sido estrenado con anterioridad al usuario que lo adquiere. Este tipo de objetos de segunda mano son los que aquí interesan, ya que en otras ocasiones estos artículos pueden llegar a incrementar su precio, debido a antigüedad ya que son objetos realmente antiguos, que no se fabrican o venden en ninguna parte. A veces el mero hecho de haber pertenecido a alguien famoso o importante, puede incrementar el precio en porcentajes astronómicos. Aunque el tipo de objeto con el que la aplicación va a funcionar esté bien definido, esto no quiere decir que el proyecto consista en una página de venta de segunda mano aunque se asemeje mucho. Actualmente se pueden obtener artículos de segunda mano en diferentes lugares: desde los rastros de las ciudades, hasta los mercadillos de barrios o ferias de los pueblos. La ventaja que ofrecen los rastros o rastrillos, es que los productos que se venden tienen un precio menor a lo normal. Además, los clientes sólo preguntan por los productos disponibles. La desventaja es el tener que desplazarse físicamente hasta él, únicamente en los días señalados durante los cuales está instalado. 29

43 Otra posibilidad donde adquirir o vender productos de segunda mano es a través de los anuncios clasificados. Estos anuncios ofrecen la ventaja de tener un mayor rango en un producto en concreto que el rastrillo además de estar clasificados por categorías, por lo que puede encontrarse un mayor abanico de productos que en el mercadillo. En este tipo de anuncios es necesaria una descripción del producto, los datos de contacto y en algunas ocasiones se incluye el valor del mismo. La desventaja que tienen los anuncios clasificados publicados en la prensa escrita es que, una vez vendido el producto, todavía pueden llegar llamadas preguntando por él hasta que no se retire el anuncio. Otra desventaja que tiene es el coste al que se ven forzados a pagar por publicarlos. Este inconveniente se ve salvado gracias a la aparición de Internet y las técnicas digitales, ya que la gran mayoría de estas publicaciones digitales son gratuitas para los usuarios al tener unos costes menores de mantenimiento de sus infraestructuras respecto a los medios impresos. En Internet existen cientos de páginas de anuncios clasificados: ebay, Amazon, MercadoLibre, tablondeanuncios.com, campusanuncios.com, habitamos.com En todos estos sitios web se puede publicar un anuncio de manera gratuita además de tener una inmensa posibilidad de anuncios clasificados y productos de segunda mano. Además algunos de ellos clasifican los anuncios publicados por regiones o ciudades. Es cierto que todas estas ventajas facilitan la compra-venta y hacen estas páginas muy atractivas para el usuario. Sin embargo, la inmensa mayoría de estas páginas incluye publicidad en sus páginas. También es cierto que, aunque el campo de localidad es una característica favorable, no es un campo demasiado específico, lo que puede convertirse en un inconveniente en ciudades o regiones muy grandes. La página web más característica es el dominio nolotiro.com, en el que los usuarios publican gratuitamente anuncios de productos que no desean. Esta página ofrece las ventajas de las páginas de anuncios clasificados ya que ofrece publicaciones gratuitas y un buscador de productos. Además la gente que oferta los productos no los vende por ningún precio, simplemente lo regala. En dicha página se agrupan los anuncios por 30

44 zonas que son ciudades españolas. Este campo, sin embargo, es el mayor inconveniente de esta página ya que es una información demasiado genérica, no es muy precisa. Como ejemplo de este inconveniente se observa en que son los propios usuarios los que especifican en qué zona de esa ciudad se encuentran Web Introducción El término utilizado para referirse a una segunda generación en la historia del desarrollo de tecnología web basada en comunidades de usuarios y una gama especial de servicios, como por ejemplo las redes sociales, los blogs, o los wikis, que fomentan la colaboración y el intercambio ágil y eficaz de información entre los usuarios. La Web 2.0 es también llamada web social por el enfoque colaborativo y de construcción social de esta herramienta. El concepto original del contexto, llamado Web 1.0, eran páginas estáticas programadas en HTML que no eran actualizadas frecuentemente. El éxito de las.com dependía de webs más dinámicas donde los sistemas de gestión de contenidos servían páginas HTML dinámicas creadas al vuelo desde una actualizada base de datos. En ambos sentidos, el conseguir visitas y la estética visual eran considerados como factores importantes. Los teóricos de la aproximación a la Web 2.0 creen que el uso de la web está orientado a la interacción y redes sociales, que pueden servir contenido que explota los efectos de las redes, creando o no webs interactivas y visuales. Es decir, los sitios Web 2.0 actúan más como puntos de encuentro, o webs dependientes de usuarios, que como webs tradicionales. 31

45 Origen del término El término fue acuñado por Dale Dougherty de O'Reilly Media en una tormenta de ideas con Craig Cline de MediaLive para desarrollar ideas para una conferencia. Dougherty sugirió que la web estaba en un renacimiento, con reglas que cambiaban y modelos de negocio que evolucionaban. Reclutó a John Battelle para dar una perspectiva empresarial, y O'Reilly Media, Battelle, y MediaLive lanzaron su primera conferencia sobre la Web 2.0 en Octubre del La segunda conferencia se celebró en octubre de 2005, en donde resumieron los principios clave que creen que caracterizan a las aplicaciones Web 2.0: - La web como plataforma. - Efectos de red conducidos por una "arquitectura de participación". - Innovación y desarrolladores independientes. - Pequeños modelos de negocio capaces de difundir servicios y contenidos. - El perpetuo beta. - Software por encima de un solo aparato. En general, cuando se menciona el término Web 2.0 se hace referencia a una serie de aplicaciones y páginas de Internet que utilizan la inteligencia colectiva para proporcionar servicios interactivos en red dando al usuario el control de sus datos. Así, puede entenderse como Web 2.0 a "todas aquellas utilidades y servicios de Internet que se sustentan en una base de datos, la cual puede ser modificada por los usuarios del servicio, ya sea en su contenido (añadiendo, cambiando o borrando información o asociando datos a la información existente), pues bien en la forma de presentarlos, o en contenido y forma simultáneamente."- (Ribes, 2007) 32

46 Tecnología Se puede decir que una web está construida usando tecnología de la Web 2.0 si se caracteriza por las siguientes técnicas: - CSS, marcado XHTML válido semánticamente y microformatos. - Técnicas de aplicaciones ricas no intrusivas, como por ejemplo AJAX. - Java Web Start. - XUL (XML-based User-interface Language). - Redifusión/Agregación de datos en RSS/ATOM. - URLs sencillas con significado semántico. - Soporte para postear en un blog. - JCC y APIs REST o XML. - JSON (JavaScript Object Notation). - Algunos aspectos de redes sociales. - Aplicación web híbrida). Y en general: - El sitio no debe actuar como un "jardín cerrado": la información debe poderse introducir y extraer fácilmente. - Los usuarios deberían controlar su propia información - Basada exclusivamente en la web: los sitios Web 2.0 con más éxito pueden ser utilizados enteramente desde un navegador. - La existencia de autolinks es requisito imprescindible Software del servidor La funcionalidad de Web 2.0 se basa en la arquitectura existente de servidor web pero con un énfasis mayor en el software dorsal. La redifusión sólo se diferencia nominalmente de los métodos de publicación de la gestión dinámica de contenido, pero los servicios web requieren normalmente un soporte de bases de datos y flujo de trabajo 33

47 mucho más robusto y llegan a parecerse mucho a la funcionalidad de Internet tradicional de un servidor de aplicaciones. El enfoque empleado hasta ahora por los fabricantes suele ser bien un enfoque de servidor universal, el cual agrupa la mayor parte de la funcionalidad necesaria en una única plataforma de servidor, o bien un enfoque plugin de servidor web con herramientas de publicación tradicionales mejoradas con interfaces API y otras herramientas. Independientemente del enfoque elegido, no se espera que el camino evolutivo hacia la Web 2.0 se vea alterado de forma importante por estas opciones Comparación con la Web Semántica En ocasiones se ha relacionado el término Web 2.0 con el de Web Semántica. Sin embargo ambos conceptos, corresponden más bien a estados evolutivos de la web, y la Web Semántica correspondería en realidad a una evolución posterior, a la Web 3.0 o web inteligente. La combinación de sistemas de redes sociales como Facebook, Twitter, FOAF y XFN, con el desarrollo de etiquetas, que en su uso social derivan en folcsonomías, así como el plasmado de todas estas tendencias a través de blogs y wikis, confieren a la Web 2.0 un aire semántico sin serlo realmente. Sin embargo, en el sentido más estricto para hablar de Web Semántica, se requiere el uso de estándares de metadatos como Dublin Core y en su forma más elaborada de ontologías y no de folcsonomías. De momento, el uso de ontologías como mecanismo para estructurar la información en los programas de blogs es anecdótico y sólo se aprecia de manera incipiente en algunos wikis. Por tanto se puede identificar la Web Semántica como una forma de Web 3.0. Existe una diferencia fundamental entre ambas versiones de web (2.0 y Semántica) y es el tipo de participante y las herramientas que se utilizan. La 2.0 tiene como principal protagonista al usuario humano que escribe artículos en su blog o colabora en un wiki. El requisito es que además de publicar en HTML emita parte de sus aportaciones en diversos formatos para compartir esta información como son los RSS, ATOM, etc. 34

48 mediante la utilización de lenguajes estándares como el XML. La Web Semántica, sin embargo, está orientada hacia el protagonismo de procesadores de información que entiendan de lógica descriptiva en diversos lenguajes más elaborados de metadatos como SPARQL, POWDER u OWL que permiten describir los contenidos y la información presente en la web, concebida para que las máquinas "entiendan" a las personas y procesen de una forma eficiente la avalancha de información publicada en la web Aplicaciones Educativas Anteriormente Internet era propiamente unidireccional, es decir, la información era más bien de corte informativo y no permitía la interacción directa con y entre los usuarios. Hoy en día, se ha convertido en bidireccional y permite la interacción de todo tipo de contenido, sean estos videos, imágenes, textos e inclusive almacenamiento y edición de archivos online y en tiempo real. Estas herramientas permiten la integración de un tejido social, es decir, una red de personas que pueden interactuar a través de los espacios que se han generado en internet, tales como blogs, google groups, twitter, facebook, wikipedia y un sinfín de útiles aplicaciones que permiten la interrelación de información. En este sentido, la información necesita ser procesada, asimilada en aprendizajes útiles para los propósitos de la educación, que verdaderamente incidan sobre los conocimientos que imparten los docentes en sus aulas. Así, la web se basa en un componente social, por lo que aplicada en el ámbito educativo, constituye un potente medio para construir el conocimiento de forma colaborativa, mediante aportaciones individuales que enriquezcan el aprendizaje y la práctica docente. En este sentido, la información circula en internet y es necesario desarrollar competencias necesarias para recopilar, organizar y procesar la información para generar contenidos oportunos y aplicables en la vida diaria. Así por ejemplo, se podría utilizar google earth, al momento de impartir la clase de geografía o historia universal para ubicarnos en el espacio y en el tiempo, creando estrategias de participación de manera presencial o virtual con los alumnos, al tiempo que se generan respuestas en determinados blogs creados para la materia, y se suben los productos escritos formales al correo electrónico o a un escritorio virtual o a officelive workspace, que da la posibilidad de subir y compartir archivos online, al tiempo que se pueden editar por los usuarios participantes. 35

49 2.3. Redes Sociales Historia Desde su ingreso, los sitios de redes sociales tales como MySpace, Facebook, Cyworld, Twitter, Meeterh y Bebo han atraído a millones de usuarios, muchos de los cuales han integrado estos sitios en sus prácticas diarias. El primer sitio de redes sociales reconocibles puesto en marcha en SixDegrees.com permitía a los usuarios crear perfiles, lista de amigos y amigos de sus amigos. De 1997 a 2001, AsianAvenue, Blackplanet y MiGente permitían a los usuarios crear relaciones personales y profesionales, creando perfiles que permitían a los usuarios identificar amigos en sus redes sin pedir la aprobación de esas conexiones. Desde entonces diversas redes se han creado unas permanecen y otras han desaparecido, según la zona geográfica el líder puede ir cambiando, pero a la fecha los principales competidores a nivel mundial son: Hi5, MySpace, Facebook, Twitter. MySpace se instaló en 2003 y se ha diferenciado de otros sitios porque permite a los usuarios personalizar sus páginas. Los adolescentes fueron los primeros en adoptarlo y MySpace floreció a través de la atracción de este grupo demográfico. MySpace incluso ha modificado su política de usuario para permitir a los menores de edad crear sus propios perfiles a raíz de la demanda en el segmento de mercado. Conforme el sitio ha crecido, tres poblaciones se empezaron a formar: los músicos/artistas, jóvenes y adultos en su etapa posterior a la universidad. Facebook fue creado originalmente para apoyar a las redes universitarias, en 2004 los usuarios del sitio estaban obligados a proporcionar las direcciones de correo electrónico asociada con las instituciones educativas. Este requisito lo llevó a ser un modelo de acceso relativamente cerrado y por lo que los usuarios tenían la percepción de la web como un sitio íntimo y privado de una comunidad demográfica cerrada. Facebook 36

50 posteriormente se ha ampliado para incluir a los estudiantes de secundaria, profesionales, y finalmente todos los usuarios potenciales de Internet. A diferencia de otros sitios de redes sociales, en Facebook los usuarios sólo pueden hacer públicos sus perfiles a otros usuarios del sitio. Otra característica que distingue a Facebook es la capacidad para desarrolladores externos de crear aplicaciones lo que permite a los usuarios personalizar sus perfiles y realizar otras tareas Tecnologías actuales Una revisión de los sitios de redes sociales hace evidente que sus fundamentos tecnológicos están basados en la consolidación de aplicaciones de uso común en un único sitio. Se emplean las tecnologías estándares, como el correo electrónico y sus protocolos; http para facilitar las operaciones de subir o bajar información ya sea fotos o información sobre el perfil; la mensajería instantánea y los otros protocolos de uso común que se pueden encontrar a lo largo de muchas páginas web. Las características de las salas de chat también están disponibles y permiten a los usuarios conectarse instantáneamente en modalidad de uno a uno o en pequeños grupos en función de la oferta del sitio. Los principales proveedores de sitios de redes sociales están construidos sobre plataformas que apoyan las necesidades de los consumidores con diferentes herramientas para facilitar el intercambio de información. Estas tecnologías se encuentran en una etapa de madurez, se usan de forma generalizada por lo que son consideradas un componente integral de muchos de los principales sitios. El reciente despliegue de la nube de computación y las ofertas de almacenamiento han permitido a los proveedores ofrecer los servicios para satisfacer su creciente demanda. Los dispositivos móviles se están convirtiendo en una fuente primaria de acceso significativo de los consumidores de estas redes sociales. Esto ha sido fundamental en el cumplimiento de los requisitos de conectividad que impulsa muchas de las características de redes sociales. Como se trata de mercados maduros probablemente habrá innovaciones que seguirán impulsando las nuevas características y capacidades que se adapten a la satisfacción de necesidades de este mercado demográfico. Para los sitios de redes sociales no existen normas específicas para el despliegue de la tecnología 37

51 de cada sitio. Sin embargo, como todos ellos son ofrecidos a través de Internet utilizando navegadores web, deben atenerse a las normas comunes que son impulsadas por la aplicación y el diseño funcional de las necesidades. Por lo tanto, las normas son inducidas más por el mercado y menos por un consejo de administración o por reglamentos oficiales. A medida que los nuevos navegadores y plataformas se han desplegado los proveedores están obligados a adaptar e integrar y a permitir que sus sitios sigan siendo utilizables por nuevos consumidores Diseminación de información Una de las funciones primordiales de los sitios de redes sociales es la diseminación de la información de los usuarios, debido a esto la seguridad de la información personal se ha vuelto un asunto de prioridad para varios sitios de redes sociales. Un ejemplo es Facebook en donde sentencia como sigue No se podrá reclamar ningún derecho de contenido original que los usuarios suban a la red, una vez que los usuarios hayan cerrados sus cuentas. Este ha causado controversia entre los usuarios que son dueños de la información debido a que el proveedor determina que éste tiene algún grado de pertenencia. El proveedor Facebook, se adelanto diciendo que no estaría reclamando ningún grado de pertenencia sino que sólo era para garantizar que el material que se subiera sea conforme a los comportamientos establecidos como correctos. Otra funcionalidad dentro de los sitios de redes sociales es el intercambio de información para compartir fotografías, la cual podría ser la funcionalidad más popular actualmente. Hasta hace pocos años, un individuo o una familia que quisiera compartir información en línea, tendría que haber comprado su dominio e incluso diseñar su propia página web, en la actualidad este tipo de usuarios, simplemente se deben suscribir a algún sitio de comunidad y comenzar a compartir cualquier información. El etiquetar fotos es una función más de estos sitios de redes sociales lo cual se hace subiendo las fotos y colocándoles el nombre de la personas en cuestión. Otra funcionalidad mas es el hecho de poder compartir audio y video, lo cual permite al cliente el personalizar su página y estructurarla de una manera personal, algunos clientes crean listas de reproducción dentro de sus sitios personales, y algunos músicos incluso pueden crear sus propias 38

52 melodías para sus visitantes. Otra funcionalidad que ha tomado gran auge es la de mensajes de texto cortos en tiempo real, como es el caso de Twitter, en la que algunos proveedores de sitios de redes sociales han agregado la compatibilidad. De esta manera se seguirán añadiendo diferentes funcionalidades a los sitios de redes sociales como lo que ha anunciado Facebook en el mes de junio del 2009 Se anuncia la integración con Xbox Live en la próxima Expo en Los Ángeles. Ahora los usuarios podrán actualizar su estado, así como comentar fotos y jugar con diferentes amigos en línea con Xbox live Software para el análisis de redes sociales El uso de las ideas y herramientas de la rama de las matemáticas conocida como "teoría de grafos" ha ayudado a desarrollar una gran cantidad de herramientas y software de análisis. A diferencia de estas herramientas de análisis, muchas compañías han desarrollado también software dirigido a promover relaciones entre internautas, ya sea con fines laborales o lúdicos Redes sociales en Internet El software germinal de las redes sociales parte de la teoría de los Seis Grados de Separación, según la cual toda la gente del planeta está conectada a través de no más de seis personas. De hecho, existe una patente en EEUU conocida como six degrees patent por la que ya han pagado Tribe y LinkedIn. Hay otras muchas patentes que protegen la tecnología para automatizar la creación de redes y las aplicaciones relacionadas con éstas. El origen de las redes sociales se remonta, al menos, a 1995, cuando Randy Conrads crea el sitio web classmates.com. Con esta red social se pretende que la gente pueda recuperar o mantener el contacto con antiguos compañeros del colegio, instituto, universidad, etcétera. 39

53 En 2002 comienzan a aparecer sitios web promocionando las redes de círculos de amigos en línea cuando el término se empleaba para describir las relaciones en las comunidades virtuales, y se hizo popular en 2003 con la llegada de sitios tales como MySpace o Xing. Hay más de 200 sitios de redes sociales, aunque Friendster ha sido uno de los que mejor ha sabido emplear la técnica del círculo de amigos. La popularidad de estos sitios creció rápidamente y grandes compañías han entrado en el espacio de las redes sociales en Internet. Por ejemplo, Google lanzó Orkut el 22 de enero de Otros buscadores como KaZaZZ! y Yahoo crearon redes sociales en En estas comunidades, un número inicial de participantes envían mensajes a miembros de su propia red social invitándoles a unirse al sitio. Los nuevos participantes repiten el proceso, creciendo el número total de miembros y los enlaces de la red. Los sitios ofrecen características como actualización automática de la libreta de direcciones, perfiles visibles, la capacidad de crear nuevos enlaces mediante servicios de presentación y otras maneras de conexión social en línea. Las redes sociales también pueden crearse en torno a las relaciones comerciales. Las herramientas informáticas para potenciar la eficacia de las redes sociales online (software social), operan en tres ámbitos, las 3Cs, de forma cruzada: o o o Comunicación, ayudan a poner en común conocimientos. Comunidad, ayudan a encontrar e integrar comunidades. Cooperación, ayudan a hacer cosas juntos. El establecimiento combinado de contactos es una aproximación a la red social que combina elementos en línea y del mundo real para crear una mezcla. Una red social de personas es combinada si se establece mediante eventos cara a cara y una comunidad en línea. Los dos elementos de la mezcla se complementan el uno al otro. 40

54 Las redes sociales continúan avanzando en Internet a pasos agigantados, especialmente dentro de lo que se ha denominado Web 2.0, y dentro de ella, cabe destacar un nuevo fenómeno que pretende ayudar al usuario en sus compras en Internet. Las redes sociales de compras tratan de convertirse en un lugar de consulta y compra. Un espacio en el que los usuarios pueden consultar todas las dudas que tienen sobre los productos en los que están interesados, leer opiniones y escribirlas, votar a sus productos favoritos, conocer gente con sus mismas aficiones y, por supuesto, comprar ese producto en las tiendas más importantes con un solo clic. Esta tendencia tiene nombre, se llama Shopping

55 3. Antecedente: chatarra.me 42

56 3.1. Chatarra.me El proyecto reutiliza.me es una idea que surge a partir de un proyecto web anterior. Dicho proyecto, denominado chatarra.me, surge ante la necesidad de mejorar y facilitar el servicio que ofrecen los chatarreros convencionales. Actualmente este servicio se realiza de forma arcaica, ya que el chatarrero pasa periódicamente por las viviendas anunciándose mediante un megáfono. El usuario que desee realizar la venta, cuando oye que se acerca el chatarrero, tiene que salir a la calle para avisarle. Este sistema tiene una serie de desventajas tanto para el usuario como para el chatarrero. Un inconveniente para el usuario es que, para deshacerse de alguna chatarra, tiene que hacerlo cuando pase el chatarrero, por lo que puede pasar más tiempo del deseado, y no lo más rápido posible que es lo deseable cuando se trata de deshacerse de algo. También es muy incómodo para el usuario tener que estar atento a ver si oye pasar al chatarrero, ya que debe permanecer atento, de media, varios días. Esto puede interferir en la actividad diaria del usuario debido a que tiene que permanecer por si aparece el chatarrero. Para el chatarrero el inconveniente es la incertidumbre. Primero porque, cada vez que sale a por chatarra, tiene que dar vueltas sin saber si habrá alguien que solicite su servicio. Esto puede llevar a un gasto importante de gasolina y de tiempo. Segundo porque no sabe el tamaño o cantidad de chatarra recogida cada vez que sale. Chatarra.me quería ofrecer un servicio web en el que pudieran encontrarse tanto los usuarios como los chatarreros con una aplicación que les facilitara el intercambio de la chatarra. Mediante esta página web los usuarios podrían informar que tienen chatarra disponible para los chatarreros, indicando la dirección de recogida, hora o franjas horarias para recoger la chatarra y también una pequeña descripción de la chatarra publicada. Por otra parte los chatarreros podrían, mediante una sencilla y económica cuenta en la página, indicar en qué zona geográfica con un radio concreto quería conocer las chatarras publicadas, saber cuándo recogerlas, que tamaño tienen y también consultar cuál sería la ruta más rápida para recoger las chatarras reservadas. 43

57 Por lo tanto, con chatarra.me el usuario se ahorraría tener que estar pendiente del chatarrero y se desharía de la chatarra en menos tiempo. Para el chatarrero supondría un menor coste de carburante y tiempo, al conocer de antemano la chatarra que tiene que recoger cada día y elegir qué chatarra recoge. Este proyecto no prosperó por el inconveniente de saber llegar a los usuarios de esta página, en concreto a los chatarreros. Si bien es cierto que, a través de Internet se podría llegar a gente dispuesta a publicar su chatarra, también es cierto que ese medio no sirve para llegar a los chatarreros. Una alternativa que supliese esa carencia sería crear una empresa que se dedicara explícitamente a este servicio usando esta aplicación como principal interfaz al usuario. La similitud lógica con este proyecto es muy grande, ya que ambas aplicaciones consisten en intermediar entre dos partes: una interesada en deshacerse de algo y otra interesada en recogerlo. También se asemejan en que ambas son aplicaciones caracterizadas en el ámbito muy local al que están dirigidas. Sin embargo chatarra.me contaría con la novedad en el mercado, mientras que reutiliza.me se encuentra ante un mercado de subastas y de venta de 2ª mano bastante explotado. 44

58 4. Estudios de APIS y servicios de terceros 45

59 4.1. Introducción Actualmente con una Internet tan conectada internacionalmente y con tanta información importante resulta imprescindible estudiar los servicios aportados por terceros que sirvan para nutrir de información a la aplicación así como para añadir funcionalidad que mejore la experiencia de navegación y el servicio ofrecido a los usuarios del sistema. Es importante estudiar qué servicios existen actualmente en Internet y cuáles de estos servicios pueden ser integrados con la aplicación a desarrollar para lograr la consecución de los objetivos del proyecto GoogleMaps API La API de GoogleMaps utiliza los datos geográficos de TeleAtlas y ofrece dos interfaces de acceso a la información geográfica: Métodos JavaScript y peticiones HTTP. Google permite la inclusión de mapas dinámicos navegables en los sitios web que hacen uso de su API. El número de peticiones a la API está limitado a peticiones diarias desde una única dirección IP. Este límite no es realmente importante si se utilizan los métodos de acceso JavaScript en lugar de peticiones HTTP, ya que de este modo las peticiones son hechas desde la máquina del cliente en vez de desde el servidor. De este modo se logran peticiones por cliente diarias de límite y no en total como ocurriría si el servidor web fuera el que realizara las peticiones HTTP. Por otro lado la API de GoogleMaps ofrece un método de geocodificación que permite convertir direcciones escritas en cadenas de texto a una latitud y longitud concretas así como relacionarlas con la población geográfica a la que pertenecen. 46

60 4.3. Google AJAX API Una funcionalidad no disponible en la API de GoogleMaps es la posibilidad de localizar geográficamente al usuario. Sin embargo la API de AJAX que también pertenece a Google es capaz de realizar esta tarea. Cuando una aplicación utiliza el cargador de API AJAX de Google, éste intenta determinar la ubicación geográfica del cliente en función de su dirección IP. Si este proceso se realiza correctamente, la ubicación del cliente, limitada al nivel metropolitano, queda disponible para ser utilizada por el sitio web mediante JavaScript. Si el proceso no encuentra coincidencias, la propiedad se establece en "null". Hay que tener en cuenta que los rangos de IP pertenecientes a áreas metropolitanas cambian cada cierto tiempo y no se mantiene un registro común de todas ellas, por lo que la información de localización del usuario ofrecida por esta API no es 100% fiable. Aún así resulta muy útil en la mayoría de aplicaciones geográficas Freebase Freebase es una base de datos mundial libre generada mediante las aportaciones de información de personas y organizaciones de todo el mundo. También incluye información obtenida de distintas bases de datos de internet, como Wikipedia, estructurada de forma que agentes software puedan detectar relaciones y obtener metainformación semántica. Dispone de una API libre que hace uso de un lenguaje de marcado propio para las peticiones. Así mismo está disponible para descarga en formato CSV dividida en bloques de áreas de conocimiento. Freebase cuenta acutalmente con información sobre cerca de áreas geográficas Maxmind GeoLite City GeoLite City es una base de datos gratuita que incluye información sobre ciudades de todo el mundo asociadas a rangos de IPs asignados a dichas ciudades para la utilización 47

61 de los datos en sistemas de geolocalización. Actualmente cubre información asociada a cerca de ciudades del mundo Geonames Geonames es un servicio web geográfico libre y una base de datos distribuida bajo licencia libre Creative Commons. La información geográfica es creada y corregida por la comunidad de usuarios. Es probablemente el servicio web libre con mayor información geográfica mundial. Actualmente consta de información sobre 2.2 millones de lugares geográficos habitados y 1.8 millones de nombres alternativos para éstos. Geonames ofrece varios servicios de API que permiten acceder a todos estos datos de forma gratuita y libre. También permite descargar la base de datos en formato CSV para poder utilizarla localmente sin necesidad de acceder a las APIs Instituto Nacional de Estadística El sitio web del Instituto Nacional de Estadística posee información de censo de todas las poblaciones de España. Esta información puede descargarse en formato CSV y permite conocer todas áreas pobladas de españa así como información demográfica asociada a éstas. No existe ningún tipo de API pública, por lo que la única opción para trabajar con los datos del INE es programar un script de importación de los datos descargados a una base de datos World Gazetteer World Gazetteer es un sitio web que contiene información de poblaciones de todo el mundo recopilando datos de oficinas de estadística, obras de consulta, mapas, etc. La información de puede ser descargada en formato CSV. Ha sido creado por Stefan Helders y es mantenido de forma comunitaria. 48

62 4.9. Amazon S3 Amazon S3 es un sistema de archivos en red construido sobre la infraestructura de Amazon. La empresa Amazon, con amplia experiencia en escalabilidad de entornos web, alquila su infraestructura de almacenamiento y de proceso ofertando web services que son accedidos mediante una API pública. Amazon S3 permite almacenar y servir vía web una cantidad ilimitada de archivos. Se cobra una tarifa mensual por almacenamiento y transferencia de datos que se ajusta al uso que se ha realizado de la infraestructura de almacenamiento de Amazon durante ese mes. El almacenamiento en Amazon ofrece escalabilidad y simplicidad a bajo coste, resultando una opción adecuada para delegarle la gestión de archivos de media (imágenes, vídeos, etc.) de cualquier servicio web. Amazon S3 basa su sistema de almacenamiento en tres conceptos: Buckets de almacenamiento: imitan el funcionamiento de un directorio contenedor de archivos. Los nombres de los buckets están compartidos entre toda la red de Amazon S3, por lo que si alguien crea un bucket ningún otro usuario del sistema de almacenamiento podrá usar ese nombre para un nuevo bucket. Objects: son las entidades de datos en sí, los archivos. Un object almacena tanto los datos del archivo que representa como los metadatos necesarios para ser gestionados por S3. Un object puede ocupar entre 1 byte y 5 Gigabytes. Keys: claves únicas que identifican a los objects de cada bucket. Un object se identifica de manera unívoca dentro de todo el sistema de Amazon S3 mediante el nombre del bucket al que pertenece y la key que tienen asignada. 49

63 4.10. Amazon CloudFront Amazon CloudFront es otro de los web services que ofrece Amazon a terceros. Se trata de una red de distribución de contenidos. Una red de distribución de contenidos o CDN (Content Delivery Network) es una colección de servidores web distribuidos en varias ubicaciones geográficas para ofrecer contenidos de manera más eficiente a los usuarios. El servidor seleccionado para la entrega de contenido a un usuario concreto es típicamente basado en una red de medida de proximidad. Por ejemplo, el servidor de red con el menor número de saltos o el servidor con el menor tiempo de respuesta es elegido frente a los otros. Amazon CloudFront es una red de distribución de contenidos que sirve información desde catorce áreas geográficas actualmente: ocho en Estados Unidos (Ashburn (VA), Dallas/Fort Worth (TX), Los Angeles (CA), Miami (FL), Newark (NJ), Palo Alto (CA), Seattle (WA), St. Louis, (MO), cuatro en Europa (Amsterdam, Dublín, Frankfurt y Londres) y dos en Asia (Hong Kong y Tokyo). 50

64 5. Estudio de la arquitectura 51

65 5.1. Introducción El objetivo de este capítulo es definir las posibles soluciones de arquitectura técnica que satisfagan tanto los requisitos como las restricciones de diseño. Para ellos, se definirán las posibles soluciones a modo de alternativas para someterlas a estudio y elegir los componentes software y hardware más adecuados para ser desarrollada e implementada Especificación y evaluación de alternativas Elección de lenguaje de programación Primeramente se realiza la elección del lenguaje de programación más adecuado para el desarrollo. El lenguaje de programación es una de las decisiones más importantes a tomar ya que el tiempo de desarrollo, la calidad del software, y la capacidad del software para funcionar en la plataforma se ven afectados por ella. Para el desarrollo de la aplicación web se ha valorado la posibilidad de utilizar uno de tres posibles lenguajes interpretados útiles para desarrollo web. Se han considerado PHP, Python y Ruby. Se han valorado cinco características esenciales que afectan directamente al tiempo de desarrollo, calidad del software, mantenibilidad de código y coste del desarrollo. Las características tenidas en cuenta para este estudio son: Nivel del lenguaje Permite determinar la facilidad de mantenimiento del código y el tiempo necesario para el desarrollo. También afecta directamente al coste del mismo. Una aplicación desarrollada con un lenguaje de alto nivel tendrá un mantenimiento más sencillo y realizar cualquier modificación en el código será más fácil y rápido. Por otra parte el tiempo de desarrollo será inferior porque se requerirán menos líneas de código para que el programa realice tareas concretas. 52

66 Orientación a objetos Afecta a la flexibilidad y la simplicidad del código. Un lenguaje que soporta orientación a objetos resulta más potente y ofrece mayor flexibilidad que uno sin orientación a objetos. El código también resulta más simple y fácil de entender y extender con lenguajes que soportan orientación a objetos. Sintaxis del lenguaje Permite saber si la sintaxis del lenguaje es complicada o sencilla. Con una sintaxis sencilla el tiempo de desarrollo se ve reducido así como la existencia de errores en el código. Por otro lado, la sintaxis puede ser débil o potente. Con una sintaxis débil se requiere gran cantidad de código para realizar tareas medianamente complejas. Por el contrario una sintaxis potente permite realizar tareas más complejas con necesidad de menos código. El tiempo de desarrollo y, por lo tanto, también el coste del proyecto y la mantenibilidad del código se ven afectados en gran medida por la potencia de la sintaxis del lenguaje elegido. Librerías disponibles La cantidad de librerías disponibles para un lenguaje afecta directamente al tiempo de desarrollo y a la calidad del software resultante. Un lenguaje para el que existen numerosas librerías permite reducir el tiempo de desarrollo al poder integrar las necesarias en el proyecto en lugar de tener que programarlas. Generalmente, el código resultante también tendrá una calidad mayor ya que las librerías generalmente son probadas y mejoradas por otros desarrolladores. Organización de código La forma en la que se puede organizar el código y la posibilidad de separar las funciones de la aplicación siguiendo un patrón MVC (Modelo Vista y Controlador) influye directamente en la mantenibilidad y extensibilidad del código. Los lenguajes que se prestan a separar y organizar el código siguiendo un patrón MVC permiten desarrollar software más fácil de mantener y extender. 53

67 Madurez del lenguaje La madurez del lenguaje afecta a la calidad y mantenibilidad del código. Un lenguaje maduro que lleve varios años de desarrollo es más estable y genera código más fácil de mantener que un lenguaje nuevo en el que todavía existan métodos que van a ser modificados, sintaxis que va a ser cambiada, etc. A continuación se incluye la tabla que muestra las características analizadas para cada uno de los tres lenguajes considerados: PHP Ruby Python Nivel del lenguaje Alto nivel Alto nivel Alto nivel Orientación a objetos Añadida Todo se ve como un objeto Todo se ve como un objeto Sintaxis del lenguaje Poco complicada Muy sencilla y potente Sencilla y potente Librerías disponibles Gran cantidad de librerías Pocas librerías Gran cantidad de librerías Organización de código Spaguetti-code Buena Buena Madurez del lenguaje Alta Baja Alta Tabla 1 comparación de los lenguajes de programación web en estudio Se ha utilizado un sistema de puntuaciones para poder comparar en una gráfica todos los aspectos de los lenguajes estudiados. Para cada lenguaje se han asignado puntuaciones con valores entre 1 y 3 para cada una de las características. Los resultados de la comparación pueden verse en la figura 1. 54

68 3,5 3 2,5 2 1,5 PHP Ruby Python 1 0,5 0 Nivel del lenguaje Orientación a objetos Sintaxis Librerías disponibles Organicación del código Madurez Figura 1 Gráfica comparativa de lenguajes de programación Una vez realizada esta valoración se opta por Python como lenguaje preferente. Se toma esta decisión debido a la gran cantidad de librerías existentes, la orientación a objetos soportada en el núcleo de Python, la sintaxis sencilla y potente así como la madurez del lenguaje. Sin embargo se procede a valorar distintos frameworks escritos en Python, PHP y Ruby para conocer el rendimiento de estos y sus características y poder así tomar una decisión más representativa. 55

69 Elección de Framework de desarrollo de la aplicación Un framework es una estructura de soporte definida mediante la cual otro proyecto puede ser organizado y desarrollado. Suele constar de diversas librerías y funciones orientadas al entorno para el que está preparado (en este caso entorno web) que permiten a los programadores desarrollar aplicaciones tomando estas librerías y funciones como base. Teniendo en cuenta la envergadura de la aplicación web a desarrollar se ha optado por utilizar alguno de los frameworks actualmente existentes para los lenguajes analizados. Se han comparado los seis frameworks para web más utilizados actualmente: CodeIgniter, Catalyst, Django, Ruby On Rails, Symfony y TurboGears. Adicionalmente a Django se ha incluido en la comparación Django con Psyco, un módulo de Python que permite acelerar la ejecución de código. Se ha realizado una prueba de rendimiento lanzando transacciones contra cada framework sobre la misma configuración hardware y se han medido distintos parámetros. Se han simulado 300 usuarios simultáneos interactuando con el sistema. Cada usuario envía una petición al servidor y este le responde con un sencillo HTML que muestra un escueto Hola mundo. Los parámetros analizados sirven para determinar qué framework ofrece mejores resultados de rendimiento en cuanto a: - Disponibilidad Resulta de vital importancia para poder ofrecer un servicio que funcione 24/7. Para una aplicación web es indispensable que el sistema ofrezca una alta disponibilidad. 56

70 - Carga de la CPU Es uno de los factores más importantes ya que la carga que produzca el framework en la CPU determinará la escalabilidad del sistema y el soporte de picos de transacciones. - Uso de memoria El uso de memoria por parte del framework es un factor esencial que determina la escalabilidad del sistema y la disponibilidad del mismo. - Duración de transacción más larga Permite saber cuánto tardará como máximo una petición web en ser servida en caso de que haya alta carga en el sistema. - Tiempo de respuesta medio Da una idea aproximada de cuánto tarda una petición web en ser servida. Sirve como valor de referencia para saber cuánto deberían tardar una petición web estándar en ser servida. - Número de transacciones servidas en un intervalo de tiempo Permite conocer cuántas peticiones por segundo es capaz de servir el framework. Es un reflejo de la escalabilidad que ofrece el framework. Cuantas más peticiones sea capaz de servir por segundo el framework será capaz de soportar un mayor número de usuarios utilizando la aplicación web simultáneamente. El equipo utilizado para la prueba ha consistido en un servidor web con las siguientes características: CPU: Intel Core2Duo Memoria principal: 2 GB Sistema Operativo: Ubuntu Hardy Servidor web: Apache Para obtener los resultados estadísticos de las pruebas se ha utilizado Apache Bench, que es una herramienta incluida en el propio Apache con la que se puede medir, entre 57

71 otros parámetros, la carga de la CPU, la cantidad de memoria usada, tiempo de respuesta También se ha utilizado Siege, una utilidad para la comprobación y pruebas de rendimiento de regresión. Puede hacer pruebas de estrés a una URL con el número de usuarios que defina el usuario. El programa informa del número total de acciones registradas, bytes transferidos, disponibilidad, tiempos de respuesta, concurrencia y estado de finalización. Resultados de la prueba de rendimiento La primera medida que se ha obtenido es la disponibilidad ofrecida por cada framework. En este aspecto todos los frameworks han ofrecido unos resultados excelentes excepto Symfony cuya disponibilidad ha sido del 97,35%. La disponibilidad del resto de frameworks se sitúa en torno a %. Los frameworks que han ofrecido una disponibilidad del 100% han sido Catalyst, Django (stand-alone y con el módulo Psyco) y TurboGears. Todos los resultados de disponibilidad se pueden apreciar en la figura 2. 58

72 100 Disponibilidad (en %) 99, , ,5 Disponibilidad (en %) 97 96,5 96 Figura 2 Disponibilidad de cada framework En la figura 3 se puede observar el porcentaje de carga de la CPU al servir las peticiones con los distintos frameworks. En este caso TurboGears es el framework que mayor carga produce en la CPU llegando a un 54% de carga de procesamiento seguido por Ruby on Rails con un 49% de carga. El framework que mejores resultados ofrece es Django con una carga de CPU del 22% y disminuyendo a 18% al usarlo conjuntamente con el módulo Psyco. 59

73 60% Carga de la CPU (en %) 50% 40% 30% Carga de la CPU (en %) 20% 10% 0% Figura 3 Porcentaje de carga de la CPU con cada framework Además de la carga que producen los frameworks en la CPU es de vital importancia conocer la cantidad de memoria que éstos requieren para servir las peticiones. En la figura 4 se detalla el uso de memoria principal utilizada durante todo el proceso por cada framework. En este aspecto Ruby on Rails ofrece los peores resultados alejándose en gran medida de los valores obtenidos con el resto de frameworks. Durante todo el proceso de prueba Ruby on Rails ha usado MB de memoria. Catalyst es el segundo framework que más memoria ha requerido, con un uso de MB. El resto de frameworks se sitúan en un uso de memoria mucho más comedido. Django es el 60

74 framework que menos memoria ha necesitado durante toda la prueba, utilizando tan solo 8188 MB para servir todas las peticiones realizadas Memoria usada (en MegaBytes) Memoria usada (en MegaBytes) Figura 4 Memoria utilizada por los procesos de cada framework También resulta importante estudiar cuánto ha durado la transacción más larga para conocer cuánto debe esperar un usuario como máximo tras realizar una petición. En este caso CodeIgniter, Ruby on Rails, Symfony y TurboGears han tardado cerca de 30 segundos en servir una petición en el peor caso. Catalyst ha ofrecido un resultado 61

75 mejor, tardando 23 segundos en la transacción más larga. El mejor resultado lo ha obtenido Django tardando tan solo 12 segundos y 8 segundos al trabajar con el módulo Psyco. Las duraciones de la transacción más larga para cada uno de los frameworks a estudio se muestran en la figura Duración de la transacción más larga (en segundos) Duración de la transacción más larga (en segundos) Figura 5 Duración de la transacción más larga en cada framework El tiempo de respuesta medio por transacción también es un factor importante a tener en cuenta. La figura 6 ilustra el tiempo de respuesta medio requerido para servir cada petición HTTP recibida para cada uno de los frameworks. Se puede observar que 62

76 Django (tanto stand-alone como con el módulo Psyco) es el framework que menos tarda en servir las peticiones HTTP recibidas de media. En este caso el tiempo de respuesta medio es muy cercano a cero. El resto de frameworks ofrecen un tiempo de respuesta medio mucho mayor, siendo Symfony el que peores resultados ha dado en la prueba, llegando a un valor cercano a los 4 segundos de tiempo de respuesta medio. 5 Tiempo de respuesta medio (en segundos) 4,5 4 3,5 3 2,5 2 Tiempo de respuesta medio (en segundos) 1,5 1 0,5 0 Figura 6 Tiempo de respuesta medio en cada framework en segundos Por otra parte se ha estudiado el número total de transacciones servidas para conocer la capacidad para servir peticiones de cada framework. De esta forma se puede apreciar la escalabilidad de cada uno de ellos. La figura 7 muestra los resultados obtenidos en este apartado de las pruebas. Symfony ha sido el framework que peores resultados ha ofrecido sirviendo aproximadamente peticiones durante toda la prueba de 63

77 rendimiento. CodeIgniter y Ruby on Rails se sitúan por debajo de las peticiones servidas. El resto de frameworks supera esta barrera. Django es de nuevo el framework que mejores resultados ofrece llegando a servir casi peticiones en modo standalone y superando este valor sirviendo peticiones al incluir el módulo Psyco Número de transacciones servidas en total Número de transacciones servidas en total Figura 7 Número total de transacciones servidas por cada framework Además del número total de transacciones servidas por cada framework se ha estudiado el tiempo total requerido por cada uno de ellos para servir todas las transacciones. La figura 8 ilustra los resultados obtenidos. Todos los frameworks se sitúan en un umbral entre 60 y 80 segundos requeridos para servir el total de transacciones especificado en la 64

78 figura 7. Django ha sido el framework que menores tiempos ha logrado seguido por Ruby on Rails. Django ha tardado aproximadamente 60 segundos (tanto standalone como con el módulo Psyco) mientras que Ruby on Rails ha tardado 65 segundos. El resto de frameworks se sitúan en valores entre 70 y 80 segundos requeridos para servir todas las peticiones recibidas durante las pruebas de rendimiento. 90 Tiempo requerido para servir todas las transacciones Tiempo requerido para servir todas las transacciones Figura 8 Tiempo requerido por cada framework para servir todas las transacciones Utilizando el número total de transacciones servidas por cada framework y el tiempo requerido para responder las peticiones se ha calculado el número de transacciones 65

79 servidas por segundo por cada uno de los frameworks a estudio. De esta forma se obtiene un valor más representativo del rendimiento real de cada framework. En la figura 9 se puede apreciar el número de transacciones servidas por segundo por cada uno de los frameworks a estudio. Hay tres grupos claramente diferenciados: CodeIgniter y Symfony han servido menos de 100 peticiones por segundo, siendo Symfony el que peor resultados ha obtenido siendo capaz de servir tan sólo 30 transacciones por segundo. El resto de frameworks ha logrado procesar más de 100 transacciones por segundo con TurboGears alcanzando incluso las 150 transacciones por segundo. Django ha ofrecido unos resultados muy superiores al resto de frameworks llegando a servir cerca de 490 transacciones por segundo en configuración standalone y hasta 530 transacciones por segundo con el módulo Psyco. 600 Número de transacciones servidas por segundo Número de transacciones servidas por segundo Figura 9 Número de transacciones por segundo servidas por cada framework 66

80 Para agregar los resultados obtenidos en las distintas medidas de la prueba de rendimiento se ha utilizado un sistema de puntuaciones que permite establecer qué framework ofrece un mayor rendimiento. Se ha asignado una puntuación de 1 (puntuación más baja), 2 ó 3 (puntuación más alta) para cada framework en cada una de las medidas tomadas según los resultados que éste ha ofrecido. 3,5 3 2,5 2 1,5 1 Disponibilidad Carga de la CPU Memoria usada Transacción más larga Tiempo de respuesta Transacciones/segundo 0,5 0 Figura 10 Puntuación obtenida por cada framework en cada apartado La figura 10 detalla la puntuación obtenida por cada framework en cada uno de los apartados de la prueba de rendimiento y su puntuación total lograda. Se puede apreciar que Django es el framework que mayor puntuación ha obtenido, siendo standalone la implementación más recomendada. 67

81 Teniendo en cuenta todos los resultados obtenidos en la prueba de rendimiento se ha decidido elegir Django entre todos los frameworks estudiados. Además Django está desarrollado con Python, lenguaje de programación que previamente se había seleccionado como el más óptimo para el desarrollo. Con el fin de apoyar la decisión se han analizado las características de Django encontrando los siguientes puntos fuertes en la herramienta: - Fomenta el desarrollo rápido de aplicaciones (Rapid Application Development). - Permite el desarrollo de aplicaciones plug-and-play fácilmente integrables y escalables. - Genera automáticamente la estructura de la base de datos en función de los modelos de negocio definidos. - Ofrece un ORM (Mapeador de objetos relacional) con soporte para MySQL, SQLServer, PostgreSQL y Oracle. Esto evita ligarse a un gestor de bases de datos concreto y permite la modificación de la arquitectura de sistemas en cualquier momento. - Es multiplataforma sin necesidad de recompilar código alguno. Al estar desarrollado en Python la aplicación puede correr tanto en GNU/Linux, UNIX, BSD, Mac OSX, Windows, etc. Permite tener libertad a la hora de elegir el sistema operativo de desarrollo y el de producción. - Es adaptable a cambios en la arquitectura de sistemas. - Ofrece un alto soporte para internacionalización desde el núcleo de la herramienta. - Es fácilmente integrable con cualquier framework de AJAX incluyendo serializadores JSON, XML. - Permite utilizar Back-ends de almacenamiento plugables. Se pueden desarrollar Back-ends específicos para sistemas de archivos distintos. - Permite utilizar Back-ends de caché plugables. - Permite incluir middleware propio para el procesamiento de peticiones http. 68

82 Tras los resultados ofrecidos en la prueba de rendimiento y el análisis de características del framework, Django se acepta como la alternativa más adecuada para el sistema por haber demostrado su idoneidad para entornos web en cuanto a escalabilidad, flexibilidad, disponibilidad y robustez Elección del sistema gestor de bases de datos Tras la elección del framework de desarrollo se procede a estudiar el sistema gestor de bases de datos más adecuado para el proyecto. Se han estudiado dos alternativas de código abierto: MySQL y PostgreSQL. Ambos gestores son bases de datos relacionales SQL. Ambos son también utilizados ampliamente en arquitecturas web y son soportados de forma nativa por el mapeador de objetos relacional de Django. Se pretende estudiar cuál de los dos ofrece mejores prestaciones con el fin de seleccionar el sistema gestor más idóneo para el proyecto. Se han estudiado las características y los tipos de indexado soportados por ambos gestores: El indexado avanzado permite que los sistemas gestores de bases de datos optimicen las peticiones para lograr un rendimiento mayor. Se han analizado los tipos de indexado avanzado de MySQL y PostgreSQL para determinar cuál de los dos puede ofrecer mayores prestaciones en entornos web. Tras analizar los tipos de indexado soportados por cada uno de los gestores de bases de datos PostgreSQL se presenta como la alternativa más adecuada por soportar características más avanzadas en sus tipos de indexado. 69

83 Elección de Framework de JavaScript Dado que la aplicación web va a requerir un alto grado de interacción con el navegador se ha optado por elegir un framework de JavaScript para el desarrollo del front-end de la aplicación. Se han estudiado tres frameworks de JavaScript. Los tres son de código abierto y tratan de abstraer las diferencias de los distintos navegadores para permitir generar código JavaScript que se ejecute del mismo modo en todos ellos. Frameworks JavaScript sometidos a estudio: o jquery jquery es un framework JavaScript que simplifica la forma de interactuar con los documentos HTML, manipular el DOM (Document Object Model), manejar eventos, desarrollar animaciones y agregar interacción con la tecnología AJAX. o MooTools MooTools destaca por ser un framework compacto y modular. Permite desarrollar JavaScript abstrayendo particularidades de los distintos navegadores. Soporta distintos tipos de efectos, gestión de eventos e interacción AJAX. o Prototype Es un framework orientado al desarrollo dinámico que destaca por su flexibilidad y extensibilidad. Soporta AJAX y eventos. Se han valorado las seis características de los frameworks más importantes para la aplicación web a desarrollar. A continuación se especifican las características analizadas: 70

84 - Velocidad de selectores Es un factor clave en el rendimiento del framework. El tiempo de espera del usuario depende directamente del tiempo que requiera el framework en seleccionar los elementos del DOM. - Simplicidad Cuanto más simple sea el código generado con el framework más rápido será el desarrollo y más fácil será depurar el código. - Flexibilidad La flexibilidad del framework se refiere a la posibilidad de programar diferentes acciones con el mismo sin estar limitado por su estructura o sus convenciones. - Extensibilidad La extensibilidad del framework es la capacidad del mismo para ser ampliado mediante plug-ins u otros módulos de terceros que extiendan su funcionalidad. - Mantenibilidad La mantenibilidad del código es la facilidad para mantener y actualizar el código creado con el framework. Depende también de la simplicidad que ofrezca éste. - Escalabilidad La escalabilidad del framework se refiere a la capacidad del mismo para gestionar eventos y acciones complejas que puedan ocurrir simultáneamente y la capacidad del mismo para seguir ofreciendo un buen rendimiento ante dichas situaciones. 71

85 La tabla 2 muestra la comparativa entre los tres frameworks JavaScript. jquery Mootools Prototype Velocidad de selectores Alta Alta Baja Simplicidad Alta Media Baja Flexibilidad Media Alta Alta Extensibilidad Alta Alta Alta Mantenibilidad Alta Media Media Escalabilidad Alta Alta Alta Tabla 2 Comparación de los frameworks JavaScript en estudio Se ha asignado una puntuación numérica a cada uno de los frameworks para cada una de las características comparadas de la siguiente manera: Baja 1, Media 2 y Alta 3. A continuación se han agregado los resultados de todas las características para cada framework con el objeto de compararlos en conjunto. La figura 11 detalla la puntuación total obtenida por cada uno de los frameworks estudiados. jquery es el framework que mejores resultados ofrece en la comparativa y a priori el más adecuado para el desarrollo del front-end del presente proyecto web. 72

86 3,5 3 2,5 2 1,5 1 0,5 jquery Mootools Prototype 0 Figura 11 Puntuación obtenida por cada uno de los frameworks de JavaScript Además de la comparativa general se ha realizado un test de velocidad de selección de elementos para los tres frameworks a estudio. Para la realización de la prueba se han utilizado 40 selectores distintos de elementos del DOM (Document Object Model) y se ha medido el tiempo requerido por cada uno de los frameworks en hacer la selección de cada uno de ellos. Los selectores permiten seleccionar los elementos del DOM que cumplan las características especificadas en la consulta de cada selector. De este modo se pueden seleccionar elementos del documento HTML mediante JavaScript filtrando por distintos tipos de atributos. La tabla 3 muestra el tiempo requerido por cada framework para seleccionar los elementos coincidentes con cada selector. También especifica el número de elementos encontrados para cada selector para poder comprobar si el framework ha encontrado todos los elementos correspondientes al selector, sólo una parte o ninguno de ellos. 73

87 jquery es el framework que menos tiempo total ha requerido en ejecutar todos los selectores. Tan solo ha tardado 38 ms mientras que MooTools ha tardado 46 ms y Prototype 156 ms. Tabla 3 Comparativa de rendimiento de selectores para los frameworks JavaScript en estudio. 74

88 Tras la comparativa de rendimiento de los distintos frameworks se selecciona jquery para el desarrollo del front-end de la aplicación Elección de Framework CSS Con el objetivo de crear un interfaz de usuario escalable se ha optado por utilizar un framework de estilos de cascada para el diseño. Se han estudiado tres frameworks CSS8 tipo grid. Los frameworks analizados son BlueprintCSS, 960.gs y YUI CSS. La tabla 4 muestra la comparativa de las características más importantes analizadas en los tres frameworks. YUI CSS Blueprint 960.gs Ancho de página 750, 950 y 974 px 950 px Definible (960 px por defecto) Número de columnas Fraccional 24 Definible (12 ó 16 por defecto) Plantillas de diseño No No Sí Tamaño 1,5 KB 14 KB 3,5 KB Simplicidad Baja Media Alta Licencia BSD MIT Dual GPL/MIT Tabla 4 Comparación de frameworks CSS Los tres frameworks son de código abierto. Los más livianos son YUI CSS y 960.gs con un tamaño de 1,5 KB y 3,6 KB respectivamente. Al igual que con la selección de los 75

89 anteriores frameworks se ha utilizado un sistema de puntuaciones para agregar las valoraciones de las distintas características de los mismos. La figura 12 muestra la comparación final entre frameworks con sus respectivas puntuaciones. 3,5 3 2,5 2 1,5 YUI CSS BluePrint 960gs 1 0,5 0 Ancho de página Número de columnas Plantillas de diseño Tamaño Simplicidad Licencia Figura 12 Comparación de los frameworks CSS en estudio Tras comparar las características de los frameworks se ha optado por utilizar 960.gs en el diseño del interfaz web debido a que ha logrado la mayor puntuación y por ser el único que ofrece plantillas de diseño Elección del sistema de distribución de contenidos Se ha optado por elegir una red de distribución de contenidos (CDN) para servir todos los archivos media gestionados por la aplicación 76

90 (imágenes, documentos, archivos CSS, etc.). La red consta de equipos situados en distintas áreas geográficas del mundo que opera de forma transparente para entregar contenidos desde el lugar más cercano al usuario. Se ha optado por esta opción con el fin de aligerar la carga del servidor de la aplicación, disminuir los costes de transferencia de datos, aumentar la escalabilidad del sistema de almacenamiento y conseguir mayor velocidad en el servicio de contenidos al usuario. Tras analizar distintas opciones se ha optado por utilizar Amazon CloudFront integrado con el sistema de almacenamiento de archivos Amazon S3. Ambas soluciones forman parte de los web services que ofrece Amazon a terceros mediante uso de su propia infraestructura Configuración de la solución final La configuración de la solución final consta de un servidor dedicado que incluye el software servidor de la aplicación y el servidor de bases de datos, y un sistema de comunicación con los servidores media de Amazon S3 y CloudFront para distribuir contenidos. Toda la configuración queda detallada en la figura 18. El servidor de bases de datos consta del gestor PostgreSQL elegido previamente para la solución final. El servidor de la aplicación consta de Python, Django y un servidor Apache integrados para su correcto funcionamiento. El servidor de la aplicación se comunica directamente con el servidor de bases de datos y utiliza las APIs de Amazon S3 y Amazon CloudFront para almacenar y servir contenidos media. Así mismo utiliza AJAX y notación XML/JSON para acceder a servicios de terceros como GoogleMaps ó Freebase mediante sus correspondientes APIs. En el navegador de los usuarios se ejecuta el código JavaScript del front-end de la aplicación mediante el framework jquery y se realizan las consultas asíncronas AJAX al servidor. En la figura 13 el framework de estilos de cascada CSS queda obviado por no tener que ver directamente con la arquitectura de programación sino con el diseño del interfaz. 77

91 Figura 13 Diagrama de la configuración final del sistema 78

92 6. Análisis conceptual de la aplicación 79

93 6.1. Necesidades y requisitos del sistema Introducción En el siguiente apartado se analizarán las necesidades y requisitos del sistema para definir de una manera clara y concisa lo que la aplicación debe ser capaz cubriendo todo el alcance del proyecto. En este capítulo se incluye toda la funcionalidad que el sistema debe ofrecer al usuario final Reconocimiento del problema y alcance El objetivo principal es la realización de un sistema capaz de gestionar la publicación y reserva de artículos de segunda mano por parte de los usuarios. Para ello, se deberán ofrecer herramientas que permitan a los usuarios reservar los elementos publicados. Por otra parte, y dado que muchos sitios web no ofrecen una relación detallada entre los artículos publicados y el área geográfica determinada del publicador, se deberá permitir la asociación de los elementos publicados con el área geográfica. El sistema también deberá ser capaz de filtrar aquellos artículos publicados dentro del radio de área geográfica que desee el usuario a la hora de reservar. Para ello se deberá desarrollar un sistema de información geográfica GIS propio que se nutra de información geográfica aportada por servicios y APIs de terceros. El sistema también deberá gestionar toda la información de los plazos de recogida, la notificación y avisos a ambos usuarios de una manera correcta y eficaz. Para aquellos usuarios con varios artículos reservados, y siempre que lo deseen, el sistema deberá ofrecer una ruta óptima de recogida de los artículos particulares. El sistema deberá penalizar a aquellos usuarios que se comporten de manera perjudicial para el sistema y para el resto de usuarios. 80

94 Para todo ello el sistema debe ser capaz de ofrecer su funcionalidad a usuarios de cualquier parte del mundo. Es por esto que el sistema deberá constar de un interfaz web que permita a los usuarios interactuar con él de una forma sencilla y eficaz. Los objetivos de este proyecto se centran en el desarrollo de una aplicación web denominada reutiliza.me, que facilite la publicación, organización, reserva y adquisición económica de artículos de segunda mano asociados a áreas geográficas Tipología de usuarios finales Existen dos tipos de usuario claramente definidos por el uso que hacen de la aplicación diseñada: el usuario final y el administrador del sistema. - Usuario final: Utiliza la aplicación para publicar artículos de segunda mano de forma gratuita y sin obtener beneficio por ello. También para poder reservar por un mínimo precio los artículos que desee situados dentro del radio de su área geográfica. Si un usuario tiene varios artículos reservados, tiene la opción de que el sistema le calcule la ruta más óptima para recogerlos. - Administrador del sistema: Utiliza la aplicación para gestionar toda la información de los usuarios y realizar tareas de mantenimiento del sistema. También soluciona problemas de usuarios y controla los contenidos publicados para evitar contenidos no deseados y moderar el comportamiento de los usuarios Especificación de necesidades y requisitos La solución web deberá ofrecer las siguientes funcionalidades a sus usuarios. Se han dividido las necesidades y requisitos del sistema en tres secciones: 81

95 - Necesidades y requisitos para el usuario final. - Necesidades y requisitos para el administrador. - Otras necesidades y requisitos del sistema. Necesidades y requisitos para el usuario final. El sistema deberá ofrecer a los usuarios la siguiente funcionalidad: Publicar artículos de segunda mano asociados a una dirección El sistema deberá ofrecer herramientas sencillas y potentes para que los usuarios puedan publicar fácilmente artículos de segunda mano concretos y asociarlos a una dirección. Reservar artículos de segunda mano publicados ubicados en su área geográfica El sistema deberá permitir la reserva exclusiva de aquellos artículos publicados dentro de su área geográfica por el precio mostrado. Comunicación de reserva de un artículo de segunda mano publicado El sistema deberá comunicar que se ha realizado la reserva exclusiva de un artículo publicado al usuario que lo publicó. De la misma forma le comunicará los días de plazo en los que se realizará la recogida. Comunicación del plazo y tiempo para su vencimiento El sistema deberá comunicar a aquel usuario que realizó una reserva del tiempo de plazo que dispone para ejecutar la recogida así como de la penalización pertinente en caso de no realizarla. Preguntar sobre el estado de la recogida al usuario publicador El sistema deberá, al finalizar el plazo de recogida, preguntar al usuario publicador de un artículo que fue reservado con posterioridad sobre si la recogida se ha realizado o no. En caso de que no se realice la recogida, su artículo de segunda mano volverá a publicarse si el usuario lo desea. 82

96 Preguntar sobre el estado de la recogida al usuario que reservó El sistema deberá, al finalizar el plazo de recogida, preguntar al usuario que reservó un artículo publicado si la recogida se ha realizado o no. En caso de que no se realice la recogida, se procederá a la penalización correspondiente. Organización de los artículos de segunda mano publicados El sistema deberá ofrecer un sistema de búsqueda para facilitar la búsqueda al usuario. En este sistema de búsqueda el usuario introducirá el tipo de artículo que busca y el sistema le mostrará todos los artículos de su área geográfica relacionados con el criterio de búsqueda. Cálculo de la ruta óptima de recogida El sistema deberá ofrecer la posibilidad de calcular y mostrar la ruta óptima para recoger varios artículos reservados a aquel usuario que realizó varias reservas. Necesidades y requisitos para los administradores del sistema. Administrar todos los contenidos de la aplicación web y sus relaciones El sistema deberá ofrecer una interfaz sencilla y potente con vistas CRUD que les permita a los administradores crear, modificar y eliminar cualquier contenido. La interfaz deberá ser accesible a través de la web para que la aplicación pueda ser administrada remotamente. Ofrecer distintos niveles de acceso a los datos El sistema deberá implementar un sistema de seguridad que permita editar permisos de lectura, modificación y eliminación de datos a nivel de usuarios concretos o grupos de usuarios. 83

97 Ejecutar tareas de mantenimiento El sistema deberá ofrecer una interfaz por línea de comandos accesible mediante el protocolo SSH para que los administradores puedan ejecutar de forma remota todas las tareas de mantenimiento. Así mismo deberá ofrecer comandos potentes que permitan realizar tareas concretas como limpieza de contenidos huérfanos, backups de datos y comprobaciones del sistema. Otras necesidades y requisitos del sistema. Ofrecer escalabilidad horizontal El sistema debe ser capaz de crecer de forma horizontal, es decir, mediante la inclusión de nuevo hardware. Para ello debe ser capaz de soportar cambios en el hardware y despliegue de la aplicación sobre distintas máquinas sin necesidad de realizar cambios importantes en el código fuente. Ofrecer seguridad El sistema debe ser capaz de asegurar los datos privados de los usuarios evitando posibles accesos no autorizados a los mismos controlando las acciones de los usuarios Análisis de la penalización En el caso de que un usuario haga un uso incorrecto del servicio que ofrece reutiliza.me, el sistema tendrá la capacidad necesaria para detectarlo y llevar a cabo la penalización correspondiente. El principal problema que tiene esta aplicación web es que no tiene ninguna forma para conocer si la recogida del artículo de segunda mano se realiza o no. Es por eso que la aplicación necesita de los usuarios conocer el estado de la recogida. Para facilitar la colaboración de los usuarios implicados, el sistema se basará en lo que, en principio, buscan los usuarios y se consideran sus necesidades. Analizando el punto débil de la aplicación, es decir la recogida, se observan dos usuarios del mismo sistema pero con 84

98 intereses distintos. Por una parte se encuentra el usuario publicador, que es quién publica un artículo con el servicio web. La finalidad que le ha llevado a este usuario a publicar un artículo es deshacerse de algo que tiene, en buen estado que ya no le sirve o bien le estorba pero que considera todavía puede utilizarse. Por lo tanto lo que busca es alguien que quiera dicho objeto y su necesidad es la de quitarse de en medio dicho artículo. Por el contrario se encuentra el usuario que reserva, es decir un usuario del sistema, que tiene una cuenta de usuario y que ha reservado en exclusividad un artículo publicado situado dentro de su área geográfica. Este usuario ha realizado la reserva de un artículo porque le interesa obtenerlo por el bajo precio por el que lo ha visto. Resulta obvio que lo que busca este otro tipo de usuario es el objeto que ha reservado a ese precio y su necesidad es la de rentabilizar el crédito de su cuenta de usuario al máximo. Una vez reconocidos las necesidades y los deseos de cada uno de los participantes de la recogida del artículo, sólo falta implantar en la aplicación un sistema eficiente para controlar y conocer el estado de la recogida. Para conocer si se produce o no la recogida, el sistema se comunicará con ambas partes, para contrastar la información dada por cada uno y así proceder como sea conveniente. A continuación se muestra como se relacionará el sistema con el usuario publicador. - Cuando un usuario reserva un artículo de segunda mano publicado en el sistema, la aplicación le informará al usuario publicador que su artículo ha sido reservado con exclusividad y el tiempo de plazo en el que podrán ir a recogerlo. Si el usuario que reservo va a recogerlo dentro de plazo, el sistema le preguntará al 85

99 usuario publicador si realmente se ha procedido a la recogida. El usuario publicador indicará si es así o no. En caso de que se haya producido la recogida pero el usuario publicador indica que no se hizo, el sistema volverá a publicar el artículo y si en la siguiente recogida el usuario que reserva indica que no había ningún artículo que recoger, entonces el usuario publicador será penalizado. Si el tiempo de plazo se termina y el sistema no tiene noticias de que se haya producido la recogida, la aplicación le preguntará al usuario publicador si el usuario que reservó realizó la recogida dentro de plazo. Si es así, el publicador indicará que si lo hizo para no perjudicar al otro usuario. Si no es así, el publicador indicará que no lo hizo, para que el sistema lo publique de nuevo, ya que a este usuario lo que le interesa es que su artículo esté publicado, para que alguien reserve y recoja su artículo cuanto antes. Ahora falta estudiar como se relacionará el sistema con la otra parte. - Cuando un usuario reserva un artículo de segunda mano publicado en el sistema, la aplicación le informará del plazo en el que podrán ir a recogerlo. Si lo recoge antes de que finalice el plazo, deberá comunicarlo al sistema, para que sepa que se produjo la recogida, eliminar el contador del plazo y así evitar que le penalicen. Si el tiempo de plazo se termina y el sistema no tiene noticias de que se haya producido la recogida, la aplicación actuará como se ha visto anteriormente, para penalizar al usuario que realizó la reserva. La penalización a cada usuario, las tres primeras veces, consistirá en reducirle parte del crédito que pagó al realizar su cuenta. Después del tercer aviso, se cancelara su cuenta, sus publicaciones y las reservas que tuviera pendientes. 86

100 6.2. Metodología utilizada Metodología tradicional metodología ágil Metodología tradicional: - Análisis de requisitos. - Especificación de requisitos. - Diseño del sistema. - Implementación. - Pruebas. El problema es que, en la gran mayoría de las veces, el cliente no sabe de tecnología. En muy pocos casos el cliente sólo conoce algo la tecnología que usa. El cliente tiene una idea abstracta de lo que quiere, es decir, no sabe que quiere en concreto si no lo ve antes. Además, prefieren algo funcional que puedan probar y ver, aunque sean a pequeña escala, antes que un diseño. En casi todos los proyectos hay cambios en los requisitos. Metodología ágil: También conocido como desarrollo ágil de software. Es un paradigma de desarrollo de software basado en procesos ágiles. Los procesos ágiles de desarrollo de software, conocidos anteriormente como metodologías livianas, intentan evitar los tortuosos y burocráticos caminos de las metodologías tradicionales enfocándose en la gente y los resultados. Es un marco de trabajo conceptual de la ingeniería de software que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de vida del proyecto. Existen muchos métodos de desarrollo ágil, la mayoría minimiza riesgos desarrollando software en cortos lapsos de tiempo. El software desarrollado en una unidad de tiempo es llamado iteración, la cual debe durar de una a cuatro semanas. Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión 87

101 y documentación. Una iteración no debe agregar demasiada funcionalidad para justificar el lanzamiento del producto al mercado, pero la meta es tener una demostración sin errores al final de cada iteración. Al final de cada iteración el equipo vuelve a evaluar las prioridades del proyecto. Los métodos ágiles también enfatizan que el software funcional es la primera medida del progreso. Combinado con la preferencia por las comunicaciones cara a cara, generalmente los métodos ágiles son criticados y tratados como "indisciplinados" por la falta de documentación técnica. Las características de la metodología ágil son: - Agilizan el desarrollo, de esta forma se tiene en seguida algo que funcione. - Se da por hecho que los requisitos van a cambiar. - Exige una entrega constante del proyecto. - Produce una respuesta rápida al cambio. - El cliente puede ver si el sistema se está adecuando a sus necesidades Programación Extrema Es el más destacado de los procesos ágiles de desarrollo de software. Los defensores de la programación extrema consideran que los cambios de requisitos sobre la marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del proyecto es una aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos. 88

102 Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software. Principios de la programación extrema: - Simplicidad: la simplicidad es la base de la programación extrema. Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Un diseño complejo del código junto a sucesivas modificaciones por parte de diferentes desarrolladores hacen que la complejidad aumente exponencialmente. Para mantener la simplicidad es necesaria la refactorización del código, ésta es la manera de mantener el código simple a medida que crece. También se aplica la simplicidad en la documentación, de esta manera el código debe comentarse en su justa medida, intentando eso sí que el código esté autodocumentado. Para ello, se deben elegir adecuadamente los nombres de las variables, métodos y clases. Los nombres largos no disminuyen la eficiencia del código ni el tiempo de desarrollo gracias a las herramientas de autocompletado y refactorización que existen actualmente. Aplicando la simplicidad junto con la autoría colectiva del código y la programación por parejas se asegura que cuanto más grande se haga el proyecto, todo el equipo conocerá más y mejor el sistema completo. - Comunicación: la comunicación se realiza de diferentes formas. Para los programadores el código comunica mejor cuanto más simple sea. Si el código es complejo hay que esforzarse para hacerlo inteligible. El código autodocumentado es más fiable que los comentarios ya que estos últimos pronto quedan desfasados con el código a medida que es modificado. Debe comentarse sólo aquello que no va a variar, por ejemplo el objetivo de una clase o la funcionalidad de un método. Las pruebas unitarias son otra forma de comunicación ya que describen el diseño de las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Los programadores se comunican constantemente gracias a la programación por parejas. La 89

103 comunicación con el cliente es fluida ya que el cliente forma parte del equipo de desarrollo. El cliente decide qué características tienen prioridad y siempre debe estar disponible para solucionar dudas. - Realimentación: al estar el cliente integrado en el proyecto, su opinión sobre el estado el proyecto se conoce en tiempo real. Al realizarse ciclos muy cortos tras los cuales se muestran resultados, se minimiza el tener que rehacer partes que no cumplen con los requisitos y ayuda a los programadores a centrarse en lo que es más importante. Considérense los problemas que derivan de tener ciclos muy largos. Meses de trabajo pueden tirarse por la borda debido a cambios en los criterios del cliente o malentendidos por parte del equipo de desarrollo. El código también es una fuente de retroalimentación gracias a las herramientas de desarrollo. Por ejemplo, las pruebas unitarias informan sobre el estado de salud del código. Ejecutar las pruebas unitarias frecuentemente permite descubrir fallos debidos a cambios recientes en el código. - Valentía: para los gerentes la programación en parejas puede ser difícil de aceptar, porque les parece como si la productividad se fuese a reducir a la mitad ya que sólo la mitad de los programadores está escribiendo código. Hay que ser valiente para confiar en que la programación por parejas beneficia la calidad del código sin repercutir negativamente en la productividad. La simplicidad es uno de los principios más difíciles de adoptar. Se requiere coraje para implementar las características que el cliente quiere ahora sin caer en la tentación de optar por un enfoque más flexible que permita futuras modificaciones. No se debe emprender el desarrollo de grandes marcos de trabajo ( frameworks ) mientras el cliente espera. En ese tiempo el cliente no recibe noticias sobre los avances del proyecto y el equipo de desarrollo no recibe realimentación para saber si va en la dirección correcta. La forma de construir marcos de trabajo es mediante la refactorización del código en sucesivas aproximaciones. - Respeto: el respeto se manifiesta de varias formas. Los miembros del equipo se respetan los unos a otros, porque los programadores no pueden realizar cambios 90

104 que hacen que las pruebas existentes fallen o que demore el trabajo de sus compañeros. Los miembros respetan su trabajo porque siempre están luchando por la alta calidad en el producto y buscando el diseño óptimo o más eficiente para la solución a través de la refactorización del código. Las características fundamentales de este método son: - Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. - Pruebas unitarias continuas: frecuentemente repetidas y automatizadas, incluyendo pruebas de regresión. Se aconseja escribir el código de la prueba antes de la codificación. - Programación en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se supone que la mayor calidad del código escrito de esta manera (el código es revisado y discutido mientras se escribe) es más importante que la posible pérdida de productividad inmediata. - Frecuente integración del equipo de programación con el cliente o usuario. Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo. - Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes. - Refactorización del código: es decir, reescribir ciertas partes del código para aumentar su legibilidad y manutención pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo. - Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en grupos de trabajo distintos, este método promueve 91

105 el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados. - Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo. La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Cuanto más simple es el sistema, menos tendrá que comunicar sobre éste, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores. Para el desarrollo del sistema se ha utilizado el paradigma de desarrollo ágil de software basándose en procesos ágiles. Los procesos ágiles de desarrollo tratan de evitar los tortuosos y burocráticos caminos de las metodologías tradicionales de desarrollo de software, enfocándose en los usuarios que van a utilizar la aplicación y los resultados obtenidos. La metodología elegida dentro de este paradigma ha sido la de programación extrema (extreme Programming), XP. La programación extrema se diferencia de las metodologías tradicionales de desarrollo de software en que se centra en la adaptabilidad más que en la previsibilidad: El desarrollo ágil permite que los cambios de requisitos sean modificados sobre la marcha como ocurre en el mundo real, ya que es algo inevitable en el desarrollo de proyectos. La capacidad de adaptación a los cambios de requisitos en cualquier punto de vida del proyecto es una aproximación más realista 92

106 que definir todos los requisitos al comienzo del proyecto y requerir grandes inversiones en caso de que se produzcan cambios de requisitos. La Programación Extrema es una metodología ligera de desarrollo de software basada en la simplicidad, la comunicación y la reutilización del código desarrollado. Se puede encontrar la utilidad del desarrollo ágil en el desarrollo de proyectos de software reales. La metodología XP tiene en cuenta cuatro variables que afectan al desarrollo de cualquier proyecto de software: Coste, Tiempo, Calidad y Alcance. Puede ser comparada con las metodologías en cascada e iterativas. Mientras que un desarrollo iterativo consiste en realizar varias iteraciones a las fases del desarrollo en cascada, la metodología XP parte de un pequeño prototipo de la aplicación y realiza más iteraciones más pequeñas sobre el mismo de forma iterativa. Además de estas iteraciones existe una fase de análisis que está presente durante todo el proceso de desarrollo. La figura 14 muestra las diferencias entre las tres metodologías. 93

107 Figura 14 Comparación de las metodologías en cascada, iterativa y XP Para el desarrollo de la aplicación se hizo un sencillo prototipo inicial y se realizaron sucesivas iteraciones generando versiones más avanzadas del prototipo hasta llegar al producto final. 94

108 6.3. Modelo de dominio Introducción En este apartado se describen los diagramas de clases del sistema. El sistema se ha subdividido en siete aplicaciones Django integradas en un sólo proyecto común. Los modelos de datos se dividen entre las siguientes aplicaciones del sistema: o Aplicación de autenticación de Django. o Aplicación de publicaciones. o Aplicación de administrador. o Aplicación de sesión. o Aplicación de sitios. o Aplicación de metainformación. La siguiente figura muestra el diagrama en general. Figura 15 Diagrama de clases del sistema general 95

109 Para que pueda verse con más detalle, a continuación se muestra el mismo diagrama anterior, pero en tres partes. Figura 16 Parte del diagrama de clases del sistema general 96

110 Figura 17 Parte del diagrama de clases del sistema general Figura 18 Parte del diagrama de clases del sistema general 97

111 A continuación se detallan los diagramas de clases pertenecientes a cada una de las aplicaciones y el glosario de clases con su descripción Diagrama de clases de la aplicación de autenticación de Django La figura 19 muestra el diagrama de clases de la aplicación de autenticación de Django. La función de esta aplicación es la de autenticar tanto a usuarios como a administradores. Figura 19 Diagrama de clases de la aplicación de autenticación de Django 98

112 Diagrama de clases de la aplicación publicaciones La figura 20 muestra el diagrama de clases de la aplicación de publicaciones. En dicho diagrama se pueden observar las distintas clases que componen la aplicación que se encarga de todo aquello que está relacionado con las publicaciones de los usuarios. De las 3 clases, dos de ellas Thing y Profile están relacionadas con la clase User de la aplicación de autenticación. Figura 19 Diagrama de clases de la aplicación publicaciones 99

113 Diagrama de clases de la aplicación de administrador La aplicación de administrador está compuesta de una única clase, la cual se relaciona con la clase contenttypes de la aplicación de metainformación y también con la clase User de la aplicación de autenticación. Contiene toda la información referente a los administradores. Figura 20 Diagrama de clases de la aplicación de administrador Diagrama de clases de la aplicación de sesión Las sesiones de usuario y de los administradores se rigen según lo establecido en la clase Session de esta aplicación. En la figura 21 se puede ver su diagrama correspondiente. Figura 21 Diagrama de clases de la aplicación de sesión 100

114 Diagrama de clases de la aplicación de sitios En la figura 22 se puede el diagrama de la aplicación de sitios. Se compone de única clase. Esta aplicación es imprescindible para que la aplicación de reutiliza.me pueda correr bajo distintas URL s. Figura 22 Diagrama de clases de la aplicación de sitios Diagrama de clases de la aplicación de metainformación En la figura 23 se puede el diagrama de la aplicación, compuesta por una única clase, a la que acceden las clases LogEntry y Permission. Figura 23 Diagrama de clases de la aplicación de metainformación 101