Fim do Waterfall = Fim do Analista?

Para falar a verdade o papel no Analista está morrendo com o fim de arquiteturas complicadas e abstrações pobres. Não tem qualquer relação com o “fim do waterfall”, aliás, quem disse que o Waterfall está acabando?

Cara, acredito que seja uma tendência. Acho que o modelo é rígido demais e, como li em algum lugar por aí, hoje em dia devemos planejar para o presente e codificar para o futuro.

Aqui no trabalho, como metodologia principal (recomendado para todo o projeto), ainda é o waterfall. Mas já existe um consenso entre nós que o modelo não é eficiente. Assim, no desenvolvimento de ferramentas internas, nas equipes, estamos tentando o desenvolvimento iterativo e incremental.

• Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas, é o fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.

Creio que o desenvolvedor esteja absorvendo este papel.

• Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas, é o fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.
  

Não tem nenhum professional emergindo, entre Requisitos, Analista e Desenvolvedor, só fica Requisitos e Desenvolvedor. É um fortalecimento tanto dos papéis de quem tem a informação quanto de quem irá fazer o sistema para lidar com ela.

• Mas se esta morrendo o papel do Analista, que profissional esta emergindo ? , quanto ao fim das arquiteturas complicadas, é o fim para o seu legado ? , não posso pensar que aquele analista iria ficar para essa migração a renovar as novas abstrações e conceitos.
  

Não tem nenhum professional emergindo, entre Requisitos, Analista e Desenvolvedor, só fica Requisitos e Desenvolvedor. É um fortalecimento tanto dos papéis de quem tem a informação quanto de quem irá fazer o sistema para lidar com ela.

Acredito nisso também !!! ; )

celso.martins:

A morte lenta da função de analista pode estar relacionada à morte lenta do waterfall?

Sem contar a perda de informação com o caminho feito pelos requisitos até chegar ao desenvolvedor (existe até uma tirinha sobre isso - a montagem de um balanço na árvore -, mas não encontrei).

É claro que esta metodologia ainda não morreu, mas creio que tenha ficado claro a sua ineficiência.

Me parece que o Desenvolvimento iterativo e incremental tem papel importante na eliminação da função do analista. Posso estar enganado, mas me parece muito lógico.

Abraços

encontrei essa, mas eu ja tinha visto uma diferente:

projeto.jpg800×600

Todo desenvolvedor tem que ser também um analista, onde já se viu programar sem pensar no que está fazendo?

Nem estagiário deveria fazer isso.

Era essa mesmo… não conheço outra… sensacional essa tira. =)

Mauricio Linhares:

Todo desenvolvedor tem que ser também um analista, onde já se viu programar sem pensar no que está fazendo?
Nem estagiário deveria fazer isso.

Pois é… nunca achei muito lógico esses papéis distintos. Levando só para o lado da UML, o analista modelaria a solução, mas o programador deveria conhecer a UML para entender o modelo do Analista. Isso subjulgava o programador, dizendo, creio eu, que ele não era capaz de compreender um problema e modelar a solução.

EDIT:

Bruno Laturner:

Não tem nenhum professional emergindo, entre Requisitos, Analista e Desenvolvedor, só fica Requisitos e Desenvolvedor. É um fortalecimento tanto dos papéis de quem tem a informação quanto de quem irá fazer o sistema para lidar com ela.

É exatamente esse o meu ponto de vista também.

Todo desenvolvedor tem que ser também um analista, onde já se viu programar sem pensar no que está fazendo?

Nem estagiário deveria fazer isso.

Nossa até quem fim eu concordo com você … [size=18] ;)[/size]

Dentro do modelo Iterativo, tenha a UML:

• Como rascunho.
• Como planta de software.
• Como linguagem de programação (determina uma especificação executavel, ainda em desenvolvimento)…
• Como documentação.

Visual é a palavra chave aqui.

Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.

Esses são alguns pontos fortes, no modelo Iterativo.

No projeto Iterativo, o cliente está envolvido nas reuniões, visto como responsável pelo projeto também, e os programadores participam e não recebem recados dos analistas. Muitas perspectivas, definem um Projeto Unificado.

O Projeto em Cascata ainda é muito utilizado, pois requer uma mudança em um nível mais alto: financeiro.

IMHO

F?io Henrique:

Não vejo como isso possa subjulgar o desenvolvedor. Pelo contrário, é um meio comum para garantir a comunicação (entendimento), e explorar possiblidades em um projeto.

