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

AGENDA

INTRODUCCIÓN

MARCO TEÓRICO

ANÁLISIS Y DISEÑO

CONCLUSIONES Y RECOMENDACIONES

INTRODUCCIÓNPLANTEAMIENTO DEL

PROBLEMA

JUSTIFICACIÓN

ALCANCE

OBJETIVOS

AGENDA

Planteamiento del problema Búsqueda de bienes inmuebles:

Pérdida de tiempo.

Muchas llamadas telefónicas.

Recorrer grandes distancias.

Costos elevados.

CAP. I

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

Alcance

Desarrollo de APIs internas.• Publicación.• Búsqueda.

MASHUP o sitio Web.• APIs internas.• APIs públicas

CAP. I

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

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

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

MARCO TEÓRICO

AGENDA

INGENIERÍA DE SOFTWARE

INGENIERÍA WEB

WEBAPPS

CICLO DE IWEB

METODOLOGÍA XP

FASES DE XP

MASHUP

REST

FORMATO DE INTERCAMBIO DE DATOS

APIS PÚBLICAS

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

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

Características de WebApps

Intensivas de Red

Controlada por el

Contenido.

Evolución continua

Inmediatez

Seguridad

Estética

CAP. II

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

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

Ciclo de IWeb

CAP. II

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

¿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

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

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

¿Quién practica XP?

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

CaracterísticasDesarrollo Incremental e Iterativo

•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

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

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

Ciclo de Vida de XP

CAP. II

FASES DE XP

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

MASHUP

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

Arquitectura de MASHUP

Presentación / Interactividad

(cliente)

Datos

El proveedor de contenidos (fuente de

los datos – web services)

CAP. II

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.

Protocolos de APIs Para la creación de los servicios web de las

APIs Públicas se puede usar varios protocolos.

CAP. II

REST

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

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.

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

REST satisface sus principios aplicando las siguientes restricciones

•URIs.•Recursos son los objetos lógicos.•Representaciones del estado del recursos.

Identificación y manipulación

de recursos

•HTTP es un protocolo sin estado y cuando se utiliza adecuadamente, es posible interpretar cada mensaje sin ningún conocimiento de los mensajes precedentes.

Mensajes auto

descriptivos

•Estado actual de una aplicación Web debe ser capturado en uno o mas documentos de hipertexto.

Hipermedia como un mecanismo del

estado de la aplicación

CAP. II

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 Update >>

Delete DELETE Delete Del/rm

CAP. II

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).

http://www.service.com/inmuebles/001

http://www.service.com/inmuebles/obtenerInmueble?id=001

CAP. II

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

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

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

APIs Públicas

CAP. II

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

CAP. II

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

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

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

Tabla de Resumen de las APIs del MASHUP

API Protocolos Protocolo

seleccionado

Formato de

Intercambio

de Datos

Formato

Seleccionado

Google Maps REST REST XML, VML,

JSON, KML

JSON

Flickr REST, SOAP,

XML-RPC

REST REST, XML-

RPC, SOAP,

JSON, PHP

JSON

YouTube GData (REST),

ATOM/RSS

GData (REST) ATOM, RSS,

JSON, XML

JSON

Facebook REST REST XML XML

CAP. II

IIIANÁLISIS Y DISEÑO

AGENDA

ANÁLISIS

PLAN DE ITERACIONES

ARQUITECTURA

Análisis

Historias de usuario.

Clasificación.

Priorización.

Planificación de las iteraciones.• D

iagramas de secuencia.

• Codificación.

• Pruebas de aceptación.

CAP. III

Plan de Iteraciones

ID Task Name No H.S. Prioridad Duration Start Finish

1 Primera Iteracion (Usuarios) 21 days W ed 01/09/10 W ed 08/09/10

2 Registro de Usuarios 4 1 21 days Wed 01/09/10 Wed 08/09/10

3 Baja de mi Cuenta 6 2 21 days Wed 01/09/10 Wed 08/09/10

4 Modificacion Usuario 5 3 21 days Wed 01/09/10 Wed 08/09/10

5 Reactivar mi Cuenta 7 4 21 days Wed 01/09/10 Wed 08/09/10

6 Suspender acceso a usuarios 13 5 21 days Wed 01/09/10 Wed 08/09/10

