Olá pessoal. Seguinte, em algumas empresas, o UML é amplamente utilizado. Às vezes, o programador recebe o UML já pronto,
completo, e só deve preencher a implementação, devendo seguir À RISCA o UML. Essa é uma prática boa? Ou tem várias desvantagens?
Kaizenman, essa é a melhor prática que existe.
Varias empresas acabam por passar as definições de seus projetos a seu programadores na base do papel A4 ou de outras maneiras. Mas o que realmente acontece é que os programadores acabam se confundindo por não entenderem realmente onde o analista quer chegar, ou ate entende mas as vezes como não há um bom entendimento do que é preciso ser feito, o projeto acaba tomando um outro rumo!
É aquela velha historinha…O cliente pede um carro, o gerente imagina um avião, o analista ver uma biscicleta e o programador desenvolve uma roda. :?
Por isso a prática melhor é o uso da UML.
Assim todos procuram ver uma única coisa entende?
( Ou em alguns casos evita a enrrolação de certos companheiros programadores! :lol: )
(Isso evita um pouco também o uso de POG(Programação Orientada a Gambiarra));
Se existe desvantagens eu desconheço.Mas o que posso realmente te passar é que as vantagens são bem maiores que as desvantagens!
Acredito que a representação UML é de fundamental importancia, mas antes de implementar creio que deve-se ter a lista de requisitos bem explicada e entendida pelo programador.
Acredito que O UML não é suficiente para o desenvolvimento. Então essa seria a desvantagem.
"
Concordo, so a UML não ajuda, tem que estar bem explicado as regras do negócio e a metodologia a ser usada na aplicação… Como programador, vejo que isso dificulta certos projetos, na hora de serem realizados…
[quote=kaizenman]Olá pessoal. Seguinte, em algumas empresas, o UML é amplamente utilizado. Às vezes, o programador recebe o UML já pronto,
completo, e só deve preencher a implementação, devendo seguir À RISCA o UML. Essa é uma prática boa? Ou tem várias desvantagens? [/quote]
Eu odiaria isso. É, na minha opinião extrema, nojento.
Restringe a capacidade e a criatividade do programador (que, nesse caso é mais um digitador do que programador). Isso aí é pra empresas que não confiam nos desenvolvedores. Pior prática que isso é impossível… Como que um cara, usando UML consegue ver a real necessidade do cliente? Consegue ver bem por cima, mas na hora de fazer o código sempre tem alguma coisa que falta ou o digitador fica em dúvida. Acho que da UML só deve ser utilizado o básico e sem detalhes.
A melhor abordagem, na minha opinião, é deixar o programador em contato com o cliente direto, sem aquele hierarquia engraçada e gigante de Engenheiro de Requisitos, Engenheiro de Software (que, na verdade, é um modelador que sabe usar UML, um pouco de OO e não sabe (ou tem medo de) escrever código) e por aí vai.
Editado: o resultado dessa hierarquia é aquela figurinha que todos conhecem. O cliente pede uma balança e passa por tanta gente aquela modelagem e aquelas regras de negócio que ela sofre tantas modificações que o programador, que é o coitado e o culpado da história, só fez o que foi pedido - enquanto que se ele tivesse conversado com o cliente, ele entenderia BEM melhor.
Editado2: http://blog.fragmental.com.br/2008/07/25/uh-eme-ele/
É só minha opinião né 
O problema é que a UML é apenas (não que ela não seja importante e não tenha valores) uma ferramenta de apoio e algumas pessoas utilizam ela como ferramenta principal achando que ela vai resolver o projeto; simples assim. Ao utilizar orientação a objetos a abstração aumentou muito; fazendo com que a complexidade do entendimento, elaboração, comunicação se elevasse bastante também e foi aí que surgiu a idéia da UML para nos ajudar.
Quando vc utiliza a UML para expor alguma idéia perceba que os dialogos ficam mais objetivos e enriquecidos; verifica-se muito mais coisas do se vc não estivesse visualizando graficamente o problema em questão.
Quando um problema estiver confuso, causando muitas divergencias com dificuldade de chegar em uma idéia interessante; utiilze a uml e vc vai ver o resultado, faça este teste. Aqui no guj existem alguns casos assim, a pessoa expôs o problema e logo depois colocou o diagrama; vc vai perceber que a thread ficou mais curta e a DISCUSSÂO (essa é a idéia) mais produtiva.
Ela é só mais uma bala (não é de prata não) no arsenal do desenvolvedor.
flws
"
Eu adoro UML, sempre que possível eu uso, é ótimo pra tu ter algumas informações representadas, de modo que com um simples olhar tu já consegue saber praticamente tudo sobre o sistema. Desde visão abstrata das coisas até detalhes técnicos que auxiliam no desenvolvimento.
Agora, obrigar a ter UML em todos os processos, pra mim não é muito legal. É bom usar em situações específicas, senão acaba só atrasando o desenvolvimento IMHO.
pô galera valeu aí pelas respostas… deu uma clareada melhor
Lendo este tópico sinto que eu vivo em outro planeta. Ha uns 5 anos nao sei mais o que eh UML e tenho que confessar que nao sinto falta nenhuma!
Realmente…
Algumas empresas os desenvolvedores são “Digitadores de Luxo”.
[quote=igor_jua] Mas o que realmente acontece é que os programadores acabam se confundindo por não entenderem realmente onde o analista quer chegar, ou ate entende mas as vezes como não há um bom entendimento do que é preciso ser feito, o projeto acaba tomando um outro rumo!
[/quote]
Mito -> o que realmente acontece é que os programadores acabam se confundindo…
Verdade -> o que realmente acontece é que o analista não sabe usar/escrever UML, quanto mais entender sobre a tecnologia que resolve um problema de negócio. É muito bonito software rodando no papel. Vai chegar o dia em que haverá um compilador para .docs. Enquanto isso as crianças precisam de leite e a área continua infestada com profissionais que só sabem fazer bonequinhos e bolinhazinhas.
Solucao: manda o analista embora, contrata um programador capaz de conversar com o cliente e escrever especificacoes executaveis. O resultado eh um produto melhor, entregue mais cedo, gastando menos e (adivinha?) sem precisar de UML.
acho que isso depende de projeto a projeto, muitas vezes o cliente quer entender sobre o projeto, bem como acompanhar por especificações e/ou código-fontes, configurações e documentação, e isto varia de projeto a projeto.
mas, por exemplo, mesmo uma equipe que adota algumas práticas do scrum, onde um time com 10 pessoas ou pouco mais, mesmo que não seja equipe multidisciplinar, é necessário centralizar esta conversa com cliente entre 1 ou mais membros.
quanto ao analista sair ou ter que programar concordo, mas contato direto com cliente e ficar como regra não usar UML varia. eu por exemplo utilizo bastante um diagrama de classes básico sobre um conjunto de novas features ou mudanças destas dentro de um backlog, e o resultado é a não perca de tempo com interpretações falsas para requisitos descritos pelo cara que contactou o cliente e compilou tudo, e sem contar que ajuda na comunicação!
É o que sempre digo:
Existem 2 grupos, os que querem o software e os que desenvolvem o software; o restante existe para atrapalhar o bom entendimento entre estas 2 partes.
flws
Mas o cliente consegue ver até em que passo está o desenvolvimento só de olhar pro quadro onde estão as estórias. Além disso, se for ele mesmo que escrever essas estórias, não vai ter problema em saber o que já foi feito e que falta fazer.
É verdade. Mas a razão disso é porque são 10 pessoas! Pega um cliente tímido e joga 10 pessoas em cima dele! Ele vai ficar aterrorizado (isso é exagero hehe). As vezes, umas 4, 5 já dão conta do trabalho e tem um contato melhor com o cliente.
Eu to com você nessa. As vezes usar UML pra comunicação é interessante, mas IMHO é muito mais interessante fazer uns rabiscos em vez de uns quadrados ligados nos outros.
Abraço.
"
Entre um monte de diagramas UML e uma historia bem escrita em portugues (ou outro idioma) que sera interpretado, por exemplo, pelo Cucumber/RSpec e pode disparar testes de aceitação - inclusive selenium - eu fico com o segundo.
Eu posso usar UML se eu quero modelar as minhas classes e processos de uma forma melhor e isso não ter nada haver com clientes - e posso escolher não usar. Agora existe um componente onde eu TENHO que usar devido as circunstâncias (o cliente quer ver, quer acompanhar, quer dar pitaco, quer exigir herança multipla em C++ no lugar de um deamon escrito em Perl). Acho que nessas situações as metodologias Ageis trouxeram novos desafios.
Acho que a critica maior ao UML é na verdade uma critica à muleta de querer “controlar” processos complexos com metodos exatos, em detrimentos à metodos empiricos. Acho, IMHO, que a UML fala um pouco sobre a sensação de segurança de um cliente ou gerente sobre um processo complicado e com “tudo para dar errado”. Acho que não é a Big Picture pois deixamos de lado outras coisas nessa simplificação (como MDA) mas vai por ai. 
"