UML - Diagrama de Sequência - Cadastrar Produtos

Galera,

meu Brother "Heero" e eu estamos desenvolvendo um sistema para uma loja e estamos começando...estamos com dificuldades como todo mundo encontra em projetos, mas vamos em frente e lutando sempre...

Definimos primeiro os cadastros…e fizemos os casos de uso e agora queremos fazer o diagrama de sequência para fazer um detalhamento de cada cenário…

O diagrama de estou postando e de Cadastrar Produto…não sei ao certo se está tudo OK…

O cenario é o seguite:
1- o ator click em novo o sistema libera os campos para preencher os dados
2- informa a descrição
3- informa o grupo de produtos
4- informa o sub grupo de produtos
5- informa o fornecedor
6 -informa a unidade
7 - click no botão confirmar e o método cadastrar é invocado

Falem o que quiserem, OK!

Tentei fazer o maximo de detalhamento possível…

Obrigado…


Seu diagrama aparenta estar OK, mas o diagrama de sequência não precisa ter todos os detalhes. Os diagramas de interação servem para alocar responsabilidades aos participantes, não são uma boa ferramenta para modelar o comportamento interno da classe.

Só estou achando estranho você conseguir obter uma entidade logo a partir do seu construtor. Geralmente essa pergunta é feita para um repository e não para a própria entidade. OK?

Se vc postar o caso de uso seria bom para complementar a minha opinião.

Rodrigoy,

eu tenho difuculdade com OO, pois trabalho com Delphi e estou mudando de tecnologia, no caso nós estamos querendo fazer o sistema em OO pelas vantagens tem.

penso assim:

1- tem o ator
2- tenho a interface que será implementada pela classe de controle onde a classe de controle será onde coloco minhas regras de negocio e as chamadas dos métodos das classe de entidade. “Não sei se estou certo.”

continuando… então quando quero utilizar o metodo cadastrar por exemplo:

da iterface chamo o método cadastrar que esta na classe de controle…
“para fazer essa chamada a esse metodo não é so instaciar um obj da classe de controle e chamar o metodo??”
e esse metodo da classe de controle é implementado pela classe Produto que tem o método cadastraProduto();

“Não sei se era isso que você perguntou mas é o que eu acho que sei…”

Segue o Caso de Uso eu não especifiquei muito so coloquei as operações basicas, OK!!!

Mais uma vez muito obrigado, cara!!

Welligton, tranquilo, todos estamos aqui para aprender… alguns comentários…

O caso de uso é o texto. O diagrama é só para ajudar. Tenho um artigo no curso online grátis que fala um pouco sobre caso de uso CRUD (apesar que geralmente caso de uso assim nem chega a existir). Quando falei sobre caso de uso é o texto que estava me referindo. Nesse post eu escreví um caso de uso simples:

http://www.guj.com.br/posts/list/37661.java#201019

Seu raciocínio está certo, mas geralmente um entity não consegue se criar a sí próprio (vixe). Geralmente temos um repository que serve para buscar entities (faça uma busca aqui no fórum que vc vai achar material, ou acesse o site do www.martinfowler.com, no catalogo de patterns). Este mesmo repository pode ter uma operação add(Entity) que cadastra.

Regras de negócio devem ao máximo serem alocadas aos entities e não para as classes de controle. Aliás, os stereotypes padrão da UML 2.0 são <<boundary>> , <<control>> e <<entity>>.

Você já tem o texto do caso de uso?

Sim eu tenho o descritivo…eu pensei que fosse o diagrama.

Obrigado pelas dicas…já entrei nesse site que você falou e ja cadastrei lá…depois vou ver como é esse curso…

Olhei o exemplo que você fez…nós também fizemos algo do tipo…vou postar para ver o que você acha, blz?

Outra coisa que eu fiquei “voando”, falei da classe de controle <> não é la que colocamos as regras de negocio e as chamadas dos métodos…não é tipo o “meio de campo entre a interface e a entidade”, voce deixa separado os metodos de uma classe e coloca as regras de negócio na controle???

então segue o descritivo do “caso de uso Produtos”

Não consigo baixar doc. cole o texto. O que falei é que devemos ao máximo alocar regras de negócio para entidades e não para as classes de controle.

OK?

Caso de Uso: Produtos

Ator Principal Gestor de Compras
Atores Secundários Gerente

Descrição
O Gestor de Compras pode cadastrar um novo produto, alterar, remover e pode pesquisar os dados do produto.

Fluxo Principal

  1. O Gestor seleciona a opção de cadastrar o produto.
  2. O sistema abre uma nova tela de cadastro de produtos
  3. O gestor pode cadastrar um produto.

Fluxo Alternativo

1 - Pesquisar produto:
1.1 – O sistema abre uma tela de pesquisa de produtos onde o usuário poderá informar o código ou o nome do produto.
1.2 - O sistema mostra os detalhes do produto encontrado.

2 - Novo produto:
2.1 - Apaga os campos que estão preenchidos.
2.2 - O sistema habilita os campos para que sejam preenchidos.
2.3 - O ator informa os dados do novo produto a ser cadastrado.

3 - Alterar produto:
3.1 - O sistema habilita os campos para que possam ser alterados.
3.2 - O ator altera os dados.
3.3 - O ator confirma as alterações no produto.

4 - Confirmar:
4.1 - O ator confirma o cadastro do novo produto.
“Produto cadastrado com sucesso”.

5 - Remover:
5.1 – O ator localiza o produto.
5.2 – O ator remove o produto.

6 - Cancelar:
6.1- O ator pode cancelar a operação de alteração e cadastro de um novo produto.

7 - Relatório:
7.1 – O ator pode imprimir relatórios dos produtos

