Ministério da Educação Secretaria de Educação Profissional ... · programação de computadores, modelo conceitual, mapeamento de associações, serialização de objetos Java,

Ministério da EducaçãoSecretaria de Educação Profissional e Tecnológica

Instituto Federal CatarinenseCampus Avançado Sombrio

LEONARDO DAROS SANTOS

MIGRAÇÃO DE PERSISTÊNCIA EM BANCO DE DADOS PARA ARQUIVOS EM

UM GERENCIADOR FINANCEIRO

Sombrio

2015




Trabalho de Conclusão de Curso apresentado aoCurso de Técnico em Informática Integrado aoEnsino Médio, do Instituto Federal de Educação,Ciência e Tecnologia Catarinense – CampusAvançado Sombrio para obtenção do título deTécnico em Informática.

Orientadora: Profª. Cristiane Cardoso Silva, Esp.

Coorientador: Prof. Iuri Sônego Cardoso, Me.

Sombrio

2015




Este Trabalho de Conclusão de Curso foi julgadoadequado para obtenção do título de Técnico emInformática (Informática) e aprovado em sua formafinal pelo Curso de Técnico de Informática Integradoao Ensino Médio do Instituto Federal de Educação,Ciência e Tecnologia Catarinense – CampusAvançado Sombrio.

Sombrio (SC), 20 de novembro de 2015.

_______________________________________________

Professora e Orientadora Cristiane Cardoso Silva, Esp.

Instituto Federal Catarinense – Campus Avançado Sombrio

BANCA EXAMINADORA

_______________________________________________

Professor Thales Nascimento da Silva, Me.

Instituto Federal Catarinense – Campus Avançado Sombrio

_______________________________________________

Professor e Coorientador Iuri Sônego Cardoso, Me.

Instituto Federal de Santa Catarina – Campus Criciúma.

Eu dedico à minha Família, e a todas as pessoas que

colaboraram diretamente ou indiretamente nesta conquista.

AGRADECIMENTOS

Aos meus professores, em especial ao orientador no período de Dezembro de

2014 a Setembro de 2015, Iuri Sônego Cardoso. A este Instituto, pela oportunidade

deste aprendizado e novos conhecimentos. Aos colegas de classe. Às pessoas que

tornaram este período melhor para mim, sendo minha família e a minha namorada,

pelo total apoio e amor, e a todos que contribuíram de forma direta ou indireta na

realização deste trabalho.

“A complexidade de depurar é o dobro da de escrever o código. Portanto, se você

escrever código o mais inteligente possível, por definição você não será esperto o

suficiente para depurá-lo.” - Brian W. Kernighan

RESUMO

No âmbito do desenvolvimento de software, o armazenamento de dados pode serrealizado de diferentes formas, tais como arquivos e banco de dados. Realizar atransformação de um aplicativo de uso pessoal que armazena dados em banco dedados, para que passe a armazenar em arquivos. Esta transformação é indicadapara que o usuário tenha recursos como a mobilidade dos dados. O objetivo destetrabalho é migrar a forma de armazenamento de informações de banco de dadosrelacional para arquivo, no aplicativo gerenciador financeiro GEF, simplificando a suainstalação e a mobilidade de seus dados. A revisão da literatura explora os temas daprogramação de computadores, modelo conceitual, mapeamento de associações,serialização de objetos Java, criptografia de dados, gravação em arquivos e aimplementação de Filas, para que se possa exemplificar a metodologia adotada noprocesso. Através do estudo do projeto do software base pode-se migrá-lo parapersistir dados em arquivos, projetando a estrutura de classes e associações, deforma que a implementação destas, em uma linguagem de programação, permitaque os dados sejam manipulados em forma de objetos e, posteriormente,transformados em bytes através da serialização de objetos. Assim, os dados podemser gravados em um arquivo de forma segura por meio de criptografia. Houve amelhoria do filtro de movimentações, permitindo múltiplos recursos na filtragem, bemcomo a criação de relatórios dinâmicos. A migração acarreta leves mudanças, comoa necessidade do menu Arquivo. O uso de arquivos apresenta vantagens, como amobilidade dos dados e a possibilidade de uso de múltiplos arquivos.

Palavras-chave: Desenvolvimento de Software. Programação Orientada a Objetos.

UML. Persistência em arquivos.

ABSTRACT

In the ambit of software development, the data storage can be accomplished withdifferent forms, such as files and database. Performing transformation of a personaluse application that stores data in the database to do the persist in the files isindicated so that the user has resources as data mobility. The objective of thisacademic work is migrate the form of storage of the data, from relational database tofiles, in the financial manager application GEF, simplifying its installation and themobility of its data. The literature review explores the themes of computerprogramming, conceptual model, associations mapping, serialization of Java objects,data encryption, writing to files and the implementing queues, exemplifying themethodology adopted in the process. By study of the software base project, it can bemigrated to persist data in files, designing the structure of classes and associations ina way that the implementation in a programming language enables the datamanipulation in objects and later transformed it into bytes by serialization of theseJava objects. Thus, the data can be recorded in files in a safe way by encryption.There was the improvement of movimentation filter, allowing multiple resources in thefiltering, just like the creation of dynamically reports. The migration causes fewchanges as the need of the File menu. The use of files has advantages such as datamobility and the possibility of use multiple files.

Keywords : Software Development. Object Oriented Programming. UML. Persistence

in files.

LISTA DE ILUSTRAÇÕES

Ilustração 1: Exemplo de Entidade..............................................................................24

Ilustração 2: Exemplo de entidade com atributos.......................................................24

Ilustração 3: Entidades com Relacionamento.............................................................25

Ilustração 4: Exemplo de Classe em UML..................................................................27

Ilustração 5: Exemplo de associação em UML...........................................................29

Ilustração 6: Exemplo de associação unidirecional....................................................30

Ilustração 7: Entidades do Diagrama ER do projeto...................................................31

Ilustração 8: Classes do diagrama de classes do projeto...........................................31

Ilustração 9: Diagrama UML com associação um-para-muitos unidirecional.............33

Ilustração 10: Diagrama UML com associação um-para-muitos unidirecional...........34

Ilustração 11: Diagrama UML com associação um-para-muitos bidirecional.............36

Ilustração 12: Diagrama entidade-relacionamento do GEF........................................49

Ilustração 13: Diagrama de Classes do GEF..............................................................50

Ilustração 14: Exemplo de tela de Cadastro...............................................................56

Ilustração 15: Menu de manipulação de arquivos......................................................56

Ilustração 16: Tela Propriedades do Arquivo...............................................................57

Ilustração 17: Tela Senha do Arquivo..........................................................................58

Ilustração 18: Tela abrir Arquivo..................................................................................58

Ilustração 19: Tela salvar Arquivo................................................................................59

Ilustração 20: Tela Relatórios de Movimentações.......................................................59

Ilustração 21: Tela de Seleção de Conta Bancária.....................................................60

Ilustração 22: Tela Configuração PDF.........................................................................61

Ilustração 23: PDF layout detalhado...........................................................................69

Ilustração 24: PDF layout em colunas........................................................................70

Ilustração 25: Classe CriptografiaAES........................................................................71

Ilustração 26: Senha para abrir o arquivo...................................................................72

LISTA DE QUADROS

Quadro 1: Exemplo de algoritmo implementado em Portugol....................................18

Quadro 2: Exemplo de algoritmo em Java..................................................................20

Quadro 3: Exemplo de classe em Java......................................................................21

Quadro 4: Exemplo de declaração de objetos em Java.............................................22

Quadro 5: Possíveis visibilidades de um elemento (atributo ou operação)................27

Quadro 6: Sintaxes UML.............................................................................................28

Quadro 7: Conectividade versus multiplicidades........................................................29

Quadro 8: Implementação em Java do padrão associação como atributo................33

Quadro 9: Implementação em Java do padrão objeto de coleção.............................35

Quadro 10: Implementação em Java do padrão Mutual Friends................................37

Quadro 11: Método que realiza a transformação de Objeto em Bytes.......................39

Quadro 12: Método que realiza a transformação de bytes em objeto........................40

Quadro 13: Método de escrita de dados em arquivo..................................................42

Quadro 14: Método de leitura de dados em arquivo...................................................43

Quadro 15: Classe ArquivosRecentes........................................................................44

Quadro 16: Implementação de uma fila em Java.......................................................44

Quadro 17: Atributos e métodos da classe Movimentacao.........................................52

Quadro 18: Associação da classe Movimentacao com TipoMovimentacao...............53

Quadro 19: Associação entre Movimentacao e Categoria..........................................53

Quadro 20: Associação entre Movimentacao e Favorecido.......................................54

Quadro 21: Classe TipoMovimentacao.......................................................................55

Quadro 22: Implementação do método de cadastro de conta bancária.....................62

Quadro 23: Implementação do método de editar conta bancária...............................63

Quadro 24: Implementação do método de listar contas bancárias............................64

Quadro 25: Implementação do método de excluir conta bancária.............................65

Quadro 26: Algoritmo de filtro de dados da classe Movimentacao.............................66

Quadro 27: Métodos que verificam o período da movimentação...............................67

Quadro 28: Métodos que verificam a Categoria e Favorecido da Movimentacao......68

Quadro 29: Comparativo da forma de persistir dados................................................73

LISTA DE SIGLAS

AES - Advanced Encrypt Standard

DER – Diagrama Entidade Relacionamento

ER – Entidade Relacionamento

FIFO – First In First Out

GEF - Gerenciador Financeiro

IDE - Integrated Development Environment

JDK – Java Devlopment Kit

PDF – Portable Document Format

POO – Programação Orientada a Objetos

SGBD – Sistema Gerenciador de Banco de Dados

TCC – Trabalho de Conclusão de Curso

UML – Unifield Modeling Language

XML – Extensible Markup Language

SUMÁRIO

1 INTRODUÇÃO.........................................................................................................14

2 OBJETIVOS.............................................................................................................16

2.1 OBJETIVO GERAL................................................................................................16

2.2 OBJETIVOS ESPECÍFICOS.................................................................................16

3 REFERENCIAL TEÓRICO......................................................................................17

3.1 PROGRAMAÇÃO DE COMPUTADORES............................................................17

3.1.1 Algoritmos...........................................................................................................17

3.1.2 Linguagens de Programação.............................................................................19

3.1.4 Orientação a objetos..........................................................................................20

3.2 MODELO CONCEITUAL.......................................................................................23

3.2.1 Diagrama entidade-relacionamento...................................................................23

3.2.2 Diagrama de classes da UML............................................................................26

3.2.3 Transformação do diagrama ER para o diagrama de classes da UML.............31

3.3 MAPEAMENTO DE ASSOCIAÇÕES EM JAVA....................................................32

3.3.1 Associação como atributo..................................................................................32

3.3.2 Objeto de coleção..............................................................................................34

3.3.3 Mutual Friends....................................................................................................36

3.4 SERIALIZAÇÃO DE OBJETOS EM JAVA............................................................38

3.4.1 Objetos transformados em bytes.......................................................................39

3.4.2 Bytes transformados em objetos........................................................................40

3.5 CRIPTOGRAFIA DE DADOS................................................................................41

3.6 GRAVAR E LER BYTES EM ARQUIVOS.............................................................42

3.7 IMPLEMENTAÇÃO DE FILAS..............................................................................43

4 MATERIAIS E MÉTODOS.......................................................................................45

4.1 MATERIAL.............................................................................................................45

4.2 MÉTODOS.............................................................................................................45

4.2.1 Definição dos Requisitos....................................................................................46

4.2.2 Projeto................................................................................................................47

4.2.3 Implementação...................................................................................................47

5 RESULTADOS E DISCUSSÕES.............................................................................49

5.1 TRANSFORMAÇÃO DO DER EM DIAGRAMA DE CLASSES DA UML.............49

5.2 IMPLEMENTAÇÃO DO DIAGRAMA DE CLASSES UML....................................52

5.3 TELAS DO PROGRAMA.......................................................................................56

5.4 MANIPULAÇÃO DOS OBJETOS..........................................................................62

5.5 FILTRO DE DADOS..............................................................................................65

5.6 RELATÓRIOS EM PDF.........................................................................................69

5.7 SEGURANÇA DOS ARQUIVOS...........................................................................70

5.8 DISCUSSÃO.........................................................................................................73

6 CONSIDERAÇÕES FINAIS.....................................................................................74

REFERÊNCIAS...........................................................................................................76

APÊNDICE A – Cronograma de Atividades.............................................................78

APÊNDICE B – Artigo apresentado ao SICT-Sul....................................................79

14

1 INTRODUÇÃO

No âmbito do desenvolvimento de software, o armazenamento de dados pode

ser realizado de diferentes formas, tais como arquivos e banco de dados. Essas

podem apresentar vantagens e desvantagens, quanto a características de

praticidade e segurança. Sendo assim, deve-se pensar na melhor forma do

armazenamento dos dados quando se projeta o software, pois, analisando o

contexto que o software se aplica, uma das formas de armazenar se torna mais

trivial ao usuário e ideal às circunstâncias da natureza do software.

Por exemplo, sistemas de médio e grande porte empregados em empresas

geralmente utilizam banco de dados, porque esse permite acesso simultâneo de

vários usuários aos dados em uma rede de computadores, entre outros motivos. Por

outro lado, aplicativos de uso pessoal como editores de texto, planilhas eletrônicas,

entre outros, utilizam a persistência (armazenamento) em arquivos, por não

necessitar de uma estrutura mais complexa instalada, como um sistema gerenciador

de banco de dados.

O software Gerenciador Financeiro GEF utilizava de persistência de dados

em um banco de dados relacional com o Sistema Gerenciador de Banco de Dados

(SGBD) MySQL gerenciando-o; assim, necessita ser instalado na máquina onde o

aplicativo for utilizado (local). Além disto, copiar os dados para outro local

(computador) necessita exportar dados do SGBD e importá-los no SGBD destino, o

que não é uma tarefa trivial para um usuário leigo em desenvolvimento de software.

Bancos de dados relacionais possuem diversas características, como a

capacidade de armazenar milhões de registros, o controle de acesso concorrente

aos dados, e a possibilidade da implementação de uma arquitetura cliente-servidor.

Arquivos armazenados em uma unidade de armazenamento não possuem estes

recursos, ao menos que seu gerenciador (sistema) os ofereça. Todavia, os arquivos

possuem características próprias, como a praticidade de manipulação ao usuário,

instâncias diferentes armazenadas em múltiplos arquivos e o rápido acesso e escrita

de dados.

Deste modo, no gerenciador financeiro GEF tornar-se-ia mais trivial persistir

informações em arquivos, tal maneira é utilizada, atualmente, por diversos sistemas

15

aplicativos, em sua maioria de uso pessoal ao usuário. Neste contexto, seria

possível migrar a forma de persistir informações no gerenciador financeiro GEF, para

que este apresente armazenamento em arquivos?

Este trabalho apresenta os objetivos no Capítulo 2; temas do conhecimento

no Capítulo 3, tais como programação de computadores, o modelo conceitual, entre

outros. Os materiais e métodos utilizados nesta pesquisa, são descritos no Capítulo

4; os resultados obtidos, no Capítulo 5; por fim, as considerações finais no Capítulo

6.

16

2 OBJETIVOS

Este capítulo aborda o objetivo geral e os específicos deste trabalho de

conclusão de curso.

2.1 OBJETIVO GERAL

Migrar a forma de armazenamento de informações, de banco de dados

relacional para arquivo, no aplicativo gerenciador financeiro GEF, simplificando a sua

instalação e a mobilidade de seus dados.

2.2 OBJETIVOS ESPECÍFICOS

• Utilizar-se de material bibliográfico, a fim de construir conhecimento sobre o

diagrama de classes da UML, a implementação de associações em Java,

criptografia de dados e a serialização de objetos;

• Modelar de forma consistente e funcional, a estrutura lógica das classes Java

envolvidas na implementação, utilizando o Diagrama de Classes da UML;

• Utilizar recursos da Orientação a Objetos da linguagem Java para realizar a

migração de armazenamento em banco de dados para arquivos;

• Melhorar a apresentação de dados ao usuário, proporcionando-o recursos

como a filtragem de informações e a visualização destas de forma dinâmica;

• Garantir segurança dos dados do usuário, utilizando-se o princípio da

criptografia como recurso;

• Proporcionar conjuntos de dados diferentes no sistema, através do uso de

múltiplos arquivos que não possuem relação entre si;

• Facilitar que usuários leigos em banco de dados, transportem os dados em

forma de arquivo, de um computador para outro.

17

3 REFERENCIAL TEÓRICO

Este capítulo apresenta o referencial teórico deste trabalho de pesquisa,

abordando assuntos como programação de computadores (seção 3.1), modelo

conceitual (seção 3.2), mapeamento de associações em Java (seção 3.3),

