5/09/ Agregar cambios en las alertas Matias Herrera

Transcripción

1 K2BProyectos Móvil Descripción de la Arquitectura Versión 1.5 Historia de revisiones Fecha Versión Descripción Autor 24/08/ Comienzo de la versión Milagros Garicoits 25/08/ Se corrigen errores, vista del modelo de casos de uso, Milagros Garicoits trazabilidad del modelo de casos de usos al modelo de diseño, comienzo con descomposición en subsistemas 26/08/ Descomposición en subsistemas Milagros Garicoits 26/08/ Revision de SQA Rodrigo Amaro 29/08/ Modificaciones en las Milagros Garicoits transacciones de casos de uso al modelo de diseño y en la descomposición en subsistemas 2/09/ Descripción de las clases Milagros Garicoits 4/09/ Modelo de implementación Milagros Garicoits 5/09/ Corrección de errores Milagros Garicoits, Martin Reyes, Matias Herrera 5/09/ Agregar cambios en las alertas Matias Herrera 5/09/ /09/ Agregar G tecnical al login, repositorio offline Agregar cambios en los Check In/Out no favoritos Milagros Garicoits Matias Herrera 9/09/ Revision SQA Rodrigo Amaro 9/09/ Arreglos luego de la revisión Milagros Garicoits Descripción de la Arquitectura Página 1 de 16

2 Contenido CONTENIDO INTRODUCCIÓN... 4 EL PRESENTE DOCUMENTO BRINDA UNA PRIMERA APROIMACIÓN A LA VISIÓN GLOBAL DE LA ARQUITECTURA DEL SOFTWARE A SER DESARROLLADO PROPÓSITO ALCANCE... 4 ESTA DESCRIPCIÓN AYUDARA A LOS DISEÑADORES E IMPLEMENTADORES EN LA COMPRENSIÓN GLOBAL DE LA ARQUITECTURA DEFINICIONES, SIGLAS Y ABREVIATURAS REFERENCIAS VISIÓN GENERAL VISTA DEL MODELO DE CASOS DE USO CASOS DE USO RELEVANTES A LA ARQUITECTURA Login Ingreso de Horas Simple Reporte Horas y Tareas Disparar Alertas TRAZABILIDAD DESDE EL MODELO DE CASOS DE USO AL MODELO DE DISEÑO Login Ingreso de Hora Simple Reporte de Horas y Tareas [Web] Disparar Alertas VISTA DEL MODELO DE DISEÑO DESCOMPOSICIÓN EN SUBSISTEMAS Modulo GAM Modulo de Servicios Móviles Modulo Servicio Modulo Usuario Modulo Alertas Modulo Template Modulo Tareas Modulo Servicio K2B DISEÑO DE TRANSACCIONES Template TemplateComún CheckInOutFavorito CheckInFavorito Usuario Configuración Feriado Tareas Alerta AleratCheck AleratFaltaIngreso AlertaInsuficienciaMes AlertaInsuficienciaSemana AlertaInsuficienciaDia DISEÑO DE CASOS DE USO TRAZABILIDAD DESDE EL MODELO DE DISEÑO AL MODELO DE IMPLEMENTACIÓN Descripción de la Arquitectura Página 2 de 16

3 6. VISTA DEL MODELO DE IMPLEMENTACIÓN SUBSISTEMAS K2BProyectosMovil COMPONENTES [Componente 1] INTERFASES [Interfase 1] K2BResumida COMPONENTES [Componente 1] INTERFASES [Interfase 1] VISTA DEL MODELO DE DISTRIBUCIÓN DIAGRAMA DE DISTRIBUCIÓN NODOS Google Calendar GTechnical Apache Tomcat (KB K2BProyectos Móvil) Apache Tomcat (KB K2BResumida) MySQL DBMS (BD Proyecto Móvil) DBMS DONDE SE IMPLEMENTARA LA BASE DE DATOS MySQL DBMS (BD K2B Resumida) DBMS DONDE SE IMPLEMENTARA LA BASE DE DATOS CONEIONES DADA LA ETAPA EN LA QUE SE ENCUENTRA EL PROYECTO, AUN NO CONTAMOS CON DEMASIADA INFORMACIÓN Apache Tomcat - MySQL Entre los Servidores Clientes Servidores Descripción de la Arquitectura Página 3 de 16

