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

Programação Arquitetura
#23

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 :frowning: Acho que foi a situação mais ridícula e vergonhosa da minha vida profissional.

#24

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.

#25

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.

#26

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!

#27

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.

#28

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.

#29

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

#30

É 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.

#31

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

Ninguém confessa, mas usam Go Horse diariamente.

#32

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.

#33

[quote=Rubem Azenha][quote=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.

[/quote]

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.[/quote]

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.

#34

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

#35

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.

#36

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.

#37

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.

#38

[quote=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.[/quote]

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:

#39

[quote=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.[/quote]

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).

#40

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

#41

É verdade.

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

#42