serialização de objetos em Java (seção 3.4), criptografia de dados (seção 3.5),

gravação de bytes em arquivos (seção 3.6). e por fim, implementação de Filas

(seção 3.7).

3.1 PROGRAMAÇÃO DE COMPUTADORES

Segundo Santos (2013), a programação de computadores está ligada a

manipulação de informações utilizando os recursos que o computador oferece, o

hardware e seus periféricos, de forma que estas informações são tratadas por um

programa ou aplicação, para que o computador resolva tal tarefa.

As subseções presentes nesta seção, apresentam as subáreas da

programação de computadores, como os algoritmos, e as linguagens de

programação como Java que é orientado a objetos.

3.1.1 Algoritmos

Segundo Salvetti, pode-se definir algoritmo como: “Uma sequência finita de

instruções ou operações cuja execução, em tempo finito, resolve um problema

computacional, qualquer que seja sua instância.” (SALVETTI, 1999 apud

ASCENCIO; CAMPOS, 2007, p. 2)

Nesse sentido Manzano e Oliveira (2014, p. 25), descrevem que o algoritmo:

[…] do ponto de vista computacional, pode ser entendido como regrasformais, sequenciais e bem definidas a partir do entendimento lógico de umproblema a ser resolvido por um programador com o objetivo de transformá-lo em um programa que seja possível de ser tratado e executado por umcomputador, em que dados de entrada são transformados em dados desaída.

18

Para um melhor entendimento deste conceito, pode-se realizar uma analogia

literal de forma que esta sequência lógica pode ser traduzida para um evento

cotidiano em vez de um evento computacional. Tem-se como exemplo clássico uma

receita de bolo em que se deve realizar um passo a passo de ações a fim de chegar-

se ao resultado final. (MANZANO; OLIVEIRA, 2014, p. 25)

Segundo Ascencio e Campos (2007, p. 4) o pseudocódigo ou portugol

“Consiste em analisar o enunciado do problema e escrever, por meio de regras

predefinidas [utilizando a língua portuguesa], os passos a serem seguidos para sua

resolução.”

O Quadro 1, mostra um exemplo de Algoritmo em portugol que calcula o

consumo médio de combustível.

Quadro 1: Exemplo de algoritmo implementado em Portugol

12345678910111213

algoritmo “consumo medio”;varkilometragem,litros,consumo: real;inicio

escreva (“Digite quantos KM você percorreu: ”); leia (kilometragem); escreva (“Digite o tanto de combustivel gasto: ”); leia (litros); consumo <- (kilometragem/litros);

escreva(“O consumo médio do veiculo é: ” , consumo, “KM/L”);

fimalgoritmoFonte: O Autor, 2015.

A sequência lógica do algoritmo descrito no Quadro 1 é capturar (ler) a

entrada de dados do teclado, realizar o processamento do cálculo e emitir (escrever)

a saída computada.

19

3.1.2 Linguagens de Programação

Manzano e Oliveira explicam Linguagem de Programação como:

Para que um computador eletrônico funcione, necessita ser programado. Oprocesso de programação é uma “conversa” entre um ser humano(tecnicamente preparado) e o computador propriamente dito. O processode comunicação se faz com o uso de uma linguagem de programação queo computador “entenda”. É possível comunicar-se com um computadorutilizando linguagem de baixo ou alto nível. (MANZANO; OLIVEIRA, 2014,p. 21)

De acordo com Manzano e Oliveira (2014) as linguagens de baixo nível são

mais próximas ao nível da máquina, isto é, os comandos são baseados em registros

no processador que quando manipulados realizam determinada função.

Existem linguagens de máquina, linguagens assembly, e linguagens de alto

nível. Uma linguagem assembly é mais operável que a linguagem de máquina, pois

possui comandos com ações definidas. Já as linguagens de alto nível destacam-se

pela sua facilidade de uso e aprendizagem, por serem mais próximas da linguagem

humana baseando seus comandos em palavras de um idioma, geralmente o inglês.

Destacam-se algumas linguagens como PASCAL, C, Java , C++, entre outras.

(MANZANO; OLIVEIRA, 2014)

3.1.3 Java

A definição de Deitel, M. e Deitel P. para a linguagem de programação Java é

de que:

É uma linguagem de alto nível, criada em 1991, baseada em C++. Massomente chamou a atenção quando resolveram utilizá-la para adicionarconteúdo dinâmico à internet, em 1995. É usada atualmente para programasde grande porte, aplicativos móveis, aplicativos e funcionalidades da web.(DEITEL, M.; DEITEL, P., 2010. p. 6)

Java é orientada a objetos e possui centenas de bibliotecas e classes

próprias trazendo diversos recursos ao programador.

20

Quadro 2: Exemplo de algoritmo em Java

12345678910111213141516

