NT000A3B0A

RELATÓRIO DE ESTÁGIO
NEUS BEANGEN – UM FRAMEWORK PARA

REALIZAÇÃO DE MAPEAMENTO OBJETO RELACIONAL
Fábio Pereira Carneiro
Orientador: Hamilton Soares da Silva

Supervisor: Mário Henrique Matos Alves
Coordenador de estágio: Antônio Carlos
Empresa: NEUS – Tecnologia da Informação
João Pessoa
10 de fevereiro de 2005
Relatório de Estágio - Fábio Pereira Carneiro - NEUS BeanGen
SUMÁRIO
RESUMO ............................................................................................................................................................... 5
DEDICATÓRIA.................................................................................................................................................... 6
IDENTIFICAÇÃO................................................................................................................................................ 7
ESTAGIÁRIO ......................................................................................................................................................... 7
EMPRESA ............................................................................................................................................................. 7
INTRODUÇÃO..................................................................................................................................................... 8
PROPÓSITO DO DOCUMENTO ................................................................................................................................ 8
ORGANIZAÇÃO DO DOCUMENTO.......................................................................................................................... 9
Aquisição de Conhecimento............................................................................................................................ 9
Desenvolvimento do Projeto ........................................................................................................................... 9
Treinamento .................................................................................................................................................... 9
MOTIVAÇÃO ........................................................................................................................................................ 9
Estado da Arte – Arquitetura NEUS ............................................................................................................. 10
AQUISIÇÃO DE CONHECIMENTO .............................................................................................................. 11
MAPEAMENTO OBJETO RELACIONAL ................................................................................................................ 11
PROGRAMAÇÃO ORIENTADA A OBJETOS (POO) ................................................................................................ 12
SGBD’S – RELACIONAL X OO........................................................................................................................... 13
OO X SGBD ...................................................................................................................................................... 13
JDBC................................................................................................................................................................. 15
GERAÇÃO DE CÓDIGO ........................................................................................................................................ 17
ANT .................................................................................................................................................................. 18
XDOCLET .......................................................................................................................................................... 21
O que é? ........................................................................................................................................................ 21
XDoclet X JavaDoc ....................................................................................................................................... 21
Integração com ANT ..................................................................................................................................... 23
XDoclet Template (arquivo.xdt).................................................................................................................... 23
Tag Handlers................................................................................................................................................. 24
Geração (1 – 1) X (N – 1) ............................................................................................................................. 25
Exemplo......................................................................................................................................................... 25
DESENVOLVIMENTO DO PROJETO .......................................................................................................... 30
METODOLOGIA .................................................................................................................................................. 30
PROCESSO .......................................................................................................................................................... 31
Planejamento ................................................................................................................................................ 31
Escopo....................................................................................................................................................... 31
Recursos.................................................................................................................................................... 32
Riscos........................................................................................................................................................ 33
Métricas..................................................................................................................................................... 35
Cronograma............................................................................................................................................... 36
Modelo de Ciclo de Vida............................................................................................................................... 36
Análise de Requisitos .................................................................................................................................... 38
Estudo de Viabilidade ............................................................................................................................... 38
Projeto do Sistema ........................................................................................................................................ 38
Estruturas de Dados................................................................................................................................... 38
Arquitetura do Sistema.............................................................................................................................. 39
Interfaces do Sistema ................................................................................................................................ 40
Implementação .............................................................................................................................................. 41
UFPB – Universidade Federal da Paraíba -2-

Geração de Arquivo Exemplo ................................................................................................................... 41

Testes............................................................................................................................................................. 47
Implantação .................................................................................................................................................. 47
Manutenção................................................................................................................................................... 47
TREINAMENTO ................................................................................................................................................ 49
NEUS BEANS .................................................................................................................................................... 49
Acessor Methods ........................................................................................................................................... 49
Chave Primária............................................................................................................................................. 49
Representação Gráfica.................................................................................................................................. 50
NEUS BEANGEN TAGS ..................................................................................................................................... 50
BeanTags....................................................................................................................................................... 50
@neus.isBean............................................................................................................................................ 51
@neus.poolSize......................................................................................................................................... 51
GetterMethodTags ........................................................................................................................................ 51
DBGetterMethodTags ............................................................................................................................... 52
CompositionGetterMethodTags ................................................................................................................ 54
CONCLUSÕES ................................................................................................................................................... 57
REFERÊNCIAS.................................................................................................................................................. 58
BIBLIOGRAFIA ................................................................................................................................................... 58
INTERNET........................................................................................................................................................... 58
AVALIAÇÃO...................................................................................................................................................... 59
SUPERVISOR – MARIO HENRIQUE MATOS ALVES .............................................................................................. 59
COORDENADOR – HAMILTON SOARES DA SILVA ............................................................................................... 60

ÍNDICE DE FIGURAS
FIGURA 1 - ARQUITETURA EM CAMADAS USADA NA NEUS ............................................................. 10
FIGURA 2 – MOR – MAPEAMENTO OBJETO RELACIONAL................................................................ 12
FIGURA 3 – XDOCLET X JAVADOC............................................................................................................ 21
FIGURA 4 – CAMADAS DA ENGENHARIA DE SOFTWARE .................................................................. 30
FIGURA 5 – MODELO DE CICLO DE VIDA CASCATA ........................................................................... 37
FIGURA 6 – ARQUITETURA DO NEUS BEANGEN................................................................................... 39
FIGURA 7 – INTERFACES DO NEUS BEANGEN ....................................................................................... 41
ÍNDICE DE TABELAS
TABELA 1 – COMPOSIÇÃO – PESSOA/CIDADENATAL – CLASSES JAVA ........................................ 13
TABELA 2 – COMPOSIÇÃO – PESSOA/CIDADENATAL – TABELAS SGBDR .................................... 14
TABELA 3 – HERANÇA – VEICULO/TAXI – CLASSES JAVA ................................................................ 14
TABELA 4 – HERANÇA – VEICULO/TÁXI – TABELAS SGBDR ............................................................ 15
TABELA 5 – LOOKUP.JAVA - EXEMPLO DE USO DA API JDBC ......................................................... 16
TABELA 6 – RGC X CDG................................................................................................................................ 17
TABELA 7 – ARQUIVO “.BAT” PARA BUILD SIMPLES.......................................................................... 19
TABELA 8 – ARQUIVO DO ANT - BUILD.XML..................................................................................... 19
TABELA 9 – EXEMPLO XDOCLET - HELLOWORLD.JAVA .................................................................. 22
TABELA 10 – HTML GERADO PELO JAVADOC ...................................................................................... 22
TABELA 11 – CRIAÇÃO DE UMA TAG PRÓPRIA..................................................................................... 25
TABELA 12 – RAIZ DE GERAÇÃO DE CÓDIGO RGC.............................................................................. 26
TABELA 13 – GERAÇÃO 1 – 1........................................................................................................................ 29

Resumo
O projeto NEUS BeanGen se propõe a automatizar a camada responsável pelo
mapeamento de objetos Java em tabelas de bancos de dados relacionais, com o propósito de
aumentar a produtividade no desenvolvimento de software abstraindo ao máximo o uso de
API’s como JDBC. A automatização será adquirida através de geração de código que
proporciona a diminuição no tempo de desenvolvimento de softwares visto que códigos
redundantes antes escritos por programadores, a partir de então serão gerados a partir de uma
raiz de geração. A detecção de erros de programação será facilitada devido ao fato de que os
erros são centralizados na raiz de geração de código. Portanto o projeto tende a aumentar a
produtividade trazendo mais segurança para o desenvolvimento de softwares.

Dedicatória
Dedico este trabalho a todas as pessoas

que contribuíram direta ou indiretamente para
a minha formação moral, ética e profissional.

Identificação
Estagiário
Nome: Fábio Pereira Carneiro
Endereço: Av. Olinda, 385 apto 901 Tambaú – João Pessoa - PB
Telefones: 226-2823 / 8802-1610
Curso: Bacharelado em Ciências da Computação
Período do Estágio: 11/2003 a 03/2004
Empresa
Nome: NEUS – Tecnologia da Informação
Endereço: Av Ruy Carneiro, Trade Office Center Nº 300, Sala 206
Tambauzinho, João Pessoa – PB
Telefone: 225-8257
A NEUS – Tecnologia da Informação é uma empresa especializada em
desenvolvimento de software para Internet, sistemas de comércio eletrônico
entre empresas e serviços executivos de suporte à decisão (Data Warehousing e
Data Mining).
Sua missão é construir softwares de excelência como meio para seus clientes e
a sociedade, como um todo, prosperarem. Já se destaca no mercado regional
como provedora de soluções tecnológicas, em particular soluções orientadas
para a Internet. Atualmente possui uma equipe de 11 pessoas (entre
desenvolvedores e sócios) e atua em três áreas de competência:
desenvolvimento de sistemas; serviços educacionais; e serviços de suporte à
decisão.

Introdução
Propósito do Documento
Um dos requisitos para a conclusão do curso de Bacharelado em Ciências da
Computação na Universidade Federal da Paraíba UFPB é a realização de um
estágio supervisionado com o objetivo de aprimorar os conhecimentos
adquiridos na universidade, colocando os mesmos em prática a fim de preparar
o aluno para a vida profissional.
Este documento tem como objetivo relatar os estudos feitos e as atividades
desenvolvidas pelo aluno Fábio Pereira Carneiro durante seu estágio, realizado
sob a supervisão de Mário Henrique Matos Alves (gerente de projetos da
NEUS – Tecnologia da Informação) e orientação do professor Hamilton Soares
da Silva.

