Qual a importância dos diagramas UML para um projeto bem-sucedido? [fechadas]

Estou no meio de um projeto e me pediram para escrever diagramas UML (casos de uso, diagrama de classes etc.). O projeto não é muito complexo.

Fiquei me perguntando se isso seria uma perda de tempo. Devo apenas fazer outras coisas divertidas, como escrever código? E quando não está certo construir algo sem passar por toda a fase conceitual? É tudo uma questão de complexidade? E se sim, como medir?

Eu era um grande fã da UML há um tempo atrás. Tenho até a certificação OMG. Usei-o extensivamente em grandes projetos empresariais nos quais participei.

Hoje, parei a UML quase completamente. Às vezes, eu uso o diagrama de seqüência que considero muito útil para descrever interações entre sistemas, mas nenhum outro diagrama.

Agora, prefiro trabalhar com histórias de usuários, suportadas pela (apenas) documentação necessária escrita pelo proprietário (ou analistas) do produto E por sua (sua) dedicação à equipe de desenvolvimento para fornecer mais detalhes conforme necessário.

A UML é uma ferramenta que você pode usar, mas certamente não é um fator crítico para o sucesso de seus projetos. Depois de muitos anos, agora acho que o fator crítico é a equipe de desenvolvimento, independentemente de quais ferramentas ela usa.

O planejamento é crítico, mas como o famoso estrategista Carl von Clausewitz adverte

Nenhum plano de campanha sobrevive ao primeiro contato com o inimigo

Portanto, não é um desperdício de tempo enorme planejar como atacar inicialmente os problemas. Mas provavelmente é um desperdício de tempo para documentar seu código para futuros programadores. Para usar uma metáfora militar, você precisa de um plano de batalha, mas não daria esse plano aos historiadores para usá-los como um relatório pós-ação.

Mais concretamente, você pode usar esses diagramas para comunicar suas intenções à sua equipe e pensar em seu plano de ataque antes e durante o projeto. Mas as probabilidades são de que o que você criar precisará ser ajustado conforme você codifica e aprende mais sobre o problema. Quase sempre o seu plano / design inicial precisa ser alterado, porque você não pode saber tudo de antemão.

Acho que os diagramas UML só podem ser úteis se eles expressarem algo em um nível mais alto de abstração do que o seu código .

Escrever UML apenas por uma questão de escrever UML torna-se uma burocracia desnecessária e torna o projeto e o código menos adaptáveis ​​a mudanças sem qualquer benefício.

Por exemplo, um diagrama de classes UML mostrando todas as classes em um pacote, com todos os seus atributos e métodos - algo que pode ser facilmente gerado automaticamente - não fornece nenhum valor: está no mesmo nível de abstração que o seu código . Além disso, o código certamente será uma fonte melhor para essas informações, pois sempre estará atualizado e provavelmente será documentado e organizado de uma maneira que seja mais fácil saber quais métodos / atributos / coisas são mais importantes.

Por outro lado, se você tiver conceitos de um nível de abstração mais alto do que o que pode ser expresso expresso no código, documentá-los em um diagrama pode ser uma boa idéia.

Por exemplo, um diagrama mostrando os módulos abstratos de nível superior em um sistema complexo, com suas dependências e talvez uma pequena descrição de suas responsabilidades e para qual pacote / namespace eles mapeiam no código-fonte pode ser realmente útil para um novo membro da equipe que precisa ser introduzido no projeto ou também pode ser usado para descobrir onde uma nova classe / funcionalidade deve ser lançada.

Outro exemplo de um diagrama útil pode ser um diagrama de seqüência que mostra as etapas de alto nível a serem tomadas em um protocolo de comunicação. Talvez cada etapa tenha pequenas peculiaridades e complexidades, mas provavelmente é suficiente descrevê-las no próprio código. O diagrama de nível superior pode ajudar um programador a entender facilmente o "quadro geral" das coisas, sem precisar se preocupar com as complexidades de cada interação.

Enfim, esses são apenas alguns exemplos; Existem muitos casos em que um diagrama simples pode ajudar bastante. Lembre-se de que você deve fazê-las somente quando não puder expressar algo no próprio código. Se você estiver usando diagramas UML para explicar o próprio código-fonte, torne o código de classificação mais auto-documentado.

