Até que ponto um programador deve desenvolver sua compreensão do Processo Unificado e da UML? [fechadas]

Eu sei que muitos lugares usam a UML e o processo unificado como modelo de desenvolvimento ... mas há muitos que não. Seria importante ter mais do que uma compreensão básica e funcional desses assuntos ou seria melhor focar no desenvolvimento de habilidades de programação em outras áreas (por exemplo, desenvolvimento de linguagem, IDEs, etc.)?

A menos que você ache que observar a tinta secar enquanto esgoto é um bom momento, ignore o Processo Unificado. Espere, ignorá-lo não é suficiente. Tema isso. Até onde eu sei, atualmente só é usado por lugares enormes que estão além de toda esperança de eficiência, qualidade ou sanidade.

A UML, por outro lado, pode ser uma notação útil para conceitos importantes de programação. Obtenha o UML Distilled de Martin Fowler, experimente e pratique esboços de diagramas enquanto pensa em design. É uma habilidade que uso regularmente e fico feliz por tê-la.

Esteja ciente de que as pessoas tentam usar em excesso a UML. O UML do quadro branco ao discutir as coisas é impressionante. Um diagrama ocasional na documentação publicada pode ser bom. Mas a busca para documentar toda a sua base de códigos na UML é inútil e inútil. E o desejo de "programar em UML" é idiota. Se você se deparar com pessoas assim, fuja. Mas primeiro, marque a testa com um diagrama de sequência, para que todos nós sejam advertidos adequadamente.

Não gaste muito tempo com UML. Na minha equipe, sou o único a conhecer muito bem a UML e, portanto, criar casos de uso, componente, estado, implantação e outros diagramas. Os outros membros da equipe são melhores que eu na codificação, mas não tão bons no diagrama UML.

O truque que usamos é focar no diagrama de classes no nível de modelagem para definir a estrutura do aplicativo e também permitir que o desenvolvedor / arquiteto codifique como quiser. Em seguida, mesclamos o modelo com o novo código e atualizamos o modelo a cada iteração. Realmente fácil e muito eficiente. Desenvolvemos em Java com Omondo EclipseUML.

Eu recomendaria não usar nenhum MDD que seja para mim uma verdadeira porcaria !! O Modeler tentará ocupar mais energia dentro do processo de desenvolvimento, mas isso não criará nenhum valor se eles tentarem gerar todo o código do modelo. O código pertence ao desenvolvedor / arquiteto, mas não ao modelador. A UML deve ser apenas uma visão dos requisitos do projeto (por exemplo, caso de usuário, sequência, etc.) do processo (por exemplo, diagrama de estado ou de atividade), implantação (implantação, diagramas de componentes). O diagrama de classes deve exibir o código e o diagrama de classes UML deve ser usado apenas como visualizador do código. A codificação Java deve respeitar a abordagem de objetos e a UML, que também é uma linguagem de objetos, é realmente útil para evitar codificações ruins e estúpidas.

O mais importante são as iterações do diagrama de classes entre modelo para código e código para modelo. Não quero dizer realmente sincronização ao vivo, mas ser capaz de mesclar código e modelo a cada iteração. Eu uso o Omondo EclipseUML e acho que eles são os únicos a mesclar java, entidades de banco de dados e IDs de modelo. A mesclagem de ID é realmente um conceito poderoso e é perfeita para nossos projetos ágeis.

Minha recomendação é não comprar nenhum livro. Você deve ter uma abordagem de objetos e usar a linguagem do diagrama de classes para visualizar seus objetos, a fim de criar arquiteturas melhores. Se um membro da equipe conhece a UML, use os outros diagramas, se não o diagrama de classes seria suficiente.

O Processo Unificado e a UML são um conjunto de ferramentas estruturadas de pensamento e comunicação. Essas ferramentas ajudam de algumas maneiras; definindo uma maneira de falar sobre projetos e ajudando-nos a trabalhar nos detalhes e facetas de nossos projetos.

Melhorar seu próprio pensamento é fundamental para concluir os detalhes de um design e encontrar o caminho para um produto são e coerente. As disciplinas pessoais ajudam você a se concentrar, acompanhar detalhes, pensar além dos limites e lembrar o que pensa meses depois.

Melhorar a forma como o design é abordado e aprimorado é fundamental para fazer com que um grupo de designers fique ainda mais rápido. As disciplinas do grupo ajudam a obter mais do grupo.

Mas lembre-se de que a UML e o Processo Unificado são apenas uma das muitas ferramentas de pensamento. Eles são razoáveis, mas podem ou não ser adequados para você ou seu grupo (o que é tão importante quanto qualquer outro fator).

Na minha opinião, agora há uma maneira de contornar a UML. Pegue um livro e aprenda. Você precisa:

• leia livros técnicos que usam UML (existem muitos)
• use-o como uma ferramenta de desenho para discutir idéias / soluções com faculdades.
• forneça a si mesmo uma maneira rápida de visualizar a solução em que está pensando e raciocinar sobre ela.
• ler / raciocinar sobre projetos técnicos / funcionais em determinadas empresas

O processo unificado que eu acho que é uma história diferente, depende do empregador em que você está. Eu leria um livro pelo menos para saber o que é e quando chegar a hora em que você realmente precisa estudá-lo.

Espero que isto ajude.

Eu não acho que você precise de um conhecimento extremamente profundo da UML, mas definitivamente deve poder olhar para um diagrama e saber o que está acontecendo. O que você DEVE tentar obter um conhecimento profundo dos diferentes padrões de design (compre um livro). Quando você cria seus próprios designs, ele ajuda a conhecer o padrão de design e o padrão UML, mesmo que você não o desenhe. Também ajuda a entender um diagrama UML quando você o vê, porque você pode entender um pouco melhor por que a UML se parece com isso.

Eu estive neste negócio desde 1987 e as únicas vezes em que lidei com a UML e o Processo Unificado foram algumas ocasiões em que algum consultor mal-intencionado pagou muito dinheiro para forçar a alimentar a equipe com todas as minúcias desses exagerados, metodologias exageradas e tendenciosas. Após todas as tentativas de aplicar essa porcaria não adulterada, acabamos gerando documentação obsoleta quase que imediatamente para encher a Biblioteca do Congresso de transbordar e além, ao mesmo tempo em que desacelera o design e o desenvolvimento de nossos projetos.

Se o seu produto comercial for medido em libras de papel e / ou no tamanho da documentação, nunca será lido mais de uma vez (se houver) e será obsoleto para sempre, e será a base na qual você são pagos, então, por todos os meios, fique louco com essa porcaria.

Caso contrário, corra gritando pelas colinas com a primeira menção de UML e UP. Ou melhor, bata na primeira pessoa que a disser a polpa.

Você pode mencionar que poderia usar a UML SEM o Processo Unificado. Eu uso muito UML ao mesmo tempo que a programação, mas, para mim, é importante ser prático, não apenas usá-lo porque "é uma ferramenta nova e brilhante".

Diagramas de classe, casos de uso e diagramas seqüenciais são os meus favoritos. Não preciso usar outros tipos de diagramas com tanta frequência, como esses.

Muitas empresas não usam o Unified / Rational Process.