Quando eu disse subjulgar o desenvolvedor, foi no sentido de que o desenvolvedor não seria capaz, teoricamente, de entender um problema e modelar a solução. O que acho um absurdo.

Mas aí é que está o problema. A maior parte dos softwares não pode ser modelada em UML, porque ela é restrita demais em termos de “programação”, o máximo que acontece é o analista chegar com um rascunho do que ele imagina, rascunho esse que seria muito bem mais aproveitável se feito pela equipe de desenvolvedores em vez de sair direto de um único “analista”. Se fosse possível programar a maior parte dos sistemas só com UML, o Maker já teria tomado o emprego de todo mundo aqui.

Assim, eu nunca trabalhei numa consultoria de code monkeys, então nunca passei por uma situação de ser tradutor de diagramas UML, mas eu realmente custo a acretidar que existam lugares onde os programadores simplesmente “traduzam” os diagramas que um analista fez. E se isso existe, quem faz o trabalho com certeza não deve ser lá muito bom do ofício não viu, porque não tem condições de uma pessoa se passar a um absurdo desses e não odiar o que faz todos os dias.

A maneira mais eficiente de se “explorar” coisas em um sistema é com testes e refactorings, porque eles vão lhe mostrar os resultados ali, na hora, UML é só imagem. Como já dizia aquela propaganda da Sprite, “imagem não é nada, sede é tudo”

A maneira mais eficiente de se “explorar” coisas em um sistema é com testes e refactorings, porque eles vão lhe mostrar os resultados ali, na hora, UML é só imagem. Como já dizia aquela propaganda da Spite, “imagem não é nada, sede é tudo” :)

Me refiro a uma Iteração inicial, onde o produto PODE não existir.

Concordo, pois das refactorings, é feita a engenharia reversa, disponibilizando a UML. Me corrijam se estiver errado, pois tenho aprendido assim. E nesse ponto de vista, achar que o desenvolvedor NÃO é capaz, é jogar essas possibilidades fora. Mas antes de uma refactoring, podem vir rescunhos UML dando um visão, mas não são candidatos a documentação, como são os resultados da engenharia reversa das refactorings.

Acho uma boa automatizar processos repetitivos. Mas desenvolver lógica de negócio é “humano” demais. Acho que a AI teria que avançar demais para conseguir executar esse tipo tarefa. Aí Matrix e Eu, Robô começariam a se tornar realidade.

Agora, se conectar numa tabela e gerar as operações de CRUD em um DAO, e gerar os forms JSP, acho sensacional. Mesmo porque essa tarefa repetitiva é chata demais. Eu, particularmente, gosto mais de desenvolver as BL.

Mauricio Linhares:

Assim, eu nunca trabalhei numa consultoria de code monkeys, então nunca passei por uma situação de ser tradutor de diagramas UML, mas eu realmente custo a acretidar que existam lugares onde os programadores simplesmente “traduzam” os diagramas que um analista fez. E se isso existe, quem faz o trabalho com certeza não deve ser lá muito bom do ofício não viu, porque não tem condições de uma pessoa se passar a um absurdo desses e não odiar o que faz todos os dias.

Também nunca vi um code monkeys. Se não fosse o farto material na Internet, acharia que é uma lenda.

Não entendi esse conceito. Pode me explicar melhor, por favor?

Não entendi a relação entre refatoração e engenharia reversa.

Obrigado! =)

Abraços!

celso.martins:

F?io Henrique:

Concordo, pois das refactorings, é feita a engenharia reversa, disponibilizando a UML.

Não entendi esse conceito. Pode me explicar melhor, por favor?

Não entendi a relação entre refatoração e engenharia reversa.

Obrigado! =)

Abraços!

Engenharia avante, reversa e de ida e volta.

Engenharia avante significa a geração de código a partir de digramas;

:arrow: engenharia reversa significa a geração de diagramas a partir do código; (você PODE ter alterado código, sem sincronizar os diagramas UML)

e a engenharia de ida e volta fecha o ciclo.

Antes de ir para o quadro novamente para uma nova iteração, use uma ferramenta UML para fazer engenharia reversa do código para produzir diagramas UML de classe, pacote e de iNteração, imprima em papel de plotter, grande, mande os desenvolvedores rascunharem a nova iteração.

http://www.objectsbydesign.com/tools/umltools_byCompany.html

Isso para mim, são apenas conceitos não experimentados por mim na prática. Mas tenho me esforçado no sentido.

