Arquitetura Geral do Software

A arquitetura do sistema é composta de três grandes blocos que interagem entre si. Estes blocos são o cliente, o servidor e o hardware. Cada bloco possui uma ou mais funcionalidades, sendo que a troca de informações entre blocos garante o perfeito funcionamento do sistema.

Cliente

A figura do cliente é representada por um navegador Web. Sua principal função é exibir ao usuário o status de sua residência, além de possibilitar a interação por parte do usuário, permitindo que o mesmo possa realizar comandos remotos na sua residência, como por exemplo desligar a lâmpada da sala, ou capturar a imagem de vídeo de uma câmera na entrada da casa.
Devido a aplicação cliente se tratar de um navegador Web, protocolo de comunicação utilizado para comunicação entre o computador cliente e computador servidor é o protocolo HTTP.
Para o desenvolvimento da interface, utilizou-se três linguagens de programação:
• HTML – responsável por montar estaticamente a interface da aplicação no cliente;
• Javascript  – responsável por tornar a interface dinâmica a medida que o usuário interage com a mesma. Também utilizada para gerar atualizações na interface quando ocorreram mudanças na aplicação final (residência);
• PHP  – Devido a grande interação entre cliente-servidor, linguagens de geração de páginas dinâmicas tiveram que ser utilizadas.
Apesar da linguagem PHP ser responsável pela geração de páginas dinâmicas, o funcionamento da linguagem ocorre na máquina servidor, acoplado juntamente com o servidor Web.

Como característica importante, citamos a utilização de controle de sessão no cliente, o que garante a segurança da residência, pois somente através de autenticação eletrônica o usuário possui controle da residência.
Para auxiliar o desenvolvimento da interface no cliente, pode-se utilizar um editor de texto qualquer, no entanto, utilizou-se como ferramenta de desenvolvimento o software HomeSite. Este software foi escolhido devido às facilidades que o mesmo proporciona no desenvolvimento de aplicações utilizando as linguagens de programação empregadas no cliente.

Servidor

O servidor é o computador que está localizado junto à residência do usuário. Dentre as funcionalidades realizadas pelo servidor, citamos :
• envio e recepção de pacotes de controle através da porta RS-232;
• interpretação dos pacotes de controle enviados pelo controlador mestre;
• monitorar a base de dados em busca de alterações no status da aplicação;
• atualização da base de dados;
• atualização da interface no cliente.
A base de dados, no contexto do sistema, serve como gateway entre o computador cliente e o controlador mestre. Ela também é responsável em manter o status da residência, sendo que qualquer alteração no status da residência deve ser gravada na base de dados. A partir do momento que ocorre uma alteração na base de dados, o software que está rodando no computador servidor é 81
capaz de gerar comandos de atualização para a interface cliente, ou enviar pacotes de controle através da porta RS-232, gerando neste caso a atualização dos periféricos dentro da residência.
O software desenvolvido para rodar no servidor e realizar algumas das funcionalidades citadas acima foi totalmente desenvolvido em Java. Este software é capaz de comunicar-se com a porta de comunicação RS-232, assim como acessar a base de dados existente no servidor.
A base de dados utilizada no sistema foi desenvolvida em Access, pois o sistema operacional que está sendo utilizado para desenvolvimento do sistema pertence à família MS – Windows. O acesso a base de dados através do software desenvolvido ocorre com a utilização de JDBC (Java Database Connectivity) [17][25], utilizando o driver denominado JDBC-ODBC.
Como parte da arquitetura necessária para alcançar o objetivo do trabalho existirá instalado um servidor Web, rodando e ativo, localizado na residência. Sua finalidade é armazenar a interface da residência. O servidor Web escolhido para suportar nosso sistema foi o servidor Web Apache. O principal motivo pela escolha deste servidor Web podem ser justificadas pelas seguintes características: robusto, confiável, largamente utilizado na internet, de fácil instalação e principalmente por suportar diferentes plataformas de hardware.
Devido as características gerais da arquitetura do sistema, é necessário a utilização de linguagens que permitam a geração de páginas dinâmicas e acesso a banco de dados via Web.
Conforme descrito na Seção 6.2.5, a linguagem PHP provê as características citadas acima, além de: (i) possuir compatibilidade com servidores Web Apache (normalmente linguagens de geração de páginas dinâmicas rodam acopladas a um servidor Web); (ii) ser compatível com um grande número de servidores Web existentes no mercado, assim como um grande número de plataformas computacionais; (iii) suportar um grande número de banco de dados diferentes disponíveis no mercado, garantindo assim a portabilidade do sistema entre diferentes plataformas, servidores Web e fabricantes de banco de dados.
Dentre as razões citadas, devemos salientar que a linguagem PHP foi totalmente projeta para o desenvolvimento de aplicações Web. Como parte de seu projeto inicial, o objetivo da linguagem é proporcionar aos programadores o desenvolvimento de sistemas Web de maneira fácil, simples e rápida.

