Você deve criar diagramas de classes antes ou depois da implementação?

Do jeito que eu vejo, se você criar um antes de obter a vantagem de:

• Planejando à frente
• Visão geral do projeto

mas você perde:

• Tempo (fazendo o trabalho, você provavelmente acabará repetindo ao escrever código)

Por outro lado, eu poderia criar todos eles depois de escrever meu código apenas para mantê-lo como referência para futuros desenvolvedores.

Qual serve ao propósito dos diagramas de classes e qual é mais vantajoso?

Se você os criar antes, eles farão parte da fase de design.

Se você os criar depois, poderá usá-los apenas para documentação. Mas a documentação é melhor e mais rápida se você fizer isso durante o design e a codificação.

A propósito, você não perde tempo fazendo design! A parte de codificação será mais rápida. E melhor.

Afinal, você acha que projetar um arranha-céu ou uma ponte é uma perda de tempo, em vez de apenas começar a construí-lo?

Um compromisso é começar a criar algum código fictício durante a fase de design (apenas protótipos de classes / funções) e usar esse esqueleto de código para criar os diagramas de classes.

Quando os criei antes da codificação, os vemos como documentos "temporários". Ou seja, criamos os diagramas e colocamos nossos pensamentos no papel. Começamos a codificar a partir desses diagramas de classes. Nós então os jogamos fora. Não vale a pena gastar tempo para mantê-los após o início da codificação. E se você deseja modelos de classe atualizados, use uma ferramenta para criá-los a partir do código.

Em ambos os casos, eles permanecerão como parte da documentação. Ninguém os atualizará quando forem feitas alterações na implementação. Os diagramas não terão datas, portanto você nem saberá a que versão do código eles se referem. Quando uma nova pessoa é adicionada ao projeto, você fornece a ela os diagramas dizendo "Aqui estão alguns diagramas criados em algum momento durante o design ou a implementação. Não sabemos o quanto estão atualizados".

Isso faz parte do design e, portanto, deve ser criado antes da implementação. Isso não significa que eles não possam ser refinados durante / após a implementação para refletir o estado atual das implementações.

Fornecer um design após a implementação é o que eu chamaria de "codificação de cowboy", e com certeza você pode prosperar no oeste selvagem, mas lembre-se de que os cowboys geralmente acabam mortos em algum momento ou outro.

Depende da profundidade do design. Algumas pessoas insistem em escrever diagramas de classe, mesmo para as classes mais triviais, porque "é uma boa prática". Eu acho que é uma perda de tempo desenhar algo quando você já sabe exatamente como isso será implementado. Ao criar um novo design, algo que não é familiar, é definitivamente útil desenhar alguns diagramas primeiro.

Porém, nunca uso ferramentas UML, porque o design geralmente muda tanto durante a implementação que preciso redesenhar o diagrama. Suponho que uma boa ferramenta bidirecional lidaria com essas alterações, mas nunca usei uma boa (porém, usei apenas grátis). Em vez disso, desenho em papel ou em um quadro branco para me ajudar a classificar o design. Depois de implementá-lo e ter a certeza razoável de que é bom, farei um diagrama mais formal.

Além disso, não vamos esquecer os outros tipos de diagramas. Sempre achei os diagramas de sequência entre os mais úteis e os uso frequentemente quando há muita comunicação entre os componentes.

Antes da implementação. Como um dos meus ex-colegas de trabalho disse uma vez 'Eu gosto de fazer o máximo de programação possível antes de começar a codificar', e acho que essa é uma boa abordagem.

Acho que o ato de desenhar um diagrama geralmente me alerta para a falta de informações. Isso também acontecerá se eu estiver digitando apenas um editor de código sem ter desenhado o diagrama, mas as instâncias serão mais espaçadas (porque passarei um tempo escrevendo algoritmos, cálculos e testes e similares) e, portanto, posso permitir mais tempo para passar antes de obter minhas informações ausentes.

Além disso, se o design que você tem vagamente em sua cabeça for uma porcaria, você perceberá isso mais rapidamente se o diagrama primeiro. Portanto, eu pelo menos desenhei algo rápido e informal. Se ele se transformar em um diagrama eletrônico que outras pessoas possam usar como referência dependerá do projeto.

A criação do diagrama de classes deve ser feita, durante e depois, porque o modelo deve ser interativo com as modificações de código e requisitos. Primeiro, você precisa criar um diagrama de classes para iniciar seu projeto. Ajudaria a visualizar em um nível mais alto de abstração seus objetos. Você poderá criar uma arquitetura de software estável e inteligente. Então você precisa codificar e, às vezes, notará que a arquitetura que parece estar bem na UML não é realmente possível no código. Você então altera seu código e arquitetura. Finalmente, você atualiza seu modelo com modificação de código e gera documentação.

No meu último projeto, os tomadores de decisão mudaram meus requisitos mais de 50 vezes no ano passado. É realmente doloroso e a UML me ajuda a manter a rastreabilidade das mudanças e por quê. A UML deve permitir que o modelo e o código sejam mesclados a qualquer momento de maneira iterativa (por exemplo, de código para modelo, de modelo para código, de ambos, de código após refatoração, etc ...) Eu uso o Omondo EclipseUML for Helios e estou muito feliz com esta ferramenta. Meu recurso favorito é a mesclagem de modelos, que permite atualizar meu modelo a qualquer momento, sem perder as informações do modelo. Também gosto de modelagem de entidades diretamente no diagrama de classes e crio o banco de dados usando estereótipo e hibernação. Realmente poderoso e completo do objeto ao banco de dados !!

Antes : ajudará a organizar seus pensamentos e a comunicar sua intenção. Não entre em detalhes aqui.

Depois : é gerado automaticamente a partir do código como parte do processo de compilação, obviamente (espero que você não esteja muito ligado ao uml)

Ambos são úteis, mas o material anterior pode ser jogado fora assim que implementado ... já está desatualizado de qualquer maneira neste momento.

Com o Topcased , crio meus diagramas de classe durante a fase de design. Então clico no botão "Gerar código" para produzir uma tela da minha implementação. Em seguida, preencho os espaços reservados com código.

Vou votar na resposta (C) Não se preocupe.

Eles são em grande parte desnecessários. Pessoalmente, nunca me importo em olhar para eles quando são fornecidos.

Eles são desnecessários antes do desenvolvimento, porque o design será alterado de qualquer maneira. E se você não acha que o design de suas aulas mudará, então já está se algemando e impedindo que o seu eu futuro seja capaz de resolver adequadamente o problema. Se você acha que precisa seguir alguns diagramas de classe pré-existentes, trabalha para a NASA ou se atira no pé.

Depois, são documentação desnecessária. Se você não consegue descobrir o que as classes estão fazendo ou como elas se relacionam com uma pequena inspeção de código, você tem um furo no seu conjunto de habilidades como desenvolvedor de software.

Obviamente, essa resposta parece realmente arrogante e opinativa; Ah bem.

Com o Eiffel e as ferramentas associadas, isso é apenas uma diferença de ponto de vista, todos apontando para os mesmos arquivos subjacentes.