tcc ferramenta rad
TRANSCRIPT
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
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.
iii
iii
DEDICATÓRIA
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.
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.
vi
vi
Não tento dançar melhor do que ninguém.
Tento apenas dançar melhor do que eu mesmo.
Mikhail Baryshnikov
vii
vii
SUMÁRIO
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
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
ix
ix
LISTA DE FIGURAS
Figura 1 - Ciclo RAD x Ciclo Tradicional ................................................................................. 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
Figura 8 - Front-end ................................................................................................................. 36
Figura 9 - Sistema de Desenvolvimento de Interfaces ............................................................. 37
Figura 10 - Gerenciador de menus ............................................................................................ 38
Figura 11 - Gerenciador de persistência ................................................................................... 39
Figura 12 - Barras de componentes .......................................................................................... 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
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
xi
xi
LISTA DE SIGLAS
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
xii
xii
RESUMO
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.
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
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.
4
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
5
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.
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
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.
8
8
Figura 1 - Ciclo RAD x Ciclo Tradicional
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
9
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.
10
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.
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
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.jar” que 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.
13
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
14
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.
15
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
16
16
código gera um arquivo XML que é interpretado por um compilador, integrado a uma
biblioteca Java.
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
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.
19
19
Figura 2 - Diagrama de entidades e relacionamentos
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.
20
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.
21
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);
22
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
SDI
TELAOBJEDITORCOMPONENTE
UTIL
DAO
PERSISTENCIA
ARTICOS
MENU ATALHO
COMPILADOR
SDB
RELATORIO
Tela.art
Licenca.lic
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.
23
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>[email protected]</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>
24
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
25
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
26
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
27
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.
28
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>
29
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 “.java”
para o bytecodes ou “.class” no Á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.
30
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();
}
}
31
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
32
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 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.
33
33
4.8 Pacote ARTICOS
Este módulo é responsável pelo front-end, ou seja, a interação “Homem –
Máquina” do 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.
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.
35
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
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
36
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
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.
37
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
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
38
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
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
39
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 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”,
40
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
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.
41
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.
42
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
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.
43
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
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.
44
44
Figura 15 - Sistema de Desenvolvimento de Banco de Dados
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 é
45
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 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.
46
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
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.
47
47
Figura 18 - Tela de parâmetros
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.
48
48
Figura 19 - Execução dos relatórios
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.
49
49
6 ANÁLISE DOS RESULTADOS
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
50
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.
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
52
maneira de efetuar o levantamento de requisitos, a maneira de efetuar a validade do sistema e
seu controle de qualidade.
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.. Banco de dados: projeto e implementação. São Paulo: Érica, 2004.
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.