Debugger (Hardware)

O hardware é representado pelo controlador mestre, juntamente com os nodos acoplados a ele via barramento CAN. Sua principal função é distribuir aos nodos os pacotes de comandos recebidos através da interface RS-232, assim como enviar para o computador servidor pacotes de controle.

Devido a necessidade de verificar o que o computador servidor está enviando através da porta RS-232, foi desenvolvido um software de debug que mostra na tela todas as informações que chegam até ele, logo, a partir deste momento podemos verificar se a implementação do software no computador servidor está de acordo com o protocolo CAN explicado na Seção 8.5. O software de debug também possibilita que pacotes de controle sejam enviados ao servidor, neste caso, simulando o envio de pacotes como se fosse o próprio controlador mestre, permitindo assim o teste das funcionalidades realizadas pelo software residente no servidor.

Arquitetura do Servidor

Esta Seção apresenta o servidor, dividido em três partes: comunicação com o cliente, banco de dados e comunicação com o controlador mestre.

Comunicação com o cliente

Como descrito na Seção 2, toda a comunicação com o computador cliente ocorre através do protocolo HTTP. A distribuição das informações através deste protocolo é feita através de um servidor Web Apache, versão 1.3.14, rodando no servidor. Todas as requisições que partirem do computador cliente serão recebidas pelo servidor Web. O servidor é responsável por gerenciar estas requisições e respondê-las ao longo do tempo ao(s) cliente(s).
A homepage da residência é armazenada no disco rígido do computador, cujo diretório é diretamente mapeado no servidor Web, permitindo assim a disponibilização da homepage na internet. Para o desenvolvimento da homepage, foram utilizadas as linguagens de programação HTML, Javascript e PHP.
A linguagem PHP é executada no servidor Web e gera saídas de texto no formato HTML / Javascript, que neste caso quando enviadas através do protocolo HTTP ao cliente (navegador Web) serão interpretadas, montando a interface visual e um conjunto de funcionalidades oferecidas ao usuário.

Banco de dados

O banco de dados utilizado para o desenvolvimento do sistema foi o Access, devido ao desenvolvimento do trabalho ocorrer sobre a plataforma Windows NT. O banco de dados Access apresenta ótima compatibilidade, desempenho e interface de fácil interação. A utilização de banco 83 de dados em Access não compromete a portabilidade do sistema, pois todos os tipos de dados utilizados no banco de dados são comuns entre fabricantes de banco de dados, o que garante que através de comandos SQL possamos migrar o banco de dados atualmente feito em Access para outros sistemas de banco de dados.
Na Figura 56 apresentamos as tabelas utilizadas no sistema, assim como seus respectivos relacionamentos. A seguir, descreveremos detalhadamente todas as tabelas e relacionamentos  existentes no banco de dados criado para suportar o sistema proposto no trabalho. A Figura 56 ilustra no canto superior esquerdo a tabela Usuarios. Sua principal função é armazenar os usuários que possuem permissão de acesso à homepage da residência e consequentemente o acesso àsaplicações desta. Também indica quais usuários possuem acesso a interface de manutenção deusuários. Na Tabela 8 informações mais detalhadas são fornecidas.

As colunas acesso_permitido, acesso_manutencao são definidas como do tipo byte, no entanto, para o sistema essas colunas tem significado boleano, ou seja, verdadeiro ou falso. Neste caso representamos verdadeiro pelo número 1 e falso pelo número 0.
Visando aumentar a segurança e a confiabilidade do sistema, a senha do usuário é criptografada e armazenada no banco de dados. O algoritmo de criptografia utilizado pelo sistema é  o md5, com fingerprint de 128 bits (link [30]). O algoritmo md5 é um algoritmo do tipo irreversível e sua principal utilização é comparação de strings criptografadas. Seu funcionamento é simples, basta uma string qualquer ser informada e o algoritmo automaticamente retorna outra string de exatamente 32 bytes. A senha do usuário é armazenada criptografada. A todo momento que o usuário realizar uma tentativa de login no sistema, a senha digitada é criptografada e comparada com a senha existente no banco de dados, se as strings forem iguais e o usuário possuir no banco de dados permissão de acesso ao sistema (coluna acesso_permitido), o usuário é aceito pelo sistema.
No trecho de código abaixo mostramos como ocorre a criptografia de uma string através do algoritmo md5 utilizando a linguagem PHP.

