4.5.1.1.

Descripción de casos de uso

Los principales casos de uso para el sistema ciber son descritos en Tabla 4.24.

Tabla 4.24. Descripción de casos de uso

Casos de uso
UC-1: Recolectar datos
UC-2: Detectar evento de
fuga
UC-3: Visualizar el
rendimiento de servicios
UC-4: Monitorear el
proceso en línea
UC-5: Soportar análisis de
datos
UC-6: Proveer reportes de
operación
UC-7: Reprocesar tramas de
datos no enviadas
Fuente: Elaboración propia
Descripción
El sistema debe recibir, registrar y procesar trama de datos en
tiempo casi real de las variables medidas (temperatura, flujo,
presión y ruido acústico) en el poliducto.
El equipo del plan de contingencias de la empresa transportadora
debe ser notificado 24/7 de algún desbalance inusual de las
variables
medidas.
El administrador debe visualizar el rendimiento de cada uno de los
servicios de la arquitectura de manera gráfica e interactiva.
Un usuario deberá ingresar sus credenciales (usuario/contraseña) en
una interfaz para ver el estado actual de operación de las
estaciones de monitoreo.
Se requiere de una plataforma que soporte la ejecución de
algoritmos capaces de detectar y ubicar fugas en el poliducto.
Mediante la exploración de logs, los cuales deben incluir
información del origen y destino de los datos, un time stamp.
Debido a que el proveedor de Cloud pública garantiza un 99% de
la disponibilidad de sus servicios, se requiere que el sistema
reprocese
el 1% restante.

5.2.2. Escenarios de atributos de calidad

Los escenarios de atributos de calidad más relevantes son presentados en la Tabla 4.25. Para
cada escenario se han identificado los casos de uso asociados.

Tabla 4.25 Descripción de los escenarios de atributos de

calidad Fuente: Elaboración propia
Atributos de Caso de uso
ID Escenario
calidad asociado
Se estima que 20 estaciones de monitoreo envían
datos simultáneamente en intervalos de 10s. Por lo
QA-1 Rendimiento menos el 99% de los datos son procesados y UC-1, 2,5
almacenados correctamente, con un tiempo de
procesamiento menor a 2s.
En la etapa de producción, la interfaz de monitoreo
QA-2 Rendimiento deberá refrescarse automáticamente con una latencia UC-4
menor 1s.
La implementación de las estaciones de monitoreo
QA-3 Escalabilidad será de manera progresiva, la disponibilidad y Todos
rendimiento
de todo sistema no se debe ver afectado.
El sistema deberá continuar operando en modo
QA-4 Disponibilidad degradado ante la falla de cualquier nodo o Todos
componente hasta ser restablecido en máximo 30 min.
En la etapa de desarrollo, el sistema deberá facilitar la
QA-5 Testeabilidad realización de pruebas de concepto de todos los Todos
servicios de la solución.
 Tabla 4.25. Descripción de los escenarios de atributos de calidad -
Continuación Fuente: Elaboración propia
Atributos de Caso de uso
ID calidad Escenario asociado
El sistema deberá facilitar la realización de pruebas
para verificar los cálculos de los datos estadísticos
QA-6 Testeabilidad UC-6
realizados por los algoritmos son correctos, o si la
información obtenida es veraz al 100%.
Por lo menos el 99% de las operaciones realizadas por
QA-7 Seguridad Todos
el sistema deben ser registradas en logs.
Cada vez que los usuarios ingresen sus credenciales a
QA--8 Seguridad la interfaz de monitoreo estas deben encriptadas y el UC-4
acceso se registrará en la BD el 100% de los casos.

5.2.3. Restricciones

Las restricciones asociadas al sistema se presentan en la Tabla 4.26.

Tabla 4.26. Descripción de las restricciones

Fuente: Elaboración propia
ID Restricción
CON-1 Usar Cloud pública como modelo de despliegue con el proveedor AWS.
CON-2 Usar XaaS como modelo de servicio de Cloud Computing.
CON-3 El protocolo de comunicación debe estar orientado a IoT.
CON-4 Se deben soportar por lo menos 20 dispositivos y 20 usuarios conectados en simultáneo.
CON-5 El acceso al sistema debe ser a través de un navegador web (Chrome, Firefox, IE8+).
La conexión de internet de las estaciones de monitoreo puede tener un ancho de banda
CON-6
limitado, pero en general es confiable.

