diagrama de sequencia - 3 (três) Camadas

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

Cadastrar

Alterar

Remover

"mvc" - model view controle
uma classe de controle, outra de negócios e outra de acesso aos dados
o que vcs acham desses diagramas?
inclementar mais alguma coisa?
padrão de nomes (métodos, mensagens, <<>>, etc) ???

faz um separado pra cadastrar, alterar, remover e consultar???

vamos trocar idéias, pra aprimorar o detalhento da uml no caso de diagrama de sequencia de 3 camadas

ps.: já olhei os tópicos de diagram de sequencia em 3 camadas no guj no guj

grande abraço a todos

Debugger Membro desde: 20/05/2006 15:59:44 Mensagens: 56 Offline

http://www.guj.com.br/posts/list/34800.java" target="_new" rel="nofollow"> http://www.guj.com.br/posts/list/34800.java

http://www.guj.com.br/forums/show/12.java" target="_new" rel="nofollow"> http://www.guj.com.br/forums/show/12.java

Debugger Membro desde: 20/05/2006 15:59:44 Mensagens: 56 Offline

http://www.guj.com.br/posts/list/35561.java

Não, MVC não tem haver com as camadas. MVC é um padrão arquitetural geralmente utilizado para clientes pesados tipo Swing.

http://www.martinfowler.com/eaaCatalog/modelViewController.html

Geralmente frameworks web usam frontcontroller:

http://www.martinfowler.com/eaaCatalog/frontController.html

View - Camada de Apresentação, só exibe os dados.

Model - Não é uma entidade do modelo de negócio propriamente dita, mas pode ser um façade que conversa com o modelo. Ligar diretamente a um entity não é uma boa prática. O Model geralmente mantém o estado da tarefa que o ator está efetuando no momento.

Controller - As ações da View precisam sensibilizar o model (ou um combo mudou ou o usuário quer salvar os dados) e para não deixar essas ações ligadas ao model diretamente, usamos um controlador.

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

'rodrigoy wrote:Não, MVC não tem haver com as camadas. MVC é um padrão arquitetural geralmente utilizado para clientes pesados tipo Swing.

eu acho que vc deva estar esquivocado:

http://www.macoratti.net/cshp_3c1.htm wrote:O modelo de três camadas fisícas ( 3-tier ) divide um aplicativo de modo que a lógica de negócio resida no meio das três camadas físicas. Isto é chamado de camada física intermediária ou camada física de negócios. A maior parte do código escrito reside na camada de apresentação e de negócio.

mas o q vcs pensam do diagrama?
soh meu alterar q fico na dúvida, será que tem alguma depêndencia?

grande abraço a todos

Heero, o Rodrigo está certo. um artigo com várias fontes bibliográficas:

http://fragmental.com.br/wiki/index.php?title=Arquitetura_de_Camadas_em_Java_EE

MVC diz como componentes, sejam camadas, objetos ou palitos de fósforo se comportam quando interagem, não diz como separar as coisas. Camadas dizem como separar um sistema agrupando componentes com responsabilidade em comum.

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

mas lembre-se de só criar diagramas que agreguem algum valor. Ter diagramas redundantes só por ter não é nada útil, a menos que você cobre por eles

Da uma olhada aqui:
http://java.sun.com/blueprints/patterns/MVC.html

Valeu? Até..

[]s

Apoio 100% o comentário do pcalcado:

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

mas lembre-se de só criar diagramas que agreguem algum valor. Ter diagramas redundantes só por ter não é nada útil, a menos que você cobre por eles

No diagrama de seqüência vá até o nível em que ele vá agregar algo ao seu projeto. Seja para desenhar uma solução que está um pouco mais complicada, ou para especificar a implementação de um caso de uso para a equipe de desenvolvimento.
Partindo desse pressuposto, e respondendo à sua pergunta, sim: precisa de mais detalhes no seu diagrama.

Att,
Leandro Ramos.

Não ao ponto de programar em UML! A idéia do modelo é só alocar responsabilidades aos componentes, sem se preocupar com o funcionamento interno deles (isso você resolve no código).

Os diagramas de interação da UML são usados para mostrar a colaboração de objetos e não o funcionamento interno dos participantes da interação.

[]s

Rodrigo Y.

Olá.

Concordo com você, Rodrigo !

Mas no caso apresentado de operações CRUD bem simples fico me perguntando qual a real finalidade, uma vez que no caso em questão apenas estão as operações básicas, sem nenhuma outra mensagem trocada ou algo que exija um diagrama de sequencia.

Talvez ao invés do diagrama de seqüência um diagrama de comunicação, já que parece não haver necessidade de demonstrar a seqüência de troca das mensagens.

Att,
Leandro Ramos.

Vai do seu projeto.... nenhum diagrama é obrigatório. Você modela o que precisa ser modelado

. Se é simples mesmo, nem o diagrama de comunicação é necessário, nem mesmo uma descrição de caso de uso precisa. Pode acontecer de alguns projetos ter CRUDS enjoados, com regras.

Mas, geralmente cadastros de tabelas básicas são feitos no final do projeto, nas últimas iterações. Aquela fase final que só tem programador júnior na equipe!

As coisas mais arriscadas são resolvidas nas primeiras iterações.

Smalltalk Membro desde: 09/05/2009 22:57:49 Mensagens: 1 Offline

Muito do que falaram por aí eu concordo em gênero, número e grau.

Mas há de se atentar em algumas observações como:

"Não, MVC não tem haver com as camadas. MVC é um padrão arquitetural geralmente utilizado para clientes pesados tipo Swing. "

A definição da arquitetura, deve basear em requisitos críticos ou objetivos centrais do sistema. Isso envolve escolha da linguagem, escolha do banco de dados... MVC é um padrão de design e não um padrão arquitetural. Uma arquitetura pode conter mais de um padrão de designer, conforme a necessidade. Um módulo web pode conter alguns requisitos que pode ser melhor atendido por um outro padrão de design, enquanto um módulo que usa Swing, seja melhor estruturado com um outro padrão de design.

Até mais,
Diego Pelícia

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