Brambilla et al.

Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14

Diario de Servicios de Internet
DOI 10.1186 / s13174-017-0064-1
y Aplicaciones

INVESTIGACIÓN Acceso abierto

desarrollo basada en modelos de usuario

interfaces para sistemas de IO a través de componentes específicos
de dominio y los patrones
*
Marco Brambilla 1 , Eric Umuhoza 1 y Roberto Acerbis 2

Abstracto

Internet de las tecnologías y aplicaciones de las cosas están evolucionando y ganando tracción continua en todos los ámbitos y entornos, incluyendo casas, ciudades, los
servicios, la industria y las empresas comerciales. Sin embargo, todavía quedan muchos problemas que deben abordarse. Por ejemplo, la visión de la IO se centra
principalmente en el aspecto tecnológico y la infraestructura, y sobre la gestión y el análisis de la enorme cantidad de datos generados, mientras que hasta ahora el desarrollo
de interfaces de front-end y de usuario para la IO no ha jugado un papel relevante en la investigación. Por el contrario, las interfaces de usuario pueden jugar un papel clave en
la aceptación de las soluciones de la IO por adoptadores finales. En este trabajo se discuten los requisitos y escenarios de uso cubren los aspectos de extremo delantero de
sistemas de IO y se presenta un enfoque basado en modelos para el diseño de tales interfaces por: la definición de componentes específicos y patrones de diseño utilizando
un lenguaje de modelado visual para las aplicaciones de la IO; que describe una implementación de la solución que comprende también la generación automática de código a
partir de modelos; y por que muestra la solución en el trabajo.

palabras clave: Internet de las cosas, de desarrollo basada en modelos, la interacción del usuario, patrones de diseño, aplicaciones móviles, el modelado, la
experiencia del usuario, ingeniería de software, IFML

1. Introducción
La interacción del usuario juega un papel crucial en una gran clase de
mercancías y sistemas blandas. Esto es cierto también para la Internet de los
sistemas de objetos (IO), aunque este aspecto ha sido descuidado fre-
cuentemente. De hecho, la corriente de visión IO se centra principalmente en el
aspecto tecnológico y de infraestructura, y sobre la gestión y el análisis de la
enorme cantidad de datos generados [13]. Hasta el momento, el desarrollo del
front-end de las aplicaciones de la IO e interfaces de usuario para la IO ha sido
cubierto por un conjunto muy limitado de la investigación [46]. En el otro lado, una
gran cantidad de investigación se ha centrado en escenarios relacionados con el
uso industrial de la IO (IIoT) [7, 8], y de máquina a máquina (o sensor a sensor)
comu- nicación [9-11 ]. Iniciativas como Internet Consorcio Industrial (CII) 1 demostrar usuario y los patrones de diseño de la IO-específica. En particular, nos centramos en
esta tendencia y la toma de conciencia de ING en crecimiento- de la importancia
de esto dentro de las em presas com-. Sin embargo, la IO ha ido mucho más allá
del contexto planta industrial: la IO es (y será cada vez más ser) una parte de
la vida cotidiana de los consumidores también. Por lo tanto, tal y como ha sucedido en
otros campos como la Web, móviles y portátiles, interfaces de usuario en el ecosistema
de la IO desempeñarán cada vez más un papel clave en la aceptación de los usuarios
finales. De hecho, las cosas inteligentes conectados entre sí por el paradigma de la IO
pueden cooperar e intercambiar información, pero su objetivo final es proporcionar valor
a la perso- PLE. Dicho valor puede ser percibido sólo a través de apro- comió interfaces
de usuario, que visualizan información (a través del tablero de instrumentos, informes, o
la infografía), permitir al usuario navegar por la información, y también interactúan con
los dispositivos, estableciendo las propiedades o la regulación de su comportamiento.
En este artículo se propone un enfoque basado en modelos para el diseño de
interfaces de usuario de sistemas de IO, por defin- ing componentes de interfaz de
las siguientes preguntas de investigación, redactadas como objetivos de investigación:

• RQ1: Definir los principales conceptos de dominio específico para los casos de uso
típicos de la IO y;
* Correspondencia: marco.brambilla@polimi.it • PI2: Definir un (visual) lenguaje de modelado para el desarrollo de los
1 Politécnico de Milán. Dipartimento di Elettronica, Informazione e Bioingegneria, Piazza L.

Da Vinci 32, 20133 Milán, Italia Lista completa de información sobre el autor está aspectos de la interacción de usuario de las aplicaciones de la IO;
disponible al final del artículo

© El Autor (s). 2017 Acceso abierto En este artículo se distribuye bajo los términos de la licencia 4.0 de Creative Commons Reconocimiento Internacional
(http://creativecommons.org/licenses/by/4.0/), que permite el uso ilimitado, distribución y reproducción en cualquier medio, siempre que se dará información al autor
(s) original y la fuente, proporcionar un enlace a la licencia Creative Commons, e indicar si se han realizado cambios.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
• PI3: Definir un conjunto de prácticas de diseño que aumentan la productividad y
simplifica el diseño de los extremos delanteros de la IO;
• PI4: Implementar herramientas impulsada modelo que cubren las fases
de diseño, despliegue y ejecución de aplicaciones de IO.
En el resto del documento, abordamos estas preguntas mediante la
definición de soluciones y demostrar la viabilidad de los enfoques propuestos
con ejemplos y casos de uso. En particular, las soluciones que proponemos
se centran en la ampliación de la lengua IFML norma adoptada por el Objeto
Hombre- Grupo agement (OMG) [12], junto con las directrices metodológica y
soporte de herramientas para su implementación. Por ello, la investigación ha
abordado los siguientes aspectos:
1. Estudio de la IO dominio, adopción y sus aplicaciones actuales
(respondiendo a RQ1);
2. Extracción de casos de uso común para la IO (respon- diendo a RQ1). Los casos
de uso identificados durante esta fase incluyen: gestión de dispositivos, la
detección de dispositivos (o de búsqueda), la interacción con los dispositivos, y
la recogida de información de los dispositivos;
3. Definición de un conjunto de nuevos componentes IFML que permite el modelado de las
interacciones de los usuarios de la IO (respondiendo a RQ2);
4. Definición de un conjunto de patrones de diseño reutilizables (respondiendo
a RQ3);
5. Aplicación de la solución propuesta como una plataforma de gestión de la
IO, las herramientas de diseño y código ators gene- (respondiendo a PI4).
El trabajo se organiza de la siguiente manera: la sección 2 se analiza el
fondo de la lengua IFML; Sección 3 muestra los casos de uso común de los
sistemas de IO; La sección 4 presenta las extensiones a IFML adaptado a
aplica- ciones basadas en la IO; Sección 5 presenta patrones de diseño
para el eling mo- de las interacciones del usuario con sistemas de IO;
Sección 6 muestra un ejemplo; Sección 7 resume nuestra tación aplica-;
Sección 8 describen tres casos industriales donde el enfoque ha sido
aplicado y validar las ventajas de la solución; Sección 9 comentarios el
trabajo conexas; y la Sección 10 concluye.
2 Antecedentes sobre IFML
La interacción Flow Modeling Language (IFML) está diseñado para
expresar el comportamiento de contenido, la interacción del usuario y el
control del front-end de aplicaciones de software. Su metamodelo utiliza
los tipos de datos básicos del metamodelo UML, se especializa varios
metaclases UML como base para metaclases IFML, y presume que el
modelo de dominio IFML está representado en UML. Un modelo IFML
apoya el siguiente diseño perspectivas: (i) La Ver especificación de
estructura, que consiste en la definición de vista de contenedores, sus
rela- ciones de anidación, su visibilidad, y su accesibilidad; (Ii) La
ver especificación de contenido, que consiste en la definición
Página 2 de 21
de ViewComponents, es decir, el contenido y de entrada de datos ele- mentos
contenidos dentro de ViewContainers; ( iii) La
especificación de eventos, que consiste en la definición de
Eventos que pueden afectar el estado de la interfaz de usuario.
Eventos puede ser producido por la interacción del usuario, por la
aplicación, o por un sistema externo; (Iv) La especificación transición
evento, que consiste en la definición del efecto de una Evento en la
interfaz de usuario; (V) La parámetro de especificación de unión, que
consiste en la definición de las dependencias de entrada-salida entre
ViewComponents y entre ViewComponents
y Comportamiento; y (vi) La referencia a Comportamiento desencadenado por los
eventos del usuario. El efecto de una Evento
está representado por una InteractionFlow conexión, que conecta el
evento a la ViewContainer
o ViewComponent afectado por la Evento. los
InteractionFlow expresa un cambio de estado de la interfaz de usuario: la
ocurrencia del evento causa una transición de estado que produce un cambio en
la interfaz de usuario. La figura 1 muestra un ejemplo sencillo de modelo IFML,
que describe una interfaz de usuario donde el usuario puede buscar un producto
mediante la introducción de algunos criterios de búsqueda en la forma de
producto de búsqueda. El modelo consiste en una ViewContainer
productos ( que describe una pantalla o página web), que con- tiene dos (ViewComponents
widgets de visuales posicionado en la pantalla), a saber, la Búsqueda de Producto Formar,
donde el usuario puede introducir los criterios de búsqueda y la ProductRe- sultList
Lista, que muestra los resultados de búsqueda. ULTERIORES más, una La
eliminación del producto Acción puede ser activado cuando el usuario selecciona
la Borrar Evento asociado a TResultList productividad. Este modelo ejemplo se
ajusta a la metamodelo IFML, un extracto de cual se muestra en la Fig. 2.
2.1 móvil IFML
diseño de la parte frontal es una tarea más compleja en aplica- ciones
móviles debido principalmente a: (i) la pequeñez de las pantallas de los
dispositivos móviles. Esta restricción requiere un esfuerzo extra en el
diseño de interacción en el fin de explotar al mejor el limitado espacio
disponible; (Ii) Las aplicaciones móviles interactúan con otras
características de software y hardware instalados en el dispositivo que se
están ejecutando en; y (iii) la interacción con el usuario, que básicamente
se realiza mediante la realización de gestos precisos en la pantalla o
mediante la interacción con otros sensores. Estas interacciones menudo
dependen del dispositivo, el sistema operativo y la aplicación en sí. Esta
sección presenta una extensión móvil de IFML diseñado para expresar el
contenido, la interacción del usuario, y controlar el comportamiento de la
front-end de aplicaciones móviles [13]. Un extracto de esas extensiones,
2.1.1 Contenedores y componentes
Esta sección presenta los conceptos añadido a IFML con el fin tomodel
los envases y componentes que caracterizan
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 3 de 21

Figura 1 IFML ejemplo: búsqueda de productos, lista y eliminación. Themodel consiste en una ViewContainer productos el cual contiene dos ViewComponents
( Búsqueda de Producto forma y ProductResultList lista); y La eliminación del producto Acción desencadenada una vez que el usuario selecciona el Borrar Evento asociado a

ProductResultList

el contexto móvil. Una nueva clase llamada Pantalla ha sido definido para Un rasgo característico de interfaces móviles es el lización uti- de
representar la pantalla de una aplicación móvil. Desde la pantalla es el predefinido ViewContainers dedicado a las funcionalidades específicas
que se proporcionan en el sistema oper- ating (incluyendo Notificaciones área
contenedor principal de una aplica- ción móvil, que extiende la clase núcleo ViewContainer
de la norma IFML. La clase Barra de herramientas representa un y ajustes
DETERMINADO sub-recipiente de la pantalla. Puede contener otros panel). Estos contenedores a nivel de sistema proporcionan econo- mía de
contenedores y puede tener en su límite una lista de eventos. Se extiende la espacio y hacer cumplir un uso consistente de características mon com-.
clase núcleo ViewContainer de la norma IFML. La clase MobileComponent denota los MobileSystem estereotipo se ha definido para distinguir estos especial ViewContainers.
el componente de vista lar móvil particu- tales como el botón, la imagen, y el
icono. UN MobileComponent está sujeta a los eventos de usuario, que se UN ViewContainer estereotipado como MobileSystem
describen a continuación. denota una región fija de la interfaz, gestionado por el sistema operativo
móvil o por otro marco de interfaz de una manera entre aplicaciones. los MobileSystem
estereotipo se puede aplicar también a una ViewComponents a más
destacado

Figura 2 extracto IFML Metamodel que muestra la flujo de interacción elementos del lenguaje
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
Fig. 3 Metamodelo que representa las extensiones móviles y la IO de IFML
que la interfaz utiliza los componentes del sistema (como se muestra en la Fig.
5).
2.1.2 contexto móvil
El contexto es un aspecto de tiempo de ejecución del sistema que de-
termina la forma en la interfaz de usuario debe ser configurado y el
contenido que se puede mostrar. El contexto asume una particular
relevancia en las aplicaciones móviles, que deben explotar toda la
información disponible para ofrecer la interfaz más eficiente. Por lo tanto, el
contexto debe reunir todas las dimensiones que caracterizan a la intención
del usuario, la capacidad del dispositivo de acceso y de la red de
comunicación, y el entorno que rodea al usuario. Una nueva clase MobileContext
extender el Contexto ha sido definido para expresar las características
contextuales móviles.
2.1.3 Eventos
En esta sección se describen los nuevos tipos de eventos que están
correspondientes a la foto tomada en su caso. Una vez que la foto está
definidos dentro de IFML para el contexto móvil. Una nueva clase MobileUserEvent
permitiendo que el ing modelo- de los eventos de usuario móviles se han
definido.
MobileUserEvent se extiende ViewElementEvent del IFML. los MobileUserEvent asociada a la
se extiende además a un modelo de los eventos de usuario móviles
específicos. Sus extensiones específicas incluyen: Arrastrar y soltar, DoubleTap,CameraAction disparar.
tacto,
y Pulsación larga. Cada uno de ellos representa un evento relacionado con
el gesto que lo activa.
Las pantallas de la Fig. 4a muestran un ejemplo de la utilización de la Pulsación su aplicaciones de IO. Antes de proceder con las especificaciones de casos de uso,
larga gesto que permite al usuario gestionar la lista seleccionada. La figura 4b
muestra un fragmento de modelo IFML para la gestión de listas. Cuando un
usuario realiza la
Pulsación larga gesto en un elemento de la lista, un pop-up que contiene la
información del elemento seleccionado se muestra lo que le permite editar o
borrar la lista. Una nueva clase MobileSystemEvent ha sido definido para
expresar los eventos del sistema móvil. se extiende
SystemEvent del IFML. Las siguientes clases se extienden
MobileSystemEvent para eventos específicos del sistema:
Página 4 de 21
• SensorEvent, la definición de eventos relacionados con los sensores del dispositivo;
• BatteryEvent, que describe los eventos relacionados con el estado de la
batería;
• NotificationEvent, la agrupación de los eventos relacionados con las
notificaciones genéricas manejados por el sistema operativo;
• StorageEvent, que describe los eventos relacionados con la capacidad de
archivado; y
• ConnectionEvent, que describe los eventos relacionados con el estado de
conexión del dispositivo.
MobileActionEvent clase ha sido definida para modelar los
acontecimientos desencadenados por una acción móvil. Entre las
acciones móviles, tenemos acciones relacionadas con la cámara de fotos
como la Disparar acción y acciones relacionadas con micrófono. La Figura
5 muestra un ejemplo de tales eventos. Un usuario toma una foto con la
era cam- foto del dispositivo y la aplicación muestra el producto
disponible, una pantalla preguntando al usuario si quiere usar o volver a
tomar se muestra la foto. los foto disponibles CameraActionEvent está
3 Los casos de uso
En esta sección se presentan los principales casos de uso que las identificadas para
ofrecemos un breve resumen de la terminología utilizada en la IO el papel. En
particular, vamos a hacer uso de los siguientes conceptos de la IO:
• Dispositivo o cosa: Denota todos los tipos de dispositivos que pueden
generar información (sobre evento físico o estado) e iniciar, modificar o
mantener esos acontecimientos o estados; o que pueden realizar
acciones.
• Categoría: Los dispositivos de la IO se pueden agrupar en dife- rentes categorías
en base a algún criterio, como el tipo, características y ubicación
geográfica.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 5 de 21

un

segundo

Fig. 4 Ejemplo de Pulsación larga evento se usa para mostrar las opciones de una lista presionado: un la interfaz de usuario que representa el gesto realizado; segundo el modelo IFML correspondiente

• Terminal: Un terminal es cualquier dispositivo que puede ejecutar una
aplicación IO con una interfaz de usuario que puede controlar otros
dispositivos a través de la red.
• Comunicación: Los dispositivos pueden comunicarse de diferentes
maneras y se puede conectar con los terminales y los sistemas
externos. Varios de comunicación proto se han propuesto para la IO
cols alrededor del IEEE
802.15.X estándar.
• Sistema externo: Con sistema externo nos referimos a todos los
sistemas conectados a una red en la que la información de
dispositivos y terminales puede ser almacenada, procesada y
recuperados. Ejemplos de la externa
sistemas incluyen sistemas de gestión empresarial como la gestión de
relaciones con clientes (CRM) y la planificación de recursos
empresariales (ERP).
• Intermediario: Representa cualquier dispositivo o sistema que actúa como
una puerta de enlace entre el dispositivo de la IO y el terminal en una
comunicación indirecta. Los casos de uso que hemos identificado para las
aplicaciones de la IO se basan en nuestras experiencias industriales, así como
en una amplia investigación sobre las aplicaciones de la IO disponibles en el
mercado y lo que se espera que sea la interfase de usuario de las aplicaciones
de la IO en diferentes áreas de su aplicación .

Fig. 5 Ejemplo de uso de MobileAction ( Disparar), MobileActionEvent ( Foto disponible) y MobileSystem estereotipo
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
En particular, nos basamos en la experiencia directa de los escenarios en los
campos de la construcción de monitoreo (con sensores y actuadores que
controlan el estado de los grandes recintos utilizados para eventos públicos), las
ciudades inteligentes (que cubren las necesidades de seguimiento de flujo de
personas, incluyendo peatones y vehículos, la disponibilidad de estacionamiento y
transporte público), ING mercado y el monitoreo de ventas (para el control de las
interacciones con los escaparates de las tiendas y artefactos), y el sensor masiva
Desplegar ción de bienes comerciales para el mantenimiento adaptativo (grandes
electrodomésticos). Además, investigamos los usos po- sible de los productos de
la IO equipados para el mercado de consumo, producida por los vendedores
famosos (Philips, Bticino, Vimar, y otros). Fuera de este análisis se derivó un
conjunto de casos de uso abstractos que cubren todos estos escenarios.
Presentamos los casos de uso utilizando el siguiente esquema: descripción, el
actor principal, y
tareas principales. La lista detallada de los casos de uso se presenta en la Tabla 1.
El usuario de la aplicación IO podría tener papeles dife- rentes, definidos
como un conjunto de acciones permitidas. Las funciones principales son: Administrador, empresa.
el usuario que tiene derechos de acceso a todo el sistema, incluyendo los
siste- mas externos; Ejecutante, el usuario que puede gestionar y actuar
interacción con los dispositivos de la red local; y Espectador,
el usuario que puede mostrar la información de los dispositivos o la información
sobre el entorno monitorizado por esos dispositivos. Los casos de uso
indicados en la Tabla 1 cubren esencialmente dispositivo y gestión de usuarios,
la IO uso de dispositivos, y gestión de datos. Los casos de uso identificados
son: Configurar acceso y permiso, Gestión de dispositivos, interactuar con los
dispositivos, Manejo de esperar la señal, dispositivos de búsqueda, Administrar
notificaciones, Obtener información de los dispositivos, información visualizar,
compartir información, de almacenes de información, recuperar la información
almacenada. Su caracterización detallada reportado en la Tabla 1 responde a RQ1.
4 lenguaje de modelado de la IO
En esta sección nos dirigimos a la especificación de un lenguaje de dominio específico para el
diseño de interfaz de usuario de la IO, respondiendo así a
PI2. . Las interacciones entre el usuario y los siste- mas de IO, como se muestra
en la figura 6, se pueden dividir lógicamente en dos fases: (i) Usuario
Terminal comunicación. Esta
fase representa las interacciones entre el usuario y el terminal utilizado
para acceder al sistema IO; y (ii)
Terminal IoTdevices comunicación. Esta repre- fase
resiente las interacciones entre el terminal y los dispositivos IO. La primera
fase puede ser modelado utilizando el estándar IFML y sus extensiones,
especialmente el IFML móvil (introducido en la Sección 2.1). Esta sección
se refiere a la segunda fase de las interacciones con tem la IO sis-.
Presenta los nuevos elementos añadidos a la IFML para modelar tanto la eventos•
y comportamiento asociada a los dispositivos de la IO.
Página 6 de 21
4.1 Modelo de contenido
En esta sección se presenta el modelo de contenido de un sistema de la IO. El
modelo diseñado cubre los casos de uso que se presentan en la Sección 3, con un
multi-inquilino y perspectiva de la empresa. De hecho, los casos de uso descritos
hasta ahora representan la pers- pectiva de un único sistema IO. En base a esto,
ahora apuntamos a una plataforma que soporta múltiples sistemas de IO dentro y
fuera de las empresas. Por lo tanto, el modelo propuesto permite definir una
infraestructura única para una plataforma de aplicaciones múltiples usuarios que
pueden servir a varios clientes al mismo tiempo.
La Figura 7 muestra una pieza de modelo de contenido. El modelo
comprende los conceptos necesarios para el modelado de los usuarios de la
aplicación y la estructura de una organización y sus clientes y los conceptos
necesarios para definir los servicios de la IO.
• Usuario, que representa al usuario físico que acceder a la aplicación. El
usuario puede ser o bien una CustomerUser
o una OrganizationUser refiriéndose respectivamente a una al cliente central o una
• Inquilino, este concepto define un dominio de acceso, ya sea para una
organización o un cliente. El inquilino se caracteriza por sus propias
configuraciones y diseño cal gráficamente. Es la principal condición de
partición para los datos.
• Organización, que describe una empresa que ofrece un ser- vicio al
cliente. La organización produce y vende Cosas gestionado por la
aplicación. La organización pertenece a un inquilino u otra
organización.
• Cliente, Este concepto describe una empresa que ya sea comprado
o utiliza el servicio de la organización. El cliente tiene una referencia
a las organizaciones que venden el Cosas o proporciona asistencia
técnica.
• Rama, que representa una unidad de organización sub pertenen- ing a un
cliente.
• Ubicación, que representa un lugar físico propiedad de un cliente. La
ubicación es el lugar donde se ha instalado una cosa (por ejemplo, oficina,
tienda, y la planta).
• Cosa, este concepto representa un objeto genérico CONECTADOS a
Internet, capaz de enviar y recibir datos. Las características de una
cosa se definen por la correspon- diente ThingDefinition y se une a
una específica
Ubicación.
• ThingDefinition, que representa la definición de una cosa. Describe
la expuesta Métrica y el Apoyado Mando.
• Mando, que representa una instrucción que puede ser ejecutado por una
cosa. Un comando tiene un nombre y un conjunto de CommandParameter
caracterizado por un nombre y un tipo.
Métrico, este concepto representa una carac- ca- observable de una
cosa. Puede ser una medida física (por ejemplo, temperatura) o un valor
de una variable interna (por ejemplo, número de copias y de horas de
trabajo). Una métrica
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 7 de 21

tabla 1 IO casos de uso Caso de

uso Descripción Actor Tareas principales

Configurar el acceso Permite que el propietario de la aplicación o el administrador, para Administrador

• Gestión de usuarios, equipos y funciones
y permisos establecer los derechos de acceso para los usuarios, equipos o
• configuración de acceso
funciones.
• de configuración de permisos
• visualizar la información

Interactuar con los Permite al usuario enviar un conjunto de operaciones de los espectador
• Enviar operaciones
dispositivos dispositivos, que se encargan de llevarlas a cabo. intérprete
• Manejo de rutinas
administrador

administrar Permite al usuario tomanage y configurar los dispositivos Administrador

• Incluir dispositivos en el sistema
los dispositivos que pertenecen al sistema.
• Retire los dispositivos de sistema de
• Administrar categorías
• Incluir dispositivos a categorías
• Asignar una ubicación

Manejo de espera Permite al usuario conectar el terminal a la red y espectador

• Activar la espera de la señal
para la señal empezar a escuchar a los dispositivos de la red. intérprete
• Desactivar la espera de la señal
administrador

Manejo de Permite al usuario recibir las notificaciones procedentes de espectador

• visualizar la notificación
notificaciones diferentes dispositivos directamente o a través de un sistema intérprete
• Guardar la notificación
externo. administrador
• eliminar la notificación

dispositivos Permite al usuario buscar dispositivos que ya están espectador

• Buscar un dispositivo específico
de búsqueda registrados en el sistema, perteneciente a la local o con intérprete
• Buscar dispositivos por categoría
redes externas. administrador
• Buscar dispositivos por criterios

Almacenar Define cómo el sistema puede almacenar la información Administrador

• Almacenar localmente la información
información recogida por los diferentes dispositivos sobre el medio ambiente
• Almacenar la información de forma externa
o el estado de los dispositivos.
• Almacenar en un dispositivo de la información

Recuperar la Permite al usuario recuperar información almacenada espectador

• recuperación de información local
información almacenada en el terminal o en un sistema externo. intérprete
• recuperación de información externa
administrador

Obtener información de Permite al usuario solicitar información a los espectador

• Obtener información de los dispositivos asociados a la
los dispositivos dispositivos de la red. intérprete
administrador
solicitud
• Obtener información de los dispositivos asociados a la
sistema externo
• Obtener información de los dispositivos de la misma
red

visualizar la Permitir al usuario visualizar la información relacionada con o espectador

• La información en pantalla
información producidos por dispositivos de diferentes maneras. intérprete
administrador

Compartir Permitir al usuario compartir información a través de un canal espectador

• Compartir información
información de comunicación con otros usuarios o sistemas. intérprete
administrador

se caracteriza por un nombre, una unidad de medición, y un tipo (por
ejemplo, entero, flotante, y boolean).
• Medida, que representa un valor de un indicador en una fecha y hora específica. Un
conjunto de medidas que constituye la serie de tiempo. Cosas sendmeasures al
sistema de ejecución de servidor a intervalos regulares o cuando se producen
eventos particulares.
4.2 Interactionmodel
En esta sección se presentan los nuevos componentes que permiten hacer referencia
a los conceptos de la IO durante el ing modelo- de la interfaz de usuario para las
aplicaciones basadas en la IO. Estos conceptos incluyen las acciones IO-específicos y
los eventos de dispositivos IO.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
Fig. 6 Descripción general de la interacción del usuario con los sistemas de IO a través del terminal, que consiste en el envío de comandos y solicitando o seguimiento de los datos de los dispositivos de IO
(posiblemente a través de un intermediario)
4.2.1 acciones de IO
Esta categoría comprende los componentes que describen las acciones activan
cuando el usuario interactúa con los dispositivos IO dife- rentes. Esas acciones se
pueden agrupar en dos categorías: las acciones del dispositivo, que representan las
acciones enviadas directamente a los dispositivos; y las acciones de intermediación,
que representan las acciones enviadas a los dispositivos a través de una
intermediario ( un componente que gestiona la comunica- ción entre el
usuario y los dispositivos). Cada categoría puede ser descompuesto en
dos subcategorías: Conjunto
y Obtener comportamiento. Observe que el modelo de contenido se encarga de la definición de
los conceptos relacionados con la transferencia de datos,
Fig. 7 modelo de contenido que subyace un sistema IO
Página 8 de 21
mediante Métrico y Medida ( que en realidad contienen todos los metadatos sobre los
formatos de transferencia de datos, tamaño, etc.).
Establecer acciones. Esta categoría incluye las acciones que permiten al usuario
enviar a uno o más dispositivos, una serie de identificadores de las operaciones o
programas que estos dispositivos tienen que realizar o ejecutar. Suponemos que las
operaciones son conocidos a priori por los dispositivos, por lo tanto, cuando enviamos
un identificador de una operación para un determinado dispositivo, el dispositivo sabe
cómo realizar la operación correspondiente. los Conjunto las operaciones se utilizan
principalmente para configurar los dispositivos (por ejemplo: cambiar el rango en el
que los sensores están
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
activado) y para realizar acciones específicas, tales como encender y apagar el
dispositivo. Hemos definido una nueva clase,
setAction, que permite el modelado de esas acciones (véase la Fig. 3).
Obtener acciones. los Obtener Las acciones se utilizan principalmente para
recuperar la información de los dispositivos, categoría de dispositivos, un pro
Gramor un operation.We han definido una nueva clase, ción GetAc-, que permite el
modelado de esas acciones (véase la Fig. 3). La clase getAction se ha ampliado
aún más a REPRESENTA los datos específicos para recuperar. Ejemplos de esos
datos incluyen detalles y estado del dispositivo, información RESPETA por el
dispositivo y el estado de la operación asignado al dispositivo.
las acciones del Plan. Para las acciones anteriores, se supone que los
dispositivos se ejecutan las operaciones especificadas una vez que el usuario
activa la acción. Pero existen otros casos en los que el usuario desea programar
la ejecución de una acción determinada en un momento determinado. Hemos
definido una acción específica, llamada PlanAction, para modelar las operaciones
que no se ejecutan inmediatamente por los dispositivos pero sched- ULed para
la ejecución (una o varias veces) en un momento posterior. PlanAction es una
acción asincrónica que espera hasta la hora prevista para la ejecución de la
operación. Se introduce dispositivos de la selectivos, el tiempo de ejecución,
operaciones, y opcionalmente (para las acciones repetitivas u operaciones) el
número de repeticiones.
4.2.2 acontecimientos de la IO
En esta sección se describen los nuevos eventos definidos como extensión IFML
para el dominio de la IO. Esos acontecimientos se agrupan en: eventos de
dispositivos, y los eventos asociados a las acciones de la IO.
Eventos de dispositivos IO. Los dispositivos de la IO emiten señales específicas
que contienen información acerca de su estado o sobre lo que están supervisando.
Esas señales son captadas por la captura de eventos específicos y se envían a los
usuarios (terminales) en forma de notificaciones. Esos acontecimientos se agrupan
en dos categorías:
1. Individual Información del Evento. Es un evento que captura
cada mensaje desde el dispositivo que está escuchando. Una
nueva clase SingleInformationEvent ING extend- SystemEvent de la
norma IFML se ha definido para modelar esos eventos.
El uso de este evento se ejemplifica en la Fig. 8. En este ejemplo,
la información del dispositivo se muestra al usuario sólo una vez que
el terminal es CONECTADOS. Para probar la conectividad
usamos la ActivationExpression, una condición booleana que
determina si el ViewElement asociado está activo o inactivo,
asociado
Página 9 de 21
al evento. los ActivationExpression con- texto. ConnectivityType <>
“NINGUNO” establece que el
SingleInformationEvent se activará sólo cuando hay una red
activada en el terminal.
2. Evento se aproxima. Es un evento que permite capturar
la primera señal enviada por el dispositivo al que está asocia- dos. Este
evento se usa cuando los datos transmitidos por el dispositivo ha de ser
mostrados al usuario sólo una vez, es decir, cada vez que se detecta el
dispositivo por primera vez por el terminal.
Una nueva clase, ApproachingEvent, extensión
SystemEvent ha sido definido para modelar los eventos que se
aproximan. El uso de este evento es ejemplificarse en la Fig. 9. En
este ejemplo, la información del dispositivo se muestra al usuario
una vez que el usuario entra en el área de cobertura del dispositivo
de transmisión a través de Bluetooth. los ActivationExpression
"Contexto. ConnectivityType = “Bluetooth” indica que el usuario
recibe información desde el dispositivo sólo cuando la conectividad
Bluetooth está activada en su terminal.
eventos de acción. Esta categoría agrupa dos tipos de eventos:
evento de temporizador, que denota el tiempo en que está programada la acción
ado aso- para su ejecución; y Repita el caso,
especificando el tiempo en el que se repite la ejecución de la acción
ciados aso-. Hemos definido una nueva clase para cada tipo de estos
eventos: TimerEvent y
RepeatEvent.
5 patrones de interacción para la IO
En esta sección, se presentan las interacciones de la IO bajo un punto de vista
orientado a los problemas, con el objetivo de mostrar algunas soluciones ejemplares
y reutilizables a los problemas típicos, respondiendo así a PI3. Se introduce un
número de patrones que se pueden utilizar para hacer frente a los problemas típicos
en el diseño de las interacciones del usuario (UI) con el objetivo de show-ing la
expresividad de las extensiones de la IO diseñados. Mostramos la correspondencia
entre esos patrones y los patrones de interfaz de usuario se define en el contexto de
IFML [14]. También presentamos un conjunto de patrones de sincronización de
datos alternativos que pueden ser relevantes para diferentes soluciones de IO, y se
analiza su compatibilidad con los patrones de interfaz de usuario para la IO.
5.1 patrones de IO
Los patrones de diseño de interfaz de usuario para los sistemas de IO se pueden agrupar en tres
categorías: Establecer patrones, Obtener patrones, y
Modelos basados ​en eventos.
5.1.1 Establecer patrones
Esta categoría reagrupa los patrones que permiten al usuario enviar al
dispositivo un conjunto de operaciones a ejecutar.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 10 de 21

Fig. 8 Ejemplo de uso de SingleInformationEvent. Una notificación se muestra al usuario cuando se activa el evento

La Figura 10 es un ejemplo de un patrón de esta categoría, Un dispositivo una 5.1.3 patrones basados ​en eventos

operación, un patrón que permite al usuario establecer una operación para ser Esta categoría reagrupa los patrones desencadenados por una ocurrencia de una
ejecutado por un dispositivo específico. El usuario selecciona un dispositivo de serie de eventos específicos. La Figura 12 ejemplifica una tern Pat- de esta
interés a partir de una lista de los dispositivos del sistema. Luego, se elige la categoría, Tire de la Información. Este patrón permite al usuario verificar la
operación que se formó per- de una lista de operaciones apoyadas por el dispositivo disponibilidad periódicamente de nuevos datos de los dispositivos. Para ahorrar
seleccionado. algunos recursos como la energía, de los datos que pueden ser retrasada por una
cierta cantidad de tiempo sin impactar sobre el resultado de la aplicación, el usuario
Otros modelos de esta categoría son: puede decidir activar periódicamente el servicio de escucha y tirar toda la
• Un dispositivo más de las operaciones, información de los dispositivos. Otros modelos de esta categoría son Lanzamiento
• Más Dispositivos una operación, de aplicaciones
• Más dispositivos más operaciones,
• Un dispositivo de un solo programa, y y Empuje de la Información, descrito en el apéndice (Tabla 8).
• Una categoría más operaciones descritas
en el apéndice (Tabla 6). patrones de interacción del usuario 5.2

5.1.2 patrones Get
Esta categoría comprende los patrones de interacción que permiten recuperar
información de un dispositivo, categoría, programa u operación. La Figura 11 es
un ejemplo de un patrón de este CAT- goría, Obtener detalles de un dispositivo, un
patrón que permite al usuario recuperar la información general sobre el dispositivo,
como Id, nombre, descripción, y el modelo. El usuario selecciona un dispositivo
que está interesado en una lista de dispositivos. Otros modelos de esta categoría
son:
El trabajo en [14] se presenta un conjunto de patrones de diseño que se pueden utilizar para
hacer frente a los problemas típicos (relacionado con la interfaz organización, el contenido y
la navegación) de modelado de interfaz de usuario en general. Se presenta en la Tabla 2 un
subconjunto de patrones que son relevantes, como la construcción de bloques, de un
modelo de pautas de interfaz de usuario para los sistemas de IO. La Tabla 3 muestra una
correspondencia entre esos patrones de interfaz de usuario con los patrones de la IO
introducidas en la Sección 5.1. Como filas de la Tabla 3, se indican las pautas de la IO,
mientras que las columnas que tienen patrones de interfaz de usuario genéricos. Una célula
comprobado (i × j) significa que el j patrón UI XX ha sido (puede ser) utilizados para modelar

la yo patrón de la IO XX. El trabajo en [14] cubierto también las operaciones de base de

• Obtener estado del dispositivo, datos tradicionales de creación, actualización y supresión de un objeto de una entidad-dado Patrones
• Obtener información del dispositivo, CRUD. En el contexto de la IO, estos patrones se utilizan para configurar un sistema IO
• Obtener Información para una categoría, mediante la adición, actualización o eliminación de un objeto IO al repositorio de
• Búsqueda de dispositivos y

• Dispositivos cercanos

descrito en el apéndice (Tabla 7).

Fig. 9 Ejemplo de uso de ApproachingEvent. Los detalles de un dispositivo se muestran a los usuarios como la notificación una vez que entra en el área de cobertura de ese dispositivo
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 11 de 21

Sección 5, hemos modelado la interacción de casa inteligente, una aplicación

que permite al usuario interactuar con diferentes dispositivos de un sistema
de casa inteligente. El ejemplo está inspirado en un proyecto real
implementado por nuestro enfoque y reportado en la Sección 8. Figura 13a
contiene un pedazo de la interfaz de usuario de

casa inteligente solicitud. . La interfaz de usuario en la figura 13a se divide en tres caminos:
(i) Administración de cámaras. Cuando el usuario selecciona gestionar la cámara desde la

pantalla de inicio, una nueva pantalla

La Fig. 10 Ejemplo de Set Patrón: Un Dispositivo Uno Operación
cámaras Se muestra que muestra una lista de las cámaras disponibles. La pantalla
muestra imágenes en tiempo real de la cámara seleccionada. El botón detalles asociado
a cada cámara permite al usuario acceder a la imagen de alquiler Cur- detalles, el
estado y, de la cámara seleccionada; (Ii) Administración de las luces. Una vez que el
usuario selecciona Manejo de las luces desde la pantalla de inicio, una nueva
el sistema. Estos patrones no se consideran explícitamente en esta sección, ya
pantalla llamada Luces se visualiza. La pantalla
que consideran que la parte estática del sistema de la IO.

Luces, contiene una lista de las luces disponibles con su estado de alquiler Cur- ( EN o
El permiso de acceso y configuración. La seguridad es un tema clave en sistemas de
APAGADO). El usuario puede cambiar el estado de la luz seleccionada pulsando
IO. En la sección 3, se ha informado de las funciones comunes en un sistema IO. La
sobre / de botón asocia- dos a cada luz; (Iii) gestionar las alarmas. El camino que
configuración de la misión y derechos de acceso per- se realiza mediante el uso de los
permite al usuario ver los registros de las últimas alarmas. Una vez que el usuario
zuecos CRUD de usuarios, grupos y mediante la asignación de los derechos de acceso
selecciona gestionar alarma desde la pantalla de inicio, una nueva pantalla Alarmas
al grupo de usuarios. El control de acceso es entonces administrado por el Iniciar sesión y
recientes Se muestra que contiene una lista de los últimos alarmas.
Gestión de usuarios patrones (véase la Tabla 2).

La Figura 13c muestra el modelo IFML que describe la interacción del usuario de la
5.3 patrones de sincronización de datos
pieza de casa inteligente solicitud. El modelo de interacción se obtiene mediante la
Hay varios factores a considerar cuando se trata de la construcción de un modelo para
combinación de los siguientes patrones de interacción con el usuario de la IO:
describir la alineación de datos. patrones de sincronización de datos han sido
ampliamente estudiado en la informática. Se presentan los patrones que se pueden
• Obtener información de una categoría, se utiliza para recuperar el estado
aplicar en el contexto de las aplicaciones basadas en la IO en la Tabla 4, mientras que
actual de las luces controladas;
una síntesis de la compatibilidad entre los patrones y los patrones de interacción de
• Obtener estado del dispositivo, se utiliza para recuperar el estado actual de Camera01;
usuario para las aplicaciones basadas en la IO se informa en la Tabla 5. La tabla
enumera los patrones de interacción de usuario para las aplicaciones basadas en la
• Obtener información del dispositivo, Se utiliza para recuperar la
IO como filas y los datos sincronizada patrones NIZATION como columnas. Una célula
información sobre el objeto supervisado (imagen mostrada en la pantalla
marcada indica una posible coincidencia en la adopción de la correspondiente pareja
de Cámara 01);
de patrones.
• Un dispositivo una operación, utilizado por ejemplo para apagar el Light01;

• Obtener detalles de un dispositivo, utilizado para acceder a los detalles de la logline

seleccionada de las alarmas.

6 Ejemplo
Para demostrar la eficacia de que las extensiones se diseñaron y el uso de patrones
de diseño de interfaz de usuario que se presentan en
• Almacenar información, se utiliza para almacenar la nueva alarma;
• Empuje de la Información, se utiliza para informar al usuario acerca de la nueva
alarma. En el caso ejemplificado, la nueva alarma llegó (como un mensaje de
notificación) mientras el usuario estaba visualizando una lista actualizada de las
luces después de apagar el Light01.

7 Aplicación
Además de la definición formal de las extensiones de la IO a la lengua IFML y
un modelo de pautas de diseño de interfaz de usuario para la IO, nuestra
investigación incluyó la implementación de una plataforma para el desarrollo de
aplicaciones móviles y web para interactuar con los sistemas de IO, con el
objetivo de respondiendo a PI4. Esto se ha logrado en colaboración con
WebRatio 2, una empresa dedicada a las basado en modelos
La Fig. 11 Ejemplo de Get Patrón: obtener detalles de un dispositivo
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 12 de 21

La Fig. 12 Ejemplo de patrón basada en eventos: Tire Información

desarrollo de interfaces de usuario y ahora la construcción de una nueva oferta para la IO 3.
La plataforma se basa en un único modelo de datos estática de propósito
general (introducido en la Sección 4.1) que representa cualquier
infraestructura para la gestión de sistemas de IO. Nuestra tación aplica-
basó en WebRatio, un entorno de desarrollo IFML soporte que comprende
varios modelado per- perspec- e incluye un marco de generación de código
que
automatiza la producción de los componentes de software en todos los
niveles de la aplicación y la conexión entre la aplicación y APIs externas.
Desde la perspectiva arquitectónica, podemos ver la plata- forma como una
aplicación de servidor sin estado multiusuario y un conjunto de aplicaciones
de cliente de espesor. Clientes a mantener la sesión de los usuarios
autenticados y son responsables de la com- posición de la interfaz gráfica de
usuario. Sin lógica de presentación se ejecuta en el servidor. El backend
sirve de datos, ya sea en la moda tirar o empujar, y ejecuta la lógica de
negocio.

Tabla 2 Usuario patrones de interacción Pattern

Descripción

detalles principales y Presentar algunos artículos y una selección permite al

múltiples detalles usuario acceder a los detalles de un caso a la vez. 7.1 backend
La arquitectura de servicios de fondo está compuesta por los siguientes componentes:

Multi-nivel de detalles También se llama en cascada índice, se compone de una

Master secuencia de listas de más de clases distintas, de manera que
cada lista especifica un cambio de selección de un objeto,
seleccionado de entre el índice, para el conjunto de objetos
relacionados con ella a través de un papel asociación. Al final, se
muestra un solo objeto.
capa microservicios y puerta de enlace API.
capa 7.1.1 microservicios
La capa microservicios proporciona acceso a los datos. A microService es
un sistema de software independientemente de despliegue autónomo, que
proporciona una funcionalidad específica y atómico. Los micro-servicios

selección por defecto Simula la elección de un usuario en el acceso inicial de una lista,
presentes en nuestra tecture archi- incluyen: (i) Identidad, que proporciona
seleccionando así una instancia predeterminada. información para la gestión de usuarios; (Ii) Red, que agrupa los conceptos
relacionados con la estructura organizativa de los actores; (Iii) Inventario, que
forma de varios campos Formulario para la presentación de información a través de
varios campos. agrupa los conceptos relacionados con la definición de las cosas; (Iv) Datos, que
permite a los clientes acceder al valor real recogida por los sen- sores de la
campo precargado Variante de multi-campo Formwhere algunos campos están
IO; y V) Ver, lo que permite la gestión de todos los recursos gráficos utilizados
precargados con los valores existentes.
por los clientes.
Preasignado campo Formwhere el valor de un campo de selección es
de selección pre-seleccionada.