Uma vez me foi dito, em um cenário pessoal, que aquilo que eu mais odiava ou achava chato de fazer, seria justamente, o que me faria crescer. Quando um Analista descobre as capacidades relativas a UML, sua visão de implementação é objetiva e clara. UML não foi uma projeção qualquer.

Creio que no modelo Iterativo a figura do Analista se faz ainda mais presente.

IMHO

:lol:

Eh como eu disse em outro topico, colocar a figura do analista no processo de criacao de um software é por um atravessador entre a informacao e o codigo sem a menor necessidade. Digo e repito, analista que nao programa e programador que nao sabe transformar requisito em codigo nao servem.

O tempo que isso vai levar pra ganhar forca no mercado já é outra historia. O modelo que nos temos hoje esta longe do fim. Só quando as empresas ageis ganharem forca e comecarem, em grande escala, a mostrar que com agilidade o lucro pode ser maior.

Engenharia reversa eu sei o que é, não entendi a parte da refatoração partir a engenharia reversa.

F?io Henrique:

…
Creio que no modelo Iterativo a figura do Analista se faz ainda mais presente.
IMHO
:lol:

Respeito a sua opnião, mas discordo dela. Se você está, constantemente, analisando, implementando e testando, acredito que o desenvolvedor deva ter estas 3 habilidades.

celso.martins:

Mauricio Linhares:

Assim, eu nunca trabalhei numa consultoria de code monkeys, então nunca passei por uma situação de ser tradutor de diagramas UML, mas eu realmente custo a acretidar que existam lugares onde os programadores simplesmente “traduzam” os diagramas que um analista fez. E se isso existe, quem faz o trabalho com certeza não deve ser lá muito bom do ofício não viu, porque não tem condições de uma pessoa se passar a um absurdo desses e não odiar o que faz todos os dias.

Também nunca vi um code monkeys. Se não fosse o farto material na Internet, acharia que é uma lenda.

Caramba, em que mundo vocês vivem?! :shock:

celso.martins:

F?io Henrique:

Engenharia avante, reversa e de ida e volta.

Engenharia avante significa a geração de código a partir de digramas;

:arrow: engenharia reversa significa a geração de diagramas a partir do código; (você PODE ter alterado código, sem sincronizar os diagramas UML)

e a engenharia de ida e volta fecha o ciclo.

</blockquote>

Engenharia reversa eu sei o que é, não entendi a parte da refatoração partir a engenharia reversa.

F?io Henrique:

…
Creio que no modelo Iterativo a figura do Analista se faz ainda mais presente.
IMHO
:lol:

Respeito a sua opnião, mas discordo dela. Se você está, constantemente, analisando, implementando e testando, acredito que o desenvolvedor deva ter estas 3 habilidades.

Imagino que você esteja pensando que estou associando (de forma dependente) refatoração com engenharia reversa UML.

Na verdade, estou usando o implicito.

Está implicito que se você faz uma refatoração, logo, seu código esta diferente e o UML pode não estar sincronizado com esse novo código. Do produto da refatoração (novo código) , é feita a engenharia reversa para atualizar o UML.

Na prática, sempre que são feitas alterações relevantes, significativas e que alteram o diagrama representacional UML, em vez de alterar o UML diretamente, pode ser feita a engenharia reversa atualizando os diagramas UML.

Tanto os Desenvolvedores que desempenham o papel dos Analistas e Analistas que códificam, por papel são Analistas.
Então se um Desenvolvedor desempenha funções antes, atendidas pelos Analistas, logo o mesmo é Analista. Diferente da figura de Desenvolvedor que pode nem ter noções de Arquitetura e/ou Metodologias. No meu ponto de vista, uma unificação, mas prevalecerá a definição Analista.

Então, acho que fui breve demais nos posts anteriores.

Vlw

IMHO

Caramba, em que mundo vocês vivem?! (2 - revista e ampliada)

Caramba, em que mundo vocês vivem?! (2 - revista e ampliada)

Vocês trabalham de code monkeys?

Sério, meu primeiro trabalho como estagiário ainda foi iniciar a construção de uma gui que funcionasse na web e no desktop e o analista só chegou pra mim e deu as funcionalidades mínimas, quem implementou, arquiteuturou a coisa fui eu (com o design patterns do lado, que tem uma discussão exatamente sobre isso nos exemplos de factory).

F?io Henrique:

Imagino que você esteja pensando que estou associando (de forma dependente) refatoração com engenharia reversa UML.

Na verdade, estou usando o implicito.

