Elizeu_Santos wrote:li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.

alguém quer falar sobre isso?

Elizeu_Santos wrote:li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.

alguém quer falar sobre isso?

Giulliano wrote:

Elizeu_Santos wrote:li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.

alguém quer falar sobre isso?

Meus professores sempre diziam: se for buscar informação, busque de uma fonte confiável.

YvGa wrote:

Giulliano wrote:

Elizeu_Santos wrote:li em alguns tópicos pessoas falando em substituir UML pelo TDD o que para mim foi um choque pois para mim são metodologias com propósitos distintos que devem andar lado a lado. Não postei links por que estou na empresa e a maior parte dos links estão bloqueados.

alguém quer falar sobre isso?

Meus professores sempre diziam: se for buscar informação, busque de uma fonte confiável.

Concordo.

E para ajudar a entender o que é de fato fonte confiavel eu digo o que, pra mim, nao eh: Blog.

Livros sao fontes confiaveis, procure neles o que voce precisa. Blog é otimo pra voce ler uma outra visao, ou nao, de um assunto que voce ja conhece. Como aprendizado eles tem muito pouco a oferecer, normalmente.

Sobre o post, eu entendi a opiniao do autor e concordo em alguns pontos, mas eh bem superficial, o que acaba confundindo mesmo. A comparacao pode parecer estranha a principio, mas acho que a intencao era de mostrar que com TDD vc nao precisa de UML, pelo menos nao da UML documentacao (UML eh bastante eficiente para comunicacao). Na verdade eh uma forma diferente, e um pouco estranha, de fazer a velha comparacao Agil x Cascata.

s4nchez wrote:Fico feliz que quase 4 anos depois esse meu post ainda chama atencao de alguns. Por outro lado, fico surpreso que ainda tem gente ficando chocado com o que esta escrito ali.

Elizeu, voce pode explicar um pouco melhor o que quis dizer com "metodologias com propositos distintos que devem andar lado a lado"?

starkiller wrote:Cara, pra mim o tdd vem pra complementar UML e vice-versa, se você poder usar os dois é bem melhor. UML dá uma melhor visão de seu sistema, baseando-o em modelos, assim cada participante tem uma visão do sistema de acordo com sua especialização. Trabalhei com TDD e realmente é bem versátil vc desenvolver um sistema já prevendo os bugs. O produto final fica muito mais estável e fica mais dificil de ocorrerem bugs. Mas nada impede de se usar UML. A pessoa que escreveu esse artigo tem uma visão bem limitada, restringindo UML a apenas diagramas de Classe, pois esta vai muito além, sendo uma linguagem unifica que baseia todo seu sistema em Modelos. Em Uml, temos diagramas de classes, caso de uso, configuração, deploy e por ai vai, deixando seu sistema muito bem documentado e de fácil entendimento por todos envolvidos no sistema. Então, dizer que se deve trocar uma pela outra é uma afirmação extremista demais e até imbecil, já que as duas tem propostas diferentes!

immortalSoul wrote:
Estranho não, é muito comum e até é compreensivel.
Como disse antes, é a questão do foco. Quando se da enfase no UML normalmente a empresa está dando enfase no processo e na documentação como suporte a esse processo. ( Isso não é regra, mas é uma generalização 'aceitavel')
O TDD inverte as coisas e coloca o foco no resultado(dos testes). A documentação do teu sistema e de tuas regras são os próprios casos de teste ( mais ainda digo que isso está mais pra BDD ).
Raramente uma empresa vai adotar formalmente a UML tendo como foco a comunicação ( apesar da utilização dos artefatos para comunicação ser inerente aos processos ). E indo um pouco além, a UML pode no máximo complementar a comunicação. Ela SOZINHA não é adequada o suficiente nem mesmo para comunicação.