Organização do Documento
O estágio realizado pelo aluno, assim como este documento, foi dividido em
três partes:
Aquisição de Conhecimento
Nesta etapa o aluno se dedicou a estudar as tecnologias, conceitos e
ferramentas que seriam utilizadas no projeto.
Desenvolvimento do Projeto
Foi estabelecida uma metodologia de desenvolvimento do projeto. Nesta parte
do documento será detalhado o processo utilizado para o desenvolvimento,
assim como o modelo de ciclo de vida do projeto que define analise, projeto,
implementação, testes e implantação.
Treinamento
O projeto consiste em estabelecer uma forma de abstração para o
desenvolvimento de softwares na empresa, portanto, seus usuários, os
desenvolvedores, precisam entender como funciona o NEUS BeanGen.
Para isso o aluno elaborou um treinamento com um exemplo didático que foi
ministrado pelo mesmo na empresa ao termino do projeto. Nesse treinamento
foram esclarecidas as interfaces necessárias para a utilização do NEUS
BeanGen.
Motivação
O projeto NEUS BeanGen se propõe a automatizar, usando geração de código,
a camada de Mapeamento Objeto Relacional de objetos Java em Bancos de
Dados Relacionais.
Para se entender a necessidade dessa automatização, será apresentada a
arquitetura de desenvolvimento utilizado na NEUS – Tecnologia da
Informação antes do NEUS BeanGen, ou seja, o “estado da arte”.

Estado da Arte – Arquitetura NEUS

A NEUS – Tecnologia da Informação possui uma arquitetura de
desenvolvimentos de software bem definida em 4 camadas como mostra a
Figura 1.
Figura 1 - Arquitetura em camadas usada na NEUS
O uso de uma arquitetura multicamadas traz diversos benefícios como o fato de

que o conceito “dividir para conquistar” é colocado em prática. Uma das
características mais importantes desse tipo de arquitetura é a independência das
camadas. Cada camada possui a uma interface bem definida que facilita a
substituição de camadas no caso de uma reengenharia. Por exemplo, se a
camada Data fosse trocada por outra, não seria necessário nenhuma
modificação nas camadas acima, desde que a nova camada Data que
substituiria a antiga implementasse a interface definida. É um tipo de “plug and
play” de software.
Nosso foco principal é nas camadas Business e Data. O Mapeamento Objeto
Relacional é realizado completamente na camada Data, a camada Business
estabelece uma interface comum para o acesso aos objetos através da
implementação do design pattern chamado Fachada (Facade). A camada
Business não enxerga tabelas, banco de dados relacional, chaves, etc; mas sim
enxerga objetos Java que são entregues a ela pela camada Data. Na camada
Business é onde se encontram todas as regras de negócio do software.
UFPB – Universidade Federal da Paraíba - 10 -

Percebeu-se que muito código dessas duas camadas era replicado em vários
lugares. Quando se fala em código replicado não significa que o código era
“igual”, mas significa dizer que a escrita de um código “parecido” era
necessário em diversos arquivos. Essa replicação era realmente necessária, ou
seja, não se tratava de algo que poderia ser abstraído com uso de herança ou
polimorfismo, mas sim replicações devido, principalmente ao uso da API
JDBC que disponibiliza uma interface SQL, portanto temos que mapear os
objetos em statements SQL. Mais adiante essas replicações serão detalhadas.
As replicações da camada Business ocorrem principalmente na Fachada que
estabelece uma interface única e centralizada às funcionalidades do sistema.
Foi determinado que as replicações de código eram necessárias e que uma
forma de evitar a escrita das mesmas seria a geração automática do código
replicado. Ou seja, a partir de um código seriam gerados as suas replicações.
Aquisição de Conhecimento
Para o desenvolvimento do projeto foi necessário o aprendizado, por parte do
aluno, tanto da arquitetura da empresa como de conceitos e tecnologias que
seriam usadas no projeto.
Mapeamento Objeto Relacional

Mapeamento Objeto Relacional (MOR – ou Object Relational Mapping ORM)
é o processo de transformar a representação de dados em uma linguagem
orientada a objetos para um banco de dados relacional (SGBD Relacional) e
vice-versa (Figura 2). Para isso se faz necessário o entendimento dessas duas
formas de representação dos dados, suas semelhanças e diferenças [FUSSEL].

Figura 2 – MOR – Mapeamento Objeto Relacional
Papel do Mapeamento Objeto Relacional (MOR) frente às linguagens de programação

orientadas a objetos (POO) e os Sistemas de Gerenciamento de Banco de Dados Relacionais
(SGBDR).
É importante ressaltar que não entraremos em detalhes a respeito dos conceitos

de cada uma das representações, mas sim na forma de fazer o mapeamento
entre elas. Portanto conceitos de POO como herança, composição e de SGBD’s
como chaves, tuplas serão abstraídos.
Programação Orientada a Objetos (POO)

O desenvolvimento de softwares está sendo, cada vez mais, realizado
utilizando linguagens de programação orientadas a objetos, devido aos seus
mecanismos facilitadores como herança, polimorfismo, composição que
resultam em grandes benefícios de reuso e manutenibilidade de código.
Java é a linguagem utilizada na empresa onde foi realizado o estágio. Possui o
paradigma de Orientação a Objetos assim como outros benefícios como
independência de plataforma, grande número de programadores e
conseqüentemente um muitas API’s disponíveis [ECKEL].

SGBD’s – Relacional x OO
Os Sistemas de Gerenciamento de Bancos de Dados (SGBD, ou Data Base
Management System DBMS) não evoluíram no mesmo sentido das linguagens
de programação. Foram desenvolvidos Bancos de Dados Orientados a Objetos,
mas a grande maioria dos softwares usa, como base de dados, Sistemas de
Gerenciamento de Banco de Dados Relacional (SGBDR – ou RDBMS) devido,
principalmente, a fatores de performance.
Os Bancos de Dados Relacionais armazenam as informações em forma de
tabelas que possuem relacionamentos entre si. Os relacionamentos são
conseguidos através do uso de “chaves” que referenciam outras tabelas.
OO x SGBD
Veremos algumas características da programação orientada a objetos e como
representá-las em um SGBD. Não veremos formas de fazer o mapeamento,
mas sim as duas representações isoladamente. [FUSSEL]
Composição – um objeto é composto de outro. Como exemplo
podemos citar o relacionamento entre as classes Pessoa e Cidade. Onde cada
Pessoa possui um objeto interno que significa a cidade onde nasceu. Vejamos o
código Java abaixo que representa essa associação:
Tabela 1 – Composição – Pessoa/CidadeNatal – Classes Java

Cidade.java Pessoa.java
class Cidade{ class Pessoa{

int codigo *; String cpf;
String nome; String nome;
int numeroHabitantes; Int idade;
(...) Cidade cidadeNatal;
} (...)
}
* A criação do atributo “código” na classe Cidade foi com o intuito de se ter uma chave
primária ao criarmos, posteriormente, uma tabela Cidade.

O comportamento da classe Cidade está encapsulado dentro da classe Pessoa.

SGBD’s não implementam composição, mas existe uma forma de se conseguir
representar uma composição em um SGBD através do conceito de Chaves
Estrangeiras que significa dizer que uma coluna de uma tabela deve ser chave
primária em outra.
A representação do exemplo acima em um SGBD se daria através da criação
de duas tabelas Pessoa e Cidade e de uma chave estrangeira entre elas.
Tabela 2 – Composição – Pessoa/CidadeNatal – Tabelas SGBDR

CIDADE PESSOA
CODIGO (CHAVE_PRIMARIA) CPF (CHAVE_PRIMARIA)
NOME NOME
NUMEROHABITANTES IDADE
CODIGOCIDADENATAL (CHAVE_EST)
Herança – dizer que uma classe A é filha da classe B, significa que A

herda todas as características da classe B. A grande intenção da herança é o
reuso de código. Como exemplo podemos citar a relação Veiculo – Táxi
Tabela 3 – Herança – Veiculo/Taxi – Classes Java

Veiculo.java Taxi.java
class Veiculo{ Class Taxi extends Veiculo{

String placa; String numeroTaximetro;
int anoFabricacao; (...)
int numeroPortas; }
(...)
}
Um objeto da classe Táxi possui placa, anoFabricacao e numeroPortas, pois

esses são campos da classe mãe.
Existem duas formas de representar herança em um SGBD:
1 – Criação de duas tabelas com chaves primárias em comum:

Tabela 4 – Herança – Veiculo/Táxi – Tabelas SGBDR

VEICULO TAXI
PLACA (CHAVE_PRIMARIA) PLACA (CHAVE_PRIMARIA)
ANOFABRICACAO NUMEROTAXIMETRO
NUMEROPORTAS
2 – Criação de uma tabela que possui todos os campos
TAXI
PLACA (CHAVE_PRIMARIA)
ANOFABRICACAO
NUMEROPORTAS
NUMEROTAXIMETRO
É importante ressaltar que na solução 1 para recuperar um TAXI do banco será

necessário um “join” entre as tabelas, tornando-se mais lento do que na solução
2. A escolha da solução 1 somente se justifica se for detectada a necessidade
de um acesso aos veículos, independentemente se é táxi ou outro objeto filho
de Veículo.
JDBC
JDBC (Java DataBase Connection) é uma interface padrão para acesso a
Bancos de Dados. Foi desenvolvido no nível de SQL, o que nos permite
construir statements SQL e embuti-los dentro de chamadas de uma API Java.
É através do uso dessa interface JDBC que é feito o Mapeamento Objeto
Relacional. [java.sun. com]
Uma classe chamada Driver JDBC controla todo o acesso ao banco. O usuário
da API JDBC somente “enxerga” comandos SQL. Cada Banco de Dados
possui o seu Driver JDBC.
Através desse Driver consegue-se uma conexão (java.sql.Connection) como
banco. Essa Connection nos fornece um Statement que ao serem executados
resultam em ResultSet (conjunto de resultados que representa a tabela de
retorno de um SELECT por exemplo). Abaixo está um exemplo retirado do
livro “Thinking in Java” (Bruce Eckel)

Tabela 5 – Lookup.java - Exemplo de uso da API JDBC

//: c15:jdbc:Lookup.java
// From 'Thinking in Java, 2nd ed.' by Bruce Eckel
// www.BruceEckel.com. See copyright notice in CopyRight.txt.
// Looks up email addresses in a
// local database using JDBC.
import java.sql.*;
public class Lookup {

public static void main(String[] args)
throws SQLException, ClassNotFoundException {
String dbUrl = "jdbc:odbc:people";
String user = "";
String password = "";
// Load the driver (registers itself)
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection c = DriverManager.getConnection(dbUrl, user, password);
Statement s = c.createStatement();
// SQL code:
ResultSet r = s.executeQuery("SELECT FIRST, LAST, EMAIL " +
"FROM people.csv people " +
"WHERE " +
"(LAST='" + args[0] + "') " +
" AND (EMAIL Is Not Null) " +
"ORDER BY FIRST");
while(r.next()) {
System.out.println(r.getString("Last") + ", "
+ r.getString("First")
+ ": " + r.getString("EMAIL") );
}
s.close(); // Also closes ResultSet
}
} ///:~

Geração de Código
Detectou-se a necessidade em duas camadas da arquitetura usada na NEUS –
Tecnologia da Informação, a presença de muito código que podia ser derivado
de outro. Chamou-se esse código que poderia ser derivado de Código
Derivável por Geração (CDG). Ele pode ser derivado de uma Raiz de Geração
de Código (RGC). Abaixo vemos um exemplo de RGC e CDG.
Tabela 6 – RGC X CDG

RAIZ DE GERAÇÃO DE CÓDIGO CÓDIGO DERIVÁVEL POR
R GC GERAÇÃO CDG
public class Pessoa { public class PopuladorMapPessoa{
private String nome; public void fill(Object obj, Map map){
public String getNome() { Pessoa objPessoa = (Pessoa) obj;
return this.nome; map.put("nome", objPessoa.getNome());
} }
public void setNome(String nome) { }
this.nome = nome;
}
}
RAIZ DE GERAÇÃO DE CÓDIGO CÓDIGO DERIVÁVEL POR

R GC GERAÇÃO CDG
public class Veiculo { public class PopuladorMapVeiculo{
private String placa; public void fill(Object obj, Map map){
public String getPlaca() { Veiculo objVeiculo = (Veiculo) obj;
return this.placa; map.put("placa", objVeiculo.getPlaca());
} }
public void setPlaca(String placa) { }
this.placa = placa;
}
}

Esse dois exemplos retratam bem os conceitos de RGC e CDG. Isso ocorre
porque foi estabelecido um padrão de código. A partir de então, ao se fornecer
outro código RGC pode-se derivar o seu respectivo CDG.
O XDoclet é uma ferramenta que auxilia no processo de percorrer a RGC
resultando no seu CDG. Para trabalhar com XDoclet faz-se necessário o
entendimento de outra ferramenta chamada ANT.
ANT
O ANT é uma ferramenta desenvolvida pela Jakarta (projeto Apache / Sun)
para automatização de tarefas de construção de software utilizando classes Java
e arquivos XML ao invés de uma comunicação direta com o Shell do sistema
operacional. [ant.apache.org]
Existem algumas definições para a sigla ANT, uma delas é Another Neat Tool,
que significa “Mais uma ferramenta perfeita”; outra definição é associar o
nome ANT ao seu significado do inglês “formiga”, no sentido de que o ANT é,
assim como a formiga, pequeno, mas com um grande “poder”.
O ANT funciona em torno do conceito de tarefas. Vejamos um exemplo:
Suponha um software simples que está organizado em dois diretórios:
src – código fonte do projeto (arquivos .java)
bin – código compilado (arquivos .class)
O processo de construção, chamado build, desse software exemplo consiste
nas tarefas:
clean – limpar o diretório de código compilado, ou seja, apagar o
diretório bin e criá-lo novamente.
compile – compilar o código que está em src e jogar os arquivos
compilados no diretório bin.
Existem algumas formas de automatizar esse processo de build. Uma delas é
fazer um arquivo “.bat”, caso o sistema operacional utilizado seja Windows,
que realiza as duas tarefas:

Tabela 7 – Arquivo “.bat” para build simples

rmdir /s /q bin
md bin
javac -d bin src\com\python\ia\wilson\*.java
Essa solução funciona, mas deixa o programador preso à plataforma Windows.

Se surgir a necessidade desse software, que está escrito em Java, ser construído
em um ambiente Linux, esse arquivo.bat não funcionará. Será necessária a
criação de outro arquivo com comandos do Shell do Linux para a realização
dessas mesmas “tarefas”.
O ANT foi desenvolvido para unificar o processo de build de uma aplicação
visto que a ferramenta em si é desenvolvida em Java e, portanto, independente
de plataforma.
É baseada em arquivos XML onde faz o mapeamento do conceito visto
anteriormente de “tarefas” através da tag <target>. O build citado acima
poderia ser feito em um arquivo XML do ANT da seguinte forma:
Tabela 8 – Arquivo do ANT - build.xml

<?xml version="1.0" encoding="UTF-8"?>
<project basedir="." default="compile" name="HelloWorldANT">
<property name="dir.src" value="src"/>

<property name="dir.bin" value="bin"/>

<target name="clean">
<delete dir="${dir.bin}"/>
<mkdir dir="${dir.bin}"/>
</target>

<target name="compile"
depends="clean">
<javac
srcdir="${dir.src}"
includes="com/**/*.java"
destdir="${dir.bin}"
debug="off"

optimize="on"
failonerror="true"
>
</javac>
</target>
</project>
Existe o conceito de dependência de tarefas, ou seja, ao se tentar executar a

tarefa “compile”, que é a tarefa default do exemplo acima, nota-se que ela
depende da tarefa “clean”. Essa dependência é expressa através do atributo
“depends”. Portanto, antes de executar a tarefa compile, o ANT executa a(s)
tarefa(s) de dependência. Esse arquivo poderia ser executado através da
seguinte linha de comando:
No diretório onde está o arquivo build.xml e os diretórios bin e src:
. . . > ant <ENTER>
O ANT procura um arquivo chamado build.xml no diretório atual. Se o

arquivo tivesse outro nome como meuArquivoDeBuild.xml, a chamada
deveria ser:
. . . > ant –buildfile meuArquivoDeBuild.xml <ENTER>
Outro detalhe a ser citado é que se a tarefa não for especificada na chamada do
ANT, a tarefa chamada é a definida como default na tag:
<project default="compile"...>
Uma forma de chamar a tarefa “clean” por exemplo, seria:
. . . > ant clean <ENTER>
Ou se o arquivo fosse o meuArquivoBuild.xml
. . . > ant –buildfile meuArquivoDeBuild.xml clean <ENTER>

Alguns IDE’s, como é o caso do NetBeans são integrados com o ANT de

forma que pode-se executar um arquivo de build a partir de um duplo clique
em um arquivo build.xml por exemplo.
XDoclet
O que é?
XDoclet é uma ferramenta de geração de código. Pode-se adicionar mais
significado ao seu código através de meta-dados que são representados através
de tags semelhantes às do JavaDoc, que gera arquivos html de documentação
para o código Java. [xdoclet.sourceforge.net]
XDoclet X JavaDoc
A grande diferença do XDoclet para o JavaDoc é que o último possui suas tags
pré-definidas que são colocadas nas classes, atributos e métodos. Alguns
exemplos dessas tags são: @author, @version, @param, @return. E a sua saída
também é pré-definida, ele gera somente arquivos html com um formato que
não pode ser alterado. Enquanto que o XDoclet disponibiliza a criação das
nossas próprias tags, por exemplo @minhaTag1, @minhaTag2; e, além disso,
pode-se gerar qualquer arquivo a partir das raízes com essas tags. Veja Figura 3
Figura 3 – XDoclet X JavaDoc
Arquivos “.html”
Arquivos “.java”
@author, @param,
@Return
JAVADOC
Arquivos quaisquer “.XXX”

Arquivos “.java”
@minhaTag1
@MinhaTag2
XDOCLET

O exemplo abaixo mostra como funciona o uso das tags JavaDoc: A classe
HelloWorld (arquivo HelloWorld.java) foi comentada com as tags JavaDoc
@author que é uma tag de classe, portanto colocada logo antes da definição da
classe e a tag de método @param que explica a função de um parâmetro do
método. Logo abaixo pode-se ver o resultado em html gerado pelo JavaDoc.
Tabela 9 – Exemplo XDoclet - HelloWorld.java

/** @author Fabio Pereira */
public class HelloWorld {
/** @param args argumentos passados na linha de comando */
public static void main(String[] args) {
System.out.println("HelloWorld");
}
}
Ao passar esse arquivo pelo JavaDoc serão gerados arquivos html:
Tabela 10 – HTML Gerado pelo JavaDoc