Está implicito que se você faz uma refatoração, logo, seu código esta diferente e o UML pode não estar sincronizado com esse novo código. Do produto da refatoração (novo código) , é feita a engenharia reversa para atualizar o UML.

Tanto os Desenvolvedores que desempenham o papel dos Analistas e Analistas que códificam, por papel são Analistas.
Então se um Desenvolvedor desempenha funções antes, atendidas pelos Analistas, logo o mesmo é Analista. Diferente da figura de Desenvolvedor que pode nem ter noções de Arquitetura e/ou Metodologias. No meu ponto de vista, uma unificação, mas prevalecerá a definição Analista.

IMHO

Pergunta: O que você fará com este UML? Ou melhor, de que forma ele está te ajudando a desenvolver?

Caramba, em que mundo vocês vivem?! (2 - revista e ampliada)

Vocês trabalham de code monkeys?

Sério, meu primeiro trabalho como estagiário ainda foi iniciar a construção de uma gui que funcionasse na web e no desktop e o analista só chegou pra mim e deu as funcionalidades mínimas, quem implementou, arquiteuturou a coisa fui eu (com o design patterns do lado, que tem uma discussão exatamente sobre isso nos exemplos de factory).
Em um dos locais que trabalhei havia uma forte cultura de code monkey. Era utilizado um framework corporativo e os casos de uso já chegavam todos mastigados. Nem tinha como fugir da arquitetura do framework, nem como fazer nada diferente do caso de uso. Porém, eu não fazia parte dessa equipe.

Então eu sempre dei muita sorte nos meus trabalhos

Eu já fui um code monkey por alguns meses numa grande consultoria. Odiei o trabalho. Além de mim, havia mais uns 60 code monkeys.

Então eu sempre dei muita sorte nos meus trabalhos :)

O meu caso, particularmente, não está relacionado a sorte e sim ao fato de eu ter trabalhado em consultorias bem pequenas (até 3 desenvolvedores). Entretanto, mesmo trabalhando em uma grande consultoria, não temos esse nível de detalhamento e temos liberdade para definir a maioria das questões técnicas. O que chega para nós é uma ET, uma EF e, no máximo, um diagrama de caso de uso. O resto é conosco.

Abraços

Mas aí é que está o problema. A maior parte dos softwares não pode ser modelada em UML, porque ela é restrita demais em termos de “programação”, o máximo que acontece é o analista chegar com um rascunho do que ele imagina, rascunho esse que seria muito bem mais aproveitável se feito pela equipe de desenvolvedores em vez de sair direto de um único “analista”. Se fosse possível programar a maior parte dos sistemas só com UML, o Maker já teria tomado o emprego de todo mundo aqui.

Assim, eu nunca trabalhei numa consultoria de code monkeys, então nunca passei por uma situação de ser tradutor de diagramas UML, mas eu realmente custo a acretidar que existam lugares onde os programadores simplesmente “traduzam” os diagramas que um analista fez. E se isso existe, quem faz o trabalho com certeza não deve ser lá muito bom do ofício não viu, porque não tem condições de uma pessoa se passar a um absurdo desses e não odiar o que faz todos os dias.

concordo plenamente com você.

Bruno Laturner:

Pergunta: O que você fará com este UML? Ou melhor, de que forma ele está te ajudando a desenvolver?

Acho que já coloquei isso antes:

Acrescentando: UML especializa subconjuntos da notação para áreas de assunto comum.

O UML representa o sistema em diferentes atuações. E é uma linguagem Visual. Visualização é um termo chave.

UML pode representar todo seu sistema para os Analistas, para você mesmo, para os Designers; UML documenta o sistema, a arquitetura de pacotes, a lógica, o dominio…

Na prática, essa visualização, fará grande diferença, quando em um quadro, quem diagrama, percebe o quanto sua visão do projeto estava mal elaborada e refaz ela talvez uma dezenas de vezes até chegar a um bom modelo.

Sabendo que em um projeto, são em maior número os que codificam. Faça um cálculo parecido com isso: N modificações modelo x qtd programadores x qtd de implementações = qtd de re-trabalho.

Para um exército de um homem só, pense em deixar um testamento UML para o proxímo. :lol:

IMHO :lol:

Infelizmente papel, e diagramas, aceitam tudo.

Qual software não pode ser modelado em UML?

Dinâmica do time não é escopo da UML, nem mesmo quem modela… O uso de artefatos para “se comunicar” sempre foi uma aberração… uma coisa que se imbutiu nos times sem qualquer lógica ou fundamentação…

O Maker não é baseado em fluxograma? Fluxograma não é UML…

Já trabalhei numa fábrica onde a visão do gestor era contratar bons analistas e programadores paguás… afinal, um bom modelo é o que há… Francamente!!!

Você pode “modelar” qualquer sistema em UML, mas isso não garante que a “modelagem” vá servir de alguma coisa além de papel higiênico, porque a UML não vai conseguir tratar de coisas simples como “abra o arquivo, processe, trate as exceções e feche o arquivo independentemente do que acontecer” de forma simples como código. Você vai ter um diagrama de sequência bizarro que é basicamente inútil do ponto de vista da programação.

Se fosse possível programar sistemas em UML, geradores de código como o Maker ou os “executable UML” da vida já teriam resolvido todos os problemas do mundo.

UML pode ser interessante como uma forma de comunicação de altíssimo nível, mas é basicamente inútil quando a tarefa é desenvolver sistemas de verdade com código de verdade. A não ser, claro, que se esteja lidando com code monkeys que realmente não sabem pensar por si só, mas aí já é comprar a própria corda pra se enforcar.

Bem, não sei o que é paguá… mas pela colocação na frase imagino que não seja algo bom… =)

[list]Só não imagino como isso funcionaria, pois não consigo visualizar como um bom modelo pode ser transformar num bom sistema sem programadores competentes. Não vejo como garantir a qualidade do que está sendo feito.[/list]
[list]Como provavelmente você está falando em waterfall (O analista analisa, o programador programa e o testador testa, entregando todos os requisitos de uma só vez para o cliente), como adaptar modelo e código às mudanças que fatalmente acontecem durante o processo?[/list]

OK… UML nunca foi uma linguagem de programação (a não ser pelos devaneios da MDA, que um dia no passado defendí). Um modelo sempre foi e sempre será uma simplificação. Os detalhes estão no código.

Eu vejo aplicabilidade da UML na maioria dos sistemas que desenvolvo, porém, sempre como rascunho. Especificação firme nunca, a não ser que seja algo executável como JBPM…

Mauricio Linhares:

UML pode ser interessante como uma forma de comunicação de altíssimo nível, mas é basicamente inútil quando a tarefa é desenvolver sistemas de verdade com código de verdade. A não ser, claro, que se esteja lidando com code monkeys que realmente não sabem pensar por si só, mas aí já é comprar a própria corda pra se enforcar.

[]s

E antes da UML ser inventada, era impossível se ter visão da possível implementação por acaso?
Você pode até afirmar que a UML te dá uma visão sobre a possível implementação e que é a ferramenta padrão para isso. Mas você não pode afirmar que seja “única e exclusivamente”.

E antes da UML ser inventada, era impossível se ter visão da possível implementação por acaso?
Você pode até afirmar que a UML te dá uma visão sobre a possível implementação e que é a ferramenta padrão para isso. Mas você não pode afirmar que seja “única e exclusivamente”.
A evolução do desenvolvimento de software em que na sua época não existia o pensamento de plataforma e onde você não encapsula codigos com regras de negócio isso tudo se expandiu para novos contexto de frameworks e assim por diante, não é possível você ter melhor mapeamento desses artefatos sem as anotações da UML, que lhe promove a geografia de onde esse objetos que estão implementados fazem sentido na sua aplicação.

E antes da UML ser inventada, era impossível se ter visão da possível implementação por acaso?
Você pode até afirmar que a UML te dá uma visão sobre a possível implementação e que é a ferramenta padrão para isso. Mas você não pode afirmar que seja “única e exclusivamente”.

Impossível não era, mas pelo que diz o pessoal que já programava profissionalmente nessa época, era quase.

No início da década de 90 havia o UON (Constantine, Weiss e Page-Jones), que, segundo Page-Jones, não conseguiu atender de forma satisfatória o objetivo de ser uma notação que abrangesse todas as construções encontradas nos sistemas orientado a objeto. Depois vieram a EUON, OODN, mas que também nunca tiveram uma aceitação em massa na comunidade de desenvolvedores.

Não é a solução definitiva. Não é perfeita. Mas foi o mais próximo conseguiram chegar, até o momento.

