arquitecturadesoftware-proyecto-i documentation

ArquitecturaDeSoftware-Proyecto-IDocumentation

Versión latest

22 de agosto de 2018

Índice general

1. Índice: 11.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2. Siguiendo la Metodología AD-HOC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2.1. Vision y Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.2. Se identifican los Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.3. Se definen los objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2.4. Historias de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.5. Selección de historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2.6. Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3. Propósito del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.1. Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.3.2. Los Servicios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3.3. Requisitos No Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.1. Visión de Conjunto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.4.2. Sección de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.3. Componente Frontend Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4.4. Componente Aplicación Móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.4.5. Componente Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.4.6. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191.4.7. Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.4.8. Sección de Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.5. Comportamiento Dinámico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.5.1. Especificación De Escenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.5.2. Modelo de Interacción de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.6. Otras Vistas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.1. Vista de Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.2. Vista de Desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291.6.3. Vista Física . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

1.7. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.7.1. Dominio Léxico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301.7.2. Diagrama Léxico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

1.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

I

CAPÍTULO 1

Índice:

1.1 Introducción

En la actualidad los sistemas informaticos han ido adquiriendo nuevas complejidades y se vuelve esencial diseñar ar-quitecturas apropiadas para enfrentar los diversos cambios requeridos en su implementacion, asi tambien los requisitosfuncionales del sistemas y los requisitos no funcionales propios de cada uno de los stakeholders.

A continuacion se plantea la documentacion en conjunto con el proceso de desarrollo de una solucion informática,planteada por equipo de desarrolladores, ingenieros y arquitectos del curso de Arquitectura de Software implementadopor la Universidad de La Frontera para la carrera de Ingenieria Civil Informática, en donde se utilizará la metodologíapara el desarrollo de software llamada AD-HOC Methodology, la cual sera de gran ayuda para recoleccion de la infor-macion relevante para la puesta en marcha del proyecto, además se expondra el desarrollo de cada una de las etapasque contempla para logrará diseñar y posteriormente implementar una solucion informatica al problema planteado.

Para la documentacion del proyecto utilizaremos como referenciar el documento «A Template for Documenting Soft-ware and Firmware Architectures» version 1.3, 15-Mar-00, en donde se definen las secciones principales de un docu-mento en donde se exclarecen todos los aspectos mas detallados de la solución.

1

ArquitecturaDeSoftware-Proyecto-I Documentation, Versión latest

1.2 Siguiendo la Metodología AD-HOC

1.2.1 Vision y Objetivo

La complejidad inherente de los actuales sistemas hace necesario diseñar una apropiada arquitectura para los sistemas,de modo de enfrentar los diversos cambios requeridos, así como satisfacer los requisitos funcionales como no funcio-nales. En esta ocasión, se requiere diseñar un sistema que permita capturar parámetros medioambientales (temperaturay humedad) y proveer una plataforma web que permita visualizar en forma gráfica las temperaturas durante el dia. Serequiere además, que dicha aplicación, pueda ser vista desde un equipo móvil (android), pero en este caso, se requiereenviar preguntas específicas que deben ser almacenadas en el sitio web, para ser respondidas y que sean visibles paratodos los usuarios.

1.2.2 Se identifican los Stakeholders

Para la realización del proyecto se ha identificado 3 tipos de usuarios. Usuarios Web: Es aquel usuario que se conectaal sistema desde la web. Usuario Móvil: Es aquel usuario que se conecta al sistema desde una App Móvil. UsuarioModerador: Es aquel usuario que autoriza o niega las preguntas enviadas por un usuario.

1.2.3 Se definen los objetivos

De acuerdo a cada uno de los usuarios identificados los los objetivos que esperan cumplir cada uno de ellos.

Usuario Web

Objetivos:

Conocer datos de parámetros medioambientales.

Proveer de ayuda a las preguntas de usuarios móviles.

Usuario Movil

Objetivos:

Obtener información de temperatura de diferentes situaciones.

Usuario Moderador

Objetivos:

Autorización de la publicación de mensajes.

2 Capítulo 1. Índice:


1.2.4 Historias de Usuario

Luego de realizar conversaciones con los stackeholder se definen y se eligen las historias de usuarios para ser imple-mentadas en el sistema.

Yo como <Usuario> quiero <hacer alguna acción> que me entregue <algo>.

Usuario Web

HU-WEB - 01 Visualizar la temperatura y humedad actuales.

