UML vale a pena ou o melhor é meter a mão na massa

Olá,

Nossa equipe utiliza pelo menos diagrama de caso de uso, classe e estado para alguns fluxos complexos. Em alguns cenários o de sequencia.

Lembrando que utilizamos para comunicação entre a equipe.

Quanto a perder tempo, não vejo dessa forma. Talvez para um projeto pessoal seja uma “perda de tempo”, agora em um ambiente corporativo, se ganha, pois nessa fase se elimina alguns problemas que se pode ter pela frente.

Eu acredito que UML vale a pena sim, ajuda a ter uma visão melhor dos processos e a identificar problemas antes que eles apareçam de surpresa, assim é possível encontrar outra forma para resolver, ao invés de uma gambiarra.

Não digo usar todos os diagramas, apenas os mais importantes ou aqueles que te ajudem a entender o processo.

Toda vez que eu comecei, fazendo pelo menos com o diagrama de Use Case e o de classes ganhei muito tempo no desenvolvimento!

Documentar Casos de Uso é imprescindível. Diagramas de Caso de Uso são úteis em raríssimos casos. Modelos de Classes pode ser gerado automaticamente de seu código, voce nao precisa ficar preenchendo os quadradinhos e ligando com setinhas. Diagramas de Sequência são ótimos para estabelecer padrões de desenvolvimento no projeto e para documentar de maneira física a implementação de Casos de Usos complexos. E por fim, Modelagem dos Processos de Negocio esse sim qualquer projeto coorporativo de porte razoável deve possuir. Sinceramente, um sistema sem um modulo de workflow na camada de negócio não pode ser chamada de sistema coorporativo, é amadorismo puro.

Código bom é aquele em que o programador sabe qual problema resolver antes de escrever qualquer linha de código. Código ruim é aquele baseado em templates mentais, baseados em decorebas, que são marretados até chegar a algo que funcione para os problemas mais imediatos.

Usar UML é um meio de compreender aquilo que deverá ser feito. Porém, existem muitas equipes que desvirtuam o UML, e que realmente atrasam o desenvolvimento. Os problemas comuns são:

:arrow: a UML é usada como se fosse um fluxograma ou um DFD glorificado;

:arrow: a UML é vista como mais importante que o código, havendo pessoas que praticamente chegam a “codificar visualmente”;

:arrow: a UML é usada como um meio de comunicação entre um lider técnico e seus subordinados, criando burocracia e substituindo conversas reais.

Com pessoas usando UML exclusivamente para resolver problemas de design, ela se torna uma vantagem.

Leonardo3001:

Código bom é aquele em que o programador sabe qual problema resolver antes de escrever qualquer linha de código. Código ruim é aquele baseado em templates mentais, baseados em decorebas, que são marretados até chegar a algo que funcione para os problemas mais imediatos.

Concordo com tudo o que voce disse sobre UML, só não entendi o que você quis dizer nesse primeiro comentário.

sulito:

Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea:

Isso prova que você trabalhou apenas em projetos pequenos.

Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.

Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.

Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.

A UML é utilizada para modelar e surgiu com o advento do reaquecimento da OO. E é como todas as outras coisas; quando bem utilizada se obtem beneficios, quando não perde-se tempo ou pode causar confusão.

Uma das técnicas para não se perder tempo com ela é: não modelar o que já é óbvio para equipe inteira.

Utilize a UML para ajudar a esclarecer pontos obscuros e criar soluções para questões mais complexas ou de difícil dominio.

flws

Bem-vindo ao mundo do CMMi…

Eu discordo totalmente do seu post. Ter um arquiteto da torre de marfim pra escrever UML e 10 code monkeys para cegamente implentar os diagramas UML nao é algo produtivo… ja trabalhei bastante nesse esquema e a produtividade é muito baixa. E geralmente a qualidade tambem nao é das melhores, por que o diagrama nao consegue representar tudo o que o programador precisa pra codificar, algumas decisoes o programador tem que tomar. Se o programador é um code monkey, ele vai tomar decisoes ruins. Se ele nao é um code monkey, ele nao precisa de um diagrama mostrando o que ele tem que codificar passo-a-passo.

