Luiz Edmundo Lopes Mizutani. Tutorial JBuilder X Enterprise

Transcrição

1 Luiz Edmundo Lopes Mizutani Tutorial JBuilder X Enterprise

2 Abstract Este tutorial é resultado da parceria ITA/FCMF-Borland, com intuito de documentar o conhecimento adquirido com esta oportunidade. A consulta a este documento é irrestrita, mas a cópia parcial ou total do mesmo pode ser feita apenas mediante referência à origem (ITA/FCMF), ao autor (Luiz Edmundo Lopes Mizutani Estudante de Engenharia de Computação de graduação no ITA) e sem fins lucrativos. Resumo O conteúdo deste tutorial contém uma seleção de informações avançadas ou pouco conhecidas sobre os recursos do JBuilder X, e destina-se a desenvolvedores que usam o JBuilder informalmente, ou seja, nunca fizeram cursos e conhecem apenas a interface e as facilidades de compilação e escrita mais comuns do Jbuilder, ou para desenvolvedores que possuem experiência com outras ferramentas de desenvolvimento em java. O JBuilder é uma ferramenta poderosa, pois torna automática muitas partes do desenvolvimento, e, pode até tornar dispensável o conhecimento específico de determinadas tecnologias ou frameworks, facilitando o mais importante, que é a sua utilização e funcionalidade. O tutorial está dividido em assuntos independentes. Assim, pode ser lido em qualquer ordem e também utilizado para consulta. As informações são oferecidas de forma bem direta, evitando comentários óbvios demais que cansariam a leitura. Grande parte do conteúdo deste tutorial foi baseada nas apostilas de treinamento oficial de JBuilder oferecidas pela Borland graças à parceria com o ITA. 2

3 Índice CAPÍTULO 1 - ATALHOS E TRUQUES ÚTEIS...6 INTRODUÇÃO DA SESSÃO:...6 ENVOLVER COM TRY/CATCH (SURROUND WITH TRY/CATCH)...6 CODEINSIGHT...7 ACHAR DEFINIÇÃO...9 SYNC EDIT...9 TEMPLATES...10 MOSTRANDO VALOR DE VARIÁVEIS DURANTE O DEBUG (TOOL TIP EXPRESSION EVALUATION)...10 PRINT HTML...11 DICAS RÁPIDAS...11 CAPÍTULO 2 - CRIAÇÃO DE PROJETOS...12 INTRODUÇÃO DA SESSÃO:...12 PROJECT WIZARD...12 PROJECT GROUP...15 CAPÍTULO 3 - USANDO O DEBUGGER...17 INTRODUÇÃO DA SESSÃO:...17 AS GUIAS DO DEBUGADOR (DEBUGGER VIEWS)...17 A GUIA DATA WATCHES...18 USANDO BREAKPOINTS...19 SMART SWAP...20 CAPÍTULO 4 - COMO USAR FRAMEWORKS DE TESTES...21 INTRODUÇÃO DA SESSÃO:...21 EXEMPLO DE APLICAÇÃO...21 CAPÍTULO 5 - SISTEMAS DE CONTROLE DE VERSÕES...29 INTRODUÇÃO DA SESSÃO:...29 CONHECIMENTOS BÁSICOS DE SCVS:...29 ESTUDO DE CASO COM CVS:

4 Lista de Figuras Figura 1: O JBuilder detecta que a excessão deve ser pega... 6 Figura 2: Escolhendo a opção Surround with Try/Catch... 6 Figura 3: Resultado final... 6 Figura 4: Demonstração do MemberInsight... 7 Figura 5: Exemplo de utilização do ClassInsight... 8 Figura 6: Usando o ParameterInsight... 9 Figura 7: Exemplo de Utilização do Sync Edit Figura 8: Exemplo de utilização Figura 9: Print HTML em ação Figura 10: Primeiro passo do Project Wizard Figura 11: Segundo passo do Project Wizard Figura 12: Terceiro passo do Project Wizard Figura 13: Propriedades do projeto Figura 14: Criando um novo Project Group Figura 15: Configuração para mostrar todas as informações durante o Debug Figura 16: Modificando o valor de uma variável Figura 17: Usando o Smart Swap Figura 18: Teste bem sucedido! Figura 19: Interface de testes do JUnit Figura 20: Tela mostrada após inserir projeto no CVS com sucesso Figura 21: Solucionando Merge Conflicts Figura 22: Comparando duas versões na aba History

5 Lista de Tabelas Tabela 1: Debbuger Views

