"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
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.
[quote=“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.
[/quote]
mas o q vcs pensam do diagrama?
soh meu alterar q fico na dúvida, será que tem alguma depêndencia?
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
[quote=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 ;)[/quote]
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.
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.
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.
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.
[/URL]
[/URL]
[/URL]
As coisas mais arriscadas são resolvidas nas primeiras iterações.