ESCUELA POLITÉCNICA DEL EJÉRCITO DESARROLLO DE UN MASHUP COMERCIAL PARA LA PUBLICACIÓN Y BÚSQUEDA DE BIENES INMUEBLES EN QUITO INTEGRANDO DISTINTAS APIS.

Presentación del tema: "ESCUELA POLITÉCNICA DEL EJÉRCITO DESARROLLO DE UN MASHUP COMERCIAL PARA LA PUBLICACIÓN Y BÚSQUEDA DE BIENES INMUEBLES EN QUITO INTEGRANDO DISTINTAS APIS."— Transcripción de la presentación:

1 ESCUELA POLITÉCNICA DEL EJÉRCITO DESARROLLO DE UN MASHUP COMERCIAL PARA LA PUBLICACIÓN Y BÚSQUEDA DE BIENES INMUEBLES EN QUITO INTEGRANDO DISTINTAS APIS PÚBLICAS Y PROVEYENDO DE LAS INTERFACES NECESARIAS PARA QUE SEA CONSUMIDO DESDE CUALQUIER TIPO DE APLICACIÓN INFORMÁTICA DIRECTOR: MSC. EDISON LASCANO CODIRECTORA: ING. TATIANA NOBOA POR: FRANCO ROBERTO ORDOÑEZ LEÓN RODRIGO XAVIER ROMERO SAAVEDRA Version 23-jul-2011 : 9:54 pm

2 CONCLUSIONES Y RECOMENDACIONES
AGENDA INTRODUCCIÓN MARCO TEÓRICO ANÁLISIS Y DISEÑO CONCLUSIONES Y RECOMENDACIONES

3 PLANTEAMIENTO DEL PROBLEMA
INTRODUCCIÓN PLANTEAMIENTO DEL PROBLEMA JUSTIFICACIÓN ALCANCE OBJETIVOS AGENDA

4 Planteamiento del problema
Búsqueda de bienes inmuebles: Pérdida de tiempo. Muchas llamadas telefónicas. Recorrer grandes distancias. Costos elevados. CAP. I

5 Justificación Escasa información en medios. Amplio uso de Internet.
Sociabilización de la información. Publicación de APIs gratuitas para consumir dicha información. Google Maps API, Flickr API, YouTube API, etc. MASHUPS. Escaso uso de este tipo de aplicaciones en Quito. CAP. I

6 Alcance CAP. I Desarrollo de APIs internas. Publicación. Búsqueda.
MASHUP o sitio Web. APIs internas. APIs públicas CAP. I

7 Objetivo General Desarrollar un MASHUP para la publicación y búsqueda de bienes inmuebles en Quito integrando distintas APIs públicas y proveyendo de las interfaces necesarias para que sea consumido desde cualquier tipo de aplicación informática. CAP. I

8 Objetivos Específicos
Revisar fundamentación teórica de MASHUPS, combinación de APIs públicas e integración de fuentes de datos externos para obtener un sitio Web que de una experiencia integrada y funcional. Investigar la integración de tecnologías basadas en Web 2.0 que permitan a los usuarios buscar y publicar un inmueble dentro de un portal Web. CAP. I

9 Objetivos Específicos
Aplicar la metodología XP y el proceso de Ingeniería Web en el análisis y diseño tanto de APIs internas como del MASHUP y para el desarrollo e implementación planificado y controlado. CAP. I

10 MARCO TEÓRICO INGENIERÍA DE SOFTWARE FASES DE XP INGENIERÍA WEB MASHUP
WEBAPPS REST CICLO DE IWEB FORMATO DE INTERCAMBIO DE DATOS METODOLOGÍA XP APIS PÚBLICAS AGENDA

11 Ingeniería de Software
Enfoque sistemático, disciplinado y cuantificable al desarrollo permite la producción y mantenimiento de software de calidad. Amplio espectro de aplicación aborda todas las fases del ciclo de vida del desarrollo de cualquier tipo de sistema de información. Las aplicaciones Web poseen distintas características, para este tipo de aplicaciones se aprovecha la Ingeniería Web. CAP. II

