Olá galera!
Será que alguém me ajudaria neste desafio (pelo menos é para mim!)
Seguinte, tenho que modelar o seguinte sistema (pela primeira vista, simples, eu acho!)
É um sistema para um posto de escapamentos:
Cadastro de clientes (aqui também será cadastrado o(s) veículo(s) que o cliente possui)
Cadastro de fornecedores
Cadastro de Produtos
Contas a Pagar
Contas a Receber
Controle de Estoque
O sistema deverá fazer o seguinte:
Cota-se o preço dos produtos com vários fornecedores
Fecha-se o pedido
Os produtos chegam e vão para o estoque
Isto gera um Contas a Pagar (que terá um Prazo de Pagamento)
Chega um Cliente na empresa e solicita a troca do escapamento
É feita uma Ordem de Serviço onde tem quais os produtos foram utilizados/vendidos e também o valor da Mão de Obra
O sistema deverá dar baixa no estoque referente aos produtos vendidos na Ordem de Serviço
Isto gerará um Contas a Receber (que terá um Prazo de Recebimento)
Galera, como faço para modelar este sistema, com suas respectivas Classes, Interfaces, etc. ??
Alguém sabe de algum material/exemplo que poderia consultar para poder criar este sistema do zero?
E a modelagem do Banco de Dados (no caso usarei o PostgreSQL)?
Como eu faria esta modelagem para o Banco de dados?
“Cadastro e Clente, fornecdor, Contas a Pagar, Receber e Controle de estoque”. Deixa eu adivinhar: isso foi o que o seu cliente disse que seria o sistema!
Esses “módulos” são um ponto de partida somente para a sua modelagem. Você ainda vai sentar com o seu cliente muitas vezes para definir campos, requisitos, etc.
Não sei qual é a sua experiência de trabalho, mas acho que você devia modelar o banco de dados para começar. Fazer um MER com 1 par N, N pra N, relacionamentos, chaves primárias, estrangeiras e por aí vai.
Acho melhor no seu caso voce tentar modelar os processos, desde a chegada do cliente ate a contabilização do pagamento.
Faz um geral aparecendo tudo e depois especifica (só um pouco) cada relação, ai vc pode apresentar pro cliente pra ele te falar se é isso mesmo que ele faz, pra só depois pensar em banco de dados.
Senão corre o risco de vc imaginar uma coisa, o cliente outra, e no final das contas ser uma terceira diferente (o caso mais comum… )
Muita gente (incluindo eu) aprendeu e aprende na metodologia do ‘se vira nos 30’, seja por um motivo ou por outro. Não é um jeito fácil, pelo contrário, e costuma demorar bem mais apra se realmente entender o qeu se passa.
Minha recomendação é que você estude bastante a plataforma Java, depois disso estude análise e projeto Orientados a Objetos. Modelagem de dados de um sistema assim geralmente é bem simples, basta colocar classes em tabelas equivalentes.
Resumindo: tente não colocar o carros na frente dos bois
Não sei qual é a sua experiência de trabalho, mas acho que você devia modelar o banco de dados para começar. Fazer um MER com 1 par N, N pra N, relacionamentos, chaves primárias, estrangeiras e por aí vai.
Se tiver uma dúvida mais específica facilita.[/quote]
Bom…minha experiência é de um iniciante!
Os detalhes creio que tenho a maioria deles. Inclusive estou tentando modelar primeiro o Banco de Dados. Na verdade eu preciso de um material que me ensine MER (e os relacionamentos: 1xn, nxn, etc.)
Vc teria algum material, livro, etc para me indicar?
E quando ao java, na verdade eu preciso melhor minha noção de UML.
Vc tb saberia onde acho algum material ou documentação sobre UML?
Muita gente (incluindo eu) aprendeu e aprende na metodologia do ‘se vira nos 30’, seja por um motivo ou por outro. Não é um jeito fácil, pelo contrário, e costuma demorar bem mais apra se realmente entender o qeu se passa.
Minha recomendação é que você estude bastante a plataforma Java, depois disso estude análise e projeto Orientados a Objetos. Modelagem de dados de um sistema assim geralmente é bem simples, basta colocar classes em tabelas equivalentes.
Resumindo: tente não colocar o carros na frente dos bois
[]s[/quote]
Blz!..acho que entendi seu recado…
Tem algum material que vc poderia me indicar?
[quote=“dsiviotti”]Não sei qual é a sua experiência de trabalho, mas acho que você devia modelar o banco de dados para começar. Fazer um MER com 1 par N, N pra N, relacionamentos, chaves primárias, estrangeiras e por aí vai.
[/quote]
Heim?!?! Não estamos falando de um paradigma OO aqui?!?
Esqueça, pelo amor de Zahl, o banco de dados, se concentre em classes, responsabilidades, objetos e mensagens!!
[quote=“pcalcado”]
Heim?!?! Não estamos falando de um paradigma OO aqui?!?
Esqueça, pelo amor de Zahl, o banco de dados, se concentre em classes, responsabilidades, objetos e mensagens!!
[]s[/quote]
Calma Philip! Sem fundamentalismo. :lol:
Pelo que li da mensagem do Fávio ele é iniciante. Some isso à pressão para entregar um sistema onde o cliente, provavelmente, acha que em 2 semanas dá pra fazer tudo. Se ele não conhece modelagem/paradigma OO, essa não e a melhor hora para sair tentando fazer um sistema assim. Além do mais, pela mensagem, ele quer usar o PostGre, logo vai usar Banco da Dados Relacional.
Independente de todo o resto, o que vai definir a forma de trabalho é a relação COMERCIAL dele com o cliente.
O dono da loja não quer nem saber se
public class Escapamento extends AutoPeca implements SoltaFumaca {
}
ou se um fabricante produz N escapamentos que podem estar em N OSs, ele vai querer o sistema rodando.
Flávio,
Você disse que é iniciante. Já “vendeu” algum sistema antes? Tem alguém pra te ajudar?
Adiantando o problema: se você vai usar Swing ou similar, o dono da loja de auto-peças, que é bem capaz de ter uns Pentium 100 com 32MB vai querer saber por que o sistema dele fica lento ou por que tem que fazer upgrade se o amigo dele que também tem uma loja não precisa.
… ou não …
Não é fundamentalismo. Se for seguir este raciocínio, faça em VB, com comandos executados dentro dos botõezinhos e base access. Ou melhor: Clipper.
Existe hora melhor para aprender do que quando existe necessidade? OO não é frescura, é uma evolução nas técnicas de engenharia de software.
O fato de usar um banco relacional não tem absolutamente nada contra desenvolvimento OO, visto que 99.9999% dos sistemas que conheço usam bases relacionais ainda, e muitos deles são OO. Um pouco mais de dificuldade, mas nada complicado.
Isto é problema do departamento comercial, ou de quem vender o sistema. Aidna que seja o próprio programador, é hora de trocar o role (“chapéu”).
Essa afirmação foi complicada. Se for assim, vou continuar programando em BASIC no meu TK2000, para que evoluir?
Em todo sistema de informação feito para um cliente (e qual não é?) o usuário não quer saber se você fez em VB ou LISP, ele quer que os requisitos sejam cumpridos.
Quando a pressão aumenta, é bem comum abrir mão de boas práticas e sofrer na manutenção, mas pelo menos entregar a tempo. O qeu você propôs, no entanto, foi planejar o sistema de um modo que já está defasado há mais de dez anos.
Putz, eu trabalhava com isso até há uns 7 meses atrás. E não tenho nenhuma saudade do antigo trampo. :lol:[/quote]
Nem eu… :lol:
Só expressando minha opinião, acho que tanto faz começar modelando o banco, quando desenhado os objetos, o importante é seguir os coneceitos de cada lado, tipo, se é de banco que vamo tratar, falamos em relacionamentos, mas se é do sistema, falamos em objetos. Acho que assim funciona mto bem…
[quote=“brlima”]
Nem eu… :lol:
Só expressando minha opinião, acho que tanto faz começar modelando o banco, quando desenhado os objetos, o importante é seguir os coneceitos de cada lado, tipo, se é de banco que vamo tratar, falamos em relacionamentos, mas se é do sistema, falamos em objetos. Acho que assim funciona mto bem…
Flw![/quote]
Você está projetando um sistema baseado em objetos ou entidades relacionais e funções?
[quote=“pcalcado”]
Não é fundamentalismo. Se for seguir este raciocínio, faça em VB, com comandos executados dentro dos botõezinhos e base access. Ou melhor: Clipper.
[]s[/quote]
Na verdade eu quase botei isso na mensagem. :lol: Eu estava levantando aspectos não técnicos. Não sou maluco pra comparar OO x Modelo Relacional. Mas a tecnologia em que um sistema será feito não se baseia no fato de qual é a melhor ou mais nova, no mundo real, se você tem que vender um sistema, muitas outras variáveis definam a tecnologia empregada.
Eu disse isso porque tenho um cliente que também vende auto-peças e até alguns dias atrás ele tinha um 486 rodando meu sistema. :shock:
Meu maior cliente é uma estatal elétrica que só usa VB6, se eu fosse desprezar os botõezinohs, funções e MUITO SQL no meio do código eu perderia trabalho. :?
Não sei se o Flávio tem um departamento comercial. :lol:
Concordo totalmente. Também já fiz muito isso, mas depende de quem programa e para qiem se programa.
Além do mais, OO existe desde a década de 60, mas, como já disse, mesmo sendo uma evolução da engenharia de software esbarra em outras coisas que falam mais alto $.
[quote=“dsiviotti”]
Além do mais, OO existe desde a década de 60, mas, como já disse, mesmo sendo uma evolução da engenharia de software esbarra em outras coisas que falam mais alto $.[/quote]
Desculpa, mas seu argumento continua ruim para entender.
Bits quânticos existem há algum tempo, ams a tecnologia não adquiriu maturidade. Já estamos dividindo objetos em aspectos hoje em dia.
Não existe bom argumento apra mandar alguém começar um sistema OO fazendo modelo relacional.
[quote=“pcalcado”]
Não existe bom argumento apra mandar alguém começar um sistema OO fazendo modelo relacional.
[]s[/quote]
Ele vai fazer um sistema OO com modelagem OO e uma Base de Dados com modelo Relacional - PostGre. Se começa por uma ou outra não vejo interferência. Só disse para começar pelo banco porque é mais simples.
A ordem dos tratores não altera o viaduto.
[quote=“dsiviotti”]
Ele vai fazer um sistema OO com modelagem OO e uma Base de Dados com modelo Relacional - PostGre. Se começa por uma ou outra não vejo interferência. Só disse para começar pelo banco porque é mais simples.
A ordem dos tratores não altera o viaduto.[/quote]
Altera sim. Pensando relacional, você está projetando agrupamentos de dados, entidades sem comprotamento, só estado.
Persistir dados em um SGBD ou num arquivo CSV ou uma classe serializável é besteira, isso é detalhe de implementação, requisitto não funcional… chame como quiser mas a fase de achar que o SGBD é o principal de um sistema acabou. Bem vindo ao mundo dos objetos.
[quote=“pcalcado”]
Altera sim. Pensando relacional, você está projetando agrupamentos de dados, entidades sem comprotamento, só estado.[]s[/quote]
Imagina que você fará um sistema em java e o Flávio fará uma base de dados no Postgre. São contratos diferentes. Vocês visitam o cliente em datas diferentes. Você prepara o sistema utilizando toda a metodologia OO que precisar enquanto o Flávio monta o BD.
Se você fez o sistema usando padrões direitinho não fará diferença pra você se o Banco é Postgre, Oracle ou arquivo TXT, certo? Então por que esperar o Flávio terminar o BD para começar a programar? Não faz diferença. O mesmo vale para ele. Ele vai fazer um BD no Postgre e não sabe se você vai usar Java, .NET ou Clipper, mas isso não impede que faça o BD.
Logo, a ordem dos tratores não altera o viaduto.
:shock:
Realmente você entendeu errado o que eu disse. Eu não disse que o BD é o principal do sistema, apenas disse para ele começar pelo BD, é bem diferente. E disse isso baseado no fato dele ser um iniciante e provavelmente estar mais acostumado.
Uma coisa é motnar um sistema para conformidade com uma base de dados existente, outra coisa é iniciar do zero. Quando você inicia seu desenvolvimento do zero, iniciando com analise de requisitos e projeto, você tem liberdade para fazer as coisas direito.
Segundo metodologias estruturadas/procedurais, o normal é desenvolver um modelo de entidades antes. As entidades são depósitos de dados (que, inclusive, é a nomenclatura utilizada nesta metodologia),e representam dados persistidos agrupados. Assim, temos um dicionário de dados para sabermos que quando falamos em ALUNO, falamos em
CREATE TABLE ALUNO(
INT CD_MATRICULA PRIMARY KEY,
VARCHAR(10) TELEFONE1,
VARCHAR(10) TELEFONE2,
VARCHAR(100) NOME,
DATE DT_NASCIMENTO
);
Isso é uma estrutura de dados. É um objeto? Não. Objetos contêm comportamento.
Se você começa a modelar seu sistema com estruturas que contêm somente dados, você vai precisar colocar seu comportamento em lugares separados, logo surgem as funções.
Eu não disse que você não pode usar análise estruturada, disse apenas que não deveria, já que trabalha com uma plataforma de objetos. Sabe ASP? Várias funçõezinhas rpocedurais trabalhando com objetos que você não cosnegue criar? Pois é.
Análise Orientada à Objetos implica em modelar unidades de software (objetos) baseados em coisas e conceitos do mundo real. Estas ‘entidades’ não possuem apenas atributos, mas também comprotamentos, que viram os métodos do nosso objeto.
Geralmente um primeiro diagrama de classes contêm apenas atributos. Após inspecionar os requisitos (casos de uso, provavelmente), você começa a pensar nos seus métodos e na sequência em que são chamados.
Após isso, você já possui seus métodos públicos, uma provavel sequência de chamadas e o comportamento dos seus objetos está definido para sua necessidade.
Num sistema construído assim, os objetos de domínio retêm as regras de negócio. A execução das regras termina na criação e consumo de objetos, estes guardam os dados e comportamento de entidades.
Persistir é na teoria o mais fácil. É apenas guardar objetos em algum lugar seguro. Infelizmente, as técnicas mais utilizadas (i.e. SGBD) foram feitas para um paradigma onde o que será persistido são apenas grupos de dados com relações muito simples. Aí entram técnicas de mapeamento e toda a parafernália.
Se você começar criando seu SGBD, começa o caminho pelo lado contrário do fluzo normal. O importante num sistema OO são os objetos, não os dados. O que fica na persistência é uma foto de um objeto em um instante T.
[quote=“dsiviotti”]
:shock:
Realmente você entendeu errado o que eu disse. Eu não disse que o BD é o principal do sistema, apenas disse para ele começar pelo BD, é bem diferente. E disse isso baseado no fato dele ser um iniciante e provavelmente estar mais acostumado.[/quote]
)