4 1. Introducción El presente documento brinda una primera aproximación a la visión global de la arquitectura del software a ser desarrollado 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 ayudara a los diseñadores e implementadores en la comprensión global de la arquitectura Definiciones, siglas y abreviaturas. Ver Glosario 1.4. Referencias Glosario Especificación de Requerimientos de Software versión 1.4 Modelo de Casos de Uso versión Visión general En este documento se describen los modelos de los casos de uso más relevantes al momento para la Arquitectura. En esta Iteración se describen los puntos 2 (Vista del modelo de casos de uso), 3 (Trazabilidad del modelo de casos de uso al modelo de diseño), y parte del punto 4 (Descomposición en subsistemas) Uno de los aspectos claves definidos en esta Arquitectura corresponde a que la aplicación será utilizada por dispositivos móviles, así como también será una aplicación web. Como uno de los requisitos presentados por el cliente, es que sea posible la sincronización con el repositorio ya existente en Genexus Consulting, se tomo la decisión de publicar web services, para cumplir dichos propósitos. Descripción de la Arquitectura Página 4 de 16

5 2. Vista del Modelo de Casos de Uso 2.1. Casos de Uso relevantes a la Arquitectura Presentamos en este diagrama los casos de usos mas relevantes a la Arquitectura del sistema a contruir, de manera de ayudar a mitigar los riesgos mas serios, y representar las funcionalidades mas importantes para el cliente y los usuarios. Descripción de la Arquitectura Página 5 de 16

6 Login Nombre Actor Descripción Login Consultor SD, Consultor WEB El usuario desea ingresar al sistema, para ellos indica el nombre de usuario y contraseña. Debe poseer de una cuenta en Genexus Consulting ya que el login será contra el repositorio del mismo. El login será persistente, es decir, se recordara el usuario y contraseña para futuros usos de la aplicación, en donde no será necesario ingresar los datos nuevamente, a menos que el usuario desee cerrar sesión Ingreso de Horas Simple Nombre Actor Descripción Ingreso de Horas Simple Consultor SD, Consultor WEB El usuario desea registrar horas de manera normal, es decir ingresando todos y cada uno de los campos requeridos para el registro Reporte Horas y Tareas Nombre Actor Descripción Reporte Horas y Tareas Consultor WEB Permite a un consultor ver un reporte de los registros de sus horas ingresados para un rango de fechas asociado a las tareas realizadas, tanto en el SD como en Google Calendar, para esas fechas Disparar Alertas Nombre Actor Descripción Disparar Alertas Reloj Cada cierto tiempo el sistema revisa las alertas existentes, y en caso de que una deba ser enviada, lo hace, ya sea por sms, o push (según la configuración del usuario) Descripción de la Arquitectura Página 6 de 16

7 3. Trazabilidad desde el Modelo de Casos de Uso al Modelo de Diseño Se describe la trazabilidad entre el Modelo de Casos de Uso y el Modelo de Diseño. Identificando los objetos y subsistemas de diseño que intervienen en el caso de uso y sus relaciones mediante una tabla. Caso de Uso Login Ingreso de Horas Simples Reporte de Horas y Tareas Disparar Alertas Usuario Configuración Feriado Tarea Template Template Comun Check in/out Favorito Check in Favorito Check in no Favorito Alerta Check Alerta InsuficienciaMensual AlertaInsuficienciaDia AlertaInsuficienciaSemana AlertaFaltaIngreso Modulo Usuario Modulo Horas Modulo Alerta Modulo Tarea Modulo Servicio GAM Modulo Servicio K2B GTechnical Login Muestra la necesidad de implementar un modulo de seguridad, que autentique y autorice al usuario a logearse a la aplicación para su uso. También es importante para la arquitectura porque releva la necesidad de implementar un modulo de servicios que consuma web services de la KB proporcionada por el cliente, y que permitan autenticar al usuario Ingreso de Hora Simple Muestra la necesidad de implementar una capa de servicios que provea integración con la KB brindada con el cliente, probando la funcionalidad principal de la aplicación. Descripción de la Arquitectura Página 7 de 16

8 Reporte de Horas y Tareas [Web] Muestra la necesidad de implementar una capa de servicios para la comunicación con la API de Google Calendar, ya que se consultarían las tareas ingresadas por el usuario a través del Calendar. También presenta la necesidad de implementar una capa de servicios que permitan invocar operaciones para consultar los registros ingresados por el usuario Disparar Alertas Es importante para reducir los riegos con respecto a la funcionalidad de alertas a través de , sms o push de notificaciones. Descripción de la Arquitectura Página 8 de 16

