Documentos de design vs UML ou ambos?

Question

Eu tive dificuldade em ficar sentado na frente da UML e obtendo valor disso, porque quase parece muito trabalho como programação (se você usar uma linguagem expressiva). Acho que escrever linguagem natural me diz mais sobre um projeto de software do que criar diagramas complicados. Eu sou novo no Uml e eu me perguntei de outras pessoas que conhecem bem um pouco:

1. A UML vale o tempo todo necessária para aprender / fazer, mesmo para projetos de médio porte?
2. Os documentos de design bem elaborados podem, embora ainda mais altos, basta manter os programadores no alvo para criar o código certo, mesmo nas equipes?

Answer 1

Eu não acho que a UML seja suficiente por si só.

Eu tive dificuldade em ficar sentado na frente da UML e obtendo valor disso, porque quase parece muito trabalho como programação (se você usar uma linguagem expressiva).

Eu concordo com isto. A UML pode fornecer assinaturas de método, mas você não preenche a carne do método. Pior, você não pode fazer nada se aproximando do TDD com a UML. Dada uma opção, prefiro ter TDD e código de funcionamento do que diagramas UML.

Acho que escrever linguagem natural me diz mais sobre um projeto de software do que criar diagramas complicados.

Spot on. As fotos podem ser úteis, a menos que sejam fotos ruins. Os diagramas de sequência tendem a se tornar impossivelmente complicados para todos os fluxos, exceto triviais.

A UML vale o tempo todo necessária para aprender / fazer, mesmo para projetos de médio porte?

Fornecedores e arquitetos dirão que a UML é indispensável, mas eu não concordo. Eu caio no "Skecher" Camp of UML Usuários.

Os documentos de design bem elaborados podem, embora ainda mais altos, basta manter os programadores no alvo para criar o código certo, mesmo nas equipes?

Não sei o que basta para manter os programadores no alvo, mas acho que a UML não é uma grande parte disso. Os arquitetos tendem a adorar porque as ferramentas UML os mantêm ocupados, mas a maioria dos desenvolvedores não se importa além de caixas e flechas em tábuas brancas.

Answer 2

Eu responderia:

Nada, absolutamente nada, substitui a necessidade de uma boa comunicação entre programadores em uma equipe de programação e gerenciamento.

Isso significa um certo nível de dividir a tarefa em declarações simples "o que precisamos fazer" para os gerentes e explicar qualquer obstáculo.

Eu trabalhei em um pequeno projeto em que toda a estrutura da classe do programa foi projetada por alguém na UML antes de qualquer código ser escrito. Ótimo, mas os designers não anteciparam a maneira como as classes podem ser usadas ou a necessidade de alterar certas estruturas para se ajustar melhor à lógica do programa. Eles simplesmente jogaram fora um design que pensavam que funcionaria.

Ainda estou para conhecer alguém que possa projetar um programa na cabeça e produzir exatamente isso ao escrever além de coisas muito simples. O processo é bastante orgânico e as coisas precisam mudar ao longo do caminho à medida que os programadores realizam seus erros anteriores e os corrigem. Eu posso ver por que o Creep começa a ocorrer e é aqui que a gerência precisa entender o que está acontecendo, ser mantido no loop e atualizado. Bons gerentes ouvirão o que seus programadores estão dizendo e ajustam as vistas de acordo.

Portanto, das suas duas opções que eu iria para o documento de design de alto nível: queremos que o software faça isso, execute nesta plataforma, aceite esse tipo de entrada e cuspir esse tipo de coisa. Isso funciona, se o acima for mantido.

Uml, no que me diz respeito, não vale a pena.

Answer 3

1. Não na minha opinião. Certa vez, fiz um módulo de design do OO como parte de um mestrado em ciência da computação e a UML mal mencionou (embora, na minha opinião, deveria ter sido discutida muito mais dada sua influência).

2. Há mais escopo para reduzir as ambiguidades em texto escrito do que em um diagrama UML, a maioria dos D daigramas da UML deixa muito espaço para a interpretação. Dito isto, sou um grande fã do uso de diagramas em documentos de design de software e muitos dos diagramas UML são extremamente sucintos: implantação, estado, classe e atividade são meus favoritos. Quando crio diagramas UML, tento manter aproximadamente as convenções, mas não os deixo atrapalhar se não puderem representar o conceito que estou tentando me comunicar.

Answer 4

Não podemos ignorar totalmente a UML, pois alguns dos diagramas são úteis quando se trata de funcionalidade complexa ou digamos um longo processo de fluxo de trabalho e cenários em que os desenvolvedores podem perder alguns casos em que os cenários não forem desenhados/projetados. Outra importância da UML é lembrar no futuro como o sistema funciona e como seus módulos estão se comunicando para garantir que o projeto seja escalável sem gerar bugs enormes que podem ser infinitivos e sérios. Portanto, os dois documentos de design escrito e a UML são importantes para qualquer projeto médio ou grande.