É o seguinte, sempre estive acostumado, devido a correria dos projetos, a implementar e depois gerar diagramas do que foi implementado.
Hoje surge uma necessidade de fazer o inverso (o correto), porém como estou acostumado com a visão de desenvolvedor fica dificil logo de cara ler um caso de uso para fazer um diagrama de classe e de sequência e ainda por cima aplicar algum design pattern no diagrama de classes, e ainda por cima não irei implementar e nem estou imerso no projeto em que irei diagramar com diagramas de classes e sequência, seria uma “terceirização” diagramar o projeto alheio.
O que vocês recomendam ou não recomendam para esse caso.
O que receberei de insumo para essa tarefa seria apenas casos de uso.
É viável ou loucura?
Abraços.
Na MINHA opinião, caso de uso não é artefato para codificação. Se existir pelo menos um desenho da aplicação, nem que seja um desenho simples, já é um bom artefato para inicio da codificação.
Casos de uso representam o que usuário conhece e sabe fazer no sistema : (Emitir pedido, Emitir nota fiscal, Emitir cobrança, etc…)
Se estes casos de uso que você receber tiverem suas regras , seus fluxos muito bem definido, com os requisitos (Func e ÑFunc caso existam ) auxiliando-os é possível sim , elaborar as classes , sequencia , estado, etc…até pq o RUP prega isto …
Agora se atente a estes user cases , pois mal elaborado no inicio compromete todo o restante do projeto … e mal feito ou projetado , deixa bem claro que quem esta especificando o sistema não entendeu nada que o negócio ou usuário tá requisitando…acho que é isto …precisando é só avisar …
Também concordo, pois a maioria das vezes em que peguei um diagrama de classes para codificar, acabei tendo que altera-lo pois durante a implementação vemos coisas que não conseguimos ter idéia quanto estamos na fase de “abstração”.
Mas muitos projetos ainda utilizam esse modelo de diagramar para desenvolver, por isso recorro até aqui para ver se vcs podem me dar uma luz com a experiência pessoal de cada um.
Diagramas, na maioria dos casos, são artefatos temporários para ajudar as pessoas a entenderem um problema visualmente e repassarem o conhecimento. Se não há nenhuma política de arquivar esses diagramas atualizados e completos, amasse o papel e jogue no lixo após o seu uso.
Os diagramas assim como toda a documentação servem, além de descrever as funcionalidades do sistema, definir o escopo do sistema e como material de apoio para futuras manutenções.
Se você não tem nada documentado, o cliente pode alterar o escopo a qualquer momento, o que gera atrasos e aumento de custo.
Sem contar que é extremamente difícil dar manutenção em sistemas sem documentação.
Todo o processo, desde o primeiro contato com o cliente até os testes, implementação e manutenção devem ser documentados e devidamente assinados pelos responsáveis.