package Exemplo;import Javax.swing.JOptionPane;public class CalculoCombustivel {

private static double kilometragem, litros , consumo;public static void main(String[] args) {String km = JOptionPane.showInputDialog("Digite

Quanto você percorreu) ");String lt= JOptionPane.showInputDialog("Digite a

quantidade de Litros Gasto");kilometragem = Double.parseDouble(km);litros = Double.parseDouble(lt);consumo = kilometragem / litros;JOptionPane.showMessageDialog(null, "A seu Consumo

de Combustivel foi de: "+consumo+" KM / L"); }}

Fonte: O Autor, 2015.

O algoritmo codificado em Java exemplificado no Quadro 2, possui a mesma

sequencia lógica para resolução do passo a passo do algoritmo escrito em portugol

descrito no Quadro 1.

3.1.4 Orientação a objetos

Para entender a modelagem de sistemas orientados a objetos, Santos (2013,

p. 2) utiliza o seguinte conceito de modelo para representação de dados: “Modelos

são representações simplificadas de objetos, pessoas, itens, tarefas, processos,

conceitos, ideias etc. Usados comumente por pessoas no seu dia a dia,

independente do uso de computadores.”

Um exemplo prático de modelo seria um pedido de compra, onde constariam

diversos dados de identificação do comprador e do vendedor, os itens vendidos bem

como sua quantidade e o total a ser pago pelo comprador.

Desta maneira Santos define Orientação a Objetos como:

Programação Orientada a Objetos ou, abreviadamente POO é umparadigma de programação de computadores onde se usam classes eobjetos, criados a partir de modelos descritos anteriormente, pararepresentar e processar dados usando programas de computadores(SANTOS, 2013, p. 5)

21

O autor conceitua que na orientação a objetos utiliza-se de classes para

declaração dos modelos, desta forma:

Classes são declaração dos modelos, de seus atributos e métodos queprocessam estes atributos; que devem ser escritas em uma linguagem deprogramação orientada a objetos, seguindo as regras e usando oscomandos e estruturas da linguagem. (SANTOS, 2013, p. 17)

No Quadro 3 a seguir, utiliza-se como exemplo a classe Filme modelada

conforme os conceitos apresentados por Santos (2013).

Quadro 3: Exemplo de classe em Java

1234567891011121314

public class Filme {private int codigo;

private String titulo; private String categoria; private String classificacao; public void setTitulo(String titulo){ this.titulo=titulo;

} public String getTitulo(){ return this.titulo; } // ... demais métodos Getter's e Setter's}


A representação gráfica das classes é feita pelo padrão UML apresentado na

subseção 3.2.2 da seção 3.2.

Sobre os atributos de uma classe, Santos define que:

Os atributos contidos em uma classe também são conhecidos como camposou estados daquela classe. Cada atributo deve ter um nome e ser de umtipo, que será ou um tipo de dado nativo da linguagem Java ou ainda umaclasse definida por um programador. Atributos também são chamados devariáveis de instância. (SANTOS, 2013, p. 17)

No Quadro 3, pode-se observar que os atributos ficam declarados logo abaixo

à declaração da classe, ou seja das linhas 2 a 5.

Também define os métodos de uma classe como:

As operações que manipulam os atributos de uma classe são chamados demétodos dessa classe. Métodos são geralmente chamados ou executadosexplicitamente a partir de outros trechos de código (comumente, outrosmétodos) na classe que os contém ou a partir de outras classes. (SANTOS,2013, p. 17)

22

No Quadro 3, pode-se observar que os métodos ficam declarados após os

atributos, tendo essa seção de declarações com início na linha 7.

Uma propriedade importante quanto aos atributos e métodos é realizar o seu

encapsulamento, definido como:

A Capacidade de ocultar dados ( ou acesso direto aos mesmos) dentro demodelos, permitindo que somente operações especializadas ou dedicadasmanipulem os dados ocultos chama-se encapsulamento, e é um dosbenefícios mais palpáveis de programação orientada a objetos. […] Comoregra, os atributos geralmente são ocultos ou privados, e as operações oumétodos que manipulam estes atributos são públicas ( não ocultas).(SANTOS, 2013, p.7)

Por questão de clareza e organização do código, utiliza-se os termos “Get” e

“Set” provenientes da língua inglesa como prefixo do nome do atributo para compor

o nome do método. Os métodos utilizados para acessar os atributos e recuperar

dados recebem o prefixo “Get”, e aqueles utilizados para acessar os atributos e

armazenar dados recebem o prefixo “Set”, como exemplificado no Quadro 3.

Finalizando a conceituação de orientação a objetos, define-se que:

Um objeto ou instância é uma materialização da classe, e assim pode serusado para armazenar os atributos e executar os métodos descritos naclasse. Para que os objetos ou instâncias possam ser manipulados, énecessária a criação de referências a estes objetos, que são basicamentevariáveis do 'tipo' da classe. (SANTOS, 2013, p.17)

Quadro 4: Exemplo de declaração de objetos em Java

123456789

package Exemplo;public class TestaFilme {

public static void main(String[] args) {Filme filme1 = new Filme();Filme filme2 = new Filme();filme1.setTitulo("Piratas do Vale do Silício");filme2.setTitulo("Os estagiarios");

}}


Observa-se que os objetos ficam armazenados em um endereço de memória

usado na máquina virtual de execução do Java (javac), portanto tem tempo de vida

determinado pelo tempo de execução do programa.

23

No Quadro 4, observa-se que na linha 1 está declarado o pacote de que a

classe pertence, na linha 2 a declaração da classe, enquanto na linha 3 a declaração

de um método main para execução do algoritmo. Nas linhas 4 e 5, pode-se observar

a declaração de dois objetos da classe Filme, e nas linhas 6 e 7 a chamada do

método setTitulo da classe Filme pela classe TestaFilme (outra classe) para acessar

os atributos da classe Filme e atribuir valores a estes.

3.2 MODELO CONCEITUAL

De acordo com Heuser (2009, p.24), “um modelo de dados é uma descrição

dos tipos de informações que estão armazenados em um banco de dados”, já o

modelo conceitual é “uma descrição do banco de dados de forma independente da

implementação em um SGBD.” (HEUSER, 2009, p. 25). Nas próximas seções

descreve-se sucessivamente a modelagem de dados utilizada para um banco de

dados, isto é, o modelo (diagrama) entidade-relacionamento; e o modelo (diagrama)

de classes da UML, finalizando com a transformação de modelo entidade-

relacionamento para o diagrama de classes da UML.

3.2.1 Diagrama entidade-relacionamento

A aplicação do modelo Entidade-Relacionamento (ER) descreve os dados

brutos antes de transformá-los em implementação de um banco de dados relacional,

o modelo ER é representado através do Diagrama Entidade-Relacionamento (DER).

(HEUSER, 2009).

Segundo Heuser (2009), o modelo ER, possui entidades como forma

de representar “conjuntos de objetos da realidade modelada sobre os quais deseja-

se manter informações no banco de dados.” “Em um DER, uma entidade é

representada por um retângulo, onde dentro dele haverá o nome dessa entidade.”

(HEUSER, 2009, p. 35). Como exemplificado na Ilustração 1, onde há uma entidade

de nome Filme, cuja representará os objetos filme (realidade).

24


Segundo Heuser (2009), os atributos são as propriedades que caracterizam

uma entidade. Cada entidade deve possuir um ou mais atributos identificadores, ou

seja, que possuem valores únicos para cada ocorrência de objeto na entidade ou

relacionamento. Na representação gráfica dos atributos, exemplificada na Ilustração

2, os atributos com o círculo preenchido representam atributos identificadores,

enquanto os não preenchidos os atributos que caracterizam a entidade

Na Ilustração 2, observa-se a mesma entidade Filme acrescida de seus

respectivos atributos. O atributo código assume um valor único, ou seja, cada filme

possui um código diferente. O atributo título especifica o nome do filme, a descrição

apresenta um resumo breve sobre ele e o ano de lançamento como forma de

informar a atualidade do mesmo.

Segundo Heuser (2009), entidades podem se relacionar quando ocorrências

de objetos de entidades diferentes ou não, possuírem semelhanças ou se

segregarem entre si, e também quando um depender das atividades do outro. No

DER, o relacionamento é representado por um losango ligado por linhas às

Ilustração 1: Exemplo de Entidade

Ilustração 2: Exemplo de entidade com atributos


25

entidades participantes do relacionamento, neste losango também deve-se utilizar

um nome representativo para o relacionamento ou sua função.

Uma propriedade importante do relacionamento é gerenciar o número de

ocorrências que uma entidade pode exercer dentro de um determinado

relacionamento, bem como o valor mínimo e o valor máximo de objetos

participantes.

O valor máximo de uma ocorrência pode ser determinado com um número

inteiro definido ou uma variável que indica muitas ocorrências e não possui restrição

de valor máximo, representada pelo símbolo “n”. Também é utilizado o algarismo “1”

para representar o valor único na participação.

O valor mínimo de participação difere em duas formas: nenhuma ocorrência,

representada pelo algarismo “0” e uma ocorrência, representada pelo algarismo “1”.

A representação gráfica é feita através de o valor mínimo e o valor máximo entre

parênteses e separados por vírgulas em cada extremo do relacionamento.

(HEUSER, 2009)

A Ilustração 3, apresenta a entidade Filme acompanhada da entidade

Categoria, e o respectivo relacionamento entre ambas, chamado de classificação. A

entidade Categoria participa do relacionamento com no mínimo zero ou no máximo

um objeto, a entidade Filme participa com no mínimo zero e no máximo muitos

objetos.

Desta forma lê-se o diagrama considerando que uma Categoria possui zero

ou muitos filmes para classificação, e um Filme possui nenhuma ou no máximo uma

Categoria como forma de classificação.

Ilustração 3: Entidades com Relacionamento


26

3.2.2 Diagrama de classes da UML

Segundo Bezerra (2007, p.15) “A UML é uma linguagem visual para modelar

sistemas orientados a objetos. Isso quer dizer que a UML é uma linguagem que

define elementos gráficos (visuais) que podem ser utilizados na modelagem de

sistemas.”

Denota-se que cada elemento da UML possui uma sintaxe e uma semântica,

onde a sintaxe significa as regras de construção desses elementos e a semântica o

sentido no contexto que determinado elemento representa. (BEZERRA, 2007).

A UML é gerenciada pelo OMG (Object Management Group) que define

padrões para a orientação a objetos. A UML possui 13 diagramas que “são utilizados

para construir modelos de diversas perspectivas do sistema.” (BEZERRA, 2007, p.

18). Um dos 13 diagramas da UML, o diagrama de classes, foi utilizado neste

trabalho na fase de análise e projeto do software, sendo que o resultado de sua

construção é apresentado no Capítulo 5.

Após os dados serem manipulados por um aplicativo, algumas informações

necessitam ser guardadas para posteriores utilizações do sistema, podendo ser em

um banco de dados relacional ou em arquivos. Desta forma, quando se armazena

em arquivos pode-se projetar a arquitetura do sistema orientado a objetos utilizando

uma linguagem de modelagem de classes da UML.

Em um Diagrama de Classes, uma classe é representada por um retângulo

com no máximo três compartimentos (divisões) a serem exibidos. No primeiro

compartimento especifica-se o nome da classe, que por convecção é apresentado

no singular iniciando com letra maiúscula.

No segundo compartimento, são representados os atributos da classe que

representam informações sobre os objetos da mesma, enquanto no terceiro

compartimento são representados os métodos da classe que são as ações que um

objeto pode realizar. O primeiro compartimento é obrigatório enquanto os outros dois

não, porém geralmente a classe possui atributos e métodos para representação.

(BEZERRA, 2007) Desta forma, observa-se na Ilustração 4 o exemplo da classe

Filme, e suas possíveis representações.

27


Tem-se na Ilustração 4, os possíveis atributos da classe Filme precedidos

pelo símbolo de subtração ( - ) que indica o encapsulamento ou visibilidade do

atributo, “a visibilidade de um atributo diz respeito ao seu nível de acesso”

(BEZERRA, 2007, p. 238), desta forma, observa-se no Quadro 5 o nível de

encapsulamento com seu respectivo símbolo e significado para o diagrama de

classes da UML.

Quadro 5: Possíveis visibilidades de um elemento (atributo ou operação)

Visibilidade Símbolo Significado

Pública + Qualquer objeto externo pode obter acesso ao elemento, desde

que tenha uma referência para a classe em que o atributo está

definido.

Protegida # O elemento protegido é visível para subclasses da classe em que

este foi definido.

Privativa - O elemento privativo é invisível externamente para classe em que

este está definido.

Pacote ~ O elemento é visível a qualquer classe que pertence ao mesmo

pacote no qual está definida a classe.

Fonte: Bezerra, 2007, p.239.

Desta forma, utilizando-se das referências de Bezerra (2007, p.238) pode-se

definir uma sintaxe para declaração de atributos, cuja está exemplificada no Quadro

6, linha 1. A sintaxe inicia com o símbolo do encapsulamento (Quadro 5) seguido

pelo nome do atributo e o tipo de dado representado por ele, que diverge com a

linguagem de programação e seus tipos primitivos ou ainda pode ser uma classe

definida pelo programador. Pode-se declarar um valor inicial ao atributo utilizando o

sinal de igualdade ( = ) seguido pelo respectivo valor.

Ilustração 4: Exemplo de Classe em UML

28

Quadro 6: Sintaxes UML

1 Visibilidade nomeDoAtributo: tipo = “valor_inicial”

2 Visibilidade nomeDoMétodo( parâmetros) : tipo_retorno {propriedades}

3 Direção nome-parâmetro: tipo-parâmetroFonte: O Autor, 2015.

Segundo Bezerra (2007), os métodos que são as operações descritas em

uma classe são definidos em UML com a sintaxe: iniciando com o símbolo da

visibilidade do método, acrescido pelo nome do método, o parâmetro entre

parênteses, sinal de dois pontos e o tipo de retorno, como exemplificada no Quadro

6, linha 2.

Segundo Bezerra (2007), os parâmetros de um método possuem direção “que

serve para definir se o parâmetro pode ou não ser modificado pela

operação”(BEZERRA, 2007, p. 242). Precedem a declaração do parâmetro e podem

ser de três tipos com significados definidos pela UML. A direção “in” que segundo a

UML “não pode ser modificado pela operação. Serve somente como informação para

o objeto receptor” (BEZERRA, 2007, p. 242).

A direção “out” que “pode ser modificado pela operação para fornecer

alguma informação ao objeto remetente” (BEZERRA, 2007, p. 242). A direção

“inout” “Parâmetro de entrada que pode ser modificado.” (BEZERRA, 2007, p. 242).

Após a direção, segue-se na sintaxe com o nome do parâmetro que deve ser único

dentro da assinatura da operação, e por último o tipo de dado passado por

parâmetro à operação e o nome da variável, exemplificado no Quadro 6, linha 3.

A associação entre classes é descrita nas palavras de Bezerra (2007, p. 113)

como:

Para representar o fato de que os objetos podem se relacionar uns com osoutros, existe outro elemento na notação do diagrama de classes, aassociação. […] Uma associação é representada no diagrama de classespor uma linha ( normalmente um segmento de reta) ligando as classes àsquais pertencem os objetos relacionados.

Embora no diagrama de classes a associação seja representada entre

classes, no sistema são executadas por objetos que são capazes de trocar

informações para realizar determinada tarefa do sistema. No diagrama as

Associações possuem características importantes como: multiplicidade, nome,

direção de leitura, papéis, tipo de participação e conectividade.(BEZERRA, 2007)

29

Quadro 7: Conectividade versus multiplicidades

Conectividade Multiplicidade de um

extremo

Multiplicidade do outro

extremo

Um para um 0.. 1 ou 1 0.. 1 ou 1

Um para muitos 0.. 1 ou 1 * ou 1..* ou 0..*

Muitos para muitos * ou 1.. * ou 0..* * ou 1..* ou 0..*Fonte: Bezerra, 2007, p. 116.

Segundo Bezerra (2007) a multiplicidade na associação serve para definir o

número inteiro mínimo e máximo de ocorrências de objetos de uma classe na

associação, sendo que a união dos dois extremos da classe formam a conectividade

como descrito no Quadro 7. Na Ilustração 5, demonstra-se a utilização de uma

associação entre a classe Filme e a classe Categoria, com a conectividade Um para

muitos.


A Ilustração 5, apresenta a classe Filme se associando com a classe

Categoria com o esteriótipo <<Enum>>, ou seja, a classe apresentará objetos

constantes de três tipos: romance, comédia ou aventura.

Segundo Bezerra, na denotação da UML a participação de um objeto na

classe “está relacionada à necessidade ou não da existência dessa associação entre

objetos. Se o valor mínimo da multiplicidade de uma associação é igual a 1 (um),

significa que a participação é obrigatória. Caso contrário, a participação é opcional.”

(BEZERRA, 2007, p. 117) Como se pode observar na Ilustração 5, onde a classe

Ilustração 5: Exemplo de associação em UML

30

Categoria participa obrigatoriamente com um objeto e a classe Filme pode participar

da associação com nenhum objeto.

Observando-se a Ilustração 5 o nome da associação é “pertence”, sendo que

este nome sempre deve fornecer algum significado semântico à mesma. Já os

nomes de papéis são indicados próximo a classe e servem justamente para indicar o

“papel da classe”, isto é, a participação dos objetos da classe na associação,

quando não se define um substantivo de identificação pode-se utilizar o nome da

classe para representar seu papel. (BEZERRA, 2007)

As associações podem ser classificadas como unidirecionais ou bidirecionais,

as bidirecionais não possuem restrições, ou seja, todos os objetos de uma

determinada classe “C1” conhecem todos os objetos relacionados consigo de outra

classe “C2” e vice-versa, que é o caso da associação exemplificada na Ilustração 5.

Uma associação unidirecional, exemplificada na Ilustração 6, impede que o

objeto de uma classe “A” conheça o objeto de outra classe “B” na qual está

relacionado, associações unidirecionais são representadas por uma flecha

apontando para a classe em que se tem o acesso, e dois cortes diagonais indicando

o não acesso a referencias na associação. (BEZERRA, 2007)

Existem outros tipos de associações que não serão referenciados devido ao

fato de não utilizá-los na realização do projeto do sistema, são eles: a generalização,

especialização, agregações, composições, associações reflexivas, associações

ternárias e classes associativas.

Ilustração 6: Exemplo de associação unidirecional


31

3.2.3 Transformação do diagrama ER para o diagrama de classes da UML

Na Ilustração 7, tem-se duas entidades do diagrama ER do projeto, este

diagrama foi elaborado no ano de 2014 pela ex-estudante Raquel Ferreira Pereira

do curso técnico em informática integrado ao ensino médio do Instituto Federal

Catarinense Campus Avançado Sombrio.

Fonte: Pereira, 2014.

Na Ilustração 7, observa-se as duas classes, Conta e Banco que possuem a

mesma modelagem que as entidades Conta e Banco na Ilustração 6, isto é, a

mesma abstração de dados, tornando-as equivalentes. Todavia na Ilustração 6 a

modelagem é feita em Entidade Relacionamento (ER), enquanto na Ilustração 7 no

Diagrama de Classes da UML.


Com os dois diagramas de modelagem, pode-se definir a transformação da

seguinte forma: As entidades, representadas pelos retângulos, do modelo ER

passam a serem classes do Diagrama de Classes da UML, seguindo as mesmas

regras de definição de classes descritas na seção 3.2.2. Os atributos do modelo ER

passam a ser atributos das classes, com, em alguns casos, o acréscimo de alguns

Ilustração 7: Entidades do Diagrama ER do projeto

Ilustração 8: Classes do diagrama de classes do projeto

32

atributos para maior precisão de modelagem. Um diferencial que pode ser notado é

que os métodos que podem estar presentes no diagrama de classes, não são

representados pelo fato de que a camada de persistência de dados1 é o foco nesta

transformação.

Os Relacionamentos do modelo ER passam a serem as Associações do

diagrama de classes, acompanhados da cardinalidade que passa a ser a

multiplicidade das classes. Além das correspondências dos dois modelos, outros

recursos adicionais estão presentes no diagrama de classes da UML, como por

exemplo, a navegabilidade de associações, o encapsulamento dos atributos e os

métodos das classes.

3.3 MAPEAMENTO DE ASSOCIAÇÕES EM JAVA

Linguagens de programação orientadas a objetos como Java, utilizada por

este projeto, não possuem suporte próprio para a construção de associações. Os

programadores utilizam padrões de escrita de código para construir associações,

utilizando de recursos como os métodos, os atributos e as classes (NOBLE, 1997

apud CARDOSO, 2011).

Segundo Noble (1997 apud CARDOSO, 2011) existem cinco padrões comuns

entre programadores para codificação de associações em uma linguagem de

programação orientada a objetos: associação como atributo, objeto de associação,

objeto de coleção, active value e mutual friends. Estes padrões apenas permitem a

comunicação entre as instâncias das classes, a multiplicidade e a navegabilidade

são características de cada padrão.

Utilizou-se nesta pesquisa três destes padrões para implementar o diagrama

de classes do projeto em Java, são eles: associação como atributo, objeto de

coleção e o Mutual Friends, que são apresentados nas próximas subseções.

3.3.1 Associação como atributo

Segundo Noble (1997, tradução nossa), o padrão associação como atributo é

utilizado quando há uma associação simples, com multiplicidade um-para-um.

1 “O objetivo de uma camada de persistência é isolar os objetos do sistema de mudanças no

mecanismo de armazenamento” (BEZERRA, 2007, p. 350)

33

Porém, é possível também utilizar em casos em que a direção da associação aponta

para a extremidade do único objeto (extremidade um), ou seja, um-para-muitos.

A Ilustração 9, representa a associação MovimentacaoTipo entre a classe

Movimentacao e a classe TipoMovimentacao, que possui navegabilidade

unidirecional no sentido do único objeto TipoMovimentacao. Desta forma, quando

utilizado esse tipo de associação, utiliza-se este padrão, que é implementado em

Java conforme exemplificado no Quadro 8.

Quadro 8: Implementação em Java do padrão associação como atributo

123456789101112131415

public class TipoMovimentacao {//atributos e métodos

}public class Movimentacao {

//atributo como associaçãoprivate TipoMovimentacao tipoMovimentacao; //métodos de acesso ao atributo tipoMovimentacaopublic TipoMovimentacao getTipoMovimentacao( ) {

return this.tipoMovimentacao;}public void setTipoMovimentacao(TipoMovimentacao tipoMov) {

this.tipoMovimentacao = tipoMov;}

}Fonte: O Autor, 2015.

No Quadro 8, a classe TipoMovimentacao (linhas 1 à 3) não recebe

implementação da associação pois sua participação é ser atributo (linha 6) de

Ilustração 9: Diagrama UML com associação um-para-muitos unidirecional


34

objetos da classe Movimentacao (linhas 4 à 15) que possuem esta característica de

possuir um tipo de movimentação. O acesso a este atributo é feito através dos

métodos getTipoMovimentacao (linhas 10 à 12) que retorna o tipo (atributo) daquele

determinado objeto de Movimentacao, e do método setTipoMovimentacao (linhas 11

à 14) que insere um tipo ao objeto de Movimentacao.

3.3.2 Objeto de coleção

Segundo Noble, o padrão objeto de coleção:

[...] é utilizado para implementar associações simples um para-muitos,

navegável na direção do único objeto para os muitos objetos associados.

Este consiste em criar um atributo na classe em que a multiplicidade de

papel é um. O atributo refere-se a uma coleção de todos os objetos da

classe oposta (em que a multiplicidade de papel é muitos) linkados ao objeto

proprietário da coleção. (NOBLE, 1997 apud CARDOSO, 2011, p. 47)

Na Ilustração 10, têm-se as classes ContaBancaria e Movimentacao

representadas no diagrama de clases da UML com a associação

ContaMovimentacao, que possui navegabilidade unidirecional no sentido dos muitos

objetos da classe Movimentacao.

Neste padrão a classe Movimentacao, que possui a extremidade zero-para-

muitos na associação, somente implementará seus próprios atributos e métodos de

Ilustração 10: Diagrama UML com associação um-para-muitos unidirecional


35

acesso que possui, enquanto a classe ContaBancaria, que possui a extremidade um

e a restrição de navegabilidade, abrigará uma coleção de muitos objetos da classe

Movimentação, como exemplificado no Quadro 9, que teve seus métodos de acesso

aos atributos ocultados para melhor entendimento do código.

Quadro 9: Implementação em Java do padrão objeto de coleção

123456789101112131415161718192021222324252627

import Java.util.HashSet;import Java.util.Set;public class ContaBancaria {

//atributo Objeto de Coleçãoprivate Set<Movimentacao> movimentacoes;movimentacoes = new HashSet<Movimentacao>();//Métodos de manipuação do atributopublic boolean addMovimentacao(Movimentacao mov) {

return this.movimentacoes.add(mov); }public boolean removeMovimentacao(Movimentacao mov) {

return movimentacoes.remove(mov); }public Set<Movimentacao> getMovimentacoes(){

return this.movimentacoes; }public void limparMovimentacoes() {

for (Movimentacao m: movimentacoes) {m.unSetCategoria();m.unSetFavorecido();

}this.movimentacoes.clear();

}} public class Movimentacao {

//atributos e métodos}


No Quadro 9, a classe Movimentacao (linhas 18 a 20) não recebe nenhum

atributo ou método na implementação da associação ContaMovimentacao, pois a

navegabilidade não permite que os objetos desta classe tenham visibilidade para os

respectivos objetos relacionados à classe ContaBancaria.

Desta forma, a implementação da associação ContaMovimentacao se faz

presente na classe ContaBancaria (linhas 3 a 17) com a utilização da classe

HashSet representando um conjunto ou coleção de objetos da classe

Movimentacao, assim, quando criado um objeto ContaBancaria ele terá um conjunto

36

de Movimentações agregados a si, restringindo no mínimo zero (conjunto vazio em

seu estado inicial) e no máximo muitas Movimentacoes serão vinculadas pois o

HashSet não possui tamanho máximo, construindo uma lista dinâmica de objetos.

3.3.3 Mutual Friends

Este padrão, que se traduzido representa “amigos mútuos” em português, é

utilizado em casos de navegabilidade bidirecional, quando se necessita de que

ambos objetos obtenham referência ao objeto da classe oposta em que está

associado. Noble define que “O padrão mutual friends é utilizado para

implementação de associações simples navegáveis em ambos os sentidos, podendo

ter multiplicidade um-para-um, um-para-muitos ou muitos-para-muitos” (NOBLE,

1997 apud CARDOSO, 2011).

A Ilustração 11, apresenta um exemplo de diagrama em UML da classe

Banco e ContaBancaria que necessitam de navegabilidade bidirecional na

associação BancoConta, as classes envolvidas apresentam multiplicidade um-para-

muitos, a implementação deste padrão está representada pelo código em Java,

apresentado no Quadro 10.


O padrão mutual friends especifica que para tornar a associação bidirecional,

ou seja, navegável em ambos os sentidos deve-se dividir a implementação em

ambas as classes, de modo que as duas implementam a associação utilizando um

mecanismo de sincronização que associe os objetos. A implementação pode ser

feita pelo padrão associação como atributo, quando a classe participa com apenas

uma referência de objeto, ou objeto de coleção quando a classe participa com mais

Ilustração 11: Diagrama UML com associação um-para-muitos bidirecional

37

que um objeto na associação. Além disso, deve-se definir uma forma de

sincronização entre as duas classes, de forma que quando uma instância é

modificada, todos os objetos associados também são.

Quadro 10: Implementação em Java do padrão Mutual Friends

123456789101112131415161718192021222324252627282930313233343536373839404142


//associação como atributoprivate Banco banco;// métodos de implementação da associaçãovoid privateSetBanco(Banco banco) throws Exception{

if(this.banco==null) { this.banco=banco;

}else if (this.banco!=banco){ throw new Exception();

} }void privateUnSetBanco( ) {

this.banco=null;}public void setBanco(Banco banco) throws Exception {

banco.addConta(this); }public void unSetBanco(Banco banco){

banco.removeConta(this);}public Banco getBanco( ){

return this.banco; }

public class Banco {// objeto de coleçãoprivate Set<ContaBancaria> contasBancárias; contasBancárias = new HashSet<ContaBancaria>( );//métodos de implementação da associaçãopublic void addConta(ContaBancaria ContaBancaria) {

ContaBancaria.privateSetBanco(this);this.contasBancárias.add(ContaBancaria);

}public void removeConta(ContaBancaria ContaBancaria){

ContaBancaria.privateUnSetBanco();this.contasBancárias.remove(ContaBancaria);

}public Set<ContaBancaria> getContas( ) {

return this.contasBancárias; }

} Fonte: O Autor, 2015.

