Arquivo Discussoes de Programacao e Tecnologia Pelo oq eu entendi no TDD o programador vai descobrindo c o tempo o que é necessário p o programa.
Ja a UML é o inverso, primeiro vc analisa primeiro e depois coloca a mão na massa.
A pergunta é um vai contra o outro?
E’ possivel trabalhar c os dois juntos? (como?)
Valeu
TDD amigo é Desenvolvimento dirigo por teste
que tudo é testado, mas que eu saiba não há relação com o que voce falou, acho que vc esta confundido as coisas
Camarada, reveja o quanto antes o que você entende por TDD.
Primeiro que eles são conceitos e ferramentas utilizadas em etapas diferentes do processo de desenvolvimento de um sistema.
Oi Skim,
não há nada de um contra o outro. Na realidade, na TDD você também tem análise, pois primeiro define a interface e os comportamentos esperados pelo seu código alvo e só depois o implementa para que passe nos testes.
Eu sei disso companheiro, mas um naum interverre no outro, o que voce falou no primeiro topico esta errado, pois num primeiro momento voce faz uso da uml para modelar seu sistema, desenha casos de uso, diagramas e etc.
quanto voce começa a programa-lo voce pode usar o TDD, desenvolvimento dirigido a teste, que diz que todas classe construida deve ser testada para se ter a certeza de que ela esta funcionando e assim voce tem um sistemas 100% testavel, e bem menos sucetivel a erros.
pois tudo o que foi construido foi testado.
ou seja uml e tdd pode ser usados em conjunto pois sao usado em estagios diferentes do desenvolvimento de um sistema e possuem finalidades diferentes…
A UML é usada principalmente para mostrar como os objetos se conversam ou integram-se , já a TDD: é útil para auxiliar o programador a focar seus esforços em partes menores do sistema e, a partir daí, construir o todo.
Trabalhar em unidades menores, através de testes, reduz a complexidade e permite o desenvolvimento de uma aplicação ?de dentro para fora?, pois o desenvolvedor trabalha diretamente no modelo, além de favorecer o baixo acoplamento e a alta coesão dos componentes criados.
Pelo oq eu entendi no TDD o programador vai descobrindo c o tempo o que é necessário p o programa.
Ja a UML é o inverso, primeiro vc analisa primeiro e depois coloca a mão na massa.
A pergunta é um vai contra o outro?
E’ possivel trabalhar c os dois juntos? (como?)Valeu
Amigo, você está confundindo UML e TDD com metodologias, coisa que nenhum dos dois é.
UML é uma linguagem utilizada para escrever documentação. É possível escrever documentação em metodologias ágeis (que, em geral, são as que mais utilizam TDD)? É, é possível. Só não recebe a mesma ênfase que em metodologias mais tradicionais como waterfall, RUP, etc.
Já TDD não está preso a nenhuma metodologia em particular. Esta técnica tem sido mais adotada por metodologias ágeis pelo fato de que estas dão mais ênfase a software funcionando (e com qualidade) do que à documentação.
De novo: UML e TDD não são conflitantes entre sí. Em geral, elas têm cenários onde são mais aplicadas (como UML -> metodologias tradicionais e TDD -> metodologias ágeis), mas continuam não sendo conflitantes.
[]'s
Eu sei disso companheiro, mas um naum interverre no outro, o que voce falou no primeiro topico esta errado, pois num primeiro momento voce faz uso da uml para modelar seu sistema, desenha casos de uso, diagramas e etc.quanto voce começa a programa-lo voce pode usar o TDD, desenvolvimento dirigido a teste, que diz que todas classe construida deve ser testada para se ter a certeza de que ela esta funcionando e assim voce tem um sistemas 100% testavel, e bem menos sucetivel a erros.
pois tudo o que foi construido foi testado.ou seja uml e tdd pode ser usados em conjunto pois sao usado em estagios diferentes do desenvolvimento de um sistema e possuem finalidades diferentes…
Só uma correção: segundo um autor (infelizmente, não me lembro qual), você deve testar tudo que “pode dar de errado”. Isso exclui aquelas típicas classes VO, por exemplo, que são puros “sacos de dados” e que não têm comportamento algum.
[]'s
Veja bem, a UML é simplesmente uma linguagem gráfica para descrever classes, objetos e outros aspectos do sistema, como interação entre objetos e estados. Muitas pessoas confundem UML com metodologia, e isso é um erro.
Assim, considerando que UML é apenas uma linguagem, não há como ela contradizer o TDD. Agora, o que realmente contradiz o TDD é o famos Big Design Up Front, ou seja, projetar todo o sistema antes de começar a implementá-lo.
Na prática, tomar o TDD fora de contexto também não faz muito sentido, pois ele é apenas uma técnica, e não uma metodologia completa. No contexto da XP (eXtreme programming) por exemplo, estórias de usuário devem ser implementadas e integradas em ciclos incrementais, não havendo espaço para o BDUF. Nesse contexto, você pode até utilizar UML para esboçar o domínio do problema ou uma arquitetura inicial, porém o que interessa é adicionar funcionalidades ao sistema mas com a disciplina de não quebrar o que já está pronto.
Por fim, eu acho muito importante diferenciar o que são ferramentas, práticas, metodologias, papéis, processos e valores. Do contrário, você corre o risco de assumir certas “verdades” para a atividade de desenvolvimento que acabam por atrapalhar a entrega de valor.
Pelo oq eu entendi no TDD o programador vai descobrindo c o tempo o que é necessário p o programa.
Ja a UML é o inverso, primeiro vc analisa primeiro e depois coloca a mão na massa.
A pergunta é um vai contra o outro?
E’ possivel trabalhar c os dois juntos? (como?)Valeu
Acho que você pode até usar os dois juntos, só não deixa o cliente saber que vc vai deixar pra ver na hora. rs
Mas em todo caso, se você tem clientes precisa analisar primeiro qual o problema dele, para só então colocar a mão na massa.
Amigo, você está confundindo UML e TDD com metodologias, coisa que nenhum dos dois é.
UML é uma linguagem utilizada para escrever documentação. É possível escrever documentação em metodologias ágeis (que, em geral, são as que mais utilizam TDD)? É, é possível. Só não recebe a mesma ênfase que em metodologias mais tradicionais como waterfall, RUP, etc.
Já TDD não está preso a nenhuma metodologia em particular. Esta técnica tem sido mais adotada por metodologias ágeis pelo fato de que estas dão mais ênfase a software funcionando (e com qualidade) do que à documentação.
De novo: UML e TDD não são conflitantes entre sí. Em geral, elas têm cenários onde são mais aplicadas (como UML -> metodologias tradicionais e TDD -> metodologias ágeis), mas continuam não sendo conflitantes.
[]'s
Acho que você esta falando da UML dos livros. Pois eu conheço várias grandes empresas onde UML é usado pra muito mais que documentação.
Amigo, você está confundindo UML e TDD com metodologias, coisa que nenhum dos dois é.
UML é uma linguagem utilizada para escrever documentação. É possível escrever documentação em metodologias ágeis (que, em geral, são as que mais utilizam TDD)? É, é possível. Só não recebe a mesma ênfase que em metodologias mais tradicionais como waterfall, RUP, etc.
Já TDD não está preso a nenhuma metodologia em particular. Esta técnica tem sido mais adotada por metodologias ágeis pelo fato de que estas dão mais ênfase a software funcionando (e com qualidade) do que à documentação.
De novo: UML e TDD não são conflitantes entre sí. Em geral, elas têm cenários onde são mais aplicadas (como UML -> metodologias tradicionais e TDD -> metodologias ágeis), mas continuam não sendo conflitantes.
[]'s
Acho que você esta falando da UML dos livros. Pois eu conheço várias grandes empresas onde UML é usado pra muito mais que documentação.
Fale mais.
Fale mais.
Você sabe, construir o sistema.
Fale mais.Você sabe, construir o sistema.
Como você constrói um sistema a partir de UML?
O próprio Kent Beck falou isso:
Como você constrói um sistema a partir de UML?
Você pode começar pelos requisitos.
Como você constrói um sistema a partir de UML?Você pode começar pelos requisitos.
Humn… entendí. De acordo com seu entendimento, requisitos não são documentação, mas peças de software funcionando.
Humn… entendí. De acordo com seu entendimento, requisitos não são documentação, mas peças de software funcionando.
What?
Humn… entendí. De acordo com seu entendimento, requisitos não são documentação, mas peças de software funcionando.What?
Amigo, você veio e disse que “UML é usada para muito mais coisas além de documentação”. Eu perguntei para o que mais, e você disse que constrói sistemas com ela. Quando eu pedí explicações a respeito, você disse que começa pelos requisitos - como se requisitos NÃO fossem documentação.
“What???” digo eu.
Obrigado a todos pelas repostas.
Eu fiz essa pergunta pq sei pouco de UML e nada de TDD e queria começar a ler sobre um deles, e se um fosse contra o outro n seria produtivo ficar perdendo tempo c um dos dois.
Agora q entendi q os dois podem trabalhar juntos (em fases diferentes) posso estudar sobre os dois.
So’ uma coisa, aproveitando a deixa do Alexandre e Jose Ignacio, eu estava lendo um artigo q dizia q UML n é documentaçao. Oq dava a entender é q a uml serve p dar uma ajuda na analise e p os programadores.
http://www.aspercom.com.br/ead/mod/resource/view.php?id=268
Na minha opiniao, n deixa de ser documentaçao.
Um abraço e mais uma vez obrigado pelas respostas.
Obrigado a todos pelas repostas.
Eu fiz essa pergunta pq sei pouco de UML e nada de TDD e queria começar a ler sobre um deles, e se um fosse contra o outro n seria produtivo ficar perdendo tempo c um dos dois.
Agora q entendi q os dois podem trabalhar juntos (em fases diferentes) posso estudar sobre os dois.
So’ uma coisa, aproveitando a deixa do Alexandre e Jose Ignacio, eu estava lendo um artigo q dizia q UML n é documentaçao. Oq dava a entender é q a uml serve p dar uma ajuda na analise e p os programadores.
http://www.aspercom.com.br/ead/mod/resource/view.php?id=268
Na minha opiniao, n deixa de ser documentaçao.Um abraço e mais uma vez obrigado pelas respostas.
Veja bem, o que é o Rodrigo Yoshima quis mostrar no artigo da MundoJava é que a UML não serve para documentar o código. Ou seja, ele quer dizer que UML não serve para documentar código que já está pronto. É o que ele deixa claro no trecho:
Por outro lado, isso não contradiz com o que o Alexadro está dizendo. Segundo o artigo, a UML pode ser uma ferramenta muito útil no levantamento de requisitos e na análise do sistema, porém o resultado dessas etapas também são documentação, como o autor do artigo também deixa claro:
Enfim, na minha opinião, tanto a UML como o TDD são ferramentas relevantes no desenvolvimento de software. Acho que vale a pena conhecer as duas e entender o momento de utilizar cada uma.
Fale mais.
Você sabe, construir o sistema.
Como você constrói um sistema a partir de UML?
Fala sério, vocês estão dando uma de doidos de propósito né?? kkk :shock:
Eu acho que “UML” no contexto em que esse tópico foi aberto não se refere à linguagem UML. O que ele quis dizer por UML é:
E aí sim a pergunta faz sentido, essa prática poderia conviver com o TDD ?
Sim. Mas isso é atribuir a UML um sentido que ela não tem. A UML é uma linguagem gráfica e ponto. Ela não é atrelada a nenhum processo ou metodologia específica, embora algumas metodologias recomendem o uso da UML.
Enfim, isso que você citou é o famoso Big Design Up Front, uma prática rejeitada pela maioria das metodologias modernas.
Fala sério, vocês estão dando uma de doidos de propósito né?? kkk :shock:Eu acho que “UML” no contexto em que esse tópico foi aberto não se refere à linguagem UML. O que ele quis dizer por UML é:
E aí sim a pergunta faz sentido, essa prática poderia conviver com o TDD ?
Pode conviver porque não esta proibido nos manuais, mas na prática não faz sentido.
Se vc parte do pressuposto que o sistema será criado todo antes, porque usar uma técnica que ajuda a descobrir o que construir com o tempo?
Sim. Mas isso é atribuir a UML um sentido que ela não tem. A UML é uma linguagem gráfica e ponto. Ela não é atrelada a nenhum processo ou metodologia específica, embora algumas metodologias recomendem o uso da UML.Enfim, isso que você citou é o famoso Big Design Up Front, uma prática rejeitada pela maioria das metodologias modernas.
Na verdade foi isso que ele disse, que UML esta atrelado a BDUF.
Ele nem sequer citou processos ou metodologias.
Sim. Mas isso é atribuir a UML um sentido que ela não tem. A UML é uma linguagem gráfica e ponto. Ela não é atrelada a nenhum processo ou metodologia específica, embora algumas metodologias recomendem o uso da UML.Enfim, isso que você citou é o famoso Big Design Up Front, uma prática rejeitada pela maioria das metodologias modernas.
Na verdade foi isso que ele disse, que UML esta atrelado a BDUF.
Ele nem sequer citou processos ou metodologias.
Bom, mas o fato é que UML não está atrelada a BDUF, nunca esteve.
Fala sério, vocês estão dando uma de doidos de propósito né?? kkk :shock:Eu acho que “UML” no contexto em que esse tópico foi aberto não se refere à linguagem UML. O que ele quis dizer por UML é:
E aí sim a pergunta faz sentido, essa prática poderia conviver com o TDD ?
Pode conviver porque não esta proibido nos manuais, mas na prática não faz sentido.
Se vc parte do pressuposto que o sistema será criado todo antes, porque usar uma técnica que ajuda a descobrir o que construir com o tempo?
E’ ai’ que ta a raiz da questão.
Eu sei q n existem regras q proíbem o uso dos dois, mas se já n faz sentido usar os dois no mesmo projeto, eu traduzo como se fosse já uma regra p evitar de usá-los juntos.
Portanto eu posso até estudar os dois, porém eu deixaria um deles p um futuro mais distante.
Fala sério, vocês estão dando uma de doidos de propósito né?? kkk :shock:Eu acho que “UML” no contexto em que esse tópico foi aberto não se refere à linguagem UML. O que ele quis dizer por UML é:
E aí sim a pergunta faz sentido, essa prática poderia conviver com o TDD ?
Pode conviver porque não esta proibido nos manuais, mas na prática não faz sentido.
Se vc parte do pressuposto que o sistema será criado todo antes, porque usar uma técnica que ajuda a descobrir o que construir com o tempo?
E’ ai’ que ta a raiz da questão.
Eu sei q n existem regras q proíbem o uso dos dois, mas se já n faz sentido usar os dois no mesmo projeto, eu traduzo como se fosse já uma regra p evitar de usá-los juntos.
Portanto eu posso até estudar os dois, porém eu deixaria um deles p um futuro mais distante.
Mas faz todo sentido usar UML e TDD no mesmo projeto, desde que não haja redundâncias. O que eu acho bobagem é detalhar cada classe do sistema com UML, isso é perda de tempo. Porém, você pode usar a UML para modelar o workflow do sistema, como o sistema será implantado, entre outras coisas.