Pesquisar

quarta-feira, 18 de fevereiro de 2009

UseCASE Generator - Viva a documentação





Se você está atualmente empregado em uma empresa que adota documentações parecidas com isso abaixo:










---------------------------------------
Identificação: 1
Envolvidos: Mariana, Pedro e Luís
Caso de Uso: Manter Empregado
Ações:
  1. Clicar em novo Empregado.
  2. Inserir dados (nome, cpf, nascimento, salário, departamento) do Empregado.
  3. Clicar em salvar.
Exeções:
  1. Empregado não encontrado.
  2. Não foi possível salvar.
---------------------------------------

ou

---------------------------------------
Identificação: 2
Envolvidos: Mariana, Pedro e Luís
Caso de Uso: Manter Departamento
Ações:
  1. Clicar em novo Departamento.
  2. Inserir dados (nome, sala) do Departamento.
  3. Clicar em salvar.
Exeções:
  1. Departamento não encontrado.
  2. Não foi possível salvar.
---------------------------------------

Logo você precisa do UseCASE Generator Java V. 1.0 OpenSouce. (apesar de ser opensource o código não está disponível :P faça o seu)

Veja a API riquíssima.
public String createUseCase(int id, String[] stakeHolders, String entity, String[] properties);

Exemplo de uso:

String minhaSalvacao = useCASEGenerator.createUseCase(1,
new String{"Mariana","Pedro","Luís"},
"Empregado",
new String{"nome", "cpf", "nascimento", "salário", "departamento"});
System.out.println(minhaSalvacao);

Notou como é simples...
Pense rápido: se você consegue generalizar criar "case use generator" logo você não precisa documentar, apenas escreva um programa (já que sua empresa exige isso) que faça isso pra você.

PS: Essa ideia do UseCASE Generator é de um amigão (Marlos) e já está patenteada, portanto crie seus próprios UseCASE Generator e viva a documentação.

TDD - Desenvolvimento Guiado por Testes

Sei que esse assunto já foi e é explorado em n locais de n diferentes formas, mesmo assim vejo gente "confundindo tudo" e perguntas do tipo:
  • Posso usar DDD com TDD? (sim)
  • TDD pode ser usado em processos não-ageis? (sim)
  • TDD não é perda de tempo? (eu acho que não)
  • Faço testes no meu processo, estou usando TDD? (depende)

A teoria de testes no desenvolvimento de sistemas é extensa, neste pequeno post não será possivel explicar cada conceito por tras dela ao contrário disso irei tentar explicar apenas o Ciclo (descaradamente inspirada no exemplo do livro).

Ciclo
1º Adicione um teste
Antes mesmo de criar o código real que irá ser testado.
2º Rode os testes e veja se os novos falham
Primeiro faça o teste falhar, geralmente escrevemos código falso.
ex: assertEquals("esperado",objeto.getRetornaNull());
3º Escreva um pouco de código
Escreva um pouco de código para fazer o teste funcionar.
4º Rode os testes automatizados e os veja funcionando
Agrege-os a sua base de testes automatizados (que pode ou deve ser rodado sempre num processo de build automatizado também).
5º Refatore o código
Agora você pode ter o tempo pra dar uma melhorada no design atual, refatoração é a ordem.
ps: refatore tanto o código da aplicação quanto os testes.
6º Volte para o passo 1
Apenas a repetição do processo. (claro que em uma nova estoria/caso de uso/whatever)

Pra finalizar minha opinião: testes são tão importantes quanto o código final . (é algo que atesta sua qualidade executavel.) ahh e leia um bom livro sobre TDD acredito que irá achar a leitura agradavel.