38

Uma das classes deve empenhar o papel de líder na associação, enquanto a

outra sua seguidora. A classe líder implementará a manipulação de ambas as

classes, dispondo de métodos com visibilidade restrita, que a classe seguidora

oferecerá somente a classe líder. (NOBLE, 1997 apud CARDOSO, 2011)

No Quadro 10, tem-se a implementação em Java da associação entre as

classes representadas na Ilustração 10, esta associação é bidirecional, a classe

ContaBancaria implementa a associação como atributo (linha 5), e a classe Banco

implementa a associação como objeto de coleção (linha 28). A classe Banco tem o

papel de líder, enquanto a classe ContaBancaria, de seguidor. Os métodos da classe

Banco (linhas 31 a 41) modificam as referências em ambas os lados da associação,

através da chamada dos métodos privateSetBanco e privateUnSetBanco (linhas 14

a 19) presentes na classe ContaBancaria que atribuem o uso à classe Banco, e

delegam o poder de modificação de suas referências.

3.4 SERIALIZAÇÃO DE OBJETOS EM JAVA

Segundo Guerra (2014), “Quando dizemos que um objeto é serializado,

estamos afirmando que este objeto será transformado em bytes, e poderá ser

armazenado em disco ou transmitido por um stream.”

Um stream, é um fluxo de dados, também chamado de córrego de

informações, uma stream é responsável pelo “transporte”, entrada ou saída, de

bytes ao longo do “córrego”. (ORACLE, 2015)

Segundo a Oracle (2015), a interface Serializable presente no Java SE 7, é

responsável por tornar as instâncias das classes que a implementam, serializaveis,

ou seja permite a transformação destes objetos em bytes, processo chamado de

serialização, ou os bytes lidos em objeto, processo chamado de desserialização.

Portanto, para que seja possível serializar objetos de uma classe, esta deverá

implementar a interface Serializable.

39

3.4.1 Objetos transformados em bytes

Segundo a Oracle (2015), no Java SE 7, a classe ObjectOutputStream é

responsável por escrever tipos primitivos de dados, ou classes Java para um objeto

OutputStream. Para que um objeto possa ser transformado em bytes e lançado a um

OutputStream, a classe do respectivo objeto deve implementar a interface

Java.io.Serializable, a codificação destes objetos é feita desde o nome da classe,

passando por sua assinatura e seus atributos até os objetos referenciados a ela.

Ainda de acordo com a Oracle (2015), no Java SE 7, a classe

ByteArrayOutputStream é utilizada para implementar um fluxo de saída em forma de

bytes, ou seja ela é responsável por transformar objetos Java ou tipos primitivos de

dados em um array de bytes.

Desta forma, combinando as duas classes pode-se construir um mecanismo

de conversão de objeto para um byte array, como exemplificado no Quadro 11.

Quadro 11: Método que realiza a transformação de Objeto em Bytes

12345678910

public byte[] getBytesObject(Object o)throws IOException{ByteArrayOutputStream baos;baos = new ByteArrayOutputStream();ObjectOutputStream oos=new ObjectOutputStream(baos);

oos.writeObject(o); byte[ ] yourBytes = baos.toByteArray();

baos.close();oos.close();

return yourBytes;}


No Quadro 11, o método getBytesObject (linhas 1 a 10), recebe como

parâmetro um Object, que pode ser um tipo primitivo, uma classe Java, arrays ou

matrizes. Com os objetos das classes ByteArrayOutputStream (linha 2) e

ObjectOutputStream (linha 3) que recebe como construtor o objeto

ByteArrayOutputStream, pode-se chamar o método writeObject (linha 5) do objeto

ObjectOutputStream, passando como parâmetro o Object, para que este seja escrito

e posteriormente (linha 6) transformado em bytes, através do objeto

ByteArrayOutputStream usando seu método toByteArray.

40

3.4.2 Bytes transformados em objetos

Segundo a Oracle (2015), no Java SE 7, a classe ObjectInputStream é

responsável por fazer o caminho inverso da classe ObjectOutputStream, ou seja

reconstruir o objeto serializado, a partir de uma stream de dados escrita usando

ObjectOutputStream.

Ainda segundo a Oracle (2015), no Java SE 7, a classe

ByteArrayInputStream é responsável por transformar uma stream de dados em um

array de bytes, ou seja essa classe permite ler um stream de dados e construir um

array de bytes a partir deles.

Desta forma, combinando as duas classes, pode-se construir um mecanismo

de leitura de bytes que os transforma em objetos novamente, como exemplificado no

método explícito no Quadro 12.

Quadro 12: Método que realiza a transformação de bytes em objeto

12345678101112

public Object bytesToObject(byte[] byteAsObj) throws IOException, ClassNotFoundException

{ByteArrayInputStream bais;

bais = new ByteArrayInputStream(byteAsObj); ObjectInputStream ous; ois = new ObjectInputStream(bais); Object obj = ois.readObject(); ois.close(); bais.close(); return obj;}


No Quadro 12, o método bytesToObject (linhas 1 a 12), recebe como

parâmetro um byte[] (byte array). Com os objetos das classes ByteArrayInputStream

(linha 3) que recebe o byte[ ] parâmetro do método, e ObjectInputStream (linha 5)

que recebe como construtor o objeto ByteArrayInputStream, pode-se chamar o

método readObject (linha 7) do objeto ObjectInputStream, que deve ler estes bytes,

e reconstruir a partir deles um Object que é o retorno do método.

41

3.5 CRIPTOGRAFIA DE DADOS

Segundo Moraes (2010, p. 213), “Criptografia é a ciência que por meio da

matemática permite criptografar (cripto=esconder) e descriptografar dados.”

Técnicas de criptografia garantem o sigilo das informações. Supondo que um

usuário remetente deseja mandar uma mensagem de texto, sem criptografia, a um

outro usuário destinatário; qualquer intruso que intercepte a mensagem no caminho,

seja ele software ou ser humano, poderá a ler a mensagem sem problemas.

Já se criptografada, o intruso encontraria um texto cifrado, isto é, longe de

uma linguagem de escrita. Tudo isto mediado por um algoritmo criptográfico que é o

mecanismo que transforma os dados normais em dados cifrados a partir de uma

chave criptográfica que pode ser usada também para recuperar os dados.

(KUROSE; ROSS, 2010).

A criptografia existe há alguns séculos. Julio César, no império Romano, já

utilizava a criptografia, porém estas técnicas foram se aprimorando ao longo do

tempo para garantir a dificuldade em quebrar uma cifragem. Nos computadores a

criptografia é realizada por um algoritmo e uma chave criptográfica. Cada algoritmo

trabalha de forma diferente, porém estes possuem características comuns como a

substituição, as combinações matemáticas, uso de matrizes entre outros. Isto torna

a criptografia na computação segura pois o custo para se descobrir o algoritmo

utilizado e a chave criptográfica é geralmente maior do que o valor dos dados em si.

(MORAES, 2010).

Existem dois tipos de criptografia, a criptografia simétrica, também chamada

de criptografia de chave privada e a criptografia assimétrica, também chamada de

criptografia de chave pública. Desta forma, em “algoritmos de chave simétrica

ambos, quem envia e quem recebe a mensagem deve possuir a mesma chave”

(MORAES, 2010, p. 220). Quando se necessita utilizar uma senha de acesso, a

criptografia simétrica é utilizada pois somente uma senha, utilizada em forma de

chave, terá o acesso aos dados. Existem muitos algoritmos de chave simétrica como

por exemplo o utilizado no projeto, o Advanced Encrypt Standart (AES). Ele usa uma

chave criptográfica de até 256 bits (32 Bytes). (MORAES, 2010).

A criptografia assimétrica “baseia-se na utilização de duas chaves, sendo uma

mantida secreta enquanto outra pode ser divulgada publicamente”(MORAES, 2010,

42

p. 222). Além de proteger informações é uma maneira eficiente de implementar

assinatura e certificados digitais. (MORAES, 2010).

3.6 GRAVAR E LER BYTES EM ARQUIVOS

Para garantir a persistência de dados pós execução, os dados podem ser

gravados em arquivos. Os dados são gravados em arquivos em forma de bytes,

desta forma, neste projeto, após a transformação de instâncias de classes em byte

arrays e a opção de criptografia destes dados, os mesmos são gravados em

arquivos, utilizando as classes FileOutputStream e FileInputStream.

Segundo a Oracle (2015), no Java SE 7, a classe FileOutputStream é

responsável pela gravação de um fluxo de saída de dados em forma de bytes em

um arquivo em disco. Enquando a classe FileInputStream é responsável pela leitura

de um arquivo em um sistema de arquivos, esta classe é destinada a ler fluxos de

bytes crus, como por exemplo byte arrays.

No Quadro 13, tem-se um método escrito em Java que utiliza a classe

FileOutputStream para escrita de dados em arquivos.

Quadro 13: Método de escrita de dados em arquivo

123456789101112

public void gravar(String local, byte[] b) throws Exception {

FileOutputStream outFile;outFile= new FileOutputStream(local);

ByteArrayOutputStream bout;bout = new ByteArrayOutputStream();

bout.write(b); bout.writeTo(outFile); outFile.close(); bout.close(); bout.flush();}


Quanto ao método descrito no Quadro 13, a classe ByteArrayOutputStream

foi utilizada como complemento, para criar o fluxo de dados a partir do array de

bytes parametro do método (linha 7) e escrevê-los no arquivo através do objeto

FileOutputStream instanciado a partir de um caminho absoluto no sistema de

arquivos (linha 8).

43

No Quadro 14, tem-se o método de leitura de dados a partir de um arquivo,

que utiliza a classe FileInputStream para esta operação.

Quadro 14: Método de leitura de dados em arquivo

12345678

public byte[] abrir(File f) throws Exception {int lenght = (int) f.length();

byte[] bytes = new byte[lenght]; FileInputStream inFile = new FileInputStream(f); inFile.read(bytes, 0, lenght); inFile.close(); return bytes;}


No método descrito no Quadro 14, resgata-se do objeto File (classe Java para

manipulação de arquivos) recebido como parâmetro, o tamanho, ou seja o número

de bytes do arquivo (linha 2). Um array de bytes é criado com o tamanho fixo

resgatado (linha 3). O objeto FileInputStream recebe em seu construtor o objeto File

(linha 4) e através do método read (linha 5) parametrizado com o byte array, o índice

inicial e número máximo de bytes destinados à leitura do arquivo e escrita para o

retorno do mesmo byte array contendo os bytes lidos no arquivo (linha 7).

3.7 IMPLEMENTAÇÃO DE FILAS

Segundo Goodrish (2013, p. 218), a fila é uma estrutura de dados em que

uma coleção de objetos é manipulada de acordo com o princípio de que “o primeiro

que entra é o primeiro que sai (FIFO – First In First Out)”, desta maneira diz-se que

em uma fila os objetos são inseridos na cauda e retirados na ponta, de forma que

quem está na fila há mais tempo, é o primeiro a ser retirado.

Goodrish (2013, p. 219) também afirma que, o Java fornece uma interface de

fila, a Java.util.Queue, também possui classes concretas que suportam o princípio

FIFO implementando a interface Queue, como por exemplo a classe Java

Java.util.LinkedList.

Neste projeto, necessitou-se o uso de uma fila para a construção de um menu

de arquivos recentes, este menu apresenta um tamanho máximo de 5 objetos, cada

objeto representa um arquivo, e o primeiro arquivo a entrar na fila, deve ser o

44

primeiro a sair no momento em que a fila estive lotada (mais que 5 objetos). Desta

forma, tem-se no Quadro 15, a classe ArquivosRecentes utilizada para instanciar os

objetos, e no Quadro 16, a implementação em Java desta fila para manipulação do

menu arquivos recentes.

Quadro 15: Classe ArquivosRecentes

1234

public class ArquivosRecentes {String nomeArquivo;String caminhoAbsoluto;


Quadro 16: Implementação de uma fila em Java

1234567891011121314151617

//Comando que instância a fila de objetos da classe ArquivosRecentesQueue<ArquivosRecentes> fila;fila = new LinkedList<ArquivosRecentes>( );

// instânciando objeto da classe ArquivosRecentes.ArquivosRecentes arquivo = new ArquivosRecentes();arquivo.nomeArquivo = "Arquivo.ext";arquivo.caminhoAbsoluto ="c:\minhaPasta\Arquivo.ext";

// O trecho abaixo verifica tamanho e insere um objeto ao fim da filaif (fila.size() < 5) {

fila.add(arquivo);}else if (fila.size() == 5){

fila.poll(); //remove o primeiro elementofila.add(arquivo)

}// O comando abaixo remove um objeto do início da fila

fila.poll();Fonte: O Autor, 2015.

45

4 MATERIAIS E MÉTODOS

As próximas duas seções (4.1 e 4.2) relatam respectivamente, o material

utilizado e a metodologia adotada neste trabalho.

4.1 MATERIAL

A fim de cumprir com os objetivos deste trabalho, utilizou-se de materiais para

tal execução, os quais possibilitaram a migração do gerenciador financeiro GEF.

Como ambiente de desenvolvimento do software, utilizou-se o NetBeans IDE

em sua versão 8.0.2.

Para modelagem da estrutura de classes do sistema, utilizou-se o software

VisualParadigm em sua versão 12.0 Community Edition, versão livre para uso não

comercial, para construir o diagrama de classes da UML.

Para desenvolvimento do sistema, utilizou-se a linguagem de programação

Java; para isso se necessitou instalar o Java Development Kit (JDK), o kit de

desenvolvimento da linguagem Java em sua versão 7.

Para emissão de relatórios no formato Portable Document Format (PDF),

utilizou-se o software livre IReport na versão 5.6.0, que é uma extensão ao

NetBeans IDE, para modelar de forma gráfica o PDF e obter o código na linguagem

XML(Extensible Markup Language) responsável pela criação do documento. Além

do software utilizou-se as seguintes bibliotecas do projeto JasperReports: commons-

beanutils 1.9, commons-collections 3.2.1, commons- digester 2.1, commons-logging

1.1.1, groovy-all 2.0.1, itext-pdfa 5.5.0, itext-pdf 5.5.0, jasperreports 6.0.3,

jasperreports-fonts 6.0.3, jasperreports-Javaflow 6.0.3, poi 3.10.1,e a servlet-api 2.4.

4.2 MÉTODOS

A metodologia adotada em um projeto é importante para atingirem-se os

objetivos propostos, sendo que a deste está apresentada nas próximas subseções

em ordem cronológica.

46

Segundo Gil (2010, p. 29) “A pesquisa bibliográfica é elaborada com base em

material já publicado.” Para atingir os requisitos traçados necessitou-se a adequação

a algumas áreas da informática, tal feito alcançado através do levantamento

bibliográfico e pesquisas online. “A principal vantagem da pesquisa bibliográfica

reside no fato de permitir ao investigador a cobertura de uma gama de fenômenos

muito mais ampla do que aquela que poderia pesquisar diretamente.”(GIL, 2010, p.

30). Ainda, “pode-se afirmar que a pesquisa científica é aquela voltada ao avanço

do conhecimento científico, ao entendimento da realidade e está muito mais atrelada

às teorias científicas, que são mutáveis.” (FREITAS JUNIOR et al, 2014).

Buscou-se conhecimentos na área da criptografia de dados, de modelagem de

sistemas utilizando a UML, além da implementação dos elementos do diagrama de

classes da UML utilizando a linguagem de programação Java, com a finalidade de

migrar a persistência de banco de dados para arquivos em um gerenciador

financeiro.

4.2.1 Definição dos Requisitos

A definição dos requisitos foi o ponto inicial no desenvolvimento do presente

trabalho. Com a companhia do professor-orientador definiu-se o tema e justificativa

do trabalho junto aos requisitos exemplificados a seguir.

O software deve trabalhar salvando seus dados somente em arquivos,

dispensando a necessidade de instalar um banco de dados.

O software deve cadastrar, excluir, editar e listar os dados de cada uma das 5

entidades do sistema assim como na versão que armazena dados em banco de

dados.

O software deve dispor ao usuário outras funções, a filtragem de dados em

que se pode combinar restrições, diferentemente da versão anterior onde não se

poderia combinar os filtros.

A apresentação dinâmica dos dados poderia ser melhorada, trazendo-os em

relatórios em tela ou utilizando um gerador de arquivos PDF.

Por se tratar de dados pessoais, o software deve realizar a segurança dos

arquivos, protegendo-os com uma senha de acesso.

47

4.2.2 Projeto

Antes de projetar o software, definiu-se um cronograma de atividades para o

período de realização do projeto, separando cada etapa em quinzenas, estipulando

prazos e prevenindo atrasos. O Cronograma de atividades seguido, encontra-se no

Apêndice A.

