Uh-Éme-Éle
Este tópico no GUJ chamou atenção, especialmente porque o li logo após um interessante texto noblog do Marcelo Araújo sobre uma outra faceta do mesmo tema: modelagem usando especificações não executáveis.
O que eu quero dizer com isso? Dada a tecnologia atual na maioria das empresas (desconsiderando o uso de coisas como DSLs ou mesmo alguma solução MDSD que, ao contrario de MDA, funcione) todos os documentos comumente utilizados para “modelagem” não são verificáveis, não são executáveis e requerem um trabalho manual enorme. Como bem disse o Emerson Macedo no post, você acaba programando duas vezes, uma na sua notação gráfica (UML) e uma na sua notação executável (Java, C#, Ruby… o que for).
Acontece que ao passar do diagrama (e diagramas aceitam qualquer besteira) para o código (onde o compilador e testes unitários são muito exigentes – fora os usuários) o tal do pseudo-modelo criado pelo “analista” no Rational Rose (porque a empresa não percebeu que o Rose foi descontinuado há anos) é completamente diferente do modelo implementado. As classes até têm o mesmo nome mas a mecânica interna é bem diferente. E por quê? Porque UML não vai te oferecer tudo o necessário para modelar. O mínimo que se espera de um modelo de um sistema é que ele seja verificável para saber se cumpre seus requisitos. Como é que eu vou saber isso com UML? Como eu testo UML?
Há algum tempo que eu me pergunto porque que se usa UML para “modelar”. Não me entenda mal, UML é uma ótima noção gráfica para Orientação a Objetos e com ela você consegue passar uma big picture muitas vezes mais rapidamente do que código; mas ela fica por aí: comunicação.
Quando modelamos o comportamento de objetos nós estamos descrevendo como este se comporta em diversas situações. Ao modelar uma determinada atividade você precisa descrever um conjunto grande de detalhes sobre esta, e UML não esta pronta para este tipo de coisa - e nem é a idéia por trás dela. Se modelar em UML fosse eficiente nós estaríamos programando em UML não em C#, Java ou o que for.
O primeiro problema ao tentar introduzir este pensamento na indústria é: mas eu não posso deixar que meus “implementadores” façam o que quiserem. Pergunta: o que raios é um implementador? Um datilografo de luxo?
Supondo que sua empresa seja a típica empresa de três letrinhas, aquelas que contratam qualquer um como “programador júnior” porque ele vai receber instruções do analista. Neste cenário eu pergunto: para que o tal programador? Que tal dar ao seu “analista” uma ferramenta mágica em que ele consiga criar um modelo abstrato e ao mesmo tempo executável? Que tal se ao invés de gastar rios de dinheiro pagando 10-reais-mais-o-busão para seus implementadores você eliminasse completamente a necessidade deles, fazendo com que o “analista” sozinho cuide do serviço?
Não precisa sacar seus milhões do banco nem pensar em como justificar o gasto com esta ferramenta no orçamento, você muito provavelmente já possui o necessário dentro da sua empresa: uma linguagem de programação decente. Faça seu “analista” usar código para expressar a modelagem. No final dá no mesmo para o nível de modelagem desejada e você ainda ganha algo verificável e executável. Economia de rios de dinheiro quase que instantânea.
Mas como assim? O “modelo lógico” é muito diferente do “modelo físico” e o “analista” não pode perder tempo com essas coisinhas de tecnologia, tem que pensar em modelar o negocio. Muito bem, duas coisas:
- Analista de Sistemas não é analista de negócios. Se você não sabe o que é um analista de negócios eu recomendo que você mande um e-mail pro Paulo Vasconcellos perguntando.
- Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo “diagrama de domínio”. POJO/POCO, Hibernate, IoC, Camadas, OO, AOP, EJB3, MVC… toda essa parafernália de letrinhas permite que seus objetos de negocio não tenham o menor traço de infra-estrutura. Claro que alguém vai ter que fazer a infra-estrutura –ainda que seja mínima. Caso seus “analistas” sejam de qualidade extremamente baixa eu recomendo que você contrate um bom técnico para atuar como arquiteto e líder técnico do time.
Verdade seja dita: esta não é a primeira vez que este blog trata do tema e desde a última vez muita coisa melhorou, mas ainda há muito que melhorar.
July 25th, 2008 at 10:49 pm
Já amei UML. Já odiei UML. Hoje foda-se UML.
UML nasceu para facilitar o entendimento de rotinas detalhadas (ex: cálculo de imposto) e globais (ex: arquitetura) do teu sistema. Hoje em dia, para as rotinas específicas, um teste unitário é muito mais fácil de entender do que a UML. Para rotinas globais, um diagrama no OpenOffice Draw bem feito possui muito mais informação e apresenta-a de uma maneira muito mais amigável do que qualquer diagrama da UML.
UML morreu. Só que esqueceram de anunciar no Jornal Nacional. :)
[]s
July 26th, 2008 at 1:58 am
“esta não é a primeira vez que este blog trata do tema” e tomara que não seja a última! a cada vez a visão melhora mais.
July 26th, 2008 at 8:12 am
Concordo, serve como comunicação. Para gerar diagramas de bibliotecas modeladas em LINGUAGEM DE PROGRAMAÇÃO também é válida…
[]s
July 26th, 2008 at 8:15 am
Amém!
E quando leio o que você escreveu, “me cago de medo” de ir pra uma empresa que tenho o SenhorGrandeModelador e eu seja o Implementador. Se eu conseguir emprego em algum lugar assim… eu prefiro ficar desempregado. Uma, ele vai me dar diagramas de casos de uso, de classes, sequência e estados (só por cima). Tudo isso, ele manda zipado por e-mail (veja a situação): eu nunca vi a cara do caboco e tenho que entender como funciona aquilo. Se as coisas funcionarem assim, você tem um grande caminho divulgando seu blog ou escrevendo um livro no estilo Diogo Mainardi. E você tem todo o meu apoio. Minha turma da faculdade já lê as coisas que você posta aqui e um dai eu convenço eles de que as coisas que o professor fala nem sempre se aplicam à realidade.
Abraço.
July 26th, 2008 at 8:55 am
“O implementador não vai ter a sacada de usar o pattern X”,”O implementador vai usar patterns onde não devia”, “O implementador vai furar o encapsulamento”, “O implementador não vai pensar em reuso”, escuto essas frases a anos. Não sei porque é tão difícil acreditar que pessoas podem programar e continuar: sendo inteligentes, tendo bom senso, lendo bons livros…
July 26th, 2008 at 10:22 am
Mundo corporativo é outra assim mesmo, pois a última assinatura é sempre do senhorzinho que não sabe nada de software e para ele, algo só é sério quando baseado em documentos. E ao aprovar certa metodologia a se instaurar na empresa na qual ele é diretor, ele sempre vai aceitar estas. É difícil, sendo realista, enfiar tais idéias na cabeça destes. E como fazer?
O que tentei foi adotar certas práticas na minha equipe, tudo in-box, sem “ferir” ninguém da alta gerência. Er, tentei..
1 - Ninguém acreditava que iria funcionar
2 - Ninguém queria mudar, “estava dando certo”
3 - Resignação é praxe neste tipo de corporação
4 - Eu pedi demissão e estou atrás de uma empresa séria para trabalhar.
July 26th, 2008 at 10:41 am
Shoes, shoes… tem algum trauma com o Rose? he he he…
Cara, desde sempre uma linguagem visual é boa para ter este “big picture” que você falou. Segundo o Booch “nós usamos um modelo para compreender melhor uma coisa que é complexa”. Ponto final.
Também tenho asco dessa divisão “analista-implementador” e usar UML para “programar”. De qualquer forma, geralmente vejo a UML como uma boa ferramenta de ensino OO e uma boa introdução sobre conceitos arquiteturais.
@Andre Brito
Cara, a última coisa que nossa area precisa hoje é um Diogo Mainardi. Acredite.
Abraços!
July 26th, 2008 at 12:37 pm
Um dos maiores problemas com a UML, RUP foi o uso errado. Ainda hoje encontro muitas empresas utilizando “RUP” com analise e projeto na fase de Elaboração e codificando na fase de Construção, ou seja, cascata (em todos os sentidos). Em muitos casos, dizer que usa RUP, significa apenas que estão usando os 200 templates do Repositório do RUP.
Usar UML como codificação ou documentação, só se você for obrigado a especificar para uma fabrica de software que usa mão-de-obra barata. Contudo, concordo com Rodrigo Yoshima, UML ainda tem usos importantes.
A filosofia e praticas ágeis tem resultados são evidentes, mas a necessidade de entender conceitos de forma sólida não mudou (muita leitura). Acho que esse ainda é o maior desafio, formação de pessoas.
July 26th, 2008 at 4:44 pm
Oi Phillip!
Sobre essa mania das empresas quererem substituir programadores por datilógrafos de luxo, é porque infelizmente muitas empresas são como as descritas no livro Peopleware:
“The maddening thing about most of our organizations is that they are only
as good as the people who staff them. Wouldn’t it be nice if we could get
around that natural limit, and have good organizations even though they
were staffed by mediocre or incompetent people? Nothing could be
easier—all we need is (trumpet fanfare, please) a Methodology.”
Pelo que vejo, apenas pequena parte dos gerentes de projeto percebeu que Methodologias não funcionam, a maioria ainda acredita que software pode ser contruído como casas: o engenheiro faz a planta (que podem ser os diagramas UML!) e os pedreiros colocam os tijolos.
E vai tentar explicar que software é novo desenvolvimento e não manufatura para quem tem Waterfall na cabeça há mais de 20 anos, é quase impossível, sou da opinião que os céticos só mudarão de opinião - *se* o fizerem - por si próprios, depois de muitas casas desmoronarem.
July 26th, 2008 at 4:50 pm
Ah, para os que tiverem curiosidade, o ótimo capítulo sobre Metodologias do livro Peopleware está aqui:
http://web.mit.edu/orange/process/method
July 27th, 2008 at 12:01 pm
Parabéns Philip. Concordo plenamente. Seu post me fez lembrar o que eu disse para o ‘analista’ sexta: “esquece esses diagramas e me ajuda a pesquisar a solução” ahhahaha!
July 28th, 2008 at 12:54 am
Tks Philip, pela referência.
Rodrigo, concordo contigo: a última coisa que precisamos é um Mainardi.
Abraços,
July 29th, 2008 at 1:11 am
@Rodrigo Yoshima
“nós usamos um modelo para compreender melhor uma coisa que é complexa”
O ponto que gostaria que incitar um pouco é que muitas e muitas vezes “a coisa” nem é complexa…
[]´s
July 30th, 2008 at 11:44 pm
Na equipe que trabalho usamos UML muito superficialmente apenas para comunicação, principalmente para demonstrar a arquitetura do sistema. Tudo via papel e lapis.
Acredito que UML ainda não está morta. Mas acredito que assim como o RUP é muito mal entendido e aplicado a UML também o é.
Como o Philip colocou:
“Há mais de cinco anos que não há quase nenhum motivo para que uma aplicação Java ou C# não seja uma cópia de 1-para-1 de um modelo UML do tipo “diagrama de domínio”. ”
Então a UML pode ser utilizada muito ainda, principalmente aumentando a produtividade e reduzindo etapas no desenvolvimento.
August 1st, 2008 at 5:13 am
Olá Philip,
em ‘defesa’ de MDA, posso dizer que minha experiência com ferramentas desse tipo é boa. Com MDA o modelo UML acaba sendo ‘compilado’. Temos documentação sempre atualizada (afinal o PIM é a base para a geração de código) e ela sempre reflete aquilo que o sistema faz.
[]s
August 2nd, 2008 at 12:42 am
Um problema nessa discussão é que muitas das grandes empresas não desenvolvem em casa. Apenas especificam. O uso de fábricas de software é muito comum. Então como fica? Como passar um especificação consistente e de fácil entendimento (entendimento comum) para a fábrica?
August 2nd, 2008 at 9:05 am
De todos os diagramas da UML fico com dois:
- Caso de uso: serve como resposta à pergunta “tá entendendo ou quer que eu desenhe?”
- Atividade: dar uma visão ampla/geral para algum técnico (tester, por ex.) do que o sistema é capaz.
E para por aí.
August 2nd, 2008 at 12:25 pm
@Tiago
Meu grande problema com MDA é tentar usar uma linguagem que não foi feita para isso para escrever proramas. Não é só porque uma ferramenta é visual que ela aumenta o nível de abstração.
(nta: eu sei que MDA teoricamente não precisa ser visual nem UML, só nunca vi uma ferramenta mainstream que não o fosse)
@Leonardo
Fábrica de software é consequência do problema. Quando voc^percebe que separar o rojeto em “fases” é waterfall não há sentido em usar uma fábrica de software. Neste caso, para terceirizar serviços, basta utilizar uma onsultoria “normal” e não uma linha de montagem.
August 6th, 2008 at 5:12 am
@Shoes
“Meu grande problema com MDA é tentar usar uma linguagem que não foi feita para isso para escrever proramas. Não é só porque uma ferramenta é visual que ela aumenta o nível de abstração.”
Você se lembra para que Java originalmente foi feito? ;)
“(nta: eu sei que MDA teoricamente não precisa ser visual nem UML, só nunca vi uma ferramenta mainstream que não o fosse)”
A quais ferramentas exatamente você se refere?
August 8th, 2008 at 9:13 am
Rubem,
1 - A linguagem Java foi feita para ser uma liguagem multi-propósito com sintaxe parecida com C++. Ela é assim até hoje.
2 - Qual ferramenta mainstream MDA não usa UML?
August 15th, 2008 at 6:02 am
Com MDA eu mexi um pouco com o Together, você pode utilizar outros metamodelos (inclusive Java) e até criar uma outra “linguagem de modelagem” (que por consequência vai criar outros metamodelos) e criar transformações em cima dessa linguagem (ou dos metamodelos que essa linguagem trabalha). Eu mesmo criei uma “Spring Modeling Language” e fiz uma “transformação” que gera os arquivos de configuração do Spring só para testar. Ficou legal para provar o conceito…
PS: não tenho certeza se isso é MDA mesmo ou se é simplesmente transformação de modelos…
August 22nd, 2008 at 9:18 pm
“Minha turma da faculdade já lê as coisas que você posta aqui e um dai eu convenço eles de que as coisas que o professor fala nem sempre se aplicam à realidade.”
concordo plenamente, me parece que o problema vem de sala de aula, o professor quando fala de UML fala que é indispensavel, sem o C.Uso, D.Classe e D.Sequencia não dá nem para começar a desenvolver, que sem UML não temos uma base para começar o desenvolvimento… acho que ninguém usa relamente UML, seus diagramas como Atividade, Estado, Sequencia… pelo menos não tenho visto ninguém dizendo que usa e tem ganhos com isso… concordo com o que foi dito no post, são tantos frameworks como HIbernate, Spring’s que por mais que fizessemos uma excelente documentação com a UML não refletiria o que será desenvolvido.
August 27th, 2008 at 11:21 am
[…] sobre a qual ponderei hoje. O primeiro é o “13 reasons for UML’s descent into darkness” e o “Uh-Éme-Éle” do blog Fragmental, que descobri hoje e considero muito bem escrito e interessante. Ambos […]
September 26th, 2008 at 12:29 pm
[…] que não pensa e simplesmente segue algumas folhas de papel com vários diagramas UML e fluxos alternativos escritos por analistas de sistemas, eu -como desenvolvedor- devo estar tão […]
November 11th, 2008 at 7:34 am
[…] atender esta necessidade, normalmente uma equipe nova é contratada, toneladas de documentos e diagramas são produzidos até que os programadores comecem a codificar. A esta altura, o prazo já está […]