[quote=sergiotaborda]
Leia o artigo do Rodrigo Yoshima na Mundo Java para mais detalhes de porque UML não é uma documentação e porque não se deve abusar de Casos de Uso. [/quote]
Está disponível para download este artigo:
[quote=sergiotaborda]
Leia o artigo do Rodrigo Yoshima na Mundo Java para mais detalhes de porque UML não é uma documentação e porque não se deve abusar de Casos de Uso. [/quote]
Está disponível para download este artigo:
Não vejo diferença entre uma Storie e um Caso de Uso. A motivação de ambos é a mesma coisa. Quando falamos “usar caso de uso” é simplesmente especificar um software sob o ponto de vista do usuário. Alguma diferença com relação à User Stories?
Use Case é um conceito que existe mesmo você não se importando que eles existam.
[quote=rodrigoy]Não vejo diferença entre uma Storie e um Caso de Uso. A motivação de ambos é a mesma coisa. Quando falamos “usar caso de uso” é simplesmente especificar um software sob o ponto de vista do usuário. Alguma diferença com relação à User Stories?
Use Case é um conceito que existe mesmo você não se importando que eles existam.
[/quote]
Mesmo sendo essa diferenca irrelevante para a discussao atual eu tentei mas nao consegui entender o seu ponto. Sao conceitos iguais porque suas motivacoes sao iguais? É isso?
Vc colocou que equipes ágeis não usam casos de uso. Se você partir da premissa que a raiz da técnica de User Stories são as práticas do Jacobson (Use Cases), TODAS AS EQUIPES ÁGEIS usam casos de uso. Agora especificação formal de casos de uso algumas equipes ágeis não usam.
Só isso… sei que vc está no calor da discussão… deixa eu ficar quietinho aqui senão vai sobrar porrada pra mim também… pode continuar sua acalorada discussão com o Sergio…
“É um absurdo total não querer entender a UML e pior ainda querer desmerecer Use Case, ou levantamento de requisitos.”
Vejo em tudo requisitos, aliás não se pode imaginar entender serviços em arquitetura J2EE, JEE, SpringFrameWork, .NET onde tudo passa a ter contexto ou qualquer melhor significado tecnologico por decisões de requisitos ao sistema e por os mesmo serem compativeis ao interesses por sua arquitetura ou não.
Até por analise de ponto de função ter o uso de uma linguagem que seja melhor aderente ao tempo de projeto, e por ai vai., o que me transfere um requisito por optar por um outra solução.
Estão querendo desmerecer uma matéria onde a Analise de Requisitos que permite o melhor estudo possivel de viabilidade para senão a melhor adequação de artefatos de sistemas,e implementa-las posteriormente a uso da OO e Design Patterns desejáveis.
[quote=rodrigoy]
Só isso… sei que vc está no calor da discussão… deixa eu ficar quietinho aqui senão vai sobrar porrada pra mim também… pode continuar sua acalorada discussão com o Sergio… [/quote]
Minha nao, sou da paz! 8)
Além do mais eu ja desisti de tentar convencer o Sergio que UML ´e no maximo documentacao.
Mas se nao for capaz de ater-se ao tema do topico sua decisão não é de todo ruim. :thumbup:
[quote=cmoscoso][quote=rodrigoy]
Só isso… sei que vc está no calor da discussão… deixa eu ficar quietinho aqui senão vai sobrar porrada pra mim também… pode continuar sua acalorada discussão com o Sergio… [/quote]
Minha nao, sou da paz! 8)
Além do mais eu ja desisti de tentar convencer o Sergio que UML ´e no maximo documentacao.
[/quote]
Ah! era isso que estava tentando ? … quem diria…
Eu achei que vc estava falando de levantamento de requisitos , sua relação com o desenvolvimento e tentando constestar que
Casos de Uso não são formas de capturar requisitos…
… afinal foi tudo perda de tempo.
Acho que vcs todos nao sabem nada, tudo uns ,muleke que no maximo programou uns CRUDzinho. A unica pessoa que falou algo com sentido aki foi o Marcio Duran
:thumbup: [size=24]Thank you !!![/size]