5.2.4. Preocupaciones arquitecturales

Las preocupaciones arquitecturales iniciales que se han considerado se muestran en la Tabla

4.27.
Tabla 4.27. Descripción de las
preocupaciones Fuente: Elaboración
propia
ID Preocupación
CRN-1 Establecer una estructura general del sistema, siguiendo una arquitectura de referencia.
CRN-2 Aprovechar el conocimiento del programador sobre PHP, CSS y Javascript.
CRN-3 Familiarizar al diseñador con los servicios que brinda el proveedor de Cloud pública.
4.5.2. Proceso de diseño ADD 3.0

4.5.2.1. Revisión de las entradas

El primer paso del proceso ADD consiste en revisar las entradas e identificar los
requerimientos que será considerado como “drivers”.

Tabla 4.24. Descripciones entradas

Fuente: Elaboración propia
Categoría Descripción
El propósito es elaborar un diseño lo suficientemente detallado del sistema
Propósito de diseño ciber.
De los casos de uso presentados anteriormente, los siguientes son
considerados primarios:
Requerimientos  UC-1
funcionales primarios  UC-2
 UC-4
 UC-5
Detallados en la Tabla 4.25. Pero deben ser priorizados.
ID Importancia para el usuario Dificultad de implementación
QA-1 Alto Alto
QA-2 Alto Medio
QA-3 Alto Medio
Escenarios de QA-4 Alto Alto
atributos de calidad QA-5 Bajo Medio
QA-6 Bajo Medio
QA-7 Medio Medio
QA-8 Medio Medio
De la lista, sólo QA-1, QA-2, QA-3, QA-4, QA-7, QA-8 serán
seleccionados como drivers.
Restricciones Todas las restricciones detalladas en la Tabla 4.26.
Preocupaciones Todas las preocupaciones arquitecturales detalladas en la Tabla 4.27 son
arquitecturales incluidas como drivers.

4.5.2.2. Iteración 1: Selección de la arquitectura

Paso 2: Establecer el objetivo de la iteración por medio de la selección de drivers

El objetivo de esta primera iteración es resolver la preocupación arquitectural (CRN-
1) de establecer una estructura inicial para el sistema. Sin embargo, también se ha
tenido en cuenta todos los drivers que puedan influir en la estructura general del
sistema:
- QA-1: Rendimiento
- QA-2: Rendimiento
- QA-3: Escalabilidad
- QA-4: Disponibilidad
- QA-7: Seguridad
 - QA-8: Seguridad
- CON-1: Usar Cloud pública como modelo de despliegue con el proveedor
AWS.
- CON-2: Usar Xaas como modelo de servicio de Cloud computing
- CON-3: El protocolo de comunicación debe estar orientado a IoT.
- CON-6: La conexión de internet de las estaciones de monitoreo puede tener
un ancho de banda limitado, pero en general es confiable.

Paso 3: Escoger uno o más elementos para ser refinados

Por tratarse de la primera iteración, el elemento a refinar es todo el sistema.

Paso 4: Escoger uno o más conceptos de diseño para satisfacer los drivers
seleccionados
En la Tabla 4.25, se muestra las decisiones de diseño.

Tabla 4.25. Decisiones de diseño – Iteración 1

Fuente: Elaboración propia
Decisiones de
diseño y Rationale
alojamiento
La arquitectura IoT Backend serverless, está compuesto por:
1. Capa para la ingesta de datos en tiempo real, que soporta grandes
cantidades de datos provenientes de dispositivos conectados (QA-1).
2. Capa de almacenamiento de datos, compuesto por tres servicios:
2.1. Servicio dedicado a base de datos de tipo no relacional,
especializado para lectura de datos con una baja latencia estable en el
rango de los milisegundos de un dígito (QA-1).
2.2. Servicio de repositorio objetos, para el almacenamiento de datos
procesados. A demás, permite almacenar archivos estáticos de HTML
y JS de una página web.
2.3. Servicio redundante de base de datos para almacenamiento en el
Seleccionar la orden del peta bytes, se encarga de realizar una réplica de los datos
arquitectura de procesados.
referencia 3. Capa de procesamiento, con el servicio de MapReduce, para la
“IoT Backend computación paralela de los datos (QA-2).
Serverless” 4. Servicio dedicado de monitoreo y administración de recursos. (QA-7)
propuesta por En términos generales esta arquitectura de referencia permite crear una
el proveedor solución rentable y escalable a lo largo del tiempo (QA-3), y está
AWS especializada para ser integrada con dispositivos IoT (CON-3).
Alternativas Motivos de descarte
Real-time stream  Uso orientado para el seguimiento de la actividad
processing de una aplicación, procesamiento de sus
serverless transacciones, limpieza de datos, análisis de
redes sociales.
 No cuenta con servicio de MapReduce.
Data lake  Uso orientado para aplicaciones de Big Data.
 Ofrece bastante libertad para escoger los servicios,
lo cual significa un impacto negativo debido a la
poca experiencia en diseño de software. (CRN-3)
 Decisiones de diseño y
alojamiento Rationale
El protocolo MQTT ha sido seleccionado por los siguientes
motivos:
 Protocolo orientado a IoT (CON-3).
 Protocolo soportado por la arquitectura de referencia.
Definir MQTT como  Requiere muy poco ancho de banda (CON-6).
protocolo de  Precisa de muy pocos recursos para su funcionamiento
comunicación. Alternativa Motivo de descarte
Constrained Application
Protocol (COAP) Protocolos no soportados
por la arquitectura de
Extensible Messaging and
referencia
Presence Protocol (XMPP)
Lenguaje estándar para intercambio de datos que destaca por
ser ligero y rápido.
Alternativa Motivo de descarte
Definir JSON como Extensible Markup Language Formato universal para
formato de envío y (XML) datos sin embargo, es más
recepción de datos pesado en I/O.
YAML Ain’t Markup No es compatible con el
Language (YAML) protocolo de comunicación
establecido.

En la Figura 4.9 se presenta un boceto de la arquitectura de referencia, sin tener en

cuenta las tecnologías recomendadas por AWS, dado que se requiere elaborar una
estructura inicial del sistema.

Figura 4.9. Boceto inicial de la arquitectura de referencia

Fuente: Elaboración propia

Paso 5: Instanciar los elementos arquitecturales, asignar responsabilidades y

definir interfaces
Las decisiones de diseño se resumen en la Tabla 4.26.

Tabla 4.26. Decisiones de diseño – Iteración 1

Fuente: Elaboración propia
Decisiones de diseño y
alojamiento Rationale
Colocar el protocolo
Al ser el protocolo seleccionado
MQTT entre las
para la comunicación de IOT se
estaciones y capa
ingesta debe colocar entre la comunicación
de las estaciones y la capa de ingesta
de datos.
 Colocar JSON entre las
Al ser el formato seleccionado para
estaciones y capa
el transporte de datos de las
ingesta
estaciones, se debe colocar entre la
comunicación de las estaciones y la
capa de ingesta de datos.
En la arquitectura de referencia se tiene tres servicios de
Eliminar elemento replicar base de datos, para esta etapa inicial del proyecto es
datos procesados en la innecesario utilizar el bloque de réplica de datos ordenados
capa de almacenamiento debido a que genera un costo adicional. Sin embargo, no
se descarta la
posibilidad de usarlo a futuro.
 Tabla 4.26. Decisiones de diseño – Iteración 1
(Continuación) Fuente: Elaboración propia

Decisiones de diseño y
alojamiento
Dividir el elemento de
“ingerir datos” en tres sub
elementos .
Renombrar a la capa de
ingesta por capa de ingesta
y analítica
Rationale
La arquitectura de referencia seleccionada carece de
elementos de seguridad, y de pre-procesamiento de datos.
Por lo tanto, el elemento “ingerir datos” se descompone en:
 Seguridad e Identidad.
 Gestionar mensajes.
 Filtrar datos.
Más cambio de nombre implica una inclusión de una nueva
tarea (filtrar datos).

Paso 6: Boceto de las vistas y registro de las decisiones de diseño

En la Figura 4.9, se muestra el boceto de la arquitectura teniendo en cuenta las
decisiones de diseño.

Figura 4.9. Boceto inicial de la arquitectura

diseñada Fuente: Elaboración propia

En la Tabla 4.27, se describe la responsabilidad de cada elemento que compone la

arquitectura diseñada.

Tabla 4.27. Elementos de la arquitectura diseñada – Iteración 1

Fuente: Elaboración propia
Elemento Responsabilidad
Capa de ingesta y Esta capa es responsable de recolectar información de todas las
analítica fuentes de datos y enviarla a la capa de almacenamiento.
Capa de Esta capa se encarga de almacenar dos tipos de datos: ‘en crudo’ y
almacenamiento procesados.
Capa de Esta capa se encarga del procesamiento de la información.
procesamiento
Capa de Esta capa se encarga de monitorear el estado de cada servicio.
monitoreo
Seguridad e Elemento es responsable de establecer una conexión segura entre los
identidad dispositivos y el sistema.
Gestionar Este elemento se encarga de gestionar la cola de mensajes.
mensajes
 Tabla 4.27. Elementos de la arquitectura diseñada – Iteración 1 (Continuación)
Fuente: Elaboración propia
Elemento Responsabilidad
Este elemento clasifica los datos según su tipo: temperatura, flujo,
Filtrar datos
presión, ruido acústico.
Almacenar datos Este elemento se encarga de almacenar los datos provenientes de la
en crudo capa de ingesta y analítica.
Este elemento se encarga de almacenar los datos provenientes de la
Almacenar datos
capa de procesamiento de datos. Además, permite almacenar
procesados
contenido
estático de un sitio web.
Este elemento permite procesar gran cantidad de datos en
MapReduce “multithreading”.
Este elemento ofrece información procesable para monitorear sus
Monitorear aplicaciones, comprender cambios de rendimiento que afectan a todo
servicios el sistema y tomar acciones, optimizar el uso de recursos y lograr una
vista unificada del estado de las operaciones.

Paso 7: Realizar el análisis del diseño actual, revisar el objetivo de la iteración

y el logro del propósito del diseño
Las decisiones tomadas en esta iteración abordan importantes consideraciones
iniciales que afectan a la estructura general del sistema. No fue necesario empezar
desde cero dado que la arquitectura de referencia seleccionada ofrece una estructura
inicial y un flujo de datos estandarizado.

En la Tabla 4.28, se resume el proceso de diseño utilizando el tablero Kanban.

Tabla 4.28. Tablero Kanban – Iteración 1

Fuente: Elaboración propia
No Parcialmente Completamente Decisiones de diseño durante la
realizado realizado realizado iteración
Seleccionar una arquitectura de
referencia que proporciona los
UC-1 servicios de ingesta de datos. Queda
pendiente el detalle de la tecnología
a utilizar.
Seleccionar una arquitectura de
referencia que proporciona un
UC-2 elemento encargado de MapReduce.
Queda pendiente el detalle de la
tecnología a utilizar.
Este caso de uso ha omitido en esta
iteración por no ser considerado
como primario. Sin embargo, la
UC-3 arquitectura de referencia
seleccionada lo respalda con un
elemento. El detalle del elemento
aún no ha sido definido
UC-4 No se han tomado decisiones.
Seleccionar una arquitectura de
UC-5 referencia que soporta esta
funcionalidad.
 Tabla 4.28. Tablero Kanban – Iteración 1
(Continuación) Fuente: Elaboración
propia
No Parcialmente Completamente Decisiones de diseño durante la
realizado realizado realizado iteración
Este caso de uso ha omitido en esta
iteración por no ser considerado
como primario. Sin embargo, la
UC-6 arquitectura de referencia
seleccionada lo respalda con un
elemento. El detalle del elemento
aún no ha sido definido.
Este caso de uso ha omitido en esta
UC-7 iteración por no ser considerado
como primario.
Dividir el elemento de “ingerir
datos” en tres sub elementos. El
QA-1
detalle de estos elementos aún no ha
sido definido.
QA-2 No se han tomado decisiones.
No se han tomado decisiones, ya que
QA-3 AWS garantiza escalabilidad en sus
servicios.
No se han tomado decisiones, ya que
Q-4 AWS garantiza la alta
disponibilidad de sus servicios.
QA-7 No se han tomado decisiones.
QA-8 No se han tomado decisiones.
Elegir AWS como proveedor de
CON-1 Cloud pública.
Seleccionar una arquitectura de
referencia de tipo serverless. Queda
CON-2
pendiente agregar más elementos a
la arquitectura.
CON-3 Seleccionar el protocolo de
comunicación MQTT orientado a
CON-6 IoT.
Seleccionar una arquitectura de
CRN-1 referencia.
CRN-2 No se han tomado decisiones.
Algunas de las tecnologías que se
CRN-3 mencionan son familiares con el
diseñador.

4.5.2.3. Iteración 2: Integración de la capa de ingesta y la capa de presentación Paso 2:

