Diagramas UML verdadeiramente úteis

UML tem uma selva de diagramas.
Diagramas de perfis, diagramas de classes, diagramas de pacotes ...

No entanto, (IMH-e-não-muito-experiente-O), vejo que fazer todo e qualquer diagrama é um exagero.

Portanto, quais diagramas UML são mais adequados em um contexto da Web, mais especificamente em um blog (queremos construí-lo do zero).

_{Entendo que só porque usei diagramas UML não significa que nosso código seria ótimo e brilhante ... mas certamente seria melhor do que apenas código não planejado ...}

Como orientação geral:

• Um diagrama de implantação para uma visão geral da arquitetura (válida para qualquer sistema)
• Um diagrama de casos de uso para uma visão geral do que os usuários farão com o sistema (aqui)
• Um diagrama de classes para o modelo de dados
• Diagramas de atividades para o fluxo de casos de uso individuais, se eles forem complexos
• Talvez um diagrama de máquina de estado se você tiver um fluxo de trabalho de criação / revisão / publicação para entradas de blog

Alguns tipos de diagrama (por exemplo, diagrama de temporização) têm usos bastante especializados, outros tendem a um nível de detalhe em que o código real faz um trabalho melhor (por exemplo, diagramas de sequência) e outros ainda parecem destinados a projetos gigantescos, mas têm utilidade questionável mesmo lá ( diagramas de pacotes? Qualquer IDE pode mostrar seus pacotes).

O diagrama é menos importante do que as conversas que você tem ao comunicar conceitos entre as várias partes interessadas em um projeto. Depois de anos desenvolvendo software, me vi tentando capturar informações em diagrama ainda menos nos últimos anos do que costumava quando estava começando. Hoje em dia, talvez eu elabore alguns casos de uso simples em um quadro branco ao discutir conceitos, e frequentemente recorrerei a um fluxograma simples, mas clássico, se estiver tentando entender melhor como um cliente deseja que um sistema funcione. Se eu estiver particularmente preocupado, usarei a câmera do meu telefone para capturar a imagem no quadro branco para me ajudar a lembrar de coisas específicas.

O design inicial fortemente documentado não é muito enxuto. Desestimula a mudança e fixa o seu pensamento em torno de um único plano de ataque que pode acabar totalmente errado para o projeto em geral. Você deseja adiar o máximo possível de seu design até o último minuto, a fim de reduzir as chances de uma grande mudança atrapalhar seus designs e agendamentos mais tarde. Isso não quer dizer que a UML não deva ser usada, mas que deve ser usada com moderação, como um meio de melhorar a comunicação de conceitos, e não como um meio de definir os sistemas que você pretende construir.

A UML foi projetada como uma linguagem de comunicação entre as pessoas envolvidas. (programadores-programadores, programadores-empresários, empresários-usuários) As pessoas expressam seus modelos mentais em uma linguagem simples e unificada que todos entendem.

Você precisa se perguntar quanto dessa comunicação precisa.

• É um software ou produto interno que você deseja vender junto com a documentação?
• Por quanto tempo você manterá o software? Você contratará um programador para mantê-lo?
• Quão ágil você quer ser? Você pode perder tempo com um planejamento muito detalhado.
• Quão estranhas coisas você quer fazer? Geralmente, você não precisa documentar padrões comuns, como caso de uso detalhado de registro ou arquitetura geral de um blog.

Uma regra prática é fazer os diagramas de alto nível para fornecer uma visão geral e dedicar tempo a coisas complicadas ou pouco comuns. Escrever / desenhar seu modelo mental na UML o força a entendê-lo completamente e a resolver muitos bugs antes de escrever uma única linha de código.

Você precisa do número necessário para entender e comunicar o sistema. Para o software de blog, eu acho que você não precisa de muitos. Modele o quanto for necessário para entender o sistema. Pare de modelar quando parar de adicionar sua compreensão.

Se você é novo na UML, pode querer fazer alguns diagramas em detalhes para aumentar sua compreensão dos diagramas. Depois de entender bem um tipo de diagrama, você pode fazê-lo em sua mente, a necessidade de diagramas reais se torna menor.

Se você datar as versões do diagrama, isso ajudará a avaliar se é provável que elas sejam atuais. Comparar o design atual com diagramas mais antigos pode ser útil para determinar quais áreas do projeto variaram significativamente do design original.

A menos que você esteja usando ferramentas que geram o código a partir de diagramas ou incorporam a especificação do diagrama no código, é provável que caiam fora de sincronia com o código. Diagramas detalhados tendem a se tornar significativamente mais incorretos ao longo do tempo. do que o diagrama de visão geral. Os diagramas de visão geral também exigirão menos manutenção para mantê-los atualizados.

Você pode achar útil gerar diagramas que:

• Descreva os atores e como eles usam o sistema.
• Descreva a estrutura dos pacotes dentro do sistema. Observe quais pacotes contêm componentes reutilizáveis.
• Modele a estrutura do banco de dados.
• Os diagramas de sequência são úteis para projetar componentes padrão. Se você tiver muitos componentes semelhantes, modele um e use-o como padrão para os outros. Considere a reutilização de código em casos como este.

Gere diagramas que são úteis no planejamento do projeto. Se um diagrama não for necessário para entender e / ou comunicar algo sobre o projeto, não perca tempo com ele. Sinta-se à vontade para usar um diagrama não-UML, se isso ajudar a entender. UML pode não ser a melhor maneira de modelar o banco de dados.

Eu diria que você precisa adaptar os diagramas UML ao nível de modelagem de todas as partes interessadas e ao tempo necessário para concluir o projeto.

Se a equipe não conhece a UML e não tem tempo, apenas o diagrama de classes proveniente do código reverso é possível. Cada membro pode adicionar seus comentários no diagrama de classe, o que já é uma boa solução para documentação. Nesse caso, o modelo é apenas uma visualização gráfica do código. Isso cobriria quase 90% das necessidades de modelagem se feito com cuidado e não acrescentará tempo extra ao projeto.

Se você possui conhecimento avançado de partes interessadas, todos os diagramas podem agregar valor real ao projeto, a fim de cobrir as necessidades completas do projeto de modelagem. Isso poderia adicionar um tempo significativo à entrega do projeto, mas espera-se que a qualidade da entrega seja melhor.

A UML é legal, brilhante e pode ser adaptada a qualquer projeto, se usada com moderação. Não beba e dirija, por exemplo, ao mesmo tempo :-)

Além de alguns diagramas gerais que serão usados ​​para comunicar a arquitetura geral do seu aplicativo em termos de servidores, camadas ou grandes módulos, acho que não é possível prever quais diagramas serão necessários anteriormente.

Aguarde até o último momento responsável. Você verá quando precisar deles . Geralmente, é

• durante uma conversa com o cliente / especialista / analista de domínio, para esclarecer um caso de uso
• ou pouco antes de começar a codificar, para criar uma primeira versão do seu design.

De qualquer forma, seus modelos provavelmente se tornarão obsoletos assim que você escrever algumas linhas de código ou obter o primeiro feedback do cliente. Portanto, não se preocupe em planejar tudo antecipadamente ou em polir seus diagramas.