Há alguns anos, quando era consultor independente, eu fui chamado por uma empresa bem grandinha do ramo de telefonia. Eles tinham produtos em C++ e queriam migrar para o Java. Na verdade já haviam migrado, mas estavam com problemas.
A primeira tentativa deles foi transferir toda a parte gerencial do sistema -que era vendido por alguns milhões de Euros- para Java. Para fazer esta etapa eles haviam contratado há um ano uma consultoria especializada canadense. Os canadenses sugeriram a compra de uma ferramenta RAD -por um acaso de outra empresa canadense- que permitiria que os desenvolvedores C++ criassem a aplicação em pouco tempo. Em três meses, tempo recorde, a aplicação já estava rodando no cliente, em produção. Durante os testes eles verificaram que a coisa era muito lenta mas como o mercado de telefonia tem muito dinheiro eles simplesmente aumentaram o número de máquinas.
A coisa foi passando até que alguém foi fazer a primeira manutenção. O sistema era um grande catálogo de assinantes, dependentes e registros de ligação, as regras pesadas mesmo ficavam no sistema em C++. As primeiras manutenções foram correção de bugs. A ferramenta funcionava dentro do Eclipse, você definia um modelo de entidades parecido com o modelo relacional, depois dizia quais operações precisava (criar, ler, listar, etc.), isso gerava o código. Se você precisasse de uma regrinha de negócio diferente, digamos que cada vez que um novo cliente fosse adicionado alguém recebesse um email, ia ter que alterar o código gerado. Como a aplicação -como todas- tinha suas peculiaridades muito código era escrito a mão. Mesmo assim o ato de criar toda a infra-estrutura (o scaffolding) poupava muito tempo.
Qual não foi a surpresa quando alguém reparou que a ferramenta só gerava código, ela não o lia de volta? Se você alterar o código e fizer alguma alteração o fornecedor deu duas escolhas:
- Alterar o código usando a ferramenta gráfica, regerar o código e depois adicionar novamente nossas alterações
- Abandonar a ferramenta e fazer tudo no código
Neste ponto que eu fui chamado. O fornecedor sugeria fortemente a segunda opção, por incrível que pareça. Eu concordei com eles, recomendei ao cliente que assumisse o prejuízo de ter escolhido uma ferramenta ruim e refatorasse o sistema enquanto inseria novas funcionalidades.
O mundo adora ferramentas RAD. Elas provocam a ilusão de que você não precisa de conhecimento ou de um profissional para criar programas. Não é assim que a banda toca.
Essas ferramentas surgem todos os anos. Todos se dizem revolucionários, quase nenhum diz que é um gerador de código, e todos dizem que servem para 87% dos casos. Puro marketing.
Geradores deste tipo existem há décadas. É até engraçado que o mais novo representante desta leva se gabe de ‘revolucionar’ usando o conceito de programação visual por fluxograma. Ahm? Isso existe praticamente desde que surgiram IDEs gráficas. Qualquer coisa que gere código via UML vai ter um fluxograma. A diferença é que não vai ter só fluxogramas, exatamente porque essas coisas foram abandonadas.
Na UML utilizamos o diagrama de atividades para um fim muito específico: representar transição entre estados dos objetos. É um dos diagramas mais raramente utilizados em um projeto OO simplesmente porque ele é procedural demais. Um sistema OO foca na interação entre objetos, não em algoritmos em si -que estão encapsulados dentro dos objetos.
Ao utilizar um fluxograma como unidade principal do seu sistema você está abandonando a OO. Isso pode ser uma coisa boa, depende do caso. para sistemas genéricos décadas de pesquisa da indústria apontam que Orientação a Objetos traz os melhores resultados na modelagem de negócios. Para um caso específico (BPM por exemplo), fluxogramas podem ser melhor. Estas ferramentas vendem trinta anos de retrocesso em modelagem.
Ainda assim, elas oferecem um bom scaffolding, não? Você não precisa saber nada sobre arquitetura, basta gerar o código na ferramenta! Bem, não exatamente. A maioria destas ferramentas vai seguir o exemplo acima: possuem poucos pontos de extensão e quando possuem não conseguem se integrar a eles. A primeira pergunta a fazer para um fornecedor desses é se a ferramenta suporta round-tripping. Round-tripping é o ato de gerar o código na ferramenta, editar o código e a ferramenta ser capaz de lidar com o código alterado. Quase nenhum RAD possui esta característica.
Outro problema é a arquitetura. Eu tenho certeza que uma arquitetura web simples pode ser utilizada por 87% dos casos mas tenho mais certeza ainda que cada um destes casos vai evoluir de uma maneira diferente. A arquitetura tem que ser flexível o suficiente para permitir todas estas formas de evolução. Obviamente que nenhuma destas ferramentas oferece nada parecido. Nós já vimos antes sobre o problema de se estabelecer uma arquitetura única para tudo, o problema com estas ferramentas é muito pior. Quando se define uma única arquitetura para todos os sistemas de uma empresa é ruim mas o que estas empresas estão vendendo é uma arquitetura única que funcionaria em diversos tipos de aplicações de diversos domínios sem sequer saber as necessidades delas antes.
Infelizmente em busca do cálice sagrado as empresas e -pior ainda- governos vão continuar gastando dinheiro nestes engodos. Eles prometem inovação mas fazem retrocesso de três décadas no tempo. Como conseguem montar um CRUD em 30 minutos são vendidos como a última bolacha do pacote, e lá vão os gerentes desinformados comprar estas coisas.
Se você está procurando este tipo de ferramenta esqueça qualquer um desses produtos ‘revolucionários’. Para começar entenda que a Ciência da Computação ainda não tem uma resposta definitiva para você. Sinto muito, estamos trabalhando nisso (é uma das partes da minha pesquisa). O campo mais avançado nesta área chama-se MDA. Eu não acredito em MDA mas isso não me faria negar que ela é a proposta mais plausível para este tipo de ferramenta atualmente. MDA possui implementações livres e proprietárias, é um padrão do OMG, utiliza UML, é baseado em um conceito de transformação de modelos e não de geração de código, é extremamente extensível e pode ter as características de produtividade dessas ferramentinhas de garagem. Só não baseie sua estratégia nele.
Os problemas de MDA: (1)ele eleva o nível de abstração mas não gera programação intencional e (2)ele usa uma ferramenta que não foi criada para isso, UML. São problemas muito menores do que os que você vai enfrentar com estes softwares ‘revolucionáros’ de ‘programação por fluxograma’.
Não caia no conto do vigário.
Todo ano aparece um revolucionário, quem se lembra (sofreu) do Egen?
Tem até empresa que sai no Brasil inteiro palestrando sobre sua revolucionária ferramenta que faz tudo…
[...] ia esquecendo, o Shoes blogou sobre a discussão do [...]
Fala Phillip,
adicionei vc no msn. Queria trocar uma idéia sobre algumas coisas. Bom, quando tiver on line me autoriza lá.
[] s e seus pots continuam nos fazendo pensar bastante.
obs: sobre o mac book, ele faz isso td mesmo ? se faz, eu vou chorar e querer um pra mim hehe
Até que essas ferramentas têm o seu lado positivo: se não fosse aquela discussão no GUJ sobre o MAKER, esse post seu não sairia, não é?
[...]seus pots continuam nos fazendo pensar bastante.[...]2
Há pessoas/empresas que imaginam que sistemas são sempre/somente CRUD… todas “regras” (ou características) do sistema são “esquecidas”.
Apenas algumas correções de texto.
*…(2)ele usa uma erramenta…* = * erradamente *
*…menores do que os que voc6e vai…* = * você *
A um pouco mais de 1 mês atrás eu escrevi sobre o assunto em http://emerleite.wordpress.com/2007/12/12/programadores-escrevem-codigo-ferramentas-apenas-ajudam/
É impressionante como esses fornecedores estão enganando muita gente e vendendo uma suposta “galinha dos ovos de ouro”.
Parabéns pelo post
Obrigado novamente, Leandro, correções feitas ;)
O engraçado é que essas ferramentas “revolucionárias” conseguem tirar o emprego atual de muitos bons profissionais no mercado, pois quando um bom profissional está numa empresa que adota tal ferramenta ele já procura coisa melhor (o que não é melhor que isso, certo?) no mercado :) No final das contas, a empresa perde dinheiro por todos os lados, contudo ela só percebe alguns anos depois.
Excelente post Phillip, parabéns.
Sempre que trabalhei em empresas médias/pequenas desempenhei o papel de Desenvolvedor por completo. Quando trabalhei em empresas grandes, em sua maioria absoluta existiam analistas, inclusive eu que sequer tocavam no código. Isso me saturou e ví que não tinha nada a ver comigo.
Por favor não aprove o comentário anterior. Era para estar no post de analista de sistemas e eu o coloquei aqui por engano. Me confundi nas abas do firefox :)
Ferramentas servem apenas para *ajudar* a uma equipe de desenvolvimento a ser mais produtiva, não fazer milagres como essas ferramentas propôem. Até porque milagre mesmo elas estão longe de fazer pois a representatividade de um CRUD no todo é praticamente nula. Quanto ao MDA acho que a proposta é boa, tem gente boa dando o apoio, mas acho que não pega não. *Eu não acredito em milagres no desenvolvimento*.
Phillip, você já trabalhou com alguma ferramenta que faça transformação de modelo? Pois até agora a melhor ferramenta que já tive contato que diz que faz algo MDA foi a AndroMDA e ela transforma modelo UML da fase de análise em código :0
Ei, cuidado, MDA não esta necessariamente restrita a UML :)
De que MDA você está falando, Rubem?
http://www.omg.org/mda/executive_overview.htm
Parabéns pelo post, eu já vivenciei este cenário.
Li os posts sobre o Maker e me lembrei do JCompany, AppFuse, AbShaper, Facas Ginsu, o antigo GAS (Clipper), a série de livros aprenda em 24 horas e os produtos fantásticos made in Taiwan, todos são incríveis.
SCJA, SCJP, SCWCD, SCBCD, SCDJWS, SCEA, SCEA5
Shoes, parabéns por mais este excelente post.
No entanto, eu fiquei com uma dúvida relativa ao seguinte trecho:
“Na UML utilizamos o diagrama de atividades para um fim muito específico: representar transição entre estados dos objetos. É um dos diagramas mais raramente utilizados em um projeto OO simplesmente porque ele é procedural demais. Um sistema OO foca na interação entre objetos, não em algoritmos em si -que estão encapsulados dentro dos objetos.”
Estou longe de ser um profundo conhecedor da UML, na verdade, ainda tenho um conhecimento bem superficial dela, mas “representar transição entre estados dos objetos” não seria a função do diagrama de estados?
Analisando o parágrafo como um todo, me parece claro que você está mesmo se referindo ao diagrama de atividade, principalmente ao mencionar que o foco de sistemas orientados a objetos é a interação entre os objetos, e não os algoritmos que estes encapsulam, que por sua vez são modelados pelo diagrama de atividade.
No entanto, ainda assim aquela sua definição sobre o papel do diagrama de atividades me causou uma certa estranheza, o que me fez cogitar que talvez você tenha se enganado naquela parte específica, ou que então os meus conceitos relativos a UML estão piores do que eu imaginava.
Eu sei que este não é exatamente o ponto central do post, mas se pudesse me esclarecer essa pequeno detalhe eu ficaria grato.
De qualquer forma, parabéns pelo artigo novamente.
Oi, Elomar,
Você está certo. O diagrama de estados que msotra estas transições. O que eu tentei dizer -e me enrolei todo- é que o diagrama de atividades não possui modela algoritmos simplesmente, ele modela interações entre objetos que ocasionam na mudança de estados destes.
[]s
Olá, Shoes.
Agora entendi o que você quis dizer, e, pra ser sincero, percebi que tinha um percepção incompleta sobre o diagrama de atividades. Sendo assim, obrigado pelo esclarecimento.
Abraços.
[...] Saiu no InfoQ uma matéria sobre o J2EE Spider, do Bruno Braga. Eu recebi um email do Bruno há algum tempo me convidando para fazer um review da nova versão da ferramenta, e dando ênfase no fato que não é um gerador abrace-o-mundo como vemos por aí. [...]
Olá, o que você disse acontece extamente da forma como o disse. Onde trabalho, está acontecendo exatamente isso. Um programador conseguiu vender a idéia para um gerente e está desenvolvendo (isso é o pior, está começando do zero) uma ferramenta que promete fazer de tudo, gerar código, fazer CRUDs em pouco tempo, gerar telas, gerar código em várias linguagems, prometendo que o analista vai se focar somente no negócio e etc… Lindo né? Pq ninguém nunca pensou nisso??? Rsrs… Trabalhei em um projeto em que as regras de negócio mudavam tanto e eram tão específicas que era díficil fazer manutenção no sistema e deixar a aplicação do jeito que o cliente queria. Queria ver como uma ferramenta dessas dá conta do recado, ou não né!!! É dose trabalhar em um lugar e estar cercado de idiotas.
Abraço.
Caro pcalcado,
Duas coisas:
O Rubem Azenha tah certo, MDA nao eh exclusivamente UML, embora UML seja a oferta da OMG para modelagem (vide o link que postaste). Se leres o MDA Guide, vais ver que eles sempre usam “may”, “can”, mas nunca “must” ou “should” ou coisa parecida.
Diagrama de atividades nao modela interacoes, modela comportamento (diagramas de sequencia e colaboracao, sim). O comportamento pode ou nao involver invocacoes de operacoes no mesmo objeto ou outros objetos, mas essa eh apenas uma das possibilidades. Maquinas de estados sao outra forma de definir comportamento de elementos como operacoes.
Falou,
Rafael
Rafael,
Eu já li a documentação do MDA. Se o OMG vende MDA comot ecnologia agregada ao UML (vide quote) então seu argumento é algo como: “Nem todo computador é binário”. É claro que é possível, só não tem nenhum caso prático.
Quanto aos diagramas, eu realmente gostaria de saber como você consegue modelar uma algoritmo usando objetos sem utilizar interações entre objetos. Se você possui uma linguagem sem objetos isso é possível, numa linguagem 100% OO não.
MDA eh uma iniciativa para padronizar a terminologia (PIM, PSM, PM, markings, etc) das praticas existentes de desenvolvimento baseado em modelos, e nao um pacote de tecnologias concebido pela OMG. Existem varias ferramentas que se encaixam em MDA e que nao usam UML, usam metamodelos proprietarios, alguns deles precedendo a propria UML (Shlaer-Mellor). UML 2.* inclui um monte de coisas que essas linguagens de modelagem jah possuiam, justamente para que a OMG tivesse uma solucao completa o suficiente para se fazer MDA usando tecnologias OMG. Mas isso nao eh pre-condicao.
Re: diagrama de atividades vs. interacoes
Cara, foi o que eu escrevi acima: o foco do diagrama de atividades nao eh interações, e sim ações/activity nodes (pedaços de comportamento). Invocação de operação é uma entre 50 ações disponíveis, por baixo. Por isso, nao faz sentido destacar interacoes entre objetos. UML, assim como Java, C++ e C# (e diferentemente de Smalltalk) *não é* 100% orientada a objetos, bem longe disso.
Rafael,
Como quotei antes o OMG define MDA em função de UML. Se hipoteticamente podemos ter MDA sem UML pode ser uma coisa interessante mas não consigo ver ninguém fazendo isso -pelo contrário, quem não usa UML foge de MDA como faz a Microsoft com DSL Tools. Se você tiver alguns exemplos destas “varias ferramentas que se encaixam em MDA” ajudaria.
Eu não incluiria Mellor nessa lista. Em 2007 eu assiti uma palestra dele no SPIN-RS onde deixou bem claro que não acredita que as iniciativas em torno de UML são bem sucedidas porque o comitê se recusou a adotar características básicas para tonrar a linguagem executável -que por coincidência, foram sugeridas por ele. Se o autor do método alou que é uma furada eu não sei exatamente o que pode ser contestado.
Sobre diagramas, você falou claramente acima que diagrama de atividades não modela interações. Meu ponto é que num sistema OO não existe qualquer atividade se não houver interação entre objetos. Se você tem um diagrama deste tipo sem interações entre objetos o que você tem é um fluxograma, uma técnica muito usada nos anos 70. Da especiicação:
E eu não encontrei nada na especificação do diagrama sobre não-objetos. Aliás, a especificação é danosamene abstrata. De qualquer modo, você não precisa de linguagens 100% Orientadas a Objetos para ter programas Orientados a Objetos.
Resumindo:
- MDA não precisa ser feito só com UML: Ok, mas ainda é mesmo que “computador não precisa ser binário”. Possível pode até ser mas quem faz? Aliás, qual a vantagem de fazer?
- Diagramas de Atividades modelam comportamentos e nao interações: Ok mas num sistema OO comportamento vai implicar em interações.
Se você acredita que MDA é uma plataforma razoável, ótimo, existem várias pessoas que acreditam nisso.
Gente essa ferramenta não passa de um furor no mercado. Logo o mercado vai se tornar seletivo e abandonar uma idéia mal acabada.
A Softwell é bastante marketeira e tem bastante grana pra isso, pois o Freire não tem apenas empresa de informatica, logo se vê que não entende o produto que tem em mãos.
Tive contato com a ferramenta, cheia de bugs e mesmo a pessoa que apresentou não conseguiu finalizar um unico fluxo simples que em qualquer linguagem não demoraria mais do que alguns minutos.
Programar em fluxo não é 60 vezes maior produtividade e sim extremamente moroso e medonho.
Cara… concordo em parte com que vc falou… mas tem nego q só repete as coisas sem pensar. Essas ferramentas obviamente que são pra CRUD. Se o seu sistema não tem mto CRUD, simplesmente não use. Um bom exemplo disso seria o FPA. Se o seu sistema não tem mto CRUD, esqueça FPA. Como mto bem foi dito pelo autor, essas ferramentas NÃO tiram emprego de programador… apenas facilita e aumenta produtividade.
Tenho experiência positiva nessa área. Desenvolvi uma ferramenta que gera toda a aplicação. Por enquanto apenas pra PHP. O analista e os programadores gostaram bastante da ferramenta, inclusive propondo novas funcionalidades e encontrando bugs. A nova versão (gera view tbm) está em fase beta. A aplicação gerada faz CRUD a partir do diagrama de classes e foi projetada utilizando padrões arquiteturais como MVC e MVP (o usuário escolhe). Escolhe ainda uma série opções como linguagem, SGBD, e outros. []’s
Vão me crucificar, + penso que a visão do $ muda as coisas: Vejam: Prezados, além de empresário do uma softhouse com presença nacional e com clientes de vários portes, fui professor por muitos anos nas disciplina de ciência da computação e naquela época comungava com vocês em todas as críticas às ferramentas, especificamente o MAKER. Já fui purista em software livre, java, oo, uml, e etc. Naquela época, não faz muito tempo, uns 2 anos atras, tb pensava como os senhores. No entanto, hoje o problema de produtividade na minha empresa e outras softhouses é grande. Observe os post´s aqui, se defende muito o programador e não a empresa que gera os recursos para todos nós. Temos avaliado estas ferramentas com um check-list de mais de 500 questões e apesar de tudo comentado (o mais pesado de uma delas que estamos preferindo é não usar O.O., ou seja, volta no passado) tem com poucas deficiências atendido nossos testes inclusive práticos. É difícil ler o que estou escrevendo e não acreditar, qq programador vai dizer que estou doido, que não temos futuro, etc. + na verdade é bem simples: Se faz CRUD, implementa o que precisamos no cliente, com a velocidade que precisamos, gera $ e dá vida às nossas organizações. Não esqueçam por favor que há aplicações em COBOL rodando em grandes cias até hoje e são eficientes, mesmo com interface que muitos aqui morreriam de rir, ou seja, elas estão gerando $ para manter os empregos de muita gente. Demorei para sair do encantamento da tecnologia e cair na real que o cliente quer é resultado, não importa como vc faz isto, desde que seja seguro e entregue o prometido.
Por favor, já estou bem calejado com críticas e gestão de conflitos tem sido meu passatempo nos últimos anos. É interessante ver como muitos nobres colegas escrevem com raiva com tanto vigor, nesta hora eles se questionam e com o tempo, 40, 50 anos lembrarão do que eu estou escrevendo aqui.
Abraços a todos
Prof.DAvince
Davince,
Não vi nenhum argumento no seu texto com relaçao aos pontos levantados no post. A ferramenta em questão faz CRUD de forma rápida? Isso não é nenhuma novidade, com seu “calejamento” todo imagino que você, como eu, já viu isso dezenas de vezes anteriormente e já sabe onde isso vai parar.
[...] Eu sempre me questionei sobre programadores que somente leem tutoriais na net e trabalham com o “Ctrl+c e Ctrl+v”, onde muitas vezes você não tem noção do que código está fazendo (eu já me peguei fazendo isso), “mas funciona” então não meche (qualquer semelhança é mera coincidência). Acho que por esse tipo de “profissional” que ainda há pessoas que acreditam que daqui a pouco as ferramentas RAD vão acabar com os desenvolvedores (vide: aqui e aqui). [...]