Baseado no livro Domain Specific Modeling por Steven Kelly e Juha-Pekka Tolvanen, Lispy, o autor do blog Learning Lisp, expôs alguns pensamentos sobre como uma linguagem de modelagem deveria parecer:
1) Ela deveria mapear os conceitos do problema de domínio e não os detalhes de implementação.
2) Ela tem que ser formalizada e útil não somente para experts do domínio mas tam´bem para as tarefas de desenvolvimento tornando possível gerar código executável a partir do código executável, documentação e certas classes de testes, assim como eliminar a necessidade de implantar algum outro teste, e elevando o nível de abstração para os mantenedores do código.
3) Ela precisa ter suporte em ferramentas stand alone que deveria permitir aos experts do domínio “organizar seus frameworks e bibliotecas de maneira que os modelos possam ser ‘compilados’ em um código totalmente funcional.”, e tudo isto sem ter que pensar em termos de código. Para ilustrar esta idéia, Lispy utiliza a analogia de compilar C para código de máquina, onde C é de alguma maneira “uma linguagem de modelagem para código de máquina” e onde programadores C não precisam modificar o código de máquina compilado utilizando compiladores criados pelos experts da linguagem.
Então, para termos uma linguagem de modelagem realmente útil, você tem que ir para “Especifico do Domínio” em ambos os lados do problema: a linguagem de modelagem tem que mapear diretamente o domínio do problema e o código gerado tem que mapear ao ambiente alvo. [...] Se o processo de geração de código é muito complicado, você pode precisar de abstrações melhores no nível do framework. Se o processo de geração de código é impossível, então a linguagem de modelagem pode não estar fornecendo uma descrição detalhada o bastante dos requisitos. Se tem muita repetição nos modelos, então a linguagem de modelagem vai precisar ser extendida para cobrir os conceitos adicionais.
Onde a UML se encontra em todas estas observações? De acordo com o autor, UML não é uma ferramenta apropriada para desenvolvimento dirigido a modelo. Ela não pode ser compilada, executada, ou interpretada, dessa maneira sendo “reduzida ao nível de mera documentação” e adicionando “nenhum valor a mais para o projeto além de um comentário de código elaborado.”. De acordo com Lysp, UML aplica abstração “no ponto errado do problema” porque ela “foi projetada para mapear codificação de arquiteturas- e por conta disto falhou ao elevar o nível de abstração"
Seven Kelly recentemente expressou opinião similar:
Eu sempre pensei em UML como sendo mais específica sobre escolhas de implementação [...] –ex.: a restrição para uma linguagem orientada a objetos, e suas classes individuais, campos e métodos de uma implementação definida diretamente nos modelos. [...] A única parte da UML que está em um nível maior de abstração é o diagrama de Casos de Uso, e ela tem falta total de precisão.
Entretanto, reagindo ao seu post, Franco Civello argumentou que é possível utilizar UML com sucesso em um desenvolvimento dirigido a modelo de maneira “a expressar modelos precisos em alto nível de abstração”, falou ainda que somente utiliza “aquelas partes do UML propícia a uma interpretação concisa”:
Eu vou justificar minha posição dando um exemplo de como a UML pode ser utilizada para escrever modelos sem detalhes de implementação.
[…] tendo produzido casos de uso informais para esclarecer requisitos, e um modelo de domínio para pegar um entendimento inicial da área desejada, o analista produz um modelo de especificação preciso, em UML, onde o sistema a ser desenvolvido é representado como um objeto, pertencendo a um tipo (nota, não uma classe, como o sistema é utilizado em uma abstração para definir o comportamento visível, nem uma entidade de software para ser implantada diretamente, por exemplo, Java).
Os passos em um fluxo de um caso de uso são então formalizados como operações no tipo do sistema, com uma especificação declarativa de comportamento baseado na notação de um contrato funcional, escrito com suas pré e pós condições, expressadas em modelo subjacente (o tipo de modelo do sistema, derivado essencialmente do modelo de domínio).
Lispy julga a abordagem interessante e ele argumenta que isto não necessariamente uma contradição com o que Kelly e Tolvanen sugeriram em seu livro. UML é utilizada para mapear o domínio do problema ao invés de descrever o código da arquitetura, existe uma certo nível de formalização e, conforme frisado por Franco Civello, “um subconjunto executável da UML, xUML, esta disponível e também é suportado por algumas ferramentas”.