Você está na página 1de 66

FACULDADE SUL BRASIL - FASUL CURSO DE SISTEMAS DE INFORMAÇÃO

DESENVOLVIMENTO DE FERRAMENTA RAD PARA SISTEMAS DE BANCO DE DADOS

CESAR AUGUSTO HUNOFF

TOLEDO PR

2010

INFORMAÇÃO DESENVOLVIMENTO DE FERRAMENTA RAD PARA SISTEMAS DE BANCO DE DADOS CESAR AUGUSTO HUNOFF TOLEDO –

CESAR AUGUSTO HUNOFF

DESENVOLVIMENTO DE FERRAMENTA RAD PARA SISTEMAS DE BANCO DE DADOS

Trabalho de Conclusão de Curso, apresentado ao Curso de Sistemas de Informação, Faculdade Sul Brasil FASUL, como requisito parcial para a obtenção do grau de Bacharel em Sistemas de Informação.

Orientador: Rui Rossi dos Santos

TOLEDO PR

2010

ii
ii

TERMO DE APROVAÇÃO

CESAR AUGUSTO HUNOFF

DESENVOLVIMENTO DE FERRAMENTA RAD PARA SISTEMAS DE BANCO DE DADOS

Trabalho de Conclusão de Curso, aprovado como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação no Curso de Sistemas de Informação da Faculdade Sul Brasil, pela seguinte banca examinadora:

Orientador:

Prof. Rui Rossi dos Santos Colegiado de Sistemas de Informação, FASUL

Prof. Jéfer Benedett Dörr Colegiado de Sistemas de Informação, FASUL

Prof. Simone Regina Silva Colegiado de Sistemas de Informação, FASUL

Toledo, 19 de novembro de 2010.

ii

DEDICATÓRIA

iii
iii

Dedico este trabalho a todos os colegas que passaram em minha vida que de uma maneira ou outra contribuíram para esta caminhada e, especialmente, àqueles que fizeram de sua vida uma luta para chegar até aqui.

iv
iv

AGRADECIMENTOS

Primeiramente, aos meus pais, Rude Hunoff e Marli Hunoff que mesmo com todas as dificuldades foram meus primeiros professores, ensinaram-me o caminho da sabedoria, essencial para mais esta caminhada e conquista na minha vida.

De forma especial a minha noiva, Keila Martins, que esteve sempre presente nos momentos de dificuldade e comemorou comigo os momentos de alegria.

A minhas irmãs Camila e Ladislaine e seu esposo Marcelo por fazer parte da minha caminhada até aqui.

De forma especial a minha tia, professora Clasi Maria Schio pela correção deste trabalho.

Ao orientador, Rui Rossi dos Santos, que estivera sempre disposto a auxiliar-me e contribuir para o desenvolvimento de um estudo de resultados.

Ao MS. Juliano Lamb por ter me incentivado a dar continuidade à ideia que gerou o tema deste trabalho.

iv

v
v

Também a todos os professores e à coordenadora Simone Regina da Silva, que ministraram alguma disciplina ao longo do curso, desempenhando exemplarmente seu papel de mediador no processo de ensino/aprendizagem.

v

vi
vi

Não tento dançar melhor do que ninguém. Tento apenas dançar melhor do que eu mesmo.

Mikhail Baryshnikov

SUMÁRIO

vii
vii

LISTA DE FIGURAS

IX

LISTA DE QUADROS

X

LISTA

DE

SIGLAS

XI

RESUMO

XII

INTRODUÇÃO

1

1 SISTEMAS DE BANCO DE DADOS

2

1.1 OBJETIVOS DE UM SISTEMA DE BANCO DE DADOS

2

1.2 TÉCNICAS DE SISTEMA DE BANCO DE DADOS

3

 

1.2.1 DML

3

 

1.2.2 Estrutura do sistema de banco de dados

4

2 MODELOS DE DESENVOLVIMENTO

6

2.1 MODELOS TRADICIONAIS

6

2.2 MODELO RAD

7

3 MATERIAIS E MÉTODOS

11

3.1

TECNOLOGIAS

11

3.2.1 Tecnologia Java

12

3.1.2 Banco de dados Firebird

13

3.2.3 Extensible Markup Language

14

3.3

FERRAMENTAS

14

3.3.1 Ambiente de desenvolvimento

15

3.3.2 Plataforma de desenvolvimento de relatórios

15

vii

viii
viii

4

CONSTRUÇÃO DE UMA FERRAMENTA RAD

17

4.1 BANCO DE DADOS

18

4.2 ESTRUTURA DA FERRAMENTA RAD

22

4.3 PACOTE

UTIL

23

4.4 PACOTE

RELATORIO

25

4.5 PACOTE SDB

26

4.6 PACOTE

SDI

27

4.7 PACOTE

COMPILADOR

29

4.8 PACOTE

ARTICOS

33

5 OPERAÇÃO DA FERRAMENTA RAD DESENVOVIDA

33

5.1 ACESSANDO O SOFTWARE

34

5.2 MÓDULO

SDI

37

5.3 MÓDULO SDB

43

5.4 MÓDULO

RELATÓRIO

46

6

ANÁLISE DOS RESULTADOS

48

CONCLUSÃO

51

REFERÊNCIAS BIBLIOGRÁFICAS

53

viii

LISTA DE FIGURAS

ix
ix

Figura 1 - Ciclo RAD x Ciclo Tradicional

Figura 8

Front-end

8

Figura 2 - Diagrama de entidades e relacionamentos

19

Figura 3 - Diagrama de pacotes

22

Figura 4 - Mapeamento objeto-relacional

24

Figura 5 - Fluxo de compilação

32

Figura 6 - Tela seleção proprietária

35

Figura 7 - Tela de autenticação

35

-

36

37

Figura 9 - Sistema de Desenvolvimento de Interfaces Figura 10 - Gerenciador de menus

38

- Figura 12 - Barras de componentes

Figura 11

Gerenciador

de

persistência

39

40

Figura 13 - Editor de regras

42

Figura 14 - Tela de mensagens

43

Figura 15 - Sistema de Desenvolvimento de Banco de Dados

44

Figura 16 - Manipulação de tabelas

45

Figura 17 - Cadastro de relatório

46

Figura 18 - Tela de parâmetros

47

Figura 19 - Execução dos relatórios

48

ix

x
x

LISTA DE QUADROS

QUADRO 1 - Código fonte da view tabela

21

QUADRO 2 - Arquivo licença

23

QUADRO 3 - Arquivo de XML

28

QUADRO 4 - Método de compilação

30

QUADRO 5 - Método de execução

31

QUADRO 6 - Comandos de execução

34

x

LISTA DE SIGLAS

xi
xi

API

-

Aplications Programming Interface

BD

-

Banco de Dados

CPF

-

Cadastro de Pessoas Físicas

DAO

-

Data Access Object

DCL

-

Data Control Language

DDL

-

Data Definition Language

DER

-

Diagrama Entidade Relacionamento

DML

-

Data Manipulation Language

IDE

-

Integrated Development Environment

IP

-

Internet Protocol

IPL

-

InterBase Public License

JDBC

-

Java Database Connectivity

JDK

-

Java Development Kit

JEE

-

Java Enterprise Edition

JME

-

Java Micro Edition

JSE

-

Java Standard Edition

JVM

-

Java Virtual Machine

MDI

-

Multiple Document Interface

RAD

-

Rapid Application Development

SDB

-

Sistema de Desenvolvimento de Banco de Dados

SDI

-

Sistema de Desenvolvimento de interfaces

SGBD

-

Sistema Gerenciador de Banco de Dados

SQL

-

Structured Query Language

UML

-

Unified Modeling Language

XML

-

Extensible Markup Language

XMS

-

Extended Memory Specification

XMX

-

Extended Memory Maximum

xi

RESUMO

xii
xii

O desenvolvimento de sistemas com persistência em banco de dados relacional, em ambientes corporativos, sempre acarreta grande complexidade e longo tempo de implementação. O objetivo deste trabalho é demonstrar a utilização do modelo de desenvolvimento RAD, unido à tecnologia Java para a criação e desenvolvimento de uma ferramenta que facilite esta tarefa. Possuindo recursos como interface de desenvolvimento visual de formulários, geradores automáticos de código e uma interface facilitada de manipulação do banco de dados, além de uma vasta biblioteca de métodos que facilitam e auxiliam a criação de regras de negócio e fornecem ao usuário a possibilidade de efetuar o desenvolvimento de uma solução não necessitando de vasto conhecimento em programação de computadores para fazê-lo.

xii

INTRODUÇÃO

O principal problema no ambiente de desenvolvimento de sistemas com banco de

dados sempre foi o tempo gasto com programação e a complexidade na sua criação. Se

estender esta realidade para o ambiente corporativo, pode-se acrescentar o custo alto em licenças e mão-de-obra especializada.

A engenharia de software surgiu para tentar suprir esta necessidade com técnicas

de ciclo de desenvolvimento de aplicações, conhecidas como metodologias tradicionais. Porém, estes não cumprem seu papel por possuir um método que não atende o quadro atual do mercado, seguindo regras rígidas e inflexíveis que não conseguem acompanhar as constantes mudanças nas necessidades dos usuários. Com o passar do tempo, este quadro foi agravando-se e foram criadas novas metodologias de desenvolvimento como RAD (Rapid Application Development) ou desenvolvimento rápido de aplicações. Esta metodologia visa suprir com sucesso alguns destes problemas como tempo de desenvolvimento e custo em especialistas em programação de computadores. Além da metodologia de desenvolvimento é fundamental utilizar uma tecnologia que atenda seus requisitos. O Java cumpre muito bem este papel pelo seu dinamismo e flexibilidade, além de estar em constante evolução. Unindo estes dois recursos, a metodologia

de desenvolvimento e a tecnologia de programação, foi criada uma ferramenta de desenvolvimento que oferece um ambiente completo de criação de sistemas voltados à ambientes desktop. Esta ferramenta possui um ambiente robusto e ágil de desenvolvimento visual e totalmente facilitado. O objetivo deste trabalho é demonstrar como todos esses recursos foram integrados para desenvolver esta ferramenta e como ela pode ser utilizada.

1

SISTEMAS DE BANCO DE DADOS

Uma das principais razões de utilizar um sistema de banco de dados é ter um controle total e centralizado por somente uma aplicação e prover aos usuários um ambiente, que facilite manipular as informações armazenadas. Segundo DATE (1990, p. 3), “O sistema de banco de dados é basicamente um sistema de manutenção de registros por computador ou seja, um sistema cujo objetivo global é manter as informações e torná-las disponíveis quando solicitadas.”. Considerando que os bancos de dados são projetados para gerir uma grande gama de informações, então, torna-se indispensável o uso de um sistema para seu gerenciamento que implique na definição das estruturas de armazenamento e manipulação dos dados e garanta a segurança e a consistência da informação, através de um grande conjunto de técnicas e conceitos para administração dos dados.

1.1 Objetivos de um sistema de banco de dados

