Extensión K2B proyectos para Smart Devices

Transcripción

1 Extensión K2B proyectos para Smart Devices Descripción de la Arquitectura Versión /10/2012 Historia de revisiones Fecha Versión Descripción Autor 28/08/ Creación del documento Diego Cardozo 01/09/ Agregar contenido al documento Matías Morales, Diego Cardozo 01/09/ Revisión SQA Rodrigo Machín 11/10/ Actualización según RTF y versión 3.0 del modelo de diseño Diego Cardozo

2 Contenidos Contenidos... 2 Introducción... 4 Propósito... 4 Alcance... 4 Definiciones, siglas y abreviaturas... 4 Referencias... 4 Visión general... 4 Vista del modelo de casos de uso... 5 Diagrama de casos de uso relevantes a la arquitectura... 5 Casos de uso relevantes a la arquitectura... 5 Inicio de sesión... 5 Registro de horas común... 5 Crear plantillas y registrar horas mediante plantillas... 5 Registro de horas desde archivo... 6 Checkin / Checkout... 6 Ver horas registradas... 6 Gráficas... 6 Notificaciones... 6 Consulta de tareas... 6 Trazabilidad del modelo de casos de uso al modelo de diseño... 7 Inicio de sesión... 7 Registro de horas común... 8 Registro de horas mediante plantillas... 8 Registro de horas desde archivo... 9 Check-in... 9 Check-out Ver horas registradas y ver gráficas Notificaciones Consulta de tareas Vista del modelo de distribución Diagrama de despliegue Componentes Conexiones e interfaces Decisiones relevantes a la implementación

3 Configuración de parámetros Parámetros pre-cargados Gestión de configuración Gestión de errores Gestión de objetos

4 Introducción Propósito El presente documento tiene como fin brindar una apreciación global de la arquitectura del sistema. Por ello comprende su exposición desde distintas vistas para mostrar los diferentes aspectos de la arquitectura diseñada. Alcance En conjunto con el modelo de diseño, este documento sirve para transmitir a todo el equipo de trabajo una visión global del diseño del sistema. Por tanto es fundamental en la fase de construcción, siendo parte del enlace natural entre el análisis y la implementación del sistema. Definiciones, siglas y abreviaturas Modelo de casos de uso. Modelo de diseño. Referencias Visión general En primer lugar se presenta la vista del modelo de casos de uso, en donde se expone la descripción de los casos de uso relevantes para la arquitectura y el motivo para su elección como tal. A continuación se expone la trazabilidad del Modelo de casos de uso al Modelo de diseño (que es descrito en su respectivo documento [2]) para dichos casos de uso. Luego se presenta la vista del modelo de distribución por medio de un diagrama de despliegue y una descripción de los componentes y las conexiones e interfaces. El documento evoluciona en su completitud con las sucesivas iteraciones, acompañando el refinamiento del sistema y el desarrollo del proceso de software. 4

5 Vista del modelo de casos de uso Diagrama de casos de uso relevantes a la arquitectura Casos de uso relevantes a la arquitectura A continuación se incluye la descripción de los casos de uso relevantes a la arquitectura. Inicio de sesión El caso de uso es clasificado como relevante para la arquitectura del sistema dado que determina la utilización del componente GAM para la validación contra el usuario de GXTechnical. Para aislar esta funcionalidad del resto y conseguir que no interfiera con otras, se incorpora el componente dentro del módulo de autenticación. Registro de horas común El caso de uso es crítico para el sistema pues constituye la funcionalidad principal de la aplicación, junto con los demás caso de uso que cubren los distintos métodos de ingreso. Los objetos definidos para la implementación de esta funcionalidad son ampliamente reutilizados en la implementación de otras que se enmarcan dentro del módulo de registro de horas. Crear plantillas y registrar horas mediante plantillas El ingreso mediante plantillas es un mecanismo que busca agilizar y facilitar el ingreso de horas mediante el almacenamiento de datos pre-establecidos dentro de la base de datos. Requiere la definición de estructuras (transacciones), las cuales son consultadas mediante acceso a la base de datos correspondiente a la KB implementada por el grupo. 5

6 Registro de horas desde archivo La funcionalidad asociada con este caso de uso fue pedida específicamente por el cliente desde el comienzo y atiende el perfil ciertos usuarios finales de la aplicación que prefieren o necesitan realizar registros por medio de planillas con un formato predefinido. Si bien se está funcionalidad se incorpora dentro del módulo de ingreso de horas, sus requerimientos arquitectónicos son únicos dado que requiere la incorporación de carga de archivos hacia el servidor para poder trabajar con los mismos. Checkin / Checkout El usuario desea hacer check-in para indicar al sistema que comienza a trabajar en un determinado proyecto, elemento, cargo y tipo de hora. A posteriori, el usuario realizará check out para marcar el fin. El mecanismo de ingreso de horas mediante check-in/check-out es otro de los métodos que busca agilizar el registro de horas y que fue sugerido por el cliente desde el inicio. Si bien el mecanismo comparte objetos con otros tipos de registros, es relevante para la arquitectura considerarlo individualmente dado que sus estructuras de datos se comportan de manera ligerametne diferente a las del resto de la aplicación. Es decir, en general los datos de los registros se almacenan en la base de datos por un período indefinido de tiempo, y no es usual eliminarlos. Sin embargo, el mecanismo de Checkin dá de alta datos que luego deben existir y ser dados de baja al realizar Checkout para poder realizar la correspondiente alta de un registro posteriormente. Ver horas registradas Los principales propósitos del sistema son: agilizar y simplificar el registro de horas y brindar la posibilidad al usuario de realizar un seguimiento de sus horas registradas. Es en este último sentido en donde el caso de uso ver horas registradas cobra significancia, y es el principal representante de las consultas de datos por web service que existen en el sistema. Gráficas La visualización mediante gráficas de los datos de un consultor incorpora riegos técnicos que son sumamente relevantes para la arquitectura. Notificaciones Es quizás la funcionalidad que representa los mayores riesgos y desafíos para la arquitectura. Cada tipo de notificaciones (push, por y por SMS) requieren soluciones distintas y complejas desde un punto de vista arquitectónico. Consulta de tareas Esta funcionalidad impacta la arquitectura dado que define conexiones con interfaces externas al sistema desarrollado y también externas al sistema proporcionado por el cliente. En concreto, esta funcionalidad se conecta con el API de Google. 6

