Passos para a prova SCJP

Esta é a primeira das certificações Java. Na verdade é a segunda depois da criação da SCJA que é uma prova mais global. Como primeiro passo para a certificação, uma vez que vc adquiriu o voucher como explicado em http://portalarquiteto.blogspot.com/2008/03 é então se preparar para a prova.

E esta é a pior parte. Para a preparação então é interessante ler algum livro e também fazer provas sobre o assunto. Como livro aconselho que você dê uma olhada em 2 que são muito interessantes.

Um é o SCJP Sun Certified Programmer for Java 5 Study Guide que é um livro da Katie Sierra mais voltado para a certificação. Existe neste livro várias questões da prova com resposta e também explicação para as respostas. Este não é um livro para explicar passo a passo a linguagem, mas sim para te treinar para a certificação.

Outro livro muito bom também, que foi o que estudei e se chama Head First Java, 2nd Edition. Ele explica muito melhor sobre a linguagem e sobre sua lógica em sí, mas não explica muito sobre a prova. É uma leitura muito bacana (pelo menos eu achei), mas não é muito voltada para a certificação.

Vale a pena também estudar através de provas e simulados que se encontram nos seguintes sites abaixo:

• http://www.javaranch.com
• http://www.danchisholm.net
• http://www.michael-thomas.com/tech/java/index.html
• http://www.tipsmart.com
• http://www.whizlabs.com

Existem alguns programas que possuem simulados da mesma maneira, mas realmente nunca comprei, mas sei que são muito bons para quem quiser fazer a prova com mais tranquilidade.

Para quem for se aventurar a fazer as provas boa sorte e estudem porque não é tão simples como a maioria acha. Vou tentar postar mais posts, mas realmente estas semanas estão muito corridas, pois estou entregando minha monografia da pós.

Passos para realizar certificações SUN

A sequência de passos que vc precisa para qualquer certificação da SUN são:

1. Se prepare para os exames da maneira que você achar necessário.
2. Contate os Serviços Educacionais Sun para adquirir um voucher de testes ligando para 0800-55-78-63. (Os vouchers demoram algum tempo pra chegar)
3. De posse dos vouchers, marque seu teste em um local que seja mais conveniente através do site www.prometric.com.
4. Faça o teste no local e data indicada.

Como para realizar os testes da Sun não é necessário fazer o treinamento com eles, cada um se prepara da maneira que achar conveniente. Meu conselho pessoal é estudar por algum livro e se possível fazer alguns simulados.

Algumas pessoas também acham melhor comprar o voucher e depois se preparar, pois ele demora um pouco para chegar. Depois de comprar o voucher você tem um ano para utilizá-lo e isto é importante, pois muita gente perde a data.

Há também sites que disponibilizam conteudo e provas na web tais como:

• http://www.javaranch.com
• http://www.danchisholm.net
• http://www.michael-thomas.com/tech/java/index.html
• http://www.tipsmart.com
• http://www.whizlabs.com

A sequência de certificações é:
Para as provas SCEA, SCJA e SCJP não existe nenhum pré-requisito. Para o restante é necessário possuir a certificação SCJP que por sinal é a mais procurada.

Vou tentar postar ao longo destas semanas mais detalhes sobre algumas destas certificações.

Porque integrar mantis e subversion

Hoje me perguntaram sobre qual o benefício de se integrar o Mantis e o Subversion e então resolvi escrever este post. No ultimo serviço trabalhávamos com o Bugzilla, o SVN e também com o Cruise control.

Então a seqüência de passos lá era a seguinte:

1. Desenvolvíamos nossa parte do sistema e subíamos com nossas alterações para o SVN.
2. Então o Cruise control executava a integração de tudo que todo mundo mexeu.
3. Para cada vez que o Cruise control integrava e executava os testes de unidade com sucesso era gerada uma nova versão no SVN.
4. Então os testadores procuravam os erros nas versões geradas pelo Cruise Control (e consequentemente também no SVN).
5. Se achassem algum erro era cadastrado no Bugzilla junto com o número da versão do SVN.
6. Uma vez encontrado o erro este era corrigido e era colocada a versão provável em que a correção já estaria corrigida. Neste caso era mais uma estimativa, porque queríamos evitar que os testadores verificassem erros corrigidos antes deste ter sido integrado pelo Cruise Control.

Esta era a seqüência normal. No nosso caso não existia integração entre o SVN e o Bugzilla e então a gente olhava no Cruise control e colocava na mão o número da versão. Esta versão era importante para depois conseguirmos ver quando o erro ocorreu e também funcionava como uma proteção para os testadores. O pessoal só poderia colocar o erro como inválido se fosse testado na mesma versão em que o erro foi cadastrado.

Não utilizei ainda os dois integrados ainda, mas a integração é então importante para que você cadastre o erro para a versão correspondente e para que a ferramenta te auxilie com isto.

Diagrama de objetos

Na prática este é mais um dos diagramas muito pouco utilizados. O diagrama de objetos é uma variação do diagrama de classes e utiliza quase à mesma notação. O diagrama de objetos é como se fosse o perfil do sistema em certo momento de sua execução.

Existem apenas duas diferenças entre o diagrama de classes os objetos são escritos com seus nomes sublinhados e todas as instâncias num relacionamento são mostradas. Este diagrama é importante para se ter uma visão do sistema em determinado tempo e para se conferir se os dados estão atribuídos corretamente no tempo e se são consistentes.

Segue abaixo um exemplo de um diagrama de objetos:

O exemplo acima mostra um diagrama de objetos para o cliente Michael Richardson e seus dois pedidos na Virtual LTDA. O diagrama pode ser lido da seguinte maneira: O objeto R. Michael Richardson da classe Cliente está associado a ambos os objetos 123456 e 123700 da classe Pedido. Usa-se o diagrama de objetos para modelar a visão estática de um sistema. Ele mostra o retrato do sistema em determinado momento.

É isto aí pessoal. Qualquer problema entrem em contato...

Diagrama de robustez

Este é um diagrama que não existe na UML e é geralmente um diagrama de colaboração adaptado e que faz uso dos estereótipos entity, boundary e control. Ele é utilizado em processos como o ICONIX para passar da análise (o que) para o desenho (como).

Através da análise de robustez, podemos fazer a verificação de sanidade, isto é, a verificação se o texto do caso de uso está correto e que ele não representa para o sistema que não é razoável ou impossível.

Este é um diagrama que não é necessário ser mantido atualizado uma vez que é utilizado apenas para a transição. Sendo assim, ao criar os diagramas, é perfeitamente plausível usar apenas lápis e papel.

A análise de robustez consiste então em ler o texto do caso de uso e identificar de forma preliminar, o conjunto de objetos que irão participar do caso de uso. Em seguida deve-se percorrer cada passo do caso de uso desenhando os atores, as classes de fronteira, os controladores, as entidades e a conexões entre elas.

As seguintes regras devem ser obedecidas:

1. Atores interagem apenas com objetos de fronteira (boundary)
2. Objetos de fronteira podem interagir com atores e controladores.
3. Objetos de entidade interagem apenas com controladores
4. Controladores interagem com qualquer outro tipo de objeto e também com outros controladores, mas nunca com atores.