Outra tabela existente no banco de dados é a tabela denominada TabelaNodos. Esta tabela é responsável em armazenar as informações referentes ao periféricos existentes na residência. A Tabela 9 representa a estrutura de dados utilizada na TabelaNodos.

Os campos desta tabela de nodos são descritos abaixo.
• ID_NODO – é a chave primária da tabela e sua principal função é permitir o relacionamento entre a TabelaNodos com a TabelaDados.
• classe – representa a classe da aplicação dentro da residência. Exemplo: iluminação, refrigeração;
• aplic – representa a aplicação propriamente dita. Exemplo: dentro da classe iluminação existe a aplicação lâmpadas, dimmers, etc;
• nodo_id – representa um conjunto finito de aplicativos de uma mesma aplicação;
• tamanho – indica o número bytes utilizado para que a aplicação seja controlada;
• dirty_mestre – indica que o controlador mestre está desatualizado em relação a base de dados;
• dirty_servidor – indica que o estado da base de dados foi alterado e o servidor deve enviar comandos para a atualização da interface cliente;
• nro_perifericos – indica o número de periféricos existentes para uma aplicação;
• atualizando – indica que o registro está sendo atualizado e garante que aquele registro não seja lido antes de sua atualização ser considerada concluída;
• extensao – o envio/recepção de pacotes maiores que 8 bytes ocorrem normalmente para arquivos transportando imagens, vídeos, etc. Neste caso existe a necessidade de sabermos qual é o tipo de arquivo que trafega para uma determinada aplicação, pois no término do processo de envio, o arquivo deve ser salvo com a extensão correta para que depois esse arquivo posso ser interpretado pela aplicação cliente o navegador Web;
• descricao – descrição que indica ao servidor como ele deve fazer a atualização da interface do cliente.
As colunas dirty_mestre, dirty_servidor e atualizando como no caso da tabela Usuarios, representam informações boleanas, sendo assim, o número 0 representa falso e o número 1 verdadeiro.

A TabelaDados é a terceira e última tabela do banco de dados. A responsabilidade desta tabela é armazenar os dados referentes as aplicações existentes na residência.

Abaixo explicamos detalhadamente o significado de cada coluna existente na TabelaDados.
• ID_NODO – utilizada para identificar qual é a aplicação que o registro está associado na TabelaNodos;
• indice – indica qual é a posição do byte dentre todos os bytes existentes para aquela aplicação específica;
• dado – representa o dado da aplicação.
O relacionamento criado entre as tabelas TabelaNodos e TabelaDados existe para permitir identificar, quais são os dados existentes para cada aplicação. Desta forma, a coluna denominada ID_NODO em ambas as tabelas é utilizada para efetivar este relacionamento.
Esta organização do banco de dados garante independência das aplicações na atualização da base de dados. Em outras palavras, pacotes de controles que chegam ao servidor são  gravados diretamente na base de dados, não importando que tipo de aplicação está enviando estes pacotes.
A estrutura de banco de dados planejada e utilizada atualmente não é a mesma estrutura planejada na primeira versão do banco de dados. A primeira versão desenvolvida tornouse inviável, pois para cada tipo de aplicação existente deveria haver uma estrutura de banco de dados proprietária de acordo com esta aplicação, logo, para cada novo tipo de aplicação adicionada ao sistema, era necessário preparar a base de dados e inclusive modificar o programa Java que roda no servidor para suportar esta nova aplicação, já que as estruturas de banco de dados também foram criadas neste momento.
Devido a estas exigências técnicas (necessidade de refazer todo o banco de dados a cada aplicação), tornou-se inviável a utilização desta estrutura. Como solução a este problema, planejou-se a estrutura de banco de dados atual, a qual que é independe da aplicação, pois informações referentes às aplicações são sempre armazenadas na TabelaNodos e os dados referentes a estas aplicações são armazenados na TabelaDados.
Nesta Seção apresentamos e explicamos as estruturas de dados utilizadas neste trabalho. Na próxima Seção iremos descrever como o sistema desenvolvido em Java interage com o banco de dados.

Comunicação com o banco de dados / controlador mestre

(comunicação serial)
Como já fora dito na Seção 7.1.2, o banco de dados serve de gateway entre a aplicação cliente e o hardware, tendo a responsabilidade de guardar o status das aplicações da residência. Também já foi visto que toda a comunicação com o controlador mestre (hardware) ocorre através da porta de comunicação serial padrão RS-232,enviando e recebendo pacotes de controle.
Devido à necessidade de implementação destas funcionalidades, desenvolveu-se um software responsável pelo controle/atualização do banco de dados, juntamente com o controle da porta de comunicação RS-232. O software que roda no servidor foi desenvolvido totalmente em Java. O acesso à base de dados acontece através dos métodos da biblioteca JDBC, utilizando o driver JDBC-ODBC. Para a implementação da comunicação serial utilizando RS-232 utilizamos o pacote desenvolvido pela Sun Microsystems denominado de CommAPI .

Devido a utilização da linguagem Java, todo o desenvolvimento é orientado a objetos, sendo que todas as operações realizadas pelo software são executadas através da chamada de métodos destes objetos. A utilização da linguagem Java também garante a portabilidade do sistema entre diferentes plataformas. Para que o sistema seja portado para outra plataforma, a única mudança que deve ser feita no código fonte é na linha de código que faz a carga do driver de banco de dados. As Seções seguintes detalham os dois componentes deste software:
• Comunicação serial, liga o software ao hardware;
• Acesso a base de dados.
A Figura 58 ilustra o relacionamento dos métodos utilizados pela aplicação para a comunicação com o banco de dados e porta de comunicação RS-232 que serão apresentandos nas Seções seguintes:
Figura 58 – Métodos de acesso a base de dados e porta de comunicação RS-232

Comunicação serial

Este módulo gerencia o envio e a recepção de pacotes de controle em paralelo. A qualquer momento o controlador mestre pode enviar pacotes, neste caso o software deve estar preparado para recebe-los.
Sendo assim, utilizou-se o conceito de threads para possibilitar a monitoração da porta serial, pois ao mesmo tempo em que a porta serial é monitorada, outras operações devem ser realizadas pelo software, logo, somente com a utilização de threads podemos tratar eventos em paralelo.
Para conseguir classificar os bytes que chegam na porta serial e montar um pacote de controle, seja ele de qual for o tipo, criou-se um método chamado de montaPacoteControle(), o qual sempre recebe o byte proveniente da porta serial. Internamente a este método, mecanismos de controle e sequenciamento foram implementados para que o pacote de controle seja identificado dentro da seqüência de bytes que chegam. Atualmente classificamos os pacotes como sendo de dois tipos :
• Pacotes Pequenos – Pacotes com até 8 bytes de tamanho
• Pacotes Grandes – Pacotes maiores que 8 bytes.
Devido a existência destes dois tipos de pacotes, foram criadas duas implementações diferentes para suportá-los.
No caso de pacotes pequenos, à medida que os bytes chegam na porta serial, e o método montaPacoteControle() é chamado, o método gerencia a montagem do pacote. De acordo com a seqüência dos bytes, juntamente com as informações contidas nestes bytes, consegue-se interpretar e extrair informações destes (segundo a especificação do protocolo CAN) e montar a classe chamada PacoteControle, que possui os seguintes atributos: Classe, aplicação, nodo id, tamanho, RTR, dados.
No final do processo, quando o pacote de controle é montado, temos dividas as informações listadas acima em forma de atributos. Logo, para obtermos as informações da classe basta utilizarmos os métodos específicos para cada atributo. Por exemplo: para obtermos a Classe do pacote de controle que acaba de ser montado, devemos simplesmente chamar o método getClasse() e assim sucessivamente para cada atributo (getAplicacao(), getNodoId(),etc).
No caso de pacotes grandes a implementação foi realizada de maneira diferenciada, pois para pacotes pequenos, todos os bytes referentes a um pacote chegam na porta serial em seqüência.
No entanto, para pacotes grandes, nem sempre isso ocorre, pois bytes de outros pacotes podem chegar misturados aos de pacote grande. Neste caso, o software deve implementar uma lógica que encaminhe o pacote para a “fila” correta, até que esta fila atinja o tamanho do pacote, montando assim o pacote grande. A Figura 59 representa graficamente este problema. Note que o servidor está recebento uma sequencia de pacotes com Identificador A, que são fragmentos (sub-pacotes) de um pacote grande. Porém o quarto pacote recebido é de outra origem, possivelmente um pacote de controle comum (pacote pequeno).