Projetou-se o software pensando em sua melhor forma de implementá-lo, pois

a adição de novos elementos ao diagrama de classes possibilitou o mecanismo de

comunicação dos objetos no sistema. Primeiramente, estudou-se o diagrama ER do

sistema, e então realizou-se a migração do diagrama ER para o diagrama de

classes da UML.

No diagrama da UML necessitou-se além de transformar entidades em

classes, definir uma classe controladora que armazena todas as instâncias do

programa para que um único objeto fosse serializado no arquivo.

A definição das navegabilidades das classes e a criação das classes com o

esteriótipo enumeration foram os recursos extras adicionados, também utilizados na

implementação em Java.

4.2.3 Implementação

A implementação do diagrama de classes em Java no gerenciador financeiro

GEF foi iniciada com a construção das classes na linguagem de programação Java.

Após a definição das classes, iniciou-se a implementação dos cadastros, ou seja a

criação de objetos utilizando Interface Gráfica. Começou-se pela classe menos

dependente no sistema, a classe banco, que armazena suas instâncias em uma

coleção de objetos por se relacionar com a controladora.

Realizou-se, então, a edição, a exclusão e a listagem de bancos. O mesmo

processo foi realizado com a Categoria e Favorecidos que também tiveram suas

instâncias armazenadas na controladora. As outras classes, Movimentacao e

ContaBancaria se relacionam com as outras já citadas. A implementação seguiu pela

ContaBancaria que tem suas instâncias armazenadas em um objeto de coleção

dentro de um objeto banco, pois um banco, possui uma coleção de contas

48

Bancárias. Do mesmo modo a classe Movimentacao, que se relaciona com

ContaBancaria, Categoria e Favorecido. As classes (enumerations)

TipoContaBancaria e TipoMovimentacao definem um atributo nas classes

Movimentacao e ContaBancaria conforme o padrão associação como atributo.

Após a implementação do esquema de dados do programa, buscou-se

aprimorar a visualização dos dados. Primeiramente criou-se um algoritmo de filtro

capaz de trabalhar com múltiplas condições, retornando à tela somente os objetos

que a satisfazem. Após o filtro concluído, elaborou-se um gerador de relatórios em

PDF, que utiliza os dados em tela e os apresenta no documento PDF,

proporcionando a impressão de relatórios.

Para proporcionar praticidade ao usuário, elaborou-se uma barra de menu

arquivo, este menu possui as opções salvar, que salva a instância da classe

Controladora, que contém todos os objetos do sistema no arquivo aberto; salvar

como que salva a instância classe Controladora em um local definido; abrir que abre

um arquivo selecionado e lê a instância da classe Controladora; recentes que

armazena os últimos cinco arquivos abertos recentemente. E por fim o menu

propriedades que está relacionado à segurança do arquivo.

Para garantir a segurança do arquivo o usuário seleciona a opção de arquivo

com senha e fornece uma senha, que é utilizada para abrir o arquivo. Utilizando o

algoritmo de criptografia AES, o programa criptografa os dados pela senha fornecida

(chave de cifra) que é utilizada para posteriormente abrir o arquivo e descriptografar

os bytes, permitindo transformá-los em objeto novamente.

49

5 RESULTADOS E DISCUSSÕES

Este capítulo tem por objetivo apresentar os resultados obtidos neste

trabalho, apresentando o software gerenciador financeiro GEF, cumprindo com os

requisitos e objetivos definidos no início de sua construção.

5.1 TRANSFORMAÇÃO DO DER EM DIAGRAMA DE CLASSES DA UML

Para atingir o objetivo principal do projeto, a transformação da persistência de

informações em arquivos em vez de banco de dados, realizou-se a transformação

de um diagrama entidade-relacionamento para um diagrama de classes da UML. Na

Ilustração 12, encontra-se o diagrama ER que representa o banco de dados do GEF.

Este foi utilizado como base para transformação em diagrama de classes da UML.

Ilustração 12: Diagrama entidade-relacionamento do GEF


50

O diagrama entidade-relacionamento foi construído no ano de 2014, onde o

software armazenava em banco de dados. No entanto, para construir o sistema

orientado a objetos necessitou-se modelar através do diagrama de classes da UML

a comunicação das classes do sistema.

Na Ilustração 13, observa-se que o diagrama de classes do projeto possui as

cinco classes, Favorecido, Categoria, Banco, Movimentacao e ContaBancaria que

estão presentes no diagrama ER como entidades. A criação das classes e

associações permitirá que os objetos sejam instanciados e posteriormente unidos

através das associações, proporcionando cadastros, edições e exclusões.

Além das cinco classes e a transformação do relacionamento das mesmas

para associações do diagrama de classes da UML, transformou-se para classes, os

Ilustração 13: Diagrama de Classes do GEF


51

dados de tipo de movimentação e tipo de conta bancária, que no diagrama ER eram

atributos das entidades Movimentacao e ContaBancaria. Estas classes foram

projetadas com o esteriótipo enumeration, tornando objetos constantes no sistema.

No caso de Movimentacao a associação criada foi um-para-muitos com

navegabilidade unidirecional no sentido do único objeto TipoMovimentacao.

Desta forma uma movimentação só pode possuir um tipo, e este tipo pode ser

Saque ou Deposito. No caso de ContaBancaria, a associação também é um-para-

muitos com navegabilidade unidirecional no sentido do único objeto

TipoContaBancaria, e o tipo pode ser Poupança, Salario ou Corrente. Com o intuito

de possuir o controle de todos os dados do sistema criou-se a classe Controlador,

com o objeto INSTANCE o único objeto gravado no arquivo.

As associações da classe Controlador possibilitaram que ela armazenasse

todos os objetos do sistema. Sabendo-se que ContaBancaria e Movimentacao são

as classes que mais se associam, portanto seus objetos estão armazenados em

outras classes, definiu-se que Banco, Categoria e Favorecido armazenariam suas

instâncias no Controlador, e, consequentemente, os objetos Banco armazenariam

todos os objetos do sistema.

52

5.2 IMPLEMENTAÇÃO DO DIAGRAMA DE CLASSES UML

Como resultado da implementação na linguagem de programação Java das

classes e suas associações modeladas, observa-se os próximos quadros que

apresentam os resultados da implementação total da classe Movimentacao. A

divisão da classe Movimentacao em diferentes quadros foi realizada por motivo de

espaço e fins de melhor visualização de cada parte da implementação.

O Quadro 17, possui a implementação em Java da modelagem da classe

Movimentacao sem nenhuma associação a ela, isto é, somente constam os atributos

que a caracterizam e os métodos de acesso a esses.

Quadro 17: Atributos e métodos da classe Movimentacao

123456789101112131415161718

public class Movimentacao implements Serializable{// atributos e métodos da modelagem da classeprivate Date data;private double valor;

public Date getData() {return this.data;

} public void setData(Date data) { this.data = data; } public double getValor() { return this.valor; } public void setValor(double valor) { this.valor = valor; }}


O Quadro 18, apresenta a implementação em Java da associação entre a

classe Movimentacao e TipoMovimentacao, que apresentam a multiplicidade um-

para-muitos com navegabilidade no sentido do único objeto TipoMovimentacao,

conforme apresentada no diagrama de classes na Seção 5.1.

53

Quadro 18: Associação da classe Movimentacao com TipoMovimentacao

12345678910

public class Movimentacao implements Serializable{private TipoMovimentacao tipoMovimentacao;public TipoMovimentacao getTipoMovimentacao() {

return this.tipoMovimentacao;}public void setTipoMovimentacao(TipoMovimentacao

tipoMovimentacao) { this.tipoMovimentacao = tipoMovimentacao;

}}


Quadro 19: Associação entre Movimentacao e Categoria

12345678910111213141516171819202122232425262728