HU-WEB - 02 Visualizar un mapa de temperaturas maximas y minimas dentro de un intervalo dado.

HU-WEB - 03 Visualizar en gráficos los valores históricos de temperatura y humedad para poder comparardentro de un intervalo específico de fechas.

HUW - 04 Permitir responder a las preguntas del usuario móvil.

Usuario Móvil

HU-MOV - 01 Yo como usuario móvil quiero poder enviar preguntas acerca del clima.

HU-MOV - 02 Yo como usuario móvil quiero saber cuando mis preguntas sean aprobadas para ser publicadas.

HU-MOV - 03 Yo como usuario móvil quiero ser notificado cuando mis preguntas sean respondidas.

HU-MOV - 04 Yo como usuario móvil quiero visualizar las respuestas a mis preguntas.

Moderador

HU-MOD - 01 Yo como usuario moderador quiero saber cuando alguien realiza una pregunta para poder aprobaro no (recibir una notificación).

HU-MOD - 02 Yo como usuario moderador quiero aprobar preguntas de usuario móvil.

HU-MOD - 03 Yo como usuario moderador quiero saber cuando alguien responde a una de las preguntas yaaprobadas para filtrar su contenido.

1.2.5 Selección de historias de usuario

En primer lugar se definen los criterios para la selección de las historias de usuarios que se implementarán. Cada unode los siguientes criterios se aplica asignando una nota entre 1-10.

Complejidad de implementación: Nota de 1 hasta 10, donde 1 es muy fácil de implementar, y 10 es muy difícilsu implementación.

Relevancia para el Usuario: Nota de 1 hasta 10, donde 1 es de muy poca relevancia, y 10 es muy importante ocrucial su implementación.

Disponibilidad de herramientas para reuso: Nota de 1 hasta 10, donde 1 significa que no existen herramientaso librerias para su reuso, y 10 significa que existen suficientes librerias y son de fácil implementación.

Usuario web

Historia deusuario

Complejidad de imple-mentación:

Relevancia para elUsuario:

Disponibilidad de herramientaspara reuso:

HU-WEB - 01 1/10 10/10 8/10HU-WEB - 02 8/10 5/10 4/10HU-WEB - 03 4/10 9/10 8/10HU-WEB - 04 1/10 9/10 10/10

1.2. Siguiendo la Metodología AD-HOC 3


Considerando cada uno de los criterios mensionados en la tabla, se implementarán las historias de usuario, HU-WEB- 01, HU-WEB - 03, HU-WEB - 04. La historia de usuario HU-WEB - 02 no se implementó debido a su complejidady la falta de librerías y conocimientos en el área de mapas geográficos.

Usuario movil

Historia deusuario




HU-MOV - 01 1/10 10/10 10/10HU-MOV - 02 7/10 6/10 8/10HU-MOV - 03 7/10 6/10 8/10HU-MOV - 04 1/10 9/10 10/10

Para el usuario movil, se implementarán las historias HU-MOV - 01 y HU-MOV - 04. Las historias de usuario HU-MOV - 02 y HU-MOV - 03 no se implementarán por el hecho de que manejar lás notificaciones es muy complejo yrequiere más tiempo que del que se dispone.

Usuario moderador

Historia deusuario




HU-MOD - 01 7/10 6/10 8/10HU-MOD - 02 1/10 10/10 10/10HU-MOD - 03 7/10 7/10 8/10

Para el usuario moderador, se implementará la historia HU-MOD - 02. Las historias HU-MOD - 01 y HU-MOD - 03no se implementarán por el hecho de que es complejo implementar un sistema de notificaciones y no se cuenta con eltiempo suficiente.

1.2.6 Mockups

A continuacion se presentan los mockups diseñados de acuerdo a una posterior discucion con el equipo de desarrollo,de esta forma.

Mockups peteneciente a Usuario Web



Mockups peteneciente a Usuario Móvil



Mockups peteneciente a Usuario Moderador



1.3 Propósito del Sistema

problem description, system interface, non-functional requierements

1.3.1 Contexto

Descripción del Problema

