UML - Diagrama de Sequência - Cadastrar Produtos

Programação Arquitetura
#1

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…

2006/7/31/cc5b34e5ecfdc17ab6bbfc508fd4b71e_11684.png1144×1083 27.7 KB

#2

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.

#3

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

#4

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?

#5

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”

#6

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?

#7

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+

#8

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?

#9

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

#10

[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…

#11

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

#12

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

#13

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…

#14

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

#15

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 ?
#16

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

#17

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

#18

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?

#19

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:

#20

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.