12 Proceso mediante el cual se crean WebApps de alta calidad.
Ingeniería Web Proceso mediante el cual se crean WebApps de alta calidad. Muy Necesario ya que las WebApps están contempladas en las estrategias de negocios de las empresas. CAP. II

13 Características de WebApps
Intensivas de Red Controlada por el Contenido. Evolución continua Inmediatez Seguridad Estética CAP. II

14 El Proceso de Ingeniería Web
Los procesos de IWeb adoptan la filosofía del desarrollo ágil. “Internet cambió la prioridad principal del desarrollo de software de ‘que’ a ‘cuando’. El reducido tiempo para el mercado se ha convertido en el límite competitivo por el que luchan las compañías líderes. En consecuencia, reducir el ciclo de desarrollo es ahora una de las misiones más importantes de la ingeniería de software.” Aoyama Aoyama, M., "Web-Based Agile Software Developmen", en IEEE Computer. CAP. II

15 Marco de Trabajo de la Ingeniería Web
PROCESO IWEB Modelo de proceso Ágil (XP, SCRUM, Desarrollo adaptativo) Modelo del proceso IWeb es adaptable Las tareas de ingeniería requeridas están bajo el criterio del equipo. CAP. II

16 Ciclo de IWeb CAP. II

17 Metodología De Desarrollo Programación Extrema (XP)
Breve reseña histórica: Creada por Kent Beck en 1996. 1999 publica el libro Extreme Programming Explained. Internet ayuda a su rápida difusión y uso. CAP. II

18 ¿Qué es XP? Es una metodología basada en procesos ágiles de desarrollo de software. Livianas o ágiles porque intentan evitar procesos pesados y burocráticos de las metodologías tradicionales Centra su esfuerzo en las personas y los resultados. Enfatizan que el software funcional es la primera medida del progreso. Se basa en desarrollo iterativo. En todas las iteraciones se repite un proceso de trabajo similar para proporcionar un resultado completo sobre producto final. CAP. II

19 Poner más énfasis en la adaptabilidad que en la previsibilidad.
XP es la metodología más destacada de los procesos agiles de desarrollo de software porque su principal característica es: Poner más énfasis en la adaptabilidad que en la previsibilidad. CAP. II

20 Manifiesto para el desarrollo Ágil de software
Por medio de este trabajo hemos aprendido a valorar: A los individuos y sus interacciones sobre los procesos y las herramientas. Al software en funcionamiento sobre la documentación extensa. A la colaboración del cliente sobre la negociación del contrato. A la respuesta al cambio sobre el seguimiento de un plan. CAP. II

21 ¿Quién practica XP? CAP. II
Ingenieros de software y otros participantes del proyecto (clientes y usuarios finales). Forman un equipo ágil: Es un equipo con organización propia y que controla su propio destino. Fomenta la comunicación y la colaboración entre todos los miembros. CAP. II

22 Características CAP. II Desarrollo Incremental e Iterativo Pruebas
XP asume que la planificación nunca será perfecta. La información varía en función de las necesidades del cliente. Reuniones con equipo de trabajo (representante cliente y desarrolladores). Pruebas Existen varias pruebas para garantizar el correcto funcionamiento del código, como son las pruebas de aceptación. El cliente es el responsable de definir las pruebas de aceptación. Programación en parejas Se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un mismo puesto. Se mejora la calidad del código escrito ya que el código es revisado y discutido mientras se escribe. Reuniones constantes Se recomienda que un representante del cliente trabaje junto al equipo de desarrollo CAP. II

