Porque não se generaliza o UML ? As 5 razões

Não é por falta de divulgação que o UML não tem uma adopção generalizada. Desde há alguns anos que “UML” é uma palavra que entrou no vocabulário de todos os que trabalham na engenharia de software. Apesar disso, o certo é que em Portugal o seu uso é pouco mais que residual. Tirando alguns – poucos – projectos em que existe um cliente, um gestor de projecto ou um arquitecto de software que faz questão em fazer alguma especificação em UML, esta notação não é praticamente usada. Se me pedissem uma projecção, eu diria que 95% dos projectos de software que se realizam em Portugal não são especificados em UML. Fora de Portugal, a realidade não é muito diferente. Segundo uma pesquisa de 2006 do professor Júlio Leite, da Universidade Católica do Rio de Janeiro, as taxas de adesão variavam muito consoante as zonas do globo mas, em nenhum dos estudos encontrados, ultrapassava os 30% de adesão.  Acredito que agora o panorama seja um pouco mais animador.

Vamos então às 5 razões que, na minha opinião, explicam o relativo insucesso:

1 – A compreensão dos diagramas não é clara nem imediata

A compreensão dos diagramas obriga a algum tempo de estudo e assimilação de conceitos e não é entendida pela maioria das pessoas. As que têm background informático de há 10-15 anos atrás ou mais, não tiveram nos seus estudos uma formação forte em OOP e as outras, aquelas que têm capacidade e formação não podem, nem fazem, diagramas em UML porque simplesmente os primeiros é que mandam e lhes pagam os ordenados!

2 – É encarado apenas como desenho inicial do sistema

Na maior parte da vezes é visto e utilizado apenas como um conjunto de normas para desenhar e documentar projectos quando estes estão no seu início. Com o decorrer do projecto e a introdução de alterações ao mesmo, raramente estas alterações são repercutidas nos diagramas iniciais. Assim, este tipo de documentação passa a ser apenas um conjunto de papéis desactualizados que nunca mais serão lidos por ninguém.

3 – As aplicações que existem são fracas

Ainda não apareceu a killer application que vai tornar o desenho em UML fácil e acima de tudo produtivo. Um exemplo: Para mim quando estou a desenhar um diagrama de classes não quero estar a pensar se coloco a classe por cima, à esquerda ou à direita, se há espaço ou não … quero lá saber … para isso existem algoritmos e ferramentas que, consoante as relações que estabeleço entre os vários componentes, o tamanho que esses componentes ocupam no ecrã e a importância de cada um, me desenham a melhor imagem/diagrama possível. É isso que se passa com as aplicações para desenho de diagramas UML mais conhecidas do mercado? Infelizmente não. Perde-se um tempo enorme a “arrumar” as classes, os packages, as ligações, etc. É realmente muito tempo com coisas que não são importantes.

4 – Domínio de utilização demasiado amplo

O UML pode ser utilizado para especificar quase tudo. Tanto é utilizado para especificar regras e classes de negócio de alto nível como é utilizado para especificar detalhes técnicos que só interessam aos programadores. Gera-se assim um pouco de confusão nos vários stakeholders.

5 – Falha no diagrama de classes

Considero que o diagrama de classes é o diagrama com mais importância na notação UML. Assim, qualquer falha que este apresente tem obviamente repercussões importantes.

E de que falha estou eu a falar?

Não existe maneira de implementar construções semelhantes ao Mixin do Ruby, Pyton e de outras linguagens modernas, as chamadas dinâmicas, que vão um pouco mais longe na implementação do conceito OOP. Este conceito, apesar de só agora estar a aparecer nas linguagens mainstream, foi desenvolvido inicialmente na linguagem LISP, há muitos anos atrás. Estranhamente para mim, nunca foi adoptado nem na linguagem Java, nem pela mais recente linguagem C#.

Para quem não conhece, um Mixin é um tipo de construção parecido com uma classe tradicional mas com algumas diferenças:

  • Não pode ser instanciada, i.é, não podemos criar instâncias desse tipo;
  • Serve como resource para outras classes de uma forma transversal à hierarquia normal de classes em OOP;
  • Permite também que determinada instância de uma classe normal, em runtime e de forma dinâmica, possa estender esse Mixin.

Costumo dar como exemplo de implementação, a classe “Cliente” ou “Fornecedor”. É bastante comum, quando estamos a modelar um sistema, identificarmos estes elementos como classes normais OOP mas, se pensarmos um pouco, iremos perceber que um “Cliente” ou “Fornecedor” não são propriamente classes estáticas, mas sim comportamentos e características pontuais de alguns indivíduos – instâncias-  de duas classes: a classe “Pessoa” e a classe “Empresa”. Estes comportamentos manifestam-se quando estes efectuam as acções de vender ou comprar algo.

Como este, existem dezenas de outros exemplos da vida real que não são passíveis de modelar correctamente no diagrama de classes do UML na sua actual especificação, a 2.0.

Conclusão

Nos projectos de software onde participo, há muitos anos que não abdico de fazer a representação em UML – ou tipo UML –  do sistema aplicacional que a equipa vai desenvolver. Não estou a dizer que utilizo sempre todos os diagramas mas, o diagrama de classes de alto nível -o que representa o negócio- é sempre obrigatório.

Claro que utilizo alguns “truques” para minimizar ou mesmo ultrapassar as deficiências que identifiquei nos pontos anteriores. Mas, sobre isso falarei detalhadamente em próximos posts.

Adianto apenas a minha visão acerca dos duas principais funções que os diagramas UML devem ter no desenvolvimento de projectos de engenharia de software: 

  1. Representar em toda a extensão, o domínio funcional para o qual estamos a desenvolver o software;
  2. No seu formato XML, deve ser a source principal de todo o sistema aplicacional seja qual for a tecnologia de mais baixo nível que se utilize – C#, JAVA, Ruby. ASPX, JSP, JSF, SQL, Oracle …etc – para fazer correr as aplicações.

Será que isto é possível? Sinceramente penso que sim.

Para quem ficou curioso e quiser ter uma ideia de como isto pode ser feito, o professor Paulo Sousa escreveu uma série de artigos – este é o link para 1º artigo- no seu blog que vale a pena ler.

Referências:

[Leite 07] Leite, J.C.S.P, Alguns dados sobre o uso de UML, Março 2006, http://jcspl.wordpress.com/2006/03/31/uml-e-popular-na-producao-de-software/

OMG, UML in Practice: A Survey of UML Use, Fev 2005,  http://www.omg.org/docs/ad/05-02-08.pdf

IBM Rational UML Resource Center,
http://www-306.ibm.com/software/rational/uml/

Anúncios

Deixe uma Resposta

Preencha os seus detalhes abaixo ou clique num ícone para iniciar sessão:

Logótipo da WordPress.com

Está a comentar usando a sua conta WordPress.com Terminar Sessão / Alterar )

Imagem do Twitter

Está a comentar usando a sua conta Twitter Terminar Sessão / Alterar )

Facebook photo

Está a comentar usando a sua conta Facebook Terminar Sessão / Alterar )

Google+ photo

Está a comentar usando a sua conta Google+ Terminar Sessão / Alterar )

Connecting to %s

%d bloggers like this: