ESCUELA POLITÉCNICA DEL EJÉRCITO DESARROLLO DE UN MASHUP COMERCIAL PARA LA PUBLICACIÓN Y...
-
Upload
chuy-ortiz -
Category
Documents
-
view
216 -
download
0
Transcript of ESCUELA POLITÉCNICA DEL EJÉRCITO DESARROLLO DE UN MASHUP COMERCIAL PARA LA PUBLICACIÓN Y...
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