23 Corrección de todos los errores
Características Corrección de todos los errores Antes de añadir una nueva funcionalidad se debe revisar y corregir los errores para poder continuar. Se recomienda hacer entregas parciales pero frecuentes. Refactorización  Es reescribir ciertas partes del código para aumentar su legibilidad y facilidad de mantenimiento pero sin modificar su comportamiento. Simplicidad La mejor manera de que las cosas funcionen es mantener simplicidad en el código e ir incrementando funcionalidades sobre versiones funcionales. La programación extrema propone 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. CAP. II

24 El cliente debe estar integrado en el proyecto.
Principios de XP Simplicidad Se simplifica el diseño para agilizar el desarrollo y facilitar el mantenimiento. Para mantener la simplicidad es necesaria la refactorización del código. Comunicación Programadores, el código comunica mejor cuanto más simple sea, por esto, si el código es complejo hay que esforzarse para hacerlo legible. Pruebas unitarias, describen el diseño de las clases y los métodos al mostrar ejemplos concretos de cómo utilizar su funcionalidad. Retroalimentación El cliente debe estar integrado en el proyecto. Su opinión sobre el estado del proyecto se conoce en tiempo real gracias a los ciclos cortos tras los cuales se muestran resultados. Se minimiza el tener que rehacer partes que no cumplen con los requisitos. CAP. II

25 Ciclo de Vida de XP CAP. II

26 FASES DE XP CAP. II FASE DEFINICIÓN ENTREGABLE Fases de Exploración
Especificación de Requerimientos mediante Historias de Usuario. Diagrama de Arquitectura del Sistema. Historias de Usuario. Metáforas Diagrama de Arquitectura. Fase de Planificación Clasificación y Priorización de Requerimientos Generar Plan de Iteraciones Plan de Iteraciones Fase Iteraciones Diseño Plan de Pruebas Codificación Test de Aceptación Aprobado Fase Producción Aprobación del Usuario Publicación de Versión. Software CAP. II

27 MASHUP CAP. II Sitio Web Híbrido.
Datos o servicios propios y de terceros Combinación o mezcla para crear una aplicación nueva. APIs Adquiere información externa usando APIs Publicas Google Maps, Yahoo!, Facebook Contenido Propio CAP. II

28 Arquitectura de MASHUP
Presentación / Interactividad (cliente) Datos El proveedor de contenidos (fuente de los datos – web services) CAP. II

29 Por qué un MASHUP? Bajo Costo/Riesgo desarrollo
Ciclo de desarrollo rápido Usualmente no se requiere una gran equipo de desarrollo. Utiliza poder de procesamiento de terceros “CloudComputing”. Proveedores de servicios están habilitando su contenido para ser mezclado. Reutilización de Software MASHUPs usan otros servicios.

30 Protocolos de APIs Para la creación de los servicios web de las APIs Públicas se puede usar varios protocolos. CAP. II

31 REST CAP. II Representational State Transfer
Es un estilo de arquitectura de software para sistemas de hipermedia distribuidos tales como la Web Modelo Basado en Recursos Los recursos son identificados por una URI única Representación de Recursos Dichos recursos pueden representarse en diversos formatos como HTML, XML, JSON o RSS, según lo solicite el cliente CAP. II

32 Por qué usar REST? Diseñado para Web.
HTTP estándar así que es mas simple. Permite varios formatos de datos. Los accesos de REST pueden ser almacenados en memoria(Cache). Tendencia Tecnológica. Acceso a recursos con nombres a través de una interface singular y consistente.

33 Características de REST
URLs limpias En REST las URLs representan recursos y no acciones, por lo tanto siempre tienen el mismo formato Formatos de respuesta variados Los controladores REST están escritos de manera que las acciones pueden devolver sus resultados fácilmente en diferentes formatos de respuesta. Una misma acción puede entregar HTML, XML, JSON, RSS Menos código REST ayuda al desarrollo de acciones capaces de ser usadas en varios clientes logrando tener menos código en los controladores CAP. II