public class Movimentacao implements Serializable {private Categoria categoria;void privateSetCategoria(Categoria c)throws

Exception{ if(this.categoria==null){ this.categoria=c; }else{

if(this.categoria!=cat){ throw new Exception(); } }

}void privateunSetCategoria(){

this.categoria = null;}public void setCategoria(Categoria c)throws

Exception{c.addMovimentacao(this);

}public void unSetCategoria(){

if(categoria!=null){ categoria.removeMovimentacao(this); }

}public Categoria getCategoria(){

return this.categoria;}


54

O Quadro 19, apresenta a classe Movimentacao com a implementação da

associação entre a classe Movimentacao e Categoria. Uma associação um-para-

muitos bidirecional, conforme apresentada pelo diagrama de classes na Seção 5.1.

Quadro 20: Associação entre Movimentacao e Favorecido

1234567891011121314151617181920212223242526272829

public class Movimentacao implements Serializable{private Favorecido favorecido;void privateSetFavorecido(Favorecido fav) throws

Exception{if(this.favorecido==null){

this.favorecido=fav; }else{ if(this.favorecido!=fav){ throw new Exception(); } }

}void privateunSetFavorecido(){

this.favorecido=null;}public void setFavorecido(Favorecido fav) throws

Exception { fav.addMovimentacao(this); }

public void unSetFavorecido(){if(favorecido!=null){

favorecido.removeMovimentacao(this); }

}public Favorecido getFavorecido(){

return this.favorecido;}


O Quadro 20, apresenta a classe Movimentacao com a implementação da

associação entre a classe Movimentacao e Favorecido. Uma associação um-para-

muitos biderecional, conforme apresentada pelo diagrama de classes na Seção 5.1.

55

Quadro 21: Classe TipoMovimentacao

12345678910111213

public enum TipoMovimentacao implements Serializable{Saque,Deposito;

public String getString(TipoMovimentacao tmov){

switch(tmov){case Saque:

return "Saque";default:

return "Deposito"; } }}


O Quadro 21, apresenta a implementação da classe TipoMovimentacao, que

possui uma associação com a classe Movimentacao. A classe foi implementada

como um enum da linguagem Java, o qual não permite instanciar estes objetos mais

de uma vez, sendo eles constantes no sistema.

56

5.3 TELAS DO PROGRAMA

Esta seção apresenta as janelas gráficas criadas para atingir os propósitos

deste trabalho ou para melhorar a versão anterior.

Ilustração 14: Exemplo de tela de Cadastro


Ilustração 15: Menu de manipulação de arquivos


57

As telas de Cadastro e Edição do software foram reajustadas, como

exemplificada na Ilustração 14, que contém a tela de Cadastro de Conta Bancária. O

padrão de design foi reajustado adicionando o painel na cor azul na lateral direita

para conter os botões salvar e cancelar, que se tornou o padrão usado em todas as

telas do software, sendo elas de cadastro, edição ou de outras funções.

Para possibilitar que o software manipulasse os arquivos usados na

persistência de informações, necessitou-se criar um menu arquivo – Ilustração 15 –,

que está presente em diversos softwares aplicativos que utilizam arquivos, como o

LibreOficce.

O menu arquivo do GEF conta com as opções de Novo, que cria um novo

arquivo vazio, Abrir Arquivo... que abre o explorador de arquivos (Ilustração 18) para

abrir um arquivo do GEF, opção Salvar que salva as modificações no arquivo aberto,

opção Salvar Como... que abre o gerenciador de arquivos do sistema operacional

(Ilustração 19), e o menu Recentes que traz as opções dos cinco últimos arquivos

abertos no sistema, e com um clique no nome do arquivo o software o abre. E a

opção Propriedades que abre a tela de Propriedades, apresentada na Ilustração 16.

A Ilustração 16, apresenta a tela Propriedades do Arquivo. Esta tela apresenta

ao usuário informações como o nome do arquivo aberto e o seu local de

armazenamento. A tela Propriedades está ligada diretamente a um requisito do

software: a segurança do arquivo. A tela disponibiliza ao usuário a opção de

Ilustração 16: Tela Propriedades do Arquivo


58

Segurança com criptografia, sendo assim o usuário deve definir uma senha de

abertura ao seu arquivo, através do botão Definir Senha que abre uma nova tela

Senha do Arquivo exemplificada na Ilustração 17, onde o usuário digita sua senha e

a confirma salvando e tornando o arquivo protegido por ela.

Ilustração 18: Tela abrir Arquivo


Ilustração 17: Tela Senha do Arquivo


59

Ilustração 19: Tela salvar Arquivo

Ilustração 20: Tela Relatórios de Movimentações



60

Na Ilustração 20, observa-se a tela de Relatório de Movimentações. Essa tela

já existia no GEF, no entanto necessitou-se modificá-la para atender aos requisitos

de filtro de informações em conjunto (Seção 5.4) e apresentação dos dados em PDF

(Seção 5.5). As modificações foram feitas no painel lateral. Inicialmente tinha-se o

botão Buscar, um campo de texto para digitar uma única data, e três caixas de

seleção, uma para Categoria, uma para Favorecido e uma para Conta Bancária.

Todavia, observou-se a possibilidade de melhora, trazendo outra caixa de

texto em que o usuário informa um período, nestas pode-se digitar as duas datas, ou

somente inicial (a partir de) ou final (até a data). As caixas de seleção

permaneceram à Categoria e Favorecido, e a caixa de seleção para Conta Bancária

foi trocada por uma tela interativa de Seleção de Conta Bancária, presente na

Ilustração 21, onde o usuário pode selecionar mais de uma conta para o filtro,

trazendo mais recursos.

Adicionou-se o botão Gerar PDF que abre a tela de configurações do PDF,

exemplificada na Ilustração 22. Botões limpar foram adicionados em cada campo

para ajudar o usuário a cancelar determinado filtro.

Ilustração 21: Tela de Seleção de Conta Bancária


61

Como exemplificada na Ilustração 22, a tela Configuração PDF é responsável

por resgatar do usuário a informação de como ele deseja a disposição dos dados no

layout do PDF. Optou-se por desenvolver três layout's, um agrega movimentações

em uma página só de forma detalhada, o outro separa uma movimentação por

página, e o terceiro dispõe os dados em colunas.

Sendo assim, dependendo da ocasião o usuário pode escolher o que melhor

lhe convém. O botão Próximo abre o gerenciador de arquivos do sistema

operacional para que o usuário escolha o nome do arquivo e o diretório em que

deseja salvar o documento PDF, logo após o sistema gera o relatório em arquivo

PDF das movimentações (Seção 5.6).

Ilustração 22: Tela Configuração PDF


62

5.4 MANIPULAÇÃO DOS OBJETOS

Um dos requisitos do sistema é realizar a manipulação dos objetos, isto é,

instanciá-los (Cadastros), modificar valores dos atributos (Edições), remoção de

objetos (Exclusões), e consultas de determinados objetos listados em tela. Sendo

assim, o usuário manipula os valores dos atributos das classes – Banco,

ContaBancaria, Categoria, Favorecido e Movimentacao –, criando, editando ou

excluindo instâncias das mesmas.

Quadro 22: Implementação do método de cadastro de conta bancária

public boolean cadastraContaBancaria(){ContaBancaria a = new ContaBancaria(); //cria instância//seta valores das caixas de texto aos atributos da contaa.setNomeIdentificador(nomeconta.getText());a.setNumAgencia(Integer.parseInt(numeroagen.getText()));a.setNumConta(conta); //associa ao tipo de containt x = tipodeconta.getSelectedIndex(); //ComboBoxTipoContaBancaria contabancaria = tipoc.get(x);//ArrayLista.setTipoconta(contabancaria);//associa ao bancoint selectedIndex = nomebnc.getSelectedIndex();//ComboBoxBanco bnc = codbancos.get(selectedIndex); //ArrayListtry {

a.setBanco(bnc); //Cria associação de Conta e Banco} catch (Exception ex) {

JoptionPane.showMessageDialog(null, ex); }

return bnc.containsConta(a); //sucesso do cadastro}Fonte: O Autor, 2015.

No Quadro 22, observa-se a criação de um objeto ContaBancaria no

sistema, o código é executado no clique do botão Salvar após os campos da tela de

cadastro estarem devidamente preenchidos pelo usuário.

No Quadro 23, observa-se que para editar uma conta bancária o método

editarContaBancaria recebe os parâmetros de ContaBancaria e Banco que se

deseja editar. Com o objeto de ContaBancaria, o método atualiza os valores dos

atributos da classe, além de atualizar a associação com a classe

63

TipoContaBancaria, atualizando o atributo como associação. Já na classe Banco

encerra a associação nos atributos de ambas as classes e associa a conta bancária

ao banco editado.

Quadro 23: Implementação do método de editar conta bancária

public void editarContaBancaria(ContaBancaria c, Banco banco){//modifica valores dos atributos do objeto ContaBancariac.setNomeIdentificador(nomeContaEd.getText());c.setNumAgencia(Integer.parseInt(numeroAgEd.getText()));c.setNumConta(Integer.parseInt(numeroContaEd.getText()));//modifica o TipoContaBancariaint x = tipodecontaed.getSelectedIndex(); //comboboxTipoContaBancaria tcontabancaria=tipoc.get(x);//ArrayList//Associa a TipoContaBancariac.setTipoconta(tcontabancaria);

//associa a Bancoint selectedIndex=nomebnced.getSelectedIndex();//ComboBoxBanco banc = codbancos.get(selectedIndex); //ArrayListtry {

c.unSetBanco(banco); //cancela a antiga associaçãoc.setBanco(banc); //cria nova associação

} catch (Exception ex) {JOptionPane.showMessageDialog(null, ex);

}}Fonte: O Autor, 2015.

64

No Quadro 24, observa-se a implementação de um método de listagem de

contas bancárias. Este pode ser usado para dispor os dados em uma tabela na

janela.

Quadro 24: Implementação do método de listar contas bancárias

public void listarContas() {if(Controladora.getInstancia()!= null){

try {Set<Banco> bancos; bancos=Controladora.getInstancia().getBancos();// para cada banco for (Banco bs: bancos) {

Set<ContaBancaria> contas =bs.getContas();//para cada conta bancáriafor (ContaBancaria cs: contas) {

//determina banco e saldodouble tt = 0.0; // total (saldo)Banco banco = cs.getBanco();String nome = banco.getNome();

int codigo = banco.getCodigo();String bnc = nome + " - COD: " +

codigo;Set<Movimentacao> movimentacao;movimentacao = cs.getMovimentacao();//para cada movimentacaofor (Movimentacao m : movimentacao) {//soma-se para determinar o saldo

double x = m.getValor();tt += x;

}//adiciona-se ao JTable os registros de nome, bnc e tt da //Conta(trecho oculto) } }

} catch (Exception ex) {JoptionPane.showMessageDialog(null, ex);

}}Fonte: O Autor, 2015.

65

No Quadro 25, observa-se a implementação do método para excluir uma

ContaBancaria recebendo a mesma como parâmetro e retornando um valor boolean.

Quadro 25: Implementação do método de excluir conta bancária

public boolean excluirContaBancaria (ContaBancaria cb) {Banco banco = cb.getBanco();//identifica o banco da conta//remove a conta do bancoboolean x = banco.removeConta(cb); //exclui as movimentações da contacb.limparMovimentacoes(); listarContas(); //Método descrito no Quadro 06return x;}

}


5.5 FILTRO DE DADOS

Para a funcionalidade de melhor apresentação dos dados ao usuário,

realizou-se a adaptação do filtro de movimentações, de modo que nessa versão o

usuário pode buscar movimentações combinando múltiplas condições de filtragem.

Tal modo melhora a experiência do usuário, pois se ele deseja, por exemplo,

visualizar movimentações de determinada conta bancária em um determinado

período, o software disponibiliza a função. Pode-se usar as quatro restrições

simultaneamente, os quais são categoria, favorecido, período e conta bancária.

Para isso, se desenvolveu um mecanismo que não se comunica com o banco

de dados e sim realiza a pesquisa dentro de uma coleção de objetos. O algoritmo foi

implementado com uma lógica de exclusão de objetos, isto é, os objetos que não

atendem às restrições não são apresentados em tela.

No Quadro 26, tem-se o algoritmo de filtro de dados do Gerenciador

Financeiro. Este algoritmo utiliza uma lista de objetos da classe Movimentacao,

citada na Seção 5.2. Sua execução ocorre ao clicar-se no botão buscar da Tela

Relatório de Movimentações (Ilustração 20).

66

Quadro 26: Algoritmo de filtro de dados da classe Movimentacao

123456789101112131415161718192021222324252627

Set<Banco> banco= Controladora.getInstancia().getBancos();for (Banco b : banco) {

Set<ContaBancaria> contas = b.getContas();nextRow:for (ContaBancaria cb : contas) {

mov = cb.getMovimentacao();for (Movimentacao m : mov) {

if (isAnteriorDataIni(m)) {continue;

}if (isPosteriorDataFim(m)) {

continue;}if (isCategoriaDiferente(m)) {

continue;}if (isFavorecidoDiferente(m)){

continue;}if (contselec.size() > 0) {

if (contselec.contains(cb) == false) {continue nextRow;

}}

}}

}


O Quadro 26, apresenta o algoritmo utiliza os métodos descritos nos Quadros

27 e 28. O Algoritmo busca todos os bancos cadastrados na Controladora (linha 1).

Para cada banco, o algoritmo percorre suas contas bancárias (linha 5) e para cada

conta bancária o algoritmo percorre suas movimentações (linha 7). Em cada

movimentação, testa-se se a movimentação tem sua data anterior (linha 8) à data

inicial indicada na caixa de texto da janela (Quadro 27).

Caso verdadeiro, o sistema recorre a próxima movimentação através do

comando continue. O mesmo ocorre ao verificar se a movimentação tem sua data

posterior (linha 11) à data final indicada na caixa de texto da janela (Quadro 27). Na

linha 14, o algoritmo verifica se a categoria da movimentação é diferente da

categoria selecionada na caixa de seleção da janela. Na linha 17, o sistema verifica

se o favorecido da movimentação é diferente do favorecido selecionado na caixa de

seleção da janela. Nestas linhas, caso a instrução de decisão retorne verdadeiro, o

67

sistema cancela a filtragem e passa para o próximo objeto do laço de repetição. Nas

linhas 20 à 23, o sistema verifica se a conta bancária da movimentação está

selecionada, através do método contains (Contém) do ArrayList de contas bancárias

selecionadas contselec.

Quadro 27: Métodos que verificam o período da movimentação

1234567891011121314151617181920212223242526272829303132333435

private boolean isAnteriorDataIni(Movimentacao m) {if (!CTDataInicial.getText().equals(" / / ")) {

SimpleDateFormat format; format = new SimpleDateFormat("dd/MM/yyyy");String dataini = CTDataInicial.getText();java.util.Date datainic = null;try {

datainic = format.parse(dataini);} catch (ParseException ex) {

JOptionPane.showMessageDialog(null, "Formato de Data errado");

}int compareTo = m.getData().compareTo(datainic);return compareTo < 0;

}return false;

}

private boolean isPosteriorDataFim(Movimentacao m) {if (!CTDataFinal.getText().equals(" / / ")) {

SimpleDateFormat format; format = new SimpleDateFormat("dd/MM/yyyy");java.util.Date datafim = null;String datafimn = CTDataFinal.getText();try {

datafim = format.parse(datafimn);} catch (ParseException ex) {

JOptionPane.showMessageDialog(null, "Formato de Data Errado");

}int compareTo = m.getData().compareTo(datafim);return compareTo > 0;

}return false;


No Quadro 27, o método isAnteriorDataIni verifica se a data da movimentação

é anterior à data na caixa de texto. Desta forma, a partir da linha 2, se a caixa de

68

texto está preenchida, o método transforma os dados em um objeto Date e compara

as datas através do método compareTo (linha 13) que retorna o número um negativo

se a data da movimentação é anterior à da caixa de texto.

O método isPosteriorDataFim verifica se a data da movimentação é posterior

a data na caixa de texto. Desta forma, a partir da linha 20, se a caixa de texto está

preenchida o método transforma os dados em um objeto Date e compara as datas

através do método compareTo (linha 31) que retorna o número um positivo se a data

da movimentação é posterior a data da caixa de texto.

Quadro 28: Métodos que verificam a Categoria e Favorecido da Movimentacao

1234567891011121314151617

private boolean isCategoriaDiferente(Movimentacao m) {if (CBCategoria.getSelectedIndex() > 0) {

int x = CBCategoria.getSelectedIndex();Categoria c = cats.get(x – 1);return m.getCategoria() != c;

}return false;

}

private boolean isFavorecidoDiferente(Movimentacao m) {if (CBFavorecido.getSelectedIndex() > 0) {

int x = CBFavorecido.getSelectedIndex(); Favorecido f = favs.get(x - 1);

return m.getFavorecido() != f; } return false;}


No Quadro 28, os métodos isCategoriaDiferente e isFavorecidoDiferente

verificam, respectivamente, se a categoria e o favorecido da movimentação são

diferentes dos selecionados nas caixas de seleção. O índice zero da caixa de

seleção contém opção de não selecionar nenhuma categoria, desta forma,

resgatando-se o índice selecionado (linha 2 e 11), busca-se o objeto de um ArrayList,

e campara-se ao objeto pertencente a movimentação (linha 5 e 14).

69

5.6 RELATÓRIOS EM PDF

A Ilustração 23, apresenta o layout do PDF gerado pelo Gerenciador

Financeiro, na qual as movimentações são apresentadas em uma página de forma

detalhada.

Ilustração 23: PDF layout detalhado


70

A Ilustração 24, apresenta o layout do PDF na qual a disposição dos dados é

em forma de colunas, gerado pelo Gerenciador Financeiro. Ainda, desenvolveu-se

outro layout na qual cada movimentação ocupa uma página inteira do arquivo PDF.

5.7 SEGURANÇA DOS ARQUIVOS

Como resultado da segurança dos arquivos, esta seção apresenta os

métodos adotados pelo sistema para proteger o arquivo. Os princípios da

criptografia foram usados, tendo como algoritmo computacional o AES. Os Métodos

em Java utilizando a classe Cipher da linguagem para realizar a crifragem e

decifragem dos bytes, estão exemplificados na classe CriptografiaAES, presente na

Ilustração 25.

Ilustração 24: PDF layout em colunas


71

Na Ilustração 25, a classe CriptografiaAES funciona como disponibilizadora

da criptografia no sistema, através do método encypt utilizado para criptografar os

bytes ou do método decrypt utilizado para descriptografar os bytes.

Para realizar o processo de salvar os dados o sistema realiza alguns passos.

Precisa-se chamar o método encrypt (linha 7) quando a opção de com criptografia,

presente na Tela de Propriedades do Arquivo (Ilustração X) está marcada. Desta

forma, quando o usuário salvar o arquivo, o sistema se encarrega de serializar o

objeto Controlador, e em vez de gravá-lo no arquivo, o sistema busca a senha

definida pelo usuário, conta os bytes da senha e então acrescenta no início da

senha os bytes faltantes para totalizar uma chave de 16 bytes de tamanho. Realiza

então o processo de criptografia utilizando o método encrypt, utilizando os bytes

serializados e a chave criptográfica de 16 bytes. Logo após, os dados cifrados são

gravados no arquivo.

Quando o usuário abre um arquivo o sistema também realiza uma rotina de

passos. O software tenta abri-lo desserializando e transformando os bytes em objeto

Controlador. Caso ocorra uma exceção, possivelmente causada pelo fato de os

bytes estarem criptografados, o sistema pede a senha ao usuário (Ilustração 26). A

senha então é transformada em chave criptográfica e o sistema tenta realizar a

descriptografia dos dados utilizando o método decrypt. Caso realizada com sucesso,

o sistema transforma os bytes em objeto Controlador (desserialização). Caso ocorra

Ilustração 25: Classe CriptografiaAES


72

erro, o sistema pede a senha novamente ao usuário, alertando-o de erro de senha,

se a exceção ocorrer mais de uma vez, o sistema pede a senha novamente mas

também alerta sobre a possibilidade de os dados estarem corrompidos.

Ilustração 26: Senha para abrir o arquivo


73

5.8 DISCUSSÃO

O Quadro 29, apresenta os comparativos quanto ao gerenciador

financeiro GEF em sua versão base – utilizando banco de dados – e o GEF

persistindo em arquivos.

Quadro 29: Comparativo da forma de persistir dados

Característica Banco de Dados Arquivos

Segurança

Possui por padrão: Integridade,

Confidencialidade eDisponibilidade dos dados às

pessoas autorizadas.

Pode-se implementar acriptografia dos dados,sendo assim o sistema

possui Integridade,Confidencialidade eDisponibilidade dosdados a usuários

autorizados.

Transporte dos Dados

Deve-se fazer um backup dobanco de dados e importá-losno outro dispositivo. Processo

complexo que exigeconhecimento aprofundado dousuário e/ou ferramentas que

realizem o processo de backupe recuperação.

Deve-se transportar osarquivos através dequalquer unidade dearmazenamento, em

nuvem ou físico.Processo simples.

Instalação de SoftwaresSecundários

Necessidade de instalação doSistema Gerenciador de Banco

de Dados (SGBD).

Não há necessidade deum softwaresecundário.

Acesso simultâneo aosdados

Permite que múltiplos usuáriosacessem os dados sem haverinconsistência. SGBD realiza a

gerência de acesso.

Permite abrir o mesmoarquivo em duas

execuções. No entanto,ao salvar os dados em

uma execução, nãoatualiza os dados em

outra execução.

Acesso aos dados emRede

Permite arquitetura cliente-servidor. Acesso do

cliente aos dadosarmazenados em um servidor.

Não permite arquiteturacliente-servidor.

Persistência somenteem máquina local, no

entanto, pode-se enviaro arquivo pela rede eser aberto em outra

máquina.


74

6 CONSIDERAÇÕES FINAIS

A persistência em arquivos é um meio de armazenar informações de forma

mais simples, sem necessitar de softwares secundários, proporcionando ao usuário

uma melhor experiência ao manipular suas informações. O uso de arquivos em um

software de uso pessoal é mais viável do que utilizar banco de dados, pois, arquivos

são práticos, leves e muito utilizados em um sistema operacional.

Este trabalho migrou a forma de armazenar dados em um software orientado

a objetos de banco de dados para arquivos. Sendo assim, é possível construir a

arquitetura de um software utilizando a orientação a objetos da linguagem Java,

como também é possível transformar a persistência de banco de dados para

arquivos.

O uso de arquivos não cria uma dependência de um software secundário. O

problema do acesso simultâneo aos dados pode ser resolvido criando-se

mecanismos de sincronização dos dados em diferentes execuções, isto é, abrindo o

arquivo periodicamente durante a execução, ou salvando os dados no mesmo.

Quanto à questão de segurança, arquivos podem ser protegidos por senha ou

com restrições de acesso. Além disso, a migração apresenta pequenas mudanças

na interface gráfica do software, por exemplo, a inserção do menu para manipulação

dos arquivos.

A possibilidade de novos estudos, além da sala de aula, foi fundamental, pois,

além de pôr em prática o estudo de banco de dados durante o curso técnico em

informática, pôde-se desenvolver novas habilidades focadas em outra forma de

armazenar informações: a persistência em arquivos. No desenvolvimento de

software é importante saber usar os recursos da linguagem de programação para

construir a aplicação da forma mais viável, e com o desenvolvimento desta pesquisa

pôde-se adquirir conhecimentos extras sobre a linguagem de programação Java.

Migrar um software é uma tarefa em que se deve conhecer as duas

tecnologias, desta forma, deve-se realizar o estudo do projeto base, entendê-lo

quanto a sua implementação, e então pensar na melhor forma de projetar o software

para que esse persista em arquivos, processo um pouco demorado e que exige do

desenvolvedor conhecimento específicos.

75

O GEF, em sua versão persistindo em arquivos encontra-se disponível para

download no endereço: <www.gef-gerenciador-financeiro.sourceforge.net>. O

Apêndice B, apresenta o artigo completo referente ao mesmo tema deste trabalho,

que foi submetido e apresentado ao 4º Simpósio de Integração Científica e

Tecnológica do Sul Catarinense (4º SICT Sul) em Novembro de 2015.

Como trabalhos futuros, sugere-se a implementação de recursos da

estatística e da matemática financeira, bem como a geração de gráficos para melhor

visualização de informações pertinentes a partir dos dados. Quanto ao Design das

telas, o GEF abre os cadastros e edições em janelas separadas. Então, sugere-se

que esse apresente todas funções em painéis a serem apresentados dentro da

janela principal do programa.

http://www.gef-gerenciador-financeiro.sourceforge.net/

76

REFERÊNCIAS

ASCENCIO, Ana Fernanda Gomes; CAMPOS, Edilene Aparecida Veneruchi de. Fundamentos da programação de computadores: algoritmos, Pascal, C/C++ e Java . 2. ed. São Paulo: Pearson Prentice Hall, 2007.

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. rev. e atual. Rio de Janeiro: Elsevier, Campus, 2007.

CARDOSO, Iuri Sônego. Inserindo suporte a declaração de associações da UML2 em uma linguagem de programação orientada a objetos. 2011. 361 f. Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico. Programa de Pós-Graduação em Ciência da Computação. Florianópolis, 2011.

DEITEL, Harvey M.; DEITEL, Paul. Java como programar. 8. ed. São Paulo: Pearson Prentice Hall, 2010.

FREITAS JUNIOR, Vanderlei et al. A pesquisa científica e tecnológica:.Espacios, Caracas, v. 35, n. 9, p.12-12, jul. 2014. Disponível em:<http://www.revistaespacios.com/a14v35n09/14350913.html#pesquisa>. Acesso em: 14 ago. 2015.

GIL, Antônio Carlos. Como elaborar projetos de pesquisa. 5. ed. São Paulo: Atlas,2010.

GUERRA, Glaucio. Introdução a serialização de objetos. Disponível em:<http://www.devmedia.com.br/introducao-a-serializacao-de-objetos/3050>. Acesso em: 14 mai. 2015.

HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.

KUROSE, James F.; ROSS, Keith W. Redes de computadores e a internet: uma abordagem top-down. 5. ed. São Paulo: Pearson Addison Wesley, 2010.

MANZANO, José Augusto N. G; OLIVEIRA, Jayr Figueiredo de. Algoritmos: lógica para desenvolvimento de programação de computadores . 26. ed. rev. São Paulo: Érica, 2012.

MORAES, Alexandre Fernandes de. Redes de computadores: fundamentos. 7. ed. São Paulo, SP: Érica, 2010.

NOBLE, James. Basic Relationship Patterns. In: EUROPEAN CONFERENCE ON PATTERN LANGUAGES OF PROGRAMMING (EUROPLOP), 2., 1997, Irsee. Proceedings… Munich: Siemens AG, 1997.

ORACLE. Class ByteArrayIntputStream. Disponível em:<https://docs.oracle.com/Javase/7/docs/api/Java/io/ByteArrayInputStream.html>. Acesso em: 14 mai. 2015.

ORACLE. Class ByteArrayOutputStream. Disponível em:<https://docs.oracle.com/Javase/7/docs/api/Java/io/ByteArrayOutputStream.html>. Acesso em: 14 mai. 2015.

77

ORACLE. Class ObjectInputStream. Disponível em:<http://docs.oracle.com/Javase/7/docs/api/Java/io/ObjectOutputStream.html>. Acesso em: 14 mai. 2015.

ORACLE. Class ObjectInputStream. Disponível em:<https://docs.oracle.com/Javase/7/docs/api/Java/io/ObjectInputStream.html>. Acesso em: 14 mai. 2015.

ORACLE. Interface Serializable. Disponível em: <http://docs.oracle.com/Javase/7/docs/api/Java/io/Serializable.html>. Acesso em: 19 mai. 2015.

PEREIRA, Raquel Ferreira. GEF: Gerenciador Financeiro. Orientador: Iuri Sônego Cardoso. Trabalho de Conclusão de Curso, Curso Técnico em Informática Integrado ao Ensino Médio, IF Catarinense – Campus Avançado Sombrio, 2014.

SANTOS, Rafael. Introdução à programação orientada a objetos usando Java. 2. ed. Rio de Janeiro: Elsevier: Campus, 2013.

78

APÊNDICE A – Cronograma de Atividades.

79

APÊNDICE B – Artigo apresentado ao SICT-Sul.

MIGRAÇÃO DE PERSISTÊNCIA EM BANCO DE DADOS PARA ARQUIVOS:CODIFICAÇÃO EM UMA LINGUAGEM ORIENTADA A OBJETOS

Leonardo Daros Santos1, Iuri Sônego Cardoso2

1Instituto Federal Catarinense – Campus Avançado Sombrio / Discente / [email protected] Federal de Santa Catarina – Campus Criciúma / Docente / [email protected]

Resumo: No âmbito do desenvolvimento de software, o armazenamento de dados pode ser realizado dediferentes formas, tais como arquivos e banco de dados. Realizar a transformação de um aplicativo de usopessoal que armazena dados em banco de dados para que passe a armazenar em arquivos é indicado paraque o usuário tenha recursos como a mobilidade dos dados. O objetivo deste trabalho é demonstrar comorealizar esta migração em softwares orientados a objetos, utilizando como exemplo o gerenciador financeirode nome GEF. A revisão da literatura explora os temas da modelagem entidade-relacionamento,modelagem de classes e a implementação de associações em uma linguagem orientada a objetos, paraque se possa exemplificar a metodologia adotada no processo. Através do estudo do projeto do softwareoriginal pode-se migrá-lo para persistir dados em arquivos, projetando a estrutura de classes e associaçõesde forma que a implementação destas em uma linguagem de programação permita que os dados sejammanipulados em forma de objetos e posteriormente transformados em bytes através da serialização deobjetos. Assim, os dados podem ser gravados em um arquivo de forma segura por meio de criptografia. Amigração acarreta leves mudanças na interface do software e o uso de arquivos apresenta vantagens comoa mobilidade dos dados e a possibilidade de uso de múltiplos arquivos. Palavras-Chave: Desenvolvimento de Software. Orientação a Objetos. UML. Persistência em arquivos.1 INTRODUÇÃO

No âmbito do desenvolvimento de software, o armazenamento de dados pode

ser realizado de diferentes formas, tais como arquivos e banco de dados. Estas podem

apresentar vantagens e desvantagens quanto a características como praticidade e

segurança. Sendo assim, deve-se pensar na melhor forma do armazenamento dos dados

quando se projeta o software, pois, analisando o contexto que o software se aplica, uma

das formas de armazenar se torna mais trivial ao usuário e ideal às circunstancias da

natureza do software. Por exemplo, sistemas de médio e grande porte empregados em

empresas necessitam utilizar banco de dados, porque este permite acesso simultâneo de

vários usuários aos dados em uma rede de computadores, entre outros motivos. Por outro

lado, aplicativos de uso pessoal como editores de texto, planilhas eletrônicas, entre

outros, utilizam a persistência (armazenamento) em arquivos por não necessitar de uma

estrutura mais complexa instalada, como um sistema gerenciador de banco de dados.

Realizar a transformação de um aplicativo de uso pessoal que armazena dados

em banco de dados para que passe a armazenar em arquivos é indicado para que o

usuário tenha recursos como a mobilidade dos dados, por exemplo. Neste contexto, o

objetivo deste trabalho é demonstrar como realizar a migração da maneira de persistir

dados em banco de dados para persistência em arquivos, em softwares orientados a

objetos. Neste trabalho, utilizou-se o gerenciador financeiro de nome GEF como base

para demonstrar a migração do armazenamento de dados para arquivos. Este é um

80

aplicativo pessoal, de código aberto2, codificado em uma linguagem orientada a objetos, e

que armazena dados em banco de dados.

O presente trabalho está organizado da seguinte forma: a metodologia é

apresentada na Seção 2 e da Seção 3 à Seção 7 são apresentados, junto a revisão

bibliográfica, os passos para migração de persistência em banco de dados para arquivos.

Por fim, os resultados, discussões e considerações finais são apresentados nas Seções 8

e 9.

2 METODOLOGIA

Para demonstrar a migração da forma de armazenamento de dados em um

software alvo, de banco de dados para arquivos, este trabalho apresenta um diagrama

Entidade-Relacionamento (ER) para demonstrar as estruturas de banco de dados

utilizadas originalmente pelo software alvo (HEUSER, 2009); diagrama de classes da

Unified Modeling Language (UML) para demonstrar a estruturação das classes

resultantes do processo de migração e como os dados serão estruturados na memória

para posterior escrita em arquivos (BEZERRA, 2007); e exemplos de código Java para

demonstrar a implementação do diagrama de classes e a consequente manipulação dos

objetos. Utilizou-se o GEF como software alvo para aplicar os procedimentos descritos

neste trabalho.

O processo de migração apresentado neste trabalho inicia pela análise do

projeto existente (detalhada na Seção 3), tendo a finalidade de adquirir conhecimento do

estado do software antes da migração, ou seja, como ele está implementado e como o

seu banco de dados está estruturado. Esta análise é realizada com base na

documentação do software e na documentação do banco de dados, sendo esta última

estruturada em um diagrama ER.

Com o conhecimento do diagrama ER do banco de dados, é então realizada a

transformação para o diagrama de classes da UML, conforme detalhado na Seção 4,

mapeando entidades em classes, relacionamentos em atributos, entre outras

transformações. Esta etapa tem por objetivo ter um modelo de dados mais próximo das

linguagens orientadas a objetos, facilitando o próximo passo.

Obtendo-se o diagrama de classes, implementa-se as classes e as

associações entre as classes, permitindo a comunicação dos objetos no sistema. Isto é

feito utilizando uma linguagem orientada a objetos (linguagem Java) conforme

apresentado na Seção 5.

2 Tradução de opensource: licença de utilização do código fonte disponível de forma livre, gratuitamente.

81

Assim como no uso de banco de dados para armazenar dados, os softwares

que armazenam dados em arquivos necessitam manipular dados (consulta, inserção,

edição e exclusão de dados). A Seção 6 exemplifica como tais manipulações são feitas

através da orientação a objetos da linguagem Java.

Os objetos Java são endereçados na memória RAM (Random Access

Memory), por consequência, existem somente em tempo de execução do software. Para

armazenar dados de forma que eles não se percam ao encerrar a execução, deve-se

armazenar os objetos Java em arquivos, permitindo posterior recuperação. Os detalhes

da implementação dos processos de armazenamento e recuperação de dados estão

detalhados na Seção 7.

3 PROJETO E IMPLEMENTAÇÃO EXISTENTE

O gerenciador financeiro GEF é um software de código fonte aberto; persiste

os dados em banco de dados relacional; utiliza a linguagem SQL (Structured Query

Language) para manipulação de dados em um sistema gerenciador de banco de dados

MySQL Server3 (DATE, 2004). O software tem como funcionalidade realizar a gerência de

contas bancárias e suas movimentações; portanto, armazena dados de bancos, contas

bancárias de um banco, movimentações de uma conta bancária, o tipo de movimentação,

o tipo de conta bancária, a categoria de uma movimentação e o seu favorecido. O

diagrama ER do projeto do banco de dados deste software está presente na Figura 01.

Segundo Heuser (2009, p. 35), uma entidade representa “conjuntos de objetos

da realidade modelada sobre os quais deseja-se manter informações no banco de dados.”

No diagrama ER, são representadas pelos retângulos, como se pode observar na Figura

01, que possui as entidades Conta, Banco, Movimentação, Favorecidos e Categoria.

Heuser (2009) afirma ainda, que os atributos são as propriedades que caracterizam uma

entidade. Cada entidade deve possuir um ou mais atributos identificadores, ou seja, que

possuem valores únicos para cada ocorrência de objeto na entidade ou relacionamento.

Como por exemplo na entidade Categoria que possui um código como atributo

identificador e nome como atributo. Segundo Heuser (2009), entidades podem se

relacionar quando ocorrências de objetos de entidades diferentes ou não, possuírem

semelhanças ou se segregarem entre si, e também quando um depender das atividades

do outro. Tem-se o exemplo da entidade Conta e Banco, pois um depende do outro,

sendo que uma conta tem um banco e um banco tem várias contas. Neste contexto,

Heuser (2009) define que os relacionamentos possuem cardinalidade que determinam o

3 Disponível em: https://www.mysql.com/.

https://www.mysql.com/

82

número mínimo e máximo de ocorrências do relacionamento. A cardinalidade pode ser de

nenhuma (0), uma (1), ou muitas ocorrências (n), formando um par ordenado onde o

primeiro valor corresponde ao mínimo e o segundo ao máximo.

Fonte: Pereira, 2014.

4 TRANSFORMAÇÃO DO DIAGRAMA ER EM DIAGRAMA DE CLASSES UML

Segundo Santos (2013), as classes são meios de representar modelos, isto é,

objetos, pessoas e itens da realidade para o meio computacional. Assim como as

entidades, as classes possuem atributos que caracterizam seus objetos (instâncias), além

de métodos que são ações para desempenhar determinada função ou manipular os

atributos. Bezerra (2007), explica que em um diagrama de classes da UML, as classes

são retângulos que possuem nome com letra maiúscula e também atributos com a

primeira palavra iniciando com letra minúscula e as demais iniciando com letra maiúscula.

Segundo Bezerra (2007), para representar o fato de que classes podem se

associar existe a associação no diagrama de classes. A associação entre classes define

multiplicidade – valor mínimo e máximo de ocorrências de um objeto na associação –,

navegabilidade, sendo ela unidirecional ou bidirecional – condição de se um objeto

conhece o outro o qual se associa –, além de nomes de papel de cada classe na

associação. Embora no diagrama de classes a associação seja representada entre

Figura 01 – Diagrama entidade-relacionamento do GEF

83

classes, no sistema são executadas por objetos que são capazes de trocar informações

para realizar determinada tarefa do sistema. (BEZERRA, 2007)

Fonte: Os Autores, 2015.

Na Figura 02, observa-se que o diagrama de classes do projeto possui as cinco

classes, Favorecido, Categoria, Banco, Movimentacao e ContaBancaria que estão

presentes no diagrama ER como entidades. A criação das classes e associações permitiu

que os objetos fossem instanciados e posteriormente unidos através das associações,

proporcionando cadastros, edições e exclusões. Além das cinco classes e a

transformação do relacionamento das mesmas para associações do diagrama de classes

da UML, transformou-se para classes, os dados de tipo de movimentação e tipo de conta

bancária, que no diagrama ER eram atributos das entidades Movimentacao e

ContaBancaria.

Figura 02 – Diagrama de classes do GEF

84

Com o intuito de possuir o controle de todos os dados do sistema criou-se uma

classe Arquivo, que armazena todos os dados por meio de associações, sendo assim ao

gravar no arquivo a instância da classe Arquivo, os demais dados são armazenados.

Sabendo-se pois, que para que uma movimentação exista necessita estar

vinculada a uma conta bancária, e para que uma conta bancária exista necessita estar

vinculada a um banco; e que uma movimentação pode possuir categoria e favorecido,

definiu-se que as classes Banco, Categoria e Favorecido armazenariam suas instâncias

na classe Arquivo, e consequentemente, os objetos Banco armazenariam todos os

objetos de ContaBancaria e Movimentacao.

5 IMPLEMENTAÇÃO DO DIAGRAMA DE CLASSES EM CÓDIGO JAVA

A construção do banco de dados é feita após projetá-lo usando a modelagem

entidade-relacionamento. De forma similar, no software orientado a objetos, após

organizar as classes no diagrama de classes da UML, implementa-se estas em uma

linguagem de programação orientada a objetos, como a linguagem Java já utilizada na

codificação do gerenciador financeiro GEF. Cada classe do diagrama é mapeada em uma

classe no código, porém associações não possuem uma estrutura específica, sendo

necessário construí-las.

Segundo Noble (1997), existem 6 padrões comuns de implementação de

associações. Utilizou-se na migração do GEF, três deles: associação como atributo,

objeto de coleção e mutual friends. O padrão associação como atributo é utilizado quando

há uma associação com multiplicidade um-para-um ou um-para-muitos com

navegabilidade unidirecional no sentido do único objeto, sua implementação está descrita

na Figura 03. O padrão objeto de coleção é utilizado quando há uma associação com

multiplicidade um-para-muitos com navegabilidade unidirecional no sentido dos muitos

objetos, sua implementação está descrita na Figura 04. O padrão mutual friends é

utilizado quando há uma associação com navegabilidade bidirecional, cria-se um

mecanismo de sincronização de ambas as classes e pode-se utilizar todas as

multiplicidades, sua implementação está descrita na Figura 05.

Figura 03 – Implementação em Java do padrão associação como atributo

public class TipoMovimentacao {//atributos e métodos

}public class Movimentacao {

private TipoMovimentacao tipoMovimentacao; //associação como atributo//métodos de acesso ao atributo tipoMovimentacaopublic TipoMovimentacao getTipoMovimentacao( ) {

return this.tipoMovimentacao;}

85

public void setTipoMovimentacao(TipoMovimentacao tipoMov) {this.tipoMovimentacao = tipoMov;

}}


Figura 04 – Implementação em Java do padrão objeto de coleção


//atributo Objeto de Coleçãoprivate Set<Movimentacao> movimentacoes;movimentacoes = new HashSet<Movimentacao>();//Métodos de manipuação do atributopublic boolean addMovimentacao(Movimentacao mov) {

return this.movimentacoes.add(mov); }public boolean removeMovimentacao(Movimentacao mov) {

return movimentacoes.remove(mov); }public Set<Movimentacao> getMovimentacoes(){

return this.movimentacoes; }public void limparMovimentacoes() {

for (Movimentacao m : movimentacoes) {m.unSetCategoria();m.unSetFavorecido();

}this.movimentacoes.clear();

}} public class Movimentacao {

//atributos e métodos}


Figura 05 – Implementação em Java do padrão Mutual Friends

import java.util.HashSet;import Java.util.Set;public class ContaBancaria {

//associação como atributoprivate Banco banco;// métodos de implementação da associaçãovoid privateSetBanco(Banco banco) throws Exception{

if(this.banco==null) { this.banco=banco;

}else if (this.banco!=banco){ throw new Exception();

} }void privateUnSetBanco( ) {

this.banco=null;}public void setBanco(Banco banco) throws Exception {

banco.addConta(this); }public void unSetBanco(Banco banco){

banco.removeConta(this);}public Banco getBanco( ){

86

return this.banco; }

public class Banco {// objeto de coleçãoprivate Set<ContaBancaria> contasBancarias; contasBancarias = new HashSet<ContaBancaria>( );//métodos de implementação da associaçãopublic void addConta(ContaBancaria ContaBancaria) {

ContaBancaria.privateSetBanco(this);this.contasBancarias.add(ContaBancaria);

}public void removeConta(ContaBancaria ContaBancaria){

ContaBancaria.privateUnSetBanco();this.contasBancarias.remove(ContaBancaria);

}public Set<ContaBancaria> getContas( ) {

return this.contasBancarias; }

}

Fonte: Os Autores, 2015.Figura 06 – Implementação em Java da classe Arquivo

public class Arquivo implements Serializable {private static Arquivo Instance = new Arquivo();//instância a ser gravada//objetos de coleçãoprivate final HashSet<Banco> BANCOS = new HashSet<>(); private final HashSet<Favorecido> FAVS = new HashSet<>();private final HashSet<Categoria> CATEGORIAS = new HashSet<>();public static void setIntancia(Arquivo c) {

Instance = c;}public static Arquivo getInstancia() {

return Instance; }

public void addBanco(Banco e) { //manipulação de bancosBANCOS.add(e);

}public boolean removeBanco(Banco n) {

return this.BANCOS.remove(n); }

public Set<Banco> getBancos() {return this.BANCOS;

}//outros métodos de Favorecido e Categoria (trecho oculto)

}


Na Figura 06, observa-se a implementação da classe Arquivo, esta possui

associação um-para-muitos com navegabilidade no sentido dos muitos objetos com a

classe Banco, Categoria e Favorecido, implementou-se o padrão de codificação de

associações objeto de coleção (classe HashSet).

6 MANIPULAÇÃO DE OBJETOS JAVA

Após a migração, o software deve manter as funcionalidades originais. Sendo

assim, um dos requisitos do sistema é realizar a manipulação dos dados, isto é, instanciar