Class HelloWorld
java.lang.Object
HelloWorld
public class HelloWorld

extends java.lang.Object
author: Fábio Pereira

(...)
Method Detail
Main
public static void main(java.lang.String[] args)
Parameters:
args - argumentos passados na linha de comando

Nesse caso o arquivo HelloWorld.java funcionou como raiz RGC e o html

como derivável CDG.
Integração com ANT

O XDoclet é completamente integrado com o ANT, na verdade, ele não só é
integrado como é dependente. Atualmente o XDoclet só funciona através do
ANT.
A geração de código do XDoclet é feita através de tarefas do ANT. Mais a
seguir será mostrado um exemplo.
XDoclet Template (arquivo.xdt)

Quando temos uma Raiz de Geração de Código RGC e queremos a partir dela
gerar um Código Derivável por Geração CDG, devemos estabelecer o “formato
modelo” desse CDG, esse formato é definido através de um arquivo chamado
template.
Esse template é um arquivo com a extensão XDT (XDoclet Template) que
possui tags XML do tipo: <XDtClass:className /> Essa tag iria ser
transformada no nome da classe da RGC.
As tags de templates tem o seguinte formato:
Tag sem corpo:
<XDt(NAMESPACE):(TAG_NAME)/>
Tag com corpo:
<XDt(NAMESPACE):(TAG_NAME)/>
(CORPO DA TAG)
</XDt(NAMESPACE):(TAG_NAME)>
O Namespace define que tipo de tag é essa, que pode ser de classe, de método,
de atributo ou uma tag customizada. Tagname é o nome da tag.
Existem dois tipos de tags usadas nos templates:
Block Tags – são tags que simulam instruções de controle de fluxo de uma
linguagem de programação do tipo if, for, etc. São exemplos: forAllClasses,

forAllMethods, ifIsClassAbstract, ifHasMethodTag. Essas tags geralmente não

possuem corpo.
Content Tags – são tags que se transformarão em texto. Quase que como uma
macro de substituição. className, methodName, methodType, etc. Essas tags
geralmente possuem corpo.
É importante diferenciar tags do XDoclet que são tags colocadas na
documentação das classes das tags dos templates:
Tags do XDoclet (Pessoa.java) Tags dos Templates XDT (info.xdt)
/** @minhaTagAuthor João */ <XDtClass:forAllClasses>

Classe - <XDtClass:className />
public class Pessoa {
</XDtClass:forAllClasses>
(. . .)
Tag Handlers
O XDoclet possui uma grande quantidade de tags de templates definidas como
é o caso dos exemplos vistos anteriormente: forAllClasses, className,
methodName, etc. Mas existem ocasiões onde há a necessidade de criação das
nossas próprias tags. Por exemplo, se quisermos uma tag para indicar no
arquivo gerado a data da geração, poderíamos criar o nosso próprio namespace
“meuNamespace” e um taghandler, que nada mais é do que uma classe Java
filha da classe xdoclet.XDocletTagSupport com métodos que representam as
tags. A nossa tag da data poderia ser chamada de minhaTagDataAtual. Logo
deveria ser criado uma classe TagHandler e citá-la no arquivo xdoclet.xml que
é o arquivo de configuração da geração. O arquivo xdoclet.xml pode ser
comparado ao web.xml em uma aplicação web.

Tabela 11 – Criação de uma Tag própria

MeuTagHandler.java xdoclet.xml
package com. taghandler;
import xdoclet.XDocletTagSupport; <xdoclet-module>
/** <taghandler
namespace="meuNamespace"
*@xdoclet.taghandler
class="com.taghandler.MeuTagHander"
namespace="meuNamespace" />
*/ </xdoclet-module>
public class MeuTagHandler
extends XDocletTagSupport{
public String minhaTagDataAtual()

{
return = "" + new Date();
}
Geração (1 – 1) X (N – 1)
XDoclet disponibiliza duas formas de geração, essas duas se caracterizam pelo
fato de que na geração 1 – 1 a partir de cada arquivo RGC será gerado um
correspondente CDG. Enquanto que na geração N – 1 é gerado apenas um
arquivo CDG a partir de vários arquivos RGC.
Exemplo
Vamos gerar o CDG abaixo a partir da RGC dada:

Tabela 12 – Raiz de Geração de Código RGC

Pessoa.java Veiculo.java
/** /**
* @minhaTagAuthor Autor da Classe Pessoa * @minhaTagAuthor Autor da Classe Veiculo
*/ */
public class Pessoa { public class Veiculo {
private String nome; private String placa;
public String getNome() { public String getPlaca() {
return this.nome; return this.placa;
} }
public void setNome(String nome) { public void setPlaca(String placa) {
this.nome = nome; this.placa = placa;
} }
} }
CÓDIGO DERIVÁVEL POR

GERAÇÃO CDG
infoClasses.txt
Classe – Pessoa
Autor – Autor da Classe Pessoa
Metodos:
getNome
setNome
Classe – Veiculo
Autor – Autor da Classe Veiculo
Metodos:
getPlaca
setPlaca
O exemplo tem como CDG um arquivo txt com o intuito de demonstrar que
não necessariamente “código” pode ser gerado, mas sim qualquer arquivo.

Os arquivos a serem criados são: template e build.xml. Não necessitamos de

um TagHandler pelo fato de que com as tags existentes nos namespaces Class e
Method pode-se conseguir a geração desejada.
infoTemplate.xdt
<XDtClass:forAllClasses>
Classe - <XDtClass:className />
Autor - <XDtClass:classTagValue tagName="minhaTagAuthor" />
Metodos:
<XDtMethod:forAllMethods>
<XDtMethod:methodName />
</XDtMethod:forAllMethods>
</XDtClass:forAllClasses>
build.xml

<project basedir="." default="all" name="deprecation">
<property name="dir.raiz" value="." />

<property name="dir.lib" value="${dir.raiz}\lib" />
<property name="dir.dest" value="${dir.raiz}\generatedFiles" />
<property name="dir.src" value="${dir.raiz}\src" />
<property name="dir.bin" value="${dir.raiz}\bin" />
<property name="dir.build" value="${dir.raiz}" />

<property name="dir.templates" value="${dir.raiz}\templates" />
<property name="nomeTemplateInfo" value="infoTemplate.xdt" />




<path id="classpath.lib.xdoclet">
<fileset dir="${dir.lib}">
<include name="**/*.jar"/>
</fileset>
<pathelement path="${dir.build}/"/>
</path>




<target name="infoClasses"
description="Gera o arquivo.">
<taskdef name="taskInfoClasses"

classname="xdoclet.DocletTask">
<classpath refid="classpath.lib.xdoclet"/>
</taskdef>
<taskInfoClasses
destdir="${dir.dest}">
<fileset dir="${dir.src}">
<include name="**/*.java"/>
</fileset>
<template
templateFile="${dir.templates}/${nomeTemplateInfo}"
destinationFile="infoClasses.txt"
/>
</taskInfoClasses>
</target>




<target name="clean">
<delete dir="${dir.dest}"/>
<delete dir="${dir.bin}"/>
<mkdir dir="${dir.dest}"/>
<mkdir dir="${dir.bin}"/>
</target>




<target name="all" depends="clean, infoClasses" />
</project>
Esse foi um exemplo de geração (N – 1). Se quiséssemos um arquivo de

informação para cada classe, ou seja, geração (1 – 1), pouca coisa mudaria.
Somente deveríamos retirar a tag <XDtClass: forAllClasses/> do template, pois
já que será um arquivo para cada RGC o engenho do XDoclet já percorre as
classe. E a outra mudança principal seria o atribto
destinationFile=”infoClasses.txt” do build.xml ele deveria ser alterado para:
destinationFile=”infoClass{0}.txt”, onde {0} será substituído pelo nome do
arquivo correspondente. Portanto seriam gerados dois arquivos a partir da RGC
dada:

Tabela 13 – Geração 1 – 1
infoClassPessoa.txt infoClassVeiculo.txt
Classe – Pessoa Classe – Veiculo
Autor – Autor da Classe Pessoa Autor – Autor da Classe Veiculo
Metodos: Metodos:
getNome getPlaca
setNome setPlaca

Desenvolvimento do Projeto
Metodologia
Engenharia de Software é uma tecnologia em camadas como mostra a Figura 4.

Figura 4 – Camadas da Engenharia de Software
O grande objetivo da Engenharia de Software é garantir a qualidade do que se

é desenvolvido. As outras camadas estão apoiadas no foco na qualidade. Essa
qualidade somente é conseguida estabelecendo-se padrões para o
desenvolvimento. [PRESSMAN]
Um processo de software define um conjunto de atividades a serem realizadas,
com responsabilidades, artefatos de entrada e saída, dependências e ordem de
execução e modelo de ciclo de vida. Um método é a descrição sistemática de
como deve-se realizar essas atividades. Essa descrição é geralmente feita
através de padrões. Os métodos abrangem um amplo conjunto de tarefas que
inclui análise de requisitos, projeto, implementação, teste e manutenção.
A metodologia é a união de métodos e processo.

Processo
Planejamento
O planejamento de um software consiste em realizar as atividades de definição
do escopo, definição de recursos, análise de riscos, definição de métricas e
elaboração de cronograma. O aluno acompanhou, para um maior aprendizado
do processo como um todo, o planejamento do NEUS BeanGen, gerido
principalmente pelo seu supervisor Mário Henrique Matos Alves, que é o
gerente de projetos da empresa e, portanto, o responsável por essa tarefa.
A seguir serão citadas as etapas do planejamento com um resumo sobre cada
uma delas.
Escopo
A definição do escopo de um software consiste em chegar a respostas básicas
sobre às perguntas citadas abaixo:
Quem são os usuários do software e qual o

ambiente utilizado?
O NEUS BeanGen será utilizado para a automatização dos desenvolvimento
dos sistemas da NEUS e portanto será utilizado na própria empresa pelos seus
desenvolvedores.
Problemas que o Software irá resolver?

O NEUS BeanGen se propõe a gerar arquivos que, na sua ausência, seriam
escritos por programadores. Portanto, o programador não precisará escrever um
código parecido em vários lugares se preocupando com a concordância dos
mesmos.
A correção de erros do código se torna mais fácil devido ao fato de que se um
problema ocorrer, sabe-se que ele está nos arquivos de Raiz de Geração, a
correção é feita nesses arquivos e os seus derivados serão gerados novamente.
Mais adiante será explicado o conceito de arquivos de Raíz de Geração e
arquivos derivados.

Quais benefícios o software trará?

Pelo fato do NEUS BeanGen diminuir o esforço necessários por parte dos
programadores no desenvolvimento de softwares, a empresa terá uma
necessidade menor de recursos humanos para cada software que for
desenvolvido a partir de então.
Recursos
Os recursos utilizados foram divididos em três tipos: humanos, hardware e
software.
Humanos
Os recursos humanos definem quem são as pessoas envolvidas no projeto do
software. No caso do NEUS BeanGen:
Cargo Funções no projeto NEUS BeanGen
Gerente Sênior Define aspectos do negócio Édrei Barbosa

que tem influência no projeto
Gerente de Projeto Planeja, motiva, organiza e Mário Henrique Matos Alves

controla as pessoas
envolvidas
Desenvolvedor Tem habilidades técnicas Fábio Pereira Carneiro

para desenvolver o software
Cliente Especifica os requisitos NEUS – Tecnologia da

Informação
Usuário Final Usa o software Programadores da NEUS

Hardware
Foram utilizadas duas máquinas com a seguinte descrição:
Processador: Pentium 4 de 1.6 GHz
Memória RAM: 512Mb
HD: 40Gb
Software
Foram utilizados os softwares:
Sistema Operacional: Windows 2000
IDE (Integrated Development Environment): NetBeans
Softwares de apoio: XDoclet, Máquina Virtual Java da Sun (JVM), WinCVS.
Riscos
Riscos são características que possam vir a dificultar o projeto. Existem três
etapas na análise de riscos:
Identificação: elicitar os riscos e categorizar cada um deles como risco de
negócio, de projeto ou técnico.
Estimativas: estimar a probabilidade de sua realidade e qual seria o impacto
sobre o projeto caso ele se tornasse real.
Administração: consiste em encontrar uma solução para diminuir ou acabar
com o impacto do risco caso ele realmente se concretize.
Abaixo está a tabela de análise de riscos do NEUS BeanGen.

Identificação Impossibilidade de gerar algum dos arquivos necessários com a tecnologia

disponibilizada através do XDoclet.
Risco Técnico
Estimativas Impacto Atraso no cronograma, ou até mesmo a não

implementação de algum requisito
Probabilidade Moderado
Administração Procurar uma tecnologia diferente para implementar.
Identificação Não aprendizado das tecnologias necessárias para o projeto
Risco Técnico
Estimativas Impacto Atraso no cronograma
Probabilidade Moderado
Administração Inserir outra pessoa no projeto.
Identificação Restrição por parte dos programadores em usar o BeanGen
Risco de Negócio
Estimativas Impacto Dificuldade de implantação na empresa
Probabilidade Improvável
Administração Incentivar o uso através de palestras na empresa.

Métricas
O processo de medir software tem o objetivo de estimar o tamanho do mesmo
para facilitar estimativas de esforço (pessoa-mês) e cronograma.
As medições feitas no NEUS BeanGen foram através dos arquivos a serem
gerados. Para cada arquivo a ser gerado foi dado um nível de complexidade e
para cada nível de complexidade (NC) foi estimado um esforço. A tabela
abaixo ilustra as medições:
CAMADA DATA CAMADA BUSINESS

Arquivo N NC Arquivo N NC
coleção{0}.xml 1 3 ComplementoFachada.java 1 2
ComandoRepositorio{0}JDBC.java 2 2 ComplementoFachadaComColecao.java 2 2
ComplementoRepositorio{0}.java 3 3 FachadaComposta.java 3 4
createTable.sql 4 1
createPrimaryKey.sql 5 1
createForeignKey.sql 6 3
createIndex.sql 7 1
dropTable.sql 8 1
TOTAL 15 TOTAL 8
A cada arquivo foi criado um numero identificador, no cronograma o arquivo

será referenciado através da primeira letra da camada ao qual pertence seguido
do seu identificador. Por exemplo, (createIndex.sql = D7),
(FachadaComposta.java = B3)
Baseado em um exemplo teste do XDoclet de desenvolvimento de geração de
um arquivo, foi estimado um esforço de 6 horas por nível de complexidade
(HN) de complexidade. Portanto, o tempo total de desenvolvimento (TD) é
calculado como:
TD = HN * ∑NC = 6 * (15 + 8) = 138 horas
TD = (34,5 dias) * (4 horas / dia)

TD = (6,9 semanas) * (5 dias / semana)

Cronograma
O cronograma representa os prazos do projeto. Quando as tarefas começam e
quando terminam. Baseado nas métricas citadas anteriormente foi criado o
seguinte cronograma para o projeto NEUS BeanGen.
Estimativa de Tempo
Planejamento
Análise
Projeto
Implementação
Testes
Implantação
Manutenção
0 1 2 3 4 5
Tempo (em mêses)
Modelo de Ciclo de Vida

Existem diversos modelos que definem combo será o ciclo de vida do
desenvolvimento do software, cada um possuindo suas vantagens e
desvantagens. Os modelos mais conhecidos são: Modelo Clássico ou em
Cascata, Modelo Evolucionário que se divide em Programação Exploratória e
Prototipação ou Prototipagem, Modelo de Transformação Formal ou
Refinamento, Modelo Espiral e o paradigma 4GT ou Técnicas de Quarta
Geração.
O projeto NEUS BeanGen não consiste em um software comum. Ele se propõe
a formar, juntamente com a arquitetura da NEUS, um framework para
desenvolvimento de outros softwares, ainda assim, o projeto usou dos padrões
estabelecidos pela ES para garantir sua qualidade.
Para o seu desenvolvimento foi utilizado o Modelo Cascata com alguns ajustes
devido ao fato já citado acima do projeto não ser comum. Duas características

do projeto foram definitivas na escolha do modelo em cascata, se essas

características estiverem presentes no projeto, aconselha-se o uso desse
modelo, são elas:
Requisitos bem compreendidos – o NEUS BeanGen tem como
clientes os programadores que usam a arquitetura da NEUS. Logo a definição
de requisitos seria feita por programadores que conhecem bem a arquitetura e
tem a capacidade de definir os requisitos para a automatização da mesma. Essa
característica é importante pois o modelo em cascata não fornece facilidade
para uma mudança posterior nos requisitos.
Alta interação com cliente – os “clientes” do NEUS BeanGen somos
nós programadores, isso traz uma maior facilidade na análise dos requisitos,
pois haverá uma quebra da barreira de comunicação programador-cliente.
Conseqüentemente a interação com o “cliente” será alta devido ao fato de que
ele somos nós.
O Modelo Cascata está ilustrado na Figura 5:
Figura 5 – Modelo de Ciclo de Vida Cascata
Definição dos
requisitos
Projeto do
Sistema
Implementação
Teste
Manutenção
Documentação
A principal característica do modelo em cascata é que as diferentes etapas do

desenvolvimento seguem uma seqüência: a saída da etapa atual flui para a
etapa posterior. Tem a vantagem de só avançar para a etapa seguinte quando a
etapa atual for avaliada pelo “cliente”. No caso do NEUS BeanGen isso foi

uma vantagem pelo fato de que o programador, que é o cliente, avalia a etapa
antes de passar para a próxima.
Análise de Requisitos
Segundo o IEEE a definição de Análise de Requisitos é:
“Processo de aquisição, refinamento e verificação das necessidades do
cliente com o objetivo de obter uma especificação correta e completa dos
requisitos”
Os clientes do NEUS BeanGen eram os próprios desenvolvedores da empresa,
portanto o processo de análise de requisitos se deu através de reuniões entre os
mesmos para identificar necessidades. Necessitava-se de geração de arquivos
considerados deriváveis, portanto, foram elicitados todos os arquivos que
poderiam ser gerados.
Estudo de Viabilidade
Nessa etapa deve-se verificar se o projeto é realmente factível, isso inclui um
estudo de viabilidade de custos e viabilidade técnica. O aluno foi o responsável
pelo estudo de viabilidade técnica procurando tecnologias disponíveis para
geração de código e verificando se elas atendem as necessidades do projeto.
Nessa etapa o aluno adquiriu conhecimentos suficientes sobre geração de
código, ferramentas e API’s para o desenvolvimento do projeto. Essas
tecnologias foram detalhadas na introdução deste documento.
Projeto do Sistema
Projeto é uma representação de engenharia de algo que será construído
posteriormente. Basicamente foram realizadas as tarefas de definição das
estruturas de dados, arquitetura do software e definição das interfaces.
Estruturas de Dados
Os “dados” maipulados pelo NEUS BeanGen são arquivos com código Java
comentado com suas devidas tags XDoclet. Não há armazenamento de

informações. Nessa fase de projeto deve-se representar os dados a nível do

usuário. Foram definidos os formatos dos arquivos raízes as tags que serão
utilizadas em cada um dos arquivos. O seu detalhamento será mostrado
posteriormente.
Arquitetura do Sistema
Arquitetura é a forma como as várias partes do software são integradas para
formar um total coeso. Ou seja, deve-se definir os módulos do software e suas
interligações. A definição abaixo foi dada por Jarrold Grochow:
“A arquitetura de um sistema é um arcabouço abrangente que descreve sua
forma e estrutura, seus componentes e como eles se articulam”
Jerrold Grochow
O projeto NEUS BeanGen está apoiado sobre a arquitetura da NEUS.
Basicamente em cima das duas camadas que necessitam de geração de código
para o Mapeamento Objeto Relacional que são Data e Business. Para cada uma
dessas camadas foi feito um modelo com sub-camadas de geração de acordo
com a especificação do XDoclet para geração de código, ou seja, para cada
camada da NEUS foi definido um TagHandler, um conjunto de templates e
uma tarefa ant que execute essa geração. Essa arquitetura está na Figura 6.
Figura 6 – Arquitetura do NEUS BeanGen

Interfaces do Sistema
A comunicação Usuário – NEUS BeanGen será realizada através de scripts
ANT. Nesses scripts são estabelecidos os diretórios de origem e de destino para
os arquivos. Portanto a interface de entrada para o NEUS BeanGen será uma
tarefa ANT para cada camada da NEUS (Data e Business). Para essa tarefa
ANT deve-se estabelecer um local onde estão os arquivos Raiz de Geração de
Código que chamaremos de NEUS Beans contendo as devidas tags que serão
detalhadas posteriormente.
Uma das grandes características do NEUS BeanGen é o seu alto nível de
abstração, portanto o usuário terá uma interface simples que esconde ao
máximo os detalhes da geração do código.
O resultado da geração será a geração de toda a camada Data e parte da
camada Business. A partir de então o usuário disponibilizará de uma Fachada
do sistema que está desenvolvendo usando o NEUS BeanGen com acesso a
todos os objetos do sistema que estão armazenados em um banco de dados, que
para ele se torna transparente.
Os métodos da Fachada serão a interface que o usuário irá usar a partir de
então para programar. Para cada entidade com persistência no banco de dados,
que chamaremos mais adiante de NEUS Bean, existirão métodos de acesso
(filtrar, get, soma, mínimo, maximo, etc), cadastro(cadastrar) e
alteração(alterar) na Fachada. O detalhamento dos métodos da Fachada foge
ao escopo do projeto NEUS BeanGen que consiste em gerar arquivos onde um
desses arquivos é a Fachada do sistema. Após a geração de todos os arquivos,
essa Fachada será um dos arquivos mais importantes por ser o ponto através do
qual o usuário (programador) terá acesso as funcionalidades do sistema. Mas
ela se torna importante para o desenvolvimento pós-geração de código, ou seja,
dentro da arquitetura de desenvolvimento.
A figura abaixo mostra uma visão macro do NEUS BeanGen com suas
entradas e saídas.

Figura 7 – Interfaces do NEUS BeanGen
Implementação
A implementação do NEUS BeanGen consistiu em criar, para cada arquivo que
deveria ser gerado os seguintes artefatos: template, tags no TagHander, tarefa
ANT. E finalmente uma tarefa ANT que unificasse a geração da camada Data e
outra para a camada Business.
Devido a fatores de sigilo de código da empresa, não serão mostrados todos os
arquivos gerados, mas sim apenas um deles.
Geração de Arquivo Exemplo

Para cada objeto Java que deve ser persistente no banco de dados, ou seja,
cujos dados devem permanecer gravados em uma tabela no banco, deve-se

criar um arquivo que faz o mapeamento do objeto em sua SQL mapeamento

Objeto-Tabela,Tabela-Objeto. O arquivo ComandoRepositorio{0}JDBC.java
é o espelho do objeto em uma tabela no banco de dados. Ele possui métodos
para mapear a SQL de cadastro, alteração, set dos campos do objeto através de
um resultSet que consiste em uma linha da tabela no banco .
Vejamos como seria o arquivo ComandoRepositorioPessoaJDBC.java para a
classe Pessoa com os campos nome e idade. Por serem desnecessários, serão
ocultados os comandos import nos códigos mostrados.
É importante citar que o escopo do desenvolvimento do NEUS BeanGen não é
entender como esse arquivo funciona mas sim saber que ele existe, que pode
ser derivado do bean Pessoa e quais as tags do XDoclet que fazem com que
esse arquivo seja gerado.
RGC – Pessoa.java
public class Pessoa extends IntegerChaveImpl{

// CAMPO NOME
private String nome;
public String getNome() {return this.nome; }
public void setNome(String nome) {this.nome = nome;}
// CAMPO IDADE
private int nome;
public int getIdade() {return this.idade; }
public void setIdade(int idade) {this.idade = idade;}
}
CDG – ComandoRepositorioPessoaJDBC.java
public class ComandoRepositorioMunicipioJDBC extends
ComandosRepositorioAbstratoJDBC
{
public void cadastrar(ObjetoChave objeto, PreparedStatement ps)
throws SQLException
{
Pessoa objetoPessoa = (Pessoa) objeto;
SetadorPreparedStatement setador
= new SetadorPreparedStatement(ps);
setador.set(objetoPessoa.getCodigo(), false);

setador.set(objetoPessoa.getNome(), false);
setador.set(objetoPessoa.getIdade(), false);
}
public void alterar(ObjetoChave objeto, PreparedStatement ps)

throws SQLException
{
SetadorPreparedStatement setador = new
SetadorPreparedStatement(ps);
setador.set(objetoPessoa.getNome(), false);
setador.set(objetoPessoa.getIdade(), false);
setador.set(objetoPessoa.getCodigo(), false);
public void setObjeto(ObjetoChave objeto, ResultSet rs)

throws SQLException
{
int campocodigo = rs.getInt("IDPESSOA");

objetoPessoa.setCodigo(campocodigo);
String camponome = rs.getString("nome");

objetoPessoa.setNome(camponome);
int campoidade = rs.getString("idade");

objetoPessoa.setIdade(campoidade);
public ObjetoChave criarObjeto()

{
return new Pessoa();
}
}
Ao analisar esses dois arquivos nota-se que o segundo é totalmente derivável

através do primeiro. Portanto deve-se estabelecer um modelo de geração
através de um template XDoclet para ele.
Template – comandoRepositorioTemplate.xdt
public class ComandoRepositorio<XDtNeusClass:className/>JDBC extends
ComandosRepositorioAbstratoJDBC
{
public void cadastrar(ObjetoChave objeto, PreparedStatement ps)
throws SQLException
{
<XDtNeusClass:className/> objeto<XDtNeusClass:className/> =
(<XDtNeusClass:className/>) objeto;

<XDtNeusData:
instrucoesSetarPSComandoRepositorioSuperclassesForaDoProjeto />
<XDtMethod:ifHasMethodTag tagName="neus.isColumn">
<XDtNeusData:setarPSComandoRepositorioMetodoGetter />
</XDtMethod:ifHasMethodTag>
}
public void alterar(ObjetoChave objeto, PreparedStatement ps)

throws SQLException
{

<XDtNeusData:
instrucoesSetarPSCamposNotPrimaryKeyComandoRepositorioSuperclassesForaDoProjeto />
<XDtMethod:ifHasMethodTag tagName="neus.isNotPrimaryKey">
<XDtNeusData:instrucoesSetarPSCamposPrimaryKeyComandoRepositorioSuperclassesForaDoProjet
/>
<XDtMethod:ifHasMethodTag tagName="neus.isPrimaryKey">
}
public void setObjeto(ObjetoChave objeto, ResultSet rs)

throws SQLException
{
<XDtNeusData:
instrucoesSetarObjetoComandoRepositorioSuperclassesForaDoProjeto/>
<XDtNeusData:setarObjetoComandoRepositorioMetodoGetter />
}
public ObjetoChave criarObjeto()

{
return new <XDtNeusClass:className/>();
}
Notemos que algumas das tags usadas no template não são tags de namespaces
já definidos pelo XDoclet que são Class, Method, etc. Um exemplo de uma tag
definida pelo NEUS BeanGen é
<XDtNeusData:setarObjetoComandoRepositorioMetodoGetter />
Para o uso dessa tag foi necessária a criação de um TagHandler com o
namespace NeusData. Criação de TagHandler já foi explicado enquanto
detalhava-se o funcionamento do XDoclet, portanto aqui será mostrado apenas
uma parte do NeusDataTagHandler.java.
TagHandler – NeusDataTagHandler.java
/**
* @xdoclet.taghandler namespace="NeusData"
*
*/
public class NeusDataTagHandler extends NeusTagHandlerAbstract
{
(...)
public String setarObjetoComandoRepositorioMetodoGetter(

Properties attributes)
{
String str = "";
String nomeClasse = getNomeClasseAtual();
String nomeObjeto = "objeto" + nomeClasse;
boolean isComposto = !(isJavaType(tipoRetornoFullMetodo()));

String tipo = "";
String nomeCampo = nomeCampoMetodoGetter();
String nomeColuna = nomeCampo;
if (isComposto)
{
tipo = tipoRetornoFullMetodo();
nomeColuna = "ID" + nomeColuna.toUpperCase();
}
else
{
tipo = tipoRetornoMetodo();
}

str += getSetarObjetoComandoRepositorio(nomeObjeto,
nomeCampoMetodoGetter(),
nomeColuna,
isComposto,
tipo,
possuiTag("neus.isNull", FOR_METHOD));
return str;
}
(...)
}
Abaixo é mostrada a tarefa ANT criada para a geração do

ComandoRepositorio.
Tarefa ANT – build.xml

<project basedir="." default="core" name="deprecation">

(...)
<property name="nomeTemplateComandoRepositorio"
value="comandoRepositorioTemplate.xdt" />
<target name="generate.comandoRepositorio"
description="Gera a classe ComandoRespositorio.">
<taskdef name="generate.comandoRepositorio"
classname="xdoclet.DocletTask">
<classpath refid="classpath.drivers.build" />
</taskdef>
<generate.comandoRepositorio
destdir="${dir.comandoRepositorio}" >
<fileset dir="${dir.beans}">
<include name="**/*.java"/>
</fileset>
<template
havingClassTag="neus.isBean"
templateFile=
"${dir.templates}/${nomeTemplateComandoRepositorio}"
destinationFile="ComandoRepositorio{0}JDBC.java"
/>
</generate.comandoRepositorio>
</target>
(...)
<!—TAREFA QUE UNIFICA A GERAÇÃO DA CAMADA DATA-->

<target name="generate.data"
depends="generate.comandoRepositorio,
generate.complementoRepositorio,
generate.xml,
generate.scriptsBD" />
</project>
Notemos a presença da tarefa de unificação de toda a geração da camada Data

que faz referencia de dependência à tarefa generate.comandoRepositorio.
Testes
Testar um software significa executá-lo com o objetivo de descobrir um ou
mais erros. No projeto em questão foi criado um exemplo com todos os
requisitos que foram implementados para a geração do código e esse exemplo
foi submetido à geração. Alguns erros foram encontrados e corrigidos.
Os testes eram parcialmente automatizados pelo ANT, pelo próprio princípio
da geração de código com XDoclet que já utiliza essa ferramenta de automação
de construção.
Foram necessários testes manuais como abrir arquivos gerados e compará-los
com o que eles deveriam realmente ser.
Implantação
Logo após o termino do desenvolvimento e testes do NEUS BeanGen ele
estava em condições de ser implantado. Nesse instante a empresa iniciava o
desenvolvimento de dois sistemas e, portanto, a implantação do NEUS
BeanGen consistiu em utilizá-lo para o desenvolvimento desses sistemas.
Uma parte da implantação consistiu também na realização de treinamento dos
programadores que iriam usar o NEUS BeanGen.
Manutenção
Existem quatro tipos de manutenção de software: corretiva, adaptativa,
perfectiva e preventiva. Durante o desenvolvimento dos dois sistemas usando o

NEUS BeanGen foram feitas algumas modificações no mesmo. A maioria

delas foi de caráter perfectivo, ou seja, com o intuito de melhorar o software.

Treinamento
Uma das tarefas realizadas pelo aluno foi elaborar um treinamento para os
desenvolvedores da empresa quer serão os usuários do NEUS BeanGen.
Nesta seção será mostrada uma parte desse treinamento através de uma visão
geral de alguns conceitos como NEUS Beans e NEUS BeanGen Tags.
NEUS Beans
Cada classe do projeto que necessita de armazenamento no banco de dados é
considerada um NEUS Bean. Por exemplo, em um projeto de controle
acadêmico será criada uma classe Aluno que deverá possuir persistência no
banco de dados. Portanto a classe Aluno deverá ser um NEUS Bean.
Acessor Methods
Assim como os Java Beans, origem da denominação, os NEUS Beans possuem
accessor methods para os seus atributos. Accessor Methods são métodos de
acesso aos atributos de uma classe. No caso dos NEUS Beans eles devem ser
getter e setter. Por exemplo, se a classe Aluno possuir um atributo String
nome, ela deve possuir dois métodos:
public String getNome() e public void setNome(String nome).
Os NEUS Beans são parte da camada Business da arquitetura NEUS. Eles
realizam o papel principal no momento em que se está utilizando o NEUS
BeanGen, pois são a Raiz Geração de Código (RGC) para todo o processo de
geração das dos arquivos deriváveis.
Chave Primária
Uma característica dos NEUS Beans é que a classe IntegerChaveImpl sempre
está acima na sua árvore de herança. Essa classe interpreta como chave

primária da tabela que representa o objeto um inteiro seqüencial gerido por

uma tabela de seqüências. Essa característica fica transparente para o usuário
visto que chave primária é um conceito de banco de dados relacional.
Para cada tabela é criada uma coluna com o nome ID<nomeNEUSBean> que
é a chave primaria dessa tabela. Para a classe Aluno por exemplo essa coluna
seria IDALUNO.
Representação Gráfica
Foi criada uma representação parecida com a UML para os NEUS Beans.
Suponha uma classe Aluno com os campos: nome, dataNascimento. Sua
representação seria:
Aluno
String nome
Date dataNascimento
Nessa representação não é necessário explicitar os métodos setter e getter, eles

estão implicitamente presentes.
NEUS BeanGen Tags

Os NEUS Beans são a fonte para toda a geração de código. O usuário tem uma
abstração total do banco de dados, mas deve haver alguma forma de informar
algumas características, como por exemplo o fato de uma campo de um objeto
poder ser null ou não. Essas características são informadas ao NEUS BeanGen
através de tags que são colocadas nos NEUS Beans. Essas tags receberam o
nome de NEUS BeanGen Tags.
Existem dois tipos de NEUS BeanGen Tags: BeanTags e GetterMethodTags.
BeanTags
São as tags colocadas como documentação da classe NEUS Bean, ou seja, no
mesmo lugar onde as tags JavaDoc de classe ficam.

Vejamos um exemplo de uso dessas tags e posteriormente a explicação de cada

uma das tags:
Aluno.java
/**
* @author Fabio Pereira
* @neus.isBean
* @neus.poolSize 100
*/
public class Aluno extends IntegerChaveImpl{
(...)
}
@neus.isBean
Todos os NEUS Bean devem possuir essa tag. É essa tag que informa que
aquela classe é realmente um NEUS Bean.
@neus.poolSize
A arquitetura da NEUS usa o um cache de objetos em memória. Isso significa
dizer que quando precisa-se acessar um objeto primeiramente procura-se esse
objeto em memória no seu devido cache e somente se ele não estiver lá deve-se
buscá-lo no Banco de Dados. Essa técnica é utilizada devido ao fato de que
acesso à memória é bem mais rápido do que acesso ao banco de dados.
Portanto, cada NEUS Bean possui um cache com tamanho definido através
dessa tag. Exemplo: @neus.poolSize 100.
GetterMethodTags
Algumas informações são específicas de cada atributo do NEUS Bean. O
método getter do atributo foi o escolhido para a documentação de informações
sobre o mesmo. Logo elas ficam no mesmo local da documentação JavaDoc
para métodos.

Todos os métodos getter do NEUS Bean devem possuir uma tag de cada um
dos pares de GetterMethodTags.
Os pares são do tipo @neus.isAlgumaCoisa ou @neus.isNotAlgumaCoisa.
Essas tags são subdivididas em dois subgrupos: DBGetterMethodTags e
CompositionGetterMethodTags
DBGetterMethodTags
Data Base GetterMethodTags são tags que informam ao NEUS BeanGen
características diretas do Banco de Dados. São elas:
@neus.isColumn / @neus.isNotColumn
Essa tag estará em um método getter de um atributo, ela indica se esse atributo
é ou não (is ou isNot) uma coluna no banco. Ela se faz necessária pelo fato de
que o NEU Bean pode possuir atributos que não são persistentes, como por
exemplo um campo calculado a partir de outros.
Portanto no exemplo do Aluno para indicar que o campo nome é persistente no
banco na forma de uma coluna colocaria-se a tag @neus.isColumn no método
getter do atributo nome. Veremos esse exemplo mais a frente.
@neus.isNull / @neus.isNotNull
Essa tag é auto explicativa. Determina se o atributo pode ou não ser null. Essa
característica será repassada para os scripts de criação do Banco de Dados.
@neus.isString TIPO(TAM) / @neus.isNotString

Essa tag não indica somente se o atributo é String ou não, pois isso já pode ser
identificado através do retorno do método getter. A função dessa tag é indicar
que tipo e o tamanho dessa String no banco de dados.
Portanto o uso dessa tag pode ser
@neus.isString VARCHAR(35)
@neus.isNotString
@neus.isString CHAR(1)

@neus.isDateTime / @neus.isNotDateTime
Alguns Bancos de Dados fazem diferença entre o tipo DATE e DATETIME,
que diferenciam o armazenamento apenas da data ou data e hora.
Nos NEUS Beans deve-se usar sempre o tipo java.util.Date para atributos data,
mas é necessário indicar para o banco se esse campo usa data e hora
(@neus.isDateTime) ou somente a data (@neus.isNotDateTime).
Exemplo
O exemplo abaixo ilustra o uso das DBGetterMethodTags com a classe Aluno.
Aluno.java
(...)
public class Aluno extends IntegerChaveImpl{
private String nome;
private Date dataNascimento;
/**
* @neus.isColumn
* @neus.isNotNull
* @neus.isString VARCHAR(60)
*/
public String getNome() {return nome;}
public void setNome(String nome) {this.nome = nome;}
/**
* @neus.isColumn
* @neus.isNotNull
* @neus.isNotDateTime
*/
public Date getDataNascimento() {return dataNascimento;}
public void setDataNascimento(String dataNascimento) {
this. dataNascimento = dataNascimento;
}
}

CompositionGetterMethodTags
São usadas para definir características específicas de objetos com composição,
ou seja, objetos que possuem outros objetos dentro deles.
Suponha que queiramos desenvolver um sistema acadêmico e no cadastro do
aluno estão os dados sobre o seu endereço. Vamos então criar duas classes
Aluno e Endereco e uma composição entre eles. Será mostrado o modelo das
tabelas no banco para um entendimento de como é implementada composição
em um banco de dados relacional (SGBDR).
Composição em Classes
Endereço Aluno
String logradouro String nome
int numero Date dataNascimento
String cidade Endereco endereco
String cep
Composição no SGBDR (Tabelas)
T_ENDERECO T_ALUNO
IDENDERECO NOME
LOGRADOURO DATANASCIMENTO
NUMERO IDENDERECO
CIDADE
CEP
Portanto vemos que composição é resolvido no Bando de Dados Relacional

através do uso de chaves estrangeiras.
@neus.isFilled / @neus.isNotFilled
Essa tag define se um objeto dentro de outro será preenchido (filled) ou não.
Portanto, no exemplo mostrado acima, o getter method de endereço na classe

Aluno deveria possuir essa tag. Com isso, ao solicitar um objeto Aluno através
de algum método da fachada esse aluno virá com os campos do seu objeto
interno endereco (logradouro, numero, cidade, cep) preenchidos. Caso essa tag
não seja colocada, o objeto interno endereco virá apenas como o seu
IDENDERECO que é o único campo que está na tabela do Aluno.
@neus.isInsertedAfter / @neus.isInsertedBefore
Algumas vezes, ao fazermos uma solicitação de cadastro de um objeto,
queremos que algum objeto interno seja cadastrado também. É o caso do
exemplo anterior. Suponha que preenchemos um objeto Aluno da seguinte
forma:
CadastradorDeAluno.java
public class CadastradorDeAlunoTeste {

public void cadastrarAluno()
{
Aluno objAluno = new Aluno();
objAluno.setNome(“João da Silva”);
objAluno.setDataNascimento(new Date());
Endereco objEnderecoDoAluno = new Endereço();

objEnderecoDoAluno.setLogradouro(“Av Epitácio Pessoa”);
objEnderecoDoAluno.setNumero(3215);
objEnderecoDoAluno.setCidade(“João Pessoa”);
objEnderecoDoAluno.setCep(“58000-000”);
objAluno.setEndereco(objEnderecoDoAluno);
FachadaAccessor.getFachada().cadastrar(objAluno);

Ao solicitarmos da Fachada, que é a classe gerada pelo NEUS BeanGen que

representa o ponto central de acesso ao sistema de acordo com o design patter
Facade, o cadastro do objeto objAluno, queremos que o objeto
objEnderecoDoAluno que está dentro do objAluno seja cadastrado também.
Logo o endereco interno do aluno isInserted. A escolha entre After/Before
consiste em dizer quem será cadastrado antes ou depois. Nesse caso o
objEnderecoDoAluno deve ser cadastrado antes(Before) pois no momento de
cadastrar o Aluno, precisa-se do código IDENDERECO que só será gerado ao
se cadastrar o endereço.
Portanto as tags do método getEndereco() seriam:
Aluno.java
public class Aluno extends IntegerChaveImpl

/**
* @neus.isColumn
* @neus.isNotNull
* @neus.isFilled
* @neus.isInsertedBefore
*/
public Endereco getEndereco()
{
return endereco;
}

Conclusões
O mercado de trabalho na área de informática está cada vez mais competitivo,
exigindo que os profissionais tenham um alto grau de qualificação. O estagio
realizado pelo aluno na NEUS Tecnologia da Informação foi de grande
importância para colocar em prática os conceitos aprendidos na universidade.
O aluno teve a oportunidade de lidar com conceitos de ponta, como é o caso de
geração de código, POO e aplicações web.
O espírito de equipe foi cultivado durante todo o projeto e o aluno teve a
oportunidade de vivenciar um trabalho com pessoas cujas personalidades e
conhecimentos eram os mais variados.
A escolha das ferramentas e API’s foram acertadas. O ANT unido ao XDoclet
fizeram com que o NEUS BeanGen obtivesse sucesso trazendo para a empresa
os objetivo desejado que era o aumento na produtividade devido ao foco da
programação estar voltado para os pontos chaves dos sistemas em oposição à
programação de códigos repetitivos que eram desenvolvidos anteriormente.
Competitividade é também uma palavra chave para empresas de software
atualmente. Esse aumento na produtividade torna a empresa mais competitiva
no mercado ao qual ela se destina de aplicações web.
O aluno se sente lisonjeado de ter a oportunidade de fazer um estágio produtivo
em uma empresa que proporciona um ambiente de trabalho amigável com
tecnologias de ponta. Uma experiência de vida que lhe servirá de embasamento
prático para toda a sua vida profissional.

Referências
Bibliografia
• [ECKEL] Bruce, “Thinking in Java”, President, MindView, Inc. 1999
• [PRESSMAN] Roger S., “Engenharia de Software”, Mc Graw Hill,

2002.
• [FUSSEL] Mark L., “Foundations of Object Relational Mapping”,

1997
Internet
• ant.apache.org
• xdoclet.sourceforge.net
• java.sun.com

Avaliação
Supervisor – Mario Henrique Matos Alves
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Nota: _________________
______________________________________________________________
MARIO HENRIQUE MATOS ALVES

Orientador – Hamilton Soares da Silva
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Nota: _________________
__________________________________________________________
HAMILTON SOARES DA SILVA

NT000A3B0A

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

NT000A3B0A

Enviado por

Direitos autorais:

Formatos disponíveis

RELATÓRIO DE ESTÁGIO

NEUS BEANGEN – UM FRAMEWORK PARA

Fábio Pereira Carneiro

Orientador: Hamilton Soares da Silva

UFPB – Universidade Federal da Paraíba -2-

Geração de Arquivo Exemplo ................................................................................................................... 41

UFPB – Universidade Federal da Paraíba -3-

UFPB – Universidade Federal da Paraíba -4-

UFPB – Universidade Federal da Paraíba -5-

Dedico este trabalho a todas as pessoas

UFPB – Universidade Federal da Paraíba -6-

UFPB – Universidade Federal da Paraíba -7-

UFPB – Universidade Federal da Paraíba -8-

UFPB – Universidade Federal da Paraíba -9-

Estado da Arte – Arquitetura NEUS

O uso de uma arquitetura multicamadas traz diversos benefícios como o fato de

UFPB – Universidade Federal da Paraíba - 10 -

Mapeamento Objeto Relacional

UFPB – Universidade Federal da Paraíba - 11 -

Figura 2 – MOR – Mapeamento Objeto Relacional

Papel do Mapeamento Objeto Relacional (MOR) frente às linguagens de programação

É importante ressaltar que não entraremos em detalhes a respeito dos conceitos

Programação Orientada a Objetos (POO)

UFPB – Universidade Federal da Paraíba - 12 -

Tabela 1 – Composição – Pessoa/CidadeNatal – Classes Java

class Cidade{ class Pessoa{

UFPB – Universidade Federal da Paraíba - 13 -

O comportamento da classe Cidade está encapsulado dentro da classe Pessoa.

Tabela 2 – Composição – Pessoa/CidadeNatal – Tabelas SGBDR

Herança – dizer que uma classe A é filha da classe B, significa que A

Tabela 3 – Herança – Veiculo/Taxi – Classes Java

class Veiculo{ Class Taxi extends Veiculo{

Um objeto da classe Táxi possui placa, anoFabricacao e numeroPortas, pois

1 – Criação de duas tabelas com chaves primárias em comum:

UFPB – Universidade Federal da Paraíba - 14 -

Tabela 4 – Herança – Veiculo/Táxi – Tabelas SGBDR

2 – Criação de uma tabela que possui todos os campos

É importante ressaltar que na solução 1 para recuperar um TAXI do banco será

UFPB – Universidade Federal da Paraíba - 15 -

Tabela 5 – Lookup.java - Exemplo de uso da API JDBC

public class Lookup {

UFPB – Universidade Federal da Paraíba - 16 -

Tabela 6 – RGC X CDG

RAIZ DE GERAÇÃO DE CÓDIGO CÓDIGO DERIVÁVEL POR

UFPB – Universidade Federal da Paraíba - 17 -

UFPB – Universidade Federal da Paraíba - 18 -

Tabela 7 – Arquivo “.bat” para build simples

Essa solução funciona, mas deixa o programador preso à plataforma Windows.

Tabela 8 – Arquivo do ANT - build.xml

<project basedir="." default="compile" name="HelloWorldANT">

<property name="dir.src" value="src"/>

UFPB – Universidade Federal da Paraíba - 19 -

Existe o conceito de dependência de tarefas, ou seja, ao se tentar executar a

. . . > ant <ENTER>

O ANT procura um arquivo chamado build.xml no diretório atual. Se o

. . . > ant –buildfile meuArquivoDeBuild.xml <ENTER>

. . . > ant clean <ENTER>

Ou se o arquivo fosse o meuArquivoBuild.xml

. . . > ant –buildfile meuArquivoDeBuild.xml clean <ENTER>

UFPB – Universidade Federal da Paraíba - 20 -

Alguns IDE’s, como é o caso do NetBeans são integrados com o ANT de

Arquivos quaisquer “.XXX”