A UML é prática?[fechado]

https://stackoverflow.com/questions/18803

09-06-2019
|

Pergunta

Na faculdade, tive vários projetos e UML cursos orientados, e reconheço que a UML pode ser usada para beneficiar um projeto de software, especialmente caso de uso mapeamento, mas é realmente prático?Fiz alguns períodos de trabalho cooperativo e parece que a UML não é muito usada na indústria.Vale a pena dedicar tempo durante um projeto para criar diagramas UML?Além disso, acho que os diagramas de classes geralmente não são úteis, porque é mais rápido examinar o arquivo de cabeçalho de uma classe.Especificamente, quais diagramas são mais úteis?

Editar: Minha experiência é limitada a projetos pequenos, com menos de 10 desenvolvedores.

Editar: Muitas respostas boas e, embora não sejam as mais detalhadas, acredito que a selecionada é a mais equilibrada.

Solução

Em um sistema suficientemente complexo, existem alguns locais onde alguma UML é considerada útil.

Os diagramas úteis para um sistema variam de acordo com a aplicabilidade.Mas os mais utilizados são Diagramas de Estado, Diagramas de Atividades e Diagrama de Sequência.

Existem muitas empresas que os defendem e muitas que os rejeitam abertamente, considerando-os uma total perda de tempo e esforço.

É melhor não exagerar e pensar no que é melhor para o projeto em que você está e escolher o que é aplicável e faz sentido.

Outras dicas

Usar UML é como olhar para seus pés enquanto você anda.É tornar consciente e explícito algo que normalmente você pode fazer inconscientemente.Os iniciantes precisam pensar cuidadosamente sobre o que estão fazendo, mas um programador profissional já sabe o que está fazendo.Na maioria das vezes, escrever o código em si é mais rápido e eficaz do que escrever sobre o código, porque sua intuição de programação está sintonizada com a tarefa.

Não se trata apenas do que você está fazendo.E o novo contratado que chegará daqui a seis meses e precisa se atualizar sobre o código?E daqui a cinco anos, quando todos que estão trabalhando no projeto tiverem ido embora?

É extremamente útil ter alguma documentação básica atualizada disponível para qualquer pessoa que ingressar no projeto posteriormente.Não defendo diagramas UML completos com nomes de métodos e parâmetros (muito difíceis de manter), mas acho que um diagrama básico dos componentes do sistema com seus relacionamentos e comportamento básico é inestimável.A menos que o design do sistema mude drasticamente, essas informações não deverão mudar muito, mesmo que a implementação seja ajustada.

Descobri que a chave para a documentação é a moderação.Ninguém vai ler 50 páginas de diagramas UML completos com documentação de projeto sem adormecer algumas páginas depois.Por outro lado, a maioria das pessoas adoraria obter de 5 a 10 páginas de diagramas de classes simples com algumas descrições básicas de como o sistema é montado.

O outro caso em que descobri que a UML é útil é quando um desenvolvedor sênior é responsável por projetar um componente, mas depois entrega o design para um desenvolvedor júnior implementar.

Usar UML é como olhar para seus pés enquanto você anda.É tornar consciente e explícito algo que normalmente você pode fazer inconscientemente.Os iniciantes precisam pensar cuidadosamente sobre o que estão fazendo, mas um programador profissional já sabe o que está fazendo.Na maioria das vezes, escrever o código em si é mais rápido e eficaz do que escrever sobre o código, porque sua intuição de programação está sintonizada com a tarefa.

A exceção é porque você se encontra na floresta à noite sem tocha e começou a chover - então você precisa olhar para os pés para evitar cair.Há momentos em que a tarefa que você assumiu é mais complicada do que sua intuição pode suportar, e você precisa desacelerar e declarar explicitamente a estrutura do seu programa.Então a UML é uma das muitas ferramentas que você pode usar.Outros incluem pseudocódigo, diagramas de arquitetura de alto nível e metáforas estranhas.