O sistema de banco de dados é um software que permite o gerenciamento das informações, contidas através de regras que precisam ser pré-determinadas e implementadas por programadores de computador, cuja meta básica é proporcionar um ambiente facilitado e seguro para os usuários que farão uso dele, além de fornece-lhe uma visão abstrata dos dados, escondendo algumas informações como as que garantem a sua consistência. O banco de dados muda, ao longo do tempo, conforme a necessidade de sua utilização. O software deve estar preparado para atender ás funções que serão incorporadas conforme ás necessidades que irão surgindo, ou seja, o sistema deve ser flexível de maneira que consiga acompanhar de forma rápida o ambiente externo. Para que o sistema seja eficiente, precisa atender as necessidades de recuperação das informações que implica diretamente na forma com que foi desenvolvido. Para garantir essa eficiência, é necessário respeitar os seguintes níveis de abstração sendo o nível físico e lógico.

Nível físico que é o mais baixo de abstração e descreve como esses dados estão sendo armazenados.

3

Nível lógico é o intermediário que define basicamente quais dados e de que maneira serão armazenados, e de visão que descreve a parte do banco de dados, ou seja, é a visão de acesso que o usuário terá disponível das informações.

1.2 Técnicas de Sistema de banco de dados

Os sistemas de banco de dados possuem técnicas para a manipulação e gerenciamento da informação e é de responsabilidades do programador definir a arquitetura e

o modo apropriado de estruturar o software. Para seguir a premissa de uma metodologia ágil de desenvolvimento do sistema de banco de dados, foi adotado a DML (Linguagem de Manipulação de Dados) para manipulação da informação e uma arquitetura que possibilite um desenvolvimento ágil da persistência, interface e regras de negócio com o BD (Banco de Dados).

1.2.1 DML

A manipulação do software com o banco de dados é feita através de chamadas de

DML que é um grupo de comandos dentro da linguagem SQL (Structured Query Language) ou linguagem de consulta estruturada.

A linguagem SQL pode ser dividida em três sub-linguagens o DDL, DML e DCL:

o DDL (Data Definition Language) que efetuam a definição das variáveis, as DML (Data

Manipulation Language) que efetuam a manipulação de dados com comandos específicos e as

DCL (Data Control Language) que estabelecem o controle de acessos às bases de dados e à sua manipulação.

O DML é um grupo de comandos de programação de computador, utilizado para

permitir o acesso facilitado aos dados, proporcionar uma interação eficiente entre homens e

máquinas através de comandos para recuperação, inserção, remoção e modificação das informações, contidas no BD. Existem dois tipos de DML os procedurais e os não procedurais. As procedurais que exigem que usuários informem quais dados são necessários e como obtê-los, e as não procedurais que exigem que os mesmos especifiquem os dados necessários sem a necessidade de informar como obtê-los.

3
3

4

Os principais comandos necessários para efetuar as operações da DML são SELECT, INSERT, UPDATE, DELETE: o SELECT (Seleção de Dados), responsável por recuperar as informações, INSERT (Inserção de Dados), responsável por inserir novas informações, UPDATE (Atualização de Dados), responsável por alterar informações existentes e DELETE (Exclusão de Dados), responsável por apagar definitivamente as informações do BD. Com o uso da DML é feito o controle de transação. Segundo SILBERSCHATZ (1990, p. 13), Uma transação é uma coleção de operações que desempenham uma função lógica única dentro de uma aplicação”. É ela que garante a consistência da informação manipulada, ou seja, ela controla a transferência dos dados entre a aplicação e o BD. Ela é confirmada caso não ocorra falhas e pode ser abortada caso haja inconsistência ou qualquer evento fora do planejado.

1.2.2 Estrutura do sistema de banco de dados

Na arquitetura clássica, os sistemas de BD utilizam três camadas separadas de manipulação dos dados, seguindo o princípio de uma camada para persistência, outra para regras de negócio e, por último, a interface do usuário. A camada de persistência de dados é responsável por consistir e gravar

fisicamente a informação no BD. Por exemplo: quando o usuário efetua uma entrada de dados por uma tela de cadastros, estes ficam em memória até que seja persistida fisicamente no banco, tornando-se uma informação não volátil, podendo ser recuperada posteriormente.

A camada de regras de negócio define a política de tratamento da informação

antes que sejam persistidas, suas particularidades e funcionamento em cada situação. É ele que define, basicamente, os objetivos da aplicação.

A interface com o usuário é responsável pela interação da máquina com o homem.

Normalmente, os usuários julgam a qualidade do software pela sua interface, avaliando sua acessibilidade e o que nela foi disponibilizado.

O aplicativo, desenvolvido, utiliza somente uma camada de tratamento dos dados,

que contém a persistência, regras de negócio e interface com usuário que são feitos no mesmo

nível de abstração. A principal vantagem desta técnica é facilitar a manutenção e

4
4

5

acessibilidade ao código com a centralização dos componentes de cada camada, consequentemente, um ganho muito alto em tempo de desenvolvimento e custo.

5
5

2

MODELOS DE DESENVOLVIMENTO

Este capítulo tem como objetivo explanar o modelo RAD, utilizado no desenvolvimento deste trabalho, demonstrando a sua aplicação na padronização e desenvolvimento de ferramentas que auxiliam os programadores a superar as dificuldades apresentadas, mostrando seu conceito e utilização em comparação ao outros modelos de desenvolvimento difundidos no mercado.

2.1 Modelos tradicionais

Com o crescimento contínuo das tecnologias de programação, no fim da década de sessenta e inicio da de setenta, as empresas de desenvolvimento de sistemas passaram a enfrentar grandes dificuldades para cumprir prazos e mostrar resultados dentro do orçamento planejado ao atender a demanda que o mercado exigia em criação de softwares. Este quadro foi identificado e conhecido como a “Crise do Software”. Segundo PRESSMAN (1995, p. 22), “quer o chamemos de crise de software ou aflição de software, o termo alude a um conjunto de problemas que são encontrados no desenvolvimento de software de computador. Os problemas não se limitam a software que não funciona adequadamente. Ao contrário, a aflição abrange problemas associados a como desenvolvemos o software, como mantemos um volume crescente de software existente e como podemos esperar acompanhar a crescente demanda por mais softwares.”. Esta situação impactava, diretamente, no estilo e metodologia que as equipes de desenvolvimento utilizavam, pois já não estava satisfazendo a necessidade da época e levantava a dúvida de como iriam conseguir atender o crescimento contínuo no desenvolvimento de softwares e os deixar preparados para a futura demanda. Com este cenário, que predominava, começou a surgir à necessidade de criar e desenvolver métodos, padronizados e documentados para superar este fato, dando inicio ao conceito de “Engenharia de Software“ que abriu novos horizontes na área de pesquisa e literaturas.

Com estas pesquisas, tornou-se possível a padronização da metodologia de desenvolvimento e surgiram modelos de engenharia como o RAD (Rapid Application Development), Desenvolvimento Rápido de Aplicação, programação estruturada, orientação a objetos entre outros.

7

Apesar de todo o avanço e padronização na área de engenharia, as empresas especializadas em desenvolvimento de sistemas continuam a luta contra a crise, sofrendo com atrasos de projetos, estouro de orçamentos e produtos finais defeituosos que acarretam alto custo e manutenção, algumas vezes antes mesmo de serem concluídos. Na década de setenta, em plena ascensão da crise do software, foi criado um ciclo de vida clássico para o desenvolvimento de sistemas estruturados, conhecidos e utilizados até hoje, como “modelo em cascata” que aborda um rígido passo a passo para a criação de um software, exigindo que cada etapa seja finalizada para dar continuidade a próxima. Para PRESSMAN (1995, p. 32), O paradigma do ciclo de vida requer uma abordagem sistemática, sequencial ao desenvolvimento do software, que se inicia no nível do sistema e avança ao longo da análise, projeto, codificação, testes e manutenção.”. Em resposta a este ciclo tradicional com regras sequenciais rígidas, no início da década de oitenta, James Martin, embasado no ciclo de vida, conhecido como “Modelo Espiral” o qual defende um modelo de prototipagem evolutiva na qual o protótipo do sistema é gerado e refinando até o produto final. PRESSMAN (1995, p. 38), “O modelo espiral para a engenharia de software foi desenvolvido para abranger as melhores características tanto do ciclo de vida clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento a análise dos riscos que falta a esses paradigmas.”.

2.2 Modelo RAD

Martin evolui e documentou este método que passou a ser conhecido como RAD, que visa comprimir o passo a passo do ciclo tradicional em um processo interativo, buscando aperfeiçoar e desenvolver os modelos de dados e processos em protótipos. Estes são testados pelos usuários. Identificados os novos requisitos, dão início ao ciclo novamente até que chegam ao fim. A Figura 1 demonstra um comparativo entre o ciclo de vida RAD e o tradicional. É possível verificar que é gerado um protótipo para efetuar testes e, se detectados, alguma necessidade de alteração, volta-se à fase de análise do requisito. Este processo pode ser dividido em várias equipes de desenvolvimento enquanto o tradicional segue uma linha contínua e, caso sejam necessárias alterações, serão feitas já com o software pronto.

7
7

8

Figura 1 - Ciclo RAD x Ciclo Tradicional

8 Figura 1 - Ciclo RAD x Ciclo Tradicional Martin baseia seu modelo em quatro pilares

Martin baseia seu modelo em quatro pilares essenciais sendo eles: metodologia,

pessoas, gerenciamento e ferramentas. Este conceito somente foi efetivado como um modelo de desenvolvimento, no ano 1991, com a publicação do seu livro “Rapid Application Development” no qual ele o documenta todo seu modelo.

O primeiro pilar, metodologia, tem o desafio de prover meios que desenvolvam

sistemas de maneira rápida e cada vez melhores, com custos reduzidos. Para superar este desafio, o modelo RAD combina as melhores técnicas disponíveis e especifica a melhor maneira de aplicá-las, utilizando protótipos que evoluem até o produto final e efetua reuniões para levantamento de requisitos.

O ponto mais importante do modelo incentiva à participação efetiva do usuário em

todo o processo de desenvolvimento do sistema e, assim assegura que os requisitos, levantados, sejam contemplados corretamente. Para facilitar este processo, são utilizados os protótipos evolutivos. Todo o modelo de ciclo de vida do RAD é projetado para que os programadores desenvolvam sistemas que contemplem, realmente, a necessidade dos usuários. Para que isto

8
8

9

seja possível, a metodologia escora-se em quatro pontos fundamentais que resumem todas as tarefas necessárias para a concepção de um sistema.

Primeiro, o planejamento de necessidades: nesta fase, basicamente, define-se o escopo do sistema, ou seja, as funções de negócio que o software irá atender, segundo, o modelo de usuário: nesta fase, constrói-se um protótipo com as funções críticas do sistema para validações; terceiro, a construção: nesta fase, constrói-se o plano de implementação e conclui-se a definição do sistema; quarto, implementação: nesta fase, ocorre o término do sistema, bem como os testes com os usuários e a conversão dos dados para a aplicação final.

O segundo pilar são as pessoas. O uso de excelentes ferramentas é importante no

