ti-enxame.com

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

A meu ver, se você criar um antes de obter a vantagem de:

  • Planejando à frente
  • Visão geral do projeto

mas você perde:

  • Tempo (trabalhando, você provavelmente vai acabar repetindo ao escrever o código)

Por outro lado, eu poderia simplesmente criá-los todos depois de escrever meu código apenas para mantê-lo como uma referência para futuros desenvolvedores.

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

11
Jonn

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

Se você criá-los depois, pode apenas usá-los para documentação. Mas documentar é melhor e mais rápido se você fizer isso durante o design e a codificação.

Aliás, você não perde tempo fazendo design! A parte da codificação será mais rápida. E melhor.

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

Um meio-termo é 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 construir os diagramas de classes.

9
Wizard79

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

12
Jeff Siver

Em qualquer caso, eles permanecerão como parte da documentação. Ninguém os atualizará quando forem feitas mudanças na implementação. Os diagramas não terão datas, então você nem mesmo saberá a qual versão do código eles se referem. Quando uma nova pessoa é adicionada ao projeto, você fornecerá a ela os diagramas, dizendo "Aqui estão alguns diagramas que foram criados em algum momento durante o design ou implementação. Não sabemos se estão atualizados."

4
Mark Lutton

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

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 ponto ou outro.

3
Chris

Depende da profundidade do design. Algumas pessoas insistem em escrever diagramas de classes até mesmo para as classes mais triviais, porque "é uma boa prática". Acho uma perda de tempo desenhar algo quando você já sabe exatamente como vai ser implementado. Quando criando 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 tenho que redesenhar o diagrama. Suponho que uma boa ferramenta bidirecional lidaria com essas mudanças, mas nunca usei uma boa (no entanto, usei apenas as gratuitas). Em vez disso, desenho em papel ou em um quadro branco para me ajudar a organizar o design. Depois de implementá-lo e estar razoavelmente certo de que está correto, farei um diagrama mais formal.

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

3
Matt Olenik

Antes da implementação. Como um de meus ex-colegas de trabalho disse uma vez: 'Gosto de programar o máximo possível antes de começar a codificar', e acho que é uma boa abordagem para isso.

1
GSto

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

Além disso, se o projeto que você tem vagamente em sua cabeça acabar sendo uma porcaria, você notará isso mais rapidamente se primeiro diagramar. Portanto, pelo menos desenho algo rápido e informal. Se ele se transforma em um diagrama eletrônico que outros possam usar como referência, dependerá do projeto.

1
Kate Gregory

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

Em 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ê. UML deve permitir a fusão de modelo e código a qualquer momento de forma iterativa (por exemplo, de código para modelo, de modelo para código, de ambos, do código após refatoração, etc ...) Eu uso Omondo EclipseUML para Helios e estou muito feliz com esta ferramenta. Meu recurso favorito é a fusão de modelos, que me permite atualizar meu modelo a qualquer momento sem perder as informações do modelo. Também gosto de modelar entidades diretamente no diagrama de classe e criar o banco de dados usando estereótipo e hibernação. Realmente poderoso e completo de objeto a banco de dados !!

1
UML_GURU

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

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

Ambos são úteis, mas o material antes pode ser jogado fora assim que for implementado ... já está desatualizado neste ponto.

1
Matthieu M.

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

0
mouviciel

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

Eles são amplamente desnecessários. Pessoalmente, nunca me preocupo em olhar para eles quando são fornecidos.

Eles são desnecessários antes do desenvolvimento, porque o design mudará de qualquer maneira. E se você não acha que o design de suas classes vai mudar, então você já está se algemando e impedindo que seu futuro eu seja capaz de resolver o problema adequadamente. Se você acha que precisa seguir alguns diagramas de classe pré-existentes, ou trabalha para a NASA ou está atirando no próprio 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 umas com as outras com uma pequena inspeção de código, então você tem um buraco em seu conjunto de habilidades como desenvolvedor de software.

Claro, essa resposta parece realmente arrogante e teimosa; Ah bem.

0
Chris Holmes

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

0
Greg Domjan