Alejandro Ardila Schickler 9/4/2013

Transcripción

1 PONTIFICIA UNIVERSIDAD JAVERIANA MOOSTREAM Software Architecture Document (SAD) Alejandro Ardila Schickler 9/4/2013

2 Historial de Cambios FECHA DESCRIPCIÓN 05/09/2013 Creación de secciones 1 a 5 21/10/2013 Creación de Secciones 6 y 7 17/11/2013 Revisión del Documento

3 Tabla de Contenidos Historial de Cambios... 1 Tabla de Tablas... 4 Tabla de Ilustraciones Introducción Propósito... 6 Objetivos principaes:... 6 Audiencia Alcance Definiciones, Acrónimos y Abreviaciones... Error! Bookmark not defined Referencias Bibliográficas Apreciación Global Contexto Vista Funcional Vista No-Funcional Vista Lógica Vista de Interfaces... Error! Bookmark not defined Vista de Diseño Vista de Despliegue Vista de Datos Contexto Arquitectura Móvil Arquitectura App Engine Vista Funcional Vista No Funcional Rendimiento Escalabilidad Seguridad Internacionalización Vista Lógica MOODSTREAM mobile MOODSTRAM App Engine... 11

4 6. Vista de Interfaces... Error! Bookmark not defined. 7. Vista de Diseño Vista de Despliegue Vista de Datos... Error! Bookmark not defined.

5 Tabla de Tablas Tabla 1 - Módulos de la Arquitectura Móvil... 9 Tabla 2 - Módulos de la Arquitectura del Motor App Engine... 10

6 Tabla de Ilustraciones Ilustración 1 - Apreciación Global de Arquitectura... 8 Ilustración 2 - Diagrama de Componentes MOODSTREAM Ilustración 3 - Diagrama de Despliegue MOODSTREAM... 15

7 1. Introducción 1.1. Propósito Objetivos principaes: Dar una descripción de la arquitectura de software de MOODSTREAM, un sistema de photostreaming. Incluir los principales componentes de software y sus interacciones. Describir las plataformas de software y hardware utilizadas. Enunciar las formas en cómo el sistema está construido y desplegado. Audiencia El documento va dirigido a cualquier, inversionista o desarrollador activo de MOODSTREAM que desee consultar la forma en la cual fue diseñado, administrado y desplegado el sistema. Estos acudientes, para que entiendan el desarrollo del documento, tendrán que tener nociones de diseño orientado a objetos, atributos de calidad y diseño de la arquitectura del sistema Alcance Dentro del documento describirá únicamente: Elementos Funcionales del Sistema. Elementos No Funcionales del Sistema. Lógica de cómo interactúan los componentes en el sistema. Formas de comunicación del sistema. Diseño y despliegue del sistema. Formas de Almacenamiento del Sistema. Formas de Autenticación y Autorización. Es de vital importancia resaltar que dentro de los elementos no funcionales del sistema no especificarán conceptos como Flexibilidad, Extensibilidad, Auditabilidad, Accesibilidad y Regulaciones Legales; por lo que estas son responsabilidad directa de Google Inc Referencias Bibliográficas

8 [1] ISTAR, Plantilla HACER & USOS. [2] S. Brown, «Coding Architecture,» [En línea]. Available: [3] P. C. Peter Eeles, The Process of Software Architecting, Boston: Pearson Education, Inc., [4] Y. Natchetoi, «Service-Oriented Architecture for Mobile Applications».SAP Apreciación Global El documento estará dividido es las siguientes secciones: Contexto Se especifica el contexto y comunicación general del sistema. Se especifican, por medio de diagramas de bloque, los actores, sistemas externos, sistemas externos y las relaciones entre ellos. Adicionalmente se mencionan, de una manera general, las tecnologías tecnologías y frameworks utilizados Vista Funcional Muestra las Funcionalidades del sistema y especifica cuáles de estas tienen significado para la arquitectura. Profundiza aún más el contexto del sistema Vista No-Funcional Se concentra en tener claro conceptos de infraestructura y organización del sistema a partir de la clasificación de los requerimientos no funcionales del sistema. Esta vista acopla los objetivos de negocio del sistema a las características arquitecturales que debe tener el sistema Vista Lógica Representa la estructura del sistema en sus diferentes componentes a desarrollar o integrar. Muestra el diseño de la Arquitectura a Alto nivel y muestra la dependencia entre los componentes Vista de Diseño Se exponen las diferentes aproximaciones de diseño que va a tener el sistema. Esto incluye diagramas de clase y sus formas de interacción (o diagramas de secuencia) para cumplir los casos de uso Vista de Despliegue Muestra por medio del diagrama de despliegue cómo el sistema va a ser desplegado en infraestructura física.