datos de búsqueda Útil para la tarea de entrada de datos que consiste en un

complejo de opciones formwith entre muchas opciones, como gateway 7.1.2 API
en el caso de la forma de llenado con grandes catálogos de
La puerta de enlace API es un componente que funciona como proxy de
productos.
hacia las micro-servicios. Expone las API micro-servicios a los clientes.
campos de selección Útil para tareas de entrada de datos que implica entrar en un
en cascada conjunto de selecciones que tienen algún tipo de dependencia
entre los demás.

arquitectura 7.2 Client

Búsqueda básica búsqueda por palabra clave en una colección de artículos.
La arquitectura de extremo frontal está basado en tecnologías web estándar y
Búsqueda sensible a la Permite la búsqueda de elementos que están relacionados y contenedores híbridos. Los clientes son gruesas aplicaciones con estado.
ubicación cerca de la posición del usuario actual.
Después del inicio de sesión, un cliente guarda la identidad del usuario y lo

Iniciar sesión Reconoce y comprueba la validez de una identidad utiliza para firmar las solicitudes posteriores. Los clientes se comunican sólo con
proporcionada por el usuario. la forma en puerta-API, y nunca directamente con los micro-servicios. El cliente
construye dinámicamente la interfaz de usuario utilizando los recursos comunes
Gestión de usuarios Espectáculos y permite editar la información
applicationdependent asociado con la identidad de un recuperados por el servicio (en el proxy) junto
usuario autenticado.
Tabla 3 Síntesis de los patrones de interacción de usuario utilizado para modelar patrones de IO

