Arquivo Discussoes de Programacao e Tecnologia Olá pessoal, estou com uma dúvida há tempos, tenho lido ultimamente sobre o “desuso” do uml para a criação do projeto do sistema, principalmente em relação ao Diagrama de classes, na faculdade eu usava o JUDE (que parece está descontinuado)…
A minha dúvida é a seguinte, é possível desenvolver uma aplicação OO sem “desenhar” principalmente o diagrama de classes para dar conta dos relacionamentos?
Qual aplicativo usa-se no momento para o desenvolvimento do diagrama de classes?
Muito Obrigado
acho meio impossível fazer um sistema sem desenhar os diagramas antes… Eu aprendi desde o principio fazer a modelagem antes de tudo… sempre usei o Toad Data Modeler para isso, inclusive é uma mão na roda, pois já gera script do banco 
Eu uso muito papel e lápiz, “Giz” e lousa.
Em um ambiente onde outros podem sugerir melhorias isso é muito interessante pois cada um pode simplemente pegar seu modelo em UML e fazer as alterações e distribuir a idéia.
Eu tentei alguns mas vi que é demorado ficar desenhando, apagando, arrastando, jogando em tela, redimensionando…
Prefiro o papel e o lápiz
Olá pessoal, estou com uma dúvida há tempos, tenho lido ultimamente sobre o “desuso” do uml para a criação do projeto do sistema, principalmente em relação ao Diagrama de classes, na faculdade eu usava o JUDE (que parece está descontinuado)…
A minha dúvida é a seguinte, é possível desenvolver uma aplicação OO sem “desenhar” principalmente o diagrama de classes para dar conta dos relacionamentos?
Qual aplicativo usa-se no momento para o desenvolvimento do diagrama de classes?Muito Obrigado
No curso um professor meu indicou o StarUML, ele é free se não me engano.
Abraço.
Na minha Opinião da pra fazer, mas deve ser horrivel isso ! sem falar que o codigo fica totalmente associado a quem fez, pois não saberei em que você pensou para fazer aquilo, com o diagrama fica mais facil de entender o caminho que o programador ****** seguil.*******No curso um professor meu indicou o StarUML, ele é free se não me engano.
Abraço.
*Seguiu !!!
sorry
Luiz Augusto Prado
Concerteza antes de passar para um ferramenta case, o papel e lápis “comem solto”, porém, após o esboço, creio que seria meio ruim você passar para um banco, por exemplo, todas as tuas ideias de relacionamentos, tanto é que tu teria que ficar umas boas horas amarrando as tabelas na mão…
Tem como fazer o reverso?
Do sistema atual algum programa que gere o Diagrama?
Luiz Augusto PradoConcerteza antes de passar para um ferramenta case, o papel e lápis “comem solto”, porém, após o esboço, creio que seria meio ruim você passar para um banco, por exemplo, todas as tuas ideias de relacionamentos, tanto é que tu teria que ficar umas boas horas amarrando as tabelas na mão…
Sim, para a modelagem do banco de dados deve ser utilizado uma ferramenta case.
Já o diagrama de classes, não vejo tanta facilidade. Nesse ponto o UML só seria interessante de ser feito após o fim do módulo(projeto) para documentação e futuras manutenções.
Tem como fazer o reverso?
Do sistema atual algum programa que gere o Diagrama?
aí depende do seu banco…
então, o Diagrama do Banco de Dados, tá ligado diretamente ao Orientação Objeto(OO)?
Não são dois diagramas separados?
um para a modelagem dos dados e outro para OO?
Aqui você quer dizer modelagem do banco ou modelagem do sistema?
O seu método é o que mais funciona. Um bom lápis e bonequinhos e caixinhas no papel me falam muito mais que complexos diagramas de classe e sequência. = )
Código totalmente associado ao programador que fez? Mas sempre teremos isso…
A ideia é que o programador codifique bem e de forma limpa o seu código e não precisemos de documentações UML pra saber o que ele fez ou deixou de fazer.
Pessoal, documentação do projeto em UML é ultrapassado e em raras exceções pode funcionar. O código hoje é muito vivo e manter as atualizações é extremamente custoso. Considero que a melhor documentação é
uma ótima suite de Testes.
Abs!
Na verdade o seu banco deveria seguir a modelagem do seu sistema, e não o contrário. Programar orientado a banco de dados é perigoso não? 
Abs!
Em relação a UML, o seu ponto é mais interessante que escrever dezenas de umls antes.
O próprio JPA consegue fazer isso = )
Na verdade o Banco de Dados é Relacional(estou considerando uma solução NoSQL mesmo) e a sua modelagem será OO. Realmente é complicado ter uma conversa perfeita entre os dois mas é coerente que você faça a modelagem da sua aplicação
e em seguida passe para o armazenamento dessas informações. Você não deveria criar tabelas, já que não sabe ainda o que será necessário para a sua aplicação.
Alguém discorda?
Abs!
então, o Diagrama do Banco de Dados, tá ligado diretamente ao Orientação Objeto(OO)?Não são dois diagramas separados?
um para a modelagem dos dados e outro para OO?
Na verdade o Banco de Dados é Relacional(estou considerando uma solução NoSQL mesmo) e a sua modelagem será OO. Realmente é complicado ter uma conversa perfeita entre os dois mas é coerente que você faça a modelagem da sua aplicação
e em seguida passe para o armazenamento dessas informações. Você não deveria criar tabelas, já que não sabe ainda o que será necessário para a sua aplicação.Alguém discorda?
Abs!
Ok!
Mas com o sistema pronto(onde não foi feito o diagrama de UML), existe algum software que lê as classes em java e cria um diagrama de UML?
Sim. Exemplos:
http://essmodel.sourceforge.net/features.html
Mas por curiosidade, por que você iria querer fazer isso?
visual paradigm e E.A
Eu uso muito papel e lápiz, “Giz” e lousa.
Em um ambiente onde outros podem sugerir melhorias isso é muito interessante pois cada um pode simplemente pegar seu modelo em UML e fazer as alterações e distribuir a idéia.Eu tentei alguns mas vi que é demorado ficar desenhando, apagando, arrastando, jogando em tela, redimensionando…
Prefiro o papel e o lápiz
Essa é a melhor forma de usar UML. Para mim a UML deve ser usada para para divulgar idéias, para comunicar algo e não modelar um sistema inteiro. Isso é coisa de analista que não sabe nada de programação e que acretida que pode modelar um sistema inteiro com UML. O problema é que UML não da uma indicação clara das responsabilidades das classes e, com exceção de projetos muito simples, haverá problemas de comunicação, pois o cara que criou o modelo poderia querer uma coisa mas foi desenvolvida outra! Um exemplo é são os padrões State e Strategy que são identicos, mas fazem coisas completamente diferentes. Segue abaixo os diagramas dos dois, para uma comparação. Esse é um exemplo claro do problema de comunicação que pode surgir. Outro problema é a defasagem da implementação x documentação. Uma coisa pode paracer muito boa no papel mas não vai funcionar tão bem quando implementado, então é feito uma modificação no código que não é propagado para documentação.
A UML é um recurso poderoso, mas deve ser usada com moderação e de maneira apropriada!
Perfect!
Perfect!
É totalmente possível, tanto que muita gente o faz assim, sem diagramação formal, e sim os tais rascunhos de papel de pão.
Vc aprendeu a moda antiga, então é natural que pense assim, você foi talhado desse jeito, mas é interessante que você procure se atualizar pois você está um pouquinho defasado, modelar o banco antes de tudo é programar orientado a banco e não a objetos. VocÊ deve conhecer as alternativas para pelo menos decidir o que é melhor para o seu contexto.
Não sou xiita, acho que existem processos e regras de negócio que precisam ser mapeados com mais atenção e a UML pode ajudar, porém já tendo feito muito diagrama UML desde que comecei a trabalhar com desenvolvimento, hoje se eu puder tomar essa decisão em um projeto prefiro começar o quanto antes possível no código.
Na minha Opinião da pra fazer, mas deve ser horrivel isso ! sem falar que o codigo fica totalmente associado a quem fez, pois não saberei em que você pensou para fazer aquilo, com o diagrama fica mais facil de entender o caminho que o programador seguil.No curso um professor meu indicou o StarUML, ele é free se não me engano.
Código totalmente associado ao programador que fez? Mas sempre teremos isso…
A ideia é que o programador codifique bem e de forma limpa o seu código e não precisemos de documentações UML pra saber o que ele fez ou deixou de fazer.Pessoal, documentação do projeto em UML é ultrapassado e em raras exceções pode funcionar. O código hoje é muito vivo e manter as atualizações é extremamente custoso. Considero que a melhor documentação é
uma ótima suite de Testes.Abs!
Bom, vc disse bem, a Ideia é que o programador codifique bem e de forma limpa, mas será que isso sempre acontece amigo ?? o cara chega ai na sua empresa, faz de qualquer jeito e some no mundo ! ai seu cliente quer uma alteração no programa, ai bem na parte do programador que te abondonou, e ai, vc faz oque ? perde uma vida só pra entender o que o cara fez, ou consulta um diagrama simples com tudo que vc precisa saber sobre o codigo ?
Nem tudo é um sonho, dizer que a função do programador e fazer tudo certo vc esta completamente certo, mas acreditar que todos fazem ao ponto de vc nunca precisar de um material de apoio ja acho um pouco de descuido, é minha opinião !
Abraço
Infelizmente tenho que concordar com o x@ndy; realmente o que ocorre hoje em dia é + ou - isso mesmo.
A problema é que muitos esquecem do seguinte:
flws
O problema é que se o cara já fez um trabalho sujo no código, um código macarrônico, procedural, sem padrões, etc com toda a certeza ele fez igual em possíveis diagramas. Se o código está um lixo e sem entendimento algum, os diagramas, que refletem o código, também o estarão
A documentação raramente andará com o projeto, ou seja, se você pegar um diagrama, novamente, ele estará defasado em relação ao código horrível que você acabou de encontrar. Além de te confundir, os diversos diagramas de sequencia, classe, etc não só te darão um feedback errado como te confundirá mais ainda.
Abs!
Perfect!
É totalmente possível, tanto que muita gente o faz assim, sem diagramação formal, e sim os tais rascunhos de papel de pão.
Vc aprendeu a moda antiga, então é natural que pense assim, você foi talhado desse jeito, mas é interessante que você procure se atualizar pois você está um pouquinho defasado, modelar o banco antes de tudo é programar orientado a banco e não a objetos. VocÊ deve conhecer as alternativas para pelo menos decidir o que é melhor para o seu contexto.
Não sou xiita, acho que existem processos e regras de negócio que precisam ser mapeados com mais atenção e a UML pode ajudar, porém já tendo feito muito diagrama UML desde que comecei a trabalhar com desenvolvimento, hoje se eu puder tomar essa decisão em um projeto prefiro começar o quanto antes possível no código.
Perfect!
Não foi eu quem criou o Tópico, mas gostaria de mais opiniões a respeito do assunto, pra poder ter uma visão mais geral, se isso realmente acontece com todos, ou melhor, se todos acham que assim é melhor.
Abraços
Sério, quem ta dizendo que UML é uma obrigação, deveria dar uma lida em algumas metologias ágeis e principalmente no Getting Real da 37signals.
Bom, vc disse bem, a Ideia é que o programador codifique bem e de forma limpa, mas será que isso sempre acontece amigo ?? o cara chega ai na sua empresa, faz de qualquer jeito e some no mundo ! ai seu cliente quer uma alteração no programa, ai bem na parte do programador que te abondonou, e ai, vc faz oque ? perde uma vida só pra entender o que o cara fez, ou consulta um diagrama simples com tudo que vc precisa saber sobre o codigo ?Nem tudo é um sonho, dizer que a função do programador e fazer tudo certo vc esta completamente certo, mas acreditar que todos fazem ao ponto de vc nunca precisar de um material de apoio ja acho um pouco de descuido, é minha opinião !
Abraço
Documentação não é sinal de qualidade de código. Se fosse assim era só fazer documentação que o produto seria uma maravilha.
Claro que não da para sair codificando a moda loco. O levantamento de requisitos é fundamental, é necessário antes de fazer entender o que fazer! O problema é querer modelar um sistema inteiro com UML. Isso não é possivel, pelos motivos que já relatei, entre outros.
Bom, não tenho experiencia profissional para afirmar como é, vcs podem opinar bem mais que eu, eu so me baseio o que eu aprendo na faculdade, afinal, esta dentro das boas praticas de desenvolvimento de software que é um padrão universal, mas como disse, isso na teoria, na pratica pode mudar, não sei, mas tem pessoas que acham necessario, outras não, quando eu tiver com essa experiencia profissional e ja ter desenvolvido todo um sistema sem tais ferramentas posso mudar totalmente de opinião !Não foi eu quem criou o Tópico, mas gostaria de mais opiniões a respeito do assunto, pra poder ter uma visão mais geral, se isso realmente acontece com todos, ou melhor, se todos acham que assim é melhor.
Abraços
Toda indústria evolui de forma natural passando por etapas de elucidação durante sua evolução. Outro dia conversando com um amigo meu que já está a quase 40 anos na área, ele estava me contando sobre como alguns posts que ele andou lendo sobre práticas ágeis (lembro aqui que na Web existe de tudo e é claro que ele não perdeu tempo filtrando, só leu por ler) ele já praticava em alguns de seus projetos lá pela década de 70 - 80.
A própria Engenharia de Software, hoje amplamente aceita e divulgada como verdade absoluta pela academia, tal como é em sua essência, veio com o intuito de organizar a casa em Projetos de Software, que falhavam em uma larga escala de vezes, gerando trauma no mercado. Quando a ES chegou, também gerou essa gama de discussões acaloradas na comunidade, sobre o que era “CERTO” e “ERRADO” no Desenvolvimento de Software.
Claro, após esse período, a Engenharia de Software foi aceita na comunidade como a ciência que resolveria o problema dos fracassos da área de DS. Alguns fatores surgem aqui:
Como acontece em todas as ocasiões, sempre que uma metodologia ou ciência entra em evidência ou se torna amplamente aceita, começam a aparecer os oportunistas de plantão que começam a introduzir nomes e siglas para ganhar algum $$ com a proposta;
Sempre aparecem os evangelizadores de tais práticas que as colocam em um pedestal e fundam a igreja da metodologia e se transformam em verdadeiros pastores, onde quem falar alguma coisa contra a santíssima metodologia, vai pro inferno;
Sempre aparecem a gama de “profissionais” que simplesmente vão de acordo com as pregações desses pastores e não conseguem montar uma opinião própria;
Sempre existirão os críticos que querem matar o pastor e não tem uma abordagem prática melhor, além de criticar;
E GRAÇAS A DEUS, ALÁ, ELEFANTE BRANCO, EVOLUÇÃO, (coloque aqui o que você acredita), enfim…
Houve uma época em que essa idéia de se gerar a documentação, foi largamente aceita como única alternativa para evitar o fracasso de projetos de Software que eram “desorganizados” e a tal da documentação e modelagem viriam pra salvar a pátria.
Acontece que mesmo adotando tais métodos, projetos de software continuaram e continuam falhando de forma miserável e agora com um agravante, perde-se um tempo absurdo construindo artefatos que dizem conter as regras do Sistemas, mas que de tão defasados e inconsistentes que estão, acabam gerando ainda mais frustação.
Perceba que quando falamos em regras de um Sistema, estamos falando de uma coisa bem séria e que a experiência ainda vai lhe ensinar: “O que um Sistema deve fazer, deve ser definido pelo cliente e em 99,999999% dos casos, o cliente não sabe o que quer, ou se sabe, quando vê o Software funcionando muda de opinião.”.
Aí perdemos tempo colocando todas as idéia desse cara em um calhamaço de papel, com idéias retiradas de uma ou outra conversa que tiveram com um cara que muitas vezes nem será o cara que vai usar o Sistema e quando a primeira versão do Software é gerada e mandada pra ser homologada, o cara diz que não está atendendo.
Aí bate o desespero de dizer “como não ? Perdemos 6 meses docuimentando o Sistema, nós criamos o Diagrama de Casos de Uso e vocês assinaram o documento de Requisitos.”.
Daí percebemos que palavras em um papel, não é Software. Palavras podem ser ambíguas, diagramas mais ainda.
Começa então a fase do inferno do projeto. Como perdeu-se tempo lá no início, precisa-se correr atrás do preju e alguns sintomas aparecem nessa fase:
Stress da equipe que agora começa a perder suas madrugadas, seus fins de semana, seus feriados, etc. em horas extras pra poder recuperar o tempo perdido;
Caça aos culpados, onde analistas põe a culpa nos programadores que não desenvolveram o que foi especificado e programadores que acusam analistas que não documentaram de forma correta;
Gerentes de projeto mirando sua metralhadora de acusações para todos os lados querendo tirar o seu da reta;
Cliente insatisfeito, se sentindo enganado pela consultoria;
Existem algumas outras, mas acho que já deu pra entender. E eu lhe pergunto, isso é culpa do processo ???
Na minha visão metade da culpa só é do processo, só a metade onde o processo parece que esquece que quem os coloca em prática, são pessoas e pessoas são difíceis.
Há muito mais coisas envolvidas em um processo de desenvolvimento de Software, que estimativa e nem documento algum são capazes de mensurar.
Essas práticas http://manifestoagil.com.br/ tentam trazer uma nova abordagem para a ES como forma de evolução.
Ao pesquisar sobre, lhe recomendo 2 coisas:
1 - Perceber que nem tudo o que já foi evoluído foi jogado fora e que documentos e modelos ainda têm o seu espaço no processo;
2 - Isso é o que temos hoje, inclusive já com algumas vertentes pregando idéias diferentes;
E assim a vida segue seu ciclo. É o modelo perfeito ??? Não sei, só sei te dizer que no final das contas foi o modelo que casou com o que eu sempre critiquei no modelo anterior.
Minha dica é que você estude, se aperfeiçoe, critique o que ver de errado e busque soluções alternativas, mesmo aquelas que são ensinadas na sua faculdade.
A academia está bastante defasada nas disciplinas de desenvolvimento de software em relação ao mercado, por isso use e abuse da faculdade somente pra extrair conceitos.
Saiba que ainda não acabou por aí e que “Metodologias Ágeis” foi mais um nome dado para ganhar algum $$ em cima do novo padrão que a indústria está tentando implantar e que logo logo irá evoluir para algo ainda melhor e que passará pelo mesmo ciclo que eu coloquei no início do Post.
Espero ter sido claro cara e qualquer coisa que você queira discutir sobre o assunto, será bem vindo.
Abs []
Diego, cuidado para não se tornar o pastor dessas duas metodologias…
Perceba que no documento da 37signals eles deixam bem claro que essa é a forma deles desenvolverem o software deles e que não há certo ou errado e sim que é assim que ELES fazem.
Os softwares da 37signals são bem específicos.
Uso as metodologias deles para aplicar em uma Startup que estou criando, mas nem sonho em usá-los para o Sistema ao qual dou manutenção em um grande Banco da minha cidade.
Temos que acima de tudo, saber que em desenvolvimento de Software existem os mais diversos cenários e que o que é verdade em um cenário, pode não ser no outro.
E assim, seguimos, sempre procurando desenvolver da melhor forma possível sem receita de bolo.
Abs []
Diego, cuidado para não se tornar o pastor dessas duas metodologias…Perceba que no documento da 37signals eles deixam bem claro que essa é a forma deles desenvolverem o software deles e que não há certo ou errado e sim que é assim que ELES fazem.
Os softwares da 37signals são bem específicos.
Uso as metodologias deles para aplicar em uma Startup que estou criando, mas nem sonho em usá-los para o Sistema ao qual dou manutenção em um grande Banco da minha cidade.
Temos que acima de tudo, saber que em desenvolvimento de Software existem os mais diversos cenários e que o que é verdade em um cenário, pode não ser no outro.
E assim, seguimos, sempre procurando desenvolver da melhor forma possível sem receita de bolo.
Abs []
Sim, eu concordo com você. Eu acho que não existe uma melhor metodologia, e sim uma melhor metodologia para determinada situação. Não sei se fui bem claro, mas eu disse algo parecido com: “Pra quem acha que UML é uma OBRIGAÇÃO…”. O que eu quis dizer é: Sim existe lugar para UML. Mas UML ou “Documentação extensa e formal” não é a melhor solução para TODAS as aplicações e portanto não deve ser tratada como bala de prata.
Perfeito cara… Eu que interpretei mal o restante de seus textos…
De fato, o cuidado que devemos ter ao nos tornarmos adeptos de metodologia X ou Y ou especialistas em Tecnologia A ou B, é justamente nos tornarmos cegos às novidades e evoluções da nossa área.
Abs []
Juro que pensei que este tópico iria descambar, até o momento pelo menos.
Parabéns!
Gostei bastante do que você escreveu adriano_si.
flws
adriano_si, o que teu amigo falou é verdade; o pior é que depois de tanto tempo muitos, senão a maioria, não entenderam a idéia.
Dizem que utilizam “Metologias Ágeis” como desculpa para fazer a maior bagunça no projeto - e ainda acham que é bacana e moderno.
Só quem pega um projeto destes para fazer ajustes sabe exatamente do que estou falando.
flws
Luiz Augusto PradoConcerteza antes de passar para um ferramenta case, o papel e lápis “comem solto”, porém, após o esboço, creio que seria meio ruim você passar para um banco, por exemplo, todas as tuas ideias de relacionamentos, tanto é que tu teria que ficar umas boas horas amarrando as tabelas na mão…
Na verdade o seu banco deveria seguir a modelagem do seu sistema, e não o contrário. Programar orientado a banco de dados é perigoso não?
Abs!
Por que perigoso?
Quando tenho que fazer um sistema (modulo), de acordo com o que o cliente deseja (Caso de uso), a primeira coisa que faço é extrair as tabelas e relacionamentos necessarios para que aquele sistema funcione. Apartir desse modelo pronto que eu passo para as classes.
Eu uso muito papel e lápiz, “Giz” e lousa.
Em um ambiente onde outros podem sugerir melhorias isso é muito interessante pois cada um pode simplemente pegar seu modelo em UML e fazer as alterações e distribuir a idéia.Eu tentei alguns mas vi que é demorado ficar desenhando, apagando, arrastando, jogando em tela, redimensionando…
Prefiro o papel e o lápiz
Essa é a melhor forma de usar UML. Para mim a UML deve ser usada para para divulgar idéias, para comunicar algo e não modelar um sistema inteiro. Isso é coisa de analista que não sabe nada de programação e que acretida que pode modelar um sistema inteiro com UML. O problema é que UML não da uma indicação clara das responsabilidades das classes e, com exceção de projetos muito simples, haverá problemas de comunicação, pois o cara que criou o modelo poderia querer uma coisa mas foi desenvolvida outra! Um exemplo é são os padrões State e Strategy que são identicos, mas fazem coisas completamente diferentes. Segue abaixo os diagramas dos dois, para uma comparação. Esse é um exemplo claro do problema de comunicação que pode surgir. Outro problema é a defasagem da implementação x documentação. Uma coisa pode paracer muito boa no papel mas não vai funcionar tão bem quando implementado, então é feito uma modificação no código que não é propagado para documentação.
A UML é um recurso poderoso, mas deve ser usada com moderação e de maneira apropriada!
Esse é um problema chato. O UML é uma idéia muito interessante, mas os recursos que as maquinas oferecem para desenharmos o UML é muito lento em comparação com o lapiz e papel. Bem, infelizmente isso ocorre comigo.
Esse mesmo problema também ocorre quando tenho que escrever sobre matemática. Consegue imaginar vc lembrando uma tecla de atalho pra cada um dos milhares de simbolos da matemática?
Estou começando a voltar para o velho lapiz, papel e borracha.
É perigoso pq você não sabe exatamente o que precisará e não sabe como será o seu design. O design do seu código te dirá exatamente o que fazer e onde armazenar. Se vc desenvolver com TDD por exemplo, as suas tabelas serão criadas a medida que cada funcionalidade sua nascer, ou seja, você mantem as coisas simples e só desenvolve aquilo que realmente precisa. Se você trabalhar com iterações por exemplo, com integras contínuas e com integração contínua, verá que o seu esforço tem q ser concentrado naquilo que precisa entregar, o que foge do modo orientado a banco de ser.
É regra para o mundo? não! Funciona? Muito bem!
Abs!
Por que perigoso?
Quando tenho que fazer um sistema (modulo), de acordo com o que o cliente deseja (Caso de uso), a primeira coisa que faço é extrair as tabelas e relacionamentos necessarios para que aquele sistema funcione. Apartir desse modelo pronto que eu passo para as classes
É perigoso pq você não sabe exatamente o que precisará e não sabe como será o seu design. O design do seu código te dirá exatamente o que fazer e onde armazenar. Se vc desenvolver com TDD por exemplo, as suas tabelas serão criadas a medida que cada funcionalidade sua nascer, ou seja, você mantem as coisas simples e só desenvolve aquilo que realmente precisa. Se você trabalhar com iterações por exemplo, com integras contínuas e com integração contínua, verá que o seu esforço tem q ser concentrado naquilo que precisa entregar, o que foge do modo orientado a banco de ser.
É regra para o mundo? não! Funciona? Muito bem!
Abs!
Como vc lida com a performance do banco de dados no CRUD?
Luiz Augusto PradoConcerteza antes de passar para um ferramenta case, o papel e lápis “comem solto”, porém, após o esboço, creio que seria meio ruim você passar para um banco, por exemplo, todas as tuas ideias de relacionamentos, tanto é que tu teria que ficar umas boas horas amarrando as tabelas na mão…
Na verdade o seu banco deveria seguir a modelagem do seu sistema, e não o contrário. Programar orientado a banco de dados é perigoso não?
Abs!
“Programar orientado a banco de dados é perigoso não?”
Não! Com uma boa modelagem do banco de dados partindo dos requisitos do usuário, não vejo problema algum em modelar o banco e depois partir pro software, além do mais, fazer um sistema e depois o banco, ao meu ver, lhe dará imensos transtornos e remodelagem de banco…
Não entendi a pergunta
Partindo dos requisitos do usuário temos casos de uso, partindo dos casos de uso temas regras de negócio, partindo das regras de negócio temos o design do seu projeto. Se ele vai precisar ou não de um banco de dados, é aqui que vamos descobrir, se vamos
precisar guardar ou não o rg do cara, é aqui que vamos descobrir
O que quero dizer é que o desenvolvimento orientado a banco de dados te faz modelar algo que você não tem, algo que você imagina que existirá, o que muitas vezes pode não ocorrer. É uma questão de prioridade. Você prefere modelar algo que na hora você precisa, ou imaginar o que vc vai precisar, pra começar a modelar?
Abs!
Não! Com uma boa modelagem do banco de dados partindo dos requisitos do usuário, não vejo problema algum em modelar o banco e depois partir pro software, além do mais, fazer um sistema e depois o banco, ao meu ver, lhe dará imensos transtornos e remodelagem de banco…
Partindo dos requisitos do usuário temos casos de uso, partindo dos casos de uso temas regras de negócio, partindo das regras de negócio temos o design do seu projeto. Se ele vai precisar ou não de um banco de dados, é aqui que vamos descobrir, se vamos
precisar guardar ou não o rg do cara, é aqui que vamos descobrirO que quero dizer é que o desenvolvimento orientado a banco de dados te faz modelar algo que você não tem, algo que você imagina que existirá, o que muitas vezes pode não ocorrer. É uma questão de prioridade. Você prefere modelar algo que na hora você precisa, ou imaginar o que vc vai precisar, pra começar a modelar?
Abs!
Por isso que gosto do papel e do lápiz.
É no momento que estou criando meu diagrama de classes que vou modelando o banco de dados.
Como o colega acima falou, começar pelo banco de dados evita problemas futuros.
Mesmo depois de o sistema estar pronto ele pode evoluir e ser atualizado. Isso pode lhe exigir uma manutenção ou migração em tabelas ou dados muito caóticos se seu banco de dados fosse baseado em uma view, por exemplo.
A qualquer momento vc pode ver que mudando, removendo ou acrescentando uma tabela (com relacionamentos) isso vai afetar aperformance do seu sistema ou do seu desenvolvimento.
Seja no tempo para que seu banco de dados apresente os resultados, na qualidade do sistema, tempo de desenvolvimento ou seja na usuabilidade.
Você cria diagramas de classe antes de iniciar um projeto? A partir do diagrama de classes vc cria o seu banco? 0_o
Banco de dados baseado em uma view? 0_o
Por isso que gosto do papel e do lápiz.
É no momento que estou criando meu diagrama de classes que vou modelando o banco de dados.
Como o colega acima falou, começar pelo banco de dados evita problemas futuros.
Mesmo depois de o sistema estar pronto ele pode evoluir e ser atualizado. Isso pode lhe exigir uma manutenção ou migração em tabelas ou dados muito caóticos se seu banco de dados fosse baseado em uma view, por exemplo.A qualquer momento vc pode ver que mudando, removendo ou acrescentando uma tabela (com relacionamentos) isso vai afetar aperformance do seu sistema ou do seu desenvolvimento.
Seja no tempo para que seu banco de dados apresente os resultados, na qualidade do sistema, tempo de desenvolvimento ou seja na usuabilidade.
Você cria diagramas de classe antes de iniciar um projeto? A partir do diagrama de classes vc cria o seu banco? 0_o
Sim, quanto recebo o pedido do sistema vejo tudo o que é necessario.
Apartir disso começo com papel e lápiz desenhando as classes prevendo as tabelas e relacionamentos no banco.
Então, com esse minimo, eu começo modelando o banco de dados.
Aqui tem um exemplo de como faço com anottations para eu gerar meu banco:
package testeorm.Interfaces;
import testeorm.DialectMySQL;
import orm.generators.Annotations.*;
@Table( DataBase="db_condominio", Nome="Usuario" )
public interface Usuario
{
@Column(SqlDataType=DialectMySQL.DataType_INT, Key=DialectMySQL.KeyType_PRIMARY, AutoIncrement=true, Nullable=true, lengthMax=11, lengthMin=1)
public int idUsuario();
@Column(SqlDataType=DialectMySQL.DataType_VARCHAR, Key=DialectMySQL.KeyType_UNIQUE, Nullable=false, lengthMax=16, lengthMin=8)
public String login();
@Column(SqlDataType=DialectMySQL.DataType_VARCHAR, Nullable=false, lengthMax=32, lengthMin=8)
public String senha();
@Column(SqlDataType=DialectMySQL.DataType_BOOLEAN, Nullable=false, lengthMax=3)
public boolean ativo();
@Column(SqlDataType=DialectMySQL.DataType_DATE, Nullable=false, lengthMax=8)
public String dataEntrada();
@Column(SqlDataType=DialectMySQL.DataType_DATE, Nullable=true, lengthMax=8)
public String dataSaida();
@Column(SqlDataType=DialectMySQL.DataType_INT, Key=DialectMySQL.KeyType_INDEX, Nullable=false, lengthMax=11, lengthMin=1)
@Foreign(ForeignKeyOf=testeorm.Interfaces.Pessoa.class, ForeignKeyName="idPessoa")
public int idPessoa();
}
Não tenho nada contra a sua metodologia, mas prever as tabelas, prever relacionamentos e sair desenvolvendo orientado ao banco acho no mínimo perigoso(again!). Se você define classes antes mesmo de codificar,
quer dizer que você não tem uma suite de testes certo? Ou no mínimo cria os seus testes depois da sua implementação correto? Viu o perigo? Modelar algo no banco que no existe, para um código que você ainda não tem,
e para um requisito que ainda não existe no seu design.
Por curiosidade, o que seria isso no seu código? Um ORM proprietario?
Sim, quanto recebo o pedido do sistema vejo tudo o que é necessario.
Apartir disso começo com papel e lápiz desenhando as classes prevendo as tabelas e relacionamentos no banco.
Então, com esse minimo, eu começo modelando o banco de dados.
Aqui tem um exemplo de como faço com anottations para eu gerar meu banco:
Não tenho nada contra a sua metodologia, mas prever as tabelas, prever relacionamentos e sair desenvolvendo orientado ao banco acho no mínimo perigoso(again!). Se você define classes antes mesmo de codificar,
quer dizer que você não tem uma suite de testes certo? Ou no mínimo cria os seus testes depois da sua implementação correto? Viu o perigo? Modelar algo no banco que no existe, para um código que você ainda não tem,
e para um requisito que ainda não existe no seu design.
Se eu não tenho dados, por que preciso de designer?
Quando entendo o que o cliente quer, entendo que dados ele quer. Por isso não entendi porque fala que o banco não é um requisito do sistema?
Estamos falando de joguinho, ou módulo ou classe especifico que não necessite de um banco de dados?
Sim, testo cada metodo que vou acrescentando.
O teste é simular o máximo de combinação de casos que o tempo permitir parar cada metodo da classe.
De acordo com a codificação que escolher para o banco, vc poda um monte de decisoes das camadas acima. Exemplo: se colocar delete cascate=on num relacionamento não precisarei ficar verificando permissões no codigo. Assim, faço os testes levando em conta esses tipos de restriçoes em consideração.
SqlDataType=DialectMySQL.DataType_VARCHAR@Table( DataBase=“db_condominio”, Nome=“Usuario” )
Por curiosidade, o que seria isso no seu código? Um ORM proprietario?
Esse fonte é do link que passei.
To dando esse exemplo pra te mostrar que existem outros paradigmas.
Quem te diz como você codificará são os requisitos, as regras de negócio e não os dados.
Você testa cada método que vai acrescentando ou acrescenta um método pra cada teste? Há uma grande diferença aqui também
Será que estamos falando do mesmo tipo de teste?
De acordo com a codificação que escolher para o banco, vc poda um monte de decisoes das camadas acima.
Não é mais facil, em vez de pensar o que será podado ou não, simplesmente podar na codificação, já que com um simples teste você terá um requisito testado e funcionando e limpo, sem precisar pensar em podar ou não.
Vejo o banco como infra e não como negócio. É um lugar burro que só envio e recebo coisas que quero guardar pra não perder.
Abs!
Mas este ORM é “caseiro”? Ele gera o seu banco a partir das suas classes? É isso?
Só para deixar claro, o seu paradigma é “programar orientado a banco de dados”? Vamos deixar claro para termos uma conversa sadia e eu nãoi falar A e vc entender B e vice versa =)
Abs!
Regras de negócio é o que o cliente quer executar. Se vc não entende o que o cliente quer, não tem como fazer o sistema.
Sim esse é um esboço de orm que estou fazendo.
Sim. Regras de negócios sao os problemas que o cliente quer resolver. Em nenhum momento banco de dados entra na conversa. Banco é infra
Pq? Para estudo ou para distribuição?
Abs!
Pessoas, não há o CERTO e o ERRADO nessa brincadeira de desenhar Sistemas.
Ambos modelos funcionam e é perfeitamente válido começar um Sistema a partir do modelo relacional.
O que o Alexandre está falando, é concentrado unicamente para Sistemas que querem apoiar-se na Orientação a Objetos para serem escaláveis, de fácil manutenção, livres de gambiarras, etc.
O que ele está tentando lhe mostrar é que começar a modelagem de um Sistema a partir de seu modelo relacional traz alguns perigos. Um dos pontos fortes na argumentação dele é que quando você modela um banco de dados relacional, você já está garantindo que seu sistema terá um Banco de Dados Relacional e que qualquer mudança desse paradigma pode ferrar com seu projeto lá na frente.
Esse exemplo não é meu, mas tenho uns amigos que começaram a modelagem de um Sistema há um tempo atrás e lá pelo 5º mês descobriram que o modelo reclacional ia ferrar com o que eles queria fazer. Tinham 2 opções;
1 - Inventar gambiarras relacionais que consertariam um problema e arranjariam outro;
2 - Pensar em uma alternativa ao modelo ER;
Depois de 1 ou 2 semanas de tentativas e algumas pogs, chegaram a conclusão que um banco Não Relacional seria a saída. Hoje o sistema está implementado no Voldemort;
Se você perceber, ficamos tão fechados nessa idéia de banco de dados relacionais que dificilmente conseguimos enxergar fora da caixa.
Outro perigo grande nessa abordagem é que Modelo OO !!!==== de Modelo ER.
Uma linha de uma tabela precisa de uma gambiarra de mapeamentos e Objetos Anêmicos para todos os lados pra poder ser representada em um Modelo OO.
Claro que para as argumentações acima você pode dizer que: “90% dos Sistemas hojes são resolvidos com modelos relacionais” e eu lhe respondo: “PERFEITO, você está certíssimo” e em nenhum momento posso contradizer tal afirmação.
Porém perceba que mesmo na afirmação acima temos algo que pode se tornar um grande problema. Seu usuário enxerga Software funcionando na cara dele e não banco de Dados. Com base nisso a preocupação do Alexandre é que se você monta seu banco de dados primeiro e fecha um Sistema em cima desse modelo, você corre o risco de 2 coisas:
1 - empacar algumas coisas na sua apresentação de dados por conta de tipos mal pensados;
2 - Quando as telas forem aparecendo e as manutenções também, o custo de mexer no BD aumenta consideravelmente, e o belo Modelo ER que foi pensado antes do designer da aplicação, começa a se comunicar com a mesma através da criação das malditas “FLAGS”, deixando o Sistema todo remendado e com regras confusas;
Com base nisso, respondo sua pergunta. Claro que é perfeitamente possível fazer um Sistema do 0, começando pelo modelo ER, em momento algum alguém discordou disso. O que estão tentando lhe dizer é que não é aconselhável e nem muito menos fácil, a menos que você queira sacrificar a manutenção.
Várias pessoas já desaconselham a prática, o que não quer dizer que a torne errada, mas é porque realmente já apanharam bastante com tal abordagem.
Resumindo, não é errado é só desaconselhável.
Abs []
Regras de negócio é o que o cliente quer executar. Se vc não entende o que o cliente quer, não tem como fazer o sistema.
Sim. Regras de negócios sao os problemas que o cliente quer resolver. Em nenhum momento banco de dados entra na conversa. Banco é infra
Pq? Para estudo ou para distribuição?
Abs!
Estava estudando ele, mas penso em utilizar isso nas minhas distribuições.
Até agora para sistemas simples a idéia tem funcionando.
Exatamente. O que quero mostrar é que algumas soluções podem ser melhores que outras e vice versa
+1
E infelizmente muitos levam os modelos anêmicos para o design do código. BOLOVOS que até hoje sobrevivem.
Exatamente. Possível é, aconselhável não.
Perfect!
Abs!
[Desviando o tópico]
E por que voce faria isso??? Os Frameworks do mercado não estão atendendo às suas necessidades?
“As suas distribuições” você que dizer nos sistemas que você for desenvolver ou está desenvolvendo? Tem a possibilidade de outro programador colocar a mão nisso? Se sim, de verdade, aconselho fortemente que você repense isso!
Soluções caseiras são aberrações mal projetadas e que atrapalham a vida de qualquer programador. Em nenhum momento estou falando do seu Framework e sim da utilização dele em produção.
[/Desviando o tópico]
Abs!
Estava estudando ele, mas penso em utilizar isso nas minhas distribuições.
Até agora para sistemas simples a idéia tem funcionando.
[Desviando o tópico]
E por que voce faria isso??? Os Frameworks do mercado não estão atendendo às suas necessidades?
“As suas distribuições” você que dizer nos sistemas que você for desenvolver ou está desenvolvendo? Tem a possibilidade de outro programador colocar a mão nisso? Se sim, de verdade, aconselho fortemente que você repense isso!
Soluções caseiras são aberrações mal projetadas e que atrapalham a vida de qualquer programador. Em nenhum momento estou falando do seu Framework e sim da utilização dele em produção.[/Desviando o tópico]
Porém, todavia, entretanto, se seu Framework corresponder em seus testes, não custa nada distribuir como Open Source e tentar juntar uma galera para ajudar…
Vai que cola… e mesmo que não dê certo, valeu a experiência.
Abs []
Abs!
Pessoas, não há o CERTO e o ERRADO nessa brincadeira de desenhar Sistemas.Ambos modelos funcionam e é perfeitamente válido começar um Sistema a partir do modelo relacional.
O que o Alexandre está falando, é concentrado unicamente para Sistemas que querem apoiar-se na Orientação a Objetos para serem escaláveis, de fácil manutenção, livres de gambiarras, etc.
O que ele está tentando lhe mostrar é que começar a modelagem de um Sistema a partir de seu modelo relacional traz alguns perigos. Um dos pontos fortes na argumentação dele é que quando você modela um banco de dados relacional, você já está garantindo que seu sistema terá um Banco de Dados Relacional e que qualquer mudança desse paradigma pode ferrar com seu projeto lá na frente.
Esse exemplo não é meu, mas tenho uns amigos que começaram a modelagem de um Sistema há um tempo atrás e lá pelo 5º mês descobriram que o modelo reclacional ia ferrar com o que eles queria fazer. Tinham 2 opções;
1 - Inventar gambiarras relacionais que consertariam um problema e arranjariam outro;
2 - Pensar em uma alternativa ao modelo ER;
Depois de 1 ou 2 semanas de tentativas e algumas pogs, chegaram a conclusão que um banco Não Relacional seria a saída. Hoje o sistema está implementado no Voldemort;
Se você perceber, ficamos tão fechados nessa idéia de banco de dados relacionais que dificilmente conseguimos enxergar fora da caixa.
Outro perigo grande nessa abordagem é que Modelo OO !!!==== de Modelo ER.
Uma linha de uma tabela precisa de uma gambiarra de mapeamentos e Objetos Anêmicos para todos os lados pra poder ser representada em um Modelo OO.
Claro que para as argumentações acima você pode dizer que: “90% dos Sistemas hojes são resolvidos com modelos relacionais” e eu lhe respondo: “PERFEITO, você está certíssimo” e em nenhum momento posso contradizer tal afirmação.
Porém perceba que mesmo na afirmação acima temos algo que pode se tornar um grande problema. Seu usuário enxerga Software funcionando na cara dele e não banco de Dados. Com base nisso a preocupação do Alexandre é que se você monta seu banco de dados primeiro e fecha um Sistema em cima desse modelo, você corre o risco de 2 coisas:
1 - empacar algumas coisas na sua apresentação de dados por conta de tipos mal pensados;
2 - Quando as telas forem aparecendo e as manutenções também, o custo de mexer no BD aumenta consideravelmente, e o belo Modelo ER que foi pensado antes do designer da aplicação, começa a se comunicar com a mesma através da criação das malditas “FLAGS”, deixando o Sistema todo remendado e com regras confusas;
Com base nisso, respondo sua pergunta. Claro que é perfeitamente possível fazer um Sistema do 0, começando pelo modelo ER, em momento algum alguém discordou disso. O que estão tentando lhe dizer é que não é aconselhável e nem muito menos fácil, a menos que você queira sacrificar a manutenção.
Várias pessoas já desaconselham a prática, o que não quer dizer que a torne errada, mas é porque realmente já apanharam bastante com tal abordagem.
Resumindo, não é errado é só desaconselhável.
Abs []
Estou pensando no que falou.
1 - empacar algumas coisas na sua apresentação de dados por conta de tipos mal pensados;
A única forma séria de me prejudicar que vi, seria se uma má escolha de meu tipo de dado me obrigasse a desmanchar um relacionamento entre duas entidades.
Mas veja, o tipo de dado que uso para relacionar 2 entidades é sempre inteiro FK.
Como uma fala de escolha de tipo poderia me atrapalhar?
É possivel que esteja preso na caixa.
Preciso de um exemplo simples pra entender como isso pode ocorrer.
Com toda certeza! E o Github está aí pra isso. Opa, e por sinal, Luiz Augusto Prado se puder/quiser disponibilizar isso no Github seria legal. =)
Mas o que eu quis dizer foi deixar um projeto (fatalmente será legado para alguém) com um framework caseiro para outros desenvolvedores, sem que este framework esteja maduro/conhecido/tenha apanhado/etc
Vale a pena a leitura: http://www.milfont.org/tech/2009/06/06/frameworks-caseiros-2-a-missao/
Abs!
Estava estudando ele, mas penso em utilizar isso nas minhas distribuições.
Até agora para sistemas simples a idéia tem funcionando.
[Desviando o tópico]
E por que voce faria isso??? Os Frameworks do mercado não estão atendendo às suas necessidades?
“As suas distribuições” você que dizer nos sistemas que você for desenvolver ou está desenvolvendo? Tem a possibilidade de outro programador colocar a mão nisso? Se sim, de verdade, aconselho fortemente que você repense isso!
Soluções caseiras são aberrações mal projetadas e que atrapalham a vida de qualquer programador. Em nenhum momento estou falando do seu Framework e sim da utilização dele em produção.[/Desviando o tópico]
Abs!
Sim, eu sei que estou diante de algo que pra ser bom vai precisar de muita gente.
Eu não conseguirei fazer algo robusto como um JPA ou o Hibernate, que possui uma galera enorme ajudando.
A minha idéia é tentar criar algo simples de forma que o máximo de pessoas possam utilizar e entender sem ter que ficar anos estudando para entender todo um codigo.
As coisas evoluem e crescem em volume de dados rapidamente. Isso pra mim é outra variavel que coloco em consideração no desenvolvimento.
Desaconselho o framework em projetos em produção que envolvam outras equipes, mas a ideia em si é ótima, principalmente como estudo.
Se possível deixe no Github o projeto e a galera que se interessar vai querer ajudar com toda certeza =)
Abs!
Sim, eu sei que estou diante de algo que pra ser bom vai precisar de muita gente.
Eu não conseguirei fazer algo robusto como um JPA ou o Hibernate, que possui uma galera enorme ajudando.
A minha idéia é tentar criar algo simples de forma que o máximo de pessoas possam utilizar e entender sem ter que ficar anos estudando para entender todo um codigo.
As coisas evoluem e crescem em volume de dados rapidamente. Isso pra mim é outra variavel que coloco em consideração no desenvolvimento.
Desaconselho o framework em projetos em produção que envolvam outras equipes, mas a ideia em si é ótima, principalmente como estudo.
Se possível deixe no Github o projeto e a galera que se interessar vai querer ajudar com toda certeza =)Abs!
Legal, tenho interessem formar uma equipe.
Quem tiver interesse em participar de uma equipe mande uma MP.
Uma das minhas metas é que o ORM possa ser estudado e compreendido por inteiro dentro do espaço de algumas horas.
Alguem acha que pode colocar outra meta importante?
Quem sabe se vc criar um tópico pra isso a galera participa =)
Abs!
Eu acho q não dá para ter uma posição radical a esse respeito.
Vc querer documentar tudo nos mínimos detalhes realmente é impossível, como o amigo acima falou, o código é uma coisa viva e “muda” constantemente.
No entanto, acho benéfico haver um punhado (uma pequena quantidade que seja) de diagramas, em especial de atividades e de sequência, descrevendo em um nível de abstração alto algumas regras de negócio complexas. Ele não precisa ir até o último dos detalhes, não tem que mostrar de onde o objeto Usuario vai obter um UsuarioDAO para consultar se o login/senha está correto (até porque os containers tipo Spring fazem isso de forma transparente).
Eu mesmo, quando vou modelar algo, eu parto sempre do diagrama de sequência. Ele é muito rico e é fácil vc definir rapidamente: este objeto fala com este, retorna para aquele e assim vai. Em uma imagem fácil de entender vc detalha a regra de negócio e os objetos que interagem nela (e o melhor, como interagem!). Estes dias estava tentando pensar em um módulo do sistema que estou fazendo e comecei a rascunhar diagramas de sequência. Primeiro diagrama: não, isto não está bom. Segundo: também não está. No terceiro que eu percebi que tinha um objeto apenas enchendo linguiça ali, fiz a 4ª versão sem aquele objeto e sorri: é isto que eu quero! Talvez gente + tarimbada do que eu (eu tenho pouca experiência com linguagens OO) enxergasse o problema logo na primeira olhada.
Ou seja, como ferramenta de modelagem, a UML é poderosa (sabendo usar!). Mas não desprezaria a possibilidade de incluir o diagrama que fiz na documentação, é bom eu ter uma referência de “como” eu cheguei naquela forma de conectar objetos