La complejidad inherente de los actuales sistemas hace necesario diseñar una apropiada arquitectura para los sistemas,de modo de enfrentar los diversos cambios requeridos, así como satisfacer los requisitos funcionales como no funcio-nales. En esta ocasión, se requiere diseñar un sistema que permita capturar parámetros medioambientales (temperaturay humedad) y proveer una plataforma web que permita visualizar en forma gráfica las temperaturas durante el dia. Serequiere además, que dicha aplicación, pueda ser vista desde un equipo móvil (android), pero en este caso, se requiereenviar preguntas específicas que deben ser almacenadas en el sitio web, para ser respondidas y que sean visibles paratodos los usuarios.

1.3. Propósito del Sistema 11


1.3.2 Los Servicios

Servicios provistos por el Sistema

Interface ServiciosServicio de Usuarios

Provee acceso a la persistencia de datos, permitecrear, buscar, actualizar y eliminar objetos de tipoUsuario.

Servicio de MedidasEntrega medidas de temperatura, humedad res-pecto a diferentes posibles rangos de tiempo.

Servicio de PreguntasProvee acceso a la persistencia de datos, permitecrear, listar, obtener, actualizar y eliminar pregun-tas.Permitir registrar respuestas a preguntas.

Servicio de RespuestasProvee acceso a la persistencia de datos,permitecrear, listar, obtener, actualizar y eliminar res-puestas.

GráficosPermitir visualizar gráficos de medidas y compa-rar medidas de diferentes periodos.

1.3.3 Requisitos No Funcionales

Requisitos

Los sensores utilizados deben poder conectarse a la base de datos para proveer las medidas registradas, sinembargo, si la conexión a la base de datos es interrumpida, el software controlador del sensor debe mantenerseen pausa hasta establecer una nueva conexión.

Restricciones

El software del sensor debe estar programado en un lenguaje de bajo consumo de recursos.



1.4 Estructura

1.4.1 Visión de Conjunto

El sistema se encuentra compuesto por tres componentes principales; Backend, Frontend Web, Aplicación Móvil,agregando otras dos partes adicionales; un motor de base de datos y una colección de sensores.

El Frontend web tiene Componentes Visuales que le permiten a los usuarios interactuar gráficamente con ellos,contienen vistas y controladores. Los Ocultadores de Componentes Visuales controlan la forma en la que ciertoscomponentes se despliegan al usuario.

La Aplicación Móvil se describe de una forma bastante similar, pero este al no tener un acceso a navegador por URLno requiere Ocultadores de Componentes para impedir el acceso a ciertos componentes de URL.

Los Servicios del Frontend y la Aplicación Móvil se comunican con el Spring Servlet del Backend utilizando elprotocolo HTTP, por lo que aquí se encuentra presente un Estilo de Arquitectura Orientada a Servicios (SOA), especí-ficamente REST. Las solicitudes pasan por varios filtros (Pipes and filters), uno de ellos es el filtro de Autenticaciónel cuál extrae credenciales a las peticiones de los usuarios.

Las peticiones que llegan al Spring Servlet son derivadas a los Controladores, los cuales conocen la intención dela solicitud y generan una respuesta dependiendo de la operación que se requiere. Para generar tal respuesta, losControladores solicitan datos al componente Repository, el cuál contiene diversas interfaces que permiten gestionarla información de la Base de Datos (Estilo de Arquitectura Repository). Sin embargo, Repository no puede hacer estodirectamente ya que no conoce exactamente cuál motor de base de datos se encuentra utilizando, por lo que deriva taltarea al Hibernate Entity Manager, para generar los procedimientos de comunicación con la Base de Datos.

El Sensor es un componente técnico que puede comunicarse directamente con la Base de Datos para almacenarinformación respecto a las medidas que este obtiene.

Los Modelos tienen el propósito de dar a conocer la estructura de los datos que se deben almacenar en la Base deDatos, por lo que Hibernate Entity Manager los utiliza principalmente para conocer la forma de los datos.

1.4. Estructura 13


1.4.2 Sección de Componentes

En esta seccion se describe cada uno de los componentes pertenecientes a cada una de las las arquitectura que compo-nen nuestro sistema.

1.4.3 Componente Frontend Web

Componente Frontend_WebResponsabilidades

Interactúa con el usuario web y el usuario mo-derador, a través de componentes visuales quepermiten cierto acceso a componentes de URL.Es intermediario entre las operaciones de losusuarios y el backend.

ColaboradoresComponente: Backend

Notas El componente se crea una sola vez y persiste durantetodo el tiempo.

Problemas

Componentes Visuales

SubComponente Frontend_Web_Componentes_VisualesResponsabilidades