Finalmente, algumas das regras gerais que se aplicam ao código também podem se aplicar aos diagramas: evite repetir-se, mantenha-o simples, não tenha medo de mudar as coisas (apenas porque algo está documentado em um diagrama UML não significa que não possa seja alterado) e sempre pense em quem lerá / manterá esses diagramas no futuro (provavelmente seu futuro) ao escrevê-los :)

A UML tem valor se os membros da equipe a entenderem coletivamente e a considerarem uma maneira útil de resumir e comunicar as decisões de design. Você não precisa saber tudo, apenas o subconjunto que a equipe considera útil.

Além disso, você não precisa desenhar diagramas polidos perfeitos. Um diagrama de seqüência mais ou menos esboçado em um quadro branco ou um diagrama de classe em que as classes são post-its coladas no quadro branco pode ser suficiente, dependendo do contexto.

Certa vez, trabalhei em um show em que precisava gerenciar uma equipe de desenvolvedores de contratos no exterior.

Algumas das coisas que eles estavam produzindo eram bastante horrendas (um sintoma comum dos codificadores remotos por contrato - eles realmente não se importam muito com o seu código, apenas querem ser executados rapidamente).

Para gerenciar o projeto, eu me vi produzindo diagramas UML e entregando-os para codificar. Foi muito bem-sucedido - não demorei muito tempo para escrever um programa em UML, muito mais rápido que em Java, e era algo que os empreiteiros podiam seguir e medir.

Uma ressalva - às vezes eles queriam se tornar criativos e se desviar dos meus modelos; no entanto, nesses casos, eles estavam realmente corretos e, em geral, a UML melhorou a qualidade do produto final.

Se alguém lhe pediu para preparar diagramas UML e que alguém está pagando seu salário, não é realmente uma perda de tempo. Pode ou não ser um desperdício do tempo dessa pessoa.

Se alguém planeja entender seu projeto lendo seus diagramas UML, provavelmente não é uma perda de tempo.

Acho útil no estágio inicial do projeto obter idéias no papel ou no quadro branco. Eu usei principalmente diagramas de classes UML, sem uma aderência estrita aos padrões. É útil revisitar o design original da UML quando você estiver no meio do processo e também no final do projeto. Isso me ajudou a olhar para uma base de código em um nível mais alto de abstração que você pode apenas lendo o código e até ajudou a detectar possíveis erros.

Há um bom argumento aqui feito pelo ragu.pattabi que distingue entre dois tipos de UML ...

Eu acho que o sabor ágil da UML (por exemplo, esboço rápido do quadro branco) é mais bem-sucedido do que o sabor em cascata da UML (por exemplo, diagrama elaborado com todos os detalhes sangrentos para documentação, geração de código etc. para deixar os gerentes mais experientes em documentos).

Quando a UML era vista como uma habilidade 'must have' (há 10 anos ou mais), eu provavelmente era contra devido às opiniões opinativas de seus muitos fãs na época. Mas agora que caiu em desuso, eu me vejo vendo o que é - uma ferramenta útil que tem mérito, mas não é a bala de prata do desenvolvimento de software.

Uso UML (ou sth semelhante a UML :)) quando converso com amigos sobre algo que estamos prestes a fazer. Para discutir idéias. Não para preparar o projeto UML que gerará automaticamente o código para mim. Não consigo imaginar criar minhas classes em UML, gerar código e não ajustá-lo mais tarde. Isso nunca acontece. Portanto, você precisará trazer alterações de código para a UML. E quando uso UML, desenho no quadro branco ou no papel. Nunca em ferramentas como o Enterprise Architect.

O único motivo para documentar todo o meu código na UML seria um contrato em que o cliente o exija. Por exemplo, quando ele quer ter uma opção de mudar de loja de software após a conclusão de parte do software.

A documentação do trabalho do projeto é uma entrega fundamental de um projeto profissional. Quanto é suficiente? Bem, depende, é claro, de muitos fatores. No entanto, na minha opinião, casos de uso, diagramas de classes, diagramas de fluxo de processos etc. não são perda de tempo. Eles têm valor em várias fases do projeto. O único problema com a documentação são geralmente recursos.

Alguns programadores consideram a documentação um desperdício de tempo. mas isso não é verdade. Se você visualizar a documentação como uma exibição de suas regras de design e sistema de uma maneira elegante e clara, poderá apreciar mais. Além disso, é preciso colocar-se na posição das pessoas que precisam manter o sistema. Ser lançado 500 arquivos de código e ser solicitado a corrigir os problemas com eles é meio ruim, mas não incomum.

Sugiro que você aloque tempo no seu projeto e produza os diagramas em ciclos. O primeiro abordaria os aspectos de alto nível do seu projeto e os níveis subsequentes poderiam se concentrar mais nos detalhes.

Casos de uso em particular não podem ser deduzidos facilmente do código (diferente de muitos outros aspectos de um sistema). Certifique-se de fazer isso.

A UML é uma ferramenta, nada mais, e se é útil ou mesmo crucial depende apenas do seu fluxo de trabalho de desenvolvimento e design. Existem muitas maneiras de Roma, e algumas delas envolvem UML, enquanto outras não.

Se o seu fluxo de trabalho se baseia na UML para documentar ou planejar sua arquitetura, a remoção dela seria tola. Se a UML é a melhor maneira possível de comunicar a estrutura do projeto a outros membros da equipe (no sentido mais amplo), use-a de todos os modos. Mas se o projeto funcionar bem sem a UML, fazer diagramas da UML apenas por isso é um absurdo.

Eu tenho alguns pensamentos sobre isso. O idioma pode ser usado e abusado, forçar e distrair, disparar e embalar. A UML é apenas outro idioma adequado para um conjunto específico de problemas e, como qualquer outro idioma, levará tempo e esforço para aprender a falar fluentemente e a entendê-lo corretamente.

A decisão sobre o que comunicar é incrivelmente mais importante do que a linguagem na qual ele é comunicado. A UML não fará magicamente seus projetos ruins serem compreensíveis. Assim como qualquer outro idioma, é fácil se perder nos detalhes ou deixar muito para a imaginação.

A UML recebeu um nome ruim por causa dos inúmeros IDE's horríveis, permitindo a criação de protótipos de ida e volta, a manipulação de gráficos com uso intenso de cliques e a dificuldade de alterar qualquer coisa. A UML 2.0 pode ser complexa o suficiente para satisfazer certos acadêmicos, mas seu metamodelo não parece atrair muitas aplicações práticas.

Ainda assim, eu uso a UML de tempos em tempos. Para avaliar um design de alto nível (um bom design tem complexidade à margem e simplicidade no centro). Comunicar uma ideia a um colega e receber feedback. Para encontrar relações ocultas, normalizar etc. Mas é sempre um reflexo de algo que já está na minha cabeça. Geralmente, desenho UML com caneta e papel, de preferência longe de qualquer computador. Se necessário, quando um design se cristaliza, faço uma representação visual em um programa de desenho.

A UML é absolutamente fantástica para obter uma visualização gráfica da sua arquitetura usando um diagrama de classes. A interação usando o diagrama de sequência é mágica para mim. O problema não é, portanto, UML, mas MDD para mim.

Quero dizer que, se UML é um visualizador de código, é realmente útil para fins de documentação, mas certamente não para geração de código. O projeto deve ser centralizado em código e certamente não centralizado em modelo. A UML deve ser usada no estágio de implementação usando uma sincronização de código e modelo ativos. Quero dizer, não apenas no nível de requisitos, que exige muito investimento para um pequeno retorno em produtividade e qualidade.

Eu os acho superestimados. Eu os considero as únicas figuras que não pintam mais que mil palavras.

A UML é valiosa apenas se as pessoas que projetam o sistema não puderem escrever o código elas mesmas. ou seja, UML é uma 'linguagem' que comunica os conceitos de arquitetura a outra pessoa. Agora, se você é a pessoa que está projetando o código e implementando-o, por que precisaria se mostrar o que vai fazer? ?! Siga em frente e siga direto para a codificação. Você ainda precisará documentar o que fez mais tarde, mas a eficiência geral é mais rápida.

Mas, se você fosse um arquiteto de sistema e quisesse dizer à sua equipe terceirizada de desenvolvedores o que queria, teria que contar de alguma forma e é aí que entra a UML. No entanto, acho que existem muitos meios alternativos de execução Essa tarefa hoje em dia e, francamente, a complexidade do diagrama UML significa que todos precisam entender como lê-la, o que é um pouco autodestrutivo, se não o fizer.