9 4. Vista del Modelo de Diseño 4.1. Descomposición en Subsistemas cmp BlackBerry UI Android UI Iphone UI Web UI Capa de Presentacion <<Servicios Externos>> GTechnical Modulo K2BProyectos Movil Modulo Usuario GAM Modulo de Servicios Moviles Modulo K2B Resumido <<Servicios Externos>> Google API Modulo Alertas Modulo Horas Modulo Servicio K2B Modulo Tareas Modulo Servicio Google Modulo Servicio Logica de Negocio BD Proyecto Movil BDK2B Resumida Capa de Persistencia Modulo GAM El modulo GAM será el encargado del login para los usuarios. Se encara de autenticar y autorizar. Necesitara consultar en la base de datos de la Kb K2B resumida, para autenticar a los mismos Modulo de Servicios Móviles Este modulo es el que implementara los procedimientos que serán consumidos desde los SD y la web. Determinara también los permisos de los usuarios, dependiendo si son administrativos o no Modulo Servicio Este modulo es el encargado de consumir los web services publicados en el modulo resumido de K2B Modulo Usuario Descripción de la Arquitectura Página 9 de 16

10 Engloba lo referente a los usuarios y a las configuraciones personales del mismo, como por ejemplo, los feriados, días laborables, horas contratadas, , celular, tipos de notificaciones, etc Modulo Alertas Este modulo mantendrá lo referente a las configuraciones de alertas, ya que un usuario puede dar de alta distintos tipos de alertas Modulo Horas Este modulo engloba todo lo referente a registros de horas, ya sean desde templates, check in/out, ingreso simple y masivo de horas Modulo Tareas Este modulo es el encargado de manejar las tareas. Un usuario puede dar de alta, modificar e eliminar tareas personales creadas por el, pero también se podrán consultar las tareas que el usuario ingrese en Google Calendar, desde su . Por ello, dentro de este modulo, contamos con modulo de servicios, que será el encargado de comunicarse con la API de Google Calendar Modulo Servicio K2B Modulo que publica los servicios a consumir desde el modulo K2BProyectos Movil. Sera el encargado de la comunicación entre estos dos. Descripción de la Arquitectura Página 10 de 16

11 4.2. Diseño de Transacciones pkg Template Modulo Horas Modulo Usuario Usuario ModuloTarea Tarea TemplateComun CheckInOutFavorito Configuracion Feriado CheckInFavorito Modulo Alertas Alerta AlertaCheck AlertaInsuficienciaDia AlertaFaltaIngreso AlertaInsuficienciaMes AlertaInsuficienciaSemana Capa Logica K2B RRHHTipoHora RRHHRegistroHoras Persona RRHHk2b RRHHk2bPuestoEmpleado ProyectoTipoHora EDT Proyecto ProyectoPuesto ProyectoPuestoPersona Template Es una transacción padre, referente al registro de hora mediante templates. Tiene un nombre, un id que lo identifica, el proyecto, elemento y tipo de hora TemplateComún Generalización de la transacción Template, utilizada para registrar horas mediante un template (o pattern) que el usuario configura a su gusto, indicando hora de inicio, de fin, cantidad de horas trabajadas y si son facturables o no CheckInOutFavorito Descripción de la Arquitectura Página 11 de 16

12 Generalización de la transacción Template, utilizada para hacer registros de horas por medio de Check In s. Esta clase tiene como atributos únicamente los de la transacción padre CheckInFavorito Esta transacción es creada cuando el consultor realiza un check in. Se utiliza para almacenar los datos temporalmente, para luego, al hacer check out (u otro check in), poder guardar el registro de hora Usuario Esta transacción es utilizada para referenciar a los consultores. Guarda un nombre de usuario, el celular (para enviar alertas por sms), el , la contraseña y una variable para indicar si el usuario tiene permisos de administrador o no Configuración Se utiliza para almacenar las preferencias del usuario con respecto a recibir alertas via sms, o push de notificaciones. También se configuran los días laborables y las horas por las que fue contratado Feriado Utilizada para indicar las fechas de días feriados Tareas Se utiliza para la funcionalidad brindada al usuario para dar de alta tareas. Tienen un nombre, una fecha, una descripción, hora inicio, hora fin, un campo para indicar si finalizo o no, duración estimada, duración real (una vez finalizada) Alerta Es una transacción padre que encapsula las propiedades generales de las alertas, mantiene el nombre y la hora de disparo de la alerta, además establece si esta activada o no AleratCheck Se utiliza para bridar la funcionalidad al usuario de configurar alertas que le avise en caso de no realizar checking AleratFaltaIngreso Es utilizada para advertir al usuario en caso de no haber realizado un registro a una hora previamente configurada por el mimo AlertaInsuficienciaMes Se utiliza para bridar la funcionalidad al usuario de configurar alertas que le avise en caso de no alcanzar el valor esperado de horas ingresadas en un mes AlertaInsuficienciaSemana Se utiliza para bridar la funcionalidad al usuario de configurar alertas que le avise en caso de no alcanzar el valor esperado de horas ingresadas en una semana AlertaInsuficienciaDia Se utiliza para bridar la funcionalidad al usuario de configurar alertas que le avise en caso de no alcanzar el valor esperado de horas ingresadas entre un día de inicio y otro de fin Diseño de Casos de Uso Descripción de la Arquitectura Página 12 de 16