Se encarga de contener los contenidos visuales yelementos que componen las vistas del frontendweb del sistema.Interfaces provistas:

• Grafico_medidas: Provee los metodospara modificar los diferentes valoresmedidas para posteriormente graficar.

ColaboradoresSubComponente: Frontend_Web_ServicesInterface: Grafico_medidas

Notas El sub-componente se crea una vez y persiste mientrasel sistema esta en uso.

Problemas



Servicios

SubComponente Frontend_Web_ServiciosResponsabilidades

Contiene todos los servicios que son necesariospara interactuar con el backend.Es intermediario entre las operaciones de losusuarios y el backend.Interfaces previstas:

• Usuario_controller: Provee accionespara acceder a un usuario y registrar unusuario.

• Pregunta_controller: Provee las accio-nes para listar todas las preguntaspor diferentes criterios (no aprobadas,aprobadas o todas). Además le permiteal moderador aprobar preguntas.

• Respuesta_controller: Provee los me-todos al moderador para aprobar res-puestas, ademas de listar por respuestasaprobadas o no aprobadas.

• Medida_controller: Provee los metodospara listar todas medidas registradas,como tambien por un rango de fechas

ColaboradoresSubComponente: Backend_Spring_ServletInterface: Usuario_controllerInterface: Pregunta_controllerInterface: Respuesta_controllerInterface: Medida_controller

Notas El sub-componente se crea se crea una sola vez y seinyecta en los componentes visuales. Pueden existir dis-tintas instancias del componente.

Problemas

Ocultadores de componentes visuales

SubComponente Frontend_Web_Ocultadores_De_Componentes_VisualesResponsabilidades

Se encarga de restringir el acceso de los elemen-tos visuales para los distintos usuarios.

ColaboradoresSubComponente: Fron-tend_Web_Componentes_Visuales


Problemas

1.4. Estructura 15


1.4.4 Componente Aplicación Móvil

Componente Aplicación_MóvilResponsabilidades

Interactúa con el usuario móvil, permitiendolecrear preguntas acerca del clima.Es el intermediario entre las operaciones de losusuarios móvil y el backend.

ColaboradoresComponente: Backend

Notas El componente se crea una sola vez y persiste mientrael sistema está en ejecución.

Problemas

Componentes Visuales

SubComponente Aplicación_Móvil_Componentes_VisualesResponsabilidades

Se encarga de contener los contenidos visuales yelementos que componen las vistas de la aplica-ción movil.Es intermediario entre las operaciones de losusuarios móvil y el backend.

ColaboradoresSubComponente: Aplicación_Móvil_Servicios


Problemas



Servicios

SubComponente Aplicación_Móvil_ServiciosResponsabilidades

Interactúa con el usuario web y el usuario mo-derador, a través de componentes visuales quepermiten cierto acceso a componentes de URL.Es intermediario entre las operaciones de losusuarios y el backend.Interfaces provistas:

• Usuario_controller: Provee metodospara registrar y acceder a un usuario.

• Respuesta_controller: Provee metodospara crear preguntas y listar por criteriode preguntas aprobadas y no aprobadas.

ColaboradoresComponente: Backend_Spring_ServletInterface: Usuario_controllerInterface: Pregunta_controller

Notas El sub-componente se crea se crea una sola vez y seinyecta en los componentes visuales. Pueden existir dis-tintas instancias del componente.

Problemas

1.4.5 Componente Backend

Componente BackendResponsabilidades Se encargar de recicibir todas las peticiones del compo-

nenColaboradores

Componente: Frontend_WebComponente: Aplicación_MóvilComponente: Base_de_datos

Notas El componente se crea una vez y persiste todo el tiempopara el sistema. Existe solo una instancia del componen-te en la arquitectura.

Problemas

1.4. Estructura 17


Spring Servlet

SubComponente Backend_Spring_ServletResponsabilidades

Se encarga de recicibir todas las peticiones y de-rivarlas a los respectivos controladores.

ColaboradoresSubComponente: Backend_ControladoresSubComponente: Backend_Autenticación

Notas El sub-componente se encuentra disponible (persiste)durante todo el tiempo para el sistema. Existe solo unainstancia del sub-componente.

Problemas

Autenticación

SubComponente Backend_AutenticacionResponsabilidades

Realiza operaciones para comprobar una solicitudde autentificacion