E se voce quiser fazer um diagrama que mostra todos os detalhes pra um programador codificar, o diagrama vai ficar tao complexo e tao demorado pra fazer que voce vai precisar de 10 arquitetos da torre de marfim.

E o problema mais grave é que em 99% dos casos esses diagramas acabam ficando desatualizados. Com o passar do tempo, mudanças vao sendo feitas no codigo refletindo uma mudança nos requisitos que nao é refletida nos diagramas UML. O que acaba confundindo que vai dar manutencao no sistema. E se for necessario adicionar funcionalidade nova, o diagrama desatualizado confunde o arquiteto da torre de marfim… No fim acabam fazendo UML só para seguir o processo, mas ignoram na hora de codificar.

Enfim, eu nao acho uma boa idea fazer o sistema usando a metodologia “Arquiteto da torre de marfim que manja de UML + 10 code monkeys”. É melhor e mais produtivo ter 2 desenvolvedores com boas noçoes de design, orientacao a objetos e TDD.

Voce pode usar UML, mas acho que projetar num nivel mais alto. Ou entao pra projetar algo, mas nao pensando que aquilo vai ser o passo-a-passo de um outro desenvolvedor.

deniswsrosa:

Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.

Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.

Essa “ótima análise de requisitos” pode virar um BDUF, e tem projetos que precisam estar prontos no dia X senão eles falham completamente. Imagine um site de Copa do Mundo ficando pronto depois da final.

BTW, independente da análise, programa feito por code monkeys vira macacada.

Eu diria: Vira gilete na mão de macaco!

flws

Rubem Azenha:

deniswsrosa:

Isso prova que você trabalhou apenas em projetos pequenos.

Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.

Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.

Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.

Bem-vindo ao mundo do CMMi…

Eu discordo totalmente do seu post. Ter um arquiteto da torre de marfim pra escrever UML e 10 code monkeys para cegamente implentar os diagramas UML nao é algo produtivo… ja trabalhei bastante nesse esquema e a produtividade é muito baixa. E geralmente a qualidade tambem nao é das melhores, por que o diagrama nao consegue representar tudo o que o programador precisa pra codificar, algumas decisoes o programador tem que tomar. Se o programador é um code monkey, ele vai tomar decisoes ruins. Se ele nao é um code monkey, ele nao precisa de um diagrama mostrando o que ele tem que codificar passo-a-passo.

E se voce quiser fazer um diagrama que mostra todos os detalhes pra um programador codificar, o diagrama vai ficar tao complexo e tao demorado pra fazer que voce vai precisar de 10 arquitetos da torre de marfim.

E o problema mais grave é que em 99% dos casos esses diagramas acabam ficando desatualizados. Com o passar do tempo, mudanças vao sendo feitas no codigo refletindo uma mudança nos requisitos que nao é refletida nos diagramas UML. O que acaba confundindo que vai dar manutencao no sistema. E se for necessario adicionar funcionalidade nova, o diagrama desatualizado confunde o arquiteto da torre de marfim… No fim acabam fazendo UML só para seguir o processo, mas ignoram na hora de codificar.

Enfim, eu nao acho uma boa idea fazer o sistema usando a metodologia “Arquiteto da torre de marfim que manja de UML + 10 code monkeys”. É melhor e mais produtivo ter 2 desenvolvedores com boas noçoes de design, orientacao a objetos e TDD.

Voce pode usar UML, mas acho que projetar num nivel mais alto. Ou entao pra projetar algo, mas nao pensando que aquilo vai ser o passo-a-passo de um outro desenvolvedor.

Calma!

Primeiro, que quando me refiro a code monkeys, não imaginem um indiano numa baia apertada todo suado traduzindo linguagem estruturada para Java. Mas sim programadores que não devem tomar decisões críticas, eu tb jah trabalhei com o método de “N desenvolvedores com boas noções de design”, e particularmente acho muito produtivo também, masss… para projetos pequenos, vc já tentou fazer isso num projeto com mais de 50 pessoas pra ver o resultado??? Nesses casos são poucas as pessoas capazes de realmente tomar uma decisão tendo consciencia do impacto disso no todo. Sem contar que nesses casos, o conhecimento não flui tão bem assim como quando temos 5 … 10 pessoas.

A UML não se limita a “Diagrama de Clases”, existem diagramas muito úteis como o de sequencia por exemplo, e todos eles ajudam a tornar menos provavel que acontecam “mal entendidos” do que foi especificado do que foi desenvolvido, limitando a decisão dos programadores a coisas comuns do dia a dia e não.

Agora, que a maioria dos projetos não são bem analisados, que muitos fazem mal uso do UML, isto é um fato que todos nós sabemos na pele. Mas é questão de Mal uso para a sua necessidade.

Desculpe, mas esse papo de “projeto grande” é coisa de CMMista. Se um projeto tem 50 desenvolvedores, não existe milagre que faça a comunicação fluir bem. Nessa caso o ideal seria quebrar em algumas equipes menores. Enfim, quem tem ja alguns anos de projetos nas costas ja viu essa papo de 1 arquiteto fazendo UML e 10 programadores traduzindo UML em codigo nao funciona. Simples assim. Nao funciona. Pelos motivos que eu disse no post anterior.

Se voce acha que um programador deve apenas traduzir UML para codigo, eu acho que voce esta tao errado que eu nem sei como comecar a me explicar…

Se voce ler sobre metologias ageis, existe muita discussao sobre o que fazer em projetos grandas. Eu acredito que a maioria dos especialistas de verdade vao falar que nao tem como fazer um desenvolvimento de qualidade com 50 desenvolvedores na equipe e que o correto seria quebrar em equipes menores.

Eu sei muito bem que existe outros diagramas… tenho pesadelos da epoca em que eu tinha que ler diagramas de sequencia. Perdia mais tempo lendo e discutindo coisas que nao iam dar certo/poderiam ser melhores se eu implementasse da maneira como havia sido escrito do que efetivamente codificando. Era comum do “projetista” ficar horas com o “programador” para explicar o que ele havia feito no diagrama.

Cara, até concordo com você, mas para um programador implementar um funcionalidade dessa forma ele teria que ser “o cara do caso de uso”, ou seja, ele tem que entender muito bem aqueles requisitos e tem que saber exatamente tudo que deve ser feito, o problema é que na maioria dos casos não é assim que funciona, simplesmente você é contratado no meio do projeto. Sem contar que os projetos são vendidos como “pacotes fechados”, ou seja, tudo o que deve ser feito é definido antes. Se você pensar em situações que você cumpre demanda interna, ok, sua afirmação é valida, agora num contexto de fábrica de software é mais dificil usar essa metodologia.

Voltando ao UML, provavelmente fizeram um grande mau uso dela neste projeto que vc citou, pois tentam “mastigar demais” um diagrama, e acabam complicando mais, diagrama de sequencia mesmo, é otimo pra saber o fluxo das informacoes, não pra ficar rabiscando chamada de métodos.

Eu dúvido que vocês não tenham pelo menos um rascunho de um diagrama de estados no seu projeto.

Enfim… acho que a minha visão de “code monkeys” é um pouco mais abrangente que a de vocês.

deniswsrosa:

sulito:

Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea:

Isso prova que você trabalhou apenas em projetos pequenos.

Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.

Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.

Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.

Ei calma ai, existi projectos grandes com programadores experientes que fica mais facil dividir as tarefas e começar a programar, para cumprir prazo, do que ficar metade do tempo dado para o projecto discutindo UML.
E analisando bem ter 1 desenhador de UML e uns 10 code monkes nao funciona em projectos grandes, porque normalmente nos UML se mete as interfaces ( como as classes devem estar e como devem se comportar) e não se mete codigo nos UML, e com code monkeys ai fica dificil o software ter um bom desempenho e performance, porque eles podem implementar o código da pior forma possivel e respeitar a interface( requisitos) UML.

Normalmente eu estou abituado a programar sozinho , não importando o tamanho do projecto, e quero mudar este quadro por isso abri este topico para saber se os UML são vantajosos ou se fazem o pessoal perder tempo.

