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.
[quote=ViniGodoy]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. [/quote]
Agile só funciona para projetos pequenos -> MITO
[quote=dedejava]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.[/quote]
Respondendo:
só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…
[quote=Taz]
só vi perda de tempo em dinheiro usando Casos de Usos, mesmo em projetos grandes. Prefiro algo mais “Feature Driven”…[/quote]
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.
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.
[quote=Taz]
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. [/quote]
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.
[quote=dedejava]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.[/quote]
Tirando o titulo engenheiro 8), 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ó.
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.
Ele fala que são iguais? Referências?
[quote=rodrigoy]
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.[/quote]
IMHO, essa é a resposta: eu e minha equipe usaremos o que acharmos melhor. 
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.
[quote=ViniGodoy]
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.[/quote]
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.
[quote=Taz][quote=rodrigoy]
Taz, o Kent Beck não faz diferença entre uma história e um caso de uso.
[/quote]
Ele fala que são iguais? Referências?
[/quote]
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.
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.
acho besteira usar estes diagramas em projetos muito pequenos e não extenciveis ou pouco extenciveis mas acho primordial usar em projetos grandes e extenciveis… trabalho em um projeto gigantesco que a muito pouco diagramas… e isto as vezes gera confusões, dificuldade de entendimento de processos e do funcionamento de certas funções e duplicidade de algumas classes… pois é imprecendivel um diagrama de Caso de Uso para entender como determinado escopo do sistema vai interagir e quem são os atores e suas ações… isto faz com que vc entenda o sistema… e tbm é importante diagramas de classes por varias coisas como evitar classes duplicadas… qdo a um projeto de uns 30 programadores e varios recebem uma tarefa sobre o mesmo modulo concorrentemente… sem um diagrama de classe e uma ordem a fazer as coisas fica realmente uma bagunça o projeto… e tbm tal diagrama facilita a compreensão da interação dos objetos no sistema… porem é algo muito custoso para ser implementado em sistemas pequenos ou com poucos desenvolvedores envolvidos… mas em grandes sistemas o esforço compensa… mas um diagrama que acho que não deveria faltar em CRUD nenhum é o diagrama de ER (entidade relacionamento) em um crud seu interagir com o banco é muito frequente… se vc não souber a estrutura do banco não tem como fazer nada…
Ok. Vamos analisar as duas referências que ele faz a “use cases” no livro dele. Já as referências a “stories” são incontáveis.
[quote]Referência 1 (Capítulo 7):
Feedback also works at the scale of weeks and months. The customers and testers write
functional tests for all the stories (think “simplified use cases”) implemented by the system.
[/quote]
[quote]Referência 2 (Bibliografia):
Ivar Jacobson, Object-Oriented Software Engineering: A Case Driven Approach, Addison-
Wesley, 1992; ISBN 0201544350.
My source for driving development from stories (use cases).
[/quote]
Entendo que as duas referências que ele faz são meramente com a finalidade de orientar o leitor sobre o conceito de “stories” e não de afirmar que stories = use cases. Aliás, se vc analisar a primeira, pode interpretar como uma crítica o “think simplified use cases”. Obviamente, aqui ele refere-se ao rigor formalista da técnica.
Sem querer desmerecer o Jacobson (e concordo com vc que ele criou um método bastante interessante para lidar com requisitos), mas ele mesmo admite que foi mal-compreendido pelas pessoas que tentavam aplicar a técnica. Além disso, outros agilistas como Scott Ambler “descem a lenha” em Use Cases.
Resumo: stories != use cases
[quote=Taz]
Entendo que as duas referências que ele faz são meramente com a finalidade de orientar o leitor sobre o conceito de “stories” e não de afirmar que stories = use cases. [/quote]
Taz, como você sabe, o mercado tem uma força enorme de deturpar as coisas. A idéia é a mesma, porém, a forma que é utilizado no mercado é que é diferente. Você poderia dizer que stories != formal use cases. Aí sim eu concordaria. Determinadas histórias podem requerer uma formalidade maior. Sim, o Beck critica o modo formal.
Ele diz isso com relação ao UP como um todo não com a técnica de use cases especificamente. Ele se vangloria bastante dos use cases ser a técnica a mais utilizada no mundo.
O Ambler não gosta de Use Case-Driven e não dos casos de uso em geral. Mesmo que você não faça diagramas, mesmo que não escreva nenhum texto os casos de uso vão continuar a existir. Nenhum sistema funciona sem estímulos externos e execução atômica de procedimentos.
De qualquer forma essa discussãozinha é pouco produtiva. Só quero que vc entenda que casos de uso não precisam ser formais. Falo muito sobre isso em meus cursos.
extenciveis? imprecendivel? Não seria extensíveis? imprescindível? Ia perder fácil no programa do Luciano Hulk. 
Tirando a brincadeira de lado, não concordo com a sua opinião. Baseia-se numa visão estreita de mundo em que só existem duas opções possíveis e antagônicas, de um lado o desenvolvimento caótico e problemático (mau), de outro o desenvolvimento burocrático e previsível (bom).
Não vai demorar muito e você vai perceber que existem mais coisas entre o céu e a terra do que sonha sua vã filosofia. Exemplo 1: documentação em excesso não garante qualidade. Exemplo 2: waterfall não garante programas extensíveis. Exemplo 3: deixar os testes no final é garantia de que eles não serão feitos adequadamente. E por aí vai.
Sinceramente, a discussão está interessante, mas acho que estamos discutindo o sexo dos anjos.
Primeiro, porque nenhum modelo propõe-se a ser 100% formal. Especialmente se tratando da especificação de Use Cases. Isto é, na maior parte dos processos (incluindo o Processo Unificado), o documento que dá o formato de um Use Case pode ser tão simples quanto uma história, e nem precisa ser tão formal quanto o proposto pelo Cockburn - embora processos formais geralmente considerem isso aconselhavel, esse modelo não é imposto.
Da mesma forma, as práticas ágeis dão sempre a flexibilidade da equipe de desenvolvimento utilizar um método mais formal, se isso for mais adequado. É o que fazemos aqui, quando lidamos com clientes de outros países. Mas, no caso do desenvolvimento ágil, a orientação geral é simplificar. Ou seja, o aconselhável aqui é ir no sentido oposto e obter um processo simples.
Acho que essa é a lição importante de ambos os processos.
Dizer simplesmente “use cases são histórias” é uma simplificação perigosa. Mas também afirmar que “use cases não são histórias” é uma generalização incorreta.