perfis de utilizador para casas inteligentes · perfis de utilizador para casas inteligentes...
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
Conteudo
1 Introducao 1
1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Estrutura da dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Estado da Arte 6
2.1 Conceitos associados a Domotica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Servicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Definicao de Conflito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2.A Detecao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2.B Resolucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3 Preferencias de Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Configuracao de Casas Inteligentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3 Solucoes para Resolucao de Conflitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Analise Crıtica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 O Sistema DomoBus 18
3.1 Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Modelo de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Linguagem de Especificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Concepcao da solucao 27
4.1 Caracteristicas Gerais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Areas de Preferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3 Perfis de Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4 Deteccao de Conflitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Estrategia para Resolucao de Conflitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.6 O Refinar de um Perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.7 Extensao do Modelo de Dados DomoBus . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
vi
4.8 Funcionamento da Solucao e Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 Implementacao da solucao 35
5.1 Gestor de Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.2 Visualizar, Criar e Remover Utilizadores . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.3 Gerir Perfis de Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.4 Documentacao e Ajudas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2 Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.1 Principais Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2.2 Interface do Simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.3 Aplicar os Perfis de Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.4 Mecanismo para Resolucao de Conflitos . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.5 Mecanismo para Refinar um Perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6 Avaliacao 44
6.1 Cenarios de Utilizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.2 Testes de Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.1 Processo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.2.2 Tarefas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.3 Participantes e Preparacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.2.4 Questionario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.3 Resultados e Discussao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.1 Simulador e Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.3.2 Usabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Conclusoes e Trabalho Futuro 55
7.1 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Bibliografia 57
A Manual de Utilizador 61
B Testes de Usabilidade - Guiao 74
C Testes de Usabilidade - Questionario 77
D Testes de Usabilidade - Resultados 80
vii
Lista de Figuras
3.1 Arquitetura nıvel de Controlo DomoBus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Arquitetura nıvel de Supervisao DomoBus. . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 UML do modelo de dados de uma habitacao (Nunes, 2004). . . . . . . . . . . . . . . . . 21
3.4 UML do modelo de dados de um dispositivo (Nunes, 2004). . . . . . . . . . . . . . . . . . 21
3.5 UML do modelo de dados de um cenario (Nunes, 2004). . . . . . . . . . . . . . . . . . . . 23
3.6 Estrutura de um pacote. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.1 Exemplo de areas de preferencia e as suas propriedades . . . . . . . . . . . . . . . . . . 28
4.2 Funcao ln(x) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Funcionamento da Solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Gestao de Utilizadores e Janela de Login. . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Gestao de Perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Definir um novo perfil de utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.5 Configuracao de Area de Preferencia e Ajudas. . . . . . . . . . . . . . . . . . . . . . . . . 39
5.6 Interface grafica do simulador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.7 Menu de utilizador e configuracoes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.8 Grafico acerca das alteracoes ao perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.1 Aplicacao de um perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Aplicacao da Atividade ”Ver Filme” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Aplicacao do mecanismo de resolucao de conflitos . . . . . . . . . . . . . . . . . . . . . . 46
6.4 Aplicacao do mecanismo de refinamento de perfil . . . . . . . . . . . . . . . . . . . . . . 47
6.5 Eficiencia - Tempo de Execucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.6 Eficacia - Numero de Erros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.7 Experiencia de Utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
viii
Lista de Tabelas
2.1 Comparacao de Solucoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1 Sumario dos diferentes tipos de perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Matriz decisao Canal TV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
D.1 Tempo de execucao e numero de erros dos utilizadores . . . . . . . . . . . . . . . . . . . 80
D.2 Experiencia dos utilizadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
ix
Listagens
3.1 Exemplo da estrutura de uma habitacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Exemplo dos tipos de propriedades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.3 Exemplo de um TipoDispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.4 Exemplo de um Dispositivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
x
Acronimos
XML Extensible Markup Language
PSR Problema de Satisfacao de Restricoes
DCN DomoBus Control Network
SM Modulos de Supervisao
HS Home Server
IoT Internet das Coisas
PU Perfil de Utilizador
RC Resolucao de Conflitos
xi
Capıtulo 1
Introducao
Atualmente, a expressao Casa Inteligente ou na lıngua inglesa Smart Home, e normalmente utili-
zada para definir uma habitacao que esta equipada com tecnologias conectadas pela rede (Wi-Fi, Blu-
etooth ou protocolos semelhantes) para controlar, automatizar e otimizar variaveis do ambiente como
a temperatura, iluminacao, seguranca, ou entretenimento (Banker, 2016). Uma Casa Inteligente pode
ser controlada remotamente atraves de um smartphone, tablet ou computador, ou utilizando um sis-
tema disponibilizado pela propria casa. O seu foco principal e proporcionar conforto aos habitantes.
No entanto, os avancos significativos no mercado da Internet das Coisas (IoT), a maior necessidade
de seguranca e a constante procura por poupancas energeticas sao outros fatores importantes para
a sua crescente popularidade. O mercado global das casas inteligentes foi avaliado em 54 bilhoes de
dolares em 2016 e preve-se que alcance a meta dos 137 bilhoes de dolares ate 2023, com a uma taxa
de crescimento de cerca de 13% (Markets and Markets, 2017).
Existem contudo alguns desafios que necessitam de ser ultrapassados de modo a suscitar um inte-
resse generalizado por este tema (Brush et al., 2011; Alam et al., 2012; Maternaghan and Turner, 2013;
Wilson et al., 2015), nomeadamente:
Flexibilidade: Os sistemas devem ser capazes de acomodar qualquer tipo de tecnologias sem qual-
quer restricao sobre a sua marca, permitindo um bom nıvel de compatibilidade entre diferentes
solucoes. Isto evita que o utilizador seja obrigado a escolher entre um unico sistema proprietario
e a integracao individual de diferentes tecnologias. Adicionalmente, o utilizador deve ser ca-
paz de estender facilmente a solucao adquirida, complementando-a com novos componentes. A
monitorizacao e controlo da habitacao deve poder ser realizada a partir de qualquer localizacao,
recorrendo para isso aos dispositivos moveis da atualidade;
1
Custo: Os custos de hardware, instalacao e manutencao destes sistemas sao uma das maiores
preocupacoes para os utilizadores. Do mesmo modo, o tempo necessario para os instalar, confi-
gurar e gerir nao deve ser ignorado;
Personalizacao: Qualquer sistema deve ser capaz de se adaptar a rotina e as tarefas que cada utiliza-
dor pretende desempenhar e considerar que nem sempre os utilizadores pretendem os mesmos
automatismos. A sua complexidade de configuracao e manutencao sao aspetos importantes para
a maioria dos utilizadores. Deve ser encontrado um equilıbrio entre personalizacao e automacao;
Usabilidade: Interfaces demasiado confusas limitam o uso das funcionalidades. Apesar dos utiliza-
dores estarem gradualmente a acostumar-se a dispositivos mais sofisticados, deve-se partir do
principio que nao tem conhecimentos tecnicos especializados. Qualquer visitante de uma casa
inteligente deve ser capaz de utilizar as suas funcionalidades sem duvidas nem receios de fazer
algo errado.
Um dos aspetos chave para o sucesso da automacao residencial e a sua capacidade em satisfazer
as exigencias de cada utilizador. Diferentes tipos de pessoas tem diferentes exigencias (Wilson et al.,
2015) e cada indivıduo tem as suas preferencias relativamente aos servicos disponıveis numa casa
inteligente. Estes servicos podem estar relacionados, por exemplo, com a climatizacao, iluminacao
e seguranca da habitacao. Um Perfil de Utilizador (PU) corresponde ao conjunto de valores que o
utilizador pretende para a configuracao da casa inteligente, que podem incluir por exemplo, o valor da
temperatura, o seu canal de TV favorito ou o genero musical preferido. Existe como tal a necessidade de
caracterizar individualmente cada utilizador, captando rigorosamente estas preferencias e habitos mais
comuns. Adicionalmente, com os progressos na area das casas inteligentes, e necessario conceber
uma solucao que se adapte as mudancas nas preferencias dos residentes com o passar do tempo.
Numa habitacao e comum existirem varios ocupantes. Mesmo as pessoas quando vivem sozinhas,
podem ter visitas de familiares ou amigos. Os ocupantes podem ter preferencias distintas e partilhar os
mesmos espacos da habitacao.
A literatura existente aborda a criacao de automatismos para as casas inteligentes de duas formas
distintas, atraves de configuracao semantica, introduzindo acoes manualmente (Maternaghan and Tur-
ner, 2013; Kao and Yuan, 2012) ou entao atraves do reconhecimento de habitos (Chen et al., 2012;
Iglesias and Kastner, 2013; Rashidi and Cook, 2008). Existe, no entanto, um vazio por preencher entre
estes dois tipos de abordagens devido a sua falta de personalizacao. Alem disso, as abordagens utili-
zadas para resolver os conflitos entre as preferencias dos utilizadores sao na sua maioria baseadas em
regras ou em satisfacao de restricoes (Maternaghan and Turner, 2013; Luo et al., 2013; Armac et al.,
2006), inflexivamente ignorando a intencao dos seus utilizadores.
2
1.1 Motivacao
Para ilustrar a importancia dos perfis de utilizador, consideremos uma sala de estar equipada com
um ar condicionado, dois candeeiros e uma televisao. Suponhamos que o Pedro durante o inverno gosta
da temperatura interior a 20º C e da intensidade luminosa a 85%. Sempre que entrar na sala de estar ou
noutra divisao que permita colocar estas preferencias, o Pedro tera de as definir manualmente em cada
dispositivo. No entanto, de cada vez que outro habitante altera as preferencias do Pedro, ele tera de
as definir novamente, inclusive alguns dispositivos nao guardam o estado quando sao desligados. Na
sua casa, no local de trabalho, caso visite a casa de um familiar ou amigo, o Pedro tera igualmente de
aplicar as suas preferencias manualmente em cada dispositivo, o que se torna uma tarefa repetitiva. E
ainda importante mencionar que um utilizador pode querer diferentes preferencias, em funcao da tarefa
ou atividade que desempenha, como por exemplo estudar ou ver um filme, ou em funcao da divisao da
casa em que se encontra. Todas estas situacoes devem ser geridas pela casa inteligente de modo a
satisfazer os utilizadores em diferentes circunstancias da sua vida quotidiana.
Suponhamos agora que no mesmo espaco onde se encontra o Pedro, entra outro utilizador com pre-
ferencias distintas sobre a intensidade luminosa e temperatura. Perante este cenario vai inevitavelmente
ocorrer um conflito entre as preferencias de ambos os utilizadores. Estes conflitos devem ser resolvidos
automaticamente tendo em conta diversos fatores como, por exemplo, a hierarquia dos utilizadores, o
grau de exigencia que colocam nos valores que definiram e a satisfacao global de todos os envolvidos
com a resolucao proposta. Naturalmente, se as preferencias dos utilizadores nao se sobrepuserem,
nao existira conflito e o sistema devera aplicar as preferencias de cada um sem restricoes.
Como consequencia, e fundamental desenvolver uma solucao fiavel ”multi-ocupante”, capaz de reu-
nir, aplicar e adaptar as preferencias dos diferentes utilizadores de forma automatica.
1.2 Objectivos
No panorama atual existe um enorme potencial para os sistemas e tecnologias domoticas, mas so
recentemente e que alguns dos problemas comecaram a ser abordados pela comunidade cientıfica.
A grande maioria dos sistemas dificilmente vai alem da configuracao de automatismos para as ca-
sas inteligentes. Os estudos que propoem sistemas capazes de criar estes automatismos, nao sao
flexıveis nem eficazes para uma utilizacao diaria por parte dos utilizadores. Estes sistemas ou sao
completamente automaticos, nao permitindo qualquer tipo de personalizacao, ou sao totalmente confi-
gurados atraves de regras, com interfaces muito complexas. Os sistemas de detecao e resolucao de
conflitos apresentam ainda um certo grau de imaturidade, desconsiderando parametros importantes
como a hierarquia dos utilizadores e a satisfacao perante a resolucao proposta.
3
Com base na literatura analisada sera conceptualizado e implementado um sistema, que permitira
a um utilizador configurar uma casa inteligente atraves de perfis de utilizador, suportados por um me-
canismo de resolucao de conflitos que possibilitara multiplos utilizadores partilhar o mesmo espaco,
mesmo com preferencias distintas. Perante a necessidade de adaptacao, propoe-se ainda uma me-
todologia que ajusta automaticamente os perfis de utilizador, uma vez que as preferencias de cada
pessoa podem alterar-se com o passar do tempo.
O objetivo desta dissertacao e conceber um sistema adaptavel, que torne possıvel satisfazer as
preferencias de multiplos habitantes ao oferecer:
• Diferentes perfis de utilizador, adaptaveis a cada situacao e compatıveis entre multiplas habitacoes;
• Resolucao de conflitos entre preferencias de utilizadores que coabitem o mesmo espaco;
• Ajuste automatico dos perfis dos utilizadores em funcao da mudanca nas suas preferencias ao
longo do tempo;
• Uma Interface de utilizador intuitiva que permita a qualquer habitante definir e gerir os seus perfis
de forma rapida e simples;
Para validar a eficacia da solucao final sera desenvolvida uma aplicacao capaz de ler os perfis de
diversos utilizadores, a estrutura de uma casa e os dispositivos que ela contem, permitindo simular
o funcionamento de uma habitacao. Assim, sera possıvel simular a presenca de um utilizador numa
dada divisao e verificar se as accoes desencadeadas satisfazem as definicoes do seu perfil. Da mesma
forma, sera possıvel simular a presenca de multiplos utilizadores numa mesma divisao e validar a
eficacia dos mecanismos de resolucao de conflitos. A aplicacao permitira ainda criar e gerir perfis de
utilizador e testar o funcionamento do mecanismo de ajuste automatico dos perfis.
O objetivo da solucao final proposta e lidar com as principais limitacoes dos sistemas domoticos da
atualidade, particularmente ao nıvel da flexibilidade, interoperabilidade, custo, personalizacao e usabi-
lidade, introduzindo os perfis de utilizador e utilizando a arquitetura oferecida pelo sistema DomoBus
(Nunes, 2003). Serao introduzidos e modificados alguns conceitos do modelo de dados da abordagem
DomoBus de forma a permitir definir os perfis de utilizador.
1.3 Estrutura da dissertacao
O restante documento encontra-se organizado em sete capıtulos e tres anexos.
O capıtulo seguinte apresenta uma perspectiva sobre os conceitos mais importantes para o topico
em questao, nomeadamente o que sao servicos, o que e um conflito e o que e um perfil de utiliza-
dor. Adicionalmente, neste capıtulo e analisada a literatura relacionada que inclui solucoes para definir
automatismos para uma casa inteligente e sistemas capazes de resolver diferentes tipos de conflitos.
4
O capıtulo 3 descreve a arquitectura e as vantagens do sistema DomoBus, sobre o qual vai ser
desenvolvida a solucao.
No capıtulo 4 sao introduzidos os mecanismos e conceitos necessarios para a implementar a
solucao e o capıtulo 5 apresenta as duas ferramentas desenvolvidas, para gerir os perfis de utiliza-
dor e para validar os mecanismos propostos no capitulo anterior.
O capıtulo 6 descreve todo o processo de avaliacao das funcionalidades, assim como os testes de
usabilidade e conclusoes obtidas. O ultimo capıtulo conclui a dissertacao com uma discussao geral e
propostas para o trabalho futuro.
Finalmente, nos anexos temos o manual de utilizador da aplicacao, o guiao, o questionario e os
resultados dos testes de usabilidade apresentados no capıtulo da avaliacao.
5
Capıtulo 2
Estado da Arte
Nos ultimos anos, tem surgido novas abordagens que visam automatizar as atividades realizadas
pelos utilizadores de uma casa inteligente. O objetivo principal destas abordagens passa por aumen-
tar o nıvel de conforto dos habitantes, produtividade e garantir eficiencia energetica. Igualmente, a
literatura relacionada com a detecao e resolucao de conflitos no contexto da automacao residencial
tem aumentado consideravelmente. Para melhor compreender o tema dos perfis de utilizador serao
analisados os trabalhos relevantes destas duas tematicas.
Comecaremos por introduzir os conceitos mais importantes para a compreensao do tema e de
seguida serao apresentadas diferentes metodologias que possibilitam a definicao de automatismos
para a habitacao. Identificaremos diferentes tipos de abordagens (automaticas e manuais), capazes
de retratar as preferencias dos utilizadores. Posteriormente, analisaremos diferentes metodologias de
resolucao de conflitos entre multiplos utilizadores, dispositivos e servicos. Por fim, sera realizada uma
comparacao dos diferentes sistemas e discutidas as suas vantagens e limitacoes face ao problema
apresentado.
2.1 Conceitos associados a Domotica
2.1.1 Servicos
Os servicos sao areas funcionais que recorrem a sensores e atuadores para gerir uma habitacao.
Tecnicamente, uma plataforma de servicos e uma combinacao entre hardware, a rede, um sistema
operativo ou uma framework que e necessaria para oferecer servicos ao utilizador final (Abdulrazak
et al., 2011). Os servicos geralmente oferecidos pela automacao residencial sao os seguintes:
Climatizacao: O controlo de dispositivos como ar condicionados, aquecedores, desumidificadores,
sensores de temperatura e humidade permite uma gestao adequada da climatizacao de uma
6
habitacao, beneficiando o conforto dos utilizadores.
Iluminacao: As funcionalidades que dizem respeito a iluminacao permitem controlar a intensidade
luminosa de diversos dispositivos assim como criar regras para ligar, desligar e temporizar.
Entretenimento: Todos os dispositivos relacionados com o lazer dos habitantes podem ser inseridos
na area do entretenimento. Nomeadamente dispositivos como televisores, consolas, media cen-
ters ou sistemas de som podem ser configurados para comunicar entre si, de modo a garantir
uma experiencia do agrado dos utilizadores.
Seguranca: A domotica apresenta uma mais-valia para a seguranca da habitacao. Atraves do controlo
de camaras de vigilancia, sensores de presenca, movimento e captacao de audio e possıvel
monitorizar eficazmente a habitacao. Este servico permite para alem de detetar intrusos, prevenir
situacoes que possam comprometer a seguranca dos habitantes como fugas de gas, inundacoes
ou incendios.
Energia: E possıvel gerir os custos energeticos da habitacao recorrendo a dispositivos de medicao,
como o caso de alguns sensores. O servico relacionado com a energia tem como objetivo contro-
lar os restantes servicos e garantir que os consumos energeticos da habitacao sao adequados,
realizando otimizacoes e, caso existam, priorizando a utilizacao de recursos renovaveis.
Dependendo do sistema e dos seus utilizadores podem ser introduzidas classes de servicos mais
especificas, como por exemplo, relacionadas com a saude ou com a privacidade dos habitantes.
E possıvel aceder a grande parte destes servicos pela Internet, recorrendo a aplicacoes especiali-
zadas construıdas para o efeito ou atraves de paginas web.
2.1.2 Definicao de Conflito
Na maioria das vezes inevitaveis, os conflitos surgem quando existe uma incompatibilidade de ativi-
dades. Diz-se que duas pessoas entram em conflito quando as suas acoes interferem, obstruem ou de
alguma outra forma tornam o comportamento do outro indivıduo menos eficiente (Tjosvold, 1997). No
ambito das casas inteligentes os conflitos podem ser ainda mais abrangentes e englobar dispositivos,
servicos ou politicas. Ao nıvel da automacao residencial, um exemplo tıpico de conflito acontece caso
um habitante pretenda reduzir a temperatura da sala durante a noite, mas um familiar seu pretenda
aumentar a temperatura. Simultaneamente ouvir musica e ver televisao podem ser consideradas acoes
incompatıveis, tal como pessoas diferentes quererem ver diferentes programas na mesma TV. O utiliza-
dor pode inclusive entrar em conflito consigo mesmo caso defina uma politica para poupar energia ao
mesmo tempo que deseja manter a casa aquecida no inverno.
7
2.1.2.A Detecao
A detecao de conflitos e parte integrante da maioria da literatura relacionada com os conflitos em
casas inteligentes. A capacidade de um sistema em reconhecer um estado de conflito e fundamental
para produzir uma boa resolucao. Existem como tal diferentes tipos de abordagens de detecao, que
variam consoante cada sistema. Existem abordagens baseadas em politicas que detetam os conflitos
durante a sua criacao, caso uma politica introduzida contradiga uma outra ja existente no sistema, como
e o caso da framework HOMER (Maternaghan and Turner, 2013). E ainda possıvel detetar conflitos
recorrendo as preferencias dos utilizadores (Park et al., 2005), caso estes tenham preferencia sobre o
mesmo servico ou dispositivo, ou recorrendo a regras implementadas com o objetivo de detetar e ate
mesmo evitar estes conflitos (Armac et al., 2006; Tuttlies et al., 2007). Estes sistemas serao analisados
posteriormente.
2.1.2.B Resolucao
Os mecanismos de Resolucao de Conflitos (RC) tambem variam consideravelmente de sistema
para sistema. Um dos mecanismos utilizados com alguma regularidade e o Problema de Satisfacao
de Restricoes (PSR), que consiste em satisfazer o maior numero possıvel de requisitos de entre varios
utilizadores, como e o caso do sistema apresentado por Camacho et al. (Camacho et al., 2014). Adicio-
nalmente, existem sistemas que optam por realizar uma ponderacao entre os varios valores em conflito
de modo a maximizar o nıvel de satisfacao dos utilizadores (Park et al., 2005). E possıvel ainda en-
contrar sistemas que utilizam regras para detetar e resolver os conflitos (Armac et al., 2006). Como
ultimo recurso, existem sistemas que recorrem aos utilizadores para resolver os conflitos manualmente
de modo a garantir um maior nıvel de exatidao (Maternaghan and Turner, 2013).
2.1.3 Preferencias de Utilizador
As preferencias dos utilizadores, mais concretamente os sistemas capazes de reunir estas pre-
ferencias, sao tambem parte importante deste estudo. As abordagens para reunir as preferencias de
um utilizador podem ser categorizadas em duas classes: (1) Configuracao semantica (Maternaghan and
Turner, 2013; Kao and Yuan, 2012): onde o utilizador especifica detalhadamente as suas preferencias
sobre certos dispositivos, servicos ou regras automaticas. (2) Reconhecimento de habitos (Chen et al.,
2012; Iglesias and Kastner, 2013; Rashidi and Cook, 2008; Rafferty et al., 2017): capazes de extrair
da rotina dos habitantes informacoes relativas aos seus interesses. Em sıntese, as preferencias de um
utilizador sao a configuracao que este pretende para os servicos, dispositivos ou politicas existentes
numa habitacao. Uma vez que os interesses dos utilizadores podem mudar ao longo do tempo ou de
acordo com a situacao (Hasan et al., 2006), a solucao desenvolvida utiliza uma combinacao entre estas
8
duas abordagens para melhor representar as preferencias dos utilizadores.
Perfil de Utilizador - e um conjunto de preferencias que determinado utilizador possui sobre os
servicos prestados pela habitacao. Essas preferencias podem relacionar-se, por exemplo, com a
iluminacao, climatizacao ou entretenimento. Concretamente, um utilizador pode ter preferencias sobre
o servico de climatizacao, preferindo a temperatura a 23º C. Pode ainda ter preferencias relacionadas
com o nıvel da intensidade luminosa e o canal de TV favorito. O conjunto de preferencias do utilizador
e, consequentemente, o seu perfil de utilizador.
2.2 Configuracao de Casas Inteligentes
USHAS (Kao and Yuan, 2012) e um sistema semantico de automacao residencial, que tem como
objetivo permitir a configuracao de uma habitacao de acordo com varios fatores como: a divisao, o
indivıduo, o dispositivo e ainda em que momento e executada uma determinada tarefa. Este sistema
utiliza Web Service (WS) e Web Services Description Language (WSDL), para executar os processos
automaticamente, Web Ontology Language (OWL) para descrever o ambiente da habitacao e para tor-
nar possıvel definir acoes por parte dos utilizadores usa a Semantic Home Process Languange (SHPL),
uma linguagem definida pelos autores.
A ontologia definida pelo USHAS e um dos pontos importantes deste trabalho, permitindo man-
ter, procurar e ainda escolher informacao de alto nıvel. A ontologia definida da a possibilidade ao
utilizador de poder dar uma ordem, como por exemplo, ”apagar todas as luzes do primeiro piso” e
consequentemente o sistema sabera que tem de apagar a luz X ou Y. Seis classes principais sao
definidas nesta ontologia: Pessoa (adulto, crianca, membro ou ate ladrao), Dispositivo (sensores e atu-
adores ou uma categoria em particular como ar condicionado), Tempo (tempo especifico, intervalo de
tempo ou repeticao periodica), Ambiente (luminosidade, humidade, entre outros), Evento (relacionado,
por exemplo, com a mudanca de estado de dispositivo ou localizacao de uma pessoa) e Localizacao
(por exemplo, sala de jantar ou cozinha). Esta ontologia da ao utilizador uma certa liberdade, podendo
abstrair-se no momento de definir novas acoes.
Na linguagem SHPL existem quatro categorias: pre-condicoes, variaveis, tempo de execucao e fluxo
de invocacoes. ”Se a temperatura for maior que 30 ºC as 6:00 da tarde, ligar o ar condicionado”, o valor
30 sera a variavel, ”Se a temperatura for maior que 30 ºC” sera a pre-condicao, 6:00 da tarde sera o
tempo de execucao e ligar o ar condicionado a invocacao. A linguagem permite testar tantas condicoes
quanto o desejado e da a possibilidade de expressar os conceitos de ”todos” ou ”nenhuns”, sendo util
quando e necessario referenciar multiplos dispositivos. O USHAS foi criado no sentido de permitir a
definicao semantica de varios processos, proporcionando um certo grau de automatismo a habitacao e
permitindo definir processos utilizado simples paginas web.
9
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
1 <?xml version=”1.0” encoding=”UTF-8”?>
2 <House Address=”Rua Olival 196” ID=”1” Name=”Lisbon House” Phone=”212183746”>
23
3 <FloorList>
4 <Floor HeightOrder=”0” ID=”1” Name=”Ground-floor” />
5 </FloorList>
6 <DivisionList>
7 <Division AccessLevel=”1” ID=”1” Name=”Living-room” RefFloor=”1” />
8 <Division AccessLevel=”3” ID=”2” Name=”Kitchen” RefFloor=”1” />
9 </DivisionList>
10 </House>
• Tipos de propriedades:
Como e possivel observar na Listagem 3.2, estao representados os tres tipos de propriedades
mencionados anteriormente, escalar, enumerado e vector. A propriedade escalar e uma percenta-
gem entre 0 e 100. O enumerado representa os modos de funcionamento de um ar-condicionado
e o vector com tamanho maximo 10, e o nome de um filme.
Listagem 3.2: Exemplo dos tipos de propriedades
1 <?xml version=”1.0” encoding=”UTF-8”?>
2 <ScalarValueTypeList>
3 <ScalarValueType ID=”1” MaxValue=”100” MinValue=”0” Name=”Percentage (0-100)”
NumBits=”8” Step=”1” Units=”%” />
4 </ScalarValueTypeList>
5 <EnumValueTypeList>
6 <EnumValueType ID=”1” Name=”AC-Heater Commands”>
7 <Enumerated Name=”Off” Value=”0” />
8 <Enumerated Name=”Heating” Value=”1” />
9 <Enumerated Name=”Cooling” Value=”2” />
10 </EnumValueType>
11 </EnumValueTypeList>
12 <ArrayValueTypeList>
13 <ArrayValueType ID=”1” MaxLen=”10” Name=”Movie name”>
14 </ArrayValueType>
• Tipos de dispositivos:
Um exemplo de um tipo de dispositivo e apresentado na Listagem 3.3. O tipo de dispositivo em
questao e um candeeiro ajustavel, que tem duas propriedades associadas, ligar/desligar (enume-
rado) e a intensidade luminosa (escalar).
24
Listagem 3.3: Exemplo de um TipoDispositivo
1 <?xml version=”1.0” encoding=”UTF-8”?>
2 <DeviceTypeList>
3 <DeviceType Description=”-” ID=”1” Name=”Adjustable Light - Cand , Lamp” RefDeviceClass=”1”>
4 <PropertyList>
5 <Property AccessMode=”RW” ID=”1” Name=”On-Off” RefValueType=”2” ValueType=”ENUM” />
6 <Property AccessMode=”RW” ID=”2” Name=”Luminosity” RefValueType=”1”
ValueType=”SCALAR” />
7 </PropertyList>
8 </DeviceType>
9 </DeviceTypeList>
• Dispositivos:
Na Listagem 3.4 e apresentado um dispositivo concreto composto por varios atributos, entre eles
um nıvel de acesso, um endereco, de modo a ser possıvel comunicar, a divisao a que pertence e
o id do tipo dispositivo a que esta associado.
Listagem 3.4: Exemplo de um Dispositivo
1 <?xml version=”1.0” encoding=”UTF-8”?>
2 <DeviceList>
3 <Device AccessLevel=”9,9” Address=”0100” ID=”1” Name=”Kitchen Cand” RefDeviceType=”2”
RefDivision=”2” UserBlocked=”2,2”>
4 <DeviceServiceList>
5 <DeviceService RefService=”1” />
6 <DeviceService RefService=”4” />
7 </DeviceServiceList>
8 </Device>
9 </DeviceList>
3.4 Comunicacao
Como explicado na seccao 3.1, para interagir entre diferentes dispositivos sao utilizados essencial-
mente tres tipos de mensagens:
• GET - permite ler o valor de uma propriedade de um dado dispositivo, possibilitando monitorizar
o seu estado;
25
• SET - permite escrever um novo valor numa propriedade de um dispositivo, oferecendo um me-
canismo para mudanca de estado;
• NOTIFY - mecanismo de alerta automatico caso o valor da propriedade de um dispositivo sofra
alteracoes.
Para enviar qualquer um destes tipos de mensagens e necessario enviar um pacote com tres cam-
pos fundamentais (Figura 3.6), o endereco do dispositivo (DevAddr), um descritor de propriedade (Prop-
Desc) e um valor (value). O endereco de um dispositivo pode ter ate 32 bits, e unico e e utilizado como
identificador global do dispositivo. O descritor de propriedade tem como funcao identificar o tipo de
propriedade pretendida, como tal e necessario explicitar o tipo de propriedade (escalar, enumerado ou
vetor), se o valor da propriedade e invalido (devera ser ignorado), e o ID associado ao tipo de proprie-
dade. Por ultimo o campo value, contem o valor da propriedade a ser enviada.
Figura 3.6: Estrutura de um pacote.
No caso da mensagem GET existe ainda a possibilidade de ler o valor da propriedade de um dispo-
sitivo e escreve-lo noutro dispositivo se os tipos de propriedade foram iguais (ambos int: 8,16 ou 32BIT,
ou ARRAY ). Num pacote SET podem opcionalmente ser identificados o dispositivo e a propriedade que
originaram a mensagem, desta forma e possıvel responder com um ACK ou um erro, caso qualquer um
destes se venha a verificar.
26
Capıtulo 4
Concepcao da solucao
A literatura estudada nos capıtulos anteriores permitiu-nos analisar cuidadosamente os diferentes
tipos de sistemas domoticos. Os seus pontos fortes e fracos foram estudados a fim de identificar o
que um sistema domotico deve ter e nao ter para agradar aos utilizadores. Que funcionalidades e
necessario melhorar ou manter para desenvolver uma solucao domotica realmente util.
Uma das funcionalidades importantes nos edifıcios inteligentes e a de garantir um espaco con-
fortavel para os seus ocupantes. Para criar esse espaco e necessario recolher informacao sobre os
utilizadores, resolver potenciais conflitos entre preferencias e aplicar otimizacoes. Neste capıtulo apre-
sentamos uma solucao pratica capaz de captar, aplicar e ajustar as preferencias dos utilizadores do
sistema DomoBus e resolver conflitos em espacos partilhados.
4.1 Caracteristicas Gerais
Depois de considerar diferentes possibilidades para o desenvolvimento da solucao, definimos estas
caracterısticas como principais para a solucao final:
• Definicao de perfis de utilizador: capazes de representar as preferencias de cada habitante, de
tal modo que seja necessario o menor nıvel de interacao possıvel com o sistema. E possıvel o uti-
lizador configurar detalhadamente as suas preferencias, mas tambem as atividades que pretende
vir a realizar.
• Refinar os perfis de utilizador existentes: o sistema adapta os perfis automaticamente, apren-
dendo com as alteracoes manuais que o utilizador realiza sobre as suas preferencias. Ajustando
os perfis em tempo real.
• Resolucao de conflitos entre utilizadores: flexıvel e que considera varios fatores como a hie-
rarquia dos utilizadores e as intencoes de cada habitante, adaptando-se a cada contexto.
27
Assumindo que o sistema sera utilizado no ambito de uma casa inteligente, a localizacao dos uti-
lizadores devera ser sempre conhecida. Os nossos algoritmos utilizam essa informacao para resolver
conflitos e aplicar os perfis dos utilizadores. Essa informacao pode ser obtida atraves da utilizacao de
smartwatches, smartphones ou um equipamento que possibilite o reconhecimento automaticamente na
entrada e saıda de uma divisao.
4.2 Areas de Preferencia
O conceito de areas de preferencia foi introduzido para permitir ao utilizador escolher quais os
servicos de uma casa que pode gerir. A diferenca entre um servico e uma area de preferencia e que
uma area de preferencia tem associado um nıvel de preferencia. Cada uma destas areas e composta
por propriedades especıficas e relacionadas com a area em questao, como ilustra a Figura 4.1.
Figura 4.1: Exemplo de areas de preferencia e as suas propriedades
Estas areas sao dinamicas, podendo ser modificadas em numero e em tipo. Se por exemplo, uma
habitacao nao dispoe de estores regulaveis, a area privacidade podera ser removida. Numa outra
habitacao, podera ser util ter uma area relacionado com a seguranca. Caso seja necessario adicionar
28
ou remover propriedades de uma area, tambem o podera ser feito, por exemplo remover a propriedade
”Estacao Radio” e adicionar uma outra relacionada com o tipo de musica.
Das areas de preferencia existentes, o utilizador pode escolher sobre quais as areas quer manter
preferencia, por exemplo apenas sobre as areas de Iluminacao e Privacidade, ou sobre todas elas.
Cada utilizador devera explicitar um nıvel de preferencia para as areas que escolheu. Concretamente,
o nıvel de preferencia corresponde a uma escala, que varia entre ”muito baixo”, ”baixo”, ”neutro”, ”alto”e
”muito alto”, representada por numeros naturais de 1 a 5 respetivamente. O nıvel de preferencia serve
para permitir ao sistema resolver conflitos automaticamente, caso se encontrem na mesma zona da
casa utilizadores com preferencias sobre as mesmas areas. Resumidamente, caso um utilizador deseje
por exemplo, a temperatura a 23º C, devera escolher um nıvel de preferencia (entre 1 e 5) para a area
da Climatizacao.
4.3 Perfis de Utilizador
O objetivo desta dissertacao e criar uma solucao altamente personalizavel mas ao mesmo tempo
automatica. Consequentemente, foram criados tres tipos de perfis de utilizador: o perfil generico, a
atividade e o perfil especıfico:
• Perfil Generico - Pratico e abrangente. Esta associado a uma ou mais areas de preferencia,
e rapido e facil de configurar (requer apenas uma configuracao inicial). Este perfil permite ao
utilizador configurar as suas preferencias mais regulares. Esta sempre disponıvel e pode ser
utilizado em varias habitacoes: na propria casa, na casa de um familiar ou de um amigo. O seu
funcionamento e automatico.
• Atividades - As Atividades servem um proposito diferente pois estao associadas a praticas re-
gulares como ler, ver televisao, ou fazer exercıcio. Sao ativadas manualmente pelo utilizador e
permitem a realizacao de tarefas espontaneamente. Por exemplo, para a atividade ler, podera
ser definido uma intensidade luminosa de 90% e volume de som desligado. Enquanto para a
atividade fazer exercıcio, podera ser definido um volume de som 80% e estacao de radio: M80.
As atividades sao configuradas individualmente por cada utilizador e sao tambem independentes
da habitacao.
• Perfil Especıfico - Este perfil e de ativacao automatica e permite explicitar as preferencias de um
utilizador em funcao de uma divisao (por exemplo a sala) ou conjunto de divisoes (por exemplo
todos os quartos). Este tipo de perfil permite inclusive configurar individualmente os dispositivos
de uma divisao. Consequentemente, devido a ser altamente configuravel este tipo de perfil obriga
29
Tabela 4.1: Sumario dos diferentes tipos de perfil
PerfisPerfil Generico Actividade Perfil Especıfico
Modo funcionamento Automatico Manual AutomaticoAplica-se a multiplas habitacoes Sim Sim Sim1
Permite conf. divisao Nao Nao SimPermite conf. dispositivo Nao Nao Sim
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
Ibero-Americana WWW/Internet 2004,Madrid, Spain, Oct. 2004.
C. Banker. (2016) Definicao de casa inteligente, acedido em setembro 2017. [Online]. Available:
https://www.coldwellbanker.com/blog/what-is-a-smart-home-2/
Markets and Markets. (2017) Crescimento esperado da automacao residencial ate 2023, acedido
em setembro 2017. [Online]. Available: http://www.marketsandmarkets.com/Market-Reports/
smart-homes-and-assisted-living-advanced-technologie-and-global-market-121.html
A. Brush, B. Lee, R. Mahajan, S. Agarwal, S. Saroiu, and C. Dixon, “Home automation in the wild: chal-
lenges and opportunities,” in proceedings of the SIGCHI Conference on Human Factors in Computing
Systems. ACM, 2011, pp. 2115–2124.
M. R. Alam, M. B. I. Reaz, and M. A. M. Ali, “A review of smart homes—past, present, and future,” IEEE
Transactions on Systems, Man, and Cybernetics, Part C (Applications and Reviews), vol. 42, no. 6,
pp. 1190–1203, 2012.
C. Maternaghan and K. J. Turner, “Policy conflicts in home automation,” Computer Networks, vol. 57,
no. 12, pp. 2429–2441, 2013.
C. Wilson, T. Hargreaves, and R. Hauxwell-Baldwin, “Smart homes and their users: a systematic analy-
sis and key challenges,” Personal and Ubiquitous Computing, vol. 19, no. 2, pp. 463–476, 2015.
Y.-W. Kao and S.-M. Yuan, “User-configurable semantic home automation,” Computer Standards & In-
terfaces, vol. 34, no. 1, pp. 171–188, 2012.
L. Chen, C. D. Nugent, and H. Wang, “A knowledge-driven approach to activity recognition in smart
homes,” IEEE Transactions on Knowledge and Data Engineering, vol. 24, no. 6, pp. 961–974, 2012.
F. Iglesias and W. Kastner, “A global approach of habit profiles for smart home control,” 13th Conference
of International Building Performance Simulation Association, pp. 1969–1976, aug. 2013.
58
P. Rashidi and D. J. Cook, “Adapting to resident preferences in smart environments,” in AAAI Workshop
on Preference Handling, 2008, pp. 78–84.
H. Luo, R. Wang, and X. Li, “A rule verification and resolution framework in smart building system,”
in Parallel and Distributed Systems (ICPADS), 2013 International Conference on. IEEE, 2013, pp.
438–439.
I. Armac, M. Kirchhof, and L. Manolescu, “Modeling and analysis of functionality in ehome systems:
dynamic rule-based conflict detection,” in Engineering of Computer Based Systems, 2006. ECBS
2006. 13th Annual IEEE International Symposium and Workshop on. IEEE, 2006, pp. 10–pp.
R. Nunes, “DomoBus - A New Approach to Home Automation,” 8CLEEE - 8th International Congress on
Electrical Engineering, Portugal, Jul. 2003.
B. Abdulrazak, S. Giroux, B. Bouchard, M. Mokhtari, and H. Pigot, Towards Useful Services for Elderly
and People with Disabilities: 9th International Conference on Smart Homes and Health Telematics,
ICOST 2011, Montreal, Canada, June 20-22, 2011, Proceedings. Springer Science & Business
Media, 2011, vol. 6719.
D. Tjosvold, “Conflict within interdependence: Its value for productivity and individuality,” Using conflict
in organizations, pp. 23–37, 1997.
I. Park, K. Lee, D. Lee, S. J. Hyun, and H. Y. Yoon, “A dynamic context conflict resolution scheme for
group-aware ubiquitous computing environments,” in Proceedings of the 1st International Workshop
on Personalized Context Modeling and Management for UbiComp Applications (ubiPCMM 2005),
2005, pp. 42–47.
V. Tuttlies, G. Schiele, and C. Becker, “Comity-conflict avoidance in pervasive computing environments,”
in On the move to meaningful internet systems 2007: OTM 2007 workshops. Springer, 2007, pp.
763–772.
R. Camacho, P. Carreira, I. Lynce, and S. Resendes, “An ontology-based approach to conflict resolution
in home and building automation systems,” Expert Systems with Applications, vol. 41, no. 14, pp.
6161–6173, 2014.
J. Rafferty, C. D. Nugent, J. Liu, and L. Chen, “From activity recognition to intention recognition for
assisted living within smart homes,” IEEE Transactions on Human-Machine Systems, vol. 47, no. 3,
pp. 368–379, 2017.
M. K. Hasan, K. Anh, L. Mehedy, Y.-K. Lee, and S. Lee, “Conflict resolution and preference learning in
ubiquitous environment,” in International Conference on Intelligent Computing. Springer, 2006, pp.
355–366.
59
S. Bandara, T. Yashiro, M. F. F. Khan, N. Koshizuka, and K. Sakamura, “Predicting collective user prefe-
rence for optimal comfort level in smart buildings,” in Consumer Electronics (GCCE), 2015 IEEE 4th
Global Conference on. IEEE, 2015, pp. 7–11.
R. J. L. Camacho, “Intelligent actuation in home and building automation systems,” 2014.
A. Dixit and A. Naik, “Use of prediction algorithms in smart homes,” International Journal of Machine
Learning and Computing, vol. 4, no. 2, p. 157, 2014.
P. Electronics, “X10 Home Gadgets. Acedido em Agosto 2017,” 1975. [Online]. Available:
https://www.x10.com/
E. I. B. Association, “KNX standard. Acedido em Agosto 2017,” 1990. [Online]. Available:
https://www.knx.org/
J. Nielsen and T. K. Landauer, “A mathematical model of the finding of usability problems,” in Procee-
dings of the INTERACT’93 and CHI’93 conference on Human factors in computing systems. ACM,
1993, pp. 206–213.
R. A. Virzi, “Refining the test phase of usability evaluation: How many subjects is enough?” Human
factors, vol. 34, no. 4, pp. 457–468, 1992.
J. C. Romano Bergstrom, E. L. Olmsted-Hawala, J. M. Chen, and E. D. Murphy, “Conducting iterative
usability testing on a web site: challenges and benefits,” Journal of Usability Studies, vol. 7, no. 1, pp.
9–30, 2011.
ISO/IEC25022:2016, “Systems and software engineering — Systems and software quality requirements
and evaluation (SQuaRE) — Measurement of quality in use,” International Organization for Standar-
dization, Geneva, CH, Standard, Jun. 2016.
C. Smith and T. Mayes, “Telematics applications for education and training: Usability guide,” Comission
of the European Communities, DGXIII Project, 1996.
T. Hargreaves, C. Wilson, and R. Hauxwell-Baldwin, “Who uses smart home technologies? representati-
ons of users by the smart home industry,” European Council for an Energy Efficient Economy (ECEEE)
Summer Study on Energy Efficiency in Buildings, 2013.
B. Andres, F. Alejandra, J. Miguel, S. Augusto, and W. Pedro, “Towards the evolution of smart home
environments: A survey,” International Journal of Automation and Smart Technology, vol. 6, no. 3, pp.
105–136, 2016.
60
Manual de Utilizador
Gestor de Perfis
Versão 1.0
Instituto Superior Técnico
Outubro 2017
Apendice A
Manual de Utilizador
61
Gestor de Perfis
Conteúdo
1. Introdução.......................................................................................................................................3
1.1. Âmbito e propósito..................................................................................................................3
1.2. Requisitos iniciais....................................................................................................................3
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.1. Botões principais......................................................................................................................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.1. Login.........................................................................................................................................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.
A Tempo 17 28 9 18 30 22 19 16 23 20 19 9 30Erros 0 0 0 0 0 0 0 0 0 0 0 0 0
B Tempo 60 90 74 72 84 64 50 68 72 70 72 50 90Erros 1 3 2 1 1 0 0 0 0 0.9 1 0 3
C Tempo 25 50 32 40 33 42 19 39 44 36 33 19 50Erros 0 1 1 1 0 1 0 0 0 0.6 1 0 1
D Tempo 5 20 10 3 10 55 5 12 19 15 10 3 55Erros 0 0 0 0 0 2 0 0 0 0.3 0 0 2
E Tempo 54 60 80 55 105 65 65 82 70 71 65 54 105Erros 0 1 1 0 0 0 0 1 0 0.4 0 0 1
F Tempo 60 90 50 52 74 65 54 63 55 63 60 50 90Erros 1 0 1 1 1 0 0 0 0 0.6 1 0 1
G Tempo 20 24 30 13 80 17 11 17 21 26 20 11 80Erros 0 0 1 0 2 0 0 0 0 0.4 0 0 2
H Tempo 3 5 3 2 5 7 3 5 4 4 4 2 7Erros 0 0 0 0 0 0 0 0 0 0 0 0 0
Legenda: Tempo = Tempo de Execucao (segundos), Erros = Numero de Erros.
80
Tabela D.2: Experiencia dos utilizadores
Tarefas Utilizadores Estatısticas1 2 3 4 5 6 7 8 9 Media Mediana Min. Max.
A 5 5 5 5 5 5 5 5 5 5 5 5 5B 4 4 4 5 3 5 4 5 4 4 4 3 5C 5 5 3 5 4 5 4 4 5 4 5 3 5D 5 5 4 5 5 5 5 5 5 5 5 4 5E 4 4 3 5 3 5 4 5 5 4 4 3 5F 3 4 4 5 4 5 4 4 5 4 4 3 5G 5 5 3 5 2 5 4 5 5 4 5 2 5H 5 5 5 5 5 5 5 5 5 5 5 5 5
Legenda: Min.= Valor Minimo, Max.= Valor Maximo.Dificuldade: 1) Muito Difıcil, 2) Difıcil, 3) Moderado, 4) Facil, 5) Muito Facil.
81