Extensión K2B proyectos para Smart Devices

Extensión K2B proyectos para

Smart Devices

Descripción de la Arquitectura

Historia de revisiones

Fecha Versión Descripción Autor

28/08/2012 1.0 Creación del documento Diego Cardozo

01/09/2012 1.1 Agregar contenido al documento Matías Morales, _{Diego Cardozo}

01/09/2012 1.2 Revisión SQA Rodrigo _Machín

2

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 ... 10

Ver horas registradas y ver gráficas ... 10

Notificaciones ... 11

Consulta de tareas ... 11

Vista del modelo de distribución ... 12

Diagrama de despliegue... 12

Componentes ... 12

Conexiones e interfaces... 12

3

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

Referencias

 Modelo de casos de uso.

 Modelo de diseño.

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.

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.

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 email 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.

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

8

Registro de horas común

9

Registro de horas desde archivo

10

Check-out

11

Notificaciones

12

Vista del modelo de distribución

Diagrama de despliegue

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

dominioAntel @ancelinfo.com.uy Dominio de Antel para SMS

dominioMovistar @sms.movistar.com.uy Dominio de Movistar para SMS

FromAddress [email protected] 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 email)

smtpPassword grupo8gx Contraseña para SMTP (notificaciones email)

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

14

Gestión de objetos