los patrones de la IO Los patrones de interacción de

usuario detalles MasterMultinivel selección forma campo Datos campos de Búsqueda Búsqueda Iniciar sesión Perfil de
datos por defecto multicampo precargado miran hacia arriba selección en básica Locationaware usuario de
maestros cascada pantalla

Un dispositivo de una sola operación

Uno de los dispositivos más operaciones

Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14

Más dispositivos de una sola operación

Más dispositivos más operaciones

Un dispositivo de un solo programa

Una de las categorías más operaciones

Obtener datos de un dispositivo

Obtener estado del dispositivo

Obtener información del dispositivo

Obtener información para una categoría

dispositivo de búsqueda

Dispositivos cercanos

extraer información

inicio de la aplicación

extraer información
Página 13 de 21
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
Tabla 4 Sincronización de datos modelo modelos
Descripción
sincronizaciones de La gestión de un evento de sincronización de datos de forma
datos asíncronos asíncrona y sin bloquear la interfaz de usuario.
sincronización de Administrar un evento de sincronización de datos de forma sincrónica; el
datos síncrono bloqueo de la interfaz de usuario mientras se produce.
almacenamiento parcial Sincronizar y almacenar datos sólo cuando sea necesario para
optimizar el ancho de banda de la red y el uso del espacio de
almacenamiento.
completa de Sincronizar y almacenar los datos antes de que sea necesaria para que la
almacenamiento aplicación tiene una mejor respuesta o tiempo de carga.
transferencia completa En un evento de sincronización, todo el conjunto de datos se
transfieren entre el dispositivo móvil y el sistema remoto.
transferencia de En un evento de sincronización, sólo las partes del conjunto de datos
marca de tiempo cambiado desde la última sincronización se transfieren entre el
dispositivo móvil y el sistema remoto utilizando un último cambio de
marca de tiempo.
transferencia de En un evento de sincronización, sólo las partes del conjunto de
matemática datos cambiado desde la última sincronización se transfieren entre
el dispositivo móvil y el sistema remoto usando un método
matemático.
con las plantillas específicas para cosas y métrica, y los elementos gráficos
de propiedad del corresponsal inquilino.
La figura 14 muestra un ejemplo de una interacción entre el cliente y el API
de puerta de enlace a fin de realizar una solicitud. Inicialmente el cliente
solicita un token mediante el uso de la
/autenticar punto final. La API de puerta de enlace a continuación, consulta la Identidad
microService para verificar las credenciales del cliente y generar un token. El
cliente ahorra el token y utilizarlo para las solicitudes posteriores. En el caso
ejemplificado, el cliente realiza una petición para recuperar todas las Cosas
pertenecientes a su Cliente.
Figura 15 informa de una pieza de la interfaz de usuario de una aplicación Web
implementada para soportar un escenario basado en la IO.
8 Experiencias y validación
Gracias a la colaboración con el equipo de Semioty WebRatio, tuvimos la
posibilidad de validar nuestro enfoque en torno a diez casos industriales
reales. En esta sección se presenta la experiencia en tres de ellos.
Representan casos significativos de la vida real a la que hemos aplicado
nuestro enfoque, y por lo tanto han sido útiles para que validen nuestra
solución también.
sistema de automatización 8.1 Inicio
Una empresa especializada en soluciones de automatización de casas ción de
consumo necesita una aplicación móvil para el hogar
Página 14 de 21
la gestión de los sistemas de automatización. Los requisitos de la aplicación
fueron:
• monitoreo de varios electrodomésticos: climatización (calor ing
ventilación y aire acondicionado), luces, sistema de seguridad
(cámaras y alarmas), sistema de riego, y los sensores ambientales;
• visualización del estado de todos los aparatos y dispositivos,
dispositivos de filtro, y poner de relieve los activos;
• notificación en tiempo real sobre el consumo y los estados de los aparatos;
• Multiplataforma (iOS, Android y Windows) y múltiples dispositivos
(teléfonos inteligentes y tabletas) ¡Ejecución ción. En particular, la
versión de la tableta deberá permitir la visualización del mapa casa con
las cosas en sus respectivas habitaciones;
• La configuración remota de la tem domótica sis-, mediante el envío de
comandos a los dispositivos como encender / apagar las luces. Los
comandos pueden ser enviados a un solo dispositivo o un grupo de ellos.
8.2 hornos inteligentes para la industria de panificación
Una empresa especializada inmanufacturing de hornos para la industria ery bak-,
necesitaba una herramienta que permite la configuración y monitoreo de hornos
industriales desplegados en las instalaciones de sus tomers cliente central. La herramienta
se proporciona cuatro interfaces de usuario diferentes:
1. El Tablero de instrumentos de producción para el usuario final del
el horno. Será visualizar información relacionada con el uso del
horno. La información a Visual_Up ize incluyen: secuencias de
cocción en orden temporal y detalles (fechas y horas, finalización
porcentaje edad, la carga del carro, el consumo de energía
calculado y perfil de temperatura) de la cocción en curso y hecho.
Asimismo, permitirá enviar recetas al horno.
2. El Tablero de instrumentos para la administración de energía. Será visu-
Alize la información sobre el consumo de energía del horno, que
incluyen: (i) actual y el consumo previ- ous referenciado por día,
semana, mes y año; (Ii) Cálculo de los costes de consumo de
energía que se refieren a día, semana, mes y año; y (iii) El consumo
de energía y el coste medio por receta. Para cada uno, se muestra
el consumo y el coste medio de toda la cocina.
3. La Tablero de instrumentos para el mantenimiento lo que permitirá a
visualizar y gestionar el estado de diversos componentes del horno.
4. La Tablero de instrumentos receta deberá permitir visualizar, editar,
añadir y borrar recetas disponibles para el horno.
8.3 gestión impresoras industriales
Una empresa especializada en tecnologías de impresión, quería una
aplicación para controlar las impresoras inteligentes desplegados a sus
clientes. La solicitud deberá permitir que el
Tabla 5 Síntesis de la compatibilidad entre los patrones de sincronización de datos y los patrones de la IO

los patrones de la IO patrones de sincronización de datos

asíncrona. sincronización de datos. Sincronización. sincronización de datos.

almacenamiento parcial completa de almacenamiento transferencia completa transferencia de marca de tiempo Mates. transferir

Un dispositivo de una sola operación

Uno de los dispositivos más operaciones

Más dispositivos de una sola operación

Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14

Más dispositivos más operaciones

Un dispositivo de un solo programa

Una de las categorías más operaciones

Obtener datos de un dispositivo

Obtener estado del dispositivo

Obtener información del dispositivo

Obtener información para una categoría

dispositivo de búsqueda

Dispositivos cercanos

extraer información

inicio de la aplicación

insertar información
Página 15 de 21
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 16 de 21

un segundo

do

La Fig. 13 Ejemplo de modelado basado en patrón: un una pieza de interfaz de usuario de casa inteligente solicitud; segundo Los objetos inteligentes considerados en casa inteligente

solicitud; do El modelo de interacción con el usuario de la aplicación, obtenida combinando juntos varios patrones de diseño

seguimiento de: (i) los diferentes estados asumidas por la impresora durante
un intervalo de tiempo dado; (Ii) los parámetros de impresión (incluyendo la
velocidad, número de copias, y la cantidad de tinta); y (iii) las estadísticas de
efectividad global de los equipos. El objetivo final del sistema es permitir que
pre- mantenimiento predictiva y el monitoreo continuo de la
dispositivos, con el fin de aumentar el nivel de servicio para los clientes.
8,4 validación preliminar
En todos los escenarios descritos hemos aplicado nuestro enfoque y se obtuvo
la versión final de las aplicaciones en ejecución
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
La Fig. 14 Ejemplo de interacción entre el cliente y el servidor
con la satisfacción del cliente. Las aplica- ciones generadas consistieron en una
implementación basada en la nube del lado del servidor del sistema, además de
aplicaciones móviles (cuando sea necesario) para múltiples plataformas generadas
en Córdoba PhoneGap distribución ción. En esta etapa, ya que la plataforma no
está todavía completamente industrializado, debido a la diversidad de los clientes
que tuvimos que implementar una solicitud por cliente, en lugar de la solución de
múltiples usuarios ideado en nuestro marco conceptual.
Aunque no corrimos una validación completa y detallada del trabajo, se
presenta aquí la evaluación de algunos indicadores de calidad de nuestro
enfoque. En términos de adecuación del lenguaje de modelado, podemos
reportar el alto grado de satisfacción de los diseñadores. De hecho, los
componentes del modelo de contenido y de interacción del usuario definidos
estaban cubriendo completamente todos los requisitos de todas las
aplicaciones. El único caso que no pudo ser cubierto por completo era
automáticamente la del diseño de la
La Fig. 15 Ejemplo de una aplicación caso real de una interfaz de usuario para el sistema de la IO, para el seguimiento de los parámetros de un sistema de aire acondicionado
Página 17 de 21
mapa de la ubicación con la posición de los dispositivos. Para optimizar la
experiencia, esto tenía que ser manualmente implementado en Javascript. En
términos de ejecutabilidad, la plataforma de generadores y la ejecución
estaban cubriendo los requisitos también: toda la estructura ge- neral de la
aplicación, la navegación y los principales contenidos de las páginas se han
generado automat- camente. La parte de interfaces que no podría generarse
es básicamente la personalización de la interfaz de usuario de estilo. En
términos de la cobertura de los patrones de diseño, todo el comportamiento
principal podría ser cubierto y se subsumido por uno u otro patrón. Por lo tanto
el diseño de la estructura de la aplicación básica podría especificarse con un
enfoque basado en el patrón-. Lo que no pudo ser cubierto con esta era la
conexión entre los patrones: esta parte requiere algún diseño manual y el
perfeccionamiento de los modelos de Opti-zando la experiencia en el traslado
de un caso de uso (es decir, el patrón) a otro.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14
9 RelatedWork
Este trabajo está relacionado con un gran corpus de investigaciones que se aplican
desarrollo dirigido por modelos (MDD) para especificar el
la interacción del usuario para el modelado de la interfaz de usuario
multi-dispositivo. Entre ellos podemos citar: UsiXML [15], TERESA [16], IFML [12],
y María [17]. Estos enfoques tratan con el catión especificación de interfaces de
usuario de propósito general y la interacción y que son agnósticos con respecto a
la plata- forma técnica o tecnología. Nuestro enfoque que se centra en los aspectos
específicos de las interacciones del usuario para sistemas de IO. Por otro lado, los
enfoques que se aplican MDD para el desarrollo de aplicaciones basadas en la
IO no se centran específicamente en las interfaces de usuario; que se pueden
agrupar en dos clusters.
El primer grupo incluye las obras que se dirigen cortabilidad eje- para la
IO, es decir, producir un código ejecutable para las aplicaciones basadas en la
IO. Entre ellos podemos citar: (i) FRASAD (Marco para la aplicación del
sensor Desa- ment) [18], a, software de múltiples capas nodo centrada archi-
tecture que tiene por objeto llenar el vacío entre las aplicaciones y los
sistemas de bajo nivel de sensor linfáticos. Proporciona una basado en
normas modelo de programación que permite describir los comportamientos
locales del nodo sensor y una lenguaje específico de dominio para el
modelado de aplicaciones basada en sensores. El código de aplicación final
se genera automáticamente a partir de los modelos iniciales; (Ii) Pankesh
Patel y Damien Cassou [19] propusieron una metodología de desarrollo que
consiste en separar el desarrollo de aplicaciones de la IO en diferentes
preocupaciones: dominio, funcional, despliegue, y la plataforma. Esta
separación permite a los interesados ​para hacer frente a esos problemas de
forma individual y reutilizarlos. El marco integra un conjunto de lenguajes de
modelado para especificar cada uno de los cuales permite describir una de las
preocupaciones mencionadas de las aplicaciones de la IO; (Iii) Franck Fleurey
et al. [20] propuso enfoque AMDD para generar APIs comuni- cación
eficientes para intercambiar mensajes con y entre los dispositivos de recursos
limitados. Este enfoque se basa en ThingML (lenguaje de modelado cosas)
[21]; (Iv) Mainetti et al. [22] propuso un modelo conceptual para la IO, la Web
de temas (WOX). WOX extiende el concepto de tema de la MQ Telemetry
Transport (MQTT) publicación-suscripción protocolo [23] con el objetivo de
llenar la brecha entre el diseño y los dominios solución en el contexto IO. En
WOx la entidad genérica la IO es visto como un conjunto de parejas Tema en
roles. Un papel WOX se expresa en términos de dimensiones gías
tecnológico y de colaboración; (V) Conzon et al. [24, 25] proporciona un
modelo impulsado juego de herramientas de desarrollo basado en el servicio
de descubrimiento semántica, lo que permite seleccionar de forma dinámica y
la localización de recursos o dispositivos disponibles, y proporciona una
interfaz gráfica que permite opers desa- para componer aplicaciones mashup.
(Vi) Ferry Pramu- dianto et al. [26] propuesto approachwhich AMDD se centra
en la separación de modelado de dominio desde tecno implementaciones
lógicas.
Página 18 de 21
expertos para la construcción de modelos de dominio mediante la
composición de objetos vir- tuales y vincularlos a las tecnologías de
implementación. Permite la generación automática de un código de
prototipo a partir de los modelos de dominio y un refinamiento manual del
mismo. Todos estos enfoques tienen en común el objetivo principal, es
decir ejecutabilidad de los sistemas de IO, aunque difieren en las fases
de desarrollo cubiertos y el tipo de apoyo proporcionado al diseñador. En
este sentido, su principal objetivo es la construcción de API o ERS
middleware lay- con el fin de enmascarar el acceso a diversos
dispositivos IO, lo que permite el descubrimiento, la integración y la
ejecución de las funciones del dispositivo. Nuestro trabajo se dirige a una
dimensión ortogonal, es decir la interacción del usuario. Como tal,
nuestro enfoque podría utilizarse junto con uno de los métodos descritos
anteriormente. Pueden proporcionar la capa de acceso común a los
dispositivos,
En el segundo grupo de TDM se acerca incluimos obras que se aplican MDD
a otros aspectos de la IO aplica- ciones. Entre ellas podemos mencionar un
enfoque MDD para el análisis de las aplicaciones de la IO a través de la
simulación [27]. Pre- Hofer y Chiarabini [28] compararon la basado en modelos
y
enfoques mashup, teniendo en cuenta las herramientas y metodologías para el
desarrollo de aplicaciones de la IO, usando UML y Paraimpu [29]. Una vez más,
nuestro enfoque está trabajando en aspectos onal orthog- con respecto a estas
cuestiones. Sin embargo, se puede integrar muy bien con ellos, gracias a la
disponibilidad de la semántica formal de IFML y de soluciones de simulación
basados ​en IFML [30]. Ni especifica- ción formal detallado ni herramientas de
simulación / validación son necesarios para las extensiones propuestas para la
IO, ya que dependen de los recursos y la infraestructura sobre IFML existentes.
Viceversa, en nuestra approachwe concentrarse en proporcionar métodos de
diseño eficientes y ejecutabilidad.
10 Conclusiones
En este trabajo presentamos los casos de dominio y uso de la IO ( RQ1), y se dirigió a
ellos mediante la definición de un conjunto de exten- siones de IFML estándar de
OMG para el modelado de la interfaz de usuario de las aplicaciones basadas en la IO
( PI2). Hemos presentado un conjunto de patrones de diseño para las interacciones de
los usuarios comunes para estas aplicaciones ( PI3). Además de a la definición formal
de las extensiones de la IO a la lengua IFML y un modelo de pautas de diseño de
interfaz de usuario para la IO, nuestra investigación incluyó la implementación de un
proto- tipo generador de código adaptados para el desarrollo de aplicaciones de la IO
( PI4).
Los futuros trabajos incluyen la realización de generadores de código, la
aplicación de otros casos reales en colaboración con los clientes
WebRatio y el idation Val- del enfoque en términos de rendimiento (tanto
de los generadores de código y de los sistemas generados) así como de
la aceptación por parte de los usuarios finales de las soluciones
generadas.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 19 de 21