8 - Sair:
8.1 - Quando o ator escolhe esta opção, o sistema sai da tela de cadastro de produtos e retorna para a tela principal.

Fluxo de Excepcional

1 - Produto não encontrado:
1.1 - Caso não seja encontrado nenhum produto, o sistema emite uma mensagem “Nenhum produto encontrado”.

2 – Código para pesquisa inválido
2.1 – Caso o código para pesquisa estiver vazio, o sistema emite uma mensagem “Favor preencher o campo código”.

3 – Produto não cadastrado
3.1 – Caso não seja possível cadastrar o produto, o sistema emite uma mensagem “Não foi possível cadastrar o produto”.

Obrigado pela toque das regras de negócio que coloca-se na entidade!!

Está aí o Descritivo…!! T+

Vamos dar só uma melhorada na leitura do seu UC. Prefira usar o termo ator no texto, se por alguma razão o ator mudar você não precisa alterar o texto todo.

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)

Você está detalhando demais o caso de uso. Determinados detalhes é melhor deixar a responsabilidade para o seu caprichoso programador (mensagens de quando não existe dados para mostrar como exemplo). Outros detalhes como o botão cancelar estarão num protótipo e o programador deverá se preocupar com isso também.

Caso de uso se foca no Ator e não no Sistema. Casos de uso são requisitos e não possuem detalhes de implementação (note que vc só tem uma elipse).

OK?

rodrigoy,
valeu pela explicação, agora posso focar mais na ação do ator. Nós detalhamos muito porque, esse projeto que heero e eu estamos desenvolvendo, nós vamos fazer toda parte de engenharia e a codificação também, esse é o motivo queriamos ter a visão da ação do ator e já pensando como o sistema funcionaria…mas valeu mesmo pelas dicas sempre pensar na posição de quem está usando o sistema…certo?
Mas você acha que só esta detalhado de mais, a estrutura de maneira geral está boa?
Vou fazer as alterações que você deu as dicas!!
O ator não faz é o sistema, olhei o vacilo que dei…

Então com relação ao diagrama de sequência partindo desse descritivo o que você acha??

Muito Obrigado pelo tempo e atenção!!!

[quote=wellington_arantes]rodrigoy,
valeu pela explicação, agora posso focar mais na ação do ator. Nós detalhamos muito porque, esse projeto que heero e eu estamos desenvolvendo, nós vamos fazer toda parte de engenharia e a codificação também, esse é o motivo queriamos ter a visão da ação do ator e já pensando como o sistema funcionaria…[/quote]

Acho que o seu diagrama de seq. está OK, só falei que não entendí a parte que a própria entidade retorna ela mesma. A interação diz como os componentes conversam para resolver o propósito do caso de uso. Aí sim você estará investigando o funcionamento interno do sistema.

O Caso de Uso é requisito. É O QUE o sistema tem que fazer, e não COMO ele faz, então, não precisa pensar em como ele funciona. Um protótipo ajuda a dar uma “cara” para o caso de uso e resolve muitos outros requisitos. Caso de Uso isoladamente não são suficientes para mapear todos os requisitos. Fórmulas e Cálculos também ficam fora do caso de uso.

Vc já pegou a idéia: O FOCO NO ATOR. O caso de uso resolve o que é importante para o Ator.

A estrutura do seu caso de uso está OK, fora os comentários que vc já entendeu…

Ah agora acho que sei explivcar o que fiz, a entidade retornar uma “valor”…

Vou tentar explicar o que pensei.

Na classe de entidade tem o método que retorna um boolean por exemplo.
A classe de controle faz a chamada do método que esta na entidade, o método é executado e retorna um boolean.

Pensei assim…

Na classe produtos terá um método cadastrar que se tudo ocorrer bem ele retorna true, para a classe de controle que retorna true para a interface e se precisar faz os tratamentos com o valor do retorno!!!

Muito obrigado novamente cara!!!
Valeu muito!!

também fasso parte desse projeto junto com meu brother camarada "wellington_arantes"
Gostaria de tirar certas dúvidas, das quais não consegui entender de maneira correta
se não for incomodo

1-

pelas citações acima, não consigo visualizar qual seria a melhor opção pra um cadastro de produtos, qual seria o ponto de equilibrio???
por que não fazemos um cadastro de produtos todos aqui envolvidos para o diagrama de sequencia, a gente fica falando, falando, falando
q tal fazermos na prática um ideal (com as entidades citadas por wellington_arantes)???
isso ajudaria várias outras pessoas q tivessem dúvidas, para não passarem a mesma dificuldades
poderíamos até deixar na wikipedia

grande abraço a todos

Heero, quando se fala no diagrama de sequência o mais comum é esse tipo de discussão. O que você precisa ter em mente é que o diagrama de sequência é um diagrama de interação, isto é, ele mostra como os componentes trocam mensagens para resolver um requisito (que geralmente é um caso de uso).

Essa resposta é você quem vai ter que investigar. Minhas dicas são: foque o diagrama na comunicação entre os componentes, se seu diagrama descobrir as operações public que resolvem a interação já está muito bom…

Não use o diagrama de sequência para demonstrar a implementação interna do componente. Só isso…

Olá

[quote=wellington_arantes]Muito obrigado novamente cara!!!
Valeu muito!![/quote]

Que tal dar umas 5 estrelinhas para o Rodrigo que está ajudando tanto a vocês?

[]s
Luca

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 ?

  1. É 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 ?

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

Pesquisar produto é um fluxo alternativo de cadastrar produto?

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

[quote=gafanha]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 ?

  1. É 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 ?[/quote]

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.

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?

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)

:wink:

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.