34 REST satisface sus principios aplicando las siguientes restricciones
Identificación y manipulación de recursos URIs. Recursos son los objetos lógicos. Representaciones del estado del recursos. Mensajes auto descriptivos HTTP es un protocolo sin estado y cuando se utiliza adecuadamente, es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes. Hipermedia como un mecanismo del estado de la aplicación Estado actual de una aplicación Web debe ser capturado en uno o mas documentos de hipertexto. CAP. II

35 Métodos HTTP usados por REST
Los métodos HTTP usados son PUT, GET, POST, DELETE y suelen ser comparados con las operaciones asociadas a la tecnología de base de datos, operaciones CRUD: CREATE, READ, UPDATE, DELETE Acción HTTP SQL Unix Shell Create POST Insert > Read GET Select < Update PUT >> Delete DELETE Del/rm CAP. II

36 Diseño Servicio Web en REST
Identificar todas las entidades conceptuales que se desean exponer como servicio, ejemplo inmueble, usuario, foto, video, etc. Crear una URL para cada recurso. Los recursos deberían ser nombres no verbos (acciones). CAP. II

37 Diseño Servicio Web en REST
Categorizar los recursos de acuerdo con si los clientes pueden obtener una representación del recurso o si pueden modificarlo. Para lo primero, se debe hacer los recursos accesibles utilizando un HTTP GET. Para lo último, se debe hacer los recursos accesibles mediante HTTP POST, PUT y/o DELETE. CAP. II

38 Utilidad de REST El servicio Web no tiene estado.
Una infraestructura de almacenamiento en memoria puede mejorar el rendimiento. Tanto el productor como el consumidor del servicio conocen el contexto y contenido que va a ser comunicado. El ancho de banda es importante y este necesita ser limitado. La distribución de Servicios Web o la agregación con sitios Web existentes puede ser fácilmente desarrollada mediante REST. CAP. II

39 Formato de Intercambio de Datos
XML Extensible Markup Language (XML) es un formato de texto flexible y sencillo Originalmente diseñado para afrontar los retos de la publicación electrónica a gran escala. También está desempeñando un papel cada vez más importante en el intercambio de una amplia variedad de datos en la Web y en otros lugares JSON Notación de Objetos de JavaScript Es ligero, simple de leer y escribir para humanos, y simple de interpretar y generar para las maquinas. Basado en JavaScript, pero es completamente independiente del lenguaje de programación. RSS Es un formato para poner notas de contenido Web, Proviene del acrónimo de Really Simple Syndication. Es un dialecto de XML y se debe ajustar a la especificación XML 1.0. CAP. II

40 APIs Públicas CAP. II

41 APIs Públicas Es una Interfaz de programación de aplicaciones orientadas a la web. Se pueden acceder vía HTTP y ejecutadas en un sistema remoto. Permiten a sitios web interactuar con otros utilizando REST, SOAP, JavaScript y otras tecnologías web. Sus posibilidades no se limitan a aplicaciones basadas en web, se está convirtiendo en una tendencia creciente en las llamadas aplicaciones Web 2.0 CAP. II

42 CAP. II

43 Varios aspectos de Google Maps son los responsables de su facilidad de uso por cualquier usuario:
Sistema de deslizamiento de imagen, acoplado a la carga dinámica de nuevas imágenes; Adaptación del mapa al tamaño de ventana del navegador Interfaz minimalista, esencial sin sobrecarga de contenido. Posibilidad de cambiar de tipo de mapa en un clic. CAP. II

44 Google Maps se apoya poderosamente sobre la utilización de JavaScript.
La carga y el deslizamiento de imagen no podrían efectuarse sin este código CAP. II

45 Flickr Flickr es un sitio web que permite almacenar, ordenar, buscar y compartir fotografías y videos en línea. Esta se encuentra disponible a los desarrolladores que la utilicen de forma “no comercial” y en caso de que se desee realizar algo comercial es necesario que se realice un acuerdo previo. CAP. II

