O código é normalmente gerado a partir da UML? [fechadas]


39

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?


6
@SK - Todos sabemos que SEU código é fantástico e está escrito de uma maneira tão clara que até uma criança de 5 anos pode entender todo o projeto lendo apenas alguns de seus métodos. No entanto, para o resto de nós que não tem sua capacidade sobrenatural de escrever códigos claros, os diagramas são de grande benefício para descrever como o sistema funciona de maneira sucinta e os diagramas UML são uma maneira padrão de desenhar esses diagramas. Não estou afirmando que eles são o melhor caminho, apenas um caminho padrão que funciona na maior parte do tempo.
Dunk

2
@ Dunk, provavelmente você perdeu o momento em que o resto de nós inventou um discurso em vez de uma pintura de caverna. Os diagramas quase sempre são apenas uma maneira de obscurecer o que eles devem representar. Um texto simples é sempre melhor. E quanto maior o seu sistema, mais complexo é o seu comportamento, maior é essa lacuna entre o estilo de comunicação da era dos homens das cavernas e o inglês moderno. Nunca vi um diagrama que pudesse entender sem traduzi-lo manualmente em um texto primeiro.
SK-logic

9
@ SK-logic - Eu pensei que uma imagem pintou mais que mil palavras?
Michael Arnell

5
@ SK-logic: Existem algumas coisas que são melhor comunicadas através de texto. E, acredite ou não, outros são melhor comunicados através de diagramas, e isso inclui o design do sistema, e não apenas o OO. E pode até ser diferente para pessoas diferentes e não, sua preferência por informações textuais não é uma marca de superioridade dada por Deus.
Michael Borgwardt

3
@ SK - enquanto sua opinião tem alguns pontos válidos, como um diagrama sozinho quase nunca é suficiente e é preciso adicionar algum texto. Continuarei a usar o que você acredita serem diagramas inúteis, enquanto continuo construindo com sucesso sistemas bastante grandes, com prazos quase impossíveis em equipes consideráveis, porque ainda não vi uma maneira melhor de me comunicar com outros desenvolvedores. Sei que você tem tempo de sobra para se sentar e guiar individualmente todos os desenvolvedores, mas estou muito ocupado fazendo o trabalho.
Dunk

Respostas:


64

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.


5
Exatamente. Mas, então, surge a pergunta: por que a UML com todas as suas regras estritamente inúteis e, consequentemente, suas ferramentas inchadas para criar UML, em primeiro lugar? Polígonos e elipses simples, conectados por linhas e setas, fazem um trabalho tão bom, se não melhor, em transmitir intenções quanto a UML.
Dexter

1
+1 por hype dos anos 90, o design de hardware estava se movendo na direção oposta ao mesmo tempo, longe da captura esquemática e em direção aos HDLs.
jk.

2
De 1996 a 2002, eu trabalhava para uma empresa em que usamos diagramas UML com sucesso como modelos "melhores" de ER. Tivemos nossos próprios geradores de código para gerar código C ++ para nossa estrutura ORM, SQL / DDL e documentação, tudo a partir de um único modelo.
Doc Brown

2
Um ótimo uso do diagrama UML também é o andaime. Gere classes, com getters / setters, talvez sua árvore de diretórios etc.
Clement Herreman

5
@ Dexter: o problema é que "polígonos e elipses simples, conectados por linhas e setas" deixam muito em aberto para interpretação. Pode ser que a UML se esforce demais para ter um símbolo especial para tudo, mas certamente vale a pena ter uma notação padronizada que permita distinguir visualmente entre classes e sistemas de hardware e entre um relacionamento de herança e um canal de comunicação.
Michael Borgwardt

36

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.


2
+1, obrigado por abordar a questão sobre a complexidade de problemas com palavras reais. Ótimo ponto.
NoChance

e o G, a linguagem de programação gráfica usada no LabVIEW?
Angelo.Hannes

1
@ Angelo.Hannes: Resolvendo problemas do mundo real em abordagens invariáveis ​​do Labview, parecidas com esta: img.thedailywtf.com/images/201104/labview.jpg
whatsisname

@whatsisname este diagrama está muito confuso. Mas vi diagramas estruturados e "legíveis" muito bons no LabVIEW resolvendo problemas do mundo real.
precisa saber é o seguinte

@ Angelo.Hannes: Eu usei sistemas semelhantes ao LabVIEW. Eles são bons para criar aplicativos pequenos em um domínio limitado.
kevin Cline

9

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.


4
Eu realmente senti a necessidade de uma resposta com um grande NÃO em algum lugar.
ZJR

6

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.


@mouviciel: Eu não acho que exista uma ferramenta que não tenha esses problemas. O Rhapsody realmente tenta atenuar os piores problemas usando o código gerado, que é o texto, como autorizado para os membros.
Jan Hudec

3

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.


1

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.


3
Quero destacar duas coisas: 1. Você gosta de listas ordenadas.
Talnicolas

@talnicolas, você está correto! Eu faço :)
NoChance

0

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.


0

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.


-1

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.


-4

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.


-5

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!


1
Isso não é uma resposta, cara, apenas uma queixa. Eu concordo um pouco sobre por que os codificadores ainda estão escrevendo cada código de linha, enquanto é FÁCIL criar pequenos construtores de código com arrastar e soltar. Você está totalmente certo quanto ao fato de o Bussiness ter implementado melhor a tecnologia do que os usuários que a utilizam. Você pode criar uma máquina pré-configurada inteira com seu aplicativo em segundos, mas você não pode criar software com poucos (milhares) cliques ou pressionamentos de tecla. Extra. Eu tenho que Día e Pythonnect podem fazer um bom trabalho executando código diretamente da sua UML, mas ainda não testaram.
M3nda 01/07/19
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.