A lógica implementada no software servidor funciona da seguinte forma. Sempre que o sistema identificar que um pacote grande está para ser recebido, este pacote é adicionado em uma fila de pacotes grandes. A partir deste momento, já possuímos uma identificação deste pacote na fila. Todas as informações que chegaram através da serial com este identificador, são gravadas em forma de atributos em sua respectiva entrada na fila. Desta forma é possível ao sistema gerenciar o recebimento dos bytes de dados para cada pacote grande. A cada pacote que chega através da serial é feita uma verificação se este faz parte de um pacote grande. Sendo um pacote grande, automaticamente é feita uma busca pelo identificador na lista de pacotes grandes para verificar se o pacote já possui entrada. Em caso positivo, recupera-se o contexto atual do pacote e adiciona-se os novos bytes de dados (nova remessa de dados) que estão chegando a partir da posição do último byte que foi gravado. Em caso negativo, o pacote grande que está sendo enviado é adicionado na lista. Se não for pacote grande o tratamento é feito como descrito anteriormente para o caso de pacotes pequenos.
A Figura 60 representa a fila de pacotes grandes. Percebe-se que com o nodo da lista com ID A estão todos os pacotes com este ID. Em cada um desses pacotes está contida até 8 bytes de dados que representam um parte dos dados enviados pelo processo de envio de pacotes grandes. O último pacote recebido (ID A e Seq4) é identificado com pertencente a lista de ID A, sendo o mesmo adicionado a esta lista. Ainda n Figura 60, podemos visualizar a existencia de recebimento de mais duas mensagens de pacotes grandes (ID B e C).

Como visto anteriormente, explicamos a recepção de pacotes de controle enviados pelo controlador mestre, agora iremos tratar do caso inverso, o sistema enviando pacotes de controle para o controlador mestre.
Durante o envio de pacotes pelo sistema, possuímos duas situações distintas: o envio de pacotes pequenos e o envio de pacotes grandes. Devido a necessidade de envio de pacotes pela porta serial, foi criado um método denominado de enviaPacote(). Este método recebe os seguintes parâmetros: Classe, aplicação, nodo id, RTR, tamanho, dados.
Todos estes parâmetros são declarados ao sistema como array de bytes, pois trabalhando diretamente com este tipo de dado o processo de envio através da porta serial é simplificado pois a mesma é apta para trabalhar diretamente com o tipo byte.
Dentro da lógica do método enviaPacote() é feita a distinção através do parâmetro tamanho se o pacote que está sendo enviado é um pacote grande, neste caso maior que 8 bytes, ou um pacote pequeno. É também internamente ao método enviaPacote() que a montagem dos pacotes a serem enviados pela serial é realizada, de acordo com as normas do protocolo CAN.
Se o pacote for do tipo pacote pequeno, os métodos de envio de bytes pela porta serial existentes na biblioteca CommAPI são invocados e os bytes são transmitidos diretamente de acordo com a seqüência especificada pelo protocolo CAN.
No caso de pacotes grandes, a lógica utilizada para o envio de pacotes utilizando CAN é um tanto quanto mais complexa, pois como já foi visto na Seção 8.4, os dados devem ser fragmentados várias vezes em tantos pacotes quanto forem necessários, pois cada pacote pode transportar até no máximo 8 bytes de dados, sendo assim, se quisermos transmitir 20 bytes de dados, o envio destes dados serão divididos em três pacotes, cada um contendo 8 + 8 + 4 bytes de dados. Esta lógica é implementada pelo método enviaPacoteMaior(). Este método é um método privado que somente é invocado internamente ao método enviaPacote(), sendo assim, quando pacotes grandes devem ser enviados, o método enviaPacote() identifica que é um pacote grande e automaticamente invoca o método interno enviaPacoteMaior(), que por sua vez é responsável em montar os pacotes seguindo o protocolo CAN e posteriormente enviá-los através da porta serial.
A seguir veremos com detalhes a interface de comunicação com o banco de dados implementada no software existente no servidor.

Acesso a base de dados

Na questão do acesso a base de dados, temos dois eventos que automaticamente necessitam que ocorra o acesso a base de dados:
• Chegada de pacotes através da serial;
• Envio de pacote através da porta serial.
Chegada de pacotes através da serial

