Oi galera.
Eu nao concordo com a metodologia que estou usando: primeiro, modelar o diagrama de classes a nível de implementacao e depois implementar. Acho ridiculo, mas tudo bem, sou obrigado a usar.
Minha primeira duvida e a seguinte: como represente o Banco de Dados no diagrama de classes quando uso o MVC? tenho uma classe pessoa, com suas subclasses e outra classe carre com suas subclasses. As classes da GUI se comunicam com uma unica controladora (p. ex. cadastro de todo muno vai se comunicar com uma controladora so. Ta certo isso/). Essa por sua vez se comunicaria com as classes carro e pessoa. Porem, algo me diz duas coisas:
1-a classe carro e pessoa ja sao a parte do modelo
2-tenho que fazer uma controladora para o banco de dados
essa duvida me consome. Eu acredito que o mais correto seria ligar a controladora direto com pessoa e carro, mas onde ficaria represetnado o banco de dados?
O Banco de Dados não aparece no diagrama UML, ao menos não no diagrama de classes. Vc. pode colocá-lo, se quiser, em um diagrama de componentes, se é que vc. utiliza este diagrama para algo de útil além de enfeitar a parede.
Quanto ao relacionamento da classe de controle e de domínio, o que faz sentido é vc traçar dependências do controle para as entidades manipuladas. E só. Não faz sentido ter, p.ex, um relacionamento 1:N de uma classe de controle para uma de domínio.
Hmm…
Que bom que o banco não aparece no diagrama de classes. de acordo com a metodologia que uso, esse diagrama deve ser o da implementação (que eu discordo mortalmente).
sobre o que foi falado da relacao entre controller e model, estou fazendo isso mesmo: uma associacao sem multiplicidade.
entao ficaria basicamente assim:
interfaces de cadastro - controller cadastro - model das pessoas e dos carros
?
Reforçando: nos diagramas que monto eu nunca tenho associação entre classes da camada de controle e do domínio. O que coloco são dependências (aquela linha pontilhada). A base da dependência é uma classe de controle e o destino (a parte com a ponta da seta) uma classe do domínio ou uma classe de serviço.
Um ponto importante: não faço isto apenas por achar correto. Faço pois utilizo uma ferramenta de geração de código (AndroMDA) que utiliza estas convenções para gerar artefatos concretos (ex: classes java) que são utilizados na implementação. Uma dependência como esta que descrevi gera o código de suporte spring para injetar DAOs no controller.
A parte de DAO, spring e essas coisas é desconhecido para mim.
Porém, a parte de associação achei bastante interessante. E realmente faz sentido, porque os modelos nunca vão acessar o controller. Já o controller acessa os modelos para pegar os dados e apresentar nas views (é certo isso, né?). Então o sentido (navegabilidade) é do controller para o model.
Muito interessante isso (:
Obrigado pelas respostas.
Abraço.
Isso me deixa preocupado, porque aparenta que eu nao estou entendo direito MVC.
A View tem uma referencia para o Model e o Model responde coisas para a View, certo? Eu achei que o Controller pegasse coisas da View, tivesse a lógica, conversasse com o Model e retornasse os dados para a view, tipo uma ponte entra o banco e a view, entende como? Mas pelo jeito não tem ponte nenhuma e a view já lida com o model o que, ao meu ver, parece bastante estranho.