Pois é, caro Bruno, pois é!

Obrigado pelo comentário. Abraços!

Paulo Vasconcellos

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.

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

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

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

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

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

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