Nunca fui fã de UML, mas cheguei a valorizar um bom diagrama de sequência para descrever interações entre sistemas ou tarefas.

No entanto, o diagrama de classes é obsoleto antes de nascer. Um design aproximado não requer UML, e uma documentação completa é melhor extraída automaticamente (ao vivo) da base de código. Javadoc e Doxygen obsoleta completamente a necessidade de diagramas de classes manuais.

A questão da documentação é que existem dois níveis:

• decisões de alto nível (arquiteturais) devem ser documentadas manualmente
• fatos de baixo nível (relações entre entidades) devem ser extraídos automaticamente

Normalmente, itero entre os diagramas de código e UML. Acho que os diagramas ajudam a mostrar o quadro geral e um caminho sólido a seguir e podem ser alterados rapidamente quando problemas são descobertos. Além disso, quando tenho os diagramas, a codificação tende a se tornar trivial.

Por outro lado, quando eu desenho o código nas figuras, ele expõe problemas de dependência e torna óbvias as oportunidades de aprimoramento do design, o que provavelmente não seria percebido se tivéssemos o código para trabalhar. Em particular, se é difícil desenhar, também será difícil codificar e manter um pesadelo.

Eu descobri que a iteração é necessária, porque apenas desenhar as imagens sempre perde aspectos importantes, enquanto apenas codificar resulta em projetos problemáticos.

No entanto, como outro pôster disse, tudo se resume ao povo. Se eles tiverem habilidade em "usar" diagramas UML, a UML será inestimável. Se não estiverem, os diagramas não têm valor.

Assim, a resposta para sua pergunta é realmente "depende". Nesse caso, depende das pessoas, da complexidade do projeto e de quão importante é que o sistema funcione corretamente.

Pela minha experiência, a UML é importante para a comunicação entre os desenvolvedores sobre os padrões de código e para a arquitetura em geral do aplicativo.

Adoro diagramas, mas se me pedissem para fazer um (especialmente UML!), Faria duas perguntas:

1. para quem é isso?
2. Eles precisam agora?

Os diagramas ficam desatualizados imediatamente. Portanto, a menos que você o esteja usando para se comunicar com alguém agora, ele simplesmente apodrecerá. E se a pessoa com quem você está se comunicando se sair melhor com uma descrição de texto, uma ligação telefônica ou um digram informal em um quadro branco - sugira isso.

Uma das principais queixas sobre os diagramas UML, como os vi usados ​​até agora, é que eles costumam servir apenas como "figuras bonitas" na parede de alguém ou como uma página dobrada em um encadernado em algum lugar e raramente servem como linha de base para um código de produção.

Nesse tipo de cenário - os diagramas UML (ou qualquer que seja o sabor da linguagem de modelagem usada) raramente são úteis a longo prazo, pois tendem a sofrer perda de relevância à medida que o tempo passa e o projeto evolui. Esses desenhos iniciais são inúteis e incorretos em alguns anos e tê-los por perto é prejudicial.

Dito isto, o uso de ferramentas de modelagem (não necessariamente UML) não é uma prática totalmente inútil, se os modelos fornecerem informações reais e relevantes ao código em execução. Se a descrição do modelo for um artefato útil do código, deverá ser tratado como código:

Usando-o como uma fonte direta de metadados para tomar decisões dinâmicas com base nos conceitos modelados ou usando a geração de código para gerar artefatos de código estático que são usados ​​no código de trabalho real.

Não sei se a questão é sobre o mérito da UML ou sobre o mérito de projetar a arquitetura dos programas.

Sobre a UML. Você geralmente só precisa: casos de uso, diagramas de classes e diagramas de sequência. Simples e fácil, embora você possa fazê-lo certamente com seus próprios tipos de diagramas. Nesse sentido, a UML é um padrão que todos entenderão.

Sobre a criação de programas.

1. Todo programa tem um design, mesmo que você não o planeje. Quando o código for escrito, faça a engenharia reversa. Se você não planejou, aposto que será um projeto ruim.

2. O design economizará tempo, usando padrões conhecidos para problemas recorrentes.

3. Se você trabalha em equipe, o design é necessário para discutir soluções, transmitir idéias e muito prático, mas necessário, para distribuir o trabalho.