UML - Diagrama de Sequência - Cadastrar Produtos

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

Fala Rodrigo olhando o caso de uso que você reescreveu me surgiu algumas dúvidas

rodrigoy wrote:
Fluxo Principal
- O Ator seleciona a opção de cadastrar o produto [A1];

...

Fluxo Alternativos
[A1] - Pesquisar produto

Pesquisar produto é um fluxo alternativo de cadastrar produto?

rodrigoy wrote:
Fluxo Principal
- O Ator seleciona a opção de cadastrar o produto [A1];
- O Sistema abre uma nova tela de cadastro de produtos;
- [P1] O Ator entra com os dados do produto;
- O Sistema cadastra o produto;

Fluxo Alternativos
[A1] - Pesquisar produto
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto. Volta para o passo P1 [A2]

No fluxo alternativo [A1] ele pesquisa e encontra um produto!(Sinal que ele esta cadastrado). Se ele já esta cadastrado porque volta ao passo [P1] entra com os dados e logo em seguida cadastra denovo?

[]s Valews pela ajuda

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

gafanha wrote:Comentários de quem tá començando também ....

1. O título do caso de uso não deveria ser o objetivo do ator principal ? E não deveria conter um verbo ?

2. Um CRUD sem nenhum fator de complexidade deveria mesmo ser detalhado neste nível ? Com diagrama de sequencia e tudo mais ? Ou bastaria a narrativa do caso de uso utilizando o escopo do usuário.

2.1 Se o cadastro de produto tivesse alguma interação com entidades de estoque ou alimentasse contadores se justificaria o detalhamento. Estou certo ?

3. É correto criar os casos de uso com a implementação já pronta na cabeça ? Ou deveríamos somente concentrar-nos no que domínio nos diz ?

Perguntas bem colocadas.

1 - Sim. O título do caso de Uso deve expressar a META do usuário ao utilizar o sistema. No caso aqui, eu preferiria utilizar "Manter Produto".

2 - Há controvérsias. Se vc usa RUP, provavelmente seria obrigado a fazer todo o detalhamento exigido pelo template. O XP seria mais flexível e, pra falar a verdade, utilizaria Story Cases no lugar dos Casos de Usos.

2.1 - Talvez não. Para que vc utiliza os contadores? Para atender outra funcionalidade do usuário? Por outro lado, se, por exemplo, uma inserção de um Produto dispara um e-mail para o Almoxarifado, isso deveria estar descrito no Caso de Uso e no Diagrama de Sequência.

3 - Não entendi. Explique com um exemplo.

brunohansen wrote:Fala Rodrigo olhando o caso de uso que você reescreveu me surgiu algumas dúvidas

Bruno, esse templatezinho que tenho instruído o pessoal é algumas adaptações que fiz na maneira que o Cockburn descreve no livrro Writting Eff. Use Cases.

Para falar a verdade, no fluxo [A1] faltou um primeiro passo:
- O Ator informa que deseja buscar um produto;
(Acho que isso vai dar mais sentido)

O caso de uso possui um fluxo básico, é a maneira mais comum do ator atingir o objetivo. Dessa maneira comum, surgem jeitos alternativos do ator atingir o objetivo ou por alguma razão o objetivo não pode ser alcançado.

A leitura do caso de uso nos diz que onde no fluxo básico [A1] ocorre. Isso facilita a decomposição de cenários que podem ser os seus Casos de Teste. O que chamamos de cenário 0 (zero) é o próprio fluxo básico:

- O Ator seleciona a opção de cadastrar o produto;
- O Sistema abre uma nova tela de cadastro de produtos;
- O Ator entra com os dados do produto;
- O Sistema cadastra o produto;

Como temos um fluxo alternativo, temos o cenário 1 (pesquisar produto):

- O Ator informa que deseja buscar um produto; (o passo que esqueçí)
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto.
- O Ator entra com os dados do produto;
- O Sistema cadastra o produto;

No fluxo alternativo [A2] que ocorre dentro de [A1], temos mais um cenário (remover produto):

- O Ator informa que deseja buscar um produto; (o passo que esqueçí)
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto;
? O Ator informa que deseja remover o produto;
? O Sistema remove o produto.

A indicação do ponto onde ocorre o fluxo alternativo é importante para a decomposição de cenários de maneira quase automatizada (algumas ferramentas ajudam nessa tarefa).

A lição 4 do curso on-line grátis da ASPERCOM explica isso melhor...

OK?

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

rodrigoy wrote:
Fluxo Principal
- O Ator seleciona a opção de cadastrar o produto [A1];
- O Sistema abre uma nova tela de cadastro de produtos;
- [P1] O Ator entra com os dados do produto;
- O Sistema cadastra o produto;

Fluxo Alternativos
[A1] - Pesquisar produto
- O Sistema abre uma tela de pesquisa de produtos;
- O Ator informa os dados de busca;
- O Sistema mostra os produtos encontrados;
- O Ator seleciona um produto. Volta para o passo P1 [A2]

[A2] - Remover produto
? O Ator informa que deseja remover o produto;
? O Sistema remove o produto. (não é o ator que remove, é o sistema)

Tudo o que foi dito aqui ficaria melhor representado com protótipos de telas e um diagrama que ilustre a navegação entre elas. Isso seria:

- Mais prático (ajuda o programador/web designer)
- Mais fácil (evita discussões relacionadas a estilos pessoais de escrita)
- Mais rápido
- Mais intuitivo (utiliza imagens em vez de linguagem escrita)

Exato, é a eterna questão do CRUD Use Cases, sobre sua aplicabilidade ou não. Foi o que falei no post abaixo:

http://www.guj.com.br/posts/preList/37595/202235.java#202235

Usei esse post mais para demonstrar a técnica.

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

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.

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!

[]s

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:

FEAT 331: Permitir o cadastro de produtos;
http://www.agilemodeling.com/essays/fdd.htm

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...

OK?

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

rodrigoy wrote: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.

Não intendi o que você quis passar você poderia detalhar um pouco mais para mim?

De qualquer forma eu prometo ler [Ambler] um dia...

brunohansen wrote:

....
1.1.2 O Ator informa os dados de busca;
1.1.3 Sistema mostra os produtos encontrados;

....
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;

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".

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

Ahh tá!!!

A parte de eventos fui eu que coloquei mesmo so para explicitar aqui no post ela realmente não faz parte...

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

rodrigoy wrote:

Vou repetir o meu lema: Bom senso... o desenvolvimento de sistemas se baseia em bom senso...

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".

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

Bom dia Rodrigo, Taz!

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.

rodrigoy wrote:
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:

FEAT 331: Permitir o cadastro de produtos;
http://www.agilemodeling.com/essays/fdd.htm

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).

Taz wrote:
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".

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]

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

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?

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.

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.

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í...

JavaEvangelist Membro desde: 27/03/2006 11:11:34 Mensagens: 391 Offline

Taz wrote:
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í...

Concordo plenamente!

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

GUJ Ranger Membro desde: 02/06/2005 16:28:38 Mensagens: 939 Offline

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

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.

Notícias, artigos e o maior fórum brasileiro sobre Java