6 Capítulo 1 - Atalhos e Truques Úteis Introdução da Sessão: Esta sessão do tutorial lista recursos que podem ser bastante utilizados durante o desenvolvimento, mas que nem sempre são conhecidos. Cada recurso possui descrição, exemplo de utilização e modo de utilização. Envolver com try/catch (Surround with try/catch) Sempre que um método joga uma exceção, devemos, ao chamá-lo, usar a expressão try{ para poder pegar a excessão (catch). O JBuilder sempre detecta erros quando o usuário não usa o try/catch se for necessário. Para, rapidamente tratar das excessões jogadas (com os blocos corretos), basta posicionar o cursor na linha desejada ou selecionar o trecho desejado, clicar com o botão direito e escolher a opção Surround with Try/Catch : Figura 1: O JBuilder detecta que a excessão deve ser pega Figura 2: Escolhendo a opção Surround with Try/Catch Figura 3: Resultado final 6

7 CodeInsight O CodeInsight é um conjunto de 3 recursos que a toda hora nos ajuda durante composição do código. A seguir todos são descritos com exemplo de utilização e atalhos. Os 3 possuem atalhos pré-definidos, mas podem também ser acessados através do menu Edit. MemberInsight O MemberInsight é um recurso do JBuilder que auxilia a escrita do código nos indicando as subclasses, métodos ou variáveis acessíveis dada uma classe raiz como javax.sql ou java.awt. A utilização é automática quando escrevemos ponto (. ) após o prefixo desejado ou quando apertamos ctrl+espaço. Quando usamos o MemberInsight, o JBuilder nos mostra uma janela contendo as possíveis entradas com descrição do que são quando não são métodos. Quando aparecem métodos na lista, a lista mostra os parâmetros aceitos e a saída do método. Métodos em negrito pertencem à classe atual. Os outros métodos são herdados. Para inserir no código algo desejado, basta escolher com o cursor ou com as setas do teclado e clicar ou apertar enter com a linha desejada selecionada. Se for escolhido um método, o JBuilder completa automáticamente o resto da linha com ponto e vírgula ( ; ) e posiciona o cursor para que sejam escritos os parâmetros necessários, caso existam. Figura 4: Demonstração do MemberInsight Utilizando o mesmo atalho do MemberInsight (ctrl+espaço), podemos invocar o TagInsight em arquivos HTML, JSP ou XML. O TagInsight nos mostra os tags que podem ser inseridos no lugar onde chamamos essa função, com uma breve descrição ao lado. ClassInsight Muitas vezes sabemos o nome da classe que queremos usar, mas não lembramos do pacote onde a mesma se localiza. Outras vezes queremos inserir um método que não havíamos pensado que precisaríamos dele quando começamos a escrever a classe. Nestes casos e em outros, podemos usar o ClassInsight. Este recurso nos fornece uma lista de classes com o endereço completo relativo à sua árvore que contêm o texto 7

8 escrito no campo Search for, na parte de cima da caixa de diálogo. Podemos inserir a classe pedida de 3 formas: - Insert short class name with explicit import: Insere apenas o nome da classe desejada, escrevendo o endereço completo dela em uma diretiva de importação no começo da classe em edição. - Insert short class name with package import: Insere o nome da classe desejada, e uma diretiva de importação. Porém, a diretiva de importação importa o pacote onde está a classe desejada, e não apenas a classe. - Insert fully qualified class name: Insere o endereço completo da classe na linha onde foi invocado o ClassInsight, sem importar nada. Útil quando usamos apenas uma vez a classe selecionada. Para usar o ClassInsight, basta usar o atalho ctrl+alt+espaço. Para atualizar o MemberInsight caso sejam inseridas novas importações, deve-se compilar a classe antes, com Project Make ou Project Rebuild. Figura 5: Exemplo de utilização do ClassInsight ParameterInsight O último recurso do tipo CodeInsight é o ParameterInsight, que apenas nos informa os tipos de parâmetros aceitos pelo método que estamos escrevendo. A sua utilização é automática quando abrimos o primeiro parenteses do método. Mas as vezes fechamos o ParameterInsight e queremos usá-lo novamente no mesmo método. Para 8

9 isso, basta usar o atalho shift+ctrl+espaço. Notar que todos os atalhos do CodeInsight utilizam espaço e combinações de ctrl com alt ou shift. Figura 6: Usando o ParameterInsight Achar Definição Ao revisarmos um código, sempre alternamos entre diversos arquivos em busca das definições dos métodos utilizados, e isso toma grande parte do nosso tempo de revisão. O JBuilder pode encontrar automáticamente as definições dos métodos que utilizamos, mesmo que esteja compactada num pacote do JDK como java.awt.button. Para isso, basta posicionar o cursor na chamada do método desejado e apertar ctrl+enter ou selecionar a opção Search Find Definition. O arquivo onde está o método desejado aparecerá aberto e com o cursor sobre o método. Esse recurso não altera os dados do projeto. Basta fechar o arquivo recém aberto para voltar ao ponto anterior. Sync Edit A edição sincronizada ( Sync Edit ) é um novo recurso do JBuilder (introduzido a partir do Jbuider 9). Ele serve para facilmente alterar o nome de variáveis ou classes, localizando todas as ocorrências da mesma no código selecionado e editando todas ao mesmo tempo. Para usar este recurso, basta selecionar o trecho de código no qual deseja-se usar a edição sincronizada e clicar no botão que aparece à esquerda da numeração das linhas. A área selecionada torna-se amarela, e os nomes que podem ser editados são sublinhados. Quando posicionamos o cursor sobre um desses nomes, os outros nomes iguais são destacados. Uma boa forma de utilizar este recurso é apertando alt+ a antes de entrar no Sync Edit, para selecionar todo o código e ter-se certeza de que todas as chamadas nos nomes a serem modificados estão sendo editadas. 9

10 Figura 7: Exemplo de Utilização do Sync Edit Templates O JBuilder oferece trechos de código comuns em todos os programas para serem inseridos de forma rápida. Exemplos de templates são blocos if/else, main ou mouse listener. Apertando ctrl+ j aparece uma lista com os templates disponíveis. Assim, basta selecionar algum template e apertar enter ou dois cliques. Na lista, podemos ver à esquerda uma de cada linha um nome-atalho, com o qual podemos inserir o código referente à linha sem precisar acessar à lista, bastando escrever esse nome e usar o mesmo atalho (ctrl+ j ). Os templates podem ser editados, removidos ou criados na caixa de diálogo Tools Editor Options, na guia Templates. Mostrando Valor de Variáveis Durante o Debug (Tool Tip Expression Evaluation) Para ver facilmente o valor de uma variável enquanto estamos debugando um programa, basta posicionar o cursor sobre o nome da variável. Se ela estiver sendo utilizada no momento, o seu valor aparecerá na forma de tool tip. A única exigência é que o processo de debug esteja parado. Uma boa prática é parar nas partes suspeitas do código utilizando breakpoints (clicando sobre o número da linha podemos adicionar breakpoints rapidamente). 10

11 Figura 8: Exemplo de utilização Print HTML Existe a opção print HTML, útil quando queremos publicar um código com a formatação em cores do JBuilder. Para usar, basta acessar o menu File Print e selecionar a opção To HTML file. Figura 9: Print HTML em ação Dicas Rápidas - A partir da versão X do Jbuilder, pode-se notar que os nomes de argumentos de métodos, métodos e variáveis ainda não utilizadas até então são coloridos de cinza até que os usemos. - Para ajustar a identação das linhas do seu código java, basta selecionar tudo (ctrl+a) e clicar tab. 11

12 Capítulo 2 - Criação de Projetos Introdução da Sessão: Podemos considerar cada programa que criamos como um projeto. Quando aprendemos Java, fazendo tudo manualmente, não nos preocupamos com a organização das nossas classes, e nem sequer criamos um pacote. Mas quando os programa tornamse mais complexos, é fundamental que eles estejam organizados em diretórios com hierarquia e separação de tipos de arquivos. Afinal, projetos (ou sistemas) possuem documentação, códigos fontes, arquivos compilados, backups, html, imagens, entre outras coisas. O JBuilder nos fornece um padrão de organização reconhecido por ele quando criamos um novo projeto. A criação de projetos é básico no JBuilder, mas nem sempre são conhecidos os detalhes das opções oferecidas. Esta sessão trata de explicar o que há por trás das opções mais importantes da criação de projetos e grupos de projetos. Grupo de projetos é um tipo pouco usado, mas bastante útil quando se quer integrar vários subprojetos que são inicialmente trabalhados independentemente. Project Wizard O nome Wizard (feiticeiro em inglês) em termos de computação refere-se à guias passo a passo para realizar alguma ação. Neste caso, vamos usar o Project Wizard para criar um novo projeto. A partir da tela inicial do JBuilder, sempre que chamamos o wizard de qualquer outra coisa, como o Applet Wizard, o JBuilder chama automáticamente o Project Wizard antes, pois o Applet Wizard utiliza a estrutura criada pelo Project Wizard. Para chamar o Project Wizard, basta selecionar a opção do menu File New Project... ou File New... e selecionar Project na guia Project. 12

13 Figura 10: Primeiro passo do Project Wizard O nome do projeto será referenciado também como o nome do pacote onde está o projeto. Assim, deve-se evitar nomes com espaços para que não haja problemas durante a compilação com as ferramentas de linha de comando do JDK incluídas no JBuilder. Escolhendo outro projeto como template, o Jbuilder criará o novo projeto no mesmo pacote do template escolhido. Marcando a opção Generate project notes file fará que o JBuilder crie um HTML na raiz do diretório de trabalho constando informações sobre o projeto que são descritas no passo 3. Classe do projeto também possui essas informações na forma de comentário. Figura 11: Segundo passo do Project Wizard 13

14 No segundo passo do Project Wizard escolhemos o JDK que iremos usar. Nesse campo escolhemos, por exemplo, se vamos desenvolver para portáteis com J2ME ou para PC s com J2EE. Notar na guia Class Path as classes reconhecidas pelo projeto de acordo com o JDK escolhido. Os outros campos definem onde serão guardados os arquivos.class, arquivos de backup, códigos fonte e testes. Geralmente não há motivos para mudar algum dos diretórios padrão. Figura 12: Terceiro passo do Project Wizard O terceiro e último passo do Project Wizard serve para descrever o projeto. Os dados fornecidos serão incluídos nos códigos fontes e nas notas do projeto (lembrar do primeiro passo). O campo Encoding serve para especificar como o JBuilder interpreta arquivos de texto contendo caracteres além dos que existem no ASCII. Caso o seu programa utilize linguagens diferentes, é bom pesquisar sobre o assunto. Detalhes sobre cada tipo oferecido podem ser encontrados na documentação do JDK. Quando a opção Enable Source Package Discovery And Compilation está marcada, todos os pacotes dentro da pasta do projeto podem aparecer automáticamente no project pane (painel à esquerda da área de trabalho do JBuilder) e são compilados com o comando build. O campo Deepest package exposed determina a profundidade máxima dos pacotes que aparecem no project pane caso a opção anterior esteja marcada. Todas as opções marcadas até agora (com excessão da escolha do nome do projeto) e várias outras podem ser alteradas no menu Project Project Properties ou clicando com o botão direito do mouse sobre o nome do projeto no project pane e escolhendo a opção properties. 14

15 Figura 13: Propriedades do projeto Entre as propriedades do projeto, podemos configurar as propriedades de execução do projeto (o que acontece quando selecionamos a opção Run Run Project ou F9) e de construção ( Build ). As propriedades de execução determinam a forma de utilização do debug, do Optimizeit e propriedades específicas ao tipo de projeto, como parâmetros em aplicações e tamanho da janela em applets. Entre as propriedades de execução podemos encontrar as opções de debug ( Debug Options ). É recomendável que sejam incluídas nos códigos compilados as informações oferecidas para que possamos debugar os programas, a não ser que o programa esteja preparado para ser terminado, visto que essa opção torna os arquivos maiores. A opção Obfuscate é um processo que previne engenharia reversa dos arquivos compilados. As propriedades de construção determinam como o Jbuilder deve compilar java, interpretar Ant, escrever Javadocs e agir quando for dado o comando Build. Para usar Ant, basta adicionar ao projeto o arquivo build.xml. O JBuilder reconhecerá automaticamente como um Ant. Podemos adicionar bibliotecas que interpretam comandos Ant que não estão no padrão do Jbuilder e podemos configurar nas propriedades de qualquer xml para que ele seja interpretado com um Ant e para que ele seja executado sempre que for dado o comando Make ( o comando Make está incluído entre os passos do Build ). Project Group Project Group é um container que agrupa projetos relacionados. Por exemplo, quando estamos criando uma aplicação cliente servidor, é útil trabalharmos individualmente cada interface ( a cliente e a servidor) e testá-los juntos usando um Project Group. O JBuilder salva Project Groups como arquivos XML com a extensão.jpgr. Mesmo agrupados, os projetos podem ser abertos individualmente, assim não 15

16 atrapalharia o trabalho, caso equipes diferentes trabalhassem nem cada projeto. Pode-se configurar a ordem de execução dos projetos num Project Group. Para criar um Project Group, basta acessar o menu File New e, na guia Project, selecionar Project Group. Figura 14: Criando um novo Project Group Na janela seguinte o Jbuilder pergunta qual o diretório onde será salvo o grupo de projetos, e no segundo passo quais projetos serão agrupados, bastando indicar o arquivo que caracteriza o projeto, que pode ser.jpx ou.jpr. O comando Add Recursively é útil quando já temos organizados em subpastas os projetos relacionados, pois o JBuilder procura nelas por outros projetos. Ao clicar com o direito sobre o nome do grupo de projetos e selecionar propriedades, podemos escolher a ordem em que os projetos responderão ao comando Make, podendo executar subcomandos individuais aos projetos entre Clean, Make e Rebuild. 16

17 Capítulo 3 - Usando o Debugger Introdução da Sessão: O JBuilder possui um arsenal poderoso para analisar cada comando de um programa a procura de erros. É interessante lembrar que enquanto um programa está sendo desenvolvido, devemos sempre habilitar nas propriedades do projeto, guia Build Java, que o JBuilder disponibilize informações de fonte, linha e variável em Debug Options. Esta opção pode ser retirada quando o programa estiver acabado, mas gerar arquivos.class menores. Por padrão o JBuilder inclui todas as informações e nada precisa ser alterado. Figura 15: Configuração para mostrar todas as informações durante o Debug Para iniciar o Debug, basta clicar sobre o botão ou clicar shift+f9. Durante o Debug, o programa executa como normalmente executaria, porém o usuário passa a ter a capacidade de parar a execução para análise em qualquer linha. As Guias do Debugador (Debugger Views) O JBuilder apresenta 8 guias na parte de baixo que oferecem diferentes tipos de informações durante a debugação do projeto. Uma breve descrição de cada guia é fornecida abaixo. Maiores detalhes serão fornecidos a seguir. Tabela 1: Debbuger Views 17

18 Ícone Debugger View Console output, input, and errors Threads, call stacks and data Data watches Loaded classes and static data Data and code breakpoints Classes with tracing disabled Synchronization monitors Custom views Descrição Mostra as saídas e entradas do programa e permite entradas via console. Mostra o estado atual de todas os grupos de thread do programa. Expandindo esta guia é possível ver as threads e a sequência de chamada de métodos das mesmas. Mostra o valor atual de variáveis que queremos rastrear. Mostra as classes carregadas pelo programa e dados estáticos, caso existam, da classe escolhida. Mostra uma lista com todos os breakpoints setados e o estado atual de cada. É possível também editálos por essa guia. Mostra uma lista ordenada alfabeticamente com as classes e packages que não precisam ser debugadas. Caso a opção Smart Step esteja ligada, essa lista será ignorada do debug. Geralmente desabilitamos classes e pacotes que temos certeza de que funcionam corretamente. A guia Synchronization monitors mostra os monitores de sincronização usados pelas threads dos programas e os seus estados atuais. Este recurso é útil para detectar deadlocks. Esta guia permite adicionar, editar ou deletar um custom viewer para um objeto particular. A Guia Data Watches Através da guia Data Watches podemos monitorar os valores de variáveis ou objetos durante a execução do programa. Para adicionar um watch, basta acessar o menu Run Add Watch... ou clicar o botão Add Watch descrito pelo ícone. Uma caixa de diálogo aparece perguntando o nome da variável ou objeto a ser monitorado (campo Expression ) e uma descrição do watch, podendo ser deixado em branco. Outra maneira de monitorar variáveis é acessando o menu Run Evaluate/Modify.... Na janela que aparece, escrevemos as expressões da mesma maneira que na hora em que adicionamos watches, e ao clicar o botão Evaluate obtemos os valores desejados. A vantagem de usar este método é que podemos modificar manualmente os valores de variáveis mais simples como inteiro ou char apenas escrevendo o novo valor no campo New Value e clicando em Modify. 18

19 Figura 16: Modificando o valor de uma variável Usando BreakPoints Breakpoints são pontos do código onde desejamos que o debug pare a execução para que possamos analisar o status do programa até então. Para adicionar breakpoints, podemos clicar com o botão esquerdo do mouse sobre o número da linha onde se deseja adicionar um breakpoint ou acessando o menu Run Add Breakpoint e escolhendo algum tipo de breakpoint, que pode ser de linha, método, classe, excessão ou entre processos. Todos os tipos têm em comum que fazem o programa parar quando atingem o tipo escolhido. É possível fazer o programa gerar uma mensagem no console dizendo que passou pelo breakpoint, além de fazer o programa parar a execução. Para isto basta selecionar a opção Log Message em Actions, na caixa de diálogo que adiciona breakpoints. O campo Condition permite que o breakpoint entre em ação apenas quando alguma condição lógica acontece, como isfinal==true. O campo Pass count nos permite especificar o número de vezes em que o programa poderá passar pelo breakpoint antes de executar a sua ação. A guia Data code and breakpoints permite gerenciar todos os breakpoints que criamos. Podemos através dela adicionar, deletar, configurar ou desabilita breakpoints. O último caso é usado quando não queremos perder a localização de um breakpoint, porém queremos que o código passe pelo mesmo. Depois que o programa para a sua execução, podemos continuar a execução até o próximo breakpoint através do botão Resume Program, ou podemos fazer uma análise mais detalhada, linha por linha, com o botão Step over. Os botões Step into e Step out possibilitam respectivamente analisar os detalhes da execução de um método ou sair desse modo detalhado, pulando para a próxima linha do método principal. 19

20 Smart Swap O recurso Smart Swap foi introduzido a partir da versão 8 do JBuilder, e permite modificar o código do programa durante o debug, fazendo esse código tornar-se ativo sem precisar reiniciar o debugador, poupando tempo de desenvolvimento do programa. Por padrão o Smart Swap já está habilitado, mas deve-se ter certeza de que a opção Enable Smart Swap está habilitada nas configurações de execução (runtime configuration) na guia Debug. Para usar o Smart Swap basta parar a execução durante o debug com um breakpoint e fazer as alterações desejadas no código. Ao continuar a execução ou apertar o o botão Smart Swap, o JBuilder pergunta o que fará daí em diante oferecendo as seguintes opções: Compile and update the compiled classes: Esta opção faz o JBuilder recompilar o código com as modificações feitas e continuar a execução no mesmo ponto onde estava. Esta opção é escolhida automaticamente quando é usado o botão Smart Swap. No special action; just resume: O JBuilder ignora as mudanças e continua o debug. Restart debug session: O debug é interrompido, o novo código é compilado e a execução recomeça do começo. Figura 17: Usando o Smart Swap 20

21 Capítulo 4 - Como Usar Frameworks de Testes Introdução da Sessão: Para ajudar os programadores a testar os seus softwares, o JBuilder possui o framework unit test. É importante preocupar-se com testes para cada unidade do sistema, pois isso permite ter certeza de que o software está operando corretamente, como designado. Quando muitas unidades de testes são combinadas, a suite de testes resultante ajudará a detectar erros antes que a aplicação seja entregue. Em resumo, a habilidade de re-executar uma unidade de testes enquanto desenvolvemos significa que podemos terminar a aplicação com mais confiança. Sempre que o teste é bem sucedido, podemos ter certeza de que a aplicação continua em boa forma. O JBuilder suporta um framework open source orientado a objeto muito usado, o JUnit, e é sobre ele que vamos tratar nesta sessão. Pode-se encontrar mais informações sobre este framework em e Exemplo de Aplicação Estudaremos como usar o framework JUnit através de uma aplicação construída passo a passo e bem comentada. O objetivo final será comprovar que o tempo investido no design de testes é muito minimizado pelo JUnit e mostrar como é fácil aplicá-lo. Primeiramente crie um novo projeto e chame-o de Cadastro_de_Empregados. Aceite as configurações padrões clicando Finish. Depois crie uma nova classe (menu File New... guia General), chame-a de Cadastro e cole o seguinte código em seu conteúdo: package cadastro_de_empregados; /*Este programa executa o cadastro de empregados, mas não permite que existam mais que 5 empregados na empresa, controlando o número total de empregados com uma variável estática (nempregados).*/ public class Cadastro { private String nome = null; private String sobrenome = null; private static int controleid; private int ID = -1; private int salario; private static int nempregados; //Primeiro nome do empregado //Sobrenome do empregado //Contador que atribui ID aos empregados //Número de identificação do empregado //Salário atual do empregado //Número de empregados criados /*Construtor de Cadastro Notar que ele apenas atribui os valores de identificação do empregado e soma 1 ao número de empregados total.*/ public Cadastro(String nome1, String sobrenome1, int salario1) { //Verifica se o número máximo de empregados já foi atingido antes de cadastrar if (nempregados<5) { nome = nome1; sobrenome = sobrenome1; salario = salario1; ID = controleid; ++controleid; ++nempregados; 21

22 else { System.out.println("O número máximo de empregados já foi atingido!"); /*Método para demitir o empregado, diminuindo o número de empregados da empresa e zerando os campos*/ public void demitir(){ --nempregados; nome = null; sobrenome = null; salario = 0; ID = -1; /*Método que retorna o número atual de empregados*/ public static int getnempregados(){ return nempregados; /*Método que retorna o salario atual do empregado*/ public int getsalario(){ return salario; /*Método para aumentar o salario somando ao aumento*/ public void aumentarsalario(int aumento){ if (aumento>=0) { salario += aumento; else { System.out.println("O aumento deve ser positivo!"); /*Método para diminuir o salario subtraindo a reducao*/ public void diminuirsalario(int reducao){ if (reducao>=0) { salario -= reducao; else { System.out.println("A reducao deve ser positiva!"); /*Método que retorna o nome completo do empregado*/ public String getnomecompleto(){ return new String(nome+" "+sobrenome); /*Método que retorna o ID do empregado*/ public int getid(){ return ID; A funcionalidade do programa acima pode ser entendida pelos comentários. Vamos agora criar 4 casos de testes, um para testar o método demitir, um para testar o construtor, um para testar o método aumentarsalario e o último para testar o método diminuirsalario. Para isso, vá em File New... e na guia Test selecione Test Case. No primeiro passo escolhemos os métodos a serem testados. Podemos escolher mais de um método segurando ctrl, mas para isolar os testes vamos criar cada um individualmente. Comece escolhendo o método demitir. No segundo passo escolha o nome TestCadastroDemitir para a classe de teste e aceite os outros padrões. No terceiro passo podemos adicionar fixtures ao teste. Fixtures oferecem um conjunto de objetos que podem ser reutilizados em testes semelhantes. No momento não temos nenhum 22

23 fixture, então clique next. Selecione a opção Create a runtime configuration e aceite o nome oferecido e o executor do teste (JBuilder Test Runner no caso), clicando em Finish. Notar que o JBuilder fornece grande parte do código a ser usado no teste, e cria comentários To Do para lembrar o que está faltando. Devemos completar o código de 2 métodos neste caso. O método setup serve para iniciar os objetos e fazer as preparações necessárias que serão usados durante o teste. O método teardown faz a limpeza do que foi feito nas instanciações do setup e pode também, por exemplo, fechar uma conexão, caso tenha sido aberta para usar durante o teste. O teste é executado pelo método testdemitir. Devemos programá-lo para usar o método a ser testado e comparar o resultado com um resultado esperado. Neste caso vamos cadastrar 3 funcionários e demitir 2. Assim esperamos obter o número de 3 funcionários antes de demitir o primeiro, 2 funcionarios depois de demitir o primeiro e 1 funcionário depois de demitir o segundo. Os métodos que verificam se os valores estão corretos estão contidos na classe Assert, dentro do pacote junit.framework, já importado. Insira o código abaixo sobre o código já fornecido pelo JBuilder na classe TestCadastroDemitir: package cadastro_de_empregados; import junit.framework.*; public class TestCadastroDemitir extends TestCase { private Cadastro cadastro1 = null; private Cadastro cadastro2 = null; private Cadastro cadastro3 = null; protected void setup() throws Exception { super.setup(); cadastro1 = new Cadastro("Kaeru", "Nakama", 1000); cadastro2 = new Cadastro("Mieko", "Watanabe", 1000); cadastro3 = new Cadastro("Kakashi", "Katsumoto", 1000); protected void teardown() throws Exception { cadastro3.demitir(); cadastro1 = null; cadastro2 = null; cadastro3 = null; super.teardown(); public void testdemitir() { assertequals("o construtor está com problemas",3,cadastro1.getnempregados()); cadastro1.demitir(); assertequals("demitir 1 com problemas",2,cadastro2.getnempregados()); cadastro2.demitir(); assertequals("demitir 2 com problemas",1,cadastro3.getnempregados()); cadastro2.demitir(); assertequals("demitir 2 com problemas",1,cadastro3.getnempregados()); Execute o teste e note que o JBuilder oferece uma interface diferente de execução para testes. A configuração de execução do tipo teste pode ser feita em runtime configurations. Como criamos o teste usando um wizard, foi criada automaticamente a configuração de execução. Foi introduzido um erro proposital no código para que fosse detectado pelo teste. O erro foi permitir que o mesmo empregado 23

24 possa ser demitido várias vezes, reduzindo o número de empregados à menos que 0. Para corrigir este erro, substitua o método demitir pelo método descrito abaixo: public void demitir(){ if (nempregados > 0 && ID!= -1) { --nempregados; if (nempregados == 0){ controleid = 0; nome = null; sobrenome = null; salario = 0; ID = -1; Foi usado para validar o teste o método assertequals de Assert. O primeiro argumento deste método é a mensagem de erro fornecida caso o teste falhe, e pode ser ignorada caso se queira. O segundo argumento é o resultado esperado, e o terceiro é o resultado real. Ambos devem ser do mesmo tipo, mas podem ser de qualquer tipo, existem assertequals para todos os casos. Vamos agora testar o construtor. Acesse o Test Case Wizard como anteriormente, selecione o construtor Cadastro(String, String, int) como método a ser testado, aceite os padrões dos passos 2 e 3 e no quarto passo marque a opção Create a runtime configuration. A idéia do teste do construtor será verificar se os campos estão sendo preenchidos corretamente 2 vezes e ao criar 6 cadastros, verificar se ele ignorou o último, pois somente são permitidos 5 empregados cadastrados ao mesmo tempo. O código para isso encontra-se abaixo: package cadastro_de_empregados; import junit.framework.*; public class TestCadastro extends TestCase { private Cadastro cadastro1 = null; private Cadastro cadastro2 = null; private Cadastro cadastro3 = null; private Cadastro cadastro4 = null; private Cadastro cadastro5 = null; private Cadastro cadastro6 = null; protected void setup() throws Exception { super.setup(); protected void teardown() throws Exception { cadastro1.demitir(); cadastro2.demitir(); cadastro3.demitir(); cadastro4.demitir(); cadastro5.demitir(); cadastro6.demitir(); cadastro1 = null; cadastro2 = null; cadastro3 = null; cadastro4 = null; cadastro5 = null; cadastro6 = null; super.teardown(); public void testcadastro() { 24

25 String nomecompleto1 = "Kaeru Nakama"; String nomecompleto3 = "Kakashi Katsumoto"; int salario1 = 1200; int salario3 = 800; int ID1 = 0; int ID3 = 2; int ID6 = -1; int nempregados1 = 1; int nempregados3 = 3; int nempregados6 = 5; cadastro1 = new Cadastro("Kaeru", "Nakama", 1200); //Verifica se o nome foi criado corretamente assertequals(nomecompleto1,cadastro1.getnomecompleto()); //Verifica se o salário foi criado corretamente assertequals(salario1,cadastro1.getsalario()); //Verifica se o ID foi atribuído corretamente assertequals(id1,cadastro1.getid()); //Verifica se o número de empregados está correto //Notar o uso de asserttrue para mostrar o seu funcionamento asserttrue(nempregados1==cadastro1.getnempregados()); cadastro2 = new Cadastro("Mieko", "Watanabe", 1100); cadastro3 = new Cadastro("Kakashi", "Katsumoto", 800); //Verifica se o nome foi criado corretamente assertequals(nomecompleto3,cadastro3.getnomecompleto()); //Verifica se o salário foi criado corretamente assertequals(salario3,cadastro3.getsalario()); //Verifica se o ID foi atribuído corretamente assertequals(id3,cadastro3.getid()); //Verifica se o número de empregados está correto asserttrue(nempregados3==cadastro3.getnempregados()); cadastro4 = new Cadastro("Hirata", "Mizutani", 2000); cadastro5 = new Cadastro("Keiko", "Kobayashi", 1500); cadastro6 = new Cadastro("Saori", "Uno", 1300); //Verifica se o número de empregados está correto assertequals(nempregados6,cadastro6.getnempregados()); //Verifica se o ID está correto //Como o cadastro 6 não deve ser realizado, devemos obter o valor -1 assertequals(id6,cadastro6.getid()); Novamente este teste deve estar correto, pois todas as verificações feitas com os métodos de Assert estão corretas. Notar que dessa vez não foi escrita nenhuma mensagem de erro, mostrando que a mesma pode ser ignorada para maior simplicidade. Moderíamos simplificar ou complicar mais ainda este código de testes retirando ou adicionando verificações a cada cadastro. Tudo isso afetaria a confiabilidade do teste. Deve-se usar o bom senso para saber quando um teste é bom o suficiente para o que precisamos. Figura 18: Teste bem sucedido! 25

26 O próximo teste é o do método aumentar salário. Crie um Test Case com o Wizard, chame a classe de teste de TestAumentarSalario, crie uma configuração de execução no último passo, e antes de clicar Finish mude o Test Runner para JUnit SwingUI Test Runner. Este teste será bem simples. Cadastramos um empregado, aumentamos o seu salário e verificamos se o valor final é o esperado. O código completo encontra-se abaixo: package cadastro_de_empregados; import junit.framework.*; public class TestAumentarSalario extends TestCase { private Cadastro cadastro = null; protected void setup() throws Exception { super.setup(); cadastro = new Cadastro("Yusuke", "Urameshi", 500); protected void teardown() throws Exception { cadastro.demitir(); cadastro = null; super.teardown(); public void testaumentarsalario() { int aumento = 750; int aumento1 = -500; cadastro.aumentarsalario(aumento); assertequals(1250,cadastro.getsalario()); cadastro.aumentarsalario(aumento1); assertequals(1250,cadastro.getsalario()); Ao executar este teste, vemos que uma janela Swing aparece com os dados sobre o teste. Esta janela faz parte do framework JUnit e pode ser escolhida pelo campo Test Runner das configurações de execução. Através dessa interface podemos repetir o teste várias vezes caso se queira, bastando apertar o botão Run. 26

27 Figura 19: Interface de testes do JUnit O último teste a ser criado é o teste do método diminuirsalario. Da mesma forma que foi feita no teste anterior, crie a classe de teste TestDiminuirSalario com o código abaixo: package cadastro_de_empregados; import junit.framework.*; public class TestDiminuirSalario extends TestCase { private Cadastro cadastro = null; protected void setup() throws Exception { super.setup(); cadastro = new Cadastro("Yusuke", "Urameshi", 1400); protected void teardown() throws Exception { cadastro.demitir(); cadastro = null; super.teardown(); public void testdiminuirsalario() { int reducao = 250; int reducao1 = -500; cadastro.diminuirsalario(reducao); assertequals(1150,cadastro.getsalario()); cadastro.diminuirsalario(reducao1); assertequals(1150,cadastro.getsalario()); 27

28 Temos muitos testes feitos, e não é nada prático ficar executando um por um para testar um sistema. Vamos então agrupar os testes criados em um Test Suite. Test Suites implementam a interface Test assim como Test Cases, e assim também podem executar testes. Para criar um Test Suite acesse o menu File New... e selecione na guia Test a opção Test Suite. Adicione o primeiro passo todos os testes que criamos (use o ctrl para facilitar). Aceite o nome de AllTests e crie uma configuração de execução com o Test Runner do JUnit modo Swing. Execute o AllTests com todos os testes juntos ou individualmente pela janela Swing do JUnit. Quando trabalhamos com rotinas de testes, é sempre bom configurar o botão Make nas configurações de projeto para que sempre execute os testes criados. Isso assegura que problemas recém criados não crescerão indefinidamente. Não utilizamos neste exemplo fixtures. O JBuilder fornece wizards de fixtures mais usadas. Abaixo segue uma breve descrição de cada tipo: JNDI Fixture: Classe que facilita o uso de lookups JNDI (Java Naming and Directory Interface), uma API usada para localizar interfaces EJB no cliente. JDBC Fixture: Este fixture serve para ajudar os Test Cases a criarem conexões JDBC. Comparison Fixture: Uma fixture de comparação é usada para gravar a saída de um teste executado e depois compará-lo com a saída de um teste subsequente. Custom Fixture: Este último tipo apenas fornece um construtor e os métodos setup e teardown para que possamos completar com qualquer código. Um bom exemplo de aplicação do JDBC Fixture e do Comparison Fixture pode ser encontrado no seguinte endereço: 28

29 Capítulo 5 - Sistemas de Controle de Versões Introdução da Sessão: Em um ambiente com múltiplos desenvolvedores é necessário que haja uma forma de controle para edição dos arquivos de um projeto para evitar que informações sejam sobre-escritas e para gerenciar as mudanças durante o desenvolvimento, ou seja, deve haver um controle de versões. Ferramentas que oferecem controle de versões são chamadas de Sistemas de Controle de Versões (SCVs) ou Version Control Systems (VCS), e o JBuilder possui integração com os seguintes programas deste tipo: ClearCase: O Sistema de Controle de Versões da Rational. CVS: O CVS, ou Concurrent Versions System é um projeto open source gratuito, disponível na página O CVS é instalado automaticamente junto com o JBuilder. Star Team: É a ferramenta da Borland para gerenciamento de versões e de requisitos. Com o Star Team o JBuilder possui, a partir da versão 9, uma forte integração, visto que a Borland desenvolve os dois programas. Microsoft Visual SourceSafe: O Visual SourceSafe é o Sistema de Controle de Versões da Microsoft. Conhecimentos Básicos de SCVs: Os recursos de cada sistema podem variar bastante, mas alguns conceitos são básicos para todos os Sistemas de Controle de Versões. Deve existir um servidor central onde são guardados os arquivos de projeto oficiais. Esse servidor deve ser acessível por todos os desenvolvedores, e a escrita e leitura é controlada pelo sistema. Este servidor é normalmente chamado de Repository. Cada usuário deve possuir uma pasta de trabalho (Workspace) para onde os arquivos do Repository são copiados para serem editados. Ao terminar a edição, os arquivos editados são comparados com os do Repository e, caso não haja conflitos, são salvos como uma nova versão. O versionamento é responsabilidade do SCV, que gerencia novas e velhas versões dos arquivos do projeto. O usuário apenas envia o comando de atualização do arquivo. Caso o SCV feche (lock) os arquivos que estão sendo editados para edição simultânea, o uso de ferramentas de comparação entre versões torna-se desnecessário. Porém, se for permitido que mais de um desenvolvedor edite o mesmo arquivo ao mesmo tempo, faz-se necessário o uso desse tipo de recurso. Alguns SCVs possuem as ferramentas necessárias para fazer este tipo de comparação, mas o JBuilder já possui meios para auxiliar a junção (merge) das alterações feitas em arquivos diferentes, o que será detalhado adiante. 29

30 Estudo de Caso com CVS: Inicie um novo projeto com o nome Calculadora e crie uma classe também chamada calculadora. Use todas as outras opções de acordo com o padrão do JBuilder. Abaixo do construtor escreva a seguinte classe: public int soma(int a, int b){ return a+b; Acesse o item do menu Team Select Project VSC... e escolha o CVS. Com isso podemos criar um repositório para o nosso projeto. Para isso, vá em Team Create Local Repository... e escolha um diretório vazio. Normalmente devemos escolher como repositório uma pasta que possa ser acessível a todos os desenvolvedores via rede interna ou internet. Para este exemplo, é suficiente usar apenas um computador. Depois que o CVS cria o repositório, vamos inserir o nosso projeto Calculadora. Clique na opção do menu Team Place Project Into CVS.... No primeiro passo, escolha a opção Local em Connect type e certifique-se que o endereço de Repository Path está apontando para o repositório recém criado por você. O segundo passo permite que seja escrita uma descrição do projeto a ser colocado no repositório. Escreva a seguinte descrição: Esta calculadora servirá para estudar o uso de Sistemas de Controle de Versões. O terceiro passo serve para escolher que partes do projeto serão colocadas no repositório. Algumas partes de um projeto não são recomendadas que sejam controladas, como backups e arquivos compilados. O JBuilder já oferece uma boa configuração sobre o que irá para o repositório, por isso aceite o padrão clicando Finish. Figura 20: Tela mostrada após inserir projeto no CVS com sucesso 30

31 Vamos agora simular que dois usuários diferentes estão editando a classe Calculadora ao mesmo tempo. Para isso, abra outra janela do JBuilder e vá em File New... e na guia Project escolha Pull Project from CVS. No primeiro passo, escolha um diretório vazio que servirá como Workspace, e como propósito de recuperação do projeto escolha a opção Checkout for development work. Como estamos usando o mesmo computador, escolha a opção Local em Connect type no segundo passo. No terceiro passo verifique se o caminho onde foi instalado o repositório e o nome do projeto a ser recuperado (Calculadora) estão corretamente escolhidos, e clique Next. No quarto passo aceite os padrões para obter a última versão do projeto e clique Finish. Temos agora duas instâncias do JBuilder com o mesmo projeto aberto. Vamos chamar o primeiro JBuilder aberto de desenvolvedor A e o segundo de desenvolvedor B. Escreva na parte B o seguinte método abaixo do método soma: public int subtracao(int a, int b){ return a-b; Salve o programa e no menu Team escolha a opção Update Calculadora.java... para fazer o JBuilder verificar as diferenças entre a versão de Calculadora.java do workspace de B e a versão do repositório, e depois formar uma versão onde não há perdas entre as duas (merge). Caso haja conflitos entre as versões, o JBuilder pede ajuda do usuário para executar a operação, escolhendo as partes a serem mantidas e a serem descartadas. Desta vez não temos nenhum conflito, então podemos substituir a versão do servidor por esta nossa nova versão, bastando clicar na opção Team Commit Calculadora.java.... OJBuilder pede, então que seja feito um comentário sobre as mudanças feitas nesta versão. Escreva o seguinte texto: Adicionado método subtracao. Feito isto, vamos passar para o usuário A. Insira o seguinte método abaixo do método soma: public int multiplicacao(int a, int b){ return a*b; Salve o arquivo e tente fazer um commit da mesma forma que antes. Como a versão que estamos trabalhando na parte A está desatualizada, o JBuilder não completa a operação de substituir o arquivo no repositório por este novo. Vamos então fazer um update neste arquivo para validar as diferenças entre as versões e criar uma nova versão sem perda de dados. Vá novamente em Team Update Calculadora.java... e clique ok quando o JBuilder pede confirmação desta ação. Após o término da operação, é encontrado um conflito entre as versões, então o resultado é um arquivo com todas as partes não repetidas das duas versões e alguns comentários a serem apagados. Basta, neste caso, apagar os comentários feitos para obter a versão desejada. Faça um commit normalmente para atualizar a versão do repositório e escreva o seguinte comentário: Adicionado método multiplicacao. Na parte do usuário B, suponha que o usuário queira apenas verificar se houve mudança no arquivo que ele está trabalhando. A forma mais rápida de fazer isso é 31

32 clicando em Team Status for Calculadora.java.... Verifique que o JBuilder informa que o arquivo foi modificado no repositório. Para visualizar as mudanças feitas por outros usuários, sem fazer o merge nos arquivos, pode-se usar o comando Team Status Browser.... Ao saber que houve mudanças na versão do repositório, o usuário B deve fazer o quanto antes um update, para evitar que as diferenças entre as duas versões fique muito grande. Execute o update em B e vá para o próximo passo. Até agora fizemos apenas adição de elementos em nosso programa. Desta vez vamos editar as nossas classes. Na área de trabalho B, vamos fazer alterações para que os nossos métodos suportem números do tipo float. O resultado final deve ser igual ao que está abaixo: package calculadora; public class Calculadora { public Calculadora() { public float soma(float a, float b){ return a+b; public float multiplicacao(float a, float b){ return a*b; public float subtracao(float a, float b){ return a-b; Faça um update e depois commit. Entre com o seguinte comentário para esta versão: Adicionado suporte a float. Na parte do desenvolvedor A, adicione o seguinte método ao código antes de fazer um update: public float divisao(float dividendo, float divisor){ if(divisor!=0) return dividendo/divisor; return 0; Até aqui não introduzimos nenhum conflito a operação update seria automática. Para que haja conflitos, devemos editar partes iguais do programa. Para testar esta situação, vamos alterar o método multiplicacao para que fique da seguinte forma: public double multiplicacao(double a, double b){ return a*b; Agora faça um merge entre esta nova versão e a do repositório com o comando update. O JBuilder envia uma mensagem dizendo que houve um ou mais conflitos durante a operação de merge. Na verdade houve apenas um conflito, o que introduzimos no método multiplicacao. Para tratar deste conflito, clique na aba History de A e dentro da interface que aparece, selecione a aba Merge Conflicts. Nesta tela são mostradas as duas versões da linha em conflito (a do workspace A e a do repositório) na 32

33 parte superior, e na parte inferior vemos a versão final com os conflitos resolvidos. Por padrão o JBuilder mantém as alterações feitas pelo usuário e não a do workspace, e estão destacadas em verde. Mas como sabemos que a versão de multiplicacao de A está errada propositalmente, vamos selecionar a versão do repositório para ser mantida. Assim, procure na versão do repositório a linha em conflito e clique no marcador ao lado esquerdo da linha para tornar a versão do repositório a oficial. Note que as cores de destaque mudam de vermelho para verde no repositório e de verde para vermelho no workspace de A: Figura 21: Solucionando Merge Conflicts Feito isto, clique no botão Apply e verifique se está tudo correto na aba Source. Neste exemplo, criamos apenas uma fila de versões, mas caso tenhamos dúvidas sobre o que manter ou não durante conflitos, podemos criar ramificações para separar uma versão em duas. Para isso, use o comando Team CVS Administration... Create Branch.... Para navegar entre as diferentes versões criadas, podemos usar as outras abas de History. Na Aba Contents podemos ler o conteúdo de cada versão. Na Aba Info lemos os comentários que adicionamos quando criamos cada versão com o comando commit. Na Aba Diff podemos comparar diferentes versões entre os arquivos. O JBuilder destaca blocos de diferenças para facilitar a localização. 33

34 Figura 22: Comparando duas versões na aba History 34