ColaboradoresNotas El sub-componente se crea una sola vez y persiste por

siempre para el sistema. Existe solo una instancia delcomponente en la arquitectura.

Problemas

Controladores

SubComponente Backend_ControladoresResponsabilidades

Reciben solicitudes y generan una respuesta, de-pendiendo de la operación que se requiere.

ColaboradoresSubComponente: Backend_Repository

Notas El sub-componente controladores se crea una sola vez yes persistente la ejecución del sistema. Se instancia unasola vez en la arquitectura.

Problemas Las referencias ciclicas en los modelos generan conflic-tos al generar el JSON.



Repository

Entity Manager

SubComponente Backend_Entity_ManagerResponsabilidades

Se encarga de realizar los procedeimientos de co-municacion para conectar con la base de datos.Realiza las operaciones CRUD a las tablas de labase de datos.

ColaboradoresSubComponente: Backend_Modelos

Notas El sub-componente Entity Manager se crea una sola vez,y esta instancia persiste para todo el sistema mientrasesta funcionando.

Problemas

Modelos

SubComponente Backend_ModelosResponsabilidades

Dan a conocer la estructura de los datos que sedeben almacenar en la base de datos.

ColaboradoresNotas El sub-componente es creado a medida que es necesita-

do por el Entity Manager y es destruido una vez ya nose necesita. Existen muchas instancias del componenteen la arquitectura.

Problemas

1.4.6 Base de Datos

Componente Base_de_datosResponsabilidades

Almacenar y gestionar la información de medi-ciones, sensores, usuario, preguntas y respuestas.

ColaboradoresNotas El componente se crea una sola vez, y existe solo una

instancia de este en sistema la cual persiste durante todoel tiempo.

Problemas

1.4. Estructura 19


1.4.7 Sensor

Componente SensorResponsabilidades

Registrar medidas medioambientales y almace-narlas en el componente Base_de_datos.

ColaboradoresComponente: Base_de_datos

Notas Existen muchas instancias del componente sensor, sinembargo, cada una de persiste una vez es creada.

Problemas

1.4.8 Sección de Interfaces

En esta sección se describen y especifican los servicios o interfaces que provee el sistema.



Usuario

Interface Usuario_controllerDescripción Permite acceder, eliminar, crear y actualizar un usuario.Operaciones

Operación: usuario_index()Ruta: usuarioMetodo: GETDescripción: Lista cada usuario con sus datos(nombre, correo)

Operación: usuario_store( usuario_data )Ruta: usuarioMetodo: POSTDescripción: Guarda todos los datos de un nuevousuario

Operación: usuario_show ( usuario id )Ruta: usuario/{id}Metodo: GETDescripción: Muestra todos los datos del usuarioespecificado en el id

Operación: usuario_destroy ( usuario id )Ruta: usuario/{id}Metodo: DELETEDescripción: Elimina al usuario correspondienteal id

Operación: usuario_update ( usuario id, usuarionew_data)Ruta: usuarioMetodo: PUTDescripción: Actualiza los datos del usuario es-pecificado en el id

Protocolo No existen restricciones en el orden de las operacionesNotas Esta interface es provista en el componente servicios del

frontend y el componente servicios de la aplicación mo-vil

Problemas

1.4. Estructura 21


Pregunta

Interface Pregunta_controllerDescripción Permite acceder, eliminar, crear, actualizar y listar por

preguntas aprobadas y no aprobadas.Operaciones

Operación: pregunta_index()Ruta: preguntaMetodo: GETDescripción: Lista cada pregunta con sus datos,ademas extrae las respuestas de cada pregunta

Operación: pregunta_indexAprobados()Ruta: pregunta/aprobadosMetodo: GETDescripción: Lista cada pregunta aprobada consus datos, además respuestas de cada pregunta

Operación: pregunta_indexNoAprobados()Ruta: pregunta/noaprobadosMetodo: GETDescripción: Lista cada pregunta no aprobadacon sus datos.

Operación: pregunta_store( pregunta_data )Ruta: preguntaMetodo: POSTDescripción: Guarda todos los datos de una nue-va pregunta

Operación: pregunta_show ( pregunta id )Ruta: pregunta/{id}Metodo: GETDescripción: Muestra todos los datos de una pre-gunta especificada en el id

Operación: pregunta_destroy ( pregunta id )Ruta: pregunta/{id}Metodo: DELETEDescripción: Elimina la pregunta correspondien-te al id

Operación: usuario_update ( usuario id )Ruta: pregunta/aprobar/{id}Metodo: GETDescripción: Cambia el estado de una preguntano aprobada a aprobada.



Problemas1.4. Estructura 23


Respuesta

Interface Respuesta_controllerDescripción Permite acceder, aprobar, eliminar, ademas de listar por

respuestas no aprobadas.Operaciones

Operación: respuesta_indexNoAprobado()Ruta: respuesta/noaprobadosMetodo: GETDescripción: Lista las respuestas no aprobadascon sus datos.

Operación: respuesta_store( respuesta_data )Ruta: respuestaMetodo: POSTDescripción: Guarda todos los datos de una nue-va respuesta

Operación: respuesta_aprobar ( respuesta id )Ruta: respuesta/aprobar/{id}Metodo: GETDescripción: Permita aprobar una respuesta conla id especificada

Operación: respuesta_destroy ( respuesta id )Ruta: respuesta/{id}Metodo: DELETEDescripción: Elimina la respuesta correspon-diente al id



Problemas



Medida

Interface Medida_controllerDescripción Permite acceder, guardar, listar y encontrar medidas en-

tre un rango de fechas.Operaciones

Operación: medida_index()Ruta: medidaMetodo: GETDescripción: Lista todas las mediciones registra-das.

Operación: medida_indexOf( Rango ran-go_fecha )Ruta: medida/rangeMetodo: POSTDescripción: Lista todas las medidas encontradasen el rango de fechas establecido.

Operación: medida_store( medida_data )Ruta: medidaMetodo: POSTDescripción: Guarda todos los datos de una nue-va medida

Operación: medida_show ( medida id )Ruta: medida/{id}Metodo: GETDescripción: permite obtener la medida corres-pondiente al id



Problemas

1.4. Estructura 25


Grafico

Interface Grafico_medidasDescripción Permite graficar las medidas registradas, cambiar el ran-

go de fechas a a partir de una lista de medidasOperaciones

Operación: grafico_setMedidas()Descripción: Permite modificar las medidas quese mostrarán en el gráfico.

Protocolo No existen restricciones en el orden de las operacionesNotas Esta interface es provista en el componente de Forntend,

especificamente en el sub-componente componentes vi-suales.

Problemas

1.5 Comportamiento Dinámico

1.5.1 Especificación De Escenarios

Para describir el comportamiento dinamico utilizaremos el diagrama de casos de usos.

Casos de Uso



Definición de Actores.

ACT -<01>

Visitante Web

Descrip-ción

Corresponde al visistante web que accede a la información sobre paramestros medioambientales yresponder preguntas en el sistema web.

ACT - <02> Visitante MóvilDescripción Corresponde al visitante movil que accede para realizar preguntas.

ACT - <03> Visitante ModeradorDescripción Corresponde al usuario que accede para filtrar las preguntas y las respuestas de los demas visitantes.

Definición de casos de usos.

CU - <01> Visualizar datos de parámetros medioambientalesActores ACT - <01>Descripción Permite al actor visualizar los datos de parametros medioambientales.Pre-condición El actor esta autentificado.Secuencia Nor-mal

Paso Acción1 El usuario selecciona fechas para visualizar mediciones.2 El sistema extrae los datos registrados en la base de datos.3 El sistema muestra los registros de parametros medioam-

bientales.

CU - <02> Responder PreguntasActores ACT - <01>Descripción Permite al usuario responder pregunatas.Pre-condición El campo de texto debe tener contenido.Post-condición El actor recibió una alerta indicando que el mensaje se envió.Secuencia Normal Paso Acción

1 Escoger la pregunta a responder2 Rellenar el campo con el contenido a enviar.3 Presionar el botón «Enviar»

Puntos de Inclusión Obtener preguntas y respuesas

CU - <03> Obtener preguntas y respuestas.Actores ACT - <01>Descripción El actor puede acceder a las diferentes preguntas y respuestas que han sido aprobadas.Secuencia Normal Paso Acción

1 Dirigirse al menú de preguntas y respuestas.

1.5. Comportamiento Dinámico 27


CU - <03> Filtrar preguntas y respuestas pendientes de aprobaciónActores ACT - <03>Descripción Permite al moderador aprobar y/o eliminar preguntas.Pre-condición Hay preguntas por aprobar.Secuencia Normal Paso Acción

1 Dirigirse al panel de preguntas no aprobadas.2 Presionar el botón “Rechazar” de la pregunta o respuesta que se

desea rechazar.3 El sistema realiza los cambios a las preguntas o respuestas selec-

cionadas.Secuencia Alter-nativa

Paso Acción

2b Presionar el botón “Aceptar” de la pregunta o respuesta que sedesea aprobar.

CU - <03> Registrar preguntasActores ACT - <02>Descripción El actor puede registrar preguntas medioambientales.SecuenciaNormal

Paso Acción1 Dirigirse al menú de preguntas y respuestas.

Secuencia Al-ternativa

Paso Acción

1 El actor ingresa la pregunta y la envía.2 El sistema registra la pregunta y muestra un mensaje indicando que la nueva

pregunta se encuentra en evaluación.

CU - <03> Mostrar preguntas.Actores ACT - <02>Descripción El actor puede acceder a las diferentes preguntas que él registró, y puede ver las respuestas de las

preguntas aprobadas.SecuenciaNormal

Paso Acción1 Dirigirse al menú de preguntas y respuestas.2 El usuario selecciona la pregunta deseada.3 El sistema entrega todos los datos de la pregunta

seleccionada.



1.5.2 Modelo de Interacción de Componentes

Mecanismos

1.6 Otras Vistas

1.6.1 Vista de Procesos

1.6.2 Vista de Desarrollo

1.6.3 Vista Física

Diagrama de Despliegue A, considerando una implementecion con pocos recursos disponibles.

1.6. Otras Vistas 29


Diagrama de Despliegue B, considerando una implementecion con una mayor cantidad de recursos disponibles.

1.7 Marco Conceptual

1.7.1 Dominio Léxico

Sensor: Es un aparato electrónico que registra medidas medioambientales del sector en el que se encuentra.

Medida: Consiste en un registro que graba información de temperatura y humedad en un momento específicode tiempo.

Gráfico: Es un gráfico de interpolación que muestra variaciones de medidas entre un rango de tiempo.

Pregunta: Es una pregunta sobre el clima, que puede ser creada por cualquier tipo de usuario.

Respuesta: Es un registro que puede ser creado por cualquier tipo de usuario, para poder responder una pregunta.

Moderador: Un tipo de usuario que puede gestionar las cuentas de usuario del sistema, y moderar/sancionarpreguntas y respuestas indebidas.

Usuario: Cualquier tipo de persona que utiliza el sistema y registra una cuenta de usuario en el, puede ser unvisitante web, visistante móvil o moderador.



1.7.2 Diagrama Léxico

Restricciones

Una Pregunta o Respuesta no puede ser visualizada si el Moderador no la aprueba.

En caso de que no existan Medidas, el gráfico puede mostrarse vacío.

Para que exista una Pregunta o una Respuesta, debe haber un Usuario que la haya creado.

1.8 Conclusiones

Con la realización de este proyecto hemos podido poner en práctica nuestros conocimientos de Arquitectura de soft-ware adquiridos durante el semestre los cual son una excelente base para la comunicación.

La arquitectura de software es mas bien un plan del sistema primordial para la comprensión, negociación y comuni-cación entre todos los interesados que nos facilita el proceso de toma de decisiones, la administración de todo tipo decambios y el logro de un desarrollo más eficiente.

Junto a el equipo se realizó un diseño escalable del modelo de negocio que nos permite maximizar el ciclo de vida dela aplicación y minimizar los tiempos de desarrollo de nuevas funcionalidades, actualizaciones, etc.

Esta escalabilidad facilitara la integración de distintos tipos de dispositivos clientes con las mismas prestaciones queel punto anterior.

Ventajas del Sistema

Para el desarrollo del sistema se escogió el uso de una arquitectura RESTful en java utilizando el Framework Spring-Boot para el Backend y el Framework Angular para nuestro Frontend las principales ventajas y desventajas que estaimplantación nos ofrece serian:

Ventajas del uso de REST

1. Separación entre el cliente y el servidor: el uso de REST separa totalmente la interfaz de usuario del servidory el almacenamiento de datos. Eso tiene algunas ventajas cuando se hacen desarrollos. Como mejorar la por-tabilidad de la interfaz a otro tipo de plataformas, aumenta la escalabilidad de los proyectos y permite que losdistintos componentes de los desarrollos se puedan evolucionar de forma independiente.

