Há exatamente um ano Ivar Jacobson “media a temperatura” da UML. Como um de seus criadores, Jacobson fez uma leitura honesta da moda (“espalhou como fogo em mato seco”), desilusão, críticas de acadêmicos e agilistas e do ressurgimento da UML. Concluiu pedindo um uso mais “esperto” (smart) da linguagem. Conclusão vaga e marketeira: ele mantém o “Smart Blog” que vende um “Smarter Way”. Muito smart e ambíguo para o meu gosto.
O que não desvaloriza seu diagnóstico objetivo e claro do momento atual da UML. Sim, a UML ganha uma segunda vida. Ou deveríamos dizer segunda chance? Até a Microsoft, que parecia ter sugerido de forma um tanto ingênua que DSL’s (Domain-Specific Languages) seriam alternativas à UML, agora destaca seu amplo suporte como um diferencial da nova versão do Visual Studio¹. São diversos os sinais que indicam um tipo de renascimento da UML. O que fazer para evitar um novo ciclo de desilusões e abandono?
Deveríamos começar por uma isenta avaliação de tudo o que fizemos de errado na primeira onda. Em primeiro lugar há nossa irritante mania de viver colocando a carroça na frente dos bois. A adoção da UML significou, para várias organizações, a aquisição de ferramentas caríssimas. Os fornecedores dessas ferramentas, cumprindo bem o seu papel, prometiam maravilhas. Particularmente em relação ao aumento da produtividade dos desenvolvedores. Ignoravam ou faziam vista grossa para um contexto mais amplo. A incorporação da UML normalmente fazia parte de um plano maior: a implantação de novos métodos de trabalho. Numa cumbuca mais sortida que feijoada baiana fica difícil apontar responsáveis diretos por ganhos ou perdas. E a UML acabou pagando muito mais do que devia. Tanto que até hoje encontramos pessoas que acham que UML é uma “metodologia”.
Ensinar UML através de uma ferramenta é como ensinar matemática com calculadoras: um grande e sério erro.
Desconfio que a raiz do problema está na forma como UML é ensinada e aprendida. O ensino da UML através de uma ferramenta, qualquer ferramenta, é um grande erro. Tão sério quanto ensinar matemática com calculadoras. Os alunos não têm a chance de perceber a UML como ela é, como uma Linguagem. E as limitações das ferramentas, que não são poucas, acabam interpretadas como limitações da linguagem.
Por exemplo, não é raro encontrar pessoas que dizem que o desenho ao lado é um erro. Para elas a UML seria um simples padrão de notação. E, como tal, estaria restrita às figurinhas oferecidas nas ferramentas. Considero este o mais sério e comprometedor problema que temos com a UML. Uma limitação que nos leva a utilizá-la da mesma maneira que um compositor de funk carioca utiliza a língua portuguesa.
Como toda linguagem, do português ao C#, a UML é viva. É extensível. Podemos e devemos adaptá-la às nossas necessidades. Mas fizemos um serviço tão ruim neste ponto que existem aqueles que acham que a possibilidade de criar extensões como a EPBE (Eriksson-Penker Business Extensions) é gambiarra ou correção de bugs, não uma característica projetada da linguagem.
Ao ensinar UML devemos abandonar toda e qualquer ferramenta automatizada. Lápis e páginas de caderno são tudo o que precisamos para ensinar e aprender UML. Um profissional que domine bem os conceitos da linguagem saberá tirar mais valor de qualquer ferramenta que lhe seja oferecida. E assim, talvez, aquelas promessas maravilhosas dos fornecedores de ferramentas se realizem.
Grande Demais, Complexa pra Chuchu
Não deveríamos ensinar português através da gramática e sim com Chico Buarque e Machado de Assis.
São outras críticas comuns, que aparecem principalmente no discurso de alguns agilistas. Toda linguagem é naturalmente complexa. Ou, melhor colocando: toda gramática², em sua plenitude, é naturalmente complexa. O fato é que pouquíssimos de nós dominamos a gramática da língua portuguesa, por exemplo. Mas isso não impede que utilizemos a língua das mais diversas maneiras em nosso dia a dia. O mesmo precisa ser dito sobre a UML. Ninguém precisa conhecer de cor e salteado toda a especificação e o metamodelo da UML, sua gramática, para poder utilizá-la. Aliás, se quisermos espantar fregueses, basta apresentar a UML desta forma.
A UML é grande por necessidade, não por pura encheção de linguiça. E parece complexa para todos que não entendem ou não aceitam sua proposição original, de ser uma Linguagem Unificada de Modelagem. Ela é perfeita? Claro que não – fomos nós humanos que a criamos. É boa? Sim, eu diria excelente. Mas talvez esteja aqui seu grande problema: não há nada que possa ser comparado à UML. Lá em meados dos anos 90 tínhamos dezenas de propostas de padrões de notação. A UML veio para acabar com aquela baderna. Mas seu sucesso e consequente aceitação universal – um tipo de monopólio – criou este problema. Ela não é pior nem melhor nem maior nem mais complexa que ninguém simplesmente porque não temos com o que comparar.
UML não é Chacrinha
O Chacrinha dizia que tinha vindo para “complicar, não para explicar”. O maior objetivo da UML é o oposto. E, de novo, tenho que apelar para o “L” de UML: toda linguagem criada pelo homem tem esse único objetivo, facilitar a comunicação. Mas não são poucas as organizações que destruíram esse propósito quando instituíram que UML era “padrão de documentação”. Quando passaram a exigir que esse ou aquele diagrama fossem elaborados com o único propósito de documentar determinado trecho de um projeto. Nada pode ser mais nocivo e criar mais antipatia a uma proposta do que a percepção de obrigatoriedade descerebrada ou insensata. Por isso não são poucos os que fazem cara de nojo quando ouvem as letrinhas U-M-L. Passa da hora de devolvermos à UML suas proposições originais: explicar, e não complicar; Facilitar a comunicação e interação, e não substituí-las.
Confesso que a ficha do péssimo uso que fazemos da UML só caiu quando comecei a participar de alguns fóruns e a apresentar meus eventos para analistas de negócios. Cheguei a acreditar na realização da profecia sugerida na capa da Software Development de abril de 2001, apresentada acima. Mas aí vieram o artigo do Jacobson, debates mais ricos, empresas interessadas na ressurreição da UML e a onda do Pensamento Visual. Taí, a UML realmente tem sua segunda chance. Ou eu deveria dizer que nós temos uma segunda chance?
.:.
Observações:
- Na revista INFO de junho/2010 tem um anúncio do Visual Studio, apresentado na forma de uma entrevista com o gerente de produtos da Microsoft Brasil, Sr. Rodrigo de Carvalho. A primeira pergunta é: “Por que clientes devem migrar para a nova versão do Visual Studio 2010?”. Resposta: “Por várias razões, mas destacaria: suporte à modelagem UML…“. Sim, ele começou pelo suporte à UML. Quem conhece o histórico das idas e vindas da MS em relação à UML entenderá o meu destaque aqui.
- Gramática, segundo o Houaiss, é um “conjunto de regras que determinam o uso correto de uma língua”.
Não exagero quando trato a especificação da UML como um tipo de gramática. E reitero objetivando a aceitação de que UML é de fato uma língua. E que, como tal, ela deve nos ajudar a atender três grandes objetivos: i) Organizar o conhecimento; ii) Representar o conhecimento; e iii) Trocar conhecimentos.
The Morte e Vida UML by finito, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 Brazil License.
Artigos relacionados:
Related posts brought to you by Yet Another Related Posts Plugin.
{ 11 comments… read them below or add one }
Fantástico Paulo,
Eu acho que UML é um recurso excelente que temos ao tentar comunicar idéias de design de software. Nos últimos anos andei freqüentando eventos que pregam o agilismo e sempre achei engraçado como batem em UML e logo em seguida ensinam a modelar desenhando quadrados e círculos num quadro branco e acham que aquilo é totalmente diferente da UML. E ficam bravos quando eu pergunto sobre padronização.
Vamos ver se nossos erros não vão ser descontados em mais uma solução padronizada de novo.
Excelente artigo Paulo. Mais uma vez impressionando com a “linguagem” usada. Concordo plenamente quando diz que “Ensinar UML através de uma ferramenta é como ensinar matemática com calculadoras: um grande e sério erro” e que deveria ser ensinado “português ..com Chico Buarque e Machado de Assis”. Infelizmente isso é o que acontece nas escolas e faculdades. Isso faz com que aconteça um recuo na curva de aprendizado da pessoa bem como uma limitação cada vez maior no fato de conhecer a fundo determinado ensino/prática/metodologia.
Concordo plenamente e mais uma vez, obrigado por nos brindar com seus excelentes artigos. Este já estou encaminhando para toda equipe aqui da CTBC. (Claro, com seus devidos créditos!!)
Abs
Olá Rodrigo, Nilton e colegas tuiteiros,
Muito obrigado pelos comentários e por compartilhar.
@Nilton, eu até entendo as restrições colocadas por alguns agilistas. Tem muito a ver com a forma como a UML vem sendo (mal) tratada ao longo dos anos. São traumas, meu caro. Traumas que acabam criando incoerências como a apontada por ti.
Abraços,
Paulo Vasconcellos
Oi, Paulo,
A Microsoft melhorou o suporte à UML do Visual Studio não por qualquer tipo de “renascimento”, mas sim porque era uma funcionalidade bastante criticada na ferramenta. O /mainstream/ continua usando UML e seria muito difícil um fornecedor de ferramentas não querer este mercado. Fora o fato que a fonte citada não é exatamente uma referência em desenvolvimento de software ou foca neste público.
Sobre limitações, creio que você está certo e errado. A linguagem em si não te limita (UML sequer precisa ser gráfica!) mas a forma de extensão da linguagem é extremamente burocrática –vide a baixa popularidade e eventual fracassos de tentos profiles que surgiram e se foram. UML é extremamente mais difícil de se extender que português, é bem parecida com C# no sentido que possui um padrão a ser seguido. A solução para extensibilidade é, geralmente, adotar apenas uma parte da linguagem mas o fato de você ter que fazer este tipo de coisa já é um sintoma dos problemas desta.
Quando diz que “toda linguagem é naturalmente complexa” creio que você erra em assumir que linguagens, do português ao C#, são a mesma coisa. Apesar de haverem conceitos “globais” de design (o novo livro de Fred Brooks fala muito disto) uma linguagem natural é *muito* diferente de uma linguagem criada para ser formal e visual, que por sua vez é muito diferente de uma linguagem formal e executável.
E linguagens não precisam ser complexas para serem completas. Matemática, LISP e Ruby são exemplos de linguagems extremamente simples e elegantes e ainda assim completas. UML não precisaria ser tão complexa, o é por razões histórias e o típico design por comitê.
Ainda que houvesse a necessidade de ser complexa para ser completa e unificada, isto apenas colocaria em xeque a necessidade de tal linguagem, especialmente hoje que sabemos claramente que transformação de modelos não é tão simples quanto se achava nos anos 90.
UML é útil em diversas ocasiões mas não dá para defender o design de uma ferramenta onde praticamente 100% dos usuários têm que usar um subconjunto do já subconjunto básico da linguagem.
[]s
Olá Shoes,
Antes de mais nada, muito obrigado pela contribuição. Vamos lá:
1. A MS tentou, por mais de uma vez, abandonar a UML. O fato de um gerente de produtos dela, mesmo que não seja uma referência – um desenvolvedor, citar o suporte à UML no Visual Studio me espantou sim. Pela reviravolta e pelo fato de se tratar de uma versão 2010 do produto. E não creditei o “renascimento” só a este fato. Utilizei-o apenas como exemplo.
2. Não vejo os três mecanismos de extensibilidade oferecidos pela UML como complexos. Concordo contigo que a brevidade dos profiles apontam para um problema. Mas seria mesmo da linguagem? Eu, por exemplo, brigo por uma maior (re)conhecimento da EPBE. Sua não adoção tem pouco ou nada a ver com a UML ou a complexidade de seus mecanismos de extensão. 90% de quem já estudou UML mal sabe da existência deles. O buraco é mais embaixo.
3. Quando comparei linguagens, do português ao C#, trabalhei no mais alto nível de abstração possível. É claro que uma linguagem natural se diferencia de uma linguagem de programação que se diferencia da UML. Mas, lá em cima, todas buscam: i) a organização do conhecimento; ii) a codificação do conhecimento; e iii) a troca de conhecimentos.
Talvez eu tenha utilizado o termo “complexo” de forma um pouco desleixada. Matemática pode ser complexa. Assim como a UML. Que também pode ser simples. Minha mensagem principal foi: podemos complicar ou simplificar o ensino e uso da UML. Sempre complicamos. A outra alternativa merece uma oportunidade.
4. Algumas expectativas que existiam com a UML, particularmente com sua versão 2.0, já caíram por terra. Defendo seu uso mais básico e mais amplo. Afinal, como eu disse, não temos nenhuma outra alternativa. Temos?
Abraços,
Paulo Vasconcellos
Paulo,
1) A Microsoft já tentou se livrar da web, do open-source e de qualquer coisa que ela considere uma ameaça a seu modelo de negócios. Nenhuma destas tentativas teve a ver com méritos técnicos ou de processo, apenas questões econômicas relacionadas à maneira como a empresa lida com ameaças.
2) Parece que concordamos em discordar então. Eu já tive que trabalhar com extensões (geralmente da Rational) e tive até que criar algumas. Não só o esforço foi ridiculamente enorme bem como até agora eu não entendi qual o benefício em se utilizar uma extensão da UML ao invés de notações gráficas específicas (e apesar de UML não ser apenas uma notação gráfica, para mim ela simplesmente não tem valor prático como linguagem em si; apenas como visualização de um modelo OO que foi ou será construído em uma linguagem executável e verificável).
3) A linguagem matemática não é complexa, pelo contrário. Os conceitos por trás da linguagem podem o ser, mas isso é outra coisa.
Como um exemplo, pense em JavaScript ou Ruby. São linguagens extremamente simples, você consegue certamente aprender todo o seu escopo em uma tarde. O fato de que lidam com temas complexos (OO via protótipos, metaprogramação, etc.) não faz delas linguagens complexas.
5) Temos centenas de alternativas, Paulo. De cartões CRC até Omni Graffle existem várias formas de se modelar um problema com notação gráfica consistente –muitas vezes baseado em, ainda que incompatível com, UML.
[]s
Shoes,
1. É o histórico citado por ti que fez com que o “amplo suporte” à UML pela Microsoft merecesse destaque.
2. Aqui discordamos mesmo. Talvez porque você esteja entendendo que todo o trampo com extensões seja “ridiculamente enorme”. Na maioria dos casos não é. Não precisamos de novas EPBE’s ou extensões para modelagem de dados o tempo todo. O que tentei passar é que não utilizamos como deveríamos nem recursos básicos de extensão como os estereótipos. Por isso coloquei aquele “ator com dúvidas” no artigo.
3. Ok. Entendi seu ponto.
5. Não vejo as sugestões apresentadas por ti como alternativas. Podem funcionar como complementos. Aqui talvez a gente caia em questão de “gosto”. Eu gosto de trabalhar com um conjunto. E a UML me oferece um conjunto que cobre pelo menos 80% de minhas necessidades para a comunicação e expressão visual.
Mas eu entendo que nossas perspectivas são muito distintas. E respeito seu ponto de vista.
Abraços e mais uma vez obrigado pela contribuição.
Paulo Vasconcellos
Olá Paulo,
muito bom o post!
Penso que não só UML, ou linguagens, mas tudo que se vai aprender, deve ter início nos conceitos, e não nas ferramentas.
As pessoas pensam que dominar uma ferramenta em determinado assunto, é dominar o assunto.
Um abraço.
Oi Murilo,
A praga da “carroça na frente dos bois” é universal. Um colega, artista e designer, também vive reclamando que a área dele tá repleta de gente que sabe tudo sobre Photoshop e afins mas não conhece o básico sobre desenhos, cores etc. Nossas “escolas”, por omissão ou ação, têm grande parcela de culpa pela praga.
Abraços e muito obrigado pela participação.
Paulo Vasconcellos
Muito bom artigo,
se todos os anlistas, desenvolvedores e profissionais envolvidos no projeto de um sistema tivessem essa visão da UML, não sairiam utilizando ela porque se ‘deve usar UML’, mas sim porque precisam usar. É importante compreender a necessidade de usar uma notação que possa ser utilizada para facilitar a comunicação com outras pessoas, e assim facilitando o entendimento a respeito de determinado processo, classes, etc.
Pois é, caro Bruno, pois é!
Obrigado pelo comentário. Abraços!
Paulo Vasconcellos