Banco de dados SQLite

SQLite é um banco de dados escrito inteiramente em linguagem C e por suas características como ágil, leve, altamente confiável, com muitas ferramentas incluídas, é extensamente aplicado em diversas situações das mais diversas áreas. Está embarcado em computadores, sistemas embarcados, telefones celulares, dispositivos eletrônicos e mais [24].

32 Capítulo 3. Fundamentação teórica

Devido a tais características, essa ferramenta de banco de dados é implantado em algumas soluções e aplicações da empresa. Ao adquirir experiência e notar as vantagens que se obtém ao trabalhar com o mesmo, optou-se por utilizar na aplicação em desenvolvimento deste projeto. Sem haver necessidades de compras de licenças e ser open source, tal banco deverá ser usado para implantar um dos requisitos do projeto, citados no capítulo 4.

O SQLite possui uma comunidade ampla de desenvolvedores e hobistas, apresen- tando suporte e documentações para diversas situações que se possa enfrentar numa implantação. Esse suporte trouxe aplicações para integrações com diversas linguagens de programação, incluindo o Python [25].

33

4 Análise do problema

Neste capítulo serão apresentado brevemente o funcionamento do sistema embarcado desenvolvido pela empresa, ressaltando alguns pontos importantes e suas tecnologias, os requisitos propostos para o novo sistema, as técnicas escolhidas para implantação e o projeto propriamente dito, contando com seus diagramas.

4.1

Requisitos do sistema

Os requisitos são, como o nome diz, o que o sistema precisa ter e/ou ser capaz de realizar. Sendo assim, propõe-se que os requisitos para que a aplicação atenda sejam os seguintes:

• R.1: A aplicação deve ser de fácil uso e intuitivo;

• R.2: Ser capaz de analisar curvas de todos as mensagens do arquivo de log de modo mais rápido e fácil;

• R.3: Receber arquivos logs de entrada de diferentes padrões;

• R.4: Deve ser capaz de usar a aplicação em diferentes sistemas operacionais, tanto quanto distribuições GNU/Linux, Windows e MacOS;

• R.5: Ser capaz de aplicar parâmetros de escala e offset para as curvas geradas; • R.6: Aplicação deve ser capaz de armazenar informações de sensores já mapeados,

afim de evitar retrabalhos num banco de dados local;

• R.7: Buscar nas mensagens candidatas por sensores já cadastrados em nosso banco de dados dos sensores;

• R.8: Aplicar os parâmetros das mensagens já cadastradas sobre as candidatas correspondentes, identificados em "matchs";

• R.9: Ter a opção de buscar dentro das mensagens por bytes de controle - funciona- mento de header estendido;

• R.10: Ter a opção de filtrar por mensagens sem variações em seus dados;

• R.11: Ser capaz de aplicar a busca usando métodos estatísticos de correlação, baseado numa aplicação interna da empresa chamada de CAN Inspector ;

• R.12: Exportar a instrução SQL para inserir ao banco de dados oficial da empresa que contém tabela de sensores mapeados;

34 Capítulo 4. Análise do problema

4.2

Viabilidade e cronograma

Após análise do problema proposto como um todo, considerando as complicações tecnológicas; capacidade de encontrar informações; técnicas disponíveis na rede internet com amplo suporte da comunidade de desenvolvedores; análise da complexidade envolvida para com cada requisito citado acima; tempo disponível e necessidade de implantação do projeto, conclui-se viável o estudo e desenvolvimento desta aplicação em questão. Visando concluir o projeto, uma cronograma separando as macro atividades por meses foi elaborado no início do projeto e seguido durante a execução, ilustrado na Tabela1.

Tabela 1 – Cronograma do desenvolvimento das macro atividades do projeto. Fev Mar Abr Mai Jun Jul Estudo de protocolos veiculares x

Escolha da linguagem de programação x Coleta de informações na empresa x

Criação de banco de dados local x x Determinar funcionalidades do sistema x x Estudo de técnicas na identificação de sensores x x

Escolha e implantação de interface gráfica x x x

Escrita de código x x x x

Testes e validação x x

35

5 Implantação da aplicação

Será abordado nes te capítulo os procedimentos para implantação da aplicação em questão, detalhando como foi o procedimento para os testes e validações, seguido da arquitetura implantada, seus diagramas e suas respectivas explicações.

5.1

Métodos escolhidos

Durante o processo de definição inicial da arquitetura do projeto, algumas ideias foram cogitadas para se buscar a solução dos problemas. Nesse processo, a proposta para a solução adotada é modular. Dessa forma, módulos deverão ser implantados independen- temente do outro, estando todos sob controle de um módulo especial, o controlador. O módulo controlador, chamado aqui de application controller instanciará objetos declarados em cada módulo, controlando inteiramente a aplicação.

Antes de iniciar a escrita e implantação do código de cada módulo, foram propostos como seriam feitas as trocas de mensagens e informações entre os mesmos, prevendo inicialmente quais seriam os campos necessários nas entradas e saídas de cada módulo. Em cada, buscou-se manter o menor número possível de classes, nos quais na verdade foram propostas classes que representem a função geral no nome do módulo.

Quanto as técnicas e tecnologias adotadas são as mesmas citadas no capítulo da fundamentação teórica, frisando que a linguagem de programação é Python 3.5; uso do framework Qt 5; implantação de um banco de dados SQLite; módulos em Python para integrar tais técnicas foram usados, tais como sqlite e pandas; e por fim o uso de ambiente de desenvolvimento open-source específico para Python, o PyCharm.

5.2

Diagrama de classes

Um diagrama de classes foi criado para ilustrar como se dará a comunicação entre as classes que representam os módulos da aplicação, ilustrado na Figura10 a seguir [26,27]. Nota-se que a maioria das classes possuem mesmo nome dos módulos do diagrama da Figura 11. Elaborado no início do projeto, buscou-se através deste diagrama orientar a forma de escrever o código no momento da implantação, sofrendo poucas alterações tentando ater-se ao que foi proposto inicialmente, diminuindo retrabalhos. Por tais motivos, o detalhamento de cada classe, mencionando seus atributos e métodos serão descritos na implantação do módulo respectivo.

36 Capítulo 5. Implantação da aplicação

Figura 10 – Diagrama de classes proposto.

Fonte: elaborado pelo autor.

5.3

Arquitetura modular

Uma arquitetura modular foi proposta pelas vantagens que se obtém ao trabalhar com esta técnica, podendo citar facilidade de manutenção de código, expansível, confiabili- dade e outras pessoas poderiam adicionar módulos e estratégias sem prejudicar as demais funcionalidades. A Figura11 ilustra os módulos propostos e suas descrições e detalhes se encontram a seguir.