Mas notei que mesmo com os UML os code monkeys podem cometer erros graves na implementação programando da pior forma possivel e respeitando os requisitos UML.

e Alem do mais na hora de codificar pode se notar que a outra forma melhor de implementar o projecto para ganhar performance ou desempenho, e ai tem que se alterar novamente os UML.

Mas resumindo segundo as coisas que os outros gujeiros disseram , eu achei que a melhor forma é dividir a equipe em equipes pequenas e dividir as tarefas de uma forma que na hora da implementação cada equipe de 2 a 4 pessoas podera ter a extrema liberdade de implementar o codigo e a logica da forma que melhor achar. mas quando estiverem no fim começar a fazer os UML para ficar a documentação para os outros membros dos outros grupos poderem entender mais facilmente o que foi feito e como foi feito.
:idea: :idea: :idea: :idea: :idea: :idea: :idea: :idea:

sulito:

deniswsrosa:

sulito:

Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea:

Isso prova que você trabalhou apenas em projetos pequenos.

Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.

Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.

Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.

Ei calma ai, existi projectos grandes com programadores experientes que fica mais facil dividir as tarefas e começar a programar, para cumprir prazo, do que ficar metade do tempo dado para o projecto discutindo UML.
E analisando bem ter 1 desenhador de UML e uns 10 code monkes nao funciona em projectos grandes, porque normalmente nos UML se mete as interfaces ( como as classes devem estar e como devem se comportar) e não se mete codigo nos UML, e com code monkeys ai fica dificil o software ter um bom desempenho e performance, porque eles podem implementar o código da pior forma possivel e respeitar a interface( requisitos) UML.

Normalmente eu estou abituado a programar sozinho , não importando o tamanho do projecto, e quero mudar este quadro por isso abri este topico para saber se os UML são vantajosos ou se fazem o pessoal perder tempo.

Mas notei que mesmo com os UML os code monkeys podem cometer erros graves na implementação programando da pior forma possivel e respeitando os requisitos UML.

e Alem do mais na hora de codificar pode se notar que a outra forma melhor de implementar o projecto para ganhar performance ou desempenho, e ai tem que se alterar novamente os UML.

Mas resumindo segundo as coisas que os outros gujeiros disseram , eu achei que a melhor forma é dividir a equipe em equipes pequenas e dividir as tarefas de uma forma que na hora da implementação cada equipe de 2 a 4 pessoas podera ter a extrema liberdade de implementar o codigo e a logica da forma que melhor achar. mas quando estiverem no fim começar a fazer os UML para ficar a documentação para os outros membros dos outros grupos poderem entender mais facilmente o que foi feito e como foi feito.
:idea: :idea: :idea: :idea: :idea: :idea: :idea: :idea:

Novamente, nem se quer citei diagrama de classes, e claro, o desenvolvimento não tem que ( e nao pode) ser waterfall, só digo que todo mundo usa UML no seu dia a dia, seja pra passar conhecimento pro colega, seja pra tirar uma dúvida ou etc, todos os bons programadores que conheco no mínimo rabiscam alguma coisa antes de sair programando, e isso é na verdade um diagrama UML qualquer que simplesmente não segue os padrões de formatação. E quando você não guarda esse seu rabisco em algum lugar, vc mesmo pode esquecer a forma que implementou, ou uma pessoa pode ter um outro entendimento de como a coisa realmente funciona quando o conhecimento é passado de boca em boca.

A UML ajuda na visão do que está sendo feito além de ser de grande ajuda na Gestão do conhecimento.

UML é muito importante tanto para equipes pequenas ou grandes para melhorar a comunicação, até mesmo para quem programa sozinho como eu. Eu costumo utilizar os diagramas de componentes, sequência e o de modelagem de processo de negócio, que é exelente para demostrar o processo de uma determinado requisito ou processo do sistema, dando um visão mais abrangente. Esses digramas que citei na minha opnião são essencias para qualquer projeto seja individual ou em equipe.

deniswsrosa:

Cara, até concordo com você, mas para um programador implementar um funcionalidade dessa forma ele teria que ser “o cara do caso de uso”, ou seja, ele tem que entender muito bem aqueles requisitos e tem que saber exatamente tudo que deve ser feito, o problema é que na maioria dos casos não é assim que funciona, simplesmente você é contratado no meio do projeto. Sem contar que os projetos são vendidos como “pacotes fechados”, ou seja, tudo o que deve ser feito é definido antes. Se você pensar em situações que você cumpre demanda interna, ok, sua afirmação é valida, agora num contexto de fábrica de software é mais dificil usar essa metodologia.

Voltando ao UML, provavelmente fizeram um grande mau uso dela neste projeto que vc citou, pois tentam “mastigar demais” um diagrama, e acabam complicando mais, diagrama de sequencia mesmo, é otimo pra saber o fluxo das informacoes, não pra ficar rabiscando chamada de métodos.

Eu dúvido que vocês não tenham pelo menos um rascunho de um diagrama de estados no seu projeto.

Enfim… acho que a minha visão de “code monkeys” é um pouco mais abrangente que a de vocês.

Cara… deu pra ver que voce comprou a ideia do CMMi, PMBok, Cascata, etc… Voce falou algumas palavrinhas magicas, como fabrica de software e gestao de conhecimento, tudo tem que ser definido antes. Sinto muito, mas voce esta indo na contra-mao do resto da industria. Quase todo mundo esta indo na direcao completamente oposta ao mindset que voce esta seguindo. Se voce nao acreditar em mim, e nao acreditar em todo o material que vem sendo publicado sobre desenvolvimento agil nos ultimos, sei la, 5 anos, só o tempo mostrara pra voce como essa abordagem é falha.

Nao tem jeito, o desenvolvedor tem que aprender do negocio, a equipe de negocios tem que interagir com a equipe de desenvolvimento, as equipes grandes tem quer quebradas em times menores e os desenvolvedores tem que ter boas nocoes de design, orientacao a objetos e TDD. Sem isso, voce pode fazer a documentacao que voce quiser, usar o diagrama que voce quiser, o trabalho nao sera eficiente.

sulito:

Pessoal eu queria que aqueles que tem experiencia em UML digam qualquer coisa, quando se tem um projecto fazer antes os desenhos UML faz perder muito tempo , ou é produtivo???
eu acho que por a mão na massa faz ganhar mais tempo, e fazer apenas uma lista minima de requisitos chega :idea: :idea: :idea: :idea:

Concordo plenamente com você Rubem Azenha

Trabalhamos assim:

1. Escrevemos um user story
2. Escrevemos a documentação (UML ou não) necessária para entender o problema. Entendido, botamos a mão na massa. Não vejo sentido em ficar escrevendo mais documento. Ninguém vai ler mesmo. Além disso, de forma geral os clientes costumam ficar mais contentes quando recebem software que funciona, mesmo que com poucos diagramas, do que um monte de diagrama para explicar o por que dele não funcionar

Botar a mão na massa = TDD = 1) Escrever testes automáticos 2)fazer o código passar nos testes 3)refatorar 4; voltar ao passo 1

Documentação necessária:
Casos obvios: nada
Casos simples: detalhar alguns cenários + algum diagrama de classe
Mais difícil: Mais cenários + diagrama de classes
Mais dificil: Mais cenários + diagramas de classes + algum diagrama de sequencia
Mais difícil: …

Ferramentas:
Primeira iteração:
Lápis, borracha, quadro branco, câmera fotográfica
Enterprise Architect para organizar as coisas

Demais iterações:
                   Enterprise Architect para engenharia reversa
                   Lápis, borracha, quadro branco, câmera fotográfica
                   Enterprise Architect para organizar as coisas

Abraços

luizSC,

Gostei muito da forma como vocês estão trabalhando, é mais ou menos parecido com o que eu estou fazendo (só que o meu projeto é um projeto solo…).

Eu só tenho trauma de tirar foto do quadro-negro com a câmera digital… num outro projeto que eu participei, passamos por uma situação ridícula de ter que reescrever várias vezes alguns diagramas cada vez que faziamos uma reunião (o produto ainda não estava muito bem definido). Sem falar que uma vez a foto não ficou muito boa e na hora ninguém se preocupou em olhar… depois, fomos ver a foto e não dava para ler algumas coisas Acho que foi a situação mais ridícula e vergonhosa da minha vida profissional.

