Engenheiros ainda usam diagramas de casos de uso e diagramas de classe?

Oi.
Minha pergunta é essa. Tem muito desenvolvedor que não uso diagramas de casos de uso, de classe, UML e derivados.
Gostaria de saber se os engenheiros atuais e mais 'descolados' usam.
Abraço.

Depende.

Se for para fazer um sistema grande, com múltiplos usuários e gerenciamento de conflitos interdepartamentais sim.
Se for escrever um livro, e quiser demonstrar com clareza um projeto ou idéias, sim também.

Agora, para sistemas onde um só usuário tem autonomia, acho melhor um processo ágil. Sem tanta diagramação.

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 425 Offline

ViniGodoy wrote:Depende.

Se for para fazer um sistema grande, com múltiplos usuários e gerenciamento de conflitos interdepartamentais sim.
Se for escrever um livro, e quiser demonstrar com clareza um projeto ou idéias, sim também.

Agora, para sistemas onde um só usuário tem autonomia, acho melhor um processo ágil. Sem tanta diagramação.

Agile só funciona para projetos pequenos -> MITO

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 425 Offline

dedejava wrote:Oi.
Minha pergunta é essa. Tem muito desenvolvedor que não uso diagramas de casos de uso, de classe, UML e derivados.
Gostaria de saber se os engenheiros atuais e mais 'descolados' usam.
Abraço.

Respondendo:

só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais "Feature Driven"...

Taz wrote:
só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais "Feature Driven"...

Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa. Caso de uso simplesmente é um requisito atômico que pode ser capturado, analisado, implementado, testado (não necessariamente nesta ordem) e ao mesmo tempo agrega algum valor observável para os usuários.

O uso da UML muitas vezes é para discutir com a equipe ou com os usuários. Um modelo de casos de uso pode enriquecer ou entorpecer essa discussão. Um diagrama de classes é muito bom para discutir o domínio e chegar a um domain model mesmo que seja no papel.

De qualquer forma o uso da UML deve ser homeopático. UML não é documentação. Seja realista com relação à UML.

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 425 Offline

rodrigoy wrote:

Sem exageros. Um caso de uso é uma história. Caso de uso é um conceito, assim, não considero o termo caso de uso nem o diagrama e nem a narrativa.

Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.

Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido.

This message was edited 1 time. Last update was at 12/05/2008 00:07:48

Taz wrote:
Bastante política sua visão sobre Casos de Usos, mas para mim: casos de usos != estórias. Caso de Uso é o que UML define como Caso de Uso, com toda sobrecarga de seus templates e com toda sua buracracia. Casos de Usos possuem homenzinhos, bolinhazinhas, setinhas, fluxo principal, fluxos alternativos, etc, etc.

Mantenho a posição. Casos de Usos (de acordo com a definição da UML) geram muita confusão e desperdício de recursos em projetos. Prefiro a flexibilidade de uma abordagem narrativa e livre aliada ao uso seletivo de UML. Por exemplo: ora um Diagrama de Estados aqui, ora um Diagrama de Atividades ali, de acordo com o requisito sendo definido.

Taz, o Kent Beck não faz diferença entre uma história e um caso de uso. Não vejo porque nós deveríamos fazer. A UML não define padrão para template nem para a narrativa e o diagrama é bem conciso. Se você está usando a prática de maneira correta não vejo porque taxar como burocrático ou dispendioso. Use Case é mais antigo que a UML.

Sei que essa não deve ser a resposta, mas se seu projeto não exige formalidade você pode usar os casos de uso no modo "brief use cases" e o desenvolvimento ficará muito próximo de User Stories.

dedejava wrote:Oi.
Minha pergunta é essa. Tem muito desenvolvedor que não uso diagramas de casos de uso, de classe, UML e derivados.
Gostaria de saber se os engenheiros atuais e mais 'descolados' usam.
Abraço.

Tirando o titulo engenheiro

, isso fica a cargo do cliente e da equipe que esta desenvolvendo ( vide outras respostas).

Em alguns casos não dá para escapar de uma montanha de diagramas inuteis que no project equivalem a 80% do projeto, isso sem vc escreverf uma linha de código.

Pessoalmente eu prefiro utilizar tais diagramas apenas quando tenho dúvida em algum conceito ou funcionalidade, porém, muitas vezes o código fala por si só.

This message was edited 1 time. Last update was at 12/05/2008 08:06:04

Bom eu só utilizo os diagramas de casos de uso quando as regras são meio confusas ou de dificil compreensão, acredite apesar da maioria dos casos de usos serem simples ha alguns bem chatos, mas somente nesses casos. Já diagramas de classes quase não uso acho que eles servem principalmente para conhecer o sistema que irá desenvolver ou dar manutenção ou para debater com a equipe e com o cliente, mas acredito que não seja uma coisa essencial.

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 425 Offline

rodrigoy wrote:
Taz, o Kent Beck não faz diferença entre uma história e um caso de uso.

Ele fala que são iguais? Referências?

rodrigoy wrote:

Sei que essa não deve ser a resposta, mas se seu projeto não exige formalidade você pode usar os casos de uso no modo "brief use cases" e o desenvolvimento ficará muito próximo de User Stories.

IMHO, essa é a resposta: eu e minha equipe usaremos o que acharmos melhor.

This message was edited 1 time. Last update was at 12/05/2008 09:26:04

Taz wrote:Agile só funciona para projetos pequenos -> MITO

Ops... ops... não foi o que eu falei. Até porque, temos tocado projetos bastante grandes com agile development aqui.

O que eu falei é que uma das premissas do Agile é que o usuário sabe o que quer ou, pelo menos, tem autonomia total de decisão. E, infelizmente, em alguns sistemas o analista acaba agindo como mediador e, infelizmente também, temos que usar a documentação como arma - o que justamente o agile quer evitar.

Tente implementar um sistema onde há conflitos de interesses entre os setores e você vai perceber o que estou falando. E não precisa ser um sistema grande. Aliás, na prática, nada funciona quanto há esse tipo de conflito.

JavaEvangelist Membro desde: 02/06/2005 16:28:38 Mensagens: 425 Offline

ViniGodoy wrote:
Tente implementar um sistema onde há conflitos de interesses entre os setores e você vai perceber o que estou falando. E não precisa ser um sistema grande. Aliás, na prática, nada funciona quanto há esse tipo de conflito.

Nem tentaria. Existe um princípio de administração chamado de amplitude de controle que diz que um departamento/funcionário/projeto não pode ter dois chefes. Se vc tem, vc tem um problema gerencial que documentação não resolverá. A melhor caminho é sentar com os dois para resolver o conflito. Se eles não resolverem, escale para os chefes deles...

Taz wrote:Nem tentaria. Existe um princípio de administração chamado de amplitude de controle que diz que um departamento/funcionário/projeto não pode ter dois chefes. Se vc tem, vc tem um problema gerencial que documentação não resolverá. A melhor caminho é sentar com os dois para resolver o conflito. Se eles não resolverem, escale para os chefes deles...

As vezes o conflito ocorre entre o chefe, que quer mudanças de processo, e o gerente, que vai te boicotar, já que tem medo de perder autonomia/poder. Ou mesmo entre gerente (que quer mudanças) e funcionário (que pensa que será demitido, ou provavelmente vai ser demitido, mas é quem conhece o detalhe do processo).

Não sei se você já passou por isso, mas nessa situação, é realmente muito difícil trabalhar. Pior ainda se você conseguiu esse projeto através de licitação, onde o problema irá ocorrer e você não poderá simplesmente virar as costas e abandonar o barco.

Aí infelizmente, somos obrigados a usar a documentação como arma. Não estou dizendo que apoio a prática, nem que ela é ideal, e nem que isso presta. É mesmo uma constatação triste. E triste também (para mim) foi eu já ter passado por isso, mais de uma vez, no passado.

This message was edited 1 time. Last update was at 12/05/2008 10:06:58

Taz wrote:

rodrigoy wrote:
Taz, o Kent Beck não faz diferença entre uma história e um caso de uso.

Ele fala que são iguais? Referências?

Beck (Extreme Programming Explained, 2nd Edition wrote:
Ivar Jacobson, Magnus Christerson, Parik Jonsson, and Gunnar Overgaard , Object-Oriented Software Engineering: A Case Driven Approach, Addison-Wesley, 1992; ISBN 0201544350.
My source for driving development from stories (use cases).

O ponto é que a formalidade do Use Case pode variar. O Cockburn diz o mesmo. Como disse, caso de uso é um conceito muito mais antigo que a UML. Sou fã do Jacobson por essa contribuição dele. Caso de uso é muito mais uma ferramenta de gestão do que especificação de requisitos.

ViniGodoy wrote:Tente implementar um sistema onde há conflitos de interesses entre os setores e você vai perceber o que estou falando. E não precisa ser um sistema grande. Aliás, na prática, nada funciona quanto há esse tipo de conflito.

A solução para esse tipo de problema no Scrum é o Product Owner. O Product Owner deve ter a palavra final. Minha visão é que o Product Owner deve ser um de$graçado ganancio$o. Se você focar em obter ROI do projeto muitas besteiras caem por terra.