processo de desenvolvimento, porém não garante o sucesso do projeto. Todo o modelo depende da participação e habilidades das pessoas, envolvidas. Para que a metodologia cumpra seu papel de desenvolvimento rápido de software, é essencial que estas pessoas estejam constantemente motivadas, treinadas e envolvidas no projeto, já que o modelo permite que os usuários assumam papéis diferentes durante as fases. Na fase de construção do software, é essencial o acompanhamento ativo do usuário que deve estar preparado a intervir no desenvolvimento, sempre que perceber que o foco está sendo desviado, assim, garantindo, a velocidade e autonomia na implementação.

O terceiro pilar a gestão. Ele tem o objetivo do modelo de um desenvolvimento

rápido, que só é possível se os usuários estiverem devidamente envolvidos ou se surgirem problemas de gerenciamento do projeto como mudanças de hábitos e culturais. Os gestores devem estar preparados para lidar com este quadro, além de ter um profundo conhecimento nos conceitos do modelo RAD assim, poderão, estar constantemente motivando os usuários e mostrando as vantagens da metodologia como velocidade, produtividade, entre outros. Os gerentes devem estar promovendo treinamentos na ferramenta que é a melhor maneira de colocar os usuários no novo ambiente de trabalho e, assim, mostrando-lhes as técnicas de desenvolvimento rápido. Quarto pilar ferramentas RAD: as ferramentas usam a combinação de técnicas informatizadas e humanas para alcançar o objetivo de velocidade no desenvolvimento, que se resume na a principal meta da realização deste projeto de pesquisa que é a organização e seus usuários com o uso das ferramentas, porque os mesmos irão construir sua aplicação de forma que atenda seus objetivos.

9
9

10

As ferramentas que implementam o modelo RAD utilizam técnicas de geração de código automático, automação na construção de algoritmos e interfaces que facilitem, de maneira efetiva, a posterior manutenção. Esta abordagem gera uma grande vantagem ao diminuir os erros de codificação e implantação, diminuindo, de forma expressiva, a necessidade de manutenção e, consequentemente, o custo. As técnicas RAD estão difundias nas ferramentas, conhecidas no mercado proprietário, já há bastante tempo, como no Microsoft Visual Basic e Borland Delphi. Nestes dois exemplos, pode-se perceber a abordagem do modelo de desenvolvimento com seus recursos de geração de código automatizado e sua interface de desenvolvimento visual de telas.

A ferramenta desenvolvida aborda o conceito do modelo RAD, principalmente por ele possuir um modelo de criação voltado aos usuários finais e suas características de utilizar ferramentas de desenvolvimento visuais, sem obrigar que o programador necessite de grande conhecimento de programação para utiliza-la.

10
10

3

MATERIAIS E MÉTODOS

Neste capítulo, mostra-se os materiais e métodos, utilizados, para efetuar o desenvolvimento desta pesquisa.

O desenvolvimento desta ferramenta foi realizado em duas partes, sendo elas: a

contextualização do tema e a criação da ferramenta, porém foi executada em paralelo. Os testes da ferramenta foram feitos em uma empresa cujo ramo de atividade é a comercialização de madeiras.

Para a contextualização, inicialmente, foram efetuadas pesquisas bibliográficas em

livros, artigos e entrevistas com profissionais especializados, mas, por não ser o tema muito difundido, o estudo foi focado mais na experiência dos entrevistados e na experiência de desenvolvimento do próprio autor deste estudo. Munido deste levantamento teórico com o conceito do modelo RAD foi desenvolvido uma ferramenta para desenvolvimento de soluções em software com banco de dados. Para efetuar a implementação da ferramenta, foram focadas a utilização de tecnologias e ferramentas livres, que são bem difundidas para poder obter suporte facilitado.

O desenvolvimento da ferramenta iniciou com um levantamento bibliográfico

preliminar para traçar a linha de estudo e poder limitar a área a ser aborda. Após essa etapa, foi feito um amplo levantamento de material em livros, artigos, buscando estudos já efetuados, assim, fornecendo embasamento para efetuar o projeto e criar uma análise crítica sobre o assunto. Como há poucas bibliografias específicas sobre o assunto, nesse estudo, também foram utilizadas entrevistas informais com profissionais na área para complementar o material levantado, e dar uma visão prática para a pesquisa.

3.1

Tecnologias

O objetivo deste tópico é apresentar uma abordagem contextual sobre tecnologias

utilizadas no desenvolvimento da ferramenta, que é a segunda parte da pesquisa. O foco busca tecnologias, ambientes de desenvolvimento e ferramentas livres para não agregar custo ao estudo.

12

3.2.1 Tecnologia Java

Segundo SANTOS (2004, p. 8), A tecnologia Java é simples, orientada a objetos, robusta, segura, compilada, interpretada independente da plataforma, portável, com tipagem forte e que oferece suporte a programação concorrente e de sistemas distribuídos. Por este motivo, escolheu-se Java como a tecnologia para a implementação desta ferramenta, além da facilidade de construção de códigos dinâmicos em tempo de execução que é a chave da ferramenta desenvolvida neste projeto.

Por ser portável em múltiplas plataformas, ele executa a aplicação em uma máquina virtual, chamada JVM (Java Virtual Machine), que, em síntese, é um ambiente independente do sistema operacional, mas hospedado nele, permitindo a execução das aplicações Java em múltiplos ambientes sem adaptação do código. Para esta pesquisa, é importante destacar a utilização do JDK (Java Development Kit), que, em síntese, é o aplicativo incluso no Java, responsável por possuir as bibliotecas que complementam o código, desenvolvido pelo programador e efetuar sua compilação para a posterior interpretação da JVM. Esta compilação é feita através de uma biblioteca chamada tools.jarque será abordada a fundo no próximo capitulo.

A tecnologia Java divide-se em três grandes grupos, sendo cada um especialista

em atender ambientes distintos. São eles: JSE (Java Standard Edition), JME (Java Micro Edition) e JEE (Java Enterprise Edition). Java Standard Edition (JSE), é a tecnologia Java, voltada ao desenvolvimento para computadores pessoais e utiliza uma arquitetura que exige mais o uso de memória e processamento do equipamento. Pode-se dizer que é a plataforma principal do Java por dar suporte direto ao JDK. Por este motivo, é a ramificação da tecnologia que foi utilizado, para a implementação deste projeto.

Java Micro Edition (JME), é a tecnologia Java, voltada para dispositivos com plataforma móvel para celulares e exibe a necessidades de menos memória e capacidade de processamento dos equipamentos.

E, por ultimo, o Java Enterprise Edition (JEE), que é a tecnologia Java, voltada

para aplicação em rede e possui recursos especializados para implementação de acesso remoto, transferências, em fim, tudo que envolve a utilização em rede.

12
12

13

O Java foi empregado para o desenvolvimento desta ferramenta, por possuir características que facilitem a manipulação dinâmica de classes e recursos como a compilação de código fonte. Além de ser uma linguagem bem difundida e de fácil aprendizado, se adequando perfeitamente com os objetivos da ferramenta.

3.1.2 Banco de dados Firebird

Para MACHADO (2004, p. 30) os “Bancos de dados podem ser definidos como um conjunto de registro dispostos em estrutura regulares devidamente relacionado que possibilita a reorganização dos mesmos e produção de informação. Um banco de dados é usualmente acessado por meio de um software conhecido como Sistema Gerenciador de Banco de Dados (SGBD). Normalmente um SGBD adota um modelo de dados, de forma pura, reduzida ou estendida. Muitas vezes o termo banco de dados é usado como sinônimo de SGDB“.

O Firebird é um sistema de manutenção e gerenciamento do banco de dados. Seu

desenvolvimento foi baseado no InterBase que abriu o seu código em meados de julho do ano 2000, quando alguns programadores, em forma de associação, assumiram seu

desenvolvimento. Segundo a FIREBIRD (2010), o banco de dados Firebird é poderoso e leve ao

mesmo tempo, com mínima necessidade de configuração e administração. Atende igualmente bem a aplicações de um único usuário e a aplicações corporativas. Um simples servidor Firebird pode manipular múltiplas bases de dados independentes, cada uma com múltiplas conexões clientes. E o melhor de tudo: é verdadeiramente Open Source, assim, livre de qualquer exigência de licenças, mesmo para uso comercial..

O banco é licenciado pela IPL (InterBase Public License), que certifica que podem

ser atribuídas e comercializadas as aplicações de terceiros sem custos, e a tecnologia está aberta a receber qualquer modificação feita por um usuário. Outro ponto importante do Firebird é que exige pouco consumo de memória e capacidade de processamento do equipamento no qual está hospedado. Ele dá suporte a múltiplas plataformas com versão específica para cada uma delas. Como ferramenta, implementada na pesquisa, visa à criação de sistemas de banco de dados, ele foi utilizado, principalmente, pelo suporte facilitado de sua tecnologia, sua

13
13

14

portabilidade e por gerar um arquivo único para repositório dos dados que pode ser facilmente manipulado pela aplicação em tempo de execução.

3.2.3 Extensible Markup Language

A XML é uma tecnologia que se encontra em constante ascensão, sendo utilizada em diversas aplicações por sua flexibilidade e facilidade de utilização, embora seu real campo de atuação seja para uso em ambiente WEB, formando um perfeito casamento com essa tecnologia.

Segundo GRAVES (2003, p. 2), “É uma linguagem usada para representar dados como uma string de texto que inclui uma marcação intercalada a fim de escrever as propriedades dos dados. O uso da marcação permite que o texto seja intercalado por informações relacionadas a seu conteúdo.. Para FILHO (2004, p. 9), “A XML é uma linguagem extensível, mas que há menos tempo caracteriza-se por sua simplicidade quando comparada a outros formatos”. Sua estrutura é composta de elementos e subelementos, separados por marcações, denominadas de tags, que fornecem um meio de inserir os dados sobre a estrutura do documento, formando uma espécie de banco de dados. É uma tecnologia projetada para comunicar um conteúdo em uma representação flexível e ampliável. Portanto, os dados, armazenados, podem ser constantemente revisados e alterados. Para este trabalho, a linguagem XML foi utilizada para armazenar a estrutura das telas criadas pelo software em arquivos. Estes documentos são expressos através de estruturas de uma árvore, sendo compostos por parâmetros de tela e, em seguida, seus componentes.

3.3

Ferramentas

As Ferramentas descritas abaixo referem-se às utilizadas no desenvolvimento da ferramenta desenvolvida. Todas são Open Source para não agregar custo à criação, e são atuais com seu projeto de implementação e atualização em funcionamento.

14
14

15

3.3.1 Ambiente de desenvolvimento

Para SANTOS (2004, p. 2) “O ambiente de desenvolvimento é um conjunto de

ferramentas utilizadas para a construção de aplicativos.”. Este ambiente possui um conjunto

de ferramentas, bibliotecas, compilador e interpretador da tecnologia por ela suportada.

Para a implementação da ferramenta, foi escolhido o Netbeans por ser uma IDE

(Integrated Development Environment) ou ambiente integrado de desenvolvimento que

oferece suporte a toda a tecnologia Java que permite que seja desenvolvida, usando recursos

visuais, seguindo o modelo RAD.