Devido a esta interação do sistema com a base de dados, criou-se uma classe denominada BancodeDados, cujo principal objetivo é prover métodos que interajam com a base de dados de acordo com as necessidades do sistema.
Quando um pacote é considerado montado, também passa a ser responsabilidade deste método avisar ao banco de dados que existe um pacote de controle disponível e que o mesmo deve ser salvo na base de dados. Como conseqüência da chegada de pacotes de controles, necessitamos atualizar a base de dados com as informações provenientes deste pacote. Visando alcançar este objetivo, criou-se um método na classe BancodeDados denominado gravaPacote(). Internamente a este método é realizada uma atualização sobre o registro específico referente à aplicação que teve mudança de status por algum motivo. Este registro encontra-se localizado na tabela do banco de dados denominada TabelaNodos.
Este método recebe como parâmetro as seguintes informações provenientes do pacote de controle que acaba de ser montado :
• classe – classe da aplicação;
• aplicação – tipo da aplicação;
• nodo id – nodo id da aplicação;
• tamanho – tamanho em número de bytes da área de dados;
• dados – array de bytes contendo os dados;
• dirty_mestre – indica que a atualização deve ser propagada ao controlador mestre (houve atualização do status da residência através do computador cliente);
• dirty_servidor – indica que a atualização deve ser propagada ao computador cliente (houve atualização do status da residência através do controlador mestre).
Para o registro específico, são atualizadas informações tais como o tamanho atual do pacote, os dados referentes a este pacote e se a atualização deve ser propagada ao controlador mestre ou ao computador cliente (interface Web).
É importante salientarmos que os dados referentes a uma aplicação específica estão armazenados na tabela TabelaDados, sendo assim, a atualização dos dados ocorre sobre esta tabela.
Para esta atualização põem-se em prática o relacionamento que existe entre as tabelas TabelaNodos e TabelaDados, pois a partir do ID_NODO obtido a partir do registro da aplicação (TabelaNodos), conseguimos encontrar todos os dados referentes àquela aplicação (TabelaDados).
No início do processo de atualização das informações referentes a uma aplicação, a primeira operação que é realizada é modificar o status da coluna atualizacao indicando que este registro está sendo atualizado, após isso, as demais operações de banco de dados são realizadas. Ao final do processo de atualização, quando todas as operações de atualizações referentes a esta aplicação já estão concluídas, o status da coluna atualizacao volta ao normal indicando que este registro não está mais sendo atualizado.

Envio de pacote através da porta serial

O envio de pacotes através da porta serial para o controlador mestre deve ocorrer sempre que a coluna dirty_mestre da tabela TabelaNodos estiver com o seu valor booleano em true.
Na classe BancodeDados criou-se o método monitoraMestre(), sua função principal é procurar no banco de dados por aplicações que estejam com o status desatualizado em relação ao controlador mestre (coluna dirty_mestre com valor igual a true) e enviar estas informações (classe, aplicação, nodoid, dados, etc) através da porta serial utilizando o método descrito anteriormente chamado enviaPacote().
Para que constantemente o status do banco de dados em relação ao controlador mestre seja monitorado, o método monitoraMestre() deve ser chamado de tempos em tempos. Para que isto seja possível, novamente utilizou-se o conceito de threads, sendo assim, criou-se uma thread que é executada em segundo plano, e que em um intervalo definido de tempo invoca o método monitoraMestre(), que por sua vez envia os pacotes de controle ao controlador mestre.

Arquitetura do cliente

Neste Capítulo descreveremos o processo de funcionamento da interface Web no cliente.
Essa interface possui quatro funcionalidades básicas:
• Autenticação de usuários no sistema;
• Atualização da interface Web;
• Atualização do status da residência;
• Manutenção dos usuários do sistema.

Autenticação de usuários no sistema

O acesso ao sistema ocorre mediante a autenticação do usuário através de uma tela onde deve-se obrigatoriamente informar um usuário e senha, seguindo o mesmo conceito utilizado em redes corporativas.
O controle da sessão do usuário no navegador Web, é realizado com a utilização de cookies de sessão. Cookies são informações que um site Web envia ao seu browser, permitindo que o site Web possa ler estas informações quando desejar.
Os cookies são classificados em dois tipos:
• Cookies de sessão – ficam armazenados na memória do computador e duram até que a sessão do browser seja fechada.
• Cookies persistentes – ficam armazenados no disco rígido do computador, por isso são denominados persistentes.
No processo de autenticação no sistema, o usuário informa ao sistema um usuário e senha.
Neste momento o sistema criptografa com md5 a senha digitada e acessa a base de dados procurando se existe realmente o usuário. Se o usuário existe, compara a senha digitada que já está criptografada com a senha contida na base de dados. Se forem iguais, o usuário tem permissão de acessar a residência caso a coluna acesso_permitido possua o valor 1 (verdadeiro).
Quando ocorre sucesso na autenticação do usuário, automaticamente é criado um cookie de sessão e o usuário é encaminhado para a interface de controle da residência. Se por algum motivo ocorrer algum problema na autenticação do usuário (ex.: senha incorreta), o cookie não é criado e o usuário não terá acesso ao sistema.
O encerramento da sessão do usuário pode ocorrer de duas formas. A primeira delas é fechando todas as instâncias do navegador Web que estiverem ativas, pois o cookie de sessão permanece ativo enquanto o navegador Web estiver ativo, neste caso, fechando os navegadores garantimos o término da sessão no sistema. Outra maneira possível é através da opção Logout, que encontra-se na interface interna do sistema.
É importante salientar que caso nenhuma das duas alternativas acima seja tomada, a sessão continuará ativa. Neste caso pode-se voltar normalmente a interface de controle da residência sem a necessidade de autenticação.

