Historia de revisiones

Transcripción

1 Herbert Game Descripción de la Arquitectura Versión 1.8 Historia de revisiones Fecha Versión Descripción Autor 29/08/ Creación del documento Juan Pablo Balarini Máximo Mussini 30/08/ Actualización Juan Pablo Balarini 31/08/ Actualización Juan Pablo Balarini 01/09/ Actualización Máximo Mussini 02/09/ Actualización sección Casos de Uso Juan Torres 03/09/ Revisión de Calidad Federico Dadalt 07/09/ Actualización de diagramas Máximo Mussini 14/09/ Corrección de los índices y algunos de los errores encontrados en la última revisión. Diagramas de paquetes Máximo Mussini 07/10/ Manejo de errores Máximo Mussini 08/10/ Revisión de Calidad Federico Dadalt Descripción de la Arquitectura Página 1 de 15

2 Contenido 1. INTRODUCCIÓN PROPÓSITO ALCANCE DEFINICIONES, SIGLAS Y ABREVIATURAS REFERENCIAS VISIÓN GENERAL ESTILO DE LA ARQUITECTURA VISTA DEL MODELO DE CASOS DE USO DIAGRAMA DE CASOS DE USO RELEVANTES A LA ARQUITECTURA CASOS DE USO RELEVANTES A LA ARQUITECTURA Crear Pantalla Modificar Pantalla Jugar Pantalla Registrar Usuario Modificar Usuario Iniciar Sesión Cerrar Sesión Listar Ranking Facebook TRAZABILIDAD DESDE EL MODELO DE CASOS DE USO AL MODELO DE DISEÑO Crear/Modificar Pantalla Jugar Pantalla Registrar / Modificar Usuario Iniciar Sesión / Cerrar Sesión Listar Ranking Facebook VISTA DEL MODELO DE DISEÑO DIAGRAMA DE COMPONENTES DE LA ARQUITECTURA DESCOMPOSICIÓN EN SUBSISTEMAS SQL Database ADO.NET Entity Framework Herbert Data Access Herbert API Herbert Services Herbert Web Herbert Language Herbert Win UI Herbert Web UI Herbert Windows Phone UI VISTA DEL MODELO DE DISTRIBUCIÓN DIAGRAMA DE DISTRIBUCIÓN NODOS Database Herbert Server Servidor Facebook Servidor Windows Live Windows PC Windows Phone Device Descripción de la Arquitectura Página 2 de 15

3 Web Client CONEXIONES Conexión Herbert - Facebook Conexión Herbert Windows Live Conexión Herbert Base de datos Conexión Windows App - Herbert Conexión Windows Phone App - Herbert Conexión Silverlight App - Herbert Conexión Web Client - Herbert MANEJO DE ERRORES BUENAS PRÁCTICAS Descripción de la Arquitectura Página 3 de 15

4 1. Introducción El presente documento pretende describir la arquitectura a ser utilizada en el proyecto Herbert Propósito Este documento proporciona una apreciación global y comprensible de la arquitectura del sistema usando diferentes puntos de vista para mostrar distintos aspectos del sistema. Intenta capturar y llegar a las decisiones de arquitectura críticas que han sido hechas en el sistema Alcance Esta descripción asistirá a diseñadores e implementadores, siendo una guía para comenzar su desarrollo. A su vez permitirá que otras personas puedan comprender el proyecto de forma global Definiciones, siglas y abreviaturas. Detalladas en el Glosario Referencias Glosario Modelo de Casos de Uso Especificación de requerimientos 1.5. Visión general Se presentan primero los casos de uso más relevantes respecto a la arquitectura del sistema, luego la vista del modelo de diseño, y finalmente la distribución física del mismo mediante un diagrama de despliegue. Descripción de la Arquitectura Página 4 de 15