Establecer el objetivo de la iteración por medio de la selección de drivers

El objetivo de esta iteración es identificar los elementos necesarios para integrar la
capa de ingesta y la capa de presentación a la arquitectura seleccionada.
En esta segunda iteración el caso de uso que se atenderá es el UC-4. Los atributos de
calidad asociados a los casos de uso seleccionados son: QA-1, QA-2, QA-3, QA-4 y
QA-8.
Paso 3: Escoger uno o más elementos para ser refinados
El elemento para refinar es la capa de presentación.

Paso 4: Escoger uno o más conceptos de diseño para satisfacer los drivers
seleccionados
Los conceptos de diseño establecidos se muestran en la Tabla 4.29.

Tabla 4.29. Descripción de las restricciones – Iteración 2

Fuente: Elaboración propia

Decisiones de diseño y
Rationale
alojamiento
De acuerdo con la restricción CON-5, la interfaz de
monitoreo tiene que a través de un navegador web.
Esta arquitectura de referencia de tipo serverless, se
Utilizar la arquitectura de
caracteriza por estar compuesta de elementos para:
referencia para una
 Distribuir contenido estático
aplicación web serverless
 Distribuir contenido dinámico:
oVerificar consultas.
oEjecutar consultas.
Introducir elemento para De acuerdo con el escenario QA-8, es necesario tener el
autentificar y autorizar control de acceso, la inscripción y el inicio de sesión de
usuarios los
usuarios.
Uso patrón base de datos Dado que el elemento “Almacenar datos procesados”
compartida (Shared permite almacenar contenido web estático.
database)

Paso 5: Instanciar los elementos arquitecturales, asignar responsabilidades y

definir interfaces
Las decisiones de diseño se resumen en la Tabla 4.30.

Tabla 4.30. Descripción de las restricciones – Iteración 2

Fuente: Elaboración propia

Decisiones de diseño y
alojamiento Rationale
Alojar la aplicación web
(frontend) en los servicios Esta alternativa atiende a la restricción CON-2. A demás
proporcionados por la cumple con el UC-4.
arquitectura de referencia
Definir PHP, JQUERY,
HTML, CSS como
lenguajes de programación
para el contenido web
estático. Son lenguajes conocidos por el programador (CRN-2).
Definir JAVASCRIPT
como lenguaje de
programación para el
contenido dinámico.
Paso 6: Boceto de las vistas y registro de las decisiones de diseño
En la Figura 4.10 se presenta el boceto de la arquitectura teniendo en cuenta las
decisiones de diseño presentadas en la sección anterior.

Figura 4.10. Boceto de la arquitectura después de la Iteración

2 Fuente: Elaboración propia

En la Tabla 4.31, se describe la responsabilidad de cada elemento que compone la

arquitectura diseñada.

Tabla 4.31. Descripción de las restricciones – Iteración 2

Fuente: Elaboración propia

Elemento Responsabilidad
Capa de Esta capa se encarga de gestionar el contenido web y mostrar la
presentación información procesada.
Autorizar acceso Este elemento se encarga de administrar las credenciales para el
acceso de usuarios a la plataforma web.
Distribuir contenido Este elemento se encarga de gestionar la distribución del
estático contenido estático de la plataforma web.
Verificar consultas Este elemento administra las solicitudes que pueden realizar los
usuarios dentro de la plataforma web.
Ejecutar consultas Este elemento gestionar las consultas a base de datos.
Paso 7: Realizar el análisis del diseño actual, revisar el objetivo de la iteración y
el logro del propósito del diseño
En la Tabla 4.32, se muestra el resumen del proceso de diseño y las decisiones
hechas durante la iteración. Los drivers que han sido completamente realizados en la
iteración anterior no serán mostrados.

Tabla 4.32. Tablero Kanban – Iteración

2 Fuente: Elaboración propia
No Parcialmente Completamente Decisiones de diseño durante la
realizado realizado realizado iteración
UC-1 Estos casos de uso han omitidos en
UC-2 esta iteración porque no son
UC-3 considerados como primarios.
Seleccionar una arquitectura de
UC-4 referencia para una aplicación web
serverless.
UC-5 Estos casos de uso han sido omitidos
UC-6 en esta iteración porque no son
UC-7 considerados como primarios.
QA-1 No se han tomado decisiones.
QA-2 El detalle de los elementos que
QA-3 cumplen con estos atributos de
QA-4 calidad aún no ha sido definido.
QA-8 No se han tomado decisiones.
Seleccionar una arquitectura de tipo
CON-2
serverless.
El detalle del elemento que atiende
CON-4 esta preocupación aún no ha sido
definido.
Seleccionar la arquitectura para una
CON-5
aplicación web serverless.
Programar el contenido estático y
dinámico de la página web con
CRN-2
lenguajes conocidos por el
programador.
CRN-3 No se han tomado decisiones.
4.5.2.4. Iteración 3: Selección de las tecnologías