Atualização da interface Web

A atualização de interface Web, que ocorre quando há modificações no status da residência.
A interface Web possui os seguintes frames:
• Frame 1 – Bibliotecas Javascript;
• Frame 2 – Programa PHP de leitura da base de dados;
• Frame 3 – Programa PHP para atualização da base de dados;
• Frame 4 – Menu de opções;
• Frame 5 – Aplicações encontradas na residência.
Os frames 1, 2 e 3 são invisíveis para o usuário, pois se tratarem de frames responsáveis unicamente pelo processamento de informações que ocorrem em segundo plano na interface cliente.
No frame 2, existe um programa desenvolvido em PHP cuja principal função é ler a base de dados contida no servidor e verificar quais dos registros da base de dados estão desatualizados em relação ao computador cliente (coluna dirty_servidor), com base nestes registros, o programa PHP gera comandos Javascripts que atualizam a interface Web. Como se fosse uma thread, este programa é invocado de tempos em tempos garantindo a atualização da interface Web. Com a utilização de comandos Javascript para atualização da interface, juntamente associada com a monitoração constante da base de dados sem a necessidade de interação do usuário, a atualização da interface ocorre de maneira automática sem que o usuário precise clicar em um botão de “Atualizar” a todo instante. Esta é uma importante vantagem do sistema, uma vez que o usuário é automaticamente informado de tudo que é monitorado na residência, possibilitando, inclusive, o recebimento de menssagens de alarme na interface.
O programa PHP acessa o banco de dados através de um conector de banco de dados fornecido pela própria linguagem, no caso da migração do sistema para outras plataformas, esta linha poderá ser modificada de acordo com o banco de dados existente na nova plataforma.
O programa PHP, gera comandos Javascripts de atualização e também é capaz de acessar bibliotecas de funções também escritas em Javascript.
Devido a dinâmica utilizada para a atualização da interface cliente, criou-se uma biblioteca de funções Javascript. Esta biblioteca está localizada no frame 1 e atualmente agrupa um número determinado de funções úteis para as aplicações já desenvolvidas. A medida que novos controles da residências são implementados na interface, esta biblioteca Javascript deve incluir as novas funcionalidades que serão necessárias.
Com a crescente utilização do navegador Web Internet Explorer, a homepage da residência foi construída baseando-se na versão 4.0 deste navegador Web. Devido aos avançados recursos de  Javascript utilizados para permitir a atualização da homepage sem a interação do usuário, é possível que nem todas as funcionalidades empregadas sejam suportadas por outros navegadores Web.

Actualização do status da residência

Toda a atualização do status da residência ocorre antes sobre o banco de dados, sendo assim, a interface cliente comunica-se diretamente com o banco de dados de acordo com a interação do usuário com a interface cliente. Após este passo, o programa desenvolvido em Java responsabilizase em repassar as mudanças da base de dados através da porta serial.
Neste primeiro momento, constriu-se três aplicações diferentes para a residência :
• Lâmpadas;
• Dimmers;
• Captura de vídeo.
Na aplicação de lâmpadas, controla-se determinadas lâmpadas da residência.
Dimmers são responsáveis em mensurar a grandeza de determinadas aplicações. Por exemplo: um termômetro para medir a temperatura da cozinha, lâmpadas com controle de intensidade, temperatura da geladeira, etc.
Captura de vídeo representa a imagem de determinada peça da residência que é capturada por uma câmera de vídeo e enviada ao computador cliente.
Como vemos na Figura 62, dependendo da aplicação, a interface oferece um conjunto de informações ao usuário. As informações que a interface pode exibir ao usuário são as seguintes :
• Descrição da aplicação – descreve qual é a aplicação que está sendo controlado;
• Ação – indica a ação que pode ser comandada sobre uma determinada aplicação;
• Localização – localização da aplicação dentro da residência;
• Estado atual – corresponde ao estado atual da aplicação dentro da residência;
• Data e hora – indica a data e o horário referente ao status da aplicação.
A interação que acontece entre o usuário e a residência ocorre através da coluna ação, permitindo ao usuário interagir diretamente com uma determinada aplicação. No caso de lâmpadas, podendo ligar e desligá-las. Para dimmers, podemos atualizar o seu valor de acordo com o tipo de dimmer.

No momento que o usuário realiza algum comando, devemos atualizar a base de dados. Para que isso seja possível, quando o comando é realizado, o novo status da aplicação é capturado  através de comandos Javascript e é enviado para processamento no frame 3, cuja responsabilidade é atualizar a base de dados, indicando que a aplicação está com seu status desatualizado em relação ao controlador mestre (dirty_mestre).