13 Ver documento de Diseño de Casos de Uso 5. Trazabilidad desde el Modelo de Diseño al Modelo de Implementación En nuestro modelo de diseño podemos ver dos módulos principales (diferenciados con color verde y celeste), uno que representa la KB resumida que nos brindo el cliente, y otro que representa el nuevo sistema para SD. Dentro de este ultimo nos encontramos con 4 módulos distintos; uno abarca lo relativo a los usuarios, y configuraciones personales, otro modulo implementara lo relativo a las tareas, por otro lado tenemos un modulo relacionado a las alertas, y configuraciones de las mismas, y por ultimo el modulo template, el cual se relaciona con el ingreso de los registros de horas, sea comúnmente o a través de un template, o check in s. También tenemos 2 modulos que corresponden a los servicios a publicar y consumir. Pero estos módulos serán implementados en una misma KB, por lo cual, nuestro sistema estará compuesto por dos subsistemas: K2BProyectosMovil y K2BResumida, que se comunicaran por protocolo SOAP. 6. Vista del Modelo de Implementación 6.1. Subsistemas K2BProyectosMovil Este subsistema corresponde a la base de conocimiento en donde se implementaran los módulos tareas, alertas, usuarios y template. En esta KB se publicaran los servicios que serán consumidos desde los SD y desde la web, y también habrá un modulo que será el encargado de consumir los servicios brindados por la KB resumida que nos brindo el cliente. Este subsistema será el encargado de manejar los registros, check s in/out, alertas y tareas ingresadas por el usuario. Descripción de la Arquitectura Página 13 de 16

14 6.2. Componentes [Componente 1] [Se especifica la correspondencia con el Modelo de Diseño del Componente 1 implementado relevante a la Arquitectura. También se debe especificar cómo están organizados los componentes de acuerdo a la estructura y mecanismos de modularización disponibles en el ambiente de implementación y en el(los) lenguaje(s) de programación, y cuales son las dependencias entre los distintos componentes. Pueden existir dependencias de compilación entre componentes, denotando cuales componentes son requeridos para la compilación de un componente específico.] 6.3. Interfases [Interfase 1] [Se detalla brevemente y se especifica la correspondencia con el Modelo de Diseño de la Interfase 1 relevante a la Arquitectura.] K2BResumida Este subsistema corresponde a la base de conocimientos que nos brindo el cliente. Se la encargada de ingresar en la base de datos los nuevos registros de horas y hacer consultas sobre los mismos Componentes [Componente 1] 6.5. Interfases [Interfase 1] Descripción de la Arquitectura Página 14 de 16

15 7. Vista del Modelo de Distribución 7.1. Diagrama de Distribución 7.2. Nodos Google Calendar Servidor de Google Calendar, que expone un servicio por el cual obtenemos la información de las tareas ingresadas en el calendar del usuario GTechnical Servicio externo donde se consumirá el servicio web para realizar el login de los consultores Apache Tomcat (KB K2BProyectos Móvil) Servidor Web donde se encontrara la aplicación implementada por nosotros Apache Tomcat (KB K2BResumida) Servidor Web donde se encontrada la aplicación de K2B que brinda el cliente MySQL DBMS (BD Proyecto Móvil) DBMS donde se implementara la base de datos. Descripción de la Arquitectura Página 15 de 16

16 MySQL DBMS (BD K2B Resumida) DBMS donde se implementara la base de datos Conexiones Dada la etapa en la que se encuentra el proyecto, aun no contamos con demasiada información Apache Tomcat - MySQL Esta conexión se realizara mediante el driver JDBC Entre los Servidores Esta conexión se realizará a través de la red LAN interna de IBM (intranet) Clientes Servidores Los clientes web y desde los SD se comunicaran por http con el servidor. En caso de disponer de la funcionalidad offline, habrá que implementar web services para la subida y bajada de datos al momento de la sincronización con los SD. Descripción de la Arquitectura Página 16 de 16