Apéndice

Tabla 6 IO patrones de interacción del usuario: Modelos de identificación

Patrón Descripción Ejemplo

P1 Un dispositivo de una Este patrón permite al usuario establecer una operación para ser ejecutado por un
sola operación dispositivo específico. El usuario selecciona un dispositivo de interés a partir de una
lista de los dispositivos del sistema. Luego, se elige la operación que se realiza a
partir de una lista de operaciones apoyadas por el dispositivo seleccionado.

P2 Uno de los dispositivos Este patrón permite al usuario enviar a un solo dispositivo un conjunto de las
más operaciones operaciones a realizar. Las interacciones comienzan con la selección de un
dispositivo de interés. A continuación, el usuario selecciona las operaciones
deseadas a partir de una lista de operaciones compatibles.

P3 Más dispositivos de
una sola operación
Este patrón permite al usuario enviar a muchos dispositivos de una operación a ser
ejecutado. Las interacciones comienzan seleccionando los dispositivos de interés. A
continuación, el usuario selecciona una operación (a partir de una lista de las
operaciones soportadas por los dispositivos seleccionados) para ser ejecutado por
dichos dispositivos.

P4 Más dispositivos más Este patrón permite al usuario enviar un conjunto de operaciones a diferentes
operaciones dispositivos. Esas operaciones no son necesarias las mismas para todos los
dispositivos, por lo que las operaciones deben ser encuadernados a los dispositivos
que pueden realizar ellos.