Acho que UML é legal pra aprender padrões, se comunicar com equipes remotas, e pra fazer prova de concurso, mas na prática, não se usa.

Realmente manter documentação atualizada depois que o código evolui, é refatorado, sofre alterações, não tem condições.

Agora, se o gerenciamento for controlado por um CMMI, ai dos males, UML é o menor.

Agora mesmo na empresa, tenho a missão de desenvolver 23 Diagramas de Sequencia. Sou Analista Desenvolvedor, a segunda coisa que me perguntaram na entrevista (a primeira foi sobre Java), foi se eu dominava UML (Diagrama de Caso de Uso e Sequencia).

Posso te dizer que fiquei 1 mes so fazendo Caso de Uso (Claro que tinha um Analista Senior me ajudando nos casos de uso).

E também posso afirmar que o projeto foi desenvolvido muito rapido, simplesmente pq tinhamos 90% das informações registradas nos casos de uso e sequencia.

A consultoria que trabalho funciona desta maneira, todo projeto que pegamos tem que ter no minimo os casos de uso e sequencia. Mas ja trabalhei em empresas que o pessoal não quer nem saber sobre diagramas. Varia de empresa para empresa.

Sinceramente, eu não consigo ver essa definição de CODE MONKEYS e não ficar um pouco, digamos, revoltado.

Muita gente acha que se a UML estiver feita direitinho, tudo certinho, uma análise bem feita, etc, o código sai automaticamente.

Sou programador e isso é uma absoluta mentira. A programação é a alma do sistema, e NUNCA vai ficar igual à análise. Nunca mesmo!

De todas as vezes em que tive que pegar uma análise pronta e programar o sistema, tive que repensar muitas coisas do sistema, coisas que só são descobertas durante a programação. E muitos diagramas eu olhei, olhei, não entendi o que o analista quis dizer, fiz de outra forma, e funcionou muito melhor do que seria. E não foi só uma vez, e não foi com análise mal feita.

Podem me chamar de antiquado, atrasado, mas eu prefiro pegar um sistema pra fazer, levantar os requisitos de forma correta, rabiscar algumas coisas e discutir com a equipe de desenvolvimento, e começar a programação, do que ficar perdendo tempo desenhando diagramas que não ajudarão em nada na programação.

Não consigo ver um diagrama de caso de uso e pensar na sua aplicação na programação, é simplesmente perda de tempo.

Faça a melhor análise do mundo e passe para o programador, ele vai pensar 5 vezes mais do que você, fazer de forma melhor, e perder um precioso tempo lendo seus diagramas.

E digo mais: muitas características do sistema são definidas na hora da programação, então o final do sistema vai depender da habilidade do programador.

Resumindo a história, até acho que pode ser feita uma análise em UML, mas com diagramas úteis (leia-se diagrama de classes, no máximo sequência). E sem perder muito tempo com eles. Agora, dizer que depois da análise com UML é só partir pro abraço, já é incrivelmente errado.

Em tempo, ou o diagrama de estados consegue ser mais inútil do que o de caso de uso, ou então eu não entendi direito, e nunca vou entender!

Boto fé em diagramas também não… prefiro análise em rabiscos, muita conversa com o cliente, muito teste, e iteratividade.
Acho que quanto mais abstração na documentação, melhor, logo, entrar no mérito de classes, e métodos dessas classes em diagramas é algo que definitivamente não funciona, são coisas que mudam muito, e dá muito mais trabalho sincronizar código e documentação do que refazer uma porção de código que deu errado.

Algo vejo que dá certo é manter a “documentação” bem enxuta, dando apenas um caminho primário a ser seguido na implementação, sem esmiuçar nada; entrar em detalhes, é pedir pra fazer trabalho de tolo.

Diagramas são lindos, mas no final das contas não ajudam muito.

E sempre bom adotar metodologias de desenvolvimento de software sejam elas agéis ou RUP. No começo pode parecer um tempo perdido, mas este tempo pode evitar muito retrabalho futuramente.

oi,

UML é util sim, porque não? o que não é util é você perder mais tempo documentando do que realmente entender o problema

existem apenas duas justificativas para documentação em excesso (seja usando UML ou qualquer outra ferramenta)

1. os requisitos não estão claros

2. por “medo das mudanças” eu documento tudo o que puder para me resguardar depois

abs

É engraçado ver esse povo que diz que UML é perda de tempo.
São os mesmos que vão realizar manutenção ou mesmo ampliação de softwares feitos sem documentação, cujo código foi baseado em “achismo” por parte do programdor e que reclamam por não ter um suporte ou mesmo um caminho.
As comunidades de desenvolvimento de software vêm há tanto tempo buscando padrões para facilitar a vida daqueles que precisam criar um programa e, ainda existem pessoas que não conseguem ver além daquilo que está à sua frente.

Claro, existem projetos de uma complexidade muito elevada e, para tal, pode-se fazer necessário o uso de todos os diagramas. Há outros em que a complexidade é muito baixa, apenas a especificação de caso de uso, diagrama de classes e um ou outro mais são necessários.

O problema é que em muitas empresas é o próprio programador que fica responsável por fazer essa análise, mutas vezes, tendo apenas feito um curso de uma linguagem X, aprendido outras 2 à força e que nunca viu os fundamentos da UML.

Cada diagrama da UML visa mostrar o sistema a partir de um ponto de vista, uma lógica específica, com o objetivo de ser clara para o programador e, principalmente, ao cliente.
E onde isso ajuda?
Não é só uma questão de prototipação, é possível ver limitações e falhas que a estrutura, linguagem ou mesmo profissionais possuam. Além de, certamente, servir como argumento, caso o cliente diga “Não foi isso que eu pedi”.
Perda de tempo? E se o cliente diz que não vai mais aceitar o projeto pois não ficou como ele queria?
Quando você mostra para o cliente uma especificação de casos de uso ou um diagrama de sequência, fica mais simples interpretar o que ele quer e, se não for isso, muito mais seguro alterar.

gohorsenew.jpg?w=748&h=746748×747

Ninguém confessa, mas usam Go Horse diariamente.

A documentação é “see the code”, e os comentários que existem nele… diagramas de classes/atividade/sequencia desatualizados mais atrapalham do que ajudam. Mas bem, essa é minha opinião… uso e não tenho problemas, código ruin é código ruin com/sem diagrama de classe.

E botar a culpa nos programadores não é muito sensato, assim você está dizendo que um programador ruin com bons diagramas resultará em um código de qualidade, o que sabemos não ser verdade.

Rubem Azenha:

deniswsrosa:

Isso prova que você trabalhou apenas em projetos pequenos.

Quando temos fluxos muito complexos, sistemas grandes com várias pessoas desenvolvendo, UML é fundamental para que todos se entendam, não dá pra desenvolver algo “aqui no meu quadrado”.

Mesma coisa a “lista Minima de requisitos”, vc simplesmente está dando pouco valor a principal fase do projeto, o levantamento de requisitos. Acho que boa parte dos projetos falham por esse motivo, muitos gerentes já querem “sair programando” e pulando as outras fases de desenvolvimento, no final dá merda e ninguem sabe o porque.

Quando vc tem uma otima analise de requisitos e uma ótima documentação, programar vira uma tarefa que pode ser feita por code monkeys.

Bem-vindo ao mundo do CMMi…

Eu discordo totalmente do seu post. Ter um arquiteto da torre de marfim pra escrever UML e 10 code monkeys para cegamente implentar os diagramas UML nao é algo produtivo… ja trabalhei bastante nesse esquema e a produtividade é muito baixa. E geralmente a qualidade tambem nao é das melhores, por que o diagrama nao consegue representar tudo o que o programador precisa pra codificar, algumas decisoes o programador tem que tomar. Se o programador é um code monkey, ele vai tomar decisoes ruins. Se ele nao é um code monkey, ele nao precisa de um diagrama mostrando o que ele tem que codificar passo-a-passo.