5 2. Estilo de la arquitectura Se utilizará un estilo de arquitectura en capas, adaptada a los servicios que brinda la plataforma.net. El servidor de la aplicación (que podría o no estar ubicado en la plataforma Windows Azure), brindará servicios a tres tipos de clientes distintos: Windows, Web, y Mobile. Cabe notar que las tres aplicaciones cliente siguen el patrón de diseño de cliente grueso, ya que en ellas se encuentra la mayor parte de la lógica relacionada con el juego, más específicamente, con la interpretación del lenguaje h. Esto permite alivianar la carga del servidor y mejorar los tiempos de respuesta para el usuario, lo cual es fundamental para cualquier programa interactivo. El servidor se encargará de brindar servicios a las aplicaciones cliente a través de WCF, así como de ofrecer servicios web a través de ASP.NET MVC. También estará encargado de manejar la conexión con sistemas externos (Windows Live, Facebook). Finalmente, los datos del sistema se almacenarán en una base de datos SQL Server. El acceso a los mismos se realizará utilizando el ADO.NET Entity Framework, y para una mayor abstracción se desarrolló una capa de acceso a datos liviana siguiendo el patrón de diseño Repository. El sistema propone una fuerte división de las responsabilidades, a través de interfaces bien definidas de acceso a datos, servicios, y comunicación. El diagrama en capas a continuación permite apreciar a grandes rasgos cómo está compuesta la aplicación: Descripción de la Arquitectura Página 5 de 15

6 3. Vista del Modelo de Casos de Uso 3.1. Diagrama de Casos de Uso relevantes a la Arquitectura 3.2. Casos de Uso relevantes a la Arquitectura Crear Pantalla El caso de uso inicia cuando el usuario selecciona la opción de crear una pantalla. Esta pantalla podrá ser jugada por él y por el resto de los usuarios del sistema. Descripción de la Arquitectura Página 6 de 15

7 Modificar Pantalla El caso de uso inicia cuando el usuario selecciona la opción de modificar una pantalla existente en el sistema. En este Caso de Uso, un Jugador solamente podrá modificar una pantalla creada por él mismo, para el caso del Administrador podrá modificar pantallas que se encuentren dentro de las 50 iniciales Jugar Pantalla El Caso de Uso se inicia cuando el usuario selecciona un nivel para jugar el cual debe estar desbloqueado. Luego escribe el algoritmo y una vez confirmado el mismo, el robot (o el elemento en cuestión) se mueve por la pantalla según el algoritmo ingresado y las variantes de la pantalla. Una vez concluido el movimiento se muestra el puntaje obtenido. En caso de no haber completado todos los puntos el mismo es Registrar Usuario El Caso de Uso se inicia cuando el usuario desea registrarse en el sistema. Para ello el sistema muestra un formulario donde el usuario debe ingresar los datos necesarios, entre ellos podrá asociar su cuenta a la de Live y/o Facebook. El sistema valida los mismos y en caso exitoso se le mostrará al usuario la página inicial del juego. En caso contrario se mostrará un mensaje acorde Modificar Usuario El Caso de Uso se inicia cuando el usuario desea cambiar los datos de su cuenta. Para ello el sistema le muestra los datos y el usuario podrá modificar los mismos Iniciar Sesión El Caso de Uso se inicia cuando el usuario desea iniciar sesión en el juego. Para ello el sistema muestra un formulario donde el usuario debe ingresar los datos necesarios. El sistema valida los mismos y en caso exitoso se le mostrará al usuario la página inicial del juego. En caso contrario se mostrará un mensaje acorde Cerrar Sesión El Caso de Uso se inicia cuando el usuario selecciona la opción de cerrar la sesión del juego. Luego el sistema le confirma al usuario que ha cerrado sesión y se muestra la pantalla inicial Listar Ranking Facebook El Caso de Uso se inicia cuando el usuario selecciona la opción de ver el ranking de sus amigos de Facebook. El sistema lista el ranking mencionado. Descripción de la Arquitectura Página 7 de 15

8 4. Trazabilidad desde el Modelo de Casos de Uso al Modelo de Diseño Crear/Modificar Pantalla Herbert Win UI Herbert Services Herbert API Herbert Data Access SQL Database Jugar Pantalla Cargar Pantalla Herbert Web UI Herbert Services Herbert API Herbert Data Access SQL Database Herbert WP7 UI Ejecutar Programa (en lenguaje h ) Herbert Web UI Herbert WP7 UI Herbert Language Registrar / Modificar Usuario Herbert Web UI Herbert Services Herbert API Herbert Data Access SQL Database Herbert WP7 UI Descripción de la Arquitectura Página 8 de 15