Fluxos de trabalho genéricos e DFDs podem ser muito úteis para processos complexos.Todas as outras diagramações (ESPECIALMENTE UML) têm sido, na minha experiência, sem exceção, uma dolorosa perda de tempo e esforço.

Eu tenho que discordar, a UML é usada em todos os lugares - em qualquer lugar em que um projeto de TI esteja sendo projetado, a UML geralmente estará lá.

Agora, se está sendo usado bem é outro assunto.

Como Stu disse, considero os casos de uso (junto com as descrições dos casos de uso) e os diagramas de atividades os mais úteis do ponto de vista do desenvolvedor.

O diagrama de classes pode ser muito útil ao tentar mostrar relacionamentos, bem como atributos de objetos, como persistência.Quando se trata de adicionar um único atributo ou propriedade, eles geralmente são um exagero, especialmente porque muitas vezes ficam desatualizados rapidamente depois que o código é escrito.

Um dos maiores problemas da UML é a quantidade de trabalho necessária para mantê-la atualizada depois que o código é gerado, pois há poucas ferramentas que podem reprojetar a UML a partir do código, e poucas ainda fazem isso bem.

Qualificarei minha resposta mencionando que não tenho experiência em grandes ambientes de desenvolvimento corporativo (semelhantes à IBM).

A maneira como vejo a UML e o Processo Racional Unificado é que é mais CONVERSANDO sobre o que você vai fazer do que realmente FAZENDO o que você vai fazer.

(Em outras palavras, é em grande parte uma perda de tempo)

Jogue fora apenas na minha opinião.A UML é uma ótima ferramenta para comunicar ideias, o único problema é quando você a armazena e mantém, porque você está essencialmente criando duas cópias da mesma informação e é aí que ela geralmente falha.Após a rodada inicial de implementação, a maior parte da UML deverá ser gerada a partir do código-fonte, caso contrário ela ficará desatualizada muito rapidamente ou exigirá muito tempo (com erros manuais) para se manter atualizada.

Fui co-ministrador de um curso de projeto de desenvolvimento de nível sênior nos dois últimos semestres da escola.O projeto foi planejado para ser usado em um ambiente de produção com organizações sem fins lucrativos locais como clientes pagantes.Tínhamos que ter certeza de que o código fazia o que esperávamos e que os alunos estavam capturando todos os dados necessários para atender às necessidades dos clientes.

O tempo de aula era limitado, assim como meu tempo fora da sala de aula.Como tal, tínhamos que realizar revisões de código em todas as reuniões de turma, mas com 25 alunos inscritos o tempo de revisão individual era muito curto.As ferramentas que consideramos mais valiosas nessas sessões de revisão foram ERD, diagramas de classes e diagramas de sequência.Os ERDs e os diagramas de classes foram feitos apenas no Visual Studio, portanto o tempo necessário para criá-los foi trivial para os alunos.

Os diagramas comunicaram muitas informações muito rapidamente.Ao ter uma rápida visão geral dos projetos dos alunos, poderíamos isolar rapidamente áreas problemáticas em seus códigos e realizar uma revisão mais detalhada no local.

Sem o uso de diagramas, teríamos que gastar um tempo examinando, um por um, os arquivos de código dos alunos em busca de problemas.

Estou chegando a este tópico um pouco tarde e tentarei apenas esclarecer alguns pontos menores.Perguntar se a UML é útil é muito ampla.A maioria das pessoas pareceu responder à pergunta da perspectiva típica/popular da UML como uma ferramenta de desenho/comunicação.Observação:Martin Fowler e outros autores de livros sobre UML acham que a UML é melhor usada apenas para comunicação.No entanto, existem muitos outros usos para UML.Acima de tudo, UML é uma linguagem de modelagem que possui notações e diagramas mapeados para os conceitos lógicos.Aqui estão alguns usos da UML:

Comunicação
Documentação padronizada de projeto/solução
Definição de DSL (linguagem específica de domínio)
Definição de modelo (perfis UML)
Uso de padrão/recurso
Geração de código
Transformações de modelo para modelo

Dada a lista de usos acima, a postagem de Pascal não é suficiente, pois se refere apenas à criação de diagramas.Um projeto poderia se beneficiar da UML se algum dos itens acima for um fator crítico de sucesso ou se for uma área problemática que precise de uma solução padronizada.

A discussão deve se expandir de como a UML pode ser superada ou aplicada a pequenos projetos para discutir quando a UML faz sentido ou realmente melhorará o produto/solução, pois é quando a UML deve ser usada.Há situações em que a UML para um desenvolvedor também pode ser percebida, como Aplicação de Padrão ou Geração de Código.

A UML tem funcionado para mim há anos.Quando comecei, li o livro de Fowler UML destilado onde ele diz "faça modelagem/arquitetura/etc suficiente".Basta usar o que você precisar!

Da perspectiva de um engenheiro de controle de qualidade, os diagramas UML apontam possíveis falhas na lógica e no pensamento.Facilita meu trabalho :)

Acho que a UML é útil, mas acho que a especificação 2.0 tornou o que antes era uma especificação clara um tanto inchada e complicada.Concordo com a edição de diagramas de tempo, etc., uma vez que preencheram uma lacuna...

Aprender a usar a UML de forma eficaz requer um pouco de prática.O ponto mais importante é comunicar com clareza, modelar quando necessário e modelar em equipe.Quadros brancos são a melhor ferramenta que encontrei.Não vi nenhum "software de quadro branco digital" que conseguisse capturar a utilidade de um quadro branco real.

Dito isto, gosto das seguintes ferramentas UML:

Violeta - Se fosse mais simples seria um pedaço de papel
Altova UModel - Boa ferramenta para modelagem Java e C#
MagicDraw – Minha ferramenta comercial favorita para modelagem
Poseidon – Ferramenta decente com bom custo-benefício
StarUML – Melhor ferramenta de modelagem de código aberto

Os diagramas UML são úteis para capturar e comunicar requisitos e garantir que o sistema atenda a esses requisitos.Eles podem ser usados iterativamente e durante vários estágios de planejamento, design, desenvolvimento e teste.

Do tópico: Usando modelos no processo de desenvolvimento no http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Um modelo pode ajudá -lo a visualizar o mundo em que seu sistema funciona, esclarecer as necessidades dos usuários, definir a arquitetura do seu sistema, analisar o código e garantir que seu código atenda aos requisitos.

Você também pode querer ler minha resposta à seguinte postagem:

Como aprender “bom design/arquitetura de software”? no https://stackoverflow.com/questions/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Embora esta discussão esteja inativa há muito tempo, tenho alguns pontos - que considero importantes - a acrescentar.

Código com erros é uma coisa.Deixados à deriva, erros de projeto podem muito realmente inchado e feio.A UML, entretanto, é autovalidada.Com isso quero dizer que, ao permitir que você explore seus modelos em dimensões múltiplas, matematicamente fechadas e que se verificam mutuamente, isso gera um design robusto.

A UML tem outro aspecto importante:ela “conversa” diretamente com a nossa capacidade mais forte, a da visualização.Se, por exemplo, o ITIL V3 (no fundo, bastante simples) tivesse sido comunicado na forma de diagramas UML, ele poderia ter sido publicado em algumas dezenas de desdobráveis A3.Em vez disso, saiu em vários volumes de proporções verdadeiramente bíblicas, gerando toda uma indústria, custos exorbitantes e um choque catatónico generalizado.

Vejo diagramas de sequência e diagramas de atividades usados com bastante frequência.Eu trabalho muito com sistemas embarcados e de "tempo real" que interagem com outros sistemas, e os diagramas de sequência são muito úteis para visualizar todas as interações.

Gosto de fazer diagramas de casos de uso, mas não conheci muitas pessoas que os considerem valiosos.

Muitas vezes me perguntei se o Rational Rose é um bom exemplo dos tipos de aplicativos que você obtém com o design baseado em modelo UML.É inchado, cheio de erros, lento, feio, ...

Achei a UML não muito útil para projetos muito pequenos, mas realmente adequada para projetos maiores.

Essencialmente, não importa realmente o que você usa, basta manter duas coisas em mente:

Você quer algum tipo de planejamento de arquitetura
Você quer ter certeza de que todos na equipe estão realmente usando a mesma tecnologia para o planejamento do projeto

Então UML é apenas isso:Um padrão sobre como você planeja seus projetos.Se você contratar novas pessoas, é mais provável que conheçam qualquer padrão existente - seja UML, Flowchard, Nassi-Schneiderman, qualquer que seja - em vez de seu material interno existente.

Usar UML para um único desenvolvedor e/ou um projeto de software simples parece um exagero para mim, mas ao trabalhar em uma equipe maior, eu definitivamente gostaria de algum padrão para planejamento de software.

UML é útil, sim!Os principais usos que fiz dele foram:

Brainstorming sobre como um software deve funcionar.Torna mais fácil comunicar o que você está pensando.
Documentar a arquitetura de um sistema, seus padrões e os principais relacionamentos de suas classes.Ajuda quando alguém entra na sua equipe, quando você está saindo e quer ter certeza de que seu sucessor vai entender, e quando você eventualmente esquece para que diabos aquela aula foi feita.
Documentar qualquer padrão de arquitetura que você usa em todos os seus sistemas, pelos mesmos motivos do ponto acima

Eu só discordo Michael quando ele diz isso usar UML para um único desenvolvedor e/ou um projeto de software simples parece um exagero para ele.Eu usei isso em meus pequenos projetos pessoais, e documentá-los usando UML me economizou muito tempo quando voltei a eles sete meses depois e esqueci completamente como havia construído e reunido todas aquelas classes.

Eu acredito que pode haver uma maneira de utilizar casos de uso de peixes UML, pipas e no nível do mar, como descrito por Fowler em seu livro "Uml destilado". Minha idéia era empregar casos de uso de Cockburn como ajuda para a legibilidade do código.

Então, fiz um experimento e há um post aqui sobre a tag "Uml" ou "Fowler". Foi uma ideia simples para C#.Encontre uma maneira de incorporar casos de uso de Cockburn nos namespaces de construções de programação (como os namespaces de classe e de classe interna ou fazendo uso dos namespaces para enumerações).Acredito que esta poderia ser uma técnica viável e simples, mas ainda tenho dúvidas e preciso que outras pessoas verifiquem.Poderia ser bom para programas simples que precisam de um tipo de linguagem específica de pseudo-domínio que pode existir bem no meio do código c# sem quaisquer extensões de linguagem.

Por favor, verifique a postagem se você estiver interessado.Ir aqui.

Um dos problemas que tenho com a UML é a compreensão da especificação.Quando tento realmente entender a semântica de um diagrama específico, rapidamente me perco no labirinto de metamodelos e metamodelos.Um dos pontos fortes da UML é que ela é menos ambígua que a linguagem natural.No entanto, se dois ou mais engenheiros interpretarem um diagrama de maneira diferente, ele falhará no objetivo.

Além disso, tentei fazer perguntas específicas sobre o documento de superestrutura em vários fóruns da UML e aos membros do próprio OMG, com pouco ou nenhum resultado.Não creio que a comunidade UML ainda esteja madura o suficiente para se sustentar.

Vindo de um estudante, acho que a UML tem muito pouca utilidade.Acho irônico que os PROGAMERS ainda não tenham desenvolvido um programa que gere automaticamente as coisas que você disse serem necessárias.Seria extremamente simples projetar um recurso no Visual Studio que pudesse extrair partes dos dados, buscar definições e respostas de produtos suficientes para que qualquer pessoa pudesse observá-lo, grande ou pequeno, e entender o programa.Isso também o manteria atualizado porque retiraria as informações diretamente do código para produzi-las.

A UML é usada assim que você representa uma classe com seus campos e métodos, embora seja apenas uma espécie de diagrama UML.

O problema com a UML é que o livro dos fundadores é muito vago.

UML é apenas uma linguagem, não é realmente um método.

Quanto a mim, realmente acho irritante a falta de esquema UML para projetos de código aberto.Pegue algo como o Wordpress, você só tem um esquema de banco de dados, nada mais.Você tem que passear pela API do Codex para tentar ter uma visão geral.

A UML tem seu lugar.Torna-se cada vez mais importante à medida que o tamanho do projeto aumenta.Se você tiver um projeto de longa duração, é melhor documentar tudo em UML.

A UML parece boa para grandes projetos com grandes equipes de pessoas.Porém já trabalhei em equipes pequenas onde a comunicação é melhor.

Usar diagramas no estilo UML é bom, especialmente no estágio de planejamento.Tenho tendência a pensar em código, por isso acho difícil escrever especificações grandes.Prefiro anotar as entradas e saídas e deixar que os desenvolvedores projetem a parte intermediária.

Em minha experiência:

A capacidade de criar e comunicar diagramas de código significativos é uma habilidade necessária para qualquer engenheiro de software que esteja desenvolvendo um novo código ou tentando compreender o código existente.

Conhecer as especificidades da UML - quando usar uma linha tracejada ou um ponto final de círculo - não é tão necessário, mas ainda é bom ter.

Acredito que a UML é útil apenas porque leva as pessoas a pensar sobre os relacionamentos entre suas classes.É um bom ponto de partida para começar a pensar em tais relacionamentos, mas definitivamente não é uma solução para todos.

Minha convicção é que o uso da UML é subjetivo à situação em que a equipe de desenvolvimento está trabalhando.

A UML é útil de duas maneiras:

Lado técnico:muitas pessoas (gerentes e alguns analistas funcionais) pensam que UML é um recurso de luxo porque O código é a documentação:você começa a codificar, depois de depurar e corrigir.A sincronização dos diagramas UML com o código e a análise obrigam a entender bem as solicitações do cliente;
Lado de gestão:os diagramas UMl são um espelho das necessidades do cliente que são imprecisas:se você codificar sem UML, talvez encontre um bug em require depois de muitas horas de trabalho.Os diagramas UML permitem encontrar os possíveis pontos controversos e resolvê-los antes da codificação =>ajudar no seu planejamento.

Geralmente todos os projetos sem diagramas UML possuem uma análise superficial ou são de tamanho reduzido.

se você estiver no grupo do LinkedIn ENGENHEIROS DE SISTEMAS, ver minha antiga discussão.

No final das contas, a UML só existe por causa do RUP.Precisamos de UML ou qualquer coisa relacionada para usar Java/.Net?A resposta prática é que eles têm documentação própria (javadoc etc.), que é suficiente e nos permite realizar nosso trabalho!

UML não, obrigado.

A UML é definitivamente útil, assim como o junit é essencial.Tudo depende de como você vende a ideia.Seu programa funcionará sem UML da mesma forma que funcionaria sem testes de unidade.Dito isto, você deve criar o UML conforme ele estiver conectado ao seu código, ou seja, quando você atualiza os diagramas UML, ele atualiza seu código, ou quando você atualiza seu código, ele gera automaticamente o UML.Não faça apenas por fazer.

A UML definitivamente tem seu lugar na indústria.Imagine que você está construindo software para aeronaves Boing ou algum outro sistema complexo.UML e RUP seriam de grande ajuda aqui.

UML é apenas um dos métodos de comunicação entre as pessoas.O quadro branco é melhor.

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow