A grande maioria das aplicações, independente de porte, precisam de dados per- sistentes para manter um registro histórico. Partindo desse princípio, pode-se dizer que o gerenciamento desses dados é de fundamental importância para o correto funcionamento de um sistema computacional. Levando esse conceito de gerenciamento de dados para softwares Java, como o InterAB e o WbS, geralmente ele se refere a armazenar/persistir dados em um banco de dados relacional e recuperá-los por meio dos recursos da lingua- gem. No projeto de banco de dados dos softwares foi utilizado o Sistema Gerenciador de Banco de Dados (SGBD) MySQL (ORACLE, 2014e), o framework de Mapeamento Objeto-Relacional Hibernate (Object Relational Mapping - ORM) (REDHAT, 2014a) e o padrão para persistência de dados Objeto de Acesso a Dados (Data Access Object - DAO) (ORACLE, 2014b).
Com o objetivo de apresentar o projeto de banco de dados dos softwares, a seguir será discutida de que forma o paradigma de orientação a objetos pode ser mapeado para uma base de dados relacional como o MySQL, assim como será mostrado o modelo físico do projeto e de que maneira ele colabora para a integração dos softwares.
3.5.1
Mapeamento Objeto-Relacional
Um banco de dados relacional utiliza uma abordagem diferente para armazenar informações, que nada se assemelha ao processo empregado em um sistema com base em objetos. Geralmente o processo de persistência envolvendo objetos se dá por meio da serialização destes, de modo que essa persistência de objeto se concentra em guardar o estado (valores) deste em disco e, em dada situação, recuperar o mesmo para fazer uso de suas informações. Essa abordagem tem uma limitação: é geralmente aplicada para persistir objetos simples, nos quais não há relacionamentos complexos envolvendo grandes estruturas de dados.
Apesar da técnica de serialização de objetos poder ser aplicada em projetos mai- ores, seu emprego geralmente não é recomendado devido às grandes operações de es- crita/leitura que podem estar envolvidas em tais processos, além da certeza da perda de desempenho global do sistema (ORACLE, 2014d).
O JDBC (ORACLE, 2014d) é uma das maneiras mais práticas para desenvolver um software Java que interaja com um banco de dados relacional. Essa tecnologia atende a uma parte considerável das necessidades para operações das mais diversas naturezas. Contudo, conforme as aplicações evoluem, é sentida a necessidade de padronizar sua arqui- tetura, o padrão de codiĄcação e as próprias operações SQL (Structured Query Language) realizadas por ela. Dessa forma, a adoção do framework Hibernate em um sistema tende a ser um caminho natural quando se visa algum tipo de padronização.
A técnica de Mapeamento Objeto-Relacional é uma forma automatizada e trans- parente de persistir objetos que pertencem a uma aplicação nas respectivas tabelas em um banco relacional, usando para isso tecnologias como o framework Hibernate, o qual des- creve como realizar esse mapeamento entre objetos e banco de dados (REDHAT, 2014a). Em essência, o Hibernate trabalha para fazer a transformação de dados de uma forma para outra de maneira completa e reversível. Essa solução ORM contém os seguintes pontos (REDHAT, 2014a):
∙ Uma API (Application Programming Interface) para realizar as operações CRUD (Create, Read, Update and Delete) básicas em objetos de classes persistentes; ∙ Uma linguagem ou API para especiĄcar consultas que se referem às classes ou às
propriedades das classes;
∙ Facilidade de especiĄcar o metadado de mapeamento;
∙ Uma técnica para que a implementação ORM interaja com objetos transacionais permitindo executar veriĄcações do tipo leitura suja (dirty checking) ou carrega- mento sob demanda (lazy association fetching).
O acesso aos dados varia dependendo da fonte de dados. O acesso ao armazena- mento persistente, como um banco de dados, varia muito, dependendo do tipo de arma- zenamento (bancos de dados relacionais, bancos de dados orientados a objetos, arquivos simples e assim por diante) e da implementação do fabricante. Adicionalmente a padroni- zação proporcionada pela utilização do framework Hibernate, o padrão para persistência de dados DAO permite separar regras de negócio das regras de acesso ao banco de dados. No software WbS que utiliza a arquitetura MVC, todas as funcionalidades de bancos de dados, tais como obter as conexões, mapear objetos Java para tipos de dados SQL ou executar comandos SQL, são realizadas por classes DAO em conjunto com o Hibernate.
A vantagem de utilizar o padrão DAO é a separação simples e rigorosa entre duas partes importantes de um software que não devem e não podem conhecer muitos detalhes uma da outra, e que podem evoluir frequentemente e independentemente (ORACLE, 2014b). Mudanças nas regras de negócio podem contar com a mesma interface DAO, enquanto que modiĄcações na lógica de persistência não alteram a lógica de negócio, desde que a interface entre elas não seja modiĄcada.
O padrão DAO pode ser utilizado em uma diversidade de aplicações, escondendo todos os detalhes relativos ao armazenamento de dados do restante da aplicação. Ade- mais, esse padrão atua como um intermediário entre a aplicação e o banco de dados, mitigando problemas de comunicação entre a base de dados e a aplicação, evitando es- tados inconsistentes de dados. O diagrama de classes apresentado na Figura 20 exem-
pliĄca o padrão DAO, considerando a classe Java Sensor do software WbS. A classe FonteDadosé a origem dos dados (relacional, orientado a objetos, arquivos, etc.). A classe SensorDAOHibernate é a classe concreta que implementa a interface SensorDAO, sendo responsável pelo acesso e persistência dos dados do Sensor. A classe Sensor é a classe do domínio e representa um sensor da rede, contendo os dados que transitam de/para a fonte de dados. Por Ąm, a classe SensorRN contém a lógica de negócio e usa uma instância da classe SensorDAOHibernate (um objeto) como uma interface com a fonte de dados.
Figura 20 Ű Diagrama de classes para exempliĄcar o padrão DAO.
Fonte: Produzido pelo autor
3.5.2
Modelo físico
O modelo físico do banco de dados para os softwares InterAB e WbS é apresentado na Figura 21. Nesse modelo são especiĄcadas as tabelas do banco de dados, os atributos das tabelas e seus domínios, os relacionamentos entre as tabelas e as chaves primárias e estrangeiras. Essa estrutura de tabelas é criada automaticamente e atualizada no banco de dados através das anotações (BERNARD, 2014) nas classes Java que são interpretadas e mapeadas para as tabelas do modelo relacional através do Hibernate.
Esta modelagem relacional traz como informação adicional de que maneira o banco de dados foi organizado para armazenar dados acerca de leituras de sensores, curvas de calibração, interrogadores, sensores, técnicas de Ąltragem/compressão de dados, métodos de detecção de anomalia, eventos, atualizações, usuários e permissões de usuário.
Figura 21 Ű Modelo físico do banco de dados. itv_atualizacao id_atualizacao INT(11) data_atualizacao DATETIME Indexes itv_dado id_dado INT(11) comp_onda_pico DOUBLE tempo_dado DATETIME tempo_inc_dado DOUBLE id_sensor INT(11) Indexes itv_fuzzy_configuracao id_configuracao INT(11) data_conf VARCHAR(45) nm_conf VARCHAR(45) id_usuario INT(11) id_anomalia INT Indexes itv_fuzzy_regras id_regras INT(11) des_regras LONGTEXT id_configuracao INT(11) Indexes itv_fuzzy_termo id_termo INT(11) nm_termo VARCHAR(20) ordem_termo INT(11) x1_termo DOUBLE x2_termo DOUBLE x3_termo DOUBLE x4_termo DOUBLE id_variavel INT(11) Indexes itv_fuzzy_variavel id_variavel INT(11) int_Final DOUBLE int_Inicial DOUBLE n_Termos INT(11) nm_variavel VARCHAR(45) ordem_variavel INT(11) tipo_variavel BIT(1) valor_entrada DOUBLE id_configuracao INT(11) Indexes itv_inter id_inter INT(11) fx_fim_inter DOUBLE fx_ini_inter DOUBLE ip_inter VARCHAR(16) localizac_inter VARCHAR(40) modelo_inter VARCHAR(20) nm_inter VARCHAR(20) no_amostras_inter INT(11) no_canais_inter INT(11) portad_inter INT(11) portap_inter INT(11) st_inter BIT(1) tx_varredura_inter INT(11) id_usuario INT(11) Indexes itv_compress id_metodo INT(11) ativo_metodo BIT(1) nome_metodo VARCHAR… id_usuario INT(11) Indexes itv_permissao id_usuario INT(11) ds_permissao VARCHAR(30) Indexes itv_sensor id_sensor INT(11) canal_sensor INT(11) comp_onda_ref DOUBLE fx_deriv_max_sensor DOUBLE fx_deriv_min_sensor DOUBLE fx_valor_max_sensor DOUBLE fx_valor_min_sensor DOUBLE localizac_sensor VARCHAR(40) modelo_sensor VARCHAR(20) nm_sensor VARCHAR(20) serial_sensor VARCHAR(30) st_sensor BIT(1) tx_amostragem_sensor DOUBLE tipo_sensor VARCHAR(25) id_inter INT(11) id_usuario INT(11) id_calibracao INT(11) Indexes itv_usuario id_usuario INT(11) dt_usuario DATE email_usuario VARCHAR(45) login_usuario VARCHAR(15) nm_usuario VARCHAR(45) senha_usuario VARCHAR(15) st_usuario BIT(1) Indexes itv_calibracao id_calibracao INT(11) param1 DOUBLE param2 DOUBLE param3 DOUBLE id_usuario INT(11) Indexes itv_algoritmos id_anomalia INT(11) nm_met_alg VARCHAR(20) id_usuario INT(11) id_anomalia INT Indexes itv_evento id_evento INT data_evento DATE id_anomalia INT Indexes itv_anomalia id_anomalia INT st_anomalia BIT(1) Indexes
Fonte: Produzido pelo autor
3.5.3
Integração dos softwares através do banco de dados
O modelo físico apresentado na Figura 21 foi criado com o propósito de ser aces- sado pelas duas aplicações: InterAB e WbS. EspeciĄcamente, por intermédio da tabela itv_atualizacao, a qual não possui nenhum relacionamento com outra tabela, é possível sincronizar e integrar os dois softwares usando um esquema semelhante ao problema do produtor-consumidor.
As duas aplicações compartilham a mesma base de dados. O produtor, neste caso o InterAB, insere os dados referentes às leituras dos sensores na tabela itv_dado, assim como insere atualizações na tabela itv_atualizacao como forma de notiĄcar a aplica- ção consumidora de que novos dados de sensores foram persistidos. O WbS, no papel de consumidor, a todo o momento realiza a leitura da tabela de atualizações para saber se existem ou não novas leituras dos sensores armazenadas no banco de dados compartilhado. A Figura 22 apresenta os dois softwares trabalhando em conjunto através de notiĄcações de atualizações no banco de dados compartilhado. Dessa maneira, se torna possível inte- grar as aplicações desenvolvidas na forma de um software de monitoramento que realize a atividade de gerenciamento de dados do processo de SHM.
Figura 22 Ű Integração dos softwares.
Interrogador 1 InterAB Interrogador 2 Sensor Dad os Aquisição Interrogador N Aq uis ição JDBC Aqu isiç ão Dados Dado s Threads Threads A rm a z e n a m e n to Processamento Acesso Banco de dados JDBC Dados Laptop Visualização Interpretação e análise Avisos e alarmes
Conteúdo Conteúdo Requisição Requisição Exportação Web-based System Laptop A tu a li z a ç õ e s