Coding Dojo Floripa

Desenvolvimento Ágil

UML vs TDD

Posted by Ivan Sanchez em Quarta-feira, Maio 2, 2007

Aqui estão os principais benefícios que as pessoas buscam com UML, e uma análise resumida de como é possível (ou não) obtê-los com Test-Driven Development (TDD):

Análise prévia do problema

Se você precisa explorar o que o sistema deve fazer exatamente, o que pode ser melhor do que trabalhar como se ele já existisse? Os testes em TDD permitem isso, e de quebra ainda permitem validar o que foi implementado posteriormente. Ponto para TDD neste quesito.

Resultado parcial: UML 0 x 1 TDD

Reutilização de código

Aqui as duas abordagens trabalham de maneira muito distintas. Enquanto em UML tentamos identificar os pontos de reutilização antes, em TDD você deixa que estes pontos apareçam através de duplicações no código, que são removidos e transformados em componentes reutilizáveis com apoio dos testes automatizados. Para não entrar numa discussão sobre BDUF x Agile por enquanto, vamos declarar um empate.

Resultado parcial: UML 1 x 2 TDD

Linguagem unificada para especificação de sistemas

Como o princípio do TDD é especificar o sistema através de testes executáveis, ainda não existe uma ferramenta genérica que seja aplicável para qualquer sistema. Isto se deve ao fato que a execução destes testes automatizados geralmente depende da tecnologia que o sistema utiliza.

Ferramentas como FitNesse fornecem uma linguagem única para escrever testes independente da tecnologia do sistema, porém ainda deixam a desejar no que trata da execução destes testes.

Já para sistemas web, no entanto, o Selenium já desponta como ferramenta que se aplica a qualquer sistema que trabalhe com apresentação em HTML (independente da linguagem utilizada no servidor), o que constitui um cenário bastante abrangente hoje em dia.

Em resumo, se o que você busca é uma linguagem genérica, UML leva uma certa vantagem.

Resultado parcial: UML 2 x 2 TDD

Aumento na qualidade

Ambas as abordagens (se bem utilizadas) apóiam a qualidade, mas nenhuma delas a garante. Então temos mais um empate.

Resultado parcial: UML 3 x 3 TDD

Ferramenta de aprendizado

Não existe diagrama que substitua o que é ver uma determinada parte do sistema funcionando. E com TDD é possível aprender tanto o que o sistema faz (testes funcionais ou de aceitação) quanto como ele funciona internamente (testes de integração, de unidade, de desempenho). Mais um ponto para TDD.

Resultado parcial: UML 3 x 4 TDD

Facilidade na manutenção

Fazer uma mudança no sistema em UML implica em atualizar os diagramas e aplicar estas mudanças no código. Em TDD mudanças são representadas por novos testes automatizados, enquanto os testes já existentes colaboram para analisar o impacto desta alteração no resto do sistema. A vantagem de TDD neste caso é que é possível ver se o sistema está 100% funcionando por inteiro, o tempo todo. Já com UML isso só pode ser feito manualmente ou com apoio de ferramentas de rastreabilidade.

Resultado final: UML 3 x 5 TDD

Conclusão

Quem esperava uma vitória fácil de TDD deve ter ficado decepcionado. A questão é que UML tem seu valor, ainda mais se considerarmos que a maioria dos softwares ainda é construída com ciclos em cascata ou espiral. A minha idéia aqui foi apenas apresentar uma alternativa ao uso de UML e levantar a questão: será que UML é a melhor solução?

A minha parte eu já fiz, lançando a questão. Agora só me resta esperar a resposta dos defensores da UML😉