9 Vista de Datos Explica, justifica e identifica los datos que se van a utilizar en el sistema. 2. Contexto En términos generales, el contexto de MOODSTREAM radica en la implementación de 2 aplicaciones. La aplicación cliente, dada por dispositivos móviles, y la aplicación servidor que utiliza patrones de diseño y frameworks empresariales bajo la Plataforma Google AppEngine. Ilustración 1 - Apreciación Global de Arquitectura [1] En la Ilustración 1 se aprecia, de una forma global la forma en la que va a funcionar la arquitectura del sistema. Dividiéndose en la arquitectura móvil [1] y la arquitectura de App Engine.

10 2.1. Arquitectura Móvil Módulo Administrador de conexiones Descripción Está encargado de gestionar la comunicación entre la terminal móvil y la aplicación servidor. Además también por temas visuales mantendrá comunicación con el LBS de Google Maps para desplegar mapas enriquecidos al usuario. Para invocar las funciones necesarias del servidor, el módulo utilizará tareas asincrónicas. De esta forma se podrá hacer búsquedas específicas sin necesidad de comprometer la fluidez de la aplicación. Recibirá la información solicitada en formato JSON. Administrador de sensores Controla y maneja las peticiones a los sensores del dispositivo móvil. Debe verificar que cada petición sea única. Es decir, el sensor a utilizar no puede estar en uso por otra aplicación o hilo propio del programa. Controlador Basado en Eventos El módulo es susceptible a eventos de sensor y de datos provenientes y hacia el servidor. Además maneja la conversión de formato JSON a objetos en la aplicación. Administrador de Objetos del Negocio Contiene los objetos de negocio pertinentes. Invocación Remota Por medio de especificación de interfaces, hace llamados remotos a los métodos/clases del sistema. Render Interfaz Gráfica Hace un render de las interfaces gráficas del sistema. El estándar utilizado en este caso es el XML (propio de la plataforma Android). Persistencia local Ayuda a mantener un estado del sistema así no se tenga conexión a internet. Esto permite que la aplicación tenga más usabilidad y no dependa rotundamente (en los casos de uso básicos) de la aplicación. Tabla 1 - Módulos de la Arquitectura Móvil 2.2. Arquitectura App Engine y S3 Módulo Descripción API Conjunto de interfaces que proveen servicios al sistema. Inicialmente la invocación se hará directamente a un dominio asignado por las herramientas de Google de la forma Memoria Caché Ayuda a que se reduzca la latencia y tasas de

11 NoSQL S3 transacción en la base de datos del sistema. Mantiene una persistencia transitoria de los datos y metadatos más utilizados y así tener un rápido acceso a ellos. Base de datos no relacional especializada para simplificar búsquedas complejas como navegación por grafos en redes sociales. Base de datos especializada en almacenamiento de archivos binarios de gran tamaño. Tabla 2 - Módulos de la Arquitectura del Motor App Engine 3. Vista Funcional Las funcionalidades y prioridades del sistema están especificadas en el Documento de Requerimientos de Software. Se encontrará: Diagrama de Casos de Uso relacionando cada una de las funciones del sistema con los actores. Referencia a la Plantilla HACER del grupo ISTAR [2] de la Pontificia Universidad Javeriana que documenta de una manera más profunda los casos de uso y los respectivos requerimientos funcionales y no funcionales del sistema. 4. Vista No Funcional Por más de que en mayoría de la documentación de software no se hace un énfasis en la definición de los requerimientos no funcionales, se cree que es de vital importancia, dentro del proceso de desarrollo de software, hacer la transición de un modelo conceptual de software a la entrega de este. A continuación se enunciarán los tipos de requerimientos no funcionales en los cuales se quiere hacer énfasis para el sistema de MOODSTREAM Rendimiento El sistema debe brindar una base de datos no relacional. El sistema debe aislar los meta-datos de la foto a los de su contenido binario 4.2. Escalabilidad El sistema debe incluir bases de datos distribuidas 4.3. Seguridad El sistema debe implementar protocolos de autenticación OAuth Internacionalización El sistema debe soportar el idioma Español. El sistema debe soportar el idioma Inglés.