O Netbeans começou como um projeto, em 1996, por estudantes na República

Checa. Teve seu primeiro lançamento como IDE, em 1997 e foi transformada em ferramenta

Open Source, em julho de 2000. Pela Sun Microsystems que, atualmente, é subsidiada pela

Oracle.

Atualmente, a versão 6.9 fornece suporte completo a todas as tecnologias Java,

incluindo depurador, compilador e ambiente de teste integrado. Além destes, oferece suporte a

diversas tecnologias de programação como o C, C++, PHP, etc, com recursos visuais

avançados e geradores de código que facilitam e agilizam a vida dos desenvolvedores.

Por estes motivos, o Netbeans foi empregado para a implementação da ferramenta

desenvolvida, se tornando um poderoso parceiro para este projeto colaborando com economia

de tempo de desenvolvimento e facilitando a elaboração.

3.3.2 Plataforma de desenvolvimento de relatórios

Um relatório é um agrupamento de dados, extraído de uma fonte de informação

para retornar resultados parciais ou totais de um determinado assunto. Para qualquer sistema

de banco de dados é indispensável uma ferramenta que gere um retorno de informação para o

usuário.

Para executar esta tarefa na ferramenta RAD optou-se pela ferramenta iReport,

que é especializada nesta função. Unida à tecnologia Java, ela é capaz de efetuar a

implementação de relatórios para impressão e arquivos de diversos formatos e web.

O iReport é uma ferramenta Open Source de desenvolvimento visual, que segue a

modelo RAD. Com ela, o desenvolvedor monta o relatório visualmente e um gerador de

15
15

16

código gera um arquivo XML que é interpretado por um compilador, integrado a uma biblioteca Java.

16
16

4

CONSTRUÇÃO DE UMA FERRAMENTA RAD

Após as etapas anteriores de contextualização e apresentação das técnicas e ferramentas utilizadas na construção da ferramenta RAD, este capítulo dá início à parte prática do projeto.

O propósito principal deste projeto é o desenvolvimento de uma ferramenta RAD que recebe o nome de Árticos que seja de fácil utilização para criação e implementação de sistemas de banco de dados. O foco desta ferramenta é ser uma facilitadora de desenvolvimento para os usuários finais. Com uma interface visual intuitiva e totalmente dinâmica, que, exija de seus utilizadores pouco conhecimento técnico na tecnologia de programação e experiência em desenvolvimento. Ela permite que o software seja utilizado para criação de sistemas de banco de dados, aptos para diversos ramos de atividades, dando uma flexibilidade grande à ferramenta. O Árticos é dividido em dois módulos principais o SDI e SDB sendo eles: o SDI (Sistema de Desenvolvimento de interfaces), no qual o usuário tem a possibilidade de criar e desenvolver telas visualmente que efetuam, automaticamente, a persistência com os campos das tabelas desejadas do banco de dados e também possui um editor de regras de negócio que permite tratar os dados através de eventos nos campos de tela; e o modulo SDB (Sistema de Desenvolvimento de Banco de Dados), que permite as manutenções da base de dados, além de oferecer assistentes de criação e alteração de tabelas e possui, também, um editor de código SQL com visualização dos resultados em grade. Além destes dois, há um módulo central no qual é executada a aplicação desenvolvida pelos usuários. O ponto forte deste é o controle de permissões de usuários sobre as telas, menus dinâmicos de acesso a elas e a criação de atalhos com imagem, liberados para todos que acessam o sistema. Para a execução de relatórios, o sistema possui uma interface, onde são cadastrados, após serem criados, pela ferramenta IReport, no momento em que usuário solicita sua execução pelo sistema, esses dados, cadastrados, são lidos e montam uma tela de entrada de parâmetros dinâmicas, facilitando a execução e até mesmo o desenvolvimento dos mesmos.

Segundo CARVALHO (1995, p. 24), Engenharia de software é auxiliar no processo de produção de software, de forma que o processo dê origem a produtos de alta qualidade, produzidos mais rapidamente e a um custo cada vez menor”.

18

Para PRESSMAN (1995, p. 31), “Ela abrange um conjunto de três elementos fundamentais, métodos, ferramentas e procedimentos que possibilita ao gerente o controle do processo de desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade produtivamente.”.

A elaboração do software é um processo criativo. Porém, além da criatividade do

programador ele precisa de um norteamento. A engenharia descreve a maneira com que o sistema será desenvolvido, detalhando seus processos, funções e funcionalidades. Isso é feito através de diagramas e métodos padronizados.

Neste tópico foi detalhado todo o processo de engenharia, desde a definição do banco de dados, processo de modelagem e implementação até a exposição dos diagramas UML da aplicação onde será apresentado todo o desenvolvimento da ferramenta.

4.1 Banco de dados

O Árticos persiste seus dados em um banco Firebird, sendo nele implementadas as

tabelas nativas que o sistema utiliza como padrão e as definidas pelo usuário, através do módulo SDB, além de uma View, que retorna os dados pertinentes à estrutura das tabelas,

criadas pelo usuário.

A ferramenta utiliza o banco de dados como um simples repositório, sendo que as

validações e persistência são efetuadas por regras de negócio direto nas aplicações geradas por ela. Sua estrutura de tabelas nativas segue o padrão de nomenclatura, com as inicias “sis_” seguido da descrição de sua função para facilitar a compreensão dos programadores e separar das criadas, posteriormente, pelos usuários. Estas entidades armazenam os dados básicos de configuração e acesso das aplicações criadas pelo Árticos, no diagrama de entidade e relacionamento (DER). Na Figura 2, é possível visualizar a representação do relacionamento entre as tabelas da ferramenta RAD e fica claro também, a estrutura adotada na criação do

banco que visa, principalmente, criar diretivas de segurança, que ligam os registro a algum usuário cadastrado.

18
18

19

Figura 2 - Diagrama de entidades e relacionamentos

19 Figura 2 - Diagrama de entidades e relacionamentos Cada tabela possui um papel de armazenamento

Cada tabela possui um papel de armazenamento distinto e fundamental na concepção do sistema e, a seguir, apresenta a definição detalhada de cada entidade vista na Figura 2.

A tabela SIS_MENU é responsável por armazenar os menus de acesso às telas

criadas pelos usuários e as nativas do sistema. O campo “tela” armazena o nome da interface, criada, que deve ser invocado pelo compilador no momento da execução. Outro fator

importante desta tabela é que ela possui uma referência circular entre os campos “ID” e “ID_PAI” cuja persistência é feita através de regras diretas na ferramenta.

A tabela SIS_ATALHO armazena os atalhos dos menus, permitindo que cada

usuário tenha seus registros para a personalização da área de trabalho individual dentro do sistema.

19
19

20

A tabela SIS_PERMISSAO possui a cardinalidade de muitos para muitos que é

responsável por armazenar as permissões de acesso a menus por usuários, visando a

flexibilidade e segurança do sistema.

A tabela SIS_USUARIO é responsável por armazenar os usuários do sistema de

dados como os pertinentes à conexão para envio de mensagens eletrônico e dado para identificação, como nome e foto. A tabela SIS_RELATORIO armazena os dados dos relatórios criados pelo iReport. O campo “nome” armazena o nome do arquivo gerado e, assim, permite que seja

invocado através do compilador para sua posterior execução.

A tabela SIS_PARAMETROSREL possui a cardinalidade de um para muitos com

a tabela SIS_RELATORIO e armazena os parâmetros de execução dos relatórios conforme

sua necessidade e tipo. Através desses dados, é possível criar uma interface dinâmica de execução de relatórios.

A tabela SIS_PERMISSAOREL possui a cardinalidade de muitos para muitos,

ligando as tabelas SIS_RELATORIO e SIS_USUARIO e armazena os dados pertinentes à permissão de execução dos relatórios. Como é possível observar nas tabelas descritas anteriormente e pelo diagrama DER, a estrutura do banco de dados foi montada priorizando a personalização do sistema e a segurança onde tudo, direta ou indiretamente, tem ligação com o usuário. As entidades

descritas a seguir têm a função de armazenar e retornar dados do banco referentes às interfaces criadas pelos programadores com o uso do sistema.

A SIS_TABELA é responsável por armazenar a descrição das tabelas físicas do

banco. Estes dados são utilizados pelo módulo SDB do sistema e a persistência desta tabela é feita através de regras de negócio pela aplicação.

A SIS_CAMPOS é responsável por armazenar a descrição dos campos das tabelas

físicas, os dados que são utilizados nas telas de pesquisa e pelo módulo SDB do sistema e,

como na anterior, sua persistência é feita via aplicação.

A view TABELA retorna os campos e suas propriedades das tabelas físicas do

banco de dados. Esta é o “coração” da aplicação, pois através dos dados, é possível criar a persistência dinâmica, porque eles garantem o funcionamento do módulo SDB e tem um papel fundamental no módulo SDI do sistema.

20
20

21

O QUADRO 1 mostra o código fonte de criação da view. Nele, é possível visualizar as funções e tabelas específicas do Firebird, bem como a estrutura que garante o retorno dos dados.

QUADRO 1 - Código fonte da view tabela

CREATE VIEW TABELA(TABELA, CAMPO, TIPO, TAMANHO, ESCALA) AS SELECT CAMPOS.RDB$RELATION_NAME TABELA, CAMPOS.RDB$FIELD_NAME CAMPO, CASE TIPOS.RDB$TYPE_NAME WHEN 'LONG' THEN 'INTEIRO' WHEN 'VARYING' THEN 'TEXTO' WHEN 'DATE' THEN 'DATA' WHEN 'INT64' THEN 'NUMERO' WHEN 'BLOB' THEN 'FOTO' ELSE TIPOS.RDB$TYPE_NAME END AS TIPO, COALESCE(DADOSCAMPO.RDB$CHARACTER_LENGTH,0) AS TAMANHO, COALESCE(DADOSCAMPO.RDB$FIELD_PRECISION,0) AS ESCALA FROM RDB$RELATIONS TABELAS, RDB$RELATION_FIELDS CAMPOS, RDB$FIELDS DADOSCAMPO, RDB$TYPES TIPOS WHERE TABELAS.RDB$RELATION_NAME = CAMPOS.RDB$RELATION_NAME AND CAMPOS.RDB$FIELD_SOURCE = DADOSCAMPO.RDB$FIELD_NAME AND DADOSCAMPO.RDB$FIELD_TYPE = TIPOS.RDB$TYPE AND TIPOS.RDB$FIELD_NAME = 'RDB$FIELD_TYPE' AND TABELAS.RDB$VIEW_BLR IS NULL AND (CAMPOS.RDB$SYSTEM_FLAG IS NULL OR CAMPOS.RDB$SYSTEM_FLAG = 0);

21
21

22

4.2 Estrutura da ferramenta RAD

