UML - Diagrama de Sequência - Cadastrar Produtos  XML
Índice dos Fóruns » Arquitetura de Sistemas
Autor Mensagem
wellington_arantes
HelloWorld

Membro desde: 31/07/2006 10:09:43
Mensagens: 11
Offline

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...
[Thumb - DiagramadeSequênciaCadastrar.png]
 Nome do arquivo DiagramadeSequênciaCadastrar.png [Disk] Download
 Descrição Diagrama de Sequência - Cadastrar Produto...
 Tamanho 28 Kbytes
 Baixado:  7536 vez(es)

[MSN]
rodrigoy
GUJ Ranger
[Avatar]

Membro desde: 18/04/2006 01:06:28
Mensagens: 758
Localização: São Paulo
Offline

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.



Rodrigo Yoshima
www.ASPERCOM.com.br

Próximas Turmas:
São Paulo: Scrum 28/agosto | OOAD-UML 13/setembro

Débito Técnico Blog: blog.aspercom.com.br
[WWW]
wellington_arantes
HelloWorld

Membro desde: 31/07/2006 10:09:43
Mensagens: 11
Offline

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!!
[Thumb - CasoDeUso.png]
 Nome do arquivo CasoDeUso.png [Disk] Download
 Descrição Caso de Uso- Basico
 Tamanho 4 Kbytes
 Baixado:  1127 vez(es)

[MSN]
rodrigoy
GUJ Ranger
[Avatar]

Membro desde: 18/04/2006 01:06:28
Mensagens: 758
Localização: São Paulo
Offline

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?

Rodrigo Yoshima
www.ASPERCOM.com.br

Próximas Turmas:
São Paulo: Scrum 28/agosto | OOAD-UML 13/setembro

Débito Técnico Blog: blog.aspercom.com.br
[WWW]
wellington_arantes
HelloWorld

Membro desde: 31/07/2006 10:09:43
Mensagens: 11
Offline

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 <<Control>> 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"
 Nome do arquivo Produtos.doc [Disk] Download
 Descrição Descrição do caso de Uso Produtos
 Tamanho 34 Kbytes
 Baixado:  1579 vez(es)

[MSN]
rodrigoy
GUJ Ranger
[Avatar]

Membro desde: 18/04/2006 01:06:28
Mensagens: 758
Localização: São Paulo
Offline

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?

Rodrigo Yoshima
www.ASPERCOM.com.br

Próximas Turmas:
São Paulo: Scrum 28/agosto | OOAD-UML 13/setembro

Débito Técnico Blog: blog.aspercom.com.br
[WWW]
wellington_arantes
HelloWorld

Membro desde: 31/07/2006 10:09:43
Mensagens: 11
Offline

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+
[MSN]
rodrigoy
GUJ Ranger
[Avatar]

Membro desde: 18/04/2006 01:06:28
Mensagens: 758
Localização: São Paulo
Offline

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?

Rodrigo Yoshima
www.ASPERCOM.com.br

Próximas Turmas:
São Paulo: Scrum 28/agosto | OOAD-UML 13/setembro

Débito Técnico Blog: blog.aspercom.com.br
[WWW]
wellington_arantes
HelloWorld

Membro desde: 31/07/2006 10:09:43
Mensagens: 11
Offline

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!!!!
[MSN]
rodrigoy
GUJ Ranger
[Avatar]

Membro desde: 18/04/2006 01:06:28
Mensagens: 758
Localização: São Paulo
Offline

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


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



Rodrigo Yoshima
www.ASPERCOM.com.br

Próximas Turmas:
São Paulo: Scrum 28/agosto | OOAD-UML 13/setembro

Débito Técnico Blog: blog.aspercom.com.br
[WWW]
wellington_arantes
HelloWorld

Membro desde: 31/07/2006 10:09:43
Mensagens: 11
Offline

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!!
[MSN]
Heero
JavaChild
[Avatar]

Membro desde: 14/06/2003 00:20:01
Mensagens: 139
Offline

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-
Rodrigoy wrote:o diagrama de sequência não precisa ter todos os detalhes.


oazuc :http://www.guj.com.br/posts/list/37595.java wrote:Partindo desse pressuposto, e respondendo à sua pergunta, sim: precisa de mais detalhes no seu diagrama.


pcalcado :http://www.guj.com.br/posts/list/37595.java wrote:Quanto aos seus diagramas, eles estão, digamos, 'alto nível demais', tente fazer algo mais próximo da implementação física (o tal 'projeto de software').



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--
[Email] [MSN]
rodrigoy
GUJ Ranger
[Avatar]

Membro desde: 18/04/2006 01:06:28
Mensagens: 758
Localização: São Paulo
Offline

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

Rodrigo Yoshima
www.ASPERCOM.com.br

Próximas Turmas:
São Paulo: Scrum 28/agosto | OOAD-UML 13/setembro

Débito Técnico Blog: blog.aspercom.com.br
[WWW]
Luca
Moderador
[Avatar]

Membro desde: 06/09/2002 14:30:10
Mensagens: 5818
Localização: São Paulo/SP ou Paraty/RJ
Offline

Olá

wellington_arantes wrote:Muito obrigado novamente cara!!!
Valeu muito!!


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

[]s
Luca

Dare Obasanjo (Program Manager at Microsoft)
"The folks I know from across the industry who have to build large scale Web services on the Web today at Google, Yahoo!, Facebook, Windows Live, Amazon, etc are using RESTful Web services. The only times I encounter someone with good things to say about WS-* is if it is their job to pimp these technologies or they have already "invested" in WS-* and want to defend that investment."


CEP, JMS, JMX e coisas afins (ou não)
http://lucabastos.blogspot.com/
[Email] [WWW]
gafanha
Debugger
[Avatar]

Membro desde: 02/05/2006 20:33:13
Mensagens: 58
Localização: Itatiba - SP
Offline

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 ?

Douglas M dos Santos
 
Índice dos Fóruns » Arquitetura de Sistemas
Ir para:   
Powered by JForum 2.1.8 © JForum Team