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.

Diagrama de componentes

O Diagrama de componentes da UML ilustra como as classes deverão se encontrar organizadas através da noção de componentes de trabalho. O diagrama tem por objetivo apresentar a disposição dos componentes físicos de um sistema.

O principal objetivo deste diagrama segundo Scott Ambler, é possibilitar a construção de artefatos para o perfil de arquitetura da solução, seja para a arquitetura técnica ou a de negócios.

O diagrama é composto normalmente por componentes, interfaces e portas. Os componentes são representados pelo estereótipo da uml <> ou um retângulo vertical de duas hastes. Interfaces são representadas através de uma linha com um círculo ou semicírculo ligado ao componente. Portas são representados através de retângulos saindo dos componentes.

Normalmente é utilizado para:

• Modelar os componentes do código-fonte, do código executável do software.
• Destacar a função de cada módulo para facilitar a sua reutilização.
• Auxiliar no processo de engenharia reversa, por meio da organização dos módulos do sistema e seus relacionamentos.

Retirado de http://www.rnp.br

Diagrama de máquina de estados

O diagrama de máquina de estados era conhecido nas versões anteriores como diagrama de gráfico ou simplesmente como diagrama de estados, tendo então mudado para este novo nome após a versão 2.0. Este diagrama procura acompanhar as mudanças sofridas nos estados de uma instância de uma classe ao longo da execução de um caso de uso, subsistema ou mesmo sistema.

O Diagrama de máquina de estados muitas vezes se baseia no caso de uso e se apóia no Diagrama de Classes.

Retirado de http://www.comp.ita.br/~olany/State_Diag2.jpg

O diagrama acima mostra um diagrama de máquinas de estado. Este diagrama mostra como ocorrem as alterações nos estados de um objeto após terem sido realizados ações sobre este.

Diagrama de Comunicação

O diagrama de comunicação é o antigo diagrama de colaboração até a versão 1.5 da UML, tendo modificado seu nome a partir da versão 2.0. Este é um diagrama bem parecido com o diagrama de seqüência, mas não possui seu aspecto temporal.

Ele normalmente é utilizado como complemento do diagrama de seqüência, porem possui um enfoque diferente, concentrando-se em como os objetos estão vinculados através de mensagens. Pode ser gerado a partir do diagrama de seqüências por representar os mesmos dados. Outra característica do diagrama de comunicação é que as mensagens possuem numeração para designar seqüência.

Figura retirada de http://www.novatec.com.br

Nesta figura é mostrado o diagrama de comunicação do caso de uso realizar submissão. É mostrado as mensagens trocadas entre o Submissor, a página do congresso, o controlador do congresso, o tema e a Submissão.

Diagrama de estrutura composta

Olá pessoal,

Quis hoje começar a debater sobre alguns diagramas da uml 2.0 que são pouco utilizados. O primeiro da lista de diagramas pouco utilizados é o diagrama de estrutura composta.

O diagrama de estrutura composta é utilizado para modelar colaborações. Uma colaboração descreve uma visão de um conjunto de entidades cooperativas interpretadas por instâncias que cooperam entre si para executar uma função específica.

Então podemos dizer que o diagrama de estrutura composta reflete a colaboração interna das classes para descrever a funcionalidade. São bem similares aos diagramas de classes, exceto pelo fato de que eles modelam um uso específico da estrutura.

Retirado de http://www.novatec.com.br

O termo estrutura se refere à composição dos elementos estruturais interconectados de forma a atingir algum objetivo comum. O exemplo acima mostra como as instâncias das classes autor, submissão, tema e tipo colaboram entre si para submeter à submissão. As colaborações podem também possuir multiplicidade, se as regras seguidas pelas classes utilizarem múltiplas instâncias.

Este é um diagrama que não é muito utilizado na UML e provavelmente é mais um diagrama teórico do que um diagrama utilizado nos processos de desenvolvimento.