Perfis de Utilizador para Casas Inteligentes Artur Ricardo Estima Marques de Arˆ ede Dissertac ¸˜ ao para obtenc ¸˜ ao do Grau de Mestre em Engenharia Inform ´ atica e de Computadores Orientador: Prof. Renato Jorge Caleira Nunes J´ uri Presidente: Prof. Paolo Romano Orientador: Prof. Renato Jorge Caleira Nunes Vogais: Prof. Alberto Manuel Ramos da Cunha Outubro 2017
94
Embed
Perfis de Utilizador para Casas Inteligentes · Perfis de Utilizador para Casas Inteligentes Artur Ricardo Estima Marques de Aredeˆ Dissertac¸ao para obtenc¸˜ ao do Grau de
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Perfis de Utilizador para Casas Inteligentes
Artur Ricardo Estima Marques de Arede
Dissertacao para obtencao do Grau de Mestre em
Engenharia Informatica e de Computadores
Orientador: Prof. Renato Jorge Caleira Nunes
Juri
Presidente: Prof. Paolo RomanoOrientador: Prof. Renato Jorge Caleira NunesVogais: Prof. Alberto Manuel Ramos da Cunha
Outubro 2017
“Those who plan do better than those who do not plan,
even though they rarely stick to their plan.”
— Winston Churchill
ii
Agradecimentos
Esta dissertacao e o resultado de muito esforco e dedicacao e e importante exprimir os meus sinceros
agradecimentos a algumas pessoas sem as quais este trabalho nao seria possıvel.
Em primeiro lugar, gostaria de agradecer ao meu orientador, o Prof. Renato Nunes, pela confianca
que depositou em mim, pelo conhecimento transmitido, pela disponibilidade e apoio demonstrado em
todos os momentos.
Gostaria de agradecer a todos os meus amigos e colegas, em especial ao Alexandre Eraclides, ao
Joao Rego e ao Eduardo Melo, que me acompanharam durante esta extraordinaria jornada, nos longos
projetos, trabalhos, exames e risadas e por serem o meu suporte quando a minha famılia estava longe.
Por fim, gostaria de agradecer a minha famılia por todo o apoio, incentivo e paciencia demonstrada
ao longo do meu percurso academico. Aos meus pais, Artur Arede e Isabel Soares, pelos valores
com que me educaram que fizeram de mim quem sou. Ao meu avo, David Rosa, que sempre parti-
lhou comigo a sua sabedoria e os bons conselhos. E ao meu irmao, Andre Arede, pelo seu enorme
entusiasmo, amizade e confianca nas minhas capacidades.
A todos e a cada um de voces um muito obrigado, Artur Arede.
Dedicado a memoria da minha avo Francelina Baltazar.
iii
Abstract
Smart homes main goal is to improve the comfort, security and allow energetic savings to its inhabitants.
However, the usefulness of smart homes strongly depends on how easy users can take advantage of its
existing functionalities. In this thesis, we introduce user profiles, a method that accurately captures user
preferences, such as temperature, room luminance, shutter status, volume or preferred TV channel.
When a user enters any room of the house, the proposed solution will configure the room automatically
to satisfy in the best way possible the user preferences. In order to do that, if there are several users
in the same room, the system deals autonomously with conflicts between preferences. Additionally,
the system identifies manual actions performed by the users and uses that to automatically make small
adjustments to their profiles.
The contributions of this dissertation include a review on relevant literature on smart home confi-
guration methods, conflict detection, conflict resolution and machine learning strategies. We provide a
practical approach to configure a smart home backed by a conflict resolution mechanism that maximizes
user satisfaction. The proposed mechanisms, the developed system and its user interface, were evalu-
ated through a simulation context and conducting usability tests. The implemented solution follows the
DomoBus approach.
Keywords
Smart Homes, User Profiles, Conflict Resolution, Machine Learning, DomoBus
Resumo
As casas inteligentes tem como principal objetivo melhorar o conforto, a seguranca e permitir poupancas
energeticas aos seus habitantes. No entanto, a utilidade das casas inteligentes depende da facilidade
com que os utilizadores conseguem tirar proveito das funcionalidades existentes. Com esta dissertacao,
introduzimos um metodo que permite ao utilizador definir um ou mais perfis, explicitando as suas pre-
ferencias pessoais como, por exemplo, valor da temperatura, nıvel de luminosidade, estado das persi-
anas, som ambiente e canal de TV preferido. Quando um utilizador entra numa dada divisao da casa,
o sistema configura automaticamente essa divisao para satisfazer da melhor forma possıvel as suas
preferencias. O sistema lida, de forma autonoma, com os conflitos entre preferencias de utilizadores,
caso se encontrem diversos utilizadores na mesma divisao. Adicionalmente, efetua pequenos ajustes
aos perfis dos utilizadores, sempre que identifica que os utilizadores alteram manualmente os valores
das suas preferencias.
As contribuicoes desta dissertacao incluem o estudo sobre a literatura relevante relacionada com
a configuracao de casas inteligentes, detecao de conflitos, resolucao de conflitos e estrategias de ma-
chine learning. Propomos uma abordagem pratica para configurar uma casa inteligente apoiada por
um mecanismo de resolucao de conflitos que maximiza a satisfacao dos utilizadores. Os mecanismos
propostos, o sistema desenvolvido e a interface de utilizador criada, foram avaliados atraves de um
contexto de simulacao e conduzindo diversos testes de usabilidade. A solucao implementada segue a
abordagem DomoBus.
Palavras Chave
Casas Inteligentes; Perfis de Utilizador; Resolucao de Conflitos; Machine Learning; DomoBus
CASAS (Rashidi and Cook, 2008) e um sistema para casas inteligentes que descobre e adapta-se
as mudancas nas preferencias dos residentes, permitindo desta forma gerar automaticamente politicas
satisfatorias de controlo. A capacidade de adaptacao do sistema CASAS e alcancada primariamente
atraves da utilizacao de metodos de data mining, no entanto dispoe tambem de estrategias de aprendi-
zagem que tem em consideracao o feedback, fornecido de forma implıcita ou explicita, dos residentes.
Para o sistema sao enviadas informacoes correspondentes aos varios sensores presentes no am-
biente da habitacao, como por exemplo, movimento ou luz. Esses dados sao ”minados” pelo algoritmo
Frequent and Periodic Activity Miner (FPAM) com o proposito de descobrir padroes interessantes de
automatizar nas atividades dos residentes (uma atividade e composta por dois ou mais eventos, sendo
um evento, por exemplo, ligar luz). O FPAM e capaz de encontrar padroes de atividades com perıodos
inexatos, duracao variavel e restricoes de tempo previsıveis. Depois da estrutura das atividades e os
seus respetivos perıodos serem conhecidos pelo FPAM, estes padroes sao entao modelados pelo Hi-
erarchical Activity Model (HAM), cujo objetivo passa por filtrar as atividades de acordo com o dia e a
hora em que ocorrem. Por outras palavras, recorrendo a informacao temporal recolhida pelo FPAM e
possıvel perceber as preferencias temporais dos utilizadores sobre as suas atividades.
Uma vez que os habitos dos utilizadores tem tendencia a alterar-se com o passar do tempo, o
sistema CASAS dispoe de dois tipos diferentes de mecanismos de adaptacao, ao qual os autores
chamam de feedback de preferencias implıcito e explicito. Dentro dos mecanismos explıcitos existe a
abordagem de direct manipulation, em que os utilizadores podem explicitamente fornecer feedback ao
sistema, manipulando diretamente as atividades atraves de uma interface disponıvel. Alem disso existe
ainda a abordagem guidance, que possibilita os utilizadores guiar o sistema avaliando as atividades e
fornecendo desta forma tambem um feedback explicito. Por outro lado, existe a abordagem request,
que corresponde a uma combinacao entre o feedback explicita e implıcito e permite aos residentes
eleger uma atividade a monitorizar, dando a indicacao de que podem ocorrer mudancas. Por ultimo,
a abordagem smart detection nao requer qualquer tipo de interacao com o utilizador, neste caso o
sistema procura misturar as novas atividades com as descobertas anteriormente, constituindo assim
uma forma de feedback implıcito.
Chen et al. (Chen et al., 2012) propoem uma abordagem para o reconhecimento de atividades
baseada na modelacao ontologica e no raciocınio semantico. A motivacao para o trabalho vem do facto
de apesar da quantidade de dados ser cada vez maior, devido ao numero de sensores presentes nas
casas inteligentes estar a aumentar, existe ainda uma enorme diferenca entre o potencial dos dados e
o que realmente e realizado com eles. Recolhendo informacao sobre que Activities of daily living (ADL)
um utilizador realiza por norma e a forma especifica que cada utilizador tem de executar uma ADL, e
possıvel criar perfis individuais de utilizador para a execucao de cada atividade.
Visto que as atividades podem variar na sua forma de serem executadas de pessoa para pessoa,
10
foram criados dois modelos ontologicos: (1) o modelo ontologico de ADL, que tem como objetivo prin-
cipal identificar atividades desempenhadas pelos utilizadores. (2) O modelo ontologico de contexto,
criado com o proposito de determinar todos os dados sobre o ambiente em que atividade e realizada,
desde a localizacao onde e executada ate a informacao temporal. As ADL sao realizadas numa diver-
sidade de contextos especıficos. A informacao contextual (por exemplo, a temperatura ou a duracao
de um evento), e capturada atraves de multiplos sensores, ja que as ADL requerem uma ligacao de
informacoes de forma a inferir certas atividades.
A arquitetura do sistema esta dividida em tres principais areas. Uma das areas contem as ontolo-
gias de contexto usadas para instanciar observacoes dos sensores e a diferenciacao entre atividades
genericas e atividades personalizaveis. A outra area contem os componentes relacionados com o am-
biente fısico, como os utilizadores e os sensores. O Assistive Agent, componente principal do sistema,
recebe como input as descricoes semanticas de uma situacao e executa o reconhecimento de ativida-
des. Para o reconhecimento de atividades foi desenvolvido um algoritmo, baseado em logica de primeira
ordem, que permite organizar de forma hierarquica e temporal os resultados do reconhecimento rea-
lizado. O reconhecimento de atividades e um processo progressivo. As atividades sao gradualmente
aperfeicoadas, deixando de ser atividades genericas e altamente abstratas, para se tornarem atividades
concretas com relevantes detalhes sobre a sua execucao.
Numa organizacao, normalmente existe sempre algum tipo de hierarquia entre os seus integran-
tes. Bandara et al, (Bandara et al., 2015) propoem um algoritmo para prever automaticamente as pre-
ferencias de um grupo de utilizadores, baseando-se na sua hierarquia. Uma relacao hierarquica entre
os elementos pode ser definida, investigando dentro do grupo o ultimo utilizador que alterou manual-
mente as condicoes do ambiente de modo a satisfazer as suas proprias preferencias. Esse utilizador
sera quem tem prioridade de preferencias de entre o grupo de utilizadores presente no momento da
alteracao. E importante referir que a medida que os utilizadores vao efetuando alteracoes manuais o
sistema vai registando essas alteracoes e os utilizadores que as realizaram. Isto e relevante pois recor-
rendo a esse registo o sistema e capaz de deduzir de um grupo de utilizadores quem tem prioridade de
preferencias, baseando-se na hierarquia definida anteriormente. Resumidamente, a relacao hierarquica
entre os ocupantes e as condicoes de conforto para um ambiente podem ser geradas monitorizando a
interacao entre os ocupantes. Visto que e possıveis os utilizadores terem o mesmo nıvel hierarquico, e
necessario resolver os conflitos. Como tal, de modo a evitar inconsistencias, as interacoes mais antigas
e que causam conflitos sao removidas. Em conclusao, o algoritmo desenvolvido gera uma hierarquia
entre utilizadores, tendo em consideracao as alteracoes manuais realizadas sobre o ambiente e caso
surjam conflitos sao removidas as interacoes mais antigas. Foi efetivamente verificada uma reducao do
numero total de interacoes manuais realizadas pelos utilizadores.
Iglesias e Kastner (Iglesias and Kastner, 2013) introduzem um conceito ao qual chamam de perfil
11
de habito. Os perfis de habito funcionam sobre os principais servicos presentes numa casa inteligente,
como por exemplo, seguranca, iluminacao, climatizacao entre outros. Os autores definem um perfil de
habito como sendo uma colecao de dados relacionados temporalmente, que correspondem a um certo
fenomeno domestico. Os perfis sao neste trabalho caracterizados como abstracoes de comportamentos
dos utilizadores. Um comportamento pode ser unico (nao representativo), mas pode eventualmente
tornar-se num comportamento repetitivo (passando assim a ser um habito estavel).
As funcoes principais dos perfis de habito passam por: reunir a operacao dos diversos servicos num
unico contexto comum, controlo preditivo e fornecer feedback baseando-se em experiencias anteriores
(tendo em conta o procedimento dos utilizadores para resolver certas situacoes anteriormente ou o que
habitualmente fazem). Na implementacao os autores usam uma framework que usa estes perfis. A
framework gera perfis de comportamento a partir da transformacao dos dados fornecidos pelos sen-
sores. A partir destes dados sao gerados padroes de habito. Estes sao interpretados e traduzidos de
modo a produzir a informacao necessaria para tomar acoes. Neste trabalho sao ainda introduzidas
diversas aplicacoes que apresentam funcoes esperadas por um sistema inteligente. Estas aplicacoes
podem atuar sobre a iluminacao, seguranca, climatizacao e consumo de energia. E ainda prevista uma
criacao de relatorios sobre consumos energeticos e uma aplicacao que permite aos utilizadores corrigir
as suas preferencias de forma a ajudar o sistema. Na simulacao realizada e feita uma curta mencao
acerca da resolucao de conflitos entre utilizadores. Esta passa por atribuir a cada divisao uma ordem
de prioridades acerca das atividades que se podem realizar. Sao mencionadas tres tipos de atividades:
trabalhar, relaxar e dormir.
2.3 Solucoes para Resolucao de Conflitos
Camacho (Camacho, 2014), propoe uma solucao para detetar e resolver conflitos sobre as condicoes
do ambiente de uma casa inteligente. A framework apresentada e composta por tres modulos principais
responsaveis por reunir informacao de um contexto, detetar, resolver conflitos e decidir qual a acao a
tomar avaliando as condicoes do ambiente inserido.
A informacao de um contexto fornecida pela ontologia, e utilizada pelo modulo Analyser para ex-
trair informacao sobre possıveis conflitos. Esta informacao recolhida tem indicacoes sobre os ocupan-
tes presentes numa divisao, as atividades a ser executadas e ainda sobre as variaveis de ambiente
(como por exemplo a temperatura ou intensidade luminosidade) em uso num determinado momento.
A informacao e traduzida para formulas matematicas de forma a encontrar solucoes validas para o
problema. Os modulos Resolver e Advisor aplicam tecnicas de programacao com restricoes sobre os
elementos devolvidos pelo modulo Analyser, modelando-os como restricoes. Estas restricoes corres-
pondem aos varios conjuntos de solucoes, dos quais sao escolhidos os mais adequados a resolucao do
12
problema. O modulo Decider recebe as solucoes e os dados gerados por ambos os modulos (Resolver
e Advisor ) e le os dados dos atuadores de forma a verificar sobre quais os dispositivos e necessario
atuar para criar o ambiente pretendido.
As ontologias sao utilizadas para representar conhecimento, recorrendo para isso a regras semanticas
ou sintaticas. O sistema utiliza uma ontologia como input. Como output sao devolvidos comandos para
os atuadores e notificacoes para os utilizadores. Para alem do conflito entre preferencias de utilizadores,
as otimizacoes energeticas fazem tambem parte deste trabalho, ja que ambos podem ser modelados
como instancias de um PSR. Em suma, o sistema executa acoes sobre variaveis de um ambiente, de
modo a tentar satisfazer todas as restricoes impostas pelos utilizadores sobre estas variaveis. Se nao
for encontrada uma solucao, visto que nem sempre e possıvel satisfazer todas as restricoes impostas
pelos utilizadores, o sistema sugere ao utilizador uma outra divisao onde este possa usufruir das suas
preferencias.
Armac et al. (Armac et al., 2006), caracteriza os conflitos como inevitaveis podendo estes ocor-
rer quando varios servicos coexistem no mesmo ambiente. Estes servicos podem ser simples como
de controlo de iluminacao e temperatura ou complexos como perfis de utilizadores ou para prevenir
situacoes perigosas.
Este trabalho da uma contribuicao no sentido de mecanizar a identificacao de diferentes situacoes
de conflito, formalizando uma classificacao para os diferentes tipos de conflito. Dependendo do mo-
mento no tempo em que os conflitos sao identificados, podem ser empregues duas tecnicas diferentes
de detecao de conflitos: a estatica ou a dinamica. A detecao usando a tecnica estatica e realizada, mai-
oritariamente, durante o design e especificacao e analisa os elementos do sistema e as suas interacoes
baseando-se numa descricao formal do seu comportamento. Em alternativa, a tecnica dinamica e um
processo que corre paralelamente ao sistema e que esta continuamente a obter informacoes do am-
biente, trabalhando sobre uma imagem atualizada do sistema. A detecao dinamica de conflitos e mo-
delada atraves de uma maquina de estados que e criada para cada recurso. Sao as mudancas de
estado destas maquinas que, quando requisitadas por um servico, eventualmente levam a situacoes de
conflito. Os autores recorrem, maioritariamente, a uma detecao de conflitos dinamica que utiliza uma
estrategia de resolucao baseada em regras.
A framework HOMER (Maternaghan and Turner, 2013) e descrita como um sistema offline para ana-
lisar conflitos e tem como objetivos suportar o controlo, monitorizacao e personalizacao de um sistema
de automacao residencial (HAS). E um sistema aberto que permite a adicao de novos dispositivos.
Em vez de limitar a personalizacao apenas ao nıvel dos dispositivos, a framework Homer foi dese-
nhada para permitir a escrita de politicas (When something happens Do something). Estas politicas
permitem ser configuradas recorrendo a diferentes variaveis, nomeadamente, relacionadas com um
dispositivo, a localizacao (o que deve acontecer em determinada divisao), o espaco temporal (o que
13
deve acontecer ao fim de semana, por exemplo) e o indivıduo (o que deve acontecer quando certa
pessoa entra numa divisao). Para escrever estas politicas o sistema dispoe de uma linguagem criada
para o efeito, a Homeric policy language, que segue uma gramatica propria. A informacao necessaria
para detetar um conflito esta acessıvel desde o momento em que e definida uma politica nova, dando a
possibilidade ao utilizador de modificar politicas problematicas.
A arquitetura do sistema e constituıda por varios modulos. Dois destes modulos desempenham
funcoes principais, sao estes os Overlap Detector e o Conflict Detector. O Overlap Detector verifica po-
liticas novas ou editadas comparando-as com as politicas existentes. Para alem de verificar a validade
de uma politica, apura tambem se a politica pode ser ativada simultaneamente com outra ja presente.
Se sim, entao sao consideradas sobrepostas. O Conflict Detector verifica se as politicas sobrepostas
tem acoes que entram em conflito entre elas. A detecao de conflitos depende da informacao fornecida
pelos utilizadores sobre os efeitos no ”ambiente” de situacoes particulares.
Os conflitos sao tratados em tres etapas: detecao de sobreposicoes entre politicas, detecao de
conflitos entre as suas acoes e, por fim, lidar com os conflitos detetados. O problema de detetar
sobreposicoes e tratado como um PSR, em que se tenta satisfazer as restricoes impostas pelas poli-
ticas. As clausulas das politicas sao mapeadas em restricoes e analisadas pela ferramenta escolhida
pelos autores, o JaCoP. Esta ferramenta, baseada em Java, pode ser integrada com o HOMER. Na
detecao de conflitos, as acoes sao avaliadas pelo efeito que produzem nos valores do ”ambiente”. A
analise ajuda os utilizadores a avaliar se o conflito existe realmente ou pode ser ignorado. Para a
resolucao de conflitos, devido a natureza subjetiva, o utilizador e informado de conflitos aquando da
criacao/alteracao de politicas e e levado a decidir o que e importante e o que deve ser ignorado.
Park et al. (Park et al., 2005) propoe uma tecnica dinamica de resolucao de conflitos ao conside-
rar ambas as intencoes dos utilizadores envolvidos e as suas preferencias. O objetivo e maximizar a
satisfacao dos utilizadores com o resultado produzido pela resolucao. Para isso, os conflitos sao re-
solvidos de forma diferente, dependendo das intencoes dos utilizadores envolvidos. As intencoes dos
utilizadores sao modeladas por um valor associado a um contexto (por exemplo a preferencia do uti-
lizador A sobre o contexto Iluminacao e Muito Alta). A diferenca entre o resultado da resolucao e a
intencao do utilizador e representado por um conjunto de ”funcoes de distancia”. As preferencias dos
utilizadores sao expressas como funcoes de custo. As funcoes de custo permitem refletir o nıvel de
satisfacao do utilizador face a diferenca entre a sua intencao e o resultado da resolucao. As aplicacoes
em conflito adaptam-se entao ao resultado da resolucao.
Luo et al. (Luo et al., 2013), propoem uma framework de verificacao de regras e um mecanismo de
resolucao de conflitos. A estrategia utilizada e dividida em dois passos. Em primeiro lugar e realizada
uma verificacao das regras durante a sua criacao. Em segundo lugar e feita uma verificacao em tempo
de execucao das regras. A verificacao avalia as regras baseando-se numa analise probabilıstica de
14
modo a verificar se o conteudo das regras e anormal e deteta caso existam conflitos entre elas. Foi
criada uma classificacao para os diferentes tipos de conflitos. Os conflitos podem ocorrer entre: (1) um
utilizador e um servico, (2) um utilizador e multiplos servicos, (3) multiplos utilizadores e um servico e
ainda (4) multiplos utilizadores e multiplos servicos. Com base nesta informacao e utiliza uma tabela
que mapeia o tipo de conflito a uma resolucao adequada. As resolucoes disponıveis para os conflitos
sao as nomeadamente: questionar o utilizador, priorizar o servico, priorizar o utilizador, priorizar o timing
e priorizar o objetivo. Este mecanismo funciona em tempo de execucao e permite aumentar a eficiencia
e fiabilidade do sistema de verificacao de regras.
COMITY (Tuttlies et al., 2007) e uma middleware framework que permite as aplicacoes evitar os
conflitos, detetando e resolvendo potenciais conflitos em ambientes computacionalmente ”pervasivos”,
Pervasive Computing environments (PCE). A execucao de uma aplicacao num Pervasive Computing
environments (PCE) pode alterar fisicamente o ambiente, nomeadamente o seu contexto. Para tal,
as aplicacoes devem especificar a sua influencia sobre o ambiente fısico antes de serem executadas.
Desta forma, e possıvel detetar os conflitos antes de ocorrerem.
O sistema e constituıdo por varios modulos, dos quais tres desempenham funcoes fundamentais:
conflict manager, context model e conflict specification database. O modulo conflict manager deteta
conflitos utilizando a informacao guardada no context model e na conflict specification database. O con-
text model contem informacao sobre como o ambiente esta a ser afetado pela execucao das aplicacoes.
A conflict specification database contem descricoes das situacoes que sao consideradas conflitos pelas
aplicacoes ou pelos utilizadores.
Antes de uma aplicacao ser executada necessita de comunicar os seus efeitos sobre o contexto
ao conflict manager. O conflict manager determina entao se o seu efeito vai dar origem a um conflito.
Caso seja detetado um conflito o sistema tenta resolve-lo automaticamente. Uma forma simples de
resolver o conflito seria proibir a execucao da aplicacao. A outra forma, introduzida pela componente
PCOM, e usar uma configuracao alternativa da aplicacao para que ambas as aplicacoes possam ser
executadas. A PCOM e um ”componente-sistema” desenhado para sistemas computacionalmente
”pervasivos” com dispositivos de recursos restritos, que permite especificar contratos entre compo-
nentes. Assim, e possıvel compor aplicacoes dinamicamente a partir dos componentes disponıveis e
adapta-las a ambientes diferentes.
2.4 Analise Crıtica
Durante este capıtulo apresentamos uma perspetiva sobre a literatura mais relevante acerca do tema
da detecao e resolucao de conflitos. Foram tambem estudadas diferentes estrategias, semanticas
e de reconhecimento de habitos, para a definicao de automatismos para as casas inteligentes. A
15
Tabela 2.1: Comparacao entre sistemas em termos de mecanismo de resolucao de conflitos, aprendizagem au-tomatica de habitos e possibilidade de configuracao por parte dos utilizadores
Sistema Configuravel porvarios Utilizadores
Aprendizagemde Habitos
Mecanismo deResolucao de Conflitos
Configuracao deHabitacoes
Iglesias and Kastner (2013) Nao Sim PrioridadesBandara et al. (2015) Nao Sim PrevencaoKao and Yuan (2012) Sim Nao -
Rashidi and Cook (2008) Nao Sim -Chen et al. (2012) Nao Sim -
Resolucao deConflitos
Maternaghan and Turner (2013) - Nao Regras/PSRTuttlies et al. (2007) - Nao Prevencao
Camacho et al. (2014) - Nao Prioridades/PSRLuo et al. (2013) - Nao Regras
Armac et al. (2006) - Nao RegrasPark et al. (2005) - Nao Intencao dos Utilizadores
Tabela 2.1 apresenta uma visao global das solucoes analisadas, comparando-as em termos de me-
canismos de resolucao de conflitos, possibilidade de configuracao de preferencias (dispositivos e
acoes) por parte dos utilizadores e se apresentam algum mecanismo de reconhecimento de habitos
e respetiva configuracao automatica.
Dos mecanismos de resolucao de conflitos analisados, alguns sao baseados em problemas de
satisfacao de restricoes. Estes mecanismos permitem geralmente um alto nıvel de exatidao. No en-
tanto, sao pouco flexıveis devido a ser necessario satisfazer constantemente as restricoes impostas.
Isto acaba por causar situacoes, que em ultimo caso, obrigam o utilizador a ter de optar, pois por vezes
nao e possıvel satisfazer as suas preferencias. A escalabilidade relativa ao numero de utilizadores e
tambem uma contrapartida, pois caso exista um grande numero de utilizadores em conflito, com valores
de preferencia dıspares, torna-se complicado satisfazer cada um deles. Em alternativa, existem siste-
mas como os propostos por Maternaghan and Turner (2013); Armac et al. (2006), que se baseiam na
detecao de conflitos entre regras. Este tipo de abordagem permite um alto rigor e flexibilidade, devido
a quantidade de configuracoes que podem ser adicionadas. Contudo, a maioria destes mecanismos
utiliza algoritmos focados em modelos de regras, apenas considerando estas regras e ignorando os
varios utilizadores, intencoes e preferencias, aplicando sempre o mesmo tipo de resolucao. Estes
sistemas obrigam o utilizador a despender tempo a configurar individualmente cada regra e por ve-
zes e um requisito conhecer a linguagem utilizada. Sistemas baseados em regras representam um
nıvel de complexidade adicional para o uso diario dos utilizadores (Brush et al., 2011).
Uma abordagem baseada na prevencao dos conflitos e utilizada por Tuttlies et al. (2007). No entanto,
nem sempre e possıvel prever os conflitos, e caso existam preferencias contraditorias, por exemplo, so-
bre a intensidade luminosa, a resolucao do conflito tera de ser manual. A solucao proposta por Park
et al. (2005), considera as intencoes dos utilizadores envolvidos, tal como as suas preferencias, de
modo a melhor representar a sua vontade. Esta abordagem determina um valor que minimiza o custo
de todos os utilizadores envolvidos no conflito. Concluımos que esta solucao e a que mais se foca na
satisfacao dos utilizadores, visto ser simples de utilizar, permitir uma boa flexibilidade e escalabili-
16
dade ao nıvel do numero de utilizadores. Contudo, quando em conflito estao valores enumerados, tais
como varias estacoes de radio ou canais de TV nao existe uma resolucao de conflitos satisfatoria. O
estudo realizado revelou ainda que grande parte das solucoes de resolucao de conflitos, com excecao
do algoritmo desenvolvido por Bandara et al. (2015), nao considera existir uma hierarquia entre os
seus utilizadores, como tal, estas abordagens podem nao ser praticas quando existe realmente tal
hierarquia. Por outro lado, o mecanismo de resolucao de conflitos desenvolvido no estudo ignora por
completo os valores das alteracoes manuais antigas e obriga a que todas as alteracoes ”manuais” so-
bre as variaveis do ambiente sejam realizadas atraves de uma aplicacao e nao fisicamente.
Relativamente a configuracao semantica para as casas inteligentes, a solucao USHAS, Kao and
Yuan (2012), sofre do mesmo problema que muitas solucoes de resolucao de conflitos baseadas em
regras, uma vez que e necessario adicionar e configurar cada acao que se pretende automatizar.
A experiencia de utilizador destes sistemas e baixa e negligenciam a portabilidade, uma vez que
as regras sao especificas para cada habitacao. Por outro lado, os mecanismos de data mining e de
monitorizacao de habitos, tem vantagens interessantes relativamente as solucoes alternativas, pois
requerem pouca ou nenhuma configuracao uma vez que vao detetando padroes nas rotinas dos seus
utilizadores. Apesar disso, estes metodos nao sao totalmente eficazes caso se pretendam resultados
imediatos, como e possıvel conclui atraves da analise de diferentes estudos realizados Iglesias and
Kastner (2013); Dixit and Naik (2014). O estudo realizado por Iglesias and Kastner (2013) conclui que
sao necessarios cerca de 20 dias ate que o sistema apresente uma avaliacao fiavel dos habitos dos
utilizadores, produzindo bons resultados apenas quando os habitos ja se encontram bem tracados e
estaveis. Outro dos aspetos importantes prende-se com o facto do desempenho destes sistemas estar
fortemente dependente de outras variaveis. Variaveis como o tamanho da amostra, a frequencia
com que certas sequencias de habitos sao repetidas ou a quantidade de ruıdo existente (acoes
executadas no meio de sequencias repetitivas), podem influenciar consideravelmente a qualidade dos
resultados produzidos, como e possıvel observar no estudo realizado por Dixit and Naik (2014).
Em conclusao, podemos verificar que grande parte das solucoes sao unilaterais, ou seja, apenas
abordam uma parte do problema, nao oferecendo uma resposta suficientemente abrangente. Algumas
destas solucoes focam-se apenas na area de resolucao de conflitos, enquanto outras solucoes partem
do pressuposto que um espaco apenas e ocupado por um unico individuo, como e possıvel observar
na Tabela 2.1. Os sistemas apresentados por Iglesias and Kastner (2013); Bandara et al. (2015) sao os
unicos que oferecem uma solucao para ambos os problemas, mas apresentam as limitacoes referidas
anteriormente. A solucao que procuramos deve ser personalizavel e facil de usar, resolvendo conflitos
caso surjam. Pretendemos, como tal, desenvolver um sistema adaptavel aos utilizadores, capaz
de configurar uma habitacao automaticamente, e um mecanismo de resolucao de conflitos flexıvel,
escalavel e que retrate com precisao as preferencias dos seus utilizadores.
17
Capıtulo 3
O Sistema DomoBus
O DomoBus1 (Nunes, 2003) e uma framework desenvolvida no ambito academico, que tem como
principal objetivo integrar dispositivos de diferentes tecnologias, como sensores e atuadores. O Do-
moBus suporta interoperabilidade entre varios sistemas e permite uma alta escalabilidade relativa ao
numero de dispositivos. Consente a criacao e teste de novas ideias, sendo possıvel a sua expansao.
A solucao desenvolvida utiliza o sistema DomoBus que foi estendido ao nıvel do modelo de dados, de
modo a possibilitar a introducao dos diversos perfis de utilizador.
3.1 Arquitetura
No que diz respeito a arquitetura, um sistema DomoBus e composto por dois nıveis principais, o
nıvel de controlo e o nıvel de supervisao, tal como ilustrado na Figura 3.1.
O DomoBus apresenta um modelo de dados generico e flexıvel (Nunes, 2004), permitindo represen-
tar qualquer dispositivo e as suas propriedades. Este modelo fornece suporte a interoperabilidade entre
tecnologias de automacao residencial, sendo possıvel desta forma usufruir de multiplas solucoes como
X10 (Electronics, 1975), KNX (Association, 1990), DomoBus Control Network (DCN), entre outras, na
mesma habitacao.
Para permitir a comunicacao entre diferentes tecnologias, e necessario mapear o modelo generico
de dados para cada tecnologia domotica em particular. Esta tarefa e realizada por dois elementos
fundamentais a arquitetura, o gateway de software, presente em cada modulo de supervisao e ilustrado
na Figura 3.2, e o gateway de hardware.
A comunicacao com o sistema domotico e realizada utilizando um servico de mensagens baseado
em sockets. De modo a possibilitar a interacao entre dispositivos existem essencialmente tres tipos de
mensagens: GET, SET e NOTIFY, explicados em maior detalhe na seccao 3.4.1www.domobus.net
18
Uma das vantagens do sistema DomoBus e a possibilidade de acesso remoto. Esta caracterıstica
permite aos utilizadores acederem remotamente aos dispositivos da sua habitacao, a partir de qualquer
localizacao, desde que disponham de acesso a rede Internet. O sistema possui ainda uma interface
grafica de utilizador (alto nıvel), para que de uma forma intuitiva se possa monitorizar e controlar dispo-
sitivos a partir de um tablet por exemplo (como ilustrado na Figura 3.2).
O nıvel de Supervisao e composto por Modulos de Supervisao (SM). Um edifıcio ou habitacao
podera contar com multiplos SM caso se justifique, permitindo uma supervisao distribuıda e assim
oferecendo qualidades como fiabilidade e performance. Os SM sao responsaveis pela gestao e su-
pervisao do sistema. Estes recebem informacao das diferentes tecnologias domoticas e processam-na
de acordo com as regras programadas, enviando as respetivas tecnologias os comandos apropriados.
Cada SM pode monitorizar varias tecnologias domoticas. Os SM sao constituıdos por supervisores
(software) que executam diversas tarefas. Os supervisores tem como objetivo o suporte a definicao
do comportamento desejado para uma habitacao. O modelo assenta numa nocao de ”cenario”, que
Figura 3.1: Arquitetura nıvel de Controlo DomoBus.
19
pode ser por exemplo ”Regar Jardim” ou ”Levantar de manha” (detalhado na seccao 3.2). Ao nıvel de
supervisao, existe ainda um Home Server (HS), com acesso a rede internet que permite interacao com
outros sistemas. As acoes de supervisao do sistema sao definidas e controladas pelo HS, que oferece
ao utilizador uma interface grafica para o poder fazer. Para alem disso, o servidor podera ser desligado
nao afetando as acoes de controlo e automacao do sistema, uma vez que os SMs fazem download das
acoes, podendo realizar as tarefas normalmente. O HS permite uma centralizacao da configuracao do
sistema, de forma a simplificar o seu acesso e gestao.
Figura 3.2: Arquitetura nıvel de Supervisao DomoBus.
20
3.2 Modelo de dados
Como referido, de forma a representar qualquer dispositivo, independentemente da tecnologia, o
DomoBus apresenta um modelo de dados generico. Com este modelo e possıvel representar uma
habitacao e as suas divisoes (Figura 3.3), os dispositivos presentes nessa habitacao (Figura 3.4), e
tambem os comportamentos do sistema, conhecidos por cenarios (Figura 3.5).
Figura 3.3: UML do modelo de dados de uma habitacao (Nunes, 2004).
Neste modelo uma habitacao podera ter um ou mais pisos. Cada um destes pisos pode ter uma
ou mais divisoes, estas divisoes podem ser divisoes concretas como um quarto ou uma sala, ou entao
zonas definidas pelo utilizador. Cada divisao podera ainda ter associados varios dispositivos, no entanto
um dispositivo esta presente apenas numa unica divisao. Este modelo permite ao utilizador definir
zonas de interesse numa habitacao de forma simples e objetiva.
Figura 3.4: UML do modelo de dados de um dispositivo (Nunes, 2004).
Na Figura 3.4 podemos observar a estrutura utilizada pelo sistema DomoBus para representar um
dispositivo e as suas propriedades.
A entidade TipoDispositivo tem como funcao abstrair os dispositivos de um determinado tipo, por
exemplo, candeeiros, televisores e acondicionados. A sua utilizacao permite evitar repeticoes caso
21
existam multiplos dispositivos com as mesmas caracterısticas, por exemplo, varios televisores. A classe
Servico, associada a entidade TipoDispositivo, permite agrupar tipos de dispositivos que partilham
uma area funcional, por exemplo climatizacao, iluminacao, entretenimento, etc. Cada TipoDispositivo e
caracterizado por um conjunto de propriedades (TipoPropriedade), essas propriedades podem ser, no
caso de um candeeiro, o estado ligado/desligado e a sua intensidade luminosa, no caso de um televisor,
o estado ligado/desligado, o volume e o canal. A interacao com os dispositivos e feita atraves da leitura
e escrita nas suas propriedades. O acesso a essas propriedades pode estar limitado pelo privilegio dos
utilizadores.
O TipoPropriedade tem como principal objetivo reutilizar propriedades que sao comuns a multiplos
dispositivos como por exemplo, o estado Ligado/Desligado. Para cada tipo de propriedade e possıvel
definir um modo de acesso que pode ser so leitura, so escrita ou leitura e escrita. O TipoPropriedade
pode assumir tres categorias diferentes de valores:
• Escalar - identifica um valor inteiro que varia entre um mınimo (ValorMin) e um maximo (Valor-
Max). Esse valor pode tambem ter um certo tipo de unidades (Celsius, Watt, Lux), pode corres-
ponder a uma percentagem (entre 0 e 100 por exemplo) ou simplesmente nao possuir unidades.
• Enumerado - E utilizado caso a propriedade em questao tenha um conjunto limitado de valores.
Um enumerado corresponde a pares ”nome, valor”. No caso do funcionamento de um ar condi-
cionado por exemplo, pode-se considerar um conjunto bem definido de estados: desligado (0),
aquecer (1) e arrefecer (2).
• Vetor - O tipo vetor e usado caso seja necessario representar uma longa cadeia de carateres, ou
algo que nao seja um escalar ou um enumerado.
O modelo de abstracao de dispositivos utilizado e notoriamente flexıvel e pratico pois permite fa-
cilmente adicionar novos dispositivos. Suponhamos que um utilizador pretende introduzir um novo
dispositivo no sistema, por exemplo um candeeiro de cozinha. Caso ja exista no sistema um TipoDis-
positivo Candeeiro com as propriedades Ligar/Desligar (enumerado) e Intensidade Luminosa (escalar),
apenas e necessario referencia-lo.
Para alem dos modelos apresentados o DomoBus apresenta ainda um suporte a definicao do com-
portamento para uma habitacao (Figura 3.5). Essencialmente este modelo, baseado na nocao de
cenario, pode ser um conjunto de accoes definidas pelo utilizador, por exemplo, ”Levantar de manha”,
”Regar jardim” ou ”Ver Televisao”. Resumidamente, um cenario corresponde a uma expressao: ”IF
condicao THEN lista-acoes” onde o termo ”condicao” pode ser uma expressao complexa que pode
envolver o tempo ou o valor de qualquer propriedade de um dispositivo. A expressao e construıda re-
correndo aos operadores logicos ”OR” e ”AND”. A ”lista-acoes” e uma sequencia de acoes, em que
cada uma consiste na atribuicao de um valor a uma propriedade de um dispositivo. A utilizacao de
22
Figura 3.5: UML do modelo de dados de um cenario (Nunes, 2004).
acoes de desativacao e facultativa. As acoes de desativacao sao uteis caso, por determinado motivo,
se pretenda desativar um cenario. Um cenario pode ser suspenso, caso o utilizado assim o entenda e
reativado posteriormente.
3.3 Linguagem de Especificacao
Para representar o modelo de dados e utilizada uma linguagem de especificacao propria, no for-
mato Extensible Markup Language (XML), onde cada ficheiro contem os elementos necessarios para
representar a estrutura da habitacao, os dispositivos e as respetivas propriedades. Esta linguagem e
flexıvel e permite a descricao de qualquer tipo de sistema, com qualquer combinacao de dispositivos
e permitindo a descricao detalhada da estrutura da casa onde o sistema esta instalado. A linguagem
de especificacao pode ser utilizada em diferentes sistemas e pode ser complementada quando for
necessario, sendo para isso apenas necessario estender o ficheiro XML. Podem ser definidos novos
dispositivos a partir dos tipos de dispositivos presentes. Diversas aplicacoes conseguem utilizar esta
linguagem, uma vez que e generica, utilizando apenas os elementos necessarios a sua execucao.
Seguidamente sao apresentados exemplos dos elementos mais importantes presentes na configura-
cao XML de um sistema DomoBus:
• Habitacao:
Na Listagem 3.1 e apresentada a estrutura de uma habitacao, constituida por um piso, o ”res-do-
chao”, e duas divisoes, uma sala e uma cozinha.
Listagem 3.1: Exemplo da estrutura de uma habitacao
a um maior investimento por parte do utilizador. Pode ser util, por exemplo, caso o utilizador
pretenda definir condicoes particulares para trabalhar no escritorio.
A tabela 4.1 sintetiza as principais caracterısticas dos perfis.
4.4 Deteccao de Conflitos
Para detetar conflitos entre utilizadores e apenas necessaria conhecer a sua localizacao. Para o
efeito podem ser utilizados dispositivos capazes de determinar a localizacao do utilizador, como por
exemplo smartwatches, smartphones ou algum tipo de sensores. Sabendo essa informacao e possıvel
determinar se os perfis/preferencias dos utilizadores que estao num espaco partilhado se encontram
em oposicao e imediatamente aplicar o mecanismo de resolucao de conflitos.
4.5 Estrategia para Resolucao de Conflitos
A estrategia de resolucao de conflitos e baseada na solucao apresentada por Park et al. (2005) e
tem em consideracao os nıveis de preferencia dos utilizadores para cada uma das areas de preferencia.
Na resolucao de conflitos, o valor final de cada propriedade e calculado separadamente. Por exemplo, o
valor que o sistema atribui a propriedade intensidade luminosa e calculado em separado do valor a atri-
buir a propriedade temperatura. Foi introduzido um novo parametro a equacao original que representa
a hierarquia entre utilizadores. Uma vez que todos os utilizadores dispoem de um nıvel de acesso, este
funciona como hierarquia, garantindo um maior impacto na resolucao de conflitos aos utilizadores com
maior nıvel de acesso.
Suponhamos o seguinte cenario: O nıvel de preferencia do Joao para a area de iluminacao e ”muito
alto” (5), sendo o seu valor de preferencia para a intensidade luminosa 350 lux. No caso da Ana, o nıvel
de preferencia para a area de iluminacao e ”baixo” (2) e prefere a intensidade luminosa a 200 lux. Nesta
situacao o nıvel de acesso do Joao e 1, inferior ao da Ana que e 2. Em sıntese, podemos observar que
o Joao e bastante exigente no que diz respeito a intensidade luminosa, enquanto a Ana nao o e tanto.
1Uma vez que este tipo de perfil permite lidar com dispositivos e divisoes especificas a cada habitacao, so e possıvel mantera funcionalidade para multiplas habitacoes caso se utilize o TipoDivisao (introduzido na seccao 4.7).
30
Ambos os utilizadores encontram-se os na mesma divisao e possuıam privilegios diferentes, sendo que
neste cenario a Ana e o utilizador com o maior nıvel de acesso. A solucao para a equacao rc, baseada
no trabalho apresentado por Park et al. (2005), sera o que o sistema ira aplicar a propriedade, neste
caso intensidade luminosa. As variaveis NpUa e NpUb representam o nıvel de preferencia do utilizador
A e B, respetivamente, sobre a area de preferencia. Ja as variaveis PrivUa e PrivUb correspondem ao
nıvel de acesso ou privilegio que os utilizadores A e B detem perante o sistema. As variaveis PrefUa
e PrefUb sao os valores que os utilizadores A e B, respetivamente, preferem para a propriedade. A
equacao permite a adicao de mais utilizadores.
rc =NpUa× PrivUa× PrefUa+NpUb× PrivUb× PrefUb
NpUa× PrivUa+NpUb× PrivUb= (4.1)
=5× 1× 350 + 2× 2× 200
5× 1 + 2× 2' 283 .
O valor dado pela solucao da equacao, sera o que o sistema ira aplicar a propriedade intensidade
luminosa, concretamente neste caso, 283 lux.
Por outro lado, em situacoes que existem enumerados, tais como, canais de televisao, estacoes de
radio, tipos de musica favoritos, a abordagem tera de ser algo diferente. Propoe-se entao que estas
situacoes sejam resolvidas com recurso a uma tabela.
Imaginemos para isso um cenario onde o Joao tem o nıvel de preferencia ”muito alto”(5) sobre a area
de entretenimento e prefere o canal TVI. O Pedro, com nıvel de preferencia ”baixo”(2), sobre a mesma
area, prefere o canal SIC. Considere-se que ambos os utilizadores se encontram na mesma divisao e
que os seus nıveis de acesso sao 2 e 1 para o Joao e o Pedro respetivamente. E possıvel atribuir a
cada um dos canais disponıveis um valor, que corresponde a multiplicacao do nıvel de preferencia do
utilizador pelo seu nıvel de acesso, como exemplificado na Tabela 4.2. Por simples analise da tabela
conclui-se que o canal escolhido e, portanto, a TVI.
Tabela 4.2: Matriz decisao Canal TV
SIC TVI RTP SICN SPORTVGrau 2 10 0 0 0
Caso entre na mesma divisao um terceiro utilizador, com nıvel de acesso 2, um nıvel de preferencia
”alto”(4) sobre o entretenimento e que prefira tambem o canal SIC, entao, o ”Grau”de preferencia global
para o canal de TV SIC e alterado para 10. Isto vai causar uma igualdade de ”Grau”, entre os canais SIC
e TVI. Nesta situacao, o sistema dara prioridade ao canal de TV que tem o maior numero de utilizadores
associado. O que para este caso, seria a SIC. Por ultimo, caso exista tambem uma igualdade em relacao
ao numero de utilizadores, sera dada prioridade a preferencia do utilizador que esta ha mais tempo na
divisao.
31
4.6 O Refinar de um Perfil
De modo a melhor representar as mudancas nas preferencias de um utilizador, ao longo do tempo,
e util poder dispor de um mecanismo de ajustamento dinamico do respetivo perfil. Este mecanismo que
pode estar ou nao ativo, permite que ao ser detetada uma alteracao manual numa propriedade, seja
desencadeado um ajustamento do perfil, recalculando o valor para a propriedade alterada. Assim, sem-
pre que um utilizador modificar manualmente uma dada propriedade, o sistema ira automaticamente
atualizar o seu perfil. No ajuste realizado ao perfil sao considerados a magnitude da alteracao realizada
e a quantidade de ocasioes que ja foi alterada essa mesma propriedade. Alterar a propriedade uma vez
nao deve significar muito, mas alterar continuamente significa que o utilizador nao esta satisfeito com o
valor da propriedade e a alteracao deve ser mais significativa. Para atingir este fim propoe-se o uso da
seguinte funcao:
ap = ln (kn) (4.2)
Figura 4.2: Funcao ln(x)
Nesta funcao, k representa o valor da alteracao manual realizada pelo utilizador e n o numero de
alteracoes realizadas sobre a propriedade. A variavel n comeca em 1 visto que o refinamento e apenas
realizado aquando da primeira alteracao sobre uma propriedade. A funcao usada tem um crescimento
logarıtmico, que e gradual, de forma a nao alterar drasticamente as preferencias do utilizador. A esta-
bilidade do valor de uma propriedade deve tambem ser tido em conta. Para tal, a medida que o tempo
passa, o valor da variavel n sera decrementado automaticamente, reduzindo o peso de alteracoes que
ocorreram ha um tempo significativo. Deste modo apenas serao consideradas alteracoes que corres-
pondem a ajustes frequentes.
O refinamento de perfil pode tambem ser desativado e ativado, como referido, sendo tambem
possıvel recuperar o perfil original. Nas situacoes que existem multiplos utilizadores na mesma di-
visao, o mecanismo de reajuste e desativado por nao ser possıvel identificar o utilizador que realizou a
alteracao.
32
4.7 Extensao do Modelo de Dados DomoBus
O trabalho realizado passou por estender e modificar a linguagem de especificacao XML e o modelo
de dados do sistema DomoBus (Nunes, 2004). Foi como tal necessario introduzir novos atributos e ele-
mentos de forma a permitir expressar os perfis dos utilizadores. Um dos novos elementos introduzidos
ao modelo de dados foi o TipoDivisao, que permite agrupar diferentes divisoes, como por exemplo todas
as casas de banho ou quartos, possibilitando o utilizador explicitar diferentes preferencias consoante
o tipo de divisao. A cada divisao devera ser sempre associado um tipo. A introducao deste elemento
permite ainda que um perfil possa ser carregado noutra habitacao. O utilizador pode, por exemplo,
utilizar o seu perfil na casa de um amigo, ou na sua casa de ferias.
Foi adicionado tambem o conceito de area de preferencia ao modelo de dados do sistema DomoBus.
Os nomes atribuıdos as areas de preferencia sao escolhidos pelos utilizadores e e possıvel criar novas
areas de preferencia, como referido anteriormente. Caso seja necessario introduzir uma nova area de
preferencia, como por exemplo a seguranca, basta indicar o seu nome e identificador unico no ficheiro
XML de configuracao da habitacao. Para adicionar uma associacao entre uma area de preferencia e
uma Propriedade e so adicionar o identificador da area de preferencia a Propriedade pretendida.
4.8 Funcionamento da Solucao e Tecnologias
O funcionamento da solucao final encontra-se detalhado na Figura 4.3.
Figura 4.3: Funcionamento da Solucao
A solucao e composta por dois componentes principais. O Gestor de Perfis (Profile Manager ) e a
33
ferramenta responsavel pela criacao e gestao dos perfis de utilizado. Os utilizadores interagem dire-
tamente com a ferramenta atraves de uma interface grafica que simplifica todas as operacoes. Existe
ainda um segundo componente responsavel por aplicar e conectar os mecanismos da solucao. Este
segundo componente destina-se a aplicar os perfis de utilizador corretamente, resolver conflitos entre
preferencias e aplicar otimizacoes aos perfis. O resultado produzido sao acoes sobre o ambiente em
que se encontram os utilizadores. A persistencia de dados e alcancada atraves da utilizacao de um
ficheiro XML, de onde sao lidos e guardados os perfis de utilizador.
Para o desenvolvimento da solucao foi escolhida a linguagem Java e usado o software NetBeans
IDE. Foram utilizadas as bibliotecas JavaFX e JFoenix juntamente com o software auxiliar Scene Buil-
der, estas tecnologias permitem simplificar a criacao da interface de utilizador. A componente grafica da
aplicacao utiliza uma biblioteca baseada no Material Design disponibilizado pela Google, este design e
uniformizado e semelhante ao que encontramos em tablets ou smartphones, desta forma facilitando a
utilizacao por parte de qualquer utilizador. O Gestor de Perfis funciona em Windows, Mac OS X e Linux.
34
Capıtulo 5
Implementacao da solucao
Durante os capıtulos anteriores apresentamos e discutimos os trabalhos relevantes para o pro-
blema apresentado. A solucao idealizada utiliza metodologias que tornam possıvel criar uma solucao
completa, centrada nos utilizadores e nas suas preferencias. Foi necessario tirar partido de diferentes
tecnologias para criar uma interface consistente e simples.
Este capıtulo descreve em detalhe a implementacao da solucao que tem como objetivos principais:
(1) desenvolver uma interface grafica para os utilizadores gerirem os seus perfis e (2) testar a utilizacao
dos perfis de utilizador, mecanismo de resolucao de conflitos e refinamento dos respetivos perfis em
cenarios concretos. Por esta razao elaboramos duas ferramentas, o Gestor de Perfis, que permite aos
utilizadores definir as suas preferencias e estabelecer os seus perfis, e um simulador, cuja finalidade e
validar a efetividade dos perfis e dos respetivos mecanismos.
5.1 Gestor de Perfis
O Gestor de Perfis e um software desenvolvido para os habitantes de uma casa inteligente poderem
definir, editar e visualizar os seus perfis de utilizador. Uma vez que a finalidade desta dissertacao
e desenvolver uma solucao centrada nos utilizadores, um dos pontos de destaque da ferramenta e
a usabilidade. A sua interface intuitiva e pratica permite aos utilizadores uma rapida aprendizagem,
tornando eficiente a criacao de perfis. As funcionalidades centrais da aplicacao sao: controlo de acesso
aos perfis, gestao de utilizadores e gestao de perfis de utilizador.
No Anexo A e possıvel consultar o Manual de Utilizador do Gestor de Perfis, que contem uma breve
descricao da aplicacao, os requisitos necessarios e ainda um tutorial sobre todas as funcionalidades da
ferramenta e como as usar.
35
5.1.1 Login
A fim de garantir que todos os utilizadores podem definir e aceder autonomamente aos seus perfis,
foi implementada a funcionalidade de controlo de acessos. O utilizador devera introduzir as suas cre-
denciais, pressionar o botao de ”LOGIN” e seguidamente tera acesso a sua area de gestao de perfis.
No entanto, se as credenciais nao corresponderem a uma conta existente, sera apresentada uma men-
sagem de alerta impedindo o utilizador de utilizar a aplicacao. O menu de Login (ver Figura 5.1) e a
primeira janela que o utilizador encontra quando inicia a aplicacao.
Figura 5.1: Login
5.1.2 Visualizar, Criar e Remover Utilizadores
O menu de gestao de utilizadores (ver Figura 5.2 (a)) apenas pode ser acedido pelo administrador do
sistema ou utilizadores com nıvel de acesso maximo (10). Este menu da a possibilidade de visualizar,
criar e remover os utilizadores do sistema DomoBus, assim como os seus respetivos perfis.
Quando a pagina de criacao de um novo utilizador e acedida (ver Figura 5.2 (b)), o administrador ou
utilizador privilegiado pode criar uma nova conta introduzindo tres informacoes basicas: nome, palavra-
passe e nıvel de acesso do novo utilizador. O nıvel de acesso corresponde a um valor entre 1 e 10 e
possibilita definir uma hierarquia entre os utilizadores, por exemplo pai e filho. Todos estes campos sao
obrigatorios, se ao criar um novo utilizador algum destes campos for esquecido, ira ser apresentada
uma mensagem de alerta, o mesmo acontece caso o nome de utilizador ja exista.
36
(a) Gestao de Utilizadores (b) Criar Novo Utilizador
Figura 5.2: Gestao de Utilizadores e Janela de Login.
5.1.3 Gerir Perfis de Utilizador
Depois de realizar o login com sucesso, os utilizadores regulares (nıvel de acesso de 1 a 9) ace-
dem directamente a janela de gestao de perfis (ver Figura 5.3). Aqui os seus perfis de utilizador sao
apresentados na forma de uma lista, ordenados pelo respectivo tipo de perfil.
Figura 5.3: Gestao de Perfis
Na barra do lado direito da lista existem multiplos botoes, nomeadamente: New Profile, Show Profile,
Edit Profile e Delete Profile. Os seus nomes sao intuitivos. O botao ”New Profile” permite criar um
37
novo perfil, redirecionando imediatamente o utilizador para o menu de escolha do tipo de perfil (ver
Figura 5.4 (a)). O botao ”Show Profile” permite visualizar as preferencias do perfil selecionado. O
botao ”Edit Profile” da a possibilidade de editar as preferencias do perfil. Finalmente, o botao ”Delete
Profile” permite remover o perfil selecionado.
(a) Tipo de Perfil (b) Areas de Preferencia
Figura 5.4: Definir um novo perfil de utilizador
No processo de criacao de um novo perfil (Figura 5.4 (a)), o utilizador deve primeiro designar o
tipo de perfil que quer configurar: Generico, Especıfico ou Actividade. No caso de selecionar o Perfil
Generico (um por utilizador) sera incentivado a configurar uma ou mais areas de preferencia (ver Figura
5.4 (b)). Para definir uma nova Actividade o processo e semelhante ao do Perfil Generico, a diferenca
esta no facto da Actividade ter associado tambem um nome, para facilitar a sua identificacao. Por ultimo,
o Perfil Especifico devera incluir tambem uma divisao ou varias divisoes (incluindo o TipoDivisao), onde
aplicar as preferencias.
Para cada uma das areas de preferencia que pretende configurar, o utilizador devera escolher um
nıvel de preferencia entre 1 e 5 (Figura 5.5 (a)), activar/desactivar as propriedades que desejar e guardar
as alteracoes. No final, para criar o perfil e so pressionar o botao verde ”Create Profile” (Figura 5.4 (b)),
voltando para o menu de gestao de perfis.
5.1.4 Documentacao e Ajudas
O Manual de Utilizador (Anexo A) explica detalhadamente o Gestor de Perfis e como os utilizadores
deverao usar as suas respetivas funcionalidades. E aconselhada a leitura do manual antes de utilizar a
aplicacao de modo a agilizar o processo de aprendizagem.
Para alem da documentacao produzida, todos os menus dispoem ainda de uma ajuda especializada
(ver Figura 5.5 (b)). Elementos da interface, como e o caso do nıvel de preferencia (Figura 5.5 (a)),
38
podem ser desconhecidos por alguns utilizadores caso ignorem a leitura do manual. Por essa razao, ao
lado destes elementos existe uma informacao ou quick tip que contextualiza imediatamente o utilizador.
(a) Configuracao de uma area e quick tip (b) Menu de Ajuda
Figura 5.5: Configuracao de Area de Preferencia e Ajudas.
5.2 Simulador
O principal objetivo do simulador e aplicar os mecanismos conceptualizados no capıtulo anterior e
garantir a sua utilidade em cenarios reais. O simulador assegura tres aspetos fundamentais. Certifi-
car a correta utilizacao, de acordo com a situacao, dos diferentes tipos de perfis configurados pelos
utilizadores. Quando multiplos utilizadores partilham o mesmo espaco, confirmar que o mecanismo
de resolucao de conflitos adotado e realmente eficaz. Por ultimo, garantir que os perfis se adaptam
continuamente as mudancas nas preferencias dos seus utilizadores.
5.2.1 Principais Funcionalidades
O simulador permite aos utilizadores explorar multiplos cenarios. E possıvel obter e comparar
informacoes sobre o estado actual dos perfis, propriedades e dispositivos da habitacao. As funcio-
nalidades principais oferecidas sao as seguintes:
• Movimentacao de Utilizadores - concretamente um dos pontos centrais do simulador. Esta funci-
onalidade da a possibilidade de movimentar em tempo real e para qualquer divisao os utilizadores
do sistema DomoBus. A partir desta funcionalidade podem ser exploradas inumeras combinacoes
entre as preferencias de utilizadores e observar a aplicacao dos restantes mecanismos;
• Controlo - o simulador permite a qualquer momento ativar e desativar as Actividades configuradas
pelos utilizadores assim como o mecanismo de refinar os perfis;
39
• Informacoes - sao apresentadas varias informacoes sobre o estado da habitacao, das divisoes,
dos dispositivos e dos perfis. Algumas das informacoes indicadas sao, por exemplo, o historico
dos valores de uma propriedade, os utilizadores presentes numa divisao e os seus nıveis de
permissao e para cada utilizador o perfil que se encontra ativo;
• Estatısticas dos Perfis - para cada perfil refinado e possıvel analisar o grafico correspondente
as alteracoes automaticas realizadas sobre o perfil, de modo a acompanhar a sua evolucao;
• Carregar cenario - para agilizar a simulacao de uma situacao real e possıvel ler directamente um
ficheiro com as instrucoes para criar um cenario pretendido. Um cenario pode variar relativamente
ao numero de utilizadores, divisao, Atividades ativas entre outros;
• Comunicacao com o sistema DomoBus - atraves da utilizacao do protocolo de comunicacao do
sistema DomoBus a nossa aplicacao comunica diretamente com outras aplicacoes que utilizam o
mesmo protocolo. Isto e especialmente relevante porque podemos, por exemplo, ver em tempo
real informacoes disponibilizadas por outras aplicacoes.
5.2.2 Interface do Simulador
A interface grafica do simulador encontra-se apresentada na Figura 5.6. Quando o simulador e inici-
ado, os utilizadores vao encontrar informacoes sobre a localizacao atual dos habitantes, os dispositivos
e as propriedades presentes numa determinada divisao.
Figura 5.6: Interface grafica do simulador
40
O menu inicial encontra-se dividido em quatro areas fundamentais:
1. Na primeira area existem duas componentes importantes do simulador: a barra de ferramentas
e o separador das divisoes. No topo superior e possıvel observar a barra de ferramentas que
permite aceder a varias funcionalidades, como por exemplo ativar e desativar o mecanismo para
refinar um perfil, verificar a evolucao do perfil ao longo do tempo ou sair do simulador. Mais abaixo
encontra-se o separador de divisoes, cujo objetivo e oferecer informacoes sobre cada divisao em
particular e movimentar qualquer utilizador para essa mesma divisao;
2. Os dois paineis do lado esquerdo oferecem informacao sobre quais os utilizadores estao presen-
tes na divisao e quais se encontram noutros locais da casa. Ao arrastar o seu nome e possıvel
simular a sua movimentacao;
3. Em destaque encontra-se o painel que contem o historico de alteracoes realizadas sobre uma
dada propriedade. Isto e particularmente util pois permite analisar entradas e saıdas de utilizado-
res e a diferenca entre as suas preferencias. Na barra de menus existe uma opcao que permite
alterar a propriedade a seguir;
4. Por fim, na zona inferior do simulador existem tres paineis informativos. O painel mais a esquerda
informa quem sao os utilizadores com o maior nıvel de permissao presentes na divisao, conse-
quentemente, as suas preferencias terao mais impacto na resolucao de conflitos. O painel central
”Last Changes” informa da ultima alteracao realizada sobre uma propriedade. Ja o painel ”Devi-
ces” , do lado direito, informa quais sao os dispositivos presentes na divisao e as suas respetivas
propriedades.
5.2.3 Aplicar os Perfis de Utilizador
A aplicacao dos perfis de utilizador numa qualquer divisao faz uso da funcionalidade de movimen-
tacao de utilizadores. Quando um utilizador entra na divisao e aplicado o perfil que estiver configurado,
ou seja, no caso de o utilizador ter apenas um Perfil Generico, o sistema configura automaticamente
todos os dispositivos da divisao para satisfazer as preferencias desse utilizador da melhor maneira
possıvel. No caso de o utilizador ter definido um Perfil Especifico para uma determinada divisao, sempre
que entrar sao aplicadas as preferencias que definiu, tambem de forma automatica. Adicionalmente,
caso o utilizador pretenda iniciar espontaneamente uma Atividade numa certa divisao da habitacao,
podera faze-lo recorrendo ao menu especıfico criado para o efeito (ver Figura 5.7 (a)).
Para movimentar um qualquer utilizador para a divisao que se pretende, basta arrastar o seu nome
para a lista de utilizadores na divisao (”Users in the Kitchen” na Figura 5.6) e para remover apenas e
necessario realizar a operacao inversa.
41
(a) Informacoes de Utilizador (b) Propriedade Disponiveis
Figura 5.7: Menu de utilizador e configuracoes.
5.2.4 Mecanismo para Resolucao de Conflitos
Como abordado no capıtulo anterior, o mecanismo de resolucao de conflitos entre utilizadores e
aplicado automaticamente. Para tal, e apenas necessario movimentar dois ou mais utilizadores com
as mesmas preferencias para a mesma divisao. Caso efetivamente se queiram confirmar os resultados
produzidos pela resolucao, existem duas possibilidades. Pode ser consultada a aplicacao Supervisor,
desenvolvida no ambito do sistema DomoBus, e comprovar os valores das propriedades nos respetivos
dispositivos presentes no sistema. Como alternativa e possıvel consultar diretamente os valores das
propriedades no simulador, atraves do painel ”Devices”.
5.2.5 Mecanismo para Refinar um Perfil
Para utilizar o mecanismo de refinar um perfil e fundamental realizar duas acoes. Em primeiro,
o utilizador devera ativar o mecanismo, isto e realmente necessario pois nem sempre os utilizadores
pretendem ver os seus perfis alterados face ao que configuraram inicialmente. Como tal, para ativar
e preciso pressionar o botao ”Refinement Mechanism”, presente no menu ”Simulator ” da barra de
ferramentas. Para desativar e exatamente o mesmo processo de ativar mas o botao devera marcar o
mecanismo como desativado. Seguidamente, o utilizador devera simular a alteracao manual da pro-
priedade de um dispositivo. Para realizar esta acao e necessario utilizar uma ferramenta para o efeito
como e o caso do Supervisor, que posteriormente notifica a nossa aplicacao sobre qualquer alteracao
manual realizada. De notar que este mecanismo apenas funcionara caso exista apenas um utilizador na
divisao de modo a identificar claramente quem desencadeou a alteracao. Consequentemente, depois
de detetar que foi realizada uma alteracao manual, ira ser aplicado o ajuste ao perfil.
O simulador permite ainda seguir todas as alteracoes manuais e os respetivos ajustes aos perfis.
Concretamente, existe uma funcionalidade que produz um grafico caso o perfil do utilizador seja refi-
42
nado (ver Figura 5.8). Para assegurar uma boa visibilidade dos dados e tracado um grafico por cada
propriedade de um perfil ajustada. Cada grafico inclui duas linhas. A linha preta a tracejado repre-
senta o historico das alteracoes manuais realizadas pelo utilizador, e a linha cor de laranja corresponde
aos ajustes automaticos efetuados (pelo mecanismo) sobre a propriedade do perfil. O eixo dos X cor-
responde ao numero de alteracoes realizadas manualmente sobre a propriedade e no eixo dos Y os
valores que a propriedade tomou. Ambos estes fatores sao utilizados na equacao para refinar um perfil.
Figura 5.8: Grafico acerca das alteracoes ao perfil
No caso especifico da Figura 5.8, por analise do grafico podemos constatar que o valor da propri-
edade ”Volume” foi alterado um numero razoavel de vezes (precisamente 9), para um valor sempre
superior ao definido originalmente para o perfil. Isto vai obviamente traduzir-se num aumento do valor
da propriedade no perfil. No entanto, a excecao ocorre quando o utilizador altera manualmente e dras-
ticamente o valor da propriedade para um valor inferior ao do seu perfil, na quarta alteracao manual.
Nesta situacao a propriedade ”Volume” do perfil vai sofrer um ajuste nao muito acentuado, uma vez
que o utilizador apenas realizou uma alteracao espontanea. Este resultado que vai de encontro ao
esperado durante a concecao do mecanismo.
43
Capıtulo 6
Avaliacao
No capitulo anterior apresentamos duas ferramentas, o Gestor de Perfis e o Simulador, responsaveis
por colocar em pratica todos os conceitos associados aos perfis. Uma vez que o envolvimento de
utilizadores reais e fundamental no desenvolvimento de uma solucao centrada nos utilizadores, foram
formalizados dois metodos de avaliacao distintos.
Em primeiro lugar, para validar a aplicacao dos perfis de utilizador, do mecanismo de resolucao de
conflitos e o refinar de um perfil sao utilizados diferentes cenarios praticos, que tornam possıvel enten-
der a utilidade de cada funcionalidade. Seguidamente, foi conduzida uma serie de avaliacoes com um
grupo de utilizadores. O principal objetivo e recolher informacao sobre as expectativas dos utilizadores,
opinioes e dificuldades a interagir com o Gestor de Perfis e garantir que os principais objetivos foram
alcancados (relativamente a usabilidade e a experiencia de utilizador). Estes dois metodos de avaliacao
realizados permitem validar a completude e eficacia da solucao.
6.1 Cenarios de Utilizacao
Os diferentes cenarios de utilizacao propostos correspondem a alguns exemplos praticos de aplicacao
dos perfis de utilizador e tecnicas subjacentes. Estes cenarios descritos de seguida permitem entender
as funcionalidades da solucao, assim como compreender a sua utilidade:
• Cenario 1 (Figura 6.1): A ’Ana’, de manha antes de ir para o trabalho, gosta de ver as noticias
acerca do transito no canal de TV SIC enquanto prepara o pequeno-almoco na cozinha. Apos ter
percebido qual o percurso mais rapido para chegar ao trabalho, desloca-se para a casa de banho,
onde gosta da intensidade luminosa a 90% e de ouvir a radio M80.
O primeiro cenario evidencia a variedade de preferencias que um utilizador pode ter em diferentes
locais da habitacao. Estas preferencias (por exemplo a intensidade luminosa ou estacao de radio)
44
Figura 6.1: Aplicacao de um perfil
podem variar dependendo do contexto. Como tal, torna-se util a utilizacao de diferentes tipos de perfis
de utilizador de acordo com a situacao.
• Cenario 2 (Figura 6.2): O ’Joao’ encontra-se na sala a ler um livro e comeca a passar um filme
do seu interesse. Como tal, o ’Joao’ seleciona a atividade ”Ver Filme” que reconhece as suas
preferencias de iluminacao, temperatura e nıvel de estore.
Figura 6.2: Aplicacao da Atividade ”Ver Filme”
Este segundo cenario retrata a situacao em que o utilizador pode querer realizar espontaneamente
45
uma atividade. Para estas situacoes apenas tera de selecionar a atividade pretendida e o sistema
ajustara as variaveis do ambiente para satisfazer as suas preferencias.
• Cenario 3 (Figura 6.3): Ao preparar o pequeno-almoco, a ’Ana’ gosta de ouvir a estacao de
radio RFM, e um nıvel para a intensidade luminosa de 80%. O ’Pedro’ que acorda a mesma hora,
entra na cozinha ao mesmo tempo que a ’Ana’ para preparar tambem o seu pequeno-almoco. No
entanto, este tem preferencias sobre a estacao de radio, preferindo a RFM, gosta da temperatura
a 24º C e nıvel de intensidade luminosa a 55%. Mais tarde, junta-se o ’Joao’, que gosta da
temperatura a 21º C e do nıvel de intensidade luminosa a 40% .
Figura 6.3: Aplicacao do mecanismo de resolucao de conflitos
O cenario descrito permite retratar a situacao em que nem sempre as preferencias dos utilizadores
sao as mesmas. Como tal, existe a necessidade de maximizar o nıvel de satisfacao dos utilizadores.
Como nem todos os utilizadores possuem o mesmo privilegio nem a mesma exigencia sobre cada area
de preferencia, e necessario considerar ambos os fatores. A ’Ana’ tem nıvel de permissao 9, o Pedro 5
e o Joao 8, e nıveis de preferencia sobre a area de iluminacao, 5, 5 e 4 respetivamente.
rc =5× 9× 80 + 5× 5× 55 + 4× 8× 40
5× 9 + 5× 5 + 4× 8= 61.3 % . (6.1)
O mecanismo de resolucao de conflitos aplica a Equacao 6.1, formulada na Seccao 4.5, de forma a
encontrar o valor para a intensidade luminosa da divisao. O mesmo acontece para os restantes valores
em conflito.
46
Figura 6.4: Aplicacao do mecanismo de refinamento de perfil
• Cenario 4 (Figura 6.4): O ’Joao’ definiu um nıvel ideal para a intensidade luminosa de 40% no
seu perfil. No entanto, esse nıvel ja nao se adequa as suas necessidades. Assim, altera esse
valor em 5 ocasioes, manualmente, para 90%.
O quarto cenario representa a situacao das preferencias dos utilizadores definidas nao estarem
atualizadas. Podem acontecer situacoes em que os nossos gostos se alteram, ou num determinado
momento as preferencias que definimos nao sao adequadas. Como tal, e utilizado o mecanismo para
refinar o perfil que ajusta automaticamente a propriedade intensidade luminosa, alterada manualmente
pelo utilizador. Nesta situacao, com 5 alteracoes para 90%, o valor desta propriedade do perfil foi
ajustado de 40% para 60%.
47
6.2 Testes de Usabilidade
Para qualquer interface, alguns problemas sao faceis de encontrar, uma vez que sao flagrantes e
encontrados por quase todos os usuarios de teste, enquanto outros sao mais difıceis de encontrar, uma
vez que sao mais subtis ou encontrados apenas sobre circunstancias especiais (Nielsen and Landauer,
1993). Para garantir um elevado nıvel de usabilidade na criacao dos perfis de utilizador foi realizado
um conjunto de testes a um grupo de 9 utilizadores, que se preve que encontrem cerca de 95% dos
problemas de usabilidade existentes no produto (Nielsen and Landauer, 1993; Virzi, 1992). Foi seguido
um modelo iterativo de testes de usabilidade (Romano Bergstrom et al., 2011), em que sao realizados
os testes com 5 utilizadores e seguidamente implementadas as correcoes necessarias a interface.
Posteriormente, inicia-se uma nova fase de testes e novas correcoes sao realizadas. Este modelo e
mais eficaz do que testar uma unica vez com todos os utilizadores.
6.2.1 Processo
Todos os utilizadores realizaram o mesmo conjunto de tarefas, mesmo depois de implementar as
correcoes a primeira versao da solucao. O tempo estimado para completar a avaliacao foi entre 20 a
30 minutos e encontra-se dividido em tres partes:
• Preparacao: todo o software necessario para realizar os testes de usabilidade encontrava-se
previamente instalado no computador designado. Antes de iniciar, todos os utilizadores receberam
um Guiao (que pode ser consultado no Anexo B) com as instrucoes sobre cada tarefa e o Manual
de Utilizador (de leitura opcional);
• Tarefas: concluıda a preparacao, os utilizadores completaram o conjunto de tarefas pedido no
Guiao. Para cada tarefa foram registados os tempos de execucao e numero de erros dos utiliza-
dores;
• Questionario: depois de finalizadas todas as tarefas, os utilizadores responderam a um ques-
tionario para avaliar a usabilidade, experiencia de utilizador e obter feedback (sobre os pontos
negativos e positivos e novas ideias para melhorar a ferramenta) do Gestor de Perfis. Este Ques-
tionario pode ser consultado no Anexo C.
O Manual de Utilizador (Anexo A) explica as funcionalidades do Gestor de Perfis e como utilizar a
respetiva interface. O manual esteve disponıvel para consulta durante a realizacao das tarefas. O Guiao
(Anexo B) contem uma breve introducao sobre o Gestor de Perfis e a avaliacao, uma preparacao e as
tarefas solicitadas.
48
6.2.2 Tarefas
A avaliacao proposta consiste em 8 tarefas que possibilitam explorar o Gestor de Perfis e utilizar
todas as funcionalidades disponıveis a fim de garantir uma cobertura total da ferramenta e receber feed-
back sobre a experiencia de utilizacao. A ordem das tarefas seguiu o processo ”natural” da criacao de
perfis. Os utilizadores comecaram por realizar tarefas simples como criar utilizador e no final pedia-se
que criassem um perfil mais completo. Os utilizadores criaram os tres tipos de perfis e lidaram direta-
mente com os conceitos associados, como por exemplo, de area de preferencia, nıvel de preferencia,
propriedades e respetivos valores.
A avaliacao da experiencia de utilizador foi realizada no final de cada tarefa, desta forma os utiliza-
dores podiam imediatamente dar o seu feedback. Todas as tarefas estao presentes no Guiao que pode
ser encontrado no Anexo B.
6.2.3 Participantes e Preparacao
No total 9 utilizadores, com idades compreendidas entre os 17 e os 64 anos, participaram na
avaliacao do Gestor de Perfis. No grupo de participantes todos estavam familiarizados com a utilizacao
de smartphones, tablets ou computadores pessoais. As avaliacoes realizaram-se presencialmente,
desta maneira foi possıvel seguir todo o processo de interacao com a ferramenta. No fim, foi ainda
possıvel partilhar ideias e discutir alguns aspetos da solucao.
Relativamente a preparacao da avaliacao, os utilizadores precisaram de um computador, que lhes
foi facultado ja pre configurado. Adicionalmente, pedia-se que confirmassem que o ficheiro XML de
configuracao da habitacao se encontrava na localizacao correta. E ainda importante referir que alguns
utilizadores optaram por pedir uma curta explicacao sobre o Gestor de Perfis e as suas funcionalida-
des em alternativa a ler o Manual de Utilizador. Isto permitiu avaliar fatores interessantes como e o
caso da facilidade de aprendizagem, que caso contrario nao seriam autenticos. Depois de realizada a
preparacao, os utilizadores iniciaram a aplicacao e comecaram a realizar as tarefas pedidas no Guiao.
6.2.4 Questionario
Finalmente, depois de completar as 8 tarefas, cada utilizador respondeu ao Questionario (ver Anexo
C) que estava dividido em duas seccoes:
• Usabilidade;
• Opiniao Pessoal.
A usabilidade pretende avaliar o software a varios nıveis, nomeadamente em termos da sua eficacia,
eficiencia e satisfacao dos utilizadores. A motivacao principal para a inclusao desta seccao foi preci-
49
samente para compreender a experiencia dos utilizadores acerca dos processos de criar, editar e gerir
os seus proprios perfis. As perguntas sobre a usabilidade foram colocadas no final de cada tarefa e
foram avaliadas numa escala ate cinco. Os utilizadores classificaram a dificuldade das tarefas que iam
realizando.
A seccao de opiniao pessoal contemplou tres perguntas de resposta aberta. Com a primeira per-
gunta procurou-se perceber a impressao geral com que ficaram da aplicacao e da sua interface. Com a
segunda pergunta pretendeu-se encontrar a tarefa que os utilizadores consideraram mais complexa e o
motivo. Por ultimo, a terceira pergunta procurou obter uma perspetiva do ponto de vista dos utilizadores,
sobre aspetos que gostariam de ver introduzidos ou alterados no Gestor de Perfis.
6.3 Resultados e Discussao
As duas seccoes anteriores focaram-se exclusivamente na avaliacao, tanto das funcionalidades
como da usabilidade da solucao. Nesta seccao apresentamos e discutimos os resultados de ambas as
componentes.
Depois de totalizar as 9 avaliacoes com utilizadores, foi realizada a analise dos resultados obtidos
ao Gestor de Perfis. Todos os utilizadores completaram as tarefas do Guiao e o Questionario. A tabela
com os resultados dos testes de usabilidade pode ser consultada no Anexo D.
6.3.1 Simulador e Funcionalidades
Os resultados da implementacao dos perfis de utilizador e dos respetivos mecanismos foram bas-
tante positivos. O simulador permitiu realizar varias experiencias com os perfis de utilizador e as
multiplas combinacoes possıveis. Alguns utilizadores utilizaram inclusive o simulador para controlar
a movimentacao dos habitantes e confirmaram a aplicacao dos perfis que definiram. Foram varios os
pontos positivos a reter, nomeadamente a validacao dos mecanismos desenvolvidos, a eficacia e com-
pletude da solucao quando colocada a prova por cenarios concretos. As funcionalidades adicionais im-
plementadas no simulador, para comparar, apresentar e consultar informacoes, foram particularmente
uteis para seguir todas as alteracoes aos perfis e aos dispositivos das divisoes, mantendo o utilizador
sempre esclarecido. No entanto, um ponto menos positivo foi o facto do simulador apenas funcionar
no sistema operativo Windows devido a algumas funcionalidades nao serem compatıveis com todos os
sistemas operativos.
50
6.3.2 Usabilidade
O conjunto de testes de usabilidade avalia o Gestor de Perfis recorrendo a tres metricas tradicional-
mente recomendadas (Nielsen and Landauer, 1993; ISO/IEC25022:2016; Smith and Mayes, 1996):
• (1) Facilidade de aprendizagem: o utilizador consegue rapidamente interagir com o sistema,
aprendendo as opcoes de navegacao e a funcionalidade dos botoes;
• (2) Facilidade de utilizacao: depois de o utilizador ter aprendido a interagir com a aplicacao,
deve conseguir usa-la com facilidade, nunca perdendo a orientacao;
• (3) Satisfacao do utilizador: mede se o utilizador gosta de utilizar a aplicacao, devido a sua in-
terface, conteudo disponıvel, processo de interacao e navegacao, ajudas disponıveis entre outros.
Estes aspetos sao avaliados pelos utilizadores e registados enquanto interagem com a aplicacao.
Basicamente, a eficiencia e determinada pelo tempo medio que os utilizadores demoraram a completar
cada tarefa. A eficacia foi analisada com base no numero de erros cometidos pelos utilizadores, se os
utilizadores conseguiram recuperar desses erros e se foram induzidos em erro por alguma informacao.
Para avaliar a experiencia com a utilizacao da aplicacao, os utilizadores responderam a um conjunto
de questoes para classificar o nıvel de dificuldade das funcionalidades e o nıvel de satisfacao com a
ferramenta em si.
Os resultados obtidos pelos utilizadores nos testes de usabilidade podem ser consultados no Anexo
D. Para cada tarefa foram determinadas a media e a mediana relativamente ao tempo de execucao,
numero de erros e experiencia de utilizador, com o proposito de analisar estatisticamente os resultados.
Figura 6.5: Eficiencia - Tempo de Execucao
51
Podemos observar por analise do grafico da Figura 6.5 que o tempo medio para criacao de um Perfil
Generico (tarefa B), uma Atividade (tarefa E) ou um Perfil Especifico (tarefa F) foi cerca de um minuto,
o que indica que a maioria dos utilizadores desempenhou a avaliacao corretamente e dentro do tempo
esperado. A media individual das restantes tarefas nao excedeu os 35 segundos. E importante referir
que a maioria dos utilizadores nao leu o manual de utilizador, navegaram livremente pelo Gestor de
Perfis sem conhecer qualquer detalhe sobre a criacao de um perfil. Pode constatar-se ainda que o
tempo de criacao dos perfis foi diminuindo a medida que os utilizadores conheciam melhor a aplicacao,
mesmo apesar da tarefa de criacao do Perfil Especifico ser a mais complexa. Estas observacoes
indicam a eficiencia e a facilidade de aprendizagem da aplicacao.
Figura 6.6: Eficacia - Numero de Erros
O grafico da Figura 6.6 corresponde aos erros cometidos pelos utilizadores durante a avaliacao. Nas
tarefas de criacao e remocao de utilizadores nao foi cometido qualquer tipo de erro. A tarefa que registou
mais erros (media de 1), foi precisamente a criacao de um Perfil Generico de utilizador, claramente
influenciada pelo desconhecimento inicial da interface da aplicacao. No entanto, todos os utilizadores
conseguiram recuperar dos erros com sucesso. Na criacao da Atividade e Perfil Especıfico observou-se
uma reducao dos erros cometidos para metade, devido precisamente a facilidade de aprendizagem da
interface.
No que diz respeito a experiencia de utilizador, pode dizer-se que foi um dos pontos muito positivos
da avaliacao. O grafico da Figura 6.7 permite-nos observar os resultados do questionario realizado aos
utilizadores acerca da sua experiencia com o Gestor de Perfis. Praticamente todas as tarefas obtiveram
uma classificacao elevada, na escala de um a cinco, em que cinco significa que a tarefa foi muito
facil de concretizar e um muito difıcil. A avaliacao por parte dos utilizadores e uma fase vital para o
52
Figura 6.7: Experiencia de Utilizador
desenvolvimento de uma solucao centrada nos utilizadores e estes resultados verificam efetivamente a
sua satisfacao com o uso da aplicacao e das funcionalidades.
Contudo, mesmo apesar dos resultados positivos, alguns problemas de usabilidade foram registados
a partir dos erros cometidos pelos utilizadores durante a execucao das tarefas.
O primeiro problema de usabilidade relacionava-se com a acao de salvar um perfil de utilizador.
Sempre que os utilizadores salvavam um perfil aparecia uma mensagem de sucesso, no entanto o uti-
lizador permanecia na mesma janela e para aceder ao menu dos seus perfis era necessario retroceder
manualmente. As pessoas esperavam ser reencaminhadas para o menu inicial depois de concluırem a
tarefa. Para melhorar este aspeto o botao de criar um perfil foi alterado, reencaminhando diretamente
para a pagina dos perfis de utilizador.
Quando os utilizadores tentavam ativar uma propriedade, nao era imediatamente intuitivo pressionar
o botao de ligar. Alguns realizaram um duplo click no nome da propriedade, enquanto outros apenas
carregaram no seu nome. Consequentemente, alguns utilizadores perderam tempo para encontrar a
forma para ativar uma propriedade. Este problema foi resolvido permitindo ativar uma propriedade
pressionando diretamente sobre o seu nome. Os casos mais evidentes foram imediatamente corrigidos
da 1ª para a 2ª iteracao dos testes de usabilidade.
Todos os utilizadores forneceram o seu feedback e as opinioes pessoalmente e atraves das per-
guntas com resposta aberta presentes no questionario. A interface apelativa e facilidade de uso da
aplicacao foram mencionadas pela grande maioria dos participantes. Os utilizadores demonstraram
ainda interesse sobre o futuro da aplicacao e foram sugeridas novas funcionalidades e melhorias. Algu-
mas das sugestoes podem ser consideradas para o trabalho futuro uma vez que sao ideias interessan-
53
tes que podem melhorar o sistema e a experiencia de utilizador. O feedback positivo recebido acerca
dos perfis de utilizador e da aplicacao demonstra o seu potencial e possibilidade para crescimento
futuro.
54
Capıtulo 7
Conclusoes e Trabalho Futuro
A popularidade das casas inteligentes tem aumentado nos ultimos anos. No entanto, a sua divulgacao
tem sido lenta comparativamente ao que se previa, dado que as solucoes atuais apresentam ainda al-
gumas limitacoes (Brush et al., 2011; Hargreaves et al., 2013). Os sistemas existentes sao baseados
na sua maioria em abordagens centradas na tecnologia, em detrimento de solucoes mais simples cen-
tradas nos utilizadores (Andres et al., 2016). O sucesso das casas inteligentes esta diretamente ligado
a satisfacao das necessidades dos utilizadores e a facilidade de uso. Como tal, e fundamental investir
em novas abordagens personalizaveis, que se adaptem aos habitantes destas casas.
7.1 Conclusoes
Para desenvolver uma solucao para este problema foram analisados os sistemas domoticos existen-
tes de modo a identificar as suas restricoes, vantagens e desvantagens. A literatura estudada divide-
se em duas areas principais. A area de criacao de automatismos para a casa inteligente e a area de
resolucao de conflitos entre preferencias de diferentes utilizadores. Existe, no entanto, um vazio por pre-
encher entre estes dois tipos de abordagens assim como uma falta de capacidade de personalizacao.
O presente trabalho veio, neste contexto, introduzir o conceito de perfil de utilizador. Um perfil ofe-
rece a capacidade de personalizar o funcionamento do sistema, permitindo expressar as preferencias
de um utilizador de forma generica ou mais detalhada, conforme o desejado. Foram propostos tres
tipos de perfis, o Perfil Generico, a Atividade e o Perfil Especıfico. O Perfil Generico apresenta como
caracterıstica principal a facil configuracao das preferencias de um utilizador, independentemente da
habitacao. Ja a Atividade da ao utilizador a possibilidade de definir e ativar, a qualquer momento, as
suas preferencias para realizar uma determinada tarefa. O Perfil Especifico garante a possibilidade de
configurar pormenorizadamente parametros de certos dispositivos e ainda personalizar as preferencias
em funcao da divisao da casa.
55
Como nem todos os utilizadores partilham das mesmas preferencias, existe a necessidade de re-
solver conflitos entre as diferentes exigencias dos utilizadores. O mecanismo de resolucao de conflitos
aplicado tem em consideracao multiplos fatores, nomeadamente, o nıvel hierarquico dos utilizadores, o
grau de preferencia manifestada pelos utilizadores sobre um determinado aspeto, o numero de utiliza-
dores envolvidos e a ordem de chegada ao espaco.
Adicionalmente, foi proposto um mecanismo para refinar um perfil que tem em atencao a quantidade
de vezes que um utilizador altera manualmente uma propriedade do ambiente e a magnitude dessa
alteracao, ajustando automaticamente o seu perfil.
Para validar o potencial da solucao apresentada, foi desenvolvida uma aplicacao capaz de gerir os
perfis de diferentes utilizadores e simular o funcionamento de uma habitacao, seguindo o modelo Do-
moBus. Esta aplicacao permite verificar a correta aplicacao das preferencias dos utilizadores quando
estes entram numa dada divisao, testar a resolucao de conflitos quando diferentes utilizadores par-
tilham um mesmo espaco e ainda validar os mecanismos de ajuste dos perfis quando e identificado
que os utilizadores modificaram manualmente certos valores do ambiente. O simulador desenvolvido
permitiu avaliar na pratica a eficacia de todos os mecanismos desenvolvidos, recorrendo a um conjunto
de cenarios representativos do quotidiano dos utilizadores. Os mecanismos funcionaram com exito e
apresentaram bons resultados.
A gestao e criacao dos perfis de utilizador sao asseguradas pelo Gestor de Perfis. Este software
oferece diversas funcionalidades como por exemplo criar utilizadores, criar diferentes perfis e alte-
rar os perfis existentes, garantindo simplicidade e rapidez durante todo processo. Os resultados da
avaliacao com utilizadores reais revelaram que, apesar dos utilizadores nao conhecerem a aplicacao,
todos eles completaram as tarefas propostas com sucesso, nomeadamente foram capazes de criar os
seus proprios perfis em menos de um minuto e meio. A solucao final recebeu um feedback positivo
apresentando uma boa usabilidade, eficiencia e experiencia de utilizador, fundamental num sistema
centrado nos utilizadores.
7.2 Trabalho Futuro
E reconhecido que alguns aspetos da solucao necessitam de melhorias, como e caso do aspeto
da portabilidade, e algumas das sugestoes dadas pelos utilizadores sao boas ideias para adicionar a
solucao no futuro.
O trabalho futuro podera lidar com aspetos relevantes associados a melhoria da experiencia dos
utilizadores do sistema. Uma direcao que podera ser relevante seguir esta relacionada com o suporte
a dispositivos moveis. Criar e editar perfis a partir de um smartphone ou atraves de paginas Web,
permitira um nıvel de usabilidade acrescido e garante uma maior liberdade aos utilizadores.
56
Adicionalmente, podera ser uma mais valia introduzir um mecanismo de feedback explicito durante
a resolucao de conflitos, que melhore continuamente com a opiniao fornecida pelos utilizadores.
Seria interessante automatizar a definicao do perfil generico de cada utilizador, assim como introdu-
zir nos perfis uma vertente relacionada com as otimizacoes energeticas. Isto podera aumentar o grau
de personalizacao dos perfis atraindo mais utilizadores a utilizar o sistema.
57
Bibliografia
R. Nunes, “Modelo de Especificacao e Programacao de um Sistema Domotico,” IADIS Conferencia
2. Antes de começar.............................................................................................................................4
2.1. Conceitos Principais................................................................................................................42.1.1. Preferências de Utilizador.................................................................................................................................42.1.2. Perfil de Utilizador............................................................................................................................................42.1.3. Tipos de Perfis de Utilizador.............................................................................................................................42.1.4. Área e Nível de Preferência..............................................................................................................................5
3. Interface do Gestor de Perfis..........................................................................................................6
3.2. Menu.........................................................................................................................................73.2.1. Barra de navegação principal............................................................................................................................73.2.2. Barra de funcionalidades...................................................................................................................................83.2.3. Área de conteúdos.............................................................................................................................................8
4. Usar a aplicação..............................................................................................................................9
4.2. Criar um Novo Utilizador.......................................................................................................9
4.2. Gerir os Perfis de Utilizador.................................................................................................10
4.3. Criar um Perfil de Utilizador...............................................................................................11
4.4. Visualizar um Perfil de Utilizador.......................................................................................13
4.5. Editar um Perfil de Utilizador..............................................................................................13
4.6. Eliminar um Perfil de Utilizador.........................................................................................13
Manual de Utilizador Page 2
62
Gestor de Perfis
1. Introdução
1.1. Âmbito e propósito
O Gestor de Perfis é um software direcionado para a gestão e controlo de perfis de utilizador. Osperfis de utilizador permitem configurar de forma fácil, rápida e intuitiva uma casa inteligente, indode encontro as necessidades de cada pessoa.
Um perfil de utilizador permite um alto detalhe de configuração das preferências de um utilizador,como por exemplo o nível da intensidade luminosa, o canal de TV preferido ou temperaturaambiente. Os diferentes tipos de perfil dão a possibilidade de definir estas preferências em funçãodas atividades que um utilizador desempenha, por exemplo “estudar” ou “ver um filme”, ou emfunção da divisão ou casa em que se encontra.
O principal objetivo deste manual de utilizador é orientar e ajudar os utilizadores durante autilização do Gestor de Perfis e das suas principais funcionalidades, e ainda detalhar os passosnecessários para executar corretamente cada ação. As funções básicas de login, criar e apagarutilizadores são explicadas neste documento, mas também as funcionalidades principais de criarum perfil, gerir os perfis e gerir os utilizadores do sistema.
Este software pode ser usado por qualquer tipo de utilizador uma vez que a interface desenvolvidaé simples e permite uma rápida adaptação. De modo a obter o máximo rendimento, antes deiniciar a utilização da aplicação, é recomendável que se conheça todas as suas funcionalidades econceitos principais.
1.2. Requisitos iniciais
De modo a usar o Gestor de Perfis, é necessário um computador com pelo menos a versão 8 doJava e o Apache Maven 3.5.0., para iniciar a aplicação deverá primeiro executar a aplicação eseguidamente escolher o Gestor de Perfis. Para utilizar a aplicação como administrador, deverãoser utilizadas as credenciais: username: Admin, password: admin. Caso pretenda utilizar aaplicação como um utilizador regular, se já usufruir de uma conta, então poderá utilizar as suascredências pessoais. Existem ajudas ao nível da aplicação caso pretenda esclarecer algumadúvida específica de um determinado menu.
Manual de Utilizador Page 3
63
Gestor de Perfis
2. Antes de começar
Esta secção explica alguns dos conceitos mais importantes para usar a aplicação e ainda comorealizar a operação de Login para começar a utilizar as funcionalidades do Gestor de Perfis.
2.1. Conceitos Principais
2.1.1. Preferências de Utilizador
Os dispositivos domóticos são compostos por um conjunto de propriedades. Estas propriedadespodem ser, por exemplo, a luminosidade, o canal de TV, a temperatura ou a estação de rádio. Aspreferências de um utilizador são os valores que o utilizador prefere para estas propriedades. Porexemplo, se um utilizador gostar particularmente da temperatura a 21º, então este valor faz partedas suas preferências de utilizador.
2.1.2. Perfil de Utilizador
Um perfil de utilizador corresponde ao conjunto de preferências que determinado utilizadorpretende para os dispositivos domóticos existentes na casa inteligente. Concretamente, se umutilizador tiver preferências pela temperatura a 23º C e o canal de TV SIC, estas preferências doutilizador são, consequentemente, o seu perfil de utilizador.
2.1.3. Tipos de Perfis de Utilizador
a) Perfil Genérico Permite colocar automaticamente as preferências doutilizador (temperatura, iluminação, nível do estore etc.) em qualquer divisãoda casa ou de outra habitação com o sistema DomoBus. Por exemplo: Seum utilizador gostar da intensidade luminosa a 80% então esse valor seráaplicado sempre que o utilizador estiver presente.
b) Atividade Possibilita a ativação manual de uma determinada atividade queo utilizador queira realizar espontâneamente, por exemplo ”Ver um Filme”,”Ler um Livro” ou ”Trabalhar”. Ao ativar uma atividade as preferências que outilizador configurou para essa actividade são colocadas imediatamente.
c) Perfil Especifico – Semelhante ao Perfil Genérico mas permite aindaconfigurar dispositivos individualmente e escolher qual a divisão que sepretende aplicar certas preferências. Por exemplo: Na sala colocar atemperatura a 20º e no quarto a 22 ºC.
Manual de Utilizador Page 4
64
Gestor de Perfis
2.1.4. Área e Nível de Preferência
Uma área de preferência corresponde a um domínio ao qual estão relacionadas todas aspropriedades. Por exemplo: A área de entretenimento tem propriedades como o Canal de TV ou aEstação de Rádio, enquanto a área de climatização tem a propriedade temperatura.
Para permitir que múltiplos utilizadores possam coabitar no mesmo espaço é necessário que osutilizadores definam para cada área de preferência que pretendem configurar, um nível depreferência. Desta forma torna possível vários utilizadores poderem partilhar a mesma divisão.
Manual de Utilizador Page 5
65
Gestor de Perfis
3. Interface do Gestor de Perfis
3.1. Botões principais
Descrição Botão
Fechar o Gestor de Perfis
Retroceder para o menu anterior
Menu de Ajuda
Informação sobre uma funcionalidade
Editar e criar os perfis do utilizador
Criar um novo utilizador
Remover o utilizador do sistema
Criar um novo perfil de utilizador
Editar o perfil de utilizador selecionado
Escolher o nível de preferência para uma área
Remover o perfil de utilizador selecionado
Visualizar detalhes de um perfil
Manual de Utilizador Page 6
66
Gestor de Perfis
3.2. Menu
A figura abaixo apresenta a interface do Gestor de Perfis. Os menus de navegação, o menu dasfuncionalidades e as informações apresentadas encontramse sempre na mesma posição do ecrã.O menu abaixo apresentado, será o primeiro menu do Gestor de Perfis que o utilizador iráencontrar caso tenha permissões de administrador. Este menu permite gerir os utilizadores dosistema DomoBus. Neste menu é possível criar e apagar utilizadores, e ainda aceder ao menuque permite gerir os perfis de cada habitantes. Caso o utilizador não tenha permissões deadministrador apenas poderá gerir os seus próprios perfis.
3.2.1. Barra de navegação principal
A barra de navegação principal permite ao utilizador fechar a aplicação, aceder ao menu de ajudae retroceder para o menu anterior. Sempre que o utilizador pretenda ir para o menu inicial, bastacarregar no logótipo do DomoBus. A barra de navegação principal é igual em qualquer menu doGestor de Perfis.
Manual de Utilizador Page 7
67
Gestor de Perfis
3.2.2. Barra de funcionalidades
A barra de funcionalidades permite concretizar ações associadas ao menu em que o utilizador seencontra. Como tal, os botões que constituem esta barra variam consoante o menu.
3.2.3. Área de conteúdos
A área assinalada é utilizada para apresentar as informações relevantes. Nesta figura sãoapresentados todos os utilizadores do sistema. No menu de gestão de perfis esta área é utilizadapara apresentar os perfis do utilizador.
Manual de Utilizador Page 8
68
Gestor de Perfis
4. Usar a aplicação
Caso seja um utilizador regular, depois do login, o utilizador vai diretamente para o menu degestão de perfis. As funcionalidades relacionadas com os perfis de utilizador irão ser explicadasde seguida. Notese que exceto seja administrador, cada utilizador apenas pode editar os seuspróprios perfis.
4.1. Login
Depois de iniciar o Gestor de Perfis, irá encontrar o menu de login, que dará acesso à gestão dosperfis de utilizador. Uma mensagem de alerta irá aparecer caso as credenciais introduzidasestejam incorretas. Para efectuar o login:
1. Colocar as credenciais nos respectivos campos Username e Password;2. Carregar no botão de LOGIN.
4.2. Criar um Novo Utilizador
Este menu permite criar um novo utilizador para o sistema. No passo 1. deve inserir o nome deutilizador e a palavra pass. No passo 2. deve inserir o nível de acesso do novo utilizador. Nopasso 3. pode confirmar ou cancelar a criação do utilizador.
Manual de Utilizador Page 9
69
Gestor de Perfis
4.2. Gerir os Perfis de Utilizador
Este menu permite criar um novo perfil de utilizador, editar e visualizar as preferências associadasa um perfil já existente, e remover um perfil. Estas funcionalidades encontramse disponíveis nabarra de funcionalidades à direita. Na área correspondente ao conteúdo é possível ver todos osperfis deste utilizador.
Manual de Utilizador Page 10
70
Gestor de Perfis
4.3. Criar um Perfil de Utilizador
A criação de novos perfis tem uma sequência de passos bem definida. Depois de carregar nobotão parar criar um novo perfi, é necessário selecionar o tipo de perfil que pretende configurar. Acriação do perfil genérico está limitada a um por utilizador uma vez que este perfil pode serutilizado em qualquer local. Seguidamente, o utilizador deverá carregar na área de preferênciapela qual tem interesse definir as suas preferências. Adicionalmente deve escolher o nível depreferência para essa área, de 1 a 5, em que 5 significa que é muito exigente sobre essa área e 1que tem flexibilidade sobre as suas preferências, além disso deve escolher as propriedades erespetivos valores que quer ver presentes no seu perfil. No final deverá guardar as alterações ecarregar no botão para criar o perfil. Para adicionar mais do que uma área de preferência ou maispropriedades ao perfil é só repetir dos passos B) a E).
A) Selecionar o tipo de perfil – Escolher um dos seguintes tipos de perfil a configurar: Genérico, Actividade ou Específico.
Manual de Utilizador Page 11
71
Gestor de Perfis
B) Áreas de preferência – Existem várias áreas de preferência que o utilizador podeconfigurar, Iluminação, Entretenimento, etc. Para escolher uma área é só carregar no icone1. da imagem abaixo. Quando acabar de configurar todas as áreas pretendidas podeverificar o estado do perfil carregando no botão verde realçado em 2. Para criar o perfil éapenas necessário pressionar o botão apresentado em 3.
C) Configurar área de preferência – Quando selecionar a área de preferência vai encontraro menu apresentado na imagem abaixo. Para configurar uma área de preferência énecessário definir um nível de preferência, este pode ser definido em 1. como apresentadona imagem abaixo. Para activar/desactivar uma propriedade para o perfil é apenas
Manual de Utilizador Page 12
72
Gestor de Perfis
necessário carregar no botão apresentado em 2. que o irá direcionar para o menu D). Porúltimo para salvar a configuração da área de preferência é apenas necessário carregar nobotão Save, apresentado no passo 3. Para criar o perfil deve carregar no botão CreateProfile, como explicado em B).
D) Escolher o valor para uma propriedade – A imagem abaixo demostra o processo deescolher um valor para uma propriedade:
4.4. Visualizar um Perfil de UtilizadorPara visualizar as propriedades presentes num perfil de utilizador é necessário carregar no botãoshow profile existente no menu do capítulo 4.1. Para sair carregue Ok.
4.5. Editar um Perfil de UtilizadorO processo de editar um perfil de utilizador é muito semelhante ao de criar um novo perfil. Ospassos e menus são exatamente iguais ao de criar um perfil, ignorando o passo A) de escolher otipo de perfil, pode seguirse os passos do B) ao E) para criar um perfil.
4.6. Eliminar um Perfil de UtilizadorPara eliminar um perfil de utilizador do sistema apenas é necessário carregar no botão deleteprofile existente no menu do capítulo 4.1 e confirmar a operação.
Manual de Utilizador Page 13
73
Guião de avaliação para o Gestor de Perfis
O Gestor de Perfis é um software direcionado para a gestão e controlo de perfis de utilizador. Os perfis de utilizadorpermitem configurar de forma fácil, rápida e intuitiva uma casa inteligente, indo de encontro as necessidades de cadapessoa.
Um perfil de utilizador permite um alto detalhe de configuração das preferências de um utilizador, como por exemplo onível da intensidade luminosa, o canal de TV preferido ou temperatura ambiente. Os diferentes tipos de perfil dão apossibilidade de definir estas preferências em função das atividades que um utilizador desempenha, por exemplo“estudar” ou “ver um filme”, ou em função da divisão ou casa em que se encontra.
Este software pode ser usado por qualquer tipo de utilizador uma vez que a interface desenvolvida é simples e permiteuma rápida adaptação. De modo a obter o máximo rendimento, antes de iniciar a utilização da aplicação, érecomendável a leitura do manual de utilizador para que se conheça todas as funcionalidades e conceitos da aplicação.
Obrigado pela sua colaboração e tempo despendido.
Preparação
Antes de começar as tarefas é necessária realizar uma preparação:
• Ler o manual de utilizador (opcional);• Ter um computador com o software necessário instalado; • Garantir que o ficheiro XML de configuração da habitação (XML_general.xml) se encontra na pasta resources
fornecida.
Testes de Usabilidade
Depois de realizar as configurações iniciais, pode começar a realizar as tarefas descritas abaixo pela ordem queaparecem. O Manual de Utilizador pode ser consultado caso não saiba o que fazer de seguida. Estas tarefas sãorealizadas individualmente e no final deverá ser respondido ao questionário.
Cenário: Criar um novo utilizador.
Tarefa A
1. Fazer login na aplicação com as credenciais username: Admin e password: admin;2. Criar um novo utilizador com:
a) username: o seu nome;b) password: teste;c) access level: 9;
Apendice B
Testes de Usabilidade - Guiao
74
Cenário: Criar um Perfil Genérico para o seu utilizador.
Tarefa B
1. Selecione o seu utilizador e crie um novo perfil genérico;2. Escolha a área de preferência Lighting:
a) Defina o nível de preferência desta área para 4;b) Active a propriedade Luminosity e defina o seu valor para 50%;c) Guarde.
3. Escolha agora a área de preferência Entertainment:a) Defina o nível de preferência desta área para 2;b) Active a propriedade Channel e defina o seu valor para SIC;c) Guarde.
4. Visualize as propriedades do perfil;5. Crie o perfil.
Cenário: No Perfil Genérico criado, alterar o valor da propriedade Luminosity para 80%.
Tarefa C
1. Edite o perfil genérico que criou;2. Escolha a área de preferência Lighting:
a) Edite a propriedade Luminosity e defina o seu valor para 80%;b) Guarde as alterações.
3. Guarde o perfil.
Cenário: Visualizar as propriedades atualizadas do Perfil Genérico.
Tarefa D
1. Visualize as propriedades do seu Perfil Genérico.
Cenário: Crie um novo Perfil Actividade.
Tarefa E
1. Crie um novo perfil actividade para o seu utilizador;2. Dêlhe o nome de “Ver Filme”;3. Escolha a área de preferência Lighting:
a) Repare nas diferenças em relação ao Perfil Genérico, se for preciso utilize as ajudas disponíveis;b) Active a propriedade Luminosity e defina o seu valor para 10%;c) Guarde.
4. Escolha a área de preferência Entertainment:a) Active a propriedade Volume e defina o seu valor para 90%;b) Guarde.
5. Escolha a área de preferência Security:
75
a) Active a propriedade Blind Position e defina o seu valor para 0%;b) Guarde.
6. Visualize as propriedades do perfil;7. Crie o perfil.
Cenário: Crie um novo Perfil Específico.
Tarefa F
1. Crie um novo perfil específico para a divisão Livingroom;2. Escolha a área de preferência Entertainment:
a) Defina o nível de preferência desta área para 2;b) Active a propriedade Volume e observe a diferença em relação aos outros perfis;c) Defina o valor desta propriedade para 40%;d) Active a propriedade Channel, defina o seu valor para TVI e escolha o dispositivo Livingroom_TV;e) Guarde.
3. Visualize se as propriedades do perfil estão de acordo com as definidas;4. Crie o perfil.
Cenário: Desactivar a propriedade Channel do Perfil Específico.
Tarefa G
1. Edite o perfil específico que criou para a divisão Livingroom;2. Escolha a área de preferência Entertainment:
a) Desactive a propriedade Channel;b) Guarde.
3. Visualize as propriedades do perfil;4. Guarde as alterações ao perfil.
Cenário: Apagar um utilizador do sistema.
Tarefa H
1. Apague o utilizador que criou.
76
Apendice C
Testes de Usabilidade - Questionario
77
78
79
Apendice D
Testes de Usabilidade - Resultados
Tabela D.1: Tempo de execucao e numero de erros dos utilizadores
Tarefas Utilizadores Estatısticas1 2 3 4 5 6 7 8 9 Media Mediana Min. Max.