Para melhor ilustrar a arquitetura, utilizada, pode-se visualizar o diagrama de pacotes no qual é representada a distribuição dos módulos, seus relacionamentos e comunicação entre os demais. Para BOOCH, RUMBAUGH, JACOBSON (2000, p. 20), Você usa os pacotes para organizar seus elementos de modelagem em conjuntos maiores que possam ser manipulados como grupos. Você é capaz de controlar a visibilidade desses elementos, permitindo que alguns itens fiquem visíveis fora do pacote, enquanto outros ficarão ocultos. Os pacotes também podem ser empregados para apresentar diferentes visões da arquitetura de seu sistema.”. O sistema foi dividido em pacotes, de maneira que prioriza a acessibilidade entre eles, a manutenção e a reusabilidade como se pode ver na Figura 3.

Figura 3 - Diagrama de pacotes C OM P ON E N TE E D
Figura 3 - Diagrama de pacotes
C
OM P ON E N TE
E
D ITOR
TE LA OB J
S
D B
S
D I
P E R S IS TE N C IA
M E N U
A
TA LH O
U
TIL
D A O
R E LA TOR IO
A R TIC OS
L i c e n c a . l i c
C OM P ILA D OR

Te l a. a r t

Na divisão dos módulos e suas dependências ficam claras, a arquitetura e engenharia adotada na implementação do sistema, além das dependências entre os pacotes.

22
22

23

4.3 Pacote UTIL

O pacote UTIL tem papel fundamental na estrutura do sistema e subdivido em

outros dois pacotes: o DAO e o PERSISTENCIA que juntos são responsáveis pelo acesso e

manipulação do banco de dados que consiste nos processos de comunicação e mapeamento do banco relacional em objetos e sua consistência.

O pacote PERSISTENCIA provê a conexão com a base de dados que é feita

através de uma biblioteca JDBC que significa, em síntese, uma coleção de classes e métodos responsável pela execução e manipulação de comandos SQL, através do Java. Para que esta conexão seja estabelecida, foi utilizado driver JDBC “jaybird-full-2.1.6.jar” nativo do Firebird, que contém todos os métodos para comunicação com este banco especifico. Para configurar a conexão e visando a utilização do sistema para vários fins distintos, foram centralizados todos os parâmetros de acesso em um arquivo chamado de “Licenca.lic”, que é encriptado para proteger contra qualquer alteração não autorizada fora do sistema. Possui uma estrutura XML que facilita a sua leitura e manipulação e, além de armazenar os parâmetros de conexão, guarda informações do proprietário do software, bem como os endereços de gravação de arquivos fontes das telas, desenvolvidas pelo módulo SDI. QUADRO 2 é um exemplo do arquivo de licença decriptado.

QUADRO 2 - Arquivo licença

<TO.proprietariaTO> <nome>Cesar Augusto</nome>

<cgc>54.200.301-54</cgc>

<tel1>(45)3254-1510</tel1>

<tel2>(45)3254-1510</tel2>

<e mail>augustohunoff@gmail.com</e mail> <endereco>Rua 25 de outubro</endereco> <complemento>apartamento 1</complemento> <bairro>Centro</bairro> <cidade>Marechal Cândido Rondon</cidade> <uf>PR</uf>

<banco>C:\Articos2\TESTE.FDB</banco>

<ip>127.0.0.1</ip>

<porta>3050</porta>

23

24

Continuação do QUADRO 2.

<dirTela>C:\Articos2\Arquivos\Telas</dirTela>

<dirCompilacao>C:\Articos2\Arquivos\Fontes</dirCompilacao>

<dirTeste>C:\Articos2\Arquivos\Temp</dirTeste>

<dirRelatorio>C:\Articos2\Arquivos\Relatorios</dirRelatorio>

<validade>01/12/2010</validade>

<licensas>10</licensas>

<dias>0</dias>

</TO.proprietariaTO>

Deste arquivo, pode-se ressaltar o campo IP que é responsável pelo endereço do servidor, no qual está hospedado o banco de dados. O campo PORTA armazena a porta de acesso a este servidor e o campo BANCO armazena o endereço do arquivo da base de dados dentro do servidor. Um dos principais problemas na implementação de um sistema, utilizando uma tecnologia orientada de objetos e um banco de dados relacional é o mapeamento objeto- relacional. É um processo trabalhoso que envolve muito tempo e sua função, basicamente, é representar as tabelas com seus respectivos campos em classes e cada registro destas entidades são novas instâncias das classes. O responsável por este papel é o subpacote DAO que possui o mapeamento de todas as tabelas nativas do sistema. Na Figura 4, é possível visualizar a tabela SIS_TABELA com seu mapeamento objeto-relacional. Pode-se observar que cada campo da tabela torna-se um atributo privado na classe e esta possui métodos set para alimentar estes campos e get para recuperá-los.

Figura 4 - Mapeamento objeto-relacional

24
24

25

O subpacote PERSISTENCIA desempenha a função de fazer a persistência dos

objetos, mapeados, com o banco de dados, através de métodos que transformam o objeto novamente em atributos relacionais e o disparam contra o banco via execução de comandos SQL. Feito isso, aguarda o retorno da confirmação da transação, aberto com o disparo. O mesmo ocorre com a recuperação dos dados em que é disparado um comando SQL que retorna os dados, solicitados, que são transformados em objetos conforme o mapeamento. Em resumo, o pacote UTIL dá o suporte de acesso do banco de dados para toda a aplicação e efetua todo o tratamento de erro e a consistência com a base.

4.4 Pacote RELATORIO

Para GONÇALVES (2008, p. 12), “Um relatório é uma maneira agradável de apresentar os dados vindos de alguma base de informação com sua aparência formatada. Na maioria das vezes, relatórios são usados para agrupar as informações vindas de um grupo de dados, relacionados entre si, oriundos de diversas tabelas. Como resultado você tem apenas os campos determinados na construção do seu relatório e exposto como tal de forma a simplificar

a compreensão das informações. Vindo em um formato padronizado para impressão, como

um texto feito em um editor de textos, você só precisa mandar para a impressão ou exportá- los para outro formato de uso maior.. No Árticos, os relatórios são desenvolvidos através da ferramenta IReport que, como já visto nesta pesquisa, é uma especialista nesta função que gera um arquivo XML com

a definição e de dados e da estrutura do relatório. O módulo RELATORIO faz uso da

biblioteca de métodos, escrita em Java, chamada JasperReports que foi desenvolvida para auxiliar a criação e manipulação destes arquivos. No conceito, seguido pelo Árticos, todos os relatórios possuem parâmetros de entrada para filtragem ou inserção de dados, diretamente ligados à sua estrutura. O módulo

implementa uma tela de cadastro, usando como repositório as tabelas do banco de dados SIS_RELATORIO e SIS_PARAMETROSREL, para armazenar estes parâmetros e dados de acesso aos arquivos XML gerados.

O módulo permite que os parâmetros possam assumir várias formas de passagem

de valores, sendo caracteres numéricos, alfanuméricos ou do tipo data que permitem ser alimentados, através de uma consulta ao banco de dados, por uma lista de valores ou uma

25
25

26

simples entrada por digitação. Assim, possibilitando uma flexibilidade para os usuários efetuarem suas customizações. No momento da execução do relatório, o módulo monta uma tela dinâmica com os parâmetros de entrada cadastrados, já efetuando os tratamentos dos dados como tipos inválidos ou informações nulas. Para a execução dos arquivos XML, o módulo usa métodos especializados. A biblioteca JasperReports coleta os parâmetros informados, compila, executa o relatório e o exibe em uma interface personalizada, que permite salvar o relatório em vários formatos diferentes de arquivo. Como os relatórios retornam informações armazenadas pelas operações do sistema que nem sempre devem ficar disponíveis a todos os usuários, o módulo disponibiliza métodos para controle de permissões de acesso a eles. Armazena parâmetros de segurança na tabela SIS_PERMISSAOREL que define quem terá acesso para executá-los.

4.5 Pacote SDB

O módulo SDB (Sistema de Desenvolvimento de Banco de Dados) provê um conjunto de métodos e interfaces que permitem ao usuário do Árticos projetar, construir e manipular a base de dados e sua estrutura. Seu acesso ao banco de dados é feito através dos métodos do módulo UTIL. Além destas funções, o SDB ainda retorna, gerencia e armazena toda a estrutura, descrição e relacionamentos do banco de dados. Estas informações são depositadas nas tabelas SIS_TABELA e SIS_CAMPOS, que guardam os dados de descrição, observação e a finalidade de cada um. Estas informações são processadas por métodos, ligados às informações da view TABELA, sendo disponibilizadas em uma interface visual, retornando todos os dados conceituais do banco para facilitar seu entendimento ao usuário. O módulo possui alguns facilitadores para a manipulação da estrutura do DB, uma interface gráfica para a criação e edição das tabelas. Este envolve desde a criação dos campos, chaves e índices com o uso de um dialeto em português, desenvolvido para facilitar o desenvolvimento. Para as consultas e execução de códigos SQL, o módulo possui um editor de regras com o reconhecimento de palavras reservadas, tratamento de transações, funções de

o módulo possui um editor de regras com o reconhecimento de palavras reservadas, tratamento de transações,

27

salvar e recuperar arquivos de código e a função de execução de códigos em multi-janelas e ou por seleção de trechos. O retorno da informação desta consulta é através de uma interface do tipo grade de dados com ordenação por coluna.

Na execução e manipulação das regras SQL, é feito, dinamicamente, o tratamento

de erros. Através da interceptação da resposta feita pelo banco de dados e sua tradução para o português das mensagens mais comuns, catalogadas, facilitando os tratamentos e desenvolvimento dos códigos. Com o armazenamento dos dados, centralizados em uma base, é fundamental que

seja adotada uma política de segurança como rotina pelos usuários do sistema. É melhor que ele seja feito de maneira automatizada para reduzir os riscos de erros humanos. O SDB oferece métodos que automatizam e auxiliam o processo de cópias de segurança tanto para fazê-lo como para recuperá-lo.

4.6 Pacote SDI

O pacote SDI (Sistema de Desenvolvimento de Interfaces) provê um conjunto de ferramentas e métodos que se aplicam à metodologia RAD e facilitam o desenvolvimento de interfaces com persistência ao banco de dados. Para atender este requisito, o pacote oferece uma interface de desenvolvimento

visual de telas, adotando técnica de criação drag-and-drop. O usuário tem a liberdade de construir as interfaces, totalmente personalizadas, arrastando e posicionando os componentes como desejar.

Os componentes disponíveis para os usuários utilizarem, são voltados para a

persistência com o banco de dados, possuindo parâmetros que efetuam a conexão com o campo da tabela, bem como os que definem tamanho visível na tela, posição no formulário e

um de texto que é exibido como uma mensagem de ajuda durante a execução. No próximo capítulo, será apresentada a utilização detalhadamente.

O pacote efetua a consistência e persistência com o banco de dados,

dinamicamente, transformando cada campo da tabela em uma variável local com o tipo de dado que corresponde ao tipo implementado no banco. Esta variável fica disponível para tratamento via regra de negócio e ou ligação ao um componente de tela.

27
27

28

