Diagrama de sequencia - 3 (três) Camadas

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

http://www.guj.com.br/forums/show/12.java

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.

eu acho que vc deva estar esquivocado:

“http://www.macoratti.net/cshp_3c1.htm”:

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é… :thumbup:
[]s

Apoio 100% o comentário do pcalcado:

pcalcado:

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