E se voce quiser fazer um diagrama que mostra todos os detalhes pra um programador codificar, o diagrama vai ficar tao complexo e tao demorado pra fazer que voce vai precisar de 10 arquitetos da torre de marfim.

E o problema mais grave é que em 99% dos casos esses diagramas acabam ficando desatualizados. Com o passar do tempo, mudanças vao sendo feitas no codigo refletindo uma mudança nos requisitos que nao é refletida nos diagramas UML. O que acaba confundindo que vai dar manutencao no sistema. E se for necessario adicionar funcionalidade nova, o diagrama desatualizado confunde o arquiteto da torre de marfim… No fim acabam fazendo UML só para seguir o processo, mas ignoram na hora de codificar.

Enfim, eu nao acho uma boa idea fazer o sistema usando a metodologia “Arquiteto da torre de marfim que manja de UML + 10 code monkeys”. É melhor e mais produtivo ter 2 desenvolvedores com boas noçoes de design, orientacao a objetos e TDD.

Voce pode usar UML, mas acho que projetar num nivel mais alto. Ou entao pra projetar algo, mas nao pensando que aquilo vai ser o passo-a-passo de um outro desenvolvedor.

HAHAHA

Esse CMMI…

Já estive numa situação a que você descreveu, em que tivemos que entregar diagramas antes do código, no “fim” da fase de design, então fizemos pra seguir o processo mesmo, mas o código que desenvolvemos depois não teve nada a ver com os diagramas.

http://www.agilemodeling.com/artifacts/robustnessDiagram.htm

Acho que eu daria meu testículo esquerdo para NUNCA MAIS ter que ouvir alguém falar em fase de requisitos quando fala de RUP. Não existe fase de requisitos, fase de design, fase de codificação nem fase de testes no RUP. Quem divide seu projeto em fases atreladas a uma única atividade, vai terminar o projeto com uma bela fase de envio de currículo.

O pessoal está confundindo a UML com o uso dela. Não é porque você usa UML que tem de ficar alguém só programando UML e alguém só codificando o que está escrito em UML. Não é porque você usa UML que a fase de requisito tem de terminar todinha pra depois começar a fase de codificação.

Nem CMMI, RUP ou PMI pregam isso. Se alguém faz dessa forma, está fazendo por sua conta, não culpem a ferramenta por quem a usou.

O pessoal tá confundindo a aplicação de UML com metodologia de desenvolvimento. A UML se encaixa no ciclo de vida em cascata, em espiral, Up to down, enfim…
É totalmente possível utilizar todos os padrões UML e codificar antes da diagramação, depende do que foi determinado para a metodologia do projeto.

drsmachado:

O pessoal tá confundindo a aplicação de UML com metodologia de desenvolvimento. A UML se encaixa no ciclo de vida em cascata, em espiral, Up to down, enfim…
É totalmente possível utilizar todos os padrões UML e codificar antes da diagramação, depende do que foi determinado para a metodologia do projeto.

Falou e disse, “bela e fofa caveirinha” hehehe
Agora toda vez vou lembrar do nosso amigo disfarçado pra conseguir tirar dúvidas. :lol: :lol:

drsmachado:

O pessoal tá confundindo a aplicação de UML com metodologia de desenvolvimento. A UML se encaixa no ciclo de vida em cascata, em espiral, Up to down, enfim…
É totalmente possível utilizar todos os padrões UML e codificar antes da diagramação, depende do que foi determinado para a metodologia do projeto.

Putz, terminei de ler o tópico agora e finalmente alguém falou o que tava pensando em escrever.
Mas que saco, que mania é essa de querer usar uma coisa em detrimento de outra. Sem essa de “ou um ou outro”, é necessário o equilíbrio, não exclusividade.

A maioria dos casos onde ví isso acontecer era indício da pouca experiência da equipe aliada a metodologia waterfall (um pouco mais um do que outro, mas sempre caminhando juntos).

LOL
Que conste que ri muito com esse post, muito bom!

É verdade.

As fases do RUP possuem enfase em determinada área (como modelagem, implantação, etc). Infelizmente nunca estive em um processo RUP de verdade