UML é prático? [fechadas]

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

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

Edit: Muitas respostas boas, e embora não as mais prolixas, acredito que a selecionada é a mais equilibrada.

Em um sistema suficientemente complexo, existem alguns lugares onde alguns UMLsão considerados úteis.

Os diagramas úteis para um sistema variam de acordo com a aplicabilidade.
Mas os mais usados ​​são:

• Diagramas de Classe
• Diagramas de Estado
• Diagramas de Atividades
• Diagramas de Seqüência

Existem muitas empresas que juram por eles e muitos que os rejeitam abertamente como 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.

Usar UML é como olhar para os pés enquanto caminha. É tornar consciente e explícito algo que você geralmente pode fazer inconscientemente. Os iniciantes precisam pensar cuidadosamente sobre o que estão fazendo, mas um programador profissional já sabe o que estão 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á em seis meses a partir de agora e precisará se familiarizar com o código? Que tal daqui a cinco anos, quando todos os que estão trabalhando no projeto já tiverem partido?

É extremamente útil ter alguma documentação básica atualizada disponível para qualquer pessoa que se junte ao projeto posteriormente. Eu não defendo diagramas UML completos com nomes de métodos e parâmetros (muito difícil 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 devem 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 design sem adormecer algumas páginas. Por outro lado, a maioria das pessoas adoraria obter 5-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 passa o projeto para um desenvolvedor júnior implementar.

Usar UML é como olhar para os pés enquanto caminha. É tornar consciente e explícito algo que você geralmente pode fazer inconscientemente. Os iniciantes precisam pensar cuidadosamente sobre o que estão fazendo, mas um programador profissional já sabe o que estão 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 uma tocha e começou a chover - então você precisa olhar para seus 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 definir explicitamente a estrutura de seu programa. Então UML é uma das muitas ferramentas que você pode usar. Outros incluem pseudocódigo, diagramas de arquitetura de alto nível e metáforas estranhas.

Fluxo de trabalho genérico e DFDs podem ser muito úteis para processos complexos. Todos os outros diagramas (ESPECIALMENTE UML) foram, em minha experiência, sem exceção, uma perda dolorosa de tempo e esforço.

Eu teria que discordar, a UML é usada em todo lugar - em qualquer lugar que um projeto de TI esteja sendo desenvolvido, a UML geralmente estará lá.

Agora, se está sendo bem usado, é outra questão.

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 objeto, como persistência. Quando se trata de adicionar um único atributo ou propriedade, eles geralmente são exagerados, especialmente porque costumam ficar desatualizados rapidamente depois que o código é escrito.

Um dos maiores problemas com a UML é a quantidade de trabalho necessária para mantê-la atualizada depois que o código está sendo gerado, já que existem poucas ferramentas que podem fazer a reengenharia da UML a partir do código e poucas ainda o fazem 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 Rational Unified Process é que ela está mais FALANDO sobre o que você vai fazer do que realmente FAZENDO o que vai fazer.

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

Jogue fora apenas na minha opinião. UML é uma ótima ferramenta para comunicar ideias, o único problema é quando você armazena e mantém, porque você está essencialmente criando duas cópias da mesma informação e é aqui que normalmente acontece. Após a rodada inicial de implementação, a maior parte da UML deve 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.

Eu co-ministrei um curso de projeto de desenvolvimento de nível sênior nos meus dois últimos semestres na 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 das aulas era limitado, assim como o meu tempo fora da sala de aula. Como tal, tivemos que realizar revisões de código em todas as reuniões de classe, mas com 25 alunos matriculados, o tempo de revisão individual era muito curto. A ferramenta que consideramos mais valiosa nessas sessões de revisão foram os ERDs, diagramas de classe e diagramas de sequência. ERD's e diagramas de classe eram feitos apenas no Visual Studio, então o tempo necessário para criá-los era trivial para os alunos.

Os diagramas comunicaram muitas informações muito rapidamente. Tendo uma visão geral rápida dos designs dos alunos, podemos isolar rapidamente as áreas problemáticas em seus códigos e realizar uma revisão mais detalhada no local.

Sem usar diagramas, teríamos que reservar um tempo para percorrer um a 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 UML é útil por ser muito ampla. A maioria das pessoas parecia responder à pergunta da perspectiva da UML típica / popular como ferramenta de desenho / comunicação. Nota: Martin Fowler e outros autores de livros UML acreditam 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ção e diagramas mapeados para os conceitos lógicos. Aqui estão alguns usos para UML:

• Comunicação
• Documentação padronizada de projeto / solução
• Definição de DSL (Domain Specific Language)
• Definição de modelo (perfis UML)
• Uso de padrão / ativo
• 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 só fala sobre a criação de diagramas. Um projeto pode se beneficiar da UML se qualquer um dos itens acima for um fator crítico de sucesso ou áreas problemáticas que precisam de uma solução padronizada.

A discussão deve se expandir a partir de como a UML pode ser exagerada 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. Existem situações em que a UML para um desenvolvedor também pode ser sentida, como o aplicativo de padrão ou a geração de código.

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

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 inchado e complicado. Eu concordo com a edição dos diagramas de tempo etc, pois eles preencheram uma lacuna ...

Aprender a usar a UML de maneira eficaz requer um pouco de prática. O ponto mais importante é comunicar-se com clareza, modelar quando necessário e modelar como uma equipe. Os quadros brancos são a melhor ferramenta que encontrei. Eu não vi nenhum "software de quadro branco digital" que conseguiu capturar a utilidade de um quadro branco real.

Dito isso, gosto das seguintes ferramentas UML:

1. Violeta - Se fosse mais simples, seria um pedaço de papel

2. Altova UModel - Boa ferramenta para modelagem Java e C #

3. MagicDraw - Minha ferramenta comercial favorita para modelagem

4. Poseidon - ferramenta decente com boa relação custo-benefício

5. 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 em 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 de 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”? em /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

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

Código com erros é uma coisa. Da esquerda para a direita, os erros de design podem ficar muito inchados e feios de fato. UML, no entanto, é autovalidante. Com isso quero dizer que, ao permitir que você explore seus modelos em dimensões múltiplas matematicamente fechadas e mutuamente verificáveis, isso gera um design robusto.

A UML tem outro aspecto importante: ela "fala" diretamente com nossa capacidade mais forte, a de visualização. Se, por exemplo, o ITIL V3 (no fundo, simples o suficiente) 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 tomos de proporções verdadeiramente bíblicas, gerando uma indústria inteira, custos estonteantes e choque catatônico generalizado.

Vejo diagramas de sequência e diagramas de atividades usados ​​com bastante frequência. Eu trabalho muito com sistemas "em tempo real" e embarcados que interagem com outros sistemas, e os diagramas de sequência são muito úteis na visualização de 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 do design baseado em modelo UML. É inchado, cheio de erros, lento, feio, ...

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

Essencialmente, não importa o que você usa, você só precisa 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

Portanto, UML é apenas isso: um padrão de 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 suas coisas internas existentes.

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

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

• Brainstorming sobre como um software deve funcionar. Facilita a comunicação do que você está pensando.
• Documentando a arquitetura de um sistema, seus padrões e os principais relacionamentos de suas classes. Ajuda quando alguém entra em sua equipe, quando você está saindo e quer ter certeza de que seu sucessor vai entender, e quando você finalmente esquece para que diabos aquela pequena aula foi feita.
• Documentar qualquer padrão arquitetônico que você usa em todos os seus sistemas, pelas mesmas razões do ponto acima

Só discordo de Michael quando ele diz que usar UML para um único desenvolvedor e / ou um projeto de software simples parece exagero para ele. Eu o usei em meus pequenos projetos pessoais e tê-los documentados usando UML economizou muito tempo quando voltei a eles sete meses depois e tinha esquecido completamente como havia construído e montado todas essas classes.

Acredito que possa haver uma maneira de utilizar os casos de uso UML de peixes, pipas e nível do mar no estilo Cockburn, conforme descrito por Fowler em seu livro "UML Distilled". Minha ideia era empregar casos de uso Cockburn como um auxílio para a legibilidade do código.

Então fiz um experimento e tem um post aqui sobre isso com a Tag "UML" ou "FOWLER". Era uma ideia simples para c #. Encontre uma maneira de incorporar os casos de uso de Cockburn aos namespaces de construções de programação (como a classe e os namespaces da classe interna ou usando os namespaces para enumerações). Acredito que esta seja uma técnica viável e simples, mas ainda tenho dúvidas e preciso que outras pessoas a verifiquem. Pode 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. Vá 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 de venda da UML é que ela é menos ambígua do que a linguagem natural. No entanto, se dois ou mais engenheiros interpretam um diagrama de maneira diferente, ele falha no objetivo.

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

Vindo de um estudante, acho que a UML tem muito pouco uso. Acho irônico que os PROGAMERS ainda não tenham desenvolvido um programa que gerará automaticamente as coisas que você disse serem necessárias. Seria extremamente simples projetar um recurso no Visual Studio que pudesse extrair pedaços dos dados, buscar definições e respostas de produto suficientes para que qualquer pessoa pudesse olhar para ele, grande ou pequeno, e entender o programa. Isso também o manteria atualizado porque levaria as informações diretamente do código para produzir as informações.

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 do fundador é 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ê precisa vagar pela Api do Codex para tentar obter o quadro geral.

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

UML parece bom para grandes projetos com grandes equipes de pessoas. No entanto, trabalhei em equipes pequenas onde a comunicação é melhor.

Usar diagramas UML-esque é bom, entretanto, especialmente no estágio de planejamento. Eu tendo a pensar em código, então acho difícil escrever grandes especificações. Eu prefiro anotar as entradas e saídas e deixar que os desenvolvedores projetem a parte intermediária.

Acredito que a UML seja útil apenas pelo fato de fazer as pessoas pensarem sobre os relacionamentos entre suas classes. É um bom ponto de partida para começar a pensar sobre esses relacionamentos, mas definitivamente não é uma solução para todos.

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

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 entender o código existente.

Saber as especificações da UML - quando usar uma linha tracejada ou um ponto final circular - não é tão necessário, mas ainda é bom ter.

UML é útil de duas maneiras:

• Lado técnico: muitas pessoas (gerente e algum analista funcional) 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 obriga a entender bem as solicitações do cliente;

• Lado de gerenciamento: os diagramas UMl são um espelho das necessidades do cliente que são imprecisas: se você codificar sem UML, talvez você possa encontrar um bug em requisições após muitas horas de trabalho. Os diagramas UML permitem que você encontre os possíveis pontos polêmicos e resolva antes que a codificação => ajude seu planejamento.

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

se você está no grupo do LinkedIn SYSTEMS ENGINEERS , veja minha discussão anterior .

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

UML não, obrigado.

UML é definitivamente útil, assim como 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 isso, você deve criar do UML conforme ele está conectado ao seu código, ou seja, quando você atualiza os diagramas UML, ele atualiza o seu código, ou quando você atualiza o seu código, ele gera automaticamente a UML. Não faça apenas por fazer.

A UML definitivamente tem seu lugar na indústria. Imagine que você está construindo um 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 dentro das pessoas. O quadro branco é melhor.