Então, quando eu estava na universidade, fui educado sobre os benefícios da UML e seu futuro no desenvolvimento de código.

Mas, de acordo com minha experiência no setor, descobri que, embora utilizemos diagramas - desde diagramas de ER, diagramas de classe, diagramas de estado até diagramas de fluxo de trabalho - tudo isso é para fins de comunicação.

Ou seja, nunca gerei código automaticamente a partir de diagramas e, do ponto de vista da comunicação, geralmente tento manter meus diagramas o mais simples e fácil possível de entender.

Mas quando olho para o Visio e o Enterprise Architect, parece que eles têm muitos tipos diferentes de gráficos, formas, objetos de propriedades, a maioria dos quais não uso.

As pessoas usam a UML para fazer coisas mais sofisticadas, como geração de código ou banco de dados?

Sim, as ferramentas UML CASE foram um dos itens quentes dos anos 90 ... e falharam no fornecimento.

A razão fundamental para isso é que os diagramas UML (ou quase todos os outros tipos de) ajudam a entender o problema e / ou o programa que o soluciona apenas na medida em que o diagrama está abstraindo os detalhes de implementação do código real. Assim (para qualquer parte não trivial do código), um diagrama que é fácil de entender é inerentemente inútil para a geração de código , porque não possui os detalhes necessários. E vice-versa, um diagrama que é diretamente utilizável para geração de código não ajuda muito a entender o programa melhor do que o próprio código. Se você já viu um diagrama de classes UML com engenharia reversa a partir do código de produção, provavelmente sabe o que quero dizer.

A única exceção em potencial que conheço são os diagramas de Entidade-Relacionamento, que não abrangem o código em si, apenas (como o nome indica) partes de dados e seus relacionamentos. Mas nunca ouvi falar de uma tentativa bem-sucedida de usar qualquer tipo de diagramas UML para geração de código real [Atualização] - ou seja, mais do que esqueletos de classe e código trivial como getters / setters -, exceto em ferramentas / áreas de propósito especial como ORM, como testemunhado pelo Doc Brown abaixo [/ Update] , e acho que não é por acaso.

Pessoalmente, não odeio a UML - acho que os diagramas da UML podem ser uma ótima ferramenta de comunicação - para mostrar suas intenções e idéias durante as discussões de design ou para visualizar a arquitetura do seu aplicativo. Mas é melhor mantê-los nisso e não tentar usá-los para coisas em que não são bons.

Então, quando eu estava na universidade (há um tempo atrás), me disseram que a UML era o futuro, a UML substituirá a programação e apenas geraremos código a partir de diagramas etc.

Eles estavam errados. Isso acontecerá quando as pessoas abandonarem a fala e voltarem à pintura nas cavernas.

Os problemas do mundo real e os programas que os resolvem têm uma complexidade essencial que não pode ser reduzida. Para produzir um programa de trabalho, essa complexidade deve ser capturada e expressa em alguma linguagem executável. A questão é se alguma linguagem de programação diagramática poderia ser mais eficaz do que uma linguagem de programação textual. Temos experimentado programação esquemática há cerca de trinta anos, e até agora as evidências são predominantemente a favor da programação textual. Não conheço nenhum aplicativo importante produzido pela geração de código a partir de diagramas.

NÃO

A legenda foi baseada na suposição falhada de que a escrita:

class ClassName extends SomeThing
{

}

... é difícil e precisa de automação .

Você ainda pode encontrar um crente ocasional ou uma multidão de crentes.
Mas é assim que acontece com as religiões e cultos.

Esteve lá, não achou muito útil.

Geralmente, os diagramas específicos o suficiente para gerar algum código a partir deles, principalmente o diagrama de classes, não acrescentam muito ao entendimento do programa e você não pode gerar código a partir dos diagramas de visão geral, como caso de uso ou atividade no nível da visão geral. crucial para a documentação. Um diagrama que é útil para entender e pode gerar código é o gráfico de estados, que é útil quando você realmente precisa de uma máquina de estados. Mas geralmente você deve tentar evitá-los, porque eles são inerentemente propensos a erros.

Em um projeto, fomos solicitados a projetar o código no modelador UML (Rhapsody) e gerá-lo a partir daí. Funcionou e provavelmente foi um pouco mais fácil do que digitar os cabeçalhos (era C ++) e os protótipos manualmente. A capacidade de manter esses dois consistentes automaticamente foi um pouco útil.

Os corpos dos métodos ainda precisavam ser preenchidos manualmente, porque os diagramas não podem realmente representar isso, com exceção dos esqueletos das máquinas de estado.

Por outro lado, é bastante complexo, então você precisa aprender muitas coisas extras e, mais importante, foi doloroso mesclar. A fusão é bem pesquisada para arquivos de texto e funciona com eles, mas ninguém inventou a maneira fácil de mesclar as alterações nos diagramas ainda. O Rhapsody, na verdade, mantém parte das informações no código gerado e as analisa novamente, portanto não era totalmente inutilizável, mas ainda era uma complicação séria.

Embora seja certamente possível gerar código (e até sistemas inteiros) diretamente dos modelos UML, nunca o encontrei sendo usado dessa maneira.

Na minha experiência, a maioria das empresas parece usá-lo como uma ferramenta de comunicação para requisitos, ou "MS Paint para desenhar diagramas".

Uma distinção importante que eu gostaria de fazer é que a maioria das ferramentas de modelagem UML permite criar um único modelo do seu sistema. O Visio, por exemplo, tem um entendimento bastante bom de como a UML funciona e há muitas coisas que você pode adicionar que não estão diretamente relacionadas ao diagrama. Os diagramas reais são simplesmente perspectivas diferentes em partes do modelo, permitindo destacar aspectos diferentes do sistema.

tudo isso (diagramas de modelagem) é para fins de comunicação

A modelagem tem 4 usos importantes no processo de desenvolvimento de software:

1. Ferramenta de Design Integrado

2. Ferramenta de comunicação

3. Uma ajuda à geração de software

4. Uma maneira de reduzir a complexidade do problema das palavras reais (aprendi isso com a resposta de @kevin cline acima)

5. O processo de modelagem leva alguns designers a pensar em detalhes não considerados durante a codificação (e vice-versa). A modelagem em tempo de design permite que você considere uma imagem maior do que codificar um método ou uma classe em um idioma.

Na minha opinião, a modelagem é vital para criar bancos de dados (diagramas de ER), entender os fluxos de processos (diagramas de atividades) e entender as interações usuário-sistema (diagramas de casos de uso).

As pessoas usam a UML para fazer coisas mais sofisticadas, como geração de código ou banco de dados?

Sim, de fato. ERDs (não um diagrama UML) e diagramas de classes podem ser usados ​​(dependendo dos recursos da sua ferramenta) para gerar:

1 - Linguagem de definição de dados (DDL)

2 - Procedimentos armazenados para diagramas de CRUD e de classe no seu idioma preferido (menos útil, pois as ferramentas ORM fazem mais sobre isso)

Entre os recursos mais valiosos das ferramentas de modelagem estão:

1 - Capacidade de manter a integridade do modelo. Se você fizer uma alteração, ela será propagada no modelo

2 - Capacidade de responder a perguntas usadas (onde a 'conta' é usada no meu modelo?)

3 - Capacidade de permitir que usuários simultâneos trabalhem no modelo

4 - Pesquisar em representações gráficas

5 - Controle de impressão

6 - Camadas (organize seus elementos do diagrama em camadas) para que você possa se concentrar em uma camada por vez

7 - Geração de código de banco de dados para vários sistemas de banco de dados

8 - Validação do modelo (verifica a consistência, falta de chaves, ciclos, etc.)

Portanto, as ferramentas de modelagem, especialmente as boas, fazem muito mais que o Paint.

Usamos o Arquiteto de Software para criar projetos de alto nível e documentar algumas das interações mais misteriosas de componentes em nossas coisas. Às vezes, geramos o esqueleto do aplicativo a partir dos diagramas, mas, uma vez feito isso, mantemos os dois separadamente, não tentamos fazer engenharia reversa do código em um diagrama após a conclusão. Eu costumava usar uma ferramenta chamada Rational XDE que funcionava muito bem para programas pequenos, mas ela se perdia quando você começava a adicionar manipuladores de eventos Swing ou tentava trabalhar com o Struts.

Penso que uma grande parte da razão pela qual as pessoas não escrevem em UML é que é preciso muito mais trabalho para especificar completamente tudo em UML e gerar o código a partir do seu diagrama. Eu sei que o Departamento de Defesa dos EUA está trabalhando com o OMG para desenvolver algumas ferramentas que irão gerar código "comprovado" a partir de diagramas que foram verificados corretos, mas minha impressão é que você acabará com uma ordem de magnitude mais metadados do que o código real. O que provavelmente é bom (afinal, é documentação), mas gerar metadados não é mais rápido do que escrever código, então você acaba gastando proporcionalmente mais tempo.

A própria UML é um sistema de notação, por isso é motivo de comunicação e documentação. É raro o caso de gerar código a partir do modelo UML, mas sim, existem pessoas fazendo isso. Usuários de rapsódia fazem isso com mais frequência do que Rose. A parte difícil é manter o modelo e o código sincronizados; para a maioria dos projetos reais, o custo é alto demais.

No meu projeto mais recente, estou usando o UML-Lab (https://www.uml-lab.com). Essa é uma boa ferramenta que permite que o modelo também tenha engenharia reversa. A ferramenta gera código java e até anotações JPA que são bastante precisas.

O desafio é quando se trabalha em equipe. O modelo é estático e está em um único recurso, o que torna um pouco difícil mantê-lo sincronizado com várias alterações do desenvolvedor. Existe uma versão de avaliação disponível por 1 mês, que é um bom momento para explorar e comparar com outras pessoas, se você estiver investigando.

Esta é a primeira vez que vi um produto fazendo modelagem de objetos e modelagem de dados de uma só vez, juntamente com a geração de código.

Caso contrário, em meus projetos anteriores, sempre vi modelos obsoletos imprecisos ou muito detalhados.

Em meus projetos anteriores, às vezes eu gerava diagramas por engenharia reversa. Na maioria das vezes, descobri que os diagramas estão desordenados e preferi desenhá-los filtrando manualmente todo o ruído.

Eu acho que podemos usar UML para gerar código. Não é lógica de negócios, pois a lógica de negócios não é um padrão e varia de aplicativo para aplicativo. Os diagramas de classes, juntamente com os diagramas de ER, podem ser usados ​​para gerar interfaces, classes, entidades de hibernação, métodos básicos de DAO, etc. .

Além disso, conforme mencionado nos comentários anteriores, o esquema do banco de dados, scripts DDL etc. podem ser gerados usando modelos.

Usando o OAW e uma ferramenta de modelagem como o Enterprise Architect, podemos escrever geradores de código mais fortes, que podem até ajudar na geração de arquivos de configuração, código de fábrica usando estereótipos e valores marcados.

Ainda não entendo por que a inteligência comercial com ferramentas como o Business Object é capaz de analisar e tirar proveito de todas as informações da empresa, enquanto no nível tecnológico ainda estamos trabalhando apenas no nível do código ou no nível abstrato com a UML !!

O problema não é UML, mas a transformação de modelo entre UML e MOF e geração de código a partir de um diagrama clas ou xmi usando modelos. Diz-se que a UML fornece uma visão abstrata do mundo real, portanto, você só vê o que é realmente importante. Dito isto, como gerar um código preciso se o diagrama UML é apenas uma visão do mundo real? É impossível e, portanto, o desenvolvimento orientado a modelos que geraria código a partir de um modelo falhou.

A solução é transformar para mapear o mundo real e, portanto, todo o código do projeto em um único modelo UML. Tendo um único modelo e a lógica completa do projeto, você pode gerar visualizações do modelo e não do código a cada vez. Existe uma iniciativa corajosa feita por Omondo dentro da tecnologia Java / Jee. O conceito é MOF e UML sincronizados ao vivo diretamente com o código e o ORM. O diagrama UML agora é apenas uma visualização de alto nível do modelo que está mapeando todo o projeto. Você pode criar centenas de visualizações, adicionar centenas de notas, etc ... para entender melhor o projeto. O código será gerado apenas se o elemento for alterado ou criado. Tecnologia maravilhosa em que o ID Java é mapeado para o ID UML sem a ponte de transformação tradicional entre MOF e UML.

O que é fantástico também é poder modelar meu domínio no nível UML e obter minhas anotações ORM diretamente no código e, portanto, usando o Hibernate, posso criar, apagar, criar meu banco de dados, implantar etc ... em uma integração contínua permanente na qual A UML é parte de toda a arquitetura e não da arquitetura do projeto.

Nunca fiquei desapontado com a UML como visualizador de alto nível se a sincronização ao vivo com o código, mas foi absolutamente devastada pelo tradicional uso do MDA com a geração de código de modelos de desenvolvimento orientados a modelos. A geração de código a partir de um modelo é como uma página HTML vinda de um documento do word. Como alterá-lo uma vez gerado? É impossível atualizar e você gasta mais tempo limpando o código do que escrevendo do zero!