Paso 2: Establecer el objetivo de la iteración por medio de la selección de drivers

El objetivo de esta iteración es atender la preocupación arquitectura CRN-3,
detallando todos los elementos que componen a las capas de la arquitectura
diseñada.

Paso 3: Escoger uno o más elementos para ser refinados

Las arquitecturas de referencia seleccionadas en las anteriores iteraciones fueron
descompuestas en elementos que facilitan la selección de las tecnologías.

Paso 4: Escoger uno o más conceptos de diseño para satisfacer los drivers
seleccionados
En esta iteración los conceptos de diseño son.
Tabla 4.33. Decisiones de diseño – Iteración 3
Fuente: Elaboración propia
Decisiones de diseño y
alojamiento Rationale

Una arquitectura basada en eventos permite usar el modelo

Implementar el patrón
arquitectural basado en
eventos.
pub/sub.
 Publishers: son los remitentes de mensajes, los que
generan los eventos (estaciones de monitoreo).
 Subscribers: son los que reciben los mensajes y responden
al Publisher. (Sistema ciber).
 Modelo Pub/sub: la infraestructura de mensajería (capa de
recolección) mantiene un seguimiento de las suscripciones.
Cuando se publica un evento, se envía el evento a cada
subscriber, este se encarga de canalizarlo hacia otras capas.
Para cada estación de monitoreo se debe crear un subscriber,
para recibir los siguientes topics: temperatura, flujo, presión
y ruido acústico.

Implementar el patrón de Debido a que el elemento de “Almacenar datos en crudo” se

data compartida (Shared guarda la información obtenida de las estaciones.
database) en una base de
datos no-SQL.
Implementar el patrón
Solución para el problema del volumen, ya que se centra en
MapReduce para el
el procesamiento distribuido y paralelo de gran cantidad de
procesamiento de analítica
datos estáticos. Se caracteriza por ser tolerante antes fallos
batch.
(UC-7).
Paso 5: Instanciar los elementos arquitecturales, asignar responsabilidades y
definir interfaces
Los elementos arquitecturales son componentes externos desarrollados por AWS. En
la Tabla 4.34, se describe cada componente seleccionado.

Tabla 4.34. Descripción de las restricciones – Iteración 3

Fuente: Elaboración propia

Decisiones de diseño y
alojamiento Rationale
Este servicio hace posible la comunicación bidireccional y
segura entre dispositivos conectados a Internet y a la nube de
AWS a través de MQTT. Se compone de los siguientes
elementos:
 Seguridad e identidad: usa el estándar de seguridad “TLS
1.2”. Con certificados X.509 cada dispositivo se
autentifica a la contraparte con que se está comunicando
(AWS IoT) e intercambia una llave para mantener una
sesión activa. De esta manera se garantiza la confiabilidad
de dato/mensaje.
 IoT Topic: es el agente de mensajes, proporciona un
Seleccionar AWS IoT
mecanismo seguro para que los dispositivos y las
como elemento principal
aplicaciones de AWS IoT publiquen y reciban mensajes
de la capa de recolección
entre sí. Ejemplo de topic:
- estacionX/tipo_de_sensor
Cada estación de monitoreo enviará datos a un
determinado topic.
 IoT Rule: es el motor de reglas, proporciona funciones de
procesamiento de mensajes y de integración con otros
servicios de AWS. Puede utilizar un lenguaje basado en
SQL para seleccionar datos de cargas de mensajes,
procesar y enviar datos a otros servicios, como Amazon
DynamoDB. También puede utilizar el agente de mensajes
para volver a publicar mensajes para otros suscriptores.
El escalamiento de este servicio es de manera automática [45].
Es una base de datos no relacional que ofrece rendimiento
fiable a cualquier escala. Este servicio completamente
Seleccionar Amazon
administrado incluye muchas características para ayudar a
DynamoDB para
los desarrolladores a crear un almacén de datos escalable a
almacenar datos en
nivel mundial para aplicaciones que necesiten acceso a datos
‘crudo’
con un nivel de respuesta alto [46].
Es un servicio de almacenamiento de objetos creado para
almacenar y recuperar cualquier volumen de datos desde
Seleccionar Amazon S3
cualquier ubicación: sitios web y aplicaciones móviles,
para almacenar datos
aplicaciones corporativas y datos de sensores o dispositivos
procesados
von IoT. Está diseñado para ofrecer una durabilidad del 99,
999999999% [47].
Proporciona un marco Hadoop administrado que permite
Seleccionar Amazon EMR procesar enormes volúmenes de datos de manera sencilla,
para ejecutar MapReduce ágil y rentable en instancias de Amazon EC2 cuya escala
puede ajustarse de manera dinámica [48].
Permite incorporar el control de acceso, la inscripción y el
Seleccionar Amazon inicio de sesión de los usuarios a aplicaciones web. El
Cognito para autorizar escalado de Amazon Cognito le permite admitir millones de
acceso usuarios e iniciar sesión tanto mediante proveedores de
identidad empresarial a través de SAML 2.0 [49].
 Tabla 4.34. Descripción de las restricciones – Iteración 3 (Continuación)
Fuente: Elaboración propia
Decisiones de diseño y
alojamiento Rationale
Es un servicio rápido de red de entrega de contenido (CDN)
Seleccionar Amazon
como datos, vídeos, aplicaciones de forma segura, con baja
CloudFront para distribuir
latencia, altas velocidades de transferencia. Entorno fácil
el contenido estático
para
desarrolladores [50].
Es un servicio completamente administrado, administra todas
las tareas involucradas en la aceptación y el procesamiento
Seleccionar Amazon API
de hasta cientos de miles de llamadas de API simultáneas,
Gateway para verificar
entre ellas, la administración del tráfico, el control de
consultas
autorizaciones y acceso, el monitoreo y la administración de
la versión de API [51].
Es un servicio que ejecuta código (en una infraestructura
Seleccionar AWS Lambda informática de alta disponibilidad) en respuesta a eventos y
para ejecutar consultas administra automáticamente los recursos informáticos
subyacente [52].
Este servicio ofrece datos e información procesable para
Seleccionar Amazon monitorear sus aplicaciones, comprender cambios de
CloudWatch para rendimiento que afectan a todo el sistema y tomar acciones,
monitorear servicios optimizar el uso de recursos y lograr una vista unificada del
estado de las operaciones [53].

Paso 6: Boceto de las vistas y registro de las decisiones de diseño

En la Figura 4.11, se muestra la vista física de la arquitectura diseñada.

Figura 4.11. Vista física de la arquitectura diseñada

Fuente: Elaboración propia
Paso 7: Realizar el análisis del diseño actual, revisar el objetivo de la iteración
y el logro del propósito del diseño
En la Tabla 4.34, se muestra el resumen del proceso de diseño y las decisiones
hechas durante la iteración. Los drivers que han sido completamente realizados en la
iteración anterior no serán mostrados.

Tabla 4.34. Tablero Kanban – Iteración

3 Fuente: Elaboración propia
No Parcialmente Completamente Decisiones de diseño durante la
realizado realizado realizado iteración
Seleccionar las tecnologías de los
UC-1 elementos de la capa de ingesta y
analítica de datos.
Seleccionar servicios totalmente
UC-2 administrados por AWS.
Seleccionar el servicio de Amazon
UC-3
CloudWatch.
Seleccionar las tecnologías de los
UC-4 elementos de la capa de presentación.
Seleccionar el servicio de Amazon
EMR, y e implementar el patrón
UC-5
MapReduce para el procesamiento de
analítica batch.
Seleccionar el servicio de Amazon
UC-6 CloudWatch.
UC-7 No se han tomado decisiones.
QA-1
QA-2 Seleccionar servicios totalmente
QA-3 administrados por AWS.
QA-4
Seleccionar el servicio de Amazon
QA-7
CloudWatch.
Seleccionar el servicio de Amazon
QA-8 Cognito para administrar credenciales
de acceso a la plataforma web.
Seleccionar el servicio de AWS IoT
CON-4 para gestionar la comunicación con los
dispositivos.
Describir cada uno de los servicios de
CRN-3 la arquitectura diseñada.