Acredito que a má fama da UML seja devido a carência de ferramentas de integração com as IDEs. Estas ferramentas deveriam manter o diagrama atualizado com as modificações do código (realmente, é chato demais ficar replicando as alterações no código no diagrama). Já utilizei o OMONDO e meu eclipse ficou tão pesado que acho que eu precisaria de um “deca-core” para rodar. Sem contar que os diagramas gerados na engenharia reversa ficam confusos demais e a tentativa de acerto é, literalmente, um parto. Posso não ter conseguido usar a ferramenta direito. Fiquei cerca de um mês insistindo, pois acreditava que se conseguisse usar da forma como é proposto pelos criadores do plugin a maioria dos meus problemas com a atualização UML-Código estariam resolvidos. Mas, infelizmente, não consegui. Não sei se foi culpa do plugin ou minha.

Abraços.

Mauricio Linhares:

UML pode ser interessante como uma forma de comunicação de altíssimo nível, mas é basicamente inútil quando a tarefa é desenvolver sistemas de verdade com código de verdade. A não ser, claro, que se esteja lidando com code monkeys que realmente não sabem pensar por si só, mas aí já é comprar a própria corda pra se enforcar.

Eu acho que é na comunicação que está a eficiência da UML. Concordo que para desenvolver seja quase inútil, já que você está com o sistema no sangue . Mas se o projeto for para mão de outra pessoa, acho que seria bom ter os diagramas. Facilitaria o entendimento.

E se esse projeto voltar com a documentação da equipe original e da equipe por onde ficou algum tempo, vai ajudar a conhecer as alterações que a outra equipe realizou e a lembrar as hierarquias, os relacionamentos, as atividades, etc.

Acrescentando: Teste a priori. Em Desenvolvimento Dirigido por Testes, apoiado pelo PU, os testes são escritos primeiro.

Desenvolvimento Iterativo não é atuação Cawboy do programador. Desculpe-me a franquesa.

Não vejo como a UML não seja utilizada Em uma decente A/POO a UML é muito importante, embora, não seja um bala de prata.

A UML é vasta, muito ampla, e se você quiser ir a fundo com especificações do tipo: abra o arquivo, feche o arquivo, dá pra fazer sim. Mas no modelo Iterativo são deixadas as partes especulativas de um sistema.

"

Meus dois centavos, baseados na leitura dessa thread “em um tapa só”:

Uma coisa que eu ouvi já de várias pessoas, acho que o Yoshima inclusive, é que UML não é documentação.

Sério, as pessoas superestimam demais a UML. Escrevem-se tanto detalhes nesse diagrama que se perde a visão do todo. E aí, os diagramas ficam praticamente no mesmo nível de detalhe do código. E veja só, ninguém é louco de escrever uma aplicação em Java e, ao mesmo tempo, a mesma aplicação em C# (porém sem compilar), alegando que uma das linguagens é mais fácil de se trabalhar. Mas incrivelmente, com a UML, os rupistas e cascateiros escrevem a mesma aplicação de duas formas diferentes, e nem se tocam do ridículo!

Eu acho a UML útil, mas só se for pra comunicar uma idéia “macro”. Tipo, algum conceito que, se fosse olhar pro código, exigiria a leitura de um punhado de arquivos. Fora isso, é refazer a mesma coisa sem necessidade.

Com relação ao uso de UML para engenharia reversa, tenho uma postura bastante contrária. Os diagramas resultantes serão, no mínimo, confusos. E, implicitamente, assume uma postura cascata, onde haveria um dia mágico onde a aplicação antiga se desligaria e a nova entraria no ar. Fato é que esse dia nunca chega! Existem, em códigos legados, conceitos tão implícitos (mas importantes pros clientes) que uma análise BDUF não vai capturar. E quando ocorre a “fase de transição”? (Que a literatura sobre engenharia reversa não fala!) É aquele momento onde um requisito urgente precisa ser adicionado na aplicação mais antiga porque a nova ainda está em desenvolvimento. Nesse caso, o menos ruim é fato de se escrever duas vezes, porque o pior é o fato de que esse requisito pode ser esquecido quando a nova versão estiver no ar!

Vou causar briga com isso, mas enfim: engenharia reversa é lenda! Só funciona quando a aplicação é pequena, mantido por um curto período por um ou dois programadores que ainda estão disponíveis para conversar. Ou então quando a aplicação antiga é tão ruim que, simplesmente, não atende o que o cliente quer (aí não precisa de engenharia reversa, pois o legado não tem como ajudar). Pros outros casos, só resta a triste sina: mantenha a aplicação, mas refatore e adicione casos de testes quando for mexer. Isso significa que aquela mudança do Struts 1 para o Grails não deve ser feita? Exatemente! Não dá pra saber o que está escondido no código legado (e, ao contrário do que muitos acreditam, a UML não ajuda), e é melhor não sumir com requisitos da aplicação da noite para o dia.