7 Segunda Iteracion 21 days Thu 09/09/10 Thu 16/09/10

8 Publicacion de Inmuebles 9 1 21 days Thu 09/09/10 Thu 16/09/10

9 Modificacion de Inmueble Publicado 11 2 21 days Thu 09/09/10 Thu 16/09/10

10 Eliminacion de Inmueble Publicado 12 3 21 days Thu 09/09/10 Thu 16/09/10

11 Dar de Baja a inmuebles 14 4 21 days Thu 09/09/10 Thu 16/09/10

12 Mis Inmuebles 8 5 21 days Thu 09/09/10 Thu 16/09/10

13 Busqueda Inmuebles base criterios 1 6 21 days Thu 09/09/10 Thu 16/09/10

14 Busqueda Inmuebles mapa 2 7 21 days Thu 09/09/10 Thu 16/09/10

15 Ver Inmueble 3 8 21 days Thu 09/09/10 Thu 16/09/10

16 Publicar sitio de referencia (Administrador) 15 9 21 days Thu 09/09/10 Thu 16/09/10

17 Publicar Sitio de Referencia 10 10 21 days Thu 09/09/10 Thu 16/09/10

T F S S M T W T F S S M T W T F S S M T W T F S S M T W T F S S T16 Aug '10 23 Aug '10 30 Aug '10 06 Sep '10 13 Sep '10

CAP. III

Diseño Arquitectónico

CAP. III

EASY HOMEBASE DE DATOS

EASY HOME

API

Publicación de inmueble

Latitud y Longitud

ID de la foto

ID del video

Metadata del

Inmueble

MA

SH

UP

Metadata Del

Inmueble

EASY HOMEBASE DE DATOS

EASY HOME

API

Visualización del inmueble

ID de la foto

ID del videoMetadata

delInmueble

MA

SH

UP

Inmueble

Foto

Video

ID del Inmueble

Datosdel

Inmueble

EASY HOMEBASE DE DATOS

EASY HOME

API

Publicación de Referencias

Latitud y Longitud

Metadatade la

referencia

MA

SH

UP

Datosde

referencia

EASY HOMEBASE DE DATOS

EASY HOME

API

Visualización de Referencias

Referencia

Metadatade la

referencia

MA

SH

UP

Datosde

referencia

EASY HOMEBASE DE DATOS

EASY HOME

API

Registro Usuarios

Datos

Metadatadel

usuario

MA

SH

UP

Datosde

usuario

EASY HOMEBASE DE DATOS

EASY HOME

API

Visualizar datos del Usuario

Datos

Metadatadel

usuario

MA

SH

UP

Datosde

usuario

EASY HOMEBASE DE DATOS

EASY HOME

API

Buscar inmueble

ID de la foto

Parámetros

MA

SH

UP

Inmuebles

Foto

Parámetrosdel

Inmueble

Datosde los

Inmuebles Resultados

1 2

3

4

56

7

IV CONCLUSIONES Y RECOMENDACIONES

AGENDA

CONCLUSIONES

CAP. IV

•MASHUP•API Pública•Requerimientos de Usuario

Implementación.

•Base Solida.•Investigación.•Herramientas y Tecnología.•Estándar

Marco Teórico.

•Construcción de la presente aplicación.•Correcta interpretación de las necesidades.

Planificación y diseño

CONCLUSIONES

CAP. III

•Iterativa resuelve eficiencia código, refactorización, compartir conocimiento.•Resultados Eficientes.

Metodología.

•Utilización de APIs y MASHUP.•Adaptabilidad del software.•Involucrar usuario final.

Pruebas Aceptac

ión.

CONCLUSIONES

AGENDA

•Interacción con otras aplicaciones.•Servicios y Funcionalidad.

API EasyHo

me.

•Integración de varias fuentes de datos.•Datos aislados.

MASHUP

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.

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.

ANEXOS

URIs APIs EasyHome

Uri Método Descripción

POST Servicio en http://easyhome.dyndns.org/easyhome/inmueble/

PUT Servicio en http://easyhome.dyndns.org/easyhome/inmueble/

/{idInmueble} GET Servicio en http://easyhome.dyndns.org/easyhome/inmueble/{IDINMUEBLE}

CAP. III