• Nenhum resultado encontrado

3 DESENVOLVIMENTO DO SOFTWARE

3.2 Estruturação do Software

A primeira tarefa para o começo da estruturação do software foi a identificação de quais funções o aplicativo deveria desempenhar (diretrizes), quais eram as possibilidades e quais os riscos.

Assim, foi elaborada uma descrição do processamento para o software gerenciador do sistema, mostrada a seguir:

O software gerenciador permite ao usuário fazer a configuração do banco de dados (conexão) e do protocolo de comunicação, onde a primeira é indispensável para a aquisição das informações dos medidores, e a segunda é necessária somente se os dados forem ser escritos no banco. Também é possível, e necessário, o cadastramento dos medidores no software, através dos parâmetros endereço, fases (TA, TB, TC, CA, CB, CC), número de pontos por ciclo, número de ciclos, temporização (timer) e código do medidor no banco de dados (se for o caso). Também é possível escolher se o software deve apresentar gráficos, cálculos e/ou armazenar as informações no banco de dados. Essa lista de medidores cadastrados pode ser salva em arquivo de texto, assim como pode ser posteriormente aberta.

Após todos medidores estarem cadastrados, o usuário pode escolher de quais quer começar a adquirir os dados, e interromper, recomeçar, cadastrar e descadastrar a qualquer momento.

Os vetores são adquiridos dos medidores através de pedidos, utilizando-se o protocolo ModBus/RTU. As informações pedidas a um medidor são sempre iguais, de acordo com as fases, número de ciclos e pontos por ciclo cadastrados.

Tendo as informações em memória, o software deve realizar as operações indicadas (gráficos, cálculos e armazenamento em banco de dados), de acordo com o cadastramento do medidor.

Essa descrição ajuda a identificar os agentes e os processamentos do sistema, auxiliando no desenvolvimento do primeiro diagrama utilizado no projeto do software , o diagrama de fluxo de dados (DFD), que auxilia no desenvolvimento dos domínios da informação e funcional, simultaneamente. A Figura 3.2 mostra o DFD obtido.

Receber comandos do usuário Solicitar configuração do Protocolo Configurações do Banco de dados Gravar no BD Configurações dos Medidores Configurações do protocolo Realizar cálculos e gráficos Criar Medidor Receber Pedido

Enviar Pedido Verificar

Parâmetros Solicitar configurações para o pedido Solicitar configuração do BD Ler configurações dos medidores Solicitar nome e endereço do arquivo Solicitar nome e endereço do arquivo Ler arquivo Arquivo Iniciar Temporizador do Medidores BD Calculos Graficos Receber parâmetros para os medidores Verificar dados Configurar BD Usuário

Abrir arquivo de configuração de medidores Salvar configuração de medidores Adquirir dados Medidor Busca configurações Gravar dados Busca configurações Busca parâmetros Mostrar Dados Armazenar Dados Mostrar parâmetros de perfórmance Plotar formas de onda instantâneas Cadastrar medidores Configurar protocolo Armazenar Armazenar Armazenar

Figura 3.2 – Diagrama de fluxo de dados.

Este diagrama é bastante interessante de se observar no início do planejamento do software, pois ele é uma técnica gráfica que descreve o fluxo de informações e as transformações que são aplicadas à medida que os dados se movimentam da entrada para a saída.

Pode-se observar que bloco “Receber comandos do usuário” representa uma parte central do software, o qual direciona o processamento para as sub-funções (ramificações) do sistema, como a abertura (ou gravação) de um arquivo de configurações, a configuração do

52

protocolo de comunicação ou do banco de dados, o cadastramento/retirada dos medidores ou o controle das aquisições de dados.

Também se pode verificar que em níveis mais abaixo o processamento é automático, não mais dependendo da ação do usuário. Por exemplo, quando o temporizador de um medidor cadastrado termina a contagem, é enviado um pedido pela porta serial com as configurações armazenadas na instância desse medidor. E quando chega a resposta à esse pedido, o software verifica os de novo os parâmetros para decidir se deve gerar os gráficos, realizar os cálculos ou gravar no banco de dados.

Outra ferramenta utilizada, cujas finalidades são a delimitação do contexto do sistema, documentação e entendimento dos requisitos, servindo também como entrada para a etapa de análise, é a descrição e o diagrama dos casos de uso.

A descrição dos casos de uso está no Apêndice A, e o diagrama de casos de uso está mostrado na Figura 3.3.

Figura 3.3 – Diagrama de casos de uso.

No diagrama da Figura 3.3 busca-se caracterizar de forma gráfica a visualização de como o sistema a ser desenvolvido vai interagir com o ambiente (usuários e outros sistemas), o que serve de base do processo de desenvolvimento do sistema [4].

Outro diagrama interessante de se utilizar no desenvolvimento de um software é o diagrama de classes, que é um grafo que descreve as estruturas de classe do aplicativo, seus atributos, operações e relacionamentos presentes no sistema. Este diagrama é utilizado para a modelagem estática, dando suporte às necessidades funcionais (serviços que o sistema deve providenciar aos usuários finais), e auxiliar nas seguintes estruturações:

• Vocabulário do sistema: especificação das abstrações contidas dentro do domínio do sistema, identificando as suas responsabilidades;

• Colaboração: envolve o trabalho conjunto entre os objetos do sistema, visando um comportamento cooperativo.

O diagrama de classes desenvolvido está mostrado na Figura 3.4.

54

O último diagrama utilizado para a estruturação do software foi o diagrama de seqüência, que tem como objetivo apresentar as interações entre objetos, enfatizando a seqüência temporal em que as mensagens são trocadas.

Esta é outra forma de se visualizar graficamente o fluxo de informações e dados, através das mensagens dos objetos do software, e está mostrado no Apêndice B.

Documentos relacionados