Olá…estou redesenhando um projeto meu e gostaria de pediu auxílio de vocês para minhas classes e relacionamentos. Tenho aqui um diagrama de classe que gostaria de dessem uma olhada.
Este projeto meu é para uma empresa em que tenho (tinha) vinculo, mas ao termino vou deixar o projeto Open Source para quer quiser usar e verificar os códigos, e corrigindo… e aumentando, porque nao!! É um sistema de venda geral com servidor web tomcat e cliente magro desktop Swing, podendo ser extendido para outros tipos de clientes. Vou implementar no servidor a ferramenta OLAP Mondrian para a gerencia de informações e relatórios estáticos com drill…
Vou implementar tbm o envio para o servidor com HTTPClient, como o Luca me sugeriu em outro tópico, enviando e resgatando as informações com XML pelo XStream… acho que dessa forma a rede fica mais “leve” do que com objetos. No servidor será persistido com Hibernate e com banco Firebird, que ao meu ver é mais poderoso do que o MySQL. A lógica tentará ser o mais simples e funcional no servidor e não terá EBJ’s… o cliente terá os resources para internacionalização, mesmo no Swing.
Como é um projeto Open, estou tentando torná-lo o mais “internacional” possível. Sei que muita coisa aqui no brasil nao tem em outros países, mas tentei chegar perto disso. Gostaria tbm de pedir opinião sobre os nomes das classes e campos, bem como deixar mais perto internacionalmente, mas cobrindo a burocracia do Brasil… mas por favor, o enfoque será os relacionamentos e a arquitetura das classes… estou precisando mesmo para continuar o projeto.
A idéia do sistema é esta:
–> cadastro, alteração, exclusão e consulta de:
– cliente
– funcionario
– fornecedor
– produto
–> movimentações:
– venda
– compra
– pagamento
– recebimento
Possui tbm outras opções que não está mapeada no modelo pq não faz parte do “núcleo”, como comissões de funcionáios, impressões, relatórios e caixa.
A Venda possui um Cliente, que escolhe os Produtos (Itens de Venda) e, ao final, cria uma Conta a Receber, onde as parcelas são Itens de Conta a Receber. O recebimento é feito através desta classe de Itens de Conta a Receber. No caso eu somente atualizo o status da parcela como “finalizado”… e caso for reparcelado, eu cria outra Conta a Receber e os itens. Está legal?? Não está implementado o Pagamento das Compras ainda.
Sobre as heranças, eu sei que ela nao presta e etc, mas creio eu que neste caso, onde o que conta é o mapeamento de um punhado de classes “fixas”, reaproveitando métodos e atributos (nas abstratas há métodos get/set) e encaixa o É-UM, é mais simples e natural do que criar composições. O que acham?
Em Fornecedor há mais atributos que este aí, somente por efeito de simplicidade não mencionei.
Só lembrando da regra de que TODOS os atributos de uma classe TÊM QUE SER pertineteS a ela, achei que esse método feito ficou legal, mas não tenho muita experiência e vocês podem apontar os erros… não é intuito levar a discuções longas sobre herança, mas sobre a arquitetura apresentada…
Obrigado pela contribuição.
Após pronto, disponibilizarei a todos!
vlw
Joao Paulo 