P5 Un dispositivo de un Este patrón permite al usuario enviar el programa (identificador) al dispositivo

solo programa que ejecutarlo. UN programa es un conjunto de operaciones que tienen que ser
ejecutado en un orden preciso. Suponemos que los programas ya están
configurados en los dispositivos, por lo tanto, el usuario sólo tiene que enviar el
identificador de programa al dispositivo.

P6 Una de las categorías Este patrón permite al usuario configurar las operaciones a diferentes dispositivos en
más operaciones función de los grupos a los que pertenecen, sin necesidad de seleccionar un
dispositivo a la vez.

Tabla 7 IO patrones de interacción del usuario: Obtener patrones ID

Patrón Descripción Ejemplo

P7 Obtener datos de un dispositivo El usuario recupera, la información general sobre el dispositivo, como Id, nombre,
descripción, andmodel. El usuario selecciona un dispositivo que está interesado
en una lista de dispositivos.

P8 Obtener estado del dispositivo Este patrón permite al usuario recuperar el estado actual de un dispositivo dado.
Las interacciones comienzan con la selección del dispositivo para el que el
usuario necesita conocer el estado Tho. Entonces, el estado correspondiente se
muestra al usuario.
Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 20 de 21

Tabla 7 IO patrones de interacción del usuario: Obtener patrones ( Continuado)

Patrón
CARNÉ DE IDENTIDAD Descripción Ejemplo

P9 Obtener información del dispositivo Este patrón permite al usuario recuperar la información proporcionada por un
dispositivo sobre el objeto supervisado. Las interacciones comienzan con la
selección del dispositivo para el que el usuario necesita saber aunque la
información del objeto supervisado. A continuación, la información solicitada
se muestra al usuario.

P10 Obtener Información para una Este patrón permite al usuario obtener la información de todos los dispositivos
categoría de la misma categoría.

P11 dispositivo de búsqueda Este patrón permite al usuario buscar un dispositivo específico. La búsqueda
del dispositivo se puede hacer de diferentes maneras dependiendo de la
aplicación y de los dispositivos.

P12 Dispositivos cercanos Este patrón permite al usuario recuperar todos los dispositivos cerca de un
lugar determinado. La ubicación pueden enchufar por el usuario o recupera
de la ContextDimension, Posición, que representa la información de
ubicación del dispositivo utilizado para acceder a la aplicación.

Tabla 8 IO patrones de interacción del usuario: Patrones de identificación basados ​en

eventos Patrón Descripción Ejemplo

P13 extraer información Este patrón permite al usuario verificar la disponibilidad periódicamente de nuevos
datos de los dispositivos. Para ahorrar algunos recursos como la energía, de los
datos que pueden ser retrasada por una cierta cantidad de tiempo sin impactar
sobre el resultado de la aplicación, el usuario puede decidir activar periódicamente
el servicio de escucha y tirar toda la información de los dispositivos.