16 Respostas to “UML vs TDD”

  1. Opa, só uma dúvida, você está sugerindo que ao invés de utilizar a UML eu utilize TDD? ou seja: good bye UML ???

  2. Acho que cada indivíduo e cada equipe precisam escolher por si só o que funciona melhor para eles. Além disso, nada impede de usar as duas abordagens. Como o Ivan mostrou, UML tem suas forças e TDD também e um não precisa necessariamente substituir o outro.

    Artigos deste tipo são bons para mostrar às pessoas que há o outro lado da moeda. Tem gente que joga só de um lado simplesmente por não saber da existência do outro.

  3. Olá Rodrigo,

    Como eu disse no post, UML tem seu valor e inclusive pode ser melhor que TDD em alguns casos, por isso não me arrisco a dizer “largue UML e só use TDD”.

    O Thiago resumiu bem as minhas intenções: só quero mostrar que há um outro lado da moeda. Eu particularmente já abandonei UML faz tempo, mas por enquanto estou mais pra exceção do que regra😉

  4. Opa, tudo certo. Agora uma coisa que eu não sei como funciona no TDD, é o seguinte: Tudo bem, estou desenvolvendo orientado a testes, e ao escrever um teste eu começo a escrever o código para validar o teste e dar início literalmente ao desenvolvimento do meu sistema, mas onde está a especificação desse método? quem disse que esse método deve funcionar assim? etc… No caso, UML e TDD estão em dois extremos, o TDD vamos dizer assim: na camada de baixo, e a UML na camada de cima. comments?

    []s

    Rodrigo

  5. Aí é que está. Com TDD o teste é também a especificação. E esta especificação pode ser de um nível de abstração tão alto quanto um Caso de Uso (Teste de Aceitação) ou quanto um Diagrama de Sequência (Teste de Unidade).

    Sendo assim, UML e TDD não são extremos, são somente abordagens diferentes que podem ser usadas em qualquer nível…

    Talvez este outro post deixe as coisas um pouco mais claras.

    Apropósito, valeu pelos comentários. Acredito que suas dúvidas também são as dúvidas de muita gente que está conhecendo TDD agora. Então espero que eu esteja ajudando e fique a vontade para continuar escrevendo…

  6. A especificação está na sua cabeça (ou na do “cliente”, se você quiser chamar assim), você somente está a formalizando em forma de testes. O mesmo acontece quando se usa UML e vai acontecer para _toda_ abordagem que puder ser escolhida para formalizar especificações.

  7. Ivan e Rodrigo, acho que sobre este assunto é interessante também o artigo antigo aqui do blog com a seqüência de desenvolvimento e o outro de título Você pensa antes de sair programando?

  8. Sou adepto a metodologia ágeis, principalmente pela a agilidade🙂. Eu acho que o ponto mais baixo do TDD é a falta de ferramentas eficientes para testes genéricos, algo mais automatizado.

    Bom post e parabéns pelas informações contidas no seu blog!

  9. Fabricio Brasiliense said

    Não querendo ser chato, mas discordo bastante deste artigo. Pra mim comparar UML com TDD é o mesmo que comparar temperatura com tempo. Como o próprio nome diz UML é uma linguagem de modelagem, uma ferramenta, não vejo o que tem haver com prática de desenvolvimento.

    Quanto a aprendizado, em UML existem diversos diagramas para modelagem statica quanto dinâmica e em estrutura e comportamento.

    Sobre a facilidade de manutenção, hoje existem ferramentas como o together que permitem em tempo real a sincronização tanto de código quanto de diagramas.

    Apenas ressaltar, para mim são coisas diferentes. TDD é uma prática fantástica que resolve muito dos nossos problemas (para programadores, gerentes e clientes). Mas abandonar UML por TDD? Você trocaria javadoc por Scrum?

  10. Salve Fabrício…

    O que TDD e UML tem a ver é simples: os 2 podem ser usados usados para concepção e especificação de sistemas. E é a partir dessas finalidades em comum que eu lancei a comparação. Com certeza UML e TDD possuem outras finalidades, porém eles também compartilham alguns objetivos, e são esses que eu tentei levantar.

    Quanto a aprendizado, se você tiver todos estes diagrama e nenhum teste, você terá confiança de alterar um sistema baseando-se apenas nestes documentos? Qual garantia você terá de que esta mudança não trará nenhum problema? Sobre a manutenção, esta sincronização permite validar se uma mudança causará problemas em tempo de execução?

    Enfim, concordo que eles são coisas diferentes. UML é uma linguagem e TDD uma prática. E só para fim de exemplo, eu já abandonei UML em grande parte porque TDD me traz todos os benefícios que eu preciso e muito mais.

    Então eu que lhe pergunto, por que não abandonar UML por TDD? Porque são coisas diferentes não me soa como um bom motivo (mas estou aberto a discutir, claro)…

  11. […] conversa com Ivan Sanchez sobre SCRUM, Extreme Programming, certificações de metodologias ágeis, TDD, UML, BDD e sobre os Coding Dojos e outros assuntos em […]

  12. luciana said

    Tenhos as duvidas abaixo refente ao XP , podem me ajudar ?

    1 – Como funciona a previsão de tempo e custo do projeto utilizando esta metodologia ?
    2 – È possivel usar APF para estimar ?
    3 – Em uma mesma fábrica de sostware pode ser utilizada duas metodologias, tomando por paramentro por exemplo o tamanho e o grau de dificuldade do sistema ?
    3 – Há alguma preocupação ou planejamento visando as manutenções evolutivas futuras, ou uma certificação do requisito ?
    4 – O cliente assina algum documento confirmando o escopo do produto ?
    5 – Há algum documento de entrada para o teste ?
    6 – Há possibilidades de usar atividades da prateleira como o RUP ou é modular o processo ?

  13. Elizeu said

    deve ser meio complicado criar um sistema enorme sem fazer ao menos 1 diagrama. eu achei o artigo no mínimo tendencioso.

  14. lauro said

    Me desculpem a franqueza… mas esse artigo é uma viagem na maionese! O autor tentou resumir toda a modelagem de software somente utilizando TDD… No final, como serão validadas se as implementações realmente são aquilo que o usuário realmente queria?

  15. Ivan Sanchez said

    No meu caso, as implementacoes sao validadas porque o cliente me ajudou a escrever os testes. Ele eh capaz de escreve-los e le-los, e de quebra ainda posso simplesmente executa-los e ver meu build passando a cada mudanca.

    Agora, como voce valida seus sistemas usando UML? Existe algo que garanta que o seu codigo realmente implementa o que foi definido nos seus diagramas? A nao ser que sua sua preocupacao seja a “validacao” dos diagramas, UML nao eh garantia de implementacao.

    E nao estou resumindo toda a modelagem a TDD. Modelagem ainda eh uma atividade primariamente criativa e que tem mais a ver com comunicacao entre pessoas do ferramentas. Eu uso TDD para representa-la, voce pode usar o que achar mais interessante na sua realidade😉

  16. Ricardo said

    Concordo com o Elizeu e o Fabrício acima. Se olharmos para o RUP/UP/UML, por exemplo, veríamos o TDD apenas na fase de implementação. Não faz sentido comparar com o todo. E dizer que não precisa de um diagrama sequer, é como olhar para os dados tabelados de trajetória de projétil e dizer que “tem certeza” de que é uma parábola…. Também estou aberto à discussão, mas acho que este artigo precisa ser refatorado. Um abraço e parabéns pelo (restante) do blog.

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

 
%d bloggers like this: