[quote=Skim]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[/quote]
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[/quote]
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[/quote]
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.[/quote]
[quote=JoseIgnacio][quote=Alexandre Saudate]
Humn… entendí. De acordo com seu entendimento, requisitos não são documentação, mas peças de software funcionando. [/quote]
What?[/quote]
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.
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.
[quote=Skim]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.[/quote]
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.
[quote=Alexandre Saudate][quote=JoseIgnacio][quote=Alexandre Saudate]
Fale mais. [/quote]
Você sabe, construir o sistema.[/quote]
Como você constrói um sistema a partir de UML?[/quote]
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.
[quote=rmendes08]
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.[/quote]
Na verdade foi isso que ele disse, que UML esta atrelado a BDUF.
[quote=JoseIgnacio][quote=rmendes08]
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.[/quote]
Na verdade foi isso que ele disse, que UML esta atrelado a BDUF.
Ele nem sequer citou processos ou metodologias.[/quote]
Bom, mas o fato é que UML não está atrelada a BDUF, nunca esteve.
[quote=JoseIgnacio][quote=gomesrod]
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 ?[/quote]
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?[/quote]
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.
[quote=Skim][quote=JoseIgnacio][quote=gomesrod]
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 ?[/quote]
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?[/quote]
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.
[/quote]
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.