O SDI possui um editor de regras de negócio que permite que o programador desenvolva códigos para manipulação dos dados. Por este editor, fica aberta toda a tecnologia Java bem como os campos das tabelas do banco de dados. Para facilitar o código estão disponíveis alguns métodos, previamente implementados, como validador de CPF entre outros. Estas regras, desenvolvidas, são disparadas através de eventos, acionados pelos componentes de tela ou por ela mesma, e eventos específicos para a persistência dos dados como antes de inserir, antes e depois de alterar, depois de selecionar nos dados do BD. As telas, criadas, são armazenadas em um arquivo XML, com a extensão “.lic” bem como uma cópia de segurança que armazena seu estado anterior antes da última alteração. O QUADRO 3 mostra um trecho de um arquivo. Nele, é possível visualizar como eles são estruturados em uma hierarquia com início nas configurações de acesso à tabela do BD, seguindo-a com suas propriedades e componentes com suas propriedades e eventos.

QUADRO 3 - Arquivo de XML

<telaObj.TelaObj> <nome>FrCor</nome> <pro> <vt> <telaObj.propriedadeObj> <nome>Nome</nome> <valor class="string">FrCor</valor> <tipo>texto</tipo> </telaObj.propriedadeObj> <telaObj.propriedadeObj> <nome>Rotulo</nome> <valor class="string">Cadastro de Cor</valor> <tipo>texto</tipo> </telaObj.propriedadeObj> <telaObj.propriedadeObj> <nome>Interface</nome> <valor class="string">TBC001COR</valor> <tipo>interface</tipo> </telaObj.propriedadeObj>

28
28

29

Este arquivo será interpretado e compilado pelos métodos do compilador que gerará os arquivos class do Java. Qualquer erro retornado pelo compilador é interceptado e traduzido para facilitar o entendimento do programador. Para garantir a consistência e segurança das informações, o módulo apresenta métodos para disponibilizar uma interface que efetue o controle de segurança das telas, criadas, com a liberação para usuário previamente cadastrado no sistema, e disponibiliza ou não o acesso à criação de menus.

4.7 Pacote COMPILADOR

O módulo de compilação do Árticos é responsável por gerar os arquivos .class, necessários para a execução das interfaces e regras, criadas pelo SDI. O módulo é composto por uma biblioteca de classes especializadas nesta função que envolve a interpretação, compilação execução dos códigos. A compilação de códigos, desenvolvida em Java pelo Árticos, é composta dos seguintes processos: o módulo SDI gera um arquivo com extensão “art” como já citado no capitulo anterior. Quando solicitada a sua compilação, o compilador localiza o arquivo pelo endereço gravado na licença, interpreta em memória e submete-o ao construtor de classes do sistema que efetua a análise do XML e converte-o para um arquivo temporário com a extensão “.java” com o código-fonte na tecnologia Java. Após a geração deste arquivo, ele é submetido ao compilador Java que gera um conjunto de instruções, otimizadas, para ser interpretadas pela máquina virtual JVM. Estes arquivos são conhecidos como bytecodes. O responsável pela sua geração é o método Javac que, basicamente, empacota as classes do compilador Java e efetua a transformação do .javapara o bytecodes ou .classno Árticos. Este aplicativo esta contido pela biblioteca nativa tools.jar.

Esta biblioteca possui a classe com.java.tools.javac.Main que, basicamente, é o compilador Java. Esta classe possui um método de compilação estático, chamado compile que recebe uma lista, contendo os nomes dos arquivos a serem compilados. No QUADRO 4, demonstra-se o método de compilação do módulo. Este invoca o método e efetua o tratamento de erro de compilação, devolvendo-o no retorna do método.

29
29

30

QUADRO 4 - Método de compilação

public static String Compilar(String codClasse, String nomeClass, int tipo) throws IOException { try { proprietariaTO to = FrArticosDesk.proprietaria; String path = ""; if (tipo == COMPILAR) path = to.getDirCompilacao().replaceAll("\\\\", "/"); else path = to.getDirTeste().replaceAll("\\\\", "/"); PrintWriter saida = new PrintWriter(new FileWriter(path + "/resulado.txt")); String arquivoFonte = path + "/" + nomeClass + ".java"; FileWriter writer = new FileWriter(arquivoFonte); writer.write(codClasse); writer.close(); int resultadoCompilacao = Main.compile( new String[]{arquivoFonte}, saida); if (resultadoCompilacao == 0) { File toDelete = new File(arquivoFonte); if (toDelete.exists()) { toDelete.delete();

}

return ""; } else { BufferedReader resultado = new BufferedReader( new FileReader(path + "/resulado.txt")); String linha; String Resultado = ""; while ((linha = resultado.readLine()) != null) { Resultado += linha + "\n";

}

saida.close(); File toDelete = new File(arquivoFonte); if (toDelete.exists()) { toDelete.delete();}

return Resultado;

}

} catch (IOException exc) { exc.printStackTrace(); return "Erros na compilação: \n" + exc.getMessage();

}

}

30
30

31

Para que o usuário tenha acesso às interfaces, desenvolvidas, o módulo possui o método de execução da classe. Após ser compilada, implementa o método loadClass da biblioteca tools.jar, demonstrado no QUADRO 5, que é responsável por invocar e transformar a classe invocada em um objeto que, posteriormente, é transformado em um JInternalFrame. Todas as telas, desenvolvidas pelo SDI.

QUADRO 5 - Método de execução

public static Object executar(String nomeClass, int tipo) { Object instancia = null; try { proprietariaTO to = FrArticosDesk.proprietaria; String path = ""; if (tipo == COMPILAR) { path = to.getDirCompilacao().replaceAll("\\\\", "/"); nomeClass = nomeClass.replace(".art", ""); } else { path = to.getDirTeste().replaceAll("\\\\", "/");

}

URL[] urls = null; File dir = new File(path); java.net.URL url = dir.toURL(); urls = new URL[]{url}; ClassLoader cl = new URLClassLoader(urls); Class classe = cl.loadClass(nomeClass); instancia = classe.newInstance();

} catch (ClassNotFoundException e) {

} catch (MalformedURLException e) {

} catch (InstantiationException e) {

} catch (IllegalAccessException e) {}

return instancia;

}

O módulo também possui um conjunto de métodos que possibilita o monitoramento das variáveis locais públicas. Através deles, o usuário tem à sua disposição uma tela, na qual pode adicionar as variáveis que deseja monitorar. A tela efetua uma

31
31

32

atualização em seus valores a cada segundo, podendo acompanhar, assim, passo a passo, o que ocorre na tela. É muito útil para efetuar a validação de funcionamento de regras de negócio nas interfaces. Para possibilitar um melhor entendimento do processo de interpretação e compilação do sistema a Figura 5, descreve, passo a passo, todo o processo de compilação de uma interface, desde sua concepção pelo módulo SDI.

Figura 5 - Fluxo de compilação SDI Interpretador de Tela Gerador XML Interpretador XML Construtor
Figura 5 - Fluxo de compilação
SDI
Interpretador de Tela
Gerador XML
Interpretador XML
Construtor de Classe
Compilador
Executador

A tela é desenhada e definida de acordo com suas regras de negócio. Depois, é submetida aos métodos que interpretam a interface gráfica. Com os dados desta interpretação, é gerado o arquivo XML com toda a sua definição. Então, este arquivo é interpretado e submetido ao construtor de classes. Este construtor transforma o trabalho de criação do usuário em código fonte Java propriamente dito então a interface é submetida ao método de compilação, no qual são gerados os arquivos .class, que, posteriormente, são invocados pelo executador.

32
32

33

4.8 Pacote ARTICOS

Este módulo é responsável pelo front-end, ou seja, a interação Homem Máquinado sistema. Em síntese é a parte gráfica do software que faz a primeira interação com o usuário. Está dividido, internamente, em outros dois módulos: o ATALHO e o MENU, cada um responsável por executar funções distintas na execução do software. Este módulo efetua a aplicação de segurança do sistema. Quando o usuário executa o software, ele exibe uma tela de autenticação, que faz a leitura das diretivas, definidas nos outros módulos por usuário, impondo as regras e restrições sobre toda a aplicação.

Possui um ambiente de trabalho padronizado e o suporte para abertura de todas as

telas, desenvolvidas pelo SDI e todos os menus e atalhos do sistema, além de opções de gerenciamento de telas internas, expondo-as sobre o ambiente, bem como uma lista de acesso as que já estão sendo executadas. As interfaces são abertas, utilizando-se o método “executar” do módulo compilador que recebe a tela com um objeto e a converte em um JIternalFrame para posterior execução.

O sub módulo MENU é responsável por gerenciar e criar a barra de menus da

interface gráfica que, através das diretivas de segurança, faz com que cada usuário tenha seus menus independente dos outros.

O sub módulo ATALHO permite que cada usuário crie seus atalhos ligados a

opções de menus, com o acesso à tela desejada e a personalização com uma imagem. Estes recursos fornecem a total parametrização e personalização do sistema por usuário. Este módulo possui a classe principal do sistema, ou seja, aquela que executa o software que, no momento da execução, busca o arquivos “.lic” para a configuração dos diretórios repositórios do sistema, bem como o acesso ao banco de dados. Como o software foi feito para atender várias situações distintas, ele possui métodos de gerenciamento de múltiplos arquivos de licença que, se identificado mais de um arquivo, pergunta ao usuário qual deseja executar.

33
33
34
34

5 OPERAÇÃO DA FERRAMENTA RAD DESENVOVIDA

Após as etapas de contextualização e engenharia do sistema estarem completas, foram efetuados a implementação e desenvolvimento do software, possibilitando, assim, a geração de um protótipo. A prototipagem de software tem com, a objetivo básico apresentar, demonstrar e testar os requisitos do sistema, ajudando os envolvidos no projeto a avaliar seus resultados e funcionamento de forma geral. Este capítulo tem como objetivo apresentar, de maneira detalhada, o funcionamento do protótipo e as atividades. Então a demonstração do protótipo em funcionamento vai possibilitar uma avaliação e entendimento melhor dos objetivos do software. Esta apresentação serve como uma rota de demonstração e treinamento do sistema, passando por todo seu funcionamento. Para ilustrar este processo foram utilizados exemplos práticos em cada módulo do sistema.

5.1 Acessando o software

O Árticos foi construído para ser utilizado em dois ambientes, sendo eles: de desenvolvimento de soluções e de suas utilização como aplicação. Em cada um, necessita de recursos físicos específicos do equipamento hospedeiro com a necessidade de maior processamento e memória disponível. O QUADRO 6, demonstra os comandos de execução da JVM para cada situação.

QUADRO 6 - Comandos de execução

# Aplicação cliente

javaw -jar "c:\Articos\Articos.jar"

# Aplicação programadores

javaw -Xms128M -Xmx1024M -jar "c:\Articos\Articos.jar"

Como se pode observar, no primeiro exemplo do QUADRO 6 uma simples chamada pela máquina virtual do Java, porém no segundo ha necessidade de utilização dos módulos SDI e SDB do sistema que precisam de um maior processamento e consumo de memória. Foram utilizados dois parâmetros adicionais, o Xms que define a memória inicial da JVM, e no exemplo, é iniciada com 128MB e o Xmx que define a memória máxima, gerenciada pela máquina virtual.

34
34

35