7 Trazabilidad del modelo de casos de uso al modelo de diseño En este apartado se indica la trazabilidad entre el Modelo de Casos de Uso y el Modelo d e Diseño, identificando los subsistemas que intervienen caso de uso. La capa de persistencia remota se refiere a la conexión con los datos de la KB existente en Artech, mientras que la capa de persistencia local se refiere a la conexión con los datos prop i Inicio de sesión 7

8 Registro de horas común Registro de horas mediante plantillas 8

9 Registro de horas desde archivo Check-in 9

10 Check-out Ver horas registradas y ver gráficas 10

11 Notificaciones Consulta de tareas 11

12 Vista del modelo de distribución Diagrama de despliegue Descripción de la Arquitectura 12 Componentes Servidor1: Servidor residente en Artech, donde se encuentra desplegada la KB de K2BProyectos con la cuál nuestro sistema debe interactuar. Servidor2: Servidor donde se encontrará alojado nuestro sistema, junto con su BD (la cuál contiene datos específicos de nuestra aplicación). ServidorBD: Servidor donde se encontrará alojada la base de datos de K2BProyectos con los datos reales de los proyectos, empleados, etc. Dispositivo móvil ios: iphone o ipad con ios en una versión soportada por nuestro sistema. Dispositivo móvil Android: Celular o Galaxy Tab que ejecutan una versión de Android soportada por nuestro sistema. PC: Cualquier PC que ejecuta un navegador soportado por nuestro sistema. Conexiones e interfaces Conexión LAN entre servidores: conexión perteneciente a la DMZ de Artech, por lo cual los web services que utilizan esta conexión no precisan estar encriptados o protegidos con el protocolo https. Web Services entre KBGrupo8 y K2BProyectos: Web services que consumen servicios de la KB de K2BProyectos. Utilizan la conexión LAN perteneciente a la DMZ de Artech, y por lo tanto no se encuentran encriptados o protegidos con el protocolo https.

13 Web Services entre dispositivos móviles o PC y GAM: Estos web services son generados automáticamente por GeneXus para manejar el login persistente. Dado que atraviesan la frontera de la Intranet de Artech, deben estar protegidos utilizando protocolo https y certificados. Web Services entre dispositivos y componentes de KBGrupo8: Estos web services son generados a partir de nuestra aplicación como punto de acceso al sistema para los distintos dispositivos. Dado que atraviesan la frontera de la Intranet de Artech, deben estar protegidos utilizando protocolo https y certificados. Decisiones relevantes a la implementación Configuración de parámetros Los parámetros son los datos que son ingresados a la aplicación en su conjunto (globales) y pueden ser cambiados en tiempo de ejecución sin necesidad de recompilar la aplicación. Para gestionar los parámetros tenemos una transacción Parámetro, la cuál tiene 2 atributos: nombre y valor. Los valores de esta transacción no pueden ser modificados mediante la interfaz de usuario, sino que solamente desde la base de datos. Además, los implementadores pueden obtener el valor de los parámetros mediante el procedimiento PGetParámetro. Parámetros pre-cargados Nombre Valor Significado Dominio de Antel para SMS Dominio de Movistar para SMS FromAddress k2bsdproy@montevideo.com.uy Direccion de origen de los mails FromName k2bsdproy Remitente de los mails PeriodoTimer 300 Timer para notificaciones smtphost smtp-mvd.montevideo.com.uy Host para SMTP (notificaciones ) smtppassword grupo8gx Contraseña para SMTP (notificaciones ) smtpport 25 Puerto para el cliente SMTP stopnotificar 1 1 para notificar, 0 para desactivar Subject Notificacion K2B Asunto de los mails (notificaciones) Gestión de configuración La configuración son los datos que pueden ser ingresados y accedidos por los usuarios, y son específicos de cada uno. Se manejan mediante la transacción ConfigUsuario, la cual puede ser accedida exclusivamente mediante dispositivos móviles. Esto se debe a que las configuraciones solamente son necesarias para las funcionalidades específicas de SD. Gestión de errores Para mostrar los mensajes de error decidimos utilizar ErrorViewer con mensajes de color rojo. 13

14 Gestión de objetos Se presenta un esquema de como se organizarán los objetos según su tipo en la KB. 14