Manutenção dos usuários do sistema

Visando permitir que novos usuários sejam adicionados ao sistema, possibilitando o acesso dos mesmos ao controle da residência, criou-se uma interface de manutenção de usuários.
A disponibilização desta interface ocorre somente para o(s) usuário(s) que possuir(em) permissão para executar tal operação. Isto só é possível através da existência da coluna acesso_manutencao da tabela Usuarios.
Na interface de manutenção dos usuários, estão disponibilizadas as opções de: inclusão, alteração, exclusão Na Figura 63 apresentamos a interface de administração de usuários do sistema.

Inclusão

Permite ao usuário que possui permissão de manutenção (visando facilitar a compreensão, chamaremos este usuário de administrador) incluir novos usuários ao sistema.
Está opção está disponível através do botão inclusão. Deve-se informar o nome, e senha do novo usuário, sendo que a senha deve ser informada duas vezes.

Por configuração default, no momento da inclusão de um usuário, automaticamente o mesmo possui permissão de acesso ao sistema e não possui permissão de acesso a interface de manutenção. Para que estas opções sejam alteradas, deve-se executar a operação de alteração.

Alteração

A partir desta opção o administrador pode alterar os dados referentes a um usuário cadastrado no sistema.
Para alterar informações de um usuário, basta clicar sobre o seu nome para que a tela de alteração seja exibida .

Na alteração, o administrador pode modificar informações como por exemplo o nome do usuário, sua senha, permissão de acesso ao sistema ou até mesmo torná-lo um administrador do sistema.

Exclusão

Permite ao administrador excluir usuários permanentemente da base de dados.
Para isso basta que o administrador selecione os usuários que deseja excluir e clique no botão excluir.

Arquitetura do Debugger

O debugger na implementação de software simula o comportamento do hardware, que comunica-se diretamente com o computador servidor através da porta de comunicação serial RS- 232C. O debugger tem por finalidade exibir na tela todos os pacotes de controle que partem do computador servidor. O software de debugger possibilita também que pacotes de controles sejam enviados para o computador servidor.

Como característica do envio de pacotes, existe a possibilidade de envio de pacotes pequenos (menores de 8 bytes) utilizado normalmente para o controle de lâmpadas e dimmers. Outra possibilidade é o envio de pacotes grandes (maiores que 8 bytes).
Aplicações que utilizam o envio de pacotes grandes normalmente trabalham diretamente com arquivos, neste caso, por exemplo, enviando a imagem capturada por uma câmera de vídeo.
Para pacotes pequenos, o usuário informa diretamente na interface do debugger as informações sobre este pacote (classe, aplicação, nodoid, dados, etc). Também é possível que pacotes grandes sejam enviados utilizando o mesmo processo, no entanto, visando simular o envio de pacotes com tamanhos maiores, foi adicionado ao debugger a capacidade de enviar arquivos, desta forma, podemos facilmente enviar uma imagem ao computador servidor e visualizarmos sua exibição na interface Web.
Na Figura 67 apresentamos a interface desenvolvida para o software de debugger. Podemos visualizar na interface campos como por exemplo classe, aplicação, nodo ID, RTR. Estes campos deverão ser preenchidos, pois para a montagem dos pacotes, essas informações são essenciais.
s dados propriamente ditos podem ser obtidos de duas maneiras, a primeira é preenchendo o campo denominado de dados (obrigatoriamente deve ser preenchido o campo de DLC que indica a número de bytes de dados), a segunda maneira é utilizando um arquivo, desta forma o arquivo representa os dados que devem ser enviados. Para isso deve-se clicar sobre o botão “Arquivo” e selecionar o arquivo desejado. Após informado os dados, deve-se selecionar a partir de onde os dados serão obtidos (campo de dados ou arquivo), para isso existe uma opção na interface do debugger.
No lado direito do debugger podemos visualizar uma lista descrita como status da porta serial. Neste lista que serão exibidos todos os pacotes que chegam até o software de debugger, desta forma podemos ver o que o computador servidor estaria enviando ao controlador mestre.
O software de debugger foi desenvolvido em Java e devido as características de linguagens de programação orientadas a objetos, ocorre a reutilização de bibliotecas de classes, desta forma, o  software de debugger neste caso seria apenas um interface visual mais aprimorada sobre toda a biblioteca de classes que fora desenvolvida para o software que roda no servidor. Em outras palavras, reutilizamos todas as classes responsáveis pelo envio, recepção, codificação e decodificação de pacotes, ficando sem utilização apenas as classes que acessam o banco de dados, pois no contexto que se encontra o software de debugger isso não é necessário.