9 Iniciar Sesión / Cerrar Sesión Cuenta del sistema Herbert Win UI Herbert Web UI Herbert Services Herbert API Herbert Data Access SQL Database Herbert WP7 UI Cuenta de Facebook Herbert Web UI Facebook API Herbert Services Herbert API Herbert WP7 UI Herbert Data Access SQL Database Cuenta de Windows Live Herbert Web UI Windows Live API Herbert Services Herbert API Herbert WP7 UI Herbert Data Access SQL Database Listar Ranking Facebook Herbert Web UI Facebook API Herbert Services Herbert API Herbert WP7 UI Herbert Data Access SQL Database Descripción de la Arquitectura Página 9 de 15

10 5. Vista del Modelo de Diseño 5.1. Diagrama de Componentes de la Arquitectura Descripción de la Arquitectura Página 10 de 15

11 5.2. Descomposición en Subsistemas SQL Database Base de datos relacional, en principio ubicada en un servidor web, aunque también podría estar ubicada en la nube (SQL Azure). En donde se persistirá toda la información necesaria para el funcionamiento del sistema, tanto la información global como usuarios, niveles, y puntajes, como información personal de cada usuario (user settings) ADO.NET Entity Framework Se utiliza para facilitar la transición del modelo de base de datos relacional al modelo orientado a objetos. Encapsula el acceso a la base de datos, de forma que en lugar de programar sentencias SQL se obtienen las entidades a través de containers Herbert Data Access Encapsula el acceso a datos utilizando el patrón Repository, lo cual permite un acceso uniforme a los datos del sistema y permite una mayor modularidad en el diseño Herbert API Es responsable de proveer una interfaz uniforme para acceder a los servicios del sistema, los cuáles serán reutilizados luego tanto en la plataforma Web como en la plataforma de servicios WCF que brinda el sistema. Define los modelos de datos a utilizar y realiza la conversión entre las entidades y los modelos utilizando una herramienta llamada AutoMapper (ver Glosario). Además, encapsula el acceso a datos obtenidos de sistemas externos (Facebook, Windows Live) Herbert Services Consume algunos de los servicios de la API, exponiendo su funcionalidad a través de servicios WCF de modo que puedan ser consumidos por las aplicaciones cliente. Dichos servicios son la principal forma de comunicación entre el juego y el sistema Herbert Web Esta aplicación ASP.NET es el sitio web de Herbert, dónde se expone en línea información como puntaje global y otros. Permite al usuario jugar a través de una aplicación Silverlight embebida en el sitio, así como crear sus propios niveles de juego. Consume los servicios provistos por la API Herbert Language Básicamente es el motor lógico del juego. Este subsistema es el responsable de interpretar el lenguaje h. También es responsable de calcular el puntaje obtenido por el jugador. Los módulos de presentación (Windows, Web, y Mobile) le suministran los datos necesarios, los cuales procesa, devolviendo información en una forma que resulte útil a los mismos Herbert Win UI Es una aplicación Windows Forms que provee una interfaz gráfica que permite a un administrador acceder a la creación y edición de escenarios. Toda comunicación con el servidor se realiza mediante servicios WCF que consume del módulo de servicios del sistema. Descripción de la Arquitectura Página 11 de 15

12 Herbert Web UI Es la aplicación Silverlight que se encuentra embebida en el sitio web de Herbert, la cual permite jugar al juego Herbert accediendo mediante una cuenta de Facebook o Live (o una cuenta del sistema). Interactúa con el módulo de lenguaje para procesar la entrada del usuario, y representa el resultado de forma gráfica mediante movimientos del personaje, sonidos, y animaciones. Toda comunicación con el servidor se realiza mediante servicios WCF que consume del módulo de servicios del sistema Herbert Windows Phone UI Es la aplicación del juego para Windows Phone. Provee la misma funcionalidad que la aplicación Silverlight. Toda la comunicación con el sistema se realiza a través de servicios WCF. 6. Vista del Modelo de Distribución 6.1. Diagrama de Distribución Descripción de la Arquitectura Página 12 de 15

13 6.2. Nodos Database Es el nodo que aloja la base de datos relacional del sistema. Que esté alojada en un nodo físico distinto permitiría una mejor distribución del sistema, y si se combina con la técnica de granjas de servidores una mejor escalabilidad. Podría ser un servidor de SQL Azure Herbert Server Es el nodo donde ejecutará el servidor del sistema, que contiene a los subsistemas. Aloja tanto la aplicación Web, como la aplicación de servicios WCF. Una alternativa si se cuentan con suficientes recursos es separar ambas aplicaciones, de forma que corran en servidores independientes. Descripción de la Arquitectura Página 13 de 15

