faz as operações e retorna um feedback para a TV que, por fim, informa ao usuário o(s) estado(s) atual (is) do(s) dispositivo(s). Toda essa comunicação, presente em cada operação feita pelo usuário, obedece a um protocolo de arquitetura, uma espécie de linguagem de comunicação desenvolvida especialmente para este sistema e que é compreendida por ambas as partes.
Figura 3. Visão Arquitetural
A comunicação com o servidor (controlador) é feita via socket, pelo qual são enviados pacotes com as alterações desejadas pelo usuário. Neles, são enviados o tipo, a identificação e o estado do dispositivo que se deseja alterar, como mostra a Tabela 1. Tabela 1. Formato padrão do pacote de comunicação com o servidor
Na Tabela 2 são mostrados os valores possíveis para cada campo do pacote que será enviado pela aplicação. Nela é possível identificar o tipo de dispositivo de acordo com o valor que lhe foi atribuído na especificação. Como pode haver mais de um dispositivo do mesmo tipo, é necessário um campo próprio de identificação para representar um dispositivo em particular. Finalmente, são mostrados os estados que podem ser atribuídos a cada dispositivo. Segundo esse protocolo, a lâmpada com o valor de estado 1 estará apagada e acesa se o valor for 2. Para abrir ou fechar a porta será seguido o mesmo raciocínio. Porém, há uma particularidade no dispositivo de alarme, que além dos estados ligado e desligado (1 e 2, respectivamente), pode assumir o estado “Alarmando”, representado pelo valor 3. Para a aplicação realizar consultas ao servidor, ela precisa enviar um pacote padrão (0, 0, 0) que significa a solicitação ao servidor da situação atual de todos os dispositivos. Sempre que a aplicação é iniciada, ela tenta uma conexão com o servidor. Se a conexão for estabelecida, o servidor envia um pacote padrão para que o sistema possa estar atualizado com a situação de todos os dispositivos e exibilos ao usuário quando ele estiver na cena de uso "Consulta" do programa. Uma situação possível para exemplificar a comunicação será o usuário querer acender a lâmpada 2. Para isso, será enviado o pacote (1, 2, 2) para o servidor. O servidor tratará a informação e retornará a nova situação dessa lâmpada para o set-top Box. DETALHES DE IMPLEMENTAÇÃO
Para que a automação residencial aconteça de fato, a televisão se comunica com um servidor. Esse, por sua vez,
Finalmente, o último aspecto que merece ser tratado é o da comunicação entre o usuário e a interface da aplicação, necessária para que ele saiba o que pode fazer, o que não pode, aonde deve ir para executar uma ação etc. Enquanto está manuseando o programa, sem se perder ou desistir de usá-lo, isto é, para que tenha total domínio sobre o sistema. [7] afirmam que cores, ao lado de palavras e menus, são potenciais signos de interface. Também é possível acrescentar nessa lista símbolos, ícones, movimentos e outros. Com exceção dos movimentos, todos os outros citados foram aplicados na GUI em questão e compõem sua comunicabilidade. Para informar o usuário tudo o que ele pode fazer em um dado momento, decidiu-se por botar todas as informações na própria tela, de modo organizado e rico em cores. DESENVOLVENDO EM GINGA-NCL
Ginga-NCL é o subsistema do middleware Ginga responsável por dar suporte às aplicações escritas na linguagem declarativa NCL. As aplicações desenvolvidas nessa linguagem têm a característica de serem voltadas para a manipulação direta de documentos hipermídia, visando principalmente sincronizar no tempo e no espaço vários objetos de mídia. Com o Ginga-NCL é possível escrever TIPO DO DISPOSITIVO (1 ... 255) 1 BYTE
ID DO DISPOSITIVO (1 ... 255) 1 BYTE
ID DO DISPOSITIVO
ESTADO DO DISPOSITIVO (1... 255) 1 BYTE
DISPOSITIVO
TIPO DO DISPOSITIVO
ESTADO DO DISPOSITIVO
LÂMPADA 1
1
1
1–2
LÂMPADA 2
1
2
1–2
PORTA
2
1
1–2
ALARME
3
1
1–3
CONSULTA
0
0
0
aplicativos em XHTML, podendo ou não utilizar CSS, que é uma linguagem na qual são declaradas propriedades e valores de estilização para os elementos do HTML. Também é possível implementar aplicações com técnicas de script, usando ECMA Script ou Lua. Além disso, é possível chamar códigos em Lua através de chamadas NCL. Por NCL ser uma linguagem declarativa, o programador não especifica nenhum detalhe das funcionalidades da aplicação, isto é, de como elas vão ser executadas. O que se determina é o que vai ser feito e o que vai ser usado. Isto significa que o comportamento da aplicação não muda de acordo com seu estado, ou seja, não há nenhuma decisão a ser tomada em tempo de execução.
236