objetos (Inclusões), modificar valores dos atributos (Edições), remoção de objetos

(Exclusões), e consultas de determinados objetos listados em tela. O usuário é quem

87

manipula os valores dos atributos das classes – Banco, ContaBancaria, Categoria,

Favorecido e Movimentacao –, criando, editando ou excluindo instâncias das mesmas.

Na Figura 07, observa-se que para cadastrar uma nova conta bancária o

método cadastrarContaBancaria resgata dados preenchidos em campos de Janela

Gráfica – número da conta, número da agência, e nome identificador –, além de associar

a mesma a um Banco e um TipoContaBancaria. As Janelas do software possuem caixas

de seleção ComboBox que quando preenchidas, seus objetos possuem o mesmo índice

em um ArrayList criado, possibilitando resgatar o devido objeto selecionado.

Figura 07 – Implementação do método de cadastro de conta bancária

public boolean cadastrarContaBancaria(){ContaBancaria a = new ContaBancaria(); //cria instância//insere valores aos atributos da ContaBancariaa.setNomeIdentificador(nomeconta.getText()); //Caixa de Textoa.setNumAgencia(Integer.parseInt(numeroagencia.getText()));//Caixa

Textoa.setNumConta(conta); //Caixa de Texto//associa ao tipo de containt x = tipodeconta.getSelectedIndex(); //ComboBoxTipoContaBancaria contabancaria = tipoc.get(x); //ArrayLista.setTipoconta(contabancaria);//associa ao bancoint selectedIndex = nomebanco.getSelectedIndex(); //ComboBoxBanco bnc = codbancos.get(selectedIndex); //ArrayListtry {

a.setBanco(bnc); //Adiciona na Instância de Conta} catch (Exception ex) {

JoptionPane.showMessageDialog(null, ex); }

//Retorna se o cadastro foi ou não realizadoreturn bnc.containsConta(a);

}

Fonte: Os Autores, 2015.Figura 08 – Implementação do método de edição de conta bancária

public void editarContaBancaria(ContaBancaria c, Banco banco){//insere valores de caixas de texto aos atributos do objeto ContaBancariac.setNomeIdentificador(nomeContaEd.getText());c.setNumAgencia(Integer.parseInt(numeroAgEd.getText()));c.setNumConta(Integer.parseInt(numeroContaEd.getText()));//modifica o TipoContaBancariaint x = tipodecontaed.getSelectedIndex(); //ComboBoxTipoContaBancaria tcontabancaria=tipoc.get(x); //ArrayList//Associa a TipoContaBancariac.setTipoconta(tcontabancaria);

//associa a Bancoint selectedIndex=nomebnced.getSelectedIndex();//ComboBoxBanco banc = codbancos.get(selectedIndex); //ArrayListtry {

c.unSetBanco(banco); //remove a antiga associaçãoc.setBanco(banc); //cria nova associação

} catch (Exception ex) {JOptionPane.showMessageDialog(null, ex);

}}


88

Na Figura 08, observa-se que para editar uma conta bancária, o método

editarContaBancaria, responsável por editar uma conta bancária, recebe os parâmetros

de ContaBancaria e Banco que deseja-se editar. Com o objeto de ContaBancaria, o

método atualiza os valores dos atributos da classe e da associação com a classe

TipoContaBancaria, atualizando o atributo como associação. Na classe Banco, remove o

link da associação em ambas classes e associa a conta bancária ao banco selecionado

no ComboBox.

Na Figura 09, observa-se a implementação do método para excluir uma

ContaBancaria recebendo a mesma como parâmetro e retornando um valor boolean,

indicando se a remoção ocorreu ou não com sucesso.

Figura 09 – Implementação do método de excluir conta bancária

public boolean excluirContaBancaria (ContaBancaria cb) {Banco banco = cb.getBanco(); //identifica o banco da conta//remove a conta do bancoboolean x = banco.removeConta(cb); //exclui as movimentações da contacb.limparMovimentacoes(); listarContas(); //Método descrito no Quadro 07return x; //retorna o sucesso da exclusão}

}


Na Figura 10, observa-se a implementação de um método de listagem de

contas bancárias, este pode ser usado para dispor os dados em uma tabela na tela.

Figura 10 – Implementação do método de listagem de contas bancárias

public void listarContas() {if(Arquivo.getInstancia()!= null){

try {Set<Banco> bancos;

bancos =Arquivo.getInstancia().getBancos();// para cada banco for (Banco bs: bancos) {

Set<ContaBancaria> contas = bs.getContas();//para cada conta bancáriafor (ContaBancaria cs: contas) {

//determina banco e saldodouble tt = 0.0; // total (saldo)Banco banco = cs.getBanco();String nome = banco.getNome();

int codigo = banco.getCodigo();String bnc = nome + " - COD: " + codigo;Set<Movimentacao> movimentacao;movimentacao = cs.getMovimentacao();//para cada movimentacaofor (Movimentacao m : movimentacao) {

//soma-se para determinar o saldodouble x = m.getValor();tt += x;

}//adiciona-se ao JTable os registros de nome, bnc e tt da Conta(trecho oculto)

89

} }

} catch (Exception ex) {JoptionPane.showMessageDialog(null, ex);

}}


7 PERSISTÊNCIA DE OBJETOS JAVA EM ARQUIVOS

Segundo Guerra (2015), “Quando dizemos que um objeto é serializado,

estamos afirmando que este objeto será transformado em bytes, e poderá ser

armazenado em disco.” Quando um objeto é desserializado ocorre o processo inverso,

que consiste em ler os bytes e transformá-los em objetos. Para que um objeto seja

serializado, sua classe deve implementar a interface java.io.Serializable da linguagem

Java. Na Figura 11, observa-se o código Java que serializa um objeto, o método

getBytesObject recebe um objeto como parâmetro e retorna um array dos bytes do

determinado objeto.

Figura 11 – Método que realiza a transformação de Objeto em Bytes

public byte[] getBytesObject(Object o)throws IOException{ByteArrayOutputStream baos;baos = new ByteArrayOutputStream();ObjectOutputStream oos=new ObjectOutputStream(baos);oos.writeObject(o);byte[ ] yourBytes = baos.toByteArray();baos.close();oos.close();return yourBytes;

}


Figura 12 – Método que realiza a transformação de Bytes em Objeto

public Object bytesToObject(byte[] byteAsObj) throws IOException, ClassNotFoundException {

ByteArrayInputStream bais; bais = new ByteArrayInputStream(byteAsObj); ObjectInputStream ous; ois = new ObjectInputStream(bais); Object obj = ois.readObject(); ois.close(); bais.close(); return obj;}


Na Figura 12, o método bytesToObject recebe um array de bytes resultante de

uma serialização para que se realize o processo inverso de desserialização, retornando o

objeto Java.

Pode-se realizar a segurança dos dados antes de armazená-los em arquivo.

Para isso, utiliza-se a criptografia de dados como recurso, por meio de um algoritmo

criptográfico e uma chave criptográfica, sendo essa última definida pelo usuário em forma

90

de senha para permitir acesso ao seu arquivo. Tal método é empregado no GEF utilizando

o algoritmo AES (Advanced Encrypt Standard). Deste modo, após os dados serem

serializados, o array de bytes gerado pode ser criptografado com a chave (senha)

fornecida pelo usuário. Posteriormente, esta chave é necessária para o sistema

descriptografar o conteúdo do arquivo, recuperando o conteúdo original (os bytes gerados

pela serialização) para então desserializar a instância do sistema. A implementação deste

método de criptografia não é apresentada neste trabalho por motivos de espaço4.

A linguagem Java disponibiliza recursos para realizar a escrita dos bytes em

arquivos. Na Figura 13, observa-se a implementação de um método que recebe os bytes

e o local no disco para então persistir as informações no arquivo. A Figura 14, apresenta a

leitura de um arquivo com o local no disco especificado como parâmetro, abrindo-o e

retornando os bytes escritos nele.

Figura 13 – Implementação do método de gravação no arquivo

public void gravar(String local, byte[] b) throws Exception {FileOutputStream outFile;outFile= new FileOutputStream(local);ByteArrayOutputStream bout;bout = new ByteArrayOutputStream();bout.write(b);bout.writeTo(outFile);outFile.close();bout.close();bout.flush();

} Fonte: Os Autores, 2015.

Figura 14 – Implementação do método de leitura de dados do arquivo

public byte[] abrir(File f) throws Exception {int lenght = (int) f.length();byte[] bytes = new byte[lenght];FileInputStream inFile = new FileInputStream(f);inFile.read(bytes, 0, lenght);inFile.close();return bytes;

}


No GEF, criou-se uma barra de menu denominada arquivo, para adicionar

funções de abrir um arquivo no sistema de arquivos, bem como salvar as modificações no

arquivo aberto ou salvar como em um local específico no sistema de arquivos.

8 RESULTADOS E DISCUSSÕES

A migração na forma de persistir dados no gerenciador financeiro GEF

apresentou melhorias de praticidade no deslocamento de dados, pois o usuário pode

abrir, salvar, e proteger seus dados em forma de arquivos. Apresenta a possibilidade de4 Implementação similar é apresentada no endereço http://www.devmedia.com.br/utilizando-criptografia-

simetrica-em-java/31170. Acesso em: 10 de outubro de 2015.

http://www.devmedia.com.br/utilizando-criptografia-simetrica-em-java/31170

http://www.devmedia.com.br/utilizando-criptografia-simetrica-em-java/31170

91

uso de múltiplos arquivos com dados diferentes ao usuário, diferentemente de banco de

dados onde se possui somente um conjunto, fato que proporciona maior facilidade na

organização e no transporte dos dados. Do mesmo modo, não acarreta mudanças na

interface do software, exceto pela inserção de um menu de arquivos para adicionar

funções de manipulação dos arquivos no software.

A linguagem SQL proporciona recursos de filtragem de dados em suas

consultas. Já utilizando a linguagem Java, o programador deve implementar estes

recursos. Desta forma, deve-se conhecer a tecnologia de implementação utilizando banco

de dados para que se entenda e se chegue a uma solução equivalente utilizando a

linguagem de programação.

O presente trabalho resultou em uma migração de um software existente,

todavia, pode-se realizar a construção de um novo software que armazenará em arquivos,

levantando requisitos, projetando as classes, implementando as mesmas, e

desempenhando outras funções não relacionadas a persistência. O software GEF, em sua

versão com persistência em arquivos encontra-se disponível para download no link:

<http://gef-gerenciador-financeiro.sourceforge.net/>.

A Figura 15, apresenta os comparativos quanto ao gerenciador financeiro GEF

em sua versão base – utilizando banco de dados – e o GEF persistindo em arquivos.

Figura 15 – Comparativo da forma de persistir dados

Característica Banco de Dados Arquivos

Segurança

Possui por padrão: Integridade,

Confidencialidade e Disponibilidade dosdados às pessoas autorizadas.

Pode-se implementar a criptografiados dados, sendo assim o sistema

possui Integridade,Confidencialidade e

Disponibilidade dos dados ausuários autorizados.

Transporte dos Dados

Deve-se fazer um backup do banco dedados e importá-los no outro dispositivo.

Processo complexo que exigeconhecimento aprofundado do usuário

e/ou ferramentas que realizem o processode backup e recuperação.

Deve-se transportar os arquivosatravés de qualquer unidade dearmazenamento, em nuvem ou

físico. Processo simples.

Instalação de SoftwaresSecundários

Necessidade de instalação do SistemaGerenciador de Banco de Dados (SGBD).

Não há necessidade de umsoftware secundário.

Acesso simultâneo aos dadosPermite que múltiplos usuários acessem

os dados sem haver inconsistência.SGBD realiza a gerência de acesso.

Permite abrir o mesmo arquivo emduas execuções. No entanto, ao

salvar os dados em uma execução,não atualiza os dados em outra

execução.

Acesso aos dados em Rede

Permite arquitetura cliente-servidor. Acesso do cliente aosdados armazenados em um servidor.

Não permite arquitetura cliente-servidor. Persistência somente emmáquina local, no entanto, pode-se

enviar o arquivo pela rede e seraberto em outra máquina.


http://gef-gerenciador-financeiro.sourceforge.net/

92

9 CONSIDERAÇÕES FINAIS

Este trabalho demonstrou como migrar a forma de armazenar dados em

softwares orientados a objetos, de banco de dados para arquivos. É possível construir a

arquitetura de um software utilizando a orientação a objetos da linguagem Java e persistir

os objetos em arquivos, como também é possível transformar a persistência de banco de

dados para arquivos. O uso de arquivos em um software de uso pessoal é o mais viável

do que utilizar banco de dados, pois, arquivos são práticos, leves e muito utilizados em

um sistema operacional. O uso deste não cria uma dependência de um software

secundário. O problema do acesso simultâneo aos dados pode ser resolvido criando-se

mecanismos de sincronização dos dados em diferentes execuções, isto é, abrindo o

arquivo periodicamente durante a execução, bem como salvando os dados no mesmo.

Quanto a segurança dos dados, os arquivos podem ser protegidos com senha de acesso.

REFERÊNCIAS

BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. 2. ed. rev. e atual. Rio de Janeiro: Elsevier, Campus, 2007.

DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro: Elsevier,2004.

GUERRA, Glaucio. Introdução a serialização de objetos. Disponível em: <http://www.devmedia.com.br/introducao-a-serializacao-de-objetos/3050>. Acesso em: 14 mai. 2015.

HEUSER, Carlos Alberto. Projeto de banco de dados. 6. ed. Porto Alegre: Bookman, 2009.

NOBLE, James. Basic Relationship Patterns. In: EUROPEAN CONFERENCE ON PATTERN LANGUAGES OF PROGRAMMING (EUROPLOP), 2., 1997, Irsee. Proceedings… Munich: Siemens AG, 1997. Disponível em: <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.9273>. Acesso em: 12 mai.2015.

PEREIRA, Raquel Ferreira. GEF: Gerenciador Financeiro. Orientador: Iuri Sônego Cardoso. Trabalho de Conclusão de Curso, Curso Técnico em Informática Integrado ao Ensino Médio, IF Catarinense – Campus Avançado Sombrio, 2014. Disponível em: <https://profiuricardoso.wordpress.com/orientacoe s>. Acesso em: 20 jan. 2015.

SANTOS, Rafael. Introdução à programação orientada a objetos usando Java. 2. ed. Rio de Janeiro: Elsevier: Campus, 2013.

https://profiuricardoso.wordpress.com/orientacoes

https://profiuricardoso.wordpress.com/orientacoes

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.9273

http://www.devmedia.com.br/introducao-a-serializacao-de-objetos/3050

Documents

Ministério da Educação Secretaria de Educação Profissional ... · programação de computadores, modelo conceitual, mapeamento de associações, serialização de objetos Java,