P14 inicio de la aplicación Este patrón permite al usuario recuperar la información enviada por los dispositivos
cuando la aplicación no estaba funcionando o cuando él estaba fuera de línea. El
evento de lanzamiento llama al sistema externo y recibe las notificaciones
enviadas por todos los dispositivos cuando el usuario estaba fuera de línea.

P15 insertar información Este patrón permite al usuario visualizar los mensajes enviados por un
dispositivo de la IO como una notificación de inserción.

Notas finales Nota del editor

1 http://www.iiconsortium.org/ Springer Naturaleza se mantiene neutral con respecto a las reclamaciones jurisdiccionales en los mapas

publicados y afiliaciones institucionales.

2 http://www.webratio.com

3 http://www.semioty.com
datos del autor
1 Politécnico de Milán. Dipartimento di Elettronica, Informazione e Bioingegneria, Piazza L. Da Vinci

Contribuciones de los autores

32, 20133 Milán, Italia. 2 srl WebRatio, Piazzale Cadorna, 10, 20123 Milán, Italia.

Igualdad de contribución. Todos los autores leyeron y aprobaron el manuscrito final.

Conflicto de intereses Recibido: 28 Noviembre el año 2016 Aceptado: 28 Agosto 2017

Los autores declaran que no tienen intereses en conflicto.

Brambilla et al. Diario de Servicios de Internet y Aplicaciones ( 2017) 8:14 Página 21 de 21

referencias en Internet de las cosas, WF-IO 2015. IEEE, Milán. pp 46-51. doi: 10.1109 /
1. Koreshoff TL, Robertson T, Leong TW (2013) Internet de las cosas: una revisión de la literatura y WF-IoT.2015.7389025
de los productos. En: Actas de la 25ª australiana Interacción Humano-Computadora Conferencia: 23. Locke D (2016) MQ Telemetry Transport (MQTT) V3.1 Especificación del protocolo.
Aumento de aplicaciones, innovación, colaboración. OzCHI '13. ACM, Nueva York. pp 335-44. doi: https://www.ibm.com/developerworks/library/ws-mqtt/. En línea. Consultado el 06 de septiembre 2016
10.1145 / 2.541.016,2541048
24. Conzon D, Brizzi P, Kasinathan P, Pastrone C, Pramudianto F, Cultrona P (2015) el desarrollo de
2. Vatsa VR, Singh G (2015) Una revisión de la literatura en Internet de los objetos (IO). Int J Comput Syst aplicaciones Industrial explotando visión IOT y modelo de programación conducido. En: Inteligencia
(ISSN: 2394-1065) 2 (08) en Redes de Próxima Generación (ICIN), 2015 18ª Conferencia Internacional Sobre. IEEE. pp
3. Atzori L, Iera A, G Morabito (2010) La Internet de las cosas: Un estudio. Comput Netw 54 168-75
(15): 2787-805. doi: 10.1016 / j.comnet.2010.05.010 25. (2016) Ebbits. http://www.ebbits-project.eu/news.php. En línea. Consultado el 06 de septiembre 2016

4. Broll G, E Rukzio, Paolucci M, M Wagner, Schmidt, Hussmann H (2009) Perci: interacción de

servicio generalizado con el Internet de las cosas. IEEE Internet Comput 13 (6): 74-81
5. Kranz M, Holleis P, Schmidt (2010) la interacción Embedded: Interacción con el Internet de
las cosas. IEEE Internet Comput 14 (2): 46-53
6. Shirehjini AAN, Semsar A (2017) la interacción humana con entornos inteligentes basados ​en la IO.
Herramientas Multimed Appl 76 (11): 13343-65
7. Da Xu L, Él W, S Li (2014) Internet de las cosas en la industria: Una encuesta. IEEE Trans Ind Inf 10
(4): 2233-243
8. Capello M, M Toja, Trapani N (2016) Un servicio de monitoreo en tiempo real basado en Internet
industrial de cosas para gestionar la logística agroalimentarias. En: Actas de la 6ª Conferencia
Internacional sobre Sistemas de Información, Logística y cadena de suministro, Burdeos, Francia,
disponible en: http://ils2016conference.com/wpcontent/uploads/2015/03/ ILS2016_FB01_1.Pdf,
accede. pp 10-21
9. Holler J (2014) FromMachine-a-máquina a la Internet de las cosas: Introducción a una nueva
era de la inteligencia. Academic Press, Amsterdam. ISBN: 978-0124076846
26. Pramudianto M, Indra IR, Jarke M (2013) dirigida por modelos de desarrollo para Internet de
aplicación de prototipos cosas. En: La 25ª Conferencia Internacional sobre Ingeniería de
Software e Ingeniería del Conocimiento, Boston, MA, EE.UU., Junio ​27-29, 2013. pp 703-8.
http://dblp.uni-trier.de/rec/bib/conf/seke/PramudiantoIJ13
27. Brumbulli M, E Gaudin (2016) Hacia la simulación basado en modelos de la Internet de las cosas.
En: Complejo de Diseño de Sistemas de Gestión y Asia. Springer, Berlín. pp 17-29
28. Prehofer C, Chiarabini L (2015) A partir de Internet de las cosas mashups para el desarrollo basado
en modelos. En: Actas de la IEEE 2015 39a anual de software y aplicaciones informáticas
Conferencia - Volumen 03, COMPSAC '15. IEEE Computer Society, Washington. pp 499-504. doi:
10.1109 / COMPSAC.2015.263
29. Un Pintus, Carboni D, A Piras (2012) Paraimpu: una plataforma para una red social de las cosas. En:
Actas de la conferencia internacional sobre el 21 World Wide Web, WWW '12 Companion. ACM,
Nueva York. pp 401-4. doi: 10.1145 / 2.187.980,2188059

10. Vermesan O (2014) Internet de las cosas - a partir de la investigación y la innovación a la implantación del
mercado. River Publishers, Aalborg. ISBN: 9788793102941
11. Farooq M, WaseemM, Mazhar S, Khairi A, Kamal T (2015) Una revisión de Internet de los
objetos (IO). Int J Comput Appl 113 (1): 1-7
12. Brambilla M, Fraternali P, et al. (2014) The Interaction FlowModeling Language (IFML),
Versión 1.0. Informe técnico, Object Management Group (OMG), http://www.ifml.org
30. Bernaschina C, Comai S, Fraternali P (2017) IFMLEdit.Org: Model Driven Rapid Prototyping de
aplicaciones para móviles. En: Actas de la 4ª Conferencia Internacional OnMobile Ingeniería de
Software y Sistemas, MobileSoft '17. IEEE Press, Piscataway. pp 207-8. doi: 10.1109 /
MOBILESoft.2017.15

13. Brambilla M, Mauri A, Umuhoza E (2014) La extensión de la interacción de flujo Modeling Language
(IFML) para el modelo de desarrollo impulsado por las aplicaciones móviles para el usuario. En:
Awan I, Younas M, Franch X, Quer C (eds). Sistemas de Información Web móvil: 11ª Conferencia
Internacional, MobiWIS 2014. Proceedings. Springer International Publishing, Cham. pp 176-91.
doi: 10.1007 / 978-3-319-10359-4_15

14. Brambilla M, Fraternali P (2014) Interacción FlowModeling Idioma: Model-Driven Ingeniería interfaz de
usuario de la Web y las aplicaciones móviles con IFML. Morgan Kaufmann Publishers Inc., EE.UU.

15. Vanderdonckt J (2005) Un entorno de MDA-compatible para el desarrollo de interfaces de usuario de

los sistemas de información. En: Pastor O, Falcão e Cunha J (eds). Sistemas de Información
Avanzados de Ingeniería: 17ª Conferencia Internacional, CAISE 2005. Proceedings. Springer Berlin
Heidelberg, Berlín. pp 16-31. doi: 10.1007 / 11431855_2

16. Berti S, Correani F, Mori G, Paternò F, Santoro C (2004) Teresa: un entorno basado en transformación
para el diseño y desarrollo de interfaces de dispositivos múltiples. En: CHI '04 Resúmenes Extendidos
en factores humanos en sistemas de computación, CHI EA '04. ACM, Nueva York. pp 793-4. doi:
10.1145 / 985.921,985939

17. Paternò F, C Santoro, Spano LD (2009) María: A, declarativa, lenguaje de nivel de abstracción
universal para múltiples aplicaciones orientadas a servicios en entornos ubicuos. ACM Trans
Comput-Hum Interact 16 (4): 19: 1-19: 30. doi: 10.1145 / 1.614.390,1614394

18. Nguyen XT, Tran HT, Baraki H, Geihs K (2015) Frasad: un marco para el desarrollo de aplicaciones
IOT basado en modelos. En: 2015 IEEE segundo Foro Mundial sobre la Internet de las cosas
(WF-IO). IEEE. pp 387-92. doi: 10.1109 / WF-IoT.2015.7389085

19. Patel P, D Cassou (2015) Hacer posible que el desarrollo de aplicaciones de alto nivel para el internet de las
cosas. J Syst Softw 103: 62-84
20. Fleurey F, Morin B, Solberg A, Barais O (2011) Mde para gestionar las comunicaciones con
y entre los sistemas de recursos limitados. En: MODELOS. Springer, Berlín. pp 349-63

21. Fleurey M, Morin B (2016) ThingML. http://thingml.org. En línea; Consultado el 06 de septiembre

2016

22. Mainetti L, L Manco, Patrono L, Sergi I, Vergallo R (2015) Web de mensajes: Un enfoque de diseño basado en
modelos IOT-conscientes. En: IEEE segundo Foro Mundial