Rodrigo tomei a liberdade de editar seu caso de uso! Derrepente você olhando as diferenças você consegue intender minhas dúvidas.
Tambem li [Cockburn] Writting Eff. Use Cases. Acho que uma troca de ideia vai ser de grande valia pelos menos para mim.
Caso de Uso: CRUD Produto
Fluxo básico
1 O Ator solicita o cadastro de um produto; 2 O Sistema sistema possibilita que o ator entre com os dados do produto; (Não acho legal mencionar interface)
3 O Ator entra com os dados do produto;
4 O Sistema cadastra o produto;
Fluxos alternativos
1.1 Ator solicita a alteração de um produto
1.1.1 Sistema possibilita que o ator pesquise o produto a ser alterado;
1.1.2 O Ator informa os dados de busca;
1.1.3 Sistema mostra os produtos encontrados;
1.1.4 O Ator seleciona um produto.
1.1.5 O Ator entra com novos dados do produto; 1.1.6 O Sistema altera o produto;(Se o produsto já esta no sistema sinal que ele ja esta cadastrado, então ele não deseja cadastrar mas sim alterar)
1.2 Ator solicita a exclusão de um produto
1.2.1 Sistema possibilita que o ator pesquise o produto a ser excluido;
1.2.2 O Ator informa os dados de busca;
1.2.3 Sistema mostra os produtos encontrados;
1.2.4 O Ator seleciona um produto a ser excluido;
1.2.5 O sistema exclui produto.
[b] Eventos que façam com que ocorram fluxos alternativos:
1.1 Ator solicita a alteração de um produto
1.2 Ator solicita a exclusão de um produto
Existem outros ainda por simplicidade não os coloquei!
[/b]
Se esse é a sua versão definitiva, na minha opinião, não gosto de numerar. Outro ponto, você está descrevendo cenários e não casos de uso. Note que seus “fluxos alternativos” são um exemplo de utilização completa.
Bom, Bruno, casos de uso possuem diversos estilos de escrita. Isso varia de projeto para projeto. Atualmente estou usando Casos de Uso mais para mapear objetivos “de grande valia” para o usuário, isto é, CRUD estão fora. Para cruds não uso nem protótipo de tela e nem diagrama de navegação (como o Taz falou). Um simples texto numa lista de requisitos é suficiente:
Razão: CRUD possui um risco tão baixo que não vale a pena. Caso de Uso é uma boa ferramenta para mapear objetivos que são arriscados para o projeto. Possivelmente esses objetivos terão um caso de teste derivado do caso de uso que valide esse objetivo. Além disso, esses casos de uso são os que realmente necessitam de uma investigação mais aprofundada em análise e arquitetura (aí é que entra mais UML).
Vou repetir o meu lema: Bom senso… o desenvolvimento de sistemas se baseia em bom senso…
De qualquer modo, nesse tópico, evoluí a discussão mais para elucidar a aplicação da técnica para quem está começando…
[quote=rodrigoy]Outro ponto, você está descrevendo cenários e não casos de uso. Note que seus “fluxos alternativos” são um exemplo de utilização completa.
[/quote]
Não intendi o que você quis passar você poderia detalhar um pouco mais para mim?
Você não acha que a busca de produtos seria a mesma tanto para alterar quanto para excluir? Mas isso é só um detalhe. Aquela parte dos “eventos” também não é “tradicional”.
Difícil encontrar isso por aí. O pessoal de “qualidade” interpreta mal o RUP e quer obrigar os desenvolvedores a usar “templates” para que eles não se “desviem para o lado negro da força”. Se faltar uma vírgula, o Caso de Uso precisa ser revisto. Imagina se faltarem alguns Casos de Usos de alguns CRUDizinhos ali, aí a “casa cai”. :roll:
Hoje pela parte da manhã um amigo meu de trabalho me disse que leu o tópico e ficou com algumas dúvidas! Geradas pelas partes citadas abaixo.
Meu amigo chegou até a mim hoje de manhã e disse mais ou menos assim:
-Bruno estou preocupado estive lendo o tópico ao qual você estava discutindo sobre casos de uso. E vi que as pessoas raramente fazem casos para as coisas que nós estamos fazendo, algumas pessoas fazem somente prototipos de interface e diagramas de navegação, outros nem ao menos o fazem.
-Porque mesmo Bruno que estamos fazendo estes casos de uso?
Eu respondi:
-Bom hoje estamos trabalhando em uma equipe que ainda não conseguiu alcançar um nivel bom de conhecimento do dominio ao qual nosso projeto esta relacionado.
-Se eu fosse adotar a premissa que todos da equipe tem um bom conhecimento como eu e você e decidi-se por não fazer os casos de uso, na hora do projeto e implementação veriamos que esta faltando conhecimento de dominio para que essas disciplinas sejam feitas.
-Eu acho realmente importante que agente se prenda explicitar alguns poucos detalhes que o cliente exigiu, para que amanhã não entregamos o produto errado.
-Afinal de contas existem regras e detalhes que são realmente muito importante para o nosso cliente como: Um agendamento não pode sobrescrever o outro. Este é um exemplo de detalhe que o nosso cliente exige e ainda esta muito subjetivo na cabeça da nossa equipe.
The end! hehehe
Convenci meu amigo de equipe, mas será que essa é realmente a melhor forma de resolver meu problema? (Todos temos medo de deixar escapar o mesmo bom senso que todos almejam)
[Editado]
Agorinha meu gerente do setor me veio pedir para eu detalhar o Caso de uso Administra Estrutura Logica do Sistema. E ainda explicitou faz na forma de adicionar, remover e alterar nó do sistema !!Nada mais que isso!! Tudo para não gastar tempo!
Ai eu fico pensando sera que é realmente válido ser subjetivo assim? Tratar qualquer coisa como um nó? 90% da equipe não tem ideia de que um nó pode representar no sistema e de como as diferenças entre nó vai influenciar na sua administração!
Acho um risco muito alto ser muito subjetivo!
Acho que ter bom senso não é ser subjetivo!
[/Editado]
Esse tipo de questionamento é ótimo e é ele que realmente leva a desenvolver software de qualidade. Traduzindo:
Pq estamos fazendo da maneira X? A maneira X tem se mostrado útil?
Quantas vezes os artefatos gerados pela maneira X foram requisitadas em outras iterações do projeto?
Vale a pena desperdiçar recursos construindo artefatos da maneira X? Não podemos melhorar, fazendo da maneira Y?
Perceba quanto tempo já gastamos falando sobre estilos de escrita de um bom Caso de Uso (maneira X). Veja bem, não estou dizendo que vc deve abolir Casos de Uso do seu projeto. Estou recomendando que use-os apenas nos lugares onde eles são mais apropriados.
Se vc precisa deixar documentado de alguma maneira que um agendamento não pode sobrescrever outro, vc poderia descrever claramente isso, da seguinte forma (maneira Y):
Requisitos
Agendamento
AG01 - Agendamentos não podem ser sobrescritos. Caso haja uma tentativa de sobrescrição o sistema apresenta a mensagem “Agendamento já realizado para a Data XX/XX/XXXX e para o Recurso XXXXX”
AG02 - …
AG03 - …
Simples, objetivo, rápido, barato e efetivo.
Se X é melhor e mais efetivo que Y, a equipe dirá, e não o cara da qualidade que nunca sequer programou uma linha de código em Java e que não passa noites a fio durante a implantação do projeto.
Veja a história: como a indústria japanesa, hoje, consegue fabricar carros de melhor qualidade que a indústria americana? Eles conseguiram criar uma cultura onde os próprios funcionários eram estimulados a melhorar a qualidade do produto final. Como eles poderiam contribuir? Melhorando o processo de montagem. Dessa maneira, quando qq funcionário detectasse um problema na linha e sugerisse uma melhoria, era papel da Área de Qualidade analisar a viabilidade de se implantar essas melhorias e de , caso dessem certo, institucionalizá-las. Essa é a base do CMMI.
A questão final é: como vc vai estimular os desenvolvedores a darem opinião sobre o processo de desenvolvimento? Obrigando-os a preencher templates de documentos!? Sinceramente, acho q não é por aí…
Mas tem horas que templates são uteis! Pena que a utilidade não é tão visivel assim na prática.
Ex.:
1- Você manda o cara implementar algo sem nem ao mesmo ter conhecimento do dominio! A implementação dele mela.
2-VocÊ manda o cara fazer um caso de uso seguindo um template a partir dai ele obtem um conhecimento bom do dominio e faz um implementa ção boa! O problema que esse cara fica com a visão po eu já sabia tudo eu não precisava daqueles chatos casos de usos. Esse cara não se da conta que foi o caso de uso que gerou o conhecimento de dominio para que ele fizese uma boa implementação. Não podemos nos tornar um pre-conceituosos em relação a casos de uso… Será que não tem horas que eles são realmente importante? Acho que eles são importante sim… so que não nos damos conta disso
[quote]
Será que não tem horas que eles são realmente importante? Acho que eles são importante sim… so que não nos damos conta disso[/quote]
O que é mais importante em qualquer projeto é sua SIMPLICIDADE e a CUMPLICIDADE das pessoas que o conduzem. Se vc não conseguir essas duas coisas, Casos de Usos não vão levá-lo ao sucesso.
[quote=Taz][quote]
Será que não tem horas que eles são realmente importante? Acho que eles são importante sim… so que não nos damos conta disso[/quote]
O que é mais importante em qualquer projeto é sua SIMPLICIDADE e a CUMPLICIDADE das pessoas que o conduzem. Se vc não conseguir essas duas coisas, Casos de Usos não vão levá-lo ao sucesso. [/quote]
Como diria meu Professor de Administração de Empresas tudo se resume em Sinergia! E realmente é verdade.
Oi pessoal
Estou modelando meu sistema de trabalho de conclusão de curso, é um sistema de hotelaria, mas estou com dificuldades no diagrama de sequencia. Pois a primeira parte é de Gerar Hospedagem, ou seja, cadastrar, excluir, alterar…Mas como coloco isso no diagrama de sequencia???