46 Tabla de Resumen de las APIs del MASHUP
Protocolos Protocolo seleccionado Formato de Intercambio de Datos Formato Seleccionado Google Maps REST XML, VML, JSON, KML JSON Flickr REST, SOAP, XML-RPC REST, XML-RPC, SOAP, JSON, PHP YouTube GData (REST), ATOM/RSS GData (REST) ATOM, RSS, JSON, XML Facebook XML CAP. II

47 III ANÁLISIS Y DISEÑO ANÁLISIS PLAN DE ITERACIONES ARQUITECTURA AGENDA

48 Análisis Historias de usuario. Clasificación. Priorización.
Planificación de las iteraciones. Diagramas de secuencia. Codificación. Pruebas de aceptación. CAP. III

49 Plan de Iteraciones CAP. III

50 Diseño Arquitectónico
CAP. III

51 Publicación de inmueble
Latitud y Longitud EASY HOME BASE DE DATOS EASY HOME API ID del video MASHUP Metadata Del Inmueble Metadata del Inmueble ID de la foto

52 Visualización del inmueble
Datos del Inmueble EASY HOME BASE DE DATOS EASY HOME API Video MASHUP Metadata del Inmueble ID del video ID del Inmueble Foto ID de la foto

53 Publicación de Referencias
Latitud y Longitud EASY HOME API EASY HOME BASE DE DATOS MASHUP Datos de referencia Metadata de la referencia

54 Visualización de Referencias
EASY HOME API EASY HOME BASE DE DATOS MASHUP Datos de referencia Metadata de la referencia

55 EASY HOME API Registro Usuarios MASHUP Datos EASY HOME BASE DE DATOS
Metadata del usuario

56 Visualizar datos del Usuario
EASY HOME API EASY HOME BASE DE DATOS MASHUP Datos de usuario Metadata del usuario

57 Buscar inmueble EASY HOME MASHUP API 7 Inmuebles 4 Datos de los
BASE DE DATOS 3 EASY HOME API Resultados MASHUP 2 1 Parámetros del Inmueble Parámetros Foto ID de la foto 6 5

58 IV CONCLUSIONES Y RECOMENDACIONES
AGENDA

59 Planificación y diseño
CONCLUSIONES Implementación. MASHUP API Pública Requerimientos de Usuario Marco Teórico. Base Solida. Investigación. Herramientas y Tecnología. Estándar Planificación y diseño Construcción de la presente aplicación. Correcta interpretación de las necesidades. CAP. IV

60 CONCLUSIONES CAP. III Metodología.
Iterativa resuelve eficiencia código, refactorización, compartir conocimiento. Resultados Eficientes. Pruebas Aceptación. Utilización de APIs y MASHUP. Adaptabilidad del software. Involucrar usuario final. CAP. III

61 CONCLUSIONES AGENDA API EasyHome. Interacción con otras aplicaciones.
Servicios y Funcionalidad. MASHUP Integración de varias fuentes de datos. Datos aislados. AGENDA

62 Recomendaciones AGENDA. API Funcionalidad Expuesta.
Maximicen su desempeño Exploten su utilización e información. REST Diseñar mas servicios tomar en cuenta el estilo de arquitectura. Orientación a Recursos. Accesibilidad a diferentes Medios. Desarrollo Planificar y diseñar la coexistencia de distintas APIs. AGENDA.

63 Recomendaciones CAP. III Análisis Obtención de historias de usuarios.
Invertir el tiempo y recursos necesarios para obtener el mayor detalle. Experiencia. Seleccionar la metodología, herramientas y tecnología. Tiempo en aprendizaje de nuevas tecnologías y se optimiza el proyecto. Metodología. Aunque XP cubre las necesidades del proceso de desarrollo, es necesario complementar la administración del proyecto con una metodología como SCRUM. CAP. III

64 ANEXOS

65 URIs APIs EasyHome CAP. III Uri Método Descripción POST
Servicio en PUT /{idInmueble} GET Servicio en CAP. III