12 5. Vista Lógica La vista lógica permite, a grandes rasgos, mostrar los diferentes componentes del sistema de una manera tal que se muestren las dependencias entre estos y, en dado caso de necesitar más información, la especificación de estos. Ilustración 2 - Diagrama de Componentes MOODSTREAM La Ilustración 2 muestra el diagrama de Componentes del sistema MOODSTREAM. A continuación se presentan las principales características a entender sobre el diseño de este MOODSTREAM Mobile La forma en cómo trabaja es una mezcla entre el patrón MVC (Model View Controller) y el MAS (Mobile Actuator Sensor). El controlador de la aplicación va a permitir gestionar la interacción entre los componentes físicos del dispositivo móvil (como la cámara el GPS y el almacenamiento local) con la interfaz gráfica de usuario y la Interfaz Proveedora de Servicios (SPI). La SPI, por su parte tiene una librería cliente que encapsula peticiones HTTP directas al servidor de aplicaciones de Google MOODSTRAM App Engine Provee la implementación de las interfaces de aplicación (API) que hacen conexión web con aquellos dispositivos móviles que llamen su servicio. Esta capa aísla la lógica,

13 procesamiento interno y almacenamiento de datos de la fachada de la aplicación lo cual la hace más segura y fácil de definir. La API tendrá relación directa con los diferentes sistemas integrados que ofrece la suite básica de App Engine. Esta incluye: Almacenamiento de datos en BigTable con Google Cloud Datastore. Forma de Autenticación federada OPEN-ID por medio de la consola de Google. 6. Vista de Diseño El diseño se divide en dos desarrollos: El desarrollo de la aplicación móvil y el de google app engine. A continuación se presenta una descripción de general de cada uno de los elementos que conforman el diseño de estas 2 aplicaciones:

14 6.1. Diseño Aplicación Móvil Ilustración 3 - Diagrama de Clases Cliente Móvil SPI: Contiene los modelos de datos del sistema y la especificación de los métodos de la API para tener una comunicación directa con Google Appengine. Las clases son empaquetadas por cada entidad y son generadas por el plugin de Google Appengine para el IDE Eclipse. Activity: Las Actividades es una componente de la aplicación que provee una pantalla en la cual un usuario interactuará con ella mantienen la comunicación entre la vista y la lógica de la aplicación. Las aplicaciones en Android usualmente están compuestas de diferentes actividades relacionadas entre sí.

15 Adapter: Los adaptadores definidos en el proyecto ayudaron a controlar los datos suministrados por el back-end en forma de lista. Se combinaron con memoria caché para que su procesamiento fuera optimizado. Util: El paquete de utilidades contiene métodos, variables y constantes de uso general para toda la aplicación. Dentro de las clases de utilidad que se encuentean en el proyecto, están aquellas que controlan la comunicación con Amazon Web Services, transformación de fechas y deducción de distancias según la localización del usuario, entre otras Diseño Aplicación App Engine Model: Alberga las entidades de negocio utilizando el conocido framework de Java Empresarial JPA. Endpoint: Definen las métodos que van a ser utilizados por el API del sistema Util: Contiene constantes de configuración y acceso a la unidad de persistencia del servidor de aplicaciones. Como se está utilizando el Framework de JPA, el administrador de persistencia por defecto se define por una factoría de EntityManager. 7. Vista de Despliegue El sistema se dividió en 4 nodos cómo es mostrado en Ilustración 4:

16 Ilustración 4 - Diagrama de Despliegue MOODSTREAM Smartphone El Smartphone tiene que correr en Ambiente de Ejecución Java Android. Fuera de ejecutar la aplicación principal, este resuelve las dependencias de comunicación que debe tener con los dos nodos de Amazon Web Services y Appengine. Con appengine se utiliza una comunicación de datos ligera a partir de JSON. Servidor AppEngine El Servidor AppEngine se comunica con la aplicación móvil a partir de su definición de los endpoints programados. Fuera de eso, posee protocolos de comunicación con los servidores de Google Datasotre DataStore

17 Como el servicio que ofrece Google Appengine es una Plataforma como Servicio, se desconoce de los métodos de comunicación, distribución y acceso de Google Appengine al Datastore. Servidor Amazon Web Services Se desconoce de la implementación interna del Servidor S3. Sin embargo se sabe que su conexión con el usuario es tipo HTTP POST.