14 Servidor Facebook El servidor Facebook es quien provee la interfaz que permite a Herbert obtener información del perfil del usuario y de sus amigos. Este servidor es externo y solo se consumen servicios del mismo Servidor Windows Live El servidor Windows Live es quien proveerá, al igual que en el servidor Facebook, la interfaz que permite a Herbert obtener información del usuario. Este servidor es externo y solo se consumen servicios del mismo Windows PC Corresponde a una computadora ejecutando un sistema operativo Windows, este nodo es el anfitrión de la aplicación Herbert para Windows (conformada por el módulo de lenguaje y el módulo de interfaz Windows). Es necesario contar con conexión a Internet para acceder a la mayor parte de la funcionalidad de la aplicación Windows Phone Device Corresponde a un dispositivo móvil ejecutando un sistema operativo Windows Phone, este nodo es el anfitrión de la aplicación Herbert para Windows Phone (conformada por el módulo de lenguaje y el módulo de interfaz Windows Phone). Es necesario que el dispositivo tenga acceso a Internet para poder funcionar correctamente Web Client El nodo especifica un cliente Web, que es un dispositivo que cuenta con una conexión a Internet y un navegador que soporte Silverlight. El navegador es el encargado de descargar y ejecutar la aplicación Herbert para Silverlight Conexiones Conexión Herbert - Facebook La conexión con la API de Facebook se va a realizar por un canal https sobre TCP. Dicha conexión va a consumir servicios web provistos por Facebook. Se asume que el servidor de Facebook siempre va a estar en línea, y que el servidor de Herbert siempre va a estar disponible Conexión Herbert Windows Live La conexión con la API de Windows Live se va a realizar pon un canal https sobre TCP. Se puede asumir la misma disponibilidad del servicio que en el caso de la conexión con Facebook y con la conexión a Internet Conexión Herbert Base de datos Esta conexión se realiza por https sobre TCP. Se asume que la base de datos siempre estará disponible (si se decide utilizar SQL Azure esto estaría garantizado por las políticas de confiabilidad de servicio que brindan los data-centers de Microsoft) Conexión Windows App - Herbert Se realiza mediante servicios WCF, y es la única vía de comunicación entre Herbert y la aplicación Windows. Se controlan problemas en la comunicación mediante manejo de errores dentro de la aplicación. Descripción de la Arquitectura Página 14 de 15

15 Conexión Windows Phone App - Herbert Se realiza mediante servicios WCF, y es la única vía de comunicación entre Herbert y la aplicación Windows Phone. Se controlan problemas en la comunicación mediante manejo de errores dentro de la aplicación Conexión Silverlight App - Herbert Se realiza mediante servicios WCF, y es la única vía de comunicación entre Herbert y la aplicación Silverlight. Se controlan problemas en la comunicación mediante manejo de errores dentro de la aplicación Conexión Web Client - Herbert Se realiza por un canal https sobre TCP, y tiene como objetivo acceder al sitio web de Herbert para, entre otros, acceder a la aplicación Silverlight en línea que permite jugar al juego desde el navegador. 7. Manejo de Errores 7.1. Buenas Prácticas Para el manejo de errores se seguirán las siguientes prácticas: Encapsulamiento: En caso de que una excepción viaje a través de las capas del sistema y se cree alguna otra a partir de la primera generada, se guarda toda la información del primer error a través del encapsulamiento en el momento de la creación de la nueva excepción. De esta forma, no se pierde información debido a la propagación de la excepción o de la sustitución a través de las capas del sistema, lo cual facilita la corrección de defectos. Lanzar temprano: Las excepciones son lanzadas en el preciso instante en el que ocurre el error. Así se tiene un mejor control a la hora de depurar y de buscar el origen de la falla. Presentación del error: Todo error ocurrido en el sistema por el cual se deba notificar al usuario, debe tener una redacción adecuada, apta para el usuario. No se deberían exponer aspectos internos del sistema, esto podría confundir al usuario o resultarle poco amigable. Descripción de la Arquitectura Página 15 de 15