2. Visibilidad, fiabilidad y escalabilidad: La separación entre cliente y servidor tiene una ventaja evidente y esque cualquier equipo de desarrollo puede escalar el producto sin excesivos problemas. Se puede migrar a otrosservidores o realizar todo tipo de cambios en la base de datos, siempre y cuando los datos de cada una de laspeticiones se envíen de forma correcta. Esta separación facilita tener en servidores distintos el Frontend y elBackend y eso convierte a las aplicaciones en productos más flexibles a la hora de trabajar.

1.8. Conclusiones 31


3. La API REST siempre es independiente del tipo de plataformas o lenguajes: la API REST siempre se adaptaal tipo de sintaxis o plataformas con las que se estén trabajando, lo que ofrece una gran libertad a la hora decambiar o probar nuevos entornos dentro del desarrollo. Con una API REST se pueden tener servidores PHP,Java, Python o Node.js. Lo único que es indispensable es que las respuestas a las peticiones se hagan siempreen el lenguaje de intercambio de información usado, normalmente XML o JSON.

Desventajas del uso de REST

1. Con el uso de REST no mantenemos estados y eso hace que se deba montar una infraestructura propia parapoder conservar el conjunto de la aplicación. Generalmente el Frontend enviara un token que indicara quién esal servidor y qué es lo que ya se ha realizado en el sistema.

2. Puede producirse en determinadas circunstancias mayor rigidez en el desarrollo, sobre todo al ser dos o másproyectos independientes, el Backend basado en REST y el o los múltiples Frontend.

3. Pueden surgir situaciones de des-sincronización. Por ejemplo, desde el cliente (Frontend) se detectan nuevosrequisitos del API (Backend) y los encargados de crearlas en la parte del server pueden estar a otro ritmo ytardar en desarrollarlas.

Ventajas del uso de SpringBoot

1. Tiene un completo soporte de transacciones.

2. Es posible utilizar anotaciones.

3. El manejo de las conexiones a la base de datos se realiza por medio de DataSources.

4. El cierre de las conexiones a la base de datos es transparente al usuario.

5. Cuenta con manejo de DAOs los cuales manejan la conexión a la base de datos, que son los que obtienen yguardan los datos.

6. Se integra fácilmente con diferentes ORM lo que permite a nuestro código ser flexible a diferentes implementa-ciones.

Desventajas del uso de SpringBoot

1. Por cada servicio que tengamos debemos de configurarlo en un xml.

2. No podemos saber si realizamos bien la inyección de un objeto más que en tiempo de ejecución.

Ventajas del uso de Angular

1. Preparado para cualquier tipo de aplicaciones

2. Excelente documentación técnica

3. Un buen número de módulos creados por la comunidad

4. Sugiere muy buenas convenciones para nombrar tus archivos, componentes, módulos y servicios

5. Hace uso extensivo de un stack moderno que incluye: TypeScript y Webpack.

6. Posee una Command Line Interface: Angular CLI que permite generar código boilerplate muy rápidamente

7. Preparado para lazy loading

8. Provee un modo producción y un modo desarrollo

9. Listo para Ahead of Time Compilation

10. Angular es bien apreciado en el mundo front-end empresarial

Desventajas de uso Angular

1. Angular es un Framework que puede ser complejo, por lo que la curva de aprendizaje puede ser alta dependiendode la experiencia previa de los desarrolladores.



2. En algunas situaciones puede ser engorroso rastrear los errores generados durante el desarrollo

Con estos puntos es fácil poder apreciar que la cantidad de ventajas supera en un gran numero a las desventajas queson de menor relevancia para él sistema.

Inconsistencias en la Arquitectura

Respecto a las inconsistencias de el desarrollo del sistema podemos destacar solo una, que los sensores medioambien-tales utilizados realizan una conexión directa a la base de datos para el almacenamiento

Posibles direcciones evolución

Durante la reunión junto a los Stakeholders se trato el punto de la implementación de mapas de temperatura parafechas establecidas por los clientes, este punto será fácil de tratar una vez que se tenga una mayor cantidad de datosmedioambientales de sensores en distintas ubicaciones, gracias a la separación entre el cliente y el servidor será mássimple implementar cualquier nueva característica como esta.

1.8. Conclusiones 33

arquitecturadesoftware-proyecto-i documentation

Documents