No momento em que o software é executado, ele localiza os arquivos de licença como mostra a Figura 6. Como já demonstrado neste trabalho, cada um carrega todas as configurações de acesso e aplicação de um cliente específico.

Figura 6 - Tela seleção proprietária

cliente específico. Figura 6 - Tela seleção proprietária Assim, o usuário tem a possibilidade de utilizar

Assim, o usuário tem a possibilidade de utilizar o sistema em várias aplicações especificas, podendo escolher qual utilizar no momento de entrada do sistema. Após a escolha do arquivo proprietário desejado, o software busca nele os dados da aplicação pertinente e configura o sistema, exibindo a tela de autenticação como mostra Figura 7. Traz os dados da aplicação, escolhida, e libera os usuários cadastrados. Nesta, a entrada deve ser feita através da identificação e senha previamente cadastrado pelo administrador do sistema.

Figura 7 - Tela de autenticação

35
35

36

Feita a devida autenticação, será aberto o front-end do sistema como na Figura 8. A tela serve como ponte de acesso a todos os módulos e interfaces, desenvolvidos pelos programadores, além de trazer informações gerenciais como qual usuário está utilizando o sistema no momento.

Figura 8 - Front-end

está utilizando o sistema no momento. Figura 8 - Front-end Esta tela implementa o padrão de

Esta tela implementa o padrão de janelas MDI (multiple document interface), ou interface de documentos múltiplos que, em síntese, é um modelo de organização de aplicações que consiste em abrir múltiplas janelas, dentro de uma única principal. Este modelo é muito utilizado em aplicações comerciais existentes no mercado. Todos os menus e ícones de atalhos são criados em tempo de execução, dinamicamente, conforme o cadastro e autorização do usuário, concedido pelo administrador. Com exceção do menu “janela”, que tem como função a organização automática das janelas dentro da aplicação. Como se pode observar, todos têm o mesmo layout, visando a padronização e organização para facilitar a usabilidade.

36
36

37

5.2 Módulo SDI

Para ter acesso ao módulo SDI, na janela principal, deve-se acessar o menu, “Utilitários” e o submenu “SDI (Sistema de Desenvolvimento de Interfaces)”. Abrir-se-á então, o ambiente de desenvolvimento do sistema como na Figura 9. Este tópico demonstrará suas funções.

Figura 9 - Sistema de Desenvolvimento de Interfaces

Figura 9 - Sistema de Desenvolvimento de Interfaces O ambiente de desenvolvimento do SDI foi criado,

O ambiente de desenvolvimento do SDI foi criado, visando a facilidade para o usuário. Seguindo a metodologia RAD, a tela é dividida em subjanelas de fácil visualização e entendimento, sendo elas: a barra de menus, atalhos de menus, barra de componentes, barra de propriedades e eventos, barra de interfaces, listagem de componentes, abas de desenvolvimento e regras de negócio. A barra de menus contém as opções de “Arquivo” que oferece as funções básicas de manipulação de arquivos e o “Ferramentas” com os submenus “Executar Formulário” responsável por compilar a interface que está sendo desenvolvida em modo teste. Está opção não afetará os formulários que estão sendo utilizados pelos usuários. O submenu “Compilar

37
37

38

Formulário”, compila o formulário em modo de produção ou seja ele é automaticamente disponibilizado para os usuários. O submenu “Compilar Todos Formulários”, compila todos os formulários que foram construídos pelo SDI, armazenados no diretório de telas e, o submenu “Registrar Tela”, abre a interface de registro criação de menus como mostra a Figura 10.

Figura 10 - Gerenciador de menus

como mostra a Figura 10. Figura 10 - Gerenciador de menus Estas telas efetuam a criação,

Estas telas efetuam a criação, edição e exclusão dos menus que irão aparecer na tela principal do sistema bem como a permissão dos usuários que podem visualizá-los. A vinculação dos menus, criados com as interfaces, deve ser feita, através do apontamento do arquivo, gerado pelo ambiente de desenvolvimento. O sistema cria, dinamicamente, a persistência com as tabelas do banco de dados que as transforma em variáveis locais. Para isto, o programador deve registrar as tabelas que

38
38

39

desejar na tela que está desenvolvendo. O SDI possui uma interface que auxilia este processo.

A Figura 11 mostra como criar e gerenciar esta tarefa.

Figura 11 - Gerenciador de persistência

esta tarefa. Figura 11 - Gerenciador de persistência Esta tela auxilia a ligação com o banco

Esta tela auxilia a ligação com o banco de dados e nela deve ser informada qual tabela deseja persistir, definindo sua chave primária e sua possível chave estrangeira com outra interface criada. Com estas informações, o sistema irá criar a persistência com o banco

de dados dinamicamente e as ligações criadas são exibidas na barra de interfaces no SDI. Esta

exibe os campos com seus tipos e tamanhos que foram criados no banco de dados. É possível criar-se a chave estrangeira com diversos tipos de relacionamentos e ligações diferentes, dando uma flexibilidade grande ao desenvolvimento. Além disto, as interfaces, com o banco de dados, possuem eventos para manipulação dos dados, via regra de negócio que são: “Antes Selecionar” é executado antes das variáveis receberem os dados das tabelas. “Antes Inserir”, “Antes Alterar” e “Antes Excluir” são executados antes dos dados serem persistidos na base de dados. “Depois Selecionar” é executado após as variáveis serem alimentadas. E os eventos “Depois Inserir”,

39
39

40

“Depois Alterar” e “Depois Excluir” são executadas após as persistências com a base de dados.

O SDI possui uma série de componentes para o desenvolvimento de telas como se

pode ver na Figura 12. Ele exibe a lista todas, além da interface de propriedades e eventos. Todos os componentes possuem funções especificas e métodos prontos para facilitar a interação com regras de negócio e com a persistência dinâmica com o banco de dados.

Figura 12 - Barras de componentes

com o banco de dados. Figura 12 - Barras de componentes Para utilizar estes componentes, basta

Para utilizar estes componentes, basta selecionar na barra e clicar no local que se deseja ou posicionar no formulário. Cada componente possui propriedades e eventos específicos que ficam disponibilizados na barra de propriedades e eventos. O componente “Rótulo” tem como objetivo exibir um texto estático sobre o formulário e pode ser alterado sobre regra ou receber o valor de um campo do banco de dados. Como não possui interação direta com o usuário não possui eventos.

O componente “Caixa de Texto” é um campo de texto que permite ao usuário

inserir e recuperar uma linha de texto, sendo ela alterada por regra ou persistir um campo do banco de dados. Possui dois eventos: “Entrar” executado no momento em que o componente recebe o foco e “Sair” quando perde o foco.

40
40

41

O componente “Caixa de Texto Pesquisa” é um campo de texto semelhante ao o

anterior, porém possui a opção de pesquisa de valores, através de uma consulta SQL definida

pelo usuário. Também possui eventos de “Entrar” e “Sair”.

O componente “Caixa de Calendário” é um campo de texto especialista em

tratamento de datas, exibe uma interface gráfica de um calendário para seleção, podendo ser alterado por regra ou persistir um campo do BD. Possui eventos de “Entrar” e “Sair”.

O componente “Caixa de Senha” é semelhante ao “Caixa de Texto” com o

diferencial de exibir os caracteres ocultos no formulário.

O Componente “Lista” é um campo de texto que permite ao usuário inserir e

recuperar uma linha de texto, sendo ela alterada por regra ou persistir um campo do BD. Possui uma interface gráfica, exibindo uma lista de valores para seleção, que é definida pelo usuário. Possui eventos de “Entrar” e “Sair”.

O componente “Memorando” é um campo de texto que permite ao usuário inserir

e recuperar várias linhas de texto, sendo ele alterado por regra ou persistir um campo do BD. Possui eventos de “Entrar” e “Sair”.

O componente “Foto” é o campo especializado para persistências de imagens em

campos do tipo Blob do banco de dados.

O componente “Tabela” é um campo do tipo grade de valor, alimentado por uma

consulta SQL, definida pelo usuário com função de ordenação por coluna.

O componente “Botão” é responsável por executar uma regra de negócio, possui o

evento “Executar”, responsável por implementar esta ação. O componente “Mapa” é responsável por manipular as funções do Google Maps

como retornar posição georeferenciada e manipular mapas.

O componente “Navegador” é para os programadores Delphi semelhante ao

DBNavigator responsável por navegar e persistir os registros de uma determinada tabela do BD. Possui as funções de navegação, inserir, alterar, e apagar os dados. Todos os componentes possuem uma propriedade em comum a “Ajuda” que recebe um código em HTML definido pelo usuário. No momento da execução do formulário, pode ser acionado com o botão “F1” do teclado que exibirá uma tela, executando o código do componente que estiver em foco.

41
41

42

As regras de negócio, acionadas pelos eventos tanto dos componentes como das interfaces, permitem a manipulação das informações e a automatização de funções. A definição das regras é implementada através de codificação Java.

Figura 13 - Editor de regras

através de codificação Java. Figura 13 - Editor de regras O Editor de regras do Árticos,

O Editor de regras do Árticos, como mostra a Figura 13, é uma ferramenta que

permite a implementação e gestão de todas as regras de negócio. Este módulo do sistema tem como objetivo facilitar as implementações. Possui o reconhecimento de palavras reservadas da tecnologia Java, além de diversas variáveis e métodos prontos para serem utilizados nas regras.

O editor possui um assistente de regra, através de um menu flutuante, acionado

por um clique com o botão direito do mouse sobre o código. Por ele, pode acessar as variáveis

e métodos, além das variáveis de persistências do banco de dados e todos os componentes que estão inseridos no formulário.

além das variáveis de persistências do banco de dados e todos os componentes que estão inseridos

43

Após a interface ser montada e as regras de negócio definidas, são submetidas ao compilador nativo do Java, chamando o método compilar do pacote UTIL. A Figura 14 mostra a interface de retorno das mensagens do compilador.

Figura 14 - Tela de mensagens

das mensagens do compilador. Figura 14 - Tela de mensagens O sistema possui uma biblioteca de

O sistema possui uma biblioteca de métodos que verifica a consistência das telas, criadas, retornando uma mensagem específica para cada situação de erro. Para as regras de negócio, o sistema traduz as mensagens mais comuns, retornadas pelo compilador Java e exibe as que não são conhecidas, sem alterá-las.

5.3 Módulo SDB

Para ter acesso ao módulo SDB, na janela principal, deve-se acessar o menu “Utilitários” e o submenu “SDB (Sistema de Desenvolvimento de Banco de Dados)” que abrirão o ambiente de manipulação da base de dados como está na Figura 15. Este capítulo demonstrará suas funções.

abrirão o ambiente de manipulação da base de dados como está na Figura 15. Este capítulo

44

Figura 15 - Sistema de Desenvolvimento de Banco de Dados

44 Figura 15 - Sistema de Desenvolvimento de Banco de Dados O menu arquivo, bem como

O menu arquivo, bem como a barra de ferramentas, oferecem as opções de

tratamento de arquivos, permitindo salvar e alterar códigos SQL. Cada arquivo aberto é inserido em uma nova aba. O SDB efetua um controle sobre transação com o banco de dados. Cada janela de execução de comandos, aberta, é uma nova transação com o BD que pode ser confirmada ou abortada através dos botões de controle nas abas.

O editor de regras efetua o reconhecimento das palavras, reservadas da linguagem

de programação SQL e permite efetuar a execução dos códigos por linhas, selecionadas ou todo o bloco de código.

O tratamento de exceções é feito pelo banco de dados. O Árticos intercepta os

erros, reportados e efetua a tradução dos mais comuns e os exibe em uma caixa de mensagem na tela para facilitar a compreensão do programador. Todo o resultado das execuções é

exibe em uma caixa de mensagem na tela para facilitar a compreensão do programador. Todo o

45

apresentado através de grade de dados com a opção de indexação das colunas, somente clicando na descrição de cada uma delas.

O sistema possui uma biblioteca de dados, apresentada através de uma árvore

como mostra na Figura 16. É uma descrição completa da base de dados, trazendo as tabelas e campos com descrição, bem como o tipo de dados, tamanho e identificação de chave. No caso de estrangeira, mostra a tabela e campo a que está ligada.

Figura 16 - Manipulação de tabelas

a que está ligada. Figura 16 - Manipulação de tabelas A opção de menu flutuante permite

A opção de menu flutuante permite criar e editar tabelas, chaves primárias e

estrangeiras e também definir a descrição das tabelas e campos. O título curto, definido para os campos, será exibido nas telas de pesquisa do sistema que são acionadas através do componente “Caixa de Texto Pesquisa”. O menu também oferece a opção de consulta que gera o código SQL de consulta de dados em uma nova aba da tabela, selecionada.

45
45

46

5.4 Módulo Relatório

Como já mencionado nesta pesquisa, os relatórios são desenvolvidos pelo aplicativo IReport e cadastrados no Árticos para posterior execução. Para acessar o cadastro de relatório vai-se ao menu “Utilitários” e o submenu “Registrar Relatório”. A Figura 17 mostra a tela de cadastro dos relatórios, bem como a de cadastro de parâmetros que são usados para geração de uma tela de entrada de valores para filtragem dos dados dinamicamente.

Figura 17 - Cadastro de relatório

dos dados dinamicamente. Figura 17 - Cadastro de relatório No cadastro de parâmetros, são definidos os

No cadastro de parâmetros, são definidos os tipos de dados, podendo ser texto, número ou data, como também a categoria, podendo ser uma consulta SQL na qual será exibida uma tela de pesquisa com o código em execução e uma lista de dados a qual será exibida em uma tela de pesquisa para seleção de dados e a opção de abrangência que define que os valores dos parâmetros podem ser informados em mais que um ou valor único. Para executar os relatórios, cadastrados na janela principal, deve-se acessar o menu “Utilitários” e o submenu “Relatórios” que exibirão a tela de seleção de relatórios como, consta na Figura 18.

46
46

47

Figura 18 - Tela de parâmetros

47 Figura 18 - Tela de parâmetros Quando selecionado o relatório, é gerada, dinamicamente, a tela

Quando selecionado o relatório, é gerada, dinamicamente, a tela de parâmetros de entrada, e exibindo as telas de consultas, conforme consta no cadastro. Quando os parâmetros são informados e executados, o relatório é exibido em uma tela interna na janela principal como na Figura 19.

47
47

48

Figura 19 - Execução dos relatórios

48 Figura 19 - Execução dos relatórios Esta tela oferece as opções de zoom navegação e

Esta tela oferece as opções de zoom navegação e ajustes de páginas, além da impressão. Oferece uma variada opção de salvamento de arquivo em vários formatos como PDF, JPG entre outros. Esta forma de execução de relatórios permite realizar vários relatórios ao mesmo tempo.

48
48

6 ANÁLISE DOS RESULTADOS

49
49

A engenharia de software tradicional, com seus ciclos de vida demasiadamente longos, virá suprir diversos problemas no ambiente de criação de sistemas. Porém, por seguir um conceito extremamente rígido e inflexível leva um longo tempo para apresentar resultados e finalizar o produto. Este fato agrava-se quando se fala no ambiente corporativo, pois o negócio do cliente está em constante mudança. Por este motivo, muitas vezes, quando a produção do software é encerrada, necessita de alterações urgentes, gerando um alto custo podendo inviabilizar o projeto. Tendo como base o quadro apresentado, o modelo de desenvolvimento RAD, com sua metodologia ágil e dinâmica, visa, principalmente, superar vários problemas desta realidade e, principalmente, o longo tempo gasto no desenvolvimento dos softwares. Porém, sua metodologia não promete nenhum “milagre” em questões como custo e agenda porque exige uma disciplina firme por parte dos envolvidos no projeto. Caso contrário, não pode garantir os resultados esperados. Como foi, visto neste trabalho, para que se justifique a adoção da metodologia e obtenha-se sucesso em sua utilização, o cliente deve estar o tempo todo envolvido no projeto desde o inicio até o término. Assim expondo sua necessidade de mudança no andamento do desenvolvimento, limitando, desta forma, erros e proporcionando uma produção muito mais rápida.

Com o cumprimento desta exigência de compromisso de todos exigido pelo modelo RAD e a adoção de uma ferramenta de desenvolvimento rápido para auxiliar o cumprimento do calendário e facilitar a vida dos programadores, pode-se alcançar pontos importantes de sucesso dentro da concepção do software como uma diminuição considerável em erros de implementação e de defeitos e consequentemente, uma maior satisfação do cliente.

Especialista na metodologia do modelo RAD, proporciona aos programadores um ambiente de desenvolvimento visual, a geração de código automatizado, a reutilização de trechos da aplicação e o mais importante para o modelo a geração de protótipos em tempo de criação. Esta prototipagem interativa e evolutiva proporciona uma grande interação entre clientes, programadores e usuários finais do sistema. Assim, permite a todos os envolvidos

49
49

50

acompanhar e diagnosticando o andamento do projeto, podendo, a qualquer momento, reportar e solicitar alterações. Para o sucesso do RAD é necessário que as partes envolvidas estejam cientes de todos os requisitos e seus impactos na aplicação. Assim, os programadores, clientes, gestores e usuários devem disponibilizar um grande tempo para o projeto. A fim de facilitar o andamento do projeto, a equipe de desenvolvimento, deve ter autoridade para tomar decisões que antes eram tomadas pelos gestores. Dentre outras limitações, pode-se destacar que a abrangência de software é controlada, o desenvolvimento limita-se às operações disponibilizadas pela ferramenta adotada e o sistema tem dificuldade em interagir com outros programas e não pode ser modularizado. Como vantagens pode-se destacar a utilização das ferramentas especialistas no modelo RAD que permitem economizar tempo no desenvolvimento, manutenção e horas especializadas de profissionais em programação, além de oferecer meios de automatizar a codificação pelos geradores de código. Por outro lado, este suporte da ferramenta e esta geração de código de forma automatizada podem limitar o desenvolvimento de regras de negócio especializados a situações específicas de cada cliente, obrigando os programadores a escrever grandes extensões de codificação, manualmente, para adaptar ao suporte que a ferramenta oferece. Outro fato importante como vantagem de sua utilização é que se obtém uma visão do produto, já nos primeiros passos do projeto, através dos protótipos evolutivos, assim como, uma maior flexibilidade em possíveis alterações. Já quando em materiais e métodos, a linguagem Java, se mostrou poderosa para o projeto por possuir dinamismo e flexibilidade e por permitir de maneira facilitada a manipulação e criação de código fonte em tempo de execução. Porém, a ferramenta de desenvolvimento Netbeans, apresentou vários problemas durante sua utilização, como a criação incorreta de referências dentro do arquivo JAR, gerado problemas na geração dos arquivos fontes, além da utilização de classes que não possui ligação com pacotes nativos da linguagem Java, forçando reparos nas classes após cada compilação.

50
50

CONCLUSÃO

A ferramenta desenvolvida neste trabalho demonstra a possibilidade do uso do modelo RAD unido à tecnologia Java como uma boa alternativa para o desenvolvimento de aplicações no ambiente corporativo ou pessoal. O software desenvolvido oferece facilidade e praticidade no processo de criação e desenvolvimento de aplicações com sua interface intuitiva que permite aos usuários comuns criar aplicações sem muito conhecimento especifico que é o principal objetivo deste trabalho. Para o uso comercial, é possível ter ganhos significativos com a ferramenta com uma diminuição considerável no tempo de desenvolvimento, dispensa de programadores de computadores experientes e possibilidade de fácil adaptação e manutenção do sistema, além de implementar tecnologias livres que não possuem custos de licença. A facilidade para criar aplicações com a ferramenta mostrou ser um ponto essencial, conseguindo integrar o poder da metodologia e tudo que ela oferece à flexibilidade do Java. O que permite gerar aplicações complexas mas ao mesmo tempo, com codificação extremamente simplificada, a fim de que a ferramenta se adapte às diversas necessidades dos usuários.

Demonstra que o desenvolvimento de sistemas com a implementação da linguagem Java, integrada ao banco de dados relacional, não precisa ser uma tarefa tão complexa como parece, pois, com o uso dos recursos implementados, pode tornar-se rotina para os usuários. Outro fato importante a ser considerado neste trabalho é a quebra do paradigma do ciclo de vida tradicional da engenharia de software para um modelo totalmente flexível que incentiva a participação do usuário, do cliente e dos programadores numa parceria para o desenvolvimento de aplicações. Seguindo este pensamento, pode-se considerar os inúmeros benefícios que esta abordagem proporciona à engenharia de software como uma mudança na

52

maneira de efetuar o levantamento de requisitos, a maneira de efetuar a validade do sistema e seu controle de qualidade.

52
52

REFERÊNCIAS BIBLIOGRÁFICAS

BOOCH, G.;RUMBAUGH, J.; JACOBSON, I. UML guia do usuário. Rio de Janeiro:

Campos, 2000. CARVALHO, Adriane M. B. R.; CHIOSSI, Thelma C. dos S. Introdução a Engenharia de

Software. São Paulo: UNICAMP, 2001. DATE, C. J. Introdução a Sistemas de Bancos de Dados. Rio de Janeiro: Campos, 1990. FIREBIRD. Disponível em: <http://www.firebirdsql.org/index.php?op=guide>. Acesso em:

10 set. 2010 GONÇALVES, E. Dominando relatórios JasperReport com iReport. Rio de Janeiro:

Ciência Moderna, 2008. GRAVES, M. Projeto de banco de dados com XML. São Paulo: Makron Books, 2003.

MACHADO, F. N. R

PRESSMAN, R.S. Engenharia de Software. São Paulo: Makron Books, 1995. SANTOS, R. R. dos. Programando em Java 2 : teoria e aplicações. Rio de Janeiro: Axcel Books, 2004. SILBERSCHATZ, A.; KORTH, F. H.; SUDARSHAN, S. Sistemas de banco de dados. São Paulo: Makron Books, 1999. SILVA, F. A. Programando com XML. Rio de Janeiro: Campos, 2004.

Banco de dados: projeto e implementação. São Paulo: Érica, 2004.